1

基本的に私のプロジェクトは製品ベースです。プロジェクトを開発したら、複数のクライアントをキャッチし、ニーズに基づいてアプリケーションをデプロイします。しかし、私たちは新しい機能とプロジェクトに依存するモジュールをコンポーネントとして配置することにしました。これで、私のアプリケーションは多くの顧客を獲得しました。すべての顧客は、コンポーネントに基づいてさまざまな機能を必要としています。ただし、すべてのクライアントのコンポーネントを集中化しています。コンポーネントの追加機能をクライアント固有のフォルダーに移動して展開します。私の問題は、複数のクライアントのコンポーネント機能を維持できないことです。コンポーネントの機能コードが増加し、クライアントの機能を追跡できません。複数のクライアントの複数のコンポーネント機能を維持するためのソリューションはありますか?

4

2 に答える 2

0

あなたは本質的にソフトウェア製品ライン (SPL) について話している: 共通ベースからのバリエーション。機能は既にコンポーネントとしてパッケージ化されているため、そのようなバリエーションを管理するには専用のツールが必要です。

その後、特定の顧客に固有の構成に基づいて、完全なカスタム アプリケーションを構築できます。もちろん、言うは易く行うは難しです。

モデル駆動型ソフトウェア開発 (MDSD) アプローチは、このタスクに大いに役立ちます。この開発セットアップをサポートできるそのようなシステムの 1 つが ABSE です。これは、特にソフトウェア製品ラインを実装できる新しい MDSD アプローチです ( http://www.abse.infoの情報- 免責事項: 私は ABSE プロジェクト リーダーです)。まだ商品はありませんが。アルファプレビューが来ています。

繰り返しになりますが、MDSD をコード生成と組み合わせて使用​​することで、私が理解していることを達成した企業をいくつか知っています。

于 2010-03-31T18:05:39.970 に答える
0

私は似たような分野の企業で働いたことがあります。製品ソフトウェアですが、非常にカスタマイズされています。

基本的に、会社が下す必要がある決定があります。あなたは製品会社(つまり、すべてのクライアントに広く同じものを出荷する)ですか、それともオーダーメイドの会社ですか。現時点では、彼らは 2 つの椅子の間にいるようで、特注のソフトウェア会社ができる方法で特定のクライアントの要求を満たす能力を備えた製品会社であることの経済性を望んでいるようです.

会社が製品ソフトウェア会社になりたいと仮定すると、それができない特定の技術的な理由がない限り、カスタマイズ可能なオプション (つまり、この特定の方法を示すフラグ) を介して処理される顧客ごとの変更を含む単一のコード ベースに移行する必要があります。状況が処理されているかどうか、この機能が利用可能かどうかなど)。

これらは実行時に設定できます (クライアントが必要に応じて変更できます - Word または Excel のオプションを考えてください)、またはビルド時に設定できます (ビルド時にコードを含めたり除外したりします)。クライアントは同じコード ベースから取得する必要があります。

しかし、これはビジネスが販売できるものを制限するため、ビジネスと合意する必要があります。販売するすべての変更は、単一の製品で対応できる全体的なビジョンに適合する必要があります。

もう 1 つの方法は、基本的にはクライアントごとに特注のソフトウェアを作成することです (クライアントが必要とするものに合わせて特別にコーディングされています) が、多くの共通ライブラリを使用します。それはそれで問題ありません。まさに彼らが望んでいるものを作成することができますが、最終的にはより多くの作業が必要になり、ビジネスはそれを理解して費用を負担する必要があります。

私たちは実際に両方を少しずつ行っています - すべてのクライアントに同一のサーバー製品があり、次にそれらに固有の Web クライアントとモバイル クライアントがあります (モバイルの場合、デバイス上に多くのデッド コードを持つことはできません -ウェブ関連は歴史的なものであり、すべてのクライアント向けの標準製品に移行する予定です)。

幸運を祈りますが、これは簡単な解決策のない難しい問題です。

于 2010-03-31T13:01:59.913 に答える