软件实施方案（共7篇）
第1篇：软件实施方案
5、项目实施方案 5.1组织机构
项目组人员组织结构
为项目顺利启动并成功实施，确保项目质量，达到预期目标，建立分工明确、职责清楚、层次分明又能协调配合的项目管理组织和架构就是至关重要的环节。根据学校的情况及所需协调资源，建立的组织结构如下。
公司领导小组
项目的最高领导，了解项目进展情况，协调各自项目资源，控制项目进度、风险，进行重大决策，明确管理架构及人员，协调各自人员到位，确认项目目标系统及验收标准，对项目过程中涉及项目范围的变更内容进行确认，并审批变更，解决项目过程中所出现的重大问题。
项目总监/项目经理
项目总监是项目实施的总负责人，全权负责项目过程的管理，包括人、才、物的管理；协调各部门之间的沟通，确保工程项目的按时、优质完成。项目总工程师分管两个分项目组，每个项目组都有项目组长，分项目组的主要职能是：项目设计、项目计划编制、项目实施过程的管理、测试盒质量保证、远程支持体系的管理、用户培训、协作、验收、确保分项目的高质量完成。
商务组
由XXXX公司的商务代表组成，负责处理与合同有关的各种商务活动，例如产品的交货、费用结算、与软件产品、硬件产品供应商的商务来往。
QA 对项目组进行质量体系文件与本项目相关部分的应用培训；跟踪监督项目过程活动；检查项目成果是否符合规范、规定要求；动态监控质量体系执行情况；对违反质量管理规范的情况提出改进或否决意见；及时提交质量监控报告。
系统集成与实施组
项目相关硬件系统及网络方案确定；项目相关硬件系统环境及网络环境的搭建、调试；系统软件及所需工具的检查和安装；硬件系统的运行维护。 业务组
了解用户需要；整理撰写目标系统说明书；参加需求评审，确认最终需求；制订项目目标及验收标准；组织系统验收过程，验收最终系统。
开发组
确认系统需求；撰写开发方案及各设计文档；根据编码规范，对系统进行编码实现；对完成的模块采用白盒测试方法进行自测；对提交测试组测试出的问题进行修改。开发组下设四个开发小组
1) 规划组：负责学校学生工作管理系统采购项目规划
2) 需求调研组：负责学校学生工作管理系统采购项目需求调研 3) 开发组：负责学校学生工作管理系统采购项目的开发
4) 测试组： 搭建测试环境，确定测试方案；撰写测试计划及测试用例；对系统进行测试；根据测试结果提交各问题表及测试报告；对修改完成的版本进行回归测试。 培训组 进行用户培训。 支持服务组
对系统的软硬件运行进行维护；对系统运行中的问题进行记录，并转交开发组；对系统运行中产生的一般性故障进行维护。
5.2风险管理
将项目实施过程中出现的风险包括已成功规避的风险都在项目结项时进行总结并积累下来，形成风险操作指南，作为后期项目的一个参考。项目在立项阶段制定该项目的《风险管理计划》，每个阶段都更新相应的《风险列表》，针对风险列表中各风险进行风险的识别、分析和应对，有效规避风险。
风险识别
风险识别包含两方面内容：识别哪能些风险可能影响项目进展及记录具体风险的各方面特征。风险识别不是一次性行为，而应有规律的穿整个项目中。
项目的有效沟通也是项目成败的关键，通常项目过程中项目组成员之间或与客户之间一般都通过语言沟通交流，领导和员工间通过开会布置任务，容易造成文档、资料丢失和事后检查困难等。针对这类问题，公司制定的《项目管理制度》中明确规定项目交流制度方式、时间、频度，包括项目过程中项目组与客户交流、部门之间交流、部门内部交流、项目组内部交流过程的规范，并要求在《项目总体计划》中确定下来，保证项目过程中沟通的规范性和有效性。
风险量化
风险量化涉及到对风险和风险之间相互作用的评估，用这个评估分析项目可能的输出。这首先需要决定哪些风险值得反应。风险由于包括诸多因素而较复杂，这里就部分因素列举如下：
风险对策研究
风险对策研究包括对机会的跟踪进度和对危机的对策的定义。对危胁的对策大体分以下三点：
避免--排除特定危胁往往靠排除危胁起源。项目管理队伍绝不可能排除所有风险，但特定的风险事件往往是可以排除的。
减缓--减少风险事件的预期资金投入来减低风险发生的概率，以及减少风险事件的风险系数，或两者双管齐下。
吸纳--接受一切后果。这种接受可以是积极的（如制定预防性计划来防备风险事件的发生），也可以是消极的。
风险对策实施控制
风险对策实施控制包括实施风险管理方案以便在项目过程中对风险事件做出回应。当变故发生时，需要重复进行风险识别，风险量化以及风险对策研究一整套基本措施。就算最彻底和最复杂的分析也不可能准确识别所有风险以及其发生概率，理解这一点是很重要的，因此控制和重复是必要的。
5.3质量保证
项目承建方质量方针
始终如一地从用户利益出发，最大限度地优化从供应商到客户这一流程的所有重要环节，使用户利益最大化是项目承建方生存和发展的基本出发点。
持续改进是项目承建方每个员工的责任
项目承建方每一名员工都认识到质量对于项目成功的重要性，质量是每一个人的责任，我们不断寻求更理想的提高质量的途径，不断加强生产优质产品、提供卓越服务的主动精神、专业技能和生产过程能力。
质量保证活动
每个项目都有一个专职QA对项目过程进行跟踪，在项目立项阶段由QA制定《质量保证计划》，并根据该计划对项目各过程进行跟踪，主要包括：
代表开发小组与用户进行访谈、交流，与用户之间的交流通道，对项目组不能解决的问题以《QA报告》的形式提交项目组。
组织并参与评价项目各阶段的评审 跟踪项目需求，重点监控项目过程变更的数量，并填写相应记录表格；监控贯穿于整个项目过程需求的一致性。
定期与用户进行沟通，进行用户满意度跟踪与调查
在项目需求确定后，与项目承建商共同商定《系统验收标准》和客户测试的《测试方案》确认，保证测试过程目标明确性和有效性。
5.4配置管理
软件配置管理是指对工作成果（主要是代码和文档）进行版本管理，保证所有工作成果的完整性和跟踪性。
配置管理是对工作成果的一种有效保护。整个机构应当统一使用配置管理软件（包括文档管理软件和代码管理软件）。任何项目成员都必须对自己的工作成果进行配置管理。
软件配置管理的流程如图所示，关键活动是“制定配置管理计划”、“文档管理”和“代码管理”。
配置管理需要记录每一配置对象的创建、变更及消亡情况。 配置管理员需要及时填写配置管理报告。
在任意配置对象出现变更时，该对象必须做备份，且该备份不能将原来的备份覆盖，直至该配置对象被评审通过形成基线后，可以只保留最近的备份。
在项目出现反复或失误时，配置管理人员必须能以最快的速度拿出最近的回溯点版本。
配置管理员必须能够对每一次修改的主要责任人进行准确的定位，同时也必须对每一次修改的根本原因有准确的了解，必要时应能拿出充分的材料。
5.5文档管理
项目文档管理包括规范相关文档管理和项目过程文档管理。
规范相关文档主要用于指导项目各阶段操作内容，详细说明各阶段的主要任务及产生的阶段成果，保证各项目都能够按照科学的有成功先例的项目模式执行。在项目立项阶段，该项目QA会与项目负责人根据项目特点共同确定该项目所使用的规范，形成实施项目过程指导，作为该项目过程的执行规范；
项目过程文档指本项目在各阶段产生的阶段成果，包括需求阶段的目标系统说明书、计划阶段产生的项目工作手册或项目总体计划、设计阶段产生的数据库设计说明书和设计文档等，保证下一阶段与上一阶段工作的延续性与一致性。
为避免出现项目过程中抛开文档，自行开发，导致项目结束时才发现文档与系统根本不相关的现象，项目承建方对项目过程中的文档管理采用一套完整的流程，有独立于项目组的SCM（配置管理工程师）专职保证项目过程中能够提取出的文档与目标系统是一致的。所有项目过程中的变更都必须经SCCB审批后才能够进行变更，变更内容入库只有该项目SCM才能够进入基线库进行更新，而项目过程中的最终版本和项目验收标准版本都是从基线库中提取，从而保证项目过程中文档与系统的一致性。
5.6测试管理
专门成立独立于开发的项目测试组，由受过专业测试培训的人员组成，保证测试过程的相对独立性，也保证测试的有效性。测试人员在项目立项阶段就会参与到项目中，保证了对项目需求的了解。
测试工作流程
测试方法采用白盒测试和黑盒测试相结合的方式，测试过程分为业务模块测试、系统测试、整体测试，测试内容包括功能测试、可靠性、安全性、性能、可扩充性、可维护性、平台移植性、与其它系统的接口等测试，测试数据由测试人员通过撰写《测试用例》的方式进行准备，测试结果以《测试报告》的方式进行反馈。测试过程遵循公司《测试流程规范》，保证测试过程所有问题的有效解决。
需求阶段测试流程
在项目需求确定后，与项目承建商共同商定《系统验收标准》和客户测试的《测试方案》确认，保证测试过程目标明确性和有效性。
测试可以大致可以分为一下几类；单元/集成测试，系统测试，压力测试，性能测试。
单元/集成测试阶段流程
系统测试阶段流程图
压力测试流程
说明：压力测试为模拟用户正常使用时，系统正常工作的最小时间。
性能测试流程
说明：测试系统的崩溃极限（最多使用人数和数据库的极限容量）。
5.7用户评价
本阶段由客户项目组成员完成，包括以下步骤： 设计用户接受程度测试的标准 测试队伍的培训 设计测试的文档和数据
进行用户接受测试，允许用户评定交付的系统是否依据已达成协议的未来的流程进行设置并执行完成的。这个测试包括所有终端对终端的程序、在线业务流程、与其他系统的集成（如果有的话）等而不仅仅是系统本身的测试。
5.8项目验收
在项目试运行阶段接近结束时，项目经理应提前准备发布正式版本，确保项目验收前，客户现场所用版本为正式版本。在试运行阶段结束后，项目经理根据客户方提出的验收标准（可包括：系统功能验证、性能测试以及培训效果测试等），拟定验收方案并向客户方提出验收申请同时准备相关验收资料。
在验收方案经过客户方审核确认后，由项目经理协助客户方依据验收方案进行项目验收测试，并记录测试结果，同时将项目试运行记录整理后归档。
5.9项目保障
高层领导的参与和支持 业务部门领导的支持 高效的项目实施组织 全面的知识培训
严格的项目管理（计划管理、项目组织、项目实施范围控制、报告和决策机制） 定期的质量检查 基础数据规范和准确
避免日常工作和本项目实施的冲突
第2篇：软件实施方案
----
5、项目实施方案
5.1 组织机构
项目组人员组织结构
为项目顺利启动并成功实施， 确保项目质量，达到预期目标，建立分工明确、职责清楚、层次分明又能协调配合的项目管理组织和架构就是至关重要的环节。根据学校的情况及所需协调资源，建立的组织结构如下。
公司领导小组
项目的最高领导，了解项目进展情况，协调各自项目资源，控制项目进度、风险，进行重大决策，明确管理架构及人员，协调各自人员到位，确认项目目标
系统及验收标准，对项目过程中涉及项目范围的变更内容进行确认， 并审批变更，解决项目过程中所出现的重大问题。
项目总监 / 项目经理
项目总监是项目实施的总负责人，全权负责项目过程的管理，包括人、才、物的管理；协调各部门之间的沟通，确保工程项目的按时、优质完成。项目总工
程师分管两个分项目组， 每个项目组都有项目组长， 分项目组的主要职能是： 项目设计、项目计划编制、项目实施过程的管理、测试盒质量保证、远程支持体系
的管理、用户培训、协作、验收、确保分项目的高质量完成。
商务组
由 XXXX公司的商务代表组成，负责处理与合同有关的各种商务活动，例如产品的交货、费用结算、与软件产品、硬件产品供应商的商务来往。 QA
对项目组进行质量体系文件与本项目相关部分的应用培训； 跟踪监督项目过
程活动；检查项目成果是否符合规范、规定要求；动态监控质量体系执行情况；
对违反质量管理规范的情况提出改进或否决意见；及时提交质量监控报告。
系统集成与实施组
项目相关硬件系统及网络方案确定； 项目相关硬件系统环境及网络环境的搭
建、调试；系统软件及所需工具的检查和安装；硬件系统的运行维护。
--- ----
业务组
了解用户需要；整理撰写目标系统说明书；参加需求评审，确认最终需求；制订项目目标及验收标准；组织系统验收过程，验收最终系统。
开发组
确认系统需求； 撰写开发方案及各设计文档； 根据编码规范， 对系统进行编码实现；对完成的模块采用白盒测试方法进行自测； 对提交测试组测试出的问题进行修改。开发组下设四个开发小组
1) 规划组：负责学校学生工作管理系统采购项目规划
2) 需求调研组：负责学校学生工作管理系统采购项目需求调研
3) 开发组：负责学校学生工作管理系统采购项目的开发
4) 测试组： 搭建测试环境，确定测试方案；撰写测试计划及测试用例；
对系统进行测试； 根据测试结果提交各问题表及测试报告； 对修改完成的版本进行回归测试。
培训组
进行用户培训。
支持服务组
对系统的软硬件运行进行维护； 对系统运行中的问题进行记录， 并转交开发组；对系统运行中产生的一般性故障进行维护。
5.2 风险管理
将项目实施过程中出现的风险包括已成功规避的风险都在项目结项时进行
总结并积累下来， 形成风险操作指南， 作为后期项目的一个参考。项目在立项阶
段制定该项目的《风险管理计划》 ，每个阶段都更新相应的《风险列表》 ，针对风
险列表中各风险进行风险的识别、分析和应对，有效规避风险。
风险识别
风险识别包含两方面内容： 识别哪能些风险可能影响项目进展及记录具体风
险的各方面特征。风险识别不是一次性行为，而应有规律的穿整个项目中。
--- ----
项目的有效沟通也是项目成败的关键， 通常项目过程中项目组成员之间或与客户之间一般都通过语言沟通交流， 领导和员工间通过开会布置任务， 容易造成文档、资料丢失和事后检查困难等。 针对这类问题，公司制定的《项目管理制度》中明确规定项目交流制度方式、时间、频度，包括项目过程中项目组与客户交流、部门之间交流、部门内部交流、项目组内部交流过程的规范，并要求在《项目总体计划》中确定下来，保证项目过程中沟通的规范性和有效性。 风险量化
风险量化涉及到对风险和风险之间相互作用的评估， 用这个评估分析项目可能的输出。这首先需要决定哪些风险值得反应。 风险由于包括诸多因素而较复杂，这里就部分因素列举如下：
风险对策研究
风险对策研究包括对机会的跟踪进度和对危机的对策的定义。 对危胁的对策大体分以下三点：
避免 -- 排除特定危胁往往靠排除危胁起源。 项目管理队伍绝不可能排除所有风险，但特定的风险事件往往是可以排除的。
减缓 -- 减少风险事件的预期资金投入来减低风险发生的概率， 以及减少风险事件的风险系数，或两者双管齐下。
吸纳 -- 接受一切后果。 这种接受可以是积极的 （如制定预防性计划来防备风险事件的发生），也可以是消极的。
--- ----
风险对策实施控制
风险对策实施控制包括实施风险管理方案以便在项目过程中对风险事件做
出回应。当变故发生时， 需要重复进行风险识别， 风险量化以及风险对策研究一
整套基本措施。就算最彻底和最复杂的分析也不可能准确识别所有风险以及其发
生概率，理解这一点是很重要的，因此控制和重复是必要的。
--- ----
5.3 质量保证
项目承建方质量方针
始终如一地从用户利益出发， 最大限度地优化从供应商到客户这一流程的所有重要环节，使用户利益最大化是项目承建方生存和发展的基本出发点。
持续改进是项目承建方每个员工的责任
项目承建方每一名员工都认识到质量对于项目成功的重要性， 质量是每一个人的责任，我们不断寻求更理想的提高质量的途径， 不断加强生产优质产品、提供卓越服务的主动精神、专业技能和生产过程能力。
质量保证活动
每个项目都有一个专职 QA对项目过程进行跟踪， 在项目立项阶段由 QA制定《质量保证计划》，并根据该计划对项目各过程进行跟踪，主要包括：
代表开发小组与用户进行访谈、交流，与用户之间的交流通道， 对项目组不能解决的问题以《 QA报告》的形式提交项目组。
组织并参与评价项目各阶段的评审
--- ----
跟踪项目需求， 重点监控项目过程变更的数量， 并填写相应记录表格； 监控贯穿于整个项目过程需求的一致性。
定期与用户进行沟通，进行用户满意度跟踪与调查
在项目需求确定后， 与项目承建商共同商定 《系统验收标准》 和客户测试的《测试方案》确认，保证测试过程目标明确性和有效性。
5.4 配置管理
软件配置管理是指对工作成果 （主要是代码和文档） 进行版本管理， 保证所有工作成果的完整性和跟踪性。
配置管理是对工作成果的一种有效保护。 整个机构应当统一使用配置管理软件（包括文档管理软件和代码管理软件） 。任何项目成员都必须对自己的工作成果进行配置管理。
软件配置管理的流程如图所示， 关键活动是 “制定配置管理计划”、“文档管理”和“代码管理” 。
配置管理需要记录每一配置对象的创建、变更及消亡情况。
配置管理员需要及时填写配置管理报告。
在任意配置对象出现变更时， 该对象必须做备份， 且该备份不能将原来的备份覆盖， 直至该配置对象被评审通过形成基线后， 可以只保留最近的备份。
在项目出现反复或失误时， 配置管理人员必须能以最快的速度拿出最近的回溯点版本。
配置管理员必须能够对每一次修改的主要责任人进行准确的定位， 同时也必须对每一次修改的根本原因有准确的了解， 必要时应能拿出充分的
--- ----
材料。
5.5 文档管理
项目文档管理包括规范相关文档管理和项目过程文档管理。
规范相关文档主要用于指导项目各阶段操作内容， 详细说明各阶段的主要任务及产生的阶段成果， 保证各项目都能够按照科学的有成功先例的项目模式执行。在项目立项阶段，该项目 QA会与项目负责人根据项目特点共同确定该项目所使用的规范，形成实施项目过程指导，作为该项目过程的执行规范；
项目过程文档指本项目在各阶段产生的阶段成果， 包括需求阶段的目标系统说明书、计划阶段产生的项目工作手册或项目总体计划、设计阶段产生的数据库设计说明书和设计文档等，保证下一阶段与上一阶段工作的延续性与一致性。
为避免出现项目过程中抛开文档， 自行开发，导致项目结束时才发现文档与系统根本不相关的现象， 项目承建方对项目过程中的文档管理采用一套完整的流程，有独立于项目组的 SCM（配置管理工程师）专职保证项目过程中能够提取出
的文档与目标系统是一致的。所有项目过程中的变更都必须经 SCCB审批后才能够进行变更，变更内容入库只有该项目 SCM才能够进入基线库进行更新， 而项目过程中的最终版本和项目验收标准版本都是从基线库中提取， 从而保证项目过程中文档与系统的一致性。
--- ----
5.6 测试管理
专门成立独立于开发的项目测试组， 由受过专业测试培训的人员组成， 保证测试过程的相对独立性， 也保证测试的有效性。 测试人员在项目立项阶段就会参与到项目中，保证了对项目需求的了解。
测试工作流程
测试方法采用白盒测试和黑盒测试相结合的方式， 测试过程分为业务模块测试、系统测试、整体测试，测试内容包括功能测试、可靠性、安全性、性能、可扩充性、可维护性、平台移植性、与其它系统的接口等测试，测试数据由测试人员通过撰写《测试用例》的方式进行准备，测试结果以《测试报告》的方式进行
--- ----
反馈。测试过程遵循公司 《测试流程规范》，保证测试过程所有问题的有效解决。
需求阶段测试流程
在项目需求确定后， 与项目承建商共同商定 《系统验收标准》 和客户测试的《测试方案》确认，保证测试过程目标明确性和有效性。
测试可以大致可以分为一下几类；单元 / 集成测试，系统测试，压力测试，性能测试。 --- ----
集成测试阶段流程 / 单元
系统测试阶段流程图
--- ----
压力测试流程
说明：压力测试为模拟用户正常使用时，系统正常工作的最小时间。
性能测试流程
说明：测试系统的崩溃极限（最多使用人数和数据库的极限容量）。
5.7 用户评价
本阶段由客户项目组成员完成，包括以下步骤：
设计用户接受程度测试的标准
测试队伍的培训
设计测试的文档和数据
进行用户接受测试， 允许用户评定交付的系统是否依据已达成协议的未
来的流程进行设置并执行完成的。 这个测试包括所有终端对终端的程序、
--- ----
在线业务流程、与其他系统的集成（如果有的话）等而不仅仅是系统本
身的测试。
5.8 项目验收
在项目试运行阶段接近结束时， 项目经理应提前准备发布正式版本，确保项
目验收前，客户现场所用版本为正式版本。 在试运行阶段结束后， 项目经理根据
客户方提出的验收标准（可包括：系统功能验证、性能测试以及培训效果测试等） ，
拟定验收方案并向客户方提出验收申请同时准备相关验收资料。
在验收方案经过客户方审核确认后， 由项目经理协助客户方依据验收方案进
行项目验收测试，并记录测试结果，同时将项目试运行记录整理后归档。
5.9 项目保障
高层领导的参与和支持
业务部门领导的支持
高效的项目实施组织
全面的知识培训
严格的项目管理（计划管理、项目组织、项目实施范围控制、报告和决
策机制）
定期的质量检查 基础数据规范和准确
专业资料 学习资料 教避免日常工作和本项目实施的冲突
育培训 考试 建筑装潢资料
---
第3篇：软件实施方案
一、软件项目实施方案概述软件产品，特别是行业解决方案软件产品不同于一般的商品，用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容，每个阶段下面有不同的工作事项，各个阶段之间都是承上启下关系，上一阶段的顺利完成是保证下一阶段的工作开展的基础。
下面将按照每个项目实施阶段分别介绍。
二、软件项目实施方案介绍 （一）项目启动阶段
此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。
此阶段主任务：
公司：
在合同签定后，指定项目经理，成立项目组，授权项目组织完成项目目标。
公司项目组：进行前期项目调研，与用户共同成立项目实施组织，编制《总体项目计划》，召开项目启动会。
商务经理：
配合公司项目组，将积累的项目和用户信息转交给项目组。将项目组正式介绍给用户，配合项目组建立与用户的联系。
用户：
成立项目实施组织，配合前期调研和召开启动会，签署《总体项目计划》和《项目实施协议》。
1、成立项目组：
部门经理接到实施申请后，任命项目经理，指定项目目标，由部门经理及项目经理一起指定项目组成员及成员任务，并报总经理签署《项目任务书》。
2、前期调研：
项目经理及项目组成员，在商务人员配合下，建立与用户的联系，对合同、用户进行调研。填写《用户及合同信息表》。在项目商务谈判中，商务经理积累了大量的信息，项目组首先应收集商务和合同信息，并与商务经理一起识别那些个体和组织是项目的干系人，确定他们的需求和期望，如何满足和影响这些需求、期望以确保项目能够成功。
3、编制《项目总体计划》： 《项目总体计划》是一个文件或文件的集合，随着项目信息不断丰富和变化，会被不断变更，主要介绍项目目标、主要项目阶段、里程碑、可交付成果。通常包括以下几方面内容：项目描述，项目目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配（包括用户的）；沟通管理计划，确定项目干系人对信息和沟通的需要：即什么人何时需要什么信息以及通过什么方式将信息提供给他们。质量管理计划，确定适合于项目的质量标准和如何满足其要求。如果有必要，可以包括上述每一个计划，详细程度根据每个具体项目的要求而定。未解决事宜和未定的决策
4、启动会：
项目组与用户共同召开的宣布项目实施正式开始的会议。
会程安排如下：
共同组建项目实施组织，实施组织的权利和职责；双方签署《项目实施协议》。
项目组介绍《项目总体计划》和《项目实施协议》，包括以下内容：
项目目标、主要项目阶段、里程碑、可交付成果。所计划的职责分配（包括用户的）；
项目实施中项目管理的必要性和如何进行项目管理，项目的质量如何控制；
项目实施中用户的参与和领导的支持的重要作用；
阶段验收、技术交接和项目结束后如何对用户提供后续服务。
（二）需求调研确认阶段
此阶段的主要工作是软件公司的项目实施人员向用户调查用户对系统的需求，包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等，实施人员调研完成后，会编写《需求调研分析手册》，并交付用户进行确认，待用户对《需求调研分析手册》上所提到的需求确认完毕后，项目实施人员将以此为依据进行软件功能的实现。如果用户又提出新的需求，实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。需求调研阶段具体包括如下内容：
1、进行需求调研准备 2、编制《需求调研计划》
3、内部评审是否通过《需求调研计划》
项目组、部门经理、商务等人员根据合同要求和项目实际情况对《需求调研计划》草稿进行评审，如评审通过，则在稍后的时间内签署，如评审不通过则重新修改。
4、用户是否签署《需求调研计划》 如用户签署《需求调研计划》，则作为以后需求调研工作的指南。否则重新修改。 5、《需求调研计划》是否有变更
如果计划存在变更，则执行变更控制流程，否则按计划进行后续工作。
6、编写及发出《需求调研通知》 项目组编写《需求调研通知》，确定进行需求调研的相关事宜，发给用户，为顺利完成需求调研工作做准备
7、需求调研
项目组以《需求调研手册》为依据，从业务流程、单据使用、打印格式、报表查询几个方面展开深入和全面的调研，并搜集用户的个性化需求。
8、需求调研分析根据调研的结果
项目组和公司其他技术部门将进一步进行分析，确定合理、可行的需求，将分析结果形成《需求分析报告》草稿。
9、内部评审是否通过《需求分析报告》
项目组、部门经理、公司其他技术部门的人员对《需求分析报告》草稿进行评审，如评审通过，则在稍后由用户签署，如评审不通过则重新修改，直至内部评审通过。
10、编写及发出《需求分析报告确认通知》 项目组编写《需求分析报告确认通知》，发给用户，确定进行需求确认的相关事宜，告之相关部门及人员安排好工作，准时参与需求确认工作，为顺利完成需求确认工作做准备。
11、用户是否确认《需求分析报告》
如果用户确认，并签署了《需求分析报告》，则需求调研阶段工作结束，进行后续的软件功能实现的工作；如没有确认，则进一步进行调研、分析，直至用户最终确认并签署《需求分析报告》。双方签署了《需求分析报告》，需求调研工作结束之后，如果用户提出新的需求或是变更已有的需求，则执行需求新增及变更流程。
（三）软件功能实现确认阶段
此阶段的主要工作是项目实施人员根据需求调研阶段确认的《需求调研分析手册》中的用户需求内容进行具体软件功能的实现工作。在软件功能实现的过程中，项目实施人员将记录软件实现的详细过程。便于公司售后服务之用。每一个实施技术人员必须严格按照要求记录、存档。按照调研要求的所有功能实现完毕后，项目实施人员将编制《软件功能确认表》，将定制好软件功能待用户确认，用户根据《软件功能确认表》上的功能逐一确定软件功能是否达到要求，对不满足要求的功能，项目实施人员将会记录下来并进行功能修改，直到满足用于要求。
（四）数据标准化初装阶段
此阶段的主要工作是项目实施人员指导用户进行系统标准化资料的准备工作，并对用户进行初装资料的软件操作培训，以便用户能够及时的将标准资料录入系统，初装完成后，项目实施人员会对资料初装的情况进行核查，为以后具体业务功能的开展做好基础。
（五）系统培训阶段
系统培训阶段工作是整个项目实施工作中比较重要的工作，用户对软件的操作功能是否熟练将直接影响到后面的软件应用效果，所以软件公司和用户双方要对此阶段的工作给予足够的重视。要充分认识培训的重要性和艰巨性。在项目实施之前对用户的相关人员进行系统和规范的产品培训是非常必要的，达到让用户了解软件产品，最终自己能够解决使用中的具体的问题。
此阶段的培训工作中将用户参加产品培训的人员划分为三个层次：决策层、技术层、操作层，对不同层次的用户参加产品培训人员的培训内容分别是：
决策层：领导在实施中的作用与重要性、决策查询。
维护层：系统维护知识、操作方法。
操作层：操作方法。
具体的培训工作流程为：
1、调研培训信息：
在培训开始前3天由用户实施负责人，将参加培训的部门和人员情况填入《受训部门汇总表》、《受训人员情况一览表》。
2、编制培训计划： 结合调研结果，与用户实施负责人商议具体培训内容、时间，场地，人员等。项目组编制《培训计划》。
3、签署培训计划： 用户签署《培训计划》，进一步确认培训安排。
4、发培训通知：
培训开始前2天，按照签署的《培训计划》，将培训内容、时间，场地，人员等信息通知用户实施负责人。
5、搭建培训环境：
公司项目组在培训开始前，将培训环境搭建及检查妥当，将培训提纲及培训手册准备好。
6、组织培训：
公司项目组培训负责人与用户实施负责人组织相关人员参加培训，按培训制度严格考核。由用户将考勤情况填入《培训人员签到表》。
7、培训考核：
公司项目组培训负责人与用户实施负责人组织受训人员参加上机及理论考试。
8、培训总结： 公司项目组培训负责人与用户实施负责人一起将出勤情况及考核情况做出总结，填入《培训及考核统计表》，及时向相关负责人汇报。
（六）系统安装测试及试运行阶段
此阶段的主要工作是在用户真实环境下，对用户网络及硬件设备进行测试，对软件系统进行容量、性能压力等测试测试及试运行的目的在于确保系统各项功能均能正常使用，并且符合用户签署的《需求分析报告》中描述的需求，同时把尽可能多的潜在问题在正式运行之前发现并改正；同时目的还在于在正式运行前用户的有关人员能进一步提高操作水平，掌握操作规范。此阶段的主要工作内容为：
１、编制计划：
与用户实施负责人商议具体测试及试运行时间，地点，人员等安 排，项目组编制《测试及试运行计划》。
2、签署计划：
用户签署《测试及试运行计划》，进一步确认测试及试运行安排。
3、发测试及试运行通知：
在测试及试运行开始前2天，按照签署的《测试及试运行计划》，将时间，地点，人员等信息通知用户实施负责人。
4、搭建环境及数据准备：
在试运行开始前搭建好软件环境、硬件环境、网络环境、调通线路；检查软件、硬件、网络、线路等各个环节是否有问题；
5、组织测试及试运行：
用户相关各级领导给予全面配合，组织相关人员进行测试及试运行。公司项目组负责担当指挥，检查用户人员组织情况并给予指导，跟踪检查如下情况：
l
跟踪单据流转状况。
l
跟踪新资料登录环节。
l
观察业务流程执行状况。
l
观察操作人员操作表现。
l
观察系统运行速度及异常表现。
l
观察关键数据的正确性。
l
及时纠正错误操作、对于新发生的问题及时与相关人员沟通，确定解决办法。
6、测试及试运行总结： 测试及试运行完成，总结试运行中设备、软件的运行情况，总结试运行中业务流程和操作环节的情况，以书面总结形式将测试及试运行结果通知相关负责人。
（七）总体验收阶段
此阶段是对项目总体的完成情况进行验收。验收分阶段进行，在每一项目阶段结束时，用户对这一阶段的可交付成果进行验收，在测试及试运行结束后，对系统进行总体验收。
需要验收的可交付成果：
主要项目阶段
阶段组成
主要里程碑
可交付成果
启动阶段
编制总体项目计划
签署的《总体项目计划》
启动会
项目启动会
签署的《项目实施协议》
需求调研阶段 需求分析报告确认
需求调研结束 签署的《需求分析报告》
软件实现
软件功能确认
软件功能确认 签署的《软件功能确认表》
数据初装
用户签署初装计划及初装培训计划
签署的《初装计划及初装培训计划》
初装检查及总结
数据初装完成
《数据初装总结表》
培训及考核
用户签署培训计划
签署的《培训计划》
培训总结
培训完成
《培训总结表》
测试及试运行
用户签署测试及试运行计划
签署的《测试及试运行计划》
测试及试运行总结
试运行完成
《测试及试运行总结》
验收
总体验收
验收完成
《总体验收报告》
（八）系统交接阶段
此阶段是项目实施的最后一个阶段，主要工作是软件公司项目组向用户移交软件项目，包括软件产品、项目实施过程中所生成的各种文档，并签署《售后服务协议》，项目将进入售后服务阶段。软件公司项目组还需要让用户填写《用户满意度调查表》，对软件公司项目实施人员的整个项目实施情况进行评价，软件公司将听取用户的意见，再今后的项目实施管理中进行加强和改进。
三、软件实施的成功之道
（一）软件必须能满足和适应企业需求
这一点是整个项目能否成功实施的最关键的一环。很多企业都在这一方面吃过亏，在选型时见到的软件有很多功能模块，在样板企业里数据也能跑起来，但当软件买回来了以后，却发现了软件的很多功能与企业的现实差别很大，所以根本就用不起来。不同企业之间的管理流程和对数据的要求差别很大，基本上两个完全相同的企业是不存在的，世界上绝对不会有一种“万能软件”能满足所有企业的需求。企业在选型软件时，要充分考虑各种管理流程的特点、数据的来源、统计报表不同功能模块的关系、企业员工的接受能力及与其它系统的接口等很多问题，所以企业选择的必须是软件提供商为企业订制开发出来的。如果软件提供商不为企业做前期需求分析和订制开发，只是把现成的软件卖给企业，它的实施成功率几乎为零，如果是这样的服务，企业还不如买一套盗版软件 。所以我们可以得出这样的结论，企业买软件提供商的不是它的软件，而是它的开发能力。
（二）软件是否能进行二次开发
因为企业现有的流程不是一成不变的，需不断完善与改进，所以软件的功能也需要能进行相应的修改，而且企业在第一次做项目需求时，有些问题可能忽略掉了，所以必须要求选型的软件有强大的二次开发能力。如果软件的结构过于僵死或二次开发能力不强，它未来可能会变成一块“鸡肋”，让企业有种“食之无味、弃之可惜”的感觉。测试软件是否具有快速二次开发能力的方法也不难，就是企业在选型时，不仅要看软件提供商如何演示，还要提出一些个性化需求，看看对方能否迅速开发出来。
（三）软件和实施费用应相对便宜
企业第一次实施由于经验上的不足，风险不是没有，确实有许多优秀的企业是通过第二次实施才获得了成功。因此企业在第一次选型软件时，不要只注意软件提供商的品牌和规模，因为价格越高，企业自身的风险就越高。我们建议企业最好还是购买那些物美价廉的产品，也就是当所选软件都能满足企业现实需求且能进行二次开发时，企业最好选择价格便宜的那家，就好像一个人刚学会开车，就要买一辆奔驰轿车，无论这个人是否真正有钱都不是明智的选择。现在出现了平台化组构的软件产品，它可以通过建模工具迅速按照客户的需求进行软件开发，这样就大量地节约软件开发周期和成本，而且二次开发工作也变得十分的简单，所以企业最好选择这样的产品。
（四）软件操作要简单、易学
由于许多企业过去没有信息化建设的经验，员工一下子由过去的手工工作转为计算机工作肯定有一个适应过程，如软件组构和操作过于复杂，那么一定会加大培训和实施的难度。
四、数据整合项目实施的成功之道 案例1：麦德龙
到麦德龙购物的消费者都知道要带一张会员卡，但对会员卡有什么作用几乎都不知晓。其实，会员卡最大的收益者是麦德龙。当消费者用会员卡结账时，便留下了详细的消费档案。据麦德龙中国公司总经理海力佛介绍，公司的专门网络每天都要对这些数据进行整合分析，不仅分析商品热销、滞销情况，还要分析目标客户的购买力，由此决定大类商品，乃至细目商品的结构调整，以及促销方式的变化。
案例2：中石化
中石化于2000年初开始制定中国石化ERP总体规划，努力构架从上到下、集成一体化的中国石化ERP系统的推进策略。目前，中石化集团已经完成近70%的ERP系统实施工作。2004年年底，中海油宣布集团整体实施SAP ERP系统项目正式启动。近期，很早就提出信息化建设“六统一”的中石油集团也开始了ERP系统的招标工作。由此可以看出，中国三大石油巨头已经对管理信息化有了更深层的理解和更为迫切的需求，建立与完善各自管理信息化系统的工作正在轰轰烈烈、有条不紊的进行中。
无论是案例中的麦德龙还是三大石油巨头，亦或是其他一些公司，他们其实都在不约而同地做着同样一件事情，那就是信息整合。众多企业之所以热衷于此并非盲目追随潮流，而是缘于整合信息、消除“信息孤岛”的迫切需要。这种需要的存在是出于信息传递系统对于现代公司获得生存发展的极大重要性。信息不充分导致的信息经济学所关注的逆向选择、柠檬市场等问题，在企业内部就会表现为治理机制失调、管理混乱、决策空虚。曾有人把企业的信息流比喻为人的神经系统，那么不难想象如果“神经系统”处于瘫痪，公司的生存发展将会何等艰难。
既然市场有如此强烈的需求，那么信息应用技术的提供者们自然不会视机会如浮云，必将开发相应的应用软件系统来迎合市场。一时间，各种系统层出不穷，技术手段也日渐纯青。一方面是企业的苦苦诉求，一方面是信息技术供应商的殷殷回应，似乎信息整合已经万事俱备，剩余的工作就是顺利地将信息整合工作付与实施了。
然而，也就是这个看似最简单的环节，却同时给企业和项目实施团队带来了诸多的烦恼。同时，也导致了信息整合的成功似乎近在眼前，却又远在天涯。据国家经贸委经济信息中心和每周电脑报社对近800家企业所做的调查结果显示，近50%的企业称信息整合化效果不明显。
那么，究竟在实施过程中出现了什么问题，让信息整合一而再、再而三的止步于最后关口？
在此，依据我们以往信息整合实施的经验来看，失败多因在经营分析、对标、数据整合三个环节存在问题甚至缺失导致，本文将从数据整合的角度展开分析，列举在实施过程中经常遇到的三个数据实施的问题，并提出我们对问题的分析与解决问题的思路，希望关切这个领域的同仁们可以共同思考。
（一）、企业内部管理粗放，造成基础数据难以寻获，从而导致实施在开始阶段就举步艰难。 1、问题陈述
对于任何一种版本的信息整合系统，在项目实施的第一阶段（系统实现阶段）都要进行基础数据的录入工作。然而，项目实施方也往往从这个阶段开始就要接受挑战了。相信有过整合实施经历的读者对以下两个事例并不陌生，因为它们在项目实施中非常普遍。
例1：在对生产型企业进行系统实施时，必然要涉及到设备编码数据的录入。然而，许多企业并没有对他们的设备进行统计编码，那么项目实施方则很难进行下一步的工作。
例2：任何系统实施中都首先要对不同使用者设立不同的权限，这就需要企业的人力资源部门向项目实施方提供完整的员工岗位分配表、岗位说明书与职责说明书。而当项目实施方要求企业递送这些文件的时候，人力资源部的回答往往是“我们没有这些东西，给你们一张员工工资表，将就用吧”。这样一来，系统权限的设置必将混乱，也势必影响到系统应用的最终效果。
像上面这种例子在实施项目中还有很多很多。其实，它们反映了同一个问题，即准备录入的基础数据难以获寻的问题。搜寻不到基础数据，实施的第一步工作就无法得到开展，项目也从一开始就被笼罩上了失败的阴影。
2、问题分析
问题总是表面化的，如同冰山一角，其背后的产生原因才是深层次的。这一问题其实是企业管理不细致的表现，根源在于企业在发展过程中忽视了管理模式的更新与细化，没有形成制度化、标准化的管理模式。
当企业规模小的时候，管理和经营往往依靠领导人的个人能力。大部分日常管理工作是对已经出现的问题进行解决。而当企业规模壮大以后，管理层往往仍然延续旧有的管理思想与习惯。我们不难想象用管理十几个人的方法和手段来管理上百人、上千人的企业会出现怎样的后果。这种管理落后会表现在企业运营的各个方面，而基础数据不完善就是其表现之一。
3、解决思路
①项目实施方通过事实陈述、案例分析等方式向企业高层表明企业目前存在的问题及危害性。
②向企业高层推荐相关培训课程，建议企业聘请专业咨询公司。
（二）、企业管理流程混乱和监督机制不完善，造成基础数据不统一，从而导致实施止步不前
1、问题陈述
同样是在数据录入阶段，实施团队除了面临基础数据不全的困难以外，还往往会碰到另一类的问题。这类问题出现在基础数据的获得渠道上。在信息整合实施过程中，项目组获得基础数据的途径只能是企业内部的各种报表。然而，当这些报表递送到实施团队手中时，项目人员却经常会发现同一个数据在不同的报表中显示的结果却不尽相同。不妨先看一看下面两个事例。
例1 ：同样是A部门的年度销售额这一个数据，实施项目组却看到了三个不同的结果：在A部门递交的年度业绩考核表中是年度销售额为510万，在公司纳税统计报表中年度销售额为500万，而在下一年度部门销售目标分析报表中该数据显示的则是490万。
例2：同样是员工人数这个数据，在递交给劳动管理部门的报表中是50人，而在工资发放表中却是60人。
我们可以想象，当项目组面对以上所列述的这样的报表时，只能是一脸茫然。系统实施的第一步也再一次的面临到挫折。而这些问题都可以总结为一类，即基础数据不统一。
2、问题分析
这一问题的产生主要有两个方面的原因。
其一，是由于企业各种报表统计用途的不一致造成的。由于统计用途的不同，最基层的原始数据往往在传达过程中被各职能部门或各管理层级进行人为的修改。比如，在以上所提及的销售额不一致的情况中，可能就是因为A部门人员在考虑到不同报表用途的情况下为了自身利益而相应改动原始数据所造成的。这反映了企业的考核监督机制存在漏洞，内部审计虚空，为基层人员提供了“胡作非为”的可行性。
其二，是由于数据统计口径的不一致造成的。不同职能部门在统计同一数据时的统计口径存在差异，比如在以上所提及的员工人数不一致的情况中，可能就是因为递送工资发放表的财务部门将包含临时员工在内的所有领取公司报酬的全部人员进行了统计，而递送劳动管理部门报表的人力部门则只统计了合同员工。这种情况的存在主要是因为企业报表管理体系的不完善，没有对不同报表的口径进行统一和明确说明，报表体系混乱。而报表体系的混乱则反映了公司内部管理流程的混乱。
3、解决思路
①实施项目组尽量从企业最基层的业务一线获得企业的基础数据，避免基础数据在上传过程中出现人为操作。
②实施项目组可以建议企业方聘请专业咨询公司，让其为企业在项目实施之前梳理经营管理流程，完善监督考核机制。
（三）、最根本的原因是，企业高层对项目认识不足与企业内部上下层存在利益博弈，造成项目实施方难以获得企业各方的配合，导致实施进展缓慢 1、问题陈述
实施信息整合系统需要实施项目组对企业有较为全面的了解。这种了解需要建立在与企业高层以及中下层员工之间良好的沟通之上。而且项目的实施过程中，数据的获得等工作也只能在企业员工密切配合的前提下才能得以顺利完成。而做过该类项目的朋友一定碰到过这样的情况：
例1：项目组希望约见企业的高层领导进一步了解企业情况，却总是因为领导忙、没有时间的理由被拒绝。
例2：项目组需要职能部门提供各种数据资料，面对的却是员工的一片漠然，迟迟得不到所需要的资料。
这种情况在信息整合实施项目中的普遍存在，导致了项目组的工作难于开展，项目实施举步维艰。
2、问题分析
我们可以将这个问题的分析分解为两个层面：第一个层面，是企业高层为什么不配合；第二个层面，是企业中下层员工为什么不配合。
对于企业高层而言，他们是希望项目能够得到顺利实施的。既然如此，他们又为什么不配合项目组的工作呢？其实，这主要缘于企业高层对项目实施认识的偏差。对于很多企业高层而言，他们的观点是“我花钱请你们来，所有的事情都是你们的，我只要坐收成果就好了”。
而对于企业中下层员工而言，他们不配合就主要是因为利益博弈的结果了。由于信息整合项目的最大初衷就是为了给管理高层提供管理与决策的信息支持，
因此项目的最终受益者往往是公司的高层管理者。而中下层员工很难在信息整合中获得利益，并且因为整合项目的实施，许多中下层员工的工作量反而有所增加，或者利益受到损害。比如，财务部门以往可能只递送3张财务大表，而因为信息整合项目实施的需要，他们可能要递送更多的附表。这些附表数据在录入系统后会更有力的支持高层决策。但对于财务部门的员工而言，这只是增加了他们的日常工作量，并无其他任何意义。再比如，系统实现后，销售利润等分析数据全部由系统根据一线数据源自动生成，职能部门或各级管理层失去了人为操作数据的可能性，可能就会对其利益造成损害。因此，企业上下层级之间的利益博弈，导致了不同人员对待项目态度的迥异，也导致了基层人员对项目的抵抗心理。
3、解决思路
① 项目组通过开展三个方面的工作获得企业高层领导的配合。
A.
项目实施方利用企业高层对项目结果的强烈需求，在项目实施计划确定阶段，就向企业高层清楚地表达企业的合作对项目实施的重要意义。并且，可以建议他们参加相关培训。
B.
项目实施方在合同中明确要求企业高层组建内部项目组配合项目的实施，并对内部项目组给与充分的授权。
C.
根据项目的具体内容，由实施项目组与企业内部项目组制定绩效考核标准，提交企业高层报批。以此保障实施项目组能够得到各职能部门与各级管理层的积极支持。
② 建立由系统供应商、实施方、企业内部项目组以及咨询方参与的定期例会制度。项目相关方密切配合，充分了解企业的各个流程，把握各职能部门间、各管理层级间的利益差异。进而，尽量在技术上为企业的各种人员提供各自不同的价值点。
第4篇：软件实施方案
软件实施方案范文
【篇1：2011年软件项目实施方案范文】
一、项目实施方案概述.
1二、项目实施方案介绍.
2（一）项目启动阶段...2
（二）需求调研确认阶段...3
（三）软件功能实现确认阶段...
5（四）数据标准化初装阶段...5
（五）系统培训阶段...6
（六）系统安装测试及试运行阶段...7
（七）总体验收阶段...8
（八）系统交接阶段...9
一、项目实施方案概述
软件产品，特别是行业解决方案软件产品不同于一般的商品，用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操 作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。大量的软件公司项目实施 案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果 也对后期用户应用的情况起到非常重要的影响。项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训 阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容，每个阶段下面有不同的工作事项，各个阶段之间都是承上启下关系，上一阶 段的顺利完成是保证下一阶段的工作开展的基础。下面将按照每个项目实施阶段分别介绍。
《软件实施方案(共7篇)》相关文档：
幼儿园预防近视实施方案09-02
学生劳动教育实施方案范文（精选5篇）09-02
劳动教育课程实施方案范文（通用7篇）09-03
劳动教育课程实施方案范文（通用7篇）09-02
劳动教育的实施方案范文（通用6篇）09-03
劳动实践课程实施方案范文（通用5篇）09-02
幼儿园健康活动策划实施方案7篇09-04
集体林权制度改革实施方案09-05
中班社会领域活动方案实施方案5篇09-05
