第6回北欧勉強会

初唱和。ちくわ氏がいると場がやわらかいのはちくわ氏のすごさだと思う。

以下検索用

北欧勉強会第6回
  一言
    2007-11-27
    2.1.3まで目標
    ペースが速くなりそう
    唱和したよ
  2. 責務駆動設計
    Drawing on the Airtist Within
      絵を描くのは特別な才能ではない
      オブ脳も同様
      内なる画家の目
      センスじゃないよ。教えられることだよ
      ものを認識して書くんじゃなくて、距離とかそのまま見る
      ただのコップじゃなくて位置関係を見ろ
    責務駆動
      対処すべき責任
        アクション
        アクティビティ
      どういう風にオブジェクトを認識していくのか
  2.1 見て、記述して、設計するためのプロセス
    設計プロセス
      流動的
        観点の追加
      直線的なプロセスでは失敗する
        設計を100％完璧には無理だよね
        本は直線的にしか印刷できないけど、そんなこともないよ
          P50 左
      小休止
        イテレーション
        バッファ?
    責務駆動設計
      形式にこだわらない
      アプリケーションの責務をオブジェクトに
    オブジェクト指向以外の観点
    責務駆動開発って何?
      責務駆動設計らしさ
      CRCが出てくるのが責務駆動
  2.1.1 製作を開始する:プロジェクトの定義と計画
    私たちの行動計画
    ゴール
      ソフトウェアが行うべきこと
      ユーザーをサポートする方法
    そうですねー。
  2.1.2 舞台を準備する:初期の記述
    設計の初期
      オブ脳不要
      システムの責任(責務)
    フェーズと作業と作業結果
      作業結果がいい感じ
    フェーズ
      区切ると直線的に考えたくなるなぁ
      今どの位置にいるの？
      作業分野じゃないの？
      RUPだと期間にならない?
      ステート
      局面
    もちろんすべての要求は見つけられないだろうけどね
    ちょっとずつ演劇になってきたなぁ
  2.1.3 製作を準備する:設計
    探求的設計
      適切な設計
        ほとんどの場合最初からできない
        コード書いたり、やりたいように
        どうやって確認するの？利害関係者に
          動くもの?
          ユースケース?
    設計の洗練
  2.1.4 複数の観点から「見る」
    利害関係者の関心と要求えお正しく解釈すること
    設計の成果を広く一般に理解できる言葉で表現すること
    どうやって利害関係者の要望の差異を埋めるの?
  2.2台本を書く:分析の記述
    仕様の間違い
      最も高くつく
  2.2.1使用法の記述
    ユースケース
      会話
      ユーザーの視点を持ち続ける
    シナリオ
    会話