- - PR -
VBの開発プロジェクトで、プログラム設計書って作っていますか?
1
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-02-16 10:34
皆さんは、VBやC#での開発プロジェクトで、プロシージャ定義書、クラス定義書等のプログラム設計書って作っていますか?
私は、全く作っていません。 ソースを作って、HotDocument を 使って勝手に出力されるExcel、chmファイルを納品しているだけです。 http://www.hotdocument.net/main/about.html 納品用にプログラム設計書を、このように作れば良いよ、というような情報があれば教えていただけないでしょうか。 | ||||||||||||
|
投稿日時: 2008-02-16 21:44
納品用となると、契約内容にも関連するので一概には言い切れないですね。
場合によっては、ドキュメントのフォーマットを指定してくるケースもありますから。 そういった面倒がない場合ですと、 私もツールによる自動生成で済ませてしまえるようにしてます。 昔はNDoc、最近はSandCastleで・・・ ただ、プロジェクトメンバー数が増えるに従って、先に納品を意識した設計書を 起こす、というのはやります。人数が多いとこの方が結果楽になるかなぁ、と。 | ||||||||||||
|
投稿日時: 2008-02-17 20:03
自分個人で使うツールレベルであれば、ソースのコメントで十分ですが、
仕事の場合は下記の理由でドキュメンテーションするべきでしょう。 ・テストエンジニア、QAエンジニアが各テストレベルを担当する場合、 テストケースを作成する為のテストベースとなる。 ・テスト実施時、正常動作なのか異常動作なのかを判別する (「仕様です」と言い逃れするプログラマがいますから)。 ・開発時、「何を目的としているのか」を明確にする。 ・メンバーの意識合わせを行なう。 ・運用保守時、「何故そういう実装なのか」を調査する時間を省く。 ・運用保守時、運用エンジニアが担当システムを手早く理解するのに役に立つ。 納品を考えると、自動生成ツールで十分ですが、他のメンバーやテスト、 運用するエンジニアが別であったりする場合必要と考えるべきでしょう。 転ばぬ先の杖です。この杖があると、みんなが楽になりますから。 ドキュメンテーションせずにコーディングする場合のリスクが高いと考えています。 | ||||||||||||
|
投稿日時: 2008-02-18 11:10
エンドユーザーへの納品が多い私も作ったことがありません。 仮に作らなければならなかった場合はやはり自動生成して終了としたいですね。
ゆかさんは、本当に HotDocument がお好き ですね。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||||||
|
投稿日時: 2008-02-18 11:49
ここ2年ほど、私の仕事の範囲ではまったく作っていません。 しかし、その前にやっていた、多くのメンバーのかかわる開発では作ることが ありました。 これらのレベルの設計は頻繁に変化するので、 変化後の修正作業を行うだけの作業期間、時間に余裕があるとか、 設計を変更しなくても済むほどに十分にスキルの高いメンバーだけで構成され ているとかで無い限り、 プログラムソースコードとドキュメントの乖離という、最悪の事態に陥る ことでしょう。 もちろん、設計書すべてを否定しているのではないので、お間違いなく。
私も、お客さま向け納品物の重量と厚みを増すために作ることはあります。 ソフトウェアは本質的に目に見えないものですから、それをできるだけ 見えるようにしようとするための努力でもありますし、お金をもらうため でもあるので、これを否定はしません。
納品用ではないですが、私がもしも引き継ぎのエンジニアならば、 ・誰がこれにかかわっていて、わからないことは誰に聞けばいいか ・なぜそれを作ったか ・なぜ「わざわざ」そのような構造になっているか ・どの資料をどこから読めば理解しやすいか ・どのプログラムコードをどこから読めば理解しやすいか などを、「簡潔にテキストファイル」にまとめた資料が添付されていると、 前任者の優しさに涙を流して感謝することと思います。 _________________ たつごろー codeseek こみゅぷらす |
1