_ Agile2011の傾向と対策 Agile2011に行く人向けにAgile2011のセッションのおすすめをまとめてみました。 Agile2011では5日間のあいだに200以上のセッションが行われます。私はそのすべてのセッション概要に目を通して、特に興味をもったセッションをピックアップしてみました。参考になれば幸いです。 ちなみに、私はAgile2011には行きません。これを読んでAgile2011に参加した人は、ぜひ帰国後に報告会をやっていただけると嬉しいです。場所は提供します :) Monday AM The Origins of Agile: Robert Martin Uncle Bob がアジャイル開発に至る壮大な歴史を語ってくれる。Agile2011 のオープニングにふさわしいセッション。 An Introduction to Non-Violent Communicatio
要件定義や基本設計において、ドメインモデリング(概念モデリング)、ユースケースモデリングを行いますが、そのために必要なモデリングの手法について参考になる本を紹介します。 洋書(の翻訳)はあまり好きではないのですが、ダグ・ローゼンバーグとスコット・W・アンブラーの本は好きですね。 ユースケースを書こうとすると、どのように書くのがよいのか非常に迷います。テンプレートや本を元に書くことはできても「本当にこれがシステム開発の設計として役に立つものになっているのだろうか?」という疑問が湧いてくるのは私だけでしょうか?その疑問に応える一つの解がユースケース駆動開発実践ガイド (OOP Foundations)です。 なるべく要素技術を含めずにシステムの要件をユースケースによって記述した場合、実装する視点で見れば、非常に曖昧な情報となります。この要件と実装の間に横たわる大きなギャップをどのようにして埋め
データモデルの構造が大体固まってきたら,細かい所を確認していかなければなりません。今回は,データモデルの細かいところをレビューで確認する際に有用な,ちょっとした工夫をご紹介しましょう。 発注者はレビューポイントを見失う データモデルのレビューでは,発注者がレビュー個所を見失いがちです。文章で書かれた設計書であれば,文章の流れに沿って説明し,時には章のタイトルや構成の切れ目で確認しながら,レビューを進めることができます。しかし,ER図という「一枚の絵」を説明する場合は,そういうわけにいきません。ただでさえ見慣れない表記法のER図の解釈に気を取られるうえ,どこからでも見ることができるER図の上で,発注者の視点はすぐ迷子になってしまいます。 このため,ER図のレビューの際には,発注者に対して「どこの議論をしたいのか」「どこが確認のポイントになるのか」を明らかにしたうえで,説明することが重要です。
今回から「受発注システム」を想定して,データモデルを発注者と合意するためのコツを詳細に説明していきましょう。 前回述べたように,データモデルは発注者にとって難しいものです。このため,詳細なデータモデリングに進んだ時点からいきなりレビューを始めるのではなく,発注者と開発者の双方の理解できる,データモデルの概要がわかる全体図を使ってレビューを始めます。 最初に発注者と開発者がデータモデルの全体像を共有していれば,これがデータモデルの予備知識となり,後に続くレビューをスムーズに実施できるようになります。今回は,データモデルのレビューに欠かせない,2つの全体図を紹介しましょう。 概要図でエンティティの候補を確認する まずデータモデリングの第一段階として,対象となるシステムにはどのような業務があり,それにはどのようなデータが結びついていて,お互いにどのような関連を持っているのかというデータモデルの全
2007/12/21追記 「内部設計 見本」「外部設計 見本」などで検索に来た皆さん、残念でした。ここには見本はありません。でも、この書き込みに来たのも何かの縁。一度、外部設計とか内部設計とか、本当に必要なのか考えなおしてみませんか? 詳しくは、下記本文で。 以下、本文 BMUF (Big Modeling Up Front)=上流設計のインチキを斬るでは、敢えて「Modeling≒設計」みたいな感じで訳しちゃった。その後いろいろ考えたけど、BMUFは「先行設計」と訳すべきだったかもしれない。 辞書でmodel(動詞)を引くと、「見本を作る」というのがひっかかる。そして、おそらくソフトウェアにおけるModelingとは「見本を作る」ことであろう。 モデリング BMUF (Big Modeling Up Front)=上流設計のインチキを斬る元記事で紹介されていたSketches of Fr
本日もAgile布教活動。 若手中心でAgileに挑戦しているチームを訪問。だが、状況を聞いているうちに「これはよろしくない」と思った。問題なのは画面の紙芝居で発注者と要件を調整していることだ。そして、きれいな画面設計書には「このボタンを押すとどんな処理が走る」「このリンクをクリックするとどこに飛ぶ」みたいな懇切丁寧な説明まで書かれている。 画面ベース開発の欠点 実際にプログラムを書かずに、利用者が使うことになるはずの画面見本を元に要件を固めていく。この方法が間違いとは言わないが、以下のような欠点を抱えている。 要件定義工程が膨らむ 画面に部品を描けば、必ずその部品が引き起こすイベントについて記述する必要がでてくる 結果、関連画面も芋づる式に記述していくことになり、検討する対象が増えてしまう 要件が硬直化してくる 検討対象が増えてくれば、検証にも時間がかかるようになる 運良く、漏れや間違い
最近、こんなFirefox拡張機能が公開された。→Firesheep パケットを拾って、そこからCookieを抜き出してFacebookなどの他人セッションを乗っ取れますよ、という触れ込み。同サイトにある画面コピーを引用。 もちろん、パケットを拾えない限り意味はないので 昔ながらのパケット垂れ流しHub 同じ筐体を共有したブラウジング(最近はあまりいない?) SwitchでわけられてもARP Poisoningでなんとかなる? 暗号化なしのWiFi接続 などの環境では、SSL保護されていないセッション識別用Cookieは盗み取れちゃうかもしれない。Firesheep作者は特にFacebookサイトにおけるセッション管理を問題視している。 ちなみに我が家のWPA2環境で 犠牲者(?)...Android G2 盗む側...MacBook Pro+Firefox+Firesheep という組み
Coopa!β takes static documents and brings them to life in real-time. You can add text, graphics, or video with the same ease as presentation software, and simply place contents that change in real-time (like Ustream videos or Twitter) into documents using drag and drop. View the documents you've created on a web browser, or put them in an iPad app and take them with you wherever you go! The best p
10/13: SF New Tech & btrax Present: SF Japan Night! With Coopa, Drrop, GazoPa, Lang-8, myGengo, Spysee and More!というのに参加してきた。こういう起業系の集まりというのはなんか苦手なんよね。雰囲気は2000年ネットバブルを思い出させるものがある。ただし開催場所はパロアルトではなく、サンフランシスコ。事前にネットで予約しないと入れないとか、UStreamでの中継があるとか、10年一昔を感じさせる差もちらほら。 最初の2時間くらいはいわゆる人脈作りの場で、みんな飲み物片手にわいわいがやがや。今回は日本企業による発表が主役なので、日本人ならびに日本語を操る各国人が目立った。日本語がダメな人は当地の起業家かVCの人達か。 その後は「集団監視下における5分間エレベーターピッチ」みたいな感じで
Masanori Kusunoki / 楠 正憲 @masanork 今日のIT政策尖端研究会で何を話すか?わたしひとり外資系黒船の帽子なので割と難しい。ここはヒールになるか Masanori Kusunoki / 楠 正憲 @masanork やっぱ本業でもあるし標準化戦略に触れるべきかな。後進の育成が重要で、キャリアパスの観点からも雇用の流動性が重要なんだけど、現実には着々と高齢化が進んでいる。もう10年くらい経つとかなりヤバいことになる Masanori Kusunoki / 楠 正憲 @masanork ガラパゴス化の背景に何があるか、とかも突っ込んで議論したい。既存大企業の内向き志向とかだけでは精神論で駄目。おそらく部分最適な合理的戦略として結果的にそうなっているんだから、枠組みにメスを入れないことには掛け声倒れになる
最近いわゆる非RDBでちょいと苦労したので、この記事は楽しく読めた。一方で、この記事を勘違いして読み取って、やたらとロックかけまくるようなシステムを作り上げる人達が増えないことを願って、ちょいとメモ書きなどを。 DBの「トランザクション分離レベル」が必要な理由 (PostgreSQLで,ファントム・リードを防止すべきサンプル事例) 分離レベルがデフォルト(read comitted)のままだと,恐ろしい不具合が発生する。 この後簡単な例題があって「ね、ファントムリードって怖いでしょ」という話に進んでいるわけだ。でも考えてみよう。「ある瞬間に唐突に締めきって、その瞬間にお金を分配する」なんていう処理はあるのだろうか? 商売の世界なら「締め時間」があり、それ以前に受け付けたものなら処理の対象になる、というのが普通であろう。そして午後3時に締めて、そのコンマ数秒後に結果を出さなければならない、
本日公開され、あっという間に繋がらなくなったgoogle-io.com。何が悲しいって、申し込みページのURLが .cfm で終わっていた、ということ。これってCold Fusionかなんかで作った、ってことでしょ? Google App Engineかなんかでやってほしかったじゃないですか。 $ dig www.google-io.com ; <<>> DiG 9.6.0-APPLE-P2 <<>> www.google-io.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7467 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SE
Beyond Agile Scrum Information Base — Agile Skills Chet Hendrickson and I have offered to help the Scrum Alliance build a broad and growing base of information relating to Scrum / Agile, and to the many skills and practices that can help teams be successful. Our offer has… The Annals of Kate Oneal Kate Oneal: What is Scrum? Kate gives Dan Devlin, the company owner, an overview of Scrum. Classics W
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く