oa项目管理计划书.doc

oa项目管理计划书 OA系统软件项目计划书学号姓名日期 一、项目概述 1、目的?让企业资源利用得到延展，资源利用最大化，；?解决多岗位、多部门之间的协同工作问题，使企业信息传递与沟通交流更顺畅，提高工作效率。 ?通过该系统的设计与实现，学习基于J2EE的网站开发技能，掌握了一个项目的开发流程，也了解企业内部业务处理流程。 2、背景传统办公模式基于纸张，效率低下，无法适用于随时随地办公、移动办公的要求。 OA系统基于网络技术，能够适应电子商务时代的企业事务处理对象，不仅能够提供作为企业与机构日常业务处理的基础平台，而且能够提供灵活应变和开放交互功能，它将跨地区的各个部门紧密的连接在一起，实现信息实时共享，最大程度的发挥各级人员的工作效率，从而使办公实现信息自动化，有利于办公效率的提高和公司的综合管理。 二、WBS分解（锯齿列表）1.0OA软件系统1.1身份验证1.1.1用户登录1.1.2用户注册1.1.3用户信息修改1.2系统管理1.2.1账号管理1.2.2角色管理1.2.3权限管理1.2.4人事管理1.3文件办理1.3.1发文管理1.3.2收文管理1.3.3公文流转1.3.4文件查询1.4流程定制1.4.1JBPM工作流引擎1.4.2公文流转流程定制 三、过程模型的选择瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。 软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。 当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。 （瀑布模型）考虑到瀑布模型的简单易用，符合常规设计思路，故本系统主要采用瀑布模型。 但在开发过程中，需求的变化是不可避免的。 OA系统功能模块偏多，且有些模块过于复杂，若单纯选择瀑布模型则只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险。 考虑到增量模型的灵活性可以使其适应变化的能力大大优于瀑布模型，且能有效的管理技术风险，故该系统对一些模块采用增量模型，结合瀑布模型和增量模型进行开发由于该。 四、进度计划该OA系统的大体工作计划如下表所示任务开始时间结束时间1.可行性分析xx.10.03xx.10.082.需求分析xx.10.09xx.10.162.1功能需求分析xx.10.09xx.10.162.2数据库需求分析xx.10.09xx.10.162.4性能需求分析xx.10.09xx.10.122.5需求规格说明书xx.10.09xx.10.163.设计xx.10.17xx.10.303.1概要设计xx.10.17xx.10.203.2界面设计xx.10.20xx.10.243.3详细设计xx.10.20xx.10.304.项目编码xx.10.30xx.12.154.1身份认证模块xx.10.30xx.11.024.2系统管理模块xx.11.02xx.11.084.3文件办理模块xx.11.08xx.11.154.4公文流转模块xx.11.15xx.12.014.8流程定制等其他模块xx.12.01xx.12.155.测试（主要夹杂在编码阶段）xx.11.1xx.12.155.1单元测试xx.11.1xx.12.155.3验收测试xx.12.15xx.12.156.产品提交xx.12.16xx.12.167.维护xx.12.16- 五、质量管理计划高质量的软件应该具备以下条件a)满足软件需求定义的功能和性能b)文档符合事先确定的软件开发标准c)软件的特点和属性遵循软件工程的目标和原则为了得到高质量的软件，主要通过以下两个个方面进行保证 1、文档文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述，因此尽量完备的文档对于软件质量的保证有一定的影响。 在该软件实现过程中，需要大致下列的文档 （1）需求规格说明书 （2）软件设计说明书 （3）软件测试计划 （4）软件测试报告 （5）用户手册 （6）实现代码 （7）项目实施计划 （8）项目开发总结。 2、评审与检查a)软件需求评审（SRR）应确保在软件需求规格说明书中规定的各项需求的合理性。 b)技术评审-必须遵守相关的标准、条例和规范。 c)概要设计评审（PDR）应评价软件设计说明书中的软件概要设计的技术合适性。 d)软件验证和确认评审（SV&VR）应评价软件验证和确认计划中确定的验证和确认方法的合适性与完整性。 e)详细设计评审（DDR）应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性f)功能检查（FA）应验证所开发的软件已经满足在软件需求规格说明书中规定的所有需求g)物理检查（PA）应对软件进行物理检查，以验证程序和文档已经一致、并已做好了交付的准备。 h)综合检查（CA）应验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。 六、风险管理计划风险管理就是识别评估风险，建立、选择、管理和解决风险的可选方案和组织方法。 包括了风险标识、风险预测、风险评估和风险管理与监控四个活动，强调通过对项目目标的主动控制做到防患于未然以避免或减少损失。 下面列出潜在的风险事件以及发生的概率、影响程度、风险等级和解决办法1风险后果严重性等级表风险的影响影响值灾难级5.0严重级4.0中度级3.0轻度级2.0轻微级1.0注影响值越大，影响越严重。 2.风险管理计划表序号1潜在风险风险辨别风险概率40%风险影响避免风险措施需求分析不够全面，需求不断变化需求风险设计风险3.0需求分析时，应考虑到该系统的所有可能的需求情况，多与客户交流沟通在项目规划和详细设计计划时，应该考虑完备对系统功能模块实现时严格按设计要求不折不扣2需求不能满足客户要求10%4.03设计错误导致程序实现困难20%4.04系统功能达不到预期，系统的功能不够完善技术30%3.05软件的某些功能遗漏，导致系统不能满足需求没有做好有效的备份方案，导致重要的数据、文件丢失风险40%4.0完成6质量风险20%5.0在各个阶段都要做好文档、数据、文件的备份，保证某些数据丢失不影响项目进度严格遵循项目相关规范和标准开发在设计阶段就要设计好测试计划，这样就能给测试人员一个全面的测试方案在实现该阶段的模块中寻找问题的原因，如果找不到就要到设计中查找问题的根源1.在开发系统前应多去了解系统开发需要的工具；2.开发过程中不断地学习系统开发论坛上面的开发经验；3.端正学习态度，戒骄戒躁，认真完成各项工作；7项目规范定义不清楚，编码格式不符合标准没有切实可行的测试计划，测试不全面，导致系统运行时出现错误30%4.08测试风险20%3.09测试时在功能上出现重大问题，导致功能无法正常实现40%4.010开发人员没有接受过正规培训11开发人员精力有限、只能部分时间工作12开发系统的经验不足，不熟悉开发过程13开发人员能力有限开发人员相关风险80%2.050%4.040%3.020%3.014开发人员学习态度不够认真20%4.015开发人员人力资源不够80%2.016时间紧张，项目进度不能按时完成质量风险50%4.0合理安排课余时间，时间就像海绵里的水，挤挤总会有的实现模块内部高内聚；各模块之间低耦合17开发的各个模块无法有效的集成，导致整个系统不能有技术风险风险60%5.0效的运行18增量模型的模块无法及时完成，导致开发进度延长质量风险40%3.0严格按照详细计划完成任务，做好质量控制 七、配置管理计划协调软件开发使得混乱减到最小的技术叫做软件配置管理，它是一种标识、组织和控制修改的技术，目的是使错误达到最小并最有效地提高生产效率。 该系统选择SVN作为该项目的配置管理软件，采用VisualSVN软件作为Server保存代码,myEclipse安装SVN插件实现代码的上传和下载以及文档的管理。 7.1配置项识别所有配置项都按照相关规定统一编号，按照相应的模板生成，在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。 所有配置项的操作权限应由CMO严格管理。 基本原则是基线配置项向软件开发人员开放取得权限；非基线配置项向PM、CCB相关人员开放。 图1配置项命名规范6.1.1主要配置项类型主要配置项项目计划质量保证计划WXQ-OA-SPP-SQA-V1.0配置管理计划WXQ-OA-SPP-SCM-V1.0WXQ-OA-RM-SRS-V1.0标识符预计正式发表时间xx-10-09计划WXQ-OA-SPP-PP-V1.0xx-10-09xx-10-09需求需求规格说明书xx-10-16设计概要设计说明书WXQ-OA-Design-HL-V1.0xx-10-20详细设计说明书WXQ-OA-Design-LL-V1.0xx-10-30设计术语及规范源程序编码规则测试计划测试用例测试报告运行产品验收报告用户手册WXQ-OA-Design-STD-V1.0xx-10-20编程WXQ-OA-Code-ModuleName-V1.0xx-12-15WXQ-OA-Code-STD-V1.0xx-11-1测试WXQ-OA-Test-Plan-V1.0xx-11-1WXQ-OA-Test-Case-V1.0xx-11-15WXQ-OA-Test-Report-V1.0xx-12-15提交WXQ-OA-Product-Exe-V1.0xx-12-16WXQ-OA-Product-Report-V1.0xx-12-16WXQ-OA-Product-Manual-V1.0xx-12-16表1配置项列表6.2配置空间管理角色人员职责和工作范围配置管理者王小琼 （1）制定配置管理计划 （2）创建和维护配置库WXQ-OARMSRS-v1.0公司3个字符项目最长8个字符类型最长5个字符编号最长8位数字/字符版本号V m.n CCB负责人王小琼 （1）审批配置管理计划 （2）审批重大的变更CCB成员王小琼审批某些配置项或基线的变更表2配置管理角色职责表6.3版本控制基线名称/标识符基线包含的主要配置项预计建立时间需求需求规格说明书xx-10-16详细设计详细设计说明书、数据库设计xx-10-30项目实现软件源代码、编码规则xx-12-15系统测试测试用例、测试报告xx-12-16表3项目基线6.4变更控制主要过程 （1）变更请求提交后的评估，评估对象包括技术指标、潜在副作用、对其他配置对象和系统功能的影响以及变更的成本等。 （2）评估的结果以变更报告的形式给出，该报告由变更授权人审核批准。 （3）对被批准的变更生成工程变更工单（描述了将要进