@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

詳細設計

投稿者投稿内容
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2008-10-12 09:21
最近 詳細設計書を書く仕事が増えたけど、めんどくさいその一言につきる。
以前の仕事までは基本設計からいきなりコーディングだったのに

問題は記述の仕方のフォーマットが明示的にないのだが、記述の仕方がおかしいと返ってくる場合です。
見本もないのにわかるわけがない。 
未記人
会議室デビュー日: 2008/09/22
投稿数: 7
投稿日時: 2008-10-12 11:04
引用:

七味唐辛子さんの書き込み (2008-10-12 09:21) より:
最近 詳細設計書を書く仕事が増えたけど、めんどくさいその一言につきる。
以前の仕事までは基本設計からいきなりコーディングだったのに

問題は記述の仕方のフォーマットが明示的にないのだが、記述の仕方がおかしいと返ってくる場合です。
見本もないのにわかるわけがない。 



で?
結局何が言いたいの?
「記述の仕方がおかしい」と言われるなら何がどうおかしいのか聞くだけじゃないの?

只の愚痴ならチラシの裏にでも書いてなよ。
よねKEN
ぬし
会議室デビュー日: 2003/08/23
投稿数: 472
投稿日時: 2008-10-12 12:10
引用:

七味唐辛子さんの書き込み (2008-10-12 09:21) より:
最近 詳細設計書を書く仕事が増えたけど、めんどくさいその一言につきる。
以前の仕事までは基本設計からいきなりコーディングだったのに



基本設計書や詳細設計書の取り扱う範囲が会社によって、プロジェクトによって
違うことはままありますね。しかし、どちらも必要なものだと思います。
それ以前の仕事は基本設計という名前で詳細設計も含まれていただけではないでしょうか。

#個人的には基本設計で検討して書くべきことと詳細設計で検討して書くべきことが
#ごっちゃになっている設計書は勘弁してほしいですね。
#目的と手段がいろいろな粒度でごっちゃになってるってことで、
#非常に読みにくいし、設計書のメンテもしづらいと思いますから。

そうでなく、多くの人から客観的に見ても「基本設計からいきなりコーディング」
なんだとしたら、詳細設計部分をその都度決めながらコーディングしているだけで、
行き当たりばったりで開発しているということだと思います。
少数の優秀な開発者だけやっている小規模開発ならそれでもうまくまわりますが、
大規模開発だときついですね。小規模開発でも運用・保守フェーズの担当者が苦労しそう。

引用:

問題は記述の仕方のフォーマットが明示的にないのだが、記述の仕方がおかしいと返ってくる場合です。
見本もないのにわかるわけがない。 



見本がなくて困るなら、見本になるものを求めればよいのではないでしょうか。
求めても見本がないよという返答なら、基本設計書には何を求めて、
詳細設計書には何を求めているのかの指標を確認しながら、
実際に設計書のプロトを作って見せて、それに対してフィードバックをもらいながら、
記述レベルやフォーマットを確定していけばよいのではないでしょうか。
(重要なのはフォーマットではなく、何をどのレベルまで記述するかです。
フォーマットは記述する内容を書きやすい/読みやすいものであれば何でもよい)

「記述の仕方がおかしい」と返ってくるのですから、
詳細設計書に期待するもののイメージはあるでしょうから。
はにまる
ぬし
会議室デビュー日: 2003/12/19
投稿数: 969
お住まい・勤務地: 誤字脱字の国
投稿日時: 2008-10-13 10:18
引用:

七味唐辛子さんの書き込み (2008-10-12 09:21) より:
最近 詳細設計書を書く仕事が増えたけど、めんどくさいその一言につきる。
以前の仕事までは基本設計からいきなりコーディングだったのに


運用要件への配慮は詳細設計工程でなければ困難です。そのため詳細設計を飛ばす行為は、作る事を目的としたシステム開発現場では良くある話です。

あとシステム開発の会計処理が工事進行基準に一本化されるため、客観的な進捗説明が求められ作成資料量は増大するでしょうね。

引用:

問題は記述の仕方のフォーマットが明示的にないのだが、記述の仕方がおかしいと返ってくる場合です。見本もないのにわかるわけがない。 


開発現場では良くある不満ですが管理視点ならば失策の代表例です。

システム開発で例えれば、依頼者の要求事項を要件定義で確認せず、総合テストで”要求するシステムと違う”と依頼者より却下される話と類似しているように聞こえます。

私であれば相手の要求を聞き出しサンプル資料提示して、最低限満たすべき記述事項の合意を得るか、自論を展開して相手に自作の提示資料を基準として合意してもらいます。

ただビジネスでは生半可な知識で自論を押し付けると非常に厳しい状況に立たされる事もありますので注意が必要です。
やじゅ
常連さん
会議室デビュー日: 2008/07/15
投稿数: 28
お住まい・勤務地: 静岡市
投稿日時: 2008-10-13 16:20
設計書の書き方なら、発注者ビューガイドラインというのが
あります。参考までに

発注者ビューガイドラインの公開
http://sec.ipa.go.jp/reports/20080710.html

詳細設計書は製造者向けとなるので、下記サイトも参考までに
http://www.thinkit.co.jp/cert/project/4/4/2.htm

[ メッセージ編集済み 編集者: やじゅ 編集日時 2008-10-13 16:56 ]
七味唐辛子
ぬし
会議室デビュー日: 2001/12/25
投稿数: 660
投稿日時: 2008-10-13 19:00
いろいろありがとう。 
おかしいから直せというのは、わかるのだが、要求を満たしていないとか、ロジックがおかしい
といったレベルの話ではなく処理名称がおかしいとか処理単位の記述レベルがおかしいということで
レビュー者から赤文字で修正がくるのだが、修正内容が、感覚的で非常にわかりずらい
詳細設計を書く技術とプログラミングは別物であるというのがよくわかった。
それと どう書けばよいのかというのは学習する資料もない上流工程では ERD UML DFDとかいろいろ
あるけど たまに詳細設計の記述言語はないのかと思うときがある。今回のPRJは日本語でOKなんだけど
それが難しい。 
 

やじゅ
常連さん
会議室デビュー日: 2008/07/15
投稿数: 28
お住まい・勤務地: 静岡市
投稿日時: 2008-10-13 21:28
引用:

たまに詳細設計の記述言語はないのかと思うときがある。



一応、形式仕様記述言語ってのがあります。認知度は低いですけどね。
http://techon.nikkeibp.co.jp/article/TOPCOL/20070216/127811/
http://www.csk.com/SYStems/seminar/sm_tokyo/docs/060308_2.pdf
未記入
大ベテラン
会議室デビュー日: 2005/03/12
投稿数: 148
投稿日時: 2008-10-14 07:43
確かによくわからんよね。
ほかの発言のように粒度が違うとか。
どこからが詳細になるのかとか。
人によって違ったり。

スキルアップ/キャリアアップ(JOB@IT)