情報システムの概要

目的

• コンピュータを活用する問題解決の手順や問題解決と情報との関わり。(普通教科｢情報｣)
• コンピュータの特性及びコンピュータによる情報処理の特徴。(普通教科｢情報｣)
• 社会で利用されている代表的な情報システムの種類や特性等。(普通教科｢情報｣)
• 情報システムの設計･開発、運用保守に関わる基本的な知識や技術。(専門教科｢情報｣)

内容

問題解決とコンピュータの活用

コンピュータを用いた情報システムの設計･開発を学習する前提として取り上げる。

問題解決と情報

｢意思決定｣：代替案の中から案を選択すること
　⇒決定手順：情報の収集→代替案の作成→選択

｢問題解決｣：問題に対して定めた目標に近づくために行う意思決定とそれに基づく一連の過程。
　⇒解決手順：問題の発見→問題の分析→解決策の提案→行動

｢情報システム｣：意思決定を支援するために、必要な情報を、必要なときに、必要とする人や組織に提供するためのシステム。

｢システム思考｣：問題解決のための思考法で、対象をシステムとして捉え、そこに発生する問題を解決してゆくための意思決定と情報の関係を体系的に整理する手法。

• ブレーンストーミング(brainstorming)、KJ法、デルファイ法等(問題の発見･解決に関わる技法)
• シミュレーション(simulation)、オペレーションズリサーチ(OR)等(意思決定支援のための技法)

指導上の留意点

技法を指導する際には、簡単な問題を例示し、その解決過程を通して実践的に身に付けさせることが重要。

コンピュータによる情報処理の特徴

コンピュータの特性：自動性、高速性、正確性及び大量性。

コンピュータによる情報処理の長所：大量データを高速に処理する業務や、(処理を事前にプログラムするので)同じ処理を周期的に繰り返す提携業務。

コンピュータによる情報処理の短所：問題の解決に推理や直感が必要な業務、非定型業務。
* 短所を補う技術が開発･研究され、エンドユーザーコンピューティング(EUC)が進展し、非定型業務もコンピュータが活用されている。

情報システム：人間の意思決定に必要な情報を、正確かつ迅速に提供することが目的。

情報処理システム：情報システムのうち、具体的な処理の部分の自動化、高速化、正確化を図るためにコンピュータを活用して処理を行うシステム。

指導上の留意点

まずコンピュータの特性。次に情報システムが意思決定や問題解決を支援するということ。その情報システムの中の役割として情報処理システムが存在し、コンピュータの特性が十分に活用されていることに気づかせる。

情報処理システムの種類と実際

情報処理システムの形態と特性

バッチ処理：データを一定期間蓄積し、一括して処理する処理形式。成績処理には適するがチケット予約処理には適さない。センターバッチ処理とリモートバッチ処理がある。

リアルタイム処理：データが発生する都度処理を行い、その結果を報告する処理形式。通常、オンライン方式で処理される。

集中処理：1台の処理能力の高い大型コンピュータで処理するシステム。

分散処理：ネットワークで結んだ中型や小型のコンピュータで処理を分散するシステム。

クライアントサーバシステム：ネットワークで結んだコンピュータを機能ごとに専門化して処理を分担させるシステム。

指導上の留意点

• 身のまわりの業務でバッチ処理に適した業務、適さない業務を考えさせ、発表させる等で理解を深めさせる。
• センターバッチ処理の短所を指摘し、これを補うためのリモートバッチ処理の長所が説明できるよう指導する。
• リアルタイム処理の指導では、身近な例でリアルタイムに結果を必要とする処理を考えさせ、さらにその処理をバッチ処理で行うと不都合な点を考えさせる。この欠点を解消するためにオンラインリアルタイム処理が開発されたことを理解させる。
• 分散処理と集中処理の指導では、他方の短所ともう一方の長所の関係を考えさせ、業務内容によるシステム選択の必要性に気づかせる。
• クライアントサーバシステムの指導に当たっては、パソコンをクライアントサーバシステムにつないだ場合の利点を考えさせる。

情報処理システムの実際

社会における情報システムとして、高度道路交通システム(ITS)、金融情報システム、予約システム、企業における情報システム、エンジニアリングシステム等がある。

指導上の留意点

ここでは技術的な側面について取り上げる。その際、システムが必要とされるようになった理由を理解させる。

情報システムの開発

情報システムの分析･開発にかかわる技法

ここでは、比較的大規模で、開発者と利用者が異なり、保守管理が必要な情報システムを対象として考える。

システム開発のアプローチ

次の2種類がある。

• ｢トップダウンアプローチ｣：大きな枠組みを作ってから、内部の小さな部分を作成する方法。段階的詳細化技法とも呼ばれ、情報システムの開発では、主に設計工程に取り入れられている。
• ｢ボトムアップアプローチ｣：小さな部分を部品としてつくっておき、それらを組み合わせて全体を作り上げる方法。段階的統合化技法とも呼ばれ、情報システムの開発では、主にテスト工程に取り入れられている。

システムの開発モデル

• ｢ウォーターフォールモデル｣：上流の工程から下流の肯定に向かって順番に作業を進める方法で、工程の管理がしやすい反面、後に発見された問題点については膨大な手直しが必要になる。設計開発段階はトップダウンアプローチで、テストから運用保守にかけてはボトムアップアプローチで作業が進められる。
• ｢プロトタイプモデル｣：開発工程の初期段階でシステムの核となる部分を試作品として形作り、利用者の要求を確認した上で、本格的な開発を進める方法。工程における修正作業を大幅に減らすことができる。比較的規模の小さいシステムの開発に適している。
• ｢スパイラルモデル｣：企業内で経営環境の変化に応じた業務改善を行う場合に用いられるPDS(Plan-Do-See)の考え方をシステム開発に適用したモデル。｢計画｣→｢プロトタイピング｣→｢テスト･利用者の評価｣のサイクルを繰り返しながらシステム開発を進める方法。仕様の変更を積極的に取り入れることができ、限られた期間内で一定の開発要求に応えたい場合などに活用される手法である。

指導上の留意点

• 具体例を示すなどの工夫が必要。
• 開発技法の特徴(長所、短所)に触れるとともに、これらに対応する形で様々な設計技法が開発されたことを理解させる。

ソフトウェア開発の工程

基本設計

開発の対象となるシステムの実現の可能性や問題点等について、調査、分析を行う。

｢システム化計画｣･｢プロジェクト実行計画｣･｢要求定義｣という3工程がある。

外部設計

利用者の立場から見たシステム設計の工程。ユーザの希望を十分に取り入れ、インタフェースを構築する。

6工程「要求仕様の確認」・「サブシステムの定義と展開」・「画面設計･報告書設計」・「コード設計」・「論理データ設計」･｢外部設計書の作成｣。

業務分析の際には、文章表現よりも図式表現を用いたほうが明確になる。図式表現を用いた分析技法には、DFD(data flow diagram)、HIPO(hierarchy plus input process output)等がある。

内部設計

システム開発者側から見た設計工程。

5工程｢外部設計書の確認｣･｢機能分割･構造化｣･｢物理データ設計｣･｢入出力詳細設計｣･｢内部設計書の作成｣。

システムを構成する機能を分かりやすく表現するために、流れ図、DFD、構造化チャート、HIPO状態遷移図などが用いられる。

プログラム設計

内部設計で機能単位に分割されたプログラムを、さらに構造化技法などを活用してコンパイルの単位であるモジュールに分割する作業。

5工程｢内部設計書の確認｣･｢モジュールの分割｣･｢モジュールの仕様の作成｣･｢プログラム設計書の作成｣･｢テスト仕様の作成｣。

プログラミング

プログラム設計で分割された各モジュールを、実際のプログラムに置き換える作業。

3工程｢基本制御構造｣･｢プログラムの表現｣･｢プログラミングにおけるパラダイム｣。

テスト

開発したシステムが使用のとおりに機能するかどうかを確かめ、問題点を改善しながら完成に導く作業。

4工程｢単体テスト｣･｢結合テスト｣･｢システムテスト｣･｢運用テスト｣。

指導上の留意点

• 簡単なソフトウェアの開発は演習で取り上げる。
• データ構造やアルゴリズムは、ここでは概要の説明程度の取り扱いとする(｢アルゴリズムの基礎｣で具体的に取り上げているので)。

システムの運用保守

保守：修正作業、変更作業、改良作業。

システムの信頼性を示す指標RASIS：信頼性(Reliability)･可用性(Availability)･保守性(Serviceability)･安全性(Integrity)･機密性(Security)。

冗長性：シンプレックスシステム、ディプレックスシステム、デュアルシステム、マルチプロセッサシステム。

障害対策：フォールトトレラント、フェイルセール、フェイルソフト、ミラーリング。

指導上の留意点

個々の作業やシステムなどの内容の理解を通して、運用･保守の必要性を理解させる。

参考編

｢参考編｣はテキスト(2)p43以降にあり、テキストには｢個別に研修を進める上で必要と思われる補充的な内容をまとめた｣と書かれている。上記の｢内容｣と重複する点は省きながらまとめておく。

問題解決とコンピュータの活用

問題解決と情報

意思決定と情報

意思決定：｢今日、傘を持ってきたか？｣←情報システムが意思決定を支援。

問題解決とその手法

｢ブレーンストーミング｣の説明：メンバーが特定のテーマについての様々なアイデアを自由に提案しあい、これを記録･整理することにより、問題の発見や、解決のための発想を得ようとする手法。

｢オペレーションズリサーチ(OR)｣の説明：問題を数学的なモデルとして記述することによって、科学的に問題解決を行おうとする手法。すでに在庫問題や輸送計画、待ち合わせ問題などの分野で定石的な解決策が確立されている。

コンピュータによる情報処理の特徴

情報システムと情報処理

SIS(戦略情報システム：strategic information system)：戦略的な経営を支援する目的で構築されたシステム。

例(POSシステム)：POSレジスタで収集したデータを本部コンピュータで集計し、結果を販売情報として加盟店にフィードバックし、その意思決定を支援したり、在庫情報に基づく商品発注を支援するなど。

用語の包含関係

情報システム ⊃ 情報処理システム ⊃ データ処理システム

情報処理システムの種類と実際

専門的な用語を整理しておく。

バッチ処理

長所：

• 必要なデータをまとめて処理するため、処理がスタートすると完了するまで人間の介在が必要ない。
• コンピュータの使用効率がよい。

短所：

• コンピュータに処理要求を出してから処理結果が出力されるまでの時間(ターンアラウンドタイム)が長い。

適する業務：

• データの量は多いが、緊急性の伴わない定型業務。

センターバッチ処理：

• 発生したデータをコンピュータのある場所(コンピュータセンターなど)へ持ち込み、ここで一括入力して処理する方式。
• 持ち込みに時間がかかる場合がある。

リモートバッチ処理：

• データの発生場所の端末装置とコンピュータを通信回線で結び、端末装置からバッチ処理を起動させて直接データを送り込むシステム。
• 持ち込み時間が短縮される。

リアルタイム処理

リアルタイム処理：

• データが発生する都度、即座に処理を行ってその結果を報告する処理形式。
• 日本においては、｢みどりの窓口｣(1960年稼動開始)が最初のシステムである。

オンラインリアルタイム処理：

• リアルタイム処理は通常、データの発生場所にある端末装置とコンピュータを通信回線で結んである。
• 遠隔地で発生したデータを直接コンピュータに入力し処理結果を即座に端末装置に返すことができる。

垂直分散システムと水平分散システム

垂直分散処理システム：

• 規模の違ったコンピュータを階層的に結びつけ機能を分散するシステム。

水平分散システム：

• 複数台のコンピュータを対等な関係で結び、機能の分担や資源の共有を行いながら処理を行うシステム。

複合分散処理システム：

• 部門内の処理など限られた範囲の処理はクライアントサーバシステム(水平分散システム)で処理し、さらにこれを結んだ全社システムを垂直分散処理の形態で構成するシステム。
• 現在の企業で多く利用されている。

情報システムの開発

基本制御構造

構造化定理：いかなるプログラムも、以下に示す3つの基本制御構造のみを用いてアルゴリズムを記述できる。

• 順次構造：記述された順に処理を行う制御構造。
• 選択構造：条件判定の結果の真、偽に対応して処理の1つを選択する制御構造。
• 繰り返し構造：条件を満たしている間、処理を繰り返す制御構造。前判定繰り返し構造とも呼ばれる。

拡張構造

以下に示す拡張構造を用いて記述するとプログラムが簡明に表現できる場合がある。

繰り返し構造(後判定)：

• 処理後に条件判定を行い、条件を満たすまで、処理を繰り返す制御構造。

複合選択構造(CASE構造)：

• 条件に対応して、複数の処理を選択できる制御構造。

テスト

単体テスト：

機能の単位であるモジュールが設計どおりに機能するかを確認するテスト。次の2つの観点からテストを行う。

• ホワイトボックステスト：モジュールの内部の仕組みを確かめるテスト。プログラムの構造の正しさを確認する。
• ブラックボックステスト：モジュールの構造を無視して外部からとらえ、機能や応答を確認する。

結合テスト：

単体テストを終了したもモジュールを組み合わせて行うテスト。仕様通りに機能するかどうかの確認に加え、信頼性や操作性などについても検証する。どのモジュールからテストを始めるかで、4つに分類できる。

• ボトムアップテスト：テスト済みのモジュール群の上位に、新たなモジュールを結合して行うテスト。テストの際に未開発の上位モジュールの代わりに用いるダミーをドライバという。
• トップダウンテスト：テスト済みのモジュール群の下位に、新たなモジュールを結合して行うテスト。テストの際に未開発の下位モジュールの代わりに用いるダミーをスタブという。
• サンドイッチテスト：トップダウンテストとボトムアップテストを組み合わせて行うテスト。
• ビッグバンテスト：単体テストが終了したすべてのモジュールを一斉に結合して行うテスト。一度にすべてのモジュールの結合状態がテストでき、ドライバやスタブも不要であるが、大きなモジュール群では、バグの箇所の特定が困難である。

システムテスト：

システムの総体が仕様を満足していることを確認するテストである。プログラム間に対する結合テストであり、機能テスト、性能テスト、操作性テスト、障害テスト、負荷テスト、耐久テストがある。

運用テスト：

実際の運用と同じ条件において、システムが要求仕様を満たしているかを、機能面、操作面の双方から確認するテストであり、承認テスト、導入テスト、実地テストがある。

システムの運用保守

システム運用と保守

運用：利用者によってシステムが活用されること。

保守：システムの維持、管理のために運用しているシステムの修復や変更を行うこと。原因により次のようなものがある。

• 修正作業：運用中に発見されたバグに対応する作業。
• 変更作業：外部環境の変化やデータ項目などに変更が生じた場合に、対応するための作業。
• 改良作業：機能の追加、性能の向上、操作性に対する要望など、｢より良く使用したい｣という利用者の要求に対応するための作業。

システムの信頼性

RASIS

信頼性(Reliability)：コンピュータが故障せず、正常に動作することをさす。評価法としては、平均故障間隔(MTBF;mean time between failures)を用いる。なお、修正できない場合には、寿命(MTTF;mean time to failure)が用いられる。

可用性(Availability)：コンピュータを使用したいときに、利用できることをさす。評価法としては、｢稼働率=MTBF/(MTBF+MTTR)｣を用いる。MTTRは平均修理時間(mean time to repair)である。

保守性(Serviceability)：コンピュータの保守や修理が容易にできることをさす。評価法としては、MTTRを用いる。

安全性(Integrity)：故意または過失によるデータの改竄や破棄を防止したり、修復できることをさす。

機密性(Security)：部外者が扱えないよう、データが保護されていることをさす。

信頼性の向上(冗長性)

シンプレックスシステム：予備機を持たない最小の構成のシステム。冗長性をもたないため、経済性はもっとも有利であるが、すべての機器が1系列のみ直列に接続されているので、どれかが故障すれば、システム全体が機能しなくなる。

ディプレックスシステム：主系統と予備系統の2系統のコンピュータを並列に接続してシステムを構成する。障害発生時に、主系統から予備系統に切り替えて処理を続けることにより、システム全体の停止を防いでいる。ただし、切り換える際には切換時間が必要となる。

デュアルシステム：2系統のコンピュータが同時に同じ処理を行い、それぞれの処理結果を照合しながら処理を進めるシステム。障害の検出が即座にでき、信頼性の高いシステムが実現できる。もし、1系統が故障した場合には、残る片側の系統で処理を継続する。

マルチプロセッサシステム：複数の処理装置で主記憶装置や外部記憶装置を共有し、各処理装置が処理を分担する高効率なシステム。故障が発生した場合、装置を切り離すことにより処理能力は低下するものの、処理は続行できるため、信頼性が高い。疎結結合マルチプロセッサシステム(処理装置がそれぞれ主記憶装置をもつ)と密結合マルチプロセッサシステム(処理装置が主記憶装置を居有する)がある。

障害対策

フォールトトレラント：避けられない障害が起こる場合に、障害を受け入れながらもシステムを維持する技術や仕組み。

フェイルセール：故障や失敗が発生した場合に、安全な側に装置を誘導する技術や仕組み。

フェイルソフト：故障や失敗が発生したときに、システムの一部を切り離し、性能の低下があっても、処理を続行する技術や仕組み。

ミラーリング：記憶装置の故障に備え、複数の記憶装置に同一データを記録すること。

感想等

データフローダイヤグラム(DFD)による業務分析について

• DFDは、フローチャートを書くよりも敷居が低く、生徒に教えるには単純なものから順に、段階的に指導するのがよいと思われる。
• 処理が複雑になると表現するのが難しくなるが、論理的に処理の流れを追うことに集中でき、業務を見直すためにも有効な方法である。特に日常的に行っている処理を題材にした課題は、思わぬ発見があったりして、意欲的に取り組みやすいのではないか。
• どのレベルまで細分化するかを決める基準が難しい。
• DFDを手書きしない場合は、書きやすいソフトウェアを選ばないと、記号の配置等に手間取り、思考を中断させてしまう場合がある。特にデータストア名を表現する記号のアッパーラインを表す方法が難しいだろう。効率的な方法を考える必要がある。
• 普通教科｢情報｣でも扱い、ソフトウェアを開発する側ではなく、使う側としても情報の流れを分析したり、システム思考になれることは、非常に意味のあることだと感じる。なぜなら、このようなシステム分析により作られた情報システムの上で生活しているのが高度情報通信社会であり、生活の基盤にある様々な仕組みを理解しながら生活することにつながるであろうから。
• DFDを作成させる実習は非常に有意義であるが、普通教科｢情報｣の場合、作成例は販売や在庫管理のような社会的な内容よりも、学校生活等、さらに身近な内容から始めて、徐々に社会に目を向けさせていく方が取り組みやすいではないだろうか。すなわち、DFDに慣れさせるには、より興味を持ち楽しい分野を扱い、慣れてきてから社会において知るべき分野に進むようにすればいいのではないか。

システム開発演習について

プログラムを扱うのは普通教科｢情報｣では難しく、深入りするのは無理である。普通教科｢情報｣で情報システムについて扱う場合の実際の授業を想定すると、動機付けから教材の選択や指導方法、実習内容など、まだまだ難しい点が多いと思われる。

その他

｢情報システムの概要｣は、｢問題解決｣や｢コンピュータ概論｣、｢情報化と社会｣、｢情報と生活｣などの分野とも密接に関連している。内容は掘り下げると急激に難しくなることがらが多いが、このような分野との関連性を重視して例示や実習内容を決め、社会の状況から乖離しないわかりやすい授業を展開していかなければならないだろう。

参考文献

平成13年度新教科｢情報｣現職教員等講習会テキスト(2)　文部科学省

高等学校学習指導要領解説　情報編　文部省

以上　作成2001.9.24　(1行目に戻る)

他のページに移る場合は、ブラウザのボタンを使ってください。