組込みソフトウェアレビュー手法 - 組込みエンジニアに求められる能力

一年ぶりの投稿です。

お疲れ様でございます。成島です。

【議題】

組込みソフトウェアレビュー手法

【理由】

短納期・高品質が求められる組込みシステム開発において、スケジュールを意識しながらどのように計画的にレビューを進めていくかが鍵である。そこで、今回は基本設計の観点でレビューをする上での説明手順や準備に関して記載していこと思う。

【内容】

一番レビューにおいて重要なこと記載します。それは、レビューのストーリを組み立てられていることです。レビューストーリーとは、レビューをする上での物語を構築することです。何も考えずレビューに挑む(作成完了したからOKも含む）といくら成果物が正しくできていたとしても相手に伝えることができません。そのため、いかに相手を論破できる説明ができるかということが必要になります。

そこで私なりに、いつも自分が設計書に落とし込んで実施している内容を記載します。

上位要求が漏れなく洗い出せているかを確認できること
その内容に関して対応するか否かを検討する。
ソフト修正箇所に関して、こういう理由で必要という説明ができる。
どこのテスト工程でこのソフト修正の品質を保証するか。また、どういったテスト観点が必要か。
他担当者とIF整合取れているか。

※また、著者は、上記観点に関して、設計書のテンプレとしてローカルに保存し、運用している。逆にレビューワは、上記観点を満たせているかという観点でレビューに臨む必要があります。

上位要求が漏れなく洗い出せているか確認できること

＞また、私的に一番重要だと思う観点は、これです。「確認できること」が重要です。

変更量が多いと普段ではよい(変更量少ない)目視でやりましたや、検索かけて調査調べました等が通用しません。なぜならば、変更量が多すぎて変更内容を一目で確認できないためです。そのため、手順として仕様の抜け漏れがないことを証明できることが重要です。一つ一つの細かいところをレビューワが確認することは不可能なので、このやり方なら大丈夫だという安心を持たせて上げられれば、そのレビューは勝ちです( ´∀｀ )

実際の例を挙げますと、ソースコードのリバースから単体テスト実施します、という場面で、関数の洗い出しをしなければなりません。その時には、WinMargeで目視で確認して、関数洗い出したは、NGです。全ファイルに対して、WinMargeでソースコード差分をエビデンス(WinMergeできないかもしれないから代用して、DF)として残し、そのファイルに対して、単体テスト実施する/しないをエビデンスとして残し、説明するとレビューワも納得できる。

そもそも、エビデンスに残す必要があるのは、それがとても重要だからです。上位設計が漏れてしまうということは、不具合に直結するため、エビデンスが必要なのです。

設計書作成に必要なことまとめますと...

レビューストーリをまず立てる。
不具合に直結する作業に関しては、なるべくエビデンスに残す。
変更量が多い箇所に関しては、漏れていないかを確認できる。

以上となります。

【独り言】

自身も勉強中の身なので、これを閲覧してくださった方が、

アドバイスやご意見頂ければと思います。

また、機会があれば、一緒に業界にかかわることや組込み(ハードやソフト問わない)やITに関わる勉強会をできればよいなという思いがあります。

様々な分野で活躍されている方のお話を聞きながら自身も成長していきたいという思いがあるので、インターネット上のお付き合いもうれしく思いますが、リアルな場面でも刺激を受ける機会があればよいなと思います。

【最後に】

お役に立てる記事が書けていれば幸いであります。

最後まで視聴ありがとうございました。