软件项目实施方案-通用技术方案模板

软件项目实施技术方案通用模板

目录

第一章技术方案.......................................................................... 错误!未定义书签。

1.1项目背景......................................................................... 错误!未定义书签。

1.2设计思路......................................................................... 错误!未定义书签。

1.3技术路线......................................................................... 错误!未定义书签。

1.4基础平台设计................................................................. 错误!未定义书签。

1.4.1框架设计.............................................................. 错误!未定义书签。

1.4.2业务模块设计...................................................... 错误!未定义书签。

1.4.3业务模块分配管理.............................................. 错误!未定义书签。

1.4.4统一用户与权限管理.......................................... 错误!未定义书签。

1.4.5统一应用层安全管理.......................................... 错误!未定义书签。

1.4.6大数据处理平台.................................................. 错误!未定义书签。

1.4.7信息发布平台...................................................... 错误!未定义书签。

1.4.8门户平台.............................................................. 错误!未定义书签。

1.4.9数据共享平台...................................................... 错误!未定义书签。

1.5非功能性设计................................................................. 错误!未定义书签。第二章项目实施. (4)

2.1项目实施策略 (4)

2.1.1实施范围及内容 (4)

2.1.2项目实施方法 (4)

2.1.3项目管理办法 (4)

2.1.4系统开发方法 (5)

2.2项目组织结构 (6)

2.2.1项目管理组织结构图 (6)

2.2.2项目岗位职责 (7)

2.2.3项目参与人员 (8)

2.2.4报告和决策机制 (8)

2.3项目计划管理和监控 (9)

2.3.1计划排定 (9)

2.3.2任务分解（WBS） (9)

2.3.3检查点 (9)

2.3.4例会制度 (10)

2.4项目进度安排及计划 (11)

2.5项目实施团队情况 (11)

2.6质量保证措施 (11)

2.6.1软件质量保证概述 (11)

2.6.2软件保证质量体系 (15)

2.7风险回避 (19)

2.7.1管理策略 (19)

2.7.2风险甄别 (19)

2.8测试方案 (20)

2.8.1质量保障 (20)

2.8.2 QA模式 (20)

2.8.3审核制度 (20)

2.8.4测试管理 (20)

2.8.5测试方法 (20)

2.8.6缺陷跟踪 (21)

第三章项目培训 (22)

3.1系统管理员培训 (22)

3.2普通使用人员培训 (22)

3.3计算机普及培训（建议） (23)

3.4培训表格设计 (24)

3.5培训师资 (26)

3.6培训的考核 (26)

第四章项目验收 (27)

4.1需求及设计用户检验确认 (27)

4.2软件安装调试 (27)

4.3系统初验，投入试运行 (27)

4.4文档移交 (27)

4.5对招标书验收要求的承诺 (28)

第五章售后服务 (29)

5.1售后服务承诺 (29)

5.2售后服务体系 (29)

5.2.1服务流程 (31)

5.2.2服务质量控制 (32)

5.2.3服务内容、方式、响应时间 (35)

5.2.4应急方案处理 (43)

第一章项目实施

1.1项目实施策略

实施范围及内容

保持项目实施范围的前后一贯性决定了项目的成败，如果出现需要改变原定实施范围的需求，都应以正式文档方式提出。项目小组成员必须谨慎考虑项目范围的改变将对整个项目进程可能产生的影响，必须在批准后才能进行。在实施过程中必须加以跟踪。

项目实施方法

渐增交付

在实施过程中渐增交付的方法把最终的交付分为较细小的子交付。于是管理层能够在较短的时间内看到一定的成果。渐增交付可以同时保证项目的实施正确和衡量每阶段的成效。

滚动开发

电子政务建设是“活”的项目，它需要持续优化的过程。因此在系统的实施过程中远程目标亦会相应改变，不断改进不断完善。项目的规划需要一步一步的向着自动化的远程目标前进并不时更新。滚动开发把每一阶段的成果加上用户的反馈都作为下一阶段的基础逐渐走向目标。更重要的是，由于滚动开发把远程目标划分成多个阶段，开发能较灵活地配合远程目标不停的改变。

项目管理办法

凭借以往大型项目的实施经验，科学的项目管理方法，充分体现了项目生命周期每个阶段的各项管理要求。

具体项目活动内容将以下列视图表示：

系统开发方法

系统开发按照软件开发生命周期进行，采用“瀑布式”和“迭代”相结合的方法。对每个生命周期的阶段，设定里程碑，检查相应的阶段性成果。

系统开发采用客户要求的相关技术标准，体现系统的跨平台特性，和可移植性。

1.2项目组织结构

项目管理组织结构图

整合软件开发商、软件产品供应商与客户三方的力量，技术工程设计人员和客户相关人员的共同参与，是确保项目取得成功的必要条件。项目开发和实施过程同时也是知识转移的过程，通过完整的项目实施过程及其管理，将帮助客户培养一支内部技术维护力量，实现对软件应用系统的持续完善与增强。

在系统的建设项目中，既要对项目各个阶段进行管理，又需要对总体项目的进度进行控制，对数据交换、新旧应用系统接口等相关需求进行协调管理。

一个良好的项目管理组织可以保证项目有条不紊地按照预定计划进行，保证阶段目标的按时实现。尽量减少和协调项目内部以及项目之间的冲突，充分发挥每个项目成员的工作效率。

综上所述，该项目组的人员组成，不仅应单纯地以技术工程人员为主，同时应该请客户方的业务人员参加，从而组成联合项目组。其组织结构示意图如下。

项目管理委员会我公司项目控制委员会

系统环境小组总管理员

我公司项目经理

我公司项目开发组我公司项目实施组

项目经理

我公司质量保障我公司配置管理

子管理员我公司需求小组

我公司编码小组

系统安装调试小组

系统制作培训小组

我公司

用户

项目岗位职责角色职责

项目控制委员会负责监督、跟踪整个项目的进展；每月定期或事件驱动地召开项目进展通报和问题协调会议，监控项目进展情况，对进展过程中出现的重要问题或紧急情况有最终决策权。

项目经理制定集成实施计划和时间表；

控制和监督集成实施进程；

协调客户、供货商，参加协调会议；组织实施工作；

向主管经理报告；

协调其他部门；

业务需求分析人负责整个项目调研、需求分析工作，配合项目经理完成需求阶段工作安排，审核需求变更。

软件系统分析及设计人负责技术方案的制定、系统设计、实现阶段的控制，检查各模块、各阶段的进度；检查开发人员交付物的及时性、合法性

编码人员负责系统开发部分编码工作

项目实施经

理

负责整个项目的现场实施安装、网站页面制作和嵌套、培训美工负责网站模版及网站页面调研、创意、制作

项目实施人

员

负责网站安装、页面嵌套

项目培训人员培训用户进行系统安装、备份、网站站点创建、模版制作、信息发布审核

质量控制

按QA计划开展QA活动；向项目经理汇报QA活动的结果；当QA与项目

经理意见不一致时，QA可以独立地向部门经理直至公司总经理汇报。配置管理员

负责制定、执行和维护项目的配置管理计划；创建和维护多个层次的配

置管理库；执行配置变更之后的配置标识和基线的重新划分；进行SCM

状态统计；向分项目经理、项目组有关成员提交SCM状态统计报告；参与配置审计；负责软件配置管理库的内容的安全性和保密性。

测试负责人负责软件的测试工作（包括测试方案的制定、测试用例的编写、测试结果的确认），并负责向分项目经理提供测试反馈，必要时将信息直接反馈给高层经理。

项目参与人员

见11.5节项目实施团队情况。

报告和决策机制

在项目的实施过程中，难免会遇到一些不可预知的困难或问题，为尽快解决将会遇到的问题，本着合作的精神，杜绝扯皮和拖延现象的发生，有必要事先规定好项目组织结构和相应的报告和决策机制。

我们将采用“自下而上”的报告流程，就一般问题，项目小组成员应首先在小组内部讨论解决，否则应该按照项目组织结构图所列逐级向其分管的主管报告，向其项目经理报告乃至总项目负责人汇报。不应将问题拖延或隐瞒，因为问题的及早提出和解决，可以减少项目成功的风险。而对于涉及项目实施过程中必须得到双方认知的重大问题，由双方的最高项目管理机构协商解决。

1.3项目计划管理和监控

计划排定

计划管理是软件过程的一个重要组成部分，根据项目进度和工作范围的要求，制定切实可行的工作计划，规定每个成员的任务，检查任务完成的情况和质量，保证项目顺利实施的重要保证。

项目经理必须为项目的整体实施制定出工作计划，确定各项软件开发的活动和承诺，明确项目的相关组织和人员，将具体任务落实到组和人，从组织管理上确保项目的成功，项目经理依此跟踪检查计划的执行情况。

工作计划管理应包括以下几点：

1.编制工作计划（PMP、SQA和SCM等），有些计划必须经双方批准，例如PMP；

2.作出工作小结，说明未完成原因及改进建议；

3.工作量统计，质量检查，并由客户签字；

4.项目进展状况。

任务分解（WBS）

一个合理项目计划的制定，必须建筑在对工作范围和具体任务的充分理解的基础之上。WBS是一种被广泛采用的方法，它对任务进行拆分，使其成为若干个可执行完成的工作单元，从而对每项单元任务进行工作量的确切估算，保障项目计划的可行性。

WBS的详细结构，必须等整个系统的设计架构完全确立之后，才能进行任务分解。

检查点

在项目计划的执行过程中，难免会出现偏差，而合适的检查点设定，可以即时发现所出现的问题，快速找出合理的解决方法，降低风险。下图为过程、计划和检查点的示意图：

过程

检查点过程检查点过程

计划

计划修改

修改纠正

纠正

例会制度

项目实施集成小组必须定期召开项目工作会议，会议周期以周为单元。一般定于每周一召开项目例会，以检查项目进展状况，总结前一周的工作情况，安排下一周的工作分配。每次项目例会必须记录会议纪要，记载所讨论的问题和针对这些问题所作的决策与项目相关的记录文档，应该呈交zz 和用户方项目管理机构，以备查询。zz 的项目经理还应该定期召集zz 项目控制委员会成员会议，通报项目的整体进展状态，讨论必须交由领导处理的议项。

凡遇特别紧急事务时，可以经协商后临时召开会议，以使项目的顺利进行。

1.4项目进度安排及计划

1.5项目实施团队情况

1.6质量保证措施

软件质量保证概述

软件的质量是长期以来困扰软件业发展的一个问题。生产出高质量的软件产品是软件工程等学科研究的主要目标。

在计算机发展的早期，软件质量保证（SQA）曾经只由程序员承担。在今天，这一定义的含义是在一个组织中有多个机构负有保证软件质量的责任，包括软件工程师、项目管理者、客户、销售人员和SQA小组的成员。软件质量保证是一种应用于整个软件过程的保护性活动。它的内容很多，包括：

1、一种质量管理方法；

2、有效的软件工程技术（方法和工具）；

3、在整个软件过程中采用的正式技术评审；

4、一种多层次的测试策略；

5、对软件文档及其修改的控制；

6、保证软件遵守软件开发标准的规程（在适用时）；

7、以及度量和报告机制。

为了从事软件质量保证活动，需要在软件企业建立起质量保证体系，并往往需要第三方的认证。目前的ISO9000族的标准和美国卡耐基·梅隆大学软件工程研究所的过程能力成熟度模型等为软件企业建立质量体系和进行软件质量保证工作提供了指导。

1.6.1.1软件质量

在进行软件质量保证时，首先需要对软件质量有正确的完整的理解，并且通

过定性或定量的方法对软件质量进行度量。

McCall等人首先提出了一个对软件质量进行系统评估的框架。该模型分为三层。第一层是从用户的角度衡量软件质量，第二层从开发者的角度看待软件质量。第三层是更细化的、可定量衡量的指标。下图显示了模型的头两层。

?正确性：一个程序满足它的需求规格和实现用户任务目标的程度。

?可靠性：一个程序期望以所需的精确度完成它的预期功能的程度。

?功效：一个程序完成其功能所需的计算资源和代码的数量。

?完整性：对未授权人员访问软件或数据的可控制程度。

?可用性：学习、操作、准备输入和解释程序输出所需的工作量。

?可维护性：定位和修复程序中一个错误所需的工作量。

?灵活性：修改一个运作的程序所需的工作量。

?可测试性：测试一个程序以确保它完成所期望的功能所需的工作量。

?可移植性：把一个程序从一个硬件和/或软件系统环境移植到另一个环境所需的工作量。

?可复用性：一个程序[或一个程序的一部分]可以在另外一个应用程序中复用的程度。

?互操作性：连接一个系统和另一个系统所需的工作量。

1.6.1.2ISO9000标准

ISO9000族标准的基本思想就在于一个组织要确定其质量目标，并按照其确定的质量目标建立并有效实施质量体系，确保影响产品质量的技术、管理和人的因素处于受控状态，所有的控制应针对减少和消除不合格，尤其是预防不合格，

并建立和完善持续的质量改进机制。它由一系列规则和协议组成，由专门的组织机构以一系列的管理制度和工具来保证贯彻实施。

在组织结构上，需要由专门的部门负责质量保证工作，并在管理层里指定一名管理者代表。作为质量体系的反映，需要形成质量体系文件。质量体系文件包括质量手册、程序文件和作业指导书三个层次。

ISO9000族标准的科学依据为：（1）质量形成于生产全过程；（2）必须使影响产品质量的全部因素在生产全过程中始终处于受控状态；（3）应使企业具有持续提供符合要求产品的能力；（4）质量管理必须坚持质量改进；（5）质量管理体现PDCA循环（即计划、实施、检查、措施）；（6）质量管理的核心是预防而不是补救。

ISO9000标准族中的ISO9001标准适用于软件企业。它在20个方面规定了供方在全部生产活动中的质量要求，也叫做20个质量体系要素。

针对软件行业的特殊情况，ISO9000-3标准提供了一些指南。

1.6.1.3软件过程能力成熟度模型

软件产品的质量取决于软件开发过程，具有良好软件过程的软件机构能够开发出高质量的软件产品。1987年在美国国防部的支持下，卡耐基·梅隆大学推出了软件过程评估项目的研究成果——软件过程能力成熟度模型。该模型在软件界引起了广泛的关注，以至在其基础上形成了国际标准（ISO/IEC 15504）。

CMMI提供了一个框架，将软件过程改进的进化步骤组织成5个成熟度等级，为过程不断改进奠定了循序渐进的基础。每一个成熟度等级为持续改进过程提供一个台阶。每一等级包含一组过程目标，通过实施相应的一组关键过程域达到这一组过程目标，当目标满足时，能使软件过程的一个重要成分稳定。

CMMI的级别示意图如下：

由于CMMI是专门针对软件企业的，因此其针对性要更好，在实施的时候不需要进行术语上的转换。另外，其逐步提高的方式使得其可操作性更强。

软件保证质量体系

1.6.

2.1目标

使应用软件系统具有可靠的质量，符合最终用户的业务需求，具有很好的可靠性、效率、安全性和可扩展性；

使应用软件系统的开发能够适应不断变化的业务需求；

尽量减少系统开发的投入；

尽量缩短系统开发时间。

1.6.

2.2质量保证体系的结构

基于上面对软件质量保证的基本认识，软件开发开发的质量，需要针对项目本身建立一个完善的质量体系。我们认为，该质量体系包括组织结构、质量体系文件和资源三个主要方面。

组织

机构

质量体系文件

资源系统开发

质量保证体系

一个设计良好的组织结构能为应用软件的质量提供组织和人员上的保证。各组织的职责清晰；组织之间的接口清晰，信息沟通和反馈流畅。

质量体系文件是质量体系文档化的反映，使应用开发的各方对质量保证的各个过程有一致的依据。指导与质量有关的各项工作。

为了保证应用开发的质量，必须保证提供足够的资源，包括人力资源、设备、环境、资金等，其中人力资源方面的保证更加重要。

1.6.

2.3组织机构和角色

为了保证应用开发的质量，需要有一定的组织结构保证。公司典型的项目组织结构如下：

在上述结构中，一个大的项目可能由多个项目组组成。质量保证和配置管理组单独设置。

?项目经理

作为项目负责人，对应用软件开发的进度、资源等进行控制；协调各个开发组；是与客户进行合作的组织上的接口，负责进行双方的沟通。

?硬件集成项目组

主要由公司的硬件工程师组成，负责硬件环境分析、设计、安装、培训等一系列开发过程。

?应用开发项目组

主要由公司的软件工程师组成，负责需求分析、设计、编码、测试、安装、培训等一系列开发过程。

开发组由公司的软件工程师组成，负责从需求分析、设计、编码、测试、安装、培训等一系列开发过程。按照公司质量管理手册的规定，开发组成员将由以下角色组成，每个角色在开发过程中具有不同的职责：

根据开发组人员的实际构成，某些角色可以由同一个人承担。开发组人员职责清晰，分工合作，共同完成项目开发任务。

?质量保证组

在本应用系统项目中。除了各项目组内的质量保证工作以外，还需要在整个项目级上进行质量保证。它的职责包括：

在项目经理的授权下，制订整个项目的质量保证计划；

在整个项目的执行过程中，监督质量保证工作的执行情况，协调组织间的质量保证工作；

在项目经理的授权下，制订整个项目的集成测试计划；

组织进行集成测试活动；

组织技术评审工作；

配置管理组

在整个项目级别上从事配置管理工作，包括版本控制、变更控制。

1.6.

2.4质量体系文件

本应用系统的开发需要一套系统、完整的质量体系文件来从事质量保证工作。公司在寻求ISO 9001质量体系认证的过程中，已经建立起了一整套的质量体系文件。

?质量手册

是证实或描述文件化的质量体系的一般形式。手册的内容包括：

公司的质量方针和质量目标；

影响质量的管理、执行、验证或评审工作的人员职责、权限和相互关系；

质量体系程序和说明；

关于手册评审、修改和控制的规定。

?程序文件

程序是进行某项活动所规定的途径。程序可以形成文件，也可以不形成文件，凡是形成文件的程序，称之为“书面程序”或“文件化程序”。其内容通常包括：该项活动的目的和范围；做什么和谁来做；做什么和谁来做，何时、何地、如何做，应使用什么材料、设备和文件，如何对活动进行控制和记录。

为了给软件生命周期中的各项活动提供一个统一的可裁剪的框架，公司编制了一个软件过程手册。

?规范和作业指导书

规范和作业指导书是质量体系文件中的第三层文件，对应用开发过程中的具体环节提供比较详细的指导。典型的例子包括：软件开发计划编写规范、质量保证计划编写规范、配置管理计划编写规范、需求规格说明书编写规范等等。

1.6.

2.5资源保证

?人力资源保证

对于应用软件开发而言，人力资源是最重要的资源。为了保证项目的质量，公司将为各方面的合格优秀的人才，包括有经验的项目经理、专业的质量保证人员、经验丰富的项目组负责人和合格的程序员。

公司建立并正在逐步完善符合高科技企业情况的人力资源政策，包括人力资源规划、招聘、培训、绩效考核等，能为应用开发项目提供长期的、保持高绩效水平的能干、杰出的员工队伍。

公司将通过科学的绩效考核、职业发展规划和满意的劳资关系，保证技术队伍的长期稳定，保证应用项目在人员上的连续性。

?环境设备等资源的保证

公司将通过自己的力量，为应用项目提供环境、设备、资金和其他方面提供可靠、及时的保证。如果需要，公司可以调拨自己的小型机、开发平台、中间件

平台、CASE工具、数据库平台等为软件开发项目服务，给项目创造最佳的环境。

公司将与客户密切合作，使来自客户的各方面资源能够得到最有效的利用。

1.7风险回避

管理策略

风险管理的策略不外乎“Reactive”和“Proactive”，我们采用两者相结合的方法进行风险管理。对项目开发过程中的每个产出物进行技术审核，实行例会制度，即时掌握项目进展过程中可能出现的风险。同时还必须对那些显而易见的问题，预先做好应对计划，使项目风险降至最低。以表格的形式记录所有风险，及其解决办法，按其优先等级即时处理每个风险问题。

风险甄别

针对电子政务项目，以下是可能会出现的风险。

可能面临的风险名称建议解决办法

项目领导是否经常变更准备完整的文档资料

做好各项目的计划时间表以避免冲突

zz是否会同时存在其他开发项目，

造成冲突

项目资源（人力和物资）是否充足做好人力资源和其它资源需求的时间计划

表，同时得到上层主管的确保

加强培训

实施人员的经验和知识结构是否符

合要求

项目的实施范围是否经常变更尽量避免项目的实施范围变更, 如有变更,

可作为另外一个项目

实施周期是否实际客户和zz双方进行协商，加强沟通，以保证

开发周期的可操作性

开发流程是否有所变更依照zz的规范，适当调整

项目是否可以按时提交希望得到客户的支持，各部门充分协调

任务分配是否合理依职能分工，明确职责，成立跨部门项目控

制委员会

1.8测试方案

质量保障

QA模式

软件系统的质量保障是通过一系列的QA活动而实现的，“V-Model”是一个较为适用的模式，它按照软件工程的生命周期，将整个开发过程划分为几个阶段，在每个阶段，配以必要的QA活动，诸如，审核（例如，IBM Fagan Inspection）和测试，以达到质量保障的目的。

审核制度

项目提交的各种重要文档（诸如计划等）都应经过双方的项目经理（或其授权人）审核批复。而与项目实施相关的技术文档（包括系统分析报告、系统概要设计、系统详细设计、源代码和用户文档资料），必须经由zz进行内部技术评审，经批准后方可执行。为了提高工作效率，降低成本，建议审核批复时间应在提交后的一定周期内。

对于阶段性成果的审核应由客户方项目经理签字，确保提交的阶段性成果已审核，满足了项目实施方案的要求，达到客户方能接收的标准。

测试管理

所有交付的软件产品，必须经过严密的测试。测试内容包括单元测试、模块测试、系统测试和用户接受测试。每项测试内容，在软件系统的编码开始之前，必须制定周全的相应测试计划，确定测试内容、测试方法、测试范围和测试人员。对于每项测试，应该提交测试报告和缺陷统计报告，由QA工程师负责监控。

测试方法

软件系统的测试分为单元测试、模块测试、系统整合测试、系统集成测试、性能测试，大数据量测试等。单元测试和模块测试由软件开发工程师在开发的过程中运用“白盒测试”的方法进行，对其产出物进行严密的逻辑和功能测试，使