软件过程改进短论

软件过程改进

中小型企业软件过程改进之我见

——软件过程改进课程短论

软件工程0806 言凌峰 U200817915

引言：

通过本课程的学习，让我们对软件行业过程管理的重要性有了全新的认识，真正认识到软件项目与简单意义上的集体编程的区别，同时也看到了当前软件行业过程管理仍旧处于较为无序的状态，这次恰以中小型企业为目标对这一类初生企业的过程管理作简要分析与思考。

正文：

首先目标锁定为国内的中小型企业，通过线上搜集资料也分析，可以得出我国所谓的中小型企业的特征，如下：

人员少，一般在20人>150人之间。流动性很大，企业的组织结构不像大企业那样健全，经常是一人多职，既做开发人员，又做测试人员，甚至还作设计人员。

资金不足，难以进行企业级的大规模的过程改进以及相关的培训活动。

软件过程不明显，甚至没有明确定义的软件过程。一个项目甚至整个企业是以少数技术骨干为支撑，凭借他们的聪明才智来保证项目的顺利进行和企业的生存发展。开发人员一般对技术比较重视，而对软件过程则表现出不关心。

企业从事的软件生产呈现明显的领域特征。中小软件企业经常是给特定用户开发为其专门使用的软件产品或承接大的软件企业的子项目，而且这些软件产品和项目常集中于某一领域，因此在该领域企业往往积累了较丰富的开发经验和技术。

在得出以上特征后，发现这样的情况就是课上所谓的缺乏过程管理的典型，往往这样的企业CMMI认证很难超过3级。针对国内企业这种症状，业内已经有了对症所下的药，称为SPP理论。SPP(Simplified Parallel Process)，“精简并行过程”是对CMMI3级以内各过程域的内容和要求做了“精简”处理而创作出一种“软件过程改进方法和规范”。它由众多的过程规范和文档模板组成，主要用于指导国内软件企业进行软件过程能力的持续地改进。CMMI主要论述“应当做什么才能使软件过程能力达到CMMI某种等级”，而SPP则论述“应当怎样做才能使软件过程能力达到CMMI3级水平”。

SPP这一套模板就相当与贴在麦当劳厕所上的“MUSTDO”一样，写得规规矩矩明明白白，然而这一套繁琐的规则明细能否直接有效地将中小型企业送上CMMI3呢？答案其实是未经证实的，因为很少由企业一笔一划地去按照模板做，第一，企业对过程管理重视程度不够；第二，企业在不能确定理论有效地情况下不会规规矩矩的实行这种硬条例；第三,即便真的有企业按照SPP做了，取得了成绩，我们没有对其改进的过程跟踪记录，也就对其效果不得而知了。所以在多种因素的作用下，理论上看似摆脱混乱的过程管理只需吹灰之力，然而实际上理论永远在学术界发展，中小型企业依旧沉溺在混乱中。。。。。。

再来看看“面向国内软件企业软件过程改进框架（SPIF）”，SPIF中的KPA分别是需求管理、需求开发、系统设计、代码实现与测试、项目策划、项目监督与控制、立项管理、结项管理、度量与分析、过程与产品质量保证、配置管理，本框架结合了中小型软件企业的特点，具有较强的针对性。我们重点看看“项目监督和控制过程域”：

项目监督和控制过程域——为了保证软件系统在预期的工作量内按时保质的完成，需要定期地对其主要项目进行跟踪、监测和调整，跟踪的对象通常有规模、工作量和成本、计算

软件过程改进

机资源、进度、风险和软件工程技术活动等。其目的是通过周期性的跟踪项目计划的各种参数，不断了解项目的进展情况，以便当项目实际进展状况明显偏离计划时能够及时适当地采取纠正措施。

这一作用域相对来讲是所有KPA中效果最为明显的作用域，其实也是最初的最迫切需要解决的问题。我们看到“十一罗汉”在出发前做出了一个相当周密相当细致的计划。对于成本，工作量，分工，进度，风险等都做了详细部署，在这一作用域上，整个项目的成功才站得住脚，我们可以设想，在这样的计划之后，这群人可以作总结、分析、改进然后实现第二次“壮举”，而且应该是更快、更多、更安全的。当然，这只是说笑，不过类比软件过程改进，是比较恰当的。我们不一定要求中小型企业能够迅速全面达到CMMI的高级水平而不走弯路，显然这是不大现实的，但是在项目监督和控制过程域上花功夫，努力强迫自己多做计划，多做风险规避等等总是最有效最直接的。

由于研究时间有限，只能对主题有一个大概的认识然后择片面做讨论，未有深入分析请见谅。