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

ソフトウェア開発プロセスは、ソフトウェアを開発する ためのプロセスを規定する。通常、全体的な作業をより小さなステップまたはサブプロセスに分割し、高品質な結果を保証することを目的としている。このプロセスでは、作成および完了すべき成果物である具体的な成果物を規定することもある。 [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 取引 両方 両方 両方 DSS DSS DSS
インタフェース 最小限 最小限 弱い ウィンドウズ 重要な 重要な 重要な
ドキュメントとトレーニング 重要な 限定 内部 オブジェクト内 限定 弱い なし
完全性とセキュリティ 重要な 重要な 未知 オブジェクト内 限定 弱い 弱い
再利用性 限定 いくつかの 多分 重要な 限定 弱い なし

プロセスメタモデル

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

ISO/IEC 12207

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

能力成熟度モデルの統合

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

ISO 9000

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

ISO/IEC 15504

ISO/IEC 15504 Information technology—Process assessment, a.k.a. Software Process Improvement Capability Determination (SPICE), is a framework for the assessment of software processes. This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide, and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.

ISO/IEC 24744

ISO/IEC 24744 Software Engineering—Metamodel for Development Methodologies, is a power type-based metamodel for software development methodologies.

Soft systems methodology

Soft systems methodology is a general method for improving management processes.

Method engineering

Method engineering is a general method for improving information system processes.

See also

References

  1. ^ "Selecting a development approach" (PDF). Centers for Medicare & Medicaid Services (CMS) Office of Information Service. United States Department of Health and Human Services (HHS). March 27, 2008 [Original Issuance: February 17, 2005]. Archived from the original (PDF) on June 20, 2012. Retrieved October 27, 2008.
  2. ^ Suryanarayana, Girish (2015). "Software Process versus Design Quality: Tug of War?". IEEE Software. 32 (4): 7–11. doi:10.1109/MS.2015.87.
  3. ^ "Systems Development Life Cycle from". FOLDOC. Retrieved June 14, 2013.
  4. ^ "Software Development Life Cycle (SDLC)" (PDF). softwarelifecyclepros.com. May 2012. Retrieved June 26, 2025.
  5. ^ "SDLC Overview: Models & Methodologies". Retrieved December 12, 2021.
  6. ^ Arden, Trevor (1991). Information technology applications. London: Pitman. ISBN 978-0-273-03470-4.
  7. ^ "What is Scrum?". December 24, 2019.
  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=1325364542"