ソフトウェア開発ライフサイクル
ソフトウェアを開発する際の標準的な手順のこと。
共通フレームでソフトウェアの構想から破棄に至るまでの各工程について作業内容や用語が示されている。
多くのプロセスがあるが、基本情報では以下のプロセスとその流れを把握しておけば大丈夫らしい。
企画プロセス
経営上の課題を確認し、新しいシステム実現のための計画をするプロセス。
システム化構想とシステム化計画を立案し、開発順序、コスト、効果などのシステム化の全体像を明らかにする。
要件定義プロセス
システムや業務全体の枠組み、システム化の範囲と機能を明らかにする。
要件には機能要件と非機能要件の2種類がある。
- 機能要件：処理手順やデータ項目など業務機能に関連するもの
- 非機能要件：性能、信頼性、セキュリティ、開発基準など機能要件以外のもの
開発プロセス
様々な工程が含まれます。
システム要件定義
システム要件の定義、システム要件の評価、システム要件の共同レビューを実施する。
取りまとめる要件は主に以下の4点。
- システム化の目標と対象範囲
- 機能及び能力の定義
- 業務・組織及び利用者の要件
- その他の要件：開発期間、環境、品質など
システム方式設計
要件定義に基づき、情報システムの機能を決定する。
システム要件の実現様式を決める。(手作業で行うのかコンピュータで行うのか)
それにぞれに必要なシステムの構成を決めていく。
具体的に決定することは以下の通り。
- ハードウェア方式設計：フォールトトレラントとか信頼性をここで考える
- ソフトウェア方式設計：ソフトウェアやミドルウェアの選択
- システム処理方式設計：集中処理とか分散処理とか
- データベース方式設計：関係データベースなのかXMLデータベースなのかとか
また、システム結合テストのテスト計画書もこの段階で作成する。
ソフトウェア要件定義(外部設計)
業務の流れ、データの流れ、画面の設計、セキュリティ対策、保守を決定。
ヒアリング、ユースケース図、DFD、プロトタイプ、UML、E-R図などを用いる。
ソフトウェア方式設計(内部設計)
システムを機能単位のコンポーネント(サブシステム)に分割し、コンポーネント間の仕様を決定する。
ソフトウェア詳細設計(プログラム設計)
コンポーネントをモジュールに分割する。
各モジュールでどのような処理を行うか、モジュール間でデータをどのように受け渡すかを決める。
(モジュールは実際の開発単位であり、プログラムの部品)
また、単体テストの仕様書も作成する。
コーディング
モジュール毎にコーディングを行っていく。
単体テストを行い、モジュールが正しく動いていることを確認する。
正しく動作していなければデバックを行う。
テスト
プログラムを組み合わせ、ソフトウェアが要求通りに動くかを検証する。
結合テスト、システムテスト、運用テストの3種類のテストがある。
別々に開発されたモジュールを結合して行うテスト。 モジュール間でのデータの受け渡しや、モジュールのつなぎ合わせがうまくいっているかを確認する。 結合テストによって単体のプログラムとしての動作確認が完了する。 プログラムを組み合わせたシステム全体として正常に動作するか確認する。 機能や操作性も評価する。 機能テスト システムの機能が正常に処理されているか確認する。ソフトウェア要件定義書のすべての機能についてテストを行う。 性能テスト 性能を評価する。
スループット、ターンアラウンドタイム、レスポンスタイムなどを計算し、要件定義書の基準を満たしていることを確認する。 負荷テスト 大量のデータや、長時間の稼働にシステムが耐えられるかをテストする。
想定されたピーク時以上の負荷をかけてテストを行う。 運用テスト 運用に問題がないかを確認するテスト。
本番環境のシステム構成で、実際のデータを使い、システム利用者や運用部門がテストを行う。テストの詳細
移行
運用テストで正常に動作することが確認できれば、受け入れとなる。
移行計画にそって新システムへ移行する。
運用プロセス
システムを利用するための日常的な維持管理。 機器の管理、運用要員の育成など。
保守プロセス
ソフトウェアやハードウェアの修正や変更を行う。 バグ修正を行う 「修正保守」、法改正に対応する 「変更保守」、操作性向上などに対応する 「改良保守」 がある。
変更後は、修正を行った部分以外も正しく動作するか確認する「リグレッションテスト(回帰テスト)」を行う。
要件定義が3つもあってわかりにくい。
インターフェースとか画面の設計が出てきたらソフトウェア要件定義と覚えておけば大丈夫？？
