システム開発は「家づくり」に似ている。
ここまでで経営ニーズ・利用者ニーズ（業務プロセスの洗い出し）などから、どんなシステムが必要か決まっているはずです。システム開発部門として、形作っていきます。開発フローが家づくりに例えられることが多く、一つずつプロセスを完了させながら進めていきます。
５つプロセス
- システム要件定義
- システム設計
- プログラミング
- テスト
- ソフトウェア受入れ
開発プロセスとは？
システム要件定義
システムに必要な条件（システム要件）を決める工程。どのようなシステムを作るのかを、明確にするプロセスで、システムに必要な「機能」や「性能」をきめます。また、業務契約上、システム開発範囲を決める部分でもあるので、かなり重要な部分となります。後々の「言った、言わない」のトラブルを未然に防ぐためにもしっかりと「要件定義書」を作成しましょう。
※データベース設計では『概念モデル』まで行います。
※SLCPの５つのステップ『要件定義プロセス』は「ユーザニーズ（業務要件）」を洗い出したが、システム要件定義は、『情報システム部門範囲で考える』システムの要件を決める。
「システム要件定義書」の主な内容
- 開発の背景（課題）
- 目的（あるべき姿）
- 要求概要
- 対象範囲
- 制約条件
- システム機能要件と優先順位
- システムの実現手段
- システム化の範囲
- 概略費用
- 効果（定性／定量）
- 体制図
- 概略スケジュール
システム要件には、機能要件と非機能要件があります。
- 機能要件
ユーザからのニーズで明らかになった、システムに必要な機能。 - 非機能要件
ユーザからのニーズからはでてこないが、システムに必要な性能。「応答時間」や「セキュリティ性」など。
品質特性とは、ソフトウェアの品質を評価する基準です。
- 機能性：ニーズに合った機能の実装度合い
- 信頼性：正常に動作し続ける度合い
- 使用性：使いやすさの度合い
- 効率性：資源の効率利用の度合い
- 保守性：保守のしやすさ度合い
- 移植性：別環境への移行動作する度合い
＜重要＞
「システム要件定義書」が完成したら、開発者と発注者で書類の内容を確認し、お互いの認識が一致しているかをチェックします。この作業を「共同レビュー」といいます。
システム設計
システム要件定義をもとにシステム設計図を作成します。
- システム方式設計
システム要件を「ハードウェア」「ソフトウェア」「手作業」のどれかに振り分ける。- ハードウェア：サーバ、プリンタなど
- ソフトウェア：ソフトウェア名、バージョンなど
- 手作業：電話受付、在庫確認、データ入力など
- ソフトウェア要件定義
ソフトウェアの機能や性能を決める。- UI（ユーザー画面、印刷結果、ファイル出力など）
- データ（扱うデータ、データベース設計『論理モデル』など）
- ソフトウェア方式設計
ソフトウェア要件をプログラム単位まで分割する。 - ソフトウェア詳細設計
プログラム単位を「コーディングできる」まで分割する。具体的には、フローチャート（流れ図）などにして表す。
また、データベース設計『物理モデル』まで行う。
分割されたプログラムを「ソフトウェアユニット（ソフトウェア単体）」といいます。
プログラミング
ここまできて、やっとシステム開発として「プログラミング」となります。プログラミングとは、「プログラマー」がプログラム言語を使用し「処理手順」を記述します。
プログラミングを早く行いたいと気持ちは焦りますが、「システム設計（ソフトウェア詳細設計）の後」となります。
プログラミング重要用語
- ソースコード
人間が認識できるようにプログラム言語で記述されたプログラム - コンパイラ
ソースコードをコンピュータが認識できるように機械語に変換する機能 - 機械語
コンピュータが認識できる「0」と「1」で記述された言語
テスト
システムが仕様通りに動作するかを確認します。また、業務要件も満たしているかどうかも併せて確認します。不具合があった場合には、修正します。
重要用語
- バグ（プログラム不具合）
- デバッグ（不具合を修正する作業）
- レグレッションテスト（回帰テスト）
システム修正や機能追加したことで別のバグが発生していないかを検証
V字モデル
- 単体テスト
「開発者」がプログラミングに誤りが無いかを検証する。（※ホワイトボックステスト） - 結合テスト
「開発者」が単体テストで問題なかったプログラムを結合し、データや連携が動作するかを検証する。（※ブラックボックステスト） - システムテスト
「開発者」がシステム要件に沿ったものになっているかどうかを検証する。 - 運用テスト
「ユーザ」が本番環境と同じテスト環境で動作検証する。
ホワイトボックスとブラックボックス
- ホワイトボックステストとは？
プログラムの構造を追いかけながら分析確認するテストです。そのため、プログラムで記述されているすべての処理（分岐したもの含む）を動作検証する。但し、プログラマの誤解によるバグは見つけられない。 - ブラックボックステストとは？
プログラムでどのように記述されているのかは気にせず、「入力データ」を正しく加工し、「出力」されているかどうかの「結果」をみて検証する。
ソフトウェア受入れ
開発者が開発したソフトウェアを発注者に納品します。その際の「ソフトウェア導入」と「ソフトウェア受入れ支援」を行います。
また、納品物としてソフトウェアだけでなく、「利用者マニュアル」などを作成し、導入後の運用を円滑行えるように支援します。
- ソフトウェア導入
本番環境にソフトウェアを導入（インストール）します。新規導入のこともあれば、既存システムから「移行（切り替える）」こともあります。 - ソフトウェア受入れ支援
発注者が行う「ソフトウェア受入れテスト」に対して、開発者が支援します。発注者は、システムが契約内容通りに完成しているかどうかを確認するテストを「検収」とすることが多いです。ここで問題が無ければ「納品」完了となります。