第14章 情報システムの設計手法
コンピュータの発達により、情報システムで実現できることが複雑で多岐にわたるようになってきて、ソフトウェア開発の需要が増加
→品質のよいソフトウェアの開発者の確保が困難
→ソフトウェアが開発できない。
→情報化社会の発展が阻害される。
一定以上の品質を持つソフトウェアを効率よく開発する方法論や手法が必要となり、ソフトウェア工学によりこれらが研究された。
(この章では、主にシステム開発者が行う作業です)
1.ソフトウェア開発プロセス
1．ウォーターフォール型システム設計法（ライフサイクル型）
システムの開発の過程を、要求分析、設計、プログラミング、テスト、保守の段階に区切り、各段階で決められた目標を達成した後次の段階に進む。一度過ぎた段階には戻らないシステム設計方法。
水が上流の滝から流れていく様子を模写している。
要求分析
開発するソフトウェアが何を行うもので、どのような仕事に使うなどのソフトウェアの目的を設定する。
実際に利用するユーザの積極的な参加が必要。
設計
要求分析の結果、コンピュータ化する業務内容をどのように実現するかを明確にする。
プログラミング
プログラミング言語を用いて、プログラムを作成する工程
作成したプログラムが正しく動作するかの確認を行う。
単体テスト：プログラム単体が仕様通りにできているかを検証する。
結合テスト：まとまった処理を行う、複数のプログラムを組み合わせて正しく動作するか検証する。
システムテスト：開発したソフトウェアを組み合わせて全体として正しく動作するかを検討する。
運用テスト：実際の利用環境で、実務に絶えれるかどうかを検討する。
保守
実際の運用を通して発見された不具合や改良点などを修正していく。
対応が難しい場合は、次のシステム設計時に解決する場合もある。
ライフサイクル型の開発の考え方
開発の初期段階で問題が何かを明確にすると、何を開発したらよいかが明確になる。
何を開発したらよいかが明確になれば、どのように開発したらよいかが解決される。
最終的に、システムが開発される。
各フェーズの終了条件の設定が鍵となる。
ライフサイクル型のシステム開発は、何が問題かを明らかにし、それを解決するためにはどうしたらよいかという考え方を基にしている。
→何が問題化をユーザが考え、それをどのように実現するかをシステム開発者が考えるという分業が可能となり、高品質のソフトウェアが実現できる。
ライフサイクル型システム開発の問題点
人的資源の制約
システム開発部門の人員の固定化
エラー修正
各フェーズを終了したものは、下位に送られ戻ってくることはないため、システム開発の上流で生み出されたエラーが下流に行くまで発見されず、大きなダメージを与えることがある。
問題把握の限界
規模の大きさにより、何が問題で、どう解決するかといった手法が取れない。
実際に稼動してみて問題点が発見されたり、フィードバックの必要性が出てきた。
上流過程で、問題の明確化が行われないと次に進めない。
2.プロトタイピング型システム設計法
「利用しながら評価・改善していく」進化的アプローチ
プロトタイプと呼ばれる試作機を作成し、プロトタイプをユーザが使うことで問題点・改善点を発見し修正することで、最終製品を作り上げる。
開発手順
1)基本要件の確定：基本システムでユーザが求める情報を明らかにする。
2)プロトタイプシステムの開発：ユーザの情報要求に適合する対話型のアプリケーションシステムを開発する。
3)プロトタイプシステムの利用と評価：ユーザ自身がシステムを操作・利用し自らの情報要求に適合するかどうかを判断する。
4)プロトタイプシステムの改善と機能増幅：システム分析者・設計者がユーザの要求に基づき改善、機能の増幅を行い、再びユーザに利用・評価させる。
以下、「3)利用と評価」、「4)改善と機能増幅」を繰り返し、ユーザが満足するレベルに達すると、設計・開発は終了する。
プロトタイピングの適合する環境
情報システム化される業務・管理活動がさほど定型的でない場合。
情報システム化の対象となる業務・管理活動の範囲が相対的に狭く、機能的に分割されないが、内容的に複雑な場合
情報システムの設計者・開発者のレベルが低いため、適切なシステムの開発が困難な場合
プロトタイピングの問題点
開発プロセスの管理が困難
ライフサイクル型のシステム開発技法と異なる技術・知識が必要となる
大規模プロジェクトには適応が困難
3.反復型
ユーザの要求がまとまっていなければ、システムを開発することができないため、最初から完全なものを開発することを目的とせず、部分的な機能から開発し、それらを使用、評価し機能を拡充することで最終的なソフトウェアを構築する。作業計画を重視し、計画を管理しながら開発を進める
４．最近のシステム開発法
アジャイル：最初に全ての仕様を決めず、大体の方向性だけを決めて開発をする。開発により生み出されるソフトウェアに価値を置き、短い間隔(おおむね2週間程度)で要求の決定、実装、テスト、修正、リリースを繰り返すことで開発を進め全体の完成度を高める。臨機応変な対応が可能
スパイラル：システムをいくつかの単位に分け、それぞれの単位で要件定義、設計、開発、テスト、評価のサイクルを繰り返しシステム全体の完成度を螺旋のようにあげていく。
DevOps：開発担当者と運用者が連携して開発を行う手法
2.分析・設計手法
ソフトウェア開発では、ユーザと開発者間の意思疎通や開発者間での意思疎通を行う必要がある。この意思疎通の為の分析・設計手法として代表的なものが以下のものである。
1.構造化手法
業務の内容(処理の内容、必要な情報など)を明確に分析することで、作成するソフトウェアの設計に役立てる。
(1)データフローダイアグラム(DFD)
業務をデータの発生源や処理方法、保存などを図式化したもの。これを使用することで、データの発生源や処理内容、加工データを必要する処理などが視覚的に捉えることができる。
(2)ERダイアグラム
データ間の関連を図式化したもの。データ間の関連を視覚的にとらせることができるので、データベースの作成や処理に役立てる。
2.オブジェクト指向
従来のプログラムでは、1つ1つの部品はあるプログラム専用のもので再利用や他のプログラムからの利用が困難であった。
これに対して、各プログラムを再利用可能なオブジェクト(部品)として設計することでプログラムの生産性を高めている。
ソフトウェア開発に関する最近の話題
アウトソーシング
クラウドコンピューティング