软件开发技术-软件项目管理.pptVIP

项目管理的问题 软件项目管理者从软件项目一开始就面临着进退两难的局面。 需要定量的估算成本和有组织的计划项目的进展，但却没有可靠的信息可以使用。 对软件需求的详细分析可以提供必要的估算信息，但分析常常要花数周甚至数月的时间才能完成。 更糟糕的是，随着项目的进展经常发生改变，需求可能是不固定的。 项目管理中的常见问题 无法确定项目进度，项目经常延期 项目进展到什么程度了？ 是否按计划完成？还有百分之多少未完成？ 无法控制项目费用，经常超支 项目费用是否在按计划执行？ 目前项目是超支还是节余？ 无法控制项目风险，有可能导致项目失败 项目中存在问题吗？ 项目中的风险都消除或降低了吗？ 项目管理中的常见问题 无法确定项目的规模，不知道项目规模的变化 项目有多大？ 项目规模比前一阶段变大还是变小了？ 无法确定项目资源是否够用和可用 项目资源是否充足？ 已有的资源都可用吗？ 无法确定工作量 我到底做了多少工作 项目的工作量有多少？ 产生问题的根源 无计划 计划不完整 计划不合理 没有做项目估算 没有评估项目风险 没有制订跟踪与监控策略 跟踪与监控策略不合理 没有做跟踪 没有根据跟踪措施采取相应的行动 解决问题的最佳途径 制订合理的项目计划 进行项目估算 在项目计划中确定合理的项目跟踪与监控策略 在项目开发过程中根据跟踪结果不断调整和优化项目计划 在项目开发过程中根据跟踪结果不断调整和优化项目的跟踪与监控策略 问题分解 问题分解，有时称为划分，是一个软件需求分析的核心活动。在确定软件范围的活动中并没有完全分解问题。分解一般用于两个主要领域： 必须交付的功能 交付所用的过程。 面对复杂的问题人们常常采用分而治之的策略。简单讲，就是将一个复杂的问题划分成若干较易处理的小问题。这是项目计划开始时所采用的策略。在估算开始之前，范围中所描述的软件功能必须被评估和精化，以提供更多的细节。因为成本和进度估算都是面向功能的，所以某种程度的分解是很有用的。 项目管理的过程 软件过程的一般阶段（定义、开发和维护）适用于所有软件项目。问题在于如何选择一个合适项目组要开发的软件过程模型。 项目管理者必须决定哪一个过程模型最适合待开发项目，然后基于公共过程框架活动集合，定义一个初步的计划，便可以开始进行过程分解，即建立一个完整的计划，以反映框架活动中所需要的工作任务。 工作内容 主要内容项有7项： 规模、工作量、成本、关键计算机资源、进度、技术进展、风险。 在项目开展中： 收集数据； 与项目开发计划的估算进行比较，得出偏差； 对偏差进行分析，如果偏差超过了规定的域值，就应该采取相应的措施进行纠正（如修改计划等）。 收集跟踪数据的时机 跟踪项 度量单位 收集时机 收集人 规模 用例点(UCP) /功能点/代码行数 每个阶段和每个迭代结束时 项目经理 工作量 人时 每周 全体成员 项目成本 人民币(元) 每月 财务人员 关键计算机资源 逐项说明 每月 项目经理 项目进度 工作任务完成率% 每周 项目经理 项目风险 停留周数 每周 项目经理 技术进展 实现的用例/ 实现的类等 每周 项目经理 跟踪数据域值 跟踪项 偏差控制域 规模 10% 工作量 10% 项目成本 3% 关键计算机资源 10%(每项) 项目进度 20% 项目风险 风险发生的第一征兆是否出现 合并问题和过程 项目计划开始于问题和过程的合并。软件项目组要开发的每一个功能都必须通过为软件组织定义的框架活动集合来完成。 项目 疲惫不堪的产业专家们在讨论特别困难的软件项目时，常常提及90-90规则： 一个系统的第一个90%花费了所分配工作量和时间的90%，系统最后的10%也会花费所分配工作量和时间的90%。 项目 评估进度所采用的方法是有缺陷的（很显然，如果90-90规则是真的，90%的完成度就不是一个准确的指标）。 没有办法测定进度，因为没有可用的、量化的度量。 项目计划在项目结束时没有考虑协调所需要的资源。 没有明确地考虑风险，没有建立缓解、监控和管理风险的计划。 进度计划是不现实或有缺陷的。 为了克服这些问题，在项目开始时必须花时间建立一个现实的计划，在项目进行中监控该计划，并在项目整个过程中控制质量和变化。 环境并不简单 开发环境这一术语是指在开发和部署系统时所需的全部工件，其中包括工具、指南、流程、模板和基础设施。 环境包括： 组织的开发环境 项目的开发环境 指南 流程 工具 基础设施 模板 TPUP、RUP、瀑布模型 …… 计划模板、指南模板 报告模板…… 设计指南、编码指南、 工具指南…… 计算机、网络 设备…… VB、VC、JAVA Rose…… 以前我们的认识 组织的开发环境 项目的开发环境 组织的开发环境 开发组织内的不同项目之间通常会存在许多相似