プログラミングだけでなく、ソフトウェアの開発プロセスの全体像を勉強しようと思い調べたので学習用にメモ。
書籍などを参考に、一般的な開発のプロセスについてざっくりまとめます。開発プロセスはウォーターフォールモデルを参考にします。
不足する部分も多々あると思います。
参考文献：
・ずっと受けたかったソフトウェアエンジニアリングの新人研修
・SEの基本
・各種WEBサイト
目次：
開発方法
作業標準
開発プロセス
１、要求定義
２、要件定義
３、システム提案
４、設計
４−１、外部設計
４−２、内部設計
５、プログラミング
６、テスト
６−１、単体テスト
６−２、結合テスト
６−３、総合テスト
開発方法
ウォーターフォール型開発
最も一般的な開発手法。開発プロセスを一段階ずつ順番に終わらせていく。要件定義から始まり設計、プログラミング、テスト、運用と時系列に沿って一気通貫で進めていく。
メリット：
段階を追って開発を進めるので分かりやすい。
デメリット：
・テストで見つかった不具合が上流工程であるほど修正に手間がかかる。
・いずれかの工程が遅れると全体に影響する。
スパイラル型開発
設計と、各工程にて実際に動く見本を作り確認するプロトタイピングを繰り返しながら進めていく。
メリット：
各工程の完成度を高めながら進めることができる。
デメリット
・フィードバックごとに問題が出た場合、各工程で時間が掛かりやすい。
アジャイル型開発
変化する顧客の要望を取り入れながら、素早く開発するという目的のもと生み出された手法。
メンバー間でお互いどうコミュニケーションを取るかという所に重点が置かれている。
・プロセスやツールより、個人そのものや個人間の交流を重視せよ
・広範にわたる大量の文書作成より、きっちり動くソフトウェアの作成に注力せよ
・契約に関わる交渉より、顧客と強調することに重点をおけ
・無理に計画に従うより、目の前の変化へ柔軟に対応せよ。
引用：Agile Allianceのアジャイル宣言より
作業標準
開発を進めていく上で、様々なメンバーが携わり、また途中から参加する人もいるためニュアンスの違いなどによるトラブルを避けるべく標準的な開発手法を定めておくのが一般的。
例：
・用字と用語
・工程の名称
・作成文書と記述項目
・使用するチャート記法
・コーディング規約
・レビュー実施ガイドライン
・適用する設計手法
・適用するプログラミング言語
・適用する開発プロセス
・ユーザーインタフェースガイドライン
など
開発プロセス
１、要求定義
顧客が自分のやりたいこと、つまり「顧客の要求」を見定める工程。
顧客の「そもそも何がしたい？」をまずは把握する。
どんな業務があり、そこにどのような問題があり、どう解決したいのかという顧客の業務の要望をヒアリングし、整理して文書化する。まずは、問題点や課題を洗い出すということが目的なので、この段階ではまだ矛盾や重複、不足があってもOK。
機能要求
顧客の業務に必要な手順を実現するための機能。
在庫管理のためにこういう機能が欲しい、データの検索や登録、参照ができるなど実際に使用する機能のこと。
「やりたいことを実現する」機能。目に見える部分。
非機能要求
処理速度やセキュリティといったバックグラウンドで動く機能。顧客の業務自体に直接関係ないが、システムが備えるべき機能。範囲は広く「機能要求以外は全て非機能要求」。
２、要件定義
要求定義を基にして、顧客が開発企業の協力を得ながらシステム化すべき項目を整理する工程。
顧客の実現したいことに対し「やりたいことを実現する為に何をどう実装する？」を整理する。
この段階では、矛盾や重複、不足があってはならない。
ここで固まった内容を基に設計、開発を進めていく。
３、システム提案
顧客にシステム開発の全体像を説明するための「システム提案書」も作成する。
要求定義でヒアリングし、要件定義で実装内容を整理したのでシステム提案書としてまとめる。
これによりシステム化により解決したい問題、機能、構成、経済性メリット、稼働時期などをユーザーに理解してもらい、発注を決定してもらう。
４、設計
４-１外部設計
システムが持つべき機能や性能、構成などについての設計。
どういうレイアウトか、どういう項目をどう配置するか、操作方法など。
プログラミング手法などは含まれない。
外部設計書
システム提案書、開発計画書、要求定義署の内容を基に外部設計書を作成する。
業務フローの作成
↓
サブシステムへの分割
↓
画面レイアウトや帳票レイアウトの作成
↓
コード設計
↓
論理データ設計（ER図、CRUD図作成）
↓
システムインターフェース設計
↓
外部設計書として取りまとめる
↓
レビュー
４-２内部設計
外部設計書を基にプログラムの内部データを決定するなど、システムの具体的な実現方法を定義。データベース設計などが含まれる。機能設計や詳細設計と呼ぶこともある。
内部設計書
画面の詳細設計
↓
帳票の詳細設計
↓
外部インターフェースの詳細設計
↓
処理ロジックの詳細設計
↓
リクエスト処理の詳細設計
↓
メッセージの詳細設計
↓
物理データ設計
↓
内部設計書としてまとめる
↓
レビュー
5、プログラミング
内部設計書の内容に沿ってプログラミングを行う。
関数、受け取るデータの数や種類、呼び出し元へ返す処理結果などは全て内部設計書の内容を基にする。
6、テスト
６−１ 単体テスト
関数や手続きなど最小単位のプログラムを単体で動かし、内部設計書通りの動きをするか確認する。
準備：
テスト項目を作成し、それに対応するテストデータを定める。入力する値がAであればAがテストデータとなる。
ホワイトボックステスト
内部テストとしては、ホワイトボックステストを行う。これは、プログラムの内部（制御構造、ロジック）を確認しながら進めるテスト。機能というより、システムの整合性を確認する。開発者側視点。
ドライバとスタブ
本来は様々なプログラム同士連携して動くものであるが、単体テストでは１つの機能ごとにテストをするので仮のプログラムを用意してテストを行う。
テスト対象のプログラムを呼び出すためのプログラムをドライバ、呼び出し先として使うプログラムをスタブという。
６−２ 結合テスト
プログラムが外部設計書通りに動くか確認するテスト。単体テストが内部のロジックを見ていたのに対し、結合テストでは実際に動くかどうかの確認をする。ユーザー視点。
ブラックボックステスト
プログラムの内容がどうかは考慮せず、あくまで入力と出力の対応が正しいかを確認する。
６−３ 総合テスト
結合テストを通ったプログラムとハードウェア、ネットワークなどを連携させて動作を確認。本番環境でのテスト。