恊働ロボットCOROの開発における形式的仕様の適用事例
•
4 likes•2,256 views
協働ロボットCOROの開発において形式的仕様記述を適用した事例について解説した資料です。 2016年6月30日（木）国立情報学研究所において開催された『第1回 ソフトウェア工学勉強会』で発表しました。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to 恊働ロボットCOROの開発における形式的仕様の適用事例
Similar to 恊働ロボットCOROの開発における形式的仕様の適用事例 (20)
恊働ロボットCOROの開発における形式的仕様の適用事例
- 2. 自己紹介 2 はじめに 2004年から形式手法に興味を持ち、以降勉強と試行の繰り返し 個人レベルでは何度か現場に導入したことあり（Spin, Alloy, CSPなど） 昔、Basic Spin Manual を訳しました http://www.asahi-net.or.jp/~hs7m-kwgc/spin/Man/Manual_japanese.html 川口 順央（かわぐち まさてる） ライフロボティクス株式会社
- 6. 形式手法とは 6 形式的仕様記述とは 数理論理学等に基づき品質の高いソフトウェアを効率よく開発するための 科学的・系統的アプローチ※ ※ http://research.nii.ac.jp/~f-ishikawa/work/files/2012-05-11-SQiP-intro.pdf より 明確で厳密 高い信頼性が期待 分析・検証が可能 導入コストが高い（と言われる）
- 7. まずは仕様を書くことから 7 形式的仕様記述とは 数学的な記述が可能である形式仕様記述言語を用いて仕様を記述するレベル 0 形式仕様を詳細化することでプログラムを開発、または プログラムの性質を証明する レベル 1 プログラムの性質を自動的に検証するレベル 2 形式手法の適用レベルは、http://formal.mri.co.jp/outline/ より
- 8. 形式的仕様記述だけでも効果は期待できる 8 形式的仕様記述とは 厳密な記述で成果物の品質をあげる一方、 記述だけにとどめて導入コストを抑える狙い 明確で厳密 高い信頼性が期待 分析・検証が可能 導入コストが高い（と言われる）
- 9. なぜ仕様なのか？ 9 形式的仕様記述とは 仕様はすべての開発の原点となるから 仕様 設計・実装 検証 マニュアル 作成 見積もり 計画 進捗管理
- 10. 実際に見聞きした仕様書にまつわる問題 10 形式的仕様記述とは 1. 仕様書がない 2. 仕様書の記述が曖昧だ 3. 仕様書に画面イメージしか書いてない 4. どのボタンが効くかは書いてあるが、効かないボタンを押した時に何がおきるか書いてない 5. どの仕様書が最新版かわからない 6. 仕様書に、何が書いてあって、何が書いていないのか、わからない 7. 仕様書っぽいものが書いてあるドキュメントが複数あるが、どれが仕様書かわからない 8. 仕様書はあるが、ほとんど何も書かかれていない 9. 仕様書に書いてないので、設計者が勝手にこうだろうと決めてつくったけど、あとでひっく り返されて作り直し 10. 仕様書がメンテされない。実態とかけ離れている
- 11. 形式的仕様で解決する問題 11 形式的仕様記述とは 1. 仕様書がない 2. 仕様書の記述が曖昧だ 3. 仕様書に画面イメージしか書いてない 4. どのボタンが効くかは書いてあるが、効かないボタンを押した時に何がおきるか書いてない 5. どの仕様書が最新版かわからない 6. 仕様書に、何が書いてあって、何が書いていないのか、わからない 7. 仕様書っぽいものが書いてあるドキュメントが複数あるが、どれが仕様書かわからない 8. 仕様書はあるが、ほとんど何も書かかれていない 9. 仕様書に書いてないので、設計者が勝手にこうだろうと決めてつくったけど、あとでひっく り返されて作り直し 10. 仕様書がメンテされない。実態とかけ離れている 全部は解決しない 残りの問題には別のアプローチが必要！
- 12. 仕様書をバージョン管理することで解決する問題 12 形式的仕様記述とは 1. 仕様書がない 2. 仕様書の記述が曖昧だ 3. 仕様書に画面イメージしか書いてない 4. どのボタンが効くかは書いてあるが、効かないボタンを押した時に何がおきるか書いてない 5. どの仕様書が最新版かわからない 6. 仕様書に、何が書いてあって、何が書いていないのか、わからない 7. 仕様書っぽいものが書いてあるドキュメントが複数あるが、どれが仕様書かわからない 8. 仕様書はあるが、ほとんど何も書かかれていない 9. 仕様書に書いてないので、設計者が勝手にこうだろうと決めてつくったけど、あとでひっく り返されて作り直し 10. 仕様書がメンテされない。実態とかけ離れている
- 13. 開発プロセス上で仕様書を定義することで解決する問題 13 形式的仕様記述とは 1. 仕様書がない 2. 仕様書の記述が曖昧だ 3. 仕様書に画面イメージしか書いてない 4. どのボタンが効くかは書いてあるが、効かないボタンを押した時に何がおきるか書いてない 5. どの仕様書が最新版かわからない 6. 仕様書に、何が書いてあって、何が書いていないのか、わからない 7. 仕様書っぽいものが書いてあるドキュメントが複数あるが、どれが仕様書かわからない 8. 仕様書はあるが、ほとんど何も書かかれていない 9. 仕様書に書いてないので、設計者が勝手にこうだろうと決めてつくったけど、あとでひっく り返されて作り直し 10. 仕様書がメンテされない。実態とかけ離れている
- 14. プロセスを決めてその通りに運用することで解決する問題 14 形式的仕様記述とは 1. 仕様書がない 2. 仕様書の記述が曖昧だ 3. 仕様書に画面イメージしか書いてない 4. どのボタンが効くかは書いてあるが、効かないボタンを押した時に何がおきるか書いてない 5. どの仕様書が最新版かわからない 6. 仕様書に、何が書いてあって、何が書いていないのか、わからない 7. 仕様書っぽいものが書いてあるドキュメントが複数あるが、どれが仕様書かわからない 8. 仕様書はあるが、ほとんど何も書かかれていない 9. 仕様書に書いてないので、設計者が勝手にこうだろうと決めてつくったけど、あとでひっく り返されて作り直し 10. 仕様書がメンテされない。実態とかけ離れている
- 15. 仕様にまつわる問題の解決法まとめ 15 形式的仕様記述とは 形式的仕様記述だけでなく包括的なアプローチが必要 形式的仕様記述で厳密に記述する 仕様書自身を定義する バージョン管理を使用する プロセスを決めて運用する
- 16. 形式的仕様記述を入れる上での心配点 16 形式的仕様記述とは 1. 重くないか？開発効率落ちたりしないの？ 2. 現実的に導入可能なコストなのか？ 3. 仕様書を書くの大変そう。仕様書をメンテナンスするのも大変そう 4. 変更にかかるコストが形式的にしたことによって影響受けるか？ 5. ステークホルダー全員がどうやってやりとりするのか？全員読めるのか？ あとで検証します！
- 20. 仕様書をつくる ー 仕様書に何をどう書くか決める 20 導入の計画と現実 HW, SWに関わらずユーザから観測できる特性を記述する 特性は客観的に評価できる形式で記述する（定性的ではなく定量的に） ソフトウェアの振る舞いは状態遷移モデルで書く スクラムだけどシステム全体の仕様を最初に書く
- 21. 仕様書をつくる ー 仕様記述言語 21 導入の計画と現実 n : Int xs : String List [n = 0] ev1(m : Int) / n’ = n + m; xs’ = [] s0 s1 s2 事前状態 イベント ガード条件 事後条件 事後状態 s0 ev1(m : Int) n = 0 n’ = n; xs’ = [] s1 s1 ev2(s : String) True n’ = n; xs’ = xs ^ [s] s2 ev2(s : String) / n’ = n; xs’ = xs ^ [s] システムの振る舞いを変数拡張した状態 遷移機械で表す 実際には状態遷移表の形で表現する 変数の条件式を独自の言語で書く VDMとHaskellを足したような言語
- 22. 仕様書をつくる ー 仕様書はEXCELに 22 導入の計画と現実 電源 OFF 初期化 画面 アーム操作 画面 ひとつの画面を状態遷 移機械のひとつの状態 （丸）にする ひとつの状態の遷移を ひとつのシートに書く
- 23. 仕様書をつくる ー UI仕様と形式的仕様記述 23 導入の計画と現実 画面のイメージとボタンなどのUIパーツの配置 各UIパーツを操作したときにどんなことが起きるかが自然言語 で説明してある その画面で起きるすべてのイベントについて遷移について、論 理式および自然言語による説明がある UIパーツの配置、色については言及しない UI仕様 形式的仕様記述
- 24. 仕様書をつくる ー 形式的仕様記述の効果 24 導入の計画と現実 ただ事後条件の論理式を書いているだけなのにUI仕様で見つけられなかった 多くの考慮もれを見つけることができる – 事後条件を書くときに、変化しないものも含めてすべての状態変数について事後 条件を考えるため。プロトタイピングに近い効果がある – UI仕様の段階で複数人によるレビューで考慮もれがないことを確認したはずだっ たのに。従来の仕様書では気づくことができない。不十分！ 中にはソフトウェアのアーキテクチャに影響を及ぼしそうなものもあった – たとえば、画面の編集中の状態をどこまで永続化するか？ – これは、その画面に入ってきたときの事後条件を書くことで発見
- 25. 仕様書をつくる ー 形式的仕様記述するうえでのTips 25 導入の計画と現実 不変条件を書く – システム全体としてどういうルールで振舞っているのかは、不変条件で表す。 不変条件に書かれていないと、全部の遷移の事後条件を見て「あっ、こうい うルールなのね」とやらないといけない 高階関数より内包表記を使う – map f (filter p xs) ではなく [ f x | x : xs & p x ] どうしても書けないところは、”given”として自然言語で説明を書く
- 26. 仕様書をつくる ー 計画と現実まとめ 26 導入の計画と現実 UI設計者が書いた画面イメージ + 簡単な操作のUI仕様 から仕様書を起こす（状態遷移モデルに書き換え） いくつかの画面を先に書いたら、あとはみんなで手分 けして書く 計画 全部の画面を一人で書く 30状態、1061遷移、作成期間約1か月 レビューは手分けできた。意外とみんな読める。 レビューもできる。説明自体は2時間程度 現実 一番効果を感じる（恩恵をこうむ る）のは仕様書作成時 多くの考慮漏れ、コンセプトの矛盾 を発見することができた
- 28. 設計・実装する ー 計画と現実まとめ 28 導入の計画と現実 設計者は仕様書を確認しながら設計をする 設計時に気づいた仕様変更が必要そうな箇所はその場 で提起 計画 UI仕様および形式仕様に対してレビューをしていたた め、頭に仕様が入っていると思いこんで設計 設計レビューや実装時に仕様を満たしていないものを 発見 現実 仕様をレビューしたときの記憶があ る中、設計したものが仕様を満たし ているかを確認するのは手間に感じ られた 仕様のモデルの構造とプログラムの 構造が一致しないうえ、ツールのサ ポートがないので二重苦
- 30. 検証する ー 検証チームがいない！ 30 導入の計画と現実 テストエンジニアが作成した テスト項目表とテスト手順書をもとに、 テストチームが テストを行う よくあるテスト 開発者が仕様書に追記した 状態遷移ごとのテスト項目をもとに、 （学生アルバイトの）検証者または開発者が テストを行う 今回のテスト 論理式を読んでもらうのはつらいだろうから 以下の項目を自然言語で説明 1. 検証する遷移のガード条件 2. ガード条件を満たす手順 3. 事後条件を確認する手順 （画面から明示的にわからないものだけ説明 を追記）
- 31. 検証する ー 計画と現実まとめ 31 導入の計画と現実 遷移のガード条件ごとに検証する項目を記述。事後条 件は自然言語の方を見れば確認できる 遷移のみを確認するだけではいわゆるユーザビリティ テストが行われないし、網羅性も不安だったので＋α で遷移の周辺で好きに触ってもらった 計画 ほとんどのバグは＋α の検証で出る 自然言語で書かれた事後条件では読み切れず、結局検 証者も論理式を読む 検証者が論理式の間違いを指摘してきたりした 現実 自然言語だけで通じるようには、か なりの分量を書く事になる（文章と してまわりくどいくらい）論理式が 読めるのであればありがたい 遷移だけのテストでは足りない。遷 移という局所的な視点だけでなくシ ステム全体を捉えてテスト設計する 必要がありそう
- 33. 仕様を変更する 33 導入の計画と現実 仕様変更チケットをきって、開発者が集まって採用・ 不採用を決定する 仕様書を変更したらGitへpush 計画 EXCELだったのでGitに入れていても差分はたいして見 れないし、変更も衝突するので大変だった 現実 仕様が厳密だったことで、変更が必 要か否かの判断はしやすかった Gitでバージョン管理する場合は EXCELで書いたらだめだなと心底 思った
- 35. 結果 #1 - QCD 35 導入の計画と現実 Quality Cost Delivery So so バグ密度（バグ数/1KLOC）は1.73. Excellent !! 計画の日程で出荷判定合格 Good ! 仕様が形式的だから増えたという感覚はない
- 36. 結果 #2 – 形式的仕様で解決する問題（再掲） 36 導入の計画と現実 1. 仕様書がない 2. 仕様書の記述が曖昧だ 3. 仕様書に画面イメージしか書いてない 4. どのボタンが効くかは書いてあるが、効かないボタンを押した時に何がおきるか書いてない 5. どの仕様書が最新版かわからない 6. 仕様書に、何が書いてあって、何が書いていないのか、わからない 7. 仕様書っぽいものが書いてあるドキュメントが複数あるが、どれが仕様書かわからない 8. 仕様書はあるが、ほとんど何も書かかれていない 9. 仕様書に書いてないので、設計者が勝手にこうだろうと決めてつくったけど、あとでひっく り返されて作り直し 10. 仕様書がメンテされない。実態とかけ離れている
- 37. 結果 #2 –形式的仕様で解決した！ 37 導入の計画と現実 1. 仕様書がない → 解決した 2. 仕様書の記述が曖昧だ → 解決した。論理式により厳密に表現 3. 仕様書に画面イメージしか書いてない → 解決した。状態遷移モデルでシステムの振る舞いを記述した 4. どのボタンが効くかは書いてあるが、効かないボタンを押した時に何がおきるか書いてない → 解決した。イベントのガード条件を明記。変化しないものは変化しないと記述した
- 38. 結果 #3 – 心配していた点はどうだったか？ 38 導入の計画と現実 1. 重くないか？開発効率落ちたりしないの？ 2. 現実的に導入可能なコストなのか？ 3. 仕様書を書くの大変そう。仕様書をメンテナンスするのも大変そう 4. 変更にかかるコストが形式的にしたことによって影響受けるか？ 5. ステークホルダー全員がどうやってやりとりするのか？全員読めるのか？
- 39. 結果 #3 – 心配していた点はそうでもなかった 39 導入の計画と現実 1. 重くないか？開発効率落ちたりしないの？ → あくまで体感だが、重いという印象はない。スケジュール遅延なし 2. 現実的に導入可能なコストなのか？ → 最初に仕様書を書き上げるのは大変だけど、できなくもない 3. 仕様書を書くの大変そう。仕様書をメンテナンスするのも大変そう → 最初に書くのは大変。でもこれは形式的だからというよりシステムの複雑さに依存する。 → メンテナンスはEXCELでなければよかった
- 40. 結果 #3 – 心配していた点はそうでもなかった 40 導入の計画と現実 4. 変更にかかるコストが形式的にしたことによって影響受けるか？ → 変更の必要の有無を判断しやすくなったのでむしろ良くなった 5. ステークホルダー全員がどうやってやりとりするのか？全員読めるのか？ → 自然言語を併記すれば割と読める。ただし、自然言語だけだと正確に読めないところもある → 自然言語だけでは記述が十分がどうかはほとんど判定できない
- 41. 結果 #4 – 実は大きい副次的な効果 41 導入の計画と現実 プロジェクトを成功に導いた良い副次的な効果があった 仕様に対する安心感 設計・実装の少ない手戻り 合意形成の容易性 合理的なゴール設定が容易に
- 42. 結果 #4 – 実は大きい副次的な効果 42 導入の計画と現実 仕様に対する安心感 – 「メンバーで合意した仕様は仕様書に必ず書いてある」という安心感。すべての作業をまず仕様から、 とできた。 合意形成の容易性 – 記述が厳密なので仕様がどう規定してあるかについてぶれない。同じ議論の蒸し返しは少なくなる 設計・実装の少ない手戻り – いったん決めた仕様は大きく暴れない。そのため、設計・実装の大きなやり直しがなかった 合理的なゴール設定が容易に – 仕様が安定すれば、以降の作業を見積もりやすい。その結果、プロジェクトの見通しが増す
- 43. 結果 #5 – 開発メンバーの感想 43 導入の計画と現実 自然言語で書かれると読む人によって解釈が多様になるけど、論理式だと曖昧さがない 日本語と併記している仕様を見ると、日本語の不明瞭さがよくわかる 齟齬が生じにくいのでコミュニケーションが取りやすかった 仕様の漏れに気づきやすい 自然言語と併記されていると読むのは何とかなるけど、書くのは難易度高い 最初はとまどった。今までは要求仕様書といったレベルのものばっかりだったので 仕様に基づいて作業するときに，何を実現すればいいのかが明確になった 検証作業を行った時も、どういった条件で何を検証すればいいかが分かりやすかった 形式的仕様記述について
- 44. 結果 #5 – 開発メンバーの感想 44 導入の計画と現実 最後まで仕様書メンテしたのは初めて 仕様にテスト項目まで書くとそのまま検証に出せるのは楽だった 遷移のすぐ隣にテスト項目が書いてあるので自分で検証する時すごい楽だった 仕様書を中心にしたプロセスについて もともとは自然言語やフローチャートで業務系のアプリケーションの仕様を書いていたため、 最初は「形式仕様記述とか，まじかよ」と敷居を高く感じていたが、実際は慣れるまであまり 時間もかからず、開発メンバー間でのコミュニケーションがとても取りやすいことに気づき、 （今現在痛切に）仕事が非常にやりやすかったと感じた ある開発者の心にしみる感想
- 46. 総評と課題 46 まとめ 厳密に記述できる形式的仕様記述は仕様書の品質を飛躍的に向上させる 品質の高い仕様書は、プロジェクトに確度の高い見通しを与える メンバーで共有するためには、自然言語による併記が重要な役割を果たす 総評 論理式で事後条件を書く人を増やす 論理式を読めない相手に自然言語だけで十分に伝えるにはどうするか？ 前段階で仕様を作りきらずに開発をすすめた場合はどうなるのか？ 関数型で実装するときにどれくらい効果が残るのか？ 課題
- 47. その後（いま現在）は 47 まとめ 形式仕様は継続。メンバー全員が価値を認めている EXCELはやめた 状態遷移モデル全体を記述できる仕様記述言語をつくった。 – テキストで書いてコンバータでMarkdownを経由してHTMLに変換
- 48. 最後に ― 導入にむけて 48 まとめ まずは（部分的でも）とにかくはじめてみる 良さを見つけたら、少しずつ利用範囲をひろげていく