杭州市地铁人事管理系统谋划书论文-本科论文.doc

杭州地铁人事管理系统

论文题目： 杭州地铁人事管理系统计划书

学生姓名
分 院 　
专业名称 计算机科学与技术
班　　级 　
学　　号

1.概述
1)项目介绍
项目中文名称：杭州地铁人事管理系统
项目英文名称：Hangzhou Metro Personnel Management System
项目代号：HZ/MER-PMS
项目目的：为杭州地铁提供一款功能全面方便实用的人事管理系统。
项目背景：杭州地铁进入运营
客户信息：杭州地铁
相关系统：SQL-2000提供数据库支持，delphi开发环境。
2） 范围
功能范围：系统管理、人员管理、运营管理
应用范围：杭州地铁人事部门
3） 子计划
（1） 软件配置管理计划；
（2） 软件质量保证计划；
（3） 软件测试计划；
（4） 项目计划的维护
项目计划在下列情况下将被更新：
（1）项目关键问题的解决；
（2）需求更改导致进度的调整大于两周；
（3）人员、硬件、软件等资源需求改变；
（4）新技术的引入；
（5）开发过程的改变；
（6）软件结构功能质变；
（7）项目特性的改变。
在项目阶段性审核时，如果更改项目计划，则项目进度表也相应更新。
（8）项目特性
项目开发初期需求基本可以确定，细则有待确定。

2. 软件工作产品
软件工作产品进度表
开发产品名称
文档标识号
计划完成日期
A or R*
需求
需求获取/分析表
HZ/MER-PMS-RM-01
2012-10-30
A
系统功能说明书
HZ/MER-PMS-RM-01
2012-11-16
A
软件需求规格说明书
HZ/MER-PMS-RM-01
2012-12-28
A
计划
软件开发计划（SQP)
HZ/MER-PMS-PP-01
2012-11-16
A
软件配置管理计划
HZ/MER-PMS-PP-02
2012-11-30
A
软件质量保证计划
HZ/MER-PMS-PP-03
2012-11-30
A
软件测试计划
HZ/MER-PMS-PP-04
2012-12-10
A
设计
概要设计书
HZ/MER-PMS-SD-01
2013-01-18
A
详细设计书
HZ/MER-PMS-SD-02
2013-02-22
A
用户手册
HZ/MER-PMS-SD-03
2013-02-22
R
数据库设计
HZ/MER-PMS-SD-04
2013-02-22
R
BOSS接口规范
HZ/MER-PMS-SD-05
2013-02-22

实现
原代码模块
HZ/MER-PMS-IMP-01
2013-04-12
A
执行代码模块
HZ/MER-PMS-IMP-02
2013-04-12
R
测试
确认测试方案
HZ/MER-PMS-TEST-01
2013-01-20

集成测试方案
HZ/MER-PMS-TEST-01
2013-02-10
R
单元测试用例
HZ/MER-PMS-TEST-01
2013-03-20
R
单元测试记录
HZ/MER-PMS-TEST-01
2013-04-24
R
单元测试报告
HZ/MER-PMS-TEST-01
2013-04-26
R
集成测试记录
HZ/MER-PMS-TEST-01
见测试计划
R
集成测试报告
HZ/MER-PMS-TEST-01
R

开发产品名称
文档标识号
计划完成日期
A or R*
确认测试记录
HZ/MER-PMS-TEST-01

R
确认测试报告
HZ/MER-PMS-TEST-01
R
系统测试记录
HZ/MER-PMS-TEST-01
R
系统测试报告
HZ/MER-PMS-TEST-01
R
验收
产品发布记录
HZ/MER-PMS-CON-01
2013-05-20
R
软件质量总结报告
HZ/MER-PMS-CON-02
见SQA计划
R
财务总结报告
HZ/MER-PMS-CON-03
2013-05-20
R
项目总结报告
HZ/MER-PMS-CON-04
2013-05-20
R
维护
维护记录
HZ/MER-PMS-MT-01

*：A=审核，R=评审，采用审查还是评审由项目组决定。
3. 假设、依赖和约束
假设：杭州地铁提供的数据接近真实，功能预算满足实际
依赖的外部条件：
（1） 开发环境条件配备；
（2） 开发人员到位；
（3） 项目成员具备基本的开发素质；
（4） 和客户保持及时的联系；
（5） 指派SCCB、PM、SQA、SCM、测试组人员。
约束：SQL服务器、delphi开发工具、数据挖掘技术支持、杭州地铁运营业务逻辑等。

4.项目过程定义
1） 软件开发生命周期模型
本项目为产品研发项目，且为初期阶段，大部分需求不能马上确定，由于人力与技术资源等限制，计划采用迭代V模型，如图所示。

本产品分三个迭代阶段：
（1）分析型
（2）精英型
（3）协作型
2）方法和工具
本项目软件开发所使用的方法和工具如下表所示。
软件开发方法与工具
软件工作产品 方法 工具
需求分析与设计 00 Rational Rose 2001
编码 00 delphi
单元测试 00 delphi
文档 Word\Excel MS Office 2003

5.任务分解
描述软件任务分解和工作包，并提供进度表供项目运行、项目管理活动每周一次的评审、高级经理评审使用。项目进度安排表如示。
项目进度安排表
任务 开始日期 结束日期 负责人
需求获取分析 2012-10-15 2012-11-21 俞凯凯
软件开发计划 2012-10-15 2012-11-21 赵雅丽
系统功能说明书 2012-10-15 2012-11-21 陈惠婉
软件需求规格说明书 2012-11-21 2012-12-24 俞凯凯
概要设计 2012-12-09 2013-01-08 赵雅丽
用户手册 2012-12-31 2013-01-17 陈惠婉
详细设计 2013-01-05 2013-02-22 俞凯凯
数据库设计 2013-01-05 2013-02-22 赵雅丽
编码 2013-02-05 2013-02-22 陈惠婉
单元测试 2013-01-03 2013-04-28 某某
项目总结报告 2013-05-02 2013-05-19 某某

6.估计
1） 大妈估计
估计方法：采用功能点（特征点）估计方法并结合历史数据。
编程语言：delphi、SQL2003
估计过程：略
估计结果：
代码量=1352.29FP；
文档量=4350页；
需求数=250项。
2） 文档大小估计
软件工作产品规模估计如下表所示。

软件工作产品规模估计表
文档名称
估计文档 大小（页）
文档名称
估计文档 大小（页）
需求获取/分析表
50
源代码模块
50
系统功能说明书
80
执行代码模块
3000
软件需求规格说明书
100
确认测试方案
20
软件开发计划
30
集成测试方案
20
软件配置管理计划
20
单元测试用例
30
软件质量保证计划
20
单元测试记录
50
软件测试计划
20
单元测试报告
50
概要设计书
100
集成测试记录
50
详细设计书
300
集成测试报告
30
用户手册
100
确认测试记录
30
数据库设计
50
确认测试报告
20
BOSS接口规范
50
系统测试记录
20
财务总结报告
10
系统测试报告
20
项目总结报告
10
产品发布记录
20
维护记录
20
软件质量总结报告
10
合计
4350

3） 工作量估计
软件开发工作量估计如下表所示。
软件卡法工作量估计表
阶段
工作量（人小时）
阶段
工作量（人小时）
需求与计划
1265.00
编码
1233.67
分析
1822.12
测试
2315.00
设计
2182.94
支付
234.34
合计
9053.07

4） 关键计算机资源估计
关键计算机资源需求如下表所示
关键资源需求表
关键项 数量或说明
服务器磁盘空间 40G
网络速度 10M/200Mb/s
操作系统 Windows xp
CPU主频 P4 1.5G以上
PC机内存 1G以上

7.项目管理
1)项目组织结构如下图所示
项目组织结构图

2)角色与职责
角色岗位职责表
姓名 角色岗位和职责
俞凯凯 项目经理 需求收集、系统分析设计、项目管理
赵雅丽 软件经理 需求收集、系统分析设计、编码测试、技术支持
陈惠婉 系统分析员 需求收集、系统分析设计、编码测试、实施指导
胡图图 高级程序员 技术实施、设计、编码、测试
于晨 高级程序员 需求收集、设计、编码、测试
何妮 编码、测试
蔡琴 编码、测试
金兴 编码、测试

3)组间合作
组间合作表
小组 联系人 支持描述
软件配置管理 俞凯凯 参考《NewSkyCRM项目配置管理计划书》
软件质量管理 赵雅丽 参考《NewSkyCRM项目质量保证计划书》
外部BOSS研发 陈惠婉 计费、账务和客服方面的数据结构，数据库借口规范
测试组 董栋 GPRS需求、计费规则等，数据库接口规范
市场部 蔡彩 客户需求收集与确认

4)人员计划
人员计划表
开发阶段 起止日期 人数 技能等方面的要求
计划 2012.10.05-2012.11.07 6 系统分析员3人、需求管理1人、客户联络员1人、项目策划1人
需求分析 2012.11.05-2012.12.11 6 系统分析员4人、高级程序员1人、文档与配置1人
概要设计 2012.12.08-2013.01.20 5 系统分析员3人、高级程序员2人
详细设计 2013.01.05-2013.02.22 6 系统分析员1人、高级程序员5人
编码 2013.01.18-2013.04.20 8 高级程序员4人、程序员4人
单元测试 2013.01.10-2013.04.30 6 测试员2人、高级程序员2人、程序员2人
交付 2013.05.03-2013.05.20 4 系统分析员1人、高级程序员1人、程序员2人

5)培训计划
培训计划表
主题 人数 计划日期 提供者 备注
软件过程培训 全部 10天 SEPG 公司内部
数据仓库 2-3人 10天 Orancle 上海、杭州等地培训
Rose、UML 3-4人 5天 系统分析专家
编程技术 5-6人 5天 高级工程师
软件工程原理 全部 5天 公司内部

6)风险管理计划
影响程度：5——灾难性、4——严重、3——一般、2——轻微、1——可忽略。
分类：BU——商业风险，CU——客户特性风险，DE——开发环境风险，TE——人员经验风险，ST——建造技术风险，PS——产品规模风险，PU——过程风险。
风险计划表
风险因素 类别 概率 影响 RMMM 负责人 发生阶段
开发的产品不再符合公司的整体商业策略 BU 5% 5 监控 高级经理 全程
人力需求估计过低 TE 50% 4 监控 项目经理 详细设计与编码
没有得到预算或人力上的保证 BU 50% 4 监控 项目经理 全程
与BOSS开发组之间无法协调 DE 20% 4 缓解 高级经理 设计阶段
复用程度低于计划 PS 65% 3 风险 软件经理 编码阶段
规模估计可能和实际差别很大 PS 60% 3 监控 项目经理 设计编码
缺少对工具的培训 DE 50% 3 缓解 项目经理 编码阶段
测试和编码的具体监控难以实现 PU 40% 3 监控 项目经理 编码测试
四层结构新技术的尝试可能导致技术力量不够 ST 30% 3 缓解 软件经理 设计编码
参与人员的流动 TE 30% 3 缓解 项目经理 全程
数据仓库新技术的尝试不能保证成功 ST 20% 3 缓解 项目经理 分析设计
OO分析和设计新技术的尝试可能与传统的过程ST 20% 3 缓解 项目经理 分析设计
冲突
交付期限将被紧缩 BU 10% 3 监控 项目经理 全程
开发人员工作的短时中断 PU 90% 2 计划 项目经理 全程
与客户之间无法沟通 CU 90% 2 缓解 项目经理 需求、分析
产品创建和使用的数据库很大 PS 80% 2 监控 项目经理 测试交付
用户需求发生较大的改变 PS 65% 2 计划 项目经理 分析之后
测试工具的欠缺不能保证测试的效率 DE 50% 2 缓解 项目经理 测试交付
交付期限不能保证产品的完整性 BU 50% 2 监控 项目经理 设计编码
技术达不到预期的效果 ST 50% 2 监控 项目经理 设计
开发人员不能严格遵守过程规范 PU 50% 2 监控 项目经理 全程
合作者或合作关系的重大变化 DE 40% 2 缓解 高级经理 全程
参与人员缺乏经验 TE 40% 2 缓解 软件经理 全程
最终用户可能抵制该系统 BU 10% 1 缓解 项目经理 交付维护

7)项目技术变更管理
项目变更管理计划表
新技术 评估期 试用期 推广期
Delphi技术 2012-10-20 2012-11-21 2012-12-05
数据仓库技术 2012-10 2012-11 2012-12

8)进度跟踪
(1)项目会议
项目会议计划采用周例会与随机会议相结合的形式。
会议组织者：一般由项目经理或软件经理负责组织并实施。
项目会与的时间或频率：周例会每周一次，每次定于周五下午3点左右。随机会议根据情况临时确定。
项目会议主要内容：周例会原则上是本周工作报告和讨论问题解决办法，以及下周工作安排。随机会议视情况而定。
(2)项目里程碑
项目里程碑表
里程碑
时间
工作产品
控制时间范围
负责人
变更措施
计划阶段完成
2012-11-07
1、项目计划
2、需求说明
1-2周
赵雅丽
1、尽量避免变更，提前监控，延时不超过一周。
2、特殊情况，例如春假、培训、客户交流等，重新估计并调整计划。
3、对红牌里程碑注意总结教训。
分析阶段完成
2012-12-11
1、需求规格说明书
1周
陈惠婉
设计阶段完成
2013-02-22
1、概要设计书
2、详细设计书
3、数据库设计书
4、用户手册
5、BOSS借口规范
1周
于凯凯
编码完成
2013-04-20
1、源代码模块
2、可执行模块
3、程序库
1周
赵雅丽
测试完成
2013-04-30
1、单元测试报告
2、项目总结报告
1周
陈惠婉

(3)项目数据统计与分析
按照数据采集表收集各个阶段所有相关数据：项目计划数据、开发工作量、进度与成本数据、人员数据、评审数据、测试数据、计划变更数据等。
统计分析，确定项目状态及采取的改进工作。
(4)其他跟踪项
序号 跟踪项 跟踪方法 负责人
1 数据库合作效果 定期交流监督 项目经理
2 资产流失 客户跟踪 高级经理
3 工程和管理开销 监控 高级经理

8.移交标准
贯穿整个项目，必须在项目进行到下一阶段前达到所确定的标准，最后阶段是把产品移交给客户。
1）集成测试移交标准
必须在及成绩的测试之前达到本移交标准。
（1）提供完整可公测使用的可执行文件及相关文档；
（2）单元测试报告
（3）概要设计文档
（4）数据库设计文档
2）系统测试移交标准
必须在系统级的测试之前达到本移交标准
（1）提供完整可供测试用的可执行文件及相关文档
（2）系统需求规格说明书
（3）用户手册
（4）测试计划和测试方案
（5）单元测试报告
（6）集成测试报告
3）发布标准
在产品发布给客户之前必须满足如下移交标准：
（1） 完整的且版本一致的可执行程序；
（2） 用户手册