如何进行软件反刍管理?(茹海燕)

  作者:茹海燕
2003/6/30 14:28:30
本文关键字:
软件反刍管理,即项目事后回顾(PPR),指通过正规的项目回顾管理来获得经验教训,以利于将来项目发展。PPR在知识密集型行业中十分盛行,它在项目的螺旋式成长过程中,就像是一个休息亭,给项目以总结和重新思考的机会,从已经完成的项目中汲取尽量多的经验,为今后的发展提供积累。

但是在很多项目中,反刍管理还没有得到很好的执行,一方面是因为各方面的压力迫使项目管理越来越倾向于“走捷径”,能省略的步骤就省略;另一方面,就是成功的反刍管理的案例没有得到推广和示范,一部分人对此不以为然。以下针对本人在项目管理中的经验,提供一个软件开发反刍管理的报告模板。

我们首先需要确定,PPR回顾的是什么?项目的所有方面,都可以回顾。从管理,协调,技术创新,故障处理,计划等等,当然也包括项目成员的个人总结。所以我认为PPR可以分为两个大类:项目总结,和个体总结。

一、个体总结

个体总结,可以采用PSP(个体软件过程)的模式,模板如文后的附录。

从附录的表格可见,PSP总结突出的是时间管理和故障管理,当然也可以根据项目具体特色,设计总结的条目。例如,我们认为除了这些数据,研发人员还有一些自己思考的事情,如技术创新,也需要总结,还可以按照自己喜欢的任意格式,提交个人总结报告。我们还提供项目论坛,大家可以发表个人看法,或者刊登个人的总结,以便加强交流。

二、项目总结

以下是我制定的软件项目开发总结报告模板,它目前列举的是从计划、协调、质量和其他四个方面进行回顾总结。

 

XX项目开发总结报告

1.概述

1.1编写目的

< 编写者可以照抄下列语句,说明《开发总结报告》的编写目的,也可以适当修改。

“编写本《开发总结报告》的目的在于对××××软件项目开发过程进行总结,对遇到的困难和解决办法进行反思和总结,为以后软件的改进提供建议,为产品质量改进提供参考。”>

1.2 XX开发环境介绍

<逐项列出相关的项目及其关系。

A与B项目相关,是属于后者的一个子系统开发,因此制定的计划是后者计划的一部分,同样进度也会受后者的制约。

又如A是基于XX平台的一个子系统,因此他的稳定性和性能受后者制约;由于在此平台上已经开发了×个子系统通过性能样机评审,×个子系统通过设计定型(转产),×个子系统通过实验局和正式开局,所以一些通用模块经过考验,在稳定性和性能等方面有长足改进,也给本子系统的开发减少了风险、难度和工作量。>

1.3参考资料

< 列出相关的文档资料。

如系统设计方案,研制规范,历次测试报告(用于后面分析故障时举例)。>

2.计划总结

2.1开发计划与实践描述

< 简要介绍本软件系统的开发过程,主要是列出原定计划和实际进度。>

开发阶段

计划开始时间

计划结束时间

实际开始时间

实际结束时间

系统设计

 

 

 

 

详细设计

 

 

 

 

性能样机测试

 

 

 

 

转产

 

 

 

 

2.2进度总结

描述:

原因:

改善建议:

3与相关项目协调总结

3.1与相关项目协调描述

< 总体描述:开发过程中与相关项目协调、合作的情况,是良好,还是有待改进。>

3.2协调情况详细分析

< 说明各个具体协调情景。>

协调情景

开发影响

详细描述

原因

改进建议

 

正向

 

 

 

 

负向

 

 

 

 

 

 

 

 

4.测试故障总结

4.1故障数分布描述

< 记录历次正式测试的故障数,并总结故障分布是否呈现良好的收敛特性。>

测试

A类故障数

B类故障数

C类故障数

D类故障数

总计

系统测试一

 

 

 

 

 

系统测试二

 

 

 

 

 

系统测试三

 

 

 

 

 

验证测试一

 

 

 

 

 

总结:

4.2开发故障详细分析

< 在此对历次正式测试的故障进行分类分析,重要在于提出解决方案,为后续开发提供参考。

其中“故障类别”是对一类故障的命名,如通用模块代码不完全通用。

“解决方案”与“防范手段”的区别在于,前者提出根除的方法,后者提供前者如果作不到的情形下,如何尽早发现、定位、修复故障的手段,如对通用模块的功能进行遍历自测。

“数目”是此类故障在故障历次测试中出现的总频度。

“举例”是此类故障在某个测试报告中的详细描述位置,便于查阅。>

故障类别

原因分析

解决方案

防范手段

数目

举例

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

5.开发过程总结

< 总结其他方法和经验,为今后的系统设计、开发工作提出建议。如开发人员流动较大,而且交接工作仓促,导致系统质量收到影响;或者开发人员不足,导致自测不够充分等等。>

PPR是为了总结项目在发展中暴露的不足之初,期望今后得到改善;当然PPR实践本身也需要经常回顾、总结和提高。而且,需要强调的是,PPR虽然是项目结束之前的最后一项工作,但是它的准备工作一直贯穿者这个项目周期,所有人员都要用心用脑工作和思考,才能不断挖掘和进步。

PSP的个体项目计划总结表。

PSP项目计划总结表

人员: 日期:

程序号:

总结

计划

实际

累计

Minutes/LOC

 

 

 

LOC/Hour

 

 

 

Defects/KLOC

 

 

 

过程效益

 

 

 

A/FR

 

 

 

程序规模(LOC

 

 

 

新开发的与更改的

 

 

 

最大规模

 

 

 

最小规模

 

 

 

开发阶段时间/min

计划

实际

累计

累计百分比

计划

 

 

 

 

设计

 

 

 

 

编码

 

 

 

 

代码复查

 

 

 

 

编译

 

 

 

 

测试

 

 

 

 

后置处理

 

 

 

 

总计

 

 

 

 

最大时间

 

 

 

 

最小时间

 

 

 

 

引入的缺陷

计划

实际

累计

累计百分比

Def/Hour

计划

 

 

 

 

 

设计

 

 

 

 

 

编码

 

 

 

 

 

代码复查

 

 

 

 

 

编译

 

 

 

 

 

测试

 

 

 

 

 

总计

 

 

 

 

 

排除的缺陷

计划

实际

累计

累计百分比

Def/Hour

计划

 

 

 

 

 

设计

 

 

 

 

 

编码

 

 

 

 

 

代码复查

 

 

 

 

 

编译

 

 

 

 

 

测试

 

 

 

 

 

总计

 

 

 

 

 

本文由作者向AMT提供

作者联系方式:ru.haiyan@mail.zte.com.cn

责编:茹海燕
vsharing微信扫一扫实时了解行业动态
portalart微信扫一扫分享本文给好友

著作权声明:畅享网文章著作权分属畅享网、网友和合作伙伴,部分非原创文章作者信息可能有所缺失,如需补充或修改请与我们联系,工作人员会在1个工作日内配合处理。
畅享
首页
返回
顶部
×
    信息化规划
    IT总包
    供应商选型
    IT监理
    开发维护外包
    评估维权
客服电话
400-698-9918