Club-Zコラム第13回

印刷用表示 | テキストサイズ 小 | 中 | 大 |


clubZ_info_renewal.jpg

| HOME | コラム | グローバル化は設計・製造の仕組みを見直すチャンス | 第13回 | P4 |

更新日 2016-01-20 | 作成日 2007-12-03

コラム


グローバル化は設計・製造の仕組みを見直すチャンス

【第13回】ハード屋でも進捗管理が可能となるソフト開発計画の作成方法

株式会社RDPi  代表取締役 石橋 良造

2008.08.28

次に、問題 (b) として挙げた、結合テスト実施までに待ちが発生していることを考察したいと思います。

前述のように、実際のソフト開発は機能ごとにウォータフォール型の流れるような開発作業になっているわけではないので、現実にはこのような待ちが発生しているわけではありませんが、ここで考えるべきポイントは結合テストの計画の立て方です。結合テストとは、いくつかの機能を合わせて動作確認をすることが目的です。そして、いくつかの機能ごとに段階的に動作確認を行うことで完成度を逐次確認する方法をとります。したがって、結合テストで重要なのは、どの機能とどの機能を合わせて、どのくらいの回数をかけて、どのような順番で、どのような日程で実施するのかということです。

このような方法をとる理由は、組込型ソフトウェア開発のリスクを減らすための効果的な方法のひとつが、ハードウェアと組み合わせ、段階的に動作確認をしながら完成度を見える化して進捗を確認することだからです。実際の開発現場では意識しているかどうかにかかわらず、何度も結合テストを繰り返して、その度に完成度を確認しているはずです。これを計画の際に明示的にすることが重要です。つまり、結合テストの範囲(どのような組み合わせで結合するのか)とその実施日程(いつ動作確認ができるのか)が明示されているスケジュールにするということです。

振り返って図35LinkIcon を見てみると、結合テストという作業(タスク)が機能ごとに組み込まれており、結合テストの全体像を把握するには、スケジュールを全部見てその中から結合テストが同じ日程になっている機能をリストアップするというような変換作業が必要です。このようなスケジュールになっているということは、少々極端な言い方になりますが、結合テストの重要性がわかっておらず、完成度の確認も不十分なソフト開発になっているといえます。

結合テストの重要性がわかっている適切なスケジュールというのは、図36 のように結合テストは大項目として別出しになっており、小項目で段階的にどのような範囲の結合テストが実施されるのかがわかるようになっています。そして、どのような範囲で結合が行われるのかは別資料(「結合テスト範囲プラン」)で説明されています。

column_20080828_4.JPG

結合範囲(図36 では「結合テスト範囲プラン」)は、動作確認をしたい外部仕様の優先順位と、モジュールの新規性や処理の複雑性などのソフト内部仕様の優先順位の両方から決める必要があります。したがって、結合テストのスケジュールはソフト屋さんだけで決めるものではなく、製品全体の開発進捗をどのような段取りで確認するのか、プロジェクトリーダーやハード屋さん含めて検討すべきです。そしてそのためには、今回説明した方法でシステム設計やスケジュール作成を行い、図32LinkIcon図34LinkIcon、そして、図36 に相当する開発文書を作成する必要があります。

さて、まだ全部を説明できていませんが、今回は組込型ソフトウェア開発についてスケジュール作成方法を解説しました。前回お話しした内容について、より具体的に説明したつもりですが、いかがだったでしょうか。計画作成までの作業の流れや考え方をより深く理解していただけたのではないかと思います。次回は、ソフトウェア開発のスケジュール作成について残っている点を解説し、計画作成の全体像を明らかにしたいと思います。

それでは、また次回お会いしましょう。




【今回の記事はいかがでしたか?】

大変参考になった
参考になった
あまり参考にならなかった
参考にならなかった

今回の記事について詳細なご説明をご希望の方は、Club-Z編集局(clubZ_info@zuken.co.jp)までご連絡下さい。