南昌研究所项目计划模板.docx

资源描述

南昌研究所项目计划模板.docx

《南昌研究所项目计划模板.docx》由会员分享，可在线阅读，更多相关《南昌研究所项目计划模板.docx（16页珍藏版）》请在冰豆网上搜索。

南昌研究所项目计划模板.docx

南昌研究所项目计划模板

技术文件

技术文件名称：

技术文件编号：

20060425

版本：

V1.0

共页

（包括封面）

拟制

审核

会签

标准化

批准

版本变更记录：

版本号

拟制日期

拟制人

版本描述

存档编号

——

注：

1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。

1定义与缩略语3

2引用3

3项目概述3

3.1项目的目标3

3.2项目的范围3

4项目组织5

4.1组织结构5

4.2角色与职责5

4.3外部接口6

5项目定义过程6

6工作分解结构6

7项目估算7

8项目风险管理7

9项目计划制定8

9.1方法、工具和技术8

9.2资源计划8

9.3培训计划9

9.4进度计划9

9.5资金预算分配9

9.6资料管理计划9

9.7跟踪计划10

10依赖与承诺11

11支持过程11

11.1质量保证计划11

11.2配置管理计划11

12其他计划11

13附录11

定义与缩略语

表1.1定义与缩略语

缩写、术语

解释

SSO

单点登录，用户只需要登录一次，即输入一次统一的用户名称和用户密码，就可以多次使用多个应用系统。

webservice

WebService就是为了使原来各孤立的站点之间的信息能够相互通信、共享而提出的一种接口。

引用

表2.1　引用文档

文档名称

编号或版本号

发布日期

发布组织

南昌市信息发布平台建设方案

V200604

2006-04

项目经理

质量保证计划

V1.0

2005-07-30

QA组

配置管理计划

V1.0

2005-07-30

CM组

测试计划

V1.0

2005-07-30

测试组

项目概述

项目的目标

由于整个防汛抗旱指挥系统是一个比较大的系统，里面有很多的业务子系统，所以首先我们要构建一个防汛抗旱指挥系统的综合信息管理平台，解决统一身份认证、一站式登录问题，提供一套安全可靠的权限管理，并可以不断地扩充将要实施的各个业务子系统。

将现有的洪涝灾情系统、旱情灾情系统、实时工情检索、今日汛情检索，四个业务子系统改造成基于现在综合信息平台的系统，最终解决一个用户只登录一次的问题。

同时在此综合信息平台的基础上，实现网站式信息发布管理，作为南昌市防办防汛抗旱指挥系统的一个信息平台和入口点。

项目的范围

解决方案概述

首先，防汛抗旱指挥系统总体结构中应有一个中间容器层，用于统一管理所有的业务子系统的权限认证问题，实现业务子系统的软件热插拔，使得各个子系统能够统一和谐地处理业务问题，并且可以无限扩充。

因此，将南昌市防汛抗旱指挥系统综合信息服务平台总体体系结构分为三层：

应用层、中间容器层、数据库层。

1.中间容器层

在数据库层，分出一个专用的数据库，用于存放登录用户针对各个业务子系统的权限数据。

由于我们以后的应用将采用JAVA+JSP来实现，所以中间容器层采用扩展自JSP、Servlet容器（比如Tomcat）自带的权限认证，也成为单点登录技术（SSO），实现容器（Tomcat）下所有应用统一身份认证、一站式登录，统一管理各应用的操作权限。

2.数据库层

数据库系统主要管理两类数据库。

一类是需要提供全系统共享的数据库，主要管理用户权限相关数据。

另一类数据库是支撑应用系统自身运行的数据库，数据汇集平台包括水雨情、工情、旱情和灾情数据汇集，并实现基于数据分布协议的数据管理，重点是保障数据的一致性。

3.应用层

应用层包括市防办电子化办公、网站信息发布、和基于该平台的防汛抗旱业务子系统等等，所有只要是符合中间层提供的规范约束，并在中间层容器基础上发布的子系统。

其中网站式信息发布系统就是一类。

如果子系统不符合该容器中间层的规范约束，无法在该容器基础上发布，比如第三方的应用系统，则该容器只提供单点登录调用接口，提供WEBServices描述文件，由第三方应用系统自已调用WEBServices方法来解决单点登录问题，不负责提供权限管理。

高层次的工作分解结构

本项目的主要任务为搭建南昌市水利信息发布平台，工作包可以分为主要五块：

单点登录、系统授权、子系统发布、权限管理和界面设计。

假设与约束

表3.1假设与约束

序号

假设与约束条件

造成的影响估计

需求文档的撰写

如果在需求定义时候消耗了太多时间，则会对整个项目的进度造成影响

项目进展

如果项目进展情况比计划慢，则会推后项目的验收时间

测试结果

如果测试结果发现项目中有太多问题，则会导致项目的后期修改工作任务繁重，造成项目不能预期完成

项目的最终交付产品

表3.2项目最终交付产品

序号

交付产品名称

数量

交付日期

交付地点

交付方法

软件功能清单

----

南昌

纸件

项目验收标准

项目的验收标准为：

首先通过项目经理的审核和测试人员的测试，然后再交给客户进行评审，最终由客户确定项目顺利完成和达到预期的需求目标

项目结束：

客户签定验收协议书

项目组织

组织结构

南昌市水利信息发布平台项目经理

界面设计和文档负责人

权限管理模块负责人

子系统发布模块负责人

系统授权模块负责人

单点登录模块负责人

图4.1项目组织结构

角色与职责

表4.1　角色与职责

名称/姓名

角色

职责

联系方式

备注

外部接口

表4.2　外部接口

名称/姓名

角色

职责

联系方式

备注

项目定义过程

工作分解结构

图6.1工作分解结构图

如图6.1所示，整个项目工作主要分解为以上几个大的过程，其中软件开发过程包括的工作包的关系如图6.2所示：

管理活动包括项目估算、风险评估、项目启动会议、例会、里程碑评审会议、技术协调会、项目后分析、结束会议等。

＜描述要完成项目目标而必须完成的工作包（也就是任务或任务的集合），用唯一的序号来识别每个工作包，标识工作包的负责人。

标识项目工作包之间的依赖关系，识别关键路径＞

项目估算

表7.1　项目估算计划

估算次数

阶段点

规模

工作量

成本

进度

初始估算

需求分析前

参见Project　文档

第一次重新估算

系统设计前

第二次重新估算

编码前

第三次重新估算

系统测试前

项目风险管理

表8.1风险管理策略

风险小组成员

姓名

职责

联系方式

风险管理活动的范围

工具和方法

项目风险源

项目风险分类

风险分析所选用的参数

风险应对策略

风险跟踪和报告机制

项目计划制定

方法、工具和技术

●计算机系统硬件环境：

CPU为P42.66Ghz，内存为512M；

●计算机系统软件环境：

操作系统winxp或者win20003server，数据库为SQLserver2000；

●编程语言：

java；

●工具：

开发工具为Eclipse，源代码控制工具为CVS等等；

●开发方法：

请参照软件详细设计说明书；

●质量控制手段：

同行评审，单元测试，代码单步调试、系统测试和自动回归测试等等；

资源计划

软件和硬件资源计划

表9.1　软/硬件资源需求

序号

资源名称

需求数量

到位时间

退出日期

如何获得

责任人

备注

Pc机

2006.4

公司分配

操作系统

2006.4

公司分配

开发工具

2006.4

公司分配

2006.4

表9.2关键计算机资源

序号

资源名称

需求数量

到位日期

如何获得

责任人

人员计划

表9.3　人员需求

人员类型

需求人数

到位时间要求

退出安排

技能要求

如何获取

备注

培训计划

表9.4　培训计划

培训主题

重要性

参加人数

培训时间

（小时）

培训日期

培训方式

备注

TD的使用

一般

2006-4

内部培训

进度计划

表9.4里程碑列表

序号

里程碑名称

里程碑实现准则

计划开始日期

计划到达日期

备注

2006-04-28

资金预算分配

表9.5　资金预算分配

阶段

分析

设计

编码

合计

人力资源

研发材料

固定资产

其它费用

合计（万元）

资料管理计划

表9.6资料管理计划

资料名称

存放位置

分发和归档机制

访问权限

维护人

跟踪计划

度量计划

<描述规模、工作量、进度、缺陷、成本、关键计算机资源、风险、软件/硬件资源、问题、同行评审跟踪的策略和机制>

项目度量按照南昌研究所组织标准过程的要求。

具体情况可参见《项目计划附件》中的跟踪与监督计划页。

项目状态和技术沟通协调

●项目状态沟通的方式，如：

状态报告的发送方式、问题反映渠道等。

●项目组内部及外部进行协调交流的方式和流程，如：

讨论会、评审会、论坛、邮件等。

●小组例会和（或）项目例会的时间（如每周的第几天召开周例会。

在每月的第几天召开月例会），会议主要内容及参加人员。

●主要里程碑会议、项目结束会议、主要技术协调会议的日期、会议主要内容及参加人员。

描述本项目将在，以及在哪些阶段点/里程碑处召开评审会议。

这些会议分别由哪些人应该参加，会议的输入是什么，输出是什么。

●上述沟通协调会议的议程应该覆盖：

1）需要协调的问题包括：

●新的关键依赖和约定

●产品和产品模块需求、和设计缺陷

●产品级问题

●关键资源或人员的不可获得性

2）确定相关干系人中发生的冲突将被如何解决，如：

●标识并文档化问题

●与相关干系人沟通问题

●与相关干系人解决问题

●逐步向适当的管理人提交那些与相关干系人无法解决的问题

●跟踪问题直到关闭

●就问题的状态和决议与相关干系人沟通

依赖与承诺

＜项目的工作包之间、模块之间、项目组和部门之间的依赖关系，可以用下表来说明。

＞

表10.1　依赖

工作任务

依赖工作产品

接收者

提供者

提供时间

验收方式和接收准则

描述本项目（工作包）受影响的工作任务

项目内外的组织或个人应该提供工作产品或服务

<制定A接口规范>

<2006-4-30>

<接口方案审查通过>

注：

提供日期指本项目的当前计划中能够容忍的最后期限。

＜本项目内和项目外部的组和个人的承诺可以用下表来说明。

＞

表10.2　承诺

约定关系

责任人