软件过程的改进计划(下)

 

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．实施过程改进

• 为实施软件过程改进分配职责
  • 实施负责人：得到最高管理层的支持和信任，策划整个过程改进活动。
  • 实施改进组：这里就从公司内部选取具备软件过程理论的开发人员组成SEPG小组。并请专门的过程专家对其进行培训。
  • 软件过程改进组：负责先导项目的开发、实施，作为整个公司软件过程改进的先驱小组。
• 制订行动计划，确定过程改进后应该达到的预期目标。
• 启动软件过程改进。
• 实现先导项目的过程改进。
• 进行先导项目的过程改进的评估，如果达到预期的目标、取得收益，那么将持续地进行过程改进直到推广到整个公司的项目。如果未达到预期的目标，就先终止过程改进。进行问题的寻找并解决出现的问题。
• 将最终改进后的新过程制度化，过程结果文档化。

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

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

3．总结

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