prototyping - 进化与一次性原型

Question

谁在“低保真与高保真原型”辩论中获胜？零原型 (P0) 是否应该是最终产品的第一个版本？或者应该是 P-0 总是一次性的？行业青睐什么方法？

来自维基百科的优秀文章：软件原型

Answer 1

原型应该永远是一次性的——原型用于快速证明一个概念并影响实际产品的设计。因此，许多对实际产品很重要的东西（经过深思熟虑的架构和设计、可靠性、安全性、可维护性等）都被搁置了。如果您在构建原型时确实考虑了这些因素，那么您就不再是真正构建原型了。

我对代码直接演变成实际产品的原型的经验表明，最终结果会因此受到影响——缺乏真正的架构导致了许多拼凑在一起的代码，必须不断地修改这些代码才能添加新功能。我什至见过一个案例，原型快速开发所选择的原始技术并不是实际产品的最佳选择，V2 需要完全重写。

Answer 2

我认为我们，书呆子，已经输掉了这场特殊的战斗——所谓的“原型”（根据定义应该从头开始重写！！！-）实际上正在“进化”成（通常是半生不熟的“测试版”），等等

即使在今天，我也为我的一位同事重新夺回这个概念的聪明尝试鼓掌，即使这个词是一场失败的战斗：他正在为开发小型项目的概念证明建立一种方式（并且，如果这个概念确实得到证明，转移给软件工程师进行真正的原型设计，然后进行开发）。

这个想法是，在我们部门，我们有很多人不是（而且实际上不应该是！-）软件开发人员，但他们非常聪明，精通计算机，并且每天都与现实接触“在战壕”——他们最有可能嗅到一些潜在创新的机会，一旦实施为“生产就绪”软件项目，这些创新可能会产生真正的影响。销售人员、客户经理、业务分析师、技术经理——在我们公司，他们通常都符合这种描述。

但他们不会用 C++ 编程，几乎根本不会用 Java，也许用 Python，但离“生产化”还很远——事实上，他们更有可能在 php、javascript、perl 中创建一个智能的概念证明、bash、Excel+VBA 和其他各种“快速而肮脏”的技术，我们甚至都不想梦想永远生产和支持！-)

因此，通过将他们的原型称为“概念证明”，我们希望鼓励他们以具体的形式体现他们大胆的概念（含糊不清的自然语言喋喋不休和大量挥手是最没有用处的，而且无论如何都与公司的文化格格不入；-）和但尖锐地表明，如果将此类项目提升为存在于软件工程师的目标和优先事项中，则必须从头开始进行编程——概念验证充其量只能作为一个很好的草稿/草图规范来满足工程师的目标绝对不是逐渐丰富，而是从根本上重做！-)。

现在说这个想法的效果还为时过早——在三个月后问我，当我们评估本季度的努力时（现在，我们只是为他们提供蓝图，紧接着评估上一季度的部门和公司——明智的承诺！-)。

Answer 3

编写原型，然后不断重构它，直到它成为产品。关键是在必要时毫不犹豫地重构。

最初很少有人参与它会有所帮助。由于有太多人在做某事，重构变得更加困难。

Answer 4

来自 BUNDALLAH、HAMISI 的回应

原型通常只模拟最终程序功能的几个方面，并且可能与最终实现完全不同。与我其他同事在上面的建议相反，我不建议我的老板选择扔掉的原型模型。我和安妮塔在这方面。鉴于两种原型模型和提供的情况，我强烈建议管理层（我的老板）选择进化原型模型。公司很大，所有其他变量都给定了，例如代码的复杂性，要​​使用的编程语言的新颖性，我不会使用丢弃原型模型。丢弃的原型模型成为用户可以重新审视他们的期望并阐明他们的需求的起点。当这已经实现时，原型模型是' 扔掉”，然后根据确定的要求正式开发系统（Crinnion，1991）。但是在这种情况下，由于在这种特定情况下给出的因素的复杂性，用户可能不会一次知道所有的需求。进化原型是通过逐渐完善的过程来开发计算机系统的过程。系统的每个改进都包含一个系统规范和软件开发阶段。与传统的瀑布方法和增量原型不同，后者要求每个人在第一次就做好一切，这种方法允许参与者反思从前一个周期中吸取的经验教训。通常会经历三个这样的逐渐完善的循环。然而，没有什么能阻止不断进化的过程，这在许多系统中经常出现。根据戴维斯（1992）的说法，进化原型承认我们并不理解所有需求（正如我们在上面被告知的那样，系统很复杂，公司很大，代码很复杂，而且语言对于编程团队）。使用进化原型的主要目标是以结构化的方式构建一个非常健壮的原型并不断改进它。这样做的原因是，进化原型在构建时构成了新系统的核心，并且将构建改进和进一步的要求。这种技术允许开发团队添加功能，或进行在需求和设计阶段无法设想的更改。一个有用的系统，它必须通过在其预期的操作环境中使用而发展。产品永远不会“完成”；它总是随着使用环境的变化而成熟。开发人员经常尝试使用他们最熟悉的参考框架来定义系统——他们当前所处的位置（或者更确切地说，当前系统状态）。他们对开展业务的方式以及实施业务的技术基础做出假设。制定计划以开发能力，并且迟早会交付类似于预想系统的东西。（最高人民法院，1997 年）。进化原型比一次性原型的优势在于它们是功能系统。尽管它们可能没有用户计划的所有功能，但它们可以在最终系统交付之前临时使用。在进化原型中，开发人员可以专注于开发他们理解的系统部分，而不是致力于开发整个系统。为了最大程度地降低风险，开发人员不会实现人们知之甚少的功能。部分系统被发送到客户站点。当用户使用系统时，他们会发现新功能的机会，并向开发人员提出对这些功能的请求。然后，开发人员将这些增强请求连同他们自己的请求一起使用，并使用完善的配置管理实践来更改软件需求规范、更新设计、重新编码和重新测试。（贝尔索夫和戴维斯，1991 年）。然而，进化原型的主要问题是由于管理不善：缺乏明确的里程碑，缺乏成就 - 总是将当前原型中的内容推迟到下一个原型中，缺乏适当的评估，原型和已实施的系统之间缺乏明确性，用户缺乏持续的承诺。与传统要求相比，此过程需要用户在更长的时间内做出更大程度的持续承诺。用户必须不断了解正在发生的事情，并完全了解“原型”的期望。

参考

Bersoff, E., Davis, A. (1991)。软件配置管理生命周期模型的影响。通讯。ACM。

Crinnion, J. (1991)。进化系统开发，在结构化系统方法中使用原型的实用指南。全会出版社，纽约。

戴维斯，A. (1992)。操作原型：一种新的开发方法。IEEE 软件。

软件生产力联盟 (SPC)。(1997)。进化的快速发展。SPC 文件 SPC-97057-CMC，版本 01.00.04。