7
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

モグラたたき開発を卒業しよう 対策編 その2

Last updated at Posted at 2017-08-11

以下の記事は「モグラたたき開発を卒業しよう 対策編」の後半に書いていた部分を独立させ追記したものです。
品質を確保するうえで参考になりそうな記事を引用しています。最近の流れをつかんで、必要な情報を自分で見つけていって、職場のみなさんに紹介してくださると幸いです。

失敗百選

まずは、どのような失敗が製品開発の分野ではあって、そのような典型例から何を学ばなければならないのか、自分の感覚を研ぎ澄ましてください。

宇宙開発の分野でも失敗は起きています。

メートル法とポンド・ヤード法の勘違い、火星探査計画は水の泡

1996年6月4日――『アリアン5』フライト501

宇宙開発の分野では、O-ring(オーリング)1つでさえ、7名の乗組員が死亡した事故を引き起こしている。チャレンジャー号爆発事故

最も突出した要因は、NASAとサイオコール社が共に、接合部の設計不良が及ぼす危険に対して適切に対処しなかったことだった。彼らは接続部の設計を見直すどころか、その程度の危険は許容範囲内であると規定したのである。報告書によれば、マーシャル宇宙飛行センターの幹部たちはすでに1977年の段階で欠陥について知っていたが、問題をサイオコール社との間だけに留めて決して外には出さなかった。これはNASAの規定に対する明白な違反だった。

こういった事例をふまえつつ、宇宙開発の分野でのソフトウェアの品質確保がなされているのかについて、検索して見つかったものを示す。

人工衛星の開発手法

大規模なシステムを高い品質を保ちながら確実に効率よく開発するための手法として、NASAがアポロ計画時代に開発した「段階的プロジェクト計画」(Phased Project Planning:PPP)があります。

PPPは開発段階を幾つかのフェーズに分けて、それぞれのフェーズで作業内容を定義し結果を審査により評価して、次のフェーズへの移行を判断する手法です。

宇宙航空研究開発機構(JAXA)における信頼性向上とその対応策

宇宙用ソフトウエアの置かれる状況
• 組み込みソフトとの共通課題
– 上流工程の不確定さ(要求元は?決まらない?)
– 機能要求の増加と複雑化による検証の限界
– ハードウエア主体の文化
– 開発の外注化の加速

宇宙機高信頼性ソフトウェア開発プロセスのアプローチ

上流工程の改善
主開発工程にモデルベース開発を導入

V&V(検証と妥当性確認)

宇宙機開発の「一度きり」のシステム開発者は、テストについてどう考えているのか~『エンジニアサポートCROSS 2015』から

ホーム宙への挑戦かぐやVoyage02 成功率100%の壁


幅広い品質問題

ソフトウェアの品質問題は、宇宙にかぎらず、幅広い分野で生じる問題です。組込みソフトウェアの分野では、一般の人が使う機器の制御を背後で支えるソフトウェアです。一般の人が使う機器の分野は、プロが使う機器と違って無茶な使い方をされるものです。使用環境もまちまちです。老朽化しても無理して使われ続けることもあります。

上流工程へのテストの追加の流れ

上流工程の品質を早い段階で改善していくための試みが、重要な問題として考えられている。
上流の設計段階でどのようにテストするのかが、従来のV型のプロセスでは抜け落ちていたと考えられています。
そのため、
ソフトウェアでのテストは従来のV字型のプロセスではなく、設計の早い段階からテストを入れていくアプローチになってきているようです。システム設計のVの他に、テストの設計のVが加わることで、W型の開発になるわけです。
さらには、検証プロセスが加わってきています。

3モデルの提案 V3モデルの提案
名前の通り,3つのV字からなる

(V1) 設計構築プロセス
(V2) テストプロセス
(V3) 検証プロセス

私が聞くところの失敗するプロジェクトでは、上流設計での要件定義のレベルで失敗しているプロジェクトが多いように思えます。実現可能性について十分に検証しないまま、見切り発車で仕様を確定してしまい、下流工程では対処のしようがない状況を生じてしまいます。部分としては破綻しない仕様であっても、複数の部分が重なってきたときには、騙し絵(だましえ)のように矛盾した仕様になることがあります。

どのようなシンポジウムが開かれているのか、アクセスしてみてください。


V&Vとモデルベースデザイン

特に、製品・制御システムのソフトウェアならびに付随するネットワーク・
コミュケーションシステムの障害に注目し、それの原因を追究し、解決への提言を行う方
法論として、「事後 Verification & Validation(V&V)」という考え方を提案している。この
V&V という考え方は、本来、製品開発段階で用いられるものであるが、設計時点での想定
不足を見つけるという視点で考えると、障害を起こしたシステムの原因診断にも使える。

- PDF [大規模・複雑化した組込みシステムのための障害診断手法(付録)](http://www.ipa.go.jp/files/000045159.pdf)

モデルベースデザインの設計手法がこの付録資料の中で示されている。
モデルベースデザインでは、Simulinkのブロック図らしいものが描かれている。
モデルベースデザインでは、なんらかの動くモデルがあることで、上位設計時の設計漏れや間違いに気づきやすくなります。

製品の信頼性を維持するためには、各企業等の経験と情報を企業・業界・世代横断
で共有することが大切である。そのためには、各企業等が個別に保持する経験とノウ
ハウを第三者が理解し実践できる形に要約する必要がある。

未然防止知識シートは、知識の提供者に記入してもらうために使用するシートである。

[工程別未然防止知識整理の方針]
工程ごとの対策と、対策しなかったときにどのような問題が発生しうるのかを一覧にし、工
程ごとに未然防止知識を俯瞰できるようにするために、工程別に整理する。工程ごとのそれぞ
れの未然防止知識から、もとの未然防止知識をたどれるように整理する


ソフトウェアの品質向上に役立つ情報が無料で入手できる場所

7
15
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?