软件过程

•    软件过程指软件生存周期中的一系列相关的过程。过程是活动的集合，活动是任务的集合

•    软件过程有三层含义

Ø  个体含义，即指软件产品或系统在生存周期中的某一类活动的集合，如软件开发过程，软件管理过程等

Ø  整体含义，即指软件产品或系统在所有上述含义下的软件过程的总体

Ø  工程含义，即指解决软件过程的工程，它应用软件工程的原则、方法来构造软件过程模型，并结合软件产品的具体要求进行实例化，以及在用户环境下的运作，以此进一步提高软件生产率，降低成本

•    GB/T 8566-2007标准把软件生存周期中可以开展的活动分为5个基本过程，9个支持过程和7个组织过程。每一个过程划分为一组活动，每项活动进一步划分为一组任务

  基本（primary）过程供各参与方在软件生存周期期间使用。包括：

•    获取（acquisition）过程：为获取系统、软件产品或软件服务的组织即需方而定义的活动

•    供应（supply）过程：为向需方提供系统、软件产品或软件服务的组织即供方而定义的活动

•    开发（development）过程：为定义并开发软件产品的组织即开发方而定义的活动

•    运作（operation）过程：为在规定的环境中为其用户提供运行计算机系统服务的组织即操作方而定义的活动

•    维护（maintenance）过程：为提供维护软件产品服务的组织即维护方而定义的活动

   支持（supporting）过程用于支持其他过程，它有助于软件项目的成功和质量提高。包括：

•    文档编制（documentation）过程： 为记录生存周期过程所产生的信息而定义的活动

•    配置管理（configuration management）过程： 定义配置管理活动

•    质量保证（quality assurance）过程：为客观地保证软件产品和过程符合规定的需求以及已建立的计划而定义的活动

•    验证（verification）过程：根据软件项目需求，按不同深度验证软件产品而定义的活动

•    确认（validation）过程：确认软件项目的软件产品而定义的活动

•    联合评审（joint review）过程：为评价一项活动的状态和产品而定义的活动

•    审核（audit）过程：为判定符合于需求、计划和合同而定义的活动

•    问题解决（problem resolution）过程：为分析和解决问题而定义的活动

•    易用性（usability）过程：为易用性专业人员而定义的活动

  组织（organizational）过程用于软件组织建立和实现由相关的生存周期过程和人员组成的基础结构，并不断改进这种结构和过程。包括：

•    管理（management）过程：为生存周期过程中的管理包括项目管理而定义的基本活动

•    基础设施（infrastructure）过程：为建立生存周期过程基础结构而定义的基本活动

•    改进（improvement）过程: 为某一组织建立、测量、控制和改进其生存周期过程而定义需要执行的基本活动

•    人力资源（human resources）过程: 为给组织或项目提供拥有技能和知识的员工而定义的活动

•    资产管理（asset management）过程：为组织的资产管理者而定义的活动

•    复用大纲管理（reuse program management ）过程：为组织的复用大纲主管而定义的活动

•    领域工程（domain engineering）过程: 为领域模型、领域体系结构的确定及该领域资产的开发和维护而定义的活动

GB/T 8566-2007为软件生存周期过程建立了一个公共框架，它提供了一组标准的过程、活动和任务。对于一个软件项目，可根据其具体情况对标准的过程、活动和任务进行剪裁，即删除不适用的过程、活动和任务

GB/T 8566-2007标准的附录A中的剪裁（tailoring）过程规定了在针对该标准进行剪裁时所需要的基本活动，包括：标识项目环境；请求输入；选择过程、活动和任务；将剪裁决定和理由形成文档

附录B就剪裁要点提供简要说明，并列出一些关键要素，可以根据这些要素作出剪裁决定

•    ISO/IEC 12207-2008标准对ISO/IEC 12207-1995作了很大的改动，该标准将软件生存周期中的过程分成两大类，7个过程组，43个过程

•    第一类过程称为系统周境过程（system context processes）：这类过程处理独立的软件产品、服务或软件系统的系统周境

•    第二类过程称为软件特定过程（software specific processes）：用于实现一个软件产品或者大型系统中的某一服务

•    系统周境过程包括以下4个过程组，25个过程

–  协定过程组：获取过程、供应过程

–  组织级项目使能（启用）过程组：生存周期模型管理过程、基础设施管理过程、项目投资管理过程、人力资源管理过程、质量管理过程

–  项目过程组：项目计划管理过程、项目评估和控制过程、决策管理过程、风险管理过程、配置管理过程、信息管理工程、测量过程

–  技术过程组：利益相关方需求定义过程、系统需求分析过程、系统体系结构设计过程、实现过程、系统集成过程、系统合格性测试过程、软件安装过程、软件验收支持过程、软件运作过程、软件维护过程、软件废弃（处置）过程

•    软件特定过程包括以下3个过程组，18个过程

–  软件实现过程组：软件实现过程、软件需求分析过程、软件体系结构设计过程、软件详细设计过程、软件构造过程、软件集成过程、软件合格性测试过程

–  软件支持过程组：软件文档管理过程、软件配置管理过程、软件质量保证过程、软件验证过程、软件确认过程、软件评审过程、软件审核过程、软件问题解决过程

–  软件复用过程组：领域工程过程、复用资产管理过程、复用程序管理过程

CMM（CapabilityMaturity Model）即能力成熟度模型，是美国卡内基梅隆大学软件工程研究所（SEI）在美国国防部资助下于二十世纪八十年代末建立的，用于评价软件机构的软件过程能力成熟度的模型。此模型在建立和发展之初，主要目的在于提供一种评价软件承接方能力的方法，为大型软件项目的招投标活动提供一种全面而客观的评审依据。而发展到后来，又同时被软件组织用于改进其软件过程

1. 不成熟的软件组织

•    软件过程一般并不预先计划，而是在项目进行中由实际工作人员及管理员临时计划

•    有时，即使软件过程已计划好，仍不按计划执行

•    没有一个客观的基准来判断产品质量，或解决产品和过程中的问题

•    对软件过程步骤如何影响软件质量，一无所知，产品质量得不到保证。而且，一些提高质量的环节，如检查、测试等经常由于要赶进度而减少或取消

•    产品在交付前，对客户来说，一切都是不可见的

•    没有长远目标，管理员通常只关注解决任何当前的危机

•    由于没有实事求是地估计进度、预算，因此他们经常超支、超时。当最后期限临近，他们往往在功能性和质量上妥协，或以加班加点方式赶进度

2. 成熟的软件组织

•    具有全面而充分的组织和管理软件开发和维护过程的能力

•    管理员监视软件产品的质量以及生产这些产品的过程

•    制定了一系列客观基准来判别产品质量，并分析产品和过程中的问题

•    进度和预算可以按照以前积累的经验来制定，结果可行。预期的成本、进度、功能与性能和质量都能实现，并达到目的

•    能准确及时地向工作人员通报实际软件过程，并按照计划有规则地(前后一致，不互相矛盾)工作

•    凡规定的过程都编成文档

•    软件过程和实际工作方法相吻合。必要时，过程定义会及时更新，通过测试，或者通过成本-效益分析来改进过程

•    全体人员普遍地、积极地参与改进软件过程的活动。在组织内部的各项目中，每人在软件过程中的职责都十分清晰而明确，每人各守其责，协同工作，有条不紊，甚至能预见和防范问题的发生

CMM提供了一个成熟度等级框架：

•     1级-初始级

•     2级-可重复级

•     3级-已定义级

•     4级-已管理级

•     5级-优化级

1.初始（initial）级：

  软件过程的特点是无秩序的，甚至是混乱的。几乎没有什么过程是经过妥善定义的，成功往往依赖于个人或小组的努力

2.可重复（repeatable）级：

  建立了基本的项目管理过程来跟踪成本、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功

3.已定义（defined）级：

  己将管理和工程活动两方面的软件过程文档化、标准化，并综合成该机构的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件

4.已管理（managed）级：

  收集对软件过程和产品质量的详细度量值，对软件过程和产品都有定量的理解和控制

5.优化（optimizing）级：

  整个组织关注软件过程改进的持续性、预见及增强自身，防止缺陷及问题的发生。过程的量化反馈和先进的新思想、新技术促使过程不断改进

•    能力成熟度模型的结构

•    成熟度等级表明了一个软件组织的过程能力的水平。除初始级外，每个成熟度等级都包含若干个关键过程域（Key Process Area，简称KPA）（见表1.2）

•    达到某个成熟度级别，该级别（以及较低级别）的所有关键过程域都必须得到满足，并且过程必须实现制度化。

•     CMM提供了18个关键过程域，每个关键过程域都有一组对改进过程能力非常重要的目标，并确定了一组相应的关键实践

•     目标说明了每一个关键过程域的范围、界限和意义

•     关键实践描述了建立一个过程能力必须完成的活动和必须具备的基础设施，完成了这些关键实践就达到了相应关键过程域的目标，该关键过程域也就得到了满足

•    每个关键过程域的关键实践都是按照五个共同特性（执行约定，执行能力，执行活动，测量和分析，验证实现）进行组织的，主要解决关键实践的实施或制度化问题

•     共同特性描述关键过程域的关键实践按共同特性进行组织。共同特性是一些属性，指明一个关键过程域的执行和规范化是否有效、可重复和可持续。共有5个共同特性: 执行约定，执行能力，执行活动，测量和分析，验证实现。

Ø  执行约定：

  执行约定描述机构为确保过程的建立和持续而必须采取的一些措施。典型内容包括建立机构策略和领导关系。

Ø  执行能力：

  执行能力描述了项目或机构完整地实现软件过程所必须有的先决条件。典型内容包括资源、机构结构和培训

Ø  执行活动：

  执行活动描述了执行一个关键过程域所必需的活动、任务和规程。典型内容包括制定计划和规程、执行和跟踪以及必要时采取纠正措施

Ø  测量和分析：

  测量和分析描述了为确定与过程有关的状态所需的基本测量实践。这些测量可用来控制和改进过程。典型内容包括可能采用的测量实例

Ø  验证实现：

  验证实现描述了为确保执行的活动与已建立的过程一致所采取的步骤。典型内容包括管理部门和软件质量保证组实施的评审和审核

在执行活动这个共同特性中的实践描述了建立一个过程能力所必须完成的活动。所有其他实践共同形成了一个使机构能将执行活动中描述的实践进行规范化的基础

各关键过程域的详细描述，参见《能力成熟度模型（CMM）：软件过程改进指南》，卡耐基梅隆大学软件工程研究所编著，刘孟仁等译，电子工业出版社出版

关键过程域实例

机构过程焦点

第3级的关键过程域：已定义级

  机构过程焦点的目的是，为能改进机构整体软件过程能力的软件过程活动建立机构的职责。

   机构过程焦点包括，建立和维护机构软件过程和项目软件过程的默契关系，并协调有关评估、开发、维护和改进这些过程的活动。

   机构提供长期的约定和资源，以协调现在和将来的软件项目的软件过程的开发和维护。该项工作由某个小组实施，例如软件工程过程组。它负责机构的软件过程活动，特别是负责开发和维护机构标准软件过程和相关过程资源（如在机构过程定义关键过程域中说明的），并协调软件项目的过程活动。

目标

目标1：机构内部软件过程的制定和改进活动协调一致。

目标2：相对于过程标准，所使用的软件过程的优势和薄弱环节标识清楚。

目标3：机构级的过程开发和改进活动有计划。

执行约定

约定1：机构遵循书面的管理策略，协调整个机构范围内的软件过程开发和改进活动。

   该策略一般规定:

    1. 建立一个小组，负责机构级的软件过程活动，使这些活动与各项目协调一致。

    2. 定期评估项目所使用的软件过程，以确定其优势和薄弱环节。

    3. 对机构标准软件过程进行合理地剪裁，以得到项目使用的软件过程。

   关于机构标准软件过程，参见综合软件管理关键过程域的活动1。

    4. 每个项目的软件过程、工具和方法的改进和其他有用信息，可用于其他项目。

约定2：上级管理部门倡导和支持机构的软件过程开发和改进活动。

    上级管理部门：

    1. 向机构成员和负责人说明有关软件过程活动的约定。

    2. 制定资金、人员配备和其他资源的长期计划和约定。

    3. 制定管理和执行有关软件过程开发和改进活动的策略。

约定3：上级管理部门监督机构的软件过程开发和改进活动。

     l. 确保机构标准软件过程满足企业目标和策略。

    2. 提出关于软件过程开发和改进活动优先次序的建议。

    3. 参与制定软件过程开发和改进计划。

        a. 上级管理部门与更高层人员和负责人共同协调软件过程需求及问题

        b. 上级管理部门与该机构负责人进行协调，以获得负责人和机构成员的支持和参与

执行能力

能力1：有一个负责机构的软件过程活动的小组。

     一个小组是一些部门、负责人和人员的组合，负责一组任务和活动。小组的规模可以不同，既可以是单个兼职的人，也可以是多个来自不同部门的兼职人员，也可以由几个专职人员组成。组成小组时考虑的因素包括：分派的任务和活动、项目规模、机构结构和机构文化。某些小组，如软件质量保证组，集中关注项目活动;而其他一些小组，例如软件工程过程组，集中关注机构范围内的活动。

    1. 条件可能时，小组成员以专职工作的软件专业人员为核心，并尽可能有其他的兼职人员支持。

    该小组最一般的例子是软件工程过程组（SEPG）。

    2. 小组成员中有软件工程及软件相关科目的代表。

         软件工程及软件相关科目的实例有：

•    软件需求分析

•    软件设计

•    程序编码

•    软件测试

•    软件配置管理

•    软件质量保证

能力2：为实施机构的软件过程活动提供了充足的资源和资金。

   1. 委派在特定领域具有特长的人员支持该小组。

       特定领域的实例有：

•    软件重用

•    计算机辅助软件工程技术(CASE)

•    测量

•    培训课程开设

   2. 有支持该机构软件过程活动的工具。

       支持工具的实例有：

•    统计分析工具

•    桌面出版工具

•    数据库管理系统

•    过程建模工具

能力3：负责机构软件过程活动的小组成员接受过实施这些活动所需的培训。

       培训的实例有：

•    软件工程实践

•    过程控制技术

•    机构过程变动管理

•    软件过程计划、管理和监督

•    技术转变

参见培训大纲关键过程域

能力4：软件工程组和其他软件相关小组的成员接受过机构软件过程活动及其在这些活动中的任务方面的定向培训。

     参见培训大纲关键过程域

执行活动

活动1：定期评估软件过程，并根据评估结果制定行动计划。

     评估一般每隔一年、一年半至三年进行一次。评估可针对机构中所使用的所有软件过程，也可通过对过程和项目进行抽样评估。评估机构软件过程能力的方法实例之一是SEI软件过程评估方法。

      行动计划标识：

•    涉及哪些评估结果

•    针对评估结果实施更改软件过程的准则

•    负责实施更改的小组或个人

活动2：机构制定和维护它的软件过程开发和改进活动的计划。

       该计划：

1. 1. 以软件过程评估后的行动计划和其他的机构过程改进倡议为基础。
   2. 确定要实施的活动及实施这些活动的进度。
   3. 确定负责这些活动的小组和个人。
   4. 确定所需的资源，包括人员配备和工具。
   5. 初始发布和有大改动时通过同行评审。

        参见同行评审关键过程域。

    6.  机构的软件负责人和上级负责人评审认可。

活动3：在机构级协调关于机构和项目的软件过程的开发和改进活动。

      涉及的软件过程有：

      1.  机构标准软件过程。

      关于机构标准过程，参见机构过程定义关键过程域的活动1和活动2。

      2.  项目定义的软件过程。

      关于项目定义的软件过程。参见综合软件管理关键过程域的活动1和活动2。

活动4：在机构级协调有关软件过程数据库的使用。

      机构的软件过程数据库用来收集机构和项目的软件过程以及生成的软件产品的信息。

      关于机构的软件过程数据库，参见机构过程定义关键过程域的活动5。

活动5：监控和评价机构中限制使用的新过程、方法和工具。合适时，推广到机构的其他部分。

活动6：在机构内协调机构和项目的软件过程的培训。

       1.  制定有关机构和项目软件过程的专题培训计划。

       2. 合适时，培训由负责机构软件过程活动的小组（如软件工程过程组）或培训小组准备和实施。

       参见培训大纲关键过程域。

活动7：向与实施软件过程有关的小组通报机构和项目中软件过程开发和改进活动的情况。

       通报方式的实例有：

•    过程电子公告板

•    过程咨询委员会

•    工作小组

•    信息交流会

•    调查

•    过程改进组

•    日常讨论

测量和分析

测量1：测量机构的软件过程开发和改进活动的状态

       测量的实例有：

•    机构在过程评估、开发和改进活动中已完成的工作、工作量和耗费的资金，与计划相比较

•    每次软件过程的评估结果，与以前的评估结果和建议相比较

验证实现

验证1：上级管理部门定期评审软件过程开发和改进活动。

   上级管理部门实施定期评审的主要目的是适当地、及时地掌握软件过程活动。在满足机构需求的前提下，只要有适当的机制来报告异常情况，评审的时间间隔就尽可能长些。

      1. 对照计划，评审有关开发和改进软件过程活动的进展和状态。

      2. 讨论低层不能解决的冲突和问题。

      3. 指定和评审行动措施，并跟踪到关闭。

      4. 编写评审的总结报告，并分发给相关的小组和个人。

•    CMM的成功导致了各种模型的衍生，每一种模型都探讨了某一特定领域中的过程改进问题

Ø  SW-CMM：适用于软件开发

Ø  SE-CMM：系统工程能力成熟度模型

Ø  SA-CMM：适用于软件获取

Ø  SECAM：系统工程能力评估模型

Ø  People CMM：讨论软件组织吸引、开发、激励、组织和留住人才的能力

Ø  EIA/IS 731：替代SW-CMM和SECAM

Ø  IPD-CMM：适用于集成化产品开发

Ø  FAA-iCMM：集成了SE-CMM、 SA-CMM、SW-CMM

Ø  相应的国际标准：ISO/IEC 12207（软件生存周期过程）、ISO/IEC 15288（系统生存周期过程）、ISO/IEC 15504（软件过程评估）

•    模型的繁衍导致模型框架、术语等方面的矛盾和不一致

•    包含在当代工程中各种各样的学科和工程是密切交叉在一起的，应用不同模型时效率低下且容易混淆，常常要付出极其昂贵的代价

•    美国国防部、美国国防工业委员会和SEI/CMU于1998年启动CMMI项目，希望CMMI是若干过程模型的综合和改进，是支持多个工程学科和领域的系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率

•    2000年发布第一个CMMI模型CMMI-SE/SW/IPPDV1.0：集成了SW-CMM、EIA/IS 731、IPD CMM V0.98

•    2002年1月发布CMMI-SE/SW/IPPDV1.1

•    CMMI模型为每个学科的组合都提供两种表示法

Ø  阶段式模型

Ø  连续式模型

阶段式模型

•    阶段式模型的结构类同于软件CMM，它关注组织的成熟度，其成熟度等级如下图所示

阶段式模型的成熟度等级结构

•    CMMI V1.1的24个过程域的分组如下：

成熟度等级	过程域
已管理的	需求管理REQM，项目计划PP，项目监督和控制PMC，供应商合同管理SAM，度量和分析MA，过程和产品质量保证PPQA，配置管理CM
已定义的	需求开发RD，技术解决方案TS，产品集成PI，验证VER，确认VAL，组织级过程焦点OPF，组织级过程定义OPD，组织级培训OT，集成化项目管理IPM，风险管理RSKM，集成化建组IT，决策分析和解决方案DAR，组织级集成环境OEI
定量管理的	组织级过程性能OPP，项目定量管理QPM
优化的	组织级改革和实施OID，因果分析和解决方案CAR

连续式模型

•    连续式模型关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级（Capability level，CL）。

•    CMMI中包括六个过程域能力等级，等级号为0～5。能力等级表明了单个过程域中组织执行的好坏程度。

•    允许组织对连续式模型的过程域进行剪裁，也允许对不同的过程域采用不同的能力等级

•    下图给出了某组织的过程域能力等级

•    能力等级包括共性目标及相关的共性实践，这些实践在过程域内被添加到特定目标和实践中。当组织满足过程域的特定目标和共性目标时，就说该组织达到了那个过程域的能力等级。

•    能力等级2～5的的名字与成熟度等级2～5同名，但含义不同。能力等级可以独立地应用于任何单独的过程域，任何一个能力等级都必须满足比它等级低的能力等级的所有准则，各能力等级的含义简述如下：

•    CL0 未完成的：过程域未执行或未达到CL1中定义的所有目标

•    CL1 已执行的：其共性目标是过程将可标识的输入工作产品转换成可标识的输出工作产品，以实现支持过程域的特定目标

•    CL2 已管理的：其共性目标集中于已管理的过程的制度化。 根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制和评审

•    CL3  已定义的：其共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对该过程的改进上

•    CL4  定量管理的：其共性目标集中于可定量管理的过程的制度化。使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则

•    CL5  优化的：使用量化（统计学）手段改编和优化过程域，以对付客户要求的改变和持续改进计划中的过程域的功效

•    连续式模型将24个过程域划分为过程管理、项目管理、工程和支持四个过程组：

连续式分组	过程域
过程管理	组织级过程焦点OPF，组织级过程定义OPD，组织级培训OT，组织级过程性能OPP，组织级改革和实施OID
项目管理	项目计划PP，项目监督和控制PMC，供应商合同管理SAM，集成化项目管理IPM，风险管理RSKM，集成化建组IT，项目定量管理QPM
工  程	需求管理REQM，需求开发RD，技术解决方案TS，产品集成PI，验证VER，确认VAL
支  持	配置管理CM，过程和产品质量保证PPQA，度量和分析MA，决策分析和解决方案DAR，组织级集成环境OEI，因果分析和解决方案CAR