ソフトウェア開発の流れ　どのような工程があり、何をしていくのか？

2020年7月21日2023年2月7日

ソフトウェア開発プロジェクトの進行

ソフトウェア開発はさまざまな作業工程を経て完了します。
その作業工程を、システム開発ライフサイクル（Systems development life cycle、以下SDLCと略記）のウォーターフォールモデル（予想型モデル）では、プロダクトは「要件定義」「設計」「開発」「テスト」という一連の流れでできているとしています。
こうしたソフトウェア開発の大きな流れについてはどのような開発者も会社も共通した認識として持っていますが、実際にどのような作業をするのか、またその作業の呼称については以下の表のように一様ではありません^[1]飯村結香子 (著)、大森 久美子 (著)、西原 琢夫 (著)、川添 雄彦 (監修)『ずっと受けたかったソフトウェアエンジニアリングの新人研修 第3版 … Continue reading。

このように、ソフトウェア開発の各作業には様々な呼称がありますが、今回は上記表中のAパターンの表記を使用しながら、各工程でどのような作業をするのかを解説していきます。

要件定義

要件定義とは、ソフトウェア開発の最終成果物であるアプリケーションについての要求分析です。
要件定義を行うためのインプットは顧客からの要求事項であり、その成果物は要件定義書になります。
要件定義の位置づけは開発のスタートラインになります。何を開発するのか、何のために開発するのか、開発したアプリケーションにはどのような機能があるのか、などあらゆる視点でこれから行う開発を明確に定義します。
つまり要件定義とは開発を進める過程での道標、及びゴール設定になるものです。

外部設計

外部設計とは、ソフトウェアの外部から見える部分の設計になります。
具体的には、画面仕様、機能仕様、入出力のデータフォーマット、他のソフトウェアとの接続仕様などが設計の対象です。
要件定義で検討された外部の振る舞いを実現するため、最適なソフトウェアの基本構造を組み立てることが最初の設計になります。
この設計作業の成果物である外部設計書は、詳細の仕様が記載されたドキュメントとなり、開発者でなくても理解できますので、アプリケーションの仕様として顧客の承認を得ることが重要です。

内部設計

内部設計とは、ソフトウェアの外部からは見えない部分の設計になります。
外部設計とは表裏一体の関係になるため、それぞれ独立した設計作業にはなりません。優先すべきは外部設計になりますが、その外部設計の実現性は内部設計を合わせて確認しなければなりません。
内部設計の手法としては、モジュール分割によって内部構造を組み立てることです。ソフトウェア全体を単機能のモジュールで構成することで、信頼性、保守性、移植性を高めることができます。
モジュール分割するときのポイントは「各モジュールの機能が明確であること」、また「各モジュールのインターフェース仕様がシンプルであること」になります。
次に、定義された各モジュールの内部を設計していきます。このような作業を詳細設計と呼ぶこともあります。
モジュールの入力、出力に着目して、その仕様を満たすためのロジックを設計し詳細設計書を作成します。コーディング作業の中の設計要素を少なくするために、詳細設計の中でエラー処理も設計しておきます。
通常の開発プロジェクトでは、モジュール単位で担当者をアサインすることが多く、各モジュールの設計が並行して行われることになります。その場合、モジュールのインターフェース部分の仕様を最初に確定することが必須条件になります。

開発

開発とは、作成した設計書からプログラミング言語によるソースコードを記述する作業（コーディング）を言います。
開発での重要な点としては以下のようなものが挙げられます。

• ロジックとデータを分離する
• 同じコードは関数化して共通ライブラリとする
• グローバル変数は最小限とする
• ひとつの関数を大きくしない

コーディングを行ってプログラムを組んでいく際に気を付けなければならないことは、ソースコードを処理するのはコンピュータですが、人が読む場面があるという点です。
コーディングした内容を検討するレビューではプロジェクト・メンバー、デバッグのときには自分自身、将来的な保守になると自分が知らない人ということもあります。
したがって、ソースコードを書く時には、その意味を表す関数名、変数名、加えて簡潔で分かりやすいコメントの記述も重要になります。

単体テスト

単体テストでは、コーディングしたプログラムに対して、内部設計のとおり動作するかのテストを行います。
テストの対象としては、モジュール、もしくはモジュールを構成するさらに小さな単位のプログラムになります。
テスト方法は、入力、出力に着目して、正しく処理されていることを確認します。
処理のロジックとしては、いくつかの条件分岐がありますので、それらを網羅するような入力値でテストを実施します。
一般的には、テストの中で単体テストが軽視されることが多いのですが、単体テストで発見すべき不具合をきちんと修正して次のテストへ進めることが、最終的な品質確保につながります。

結合テスト

結合テストでは、各モジュール間のインターフェース部分が正常に動作していることを確認しつつ、すべてのモジュールを結合していきます。
結合テストは外部設計の確認であり、それが完了したときにすべてのコードがアプリケーションの形で動作するようになります。
ソフトウェア開発における不具合は、モジュール間のインターフェース部分に多く見られます。それは、ソフトウェアのインターフェースであると共に、開発担当者同士のインターフェースであることが多いためです。
したがって、結合テストをスムースに進めるためには、単体テストで各モジュールの動作を確認しておくことはもちろんのこと、レビューなどで外部設計書の精度を高めておくことも重要です。
また、結合テストは機能テストという側面もあり、網羅性のあるテストケースを作成することが求められます。
テストケースに不足があり、さらに、その部分に不具合があった場合には、機能的な欠陥を持ったままアプリケーションをリリースすることになります。
また、アプリケーションの状態すべての組み合わせをテストすると、膨大なテスト工数になりますので、どこまでテストを行うかの方針を決めることが必要です。
また、大規模なアプリケーションを開発する場合には、統合テストで大量の不具合が発見されることもあります。
不具合の現象と発生頻度などから、その不具合修正の重要度を設定し、どこまで修正実施するかをプロジェクトで判断する必要があります。これは、アプリケーションに対して要求されている品質レベルも判断材料となります。

統合テスト

機能テストが完了したアプリケーションに対して、要件定義書を用いる統合テストにより、顧客からの要求を満たしているかの確認を行います。
一般的には、ユーザーの利用に問題ないかを確認するユースケーステスト、操作性を確認するユーザビリティテスト、パフォーマンスなどの性能テスト、大量のデータ処理を実行させる負荷テストが主なテスト項目となります。
要件定義書に記載されているすべての要件について確認ができたとき、アプリケーション開発が完了したことになります。
また、統合テストの中で顧客による受け入れテストを実施することにより、最終確認を行うこともあります。

リリース以後のプロダクト

以上、今回はプロダクトを開発するまでの流れを概観していきました。
アプリケーションが完成した後は、実際に組織内で使ってみたり、市場に送り出したりとリリース作業を行います。アプリケーションの形態により、顧客へ送付するだけでよいものから、テスト環境から本番環境へ払い出し作業が必要なものまでいろいろあります。
また、リリース作業の中でデータ移行を実施しなければならないケースもありますので、要件定義書の中でリリース要件として明確にしておきます。
また、リリース時の付帯作業として、アプリケーションのバージョン管理、リリースノートの作成、ソースファイル及び開発ドキュメントの整理を行います。
リリースされたプロダクトは、保守（メンテナンス）を行いながら使用され、一定の期間で継続して使用できるか否かの評価が行われます。
評価の結果、継続して使用すると問題があると判断された場合は、新しいソフトウェアと入れ替わる形で廃棄されていきます。