0x00 背景 
 
     对于今天高度依赖信息竞争力的企业来说，信息安全的重要性已经无需多言但是，随着信息安全市场技术创新的不断加速，新的威胁、技术和方法不断涌现，信息安全人才和专业服务相对匮乏，这些都为企业的信息安全策略制定带来了困惑。
 
     信息安全成熟度模型能够帮助企业快速找到信息安全短板并制定有针对性的策略，加速将信息安全融入企业文化，提升企业“安全竞争力”。
 
0x01 CMMI V2.0 模型
 
   为了应对不断变化的全球化商业格局的挑战，CMMI DEV V2.0将通过标杆对比帮助企业建立并提高关键能力以提高企业绩效。它是一套经过验证的全球最佳实践，旨在优化不断变化的全球环境中的业务性能，帮助组织建立解决最常见业务挑战的关键能力并设定相应基准，包括：设计和开发产品
 
提高性能
交付和管理服务
维持习惯性和持久性
管理业务弹性
规划和管理工作
选择和管理供应商
确保质量
管理员工
支持实施
CMMI V2.0 关键改进
 
1. 改进业务性能：业务目标直接与运营相关联，以便在时间、质量、预算、客户满意度和其他关键驱动因素方面实现可度量的性能提升。
 
2. 利用当前的最佳实践：CMMI V2.0 是经验证最佳实践的可信来源，将不断更新以反映新在线平台上不断变化的业务需求。
 
3. 构建敏捷弹性和规模：直接指导如何增强使用 Scrum 的敏捷项目的过程，并注重性能。
 
4. 提高基准评估的价值 新的绩效导向评估方法提高了基准评估的可靠性和一致性，同时缩短了准备时间和生命周期成本。
 
5. 加速采用  通过在线访问和应用指南，比以往更加容易获得 CMMI 的优势。
 
相关文档：链接：https://pan.baidu.com/s/1264cAjIfnYLJzCYtCz-smg 提取码：mkqf
 
0x02  信息安全能力成熟度模型(IS-CMM)的建构
 
    在能力成熟度模型(CMM)的基础上提出“信息安全能力成熟度模型”(IS－CMM)这一构想，并着重探讨了IS－CMM各级中的核心
 流程域KPAs的构建。IS-CMM ( 将信息安全流程实施的全部生命周期 不同于信 息安全开发中的生命周期)分为4 个相对独立的阶段：预防 (Prevention)；监测(Monitoring)；修正(Amendment) ；更新 (Revision) 。一个或数个机构的信息安全流程环境被定义为总体信息安全流程(TotalInformation Security Processes，简称TISP)，内容包括
 
数据流程安全（电子数据安全、印刷数据安全等）
系统流程安全（项目、工程、流程、硬件，软件，数据等)；
人力流程安全(安全意识、员工培训等) 
机构流程安全 （管理、机构，文化等）
 
第一阶段为预防，包括信息安全资产评 估、安全需求细分、风险分析、安全计划与预防实施等。 
第二阶段为监测，着眼于安全脆弱性、安全灾难、操作失误 等的监控跟踪。 
第三是修正阶段，针对第二阶段发现的问 题进行更正，解决错误。 
更新阶段，将涉及的部分 或整体安全流程模块进行重新界定，重整和升级。 

 在
 IS-CMM
 中，机构的信息安全流程成熟度从低到高有 5个能力等级： 
 
第一级：无控制级 ； (Uncontrolled Level) 
第二级：控制级 ； (Controlled Level) 
第三级：定义级 ； (Defined Level) 
第四级：定量级 ； (Quantified Level) 
第五级：预防级 。
 
相关文档：链接：https://pan.baidu.com/s/17paabkT3faI8T34Ut5LQHw 提取码：sm66
 
0x03 OWASP SAMM(软件保证成熟度模型）
 
     软件保证成熟度模型（SAMM） 是一个开放的框架，用以帮助组织制定并实施针对组织所面临来自软件安全的特定风险的策略。由SAMM提供的资源可作用于以下方面：
 ✦评估一个组织已有的软件安全实践；
 ✦建立一个迭代的权衡的软件安全保证计划；
 ✦证明安全保证计划带来的实质性改善；
 ✦定义并衡量组织中与安全相关的措施。
 
 
      在最高等级上， SAMM设置了四种关键业务功能。 每种业务功能（在下文中列出）是一组软件开发过程中具体细节的相关措施；换句话说，任何涉及了软件开发的组织，必须在一定程度上实现每一个业务功能。
 
    对于每一个业务功能， SAMM设置了三个安全措施。 每个安全措施（在下页中列出）是一个与安全相关的措施的领域，以为相关业务功能建立保证。 所以，从总体来说， 这十二个安全措施都是改进软件开发业务功能的独立部分。
 
     对于每一个安全实践， SAMM设置了三个成熟度等级作为目标。 安全实践中的每个等级， 通过设置特定的活动和比先前等级更加严格的成功指标， 设定了一个更加复杂的目标。此外，每个安全实践可被独立改善， 虽然相关的措施可导致优化。
 
相关文档：链接：https://pan.baidu.com/s/1zwZpxT58hhE9lLjhc4RLRw 提取码：09bg 
  
 
0X04 微软SDL （安全开发生命周期）
 
      Microsoft SDL在开发过程的所有阶段都引入了安全性和隐私注意事项，从而帮助开发人员构建高度安全的软件，解决安全合规性要求并降低开发成本。Microsoft SDL中的指南，最佳实践，工具和过程是我们在内部使用以构建更安全的产品和服务的实践。自2008年首次共享以来，在新场景（例如云，物联网（IoT）和人工智能（AI））方面的不断积累的经验，我们对实践进行了更新。
 
 
相关文档：链接：https://pan.baidu.com/s/1NvbzczMSsEVbEjUooLiCJw 提取码：zyj5 
  
 
0x05 数据安全能力成熟度模型
 
     国标信息安全技术  数据安全能力成熟度模型 GB_T 37988-2019提出组织数据安全能力的成熟度模型架构,规定了数据采集安全、数据传输安全、数据存储安全、数据处理安全、数据交换安全、数据销毁安全、通用安全的成熟度等级要求。
 
     从数据安全过程的维度，进行划分等级，主要是5个等级：1级：非正式执行；2级：计划跟踪；3级：充分定义；4级：量化控制；5级：持续优化。
 
 
    由于各组织机构在业务规模、业务对数据的依赖性以及组织机构对数据安全工作定位等方向的差异,组织机构对模型的使用应“因地制宜”。
 
     使用模型时,组织机构应首先明确其数据安全能力的目标成熟度等级。 根据对组织机构整体的数据安全能力成熟度等级的定义,见5.3,组织机构可以选择适合自己业务实际情况的数据安全能力成熟度等级目标。 本标准定义的数据安全能力成熟度等级中,3级目标适用于所有具备数据安全保障需求的组织机构作为自己的短期目标/长期目标,具备了3级的数据安全能力则意味着组织机构能够针对数据安全的各方面风险进行有效的控制。
 
     然而,对于业务中尚未大量依赖于大数据技术的组织机构而言,数据仍然倾向于在固有的业务环节中流动,其数据安全保障的需求整体弱于强依赖于大数据技术的组织机构,因此其短期目标可先定位为2级,待达到2级的目标之后再进一步提升到3级的能力。
 
     在确定目标成熟度等级的前提下,组织机构根据数据生存周期所覆盖的业务场景挑选适用于组织机构的数据安全 PA。 例如组织机构 A 不存在数据交换的情况,因此数据交换的 PA 就可以从评估范围中剔除掉。
 
       最后,组织机构基于对成熟度模型内容的理解,识别数据安全能力现状并分析与目标能力等级之间的差异,在此基础上进行数据安全能力的整改提升计划。 而伴随着组织机构业务的发展变化,组织机构也需要定期复核、明确自己的目标成熟度等级,然后开始新一轮目标达成的工作。
 相关文档：链接：https://pan.baidu.com/s/1FcJ0bP8e6l4MYJk7gfgCzA 提取码：lrby 
 
0x06  构建安全成熟度模型 (BSIMM)
 
 构建安全成熟度模型 (BSIMM) 是一种数据驱动的模型，采用一套面对面访谈技术开展 BSIMM 评估，唯一目标就是观察和报告。企业通过参与 BSIMM 的评估，不仅可以更加具体的了解自身 SSI 的执行情况，还可以从行业视角明确所处的具体位置。
 
     BISMM 模型，是一把衡量企业在软件开发阶段构建软件安全能力的标尺。BSIMM 软件安全框架（SSF）包含四个领域 — 治理、 情报、 SSDL 触点和部署。反过来，这四个领域又包括 12 个实践模块，这 12 个实践模块中又包含 119 项 BSIMM 活动。
 
相关文档：链接：https://pan.baidu.com/s/1u2d5l9Co_8A3Vx875okuAg 提取码：hfb4
 
0x07 其他安全模型
 
著名安全博客KrebsonSecurity推荐了两个企业信息安全成熟度模型并进行了点评如下
 
1. Enterprise Strategy Group信息安全成熟度模型
 
 
ESG将企业信息安全成熟度划分为基础、进阶和高级三大类，同时为企业首席信息安全官给出了安全规划和策略路径。值得注意的是，ESG认为数据泄露等安全事故也有着积极的意义，通常重大数据泄露事故会刺激企业的信息安全成熟度提升到下一个阶段。
 
2. Blue Lava的信息安全成熟度模型
 
 
Blue lava将企业信息安全成熟度划分为“防御与处理”、“合规驱动”和“基于风险的安全方法”三大类和五个阶段：
 
第一阶段：信息安全流程缺乏组织，或者非结构化，个体的成功经验无法复制和重现，也无法扩展推广，主要原因是流程缺乏定义和文档。
 
第二阶段：信息安全进入可重现阶段，一些基本的项目管理技术成型并可重用，这基于信息安全流程已经定义、建立并文档化。
 
第三阶段：信息安全工作的重点是文档化、标准化和维护运营支持。
 
第四阶段：企业通过数据采集和分析来监控和管控自身的信息安全流程。
 
第五阶段：这是一个迭代阶段，企业通过对现有流程和新流程的监控和反馈来持续改进信息安全流程。
 
Blue Lava信息安全成熟度模型的优点是可以为所有的企业定制使用，企业可以将每个业务部门建立自己的成熟度积分体系，例如下图中的SDLC（安全开发生命周期）和PMO（项目管理部），图中红色块是企业业务部门最迫切需要提升的安全短板。
 
 
 
 
欢迎大家分享更好的思路，热切期待^^_^^ !

能力成熟度模型（Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM） 　　什么是能力成熟度模型 (Capability Maturity Model)？  CMM是指“能力成熟度模型”，是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。它是在美国国防部的指导下，由软件开发团体和软件工程学院（SEI）及Carnegie Mellon大学共同开发的。CMM的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。 　　CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。 从当今整个软件公司现状来看，最多的成熟度为1级，多数成熟度为2级，少数成熟度为3级，极少数成熟度为4级，成熟度为5级的更是凤毛麟角。 　　其所依据的想法是：只要集中精力持续努力去建立有效的软件工程过程的基础结构，不断进行管理的实践和过程的改进，就可以克服软件生产中的困难。CMM它是目前国际上最流行、最实用的一种软件生产过程标准，已经得到了众多国家以及国际软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容。 　　CMM为软件企业的过程能力提供了一个阶梯式的改进框架，它基于过去所有软件工程过程改进的成果，吸取了以往软件工程的经验教训，提供了一个基于过程改进的框架；它指明了一个软件组织在软件开发方面需要管理哪些主要工作、这些工作之间的关系、以及以怎样的先后次序，一步一步的做好这些工作而使软件组织走向成熟。
 
 
 
 
 　CMM的基本思想是，因为问题是由我们管理软件过程的方法引起的，所以新软件技术的运用不会自动提高生产率和利润率。CMM有助于组织建立一个有规律的、成熟的软件过程。改进的过程将会生产出质量更好的软件，使更多的软件项目免受时间和费用的超支之苦。  CMM实施步骤软件过程包括各种活动、技术和用来生产软件的工具。因此，它实际上包括了软件生产的技术方面和管理方面。CMM策略力图改进软件过程的管理，而在技术上的改进是其必然的结果。 　　必须牢记，软件过程的改善不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的“成熟度”等级，一个组织可按一系列小的改良性步骤向更高的成熟度等级前进。 　　成熟度等级1：初始级(Initial)。处于这个最低级的组织，基本上没有健全的软件工程管理制度。每件事情都以特殊的方法来做。如果一个特定的工程碰巧由一个有能力的管理员和一个优秀的软件开发组来做，则这个工程可能是成功的。然而通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。结果，大多数的行动只是应付危机，而非事先计划好的任务。处于成熟度等级1的组织，由于软件过程完全取决于当前的人员配备，所以具有不可预测性，人员变化了，过程也跟着变化。结果，要精确地预测产品的开发时间和费用之类重要的项目，是不可能的。 　　成熟度等级2：可重复级(Repeatable)。在这一级，有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验，故称为“可重复”。在这一级采取了一定措施，这些措施是实现一个完备过程所必不可缺少的第一步。典型的措施包括仔细地跟踪费用和进度。不像在第一级那样，在危机状态下方行动，管理人员在问题出现时便可发现，并立即采取修正行动，以防它们变成危机。关键的一点是，如没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中采取的措施也可用来为未来的项目拟定实现的期限和费用计划。 　　成熟度等级3：已定义级(Defined)。在第3级，已为软件生产的过程编制了完整的文档。软件过程的管理方面和技术方面都明确地做了定义，并按需要不断地改进过程，而且采用评审的办法来保证软件的质量。在这一级，可引用CASE环境来进一步提高质量和产生率。而在第—级过程中，“高技术”只会使这一危机驱动的过程更混乱。 　　成熟度等级4：已管理级(Managed)。一个处于第4级的公司对每个项目都设定质量和生产目标。这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离(统计质量控制措施的一个简单例子是每千行代码的错误率。相应的目标就是随时间推移减少这个量)。 　　成熟度等级5：优化级(Optimizing)。—个第5级组织的目标是连续地改进软件过程。这样的组织使用统计质量和过程控制技术作为指导。从各个方面中获得的知识将被运用在以后的项目中，从而使软件过程融入了正反馈循环，使生产率和质量得到稳步的改进。 　　整个企业将会把重点放在对过程进行不断的优化，采取主动的措施去找出过程的弱点与长处，以达到预防缺陷的目标。同时，分析各有关过程的有效性资料，作出对新技术的成本与效益的分析，并提出对过程进行修改的建议。达到该级的公司可自发的不断改进，防止同类缺陷二次出现。 　　在表中可以看出，CMM为软件的过程能力提供了一个阶梯式的改进框架，它基于以往软件工程的经验教训，提供了一个基于过程改进的框架图，它指出一个软件组织在软件开发方面需要那些主要工作，这些工作之间的关系，以及开展工作的先后顺序，一步一步的做好这些工作而使软件组织走向成熟。CMM的思想来源于已有多年历史的项目管理和质量管理，自产生以来几经修订，成为软件业具有广泛影响的模型,并对以后项目管理成熟度模型的建立产生了重要的影响。尽管已有个人或团体提出了各种各样的成熟度模型，但还没有一个象CMM那样在业界确立了权威标准的地位。但PMI于2003年发布的OPM3以其立体的模型及涵盖范围的广泛有望成为项目管理界的标准。

转载自：https://blog.csdn.net/yongchaocsdn/article/details/80893195
 
 
 
本章内容提要
 
CMMI概述
CMMI的成熟度等级及其过程域
CMMI的应用
PSP，TSP与CMMI

 
第一节 CMMI概述
 
CMMI( Capability Maturity Model Integration)即能力成熟度模型集成，由CMM (Capability Maturity Model)发展而来，它最早是应用于软件业的一个过程改进模型，为软件组织描述了从混乱的、不成熟的软件过程向成熟有序的软件过程进行改进的一条途径。后来随着应用的推广和模型本身的发展，CMMI逐渐演化成为一个被广泛应用的综合性过程改进模型。
 
1.CMMI的历史
 
1991年，美国卡耐基梅隆大学软件工程研究所（SEI）推出了能力成熟度模型CMM，CMM的作用主要有两方面：
 
为软件客户提供评价软件开发商能力的方法。
帮助软件开发商改进其软件过程，提高成熟度。
 
随着CMM在软件界应用的不断推广，其它相关学科和领域也采用它的模式，开发出了许多类似于CMM的模型。
 
SE-CMM (System Engineering CMM) 系统工程CMM，应用于系统工程管理。
SA-CMM (Software Acquisition CMM) 软件获取CMM，应用于软件获取（采购）方的能力成熟度模型。
IPD-CMM (Integrated systems product Development CMM): 集成系统产品开发CMM，应用于集成系统产品的开发管理。
P-CMM (People CMM)：人员能力成熟度模型，应用于人力资源管理。
 
为了以示区别，常把CMM叫做SW-CMM。
 
同一个组织可能会应用多个过程改进模型，但多个过程改进模型的并存可能会引起冲突和混淆。
 
CMMI为工业界和政府部门提供了一个集成的能力成熟度模型产品集，消除了不同模型之间的不一致和重复，降低了过程改进的成本。
 
CMMI覆盖了软件工程、系统工程、集成产品开发和系统采购，以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。
 
CMMI 1.0版于2000年发布，2002年又发布了1.1版，2006年发布了1.2版，2010年发布了1.3版。
 
CMMI是目前世界公认的软件产品进入国际市场的通行证。一般来说，通过CMMI认证的级别越高，就越容易获得用户的信任，在国内、国际市场上的竞争力也就越强。
 
 2000年6月，国务院颁发了《鼓励软件产业和集成电路产业发展若干政策》，其中第17条中明确规定“鼓励软件出口型企业通过CMM认证，其费用通过中央外贸发展基金适当予以支持”。随后各省市、高新区、软件园都出台了对通过CMM的企业给予资金奖励的制度。
 
2.软件过程成熟度
 
软件过程成熟度指一个具体的软件过程被明确和有效地定义、管理、度量、控制和实施的程度。
 
软件组织成熟的过程是一个不断改进、循序渐进的过程，而不是通过革命性的革新快速实现的。
 
不成熟组织与成熟组织的对比
 



 
3. CMMI中的成熟度等级
 
初始级：软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 
 
已管理级：建立了基本的项目管理过程来跟踪费用、进度和软件的功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。
 
已定义级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件。 
 
量化管理级：分析软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理活动有一个作出结论的客观依据，能够在定量的范围内预测性能。
 
优化管理级：过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 有能力识别软件过程中的薄弱环节，并有足够的手段改进它们，防止缺陷的产生。
 
CMMI是一个引导软件组织不断走向成熟的过程模型。
 





 
4.CMMI的关键过程域
 
每个成熟度等级（除了初始级）包含若干个关键过程域（Key Process Area，KPA）。
 
KPA表示当软件组织改进软件过程时必须集中精力解决的关键问题。
 
一个组织要想达到某个成熟度等级，必须满足该等级（以及较低等级）包含的KPA的所有要求，满足每个KPA的所有目标。
 




 
5.CMMI的能力等级

 
能力等级（Capability Level, CL）是指在一个单独的过程域中执行的良好程度。
 
CMMI包括6个能力等级：
 
CL0，不完整级：过程域的一个或多个目标没有被满足。
CL1，已执行级：过程通过转换可识别的输入工作产品，产生可识别的输出工作产品。能实现过程域的特定目标。
CL2，已管理级：过程作为已管理的过程被制度化。
CL3，已定义级：过程作为已定义的过程被制度化。
CL4，量化管理级：过程作为量化管理的过程被制度化。
CL5，优化级：过程作为优化的过程被制度化。

 
有关CMMI的说明
 
CMMI是什么？
 
CMMI指明该做什么，但没有指明如何做，它不是方法论，没有给出特定应用领域内的专门技术。
 
CMMI是从软件过程角度定义了成熟的软件过程的实践活动，但它并没有涉及到软件工程的所有方面，对于成熟的软件组织而言，人的因素和技术的因素也同样重要。
 
CMMI过程改进需要多长时间？有何效果？
 
统计数字表明：一般需要2年才能把成熟度提升一级（建议安排1.5年到2年）。
 
根据CMU-SEI的统计，软件企业在引入CMM后劳动生产率平均增长了35%；错误比率平均减少39%；平均成本回报率为5：1。
 
第二节 CMMI的成熟度等级及其过程域
 
2.1 初始级
 
过程
 
极少存在或使用稳定的软件过程。（过程无秩序） 
各种条例、规章制度互不协调，甚至互相矛盾。（开发无规范）   
 
人员
 
依赖个人努力和精英人物；
项目组成员的工作方式就是哪里出现危机就去哪儿解决。
 
技术
 
引进新技术是很大的风险。
 
度量
 
不收集和分析数据。
 
注意：有些组织制定了一些软件工程规范，但如果这些规范没有覆盖基本的关键过程域，且执行没有政策、资源方面的保证时，那么该组织仍然被视为处于初始级成熟度。
 
改进方向
 
建立项目管理过程，实施规范化管理，保障项目的承诺。
进行需求管理，建立客户与软件项目之间的共同理解，使项目真正反映客户的要求。
建立各种软件项目计划。如：软件开发计划、配置管理计划、风险管理计划等。
开展软件质量保证活动。

 
2.2 CMMI已管理级
 
特征：

 
进行较为现实的承诺，按以前在同类项目上的成功经验建立必要的过程准则以确保再一次成功。
 
逐个项目地建立基本过程管理条例来加强软件过程能力。
 
建立了基本的项目管理过程来跟踪成本、进度和功能，包括：需求管理、计划和跟踪监控、质量管理、配置管理、子合同管理。通过执行这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。
 
过程

 
软件开发和维护过程是相对稳定的，但过程建立在项目级别，而非企业级别。
 
软件工程过程受控于有效的工程管理过程，先前的成功经验可以被重复使用。
 
问题出现时，有能力识别并纠正，承诺可以兑现。
 
人员

 
理解管理的必要性并对管理有承诺。
 
注意人员的培训。
 
技术

 
建立技术支持活动，并有稳定的计划。
 
度量

 
有计划地收集、分析有关项目过程和产品的数据。
 
已管理级的改进方向
 
不再按项目制定软件过程，而是总结各种项目的成功经验，使之规则化，把具体经验归纳为全组织机构的标准软件过程。将改进组织机构整体软件过程能力作为软件组织的责任。
 
建立软件工程过程小组（SEPG），长期承担评估与调整软件过程的任务，以适应未来软件项目的要求。
 
积累数据：建立组织机构的软件过程库及软件过程相关的文档库。
 
加强人员培训。
 
已管理级的关键过程域
 
需求管理
项目计划
项目监督与控制
供应协议管理
过程与产品质量保证
配置管理
度量与分析

 
需求管理
 
需求管理（Requirements Management, ReqM）是指在客户和项目组之间就客户的需求建立一个协议并加以管理。该协议包括技术需求和非技术需求两个方面，它构成了整个产品生命周期中估计、计划、执行和跟踪项目活动的基础。
 
项目计划
 
项目计划（Project Planning）的目标是为实施和管理项目制定合理的计划。
 
要制定合理的计划，就要对需要完成的工作做出比较实际的估计，并为完成这些工作建立一些必要约定。
 
项目计划过程包括如下步骤：定义项目的生命周期，确定项目的范围，估计项目的规模、成本和所需资源，制定项目的进度计划，确定并评估项目风险。
 
项目监督与控制
 
项目监督与控制（Project Monitoring and control）的目标是随时掌握项目的实际开发过程，使得当项目的执行活动与计划相背离时，管理部门能采取有效的措施。
 
供应协议管理
 
供应协议管理（Supplier Agreement Management）的目标是选择合适的供应商，并对产品获取过程进行管理。
 
对软件项目来说，常需要采购一些软件或硬件产品，也有可能把项目的一部分外包给第三方来做，而采购和外包可以认为是风险最大的活动之一。
 
过程与产品质量保证
 
过程与产品质量保证（Process and Product Quality Assurance）为项目管理者提供项目过程和相关产品的适当的可见性，从而为交付高质量的产品和服务提供支持。
 
在该过程域中，产品质量评估的客观性对项目的成功是至关重要的，可以通过设立独立的质量保证组或应用一些标准来达到这种客观性。
 
质量保证工作应尽早开始，在项目初期就应制定相应的计划、标准和规程。
 
配置管理
 
配置管理（Configuration Management）是通过配置标记、配置控制、配置状态审核和配置审计来建立和维护工作产品的一致性。
 
度量与分析
 
度量与分析（Measurement and Analysis）过程域的目标是开发和维持度量能力，从而能够支持管理信息需求。
 
将度量与分析集成到项目过程中，主要有以下几方面的作用：
 
支持客观的计划和估计。
跟踪实际性能，并与计划和目标对比。
识别和解决与过程相关的问题。

 
2.3 CMMI已定义级
 
特征：
 

 
软件工程和管理方面的软件过程都已经文档化、标准化，并综合成软件开发组织的标准软件过程。
 
软件过程标准被应用到所有的项目开发和维护当中，有些项目可能要对这些标准软件过程进行裁剪。
 
对于任何项目，其生产过程、成本、计划和功能都是可以控制的，从而软件质量也可以控制。
 
软件工程过程组（SEPG）负责软件过程的定义和改进活动。
 
在全组织范围内安排培训计划。
过程
 

 
软件工程和管理活动是稳定和可重复的，具有连续性。
 
软件过程起了预见及防范问题的作用，能使风险的影响最小化。
人员
 

 
整个组织内部的所有人员对于所定义的软件过程的活动、任务有深入理解，大大增强了软件过程能力。
 
有计划地对人员角色进行培训。
技术
 

 
在定性基础上评估新技术。
度量
 

 
在全过程中收集使用数据。
 
在整个项目中系统性地共享数据。
改进方向
 

 
开始着手过程的定量分析，以达到定量控制项目过程的效果。
 
已定义级的关键过程域
需求开发
 
技术解决方案
 
产品集成
 
验证
 
确认
 
组织过程焦点
 
组织过程定义
 
组织培训
 
集成项目管理
 
风险管理
 
决策分析与解决
 
集成供应商管理
 
组织集成环境
 
集成团队
 

 
需求开发（Requirement Development）的目的是生成并分析客户、产品和产品组件的需求。
 
技术解决方案（Technical Solution）的目的是开发、设计和实现需求的解决方案。
 
产品集成（Product Integration）的目的是把产品组件组装成产品，保证产品正常工作，并把产品交付给用户。
 
验证（Verification）的目的是保证工作产品满足它们的指定需求。
 
确认（Validation）目的是展示当把产品或产品组件放到目标环境中时，它们可完成预期的用途。
 
组织过程焦点（Organizational Process Focus）过程域的目的是：在彻底理解一个组织当前过程和过程资产的弱点和优势的基础上，计划、实施和部署组织的过程改进活动。
 
组织过程定义（Organizational Process Definition）的目的是建立和维护一个组织级过程资产和工作环境标准集。
 
组织级培训（Organizational Training）的目的是增加开发人员的技能和知识，使他们可以有效地执行任务。
 
集成项目管理（Integrated Project Management）的目的是根据一个集成化的、已定义的过程来建立和管理项目，并管理利益关系人的参与，这些集成化的、已定义的过程剪裁于组织的标准过程集。
 
风险管理（Risk Management）的目的是在潜在问题发生之前识别它们，以便在产品整个生命周期中计划风险处理活动，并且必要时采取措施以缓解对目标实现的不利影响。
 
决策分析与解决（Decision Analysis and Resolution）过程域的目的是使用正式的评价过程来分析可能的决策，该评价过程是根据已制定的标准来评价可选方案。
 
2.4 CMMI量化管理级
过程
 

 
可定量地认识过程。
 
软件过程性能变化小，一般在可接受的范围内。
 
可以预见过程和产品的质量趋势，一旦度量得到的指标超出标准或有异常，可以及时采用一些措施纠正。
人员
 

 
由于每个人都了解个人的作用与组织的关系，因此能够在每个项目中产生强烈的群体意识。
技术
 

 
不断地在定量基础上评估新技术。
度量
 

 
在全组织内进行数据收集与检验。
 
度量标准化。
 
数据用于定量地理解软件过程并稳定软件过程。
改进方向
 

 
缺陷预防。不仅在发现问题时能及时改正，而且应采取特定行动防止将缺陷引入到产品中。
 
主动进行技术变动管理，标识、选择和评价新技术，使有效的新技术能在开发组织中应用。
 
进行过程变动管理。定义过程改进的目的，不断地进行过程改进。
 
量化管理级的关键过程域
 
量化项目管理（Quantitative Project Management）过程域的目的是定量管理项目的过程，从而完成项目的质量和过程性能目标。
 
组织过程性能（Organizational Process Performance）的目的是建立和维护一个对组织的标准过程集性能的定量理解，并提供过程性能数据、基线和模型来定量管理组织的项目。
 
2.5 CMMI优化管理级
过程
 

 
不断系统地改进软件过程。
 
理解并消除产生问题的公共根源，防止缺陷的产生。
人员
 

 
整个组织存在自觉的强烈的团队意识。
 
每个人都致力于过程改进。人们不再以达到里程碑的成就而满足，而要力求减少错误率。
技术
 

 
基于定量的控制和管理，事先主动考虑新技术、利用新技术。可以实现开发中的方法和新技术的革新，以防止出现错误，不断提高产品质量和生产率。
度量
 

 
利用统计数据来评估和选择过程改进。
改进方向
 

 
保持持续不断的软件过程改进。
 
优化管理级的关键过程域
 
组织革新与部署（Organizational Innovation and Deployment）的目的是选择并部署增量式和创新的改进活动，以便改进组织的过程和技术。
 
原因分析与解决（Causal Analysis and Resolution）的目的是识别缺陷和其它问题的原因，并且采取措施来预防将来再发生这些问题。
 
第三节 CMMI的应用
 
实施CMMI过程改进的两种方法
阶段表示
 
连续表示
 

 
CMMI评估
 
实施CMMI过程改进的两种方法
 
CMMI模型支持两种实施过程改进的方法，一种称为阶段表示，一种称为连续表示。
 
阶段表示（Staged Representation）为过程改进提供了一个预定义的路线图，即从成熟度等级1到成熟度等级5逐级增加，要达到某一成熟度等级，必须满足该等级（及其以下等级）上所有过程域的目标。
 
连续表示（Continuous Representation）支持单个过程域的改进，可理解为一个过程域接着一个过程域实施改进。在每个过程域上从能力等级0到能力等级5逐级增加。
 
阶段表示和连续表示的对比
 
阶段表示是从CMM模型继承而来，已经过多年的实践检验。它提供了一个明确的、被证实的过程改进路径，遵循这条路径不需要过多的讨论和争论。而且由于它的明确性和统一性，有助于进行跨组织的比较。
 
连续表示的优点是提供了灵活性。用户可根据具体的改进目标来选择需要实现的过程域及其实现次序。
 
CMMI评估
 
成熟度等级的评估由美国卡内基梅隆大学的软件工程研究所授权的主任评估师领导一个评审小组进行，其成员大部分来自企业内部。
 
评估过程包括员工培训（企业的高层领导也要参加）、问卷填写和统计、文档审查、数据分析、与企业的高层领导讨论和撰写评估报告等。评估结束由主任评估师签字生效。
 
评估结果报告给SEI。
 
一般有两种类型的评估：软件过程评估和软件能力评价。
 
软件过程评估用于确定机构当前过程的状态，决定一个机构所面临的与过程相关的问题，并且获得机构对软件过程改进的支持。
 
软件能力评价用来确定合格的软件项目承包方，或用来监督在目前的软件项目中正在进行的软件过程的状态。
 
软件过程评估方法
 
判断一个组织当前的软件过程的状态，并发现过程中的缺陷。
 
判断并确定一个组织面对的与软件过程相关的改进策略。
 
软件能力评价方法
 
判断有意承担某个软件项目的软件组织（投标者）的过程能力。
 
利用评价结果确定选择某一承包者的风险。
 
判断已进行的软件过程所处的状态是否正确或是否正常。
 
推动承包者在工作过程中改进他们的软件过程。
 
过程评估和能力评价步骤
 
挑选队伍：成员必须具有专业的软件工程和管理方面的知识，并接受过基本CMM/CMMI概念和特定评估及评价方法的训练。
 
问卷调查：让来自被评估单位的代表完成软件过程成熟度问卷并回答评估评价组提出的诊断性问题。
 
响应分析：明确哪些回答与问题的答案相吻合，并确定须进一步调查的领域。
 
现场调查：从响应分析的结果出发，评估小组进行提问、检查、协商等，以获取专业性的结论，说明软件过程的 KPA是否达到了应有的目标。
 
评估小组提供一个定义软件过程优缺点的结果清单。对于软件过程评估来说，这些结果将成为过程改进的基础和参考； 对于软件能力评价来说，这些结果为决策者提供风险分析的技术基础。
 
评估小组完成KPA基本概况的描述文件，给出组织已经满足的KPA目标和尚未满足的KPA目标。
 
软件过程评估和软件能力评价之间的不同
 
软件过程评估和软件能力评价在出发点和目标上是不同的（导致成熟度问卷调查的内容组织不一样，收集的信息不一样，结论的评价不一样）。
 
软件过程评估是在一个开放的、互相协作的环境下进行的。而软件能力评价往往是在有较大阻力的环境中进行的。（因为过程评估是为了提高管理者和工程师的工作水平，而能力评价是为了表明一个软件组织的实际软件过程能力，为选择承包者和减少费用服务）。
 
影响CMMI过程改进成败的因素
 
过程改进必须有高级主管的支持与委托，并积极地管理过程改进的进展。
 
基层技术人员的参与和支持极端重要。
 
利用定量的可观察数据尽快使过程改进的成果可见，从而激励参与者的兴趣。
 
按照软件过程改进对企业文化的要求进行变革，要求软件过程改进为商业利益服务，并与企业其他部分协调。
 
第四节 PSP，TSP与CMMI
CMM/CMMI只关注“做什么”，而不关注“怎么做”，未提供实现各过程域所需要的知识和方法。
 
    为了解决上述问题，CMU-SEI在CMM1.1基础
 
上提出了PSP/TSP。
 

 
PSP的产生
 
1995年，CMU-SEI的Watts s. Humphrey领导开发出PSP（Personal Software Processes），即个人软件过程，被认为是由定性软件工程走向定量软件工程的标志。
 
PSP是一种可用于控制、管理和改进软件工程师个人工作方式的自我改善过程，是一个包括软件开发表格、指南和规程的结构化框架。
 
PSP关注点
如何制订计划
 
如何控制质量
 
如何与其他人相互协作
 
如何预防缺陷(PSP重点)
 

 
关键是如何提高设计质量
 

 
PSP中的个人任务
为每一个项目/模块制订开发计划；
 
记录开发时间；
 
跟踪错误；
 
在工程摘要报表中保留数据；
 
使用已有的数据计划以后的项目/模块；
 
分析已有的数据以改进开发过程，不断提高开发水平。
 

 
PSP的使用效果
参加PSP培训的104位软件人员在应用了PSP后:
 

 
软件中总的差错数减少了58.0％；
 
在测试阶段发现的差错减少了71.9％；
 
生产效率提高了20.8％
 
PSP过程改进
 
 

 
PSP0（个人过程基线）
 
PSP0是过程基线，目的是为了在个人的工作中引入表格和脚本，以便工程师按照测量和报告格式记录软件过程。
 
PSP0可以通过增加三个过程而扩展到 PSP0.1：
代码规范
 
代码规模度量
 
过程优化计划 
 

 
PSP1（个人计划过程）
 
PSP1在PSP0的基础上增加了计划步骤：
规模估计：分为代码规模估算、时间估算、资源估算。
 
状态报告：对软件工程师的工作进行跟踪，检查规模估计与实际状态之间的差异。
 

 
PSP1.1又在PSP1的基础上引入了任务计划和安排。
 
PSP2（个人质量管理）
 
PSP2强调提高质量，引入了缺陷管理，包含了代码审查和设计审查。
 
PSP2.1在PSP2.0基础上增加了设计模板。
 
PSP3（循环个人过程）
 
PSP3将个人软件过程的应用拓展到大规模程序开发当中。
   将开发大型程序的个体过程细分为可以应用PSP2的片段，遵照PSP2过程循环增量地开发大型程序，从而支持迭代式的开发。在任何时间点，只有一个PSP2级过程是活动的。
 

 

 
TSP
 
软件开发通常是以团队形式进行的，因此仅有PSP是不够的。CMU-SEI又以PSP为基础，开发了TSP（Team Software Processes），即小组软件过程。
 
TSP指导项目组中的成员如何有效规划和管理所面临的项目开发任务，并且使软件开发队伍始终以最佳状态来完成工作。
 
TSP实施集体管理与自我管理相结合的原则，最终目的在于指导开发人员如何在最少的时间内，以预定的费用生产出高质量的软件产品，所采用的方法是对小组开发过程进行定义、度量和改进。
 
小组远不只是一群有才能的个人的集合。为了建立并保持高效率的工作关系，小组需要共同的目标，大家一致同意的行动计划和适当的领导，小组成员要在需要的时候乐于寻求帮助。
 
TSP实施条件
 
需要有高层主管和各级经理的支持，以取得必要的资源。
 
整个软件开发小组至少应在CMMI的第二级（已管理级）。
 
全体软件开发人员必须经过PSP的培训，并有按TSP工作的愿望和热情。
 
开发小组成员应在2到20个人之间。经验表明，4~8个人的小组工作效率最高。
 
TSP的管理原则
 
TSP遵循集体管理和自己管理自己相结合的原则。
在每一项目阶段开始要作好工作计划。
 
要有明确定义的目标，努力完成已经接受的委托任务。
 
应定期追踪项目进展状态并进行定期汇报。
 
按自己管理自己的原则管理软件过程。
 
按集体管理的原则进行管理，全体成员都要参加和关心小组工作的规划、进展的追踪和决策的制订等项工作。
 

 
TSP的循环开发策略
 
TSP通过循环开发策略完成产品。先在第一个周期中开发出最小的合理产品，再决定在接下来的每一个周期中要加进去的功能。这样的步骤可以保证得到一系列最终产品的可运行的前期版本。每个周期包括7个步骤：决定策略、进行计划、考虑需求、设计、实现、测试和最终检查。
 
TSP度量要素
 
对软件开发小组进行度量的基本要素：
所编文档页数；
 
所编代码行数；
 
花费在各个开发阶段或各个开发任务上的时间；
 
在各个开发阶段中注入和改正的差错数目；
 
在各个阶段对最终产品增加的价值。
 

 
TSP有关质量度量的经验原则：
软件设计时间应大于软件实现时间；
 
设计评审时间至少应占一半以上的设计时间；
 
代码评审时间应大于编制代码的时间；
 
每千行源程序在编译阶段发现的差错不应超过10个；
 
每千行源程序在测试阶段发现的差错不应超过5个。
 

 
PSP、TSP与CMMI之间的关系
 
PSP、 TSP 和CMMI为软件产业提供了一个集成化的、三维的软件过程改进框架。
 
PSP注重于个人的技能，能够指导软件工程师保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过PSP的学习和实践，软件工程师们能够在他们参与的项目中更为高效和高质量地完成工作，从而保证了项目整体的进度和质量。
 
TSP注重团队的高效工作和产品交付能力，结合PSP的工程技能，使软件工程师将个体过程结合进小组软件过程，并通过指导管理层如何支持和授权项目小组，坚持团队的高质量的工作，并且依据数据进行项目管理，以达到生产高质量产品的目的。
 
CMMI注重于组织能力和成熟度的提高，它提供了评价组织的能力、改进组织过程的管理方式，比TSP具有更高的层次。
 
CMMI关注“做什么”，PSP和TSP则提供了“怎么做”。
 
本章小结
理解软件过程和过程管理的概念以及两者的联系。
 
了解CMMI的发展历史。
 
理解软件过程成熟度概念和CMMI的各成熟度等级的特征。
 
了解CMMI各成熟度等级上的关键过程域。
 
理解CMMI的两种应用方式。
 
了解PSP，TSP的特征以及它们与CMMI的关系。
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 











 


 

 

CMM 是对软件组织进化阶段的描述，随着软件组织定义、实施、测量、控制和改进其软件过程。
基于CMM模型的产品包括一些诊断工具，可应用于软件过程评价和软件能力评估小组，以确定一个机构的软件过程实力、弱点、风险。最著名的是成熟度调查表。软件过程评价及软件能力评估的方法也依赖于CMM模型。
 
CMM成熟度级别
一、初始级
软件过程是无序的，甚至是混乱的，没有什么是经过定义的，项目成功的完成完全依赖个人的努力和核心人物的作用。
提高：建立项目过程管理，建立计划。
 
二、可重复级
建立基本的项目管理过程和实践去跟踪项目成本、进度、质量，必要的过程准则可以重复类似项目的成功。
提高：引入需求管理、项目管理（包括项目跟踪和监控）、子合同管理、软件配置管理和质量管理（包括质量量化和监控）。
 
三、已定义级
软件已经文档化、标准化、并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护。
提高：组织过程定义、焦点，培训大纲，软件集成管理，组织协调，专家评审等。
 
四、已管理级
制定了软件过程和产品质量的详细度量标准。软件质量都被开发组织人员所理解和控制。
提高：定量的软件过程管理和产品质量管理，防止和规避缺陷的能力，技术革新能力，过程不断改进。
 
五、优化级
加强了定量分析，通过质量反馈和新技术的反馈过程不断持续的改进。
提高：缺陷预防管理（包括预防和应对容灾措施）、过程变更管理（工作流）和技术变更管理。