【 SLCP ( Software Life Cycle Process ：ソフトウェアライフサイクルプロセス）の目的 】
ソフトウェア・ライフサイクルプロセスとは、ソフトウェア開発において、ソフトウェアの構想から廃棄に至るまでの一連のライフサイクルのことで、ソフトウェア品質保証を実行する際に非常に重要な要素です。
一般的に、ソフトウェアのライフサイクルプロセスは、「要求仕様定義」→「設計」→「プログラミング」→「テスト」→「運用」→「廃棄」のライフサイクルをたどるとされています。この一連のフローを通して、最終的にソフトウェア品質保証を実行します。
また、効率良いライフサイクルプロセスを実現するためには、プロセスごとのパフォーマンス管理を行い、パフォーマンスの向上を図ることが理想的であると言えます。
中でも一般に良く知られているソフトウェア・ライフサイクル・プロセスに、「ウォーターフォール・ライフサイクル」があります。これは、ソフトウェア開発方法論の1つで、最も基本的、一般的な開発モデルであり、その名前が示すとおり、水の流れのように、ライフサイクルのあるステップから次へ一方向に流れるプロセスです。そのプロセスは、「要求」「仕様」「分析」「設計」「プログラミング」「検査」「運用」といった形に分割されています。

【 SLCP-JCF2007 】
共通フレームとは、情報システムの企画から開発、運用、保守、廃棄にいたるライフサイクルにおいて、それらの各プロセスを明確にすることにより、関係者が「共通の言葉」で話すための「共通のものさし」を定義したものです。
コンピュータ・システムの開発において、システム取得者（ユーザー）とシステム供給者（ベンダ）の間で相互の役割や業務の範囲・内容、契約上の責任などに対する誤解がないように、双方に共通して利用できるよう用語や作業内容の標準化するために作られたガイドライン。
システム構築・運用の受発注において、契約上のトラブル防止、作業内容の確認、役割分担の明確化、社内作業標準の策定や人員計画、見積もり精度の向上、品質確保などに利用される。
共通フレームは、システムの構想・企画、開発、運用・保守、廃棄における標準的な作業の範囲とその内容・項目を分類したもので、実際のシステム開発・運用の作業や手順を定めたものではない。本来の目的は、実際の作業を共通フレームで策定するのではなく、ユーザー／ベンダ独自の開発方法・プロセスを、共通フレームの体系に対応させることにより、相互にどの役割を担っているのかを理解したり、異なるベンダの見積もりを比較したりすることである。
その内容は、ISO/IEC 12207 (JIS X 0160) に従い、システム開発に関連する作業を「プロセス」「アクティビティ」「タスク」「リスト」の4階層で表現。「プロセス」はシステム開発作業を役割の観点からまとめている。以下、プロセスの構成要素を「アクティビティ」、アクティビティの構成要素を「タスク」、タスクの構成要素を「リスト」というように、作業を細分化して表現している。共通フレーム2007におけるプロセスのレベルの構成は、次のとおり。

【 プロセス 】
それぞれの作業の役割のこと。
お互いに関連のある「アクティビティ」の集まりで、入力を出力に変えるもの。

【 アクティビティ 】
プロセス内の個々の作業のこと。

【 タスク 】
アクティビティ内の具体的実行または支援しなければならない作業のこと

【 リスト 】
タスクの作業の例示のこと

【 SLCP-JCF2013 】

1. 合意プロセス
   • 1.1 取得プロセス
     　　システムに関するニーズ、供給者の選定、契約、システムの受け入れなど
   • 1.2 供給プロセス
     　　ＲＦＰ（提案依頼書）の作成、契約、システム要件の決定、開発プロジェクト、納入と支援など
   • 1.3 合意・契約の変更管理プロセス
     　　変更要求の協議と合意、変更管理など
2. テクニカルプロセス
   組織及びプロジェクトの担当部門が技術的な決定及び行動を結果生じる利益を最適化し、リスクを軽減できるようにするアクティビティの定義をする。
   • 2.1 企画プロセス
     経営・事業の目的、目標を達成するために必要なシステムに関する要件の集合とシステム化の方針、及び、システムを実現するための実施計画を得る。
     • 2.1.1 システム化構想の立案プロセス
       経営課題を解決するするための新たな業務とシステムの構想を立案する。 経営上のニーズ・課題、事業・業務環境、現状分析、情報技術動向などを確認。対象となる業務の明確化と業務の新全体像の策定。システム化構想の承認、システム化推進体制の確立など。
     • 2.1.2 システム化計画の立案プロセス
       システム化構想を具体化するために、対象業務について運用や効果等の実現性を考慮したシステム化計画及びプロジェクト計画を具体化し、利害関係者の合意を得る。
       対象業務のシステム化による新業務モデル策定。その実現可能性と費用対効果の明確化。全体開発スケジュール、システム選定方針（ハード・ソフトの基本要件）の策定。プロジェクト推進体制の決定・目標の設定など。
   • 2.2 要件定義プロセス
     新たに構築するシステム化の範囲を明確にし、システムが持つべき要件を列挙・検討して利害関係者間で合意する。
     業務要件を実現するために必要なシステムの機能や，システムの開発方式，システムの運用手順，信頼性，安全性，セキュリティなど多様な要件がある。
     • 2.2.1 プロセス開始の準備
       要件の収集方法、文書化、合意及び承認などに関するルールの決定
     • 2.2.2 利害関係者の識別
       システムのライフサイクルの全期間を通して、どの工程でどの関係者が参画するのかを明確にする。一般消費者のように直接のコミュニケーションが困難な場合には、それを代表するものを選定する。
     • 2.2.3 要件の識別
       利害関係者から要件を引き出して、その要件を誤解がないように明確に定義する。漏れがないように抽出することが目的であり、要件の取捨選択をするものではない。
       要件には、機能要件と非機能要件がある。この段階で非機能要件も引き出す必要がある。
       ・業務要件を実現するために必要な機能に関する要件
       ・それ以外の機能に関する要件（非機能要件）－品質特性、技術要件、運用・操作要件
       などがある。（参照：「非機能要求グレード利用ガイド」）
       このアクティビティは次のタスクで構成される。
       
       • 2.2.3.1 要件の抽出
       • 2.2.3.2 制約条件の定義（必ず必要となる条件を明確にする）
       • 2.2.3.3 代表的活動順序の定義
         （システムがどのように動作するかをシナリオ化して、必要となる要件を探す）
       • 2.2.3.4 利用者とシステム間の相互作用の識別
       • 2.2.3.5 システムの使用が周辺に及ぼす影響への対処
     • 2.2.4 要件の評価
       「要件の識別」を確認して、矛盾点や曖昧点をなくし、一貫性のある要件群として整理する。そして、実現可能性や重要度により要件に優先順位をつける。
     • 2.2.5 要件の合意
       評価の結果、システムに組み入れる要件を策定して、利害関係者に示し合意を得る。
     • 2.2.6 要件の記録
       合意した要件を文書化し、ライフサイクルを通して管理できるようにする。

【 CMMI 】(Capability Maturity Model Integration)
CMMIとは、米カーネギーメロン大学ソフトウェア工学研究所が公表したソフトウェア開発プロセスの改善モデルとアセスメント手法であるCMM（Capability Maturity Model）に、有識者の意見や多くのプロセス改善事例を反映させて作成された新しい能力成熟度モデルのこと。
CMMIではハードウェア、サービス業務、コミュニケーション、リーダーシップなどの人的側面も評価され、実務レベルの指標として利用可能となっている。両者をあわせてCMM/CMMIとも呼ばれる。組織や企業のソフトウェアプロセスの成熟度を示すことができ、組織におけるソフトウェア開発などの能力を向上させたり、能力を客観的に判断するための指標として利用されている。
成熟度はレベル1～5で表され、各レベルで持つべきプロセスを規定されている。

• レベル1:（初期段階） プロセスが確立されていない初期段階
  ソフトウェア開発においてルールや開発標準などがまったく統制されていない状態。
  
• レベル2:（反復可能な段階）特定のプロジェクトリーダーや技術者に依存している状態
  同種のソフトウェア開発を、組織の一部のチームなどが一定の水準で繰り返す方針や手順が確立されている状態。
  
• レベル3:（定義された段階）首尾一貫したプロセスを標準として持っている段階
  組織全体でソフトウエアの開発・保守の方針、ガイドライン、手順が確立されていて安定的に一定水準の品質のソフトウェアが開発できる状態。
  
• レベル4:（管理された段階）標準化されたプロセスを定量的に測定し、洗練化していく状態
  さらにそれらを定量化して計測・評価できる状態。
  
• レベル5:（最適化された段階）技術・要件環境の違いによって、標準プロセスを最適化して用いられる段階
  組織が自発的に開発行為などの改善を行える段階を指す。
  

実際には、多くのソフトウェア開発組織がレベル1または2の段階にあるといわれ、レベル3以上の組織は少ない。

1. 平成22年度秋期　問49　　JavaScript