CMM1.1中文-18个关键过程域.doc

CMM等级2的关键过程域 组织机构和角色 CMM力图不依赖任何特定的组织机构和模型，但是在阐述CMM的实践时必须一致地使用与某种组织机构和角色有关的术语，而它们可能不同于任何具体组织所用的组织机构和角色。以下几节描述在解释CMM关键实践时所必需的与组织、项目及角色有关的各种概念。 2.1 需求管理 　　需求管理的目的是在顾客和将处理顾客需求的软件项目之间建立对顾客需求的共同理解。 　　需求管理包括和顾客一起建立和维护有关软件项目需求的协议，该协议称作“分配给软件的系统需求”。“顾客”可解释为系统工程组、销售组、另一个内部组织、或者一个外部顾客。协议既包括技术需求、又包括非技术需求（例如交付日期）。该协议形成估计、策划和跟踪整个软件生存周期内软件项目活动的基础。 　　将系统需求分配给软件、硬件和其它系统成分的工作可能由软件工程组之外的组（例如系统工种组）完成，软件工种组可能对此分配无直接控制，在项目约束范围内，软件工程组采取恰当步骤以保证对分配给软件的需求建档、并加以控制，该组负责处理分配给软件的系统需求。 　　为实现此控制，软件工种组评审初始的和经修改的分配给软件的系统需求，以便在它们被纳入软件项目之前使问题得以解决。每当改变分配给软件的系统需求时，都要调整受到影响的软件计划，工作产品和活动，使其与更新后的需求保持一致。 目标 目标1 分配给软件的系统需求是受控的，建立供软件工程和管理使用的基线。 目标2 　　软件计划、产品和活动与分配给软件的系统需求保持一致。 执行约定 约定1 项目遵循一书面的、组织上的方针去管理分配给软件的系统需求。 　　在这些实践中，分配给软件的系统需求称为“分配需求”（allocated requirements）。分配需求是系统需求的子集，它将用系统的软件成分来实现。分配需求是软件开发计划的主要输入。软件需求分析详细描述和提炼分配需求，并生成文档化的软件需求。 该方针一般规定： 　　1．对分配需求建立文档。 　　2．由下列人员评审分配需求： 　　　　—— 软件经理，和 　　　　—— 其它受到影响的组。 　　受到影响的组的例子有： 　　　　—— 系统测试组， 　　　　—— 软件工程组（包括所有小组，例如软件设计小组）， 　　　　—— 系统工程组， 　　　　—— 软件质量保证组， 　　　　—— 软件配置管理组，和 　　　　—— 文档支持组。 　　3. 更改软件计划工作产品和活动，以便和分配需求的改变保持一致。 执行能力 能力1 对每个项目，建立分析系统需求并将其分配到硬件、软件和其它系统成分的职责。 　　分析和分配系统需求不是软件工程组的职责，而是他们工作的先决条件。 　　该职责包括： 　　1．在项目整个生存期内，管理系统需求和它们的分配，并对其建立文档。 　　2．实现对系统需求及其分配的更改。 能力2 对分配需求建立文档。 　　分配需求包括： 　　1．影响和确定软件项目活动的非技术性需求（即：协议、条件、和（或）合同条款）。 　　协议、条件和合同条款的例子包括： 　　　　—— 要交付的产品， 　　　　—— 交付日期，和 　　　　—— 里程碑。 　　2．对软件的技术需求。 　　技术需求的例子有： 　　　　—— 最终用户、操作员、支持、或集成功能； 　　　　—— 性能要求： 　　　　—— 设计约束； 　　　　—— 编程语言；和 　　　　—— 界面需求。 　　3．用于确认软件产品满足分配需求的验收准则。 能力3　 　提供足够的用以管理分配需求的资源和投资。 　　1．指派在应用领域和软件工程方面有验和技能的个人去管理分配需求。 　　2．使得支持管理需求活动的工具是可用的。 　　支持工具的例子有： 　　　　—— 电子表格程序， 　　　　—— 配置管理工具，和 　　　　—— 跟踪工具， 　　　　—— 测试管理工具。 能力4 软件工程组和其它软件一有关组的成员受到培训以便完成他们的需求管理活动。 　　培训的例子包括： 　　项目所使用的方法、标准、规程 　　应用领域。 执行的活动 活动1 在分配需求被纳入软件项目之前，软件工程组评审它们。 　　1．鉴别出不完整的和遗漏的分配需求。 　　2．评审分配需求，确定它们是否： 　　　　—— 用软件来实现是可行的和恰当的， 　　　　—— 被清晰和正确地阐述， 　　　　—— 是相互一致的，和 　　　　—— 是可测试的。 　　3．负责分析和分配系统需求的组评审任何被识别出是有潜在问题的分配需求，并作出必要的更改。 　　4．和受到影响的组协商由分配需求引起的约定。 　　受到影响的组的例子包括： 　　　　—— 软件工程组（包括所有的小组，例如软件设计小组）， 　　　　—— 软件估计组， 　　　　—— 系统工程组， 　　　　—— 软件质量保证组， 　　　　—— 软件配置管