作業:
|
目的
|
|
手順 | |
入力とする成果物: | 結果となる成果物: |
頻度: 反復ごとに 1 回 | |
役割: プロジェクト管理者 | |
ツール メンター: |
ワークフローの詳細: |
目的 | 役職、チーム、責任および階層の観点でプロジェクトの組織構造を定義する。 |
プロジェクトの組織構造の選択は、プロジェクト特性と、既存組織のポリシーのような外部制約に依存します。したがって、何が効果的 (あるいは実現可能) であるかは、状況に大きく依存するため、構造を規定するのは困難です。プロジェクト組織の形と大きさはフェーズを超えて変化するため、生きた文書であるソフトウェア開発計画書は、このような変化を反映して更新されていきます。
目的 | プロジェクトに必要なスタッフの数、タイプ (スキル、ドメイン)、経験および才幹を決定する。 |
プロジェクトの作業見積り、望ましいスケジュール、選択した組織構造、役割の配置に基づいて、プロジェクト管理者は、そのプロジェクトに必要な要員プロファイル (スタッフの延べ人数、必要なスキル) を決定します。プロジェクトの作業見積りは、当然ながらチーム規模、経験、スキルや才幹と無関係ではありません。おそらく、プロジェクト管理者は、作業見積もりの作成時にスタッフの能力などについて仮説を立てているはずです。COCOMO の見積もりモデル (「作業: フェーズと反復の計画」を参照) では、スタッフの能力と経験が主要な作業推進力になっています。したがって、(各種の COCOMO 作業推進力を調整した結果) 受け入れ可能な全作業および実現可能なスケジュールを選択すると、要員プロファイルが決まります。
場合によっては、プロジェクト管理者は利用可能な要員の人数とスキルを事前に把握しています。それら場合では、要員の規模とスキルの組み合わせが決まっており、プロジェクトの規模に変化がないとの前提に立てば、可変であるのはスケジュールだけです。
プロジェクト管理者は要員のレベルを急速に揃えようとして崩壊の危機を招いたり、要員を大幅に増員してスケジュールを極端に減らそうとすると、生産性に壊滅的な影響があり得ることも注意しなければなりません。
方向づけ期間中は、プロジェクト範囲の定義と境界付け、および開発企画書の作成に焦点をおきます。結果的に、チーム規模は小さく、プロジェクト管理者が 1 人、ソフトウェア アーキテクトが 1 人、また、特に要求を明確にするために概念の証明のプロトタイプが必要だったり、製品サポートを構築するために、おそらく 1 ~ 2 名の開発者が必要です。
推敲フェーズでは、主にアーキテクチャおよびアーキテクチャ プロトタイプに焦点がおかれます。結果として、初期の推敲フェーズの設計作業は、アーキテクチャ的側面に焦点がおかれます。クラスとクラス属性の詳細は、識別されたとしてもアーキテクチャ的には重要ではないので、ほとんど注意は払われません。この反復中では、作業のほとんどは、アーキテクチャ チームおよび指名されたプロトタイプ作成チームが行います。通常、プロトタイプ作成チームは、経験豊かなプログラマから構成されます。この時点で、非常に小規模な設計チームができあがり、一般的なメカニズムとテクノロジーに焦点がおかれます。テスト グループは、テスト環境の構築と、初期のユース ケースのテストに焦点を当てます。
アーキテクチャ チームのメンバーの選択には、細心の注意が必要です。このメンバーは、優れた分析スキルおよび設計スキルを備えているだけでなく、リーダーとしての資質も必要です。作成フェーズ中にアーキテクチャを規模の大きなチームに伝達する場合、アーキテクチャ チームのメンバーを作成チームに配置するとよいでしょう。チームのメンバーは、ソフトウェア工学の幅広い経験も備えている必要があります。ソフトウェア設計と実装、性能のチューニング、データベース管理、ネットワーク管理、および構成管理は、アーキテクチャ チームが備えていなければならない、主要なスキルを代表しています。
作成フェーズでは、システムに機能を増やしていきながら、システムのアーキテクチャ上の統合性を維持することを重視します。これには、アーキテクチャの改善 (推敲フェーズ後にアーキテクチャを「凍結」するのではなく「ベースライン」にする) および設計者と設計内容に目を光らせるアーキテクチャ チームが必要です。
アーキテクチャ チームは、開発チームの間に入り込んで、技術的な指導を行い、ほかの技術的指導者とグループ間の問題を調整します。作成チームは、割り当てられた機能の設計と実装の両方に責任があるため、設計と開発の両方の専門知識を備えた、複数機能にまたがったチームである必要があります。典型的には、作成チームは十分に定義したインターフェイスのある 1 つ以上のサブシステムを担当します。このようなインターフェイスに変更を加えたり、新サブシステムを追加した場合はアーキテクチャ上の変更となり、入念な検討が必要となります。サブシステム内であれば、このチームは適当な設計や実装を比較的自由に行えますが、複数のチームが同一の実装メカニズムを同時並行で作成しないよう、チーム間の意思疎通が必要です。
典型的には、設計チームはレイヤリングの区分に沿って横方向に組織されます。データベース インターフェイスを担当するチームもあれば、通信インフラストラクチャを担当するチームもあり、アプリケーション機能自体を集中的に担当するチームもあります。その結果として、「上位」レイヤのチームは、問題ドメインやユーザー インターフェイス設計または外部システムとのインターフェイスについての、より専門的な知識を必要とします。「下位」レイヤのチームは、実装技術により精通しています。これらのチーム構成は、これらの異なったスキルの需要を反映させるものでなければなりません。
テストでの第一の問題は、どの程度正式なテストを求められているかということです。次に問うのは、品質目標を達成し、かつ費用とスケジュールの観点から、納得のいく範囲内に収めるとしたら、どれだけのテストが可能かということです。あらゆる種類のテストを行うための予算のあるプロジェクトというのはまれです。普通は、プロジェクトがまかなえる範囲内でテスト レベルを選択しなければなりません。各テスト仕様は、検査し保守する必要があることを忘れないでください。多数のテスト仕様書を作る計画があっても、時間がなくなって計画を実装段階に持っていけないとしたら、プロジェクト チームの士気に悪影響を与えます。
特定のテスト チームを 1 つ作成します。テスト チームの内、最低 1 人は要求獲得チームから連れてくる必要があります。このテスト チームは次のテストを担当します。
テストは、単にテストの実行だけではないことを忘れないでください。テスト環境の準備も、テスト仕様書の作成と点検もテストの中に含まれます。
ユース ケースとシステム全体のテストは、別個のグループが担当すべきです。テストの実施だけでなく、テスト報告書も作成します。ユース ケースのテスト作業に関しては、各ユース ケースに対して責任を有する者が必ず 1 人存在するように要員を編成します。
プロジェクトが小規模なため、独立したグループがユース ケースをテストできない場合には、最低限、ユース ケースの設計の担当者がユース ケースのテストを担当しないように配慮します。
中規模および大規模プロジェクトでは、回帰テストを自動化します。この機能をサポートするには、テスト チームにプログラマが必要になります。反復開発中には、これはさらに重要になります。同じテスト セットを何度も再実行するのに膨大な労力を費やさないようにするためです。
移行フェーズでは、開発作業は完了しています。ベータ テストを実施して最終リリースを準備します。正しく作成段階が行われると、プロジェクト チームは開発担当者とテスト担当者の数を減らして、規模を縮小しはじめることができます。チーム編成は、製品のユーザーへの導入を担当するトレーナーやシステムのインフラ設定の専門家中心へと変更されていきます。
ソフトウェア アーキテクトまたはアーキテクチャ チームは「フォローアップ モード」で作業を行います。障害レポートを並べ替えたり、変更提案に優先順位を付けたり、アーキテクチャに損害を与えるおそれがあるので障害を修正しないように、という命令変更の手助けをします。移行フェーズには設計作業は減り、障害の修正または最終段階における拡張などに限定されます。
Rational Unified Process
|