信息技术软件生存周期程介绍

中国电子技术标准化研究所, by,China Electronics Standardization Institute 2005,软件生存周期过程,中国电子技校,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,人,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,信息技术 软件生存周期程,GB/T8566-2007,介绍,1,综述,1.1,软件生存周期过程的提出,1.2 GB/T8566,的演变,1.3 GB/T8566,新版的结构,2 GB/T8566,新版的过程介绍,3,关于附录,D,4,软件生存周期过程模型,5,软件生存周期过程的使用,6,小结,目 次,1,综述,软件生存周期是指软件从构思开始至软件退役为止的软件发生、发展直至软件退役（死亡）的整个生存周期。为开发高水平、高质量的软件（特别是大型软件），软件的开发和维护，需要有过程来控制和管理。,在几十年的软件开发和维护过程中，许多专家总结和归纳了开发高水平、高质量软件的规律，逐步形成了软件生存周期过程的标准。只要我们认真学习、理解并结合自己的具体情况全面而又完整地贯彻过程标准（可根据具体情况进行适当的剪裁），我们就能开发出高水平、高质量的软件。以下因素决定了我们需要软件生存周期过程标准。,1.1,软件生存周期过程的提出,1.1.1,软件的特点,-,软件成本高,-,软件开发的进度难于控制,-,估计软件工作量很困难,-,软件质量难于保证,-,修正维护软件困难,综上所述，由于软件是计算机系统中的逻辑部件而不是物理部件，软件开发是逻辑思维过程，软件的工作量很难估计，进度难于控制，质量也难于评价，成本高，维护工作量繁重。同时软件的复杂度随规模按指数级增加，这就需要许多人共同开发一个大型系统。团队开发软件虽然增加了开发力量，但也增加了额外的工作量，组织不严密，管理不善，常常是造成软件开发失败多，费用高的重要原因。人们面临的不仅是技术问题，更重要的是管理问题。,1.1.2,计算机信息系统的应用与普及对软件的需求飞速膨胀,在计算机应用的初期，软件被看成是个体的脑力劳动的结晶，讲究技巧，甚至认为是个人的艺术品。目前计算机的应用领域已从单纯的科学计算发展到军事、经济文化、科学、社会主流的各个方面。软件系统从简单发展到复杂，从小型发展到大型，由封闭系统发展成为开放的不断演化的系统。 复杂系统中的软件比重也越来越大。,在计算机技术不断发展和应用的过程中，软件的规模越来越大，软件已经不再是个体产品而是成百上千人合作劳动的成果；软件开发，也从注意技巧发展为注重管理，软件开发过程从目标管理转向过程管理,1.1.3,软件工程与软件过程管理,计算机硬件的迅猛发展和应用的普及与扩展，对软件需求的日益迫切，软件的规模也日益扩大，从而产生了软件危机。人们警呼软件跟不上硬件的发展和应用的需要，软件成为计算机信息系统发展的瓶颈。,形势迫使人们思考软件的开发方式，人们越来越认识到要解决软件危机，只有使软件摆脱个体劳动的束缚，软件开发也要走工程化的道路。所谓软件工程就是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最先进的技术方法结合起来。,软件工程技术有两个明显的特点：,第一，强调规范化。,第二，强调文档化。,从近几年软件产业发展的情况看，软件开发方法和技术创新起了很大的作用，但推动软件产业上规模、上效益和上水平的真正原因是重视了软件过程的管理。,面对软件工程、过程管理和软件产业的兴起，许多专家对软件过程管理与控制进行了大量和深入的研究，在此基础上，,IEEE,和,ISO,总结与归纳这些研究成果，经过不断的讨论与修改，逐步形成了过程标准，于,1995,年正式推出了国际标准,ISO/IEC 12207,：,1995Information technology software life cycle processes,。,1.2 GB/T8566,的演变,-,GB/T8566-1988,-,GB/T8566-1995,-,GB/T8566-2001,-,GB/T8566-2007 - ISO/IEC12207,未来发展,1.3 GB/T8566,新版的结构,5 生存周期基本过程,5.1 获取过程,5.2 供应过程,5.3 开发过程,5.4 运作过程,5.5 维护过程,6 生存周期支持过程,6.1 文档编制过程,6.2 配置管理过程,6.3 质量保证过程,6.4 验证过程,6.5 确认过程,6.6 联合评审过程,6.7 审核过程,6.8 问题解决过程,6.9 易用性过程,7 生存周期组织过程,7.1 管理过程,7.3 改进过程,7.2 基础设施过程,7.4 人力资源过程,7.5 资产管理过程,7.6 重用大纲管理过程,7.7 领域工程管理过程,1.4,部分术语定义,需方,:,从供方获得或采购系统、软件产品或软件服务的组,织。,供方：与需方签订合同，并按合同规定提供系统、软件,产品或软件服务的组织。,开发方：在软件生存周期过程中执行开发活动（包括需,求分析、设计、测试直到验收）的组织。,操作方：运行系统的组织。,维护方：执行维护活动的组织。,使用周境：用户、任务、设备（硬件、软件和资料）以,及产品使用的物理和社会环境。,GB/T8566,新版的过程介绍,2.0,导引,2.1,生存周期基本过程,2.2,生存周期支持过程,2.3,生存周期组织过程,2.4,过程与组织,2.5,过程的输出,2.0,导引,在解决“软件危机”的过程中，许多科学家对软件工程、对提高软件质量的理论和方法，进行了广泛深入的研究与实践。人们日益认识到必须把项目开发人员进行严密的组织管理，使共同工作的人员能够协同配合。从而提高软件系统的可靠性、可理解性和易维护性，提高软件生产率，降低开发成本。,同时，在软件开发中，除了在软件开发过程中采用先进技术和开发方法之外，更重要的是有一整套的管理方法，即所谓软件过程管理。它重视的是软件企业在软件开发的过程中对需求管理、计划安排、合同规范、项目跟踪、资源分配和质量要求等的管理方式。换句话讲就是对软件开发全过程实行规范化的管理。,其中软件过程管理技术又包括软件管理学和软件工程经济学。它对软件质量的提高、完成软件开发的全过程和软件企业的发展起到了保证作用。随着软件开发的深入、各种技术的不断创新和软件产业的逐渐形成。人们越来越意识到软件过程管理的重要性。,GB/T 8566,标准为软件生存周期过程建立了一个公共框架，可供软件产业界参考。它包括在含有软件的系统、独立软件产品和软件服务的获取期间以及在软件产品的获取、供应、开发、运行和维护的公共软件过程体系结构。该标准也提供了为管理和改进过程的必要的支持过程、任务和活动，以及组织过程、任务和活动。软件包括固件的软件部分。,2.1,生存周期基本过程,生存周期基本过程包括,5,个过程，这些过程供各主要参与方在软件生存周期期间使用。主要参与方是参与或完成软件产品开发、运作或维护的组织。这些主要参与方有软件产品的需方、供方、开发方、操作方和维护方。,基本过程是：,a),获取过程,为获取系统、软件产品或软件服务的组织即需方而定义的活动；,b),供应过程,为向需方提供系统、软件产品或软件服务的组织即供方而定义的活动；,c),开发过程,为定义并开发软件产品的组织即开发方而定义的活动；,d),运作过程,为在规定的环境中为其用户提供运行计算机系统服务的组织即操作方而定义的活动；,e),维护过程,为提供维护软件产品服务的组织即维护方而定义的活动。也就是对软件的修改进行管理，使它保持合适的运行状态。该过程包括软件产品的迁移和退役。,获取过程包含10个活动33个任务；,供应过程包含7个活动24个任务；,开发过程包含13个活动55个任务；,运作过程包含4个活动9个任务；,维护过程包含6个活动24个任务。,2.2,生存周期支持过程,生存周期支持过程包括,9,个过程。支持过程以明确的目的作为构成整体所必须的部分支持其他过程（主要是基本过程）。有助于软件项目的成功和提高质量。支持过程按照其他过程的需要采用和执行。支持过程有：,a),文档编制过程,为记录生存周期过程所产生的信息而定义的活动；,b),配置管理过程,定义配置管理活动；,c),质量保证过程,为客观地保证软件产品和过程符合规定的需求以及已建立的计划而定义的活动。联合评审、审核、验证和确认可以作为质量保证技使用；,d),验证过程,根据软件项目需求，按不同深度（为需方、供方或某独立方）验证软件产品而定义的活动；,e),确认过程,（为需方、供方或某独立方）确认软件项目的软件产品而定义的活动；,f),联合评审过程,为评价一项活动的状态和产品而定义的活动。该过程可由任何两方应用，其中一方（评审方）以联合讨论会的形式评审另一方（被评审方）；,g),审核过程,为判定符合需求、计划和合同而定义的活动。该过程可由任何两方应用，其中一方（审核方）审核另一方（被审核方）的软件产品或活动。,h),问题解决过程,为分析和解决问题（包括不合格）而定义的活动，不论问题的性质或来源如何，它们都是在实施开发、运作、维护或其他过程期间暴露出来的；,i),易用性过程,为易用性专业人员而定义的活动。,文档编制过程包含,4,个活动,7,个任务；,配置管理过程包含,6,个活动,6,个任务；,质量保证过程包含,4,个活动,16,个任务；,验证过程包含,2,个活动,13,个任务；,确认过程包含,2,个活动,10,个任务；,联合评审过程包含,3,个活动,8,个任务；,审核过程包含,2,个活动,8,个任务；,问题解决过程包含,2,个活动,2,个任务；,易用性过程包含,3,个活动,13,个任务；,2.3,生存周期组织过程,生存周期组织过程包括,7,个过程。这些过程可被某个组织用来建立和实现由相关的生存期过程和人员组成的基础结构并不断改进这种结构和过程。采用它们通常超出特定的项目和合同的范围。但是，这些特定项目和合同的经验教训有助于改善组织状况。,组织过程有：,a),管理过程,为生存周期过程中的管理包括项目管理而定义的基本活动；,b),基础设施过程,为建立生存周期过程基础设施而定义的基本活动；,c),改进过程,为某一组织（即需方，供方，开发方，操作方，维护方，或另一过程的管理者）建立、测量、控制和改进其生存周期过程而定义需要执行的基本活动；,d),人力资源过程,为给组织或项目拥有技能和知识的员工而定义的活动；,e),资产管理过程,为组织的资产管理者而定义的活动；,f),重用大纲管理过程,为组织的重用大纲主管而定义的活动；,g),领域工程管理过程,为领域模型、领域体系结构的确定及该领域资产的开发和维护而定义的活动。,管理过程包含,6,个活动,16,个任务；,基础设施过程包含,3,个活动,5,个任务；,改进过程包含,3,个活动,6,个任务；,人力资源过程包含,6,个活动,15,个任务；,资产管理过程包含,3,个活动,15,个任务；,重用大纲管理过程包含,6,个活动,24,个任务；,领域工程过程包含,5,个活动,27,个任务；,三类过程的关系,基本过程是针对不同的使用者而规定获取、开发、维护软件需要开展的活动及任务；,支持过程是规定为支持实施基本过程而需要开展的活动及任务；,组织过程是规定为支持实施基本过程和支持过程而在组织层面而需要开展的活动及任务。,2.4,过程与组织,2.4.1,需方与获取过程,获取过程包括需方的活动和任务。此过程从确定需要获取的系统、软件产品或软件服务开始，接着就是制定和发布标书，选择供方和管理获取过程，直到验收系统、软件产品或软件服务。,需方按管理过程在项目级上管理本条中具体说明的获取过程；按基础设施过程建立本过程的基础设施；按剪裁过程为具体项目剪裁本过程；按改进过程和培训过程在组织级上管理本过程。,2.4.2,供方与供应过程,供应过程包括供方的活动和任务。这一过程可以按下述方式启动，或者编制投标书来答复需方的招标书，或者与需方签订一项合同，来提供系统、软件产品或软件服务。接着确定为管理和保证项目所需的规程和资源，包括编制项目计划，实施计划，直到系统、软件产品或软件服务交付给需方。,供方按照管理过程在项目级上管理本条中具体说明的供应过程。按照基础设施过程建立本过程的基础设施。按照剪裁过程为该项目剪裁本过程。按照改进过程和培训过程在组织级上管理本过程。,2.4.3,开发方与开发过程,开发过程包括开发方的活动和任务。过程包括需求分析、设计、编码、集成、测试和与软件产品有关的安装和验收等活动。如果合同中有规定，它可以包括和系统有关的活动。开发者按照合同执行或支持这种过程中的活动。,开发方按照管理过程在项目级上管理本条中具体说明的开发过程。按照基础设施过程建立该过程的基础设施；按照剪裁过程为该项目剪裁本过程；按照改进过程和培训过程在组织级上管理本过程。当开发者是所开发的软件产品的供方时，开发者要执行供应过程。,2.4.4,操作方与运作过程,运作过程包括操作方的活动和任务。本过程规定软件产品的运行和对用户的操作支持。因为软件产品的运行要集成到系统的运行中，所以本过程的活动和任务涉及到系统。,操作方按管理过程在项目级上管理本条中具体说明的运作过程；按照基础设施过程建立本过程的基础设施；按剪裁过程为该项目剪裁本过程；按改进过程和培训过程在组织级上管理本过程。当操作方就是运行服务的供方时，操作方执行供应过程。,2.4.5,维护方与维护过程,维护过程包括维护方的活动和任务。当软件产品由于某一问题或改进、更新的需要对编码和相关文档进行修改时，就启动本过程。目的是改进现有产品，同时维持其完整性。本过程包括软件产品的迁移和退役。本过程随着软件产品的退役而结束。,维护方按照管理过程在项目级上管理本条中具体说明的维护过程。按照基础设施过程建立该过程的基础设施；按照剪裁过程为该项目剪裁本过程；按照改进过程和培训过程在组织级上管理本过程。当维护方是维护服务的供方时，维护方要执行供应过程。,为了适应多种多样的组织，,GB/T 8566,标准中的过程组成一个综合性的集合。无论大的或小的组织均可以依据它的业务目标，从这些过程（和相关的活动与任务）中选择合适的子集来实现其目标。,GB/T 8566,标准的意图是应用于一个组织的内部或被两个或多个组织用于处理合同关系。为便于在内部和合同情况下应用,GB/T 8566,标准，标准内的任务都是用合同式的语言表达的。在内部使用时，合同式的语言被解释成自己要求的任务。,GB/T 8566,标准要与组织已有的策略和标准协调一致。通常情况，组织一直都在使用它自己现有的标准和特定的软件开发技术。因此，在组织内部应用,GB/T 8566,标准时，重要的是要澄清,GB/T 8566,标准、组织自己的标准、以及已使用的不同技术之间的关系。,2.5,过程的输出,3,关于附录,D,GB/T8566,新版的附录,D,是采用,ISO/IEC12207:1995,补篇,1:2002,的附录,F,而形成的。该附录给出一个过程评价参考模型。其适用于为了业务成功和后续持续的过程改进而需要进行过程评估的组织。,过程参考模型并不表示具体的过程实现途径，也未规定系统,/,软件生存周期的模型、方法或技术。相反参考模型旨在由组织基于其业务需要和应用领域来进行剪裁。在组织的顾客需求环境中由组织的项目来采用组织的定义过程。,参考模型的目的和结果是证明组织的过程是否正在实现的指标。这些指标对于过程评估者来确定组织实现过程的能力，并为策划组织过程改进而提供原始材料是有用的。该参考模型与标准正文 紧密结合，提供了详细的过程期望值，并包括一些附加过程，它们对软件组织进行可靠的、可重复评估是非常重要的。,3.1,生存周期基本过程：,3.1.1,获取过程,目的：,获取过程的目的是获得满足顾客需要产品和,/,或服务。该过程开始于标识顾客需要，结束于验收顾客需要的产品和,/,或服务。,结果：,获取过程成功实现的结果为：,(1),定义获取要求、目标、产品和,/,或服务验收准则和获取策略；,(2),制定一个能明确表示顾客和供方双方的期望、职责和义务的协定；,(3),获得满足顾客需要的产品和,/,或服务；,(4),监督获取过程，以满足如成本、进度和质量之类的约束；,(5),验收供方的可交付产品。,注：输出的编号仅仅是为了标识，并不 意味着优先权或顺序。,获取过程包括下列子过程的目的和结果：,a),获取政策；,b),获取策略；,c),效益分析；,d),技术要求；,e),法律和行政要求；,f),资金要求；,g),项目要求；,h),招标；,i),供方资质；,j),建议评价；,k),签订协定；,l),对供方监督；,m),验收；,n),合同结束；,o),供方关系；,p),用户关系；,q),财务管理,3.1.2,供应过程,目的：,供应过程的目的是向顾客提供满足协定要求的产品或服务。,结果：,供应过程成功实现的结果为：,(1),对顾客的请求作出响应；,(2),在顾客和供方之间就开发、维护、运行、包装、交付和安装产品和,/,或服务达成协议；,(3),由供方开发满足协定要求的产品和,/,或服务；,(4),向顾客交付符合协定要求的产品和,/,或服务。,（,5,）根据协定要求，安装产品。,供应过程还包括下列子过程的目的和结果：,a),供方投标；,b),签订协定；,c),产品发布；,d),产品验收支持,3.1.3,开发过程,目的：,开发过程的目的是把一系列需求转化为满足顾客所述需求的软件产品或基于软件的系统。开发过程的活动为系统开发者角色和软件开发者角色所用而组成。,结果：,开发过程成功实现的结果为：,(1),收集软件开发需求并达成协议；,(2),开发软件产品或基于软件的系统；,(3),开发证明最终产品基于需求的中间工作产品；,(4),在开发过程的产品间建立一致性；,(5),根据系统要求优化系统质量因素，例如，速度、开发成本、易用性等；,(6),提供证明最终产品满足需求的证据（例如，测试证据）；,(7),在根据协定要求安装最终产品。,开发过程包括下列子过程的目的和结果,需求引出,系统需求分析,系统体系结构设计,软件需求分析,软件设计,软件构造（编码和单元测试）,软件集成,软件测试,系统集成,系统测试,软件安装,3.1.4,运作过程,目的：,运作过程的目的是在其预定的环境中运行软件产品，并向软件产品的顾客提供支持。,结果：,运作过程成功实现的结果为：,(1),标识并评价软件在其预定的环境中正常运行的条件；,(2),在其预定的环境中运行软件；,(3),按照协定为软件产品的顾客提供帮助和咨询。,运作过程包括下列子过程的目的和结果：,可运行使用,对顾客支持,3.1.5,维护过程,目的：,维护过程的目的是在交付以后为了改正缺陷、改进性能或其它属性、或适应变更的环境而修改系统,/,软件产品。,结果：,注：在维护组织运行完整性的同时，目标是修改和,/,或退役现行系统,/,软件产品。,维护过程成功实现的结果为：,(1),制定维护策略以遵照发行策略管理产品的变更、迁移和退役；,(2),标识现行系统的变更对组织、运行或接口方面的影响；,(3),根据需要、更新受影响的系统,/,软件文档；,(4),开发修正产品并进行有关试验以证明没有降低需求；,(5),将升级产品迁移到顾客环境中；,(6),按需要，以受控方式使产品从使用中退役，使对顾客的干扰减到最小；,(7),将系统,/,软件的修改通知所有受影响的部分。,3.2,生存周期支持过程,3.2.1,文档编制过程,目的：,文档编制过程的目的是编写并维护由过程产生的所记录的软件信息。,结果：,过程成功实现的结果为：,(1),制定标识在软件产品或服务的生存周期中产生的文档的策略；,(2),标识应用于软件文档编制的标准；,(3),标识由过程或项目产生的文档；,(4),规定、评审、批准全部文档的内容和目的；,(5),根据标识的标准编写文档并使之可用；,(6),按定义的准则维护文档。,3.2.2,配置管理过程,目的：,配置管理过程的目的是建立并维护过程和项目的所有工作产品的完整性，并使其对相关方可用。,结果：,过程成功实现的结果为：,(1),制定配置管理策略；,(2),标识、定义由过程或项目生成的所有工作产品,/,项，并将其纳入基线；,(3),控制工作产品,/,项的修改和发行；,(4),使受影响的方面能够得到修改和发行信息；,(5),记录并报告工作产品,/,项的状态和修改；,(6),确保工作产品,/,项的完整性和一致性；,(7),控制工作产品,/,项的存储、处置和交付。,3.2.3,质量保证过程,目的：,质量保证过程的目的是保证工作产品和过程遵循预先定义的措施和计划。,结果：,过程成功实现的结果为：,(1),制定实施质量保证的策略；,(2),产生并维护质量保证的证据；,(3),标识并记录问题和,/,或与协定要求不一致的内容；,(4),验证产品、过程和活动对适用的标准、规程和需求的依从性。,3.2.4,验证过程,目的：,验证过程的目的是证明过程或项目的每个软件工作产品和,/,或服务正常反映规定的需求。,结果：,过程成功实现的结果为：,(1),制定并实现验证策略；,(2),标识所有要求的软件工作产品的验证准则；,(3),执行要求的验证活动；,(4),标识并记录缺陷；,(5),使验证活动的结果对于顾客和其他相关的组织可用。,3.2.5,确认过程,目的：,确认过程的目的是验证软件工作产品的具体预期使用的需求是否被满足。,结果：,过程成功实现的结果为：,(1),制定并实现确认策略；,(2),标识所有要求的工作产品的确认准则；,(3),执行要求的确认活动；,(4),标识和记录问题；,(5),提供所开发的软件工作产品适合于其预期用途的证据；,(6),使确认活动的结果对于顾客和其他相关的组织可用。,3.2.6,联合评审过程,目的：,联合评审过程的目的是使共利益者相对于协定的目标、对过程的进展保持一种共同的理解，以及对保证开发满足共利益者的产品而应做什么有一个共同的理解。联合评审是针对项目管理和技术层面的，并贯穿于项目的整个生存周期。,结果：,过程成功实现的结果为：,(1),根据项目需要进行管理和技术评审；,(2),通过共利益者间的联合评审活动来评价过程活动的状态和产品；,(3),评审结果通报所有受影响的部门；,(4),追踪产生于评审的行为项，直至结束；,(5),标识并记录问题。,3.2.7,审核过程,目的：,审核过程的目的是适当时独立地确定所选产品和过程与要求、计划及协定的依从性。,结果：,过程成功实现的结果为：,(1),制定并实现审核策略；,(2),根据审核策略确定所选软件工作产品和,/,或服务或过程与要求、计划和协定的依存性；,(3),由合适的独立部门完成审核活动；,(4),标识审核中检测到的问题，并通知那些负责纠正措施并解决问题的部门。,3.2.8,问题解决过程,目的：,问题解决过程的目的是确保识别、分析、管理和控制所有被发现的问题，并确保其得到解决。,结果：,过程成功实现的结果为：,(1),制定问题管理策略；,(2),记录、识别问题，并对其加以分类；,(3),分析并评估问题，以确定可接受解决方案；,(4),实施问题解决方案；,（,5),跟踪问题直至结束；,(6),通告所报告的全部问题的状态。,3.2.9,易用性过程,目的：,易用性过程的目的是充分考虑共利益者的兴趣和需要，以达到优化支持和培训，提高生产率和工作质量、改进人员工作条件、减少用户被系统拒绝的机会。,结果：,过程成功实现的结果为：,(1),系统满足用户要求并考虑其能力和技能的限制；,(2),在系统设计中应综合人为因素、人机工程学知识和技术；,(3),标识并执行以人为本的设计活动；,(4),系统设计应尽可能考虑对人员健康、安全和性能的影响；,(5),系统应提高用户有效性、效率和满意度。,3.3,生存周期组织过程,3.3.1,管理过程,目的：,管理过程的目的根据组织的业务目标，组织、监督和控制任一过程的启动和执行，以达到它的目标。管理过程是由这样的组织建立的以确保此组织和项目使用的惯例的应用一致。当这些惯例是继承组织的管理时，希望组织的每个项目使用它们时用具体例证说明之。,结果：,管理过程成功实现的结果为：,(1),定义受管理的过程、活动的范围；,(2),标识为达到过程目的必须完成的活动和任务；,(3),评价用可用的资源和限制条件达到过程目标的可行性；,(4),建立执行已标识的活动和任务所需的资源和基础设施；,(5),标识活动并完成任务；,(6),监督已定义的活动和任务的完成情况；,(7),评审过程活动产生的工作产品，并分析和评价结果；,(8),当标识的活动和任务的性能偏离或未能达到其目标时，采取修改过程性能的措施；,(9),证明成功达到过程目的。,管理过程包括下列子过程的目的和结果：,组织调整,组织管理,项目管理,质量管理,风险管理,测量,3.3.2,基础设施过程,目的：,基础设施过程的目的是为了支持其他过程的执行而需要维持稳定的和可靠的基础设施。,结果：,该过程成功实施的结果为：,a),为支持组织单位内的过程，定义基础设施需求；,b),标识并规定基础设施要素；,c),获取基础设施要素；,d),实现基础设施要素；,e),维护稳定的和可靠的基础设施。,注：基础设施可以包括硬件、软件、方法、工具、技术、标准和设施，以用于开发、运行和维护。,3.3.3,改进过程,目的：,改进过程的目的是建立、评估、测量、控制并改进软件生存周期过程。,结果：,改进过程成功实现的结果为：,(1),开发一组组织过程资产，并使其可用；,(2),定期评估组织的过程能力，以确定在达到组织目标中过程实现有效性的范围；,(3),在现有基础上，改进关于达到业务目标的组织过程的有效性和效率。,改进过程包含下列子过程的目的和结果：,过程建立,过程评估,过程改进,3.3.4,人力资源过程,目的：,人力资源过程的目的是给组织提供合适的人力资源，并维持其资质及与业务需求的一致性。,结果：,人力资源过程成功实现的结果为：,(1),通过适时评审组织和项目的需求，以标识组织和项目运行所需的角色和技能；,(2),为组织和项目提供人力资源；,(3),基于组织和项目的需要，标识并提供一组跨组织的公共培训；,(4),通过所建立的机制使组织的知识资产可用（或可收集）和可挖掘。,人力资源过程包括下列子过程的目的和结果：,人力资源管理,培训,知识管理,3.3.5,资产管理过程,目的：,资产管理过程的目的是管理从概念到退役的可重用的资产的生存期。,结果：,资产管理过程成功实现的结果为：,(1),编制资产管理策略文档；,(2),建立资产分类表；,(3),定义资产接收、验证和退役准则；,(4),运行资产存储和检索机制；,(5),记录资产的使用；,(6),控制资产变更；,(7),根据存储、检索机制，将所发现问题，进行的修改，创建的新版本及删除的资产通告资产的使用者。,3.3.6,重用大纲管理过程,目的：,重用大纲管理过程的目的是策划、建立、管理、控制并监督组织的重用大纲，并系统地开拓重用时机。,结果：,重用大纲管理过程成功实现的结果为：,(1),定义组织的重用策略，包括其目的、范围、和目标；,(2),标识研究重用可能性和期望实施重用的领域；,(3),评估组织系统性的重用能力；,(4),评估每个领域以确定其重用的潜能；,(5),评价重用建议，保证重用产品适用于建议的应用；,(6),在组织内实现重用策略；,(7),建立反馈、对话和通告机制，以便在重用大纲的管理者、资产管理者、领域工程师、开发者、操作者和维护者之间运行；,(8),监督并评价重用大纲。,3.3.7,领域工程过程,目的：,领域工程过程的目的是开发并维护领域模型、领域体系结构和领域资产。,结果：,领域工程过程成功实现的结果为：,(1),选择领域模型和领域体系结构的表示形式；,(2),建立领域界限以及与其他领域之间的关系；,(3),开发领域模型，它能够表示领域中基本的公共和不同的特性、能力、概念和功能；,(4),开发领域中描述系统的系列的领域体系结构；,(5),规定归属于领域的资产；,(6),获得或开发属于领域的资产，并在其整个生存期中维护它们；,(7),在领域资产的生存周期中维持领域模型和体系结构。,4,软件生存周期模型,4.0,导引,软件生存周期过程,标准与具体的软件生存周期模型无关。不论在具体项目中采用了哪种生存周期模型，都必须执行（可剪裁）标准中规定的过程、活动和任务。但是，在任何项目的策划阶段，根据具体项目的要求，应该选择与确定软件生存周期模型。,4.1,生存周期模型的应用,下面具体说明了系统或项目的一般生存周期模型，并描述了怎样在这个系统生存周期模型内应用,GB/T 8566,标准。,4.1.1,系统生存周期模型,一个典型的系统生存周期模型从一个想法或一个需求开始，贯穿系统的开发、生产、运作和维护，在退役时结束。生存周期模型一般用时间段或里程碑来划分。每个时间段都代表将要被执行的主要的、不同的活动和任务，在从一个时间段向另一个时间段过渡时可能需要某种授权。,例如，系统生存周期的一个模型可按如下方式进行划分，每种不同方式的划分适应于不同的系统生存周期模型：,a),需求判定；,b),概念探索和定义；,c),论证和确认；,d),工程实施,/,开发；,e),生产,/,制造；,f),提交试用,/,销售；,g),运作；,h),维护和支持；,i),退役。,4.1.2,软件生存周期模型,一个典型的软件生存周期模型是由若干活动组成的。它从软件产品或服务的一个构想或概念开始，经过系统工程和软件工程阶段，然后进行运作、维护和支持，到退役结束。,GB/T 8566,标准将这些活动及其相关活动条理化为软件生存周期模型的基本过程、支持过程和组织过程等几个大的过程类型。,4.1.3,在系统生存周期的一般模型中,GB/T 8566,标准的应用实例,下图显示了,GB/T 8566,标准在一个实例系统的生存周期模型中应用的要点，简要陈述了其基本目的，然后说明,GB/T 8566,标准的使用方式。,对,GB/T 8566,标准的任何活动或者整个生存周期模型而言，一个组织既可以在其内部使用，又可要求供方部分或全部按标准的要求提供产品或服务。,4.1.4,确定要求的活动,在这个活动中，识别和确定新的或者需改进的系统要求或构想。应当陈述最关键的一些要求，并对诸如系统成本、关键性和可行性等指标进行评审。,在进行进一步的研究、开发和承诺前，可利用获取过程来帮助做出决定，以确定要求是否在技术上和运作上都是可行的，甚至可利用开发过程来开发决策所需要的软件、方法或模型。,4.1.5,概念探索和定义活动,这个活动是初始的计划阶段。在这个阶段，通过综合的研究、试验性开发和概念评价对技术的、策略的和经济、市场的基础进行评估。为满足所确定的需求而提出的解决方案可以被细化，或者通过可行性评价、估算（如：成本、计划进度、市场、智力和后勤）、折衷方案研究和分析来选择备选的解决方案。这个活动的输出通常是初步系统需求，还可能有软件的原型，它们将被输入给下一个活动。,获取、供应和开发过程可以用来：,帮助判定初始的系统需求；,开发原型；,分析和把用户的反馈纳入到所提出的解决方案。,开发过程本身可成为一种方法，以开发用于进行相关的决策支持的分析,/,模拟模型软件。,4.1.6,论证和确认活动,在这个活动中，系统特性、有关概念、以及解决方案（包括计算机资源）将通过实施系统工程、配置主要设备、开发原型软件、测试以及评价等方式得到进一步的定义。系统特性及其相关概念、所有解决方案都得到确认，以便论证该系统（包括硬件资源和软件资源）是否适合于工程化的开发方式。然后，系统需求将被设定为系统的基线，并初步分配给系统的相关部件（如：硬件、计算机、软件和人员）。这些活动的输出将被输入给下一个活动。,获取、供应和开发过程可以用于分析和定义系统需求、最高层的系统设计方案和系统各部件（包括软件）的初步需求。开发过程可以作为进行需求分析、论证、确认、测试、制作原型以及设计解决方案的一种方法。,4.1.7,工程化,/,开发活动,该活动是系统硬件、计算机、软件、设备、人员子系统、培训和支持项被设计、制作、集成、测试和评价的阶段。输出是一个很接近目标产品的系统、下一活动所必需的文档和证明所生产的系统合格的测试结果。,GB/T 8566,标准完全适用于该活动。获取、供应和开发过程的过程、活动和任务宜经过适当的选择、剪裁，以实施软件的开发或升级。该活动所涉及的开发过程是由软件与其它系统部件共同协调实施的，可以是开发过程的一次执行或多次迭代执行。其输出是关于软件需求、设计和编码的基线。,如果要开发的软件将要成为系统的一部分，那么开发过程的所有活动都是必需的。此外需要搞清楚开发者是否将执行或支持与系统有关的活动。如果将要开发的软件是独立的而不是系统的一部分，那么就不需要进行与系统有关的活动，但宜加以考虑。,4.1.8,生产,/,制造活动,在此活动中，设计和开发好的系统要经历为需方（用户）进行生产或为进入市场（消费者）进行制造等阶段。生产阶段包括批准生产、生产过程、直到系统被交付和验收，目标是有效地为需方（用户）生产并交付可正常运行、并享有支持服务的系统。制造阶段是从批准制造和制造过程到系统被重新设计或者退役。目标是有效地为消费者制造和交付可正常运行的、并享有支持服务的系统。,与硬件相比，软件生产,/,制造的工作量是极小的。它包括，为各种用户,/,消费者将开发好的软件和文档复制到适当的介质上，对此在,GB/T 8566,标准中没有明确的任务，可利用当地业界的惯例和政府法规。配置管理过程的发行管理和交付活动可以用来控制相关的任务。其他的活动（如：完整性验证）可以在适当的地方使用。,4.1.9,提交试用,/,销售活动,在此活动中，系统经历向需方（用户）提交试用或向客户销售等阶段。提交试用阶段从向需方（用户和维护者）交付第一个可运作的系统开始。销售阶段从向用户发放第一批系统开始，直到系统退出市场为止。,获取、供应和开发过程可以用于安装和检查已开发的或者经修改的软件。,4.1.10,运作活动,该活动包括操作、运行或用户和消费者对系统的使用，并在系统撤离运作时结束。,获取、供应和运作过程可以用于软件的运作和为关联的用户提供运作支持。,4.1.11,维护和支持活动,在该活动中，依据错误、不足、问题、用户请求或组织的改编、改进需要修改系统。该活动包括向用户（或消费者）提供后勤、技术和修复支持。,获取、供应和维护过程可以用于软件的维护和向组织、用户和消费者提供支持服务。,与开发过程的所有接口需要被决定。根据该项工作的影响，考虑到适用的情形，需要的开发过程活动可以有所不同。,4.1.12,退役活动,在本阶段中，系统从正常的服务中退役。它包括将退役的系统存档和在给定的一段时间内向它的用户提供有限的支持。,获取过程和维护过程的退役活动可以用于软件退役和在特定的一段时间内向组织、用户和消费者提供支持服务。,4.2,几种软件生存周期模型,有许多的软件生存周期模型。但是，其中有四种主要的模型，它们是：,瀑布型；,增量型；,演化型；,面向对象开发型。,这些生存周期模型中的每一种都可以原封不动地使用，或者也可以把它们结合成一种混合型的生存周期模型。通过生存周期模型的选择，,GB/T 8566,标准的过程、活动和任务被链接起来，并且它们的优先关系被定义。,当为项目选择一个或多个合适的生存周期模型。确定软件生存周期模型是系统生存周期模型的子部分，还是一个完整的生存周期模型。,确定对该项目相关和适用的生存周期模型，诸如瀑布型、演化型、积木型、预期的产品改进和螺旋型等。所有这些模型都描述一定的过程和活动，这些过程和活动可以依次实施，可以重复和组合。在这些模型中，本标准的生存周期活动应反映到所选择模型中。对于演化式、积木式和预期的产品改进模型，一个项目活动的输出输入到下一项活动。在这种情况下，文档编制应当在一项活动或任务结束时完成。,5,软件生存期过程标准的使用,5.1,标准的使用步骤,(1),确定角色。例如，是需方、供方、开发方、操作方、维护方、文档开发者、配置管理人员、质量保证人员或管理人员、独立的确认与验证机构、培训人员等等。,(2),确定负有主要责任的过程。例如，需方对获取过程负责；供方对供应过程负责；开发方对开发过程负责；操作方对运作过程负责；维护方对维护过程负责，等等。,(3),了解项目的环境和特性。例如，项目的来源、背景、期限，所采用的生存期模型，系统生存期的当前阶段，系统和软件的需求，组织所采取的方针、过程和策略，系统和软件的规模、类型和关键性，所涉及的人数和当事各方，等等。,(4),为了支持基本过程，决定还要使用哪些其他的过程作为支持。例如，需方可以用开发过程在签订合同之前定义、分析、研究系统或制作系统的原型。供方可以用开发过程来开发软件。开发方可以用配置管理过程来管理项目的变化。维护方在修改现有的软件时可以用开发过程，为了管理软件的变化可以用配置管理过程，等等。,(5),决定在前面的步骤中所选的哪些过程的活动和任务适合所确定的项目，即，根据项目的具体情况，对,GB/T 8566,标准进行适当的剪裁（有关剪裁的一些规定的见下一节）。,(6),与相关的机构进行谈判。当决定并剪裁了上面步骤中的活动和任务后，最好确定谈判对象。例如，供方可以与需方、子合同当事人、独立的验证与确认机构、配置管理人员等进行谈判。,(7),执行所负责的过程、所规定的活动和任务。,(8),按合同或机构所确定的，或在常规的基础上，对过程进行管理、监督、评审或评价和改进，直至满足合同要求。,5.2,剪裁,5.2.1,剪裁过程,为使剪裁做得合理、洽当，把剪裁作为一个过程来处理。剪裁过程是根据软件产品或项目的具体情况对本标准进行剪裁的过程。这一过程包括下述活动：,a),明确项目环境；,b),请求输入；,c),选择过程、活动和任务；,d),把剪裁决定和理由写成文档。,5.2.1.1,明确项目环境,此项活动包括下述任务。,应明确影响剪裁的项目环境特性，这些特性可能是：生存周期模型；系统生存周期的当前活动；系统和软件需求；组织的方针、规程和策略；系统、软件产品或服务的规模、关键性和类型；以及涉及的人员数量和参与方。,5.2.1.2,请求输入,此项活动包括下述任务：,应请求受剪裁决定影响的组织的输入。用户、支持人员、签订合同的官员、潜在的投标者应参与剪裁。,5.2.1.3,选择过程、活动和任务,此项活动包括下述任务：,(1),应当根据,A.1,和,A.2,条中搜集的数据，对照本标准，决定要执行本标准的那些过程、活动和任务。需要编写什么文档以及由谁负责。,(2),在,(1),中已决定的但在本标准中未规定的过程、活动和任务应在合同中规定。应评价组织的生存周期过程（第,7,章），以确定他们是否能够提供这些过程、活动和任务。,(3),本标准中，要求是按含有“应”或“宜”的任务表述的。应仔细考虑这些任务，对于给定的项目或业务范围，是否应当保留或删除。需要考虑但不限于此的因素有：风险、费用、日程、性能、规模、关键性以及人机接口。,5.2.1.4,把剪裁决定和理由写成文档,此项活动包括下述任务：,所有剪裁决定连同作出决定的理由一起形成文档。,5.2.2,剪裁指南,不存在两个完全相同的项目。在诸多变化因素中，组织的方针和规程、获取方法和策略、项目规模和复杂性、系统需求和开发方法以及其他事物，影响系统获取、开发、运作或维护的方式。本标准是为通用项目编写的，以便尽可能适应变化情况。因此，为了降低成本和改进质量，本标准最好针对具体项目加以剪裁。项目中涉及的所有各方最好参与剪裁。,开发者按合同生产软件产品时，作剪裁时最好考虑所有开发过程要求。,维护者在修改软件产品时，要考虑维护过程和开发过程的各部分可以作为子过程使用。,系统层次特性 确定有关的和适用的系统层次特性，比如子系统和配置项的数量。如果系统有许多子系统或配置项，最好按每个子系统和配置项仔细地剪裁开发过程。应考虑所有接口和集成要求。,项目关键性,越是依赖于软件的正确运作和按时完成的系统，就越需要过程可见性和过程控制。就越要通过测试、评审、审核、验证、确认等手段加强管理控制。相反，对非关键软件的过分的监督和控制可能不能作到成本有效性。,技术风险,软件产品的开发可能有技术风险。如果采用的软件技术不成熟，所开发的软件产品是前所未有的或复杂的，或者软件产品包含安全、保密安全或其他关键要求，那么可能需要严格的规范、设计、测试和评价。独立的验证和确认可能是重要的。,6,小结,6.1,过程汇总,基本类,支持类,组织类,合计,过程,活动,任务,正文的,21,个过程给出“,2H”,即,What,作什么？,Who,谁来做？,附录,D,给出,How,做得怎么样？即如何评价正文中的过程。,6.2 GB/T8566,是软件工程标准中纲领性标准，由此延伸出一些细化标准，如：,文档过程标准；,维护过程标准；,配置管理过程标准；,风险管理标准；,重用过程标准等。,6.3,如何应用,GB/T8566,组织层面应用,GB/T8566,项目层面应用,GB/T8566,6.4,软工标准的使用对象、作用,-,软工标准的目的是规范市场、企业行为。,-,软工标准使用的对象或规范的对象不仅 仅是软件开发组织，实际上对软件的需方和用户也有一定的规范作用。,-,软工标准要花费代价、因此要适度。,-,供需双方应重视软件质量、认可软件价值、尊重知识产权，软件产业才能有序健康发展。,谢谢,