今回はウォーターフォールモデル開発とアジャイル開発に使われる工程に沿って紹介します。
##工程の流れ
##要件定義
要件定義において、ユーザーの意見というのはザックリした考えが多い。そこで、ユーザーの不完全な意見をベンダー側で積極的にガイドする必要がある。少ない人数の中で、多くのアイデアを必要とするのでブレーンストーミングするのも良い方法である。
システム要件定義:ユーザにヒヤリングを行い、システム化する範囲や対象業務を明確にし、新システムに必要な機能を検討する。
ソフトウェア要件定義(外部設計):画面のレイアウトと画面操作時の動作、画面上にどのような入力欄,ボタンを配置するのか、その処理について定義して文書化する。
帳票に何を印刷するのか、どのようなレイアウトで印刷するのかなどを決める。データのやりとりについての設計
##基本設計
システム方式設計:ハードウェアの構成、調達するソフトウェアパッケージ、システムの処理方式など、要件定義書に記載された機能の実現に必要なシステムの構成を決める。
ソフトウェア方式設計(内部設計):外部設計で設計した内容を、具体的にどのように実装するかを設計する。
システム開発者の為の設計なので、システム開発担当者だけで行うのが一般的である。
ソフトウェア詳細設計(プログラム設計):実装の直前に、各プログラムの動作や処理の流れを詳細に定義する。
##開発
プログラミング:モジュールごとにプログラミングを作成。
単体テスト:作成したモジュールごとに、バグがないか検証。
##結合テスト
単体テストをクリアしたモジュールを結合し、各設計書に定義された機能要件どおりに動作するか
詳細はこちら →http://gihyo.jp/lifestyle/serial/01/ipa-terminology/0013
##システムテスト
システム全体を対象に行われるテスト。製品として完成したものを本番とほとんど同じ環境でテストを行う。
銀行では第３者に数十日間のテストを行ってもらうのこと。
システムテストも最終的な結合テストといえますが、結合テストは設計・構造の妥当性を確認する － 要求とそれに対するシステムの妥当性を確認するものです。 結合テストは対象物の内部構造に焦点を合わせ、システムテストでは人と対象物に焦点を合わせます
##運用・保守
移行:実際の稼働環境へシステムを移す。
*一斉移行:ある時点でシステムから新システムへ一気に切り替える
*順次移行:システムの機能や支店・部門などの単位ごとに新システムへ切り替えていく
保守:一度完成したシステムも、ハードウェアの故障への対応や、業務の変化に伴う修正などの保守が随時行われる。
*予防保守:障害の発生を事前に防ぐために定期的に行われる
*事後保守:障害発生後に行われる