UML软件工程组织

实施基于SW-CMM 软件过程改进前的常见问题解答——评估范围方面
问天
 

1)Q:我们将来需要什么样的项目参加评估比较合适?

A:这必须慎重,否则可能会对评估结果、实施效果及企业获益影响很大。原则上说,CMM 2级评估没有对试点项目做出什么特别的要求。一般只要是生命周期比较完整,项目组成员人数在5~10人,周期在3~6个月的项目均可,当然这也不是一定的。

对于很多企业来说,通常会有两类项目,即自主研发的产品类项目和基于客户具体需求的工程类项目。究竟使用哪类项目进行试点,是很多企业决策者争论和考虑的地方。这两类项目在作为试点项目方面各自的优势在于:

显然,产品类项目风险比较小,可控度比较高;然而,工程类项目往往是最容易管理混乱的。因此,把工程类项目作为试点项目企业收益会更高。有一家公司就曾经怀着尝试的态度在两个金融领域的工程类项目中进行CMM试点,这两个项目的客户都是银行相关业务科室的人员。令他们非常意外的是,当他们告诉客户正在做CMM改进时,客户显示出了非常浓厚的兴趣。对于参加需求规格说明书评审会这样的CMM建议的活动,他们也积极配合;质量保证方面,客户还专门派了一个人配合。到了项目验收的时候,客户在验收单上签字的工作比他们历次任何一个项目都顺利,因为客户在项目开发的整个过程中很清楚地了解项目的进展和问题,并且对于项目的结果有很强的信心。这家公司的高层经理,也因为客户满意度非常高而认识到了过程改进的好处,并决心加大这方面投入的力度。相反,有些公司为了减少过程改进的实施难度,用产品研发类项目作试点,结果现在大家抱怨因为管理产生的工作量太多了而产生抵触情绪,反而影响了实施效果。

我们一般还建议选择生命周期比较完整的项目作试点,这是因为:在CMM 2级的配置管理KPA中,有些要求是关于测试和产品构建的,如果没有一个试点项目在评估的时候能够进入集成测试或者产品发布这样的产品开发后期阶段,就有可能因为找不到评估证据而被主任评估师要求延期评估。所以,如果一家企业选择了多个项目作为试点的话,可以不必所有的项目都能够非常完整的到达后期阶段,有1~2个项目即可。

对于试点项目的规模,特别是人数,应注意这样一个问题:如果一个企业希望在整个公司内实施CMM并进行评估的话,那么每个和软件开发、维护相关的部门都应有半数以上的人参与试点项目。对于不打算在整个公司范围实施的企业,大量实际情况表明,5~10人规模的中小项目在实施效果和难度方面都是值得推荐的。

目前对于大多数国内的软件开发项目来说,还是3~6个月的最多。为期6个月的项目刚好可以满足6个月的过程稳定期,在这个基础上时间长点、短点问题都不大。至于说项目开发地点是否在公司本地,其实影响不大。而项目经理是否能够认同过程改进的价值,高层经理能否真正保证项目组有足够的资源来实施新的过程,也应是此时考虑的一个重点问题。

(2)Q:既然CMM2级是项目级别的,我们用一个规模很小的项目去实施过程改进,并参加评估,岂不是很容易?

A:选择小规模的项目作为试点在理论上是可以的,因为SEI并没有规定这样做不允许,但我们强烈建议大家不要这样去做。规模小的项目沟通方便、风险小,是否需要按照CMM的要求和建议去管理应该根据具体情况去分析。如果一个1、2个人月工作量的项目要花费大量精力去形成管理文档,会让人觉得是一种罪恶。曾经有一家公司,希望在该公司一个部门实施CMM,但该部门绝大多数项目都是基于一个已经很成熟的核心产品,只需根据客户定制的一部分额外需求进行开发,因此开发工作量很小。而对于该部门来说,在客户现场将老系统切换成为新系统,并保证新系统能够稳定运行倒是非常重要。虽然这方面的工作每次只需要一、二人,二周时间就足够了,而且有关人员因为对这方面业务非常熟悉,项目失败的风险并不大,项目组也不会留下什么文档,但他们希望能够通过过程改进加强这类项目的管理,减少人员流动为该部门带来的损失。但是,这个公司定义出来的过程文档主要是用于开发类型的项目,而他们又没有足够的数据对过程进行分析和裁剪,结果造成几乎管理工作量比工程活动工作量还要多,项目组有关人员均对这套过程表示了怀疑,并开始对过程改进活动产生抵触情绪。

关于试点项目的数量,一般来说1个是不够的。有的主任评估师认为CMM 2级的特点是repeatable,即可重复的,就需要一套成文的过程应该在至少2个项目中使用。如果一个项目规模很大(100人以上),周期很长(2年以上),通常被拆分成若干个子项目进行开发,并且能够充分的体现实施CMM的有关证据,那么可以允许仅有1个项目参加评估。如果是一般规模或规模较小的项目,一定是不允许的。

规模小、数量少确实可减少实施难度,但企业如为了真正实现商业目标,通过改进获益,他们是不会这样做的。

(3)Q:我们可不可以只在公司下面的某一个部门实施CMM,以便减少实施的难度?

A:可以,因为CMM 中反复使用的是“组织”一词,它既可以代表一家完整的公司,也可以代表一家公司下面的一个或多个部门。因此,即使在评估CMM 5 级的时候,也可以只对某家公司的某一个部门进行。CMM 2级是面向项目级别的,实施的时候这方面灵活性更大。不过在主任评估师向SEI 提交评估结果时会明确写明评估的时候是在企业的什么范围内进行的(多少个部门纳入了评估的范围,大约参与的软件开发人员和管理人员的数量等)。现在很多企业向媒体宣传的时候,有意无意的掩盖了这一点,只是泛泛地说:XXX 公司已经达到了CMM 2 级的要求,久而久之造成了很多错误的认识。不过,如果企业希望通过过 程改进真正获益的话,最好还是能够在整个企业中所有与软件活动有关的的部门都实施过程改进。

虽然2 级是面向项目级别的,但我们非常欢迎和支持在整个公司的范围内实施CMM 2级,无论这些部门的软件项目是开发类的、实施或维护类的,也不论这些项目是面向客户的工程类的、还是面向市场的产品类的。这样,公司积累大量不同类型项目的宝贵经验,在将来向3 级迈进的时候,充分利用这些经验可以把3 级的实施落在实处,得到更加广泛的认同。

我个人认为,如果一家公司希望能够成为CMM 3 级的公司的话,如果在2 级的阶段投入比较多,实施的效果比较好,那么3 级的实施难度会下降很多;反之,如果2 级阶段投入较少,实施范围小、效果不是很好的话,3 级的实施难度会增加;因此可以说,一个公司在从1 级到3 级这个过程中所投入的资源(人员、时间、资金等)总数基本上是一个固定值。既然如此,为什么不早一点把工作做到实处,早一点获得成效呢?

 

 

版权所有:UML软件工程组织