CMMI是什么，有什么用，怎么认证CMMI
什么是CMMI，CMMI有什么用，怎么认证CMMI
CMMI是什么？
CMMI是“能力成熟度集成模型（Capability Maturity Model Integration）”的英文简写，该模型由美国卡内基-梅隆大学的软件工程研究所（简称SEI）受美国国防部委托，于1991年研究制定，初始的主要目的是为了评价美国国防部的软件合同承包组织的能力，后因为在软件企业应用CMMI模型实施过程改进取得较大的成功，所以在全世界范围内被广泛使用。CMMI的基本目标 ......
什么是CMMI，CMMI有什么用，怎么认证CMMI
CMMI是什么？
CMMI是“能力成熟度集成模型（Capability Maturity Model Integration）”的英文简写，该模型由美国卡内基-梅隆大学的软件工程研究所（简称SEI）受美国国防部委托，于1991年研究制定，初始的主要目的是为了评价美国国防部的软件合同承包组织的能力，后因为在软件企业应用CMMI模型实施过程改进取得较大的成功，所以在全世界范围内被广泛使用。CMMI的基本目标
百度一下 恒标冯经理15275697707
为实现此目标，CMMI给出了集中而又灵活的过程模型框架。按照模型框架执行实施项目过程，并对过程持续改进。CMMI相信通过持续的过程改善，能够最终改进组织的质量和效率。
CMMI和PMP的区别与联系
CMMI是专注于软件开发工程的过程管理模型。相比于PMP中囊括的项目管理方法工具，CMMI不直接提供实施过程的方法，但CMMI更偏向结果导向，以达成改进组织质量和效率为目标，多种途径都可以实现符合CMMI标准的项目过程，PMP中提到方法同样也可以借鉴。
CMMI能解决什么问题，有什么用
CMMI模型实施是为解决软件工程过程中的实际问题，以下列举了一些CMMI会关注的问题项目无法按期交付，费用超出预算;需求规格说明总是一改再改;人员的变动对组织带来很大的影响;维护成本居高不下;不能在顾客希望时间内完成维护,带来顾客抱怨；可移植性差；可复用性差。
CMMI是英文Capability Maturity Model Integration的缩写。CMMI认证简称软件能力成熟度集成模型，是鉴定企业在开发流程化和质量管理上的国际通行标准，全球软件生产标准大都以此为基点，并都努力争取成为CMMI认证队伍中的一分子。
对一个软件企业来说，达到CMMI2就基本上进入了规模开发，基本具备了一个现代化软件企业的基本架构和方法，具备了承接外包项目的能力。CMMI3评估则需要对大软件集成的把握，包括整体架构的整合。一般来说，通过CMMI认证的级别越高，其越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。
喜讯！立得空间成功通过CMMI5级认证
近日，立得空间顺利通过软件CMMI5级认证，获得国际权威认可，标志着立得空间的过程组织能力、软件研发能力、项目管理能力以及方案交付能力已达到国际先进水平。[图片]
[图片]
CMMI 是国际公认的衡量软件企业研发能力成熟度和项目管理水平的权威标准，代表着国际上最先进的软件工程管理方法。该认证体系共有五个等级，其中CMMI 5级为该体系最高等级的评估，是企业在软件研发标准化、规范化、成熟度等方面的最高认证。
鉴于当前业务和管理的需要，从去年5月开始，立得空间全公司齐心协力优化研发管理体系。国内外专业评估师采用MDD（V2.0)评估方法，依据美国CMMI研究院的CMMI® V2.0模型，对公司研...
近日，立得空间顺利通过软件CMMI5级认证，获得国际权威认可，标志着立得空间的过程组织能力、软件研发能力、项目管理能力以及方案交付能力已达到国际先进水平。
CMMI 是国际公认的衡量软件企业研发能力成熟度和项目管理水平的权威标准，代表着国际上最先进的软件工程管理方法。该认证体系共有五个等级，其中CMMI 5级为该体系最高等级的评估，是企业在软件研发标准化、规范化、成熟度等方面的最高认证。
鉴于当前业务和管理的需要，从去年5月开始，立得空间全公司齐心协力优化研发管理体系。国内外专业评估师采用MDD（V2.0)评估方法，依据美国CMMI研究院的CMMI® V2.0模型，对公司研发管理活动进行评估，经过诊断、构建、运行和总结阶段，加以系统的培训和优化，改进了日常研发管理工作流程。
20多年来，立得空间为全国600多个城市、数以千计的客户提供服务，我们不断提高研发管理、项目管理、产品设计等关键能力，获得了市场高度认可。2022年1月，经过国际权威专家的严格评审和考核，立得空间成功通过CMMI5级正式评估，为公司持续创新发展提供了强劲的动力。
CMMI 能力成熟度模型集成
CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。
自从1994年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在：
1、不能集中其不同过程改进的能力...
CMMI是CMM模型的最新版本。早期的CMMI（CMMI-SE/SW/IPPD）1.02版本是应用于软件业项目的管理方法，SEI在部分国家和地区开始推广和试用。随着应用的推广与模型本身的发展，演绎成为一种被广泛应用的综合性模型。
自从1994年SEI正式发布软件CMM以来，相继又开发出了系统工程、软件采购、人力资源管理以及集成产品和过程开发方面的多个能力成熟度模型。虽然这些模型在许多组织都得到了良好的应用，但对于一些大型软件企业来说，可能会出现需要同时采用多种模型来改进自己多方面过程能力的情况。这时他们就会发现存在一些问题，其中主要问题体现在：
1、不能集中其不同过程改进的能力以取得更大成绩；
2、要进行一些重复的培训、评估和改进活动，因而增加了许多成本；
3、遇到不同模型中有一些对相同事物说法不一致，或活动不协调，甚至相抵触。
于是，希望整合不同CMM 模型的需求产生了。1997 年，美国联邦航空管理局（FAA）开发了FAA-iCMMSM（联邦航空管理局的集成CMM），该模型集成了适用于系统工程的SE-CMM、软件获取的SA-CMM 和软件的SW-CMM 三个模型中的所有原则、概念和实践。该模型被认为是第一个集成化的模型。
CMMI 与CMM 最大的不同点在于：CMMISM-SE/SW/IPPD/SS 1.1 版本有四个集成成分，即：系统工程(SE)和软件工程(SW)是基本的科目，对于有些组织还可以应用集成产品和过程开发方面(IPPD)的内容，如果涉及到供应商外包管理可以相应的应用SS(Supplier Sourcing)部分。
CMMI 有两种表示方法，一种是大家很熟悉的，和软件CMM 一样的阶段式表现方法，另一种是连续式的表现方法。这两种表现方法的区别是：阶段式表现方法仍然把CMMI 中的若干个过程区域分成了5 个成熟度级别，帮助实施CMMI 的组织建议一条比较容易实现的过程改进发展道路。而连续式表现方法则通过将CMMI 中过程区域分为四大类：过程管理、项目管理、工程以及支持。对于每个大类中的过程区域，又进一步分为基本的和高级的。这样，在按照连续式表示方法实施CMMI的时候，一个组织可以把项目管理或者其他某类的实践一直做到最好，而其他方面的过程区域可以完全不必考虑。
台阶一：CMMI一级，完成级。在完成级水平上，企业对项目的目标与要做的努力很清晰，项目的目标得以实现。但是由于任务的完成带有很大的偶然性，企业无法保证在实施同类项目的时候仍然能够完成任务。企业在一级上的项目实施对实施人员有很大的依赖性。
台阶二：CMMI二级，管理级。在管理级水平上，企业在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对相关的项目实施人员有相应的培训，对整个流程有监测与控制，并与上级单位对项目与流程进行审查。企业在二级水平上体现了对项目的一系列的管理程序。这一系列的管理手段排除了企业在一级时完成任务的随机性，保证了企业的所有项目实施都会得到成功。
台阶三：CMMI三级，定义级。在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。科学的管理成为企业的一种文化，企业的组织财富。
台阶四：CMMI四级，量化管理级。在量化管理级水平上，企业的项目管理不仅形成了一种制度，而且要实现数字化的管理。对管理流程要做到量化与数字化。通过量化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
台阶五：CMMI五级，优化级。在优化级水平上，企业的项目管理达到了最高的境界。企业不仅能够通过信息手段与数字化手段来实现对项目的管理，而且能够充分利用信息资料，对企业在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。
由上述的五个台阶我们可以看出，每一个台阶都是上面一阶台阶的基石。要上高层台阶必须首先踏上较低一层台阶。企业在实施CMMI的时候，路要一步一步地走。一般地讲，应该先从二级入手。在管理上下功夫。争取最终实现CMMI的第五级。
From:http://www.baike.com/wiki/CMMI
【CMMI】软件需求质量属性定义与ISO-9126关系
===============================================================================================
Sunrise按：本文乃Sunrise在整理需求开发中的一篇小文章，供理解需求开发和ISO-9126质量特征描述间的关系。今发出，供参考。
================================================================================================
软件开发中，需求是软件开发的源头。需求...
===============================================================================================
Sunrise按：本文乃Sunrise在整理需求开发中的一篇小文章，供理解需求开发和ISO-9126质量特征描述间的关系。今发出，供参考。
================================================================================================
软件开发中，需求是软件开发的源头。需求的改变将如同亚马逊河一边蝴蝶翅膀的振动引起另外一边的风暴一样，将引起一系列相应活动和文件的改变。故要联动地看待需求的改变。见图：
CMMI-DEV V1.3在需求开发中强调了软件需求的质量属性定义，见下图：
什么是软件的质量属性呢？CMMI-DEV V1.3中就提出了timeliness, throughput, responsiveness, security, modifiability, reliability, and usability这么几个属性。所有的软件质量属性都是非功能性需求范围。但如果想要知道明确的软件质量属性定义，那恐怕就要从非CMMI-DEV这个模型去查了。
ISO-9126就是专门阐述软件质量属性的文件。它提出了6个专门的软件属性及21个子属性。见下图：
有关ISO-9126软件质量特征的细部说明如下：
ISO-9126 软件需求质量定义
Functionality
A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs. (ISO 9126: 1991, 4.1)
Sub Characteristics
Suitability:
Attribute of software that bears on the presence and appropriateness of a set of functions for specified tasks. (ISO 9126: 1991, A.2.1.1)
Accuracy:
Attributes of software that bear on the provision of right or agreed results or effects. (ISO 9126: 1991, A.2.1.2)
Interoperability:
Attributes of software that bear on its ability to interact with specified systems. (ISO 9126: 1991, A.2.1.3)
NOTE -- Interoperability is used in place of compatibility in order to avoid possible ambiguity with replaceability. (ISO 9126: 1991, A.2.1.3)
Compliance:
Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. (ISO 9126: 1991, A.2.1.4)
Security:
Attributes of software that bear on its ability to prevent unauthorized access, whether accidental or deliberate, to programs and data. (ISO 9126: 1991, A.2.1.5)
Reliability
A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. (ISO 9126: 1991, 4.2)NOTE -- Wear or ageing does not occur in software. Limitations in reliability are due to faults in requirements, design and implementation. Failures due to these faults depend on the way the software product is used and the program options selected rather than on elapsed time. (ISO 9126: 1991, 4.2)
Sub Characteristics
Maturity:
Attributes of software that bear on the frequency of failure by faults in the software. (ISO 9126: 1991, A.2.2.1)
Fault tolerance:
Attributes of software that bear on its ability to maintain a specified level of performance in cases of software faults or of infringement of its specified interface. (ISO 9126: 1991, A.2.2.2)
Recoverability:
Attributes of software that bear on the capability to re-establish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it. (ISO 9126: 1991, A.2.2.3)
Usability
A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users. (ISO 9126: 1991, 4.3)NOTES
- `Users' may be interpreted as most directly meaning the users of interactive software. Users may include operators, end users and indirect users who are under the influence or dependent on the use of the software. Usability must address all of the different user environments that the software may affect, which may include preparation for usage and evaluation of results.
- Usability defined in this International Standard as a specific set of attributes of software product differs from the definition from an ergonomic point of view, where other characteristics such as efficiency and effectiveness are also seen as constituents of usability. (ISO 9126: 1991, 4.3)
Understandability:
Attributes of software that bear on the users' effort for recognizing the logical concept and its applicability. (ISO 9126: 1991, A.2.3.1)
Learnability:
Attributes of software that bear on the users' effort for learning its application (for example, operation control, input, output). (ISO 9126: 1991, A.2.3.2)
Operability:
Attributes of software that bear on the users' effort for operation and operation control. (ISO 9126: 1991, A.2.3.3)
Efficiency
A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions. (ISO 9126: 1991, 4.4)NOTE -- Resources may include other software products, hardware facilities, materials, (e.g. print paper, floppy disks) and services of operating, maintaining or sustaining staff. (ISO 9126: 1991, 4.4)
Sub Characteristics
Time behaviour:
Attributes of software that bear on response and processing times and on throughput rates in performing its function. (ISO 9126: 1991, A.2.4.1)
Resource behaviour:
Attributes of software that bear on the amount of resources used and the duration of such use in performing its function.(ISO 9126: 1991, A.2.4.2)
Maintainability
A set of attributes that bear on the effort needed to make specified modifications. (ISO 9126: 1991, 4.5)NOTE -- Modifications may include corrections, improvements or adaptation of software to changes in environment, and in requirements and functional specifications. (ISO 9126: 1991, 4.5)
Sub Characteristics
Analysability:
Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures, or for identification of parts to be modified. (ISO 9126: 1991, A.2.5.1)
Changeability:
Attributes of software that bear on the effort needed for modification, fault removal or for environmental change. (ISO 9126: 1991, A.2.5.2)
Stability:
Attributes of software that bear on the risk of unexpected effect of modifications. (ISO 9126: 1991, A.2.5.3)
Testability:
Attributes of software that bear on the effort needed for validating the modified software. (ISO 9126: 1991, A.2.5.4)
Portability
A set of attributes that bear on the ability of software to be transferred from one environment to another. (ISO 9126: 1991, 4.6)NOTE -- The environment may include organizational, hardware or software environment. (ISO 9126: 1991, 4.6)
Sub Characteristics
Adaptability:
Attributes of software that bear on the opportunity for its adaptation to different specified environments without applying other actions or means than those provided for this purpose for the software considered. (ISO 9126: 1991, A.2.6.1)
Installability:
Attributes of software that bear on the effort needed to install the software in a specified environment. (ISO 9126: 1991, A.2.6.2)
Conformance:
Attributes of software that make the software adhere to standards or conventions relating to portability. (ISO 9126: 1991, A.2.6.3)
Replaceability:
Attributes of software that bear on the opportunity and effort of using it in the place of specified other software in the environment of that software. (ISO 9126: 1991, A.2.6.4)
NOTES
- Replaceability is used in place of compatibility in order to avoid possible ambiguity with interoperability.
- Replaceability with a specific software does not imply that this software is replaceable with the software under consideration.
- Replaceability may include attributes of both installability and adaptability. The concept has been introduced as a subcharacteristic of its own because of its importance.
【CMMI】浅谈CMMI PDP
最近项目PDP过程中碰到了几个问题，还真是比较普遍的现象。现记录下来，以供他人和自己日后参考。
问题：
1. 裁剪该听谁？ 为何要裁剪？裁剪什么？
2. 组织级过程在项目PDP中如何裁剪？
3. 是否PDP裁剪指南中提到的Mandatory就不能裁剪？
先说第一个问题。其实在裁剪过程中，我也常听到某些人谈到，XXX顾问当初不允许我们裁剪XX过程。这里，似乎我们又回到了中国的二三十年代，那时，苏联老大哥顾问可是很吃香，举手一挥，你们应该XXXXXX。不错，顾问的确当时在评估前不许裁掉XX过程域，但那时是为大家熟悉整个CMMI ML3，同时为通过SCAMPI...
最近项目PDP过程中碰到了几个问题，还真是比较普遍的现象。现记录下来，以供他人和自己日后参考。
问题：
1. 裁剪该听谁？ 为何要裁剪？裁剪什么？
2. 组织级过程在项目PDP中如何裁剪？
3. 是否PDP裁剪指南中提到的Mandatory就不能裁剪？
先说第一个问题。其实在裁剪过程中，我也常听到某些人谈到，XXX顾问当初不允许我们裁剪XX过程。这里，似乎我们又回到了中国的二三十年代，那时，苏联老大哥顾问可是很吃香，举手一挥，你们应该XXXXXX。不错，顾问的确当时在评估前不许裁掉XX过程域，但那时是为大家熟悉整个CMMI ML3，同时为通过SCAMPI A评估而设的。任何话语，必须置于一定的时空背景下去理解才有意义，而非放之四海而皆准。CMMI的实践主体是公司，而非顾问。放眼读遍整个CMMI DEV V1.2版文本，也没有一定规定必须全部保留过程、活动、工作产品，等。因此，裁剪的目的是为了公司更好更有效地执行CMMI活动，更好地做项目，从而达到服务公司的业务目的。因此，项目PDP裁剪是为项目服务，而非设置障碍。项目裁剪的决定者（PL、PM、PPQA leader和其他相关干系人）在项目实际的基础上决定裁剪，则该项目PDP就可以成立，而且可以不断被更新。
那裁剪什么？什么都可以被裁剪，只要被裁剪的符合组织的期望和要求。一般来说，生命周期的phase，PA，Activities, Work Products, Measures, 等都可以被裁剪。裁剪的方法通常可以有Delete, Revise, Merge, Reduce, Add等几种。裁剪的原则就是要符合组织期待与要求，根据实际裁剪，根据实际更新裁剪。
现在说第二个问题，组织级过程在项目PDP中如何裁剪？
要回答这个问题，先要搞清楚组织级过程域通常由谁来实施。这是个白痴的问题，组织级过程当然是组织级来实施。那么组织级与项目级有何关系？是否一定要把组织级的过程域一定要拉入项目级PDP呢？
一般认为，OPF是组织EPG要关心的事，组织应该有个常任EPG的组织，负责不断采集、分析和识别组织的问题和改善机会，不断持续组织过程的改善。由于这个机构的存在，EPG参与所有的项目。因此，从这点上来看，OPF可以被列入项目PDP中，但也可以独立出来。因为，只要EPG在做事，OPF就一定能够被满足。OPD则同理。至于OT，基本相同，但操作上则更为复杂一些。
一般来说，如果组织培训架构包括了项目培训部分，即组织可以采集到项目培训计划或项目培训可以通过某种手段汇集到组织培训那儿，则OT需要包括到PDP中。否则，为提升作业效率，OT可以被裁剪。另外一个情况，如果项目人员有不熟悉组织流程、文化、必须技能而需要组织方面的培训，则OT又不可裁剪。因此，OT的裁剪需要根据实际情况和需要来决定裁剪。
在实际作业中，PPQA是一个严谨的、很遵守规范的部门。他们通常依据现有的规定来判断是否作业符合流程与规范。然而，实际的作业又需要一定的灵活性。因此，在PDP中被界定mandatory的是否一定不能裁剪呢？如果你去问顾问这个答案，则答案一定是不能裁剪。但我们知道，任何事物都在不断运动与发展中，因此，没有什么事情是一成不变的。只要你有充分的理由去改变，则你可以去改变，但需要注意的是：改变需要遵循流程，需要获得EPG（及其他相关高阶管理者）的同意，需要你将裁剪的案例陈述清楚，并贡献到组织财富库中去。
总而言之，你做CMMI是要遵循它的精神，而不是被它的某些条条框框所束缚。中国人做事的最高境界不是形似，而是神似。只有神似，才能活用，才能最大程度地利用到CMMI。这才是能力成熟度的提高。
【CMMI】CMMI评估Final Findings翻译
【CMMI】评估Final Findings翻译
By Sunrise
2009-12-25
(C) No copy or duplication is allowed without prior consent of the author.
1．使用系統協助執行項目中工作產品審核時，審核人員由提出人指派，可能會遺漏必須參加審核人員，無法達到把關的目的。
When using a system to review and approve project work products, the review board list of each gate is assigned...
【CMMI】评估Final Findings翻译
By Sunrise
2009-12-25
(C) No copy or duplication is allowed without prior consent of the author.
1．使用系統協助執行項目中工作產品審核時，審核人員由提出人指派，可能會遺漏必須參加審核人員，無法達到把關的目的。
When using a system to review and approve project work products, the review board list of each gate is assigned by the initiator. This may drop the required review persons and lead to failure of the intended purpose for review.
2. 除了關注客戶提出之需求變更和重大變更(如平台變更) 以外，需求規格基線發佈後發生的需求變更(如因設計導致的變更)，也應納入需求管理範圍中。
Besides customer proposed requirements and major changes like platform change, it is required to include all requirement changes occurring after each release of requirement baseline, such as design changes.
3. 少數項目屬性值的估算沒有變化，但工作量估算隨工期的延長而增加，不符合估算模型的精神。
There is no change of attribute value in a few projects’ estimation, but its effort grows with schedule delay. This fails to be conformant with the intended use of the organization’s estimation model.
4. 部份項目於WBS細部任務(Task)規劃與工作量分配時，未檢查規劃完成工作量與估算結果(總工作量、生命週期階段工作量分配%...等)間之一致性。
When making WBS task planning and effort allocation, some projects failed to inspect the consistency between the planned effort and the estimated effort (total effort, percentage allocation to each lifecycle phase, etc.)
5. 項目在計畫中識別所有的Stakeholders，但是對部份外部Stakeholders的參與規劃不完整。
Project plans have identified all stakeholders, but some external stakeholders’ involvement planning is incomplete.
6. 度量報告中度量項數據來源定義不夠明確，可能影響度量資料的正確性。如工作量數據，未指出原始數據(Raw Data)來源。
The definition of certain measures’ data source in MA reports is not explicit. For example, the effort data collection fails to specify its raw data source. This may impact the correctness of measurement data.
7. 度量分析多為反應度量工作執行面之問題，對數據所呈現出之意義，未有深入詮釋(Interpretation)。
The current measurement analysis is mostly seen to reflect the execution of MA work and failed to present further interpretation upon what the data convey in itself.
8. 建議負責度量工作人員，應接受進階的訓練(如統計分析)，強化資料分析能力。
It is recommended that MA engineers receive advanced trainings like statistics to improve their ability in data analysis.
9. 目前PPQA對所有工作產品與流程執行狀況皆有進行審核，然而對部份受審查項目之深入程度不足，無法指出相關之不符合事項(NC)。
At present, PPQA audits all work products and the execution of process activities, but lacks inspection depth in some projects and therefore is unable to find out the related non conformance items.
10. PPQA人員由各單位選派人員產生。部份PPQA人員( 含主管)的工作由其主管進行稽核，可能影響評估之客觀性。
PPQA members are now assigned by different organizational units. Some PPQA members (including manager) are audited by their direct manager, which may impact on the objectivity of its evaluation.
11. 項目對代碼之配置識別不夠完整，可能影響後續管理工作之執行(例如對開放源代碼、自行開發代碼之管理應有所區別，以避免侵權)。
Projects failed to identify the complete configuration of source code. This may impact on the successive code management. For example, open source code should be distinguished from self developed code to avoid possible intellectual property infringement.
12. 部份逐步分解需求的文件(如：Draft Feature List、MMI Guide)，命名與定義不規範。建議能有一致性的規範。
The naming convention and definition of some requirement development documents like Draft Feature List and MMI Guide is short of a rule. It is recommended a rule for consistency be generated and followed.
13. 項目中有執行PDP中定義的Code Review工作， 但沒有在Peer Review Plan中指定Review的Code和Review的方法，可能導致Code Review的執行範圍不清楚、方法不一致、與紀錄不完整。
In projects, code review is performed in accordance with PDP definition. However, the Peer Review Plan does not define code review scope and method, which may cause the code review’s scope unclear, method inconsistent and records incomplete.
14. 項目使用Peer Review Report和QA Test Report分別對缺陷進行分目前析，但未見對整體測試有效性之分析。建議對整個生命週期中各開發階段Verification (Peer Review，Unit Test，PI Test，QA Test)的缺陷加強總體的分析。
The projects use Peer Review Report and QA Test Report now to analyze defects independently, and therefore miss an analysis on the validity of the entire testing. It is recommended that the organization strengthen the overall verification analysis of defects existing in each lifecycle phase (Peer Review, Unit Test, PI Test and QA Test).
15. 目前即使是同樣的工作產品，也是由項目自行制定Checklist進行Peer Review。建議組織能蒐集項目回饋之Checklist，按工作產品來分類管理，以便未來項目執行Peer Review 參考。
At present each project defines checklists itself to conduct peer review, even the same work product. It is recommended that the organization can collect all checklists defined by projects and manage them by category of work products for future peer review references.
16. 目前項目使用QA Test Report對缺陷進行分析，但未見對整體測試有效性之分析。建議對整個生命週期中各開發階段Verification (Peer Review，Unit Test，PI Test，QA Test)和Validation (White Glove Test, Stress Test, …等)的缺陷加強總體的分析。
Projects use QA Test Report now to analyze defects, but analysis on the validity of the entire testing is not seen. It is recommended that the organization strengthen the overall verification analysis (Peer Review, Unit Test, PI Test and QA Test) and validation analysis (White Glove Test, Stress Test, etc.) of defects existing in each lifecycle phase.
17. 組織應加強項目回饋之工作產品、度量數據、與經驗分享進行說明，以便項目應用這些資產。
The organization should strengthen instructions and trainings on project contributions like work products, measurement data and lessons learned so that projects can deploy these assets.
18.度量庫中項目類型考量不夠完整，未包含所有組織之項目形態。
OMR does not include all project types and all projects in the organization and therefore is incomplete.
19. 組織應加強財富庫管理規範(如入庫準則，標準生產率基線發佈頻率等)，以確保不會捨棄未來可用的數據，以及協助項目取得正確之規劃依據。
The organization should provide more detailed OPAL management guidelines (entry criteria, standard productivity baseline release frequency, etc.) to ensure that the organization’s process assets will not ignore the future usable data which may help plan projects correctly.
20. 少數項目未經CCB審核流程簽核，就已將資料回饋入庫。組織應加強財富庫簽核流程管理。
A few projects contributed project data to OPAL without CCB review and approval. The organization should strengthen the flow management of OPAL review and approval.
21. 組織財富庫目前使用項目作分類，庫結構比較複雜，目錄結構層次較深，影響使用人員查詢搜索與獲取文件的效率。建議財富庫架構可按流程(Processes)進行分類。
The available OPAL is categorized by projects and its structure is a bit complicated with multiple embedded folders. This will impact its searching and file getting efficiency. It is recommended that OPAL be classified by processes.
22. 目前組織培訓成果績效通常由員工直屬主管打分。建議根據培訓內容決定是否納入項目主管打分。
At present the organizational training effectiveness is usually assessed by home organization manager. It is recommended that project manager be included in training effectiveness assessment dependent on training content.
23. 少數項目PDP (Project Defined Process)之裁剪(Tailoring)理由的描述與組織裁剪指南的定義不一致。
The descriptions of a few projects’ PDP tailoring reasons do not comply with the definition in the organizational tailoring guidelines.
24. 少數項目之度量報告顯示實際工作量與估算工作量有落差，但未及時檢討，會影響矯正措施的有效性。
A few projects’ measurement reports show a gap between the planned effort and the estimated effort and failed to be reviewed timely, which may have impact on the validity of its corrective actions.
25. 在PDPＭ會議有討論與紀錄重要stakeholder之關鍵依賴關係，但未在項目計劃涵蓋所有重要stakeholder之關鍵依賴關係，可能對後續的項目進展中的管理造成漏失。
PDPM (Product Development and Project Management) meetings have discussed and recorded all important stakeholders’ key dependencies but failed to cover them in project plans, which may cause its missing in the following project management activities.
26. 少數項目對風險處理和提出的處理方法(Avoid, Mitigate, Accept, Transfer)不一致，例如處理方式是緩解，但並未列出緩解計劃。
A few projects failed to handle risks in consistency with their plans (Avoid, Mitigate, Accept and Transfer). For example, it is planned to mitigate, but a mitigation plan is missing.
27. 建議嚴重度(Impact)較高的風險，即使風險系數(Exposure)較低，也應訂定緩解計劃，避免一旦發生時會產生重大的影響。
It is recommended that risks with high impact be given mitigation plans even though their risk exposure is low, such that severe impact can be avoided in case of their occurrence.
28. 建議對於挑選出來備選方案的過程要有相關的記錄，以便未來追蹤與瞭解。
It is recommended that the process of how to select the alternative solutions be recorded for future traceability and understanding.
29. 建議對於備選方案各項準則(Criteria)的評分標準要有明確的定義，如無可能導致因個人認知不同而造成之差異。
It is recommended that there should be definite scoring instructions on each alternative solution’s criteria such that no misunderstanding will arise during rating.