it项目管理实践(ppt223)-项目管理(编辑修改稿)

it项目管理实践(ppt223)-项目管理(编辑修改稿)内容摘要：

用户需求的产品。  迭代式模型基于这样一个事实，就像任何一个复杂一样要经过一段时间的演化：  业务和产品需求随着开发工作的进展常常发生变化  紧迫的市场期限难于完成一个完善的产品  只要核心能够被很好的理解，产品的细节可以以后丰富和定义 Slide: 90 Version 增量模型  增量模型融合了线性模型的基本特征，每一个线性序列产生软件的一个可发布的 “ 增量 ”  第一个增量往往着重在系统架构和核心功能  系统架构反映了系统的核心需求 Slide: 91 Version 增量模型 (Incremental) 功能需求 功能需求 功能需求 功能需求 功能需求 需求分析 设计 实现 功能测试 需求分析 设计 实现 功能测试 需求分析 设计 实现 功能测试 增量发布 增量发布 增量发布 系统测试 系统测试 系统测试 实现的必要基础条件。 Slide: 92 Version 增量模型 (Incremental) 商业需求捕获 需求分析 系统功能需求 系统框架需求 系统框架设计 系统功能开发 是否可以在第一次就设计出一个好的框架。 Slide: 93 Version 螺旋模型  对大多数项目来说，在一开始就要求设计出一个好的体系架构是不现实的。 一个成熟的体系架构是要经过一段时间的积累和优化后才能形成的，特别是要对应用领域的深刻理解  螺旋模型的一个特征就是体系架构是要经过一段时间的演化而形成稳定 Slide: 94 Version 螺旋模型 设计和实现 需求 系统重构 新需求 测试 设计和实现 回归测试 当系统经过若干次重构后，对于新需求 不再出现重构时，就演化成增量模型 Slide: 95 Version 并行模型和工作流  由于 IT项目的本身特征，传统成线性按阶段划分的工程活动转变成工程活动并行开展的工作流方式，也就是并行模型 Slide: 96 Version 并行模型 需求 分析 实现 测试 设计 Slide: 97 Version 并行模型  并行模型是一种以短周期版本发布为阶段划分的模型  各个工作流的协调完全是靠统一的配置基线来保证 Slide: 98 Version 制定合适的生命周期模型  尽早验证最终产品，不要过分相信中间产品的验证手段  短周期迭代式构造产品  同步积累对产品的验证（回归测试）  建立各个工作产品一致的版本基线。 需要完善的配置管理活动支持 Slide: 99 Version 项目生命周期的选取实践 时间限制型的项目：某联通项目 需求管理 Slide: 101 Version 范围管理 vs需求管理  范围管理等价于需求管理吗。 Slide: 102 Version 定义  范围：产生项目产品所包括的所有工作及产生这些产品的过程  需求：产品必须完成的功能及必须具备的品质  为什么和传统其他行业有差别。 Slide: 103 Version IT项目的需求特征  IT领域的项目需求特征：  技术创造市场，传统领域引用了 IT技术后往往呈现出全新的应用  技术和市场发展都很快，在项目初始阶段需求是概念性的，不清晰的，片断性的  随着项目进行，随着双方的加深认识，需求也是不断演化的  需求工程活动包括：需求收集和需求分析两类活动 Slide: 104 Version 问题  需求分析活动做什么。 需求 说明 客户 规格 说明 系统 分析 分析 如果你只有一个活动可以做到 100% Slide: 105 Version 需求说明和规格说明  需求说明（ ReqB）通常是指以用户语言描述的产品要求  规格说明（ PRS）是指用产品领域的语言定义的什么样的产品可以满足用户需要 Slide: 106 Version IT项目需求活动的特征  需求收集活动，特别关注客户需求的不准确性，易变性  需求分析活动，分析活动没有做到位。 对分析活动结果的验证缺乏手段  需求管理活动，对需求特征的认识，以及相应的管理手段提高需求活动的有效性 Slide: 107 Version 需求管理的最佳实践  成立专门的需求工作小组，统一管理和分配需求，并且把需求工程活动扩展到项目的整个生命周期中。 Slide: 108 Version 需求管理的最佳实践  严格管理变更  警惕需求镀金。 注意 IT系统的新功能添加代价绝不仅仅是几行代码，还包括：  新功能的验证活动  系统变更引起的缺陷风险  系统的回归测试 Slide: 109 Version 需求管理的最佳实践  在前期细化需求，避免不完整和没有明确的需求进入到下面阶段。 因为，没有明确的部分最终总会在后面的某一阶段活动被假设需求取代，而这正是混乱产生的根源 Slide: 110 Version 需求收集的最佳实践  借助业务领域专家或客户代表，帮助项目组建立产品或系统被应用的场景。 例如：用例描述 Slide: 111 Version 需求收集的最佳实践  文档化需求，约定统一的需求描述形式。 尽可能选取比文字性描述更佳的方式表示需求。 Slide: 112 Version 需求分析的最佳实践  在产品规格说明中不仅仅要考虑正常情况的规格定义，更要确定异常情况下的规格定义 Slide: 113 Version 需求分析的最佳实践  提出对产品的可测试性的功能性要求。 产品的测试不能在产品完成之后再进行考虑，否则产品可能因为不可测或是测试代价过高而不被有效的测试 Slide: 114 Version 需求分析的最佳实践  在规格说明完成后，引入需求确认活动。 验证通过技术语言描述的产品定义是满足和覆盖客户需求的 Slide: 115 Version 需求变化的案例研究 我要我的 ERP系统具有 inter能力 建委资质认证系统 风险识别 Slide: 117 Version 风险管理过程  风险管理计划  风险识别  定性和定量风险分析  风险反应计划  风险监控 有效性体现 Slide: 118 Version 风险管理的现状  项目风险管理过程的关键并不在于是否存在正式的风险管理过程，而在于项目组的能力是否可以识别出潜在的风险  项目经理的经验和能力的反映：就在于对未来事件的预测性上 Slide: 119 Version 风险管理的最佳实践  建立组织一级的风险识别检查表  一方面，作为项目组开始风险管理的起步点；另一方面，来自项目组的经验可以不断丰富检查表的内容  参考资料： 《 Taxonomy Based Risk Identification》 Slide: 120 Version 风险的分类  产品工程风险  需求  设计  编码和单元测试  集成和测试  其他因素 Slide: 121 Version 风险的分类  开发环境  开发过程  开发系统  管理过程  管理方法  工作环境 Slide: 122 Version 风险的分类  项目限制性条件  资源  合同  接口 Slide: 123 Version 实践  杂货铺的案例  建委系统案例  十大风险列表  风险雷达 质量计划 Slide: 125 Version 质量管理的理论基础  缺陷预防， Crosby  适用性， Juran  持续性改进， TQM Slide: 126 Version 质量计划编制  在 IT领域里，质量计划编制最实用的方法是Benchmarking  即，向工业界的最佳实践 Best Practices学习 Slide: 127 Version 最佳实践  质量控制的验证与确认  质量审计  质量意识 Slide: 128 Version 质量控制（ Quality Control）  按一定的过程构造产品也不一定能保证产品质量，出现缺陷是不可避免的。 质量控制就是属于构造过程中的消除“缺陷”的工程化活动，也就是制造过程中的检查、检验手段 Slide: 129 Version 问题  质量控制就是检查完成产品的符合度，每一次检查遵循的标准是什么。  产品规格。  设计文档。  单元代码。  最终产品。  考虑传递的有效性。 活动产生结果 结果检查参照 Slide: 130 Version 质量控制：验证和确认 (V amp。 V)  验证：正确的构造了产品  Verification: Build the product right  确认：构造了正确的产品  Validation: Build the right product Slide: 131 Version Vamp。 V进一步理解  我们是否只有在产品完成之后才能检测产品的质量。 如何实施 V amp。 V。 目前的弱点是什么。  Vamp。 V的活动是整个生命周期中的必要组成部分 Verification Product Validation Slide: 132 Version 最佳实践：确认活动  重视确认活动，并为确认活动的实施进行计划，制定方法，提供资源 Slide: 133 Version 最佳实践：独立的测试  从项目初期就建立独立的测试组，并且在产品规格时就支持自动化测试。 产品开发过程中不断积累对产品的验证 Slide: 134 Version 深刻理解质量保证  质量保证是一个活动，它向所有有关的人提供证据以确立质量功能正在按需求运行的信心 Slide: 135 Version 实施质量保证活动  质量保证活动的核心是确保项目实施遵循“标准”。 标准包括：  产品的功能，性能标准，直接满足用户的需求  产品被构造的过程所遵循的标准，间接满足用户的需求  该标准为干系人所认可和信任，而质量保证活动的实施为项目在过程中满足最终目标提供信心 Slide: 136 Version 最佳实践：独立的质量保证组  项目必须依赖独立的质量保证活动组作项目运作的监督机构，以确保项目的过程遵循被确认的标准，有利于项目及早发现问题，及时纠正 Slide: 137 Version 为什么需要 QA?熵增原理  群体秩序总是趋于无序。 约束力度与体系的有序程度有关，当没有约束力的时候，体系自发过程总是趋于最无序。 举例的约束因素：法律、权威、道德、经济等  孤立体系的熵是不断增加的 Slide: 138 Version 质量意识  实质上在今天，对质量的理解已经超出了项目一级的要素。 质量理念的发展反应这种变化 Slide: 139 Version 质量理念的发展：符合性质量  符合性质量， 20世纪 40年代，以符合现行标准的程度作为衡量依据，“符合标准”就是合格的产品质量，符合的程度反映了产品质量的水平。 Slide: 140 Version 质量理念的发展：适应性质量  适用性质量， 20世纪 60年代，适合顾客需要的程度作为衡量的依据，从使用的角度定义产品质量  从“符合性”到“适用性”，反映了人们在对质量的认识过程中，已经开始把顾客需求放在首要位置 Slide: 141 Version 质量理念的发展：满意性质量  满意性质量， 20世纪 80年代，质量管理进入到 TQM阶段，将质量定义为“一组固有特性满足要求的程度”。 它不仅包括符合标准的要求，而且以顾客及其他相关方满意为衡量依据，体现“以顾客为关注焦点”的原则。 Slide: 142 Version 质量管理： TQM  全面质量管理， Total Quality Management(TQM)，是一个组织以质量为中心，以全员参与为基础，目的在于通过让。