Presentation is loading. Please wait.

Presentation is loading. Please wait.

信息系统项目建设过程 2017年2月26日星期日.

Similar presentations


Presentation on theme: "信息系统项目建设过程 2017年2月26日星期日."— Presentation transcript:

1 信息系统项目建设过程 2017年2月26日星期日

2 概要 什么是软件开发项目管理 项目管理简介 1.项目管理基础 2.项目管理过程 软件开发阶段的项目管理(做什么) 前期程序及阶段文件编制要点(如何做) 软件开发项目成功的因素(怎么才能做好)

3 一.什么是软件开发项目管理? 项目经理直接对项目赞助人负责,保证项目成功的实施 — 与项目赞助人协商,就项目的目标和所需的资源达成共识
●软件开发项目管理是为了使软件开发项目能够按照预定的范围、成本、进度、质量顺利完成,而对范围、成本、进度、质量、风险等进行分析和管理的活动。 ●软件开发项目管理的对象是软件开发工程项目,它所涉及的范围覆盖了整个软件工程的整个过程(启动-计划-实施-监控-收尾)。 ●软件开发项目管理是软件开发工程的保护性活动,它先于任何技术活动之前开始,并且持续贯穿于整个计算机软件的定义、开发和维护之中。 ●项目经理职责 项目经理直接对项目赞助人负责,保证项目成功的实施 — 与项目赞助人协商,就项目的目标和所需的资源达成共识 — 挑选核心成员,并取得他们的支持 — 在项目的进程中不断了解客户的需求 — 在项目计划过程中领导及指导小组成员 — 保证与项目干系人的沟通并汇报项目的进程 — 监控项目的进程,保证项目按时间计划执行

4 概要 什么是软件开发项目管理 项目管理简介 1.项目管理基础 2.项目管理过程 软件开发阶段的项目管理 前期程序及阶段文件编制要点 软件开发项目成功的因素

5 二.项目管理简介 1.综合管理 2.范围管理 3.时间管理 4.成本管理 5.质量管理 6.人力资源管理 7.沟通管理 8.风险管理
九大知识领域 1.综合管理 2.范围管理 3.时间管理 4.成本管理 5.质量管理 6.人力资源管理 7.沟通管理 8.风险管理 9.采购管理 重点关注: 范围管理中的需求管理; 要认真做需求调研和分析 项目管理阶段(项目管理过程) 启动 计划 实施 监控 收尾

6 二.(1.1)九大知识领域: 1.综合管理 2.范围管理 3.时间管理 4.成本管理 5.质量管理 6.人力资源管理 图片 7.沟通管理
1.1项目计划编制 1.2项目计划实施 1.3综合变更控制 2.范围管理 2.1启动 2.2范围计划编制 2.3范围定义 2.4范围核实 2.5范围变更控制 3.时间管理 3.1活动定义 3.2活动排序 3.3历时估算 3.4进度计划编制 3.5进度计划控制 4.成本管理 4.1资源计划编制 4.2成本估算 4.3成本预算 4.4成本控制 5.质量管理 5.1质量计划编制 5.2质量保证 5.3质量控制 6.人力资源管理 6.1组织计划编制 6.2人员获取 6.3队伍建设 图片 7.沟通管理 7.1沟通计划编制 7.2信息发送 7.3绩效报告 7.4管理收尾 8.风险管理 8.1风险管理计划编制 8.2风险识别 8.3定性风险分析 8.4定量风险分析 8.5风险应对计划编制 8.6风险监控 9.采购管理 9.1采购计划编制 9.2询价计划编制 9.3询价 9.4供方选择 9.5合同管理 9.6合同收尾

7 二.(1.1)九大知识领域——1: √ 1.综合管理 — 项目经理是一个集成者 — 范围、进度、和成本 — 项目管理是平衡的艺术 固定 可选
1.1项目计划编制 1.2项目计划实施 1.3综合变更控制 综合管理 ●软件项目中的综合(整体)管理 — 项目经理是一个集成者 — 范围、进度、和成本 — 项目管理是平衡的艺术 ●解决的问题:进行整体的管理和控制,在软件的功能点、时间和可用资源之间找一个平衡点 固定 可选 可调 资源 时间 功能点

8 二.(1.1)九大知识领域——2: 2.范围管理 — 必须有、应该有、最好有 — 工作分解结构(WBS) — 范围变更管理
2.1启动 2.2范围计划编制 2.3范围定义 2.4范围核实 2.5范围变更控制 范围管理 ●软件项目中的范围管理 — 必须有、应该有、最好有 — 工作分解结构(WBS) — 范围变更管理 ●解决的问题:需求蔓延 工作分解结构(WBS) 工作分解结构(简称WBS),就是把一个项目,按一定的原则分解,项目 分解成任务,任务再分解成一项项工作,再把一项项工作分配到每个人的日常活动中,直到分解不下去为止。即:项目→任务→工作→日常活动;工作分解结构以可交付成果为导向对项目要素进行的分组,它归纳和定义了项目的整个工作范围,每下降一层代表对项目工作的更详细定义。WBS总是处于计划过程的中心,也是制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础。

9 二.(1.1)九大知识领域——3: 3.时间管理 — 自底向上的时间估计与自顶向下的时间估计相结合
●软件项目中的时间管理 — 自底向上的时间估计与自顶向下的时间估计相结合 — Time boxing(时间盒子)一种管理方法,即在预算时间内对完不成的功能进行删减或者延迟,而不是拖延预算的时间。 — fixed ship date mindset (定船日期的心态) — 缓冲时间 ●解决的问题:制定合理的阶段计划,进行进度控制 3.时间管理 3.1活动定义 3.2活动排序 3.3历时估算 3.4进度计划编制 3.5进度计划控制

10 二.(1.1)九大知识领域——4: 4.成本管理 软件成本及工作量估算永远不会是一门精确的科学。 完工预算成本 成本管理
●软件项目中的成本管理 — 资源的分配和计划安排:人力、设备、材料(1.人员工资、差旅费、通讯费、硬件、工具、福利费、招待费等等;2.管理费用分摊、人员招聘费用、风险费用、培训成本费、技术支持费、用户教育费、包装制作费、市场推广费等等) — 考虑节假日、开会、培训等时间 — 应急储备和管理储备 ●解决的问题:有效分配资源,将成本控制在预算之内 4.成本管理 4.1资源计划编制 4.2成本估算 4.3成本预算 4.4成本控制 软件项目中的成本管理历史经验: 人员规模越大,成本系数越高。 技术水平越高,成本系数越高。 开发周期越长,成本系数越高。 一般系数为:1.5~3.0之间。 系统越复杂,开发难度系数越高 开发架构与语言越高级,开发难度越高 功能点越精细,准确度越高 团队开发历史越久,准确度越高 定制工作预算成本 完工实际成本 完工预算成本 软件成本及工作量估算永远不会是一门精确的科学。

11 研究产品质量问题的各种现象(缺陷或事故)
二.(1.1)九大知识领域——5: 质量管理 ●质量计划的制定和执行——质量目标管理子系统 ● 独立于项目组的质量保证组——质量保证子系统 ● 同行评审,进行缺陷管理——评审管理子系统 ●专业测试组、Bug管理、测试计划制定和执行——测试管理子系统 ●解决的问题:产品与过程质量的保证,提交高质量的软件产品 5.质量管理 5.1质量计划编制 5.2质量保证 5.3质量控制 研究产品质量问题的各种现象(缺陷或事故) 提出理论或解释造成产品质量问题的原因 在生产中检验理论以证实原因 实施纠正或改进措施 质量改进

12 二.(1.1)九大知识领域——6: 7.沟通管理 7.1沟通计划编制 7.2信息发送 7.3绩效报告 7.4管理收尾 沟通管理 ●软件项目中的沟通管理 — 简而言之:就是在适当的时间将适当的信息通过适当的渠道发给适当的利益干系人,并确保利益干系人能正确理解 — 项目经理90%的时间花在沟通上——项目管理是沟通的艺术 — 沟通方法:正式书面(立项报告或管理计划); 非正式书面(工程师日志、备忘录);正式口头(讲演、介绍);非正式口头(谈话) — 将开发工作的进展情况,包括顺利的进展、出现的拖延和障碍、甚至危机性问题等等,向所有项目有关人员进行通报 ●解决的问题: 谁需要什么信息?当他们需要的时候,如何给他们?由谁来给? 沟通的三大原则: 及时 准确 信息量恰到好处

13 二.(1.2)项目管理阶段: 五个标准化 过程组 图片

14 二.(1.3)对应关系: 图片 启动过程 计划过程 实施过程 监控过程 结束过程 综合管理 范围管理 时间管理 成本管理 质量管理
计划编制 计划实施 综合变更控制 范围管理 启动 范围计划编制 范围核实 范围定义 范围变更控制 时间管理 活动定义 活动排序 历时估算 进度计划编制 进度计划控制 成本管理 资源计划编制 成本估算 成本预算 成本控制 图片 质量管理 质量计划编制 质量保证 质量控制 人力资源管理 组织计划编制 团队建设 人员获取 沟通管理 沟通计划编制 信息发送 绩效报告 管理收尾 风险管理 风险管理计划编制 风险识别 风险定性分析 风险定量分析 风险应对计划编制 风险监控 采购管理 采购计划编制 询价 询价计划编制 供方选择 合同管理 合同收尾

15 概要 什么是软件开发项目管理 项目管理简介 1.项目管理基础 2.项目管理过程 软件开发阶段的项目管理 前期程序及阶段文件编制要点 软件开发项目成功的因素

16 二.项目管理简介: 启动阶段 细化阶段 构造阶段 移交阶段 (2)项目管理过程 图片 需求 开 发 过 程 设计 实现 集成 测试
启动阶段里程碑 细化阶段里程碑 构造阶段里程碑 移交阶段里程碑 (2)项目管理过程 启动阶段 细化阶段 构造阶段 移交阶段 开 发 过 程 需求 设计 图片 实现 集成 测试 启动(项目启动、立项、过程定义); 项目计划; 实施与监控(项目跟踪 与监控、风险管理、沟通管理、变更管理、评审); 收尾阶段; 管理过程 支持过程 配置管理、质量保证、培训、用户、维护

17 二.项目管理简介: (2.1)启动阶段——项目启动和立项 申请资源 动员项目成员
●申请启动 输入:《任务委托意向书》或外部启动文档 输出:已批准的《任务委托意向书》或外部启动文档 ●开通研发管理资源(启动项目组) 输入:已批准的项目启动文档 输出:《研发XX软件系统项目开通表》 《研发项目编号申请简化版立项报告》。。。 ●开项目启动会(可裁剪) 输入:项目的人员确定 输出:《启动阶段计划》 ●启动阶段里程碑评审 输入:项目范围清晰,关键风险已识别且有规避措施或者已规避 输出:《启动阶段里程碑报告PPT》 已批准的《立项报告》、《软件开发计划》、《项目软件过程定义》。。。 ●启动阶段关键点 — 与客户、高层的沟通,明确需求及获得相关支持 — 明确项目目标和定位 — 开项目会、统一思想、明确团队运作制度 ●启动阶段常见问题 — 需求不明确、及需求沟通不够 — 项目组成员选择不合理 — 为促成项目,过分乐观的分析项目的可行性 申请资源 动员项目成员 评审项目范围、风险、资源投入,决定项目是否继续开展,并确定项目的考核标准 图片

18 各主要里程碑重点任务是:修订软件开发计划,重点是完善各阶段(细化、构造、移交)的计划
二.项目管理简介: (2.2)计划阶段——项目计划 ●根据过程定义划分任务——工作分解结构WBS(原则:完全穷尽、彼此独立) ●活动排序 ●估计规模、工作量、资源、工期、成本等,并建立阈值; ●安排进度;制定项目计划、沟通计划、培训计划、 评审计划、质量目标、风险管理计划等。 使过程定义具体化,从而切实指导工程和项目管理活动。 细化软件开发计划,保证计划根据实际情况及时更新,使得计划具有指导意义。 项目计划的版本演化 主要里程碑0:项目启动会 制定软件过程定义和项目计划 1:立项、下委托、签合同 3:向用户提交beta版 4:发布 2:架构稳定 各主要里程碑重点任务是:修订软件开发计划,重点是完善各阶段(细化、构造、移交)的计划 次要里程碑:细化阶段第一次迭代完成 制定下一次迭代的过程定义和详细计划

19 二.项目管理简介: (2.3)实施与监控阶段——项目跟踪与监控
增加项目过程的可视性,使得对项目的管理能够起到切实有效的作用;尤其是当项目性能明显偏离软件计划时,及时采取有效的措施纠正错误的发生。 ●项目监控——数据采集和分析(工作量管理、进度、资源和费用、高风险的任务、人员的表现) ●召集会议——项目会议纪要 ●项目状态报告 ●应用项目进度计划表及阶段里程碑评审 ●风险跟踪和监控 项目跟踪的难题? ?问题总是不能及时的发现? ?必要的修复措施来得十分缓慢? 一个项目是如何拖延了一年的? 疲惫不堪的产业专家们在讨论特别困难的软件项目时,常常提及90-90规则: 一个系统的第一个90%花费了所分配工作量和时间的90%,系统最后的10%也会花费所分配工作量和时间的90%。 项目成员 项目小组 工作量纪录 数据采集 数据汇总表 过程能力基线 项目经理 项目状态报告 过程能力基线

20 二.项目管理简介: 风险指数=概率x损失 (2.3)实施与监控阶段——风险管理—1
例如:A失火的概率为0.1%,损失为35万,那么A失火的风险指数为¥350,这可能是愿意为A失火付出的保险金。 (2.3)实施与监控阶段——风险管理—1 ●风险识别 — 回顾所列出的假设和限制,每一项代表一个风险 — 回顾WBS——每项作业或完成条件那里会出错 — 考虑以往项目中出现的问题 ●制定风险响应计划 — 规避:改变项目计划,以排除风险或条件,使目标不受影响 — 转移:设法将风险的后果连同应对的责任转移到第三方 — 减轻:设法把不利的风险事件的概率或后果降低到一个可以接受的临界值 — 接受:主动或被动方式 ●风险管理模型 优先级高 严重性 优先级中 优先级低 图1:风险管理模型 可能性

21 二.项目管理简介: (2.3)实施与监控阶段——风险管理—2 —危机管理:风险已经造成麻烦后才处理。 —失败处理:觉察到风险并迅速处理。
●软件项目风险管理五种状态 —危机管理:风险已经造成麻烦后才处理。 —失败处理:觉察到风险并迅速处理。 —风险缓解:事先制订好风险发生后的补救措施,但不作任何防范措施。 —着力预防:将识别和防范作为项目一部分加以规划和执行。 —消灭根源:识别和消除风险根源 ●软件项目风险检查列表 —产品规模:与要建造或要修改的软件的总体规模相关的风险。 —商业影响:与管理或市场所加诸的约束相关的风险。 —客户特性:与客户的素质以及开发者和客户定期通信的能力相关的风险。 —过程定义:与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险。 —开发环境:与用以建造产品的工具的可用性及质量相关的风险。 —建造的技术:与待开发软件的复杂性及系统所包含技术的“新奇性”相关的风险。 —人员数目与经验:与参与工作的软件工程师的总体技术水平及项目经验相关的风险。

22 二.项目管理简介: (2.3)实施与监控阶段——风险管理—3 —性能风险:产品能够满足需求且符合于其使用目的的不确定的程度。
●软件项目风险因素 —性能风险:产品能够满足需求且符合于其使用目的的不确定的程度。 —支持风险:软件易于纠错、适应及增强的不确定的程度。 —成本风险:项目预算能够被维持的不确定的程度。 —进度风险:项目进度能够被维持且产品能按时交付的不确定的程度。 类别\因素 性能 支持 成本 进度 灾难的 1 无法满足需求而导致任务失败 错误将导致进度延迟和成本增加 2 严重退化使得根本无法到达要求的技术性能 无法做出响应或无法支持的软件 严重的资金短缺,很可能超出预算 无法在交付日期内完成 严重的 无法满足需求而导致系统性能下降,使得任务能否成功受到质疑 错误将导致操作的延迟,并使成本增加 技术性能有所下降 在软件修改中有少量的延迟 资金不足,可能会超支 交付之气可能延迟 轻微的 无法满足要求而导致次要任务的退化 成本、影响和即可恢复的进度上的小问题 技术性能有较小的降低 较好的软件支持 有充足的资金来源 实际的、可完成的进度计划 可忽略的 无法满足要求而导致使用不方便或不易操作 错误对进度及成本的影响很小 技术性能不会降低 易于进行软件支持 可能低于预算 交付日期将会提前 注:1、未测试出的软件错误或缺陷所产生的潜在的影响。 2、如果没有达到预期的结果所产生的潜在影响。

23 二.项目管理简介: (2.3)实施与监控阶段——沟通(组间协调) 项目涉及到的系统组、硬件组、公司其他部门的软件组、项目合作单位的软件组;
●对象 项目涉及到的系统组、硬件组、公司其他部门的软件组、项目合作单位的软件组; 子合同方不属于此范围; ●目的   建立一种软件工程组和其他工程组沟通的机制,使客户的需求能够更有效和迅速 的得到满足 ; ●输出 《组间计划》、《组间约定》以及《组间问题》 组间协调的活动 ●参与系统组的需求活动 ●制定《组间计划》 ●记录《组间约定》 ●跟踪组间的进展,必要时提出《组间问题》,共同商定解决方案 ●项目组成员有四个主要的沟通需求:职责、授权、协调、状态 ●沟通要点:计划、规则;项目组全体成员对目标达成共识

24 二.项目管理简介: (2.3)实施与监控阶段——变更管理 — 项目委托人:不断的变换想法与欲望 — 项目团队:成员技能与团队冲突
●变更的源头   — 项目委托人:不断的变换想法与欲望 — 项目团队:成员技能与团队冲突 — 项目优先级:市场变化/资源变换/其他项目影响 — 其他:法规/环境/企业变革 ●变更管理注意的事项 — 变更发生时,首先确定“能做些什么,以及不能做些什么” — 确定全体都一致同意的方案,提出变更步骤, 并就将要做出的变更进行即时评估 — 申请/审批修改后的计划(修改部分) — 保持/共享计划和信息的最新状态 — 尽量做的“天衣无缝”,而且没有“痛苦” ●典型的变更管理过程 提出变更申请 申请影响分析 实施变更 并跟踪发布状态 批准变更 评审分析结果 拒绝

25 二.项目管理简介: (2.3)实施与监控阶段——评审

26 二.项目管理简介: (2.4)收尾阶段—1 1.财务 3.质量 2.时间 项目结束 4.人力资源 7.项目控制 6.项目计划 5.环境
●评估与验收 1.财务 评估投资回报率,评估实际费用与计划费用的差异 3.质量 评估项目输出的表现水平,投资者和客户对质量的感受 2.时间 与计划的一致性 项目结束 4.人力资源 团队精神、激励、态度调查 7.项目控制 项目的控制是否为任务重大改进提供了基础? 6.项目计划 计划流程的费用评估及适当的管理技术使用 5.环境 环境因素对项目活动的影响

27 对OSSP(组织标准过程集)的积累和项目改进非常重要!
二.项目管理简介: (2.4)收尾阶段—2 使项目中好的实践积累下来,并在适用的项目中得以推广;同时,一些失误和无效的实践能够被记录并分析,以寻求改进的方式,避免再次出现同样的问题。 ●项目总结 — 项目总结会(喝酒与打屁股) — 项目总结报告 与《项目状态报告》属于一个系列; 总结项目的整体状态; 留下经验与教训; 给出建议; 子技术总结、测试总结、子合同总结。。。 ●文件归档 对OSSP(组织标准过程集)的积累和项目改进非常重要! 步骤 归档文件 启动 项目组任命、项目策划报告/任务书 计划 WBS图、甘特图、沟通风险计划书、项目综合计划 实施 控制 阶段进展报告、项目会议纪要、变更申请表 收尾 项目评估验收报告、项目总结报告、项目交付件相关文档

28 二.项目管理简介: (2.4)收尾阶段—3 — 顺利完成项目评估和验收 — 成功和失败的经验总结 — 完整的项目信息归档
●收尾阶段关键点 — 顺利完成项目评估和验收 — 成功和失败的经验总结 — 完整的项目信息归档 ●收尾阶段常见问题 — 经验、教训总结和传承做的不够 — 项目组成员对文档的重要性认识不足 — 项目的移交(尤其在跨部门的情况下)不平滑

29 (2)管理过程——各阶段重要关键点TOP3(回顾)
二.项目管理简介: (2)管理过程——各阶段重要关键点TOP3(回顾) ●启动阶段 — 与客户、高层的沟通,明确需求及获得相关支持 — 明确项目目标和定位 — 开工会,统一思想,明确团队运作制度 ●计划阶段 — 明确项目范围 — 全面的风险识别 — 各关键干系人的识别与沟通计划 ●实施与监控阶段 — 根据沟通计划,与项目干系人进行良好的沟通 — 严格监控项目进度,及时协调解决问题 — 重点跟踪监控高风险任务,并采取有效的防范措施 ●收尾阶段 — 顺利完成项目评估和验收 — 成功和失败的经验总结 — 完整的项目信息归档

30 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—1
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。

31 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—2
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。 软件过程或项目中的配置项(如程序、文件和数据等有关内容)被标识、定义。 根据已定义的配置项建立基线,以便对更改与发布进行有效的控制,并控制配置项的存储、处理与分发,确保配置项的完全性与一致性。 记录并报告配置项的状态以及已发生变更的需求。

32 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—3
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。 软件过程或项目中的配置项(如程序、文件和数据等有关内容)被标识、定义。 根据已定义的配置项建立基线,以便对更改与发布进行有效的控制,并控制配置项的存储、处理与分发,确保配置项的完全性与一致性。 记录并报告配置项的状态以及已发生变更的需求。 针对过程或项目确定质量保证活动、制定出相应的计划与进度表。 确定质量保证活动的有关标准、方法、规程与工具。 确定进行质量保证活动所需的资源、组织及其组织成员的职责。 有足够的能力确保必要的质量保证活动独立于管理者以及过程实际执行者之外进行开展和实施。 在与各类相关的计划进度保持一致的前提下,实施所制定的质量保证活动 。

33 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—4
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。 软件过程或项目中的配置项(如程序、文件和数据等有关内容)被标识、定义。 根据已定义的配置项建立基线,以便对更改与发布进行有效的控制,并控制配置项的存储、处理与分发,确保配置项的完全性与一致性。 记录并报告配置项的状态以及已发生变更的需求。 针对过程或项目确定质量保证活动、制定出相应的计划与进度表。 确定质量保证活动的有关标准、方法、规程与工具。 确定进行质量保证活动所需的资源、组织及其组织成员的职责。 有足够的能力确保必要的质量保证活动独立于管理者以及过程实际执行者之外进行开展和实施。 在与各类相关的计划进度保持一致的前提下,实施所制定的质量保证活动 。 根据需要验证的工作产品所制定的规范(如产品规格说明书)实施必要的检验活动: 有效地发现各类阶段性产品所存在的缺陷,并跟踪和消除缺陷。

34 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—5
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。 软件过程或项目中的配置项(如程序、文件和数据等有关内容)被标识、定义。 根据已定义的配置项建立基线,以便对更改与发布进行有效的控制,并控制配置项的存储、处理与分发,确保配置项的完全性与一致性。 记录并报告配置项的状态以及已发生变更的需求。 针对过程或项目确定质量保证活动、制定出相应的计划与进度表。 确定质量保证活动的有关标准、方法、规程与工具。 确定进行质量保证活动所需的资源、组织及其组织成员的职责。 有足够的能力确保必要的质量保证活动独立于管理者以及过程实际执行者之外进行开展和实施。 在与各类相关的计划进度保持一致的前提下,实施所制定的质量保证活动 。 根据需要验证的工作产品所制定的规范(如产品规格说明书)实施必要的检验活动: 有效地发现各类阶段性产品所存在的缺陷,并跟踪和消除缺陷。 根据客户实际需求,确认所有工作产品相应的质量准则,并实施必需的确认活动。 提供有关证据,以证明开发出的工作产品满足或适合指定的需求。

35 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—6
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。 软件过程或项目中的配置项(如程序、文件和数据等有关内容)被标识、定义。 根据已定义的配置项建立基线,以便对更改与发布进行有效的控制,并控制配置项的存储、处理与分发,确保配置项的完全性与一致性。 记录并报告配置项的状态以及已发生变更的需求。 针对过程或项目确定质量保证活动、制定出相应的计划与进度表。 确定质量保证活动的有关标准、方法、规程与工具。 确定进行质量保证活动所需的资源、组织及其组织成员的职责。 有足够的能力确保必要的质量保证活动独立于管理者以及过程实际执行者之外进行开展和实施。 在与各类相关的计划进度保持一致的前提下,实施所制定的质量保证活动 。 根据需要验证的工作产品所制定的规范(如产品规格说明书)实施必要的检验活动: 有效地发现各类阶段性产品所存在的缺陷,并跟踪和消除缺陷。 与客户、供应商以及其他利益相关方(或独立的第三方)对开发的活动和产品进行评估 。 为联合评审的实施制定相应的计划与进度,跟踪评审活动,直至结束 。 根据客户实际需求,确认所有工作产品相应的质量准则,并实施必需的确认活动。 提供有关证据,以证明开发出的工作产品满足或适合指定的需求。

36 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—7
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。 软件过程或项目中的配置项(如程序、文件和数据等有关内容)被标识、定义。 根据已定义的配置项建立基线,以便对更改与发布进行有效的控制,并控制配置项的存储、处理与分发,确保配置项的完全性与一致性。 记录并报告配置项的状态以及已发生变更的需求。 针对过程或项目确定质量保证活动、制定出相应的计划与进度表。 确定质量保证活动的有关标准、方法、规程与工具。 确定进行质量保证活动所需的资源、组织及其组织成员的职责。 有足够的能力确保必要的质量保证活动独立于管理者以及过程实际执行者之外进行开展和实施。 在与各类相关的计划进度保持一致的前提下,实施所制定的质量保证活动 。 根据需要验证的工作产品所制定的规范(如产品规格说明书)实施必要的检验活动: 有效地发现各类阶段性产品所存在的缺陷,并跟踪和消除缺陷。 与客户、供应商以及其他利益相关方(或独立的第三方)对开发的活动和产品进行评估 。 为联合评审的实施制定相应的计划与进度,跟踪评审活动,直至结束 。 根据客户实际需求,确认所有工作产品相应的质量准则,并实施必需的确认活动。 提供有关证据,以证明开发出的工作产品满足或适合指定的需求。 判断是否与指定的需求、计划以及合同相一致 。 由合适的、独立的一方来安排对产品或过程的审核工作 。 以确定其是否符合特定需求

37 文档编制 配置管理 质量保证 验证 确认 联合评审 审核 问题解决 二.项目管理简介: (2.5)支持过程—8
明确并定义文档开发中所采用的标准、软件过程中所需要的各类文档。 详细说明所有文档的内容、目的及相关的输出产品。 根据定义的标准与已确定的计划来编写、审查、修改和发布所有文档。 按已定义的标准和具体的规则维护文档。 软件过程或项目中的配置项(如程序、文件和数据等有关内容)被标识、定义。 根据已定义的配置项建立基线,以便对更改与发布进行有效的控制,并控制配置项的存储、处理与分发,确保配置项的完全性与一致性。 记录并报告配置项的状态以及已发生变更的需求。 针对过程或项目确定质量保证活动、制定出相应的计划与进度表。 确定质量保证活动的有关标准、方法、规程与工具。 确定进行质量保证活动所需的资源、组织及其组织成员的职责。 有足够的能力确保必要的质量保证活动独立于管理者以及过程实际执行者之外进行开展和实施。 在与各类相关的计划进度保持一致的前提下,实施所制定的质量保证活动 。 根据需要验证的工作产品所制定的规范(如产品规格说明书)实施必要的检验活动: 有效地发现各类阶段性产品所存在的缺陷,并跟踪和消除缺陷。 与客户、供应商以及其他利益相关方(或独立的第三方)对开发的活动和产品进行评估 。 为联合评审的实施制定相应的计划与进度,跟踪评审活动,直至结束 。 根据客户实际需求,确认所有工作产品相应的质量准则,并实施必需的确认活动。 提供有关证据,以证明开发出的工作产品满足或适合指定的需求。 判断是否与指定的需求、计划以及合同相一致 。 由合适的、独立的一方来安排对产品或过程的审核工作 。 以确定其是否符合特定需求 提供及时的、有明确职责的以及文档化的方式,以确保所有发现的问题都经过相应的分析并得到解决 。 提供一种相应的机制,以识别所发现的问题并根据相应的趋势采取行动 。

38 二.项目管理简介: (2)管理过程——回顾总结 监控 启动 计划 实施 收尾 项目管理沟通 立项申请 组建项目组 策划/任务书 项目开工会
工作分解结构 活动排序 资源工期成本估算 进度计划 风险沟通计划 项目计划 沟通 项目监控 变更管理 评估与验收 项目总结 文件归档 项目管理沟通

39 概要 什么是软件开发项目管理 项目管理简介 1.项目管理基础 2.项目管理过程 软件开发阶段的项目管理 前期程序及阶段文件编制要点 软件开发项目成功的因素

40 三.软件开发阶段的项目管理 * 软件开发生命周期模型 (1)系统开发阶段 系统需求规范 系统安全要求规范 系统结构描述 (9)软件维护阶段
* 软件开发生命周期模型 (1)系统开发阶段 系统需求规范 系统安全要求规范 系统结构描述 (9)软件维护阶段 软件维护记录 软件更改记录 (6)软件评审阶段 软件评审报告 (2)软件需求分析阶段 软件设计规范 软件测试规范 (软件校验报告) (3)软件结构设计阶段 软件结构说明 集成测试大纲 (软件结构校验报告) (7)集成测试阶段 集成测试报告 (4)软件模块设计阶段 软件模块技术要求 软件模块测试大纲 (软件模块校验报告) (6)软件模块测试阶段 软件模块测试报告 (5)编码阶段 软件源代码与支持文件 软件模块流程框图 (软件源代码校验报告)

41 三.软件开发阶段的项目管理 * 软件开发阶段组成和文件组成 — 所有文件的结构应允许在设计过程中进行不断地扩充。
* 软件开发阶段组成和文件组成 ● 开发过程中文件要求: — 所有文件的结构应允许在设计过程中进行不断地扩充。 — 各文件具有唯一的编号和一个确定的、书面表示的与其它文件之间的关系。 — 每个文件中的术语、首字母缩略词或缩写应具有相同的含义 ● 开发过程中测试要求: 软件测试过程包括软件模块测试、集成测试和系统测试三个测试阶段。 软件测试任一阶段未通过,代码重新设计后,必须回归到软件模块测试阶段进行测试。 每个软件测试阶段包括四项活动,按顺序分别是: 测试策划 测试设计和实现 测试执行 测试总结。

42 三.软件开发阶段的项目管理 (1)系统开发阶段 在该阶段要确定在系统中软件和硬件要实现的功能, 硬件和软件的可靠性指标。
●系统开发阶段 在该阶段要确定在系统中软件和硬件要实现的功能, 硬件和软件的可靠性指标。 ●硬件与软件功能的分配原则: 满足有高可靠性和安全性要求的功能 应权衡用硬件实现还是用软件实现的利弊,做出妥善决策。 ●硬件与软件可靠性指标的分配原则: 软件的可靠性指标应与硬件的可靠性指标大体相当,可根据具体情况作适当的调整,但调整不宜过大 所分配的指标应能量化、并验证。

43 (2)软件需求分析阶段——1 三.软件开发阶段的项目管理 确定软件功能需求、确定软件功能测试方案,
●软件需求分析阶段的任务: 确定软件功能需求、确定软件功能测试方案, 编写出软件设计规范和软件测试规划两个文件。 ●软件设计规范应能描述出待开发软件所要求的特性,应包括: 功能(包括能力和响应时间性能); 可靠性与可维修性; 安全性(包括安全性功能及其相关的软件安全完整性等级); 效率; 适用性; 可移植性 软硬件接口 自检的程度以及由软件检测硬件的指定程度。

44 三.软件开发阶段的项目管理 (2)软件需求分析阶段——2 要求的输入信号及其顺序与数值; 预期的输出信号及其顺序与数值;
●软件测试规范应根据软件设计规范产生,软件测试规范应用来校验软件设计规范中所述的全部要求,同时也作为已完成软件需进行的测试描述。 ●对各个要求的功能,软件测试规范应说明下述测试条件: 要求的输入信号及其顺序与数值; 预期的输出信号及其顺序与数值; 验收标准,包括性能与质量方面。 ●软件设计规范由软件开发组编写和校核,由软件测试组审核,由项目负责人批准 ●软件测试规范由软件测试组编写和校核,由软件开发组审核,由项目负责人批准

45 三.软件开发阶段的项目管理 (3)软件结构设计阶段——1 确定进行软件开发的策略和实现软件设计规范的可行性,
●软件结构设计阶段任务: 确定进行软件开发的策略和实现软件设计规范的可行性, 编写出软件结构说明文件和集成测试大纲。 ●软件结构说明应包括以下内容: 描述整个软件结构和流程,包括由哪些组件构成,组件的基本功能及相互关系; 确定、评价和详述所有硬件/软件的相互作用; 描述避错策略与故障处理(容错)之间的平衡是否正确; 设计过程中可使用现有的、已校验的,按本标准开发的软件模块(组件); ●软件结构说明应对软件的所有子模块(组件)进行辨认,包括: 这些子模块(组件)是否是新的、现有的或专用的; 这些软件先前是否已被审核。如果是,它们的审核情况是什么。

46 (3)软件结构设计阶段——2 三.软件开发阶段的项目管理 测试方法、类型和技术; 测试环境,包括工具、支持软件与配置描述;
●软件集成测试大纲根据软件结构说明进行编写,集成测试大纲应对系统中各个部件软硬件集成后的软件功能进行测试,包括以下内容: 测试方法、类型和技术; 测试环境,包括工具、支持软件与配置描述; 软件测试用例说明; ●软件结构说明由软件开发组编写和校核,由软件测试组审核,项目负责人批准 ●集成测试规范由软件测试组编写和校核,由软件开发组审核,项目负责人批准

47 (4)软件模块设计阶段——1 三.软件开发阶段的项目管理 按照软件结构说明文件对各软件模块的功能要求, 确定软件模块的实现算法与数据结构,
●软件模块设计阶段任务: 按照软件结构说明文件对各软件模块的功能要求, 确定软件模块的实现算法与数据结构, 编写出软件模块技术要求作为软件编码的依据,编写出软件模块测试大纲。 ●软件模块技术要求应包括以下内容: 每个模块要实现的功能; 确定可追溯至上一层的最低的软件组件(模块); 各模块的输入、输出及其条件; 详细的算法与数据结构; 每一软件模块应有流程框图,清晰地表明; ——模块功能; ——模块间的信息流向; ——模块内信息流程及时间的有关信息;

48 (4)软件模块设计阶段——2 三.软件开发阶段的项目管理 试验目的及条件; 试验环境、工具、配置; 预期的输入信号及其顺序与数值;
●软件模块测试大纲应根据软件模块技术要求产生,应包括以下内容: 试验目的及条件; 试验环境、工具、配置; 预期的输入信号及其顺序与数值; 预期的输出信号及其顺序与数值; 测试的覆盖程度; 验收标准或判据。 ●软件模块技术要求由软件开发组编写和校核,由软件测试组审核,由项目负责人批准 ●软件模块测试大纲由软件测试组编写和校核,由软件开发组审核,由项目负责人批准

49 (5)软件编码和模块测试阶段 三.软件开发阶段的项目管理 按软件模块技术要求,采用合适软件语言,按照软件设计规范编写出软件代码
●软件编码阶段任务: 按软件模块技术要求,采用合适软件语言,按照软件设计规范编写出软件代码 采用软件测试工具对软件代码进行静态自查。 ●软件模块测试阶段任务: 按软件模块测试大纲要求,用软件测试工具对软件模块进行测试, 并编写软件测试报告。 ●软件模块测试报告应包括如下内容: 测试结果叙述,及每个模块是否满足自身的软件模块技术要求; 应对每个模块提供测试覆盖程度的说明,指出所有的源代码指令至少执行过一次 对后续的分析。 ●开发的软件模块只有通过软件测试后,并经项目负责人批准,可进入下一个开发阶段

50 三.软件开发阶段的项目管理 (6)集成测试阶段 将系统中各个部件的硬件与软件集成,按照软件集成测试大纲对集成后的软件进行功能测试
●软件集成测试阶段任务: 将系统中各个部件的硬件与软件集成,按照软件集成测试大纲对集成后的软件进行功能测试 编写出软件集成测试报告。 ●软件集成测试报告应包括以下内容: 与软件设计规范、软件结构说明或软件模块技术要求不相符的项目; 不足以适应问题的模块、数据、结构与算法; 软件集成测试覆盖程度; 检测到的差错与缺陷; 已校验项目的识别号与配置。 ●集成后的软件只有通过软件测试后,并经项目负责人批准,可进入下一个开发阶段。

51 (7)系统测试阶段 三.软件开发阶段的项目管理 — 按照软件测试规范要求对整个软硬件系统功能进行测试, — 编写软件系统测试报告。
●系统测试阶段任务: — 按照软件测试规范要求对整个软硬件系统功能进行测试, — 编写软件系统测试报告。 ●软件测试报告应包括以下内容: — 软件设计规范、软件结构说明,软件模块技术要求是否能满足系统要求; — 软件模块测试和软/硬件集成测试是否规范充分; — 测试的结果,出现的差异和已进行的修正工作; — 对软件设计规范中要求的测试覆盖度做出评价。 ●软件只有通过软件系统测试后,经项目负责人批准,可进入下一个开发阶段。

52 (8)软件评审 三.软件开发阶段的项目管理 — 软件设计规范;软件测试规范;软件集成测试大纲
●软件评审应由与设计组无关的评审员进行。 ●评审员应评审系统软件是否适合于预期用途,软件功能是否满足软件设计规范要求,软件测试是否满足软件测试规范要求的测试覆盖率。 ●若软件不满足软件设计规范要求或软件测试要求,评审员在软件评审报告中只须报告不合格,而不要求给出任何技术解决方案。 ●软件评审前必须归档的资料至少包括: — 软件设计规范;软件测试规范;软件集成测试大纲 — 软件结构说明;软件模块技术要求;软件模块测试大纲 — 软件模块流程框图;软件模块源代码;软件模块测试报告 — 软件集成测试报告;软件系统测试报告 ●软件通过评审后,由项目负责人进行软件发布并归档。发布的软件必须有明确的版本标示和发布说明文档,发布说明文档应包括发布软件的用途、更改历史和版本说明。

53 三.软件开发阶段的项目管理 (9)软件维护 ●对软件的维护应执行配置管理,严格实施变更管理;对变更过的软件必须进行回归测试;确保对有关文档进行相应的更改,以保持文档的一致性。应建立软件维护流程,并记录在软件维护方案中,这些流程应包括: 差错报告、差错日志、维护记录、更改授权和软件系统的质量等的控制; 校验、审核和评审; 规定可批准更改软件的主管部门。 ●维护进行时,应采用与系统开发初始时相同的专用技术、工具与文件管理。 ●软件首次发布之前,应为每一软件项目建立软件维护记录,并应对它进行维护。该记录应包括以下内容: 查询有关软件项目的所有软件更改记录; 更改结果信息; 组件测试状况,包括重新审核和回归测试的数据; 软件配置历史。 ●每次维护都应建立软件更改记录,该记录包括: 修改或变更请求; 分析维护对整个系统的影响(包括硬件、软件、人之间的相互作用、环境和可能的交互); 修改或变更的详细说明; 对修改或变更进行重新审核、回归测试与重新评审。

54 概要 什么是软件开发项目管理 项目管理简介 1.项目管理基础 2.项目管理过程 软件开发阶段的项目管理 前期程序及阶段文件编制要点 软件开发项目成功的因素

55 四.前期程序及阶段文件编制要点 项目建议书 可行性研究 初步设计 施工设计 项目建设前期程序 (1)项目建议书阶段
●项目建设前期一般划分为项目建议书、可行性研究、初步设计和施工设计四个主要阶段。信息工程一般可将初步设计和施工设计合并成一个阶段。 项目建议书 可行性研究 初步设计 施工设计 (1)项目建议书阶段 ●项目建议书是对拟建项目的一个总体轮廓设想,是根据国民经济和社会发展长期规划、行业规划和地区规划,以及国家产业政策,经过调查研究、分析预测,着重从客观上对项目建设的必要性作出分析,并初步分析项目建设的可能性。项目建议书重点围绕项目建设的必要性进行分析研究,是项目立项的依据。 ●此阶段的主要任务是完成项目建议书,经过评估由主管部门批准后项目立项。

56 (2)可行性研究阶段 (3)设计阶段 四.前期程序及阶段文件编制要点
●可行性研究是对拟建项目的市场需求状况、建设条件、生产条件、协作条件、工艺技术、设备、投资、经济效益、环境和社会影响以及风险等问题,进行深入调查研究,充分进行技术经济论证,做出项目是否可行的结论,选择并推荐优化的建设方案,为项目决策单位或业主提供决策依据。可行性研究重点围绕项目建设的可行性进行分析研究,是项目决策的依据。 ●此阶段的主要任务是编制项目可行性研究报告,经项目评估,由主管部门批准项目可行性研究,确定项目投资建设是否进入启动程序。 (3)设计阶段 ●工程设计是根据建设工程的要求,对建设工程所需的技术、经济、资源、环境等条件进行更加深入细致的分析,给出详细和具体的建设方案和投资规模。设计阶段一般包括初步设计和施工图设计两个阶段,初步设计是确定项目建设规模和投资的主要依据,施工图设计是工程实施和验收的主要依据。

57 (1.1)项目建议书要点 四.前期程序及阶段文件编制要点 1.概述 项目背景描述。 2.建设必要性
●项目建议书也称为初步(预)可行性研究,是对项目方案的技术、经济条件进行论证,对项目是否可行进行初步判断。主要内容包括: 1.概述 项目背景描述。 2.建设必要性 从用户需求出发,结合国家、社会、行业、安全、效率效益、质 量等各个方面,全面描述项目的地位与作用。 3.建设方案 提出系统建设规模、目标、功能、技术方案、建设工期等轮廓设 想,并对技术方案进行初步分析和论证。 4.投资估算及资金筹措初步方案 5.经济评价 经济效益分析及社会综合评价。 6.结论及建议

58 (2.1)可行性研究报告要点—1 四.前期程序及阶段文件编制要点 项目背景 研究依据 工程范围 研究年度
●可行性研究是在批准的项目建议书基础上,从项目建设的技术、经济、工程等方面进行调查研究和分析比较,并对项目建成以后可能取得的财务、经济效益及社会环境影响进行预测,从而提出该项目是否值得投资和如何建设的报告。主要内容包括: ● 1.概述 项目背景 研究依据 工程范围 研究年度 研究工作概述(含项目的提出、规划、研究历史、本次研究经过,研究思路及特点等。) 现有相关信息系统状况 建设目标 ● 2.项目建设环境条件分析 国内外发展概况 主要建设条件

59 (2.1)可行性研究报告要点—2 四.前期程序及阶段文件编制要点 用户需求分析
建设必要性分析(从国家、社会、行业、安全、效率效益、质量等各个方面,全面描述项目的地位与作用) ● 3.系统构成及主要功能 ● 4.信息资源分析 含信息流程、信息量等分析。 ● 5.采用的主要技术标准 包括国际标准、国家标准、行业标准、其它等。 ● 6.技术方案 应用系统构成 总体结构 各分系统结构及相互关系 信息资源共享方案 网络构成 网络结构,局域网,广域网 数据传输 网络管理

60 (2.1)可行性研究报告要点—3 四.前期程序及阶段文件编制要点 计算机网络与信息安全方案 软硬设备配置原则 硬件设备配置原则
系统软件配置原则 应用软件要求 系统运行环境(机房、电源、防雷、接地等环境设施要求,以及机房监控系统设计) 相关系统配合改造方案及整合方案(含利旧设备说明) ● 7.建设工期及实施方案 ● 8.投资估算及资金筹措方案 ● 9.经济评价 含财务评价和国民经济评价。 ● 10.风险分析 ● 11.结论及建议

61 (3.1)设计文件要点 四.前期程序及阶段文件编制要点
●工程设计是可行性研究的深入和继续,在可行性研究确定项目可行的条件下,解决怎样进行建设的具体工程技术和经济问题。 初步设计是确定项目建设规模和投资的主要依据,应满足工程招标承包和进行施工准备及主要设备采购的需要。 施工图设计是工程实施和验收的依据,是运营管理的基础资料,应根据初步设计的审批意见,采用定测及补充定测资料编制。

62 (3.2)设计文件要点——初步设计主要内容包括— 1 :
四.前期程序及阶段文件编制要点 (3.2)设计文件要点——初步设计主要内容包括— 1 : ● 1.概述 设计依据 设计范围 设计年度 现有相关信息系统状况 ● 2.系统构成及主要功能 ● 3.信息资源 含信息流程、信息量等分析。 ● 4.设计原则 ● 5.技术方案 应用系统设计 总体结构 各分系统结构及相互关系 信息资源共享方案 与其它系统关系及接口

63 (3.2)设计文件要点——初步设计主要内容包括— 2 :
四.前期程序及阶段文件编制要点 (3.2)设计文件要点——初步设计主要内容包括— 2 : 网络设计 网络结构、局域网(含网络布线)、广域网(含城域网光纤通道)、数据传输、 网络管理、地址、域名分配方案 计算机网络与信息安全设计 软硬设备配置方案 硬件设备 系统软件(包括操作系统、数据库、通信中间件、应用中间件、工具软件、系统及网络管理和监控软件等) 应用软件(含开发软件模块清单、开发时间及开发工作量) 系统运行环境设计(机房、电源、防雷、接地等环境设施要求,以及机房监控系统设计) 相关系统配合改造方案及整合方案(含利旧设备说明) 计算机备品备件配置方案 ● 6.施工组织设计 ● 7.运营维护机构设置、管辖范围和定员 ● 8.总概算

64 (3.3)设计文件要点——施工设计主要内容包括— 1 :
四.前期程序及阶段文件编制要点 (3.3)设计文件要点——施工设计主要内容包括— 1 : ●1.初步设计审批意见及执行情况 ●2.设计说明(说明总的工程情况、设计内容、采用的先进技术及其他必要的说明) ●3.施工注意事项 ●4.投资检算 ●5.投资计算方法 工程建设投资是根据各种不同的定额进行计算的,在不同阶段分不同种类,在工程前期过程中,基本上可以分为投资估算、设计概算、施工图检算。 1.投资估算 在项目建议书和可行性研究阶段,通过估算指标对建设项目的投资数额进行估算。 2.设计概算 在初步设计阶段,根据概算定额和概算指标对工程造价进行概略计算。 3.施工图检算 在施工图设计阶段,根据预算定额对工程预算造价进行检算。 如果初步设计和施工图设计合为一阶段设计,则编制总预算。

65 (3.3)设计文件要点——施工设计主要内容包括— 2 :
四.前期程序及阶段文件编制要点 (3.3)设计文件要点——施工设计主要内容包括— 2 : ●6.工程建设投资 工程建设投资由静态投资、动态投资组成,静态投资包括建筑工程费、设备及工器具购置费、安装工程费、工程建设其他费用、基本预备费等,动态投资包括涨价预备费、建设期投资贷款利息等。 ●7.工程概预算费用 1.建筑工程费 在信息工程中,建筑工程主要指室外网络通道的管线敷设工程。可采用信息工程和通信工程有关定额计算。 2.安装工程费 主要指设备的装配、装置工程、附属于被安装设备的管线敷设,以及被安装设备的调整、试验所需费用。可采用信息工程有关定额计算。 3.设备购置费 根据技术方案中硬件设备选型要求,选择主流厂商的主流产品进行设备估价,一般按设备厂家报价加适当折扣进行计算,特别注意在计算硬件设备购置费用时应包括三年免费维修费用。

66 (3.3 )设计文件要点——施工设计主要内容包括— 3 :
四.前期程序及阶段文件编制要点 (3.3 )设计文件要点——施工设计主要内容包括— 3 : 4.其他费 指土地征用及拆迁补偿费、建设项目管理费、建设项目前期工作费、研究试验费、计算机软件开发与购置费、配合辅助工程费、联合试运转及工程动态检测费、生产准备费、其他等,一般按规定的费率取费。 对信息工程来说,计算机软件开发与购置费是很重要的费用,计算机软件购置费,可根据技术方案中对操作系统、数据库、应用中间件、通信中间件、开发工具等软件要求,选择成熟使用的主流厂商的主流产品进行软件价格估算,一般按软件厂家报价加适当折扣进行计算,特别注意在购置软件时应包括3年免费升级、服务等费用。 对于没有成熟应用软件可满足工程中系统功能需要时,可在工程中计列软件开发费,开发专用软件提供工程使用。 在开发人工费里应包括:需求分析、系统概要设计、系统详细设计、项目管理、编程、单元测试、系统联调等项内容的人工费用。 5.预备费 指设计概预算中难以预料的费用,一般按规定的费率计取。

67 (3.3)设计文件要点——施工设计主要内容包括—4:
四.前期程序及阶段文件编制要点 (3.3)设计文件要点——施工设计主要内容包括—4: 6.开发费

68 概要 什么是软件开发项目管理 项目管理简介 1.项目管理基础 2.项目管理过程 软件开发阶段的项目管理 前期程序及阶段文件编制要点 软件开发项目成功的因素

69 五.软件开发项目成功的因素 — 常常先承担了项目开发责任,然后担任项目经理 — 项目管理常常不是通过系统学习得来的,而是在实践中摸索出来的
●项目管理常见的问题 — 常常先承担了项目开发责任,然后担任项目经理 — 项目管理常常不是通过系统学习得来的,而是在实践中摸索出来的 — 缺乏项目经理的职业意识 — 经常面临失败的经历 ●项目失败的主要原因: — 缺少必须承担的义务和方向 — 没有项目策略上的一致性 — 变化中不明确的效益 — 不明确的目的/目标 — 组织与项目目标不一致 — 资源限制 — 不明确的责任 — 不断变化的要求 — 没有最终用户的介入 — 不规范、低效的沟通

70 五.软件开发项目成功的因素 — 合格的项目经理 — 软件系统架构师 — 代码编写程序员 — 系统测试工程师 — 系统监造工程师
●成熟的团队; — 合格的项目经理 — 软件系统架构师 — 代码编写程序员 — 系统测试工程师 — 系统监造工程师 (责任矩阵)用于项目组织分配工作任务和落实责任 组织责任者 WBS 项目经理 项目工程师 程序员 确定需求 设计 开发 修改外购软件包 修改内部程序 修改手工操作程序 测试 测试外购软件包 测试内部程序 测试手工操作系统流程 安装完成 安装完成新软件包 培训工人 注: ▲-负责; ●-协助;□ -知会; ○-审批; △-承包

71 五.软件开发项目成功的因素 — 软件范围 问题分解 — 项目负责人 项目参与者 软件项目组 协调和通讯 — 合并问题和过程 过程分解
●有效的管理: — 软件范围 问题分解 — 项目负责人 项目参与者 软件项目组 协调和通讯 — 合并问题和过程 过程分解 ●成功的项目管理标准: 在预算内按时提交满足要求的产品、服务或成果 ●成熟完美的软件产品 易操作、易维护、易管理; 界面美观、运行稳定、安全可靠; 功能点完善、拓展性良好、可灵活配置; 资源较少占用、系统交叉循环、接口广泛易建; 项目的三重制约 有效的管理 成功的项目 === 完美的产品

72 谢谢 Thank you 2017年2月26日星期日


Download ppt "信息系统项目建设过程 2017年2月26日星期日."

Similar presentations


Ads by Google