软件项目管理之超市购物系统.docx

软件项目管理之超市购物系统.docx

《软件项目管理之超市购物系统.docx》由会员分享，可在线阅读，更多相关《软件项目管理之超市购物系统.docx（14页珍藏版）》请在冰豆网上搜索。

软件项目管理之超市购物系统

软件项目管理之超市购物系统

软件项目管理

计

划

书

项目名称：

超市管理系统

班级：

xxxxxxxxxxxxxx

姓名：

xxxxxxxxxxxx

学号：

xxxxxxxxxxxxxxx

一、项目名称

超市管理系统

二、项目背景

随着计算机科学技术以及网络技术的不断发展，各个领域都已经展开了信息化建设工作，以便于及时的从外界获取信息和，更好的管理组织，使各项工作都能够得到及时、顺利的开展。

目前各类超市已经成为人们日常生活中必不可少的一部分，如何更好的对超市销售进行管理是超市管理的一个重大问题，因此设计一个可靠、高效的超市销售管理系统是十分必要的。

为了能高效的，有计划设计超市销售管理系统。

本报告的主要作用是确定各个项目模块的设计情况和主要的负责人,供各项目模块的负责人阅读,做到及时协调,按步有序进行项目的开发.减少设计中的不必要损失。

三．项目目标

3.1项目目标的衡量方法

3.1.1多目标性

对一个超市管理系统而言，目标不是单一的，而是一个多目标系统，即销售模块、库存模块、员工模块、进货模块，希望通过整个项目的实施，实现一系列的目标，满足多方面的需求。

但是很多时候不同目标之间存在着冲突，实施项目的过程就是多个目标协调的过程，由同一个层次目标的协调，也有不同层次总项目目标和子目标的协调，项目目标和组织战略的协调等。

项目目标基本表现为三方面，即时间、成本、技术性能（或质量标准）。

实施项目的目的就是充分利用可获得的资源，使得项目在一定时间内在一定的预算基础上，获得期望的技术成果。

然而这三个目标之间往往存在冲突。

3.1.2优先性

　　超市管理系统是一个多目标的系统，不同目标在项目的不同阶段，根据不同需要，其重要性也不一样，例如在启动阶段，可能更关注技术性能，在实施阶段，主要关注成本，在验收阶段关注时间进度。

对于不同的项目，关注的重点也不一样，例如单纯的软件项目可能更关注与技术指标和软件质量。

当项目的三个基本目标发生冲突的时候，成功的项目管理者会采取适当的措施进行权衡，进行优选。

当然项目目标的冲突不仅限于三个基本目标，有时项目的总体目标体系之间也会存在协调问题，都需要项目管理者根据目标的优先性进行权衡和选择。

3.1.3层次性

超市管理系统目标的层次性是指对项目目标的描述需要有一个从抽象到具体的层次结构。

即超市管理系统目标既有最高层次的战略目标，也要由较低层次的具体目标。

明确定义的项目目标按照意义和内容表示为一个递阶层次结构，层次越低的目标描述的应该越清晰具体。

最初步要实现超市管理系统的进货模块、销售模块，次要目标为建设系统的人员管理模块、薪资模块。

3.2确定项目的责任人

3.2.1项目经理

项目经理是在整个项目开发过程中项目组内对所有非技术性重要事情做出最终决定的人。

3.2.2系统架构人员

是在部门内所有软件项目中，对技术上所有重要的事情做出决定的人。

3.2.3需求人员

是项目前期与客户方打交道最多的人，对于客户来说，他可以代表整个项目组，对与项目组成员来说他的意见可以代表客户方的意见，项目组内所有与客户需求相关的事情必需得到他的认可。

3.2.4系统分析人员

是项目组中的首席执行官，他涉及项目的所有方面，是项目进度的推动者，也是项目成功的关键。

3.2.5数据库人员

协助系统分析人员对分模块进行详细设计，并直接管控该模块的进度，对于本模块中所有重要的事做最终决定的人。

3.2.6开发人员

是最终实现代码的成员。

3.2.7测试人员

找到项目中存在的不合理、不合格的部份，测试人员是项目质量的保证，是最终进行项目测试的成员。

3.2.8美工人员

负责完成软件设计师安排的功能界面设计,对项目整体色彩的调配。

3.2.9实施人员

负责制定项目实施计划,在项目实施阶段，跟踪、检查实施人员的工作质量；在实施经理安排和指导下，执行项目用户现场实施任务；

3.3项目所涉及的所有人员

由项目经理负责针对个人不同性格，专业特长，性格进行分组，合理安排人员，保证项目质量与进度。

3.4建立各方通信渠道

手机、EMail、QQ群

四、确定项目结构

4.1建立项目和策略计划的关系，如确定各个项目的顺序

4.1.1注重项目计划的层次性

4.1.2重视与客户的沟通

4.1.3该详细的详细，该简略的就简略

4.1.4制订的项目计划要现实

4.1.5运用过程化的思想指导开发

4.1.6利用成熟的项目管理工具

4.2定义开发过程

4.2.1问题描述

4.2.2可行性分析

4.2.3项目开发计划

4.2.4需求分析

4.2.5概要设计

4.2.6详细设计

4.2.7编写代码

4.2.8软件测试

4.2.9软件维护

（新系统与旧系统通信所需的软硬件标准、变更控制与配置管理标准、质量标准和过程手册、度量程序、项目计划和控制标准）

五、确定项目产品和活动

5.1技术产品、文档产品

采用PBS方法定义

5.2产品流程图

5.3项目活动网络图

关键路径：

A→C→E→H

六、分配资源

编号

主要负责的阶段

花费时间（天）

1

可行性研究以及编写项目计划书

15

2

需求分析

20

3

数据流图

10

4

界面设计

15

5

数据字典

15

6

数据记录整理

15

七、风险分析

7.1确认风险

风

险

类

别

风险描述

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

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

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

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

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

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

最终和户坚持新要求。

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

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

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

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

人事工作比预料的慢。

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

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

7.2风险排队

风险描述

可能性

计划省略是必要的任务。

中

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

中

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

高

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

高

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

中

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

高

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

高

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

中

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

中

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

中

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

高

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

高

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

高

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

中

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

中

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

中

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

中

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

中

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

中

预算削减打乱项目规划。

高

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

高

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

中

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

高

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

低

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

中

未能达到里程碑。

高

商业用户坚持新要求。

中

最终和户坚持新要求。

高

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

低

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

中

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

中

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

中

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

高

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

高

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

中

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

高

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

低

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

中

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

高

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

中

客户坚持新要求。

高

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

低

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

中

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

中

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

中

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

高

小组结构效率低下。

高

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

中

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

高

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

低

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

中

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

高

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

中

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

高

小组成员不买进项目。

低

所需规格缺少增加。

中

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

中

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

中

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

高

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

中

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

高

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

低

项目得不到足够的人员。

中

人事工作比预料的慢。

高

缺少管理承诺。

低

管理费用不合理。

中

7.3风险避免

风险描述

控制方法

人员薄弱

招募顶级人才，培训，团队建设，项目开始前招聘或预定关键成员

承包商失败

检查参考资料，外包前检查承包商的能力，积极管理承包商

设计低劣

要有清晰的设计活动和设计时间，进行设计检查

计划过于乐观

估算要科学，利用工具，借鉴历史数据

质量低劣

制定质量保证计划，落实质量保证计划，安排专人负责质量保证

需求变更

严格的变更控制流程

不切实际的进度

通过协商制定一个更为合理的进度计划，任务并行化，关注关键路径

运用新技术

提供技术培训，进行技术验证

对需求理解不够

加强与用户的沟通，组织领域知识培训，应用快速原型技术

八、结论

通过本次期末作业的总结，我了解了一个完整的软件开管理的过程，包括提出问题、可行性研究，需求分析，概要设计，详细设计，测试工作，进一步完善，设计使用说明书，总结提交实验报告。

以及其中不同人员的不同的工作对整个项目进度产生的影响。

以前我总觉得软件开发是软件生命周期里最重要的，我也认识到这是个错误的想法。

软件开发只是占整个过程的一部分，开发前要有一个严整的软件管理计划。