タグ

関連タグで絞り込む (1)

タグの絞り込みを解除

設計書に関するnakaji999のブックマーク (6)

  • 古き悪しき詳細設計書 - SiroKuro Page

    詳しすぎる詳細設計書 - SiroKuro Page の続きです。前の記事ではブクマありがとうございました。 はてな界隈の拒否反応を見る限り、詳しすぎる詳細設計書に良い印象を持ってる人は少なそうです。もっとも、私は良い面も持っていると思っていまして、 プログラマの技術的知識や業務的知識の量に左右されることなく、一定の品質を保つことができる なんてメリットがあります。属人性の排除ですね。 あたりまえですね。実は設計者が書いたプログラムを詳細設計書と呼んでいるんですから。しかもテストどころか処理系にわせてすらいないプログラムです。悪く言えば机上の空論です。良く言えば……絵に描いた? プログラマの技能に左右されないかわりに設計書の品質に左右されるので、一定の品質が「悪い方に一定」だったりすることもあって、色々と下流工程の憤が溜まりそうです。既に溜まっていますね、ごめんなさい。 題:古き悪

    古き悪しき詳細設計書 - SiroKuro Page
    nakaji999
    nakaji999 2011/03/10
    ビンゴ!「SIer は、EXCEL 方眼紙の上にプログラムを記述します。そのプログラムは詳細設計書と名付けられ、テストされることなく出荷されます」
  • 書き手だけが知っている - rabbit2goのブログ

    セミナーや人の話を聞いて新しい知識を学んだ時には、その感想とかコメントを簡単にまとめて記録に残すようにしている(ブログに載せている情報もその一例だ)。また、会議や講演のように後から情報を読み直せないものは、話の内容を延々とメモした上で、それを振り返りつつ要点をまとめるようにしている。読書の感想文、出張報告書とか、開発プロジェクト報告書なども同じで、手間と時間はかかるけど必ず文章という形で保存している。 私見だけど、他人の話でもそれを自分でノートに取ることで記憶に刻み込まれ、より理解が深まるように思う。1時間にも及ぶ話を聞いて理解するのは簡単だけど、その内容を全部覚えるのは大変だ。その直後なら話の印象が残っているのでアレコレと感想を言えても、1週間経って同じ話を出来る人はそう多くないだろう。だからこそ、話の内容をメモにとって確実に記憶へ残す手続きが必要になるのだ。自分の手を動かしてノートを取

    書き手だけが知っている - rabbit2goのブログ
    nakaji999
    nakaji999 2010/04/19
    少しでもギャップを埋めるためにソースのコメントと同じ考えで、結果だけでなくなぜそうなったかを仕様書に盛り込めば少しはよくなるだろうか。
  • キレイなコードでも仕様書の代わりにはならない - 設計者の発言

    4GL(第四世代言語。既に死語)を使っていた頃に「ソースコードが仕様書だ」と言い張っていたことがある。テーブル操作コマンドと統合されているそのプログラミング言語を使えば、じっさい英語の文章のように明解にコーディングできた。しかしそんな強力な言語を前提にしても、今から考えれば「コードが仕様書だ」と主張したのは間違いだった。 理由は単純。仕様書として通用するほどキレイにコーディングが可能と謳われている言語を使ったとしても、コーディングがキレイになることが「保証」されているわけではないからだ。まあ当然のことで、文章の読みやすさが書き手によってまるで違うのと同様、コードの読みやすさはプログラマによってまるで違う(その日の気分や体調によっても違うかもしれない)。いかに標準化を徹底しようが、同じ動きをするのにいっぽうは読みやすくいっぽうはわけがわからないなんて事態は日常的に起こる。そして、システム開発

    キレイなコードでも仕様書の代わりにはならない - 設計者の発言
  • 詳細設計書に何を書くべきか? - Sacrificed & Exploited

    詳細設計書の書き方については黙っていられないので、ちょっと意見を言わせてもらう。 私も「詳しすぎる詳細設計書 - SiroKuro Page」で示されているようなコードと1対1に対応したような詳細設計書は、書くだけ無駄だと思っている。ただ、ちゃんとした詳細設計書をつくるなら、処理内容(内部の処理の実装方法)の書き方をどのように実装言語に合せるかではなく、処理内容を一切書かないようにするべきだと考えている。 なぜなら、処理内容をいくら詳細に記述したところで、それは仕様ではなくコードであり、仕様の代わりに記述したコードでは、バグも含めて記述されているため、そのコードのみでは正しいか間違っているかを判定できないからだ。 コードの他にどういった動作が正しいのかを判定する基準が必要で、その基準が仕様であり、詳細設計書にはその仕様を記述する必要があると考えている。 現に、例として示された処理概要では、

    詳細設計書に何を書くべきか? - Sacrificed & Exploited
  • 設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited

    SIerの常識:「誰が書いても同じソースコードになるように、詳細な実装方法の記述された設計書を書かなければならない」 プログラマの常識:「誰が書いても同じソースコードになるような設計書は書くだけ無駄、誰が書いても同じ振る舞いをするように、詳細に振る舞いを記述した設計書を書かなければならない。」 プログラムを作るうえで設計書や、仕様書の類は欠かすことができない だが、設計書や仕様書をちゃんと作っているプロジェクトでもよくデスマーチに陥っている。 なぜか?「設計書に記載するべき内容が間違っている」からだ。 (設計が間違っている場合も多々あるが。) 間違ったことをまじめにやっても良い結果は得られない。 「誰が書いても同じコード」は大事なことなのか - yvsu pron. yas 昨日、大手SIerの方々と話をする機会があって、そこで出てきたのが、「誰が書いても同じコード」になることが重要で、そ

    設計書の非常識1.設計書には詳細な実装方法を書く - Sacrificed & Exploited
  • 詳しすぎる詳細設計書 - SiroKuro Page

    「詳細設計書」と呼ばれるドキュメントがあります。各処理の入出力や処理概要を記載した文章です。 入力: 「性別と身長のペア」のリスト 出力: 男性の平均身長」と「女性の平均身長」の差 処理概要: 変数「男性の合計身長」「女性の合計身長」「男性の人数」「女性の人数」を 0 で初期化する 入力を受け取る 入力されたリストから要素を読み込む 入力されたリストの要素数だけ以下を繰り返す 要素を1つ読み込み、条件分岐する もし要素が男性なら、変数「男性の合計身長」に身長を加算し、変数「男性の人数」を1増加させる もし要素が女性なら、変数「女性の合計身長」に身長を加算し、変数「女性の人数」を1増加させる 次の要素を読み込む 「男性の合計身長」÷「男性の人数」−「女性の合計身長」÷「女性の人数」を、変数「計算結果」に代入する 出力する イメージとしては、こんな感じ。各社それぞれ、どんな詳細設計書を書いてい

    詳しすぎる詳細設計書 - SiroKuro Page
  • 1