図解入門 よくわかる最新システム開発者のための仕様書の基本と仕組み の商品レビュー
古いタイプの開発手法に則っている様である。 現実の現場では千差万別で普遍的なものは机上論にならざるを得ないのは避けられないが、サンプル的に入門者の体験という意味は大きいと思われる。 著者は開発経験が無いのかと思ったが、いちおう経験者の様だ。 教科書的な内容には良い面も悪い面...
古いタイプの開発手法に則っている様である。 現実の現場では千差万別で普遍的なものは机上論にならざるを得ないのは避けられないが、サンプル的に入門者の体験という意味は大きいと思われる。 著者は開発経験が無いのかと思ったが、いちおう経験者の様だ。 教科書的な内容には良い面も悪い面もある。
Posted by
今更ながら仕様書本を読んでいます。 これ読んだら、「システム設計vol.3」の予定です。 読了しました。 概要説明だけでしたが、経験と合わせるとなるほどこういうことなのかと思えました。 次はUMLかシステム設計ですね。
Posted by
システム開発者のための仕様書の基本と仕組み ●プロジェクトの途中には、マイルストーンを満足させるための成果物(要求定義書、設計書など)がある ●機能の確定や分析により外部設計を進めることで見積もりの精度を高め、リスクを減らせる ●要件定義では、最初にアクターを決める ●開発側がま...
システム開発者のための仕様書の基本と仕組み ●プロジェクトの途中には、マイルストーンを満足させるための成果物(要求定義書、設計書など)がある ●機能の確定や分析により外部設計を進めることで見積もりの精度を高め、リスクを減らせる ●要件定義では、最初にアクターを決める ●開発側がまとめた要件定義を示す文書を顧客が確認することにより、完成イメージをあわせることができる ●用語は用語集としてまとめ、要件定義書や基本設計書で使う用語を開発者と顧客であわせる ●基本設計、外部設計では後続文書の前提を記述することが必須だが、詳細を書きすぎると次のステップを進めにくくなる ●外部設計は操作の視点、内部設計は実装の視点で検討することで、要件の曖昧さを早期に発見できる ●ユーザ機能単位で分けたり中間リリースができるように設計し、アジャイル開発の手法を採用することで、開発途中の要望を反映できる ●要求定義では、概要や中心部分を把握して全体を網羅することで見積もりのブレを小さくする ●プロジェクト進行中に発生した問題点については、的確な妥協点を判断することが重要
Posted by
・要求定義書 ↓要件定義 ↓ ・業務分析 ↓ ・アクターの抽出 ↓ ・業務の流れ ↓ ・ユースケース記述 ↓ ・アクティビティ図 ↓ ・プロトタイプの作成 ・要件定義書 ・基本設計書
Posted by
- 1