@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
どの開発プロセスを用いますか?
1
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2006-06-06 20:12
こんばんは。
また皆様のご意見を伺いたいと思います。 ちょっと前にも 話が出ているのですが、観点が違う気がしたので新しくたてました。 昨今、開発プロセスは沢山出ていると思うのですが、 大規模案件で用いることが出来る開発プロセスは結局どれがいいのかな、と考えています。 個人的には ( 感覚ですが ) ・アジャイルは大規模には向かない ・なんだかんだでウォーターフォール型でフェーズを分けるのがまだ主流 ・裏タスクでプロトタイプとかを作って、出来るだけ後戻りをしないような工夫をする という感じなのかなぁ、と。 で、「ウォーターフォールなんだけど裏でプロトを作る」のを 格好よく言うのが UP ( RUP ) かなぁ、と。 感覚論でいいのですが、皆様がもし「大規模案件があるんだけど、開発プロセス決めてよ」と 言われたら何を採用しますか? ※ 色々と前提条件があると思いますが ( 言語は?とか ) 、 その辺りは都合のいいように解釈して下さい ※ 大規模案件とはピーク時で1000人くらいの PG がいる感じを想定しています 宜しくお願いいたします。 | ||||
|
投稿日時: 2006-06-10 15:55
objectです。
>昨今、開発プロセスは沢山出ていると思うのですが、 >大規模案件で用いることが出来る開発プロセスは結局どれがいいのかな、と考えています。 > >個人的には ( 感覚ですが ) >・アジャイルは大規模には向かない >・なんだかんだでウォーターフォール型でフェーズを分けるのがまだ主流 >・裏タスクでプロトタイプとかを作って、出来るだけ後戻りをしないような工夫をする >という感じなのかなぁ、と。 全体として、答えるのが少し難しい内容ですね。 私の個人的見解ですが、例えば 「アジャイル」と「UP(RUP)」は、その観点がかなり違うと思います。 従って、これらに関しては 「一概にどちらが良い」 という問題では無いと思います。 それから、 「フェーズ・プロトタイプ等」 一部分の概念を抜き出すと、 「全体としては意味の無い議論になる」 様に思います。 重要なのは、例えば 「オブジェクト指向」を「工業プロセス」という観点から、整理してみる事 だと私は思います。 #実際に「工業プロセス」を採用するかどうかとは無関係に。 そいう意味で、 「フェーズ・プロトタイプ等の言葉」 には拘らない方が 「方向性を見失わない」 と私は思います。 >で、「ウォーターフォールなんだけど裏でプロトを作る」のを >格好よく言うのが UP ( RUP ) かなぁ、と。 私は、違うと思います。 「UP(統一プロセス)」 の意味を一言で限定するのは、 「UML」と共通する問題等があり 難しいと思いますね。 #それから、ベースは同じですが、「UP≠RUP」です。 もし、プロセスに関する勉強をするのであれば、 色んな意味で、私は 「オブジェクト指向ソフトウエア工学(OOSE)」 を一読される事をお勧めします。 #「OOSE」から「何を引き出せるか」が重要ですが。 >感覚論でいいのですが、皆様がもし「大規模案件があるんだけど、開発プロセス決めてよ」と >言われたら何を採用しますか? >※ 色々と前提条件があると思いますが ( 言語は?とか ) 、 >その辺りは都合のいいように解釈して下さい >※ 大規模案件とはピーク時で1000人くらいの PG がいる感じを想定しています 「1000人」でのソフトウエア開発は、 「私としては」有り得ない話だと思います。 恐らく、状況として 「複数の会社から要因を集める事になる」 と思います。 それらの技術者が 「協調して整合性のある作業をする」 には、 「全体とあらゆる部分、また、それらの関係を記述し、しかも誤解が起きない」 つまり 「厳密な意味で、全ての要員が実際に一貫した開発を行う事」 が求められます。 結局、何らかの「情報表現・伝達手段(ツール)」無しには無理だと思います。 従って、もし、強いて上げるなら、 「RUP」ですかね? #ローズは使った事がありますが、今の「RUP」はありません。 #余談ですが、「RUP」はオープンソース化されてたんですね。 http://itpro.nikkeibp.co.jp/article/NEWS/20051013/222708/ 私なら、熟成された 「コンポーネントベース」 の出来るだけ少人数の開発を志向します。 その為には、シッカリした 「コンポーネントベースの組織」 が必要ですけどね。 | ||||
|
投稿日時: 2006-06-18 11:23
小僧さん,こんにちは.
私ならば自分で作ります.ただし,ベースはウォータフォール型なのか繰り返し型なのか一番条件に合っていそうなものを選びます. 大規模開発ということは,開発コストに余裕があるものと仮定しています. 経験を少しお話しすると,私がやった仕事で一番大きなプロジェクトだと(ピークでソフト開発者が300人くらい←大規模?),先行(プロトタイプ製造)部隊が本隊に先行して開発プロセスも設計しました.ベースはエンドユーザに見せる大工程はウォータフォールで,開発者の感覚はUnifiedProcessです(=前者は開発者にとってあまり意味がありませんでした). その時は,お客様が雲の上の存在(滅多に本音トークできない)だったので,アジャイルを採用するどころではありませんでした. アジャイルとその他を比べることはできないのですが,大規模開発ではエンドユーザが雲の上の存在であったり,お客様を含めると意志決定のパスが長すぎてアジャイルできない(アジャイルでなくなる)のではないか,というのが私の感想です. |
1