A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation. Contrary to what my other colleagues have suggested above, I would NOT advise my boss to opt for the throw away prototype model. I am with Anita on this. Given the two prototype models and the circumstances provided, I would strongly advise the management (my boss) to opt for the evolutionary prototype model. The company being large with all the other variables given such as the complexity of the code, the newness of the programming language to be used, I would not use throw away prototype model. The throw away prototype model becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements (Crinnion, 1991). But with this situation, the users may not know all the requirements at once due to the complexity of the factors given in this particular situation. Evolutionary prototyping is the process of developing a computer system by a process of gradual refinement. Each refinement of the system contains a system specification and software development phase. In contrast to both the traditional waterfall approach and incremental prototyping, which required everyone to get everything right the first time this approach allows participants to reflect on lessons learned from the previous cycle(s). It is usual to go through three such cycles of gradual refinement. However there is nothing stopping a process of continual evolution which is often the case in many systems. According to Davis (1992), an evolutionary prototyping acknowledges that we do not understand all the requirements (as we have been told above that the system is complex, the company is large, the code will be complex, and the language is fairly new to the programming team). The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built. This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase. For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment change. Developers often try to define a system using their most familiar frame of reference--where they are currently (or rather, the current system status). They make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered. (SPC, 1997). Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered. In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system. To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest. (Bersoff and Davis, 1991). However, the main problems with evolutionary prototyping are due to poor management: Lack of defined milestones, lack of achievement - always putting off what would be in the present prototype until the next one, lack of proper evaluation, lack of clarity between a prototype and an implemented system, lack of continued commitment from users. This process requires a greater degree of sustained commitment from users for a longer time span than traditionally required. Users must be constantly informed as to what is going on and be completely aware of the expectations of the 'prototypes'.
References
Bersoff, E., Davis, A. (1991). Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM.
Crinnion, J.(1991). Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York.
Davis, A. (1992). Operational Prototyping: A new Development Approach. IEEE Software.
A prototype should always be a throwaway - a prototype is used to quickly prove a concept and influence the design of the real product. As such, a lot of things which are important for a real product (a thought-out architecture and design, reliability, security, maintainability, etc.) fall by the wayside. If you do take these things into account when building your prototype, you're not really building a prototype anymore.
My experience with prototypes where the code directly evolved into an actual product shows that the end-result suffers because of it - the lack of a real architecture resulted in a lot of cobbled-together code that had to be constantly hacked to add new features. I've even seen a case the original technology chosen for rapid development of the prototype was not the best choice for the actual product, and a complete re-write was necessary for V2.
I think we, the pedants, have lost this particular battle -- alleged "prototypes" (which by definition should be rewritten from scratch!!!-) are in fact being "evolved" into (often half-baked "betas"), etc.
Even today, I've applauded at the smart attempt by a colleague of mine to recapture the concept, even if the term is a lost battle: he's setting up a way for proofs of concept small projects to be developed (and, if the concept does get proven, transferred to software engineers for real prototyping, then development).
The idea is that, in our department, we have many people who aren't (and aren't in fact supposed to be!-) software developers, but are very smart, computer savvy, and in daily contact with the reality "in the trenches" -- they are the ones who are most likely to smell an opportunity for some potential innovation which could have real impact once implemented as a "production-ready" software project. Salespeople, account managers, business analysts, technology managers -- at our company, they all often fit this description.
But they're NOT going to program in C++, hardly at all in Java, maybe in Python but miles away from "productionized" -- indeed they're far more likely to whip up a smart proof of concept in php, javascript, perl, bash, Excel+VBA, and sundry other "quick and dirty" technologies we don't even want to dream about productionizing and supporting forevermore!-)
So by calling their prototypes "proofs of concept", we hope to encourage them to embody their daring concepts in concrete form (vague natural-language blabberings and much waving of hands being least useful, and alien to the company's culture anyway;-) and yet sharply indicate that such projects, if promoted to exist among the software engineers' goals and priorities, DO have to be programmed from scratch -- the proof-of-concept serves, at best, as a good draft/sketch spec for what the engineers are aiming for, definitely NOT to be incrementally enriched, but redone from the root up!-).
It's early to say how well this idea works -- ask me in three months, when we evaluate the quarter's endeavors (right now, we're just providing a blueprint for them, hot on the heels of evaluating last quarter's department- and company-wise undertakings!-).
发布评论
评论（4）
BUNDALLAH、HAMISI 的回应
原型通常仅模拟最终程序功能的几个方面，并且可能与最终实现完全不同。
与我其他同事上面的建议相反，我不会建议我的老板选择扔掉的原型模型。 我同意安妮塔的观点。 鉴于这两个原型模型和所提供的情况，我强烈建议管理层（我的老板）选择进化原型模型。 公司规模很大，考虑到所有其他变量，例如代码的复杂性、要使用的编程语言的新颖性，我不会使用丢弃原型模型。 废弃的原型模型成为用户可以重新审视他们的期望并澄清他们的需求的起点。 当这一点实现后，原型模型将被“丢弃”，系统将根据已确定的需求进行正式开发（Crinnion，1991）。 但在这种情况下，由于这种特定情况下给出的因素的复杂性，用户可能无法立即知道所有需求。 进化原型是通过逐步完善的过程开发计算机系统的过程。 系统的每个细化都包含系统规范和软件开发阶段。 与传统的瀑布方法和增量原型法相反，传统的瀑布方法和增量原型法要求每个人第一次就把所有事情都做对，这种方法允许参与者反思从上一个周期中吸取的经验教训。 通常要经历三个这样的逐渐完善的循环。 然而，没有什么可以阻止持续进化的过程，这在许多系统中都是常见的情况。 根据 Davis (1992) 的说法，进化原型承认我们不理解所有的需求（正如我们上面所说的那样，系统很复杂，公司很大，代码很复杂，而且语言对于编程团队）。 使用进化原型的主要目标是以结构化方式构建非常强大的原型并不断完善它。 原因是进化原型在构建后就形成了新系统的核心，并且将构建改进和进一步的要求。 这种技术允许开发团队添加功能，或进行在需求和设计阶段无法设想的更改。 为了使系统有用，它必须通过在其预期操作环境中的使用而不断发展。 产品永远不会“完成”； 它总是随着使用环境的变化而不断成熟。 开发人员经常尝试使用他们最熟悉的参考框架——他们当前所在的位置（或者更确切地说，当前的系统状态）来定义系统。 他们对业务的开展方式以及业务实施的技术基础做出假设。 制定计划来开发该功能，并且迟早会交付类似于设想系统的东西。 （国家质检总局，1997）。
进化原型比一次性原型有一个优势，因为它们是功能系统。 尽管它们可能不具有用户计划的所有功能，但它们可以临时使用，直到最终系统交付。
在进化原型中，开发人员可以专注于开发他们理解的系统部分，而不是致力于开发整个系统。 为了最大限度地降低风险，开发人员不会实现人们不太了解的功能。 部分系统被发送到客户现场。 当用户使用系统时，他们会发现新功能的机会并向开发人员提出对这些功能的请求。 然后，开发人员将这些增强请求与他们自己的请求一起使用，并使用合理的配置管理实践来更改软件需求规范、更新设计、重新编码和重新测试。 （贝尔索夫和戴维斯，1991）。
然而，演化原型的主要问题是由于管理不善造成的：缺乏明确的里程碑、缺乏成就——总是将当前原型中的内容推迟到下一个原型、缺乏适当的评估、原型与原型之间缺乏清晰度。一个已实施的系统，缺乏用户的持续承诺。 这一过程需要用户在比传统要求更长的时间内做出更大程度的持续承诺。 用户必须不断了解正在发生的事情，并完全了解“原型”的期望。
参考文献
Bersoff, E., Davis, A. (1991)。 软件配置管理生命周期模型的影响。 通讯。 ACM。
克里宁，J.(1991)。 进化系统开发，在结构化系统方法中使用原型的实用指南。 全会出版社，纽约。
戴维斯，A.（1992）。 操作原型：一种新的开发方法。 IEEE 软件。
软件生产力联盟 (SPC)。 （1997）。 进化的快速发展。 SPC 文档 SPC-97057-CMC，版本 01.00.04。
Response from BUNDALLAH, HAMISI
A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.
Contrary to what my other colleagues have suggested above, I would NOT advise my boss to opt for the throw away prototype model. I am with Anita on this. Given the two prototype models and the circumstances provided, I would strongly advise the management (my boss) to opt for the evolutionary prototype model. The company being large with all the other variables given such as the complexity of the code, the newness of the programming language to be used, I would not use throw away prototype model. The throw away prototype model becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is 'thrown away', and the system is formally developed based on the identified requirements (Crinnion, 1991). But with this situation, the users may not know all the requirements at once due to the complexity of the factors given in this particular situation. Evolutionary prototyping is the process of developing a computer system by a process of gradual refinement. Each refinement of the system contains a system specification and software development phase. In contrast to both the traditional waterfall approach and incremental prototyping, which required everyone to get everything right the first time this approach allows participants to reflect on lessons learned from the previous cycle(s). It is usual to go through three such cycles of gradual refinement. However there is nothing stopping a process of continual evolution which is often the case in many systems. According to Davis (1992), an evolutionary prototyping acknowledges that we do not understand all the requirements (as we have been told above that the system is complex, the company is large, the code will be complex, and the language is fairly new to the programming team). The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built. This technique allows the development team to add features, or make changes that couldn't be conceived during the requirements and design phase. For a system to be useful, it must evolve through use in its intended operational environment. A product is never "done;" it is always maturing as the usage environment change. Developers often try to define a system using their most familiar frame of reference--where they are currently (or rather, the current system status). They make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered. (SPC, 1997).
Evolutionary Prototypes have an advantage over Throwaway Prototypes in that they are functional systems. Although they may not have all the features the users have planned, they may be used on an interim basis until the final system is delivered.
In Evolutionary Prototyping, developers can focus themselves to develop parts of the system that they understand instead of working on developing a whole system. To minimize risk, the developer does not implement poorly understood features. The partial system is sent to customer sites. As users work with the system, they detect opportunities for new features and give requests for these features to developers. Developers then take these enhancement requests along with their own and use sound configuration-management practices to change the software-requirements specification, update the design, recode and retest. (Bersoff and Davis, 1991).
However, the main problems with evolutionary prototyping are due to poor management: Lack of defined milestones, lack of achievement - always putting off what would be in the present prototype until the next one, lack of proper evaluation, lack of clarity between a prototype and an implemented system, lack of continued commitment from users. This process requires a greater degree of sustained commitment from users for a longer time span than traditionally required. Users must be constantly informed as to what is going on and be completely aware of the expectations of the 'prototypes'.
References
Bersoff, E., Davis, A. (1991). Impacts of Life Cycle Models of Software Configuration Management. Comm. ACM.
Crinnion, J.(1991). Evolutionary Systems Development, a practical guide to the use of prototyping within a structured systems methodology. Plenum Press, New York.
Davis, A. (1992). Operational Prototyping: A new Development Approach. IEEE Software.
Software Productivity Consortium (SPC). (1997). Evolutionary Rapid Development. SPC document SPC-97057-CMC, version 01.00.04.
原型应该始终是一次性的 - 原型用于快速证明概念并影响实际产品的设计。 因此，对于真正的产品来说，很多重要的东西（深思熟虑的架构和设计、可靠性、安全性、可维护性等）都被搁置了。 如果您在构建原型时确实考虑了这些因素，那么您就不再是真正构建原型了。
我对原型的经验表明，代码直接演变成实际产品，最终结果会因此而受到影响 - 缺乏真正的架构导致大量拼凑在一起的代码，必须不断地修改这些代码才能添加新功能。 我什至见过这样的案例：最初为快速开发原型而选择的技术对于实际产品来说并不是最佳选择，V2需要完全重写。
A prototype should always be a throwaway - a prototype is used to quickly prove a concept and influence the design of the real product. As such, a lot of things which are important for a real product (a thought-out architecture and design, reliability, security, maintainability, etc.) fall by the wayside. If you do take these things into account when building your prototype, you're not really building a prototype anymore.
My experience with prototypes where the code directly evolved into an actual product shows that the end-result suffers because of it - the lack of a real architecture resulted in a lot of cobbled-together code that had to be constantly hacked to add new features. I've even seen a case the original technology chosen for rapid development of the prototype was not the best choice for the actual product, and a complete re-write was necessary for V2.
我认为我们这些学究们已经输掉了这场特殊的战斗——所谓的“原型”（根据定义应该从头开始重写！！！-）实际上正在“进化”成（通常是一半） -baked“betas”）等。
即使在今天，我仍然对我的一位同事重新夺回这个概念的明智尝试表示赞赏，即使这个术语是一场失败的战斗：他正在建立一个开发小型项目的概念验证方式（如果概念确实得到验证，则转移给软件工程师进行真正的原型设计，然后进行开发）。
我们的想法是，在我们部门，我们有很多人不是（实际上不应该！-）软件开发人员，但他们非常聪明，精通计算机，并且擅长每天与“战壕中”的现实接触——他们最有可能嗅到一些潜在创新机会，一旦作为“生产就绪”软件实施，这些创新可能会产生真正的影响项目。 在我们公司，销售人员、客户经理、业务分析师、技术经理，他们通常都符合这种描述。
但他们不会用 C++ 编程，几乎不会用 Java，也许用 Python，但离“生产化”还很远——事实上，他们更有可能用 php、javascript、perl 提出一个智能的概念证明。 、bash、Excel+VBA 以及其他各种“快速而肮脏”的技术，我们甚至不想梦想永远实现生产和支持！-）
因此，通过将它们的原型称为“概念证明”，我们希望鼓励他们以具体的形式体现他们大胆的概念（含糊的自然语言喋喋不休和大量挥手是最没有用的，而且与公司的文化格格不入；-），但尖锐地表明，如果推广这些项目，它们的存在在软件工程师的目标和优先事项中，必须从头开始编程——概念验证充其量只是作为工程师目标的良好草案/草图规范，绝对不是逐步丰富的，但从根本上重做！-)。
现在说这个想法效果如何还为时过早 - 请在三个月后问我，当我们评估本季度的努力时（现在，我们只是为他们提供一个蓝图，紧接着评估最后 季度部门和公司的工作！-)。
I think we, the pedants, have lost this particular battle -- alleged "prototypes" (which by definition should be rewritten from scratch!!!-) are in fact being "evolved" into (often half-baked "betas"), etc.
Even today, I've applauded at the smart attempt by a colleague of mine to recapture the concept, even if the term is a lost battle: he's setting up a way for proofs of concept small projects to be developed (and, if the concept does get proven, transferred to software engineers for real prototyping, then development).
The idea is that, in our department, we have many people who aren't (and aren't in fact supposed to be!-) software developers, but are very smart, computer savvy, and in daily contact with the reality "in the trenches" -- they are the ones who are most likely to smell an opportunity for some potential innovation which could have real impact once implemented as a "production-ready" software project. Salespeople, account managers, business analysts, technology managers -- at our company, they all often fit this description.
But they're NOT going to program in C++, hardly at all in Java, maybe in Python but miles away from "productionized" -- indeed they're far more likely to whip up a smart proof of concept in php, javascript, perl, bash, Excel+VBA, and sundry other "quick and dirty" technologies we don't even want to dream about productionizing and supporting forevermore!-)
So by calling their prototypes "proofs of concept", we hope to encourage them to embody their daring concepts in concrete form (vague natural-language blabberings and much waving of hands being least useful, and alien to the company's culture anyway;-) and yet sharply indicate that such projects, if promoted to exist among the software engineers' goals and priorities, DO have to be programmed from scratch -- the proof-of-concept serves, at best, as a good draft/sketch spec for what the engineers are aiming for, definitely NOT to be incrementally enriched, but redone from the root up!-).
It's early to say how well this idea works -- ask me in three months, when we evaluate the quarter's endeavors (right now, we're just providing a blueprint for them, hot on the heels of evaluating last quarter's department- and company-wise undertakings!-).
编写原型，然后不断重构它，直到它成为产品。
关键是在必要时要毫不犹豫地进行重构。
最初只有很少的人参与这件事是有帮助的。 当太多人致力于某件事时，重构就会变得更加困难。
Write the prototype, then keep refactoring it until it becomes the product.
The key is to not hesitate to refactor when necessary.
It helps to have few people working on it initially. With too many people working on something, refactoring becomes more difficult.