软件项目计划说明书》.docx

软件项目计划说明书》.docx

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

软件项目计划说明书》

软件项目计划说明书》

学院超市管理系统项目计划书系（部、中心）软件学院姓名朱发军学号3专业软件工程班级、net122班课程名称软件工程项目管理设计题目名称《超市管理系统软件项目计划书》起止时间全文结束》》年4月25日xx年5月9日成绩　指导教师签名刘风华中原工学院软件学院制目录

1、1编写目的

31、2背景

31、3定义

31、4参考资料

31、5重要术语42项目进度计划编制的背景概述

52、1软件生存期模型选择与设计

52、2项目团队情况简述

62、3软件估算情况

72、4项目范围的信息分析与使用

72、4、1软件的工作任务分解结构（WBS）

72、4、2基于项目背景的WBS的细化方案

82、4、3重要的假设及其说明83实施计划

93、1进度计划

93、2基于进度计划的成本核算1

13、3调整后的进度计划1

23、4关于进度计划的其他说明1

23、5关于其他计划的说明124项目成果产品1

44、1软件程序1

44、2软件文档1

44、3软件服务1

44、4非移交的软件产品1

44、5验收标准145其他1

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

1、2背景a、待开发的软件系统的名称:

超市管理系统b、本项目的任务提出者、开发者、用户及实现该软件的组织结构（企业）项目的任务提出者：

XX超市高层领导本系统的开发者：

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

XX超市的高层领导、部门经理及其员工。

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

（参考例图）c、该软件系统同其他系统或其他机构的基本的相互来往关系。

与本系统有关的系统：

无

1、3定义WBS:

WorkBreakdownStructure任务分解结构。

PMI:

ProjectManagementInstitute美国项目管理学会，成立于1969年一个国际性组织，PDM:

PrecedenceDiagrammingMethod单代号网络图

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

[3]《软件项目估计》（第二版）,（美）CAPERSJONES著，刘从越编译，电子工业出版社，xx年3月[4]《软件需求》（第二版），（美）KarlE、wiegers著，刘伟琴、刘洪涛译，清华大学出版社，xx年9月

1、5重要术语

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

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

3、质量计划：

主要的质量管理对象是针对项目过程中那些对最终产品起着重要的作用的中间产品：

需求规格、设计说明书，源程序，测试计划，测试结果等。

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

2、1软件生存期模型选择与设计

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

1）、瀑布模型要求严格线性的开发，每个阶段开发活动结束后，通过严格的阶段性复审与确认，得到该阶段的一致、完整、正确和无二义性的良好文档资料，以“冻结”这些文档资料，作为该阶段的结束标志，保持不变，作为下一阶段活动的唯一基础，以每一步的正确性和完整性来保证最终系统的质量。

但是大量的实践并不是这种理想的线性开发序列，而是在开发过程中逐步完善的。

而在增量开发过程：

软件描述、设计和实现活动被分散成一系列的增量，这些增量轮流被开发。

先完成一个系统子集的开发，再按同样的开发步骤增加功能（系统子集）,如此递增下去直至满足全部系统需求。

要求系统的总体设计在初始子集设计阶段就应做出设计。

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

l可以避免一次性投资太多带来的风险，将主要的功能或者风险大的功能首先实现，然后逐步完善，保证投入的有效性。

l可以更快地开发出可以操作的系统。

l可以减少开发过程中用户需求的变更。

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

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

q项目开始，明确了需求的大部分，但是需求可能会发生变化q对于市场和用户把握不是很准，需要逐步了解q对于有庞大和复杂功能的系统进行功能改进，就需要一步一步实施的。

我们开发的是酒店管理系统，分客房模块、餐饮模块、财务模块、人力资源模块。

虽然大部分的需求已明确，但是部分需求可能会发生变化；对于用户需逐步了解才能准确把握；对于复杂功能的系统进行功能改进，就需要一步一步实施的。

同时系统具有可扩充性，若使用增量模型，可以保证系统的可扩充性。

本项目具备增量模型的其他特点：

项目的复杂程度中等；项目的风险较低；产品和文档的使用率会很高。

所以选择增量式作为我们的开发模型。

图2-1增量式模型

2、具体的设计为：

图2-2详细的增量模型

2、2项目团队情况简述表2-1此项目团队人员的介绍：

职位人员项目经理：

朱发军需求分析员：

朱发军概要设计员：

朱发军详细设计员：

朱发军编码人员：

朱发军测试人员：

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

表2-2项目初期计划任务完成时间负责人资源备注项目规划xx-5-24朱发军全体人员参与需求获取xx-01-05同上开发人员，超市领导，部门经理，员工代表参与需求确定xx-01-13同上全体人员参与概要设计xx-02-03同上详细设计xx-03-04同上全体人员参与项目实施xx-11-17同上朱发军参与有待细化项目集成、测试xx-01-11同上提交xx-02-07同上朱发军参与

2、3软件估算情况此软件估算结果列表：

表2-3估算列表估算项估算结果功能点估算：

该软件的功能点总数约为20个进度估算：

该软件开发时间30天成本估算：

总成本为3900元人员数估算：

所需的人员为1个人

2、4项目范围的信息分析与使用

2、4、1软件的工作任务分解结构（WBS）表2-4WBS分解情况编号任务名称任务内容定义备注1前台销售系统涉及到超市部门员工超市前台销售的功能

1、1收银管理收银业务

1、1、1金额计算销售金额计算

1、1、2打印清单打印交易收据

1、1、2会员卡支持会员卡打折功能

1、2顾客信息录入对顾客购物信息进行管理

1、2、1顾客退货管理对顾客退货进行有效统计2后台管理系统涉及到超市部经理及部门员工的功能

2、1人事管理涉及超市人事部部经理的功能模块

2、1、1员工信息管理显示员工工作等信息

2、1、2员工操作权限管理规定员工操作守则

2、2销售管理涉及超市销售部部经理的功能模块

2、2、1查询销售信息查看销售人员工作成绩

2、2、2生成销售排行榜对销售人员评优

2、3进退货管理涉及超市货物购买负责人的功能模块

3、2、1进货信息系统查看进货信息

3、2、2退货信息系统查看退货信息

2、4库存管理仓库负责人功能模块

2、4、1库存信息管理查看商品库存信息

2、4、2库存状态警告对货物存量进行分析警告

2、4、2基于项目背景的WBS的细化方案表2-5WBS细化方案项目阶段各活动下的任务任务内容定义责任人需求分析阶段

1、对各个子系统进行需求获取用多种方式进行需求获取朱发军

2、对获得的需求进行确认分阶段的开需求评审会议同上概要设计阶段

1、各个系统的用例描述和图各个系统总的用例，分用例和所有的用例解说同上

2、各个系统的概念数据建模各个系统的E-R模型和UML模型同上

3、概要设计评审分阶段开概要评审会议同上详细设计阶段

1、各个系统对象关系建模各个系统的对象模型建立同上

2、各个系统分析类各个系统的分析类，界面类，控制类同上

3、各个系统设计类设置所有类的属性值，和方法头同上

4、各个系统物理数据库设计对所有关系进行物理数据库同上

5、详细设计评审分阶段开详细评审会议同上编码阶段

1、前台销售管理子系统编码对前台销售子系统的分析类的方法进行编码同上

2、前台销售管理子系统集成对前台销售子系统所有模块进行集成同上

3、后台管理子系统编码对后台管理子系统的分析类的方法进行编码同上

4、后台管理子系统集成对后台管理子系统所有模块进行集成同上系统集成

1、系统集成对各个子系统进行集成同上系统测试

1、集成测试对各个子系统的集成进行测试同上

2、环境测试对发布版本的环境进行测试同上提交

1、编写用户使用手册包括使用的方法同上

2、提供给用户安装程序主要是安装向导同上用户培训

1、给用户进行初期进行系统应用的基本培训同上

2、4、3重要的假设及其说明假设：

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

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

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

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

3实施计划

3、1进度计划此处用甘特图或进度表格描述。

1）进度计划：

表3-1进度计划表任务名称工期开始时间结束时间资源酒店管理系统30dxx-4-26xx-5-26l软件项目规划1dxx-4-26xx-12-24全体人员参与计划评审1dxx-12-16xx-12-24全体人员参与l需求开发1dxx-12-27xx-1-13全体人员参与用户需求评审1dxx-1-3xx-1-5全体人员参与编写需求规格说明书1dxx-1-11xx-1-12全体人员参与用例描述图1xx-1-14xx-1-20全体人员参与概要设计评审1xx-1-28xx-2-3全体人员参与l详细设计1xx-2-4xx-3-4全体人员参与分析类1xx-2-10xx-2-16全体人员参与物理数据库设计1xx-2-23xx-3-1全体人员参与前台销售管理子系统1xx-3-7xx-5-13全体人员参与收银-增量21xx-3-14xx-3-24全体人员参与交易金额计算1xx-3-14xx-3-16全体人员参与打印交易清单1xx-3-17xx-3-18全体人员参与会员卡打折1xx-3-21xx-3-22全体人员参与增量2评审1xx-3-23xx-3-24全体人员参与后台管理子系统1xx-5-16xx-7-13全体人员参与销售管理功能-增量21xx-6-17xx-7-1全体人员参与查询打印销售信息1xx-6-17xx-6-23全体人员参与生成销售排行旁1xx-6-24xx-6-28全体人员参与增量2评审1xx-6-29xx-7-1全体人员参与库存管理-增量41xx-7-27xx-8-8全体人员参与查询库存信息1xx-7-27xx-7-29全体人员参与库存状态自动警告1xx-8-1xx-8-3全体人员参与增量4评审1xx-8-4xx-8-8全体人员参与项目规划xx-12-6xx-12-157，000用户界面设计xx-12-27xx-12-3110，000修改需求、修改用户界面xx-1-6xx-1-104，000需求验证xx-1-13xx-1-134，000l概要设计xx-1-14xx-2-313，000概念数据建模xx-1-21xx-1-276，000对象关系建模xx-2-4xx-2-98，000设计类xx-2-17xx-2-2211，000详细设计评审xx-3-2xx-3-44，000l项目实施xx-3-7xx-11-17210，000后台管理子系统xx-5-16xx-7-1350，000人事管理-增量1xx-7-14xx-7-xx，000销售管理-增量2xx-7-21xx-8-311，000进退货管理-增量3xx-8-4xx-8-1111，000库存管理-增量4xx-8-12xx-8-3013，000后台管理子系统集成xx-9-8xx-9-215，000l系统集成xx-11-18xx-12-2115，000系统集成xx-11-18xx-12-2115，000l系统测试xx-12-22xx-1-3115，000系统测试xx-12-22xx-1-119，000环境测试xx-1-12xx-1-316，000l提交xx-2-1xx-2-75，000完成文档xx-2-1xx-2-33，500验收、提交xx-2-6xx-2-71，500项目开发人员为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软件程序程序名称：

酒店管理系统安装程序所用的编程语言：

VisualBasic存储程序的媒体形式:

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

4、2软件文档验收报告：

客户对产品的验收情况的记录用户安装手册：

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

指导用户怎样使用本系统帮助：

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

4、3软件服务服务名称服务的级别服务开始日期服务期限是否收费安装培训低软件提交给用户时1d不收系统维护高每年寒假开始2d视情况而定运行支持高软件提交给用户时1d不收

4、4非移交的软件产品项目计划质量保证计划配置管理计划项目范围说明书概要设计说明书详细设计说明书设计术语及规范源程序编码规则测试计划测试用例测试报告

4、5验收标准

1、验收测试的对象：

软件包括程序、数据和文档。

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

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

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

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

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

3、验收测试的目的是确认系统是否满足产品需求规格说明和技术合同的相关规定。

通过实施预定的测试计划和测试执行活动确认软件的功能需求、性能需求和文档需求。

安装测试、功能测试、界面测试、性能测试、文档测试、负载压力测试、恢复测试、安全性测试、兼容性测试等。

（1）安装测试：

安装测试的目的在于验证软件能否在不同的配置情况下完成安装，并确认能否正常运行。

（2）功能测试：

功能测试是验收测试中的主要内容。

功能测试要包含以下项目：

单个模块的查询、增加、删除、修改、保存等操作；数据的输入与输出；数据处理操作，如导入、结转等；基础数据定义的精度；计算的准确性，如仓库的历史库存、当前库存、货位库存是否准确；数据共享能力；身份验证和权限管理。

（3）界面测试：

界面要符合现行标准和用户习惯。

软件企业可以形成自己的特色，但要确保整个软件风格一致。

界面测试要从友好性、易操作性、美观性、布局合理、分类科学、标题描述准确等方面入手。

测试用例的设计要重点掌握以下几点：

第一，背景和前景的颜色是否协调，颜色反差是否用得恰当；第二，软件得图标、按钮、对话框等外观风格是否一致，美观效果所要求的屏幕分辨率；第三，窗口元素的布局是否合理，并保持一致；第四，各种字段标题的信息描述是否准确；第五，快捷键、按钮、鼠标等操作在软件中是否一致；第六，窗口及报表的显示比例和格式是否能适应用户的预期需求；第七，误操作引起的错误提示是否友好；第八，活动窗口和被选中的记录是否高亮显示；第九，是否有帮助信息，菜单导航能否正常执行；第，检查一些特殊域和特殊控件能否运行。

（4）性能测试：

性能测试主要测试软件的运行速度和对资源的消耗。

通过调整软硬件配置、网络拓扑结构、工作站点数、数据量和服务请求数来测试软件的移植性、运行速率、稳定性和可靠性。

一般借助WinRunner之类的企业级自动化测试工具来辅助测试，通过极限测试来分析评估软件性能。

（5）文档测试：

文档是软件的重要组成部分，也是软件质量保证和软件配置管理的重要内容。

文档测试主要通过评审的方式检查文档的完整性、准确性、一致性、可追溯性和可理解性。

（6）其他测试：

第一，安全性测试。

通过非法登陆、漏洞扫描、模拟攻击等方式检测系统的认证机制、加密机制、防病毒功能等安全防护策略的健壮性；第二，兼容性测试。

通过硬件兼容性测试、软件兼容性测试和数据兼容性测试来考察软件的跨平台、可移植的特性。

5其他因为项目开发是个循环迭代的过程。

在项目计划编制过程中，存在清楚的依赖关系，原则上要求它们按照基本相同的顺序进行。

但在具体的实现过程中可能会有所变动。

因此项目计划是一个逐步完善的过程。

项目计划的开发是贯穿项目始终的，可以渐进式进行，例如初始计划可能包含资源的属性和未定义的项目日期的活动排序，而后可以细化项目计划，包括具体的资源和明确的项目日期等。