ソフトウェアを開発する手法がソフトウェア開発プロセスです。 システム開発プロセス、開発工程などとも呼ばれます。
ソフトウェア開発プロセスの目的
ソフトウェアを安定した品質で開発するために、多くの知見から生み出されたのがソフトウェア開発プロセスです。 つまり、安定した品質のソフトウェアを開発するために必要な考え方になります。
ソフトウェア開発者なら当たり前に実施していることではあると思いますが、意外と正しく実行できていないものです。 なぜかバグが多いなとか、品質が安定しないなと感じた場合は、実施しているプロセスを見直してみましょう。
V字モデル
ソフトウェア開発のプロセスはV字モデルで表現されます。 プロセスは手法であり、適用するプロジェクトによって呼び方や内容が変わるのですが、だいたいは以下の構造をしています。
矢印は進む方向です。 アジャイル開発の場合もユーザーストーリーごとにこれらのステップを踏むだけで、基本は同じです。 左側については部分的に次工程以降の作業も並行で実施することも多いでしょう。
V字モデルの優れている点は、設計工程とテスト工程が対になっていて、それぞれの工程の完了基準が明確になっている点です。 左側の各工程を完了する際に、右側のテストが可能になっている必要がありますし、 右側のテスト工程の完了には、左側の設計をすべてテストしてパスする必要があります。
余談：V&V
検証と妥当確認（Verification & Validation）と呼ばれている、品質保証の考え方です。 V字モデルが２つ重なって、W字のように示されることもあります。 ただ、W字モデルとは呼びません。 インターネットにはW字モデルの解説記事が散見されますが、本来のV&Vとは違う説明がされていますし、それぞれの記事の出典も不明なので、それらの情報を参照しないほうがよいでしょう。
検証と妥当性確認の違いは、IEEE Std 1012に則ると以下の通りです。
- 検証（Verification）：開発工程の成果物がその工程の開始時に与えられた条件を満たしているか
- 妥当性確認（Validation）：利用者のニーズや意図された利用法などの要求事項を満たしているか
簡単に言うと、前工程の仕様通りにつくっているか確認するのが「検証」で、最上位の要求を満たすようにつくっているかを確認するのが「妥当性確認」と言えるでしょう。 レビューやテストでは、分かりやすい「検証」の観点のみ確認されることが多いですが、「妥当性確認」も考慮できると品質が向上します。
ウォーターフォール開発とアジャイル開発
現在主流なソフトウェア開発プロセスの種類には、ウォーターフォール開発とアジャイル開発の２つがあります。 ただ、一般的に言われるような単純な違いではないので、簡単に紹介しておきます。
ウォーターフォール開発
1976年の論文で初めてウォーターフォールの単語が出てきたということですが、その起源ははっきりしないようです。 1970年のWinston Royce博士の論文に似た図があるため、博士が提唱者であるといわれることもありますが、論文の内容はウォーターフォール開発での失敗をなくす方法を述べたものであり、単純なウォーターフォール開発をすべきというものではありません。
博士が提唱している方法は以下の５つです。
- プログラム設計を先に行う
- 設計ドキュメントを重視する
- 2回開発する
- テストを重視する
- 顧客を巻き込む
特に、1.と3.については、一般的には知られていないことなのではないかと思います。 ただし、優れた開発者であれば、経験的に知り、実施していることかと思います。
起源はともかく、ウォーターフォール開発は決められたQCDを達成する手法ということが言えそうです。 QCDを変えずに開発をするのがウォーターフォール開発という理解でまずはよいかと思います。 一般的なプロジェクトではまず予算が決まり、それに基づいてQCDを決めますので、ウォーターフォール開発になることが多いでしょう。
- [1] Winston Royce「MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS」 - http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf
アジャイル開発
アジャイル開発とは、アジャイルソフトウェア開発宣言とアジャイル ソフトウェアの 12 の原則に則った開発のことです。 元々は、エクストリーム・プログラミング、スクラムといった先進的なプラクティスをまとめるためのコンセプト、文化の定義として始まりました。
一般的に言われている単純なウォーターフォール開発との差異だけでなく、概念的なトピックを多く含みます。 詳しくは、以下のようなガイドを参照するとよいと思います。
アジャイル開発では必ずしもプロジェクト開始時に決めたQCDを是としません。 QCDすべてを変化させることのできる開発がアジャイル開発と言えるのではないかと思います。 そういった意味で、受託開発でアジャイル開発を実施するのはかなりハードルが高いものになります。 その場合、業務委託として実施する場合が多いのではないかと思います。
- [1] アジャイルソフトウェア開発宣言 - https://agilemanifesto.org/iso/ja/manifesto.html
- [2] アジャイル ソフトウェアの 12 の原則 - https://agilemanifesto.org/principles.html
各工程の説明
V字モデルの各工程の内容を簡単に説明します。
要求分析
To-Beの業務の構想と実現するシステムの構想を行ないます。 通常、プロジェクトが開始する前に実施する作業なので、工程を明確に意識することはないかもしれません。 投資対効果を判断するフェーズで、超上流工程とも呼ばれます。 要件定義を一部実施する場合も多いです。 RFP・提案書・業務フロー・見積・プロジェクト計画書などがアウトプットになります。
要件定義
機能要件・非機能要件を定義します。 主に受託開発の場合に発生する工程で、自社開発の場合では要求分析と基本設計に統合されていることもあります。
要件定義はプロジェクト開始前に実施できるのが理想ですが、要件を決定するというかなり重たい作業なので、準委任契約で実施したり、プロジェクト開始後に実施することになる場合も多いです。 要件を達成するためのシステム設計・検証も行います。 この工程から基本設計・詳細設計との境界があいまいになりがちです。 境界をどう見極めるかは、正直、経験に大きく左右されると思います。 要件定義書などががアウトプットになります。
基本設計
機能仕様やシステムの振る舞いや構造を定義します。 機能仕様書・画面定義書・I/F仕様書などががアウトプットになります。 この工程でシステムをどう定義するかが品質に大きく影響します。 UML等を用いてコミュニケーションの不備が発生しないように設計を進めていく必要があります。
詳細設計
昔は関数仕様書などを作成したりしましたが、仕様書の自動生成・自動テストに統合されたりして、最近はこの工程を実施することは少なくなったかもしれません。 詳細設計仕様書などがアウトプットになります。
実装
ソースコードを書く作業です。 テストコードを書いたり、デバッグをする作業も含まれます。
単体テスト
詳細設計で定義した仕様をテストします。 テストのコード化によって、詳細設計・実装・単体テストまでを一連の工程として実施することも多くなりました。 ユニットテストとも呼ばれます。 また、サブシステム化やモジュール化されている場合は、それぞれのサブシステム・モジュールのテストをすることを単体テストと呼ぶこともあります。
結合テスト
基本設計で定義した仕様をテストします。 機能テスト、統合テストとも呼ばれます。 この段階までは開発環境でテストします。
システムテスト
要件定義で定義した仕様をテストします。 総合テストとも呼ばれます。 ユースケースに沿ったシナリオのテストなどを実施します。 運用テストを含む場合もあります。 通常、ステージング環境でテストします。
受入テスト
要求分析で構想した内容をテストします。 UAT（User Acceptance Test）、運用テストとも呼ばれます。 受入というと、請負開発における検収としての意味合いが強くなりますが、そもそもの目的を達成できているかを確認する大事な工程です。 本番環境やステージング環境でテストします。
