あなたが携わったソフトウェア開発プロジェクトについて、システム統合の概算コスト (総システム コストのパーセンテージとして表される) はどれくらいでしたか? システム統合には、他のソフトウェア、データベースなどとの統合が含まれます。
4 に答える
33.3% というのは、システム統合には通常、プロジェクトの他の段階 (コーディング、文書化など) ではあまり見られないかなりの量のリスクが伴うためです。
0 から 99% の間。私は、まったく統合されていないシステムと、基本的に他のシステムの統合だけのシステムを構築しました。統合の良いところは、見積もりが簡単なことです。ただし、インターフェースが完全に理解されている場合に限ります。次に、機能の単なる複製です。
ただし、いくつかの複雑な要因があります。彼らはそれを非常に高価なものから不可能なものにすることができます:
- あなたが統合しなければならないシステムはよく理解されていますか (それを開発したプログラマーはまだそこで働いていますか?)
- 統合する必要があるシステムは適切にリファクタリングされていますか (また、ユニット テストと受け入れテストが自動化されていますか)。
- 単一または複数のプラットフォーム?
- ドメインの専門家は利用できますか?
これは、特に慣れていないシステムとの統合に直面している場合は、見積もるのが非常に難しい値です。あなたにできる最善の方法は、同様のプロジェクトでのあなたまたはあなたのチームの過去のパフォーマンスを追跡し、それらの値を使用して、新しいプロジェクトでどのようにパフォーマンスするかを見積もることです.
一般に、次の場合はシステム統合に時間がかかります。
- あなたやあなたのチームがまだ取り組んでいないプロトコル、データベースエンジン、オペレーティングシステムなどを使用しています。
- ベンダーまたはコミュニティのサポートが不足しているか、反応がありません。
- 公式のシステム ドキュメントの詳細が不十分であるか、古くなっています。
- このシステムは世界市場で大きなシェアを持っていません。このようなシステムは、このサイトのようなオンライン プログラミング Q&A サイトで、幅広いユーザー ベースと大きなフットプリントを持つことはありません。これには、新しいシステム、あまり普及していないシステム、またはドメインに強く依存しているシステムが含まれる場合があります。
統合システムの重要性やその他の要因によって異なります。
私は、アプリケーションのコアである一連の Web サービスに統合されたシステムで働いてきました。Web サービスがダウンした場合、私たちのシステムは役に立たなくなりました。
コストを評価しようとするとき、次の変数をリストします。
- いくつのシステムを統合し、それらはどのくらいの頻度で変更されますか?
- これらのシステムのドキュメントはありますか?
- コントロールできないサードパーティのコンポーネント/サービスですか?
- 統合システムを制御できる場合、COBOL などの「レガシー」コードを使いすぎていませんか。(少なくとも私が働いている場所では、COBOLプログラマーは高価です);
- 従業員は統合システムとアプリケーション自体に慣れていますか?
- 統合サービスに障害が発生した場合、アプリケーションにどのような影響がありますか?
これらのシナリオでの従業員の時給はいくらですか? これらの統合システムで作業するには、何時間かかるでしょうか? あなたのプロジェクトにはいくらのお金がありますか? これらの詳細、特に最後の詳細を知らずに、あなたのケースに X% の費用がかかるとは言えません。