软件开发项目实施方案.docx
《软件开发项目实施方案.docx》由会员分享，可在线阅读，更多相关《软件开发项目实施方案.docx（11页珍藏版）》请在冰豆网上搜索。
软件开发项目实施方案
软件开发项目实施方案
篇一：
软件项目实施方案范文
一、软件项目实施方案概述
软件产品，特别是行业解决方案软件产品不同于一般的商品，用户购买软件产品之后，不能立即进行使用，需要软件公司的技术人员在软件技术、软件功能、软件操作等方面进行系统调试、软件功能实现、人员培训、软件上线使用、后期维护等一系列的工作，我们将这一系列的工作称为软件项目实施。
大量的软件公司项目实施案例证明，软件项目是否成功、用户的软件使用情况是否顺利、是否提高了用户的工作效率和管理水平，不仅取决于软件产品本身的质量，软件项目实施的质量效果也对后期用户应用的情况起到非常重要的影响。
项目实施规范主要包括项目启动阶段、需求调研确认阶段、软件功能实现确认阶段、数据标准化初装阶段、系统培训阶段、系统安装测试及试运行阶段、总体验收阶段、系统交接阶段等八个阶段工作内容，每个阶段下面有不同的工作事项，各个阶段之间都是承上启下关系，上一阶段的顺利完成是保证下一阶段的工作开展的基础。
下面将按照每个项目实施阶段分别介绍。
二、软件项目实施方案介绍
（一）项目启动阶段
此阶段处于整个项目实施工作的最前期，由成立项目组、前期调研、编制总体项目计划、启动会四个阶段组成。
此阶段主任务：
公司：
在合同签定后，指定项目经理，成立项目组，授权项目组织完成项目目标。
公司项目组：
进行前期项目调研，与用户共同成立项目实施组织，编制《总体项目计划》，召开项目启动会。
商务经理：
配合公司项目组，将积累的项目和用户信息转交给项目组。
将项目组正式介绍给用户，配合项目组建立与用户的联系。
用户：
成立项目实施组织，配合前期调研和召开启动会，签署《总体项目计划》和《项目实施协议》。
1、成立项目组：
部门经理接到实施申请后，任命项目经理，指定项目目标，由部门经理及项目经理一起指定项目组成员及成员任务，并报总经理签署《项目任务书》。
2、前期调研：
项目经理及项目组成员，在商务人员配合下，建立与用户的联系，对合同、用户进行调研。
填写《用户及合同信息表》。
在项目商务谈判中，商务经理积累了大量的信息，项目组首先应收集商务和合同信息，并与商务经理一起识别那些个体和组织是项目的干系人，确定他们的需求和期望，如何满足和影响这些需求、期望以确保项目能够成功。
3、编制《项目总体计划》：
《项目总体计划》是一个文件或文件的集合，随着项目信息不断丰富和变化，会被不断变更，主要介绍项目目标、主要项目阶段、里程碑、可交付成果。
通常包括以下几方面内容：
项目描述，项目目标、主要项目阶段、里程碑、可交付成果。
所计划的职责分配（包括用户的）；沟通管理计划，确定项目干系人对信息和沟通的需要：
即什么人何时需要什么信息以及通过什么方式将信息提供给他们。
质量管理计划，确定适合于项目的质量标准和如何满足其要求。
如果有必要，可以包括上述每一个计划，详细程度根据每个具体项目的要求而定。
未解决事宜和未定的决策
4、启动会：
项目组与用户共同召开的宣布项目实施正式开始的会议。
会程安排如下：
共同组建项目实施组织，实施组织的权利和职责；双方签署《项目实施协议》。
项目组介绍《项目总体计划》和《项目实施协议》，包括以下内容：
项目目标、主要项目阶段、里程碑、可交付成果。
所计划的职责分配（包括用户的）；
项目实施中项目管理的必要性和如何进行项目管理，项目的质量如何控制；项目实施中用户的参与和领导的支持的重要作用；
阶段验收、技术交接和项目结束后如何对用户提供后续服务。
（二）需求调研确认阶段
此阶段的主要工作是软件公司的项目实施人员向用户调查用户对系统的需求，包括管理流程调研、功能需求调研、报表要求调研、查询需求调研等，实施人员调研完成后，会编写《需求调研分析手册》，并交付用户进行确认，待用户对《需求调研分析手册》上所提到的需求确认完毕后，项目实施人员将以此为依据进行软件功能的实现。
如果用户又提出新的需求，实施人员将分析需求的难度及对整个系统的影响程度来确定是否给予实现。
需求调研阶段具体包括如下内容：
1、进行需求调研准备
2、编制《需求调研计划》
3、内部评审是否通过《需求调研计划》
项目组、部门经理、商务等人员根据合同要求和项目实际情况对《需求调研计划》草稿进行评审，如评审通过，则在稍后的时间内签署，如评审不通过则重新修改。
4、用户是否签署《需求调研计划》
如用户签署《需求调研计划》，则作为以后需求调研工作的指南。
否则重新修改。
5、《需求调研计划》是否有变更
如果计划存在变更，则执行变更控制流程，否则按计划进行后续工作。
6、编写及发出《需求调研通知》
项目组编写《需求调研通知》，确定进行需求调研的相关事宜，发给用户，为顺利完成需求调研工作做准备
7、需求调研
项目组以《需求调研手册》为依据，从业务流程、单据使用、打印格式、报表查询几个方面展开深入和全面的调研，并搜集用户的个性化需求。
8、需求调研分析根据调研的结果
项目组和公司其他技术部门将进一步进行分析，确定合理、可行的需求，将分析结果形成《需求分析报告》草稿。
9、内部评审是否通过《需求分析报告》
项目组、部门经理、公司其他技术部门的人员对《需求分析报告》草稿进行评审，如评审通过，则在稍后由用户签署，如评审不通过则重新修改，直至内部评审通过。
10、编写及发出《需求分析报告确认通知》
项目组编写《需求分析报告确认通知》，发给用户，确定进行需求确认的相关事宜，告之相关部门及人员安排好工作，准时参与需求确认工作，为顺利完成需求确认工作做准备。
11、用户是否确认《需求分析报告》
如果用户确认，并签署了《需求分析报告》，则需求调研阶段工作结束，进行后续的软件功能实现的工作；如没有确认，则进一步进行调研、分析，直至用户最终确认并签署《需求分析报告》。
双方签署了《需求分析报告》，需求调研工作结束之后，如果用户提出新的需求或是变更已有的需求，则执行需求新增及变更流程。
（三）软件功能实现确认阶段
此阶段的主要工作是项目实施人员根据需求调研阶段确认的《需求调研分析手册》中的用户需求内容进行具体软件功能的实现工作。
在软件功能实现的过程中，项目实施人员将记录软件实现的详细过程。
便于公司售后服务之用。
每一个实施技术人员必须严格按照要求记录、存档。
按照调研要求的所有功能实现完毕后，项目实施人员将编制《软件功能确认表》，将定制好软件功能待用户确认，用户根据《软件功能确认表》上的功能逐一确定软件功能是否达到要求，对不满足要求的功能，项目实施人员将会记录下来并进行功能修改，直到满足用于要求。
（四）数据标准化初装阶段
此阶段的主要工作是项目实施人员指导用户进行系统标准化资料的准备工作，并对用户进行初装资料的软件操作培训，以便用户能够及时的将标准资料录入系统，初装完成后，项目实施人员会对资料初装的情况进行核查，为以后具体业务功能的开展做好基础。
（五）系统培训阶段
系统培训阶段工作是整个项目实施工作中比较重要的工作，用户对软件的操作功能是否熟练将直接影响到后面的软件应用效果，所以软件公司和用户双方要对此阶段的工作给予足够的重视。
要充分认识培训的重要性和艰巨性。
在项目实施之前对用户的相关人员进行系统和规范的产品培训是非常必要的，达到让用户了解软件产品，最终自己能够解决使用中的具体的问题。
此阶段的培训工作中将用户参加产品培训的人员划分为三个层次：
决策层、技术层、操作层，对不同层次的用户参加产品培训人员的培训内容分别是：
决策层：
领导在实施中的作用与重要性、决策查询。
维护层：
系统维护知识、操作方法。
操作层：
操作方法。
具体的培训工作流程为：
1、调研培训信息：
篇二：
通用软件研发项目实施方案
1软件系统架构设计
1.1概要说明
系统架构主要包括应用架构和技术架构。
系统采用基于组件的标准SOA应用架构，以及按照SOA方法构建的技术架构。
系统的应用架构采用了基于服务的体系架构的策略与方法，从组件、子系统以及门户三个层次对系统进行构建，组件组装形成子系统，子系统集成形成门户。
门户为人员等提供一个优化的以人为中心的操作界面，用户可以方便地对ERP的整个生命周期进行管理；同时系统管理维护人员也可以方便地通过系统对系统进行监控和管理。
系统的技术架构同样也是基于SOA方法和策略进行构建的，它支持客户端和服务器端同步和异步的两种不同的通信方式，web层和服务层进行相对分离，支持分布式和集中式部署两种方案，并且不局限于某一种应用服务器和数据库服务器产品。
1.2系统特点
1.2.1根据优化流程开发
根据流程特点进行功能设计，采用先进的工作流引擎机制。
保证了业务功能的实现。
同时达到了灵活配置。
松散耦合的目的。
保证系统能够与原系统灵活切换。
符合以“软件生命周期为主线“的高效处理流程。
使统一设计，灵活接口。
1.2.2充分利用现有资源
充分考虑现有硬件分散、系统相对独立、数据库数据分离的现状。
采用分布式部署，统一数据规范、统一接口规范的设计思路，在保证系统功能灵活配置，满足业务需求的前提下，充分利用现有数据及硬件资源。
1.2.3先进的设计理念
采用国际通用的C#语言开发，海量数据库选型、高效稳定的中间件处理。
先进的SOA架构设计，满足现有的性能需求，做到架构和系统的先进性和强大的扩展能力。
采用先进的Web2.0技术，做到界面简洁、易用。
1.2.4开放式的可扩展性
系统分部署式部署，子系统统一规划，即满足了分布应用的要求，又实现了统一标准。
形成了统一、强大的管理软件工作平台。
1.2.5与现有系统轻松衔接
设计时充分考虑现有系统现状，开发过程和现有系统数据、应用分析同步进行，保证新系统与现有系统顺利衔接。
1.2.6可信赖的高可靠性
考虑到实时运行，提供业务流程对可靠性的较高要求，在系统设计中充分考虑了减少和避免故障的可能和隐患，配合合理的系统部署方式和高效的维护服务，能够满足需求中对系统故障时间、修复时间和单点故障隐患的可靠性要求。
1.3总体体系架构
1.3.1基于组件的SOA系统应用架构
系统的应用架构是系统进行构建的主要思路和方法，我们建议ERP系统采用基于组件的SOA的系统应用架构对系统进行构建。
系统按照SOA的方法把系统从总体上划分为3个层次，分为：
组件层、系统层、集成层。
a）组件层：
组件层主要包括系统开发需要用到得各种组件，又可以分为横向通用组件、
纵向通用组件和纵向专用组件。
横向组件是大部分系统都需要用到的通用的组件，如：
Web组件、日志管理、数据校验、邮件管理、打印组件、报表组件、文档管理、参数管理、单点登陆等，横向组件的作用是更好的管理和复用系统的通用组件；纵向通用组件包括在领域应用中通用的组件，如：
工作流、报表工具、规则引擎、用户权限管理等在领域应用中使用较为广泛；纵向专用组件是针对每一个领域专用的具有领域特色的组件，在ERP系统中纵向专用组件可以分为申请、受理、收费组件、分类组件、保密组件等等有关于ERP的组件；
b）系统层：
系统层包括了有组件组装得到的各个应用系统，又可以分为核心层、综合
业务层和辅助管理层。
核心层是整个系统的重点和难点，是整个系统最重要的组成部分，如销售子系统是将申请人的申请进行接受和汇总子系统；；
c）门户平台：
基于以人为本的原则，对系统层各个子系统进行集成。
使用门户平台，
用户不需要登陆每一个子系统进行相应的工作，而是在统一的门户平台进行工作。
结合工作流技术，对于每个登陆系统的人都提供简洁统一的工作选项，对于申请人、审核人、系统管理员、维护人员、局领导等都能做到方便的操作系统，快速进行业务处理和系统管理。
下图为基于SOA的ERP系统的应用架构总体设计图。
通用以上的阐述，可以看出，系统整体都是基于SOA架构进行设计的，主要体现在如下
四个方面：
a）系统基于SOA的以服务为中心的思想和方法，对ERP系统的整体体系架构进行设计，
建立了分层的松耦合、跨平台的系统架构；
b）在组件层，我们采用了基于SOA的组件模型，它将应用程序的不同功能单元（称为
服务）通过这些服务之间定义良好的接口和契约联系起来。
接口是采用中立的方式进行定义的，它应独立于实现服务的硬件平台、操作系统和编程语言。
这使得构建在各种各样的系统中的服务可以以一种统一的通用方式进行交互；
c）系统采用了基于SOA的分类集成方法对系统的业务以及服务进行分类和集成，做成
统一的接口，面向业务和服务编写，以适应SOA系统的统一交互；
d）将每一种业务构成都分解成不同的组件或者子系统，将组件和子系统分开编写达到
每项组件和子系统都能做到相互无关，如果一项组件和系统改变将对系统中的其余组件没有任何影响。
实现组件相互之间低耦合的机制，最大程序上降低了系统的升级、业务变更对系统的影响。
同时，基于SOA的系统应用架构具有强大的系统的扩展性：
a）SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对
企业商业服务变化、发展的需要，本方案很好地体现了SOA的这一中心思想；
b）工作流和业务规则引擎的采用极大了提高了系统对于业务流程和规则变化的适应
性。
工作流引擎可以使得在业务流程发生变化时使得系统调整最小，而不需要向传统的需要完全重新开发；业务规则引擎的采用使得业务规则发生变化时只需对业务规则进行重新描述即可完成系统的转换。
c）组件模型、组件集成技术的采用使得系统在进行业务功能的调整时，可以把变化局
限于某一个范围之内，在需要时还能进行灵活的替换。
由于系统应用架构是根据每一项业务或者流程编写所以对于系统的扩展非常方便，只要对新加入的业务对应加入新的组件就可以实现对SOA系统的扩展；
总之，本节提出的基于组件的ERP系统完全体现了SOA的核心思想，通过分层组件规划、集成、工作流引擎、业务规则引擎等方法和技术充分体现SOA的策略与方法，并且很好地实现系统的可扩展性、可移植性等等。
1.3.2系统技术框架
ERP系统基于J2EE规范实现，整个架构建立在Struts框架、Spring框架和DAO模式基础之上，并提供了对于EJB、WebService、JMS等组件技术的集成机制。
技术框架逻辑上可分为：
客户层、WEB层、业务层、持久层、资源层、核心层。
如下图所示为系统的技术框架。
客户层：
客户端计算机的浏览器，用于展现页面。
WEB层：
WEB层基于StrutsMVC，完成转发请求、Http请求合法性校验、Http请求参数与数据传输对象DTO之间的绑定、Http请求参数有效性校验、用户操作权限检查、记录用户访问日志、显示系统运行异常等任务。
业务层：
业务层基于Spring框架，完成业务数据校验、业务逻辑处理、事务管理、记录业务处理日志、抛出业务处理异常等任务，同时它也支持WebService、JMS、EJB等组件服务模型。
持久层：
持久层基于DAO进行构建，完成数据读取、数据存储、封装SQL异常、抛出SQL异常、记录数据读写日志等任务。
资源层：
资源层包括数据库服务器、XML存储文件等，是数据永久存储的介质。
核心层：
核心层表现为系统提供的基础类库，为WEB层、业务层和持久层提供支持。
包括日志记录组件、异常处理组件、事务处理组件、IoC容器封装组件、WEB层数据绑定组件、WEB层数据校验组件、权限检查组件、持久层辅助组件、其他开源项目类库组件等。
本技术框架的特色或优势主要体现在如下几个方面：
（1）系统技术框架提供了对SOA的完整支持；
（2）对于同一个应用系统，系统同时支持集中式和分布式两种部署方案，系统采用分离
UI层和BL层的方式来实现分布式的实现；
（3）业务层Service的实现可以有很多种，WebService、JMS、EJB、Spring等都可以
作为对业务层的一种实现；
（4）在系统的WEB层，同时支持同步和异步两种通信交互方式，使用了AJAX技术完成
改善用户体验的任务，主要完成页面表单数据的录入校验、生成联动的下拉列表等任务。
客户端访问web层时通过AJAX技术可以实现异步交互，在提交页面时系统采用同步方式处理提交页面的内容。
如下图所示为系统对于这两种交互方式的支持图。
（5）在系统中，每个功能模块都是相对独立的存在，在可扩展性上只要将新加入的组件
添加到系统中就可以实现系统的扩展，在系统中由于采用如：
Struts、AJAX等当前最新的技术，恰当的使用，在性能上会有显著的提高，而且由于Struts、AJAX等技术已经相当的完善所以在可靠性上也有可靠的保障。
1.3.3其他重要问题
（1）业务规则是支持企业决策，影响或控制企业业务行为的指示，它是企业处理业务过
程中始终要遵循的规则，而工作流则是根据业务规则制定的实际应用当中需要流转的程序。
在系统的编制过程中将严格遵守业务规则和根据业务规则制定的工作流程，在系统
篇三：
IT软件项目开发的具体实施方案
项目管理实施方案
作为一个项目管理者，如何要成功的做好项目管理；首先必须先要明白的是在特定的领域中赋予这个角色所要实现的目标、承担的职责、以及项目管理者的具体工作内容是什么？
从我个人的浅见和角度以及我们所从事的IT领域来分析回答以上三个问题。
第一：
目标
作为一个项目的管理者，必须要明确的知道自己的工作目标；我个人认为项目管理者的目标无非就是以下两点：
1、就是清晰明确地了解项目利害关系者的需求和期望，努力做到满足项目利害关系者的不同需求；项目利害关系者包括：
项目团队成员和项目团队外成员（比如各部门的部门负责人和市场人员，客户等）。
2、就是保证开发项目按需按时保质的完成。
第二：
职责
作为项目的管理者，首先要端正态度，要明确知道自己的工作职责，认识到这份工作职责的本质。
项目管理者不是来管人的，而是来支持人的，是来协调资源的，是来营造一个适合团队成员比较认同的工作环境和氛围的，是来为一个共同的目标和大家一起战斗共同成长的。
可以大概概括成以下几点：
1、建立有效的工作流程保证项目的顺利进行。
2、制定详细周密的项目计划。
3、跟踪，推动项目按计划进行。
4、积极解决项目过程中出现的问题和冲突。
5、调动开发团队的积极性，创造力，推动团队成员在项目过程中不断成长。
6、项目风险识别、风险评估、风险解决和风险管理策略以及做好突发风险的应急预案。
7、实现目标
第三：
项目管理者的具体工作内容
最后一个是项目管理者的具体工作内容，作为项目管理者必须清晰的知道自己的工作范围和所要做的工作内容以及工作重心，分为以下六点：
1、项目前期阶段
对项目进行技术可行性分析、技术评估、成本评估以及风险评估。
与需求提出方的代表进行需求讨论，明确项目的目标、价值；确定项目范围、功能及优先级。
组建项目团队，特别要搞清楚项目的keyperson（对产品有决定权的人）。
项目启动会议，相关的利害关系人员都必须参加。
该阶段完成后的成果：
确认后的最终软件需求规格说明书文档。
2、分析设计阶段
根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分
解（WBS）；资源申请，项目涉及到的开发资源、测试资源、设计资源（包括人员和软硬件资源）；数据库设计；系统设计；文档（包括UseCase、Demo系统原型、TestCase等）；评审会议。
该阶段完成后的成果：
A、UserCase（系统用例）；B、DEMO（系统原型）；
C、系统设计文档（概要设计和详细设计）；D、数据库设计文档。
最后对完成的成果，包括UserCase和设计文档等进行评审。
3、执行阶段（开发和测试）
准备开发环境、测试环境；跟踪，推动项目按计划进行；以周报的形式通报项目的进展情况。
对项目的阶段成果进行评估，以确保该阶段完成的质量，包括代码审核、SQL审核等。
对需求变更进行控制管理；对项目风险进行管理；测试阶段BUGFIXED及改进、收集反馈意见。
4、发布阶段
包括制定项目发布计划，用户培训，发布上线。
5、上线后监控
数据监控（日志、服务器状态），根据监控出现的问题，及时进行BUGFIXED及改进或做补丁升级。
6、结束阶段
产品交付，项目总结会。
第四：
基于以上三个问题所做的应对细则
要做好项目管理，并能确实解决好以上三个问题，实现目标、
履行职责、完成工作中的具体内容，从我个人这几年的工作经验和面临的一些问题，还有所积累的一些项目管理中的一些知识以及自己的观察和思考的角度看，应该要努力做好以下这几个方面的具体工作：
1、项目开发时间的估算
制定项目进度时间表的时候，需要估算每个任务所需的时间，其中开发任务中模块的分配和时间估算是其中最主要的部分；在分配模块和估算开发时间时需要遵循的原则和目标：
1、保证项目整体的进度。
2、有助于确保开发编码的质量。
3、有助于提高开发编码的速度。
在公司现有的技术框架下，开发人员主要的工作是投入在具体的商业逻辑上。
通常每个模块所需的开发时间取决于以下三个因素：
1、所负责模块的商业逻辑的复杂程度。
2、开发人员的技术水平和对项目所在应用的熟悉程度（包括对框架和应用的熟悉程度）。
3、该模块技术实现上是否有技术难点；这里所谓的技术难点定义是：
在现有系统中还未实现的、开发人员自身也未没接触过的技术。
对于这样的难点，开发者没有相关的代码可以参考，自己也没有经验，所以需要投入一些时间研究解决。
模块分配和开发时间估算的步骤：
1、在划分好模块后，首先自己先估算一下每个模块所需要的开发时间。
2、然后召集所有开发人员，讨论模块的分配和开发时间估算。
将划
分好的模块，让开发人员从中挑选他们感兴趣的模块。
这样做可以提高开发人员的主动性和参与性。
在分配模块的时候还需从以下几方面考虑，以确保开发的速度和质量：
A、相同类似的模块由同一人负责开发，比如用户管理的增删改由同一开发者负责。
这样做的好处就是开发者对相关逻辑会更加熟悉，同时接口的定义也会比较明确，沟通的成本比较低，同时功能实现的缺陷也相应的会降低。
B、技术难度比较大的模块由技术水平比较高的人负责。
C、业务逻辑比较复杂的由对这块逻辑比较了解的人负责。
3、模块分配完后，开发人员评估自己负责开发的模块所需要的时间。
在此过程中最好做到要和开发者比较详细的讨论每个模块的技术实现，以便使时间的估算更加准确。
4、对开发人员估算的时间进行确认。
在确认过程中作为项目管理者应参考以上提到的三个因素，同时将自己估算的时间和开发人员估算的时间进行比较。
这其中的差异当然会存在的。
对于那些差异比较大的，将与技术人员探讨其中的缘由。
对于时间周期比较长的任务，尽量将任务通过再细分的手段细化任务，争取每个任务的最长时间不超过3天；时间周期越长的任务，不确定性越高，风险也越高，越有可能成为项目的瓶颈，影响项目的进度。
2、CodeReview
CodeReview是保证项目中代码质量非常重要的一个环节，在这一环中我们公司做的非常欠缺，把关不严格；这是导致每次测试后出
升级会员 