カテゴリー「派生開発」の記事

2011年6月21日 (火)

コード解析にDFDを使う?

最近すっかり、ブログすっかりご無沙汰しておりました。なんと、6月入って初ネタとは... いかんっすね。

さて、今日のお話はリバースモデリングネタです。
このブログでは、リバースのお話するのは初めてですが、実は前から、コードを読んでアーキテクチャ解析をするところに非常に興味を持っています。(...というか、ぶっちゃけお仕事も)


2011年6月17日(金)に、派生開発カンファレンス2011というイベントがありました。この講演プログラムの2番目に、
 「完全無知権プロジェクトにおける、変更要求仕様書の作成手法」
といった発表があったのです。
ここで言う”無知見”とは、派生開発元のプログラムについて知見がなく、開発ドキュメントもないような場合(例えば、外注で開発したソフトを扱う場合など)を指しています。つまり、派生開発する際のベースは、コードから読み解くしかないような場合です。
この発表では、コードを読み解く際の調査資料として、階層化DFDとAFD(*)、それとシーケンス図を用いるというものでした。

この方法では、コードから、最初に階層化DFDを作ります。
...ん?? ここで疑問が...
コードを読んで、DFDは描けるのか? コード上のオブジェクト間の関連性は、DFDになるのか??

発表資料をよく見ると、コードからデータフローを読み解き、変更要求仕様の階層化記述に使われています。
どうやら、コード上の構造を表すのではなく、コードを理解した結果の”機能”をDFDで表現したもののようです。
なんとなく、納得です。

DFDを使ったリバース方法については、XDDPの生みの親、システムクリエイツの清水さんが編み出したようです。
とっても気になる方法なので、今後も追跡してみたいと思いました。

(*) AFD:アーキテクチャ・フロー・ダイアグラム(?)
  下記の本にて登場するモデル図のようです。私も、このモデル図については確認取れていません。
  リアルタイム・システムの構造化分析 ~リアルタイム・システムの仕様書作成手法~
  Derek J.Haltley (著), Imtiaz A.Pirbhai (著), 立田 種宏 (翻訳)

2011年4月12日 (火)

USDMで仕様書を書いてみた

「強いプログラミングを作るテクニックを学ぶ」の連載3回目で、『要求分析の重要さと難しさ』というサブタイトルで、要求仕様の分析について取り上げました。その中で、USDM(*)という仕様書の表記をご紹介しました。
 ※ LEDキューブシステムUSDM版仕様書 >> Download : specofledcube_specusdm_v1a.xls

このUSDM版仕様書をご覧になった皆さんは、どう思われたでしょう?
私も当初は、ドキュメント形態として重くて面倒だな...と思っていました。その後、いろいろ試す中で、USDMを使うのも悪くないなと思うようになりました。その理由を、3つばかりご紹介しておきます。

【こんな時に、USDM作ってみてよかったと思った】

(1) 仕様理解のために使う
連載本編でもこの方法をご紹介しました。
以前から、仕様書を読んでQ&Aシートを毎回作っていましたが、それでも理解の漏れ、勘違いはあります。USDM表記法に則り、理由を考えて要求・仕様を埋める。Defaultや、異常系など、各要求項目に対して決まったルールで仕様を確認する。などにより、抜け漏れ、勘違いのフォローができました。
... 気が向いたら、Interface誌 3月号で詳細は読んでみてね。

Usdm_sample1
(2) 仕様に対する確認用に使う
実は、これが一番のおすすめポイントだと思ってます。
ご紹介したUSDM仕様書、CQ出版さんのサイトからダウンロードすると、各仕様項目のところに3つのチェックボックスが点いている事に気づいた方いらっしゃいますでしょうか? これは、後工程での確認用に作ったものなのです。

●仕様の確認で1コ目にチェック
要求元と仕様の確認ができたところで、確認済みのチェックを入れます。仕様未定の部分があれば、次工程に進めるために必要な仮仕様を書いて、チェックボックスには“未”の印をつけておきます。そうすることで、この仕様に絡む箇所は、後で仕様変更がでてくる可能性があることが見て取れます。

●設計レビューで2コ目にチェック
(基本設計などのレベルではなく、)実装目前の設計レビューでチェックを入れます。
これについては、” (3) 保守・派生開発時のベース資料 ”↓ のほうで詳しく説明します。

●テスト設計で3コ目にチェック
どの仕様に対して、テスト設計してテストケースを作成したかを確認した時点で、チェックを入れます。


Usdm_sample2
(3) 保守・派生開発時の資料として使う
一旦作ったシステムも、保守・派生開発時には、システムの設計を知るための資料が必要です。それを、このUSDM仕様書に情報を付加して使えるようにしようというものです。

仕様項目の横に、設計した結果、どこでその項目が実現されているのかを、印を付けていきます。
つまり、XDDP(**)で言うところのTM(Traceability Matrix)を作ってしまうのです。設計段階でこのマトリクスを作ってしまえば、後の保守・派生開発時には、これがそのまま影響範囲分析、変更設計のための調査資料として使えます。

また、この方法で仕様と実装の関連を残していくと、凝集度の悪い設計箇所があれば、一つの機能に対し沢山の実装箇所に印が付くことになります。そういった目線で、設計結果を確認することで、設計品質を確かめるためのレビュー資料としても使えます。


USDMの仕様記述は、確かに大変です。
折角手を掛けた仕様書ですから、やはり2度、3度これを使いまわさないと、作った効果は薄いと思います。

...とはいえ、現状のUSDMでは、未だに気になっているところもあります。
 ・EXCELはやっぱり使いにくい
 ・仕様項目間の依存関係が表せない
その辺は自作でツールをつくるなど、改善策を考える必要がありそうです。

しかし、今手持ちのツールですぐに試せる方法です。設計品質をあげるにはどうしたら... っと、手をこまねいて悩んでいるのだったら、お試ししてみるのもありだと思います。


最後に、
Interface誌に掲載するに当たり、USDM版仕様書の作成についてご指導いただきました清水吉男さんに感謝いたします!! ありがとうございました。


(*) USDM : (Universal Specification Describing Manner) 抜け漏れしにくい仕様書の表記法
   関連書籍 『要求を仕様化する技術・表現する技術 - 入門+実践 仕様が書けていますか?』
(**) XDDP: (eXtreme Derivative Development Process) 派生開発に特化したプロセス
   関連書籍 『「派生開発」を成功させるプロセス改善の技術と極意』

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

2011年3月27日 (日)

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

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

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

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


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

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

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


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

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

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

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

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


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


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

 

2011年2月 5日 (土)

プロダクトラインと派生開発(その2)

ソフトウェアプロダクトライン(以下、SPL)と、派生開発のプロセスXDDP(eXtreme Derivative Development Process)についての話の続きになります。

すこし前のことになります。
「SPLとXDDPによる多品種開発の品質と生産性の向上 ~一見矛盾する2つのアプローチの関係をどう捉えるか~」
と題したセミナーが行われ、参加してきました。

はて、疑問です。この二つは対立軸にはないと思われるからです。
その疑問は、最後のパネルディスカッションでも取り上げられ、4名のパネラーの皆さんともに、やはり対立するものではないというコメントでした。

その中で、九州大学の中西先生が、次のように二つを対比してまとめられています。

 
【SPL と XDDP の比較】
SPL XDDP
パラダイム メソトロジ
全体理解を志向 部分理解を容認
組合せを志向
(変化点の抽出が重要)
摺合せの容認
(変化点の概念が希薄)
計画駆動 変化駆動
アーキテクチャ駆動 アーキテクチャ希薄

なるほど、二つの考え方の違いがよく分かります。

SPLは、トップダウン・ボトムアップ2種類のアプローチがありますが、ポイントは全体志向であることでしょう。かならずシリーズ製品全体の仕様を考え、計画的な開発を行う。全体を通して変わらぬアーキテクチャを構築する事で、部分部分の変化点で個別の製品に対応する。そこは、SPLの譲れない考え方です。

対して、XDDPは完全にボトムアップのアプローチです。そして、派生開発の差分となる部分に関連したところだけの部分理解を容認しています。
実は、ここがSPLよりもXDDPの方が取り組みやすいところであり、危険なところであると思います。

既存製品のソフトウェアを隅々まで理解するということは、とても困難で、時間のかかる作業です。その点、部分理解容認というこの手法は、取り組み易い手法といえます。
しかし、製品としてリリースするからには、変更に抜け漏れや勘違いが混入してはいけません。つまりは、部分理解をする際、どこまでを理解すればよいかが、肝になります。その点について、強力な対策が示されていないため、レビューなどによってその点に十分なチェックが必要となるでしょう。


システムクリエイツの清水氏は、二つの関係について次のように言っていました。

SPLは2階建て構造であり、SPLに取り組むには次のような前提が満たされていることが条件である。

【SPLの前提】
  ・SPLに耐えるアーキテクチャ技術はあるか
  ・再利用性の高いモジュール技術はあるか
  ・劣化しにくい最初からの設計技術はあるか
  ・劣化しにくい変更技術はあるか
  ・計画通りに作業を進めることが出来るか

これら前提が満たされていなければ、SPLは遠い存在であり、実施できない。
また、XDDPによる派生開発を乗り越えられないようでは、SPLは成功しない。XDDPは、これらの前提を身に着け、2階(SPL開発)に登るための梯子の役割ともなる。

なるほどと思いました。
アプローチは異なるものの、いずれの方法論にも、ソフトウェア工学の基礎となる設計力、プロセス構築等は必須である。これらを習得せずして、SPLでもXDDPでも、開発の成功はありえないといことです。

ソフトウェア工学の基礎を学習し、XDDPという方法論を用いて日々学習を実践に活かしていくことで、将来SPLへの道筋が見えるのではないかと思いました。

2011年2月 4日 (金)

プロダクトラインと派生開発(その1)

唐突ですが...
ソフトウェアプロダクトライン(以下、SPL)という、近頃流行の言葉をご存知でしょうか?
Software Product Line Engineeringの和訳本(通称:黒本)では、次のように書かれています。

~定義1-3:ソフトウェア製品系列開発(Software Product Line Engineering)~ (p14 より引用)
ソフトウェア製品系列開発とは、プラットホームと大量個別生産を用いて
ソフトウェアアプリケーション(ソフトウェア集約システムおよびソフトウェア製品)を
開発するパラダイムである。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

難しい表現です。

ここで引っかかるのが、製品系列開発と、パラダイムという言葉です。

旧来の製品開発では、個々の製品について、リリースする順番に開発していました。類似製品や、シリーズ製品の場合は、元となるシステムを参考にして、新/旧製品の差分を考えて作ります。
これに対し、SPLでは製品系列として、ひとまとめにして開発を考えるのです。製品系列を通して要求分析が行われ、シリーズで共通となるところ、差異になるところを見極めて開発するため、非常に戦略的かつ、効率の良い開発が見込まれます。

しかし、上記の引用にもあるように、SPLはパラダイムなのです。
SPL本に詳しく手順が示され、それを遵守して実行すればよいという方法論ではありません。
従来の製品開発プロセスが、上手く回っておらず、開発後半のテスト工程で止め処も無く出てくるバグを対策しているようでは、とてもじゃありませんが、すぐに取り組めるものではありません。
全体を見通してプロセスを考える力があり、システムのアーキテクチャがしっかり設計できる力がなければ、とてもじゃありませんが、このパラダイムシフトには乗れないのです。

SPLについて、だいぶ乱暴な説明になっております...
この説明はここまでとし、詳しく知りたい方は、上記の本をご覧ください。


さて、ではSPLにすぐ乗れないからといって、傍観しているだけでよいのでしょうか???
それでは、世の開発スピードから取り残されてしまいます。
なんとかシリーズ開発を、今より効率よく開発が行えないものかと考えるでしょう。


そこで、もう一つご紹介するのが XDDP(eXtreme Derivative Development Process)という、派生開発の方法論です。

派生開発という言葉は、ベースとなるシステムがあり、それに対して追加・変更・削除を行うことで、新しいシステムを開発するということです。まさに、前半で言っていた旧来のシリーズ製品開発そのものです。
XDDPでは、この派生開発を上手くまわすためのアプローチ方法を具体的に提案しています。
システムクリエイツ社の清水吉男さんが生みの親で、その詳しいことは、「「派生開発」を成功させるプロセス改善の技術と極意」という本にも紹介されています。

この方法論は、
 (1) 既存部分を正しく理解し
 (2) 派生開発で行う差分の仕様を見極める
 (3) 差分について設計する
という、きわめて当たり前のことをいくつかのツール(ドキュメント)を使って、手順まで定義しています。
かなり地道なやり方ですが、これを実施することで開発効率の改善が図れるのではないかと思います。


プロダクトラインと派生開発、一気にさわりだけ紹介しました。

組込みの現場は、よりスピードアップが今度も必要になると思っています。
そのためには、今までどおりの開発をしていては追いつきません。何らかの変化が、現場にも求められるでしょう。
開発現場が変化するためには、SPLとXDDP、どちらも有効な考え方です。

この話は、一度で書ききれないので、また続きを書きます。

※ 現在は私自身も、XDDPの方法論が広められるよう、派生開発推進協議会(AFFORDD)の運営委員として活動しています。