次の方法で共有

開発タスクの実装

  • [アーティクル]

開発タスクは、要件から生じる小規模な開発作業です。 開発タスクを実装するには、適切な新しい機能をソフトウェアに追加する必要があります。 開発タスクが完了したら、その単体テスト、レビュー、コード分析、および既存のコード ベースへの統合を行う必要があります。

このトピックの内容

見積もり

デザイン ドキュメント

デザイン レビュー

単体テスト

コード分析

コード レビュー プロセス

リファクター

変更の統合

見積もり

開発タスクのコストを見積もると、機能のスコープの制御や開発作業のスケジュールに役立ちます。 イテレーション計画会議の前に、すべての開発タスクのコスト見積もりを完了し、問題を解決しておく必要があります。 開発タスクの総コストがイテレーションで対応可能なコストを超える場合は、タスクを延期または再割り当てする必要があります。 開発タスクが選択されたら、開発者がタスクのコストを見積もる必要があります。

選択された開発タスクごとにタスク作業項目を作成し、その項目を作成する基となった要件にリンクします。 この操作は、タスクまたは要件作業項目の [実装] タブで行います。 見積もりは、同様のタスクを完了するために要した時間に基づいて行い、必ず単体テストを記述するコストも考慮に入れます。 タスクごとに、見積もりをタスク作業項目の最初の見積もりフィールドに入力します。

タスク作業項目のフォームでは、次の図に示すフィールドとタブにデータが保存されます。

CMMI タスク作業項目フォーム

タスクの作成および見積もりが完了したら、作業内訳クエリを使用して、すべての要件およびタスクの内訳を表示します。 詳細については、「共有クエリ (CMMI)」を参照してください。

デザイン ドキュメント

デザイン ドキュメントには、要件を製品に実装するコードの記述方法を開発者に示すために必要な情報を含める必要があります。

デザイン ドキュメントは、チーム プロセスに応じて、仕様、要件作業項目、およびその他のドキュメントのコレクションにすることができます。

デザイン パターン、オブジェクト指向デザイン、構造モデル、モデリング言語、エンティティ リレーションシップ モデル、およびチーム用に決定されたデザインのガイドラインに示されたその他の手法を使用することを検討してください。 また、主要な意思決定を下した際の根拠を文書化することもお勧めします。 たとえば、コスト、スケジュール、または技術的なパフォーマンスが大きな影響を受ける場合は、このような影響の原因となった意思決定の理由を文書化し、その情報をデザインに含めます。

必要なデザイン ドキュメントを作成したら、チーム メンバーが共有できる場所に保存します。 詳細については、「ドキュメントおよびドキュメント ライブラリの管理」を参照してください。

デザイン レビュー

デザイン レビューは、新しいデザインまたは改訂されたデザインが技術的に正確、完全、テスト可能、かつ高品質であること、および要件が正しく実装されていることを確認するために使用します。 デザイン レビューは、問題をコードで見つかる前に特定して早い段階で品質を保証するための主要な方法です。 また、デザイン レビューでは、他の開発者からのデザインに関する追加情報も把握できます。

デザインの作成を担当する開発者は、レビュー担当者を特定してレビューをスケジュールし、デザインをすべてのレビュー担当者に配布して、デザイン レビューを編成する必要があります。

デザインに関与する関係者またはその影響を受ける関係者は、レビューに参加する必要があります。 通常、この関係者には、プロジェクト マネージャー、リード開発者、デザイン領域のテスト担当者などが含まれます。 レビュー対象のコードを担当した開発者と同じチームに所属するすべての開発者も、レビューに参加する必要があります。

レビュー会議をスケジュールし、早い段階でデザイン ドキュメントを配布して、各レビュー担当者が目を通すための十分な時間を確保できるようにします。 レビューする必要がある技術的な詳細の量に合わせて、レビュー会議の時間を計画します。

品質の検証

デザインがテスト可能であることを確認します。 ビルドされたコードが適切な方法で確認または検証できないかどうかを確認します。 検証や確認ができないと、コードの品質を確認できないため、デザインを作成し直すことが必要になります。 デザイン ドキュメントを調べて、コード エラーにつながる問題がないかどうかを確認してください。 インターフェイスの不適切な記述、デザイン上の誤り、または混乱を招く名前付けがないかどうか探します。 演算子インターフェイスの標準、安全性の標準、運用の制約、デザインの許容範囲、パーツの標準などの既存の基準とデザイン ドキュメントを比較します。 デザイン ドキュメントで見つかった欠陥について説明するバグ作業項目を作成し、担当開発者に割り当てます。

デザインのレビュー作業項目の作成

レビュー作業項目は、デザイン レビューの結果を文書化するために作成します。 レビュー チームは、デザインの次の手順を決定する必要があります。次の手順は、必要な変更の規模によって異なります。 変更の必要がない場合は、作業項目の [状態] を [終了] に設定し、[理由] を [承諾済み (現状)] に設定して、デザインに基づいてコーディングを開始できることを書き留めます。 軽微な変更が必要な場合は、作業項目の [状態] を [解決済み] に設定し、[理由] を [軽微な変更を伴って承諾済み] に設定します。 これは、軽微な変更がデザインに実装された後にコーディングを開始できることを示します。 重大な変更が必要な場合は、作業項目の [状態] を [解決済み] に設定し、[理由] を [重大な変更を伴って承諾済み] に設定します。 デザインに基づいてコーディングを開始する前に、デザインを作成し直して、もう一度デザイン レビューを行う必要があります。

単体テスト

単体テストでは、コードの単位が正しく実装されていることを検証します。 単体テストを記述して実行すると、テストの開始前にバグが特定されるので、品質管理のコスト削減に役立ちます。 開発者は、開発タスクを実装するか、またはバグを修正するための一環として記述されるすべてのコードの単体テストを記述する必要があります。 詳細については、「コードの単体テスト」を参照してください。

コード分析

コード分析では、開発ガイドラインの適用に役立つ規則セットと照らし合わせてコードをチェックします。 コード分析の目的は、コード分析における規則違反または警告をなくすことです。 コード分析では、名前付け規則、ライブラリ デザイン、ローカリゼーション、セキュリティ、パフォーマンスなど、200 以上の項目について、コードに発生する可能性のある問題がないかどうかを検査できます。

開発サイクルの早い段階でコード分析の実行を開始すると、継続的に規則違反および警告を最小限に抑えることができます。

ただし、チェックされたことがない既存のコードに対してコード分析を実行すると、規則違反が多数検出される可能性があります。 このような場合は、コードが合格する必要がある、基準となる重要な規則セットを作成し、より重要な問題が解決されてからこの規則セットを拡張することができます。 このようにして、チームは既存のコード ベースを改善しながら、新しい機能への取り組みを進めることができます。

詳細については、「コード分析ツールを使用したアプリケーション品質の分析」と「チーム プロジェクト チェックイン ポリシーによるコード品質の向上」を参照してください。

コード レビュー プロセス

リード開発者は、レビュー担当者を特定してコード レビューをスケジュールし、レビュー対象のコードをすべてのレビュー担当者に送信して、コード レビューを編成する必要があります。 コード レビューを準備するには、次の手順に実行します。

  1. レビューで行われる意思決定を追跡するために、レビューの作業項目を作成します。 変更の必要がない場合は、作業項目の [状態] を [終了] に設定し、[理由] を [承諾済み (現状)] に設定して、デザインに基づいてコーディングを開始できることを書き留めます。 軽微な変更が必要な場合は、作業項目の [状態] を [解決済み] に設定し、[理由] を [軽微な変更を伴って承諾済み] に設定します。これは、軽微な変更が実装された後にコーディングを開始できることを示します。 重大な変更が必要な場合は、作業項目の [状態] を [解決済み] に設定し、[理由] を [重大な変更を伴って承諾済み] に設定します。 デザインに基づいてコーディングを開始する前に、デザインを作成し直して、もう一度デザイン レビューを行う必要があります。

  2. コード レビューの参加者を決定します。 通常は、少なくともリード開発者や、そのコード領域を担当するアーキテクトがレビューに参加する必要があります。

  3. レビュー担当者とのレビュー会議をスケジュールし、各レビュー担当者が会議の前にコードに目を通して理解するための十分な時間を確保できるようにします。 レビューする必要があるコードの量に合わせて、レビュー会議の時間を計画します。

コード レビュー

コード レビューは、新しいコードまたは変更されたコードをデイリー ビルドに統合する前に、確立された品質基準をコードが満たすことを確認するために使用されます。 品質に関する考慮事項には、コーディング規則、アーキテクチャと設計への準拠、パフォーマンス、読みやすさ、およびセキュリティがあります。 また、コード レビューを使用すると、コードの記述方法に関する他の開発者からの追加情報も把握できます。

コードの関連性の検証

レビュー対象のコードは、コードが記述されるタスクに関連するようにします。 実装または修正される機能に対応しないコード変更は許可されません。

拡張性の検証

コードは、拡張を意図している場合、またはシステムの他の領域で再利用される場合は、拡張できるように記述します。

コードで使用される文字列定数を、国際対応可能なリソースに正しく配置します。

コードの複雑性が最小限であることの検証

繰り返されるコードは、共通の関数に簡略化できます。

同様の機能は、共通のプロシージャまたは関数に組み込みます。

アルゴリズムの複雑性の確認

レビュー対象のコード内の実行パスの数は最小限にします。

コード セキュリティの検証

資産の保護、特権レベル、およびエントリ ポイントでのデータの使用について、コードをチェックします。

コードのリファクタリング

コード レビューで、コード品質、パフォーマンス、またはアーキテクチャに対応する変更を行う必要があると判断されたら、コードをリファクタリングします。

コード レビューの作業項目のメモを読み、コードのリファクタリング方法を決定します。

リファクタリングをインクリメント方式で適用し、一度に 1 つの変更を適用します。 必要に応じて、コードおよび変更された領域へのすべての参照を変更します。

単体テストを実行して、リファクタリング後もその領域が意味的に同等のままになるようにします。 機能しない単体テストを修正します。 コード分析を実行し、警告を修正します。 コード分析の結果としてコードを変更した場合は、単体テストを再度実行します。

変更の統合

最後に、変更をバージョン コントロールにチェックインして統合します。 コードのチェックイン前に、プロセスで必要なテストを実行しておく必要があります。 チェックイン前にコードに問題がないかどうかを確認する方法の詳細については、「チーム プロジェクト チェックイン ポリシーによるコード品質の向上」を参照してください。

変更に関連付けられている作業項目が、自分が所有者ではないシナリオまたはサービス品質要求である場合は、変更が完了していることを所有者に通知します。 タスク作業項目を [解決済み] に設定し、その作業項目のテスト ケースを作成したテスト担当者の 1 人に割り当てます。

変更に関連付けられている作業項目がバグである場合は、バグ作業項目を [解決済み] に設定し、その作成者に割り当てます。