形式仕様記述では、事前/事後条件、不変条件などを明示的に書き出す必要があるため、自然言語で記述した仕様と比べて、重要な前提条件などが埋もれにくい。チーム内で仕様をもんでいく際も、解釈の差が生じにくく議論がかみ合いやすい。 仕様の解釈の幅はソフトの実装工程において、仕様策定者が想定したのとは異なる動作を作り込んでしまう事態を招きがちだ。こうしたバグは実装担当者による“実装ミス”として片付けられることが多いが、本来は上流工程で仕様を精査し、仕様の品質を高めておけば防げる。形式手法はプロジェクトメンバー間での仕様伝達における、こうした齟齬をできるだけ減らし、ソフト開発をスムーズにするための手法だ。 ライフロボティクスで今回の形式手法導入を主導した同社 研究開発部 部長の川口順央氏は「形式手法を用いることで仕様が安定すれば、以降の作業を見積もりやすい。プロジェクトの見通しが増す効果があったほか、設
「テストやレビューをしっかりやれ」「プロジェクト・マネジメントをキッチリ徹底しろ」――今のソフトウエア開発では，誰もが品質確保の確かさを「キッチリ」としか表現できない面がある。 エンジニアリングの実践に程遠いこうした現状から脱却し，ハードウエアと同じ地位を持つ工業製品としてソフトウエア開発を昇華させる必要がある。そのための道具として「形式手法（formal methods）」を知り，見直すべき時が来た。（日経エレクトロニクス 2005年12月19日号 特集より、進藤 智則＝現在は日経Robotics編集長） 第1回：「ソフトは軟らかい。すぐ 直せる」――ひょっとして…まだ，そう思っていませんか？ 第2回：現状はエンジニアリング以前，解釈ミスを減らす方法論へ（1） 第3回：現状はエンジニアリング以前，解釈ミスを減らす方法論へ（2） 第4回：10分で分かる形式的手法 第5回：国内でも成功事例が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
