原型开发的第一阶段有多普遍？

在过去的几个学期中，我一直在学习一些软件设计课程，尽管我看到了很多形式化的好处，但我觉得它并没有告诉我有关程序本身的任何信息：

• 即使它讨论了程序可以做什么，也无法从用例规范中看出程序将如何运行。
• 即使需求文档可能包含质量需求，您也无法从需求文档中得知任何有关用户体验的信息。
• 时序图很好地描述了软件如何作为调用堆栈工作，但是非常有限，并且可以从整体上高度了解整个系统。
• 类图非常适合描述系统的构建方式，但是对帮助您确定软件的功能却毫无用处。

底线到底在哪里：程序的外观，操作方式以及所提供的经验？从中进行设计不是更有意义吗？弄清楚程序应该如何通过原型工作并努力实现它，这不是更好吗？

我知道我可能正遭受理论家教授工程学的困扰，但是我需要问，他们在行业中这样做吗？人们如何弄清楚该程序实际上是什么，而不是应该遵循的程序？人们制作了很多原型，还是他们大多使用UML之类的正式工具，而我只是还没有掌握使用它们的习惯？

如果要构建GUI应用程序，我们几乎总是会创建原型或POC（概念验证）。我们将确定应用程序的视觉词汇。通常，我们会通过POC来让客户参与其中，并确保他们了解目的是什么以及应该关注的重点。我从来不后悔我生产了原型。只要确保您不尝试将原型代码转换为生产代码，就可以根据从原型中学到的知识从头开始生产代码。

说了这么多，我们几乎永远不会制作服务器端应用程序（服务，中间件等）的原型。我真的看不到这方面的投资回报率（除非您正在使用某种新技术并且需要证明不同的概念）。

在商业世界中，这很重要

在您触及商业世界之前，我也常常认为。然后，它不再足够简单以仅接受需求并继续构建。

用户使用“流程图”图和lo-fi原型在业务上确实有意义。

“程序”的操作方式可能很容易。在LOB（业务线）应用程序中，大多数只是CRUD。该挑战在于业务逻辑和规则。在这里，用户流程图和业务流程非常重要，以便有效地理解和计划。

程序如何“运行”是什么意思？您似乎在寻找除特定最终实现以外的确切实现细节，这没有任何意义。较高级别的元素应该指导实现，而不是确定实现。

根据我的经验，原型制作很少见。我当然被教导结合了规范，需求，体系结构等，并且它可能非常有用。

至于“软件需要什么”，那就是要求。您似乎错过了整点。

接口通常是事先勾勒出来的，用例可用于接口“流程”。完全没有用户体验。如果您觉得缺少某些内容，请做您的教授没有提到的其他事情。设计并不包含从天堂传下来的清晰规则。

我个人的观察是，原型设计得到了很多口红，但是一旦原型出现了生命迹象，它们通常会被简单地重命名为“ Beta”，甚至更糟的是v1.0。

原型有两种-实际上是三种：

1. 我们建立原型以完善设计并降低风险，然后再开始“实际”编码（工程）

2. 我们将项目构建为一系列精致的原型（敏捷）

3. 我们会建立原型并在可行时尽快发货（Cowboy）

您正在寻找的被称为规格-您可以在Joel的一篇文章中阅读其说明。

http://www.joelonsoftware.com/articles/fog0000000035.html

原型也可以视为您需要做的“迭代0”。它完成了几件事：

• 证明了这个概念是可以做到的。这可能是您的老板或付费客户的。
• 它使您可以识别可能难以提高生产能力的事物，并大致了解所需的工作量。
• 您实际上有执行某些操作的代码。这非常重要！

总之，除非您发现有必要采用完全不同的方法，否则所有原型都应很有可能用于构建最终产品。