HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方
HowToWriteAnEffectiveDesignDocument - 設計文書のうまい書き方 目次 この文書について 設計文書のうまい書き方 なぜ設計文書を書くのか 良い設計とは何か 同僚の開発者に向けて書く 第 1 節に書くこと: プロジェクト/サブシステムの目的を示す 第 2 節に書くこと: 設計に使う高レベルなエンティティを定義する 第 3 節に書くこと: 個々のエンティティに関する低レベルの設計を書く 使い方 設定 モデル 相互作用 第 4 節に書くこと: 利点, 前提, リスク/懸念事項 マネージャ向けに書くこと 最後に 設計文書のうまい書き方 この文書について "How to Write an Effective Design Document" の日本語訳です. http://blog.slickedit.com/?p=43 推敲歓迎: 誤訳, タイポ, 訳語の不統一,
怠訳 - TDDはもう古い!これからはADDだ! : 404 Blog Not Found
2007年06月21日04:30 カテゴリ翻訳/紹介Art 怠訳 - TDDはもう古い!これからはADDだ! こいつは厄さずにいられない。 scottberkun.com ? Blog Archive - Asshole driven development くそったれ駆動開発 - Asshole Driven development (ADD) チーム一のくそったれが、重要事項を全て決断する開発手法。理も知も技も、くそったれ殿が部屋にお出ましになるやいなやゴミ箱行き。くそったれ殿の詈と痴と偽が職場を支配する。いや、ちっとは知も技も残っているのも知れないが、ク氏の手にかかれば千の風になって飛んで行く。 認知的不協和開発 - Cognitive Dissonance development (CDD) どんな現場においても、ソフトウェアのあるべき姿に関して相反する理想が拮抗しているが、個々の
上流工程の問題解決 仕様変更編【前編】
システムが以前よりも複雑化している現在，多くの開発者やユーザーは，「仕様変更がある程度起こるのは仕方がないこと」と前向きに受け止めてはいる。だが一方で，仕様変更によるコスト超過などが原因で，プロジェクトが失敗に陥ることが非常に多い。仕様変更によるトラブルを極力防ぐにはどうすればよいのか。現場担当者の知恵から解決法を探ってみた。 「設計書の50％に手を加えなければならないほど仕様変更が続出し，収拾がつかなくなってしまった」。NTTデータ東北の太田雅典氏（法人システム事業部 第一開発担当課長）は，数年前に手がけたある出版社の広告管理システムで，開発中に起こった仕様変更のトラブルを振り返る。このプロジェクトでは，設計が一通り終わり，実装（プログラミング）フェーズに入ってから，データベース（DB）の構造や，帳票出力用の計算式，他システムとの接続インタフェースなど，システムの根幹をなす仕様の変更を次
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
