某软件公司质量管理体系

秘密秘密仅限于内部使用质量管理体系培训教材〔一〕北京博思美亚科技开展公司目录TOC\o"1-2"\h\z\u公司标准软件过程体系文件导读1软件生命周期模型15软件开发过程25技术类评审111工程估算指南146标准软件过程总体裁剪指南152公司标准软件过程体系文件导读目录1、概述51.1目的51.2适用范围51.3引用文件51.4术语51.5参考资料52、公司标准软件过程的开发62.1开发历程62.2公司标准软件过程总体结构93、软件过程体系文件133.1过程管理143.2软件开发过程153.3工程管理153.4资源管理163.5指南性文件171、概述1.1目的本文件对公司软件过程及其体系文件的总体结构进行描述，为与软件过程的开发、维护、改良、执行、管理和跟踪等有关的人员学习、理解和使用软件过程体系文件提供指南。1.2适用范围适用于SEPG、高层经理、工程经理、软件开发人员、测试人员、软件质量保证人员、软件配置管理人员及其他支持人员为了按标准开展各自的业务活动，学习、理解和使用软件过程体系文件。1.3引用文件无。1.4术语无。1.5参考资料•《SoftwareProjectManagementGuidebook》〔Version2.0〕，ProcessStrategies，Inc.•《软件工程－实践者的研究方法》，〔美〕RogerS.Pressman著，黄柏素、梅宏译，机械工业出版社出版，1999年10月•《实践中的CMM－INFOSYS公司实施软件工程之过程》，潘卡•杰罗特著，杨慧鸣、李光龙泽，2001年7月2、公司标准软件过程的开发2.1开发历程为了使软件过程保持长期稳定并能持续改良，必须开发组织〔即公司〕级的标准软件过程。为此，公司组织了以软件工程过程组〔SEPG〕为主体的标准软件过程开发和文件编写组，具体实施上述任务。公司标准软件过程是在公司范围内的软件工程全面执行CMM二级的根底上，在软件工程一般理论的指导下，收集公司全部软件工程所采用的软件过程，经过分析、归纳、提炼、分类、总结等一系列步骤开发而成；又在开发标准软件过程的根底上，形成了描述这些标准软件过程的相互关联的程序文件体系。本程序文件体系对组成标准软件过程的根本软件过程要紧，以及软件过程要素之间的关系〔软件过程结构〕进行描述，描述的重点放在过程的可操作性上。此外，与此相关联，开发或编写了公司的软件过程数据库、与软件过程相关的文档库、软件生命周期描述文件和标准软件过程裁剪指南。它们和公司标准软件过程一起，组成了公司的软件过程资产。公司的软件过程资产为标准公司软件工程的软件过程提供了根底和保证。各软件工程按标准软件过程裁剪指南，根据工程的实际情况〔主要是客户需求〕对公司标准软件过程进行裁剪，开发适合工程特定特性的工程软件过程；工程软件过程开发的重点在软件过程的可用性，以及附加到该工程的价值。工程以工程定义的软件过程为根底，制订工程软件开发方案；按方案执行工程的软件开发活动，产生相应的软件工作产品及其他开发成果；开发过程中的数据以及工程结束后进行总结的数据，经过一定的手续，反应到公司的软件过程数据和软件过程相关文档库，丰富公司的软件过程资产。如此反复循环，促使软件过程得以持续改良。以上过程和关系可以用图1表示。图中：表示实体，例如“分配到软件的需求”表示活动，例如“选择工程的软件生命周期”图中上半局部用粗线框围起来的局部即公司的软件过程资产局部，它由描述公司标准软件过程的程序文件、软件过程数据库、与软件过程相关的文档库、软件生命周期描述文件和标准软件过程裁剪指南组成。下半局部那么描述公司软件过程资产的利用过程：软件工程按标准软件过程裁剪指南，根据工程的实际情况〔主要是客户需求〕对公司标准软件过程进行裁剪，开发适合工程特定特性的工程软件过程；制订工程软件开发方案，并按方案执行工程的软件开发活动；将工程数据〔包括开发过程中的数据以及工程结束后进行总结的数据〕反应到公司的软件过程数据库和软件过程相关文档库。图1公司软件过程资产的开发和利用2.2公司标准软件过程总体结构图2为公司标准软件过程的总体结构。由于本公司的产品〔工程〕除了纯软件产品〔工程〕外，还包括软件和硬件兼有的产品〔工程〕，考虑到过程的完整性以及便于理解软件过程和其他过程之间的接口关系，图中的工程开发过程反映了软件和硬件兼有的产品的整个开发过程，但其中非软件过程局部均采用虚线，以示区别。有关内容说明如下：〔1〕工程、工程生命周期和软件生命周期工程是由一组有起止日期、相互协调的受控活动组成的独特过程，该过程要求到达符合包括时间、本钱和资源等约束条件在内的规定要求的目标，其结果将产生产品。而软件工程那么是为了开发软件产品〔包括系统〕而建立的工程。工程和产品都具有一定的生命周期。工程生命周期是指从工程启动到工程结束为止的时间间隔。工程生命周期一般包括：•初期筹划阶段〔主要是可行性分析〕；•开发筹划阶段〔开发前的人、财、物等的方案和准备〕；•实施阶段〔具体实施工程开发方案，保证工程的质量、本钱、进度的顺利完成〕；•结束阶段〔评审、鉴定及工程交付和组织结束工作〕。在整个工程生命周期，所涉及的过程可以分为两类：•工程开发过程〔和被开发产品的实现直接相关〕；•工程管理过程〔对工程的开发过程进行管理和控制〕。软件生命周期那么是指软件产品的生命周期，即是指从设想－软件产品开始到软件不再供使用为止的时间间隔。软件生命周期一般包括：概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和调整阶段、运行和维护阶段，有时还包括退役阶段。显然，工程生命周期和软件生命周期在时间上是相关的，但在概念上是完全不同的。一般来说，工程生命周期不会超过该工程所开发的软件产品的生命周期。〔2〕工程开发过程图中的下部表示工程的开发过程。它从客户需求开始，通过系统分析，将客户需求分解成软件局部的需求和硬件局部的需求〔从此处工程将分成软件工程和硬件工程两局部〕。其中，软件工程从软件需求定义阶段、设计阶段、实现阶段、测试阶段、验收交付阶段到工程总结，表示整个软件开发的结束。一般来说，作为软件开发工程到此就意味着结束了，但软件产品的生命周期并未结束。软件产品交付后，将经历使用过程中的维护阶段〔维护阶段的时间可能和工程合同有关〕，直到最后产品退役。〔3〕工程管理过程图中的中部表示工程的管理过程，即对工程的开发过程实施管理的过程。对于软件和硬件兼有的工程来说，工程管理的主要过程如下：•初期筹划〔主要针对系统分析、可行性分析进行筹划〕；•开发筹划〔开发前的人、财、物等的方案和准备〕；•工程跟踪与监控〔对工程初期的系统分析、可行性分析，以及工程开发过程中软件需求定义、设计、实现、测试、验收交付等活动进行跟踪与监控〕；•软件质量保证〔SQA，对工程的软件过程和软件产品的符合性进行质量监控，它贯穿于软件工程的始终〕；•软件配置管理〔SCM，为确保软件产品的完整性和正确性进行的管理，它贯穿于软件工程的始终〕；•需求管理〔为确保满足客户需求进行的管理，它贯穿于工程的始终〕；•评审过程〔包括同行评审等技术类评审和方案评审等管理类评审〕；•工程结束处理〔包括工程的鉴定、验收、交付，以及进行工程总结〕。此外，在工程管理活动中，还可能有以下管理过程：•工程培训；•组间协调等。〔4〕过程资产本公司的软件过程资产分两个层次：公司级资产和工程级资产。a.公司级资产包括：•过程数据库〔含软件过程和其他过程的资产〕；•过程相关文档库；•人力资源库。b.工程级资产包括：•工程控制数据库〔工程经理控制，用于保存工程数据，以便对工程进行跟踪与监控〕；•SQA管理库〔SQA控制，用于保存工程的软件质量保证数据〕；•SCM管理库〔SCM控制，用于保存工程的软件配置管理数据〕；•SCM库〔SCM控制，用于保存工程的所有配置项〕。通过一定的手续，工程的工程控制数据库和SQA管理库中的数据，经过选择，将补充到公司的过程数据库和过程相关文档库中。此外，根据实际需要，总部一级也可能需要有人力资源库。图2软件过程结构图3、软件过程体系文件公司的软件过程体系文件的组成如图3所示。软件过程体系文件软件过程体系文件过程管理工程管理软件开发过程资源管理指南性文件软件开发过程程序文件标准软件过程开发与维护过程描述文件编写标准〔一〕过程描述文件编写标准〔二〕质量管理体系数据库管理和维护文件软件生命周期模型描述文件标识标准术语文件控制程序客户需求管理程序文件工程筹划程序文件工程跟踪与监控程序文件工程总结程序文件软件质量保证程序文件软件配置管理程序文件组间协调程序文件技术类评审程序文件高层验证程序文件培训程序工程估算指南标准软件过程总体裁剪指南公司标准软件过程体系文件导读图3软件过程体系文件按文件的使用目的，公司的软件过程体系文件分为五类：过程管理、软件开发过程、工程管理、资源管理和指南。3.1过程管理过程管理是指对软件过程进行管理，此类文件的使用人员主要是对软件过程进行开发、维护、改良的人员，例如SEPG成员、工程经理、SQA等。有关文件说明如下：〔1〕标准软件过程开发与维护•使用人员：SEPG和软件过程描述文件编写人员。•内容提要：本文件对如何开发和管理公司的标准软件过程、如何编写软件过程描述文件、如何编写标准软件过程裁剪指南等作出了规定。〔2〕过程描述文件编写标准〔一〕•使用人员：软件过程描述文件编写人员。•内容提要：为能分解成假设干过程元素的较大过程编写的描述文件编写标准。〔3〕过程描述文件编写标准〔二〕•使用人员：软件过程描述文件编写人员。•内容提要：为没有明显的入口和出口准那么的过程〔例如日常管理类的过程〕编写的描述文件编写标准。〔4〕质量管理体系数据库管理和维护文件•使用人员：SEPG、工程经理、SQA和数据库的管理和维护人员。•内容提要：本文件对公司的软件过程数据库和与过程相关文档库的管理和维护作出了规定。考虑到将来需要扩充ISO9001要求的其他数据库，故起此名。〔5〕软件生命周期模型描述文件•使用人员：工程经理以及参与工程软件过程定义的有关人员。•内容提要：本文件对公司所确定的软件生命周期模型进行描述，作为公司的过程资产之一，供工程选择适合工程情况的软件生命周期模型时参考。〔6〕标识标准•使用人员：对被标识对象进行标识的人中员。•内容提要：为标准包括文件、表格、产品的标识而制订的标准。〔7〕术语•使用人员：SEPG和软件过程描述文件编写人员。•内容提要：本文件定义了本软件过程体系文件所使用的专用术语。〔8〕文件控制程序•使用人员：文件管理人员。•内容提要：本文件对文件的编写、评审、批准、发布、发放、回收等文件管理要求作出了规定，是整个质量管理体系所要求的用于对受控文件进行管理的文件。3.2软件开发过程软件开发过程是指与软件开发有关的过程，相关文件的使用人员主要是和软件开发有关的人员。〔9〕软件开发过程程序文件•使用人员：工程经理以及参与工程软件过程定义的有关人员。•内容提要：本程序文件针对本公司软件工程所采用的典型开发过程，分解成过程要素进行描述，供各软件工程根据标准软件过程裁剪指南，定义工程自己的软件过程时使用。3.3工程管理与工程管理有关的文件如下：〔10〕客户需求管理程序文件•使用人员：工程经理、SQA、SCM和软件开发人员。•内容提要：本文件是为了确保工程满足客户需求和如何确保满足客户需求，为工程编写的有关客户需求管理的程序文件。〔11〕工程筹划程序文件•使用人员：工程经理以及参与工程筹划的其他有关人员。•内容提要：为指导软件工程进行工程的初期筹划和开发筹划而编写的程序文件。〔12〕工程跟踪与监控程序文件•使用人员：高层经理、工程经理、SQA、SCM和软件开发人员。•内容提要：指导软件工程在工程方案执行过程中如何对工程进行跟踪与监控的程序文件。〔13〕工程总结程序文件•使用人员：工程经理、SQA、SCM和软件开发人员。•内容提要：指导软件工程在工程结束阶段如何进行工程总结的程序文件。〔14〕软件质量保证程序文件•使用人员：SQA、工程经理、SCM和软件开发人员。•内容提要：指导软件工程的SQA如何执行工程的软件质量保证活动，以及工程的其他人员如何配合的程序文件。〔15〕软件配置管理程序文件•使用人员：SCM、工程经理、SQA和软件开发人员。•内容提要：指导软件工程的SCM如何执行工程的软件配置管理活动，以及工程的其他人员如何配合的程序文件。〔16〕组间协调程序文件•使用人员：工程经理、SQA、SCM和软件开发人员。•内容提要：工程在进行工程筹划时，应考虑有无组间协调的情况，本程序文件提供这方面的要求和指导。〔17〕技术类评审程序文件•使用人员：工程经理、软件开发人员、SQA以及其他参与评审的人员。•内容提要：本程序文件为工程进行技术类评审〔包括同行评审及其他类型的技术评审〕规定要求和提供指导。〔18〕高层验证程序文件•使用人员：高层经理、工程经理、SQA、SCM和软件开发人员。•内容提要：在公司标准软件过程的开发和改良以及工程在执行软件开发活动的过程中，高层经理应在哪些环节进行验证，如何进行验证？工程的有关人员如何配合？本程序文件为高层经理的验证活动提出要求并提供指导。3.4资源管理资源管理主要包括人力资源、设备、环境等方面的管理。〔19〕培训程序•使用人员：公司培训组、高层经理、工程经理、SQA、SCM和软件开发人员。•内容提要：对公司级培训和工程级培训的实施要求作出规定，包括培训需求的收集、培训方案、培训实施和培训总结等。3.5指南性文件目前提供以下指南性文件：〔20〕工程估算指南•使用人员：工程经理及其他参与估算的人员。•内容提要：本指南为工程估算的方法〔例如：规模估算、工作量估算等〕提供指南。〔21〕标准软件过程总体裁剪指南•使用人员：工程经理及其他参与工程软件过程定义的人员。•内容提要：总体裁剪指南是公司标准软件过程裁剪指南中的高层裁剪指南〔或一般性裁剪指南〕。它为软件工程在对公司标准软件过程进行裁剪时，提供对一般性活动进行裁剪的指南；裁剪结果为工程进行详细的过程裁剪提供框架性的指导方针〔详细裁剪指南分散在各程序文件的“详细裁剪指南”中〕。〔22〕软件过程体系文件导读〔即本文件〕•使用人员：SEPG、高层经理、工程经理、软件开发人员、测试人员、软件质量保证人员、软件配置管理人员等为了按标准开展各自的业务活动，需要学习、理解和使用软件过程体系文件的所有人员。•内容提要：对公司标准软件过程开发的背景、开发过程、标准软件过程的总体结构，以及相应的软件过程体系文件进行导读性的说明。软件生命周期模型目录1、概述161.1目的161.2适用范围161.3引用文件161.4术语161.5参考资料162、软件生命周期模型描述172.1瀑布模型172.2原型＋瀑布模型182.3增量模型192.4增量的迭代过程模型212.5快速应用开发模型213、几种模型的比拟234、其它模型采用说明235、附录231、概述1.1目的描述公司级定义的软件生命周期模型，供工程筹划时根据工程的具体情况选择或裁剪使用，由此确定软件工程开发过程的各种不同的阶段以及各阶段的执行顺序。1.2适用范围适用于本公司的软件工程筹划。1.3引用文件•《软件开发过程程序文件》〔QMS-OP01-V1.0〕•《标准软件过程开发和维护》〔QMS-PSM01-V1.0〕•《工程筹划程序文件》〔QMS-PTM02-V2.0〕1.4术语•软件生命周期－从软件设想开始到软件不再使用而结束的时间周期。软件生命周期一般包括系统分析、软件需求分析、设计、实现、测试、验收、运行和维护各阶段，有时还包括退役阶段。•软件过程－有关开发和维护软件及其相关产品〔例如：工程方案、设计文档、代码、测试用例、用户手册等〕的活动、方法、实践和变更的集合。1.5参考资料•《软件工程Java语言实现》，StephenR.Schach著，袁兆山等译，机械工业出版社，1999年9月•《软件工程实践者的研究方法》，RogerS.Pressman著，黄柏素、梅宏等译，机械工业出版社，1999年10月•《SoftwareProjectManagementGuidebook》，FrankJ.Koch著，2001年7月•《实用软件工程》郑人杰、殷人昆、陶永雷著，清华大学出版社，1997年4月•《软件需求》，KarlE.Wiegers著，陆丽娜、王忠民、王志敏等译，机械工业出版社，2000年7月•《统一软件开发过程》，IvarJacobson、GradyBooch、JamesRumbaugh著，周伯生、冯学民、樊东平等译，机械工业出版社，2002年1月2、软件生命周期模型描述所有的工程软件开发过程都应遵循一个生命周期模型，每个模型都具有能够帮助实际软件工程进行控制及协调的特征。定义生命周期模型的目的在于将本质上无序的活动有序化，在开发筹划期间，必须仔细考虑工程的特征和目标之后，再选择生命周期模型。本文件根据组织内工程的类型，描述常用的几个软件生命周期模型，工程可根据实际情况选择或按规定剪裁使用，但应注意与公司的标准软件开发过程相兼容。见附录“软件过程结构图”，其中的工程软件开发过程即为一个选择瀑布模型的典型工程过程。2.1瀑布模型〔1〕模型描述该模型首先由Royce[1970]提出，又称线性顺序模型，包括图2－1所示的典型的几个阶段，其重要特点是：只有当一个阶段的文档已编制好，且该阶段的产品得到SQA认可后，该阶段才算完成；测试或验证在每个阶段都必须执行；一旦产品完成提交用户，其后的任何修改均属于维护阶段。如果需求明确、能较好理解且较稳定，可以考虑选择瀑布模型。图2－1瀑布模型〔2〕缺点由于其线性顺序的特点，故只有在工程开发的后期才能得到具有全部功能的软件版本；如果有未定义或未实施的需求，将会引起重复劳动，甚至开发出的产品不是用户所需要的。〔3〕本企业适合的工程类型操作系统产品；译星产品；嵌入式产品开发；对日软件外包工程等。2.2原型＋瀑布模型〔1〕模型描述原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型只是真实系统的一局部或一个模型，完全可能不完成任何有用的事情，通常包括抛弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型那么是对需求的定义较清楚的情形，原型建立之后要保存，作为系逐渐增加的根底，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成工程开发，原型＋瀑布模型的开发流程如图2－2所示：屡次迭代原型逐渐完善屡次迭代原型逐渐完善局部系统软件需求或软件需求分析原型设计原型实现原型测试瀑布测试图2－2原型＋瀑布模型以下情形建议考虑选择原型＋瀑布模型：a.工程包含一种新技术，例：新硬件、新的开发语言、新的系统架构等；b.需求不很清楚；c.存在关于性能、可靠性和可行性方面的主要的、未解决的问题；d.用户界面对系统成功是很关键的，但不很清楚。〔2〕缺点由于原型并非最终产品，如果原型不能利用，可能导致本钱的增加；同时会引起客户的误解，以为产品即将完成。〔3〕本企业适合的工程类型新领域的应用工程的开发；Web开发工程等。2.3增量模型〔1〕模型描述增量模型是一种进化软件过程模型，融合了线性顺序模型的根本成分〔重复地应用〕和原型模型的迭代特征，如以下图所示。当使用增量模型时，第一个增量往往是核心产品，即实现了根本的需求；核心产品交用户使用〔或进行更详细的复审〕，使用和/或评估的结果是下一个增量的开发方案，该方案包括对核心产品的修改，使其能更好的满足用户的需要，并发布一些新增的特点和功能。增量模型和原型模型不一样，强调每一个增量均要发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但能提供用户效劳功能和用户评估的平台。增量模型开发流程见图2－3。系统系统分析软件需求分析软件结构设计详细设计1实现1测试1验收1详细设计2实现2测试2验收2详细设计n实现n测试n验收n维护增量1增量2增量n图2－3增量模型〔2〕缺点由于增量模型的灵活性，往往容易退化成边做边改方法，使软件过程的控制丧失了整体性，最终的产品也不是开放的，而是成为维护人员的恶梦。〔3〕本企业适合的工程类型各种中、大规模的工程类型；已有系统技术路线发生改变但需求明确的移植类工程。2.4增量的迭代过程模型〔1〕模型描述该模型是一个不断迭代和增量的过程，迭代过程首先要处理一组客户的业务需求，这些业务需求合起来能够揙所开发产品的可用性。其次，迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。一个增量不一定是对原有产品的增加，尤其在生命周期初期，开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。在较后的阶段，增量通常是对原有产品的增加。采用此种模型最好是基于构件和有相应的构件开发工具〔如：RUP、配置管理工具等〕。迭代迭代1系统分析1软件需求分析1设计1实现1测试1验收1系统分析2软件需求分析2设计2实现2测试2验收2系统分析n软件需求分析n设计n实现n测试n验收n迭代2迭代3维护图2－4增量的迭代模型〔2〕缺点需要相当的风险评估的技术；每个迭代循环控制不好会变成边做边改模式。〔3〕本企业适合的工程类型较复杂的应用工程。2.5快速应用开发模型〔1〕模型描述快速应用开发模型〔RAD〕是一个线性顺序的软件开发模型，强调极短的开发周期〔2－3个月〕。该模型是线性顺序模型的一个“高速”变种，如果需求理解得很好，且约束了工程范围，就可通过使用基于构件或可得用软件包的建造方法获得快速开发。快速应用开发模型流程见图2－5。适用于信息系统应用软件的开发。小组小组1业务建模1数据建模1处理建模1应用生成1测试1业务建模2数据建模2处理建模2应用生成2测试2业务建模n数据建模n处理建模n应用生成n测试n集成/测试验收维护小组2小组n图2－5快速应用开发模型〔2〕缺点对大型的、但可伸缩的工程，RAD需要足够的人力以创立足够的RAD小组。RAD要求开发者和用户在一个很短的时间内完成一个系统，如果双方中的任何一方没完成约定，都会导致RAD工程失败。〔3〕本企业适合的工程类型具有可重用的构件库和CASE工具的应用工程；信息系统等。3、几种模型的比拟软件生命周期模型是否首先定义好绝大局部的需求？是否有多个开发周期？是否有中间软件发布瀑布模型有无无原型＋瀑布模型没有有有增量模型有有可能增量的迭代模型没有有有快速应用开发模型没有有可能4、其它模型采用说明如果在实际工作中，基于特定工程的经验积累和总结，可能需要形成新的软件生命周期模型，此时可依照一定的规程〔参见《标准软件过程开发和维护要求》、《工程筹划程序文件》〕将其定义和描述参加到本文件中。5、附录附录1软件过程结构图说明：图中“工程软件开发过程”一层延伸到产品退役，即表达出软件的生命周期。采用不同的生命周期模型在该层面的“系统分析”和“软件开发”阶段对应不同的过程。软件过程结构图软件开发过程目录1、概述291.1目的291.2适用范围291.3引用文件291.4术语291.5参考资料302、过程总体描述302.1过程概述302.2结构描述312.3过程级裁剪指南323、过程元素333.1系统分析333.2软件需求分析383.3结构设计453.4详细设计483.5编码533.6集成测试563.7系统测试603.8验收633.9验收673.10软件问题管理714、附录74附录2.3－1中大型软件工程工程的标准软件开发过程75附录2.3－2中小型软件工程工程的标准软件开发过程76附录2.3－3小型软件工程工程的标准软件开发过程77附录3.1－1《系统架构和业务需求说明书》文档编写标准78附录3.1－2《可行性分析报告》文档编写标准80附录3.1－3《系统需求规格说明书》文档编写标准81附录3.2－1需求分析方法指南87附录3.2－2结构化分析法88附录3.2－3面向对象分析法〔OOA〕89附录3.2－4快速原型法90附录3.2－5《软件需求规格说明书》文档编写标准91附录3.2－6《测试方案》文档编写标准95附录3.3－1《软件结构设计说明书》文档编写标准97附录3.4－1《软件详细设计说明书》文档编写标准101附录3.5－1《测试报告》文档编写标准103附录3.6－1集成工作单104附录3.6－2集成测试工作单105附录3.9－1《软件维护实施方案》文档编写标准106附录3.10－1软件问题报告单107附录3.10－2软件问题状态登记表1121、概述1.1目的本程序文件定义了公司内部的软件开发过程，以指导和标准软件工程中开发过程的定义和相应的实施。1.2适用范围整个公司内的软件工程。1.3引用文件《过程描述文件编写标准〔一〕》〔QMS-PSM02-V1.0〕《标准软件过程的开发和维护》〔QMS-PSM01-V1.0〕《软件生命周期模型描述文件》〔QMS-PSM05-V1.0〕《客户需求管理程序文件》〔QMS-PTM01-V2.0〕《技术类评审程序文件》〔QMS-PTM09-V1.0〕《软件配置管理程序文件》〔QMS-PTM09-V1.0〕《术语》〔QMS-PSM07-V1.0〕1.4术语•过程：把输入转换为输出的一组彼此相关的活动。•构造：将源代码进行编译、连接、生成目标代码的过程。•构造环境：主要指与源码一起进行编译、连接的环境，在C语言中一般是指由编译、连接命令、环境参数、操作语句等构成的一系列脚本程序的组合。•白盒测试：基于源码进行的测试，主要的形式包括语句覆盖、分支覆盖、路径覆盖等。•黑盒测试：基于目标代码的测试，主要的形式为功能测试。•回归测试：对新增的功能或更正错误的局部〔包括与其相关的局部〕进行的测试，而不是对软件系统全面的测试。其他术语参见《术语》文件。1.5参考资料•《软件能力成熟度模型CMM方法及其应用》，杨一平等著，人民邮电出版社，2001年4月•《实践中的CMM－INFOSYS公司实施软件工程之过程》，潘卡·杰罗特著，杨慧鸣、李光龙泽，2001年7月•《ManagingtheSoftwareProcess》WattsS.Humphrey,AddisonWesleyLongman,Inc,1989•《RecommendedApproachtoSoftwareDevelopment》SEL-81-305，1992.6•《软件需求》，KarlE.Wiegers著，陆丽那、王忠民、王志敏等译，机械工业出版社，2000年7月•《软件工程Java语言实现》，StephenR.Schach著，袁兆山等译，机械工业出版社，1999年9月•《软件工程实践者的研究方法》，RogerS.Pressman著，黄柏素、梅宏等译，机械工业出版社，1999年10月•国际－信息技术－软件生存周期过程指南GB/T8566-2002•军标－软件开发与文档编制SJ20778-20002、过程总体描述2.1过程概述软件开发过程是指软件产品开发活动中所有阶段、任务的组合。该过程可划分为一系列子过程，包括：系统分析、软件需求分析、设计、编码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如设计过程又可分为结构设计和详细设计。本程序文件描述公司通用的软件开发过程的组成〔称之为“过程元素”〕、彼此之间的关系〔输入、输出接口〕，以及相应的裁剪指南。具体的软件开发工程可以根据其范围、规模和复杂度，确定软件生命周期模型，参见《软件生命周期模型描述文件》；然后根据通用的软件开发过程和裁剪指南，确定工程具体的软件开发过程。本程序文件涉及的裁剪指南分为两个层次，一层为过程级，主要针对不同的工程所采取的过程的剪裁，以定义不同的典型过程；另一层为过程元素内部，主要针对元素内部的各个任务的剪裁。2.2结构描述软件开发过程在整个标准软件过程中的位置及组成见以下图2.2－1。图2.2－1软件过程结构图本程序文件所描述的软件开发过程的元素的组成见下表：过程元素阶段需求分析设计实现测试验收维护系统分析√软件需求分析√结构设计√详细设计√编码√集成测试√√系统测试√验收√维护√每个过程元素的具体描述和工作要求见本程序文件第三节的“过程元素”描述。2.3过程级裁剪指南活动可裁剪属性选择裁剪指导方针开发过程全过程〔附录2.3－1〕执行执行针对中大型软件工程工程或系统需求明确完全自行设计、实现的工程简化过程1－1〔附录2.3－2〕执行执行针对中小型软件工程工程自编/移植软件简化过程1－2〔附录2.3－2〕执行执行针对中小型软件工程工程自由软件简化过程2－1〔附录2.3－3〕执行执行针对小型软件工程工程自编/移植软件简化过程2－2〔附录2.3－3〕执行执行针对中小型软件工程工程自由软件软件开发过程中的技术类评审方式见《技术类评审程序文件》中相应裁剪指南3、过程元素以下分别对软件开发过程中的各个元素进行描述。3.1系统分析元素概述系统分析的目的是形成一个清楚的、完整的、一致的和可验收测试的系统需求规格说明书，与其它过程元素的关系如以下图所示：软件需求分析软件需求分析硬件设计、实现、集成系统分析系统需求规格说明书系统分配给软件的需求系统分配给硬件的需求来自客户的需求系统架构和业务需求说明书可行性分析报告来自客户的需求可以是招标书、工程说明书或意向书等任何形式的客户需求。系统分析是整个软件生命周期的开始，应分析待开发系统特定的预期使用要求，以规定系统需求。在此阶段，系统工程组要用一种反复迭代的方法逐渐扩充、完善系统需求，使其到达完整；对系统结构进行设计，建立系统的顶层结构，并标出硬件局部、软件局部和人工操作局部。应确保所有系统需求分配到各局部中。分配以各局部的系统需求及其相关系统结构应形成文档，对软件必须要实现的每个功能和每个要满足的关键点进行详细描述。通过实施本过程元素，完成《系统架构和业务需求说明书》〔附录3.1－1〕《可行性分析报告》〔附录3.1－2〕和《系统需求规格说明书》〔附录3.1－2〕，为软硬件开发人员正确建立所要求的系统提供根底。如上图所示，《系统需求规格说明书》应包括分配到软件局部的需求和分配到硬件局部的需求两局部。但在本文件中，如无特别说明，系统需求均指系统分配给软件局部的需求，也属于客户需求；《系统需求规格说明书》均指系统分配给软件局部的需求的规格说明书。入口准那么和出口准那么〔1〕入口准那么要素判断准那么招标书、工程说明书或意向书等客户需求已接受〔2〕出口准那么要素判断准那么可行性分析报告经过评审并批准执行系统架构和业务需求说明书系统需求规格说明书进行了评审并经SCCB批准作为客户需求基线评审发现的问题已关闭任务〔1〕系统架构和业务需求定义及系统可行性分析，具体过程如以下图所示：业务需求定义系统架构和业务需求定义系统架构和业务需求评审可行性分析重用分析系统架构识别来自客户的需求来自早期工程的文档来自客户的需求系统架构和业务需求书可行性分析报告a.系统架构识别•收集和逐条列出所有系统的高层需求〔指最高层的产品业务目标〕。•描述满足这些高层需求系统必须实施的根本功能，着重从系统寿命〔使用期限〕、性能、平安、可靠性和数据项等方面的问题去考虑。•通过这些功能描述，得到识别软件程序和所有主要接口的系统架构。•详细说明所有主要数据接口的格式〔如：文件、显示、打印输出等〕。b.重用分析•如果客户要求的功能与已有的产品很相似，那么可评审已有的产品的《系统架构和业务需求说明书》、《系统需求规格说明书》、《用户手册》和相关源代码等来识别重用候选项。选择较强的候选荐并估算相应的本钱，评价其可靠性等，根据将开发工程的具体情况，对是否选用重用项作出一个相对折中的选择。•调整体系结构来说明采用的可重用软件，把所有重用分析的结果以重用建议的形式记录下来，写入《系统架构和业务需求说明书》文档中。c.业务需求定义•清楚地定义系统必须如何在其业务环境下运行，包括针对所有主要业务模式的业务方案脚本，又称使用实例。形成的描述写入《系统架构和业务需求说明书》文档。•由于最终用户是系统的直接使用者，需要时可请他们作为产品代表，帮助建立业务方案脚本。d.系统架构和业务需求的评审•就系统架构和业务需求请系统和领域专家进行评审。e.可行性分析•在上述结果的根底上，进一步分析高层需求，从技术、经济、商业以及管理等方面进行可行性研究。•编写《可行性研究报告》。•对可行性分析报告进行评价，作出工程是否可行的判断和决策。如果工程可行，那么进入下一过程；否那么终止系统分析。〔2〕开发系统需求系统需求的开发过程如以下图所示。a.细化需求•基于高层需求和系统概念及体系结构，向下定义子系统层的所有需求，即细化的用户工作流程。如果系统很大〔有很多子系统〕或如果将与其它系统接口，就要清楚地定义所有外部接口。•确定系统性能和可靠性需求。如果某个接受准那么对应到某条需求〔如：满足特定的响应时间〕，那么需说明这条需求的测试准那么。b.编写系统需求规格说明书•在用户已有业务系统的层面，识别需要满足需求的输入和输出的数据，用结构化或面向对象的分析方法，派生出软件必须实施的底层功能和算法。定义所有的文件、报告和显示等，并指出哪些数据用户必须能够修改等。•保持设计和语言的中立性，即集中在软件需要做什么方面，而不是怎么做。•创立一个追溯矩阵来映射每个底层的功能或数据说明使其能够得到实现。•将上述结果形成文件，完成《系统需求规格说明书》的编写，作为软件开发的根底。c.系统需求规格说明书评审•对《系统需求规格说明书》进行同行评审。评审后的《系统需求规格说明书》必须经SCCB批准，作为需求基线，纳入配置库。工作产品•《系统架构和业务需求说明书》•《可行性分析报告》•《系统需求规格说明书》•《追溯表》〔MT-PTM01B〕〔MT-PTM01C〕职责〔1〕系统工程组：负责完本钱过程元素所要求的所有活动，并填写《追溯表》〔见《客户需求管理程序文件》〕。〔2〕工程经理：负责制订系统分析阶段的方案〔在执行过程中可能需要进行方案修订〕；管理、度量此过程，并负责安排同行评审。〔3〕SCM：统计已定义的需求项的个数和已进行说明的需求的百分比，填写《客户需求统计表》〔见《客户需求管理程序文件》〕。资源和能力要求•必要的培训资源•支持系统需求分析的设备•支持系统需求分析的工具度量•统计已定义的需求项的个数和已进行说明的需求的百分比•质量〔同行评审缺陷统计〕•完本钱元素的工作所花费的工时详细裁剪指南活动可裁剪属性选择裁剪指导方针系统构架和业务需求定义及系统可行性分析系统架构识别执行执行新工程或有新的需求的工程不执行无需修改客户需求的工程进行重用分析执行执行有可重用构件库或是已有版本的产品不执行新产品或无可重用构件库业务需求定义执行执行新工程或要修改业务需求定义的工程不执行无需修改业务需求定义的工程文档编写规模较大的、复杂的工程不编写规模较小的工程或快速原型开发；可与系统需求规格说明书合并。系统架构和业务需求说明书评审执行执行规模较大的、复杂的工程不执行规模较小的工程可不进行，将其放到系统需求说明规格说明书中一起评审。可行性分析执行执行对系统需求能否实现不清楚不执行对系统需求能否实现清楚文档编写规模较大、较复杂的工程上，执行了可行性分析活动，要求出此报告。不编写规模较小、无需执行可行性分析活动；或规模较大、较复杂的工程，执行了可行性分析活动，但不要求单独出此报告，可合并到系统需求规格说明书中。开发系统需求细化需求执行执行新工程或需求需要进一步细化的工程不执行针对旧工程，细化的需求已存在3.2软件需求分析元素概述软件需求分析是按照工程定义的软件开发过程，根据系统分配给软件的需求〔见《系统需求规格说明书》〕，进行软件质量特性规格说明的过程。该过程包括进一步明确软件运行环境，明确对软件的功能、性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化，即完成对软件需求的分析与规格定义。有关软件需求的变更管理，请参见《软件配置管理程序文件》。本元素在整个过程中的位置如以下图所示：软件需求分析软件需求分析结构设计系统分配给软件的需求入口准那么和出口准那么〔1〕入口准那么要素判断准那么客户需求〔《系统需求规格说明书》〕•已由SCCB批准为基线•已进入配置库〔2〕出口准那么要素判断准那么软件需求规格说明书•已经过审查•已批准为开发基线•已进入配置库系统测试方案•已经过审查•已获得批准•已进入配置库系统测试案例用户手册〔概要〕•已编写任务各工作阶段如以下图所示：定定义收集•分析评审准备系统分配给软件的需求软件需求规格说明书〔1〕准备阶段a.必要时对软件需求分析员进行相关培训〔包括有关的技术和业务知识培训，以及有关的工具使用培训〕。b.审查客户需求，识别并解决影响软件需求的问题。c.选择适当的需求分析方法〔参见附录3.2－1、附录3.2－2、附录3.2－3、附录3.2－4〕，并准备相应的分析工具。建议采用的需求分析方法包括：结构化分析法、面向对象分析法和快速原型法等。如果需要采用上述分析法以外的其它需求分析法，应该得到SEPG的批准。•结构化分析法采用结构化的分析技术。后续过程〔设计、实现〕通常也应该采用结构化技术。适用于中、小规模的软件工程。•面向对象分析法采用面向对象的分析技术。后续过程〔设计、实现〕通常也应该采用面向对象技术。适用于各种规模的软件工程。•快速原型法借助快速开发工具，以提供原型的方式，迅速掌握客户对软件的需求。适用于客户描述不清楚对软件的全部或局部需求。建立满足客户需求的原型后，根据所采用的工具和实际需要确定是否重新进行软件需求规格定义。快速原型不能作为惟一的软件需求规格表达方式，必须辅之以适当的软件需求规格说明书。快速原型法可以与结构化分析或面向对象分析技术结合使用。〔2〕收集、分析阶段本阶段需要与客户不断接触、协商。通过对收集到的信息进行分析、归纳，界定出对软件的需求，明确在目标产品中需要什么和以什么形式来表现。与客户交流的根本形式通常有两种：客户访谈调查〔正式的和非正式的〕、书面调查〔书面报告和调查表〕。此外，通过对客户使用的表格和所处的情景进行分析，从而获取需求，也是常用的方法。这些方法对前面推荐的三种需求分析中采用的分析法与后续过程的设计和实现方法有一定的关联关系，通常应该保持所选用的表达方法一致。详见需求分析方法指南。除了调查客户正常业务处理要求以外，特别需要关注的是异常处理和例外处理要求。这些处理要求往往在软件需求中占有很大的比例，却容易被无视。收集、分析可重用的软件或功能模块，确定可用项。本阶段的工作步骤如下：•编制工作方案，特别是与受访者协商确定调查、访谈日程安排。•运用选定的需求分析方法，收集、识别是、导出软件需求。•收集、筛选、确定可能重用的软件或功能模块。〔3〕定义阶段a.根据软件需求分析结果，选择适当的实现方案并说明选择理由，形成软件系统的初步设计方案〔包括对系统体系结构、数据体系结构和接口的初步设计〕。b.描述软件需求规格，编制《软件需求规格说明书》〔附录3.2－5〕。c.编制用于验证和确认软件需求是否得到满足的方法－《系统测试方案》和《系统测试案例》，测试方案的编写标准见附录3.2－6。d.建立《用户手册》〔概要〕。e.填写追溯表。参见《客户需求管理程序文件》。〔4〕评审阶段a.评审《软件需求规格说明书》，具体评审过程见《技术类评审程序文件》，对软件需求的评审准那么包括：•系统需求和系统设计的可追溯性；•与系统需求的外部一致性；•内部一致性；•可测试性；•软件设计的可行性；•运作和维护的可行性。b.对软件需求中的问题，与系统工程组或客户一起确定和审查，并对客户需求和软件需求做出适当的更改。c.对软件需求规格说明书进行同行评审。d.审查、批准软件需求规格说明书，必要时，对其进行设计评审。e.将软件需求规格说明书置于配置管理之下。当客户需求变更，需要对软件需求做相应的更改时，进行变更控制。参见《软件配置管理程序文件》。工作产品•《软件需求规格说明书》•《系统测试方案》•《系统测试案例》•《用户手册》〔概要〕•《追溯表》〔MT-PTM01B〕〔MT-PTM01C〕职责•工程经理：负责选择适宜的软件需求分析员，组建软件需求工作组；确定是否需要对有关人员进行培训；负责软件需求规格说明书的审查和批准。•软件需求分析员：软件需求阶段工作的主要承当者。负责完本钱过程元素产生的所有工作产品。•系统测试负责人：负责组织软件系统测试组对软件需求进行分析，审查软件需求的可测试性；参与软件需求规格说明书的审查和批准。•质量保证人员：参与工作产品的审查，统计缺陷，并对软件需求分析过程进行审计。•系统工程人员：配合处理涉及客户需求的软件需求问题。•系统工程负责人：负责组织系统工程组对软件需求进行分析，审查软件需求的可测试性；负责协调处理涉及客户需求的软件需求问题；参与软件需求规格说明书的审查和批准。•客户：参与软件需求规格说明书的审查和批准。资源和能力要求•必要的培训资源•支持软件需求的设备•支持软件需求的工具度量•需求状态统计•质量〔同行评审缺陷统计〕•完本钱元素的工作所花费的工时详细裁剪指南活动可裁剪属性选择裁剪指导方针培训培训执行执行如果软件需求分析人员对需求分析方法及有关的工具使用或对软件需求所针对领域的业务知识缺乏了解，那么必须进行相关培训。不执行软件需求分析人员已经具备相关知识。软件需求分析软件需求分析方法结构化分析法采用结构化的分析技术。后续过程〔设计、实现〕通常也应该采用结构化技术。适用于中、小规模的软件工程。详见附录3.2－1需求分析方法指南。面向对象分析法采用面向对象的分析技术。后续过程〔设计、实现〕通常也应该采用面向对象技术。适用于各种规模的软件工程。详见附录3.2－1需求分析方法指南。快速原型法借助快速开发工具，以提供原型的方式，迅速掌握客户对软件的需求。适用于客户描述不清楚对软件的全部或局部需求。详见附录3.2－1需求分析方法指南。评审设计评审执行执行重要的或技术难度较高的软件工程。不执行其它软件工程。测试系统测试案例文档单独编写规模较大的工程。不单独编写小型工程，可以与系统测试方案合并。3.3结构设计元素概述结构设计是指按照《软件需求规格说明书》，设计软件系统的体系结构，即模块结构，定义每个模块的主要功能和模板之间的联系〔即接口〕，并确定软件系统的数据体系结构。本元素在整个过程中的位置如以下图所示：结构设计结构设计软件需求分析详细设计入口准那么和出口准那么〔1〕入口准那么：要素判断准那么软件需求规格说明书•经过审查•审查获得批准•进入配置库〔2〕出口准那么：要素判断准那么结构设计说明书•经过审查•审查获得批准•进入配置库集成测试方案任务编制编制分析•设计评审•批准准备软件需求规格说明书结构设计说明书〔1〕准备阶段根据《软件需求规格说明书》，对软件需求的分析结果进行评估。•对软件需求阶段所产生的初步设计方案进行评估；•检查重用软件，核实它们与整个系统需求是否相符；•根据《软件需求规格说明书》，对未确定需求进行评估，确定对策。〔2〕分析、设计阶段对《软件需求规格说明书》进行分析的根底上，使用结构化或面向对象的方法进行结构设计。主要包括三个方面的工作－系统体系结构、数据体系结构以及接口的设计。a.系统体系结构设计•扩充软件需求阶段所提出的初步的系统体系结构。对扩展后的体系结构进行完善，降低那些使软件难于实现、测试、维护和重用的因素，形成高内聚、低耦合的系统体系结构。b.数据体系结构设计•扩展软件需求阶段所提出的初步的数据体系结构，将其变换成实现软件所需的数据结构。c.接口设计•扩展软件需求阶段所提出的初步的接口，将其变换成实现软件所需的接口；•设计软件模块间的接口；•设计人和计算机间的接口〔即人机界面〕。〔3〕编制阶段a.根据分析和设计的结果，编制《软件结构设计说明书》〔附录3.3－1〕。b.编制结构设计的验收准那么－《集成测试方案》和《集成测试案例》，确定用于验证和确认结构设计是否得到满足的方法；包括集成步骤和方法。测试方案编写标准见附录3.2－6。验证和确认的方法包括：演示、集成测试、验证测试、分析和审查等。c.定义错误处理和恢复策略，确定用户的输入、显示，更新软件需求阶段建立的初步的《用户手册》。d.填写追溯表。参见《客户需求管理程序文件》。〔4〕评审、批准阶段a.对《结构设计说明书》和《集成测试方案》进行同行评审。b.对结构设计中的问题，与软件需求分析人员一起确定和审查，并对结构设计进行适当的更改。c.审查、批准《结构设计说明书》，必要时，对其进行设计评审。d.将《结构设计说明书》、《集成测试方案》和《集成测试案例》置于配置管理之下。工作产品•《结构设计说明书》•《集成测试方案》•《集成测试案例》•《用户手册》〔初步〕•《追溯表》〔MT-PTM01B〕〔MT-PTM01C〕职责•工程经理：*负责选择适宜的设计人员，组建结构设计工作组。*负责《结构设计说明书》和《集成测试方案》的审查和批准。•结构设计人员：结构设计阶段工作的主要承当者，负责完本钱过程元素产生的所有工作产品。•系统分析员：配合处理涉及软件需求的问题。•系统工程负责人：*负责组织系统工程组对结构设计进行分析，审查结构设计的可测试性；*负责协调处理涉及软件需求的问题；*参与《结构设计说明书》和《集成测试方案》的审查和批准。•软件测试负责人：*负责组织软件测试组对结构设计进行分析，审查结构设计的可测试性；*参与《结构设计说明书》和《集成测试方案》的审查和批准。资源和能力要求•结构设计所需要的人力•结构设计所需要知识的培训•结构设计所需要的设备•支持结构设计的开发工具度量•质量〔评审发现的缺陷数、缺陷的检出率〕•完本钱元素的工作所花费的工时详细裁剪指南活动可裁剪属性选择裁剪指导方针组建设计组培训规模多个小组系统规模大、技术难度高单一小组系统规模小、技术难度一般结构设计系统体系结构的结构设计执行不执行1、如果软件需求阶段所获得初步的系统体系结构已经足够满足需要2、已由客户获得3、旧系统改造、系统体系结构不需更改执行其它情况重用构件的性能模拟执行不执行系统响应要求不高执行其它情况评审设计评审执行执行重要的或技术难度较高的软件工程不执行其它软件工程测试集成测试案例文档单独编写复杂软件集成不单独编写简单软件集成，可以与集成测试方案合并3.4详细设计元素概述详细设计是根据《结构设计说明书》进行模块设计，将结构设计所获得的模块按照单元、程序、规程的顺序逐步细化。详细定义各个单元的数据结构、程序的实现算法以及程序、单元、模块之间的接口等，作为以后编码工作的依据。本元素在整个过程中的位置如以下图所示：详细设计详细设计结构设计编码入口准那么和出口准那么〔1〕入口准那么：要素判断准那么结构设计说明书•经过审查•审查获得批准•进入配置库〔2〕出口准那么：要素判断准那么详细设计说明书•经过审查•审查获得批准•进入配置库单元测试方案任务编制编制分析•设计评审•批准准备结构设计说明书详细设计说明书根据已批准的《结构设计说明书》，详细定义各个模块的数据结构、算法、接口等，编写《详细设计说明书》〔附录3.4－1〕和《单元测试方案》，测试方案编写标准见附录3.2－6。〔1〕准备阶段根据《结构设计说明书》，对结构设计的设计方案进行评估。〔2〕分析、设计阶段a.根据《结构设计说明书》，扩展结构设计阶段所定义的系统体系结构。按照单元、程序、过程的顺序逐步细化，将各个子系统成功地精化到每个元素构件实现一个简单的功能，并且能被编写成为一个单一的单元。设计内容还包括对将程序、单元、模块各局部逐步构成造成一个完整系统的构造环境的要求，即按照程序、单元、模块的顺序确定集成方法。b.确定每个单元的实现算法•确定每个单元所包含程序的实现算法和处理流程。c.重用单元的检查•识别来自软件重用库的单元是否重用，根据必要修改这些单元的算法和处理流程。〔3〕编制阶段a.根据分析和设计的结果，编制《详细设计说明书》；b.编制详细设计的验收准那么－《单元测试方案》和《单元测试案例》，确定用于验证和确认详细设计是否得到满足的方法；验证和确认的方法包括：演示、集成测试、验证测试、分析和审查等；c.审查、批准《详细设计说明书》，必要时，对其进行设计评审；d.更新《用户手册》•对于每个子系统指定详细的输入和输出格式，例如：显示，打印机和描图仪的输出，以及数据储存。〔4〕评审、批准阶段a.对《详细设计说明书》和《单元测试方案》可进行走查或〔和〕同行评审；b.对详细设计中的问题，与结构设计人员一起确定和审查，并对详细设计做出适应的更改；c.审查、批准《详细设计说明书》，必要时，对其进行设计评审；d.将《详细设计说明书》和《单元测试方案》置于配置管理之下。工作产品•《详细设计说明书》•《单元测试方案》•《单元测试案例》•《用户手册》•《追溯表》〔MT-PTM01B〕〔MT-PTM01C〕职责•工程经理：*负责选择适宜的设计人员，组建详细设计组。*负责《详细设计说明书》和《单元测试方案》的审查和批准。•详细设计人员：详细设计阶段工作的主要承当者。负责完本钱过程元素产生的所有工作产品。•系统分析员：配合处理涉及软件需求的问题。•系统工程负责人：*负责组织系统工程组对详细设计进行分析，审查详细设计的可测试性；*负责协调处理涉及软件需求的问题；*参与《详细设计说明书》和《单元测试方案》的审查和批准。•软件测试经理：*负责组织软件测试组对详细设计进行分析，审查详细设计的可测试性；*参与《详细设计说明书》和《单元测试方案》的审查和批准。资源和能力要求•详细设计所需要的人力•详细设计所需要知识的培训•详细设计所需要的设备•支持详细设计的开发工具度量•工时•质量〔评审缺陷统计〕详细裁剪指南活动可裁剪属性选择裁剪指导方针组建设计组设计组规模规模多个小组系统规模大、技术难度高单一小组系统规模小、技术难度一般详细设计系统体系结构的详细设计执行不执行1、如果结构设计阶段所获得系统体系结构已经足够满足需要2、由客户获得3、旧系统改造、系统体系结构不需更改执行其它情况数据体系结构的详细设计执行不执行1、小工程，且数据体系结构足够满足需要2、已由客户获得3、旧系统改造、数据体系结构不需更改执行其它情况评审走查或〔和〕同行评审方法走查小型、简单软件工程同行评审大中型、一般软件工程走查和同行评审重要软件工程设计评审执行执行重要的或技术难度较高的软件工程不执行其它软件工程测试单元测试方案文档编写由独立的单元测试人员进行单元测试不编写由编程人员自己进行单元测试单元测试案例文档单独编写复杂功能单元不单独编写简单功能单元，可以与单元测试方案合并3.5编码元素概述编码阶段主要完成的工作是根据详细设计说明书编写程序源代码，包括必要的数据文件，并进行单元测试，单元测试的内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处理等方面。本元素在整个过程中的位置如以下图所示：详细设计详细设计详细设计集成测试入口准那么和出口准那么〔1〕入口准那么：要素判断准那么详细设计说明书单元测试方案•经过审查•审查获得批准•进入配置库〔2〕出口准那么：要素判断准那么源代码文件源代码文件清单•源代码文件获得批准•源代码文件进入配置库的源代码区单元测试报告•提交测试负责人软件问题报告单•提交问题管理渠道任务各工作阶段如以下图所示：详细设计说明书单元测试方案详细设计说明书单元测试方案审查代码编制单元测试准备源程序文件单元测试报告软件问题报告单详细设计说明书单元测试方案〔1〕准备阶段•培训*根据员的实际水平进行有关编程语言、编程标准、编程方法、编程工具、调试方法、配置管理等方面的培训；*根据测试人员的实际水平进行有关测试方法、测试工具、问题汇报方法等方面的培训；有关被测产品的功能培训。•准备开发及测试工具和环境，如有必要在各编码组内对临时的编译环境和调试方法进行约定。〔2〕编制阶段•程序员依据详细设计，进行程序单元的编制工作〔包括建立相关的构造环境〕，并自行检查；在无特殊要求下，单元测试也可由编程者进行，参见裁剪指南。将编制的源代码文件提交审查。•在更正测试问题时，修改源码，提交新的源码文件。〔3〕审查阶段•对源代码文件进行同行评审，主要的方法为对照详细设计说明书对代码进行查阅，也可根据编程者的经验或程序的难度、重要程度，选择走查评审方式，但目的都是发现程序存在的问题。•在更正测试问题的情况下，在更正发现的问题之后，对源代码文件进行批准，并将其提交配置库的源代码区中。〔4〕单元测试阶段•从配置库获取源码文件，对照单元测试方案和测试用例进行测试，并将测试结果记录于测试报告〔见附录3.5－1〕。对源码文件进行的测试，视程序存在缺陷的情况，可能要重复进行，直至问题解决。•将测试中发现的缺陷/问题记录于问题报告单，提交测试负责人，并进入问题管理渠道，以便相应的开发人员进行更正，见3.10测试问题管理。•单元测试的执行者，一般情况下可由程序的编码者进行，特殊情况可由独立于编码者的测试人员进行。工作产品•源代码文件•《单元测试报告》•《软件问题报告单》〔MT-OP01C〕•《软件问题状态登记表》〔MT-OP01D〕职责•工程经理*建立编码组、测试组或相应岗位，并进行必要的培训；*跟踪进度和问题解决状态；*对提交的源代码进行批准〔或指定负责人进行批准工作〕。•程序员：编写和修改程序代码〔包括自行测试〕，提交工作产品，批准后将其配置入配置区的源码库。•单元测试人员：测试源代码，提交测试报告和软件问题报告单。•评审人员：负责对指定源代码进行阅读，发现缺陷和问题，填写评审报告。资源和能力要求•编码及单元测试所需要的软硬件开发环境和编程/测试人员；•必要的编程/测试培训。度量工程经理负责进行以下统计：•源程序总量〔总代码行数或功能点等规模测量值〕；•发现的缺陷总数；•编码工时和审查工时；详细裁剪指南活动可裁剪属性选择裁剪指导方针培训编程语言、编程标准、编程方法、编程工具、调试方法、配置管理执行不执行对开发环境和编程语言等有经验的团队执行对开发环境和编程语言等缺乏经验的团队，或采用新的编程语言、工具的情况测试方法、测试工具、问题汇报方法执行不执行对单元测试有经验的团队执行对单元测试缺乏经验的团队，或采用新的工具的情况不单独编写简单功能单元，可以与单元测试方案合并3.6集成测试元素概述集成测试阶段主要完成的工作是集成和集成测试。集成是参考结构设计说明书并根据详细说明书中规定的系统集成方案将不同的测试的程序单元进行构造，并逐步构造成一个完整的软件产品的过程；集成测试那么是在集成完成之后，对各单元、模块之间接口的正确性和集成后功能的正确性进行验证。对于大型软件，集成测试可以采取分步进行的方法，例如可以先对各子系统进行集成测试，然后在子系统之间进行集成测试。本元素在整个过程中的位置如以下图所示：集成测试集成测试编码系统测试入口准那么和出口准那么〔1〕入口准那么：要素判断准那么结构设计说明书详细设计说明书集成测试方案源代码文件•经过审查•获得批准•进入配置库〔2〕出口准那么：要素判断准那么集成的软件系统〔完整的源代码和目标代码〕•获得批准•进入配置库集成测试报告•提交集成测试负责人软件问题报告单•已进入软件问题管理流程任务审查审查构造集成测试准备结构设计说明书详细设计说明书集成测试方案源代码文件集成的软件系统集成测试报告软件问题报告单〔1〕准备阶段是：•培训*根据编程人员的实际水平进行有关程序语言、集成方法、版本控制工具、构造工具和配置管理工具的培训；*根据测试人员的实际水平进行有关测试方法、测试工具、测试问题汇报方法等方面的培训。•准备构造环境；•向工程组发布集成日程及源码库冻结时间表；•准备测试工具和环境。〔2〕构造阶段•在每次集成前，根据详细设计中的集成方法和步骤〔如自顶向下，自底向上，面向对象等集成方法〕，集成负责人负责制定集成工作表单〔见附录3.6－1〕，其中列出分步集成的程序清单、配置区的获取源、集成时间表、源码库冻结方案、集成结果的版本号或标识名，并将该工作表单发布给所有工程的开发人员和管理人员；•冻结相关的源代码库；•分步骤将各局部的程序源代码导入集成环境，进行编译和链接或等同的构造操作〔针对非过程化的编程语言〕；•记录构造过程中出现的问题。如果问题属构造环境不完善，那么完善构造环境；如果问题属于源代码文件级〔包括局部构造环境〕的问题，那么填写软件问题报告单，汇报出现的问题；问题解决后，重复构造过程，直至构造完成；每次构造需标识每次构造的版本号；•构造结束或源代码导入集成环境的过程结束〔取决于代码配置管理机制〕，开放源代码库；•将工作产品提交审查。〔3〕审查阶段•核查集成状态和结果，并进行批准；•批准后，将目标程序和程序清单进入目标代码库。〔4〕集成测试阶段•在每次集成测试前，集成测试负责人负责制定集成测试工作表〔见附录3.6－2〕，其中列出当次集成测试的类型、程序名及标识号〔对应集成结果〕、范围、时间表、参加人员和分工，并将该工作表单发布给所有工程的开发人员和管理人员；•从目标代码库获取程序目标码，对照集成测试方案进行测试，并将测试结果记录于测试报告〔测试报告编写标准见附录3.5－1〕；•将测试中发现的缺陷/问题记录于软件问题报告单，提交测试负责人，并进入软件问题管理流程，以便由相关的开发人员进行更正，见3.10测试问题管理；•集成测试视程序存在缺陷的情况，可能要重复进行，直到问题解决；每当测试软件或软件的环境发生变化时，应适当进行回归测试。工作产品•集成后的系统目标代码〔包括文件清单〕，及相应的源代码〔包括文件清单〕•集成测试报告•《软件问题报告单》〔MT-OP01C〕•《软件问题状态登记表》〔MT-OP01D〕•《集成工作单》〔MT-OP01A〕•《集成测试工作单》〔MT-OP01B〕职责•工程经理：建立集成组、集成测试组或相应岗位，并进行必要的培训；跟踪进度和问题解决状态；对集成后的系统目标码进行批准〔或指定负责人进行批准工作〕。•集成负责人员：负责集成过程的实施。•集成人员：负责环境构建，集成的过程操作，并将集成后的目标代码提交批准。•程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。•测试人员：测试系统目标码，将测试报告和软件问题报告单提交测试负责人。资源和能力要求•集成环境、测试工具、人力设备资源•相关的版本维护管理的培训•集成策略及目标代码的版本维护度量工程经理负责进行以下统计：•发现的缺陷总数及解决的缺陷总数；•集成及集成测试的工时；•进度完成情况。详细裁剪指南活动可裁剪属性选择裁剪指导方针培训程序语言、集成方法、版本管理工具、构造工具和配置管理工具的培训执行不执行有集成背景的团队执行对开发环境和编程语言等缺乏经验的团队，或采用新的编程语言、工具的情况培训测试方法、测试工具、问题汇报方法执行不执行对单元测试有经验的团队执行对单元测试缺乏经验的团队，或采用新的工具的情况3.7系统测试元素概述系统测试的主要任务是从系统需求的角度对系统运行的正确性和性能进行验证。系统测试的依据为系统测试方案。本元素在整个过程中的位置如以下图所示：系统测试系统测试集成测试验收入口准那么和出口准那么〔1〕入口准那么：要素判断准那么系统需求系统的目标代码系统测试方案•经过审查•获得批准•进入配置库用户手册编写完成〔2〕出口准那么：要素判断准那么系统测试报告软件问题报告单•获得批准任务系统测试系统测试准备系统需求说明书系统目标代码集成测试方案用户手册系统测试报告软件问题报告单〔1〕准备阶段是：•培训：根据测试人员的实际水平进行有关测试方法、测试工具、测试流程、问题汇报方法等方面的培训；有关被测产品的功能培训；•安排测试日程；•准备测试工具和环境；•准备必要的测试数据。〔2〕测试阶段•从目标代码库获取程序目标代码，对照系统测试方案并参考用户手册进行测试，将测试结果记录于测试报告〔测试报告编写标准见附录3.5－1〕；•将测试中发现的缺陷/问题记录于问题报告单，并提交测试负责人，进入软件问题管理流程〔见3.10〕•集成测试视程序存在缺陷的情况，可能重复进行，直至问题解决。工作产品•《系统测试报告》•《软件问题报告单》〔MT-OP01C〕•《软件问题状态登记表》〔MT-OP01D〕职责•工程经理：负责建立系统测试组或相关的岗位，并进行必要的培训；跟踪进度和问题解决状态；对最终的目标代码进行批准〔或指定负责人进行批准工作〕。•程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。•测试人员：测试系统目标码，将测试报告提交测试负责人，将软件问题报告单提交问题管理渠道〔见3.10〕。资源和能力要求•执行测试的软硬件环境和测试人员•必要的测试工具•必要的培训度量工程经理负责进行以下统计：•发现的缺陷总数及解决的缺陷总数；•进度完成情况。详细裁剪指南活动可裁剪属性选择裁剪指导方针培训测试方法、测试工具、问题汇报方法执行不执行对单元测试有经验的团队执行对单元测试缺乏经验的团队，或采用新的工具的情况系统测试系统测试执行不执行集成测试中已包含对系统功能的测试执行集成测试只涉及模块的接口测试，不涉及功能测试3.8验收元素概述验收阶段主要由验收测试、验收测试问题改正和验收三局部组成：•验收测试的主要目的是验证所开发的系统在用户的使用环境下〔或模拟的用户使用环境下〕是否满足系统需求，从用户的角度验证整个系统进行的正确性。•验收测试问题改正是对验收测试中发差异性问题进行修改。•验收那么是在验收测试的根底上，依据工程合同或工程任务书对工程的完成情况进行综合评价。本元素在整个过程中的位置如以下图所示：验收验收系统测试维护入口准那么和出口准那么〔1〕入口准那么：要素判断准那么验收测试方案已评审测试〔系统测试、集成测试、单元测试〕已完成〔2〕出口准那么：要素判断准那么验收测试报告已提交验收测试问题报告单已关闭验收报告已提交任务〔1〕验收测试验收测试流程图如下所示：分析并报告测试结果分析并报告测试结果执行/再执行验收用例准备验收测试验收测试方案用户手册系统描述软件代码验收测试报告由验收测试组完成以下活动：a.准备验收测试测试人员从配置库提取验收测试方案和被测试系统的目标代码，根据测试方案建立测试环境，必要时准备测试数据和编写测试用例程序，同时参考用户手册。b.执行/再执行验收测试用例按验收测试方案〔必要时参考用户手册〕反复执行验收测试用例。将测试发现的问题填写到《软件问题报告单》〔见3.10问题管理〕，通过测试问题管理渠道提交给相应的开发人员进行更正，并重复测试过程，直至问题得到解决。c.分析并报告测试结果分析测试结果并形成验收测试报告〔见附录3.2－1〕。〔2〕验收测试问题改正验收测试问题改正流程如以下图所示：发布已验收测试的系统升级配置库发布已验收测试的系统升级配置库修改软件错误验收测试问题报告单将交付的产品包括以下活动：a.修改软件错误开发组人员根据测试问题报告单分析、修改错误，假设有变更那么按变更控制的要求执行。b.升级配置库SCM负责人对新提交的配置进行配置。〔3〕验收a.组织验收验收在验收测试的根底上由验收组进行，验收组通常应有客户代表和SCCB的成员参加。验收内容一般包括以下方面：•对工程实施的技术路线、采用的关键技术进行评价；•对应产生的工作产品的完整性、正确性进行评价；•对验收测试的结果进行评价；•依据工程合同或工程任务书对工程的完成情况进行综合评价。在上述评价的根底上，给出验收结论，并形成验收报告。验收结论分为：通过验收；需要复评；不通过验收。其中：•根本符合工程合同或工程任务书的要求按期保质完成的，可视为通过验收。•由于提供文件资料不详，难以判断，或任务完成缺乏80%且原因难