モグラたたき開発を卒業しよう 対策編 その２
以下の記事は「モグラたたき開発を卒業しよう 対策編」の後半に書いていた部分を独立させ追記したものです。
品質を確保するうえで参考になりそうな記事を引用しています。最近の流れをつかんで、必要な情報を自分で見つけていって、職場のみなさんに紹介してくださると幸いです。
失敗百選
まずは、どのような失敗が製品開発の分野ではあって、そのような典型例から何を学ばなければならないのか、自分の感覚を研ぎ澄ましてください。
宇宙開発の分野でも失敗は起きています。
宇宙開発の分野では、O-ring（オーリング）１つでさえ、7名の乗組員が死亡した事故を引き起こしている。チャレンジャー号爆発事故
最も突出した要因は、NASAとサイオコール社が共に、接合部の設計不良が及ぼす危険に対して適切に対処しなかったことだった。彼らは接続部の設計を見直すどころか、その程度の危険は許容範囲内であると規定したのである。報告書によれば、マーシャル宇宙飛行センターの幹部たちはすでに1977年の段階で欠陥について知っていたが、問題をサイオコール社との間だけに留めて決して外には出さなかった。これはNASAの規定に対する明白な違反だった。
こういった事例をふまえつつ、宇宙開発の分野でのソフトウェアの品質確保がなされているのかについて、検索して見つかったものを示す。
大規模なシステムを高い品質を保ちながら確実に効率よく開発するための手法として、NASAがアポロ計画時代に開発した「段階的プロジェクト計画」(Phased Project Planning：PPP)があります。
PPPは開発段階を幾つかのフェーズに分けて、それぞれのフェーズで作業内容を定義し結果を審査により評価して、次のフェーズへの移行を判断する手法です。
宇宙航空研究開発機構(JAXA)における信頼性向上とその対応策
宇宙用ソフトウエアの置かれる状況
• 組み込みソフトとの共通課題
– 上流工程の不確定さ（要求元は？決まらない？）
– 機能要求の増加と複雑化による検証の限界
– ハードウエア主体の文化
– 開発の外注化の加速
上流工程の改善
主開発工程にモデルベース開発を導入
宇宙機開発の「一度きり」のシステム開発者は、テストについてどう考えているのか～『エンジニアサポートCROSS 2015』から
幅広い品質問題
ソフトウェアの品質問題は、宇宙にかぎらず、幅広い分野で生じる問題です。組込みソフトウェアの分野では、一般の人が使う機器の制御を背後で支えるソフトウェアです。一般の人が使う機器の分野は、プロが使う機器と違って無茶な使い方をされるものです。使用環境もまちまちです。老朽化しても無理して使われ続けることもあります。
上流工程へのテストの追加の流れ
上流工程の品質を早い段階で改善していくための試みが、重要な問題として考えられている。
上流の設計段階でどのようにテストするのかが、従来のV型のプロセスでは抜け落ちていたと考えられています。
そのため、
ソフトウェアでのテストは従来のV字型のプロセスではなく、設計の早い段階からテストを入れていくアプローチになってきているようです。システム設計のVの他に、テストの設計のVが加わることで、W型の開発になるわけです。
さらには、検証プロセスが加わってきています。
３モデルの提案 Ｖ３モデルの提案
名前の通り，３つのＶ字からなる（Ｖ１） 設計構築プロセス
（Ｖ２） テストプロセス
（Ｖ３） 検証プロセス
私が聞くところの失敗するプロジェクトでは、上流設計での要件定義のレベルで失敗しているプロジェクトが多いように思えます。実現可能性について十分に検証しないまま、見切り発車で仕様を確定してしまい、下流工程では対処のしようがない状況を生じてしまいます。部分としては破綻しない仕様であっても、複数の部分が重なってきたときには、騙し絵（だましえ）のように矛盾した仕様になることがあります。
- 研究会 ソフトウェアテストシンポジウム
どのようなシンポジウムが開かれているのか、アクセスしてみてください。
V&Vとモデルベースデザイン
特に、製品・制御システムのソフトウェアならびに付随するネットワーク・
コミュケーションシステムの障害に注目し、それの原因を追究し、解決への提言を行う方
法論として、「事後 Verification & Validation（V&V）」という考え方を提案している。この
V&V という考え方は、本来、製品開発段階で用いられるものであるが、設計時点での想定
不足を見つけるという視点で考えると、障害を起こしたシステムの原因診断にも使える。
- PDF [大規模・複雑化した組込みシステムのための障害診断手法（付録）](http://www.ipa.go.jp/files/000045159.pdf)
モデルベースデザインの設計手法がこの付録資料の中で示されている。
モデルベースデザインでは、Simulinkのブロック図らしいものが描かれている。
モデルベースデザインでは、なんらかの動くモデルがあることで、上位設計時の設計漏れや間違いに気づきやすくなります。
- 「組込みソフトウェア開発データ白書 2015」及び「組込みソフトウェア向け プロジェクトマネジメントガイド［定量データ活用編］」PDF版の公開
- 「情報処理システム高信頼化教訓集（組込みシステム編）」2015年度版公開 pdf資料
製品の信頼性を維持するためには、各企業等の経験と情報を企業・業界・世代横断
で共有することが大切である。そのためには、各企業等が個別に保持する経験とノウ
ハウを第三者が理解し実践できる形に要約する必要がある。未然防止知識シートは、知識の提供者に記入してもらうために使用するシートである。
[工程別未然防止知識整理の方針]
工程ごとの対策と、対策しなかったときにどのような問題が発生しうるのかを一覧にし、工
程ごとに未然防止知識を俯瞰できるようにするために、工程別に整理する。工程ごとのそれぞ
れの未然防止知識から、もとの未然防止知識をたどれるように整理する
「【改訂版】組込みソフトウェア開発向けコーディング作法ガイド[C言語版]Ver.2.0（ESCR Ver.2.0）」PDF版と付録データの公開
PDF「組込みソフトウェア開発向けコーディング作法ガイド C++言語版」
書籍もあります。
C++言語で安全で、保守性のよいプログラムを書くのにはどうしたらよいのかを書いているもので、一度は熟読する価値があると思います。
ソフトウェアの品質向上に役立つ情報が無料で入手できる場所
Author And Source
この問題について(モグラたたき開発を卒業しよう 対策編 その２), 我々は、より多くの情報をここで見つけました https://qiita.com/nonbiri15/items/18337a5ad2d6bc4887e9著者帰属：元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .