詳細設計

投稿者

投稿内容

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2008-10-14 10:02

objectです。
久し振りに書き込みます。

>七味唐辛子さん
>最近　詳細設計書を書く仕事が増えたけど、めんどくさいその一言につきる。
「面倒くさくなかったら良い」という主張なんでしょうか？
「面倒くさい」というのは、恐らく感情的なものですから、人夫々だと思いますよ？

>以前の仕事までは基本設計からいきなりコーディングだったのに
「基本設計からいきなりコーディング」を推奨しているのでしょうか？

>問題は記述の仕方のフォーマットが明示的にないのだが、記述の仕方がおかしいと返ってくる場合です。
>見本もないのにわかるわけがない。
「詳細設計書のフォーマットが明示的(見本を含む)」であれば、全く問題はないと仰ってるんでしょうか？

以上確認させて下さい。

綾: 会議室デビュー日: 2006/06/02; 投稿数: 19; お住まい・勤務地: 江戸

投稿日時: 2008-10-14 15:24

> 詳細設計を書く技術とプログラミングは別物であるというのがよくわかった。
純粋な技術としての「プログラミング」とは別物ですが、「プログラマ」という職業に要求される技術の一部ではあると思います。
なので、仕事として「プログラミング」をするならできて当然のこと、と言われるのは仕方がない気もします。

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2008-10-14 23:12

引用:
七味唐辛子さんの書き込み (2008-10-13 19:00) より: レビュー者から赤文字で修正がくるのだが、修正内容が、感覚的で非常にわかりずらい。

レビュー担当者に指摘判断がどこにあるか伺ってみてはどうでしょうか？

レビュー担当者の手を煩わせたくない気持ちを背景にお伺いを立てれば相手も悪い気はしないと思います。

もしかすると質問を受けたレビュー担当者も、人に説明できないような曖昧な判断基準で対応していたことに気づくかもしれません。

ただ、レビューを含む検証作業は担当者の能力にかなり依存します。そのため要求能力に満たない担当者は自分の存在意義を保ちたいため、どうでも良い事を指摘する行動に移る場合があります。

この時は、残念ですが、それっぽく対応するしかないですね。 ^^;

引用:
それと　どう書けばよいのかというのは学習する資料もない上流工程では　ＥＲＤ　ＵＭＬ　ＤＦＤとかいろいろあるけど　たまに詳細設計の記述言語はないのかと思うときがある。今回のＰＲＪは日本語でＯＫなんだけどそれが難しい。

なかなか難しい話ですね。

下手に工数がかかる詳細設計書ならば、まさしく詳細設計をすっ飛ばしてプログラミングした方が、実物ありきで検証も可能、コンパイルを通過するだけの品質は保障され、工数削減が期待できます。

七味唐辛子さん話を聞いて思ったのですが、
詳細設計書で何を事前確認し事前検証するのか明確に定めなければ、資料に求める事項が立場ごとで食い違い、傍から見て感覚的な指摘が横行するように様になるんでしょうかね。

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2008-10-15 00:40

引用:
objectさんの書き込み (2008-10-14 10:02) より: >以前の仕事までは基本設計からいきなりコーディングだったのに「基本設計からいきなりコーディング」を推奨しているのでしょうか？

特に進めてはいませんが。基本設計から製造まで同一人物の場合はいきなりコーディングの場合が多いです。
自分の参加したプロジェクトでは

>「詳細設計書のフォーマットが明示的(見本を含む)」であれば、全く問題はないと仰ってるんでしょうか？
可能であればほしいです。　

現状の記載レベルでは、それほど細かいレベルの記述は要求されていませんが、処理単位や処理の流れ
いいまわしなど、暗黙的なルールがあるようでそれをつかむためにほしいということです。もちろんルールとはいっては
その会社のローカルルールなのですが、

もちろんまったくサンプルがないわけではありません。
ちなみにスレを立ててから事情が変わりまして　私は終了宣言をだされ、選手交代となりました。
しばらくはこの作業は続けますが、

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2008-10-15 01:04

引用:

やじゅさんの書き込み (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

形式仕様記述言語というのが、あるというのは知ってます。ただもう少し日本語より？のあると使いまわしが
きくかなと　どちらかというと　自分で形式仕様を設定できてそれにしたがって文章がフォーマットされる
ツール　具体的には、統合開発環境に仕様書作成支援機能をつけてくれるうれしいなと常日頃思っています。

七味唐辛子: ぬし; 会議室デビュー日: 2001/12/25; 投稿数: 660

投稿日時: 2008-10-15 01:14

[quote]
はにまるさんの書き込み (2008-10-14 23:12) より:
レビュー担当者に指摘判断がどこにあるか伺ってみてはどうでしょうか？

レビュー担当者の手を煩わせたくない気持ちを背景にお伺いを立てれば相手も悪い気はしないと思います。

もしかすると質問を受けたレビュー担当者も、人に説明できないような曖昧な判断基準で対応していたことに気づくかもしれません。
[quote]

その通りですね。おそらく　その会社の伝統的な仕様記述デザインパターンがあって　レビュー担当者は　無意識的に判断しているんだと　

思います。　

object: ぬし; 会議室デビュー日: 2002/03/20; 投稿数: 338; お住まい・勤務地: 香川県高松市

投稿日時: 2008-10-15 11:42

objectです。

>七味唐辛子さん
スレの主旨が何処にあるのかを知る為、確認させて頂きました。
誠実にお応えして頂き、有難う御座いました。

実は、私も七味唐辛子さんと同じものを、とても強く感じています。

>特に進めてはいませんが。基本設計から製造まで同一人物の場合はいきなりコーディングの場合が多いです。
>自分の参加したプロジェクトでは
仰ってるのは、「SEとPG」が分担しない場合という意味ですね。
「設計」と「製造」のフェーズを分けるというのは、矢張り重要な事であると思います。

少し表現が難しいのですが、
「設計」と「製造」の関係を考えてみると、
「製造結果の中には、設計内容が残っている筈」
だと私は思っています。

そういう意味では、特にソフトウエアの場合、
「設計成果は、製造プロセスの中に一作業結果として組み込む事は可能」
であると思います。
#但し、両者の関係をその様に出来る裏付けが確立されている必要があります。

しかし、現在のソフトウエア製造は
殆ど「コーディング(プログラミング)」だけで終了する
というプロセスになっています。

少し整理すると、
「現在の設計(文章等で表記)は、或る意味では無駄な作業になっている」
と思います。
そういう意味では、
「無駄は最小限、つまり必要なものだけにした方が良い」
のですが、
「詳細設計」⇒「必要十分なものにかなり近い」
と、私は思っています。

これは単なる想像なのですが、「詳細設計」は設計と製造で人をアサインする場合、
「基本設計だけでは作業量が不足だから製造の重要な所を持って来た」
#それが出来るかどうかには関係なく
というのが真相だったりするのではないでしょうか？

もし、そうだとすると、
「SEの為の仕事増やし」
が、
「SEとPGの差別に繋がり、無駄になり、混乱さえ生じさせている」
という事になるのでしょう。

>可能であればほしいです。
恐らく、「七味唐辛子さん」としては
「作成する事が前提なら、その為の具体的な何かが欲しい」
という事なんですよね？

これも、とても良く分かります。

現状だと、
「詳細設計が必要」としている事業所では、作成するしかないですからね。

>ちなみにスレを立ててから事情が変わりまして　私は終了宣言をだされ、選手交代となりました。
>しばらくはこの作業は続けますが、
そうなんですか…。
今の情報産業の限界を感じますね。

今の金融危機の原因は、市場主義経済(或る意味で物質中心経済)にあると思いますが、
「プログラマーにも、かなり前から関連する被害(精神的なものを含む)が出ている」
という事かもしれません。
#これは、余談でした。

#編集：「今の金融危機が->今の金融危機の原因は」に変更。

[ メッセージ編集済み編集者: object 編集日時 2008-10-15 14:19 ]

«前のページへ 1|2

詳細設計

スキルアップ／キャリアアップ（JOB@IT）