3软件项目管理探究.pptVIP

人员/资源分配图 案例：黑河市热电厂项目 项目任务书 项目进度计划 2 项目进度跟踪 项目进度表只是提供了一张进度路线图，在实际执行过程中，需要定期对其进行跟踪和控制，以决定是否需要对进度计划进行调整。 定期举行项目状态会议，各成员分别报告进展和存在问题； 评估软件工程过程中所进行的评审的结果； 判断项目里程碑是否在预定日期内完成； 比较个项目的实际开始/结束日期与计划开始/结束日期； 与开发者非正式会谈，获取项目进展及可能出现问题的客观评估； 定量评估项目进展； 决策是否需要对进度进行调整。 迭代开发项目进度跟踪 迭代项目问题：里程碑难以确认，为什么？ 技术里程碑：OO分析完成 已经定义和评审了所有的类、类层次 已经定义和评审了与每一个类相关的属性和操作 已经建立和评审了各类之间的关系 已经建立和评审了行为模型 已经确定了可复用的类 技术里程碑：OO设计完成 技术里程碑：OO测试完成 项目进度跟踪Gantt图 主要内容 3.1 软件项目管理概述 3.2 项目可行性分析与估算 3.3 项目进度安排 3.4 项目风险管理 软件项目风险 软件规模风险： 估算准确程度？ 用户需求可能发生变化的频度与规模？ 商业影响风险： 交付期限？ 政府出台新政策？ 客户相关风险： 陌生客户？客户高层的重视程度？ 客户的配合程度？ 软件过程风险： 开发者不了解/不熟悉选定的过程模型？ 没有维护足够的文档？ 开发环境风险： 无法得到可用的工具？ 没有或不会使用工具？ 开发技术风险： 之前无该技术的经验？ 该技术难以实现某些需求？ 开发人员风险： 没有足够的经验与技能？ 某些人员会中途离开？ 风险预测：建立风险表 Step 1：列出可能的风险及风险类型； Step 2：估计风险发生的可能性或概率； Step 3：估计风险可能产生的影响或后果； Step 4：确定风险缓解策略 编号 风险描述 风险类型 概率 影响程度 后果 风险缓解策略 1 规模估算不准确 产品规模 60% 严重的 … 迭代方法 2 用户数量超出想象 产品规模 30% 轻微的 … 详细调研 3 最终用户抵制新系统 商业影响 70% 严重的 … 提前与用户沟通，了解使用习惯 4 交付日期将提前 商业影响 40% 灾难的 … 核心功能尽早开发 5 用户将改变需求 产品规模 50% 轻微的 … 架构设计灵活 6 技术到不到预期效果 开发技术 40% 灾难的 … 尝试多种可能技术 7 人员缺乏经验 人员 80% 严重的 … 安排客户培训业务 8 缺少对工具的培训 开发环境 30% 可忽略的 … 查资料、自学 9 人员变动频繁 人员 80% 严重的 … 加强团队凝聚力、关键岗位配备后备人员 …… 风险缓解、监测和管理 风险缓解 确定引起风险因素 制定风险缓解方案 风险监测 监测风险因素 监测风险缓解措施的效力 风险管理及应急计划 缓解工作已经失败，风险已经发生 启动应急计划 学习材料 项目管理工具 MS Project 阅读材料 《人件》（已上传） 结束 * 理解人：理解语言和非语言信号，做出反应 项目策划任务集 规定项目范围 确定可行性 分析风险 确定需要的资源 确定需要的人力资源 确定可复用的软件资源 标识环境资源 估算成本和工作量 分解问题 使用规模、功能点、过程任务或用例等方法进行两种以上的估算 调和不同的估算 制定项目进度计划 建立一组有意义的任务集合 定义任务网络 使用进度计划工具制定任务表 定义进度跟踪机制 主要内容 3.1 软件项目管理概述 3.2 软件项目估算 3.2.1 可行性分析 3.2.2 软件项目估算 3.3 项目进度安排 3.4 项目风险管理 估算与可行性分析 软件估算的内容（定量） 需要多少工作量（成本） 需要多少时间（进度） 需要多少人员（资源） 软件估算的依据 历史信息 经验 定量预言 软件估算风险 定量的不确定性 资源不稳定性 软件项目估算的动态调整 1 确定范围 Needs: 客户/最终用户的请求、想法和业务需求； Requirements: 对未来系统所应具备的功能的陈述； Exclusions: 将不包含在未来系统中的功能的陈述； Baseline: 对未来系统中应包含的功能的陈述。 Needs Requirements Exclusions Baseline Signature 1 确定范围 范围(Scope)：描述了将要交付给最终用户的功能和特性、输入输出数据、用户界面、系统的性能、约束条件、接口和可靠性等，以及期望的时间、成本目标； 两种方法： 与所有项目成员交流之后，写出对软件范围的叙述性描述； 由最终用户开发一组用例。 注意 并不是客户所有的要求都“来者不拒”，需要分别对待！ 软件范围一定要用户同意 范围的可行