［レポート］
組込みシステム開発に特化した、要求分析・定義・管理手法に関するセミナーでした。 カンファレンス初日、朝一番のセミナーでしたが、会場はほぼ満席で、複雑化・多様化 する組込みシステム開発の要求分析技法に関する業界関係者の興味関心の高さが 伺えました。 以下、簡単にセミナーの内容をまとめ、私の所感を述べたいと思います。
ソニー株式会社 ネットワーク&ソフトウェアテクノロジーセンター
ソフトウェア品質保証部 1課 係長
橋本 隆成 氏
これからの組込みシステム
要求分析/定義を再考する
組込みシステムの特徴(リアルタイム性、リソース制約)、近年の動向(複雑化、多様化、大規模化、ユビキタス・バリュー)について、例とともに述べ、要求定義/管理が品質に大きく影響することを主張されていました。
また、"要求は開発のライフサイクルを通じて明確になり、変更されていく"ことから要求管理の重要性について述べられていました。私もプロジェクトを通じて、このようなことを感じることはありますが、要求や仕様の変更に強いソフトウェア設計やプロジェクト管理技法を導入するのみでなく、要求管理についても技法を確立することが大切であることを感じました。
組込みシステムの UseCase の描(書)き方
一般的な UseCase の有用性、一般的な UseCase の記法 (UseCase 図とその構造化、UseCase 記述の例)、組込みシステムに特化した UseCase、非機能要求の記述法などについて述べられていました。 組込みシステムの場合には、UseCase を起動するアクターが不明瞭な場合があり、イベント分析を併用するなど、UseCase の利用に関するコツのようなものも紹介されていました。
UseCase 抽出/分割に関して、その粒度は組込みシステム開発でも難しいところであると感じますが、これに関しては"プロジェクト管理手法などにも依存するため、その良し悪しは一概に言えない"とのことでした、これは"現場にあわせて確立していくしかないのかなぁ"、という思いを感じました。
要求分析・定義・管理とソフトウェア開発プロセス
反復型開発や要求定義と開発の流れ、プロセス&プロジェクト管理の重要性に関して述べられていました。
SEI-CMMと要求分析/定義および管理
CMM/CMMI に関する簡単な紹介といった内容でした。
私自身がこのあたりに関してまだ不勉強であったため、その効果のほどがあまりわかりませんでした。
実際に導入した場合にどのくらいの効果があるのか、事例をあげた説明があったらよかったという印象を受けました。
富士ゼロックス株式会社
ドキュメント・プロダクト&サプライ・カンパニー 商品開発本部
IOTデバイス開発統括部 デバイス制御開発部
杉浦 英樹 氏
システム要求のとらえ方
ハードウェアとソフトウェアを含んだ組込みシステムに要求されているコトをどのように具体化する、特にハードウェアとソフトウェアの責務分担を具体化する作業をシステム・アーキテクチャ設計と呼ばれていました。
そして、システム・アーキテクチャ設計のためにはシステムに求められる要求を正しく理解、分析できていることが肝要であり、そうでなければシステムの冗長化や品質低下、納期遅れにつながることを述べられました。システム要求の分析にはシステム分析ユースケースを用いるが、その前のたたき台としてコンセプトペーパーというアイディアを提案されていました。 コンセプトペーパーというのは開発者間で要求やシステムの最終的な姿を理解、共有するためのフリーフォーマットのドキュメントだそうです。
このアイディアにはとても共感をおぼえました、開発者間の要求/仕様理解の不一致からのしわ寄せは、ソフト開発者の負担になることが多いのはよくある話ですが、そのような不具合を減らすのに、効果があるのではないかと思ったからです。
しかしながら、フリーフォーマットのドキュメントということから、開発者の意識や技量に依存する部分が大きいようにも思いました。実現手段の特定
コンセプトペーパーとシステム分析ユースケースを元に、システムアーキテクチャ設計(実現手段の決定と責務分担)を行う手法について述べられました。 プロセスのアウトプットとしては、ユースケースごとにハード/ソフトの責務を分割、リスト化したシステム責務分担リストを作成します。
これにも非常に共感をおぼえました。基本的なことのようにも思えますが、実際の組込みシステム開発現場で、どのくらいこのようなこと(ハード-ソフト間、サブシステム間での責務分割の文書化)がきちんと行われているのでしょうか?システム要求とシステム・アーキテクチャ
システム要求をシステム分析ユースケースのシナリオで、アーキテクチャ(ソフト+ハード)はクラス図で記述し、ユースケースの実現をシステムシーケンス図で検証することを述べられました。
システムの検証
システムの機能面でのテストには、システム分析ユースケースのシナリオを元に検証し、性能に関しては品質特性展開表という文書を元に検証すると述べられました。また、要求の評価だけでなく、アーキテクチャの評価を必ず行い、継続的に改善していくことが重要であることを述べられました。
普段の仕事では、ソフトウェアの開発プロセスやアーキテクチャについて考えることはあっても、組込みシステムやシステムアーキテクチャまで含めてプロセスを考えることは、あまりなかったので、それらについて有益な話を聞けたと感じています。
組込みシステムやソフトウェアに対する要求が複雑化、多様化、大規模化している中で、本セミナーで述べられていたようなプロセス改善活動が開発現場から広がっていけばよいと思いました。
| © 2003 OGIS-RI Co., Ltd. |
|
