【初心者向け】ソフトウェア開発工程の全体像をつかみたい

【※ 当記事は2020年7月2日時点の情報です】

ペイヴメント（@pavement1234）です。

プログラマーになったら
最初にソフトウェア開発工程の全体像をざっくり掴んでおくことをオススメします。
とはいえ、いきなり細かく説明されても混乱しちゃうしなぁ…という感じかもしれず。
細かくなり過ぎないように注意しながら解説します。

ソフトウェア開発の全体像

いわゆるV字開発と呼ばれるソフトウェア開発プロセスの図を書いてみました。
ソフトウェア開発プロセスの用語には方言があるので
現場の呼び方に合わせて頂ければと思いますが、
基本はこんな感じだと思います。

それぞれの作業工程（箱）をフェーズと呼び、
①から始まり、青矢印の通り②、③、④、⑤、⑥、⑦、⑧と順番に進み、
⑨が終わるとリリース（出荷）になります。

各フェーズの成果物が完成したらレビュー（評価）をします。
レビューは対面で行うこともありますし、書面で済ませるケースもあります。
レビューを怠ると不具合が残ったまま次のフェーズに進んでしまいますので、
注意が必要です
（後工程で不具合が見つかると後戻りにより無駄が発生しますし、
出荷までに不具合が見つからないとリコールになるケースも…）。

仕様・設計が正しくプログラムに反映されているかを確認するため試験をします。
どの仕様・設計がどのフェーズで試験されるかを緑矢印で示しました。
例えば、②要件定義に対する試験は⑧システム試験で行われます。

開発を川の流れに見立て、
①②（③までと言う人もいる）を上流工程（Upstream）、
③以降を下流行程（Downstream）と呼んだりします。
SE（システムエンジニア）が上流工程を担当し、
PG（プログラマー）とテスターが下流行程を担当するのが普通です。

開発における重要な３要素はQCDです。
Q（品質：Quality）、
C（コスト：Cost）、
D（納期：Delivery）の頭文字を取っています。
QCDの各項目はトレードオフの関係にあります。
たとえば、Q（品質）を高めようとすると試験を沢山しなければならず
C（コスト）増大や、D（納期）遅れを招きます。

PM（プロジェクトマネージャー）がプロジェクト全体のQCDに責任を持ち、
PL（プロジェクトリーダー）がサブチーム
（例えばソフトウェアのある機能ブロック）のQCDに責任を持ちます。
難易度が高いシステムを構築するときにシステムアーキテクトをアサインして、
Q（品質）に責任を持たせるケースもあります
（PM、PL、システムアーキテクトも現場によって方言があります）。

余談ですが、
現場によってはフェーズを英語で呼ぶケースもあります。

全体像の説明はこのぐらいにしておきます。

各フェーズで具体的に何をするの？（ざっくり説明）

①要求分析

SE（システムエンジニア）やアナリストが顧客の要求を分析して、
ソフトウェア要求仕様書を作成します。
要求はRequirement（リクワイアメント）と呼ぶこともあります。
要求は顧客にインタビューしたり、プロトタイプを触ってもらったりして抽出します。
ここがズレると元も子もありません。

②要件定義

ソフトウェア要求仕様書をインプットとして、
SE（システムエンジニア）やアーキテクトが
機能要件と非機能要件（性能など）を明確にし、ソフトウェア要件定義書を作成します。
ソフトウェア要求仕様書とは別に、
ハードウェア制約やシステムアーキテクチャ設計書を作成することもあります。

③基本設計

ソフトウェア要件定義書をインプットとして、
開発メンバーが機能ブロック（コンポーネント）の振る舞いや、
外部インタフェース関数の入出力などを定義したソフトウェア基本設計書を作成します。
外部設計と呼ぶこともあります
機能ブロック同士の相互連携方法を説明する感じです。

機能ブロック同士がどのように相互連携するかと言うと、
外部インタフェース関数を相互に呼び合う、
メッセージ通信機構（Message Queue、Event Flagなど）を介して連携する、
という２つのパターンが多いと思います。
ここがシステムの要になりますので、
変てこりんな設計にすると性能が出なかったり、
機能が満たせなくなったりするので注意が必要です（センスが問われます）。

④詳細設計

ソフトウェア基本設計書をインプットとして、
開発メンバーが全ての関数インタフェースや、
内部処理を定義したソフトウェア詳細設計書を作成します。
内部設計と呼ぶこともあります。
関数一覧と関数の内部処理を説明する感じです。

コーディングできるレベルまでソフトウェア詳細設計書を記載できれば良いのですが、
どうしても時間が取れない場合、
Doxygenと呼ばれるツールでソースコードから関数一覧を自動生成し、
詳細設計書の代わりにする事例を見かけたことがあります。
しかしコーディングが間違っているかの検証ができないのであまりお勧めはしません。

⑤コーディング

ソフトウェア詳細設計書をインプットとして、
コーディング（プログラミング）します
プログラムをソースコードと呼んだりもします。
出来上がったプログラムは、
デバッガ（プログラムをステップ実行したり、ブレークポイントを張って処理の途中でとめたりするツール）で動作確認し、
明らかなコーディングミスが見つかったらプログラム修正します。

ここであまりにも不具合が多いようですと、
基本設計、詳細設計のどちらかに問題があるかもしれないので、
見直してみると良いです。

⑥単体試験

ソフトウェア詳細設計書、ソースコードをインプットとして、
ソフトウェア単体試験仕様書を作成します。
単体試験は関数単位で試験しますが、
カバレッジと呼ばれる条件網羅の度合いを示す指標があり、
命令網羅（C0：Statement Coverage）、
分岐網羅（C1：Branch Coverage）、
条件網羅（C2：Condition Coverage）のうち
どのレベルで試験をするかを決めなければなりません。
結合試験はホワイトボックス試験です。

ソフトウェア単体試験仕様書に試験結果を記入して
ソフトウェア単体試験結果報告書を作成します。
作業量はC0が一番少なく、C2が一番多いです（C0＜C1＜C2）。
商用プログラム開発であれば、
カバレッジマスター、C++Testあたりの単体試験自動化ツールをつかって、
ソフトウェア単体試験仕様書のレポート化や
リグレッション試験（回帰試験）の工数を削減します。

⑦結合試験

ソフトウェア基本設計書、ソースコードをインプットとして、
ソフトウェア結合試験仕様書を作成します。
結合試験はコンポーネント単位で試験しますが、
スタブ（下位モジュールのダミー）、
ドライバー（上位モジュールのダミー）を駆使して、
正常系だけでなく異常系（エラー発生時の挙動）も試験できるようにします。

ソフトウェア結合試験仕様書に試験結果を記入して
ソフトウェア結合試験結果報告書を作成します。

⑧システム試験

ソフトウェア要件定義書をインプットとして、
ソフトウェアシステム試験仕様書を作成します。
システム試験はブラックボックス試験です。
機能要件と非機能要件（性能）を確認します。
ロングラン試験（たとえば1週間連続動作させても不具合が起こらないことを確認）や
ハイローディング試験（高負荷状態で誤動作しないことを確認）なども
システム試験の範疇です。

ソフトウェアシステム試験仕様書に試験結果を記入して
ソフトウェアシステム試験結果報告書を作成します。

⑨受入試験

ソフトウェア要求仕様書をインプットとして、
受け入れ試験仕様書を作成します。
受入試験は、別名出荷試験とも呼ばれます。
要求通りに動作しているかの確認ですので、試験項目は少ないと思います。
出荷試験を実施することでリリースミスを防ぐことができます。

受け入れ試験仕様書に試験結果を記入して
受け入れ試験結果報告書を作成します。

まとめ

ソフトウェア開発の全体像について雰囲気を掴んで頂けましたでしょうか？
どのフェーズも突き詰めると奥深く面白いので、
当ブログの詳細記事や
参考書籍（情報処理試験の教科書はよくまとまっている）などを参考に、
実際の開発現場でソフトウェアエンジニアとしての経験を積んで頂ければと思います。