CMMIとは何？ わかりやすく解説 Weblio辞書 (original) (raw)

能力成熟度モデル統合 (のうりょくせいじゅくどモデルとうごう、英: Capability Maturity Model Integration, CMMI) は、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものである[1] 。 平易な言い方をすると、ソフトウェア開発組織及びプロジェクトのプロセスを改善するために、その組織の成熟度レベルを段階的に定義したものである。 CMMIは、もともとは能力成熟度モデル (CMM; Capability Maturity Model) として開発された。

概要

CMMIは、プロセスの評価や改善をすすめるための枠組みであり、段階表現と連続表現の2つの表現方法がある。段階表現では、組織の実施プロセスを評価し、レベル1からレベル5までの5段階の成熟度レベルを（組織に対して）出すことができる。連続表現では、各プロセスを評価し、レベル0からレベル3までの4段階の能力度レベルを（プロセスごとに）出すことができる。（以前はレベル0から5までの6段階であったが、v1.3から4段階に改訂された。）これらのレベルは、評価の対象となるプロセスの制度化の程度に応じて、等級づけられている。

評価の対象となる領域はさまざまであり次のようなものがある。

CMMIでは5つの成熟度レベルを厳密に定義している。

1998年の時点では、ソフトウェア開発を行う組織の75%がレベル1であると推定されている (参考)。

CMMIの前身にあたるCMMは、1980年代半ばにアメリカ合衆国のピッツバーグにあるカーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI; Software Engineering Institute) で開発された。 CMMIは、航空電子工学ソフトウェアの開発や北アメリカ、欧州、アジア、オーストラリア、南アメリカ、アフリカなどの国々の政府主体で行うプロジェクトなどで、広く採用されてきており、こうした国々でCMMIに対する官民の関心は高い[2] 。 現在、いくつかの国々の省庁は、ソフトウェア開発契約に際して業者にレベル3の基準を達成しかつ運用できていることを必須としている。 また日本においても、ソフトウェアを発注する官公庁や民間組織がCMMIを採用し、一方でソフトウェア開発を担う組織がCMMIの指針に即して自らのソフトウェア開発プロセスを改善する動きが、徐々に広がりつつある。

成熟度モデル

CMMI (能力成熟度モデル統合) は、組織がプロセスを定め洗練するための手段である。 最初のCMMはソフトウェア開発プロセスを確立し洗練することを目標としていた。 成熟度モデルは、効果的なプロセスのさまざまな特性を構造化して記述した体系である。 カーネギーメロン大学 (CMU) のCMMI研究所はCMMIの公式文書を公開しており、この中には日本語の公式訳もある。この日本語訳は、ソフトウェアプロセス改善に関する企業コンソーシアムであるJASPIC (日本SPIコンソーシアム)が翻訳作業を実施したものである。 いずれも無償でダウンロード/閲覧することができる。

成熟度モデルが提供するものは次のとおりである。

成熟度モデルは、同等の能力をもつと思われる複数の組織を評価するベンチマークとして使うことができる。

歴史

CMMI（能力成熟度モデル統合）の前身である CMM（能力成熟度モデル）は、もともとは軍事研究の一環として資金を与えられて始まった。 アメリカ合衆国空軍がカーネギーメロン大学（CMU） のソフトウェア工学研究所（SEI）に資金を渡して、軍事部門がソフトウェアの下請業者を客観的に評価するものとして使えるモデルを作る研究を依頼した。 研究成果は1989年に Managing the software process の書名で出版された（日本語訳『ソフトウェアプロセス成熟度の改善』1991年）。 CMMはその後も改訂・更新を経ている。 SEIはもはや CMM に対するサポートを止め、改訂版である CMMI（能力成熟度モデル統合、Capability Maturity Model Integration）が開発・サポートの対象となっている。 2012年、カーネギーメロン大学は、CMMI研究所（CMMI Institute）という新しい研究所を設立し、CMMIに関係する成果物と活動をSEIから移行した。 2013年現在、CMMI バージョン 1.3 が公表されており、CMMI Instituteのウェブサイトで全文を閲覧することができる。

背景

1970年代に、技術の発達によりコンピュータが広く普及しよりさまざまな用途に使われるようになり、従来より少ない費用で導入できるようになっていた。 多くの組織は、コンピュータ化による情報システムを推進する方針を採り、それに伴い組織におけるソフトウェア開発の領域の比重も非常に大きくなった。 こうした情況から、開発者および開発管理者に対する要求は日増しに大きくなっていた。 このような要求には、経験をあまり積んでいない専門職の人々が対応していた。

不幸なことに、開発者に対する要求が非常に大きくなったことは、組織にとって苦痛を伴った。 ソフトウェア開発プロジェクトが失敗に終わることは、ごく普通のありふれたことになってしまった。 その原因は、コンピュータ科学が当時は未成熟であったことだけでなく、開発プロジェクトがその規模と複雑さにおいて野心的で多くの労力を伴う傾向が有ったためでもある。 この問題に対して、エドワード・ヨードン、ラリー・コンスタンティン、ジェラルド・ワインバーグ、トム・デマルコ、デイビッド・パーナスなどの人々は、ソフトウェア開発プロセスをより熟練した工程とするための研究を行い、その研究成果を論文および書籍として発表した。

ワッツ・ハンフリーによる能力成熟度モデル（CMM; Capability Maturity Model）は、1989年に Managing the Software Process という書籍に記述され出版された（日本語訳は『ソフトウェアプロセス成熟度の改善』1991年）。 ワッツ・ハンフリーが考案したCMMは、10年前のフィル・クロスビーの業績に基づいている。 クロスビーの業績は、彼の1979年の著書 Quality is Free の "Quality Management Maturity Grid" で公表された[3][4]。 1986年から SEI（ソフトウェア工学研究所）により本格的に CMM のモデル構築が始まった。

CMMはもともとは政府のソフトウェア開発請負業者を評価するためのツールと位置づけられており、ソフトウェア開発契約に基づくプロジェクトを遂行する際に活用することが想定されていた。 CMMはソフトウェア開発の分野で活用されていたが、システム工学分野でも適用できるCMMIに発展し、さらに、さまざまなプロセスの成熟度の一般的なモデルとして、広く適用されるようになっている（ITサービス管理プロセスなど）。 システムインテグレータや情報技術関連組織などがCMMIを活用するようになっている。

CMMIのモデルは、ソフトウェアやシステムの開発、調達、サービス提供を行う組織のプロセス成熟度について、5つのレベルを規定している。

  1. 初期状態（混沌とした、いきあたりばったりで、一部の英雄的なメンバー依存の状態）。成熟したプロセスを導入する際の、出発点のレベル。
  2. 管理された状態（反復できる状態、プロジェクト管理・プロセスの規則の存在）、反復してプロセスを実行できるレベル
  3. 定義された状態（制度化された状態）、プロセスが標準ビジネスプロセスとして明示的に定義され関係者の承認を受けているレベル。
  4. 定量的に管理された状態（制御できる状態）、プロセス管理が実施され、さまざまなタスク領域を定量的に制御しているレベル。
  5. 最適化している状態（プロセスを定量的に改善する状態）、継続的に自らのプロセスを最適化し改善しているレベル。

CMMIは複数のプロセス領域（プロセスエリア）から構成されている。段階表現の場合にはプロセス領域は成熟度レベルに応じて分類されている。連続表現ではプロセスの適用対象の区分（プロジェクト管理、プロセス管理、エンジニアリングなど）に応じて分類されている。各プロセス領域はさらに複数のゴールから構成されている。ゴールには固有ゴールと共通ゴールの2種類がある。固有ゴールは、例えば、プロジェクト計画策定プロセス領域であれば、「プロジェクト計画を策定する」のように、そのプロセス領域で実施されるべき固有の内容を表わしている。共通ゴールは、プロセスの制度化の程度を表わしており、（成熟度および能力度）レベルと対応している。

CMMIによりプロセス改善に取り組む組織は、資格を認定された評定者（リードアプレイザまたはB,Cチームリーダ）によりプロセスの評定（アプレイザル）を受けることができる。評定には厳格さに応じてA,B,Cの三段階のクラスがあり、もっとも厳格なクラスAの評定では成熟度レベルの判定を出すことができる。 改善の初期にまずプロセスの評定（アプレイザル）を受けることにより、組織は改善点を客観的・網羅的に把握することができ、次の改善のための計画を立てることができる。改善活動実施後、その改善結果の確認のために、再度、評定を受ける。この際には成熟度レベルの判定ができるクラスＡの評定を実施することが多い。

レベルはその定義から累積的な概念であり、高いレベルの達成は低いレベルの内容も同時に達成していることを意味する。成熟度レベルは段階的で自然なプロセス改善の順序と考えられており、レベルを飛び越す形の改善は推奨されない。

注意: CMMはもともとは政府の請負業者が請け負ったソフトウェアを開発する能力を評価する手段を想定して作成された。 CMM/CMMIがソフトウェア開発プロセス成熟度のモデルとして一般的になると、CMM/CMMIに対する批判も多くなされるようになった。

商用のパッケージソフトウェアを開発する企業（Apple、シマンテック、マイクロソフトなど）の多くは、CMMIが規定する水準の文書を滅多に管理していない[_要出典_]。 この文書管理はCMMIのレベル2を達成するために必要である。 こうした企業のほとんどはレベル1に等級づけられるであろう。

起源

アメリカ合衆国空軍が SEI（ソフトウェア工学研究所）に資金を提供して、SEIは軍がソフトウェア開発請負業者の客観的な評価基準として使うモデルを作成する研究を行った。 1989年に、CMM（能力成熟度モデル）は Managing the software process の書名で出版された（日本語訳『ソフトウェアプロセス成熟度の改善』1991年）。

年表

現状

CMMに基づいた各モデルは多くの組織にとって有用であったが、複数のモデルを使いこなすことが難しい課題となっていた。 さらに、複数のモデルの適用を一つの組織内もしくは組織横断的に統合して実行することは、訓練、評価、プロセス改善において費用が高くついた。 複数のCMMモデルを適用するに伴う課題を克服する、CMM統合（CMMI; CMM Integration）プロジェクトが立ち上げられた。 CMMI開発チームの目的は、3つのソースモデルを統合することであった。

  1. ソフトウェア能力成熟度モデル（SW-CMM）v2.0 ドラフト C
  2. システムエンジニアリング成熟度モデル（SECM）
  3. 統合成果物開発成熟度モデル（IPD-CMM）v0.98
  4. 供給者ソーシング

CMMI は3つのソースモデルの後継版として位置づけられている。 SEI は SW-CMM、SECM、IPD-CMM および古いバージョンの CMMI を終了する方針を公表した[1]。 これらのモデルは新しいバージョンの CMMI が後継している。

またCMMIは、ISO/IEC 15504にも適合できるように、これまでの段階表現（Staged Representation）に加え、連続表現（Continuous Representation）も用意された。

CMMIの発展

CMMIバージョン1.2が公表されると、SEI は既存の CMMI を 「開発のためのCMMI」（CMMI for Development, CMMI-DEV）と改称した[2]。 現在では、CMMIは発展して、「開発」以外の目的にも使用できるような複数のモデルが作られている。それぞれのモデルは関連要素群と呼ばれている。

SEI の援助のもとでノースロップ・グラマン社が主導するチームが CMMI for Services という CMMI の関連要素群を開発した。 この開発には以下の各企業・団体も参加していた[3]。

SEIは、CMMI for Acquisition（CMMI-ACQ）という CMMI の関連要素群も開発した。

SEIは、CMMIを改善する提案を歓迎している。 SEIにCMMIのフィードバックを渡す方法については、CMMIのウェブサイトを参照。

場合によっては、CMMIは他の方法論と組み合わせることができる。 CMMI と ISO 9001 を同時に施行することは、よく行われている。 JPモルガン・チェースは、CMMをコンピュータプログラミング方法論エクストリーム・プログラミング（XP） およびシックス・シグマと統合することを試みた。 この統合を行った人々は、統合した3つの体系が互いを補強し、相互に矛盾することは無い、との所感をもった。 Extreme Programming (XP) Six Sigma CMMIを参照。

成熟度レベル

詳細はSEIのCMMIv1.3 (2010年11月の版) 第3章 26ページを参照

CMMI (能力成熟度モデル統合) には5つの成熟度レベルがある。 SEIによると、

組織のソフトウェアプロセスの予測可能性、効率性、および管理は、これらの5つの段階を経て上ることを通じて改善されると確信している。厳格な基準ではないが、経験的な証拠がこの確信を裏づけている。

レベル1 初期

成熟度レベル1では多くの場合、プロセスは場当たり的であり、組織は安定した環境を提供しない。 こうした組織では、プロジェクトの成功は、組織に属する個々人の能力と英雄的行動に依存しており、有用性が証明されたプロセスを採用していない。 場当たり的で混沌とした環境であるにもかかわらず、成熟度レベル1の組織は実際に動く成果物とサービスを提供することが少なくない。 しかしそれらは多くの場合プロジェクトの予算および予定期限を超過する。

成熟度レベル1の組織は、超過労働、危機に対処するプロセスの欠如、過去の成功を繰り返す能力の欠如、によって特徴づけられる。

レベル1の組織が遂行するプロジェクトの成功は、高い能力をもつ個人に依存している。

レベル2 管理された

成熟度レベル2の組織はソフトウェア開発などの成功を反復して実行することができる。 このレベルの組織では、組織の全てのプロジェクトにおいて反復が実現できているとは限らない。 このレベルの組織では、何らかの基本的なプロジェクト管理を行い、費用と予定 (スケジュール) を管理している。

レベル2のプロセスの規律を実行することにより、これまで行ってきた実践は今後も意識して行われ続けられる。 これまで行ってきた実践は今後も首尾良く行われる場合、プロジェクトは文書化された計画に従って実行され管理される。

プロジェクトの情況や納品物の引渡しなどは、事前に定めておいた時点 (メジャーマイルストーンやメジャータスクの完了など) での管理を通して明確になる。

基本的なプロジェクト管理プロセスが確立し、費用、予定、開発対象の機能を管理する。 レベル2のプロセスの最低限の規律は、過去の類似した分野と範囲をもつプロジェクトの成功を、反復することである。 このレベルでは、費用もしくは納品予定日を超過するという大きなリスクは依然として存在する。

レベル3 定義された

成熟度レベル3の組織では、組織の標準プロセスが確立しており、時が経つにつれ標準プロセスは改善される。 こうした標準プロセスは、組織全体に浸透させ組織における一貫性を確立すべく使用される。 組織のプロジェクトは、組織の標準プロセスによりテーラリング指針に沿って、定義されたプロセスを確立する。

組織の管理部門は、組織の標準プロセスに基づいてプロセスの目的を確立し、こうした目的が確実に適切に取り組まれるようにする。

成熟度レベル2とレベル3の重要な違いは、標準群とプロセス記述と手続きである。 成熟度レベル2の組織では、標準群とプロセス記述と手続きは、プロセスのおのおのの具体的な内容において組織内でかなり異なっているかもしれない。 成熟度レベル3の組織では、あるプロジェクトや部門の標準群とプロセス記述と手続きは、組織の標準プロセスに適合している。

レベル4 定量的に管理された

成熟度レベル4の組織では、実施プロセスを安定化し、さらに実績を予測するモデルを持つことで、ソフトウェア開発などの有効性を効果的に制御することができる。 特に、個別のプロジェクトに対してプロセスを調整し適合する道筋を同定することができる。 このとき測定可能な品質の低減や仕様からの逸脱が無いようにプロセスが制御され、安定化される。 成熟度レベル4の組織は、ソフトウェア開発プロセスやソフトウェア保守などのための定量的な品質の目標を設定する。注意すべきことは、この目標がプロセスの実績データを基にした実現可能なものであり、（低いレベルの組織でありがちな）管理層からの一方的押しつけや実現不可能な努力目標ではないということである。

プロセス全体の遂行に非常に大きく貢献するサブプロセスが選択される。 この選択されたサブプロセスは、統計的な技法と他の定量的な技法により制御される。

成熟度レベル3とレベル4の重要な違いはプロセス遂行の予測可能性である。 成熟度レベル4では、プロセスの遂行は統計的な技法と他の定量的な技法により制御され、定量的に予測可能である。 成熟度レベル3では、プロセスは単に定性的に予測可能なだけである。

レベル5 最適化している

成熟度レベル5は、段階的および革新的な技術的進歩を通じた継続的なプロセスの有効性の改善を重視する。 組織にとっての定量的なプロセス改善の複数の目標が定められる。 これらの目標は、ビジネス上の目標の変更を反映して継続的に改訂される。 またこれらの目標は、プロセス改善の管理における基準として使われる。 適用されたプロセス改善の有効性は計測され、定量的なプロセス改善目標に照らして評価される。 定義されたプロセスと組織の標準プロセスのセットの双方が、改善活動の計測の対象となる。

プロセス改善は、プロセスにおける変動の共通の原因に取り組み組織のプロセスを計測可能な形で改善するために、同定され評価され適用される。

敏捷で適応力のある進取的なプロセスの最適化は、能力の高い労働者がビジネス価値と組織の目標に同調して参加するかどうかにかかっている。 組織における変化と機会にすばやく対応する能力は、学習を加速し共有する道筋をみつけることで高まる。

成熟度レベル4とレベル5の重要な違いは、取り組む対象である、プロセスにおける変動の種類である。 成熟度レベル4では、プロセスはプロセスにおける変動の特定の原因に取り組むことと結果の統計的予測と関連している。 プロセスは予測可能な結果を出すかもしれないが、その結果はあらかじめ定めた目標の達成には不十分であるかもしれない。 成熟度レベル5では、プロセスはプロセスにおける変動に共通する原因に取り組むこととプロセスを変更し (すなわちプロセスの遂行能力の平均値を変更する) その遂行能力を向上させ (統計的確率を修整しつつ) あらかじめ定めた定量的なプロセス改善目標を達成できるようにすることと関連している。

レベルに関する表現

成熟度レベル5は「最適化しているレベル」であって「最適化されたレベル」ではない。 これは、プロセス改善に終わりはなく、常に改善し続けていくものだという 考えに基づいている。

同様の考え方から、レベルに関しては「認証」「認定」「取得」といった表現は使わず、 「達成」という表現を使うべきものとされている。レベル「認定」を「取得」する ことだけが目的の改善ならば、「認定」された時点で活動が終わってしまうからである。 仕組みとしても、CMMIでは 何らかの認証機関が成熟度レベルを認証したり、認定することはない。 資格を持ったリードアプレイザが（通常、その組織の人たちを含めた） アプレイザルチームを構成して、評定結果を出す仕組みがあるのみである。

能力度レベル

CMMIの連続表現ではプロセスごとにレベルをつけることができ、能力度レベルという名で呼ばれる。段階表現でも連続表現でもレベルの概念は同じであるとされているが、能力度レベルには、成熟度レベルにはない、レベル0が存在する。また、v1.3以降、能力度レベル4, 5は廃止された。

レベル0は、「不完全な」プロセスレベルとして特徴づけられる。 CMMIに関心をもつ多くの人々は、このレベルを冗長であるもしくは重要ではないとして、無視している[_要出典_]。 ただしプレスマンなどの人々はこのレベルに注目している。 SEI CMMI 2002年8月のバージョンの18頁を参照[5]。

アントニー・フィンケルシュタイン[6] は、負 (マイナス) のレベルが何段階か必要だと考えている。 負のレベルは、平凡であるに加えてはっきり非生産的な環境を表す。 この負のレベルは、トム・ショルシュ[7] により「能力非成熟度モデル」("Capability Immaturity Model") として改良された。

プロセス領域

CMMI (能力成熟度モデル統合) は複数のプロセス領域から構成されている。 以下は「開発のためのCMMI」のプロセス領域の一覧である。

能力成熟度モデル統合 (CMMI) のプロセス領域

プロセス領域 区分 成熟度レベル
要件管理 (REQM: Requirements Management) プロジェクト管理 2
プロジェクト計画策定 (PP: Project Planning) プロジェクト管理 2
プロジェクトの監視と制御 (PMC: Project Monitoring and Control) プロジェクト管理 2
供給者合意管理 (SAM: Supplier Agreement Management) プロジェクト管理 2
測定と分析 (MA: Measurement and Analysis) 支援 2
プロセスと成果物の品質保証 (PPQA: Process and Product Quality Assurance) 支援 2
構成管理 (CM: Configuration Management) 支援 2
要件開発 (RD: Requirements Development) エンジニアリング 3
技術解 (TS: Technical Solution) エンジニアリング 3
成果物統合 (PI: Product Integration) エンジニアリング 3
検証 (VER: Verification) エンジニアリング 3
妥当性確認 (VAL: Validation) エンジニアリング 3
組織プロセス重視 (OPF: Organizational Process Focus) プロセス管理 3
組織プロセス定義 (OPD: Organizational Process Definition) プロセス管理 3
組織トレーニング (OT: Organizational Training) プロセス管理 3
統合プロジェクト管理 (IPM: Integrated Project Management) プロジェクト管理 3
リスク管理 (RSKM: Risk Management) プロジェクト管理 3
決定分析と解決 (DAR: Decision Analysis and Resolution) 支援 3
組織プロセス実績 (OPP: Organizational Process Performance) プロセス管理 4
定量的プロジェクト管理 (QPM: Quantitative Project Management) プロジェクト管理 4
組織実績管理 (OPM: Organizational Performance Management) プロセス管理 5
原因分析と解決 (CAR: Causal Analysis and Resolution) 支援 5

論争

この節には独自研究が含まれているおそれがあります。問題箇所を検証し出典を追加して、記事の改善にご協力ください。議論はノートを参照してください。（2020年11月）

ソフトウェア業界内は多様でありまた気まぐれである。

あらゆるソフトウェア開発方法論には支持者と批判者が存在する。 CMMI (能力成熟度モデル統合) も例外ではない。

肯定的見解

批判的見解

CMMIレベル2、レベル3を達成することによる主な利点

高いCMMIレベルで評価された企業

世界中の非常に多くの情報技術企業が CMMI (能力成熟度モデル統合) とそのレベルに関心をもっている。 1999年6月にインドの Wipro Technologies 社が、SEI CMM レベル5を達成した世界で最初の情報技術サービス企業となった。 レベル5はCMMの最高の水準である。 毎年、世界中の多くの情報技術企業が CMMI の制度を導入し、自社の CMMI レベルを向上させている。 2006年現在、CMMI レベル5を達成した企業の約75%がインドに存在する企業である。 これらの企業の多くはバンガロール市に存在する[_要出典_]。

完全なリストは List of Published SCAMPI Appraisal Results を参照。 リストは、SEIだけでなく、英国の次のサイトhttp://www.pparegister.com/でも公開されている。

脚注

  1. ^ “Capability Maturity Model®Integration (CMMI®) Version 1.2 Overview (PDF)”. SEI (2006年). 2006年10月28日閲覧。
  2. ^ “What is CMMI? - Worldwide Adoption”. SEI (2006年). 2006年10月28日閲覧。
  3. ^ Crosby, Philip (1979). Quality is Free. Mc Graw Hill. ASIN B000K2M9MU. http://www.wppl.org/wphistory/PhilipCrosby/index.html
  4. ^ Crosby, Philip (1980). Quality is Free (paperback). Mc Graw Hill. ISBN 0-451-62585-4. http://www.wppl.org/wphistory/PhilipCrosby/index.html
  5. ^ “August 2002 edition of CMMI (PDF)”. CMU/SEI-2002-TR-011. SEI (2002年). 2006年10月28日閲覧。
  6. ^ Finkelstein, Anthony (2000年4月28日). “A Software Process Immaturity Model (PDF)”. University College London. 2006年10月28日閲覧。
  7. ^ Schorsch, Tom (1996年). “The Capability Im-Maturity Model”. The Air Force Institute of Technology. 2006年10月28日閲覧。

関連項目

ある企業が何らかの「エンタープライズレベル」の成熟度レベルを達成したと主張している場合、私たちは懐疑的になる必要がある。 達成したと主張するレベルが高ければ高いほど、より懐疑的になる必要がある。 多くの場合こうした主張はあるときに何らかのプロジェクトを自社で行うことを意図したマーケティング技術である。 その企業が実際に主張する水準のレベルを達成していることはほとんど無い[_要出典_]。

参考資料

出典は列挙するだけでなく、脚注などを用いてどの記述の情報源であるかを明記してください。記事の信頼性向上にご協力をお願いいたします。（2022年12月）

書籍

ウェブ

外部リンク

表 話 編 歴 ソフトウェア工学
分野 要求分析 システム解析 ソフトウェア設計 コンピュータプログラミング 形式手法 ソフトウェアテスト ソフトウェアデプロイメント ソフトウェア保守
コンセプト データモデリング エンタープライズアーキテクチャ プログラム仕様 モデリング言語 プログラミングパラダイム ソフトウェア ソフトウェアアーキテクチャ ソフトウェア開発方法論 ソフトウェア開発工程 ソフトウェア品質 ソフトウェア品質保証 ソフトウェア考古学（英語版） 構造化分析（英語版）
指向 アジャイル アスペクト指向 オブジェクト指向 オントロジー サービス指向 SDLC
モデル 開発モデル アジャイル 反復型 RUP スクラム スパイラルモデル ウォーターフォール・モデル XP Vモデル インクリメントモデル（英語版） プロトタイピングモデル 他のモデル オートモーティブスパイス CMMI データモデル 実体関連モデル 機能モデル 情報モデル メタモデル オブジェクトモデル（英語版） システムモデル（英語版） ビュー・モデル モデリング言語 IDEF UML
主な人物 ケント・ベック グラディ・ブーチ フレデリック・ブルックス バリー・ベーム（英語版） ピーター・チェン ウォード・カニンガム オーレ＝ヨハン・ダール トム・デマルコ マーティン・ファウラー アントニー・ホーア ワッツ・ハンフリー（英語版） マイケル・A・ジャクソン（英語版） イヴァー・ヤコブソン クレイグ・ラーマン（英語版） ジェームス・マーティン（英語版） バートランド・メイヤー デイビッド・パーナス ウィンストン・W・ロイス（英語版） コレット・ロラン（英語版） ジェームズ・ランボー ニクラウス・ヴィルト エドワード・ヨードン ビクター・バシリ（英語版）
関連項目 計算機科学 計算機工学 エンタープライズエンジニアリング 歴史（英語版） 経営管理論 プロジェクトマネジメント 品質マネジメント ソフトウェア人間工学 システム工学
カテゴリ コモンズ