软件原型法是一种减少软件项目失败风险的技术，它可以减少需求错误和用户界面的缺陷，缩短开发进度，增加用户的满意程度，保证最终产品的质量。然而，原型法又引入了自身的风险。
＊ 最大的风险是用户看到一个正在运行的原型便以为产品即将完成，他们会要求不再进行产品重建，而只是对原型进行一些修改就交付。由于原型没有考虑软件的总体质量和可维护性，交付原型往往造成"欲速则不达"的情况。
＊ 开发人员为了快速构造原型，可能会采用不合适的操作系统或程序设计语言，也可能使用一些效率低的算法。在一段时间的开发之后，他们往往已经习惯了这些选择，于是便在系统中参杂了这些不理想的选择。
　　处理风险承担者的期望是成功原型法的一个关键因素，因此要保证那些见到原型的人理解为什么要建立原型并且怎样建立原型，并且决不能把抛弃型原型当作可交付的产品。为了在需求开发过程中建立有效的原型，可以如下原则：
＊ 在项目计划中包括原型风险，安排好开发、评价和可能的修改原型的时间。
＊ 尽快并且廉价地建立抛弃式原型。用最少的投资开发那些用于回答问题和解决需求的不确定性的原型，不要努力去完善一个抛弃式原型的用户界面。
＊ 对于已经理解的需求不要建立原型。
＊ 不能随意地增加功能。当一个简单的抛弃式原型达到原型目的时，就不应该随便扩充它的功能。
＊ 不要从原型的性能推测最终产品的性能。原型可能没有运行在最终产品所处的特定环境中，并且你开发原型的工具与开发产品的工具在效率上是存在差异的。
＊ 在原型屏幕显示和报表中使用合理的模拟数据，那些评价原型的用户会受不现实数据的影响而不能把原型看成真正产品的模型。
＊ 不要期望原型可以代替需求文档。原型只是暗示了许多后台功能，因此必须把这些功能写入软件需求规格说明，使之完善和详细。

　　建立软件原型的目的是为了降低软件项目的风险，但这种方法本身有产生了新的风险。当用户看到正在运行的原型时，往往会错误地认为产品很快能完成，他们会说："这看起来真不错，希望继续把它做完交付。"如果你正在演示或评价一个抛弃型原型，无论它与真正的产品是多么相像，也决不会达到产品的使用程度。因此，减少这种风险的关键在于让人们明白原型"是什么"和"为什么"，并且充分认识到交付原型"后患无穷"。