3

オンライン Web ベースのソフトウェア アプリケーションに関しては、製品開発のアプローチを決定するのに苦労しています。

私たちは、SAASサービスとして提供できる可能性のあるオンラインWebアプリケーションのシステム設計に取り組んでいます。ここでは、システムの設計と実装に関する決定に続いて、コストも考慮して決定するのに苦労しています。

アプローチ A:

基本的な要件を満たし、目の前の問題を解決するための非常に基本的な要件を考慮して、すべてを設計および開発し、それを起動します。すべてをマイクロ最適化することにあまり集中しなくても、数百人のユーザーをサポートするのに十分なシステムです。

新しいモジュールを追加することにより、クライアントの要求に応じて新しい機能を追加します。

したがって、シンプルな設計、単一の開発、必要に応じてインフラストラクチャをアップグレードするか、必要に応じて最適化することにより、必要に応じてスケーリングし、将来必要に応じてシステムを完全に新しいシステムに置き換える可能性があります。

サーバーは同じままですが、クライアント アカウントのデータベースは異なります。ここでも、個別のデータベースにアクセスするクライアントごとに異なるアプリケーションがホストされます。必要に応じて、新しいサーバーを追加することがあります。管理/保守とアップグレードは少し難しいですが。

アプローチ B:

私たちは完全な要件、付加価値を追加する可能性のある追加機能を調査し (ただし、そのような追加機能がどれだけの価値を追加するかについてはまだわかりません)、非常に多数のユーザーをサポートするシステムを設計します (大量のハードウェア セットを使用)。 ) 初めから。

最初から非常に最適化されたフル機能のアプリケーションを起動します。

単一のデータベースとアプリケーション ホスティングで複数のクライアント アカウントをサポートするように設計し、成熟した SAAS アプリケーションのようなアーキテクチャを備えたクラウド サーバー/負荷分散サーバーに実装します。これにより、コーディングと保守が非常に困難になります。そして、実装には間違いなくもっと時間がかかります。

ご了承ください、

機能リスト、UI、および使用する可能性のあるテクノロジーのセットアップを用意しています。この状況に対処するための最善のアプローチを理解したいと思います。

以前のように、別の製品開発プロジェクトで、すべての機能のセットを完了するのに時間がかかりすぎ、さらにはまったく使用されていない機能が含まれていることを見てきました。このようなプロジェクトでは、コストに関する考慮事項が非常に高くなります。私はアプローチ A を採用したいと考えています。さらに、2 番目のアプローチと比較して、すぐにユーザーからのフィードバックが得られるので、どの機能に注目し、その理由を判断するのに役立つかもしれません。さらに、必要に応じて、アプローチ B に似たシステムに焦点を当ててアプリケーション全体を書き直すことがあります。

他の企業がこの種の状況をどのように管理しているかを知りたいのですが、そのようなプロジェクトを実施するための最良の方法は何ですか?

4

3 に答える 3

6

これは、古典的なBig Design Up Front (BDUF)の議論の新しいバージョンです: 実装前に設計を完了し、完成させるべきか、それとも漸進的に設計するべきか?

pro-BDUFagainst-BDUFのかなり良い議論を見てきました。個人的には、私は中間点を好みます: 事前に設計を行う必要があります。そうしないと、反復によって設計が大幅に変更されてしまいますが、このフェーズに時間がかかりすぎてはいけません。そうしないと、アーキテクチャ ドキュメントと退屈なプログラマーしか残らないことになります。何ヶ月も働いた後。

そこで、アプローチ B を少し加えてアプローチ A を行います。

于 2012-05-10T12:14:31.917 に答える
3

場合によります。

経験則:

  • 「何もない」は「壊れた」よりも優れています。
  • 80% のソリューションは、何もないよりはましです。
  • 最初の 80% はリソースの 80% を消費します。
  • 次の 20% は、リソースのさらに 80% を消費します。
  • あなたが 80% で出荷しない場合、他の誰かが出荷します。
  • 80%に到達するまでは、残りの20%はわかりません。
  • 環境と要件は、あなたが思っている以上に変化します。この規則の適用後も。

顧客を長時間待たせたり、壊れた製品や保守不可能な製品を出荷したりして、顧客を怖がらせないでください。(まだ) 必要のないインフラストラクチャーにお金を使わないでください。

于 2012-05-11T13:14:47.940 に答える
1

アプローチ A は理にかなっているように聞こえます... アジャイル SCRUM も採用できれば、スプリントでクライアントと反復的に作業できることを意味し、各スプリント後に製品バージョンと機能を開発して提供できます。クライアントは、ソフトウェアのより小さなユニットが配信されるのを見ることができます....多くの場合、クライアントは、必要な新機能について考えを変えます。

したがって、クライアントのニーズに応える機会が常にあり、クライアントが必要とするものだけを構築することができます。

于 2012-05-11T12:57:54.000 に答える