图书管理系统项目开发计划.docx

图书管理系统项目开发计划.docx

《图书管理系统项目开发计划.docx》由会员分享，可在线阅读，更多相关《图书管理系统项目开发计划.docx（28页珍藏版）》请在冰点文库上搜索。

任务管理项目开发计划

第一部分、引言

1.1编写目的

本计划编写目的是更清晰地理解任务项目的业务要求，明确项目需要做的工作，并为保证项目在范围和进度方面的要求提供可执行的依据，包含了范围、进度、人员安排在内的明确的计划和安排，以切实能保证项目能在控制中完成。

1.2背景

说明：

A、 软件系统的名称：

任务管理项目

B、 任务提出者：

：

niit_张钰彬

开发者：

尹宾，常浩，懂江鹏，彭淘

本系统完成后是针对个人事务管理后的产品，在市场上独立销售，是面向那些需要管理个人日常任务的广大计算机使用人员的。

c、本系统将是独立的系统，目前不与其他的系统或者操作系统提供特别的接口，所产生的输出都是独立的。

1.3定义

WBS WorkBreakdownStructure,工作分解结构，面向可交付成果的工作分解；

RAW ResponsibilityAssignmentMatrix,职责分配矩阵，描述在不同阶段和人员配

备情况；

CriticalPath——在NDG中描述项目的关键路线；

MilestoneChart 项目的里程碑图，标识项目的关键进程点；

受控文件一NIIT内部已经形成标准的规范性文件，在执行过程中做强制性的要求；

1.4参考资料

相关的文件包括：

A、 产品开发部的内部文件《核准任务管理项目》；

B、 任务管理项目分析会议备忘录；

C、 《任务管理项目需求说明书》；

D、 《任务管理项目可行性分析》；

E、 《任务管理项目概要设计》；

参考资料：

A、 国家标准《项目开发计划（GB856T—88）》；

B、 莱克公司的人力资源管理项目的项目开发计划；

合同：

（内部开发的产品项目，无合同）

第二部分、项目概述

2.1工作内容

为完成本项目，需要按照需求分析、设计、编码、测试等不同的阶段来进行，其中，本计划不考虑维护阶段所做的工作。

需求分析明确本项目所开发产品的特性，并对不同的功能组进行划分，并得到用户方的确认。

设计阶段将该需求转化为计算机的模型，并且对实现的功能进行分配，详细设计还将提供各模块、任务、功能点的详细规划。

编码实现将按照软件产品设计所描述的内容，编写代码实现软件各部分的功能。

测试部分包括对实现过程中的错误的修改、功能的改进的一些活动，同时包括了各子系统、模块、功能点的组合和连调。

以上的过程中，包含了不同阶段的文档输出工作，并且上一阶段的输出，通常作为下一阶段的输入而存在。

详细的工作包和任务的分配，请参考第二部分执行计划的工作内容。

2・2产品

项目的最后的产品和可交付物包括最后完成的软件包、相关的文档、手册、宣传内容等，分别如下：

2.2.1程序

1、 完成的软件系统

最后完成的软件系统，其功能、模块和性能要求请参考文档《任务管理项目需求说明书》中关于产品特征的描述。

最后完成的软件，要求是安装包的形式，并且使用光盘的形式进行交付。

2、 数据库脚本程序：

在系统遭受灾难的时候，用户可以使用该脚本程序恢复SQLServer数据库的结构。

对于ACCESS数据库，本脚本不适用。

文档《任务项目数据库脚本》是该交付物的形式，并且附带在产品的光盘中，包含脚本的使用说明文字。

2.2.2文件

1、 操作手册

操作手册提供用户对软件系统的操作指导，要求同时提供.DOC格式的电子文档和

至少一份打印稿。

2、 培训资料

相关的培训的资料要求提供给用户（具体的格式，在项目的后期进行确定）。

2.2.3月艮务

在产品到市场发行后，项目成员提供技术方面的咨询服务，这些服务属于维护阶段的一部分。

2.2.4非移交的产品

非移交的产品包括过程记录和过程文档，包括：

A、 软件的源代码

程序的源代码不提供给用户。

B、 安装程序工程

C、 需求文档

C、 过程评审记录

可能发生的需求、设计、实现和验证阶段的评审记录、评审报告，都不提交给最终用户。

D、 设计和规划文档

包括产品设计、过程规划等方面的文档，不提供给最终用户。

E、 测试记录和测试报告

不同阶段的测试规划、测试记录、测试报告等文档，都由产品开发部门保留、归档。

以上非移交的产品，不得提供给其他的单位或者个人，或者用于其他的商业事务，详细的说明参考公司的保密和安全规定。

2.3验收标准

A、程序：

程序中应包含的功能如下：

1. 永久存储用户输入的任务的信息；

2. 任务调度和任务查找操作简易；

3. 任务的删除和更新；

4. 能够针对任务设置启动时间、终止时间、任务时间间隔；

5. 任务启动的提示、多任务的启动提示；

6. 显示系统的时钟；

7. 任务启动时间、终止时间、任务启动时间间隔调整；

8. 在多用户环境下，允许不同的人管理自己的任务；

数据库脚本在SQLServer2000的查询分析器中能正确运行，创建的数据库能够支持程序的各项功能的运行，并且保证数据的准确性。

Access数据库应具备抵抗非法访问的特性。

B、 文件

操作手册的规格满足GB86的相关标准，对应的内容应包括以上功能的各部分的说明，手册中不应该包含专业性的词汇，对于数据库脚本的恢复程序，应提供非常详细的操作指引和图例。

C、 服务

其他维护的要求按照维护阶段的内部约定进行。

2.4完成项目的最迟期限

项目的系统测试的最后完成日期为2003-12-1日，然后在2004-1-1之前，进行运行时测试、B测试、产品化工作，包括用户培训等服务活动的实施。

系统在2004-1-1起，正式投放市场使用。

2.5本计划的批准者和批准日期

本计划的批准人为产品开发部门经理。

本计划的正式批准日期为2003-9-10日，实施日期为2003-9-12日。

6

第三部分、实施计划

3.1工作分解与人员分工

本项目的工作分解如下：

实施阶段

（说明：

1、 以上的工作，可以在更细的层次上进行分解，例如17,可以分别为查询界面、增加的界面和删除的询问词的设计等，系统测试可以分解为测试平台的搭建、测试用例的编写、系统各功能点的测试、测试记录的填写、测试总结和总结报告等多个工作单元。

2、 有关测试、工作分解的详细内容、文档规格，请参考ACCP3.0后续课程的描述；

3、 以上的工作分解，不存在时间先后的次序。

）

按照工作分解，职责分配如下:

T1：

文件归档

T2：

程序、界面、手册的反馈和修订

T3:

项目总结

T4：

项目结束和团队解散

P参与人员；A负责人员；S 确认审核人员;

3.2进度

最后的项目网络图如卜：

完成项目至少需要的时间用红色的线表示，项目的完成线路（完整完成项目最少所需要

的时间）为：

1-2-3-4-7-10-13-14-17-21-24-25-26-31-32-33一34

对应的时间为：

3+3+2+2+3+3+2+2+3+3+4+2+4+1+1=38（工作日）

预留20%作为整体浮动时间，实际需要的工作日为46。

在并行一些工作的条件下，项目预计完成的时间在两个月左右。

（说明：

非关键路径活动所需要的时间，没有在项目网络图上标识。

）

项目的开始日期为2003-9-1日，项目的里程碑（阶段点）时间:

9/8

9/18

10/8

10/20

11/2

（说明：

1、 可以制作一张项目的日历，说明项目针对于日期的更详细的信息，这可以借助于Microsoft

Project2000等项目管理软件来完成，此处略；

2、 项目管理软件的使用、作用，请参考ACCP3.0后续课程相关的内容;）

3.3预算

按照以上工作包的估算如下表:

分阶段的开发费用统计如下表:

阶段名称

人工费用（人月）

机时（小时）

其他（元）

项目

管理

系统

分析

软件设计

编程

调试

数据录入

其他

人工

终端小时

主机小时

外存空间

其他费用

出差资料

其他费用

SA&

SD

RA

PD

DD

CD&

UT

IT&S

T

IS&AC

TSSD

（说明：

以上实际数字的填写略。

）

SA&SD（SystemAnalysis&SoftwareDefinitionPhase）：

系统分析与软件定义阶段；

RA（RequirementsAnalysisPhase）:

需求分析阶段；

PD（PreliminaryDesignPhase）：

概要设计阶段；

DD（DetailedDesignPhase）：

详细设计阶段；

CD&UT（Coding&UnitTestingPhase）：

编码与单元测试阶段；

IT&ST（Integrating&SystemTestingPhase）：

组装与系统测试阶段；

IS&AC（Installation&AcceptancePhase）：

安装与验收阶段；

TSSD（TotalSoftwareSystemDevelopmentPhase）：

整个软件系统的开发阶段。

（说明：

1、 以上的估算分别按照各项活动的累计进行估算；并且按软件开发的不同的照阶段给出一个大体的估算数据，可以只用一种估算方法作为依据；

2、 项目的预算和估算可能由专门的项目财务管理系统来进行，项目计划中只要对该文档进行引用就可以了；

3、得出的不同阶段的估算结果，可以绘制成本曲线，以对执行阶段的成本进行控制，一般的成本曲线应该是一条类似于S形状的曲线，下图是预算形成的成本基准和实际花费的成本的对比曲线：

4、 成本对比曲线、成本偏差是要求项目经理在项目进行过程中需要控制的一个重要方面；

5、 单项成本的估算一般没有考虑管理费用，在实际项目运行的时候，需要在总金额上加上

一定比例的管理费用；例如以上管理费用的比例如果是20%,则实际的费用是50400；

6、 一般的项目，都对成本留一定的储备金，例如，以上估算结果的储备金若是10%,考虑管理费用，最后的总预算是55440o）

3.4关键问题

影响整个项目成败的关键问题、技术难点和风险包括：

风险类别

风险描述

可能性

影响

使用提高生产率工具所产生的计划节余被过高地估计了。

0.4

0.9

计划、资源和产品定义都受客户或上级管理部门支配，而不平衡

0.8

0.3

预定日期提前，但没有对产品范围或可用资源作相应调整。

0.6

0.6

产品比估计的大（从准则、功能点、模式等方面来看）。

0.9

0.5

管理审查/决策过程比预料的慢

0.8

0.5

非技术第三方任务花费的时间比预料的长（预算审批、法律审查等）。

0.8

0.5

最终和户坚持新要求。

0.9

0.8

即使递交的软件符合所要求的全产规格，但商业用户将不接受该软件.

0.8

0.9

商业用户审查/决策过程比预料的慢。

0.6

0.5

最终用户最终发现产品不能令人满意，要求♦新设计和,做。

0.6

0.9

小组成员之间的冲突导致通信差、设计差、界而错误和额外工作。

0.6

0.7

人事工作比预料的慢。

0.7

（）.6

正式手续太多（官僚性遵守软件政策和标准）.

0.8

0.7

开发不具不像预料的那样有效，开发者需要时间来创建有关工作，或改用新工具。

0.6

0.8

（说明：

1、 以上列出的是可能影响项目开发，包括进度、成本和质量的各方面最重要的一些风险和对该风险的概率、影响的估计；

2、 以上的风险，是软件开发的风险对照表的一部分，在其他的项目开发中，风险分析也可以采用风险对照表确定风险的概率和影响程度;然后在根据这些可能性和影响程度来判断是否采取预防措施；

上图中，分别使用了不同的颜色来反应风险的最后的程度。

3、 软件开发风险对照表如下：

风险类别

风险描述

可能

影响

规划风险

计划是根据使用项目问题专家（SEM）的情况制定的，但是这些成员没有得到。

计划省略是必要的任务。

使用提高生产率工具所产生的计划节余被过高地估计了。

计划、资源和产品定义都受客户或上级管理部门支配，而不平衡。

计划是乐观的“最佳实例”（而不是现实的“预期实例”）。

计划是根据使用具体小组成员的情况制定的，但这些小组成员没有得到。

预定日期提前，但没有对产品范围或可用资源作相应调整。

一项任务的推迟使从属任务一并推迟。

作为对计划到计划的失察作出反应而作出的重新估计过于乐观，或忽略了项目历史。

过大的计划压力降低生产率。

项目规划在压力下被放弃。

规划太差，不能支持需要的发展速度。

不能在分配的时间内制造规定尺寸的产品。

产品比估计的大（从准则、功能点、模式等方面来看）。

努力比估计的大（从准则、功能点、模式等方面来看）。

准则或等级资料库质量差，造成额外的测试、缺陷纠正和重做工作。

产品的不熟悉方面要花费比预料的更多的时间来设计和执行。

任务先决条件（例如培训、其他项目的完成、获得工作许可证）不能按时完成。

组织风险

产品缺少有效的高级管理发起人。

产品在不明不白的前其被搁置的时间太长。

解雇和削减降低小组的能力。

管理或销售部门坚持延长计划的技术决定。

低效的小组结构降低生产率。

管理审查/决策过程比预料的慢。

预算削减打乱项目规划。

管理部门作出挫伤开发小组的积极性的决定。

非技术第三方任务花费的时间比预料的长（预算审批、法律审查等）。

规划太差，不能支持需要的发展速度。

项目规划在压力下被放弃，导致混乱的、低效的发展。

管理部门对豪情比对准确的状况报告强得更多,从而削弱它发现和纠正问题的能力。

未能达到里程碑。

商业用户坚持新要求。

最终和户坚持新要求。

即使递交的软件符合所要求的全产规格,但商业用户将不接受该软件。

商业用户所期望的发展速度是开发者不能达到的。

商业用户最终发现产品不能令人满意。

没有征求商业用户的意见，因此产品最终不符合用户期望，因此必须重做。

商业用户审查/决策过程比预料的慢。

缺少商业用户参与审查过程、原型和规格，因而导致不稳定的要求。

商业用户通信比预料的慢。

商业用户微观管理发展过程。

商业用户提供的组成部分不匹配，并且质量差。

最终用户最终发现产品不能令人满意，要求重新设计和重做。

最终和户不买进项目，因此不提供所需要的支持。

没有征求最终用户意见，因此产品最终不符合用户期望，必须重做。

客户坚持新要求。

客户对规划、原型和规格的审查/决策过程比预料的慢。

客户将不参与对规划、原型和规格的审查过程，或不能这样做，从而导致不稳定的要求和费时的修改。

客户通信时间（例如回答澄清要求问题的时间）比预料的慢。

客户坚持延长计划的技术决定。

客户微观控制开发过程，导致进程比计划的慢。

客户提供的组成部分质量差，导致额外的测试、设计和整合工作，并导致额外的客户关系管理。

客户批准的支持工具和环境不兼容，性能差，或者功能不足，致使生产率降低。

即使递交的软件符合所要求的全部规格,但客户将不接受该软件。

客户所期望的发展速度是开发者不能达到的。

小组结构效率低下。

任务先决条件（例如培训、其他项目的完成、获得工作许可证）不能按时完成。

开发者与管理部门之间的关系差，延缓决策和持续执行。

小组成员不买进项目，因而不提供所需要的性能水平。

积极性和士气低，从而降低生产率。

缺少所需的规格，从而增加缺陷和重做工作。

员工需要额外时间来学习不熟悉的软件工具或环境。

员工需要额外时间来学习不熟悉的硬件工具或环境。

员工需要额外时间来学习不熟悉的编程语言。

合同员工在项目完成前离开。

长期员工在项目完成前离开。

项目后期增加新开发人员，并且额外的培训和通信费用降低现有小组成员的效率。

小组成员不能有效的协同工作。

小组成员不买进项目。

所需规格缺少增加。

小组成员之间的冲突导致通信差、设计差、界面错误和额外工作。

有问题的小组成员没有退出小组，从而挫伤整个小组的积极性。

项目得不到更有资格做项目的人员。

项目得到更有资格做项目的人员,但是出于政治或其他原因启用他们的。

找不到项目所需要的具有关键技能的人员。

关键人员只有部分时间才能得到。

项目得不到足够的人员。

人事工作比预料的慢。

缺少管理承诺。

管理费用不合理。

项目缺少有效的执行发起人。

很难找到关键执行人。

承包人和顾问不提供答应的组成部分。

承包人和顾问提供的组成部分质量低得不能接受，因此必须增加时间来提高质量。

外部以来风险

雇用承包人和盛况时间比预料的长。

任务先决条件（例如培训、其他项目的完成、获得工作许可证）不能按时完成。

承包人和顾问需要额外的时间来学习不熟悉的软件工具或环境。

承包人和顾问需要额外的时间来学习不熟悉的硬件工具或环境。

承包人和顾问需要额外的时间来学习不熟悉的编程语言。

合同员工在项目完成前离开。

项目后期增加新的开发承包人和顾问,并且额外培训的通信费用降低现有小组成员的效率。

小组成员之间的冲突导致通信差、设计差、界面错误和额外工作。

关键承包人和顾问只能部分时间才能得到。

非技术第三方任务花费的时间比预料的长（预算审批、设备采购审批、法律审查）。

合同类型限制到项目的全部要求。

找到卖主解决问题的可能性受限制。

培训包给第三方。

提供包给第三方。

找不到帮助部门来解决所有问题。

导致在解决问题方面浪费大量时间。

项目依赖卖主，因此控制是单方面的。

不知道的额外费用不知不觉地进入项目。

技术风险

容易出错的模式所需要的测试、设计和执行工作比预料的多。

不能接受的低质量所需的测试、设计和执行工作比预料的多。

错误用户界面的开发需要重新设计和执行。

不需要的额外软件功能（镀金）的开发扩大计划。

符合产品尺寸和速度限制所需要的时间比预料的多，包括重新设计和重新执行的时间。

与现有系统兼容和严格要求所需的测试、设计和执行比预料的多O

与其他系统、其他复杂系统或不受小组控制的其他系统的接合要求导致意料之外的设计、执行和测试。

在多操作系统下操作的要求比预料的要花费更长的时间来满足。

在不熟悉的或未经批准的软件环境下运行造成意料之外的问题。

在不熟悉的或未经批准的硬件环境下运行造成意料之外的问题。

对组织来说是新品牌的某种组成部分的开发所花的时间比预料的长。

对仍在开发中的技术和依赖延长计划。

产品取决于政府条例，这些条例意外地改变。

产品取决于草拟的技术标准，这些标准意外地改变。

在直到项目后期还不知道的项目问题方面不准确的进程跟踪结果。

初步质量担保活动被忽略。

在直到项目后期还不知道的质量问题方面不准确的质量跟踪结果。

正式手续太少（缺少遵守软件政策和标准）。

正式手续太多（官僚性遵守软件政策和标准）。

不充分的风险管理不能检测到主要项目风险。

过分简单的设计不能解决主要问题，因而导致重新设计和重新执行。

单独开发的组成部分不能容易地加以整合，因而需要重新设计和重做。

过分复杂的设计需要不必要的和无利可得的执行费用。

很差的设计导致重新设计和重新执行。

使用不熟悉的方法导致额外的培训时间和重述，以确定方法的第一次误用。

产品用低级语言（例如汇编语言）来执行，并且生产率比预料的低。

必要的功能不能用选择的准则或等级资料库质量差，造成额外的测试、缺陷纠正和重做工作。

使用提高生产率工具所产生的计划节余被过高地估计了。

开发不具不像预料的那样有效，开发者需要时间来创建有关工作，或改用新工具。

开发工具不是根据其技术优点来选择的，因而不能提供计划中的生产率。

批准的支持工具和环境不兼容，性能差，或者功能不足。

设备不能及时得到。

设备能得到，但不够用（例如没有电话，没有联网，没有办公用品等）。

设备拥挤不堪，有噪声，或受到破坏。

开发工具在所需时间不到位。

学习新工具的时间比预料的长，或者所分的阶段比预料的多。

）

第四部分、支持条件

支持本项目的开发所需要的条件和设施包括：

4.1计算机系统支持

硬件环境：

CPU：

PHI750或者更高频率

ROM：

256或者更高内存支持

磁盘：

8G

软件支持：

开发所用的操作系统：

Windows2000ServerSP1

开发工具：

VisualStudio6.0SP4

数据库系统：

MicrosoftSQLServer2000企业版覆盖测试工具：

Panoroma

4.2需由用户承担的工作

（本项目是非合同项目，本条不适用）

4.3由外单位提供的条件

（不适用）。

第五部分、专题计划要点

5.1配置管理计划

配置管理所关心的问题涉及以下三点：

1、 仔细定义软件系统的交付物；

2、 严格控制对可交付物的变更；

3、 确保软件系统的可交付物与既定的或者经过核准修订的可交付物相一致。

NIIT所有的软件项目配置管理采用标准的表格模板，并遵循了标准：

《计算机软件配置管理计划规范》（GB^T12505-1990）,本部分加以引用。

5.2质量管理计划

5.2.1、依据

A、 质量政策

NIIT科技发展有限公司在软件产品设计和开发方面通过了IS090012000的规范，同时制定了质量方针和质量目标：

质量方针：

通过严格和规范的过程管理、文档化的流程开发，提高生产效率，为客户提供稳定、易用和符合要求的产品系列。

质量目标：

在软件方面的年纯利润达到