CMMI对于一个不太懂计算机的人来说难学吗
发布网友
发布时间:2022-05-21 15:53
我来回答
共3个回答
热心网友
时间:2023-11-23 06:14
2级其实有很多问题还没有解决的,细心的人会发现,2级对软件工程活动的指导很弱,如:需求开发、设计、编码、测试等。
如果说2级是项目级那么3级已经上升为组织级了。
从评估的角度看,2级将项目管理的工作做好了,当然还有MA了,2级的MA要求是不高的,也就基本可以满足2级要求了,所以,2级相对来说也比较简单,从目前国内的情况来看,目前企业选择过2级的不多,都基本直接过3级。
具体2级的体系文件详细描述见:http://www.chinaopi.com.cn/bbs/read.asp?vid=334
3级在评估过程是有难度的,18个PA,比2级就多不少,呵呵。我们一般对工程上的PA都比较熟悉,但是对组织级的PA可能有点理解上的困难。
组织过程焦点(Organizational Process Focus):这个PA要求组织成立EPG来推动过程改进的工作,要求识别、计划、实施改进过程,保证组织过程能持续改进。
组织过程定义(Organizational Process Definition):这个PA要求组织级建立财富库,财富库内容要包括标准的过程、裁剪库、度量库、生命周期模型等。
组织培训(Organizational Training):要求组织根据商业目标要求准备并提供培训。
很多3级的企业对这个3个PA,出来组织过程定义做了点之外,其他基本比较难做,基本还是在其他的PA方面。
如果是4级的企业,这3个PA就要做得好些了。
总结一下3级的几个重要特点:
1)明确规定了需求开发、设计、编码、测试、集成等软件开发各过程的要求。
2)对项目管理提出了更高的要求,要利用组织级的数据来管理项目。
3)出现了专门针对组织级的PA,要求有专门的组织来负责过程改进的工作。
4)提供了一个做出最佳决策的指导,而这个方法可以用于软件工程,也可以用于组织级过程改进。
由这些特点大家可以看到,3级已经对软件开发的各个方面有了详细的要求,2级很多不明细的地方全部已经明确。一个达到3级的企业,肯定会定义了很多软件开发各个方面的过程,并且会有组织级的财富库。所以3级叫&ldquo已定义&rdquo级。
补充说明:
3级还有另外3个PA上文没有提到,分别是
Integrated Teaming、Organizational Environment for Integration:对大型软件团队提出了要求,一般情况下中小型软件企业可以NA。
Integrated Supplier Management:如果软件企业需要管理大量的供应商,则需要考虑这个PA。
目 录
一章:需求开发(Requirements Development) 2
二章:技术解决方案(Technical Solution)........ 5
三章:产品集成(Proct Integration).... 7
四章:验证(Verification).. 8
五章:确认(Validation).. 10
六章:风险管理(Risk Management) 11
七章:集成项目管理(Integrated Project Management)................... 12
八章:决策分析与解决方案(Decision Analysis and Resolution).. 14
九章:组织过程聚焦(Organizational Process Focus)................... 15
十章:组织过程定义(Organizational Process Definition).... 17
十一章:组织培训(Organizational Training)...... 18
因为文章涉及到20页。我们就看下第一章哦,其他的请下载附件。
说明:下载的附件只能供个人学习及参考,请不要在网络上流传及转载,除非得到张传波的同意。
一章:需求开发(Requirements Development)
CMM的时候,是没有需求开发这个PA的,需求开发和需求管理有什么区别呢?
需求管理强调的是需求的确认以及需求变更的控制,而需求开发讲究的是用系统的方法获取真正的全面的能实现的需求。
以上两个关于需求开发的例子,都是反面教材,都没有能很好地把握需求,一个没有抓住问题的关键,一个没有能找到真正的需求提供者来获取需求。
CMMI和CMM相比,增加了很多专门针对软件工程的PA,其中需求开发(RD)就是其中之一。需求开发这个PA,从很高的层次描述了如何做好需求开发。要理解好本PA,需要先理解清楚以下几个关键的概念:
1)客户需求(Customer Requirements)
2)产品需求(Proct Requirements)
3)产品组件需求(Proct Component Requirements)
客户需求是可以理解成客户为什么要做本系统,要解决什么问题,客户对系统有怎样的期望,希望能具备一些怎样的特点,简单的说,就是客户的需要是什么。
产品需求是能满足客户需求,并对软件产品规格进行了详细描述的需求,软件设计师可以根据产品需求进行设计、编码等工作。
产品组件需求,是对产品需求的进一步细化,产品可能会分割成几个子系统、几个部分,每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等,这些可以认为是产品组件需求。
从另外一个角度,需求可以分为功能性需求和非功能性需求两类,功能性需求就是系统具备怎样的功能,能做什么事情,而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求,都会包含功能需求和非功能需求。
以前面提到的&ldquo短信订餐系统&rdquo为例,其实这个系统,客户需求很简单,就是要解决部分员工不方便订餐的问题。我们看到,如果我们没有抓住这个客户需求,一开始就认为非要做一个短讯系统,那么就会陷入例子的陷阱中。要解决这个客户需求,办法之一就是做短讯订餐系统,但更合适的办法可能就是打电话回公司让别人代订午饭了。
我们很多需求开发没有做好的原因,大部分是没有把握好客户需求,直接进入软件的细节,去讨论要做什么功能,界面要怎样设计去了,而忘记了软件的根本目的是为了解决什么问题。
当我们明确客户需求后,就应该把客户需求转变成产品需求和产品组件需求,客户需求一般都是比较高层次的,而且描述也会比较简单,不能作为日后验收的标准,我们需要对软件的规格进行说明。一般来说,我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候,要注意产品需求和产品组件需求,必须和客户需求对应起来,通常是多对多的关系。为什么要对应起来?我们要保证,软件的每一个界面,每一个功能都是有用的,都是&ldquo源自&rdquo客户需求的,这样才能保证我们做的事情都是正确的事情,防止被不相干的事情干扰。
我们经常抱怨客户的需求在变,其实80%的原因是没有把握住客户需求,其实客户经常变的是产品需求或者是产品组件需求,客户需求是很少变的,就是因为我们没有把握住客户到底想要什么、需要什么,导致我们认为客户太难&ldquo服侍&rdquo了。只有把握住客户真正的需求,我们才能抓住根本,万变不离其中。
接着下来,我们将从每个SG和每个SP来详细讲解需求开发这个PA。
RD有三个SG,SG1开发客户需求,SG2开发产品需求,SG3分析和确认需求。
前两个SG讲述的是需求开发由顶而下、由粗到细的过程,SG3讲述的是需求分析和确认的过程。下面详细阐述:
SG1: Stakeholder needs,expectations,constraints,and interfaces are collected and translated into customer requirements.
参考资料:www.chinaopi.com.cn
热心网友
时间:2023-11-23 06:15
很抽象,和计算机联系不大,如果没接触过编程有一定难度,如果公司有项目的话可以理论联系实际这样比较好,至于学多久就要看你的理解能力了。祝你好运!
热心网友
时间:2023-11-23 06:15
难 cmmi是个编写软件的 过程管理办法 有经验的都不容易理解 没经验的就更不好理解了 你可以去中信保国际集团的网站上查找一些cmmi的相关只知识