软件实施计划方案文档格式.docx

软件实施计划方案文档格式.docx

《软件实施计划方案文档格式.docx》由会员分享，可在线阅读，更多相关《软件实施计划方案文档格式.docx（12页珍藏版）》请在冰豆网上搜索。

⏹QA

对项目组进行质量体系文件与本项目相关部分的应用培训；

跟踪监督项目过程活动；

检查项目成果是否符合规范、规定要求；

动态监控质量体系执行情况；

对违反质量管理规范的情况提出改进或否决意见；

及时提交质量监控报告。

⏹系统集成与实施组

项目相关硬件系统及网络方案确定；

项目相关硬件系统环境及网络环境的搭建、调试；

系统软件及所需工具的检查和安装；

硬件系统的运行维护。

⏹业务组

了解用户需要；

整理撰写目标系统说明书；

参加需求评审，确认最终需求；

制订项目目标及验收标准；

组织系统验收过程，验收最终系统。

⏹开发组

确认系统需求；

撰写开发方案及各设计文档；

根据编码规范，对系统进行编码实现；

对完成的模块采用白盒测试方法进行自测；

对提交测试组测试出的问题进行修改。

开发组下设四个开发小组

1）规划组：

负责学校学生工作管理系统采购项目规划

2）需求调研组：

负责学校学生工作管理系统采购项目需求调研

3）开发组：

负责学校学生工作管理系统采购项目的开发

4）测试组：

搭建测试环境，确定测试方案；

撰写测试计划及测试用例；

对系统进行测试；

根据测试结果提交各问题表及测试报告；

对修改完成的版本进行回归测试。

⏹培训组

进行用户培训。

⏹支持服务组

对系统的软硬件运行进行维护；

对系统运行中的问题进行记录，并转交开发组；

对系统运行中产生的一般性故障进行维护。

5.2风险管理

将项目实施过程中出现的风险包括已成功规避的风险都在项目结项时进行总结并积累下来，形成风险操作指南，作为后期项目的一个参考。

项目在立项阶段制定该项目的《风险管理计划》，每个阶段都更新相应的《风险列表》，针对风险列表中各风险进行风险的识别、分析和应对，有效规避风险。

v风险识别

风险识别包含两方面内容：

识别哪能些风险可能影响项目进展及记录具体风险的各方面特征。

风险识别不是一次性行为，而应有规律的穿整个项目中。

项目的有效沟通也是项目成败的关键，通常项目过程中项目组成员之间或与客户之间一般都通过语言沟通交流，领导和员工间通过开会布置任务，容易造成文档、资料丢失和事后检查困难等。

针对这类问题，公司制定的《项目管理制度》中明确规定项目交流制度方式、时间、频度，包括项目过程中项目组与客户交流、部门之间交流、部门内部交流、项目组内部交流过程的规范，并要求在《项目总体计划》中确定下来，保证项目过程中沟通的规范性和有效性。

v风险量化

风险量化涉及到对风险和风险之间相互作用的评估，用这个评估分析项目可能的输出。

这首先需要决定哪些风险值得反应。

风险由于包括诸多因素而较复杂，这里就部分因素列举如下：

v风险对策研究

风险对策研究包括对机会的跟踪进度和对危机的对策的定义。

对危胁的对策大体分以下三点：

避免--排除特定危胁往往靠排除危胁起源。

项目管理队伍绝不可能排除所有风险，但特定的风险事件往往是可以排除的。

减缓--减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数，或两者双管齐下。

吸纳--接受一切后果。

这种接受可以是积极的（如制定预防性计划来防备风险事件的发生），也可以是消极的。

v风险对策实施控制

风险对策实施控制包括实施风险管理方案以便在项目过程中对风险事件做出回应。

当变故发生时，需要重复进行风险识别，风险量化以及风险对策研究一整套基本措施。

就算最彻底和最复杂的分析也不可能准确识别所有风险以及其发生概率，理解这一点是很重要的，因此控制和重复是必要的。

5.3质量保证

v项目承建方质量方针

始终如一地从用户利益出发，最大限度地优化从供应商到客户这一流程的所有重要环节，使用户利益最大化是项目承建方生存和发展的基本出发点。

v持续改进是项目承建方每个员工的责任

项目承建方每一名员工都认识到质量对于项目成功的重要性，质量是每一个人的责任，我们不断寻求更理想的提高质量的途径，不断加强生产优质产品、提供卓越服务的主动精神、专业技能和生产过程能力。

v质量保证活动

每个项目都有一个专职QA对项目过程进行跟踪，在项目立项阶段由QA制定《质量保证计划》，并根据该计划对项目各过程进行跟踪，主要包括：

代表开发小组与用户进行访谈、交流，与用户之间的交流通道，对项目组不能解决的问题以《QA报告》的形式提交项目组。

v组织并参与评价项目各阶段的评审

跟踪项目需求，重点监控项目过程变更的数量，并填写相应记录表格；

监控贯穿于整个项目过程需求的一致性。

v定期与用户进行沟通，进行用户满意度跟踪与调查

在项目需求确定后，与项目承建商共同商定《系统验收标准》和客户测试的《测试方案》确认，保证测试过程目标明确性和有效性。

5.4配置管理

软件配置管理是指对工作成果（主要是代码和文档）进行版本管理，保证所有工作成果的完整性和跟踪性。

配置管理是对工作成果的一种有效保护。

整个机构应当统一使用配置管理软件（包括文档管理软件和代码管理软件）。

任何项目成员都必须对自己的工作成果进行配置管理。

软件配置管理的流程如图所示，关键活动是“制定配置管理计划”、“文档管理”和“代码管理”。

⏹配置管理需要记录每一配置对象的创建、变更及消亡情况。

⏹配置管理员需要及时填写配置管理报告。

⏹在任意配置对象出现变更时，该对象必须做备份，且该备份不能将原来的备份覆盖，直至该配置对象被评审通过形成基线后，可以只保留最近的备份。

⏹在项目出现反复或失误时，配置管理人员必须能以最快的速度拿出最近的回溯点版本。

⏹配置管理员必须能够对每一次修改的主要责任人进行准确的定位，同时也必须对每一次修改的根本原因有准确的了解，必要时应能拿出充分的材料。

5.5文档管理

项目文档管理包括规范相关文档管理和项目过程文档管理。

规范相关文档主要用于指导项目各阶段操作内容，详细说明各阶段的主要任务及产生的阶段成果，保证各项目都能够按照科学的有成功先例的项目模式执行。

在项目立项阶段，该项目QA会与项目负责人根据项目特点共同确定该项目所使用的规范，形成实施项目过程指导，作为该项目过程的执行规范；

项目过程文档指本项目在各阶段产生的阶段成果，包括需求阶段的目标系统说明书、计划阶段产生的项目工作手册或项目总体计划、设计阶段产生的数据库设计说明书和设计文档等，保证下一阶段与上一阶段工作的延续性与一致性。

为避免出现项目过程中抛开文档，自行开发，导致项目结束时才发现文档与系统根本不相关的现象，项目承建方对项目过程中的文档管理采用一套完整的流程，有独立于项目组的SCM（配置管理工程师）专职保证项目过程中能够提取出的文档与目标系统是一致的。

所有项目过程中的变更都必须经SCCB审批后才能够进行变更，变更内容入库只有该项目SCM才能够进入基线库进行更新，而项目过程中的最终版本和项目验收标准版本都是从基线库中提取，从而保证项目过程中文档与系统的一致性。

5.6测试管理

专门成立独立于开发的项目测试组，由受过专业测试培训的人员组成，保证测试过程的相对独立性，也保证测试的有效性。

测试人员在项目立项阶段就会参与到项目中，保证了对项目需求的了解。

⏹测试工作流程

测试方法采用白盒测试和黑盒测试相结合的方式，测试过程分为业务模块测试、系统测试、整体测试，测试内容包括功能测试、可靠性、安全性、性能、可扩充性、可维护性、平台移植性、与其它系统的接口等测试，测试数据由测试人员通过撰写《测试用例》的方式进行准备，测试结果以《测试报告》的方式进行反馈。

测试过程遵循公司《测试流程规范》，保证测试过程所有问题的有效解决。

⏹需求阶段测试流程

测试可以大致可以分为一下几类；

单元/集成测试，系统测试，压力测试，性能测试。

⏹单元/集成测试阶段流程

⏹系统测试阶段流程图

⏹压力测试流程

说明：

压力测试为模拟用户正常使用时，系统正常工作的最小时间。

●性能测试流程

测试系统的崩溃极限（最多使用人数和数据库的极限容量）。

5.7用户评价

本阶段由客户项目组成员完成，包括以下步骤：

◆设计用户接受程度测试的标准

◆测试队伍的培训

◆设计测试的文档和数据

◆进行用户接受测试，允许用户评定交付的系统是否依据已达成协议的未来的流程进行设置并执行完成的。

这个测试包括所有终端对终端的程序、在线业务流程、与其他系统的集成（如果有的话）等而不仅仅是系统本身的测试。

5.8项目验收

在项目试运行阶段接近结束时，项目经理应提前准备发布正式版本，确保项目验收前，客户现场所用版本为正式版本。

在试运行阶段结束后，项目经理根据客户方提出的验收标准（可包括：

系统功能验证、性能测试以及培训效果测试等），拟定验收方案并向客户方提出验收申请同时准备相关验收资料。

在验收方案经过客户方审核确认后，由项目经理协助客户方依据验收方案进行项目验收测试，并记录测试结果，同时将项目试运行记录整理后归档。

5.9项目保障

⏹高层领导的参与和支持

⏹业务部门领导的支持

⏹高效的项目实施组织

⏹全面的知识培训

⏹严格的项目管理（计划管理、项目组织、项目实施范围控制、报告和决策机制）

⏹定期的质量检查

⏹基础数据规范和准确

⏹避免日常工作和本项目实施的冲突