技术开发 频道

软件过程的改进计划

    优势:

    . 该公司是大型企业的专有开发公司,业务客户稳定,项目市场风险小。不需要考虑市场推广及销售策略。
    . 公司的组织架构较灵活,可以整个公司作为一个开发团队开发大型项目。也可以从各组中抽调部分组员进行临时组队开发小型模块。这样对于用户变化多端的需求可以并行进行处理提高效率。
    . 公司的内部组织分工、职责比较明确。适合进行过程改进。
    . 公司使用的技术及存储产品比较主流,可以支持大、中、小各种类型项目。
    . 公司已经有使用过程支持工具,并且有版本管理工具,需求变更追踪管理。
    . 公司具备一批精通零售行业业务知识的需求、开发、测试人员,同时也具备多名开发经验超过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.实施过程改进

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

    2.3.2.软件过程评估

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

    3.总结

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

0
相关文章