项目计划书Word格式.docx

项目计划书Word格式.docx

《项目计划书Word格式.docx》由会员分享，可在线阅读，更多相关《项目计划书Word格式.docx（13页珍藏版）》请在冰豆网上搜索。

提供在校教师的基本信息，如职称，联系方式

8）教学管理:

提供课程表查询，如可知道在某天某时那些班没课……；

方便学生查询成绩，包括网上查询。

9）年度学生综合测评管理

叙述：

年度综合测评是学校一年一次的对学生的综合评价。

它分德育（30分），智育（60分），体育（10），奖惩分（正负10分），加起来为100+正负10。

德育由自评——自己给自己评分（30%）+互评——班上同学给自己评分（30%）+辅导员评分——辅导员给自己评分（40%）；

智育由学生一学年的学习课程成绩来算，算法为……；

体育……；

奖惩分由一学年内获奖的情况来确定。

学校根据综合分可对学生进行排名和奖学金的发放，奖学金的评定有成绩的硬性规定，如三等奖要平均分70以上，最底分62以上。

10）辅导员个人管理:

针对辅导员的工作辅助管理他日常的事务。

他能根据个人管理更好管理每个学生，更好的为学生服务。

11）系统自我管理：

系统有自我管理功能，如有错误自动记录，提示，修复；

数据库的自动整理，备份；

……

项目团队组织

3.1项目组织结构

项目经理：

项目计划的制订和跟踪，包括进度、资源和成本的管理，还要负责团队的建立和管理

系统分析员：

需求分析、系统分析（OOA）、业务建模

架构设计师：

系统设计（OOD）

测试设计师：

测试用例的开发、测试计划

程序员：

编码实现、单元测试、集成测试

测试员：

执行功能测试和压力测试

文档工程师：

用户手册、开发指南、产品发布说明

3.2生命周期

初始阶段：

大部分需求分析，少部分设计（大部分业务建模和需求，少部分分析设计）

?

设计阶段：

大部分设计，少部分编码（大部分分析设计，部分实施及测试，开始考虑部署）

实施阶段：

大部分编码和测试，少部分设计（大部分实施及测试，部分部署）

收尾阶段：

安装及维护（大部分部署）

项目工作分解

4.1工作分解及编码

4.2项目里程碑计划

1）了解用户需求,确定开发系统要达到的目标

2）完成系统的总体设计

3）通过单元和功能测试

4）通过系统测试,打包投入使用

项目进度计划

5.1项目工序时间

序号

工作名称

工作时间（天）

紧后项目

搭接项目

搭界时间

1

产品需求

5

2

产品目标

3，4

3

规格说明书

10

6

4

初步进度计划

高层设计

最终进度计划

7

低层设计

8，9

8

编码

15

9

测试计划

单元测试

11

系统测试

—

5.2项目工序网络图

5.3关键路径

最早开始时间

最晚开始时间

最早结束时间

最晚结束时间

12

20

22

25

30

40

55

45

50

60

70

项目总工期为:

71天

5.4甘特图

项目资源计划

6.1人力资源计划

工作天数

人力资源

工作量估计（工时）

平均每天工作量

每天安排人数

管理人员

120

24

工程师

200

80

16

800

程序员

1200

6.2设备计划

设备使用情况

原材料使用情况

电脑、打印机、电话

电、纸张

电脑、打印机

电脑

电

项目采购计划

设备/原材料名称

数量

采购

方式

采购（租赁）地点

采购（租赁）成本（元）

10台

购买

中关村

30000

打印机

2台

500

纸张

若干

超市

600

项目成本预算

每项工作的费用都包括人力费用和固定费用（材料、设备）

8.1单位人力费用

管理人员：

40元/小时

工程师：

60元/小时

30元/小时

8.2费用预算安排

固定费用（元）

总费用（元）

每周平均费用（元/周）

5600

1000

13000

6500

4000

1600

13600

6800

2000

14000

7000

48600

16200

3000

25000

12500

8.3项目累计成本预算表

周数

本周费用（元）

已累积费用（元）

至本周累计费用（元）

11200

10500

21700

13300

35000

10800

45800

52800

59800

19200

79000

95200

111400

118200

130700

13

143200

项目风险计划

软件项目管理的四个阶段中，在初始阶段项目成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的，比如：

在这个阶段如果某种原因突然资金来源断了（这在需求阶段是很有可能的），以至于不能继续进行项目，不得不终止项目，那么这时候的损失只是需求分析阶段的投入。

随着项目的进展项目成功的可能性变大，风险发生的概率逐渐变小，风险对项目的损失逐渐变大，快到收尾阶段的时候风险对项目的损失最大，随着收尾阶段的进行风险又逐渐变小。

9.1风险识别?

风险源与风险事件:

1）初始阶段可能的风险事件：

1、项目目标不清

2、项目范围不明确（范围太大太小都不可以）

3、用户参与少或和用户沟通少

4、对业务了解不够

5、对需求了解不够

6、没有进行可行性研究

2）?

设计阶段可能的风险事件

1、项目队伍缺乏经验，如缺乏有经验的系统分析员

2、没有变更控制计划，以至于变更没有依据，该变更的不变，不该变的也变，这样得来的设计势必会失败或者偏离用户需求

3、仓促计划，可能带来进度方面的风险

4、漏项，由于设计人员的疏忽某个功能没有考虑进去

3）实施阶段可能的风险事件

1、开发环境没有具备好

2、设计错误带来的实施困难

3、程序员开发能力差，或程序员对开发工具不熟

4、项目范围改变（突然要增加或修改一些功能，需要重新考虑设计）

5、项目进度改变（要求提前完成任务等）

6、人员离开，在一个项目内软件开发工作有一定的连续性，需要移交和交接，有时人员离开对项目的影响会很大

7、开发团队内部沟通不够，导致程序员对系统设计的理解上有偏差

8、没有有效的备份方案

9、没有切实可行的测试计划

10、测试人员经验不足

4）收尾阶段可能的风险事件

1、质量差

2、客户不满意

3、设备没有按时到货

4、资金不能回收

风险识别的有效方法:

建立风险项目检查表、因果分析图、采访各种项目干系人等。

软件项目的风险可以从以下几方面检查：

产品规模风险

业务影响风险检

与客户相关的风险

过程风险

技术风险

开发环境风险

与人员的模式和经验有关的风险

9.2风险综合评价

风险因素

权重W

风险发生的可能性

W*c

很大（1.0）

比较大（0.8）

中等（0.6）

不大（0.4）

较小（0.2）

计划不完善

0.2

0.08

工期紧张

0.04

人员变动

0.1

目标不明确

0.02

开发环境不可靠

0.15

0.06

编程能力

0.09

测试能力

W*C=0.39

9.3风险应对措施

PMBOK提到三种应对方法

1）避免

通过分析找出来发生风险事件的原因，消除这些原因来避免一些特定的风险事件发生。

比如：

如何避免客户不满意？

客户不满意有两种情况，一种情况是没有判断客户满意度的依据，即没有双方互相认可的客户验收标准，还有一种是开发方没有达到验收标准，即没有满足用户需求。

不管是哪一种，开发方都有不可推卸的责任，只要做好以下环节完全可以避免：

1、业务建模阶段要让客户参与

2、需求阶段要多和客户沟通，了解客户真正的需求

3、目标系统的模型或DEMO系统要向客户演示，并得到反馈意见，如果反馈的意见和DEMO系统出入比较大时，一定要将修改后的DEMO系统在次向客户演示，直到双方都达成共识为止

4、要有双方认可的验收方案和验收标准

5、做好变更控制和配置管理

2）减轻

通过降低风险事件发生的概率或得失量来减轻对项目的影响。

也可以采用风险转移的方法来减轻风险对项目带来的影响。

项目预算中考虑应急储备金是另一种降低风险影响的方法。

经过风险识别发现，项目组的程序员对所需开发技术不熟。

可以采用熟悉的技术来减轻项目在成本或进度方面的影响。

也可以事先进行培训来减轻对项目的影响。

3）接受

接收风险造成的后果。

为了避免自然灾害造成的后果，在一个大的软件项目中考虑了异地备份中心。

开发应对计划:

针对需要采取应对措施的风险事件，开发应对计划，一旦发生风险事件，就实施应对计划。

比如:

在一个软件开发项目中，某开发人员有可能离职，离职后会对项目造成一定的影响，则应该对这个风险事件开发应对计划，过程可以参照如下：

1、进行调研，确定流动原因

2、在项目开始前，把缓解这些流动原因的工作列入风险管理计划

3、项目开始时，做好计划一旦人员离开时便可执行，以确保人员离开后项目仍能继续进行

4、制定文档标准，并建立一种机制，保证文档及时产生

5、对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作

6、对每个关键性技术人员培养后备人员

在考虑风险成本之后，决定是否采用上述策略。

项目质量管理

10.1文档管理

1）内部文档包括：

项目开发计划;

需求分析;

体系结构设计说明;

详细设计说明;

构件索引;

构件成分说明;

构件接口及调用说明;

组件索引;

组件接口及调用说明;

类索引;

类属性及方法说明;

测试报告;

测试统计报告;

质量监督报告;

源代码;

文档分类版本索引;

软件安装打包文件。

2）外部文档主要包括：

软件安装手册;

软件操作手册;

在线帮助;

系统性能指标报告;

系统操作索引。

根据文档的不同，文档的来源也不同，文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目进行到后百分之十的时候起到拉动项目的作用。

特别是在系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。

10.2系统维护质量保证

系统交付后还需要后续的维护，一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。

所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。

他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。

对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。

如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。