@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
各設計書がどういった場合に必要になるか?
1
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-11-18 14:13
設計書について検討しています。絶対必要なものとなくても良いもの。
設計書として顧客が望むものはどういったものなのでしょうか?個人的には受け入れ試験の試験項目作成に耐えれるものがあればいいと思っています。 それ以外の資料はベンダーで内部的にもっていればいいと思っています。 この考えって間違っていますでしょうか? その場合、どのような設計書が必要になってくるでしょうか? よろしくお願いします。 [ メッセージ編集済み 編集者: sand 編集日時 2007-11-18 14:14 ] | ||||||||
|
投稿日時: 2007-11-18 15:15
回答可能なものは答えますよ
設計書として顧客が望むものは、顧客に聞いてください。 | ||||||||
|
投稿日時: 2007-11-18 15:17
長期的に保守をsandさんおよびsandさんの会社が行うのであれば、たとえばクラス、シーケンス図や単体テストの設計書やデータなどは顧客には必要のないものです。請け負った会社が品質を保証し、将来的にもソフトウェアを改修してくれるという信頼があればよいからです。 ですが、顧客がソフトウェアの改修を自分で行いたい、もしくは他のベンダに修正を依頼したいなどの要求があればこうした保守に影響する内部的な資料は非常に重要な成果物となります。
顧客にはいわゆる要求仕様を記述した設計書(要件定義書、外部設計書)とテスト設計書(Integration Test、Perfomance Test、System Test)とそのデータ、試験結果を提出すれば十分だと思います。契約的に内部設計の資料を求められたらソースから自動生成した設計書やSQLなどを提出していれば問題ないと思います。 内部的にはそもそものコードの可読性が高いことと、JUnitなどの単体レベルの再帰テストのセットが準備できれば保守には十分なはずです。 [ メッセージ編集済み 編集者: Anthyhime 編集日時 2007-11-18 15:19 ] [ メッセージ編集済み 編集者: Anthyhime 編集日時 2007-11-18 15:22 ] | ||||||||
|
投稿日時: 2007-11-18 15:48
わからないなら作れって言った人に聞けばいいのさ。
それを作るメリットとデメリットをそれぞれ書き連ねていけば答えは出てくるはず。 極論ではベンダー内部で持っていれば良いでしょう。 ただし、あなたが作成したシステムをあなたが転職した場合は、社内の誰がメンテするのさ? あなたが転職しなかったとして、 転職した人の尻拭いをあなたがすることになったら うらむんじゃないですか? もう少し自力で悩みましょう。 設計書とカウントされるものにどんな種類があるのかは 書き出してみればわかるんじゃないかな? Web-applicationだとして、 ビジネスフロー ロバストネス図 システム用名寄せの単語帳 帳票一覧 ビジネスロジックの一覧 画面一覧 DBのER図 買い物籠やる場合はタイミング図 メッセージ一覧 バッチJOBの一覧 (OnLineから呼ばれるもの、定期バッチのみ、両方・・・等) 用件定義書 なんか、書き出せばもっと出てくる気がするが・・・? この辺で打ち止めにしてもいいか? 足りないとは思うが。 _________________ |
1