九州が、あつい!! ～SPL&MDDセミナー受講記～ (続き)

九州が、あつい!! ～SPL&MDDセミナー受講記～の続きです。

３月２５日に福岡で行われた、『プロダクトラインセミナー』＋『モデルベース開発セミナー』の午後の部についてお話しします。

午後の部も、午前に負けず劣らず、”あつい” セミナーでした。

『自動車業界におけるモデルベース開発事例』と題した午後の前半では、
　・自動車業界で実際に行われていモデルベース開発事例についてのご紹介
　・車載システム仕様化・検証技術として、EAST-ADL2(*)を使った仕様記述の紹介
　　　(*) EAST-ADL2 ：SysMLをベースに車載ドメインに特化した仕様記述言語の定義
　　　　　　(株)デンソー 佐藤洋介氏の資料より
の２本立てでした。

これまで、車系ドメインにはかかわってこなかった私にとっては、たいへん難しい内容でした。
しかし、先端を行く車関係のソフトウェアが、どのようにして上流で品質を確保しているかが垣間見え、とても勉強になる２時間弱でした。（私の勉強が足らず、詳しいレポートが出来ません。。。）

午後の後半は、『モデルベース開発とSPL・九州地域の取り組み』と題していました。
　・MDDを使ってSPLを加速する方策として、MDDツールを使いながら共通部を開発する技術的な事例紹介
　・九州技術教育専門学校における、初学者へのMDD教育事例の紹介
という、こちらも2本立てです。

エプソンの島氏による、『MDDを使ってSPLを加速する』 の内容は、技術者にとって実践寄りの内容でありました。

”MDD：モデル駆動開発”と聞くと、ベタベタな実装を知らずして、モデルのみでプログラムを語る世界と思われる方もいるかもしれません。しかし、島氏の講演は、そのイメージを払拭するモノでした。

島氏の講演内容は、以下の４つのブロックからなっていました。
　(1) プロダクトライン開発にいたる道
　(2) モデル駆動開発
　(3) よいモデルとは
　(4) ソフトウェアプロダクトライン

(1) の中での島氏は、
構造化 → オブジェクト指向 → モデル駆動 → プロダクトライン開発 とシステムの規模が大きくなり、色々な設計技法を用いて行っても、最初の構造化で作ったコードは一部残る。
また、MDDはあくまでもツールであり、ゴミのようなモデルをINPUTすると、ゴミのようなコードしかOUTPUTされない。
と仰っています。
凝集度・結合度、可変部・共通部の切り分けなど、何が”よいモデル”かを考えられなければ、MDDにもつなぐことも出来ないということでしょう。

このセミナー午前中のパネルディスカッションと同じことが言われています。
ソフトウェア工学的な、基礎知識を持たずして、MDDもSPLもうまくいくわけがないのです。

現在のソフトウェア開発は、ゼロからアーキテクチャを設計するのではなく、何らかの既存システムがあり、そこから派生（一部部分の取込みも含め）であることがほとんどです。
そのような事情の中では、旧来の技法（構造化など）による設計知識も、まだまだ必要です。
更に、一段新しい技法に取り組む（例えば、構造化設計のコードをオブジェクト指向に乗せ変えていく）ためには、両側に関する知識を持ち、よいアーキテクチャにしていくためには、新旧のコードをどのようなインタフェースで接続するか設計できるかが重要だと思います。

また、島氏は翌日のTwitterで、こんなことも呟かれていました。

『午前中（島氏の講座の前）に責務・凝集度/結合度、構造化、RTOS並行性分析、タスクマッピング、リバースモデリングの基礎みたいなのをやってもらえると、私のSPLの話がやりやすいんだけどなあ。結局やっているのは、プロダクトラインに近づけるためのモデリングトレーニング。』

『技術的には、構造化設計とオブジェクト指向設計・デザインパターンくらいまでなので、新技術紹介じゃないし。(島氏の作られたセミナー資料には)数値データを出さないので経験論文じゃないし、製品に使っているモデルは皆無なので実例紹介でもないし、基礎教育用の教材と思っています。』

私はこのBlog.などでも、日ごろから「構造化設計の基礎知識を身につけましょう」というお話をするようにしています。MDDであれ、SPLであれ、それら技法に取り組むには、開発の基礎体力が必須です。
「構造化設計なんていまさら...」 とか、 「オブジェクト指向なんて使えないよ...」 なんて、後ろ向きな方がいらしたら、ぜひ今回のようなセミナーを聞いていただきたいと思いました。

～余談～
島氏のプロダクトライン実践は、SESSAMEの主催で東京近辺で1～2日間のセミナーが実施されるそうです。

九州が、あつい!! ～SPL&MDDセミナー受講記～

2011年 ３月25日(金)に、福岡にて行われた下記のセミナーに参加してきました。

『プロダクトラインセミナー』＋『モデルベース開発セミナー』
　　午前の部：プロダクトラインセミナー　　～SPLへの最初の一歩としてのXDDP～

　　午後の部：モデルベース開発セミナー　　～モデルベース設計・検証事例～
　　　　第一部　・・・　自動車業界におけるモデルベース開発事例
　　　　第二部　・・・　モデルベース開発とSPL・九州地域の取り組み

午前の部は、
　　前半は、派生開発特化したプロセス：XDDPについての紹介　（講演）
　　後半は、SPLの導入について（XDDPはSPL導入として使えるか）をテーマにした、パネルディスカッション(*)
　　　　(*) パネル登壇者については、ES-Kyushu のセミナー告知をご覧ください
でした。

私の先月のBlog記事をお読みいただいていた方は、「おやっ どっかで見たような．．．」と思われた方もおいでではないでしょうか。 昨年１１月に行われた、JASA主催のETセミナーとそっくりです。（こちらのセミナーについては、プロダクトラインと派生開発（その２） で触れています。）
似ているどころか、開催・企画もJASAで、後半のパネルディスカッションは、１１月のセミナーのまとめをスタート地点として、話が始められました。

前回と今回のパネルでの大きな違いは、SPLを全社導入を試みた、富士通九州ネットワークテクノロジーズ(株)（以下、九ネット）の岩崎氏がパネラーに加わっていたことでしょう。『SPLを導入するためには．．．』 というお題に対し、九ネットさんの事例で、どうであったかというコメントが要所要所でお話くださいました。

このパネルで記憶に残った登壇者の皆さんのコメントに、以下のようなものがありました。

九ネット　岩崎氏：SPLが成功するための下地としては、（社内で）開発プロセスがしっかりあった。　ものの本から、実践できる開発プロセスに落とし込むのは、かなり大変。　元々プロセスができていれば、そこにアドオンする形でSPLを取り入れるのなら可能である。

SRA 林氏：SPLに取り組むためには、２Fに上がる梯子(**)を一歩一歩上がっていくことを知っていれば、決して難しいことではない。SPLは体質改善（生活習慣を変える）である。それを維持していくことが難しい。また、それを実施するための熱意が必要。それを発する人が一人以上いて、継続していくことが重要（これは、教科書には書かれないポイント！！）。
　 　　(**) SPLは２階建ての２Fの技術、ソフトウェア工学的基礎体力が１Fにある。
　　　　　　　　　　という、前回パネルのまとめのお言葉から。

XDDPの清水氏：XDDPによって、SPL実施のための下地作りはできる。近い将来SPLを考えないと、プロダクトとしてはどんどん他社に後れを取る。早く取り組まないと、後発開発は短期開発に迫られ、また新しい技術を取り入れる余裕もなくなり、差が開く一方になる。

といった、かなり熱い（というか、渇！って感じ）のお言葉。
パネル自体も、後半になればなるほど、話が盛り上がり、質疑も熱さを増すなかでの締めくくりになりました。
また、その間の会場の皆さんも、かなり必死にメモを取っていらっしゃいました。

組込みソフトウェアに限らず、短期に品質の高いソフトウェアを開発できる体質づくりが、早期に求められているのは、納得です。
その体質づくりは、大規模開発の現場以外でも、必要であると思います。
プロダクト開発と並行して、体質づくりは進められる。いつ着手するかなど、迷っている場合ではなくなってきている。
と、今回強く感じました。

．．．さて、長くなりましたので、午後のセッションについては、次の記事にてご報告とします。

原因結果グラフを使った仕様書分析

先日（っといっても、2週間前）、ソフトウェアテスト系コミュニティの方々が、原因結果グラフの勉強会をやると聞いたので、突如参加させてもらいました。

この勉強会は、テスト技法ドリルをベースに、毎回いろいろな技法についてについての勉強を行う会なのだそうです。その第3章に、入り組んだ論理関係を確認する技法として、原因結果グラフによる分析が書かれています。
　　書籍：　ソフトウェアテスト技法ドリル　　～テスト設計の考え方と実際～
　　著者：秋山浩一さん
　　出版：日科技連盟　

ここで、仕様書から原因結果グラフを検討する方法を学びました。これは、仕様書から開発対象物を分析する一手段であるため、テストにかぎらず、設計前の分析にも役立つものだと思います。

ということで、早速LEDキューブシステムの仕様書で試してみましたので、ご紹介します。

分析元となる仕様書は、CQ出版のサイトで公開しているもの（USDM版ではない方）です。
ソフトウェア要求仕様書

この仕様書の3ページ目にある、動作概要を分析してみました。

手始めに、習ったとおりに仕様書をよく読み”機能”を探してみました。
その際の作業としては　
　・ 動詞句を探し出す
　・ 動詞にかかる、目的語を探す
から、始めています。 （実際に仕様書に、これらの印を入れたモノはこちら → _forcegtest.pdf ）

そこから、この仕様の中の主機能を探し、その機能を”結果ノード”に据え、それを導き出す”原因ノード”を検討しました。その結果できたのが、こちらの原因結果グラフです。

※ 原因結果グラフの作成には、加瀬正樹さんが作られたフリーツール CEGTest(セグテスト) を使いました。

～試してみた感想～
今回は、「動画概要」を取り上げて、原因結果グラフで分析してみました。
書いてみて感じたのは、どうも分析するターゲット範囲が広すぎたのではないかということです。その理由は次のような点です。
　・概要を取り上げてしまったため、分析したページ内にすべての原因が示されているわけではない。
　　　→　実際、”表示動作の移行”の原因ノードには漏れがある。
　・原因結果グラフは、粒度の大きい機能の分析には向かなかったのではないか？
　　　→　原因結果グラフは、論理関係からデシジョンテーブルを導きだせるものであり、
　　　　　　抜け漏れのない組合せ検討などのためには適していそう。
　　　　　　今回対象にした機能は、たくさんの子機能を包括してしまっていて、原因ノードが多量になる。
　　　　　　原因が多量になると、グラフ表示が複雑になり、グラフによるレビューでも漏れが発生しそう。

反対に、ターゲット範囲（結果ノードの粒度）を絞り込んでの分析には、適しているのではないかと思いました。
たとえば、エラーに関してや、一つの操作による結果など、機能を限定しての分析には良さそうに感じています。（この辺は、もう一度範囲を絞って原因結果グラフ作成を試みたい）

試してみて良いなと思った点は、機能項目間の関係性が、この方法では示せます。
Interface紙面上では、USDM表記による仕様分析を紹介しています。USDMを使っていて気になるのは、機能間の関連性（排他や連動など）が示せないことです。
USDMによる仕様書と併用しての分析という使い方もないものか．．．と、思ったりしました。

（注意＆お願い）
今回試しに書いた原因結果グラフ自体に、用法の間違いなどあるかもしれません。あくまでも、こんな感じ... という参考程度にご覧ください。

自分に出来ること。。。

3月11日の東北地方太平洋沖地震にて、被災された皆様に、
心よりお見舞いを申し上げます。

週に一度のペースでは何か書いていこうと思って始めたこのBlogですが、ここ2週間はすっかりお休みしてしまいました。
震災後の様子を見ていて、のんきにBlog書いていて良いのだろうか。。。と、気持ち的に迷いがあり、手を付けずにいました。しかし、他に自分に何が出来るか。。。　
正直未だにわかりません。
ただ、経済活動を支えるため、また安全・安心なソフトウェア開発につなげるために、Blogに書くことがきっかけにや一助になってもらえればと考え、再開することにしました。

ちょうど今日、Interface誌の第6回目原稿も編集さんに送りました。
これからも、C言語ベースで改善していく方法を、書き続けていきます。

組込みソフトウェア開発者にとっての要求仕様書

今回は、「強いプログラムを作る・・・」 の連載第3回に絡んだお話をします。

第3回目は「要求分析の重要さと難しさ」というお話にしました。
この連載の中ではちょっと毛色の変わった回です。

正直な話をすると、”要求” という存在を考え始めたのは、私が開発を初めて10年を経てからでした。
ある年、期間限定で部署をまたいだプロジェクトチームが組まれ、開発・製造・購買・営業それぞれの担当者がメンバとなり、製品企画の段階から皆で検討するという試みが行われたのです。そこで、製品企画に触れ、開発以外の立場からのコメントを聞いて、初めて 製品に対する要求 を意識しました。

それまでの開発では、
ソフトウェアの開発スタート時に受け取る「要求仕様書」は、ハード担当が作成して渡すもの。
ソフトウェア担当は、その指示に従い作るもの。　
と、何も考えずに作っていました。
また、実際にその「要求仕様書」の内容的は、”要求” というよりも、”機能仕様” ・ ”制御仕様” の内容が、多くを占めていました。

第3回の記事でも、そのような環境を想定して、要求仕様書を実機（LED Cube）を作ってくれた方に、書いてもらいました。

　　　　　仕様書１：ソフトウェア要求仕様書　　⇒　

※ Interface ダウンロードページの3月号「組み込みで使うVisual C#と.NET Micro Framework」から、全篇 download できます。
　（USDM版ではないほうです）

本編の記事では、”「要求」と「仕様」の違いを理解する”　という話を入れました。
それは、前述のような環境にいたからこそ、強く必要性を感じたのです。

そして、そこをもう一歩踏み込んで
　「何故、要求仕様といいながら、”要求” が見えないことが多いのか？」
を、考えてみました。

その結果、
　「 組込みソフトウェア開発においては、要求仕様の発生元が、開発の内情をある程度知る人であるからかも．．． 」　　と、思ったのです。

組込みソフトウェアの場合、エンドユーザから要求仕様書が発生することは、滅多にありません。
企画や営業さんなどの手を経て、開発への要求仕様が作られます。（ましてや、ソフトウェアについては、開発内部で作成されることもしばしば）
ここで特徴的なのが、それらの人たちは、 どのような要素技術を持っているか、過去の開発製品はどんなものかを予め知っていることです。

特注品のようなケースで、直接お客様の要求を聞く様な場合でも、お客様はこちらが　何が得意か、何ができるか　を見て、注文先として指定してきているのです。

このよううに、要求仕様の発生元と、開発のと距離がある程度近いのです。
そうなると、「要求仕様」 を作成する際にも、元々ある機能仕様などをベースに考えて、作って欲しいものを、より具体的に表現してきてしまう のかもしれません。

開発側が機能仕様書として作るものを見ても、要求元と開発の距離の近さがわかるのではないでしょうか。

そんな事情がある組込みソフトウェア開発ですから、
開発担当者も、もらった要求を、そのまま作るのではなく、”要求仕様” と ”機能仕様” を分離して理解する。その上で、（要求仕様の発行元さえも気付かない）本当に作るべき仕様を考える。
という分析が、大切なのではないかな。と思った次第です。

この第3回の最後にも書きましたが。。。
この回の記事は、ビギナー向けではなく、中級以上向けでした。
そこは、見逃してください。 それでも、書きたかったんです。　　

※　関連記事：　Interface 2011年3月号