软件开发实施方案共7篇.docx

1、软件开发实施方案（共7篇） 第1篇：软件开发实施方案1 软件开发实施方案系统开发严格按照软件工程的方法进行组织， 系统的开发过程按照需求分析、系统分析与设计要求、系统编码、系统测试几个过程有 序推进。下表所示系统开发流程图，采用原型及迭代方式开发，根据 用户需求持续改进，直到最终用户确认满意。1.1 开发流程总述如下图示流程定义了我公司内部的软件开发过程， 以指导和规范软件项目中开发过程的定义和相应的实施。该过程可划分为一系列子过程，包括：软件需求分析、设计、编码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如 设计过程又可分为结构设计和详细设计。 但是在实际开发项目中， 情 况仍然

2、会是千变万化的， 因此我们也并不是一成不变的死板执行一个 僵化的工作流程， 我们的原则是在一个规范流程的指导和约束下， 根 据具体工程项目的实际要求， 为每一个项目评估并制定真正能够最好 的满足该项目要求的开发流程。开始软件需求分析YN：改进YN：改进YN：改进软件需求规格说明书（初稿）系统测试计划系统测试案例（初稿）用户手册（概要） 追溯表一软件需求规格说明书系统测试计划系统测试案例个人评审记录评审报告同行评审通过结构设计评审通过结构设计说明书（初稿）集成测试计划集成测试案例（初稿）用户手册（初稿） 追溯表一结构设计说明书集成测试计划集成测试案例个人评审记录 评审报告详细设计说明书（初稿）单

3、元测试计划单元测试案例（初稿）用户手册（修改稿） 追溯表一详细设计说明书单元测试计划单元测试案例用户手册（修改稿）个人评审记录评审报告源代码、源代码文件清单单元测试报告（经过审批）软件问题状态登记表 软件问题报告单集成工作单集成测试工作单集成测试报告（经过审批）软件问题状态登记表软件问题报告单 集成的软件系统系统测试报告（经过审批）软件问题状态登记表软件问题报告单系统管理员使用说明书 ( 经过审批)安装手册（经过审批）用户手册（经过审批 软件系统（系统测试通过）验收测试报告软件问题报告单软件问题状态登记表验收报告 可交付产品软件需求规格说明书（升级版）客户需求登记表客户需求统计表设计说明书（升

4、级版）软件问题报告单软件问题状态登记表软件维护实施计划 维护后的软件系统详细设计评审通过编码集成测试系统测试验收维护结束图 1.1-1 软件开发流程总图在应用系统软件开发项目中， 我们仍将遵循这一思想， 这一点将在随后的项目开发实施计划部分有具体的体现， 在这里和下面的相关章节中，我们仍将围绕着这个完整的开发流程来分析说明， 以此来阐明我们对项目开发的完整过程管理思想和相关实践。 下面我们对这个软件开发工作流程进行简要地分解说明。1.2 软件需求分析（1）概述由于应用系统与众多相关应用软件需要进行交互， 因此需要先对这些应用系统进行分别梳理， 充分做好需求调研工作， 编写经项目单位认可并评审通

5、过的系统需求规格说明书 。软件需求分析是按照项目定义的软件开发过程， 根据系统分配给软件的需求（见 系统需求规格说明书），进行软件质量特性规格说明的过程。该过程包括进一步明确软件运行环境， 明确对软件的功能、性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，并对软件需求进行验证和文档化， 即完成对软件需求的分析与规格定义。本元素在整个过程中的位置如下图所示：系统分配给软件的需求软件需求分析 结构设计图示：软件需求分析在软件开发过程中的位置（2）入口准则和出口准则1）入口准则要素判断准则客户需求（系统需求规格已由 CCB批准为基线说明书）已进入配置库2）出口准则要素判断准则已经过审查软

6、件需求规格说明书已批准为基线已进入配置库系统测试计划已经过审查已获得批准系统测试案例已进入配置库用户手册（概要） 追溯表一已编写已填写（3）评审评审软件需求规格说明书 ，具体评审过程见评审程序文件，对软件需求的评审准则包括： 系统需求和系统设计的可追溯性； 与系统需求的一致性； 内部一致性； 可测试性； 软件设计的可行性； 运作和维护的可行性。对软件需求中的问题， 与系统工程组或客户一起确定和审查， 根据审查结果对软件需求进行适当的修改， 必要时按基线变更控制的要求对客户需求进行相应的修改。 对软件需求规格说明书进行同行评审。审查、批准软件需求规格说明书。将软件需求规格说明书置于配置管理之下。

7、 4）工作产品 软件需求规格说明书 系统测试计划 系统测试案例 用户手册 追溯表 （ 5）职责 项目经理：负责组建软件需求分析组；确定是否需要对有关人员进行培训；负责软件需求规格说明书的审查和批准。 软件需求分析组：软件需求分析的主要承担者，负责完成本过程元素要求产生的所有工作产品。 系统测试负责人：负责组织软件系统测试组对软件需求进行分析，审查软件需求的可测试性；参与软件需求规格说明书的审查和批准。 质量保证人员：参与工作产品的审查，统计缺陷，并对软件需求分析过程进行审计。 系统开发组：配合处理涉及客户需求的软件需求问题。 客户：必要时参与软件需求规格说明书的审查和批准。1.3 结构设计（

8、1）概述结构设计是指按照软件需求规格说明书 ，设计软件系统的体系结构，即模块结构，定义每个模块的主要功能和模块之间的联系 （即接口），并确定软件系统的数据体系结构。本元素在整个过程中的位置如下图所示：软件需求分析结构设计 详细设计图示：软件需求分析在软件开发过程中的位置图（2）入口准则和出口准则1）入口准则要素判断准则软件需求规格说明书 经过审查审查获得批准进入配置库2）出口准则要素结构设计说明书 集成测试计划 集成测试案例 用户手册（初稿）判断准则经过审查审查获得批准进入配置库已完善追溯表一（ 3）评审 对结构设计说明书和集成测试计划进行同行评审。 对结构设计中的问题，与软件需求分析人员一起

9、确定和审查，并对结构设计进行适当的更改。 审查、批准结构设计说明书，必要时，对其进行设计评审。 将结构设计说明书、集成测试计划 和集成测试案例置于配置管理之下。（ 4）工作产品 结构设计说明书 集成测试计划 集成测试案例 用户手册 追溯表 （ 5）职责1）项目经理负责选择合适的设计人员，组建结构设计工作组；负责结构设计说明书和集成测试计划的审查和批准。2）结构设计人员结构设计阶段工作的主要承担者， 负责完成本过程元素产生的所有工作产品。3）系统分析员配合处理涉及软件需求的问题。4）系统开发负责人负责组织系统工程组对结构设计进行分析， 审查结构设计的可测试性；负责协调处理涉及软件需求的问题；参与

10、结构设计说明书和集成测试计划的审查和批准。5）软件测试负责人负责组织软件测试组对结构设计进行分析， 审查结构设计的可测试性；参与结构设计说明书和集成测试计划的审查和批准。1.4 详细设计（1）概述详细设计是根据 结构设计说明书进行模块设计，将结构设计所获得的模块按照单元、程序、规程的顺序逐步细化。详细定义各个单元的数据结构、程序的实现算法以及程序、单元、模块之间的接口等，作为以后编码工作的依据。本元素在整个过程中的位置如下图所示：结构设计详细设计 编码图示：详细设计在软件开发过程中的位置（2）入口准则和出口准则1）入口准则要素判断准则 经过审查 审查获得批准结构设计说明书进入配置库2）出口准则

11、要素 判断准则要素判断准则 经过审查 审查获得批准详细设计说明书进入配置库（3）评审对详细设计说明书和单元测试计划可进行走查或（和）同行评审；对详细设计中的问题， 与结构设计人员一起确定和审查， 并对详细设计做出适当的更改；审查、批准详细设计说明书 ，必要时，对其进行设计评审；将详细设计说明书和单元测试计划置于配置管理之下。（ 4）工作产品 详细设计说明书 单元测试计划 单元测试案例 用户手册 追溯表 （ 5）职责1）项目经理负责选择合适的设计人员，组建详细设计组；负责详细设计说明书和单元测试计划的审查和批准。2）详细设计人员详细设计阶段工作的主要承担者。 负责完成本过程元素产生的所有工作产品

12、3）系统分析员配合处理涉及软件需求的问题。4）系统开发负责人负责组织系统工程组对详细设计进行分析， 审查详细设计的可测试性；负责协调处理涉及软件需求的问题；参与详细设计说明书和单元测试计划的审查和批准。5）软件测试负责人负责组织软件测试组对详细设计进行分析， 审查详细设计的可测试性；参与详细设计说明书和单元测试计划的审查和批准。1.5 编码（1）概述编码阶段主要完成的工作是根据详细设计说明书编写程序源代码，包括必要的数据文件， 并进行单元测试，单元测试的内容包括模块内程序的逻辑、功能、参数传递、变量引用、出错处理等方面。本元素在整个过程中的位置如下图所示：详细设计编码 集成测试图示：编码阶段

13、在软件开发过程中的位置（2）入口准则和出口准则1）入口准则要素判断准则详细设计说明书经过审查单元测试计划 获得批准进入配置库2）出口准则要素判断准则源代码文件源代码文件获得批准源代码文件清单源代码文件进入配置库的源代码区单元测试报告提交测试负责人软件问题报告单提交问题管理渠道（3）评审对源代码文件进行同行评审， 主要的方法为对照详细设计说明书对代码进行查阅，也可根据编程者的经验或程序的难度、重要程度，选择走查评审方式，但目的都是发现程序存在的问题。（ 4）工作产品 源代码文件 单元测试报告 软件问题报告单 软件问题状态登记表 （ 5）职责1）项目经理建立编码组、测试组或相应岗位，并进行必要的培

14、训；跟踪进度和问题解决状态； 对提交的源代码进行批准 （或指定负责人进行批准工作）。2）程序员编写程序代码；测试程序代码；修改程序代码；提交工作产品，批准后将其导入配置区的源码库。3）单元测试人员测试源代码；提交测试报告和软件问题报告单。4）评审人员对指定源代码文件进行阅读，发现缺陷和问题，填写评审报告。1.6 模块集成测试（1）概述集成测试阶段主要完成的工作是集成和集成测试。 集成是参考结构设计说明书并根据详细说明书中规定的系统集成方案将不同的经测试的程序单元进行构造， 并逐步构造成一个完整的软件产品的过程；集成测试则是在集成完成之后， 对各单元、模块之间接口的正确性和集成后功能的正确性进行

15、验证。对于大型软件， 集成测试可以采取分步进行的方法， 可以先对各子系统进行集成测试，然后在子系统之间进行集成测试。本元素在整个过程中的位置如下图所示：编码集成测试 系统测试图示：集成测试在软件开发过程中的位置（2）入口准则和出口准则1）入口准则要素判断准则 经过审查 获得批准 进入配置库结构设计说明书详细设计说明书集成测试计划源代码文件2）出口准则要素判断准则 获得批准 进入配置库提交集成测试负责人 已进入软件问题管理流程集成的软件系统（完整的源代码和目标代码）集成测试报告软件问题报告单（3）审查阶段核查集成状态和结果，并进行批准；批准后，将目标程序和程序清单进入目标代码库。（ 4）工作产品

16、 集成后的系统目标代码 （包括文件清单），及相应的源代码（包括文件清单） 集成测试报告 软件问题报告单 软件问题状态登记表 集成工作单 集成测试工作单 （5）职责 项目经理：建立集成组、集成测试组或相应岗位，并进行必要的培训；跟踪进度和问题解决状态；对集成后的系统目标码进行批准（或指定负责人进行批准工作） 。 集成负责人员：负责集成过程的实施。 集成人员：负责环境构建，集成的过程操作，并将集成后的目标代码提交批准。 程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。 测试人员：测试系统目标码，将测试报告和软件问题报告单提交测试负责人。1.7 系统测试（1）概述系统测试的主

17、要任务是从系统需求的角度对系统运行的正确性和性能进行验证。系统测试的依据为系统测试计划。本元素在整个过程中的位置如下图所示：集成测试系统测试 验收图示：系统测试在软件开发过程中的位置（2）入口准则和出口准则1）入口准则要素判断准则 经过审查系统需求要素判断准则 获得批准 进入配置库 编写完成系统的目标代码系统测试计划用户手册2）出口准则要素判断准则 获得批准系统测试报告软件问题报告单（ 3）工作产品 系统测试报告 软件问题报告单 软件问题状态登记表 （ 4）职责 项目经理：负责建立系统测试组或相关的岗位，并进行必要的培训；跟踪进度和问题解决状态；对最终的目标代码进行批准（或指定负责人进行批准工

18、作） 。 程序员、设计人员：修改源码或设计，解决集成过程中出现的与源码有关的问题。 测试人员：测试系统目标码，将测试报告提交测试负责人，将软件问题报告单提交问题管理渠道。1.8 验收（1）概述验收阶段主要由验收测试、验收测试问题改正和验收三部分组成：验收测试的主要目的是验证所开发的系统在用户的使用环境下（或模拟的使用环境下） 是否满足系统需求， 从用户的角度验证整个系统运行的正确性。验收测试问题改正是对验收测试中发现的差异性问题进行修改。验收则是在验收测试的基础上， 依据项目合同或项目任务书对项目的完成情况进行综合评价。本元素在整个过程中的位置如下图所示：系统测试验收 维护图示：验收在软件开发

19、过程中的位置验收的三个组成部分视项目立项类型和客户的要求选择执行。（2）入口准则和出口准则1）入口准则要素判断准则验收测试前完成评审。验收测试计划（有验收测试要求的项目）测试（系统测试、集成测试、单已完成元测试）2）出口准则要素判断准则 已提交 已关闭 已提交验收测试报告验收测试问题报告单验收报告（3）工作产品 验收测试报告 软件问题报告单 软件问题状态登记表 验收报告 可交付产品（ 4）职责 验收测试组：负责验收测试的各项活动。 开发组人员：负责验收测试中发现问题的改正和测试辅助。 项目管理人员：负责指派验收测试责任和完成测试规程；确保测试质量和进程；确保组间协调。 验收组：具体进行验收。

20、CCB：批准运行基线。1.9 维护（1）概述维护期是指： 软件产品 / 系统验收后，进入软件运行 / 系统维护阶段，直至软件产品下一个版本的发布或系统维护期终止；本元素在整个软件开发过程中的位置如下图所示：验收维护图示：维护在软件开发过程中的位置（2）入口准则和出口准则1）入口准则要素判断准则软件产品 / 系统已验收2）出口准则要素判断准则软件产品已退役合同约定的维护期限已到期合同约定的维护范围已超出，须另签协议（3）工作产品软件需求规格说明书客户需求登记表客户需求统计表设计说明书软件问题报告单软件问题状态登记表软件维护实施计划维护后的软件系统（4）职责维护负责人：制定软件维护实施计划， 确认

21、维护类型、需求范围，分配维护任务，追踪任务的完成情况及其他项目管理工作。软件维护人员：负责进行软件维护任务的执行。QA人员：负责协助维护负责人根据实际情况剪裁标准流程。第2篇：软件开发方案和实施安排10.9.8软件开发方案所有的项目软件开发过程都应遵循一个生命周期模型，在软件的开发策划期间，需要仔细考虑项目的特征和目标，然后选择生命周期模型。在本项目中，本投标单位将选用常用的瀑布型生命周期模型。瀑布模型的主要特点是：只有当一个阶段的文档已编制好，且该阶段的产品得到质量保证人员（SQA）认可后，该阶段才算完成。测试或验证在每个阶段都必须执行；一旦产品完成提交用户，其后的任何修改均属于维护阶段。在

22、瀑布型模型中，主要定义的过程包括：需求分析、系统分析、代码实现、测试。 l 需求分析需求分析的目的是通过调查和分析，获取用户需求并定义产品需求。需求分析的输出文档是需求分析说明书（RAS）。需求分析说明书（RAS）将用客户语言来描述系统需求，其主要的目的是作为与用户沟通并达成一致的基础。这些需求需要用户参与进行评审，并得到用户的确认。然后对用户需求进行细化，对比较复杂的用户需求进行建模分析，最终形成面向软件产品的软件需求说明。需求分析的主要任务包括： 确定需求调查的方式，例如问卷式、面对面谈等； 调查与记录； 分析需求信息； 编写需求分析说明书（RAS）； 组织需求分析说明书（RAS）评审。

23、主要的角色与职责为： 系统分析员，调查和分析用户需求； 客户与最终用户提供必要的需求信息，并确认客户需求； 系统分析员定义产品软件需求； 客户与最终用户提供必要的信息，并确认产品需求。 l 系统设计系统设计是指设计软件系统的体系架构、用户界面、数据库、模块等，从而在需求和代码实现之间建立桥梁，指导开发人员去实现能满足用户需求的软件产品。系统设计可分为两个阶段：概要设计和详细设计。概要设计的要点是体系架构的设计，详细设计的重点是用户界面设计、数据库设计以及模块的设计。主要的输出文档包括：系统总体设计报告。主要的参与人员包括： 项目经理指定具备相关经验的开发人员进行软件系统架构的设计，这些开发人员

24、又称为体系架构设计人员； 在用户界面的设计中，常常需要美工和用户的参与； 项目经理指定开发人员进行数据库、模块的设计。 系统设计的主要任务包括： 设计准备，包括阅读前一阶段的文档等； 设计，不同的设计内容所采用的方法有所不同，例如对于用户界面的设计，一般采用“原型创作-原型评估-细化”的步骤或方法； 编写相关的设计文档； 组织设计评审。l 开发（代码实现）开发也称为代码实现，其主要的任务为编写整个系统的代码，并进行单元的测试。本过程的输入是个设计文档，输出是源代码、单元测试记录以及代码审查记录。其主要工作任务包括： 准备-确定代码规范等标准、准备软件开发环境等； 代码实现-代码的编写； 代码审

25、查-依据代码规范，进行代码的审查，包括开发人员的互查项目经理的同行评审； 单元测试-采用互测方式进行。l 测试测试包括集成测试、系统测试和用户验收测试。集成测试侧重于模块的集成，是子系统/模块一级的测试。系统测试是针对最终软件系统进行，是一次全面的测试，需要确保软件系统满足产品需求并遵循系统设计。所以系统测试控制的一个关键点是测试的覆盖率。验收测试一般由用户组织，属于用户对系统的符合性、正确性进行验证的测试。测试的主要任务包括： 制定测试计划-当产品需求和系统设计文档完成之后，测试小组就可以开始制定测试计划和测试用例了。测试计划的主要内容包括：测试完成准则、测试范围、测试方法、人员、测试环境与

26、辅助工具、进度； 设计测试用例-有测试人员完成其设计和编写工作，并需要通过评审； 测试实施-依据计划和测试用例进行测试，测试中发现的错误，要求及时记录，将错误及时通知开发人员并使测试人员可以跟踪错误直到错误问题解决关闭； 错误管理与改错-任何人发现的错误，将被记录，开发人员及时消除错误，在开发人员消除错误之后立即进行回归测试，以确保不会引入新的错误； 测试报告-对于系统测试盒验收测试，在测试完毕后需要进行总结并形成报告。 本投标人的产品测试独立于产品的开发，在产品单元测试完成之后，即交付专门的测试部门进行后续测试，独立开发的测试机制进一步保证了测试的有效性和完整性。l 版本控制 控制的目的是保

27、存产品的所有版本，避免发生版本的丢失混淆等现象。并且可以快速准确地查找到任何产品的任何版本。控制的范围是项目中的所有产品，从需求文档、设计文档、测试文档、用户手册到源代码。在人员参与度方面，将是所有的项目成员都必须遵照版本控制规程操作文档库。控制的要点包括： 在项目的策划阶段，编写配置管理计划。在计划中将指定人员作为配置管理员，负责整个项目的版本控制，变更控制等。计划中还需要标识配置项作为版本控制的基本对象； 配置服务器作为配置库服务器，集中存放项目的所有已完成产品； 使用配置管理工具实施管理控制； 针对产品的不同状态，实施不同的控制策略，例如基线状态的产品，其变更要求有严格的申请、评估、审批

28、实施、验证、提交过程；10.9.9软件实施安排为保证项目在规定的时间内顺利完成，软件项目管理工作对本系统的实施极其重要。本投标人将在软件项目管理总体上贯彻工程的思想，并在项目组织实施中抓住关键工序，采用一系列措施和办法。 l 软件管理总体框架l 软件管理的阶段本次项目基于GIS系统是一个包括软件和部分硬件相结合的系统集成类工作，从系统集成的角度，我们对该部分项目管理主要分为如下9个阶段： 工程的准备； 工程的确定； 工程设备采购、软件开发； 工程设备安装、单项调试和验收； 联合测试、试运行阶段； 项目验收； 培训； 运行的管理和维护； 售后服务与系统的安全保障。 各阶段逻辑顺序关系如下图所示

29、l 各个阶段的主要工作以下是各个阶段的工作时间内容具体说明。1）系统工程的准备阶段：该阶段主要工作是对系统工程进行系统分析和深化设计、准备系统接口技术要求文件。具体包括如下内容：按照相关标准规范，根据系统项目的实际情况确定系统需求，完成并提交相关文档；明确系统工程的信息流程和管理模式；确定系统相关的数据、界面接口协议，包括采用的操作系统、硬件接口、连接方式、通讯方式、网络协议、数据记录格式、应答方式、网络故障时的自救方法、进度安排、测试标准等；利用最精简的设备，搭建模拟环境，为系统检测和发布相关设备的初步验收和测试做好实验准备；从技术角度，对主要设备供应商的技术要求提出明确意见或建议；对系统

30、工程进行深化设计并提出详细的技术实施方案；制定行之有效的工程实施计划；与设备供应商等进行总进度计划协调。2）系统工程的确定阶段：该阶段主要是根据系统工程的总体安排，确定设备供应商等的工作范围、责任、相互关系等。从技术角度，确定设备供应商的工作内容；业主、系统集成商、设备供应商一起确定系统各子系统之间的接口标准、规范、实施方法以及相互责任。包括各自相关的工作内容、质量控制、变更管理、各方责任、工程进度安排、测试标准、联调开通等。3）系统工程的设备采购、软件开发阶段：该阶段本投标人、设备供应商等按照合同要求进行设备采购供应、软件开发项目实施等工作。所有主要设备都需要在货物到达后由本投标人进行测试，

31、符合标准和规范，才能送往现场安装，并提交相应的设备测试报告。通过确定阶段对系统软件总体需求的理解，进行软件实际开发阶段。4）系统设备安装、单项调试和验收、模拟联合测试阶段：该阶段有本投标人、设备供应商等按照有关要求进行设备的安装、单项调试和验收，模拟联合测试。设备安装工程中，本投标人将根据需要向业主提出工程实施阶段性验收。本投标人将按照规定的实施进度，确认个部分工程系统的进度，提交合格的各项验收测试报告给业主，对存在的问题，与业主技术协调处理。建立系统集成模拟联合测试环境，组织设备的模拟联合测试。设备供应商提供有关测试、验收的工作程序及方式给业主、本投标人，经批准后进行有关工作。设备在测试验收

32、时，本投标人和设备供应商提供所需的、标准的测试仪器、仪表。5）联合测试、试运行阶段：该阶段由本投标人负责，业主统一协调、进行功能集成、联合测试，通过后进入试运行阶段。本投标人将协调、组织相关设备供应商，负责建立功能完善的集成系统。本投标人将制定整个系统运行的方案和工作程序（包括调试运行周期），并成交业主。本投标人将提供试运行方案给业主，协调、组织有关方面，开始试运行工作。6）系统验收阶段：该阶段由业主和本投标人统一协调，组织进行验收。验收包括：预验、初验和最终验收。本投标人在系统试运行和联网运行验收通过后，将向业主提出正式验收申请。验收标准将依据有关国际标准、中国国家标准规范、系统设计和招标文

33、件的要求。验收内容至少包括以下各项：安装设备的数量、型号和规格；完整的竣工验收资料图纸；设备安装、调试的特殊工具；系统功能；系统质量。7）系统培训：本投标人将对业主指派的人员进行培训，培训内容包括理论将结合实际操作。培训开始之前本投标人将提出培训计划（包括：内容、技术资料、时间、地点、人数等），撰写培训教材，由业主确认后在实施培训。本投标人将负责使接受培训的人员达到能正确操作和维护的上岗资格。8）系统运行的管理和维护：从系统验收通过之日起，系统进入质保期，项目质保期为36个月。在此期间，本投标人将派驻专业工程师在项目现场，保障系统的正常运行并随时解决出现的问题。在质量保证期内，对任何因安装工艺

34、材料和产品质量而造成的设备或部件的损坏，本投标人将提供无常的更换和维修。在质量保证期内，本投标人将负责系统维护、确保系统维护及时、高效。如果在质保期内，国家、公安部或交通部门颁布了有关交通管理的接口标准，本投标人将无条件免费按照国标或部标，更换所提供给采购人的软件系统满足国标或部标的接入标准。9）售后服务：产品实行终身维护。本投标单位在潍坊具有指定专业维护机构，具备常住维修人员6名和相关维修设备和车辆（工程高车及售后服务车）。具有良好的售后服务、质量保证体系和相应的技术保障措施，提供全方位、有效而及时的售后服务和技术支持。本投标人接到保修通知后，10分钟实质性响应，2小时到达现场，一般故障排

35、除最长时间不超过5小时；特殊故障排除最长时间不超过12小时。一般故障指下端设备发生故障，特殊故障指系统软硬件疑难故障。当用户需求时（质保期后五年内），本投标人承诺无偿提供人员和技术支持。当系统软件版本升级时，本投标人将无偿对设备进行软件升级。本投标单位承诺免费提供后期新建应用平台的对接接口并提供免费对接服务。第3篇：软件开发项目管理实施方案.项目管理实施方案作为一个项目管理者,如何要成功的做好项目管理;首先必须先要明白的是在特定的领域中赋予这个角色所要实现的目标、承担的职责、以及项目管理者的具体工作内容是什么首先编码要有“编码规范”文档,Code Review要有“代码审核规范”文档:记录代码

36、实现应该遵循的标准。通过这两个文档来规范开发人员的代码实现,代码编写者必须要严格按照规范来进行;代码审核者根据这些标准来Code Review代码,同时在Code Review过程中不断完善该文档。在做好这些前期工作的前提下,分以下几个步骤来实施:1、检查开发者的代码实现是否遵循了编码规范。2、从代码的易维护性、可扩展性角度考察代码的质量,提出修改建议。3、代码编写者和代码审核者坐在一起,由代码编写者按照Use Case依次讲解自己负责的代码和相关逻辑,从Web层-到Manage层再到Dao层;4、代码审核者在此过程中可以随时提出自己的疑问,同时积极发现隐藏的bug;对这些bug记录在案。5、

37、代码讲解完毕后,代码审核者给自己安排几个小时再对代码审核一遍。代码需要一行一行静下心来看。同时代码又要全面的看,以确保代码整体上设计优良。6、代码审核者根据审核的结果编写“代码审核报告”,“审核报告”中记录发现的问题及修改建议,然后把“审核报告”发送给相关人员。7、代码编写者根据“代码审核报告”给出的修改意见,修改好代码,有不清楚的地方可积极向代码审核者提出。8、代码编写者bug fixed完毕之后给出反馈。9、代码审核者把Code Review中发现的有价值的问题更新到代码审核规范的文档中, 对于特别值得提醒的问题可群发email给所有技术人员。如果通过以上步骤,还因为是代码编写者的原因而出

38、现严重的缺陷问题,将通过绩效考核来加深代码编写者的印象,并在周报会议上做通报批评。3、需求变更管理需求变更管理也是项目管理中最重要的一个环节,对需求变更管理的有效性将直接影响项目的成功与否。对待需求变更的态度:1、需求变更是不可避免的。2、需求变更要必须被管理。3、积极发现引起变更的因素,促使变更尽可能早的出现,减低变更带来的风险。 需求变更管理的目标:1、相关的干系人必须清楚地了解发生的变更。2、变更处于有效的管理中。3、尽量降低变更带来的风险。通过制定需求变更的流程,确保项目中的需求变更有效地进行,实现上述的目标。需求变更流程:1、确定需求的基准线。将以User Case作为需求基准线,在

39、User Case确认之后的任何需求改变,都需要走需求变更流程,这一环节我们基本没有,期间有时候使的工作很混乱,也就是因为没有一个规范的变更流程而造成的;如果建立了这么一个流程规范和机制,需求变更没有走这个流程的将不被认可。2、项目管理者接收到需求变更的要求。需求变更的提出者可以是项目中的任何人包括产品经理、市场人员、开发人员、测试人员等。3、项目管理者评估该需求变更。针对接收到的需求变更的要求,召集相关人员讨论该需求变更的合理性、可行性,实施的代价以及对项目的影响。包括可能影响的项目范围,进度,费用,质量等计划。项目管理者作为项目的负责人,对项目的成功与否负有主要的责任。所以需求变更的决策者

40、应该由项目管理者承担。4、需求变更确认后由专人将需求变更记录下来,通知给项目中所有成员。其中以下人员对需求的变更是紧密相关的,他们必须知晓并认可此需求变更。包括(客户方,需求分析人员,测试人员,相关开发人员。需求变更记录格式如下: 序号变更提出时间变更描述变更类型(是 对原有需求 的修改还是 新增需求 原因变更提出 者开发人员对进度的 影响(工 作量1 25、确定变更的负责人。承担需求变更的具体工作,比如基线控制,对需求变更的记录,并通知相关人员。6、相关人员接收到确认的需求变更后,做以下事情。需求分析人员修改需求说明书和User Case的相关内容。测试人员修改测试用例的相关内容。开发人员修

41、改代码中的相关部分。7、按照变更后的计划实施项目,并进行检查,跟踪,对变更后的实施反馈和可能出现的问题及时沟通和处理。8、需求冻结。项目越到后期,需求变更对项目的影响就越大,所以在一定时候要进入需求冻结阶段,不再接收新需求或需求的变更。4、风险管理风险管理是项目管理者最重要的工作之一。风险管理是一个持续的过程,贯穿于整个项目过程中,风险管理包括风险识别、风险评估、风险解决以及风险管理策略。在项目的实施过程中需要不断地识别和应对风险,并加以有效的控制,风险管理的好与坏直接影响项目的实施效果,从某种意义上讲,项目实施对于项目管理者就是识别、分析、应对、控制风险的过程,使项目的约束性目标和质量目标朝

42、有利的方向发展。项目不同于日常任务,它有明确的起止时间和目标,要在明确的范围、时间和成本约束下,达到相应的质量标准,并取得用户的满意。影响项目成败的因素涉及方方面面,并且风险伴随着项目的始终,是客观存在的,作为一个项目管理者,应该具备良好的风险控制意识,善于识别风险并分析风险的影响,从中发现影响目标的风险点,并施加影响或采取应对措施,把风险的负面影响降到最低,并且风险控制应该贯穿项目始终。风险引起的负面后果集中体现在进度延后、成本超支、质量不达标等方面,导致这些问题的因素主要包括目标以及需求不明确、范围蔓延以及需求变更、代码质量或返工风险、人员技能和资源的不足、缺乏良好的团队协作等。下面将详细

43、描述一下这些问题以及出现这些问题时的应对方案:1、目标以及需求不明确为了市场竞争或内部管理决策的需要,业务部门提出的需求往往要求的时间比较紧迫,需求的提出大多停留在几张纸或口头的传达上,没有形成正式的业务需求文档,在没有明确的需求范围的情况下,有时为了迎合业务部门的口味匆匆开工,过程中用户不断地提出新的想法,技术人员开始疲于奔命和应付,很难保证项目的进度和质量,也难以取得业务部门的认可。所以,在项目的前期一定要采取相应的手段或措施,与业务部门共同明确项目目标、需求范围,充分考虑现有的时间和资源约束,将需求排定优先级, 对于关键的需求优先实现， 其他辅助性的根据过程中的具体情况进行滚动式计划，

44、并取 得业务部门的书面确认。在此过程中要注重挖掘用户的隐性需求，可以通过引导、系统 原型等手段让用户在前期充分暴露自己的想法和需求。2、范围蔓延以及需求变更 在有了明确的目标和需求范围的情况下， 需求的变更还是不可避免的， 业务部门在 看到具体系统的真实雏形之后，源源不断地要求、新想法随之产生，如果不对此加以控 制， 新的需求的加入通常会影响已实现的需求， 并且对项目进度和成本产生很大的影响。 项目管理者针对这种情况一定要采取严格的变更控制流程， 不能碍于面子， 否则最终的 结果往往是出力不讨好。针对用户提出的新需求，按照正式流程提出变更申请，组织相 关团队成员进行分析及评估， 作为是否实施的

45、依据， 变更控制负责人根据分析结果判断 是否批准，如果批准，那项目组可以安排实施，否则，正式拒绝用户的请求，当然实际 情况下可以采取一些软措施缓解矛盾。 需求变更风险：需求已经打上了基线，但此后仍然有变更发生，对项目造成影响。 如何减少此类风险的发生？ 前期的需求讨论要详细、充分。需求文档中需求的范围要明确、功能描述要清楚。 找出项目中需求的决策者(通常会是产品经理、相关职能主管、客户，所有的需求要经 过他们的认可。客户在项目过程中的全程参与有助于降低此类风险。需求讨论、需求确 认、User Case 确认、测试阶段的客户验收等环节，都要要求客户参与。在发生需求变 更时， 严格按照需求变更流程执行。 在分析设计阶段的中的确认和评审也是降低此类风 险的重要手段。3、代码质