特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日本語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの本29頁を読むと「特徴」がい
画面設計とか外部設計とか、もうやめようよ - masayang's diary
昨日は特徴(Feature)、粗筋(Story)、脚本(Scenario)でちょいと言及した「Feature, Story, Scenarioがごっちゃになりかけている」プロジェクトの人達とお話しする機会があった。 よくよく見ると、FeatureとFunctionとがごっちゃになっていた。 つまり、要件分析の段階で実装のことを考えていたのである。 なぜ、そうなったのだろう？ 画面から要件分析をすると、こうなる どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。 紙芝居感覚で交渉できるからわかりやすい。 だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。 実装をフィーチャとして捉える可能性。 例え
アジャイル手法が設計技法にも浸透しつつある - プログラマの思索
平鍋さんの記事「データモデリングなきアジャイル開発は危ういか？：An Agile Way：ITmedia オルタナティブ・ブログ」がとても分かりやすかったのでメモ。 【元ネタ】 データモデリングなきアジャイル開発は危ういか？：An Agile Way：ITmedia オルタナティブ・ブログ Twitter / akipii: とても良い記事。昔ながらの設計技法が古くなっている事実を認識すべき RT @hiranabe: 渡辺さん稲見さんへ返信ブログ書きました。「データモデリングなきアジャイル開発は危ういか？」 http://bit.ly/UsO1aA Twitter / yusuke_arclamp: アーキテクチャ設計の生成パターンは良いのがないんだよね。結局、プロトや繰り返し開発のようにプロジェクトマネジメントでリスク回避的に選択するのがベストプラクティスになってて。 Twitter
開発者向けのソフトウェア設計書は必要か？ - 勘と経験と読経
時々組織の内外で盛り上がるネタの一つに「設計書は必要なのか」談義がある。今回も後輩の一人から設計書不要論がぶつけられてきたので、現時点での個人的見解をまとめておくもの。個人的には、ソフトウェアの設計書は必須でもないし、開発戦略を練る段階で作成するかどうかを決めればいいと思っている。 議論の前提：仕様書と設計書 議論を簡単にするために、まず「仕様書」と「設計書」という言葉を再定義しておきたい。今回の整理は以下としている。 仕様書 … 開発者とユーザー(仕様決定者)が、ソフトウェアの振る舞いや動きに関してコミュニケーションするために必要な文書類のこと。 設計書 … 開発者どうしがソフトウェアを作成するにあたっての、構造や仕様についてコミュニケーションするために必要な文書類のこと。 要は今回議論しようとしている「設計書」は、ユーザー(仕様決定者)とは無関係なものであるという前提である。また、ここ
だれも教えてくれなかった外部設計の「極意」---目次
外部設計書で最も大切なことは，「システム開発を依頼してきたお客様」（発注者）に読んでもらい，理解してもらうことです。外部設計書を，開発メンバーではなく，発注者に理解してもらうためには，「いかに発注者にとって分かりやすい外部設計書を作成できるか」と「レビューを通じていかに合意形成を図るか」が重要になります。本連載では，発注者が理解しやすい外部設計書の書き方とレビューの方法に関する具体的なノウハウを解説していきます。 第1回 ユーザーと意思疎通が図れない外部設計書は危ない 第2回 ［システム振舞い編］一覧表に一工夫入れることで漏れや重複をなくす 第3回 ［システム振舞い編］全体を俯瞰でき，システム化範囲が一目で分かる業務フローを作成する 第4回 ［システム振舞い編］発注者が理解しやすいシナリオの記述方法 第5回 ［画面編］見れば“わかる”「画面レイアウト」の作り方 第6回 ［画面編］画面遷移を
開発者が知っておくべき、6つのUIアーキテクチャ・パターン - ＠IT
.NET開発者中心 厳選ブログ記事 開発者が知っておくべき、6つのUIアーキテクチャ・パターン ―― 「matarillo.com」より ―― 猪股 健太郎 2011/12/15 「.NET開発者中心 厳選ブログ記事」シリーズでは、世界中にある膨大なブログ・コンテンツの中から、特にInsider.NET／.NET開発者中心の読者に有用だと考えられるブログ記事を編集部が発掘・厳選し、そのブログ記事を執筆したブロガーの許可の下、その全文を転載・翻訳しています。この活動により、.NET開発者のブログ文化の価値と質を高め、より一層の盛り上げに貢献することを目指しています。 Martin Fowler氏の『GUI Architectures』を訳して公開しようと思ったのだが、FAQページに「PofEAAの続編などは商業出版する予定なので翻訳はしないでほしい」と書いてある。なので翻訳の公開はやめて、「
UML入門 - IT専科
UML（Unified Modeling Language）とは、様々な開発現場で使用されている設計書の書式を統一する目的で規定された言語で、1997年にOMG ( Object Management Group ) により標準化されました。 但し、UMLによる標準化はあくまで表記方法であって、開発手法の方法論ではありません。 UML2.0では表記方法を以下のように分類しています。 構造に関する表記 振る舞いに関する表記 構造に関する表記 ・クラス図（Class Diagram） クラス構造を表現します。 ・オブジェクト図（Object Diagram） クラスをより具体化したオブジェクトで表現します。 ・パッケージ図（Package Diagram） クラスなどをグループ化し整理された関係を表現します。 ・コンポジット構造図（Composite Structure Diagram） クラ
クラス設計に関するメモ
経験的にこのようにした方がよいと思った点についての記録です。 仕事で大規模(2000クラス超)かつ製品寿命がながいパッケージソフトを作っていた関係で、 ちょっとした設計の間違いが、 あとあとで大変な苦労する羽目になったりすることを経験してきました。 このような規模が大きいアプリケーションを作ることはなかなかないかもしれませんが、 なにかの参考になれば、と思います。 継承する前に委譲を検討する Singleton パターンを使うときの注意 Template Method パターンを使うときの注意 クラス間の依存に関する注意 クラスの粒度 Singleton の問題を回避できるか？ 継承する前に委譲を検討する 継承はスーパークラスの仕様をよく理解しておかないと、 バグを作りこみやすいので十分注意する必要があります。 メソッドのオーバーライドをするときも、 public void foo(){
アジャイルモデルのエッセンス: アジャイルに作れる成果物
by Scott W. Ambler, Copyright 2003 効果的にアジャイルモデリングを行うには、さまざまな種類のモデリング手法を知っておく必要があります。残念ながら、これは口で言うほど簡単なことではありません。このページはまだ作成中ですが、さまざまなモデリング成果物の概要へリンクしています。各ページには、その成果物についの解説と、1、2の例、推奨文献へのリンクが含まれています。 モデリング成果物 ビジネスルール ビジネス/本質ユースケース 変更案 CRC(Class Responsibility Collaborator)モデル 制約事項 取り決めモデル データフロー図(DFD) 本質/ビジネスユースケース 本質ユーザインターフェースプロトタイプ ユーザ機能 自由形式の図 フローチャート 用語集 Logical Data Model (LDM) ネットワーク図 オブジェクトロ
プラグイン機能を持つアプリケーションを作成する
Adobe PhotoshopやBecky! Internet Mailなどのアプリケーションでは、「プラグイン」（または、「アドイン」、「エクステンション」等）と呼ばれるプログラムをインストールすることにより、機能を追加することができるようになっています。ここでは、このようなプラグイン機能を持ったアプリケーションの作り方を考えます。（プラグインが何だか分からないという方は、「アスキー デジタル用語辞典」や「IT用語辞典 e-Words」等をご覧ください。） 早速ですが、プラグイン機能の実現のために参考になりそうな記事を以下にいくつか紹介します。 Developer Fusion - Writing Plugin-Based ApplicationsDevSource - Building Plug-ins with C# .NETSA Developer .Net - PluginFX
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
)
WPF のグローバリゼーションおよびローカリゼーションの概要
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 更新 : 2007 年 11 月 製品を 1 言語だけで作成することは、潜在的な顧客ベースを、65 億の世界人口のごく一部に制限することを意味します。アプリケーション製品をグローバルな市場に届けようとする場合、最良かつ経済的な方法の 1 つは、費用対効果の高いローカリゼーションです。 ここでは、Windows Presentation Foundation (WPF) のグローバリゼーションとローカリゼーションについて説明します。グローバリゼーションとは、複数の地域で実行するアプリケーションの設計と開発です。たとえば、グローバリゼーションは、さまざまなカルチャのユーザーのために、ローカライズされたユーザー イ
米Yahoo!がシステムダウンしない5つの理由
昨年の10月14日、米Yahoo!のトップページがダウンしたと、米Huffington Postが記事「Yahoo DOWN: Yahoo.com Outage Reported」で伝えました。米Yahoo!にとってトップページがダウンすることはきわめてまれなことで、この件が発生するまでほぼ10年にわたりトップページのダウンは起きていなかったと言われています。 その米Yahoo!はシステムダウンを防ぐためにどのような取り組みをしているのか？ 米オライリーが主催したイベント「Velocity 2011」で、Yahoo!サービスエンジニアリング部門のVice President、Jake Loomisが行ったセッション「Why the Yahoo FrontPage Went Down and Why It Didn't Go Down For up to a Decade before Th
Dropasta - Beta
削除すると元には戻せません アカウントを削除する前に、以下の内容をご確認ください アカウントに関連付いている.astaファイルや図が全て削除されます。 アカウントを削除しても数日間は、関連付いている.astaファイルや図が表示され続ける可能性があります。 Googleや他の検索エンジンにインデックスされた.astaファイルや図を管理することはできません。
Object Oriented を考える オブジェクト指向→目的志向 | システム設計日記
ソフトウェアの設計・開発で、OO:Object Oriented は、根本的な考え方の変化(パラダイムシフト)だと思う。 ソフトウェア開発の世界では、"Object Oriented" は、誰もが聞いたことがある言葉だと思うが、意味や使い方が、人によって、状況によって、ばらばらな、かなり不可思議な言葉でもある。 OOP:オブジェクト指向プログラミング オブジェクト指向言語を使ったプログラミングの総称？ もし、Java , C#, PHP5 などをオブジェクト指向言語と呼べるなら、世の中には、オブジェクト指向プログラマがたくさんいるわけだ。 実感とはだいぶ違う。 分析や設計の考え方が オブジェクト指向じゃないのに、言語だけ、オブジェクト指向（風？）でもそれは、ＯＯＰとは言えないですよね。 OOAD:オブジェクト指向分析設計 UML でクラス図とか描くこと？ オブジェクト指向言語の話といっしょ
ソフトウェアのユニバーサルデザイン設計手法
ソフトウェアのユニバーサルデザイン設計手法 関根千佳 (株式会社ユーディット：情報のユニバーサルデザイン研究所) http://www.udit-jp.com/ Universal Design Practices for Software Chika Sekine (Universal Design Institute for Information technology) 1．はじめに 21世紀の日本において、人口の4分の1が65歳以上となると言われている。同時に今や1年でかつての6年分進むといわれる高度情報社会でもある。産業や行政のあらゆる情報提供が、今以上に情報通信を通じて行なわれることが明白に予測される将来において、自分が情報弱者になるかもしれないという予想も、現状のままでは、また明白である。 障害を持つ人や高齢者は、情報機器と支援技術を用いることで、これまで取得や発信が困難であ
設計の現場で使える便利な言葉「ゼルダの石」。 - 日々、とんは語る。
説明しにくい事柄に対して、ベストマッチする言葉があると便利ですが、今日はその中のひとつ「ゼルダの石」を紹介します。 「ゼルダの石」の使い方。 ゼルダの石は、以下のように使います。 これは「ゼルダの石」だから不要ですね。さて、どういう意味でしょうか？ 「ゼルダの石」とは、あっても無くても危害をなさないもの、また、そのような表現。 ゼルダの石とは、任天堂の宮本茂さんのインタビューで、僕が共感を得た内容から作られた故事成語です。 出典がウェブのどこかに転がっているはずですが、見つけられなかったので、僕の記憶と言葉で説明します。 あるとき、ゼルダのフィールドを作成していたスタッフが、何気なく石を配置しました。ゼルダの石は持ち挙げることができます。石の下からはアイテムが出てきたり、その石は投げてぶつけることが出来ます。 しかし、次の日、これを見つけた宮本さんが「誰がこんなところに石を置いたんや!」と
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版