メモリリーク
メモリリーク (英: memory leak) とは、プログラミングにおけるバグの一種。プログラムが確保したメモリの一部、または全部を解放するのを忘れ、確保したままになってしまうことを言う。プログラマによる単純なミスやプログラムの論理的欠陥によって発生することが多い。
[参考：Wikipedia]
リソースリーク
リソースリーク (英: resource leak) とは、メモリリークをファイルやネットワーク接続、OS、ハードウェアなど一般のリソースに拡張した概念である。
例えば、一般的なOS環境でファイルへの読み書きをする場合、最初にファイルを開く処理が必要であり、これはメモリでいえば確保する処理にあたる。ファイルに対する処理が終了した時には、ファイルを閉じ、該当ファイルの使用権をOSに返却する処理が必要であり、これはメモリを解放する処理にあたる。通例、ファイルを閉じることで自動的にストリームがフラッシュされ、変更内容も反映（コミット）される。このとき、ファイルを閉じる処理を忘れて、不要なファイルがいつまでも開いた状態にあれば、リソースリークが発生したことになる。ユーザーが他のプログラムでそのファイルを開こうとしても失敗したり、ファイルを削除しようとしても失敗したり、などの原因不明のエラーに悩まされることになる。ほとんどの場合、リソースリークを起こしたプログラムが終了すれば、OSによって正常な状態に復帰されるが、ファイルを閉じるための正常な処理を経ていない場合、ファイルへの変更内容が反映されないこともある。
Windowsでは標準のタスク マネージャーやProcess Explorerといったツールを使って、各プロセスが使用しているハンドルの数を監視することで、リソースリークを診断することが可能である。
C++ではデストラクタによるRAIIを活用することでリソースリークを防止できる。JavaやC#のファイナライザはフェイルセーフとしての役目しか期待できないが、Javaのtry-with-resources文や、C#のusing文といった、C++のデストラクタによるRAIIに類似した機能を活用することで、リソースリークを防止できる。
[参考：Wikipedia]
キーワード関連：メモリリーク
もも
リバースエンジニアリング
リバースエンジニアリング（Reverse engineeringから。直訳すれば逆行工学という意味）とは、機械を分解したり、製品の動作を観察したり、ソフトウェアの動作を解析するなどして、製品の構造を分析し、そこから製造方法や動作原理、設計図などの仕様やソースコードなどを調査することを指す。
一般的に工業製品の多くは、設計図や仕様書の概略程度しか公表されておらず、詳細な動作の原理などは公表されていない。
また、コンピュータ・プログラムのソースコードも、近年優勢なオープンソース製品では公開されており、広く検証されているものも多いが、プロプライエタリ商品の場合は一部を除き非公開のため、情報セキュリティ上の危険が（仮に）存在していても秘密扱いの場合がほとんどである。そのため、様々な技術や創意工夫が用いられているこれら工業製品についての技術的情報に関しては、公開された文献から入手できない場合が大半であり、時には危険が存在しても「秘密として法的に保護」されていることすらある（各種製造物責任法などにより対抗手段もないでもないが）。
また仮に自社開発した製品であっても、それが古い製品の場合、当時の技術者がすでに退職・死亡してしまっていたり、設計図や仕様書の所在が不明になったり、あるいはそもそも最初から作成されていなかったなどの事情により、十分な情報を得ることが不可能な場合がある。
こういった事情とも絡んで、非公開情報を入手するために、ひいては、より優れた製品の開発のためにも従来の工業製品やソフトウェア製品をリバースエンジニアリングすることによって使用されている技術を分析、調査、確認することは、現場での製品開発において欠かせないプロセスの一つともなっている。
[参考：Wikipedia]
ソフトウェア測定法
ソフトウェア測定法（ソフトウェアそくていほう）またはソフトウェアメトリック（英: Software metric ）とは、ソフトウェアやその仕様の属性の尺度である。
定量的手法の威力は他の分野で証明されていたことから、計算機科学の分野でも同様の手法をソフトウェア開発に持ち込もうとする努力が続けられてきた。Tom DeMarco は DeMarco, T. (1982) Controlling Software Projects: Management, Measurement & Estimation, Yourdon Press, New York, USA, p3 の中で「測定できないものは制御できない」と記している。
典型的なソフトウェア測定法
- 成長オーダー（アルゴリズム解析、O記法など参照）
- ソースコードの行数
- 循環的複雑度
- ファンクションポイント法
- ソースコードの行当たりのバグ数
- コード網羅率
- 顧客要求仕様の行数
- クラスおよびインタフェースの個数
- Robert Cecil Martin のソフトウェアパッケージ測定法
- 凝集度
- 結合度
[参考：Wikipedia]
動的プログラム解析
動的プログラム解析 (Dynamic Program Analysis) とは、ソフトウェア解析手法の一種であり、実際のあるいは仮想のプロセッサでプログラムを実行して解析を行うこと。動的解析を効率よく行うために、標的プログラムに十分な量のテストケースを入力し、興味深い動作を起こす。コードカバレッジ等のソフトウェアテスト技法を用いて、起こりうる動作を記述したソースコードの箇所を十分な量見つけ出すことができる。ただし、実行中の一時的な命令の効果を過小評価してしまうことに気をつける必要がある。
静的解析と動的解析は相互に補完する技術である。例えば、マルチスレッド処理にまつわるバグは静的解析では見落とすおそれがあるが、動的解析では特定することができるため、Javaアプリケーションの解析には両方の解析手法が必要である。
静的解析と動的解析を組み合わせることで、バグ検出の精度と速度が高まり、競合状態やデッドロック、リソースリークなど、実行してみないと表面化しない処理を徹底的に解析することができる。 静的解析、動的解析で発見できることは、モデル検査、証明系でより効率的に発見できることもある。これらの機能を動的解析の中に組み込んでいる場合もある。
[参考：Wikipedia]
静的プログラム解析
静的コード解析 (static code analysis) または静的プログラム解析 (static program analysis)とは、コンピュータのソフトウェアの解析手法の一種であり、実行ファイルを実行することなく解析を行うこと。逆にソフトウェアを実行して行う解析を動的プログラム解析と呼ぶ。静的コード解析はソースコードに対して行われることが多く、少数ながらオブジェクトコードに対して行う場合もある。
ツールが行う静的コード解析の洗練度は、個々の文や宣言だけを検証するものから、プログラム全体を解析するものまで様々である。解析結果の利用も様々で、Lintのように単に指摘するだけのものから、形式手法を使ってそのプログラムの特性を数学的に証明する（仕様記述と振る舞いが一致しているかどうかを検証する）ものまである。
ソフトウェア測定法やリバースエンジニアリングも静的解析の一部とみなすこともある。特に組み込みシステムの開発において、ソフトウェア測定法と静的コード解析が品質向上の一助として活用されることが多くなっている。
静的解析の商業利用が増えているのは、重要なコンピュータシステムで使用されるソフトウェアの検証や潜在的なセキュリティホールを検出する必要性が増大したことを意味する。以下のような分野で、複雑さを増していくソフトウェアの品質向上に静的コード解析が使われている。
- 医療用ソフトウェア – アメリカ食品医薬品局 (FDA) は医療機器で静的コード解析が活用されているとしている。
- 原子力関連のソフトウェア – イギリスの Health and Safety Executive は原子炉保護系での静的コード解析の活用を推奨している。
VDC Research が行った調査（2012年）によれば、組み込みシステムのソフトウェア技術者の28.7%が静的コード解析ツールを既に使っており、39.7%が2年以内に使いたいと答えた。
アプリケーションのセキュリティの分野では Static Application Security Testing (SAST) という用語が使われている。
[参考：Wikipedia]
キーワード関連：動的プログラム解析、ソフトウェア測定法、リバースエンジニアリング
もも
もも
もも
もも
もも
もも
もも
もも
もも
ブラックボックステスト
ブラックボックステスト (black box test) は、プログラムの入出力だけに注目し仕様通りにプログラムが動作するか（もしくは仕様通りに動作しないか）をテストする。プログラムの入力が単一の値である場合は同値分割や限界値分析を、プログラムの入力が複数あり相互に影響を与えるような場合はディシジョンテーブルや原因結果グラフなどを用いて入力を決定する。大域変数の読み書き、通信、割り込みなどが処理中にある場合には、それらも入出力の一つとして扱う。
[参考：Wikipedia]
もも
上昇試験
単体テストおよび結合テストにおける手法の一つ。トップダウンテストとは逆に、単体テストが完了した下位モジュールから順に結合させてテストを行なう。この手法の利点は、数が多く独立性の高い下位モジュールから順に検証することで、開発とテストを平行して実施できることにある。一方で、システムの根幹となる上位モジュールで不具合が発見された場合、テストが完了したはずの下位モジュールも影響を受けるという欠点も持っている。単体試験を行う場合に、他の関数等を呼び出している関数を試験する場合に、呼出のない関数を試験してから、呼出をしている試験を行う場合にボトムアップテストになっている。
- ボトムアップテストを行う際には「テストドライバ」を用意しなければならない。
[参考：Wikipedia]
キーワード関連：下降試験
もも
もも
適合試験
OS、プログラミング言語、ネットワーク通信プロトコル、データベースなどソフトウェアを動かすための基本的なプラットフォームが、仕様に適合しているかどうかを確認する検証試験 (verification test)。OSの国際規格の一つであるPOSIXでは、 が適合試験のソースコードを公開している。 自動車用OSの国際規格OSEKでは、MODISTARC (Methods and tools for the validation of OSEK/VDX based distributed architectures) がある。 TOPPERS OSでは、TTSP (TOPPERS Test Suite Package) というテスト環境を提供し適合テスト等を実施しやすくしている。 プラットフォームの適合試験を実施せずに、アプリケーションソフトウェアの試験を実施すると、プラットフォーム仕様の変化に対応できていないことがある。
[参考：Wikipedia]
もも
システムテスト
プログラムを単独ではなく、他のプログラムやハードウェア、通信ネットワーク、データベースなどと組み合わせて実施するテスト。開発環境と実行環境が異なる場合には、実際の実行環境を使って行うこともある。顧客にしか実際の実行環境がない場合には、顧客環境で行う場合がある。実際の環境を利用することが高価であったり時間がかかる場合には、模擬試験環境 (simulator) を作成して実施することがある。この場合には、模擬環境のシステム試験、実環境でのシステム試験と区分する。模擬環境では、複数の事象を同時に発生させることが難しかったり、逆に実環境ではありえない事象を発生させることができなかったり、それぞれの短所・長所を見極めて試験を実施する。エンタープライズ系と組込みソフトウェアで本質的な違いがあるわけではなく、OS、言語、ネットワーク、データベース、接続機器数の違いが大きい。
[参考：Wikipedia]
統合試験
統合試験 (integration testing) は、単体試験が完了したプログラムを組み合わせて行う試験である。プログラムのどの部分から組み合わせていくかで、トップダウンテスト (top down test) とボトムアップテスト (bottom up test) に分けることができる。「Integration Testing」の略である「IT」と呼ぶことがある。また、結合テストと呼ぶ場合もある。 統合試験とシステム試験を分ける場合もある。統合試験とシステム試験を分ける場合に、模擬試験 (simulation) を統合試験に分類する場合と、システム試験に分類する場合がある。
[参考：Wikipedia]
単体試験
単体試験 (unit test) は、関数、メソッドなどの小さな単位で行うテストのことである。単体テストは、関数の場合には基本はブラックボックステストである。ブラックボックステストが済んだものの品質を確保するためにホワイトボックステストを行う。「Unit Testing」の略である「UT」と呼ぶことがある。また、開発現場によっては「CT（和製: Coding Test）」や「PT（和製: Program Test）」と略すこともある。
単体試験の道具としてJavaではテスティングフレームワークJUnitが有名である。これはJava専用である。他の言語にも同様のものがあり、それらを総称してxUnitと呼んでいる。
[参考：Wikipedia]
もも
性能試験
性能試験は、ソフトウェアシステムの性能を測り、必要な性能が出ることを確かめる試験である。入力をどれだけ受付けるか、どれだけの出力が可能か。通信経路数・通信速度、処理件数などプログラム単体では問題が発生しなくても、通信、データベース、入出力 (I/O)、同時に起動するソフトウェアなどの高負荷、長時間使用などの条件下では性能が低下することがある。性能を確認する試験は、システムの性能に影響を与えないように測定する必要があるため、OSやミドルウェアなどでは性能を測定する効率的な計測方法を提供していることもある。 性能試験は、単体試験から実施する場合と統合試験から実施する場合とがある。 過負荷に対する性能試験をストレステストという。
[参考：Wikipedia]
もも
ソフトウェアレビュー
ソフトウェアプロジェクトの各工程において作成される成果物について、権限者や専門家が管理面ないし技術面から審査・評価・決裁・見直し・問題指摘などを行うこと。
ソフトウェアに関する主なレビューには、承認レビューと成果物レビューの2つがある。前者は契約やマネジメントで規定された正式な認証行為としてのレビューであり、後者はソフトウェア成果物に潜む問題の早期発見を図る品質活動としてのレビューである。このほかに作業状況を評価するレビュー、プロセス品質を評価するレビュー、採用技術の評価を行うレビュー、未経験者の教育を目的としたレビューなどがある。
[参考：ITmedia]
インスペクション
最も公式なソフトウェアレビュー。ソフトウェア中の問題を検出するために、事前に定められた観点で第三者が厳密にレビュー対象を点検して欠陥の指摘と認定を行い、その結果に基づいて対象の修正と開発プロセスの評価・改善を行う。
インスペクションは、事前に定められた手順とチェックリストに従って第三者がレビューを行う、最も形式的なレビュー手法である。レビュー対象にはソースコードのほかにプロジェクト計画・要求定義・基本設計・詳細設計の各フェイズにおける各種成果物が含まれ、上流工程から実施可能な欠陥未然防止技法になっている。
[参考：ITmedia]
キーワード関連：ソフトウェアレビュー
もも
もも
もも
キーワード駆動スクリプト
「キーワード駆動スクリプト」では、スクリプトの部品化、スクリプトとデータの分離を行った上で、さらにそれらの部品を、自然言語に近い「キーワード」として抽象化します。ドメインエキスパートやテストエンジニアは、それらのキーワードを使うことで、スクリプトの内部構造を意識せずに自動テストケースを記述できるようになります。
[参考：システムテスト自動化 標準ガイド]
データ駆動スクリプト
共有スクリプトでは一連の操作を分割することでスクリプトを部品化したのに対し、「データ駆動スクリプト」ではスクリプトとデータを分離します。これによって、「手順は同じだが、入力する値は異なる」テストケースを、1つのスクリプトと複数のデータのセットで実現することができます。
[参考：システムテスト自動化 標準ガイド]
共有スクリプト
「共有スクリプト」のアプローチでは、テストケース間で重複して現れるスクリプトを部品として切り出し、それらを複数のテストケースから呼び出すことで、テストスクリプトの保守性や可読性をさらに向上させることができます。また、部品同士を組み合わせた新しいテストケースを組み立てることもできるので、リニアスクリプトが抱えていた「線形」の問題から逃れられることになります。
[参考：システムテスト自動化 標準ガイド]
構造化スクリプティング
「構造化スクリプティング」では、分岐・反復といった、プログラミングの基本的な構造を使ってスクリプトを表現することで、スクリプトの保守性・可読性を向上させることができます。
ニアスクリプトや構造化スクリプティングのアプローチでは、複数のテストケースに共通の操作（たとえばログイン／ログアウト、特定の画面への遷移など）に対応するスクリプトがテストケースごとに現れるため、操作に変更が発生した場合、そのすべてを修正する必要があります。
[参考：システムテスト自動化 標準ガイド]
キーワード関連：ニアスクリプト
リニアスクリプト
「リニアスクリプト」は、キャプチャーリプレイツールで操作を記録することで自動生成されたスクリプトを、ほとんどそのまま使うものです。1つのテストケースが1つのテストスクリプトに対応するため、テストケースの数が10倍になればスクリプトの数も10倍と、「線形に（リニアに）」増加してしまいます。
[参考：システムテスト自動化 標準ガイド]
自動化テストスクリプティング技法
テストを自動実行するためのスクリプティングの「技法」として、5つのアプローチがあります。
①リニアスクリプト
②構造化スクリプティング
③共有スクリプト
④ データ駆動スクリプト
⑤キーワード駆動スクリプト
[参考：システムテスト自動化 標準ガイド]
キーワード関連：リニアスクリプト、構造化スクリプティング、共有スクリプト、データ駆動スクリプト、キーワード駆動スクリプト
キーワード駆動テスト
キーワド駆動テストは、テストの自動化を行うときや、自動化のフレームワークの開発のときに用いられることの多い方法論です。
しかし、キーワード駆動テスト自体は自動化ためにだけ意味のあることではなく、自動化されていない、または自動化の予定がない場合でも有効な手段となります。
キーワード駆動テストはテスト用フレームワークで、ファンクションテスト用スクリプトの開発と、テストケースまたはワークフローの作成とを別々に行う事ができます。テストする特別なファンクションを表すキーワードやアクションワードを使用します。それらは各キーワード（データ）用の引数と一緒に外部データ表内にあります。
このプロセスはデータ駆動テストと似ていますが、純粋にデータだけを入力するのではなく、キーワードと関連するデータを一緒にテスト実行ドライバに入力します。
ISO/IEC/IEEE 29119
ISO/IEC/IEEE 29119は、「ソフトウェアテストの国際規格」です。
・本規格で提示されているテストの考え方（プロセス、文書、テスト技法）は、国際的に通用するものである
・あらゆるソフトウェア組織に適用可能である
・あらゆるソフトウェア開発に適用可能である
もも
ビヘイビア駆動開発
テスト駆動開発で記述されるテストケースは、作成したプログラムの動作が正しいかどうかを検証するために行う「テスト」である。テストであるという点は同一であるが、加えて、これから作成しようとするプログラムに期待される「振る舞い」や「制約条件」、つまり「要求仕様」に近い形で、自然言語を併記しながらテストコードを記述する。テストフレームワークのメソッド名も自然言語（英語など）に近い形をとっている。
テストコードの可読性があがる上、テストコードが要求仕様となりうる。要求仕様からテストコードを起こす際も、スムーズにコードに移行しやすい。
BDDではスペック（仕様）とテストは限りなく近い物である。従って、テスト駆動開発における「テストファースト」は、BDDにおいては「スペックファースト」となり、スペックを作ってから実装するという、より自然な形でのプログラム製作を実現している。
いくつかのテストフレームワークは、
- アプリケーションの振る舞いを記述するストーリーフレームワーク
- オブジェクトの振る舞いを記述するスペックフレームワーク
の2種類を含む。
[参考：Wikipedia]
エクストリーム・プログラミング
エクストリーム・プログラミング、XP（英: extreme programming）は、ケント・ベックらによって定式化され、提唱されているソフトウェア開発手法である。柔軟性の高い開発手法であるため、難易度の高い開発やビジネス上の要求が刻々と変わるような状況に向いた開発手法である。事前計画よりも柔軟性を重視する。1999年に書籍『XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法』によって発表された。
XPは、軽量開発手法あるいはアジャイルソフトウェア開発手法と呼ばれる、同種の開発手法のなかで代表的なものである。柔軟性の高い開発手法であるが、古典的には開発が進むにつれ変更コストは大きくなると言うことを前提に開発手法が構築されているのに対して、自動テストを導入するなど様々な対策をすることにより開発が進んでも変更コストが大きくならないような工夫を持ち込むことにより、変更に対する柔軟性を実現している。この変更コストが増大しないという前提が破綻すると、この手法も破綻する。
XPは比較的少人数の開発にもっとも適用しやすく、5つの価値と19の具体的なプラクティス（実践）が定義されている。XPはドキュメントよりもソースコードを、組織的開発の歯車となることよりも、個人の責任と勇気を重んじる人間中心の開発プロセスであるとしている。
[参考：Wikipedia]
アジャイルソフトウェア開発
アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している
[参考：Wikipedia]
もも
もも
B-Method
B-Methodとは、AMN（Abstract Machine Notation）という仕様記述言語（兼プログラミング言語）を中心とした形式手法に基づいたソフトウェア開発手法である。B-Method で使用する形式手法やそのツール群は単に B と呼ぶ。
Jean-Raymond Abrial を中心としてフランスおよびイギリスで開発された。Abrial の開発したZ言語とも関連しており、仕様からのプログラミング言語コード作成をサポートしている。ヨーロッパでは、大規模なインフラシステムで利用されており（パリのメトロ14号線など）、産業界の注目を集めつつある。堅牢で商業利用可能なツールが提供されており、仕様記述、設計、検証、ソースコード生成が可能である。
Z言語に比較して抽象化レベルが低く、単なる形式仕様記述というよりもコードへの詳細化に重きを置いている。そのため、B で書かれた仕様はZ言語の場合よりも実装が容易である。特にそのために様々なツール群が用意されている。
[参考：Wikipedia]
テスト駆動開発
テスト駆動開発 (てすとくどうかいはつ、test-driven development; TDD) とは、プログラム開発手法の一種で、プログラムに必要な各機能について、最初にテストを書き（これをテストファーストと言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、という短い工程を繰り返すスタイルである。多くのアジャイルソフトウェア開発手法、例えばエクストリーム・プログラミングにおいて強く推奨されている。近年はビヘイビア駆動開発へと発展を遂げている。
[参考：Wikipedia]
キーワード関連：アジャイルソフトウェア開発、エクストリーム・プログラミング、ビヘイビア駆動開発
もも
もも
ISO/IEC 15504
ISO/IEC 15504 は，世の中に存在するプロセス診断のモデルや方法についての枠組み（フレームワーク）であって特定のモデルだけに適用できる標準規格ではない。その主題は組織の運営能力と作業（プロセス）定義構造に基づいた診断(アセスメント）である。ISO/IEC 15504は 、完結した方法論を網羅せず，いろいろな方法論の共通部分だけを規定している。例示としてのモデルの一つ第5部(Part5)は、ソフトウェア事業（プロジェクト）で発生しうる活動の枠組みであるソフトウェアライフサイクルプロセス(ISO/IEC 12207: JIS X 0160)に対して、やっていてよかった指標（プラクティス）を示している。第6部(Part6)は、システムライフサイクルプロセス(ISO/IEC 15288: JIS X 0170)に対するモデルである。モデルに記載していることはやっていてよかったという過去の知見である。実施すべきものとしているわけではない。作業生産物(work product)も例である。紙であることを明示しているものは少ない。ISO/IEC 15504 は診断員(assessor)が対象の入力と出力に関して診断の前から分かっていること、面談の結果や証拠を分類し、作業の能力を判定する。診断のやり方は調達を目的として外部から観察する方法と、改善を目的として内部で作業をしている人が判断する方法がある。
[参考：Wikipedia]
もも
ISO/IEC 12207
ISO/IEC 12207 (Systems and software engineering — Software life cycle processes) とは、ソフトウェアのライフサイクル全般についての標準である。国際標準化機構 (ISO) と国際電気標準会議 (IEC) の合同技術委員会 (JTC 1) が1995年に策定した。ソフトウェアの開発や保守に関わる活動全般の標準を定義することを目的としている。翻訳が、日本工業規格 JIS X 0160（ソフトウェアライフサイクルプロセス）になっている。
ISO/IEC 12207 ではソフトウェアのライフサイクルを定義しており、システム上のサービスの入手や構成に関わる活動やプロセスも含まれる。各プロセスには必ずその出力となるものが定義されている。実際には 23種類のプロセス、95種類の活動、325種類のタスク、224種類の出力（成果物）が定義されている。
この標準の主な目的は、ソフトウェアの開発や保守に関わる様々なステークホルダー（購入者、提供者、開発者、保守者、操作者、管理者、技術者）に共通の構造を提供し、相互のコミュニケーションを円滑にすることである。そのような共通の言語はうまく定義されたプロセスで確立される。標準自体の構造は柔軟でモジュール性があり、必要な人が必要な部分だけを採用することができるようになっている。この標準の2つの基本原則は、モジュール性と信頼性である。モジュール性とは、定義されたプロセス間の結合度が最小で凝集度が最大となっていることを意味する。信頼性とは、各プロセスの信頼性を確立し、標準を応用したプロジェクトに多くの人々が法的に参加できるものにすることである。
プロセス、活動、タスクはソフトウェアプロジェクトに適用可能である。プロセスは3種類に分類されている。
基本プロセス
購入プロセス（発注プロセス）、提供プロセス、開発プロセス、運用プロセス、保守プロセス
サポートプロセス
文書化プロセス、構成プロセス、品質保証プロセス、検証プロセス、評価プロセス、ジョイントレビュープロセス、報告プロセス、問題解決プロセス
組織プロセス
管理プロセス、基盤プロセス、改善プロセス、訓練プロセス
[参考：Wikipedia]
プロセスモデル
プロセスモデル（英: process model）とは、何らかのプロセス（過程、工程）の模型(モデル)である。 化学工学はプロセス産業と呼ぶように、プロセスモデルが処理モデルである。 ビジネスプロセスモデルとは、企業の仕事の仕方のモデルである。 コンピュータでは、処理方法がプロセスモデルである。並列処理の方式などがある。 ソフトウェアプロセスは、ソフトウェアを設計し、利用し、廃棄する流れの一つの視点を提供するものであり、人の作業とコンピュータの処理を含む。
コレット・ローランドはプロセスモデルを次のように定義している:
同じ性質を持つプロセスは1つのプロセスモデルに分類する。つまり、プロセスモデルはプロセスの抽象記述である。プロセスモデルが抽象的であるとすれば、個々のプロセスは実体化したものである。
プロセスモデルは様々な開発に繰り返し利用するため、その実体は多数存在する。 […] プロセスモデルは「物事をどのようにするか（するべきか/しなければならないか）」を記述したものである。
プロセスモデルは、プロセスがどのようになるかを仮定し、予測するものである。仮定を立てるためには、前提条件が必要となり、時間的な条件、論理的な条件または空間的条件を設定する。時間的条件には初期条件，終了条件がある。論理的な条件には事前条件，事後条件，不変条件がある。空間的条件には、境界条件がある。 プロセスがこうあるべきだという方針は、常に状況（前提条件の変化）に応じて改善していくものである。
プロセスモデルの分類：
①適用分野による分類
[Dowson1988]は、以下の4つの異なる意味でプロセスモデルという用語が使われているとした:
活動指向: ある製品を定義する目的の下で関連する活動群。目標達成までの半順序的ステップ群。[Feiler1993][5]
製品指向: 製品を目標のレベルにするための一連の活動。
決定指向: 特定の製品定義のために必要な決定の集合。
文脈指向: 製品の改良をもたらす一連の文脈(コンテキスト)の集合。
②レベルによる分類
ローランドによれば、プロセスは以下のように分類され、それぞれモデル化手法が異なる。
戦略的プロセス
代替案を検討し、それを実行する計画を立案することもある。
高度な活動であり、代替案の選択も重要な選択となる。
戦術的プロセス
計画の実行を支援する。
実際の計画実行により近く、計画の詳細化を行う。
実装プロセス
最も下位のプロセス。
計画を実施するための詳細を扱う。
③粒度による分類
粒度とは、プロセスモデルの詳細さのレベルを意味する。
「粒度は提供すべき手引き、説明、手順の種類に影響を与える。粒度が粗い場合、あまり具体化しない。粒度が細かい場合、より詳細なものを提供する。必要とされる粒度は状況に依存する」[Rolland1998]
顧客や経営者は粗い粒度のプロセス記述を要求する傾向があり、意思決定のための概略的情報を必要とする。一方、ソフトウェア技術者やユーザーは細かい粒度のプロセスモデルを必要とし、それによって具体的手順を知ったり、個々の人々の依存関係が明らかになる。
細かい粒度のモデル記述法もあるが、粗い粒度のモデル記述法の方が古くから存在する。プロセスモデルは理想的にはあらゆる粒度に対応できるのが望ましい（例えば、Process Weaver [Fernström1991]）[Rolland1998]。
④柔軟性による分類
プロセスモデルは何らかの予測を行うが、実際に起きることは予測通りではない[Rolland1999]。従って、フレームワークを実際の状況に合わせて修正することでモデルの価値が向上する。このようなフレームワークの研究を Situational Method Engineering と呼ぶ。
方式を構築する手法は柔軟性の低いものから高いものまである[Harmsen1994]。
[参考：Wikipedia]
CMMIの成熟度レベル
レベル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では、プロセスはプロセスにおける変動に共通する原因に取り組むこととプロセスを変更し (すなわちプロセスの遂行能力の平均値を変更する) その遂行能力を向上させ (統計的確率を修整しつつ) あらかじめ定めた定量的なプロセス改善目標を達成できるようにすることと関連している。
[参考：Wikipedia]
CMMI
CMMIは、プロセスの評価や改善をすすめるための枠組みであり、段階表現と連続表現の2つの表現方法がある。段階表現では、組織の実施プロセスを評価し、レベル1からレベル5までの5段階の成熟度レベルを（組織に対して）出すことができる。連続表現では、各プロセスを評価し、レベル0からレベル3までの4段階の能力度レベルを（プロセスごとに）出すことができる。（以前はレベル0から5までの6段階であったが、v1.3から4段階に改訂された。）これらのレベルは、評価の対象となるプロセスの制度化の程度に応じて、等級づけられている。
評価の対象となる領域はさまざまであり次のようなものがある。
ソフトウェア開発
システム開発
プロジェクト管理
リスク管理
システム調達、情報技術 (IT) サービス
パーソナルマネジメント
CMMIでは5つの成熟度レベルを厳密に定義している。
レベル1は、非常に未熟で混沌とした開発プロセスである。
レベル5は、非常に成熟した高品質を実現する開発プロセスである。
1998年の時点では、ソフトウェア開発を行う組織の75%がレベル1であると推定されている (参考)。
CMMIの前身にあたるCMMは、1980年代半ばにアメリカ合衆国のピッツバーグにあるカーネギーメロン大学 (CMU) のソフトウェア工学研究所 (SEI; Software Engineering Institute) で開発された。 CMMIは、航空電子工学ソフトウェアの開発や北アメリカ、欧州、アジア、オーストラリア、南アメリカ、アフリカなどの国々の政府主体で行うプロジェクトなどで、広く採用されてきており、こうした国々でCMMIに対する官民の関心は高い[2] 。 現在、いくつかの国々の省庁は、ソフトウェア開発契約に際して業者にレベル3の基準を達成しかつ運用できていることを必須としている。 また日本においても、ソフトウェアを発注する官公庁や民間組織がCMMIを採用し、一方でソフトウェア開発を担う組織がCMMIの指針に即して自らのソフトウェア開発プロセスを改善する動きが、徐々に広がりつつある。
[参考：Wikipedia]
キーワード関連：CMMIの成熟度レベル
開発工程モデル
ここ数十年のソフトウェア工学の目標のひとつとして、反復可能かつ予測可能な開発工程の方法論を見出し、生産性と品質を向上させるということが挙げられる。一部の人々はソフトウェア開発の一見して手に負えないタスクを体系化し、形式化しようとしてきた。他の人々はソフトウェア開発にプロジェクトマネジメント手法を適用した。プロジェクトマネジメントを適用しなければ、ソフトウェアプロジェクトは簡単に納期に遅れたり、予算を超過したりする。多くのソフトウェアプロジェクトは実際に機能/コスト/納期に問題を抱えており、プロジェクトマネジメントの困難さを証明している。
①ウォーターフォール型
最もよく知られた従来型の開発工程モデルはウォーターフォール・モデルである。このモデルでは、開発者は上述の工程（局面、フェーズ）を順番に行う。要求仕様を作成し、それを分析し、解決法を設計し、そのためのソフトウェアフレームワークのアーキテクチャを作り、コードを書き、評価し（単体テスト→システムテストの順）、配備し、保守する。各工程が完了すると、次の工程に進むことができる。ちょうど、家の骨組みを組み上げてから土台を変更できないというのと同じ考え方である。
ウォーターフォール・モデルでは上流工程での間違いや仕様変更を後から訂正・反映することを考慮していないと考えられがちだが、これは誤解である。これは要求管理に変更制御を含めるかどうかという問題である。
この手法は特に大規模なシステム開発や危険の大きいプロジェクト（軍需関係の契約など）で使われている。各工程ごとに契約・入札が行われる場合もある。
大規模なシステム開発ではサブシステム化も併用し、各サブシステムで時期をずらしてウォーターフォール・モデルを採用する事で、先行するサブシステムで発見した問題を後続のサブシステムでは早い段階の工程で取り入れたり、各工程の要員（設計者、プログラマ、テスターなど）や主要イベント（プロジェクト立ち上げ、レビュー、検収、研修、本番稼動など）の平準化を図る場合も多い。また各工程の内部では後述のスパイラルモデルや反復型開発を組み合わせる場合もある。
ウォーターフォールの問題は、要求分析と要求管理についての技術的未熟さから生じることが多い。さらに言えば、開発工程の弱点の把握不足と開発者が問題を理解せずにコーディングを開始してしまうことからも問題が生じる。また、しばしば省略されがちな工程として顧客と開発者の間での共同レビューがある。開発者は危険を承知で設計を進めて開発するが、その設計は最終的には Critical Design Review（最終設計審査）というマイルストーンでチェックを受けることになる。この手法への批判はソフトウェア工学者よりも実際の技術者から出てくることが多い。批判者は WISCY（Why Isn’t Someone coding yet ?）アプローチなどを信奉している。
②反復型
反復型開発は、ソフトウェアを徐々に開発していく手法であり、問題点や前提の間違いを早期に検出して大きな問題となるのを防ぐ。反復型開発はパッケージでない商用ソフトウェア開発で好まれる。というのも、自分がソフトウェアに何を求めているかをうまく定義できない顧客の要求にも応えて開発していくことが可能だからである。
アジャイルソフトウェア開発は反復型開発からの派生手法である。アジャイルでは、従来よりも軽量で人間中心の視点を導入した。アジャイルでは計画よりもフィードバックを重視する。フィードバックは主にテスト（評価）と開発途中のソフトウェアを外部にリリースすることで得られる。
アジャイルソフトウェア開発は従来の方法論よりも効率的と思われる。少ない工数でより多くの機能を開発でき、品質の高いソフトウェアを開発できる。しかし、ビジネス的観点から見ると、長期的計画を立てるのが困難であるという問題がある。基本的に、必要な機能は開発されるが、それが何時になるのかは不明である。
エクストリーム・プログラミング(XP)は最も有名なアジャイル的手法である。XPでは工程が非常に短いステップに分割される。ウォーターフォール・モデルでは数ヶ月から数年かかる工程を1日から1週間の工程に分割するのである。まず、自動化されたテストを書き、その工程でのゴールを定める。次に（2人のプログラマにより）コーディングを行い、全部のテストをパスした段階でその工程が完了する。設計とアーキテクチャはリファクタリングによって生み出され、コーディングの後に完成する。設計はコーディング担当者が行う。設計とコードの統合を行う段階は他のアジャイルソフトウェア開発と同様である。不完全だが機能するシステムがユーザー（あるいはその一部、開発チームもユーザーの一部である）に配布され、評価される。その後、次に重要と思われる部分に関するテストが書かれ、次のサイクルが開始される。
反復型開発には独自の利点があるが、ソフトウェアアーキテクトはさらに信頼できるソフトウェア開発基盤を生み出そうとしている。そのような開発モデルの基盤には最前線の現場の分析とプロトタイピングが必要である。開発モデルは特定の設計パターンや実体関連図（ERD）に依存していることが多い。反復型開発はコストおよび品質で有利な長期的戦略を採用することにより、事前の基盤を必要としない。
反復型開発への批判は、これらの手法が顧客に対してソフトウェア開発に深く関わること、すなわち開発者的スキルと経験を要求することを問題にする。また、そうでなければこの手法のコストは増大する。それは「どういう家が欲しいか決めかねているなら、試しに私どもに建てさせて気に入るかどうか見てみてください。もし気に入らなかったら、取り壊して立て直します」と言っているようなものである。この批評は、反復型開発の要点を取り違えている。反復型開発では顧客からフィードバックを得るのに家全体を建てる必要はない。従来型の開発手法で実際の開発が始まる前に行っている要求分析と開発完了後に行っている評価を、反復型開発では全工程に分散させていると見ることができる。
実際、アジャイルのコミュニティでは要求仕様を固定せずにソフトウェアを改良していくという点で曲折があった。従来の手法ではこれは許されず、商業的にもナンセンスである。アジャイル的手法ではアーキテクチャの変更を迫るような新たな要求について、顧客が対価を支払わない場合、アジャイル的にプロジェクトは終了させられる。
これらの手法はウェブベースの技術の発展と共に開発されてきた。したがって、アーキテクチャとソリューションの機能のほとんどがアプリケーションのバックボーンに選ばれた技術で実現されていると仮定すると（つまり、ミドルウェアで実現されている）、これらの手法は実際には保守ライフサイクルと同義である。
リファクタリングは、設計を慎重に行って文書化することの代替案としてアジャイル・コミュニティが提案したものである。アーキテクチャ上の問題に対するリエンジニアリングへの代替案は提案されていない。どちらも比較するとコストがかかる。既存のコードへのリファクタリングを1回通して行うと 10% から 15% のコスト増となると言われている。しかし、この値に再評価やリグレッションテストも含んでいるかどうかは不明である。もちろん、既存のアーキテクチャを捨ててしまう方がさらにコストがかかる。実際、アジャイル的手法を利用した開発ではコスト問題に悩んでいるという調査結果がある(Software Development at Microsoft Observed)。ここでは、基本設計の管理よりもプログラミング担当者らによる定常的なリバースエンジニアリングが強調されている点に注意されたい。
テスト駆動開発（TDD）はアジャイル的手法から生まれた便利な手法だが、同時に問題もはらんでいる。TDD ではコードを書く前にそのコードに関する単体テストを書く必要がある。したがって、まずどういうコードを書くかを考え、それを書く前にその単体テストを書けるほど十分に詳細を決定しなければならない。アジャイルソフトウェア開発では簡単な設計からコードを書くのであるから、TDD をアジャイル的でない開発工程モデルに取り入れることはアジャイル的なものとは正反対となる。
3.形式手法
形式手法は要求/仕様記述/設計段階でのソフトウェア（およびハードウェア）問題への数学的対処法である。形式手法の例として、B-Method、ペトリネット、RAISE、VDM などがある。形式仕様記述もZ記法など様々な手法がある。より一般化すれば、有限状態機械のシステムを設計することでオートマトン理論を応用してアプリケーションの動作を解明する。
有限状態機械(FSM) に基づいた方法論で実行可能ソフトウェアの仕様記述ができ、従来的なコーディング工程を省くことができる（仮想有限状態機械およびイベント駆動有限状態機械）。
形式手法はアビオニクスソフトウェアなどの安全性が重要とされるソフトウェアでよく採用されている。DO178Bなどのソフトウェアの安全性保証標準規格では、形式手法の採用が義務付けられている（レベルAの場合）。
形式手法は開発工程に様々な形で入り込んできつつある（例えば、OCL、JML、モデル駆動型アーキテクチャなど）。
[参考：Wikipedia]
開発工程
1ソフトウェア要求分析
ソフトウェア製品を作るにあたっての最初のタスクは要求を引き出す・集めることである。顧客はソフトウェアに何をさせたいのかを知っているものである。しかし、その要求は不完全だったり、曖昧だったり、互いに矛盾していたりする。経験をつんだソフトウェア技術者はそれを聞き出して一貫性のある要求仕様に纏め上げる。
2.仕様記述
仕様記述は可能な限り厳密な方法で開発すべきソフトウェアを正確に記述するタスクである。安全性が重要なソフトウェアシステムでは、開発に先駆けて仕様記述を注意深く行うが、実際に最も成功している仕様記述とは、既存のアプリケーションを理解して改善するために書かれるものであろう。安定していなければならない外部インターフェイスにとって仕様記述は最も重要である。
3.ソフトウェアアーキテクチャ
ソフトウェアシステムのアーキテクチャとは、システムを抽象的に表現したものである。アーキテクチャはソフトウェアシステムが製品として要求に適合しているかを検証するのに使用される他、将来の追加要求に応えるためにも使用される。アーキテクチャ作成段階ではソフトウェアシステム間や他のソフトウェア製品間のインターフェイスも規定し、ハードウェアやオペレーティングシステムも規定する。
4.実装
設計からコードを作成する段階はソフトウェア開発において最も明白な工程であるが、必ずしも最大の工程とは限らない。
5.評価
特に複数の技術者が開発したコードを結合して行う評価はソフトウェア技術者が行う。
6.文書化
ソフトウェアの内部設計を文書化するタスクは重要だが、しばしば見過ごされている。これは将来の保守と改良に使用される。文書化は外部インターフェイスにとっては最も重要である。
[参考：Wikipedia]
プロセスとメタプロセス
プロセスとメタプロセスとは、
ソフトウェア開発組織の巨大化とともに開発工程に関する方法論が提案されるようになってきた。アメリカでは軍需での契約を獲得する条件としてプロセスモデルに基づいた評価が行われるため、それが方法論の発達を促したとも言える。ISO 12207 はプロジェクトのライフサイクルを選択・実装・監視する手法に関する標準規格である。
能力成熟度モデル(CMM) は主要なモデルの1つである。独自のアセスメントにより組織が自身で定義したプロセスにどれだけ忠実に従っているかを測る。このとき、そのプロセスの品質そのものやソフトウェア製品の品質は関与しない。CMM は徐々に拡張され能力成熟度モデル統合(CMMI) となった。ISO 9000 は形式的に構成されたプロセスとその文書に関する標準規格である。
ISO 15504 は、ソフトウェアプロセスのアセスメントのためのフレームワークであり、Software Process Improvement Capability Determination (SPICE) とも呼ばれる。この標準規格はプロセスを比較するための明確なモデルとなっている。SPICE も CMM や CMMI と同様に使われている。それは、ソフトウェア開発を管理/制御/誘導/監視するためのプロセスのモデルである。このモデルを使って、ソフトウェア開発において組織やプロジェクトチームが実際何をしているのかを測る。その情報を元に弱点を検出し、それを克服するよう改善する。同時に長所も探し出して、それを組織やチーム全体の共通の慣習にして継続させるようにしていく。
シックス・シグマはプロセス管理の方法論の一種であり、統計分析により企業の経営品質を測定し、それを向上させる。製造やサービスのプロセスでの問題点を検出して排除するのに使われる。最大許容欠陥発生率は百万回につき 3.4回である。しかし、シックス・シグマは製造業を対象としているため、ソフトウェア開発に適用するにはさらに研究が必要である。
[参考：Wikipedia]
ソフトウェア開発工程
ソフトウェア開発工程（ソフトウェアかいはつこうてい、Software Development Process）とは、ソフトウェア製品の開発の構造を意味する。ソフトウェアライフサイクル、ソフトウェア開発プロセス、ソフトウェアプロセスもほぼ同義語である。開発工程にはいくつかのモデルがあり、開発工程内の各種タスク・活動のための手法を提案している。
1 プロセスとメタプロセス
2 開発工程
3 開発工程モデル
[参考：Wikipedia]
PRINCE2
PRINCE2とは、イギリス商務局 (OGC) が開発したロプジェクトマネジメントの方法論の1つ。プロジェクトの管理面、組織面、制御面をカバーする。
1989年、イギリス政府の情報システムのプロジェクトマネジメントの標準として中央電子計算機局 (CCTA) が PRINCE を開発した。これは、すぐにIT向けにイギリス政府機関以外でも使われるようになった。1996年、より汎用的なプロジェクトマネジメント手法として PRINCE2 が発表された。PRINCE2 は徐々に知名度が上がり、イギリスでのプロジェクトマネジメントのデファクトスタンダードとなっている。また、イギリス以外の国々にもその利用が広がりつつある。
最新版は商務局が2005年にリリースしたもので、2008年9月を目指して改版作業中である。
「PRINCE2」という名称は OGC の商標であり、英語の「projects in controlled environments, 2nd version」に由来する。
[参考：Wikipedia]
Vモデル
Vモデル（V-Model）とは、IT製品開発の手法の一種。ドイツ政府と軍関係のプロジェクトで標準として採用されている。また、一般に利用可能であるため、様々な企業でも使われている。プロジェクトマネジメント手法としては、PRINCE2に匹敵する。また、システム開発やソフトウェア開発の手法としても使われている。
現在のバージョンは V-Model XT と呼ばれ、2005年2月に完成した（http://www.v-modell-xt.de）。能力成熟度モデル統合(CMMI)とは直接競合しない。CMMIは「何を」すべきかを示すものだが、Vモデルはそれに加えて「如何にして」「何時」「誰が」責任を持って行うかも示す。
Vモデルはドイツ政府関連のソフトウェア開発工程を規定するために開発された。ソフトウェア開発の中で行うべき活動とその成果物を規定している。Vモデルはソフトウェア開発のライフサイクルをグラフィカルに表現したものでもある。自動化されたシステム検証フレームワークとの関連でなされるステップを要約している。
仕様策定部分は主に次のような作業からなる:
1.ユーザー要求仕様
2.機能仕様
3.設計仕様（詳細仕様）
テスト実行部分は主に次のような作業からなる:
1.受け入れテスト
2.操作テスト
3.性能テスト
[参考：Wikipedia]
キーワード関連：PRINCE2、CMMI、ソフトウェア開発工程