超市结算系统项目设计方案

1 超市结算系统项目设计方案 1、提出项目 市结算系统 计一个小游戏的应用 开发一个电子商务网站 内容 超市结算系统 小游戏 电子商务网站 项目如何诞生 为 了 方 便 顾 客 付 款 ，收银员的快速结算，以及加快对退货赠品等事项的处理。附近超市提出了开发一个操作便捷，界面清晰的 超 市 结 算 系 统 。 运用已学的知识能够做到 对网站网页的风格设计较感兴趣 项目特征 需求 较易弄清 、涉及的知识面广、具有一定的可操作性 规模小，容易实现 方向难以明确，对安全性，稳定性要求高 生命周期 需求分析、系统的 方案设计、设计系统、结束设计、维护系统 确定游戏类别规模、设计游戏，验证游戏 确定使用人群，需求分析，整体设计，网站详细设计，结束设计，安全维护 项目阶段 1. 需求调查，弄清客户需求 2. 根据客户需求，制定几套设计方案 3. 用户选择方案，查找需要的资料 4. 进行系统设计，并实时修改 5. 客户验收系统，做好相关的维护工作 1. 查找资料选择小型的容易操作的游戏类别 2. 进行游戏的结构设计（包括游戏的计分方法、游戏的模式等） 3. 设计游戏 4. 试玩游戏，检验游戏的稳定性 1. 综 合 团 队 的 意见，确定网站的方向。 2. 进行市场调查，做出需求分析 3. 确定网站的整体风格，网页数等 4. 分配任务进行详细设计 5. 结束设计，进行安全测试，进行网站维护 交付的成果 可供客户方便使用的 超市结算系统 一个简单的射击小游戏 安全稳定的旅游电子商务网站 2、选择项目 2 提出的三个项目具有一定的相似性，都是运用计算相关的知识进行设计开发的。如何选择项目，采用加权评分的方法进行评分选择。 整体分析如下表 备注： 00 到 100 表示程度加深 指标 权重 超市结算 系统 小游戏 电子商务网站 总体规模 20% 80 50 75 知识运用范围 15% 70 30 70 信息收集量 15% 50 30 60 人员数量 10% 30 10 35 时间成本 15% 60 20 70 资金成本 5% 20 10 20 收获 20% 60 30 40 项目权重得分 100% 59 果显示：开发 超市结算系统 的项目权重的 得 分最高，所以选择的项目为 超市结算系统。 3、建立项目组织 目授权 乙方项目授权书 (见附录 1) 项目章程 一、项目概述： 1、项目名称：超市结算系统 2、项目背景： 21 世纪我国的超市产业飞速发展，其经营模式更为复杂，旧的管理体制已经无法适应超市的发展，这就迫切的需要引进新的管理技术。超市的数据和业务越来越庞大，而计算机就是一种高效的管理系统，这就需要我们把超市的管理与计算机结合起来，从而超市管理系统应运而生。依靠现代化的计算机信息处理技术来管理超市，节省了大量的人力、物力，改善了员工的并且能够快速反映出商品的进、销、存等状况和各种反馈信息分析，使管理人员快速对市场的变化做出相应的 决策，加快超市经营管理效率。 3、项目目的： 通过网络传递销售信息可以不受距离的限制的优势，我们可以借阅许多的人力和物力，方便管理，由此可以减少不必要的开支，通过超市管理系统提高超市的销售效率，同时提高超市的经济效益。 4、 项目主要工作： 3 系统计划：问题定义和可行性研究，写出项目计划书和可行性研究报告 系统需求分析：分析目标和任务，画出数据流程图，编写数据字典 系统总体设计：画出系统结构图，找出所有的系统模块，并开始设计数据库，编写概要设计说明书 系统详细设计：画出基本逻辑结构图 ， 构流程图，代码设计，用户界面设计，数据输入与显示，控制界面的设计，系统安全控制设计，编写详细设计文档 系统测试：对系统记性全面的测试 系统实施与维护： 系统的实施以及对系统运行后的维护 二、项目目标： 1、时间目标：本项目要求于 _2014_年 _3_月 _24_日开始，于 _2014_年 _6_月 _1_日结束。项目的结束以正式发布项目结项通知的日期为准。 2、可交付成果目标： 本项目要求最终交付如下的成果： 目应于 2014 年 6 月 29 日前提交 _超市结算系统和用户使用说明 书 _。由 _项目经理 _负责组织评审，须满足的质量要求为： _系统能在三日内快速完成安装， _用户能在15 个工作日内学会使用系统，系统在三个月内能无错的稳定运行 _。 项目应于 2014 年 6 月 29 日前提交 _系统的各项说明书，测试报告 _。由 _项目经理 _负责组织评审，须满足的质量要求为： _系统开发设计过程中的各阶段的文档都有，文档的格式，内容符合规定 _。 目组织结构 项目经理 项目设计主管 项目研发主管 项目生产主管 4 4、项目立项 目名称及来源 项目名称：超市结算 系统 项目属性：虚拟项目 项目发起人及简介： 武汉中商平价连锁分公司（简称 中商平价 ）是武汉中商集团股份有限公司下属的三大连锁公司之 一，是一家以超市连锁经营为主的商业零售企业。 中商平价成立于 2000 年，经过近 8 年的不断发展，目前已发展成为拥有连锁门店 30余家，网点遍布湖北武汉、襄樊、荆门、荆州、仙桃、黄石、黄冈、大冶等 12 地市，年销售达 35 亿元的大型连锁企业，在华中地区位于前三甲，旗下年销售过亿元的综合型大卖场6 个，社区超市和区域公司购物广场 24 个，总经营总面积达 35 万余平方米。 武汉中商平价超市连锁有限责任公司（简称中商平价），是大型上市企业武汉中商集团股份有限公司旗下的全资子公司，是主营超市业态的现代化连锁商业企业。 位于民族大道的中商平价曙光超市也是武汉中商平价连锁超市中的一家。其重要面对的客户群为周边的学校的学生和居民。因此其产品类型有限。为了方便顾客付款，收银员的快速结算，以及加快对退货赠品等事项的处理。超市管理人员提出了开发一个操作便捷，界面清晰的超市结算系统。 拟 定 甲 方 招 标 书 （ 见 附 录 ） 拟 定 乙 方 投 标 书 （ 见 附 录 ） 项 目 合 同 目利益相关者分析 利 益 相 关 者 ：曙 光 超 市 的 管 理 人 员 、收 银 员 、顾 客 ，项 目 团 队 我们项目组。 关 键 项 目 利 益 相 关 者 分 析 表 因素 超市的高层管理人员 收银员 项目团队 系统安全性 需要良好的系统安全性，保障超市信息的系统便于灵活运用，不会出现死机、卡机、根据客户的要求，采取一定的措施，确保系统 5 安全。需要仔细的探讨安全性。 或商品信息录入错误等 安全。可能对项目完成的时间，所需的成本有一定的影响 系统的总体开发时间 过长无法尽快使用，过短对系统的稳定性不放心 在软件开发时期，可以用已有的软件暂时代替，所以影 响不大 需要把握好开发时间，时间越长可能开发的系统效果越好，但成本也会加大 系统操作的难易程度 操作简便的系统，便于管理者提取信息，制定计划 便于操作的系统能过加快结算的速度，提高工作效率 简便的操作界面，对开发的要求提高，需要不断完善 系统开发的模型选取 无影响 无影响 采用快速原型法，更好的了解客户需求，设计出客户需要的系统 选取原有系统作为参照 能过减少系统开发的资金投入，便于理解使用 便于理解，能尽快的掌握，但可能出现操作失误 增加了开发的工作量开发的难度减弱 系统成功开发的标准 客户的消费 信息能够准确的录入，信息统计分类准确，系统稳定 便于理解操作，系统稳定 达到客户要求，系统安全稳定 定项目的生命周期 将整个项目分为如下几个阶段： 阶段 简介 备注 项目启动 里程碑 识别客户需求 系统需求分析报告 对系统进行客观完整的描述 项目计划 里程碑 6 分析项目实施的条件需求，判定项目能否实现 可行性研究报告 对系统进行初步设计 相应的设计文档 对系统进行具体明确的设计 详细设计文档 项目实施 里程碑 1.对系统进行实现 完整的超市收银系统 测试系统的性能，安全性等方面 测试报告 用户验收 交与客户验收 对系统进行维护 佳管理实践 企业团队的管理最终是对人的管理。很多成员除了对物质利益的需求以外，还需要提升自我，实现自我价值。因此团队的管理采用人性化的管理方式，根据不同成员的个性特点分配相应的任务，发挥他们的主观能动性，营造一种积极活跃的团队氛围。 5、项目范围管理计划 目章程： 7 8 6、 项目时间管理计划 目进度计划 目活动的依赖关系 在甘特图中，确定各个子项目的依赖关系，由前置任务可以看出，在项目过程中，基本按照项目的流程进行，如图所示： 图一 动历时 活动从 2014 年 3 月 24 日开始， 2014 年 6 月 1 日结束。总历时 50 个工作日。 其中启动项目 3 个工作日、编制项目计划 3 个工作日、执行任务 23 个工作日、控制任务 5 个工作日、结束任务 15 个工作日。 导式网络图 9 图二 图三 定关键路径和时差 由甘特图所示，确定的关键路径如图 10 图四 根据甘特图上各个子任务的状态，确定最早开始时间和最晚开始时间，由于项目主要是按照项目分解的流程工作，所以项目的自由时差和总是差相对较少，下图为截图： 图五 定里程碑 11 3 月 31 日完成需求调查，结束需求报告的撰写 4 月 13 日完成总体设计，提交总体设计报告 5 月 11 日系统设计完成 5 月 18 日完成系统安装 细项目进度计划 对于项目的详细进度，主要包括各个子任务的工作时间、总工程历时和里程碑任务的提交时间，如图所示 图六 12 ： 图七 图八 13 显示关键路径： 图九 时差： 图十 佳管理实践 利用软件开展项目的时间管理，协助沟通的软件能够帮助项目经理同项目的利益相关者交换与进度有关的消息，决策支持模型能够帮助项目经理分析权衡各种进度方案。 14 3、项目工作分解结构（ 1、 项目启动 2、 启动任务 项目发起人的启动会议 究类似项目 拟项目要求 定项目章 程 署合同 3、 编制任务计划 统计划 统定义 行性分析 写项目计划书 统需求分析 求调查 4、 执行任务 析任务 究旧系统 计任务 细设计 块设计 5、 控制任务 览报告 统测试 6、 结束任务 户验收 收系统 付各阶段相关报告 7、 结束项目 15 7、 项目成本管理计划 本估算 同成本估算 根据以往类似的项目经验，通过类 比估算方法，对项目进行了粗略的成本估算，对于此次项目的估算金额为 。 细成本估算 制定资源计划，进行资源分配 “ 超市结算系统 ” 项目的资源数据库 资源名称 标准工资率（元 /小时） 加班工资率（元 /每小时） 项目经理 业分析员 据库分析员 术人员 超市结算系统 ” 项目的资源分配 工作任务 资源分配 与项目发起人的启动会议 项目经理 50%,数据库分析员 50%,商业分析员 50%,技术 16 人员 50% 草拟项目要求 商业分析员 ,项目经理 50% 制定项目章程 项目经理 系统定义 项目经理 可行性分析 商业分析员 50%,数据库分析员 50%,技术人员 50% 编写计划书 项目经理 ,技术人员 50% 进行需求调查 商业分析员 撰写需求报告书 商业分析员 ,项目经理 50% 研究旧系统 项目经理 50%,技术人员 设计系统模块 数据库分析员 ,技术人员 模块具体设计 技术人员 ,数据库分析员 模块间接口设计 技术人员 编码 技术人员 系统测试 项目经理 ,技术人员 检查各阶段的报告 项目经理 验收系统 项目经理 交付系统相关报告 项目经理 系统维护 技术人员 确定每项活动的成本： 工作任务 成本 与项目发起人的启动会议 ￥ 拟项目要求 ￥ 定项目章程 ￥ 署合同 ￥ 统定义 ￥ 行性分析 ￥ 写计划书 ￥ 行需求调查 ￥ 17 撰写需求报告书 ￥ 究旧系统 ￥ 1,计系统模块 ￥ 2,块具体设计 ￥ 3,块间接口设计 ￥ 1,码 ￥ 1,统测试 ￥ 3,查各阶段的报告 ￥ 收系统 ￥ 付系统相关报告 ￥ 统维护 ￥ 3, 确定项目总成本：项目总成本为￥ 21,本预算 目详细成本计划 18 资源分配 项目成本计划 19 值分析 入实际数据 在实际进度中，项目已经实施完成了编制任务计划阶 段，而接下来的任务便是执行任务。下图为输入项目实际进度与成本信息时的甘特图 到跟踪甘特图 20 行挣值分析 全部盈余分析如下图所示 续应对措施： 通过 的跟踪甘特图以及 目详细成本的比较得出，项目的整个进展过程相对较有序，并且在严格按照 的计划在执行，但是，我认为，在后期的工作中可以对于项目的进度进行调整，可以一最好的效率完成此次项目。 佳管理实践 在项目的实施过程中要注意项目进度的管理，一个项目的实施进度最先影响到项目的 成本，所以，在一个项目小组中，各个人员要懂得配合以及团结，以整个项目的进展为前提展开项目的实施，才能高效率高质量的完成项目。 8、 项目质量管理计划 量目标 （ 1）产品的质量标准 a) 满足客户的需求 ; b) 能在有系统故障或者、数据输入无效或操作等意外环境下，系统能做出适当的响应； c) 有足够的计算机资源来完成预定的功能； 21 d) 能够有效的控制未经授权的人使用软件或者数据； e) 能使用户较轻松的理解和使用该系统； f) 在一定程度上能够诊断和改正错误； g) 能够修改或改正在运行的系统需要的工作量； h) 可测试； i) 能被其他相关的程序再次使用； j) 较同类产品相比价格低廉、系统稳定； k) 按时完成系统并及时维护升级。 （ 2）项目质量标准 a) 按时完成任务并提交相关文档； b) 符合开发企业的行业技术标准； c) 项目具有良好的保密性； d) 有良好的技术性能。 量策略 选择合适的开发技术； 做好项目开发人员的培训； 做好用户的使用培训； 向用户灌输质量观点； 在项目进行的过程中进行过程规划等一系列的活动； 确定相关的质量标准。 量保证活动 在产品的开发设计阶段，采取措施减少由于设计原因为产生的质量隐患； 在管理过程中不断对产品的质量进行多方面的检测，并及时 作出反馈； 跟踪问题的解决情况； 收集新方法，提供过程改进的依据； 在产品制成后进行检测。 量控制活动 A. 技术评审：评审的对象包括软件需求规格说明书、软件设计方案、测试计划、用户手册、维护手册、系统开发过程、产品发布说明等； 22 B. 代码走查：以此检测其他此时方法无法检测到的错误； C. 代码会审：由一组人通过阅读、讨论和争议对程序进行静态分析； D. 软件测试； E. 缺陷追踪。 量保证的报告途径 做书面的产品设计和产品开发的报告，并通过小组会议进行评审； 管理过程中定时进行检测，并及时以书面或者口头方式向项目经 理做汇报； 项目经理对于已经检测到的错误进行监督和跟踪，并做好记录； 对于改进的过程，进行小组的评审，评审通过后以书面形式对新技术以及改进的过程做出书面报告，递交至上级； 产品制成，进行测试，对于测试的结果以书面形式进行汇报。 录的收集、维护和保存 项目经理负责对各类报告以及各项评审的内容、过程及结果进行收集和保存。 佳管理实践 有效提高交付成果的质量则需要： 通过强有力的领导，从上至下贯彻质量观念； 建立组织项目管理体系； 建立项目级的激励制度，并设法和鼓励全员参与管理； 着力提高项 目实施过程中产生的各种文档的质量； 用规范的程度度模型来指导自身的组织和体系结构建设； 掌控好质量与成本的关系，在有限的成本下尽量通过良好的管理来实现更高的质量； 形成质量改进的习惯，真正发挥质量改进的作用。 23 9、 项目人力资源管理计划 任分配矩阵 9 责任分配矩阵 上图为责任分配矩阵， R 表示责任组织部门， P 代表执行组织部门。把 动工作分配到组织的单位部门中。 在主要的分配过程中，按照部门的职能划分相应的责任和执行的责任，例如在 需求分析 系统开发 测试工程 结束验收 P P P P P P P R P R P R P R P R P R P R P R P R P R P R P R P 24 中的 统测试，此次活动的责任组织部门和执行组织部门都是测试工程，是按照部门的功能确定的。 力资源管理 建资源日历 创建资源日历，输入事件的名称、开始时间和结束时间，在事件的名称下面输入愚人节，把时间设置为四月一日开始，并在四月一日结束。 析资源使用情况 在视图的资源使用状况中查看资源的使用状况，本项目没有出现过度使用资源的状况，在资源的分配 上比较合理的平衡资源。 源平衡 如出现资源的过度使用可以通过视图 资源管理操作，会出现资源管理工具， 25 此时会弹出资源分配视图查看。 目人员计划 在资源管理的调配中可以在工具 资源调配的方法进行资源的分配。 佳管理实践 最佳管理实践也可以通过资源分配的方法来选出最适合工作的地方，在课本中最佳实践中公司通过其雇员的意见来制作最佳雇主的排行榜。 26 10、 项目沟通管理计划 项目沟通管理计划是对于项目全过程的沟 通工作，沟通方法、沟通渠道等各个方面的计划与安排。 目进程中的信息类型 文本信息：项目章程、合同、计划书、需求报告书、阶段测试报告、系统的相关报告等。 实时信息：项目各阶段的实施情况、进程中出现的问题、任务的完成情况、项目干系人与项目团队的沟通情况、成本与时间的进行情况等等。 目信息实时查询和管理方法 息查询方式 通过电子邮件、询问项目经理或项目组成员、 话、微信等实时聊天工具进行查询。 息更新和发布方式 通过召开全体会议、电子邮 件、群通话、电话通话进行信息的更新和发布。 目组成员的沟通方式 正式沟通：通过召开会议、发送电子邮件的方式进行正式沟通。 非正式沟通：通过面对面、电子邮件、电话、第三方转达或 信等实时聊天工具进行沟通、。 目交流会议计划 召开项目的周例会，在每周五的下午四点到六点，讨论本周的项目进行情况、问题处理情况、成本与时间的花费情况，下周工作安排与重大信息的发布，记录会议中的问题解决方法。 题报告制度 项目发起人 项目经理 高层领导 开发小组 27 问题报告 由开发小组向上逐级上报，如在上一层解决反馈回来，则终止上报。问题的反馈也是逐级反馈的。 目报告制度 项目报告制度由项目组向项目经理与高层管理人员报告。主要是通过会议进行项目的报告。 佳管理实践 阿拉斯加航空公司使用基维百科后促进了项目沟通与合作。基维百科给项目管理带来的益处包括，更优质的文件，提高了信任度和文件共享度，持续增长的信息和链接。 项目发起人 项目经理 高层领导 开发小组 28 11、项目风险管理计划 别计划 序号 风险识别 风险评估 风险应对措施 潜在的风险事件 风险发生的后果 可能性 严重性 风险值 风险等级 应对措施 预防措施 1 需求不明确 客户不接受产品或拒绝付款 00 派遣经验丰富的需求分析师与客户进行深入的交流，明确客户的主要需求，引导客户对项目做出正确的描述。 事先进行需求评审 2 项目范围定义不明确 项目没完没了 60 要求需求小组按照客户的要求变更项目范围。 需求要在事先定义清楚并获得客户的确认。 3 项目目标不明确 导致项目进度拖期或成本超支。 40 修改项目目标。 事先明确项目目标 4 与客户沟通不够 软件不能满足客户需求 70 立即与客户进行沟通 制定沟通管理计划 5 需求小组对客户业务了解不够 软件不能实现业务功能 70 修改软件 加强与了解并让客户参与 6 需求小组没有真正理解客户需求 软件不能萍踪客户需求 0 8 560 根据客户需求修改 让客户确认需求报告 7 需求分析报告没有得到客户的确认 客户拒绝签字、验收 0 5 250 取消项目或修改项目 事先获得客户确认 29 8 需求不断变化 项目变得没完没了 60 提交 论、决定 建立范围变更程序 9 缺乏有效的需求变化管理过程 项目不能按时、按预算完成 4 160 对需求变化进行评审 建立需求变更程序 10 任务定义不够充分 项目不能按时、按预算完成 40 重新定义 事先与客户达成共识 11 缺乏有经验的分析员 分析错误或不可行 0 4 200 培训或换人 配备有经验的分析员 12 设计偏 离客户需求 软件不能萍踪需求，客户拒绝接受 0 5 250 修改设计 进行设计评审 13 软件功能漏项 客户不满意 60 增加相应的功能 进行设计评审、获得客户确认 14 程序员对系统设计的理解上出现偏差 软件实现不了设计的功能，客户拒绝接受 08 修改代码 进行设计评审 15 程序员开发能力差 项目进度拖期 60 培训或换人 配备精兵强将 16 程序员不熟悉开发工具 项目进度拖期、质量问题 6 立即改 进 提前准备 17 设计错误导致编码实现困难 质量问题 0 4 200 修改设计 编码之前进行设计评审 18 客户要求增加功能 项目进度拖期、成本超支 80 修改程序 事先确定范围目标 19 项目将会时间提前 质量问题 60 加班加点或增加资源 合同固定交付时间 20 程序员离开 项目执行不下去 0 5 200 临时替补人 与相关人员签订合同 21 开发团队内部沟通不够 接口混乱、质量问题 4 164 修改程序 制定内部沟 通计划 30 22 没有切实可行的测试计划 项目拖期、质量问题发现不了 0 修改测试计划 事先评审测试计划 23 测试人员不能按时到位 项目进度拖期 2 临时安排测试人员 制定出人力资源计划 24 测试人员经验不够 程序问题发现不了 2 培训或换人 选择有经验的人员 25 测试设备故障 项目拖期 6 修理或换设备 加强设备预防性维修 26 测试期间出现重大问题 客户拒绝接受产品 0 4 200 修改程序 分 步测试 27 没有有效的备份方案 数据丢失无法挽救 06 重新开始 异地双重备份 28 测试发现的问题迟迟解决不了 项目进度拖期 35 加快解决 专家会诊解决 29 设备不能按时到位 项目进度拖期 2 催设备供应商 提前采购或合同约束 30 运行时质量问题多 客户投诉 72 即时解决问题 事先进行局部运行 31 客户突然要求增加功能 项目进度拖期、成本超支 80 作出相应修改 事先确定项目 范围和功能要求 32 重要的记录、文件、数据丢失 客户投诉、要求赔偿 35 重新生成数据 做好备份 33 系统崩溃 客户要求承担损失 0 2 60 加紧修复 事先备份 34 出现故障，用户维护人员解决不了 客户投诉 12 派技术人员帮助解决 事先培训客户系统维护人员 35 用户手册错误多 客户投诉 2 修改错误 专人检查 36 培训手册没有按时准备好 客户投诉，培训不能按时进行 5 加班加点准备 提前 准备出来 31 险级别分析 概率 阵图 概率 高 中 高 13 47 810 影响 险等级 37 培训效果差 客户不满意 4 重新培训 确定标准、充分准备、把好培训师质量关 风险 18 风险 2、 6、 8、 34 风险 24 风险 1、 3、 4、 5、 7、 9、10、 11、 12、 13、 14、 15、17、 19、 20、 21、 26、 30、32 风险 23、 35、 36、 37 风险 16、 22、 25、 27、28、 29、 32、 33 32 败的后果 险清单 排序 风险序号 风险事件 可能性 影响程度 风险值 风险级别 风险应归措施 1 6 需求小组没有真正理解客户需求 0 8 560 要求需求小组按照客户的要求变更项目范围。 2 2 项目范围定义不明确 60 需求要在事先定义清楚并获得客户的确认。 3 8 需求不断变化 69 提交 论、决定 高风险 低风险 中度风险 33 佳管理实践 1、人力资源风险的应对措施 （ 1）和有关资源部门充分沟通，达成共识，建立人员的稳定和释放机制，在开发周期 内保持人员的相对稳定，资源线调动资源需要和产品部协调，并将此作为产品线考核资源线的一个指标。 （ 2）针对人员缺乏经验，需要进行系列的培训组织，保证项目开发人员及时了解产品知识。工作交接规范化，保证产品开发不会因为人员变动受到大的冲击。 （ 3）对项目组进行良好组织，使得每一个开发活动的信息能被广泛传播和交流。 （ 4）对所有工作进行详细复审，避免只有一个人熟悉该项工作情况出现。 4 34 出现故障，用户维护人员解决不了 12 要求需求小组按照客户的要求变更项目范围。 5 18 客户要求增加功能 80 修改程序 6 31 客户突然要求增加功能 80 作出相应修改 7 14 程序员对系统设计的理解上出现偏差 08 修改代码 8 5 需求小组对客户业务了解不够 70 修改软件 9 10 任务定义不够充分 40 重新定义 10 3 项目目标不明确 40 修改项目目标 34 （ 5）对于每一个关键技术岗位都指定一个后备人员 2、对于需求变动的缓解措施 （ 1）在进行需求分析时和 市场人员甚至用户进行充分沟通。 （ 2）定出基线进行详细评审。 （ 3）周知版本计划，并用市场销售指导书指导市场人员签单时注意公司产品的规格，引导用户 （ 4）严格控制需求的变更，建立需求变更控制机制 （ 5）及时调整计划；并周知所有项目有关人员 3、对于技术因素的缓解措施 （ 1）使用模块化、层次化开发模式，尽量降低系统复杂性 （ 2）加强评审 4、 进度风险的缓解措施 （ 1）强化周报，月报，例会等措施 （ 2）定期（如月）更新日程表 5、 商业风险的缓解措施 （ 1）重点关注关键路 径 （ 2）客户定期，充分沟通 12、项目采购管理计划 由于项目所需的工具都具有，所以为做采购计划。 35 13、项目配置管理计划 言 的 本计划的目的在于对所开发的超市进销存软件规定各种必要的配置管理条款，以保证所交付的超市进销存软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本 计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 义 本计划中用到的一些术语的定义按 11457 和 12504。 织及职责 求：在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。 工及其职责 （ 1） 组长：李升娟 总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和 评审负责； 负责监督在软件配置管理工作中认真执行软件工程规范； （ 2）项目的专职配置管理人员：罗韵熙 检查在作配置更改时的质量保证措施； （ 3）各子系统的配置管理人员 具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查； 36 （ 4）用户代表：美丽 负责反映用户对配置管理的要求，并协助检查各类人员对软件配置管理计划的执行情况； （ 5）项目专职的配置管理人员：张泽慧 协助组长开展各项软件配置管理活动，负责审查所 采用的配置管理工具、技术和方法，并负责汇总、维护和保存有关软件配置管理活动的各项记录。 置管理环境 遵守如下标准、条例和约定： A 软件开发库、软件受控库与软件产品库的操作规程与管理规程； B 系统、子系统、模块和程序单元的命名约定； C 文档和测试用例的命名和管理规程。 这引起命名约定、操作规程与管理规程应由 目技术组负责制订，并应认真听取各子系统项目负责人的意见，最后报项目总体组审批。在执行过程中，如果发现某些条款需要修改，则必须办理正规的审批手续，最 后要经项目总体组批准。 置管理活动 1、 配置标识 （ 1）文档 所有为本项目编制的文档，都要符合规定。超市进销存软件系统及其所属的各个子系统所编写的文档数目，可根规定作适当的剪裁。剪裁方案由技术组提出建议，报总体组批准。 （ 2） 程序 所有属于本项目的程序、分程序、模块和程序单元，都要按照由项目技术组制订，且经总体组批准的软件系统的命名约定的规定来标识。 （ 3） 各类基线 37 所有属于本项目及其各子系统的各类基线，首先要按照任务书、软件需求规格说明书的规定确定其技术内容，然后按照软件系统的 上述命名约定的规定来标识。 2、 配置控制 软件配置的更改管理适用于本项目的所有文档和代码，其中包括本项目的各个运行软件，也包括为本项目专门开发的支持软件。配置控制的要点如下： A 修改批准权限；对本项目各个子系统及其专用支持软件的功能基线、指派基线、产品基线及其集成系统的任何修改（称为 A 类修改），都必须通过项目配置管理小组讨论，并必须经总体组批准；对本项目各个子系统及其专用支持软件的其他阶段产品的任何修改（称为 B 类修改），都必须通过本项目各个子系统的配置管理人员审查，并经项目的软件配置管理小组与各个 子系统负责人的共同批准并报项目总体组备案。 B 修改审批程序：上述两类修改的审批程序如表 1。 C 修改控制工具：修改控制工具是协助软件配置管理人员进行配置控制的有效手段。 3、配置状态审计 利用软件问题报告单和软件修改报告单对项目子系统及其支持软件的配置状态进行追踪。对软件问题报告单和软件修改报告单的追踪应由软件配置管理工具自动实现，用户可通过该软件系统对其进行查询。 4、 配置的检查和评审 项目软件配置管理小组要对所有由第三方提供的软件进行物理配置检查；对本项目及其各个子系统的 每一个新的释放进行功能配置检查和物理配置检查；对宿主计算机系统所提供的软件和硬件配置要每隔半年检查一次；在软件验收前要对宿主计算机系统、各个子系统及其专用支持软件的配置进行综合检查。 38 在软件开发周期各阶段的评审与检查工作中，要对该阶段所进行的配置管理工作进行必要的评审和检查。应该进行评审与检查的内容与次数，由超市进销存软件质量计划规定。 置管理计划 在实现软件配置管理计划的过程中，要特别注意实现以下三个里程碑： 1、 建立软件配置管理小组：在项目总体组批准软件配置管理计划之后，立即成立软 件配置管理小组； 2、 建立各阶段的配置基线：随着超市进销存软件系统及其所属各子系统的任务书的评审和批准，建立起功能基线；随着总体组编写的超市进销存软件需求规格说明书的批准，建立起指派基线；随着超市进销存工程化软件系统的集成与系统测试的完成，建立起产品基线。 3、 建立软件库：在本项目所属的各个子系统的研制工作的开始，就建立起各个子系统的软件开发库，并在本项目配置管理小组的计算机上建立起有关该系统及其子系统的软件受控库。以后在每个开发阶段的结束，建立各个子系统的新的开发库，同时把这个阶段的阶段产 品送入总的软件受控库，并在各个子系统的计算机上建立软件受控库的副本。软件受控库必须以主软件受控库为准。当全部开发工作结束，在配置管理小组的计算机上建立起软件产品库，并在各子系统的计算机上建立软件产品库的副本。 佳管理实践 在本项目及其所属的各个子系统的研制与开发期间，要进行各种软件配置管理活动。准确记录、及时分析并妥善存放有关这些活动的记录，对这些软件的下沉运行与维护工作十分有利。在软件配置管理小组中，应有专人负责收集、汇总与保存这些记录。 1、 基础上组装系统、各个子系统、专用支持软 件及选用软件的功能基线、指派基线与产品基线要送入软盘或磁带，至少必须一式两份且存放在两个不同的地点。这些记录应该每6 个月拷贝一次，以免意外损伤与自然老化。 39 2、上述这些软件的文档也应送入软盘或磁带，至少必须一式两份且存放在两个不同的地点，并应有一份打印的硬拷贝。磁媒体应该每隔 6 个月拷贝一次，以免意外损伤与自然老化。 3、 软件产品的源程序、测试数据、测试报告及其他有关文档，除了按 A、 B 规定妥善存放外，要在项目结束后再保存 2 年，或在条件成熟时转交给这些软件产品的生产系统。 注：具体保存年限要根据项目的性质与开 发单位的任务来确定，此处仅作为一个示例。 4、上述这些软件的各项配置的个性状态、评审记录与修改历史，要作为这些软件的历史记录来保存，目前可用打印硬拷贝一式两份存放，有条件时再转移到在线光学存储媒体中。 5、鉴于处理版权或清理财务的需要，本软件系统的各项配置可能要求存放 5，但由于我国对这些问题尚无明确的规定，因此，有关本条款的具体规定待将来有必要与可能时再作修改与补充。 14、项目集成管理计划 导言 超市结算系统的目的是是实现超市结算过程中自动化所需要的一切功能，包括管理货物，支持 用户结算，统计货物销售情况等。系统将提供给超市前台，会计以及经理等管理人员使用，进行日常任务，工作的管理，提高工作效率。同时将实现各项功能的完善封装以及建立友好的图形用户界面使得用户能较快的上手使用。 项目目标 间目标：本项目要求于 _2014_年 _3_月 _24_日开始，于 _2014_年 _6_月 _1_日结束。项目的结束以正式发布项目结项通知的日期为准。 交付成果目标： 本项目要求最终交付如下的成果： 1 项目应于 2014 年 6 月 29 日前提交 _超市结算系统和用户使用说明书 _。由 _项目经理 _负责组织评审，须满足的质量要求为： _系统能在三日内快速完成安装， _用户能在 15 个工作日内学会使用系统，系统在三个月内能无错的稳定运行 _。 40 2. 项目应于 2014 年 6 月 29 日前提交 _系统的各项说明书，测试报告 _。由 _项目经理 _负责组织评审，须满足的质量要求为： _系统开发设计过程中的各阶段的文档都有，文档的格式，内容符合规定 _。 费用目标： 本项目总预算为：￥ 用预算明细请见 下表 。 工资成本： 资源名称 标准工资率（元 /小时） 加班工资率（元 /每小时） 项目经理 业分析员 据库分析员 术人员 目活动成本： 工作任务 成本 与项目发起人的启动会议 ￥ 拟项目要求 ￥ 定项目章程 ￥ 署合同 ￥ 统定义 ￥ 行性分析 ￥ 写计划书 ￥ 行需求调查 ￥ 写需求报告书 ￥ 究旧系统 ￥ 1,计系统模块 ￥ 2,块具体设计 ￥ 3,块间接口设计 ￥ 1,码 ￥ 1,统测试 ￥ 3,查各阶段的报告 ￥ 41 验收系统 ￥ 付系统相关报告 ￥ 统维护 ￥ 3,目总预算成本： 在实施整个项目过程中，项目经理应该把好每个关。 1、 需求管理策略 在实施项目时，项目需求变化过于频繁，缺乏有效的管理机制，势必造成重复的实施活动，严重影响项目进度和质量。 根据前期达成的共识，以及客户对个性化需求的投入情况，项目经理要根据项目的投入产出、质量、长期利益等方面权衡，制定对个性化需求的平衡和决策策略。 求识别：在意向提出阶段，业务部门应发现用户的大部分潜在需求，并提出建设需求业务建设的期望。 需求分析：对变更的需求进行分析，判断新的需求是否合理，是否符合新的规划，对于不符合要求的业务需求要做出相应处理，与用户及时协商，舍去或寻找替代业务。 42 2.、 项目推动策略 当项目出现以下现象（或状态）之一时，项目经理需要择机启动项目专项推进计划，协调各方面力量，要