物品采购管理
交货日期:
物品出入库记录表
办公物品领用表
付款表
2、开发进度规划
开发进度总共定为48天:
计划需求5天 设计阶段13天 编码阶段27天 组装与测试3天
3、需求变更
在软件开发过程中,由于用户需求不明确及开发前期 用户与需求工程师交流的不充分,需求变更经常会发生:
如用户需要新增填加物品、物品入库管理等功能,而 这些需求在开发初期交流中并未提及。任何软件的设计和 开发过程中随时都可能发生需求变更,主要有内部变更因 素和外部变更因素。
费用指标完 成困难
6
0.5
理难度增加, 2.内耗影响
增加新的不确 项目完成并
定性。
带来后遗效
应
1.软件在网络 上运行,遭到 入侵,数据被 安全风险 修改的风险 2.软件自身在 网络上运行不 稳定
1.一旦出现 重大安全事 件影响整个 项目成功 2.预防和重 新编码所增 加的费用和 延长工期
10
0.6
1、加强与
5、项目生命周期内可能出现的与“人”有 关的问题及对策
5、项目生命周期内可能出现的与“人”有 关的问题及对策
5、项目生命周期内可能出现的与“人”有 关的问题及对策
5、项目生命周期内可能出现的与“人”有 关的问题及对策
6、 风险管理
主要内容:
• 风险管理的依据 • 风险分析、评估及对策
6、风险管理的依据
3.1外部变更因素
1、由于技术的快速更新,存在尝试用新系统来解决问题, 这种情况的变更,在解决用户提出的最初问题之前,发生 的可能性很大。
2、由于市场、经济、政府法规的影响,公司为了快速适应 ,往往会改变最初有关需要系统完成什么的想法或计划。
3、描述系统需求的人员已经离开企业,那么代替他的人就 有可能对目前正在开发中的系统持有一种完全不同的观点 和见解。
需求变更管理过程很大程度上就是用户与开发人员的 交流过程。开发人员应该学会认真听取用户的要求、考虑 和设想,并加以分析和整理。
4、需求变更的对策
采用面向客户的软件开发: (3)合同约束
需求变更给软件开发带来的影响是有目共睹的,所以在 与用户签订合同时,可以增加一些相关条款,如限定客户 提出需求变更时间,规定何种情况的变更可以接受、拒绝 接受或部分接受。 (4)用户参与需求评审
填写采购单
物品使用科室需填写《分公司办公物品采购申请表》, 填写所需办公物品名称、数量、报价、日期等,上交办公 室,由办公室负责审查汇总后由主管领导审批。
主管部门审批
主管领导根据所填内容,经过审查核实后,确定所申请 项目是否可以予以批准。
物品采购
物品采购由办公室和财务科共同采购,采购前进行询 价,报主管领导同意后,按照双人采购制原则,与供货单 位商洽、签供货合同或订单,进行采购。
3.2内部变更因素
1、在需求征集活动的早期,没能正确理解用户的真正需求。
2、对于要开发的系统,由于用户没有相关的使用经验,对于 一些功能可能比较模糊。随着开发过程的推进,系统开始展 现功能的雏形,用户对系统的了解也逐步深入。于是,他们 可能会想到各种新的功能,或对以前的要求进行改动。
3、范围没有圈定就开始细化。
物品入库
经批准购入的办公物品,采购后一律交由办公室保管 员清点后入库、登记造册。
物品领用
物品使用部门需填写物品领用单后方可领用。
物品采购流程图
办公室采购申请表
日期:----年----月-----日
采购表
2000元以下审批表
2000元以上审批表
报价单
上述报价是否含税: 税率:
报价有效期: 天
1、采用行 业通用运行 平台; 2、选用合 理的设计模 式。
管理层的沟
C
减轻
通; 2、 制定项目组
管理流程。
1、聘请专
业的网络安
全专家指导
预防 设计;
A
减轻 2、对程序
后备 结构进行优
化,提高网
络运行的可
靠性。
6、风险分析、评估及对策
1.程序的可扩 展性不足; 技术风险 2.软件开发平 台的可靠性不 足。
1.影响软件 网络化应用 的成功 2.费用开发 的时间和人 员配置
8
0.5
B
预防 应对
用户对界 1.影响软件
面和报表格式 网络化应用
范围风险 提出新要求, 没有增Fra bibliotek新价的成功 2.费用开发
10
0.8
值但是增加了 的时间和人
很大的编程量 员配置
。
A
预防 应对
注:风险等级分为A(高)、B(中)、C(低) 风险等级=影响程度×发生概率 风险级别量化区域为: A: 6~10 B: 4~5.9 C: 0~4
物品采购管理系统
1、业务流程分析 2、开发进度规划及分工 3、需求变更及对策 4、成本及报价
1、业务流程分析
公司办公室物品采购,主要分为2000元以上的固定资 产采购和临时办公物品采购,对于固定资产的采购需按照 固定资产采购管理办法执行;对于2000元以下的临时办公 物品的采购由办公室、财务科统一采购。物品使用科填写 物品采购单,提交办公室主管部门审批,通过后方可采购 ,采购回来的物品由办公室保管员清点后入库、登记造册 ,物品使用部门填写领用单后领用。
需求变更表
4、需求变更的对策
采用面向客户的软件开发: (1)相互协作
遭到用户抵制的项目是不会成功的。在讨论需求时, 开发人员与用户应该尽量采取相互理解、相互协作的态度 ,对能解决的问题尽量解决。即使用户提出了在开发人员 看来“过分”的要求,也应该仔细分析原因,积极提出可 行的替代方案。 (2)充分交流
• 项目的约束性目标 • 工作结构分解 • 人力资源计划 • 费用预算计划 • 进度计划 • 企业自身状况及项目前期资料 • 以往类似项目的经验
6、风险分析、评估及对策
6、风险分析、评估及对策
1.压力会带
1.管理层过于 来大量错误
乐观,给项目 2.影响工作
组压力
效率使工期
管理风险
2.沟通不够 3.并行工程管
在需求评审过程中,用户往往能提出许多有价值的意 见。同时,这也是由用户对需求进行最后确认的机会,可 以有效的减少需求变更的发生。
5、项目生命周期内可能出现的与“人”有 关的问题及对策
项目的生命周期包括概念、规划、实施和收尾四个阶 段,与之对应,西开公司成本软件开发项目团队也要经历组 建、磨合、正规、成效和解散五个过程。结合项目生命周期 的四个阶段和项目团队建设的五个过程,分析该项目整个生 命周期内可能出现的与“人”有关的问题: