パッケージソフトカスタマイズプロジェクトにおける開発手法

投稿者

投稿内容

オイル: 会議室デビュー日: 2004/03/01; 投稿数: 6

投稿日時: 2004-03-01 18:58

初めまして。よろしくお願いします。
あるパッケージソフト（カスタマイズ前提のソフト）を売っています。
まさかこんなに同時に受注があるとは思わず、販促をしていたら、３社同時に
受注と相成りました。(;_;)
３社は開発期間は約半年で、開発スケジュールも３社とも全て重複、開発規模も３０人月程度
で同じです。
１社だけなら、要件定義・外部設計・内部設計・プログラミング・結合テスト・
運用テスト・本稼動とセオリー通りすすんでいけば順当にモノが出来上がると思います。

ただ、今回３社同時という事を逆手にとって、何か効率化して
短期間で開発をできればと考えております。
（セオリー通り実施すれば問題なく納品できるとは思うのですが、
せっかくのチャンスなので・・・）

そこで、お聞きしたいのですが、この様な”同時”、”パッケージのカスタマイズ”
というキーワードで、効率化出来る事／もしくは効率化した経験をお持ちでは
ありませんでしょうか？

今考えているのは、
・設計に関して、１社で作成した設計書を流用して作成する
・プログラミングに関して、同一のモジュールを同一要員にカスタマイズさせる
事です。

以上、よろしくお願いします。

がるがる: ぬし; 会議室デビュー日: 2002/04/12; 投稿数: 873

投稿日時: 2004-03-02 12:42

どもも。がると申します。

引用:
オイルさんの書き込み (2004-03-01 18:58) より: そこで、お聞きしたいのですが、この様な”同時”、”パッケージのカスタマイズ” というキーワードで、効率化出来る事／もしくは効率化した経験をお持ちではありませんでしょうか？

一言でシンプルに身も蓋もないのですが。
オブジェクト指向での設計＆コーディングが有効だと思います。
# まぁ元々のパッケージにもよるので「絶対」ではないのですが
# 非オブジェクトで書かれたコードをオブジェクト指向に比較的
# 短期工数で置きなおす手法もなくはないので。

引用:
今考えているのは、・設計に関して、１社で作成した設計書を流用して作成する・プログラミングに関して、同一のモジュールを同一要員にカスタマイズさせる事です。

オブジェクト指向は、便利なことに「設計書もオブジェクトとして」
扱っていくことが出来ます。
ですので、設計書から仕様書(顧客提出用)、プログラムからテスト
まで、全部オブジェクト指向的に扱うことが可能です。
オブジェクト指向を身も蓋もなく書くと「変更に強いモノを作る
手法」と考えていただいてよいのかなぁ、と。
今回のような「ベースがあってそれをカスタマイズ」というパターン
にはかなり強い開発手法です。
# 専門用語で書くと「基底クラス(ベースになるソフト)から
# 派生クラス(カスタマイズしたソフト)を作っていくわけですな。

あと複数人数を使うのであればCVSとかのソース管理をしっかりと
しておくと後々泣かずにすみます :-P
# 過去に「危ないところを食い止めた」経験も「他人が悲鳴を
# 上げているのを耳にした」経験もあるので ^^;

オブジェクト指向のスキルがまったくない状態からの構築は
若干しんどいと思うのですが、一度身に着けておくと以降非常に
便利だと思います ^^

はにまる: ぬし; 会議室デビュー日: 2003/12/19; 投稿数: 969; お住まい・勤務地: 誤字脱字の国

投稿日時: 2004-03-02 18:29

ハニーな、はにまるです。（自分でも意味不明）

始めに
　　”同時”、”パッケージのカスタマイズ”に絞って効率化を何故求めるのでしょうか？
　　素朴に疑問に思いました。

　　マルチタスクで仕事をこなしている人は、誰しも経験があると思いますが、
　　１つのタスクの延期が、全工程に影響する恐れがあります。
　　先に安全策を講じて、その上で効率化出来る箇所を模索される事をお奨め致します。

経験上、
　　１．効率化し易い工程は「開発」と「テスト（運用テストは除く）」です。

　　２．「要件定義」・「外部設計」の効率化は、御客様の状況や要件に依る話か、
　　　　汎用的な話になる為、ここでは何とも言えません．．．

　　３．「要件定義」・「外部設計」・「運用テスト」・「本稼動」は人が限定される為、
　　　　スケジュールに要注意です。ＷＢＳを確りと作っておきましょう。
　　　　私は何時も抜けがあります。（私の事はどうでもいいか！

)

　　４．「運用テスト」・「本稼動」では思わぬトラブルが発生した場合を想定し
　　　　３社とも日程をずらす事をお奨め致します。
　　　　難しい話とは思いますが極力のレベルで頑張ってみてください。

作業環境として、
　　マルチプロジェクトでは、問題、知識、連絡事項などを即時に共有出来る環境を
　　整えておくとシングルプロジェクトよりもその恩恵を受けれます。
　　インフラの話だけではありません。連絡手順を取決めているか否かが非常に重要です。

実際の効率化ですが、
　　１．汎用的なテストデータを事前に準備して置く。
　　２．検証用のＳＱＬを先行して準備して置く。
　　
　　　　パッケージであらば、１と２の効果抜群です。
　　　　でも用意していないパッケージベンダーが多いのはなじぇ？

　　３．パッケージの作りと人資源にもよりますが、
　　　「単体テスト」と「結合テスト」の平行化もありです。

パッケージソフトカスタマイズプロジェクトにおける開発手法

スキルアップ／キャリアアップ（JOB@IT）