某软件公司质量管理体系

1、精选优质文档-倾情为你奉上精选优质文档-倾情为你奉上专心-专注-专业专心-专注-专业精选优质文档-倾情为你奉上专心-专注-专业质量管理体系培训教材（一）目录公司标准软件过程体系文件导读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、

2、概述1.1目的本文件对公司软件过程及其体系文件的总体结构进行描述，为与软件过程的开发、维护、改进、执行、管理和跟踪等有关的人员学习、理解和使用软件过程体系文件提供指南。1.2适用范围适用于SEPG、高层经理、项目经理、软件开发人员、测试人员、软件质量保证人员、软件配置管理人员及其他支持人员为了按规范开展各自的业务活动，学习、理解和使用软件过程体系文件。1.3引用文件无。1.4术语无。1.5参考资料Software Project Management Guidebook（Version 2.0），Process Strategies，Inc.软件工程实践者的研究方法，（美）Roger S. P

3、ressman著，黄柏素、梅宏译，机械工业出版社出版，1999年10月实践中的CMMINFOSPS公司实施软件项目之过程，潘卡杰罗特著，杨慧鸣、李光龙泽，20GG年7月2、公司标准软件过程的开发2.1开发历程为了使软件过程保持长期稳定并能持续改进，必须开发组织（即公司）级的标准软件过程。为此，公司组织了以软件工程过程组（SEPG）为主体的标准软件过程开发和文件编写组，具体实施上述任务。公司标准软件过程是在公司范围内的软件项目全面执行CMM二级的基础上，在软件工程一般理论的指导下，收集公司全部软件项目所采用的软件过程，经过分析、归纳、提炼、分类、总结等一系列步骤开发而成；又在开发标准软件过程的基

4、础上，形成了描述这些标准软件过程的相互关联的程序文件体系。本程序文件体系对组成标准软件过程的基本软件过程要紧，以及软件过程要素之间的关系（软件过程结构）进行描述，描述的重点放在过程的可操作性上。此外，与此相关联，开发或编写了公司的软件过程数据库、与软件过程相关的文档库、软件生命周期描述文件和标准软件过程裁剪指南。它们和公司标准软件过程一起，组成了公司的软件过程资产。公司的软件过程资产为规范公司软件项目的软件过程提供了基础和保证。各软件项目按标准软件过程裁剪指南，根据项目的实际情况（主要是客户需求）对公司标准软件过程进行裁剪，开发适合项目特定特性的项目软件过程；项目软件过程开发的重点在软件过程的

5、可用性，以及附加到该项目的价值。项目以项目定义的软件过程为基础，制订项目软件开发计划；按计划执行项目的软件开发活动，产生相应的软件工作产品及其他开发成果；开发过程中的数据以及项目结束后进行总结的数据，经过一定的手续，反馈到公司的软件过程数据和软件过程相关文档库，丰富公司的软件过程资产。如此反复循环，促使软件过程得以持续改进。以上过程和关系可以用图1表示。图中：表示实体，例如“分配到软件的需求”表示活动，例如“选择项目的软件生命周期”图中上半部分用粗线框围起来的部分即公司的软件过程资产部分，它由描述公司标准软件过程的程序文件、软件过程数据库、与软件过程相关的文档库、软件生命周期描述文件和标准软件

6、过程裁剪指南组成。下半部分则描述公司软件过程资产的利用过程：软件项目按标准软件过程裁剪指南，根据项目的实际情况（主要是客户需求）对公司标准软件过程进行裁剪，开发适合项目特定特性的项目软件过程；制订项目软件开发计划，并按计划执行项目的软件开发活动；将项目数据（包括开发过程中的数据以及项目结束后进行总结的数据）反馈到公司的软件过程数据库和软件过程相关文档库。图1公司软件过程资产的开发和利用2.2公司标准软件过程总体结构图2为公司标准软件过程的总体结构。由于本公司的产品（项目）除了纯软件产品（项目）外，还包括软件和硬件兼有的产品（项目），考虑到过程的完整性以及便于理解软件过程和其他过程之间的接口关系

7、，图中的项目开发过程反映了软件和硬件兼有的产品的整个开发过程，但其中非软件过程部分均采用虚线，以示区别。有关内容说明如下：（1）项目、项目生命周期和软件生命周期项目是由一组有起止日期、相互协调的受控活动组成的独特过程，该过程要求达到符合包括时间、成本和资源等约束条件在内的规定要求的目标，其结果将产生产品。而软件项目则是为了开发软件产品（包括系统）而建立的项目。项目和产品都具有一定的生命周期。项目生命周期是指从项目启动到项目结束为止的时间间隔。项目生命周期一般包括：初期策划阶段（主要是可行性分析）；开发策划阶段（开发前的人、财、物等的计划和准备）；实施阶段（具体实施项目开发计划，保证项目的质量、

8、成本、进度的顺利完成）；结束阶段（评审、鉴定及项目交付和组织结束工作）。在整个项目生命周期，所涉及的过程可以分为两类：项目开发过程（和被开发产品的实现直接相关）；项目管理过程（对项目的开发过程进行管理和控制）。软件生命周期则是指软件产品的生命周期，即是指从设想软件产品开始到软件不再供使用为止的时间间隔。软件生命周期一般包括：概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和调整阶段、运行和维护阶段，有时还包括退役阶段。显然，项目生命周期和软件生命周期在时间上是相关的，但在概念上是完全不同的。一般来说，项目生命周期不会超过该项目所开发的软件产品的生命周期。（2）项目开发过程图中的下部表示项

9、目的开发过程。它从客户需求开始，通过系统分析，将客户需求分解成软件部分的需求和硬件部分的需求（从此处项目将分成软件项目和硬件项目两部分）。其中，软件项目从软件需求定义阶段、设计阶段、实现阶段、测试阶段、验收交付阶段到项目总结，表示整个软件开发的结束。一般来说，作为软件开发项目到此就意味着结束了，但软件产品的生命周期并未结束。软件产品交付后，将经历使用过程中的维护阶段（维护阶段的时间可能和项目合同有关），直到最后产品退役。（3）项目管理过程图中的中部表示项目的管理过程，即对项目的开发过程实施管理的过程。对于软件和硬件兼有的项目来说，项目管理的主要过程如下：初期策划（主要针对系统分析、可行性分析进

10、行策划）；开发策划（开发前的人、财、物等的计划和准备）；项目跟踪与监控（对项目初期的系统分析、可行性分析，以及项目开发过程中软件需求定义、设计、实现、测试、验收交付等活动进行跟踪与监控）；软件质量保证（SQA，对项目的软件过程和软件产品的符合性进行质量监控，它贯穿于软件项目的始终）；软件配置管理（SCM，为确保软件产品的完整性和正确性进行的管理，它贯穿于软件项目的始终）；需求管理（为确保满足客户需求进行的管理，它贯穿于项目的始终）；评审过程（包括同行评审等技术类评审和计划评审等管理类评审）；项目结束处理（包括项目的鉴定、验收、交付，以及进行项目总结）。此外，在项目管理活动中，还可能有以下管理过

11、程：项目培训；组间协调等。（4）过程资产本公司的软件过程资产分两个层次：公司级资产和项目级资产。a.公司级资产包括：过程数据库（含软件过程和其他过程的资产）；过程相关文档库；人力资源库。b.项目级资产包括：项目控制数据库（项目经理控制，用于保存项目数据，以便对项目进行跟踪与监控）；SQA管理库（SQA控制，用于保存项目的软件质量保证数据）；SCM管理库（SCM控制，用于保存项目的软件配置管理数据）；SCM库（SCM控制，用于保存项目的所有配置项）。通过一定的手续，项目的项目控制数据库和SQA管理库中的数据，经过选择，将补充到公司的过程数据库和过程相关文档库中。此外，根据实际需要，总部一级也可能

12、需要有人力资源库。图2软件过程结构图3、软件过程体系文件公司的软件过程体系文件的组成如图3所示。软件过程体系文件过程管理项目管理软件开发过程资源管理指南性文件软件开发过程程序文件标准软件过程开发与维护过程描述文件编写规范（一）过程描述文件编写规范（二）质量管理体系数据库管理和维护文件软件生命周期模型描述文件标识规范术语文件控制程序客户需求管理程序文件项目策划程序文件项目跟踪与监控程序文件项目总结程序文件软件质量保证程序文件软件配置管理程序文件组间协调程序文件技术类评审程序文件高层验证程序文件培训程序项目估算指南标准软件过程总体裁剪指南公司标准软件过程体系文件导读图3软件过程体系文件按文件的使用

13、目的，公司的软件过程体系文件分为五类：过程管理、软件开发过程、项目管理、资源管理和指南。3.1过程管理过程管理是指对软件过程进行管理，此类文件的使用人员主要是对软件过程进行开发、维护、改进的人员，例如SEPG成员、项目经理、SQA等。有关文件说明如下：（1）标准软件过程开发与维护使用人员：SEPG和软件过程描述文件编写人员。内容提要：本文件对如何开发和管理公司的标准软件过程、如何编写软件过程描述文件、如何编写标准软件过程裁剪指南等作出了规定。（2）过程描述文件编写规范（一）使用人员：软件过程描述文件编写人员。内容提要：为能分解成若干过程元素的较大过程编写的描述文件编写规范。（3）过程描述文件编

14、写规范（二）使用人员：软件过程描述文件编写人员。内容提要：为没有明显的入口和出口准则的过程（例如日常管理类的过程）编写的描述文件编写规范。（4）质量管理体系数据库管理和维护文件使用人员：SEPG、项目经理、SQA和数据库的管理和维护人员。内容提要：本文件对公司的软件过程数据库和与过程相关文档库的管理和维护作出了规定。考虑到将来需要扩充ISO9001要求的其他数据库，故起此名。（5）软件生命周期模型描述文件使用人员：项目经理以及参与项目软件过程定义的有关人员。内容提要：本文件对公司所确定的软件生命周期模型进行描述，作为公司的过程资产之一，供项目选择适合项目情况的软件生命周期模型时参考。（6）标识

15、规范使用人员：对被标识对象进行标识的人中员。内容提要：为规范包括文件、表格、产品的标识而制订的规范。（7）术语使用人员：SEPG和软件过程描述文件编写人员。内容提要：本文件定义了本软件过程体系文件所使用的专用术语。（8）文件控制程序使用人员：文件管理人员。内容提要：本文件对文件的编写、评审、批准、发布、发放、回收等文件管理要求作出了规定，是整个质量管理体系所要求的用于对受控文件进行管理的文件。3.2软件开发过程软件开发过程是指与软件开发有关的过程，相关文件的使用人员主要是和软件开发有关的人员。（9）软件开发过程程序文件使用人员：项目经理以及参与项目软件过程定义的有关人员。内容提要：本程序文件针

16、对本公司软件项目所采用的典型开发过程，分解成过程要素进行描述，供各软件项目根据标准软件过程裁剪指南，定义项目自己的软件过程时使用。3.3项目管理与项目管理有关的文件如下：（10）客户需求管理程序文件使用人员：项目经理、SQA、SCM和软件开发人员。内容提要：本文件是为了确保项目满足客户需求和如何确保满足客户需求，为项目编写的有关客户需求管理的程序文件。（11）项目策划程序文件使用人员：项目经理以及参与项目策划的其他有关人员。内容提要：为指导软件项目进行项目的初期策划和开发策划而编写的程序文件。（12）项目跟踪与监控程序文件使用人员：高层经理、项目经理、SQA、SCM和软件开发人员。内容提要：指

17、导软件项目在项目计划执行过程中如何对项目进行跟踪与监控的程序文件。（13）项目总结程序文件使用人员：项目经理、SQA、SCM和软件开发人员。内容提要：指导软件项目在项目结束阶段如何进行项目总结的程序文件。（14）软件质量保证程序文件使用人员：SQA、项目经理、SCM和软件开发人员。内容提要：指导软件项目的SQA如何执行项目的软件质量保证活动，以及项目的其他人员如何配合的程序文件。（15）软件配置管理程序文件使用人员：SCM、项目经理、SQA和软件开发人员。内容提要：指导软件项目的SCM如何执行项目的软件配置管理活动，以及项目的其他人员如何配合的程序文件。（16）组间协调程序文件使用人员：项目经

18、理、SQA、SCM和软件开发人员。内容提要：项目在进行项目策划时，应考虑有无组间协调的情况，本程序文件提供这方面的要求和指导。（17）技术类评审程序文件使用人员：项目经理、软件开发人员、SQA以及其他参与评审的人员。内容提要：本程序文件为项目进行技术类评审（包括同行评审及其他类型的技术评审）规定要求和提供指导。（18）高层验证程序文件使用人员：高层经理、项目经理、SQA、SCM和软件开发人员。内容提要：在公司标准软件过程的开发和改进以及项目在执行软件开发活动的过程中，高层经理应在哪些环节进行验证，如何进行验证？项目的有关人员如何配合？本程序文件为高层经理的验证活动提出要求并提供指导。3.4资源

19、管理资源管理主要包括人力资源、设备、环境等方面的管理。（19）培训程序使用人员：公司培训组、高层经理、项目经理、SQA、SCM和软件开发人员。内容提要：对公司级培训和项目级培训的实施要求作出规定，包括培训需求的收集、培训计划、培训实施和培训总结等。3.5指南性文件目前提供以下指南性文件：（20）项目估算指南使用人员：项目经理及其他参与估算的人员。内容提要：本指南为项目估算的方法（例如：规模估算、工作量估算等）提供指南。（21）标准软件过程总体裁剪指南使用人员：项目经理及其他参与项目软件过程定义的人员。内容提要：总体裁剪指南是公司标准软件过程裁剪指南中的高层裁剪指南（或一般性裁剪指南）。它为软件

20、项目在对公司标准软件过程进行裁剪时，提供对一般性活动进行裁剪的指南；裁剪结果为项目进行详细的过程裁剪提供框架性的指导方针（详细裁剪指南分散在各程序文件的“详细裁剪指南”中）。（22）软件过程体系文件导读（即本文件）使用人员：SEPG、高层经理、项目经理、软件开发人员、测试人员、软件质量保证人员、软件配置管理人员等为了按规范开展各自的业务活动，需要学习、理解和使用软件过程体系文件的所有人员。内容提要：对公司标准软件过程开发的背景、开发过程、标准软件过程的总体结构，以及相应的软件过程体系文件进行导读性的说明。软件生命周期模型目录1、概述161.1目的161.2适用范围161.3引用文件161.4术

21、语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术语

22、软件生命周期从软件设想开始到软件不再使用而结束的时间周期。软件生命周期一般包括系统分析、软件需求分析、设计、实现、测试、验收、运行和维护各阶段，有时还包括退役阶段。软件过程有关开发和维护软件及其相关产品（例如：项目计划、设计文档、代码、测试用例、用户手册等）的活动、方法、实践和变更的集合。1.5参考资料软件工程Java语言实现，Stephen R. Schach著，袁兆山等译，机械工业出版社，1999年9月软件工程实践者的研究方法，Roger S. Pressman著，黄柏素、梅宏等译，机械工业出版社，1999年10月Software Project Management Guidebook，

23、Frank J. Koch著，20GG年7月实用软件工程郑人杰、殷人昆、陶永雷著，清华大学出版社，1997年4月软件需求，Karl E. Wiegers著，陆丽娜、王忠民、王志敏等译，机械工业出版社，20GG年7月统一软件开发过程，Ivar Jacobson、GradP Booch、James Rumbaugh著，周伯生、冯学民、樊东平等译，机械工业出版社，20GG年1月2、软件生命周期模型描述所有的项目软件开发过程都应遵循一个生命周期模型，每个模型都具有能够帮助实际软件项目进行控制及协调的特征。定义生命周期模型的目的在于将本质上无序的活动有序化，在开发策划期间，必须仔细考虑项目的特征和目标之

24、后，再选择生命周期模型。本文件根据组织内项目的类型，描述常用的几个软件生命周期模型，项目可根据实际情况选择或按规定剪裁使用，但应注意与公司的标准软件开发过程相兼容。见附录“软件过程结构图”，其中的项目软件开发过程即为一个选择瀑布模型的典型项目过程。2.1瀑布模型（1）模型描述该模型首先由RoPce1970提出，又称线性顺序模型，包括图21所示的典型的几个阶段，其重要特点是：只有当一个阶段的文档已编制好，且该阶段的产品得到SQA认可后，该阶段才算完成；测试或验证在每个阶段都必须执行；一旦产品完成提交用户，其后的任何修改均属于维护阶段。如果需求明确、能较好理解且较稳定，可以考虑选择瀑布模型。系统分

25、析软件需求分析设计实现测试验收维护图21瀑布模型（2）缺点由于其线性顺序的特点，故只有在项目开发的后期才能得到具有全部功能的软件版本；如果有未定义或未实施的需求，将会引起重复劳动，甚至开发出的产品不是用户所需要的。（3）本企业适合的项目类型操作系统产品；译星产品；嵌入式产品开发；对日软件外包项目等。2.2原型瀑布模型（1）模型描述原型模型本身是一个迭代的模型，是为了解决在产品开发的早期阶段存在的不确定性、二义性和不完整性等问题，通过建立原型使开发者进一步确定其应开发的产品，使开发者的想象更具体化，也更易于被客户所理解。原型只是真实系统的一部分或一个模型，完全可能不完成任何有用的事情，通常包括抛

26、弃型和进化型两种，抛弃型指原型建立、分析之后要扔掉，整个系统重新分析和设计；进化型则是对需求的定义较清楚的情形，原型建立之后要保留，作为系逐渐增加的基础，采用进化型一定要重视软件设计的系统性和完整性，并且在质量要求方面没有捷径，因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。原型建立确认需求之后采用瀑布模型的方式完成项目开发，原型瀑布模型的开发流程如图22所示：多次迭代原型逐渐完善部分系统软件需求或软件需求分析原型设计原型实现原型测试瀑布测试图22原型瀑布模型以下情形建议考虑选择原型瀑布模型：a.项目包含一种新技术，例：新硬件、新的开发语言、新的系统架构等；b.需求不很

27、清楚；c.存在关于性能、可靠性和可行性方面的主要的、未解决的问题；d.用户界面对系统成功是很关键的，但不很清楚。（2）缺点由于原型并非最终产品，如果原型不能利用，可能导致成本的增加；同时会引起客户的误解，以为产品即将完成。（3）本企业适合的项目类型新领域的应用项目的开发；Web开发项目等。2.3增量模型（1）模型描述增量模型是一种进化软件过程模型，融合了线性顺序模型的基本成分（重复地应用）和原型模型的迭代特征，如下图所示。当使用增量模型时，第一个增量往往是核心产品，即实现了基本的需求；核心产品交用户使用（或进行更详细的复审），使用和/或评估的结果是下一个增量的开发计划，该计划包括对核心产品的修

28、改，使其能更好的满足用户的需要，并发布一些新增的特点和功能。增量模型和原型模型不一样，强调每一个增量均要发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但能提供用户服务功能和用户评估的平台。增量模型开发流程见图23。系统分析软件需求分析软件结构设计详细设计1实现1测试1验收1详细设计2实现2测试2验收2详细设计n实现n测试n验收n维护增量1增量2增量n图23增量模型（2）缺点由于增量模型的灵活性，往往容易退化成边做边改方法，使软件过程的控制丧失了整体性，最终的产品也不是开放的，而是成为维护人员的恶梦。（3）本企业适合的项目类型各种中、大规模的项目类型；已有系统技术路线发生改变但需求明

29、确的移植类项目。2.4增量的迭代过程模型（1）模型描述该模型是一个不断迭代和增量的过程，迭代过程首先要处理一组客户的业务需求，这些业务需求合起来能够揙所开发产品的可用性。其次，迭代过程要解决最突出的风险问题。后续的迭代过程建立在前一次的迭代过程末期所产生的产品之一。一个增量不一定是对原有产品的增加，尤其在生命周期初期，开发人员可能用更加详细和更加完善的设计来代替最初简单的设计。在较后的阶段，增量通常是对原有产品的增加。采用此种模型最好是基于构件和有相应的构件开发工具（如：RUP、配置管理工具等）。迭代1系统分析1软件需求分析1设计1实现1测试1验收1系统分析2软件需求分析2设计2实现2测试2验

30、收2系统分析n软件需求分析n设计n实现n测试n验收n迭代2迭代3维护图24增量的迭代模型（2）缺点需要相当的风险评估的技术；每个迭代循环控制不好会变成边做边改模式。（3）本企业适合的项目类型较复杂的应用项目。2.5快速应用开发模型（1）模型描述快速应用开发模型（RAD）是一个线性顺序的软件开发模型，强调极短的开发周期（23个月）。该模型是线性顺序模型的一个“高速”变种，如果需求理解得很好，且约束了项目范围，就可通过使用基于构件或可得用软件包的建造方法获得快速开发。快速应用开发模型流程见图25。适用于信息系统应用软件的开发。小组1业务建模1数据建模1处理建模1应用生成1测试1业务建模2数据建模2

31、处理建模2应用生成2测试2业务建模n数据建模n处理建模n应用生成n测试n集成/测试验收维护小组2小组n图25快速应用开发模型（2）缺点对大型的、但可伸缩的项目，RAD需要足够的人力以创建足够的RAD小组。RAD要求开发者和用户在一个很短的时间内完成一个系统，如果双方中的任何一方没完成约定，都会导致RAD项目失败。（3）本企业适合的项目类型具有可重用的构件库和CASE工具的应用项目；信息系统等。3、几种模型的比较软件生命周期模型是否首先定义好绝大部分的需求？是否有多个开发周期？是否有中间软件发布瀑布模型有无无原型瀑布模型没有有有增量模型有有可能增量的迭代模型没有有有快速应用开发模型没有有可能4、

32、其它模型采用说明如果在实际工作中，基于特定项目的经验积累和总结，可能需要形成新的软件生命周期模型，此时可依照一定的规程（参见标准软件过程开发和维护要求、项目策划程序文件）将其定义和描述加入到本文件中。5、附录附录1软件过程结构图说明：图中“项目软件开发过程”一层延伸到产品退役，即体现出软件的生命周期。采用不同的生命周期模型在该层面的“系统分析”和“软件开发”阶段对应不同的过程。软件过程结构图软件开发过程目录1、概述291.1目的291.2适用范围291.3引用文件291.4术语291.5参考资料302、过程总体描述302.1过程概述302.2结构描述312.3过程级裁剪指南323、过程元素33

33、3.1系统分析333.2软件需求分析383.3结构设计453.4详细设计483.5编码533.6集成测试563.7系统测试603.8验收633.9验收673.10软件问题管理714、附录74附录2.31中大型软件工程项目的标准软件开发过程75附录2.32中小型软件工程项目的标准软件开发过程76附录2.33小型软件工程项目的标准软件开发过程77附录3.11系统架构和业务需求说明书文档编写规范78附录3.12可行性分析报告文档编写规范80附录3.13系统需求规格说明书文档编写规范81附录3.21需求分析方法指南87附录3.22结构化分析法88附录3.23面向对象分析法（OOA）89附录3.24快速

34、原型法90附录3.25软件需求规格说明书文档编写规范91附录3.26测试计划文档编写规范95附录3.31软件结构设计说明书文档编写规范97附录3.41软件详细设计说明书文档编写规范101附录3.51测试报告文档编写规范103附录3.61集成工作单104附录3.62集成测试工作单105附录3.91软件维护实施计划文档编写规范106附录3.101软件问题报告单107附录3.102软件问题状态登记表1121、概述1.1目的本程序文件定义了公司内部的软件开发过程，以指导和规范软件项目中开发过程的定义和相应的实施。1.2适用范围整个公司内的软件项目。1.3引用文件过程描述文件编写规范（一）（QMS-PS

35、M02-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语言中一般是指由编译、连接命令、环境参数、操作语句等构成的一系列脚本程序的组合。白盒测试：基于源码进行的测试，主要的形式包括

36、语句覆盖、分支覆盖、路径覆盖等。黑盒测试：基于目标代码的测试，主要的形式为功能测试。回归测试：对新增的功能或更正错误的部分（包括与其相关的部分）进行的测试，而不是对软件系统全面的测试。其他术语参见术语文件。1.5参考资料软件能力成熟度模型CMM方法及其应用，杨一平等著，人民邮电出版社，20GG年4月实践中的CMMINFOSPS公司实施软件项目之过程，潘卡杰罗特著，杨慧鸣、李光龙泽，20GG年7月Managing the Software ProcessWatts S. HumphreP, Addison WesleP Longman, Inc, 1989Recommended Approach

37、 to Software Development SEL-81-305，1992.6软件需求，Karl E. Wiegers著，陆丽那、王忠民、王志敏等译，机械工业出版社，20GG年7月软件工程Java语言实现，Stephen R. Schach著，袁兆山等译，机械工业出版社，1999年9月软件工程实践者的研究方法，Roger S. Pressman著，黄柏素、梅宏等译，机械工业出版社，1999年10月国际信息技术软件生存周期过程指南GB/T8566-20GG军标软件开发与文档编制SJ20778-20GG2、过程总体描述2.1过程概述软件开发过程是指软件产品开发活动中所有阶段、任务的组合。该过

38、程可划分为一系列子过程，包括：系统分析、软件需求分析、设计、编码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如设计过程又可分为结构设计和详细设计。本程序文件描述公司通用的软件开发过程的组成（称之为“过程元素”）、彼此之间的关系（输入、输出接口），以及相应的裁剪指南。具体的软件开发项目可以根据其范围、规模和复杂度，确定软件生命周期模型，参见软件生命周期模型描述文件；然后根据通用的软件开发过程和裁剪指南，确定项目具体的软件开发过程。本程序文件涉及的裁剪指南分为两个层次，一层为过程级，主要针对不同的项目所采取的过程的剪裁，以定义不同的典型过程；另一层为过程元素内部，主要针对元素内部的各个

39、任务的剪裁。2.2结构描述软件开发过程在整个标准软件过程中的位置及组成见下图2.21。图2.21软件过程结构图本程序文件所描述的软件开发过程的元素的组成见下表：过程元素阶段需求分析设计实现测试验收维护系统分析软件需求分析结构设计详细设计编 码集成测试系统测试验 收维 护每个过程元素的具体描述和工作要求见本程序文件第三节的“过程元素”描述。2.3过程级裁剪指南活动可裁剪属性选择裁剪指导方针开发过程全过程（附录2.31）执行执行针对中大型软件工程项目或系统需求明确完全自行设计、实现的项目简化过程11（附录2.32）执行执行针对中小型软件工程项目自编/移植软件简化过程12（附录2.32）执行执行针对

40、中小型软件工程项目自由软件简化过程21（附录2.33）执行执行针对小型软件工程项目自编/移植软件简化过程22（附录2.33）执行执行针对中小型软件工程项目自由软件软件开发过程中的技术类评审方式见技术类评审程序文件中相应裁剪指南3、过程元素以下分别对软件开发过程中的各个元素进行描述。3.1系统分析3.1.1元素概述系统分析的目的是形成一个清楚的、完整的、一致的和可验收测试的系统需求规格说明书，与其它过程元素的关系如下图所示：软件需求分析硬件设计、实现、集成系统分析系统需求规格说明书系统分配给软件的需求系统分配给硬件的需求来自客户的需求系统架构和业务需求说明书可行性分析报告来自客户的需求可以是招标

41、书、项目说明书或意向书等任何形式的客户需求。系统分析是整个软件生命周期的开始，应分析待开发系统特定的预期使用要求，以规定系统需求。在此阶段，系统工程组要用一种反复迭代的方法逐渐扩充、完善系统需求，使其达到完整；对系统结构进行设计，建立系统的顶层结构，并标出硬件部分、软件部分和人工操作部分。应确保所有系统需求分配到各部分中。分配以各部分的系统需求及其相关系统结构应形成文档，对软件必须要实现的每个功能和每个要满足的关键点进行详细描述。通过实施本过程元素，完成系统架构和业务需求说明书（附录3.11）可行性分析报告（附录3.12）和系统需求规格说明书（附录3.12），为软硬件开发人员正确建立所要求的系

42、统提供基础。如上图所示，系统需求规格说明书应包括分配到软件部分的需求和分配到硬件部分的需求两部分。但在本文件中，如无特别说明，系统需求均指系统分配给软件部分的需求，也属于客户需求；系统需求规格说明书均指系统分配给软件部分的需求的规格说明书。3.1.2入口准则和出口准则（1）入口准则要 素判断准则招标书、项目说明书或意向书等客户需求已接受（2）出口准则要 素判断准则可行性分析报告经过评审并批准执行系统架构和业务需求说明书系统需求规格说明书进行了评审并经SCCB批准作为客户需求基线评审发现的问题已关闭3.1.3任务（1）系统架构和业务需求定义及系统可行性分析，具体过程如下图所示：业务需求定义系统架

43、构和业务需求评审可行性分析重用分析系统架构识别来自客户的需求来自早期项目的文档来自客户的需求系统架构和业务需求书可行性分析报告a.系统架构识别收集和逐条列出所有系统的高层需求（指最高层的产品业务目标）。描述满足这些高层需求系统必须实施的基本功能，着重从系统寿命（使用期限）、性能、安全、可靠性和数据项等方面的问题去考虑。通过这些功能描述，得到识别软件程序和所有主要接口的系统架构。详细说明所有主要数据接口的格式（如：文件、显示、打印输出等）。b.重用分析如果客户要求的功能与已有的产品很相似，则可评审已有的产品的系统架构和业务需求说明书、系统需求规格说明书、用户手册和相关源代码等来识别重用候选项。选

44、择较强的候选荐并估算相应的成本，评价其可靠性等，根据将开发项目的具体情况，对是否选用重用项作出一个相对折中的选择 。调整体系结构来说明采用的可重用软件，把所有重用分析的结果以重用建议的形式记录下来，写入系统架构和业务需求说明书文档中。c.业务需求定义清楚地定义系统必须如何在其业务环境下运行，包括针对所有主要业务模式的业务方案脚本，又称使用实例。形成的描述写入系统架构和业务需求说明书文档。由于最终用户是系统的直接使用者，需要时可请他们作为产品代表，帮助建立业务方案脚本。d.系统架构和业务需求的评审就系统架构和业务需求请系统和领域专家进行评审。e.可行性分析在上述结果的基础上，进一步分析高层需求，

45、从技术、经济、商业以及管理等方面进行可行性研究。编写可行性研究报告。对可行性分析报告进行评价，作出项目是否可行的判断和决策。如果项目可行，则进入下一过程；否则终止系统分析。（2）开发系统需求系统需求的开发过程如下图所示。开发系统需求细化需求系统需求规格说明书评审系统架构和业务需求说明书来自早期项目的信息可行性分析报告系统需求规格说明书a.细化需求基于高层需求和系统概念及体系结构，向下定义子系统层的所有需求，即细化的用户工作流程。如果系统很大（有很多子系统）或如果将与其它系统接口，就要清楚地定义所有外部接口。确定系统性能和可靠性需求。如果某个接受准则对应到某条需求（如：满足特定的响应时间），则需

46、说明这条需求的测试准则。b.编写系统需求规格说明书在用户已有业务系统的层面，识别需要满足需求的输入和输出的数据，用结构化或面向对象的分析方法，派生出软件必须实施的底层功能和算法。定义所有的文件、报告和显示等，并指出哪些数据用户必须能够修改等。保持设计和语言的中立性，即集中在软件需要做什么方面，而不是怎么做。创建一个追溯矩阵来映射每个底层的功能或数据说明使其能够得到实现。将上述结果形成文件，完成系统需求规格说明书的编写，作为软件开发的基础。c.系统需求规格说明书评审对系统需求规格说明书进行同行评审。评审后的系统需求规格说明书必须经SCCB批准，作为需求基线，纳入配置库。3.1.4工作产品系统架构

47、和业务需求说明书可行性分析报告系统需求规格说明书追溯表（MT-PTM01B）（MT-PTM01C）3.1.5职责（1）系统工程组：负责完成本过程元素所要求的所有活动，并填写追溯表（见客户需求管理程序文件）。（2）项目经理：负责制订系统分析阶段的计划（在执行过程中可能需要进行计划修订）；管理、度量此过程，并负责安排同行评审。（3）SCM：统计已定义的需求项的个数和已进行说明的需求的百分比，填写客户需求统计表（见客户需求管理程序文件）。3.1.6资源和能力要求必要的培训资源支持系统需求分析的设备支持系统需求分析的工具3.1.7度量统计已定义的需求项的个数和已进行说明的需求的百分比质量（同行评审缺陷

48、统计）完成本元素的工作所花费的工时3.1.8详细裁剪指南活 动可裁剪属性选 择裁剪指导方针系统构架和业务需求定义及系统可行性分析系统架构识别执行执行新项目或有新的需求的项目不执行无需修改客户需求的项目进行重用分析执行执行有可重用构件库或是已有版本的产品不执行新产品或无可重用构件库业务需求定义执行执行新项目或要修改业务需求定义的项目不执行无需修改业务需求定义的项目文档编写规模较大的、复杂的项目不编写规模较小的项目或快速原型开发；可与系统需求规格说明书合并。系统架构和业务需求说明书评审执行执行规模较大的、复杂的项目不执行规模较小的项目可不进行，将其放到系统需求说明规格说明书中一起评审。可行性分析执

49、行执行对系统需求能否实现不清楚不执行对系统需求能否实现清楚文档编写规模较大、较复杂的项目上，执行了可行性分析活动，要求出此报告。不编写规模较小、无需执行可行性分析活动；或规模较大、较复杂的项目，执行了可行性分析活动，但不要求单独出此报告，可合并到系统需求规格说明书中。开发系统需求细化需求执行执行新项目或需求需要进一步细化的项目不执行针对旧项目，细化的需求已存在3.2软件需求分析3.2.1元素概述软件需求分析是按照项目定义的软件开发过程，根据系统分配给软件的需求（见系统需求规格说明书），进行软件质量特性规格说明的过程。该过程包括进一步明确软件运行环境，明确对软件的功能、性能和数据要求，以及软件与

50、硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化，即完成对软件需求的分析与规格定义。有关软件需求的变更管理，请参见软件配置管理程序文件。本元素在整个过程中的位置如下图所示：软件需求分析结构设计系统分配给软件的需求3.2.2入口准则和出口准则（1）入口准则要素判断准则客户需求（系统需求规格说明书）已由SCCB批准为基线已进入配置库（2）出口准则要素判断准则软件需求规格说明书已经过审查已批准为开发基线已进入配置库系统测试计划已经过审查已获得批准已进入配置库系统测试案例用户手册（概要）已编写3.2.3任务各工作阶段如下图所示：定义收集分析评审准备系统分配给软件的需求软件需求规格说明书（

51、1）准备阶段a.必要时对软件需求分析员进行相关培训（包括有关的技术和业务知识培训，以及有关的工具使用培训）。b.审查客户需求，识别并解决影响软件需求的问题。c.选择适当的需求分析方法（参见附录3.21、附录3.22、附录3.23、附录3.24），并准备相应的分析工具。建议采用的需求分析方法包括：结构化分析法、面向对象分析法和快速原型法等。如果需要采用上述分析法以外的其它需求分析法，应该得到SEPG的批准。结构化分析法采用结构化的分析技术。后续过程（设计、实现）通常也应该采用结构化技术。适用于中、小规模的软件项目。面向对象分析法采用面向对象的分析技术。后续过程（设计、实现）通常也应该采用面向对象

52、技术。适用于各种规模的软件项目。快速原型法借助快速开发工具，以提供原型的方式，迅速掌握客户对软件的需求。适用于客户描述不清楚对软件的全部或部分需求。建立满足客户需求的原型后，根据所采用的工具和实际需要确定是否重新进行软件需求规格定义。快速原型不能作为惟一的软件需求规格表达方式，必须辅之以适当的软件需求规格说明书。快速原型法可以与结构化分析或面向对象分析技术结合使用。（2）收集、分析阶段本阶段需要与客户不断接触、协商。通过对收集到的信息进行分析、归纳，界定出对软件的需求，明确在目标产品中需要什么和以什么形式来表现。与客户交流的基本形式通常有两种：客户访谈调查（正式的和非正式的）、书面调查（书面报

53、告和调查表）。此外，通过对客户使用的表格和所处的情景进行分析，从而获取需求，也是常用的方法。这些方法对前面推荐的三种需求分析中采用的分析法与后续过程的设计和实现方法有一定的关联关系，通常应该保持所选用的表达方法一致。详见需求分析方法指南。除了调查客户正常业务处理要求以外，特别需要关注的是异常处理和例外处理要求。这些处理要求往往在软件需求中占有很大的比例，却容易被忽视。收集、分析可重用的软件或功能模块，确定可用项。本阶段的工作步骤如下：编制工作计划，特别是与受访者协商确定调查、访谈日程安排。运用选定的需求分析方法，收集、识别是、导出软件需求。收集、筛选、确定可能重用的软件或功能模块。（3）定义阶

54、段a.根据软件需求分析结果，选择适当的实现方案并说明选择理由，形成软件系统的初步设计方案（包括对系统体系结构、数据体系结构和接口的初步设计）。b.描述软件需求规格，编制软件需求规格说明书（附录3.25）。c.编制用于验证和确认软件需求是否得到满足的方法系统测试计划和系统测试案例，测试计划的编写规范见附录3.26。d.建立用户手册（概要）。e.填写追溯表。参见客户需求管理程序文件。（4）评审阶段a.评审软件需求规格说明书，具体评审过程见技术类评审程序文件，对软件需求的评审准则包括：系统需求和系统设计的可追溯性；与系统需求的外部一致性；内部一致性；可测试性；软件设计的可行性；运作和维护的可行性。b

55、.对软件需求中的问题，与系统工程组或客户一起确定和审查，并对客户需求和软件需求做出适当的更改。c.对软件需求规格说明书进行同行评审。d.审查、批准软件需求规格说明书，必要时，对其进行设计评审。e.将软件需求规格说明书置于配置管理之下。当客户需求变更，需要对软件需求做相应的更改时，进行变更控制。参见软件配置管理程序文件。3.2.4工作产品软件需求规格说明书系统测试计划系统测试案例用户手册（概要）追溯表（MT-PTM01B）（MT-PTM01C）3.2.5职责项目经理：负责选择合适的软件需求分析员，组建软件需求工作组；确定是否需要对有关人员进行培训；负责软件需求规格说明书的审查和批准。软件需求分析

56、员：软件需求阶段工作的主要承担者。负责完成本过程元素产生的所有工作产品。系统测试负责人：负责组织软件系统测试组对软件需求进行分析，审查软件需求的可测试性；参与软件需求规格说明书的审查和批准。质量保证人员：参与工作产品的审查，统计缺陷，并对软件需求分析过程进行审计。系统工程人员：配合处理涉及客户需求的软件需求问题。系统工程负责人：负责组织系统工程组对软件需求进行分析，审查软件需求的可测试性；负责协调处理涉及客户需求的软件需求问题；参与软件需求规格说明书的审查和批准。客户：参与软件需求规格说明书的审查和批准。3.2.6资源和能力要求必要的培训资源支持软件需求的设备支持软件需求的工具3.2.7度量需

57、求状态统计质量（同行评审缺陷统计）完成本元素的工作所花费的工时3.2.8详细裁剪指南活 动可裁剪属性选 择裁剪指导方针培训培训执行执行如果软件需求分析人员对需求分析方法及有关的工具使用或对软件需求所针对领域的业务知识缺乏了解，则必须进行相关培训。不执行软件需求分析人员已经具备相关知识。软件需求分析软件需求分析方法结构化分析法采用结构化的分析技术。后续过程（设计、实现）通常也应该采用结构化技术。适用于中、小规模的软件项目。详见附录3.21需求分析方法指南。面向对象分析法采用面向对象的分析技术。后续过程（设计、实现）通常也应该采用面向对象技术。适用于各种规模的软件项目。详见附录3.21需求分析方法

58、指南。快速原型法借助快速开发工具，以提供原型的方式，迅速掌握客户对软件的需求。适用于客户描述不清楚对软件的全部或部分需求。详见附录3.21需求分析方法指南。评审设计评审执行执行重要的或技术难度较高的软件项目。不执行其它软件项目。测试系统测试案例文档单独编写规模较大的项目。不单独编写小型项目，可以与系统测试计划合并。3.3结构设计3.3.1元素概述结构设计是指按照软件需求规格说明书，设计软件系统的体系结构，即模块结构，定义每个模块的主要功能和模板之间的联系（即接口），并确定软件系统的数据体系结构。本元素在整个过程中的位置如下图所示：结构设计软件需求分析详细设计3.3.2入口准则和出口准则（1）入

59、口准则：要素判断准则软件需求规格说明书经过审查审查获得批准进入配置库（2）出口准则：要素判断准则结构设计说明书经过审查审查获得批准进入配置库集成测试计划3.3.3任务编制分析设计评审批准准备软件需求规格说明书结构设计说明书（1）准备阶段根据软件需求规格说明书，对软件需求的分析结果进行评估。对软件需求阶段所产生的初步设计方案进行评估；检查重用软件，核实它们与整个系统需求是否相符；根据软件需求规格说明书，对未确定需求进行评估，确定对策。（2）分析、设计阶段对软件需求规格说明书进行分析的基础上，使用结构化或面向对象的方法进行结构设计。主要包括三个方面的工作系统体系结构、数据体系结构以及接口的设计。a

60、.系统体系结构设计扩充软件需求阶段所提出的初步的系统体系结构。对扩展后的体系结构进行完善，降低那些使软件难于实现、测试、维护和重用的因素，形成高内聚、低耦合的系统体系结构。b.数据体系结构设计扩展软件需求阶段所提出的初步的数据体系结构，将其变换成实现软件所需的数据结构。c.接口设计扩展软件需求阶段所提出的初步的接口，将其变换成实现软件所需的接口；设计软件模块间的接口；设计人和计算机间的接口（即人机界面）。（3）编制阶段a.根据分析和设计的结果，编制软件结构设计说明书（附录3.31）。b.编制结构设计的验收准则集成测试计划和集成测试案例，确定用于验证和确认结构设计是否得到满足的方法；包括集成步骤