GB T 8566-2001 信息技术 软件生存周期过程.pdf

1、G8/T 8566-2001 前言本标准等同采用国际标准ISO/IEC12207: 1995信息技术软件生存周期过程儿本标准是GB/T8566的第二次修订。卒标准与GB/T8566-1995主要区别在于结构作了调整，把软件生存周期的所有过程归纳为基本过程、支持过程和组织过程，对部分术语名称作了修改。本标准的附录A是标准的附录，附录B至附录D是提示的附录。本标准自实施之日起代替GB/T8566-19950 本标准由中华人民共和国信息产业部提出。本标准由中国电子技术标准化研究所归口。本标准由中国电子技术标准化研究所和上海软件技术开发中心负责起草。本标准主要起草人z冯惠、周明德、杨启菁、:XiJ光龙

2、、王宝艾。本标准首次发布于1988年.1995年第一次修订。85 GB/T 8566-2001 ISO/IEC前言ISO(国际标准化组织和IEC(国际电工委员会)是世界性的标准化专门机构。国家成员体(它们都是lSO或IEC的成员国)通过国际组织建立的各个技术委员会参与制定针对特定技术范围的国际标准.IS0和lEC的各技术委员会在共同感兴趣的领域内进行合作。与IS0和IEC有联系的其他官方和非官方国际组织也可参与国际标准的制定工作。对于信息技术，ISO和IEC建立了一个联合技术委员会，即ISO/IEC JTC 1.由联合技术委员会提出的国际标准草案需分发给国家成员体进行表决。发布一项国际标准，至

3、少需要75%的参与表决的国家成员体投票赞成。国际标准ISO/IEC 12207: 1995是由lSO/IEC JTC 1信息技术联合技术委员会SC7软件工程分技术委员会制定的。附录A是本标准的组成部分。附录B、附录C和附录D仅提供参考信息。86 GB!T 8566-2001 引言软件是信息技术和传统系统的组成部分，比如交通、军事、医疗和财务系统。为了开发和管理软件，标准、规程、方法、工具和环撞迅速激增，这种激增造成了软件管理和工程困难，特别是在集成产品和服务中。软件学科需要从这种激增状态转移到公共框架。这种框架使得软件从业人员在生产和管理软件时有共同语言。本标准就提供了这种框架。这种框架包括下

4、述软件生存周期.从概念形成直到退役，并且由获取和供应软件产品及服务的各个过程组成。此外，这种框架可用来控制和改进这些过程。本标准中的过程形成一个较完整的集合，一个组织根据其目标可选择适合的子集达到目的.因此，本标准设计成可以让具体的组织、项目或应用加以剪裁.当软件是一个独立实体、嵌入系统或整个系统的组成部分时，均可使用本标准。81 中华人民共和国国家标准信息技术软件生存周期过程Information technology-Software Iife cycle processes 1 范围1. 1 目的GB/T 8566-2001 idt ISO /IEC 12207: 1995 代替GB/T

5、8566-1995 本标准为软件生存周期过程建立f一个公共框架，可供软件工业界参考。它包括在含有软件的系统、独立软件产品和软件服务的获取期间以及在软件产品的供应、开发、运作和维护期间需应用的过程、活动和任务。软件包括固件的软件部分。本标准还提供一种过程，这种过程能用来确定、控制和改进软件生存周期过程。1. 2 应用范围本标准适用于系统和软件产品以及服务的获取，还适用于软件产品和固件的软件部分的供应、开发、操作和维护，可在一个组织的内部或外部实施。应包括为软件产品和服务提供环境所需要的系统定义。注:软件生存周期期间使用的过程需要与系统生存周期期间使用的过程相一致。本标准适用于双方情况，若此双方来

6、自同一组织时也可等同应用。它覆盖从一项非正式协议直到法律约束的合同。本标准可由单方作为自我改进工作采用。本标准不打算用于现货软件产品，除非它包含在可交付产品中。本标准为系统和软件产品以及服务的获取者编写，也是为软件产品的供方、开发者、操作者，维护者、管理者、质量保证管理者和使用者编写。1.3 本标准的剪裁本标准含有一组过程、活动和任务，可根据软件项目的情况加以剪裁，剪裁过程就是删除不适用的过程、活动和任务。注z可按合同规定增加独特的或专门的过程、活动和任务。1.4 依从性依从本标准就是执行按剪裁过程(附录A)从本标准中为某软件项目选择的所有过程、活动和任务。当所需要的任务按照预定准则和合同规定

7、要求执行时，就是执行了一个过程或完成了一项活动。任何组织(例如国家机关、工业协会、公司)在作为贸易条件而采用本标准时，有责任规定软件供方依从本标准所必须的最少的过程、活动和任务。1. 5 限制本标准叙述软件生存周期过程的体系结构，但不规定如何实现或完成各过程中包含的活动和任务的细节。本标准并不打算叙述必须产生的文挡的名称、格式或编写内容。本标准可以要求编制类似级别或类型的文挡，例如各种计划。然而，本标准并非暗示这类文档必须分别编制或封装，或以某种样式组合。本标准并未规定一个特定的生存周期模型或软件开发方法。采用本标准的各方负责为软件项目选择一个生存周期模型，并把本标准所述的过程、活动和任务映射

8、到该模型中。各参与方还有责任选择和应用软件开发方法，并执行适合于软件项目的活动和任务。申华人民共和国国东质量监督幢瞌检疲总局2001-11-02批准2002- 06-01实施88 GB!T 8566-2001 本标准并不想与任何组织已有的方针、标准或规程发生矛盾，然而，任何矛盾必须加以解决，并旦任何超越的条件和状态必须以书面形式列出，作为应用本标准的例外情况处理。在本标准中有若干个任务清单，没有一个是完整元缺的，它们只是作为一些示例。2 引用标准下列标准所包含的条文，通过在本标准中引用而构成为本标准的条文。本标准出版时，所有版本均为有效。所有标准都会被修订，使用本标准的各方应探讨使用下列标准最

9、新版本的可能性。GB!T 527 1. 1-2000信息技术词汇第1部分=基本术语(idtTSO!TEC 2382-1:1993) GB!T 527 1. 20-1994信息技术词汇第20部分=系统开发(idtTSO!IEC 2382-20:1990) GB!T 6583-1994质量管理和质量保证术语(idtTSO 8402: 1994) GB!T 16260 -1996信息技术软件产品评价质量特性及其使用指南(idt ISO/IEC 9126:1991) GB/T 19001-1994 质量体系设计、开发、生产、安装和服务的质量保证模式。dtlSO 9001: 1994) ISO!AFNO

10、R:1989 计算机科学辞典3 定义本标准采用GB!T6583、GB!T527 1. 1和GB!T5271. 20中规定的定义以及下列定义E注2合适时，产品可以解释为系统的一部分囚3. 1 需方acquirer从供方获得或采购系统、软件产品或软件服务的组织。注需方可以是买主、顾客、拥有者、用户、采购者。3.2 获取acquls1tlon 取得系统、软件产品或软件服务的过程。3.3 协议agreement 确定将要建立的工作关系的期限和条件。3.4 审核audit 由授权人员对软件产品和过程进行的独立评估，以便评定是否符合需求。3.5 基线baseline 在配置项的生存周期内的某一特定时刻已正

11、式设计并固定了的且经正式批准的配置项的一个版本，而不管媒体是什么。3. 6 配置项configuration item 一个配置中的实体，它满足一项最终使用功能，并能在给定的基准点上单独标识。3.7合同contract通过法律约束当事双方的一个协议，或者一个组织内类似的内部协议，以保证软件服务的提供，或软件产品的供应、开发、生产、操作或维护。3.8 开发者deve10per 在软件生存周期过程中执行开发活动(包括需求分析设计、测试直到验收)的一个组织。3.9评价evaluation 系统地确定一个实体项目满足其规定准则的程度。3. 10 固件firmware 硬件装置和驻留在硬件装置的只读软件

12、中的计算机指令或计算机数据的组合，其软件不能在程序控制下方便地修改。89 GB!T 8566-2001 3.11 生存周期模型life cycle model 一个框架，它含有遍历系统从确定需求到终止使用这-生存周期的软件产品的开发、运行和维护中需实施的过程、活动和任务。3.12 维护者maintain盯执行维护活动的组织。3.13 监督monitoring 由需方或第三方对供方活动状况及其成果的检查。3. 14 非交付项non-deliverable item 按合同不要求交付，但可以在软件产品开发中使用的硬件或软件产品。3.15 现货产品off-the shelf product 已经开发

13、出来的、可得到的、可使用的、现成的或需要加以修改的产品。3.16操作者operator 运行系统的组织。3.17 过程process 把输入转换为输出的一组彼此相关的活动。注2术语活动包括资源的使用。t见GB/T6583 , 1. 2J 3. 18 鉴定qualification 证实实体是否有能力满足规定需求的过程。见GB!T6583.2. 13J 3.19 鉴定需求qualifica tion req uirement 一组准则或条件，当一个软件产品符合这些准则或条件时，就确定它符合规格说明，并可以在其目标环境中使用。3. 20 合格性测试qualification testing 由开发

14、者进行并由需方见证的测试(如合适)，以证明软件产品符合其规格说明，并可以在目标环境中使用。3. 21 质量保证quality assurance 为了提供足够的信任表明实体能够满足质量要求，而在质量体系中实施并根据需要进行证实的全部有计划和有系统的活动。注1 质量保证有内部和外部两种目的。a)内部质量保证E在组织内部，质量保证向管理者提供信任。b)外部质量保证.在合恫或其他情况下，质量保证向顾客或他方提供信任。2 质量控制和质量保证的某些活动是相互关联的。3 只有质量要求全面反映了用户的要求，质量保证才能提供足够的信任.GB/T 6583 ,3. 5J 3.22 发行reIease 一个配置项

15、的特定版本，已准备好用于特定目的(例如测试发行)0 3. 23招标(标书)request for proposal (tender) 需方使用的-种文件，用来向潜在的投标人表示它要获得特定系统、软件产品或软件服务的意图。3.24 退役retlrement 运作和维护组织撤出现有的支持，部分或全部由一个新的系统代替或者安装一个升级的系统。3.25 保密安全security 对信息和数据的保护，这样，未经授权的人员或系统不能阅读或修改它们，不能拒绝授权人员或系统对它们的访问。3.26 软件产品software product 90 GB/T 8566-2001 一组计算机程序、规程以及可能的相关文

16、档和数据。3.27 软件服务software servicc 实施与软件产品有关的活动、工作或义务，比如软件开发、维护和运作。3.28 软件单元software unit 一段可分开编译的代码。3.29 工作说明statement of work 需方使用的一种文件，用来叙述和规定按合同必须执行的任务。3.30供方supplier 与需方签订合同，并按合同规定提供系统、软件产品或软件服务的组织。注l 术语供方是承制方、生产方、卖方或供货方的同义词.2 需方可以指定本组织的部分为供方。3.31 系统system 由-个或多个过程、硬件、软件、设施和人员组成的集合体，提供满足规定需求或目标的能力。

17、3. 32 测试覆盖test coverage 测试用例测试系统或软件产品的需求的程度。3. 33 可测试性testability 为了确定-项需求是否满足，所设计的测试目标和可行性所能达到的程度。3.34 用户user 使用运行系统完成项特定功能的个人或组织。注:用户可以扮演其他角色，比如需方、开发者或维护者。3.35 确认validation 通过检查和提供客观证据认可针对某一特定预期用途的需求已经满足。注l 在设计和开发中，确认涉及到审查某个产品是否符合用户的需要之过程囚2 确认通常是对最终产品在规定的使用条件下进行的。在早期阶段，这样做也可能是需要的。3 确认过的词用来表示相应的状况。

18、4 如果有儿种不同的预期用途，可进行多项确认。GB/丁6583.2.183. 36 验证verfica tion 通过检查和提供客观证据认可规定需求已经满足。注I 在设计和开发中.验证是指对某项规定活动的结果进行检查的过程，以确定该活动对规定需求的合格情况。2 .验证过的一词用来表示相应的状况aGB/T 6583.2. 17 3. 37 版本verSlon 某一配置项的己标识了的实例。注z软件产品某版本的修改产生一个新版本，但要求配置管理活动。4 本标准的应用本章叙述屑于获得、供应、开发、运作和维护软件的软件生存周期的各个过程。目的是为本标准的用户提供一个框架，这样，用户就可以按照本标准调整自

19、己的过程，并合理地应用本标准。4. 1 本标准的结构4. 1. 1 生存周期过程91 GB/T 8566-2001 本标准把软件生存周期中可以开展的活动分为5个基本过程、8个支持过程和4个组织过程。每一生存周期过程划分为一组活动，每一项活动进-步划分为一组任务。子条款的编号X.X表示个过程，x.x.X表示-项活动，X.X.X.X表示一个任务。这些生存周期过程介绍如下，并描绘在图1。5牛存周期基本过程5. 1获取5.2供应E王5. 3开发5.5维护7牛存周期组织过程7. 1管理7. 3改进 6生存周期支持过程6. 1立梢编制6. 2配置管理,. .，.马马孟一7. 2基础设施7.4 j击由11图

20、1本标准的结构4. 1. 1. 1 生存周期基本过程生存周期基本过程(第5章)包括5个过程，这些过程供各主要参与方在软件生存周期期间使用。主要参与方是参与或完成软件产品开发、运作或维护的组织。这些主要参与方有软件产品tI9需方、供方开发者、操作者和维护者。基本过程有zd获取过程(5.1) 确定需方和获取系统、软件产品或软件服务的组织的活动。b)供应过程(5.2)一一确定供方和向需方提供系统、软件产品或软件服务的组织的活动。c)开发过程(5.3) 确定开发者和定义并开发软件产品的组织的活动。d)运作过程(5.4)二一确定操作者和在规定的环境中为其用户提供运行计算机系统服务的组织的活动。e)维护过

21、程(5.5) 确定维护者和提供维护软件产品服务的组织的活动。也就是对软件的修改进行管理，使它保持合适的运行状态。这一过程包括软件产品的移植和退役。4.1. 1. 2 生存周期支持过程生存周期支持过程(第6章)包括8个过程。支持过程以明确的目的作为构成整体所必须的部分支持其他过程。有助于软件项目的成功利提高质量。支持过程按照其他过程的需要采用和执行。支持过92 GB!T 8566-2001 程有ga)文档编制过程(6.1) 确定记录生存周期过程产生的信息所需的活动。b)配置管理过程(6.2)一一确定配置管理活动。c)质量保证过程(6.3)一一确定客观地保证软件产品和过程符合于规定需求以及已建立的

22、计划所需的活动。联合评审、审核、验证和确认可以作为质量保证技术使用。d)验证过程(6.4)一一根据软件项目需求，按不同深度(为需方、供方或某独立方)确定验证软件产品所需的活动。e)确认过程(6.5) (为需方、供方或某独立方)确定确认软件项目的软件产品所需的活动。f)联合评审过程(6.6) 确定评价一项活动的状态和产品所需的活动。这一过程可由任何两方采用，其中一方(评审方)以联合讨论会的形式评审另一方(被评审方)。g)审核过程(6.7)一一确定为判定符合于需求、计划和合同所需的活动。这一过程可由任何两方采用，其中一方(审核方)审核另一方(被审核方)的软件产品或活动。h)问题解决过程(6.8)一

23、一确定一个过程来分析和解决问题(包括不合格)，不论问题的性质或来源如何，它们都是在实施开发、运作、维护或其他过程期间暴露出来的。4.1.1.3 生存周期组织过程生存周期组织过程(第7章)包括4个过程。这些过程可被某个组织用来建立和实现由相关的生存期过程和人员组成的基础结构并不断改进这种结构和过程。采用它们通常超出特定的项目和合同的范围。但是，这些特定项目和合同的经验教训有助于改善组织状况。组织过程有-U管理过程(7.1)一一确定生存周期过程中的基本管理活动，包括项目管理。b)基础设施过程(7.2)确定建立生存周期过程基础结构的基本活动。c)改进过程(7.3) 确定-个组织(即需方，供方，开发者

24、，操作者，维护者，或另一过程的管理者)为建立、测量、控制和改进其生存周期过程所需开展的基本活动。d)培训过程(7.4)一-确定提供经适当培训的人员所需的活动。4. 1.2 剪裁过程附录A(标准的附录)确定进行本标准剪裁所需的基本活动。附录B(提示的附录)就本标准的剪裁要求提供简要说明，其中列出一些关键要素，可以根据这些要素作出剪裁决定。4.1.3 过程和组织之间的关系本标准含有适用于软件整个生存周期的各个过程，这些过程可以被不同的组织根据其需要和目标使用。为便于理解，附录C介绍了生存周期过程和有关各方之间的关系。5 生存周期基本过程本章定义的生存周期基本过程如下za)获取过程;b)供应过程;c

25、)开发过程gd)运作过程;e)维护过程。基本过程中的活动和任务是启动并实施这些过程的组织的职责。这种组织要保证过程存在并且起作用。5. 1 获取过程获取过程包括需方的活动和任务。此过程从确定需要获取的系统、软件产品或软件服务开始，接着就是制定和发布标书，选择供方和管理获取过程，直到验收系统、软件产品或软件服务。93 GB/T 8566-2001 具有这种需求的组织可称为拥在者，拥有者口I以就某一项或全部获取活动与某代理机构签订合同，该机构将根据获取过程开展这些活动。本条中的需方可以是拥有者或代理机构。需方按管理过程(7.。在项目级主管理本条中具体说明的获取过程;按基础设施过程(7.2)建立本过

26、程的基础设施;按剪裁过程(附录A)为具体项目剪裁本过程g按改进过程(7.3)和培训过程(7.4)在组织级上管理本过程。活动清单:本过程包括下述活动.a)启动;b)招标的准备sd合同的准备和修改gd)对供方的监督导e)验收和完成。5. 1. 1 启动此项活动包括下述任务:5.1.1.1 需方通过描述概念或需要以获取、开发或增强系统、软件产品或软件服务来开始获取过程。5. 1. 1.2 需方应定义并分析系统需求。系统需求包括业务、组织和用户，以及安全性、保密安全性与设计、测试有关的其他关键要求和应遵循的标准、规程。5.1.1.3 如果需方委托供方进行系统需求分析，需方应批准所分析的需求。5.1.

27、1. 4 需方可以自己定义和分析软件需求，也可委托供方完成这项任务。5. 1. 1. 5 宜采用开发过程(5.3)完成立1.1. 2和5.1. 1. 4中的任务。5. 1. 1. 6 需方应以风险、费用和效益作为准则对下面每个方案进行分析，考虑获取方案，这些方案包括:a)购买满足需求的现货软件产品gb)在内部开发软件产品或得到软件服务gc)通过合同开发软件产品或得到软件服务事d)上述、b)、c)条的结合;的提高现有的软件产品或服务。5.1.1.7 当要获取现货软件产品时，供方应保证满足下述条件a)满足对该软件产品的需求;b)具有有效的文档sc)满足专利权、使用权、拥有权、担保权和许可权gd)有

28、软件产品的未来支持计划。5. 1. 1. 8 需方宜准备、编制并执行一个获取计划，该计划宜包括下述内容:a)对系统的需求;b)计划的系统配置;c)需采用的合同类型:d)有关组织的职责;e)需采用的支持概念;f)考虑风险以及风险管理的方法D5.9 需方宜确定验收策略和条件(准则)，并将其写成文档。5. .2 招标的准备此项活动包括下述任务z5. 1. 2. 1 需方宜编制获取需求文档(例如招标书)，文档内容取决于在5.1.1.6中选取的获取方案。如合适，获取文街宜包括.94 a)系统需求3b)范围说明;c)投标者须知;d)软件产品清单，e)期限和条件g。子合同的控制;g)技术限制(例如目标环境)

29、。GB/T 8566-2001 5. ,. 2. 2 需方宜确定本标准适合于该项目的过程、活动和任务，并宜适当剪裁。特别是，需方宜规定适用的支持过程(第6章)及其执行组织，如果不是供方，还应规定其职责。这样供方就可以在他们的标书中确定每一适用的支持过程的方法。需方应确定引用合同的那些任务的范围。5. 1. 2. 3 获取文档还应确定合同的里程碑，此时应评审和审核供方的进度，作为监督获取的部分(见6.6和6.7)。5. 1. 2. 4 获取需求宜提交给选择来执行获取活动的组织。5. 1. 3 合同的准备和修改此项活动包括下述任务z5. 1.3. 1 需方宜建立选择供方的规程，包括标书的评价准则和

30、符合需求的程度。5. 1.3. 2 需方宣根据对供方的标书、能力评价和其他需要考虑的因素选择一个供方。5. 1. 3. 3 需方可以联合其他各方，包括潜在的供方，在合同签订前剪裁本标准，然而，需方应对剪裁作出最后决定。需方应在合间中纳入或列举被剪裁的标准。5. 1. 3. 4 需方应准备并与供方进行合同谈判，合同涉及获取需求，包括需交付的软件产品或服务的费用和计划。合同还涉及与可重复使用的现货软件产品相关的专利权、使用权、所有权、担保权和许可权。5. 1. 3. 5 -.合同开始执行，作为更改控制机制的一部分，需方应通过与供方谈判来控制对合同的更改。对合同的更改应调查对项目计划、费用、效益、质

31、量和进度的影响。注:需方确定在本标准的应用中是否使用术语合同或协议5.1.4 对供方的监督此项活动包括下述任务z5. 1.4. 1 需方应按照联合评审过程(6.6)初审核过程(6.7)监督供方的活动。需方宣按需要利用验证过程(6.4)和确认过程(6.5)补充监督。5.1.4.2 需方应与供方合作，及时提供所有必要信息，并解决所布遗留问题。5. 1. 5 验收和完成此项活动包括下述任务:5. 1.5.1 需方宜根据已确定的验收策略和准则准备验收，宜包括准备测试用例、测试数据、测试规程和测试环境。宜确定供方参与的程度。5. ,. 5. 2 需方应对可交付软件产品或服务进行验收排审和验收测试，当所有

32、验收条件满足时，应从供方接受它。验收规程宜符合5.L L 9的规定。5. 1. 5. 3 验收之后，需方宜承担己交付软件产品的配置管理职责(见6.2)。注g需方可以按照供方提供的说明书安装软件产品或进行软件服务。5.2 供应过程供应过程包括供方的活动和任务。这过程可以接下述方式启动，或者编制投标书来答复需方的招标书，或者与需方签订一项合同，来提供系统、软件产品或软件服务。接着确定为管理和保证项目所需的规程和资源，包括编制项目计划，实施计划，直到系统、软件产品或软件服务交付给需方。供方按照管理过程(7.1)在项目级上管理本条中具体说明的供应过程。按照基础设施过程口.2)建立本过程的基础设施。按照

33、剪裁过程(附录A)为该项目剪裁本过程，按照改进过程(7.3)和培训11过程95 (7.4)在组织级上管理本过程。活动清单:本过程包括下述活动a)启动;b)准备投标pc)签订合同;d)编制计划;的实施和控制$0评审和评价;在交付和完成。5.2.1 启动此项活动包括下述任务GB/T 8566一20015.2.1.1 供方评审招标书中的需求，考虑本组织的方针和其他规章。5. 2. 1. 2 供方宜作出投标或接受合同的决定。5.2.2 准备投标此项活动包括下述任务:5.2.2.1 供方宜确定并编制投标书来响应招标书，包括对本标准的剪裁建议。5.2.3 签订合同此项活动包括下述任务:5. 2. 3. 1

34、 供方宜与需方组织谈判并签订提供软件产品或服务的合同。5.2.3.2 作为更改控制机制部分，供方可以要求修改合同。5.2.4 编制计划此项活动包括下述任务z5. 2. 4. 1 供方应对获取需求进行评审，以确定一项框架来管理和保证项目，并保证可交付软件产品或服务的质量。5.2.4.2 如果合同中没有规定，供方应确定或选择一个适合于该项目的范围、规模和复杂度的软件生存周期模型，宜从本标准中选择过程、活动和任务，并反映到生存周期模型中。5.2.4.3 供方应建立计划需求，以便管理和保证该项目，并保证可交付软件产品或服务的质量。计划需求宜包括需要的资源和需方的介入。5.2.4.4 旦建立了计划需求，

35、供方应根据对每-种选择带来的风险分析，考虑开发软件产品或提供软件服务的选择方案。选择方案包括za)利用内部资源开发软件产品或提供软件服务FU通过分包合同开发软件产品或提供软件服务sc)从内部或外部资源获得现成的软件产品;d)以上川、b)、c)的综合。5.2.4.5 供方应在计划需求以及按5.2.4.4进行方案选择的基础上，制订项目管理计划，并形成文档。计划中考虑的项目包括但不限于F列za)每-组织单元的项目组织结构、职责和职权，包括外部组织sb)工程环境(适用时，用于开发、运作或维护)，包括测试环境、程序库、设备、设施、标准、规程和工具$c)生存周期过程和活动中包括要完成的软件产品、软件服务和

36、非交付项在内的工作分解结构，连同预算、人员、物理资源、软件规模和相关的任务进度安排gd)软件产品或服务的质量特性的管理，可以制订独立的质量计划;的软件产品或服务的安全、保密安全和其他关键需求的管理，可以制订独立的安全、保密安全96 GB/T 8566 2001 计划30分包方管理，包括分包方选择以及分包方与需方之间的参与，如果需要的话gg)质量保证(见6.3川h)验证(见6.4)和确认(见6.5) ;包括和验证机构以及确认机构的接口方式，如果有规定的话si )需方参与t通过诸如联合评审(见6.6)、审核(见6.7)、非正式会议、报告、修改和更改、实施、批准、验收和使用设施等方法;j)用户参与:

37、通过需求的设定活动、原理演示和评价等方法gk)风险管理2即对项目的包括潜在的技术、成本和进度安排风险等方面的管理，J)保密安全方针:即在每个项目组织一级上需要知道的和可以访问的信息的准则:m)诸如规章、所需的认证、专利权、使用权、所奋权、担保权以及许可证授予权等方面所要求的批准;n)进度安排、跟踪和报告方法;0)人员培训11(见7.4)。5.2.5 执行和控制此项活动包括下述任务:5. 2. 5. 1 供方应实施和执行5.2.4条中制定的项目管理计划。5.2.5.2 供方应:a)按照开发过程(5.3)开发软件产品;b)按照运作过程(5.4)运行软件产品sc)按照维护过程(5.5)维护软件产品。

38、5.2.5.3 供方应在合同确定的整个生存周期内监督和控制该项目的软件产品或服务的进度和质量。这应是连续的、反复进行的任务，它应提供-a)监督技术性能、费用和日程的进展，并报告项目状态gN问题的标识、记录、分析和解决。5. 2. 5. 4 供方应按照获取过程(5.1)管理和控制分包方。供方应传达所有必要的合同要求，确保交付给需方的软件产品或服务按照主合同要求开发或完成。5. 2. 5. 5 供方应按合同和项目计划中的规定与独立的验证、确认或测试机构接触。5. 2. 5. 6 供方应按合同和项日计划中的规定与其他各方接触。5.2.6 评审和评价此项活动包括下述任务:5. 2. 6. 1 供方宜协

39、调合同评审活动、接口，并与需方组织保持联系。5.2.6.2 供方应按合同和项目计划的规定与需方进行或支持非正式会议、验收评审、验收测试、联合评审和审核。联合评审应按6.6、审核应按6.7实施。5.2.6.3 供方应分别按照6.4和6.5进行验证和确认，以证实软件产品或服务和过程充分满足各自的需求。 5. 2. 6. 4 供方应按合同中的规定使需方能够得到评价、评审、审核、测试和解决问题的报告。5.2. 6. 5 供方应按合同和项目计划的规定，为了有效地进行软件产品或服务的评审，雳方可以使用供方和分包方的设施。5.2.6.6 供方应按6.3进行质量保证活动囚5.2.7交付租完成此项活动包括下述任

40、务z5.2.7.1 供方应按合同中的规定交付软件产品或服务。5.2. 7.2 供方应按合同中的规定，在所交付的软件产品或服务的支持中协助需方。97 GB/T 8566-2001 5.3 开发过程开发过程包括开发者的活动和任务。过程包括需求分析、设计、编码、集成、测试和与软件产品有关的安装和验收等活动。如果合同中有规定，它可以包括和系统有关的活动。开发者按照合同执行或支持这种过程中的活动。开发者按照管理过程(7.1)在项目级上管理本条中具体说明的开发过程。按照基础设施过程(7.2)建立该过程的基础设施;按照剪裁过程(附录A)为该项目剪裁本过程s按照改进过程(7.3)和培训过程(7.4)在组织级上

41、管理本过程。当开发者是所开发的软件产品的供方时、开发者要执行供应过程(5.2)。活动清单z本过程由下列活动组成:a)过程实施sb)系统需求分析;c)系统结构设计;d)软件需求分析ze)软件结构设计:f)软件详细设计;g)软件编码和测试;h)软件集成zi)软件合格性测试;j)系统集成;k)系统合格性测试s)软件安装gm)软件验收支持。5.3.1 过程实施此项活动包括下述任务:5. 3. 1. 1 如果合同中没有规定，开发者庇规定或选择适于项目范围、规模和复杂度的软件生存周期模型。开发过程的活动和任务应按生存周期模型选择和安排。注:这些活动和任务可以重叠或相互影响，并且可以重复地、周期地进行。5.

42、 3. 1. 2 开发者应2a)按照文档编制过程(6.1)形成输出文档gb)形成配置管理过程的输出(6.2)并按照它进行更改控制pc)按照问题解决过程(6.幻，用文档记录并解决在软件产品和任务中发现的问题和不致gd)按合同规定实施支持过程(第6章)。5. 3. 1. 3 开发者应选择、剪裁和使用那些已形成文挡的、恰当的、并由执行开发过程和支持过程(第6章)的活动的组织建立的标准、方法、工具和计算机编程语言(如果合同没有规定人5. 3. 1. 4 开发者应为开发过程活动的实施制订开发计划。计划应包括特定的标准、方法、工具、措施和与包括安全、保密安全在内的所有需求的开发、鉴定相关的职责。如果必要，

43、可以制订彼此独立的计划，这些计划应形成文档并执行。5. 3.1. 5 非交付项可用于软件产品的开发或维护。但应确保可交付软件产品在交付给需方后，它的运作和维护不受这些项的制约，否则，这些项应被考虑为可交付的。5.3.2 系统需求分析此项活动由下列任务组成，开发者应按合同要求执行或支持。5. 3.2. 1 应分析待开发系统的特定的预期使用要求，以规定系统需求。系统需求规格说明书应描述:系统的功能与能力;业务、组织和用户需求;安全、保密安全、人因工程人类工程学入接口、运作和维护需求;设计限制和鉴定需求。系统需求规格说明书应形成文挡。98 GB/T 8566-2001 5.3.2.2 应评价系统需求

44、，评价时要考虑下列准则。评价结果应形成文档za)需方要求的可追溯性5b)需方要求的-致性;c)可测试性zd)系统结构设计的可行性se)运作和维护的可行性。5.3.3 系统结梅设计此项活动由下列任务组成，开发者应按合同要求执行或支持。5.3.3.1 应建立系统的顶层结构。结构应标出硬件、软件和人工操作项。应确保所有系统需求分配到各项中。应顺序标出硬件配置项、软件配置项和手王操作项。分配到各项中的系统结构和系统需求应形成文档。5.3. 3.2 应评价项的系统结构和需求，评价时要考虑下列准则。评价结果应形成文档。a)系统需求的可追溯性;b)与系统需求的)致性;c)所使用的设计标准和方法的适宜性pd)

45、软件项满足指定需求的可行性;的运作与维护的可行性。5.3.4 软件需求分析对于每一个软件项或软件配置项，如果标识出)，此项活动由下列任务组成z5.3.4.1 开发者应建立软件需求并形成文档，包括下面描述的质量特性规格说明。软件质量特性规定见GB/T162600 a)功能与能力规格说明，包括性能、物理特性和软件项执行的环境条件$b)软件项的外部接口gc)鉴定需求:d)安全规格说明，包括那些与运作、维护相关的方法、环境影响和人为损坏ge)保密安全规定，包括那些与敏感信息相关的泄露;f)人因工程(人类工程学)规格说明，包括有关人工操作、人机接口、对人员的限制、需要人员集中注意力的区域，这些区域对人为

46、差错和培训是敏感的;g)资料定义和数据库需求;h)在运作和维护场所，对已交付的软件产品的安装与验收需求3i)用户文档gj)用户操作与执行需求;k)用户维护需求。5.3.4.2 开发者应评价软件需求，评价时要考虑下列准则。评价结果应形成文档za)系统需求和系统设计的可追溯性;b)与系统需求的外部一致性;c)内部一致性;d)可测试性p的软件设计的可行性;f)运作和维护的可行性。5.3.4.3 开发者应按照6.6实施联合评审。在成功地完成评审的情况下，应建立软件项需求的基线。5.3.5 软件结构设计对于每一个软件项或软件配置项，如果标识出)，此项活动由下列任务组成:99 GB/T 8566-2001

47、 5. 3. 5. 1 开发者应把软件项的需求转变为一种描述其顶层结构的结构图，并且标识出软件的各个部件。应确保所有软件需求分派到其软件部件，并且进一步细化以便于详细地设计。软件项的结构应形成文档。5.3.5.2 开发者应开发关于软件项的外部接口以及软件项的各个软件部件之间的接口的顶层设计，并形成文档。5. 3. 5. 3 开发者应编制数据库的顶层设计，并形成文档。5. 3. 5.4 开发者宜编制用户文挡的最初版本。5.3.5.5 开发者应规定软件集成的初步测试需求和进度安排，并形成文档。5. 3. 5. 6 开发者应评价软件项、接口和数据库设计结构，评价时要考虑下列准则，评价结果应形成文档:

48、a)软件项需求的可追溯性4b)与软件项需求的外部一致性sc)软件都件之间的内部一致性;d)所采用的设计方法和标准的适宜性;时详细设计的可行性;f)运作与维护的可行性。5. 3. 5. 7 开发者应按照6.6实施联合评审。5.3.6 软件详细设计对于每一个软件项(或软件配置项，如果标识出)，此项活动由下列任务组成:5. 3. 6. 1 开发者应编制软件项的每一软件部件的详细设计。软件部件应细化到更低级别的包含能被编码、编译、测试的软件单元。应确保所有软件项需求分派到从软件部件直到软件单元。详细设汁应形成文档。5. 3. 6. 2 开发者应开发关于软件项外部接口，软件部件之间以及软件单元之间的接口

49、的详细设计。接口的详细设计应允许在不需要更多信息的情况下编码。5. 3. 6. 3 开发者应编制数据库的详细设计并形成文档。5.3.6.4 需要时，开发者应及时更新用户文档。5. 3.6.5 开发者应规定要测试的软件单元的测试需求和进度安排，并形成文档。测试需求宜包括对软件单元在需求边界的强化要求。5. 3.6.6 开发者应及时更新测试需求和软件集成进度安排。5. 3. 6. 7 开发者应评价软件详细设计和测试需求，评价时要考虑下列准则。评价结果应形成文档:a)软件项需求的可追溯性;b)与结构设计的外部一致性;c)软件部件和软件单元之间的内部-致性gd)所采用的设汁方法和标准的适宜性;e)测试的可行性gf)运作与维护的可行性。5. 3. 6. 8 开发者应按照6.6实施联合评审。5.3.7 软件编码和测试对于每一个软件项(或软件配置项，如果标识出).此项活动由下列任务组成25. 3. 7. 1 开发者应开发下列各项并形成文挡za)每一个软件单元和数据库pb)为测试每一软件单元和数据库用的测试规程和资料。5. 3. 7.