软件过程，TSP，RUP和XP

首先是RUP，RUP有什么特点呢？迭代性开发，用例驱动，使用UML对软件建模，提倡事先设计好以组件为核心的体系结构(以体系结构为中心)，不断的评估和测试软件质量，（使用用例）控制软件的变化。在这些原则的基础上，把软件人员分成各种角色(分析，开发，管理，测试，工具支持，配置)等等，在软件开发过程中的各种产品叫做工件(Artifact)。

再看TSP，TSP把人员分成小组领导者、开发经理、计划经理、质量／生产经理，以及技术支持经理(注意这点和RUP的雷同）,要求各个人员严格记录在软件开发过程中的每一步，比如程序的Bug率，使用的时间等等。

最后一个是XP，XP的特点，双人编程，简单用例(User Story)，Refactoring，以周为基础的迭代。持续集成，现场客户，测试驱动，自动化测试，代码同步。同样的，XP也把人员分成测试，交流人员，设计师，技术作者，客户，程序员等等。

OK，说了这么多长篇大论，是为了把几个软件过程拿出来比较。所有的软件过程无非是为了避免风险，保证项目的成功。

拿交通工具做比方的话，TSP就好比坐火车，由于TSP是CMM那帮子人搞的，所以TSP不强调迭代性开发。TSP强调的是质量管理和控制，通过每个人自觉自愿的记录每天的行为，从而的得到严格的项目的数据，缺乏了这种严格控制，TSP就好比火车没有轨道，一点用处也没有。而在我们实验室一帮懒懒散散的学生中搞数据，要他们每天填表，从而知道项目消耗了多少人时，Bug率为多少，不要做梦了吧，所以TSP那套方式肯定是行不通的。

再看XP和RUP的差别，迭代性开发，两者都强调，不过两者的含义不同，在RUP中，每次迭代，强调产生的是一个个工件，比如完成了用例。而在XP中，产生的是可用的软件。为什么RUP的迭代里面可能没有产生可用的软件呢？因为RUP强调的是用例驱动和体系结构为中心，所以RUP花在设计体系结构和用例上的时间会比较多，这样带来的好处是软件的后期变更会比较少。而XP本身强调的是拥抱变化，不管三七二十一，先开发出来一个能用的再说，如果客户不满意（别忘了，XP是现场客户），Refactoring之。所以在XP的开头的时候，根本就不提倡太复杂的用例（客户在现场嘛，不懂客户的意思，现场交流啊），也不提倡过多的设计（测试驱动嘛，通不过的话Refactoring之）。

然而RUP没有现场客户的概念，所以清晰的用例描述是RUP中很重要的一环。只有这些用例在客户和团队之间达成了共识，才能做下一步的工作，同样的，需求的变更也必须通过用例来体现，RUP很强调变更管理，就是这个意思。
   

而在我们实验室做现在这个项目，不是和客户交流的问题，而是没有客户！！！
   

所以，在这种程度下，我们的用例，不是要让客户理解，而是我们自己理解就足够了。而体系结构，由于你们现在不用考虑分布式，并发，事务等等一系列东西。这些东西都由J2EE做了。
   

此外RUP在我们实验室很难办的一件事情是对各个阶段产生的工件的质量监控，同学们互相哈哈哈，很难对一个文档性的东西进行评价。
   

那么要改善我们现在做的项目，最重要的是做什么呢？第一是，小迭代，我们现在整个软件开发周期太长了，应该缩短到2－6周以内。第二，测试，我们现在的测试很多都是手动的，需要自动化这个测试过程。第三是，快速构建，持续集成。整个软件的部署周期不能像现在这么长，不能由同学们手工构建，而必须是自动化的部署。这些都是在XP中强调的。
   

RUP的不同就好比是做BUS和自己开小汽车的不同，尽管细微，但是，开小汽车更需要小心翼翼的调整方向，而公交车毕竟有线路。
   

如果在一个大公司做部门经理的话，我更愿意采用RUP那套方式，辅之于XP的各种实践，然而在实验室，我只有退而求其次，因地制宜，XP能推广多少是多少，一些很难推广的东西比如风险管理，BUG管理只能暂时放弃了

文章来源于领测软件测试网 https://www.ltesting.net/