CMMI3学习之路

  • 格式:doc
  • 大小:256.00 KB
  • 文档页数:12

从今年年初,公司一直在作CMMI3的认证,刚开始接触了她一下,只看见了她那繁杂的文档目录结构。

My God!简直不敢相信。

由于工作的需要,公司给我们做了多次关于CMMI3认证的培训。

对于CMMI3的整体的培训就有3次。

第一次应该算是介绍性的了解。

当时只是觉得:这东西好复杂,就象一团乱麻,听得我居然睡着了。

第二次以培训的性质听,突然感觉对她有了一个零零碎碎地了解。

但是到了第三次,我突然感觉到她竟是如此美丽。

于是决定把每一次的了解记录下来。

正文:一个项目的开发应该叫一个活动。

这个活动中存在着很多的环节。

现在回想起我原来的工作,往往是不能很好的处理这些重要的环节。

已导致了很多问题的发生。

而且为了解决这些问题常常是受累不讨好。

言归正传,来说说我学习到的东西。

首先,在一个软件项目开发活动中有几个步骤:在活动的进行中,不仅有这些活动,为了更好的完成这些活动还有“监督控制”、“配置管理”、“质量保证”、“培训”、“评审”在时时地监控、支持、反馈项目中的各个阶段的状态。

下面就来一项一项的看看这些活动一、立项:立项分为三种情况:1、产品研发2、招投标3、用户合同这三种情况对应这三类项目:产品研发,是公司内部提起的,无固定客户的项目;招投标,是经过投标,中标的项目;用户合同,是用户找到你,让你去给他们做的项目。

在立项阶段,这三类项目有两种处理方式。

产品研发是一种,招投标和用户合同是一种。

首先来说说产品研发,研发的立项过程如下图:其中,对于立项的申请地提出可以是组织内部的任何人。

对于招投标的立项过程相对较简单一些,提交解决方案后,组织指派负责人,然后就可以立项了。

二、需求开发说明:1、需求开发首先要有需求开发的计划,在计划中包含:需要多少次的需求开发活动,每次以什么方式,由谁去做,每次活动需要那些客户参加。

2、然后就是需求调研,这种当中可以做一些Dome跟客户进行交流3、对于最后的需求培训应该是项目组中的所有成员参加,让所有的人了解将要做的东西是做什么的4、对于需求开发阶段,最后要提交(输出)“客户需求说明书”和“软件规格需求说明书”。

前者是要给客户看,并得到客户的确认。

这两个文档中有很多项目,但是应该是如下图的关系:三、项目策划再学习的过程中,我觉得策划阶段包含的内容是最多的,开始觉得有些乱,但是实际上各部分操作还是非常有序的结合在一起。

1、在策划的开始同样也要制定策划计划。

制定好计划后开始项目定义过程2、项目定义过程主要是根据项目本身的情况,对组织定义过程进行裁剪。

所谓组织定义过程是组织内的对于任何项目的统一的定义过程。

在项目定义过程中要裁剪掉不适合的部分,例如:组织过程中定义了对于成本的估计,由于组内员工的薪金待遇并不透明,所以这个部分是不可执行的,就要裁剪掉。

当然也可以在组织定义过程上进行扩展(自己定义),最终找到适合项目的过程。

3、运用生命周期模型,选择组织内部的生命周期模型,如:瀑布、迭代、增量等等。

也可以自己定义一个生命周期模型。

定义生命周期模型后,要进行WBS分解,也就是把大的项目分解成适合的模块或者任务。

分解的粒度应该注意,过大过小都不是好事。

这步是要为下面的估计做好铺垫。

分解分为:任务分解和产品分解两部分4、估计,按照分解的结构进行估计。

估计又分为:规模估计、工作量估计、进度估计、风险估计、共利者估计、人力资源估计等等1)估计并不是凭空想象,除了个人的经验,还要参考组织上的度量库。

组织度量库中记录了曾经作过的项目中的一些数据,如:bug率,每人平均日产代码量等等2)估计也是有一定的次序的:如下图首先进行规模的估计,根据规模估计结果进行工作量的估计,再根据工作量估计的结果进行进度的估计。

在这其中工作量=规模*生产率,生产率就要参考组织度量库中的数据。

3)对于进度估计有两种方式,一种是:自下而上,就是知道项目的截止日期,根据每个任务的工作量、投入人数和任务的先后次序往前估计,一个任务一个任务一直估计到这个项目应该何时开始。

第二种是:从上至下,就是知道何时启动,根据每个任务的工作量、投入人数和任务的先后次序往后估计。

直至算出项目的截止日期。

4)在估计中有一定的基本原则,但是在实际中存在人员在开发任务时地并行的问题,还有,对于客户要求的结束日期,项目内部应当提前这个日期完成。

根据实际情况要调整计算出的进度,使其合理化。

5)在多人估计时,会产生偏差,这是不可避免的。

但是如果偏差较大,应该是由于项目组对此任务的认识不一致。

此时,此次估计作废,重新了解这部分需求,重新估计。

6)人力资源估计:主要包含需要多少人,人员的能力、何时到位、人员的技术估计7)风险估计:主要包含技术和客户两个方面5、估计完成后要进行计划的制定,主要有这几个计划:1)(总的)项目计划:在几个计划中要最先完成,包括内容:人力资源、进度等等前面讲到的问题。

还要有同行评审的内容,如:如何进行同行评审,活动中进行几次同行评审,分别都在什么时候等等2)配置管理计划(CM):记录一些配置项和基线的建立3)质量保证计划(QA):制定过程中的评审、产品审计都是在何时进行4)测量分析计划:在项目中要有的度量,如:工作量问题、测试缺陷等等5)测试计划:单元测试、集成测试何时做,其中用到的测试用例都有哪些,这时定义的测试用例只是一个大概,在今后项目测试开始之前还会对此进行细化或修改。

6、计划制定后要进行组织评审,如果评审不通过,则要在有问题的环节上进行修改,如果通过,才能进入下一步项目的主体设计四、设计此时才到项目的设计,原来没有CMMI的时候,我们常常是对于用户需求有了一知半解,就开始做设计,结果就是事半功倍。

现在才知道原来在做设计前还要那么多的事情要做。

设计主要是要写总体的设计说明书,数据库设计等等。

如果对于系统的设计并非一个人去完成,还要进行设计培训。

设计完后就要开始进入编码阶段了。

五、编码编码没有什么太多说的,每天都在做。

只要按照组织或者个项目组自己定义的编码规范去做。

注意代码的逻辑性、高效性、健壮性,按照需求去做就可以了。

六、单元测试1、单元测试前首先要细化在策划阶段编写的测试计划中的测试用例2、每次测试都要做记录,主要包含:是如何测的,有哪些用例,出现了哪些问题,对所测模块的评价3、单元测试中的模块是否通过是有标准的,大部分是靠测试人员决定是否通过,如果测试人员不能决定,则需要项目经理决定七、测试(集成、系统)1、集成测试:主要验证模块间的接口是否通过(项目经理决定是否通过)2、系统测试:主要是不同环境的安装、压力、性能的测试八、试运行1、首先也要有试运行计划:包括时间,有些活动,有谁负责。

2、主要工作:部署安装,对用户进行培训,试运行,用户要进行反馈,对反馈中出现的意见提出处理结果。

3、需要用户参与或者模拟用户(模拟用户不能使开发组中的人员)。

试运行结束后就到了项目验收阶段九、验收交付验收分为:内部验收和外部验收1、首先要有验收计划,包括:内部验收和外部验收的时间、人数,验收小组负责人及相关文档2、内部验收为在组织内部作的验收,外部验收是与客户作的验收验收阶段结束进入结项阶段十、结项结项中要产生一些文档:项目总结、个人总结、项目统计结项之后,此次活动就因该说完成了以上就是一个项目活动的大体过程,但是在这个过程中还有一些一直贯穿于项目中的活动。

就像在正文开始中说的。

下面就来说说这些活动。

一、监督与控制1、主要包括周会、周报(个人、项目)2、周会上要做三件事:1)上周工作总结2)问题风险的识别:对于以前的风险进行重新的评估。

识别新的风险3)下周工作计划二、度量分析1、对于规模、工作量和进度的度量分析:分析中发现有偏差是允许的,但是如果偏差较大时,就要分析原因,分析偏差可能会给项目带来的影响,还有对此偏差的解决方案2、问题、缺陷:要注意发现总数和关闭率三、风险问题1、风险与问题的区别:风险是有可能发生,但问题是已经遇到了2、风险的估计有三个参数:影响程度、可能性和显露度3、对于风险的处理有两种:解决和规避4、当发现一个风险的时候,就要记录下来,并且,风险的状态应该是打开的。

5、对于风险的关闭有两种可能,一是:没有转化成问题;一是:转化成问题。

此时风险关闭要出《风险报告》6、当风险转化成问题后要出《问题报告》四、项目月报项目经理要定期填写月报乡领导汇报五、CM配置管理对于配置管理主要体现在开发库、受控库和代码库中1、开发库:在项目组中,主要是对项目组的文档进行管理,对于其中的文档项目组中的所有人员可以Read,但不能Update,CM可以Read&Update。

但是各自周报,每个人自己是可以Read&Update2、受控库:在项目组中,组织关心的配置项,最后形成的SetUp部署程序应该是由受控库中的代码生成。

受控库中变更要做版本升级,包括代码和文档。

如果受控库中的代码要做变更的话,也是有一套流程,不能随便想改就改,流程如下图:3、代码库:项目组内部的用于代码开发的六、QA:项目组中的QA并不是项目组成员,他主要是监督项目活动七、同行评审项目组内部的活动,不是组织上的。

在项目计划中要策划有哪些同行评审(如:代码评审、策划评审等等),多少次。

在评审前要提前发评审的内容与项目中发现的问题不同:同行评审中出现的问题是可以不解决的。

但是项目中的问题是必须解决的。

以上就是这次学习CMMI3的内容总结,感觉CMMI主要的作用是计划、监督和控制项目活动。

我觉得如果能够好好做的话应该可以控制项目活动中的每一个细节。

如果这些细节都能够很好的处理,那么我相信这样出来的软件才是可用的。

把看似好像杂乱无章的过程变得井井有条。

这就是我发现她的美丽之处。

/kid-li/archive/2006/11/23/570293.html。