無料ブログはココログ

トップページ | 2005年10月 »

組込みシステムについてのセミナー

システム制御情報学会が大阪でセミナーをされるようです。

製品開発に活かせる組込みシステムの基礎と事例

まだ締め切られていないようです。
最近、組み込み関係が元気ですね。

のまタコ!?

のまネコで騒いでいるのは知っていましたが、今度は対抗してのまタコですか!?(ITmediaの記事
裁判慣れしているひろゆき氏だけあって面白いことをやりますね。

ソフトウェアテストシンポジウム

論文締め切りが延びたようですね。

    JaSST'06 in Tokyo

テストと聞くと狭い工程のように感じますが、品質を高める最後の砦ですし、新しい技術を取り入れて工夫する余地の多い工程ですね。最近ではTDD(テスト駆動開発)の話題もありますので、興味深いところです。

個人的には、今回はネタがないので論文はパス、会議のほうは東京か大阪のどちらかには参加したいと思っています。

5つの重要要因

アジャイルと規律によるとプロジェクトがアジャイル計画駆動のどちらのホームグランドに近いかは5つの重要要因で判断できるます。アジャイルのホームグラウンドは
以下のように要に定義されています。

人:手続き的な作業が可能な人は0%、手法を改定カスタマイズ可能な人は35%
  =>希少な熟練者が十分な割合でプロジェクト期間を通じて必要である.
    手法に慣れていない人を使うリスクは高い
変化の度合い:1ヶ月あたりの要求変更の割合が50%程度
  =>変化の度合いが非常に高い環境では設計をシンプルにして
    継続的にリファクタリングするとうまくいくが,きわめて安定した
    環境では再設計のコストが高くつく可能性がある
文化:カオスで反映する割合が90%
  =>高い自由度を持つことによって,快適で権限が与えられている
    と感じる文化で反映する(カオスにおける反映)
規模:小規模(典型的な場合3人月)
  =>小規模な製品やチーム向け.暗黙知に依存しているため
    規模を拡大することは困難である
重要度:
  =>安全性が非常に重視される製品への適用事例はない.
   設計がシンプルで文書が少ないことによる困難が予想される

リーンソフトウエア開発

SEA関西SPINの勉強会に行ってきました。
皆さんとお話していて思ったのは、視点と対象読者が面白いと言うことです。

これまで、いろいろなアジャイル本がありましたが、この本は

  • 既存の技術からアジャイルの説明を試みている
  • オブジェクト指向未経験者をターゲットとしている

と言う点です。上は、前に書いた良い点ですが、下は要注意です。計画駆動の経験がないと、問題点がピンと来ないようです。まあ、アジャイルをやっているなら、余計な説明本かもしれませんが、、、

アジャイル開発を理解するには

アジャイルオブジェクト指向プログラマの開発スタイルから発達したものです。このため、アジャイルの良さを宣伝する人の多くはオブジェクト指向が当たり前に感じている人が多いと思います。このような人たちはオブジェクト指向の、適した対象、熟知した開発者、設計手法、コーディングスタイルなどが前提であることを述べずに、アジャイルの有意な点を述べますので、オブジェクト指向が身にしみていない人間から見ると、ベーム先生の言う純粋主義者に見えたり、宗教的にさえ感じてしまいます。オブジェクト指向の設計やプログラミングを思い浮かべながら、理解しようとすることがアジャイルの理解につながるのではないでしょうか?
(このブログでは、「リーンソフトウェア開発」の紹介でオブジェクト指向との関連付けを行う予定です)

純粋主義者の解釈

今日はベーム先生の「アジャイルと規律」のお話をします。
この本はサブタイトルに「ソフトウェア開発を成功させる2つの鍵のバランス」とあるように計画駆動型開発(とりあえず従来型のウォータフォールをイメージしてください)とアジャイル開発に対し、両者のホームグラウンドと長所短所を説明し、どのように俊敏性と規律のバランスをとるかを説明しています。
この前半部分に「純粋主義者の解釈」として以下のようなことが書かれています。

  • XPの一部を少しずつ採用して始めようと考えないでください.XPの部品は精巧なスイス時計のように調和しているからです
  • アジャイル手法の利点は,既存のものから選択して適用することも,自分で新しく創造して適用することも可能なことにあります。
  • SW-CMMレベル3に100パーセント準拠していなければ入札できません
  • CMMIをひととおり解釈していれば,自分が一番良いと考える順序で自分のプロセスを改善することができます

こんな議論を聞いたことはありませんか?
たしかに手法の普及には宗教的な盲信に聞こえる断言も有効ではあります。しかし、私のように魅力を感じるものの、どうもうまくいきそうにないような気がする場合、多分、それはうまく行かないと思います。まあ、問題がないときは大丈夫なのでしょうけど、何か問題が生じたとき、あるいは、問題の兆候に気づいたとき、対応できなくなってしまいます。
このようなことを考えていた時に川端さんと小林さんからソフトウェアシンポジウムに論文を共著共著で出すお話があり、上記の観点を入れさせていただいた論文が「効果的なXPの導入を目的としたプラクティス間の相互作用の分析(PDF )」です。

空想的アジャイル

いわゆるウォーターフォールモデル型できちんと管理していると、大規模なソフトウェアを、安定して、秩序正しく開発することができます。仕事そのものは大変であっても、開発の技術的な難しさは早い段階でその多くが解決され、定められた計画にしたがって開発を進めれば、開発後の達成感を感じることができます。しかし、そこでの目標は管理目標の達成であり、知らず知らずのうちにQA(品質保証)や管理者の顔色を見ることが仕事になっています。なにか違う。ソフトウェア開発の目標はもっと違うはずだ。管理されるために作業をするのでなく、もっと効率よく開発できるはずだ。そういった疑問が始まりでした。

確かに仕様が比較的明確で、規模や信頼性のばらつきがある場合にウォーターフォールモデル型開発は非常に有効です。しかし、開発対象の自由度が増して開発が難しくなるにつれ、小規模なプロジェクトほど管理ができなくなってきました。いつしか最適な開発方法を探すようになっていました。

やがて、XPをはじめとするアジャイルソフトウェア開発が注目されるようになり、これならばと思うインスピレーションを感じました。しかし、いろいろな本や雑誌を読んで見ましたが、メタファ(比喩)が多く、アジャイル的な開発経験のない者にとっては、わかりやすい内容ではありませんでした。また、セミナー参加するもベーム著「アジャイルと規律」でいう原理主義的な話が多く、求めている最適な開発とは少し違うようでした。

このような混乱を整理してくれた本が、「アジャイルと規律」でした。

(アジャイルと規律、リーンソフトウェア開発、テスト駆動開発などを中心に話を展開していきます。次回はアジャイルと規律からお話しする予定です)

トップページ | 2005年10月 »