3

关于基于在线 Web 的软件应用程序，我们在决定产品开发方法方面面临困难。

我们正在为有可能作为 SAAS 服务提供的在线 Web 应用程序进行系统设计。我们在决定后续系统设计和实施相关决策时面临困难，也有很多成本考虑。

方法一：

我们设计和开发一切以考虑非常基本的要求，即满足基本要求并解决手头的给定问题，然后启动它。一个足够好的系统来支持几百个用户，而不需要过多地关注微观优化一切。

我们通过添加新模块在客户请求时添加新功能。

因此，简单的设计、单一的开发、必要时通过升级基础设施或在需要时进行优化来扩展，并且将来可能会根据需要用全新的系统替换系统。

我们保留相同的服务器，但客户帐户有不同的数据库。同样，为访问单独数据库的每个客户端托管不同的应用程序等。当需要时，我们可以添加新服务器。虽然管理/维护和升级有点困难。

方法 B：

我们研究全部需求，可能添加的可能增加附加值的功能（尽管我们仍然不确定哪些附加功能增加了多少价值？）并设计支持大量用户的系统（具有大量硬件） 从开始。

我们推出了功能齐全的应用程序，该应用程序从一开始就进行了很好的优化。

我们将其设计为在单个数据库和应用程序托管中支持多个客户端帐户，并在云服务器/负载平衡服务器上实现它，其架构类似于成熟的 SAAS 应用程序。尽管这使得编码和维护变得非常困难。而且肯定需要更多的时间来实施。

注意，

我们已准备好功能列表、UI 和可能使用的技术设置。我想了解解决这种情况的最佳方法是什么。

正如我之前在另一个产品开发项目中看到的那样，具有所有功能的集合，完成时间太长，甚至它有一些根本没有使用的功能。此类项目的成本考虑非常高，我更愿意采用方法 A，因为它快速、简单且可预测。此外，与第二种方法相比，我很快就会收到用户反馈，这可能有助于我决定要关注哪些功能以及为什么要关注哪些功能。此外，当需要时，我们可能会重写整个应用程序，重点关注类似于方法 B 的系统。

我想了解其他公司如何处理这种情况，以及实施此类项目的最佳方式是什么？

4

3 回答 3

6

这是经典的大设计前期 (BDUF)辩论的新版本：我们应该在实施之前完成和完善设计，还是应该增量设计？

我已经看到了很好的论点pro-BDUF和反对-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，这意味着您可以在 Sprints 中与客户进行迭代工作，您将在每个 sprint 之后开发和交付产品版本和功能。客户可以看到交付的软件的较小单元……而且，客户往往会改变他们想要什么新功能的想法。

因此，您将始终有机会响应客户的需求，并且只构建客户需要的东西。

于 2012-05-11T12:57:54.000 回答