超市管理系统软件项目计划说明书

超市管理系统软件项目计划说明书

软件学院

超市管理系统项目计划书

系（部、中心）软件学院

姓名朱发军学号 07082233

专业软件工程班级 .net122班

课程名称软件工程项目管理

设计题目名称《超市管理系统软件项目计划书》起止时间 4月25日—— 5月9日

成绩

指导教师签名刘风华

中原工学院软件学院制

目录

1.1 编写目的.......................................................... 错误!未定义书签。

1.2 背景 ................................................................. 错误!未定义书签。

1.3 定义 ................................................................. 错误!未定义书签。

1.4 参考资料.......................................................... 错误!未定义书签。

1.5 重要术语.......................................................... 错误!未定义书签。

2 项目进度计划编制的背景概述 ............................... 错误!未定义书签。

2.1 软件生存期模型选择与设计 .......................... 错误!未定义书签。

2.2 项目团队情况简述 .......................................... 错误!未定义书签。

2.3 软件估算情况.................................................. 错误!未定义书签。

2.4 项目范围的信息分析与使用 .......................... 错误!未定义书签。

2.4.1 软件的工作任务分解结构（WBS）....... 错误!未定义书签。

2.4.2 基于项目背景的WBS的细化方案......... 错误!未定义书签。

2.4.3 重要的假设及其说明.............................. 错误!未定义书签。

3 实施计划 .................................................................. 错误!未定义书签。

3.1 进度计划.......................................................... 错误!未定义书签。

3.2 基于进度计划的成本核算 .............................. 错误!未定义书签。

3.3 调整后的进度计划 .......................................... 错误!未定义书签。

3.4 关于进度计划的其它说明 .............................. 错误!未定义书签。

3.5 关于其它计划的说明 ...................................... 错误!未定义书签。

4 项目成果产品 .......................................................... 错误!未定义书签。

4.1 软件程序.......................................................... 错误!未定义书签。

4.2 软件文档.......................................................... 错误!未定义书签。

4.3 软件服务.......................................................... 错误!未定义书签。

4.4 非移交的软件产品 .......................................... 错误!未定义书签。

4.5 验收标准.......................................................... 错误!未定义书签。

5 其它.......................................................................... 错误!未定义书签。

1.1 编写目的

此项目开发计划书的编写主要是为了给开发《超市管理系统》做主要的规划和整合，在开发过程中起到引导作用，以及给使用者提供简要的说明进度是对执行的活动和里程碑制定的工作计划日期表

1.2 背景

a.待开发的软件系统的名称: 超市管理系统

b.本项目的任务提出者、开发者、用户及实现该软件的组织

结构（企业）

项目的任务提出者：XX超市高层领导

本系统的开发者：YY软件股份有限公司员工朱发军

本系统的用户：XX超市的高层领导、部门经理及其员

工。

实现该软件企业（YY软件股份有限公司）的组织结构

图：

（参考例图）

c.该软件系统同其它系统或其它机构的基本的相互来往关系。

与本系统有关的系统：无

1.3 定义

WBS :Work Breakdown Structure 任务分解结构。

PMI: Project Management Institute 美国项目管理学会，成立于1969年一个国际性组织，

PDM :Precedence Diagramming Method 单代号网络图

1.4 参考资料

[1] 《软件项目管理案例教程》（第一版），韩万江姜立新编著，机械工业出版社， 4月

[2] 《软件项目管理案例教程》（第二版），韩万江姜立新编

著，机械工业出版社， 4月

[3] 《软件项目估计》（第二版）, (美)CAPERS JONES 著，刘从越

编译，电子工业出版社， 3月

[4] 《软件需求》（第二版），（美）Karl E. wiegers 著，刘伟

琴、刘洪涛译，清华大学出版社， 9月

1.5 重要术语

1.WBS，Work Breakdown Structure，任务分解结构，是面向可交付成果的对项目元素的分组，它组织并定义了整个项目的范围。

2.进度计划,进度，就是工作计划日期表

3.质量计划：主要的质量管理对象是针对项目过程中那些对最终产品起着重要的作用的中间产品：需求规格、设计说明书，源程序，测试计划，测试结果等。

2项目进度计划编制的背景概述

2.1 软件生存期模型选择与设计

1.选择增量模型的原因：

1）.瀑布模型要求严格线性的开发，每个阶段开发活动结束后，经过严格的阶段性复审与确认，得到该阶段的一致、完整、正确和无二义性的良好文档资料，以“冻结”这些文档资料，作为该阶段的结束标志，保持不变，作为下一阶段活动的唯一基础，以每一步的正确性和完整性来保证最终系统的质量。可是大量的实践并不是这种理想的线性开发序列，而是在开发过程中逐步完善的。

而在增量开发过程：软件描述、设计和实现活动被分散成一系列的增量，这些增量轮流被开发。先完成一个系统子集的开发，再按同样的开发步骤增加功能(系统子集),如此递增下去直至满足全部系统需求。要求系统的总体设计在初始子集设计阶段就应做出设计。

2）增量模型有如下优点：

●能够避免一次性投资太多带来的风险，将主要的功能或者风

险大的功能首先实现，然后逐步完善，保证投入的有效

性。

●能够更快地开发出能够操作的系统。

●能够减少开发过程中用户需求的变更。

●

一些增量可能需要重新开发（如果早期开发的需求不稳定或者不完整）。

3）增量模型开发适合的项目：

? 项目开始，明确了需求的大部分，可是需求可能会发生变化 ? 对于市场和用户把握不是很准，需要逐步了解

?

对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的。

我们开发的是酒店管理系统，分客房模块、餐饮模块、财务模块、人力资源模块。虽然大部分的需求已明确，可是部分需求可能会发生变化；对于用户需逐步了解才能准确把握；对于复杂功能的系统进行功能改进，就需要一步一步实施的。同时系统具有可扩充性，若使用增量模型，能够保证系统的可扩充性。本项目具备增量模型的其它特点：项目的复杂程度中等；项目的风险较低；产品和文档的使用率会很高。因此选择增量式作为我们的开发模型。

第一增量

第二增量

第三增量

图2-1 增量式模型

2.具体的设计为：

图2-2 详细的增量模型

2.2 项目团队情况简述

表2-1 此项目团队人员的介绍：

职位人员

项目经理：朱发军

需求分析员：朱发军

概要设计员：朱发军

详细设计员：朱发军

编码人员：朱发军

测试人员：朱发军

由于项目初期信息不是很充分，因此初期的项目计划只存在一个计划表格，相当于一个大计划，简单说明计划的执行步骤，如表5所示。

表2-2 项目初期计划

2.3 软件估算情况

此软件估算结果列表：

表2-3 估算列表

2.4 项目范围的信息分析与使用

2.4.1软件的工作任务分解结构（WBS）

表2-4 WBS 分解情况

2.4.2基于项目背景的WBS的细化方案

表2-5 WBS 细化方案

2.4.3重要的假设及其说明

假设：

1.超市领导，公司领导都比较重视。

2.酒店里的领导，员工都比较积极主动配合。

3.分配的功能点总数为20个，平均每人1个功能点

4.每个人每个月人均生产率为1个功能点。

3实施计划

3.1 进度计划

此处用甘特图或进度表格描述。

1）进度计划：

表3-1 进度计划表

任务名称工期开始时间结束时间资源——子环境测试 1 -5-10 -5-13全体人员参与—后台管理子系统 1 -5-16 -7-13全体人员参与—人事功能-增量1 1 -5-16 -6-16全体人员参与——员工信息管理 1 -5-16 -5-19全体人员参与——员工操作权限管理 1 -5-20 -5-25全体人员参与——增量1评审 1 -6-13 -6-16全体人员参与—销售管理功能-增量2 1 -6-17 -7-1全体人员参与——查询打印销售信息 1 -6-17 -6-23全体人员参与——生成销售排行旁 1 -6-24 -6-28全体人员参与增量2评审 1 -6-29 -7-1全体人员参与—进退货管理-增量3 1 -7-14 -7-26全体人员参与——进货信息管理 1 -7-14 -7-18全体人员参与——退货信息管理 1 -7-19 -7-21全体人员参与——增量3评审 1 -7-22 -7-26全体人员参与—库存管理-增量4 1 -7-27 -8-8全体人员参与——查询库存信息 1 -7-27 -7-29全体人员参与——库存状态自动警告 1 -8-1 -8-3全体人员参与——增量4评审 1 -8-4 -8-8全体人员参与—后台管理子系统集成 1 -11-8 -11-17全体人员参与子系统集成测试 1 -11-8 -11-14全体人员参与子环境测试 1 -11-15 -11-17全体人员参与●系统集成 1 -11-18 -12-21全体人员参与——系统集成 1 -11-18 -12-21全体人员参与●系统测试 1 -12-22 -1-31全体人员参与——系统测试 1 -12-22 -1-11全体人员参与——环境测试 1 -1-12 -1-31全体人员参与●提交 1 -2-1 -2-7全体人员参与——完成文档 1 -2-1 -2-3全体人员参与——验收、提交 1 -2-6 -2-7全体人员参与

备注：安排的时间范围已包含节假日

2）项目进度图

图3-1 进度计划网络图

3）项目进度计划的甘特图：

图3-2 进度计划甘特图

4）项目甘特图实施部分的计划展开如下：

图3-3 实施部分的甘特图

5）里程碑

高层领导可能更加关注里程碑的进展，因此需要一个里程碑的图示，如下表所示。

表3-2 里程碑表

3.2 基于进度计划的成本核算

表3-3 基于进度计划的成本核算表

项目开发人员为1个人员。项目开发用到1个人月。预算总成本为340，000元（见上表），与估算的成本333，900元基本持平（有一点差距）。这样340，000元能够作为项目的成本控制参考。

3.3 调整后的进度计划

逐项列出影响初始计划的因素和调整的条目（包括影响项目成败的关键问题、技术难点和风险），指出这些问题对项目的影响然后给出调整后的进度计划。

由于系统规模不是很大，开发团队的人员对本系统也很熟悉，因此开发的过程中风险较小。因此进度计划没有太大的改动。

3.4 关于进度计划的其它说明

1.本进度计划是从按照交付日期倒推确定时间，然后安排计划内容；

2.进度安排提交的日期并非是真实的交付日期，而是留有半个月左右的余量时间，以备变化。

3.5 关于其它计划的说明

质量管理计划、1.软件质量是设计出来的不是检查出来的。因此质量管理的关键是预防重于检查，事前计划好质量，而不是事后检查。

2. 软件质量计划的主要内容为：针对项目过程中那些对最终产品起着重要的作用的中间产品：需求规格、设计说明书，源程序，测试计划，测试结果等的管理。

配置管理计划1.管理的主要内容为：版本信息。

2.管理的主要目标：软件配置的完整性和可追溯性。

项目跟踪

管理计划

1.基本原理：

2.项目跟踪的主要目的是：保证正确的人在正确的时候得到正确的信息。

4项目成果产品

4.1 软件程序

程序名称：酒店管理系统安装程序

所用的编程语言：Visual Basic

存储程序的媒体形式: 移动硬盘

本系统能够完成用户所提的基本功能需求和非功能需求，安全性能比较高，且能同时容纳人同时访问服务器。

4.2 软件文档

验收报告：客户对产品的验收情况的记录

用户安装手册：指导用户怎样安装产品

用户使用手册：指导用户怎样使用本系统

帮助：提供给用户在使用过程中的参考

4.3 软件服务

4.4 非移交的软件产品

项目计划

质量保证计划

配置管理计划

项目范围说明书

概要设计说明书

详细设计说明书

设计术语及规范

源程序

编码规则

测试计划

测试用例

测试报告

4.5 验收标准

1.验收测试的对象：软件包括程序、数据和文档。

2.验收测试要注意问题：

（1）验收测试始终要以双方确认的需求规格说明和技术合同为准，确认各项需求是否得到满足，各项合同条款是否得到贯彻执行。

（2）验收测试和单元测试、集成测试不同，它是以验证软件的正确性为主，而不是以发现软件错误为主。

（3）对验收测试中发现的软件错误要分级分类处理，直到经过验收为止。

（4）验收测试中的用例设计要具有全面性、多维性、效率性，能以最少的时间在最大程度上确认软件的功能和性能是否满足