建立一个扔掉vs第二系统效果

一方面，有一条建议说“建一个要扔掉”。只有在完成软件系统并查看最终产品之后，我们才能意识到设计阶段出了什么问题，并了解我们应该如何真正做到这一点。

另一方面，存在“第二系统效应”，它表示设计的同一类型的第二系统通常比第一个系统差。有许多功能不适合第一个项目，而被推入第二个版本通常会导致过于复杂和过度设计。

这些原则之间不是在这里有些矛盾吗？对这些问题的正确看法是什么，两者之间的边界在哪里？

我认为，这些“好的做法”是在弗雷德·布鲁克斯（Fred Brooks）的开创性著作《神话人月》中首次得到推广的。

我知道其中一些问题已通过敏捷方法解决，但从深处看，问题仍然是原则。例如，在上线之前，我们不会对3个Sprint进行重要的设计更改。

一开始要扔掉的东西来自“不知道自己不知道的事情”，因此您可以边走边学，一开始就应该做的事情。

第二系统效果来自“现在知道您不知道的事，但是不知道您仍然不知道”。即第二系统效果来自于在没有知识的情况下尝试构建比第一个系统更大，更漂亮，更复杂的系统开始时需要-听起来很像第一个系统发生的情况。

因此第二系统的作用并不矛盾。据我所知，构建具有与第一个相同功能的第二个系统从未完成。第二个系统始终必须“更好”，因此更加复杂，因此预期与第一个系统基本类似的问题-应该扔掉。

因此，在不扩大范围的情况下构建一个可以扔掉，扔掉的东西并重新构建它，就不会有第二个系统问题。（在具有紫色天空，粉红色海洋和飞猪的行星上，此操作通常更常见。）

您所指的问题意味着跳过了几件事，因此导致系统出错。让我描述一些缺少的步骤：

质量管理-第一次就做对！切勿使用任何临时性的技巧或临时性的让步。无需进行任何返工。所有资源都得到有效利用，您所做的一切都对项目做出了应有的贡献。

可行性分析-发现业务需求。为项目创建一个业务案例。

项目计划-明确定义您的初始范围，计划解决方案的交付方式，创建基准并遵守计划。不要把时间花在关键路径之外的任何事情上。

需求工程-引发业务需求（即捕获业务流程并确定计算机化系统应支持哪些业务操作，将1：1业务操作转换为系统用例）。验证并验证！（我们在构建正确的事物吗？我们在构建正确的事物吗？）所有需求必须与原始业务需求相关联。

软件设计-将用例和领域模型转换为组件设计和解决方案体系结构。所有组件都必须链接到RE的要求。

实施-按照设计中的要求对软件进行编码。所有代码都必须链接到SD中的组件。

验证-单元测试，集成测试，性能...（现在将需要测试RE中的所有用例）

这些是软件过程的一些关键方面。提及的活动是软件工程的一部分。这样，您便可以构建满足实际业务需求的正确软件解决方案，并按时，按预算和按规范进行构建。

查找以下术语以构建更好的软件并在第一时间将其正确使用：

• 可行性分析（尤其是如何建立业务案例）
• 项目管理（尤其是具有减轻风险的项目计划和风险登记）
• 需求工程（启发，分析，规范，验证）
• 软件设计（UML和基于组件的软件工程）
• 软件构造（设计模式，框架，防御性编程）
• 软件验证（单元测试，UAT等）