2010-01-01から1年間の記事一覧

結果を定めて手段を自由にする

誤解を恐れずに書くと、計画駆動に代表される予見指向が強いマネージメントではあらかじめ手段を定めて結果はなるようになるという傾向が強いと思います。 一方でアジャイルに代表される適応指向のマネージメントでは結果を定めて手段はなるようになるという…

アジャイル契約

ここのところCode Contractsを使ったDbC(Design by Contract)に凝っているのですが、ふとアジャイル契約というものを思いつきました。それでDbCにならってジャムズのアジャイル導入に関する契約を考えてみました。 不変条件: アジャイルマニフェスト 事前…

Code Contractsを使用した仕様記述の例(鶴亀算)

引き続きCode Contractsを使用した仕様記述と検証についてです。 試しに鶴亀算について仕様記述と検証を行ってみました。 はじめは簡単に考えていたのですが実際にやってみるとなかなか奥が深く思っていたほど簡単ではないことが分かりました。 そしてこの難…

Code Contractsを使用した仕様記述の例(ジャンケン判定)

Code Contractsを使用した仕様記述の参考としてジャンケン判定の仕様記述の例をあげておきます。 public enum Gesture { Rock, Scissors, Paper, } public enum Winner { Player1, Player2, Draw, } public class ScissorsPaperRock { public Winner Judge(G…

仕様記述言語としてのCode Contractsの利用

「Code Contracts(契約)の使いどころ - Jamzzの日々」に引き続きCode Contractsについて書きたいと思います。 ここまでの内容はソフトウェア本来の目的である仕様の実現という視点で品質と生産性を向上させるためにCode Contractsを契約による設計(DbC:De…

予見と適応のバランス

一般的によくあることで私自身もそうなのですが、アジャイルについて説明する際に従来の方法を「計画駆動型」とか「予見型」などと言って、それに対してアジャイル型を「適応型」として、それぞれを対比して違いを説明したりします。 これはアジャイルとはど…

Code Contracts(契約)の使いどころ

「Code ContractsとPex - Jamzzの日々」に引き続いてCode Contracts(契約)の使いどころについて書きたいと思います。 Code Contractsで興味深いと思う点は契約の継承、特にインターフェイスやabstractのクラス(abstractのメソッド)に対する契約を記述で…

Code ContractsとPex

マイクロソフトのDevLabsで公開されている.NETにおける設計とテストにおけるテクノロジーであるCode ContractsとPexを使ってみました。 結論から言うとかなり使えそうでひょっとしたら開発スタイルを変え可能性があると思いました。 かなり奥が深そうでまだ…

手続き記述から意味記述へ

プログラミング言語についてそれほど明るいわけではありませんがC#やScala、F#等のモダンなプログラミング言語の動向を見ていると、手続き型であるオブジェクト指向パラダイムと宣言型パラダイムの融合が進んできていて、徐々に慎重にであはりますが、さらに…

プロジェクトのコンカレント化戦略としてのアジャイル

プロジェクトマネージメントとしてアジャイルの意味を理解する一つの視点としてプロジェクトのコンカレント化という見方があると思います。 説明をわかりやすくするために官僚的に工程がシーケンシャルに実施されるウォーターフォール(ウォーターフォールが…

情報処理学会ソフトウェア工学研究会「ウィンターワークショップ 2010・イン・倉敷」参加報告(その2)

情報処理学会ソフトウェア工学研究会ウィンターワークショップ 2010・イン・倉敷の「アーキテクチャとパターン」セッションに参加しました。 大変更新が遅くなってしまったのですが前回の情報処理学会ソフトウェア工学研究会ウィンターワークショップ 2010・…

情報処理学会ソフトウェア工学研究会ウィンターワークショップ 2010・イン・倉敷参加報告(その1)

情報処理学会ソフトウェア工学研究会ウィンターワークショップ 2010・イン・倉敷の「アーキテクチャとパターン」セッションに参加しました。 今まであまり縁がなくて学会のイベントに参加するのは今回が初めてでしたが大いに得るものがあって非常に良い経験…

ソフトウェア設計資産のバランスシート

Martin Fowler's BlikiでWard Cunninghamが作ったメタファーである「技術的負債」は結構使えるというコラムがあります。 http://capsctrl.que.jp/kdmsnr/wiki/bliki/?TechnicalDebt その考えを借用してソフトウェア設計資産のバランスシートというものを考え…

感じる化

「見える化」の重要性が叫ばれて久しいですがさまざまな取り組みの状況を見ていると、「見える化」のための報告や情報管理でコストや手間が増大することにより合理性がなくなったり、挙句の果ては「見えるだけ化」だったりして効果的・継続的な実践は難しい…

新年の抱負2010

あけまして、おめでとうございます。 旧年中は皆様のご指導賜りましてありがとうございました。 2010年の新年を迎えるにあたって抱負を述べたいと思います。 昨年は弊社の事業環境も御多分に洩れず非常に厳しい物でした。 リーマンショック以降ある程度覚悟…