ソフトウェアプロセス(2)

一つ前

http://d.hatena.ne.jp/tsugehara/20061119/1163937809
なんかトラックバックでリンク構成って微妙だよなと思いつつ。

彼の言うソフトウェアプロセス

全部受け売りでした・・。
http://www.google.co.jp/url?sa=t&ct=res&cd=1&url=http%3A%2F%2Fwww.amazon.com%2FUnified-Software-Development-Process%2Fdp%2F0201571692&ei=-k1iRe7uFoWQsALRisyZCA&usg=__WV41iLBLl78l7HKncpFerJ3scrU=&sig2=Vs5gUDI8GygH1tUxY9sxYg


資料も作ってきたのだが、この本から抜粋しただけのショボショボ資料。
じゃあこの本をうちのソフトウェアプロセスにすりゃいいじゃんというと、カスタマイズは必要だという。
で、カスタマイズした結果がショボショボの資料なわけだが、3ページで作業項目だけ書いてある資料じゃ認識の統一が計れんと却下させてもらった。


本の元ネタはRational Unified Processの方で、こっちは有名だろう。
http://en.wikipedia.org/wiki/Rational_Unified_Process
UML使い、特にRational Rose使いには常識的な話なのかな。
でも私はあんま知らん。いかにこれまで下流工程ばかりやってきたかという話なのかもな。

会議の結果

延々2時間に渡って話せた事といえば、結局彼が何を言いたいのか理解出来たというだけだった。
通訳さんは非常に優秀だが、通訳が入ればワンクッションが入るわけでどうしても時間がかかるというのもあるが、ベトナム人SEの彼の話が長いというのもありそう。
各自宿題を持ち帰って本日また話す事に。


ユースケース駆動型開発というものはいいと思うし、必要なことも理解は出来るが、そんなガチガチに固めるのは後でいいというのが、まあ結論かな。
彼に開発の全権は委任してもいいので、彼が出来るなら別だが、提案してきた資料の中で作り方のわからない資料もあるから、全ての作業を一度試験してから実運用しないと無理だという事。
要するにスキル不足で出来ないという解釈しかしてあげられないので、まあ背伸びしないでおとなしくしててちょという感じ。
ベトナム人SEはおそらくこの手のちょっと古いが堅牢な設計関係の教育は受けてそうなので、エンジニア採用後皆でまとめていけばいいんじゃないすかね。


軽く読んだ限り、RUPは私が嫌いそうなものっぽいのが難点。
ここはもう少し理解してから調整しないとな。