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

Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and bodies of knowledge
Glossaries
Outlines

ソフトウェア開発プロセスは、ソフトウェアを開発する ためのプロセスを規定する。通常、全体的な作業をより小さなステップまたはサブプロセスに分割し、高品質な結果を保証することを目的としている。このプロセスでは、作成および完了すべき成果物である具体的な成果物を規定することもある。 [1]

ソフトウェア開発プロセスとは、厳密にはこれに限定されませんが、ソフトウェアシステムの開発をその開始から終了まで統括する高レベルのプロセスを指すことが多く、方法論、モデル、フレームワークなどと呼ばれます。システム開発ライフサイクル（SDLC）は、ソフトウェアシステムを含むシステムの開発が開始から終了まで行う典型的なフェーズを表します。方法論は、エンジニアがシステムのライフサイクル全体を通じて作業を進めるための方法を規定します。方法論とは、SDLCのために考案されたプロセスの分類、またはプロセスの青写真です。例えば、多くのプロセスはスパイラルモデルに分類できます。

ソフトウェアプロセスとソフトウェア品質は密接に関連しており、実際には予期せぬ側面や影響が観察されています。[2]

方法論

SDLCは方法論の定義を決定づけるものであり、方法論はSDLCの各フェーズに対応していなければなりません。一般的に、方法論は、コンピュータシステムが複雑で、異なるコンポーネントを統合している場合でも、期待（要件）を満たすかそれを超える高品質なシステムを実現し、期限内に予算内で納品されるように設計されます。[3]ウォーターフォール、スパイラル、アジャイル、ラピッドプロトタイピング、インクリメンタル、同期と安定化など、様々な方法論が考案されています。 [4]

方法論間の大きな違いは、フェーズがどの程度順次的か反復的かという点です。XPやスクラムなどのアジャイル方法論は、迅速な変更を可能にする軽量プロセスに重点を置いています。[5]ラショナル統一プロセスや動的システム開発手法などの反復的な方法論は、プロジェクトスコープの安定化と、製品の反復的な拡張または改善に重点を置いています。ウォーターフォールなどのシーケンシャルまたはビッグデザインアップフロント（BDUF）モデルは、大規模プロジェクトを導き、リスクを限定して成功と予測可能な結果を​​もたらすために、完全かつ正確な計画に重点を置いています。[6]アナモルフィック開発は、プロジェクトスコープと適応的な反復によって進められます。例えばスクラムでは、[7] 1つのユーザーストーリーが2週間のスプリントでSDLCのすべてのフェーズを踏むと言えます。これとは対照的に、ウォーターフォール方法論では、すべてのビジネス要件[要出典]が機能記述に変換され、通常は数か月以上かけてすべてが実装されます。[要出典]

プロジェクトには、異なる活動を記述するプロジェクトライフサイクル（PLC）とシステム開発ライフサイクル（SDLC）の両方が含まれる場合があります。Taylor (2004) によると、「プロジェクトライフサイクルはプロジェクトのすべての活動を網羅するのに対し、システム開発ライフサイクルは製品要件の実現に重点を置いています。」[8]

歴史

SDLCという用語は、 SDLC方法論の略称としてよく使用されます。また、SDLCと従来のSDLCをウォーターフォール方法論の意味で使う人もいます。

エリオット（2004）によると、SDLCは「1960年代に、大規模企業コングロマリットの時代に、大規模で機能的なビジネスシステムを開発するために誕生した。情報システム業務は、膨大なデータ処理と計算ルーチンを中心としていた」[9] 。構造化システム分析設計法（SSADM）は、1980年代に英国政府商務局（Office of Government Commerce）向けに開発された。エリオット（2004）によると、それ以来、「システム開発における従来のライフサイクルアプローチは、従来のSDLCに内在する欠陥の一部を克服しようとする、代替アプローチやフレームワークに徐々に取って代わられてきた」[9]。SDLCの中心的な考え方は、「情報システム開発を非常に慎重かつ構造的かつ体系的に進め、ライフサイクルの各段階（アイデアの発案から最終システムの提供まで）を、適用されるフレームワークの文脈の中で 、厳格かつ順次実行することを要求する」 [9]ことにある。

その後、他の方法論も考案されました。

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

1994 年の DSDM 以降、RUP を除く上記のリストにある方法論はすべてアジャイル方法論ですが、多くの組織、特に政府機関では、依然としてアジャイル以前のプロセス (多くの場合ウォーターフォールまたは類似のプロセス) を使用しています。

例

以下は、人気順に並べた注目すべき方法論です。

アジャイル

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

滝

ウォーターフォール モデルは、開発が SDLC フェーズを通じて一方向に (ウォーターフォールのように) 流れる順次的な開発アプローチです。

スパイラル

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

増分

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

プロトタイピング

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

急速な

ラピッド・アプリケーション・デベロップメント（RAD）は、大規模な事前計画ではなく、反復的な開発と迅速なプロトタイプ構築を重視する手法です。RADを用いて開発されるソフトウェアの「計画」は、ソフトウェア自体の開発と並行して行われます。大規模な事前計画が不要なため、ソフトウェアの開発期間が大幅に短縮され、要件の変更も容易になります。

シェイプアップ

Shape Upは、 Basecampが2018年に導入したソフトウェア開発アプローチです。これは、プロジェクトが明確な終わりを見せずに長期化する問題を克服するために、Basecampが社内で開発した一連の原則と手法です。主なターゲットはリモートチームです。Shape Upには、ウォーターフォール、アジャイル、スクラムとは異なり、見積もりや速度追跡、バックログ、スプリントといった概念はありません。代わりに、アペタティブネス、ベッティング、サイクルといった概念が採用されています。2022年現在、Basecamp以外にも、UserVoiceやBlockといった著名な組織がShape Upを採用しています。[10] [11]

カオス

カオス モデルには 1 つの主要なルールがあります。それは、常に最も重要な問題を最初に解決することです。

増分資金調達

増分資金調達方法論- 反復的なアプローチ。

軽量

軽量方法論- ルールとプラクティスが少数しかない方法の総称。

構造化システム分析と設計

構造化システム分析および設計方法- ウォーターフォールの特定のバージョン。

スロープログラミング

より広範なスロームーブメントの一環として、時間的プレッシャーを最小限に（あるいは最小限に）抑えた、慎重かつ段階的な作業を重視します。スロープログラミングは、バグや過度に急速なリリーススケジュールを回避することを目的としています。

Vモデル

V モデル (ソフトウェア開発) - ウォーターフォール モデルの拡張。

統一プロセス

統一プロセス（UP）は、統一モデリング言語（UML）に基づく反復的なソフトウェア開発方法論フレームワークです。UPは、ソフトウェア開発を4つのフェーズ（開始、詳細化、構築、ガイドライン）に体系化します。各フェーズは、開発の各段階におけるソフトウェアの実行可能な反復（1つ以上）で構成されます。

比較

ウォーターフォールモデルは、SDLCの各フェーズが前のフェーズの結果に基づいて構築されるように記述します。[12] [13] [14] [15]すべてのプロジェクトでフェーズが連続している必要はありません。比較的単純なプロジェクトでは、フェーズが組み合わされたり、重複したりすることがあります。[12]以下では、ウォーターフォールに代わる方法論について説明し、比較します。[16]

方法論の比較
滝ラドオープンソースオブジェクト指向ジャドプロトタイピングエンドユーザー
コントロールフォーマルMIS弱い標準ジョイントユーザーユーザー
時間枠長さ短い中くらいどれでも中くらい短い短い

–

ユーザー多くの少し少し様々少し1つか2つ1つ
MISスタッフ多くの少し数百スプリット少し1つか2つなし
トランザクション/ DSS取引両方両方両方DSSDSSDSS
インタフェース最小限最小限弱いウィンドウズ重要な重要な重要な
ドキュメントとトレーニング重要な限定内部オブジェクト内限定弱いなし
完全性とセキュリティ重要な重要な未知オブジェクト内限定弱い弱い
再利用性限定いくつかの多分重要な限定弱いなし

プロセスメタモデル

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

ISO/IEC 12207

ISO/IEC 12207は、ソフトウェアのライフサイクルを選択、実装、監視する方法を規定した国際規格です。

能力成熟度モデルの統合

能力成熟度モデル統合（CMMI）は、ベストプラクティスに基づいた主要なモデルの一つです。独立した評価システムでは、定義されたプロセスにどれだけ忠実に従っているかに基づいて組織を評価します。プロセスの品質や作成されたソフトウェアの品質に基づいて評価するのではありません。CMMIはCMMに取って代わりました。

ISO 9000

ISO 9000は、製品を製造するための正式に組織化されたプロセスと、進捗状況の管理および監視方法に関する規格を規定しています。この規格はもともと製造業向けに策定されましたが、ソフトウェア開発にも適用されています。CMMIと同様に、ISO 9000の認証は最終製品の品質を保証するものではなく、正式なビジネスプロセスが遵守されていることを保証するものです。

ISO/IEC 15504

ISO/IEC 15504 情報技術プロセス評価（SPICE）は、ソフトウェアプロセス改善能力判定とも呼ばれ、ソフトウェアプロセスを評価するフレームワークです。この規格は、プロセス比較のための明確なモデルを策定することを目的としています。SPICEはCMMIと同様に用いられ、ソフトウェア開発を管理、制御、ガイド、監視するためのプロセスをモデル化します。このモデルは、開発組織またはプロジェクトチームがソフトウェア開発中に実際に行っていることを測定するために使用されます。この情報は分析され、弱点を特定し、改善を推進します。また、組織またはチームの一般的な実践に継続または統合できる強みも特定します。

ISO/IEC 24744

ISO/IEC 24744 ソフトウェア エンジニアリング - 開発方法論のメタモデルは、ソフトウェア開発方法論のパワー タイプ ベースのメタモデルです。

ソフトシステム方法論

ソフトシステム方法論は、管理プロセスを改善するための一般的な方法です。

メソッドエンジニアリング

メソッド エンジニアリングは、情報システム プロセスを改善するための一般的な方法です。

参照

参考文献

  1. ^ 「開発アプローチの選択」（PDF）。メディケア・メディケイドサービスセンター（CMS）情報サービス局。米国保健福祉省（HHS）。2008年3月27日[初版発行：2005年2月17日]。 2012年6月20日時点のオリジナル（PDF）からアーカイブ。 2008年10月27日閲覧。
  2. ^ Suryanarayana, Girish (2015). 「ソフトウェアプロセスと設計品質：綱引き？」IEEEソフトウェア. 32 (4): 7– 11. doi : 10.1109/MS.2015.87 .
  3. ^ 「システム開発ライフサイクル」FOLDOC . 2013年6月14日閲覧。
  4. ^ 「ソフトウェア開発ライフサイクル（SDLC）」（PDF） . softwarelifecyclepros.com . 2012年5月. 2025年6月26日閲覧。
  5. ^ 「SDLCの概要：モデルと方法論」 。 2021年12月12日閲覧。
  6. ^ アーデン、トレバー（1991年）『情報技術アプリケーション』ロンドン：ピットマン社、ISBN 978-0-273-03470-4。
  7. ^ 「スクラムとは何か？」2019年12月24日。
  8. ^ Taylor, James (2004).情報技術プロジェクトの管理. p. 39.
  9. ^ abc Geoffrey Elliott (2004).グローバルビジネス情報技術：統合システムアプローチ. ピアソン・エデュケーション. p. 87.
  10. ^ 「ジェイソン・フリードによる序文 | Shape Up」. basecamp.com . 2022年9月11日閲覧。
  11. ^ 「シェイプアップは単なる良い理論なのか？」Curious Lab . 2022年9月12日閲覧。
  12. ^ ab 米国司法省 (2003). 情報資源管理 第1章 はじめに.
  13. ^ Everatt, GD; McLeod, R Jr (2007). 「第2章 ソフトウェア開発ライフサイクル」.ソフトウェアテスト：ソフトウェア開発ライフサイクル全体にわたるテスト. John Wiley & Sons. pp.  29– 58. ISBN 9780470146347。
  14. ^ Unhelkar, B. (2016). 『アジャイル実践の技法：プロジェクトと組織のための複合アプローチ』CRC Press. pp.  56– 59. ISBN 9781439851197。
  15. ^ Land, SK ; Smith, DB; Walz, JW (2012). Lean Six Sigmaソフトウェアプロセス定義の実践的サポート：IEEEソフトウェアエンジニアリング標準の使用. John Wiley & Sons. pp.  341–3 . ISBN 9780470289952。
  16. ^ Post, G., & Anderson, D., (2006).『経営情報システム：情報技術によるビジネス問題の解決』（第4版）. ニューヨーク：McGraw-Hill Irwin.
ウィキメディア コモンズには、ソフトウェア開発方法論に関連するメディアがあります。
  • 開発アプローチの選択は、2019 年 1 月 2 日に、Wayback Machine at cms.hhs.gov にアーカイブされています。
  • ゲルハルト・フィッシャー、「21世紀のソフトウェア技術：ソフトウェアの再利用から共同ソフトウェア設計へ」2009年9月15日アーカイブ、Wayback Machine、2001年
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_development_process&oldid=1321905588"