作業:
|
目的
|
|
役割: 実装担当者 | |
頻度:\ \ 各反復段階で繰り返します (プロトタイプ化が必要なければ、方向づけフェーズの反復段階では行わない場合もあります)。 | |
ステップ | |
入力とする成果物: | 結果となる成果物: |
ツール・メンター: | |
More Information: |
ワークフローの詳細: |
実装担当者は、実装作業を開始する前に、作業分担書と反復計画書で指定されている範囲を理解しておく必要があります。実装のタスクでは特定の機能 (ユース・ケース実現の実装や障害の修正など) を実現することに焦点を当てることができ、その機能を実現するための複数の設計要素を実装する作業を行います。また、設計サブシステムや設計クラスなどの特定の設計要素に焦点を当てることもでき、現在の反復で必要とされる範囲でそれらを実装します。
この作業では、1 つ以上のファイル (実装要素) を作成するか、更新します。実装担当者は、実装の準備の一環として、正しい要素バージョンを使用するために、開発環境が正しく構成されていることを確認する必要があります。この確認は、更新する要素と、コンパイルや単体テストで必要な要素の両方で必要です。実装担当者は、プロジェクトの構成と変更管理の手順を理解し、それに従う必要があります。そのような手順では、変更の制御やバージョン管理の方法、統合のために変更を配信する方法などを定めています。
クラスを実装する前に、再利用や調整が可能な既存のコードがないかどうかを調べます。実装担当者は、システムのほかの部分のアーキテクチャーや設計に実装が適合するかどうかを確認することによって、そのような再利用の可能性を探ることができます。さらに、実装をシステムのほかの部分に確実に適合させることもできます。
実装は段階的に行うことをお勧めします。コンパイル、リンク、1 日に 1、2 回の回帰テストを実行します。パブリック操作、属性、関連のすべてを設計中に定義するわけではないことに注意してください。
障害を処理するときには、症状をなくすのではなく、問題を修正するようにします。目指すべきことは、コード内の根本的な問題を修正することです。エラーの修正自体がエラーを引き起こしやすい作業なので、変更は 1 つずつ行っていきます。新しいエラーの発生源を突き止めやすくするため、修正を 1 つずつ段階的に実装することが大切です。
実装担当者は、特定のプログラミング言語用のプログラミング・ガイドラインを含め、プロジェクト固有の実装ガイドラインを理解し、それに従う必要があります。
設計を実装に変換するには、さまざまな技法があります。以下に例を示します。
しかし、手作業で行うにしても、自動変換を適用するにしても、一部の設計の抽象概念を詳細化して実装に変換することはどんな場合でも同じです。
前のステップで説明した方法で設計を実装に変換すると、程度の差はあっても実装は完了します。 これだけで、そのまま受け入れられる完全な実装になる場合もあります。 しかし通常は、実装を完了するためにかなりの労力が必要です。 たとえば、以下のような作業が考えられます。
この作業では、実装が目的に合っているかどうかを確認します。 テストに加えて、以下のような検査も有効です (テストについては、他の作業の箇所で説明しています)。
設計を実装してテストを行うと、設計に影響するエラーがどうしても見つかってしまいます。今後の保守作業あるいは契約や情報交換などのために設計の抽象概念を保持しておくのであれば、設計の更新が必要になります。
これをどのような方法で行うかは、プロジェクトの構成と変更管理のプロセスによって異なります。一般的に、必要な変更が少なく、クラスの設計と実装を同じ人が担当している場合、正式な変更依頼は必要ありません。その人が設計を変更できます。
パブリック操作への変更など、必要な変更が広範な影響を及ぼすのであれば、正式な変更依頼を提出しなければならない場合があります。
Rational Unified Process
|