项目实施方法论

• 2019年09月02日
• 技术开发,编程,技术框架,技术发展
• 车联网与无人驾驶

安菲软件项目实施方法论，是经过多年大型软件项目实施经验积累之上总结的一套软件项目实施方法论，包括实施阶段划分，项目实施各方职责，项目实施里程碑，项目实施组织措施，测试方案，验收方案，维护及质保期服务。

1.1 实施方案与计划

1.1.1 实施阶段划分

根据安菲软件多年信息化项目的经验，实施过程分为如下几个阶段进行。

1.1.1.1 阶段一：项目启动

主要任务是建立项目组，制订并落实工作计划。主要工作内容包括：

讨论策划项目计划、组织模式、人力资源计划；

组建项目领导组，项目管理组，项目业务技术组；

共同确定项目的管理制度。

交付文档：《项目启动计划》、《组织结构图》、《项目实施/进度计划》．

1.1.1.2 阶段二：需求调研

主要工作内容包括：

根据丰富的业务和应用积累准备需求调研模型，采用模型调研法进行需求调研工作。

在宁波客户方智慧园相关业务单位（物业管理部门、入驻企业、员工、业主等），了解客户当前和未来的业务需求。

分析决定在客户当前的业务行为和流程与那些反映在应用软件系统中的功能之间存在着哪些差异。

基于这个分析的结果，制定出需要剪裁或客户化的部分以支持客户的业务行为，过程和环境。

了解相关系统，确认其与本应用系统应用整合的要求。

明确和细化业务和系统接口需求，并编制相应的文档。

生产业务相关的标准规范文档等，后期不断完善。

双方评审需求。需求分析奠定了软件工程和项目管理的基础。

交付文档：《调查分析报告》、《业务需求说明书》、《梳理的业务流程》

1.1.1.3 阶段三：系统分析和集成方案设计

工作包括：

确定业务系统总体规划；

确定网络架构：

确定业务数据模型；

编写需求规格说明书并通过评审

交付文档：《业务系统分析报告》、《需求规格说明书》

1.1.1.4 阶段四：系统设计

在系统集成设计方案评审后，进行系统详细设计。

工作包括：

总体架构设计；

软件需求功能及配置；

提供安全保障方案；

交付文档：《软件概要设计说明书》

1.1.1.5 阶段五：软件详细设计

进行系统平台配置；

对应用功能数据进行分析；

建立数据映射定义；

明确业务数据转换规则；

系统报表设计；

系统查询设计；

接口数据模型定义；

系统详细设计评审。

交付文档：《详细设计说明书》、《系统数据库设计说明书》

1.1.1.6 阶段六：软件开发与测试

系统的开发与测试的工作包括：

根据实施原则安排模块开发测试顺序，保证按照实施要求提交相关模块产品进行现场部署；

根据详细设计，进行功能开发；

编写用户系统操作手册；

根据提交的系统进行测试计划的编制、测试计划的实施；

接口数据采集联调；

根据测试结果进行系统的修改。

交付文档：《程序维护手册》、《用户操作手册》、《技术手册》、《系统维护手册》、《测试计划及测试方案》、《测试报告》等

1.1.1.7 阶段七：测试、验收

测试的工作包括：

产品测试

现场安装、配置应用软件；

系统整体集成；

系统的功能验证、性能测试；

交付文档：《测试计划及测试方案》、《数据库/中间件系统部署安装方案》、《其他系统软件安装测试报告》、《系统维护手册》、《系统安装手册》、《系统参数配置说明》、《系统崩溃及恢复步骤文档》、《测试报告》等

功能验收：

现场安装调试完成，同时数据转换补录工作完成后，安排进行功能验收。

交付文档：《系统功能验收清单》、《系统功能验收报告》、《系统操作手册》、《技术服务和技术培训资料》、《系统软件功能验收测试报告》

1.1.1.8 阶段八：试运行、试运行验收

试运行：

系统试运行的时间为一个月。主要工作如下：

系统管理员操作培训；

系统应用操作培训；

系统管理员技术培训；

现场培训与指导；

试运行系统客户化调整；

系统功能完善、数据模型完善。

交付文档：《系统试运行报告》、《系统数据情况分析报告》

试运行验收：

系统经过为期1个月的正常试运行之后，进行试运行验收。安菲软件提交验收申请，并进行验收。在此阶段安菲软件完成最终应用软件系统全部功能，实现对本部业务的全面管理。

缺陷责任期：

。试运行结束后，系统进入缺陷责任期阶段，系统的缺陷责任期为一年，设备的缺陷责任期为设备产商的缺省缺陷责任期。

技术支持中心继续服务于项目，进行日常的程序维护和系统维护。

重庆本地技术支持中心继续服务于项目，进行日常的程序维护和系统维护。

服务响应为5×8小时，重大故障，1小时内响应， 4小时内排除。

交付文档：《技术服务资料》、《日常维护记录》

 1.1.2  项目实施各方职责

1.1.2.1 安菲软件项目组织职责

1.1.2.2 客户方项目组织建议

 1.1.3  项目实施里程碑

 1.2  项目实施组织措施

 1.2.1 人员组织措施

有效的组织机构是项目成功的有力保证。由于项目大小、范围等的不同，项目的组织结构亦会有所差异，在项目开始之前对于组织机构及其责任分工做出规划是非常必要的。

同时，安菲软件向客户方保证项目人员组织的稳定性，在本项目结束前，参加本项目的人员变动必须取得客户方同意，并立即安排拟订候补人员予以补充；并且客户方有对安菲软件所提供的实施人员进行面试的权力。

项目实施组织机构包括：项目领导组，项目管理组，项目业务技术组和实施组。

1.2.1.1 项目组组织结构

1.2.1.1.1  领导小组

职责：负责协调全局，调配资源，领导全局工作。即“横向协调、纵向领导、有效配置”。

协调全局——协调客户方项目建设内外的关系，掌控全局。

调配资源——客户方项目建设，需要在资金、设备、人员等全局合理配置

领导全局——客户方项目建设，要全体动员，统一思想、步骤一致。

组成：客户方相关领导、安菲软件相关领导。

1.2.1.1.2    项目管理中心

职责：规划、组织、管理、协调项目在客户方范围内的建设实施。

规划——规划建设范围、投资规模、实施计划

组织——组织技术专题研讨、业务规范研讨、工作协调例会、集中培训考核

管理——监督项目整体进度、考核工作质量

协调——协调相关业务模块的建设工作，客户方统一管理本部各部门及内部各个专业模块的建设方案，定义统一业务标准或建设原则。

组成：客户方项目管理团队，安菲软件项目管理团队。

1.2.1.1.3    技术支持与规范管理中心

职责：规范设计、定义数据结构、开发和测试、平台技术研发

规范标准——制定编码规范、业务规范、岗位规范、管理模式、考核机制、系统环境、项目过程规范，有责任完善和优化规范，对规范有最终解释权。

统一变更——搜集、整理、规范业务流程，统一管理业务需求变更，统一研究、明确答复需求申请。

规范设计——在领导组直接领导下，按客户方统一规范进行总体设计和详细设计，指导开发和测试。

定义数据结构——定义数据字典，属性信息，提供可配置参数项。

开发和测试——严格按设计进行生产系统的开发、测试、发布和维护。

平台技术研发——规范开发过程、定义规范开发结构、IOS、Android、J2EE及三层架构技术、工作流、数据库管理、设计优化。

组成：客户方业务管理团队、客户方技术管理团队、安菲软件系统分析团队、安菲软件系统软件开发团队、安菲软件系统测试团队。

1.2.1.1.4    项目实施组

职责：负责项目信息调查数据准备、接受培训和内部培训、需求差异报告和变更申请、协调实施、设计和开发、实施试运行和实施维护项目管理。

信息调查和数据准备——组织调查、整理、订正数据信息；组织在系统中录入组织结构、基础数据等。

接受培训和内部培训——接受客户方集中的应用系统培训和系统维护人员培训，组织生产部门全员的应用系统培训。

需求差异报告和变更申请——整理与客户方统一规范不符的业务差异、岗位差异、接口原则和标准差异、项目过程差异，项目提前和延期申请。

实施项目管理——进行系统实施，保证日常工作正常、有序、受控。

协调实施、设计和开发——根据客户方统一规范，协调现场专业实施小组、后台开发和设计小组，并监督实施、设计和开发在统一规范内工作。

1.2.1.2 项目工作组设置建议

项目实施成功的关键在于客户方项目组和安菲软件项目组的紧密协作和配合。在实施过程中，项目工作组将承担以下任务：

用户需求说明讨论；

参加培训，并掌握系统使用方法；

参与系统实施过程，掌握有关的方法和技术；

学习并掌握系统管理、定制和二次开发技术；

员工培训；

系统测试；

系统验收；

制定系统应用的管理制度；

制定系统可持续发展计划；

实施后系统技术支持。

作为管理系统和知识系统，在项目实施过程中要求客户项目组成员能接受并掌握有关技能，从而在项目实施后能在企业内推广和支持项目。

根据项目管理与实施经验，建议由安菲软件项目组成员和关键客户人员共同组成项目工作组。其中，客户项目组人员应包括以下角色：

• 主管领导

• 客户项目经理

• 关键用户

• 系统管理员

• 开发人员

• 数据收集和整理人员

1.2.1.3 安菲软件项目组机构设置

我们将针对客户方项目建立专业、专职的项目小组。

保证工程人员组织的稳定性，在项目投入试运行前，不抽调项目组成员。在本项目工程结束前，参加本项目的人员变动将取得贵公司同意，并立即安排拟订候补人员予以补充。

• 项目领导组：由事业部总经理直接负责项目的总体协调和安排。

• 项目管理小组：项目总体协调、监控、管理。

• 系统实施小组：由有丰富实施经验的工程师组成，负责系统的现场安装调试、数据的录入与转换、客户培训，解决现场遇到的问题，保证系统正常稳定地运行。

• 系统分析与设计小组：由有丰富经验的设计、开发人员组成，负责项目的需求调研、分析与设计，在开发与实施过程中对软件开发和实施人员提供技术和业务指导。

• 系统开发小组：由有经验的设计、开发人员组成，负责程序代码和设计思想的实现、系统的修改与维护，保持系统版本的一致性。

• 系统测试小组：负责对开发成果进行跟踪测试、阶段测试和最终测试，发现系统存在的问题，保证系统的稳定性、可靠性。

 1.2.2  质量保证措施

1.2.2.1 安菲软件质量保证的基本思想

在软件开发的全过程将采用最新国际标准的质量保证体系，使开发的产品得到可靠的保证。用户选择安菲软件，可以从两方面得到保证：一方面是安菲软件的实力和技术能力给了用户充分的信心，并且也是软件质量的保证；另一方面，安菲软件作为一家美国企业，把自己的信誉看成企业的生命，对自己的产品以及形象一丝不苟，决不会因一时的得失而损害用户的利益。

对其中的几个工作环节进行说明：

a)  计划（Plan）——实施过程中的各阶段工作需要合作双方先经过协商制定出完整的工作计划；例如：当进行实施工作时，需要制定每周的具体工作计划；所有的工作计划都需要双方正式签字，生效，并按照执行。

b)  实现（Do）——计划完成的及时性和圆满性需要合作双方共同努力，双方都将监督本方人员按时高效地完成既定计划；都应制定必须的考核和奖惩制度，制定专职人员负责相关工作，使计划能够得以确切的落实；双方还都有考察对方计划执行情况的义务和权利。

c)  检查与评审（Check）——每个工作计划到期时都将由双方进行评价，对其中未完成的内容找出具体原因，制定改善和补救措施；项目实施过程中所产生的全部文档、问题反馈、会议及交流记录等都必须以规范的文档化的形式出现，同时都必须经过双方的确认和评审，签字后才能正式生效；尤其是对于过程中所出现的问题需要双方进行多次的确认评价，直至修改完成。

d)  改善（Act）——在整个的项目实施过程中能否具有“持续改善的能力”一定程度将决定项目的成功与否，因此项目实施中双方需要多沟通交流，尽早发现问题和不足，并立即改善，保证整个项目的顺利完成；实施中工程领导小组将负责全局性的工程进展，对出现的问题和不足协商解决，改进。

1.2.2.2 安菲软件三级项目监控体系

安菲软件建立完善的项目监控体系，在内部实行三级监控管理，包括个人周报系统、项目周报系统、部门项目执行公示系统。

通过个人周报系统对项目组每个人当天工作的考核，项目管理者可以通过个人周报系统对每个的项目工作人员的工作情况进行实时的跟踪和考核，并且可以从中发现项目执行工作的问题，做出及时的调整。

项目周报系统，结合项目里程计划和子项目计划对项目组本周工作进展进行考核和监控，同时实现对项目问题和项目缺陷的有效跟踪，便于项目工作的顺利进行和问题的及时解决。

部门项目执行公示系统，通过分析各项目执行情况，找到各项目组中存在的共性的项目管理问题，进行重点环节的工作方法和流程的改进。同时对各项目组和各项目负责人员进行相关考核。

完善的项目监控体系是安菲软件成功完成项目的有力保证。

1.2.2.3 项目质量保证体系和措施

1.2.2.3.1    项目质量保证一般原则

对于客户方项目主要有如下几点：

1．在每个阶段开始时，需要对准备情况进行认真审查，并向项目领导小组汇报，确认已经具备了开始当前阶段工作所必须的条件后，才可开始该阶段的具体工作；

2．实施中的每个阶段有阶段工作计划，具体工作中每周有工作周计划，所有计划需要经双方讨论确认并签字生效；

3．实施中双方都应按时、圆满完成任务，并督促对方的工作；

4．实施中每阶段结束，每周工作结束，需对原定计划进行双方参与的总结，形成总结报告，对其中未按时完成部分制定补救措施和整改计划，为下一阶段的工作做好准备；

5．实施中所产生的需求分析文档、软件总体设计、数据库设计都必须进行评审，尽早发现问题所在，及时进行修改使后续工作能够正常进行；

6．以上文件评审合格后由双方签署评审意见后生效，将作为下一步工作的规范和标准，用户需求原则上不应再发生变更；如遇特殊情况需要改变需求，届时由双方再协商解决；

7．充分考虑到系统的复杂性，数据量庞大的特点，开发人员进行软件功能测试，项目的系统测试将安排在客户方现场进行，这需要客户方提供大力帮助。

8．实施过程中加强沟通，包括现场工作周报，用户周报等，通过充分的信息交流了解彼此的进展情况，保证计划按时完成。

根据以上原则，在整个开发过程中，安菲软件将运用一系列的质量保证手段保证开发质量。运用质量工具进行需求分析及软件设计，使软件易于理解、易于维护、易于测试。确保系统的正确性、完整性、实用性和高效性。

1.2.2.3.2    项目计划的跟踪和控制

项目计划是项目管理的基准，现代质量管理认为“计划胜于检验”，“过程决定质量”，对于项目执行来讲同样是这样。计划是项目执行的指导，计划是控制的基准，计划是项目各方沟通的平台。计划制定的过程强调渐进明细和分解。

通常应用软件开发过程中项目计划容易出现的问题

1．项目计划凌乱、无序，也就是说不能从项目计划中看到项目执行全貌。对项目执行指导意义不大。

2．项目计划只是在项目开始时进行制定，在执行过程中不对计划进行及时管理，导致项目计划失效，同时失去对项目执行的指导意义。

3．项目计划不完整，只是在当前所关注的环节存在计划，导致项目执行工作不能整体上全面协调的推进。

本项目计划跟踪和控制建议：

1．项目计划层次划分

项目计划可分为：项目里程碑计划、子项目计划、周项目计划3个层次。充分体现项目管理中渐进明细和分解的原则。

项目里程碑计划作为项目各参与方均认可的项目阶段目标指导性文件，项目各参与方均需对其负责。

对里程碑计划进行渐进明细形成子项目计划，子项目计划要说明里程碑计划中阶段目标的实现步骤和方法。

在子项目计划的指导下形成项目各参与方的周项目计划，周项目计划作为项目进度风险控制的最小单元，根据周项目计划的执行情况进行考核，并及时形成调整措施。

2．项目计划有效性和完整性

“计划赶不上变化”，在项目执行的过程中必然会发生各种各样的情况变化，如各个层次的项目计划不能得到及时的变更控制和管理，项目计划将逐渐与项目执行情况脱节并失效。项目计划的有效性的丧失必然导致项目工作陷入无序状态，最终导致项目目标不能实现，造成项目失败。

在形成各个阶段或维度的子项目计划时，非常重要的一点是要保证项目计划的完整性。如果子项目计划存在缺失，会造成项目执行中的重大缺陷，对整体项目执行产生重大影响。

针对项目计划的有效性和完整性问题提出本项目中相关项目管理建议：

（1）项目管理组承担项目计划的变更控制和管理职能，对项目计划的有效性负全面责任。

（2）建立项目计划变更控制流程。在项目执行情况发生重大变更时，相关方必须向本项目管理组提出变更申请；项目管理组根据情况及时组织项目相关方审查项目变更，并进行风险分析，更新项目计划并通知项目各方。

（3）项目总体计划和子项目计划制定，要进行相关评审，在评审通过后方可生效。

（4）建立项目计划标识体系，包括项目计划版本标识。每次项目计划的变更均需更新标识，并说明变更原因和进行相关风险的说明。

4．项目计划的执行情况跟踪

本着及早发现问题的原则，定期的对项目计划的执行情况进行跟踪，并对跟踪结果进行公布。跟踪的频度与项目执行情况相关，可以以周、两周等频度进行。

1.2.2.3.3    项目问题和缺陷跟踪机制

对于软件开发工程项目来讲，项目在执行的过程中会出现很多问题，同时在项目监控的过程中也会发现一些缺陷。这是由于软件开发项目不确定性大的自然属性所造成。

在本项目中，对于项目中的存在问题和缺陷，建立持续的跟踪机制，由项目管理组统一负责，项目管理组协调项目各方制定处理方案，并对处理方案的执行持续跟进。

1.2.2.3.4    项目配置管理

软件有一种进化的本性，从一个软件产品的定义一直到他被停止使用的过程中它会经历许多次变更。每一次变更的结果就是该产品的一个新版本。采用迭代式方法实施客户方项目后，项目的配置管理就变得特别重要。配置管理包括项目源代码、文档的版本控制与管理。标识软件配置项，建立产品基准库，对配置项的修改加以系统的控制。

配置管理的目的就是在初始、评估、以及执行这些变更的同时，维护产品的完整性。它提供了一个理性的框架来处理包括用户需求和资源限制的非理性世界。配置管理的目的就是标识每一软件项、管理并控制软件项的变更、便于追踪各软件项和后期维护。

项目实施组的质量保证QA人员负责项目的配置管理，制订配置管理计划。

建立基准：经过正式评审和认可的一组配置项（文档和其他软件工作产品），此后它们作为进一步开发的基础，并且只有通过正式的更改控制规程才能被更改。

更改控制：在合同阶段与客户明确系统更改的控制方法，以确认系统的成功实施。因客户的业务需求变更而进行更改时应有客户的确认，以防开发人员的软件项的随意更改。

管理工具：项目组采用团队开发方法，开发过程中配置管理采取管理工具SVN管理，在项目各阶段自动产生配置报告，提交给质量保证QA负责人和项目经理PM， 以随时了解项目的状态。

多开发地点配置管理：当现场开发与技术支持中心进行联合开发时，配置管理显得非常重要，通过多项目实践，安菲软件总结出一套行之有效的配置管理工作标准和方法。

在项目开发结束后，所有代码和文档备份到专用的代码备份服务器归档。后期的维护作为新任务的开始，定期整理维护活动产生的结果，追加到原项目的备份中去，同时更新配置状态报告。

 1.2.3  工期组织措施

为了保证项目工期按时完成，安菲软件除制定了详细周密的实施计划并严格执行外，通过对项目沟通、项目需求、项目风险的科学管理和实践，及时解决项目实施过程中出现的问题和预防项目风险的发生，为保证项目进度提供了强有力的支撑。

1.2.3.1 项目沟通管理措施

通常情况下85％以上的项目问题是由沟通不畅所导致。在本项目中，针对项目沟通模式提出以下建议：

1．定期项目例会

联合项目组定期项目例会，在例会上完成项目计划执行情况检查、项目计划修订、项目风险分析、项目风险应对方案制定、项目执行绩效通报等工作。

2．不定期项目会议

由联合项目中各工作方提出会议申请，并组织会议进行，完成专题沟通工作。

3．联合项目组中各方责任明确

有效的沟通的前提是联合项目组中各方职责明确清晰，避免问题出现推诿，导致项目执行效率降低。

4．项目周报

项目管理组定期制作项目周报，并向项目相关各方发送。及时的将项目进展情况，当前项目问题向项目各方说明。

5．其他非正式沟通

电话、Email等多途径的非正式沟通手段是项目沟通工作的重要组成部分。

1.2.3.2 项目需求管理措施

在软件项目中，所有的项目相关方都感兴趣的就是需求分析阶段。这部分工作若处理好了，能开发出很出色的产品，同时会使项目各方感到满意。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有项目相关方必须重视需求分析过程。

软件需求包括三个层次：业务需求、用户需求、功能需求/非功能需求。优秀需求所具有的特性：完整性、正确性、可行性、必要性、划分优先级、无二义、可验证。

需求分为需求开发和需求管理。需求开发包括：问题获取、分析、编写规格说明和验证四个阶段。需求管理包括建立和维护软件需求。

1.2.3.2.1    需求的权利和义务

通常来说，用户方在需求活动中有如下权利：

1．要求分析人员使用符合客户语言习惯的表达。

2．要求分析人员了解客户系统的业务及目标。

3．要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明。

4．要求开发人员对需求过程中所产生的工作结果进行解释说明。

5．要求开发人员在整个交流过程中保持和维护一种合作的职业态度。

6．要求开发人员对产品的实现及需求都要提供建议，拿出主意。

7．描述产品使其具有易用、好用的特性。

8．可以调整需求，允许重用已有的软件组件。

9．当需要对需求进行变更时，对成本、影响、得失有个真实可信的评估。

10．获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的。

用户方在需求活动中有如下义务：

1．给分析人员讲解业务及说明业务方面的术语等专业问题。

2．抽出时间清楚地说明需求并不断完善。

3．当说明系统需求时，力求准确详细。

4．需要时要及时对需求做出决策。

5．要尊重开发人员的成本估算和对需求的可行性分析。

6．对单项需求、系统特性或使用实例划分优先级。

7．评审需求文档和原型。

8．一旦知道要对项目需求进行变更，要马上与开发人员联系。

9．在要求需求变更时，应遵照开发组织确定的工作过程来处理。

10．尊重需求项目中开发人员采用的流程（过程）。

1.2.3.2.2    需求变更控制流程

软件需求作为系统功能的范围界定和说明，其变更必须进行严格的变更控制管理，包括建立控制点和建立报告与审查制度。

本项目中，建议建立如下需求变更控制流程：

1．成立需求变更控制委员会，由项目管理组、项目业务技术组组成，并向项目领导组负责。

2．软件开发面对初始经评审后的需求。

3．在项目执行过程中，如发生需求变更，需求变更提出者需提交业务技术组负责人员，由业务技术组负责人员签字确认后，提交需求变更控制委员会，并通知安菲软件项目组。

4．如安菲软件项目组对需求变更无疑义，该需求将进行开发实施。

5．如安菲软件项目组对需求变更有疑义或该变更的评估分析结果对项目造成重大影响，该需求将提交需求变更控制委员会集体讨论，根据讨论结果决定处理方式。

6．需求建立统一的标识体系，以方便其管理。

1.2.3.3 项目风险管理措施

PMBOK项目管理体系中，项目执行过程的风险管理主要内容是：

1. 风险识别：确定哪些风险可能对项目造成影响并且编制每一风险的特性文件。

2．风险量化：通过对风险及风险的相互作用的评估来评价项目结果的可能范围。

3．应对措施制定：确定扩大机会的步骤及对威胁的应对措施。

4．风险控制：对项目过程中风险变化的回应。

项目各阶段开始进行风险识别与控制，并对应不同阶段总结出各自典型的风险，给出相应的风险级别和风险值计算方法。

安菲软件能充分理解稳定高效的生产管理系统对于客户方发展的重要性和整个系统上线运行时间的统一性和迫切性。安菲软件清楚认识到要实现如期交付一项功能全面的生产管理解决方案这一最终目标对于双方而言本身是一种关键风险，因此投标技术方案中所列的风险项目由安菲软件和客户方确定，以便及早的对于可能存在的风险进行管理、制定策略来降低风险。

1.2.3.3.1    风险计划与管理

风险计划

在整个项目进程中都应将管理风险的程序记录在风险管理计划里。除了记录风险识别和风险评估的结果外，还应记录包括谁对处理各个领域里的风险负责，怎样保留初步风险识别和风险量化的输出项，预防性计划怎样实施，以及人力资源如何分配等。

项目经理在项目执行过程中，需要针对可能存在的风险作好预防性计划。该计划是项目总体计划和阶段计划的一个组成部分。

项目风险计划包括以下内容：

• 项目可预测或可识别的风险内容及描述；

• 应对策略；

• 所需要的时间和资源。

风险监视

有关以前若干个项目情况的历史资料对识别目前项目的潜在风险具有特殊帮助。这种历史资料往往可以从以下渠道获得：

• 项目资料文件：需要准确保留项目各个阶段的记录，这些记录会很详细，足以协助进行风险识别工作；

• 项目组的经验知识：项目组成员对每一项工作进行产出和消耗情况分析，并对项目状态做出评估，以判断可能存在的风险。当然这样收集的信息可能很有用，但较之以文件资料形式记录的信息可靠性低些。

风险控制

风险对策实施控制包括实施风险管理方案以便在项目过程中对风险事件做出回应。当变故发生时，需要重复进行风险识别，风险评估以及风险对策研究一整套基本措施。就算最彻底和最复杂的分析也不可能准确识别所有风险以及其发生概率，理解这一点是很重要的，因此控制和重复是必要的。

必须实时调整风险管理计划。一个预料之中的风险事件发生或没发生，对实际风险事件后果的评估，对风险系数和风险机率的评估，以及风险管理方案的其它方面，都应进行实时的更新调整。

1.2.3.3.2    可能存在的风险分析

 1.3  培训方案

为了保证项目的顺利实施，安菲软件针对项目要求准备了应用操作培训、系统管理员培训、技术培训等培训内容。

 1.4  测试方案

 1.4.1  安菲软件软件测试体系

软件测试是通过有目的的运行软件程序以发现其缺陷的过程。软件测试是软件质量保证工程的一个重要组成部分，也是最重要的质量保证手段。为了保证所提交的软件产品能够满足客户的需求，以及在使用中的可靠性，所以安菲软件对其所开发的软件产品会进行系统而全面的测试。

安菲软件整个测试体系包括如下几个方面：测试过程、测试方法、测试用例、测试工具与测试管理工具。可以用下图来描述一下它们之间的关系。

在测试过程中通过测试管理工具将测试用例库与测试过程进行关联，并且对测试用例进行管理，建立起测试用例与模块的对应关系。

根据系统的特点以及复杂程度，在测试过程中选用合适的测试模型与测试方法，并且运用测试工具或执行测试用例发现软件中的缺陷，由开发人员进行改正。此过程会经过两到三次的迭代。对发现的缺陷进行总结，形成缺陷报告与测试报告。

测试完成对本次编写的测试用例与发现的缺陷由测试负责人进行归纳与总结，甄别出可以进入测试用例库与缺陷库的用例与缺陷。并经由评审小组评审后充实到用例库与缺陷库。

用例库与缺陷库都是测试经验的积累，可以由下一次测试过程复用。正是这个回溯的测试体系，才能保证软件质量的不断提高，而安菲软件已经在此测试体系上进行了多次实践，积累了丰富的经验。

 1.4.2  安菲软件的测试管理

1.4.2.1 测试管理组织结构

 1.4.3  测试过程分类

对系统进行测试执行主要经过单元测试（功能测试），系统测试，验收测试几个阶段。开发过程和测试行为对应关系如下图所示。

1.4.3.1 单元测试

单元是软件系统的最小组成单位，逻辑较简单，能被单独地编译和测试。单元测试集中在程序的基本组成部分，首先保证每一个单元测试通过，为下一步集成测试打下良好的基础。

单元测试重点关注以下内容：单元接口、局部数据结构、重要的执行路径、错误处理的路径、影响上述几点的边界条件。

在系统编写一段代码或完成一个功能后，即进行单元测试。

单元测试主要由开发人员与测试人员共同执行。发现的Bug由测试管理工具进行管理。此测试阶段对Bug的修改方式采用快速式提交的方式。每个模块测试人员在本模块功能中发现一定数量Bug时停止测试，由开发人员对Bug进行修改，修改结束后再继续向下测试。并且此时不采用服务器建立版本测试，测试人员在本地机建立测试环境进行测试。

此阶段测试方法主要采用手动灰盒测试方法。

1.4.3.2 系统测试

系统测试以整个系统进行版本管理，也就是测试人员运行集成过的整个系统，强调以下几方面内容：功能、性能、可用性、安装、安全性、兼容性。Bug修改方式为按照整个系统强制提交。系统测试在全部测试用例通过之后，开发中心测试部分结束。

整个系统测试阶段采用黑盒测试的方法，

1.4.3.3 验收测试

提交验收测试的软件已经通过严格测试过程进行了质量保证，但是由于行业软件的复杂性决定系统必须经过用户实际验证，一些外部的接口必须要由接口双方共同配合调试进行验证，系统才能正式投入运行。并且对整个系统的性能方面也要经过在现场实际的硬件环境下进行验证。

验收测试主要分为功能测试与性能测试，主要由行业专家和用户对系统功能与性能进行验证。确认软件的功能，性能达到当初的设计要求。

系统提交验收测试时，同时会提供设计文档，测试设计文档以及测试报告，作为用户验收测试参考依据。根据客户方验收测试要求，在系统进行验收测试时会在验收现场指定测试人员与用户一同制定测试计划编写测试用例。这需要客户方实施地点提供大力帮助。

功能测试主要根据系统软件需求说明书与系统设计报告对系统的功能进行验证，全部设计功能是否实现，功能性问题是否存在。

性能测试主要是在现场实际的硬件环境下对整个系统性能进行验证。采用LoadRunner用来模拟多用户并发运行程序进行并发测试与压力测试，同时可以监控数据库服务器CPU利用率、内存、I/O等各项性能指标，结果形成图形形式，并且对测试结果进行全面分析。力争提早发现系统性能方面的缺陷。

在每个测试用例设计过程中，采用以用户为中心的设计方法（UCD），遵循可用性设计规范，力争达到测试人员容易理解的程度。采用的主要方法是黑盒测试（不针对代码进行测试）。验收测试发现的Bug马上由开发人员修改。并且发现的Bug作为缺陷提交到测试leader与SQA组进行分析。

验收测试结束后由双方共同出一份验收测试报告。

 1.4.4  安菲软件测试过程

项目测试在软件开发过程中不是一个孤立的过程，从立项开始到系统释放，测试工作贯穿整个软件生命周期。测试在软件生命周期中的工作过程可以用下表进行描述。

1.4.4.1 建立项目测试组

针对具体项目的测试，首先建立项目测试组，本次项目将成立：项目测试组，设立项目测试负责人。由项目测试负责人对具体项目进行测试过程管理。此时项目测试负责人可以申请用例编写者与测试工具开发人员人力资源。用例编写者与测试工具开发人员根据测试项目的难易程度可能有多个人或者一个人担任。这时还不需要确定项目中的具体测试执行者。

项目测试负责人对项目测试进行管理，监督本项目的进度与计划执行情况。并且定期向测试leader汇报Bug报告与测试进度。

1.4.4.2 制定测试计划（Test plan）

项目测试组成员参与需求调研以及需求评审工作，一方面是从需求评审开始就对缺陷进行预防，同时又对本次所测试的内容有一个深入了解。项目测试负责人根据需求调研以及评审结果制定测试计划。

测试计划主要体现的是对测试时间分配与相关资源配置。包括以下几个要点

1.  确定进度与时间的安排

2.  总体测试构思和设想

3.  测试总体范围

4.  测试方法与测试工具

5.  测试人员安排

6.  所需要进行的培训

7.  相关软硬件可用资源

8.  系统提交标准

测试计划是对本次测试的系统一个高层次、比较笼统地计划。一般在制定测试计划时往往开发计划还没有制定，所以测试计划中的进度与时间安排做成相对时间。等到开发计划制定完毕后再修改定为具体的测试时间安排。进度与时间安排中除了包括测试时间外，还包括测试用例评审，阶段性测试总结时间安排。

测试计划中所确定的测试总体计划，并不具体到每个模块的各个功能，此处只体现到模块级别用于确定本次测试所包含的总体范围。

总体测试构思与设想主要指测试的思路，测试策略，及测试用例复用的范围。并且根据总体的构思与设想，制定本次测试的测试方法，所应用的测试工具，以及为了完成本次测试人员所要接受业务与技术上的培训。

测试人员的安排根据开发人员与开发计划进行配置，按照系统划分的开发模块，一般情况按照开发人员与测试人员比例2：1进行配置。根据模块的难易程度与复用情况再进行调整。

测试所用到硬件资源，比如应用服务器的配置、IP地址、机器管理人员等也要在测试计划中进行说明。

1.4.4.3 测试大纲与测试规范（Test design spec）

项目概要设计完成之后，测试负责人根据概要设计制定测试大纲，同时指定各个模块测试负责人。每个模块测试负责人负责编写本模块的测试规范。

测试大纲代表了本系统所具有的功能点，也是本次软件测试的范围。测试大纲确定之后项目测试负责人会组织需求调研人员、设计人员、开发人员对测试大纲进行评审。经过评审确认的测试大纲同时也成为软件开发功能点开发范围。

测试规范则是细化的测试计划。用于对测试执行人员测试工作进行指导。测试规范主要是对一个或多个软件功能测试的途径和确认所需的测试详细描述的文件。主要包括以下几个要点：

1．该模块的目的与技术背景

2．测试范围

3．是否有其他功能或组件的限制

4．功能细分后的功能测试要点

5．测试用例编写思路

6．具体的测试方法

7．使用的测试工具

8．测试通过的标准

由于测试规范更多可以视作一个模块的具体详细的测试计划，所以模块测试负责人需要对相应的模块需求分析报告，总体设计报告与详细设计报告进行分析，制定本次测试策略，形成测试规范。测试人员可以根据测试规范确定测试范围，创建测试用例。从而更有效的找到产品中的缺陷。

1.4.4.4 测试用例(test case)

详细设计完成后开始整理测试用例。测试用例是描述具体怎样测试一种软件行为的文字段落一般测试用例包括如下的常见内容：

1．标题（现实目的）

2．测试版本

3．初始条件

4．输入的数据和输出结果

5．执行程序的步骤

6．标明预期的结果或者意外的结果

7．标明任何所需的测试装备/环境需要

有了测试用例可以形成不同层次的测试体系。将测试设计与测试执行更好的分开。而且同一功能不同版本多次测试时可以有明确的是否通过的纪录。并且根据通过与失败的测试用例比率估计产品总体的各个阶段的质量。而且还将测试用例全部测试通过作为本阶段测试通过的依据。

在安菲软件开发中心测试组中测试用例的来源有两个途径，一是从原有的测试用例库中复用，而对于没有复用用例的功能点则需要编写用例。

测试用例库是安菲软件在长期的测试实践中对以往项目的测试用例进行归纳总结，并且在每个项目结束后对用例库进行迭代更新，最终所形成的测试用例资源库。测试用例库也由测试管理工具进行管理。

由模块测试负责人对测试用例库中的用例进行甄别，决定每个功能点复用的用例，不能复用用例的功能点由项目测试组内用例编人员根据详细设计编写测试用例。

公司质量体系管理部门根据系统的软件种类和安菲软件质量管理制度，规定了安菲软件开发中心编写测试用例的格式，包括如下内容：

1．测试用例对应的测试大纲编号

2．测试用例描述

3．操作过程与数据

4．预期结果

5．验证过程

6．其他（以附件的形式体现）

而测试用例根据安菲软件长期经验积累，按照验证类别分对系统功能验证，性能验证，以及可用性验证。也就是说除了系统功能要满足用户需要求之外，还要对可用性与性能进行验证。

可用性主要包括以下几点：

1．用户界面测试：用户界面的设计是否看上去整洁，清楚，美观大方。

2．易用性：功能使用是否方便快捷，快捷键是否好用。系统进度是否运用光标或进度条提示。

3．通用性：各种警示图标是否运用得准确，符合国际标准。错误提示是否准确，易于诊断错误

4．文档：帮助文件，用户手册是否完善友好。

性能主要是验证系统在高并发情况是否能正常运行，在一定的压力下无明显的性能下降。

系统测试所使用的测试用例在执行之前项目测试负责人会组织需求调研人员，设计人员，开发人员对测试用例进行评审，评审通过的测试用力通过测试管理工具进行管理，将测试用例与测试大纲进行关联，建立用例与模块的对应关系。

1.4.4.5 测试执行

测试执行为整个测试工作中主要工作，经历阶段可以由下表说明，反映出测试执行时各个阶段所对应的不同重点与主要工作。

相对于适当的规范和测试计划，每个测试阶段的成功结果是软件按预期效果运行。

测试执行开始时，由项目测试负责人对测试管理软件进行配置。包括初始化项目状态，指定模块开发人员、测试人员。将测试大纲与用例导入测试管理软件，建立测试管理软件单元测试版本。

1.4.4.6 测试问题报告

Bug报告是指定期对目前软件测试中的发现Bug进行汇总，并且按照发现时间，Bug等级、发现人员、发现模块等不同条件分组汇总而形成的报告。

Bug报告主要具有如下几个特点

1．面向整个开发团队

2．能反映当前的测试状态

3．报告目前所遗留Bug

4．报告新产生的Bug

5．报告已经解决和关闭的Bug

6．根据测试结果对开发所提出的改进建议

测试报告不仅仅能反映出当前的测试Bug的数据，还有对前一阶段的测试工作的总结。所以项目测试负责人与软件项目经理可以根据此报告及时修正下一个阶段的测试与开发工作。开发负责人根据测试报告建议对开发工作进行改进，对已经发现的缺陷要在下一个版本避免。

安菲软件测试组规定，在进行单元测试时Bug由项目测试负责人每周汇总，发给项目QA，再由QA发送给整个项目团队。项目软件经理每两周对Bug报告进行总结，提出下一个阶段开发改进建议。而且每两周由项目测试负责与项目软件经理共同组织测试人员与开发人员交流会，会上对近阶段所发现以及改进的Bug进行讲解与分析。

在系统测试阶段则是以一个测试版本结束为标志提交Bug报告。而且发现的Bug会根据Bug等级记录，进行Bug分析 。

1.4.4.7 系统发布

系统测试结束之后，通过项目经理，项目软件经理/项目现场实施负责人，测试负责人三方对软件评审确认软件释放。软件释放后提交用户进行验收测试。

1.4.4.8 测试总结

确认系统释放后，由本项目的测试负责人编写本次的测试报告测试分析报告。

测试报告主要包括以下几个要点

1．对软件的质量进行评价

2．测试数据进行记录

3．测试过程进行总结

测试分析报告包括以下几个要点

1．缺陷预测与维护成本预测

2．对本次测试工作进行总结，并且提出改进建议

此外还要组织对本次测试过程中的新增的用例与缺陷进行评审，提交过程积累库。正是不断的积累总结，测试质量也不断提高。

 1.5  验收方案

项目的验收，按照总体推进分阶段验收的原则进行。

 1.5.1  系统功能验收

针对项目建设阶段的安排，系统功能验收主要是按照合同的应用软件要求、经过双方签字认可的《需求分析报告》，分别进行功能测试是否满足这些指标、同时依据制定的验收细则进行验收。系统功能验收结果要提交一份由客户方用户、安菲软件签名的系统功能验收报告，同时给出明确结论：

通过验收，可以进入试运行；

基本通过验收，但要求在某一期限内解决某些遗留问题；

未通过验收，确定在某一时间内再次进行验收。

系统功能验收工作程序：

1．验收前的准备

根据招标及合同中的系统功能和性能指标要求，双方联合制订功能测试方案、性能测试方案、数据准备情况验证方案及验收细则，做好验收时间、软/硬件环境的验收准备工作。

同时，系统将在此期间进行应用软件和应用软件相关交付项的交付工作。所有合同范围之内的文档、产品、硬件将按照用户给出的验收准则给予验收

2．验收测试

根据测试方案，安菲软件安排技术人员协助客户方进行验收；

A）  软件功能清单核实

B）  系统环境测试

C）  系统可靠性测试

D）  系统维护性测试

E）  系统相关接口测试

F）  系统稳定性测试

G）  软件功能测试

H）  系统性能测试

I） 相关文档资料验收

3．编写验收报告：验收的结果由参加验收的各方签名，形成系统功能验收报告，并且给出最终的明确结果。

4．问题处理

在验收过程中发现的问题根据售后服务规定来处理。未能确定问题类型和责任归属，由双方协商解决办法。

交付文档：《系统功能验收清单》、《系统功能验收报告》、《系统操作手册》、《技术服务和技术培训资料》、《系统软件功能验收测试报告》。

 1.5.2  项目验收

针对项目建设阶段的安排，本项目的验收，安排在项目良好运行三个月之后进行，时间安排参照项目实施进度安排：

项目验收工作程序：

1．验收前的准备

根据招标及合同中的系统性能指标要求，双方联合制订性能测试方案、数据准备情况验证方案及验收细则，做好验收时间、软/硬件环境的验收准备工作。

同时，系统将在此期间进行应用软件和应用软件相关交付项的交付工作。所有合同范围之内的文档、产品、硬件将按照用户给出的验收准则给予验收

2．验收测试

根据测试方案，安菲软件安排技术人员协助客户方进行验收；

A）软件功能清单核实

B）系统环境测试

C）系统可靠性测试

D）系统维护性测试

E）系统相关接口测试

F）系统稳定性测试

G）软件功能测试

H）系统性能测试

I） 系统试运行报告

J） 相关文档资料验收

3．编写验收报告：验收的结果由参加验收的各方签名，形成系统试运行验收报告，并且给出最终的明确结果。

4．问题处理

在验收过程中发现的问题根据售后服务规定来处理。未能确定问题类型和责任归属，由双方协商解决办法。

缺陷责任期：

系统正式上线后，系统进入缺陷责任期阶段，缺陷责任期为12个月。安菲软件对整个系统提供12个月技术支持服务，在服务期内，安菲软件保证现场及时解决巡检过程中发现的问题，并根据运行情况提出相应的优化方案，如果系统发生故障，安菲软件及时查清系统故障原因并及时修复直至满足最终验收指标和性能的要求。

 1.6  维护及质保期服务

试运行通过后，安菲软件提供为期1年的质保期技术支持和维护服务。

技术支持中心继续服务于客户方技术人员，进行日常的程序维护和系统维护。

提供7×24小时的实时响应，专人负责。

在接到报修通知后，在1小时内响应。对于影响系统正常运行的严重故障，相关技术人员将在4小时内赶到现场，查找原因，提出解决方案，并工作直至故障修妥完全恢复正常服务为止，保证系统在4小时之内修复。

缺陷责任期外，将以优惠的价格提供售后服务。在接到维护电话2小时内响应，及时组织工程技术人员排除故障，确保系统迅即恢复正常运行。

技术开发 编程 技术框架 技术发展