很详细的CMMI文档.docx
- 文档编号:2167787
- 上传时间:2022-10-27
- 格式:DOCX
- 页数:11
- 大小:206.25KB
很详细的CMMI文档.docx
《很详细的CMMI文档.docx》由会员分享,可在线阅读,更多相关《很详细的CMMI文档.docx(11页珍藏版)》请在冰豆网上搜索。
很详细的CMMI文档
CMMI3学习之路
(一):
在质疑与挣扎中偶然发现她竟是如此美丽(转)
2009年08月30日星期日20:
07
序言:
记得在上大学的时候,学习过软件工程。
但是在当时只是感觉到十分的枯燥无味。
所以也从未好好听过。
现在到了工作中,常常为无休止的变更和不合理的工作安排而烦恼。
从今年年初,公司一直在作CMMI3的认证,刚开始接触了她一下,只看见了她那繁杂的文档目录结构。
MyGod!
简直不敢相信。
由于工作的需要,公司给我们做了多次关于CMMI3认证的培训。
对于CMMI3的整体的培训就有3次。
第一次应该算是介绍性的了解。
当时只是觉得:
这东西好复杂,就象一团乱麻,听得我居然睡着了。
第二次以培训的性质听,突然感觉对她有了一个零零碎碎地了解。
但是到了第三次,我突然感觉到她竟是如此美丽。
于是决定把每一次的了解记录下来。
正文:
一个项目的开发应该叫一个活动。
这个活动中存在着很多的环节。
现在回想起我原来的工作,往往是不能很好的处理这些重要的环节。
已导致了很多问题的发生。
而且为了解决这些问题常常是受累不讨好。
言归正传,来说说我学习到的东西。
首先,在一个软件项目开发活动中有几个步骤:
下面就来一项一项的看看这些活动
一、立项:
立项分为三种情况:
1、产品研发
2、招投标
3、用户合同
这三种情况对应这三类项目:
产品研发,是公司内部提起的,无固定客户的项目;招投标,是经过投标,中标的项目;用户合同,是用户找到你,让你去给他们做的项目。
在立项阶段,这三类项目有两种处理方式。
产品研发是一种,招投标和用户合同是一种。
首先来说说产品研发,研发的立项过程如下图:
其中,对于立项的申请地提出可以是组织内部的任何人。
对于招投标的立项过程相对较简单一些,提交解决方案后,组织指派负责人,然后就可以立项了。
二、需求开发
说明:
1、需求开发首先要有需求开发的计划,在计划中包含:
需要多少次的需求开发活动,每次以什么方式,由谁去做,每次活动需要那些客户参加。
2、然后就是需求调研,这种当中可以做一些Dome跟客户进行交流
3、对于最后的需求培训应该是项目组中的所有成员参加,让所有的人了解将要做的东西是做什么的
4、对于需求开发阶段,最后要提交(输出)“客户需求说明书”和“软件规格需求说明书”。
前者是要给客户看,并得到客户的确认。
这两个文档中有很多项目,但是应该是如下图的关系:
在活动的进行中,不仅有这些活动,为了更好的完成这些活动还有“监督控制”、“配置管理”、“质量保证”、“培训”、“评审”在时时地监控、支持、反馈项目中的各个阶段的状态。
CMMI3学习之路
(二):
在质疑与挣扎中偶然发现她竟是如此美丽(转)
2009年08月30日星期日20:
07
三、项目策划
再学习的过程中,我觉得策划阶段包含的内容是最多的,开始觉得有些乱,但是实际上各部分操作还是非常有序的结合在一起。
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&Update
2、受控库:
在项目组中,组织关心的配置项,最后形成的SetUp部署程序应该是由受控库中的代码生成。
受控库中变更要做版本升级,包括代码和文档。
如果受控库中的代码要做变更的话,也是有一套流程,不能随便想改就改,流程如下图:
3、代码库:
项目组内部的用于代码开发的
六、QA:
项目组中的QA并不是项目组成员,他主要是监督项目活动
七、同行评审
项目组内部的活动,不是组织上的。
在项目计划中要策划有哪些同行评审(如:
代码评审、策划评审等等),多少次。
在评审前要提前发评审的内容
与项目中发现的问题不同:
同行评审中出现的问题是可以不解决的。
但是项目中的问题是必须解决的。
以上就是这次学习CMMI3的内容总结,感觉CMMI主要的作用是计划、监督和控制项目活动。
我觉得如果能够好好做的话应该可以控制项目活动中的每一个细节。
如果这些细节都能够很好的处理,那么我相信这样出来的软件才是可用的。
把看似好像杂乱无章的过程变得井井有条。
这就是我发现她的美丽之处。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 详细 CMMI 文档