成果物/概要設計書
Last-modified: 2014-06-26 (木) 11:04:25 (3586d)
アドオン機能について、詳細化可能な範囲で「大枠」を定義したドキュメント。
なお、定義については追加開発ドキュメント参照のこと。
作成目的 †
絵空事に過ぎない要求を現実のものとするため、プラットフォーム、コンセプト、前提、制約などを記録することにより、下記の目的を充足する。
- 安易な卓袱台返しをさせず、後続の設計の大前提を担保するため
- 複数人で分業する際に、効率化を図るため
- コミュニケーションの道具として、認識の共有を形に残すため
- 担当範囲および責任範囲を明確にするため
- 引き継ぎ資料および成果物としての位置付けを全うするため
- 顧客からの承認を受けるため
作成単位 †
基本的には追加開発テーマ単位が適当であるが、チェック/代入系やオブジェクトを共有するものについては、むしろ見づらくなってしまったり内容が薄まってしまうなどの弊害があるため、そういったケースは纏まりのよい単位でマージすべきと考える。
なお、このように追加開発テーマと設計書がn:1になることはあっても、逆は起こり得ない。
理由は、概要設計書が複数にわたるような追加開発テーマは、過度の詰め込みで機能のカプセル化できていないか、絵空事とも言える（少なくともパッケージに実装すべきでない範囲の）機能を実現しようとしているためである。
作成担当 †
各リードがレビュアを務めることを前提として、原則アプリチームの担当者以上が執筆すべきである。
補足として、マスタ項目定義に従うだけの移行ツールやシステムニーズだけの裏方系テーマについては、アプリのレビューがあることを前提に、開発チームによる代筆も構わないと考える。
作成タイミング †
アドオン判定会や変更管理Mtgをトリガとして、随時作成する。
更新ルール †
仕様変更依頼や不具合発生については随時更新とすべきだが、作業工数が溢れないプロジェクトは稀であり、保守引継や納品前のタイミングでの一括更新が慣例となってしまっている実情がある。
但し、作成目的のうち、
- 複数人で分業する際に、効率化を図るため
- コミュニケーションの道具として、認識の共有を形に残すため
- その他諸々について、顧客からの承認を受けるため
これらについては、随時更新しない = 目的が達成できないことになり、デメリットとリスクが多大であるため、当然推奨はしない。
【スポンサードリンク】
コメントはありません。 Comments/成果物/概要設計書?
