软件过程改进实践

摘要：通过结合自身在企业中参与的一些项目的经验，根据软件过程的一些方法论，如RUP，XP等来分析所参与的一些项目中的过程现状，制定出一些过程的改进计划。并且阐述一下如何实施和评估整个软件过程改进。

 

关键字：软件过程、过程改进、RUP、评估

 

1：软件过程思想

1．1：什么是过程

   过程的定义很多书上都给出了不同的答案。可能是这些给出的定义所关注的方向不同，因此会忽视一些其他方面，造成很难给过程一个明确的定义。在这里引用一个比较全面的定义来阐述过程。“过程事实上有三方面的特性：首先，过程应被定义，因此过程的第一个方面就是过程的定义，通常是将过程所包含的活动及程序文档化；第二，应将关于过程的知识传授给需要执行过程的每一个人，所以第二个方面就是过程的学习。也就是说应让过程的知识深入到每个过程执行者的头脑中去，并以此驱动他们的行为与活动；就像产品的形成是经过一系列的工序处理后的结果一样，通过执行过程中的活动才能获得最终的过程结果，这就是过程的第三方面。”***[引用自《软件过程改进 Sami Zahran著》第一章 1.2.2 ]

   

其实简单的理解，过程的定义可以描述为：什么人正在做什么事情，什么时候去完成这件事，并且如何去完成这件事的一个特定目标。

 

1．2：软件过程

1．2．1：软件过程定义

软件过程广义来将就是指：不仅仅包括软件开发和管理的过程，并且还包括软件合同的管理，软件维护，软件支持及整个软件组织的管理等的全部活动。而狭义的软件过程则指：软件开发过程，包括软件开发过程中的全部活动：需求分析，设计，编码，测试。这些过程可以是增量的交替的开发，或者可以采用迭代的开发。

我们这里所要讨论的软件过程可以定义为：对软件开发过程的管理，软件生命周期的管理与工程化过程支持的规范说明。而此软件过程的使用者为公司的软件工程师和项目经理，最终的结果就是软件程序，系统及文档。

 

1．2．2：为何要使用高效的软件过程

什么是高效的、好的软件过程？要回答这个问题，我们就必须说一说低效的、差的软件过程有些什么症状。

对于一些企业可能存在着如下的问题：

1.         软件开发过程中执行的任务比较模糊。开发项目组中成员的职责说明不明确。文档不完善，无指导意义。

2.         软件开发过程的执行缺乏监控，无法保证与企业管理目标的一致。开发项目中的每个成员喜欢用自己的过程去完成开发，极大的削弱了团队的能力。

3.         整个企业崇尚技术为主，认为只要技术高了就能提高开发效益。极大忽略了过程的管理。

4.         缺乏软件开发过程的规范化文档，进来的新人无法得到规范的指导和培训。

5.         企业原本有自己的一套规范的软件过程，但时间久了缺乏改进，也不花精力去研究新的过程，造成旧过程逐渐失效。同时这样的过程也失去了对新技术和新趋势的支持。

6.         上级领导只关心结果，不重视过程的使用和管理。整个企业的运作环境也无法支持过程的使用或改进，造成过程成为企业的负担，无法和企业目标相一致。

以上这些问题都是低效的软件过程的一些特征，低效的软件过程可能拖慢企业的开发效率，同时也无法很好的支持企业的运作，无法给企业带来更多的效益。

在理解了一些低效过程的特点后，就更加肯定了软件企业必须有个高效的软件过程支持才能为企业本身带来更多的效益，也能更快的提高项目的开发效率，保证项目的质量。因为对于软件开发项目来说，在整个开发生命周期中能保证有一个高效的过程机制去支持开发，那对于整个项目的管理是很重要的。高效的过程能够让企业的开发项目组的职责明确化，便于管理。过程目标与企业目标一致，这样可以对项目成员实行激励。高效的过程结果是规范的制度，规范的文档。这些都可以很方便的运用到对新进员工的培训中去，使新成员能更快的融入到项目组中，提高团队合作能力。

 

1．3：小结

一个好的软件过程只有被定义、培训、遵守、职责明确、有足够的支持去执行才能成为真正有效的过程。

软件过程不仅仅是我们所看到的一堆文档，这些文档所包含的内容才是真正的过程产品。通过这些规范的文档可以有效的，快速的指导整个软件开发，给项目管理一个指导性的大纲。在有了正确的管理，高效的开发过程后才能为企业和组织带来更多，更快的效益。

 

2．软件过程实践

    下面就一个开发零售百货业ERP项目的公司作为例子来研究一下软件过程的实践，包括分析企业开发过程的现状，制定改进计划，实施和评估。

2．1．分析企业现有软件过程的现状

2．1．1．业务分析及企业背景

²        这个开发零售百货业ERP系统的公司是一个由35人组成的小型企业，是隶属于某大型卖场的开发团队。

²        拥有一批对零售业务具备多年经验的需求，开发和测试人员。

²        公司内部组织分成四个独立项目组：需求组、开发组、测试组、系统组。

²        各个项目组职责明确。

²        使用J2EE架构，JAVA、JSP语言进行WEB页面开发。

²        使用SYBASE数据库/数据仓库产品进行数据存储及处理，可支持大数据量。

²        在开发过程中使用CVS、Bugzilla Bug追踪系统及自主研发的更新工具支持项目开发。

²        行业领域比较专业，有很多公式、业务规则、合同规则来指导开发工作。

²        具有稳定的客户群，分布全国都有客户分店，但是零售业客户的需求不断变化、新需求层出不穷。

²        整个软件产品对客户的管理工作起到决定性作用。客户的订单、进退货、财务、付款、合同等管理流程全部需要由软件来完成，因此直接关系到客户的经济效益。

²        软件质量和开发效率极其重要，直接影响公司的命运。

²        已经有成功发布并运行正常的软件产品。

 

2．1．2．项目风险分析

²        客户需求不断变化，给开发过程的进度控制带来很大困难

²        业务范围广、流程复杂、专业程度高（例如财务方面的业务分析及建模），需要具备一定的行业知识。

²        客户的数据安全性、完整性、可靠性、正确性需要得到百分百保证。

²        系统分为总部和全国各分店系统，需要通过网络交换数据，网络安全需要考虑。

²        服务器访问量大，需要硬件支持。

 

2．1．3．内部环境

²        内部组织结构

l         公司内部分成四个项目组：需求组、开发组、测试组、系统组。

根据开发的模块大小从需求组、开发组、测试组抽调部分组员组成模块开发小组。

系统组负责环境架设、程序更新等工作。

l         公司拥有一批业务经验、行业知识丰富的人员。

l         公司拥有多名开发经验超过5年的开发人员。

²        开发过程

l         使用比较传统的开发过程：需求分析—》设计开发—》系统测试—》发布新版本。

l         基本类似于瀑布式开发过程，其中会使用些增量式开发。

l         测试方面依据业务流程做黑盒测试，主要依靠业务经验来测试产品，无自动测试工具。

l         需求阶段有详细的需求文档作为开发依据，

l         开发过程中没有规范的设计文档，很多情况下仅仅是根据需求文档直接做开发。

l         有些设计文档是开发项目结束后才补写的。

l         没有固定去做测试计划，有时仅仅是开发完成后就开始分工测试。

l         有做测试案例但没有固定的规范约束，测试案例交由开发和需求人员确认。

l         有BUG系统追踪需求变更及BUG处理情况，但无系统的测试报告给开发人员参考，大部分情况下是口头和开发/需求人员沟通BUG的问题点。

 

²        支持工具

l         WINCVS

l         Bugzilla Bug追踪系统

l         自主研发的更新工具

2．1．4．产品特点

²        项目比较庞大，一般拆分成模块进行开发。一个模块的开发人员为3~5人左右。

²        项目开发完成的软件是作为商业应用的一个ERP系统，包括零售百货业的所有流程管理、物流管理、财务管理等。

软件的使用周期一般可以在10~20年，维护周期长，需要有高可靠性的质量保证。涉及到有很多商业及财务数据需要保存，安全性很重要。访问用户比较多，响应速度要快。

²        技术复杂程度参差不齐，有些模块比较简单技术要求不高，有些模块比较复杂，需要不断更新新技术。总体来说由于对于行业的业务分析要求严谨，又是使用比较新的开发技术，所以技术复杂程度和管理程度相对都要高一点。下图给出了一个技术与管理程度的比较：

²        Technical vs. Management Complexity

   

2．1．5．分析总结

通过以上四节对该公司的一个现状分析可以得出以下一些结论。

优势：

²        该公司是大型企业的专有开发公司，业务客户稳定，项目市场风险小。不需要考虑市场推广及销售策略。

²        公司的组织架构较灵活，可以整个公司作为一个开发团队开发大型项目。也可以从各组中抽调部分组员进行临时组队开发小型模块。这样对于用户变化多端的需求可以并行进行处理提高效率。

²        公司的内部组织分工、职责比较明确。适合进行过程改进。

²        公司使用的技术及存储产品比较主流，可以支持大、中、小各种类型项目。

²        公司已经有使用过程支持工具，并且有版本管理工具，需求变更追踪管理。

²        公司具备一批精通零售行业业务知识的需求、开发、测试人员，同时也具备多名开发经验超过5年的开发人员。

²        需求文档比较完善。

²        有成功发布并使用正常的软件产品。

 

问题点：

²        客户新需求量大、需求变化快。

²        开发过程比较落后，没有使用较先进的方法论进行改进或支持。

²        没有专门的过程实施、监控小组。没有过程专家。

²        无详细的设计文档，或是仅仅在开发完成后补写设计文档。

²        测试方面仅仅依靠测试人员的业务经验进行测试，无相关方法论的支持，没有使用专业的自动化测试工具。

²        没有明确的测试计划来管理整个测试过程。

²        测试报告不全面，没有固定格式，不能指导开发人员修改BUG。

²        Stakeholders方面存在一些需要关注的地方：业务范围广、流程复杂、专业程度高（例如财务方面的业务分析及建模），需要具备一定的行业知识。客户的数据安全性、完整性、可靠性、正确性需要得到百分百保证。系统分为总部和全国各分店系统，需要通过网络交换数据，网络安全需要考虑。

 

2．2．制定过程改进计划

2．2．1．过程改进的可行性

根据上述分析总结所列出的优势，可以得出此次软件过程改进还是可以得到执行的：

²        企业背景和业务方面有很大优势要加以利用，同时最好能说服集团公司的上层领导，告诉他们软件过程的改进可以大大提高项目的开发进度，降低开发成本，这样比较容易争取领导层对软件过程改进的支持。

²        企业的内部组织结构分工、职责比较明确，并且具备一定的灵活性。对于引入RUP的方法论进行开发过程的改进有一定可行性。

²        企业技术能力比较突出，善于接受新技术，相信开发人员对于新过程、新方法的引入不会有抵触情绪。

²        企业原本就已经使用了很多支持工具，这样有利于支持新过程的改进。

²        企业可以选取比较次要的模块作为先导项目进行过程改进的实验。

 

2．2．2．过程改进的建议

通过上述一些问题点和优势的总结，提出以下一些过程改进的建议：

²        以提高软件质量、开发效率、降低开发成本为基础说服领导层支持过程改进。保证组织外部环境对过程改进的支持。

²        成立过程改进小组，对这个企业的开发人员进行过程方法论的培训。

²        利用过程改进小组对整个开发过程进行监控，使项目经理能把重心放在控制开发进度、降低开发风险等重要事件上。

²        在开发阶段采用RUP方法论进行指导。可以对RUP的文档进行剪裁，选用适合自身项目的文档应用到开发过程中。并且使用迭代的开发方法替代原先的瀑布式开发。

²        保留原由需求文档的编写方法。

²        利用业务知识丰富的需求人员与客户沟通，务求需求的正确性和一致性。

²        客户需求量大，变化快，必须完善需求变更系统。要设定需求基线，同时引入迭代的开发方法。这样可以在最短的时间内完成最重要的需求开发。

²        规范设计文档的编写方法，可以利用RUP中的模版进行规范化。培训开发人员要有先编写设计文档后再编码的概念，编写的设计文档必须由项目经理确认。

²        对测试人员进行测试方法论的培训，使其能利用诸如等价划分法、边界值分析法等对系统进行测试。并且能很清楚的知道测试各个阶段的工作内容。

²        编写测试计划，而且必须在需求分析进行的同时编写，在需求完成后测试计划就该完成，随着开发的进行可以有所改动。

²        测试案例必须编写，并且由项目经理进行评估审查。测试案例可以在需求阶段或着开发阶段编写。

²        规范测试报告的编写格式，测试完成后每个测试员必须编写规范的测试报告，以利于开发人员修改BUG。

²        引进自动化的测试工具对性能、压力等测试务求作到自动化测试。

²        继续使用CVS，Bugzilla等支持工具，将版本控制、需求变更、BUG追踪自动化。

²        选取一个先导项目进行实验，成功后逐步推行到整个企业的软件开发过程。

 

2．2．3．过程改进计划

²        成立过程改进小组即软件工程过程组（SEPG），派专人负责整个过程改进。

²        根据背景及业务分析、项目分析、内部因素、产品特点进行现有软件过程的评估。

²        根据评估给出详细的软件过程改进建议。

²        根据软件过程改进建议转化为行动。整个行动由过程改进小组SEPG负责监控、跟踪。

²        实施软件过程改进，并同时密切监控改进过程。有问题立刻解决。

²        对实施的过程改进进行评估。

²        对成功实施的软件过程制度化。

 

2．3．实施和评估过程改进

2．3．1．实施过程改进

²        为实施软件过程改进分配职责

l         实施负责人：得到最高管理层的支持和信任，策划整个过程改进活动。

l         实施改进组：这里就从公司内部选取具备软件过程理论的开发人员组成SEPG小组。并请专门的过程专家对其进行培训。

l         软件过程改进组：负责先导项目的开发、实施，作为整个公司软件过程改进的先驱小组。

²        制订行动计划，确定过程改进后应该达到的预期目标。

²        启动软件过程改进。

²        实现先导项目的过程改进。

²        进行先导项目的过程改进的评估，如果达到预期的目标、取得收益，那么将持续地进行过程改进直到推广到整个公司的项目。如果未达到预期的目标，就先终止过程改进。进行问题的寻找并解决出现的问题。

²        将最终改进后的新过程制度化，过程结果文档化。

 

2．3．2．软件过程评估

过程的评估并不是过程的结束，而是整个软件过程的开始。通过正确的评估，可以对比出过程改进的前后整个开发过程有什么质的飞跃、可以度量收益、确定是否达到预期效果。这样的评估对整个软件过程的改进是起着指导作用的。评估报告可以让上级领导随时掌握软件过程改进的进度并且掌握过程改进所带给企业的收益和效果。

 

3．总结

综上所述，结合了自身企业的一些优缺点大致阐述了软件过程改进的一个实践步骤和方法。由于在实际中并没有做到实施阶段，因此在最后的实施和评估过程改进方面写的不够全面。希望通过这篇小文章能对自己学到的一些软件过程及度量知识有个总结和运用，为以后真正有机会实施过程改进打下基础。

最后感谢这段时间上海交通大学 沈备军 教授为我们带来的《软件过程与度量》的精彩课程。使我们在方法论上有了新的提高、新的进步。

 

参考文献：

u       《软件过程与度量》课程讲义 上海交通大学 沈备军 教授 编写。

u       《软件过程改进》 机械工业出版社 Sami Zahran著 陈新 罗劲枫等译。

u       《Rational Unifed Process 2003》文档  IBM。

u       《Rational 统一过程引论》机械工业出版社 Philippe Kruchten 著。