第13章 ユースケースモデル：操作契約を伴う詳細の追加（P181） システム操作のための契約は、システムの振る舞いの定義に役立つ。契約とは、システム操作が実行された後に発生する、問題領域オブジェクトに対する状態の変化の点から、詳細なシステムの振る…

メモ帳を持ち歩くようになってから、時々読み返すと可笑しくて仕方ない。あたしは1日どういう思考で歩いたり考えたりしてるんだろ。今日のヒットはコレ。井伏鱒二の名訳。メモには「勧酒」「井伏」と書いてあった（笑。なんだそれっ！ 「勧酒」 于武陵勧君金…

「二度測って、一度で切る」木材加工の分野で用いられる格言：十分に準備するとその後は問題が発生しない。設計図あるいは知的創造で、本当に欲しい姿が描けているか確認しておかなくてはならない。だそうだ。どっから見つけてメモったのか不明。なんでメモ…

「思う、動く、叶う」 この間の、「報い、認め、讃える」とはちょっと違うけど、メモ。

ほぼ日刊イトイ新聞のメルマガより。ここ最近ずっと「職業病」がテーマで、遺伝子関連の研究をしているから、ハエが飛んでると種類を確認しちゃうとか、車掌をしてるから客として乗っているのに、うっかり「御用のお客さまはいらっしゃいませんか？」ってや…

なんか、新しいプラクティスとしていれられないかと思ってメモ。（mixiにも書いちゃったけど）「ディズニー７つの法則」の中に「報い、認め、讃える」というものがあるそうです。マネージャーは「ゲストサービス・熱狂カード」というものを常に持ち歩き、感…

第12章 問題領域モデル：属性の追加(P171) ●問題領域モデルには、要件が明示、または暗示している情報を記録するための属性を追加する ●問題領域モデルの属性として好ましいのは、【単純な属性(simple attribute)】【データ型(data type) ●概念クラス間の関…

俺がいままで遭遇した、テストコードが書けなくて困っている人達は ・初めてだからテストコードの書き方が分からない ・やりたいテストがあるがどう書いていいのか分からない ・何をテストするべきなのかが分からない ・実はメソッドの仕様が分かっていない …

第10章 問題領域モデル：概念の視覚化 続き(P145) オブジェクトの概念が必要（=概念クラス） 仕様または説明のためのオブジェクト「Xspecification」 「クラス」（=クラシファイア）の定義 概念的な観点と仕様的・実践的観点を区別することが大切 10.9 表現…

長いプロジェクトをやっていると随分人の出入りが多い。 気持ちよく迎えてあげること 既に出来上がりつつある文化にどうやって馴染んでもらうか 短い時間で共通の語彙を共有してもらうか 既存のメンバー全員が迎え入れる気持ちになってくれるか 人によって、…

今回のネタは4つ テストになってない（空メソッドでテストした気になる） 自動化していない（電卓で確認する） 回帰してない（Configを手で修正） 楽していない（単純なアクセサのテストをしちゃう） mixiにもちょっと書いたけど、笑いごとぢゃないんだって…

残念ながら練習してたから松本さんのお話は15分ほどしか聞けませんでした。でも「人」のお話をされてたようなので、ちゃんと聞ければよかったなー。 距離を縮めること ×否定・優劣 ×トレードオフ ○ギブ＆テイク 自分の中にもAgileを取り入れること 恩送り プ…

第10章 問題領域モデル：概念の視覚化 続き(P136) ●なに？ 問題領域の概念の語彙を視覚化すること ●目標 概念クラスを抽出し、問題領域モデルを作成すること ●指針 多数の細かい概念クラスを過剰に記入することと、控えめな記述とを比べたら前者の方がよい …

本日オヤスミー。だるいー。

「理論上は,理論と実際に差異はない。しかし実際には確かに差異はある。---- Jan L. A. van de Snepscheut」 おっ。これなら実体験で知ってるぞ（笑 第9章 ユースケースモデル：システムシーケンス図の作成(P121) 「システム」シーケンス図は、ユースケース…

http://d.hatena.ne.jp/kuranuki/20041017#p1 http://d.hatena.ne.jp/amapyon/20041022みなさんの意見がとても参考になる。多分コレ！というのは決めずに、色んな条件で臨機応変にやりたいな。慣れとかあるからいい感じのとかあれば、そのメンツでは固定にし…

「強く強張ったものは折れる。しなやかなものは生き残る。---- Tao Te Ching」 私もしなやかでありたい。Tao Te Ching を調べたら、「老子の道徳真経」のことだった。 第8章 方向付けフェーズから推敲フェーズへ(P111) 推敲フェーズでは、「中核のアーキテク…

書かれた要件を絶対視しないこと。常にコードを書き、テストをし、フィードバックを受け、ユーザーとの協調を継続し、調整を重ねることが大切 成果物はオンラインが好ましい 方向付けフェーズではUMLはあまり使わない（必要なことは情報を集めること） 方向…

ようやく推敲フェーズに向かっての準備だ！なんか実際にやってるような気分になってきた（笑 っていうか、ユースケースを書き終わっての、この微妙な隙間を埋めてくれているのはとってもかゆいとこに手が届いてる感じで嬉しいかも！ 補助仕様書(P91) ユース…

推敲フェーズのステップに進むかどうかの意思決定。契約的にはどうなんだ？ 「Cockburnとslow burnは韻が同じですね」って書いてある(笑 表6.1(P80) スゴイ！こんな風にいかねーかなーーーー。ってそのために勉強してんのやった。 成果物一覧は後で作ってみ…

※P85 図6.5参照

フィードバックで得られるもの：ユーザーの評価,テスト,「自分たちが、何を知らないのかを知る」 方向付けフェーズの最初の方で書かれるユースケース1つあたりにかかる時間は2分！(casual） 推敲フェーズの完了までには、ユースケースの80〜90%が一段落。調…

ユースケースは、割りとどうでもいい細かい機能のリストに置き換えられる！ →機能仕様書と一緒に使うのはまずい(>_

ようやくユースケース図に来た！びっくり。図は大事ぢゃなかったんだ。扱いがとても低い（笑 ユースケース作業の中で大事なのは文章を書くこと！ 図を書く場合には、アクタと目標リストと関連させ、イメージを掴む

主要アクタ：SuDのサービスを使用することで達成されるユーザー目標を持つ。「主導するユーザー目標を見つける」 補助アクタ：SuDにサービスを提供する。「外部のI/Fとプロトコルを明確にする」 舞台裏アクタ：上記２つではないもの。（例）政府税務機関 ※Su…

(例） 【本質的スタイル】 管理者が自分の身元を明らかにする。 システムが管理者のIDを認証する ・・・ 【具体的スタイル】（早期の要求分析にはそぐわない） 管理者がダイアログにIDとPassを入力する（図XX参照） システムが管理者を認証する システムがユ…

「継続的で個人的なコミュニケーション」で常にユースケースをよいものにしていく。 目標（goal）と意図（intention）は同義語

システム境界の選定 ブレーンストーミングによる、目標とアクタの発見 ユースケースの定義 →EBP指針をパスしないときは目標のレベルをあげる →外部イベントを識別して、目標とアクタを発見する →ユーザー目標ごとに1つのEBPレベルユースケースを定義 →ユース…

ユースケースの個数と粒度は、 要件の[理解][保守][管理のしやすさ][時間]に影響する →下位機能の目標を記述する際には上記をふまえて検討が必要