- - PR -
仕様書の書き方
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-09-18 11:20
仕様書にシーケンス図も描いてますが、どのあたりまで記述してますか
ＪＳＰ->servlet->beanの流れを書くだけでもしんどいけど どんな風に書いてるのかな？ | ||||
|
投稿日時: 2003-11-15 12:54
前のプロジェクトでは処理がいくつかのおおまかな何パターンかに
分類出来たのでそのパターン分書いていました。といっても僕自身は シーケンス図書いたことないんですが。 僕自身はXPの考え方(ドキュメントよりもコミュニケーションのが理解しやすい、 プログラムを作るのに最低限必要なものだけ作れば良い）って考え方に賛成なので 出来るだけ少なくしたいと思っています。 だけれども顧客はドキュメントを作れと言う。 「プログラマーじゃないあなた(顧客)がクラス図やシーケンス図見て分かるんですか？」 と言ってやりたいです。なんとなくドキュメントがないと不安なんでしょうかね？ それが例えまったく役に立たないものであったとしても。 ドキュメントのことになると僕らのチームはいつももめます。いったいどういうものが 必要なのか？僕らプログラマーはワープロやモデリングソフトで作ったきれいな 仕様書なんてなくてもプログラムを作れます。鉛筆で書いた雑なメモで十分です。 「保守のことを考えて」とか「あとから入ってくる人のため」とか いうけど、ソースコードを読めば理解できると思います。そして簡単に 理解できるような美しいソースコードを書くべきなんだと思います。 ってなことをアジャイルプロセスやXPは言ってるわけで、そんなことを プロジェクトのメンバーに言っても特に上の人たちは理解してくれません。 というか初めて聞いたというような顔をします。無知の知ってやつを知ってほしいですぜ | ||||
|
投稿日時: 2003-11-15 13:50
うん？XPはそんなこと言ってなかったような？
XPではドキュメントも大切であるって言ってたと思います。 ただ、プロジェクトのはじめで作られるドキュメントは、 時間と共に使えないものになっていくわけで(要求仕様の変更等で)、 ドキュメントを書かなくていいとは言ってないはず。 プロジェクトの途中はメモ雑記程度でよくて、 がっちりしたドキュメントは要らないと言ってるんだと俺はXPを解釈しました。 この解釈があってるかどうかは分かりませんが、一つの考え方と思ってくれれば幸いです。
| ||||
|
投稿日時: 2003-11-15 14:11
> 「保守のことを考えて」とか「あとから入ってくる人のため」とか
> いうけど、ソースコードを読めば理解できると思います。そして簡単に > 理解できるような美しいソースコードを書くべきなんだと思います。 ん〜でもそこにあるソースコードの意味は分かるが、 なぜそのコード(アルゴリズム)が選択されたのかはコードには書かれないので そういう意味でのドキュメントは必要でしょう。選択の理由は速度なのか 効率なのか何らかの制限があったからなのかはコードからは一般的には 読み取れませんし、もし読み取れたとしてもなぜその選択を？までは コードの表現外になります。 (余談)ということで個人的には開発日誌は必須にしてます。コード選択の理由等も 書いておく為に。(コードの書かれた経緯が分かれば修正もしやすくなる) | ||||
|
投稿日時: 2003-11-15 15:05
シーケンス図に関してのみいうと、
COBOLやC等の旧来の手続き型言語の場合、 メソッドレベルのシーケンス図は重要だと思います。 これらの古いタイプの記述言語は どうしてもスパゲティプログラムになりますので。 一方、Java、J2EEフレームワークを使用した オープン系システム開発の場合、 メソッドレベルのシーケンス図は無意味とおもいます。 なぜなら、フレームワーク自体が処理シーケンスを 規定しているわけで、例えば、ホームインターフェースを コールするとejbXXXが呼ばれるとか、コミットするとejbStore がコールされる等、ですので、自然言語レベルの記述、 例えば、在庫をチェックする、受注伝票を起こす等の 方が分かりやすいと思います。 ただ、困るのは古いタイプのPM、お客さんは このあたりが分かってないので不安なんですよね？ ただし、われわれエンジニアも、 取説と一緒で、ドキュメントがなくても分かりやすい システム作りを目指さないといけないですね。 | ||||
|
投稿日時: 2003-11-15 19:29
「ソースを見ただけでメンテできるように」というのは賛成です。 わたしもそれを目指し，ソースだけでは見えてこない部分も できるだけコメントとしてソース中に残すようにしています。 # 基本的には理由です。「なぜこういう方式にしたか」とか， # 「なぜこの処理がこの場所でなくてはならないか」とか。 # m.kuさんの開発日誌みたいなものです。 でも，「じゃぁドキュメントは要らないじゃん」とは思いません。 ソースとドキュメントではレベルが違うからです。 ソースを見ればたしかに「今どうなっているか」はわかります。 しかし「そのソースが正しいのかどうか」「本来どうあるべきなのか」 はわかりません。それを規定するのは仕様書です。 いくらソースがロジック的に正しくても，仕様書どおりの動作を していなければ，それはバグです。 # たまに「仕様が悪い」という場合もありますけどね。 また，いくら設計内とはいえ，メモだけで合意を済ませるのはキケンです。 打ち合わせのたびに変更が入りますし，あとで改ざんもできてしまいます。 さらに担当者が変更になった場合，そんなメモの内容まで正しく 引き継がれることは期待できません。 「これが最終的に正しいですよ」というのは正式にドキュメント化し， 日付を入れ相手のサインをもらい，プロジェクト内で１元管理のもとに 保管しておきます。 特に担当間のインタフェース仕様が明確になっていないと あとでトラブルが発生したときに「どっちが悪いか」でモメます。 # 特に会社が違ってたりすると。 # 「絶対にモメることはない」という幸せなプロジェクトなら # それはそれでもいいのかも知れませんが。 | ||||
|
投稿日時: 2003-11-15 21:17
こればっかりは、難しいですね。
そもそも、欧米と日本では システム開発に対する契約形態が大きく違うし 恐らく、旧来の手法（劣っているとは思いません。）で養われた 優秀なノウハウは新しいそれを上回っているのでしょう。 実際にそのような環境でXPを適用しても泥沼 プロジェクトになりかねないと思います。 とはいう私はXPの手法を指示する一人です。 しかし、プロジェクトが成功する為に選択する 手法として必ずしもXPは適用しません。 良い部分を徐々に取り込んでいます。 （テストファーストやペアプログラミング等） 理解者も増えてきています。 さぁ又明日から頑張りましょうね。 | ||||
|
投稿日時: 2003-11-16 04:33
toppoさんの言うように日本では欧米と異なる文化が根付いていて
簡単にXP的スタイルは取り難いですね。 そもそもXPではある程度固定されたチームでのプロジェクトを想定している と思っています。チームメンバが固定されているので、互いのコミュニケーション だけで知識を共有できる、と言うことだと。 しかしながら、今の日本のJava(特にWeb)プロジェクトは外注要員をかき集めた 一時的な寄せ集めメンバで構成されることが大半で、それに日本人特有の コミュニケーションの下手さもあいまって、ドキュメントなしで知識共有 することがかなり難しいと思います。 また、ウォーターフォールプロセスに則って、 分析〜設計は少数精鋭(?) 製造〜単体テストは人海戦術 結合テスト以降はまた少数 バグが多発してまた人海戦術 という風にメンバの増減が激しく、引継ぎも適当なのでやはりドキュメントに 頼るしかないというのが現状だと思います。 # 確かに全く意味をなさないドキュメント作成を迫られて、そのおかげで # 肝心のソフト開発の時間が減る、というのはどうかと思いますけどね。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。