软件测试与可靠性评估方法研究

　　3）便于发现问题，及时纠正；

　　4）便于进一步展开，并取得用户的细节需求；　

　　5）体现原型的其它功能：便于公司内部如经理、市场部等对软件提出意见，便于开发人员对整个产品达成统一认识，等等。对内部人员来说，同样地，一套形象的原型也远胜过一堆专业术语文字；也就是说，原型对软件公司内部也十分重要。这些评价工作无形之中改进了项目质量。

　　5.3 原型方法有什么风险？

　　任何方法都是有利有弊，在我们可以探讨一下原型方法可能存在的风险。以下是一般软件公司所担心的风险：需要付出前期进度和人力成本；由于程序员对问题的不了解而效率低下，受客户牵制而在原型上反复修改；因为仓促设计而做不利于进一步在其基础上继续开发；由于过早展示原型给客户，使得客户可能提高其期望值，并提出更多离谱的要求，等等。

　　值得一提的是原型方法的主要价值之一就是尽早揭示软件中可能存在的风险及不确定因素，尤其是关于用户需求一致性方面的风险。

　　5.4 原型方法和其它方法或过程的关系如何，是否一致？

　　生命周期法中并不包括原型，或者说没有明确提供原型的概念和定义。原型可以认为是需求分析中的一个子部分。另外，应该说原型方法是对生命周期法的有益补充和完善。

　　RUP中是最优化的统一软件过程，但RUP中似乎没有提到原型，RUP的核心过程是在迭代中精化。我个人的见解是，原型非常类似于第一次迭代的过程和结果。实际上，如果把原型看作为第一轮交付的成果，那么原型的很多不利之处，诸如花费前期成本等等，这些担心都将变得不复存在。

　　XP方法对原型非常推崇，这是因为XP方法非常强调需求的重要性，甚至要求客户参与开发过程。但原型方法和XP也有区别。XP是分批交付，先做一个几个功能点的版本，完成后再每个开发周期往上面加其它功能点，而原型法一般要求做出比较完整，能覆盖主要功能点的粗略的版本。XP方法仁者见仁，智者见智，不一而举。

　　5.5 如何避免项目团队做原型的时候出现部分人员闲置？

　　在项目管理中，对人力资源的调配应和项目进展相匹配。实际上在用户接触到原型制作的同时，可以进行项目计划、架构设计、技术培训以及技术难点攻关等等。

　　如果从广义上理解原型的话，架构设计者甚至可以设计出一种用户开发团队使用的所谓框架原型，包含了主要的设计成分、模板和示例。

　　比较理想的结果是，当原型完成后，需求分析、架构设计和界面风格设计都趋于完成，从这一点可以看到，原型方法可以作为快速软件开发的重要手段。

　　5.6 如果避免项目在原型上停滞不前？

　　应使用有经验的开发人员，避免因为程序员不熟悉业务而延误进度；不要在界面设计上犹豫不决而占据时间；如果用户对原型提出了很多意见，其中部分比较明确的意见可以在开发过程中进行实现；和客户的交流应该简洁明了，而不是似是而非；另外，原型方法在项目过程中占据的时间应该在项目计划中保留出来，而不仅仅是隐含在需求调研与分析的一个部分。

　　5.7 如何避免用户看了原型后漫无边际地提要求？

　　首先，应该充分尊重客户，想想其它行业的服务质量吧。有没有听说过这样的说法，项目管理也是客户满意度的管理；软件是一种对客户的关怀，等等。确实，客户提出的思路可能和你已经形成的思路不同，一下子打乱了你的思路，也许项目经理并不介意，但这确是让设计者特别心烦的事情。如果确有把握，或者你可以不做到原型中去。有时候，即使原型很完美，用户也会额外地提出一些意见，这也是人之常情。但不管怎样，你不能认为用户根本不懂软件，让他们到时用就行了，抱这样想法的多半会付出代价。

　　其次应该进行坦诚协商，多数用户其实都是通情达理的。如果你在签订合同时答应满足任何要求，而此时又无法忍受用户的要求，那么孰是孰非应是题外之意了。一般来说，比较合理的做法可以通过增加费用、延长进度或者把需求实现分阶段来提交，以保持工作的延续性。对有些软件，尤其是信息管理系统来说，客户的实施时间其实并不是主要的，客户最需要的不是及时，而是合用。

　　其实，客户有着很多种类型，确实，个别客户会参考同类产品来提要求，极个别用户并不真正懂得计算机技术而对技术路线、技术手段等提出其意见，等等。但我们为什么还可以反过来想一下，如果是等到软件全部提交的时候，这部分用户仍有会提出同样的意见。提早暴露并解决分歧，对双方睹是有利的。如果软件公司明知可能存在矛盾，仍然先做好，然后等到用户提出反对后，再提出补充收费，如果喜欢，也无话可说。

上一页  [1] [2] [3] [4] [5] [6] 下一页

【责编:Luzi】