件-5 第五章 软件开发过程 最佳软件过程模式PPT教学课件

危害：为项目失败埋下了伏笔
乐观的进度计划有时比没有计划更为糟 糕，它将缩短项目过程中关键性的前期活 动，如需求分析和设计 此外还得承担后期的进度与资金严重超 支带来的毁誉
5.1.1 集成过程模式的生命周期
制定出合理进度计划的操作策略
根据软件过程模式后三要素和以往经验进行 科学估算，且进度表经过开发小组全体讨论
三者 结合、取舍 集成软件过程模式：
定制、扩充
该模式各要素的具体内容 实践中的常见错误及规避策略 该模式适用于用户需求不明确、不稳定的软件项目
5.1.1 集成过程模式的生命周期
1．生命周期描述
采用RUP中迭代与增量的二维过程结构为主要通用结构框架： 本质是阶段性的、渐进的、增量式的交付思想
项目开发过程是重复一系列组成系统生命周期的循环 每次循环包括四个连续的阶段 每个阶段细分为一次或多次迭代 每次迭代经历九大核心流程中的若干项
“项目组估算6个月内能开发出产品。”Bill说。 “呃哼！”Tina清了清喉咙。“Bill的意思是在理想状况下最短需要6个月，这要 求在开发过程中不能有任何差错。而各位都很清楚软件的开发过程，其中每一件事 都无法保证毫无瑕疵。因此我们认为最现实的估算为12个月，浮动范围为12至15个 月。”Tina真希望有一块手帕能擦擦额头上不断冒出的汗。 来自财务部门的Catherine问道：“不能再短些吗？” “我也希望能。”Tina回答。“但这个进度计划是经过我们小组全体成员的仔细分 析才得出的。我当然可以报一个较短的时间， 但它的价值如同一张白纸一般，不但 对开发速度的提高不起作用， 相反还增加了延迟的可能。事实上，产品的定位还有 很多待推敲的地方，对其精练的同时也可能可以缩短开发进度。”她开始讨论估算 收敛曲线，并由于进入自己熟悉的话题而感到些许轻松。
5.1.1 集成过程模式的生命周期
进度计划具体内容： 各阶段里程碑+细致度逐渐降低的计划策略
细致度逐渐降低的策略：为下两周做详细的计划，为下三个月做粗 略的计划，再以后就作极为粗糙的计划。即应该清楚地知道下两周要 完成的任务，粗略地了解一下以后三个月要实现的需求，至于系统一 年后将要做什么，有一个模糊的想法就行了 意义：仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定 了这个详细的计划，就很难进行改变，因为团队会知道根据这个计划 启动工作并有了相应的设入。然而，由于计划仅仅支配了几周的时间， 计划的其余部分仍然保持着足够的灵活性与可塑性，这样在形势发生 变化时能够迅速调整以适应商务和技术方面发生的变化
5.1.1 集成过程模式的生命周期
进度落后时增加新手、取消设计、缩短 测试时间等
进度一旦落后，必须采取一定的措施挽救
方法之一：投入更多的开发人员
增加的人员应该具有该领域的经验，不可以是新手 尤其是在项目后期，新手会产生很多新的错误，使项目混乱，再 者老员工向新手解释工作以及交流思想都要花费时间，使实际开发 时间更少，因此此时增加新手相当于越帮越忙。
根据MP思想，在生命周期中的各阶段间增设缓冲时间
降低进度压力和风险
对于有进度时间限制的小型软件开发，采用敏捷过程的思想定 制、剪裁该通用过程框架，使其具有快速性、敏捷性
MP的五个阶段可视为部分采用AP思想定制、剪裁RUP的一个范例
5.1.1 集成过程模式的生命周期
2．常见错误实践及规避策略
过于乐观的生命周期进度计划
会后，Bill 仍在生气。“下次不要跟我玩花样。”他瞪视着Tina。“为什么在会 上改变我的估算？”
“你的估算？”Tina反问，“你并未做什么估算，你只有一个不现实的目标。我们 不想自不量力地试图达到根本无法实现的进度计划，12个月是这个项目得以完成的 最短时间。咱们公司，包括你，以前曾有过进度与资金超支的教训，我只是不希望 你再犯同样的错误。刚才我已尽力不使你难堪，我想委员会能接受我的提议。”
第五章 最佳软件过程模式
5.1 RUP、AP与MP三者的集成 5.2 集成软件过程模式案例 5.3 寻求最佳软件过程模式特色和优缺点的软件过程模式
RUP:来自于专业化过程产品软件公司 AP:来自于自发性软件组织联盟 MP:来自于世界上最大最成功的商业软件公司
因为只有计划真正的执行者在进度估算时才会尽可能少的发 挥幻想
在以上进度估算基础上，在生命周期的四个 阶段之间加上一定的缓冲时间
即“总进度时间=估算的进度时间+各阶段之间的缓冲时间” 这一策略是对各种风险的预估和应对的表现，可能的风险包 括客户需求的不断修改或增加、对新技术新工具掌握难度的低 估或存在缺陷的认识不足、人员的变动等等
5.1.1 集成过程模式的生命周期
“上述过程并非是唯一的，”Tina 总结道，“还有很多通过调整产品定义和资 源投入来缩短进度的方法，选择范围还是很大的。”她接着解释了几种不同组合的 备选方案。委员会成员就这些方案提了些问题，并对 Tina的回答表示满意。
“我会认真考虑你的建议，”Catherine说，“12个月确实有些长，但你给我们提 供了许多具有吸引力的备选方案。”Tina 表示欢迎她随时打电话提出问题或讨论更 多的方案。
“情况确实比我想像中要好，”Bill承认，“这次我不再追究，不能有下一次。”
“好的。”Tina答应着，怀疑自己是否还需要有下一次。会上纠正 Bill 的时候她 紧张得胃部抽搐，但她明白如果现在不阻止，9个月后还得那么做，而这9个月中开 发人员将不得不紧张而无序地工作，生产出的低质量代码将使项目完成时间可能比 12个月还要长。总的来说，Tina认为自己做了正确的事情。
当来自客户、市场人员、上级等各方面的进 度要求难以实现时，应坚决地、同时是技巧性 地顶住压力、据理力争；案例见下。
5.1.1 集成过程模式的生命周期
案例：一次成功的进度谈判
Tina 领导的项目组经过大量的工作，估算出项目Giga-Bill1.0的进度时间为12个 月。她的上司 Bill对此估算很不满意，认为应当再短些。在项目预审会上，Tina发 现自己被Bill出卖了。