佃です。
Toshiyuki Takeda wrote:
>
> >「プロセス指向」というのが、顧客要件は初期段階でフィックスす
> >るもので、ドキュメントは大量に書かなくてはいけなくて、、、と
> >いうのであれば、プロセス指向と対極にあると思えます。
>
> これは正反対の理解ですよ。
>
> ソフトウェア開発プロセスには、ソフトウェアが有形でないことに
> 起因する数々の共通の問題（仕様変更の多さや、人間・組織の
> 問題）があるから、それをコントロールできるようにしましょう、と
> いうことです。そのために、継続的な計測とか構成管理とか
> コミュニケーションが重要になるということです。
>
これは「CMM」の説明にも見えますが、「プロセス指向」の説明で
しょうか？
（１）顧客要件は初期段階でフィックスするもの
（２）ドキュメントは大量に書かなくてはいけない
CMMでは（１）なんてことはどこにも書いてなく、「顧客要件の変
更はただちに計画や成果物に反映させましょう」と書いてあること
を知ってます。しかし、（２）については、「文書化された手順に
従って、＊＊」とか「＊＊を文書化する」という表現が目立ち、め
まいがします。（だから文書化はよくない、という主張ではありま
せん）
>
> 開発者間のコミュニケーションのために文書が必要だと
> 考えるか、ユニットテストとペアプログラミングでよいと
> 考えるか。もちろんそこには大きな差があるわけですが、
> 本質的に対極にあるとは私には思えません。
私も対極にあるとは思っていません。
プロジェクトにとってベストの選択をすればいいだけであり、状況
によりCMMを導入したり、XPを導入したり、両方をミックスしたり
すればいいと思ってます。
＃言うは易し、、、
> 松原さんの文章は翻訳書も含めてよい入門ではないかと
> 思います。ヨードンの本（「プログラマの復権」てタイトル
> だったかがわかりやすく、本質をついているかと。）
> http://www.iijnet.or.jp/sea/SPIN/SEACMM/matsubara.txt
推薦ありがとうございます。
「プロセス指向」について勉強します。
ちょうど我が家に「プログラマの復権」が転がっているので、ひま
を見つけて読まなくては！
＃買っただけではだめ、という具体例だなあ
--
Gunji Tsukuda (tsukuda@....jp)
Systems Development Laboratory, Hitachi, Ltd.