课程设计(报告)
药品进销存管理系统项目管理书
课程名称 | 软件项目管理 |
学院 | 计算机学院 |
专业 | 软件工程 |
年级班别 |
|
学号姓名 |
|
指导教师 |
|
2023年11月
目录
- 项目初始
- 立项建议书
项目名称: | 药品进销存管理系统 | |||
项目背景: | 系统管理也都将通过计算机进行整体智能化操作,对于药店药品进销存管理系统所牵扯的管理及数据保存都是非常多的,这给管理者的工作带来了巨大的挑战,面对大量的信息,传统的管理系统,都是通过笔记的方式进行详细信息的统计,后来出现电脑,通过电脑输入软件将纸质的信息统计到电脑上,这种方式比较传统,而且想要统计数据信息比较麻烦,还受时间和空间的影响,所以为此开发了药店药品进销存管理系统;为用户提供了方便管理平台,方便管理员查看及维护,并且可以通过需求进行设备信息内容的编辑及维护等;对于用户而言,可以随时进行查看销售信息和进货信息,管理员可以足不出户就可以获取到系统的数据信息等,而且还能节省用户很多时间,所以开发药店药品进销存管理系统给管理者带来了很大的方便,同时也方便管理员对用户信息进行处理。 | |||
存在问题: | 数据存储能力方面有所不足; 当数据量太大后可能影响系统运行响应速度。 | |||
解决思路: | 增设数据库存储服务器,提高数据存储能力; 优化代码,提高数据处理响应速度。 | |||
进度安排: | (一)项目前期工作 1、由XX大学软件工程四班对本项目进行规划设计,提出本项目建设方案。 2、由学校独资注册,申报建设项目。 3、完成其它立项报建的前期工作。 (二)项目实施进度安排 | |||
预期成果: | 此系统可以实时监控药品库存,确保药店随时能够满足客户需求,同时避免过多库存或过期药品的情况, 分析销售趋势和客户需求,优化采购计划,减少因库存不足或过剩而导致的损失,提高供应链的效率。确保药品储存、销售等环节符合法规和合规要求,降低违规风险,保障药店业务的合法性和可持续性。 | |||
资金预算: | 40万元 | |||
效益分析: | 系统能够实时跟踪库存水平,确保药店具备足够的药品以满足客户需求,同时避免库存积压或过期药品的情况。通过系统,药店能够更好地管理供应链,及时调整采购计划,减少因库存不足或过剩而导致的损失,并优化库存周转率。 | |||
| 评审意见: | 该项目使用的技术比较先进,能够提供较好的使用体验和功能实现,即使市面有这一类的软件,也是能够有一定的市场和投入与使用意义。 | ||
| 评 审 人: |
| 评审时间: | 2023.9.21 |
-
- 招标书
项目名称 | 药品进销存管理系统 | 标书编号 |
|
发标单位 | XX大学 | ||
项目概述 | 通过系统实现药品库存的实时监控,确保库存精确无误,通过分析销售趋势,优化采购计划,提高供应链效率,确保所有药品销售和储存活动符合相关法规和合规要求,自动化销售、采购和库存管理,提高工作效率,提供准确的库存信息,实现更高水平的客户服务。能够同时给2w人使用。 | ||
技术参数 |
2.系统必须是符合国际标准的代表未来发展主流方向的、结构化的、模块化的、稳定可靠的、实用的产品。功能模块明确,使用简单容易上手。 | ||
合格投标人 | 凡具有法人资格,有生产或供应能力的国内企业(实行生产许可证制度的须持有生产许可证),在国内注册的外国独资或中外合资、合作企业,符合并承认和履行招标文件中的各项规定者,均可参加投标。 |
-
- 投标书
1.投标总报价表
项目名称: 药品进销存管理系统 标书编号:
序号 | 项 目 | 内容/金额 | ||
1 | 投标总价 | 小写 | 大写 | |
300000 | 叁拾万 | |||
2 | 服务期限 | 项目验收后 10 个日历日 | ||
3 | 质量承诺 | 按照标书以及合同要求,按质按量完成项目 | ||
4 | 投标保证金 | 金额 | 1000 | |
形式 | 现金 | |||
5 | 说明 | 无 |
备注:详细内容见《投标明细报价表》,报价币种为人民币,金额单位为元。
2.投标明细报价表
项目名称: 药品进销存管理系统 标书编号:
模块 | 功能/内容 | 金额 |
库存管理模块 | 实时跟踪药品库存,包括入库、出库、库存调整等功能。 | 60000 |
销售采购模块 | 支持销售订单的生成、采购计划的制定,管理销售和采购流程。 | 60000 |
合规性模块
| 确保所有活动符合相关法规和合规性要求,包括药品的储存条件、销售记录等。 | 60000 |
报告分析模块 | 提供丰富的数据分析和报告功能,帮助决策制定。 | 60000 |
服务器 | 需要多个能够用于部署本系统的服务器,提高系统的性能。 | 30000 |
开发软件和一些使用的资源 | 使用到的开发软件、数据库等技术类资源 | 30000 |
|
|
|
总体项目报价(人民币): | 300000 |
3.投标技术条款偏离表
项目名称:药品进销存管理系统 标书编号:
序号 | 条款名称 | 招标文件要求 | 投标文件响应情况 | 偏差 情况 | 说明 |
1 | 使用人数 | 同时在线1W人 | 同时在线5k人 | 5k人 | 因为本系统主要是药店员工进行使用,实际上的同时在线人数不会太多,所以进行一个降低 |
2 | 系统功能 | 系统功能必须是完善的,能够为用户提供一系列的功能,从求职到应聘等等一系列流程都应该考虑在内存 | 开发的功能完善,能够实现从求职到应聘再到之后的沟通交流等等 | 相符 |
无 |
4.标书评审表
投标项目 | 疫情下的招聘网站系统 | 标书编号 | GDUT2023-CHG-W-2 |
项目分类 | 商业软件项目 | 记录人 | 张三 |
会议时间 | 2023.9.20 | 会议地点 | XX大学 |
标书制作人员 | 张三 | 标书评审人员 | 李四 |
会议评审纪要:张三 | 修改反馈 | ||
终审: |
| ||
★否决项: |
| ||
1、在线人数容量要达到2w | 修改成1w | ||
2、后端的java框架不要使用ssm框架 | 使用集成度更高的springboot模块 | ||
3、说明书的排版问题不规范 | 要根据市面上较为完善的排版格式将说明书编写完善 | ||
A、商务部分: |
| ||
1、在线人数容量要达到2w | 修改成1w | ||
B、技术部分: |
| ||
1、后端的java框架不要使用ssm框架 | 使用集成度更高的springboot框架 | ||
C、价格部分: |
| ||
1、无 | 无 | ||
D、格式排版: |
| ||
1、说明书的排版问题不规范 | 要根据市面上较为完善的排版格式将说明书编写完善 | ||
签发时间: 2023.9.21 发送人: 张三 接收人: | |||
反馈时间: 2023.9.22 发送人: 张三 接收人: | |||
复核意见: 从中找出的需要改善的问题,是正确的,需要进行修正的
复核人: 李四 |
-
- 项目合同
合同编号:gdgydx-rjgc-4234 广东省财政数据信息中心
食堂评价系统开发项目
合同书
采购编号: gdgydx-rjgc-1234
项目名称:药品进销存管理系统
签订地点:广州市
签订日期:2023年9月21日
甲方:XX大学
乙方: 广州市洪刚公司
根据广州市招投标中心招标编号为gdgydx-4234的项目招标结果、乙方报价文件及该项目中标通知书,经甲方与乙方协商一致同意签订如下条款:
一、总则
1.甲乙双方一致同意遵守《中华人民共和国合同法》、《中华人民共和国政府采购法》、《中华人民共和国政府招投标法》及其它有关法律法规,并遵循公平原则各自履行己方的权利和义务。
2.下列文件为本合同不可分割部分:
1)广州市招投标中心招标编号: gdgydx-4234招标文件;。
2)食堂评价项目乙方中标的投标文件及中标通知书;
3)本合同执行过程中双方一致同意签署的变更文件;
4)本项目《需求规格说明书》、《项目实施计划》、《项目验收方案》。
3.双方同意在出现合同理解上的歧义时,按照本合同及其附件、《需求规格说明书》、变更文件、《中标通知书》、《招标文件》、《项目实施计划》、《项目验收方案》、《投标文件》的顺序解释。
4.乙方保证按照合同条款的规定向甲方提供合格的项目应用开发软件。
5.甲方保证按照合同条款规定的时间办理乙方到期应付合同款的支付手续。
6.本项目建设采用第三方监理机制,卖方必须接受买方依法委托的项目监理单位的监督,遵守监理单位的相关管理制度。
二、合同标的内容、形式及要求
1.本合同标的为招聘网站项目应用软件。实施内容包括但不限于需求分析、研发设计、安装实施、培训、测试、调试、验收、质保期保障等全部内容。
2.本项目技术内容为前端的vue框架和后端的springboot框架。
3.合同签订的同时,双方共同组成招聘网站系统项目管理委员会,作为项目协调的最终决定机构,指定专门接口人员负责双方的协调事宜,并负责除合同本身之外的本项目其他确认事宜。
4.由乙方根据甲方需求框架充分调查并与甲方协商后于本合同生效后
___10_个工作日内提出《需求规格说明书》。经双方签字确认后实施,《需求规格说明书》将作为本合同执行不可分割的部分。
5.若需求发生变更,变更后的需求同样经双方签字确认后,以需求变更补充文件的形式,同样作为本合同执行不可分割的部分。
6.乙方开发的系统应具有先进、实用、安全、可靠、可扩展以及界面美观、大方的特点。
7.系统设计要做到:代码标准化、模块标准化、文档标准化、测试标准化以及信息标准化。
8.提交的成果:乙方按照《招聘网站项目招标文件》(编号: GDUT2023-CHG-W-3)的要求,在规定时间内完成需求调研、系统设计、研发、安装实施、测试、调试、验收、质保期保障等工作,并以光盘形式向甲方提供招聘网站项目应用软件全套软件,即系统的可执行程序。
三、合同价格及支付方式
1.合同总金额为中标价人民币大写叁拾万元,小写300000元。
2.合同总价包括了乙方进行需求调研、研发设计、安装实施、培训、测试、调试、试运行、验收、质保期保障服务等的全部含税费用,以及合同实施过程中应预见或不可预见费用。甲方无须向乙方另外支付任何费用。
3.本合同总金额在原招标技术与商务方案不变的基础下,合同价格为固定不变价。如果单价和数量的乘积与总价不一致时,以总价为准。
4.付款方式: 转账
1)合同签订后二十个工作日内甲方支付合同总价的30%项目预付款给乙方,即人民币(大写)玖万元(¥90000);
2)项目通过甲方组织的初步验收后二十个工作日内,甲方支付合同总价的40%给乙方,即人民币(大写)拾贰万元(¥120000);
4)合同总价的5%,即人民币(大写)壹万伍千元(¥15000)作为项目的质量保证金,在质保期满后30天内无息退还(项目通过竣工验收之日起计质保期)。
5.甲方采用以下方式之一向乙方支付费用:
1)转帐;
2)支票;
6.甲方履约付款时间为甲方向政府采购支付部门提出支付申请的时间(不含政府财政支付部门审查的时间)。
7.甲方支付乙方的费用汇至乙方指定账户(乙方提供的指定账户体现在付款申请内)。
8.每笔款项支付时,乙方同时向甲方提供相应金额的正式发票(含货物款发票、货物安装费发票及有关服务发票)。
四、项目实施地点及工期
1.本项目实施地点为:
1)XX大学
2.本合同总工期要求为90工作日。由于甲方所造成的延误,工期顺应顺延。
3.在合同签订后,由甲方提早10个工作日通知乙方,乙方在收到通知后5个工作日内完成用户需求调研,编制《需求规格说明书》,《需求规格说明书》经双方签字确认后的10个工作日完成系统的设计开发。在指定地点10个工作日内调试完毕进入试运行,试运行30个工作日后竣工验收。
五、安装调试
1.乙方必须向甲方提供合同产品安装所需的材料、技术资料以及组装/维修所需工具。
2.乙方在接到甲方要求开始安装的通知后5天内必须派合适的人员到现场进行安装和调试。
3.乙方派出的安装人员应具备相关的专业知识、技术水平、相应资质和能力,熟悉本合同所述产品的规格、技术指标及安装,有足够能力安装、调试本合同的产品并使之达到本合同要求。
|
-
- 项目任务书
开发单位:XX大学
项目名称:药品进销存管理系统
项目经理:
项目时间:2023.9.20
项目组设置:
序号 | 分组名称 | 人员数量 | 负责人 | 工作职责 |
1 | 总体组 | 2 |
| 项目计划和进度控制,协调小组工作 |
2 | 需求组 | 3 | 张三 | 需求获取,需求分析,用户对接 |
3 | UI组 | 1 | 李四 | 系统界面设计 |
4 | 架构组 | 2 | 王五 | 架构设计,单元模块设计,接口设计 |
5 | 开发组 | 8 | 赵六 | 系统需求开发,单元测试 |
6 | 测试组 | 3 | 陈七 | 编写测试计划,集成测试计划,系统测试,提交测试报告 |
- 项目计划与执行控制
2.1 范围计划
1.角色功能表
角色 | 角色描述 | 功能 | 功能描述 | 协作者 |
管理员
| 管理系统整体运行和用户权限。 | 用户管理 | 创建、修改和删除用户账户。 | 监管人员 |
权限管理 | 分配不同用户的系统访问权限。 | |||
系统设置 | 配置系统参数和选项。 | |||
采购员
| 负责药品的采购和供应商管理。
| 药品采购
| 生成、编辑和管理药品采购订单。 | 销售员、仓库管理员 |
供应商管理 | 维护供应商信息,评估供应商绩效。 | |||
库存预警
| 监测库存水平,生成库存不足的警报。 | |||
销售员
| 负责药品的销售和客户管理。
| 销售管理
| 创建、编辑和管理药品销售订单。 | 仓库管理员 |
客户管理
| 维护客户信息,追踪销售绩效。 | |||
销售报告
| 生成销售报告和销售趋势分析 | |||
仓库管理员
| 管理药品的库存和仓储操作。 | 库存管理
| 监控和管理仓库中的药品库存。 | 销售员、采购员 |
入库和出库 | 记录药品的入库和出库操作。 | |||
库存调整 | 处理因盘点差异等原因导致的库存调整。 | |||
财务人员
| 负责药品进销存相关的财务事务。
| 发票管理 | 记录和管理采购和销售发票。 | 销售员、采购员 |
账务核对 | 对账和核对发票,确保准确性。 | |||
财务报表 | 生成财务报表,包括利润表和资产负债表。 | |||
监管人员
| 监督系统操作的合规性和法规遵守。 | 合规性检查 | 监测系统操作是否符合法规和政策。 | 系统管理员 |
报告生成
| 生成与合规性相关的报告,用于监管目的。 |
|
2.任务分解结构(WBS)
2.2 成本计划
1.规模估算(Deiphi)
任务 编号 | 任务名称 | 张专家 | 刘专家 | 李专家 | 任务 规模(功能点) | |||||||||
ai | mi | bi | ei | ai | mi | bi | ei | ai | Mi | bi | ei | |||
1.1.0 | 确定需求 |
|
|
|
|
|
|
|
|
|
|
|
| 27 |
1.1.1 | 需求获取 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 |
1.1.2 | 需求分析 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 |
1.1.3 | 需求验证 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 |
1.2.0 | 设计 |
|
|
|
|
|
|
|
|
|
|
|
| 18 |
1.2.1 | 功能设计 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 |
1.2.2 | 系统设计 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 |
1.3.0 | 编码及功能实现 |
|
|
|
|
|
|
|
|
|
|
|
| 63 |
1.3.1 | 模块定义 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.2 | 接口开发 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.3 | 程序编码 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.4 | 管理模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.5 | 采购模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.6 | 销售模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.7 | 仓库管理模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.8 | 财务模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.3.9 | 监管模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 |
1.4.0 | 测试 |
|
|
|
|
|
|
|
|
|
|
|
| 35.8 |
1.4.1 | 内部测试 | 11 | 12 | 13 | 12 | 10 | 12 | 14 | 12 | 9 | 11 | 12 | 10.8 | 11.6 |
1.4.2 | 集成测试 | 11 | 12 | 13 | 12 | 10 | 12 | 14 | 12 | 9 | 11 | 12 | 10.8 | 11.6 |
1.4.3 | 报告测试 | 11 | 12 | 13 | 12 | 10 | 12 | 14 | 12 | 9 | 11 | 12 | 10.8 | 11.6 |
1.5.0 | 安装 |
|
|
|
|
|
|
|
|
|
|
|
|
|
1.5.1 | 软件安装 | 5 | 10 | 15 | 10 | 5 | 10 | 15 | 10 | 5 | 10 | 15 | 10 | 10 |
总计 |
|
|
|
|
|
|
|
|
|
|
|
| 153.8 |
2.成本预算(单位:w元)
任务 编号 | 任务名称 | 任务 规模 | 开发 成本 | 管理成本(10%) | 间接成本(20%) | 总预算 |
1.1.0 | 确定需求 | 27 |
|
|
| 3.9 |
1.1.1 | 需求获取 | 9 | 1 | 0.1 | 0.2 | 1.3 |
1.1.2 | 需求分析 | 9 | 1 | 0.1 | 0.2 | 1.3 |
1.1.3 | 需求验证 | 9 | 1 | 0.1 | 0.2 | 1.3 |
1.2.0 | 设计 | 18 |
|
|
| 2.6 |
1.2.1 | 功能设计 | 9 | 1 | 0.1 | 0.2 | 1.3 |
1.2.2 | 系统设计 | 9 | 1 | 0.1 | 0.2 | 1.3 |
1.3.0 | 编码及功能实现 | 63 |
|
|
| 9.1 |
1.3.1 | 模块定义 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.2 | 接口开发 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.3 | 程序编码 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.4 | 管理模块 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.5 | 采购模块 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.6 | 销售模块 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.7 | 仓库管理模块 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.8 | 财务模块 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.3.9 | 监管模块 | 7 | 1 | 0.1 | 0.2 | 1.3 |
1.4.0 | 测试 | 35.8 |
|
|
| 3.9 |
1.4.1 | 内部测试 | 11.6 | 1 | 0.1 | 0.2 | 1.3 |
1.4.2 | 集成测试 | 11.6 | 1 | 0.1 | 0.2 | 1.3 |
1.4.3 | 报告测试 | 11.6 | 1 | 0.1 | 0.2 | 1.3 |
1.5.0 | 安装 |
|
|
|
| 1.3 |
1.5.1 | 软件安装 | 10 | 1 | 0.1 | 0.2 | 1.3 |
总计 | 153.8 |
|
|
| 20.8 |
2.3 进度计划
1.项目历时估计
任务 编号 | 任务名称 | 任务 规模 | 专家A | 专家B | 专家C | 任务 历时 | |||||||||
ai | mi | bi | ei | ai | mi | bi | ei | ai | mi | bi | ei | ||||
1.1.0 | 确定需求 |
|
|
|
|
|
|
|
|
|
|
|
| 27 | 9天 |
1.1.1 | 需求获取 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 | 3天 |
1.1.2 | 需求分析 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 | 3天 |
1.1.3 | 需求验证 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 | 3天 |
1.2.0 | 设计 |
|
|
|
|
|
|
|
|
|
|
|
| 18 | 6天 |
1.2.1 | 功能设计 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 | 3天 |
1.2.2 | 系统设计 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 9 | 3天 |
1.3.0 | 编码及功能实现 |
|
|
|
|
|
|
|
|
|
|
|
| 63 | 36天 |
1.3.1 | 模块定义 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.2 | 接口开发 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.3 | 程序编码 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.4 | 管理模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.5 | 采购模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.6 | 销售模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.7 | 仓库管理模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.8 | 财务模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.3.9 | 监管模块 | 7 | 8 | 9 | 8 | 6 | 10 | 14 | 10 | 6 | 9 | 12 | 9 | 7 | 4天 |
1.4.0 | 测试 |
|
|
|
|
|
|
|
|
|
|
|
| 35.8 | 9天 |
1.4.1 | 内部测试 | 11 | 12 | 13 | 12 | 10 | 12 | 14 | 12 | 9 | 11 | 12 | 10.8 | 11.6 | 3天 |
1.4.2 | 集成测试 | 11 | 12 | 13 | 12 | 10 | 12 | 14 | 12 | 9 | 11 | 12 | 10.8 | 11.6 | 3天 |
1.4.3 | 报告测试 | 11 | 12 | 13 | 12 | 10 | 12 | 14 | 12 | 9 | 11 | 12 | 10.8 | 11.6 | 3天 |
1.5.0 | 安装 |
|
|
|
|
|
|
|
|
|
|
|
|
| 2天 |
1.5.1 | 软件安装 | 5 | 10 | 15 | 10 | 5 | 10 | 15 | 10 | 5 | 10 | 15 | 10 | 10 | 2天 |
总计 |
|
|
|
|
|
|
|
|
|
|
|
|
| 62天 |
2.任务编排PDM图(关键路径法)
3.进度编排甘特图
2.4 质量计划
1.过程审计计划
(1)需求过程审计计划
| 检查项 | 是/否/不适用 | 后继处理方案 |
清晰性 | |||
1 | 对需求的描述是否易于理解? | 否 | 进一步与客户进行沟通,明确项目的真实需求。 |
2 | 是否存在有二义性的需求? | 是 | 无 |
3 | 是否定义了术语表,对特定含义的术语赋予了定义? | 是 | 无 |
4 | 最终产品的每个特征是用唯一的术语描述的吗? | 是 | 无 |
完整性 | |||
1 | 有被遗漏的信息吗? | 是 | 无 |
2 | 是否每个需求都在项目的范围内? | 是 | 无 |
3 | 是否有的需求应该描述的更详细些? | 是 | 无 |
4 | 是否有的需求应该描述的更简略些? | 是 | 无 |
5 | 是否包含了所有的功能需求? | 是 | 无 |
6 | 是否合理的确定了所有需求? | 是 | 无 |
7 | 是否定义了可维护需求? | 是 | 无 |
8 | 是否定义了安全保密性的需求? | 是 | 无 |
9 | 是否定义了安装需求? | 是 | 无 |
可追踪性 | |||
1 | 是否所有的需求都可追溯到一个特定的是客户需求? | 是 | 无 |
可检查性 | |||
1 | 是否所有的需求都能实现? | 否 | 与客户沟通之后,将需求进一步改善 |
2 | 是否每个需求都是可测试的? | 是 | 无 |
可修改性 | |||
1 | 需求描述的是否清晰? | 是 | 无 |
2 | 组织结构是否合理? | 是 | 无 |
3 | 是否每个需求都没有内容和语法上的错误? | 是 | 无 |
接口 | |||
1 | 是否对用户界面进行了说明? | 是 | 无 |
2 | 是否对接口的安全性进行了说明? | 是 | 无 |
3 | 是否对接口的可维护性进行了说明? | 是 | 无 |
时间性能 | |||
1 | 是否定义了预期的处理时间? | 是 | 无 |
其他 | |||
1 | 是否符合法律规范? | 是 | 无 |
(2)设计过程审计计划
| 检查项 | 是/否/不适用 | 后继处理方案 |
清晰性 | |||
1 | 设计是否符合需求 | 是 | 无 |
2 | 用于设计所采集的信息是否充分 | 是 | 无 |
3 | 设计时是否用到了专业性的术语 | 是 | 无 |
完整性 | |||
1 | 设计的整个项目是否能完整满足需求? | 否 | 在原有的设计基础上将需要的功能进一步设计添加 |
2 | 设计完后的整个流程是否完整 | 是 | 无 |
3 | 设计的内容是否完整 | 是 | 无 |
可追踪性 | |||
1 | 每一个设计是否可以追踪到设计的初衷 | 是 |
|
可检查性 | |||
1 | 是否每一个设计都是可实现的? | 是 | 无 |
可修改性 | |||
1 | 设计描述的是否清晰? | 是 | 无 |
2 | 设计出的组织结构是否合理? | 是 | 无 |
4 | 是否有冗余的信息? | 否 | 无 |
(3)编码过程审计计划
| 检查项 | 是/否/不适用 | 后继处理方案 |
清晰性 | |||
1 | 编码的注释信息是否完整 | 是 | 无 |
2 | 编码实现的功能是否完善清晰 | 是 | 无 |
3 | 编码使用的技术是否清晰完善? | 是 | 无 |
完整性 | |||
1 | 代码是否完整没有遗漏? | 否 | 无 |
可追踪性 | |||
1 | 是否所有代码都是可追踪的? | 是 | 无 |
可检查性 | |||
1 | 是否所有的代码都是检查测试过的? | 是 | 无 |
2 | 是否每个代码都是可检查的? | 是 | 无 |
可修改性 | |||
1 | 代码是否是可以修改的? | 是 | 无 |
2 | 代码的编写结构是否合理? | 是 | 无 |
3 | 是否代码都没有内容和语法上的错误? | 是 | 无 |
接口 | |||
1 | 接口是否明确? | 是 | 无 |
2 | 是否对接口的安全性进行了说明? | 是 | 无 |
3 | 是否对接口的可维护性进行了说明? | 是 | 无 |
时间性能 | |||
1 | 代码运行速度是否比较快? | 是 | 无 |
2 | 代码的优化是否处理 | 是 | 无 |
2.产品审计计划
(1)功能测试报告审计
项目名称 | 药品进销存管理系统 | 项目标识 |
|
审计人 |
| 审计对象 | 功能测试报告 |
审计时间 | 2023.9.20 | 审计次数 | 2 |
审计主题 | 从质量保证管理的角度审计测试报告 | ||
审计项与结论 | |||
审计要素 | 审计结果 | ||
测试报告与产品标准的符合程度 | 符合 | ||
测试执行情况 | 正常 | ||
测试情况总结 | 正常 | ||
结论(包括上次审计问题的解决方案) | |||
经审计后无调整事项。 | |||
审核意见 | |||
同意 | |||
审核人 | 张三 | 审核时间 | 2023.9.20 |
(2)需求规格说明书审计
项目名称 | 药品进销存管理系统 | 项目标识 |
|
审计人 |
| 审计对象 | 需求规格说明书 |
审计时间 | 2022.9.22 | 审计次数 | 1 |
审计主题 | 从质量保证管理的角度审计测试报告 | ||
审计项与结论 | |||
审计要素 | 审计结果 | ||
操作使用流程 | 简单好用明确 | ||
界面优化 | 界面友好,简洁大方 | ||
运行速度 | 运行流畅、速度较快 | ||
结论(包括上次审计问题的解决方案) | |||
经审计后无调整事项。 | |||
审核意见 | |||
同意 | |||
审核人 | 张三 | 审核时间 | 2023.9.22 |
2.5 配置管理计划
1.基线与配置项表
项目名称: 药品进销存管理系统
基线名称 | 配置项名称 | 版本号 | 提交人 | 入库时间 | 审核人 |
用户需求 | 需求分析结果 | 1.0 | 张三 | 2023.9.25 | 李四 |
需求规格说明书 | 1.0 | 张三 | 2023.10.8 | 李四 | |
需求审核书 | 1.0 | 张三 | 2023.10.10 | 李四 | |
项目设计 | 界面设计说明书 | 1.0 | 张四 | 2023.10.9 | 张海 |
架构设计书 | 1.0 | 张四 | 2023.10.10 | 张海 | |
数据库设计书 | 1.0 | 张四 | 2023.10.10 | 张海 | |
模块设计书 | 1.0 | 张四 | 2023.10.10 | 张海 | |
项目实现 | 集成开发环境 | 1.0 | 陈五 | 2023.10.11 | 陈海 |
硬件配置清单 | 1.0 | 陈五 | 2023.10.12 | 陈海 | |
项目进度表 | 1.0 | 陈五 | 2023.10.11 | 陈海 | |
源代码清单 | 1.0 | 陈五 | 2023.11.27 | 陈海 | |
可执行程序 | 1.0 | 陈五 | 2023.11.27 | 陈海 | |
系统测试 | 测试规格说明书 | 1.0 | 李六 | 2023.11.30 | 李海 |
测试计划表 | 1.0 | 李六 | 2023.11.30 | 李海 | |
测试用例 | 1.0 | 李六 | 2023.12.3 | 李海 | |
测试报告 | 1.0 | 李六 | 2023.12.6 | 李海 |
2.变更管理
项目名称 | 药品进销存管理系统 | ||
申请人 | 赵六 | 申请时间 | 2023/12/4 |
变更题目 | 测试用例修改 | 紧急程度 | 常规 |
变更具体内容 | |||
新增管理员删除用户账户的测试用例 | |||
变更影响范围 | |||
测试用例表,测试报告 | |||
变更确认 | |||
同意 | |||
确认人 | 张三 | 确认时间 | 2023/12/4 |
2.6 人员与沟通计划
1.人力资源计划
姓名 | 张三 | 李四 | 王五 | 赵六 | 陈七 |
职责 | 需求 | UI | 架构 | 开发 | 测试 |
2023.9.21-2023.10.10 | 3人 |
|
|
|
|
2023.10.4-2023.10.10 |
| 3人 |
|
|
|
2023.10.11-2023.11.27 |
|
| 5人 | 8人 |
|
2023.11.28-2023.12.8 |
|
|
|
| 3人 |
2.干系人计划
干系人 | 联系方式 | 角色 | 目前态度 | 期望态度 | 规划 |
陈兵 | 123456789 | 通过需求和验证需求的用户 | 不积极 | 积极 | 进一步沟通 |
何兵 | 122222222 | 项目投资人 | 积极 | 支持 | 项目报价,进度汇报 |
李兵 | 133333333 | 需求工程师 | 支持 | 支持 | 需求分析,需求说明书撰写 |
张兵 | 144444444 | 架构师 | 支持 | 支持 | 技术选型,架构设计 |
王兵 | 155555555 | 测试工程师 | 支持 | 支持 | 执行测试用例,编写测试文档 |
3.沟通计划
信息来源 | 沟通要求 | 信息接受者 | ||||||
内部 | 外部 | 沟通的内容 | 发布频率 | 发布方法 | 发布形式 | 发布人 | 接收人 | 反馈信息 |
| √ | 项目需求 | 每月一次 | 邮件 | 报告 |
| 客户 | 积极配合 |
| √ | 项目报价 | 至多3次 | 电话 | 成本详情表 |
| 客户 | 积极配合 |
√ |
| 每日活动 | 每天1次 | 口述 | 站立会议 |
| 项目成员 | 积极配合 |
√ |
| 工作安排 | 每个迭代第一天 | 线下 | 任务列表 |
| 项目成员 | 支持 |
| √ | 项目验收 | 项目结束 | 线下 | 最终成果展示 |
| 客户 | 满意 |
2.7 风险计划
序号 | 风险描述 | 概率 | 影响程度 | 风险等级 | 风险响应计划 | 责任人 | 状态 |
1 | 接口设计出错 | 偶尔发生 | 高 | 低风险 | 每个周期内进行一次审查会议 | 张三 | 无 |
2 | 项目进度延误 | 有时发生 | 中 | 中风险 | 及时调整人员安排,并做到各司其职 | 李四 | 无 |
3 | 安全性方面未能到位 | 偶尔发生 | 高 | 高风险 | 进一步使用更加高级安全的技术进行优化 | 王五 | 无 |
4 | 客户单方面毁约 | 几乎不发生 | 高 | 高风险 | 客户毁约后需按合同中规定的金额进行赔偿 | 张三 | 无 |
5 | 费用估算不合理 | 偶尔发生 | 高 | 高风险 | 项目经理判断费用欠缺情况,并于客户进行沟通处理 | 张三 | 无 |
- 项目结束
3.1 项目验收
1.验收报告
项目名称 | 药品进销存管理系统 | |||
项目阶段 | 系统已上线 | |||
甲方 | 药品进销存管理系统项目组 | |||
甲方联系人 | 张三 | 联系电话 | 13111111111 | |
乙方 | 广州市洪刚公司 | |||
乙方联系人 | 李小春 | 联系电话 | 13622222222 | |
项目概况 | 药品进销存管理系统是一个涉及药品库存、销售和采购管理的软件系统。该系统的设计和实施旨在帮助药品相关企业或机构更有效地管理他们的库存,提高销售效率,确保合规性,并提供对业务数据的洞察; 系统可以实时跟踪库存水平,确保及时补货,自动化库存管理,减少因库存错误而导致的损失。系统可以记录销售交易,包括药品种类、数量、销售价格等信息,提供销售趋势和分析,以便做出更明智的销售决策。 系统可以确保及时采购,避免因库存短缺而错失销售机会,优化供应链,确保获得最有利的采购条件。 系统可以提供追溯性,以便在必要时追踪产品的来源和去向。系统还可以生成各种报告,如库存报告、销售报告、采购报告等,帮助管理层做出决策,提供实时和历史数据分析,以识别趋势和机会。 | |||
交付文档 | 需求分析说明书、软件设计说明书(概要设计、详细设计、数据库设计)、项目开发计划、软件测试计划、软件单元测试报告、软件集成测试报告、用户操作手册、数据库文档、系统硬件配置及部署方案、所有源代码 | |||
验收结果 | 1.所有系统功能已按照需求规格书中定义的要求得到实现,并成功执行各项功能测试,包括库存管理、销售管理、采购管理等功能 2.系统在正常和峰值负载下的性能能满足要求并通过了性能测试,如响应时间、并发用户数等方面的测试 符合相关法规和行业标准并通过了安全测试,如身份验证、数据加密等方面的测试 3.用户对系统的界面和操作感到满意,并完成用户验收测试,用户是否能够顺利使用系统进行业务操作 4.系统稳定,能在长时间运行中保持正常并通过了可靠性测试,如系统崩溃恢复、错误处理等方面的测试 5.项目文档完整,包括用户手册、技术文档、培训材料等并符合组织的文档标准和要求 | |||
药品进销存管理系统项目组盖章(签字) 张三 2023年12 月15 日 | 广州市洪刚公司盖章(签字)
李小春 2023年12 月15 日 |
- 交付清单
1. 药品进销存管理系统可执行文件 2. 药品进销存管理系统使用手册 3. 药品进销存管理系统源码 4. 系统硬件要求及部署说明
|
3.验收人员
张三,李小春,陈小东
3.2 项目总结
1.项目综述
药品进销存管理系统是一种专为药品行业设计的信息管理系统,旨在帮助药品企业更有效地管理其库存、销售和采购等业务过程。这样的系统通常具有多个模块,包括库存管理、销售管理、采购管理、财务管理等,以满足药品企业的不同需求。 药品进销存管理系统的主要目标是提高药品企业的运营效率和管理水平。通过引入自动化和信息化的手段,系统旨在简化和优化企业内部的业务流程,实现对药品库存、销售和采购等方面的全面控制。 功能模块: 库存管理:实时跟踪药品库存水平,包括批次、有效期等信息。 自动化库存报警和补货流程,避免因库存不足或过多而导致的问题。 销售管理:记录销售订单、发货和退货等操作。生成销售报表,帮助企业了解销售趋势和业绩。 采购管理:管理供应商信息,包括联系方式、价格协商等。 根据销售趋势和库存水平制定采购计划,优化采购流程。 财务管理:记录财务交易,包括收入、支出、利润等。 生成财务报表,帮助企业监控财务状况。 报表和分析:提供各种报表和分析工具,帮助企业管理层做出更明智的决策。包括库存报表、销售报表、财务报表等。 使用此系统可以实现自动化业务流程,减少手动操作,提高工作效率,能实时更新库存信息,避免因信息滞后而导致的错误;可以精确追踪每个药品的批次、有效期等信息,确保库存的新鲜和合规性。 通过销售报表和采购计划,实现对业务的精细管理;提供实时的业务信息和报表,帮助企业了解业务状况,使得决策者能够基于数据做出更准确的战略决策;能避免因库存管理不善而导致的药品过期、损耗等问题,通过财务管理模块,降低财务风险。 药品进销存管理系统的实施有助于提升药品企业的管理水平,降低运营风险,并为企业提供更多的决策支持。项目的成功实施需要团队的密切协作和对业务流程的深入理解。 |
2.进度、成本、资源等数据的实际与计划的对比
阶段 | 进度(单位:天) | 成本(单位:万元) | ||||
计划 | 实际 | 差异 | 计划 | 实际 | 差异 | |
需求分析 | 9 | 8 | 1 | 3.9 | 4 | -0.1 |
产品设计 | 6 | 7 | -1 | 2.6 | 2 | 0.6 |
产品开发 | 36 | 32 | 4 | 9.1 | 12 | -2.9 |
产品测试 | 9 | 6 | 3 | 3.9 | 4 | -0.1 |
产品验收 | 2 | 3 | -1 | 1.3 | 2 | -0.7 |
总计 | 62 | 56 | 6 | 20.8 | 26 | -5.2 |
资源包括云服务器,数据库等
进度、成本、资源等实际与计划基本相符。
3.产品提交情况
交付清单
| 1. 药品进销存管理系统可执行文件 2. 药品进销存管理系统使用手册 3. 药品进销存管理系统源码 4. 系统硬件要求及部署说明
|
是否通过验收 | 通过 |
产品已经完全交付给客户,验收完成无错误。
4.经验教训
在设计药品进销存管理系统之前,充分了解用户需求和业务流程是至关重要的。未能准确理解用户需求可能导致系统无法满足实际业务需求,从而影响到药品的正常流转和库存管理。
数据质量和一致性: 药品进销存系统依赖于准确和一致的数据。确保数据的质量,包括及时更新、纠正错误和一致性检查,对于系统的有效运行至关重要。
安全性和合规性: 药品信息属于敏感信息,因此系统必须具备高水平的安全性。在系统设计和运行过程中,要确保符合相关法规和行业标准,以防止信息泄露和滥用。
5.项目结束语
这个项目不仅仅是一个任务的完成,更是一个团队的成功。每个人都在自己的岗位上发挥了关键作用,为项目的顺利推进和成功达成目标贡献了力量。大家在面对挑战时展现出的团队合作和创造力,让这个项目超出了最初的期望。
在项目中,我们学到了很多。每一个阶段都带来了新的经验和教训,使我们更加深入地理解了团队协作的重要性,也让我们更加熟悉了项目管理的方方面面。这些经验将成为我们未来工作的宝贵财富。