Loading article…
ソフトウェア開発プロセスとは、ソフトウェアを開発する ための手順を規定するものです。通常、全体的な作業を、高品質な結果を保証することを目的としたより小さなステップまたはサブプロセスに分割します。プロセスでは、作成および完了すべき具体的な成果物（アーティファクト）を記述する場合があります。 [ 1 ]
厳密にはこれに限定されるわけではありませんが、ソフトウェア開発プロセスとは、ソフトウェアシステムの開発を最初から最後まで管理する高レベルのプロセス（方法論、モデル、フレームワークなど）を指すことがよくあります。システム開発ライフサイクル（SDLC）は、ソフトウェアシステムを含むシステムの開発作業が最初から最後まで経る典型的なフェーズを記述します。方法論は、エンジニアがシステムをライフサイクルに沿って進めるためにどのように作業を進めるかを規定します。方法論は、SDLCのために考案されたプロセスの分類、またはプロセスの設計図です。たとえば、多くのプロセスはスパイラルモデルとして分類できます。
SDLCは方法論の定義を決定づけるものであり、方法論はSDLCの各フェーズに対応しなければならない。一般的に、方法論は、コンピュータシステムが複雑で異種コンポーネントを統合する場合でも、期待（要件）を満たすかそれを上回る高品質のシステムを、予算内で期日通りに納品することを目的として設計されている。[ 3 ]ウォーターフォール、スパイラル、アジャイル、ラピッドプロトタイピング、インクリメンタル、同期と安定化など、さまざまな方法論が考案されている。 [ 4 ]
方法論間の大きな違いは、フェーズがシーケンシャルかイテレーションかという点です。XPやスクラムなどのアジャイル方法論は、迅速な変更を可能にする軽量プロセスに重点を置いています。[ 5 ] Rational Unified Processやダイナミック システム開発方法などのイテレーション方法論は、プロジェクト スコープの安定化と製品の反復的な拡張または改善に重点を置いています。ウォーターフォールなどのシーケンシャルまたはビッグ デザイン アップ フロント (BDUF) モデルは、大規模プロジェクトをガイドし、成功と予測可能な結果のリスクを制限するために、完全かつ正確な計画に重点を置いています。[ 6 ]アナモルフィック開発は、プロジェクト スコープと適応的なイテレーションによってガイドされます。スクラムでは、たとえば、単一のユーザー ストーリーが 2 週間のスプリント内で SDLC のすべてのフェーズを通過すると言えます。対照的に、ウォーターフォール方法論では、すべてのビジネス要件が機能/機能記述に変換され、通常数か月以上かけてすべて実装されます。[ 8 ]
プロジェクトには、異なる活動を記述するプロジェクトライフサイクル（PLC）とSDLCの両方が含まれる場合があります。テイラー（2004）によると、「プロジェクトライフサイクルはプロジェクトのすべての活動を網羅する一方、システム開発ライフサイクルは製品要件の実現に焦点を当てています」。[ 9 ]
SDLCという用語は、 SDLC手法の略称としてよく用いられます。また、SDLCや従来型SDLCという言葉を、ウォーターフォール型開発手法を指す言葉として使う場合もあります。
エリオット（2004）によれば、SDLCは「1960年代に、大規模なビジネスコングロマリットの時代に、大規模な機能的なビジネスシステムを開発するために誕生した。情報システムの活動は、大量のデータ処理と数値計算ルーチンを中心に展開していた」[ 10 ] 。構造化システム分析設計手法（SSADM）は、1980年代に英国政府の商務庁向けに作成された。それ以来、エリオット（2004）によれば、「システム開発に対する従来のライフサイクルアプローチは、従来のSDLCの固有の欠点のいくつかを克服しようとする代替アプローチとフレームワークにますます置き換えられてきた」[ 10 ]。SDLCの主な考え方は、「適用されるフレームワークのコンテキスト内で、アイデアの着想から最終システムの納品まで、ライフサイクルの各段階を厳格かつ順次実行することを要求する、非常に意図的で構造化された体系的な方法で情報システムの開発を追求すること」[ 10 ]である。
その後、他の手法が考案された。
1994年のDSDM以降、RUPを除く上記のリストにある手法はすべてアジャイル手法であるが、多くの組織、特に政府機関は依然としてアジャイル以前のプロセス（ウォーターフォール型など）を使用している。
以下は、人気順に並べた注目すべき手法である。
アジャイルソフトウェア開発とは、反復的な開発に基づいたフレームワーク群を指し、要件とソリューションは、自己組織化された異分野横断型チーム間の協働を通じて進化していく。この用語は、アジャイルマニフェストが策定された2001年に初めて用いられた。
ウォーターフォールモデルは、開発がSDLC（ソフトウェア開発ライフサイクル）の各フェーズを（滝のように）一方向に流れる、逐次的な開発アプローチです。
1988年、バリー・ボームは、トップダウンとボトムアップの概念の利点を組み合わせることを目的として、ウォーターフォールモデルとラピッドプロトタイピングの主要な側面を組み合わせたソフトウェアシステム開発スパイラルモデルを発表しました。このモデルは、他の手法では見過ごされてきたと多くの人が感じていた重要な領域、すなわち、特に大規模で複雑なシステムに適した、意図的な反復リスク分析を重視しています。
さまざまな手法が線形手法と反復手法を組み合わせており、主な目的はプロジェクトをより小さなセグメントに分割し、開発プロセス中に変更を容易にすることで、プロジェクト固有のリスクを低減することです。[ 11 ]
ソフトウェアプロトタイピングとは、開発中のソフトウェアプログラムのプロトタイプ、つまり不完全なバージョンを作成することである。
ラピッドアプリケーション開発（RAD）は、事前の綿密な計画よりも、反復的な開発とプロトタイプの迅速な構築を重視する開発手法です。RADを用いたソフトウェア開発では、「計画」とソフトウェア自体の記述が交互に行われます。事前の綿密な計画が不要なため、ソフトウェア開発がはるかに迅速に行え、要件変更も容易になります。
Shape Up は、 Basecampが 2018 年に導入したソフトウェア開発手法です。これは、プロジェクトが明確な終わりなく長引くという問題を克服するために Basecamp が社内で開発した一連の原則とテクニックです。主な対象はリモート チームです。Shape Up は、ウォーターフォール、アジャイル、スクラムとは異なり、見積もりや速度追跡、バックログ、スプリントがありません。代わりに、これらの概念はアペタイト、ベッティング、サイクルに置き換えられます。2022 年現在、Basecamp の他に、Shape Up を採用している著名な組織には UserVoice や Block などがあります。[ 12 ] [ 13 ]
カオスモデルには、常に最も重要な問題を最初に解決するという、一つの主要なルールがある。
段階的資金調達手法― 反復的なアプローチ。
軽量手法― ルールや手順が少ない手法全般を指す用語。
構造化システム分析設計手法― ウォーターフォールモデルの特定バージョン。
スロープログラミングは、より広範なスロームーブメントの一環として、時間的プレッシャーをほとんど（あるいは全く）かけずに、慎重かつ段階的に作業を進めることを重視します。スロープログラミングの目的は、バグの発生や過度に短いリリーススケジュールを回避することです。
Vモデル（ソフトウェア開発） - ウォーターフォールモデルの拡張版。
統一プロセス（UP）は、統一モデリング言語（UML）に基づいた反復型ソフトウェア開発手法フレームワークです。UPはソフトウェア開発を4つのフェーズに分け、各フェーズはその開発段階における1つ以上の実行可能なソフトウェア反復から構成されます。フェーズは、構想、詳細化、構築、ガイドライン作成です。
ウォーターフォールモデルは、SDLCの各フェーズが前のフェーズの結果に基づいて構築されるように記述しています。[ 14 ] [ 15 ] [ 16 ] [ 17 ]すべてのプロジェクトでフェーズが順次実行される必要はありません。比較的単純なプロジェクトでは、フェーズが結合または重複する場合があります。[ 14 ]ウォーターフォール以外の方法論については、以下で説明および比較します。[ 18 ]
プロセスモデルの中には、組織が採用している特定のプロセスを評価、比較、改善するための抽象的な記述であるものもある。
ISO/IEC 12207は、ソフトウェアのライフサイクルを選択、実装、監視する方法を規定した国際規格です。
能力成熟度モデル統合（CMMI）は、主要なモデルの一つであり、ベストプラクティスに基づいています。独立した評価では、組織が定義されたプロセスをどれだけ適切に遵守しているかに基づいて評価され、プロセスの品質や作成されたソフトウェアの品質に基づいて評価されるわけではありません。CMMIはCMMに取って代わりました。
ISO 9000は、製品製造のための正式に組織化されたプロセスと、その進捗状況を管理・監視する方法に関する規格です。この規格は元々製造業向けに作成されましたが、ソフトウェア開発にも適用されています。CMMIと同様に、ISO 9000認証は最終製品の品質を保証するものではなく、正式に定められた業務プロセスが遵守されたことを保証するものです。
ISO/IEC 15504情報技術－プロセス評価、別名ソフトウェアプロセス改善能力判定（SPICE）は、ソフトウェアプロセスを評価するためのフレームワークです。この規格は、プロセス比較のための明確なモデルを定めることを目的としています。SPICEはCMMIとよく似た方法で使用されます。ソフトウェア開発を管理、制御、誘導、監視するためのプロセスをモデル化します。このモデルは、開発組織またはプロジェクトチームがソフトウェア開発中に実際に行っていることを測定するために使用されます。この情報は分析され、弱点を特定して改善を推進します。また、組織またはチームの一般的な慣行として継続または統合できる強みも特定します。
ISO/IEC 24744 「ソフトウェアエンジニアリング－開発手法のメタモデル」は、ソフトウェア開発手法のためのパワータイプベースのメタモデルです。
ソフトシステム手法は、経営プロセスを改善するための一般的な手法である。
メソッドエンジニアリングとは、情報システムプロセスを改善するための一般的な手法である。