《软件工程实施程序》word版

1、.1. 目的本程序文件规定了软件开发工程的施行过程，其目的是以工程的观点，控制软件工程的开发和施行过程，使软件工程的开发和施行过程处于可控制的状态，进步软件产品的质量，进步工作效率。1.1. 参考资料a) ?质量管理体系标准 GB/T 19000-2000?。b) ?质量管理体系标准 GB/T 19001-2000?。c) ?质量管理体系标准 GB/T 19004-2000?。d) ?软件工程术语GBT11457-1995?。e) ?信息技术软件生存期过程GB/T 85661995?。f) ?计算机软件产品开发文件编制指南 GB 8567-88?。g) ?计算机软件需求说明编制指南 GB 93

2、85-88?。h) ?质量管理和保证标准第三部分：GB/T19001-ISO9001在软件开发、供给和维护中的使用指南?。i) 公司质量体系程序文件?设计和开发控制程序?。j) 公司质量体系程序文件?产品筹划和消费效劳控制程序?。k) 公司质量体系程序文件?工程质量方案控制程序?。1.1. 常用术语1.1.1. 软件 software软件是指计算机程序及其有关的数据和文档，也包括固化了的程序。1.1.2. 软件生存周期 software life cycle软件生存周期进指从系统对计算机软件系统提出应用需求开场，经过开发，产生一个满足需求的计算机软件系统，然后投入运行，直至该软件系统退役为止。

3、期间经历系统分析与软件定义、软件开发以及系统的运行与维护等三个阶段。其中软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试发及安装与验收等六个阶段。1.1.3. 审查 inspection a) 一种正式的评定技术。由除作者之外的某人或某一小组仔细检查软件需求、设计或代码，以找出故障、违犯开发标准之处和其它一些问题。与?软件工程术语GBT11457-1995? 2 545条相对照。参见?软件工程术语GBT11457-1995? 2 63条。b) 质量管理的一个阶段。在此阶段借助检查。观察或测量来确定材料、必须品、零部件、附属 品、系统、过程或构造是否符合预定的

4、质量要求。 1.1.4. 需求 requirement客户为解决某一问题或到达某个目的所需要的条件或才能。系统或系统部件为满足或具有的条件或才能以满足合同、标准、规格说明或其它正式的强迫性文件。所有需求的集合形成了以后开发系统或系统部件的根底。参见?软件工程术语GBT11457-1995?2404条、2406条。2407条。 1.1.5. 需求分析 requirements analysis 研究客户要求以得到系统或软件需求的定义的过程。对系统需求或软件需求的验证。1.1.6. 需求阶段 requirements phase软件生存周期中的一个阶段。在此期间对软件产品的需求如功能和性能方面的才

5、能进展定义并编制出相应的文档。1.1.7. 需求规格说明 requirements specification 陈述系统或系统部件例如，软件配置项的需求的规格说明，通常包括功能需求、性能需求。接口需求、设计需求以及开发标准。1.1.8. 概要设计 Preliminary designa) 分析各种设计方案和定义软件体系构造的过程。典型的概要设计包括计算机程序组成成分和数据的定义及构造、界面的定义，并提出时间和规模方面的估计。 b) 概要设计过程的结果。参见?软件工程术语GBT11457-1995? 2135条、2216条。 1.1.9. 详细设计 detailed designa) 推敲并扩大

6、初步设计，以获得关于处理逻辑、数据构造和数据定义的更加详尽的描绘，直到设计完善到足以能实现的地步。 b) 详细设计过程的结果。 1.1.10. 代码，编码 code a) 一组无歧义性的规那么，它规定了使数据得以用某种离散形式加以表示的方式。b) 用处理机可以承受的符号形式表示数据或计算机程序。c) 书写例行程序。d) 也可指一个或多个计算机程序，或计算机程序一部分。 已为了平安的目的对数据进展的加密表示。1.1.11. 注释 comment a) 在计算机程序、命令语言或数据之间的说明信息，旨在给读者提供澄清性材料，并不影响机器的解释工作。 b) 加到或散置在源语言语句当中的描绘、附注或解释

7、，在目的语言中这些是无效的1.1.12. 代码审计 code audit 由某人、某小组、或借助某种工具对源代码进展的独立的审查，以验证其是否符合软件设计文件和程序设计标准。还可能对正确性和有效性进展估计。参见?软件工程术语GBT11457-1995?234条、2468条、2237条、2545条。1.1.13. 验证 verification验证是指确定软件开发周期中的一个给定阶段的产品是否到达在上一阶段确立的需求的过程。1.1.14. 确认 validation确认是指在软件开发过程完毕时对软件进展评价以确定它是否和软件需求相一致的过程。1.1.15. 测试 testing测试是指通过执行程

8、序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。1.1.16. 软件质量 software quality软件质量是指软件产品中能满足给定需求的各种特性和总和。这些特性称做质量特性，它包括功能度、可靠性、时间经济性、资源经济性、可维护性和或移植性等。1.1.17. 质量保证 quality assurance质量保证是指为使软件产品规定需求所进展的一系列有方案的必要工作。2. 适用范围?软件工程施行程序?适用于纯软件开发工程的施行过程和软硬件集成工程中与软件开发相关的的施行过程。3. 人员职责3.1. 工程经理a) 负责工程设计开发的管理。b) 制定?工程施行方案

9、?，确定开发组人员分工，监控方案的执行。c) 组织施行该方案以满足目的和标准的要求，履行对过程的控制。d) 在业务代表的协助下，协调与客户关系，协调各部门的关系。e) 整体掌握工程需求和技术方案，按时提交阶段任务结果。 f) 调查、分析和解决在工程施行过程中发现的问题。问题的解决可以导致对方案的修改。保证任何方案改变所造成的影响都在控制和监视之下。问题及其解决方法都应当写成文档。 g) 保证对产品和方案进展检查，使产品和方案在完成或变更之后保持完好性和一致性。h) 从完好性方面检查产品完成的结果和记录，这些结果和记录应当存档。3.2. 技术负责人工程技术总监a) 对工程经理负责。b) 对工程的

10、技术方向和技术成果负责。c) 确立系统的技术方案及开发的总体目的，组织对概要设计、详细设计进展内部审核。d) 提出系统开发修改方案。e) 在开发过程中对程序员进展指导。f) 按时提交阶段任务结果。3.3. 系统分析员a) 对工程经理负责，根据?软件工程施行程序?和相应的作业指导书的要务施行系统分析和设计过程，提交相应的文档。b) 根据?工程施行方案?完成工程的技术设计，对设计质量负责。c) 根据?测试方案?在质量控制负责人的组织下，进展系统测试。d) 按时提交阶段任务结果。3.4. 界面美工a) 对工程经理负责。b) 界面风格设计，界面制作、美工制作。c) 根据?测试方案?在质量控制负责人的组

11、织下，参加系统测试。3.5. 文档管理人员a) 对工程经理负责。b) 根据?工程施行方案?，中的要求，维护管理文档，保证文档的完好性和一致性。c) 根据?测试方案?在质量控制负责人的组织下，参加系统测试。3.6. 程序员a) 对工程经理负责。b) 编码调试，按照?任务单?、?详细设计报告?按期、安质完成模块编码。c) 完成单元测试。根据?测试方案?在质量控制负责人的组织下，参加系统测试。3.7. 质量控制负责人a) 检查系统的概要设计、详细设计。b) 根据系统的概要设计、详细设计，完成工程的?测试方案?的制作，监视?测试记录?的制作，按方案组织测试。c) 保证对产品和方案进展检查，使产品和方案

12、在完成或变更之后保持完好性和一致性。d) 从质量管理方面，控制可能出现的风险，及时报告工程经理。3.8. 用户教育负责人在工程交付完成后，应在用户教育负责人的组织下，完成对客户的培训。a) 对工程经理负责。b) 组织用户文档编写。c) 根据根据?工程施行方案?的要求，根据客户的要求完成用户的培训。d) 积极向用户解释，软件系统的使用方法，及时向工程经理报告客户的反响。4. 工作程序4.1. 流程以以下图描绘了工程开发施行过程的流程，图中右侧是每个阶段的输入和输出，中间是处理过程，左侧是评审或检查的要点。图1. 软件工程施行流程1图2. 软件工程施行流程2图3. 软件工程施行流程34.2. 各阶

13、段的过程及评审4.2.1. 工程筹划4.2.1.1. 过程1. 为了保证交付的系统、产品或效劳的质量，全面评审合同中的需求，工程经理通过与销售、售前支持的沟通理解顾客的要求。2. 工程经理应确定或选择与工程的范围、规模和复杂性相适宜的软件生存周期模型。应当把从本标准中选出的过程、活动和任务影射到该生存周期模型中。该生存周期模型应当包括可使用的开发环境，其中包括标准、方法和工具等。 3. 编制?工程施行方案?。方案应包括：a) 对资源的需求和客户的介入。b) 为开发该产品或提供该效劳选择方案。 可供选择的方案有： a利用研发中心现有的资源提供产品或提供效劳； b通过与客户的协商，分阶段完成合同规

14、定的产品或效劳或用子合同方式开发产品或提供效劳； c从研发中心或采购现货产品； d上述a、b二条结合。c) 工程管理方案 在这些方案中应当规定下述事项： a. 工程的组织机构，以及包括外部机构在内的每个机构的权利和责任； b开发环境，包括测试环境。库、设备、仪器以及工程标准、步骤和工具； c生存期过程和活动的工作细目的构造，其中包括可交付的产品，与任务有关的经费预算、人员。物理资源、软件的规模以及时间进度； d系统的质量需求管理。假设需要，可以另外制订质量保证方案； e系统平安和保密的关键需求管理。假设需要，另外制订平安和保密方案； f客户的介入，即按合同要求进展的评审和审计、非正式的会面、报

15、告、修改和变更的施行、批准、验收、对设施的使用等； g验证和确认，在必要的情况下，规定中应包括与独立的验证和确认机构接触的方法； h质量保证，明确工程的质量目的和产品、效劳的质量保证手段、方法、时间安排等； i风险管理，此项管理包括对工程的潜在技术、本钱和进度诸风险领域的管理； j制定方案、跟踪和报告的方法； k人员培训，明确工程的人员培训的要求，及人员培训的安排。4.2.1.2. 阶段结果?工程施行方案?。4.2.1.3. 评审?工程施行方案?由工程经理负责编写，?工程施行方案?应提交研发中心的评审组进展评审。评审后，评审负责人评审结果和意见记入?评审报告?。评审通过后，工程方可进入下一个施

16、行阶段。根据工程情况，可以以会签或会议的方式进展评审。4.2.2. 需求分析4.2.2.1. 过程1. 对系统的要求进展分析，以建立系统需求。系统需求应当说明：系统的功能和性能；平安、保密、人机工程、接口、操作和维护需求；设计限制和鉴定的要求。2. 系统分析员在工程经理的组织先完成需求的分析、调查过程，并将需求分析结果写成文档。 该文档描绘： a功能和才能规格说明，其中包括性能、物理特性、运行软件的环境条件；b用户文档；c平安规格说明，其中包括与操作和维护的方法、环境影响和人员伤害有关的说明； d保密规格说明，根据合同或客户的需求描绘对敏感性信息或资料的保护手段；e人机工程和人一机规格说明，其

17、中包括与人工操作、人机对话、对人员的限制有关的规格说明，以及那些对于人的错误和才能很敏感的、需要人集中注意力的领域的说明；f处理器、存储设备或数据通道所用的硬件处理和资源储藏的规格说明；g数据定义和数据库的需求；h已交付软件在操作和维护现场上的安装和验收的需要； i用户维护需求。 j与其他系统接口的需求3. 对系统需求进展评价，使其包括下述准那么 a对系统需求和系统设计的可跟踪性； b与系统需求的外部一致性； c各种软件需求之间的内部一致性； d. 软件需求的可测性； e软件需求的测试范围； f软件设计、操作和维护的可行性。 4. 研发中心评审组应当进展合同所要求的评审，以决定软件需求的完善和

18、恰当。5. 对于内部工程或开发工作量小于6人/月的工程，应编制?系统规格说明书?代替?需求分析报告?，其内容需覆盖需求分析工作的内容。4.2.2.2. 阶段结果?需求分析报告?或?系统规格说明书?。4.2.2.3. 评审?需求分析报告?由工程经理组织系统分析员编写，?需求分析报告?应提交研发中心的评审组进展评审。评审后，评审负责人评审结果和意见记入?评审报告?。评审通过后，工程方可进入下一个施行阶段。根据工程情况，可以以会签或会议的方式进展评审。假设符合4.2.2.1的规定应提交?系统规格说明书?，代替?需求分析报告?提交评审。4.2.3. 概要设计 总体设计4.2.3.1. 过程1. 建立系

19、统体系构造。应当在系统的体系构造中表达系统的需求，该系统体系构造要表现出系统的内部构造以及硬件、软件和人工操作的要求。2. 明确系统或子系统的每个功能需求，应当执行的下述任务：a) 系统分析人员应当把软件需求转变为一个体系构造，该体系构造应描绘它的构造、定义它的主要部分。它应当保证系统的构造、功能的描绘和要求覆盖系统的需求，可以对其细化进展详细设计。b) 系统分析人员应当明确规定软件系统与外部接口的设计、各软件部分之间的设计。 c) 系统分析人员应当编写数据库设计文档。3. 工程经理和技术负责人应当确认软件配置项的体系构造、接口和数据库的设计，使其包括下面指出的各项：a. 对软件系统需求的可跟

20、踪性； b.与软件系统需求的外部一致性； c.各部分需求之间的内部一致性；d.所使用的设计方法和标准是否恰当；e.详细设计、操作和维护的可行性。 4. 在工程经理的指导下，由技术负责人组织，系统分析员为测试软件单元规定测试要求和时间进度，并将其写成文档。5. 应当对工作结果进展的评审，以确定设计方法是完善和恰当的。6. 对于内部工程或开发工作量小于6人/月的工程，应编制?系统规格说明书?代替?概要设计报告?，其内容需覆盖概要设计工作的内容 4.2.3.2. 阶段结果?概要设计报告?或?系统规格说明书?。?数据库设计报告?。?测试方案?。4.2.3.3. 评审?概要设计报告?由工程经理组织系统分

21、析员编写，?概要设计报告?应提交研发中心的评审组进展评审。评审后，评审负责人评审结果和意见记入?评审报告?。评审通过后，工程方可进入下一个施行阶段。根据工程情况，可以以会签或会议的方式进展评审。假设符合4.2.3.1的规定应提交?系统规格说明书?，代替?概要设计报告?提交评审。4.2.4. 界面设计4.2.4.1. 过程1. 在概要设计过程中，应建立系统界面设计原那么，根据客户的需求，完成整个系统的用户界面设计。2. 界面制作人员在工程经理、系统分析员的指导下完成系统的界面制作，模拟系统的运转过程。3. 根据客户的需求，工程经理应对客户讲解界面设计的原那么，通过模拟系统的运转过程，讲解对系统需

22、求的理解。4.2.4.2. 阶段结果?界面设计报告?。系统的运转界面4.2.4.3. 评审?界面设计报告?由工程经理组织系统分析员编写，?界面设计报告?应由工程经理确认、签字。4.2.5. 详细设计4.2.5.1. 过程1. 系统分析员应当根据概要设计阶段的设计成果，详细设计软件功能的每个组件或功能单元。应当尽量地将各个软件功能详细划分为组件或功能单元，以便进展编码、编译和测试。应当保证该软件的需求已完全分配给从软件功能到组件或功能单元的整个软件系统。应当把该详细设计写成文档。2. 系统分析员应当写出组件或功能单元的实现详细设计文档，并明确规定各个组件或功能单元的接口，明确规定组件或功能单元与

23、软件功能的关系。3. 系统分析员、文档管理人员最好写出软件用户手册的最初版本。 4. 在工程经理的指导下，由质量控制负责人组织编写为软件系统测试规定测试要求、进展测试设计，为每个功能项规定测试用例输入、输出、测试准那么和测试步骤，将这部分内容写入?测试方案?。工程经理和技术负责人应当评价软件的详细设计和测试要求，使其包括下面的准那么：a. 对软件系统功能需求的可跟踪性； b. 与体系构造设计的外部一致性； c各组件和功能单元的需求之间的内部一致性； d所使用的设计方法和标准是否恰当； e测试、操作和维护的可行性。 6. 对于内部工程或开发工作量小于6人/月的工程，应编制?系统规格说明书?代替?

24、详细设计报告?，其内容需覆盖详细设计工作的内容。4.2.5.2. 阶段结果a） ?详细设计报告?或系统规格说明书?。b） ?界面设计说明书?。c） ?数据流程图?。d） ?数据字典?。e） ?数据库设计报告?。f） ?任务单?。4.2.5.3. 评审详细设计完成后，应在工程经理的组织下，由工程组内部进展检查。检查后，检查人将检查结果和意见记入?评审报告?。检查通过后，由工程经理签发?评审报告?，确认详细设计完成，可进入开发阶段。假设符合4.2.5.1的规定应提交?系统规格说明书?，代替?详细设计报告?提交检查。4.2.6. 编码和单元测试4.2.6.1. 过程1. 程序员根据?任务单?，在技术

25、负责人、系统分析员的指导下，进展下述开发：a开发每个组件或功能单元和数据库；b为测试每个组件或功能单元和数据库而开发的测试软件和数据；c为进展软件集成而开发的测试软件和数据。2. 程序员应当测试每个组件或功能单元和数据库，以保证它们符合需求。记录?测试记录?。3. 技术负责人和质量控制负责人应当评价软件的代码和测试结果，使其包括下面的准那么：a. 代码标准性；b各单元需求之间的内部一致性；c单元的测试结果。d评价结果记入?任务单?。e使用的编码方法和标准是否恰当；f集成、操作和维护的可行性。4.2.6.2. 阶段结果可正确执行的程序代码。?测试记录?。?任务单?。4.2.6.3. 评审技术负责

26、人和质量控制负责人应当评价软件的代码和测试结果，结果记入 ?测试记录?或?任务单?。4.2.7. 系统集成和系统集成测试4.2.7.1. 过程1. 由工程经理指定的程序员，应当根据?详细设计?、?任务单?的要求组装各个软件单元、组件，使之可运行并实现部分或全部软件功能。2. 质量控制负责人应当组织对集成的软件的功能进展测试。保证每个集合体都能满足需求，并且在集成活动完毕时形成部分可以运转的的软件系统。集成和测试的结果应当记入?测试记录?。3. 为了进展软件的系统测试，质量控制负责人应当保证集成后的软件系统可以进展软件系统测试。4. 工程经理和技术负责人、质量控制负责人应当对集成方案、设计、代码

27、、测试、测试结果进展评价，使其包括下面的准那么：a软件功能需求的可跟踪性；b与软件功能需求的外部一致性；c软件单元、组件的内部一致性；d软件功能需求的测试范围；e使用的测试方法和标准是否恰当；f是否符合预期的结果；4.2.7.2. 阶段结果?测试记录?。?任务单?。4.2.7.3. 评审工程经理和技术负责人、质量控制负责人应当对集成方案、设计、代码、测试、测试结果进展评价，其内容记入?测试记录?。4.2.8. 系统测试4.2.8.1. 过程1. 质量控制负责人组织测试人员，根据?需求分析报告?、?概要设计报告?的要求进展系统测试。应当保证对每项要求进展符合测试。应将系统测试结果记录?测试记录?

28、。2. 必要时，文档制作人员应当更新用户手册。3. 工程经理和技术负责人应当对设计、代码、测试、测试结果和用户手册进展评价，使其包括下面的准那么：a. 对软件系统需求的可跟踪性；b与软件系统需求一致性；d软件系统需求的测试范围；e是否符合预期结果；f操作和维护的可行性。4. 应当保证软件系统的测试成功并符合需求，而且用户手册中充分描绘了软件的操作要求、过程及操作的限制。5. 为系统封装或适当时的安装和验收，更新和准备可交付的软件；4.2.8.2. 阶段结果?测试记录?。?测试报告?。4.2.8.3. 评审质量控制负责人、工程经理和技术负责人应当对设计、代码、测试、测试结果评价，其结果记入?测试

29、记录?、?测试报告?。4.2.9. 系统安装4.2.9.1. 过程这个阶段的关键任务是将通过系统集成测试的软件完成最后的包装，交付客户。同时在客户的安排下，根据?工程施行方案?的安排，进入现场，在客户指定的系统软件和系统硬件的环境下，完成软件系统的安装，同时将安装结果，记录成文档，由客户代表签字确认安装完成。4.2.9.2. 阶段结果包装的软件系统。?用户手册?。?系统安装手册?。4.2.9.3. 评审由工程经理检查工作完成情况签批?系统安装手册?。4.2.10. 软件维护、更正过程4.2.10.1. 过程当系统由于错误、缺陷、问题或客户的需要改进和修改时，从而要对代码和相关的文档进展修改时即

30、进入此过程。其目的是在保持现有系统整体性的同时修改它。此过程以客户确认而终止。1. 为了进展改正和修改，工程经理、技术负责人、系统分析员应当对问题进展讨论。2. 工程经理应当在分析的根底上，选择修改的方法，安排修改。3. 工程经理通过与客户的商谈，确定修改的方法和安排。4. 工程经理应当将问题修改恳求、分析结果记入?修改记录?。 5. 程序员在工程经理、技术负责人、系统分析员的指导下，进入开发过程以施行修改。6. 质量控制人员将测试结果记入?测试记录?。 4.2.10.2. 阶段结果修改、调试后的软件系统。?测试记录?。?修改记录?。4.2.10.3. 评审工程经理、质量控制负责人应对修改结果

31、进展检查，结果记入?修改记录?、?测试记录?，签批?修改记录?和?测试记录?。4.2.11. 用户教育4.2.11.1. 过程工程交付客户后，根据?工程施行方案?完成对客户的培训。4.2.11.2. 阶段结果?工程验收单?。4.2.11.3. 评审工程经理制作?工程验收单?，在客户确认系统验收时，确认培训情况。4.2.12. 客户确认验收4.2.12.1. 过程1. 确认工程开发已经完成，使客户满意。2. 应当保证每项系统需求都已进展系统测试、把系统测试的结果写成文档，而且系统已做好交付准备。4.2.12.2. 阶段结果?工程验收单?。4.2.12.3. 评审工程经理制作?工程验收单?，在客户确认系统验收合格后，请客户签收。4.2.13. 工程总结4.2.13.1. 过程确认工程开发已经完成