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

フリー百科事典ウィキペディアより
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェア エンジニアリングではソフトウェア開発プロセスは、設計製品管理を改善するために、ソフトウェア開発作業をより小さな、並行した、または順次のステップまたはサブプロセスに分割するプロセスですこれは、ソフトウェア開発ライフ サイクル( SDLC )としても知られています方法論には、アプリケーションを開発または維持するためにプロジェクト チームによって作成および完成される特定の成果物および成果物の事前定義が含まれる場合があります。[1]

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

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

歴史

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

方法論、プロセス、およびフレームワークは、組織が日常業務で直接使用できる特定の規範的な手順から、組織が特定のプロジェクトのニーズに合わせて調整された一連のカスタム手順を生成するために使用する柔軟なフレームワークにまで及びます。グループ。場合によっては、「スポンサー」または「保守」組織が、プロセスを説明する公式のドキュメント セットを配布します。具体例は次のとおりです。

1970年代
1980年代
1990年代
2000年代

2010年代

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

その中で、もうひとつのソフトウェア開発プロセスがオープンソースで確立されています。企業の範囲内で、これらの既知の確立されたプロセスのベスト プラクティスを採用することを、内部ソースと呼びます。

プロトタイピング

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

基本原則は次のとおりです。[1]

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

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

方法論

アジャイル開発

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

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

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

継続的インテグレーション

継続的インテグレーションとは、すべての開発者の作業コピーを共有メインラインに 1 日に数回マージする方法です。[5] Grady Boochは 1991 年のメソッドCI を初めて命名し、提案しました[6]が、彼は 1 日に数回統合することを提唱しませんでした。エクストリーム プログラミング(XP) は CI の概念を採用し、1 日に 1 回以上 (おそらく 1 日に数十回) 統合することを提唱しました。

インクリメンタル開発

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

インクリメンタル開発には、主に 3 つのバリエーションがあります。[1]

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

迅速なアプリケーション開発

迅速なアプリケーション開発 (RAD) モデル

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

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

この用語は、1991 年にJames Martinによって導入されたソフトウェア開発プロセスを説明するために最初に使用されました。Whitten (2003) によると、これはさまざまな構造化手法、特にデータ駆動型情報技術工学と、ソフトウェア システム開発を加速するためのプロトタイピング手法との融合です。 . [7]

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

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

滝の開発

ウォーターフォール モデルで表されるソフトウェア開発プロセスのアクティビティこのプロセスを表すモデルは他にもいくつかあります。

ウォーターフォール モデルは順次開発アプローチであり、開発はいくつかの段階を経て (滝のように) 着実に下向きに流れていると見なされます。通常は次のとおりです。

この方法の最初の正式な説明は、1970 年にWinston W. Royce [8]によって発行された記事としてよく引用されますが、Royce はこの記事で「ウォーターフォール」という用語を使用しませんでした。ロイスは、このモデルを、欠陥があり機能しないモデルの例として提示しました。[9]

基本原則は次のとおりです。[1]

  • プロジェクトは一連のフェーズに分割されており、フェーズ間のオーバーラップやスプラッシュ バックは許容されます。
  • システム全体の計画、スケジュール、目標日、予算、および実装に重点が置かれています。
  • 次のフェーズを開始する前に、大部分のフェーズの終わりに行われる広範な文書化、正式なレビュー、ユーザーによる承認/サインオフ、および情報技術管理により、プロジェクトの存続期間中、厳密な管理が維持されます。文書化されたドキュメントは、各フェーズの明示的な成果物です。

ウォーターフォール モデルは、ソフトウェア エンジニアリングに適用される従来のエンジニアリング アプローチです。厳密なウォーターフォール アプローチでは、前のフェーズが完了した後で再検討して修正することを思いとどまらせます。[誰によると?]純粋なウォーターフォール モデルにおけるこの「柔軟性のなさ」は、他のより「柔軟性のある」モデルの支持者による批判の原因となっています。ビッグ デザイン アップ フロントアプローチが原因で、いくつかの大規模な政府プロジェクトが予算や時間の経過とともに実行され、時には要件を満たしていないことで広く非難されてきました。[誰によると?]契約上必要な場合を除き、ウォーターフォール モデルは、ソフトウェア開発専用に開発されたより柔軟で用途の広い方法論に大きく取って代わられています。[誰によると?]ウォーターフォール モデルの批判を参照してください

スパイラル展開

スパイラルモデル (Boehm, 1988)

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

基本原則は次のとおりです。[1]

  • リスク評価と、プロジェクトをより小さなセグメントに分割し、開発プロセス中の変更をより容易にすることによってプロジェクトのリスクを最小限に抑えることに焦点を当てています。
  • 「各サイクルには、製品の各部分とその精緻化のレベルごとに、全体的な操作概念のドキュメントから個々のプログラムのコーディングまで、同じ一連のステップを経る進行が含まれます。」[10]
  • スパイラルを一周するたびに、次の 4 つの基本的な象限を通過します。(1) 反復の目的、代替案、および制約を決定し、(2) 代替案を評価します。リスクを特定して解決します。(3) 反復からの成果物を開発および検証します。(4) 次の反復を計画します。[11]
  • 各サイクルを利害関係者とその「勝利条件」の特定から始め、レビューとコミットメントで各サイクルを終了します。[12]

シェイプアップ

Shape Up は、 2018 年にBasecampによって導入されたソフトウェア開発アプローチです。これは、明確な終わりのないプロジェクトの問題を克服するために、Basecamp が社内で開発した一連の原則と手法です。主な対象者はリモート チームです。シェイプアップには、ウォーターフォールアジャイル、またはスクラムとは異なり、見積もりと速度の追跡、バックログ、またはスプリントがありません代わりに、これらの概念は食欲、賭け、サイクルに置き換えられます。2022 年現在、Basecamp の他に、Shape Up を採用している著名な組織には、UserVoice と Block があります。[13] [14]

サイクル

試行錯誤の結果、Basecamp は理想的なサイクルの長さが 6 週間であることを発見しました。この 6 週間という期間は、意味のある機能を構築するのに十分な長さですが、それでも切迫感を引き起こすには十分な短さです。

整形

シェーピングとは、設計者技術者に引き渡す前に作業を準備するプロセスです形作られた作品は、ソリューションの主要な UI 要素を詳しく説明し、うさぎの穴を特定し、明確な範囲の境界を示します。これはラフであり、ビルダー (デザイナーとエンジニア) が解決できるように細かい部分を残して、ビルダーが創造性を発揮し、トレードオフを行うことができるようにすることを目的としています。[15]形成された作業は、コメントをサポートするオンライン ドキュメント ソリューションを使用してピッチの形式で文書化されるため、チーム メンバーは技術情報を非同期的に投稿できます。このようなコメントは、プロジェクトを狂わせかねない隠れた驚きを明らかにするために重要です。

サイクルが始まる前に、利害関係者は賭けのテーブルを保持し、ピッチが確認されます。投球ごとに、賭けるか落とすかの決定が下されます。[16]

食欲

Shape Up がプロジェクトに割り当てられる時間を決定する方法は、他の方法論とは正反対です。Shape Up は、食欲 (たとえば 6 週間) から始まり、この制約内で提供できるソリューションの設計で終わります。食欲は、プロジェクトのビルダーにとって厳しい締め切りになります。[17]

建物

シェイプアップは、シェイパーとビルダーが並行して作業する 2 トラック システムです。現在のサイクルで形成されている作業は、将来のサイクルで構築するためにデザイナーやエンジニアに与えられる場合があります。

建物の建設には技術的な不確実性があることを認識し、ヒル チャートと名付けられた丘の比喩を視覚化したチャートを使用して進捗状況を追跡します。上り坂はビルダーがまだアプローチを模索している段階であり、下り坂は未知数が排除された段階です。ビルダーは、Basecamp またはJiraのインタラクティブなオンライン ヒル チャートを使用して積極的かつ非同期的に進捗状況を自己報告し、完了または未完了のステータスから不明または解決済みの問題に焦点を移します。ヒル チャートの使用は、スクラムまたはカンバンスタンドアップで線形ステータスを報告するプロセスに取って代わります。[18] [19]

高度な方法論

その他の高度なソフトウェア プロジェクトの方法論には、次のようなものがあります。

  • ビヘイビア駆動開発とビジネス プロセス管理[20]
  • カオス モデル- 主なルールは、常に最も重要な問題を最初に解決します。
  • 段階的な資金調達方法- 反復的なアプローチ
  • 軽量方法論- いくつかのルールとプラクティスしかない方法の総称
  • 構造化システムの分析と設計手法- ウォーターフォールの特定バージョン
  • スロー プログラミングは、より大きなスロー ムーブメントの一部として、時間のプレッシャーがない (または最小限の) 慎重で段階的な作業を強調しています。スロー プログラミングは、バグや過度に短いリリース スケジュールを避けることを目的としています。
  • V-Model (ソフトウェア開発) - ウォーターフォール モデルの拡張
  • 統一プロセス(UP) は、統一モデリング言語(UML)に基づく、反復的なソフトウェア開発手法のフレームワークです。UP は、ソフトウェアの開発を 4 つのフェーズに編成します。各フェーズは、開発のその段階でのソフトウェアの 1 つ以上の実行可能な反復から構成されます。つまり、開始、精緻化、構築、およびガイドラインです。UP の実装を容易にするツールや製品は数多くあります。UP のより一般的なバージョンの 1 つは、Rational Unified Process (RUP) です。
  • ビッグバンの方法論 - 小規模または未定義のプロジェクト向けのアプローチであり、通常は計画がほとんどまたはまったくなく、リスクが高くなります。

メタモデルの処理

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

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

実際に

ソフトウェア開発方法論のフレームワークに適用される 3 つの基本的なアプローチ。

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

ソフトウェア開発組織は、開発プロセスを容易にするプロセス方法論を実装します。場合によっては、請負業者が方法論の採用を要求する場合があります。たとえば、米国の防衛産業では、契約を取得するためにプロセス モデルに基づく評価が必要です。ソフトウェアのライフサイクルを選択、実装、および監視する方法を説明する国際規格は、ISO/IEC 12207です。

何十年にもわたる目標は、生産性と品質を向上させる反復可能で予測可能なプロセスを見つけることでした。ソフトウェアを設計するという一見手に負えない作業を体系化または形式化しようとする人もいます。また、プロジェクト管理手法をソフトウェアの設計に適用する人もいます。多数のソフトウェア プロジェクトは、機能、コスト、または配信スケジュールの点で期待を満たしていません。いくつかの注目すべき例について は、失敗したカスタム ソフトウェア プロジェクトと予算超過のカスタム ソフトウェア プロジェクトのリストを参照してください。

組織は、プロセス改善の中心となるソフトウェア エンジニアリング プロセス グループ(SEPG) を作成する場合があります。さまざまなスキルを持つライン プラクティショナーで構成されるこのグループは、ソフトウェア エンジニアリング プロセスの改善に携わる組織内の全員の共同作業の中心にあります。

特定の開発チームは、 1 つ以上の主要なプログラミング パラダイムプログラミング スタイルの規則、または特定のソフトウェア ライブラリまたはソフトウェア フレームワークの選択を使用する統合開発環境など、プログラム環境の詳細に同意する場合もあります。これらの詳細は、通常、モデルの選択や一般的な方法論によって決定されることはありません。

ソフトウェア開発ライフサイクル (SDLC)

も参照

参考文献

  1. ^ a b c d e f g Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). 開発アプローチの選択ウェブ記事。米国保健社会福祉省 (HHS)。再検証: 2008 年 3 月 27 日。2008 年 10 月 27 日閲覧。
  2. ^ a b Geoffrey Elliott (2004)グローバル ビジネス情報技術: 統合システム アプローチピアソン教育。p.87。
  3. ^ Suryanarayana、Girish (2015). 「ソフトウェア プロセス vs 設計品質: 綱引き?」. IEEE ソフトウェア. 32 (4): 7–11. ドイ: 10.1109/MS.2015.87 .
  4. ^ 「ソフトウェア開発プロセス」 . 2020 年 8 月 19 日。
  5. ^ 「継続的統合」 .
  6. ^ Booch, Grady (1991). オブジェクト指向設計: アプリケーションを使用ベンジャミン・カミングスp。209.ISBN _ 9780805300918. 2014年 8 月 18 日閲覧
  7. ^ a b ウィッテン、ジェフリー L .; ロニー・D・ベントレーケビン・C・ディットマン(2003)。システム分析と設計方法第6版。ISBN 0-256-19906-X . 
  8. ^ Wasserfallmodel > Entstehungskontext , Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, TU-Wien. 2007 年 11 月 28 日にオンラインでアクセス。
  9. ^ Conrad Weisert、 Waterfall 方法論: そんなものはありません!
  10. ^ Barry Boehm (1996)., "A Spiral Model of Software Development and Enhancement ". 中: ACM SIGSOFT ソフトウェア エンジニアリング ノート(ACM) 11(4):14-24、1986 年 8 月
  11. ^ Richard H. Thayer, Barry W. Boehm (1986). チュートリアル: ソフトウェア エンジニアリング プロジェクト管理IEEE の Computer Society Press。p.130
  12. ^ バリー・W・ベーム (2000). Cocomo II を使用したソフトウェアのコスト見積もり: 第 1 巻
  13. ^ 「ジェイソン・フリードの序文 | Shape Up」 . basecamp.com . 2022 年9 月 11 日閲覧
  14. ^ 「シェイプアップはただの理論ですか?」. おさるのラボ2022 年9 月 12 日閲覧
  15. ^ 「シェーピングの原則 | シェイプアップ」 . basecamp.com . 2022 年9 月 11 日閲覧
  16. ^ 「バックログではなく賭け | シェイプアップ」 . basecamp.com . 2022 年9 月 11 日閲覧
  17. ^ 「責任の引き継ぎ | シェイプアップ」 . basecamp.com . 2022 年9 月 11 日閲覧
  18. ^ 「進行状況を表示 | シェイプアップ」 . basecamp.com . 2022 年9 月 12 日閲覧
  19. ^ 「アトラシアン マーケットプレイス」 . marketplace.atlassian.com 2022 年9 月 12 日閲覧
  20. ^ リュブケ、ダニエル。van Lessen、Tammo (2016)。「ビヘイビア駆動型開発のための BPMN でのテスト ケースのモデリング」。IEEE ソフトウェア. 33 (5): 15–21. ドイ: 10.1109/MS.2016.117 . S2CID 14539297 . 

外部リンク