计算机软件项目管理国际标准.ppt

第13章 国际标准,退出,13.1 IEEE1058.1软件项目管理计划标准13.2 ISO9000质量标准13.3 ISO/IEC 12207软件生命周期过程标准13.4 ISO/IEC TR 15504软件过程评估标准13.5 能力成熟度模型13.6 小结,13.1 IEEE1058.1软件项目管理计划标准,13.1.1 软件项目管理计划的组成 一个软件项目管理计划主要由三部分组成：要做的工作，要用的资源，要花的经费。软件开发需要各种资源，主要资源有：开发软件的人员，运行软件所需要的硬件和支持软件(例如，操作系统和版本控制软件)。对资源的使用将随着时间变化。在大型项目中，资源消耗Rc随时间t的变化可以用Rayleigh分布近似表示：,其中，k是一个常数，e是自然对数的底。当时间t=k时，所需要的资源量达到峰值。典型的Rayleigh曲线如图13.1所示。,管理工作分成两类。一类工作贯穿于项目全过程，不与软件开发的特定阶段相关联，这类工作称为项目职责，例如，项目管理和质量控制。另一类工作与产品开发的特定阶段相联系，这类工作称为活动或任务。一个活动是一个大的工作单元，有它的开始时间和结束时间；它消耗资源，例如消耗计算机时间和人力；它产生工作产品，例如预算、进度表、设计文档、源代码或用户手册。一项活动又包含一系列任务，一个任务是应该管理的最小工作单元。因此，在项目管理中有三种工作，分别是项目职责、活动(大工作单元)和任务(小工作作单元)。项目管理将贯穿于整个项目开发的始终。,计划中的关键内容涉及工作产品的完成情况。工作产品预定完成的日期称为“里程碑”。为了确定一件工作产品是否真正到达了一个里程碑，必须通过一系列由开发组成员、管理部门和客户代表进行的审查。一个典型的里程碑是完成概要设计并且通过了审查的日期。一旦一个工作产品经过审查并被一致通过，它就成为一个基线。只有经过12.3.2中描述的正式过程才能修改基线。,图13.1 资源消耗随时间变化,资金当然是软件项目计划的一个关键组成部分，必须拟定出详细的资金预算和资金分配方案。资金分配应该针对每个项目职责和活动，它是时间的函数。,13.1.2 IEEE软件项目管理计划 1.引言 这部分由5个小部分组成，描述了要开发的项目和产品的概况。(1)项目概览 简要地描述项目目标、要交付的产品、有关活动及其工作产品。此外，还要列出里程碑、所需的资源、主要的进度以及主要预算。(2)项目交付 列出所有要交付给客户的软件配置项和交付的日期。,(3)软件项目管理计划的演变 没有什么计划能一成不变地执行。软件项目管理计划和其他计划一样，必须随着经验的积累以及客户方与开发方的变化而变化。在这部分描述改变计划的正式规程和机制。(4)参考资料 在这部分列出软件项目管理计划引用的所有参考文档。(5)术语定义和缩写词 这些信息确保每个人都能以同样方式理解软件项目管理计划。,2.项目组织 这部分中的4个小部分，从软件过程的角度和开发者的组织结构的角度，说明了产品是怎样开发的。(1)过程模型 根据活动(例如，产品设计或产品测试)和项目职责(例如，项目管理或配置管理)来确定过程模型。过程模型的关键内容有里程碑、基线、评审、工作产品以及可交付性。(2)组织结构 描述开发组织的管理结构。在组织中划定权限和明确责任是很重要的。(3)组织的边界和界面,没有一个项目是在真空中完成的，项目组成员必须与客户和本组织内的其他成员打交道。此外，在大型项目中还可能牵涉到转包商。必须制定出项目本身与其他实体之间在行政上和管理上的界线。在许多软件组织内部包含两种类型的组织：完成特定开发项目的开发组和起支持作用的支持组(例如配置管理组和SQA组)。如果本项目有支持组介入，则项目组和支持组之间的行政、管理界线也必须清楚地定义。(4)项目责任 针对每个项目职责(例如SQA)和每项活动(例如产品测试)，必须明确地指定好个人的责任。,3.管理过程 这部分的5个小部分描述怎样对软件项目进行管理。(1)管理的目标和优先级 描述管理的原理、目标和优先级。本部分的内容可能包括提交报告的频率和机制、不同需求的相对优先关系、项目的进度和资金预算，以及风险管理过程。(2)假设、依赖性和约束列出在规格说明文档及其他文档中包含的所有假设、依赖性和约束。,(3)风险管理 在本小节中列出项目中存在的多种风险因素和跟踪风险的机制。(4)监督和控制机制 详细地描述项目报告机制，包括复查和审计机制。(5)人员计划 项目中的有关人员是重要的资源。在这一小节中列出所需人员的类型和数量，并且指明需要他们参与工作的时间。,4.技术过程 本部分包括3个小部分，指明该项目的技术方面。(1)方法、工具和技术 详细地描述有关软件和硬件的技术方面，应该覆盖的内容包括：开发产品所用的计算机系统(硬件、操作系统和软件)，以及产品运行的目标系统。其他需要描述的内容有：所用的开发技术、测试技术、开发小组的结构、编程语言和CASE工具。此外，也应该包括技术标准，比如文档标准和编码标准，以及可能参考的其他文档，还有开发和修改工作产品的过程。,(2)软件文档 描述文档需求，即文档编制标准、里程碑、基线和对软件文档的复查。(3)项目支持功能 给出关于支持功能(例如，配置管理和质量保证)的详细计划，包括测试计划。,5.工作包、进度和预算 本部分包含5个小部分，着重描述工作包、它们之间的相互联系、资源需求和相关的预算分配。(1)工作包 详细说明工作包，并把与之相关的工作产品分解为活动和任务。(2)依赖性 模块编码是在设计之后，集成测试之前进行的。一般来说，工作包之间有相互依赖性，并且依赖于外部事件。这一小节着重说明依赖关系。(3)资源需求 完成项目需要各种各样的资源，一般来说，应该把资源需求表示为时间的函数。,(4)预算和资源分配 描述分配给各个项目职责、活动和任务的资源和预算。(5)进度表 对项目的各个部分都制定一个详细的进度表，然后确定主计划，以便在预算之内按时完成项目。附加部分 对于特定的项目，可能需要在项目计划中再增加一些内容。根据IEEE结构框架，把这些附加的内容列在一个计划的最后。附加的部分可能包括转包商管理计划、安全计划、测试计划、培训计划、硬件采购计划、安装计划和产品维护计划等。,13.2 ISO9000质量标准,13.2.1 基本思想 ISO9000的基本思想主要体现在下述几个方面。强调质量并不是在产品检验中得到的，而是在生产的全过程中形成的。ISO9000-3阐述了供方和需方应该怎样进行有组织的质量管理活动，才能得到较为满意的软件产品；规定了从双方签订开发合同到设计、实现和维护的整个软件生命周期中应该实施的质量管理活动，但是，并没有规定具体的质量管理和质量检验的方法和步骤。,为确保产品质量，ISO9000要求“在生产的全过程中，影响产品质量的所有因素都要始终处于受控状态”。为使软件产品达到质量要求，ISO9000-3要求软件开发机构建立质量管理体系。首先要求明确供需双方的职责，针对所有可能影响软件质量的因素，都要做出如何加强管理和控制的决定。,可以用ISO9000标准证实“企业具有持续地提供符合要求的产品的能力”。如果产品质量能达到标准提出的要求，则可由不依赖于供、需双方的第三方权威机构对生产厂家审查认证后，出具合格证明。还可以用ISO9000标准来“持续地改进质量”。实施ISO9000标准是企业加强质量管理、提高产品质量的过程。通常，认证的有效期为半年，取得认证之后每年还需要接受12次定期检查，以保证该企业的质量管理体系持续地符合ISO9000标准，并促使企业不断地提高质量。,13.2.2 ISO9000-3标准 ISO9000-3的全称是“质量管理和质量保证标准第三部分：在软件开发、供应和维护中的使用指南”。ISO9000-3是一个与软件生命周期相关的、对开发过程各阶段提供质量保证的质量管理体系，由质量管理体系框架、质量管理体系的生命周期活动、质量管理体系的支持活动等部分组成。标准中规定的各项质量活动都要求以文档作为各阶段活动的结果，文档在标准中占有十分重要的地位，可以说ISO9000-3标准是文档驱动的。,1.质量管理体系框架 在这部分中规定了供需双方的管理职责，并要求供方建立一个用文件规定的质量管理体系，该体系应该是一个贯穿于整个软件生命周期的综合过程，以便在软件开发过程中保证质量，而不是在开发过程结束时才发现质量问题。标准强调，应该防止发生质量问题，而不是在发生了质量问题之后依靠纠正措施来解决问题。标准中还包括，内部质量审核步骤和纠正措施等内容。,2.质量管理体系的生命周期活动 通常，一个软件开发项目按照某种生命周期模型进行组织，并根据所采用的生命周期模型的特点来计划和实施与质量保证有关的活动。这部分按照软件生命周期过程描述了有关的质量管理活动，其中包括合同评审、需方的需求规格说明、开发计划、质量管理计划、设计与实现、测试和确认、验收、复制/交付和安装、维护等。这部分对文档有如下要求。,3.质量管理体系的支持活动 在标准中规定的支持活动有：配置管理；文档控制；度量；规则、惯例和约定；工具和技术；采购；配套的培训等活动。,13.3 ISO/IEC 12207软件生命周期过程标准,这是指导软件过程实施的一个标准，它从多个角度阐述了软件生命周期各个过程中的活动，对规范软件开发过程，协调各类人员之间的关系，都具有指导作用。,13.3.1 概述 本标准建立了一个最高层次的软件生命周期体系结构。生命周期从一个设想或需求开始，直至软件被废弃(退役)时终止。体系结构由一组相互关联的过程集组成，所有过程都遵守了两条基本原则：模块化和责任。所谓模块化是指，标准中规定的过程都是模块化的，它们具有较高内聚性和较低耦合性，通常一个具体的过程完成一个独立的功能。所谓责任是指，在软件生命周期中，一个过程的执行被认为是一个部门的责任，也就是说，项目中的每个部门都承担着某种责任。责任是在整个软件生命周期中进行质量管理的一条关键原则。,标准中的过程被分成三大类：主要过程，支持过程和组织过程，如图13.2所示。主要过程是生命周期中的原动力，它们是：获取、供应、开发、运行和维护。支持过程包括：文档、配置管理、质量保证、验证、确认、联合评审、审计和问题解决。在其他过程中可以使用支持过程。组织过程有：管理、基础设施、改进和培训。一个组织可以使用组织过程来建立、控制和改进生命周期过程。标准中的一个过程被进一步细化为一系列活动，而每个活动则被分解为一系列任务，任务是基本的原子行为。,图13.2 软件生命周期过程,13.3.2 软件生命周期过程 1.主要过程 标准中描述了一个主要过程集，它们为完成软件获取、供应、开发、运行和维护等任务的部门服务。(1)获取过程 在这个过程中，标准定义了获取方通过合同的形式获取软件产品或服务时，应该完成的活动及任务。(2)供应过程 这个过程包括了软件供应方应完成的活动和任务。,(3)开发过程 在这个过程中定义了软件开发者应该完成的活动和任务，它是包含内容最多的一个过程。开发过程既可以用于开发一个新软件，也可以用于修改已有的软件。开发过程由过程实现、系统需求分析、系统体系结构设计、软件需求分析、软件体系结构设计、软件详细设计、软件编码和测试、软件集成、软件质量测试、系统集成、系统质量测试、软件安装以及软件验收等活动组成。(4)运行过程 这个过程规定了软件系统的运行者应该完成的活动和任务。(5)维护过程 维护过程包括了软件维护者应该完成的活动和任务。,2.支持过程 本标准定义了8个支持过程。一个支持过程可以被获取、供应、开发、运行和维护等主要过程调用，也可以被其他支持过程调用，以保证项目成功和项目质量提高。(1)文档过程(2)配置管理过程(3)质量保证过程(4)验证过程(5)确认过程(6)联合评审过程(7)审计过程(8)问题解决过程,3.组织过程 本标准包括4个组织过程。一个组织可以使用组织过程来实施组织内的、合作的、位于项目之上的或跨项目的功能。一个组织过程也可以支持其他过程，这些组织过程用于帮助创建、控制和改进其他过程。(1)管理过程(2)基础设施过程(3)改进过程(4)培训过程,4.过程间的相互关系 本标准共定义了17个过程，它们之间的关系如图13.3所示。图中最上面的矩形框中所包含的是组织过程，中间的矩形框描述了如何把过程应用于一个项目，最下面的矩形框是支持过程集。图中椭圆上的顺时针箭头表示plan-do-check-ack(PDCA)周期。图中，“E、F、M、P、T、U”分别代表执行(Execute)、反馈(Feedback)、管理(Manage)、实践(Participate)、任务(Task)和使用(Use)。“E:n”表示执行第n个过程，图下部的矩形框中给出了过程编号。,图13.3 生命周期过程及它们之间的相互关系,13.4 ISO/IEC TR 15504软件过程评估标准,上一节介绍的ISO/IEC 12207是从过程实施的角度对软件生命周期过程进行规范的标准，而这一节介绍的ISO/IEC TR 15504则是从过程评估的角度对软件过程进行规范的标准。13.4.1 概述 ISO/IEC TR15504为软件过程评估提供了一个框架，并为实施评估以确保各种级别的一致性和可重复性提出了一个最小需求。该需求有助于保持评估结果前后一致，并提供证据证明其级别、验证与需求相符。过程评估活动可以在过程改进活动中执行，也可以作为能力确定过程的一部分执行。,13.4.2 标准的结构 ISO/IEC TR 15504标准具有两维结构：一个是过程维，另一个是能力维。1.过程维 过程维是评估的基础，它的定义融合了一些ISO/IEC 12207软件生命周期过程的定义。在ISO/IEC TR 15504-2中描述的各个软件过程如下。客户供应者(CustomerSupplier)过程这类过程有获取、供应、需求导出和操作等4个过程。,工程(Engineering)过程 这类过程包括开发、系统与软件维护等2个过程。支持(Support)过程 这类过程包括文档、配置管理、质量保证、验证、确认、联合复审、审计和问题解决等8个过程。管理(Management)过程 这类过程有管理、项目管理、质量管理和风险管理等4个过程。组织(Organization)过程 这类过程包括组织调整、改进、人力资源管理、基础设施、测量和重用等6个过程。,2.能力维 在标准的第2部分所定义的能力等级，是一组过程和管理的属性，它们作为一个整体为软件供应者提供了改进过程实施能力的建议。每个等级都提供改进过程实施能力的建议，各个级别都制定了改进过程能力的合理的方法。在参考模型中定义了6个能力级别，下面按从低到高的顺序介绍这6个级别的特点。(1)第0级不完全级 过程不完整，而且一片混乱。(2)第1级可实施级 过程是依据直觉来实施的，有一定的工作产品。,(3)第2级有管理级 责任明确，过程和过程的中间产品可管理。(4)第3级可创建级 可以为不同目的定制预定义的过程，过程资源可管理。(5)第4级可预测级 各种度量使得过程的实施及实施结果可控制。(6)第5级优化级 用于过程改进的定量度量。在本标准中融合进了与下节将介绍的能力成熟度模型(CMM)类似的能力等级。用户可以通过不断提高能力等级的方法，提高自己的软件过程能力。,13.5 能力成熟度模型,能力成熟度模型的基本思想是，因为问题是由我们管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高生产率和软件质量。能力成熟度模型有助于软件开发组织建立一个有规律的、成熟的软件过程。改进后的过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。,软件过程包括各种活动、技术和工具，因此，它实际上既包括了软件生产的技术方面又包括了管理方面。CMM策略力图改进软件过程的管理，而在技术方面的改进是其必然的结果。必须记住，对软件过程的改进不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的成熟度等级，一个软件开发组织可用一系列小的改良性步骤向更高的成熟度等级迈进。,13.5.1 能力成熟度模型的结构 能力成熟度模型包括以下的组成成分。成熟度等级(Maturity Levels)：一个成熟度等级是在朝着实现成熟软件过程进化途中的一个妥善定义的平台。五个成熟度等级构成了CMM的顶层结构。过程能力(Process Capability)：软件过程能力描述，通过遵循软件过程能实现预期结果的程度。一个组织的软件过程能力提供一种“预测该组织承担下一个软件项目时，预期最可能得到的结果”的方法。,关键过程域(Key Process Areas,KPA)：每个成熟度等级由若干关键过程域组成。每个关键过程域都标识出一串相关的活动，当把这些活动都完成时所达到的一组目标，对建立该过程成熟度等级是至关重要的。关键过程域分别定义在各个成熟度等级之中，并与之关联在一起，例如，等级2的一个关键过程域是软件项目计划。目标(Goals)：目标概括了关键过程域中的关键实践，并可用于确定一个组织或项目是否已有效地实施了该关键过程域。目标表示每个关键过程域的范围、边界和意图，例如，关键过程域“软件项目计划”的一个目标是，“软件估算已经文档化，供计划和跟踪软件项目使用。”,公共特性(Common Features)：CMM把关键实践分别归入下列五个公共特性之中：执行约定、执行能力、执行的活动、测量和分析以及验证实施。公共特性是一种属性，它能指示一个关键过程域的实施和规范化是否是有效的、可重复的和持久的。关键实践(Key Practices)：每个关键过程域都用若干关键实践描述，实施关键实践有助于实现相应的关键过程域的目标。关键实践描述对关键过程域的有效实施和规范化贡献最大的基础设施和活动。例如，在关键过程域“软件项目计划”中，一个关键实践是“按照已文档化的规程制定项目的软件开发计划”。图13.4描绘了CMM的结构。,图13.4 CMM结构,13.5.2 能力成熟度等级 CMM通过定义能力成熟度的五个等级，引导软件开发组织不断识别出其软件过程的缺陷，并指出应该做哪些改进，但是，它并不提供做这些改进的具体措施。能力成熟度的五个等级从低到高是：初始级、可重复级、已定义级、已管理级和优化级。下面介绍能力成熟度的这五个等级。1.初始级 软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的，项目能否成功完全取决于个人能力。,2.可重复级 建立了基本的项目管理过程，以追踪成本、进度和功能性。必要的过程规范已经建立起来了，使得可以重复以前类似项目所取得的成功。3.已定义级 用于管理和工程活动的软件过程已经文档化和标准化，并且已经集成到整个组织的软件过程中。所有项目都使用文档化的、组织批准的过程来开发和维护软件。这一级包含了第2级的所有特征。,4.已管理级 已收集了软件过程和产品质量的详细度量数据，使用这些详细的度量数据，能够定量地理解和控制软件过程和产品。这一级包含了第3级的所有特征。5.优化级 通过定量的反馈能够实现持续的过程改进，这些反馈是从过程及对新想法和技术的测试中获得的。这一级包含了第4级的所有特征。,13.5.3 关键过程域 能力成熟度模型并不详细描述所有与软件开发和维护有关的过程，但是，有一些过程是决定过程能力的关键因素，这就是CMM所称的关键过程域。关键过程域是达到一个成熟度等级的必要条件。除第1级成熟度之外，每个成熟度等级都包含几个关键过程域，指明了为改进其软件过程软件开发组织应该重视的区域，同时也指明了为达到某个成熟度等级所必须解决的问题。下面给出在每个成熟度等级应该实现的关键过程域。注意，下面列出的关键过程域是累加的，例如，第3级中包含了第2级的所有关键过程域再加上第3级特有的关键过程域。,1.成熟度第2级软件配置管理软件质量保证软件子合同管理软件项目跟踪和监督软件项目计划需求管理,2.成熟度第3级同事复审组间协作软件产品工程集成的软件管理培训计划组织过程定义组织过程焦点,3.成熟度第4级软件质量管理定量的过程管理4.成熟度第5级过程变化管理技术变化管理错误预防,13.5.4 应用CMM CMM的用途主要有两个：软件开发组织用它来改进开发和维护软件的过程；政府或商业企业用它来评价与一个特定的软件公司签订软件项目合同的风险。,13.6 小结,本章简要地介绍了几个与软件项目管理有关的国际标准，供读者在实际工作中参考、借鉴。在IEEE标准1058.1中给出了软件项目管理计划的框架，它实质上是一个通用的结构，不论承担何种软件项目，在制定项目管理计划时都可以参考它。,ISO9000是一族标准，它主要是为促进国际贸易而发布的，现在，通过ISO9000认证已经成为一个企业证明其产品质量和工作质量的标志。ISO9000-3是使ISO9001标准适用于软件开发、供应和维护的指南，它为软件开发过程各阶段提供保证质量的质量体系，由质量体系框架、质量体系的生命周期活动和质量体系的支持活动等三部分组成。文档在ISO9000-3标准中占有十分重要的地位。,ISO/IEC 12207软件生命周期过程标准，是指导软件过程实施的一个标准，它从多个角度说明了软件生命周期各个过程中的活动，对规范软件开发过程，协调各类人员之间的关系，都具有指导作用。ISO/IEC TR 15504软件过程评估标准，是从过程评估角度对软件过程进行规范的标准。该标准具有两维的结构，其中一维是过程维，另一维是能力维。,能力成熟度模型(CMM)，是改进软件过程的一种策略。它的基本思想是，因为问题是管理软件过程的方法不恰当引起的，所以运用新软件技术并不会自动提高软件生产率和软件质量，应当下大力气改进对软件过程的管理。对软件过程的改进不可能一蹴而就，因此，CMM以增量方式逐步引入变化，它明确地定义了5个不同的成熟度等级，一个软件开发组织可用一系列小的改良性步骤迈入更高的成熟度等级。,