プロジェクト アクティビティ
MSF for CMMI Process Improvement を最も効果的に使用するには、プロジェクトを通常は 4 ～ 8 週間の一連のイテレーションにまとめます。 これにより、要件および実装コストの変化によって生じるプロジェクトに対するリスクを軽減できます。 反復的なプロジェクト構造は、CMMI のリスク管理の要件を満たすうえで重要な要素になります。
プロジェクトの開始時
プロジェクトの開始
プロジェクトを開始するにあたり、まずプロジェクト ビジョンを定義します。これは、プロジェクトで製品をリリースしたときにユーザーが実行できるようになる機能をまとめたものです。
また、チーム、インフラストラクチャ、およびその他のリソースを設定し、開発プロセスを決定します。
詳細については、「プロジェクトの開始」を参照してください。
最初のプロジェクト計画
プロジェクト計画には、次のアクティビティが含まれます。
計画を立てられるように、要件を細部まで十分に分析する。 この分析では、要求モデルやストーリーボードなど、作業システムの構想に役立つツールを使用することもできます。
システムのデザインまたはアーキテクチャの全体像をまとめる。 チーム メンバーには馴染みのないプラットフォームでの作業を伴う場合は、少し試してみる時間を設ける必要があります。 初期のイテレーションでは開発に時間がかかります。
開発を大まかに見積もることができる一連のインクリメンタルな製品要件として要件をキャストする。 汎用的な要件と製品要件の違いは重要であるため、これは重要なアクティビティです。 詳細については、「要件の開発」を参照してください。
イテレーションに対する製品要件の最初の割り当てを行う。
リリースの日付を設定する。
計画と要求モデルは、プロジェクト期間を通じて見直され調整されていきます。 正しく機能するソフトウェアのデモを早い段階で行うことによって要件を改善できるようにすることも、反復開発の目的の 1 つです。
最初のプロジェクト計画はイテレーション 0 で行います。
詳細については、「プロジェクト計画 (CMMI)」を参照してください。
既存の製品の精査
プロジェクトによっては、既存の製品を更新することが目的である場合もあります。 この場合、チームがその製品に慣れていなければ、イテレーション 0 のアクティビティはコードの精査になります。 以降のイテレーションの各開発タスクでも、特定の場所のコードを理解したり、コードの変更による結果をトレースしたりすることが必要になります。
詳細については、「コードのビジュアル化」を参照してください。
プロジェクト期間中
計画はプロジェクト期間を通じて見直され、変更される可能性があります。
プロジェクト計画に関連するいくつかのアクティビティは、プロジェクト期間を通じて定期的に実行されます。これらは通常、各イテレーションの終盤に行われます。
検証
顧客またはビジネス上の利害関係者に対し、イテレーション期間中に開発したソフトウェアのデモを行います。 可能であれば、試したり実際のコンテキストである程度使用したりできるようにリリースします。
十分な時間を置いてから、会議を開いてユーザー フィードバックを確認します。 フィードバックは、変更要求の生成に使用します。
詳細については、「Validation」を参照してください。
リスク管理
悪影響を及ぼす可能性がある問題の発生確率と影響を確認し、リスクを軽減するための措置を講じます。 詳細については、「リスクの管理」を参照してください。
変更管理
変更要求の作業項目を使用して、ビジネス上の利害関係者から示された要件の変更を記録できます。 これらは、ビジネス上のコンテキストの変更のほか、初期のバージョンの製品のデモおよびトライアルからも発生することがあります。 これらの変更は、ビジネス上の目的に対する製品の適合性を高めることができるので役立ちます。 この効果もインクリメンタル開発の目的の 1 つです。
プロジェクト チームによっては、変更が要求されたときに製品要件の作業項目を調整し、独立した作業項目を使用しないチームもあります。 しかし、変更要求の作業項目を使用すると、プロジェクトの後半でそれまでに行われた変更の数と性質を確認できるという利点があります。 その情報を基に、以降のプロセスまたはアーキテクチャを改善することができます。
変更要求は、製品計画レビューの入力として使用します。
詳細については、「変更の管理」を参照してください。
製品計画レビュー
各イテレーションを計画する前に、製品計画レビューを行います。 プロジェクト計画で製品要件をイテレーションに割り当てます。
計画は、主に 2 つの理由で変更されます。
要件の変更。
開発者による見積もりの変更。 プロジェクトが進むにつれて、開発チームは、以降の機能を実装するために必要な作業をより正確に見積もることができるようになります。 場合によっては、一部の機能が前のイテレーションから延期され、計画に機能が追加されることもあります。
どちらの種類の変更も、後期のイテレーションになるほど頻度が低くなります。
製品要件の派生元の要求モデルを変更します。
イテレーションに対する要件の割り当てを変更します。 最初の計画のアクティビティと同様に、ビジネス上の利害関係者が優先度を決め、開発チームが見積もりを提示し、会議を行って各イテレーションに対する機能の割り当てを調整します。
詳細については、「プロジェクト計画 (CMMI)」を参照してください。
製品のメジャー リリース前
製品の開発にかかわるアクティビティは、その種類によって異なるため、ここでは扱いません。
ソフトウェア開発の後期のイテレーションに関しては、次の点を考慮してください。
予想外の問題が発生しないようにするために、デザインの大幅な変更は行わない。
トリアージ会議における変更とバグの水準を引き上げる。 変更およびバグ修正が提案されても、製品の使用性および目的に対する製品の適合性に大きな影響を及ぼすもの以外は却下します。
テスト カバレッジを高めること、および手動テストを実行することにリソースを投入する。