CMMI对于一个不太懂计算机的人来说难学吗
发布网友
发布时间：2022-05-21 15:53
共3个回答
热心网友
时间：2023-11-23 06:14
如果说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
