ソフトウェア開発プロセス

ソフトウェアエンジニアリングにおいて、ソフトウェア開発プロセスまたはソフトウェア開発ライフサイクル（SDLC ）は、ソフトウェア開発を計画および管理するプロセスです。通常、ソフトウェア開発作業をより小さな、並列または連続的なステップまたはサブプロセスに分割して、設計や製品管理を改善します。この方法論には、アプリケーションを開発または保守するためにプロジェクトチームによって作成および完了される特定の成果物と成果物の事前定義が含まれる場合があります。^[1]

現代の開発プロセスのほとんどは、漠然とアジャイルと説明できます。その他の方法論には、ウォーターフォール、プロトタイピング、反復的および増分的開発、スパイラル開発、ラピッド アプリケーション開発、エクストリーム プログラミングなどがあります。

ライフサイクル「モデル」は、方法論のカテゴリを表すより一般的な用語と見なされる場合があり、ソフトウェア開発「プロセス」は、特定の組織によって採用される特定のインスタンスです。^{[引用が必要]たとえば、多くの特定のソフトウェア開発プロセスは、スパイラル ライフサイクル モデルに適合します。この分野は、}システム開発ライフサイクルのサブセットと見なされることがよくあります。

ソフトウェア開発方法論のフレームワークは 1960 年代まで登場しませんでした。Elliott (2004) によると、システム開発ライフサイクルは、情報システムを構築するための最も古い形式化された方法論フレームワークであると考えられます。ソフトウェア開発ライフサイクルの主なアイデアは、「情報システムの開発を非常に慎重かつ構造化された方法論的に追求し、ライフサイクルの各段階 (アイデアの発案から最終システムの提供まで) を、適用されているフレームワークのコンテキスト内で厳格かつ連続的に実行することを要求する」ことです^[2]。1960 年代のこの方法論フレームワークの主な目標は、「大規模なビジネス コングロマリットの時代に、大規模で機能的なビジネス システムを開発すること」でした。情報システムの活動は、大量のデータ処理と数値計算ルーチンを中心に展開されました^{[2] 。}

要件の収集と分析: カスタム ソフトウェア開発プロセスの第 1 段階では、クライアントの要件と目的を理解します。この段階では通常、関係者と徹底的に話し合い、インタビューを実施して、ソフトウェアに必要な機能や機能、全体的な範囲を特定します。開発チームはクライアントと緊密に連携して、既存のシステムとワークフローを分析し、技術的な実現可能性を判断し、プロジェクトのマイルストーンを定義します。

計画と設計: 要件が理解されると、カスタム ソフトウェア開発チームは包括的なプロジェクト計画の作成に進みます。この計画では、タイムライン、リソース割り当て、成果物を含む開発ロードマップの概要を示します。ソフトウェアのアーキテクチャと設計もこのフェーズで確立されます。ユーザー インターフェイス (UI) とユーザー エクスペリエンス (UX) の設計要素は、ソフトウェアの使いやすさ、直感性、視覚的な魅力を保証するために考慮されます。

開発: 計画と設計が整ったら、開発チームはコーディング プロセスを開始します。このフェーズでは、ソフトウェア コードの作成、テスト、デバッグを行います。スクラムやカンバンなどのアジャイル手法は、柔軟性、コラボレーション、反復的な開発を促進するためによく採​​用されます。開発チームとクライアントの間で定期的にコミュニケーションをとることで、透明性が確保され、迅速なフィードバックと調整が可能になります。

テストと品質保証: ソフトウェアの信頼性、パフォーマンス、セキュリティを確保するために、厳格なテストと品質保証 (QA) プロセスが実行されます。ユニット テスト、統合テスト、システム テスト、ユーザー受け入れテストなどのさまざまなテスト手法を使用して、問題やバグを特定し、修正します。QA アクティビティの目的は、ソフトウェアを事前定義された要件に照らして検証し、意図したとおりに機能することを保証することです。

展開と実装: ソフトウェアがテスト段階を通過すると、展開と実装の準備が整います。開発チームは、クライアントによるソフトウェア環境の設定、必要に応じてデータの移行、システムの構成を支援します。スムーズな移行を保証し、ユーザーがソフトウェアの可能性を最大限に引き出せるように、ユーザー トレーニングとドキュメントも提供されます。

メンテナンスとサポート: ソフトウェアの導入後は、問題に対処し、パフォーマンスを向上させ、将来の機能強化を組み込むために、継続的なメンテナンスとサポートが重要になります。ソフトウェアを最新かつ安全な状態に保つために、定期的な更新、バグ修正、セキュリティ パッチがリリースされます。このフェーズでは、エンド ユーザーにテクニカル サポートを提供し、質問や懸念に対処することも含まれます。方法論、プロセス、フレームワークは、組織が日常業務で直接使用できる特定の規定手順から、組織が特定のプロジェクトまたはグループのニーズに合わせてカスタマイズされた一連のカスタム手順を生成するために使用する柔軟なフレームワークまで多岐にわたります。場合によっては、「スポンサー」または「メンテナンス」組織がプロセスを説明する公式のドキュメント セットを配布します。具体的な例は次のとおりです。

1970年代

• 1969年からの構造化プログラミング
• Cap Gemini SDMはPANDATAから出版され、最初の英語版は1974年に出版されました。SDMはSystem Development Methodologyの略です。

1980年代

• 1980年以降の構造化システム分析設計法（SSADM）
• 情報要求分析/ソフトシステム方法論

1990年代

• オブジェクト指向プログラミング（OOP）は1960年代初頭に開発され、1990年代半ばには主流のプログラミング手法となった。
• 1991年以来の迅速なアプリケーション開発（RAD）
• 動的システム開発手法（DSDM）、1994年以来
• スクラム、1995年以来
• チームソフトウェアプロセス、1998年以来
• Rational Unified Process (RUP)、1998年以来IBMによって保守されている
• エクストリームプログラミング、1999年以来

2000年代

• アジャイル統合プロセス(AUP) は 2005 年からScott Amblerによって維持されています。
• ディシプリンド アジャイル デリバリー(DAD) は AUP に取って代わります

2010年代

• スケールド アジャイル フレームワーク(SAFe)
• 大規模スクラム(LeSS)
• デブオプス

1994 年の DSDM 以来、RUP を除く上記のリストにある方法論はすべてアジャイル方法論となっていますが、多くの組織、特に政府は、アジャイル以前のプロセス (多くの場合ウォーターフォールまたは類似のもの) をまだ使用しています。ソフトウェア プロセスとソフトウェア品質は密接に関連しており、実際には予期しない側面や影響がいくつか観察されています。^[3]

これらの中で、オープンソースには別のソフトウェア開発プロセスが確立されています。これらのベストプラクティスや既知で確立されたプロセスを企業内で採用することをインナーソースと呼びます。

ソフトウェアのプロトタイピングとは、プロトタイプ、つまり開発中のソフトウェア プログラムの不完全なバージョンを作成することです。

基本原則は以下のとおりである: ^[1]

• プロトタイピングは、スタンドアロンの完全な開発方法論ではなく、完全な方法論（増分、スパイラル、またはラピッド アプリケーション開発 (RAD) など）のコンテキストで特定の機能を試すアプローチです。
• プロジェクトをより小さなセグメントに分割し、開発プロセス中に変更を容易にすることで、プロジェクト固有のリスクを軽減します。
• クライアントは開発プロセス全体に関与するため、最終的な実装がクライアントに受け入れられる可能性が高まります。
• 一部のプロトタイプは廃棄されることを前提に開発されますが、プロトタイプから実用的なシステムへと進化できる場合もあります。

間違った問題を解決することを避けるためには、基本的なビジネス問題に対する基本的な理解が必要ですが、これはすべてのソフトウェア方法論に当てはまります。

「アジャイル ソフトウェア開発」とは、反復的な開発に基づくソフトウェア開発フレームワークのグループを指します。このフレームワークでは、要件とソリューションが自己組織化された機能横断的なチーム間のコラボレーションを通じて進化します。この用語は、アジャイル宣言が策定された 2001 年に造られました。

アジャイル ソフトウェア開発では、反復的な開発を基本としていますが、従来のアプローチよりも軽量で人間中心の視点を推奨しています。アジャイル プロセスは基本的に反復と、ソフトウェア システムを継続的に改良して提供するために提供される継続的なフィードバックを組み込んでいます。

アジャイル モデルには、次のソフトウェア開発プロセスも含まれます。

• 動的システム開発手法(DSDM)
• カンバン
• スクラム
• リーンソフトウェア開発

継続的インテグレーションとは、開発者の作業コピーをすべて共有メインラインに1 日に数回マージする手法です。 ^[4] Grady Booch は1991 年の手法で初めて CI に名前を付けて提案しましたが、^[5]彼は 1 日に数回のインテグレーションを推奨していませんでした。エクストリーム プログラミング(XP) は CI の概念を採用し、1 日に 1 回以上、場合によっては 1 日に数十回もインテグレーションを行うことを推奨しました。

線形システム開発方法論と反復システム開発方法論を組み合わせるにはさまざまな方法が考えられますが、それぞれの主な目的は、プロジェクトをより小さなセグメントに分割し、開発プロセス中に変更を容易にすることで、プロジェクト固有のリスクを軽減することです。

漸進的開発には主に3つの種類がある: ^[1]

1. 一連のミニウォーターフォールが実行され、ウォーターフォールのすべてのフェーズがシステムの小さな部分に対して完了してから、次の増分に進むか、
2. システムの個々の増分を進化的にミニウォーターフォール開発する前に、全体的な要件が定義される。
3. 初期のソフトウェア コンセプト、要件分析、アーキテクチャとシステム コアの設計はウォーターフォールを通じて定義され、その後、段階的な実装が行われ、最終的に動作するシステムである最終バージョンがインストールされます。

迅速なアプリケーション開発(RAD) は、大量の事前計画の代わりに反復的な開発とプロトタイプの迅速な構築を優先するソフトウェア開発手法です。RAD を使用して開発されたソフトウェアの「計画」は、ソフトウェア自体の作成と交互に行われます。大規模な事前計画がないため、一般にソフトウェアの作成がはるかに速くなり、要件の変更が容易になります。

迅速な開発プロセスは、構造化された技術を使用して予備的なデータモデルとビジネスプロセスモデルを開発することから始まります。次の段階では、プロトタイピングを使用して要件が検証され、最終的にデータとプロセスモデルが改良されます。これらの段階は繰り返し行われ、さらに開発を進めると、「新しいシステムの構築に使用されるビジネス要件と技術設計ステートメントの組み合わせ」が作成されます。^[6]

この用語は、1991年にジェームズ・マーティンによって導入されたソフトウェア開発プロセスを説明するために初めて使用されました。ウィッテン（2003）によると、これはさまざまな構造化技術、特にデータ駆動型情報技術エンジニアリングとプロトタイピング技術を融合したもので、ソフトウェアシステム開発を加速させます。^[6]

迅速なアプリケーション開発の基本原則は以下のとおりです。^[1]

• 主な目的は、比較的低い投資コストで高品質のシステムを迅速に開発し、提供することです。
• プロジェクトをより小さなセグメントに分割し、開発プロセス中に変更を容易にすることで、プロジェクト固有のリスクを軽減します。
• 主に反復的なプロトタイピング（開発のどの段階でも）、積極的なユーザーの関与、およびコンピュータ化された開発ツールを通じて、高品質のシステムを迅速に作成することを目指します。これらのツールには、グラフィカル ユーザー インターフェイス(GUI) ビルダー、コンピュータ支援ソフトウェア エンジニアリング(CASE) ツール、データベース管理システム(DBMS)、第 4 世代プログラミング言語、コード ジェネレーター、およびオブジェクト指向技術が含まれます。
• 主な重点はビジネスニーズを満たすことであり、技術的またはエンジニアリングの卓越性はそれほど重要ではありません。
• プロジェクト管理には、開発の優先順位付けと納期または「タイムボックス」の定義が含まれます。プロジェクトが遅れ始めた場合、納期を延ばすことではなく、タイムボックスに収まるように要件を減らすことに重点が置かれます。
• 一般的には、共同アプリケーション設計(JAD)が含まれます。ここでは、構造化されたワークショップまたは電子的に促進された対話による合意形成を通じて、ユーザーがシステム設計に積極的に関与します。
• ユーザーの積極的な関与が不可欠です。
• 使い捨てのプロトタイプではなく、反復的に製品ソフトウェアを作成します。
• 将来の開発と保守を容易にするために必要なドキュメントを作成します。
• 標準的なシステム分析および設計方法をこのフレームワークに適合させることができます。

ウォーターフォール モデルは、開発がいくつかのフェーズを経て (滝のように) 着実に下向きに流れると考えられる、順次的な開発アプローチです。通常、次のようになります。

• 要件分析によるソフトウェア要件仕様の作成
• ソフトウェア設計
• 実装
• テスト
• 複数のサブシステムがある場合の統合
• 展開（またはインストール）
• メンテナンス

この手法の最初の正式な説明は、 1970年にウィンストン・W・ロイス^[7]が発表した論文としてよく引用されるが、ロイスはこの論文で「ウォーターフォール」という用語は使用していない。ロイスは、このモデルを欠陥のある非機能的なモデルの例として提示した。^[8]

基本原則は以下のとおりである: ^[1]

• プロジェクトは連続したフェーズに分かれており、フェーズ間では多少の重複やスプラッシュバックが許容されます。
• 計画、スケジュール、目標日、予算、およびシステム全体の一括実装に重点が置かれます。
• ほとんどのフェーズの最後に次のフェーズを開始する前に、広範な文書化、正式なレビュー、ユーザーと情報技術管理者による承認/サインオフが行われ、プロジェクトの全期間にわたって厳重な管理が維持されます。文書化は、各フェーズの明確な成果物です。

ウォーターフォール モデルは、ソフトウェア エンジニアリングに適用される従来のエンジニアリング手法です。厳格なウォーターフォール手法では、以前のフェーズが完了したら、そのフェーズを再度検討したり修正したりすることは推奨されません。^{[誰によると? ]}純粋なウォーターフォール モデルのこの「柔軟性のなさ」は、他のより「柔軟な」モデルの支持者から批判の対象となっています。大規模な政府プロジェクトが予算を超過し、期間を超過し、大規模な設計を事前に行う手法が原因で要件を満たせないことがあったのは、このモデルのせいだと広く非難されています。^{[誰によると? ]}契約で義務付けられている場合を除き、ウォーターフォール モデルは、ソフトウェア開発専用に開発された、より柔軟で用途の広い方法論に大きく取って代わられました。^{[誰によると? ]}ウォーターフォール モデルの批判を参照してください。

1988 年、バリー・ボームは、ウォーターフォール モデルとラピッド プロトタイピング手法の重要な側面を組み合わせた、正式なソフトウェア システム開発「スパイラル モデル」を発表しました。これは、トップダウンとボトムアップの概念の利点を組み合わせる試みです。このモデルは、他の手法では軽視されてきたと多くの人が感じていた重要な領域、つまり、大規模で複雑なシステムに特に適した、意図的な反復リスク分析に重点を置いています。

基本原則は以下のとおりである: ^[1]

• 重点は、リスク評価と、プロジェクトをより小さなセグメントに分割して開発プロセス中の変更を容易にし、ライフサイクル全体にわたってリスクを評価し、プロジェクトの継続を検討する機会を提供することでプロジェクトのリスクを最小限に抑えることにあります。
• 「各サイクルでは、製品の各部分と各詳細化レベルについて、全体的な運用コンセプトの文書から個々のプログラムのコーディングに至るまで、同じ一連の手順を経る進行が含まれます。」^[9]
• スパイラルの各周回では、4つの基本的な象限を通過します。(1)反復の目的、代替案、制約を決定し、(2)代替案を評価し、リスクを特定して解決し、(3)反復からの成果物を開発して検証し、(4)次の反復を計画します。^[10]
• 各サイクルは、利害関係者とその「勝利条件」の特定から始まり、レビューとコミットメントで終了します。^[11]

Shape Upは、 Basecampが2018年に導入したソフトウェア開発アプローチです。これは、プロジェクトが明確な終わりのないまま長引くという問題を克服するためにBasecampが社内で開発した一連の原則と手法です。主なターゲットオーディエンスはリモートチームです。Shape Upには、ウォーターフォール、アジャイル、スクラムとは異なり、見積もりや速度の追跡、バックログ、スプリントはありません。代わりに、これらの概念はアペタイト、ベッティング、サイクルに置き換えられています。2022年現在、Basecampの他に、Shape Upを採用している著名な組織には、UserVoiceとBlockがあります。^{[12] [13]}

その他の高レベルのソフトウェア プロジェクト方法論には次のものがあります。

• 行動駆動開発とビジネスプロセス管理^[14]
• カオス モデル- 主なルールは常に最も重要な問題を最初に解決します。
• 増分資金調達方法論- 反復的なアプローチ
• 軽量方法論- ルールと実践が少数しかない方法の総称
• 構造化システム分析および設計手法- ウォーターフォールの特定のバージョン
• スロー プログラミングは、より大規模なスロー ムーブメントの一部であり、時間的なプレッシャーなしに (または最小限に抑えて) 慎重かつ段階的に作業を進めることに重点を置いています。スロー プログラミングの目的は、バグや過度に短いリリース スケジュールを回避することです。
• Vモデル（ソフトウェア開発） - ウォーターフォールモデルの拡張
• 統合プロセス(UP) は、統合モデリング言語(UML)に基づく反復的なソフトウェア開発方法論フレームワークです。UP は、ソフトウェア開発を 4 つのフェーズに編成します。各フェーズは、その開発段階におけるソフトウェアの 1 つ以上の実行可能な反復で構成されます。フェーズは、開始、詳細化、構築、ガイドラインです。

一部の「プロセス モデル」は、組織が採用した特定のプロセスを評価、比較、改善するための抽象的な記述です。

• ISO/IEC 12207は、ソフトウェアのライフサイクルを選択、実装、監視する方法を規定した国際規格です。
• 能力成熟度モデル統合( CMMI ) は、主要なモデルの 1 つであり、ベスト プラクティスに基づいています。独立した評価では、プロセスの品質や作成されたソフトウェアではなく、定義されたプロセスに組織がどの程度従っているかに基づいて評価されます。CMMI は CMM に代わるものです。
• ISO 9000 は、製品を製造するための正式に組織化されたプロセスの標準と、進捗状況を管理および監視する方法を規定しています。この標準はもともと製造業向けに作成されましたが、ISO 9000 標準はソフトウェア開発にも適用されています。CMMI と同様に、ISO 9000 の認証は最終結果の品質を保証するものではなく、正式なビジネス プロセスが遵守されていることのみを保証します。
• ISO/IEC 15504 情報技術 - プロセス評価は、ソフトウェア プロセス改善能力判定 (SPICE) とも呼ばれ、「ソフトウェア プロセスの評価のフレームワーク」です。この標準は、プロセス比較のための明確なモデルを設定することを目的としています。SPICE は、CMMI とよく似た方法で使用されます。ソフトウェア開発を管理、制御、ガイド、監視するためのプロセスをモデル化します。このモデルは、開発組織またはプロジェクト チームがソフトウェア開発中に実際に行っていることを測定するために使用されます。この情報は、弱点を特定して改善を促進するために分析されます。また、その組織またはチームの一般的な実践に継続または統合できる強みも特定します。
• ISO/IEC 24744 ソフトウェア エンジニアリング - 開発方法論のメタモデルは、ソフトウェア開発方法論のためのパワー タイプ ベースのメタモデルです。
• ソフト システム方法論- 管理プロセスを改善するための一般的な方法。
• メソッド エンジニアリング- 情報システム プロセスを改善するための一般的な方法。

こうしたフレームワークは長年にわたって多種多様化しており、それぞれに長所と短所が認められています。1 つのソフトウェア開発方法論フレームワークが、すべてのプロジェクトに適しているとは限りません。利用可能な方法論フレームワークはそれぞれ、さまざまな技術、組織、プロジェクト、チームの考慮事項に基づいて、特定の種類のプロジェクトに最適です。^[1]

• システム開発ライフサイクル
• コンピュータ支援ソフトウェアエンジニアリング（これらのツールの一部は特定の方法論をサポートしています）
• ソフトウェア開発哲学のリスト
• ソフトウェア工学の概要
• ソフトウェアプロジェクト管理
• ソフトウェア開発
• ソフトウェア開発の労力見積もり
• ソフトウェアリリースライフサイクル
• トップダウンとボトムアップの設計#コンピュータサイエンス

ウィキメディア・コモンズには、ソフトウェア開発方法論に関連するメディアがあります。

• cms.hhs.gov で開発アプローチを選択します。
• ゲルハルト・フィッシャー、「21 世紀のソフトウェア技術: ソフトウェアの再利用から共同ソフトウェア設計まで」、2001 年