つれづれなる技術屋日記: 2013年5月
このサイトではWindowsやPMBOKなど、登録商標および商標を記載省略しています。以前の記事閲覧で、カレンダー経由「ページが見つかりません」になったら、”バックナンバー”経由で辿ってください。 Facebookで知り合いの書き込みにコメントしたら、どうもソフトウェアにおける「故障モード」って整理されてない／一般的なものが存在しないようだと判明。探せば見つかるのかもしれないが、広まっているものがないように思えた。 ちなみに、CiNiiで「ソフトウェア FMEA」で検索すると19件、「ソフトウェア 故障モード」で検索すると7件ヒットした。未公開などの中に良い情報があるかもしれないが、読める論文だと、故障モードが詳細すぎる気がする。（今回ブログに書いたのは、それも理由。） またCiNiiで「FMEA」で検索すると249件、「ソフトウェア 故障モード」で検索すると119件ヒット。 と言うことで
第5回 改造の影響を調べる：詳細な工数とソースコードの変更箇所を洗い出す
対応すべき案件が決まり，いざソフトウエアの改造に臨むとき，間違っても，いきなりプログラムを変え始めてはならない。「変更個所を見つけると，すぐにでもソースコードを変えたくなる。しかし，それでは後から後から変更個所が見つかり，作業に追われてしまうことになる」（システムクリエイツ の清水氏）からだ。 急ぎすぎた改造は，プログラム品質の低下も招く。住友電気工業はかつて，押し寄せる案件に対して，開発担当者が簡単なメモを作る程度で，プログラムの変更に着手していた。情報システム部の中村伸裕氏（システム技術グループ グループ長）は，「対応は早かったが，バグが多かった」と振り返る。こうした反省から，影響分析を徹底するように改造プロセスを改めた。「今ではソースコードの変更方法までレビューしている。レビューが通らない限り，担当者に本番のソースコードは触らせない」（中村氏）。 ソフトウエアの改造に当たり，エンジニ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
機能安全対応自動車制御用プラットフォームの開発
三菱電機技報2013年4月号 論文12
http://ftp.techmatrix.co.jp/asq/lattix/document/lattix_impact_analysis_solution_20130326.pdf