@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
パッケージソフトカスタマイズプロジェクトにおける開発手法
1
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-03-01 18:58
初めまして。よろしくお願いします。
あるパッケージソフト(カスタマイズ前提のソフト)を売っています。 まさかこんなに同時に受注があるとは思わず、販促をしていたら、3社同時に 受注と相成りました。(;_;) 3社は開発期間は約半年で、開発スケジュールも3社とも全て重複、開発規模も30人月程度 で同じです。 1社だけなら、要件定義・外部設計・内部設計・プログラミング・結合テスト・ 運用テスト・本稼動とセオリー通りすすんでいけば順当にモノが出来上がると思います。 ただ、今回3社同時という事を逆手にとって、何か効率化して 短期間で開発をできればと考えております。 (セオリー通り実施すれば問題なく納品できるとは思うのですが、 せっかくのチャンスなので・・・) そこで、お聞きしたいのですが、この様な”同時”、”パッケージのカスタマイズ” というキーワードで、効率化出来る事/もしくは効率化した経験をお持ちでは ありませんでしょうか? 今考えているのは、 ・設計に関して、1社で作成した設計書を流用して作成する ・プログラミングに関して、同一のモジュールを同一要員にカスタマイズさせる 事です。 以上、よろしくお願いします。 | ||||||||
|
投稿日時: 2004-03-02 12:42
どもも。がると申します。
一言でシンプルに身も蓋もないのですが。 オブジェクト指向での設計&コーディングが有効だと思います。 # まぁ元々のパッケージにもよるので「絶対」ではないのですが # 非オブジェクトで書かれたコードをオブジェクト指向に比較的 # 短期工数で置きなおす手法もなくはないので。
オブジェクト指向は、便利なことに「設計書もオブジェクトとして」 扱っていくことが出来ます。 ですので、設計書から仕様書(顧客提出用)、プログラムからテスト まで、全部オブジェクト指向的に扱うことが可能です。 オブジェクト指向を身も蓋もなく書くと「変更に強いモノを作る 手法」と考えていただいてよいのかなぁ、と。 今回のような「ベースがあってそれをカスタマイズ」というパターン にはかなり強い開発手法です。 # 専門用語で書くと「基底クラス(ベースになるソフト)から # 派生クラス(カスタマイズしたソフト)を作っていくわけですな。 あと複数人数を使うのであればCVSとかのソース管理をしっかりと しておくと後々泣かずにすみます :-P # 過去に「危ないところを食い止めた」経験も「他人が悲鳴を # 上げているのを耳にした」経験もあるので ^^; オブジェクト指向のスキルがまったくない状態からの構築は 若干しんどいと思うのですが、一度身に着けておくと以降非常に 便利だと思います ^^ | ||||||||
|
投稿日時: 2004-03-02 18:29
ハニーな、はにまるです。(自分でも意味不明)
始めに ”同時”、”パッケージのカスタマイズ”に絞って効率化を何故求めるのでしょうか? 素朴に疑問に思いました。 マルチタスクで仕事をこなしている人は、誰しも経験があると思いますが、 1つのタスクの延期が、全工程に影響する恐れがあります。 先に安全策を講じて、その上で効率化出来る箇所を模索される事をお奨め致します。 経験上、 1.効率化し易い工程は「開発」と「テスト(運用テストは除く)」です。 2.「要件定義」・「外部設計」の効率化は、御客様の状況や要件に依る話か、 汎用的な話になる為、ここでは何とも言えません... 3.「要件定義」・「外部設計」・「運用テスト」・「本稼動」は人が限定される為、 スケジュールに要注意です。WBSを確りと作っておきましょう。 私は何時も抜けがあります。(私の事はどうでもいいか! ![]() 4.「運用テスト」・「本稼動」では思わぬトラブルが発生した場合を想定し 3社とも日程をずらす事をお奨め致します。 難しい話とは思いますが極力のレベルで頑張ってみてください。 作業環境として、 マルチプロジェクトでは、問題、知識、連絡事項などを即時に共有出来る環境を 整えておくとシングルプロジェクトよりもその恩恵を受けれます。 インフラの話だけではありません。連絡手順を取決めているか否かが非常に重要です。 実際の効率化ですが、 1.汎用的なテストデータを事前に準備して置く。 2.検証用のSQLを先行して準備して置く。 パッケージであらば、1と2の効果抜群です。 でも用意していないパッケージベンダーが多いのはなじぇ? 3.パッケージの作りと人資源にもよりますが、 「単体テスト」と「結合テスト」の平行化もありです。 |
1