ソフトウェア開発スケジュールと結合テスト プロジェクト管理の仕組み (その7)

 前回のその6:進捗管理可能なソフト開発計画に続いて解説します。
 
 ソフトウェア開発スケジュールでは次のような問題を抱えています。
 
   a. 機能ごとに開発工程別に作業(タスク)をブレークダウンしている
   b. 機能によっては結合テストを実施するまでに待ちが発生している
   c. システムテストも個別機能の開発作業の一部となっている
 
 前回に続いて、今回は上記の問題 (b) として挙げた、結合テスト実施までに待ちが発生していることを考察します。実際のソフト開発は機能ごとにウォータフォール型の流れるような開発作業になっているわけではないので、現実にはこのような待ちが発生しているわけではありませんが、ここで考えるべきポイントは結合テストの計画の立て方です。結合テストとは、いくつかの機能を合わせて動作確認をすることが目的です。そして、いくつかの機能ごとに段階的に動作確認を行うことで完成度を逐次確認する方法をとります。したがって、結合テストで重要なのは、どの機能とどの機能を合わせて、どのくらいの回数をかけて、どのような順番で、どのような日程で実施するのかということです。
 
 このような方法をとる理由は、組込型ソフトウェア開発のリスクを減らすための効果的な方法のひとつが、ハードウェアと組み合わせ、段階的に動作確認をしながら完成度を見える化して進捗を確認することだからです。実際の開発現場では意識しているかどうかにかかわらず、何度も結合テストを繰り返して、その度に完成度を確認しているはずです。これを計画の際に明示的にすることが重要です。つまり、結合テストの範囲(どのような組み合わせで結合するのか)とその実施日程(いつ動作確認ができるのか)が明示されているスケジュールにするということです。
 
            
               図35. よくあるソフトウェア開発スケジュール 
 
 振り返って図35 を見てみると、結合テストという作業(タスク)が機能ごとに組み込まれており、結合テストの全体像を把握するには、スケジュールを全部見てその中から結合テストが同じ日程になっている機能をリストアップするというような変換作業が必要です。このようなスケジュールになっているということは、少々極端な言い方になりますが、結合テストの重要性がわかっておらず、完成度の確認も不十分なソフト開発になっているといえます。
 
 結合テストの重要性がわかっている適切なスケジュールというのは、図36 のように結合テストは大項目として別出しになっており、小項目で段階的にどのような範囲の結合テストが実施されるのかがわかるようになっています。そして、どのような範囲で結合が行われるのかは別資料(「結合テスト範囲プラン」)で説明されています。
 
  
              図36. 結合テストの実施スケジュール例
 
 結合範囲(図36 では「結合テスト範囲プラン」)は、動作確認をしたい外部仕様の優先順位と、モジュールの新規性や処理の複雑性などのソフト内部仕様の優先順位の両方から決める必要があります。したがって、結合テストのスケジュールはソフト屋さんだけで決めるものではなく、製品全体の開発進捗をどのような段取りで確認するのか、プロジェクトリーダーやハード屋さん含めて検討す...
べきです。そしてそのためには、今回説明した方法でシステム設計やスケジュール作成を行い、図32:要求仕様と内部構成の双方向追跡を可能とする設計文書や図34:外部仕様から内部構造への変換、そして、図36 に相当する開発文書を作成する必要があります。
 
 今回は組込型ソフトウェア開発についてスケジュール作成方法を解説しました。次回は、ソフトウェア開発のスケジュール作成について残っている点を解説し、計画作成の全体像を明らかにします。
 
 
◆関連解説『技術マネジメントとは』

↓ 続きを読むには・・・

新規会員登録


この記事の著者