软件工程实施程序.doc

软件工程实施程序本页为作品封面，下载后可以自由编辑删除，欢迎下载！ 精 品文档1【精品word文档、可以自由编辑！】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 9385-88。h) 质量管理和保证标准第三部分：GB/T19001-ISO9001在软件开发、供应和维护中的使用指南。i) 公司质量体系程序文件设计和开发控制程序。j) 公司质量体系程序文件产品策划和生产服务控制程序。k) 公司质量体系程序文件项目质量计划控制程序。1.1. 常用术语1.1.1. 软件 software软件是指计算机程序及其有关的数据和文档，也包括固化了的程序。1.1.2. 软件生存周期 software life cycle软件生存周期进指从系统对计算机软件系统提出应用需求开始，经过开发，产生一个满足需求的计算机软件系统，然后投入运行，直至该软件系统退役为止。期间经历系统分析与软件定义、软件开发以及系统的运行与维护等三个阶段。其中软件开发阶段一般又划分成需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试发及安装与验收等六个阶段。1.1.3. 审查 inspection a) 一种正式的评定技术。由除作者之外的某人或某一小组仔细检查软件需求、设计或代码，以找出故障、违反开发标准之处和其它一些问题。与软件工程术语GBT11457-1995 2 545条相对照。参见软件工程术语GBT11457-1995 2 63条。b) 质量管理的一个阶段。在此阶段借助检查。观察或测量来确定材料、必须品、零部件、附属 品、系统、过程或结构是否符合预定的质量要求。 1.1.4. 需求 requirement客户为解决某一问题或达到某个目标所需要的条件或能力。系统或系统部件为满足或具有的条件或能力以满足合同、标准、规格说明或其它正式的强制性文件。所有需求的集合形成了以后开发系统或系统部件的基础。参见软件工程术语GBT11457-19952404条、2406条。2407条。 1.1.5. 需求分析 requirements analysis 研究客户要求以得到系统或软件需求的定义的过程。对系统需求或软件需求的验证。1.1.6. 需求阶段 requirements phase软件生存周期中的一个阶段。在此期间对软件产品的需求（如功能和性能方面的能力）进行定义并编制出相应的文档。1.1.7. 需求规格说明 requirements specification 陈述系统或系统部件（例如，软件配置项）的需求的规格说明，通常包括功能需求、性能需求。接口需求、设计需求以及开发标准。1.1.8. 概要设计 Preliminary designa) 分析各种设计方案和定义软件体系结构的过程。典型的概要设计包括计算机程序组成成分和数据的定义及构造、界面的定义，并提出时间和规模方面的估计。 b) 概要设计过程的结果。参见软件工程术语GBT11457-1995 2135条、2216条。 1.1.9. 详细设计 detailed designa) 推敲并扩充初步设计，以获得关于处理逻辑、数据结构和数据定义的更加详尽的描述，直到设计完善到足以能实现的地步。 b) 详细设计过程的结果。 1.1.10. 代码，编码 code a) 一组无歧义性的规则，它规定了使数据得以用某种离散形式加以表示的方式。b) 用处理机可以接受的符号形式表示数据或计算机程序。c) 书写例行程序。d) 也可指一个或多个计算机程序，或计算机程序一部分。 已为了安全的目的对数据进行的加密表示。1.1.11. 注释 comment a) 在计算机程序、命令语言或数据之间的说明信息，旨在给读者提供澄清性材料，并不影响机器的解释工作。 b) 加到或散置在源语言语句当中的描述、附注或解释，在目标语言中这些是无效的1.1.12. 代码审计 code audit 由某人、某小组、或借助某种工具对源代码进行的独立的审查，以验证其是否符合软件设计文件和程序设计标准。还可能对正确性和有效性进行估计。参见软件工程术语GBT11457-1995234条、2468条、2237条、2545条。1.1.13. 验证 verification验证是指确定软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程。1.1.14. 确认 validation确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。1.1.15. 测试 testing测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。1.1.16. 软件质量 software quality软件质量是指软件产品中能满足给定需求的各种特性和总和。这些特性称做质量特性，它包括功能度、可靠性、时间经济性、资源经济性、可维护性和或移植性等。1.1.17. 质量保证 quality assurance质量保证是指为使软件产品规定需求所进行的一系列有计划的必要工作。2. 适用范围软件工程实施程序适用于纯软件开发项目的实施过程和软硬件集成项目中与软件开发相关的的实施过程。3. 人员职责3.1. 项目经理a) 负责项目设计开发的管理。b) 制定项目实施计划，确定开发组人员分工，监控计划的执行。c) 组织实施该计划以满足目标和标准的要求，履行对过程的控制。d) 在业务代表的协助下，协调与客户关系，协调各部门的关系。e) 整体掌握项目需求和技术方案，按时提交阶段任务结果。 f) 调查、分析和解决在项目实施过程中发现的问题。问题的解决可以导致对计划的修改。保证任何计划改变所造成的影响都在控制和监督之下。问题及其解决办法都应当写成文档。 g) 保证对产品和计划进行检查，使产品和计划在完成或变更之后保持完整性和一致性。h) 从完整性方面检查产品完成的结果和记录，这些结果和记录应当存档。3.2. 技术负责人（项目技术总监）a) 对项目经理负责。b) 对项目的技术方向和技术成果负责。c) 确立系统的技术方案及开发的总体目标，组织对概要设计、详细设计进行内部审核。d) 提出系统开发修改方案。e) 在开发过程中对程序员进行指导。f) 按时提交阶段任务结果。3.3. 系统分析员a) 对项目经理负责，依据软件工程实施程序和相应的作业指导书的要求实施系统分析和设计过程，提交相应的文档。b) 依据项目实施计划完成项目的技术设计，对设计质量负责。c) 依据测试计划在质量控制负责人的组织下，进行系统测试。d) 按时提交阶段任务结果。3.4. 界面美工a) 对项目经理负责。b) 界面风格设计，界面制作、美工制作。c) 依据测试计划在质量控制负责人的组织下，参加系统测试。3.5. 文档管理人员a) 对项目经理负责。b) 依据项目实施计划，中的要求，维护管理文档，保证文档的完整性和一致性。c) 依据测试计划在质量控制负责人的组织下，参加系统测试。3.6. 程序员a) 对项目经理负责。b) 编码调试，依照任务单、详细设计报告按期、安质完成模块编码。c) 完成单元测试。依据测试计划在质量控制负责人的组织下，参加系统测试。3.7. 质量控制负责人a) 检查系统的概要设计、详细设计。b) 依据系统的概要设计、详细设计，完成项目的测试计划的制作，监督测试记录的制作，按计划组织测试。c) 保证对产品和计划进行检查，使产品和计划在完成或变更之后保持完整性和一致性。d) 从质量管理方面，控制可能出现的风险，及时报告项目经理。3.8. 用户教育负责人在项目交付完成后，应在用户教育负责人的组织下，完成对客户的培训。a) 对项目经理负责。b) 组织用户文档编写。c) 依据依据项目实施计划的要求，依据客户的要求完成用户的培训。d) 积极向用户解释，软件系统的使用方法，及时向项目经理报告客户的反应。4. 工作程序4.1. 流程下图描述了项目开发实施过程的流程，图中右侧是每个阶段的输入和输出，中间是处理过程，左侧是评审或检查的要点。图1. 软件项目实施流程1图2. 软件项目实施流程2图3. 软件项目实施流程34.2. 各阶段的过程及评审4.2.1. 项目策划4.2.1.1. 过程1. 为了保证交付的系统、产品或服务的质量，全面评审合同中的需求，项目经理通过与销售、售前支持的沟通理解顾客的要求。2. 项目经理应确定或选择与项目的范围、规模和复杂性相适合的软件生存周期模型。应当把从本标准中选出的过程、活动和任务影射到该生存周期模型中。该生存周期模型应当包括可使用的开发环境，其中包括标准、方法和工具等。 3. 编制项目实施计划。计划应包括：a) 对资源的需求和客户的介入。b) 为开发该产品或提供该服务选择方案。 可供选择的方案有： a利用研发中心现有的资源提供产品或提供服务； b通过与客户的协商，分阶段完成合同规定的产品或服务或用子合同方式开发产品或提供服务； c从研发中心或采购现货产品； d上述a、b二条结合。c) 项目管理计划 在这些计划中应当规定下述事项： a. 项目的组织机构，以及包括外部机构在内的每个机构的权利和责任； b开发环境，包括测试环境。库、设备、仪器以及工程标准、步骤和工具； c生存期过程和活动的工作细目的结构，其中包括可交付的产品，与任务有关的经费预算、人员。物理资源、软件的规模以及时间进度； d系统的质量需求管理。如果需要，可以另外制订质量保证计划； e系统安全和保密的关键需求管理。如果需要，另外制订安全和保密计划； f客户的介入，即按合同要求进行的评审和审计、非正式的会面、报告、修改和变更的实施、批准、验收、对设施的使用等； g验证和确认，在必要的情况下，规定中应包括与独立的验证和确认机构接触的方法； h质量保证，明确项目的质量目标和产品、服务的质量保证手段、方法、时间安排等； i风险管理，此项管理包括对项目的潜在技术、成本和进度诸风险领域的管理； j制定计划、跟踪和报告的方法； k人员培训，明确项目的人员培训的要求，及人员培训的安排。4.2.1.2. 阶段结果项目实施计划。4.2.1.3. 评审项目实施计划由项目经理负责编写，项目实施计划应提交研发中心的评审组进行评审。评审后，评审负责人评审结果和意见记入评审报告。评审通过后，项目方可进入下一个实施阶段。根据项目情况，可以以会签或会议的方式进行评审。4.2.2. 需求分析4.2.2.1. 过程1. 对系统的要求进行分析，以建立系统需求。系统需求应当说明：系统的功能和性能；安全、保密、人机工程、接口、操作和维护需求；设计限制和鉴定的要求。2. 系统分析员在项目经理的组织先完成需求的分析、调查过程，并将需求分析结果写成文档。 该文档描述： a功能和能力规格说明，其中包括性能、物理特性、运行软件的环境条件；b用户文档；c安全规格说明，其中包括与操作和维护的方法、环境影响和人员伤害有关的说明； d保密规格说明，依据合同或客户的需求描述对敏感性信息或资料的保护手段；e人机工程和人一机规格说明，其中包括与人工操作、人机对话、对人员的限制有关的规格说明，以及那些对于人的错误和能力很敏感的、需要人集中注意力的领域的说明；f处理器、存储设备或数据通道所用的硬件处理和资源储备的规格说明；g数据定义和数据库的需求；h已交付软件在操作和维护现场上的安装和验收的需要； i用户维护需求。 j与其他系统接口的需求3. 对系统需求进行评价，使其包括下述准则 a对系统需求和系统设计的可跟踪性； b与系统需求的外部一致性； c各种软件需求之间的内部一致性； d. 软件需求的可测性； e软件需求的测试范围； f软件设计、操作和维护的可行性。 4. 研发中心评审组应当进行合同所要求的评审，以决定软件需求的完善和恰当。5. 对于内部项目或开发工作量小于6人/月的项目，应编制系统规格说明书代替需求分析报告，其内容需覆盖需求分析工作的内容。4.2.2.2. 阶段结果需求分析报告或系统规格说明书。4.2.2.3. 评审需求分析报告由项目经理组织系统分析员编写，需求分析报告应提交研发中心的评审组进行评审。评审后，评审负责人评审结果和意见记入评审报告。评审通过后，项目方可进入下一个实施阶段。根据项目情况，可以以会签或会议的方式进行评审。若符合4.2.2.1的规定应提交系统规格说明书，代替需求分析报告提交评审。4.2.3. 概要设计 (总体设计)4.2.3.1. 过程1. 建立系统体系结构。应当在系统的体系结构中体现系统的需求，该系统体系结构要表现出系统的内部结构以及硬件、软件和人工操作的要求。2. 明确系统或子系统的每个功能需求，应当执行的下述任务：a) 系统分析人员应当把软件需求转变为一个体系结构，该体系结构应描述它的结构、定义它的主要部分。它应当保证系统的结构、功能的描述和要求覆盖系统的需求，可以对其细化进行详细设计。b) 系统分析人员应当明确规定软件系统与外部接口的设计、各软件部分之间的设计。 c) 系统分析人员应当编写数据库设计文档。3. 项目经理和技术负责人应当确认软件配置项的体系结构、接口和数据库的设计，使其包括下面指出的各项：a. 对软件系统需求的可跟踪性； b.与软件系统需求的外部一致性； c.各部分需求之间的内部一致性；d.所使用的设计方法和标准是否恰当；e.详细设计、操作和维护的可行性。 4. 在项目经理的指导下，由技术负责人组织，系统分析员为测试软件单元规定测试要求和时间进度，并将其写成文档。5. 应当对工作结果进行的评审，以确定设计方法是完善和恰当的。6. 对于内部项目或开发工作量小于6人/月的项目，应编制系统规格说明书代替概要设计报告，其内容需覆盖概要设计工作的内容 4.2.3.2. 阶段结果概要设计报告或系统规格说明书。数据库设计报告。测试计划。4.2.3.3. 评审概要设计报告由项目经理组织系统分析员编写，概要设计报告应提交研发中心的评审组进行评审。评审后，评审负责人评审结果和意见记入评审报告。评审通过后，项目方可进入下一个实施阶段。根据项目情况，可以以会签或会议的方式进行评审。若符合4.2.3.1的规定应提交系统规格说明书，代替概要设计报告提交评审。4.2.4. 界面设计4.2.4.1. 过程1. 在概要设计过程中，应建立系统界面设计原则，依据客户的需求，完成整个系统的用户界面设计。2. 界面制作人员在项目经理、系统分析员的指导下完成系统的界面制作，模拟系统的运转过程。3. 依据客户的需求，项目经理应对客户讲解界面设计的原则，通过模拟系统的运转过程，讲解对系统需求的理解。4.2.4.2. 阶段结果界面设计报告。系统的运转界面4.2.4.3. 评审界面设计报告由项目经理组织系统分析员编写，界面设计报告应由项目经理确认、签字。4.2.5. 详细设计4.2.5.1. 过程1. 系统分析员应当依据概要设计阶段的设计成果，详细设计软件功能的每个组件或功能单元。应当尽量地将各个软件功能详细划分为组件或功能单元，以便进行编码、编译和测试。应当保证该软件的需求已完全分配给从软件功能到组件或功能单元的整个软件系统。应当把该详细设计写成文档。2. 系统分析员应当写出组件或功能单元的实现详细设计文档，并明确规定各个组件或功能单元的接口，明确规定组件或功能单元与软件功能的关系。3. 系统分析员、文档管理人员最好写出软件用户手册的最初版本。 4. 在项目经理的指导下，由质量控制负责人组织编写为软件系统测试规定测试要求、进行测试设计，为每个功能项规定测试用例（输入、输出、测试准则）和测试步骤，将这部分内容写入测试计划。项目经理和技术负责人应当评价软件的详细设计和测试要求，使其包括下面的准则：a. 对软件系统功能需求的可跟踪性； b. 与体系结构设计的外部一致性； c各组件和功能单元的需求之间的内部一致性； d所使用的设计方法和标准是否恰当； e测试、操作和维护的可行性。 6. 对于内部项目或开发工作量小于6人/月的项目，应编制系统规格说明书代替详细设计报告，其内容需覆盖详细设计工作的内容。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. 程序员依据任务单，在技术负责人、系统分析员的指导下，进行下述开发：a开发每个组件或功能单元和数据库；b为测试每个组件或功能单元和数据库而开发的测试软件和数据；c为进行软件集成而开发的测试软件和数据。2. 程序员应当测试每个组件或功能单元和数据库，以保证它们符合需求。记录测试记录。3. 技术负责人和质量控制负责人应当评价软件的代码和测试结果，使其包括下面的准则：a. 代码规范性；b各单元需求之间的内部一致性；c单元的测试结果。d评价结果记入任务单。e使用的编码方法和标准是否恰当；f集成、操作和维护的可行性。4.2.6.2. 阶段结果可正确执行的程序代码。测试记录。任务单。4.2.6.3. 评审技术负责人和质量控制负责人应当评价软件的代码和测试结果，结果记入 测试记录或任务单。4.2.7. 系统集成和系统集成测试4.2.7.1. 过程1. 由项目经理指定的程序员，应当依据详细设计、任务单的要求组装各个软件单元、组件，使之可运行并实现部分或全部软件功能。2. 质量控制负责人应当组织对集成的软件的功能进行测试。保证每个集合体都能满足需求，并且在集成活动结束时形成部分可以运转的的软件系统。集成和测试的结果应当记入测试记录。3. 为了进行软件的系统测试，质量控制负责人应当保证集成后的软件系统可以进行软件系统测试。4. 项目经理和技术负责人、质量控制负责人应当对集成计划、设计、代码、测试、测试结果进行评价，使其包括下面的准则：a软件功能需求的可跟踪性；b与软件功能需求的外部一致性；c软件单元、组件的内部一致性；d软件功能需求的测试范围；e使用的测试方法和标准是否恰当；f是否符合预期的结果；4.2.7.2. 阶段结果测试记录。任务单。4.2.7.3. 评审项目经理和技术负责人、质量控制负责人应当对集成计划、设计、代码、测试、测试结果进行评价，其内容记入测试记录。4.2.8. 系统测试4.2.8.1. 过程1. 质量控制负责人组织测试人员，依据需求分析报告、概要设计报告的要求进行系统测试。应当保证对每项要求进行符合测试。应将系统测试结果记录测试记录。2. 必要时，文档制作人员应当更新用户手册。3. 项目经理和技术负责人应当对设计、代码、测试、测试结果和用户手册进行评价，使其包括下面的准则：a. 对软件系统需求的可跟踪性；b与软件系统需求一致性；d软件系统需求的测试范围；e是否符合预期结果；f操作和维护的可行性。4. 应当保证软件系统的测试成功并符合需求，而且用户手册中充分描述了软件的操作要求、过程及操作的限制。5. 为系统封装或适当时的安装和验收，更新和准备可交付的软件；4.2.8.2. 阶段结果测试记录。测试报告。4.2.8.3. 评审质量控制负责人、项目经理和技术负责人应当对设计、代码、测试、测试结果评价，其结果记入测试记录、测试报告。4.2.9. 系统安装4.2.9.1. 过程这个阶段的关键任务是将通过系统集成测试的软件完成最后的包装，交付客户。同时在客户的安排下，依据项目实施计划的安排，进入现场，在客户指定的系统软件和系统硬件的环境下，完成软件系统的安装，同时将安装结果，记录成文档，由客户代表签字确认安装完成。4.2.9.2. 阶段结果包装的软件系统。用户手册。系统安装手册。4.2.9.3. 评审由项目经理检查工作完成情况签批系统安装手册。4.2.10. 软件维护、更正过程4.2.10.1. 过程当系统由于错误、缺陷、问题或客户的需要改进和修改时，从而要对代码和相关的文档进行修改时即进入此过程。其目的是在保持现有系统整体性的同时修改它。此过程以客户确认而终止。1. 为了进行改正和修改，项目经理、技术负责人、系统分析员应当对问题进行讨论。2. 项目经理应当在分析的基础上，选择修改的方法，安排修改。3. 项目经理通过与客户的商谈，确定修改的方法和安排。4. 项目经理应当将问题修改请求、分析结果记入修改记录。 5. 程序员在项目经理、技术负责人、系统分析员的指导下，进入开发过程以实施修改。6. 质量控制人员将测试结果记入测试记录。 4.2.10.2. 阶段结果修改、调试后的软件系统。测试记录。修改记录。4.2.10.3. 评审项目经理、质量控制负责人应对修改结果进行检查，结果记入修改记录、测试记录，签批修改记录和测试记录。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. 过程确认项目开发已经完成，总结开发过程，评价管理过程的有效性。4.2.13.2. 阶段结果项目开发总结报告。4.2.13.3. 评审在项目完成后，项目经理组织项目组内部总结，并编写项目开发总结报告，项目开发总结报告应提交研发中心的评审组进行评审。评审后，评审负责人评审结果和意见记入评审报告。根据项目情况，可以以会签或会议的方式进行评审。4.2.14. 项目完成4.2.14.1. 过程项目开发已经完成，完成组织内部的文档交付和演示系统的建立。4.2.14.2. 阶段结果演示系统。文档交付完成，依据要求存储。4.2.14.3. 评审由研发中心组织确认演示系统，并记录交付的文档，其过程参见文件控制程序、文档资料管理规定。4.2.15. 质量管理和软件质量保证过程4.2.15.1. 过程质量管理和软件质量保证始终贯穿在软件工程实施的过程中，通过各个过程要求的评审和检查及软件的集成测试和系统测试，保证了设计、开发的质量，达到客户的满意，同时质量管理和软件质量保证过程是一个反复循环的过程，在任何一个软件工程实施的过程发生变更后，应该重新实施评审和检查及软件的集成测试和系统测试。在一个软件工程实施的过程中，项目经理应当为此项目的生存期制订进行软件质量管理活动的计划，作为项目实施计划的一个部分，执行它、维护它。该内容应当包括下述各项：a质量的目标，包括验证、确认、测试、审计和质量测量活动； b执行软件质量管理活动的质量标准、方法、步骤和工具（或引用机构的正式文件中的有关内容）； c合同规定的评审和协调的步骤； d标识、收集、编写文档、维护和处置质量记录的步骤； e执行软件质量管理活动的资源、时间表和责任。4.2.15.2. 阶段结果4.2.15.3. 评审由于本阶段贯穿项目实施过程始终，该阶段的评审应放入项目完成阶段中。5. 引用文件a） 设计和开发控制程序b） 产品策划和生产服务控制程序c） 质量记录控制程序6. 记录a） 项目实施计划。b） 需求分析报告。c） 概要设计报告。d） 详细设计报告。e） 界面设计说明书。f） 数据字典。g） 数据库设计说明书。h） 任务单。i） 测试计划。j） 测试记录。k） 系统安装报告l） 项目验收单。m） 项目开发总结报告。n） 用户手册o） 修改记录。p） 系统规格说明书。q） 工作备忘录。r） 评审报告s） 项目交接记录。第23页共23页