课件-5 第五章 软件开发过程 最佳软件过程模式.ppt

1、第五章 最佳软件过程模式,5.1 RUP、AP与MP三者的集成 5.2 集成软件过程模式案例 5.3 寻求最佳软件过程模式 习题,5.1 RUP、AP与MP三者的集成,三种各具特色和优缺点的软件过程模式 RUP:来自于专业化过程产品软件公司 AP:来自于自发性软件组织联盟 MP:来自于世界上最大最成功的商业软件公司 三者 集成软件过程模式： 该模式各要素的具体内容 实践中的常见错误及规避策略 该模式适用于用户需求不明确、不稳定的软件项目,结合、取舍 定制、扩充,5.1.1 集成过程模式的生命周期,1生命周期描述 采用RUP中迭代与增量的二维过程结构为主要通用结构框架：本质是阶段性的、渐进的、增

2、量式的交付思想 项目开发过程是重复一系列组成系统生命周期的循环 每次循环包括四个连续的阶段 每个阶段细分为一次或多次迭代 每次迭代经历九大核心流程中的若干项 根据MP思想，在生命周期中的各阶段间增设缓冲时间 降低进度压力和风险 对于有进度时间限制的小型软件开发，采用敏捷过程的思想定制、剪裁该通用过程框架，使其具有快速性、敏捷性 MP的五个阶段可视为部分采用AP思想定制、剪裁RUP的一个范例,5.1.1 集成过程模式的生命周期,2常见错误实践及规避策略 过于乐观的生命周期进度计划 危害：为项目失败埋下了伏笔 乐观的进度计划有时比没有计划更为糟糕，它将缩短项目过程中关键性的前期活动，如需求分析和设

3、计 此外还得承担后期的进度与资金严重超支带来的毁誉,5.1.1 集成过程模式的生命周期,制定出合理进度计划的操作策略 根据软件过程模式后三要素和以往经验进行科学估算，且进度表经过开发小组全体讨论 因为只有计划真正的执行者在进度估算时才会尽可能少的发挥幻想 在以上进度估算基础上，在生命周期的四个阶段之间加上一定的缓冲时间 即“总进度时间=估算的进度时间+各阶段之间的缓冲时间” 这一策略是对各种风险的预估和应对的表现，可能的风险包括客户需求的不断修改或增加、对新技术新工具掌握难度的低估或存在缺陷的认识不足、人员的变动等等,5.1.1 集成过程模式的生命周期,进度计划具体内容： 各阶段里程碑+细致度

4、逐渐降低的计划策略 细致度逐渐降低的策略：为下两周做详细的计划，为下三个月做粗略的计划，再以后就作极为粗糙的计划。即应该清楚地知道下两周要完成的任务，粗略地了解一下以后三个月要实现的需求，至于系统一年后将要做什么，有一个模糊的想法就行了 意义：仅仅对于迫切的任务才花费时间进行详细的计划。一旦制定了这个详细的计划，就很难进行改变，因为团队会知道根据这个计划启动工作并有了相应的设入。然而，由于计划仅仅支配了几周的时间，计划的其余部分仍然保持着足够的灵活性与可塑性，这样在形势发生变化时能够迅速调整以适应商务和技术方面发生的变化 当来自客户、市场人员、上级等各方面的进度要求难以实现时，应坚决地、同时是

5、技巧性地顶住压力、据理力争；案例见下。,5.1.1 集成过程模式的生命周期,案例：一次成功的进度谈判 Tina 领导的项目组经过大量的工作，估算出项目Giga-Bill1.0的进度时间为12个月。她的上司 Bill对此估算很不满意，认为应当再短些。在项目预审会上，Tina发现自己被Bill出卖了。 “项目组估算6个月内能开发出产品。”Bill说。 “呃哼！”Tina清了清喉咙。“Bill的意思是在理想状况下最短需要6个月，这要求在开发过程中不能有任何差错。而各位都很清楚软件的开发过程，其中每一件事都无法保证毫无瑕疵。因此我们认为最现实的估算为12个月，浮动范围为12至15个月。”Tina真希望

6、有一块手帕能擦擦额头上不断冒出的汗。 来自财务部门的Catherine问道：“不能再短些吗？” “我也希望能。”Tina回答。“但这个进度计划是经过我们小组全体成员的仔细分析才得出的。我当然可以报一个较短的时间， 但它的价值如同一张白纸一般，不但对开发速度的提高不起作用， 相反还增加了延迟的可能。事实上，产品的定位还有很多待推敲的地方，对其精练的同时也可能可以缩短开发进度。”她开始讨论估算收敛曲线，并由于进入自己熟悉的话题而感到些许轻松。,5.1.1 集成过程模式的生命周期,“上述过程并非是唯一的，”Tina 总结道，“还有很多通过调整产品定义和资源投入来缩短进度的方法，选择范围还是很大的。”

7、她接着解释了几种不同组合的备选方案。委员会成员就这些方案提了些问题，并对 Tina的回答表示满意。 “我会认真考虑你的建议，”Catherine说，“12个月确实有些长，但你给我们提供了许多具有吸引力的备选方案。”Tina 表示欢迎她随时打电话提出问题或讨论更多的方案。 会后，Bill 仍在生气。“下次不要跟我玩花样。”他瞪视着Tina。“为什么在会上改变我的估算？” “你的估算？”Tina反问，“你并未做什么估算，你只有一个不现实的目标。我们不想自不量力地试图达到根本无法实现的进度计划，12个月是这个项目得以完成的最短时间。咱们公司，包括你，以前曾有过进度与资金超支的教训，我只是不希望你再犯

8、同样的错误。刚才我已尽力不使你难堪，我想委员会能接受我的提议。” “情况确实比我想像中要好，”Bill承认，“这次我不再追究，不能有下一次。” “好的。”Tina答应着，怀疑自己是否还需要有下一次。会上纠正 Bill 的时候她紧张得胃部抽搐，但她明白如果现在不阻止，9个月后还得那么做，而这9个月中开发人员将不得不紧张而无序地工作，生产出的低质量代码将使项目完成时间可能比12个月还要长。总的来说，Tina认为自己做了正确的事情。,5.1.1 集成过程模式的生命周期,进度落后时增加新手、取消设计、缩短测试时间等 进度一旦落后，必须采取一定的措施挽救 方法之一：投入更多的开发人员 增加的人员应该具有

9、该领域的经验，不可以是新手 尤其是在项目后期，新手会产生很多新的错误，使项目混乱，再者老员工向新手解释工作以及交流思想都要花费时间，使实际开发时间更少，因此此时增加新手相当于越帮越忙。 方法之二：砍掉一些不重要的工作 如去掉一些不重要的文档撰写工作 但设计和测试工作是开发过程中质量保证的两个重要环节，消减这些重要的工作将导致在项目后期付出相应几倍的弥补代价 其它方法：去除产品的一些次要功能或性能需求,5.1.2 集成过程模式的人员,1人员描述 人员及组织管理采用MP中的矩阵结构模式 人员角色组成 包括产品管理、程序管理、开发、测试、用户体验与发布管理六种 工作关系 地位平等，交流与沟通 项目组

10、工作结构:由产品特性确定 大型项目组根据产品特性拆分为多个小型项目组 每个小型项目组负责产品的一个特性或一个功能模块 各小型项目组并发完成工作并设置多个同步点,5.1.2 集成过程模式的人员,项目组人员数量与质量 每个项目组成员来自矩阵结构中的横轴，由六种角色构成，不同角色可以合并，合并后每个小型项目组的人数不多于10人 每种角色都有一名专家式带头人或负责人 人员行政组织管理 为矩阵结构中的纵轴专家式管理方式 人员的激励机制： 物质方面的激励：包括高薪、奖金、股权、舒适的工作环境和合理的工作时间及假期等 精神方面的激励：包括受重视尊重的程度、兴趣程度、个人技术技能不断得以提高的机会、得以提拔升

11、迁的机会,5.1.2 集成过程模式的人员,“W理论” 项目干系者和他们的目标：相互冲突 用户“大量的特色” 与客户的“进度快”、“花尽可能少的费用” 目标相冲突 开发者 “有兴趣的开发工作” 客户“用尽量少的时间”目标冲突 开发者“没有厌烦的工作” 与维护者 “文档出色”目标冲突,5.1.2 集成过程模式的人员,“W理论” 以收益-受损(win-lose)或者受损-受损(lose-lose )模式进行目标协调，项目最终都不会成功 对客户而言，项目有时看起来像一只服用了安眠药的海龟 而同时对开发者来讲，却像是在拼了命地快速开发 项目成功的必要条件“让所有的干系者都成为获胜者” 开诚布公地了解各干

12、系者各自的利益 对各干系者的利益要求所产生的冲突进行协商，让所有干系者实现各自的利益要求,5.1.2 集成过程模式的人员,2常见错误实践及规避策略 人月神话 典型的“人月神话”：根据人力资源的数量制定项目进度计划 类比：电影的拍摄中，导演与演员两个角色的质量 开发过程对人员角色的质量不加以区分 造成一种误解，即同一角色可由不同个体替代 计划一个项目时，不在乎能得到哪个分析员、哪个开发人员、哪个测试员，只关心可得到多少 另一种表现形式：向进度落后的项目中增派新手 启示：项目组的人员组成不仅与数量有关，更重要的是人员的质量，包括人员的领域经验、团队意识等,5.1.2 集成过程模式的人员,个人英雄主

13、义 软件发展的第一阶段程序设计阶段，造就了很多个人英雄 那个时期的程序相对简单，一个人基本上可以完成一个软件 例如：国内的求伯君、吴晓军、鲍岳桥、王志东、王江民 现代的软件工程阶段和软件过程阶段，最需要的就是一种团队精神 软件规模大，需要大批程序员通力合作方可完成 金山公司总裁雷军语，“现在已经过了个人英雄主义时代了，我们更为看重的是团队英雄主义”,5.1.2 集成过程模式的人员,过度超时工作或强迫加班 少量的加班能增加每周完成的工作量，有助于保证进度计划的如期完成 过度的超时工作反而会影响人员的工作效率、降低产品质量 敏捷过程提倡可持续的开发速度，认为项目不是50米短跑，而是马拉松长跑，跑得

14、过快会导致团队精力耗尽、出现短期行为以致崩溃，因而他们工作在一个可以使在整个项目开发期间保持最高质量标准的可持续速度上 应通过强调项目的重要性鼓励适当的自愿加班,5.1.3 集成过程模式的方法,1方法描述 (1)关于需求分析方面 构建用户界面原型以获取需求 将一个可见的、可触摸的、可操作的用户界面原型显示于用户面前比用一般的书面说明方法能更有效的获取用户的需求 通过用户的反馈不断修改原型，这样在项目初期能尽可能的多的获取一些用户较明确的需求轮廓,5.1.3 集成过程模式的方法,基于用例角度的项目前景/项目范围 属RUP与MP方法的交集解决需求的多样性 项目前景和项目范围分别描述了项目的远景目标

15、和近期目标 以上描述中从用例角度给出系统为具体每一个用户提供何种价值 即对客户群进行细分，为不同的客户群体提供不同的功能 例：IE浏览器的开发 微软将客户群分为Internet的新用户与Netscape的老用户、个人用户与企业用户，这种全面、细致的需求分析帮助微软赢得了众多的客户,5.1.3 集成过程模式的方法,动态满足需求欢迎变化、先基线化后冻结：属AP与MP的交集解决需求的动态性 对需求变化的态度：欢迎变化 利用变化来为用户创造竞争优势 在项目一开始就应采取各种措施保持过程中各产品的灵活性，以保证系统对变化具有较大空间的可容纳性与适应性 例如，签订带有指导与客户协同工作方式而非指明了需求进

16、度的合同 制定细致度逐渐降低的灵活可塑的计划 进度计划中设置生命周期各阶段之间的缓冲之间 构架设计上保证系统的可扩展性等,5.1.3 集成过程模式的方法,合理控制客户期望的变化值变化允许时限：先基线化，后冻结 在项目开始阶段，建立用户界面原型，通过原型不断主动地征集客户对需求变化的意见 在项目中途，尽量满足最重要的需求变更，将不太重要的要求则推迟到下一个版本中实现 在项目末期，对需求进行冻结，不再允许任何变更 既实现了客户比较满意的目标，又避免了出现项目延期的问题,5.1.3 集成过程模式的方法,(2) 关于设计方面 首先确定是自行建造、复用还是外包 自行开发：实现成本最高，同时对核心技术掌握

17、的主动权也最大 复用：能有效缩短开发时间，但要求对被复用系统有透彻的理解与掌握 外包 在公司内部开发遇到困难时可采用外包方式 要求承包方在该业务领域有丰富的经验，能够在给定的时间内投入足够的开发人员，并且已备有一个大的程序库可提供重用代码 由于外包风险较大，因此外包比自行建造需要更好的进度管理,5.1.3 集成过程模式的方法,选择以构架为中心还是简单化设计 以构架为中心 属于RUP，考虑产品的适应性、可扩展性与可重用性等高性能需求，提倡以构架为中心的设计方法，要求构架必须留有实现现在和未来需求的所有用例空间 简单化方法 属于AP，反对过早使用复杂的模式，反对为支持未来的需求而过度构架系统 两种

18、方法的对立与统一 对产品不同质量要求的不同的应对策略 在可预见的最近几次产品开发的生命周期内，对产品质量的要求均仅为无缺陷要求，而对产品的适应性、可扩展性、可重用性等高性能指标没有要求，此时应选用AP的简单化设计方法，以达到快速开发的目的 反之，对产品质量的要求不仅为无缺陷要求，而且对适应性、可扩展性、可重用性等高性能指标可能有若干要求，此时应选用RUP的以构架为中心设计方法，以避免可能发生的系统整体重构造成最终开发效率的极速下降,5.1.3 集成过程模式的方法,以产品特性及优先级指导整个项目 该方法属于微软过程 实质与RUP渐进增量的交付思想一直 即先交付重要的、优先级别高的产品特性，再交付

19、次要的、优先级别低的产品特性，以此缓解进度压力和风险,5.1.3 集成过程模式的方法,(3) 关于实现方面 代码优化 代码的性能包括运行效率、安全性、稳定性、可理解性、可维护性等多个方面 例：在代码效率方面 明确软件开发中的优劣酸法之间的差距是靠硬件的投入平衡不了的 代码必须不断优化其算法、数据结构和程序结构以达到较高的运行效率,5.1.3 集成过程模式的方法,源代码管理 建立源代码的管理库，每日Check-in进行持续更新和集成 每日编译生成或持续集成 每日编译由微软过程提出 持续集成由XP提出 两者本质是相同：有助于团队保持一个较高的开发速度，同时避免了一次系统集成的恶梦,5.1.3 集成

20、过程模式的方法,(4) 关于测试方面 零缺陷观念 这一质量管理的观念来源于一些国际上著名的硬件生产厂商 原始核心内容：一是高目标，二是可执行的规范。 微软过程中的零缺陷观念 并不要求产品中没有Bug 在产品的每一个阶段，在发布产品的每一个版本之前都对已发现的产品Bug进行了有效的管理和控制，改正了影响产品使用的Bug，对不影响产品使用、且因资源有限无法及时修改的Bug进行跟踪和记录，确保使产品中所有已发现Bug都在项目组的控制范围之内，都可以在适当的时机得到修正,5.1.3 集成过程模式的方法,手工测试与自动测试结合 自动测试 优点：能够很快、很广泛的查找Bug 缺点：只能检查一些最重要的问题

21、，如崩溃、死机，但都无法发现一些一般的日常错误 手工测试 优点：很容易找到一些一般的日常错误 通常手工测试与自动测试相结合,5.1.3 集成过程模式的方法,内部测试与外部测试相结合 内部测试：开发人员与独立测试小组共同完成 开发人员：执行“白盒”测试，即根据源程序内部逻辑结果测试程序的过程性细节， 独立测试小组：执行“黑盒”测试，即完全不考虑程序内部的逻辑结构，只依据程序的需求规格说明书检查程序的功能是否符合其功能说明 同级评审测试的方法：对于没有条件设立独立测试小组的公司，可采用，让开发小组的成员相互测试对方的程序 外部测试：则交于专门的、权威的测试机构以及现场用户进行测试,5.1.3 集成

22、过程模式的方法,(5) 关于过程方法实施的工具方面 选用有效工具 有效工具是指能提高工作效率和工作质量的工具 如Rational Solutions中著名的配置管理工具ClearCase、变更管理工具ClearQuest、UML建模工具Rose、Microsoft的项目管理工具Project等 在有效工具的选择方面，建议选用比较成熟的、已被很多厂家或客户实践证明是有效的工具 对任何新工具的选用需高度审慎 新工具很少能达到其供应商宣传的效果 新工具可能存在这样或那样的缺陷或局限性 学习使用新工具需要培训费用和培训时间,5.1.3 集成过程模式的方法,2常见错误实践及规避策略 外包不需要严格的进度

23、管理和风险管理 案例：一个外包的项目 “我获得批准做Square-Plan25。”Kim告诉Eddie。Kim和Eddie都是商业封装软件公司 Square-Tech的项目经理。“我要在4个月内交付产品，我想这将是个令人震撼的产品。”Kim 的上一个项目Square-Calc3.0拖延了很长时间，Eddie的上一个项目Square-Plan2.0做得很好，Kim急于证明她刚刚完成的产品要比Eddie的产品更复杂些。 “我现在还不能太乐观 ，”Eddie告诉她，“我看了2.5版的性能说明书，我想用现在的开发小组你至少需要6个月的时间。你还用2.0的开发小组吗？” “是的，我已经有了将计划缩短为4

24、个月的办法。我上周读了一篇关于工作外包的文章，而且我已经找到了一个承包商，他可以为我们做图形处理部分的升级工作。这可以将计划节省2个月的时间。”,5.1.3 集成过程模式的方法,“噢，我希望你能知道他们正在做什么，”Eddie说，“我知道好多人被承包商害得焦头烂额。你的风险管理计划是什么呢？” “我已经选择了一个信誉良好的承包商 ，”Kim说，“我检查了他们的证明材料，我相信他们会做得很好，我只要经常去看看就可以了。这本来就是有风险的事情，有一些风险是不可避免的。我还有很多实际的工作要做，没有必要把时间浪费在没有用的管理上。”Eddie认为她应该多加小心，但之前他和Kim有过类似的争论，他已经

25、学会了当她已经决定要做的时候不去与她争论。“祝你好运。”他说。 Kim马上约见了承包商，并把要升级的图形部分的性能说明书交给了他。承包商Chip说，性能说明书已经很清楚了，并主刻带走它。 6周后，Kim打电话给Chip问开发进度。“一切进展顺利，”他说，“我正在做另一家公司很紧急的项目，所以现在的进度不像希望的那样快。但我还有3个半月时间来完成2个月的工作量，所以我看没什么问题。” “听起来很好，”Kim回答道，“如果需要什么告诉我，6周后我会再与你联络，那时我们就可以谈谈集成的问题了。”,5.1.3 集成过程模式的方法,6周后，Kim 再次致电检查进度。“上个项目花费的时间比我想像的要长，”

26、Chip说，“我已经开始图形处理部分的升级工作了，我正在疯狂地工作，但经过我仔细地分析研究，我认为这项工作可能最少要花费3个月的时间。” Kim几乎背过气去，这将使整个开发进度从4个月增加到6个月。“3个月 ! 你在开玩笑 ? 我需要在2周内对那部分代码进行集成，我以为你现在应该已经基本上做完了 !” “对不起，”Chip说，“但这不是我的错，这项工作远比你估计的多，我会尽快完成的。” Chip3个月后完成了工作，项目又花了1个月的时间与内部开发的代码相集成，最后整个开发时间由计划的4个月变成了7个月。Kim 断定Eddie推脱了他自己也无法完成的项目，从而坑害了她。 小结：外包的项目 由于缺

27、乏对外包过程进度的可视性，因此外包较自行开发需要更好的风险管理和进度管理，包括对承包商资质的评估、签定合同种类的选择、与承包商的持续沟通、违约责任的明确等,5.1.3 集成过程模式的方法,银弹工具 常见银弹工具： 包括4GLs（第四代语言）、CASE工具、自动化编程等，这些银弹往往宣称能大幅度提高生产效率、缩短开发时间 银弹工具的实践效果 很少能达到其供应商宣传的效果 学习使用这些银弹新工具需要培训费用和培训时间，这反过来延长了开发时间 更严重的是，这些银弹新工具往往存在这样或那样的缺陷或局限性，这将进一步降低效率或影响产品性能的其它方面 在进度计划制定时不要对银弹工具抱有过多幻想,5.1.3

28、 集成过程模式的方法,银弹工具的实践效果案例 “我真不知道为什么又一次鬼迷心窍地接受了一个根本就不可能的截止日期。”Mike 向他的开发组发牢骚说：“人家要求我们3个月就开发出一个完整的新收账系统，可实际上这个系统至少得花5个月。我想这一下我们有压力了。” “不一定吧 ？”Angela说，“我刚得到一份Blaze-O-Matic可视化编程语言第一版的宣传册子。手册上说我们很容易就能够2倍乃至3倍地提高我们的开发速度。它采用面向对象编程。我想不管怎样我都得试一下。你觉得怎么样？” “2倍或3 倍？”Mike说，“我还不知道我该不该相信呢。只是到目前为止我还没有其它选择。就算它不能缩减开发时间的一

29、半或者三分之一，但减去1个或2个月总行吧。我也认为面向对象编程对我们的项目有利。行，就是它了！” 于是项目马上就被启动了。用Blaze-O-Matic来构建基本的用户界面非常快捷，就连开发组都有点儿吃惊了。数据库支持能力也相当不错，而且程序运行也快。虽说该工具其它部分较难掌握，但到第2个月时，产品的一半已经开发出来了。这时开发组觉得他们在项目前一阶段在经历了学习曲线的同时，还达到了这种效果，因而乐观地认为到第3个月的截止期限，他们肯定能够完成产品的另一半了。,5.1.3 集成过程模式的方法,然而就在这时，他们发现了他们新工具的不足之处。Angela有点儿失望地说：“嗨，Mike，我刚发现帮助屏

30、与我们想像的不一样，链接它并不容易。我还以为一下午我就能够为所有的帮助屏设置好链接的，但没想到的是，Blaze-O-Matic并不支持上下文相关的帮助。这下要花时间了。”Mike 告诉她，集成帮助是新收账系统的关键特征之一，不管要花多少时间，问题必须得到解决。 3个月过去了，开发组却发现了Blaze-O-Matic越来越多的不足之处：Blaze-O-Matic宣称能够自动地从ASCII文件中导出记录至数据库当中，开发组还曾指望用这个特性来把旧收账系统的记录转换成新的数据库格式。但鉴于Blaze-O-Matic无法处理他们的文件使用的记录类型，开发组就不得不为访问例程重新手工编码。另外，报告模块

31、也不稳定，而且还恰好不能支持他们需要的那种报告格式，所以开发组又不得不花大量时间来进行编码，而且即使当他们自认为已经完成之后，报告格式中的小错误仍然会时不时出来发作一下。 3个月的截止期限到了，可开发组还有25%的产品没有完成，而且他们也坦承，就算是全力以赴地干，至少还得2个星期。 “看来我得汇报一下这个坏消息了。”Mike 说。然而当他回来后，Angela 又有一个不好的消息等着他。 “你还记得那些帮助屏吧 ? 事实上，Blaze-O-Matic并不支持上下文相关的帮助链接，而且它还根本无法从一个程序的内部显示出帮助信息来。我曾设想把显示帮助当作一般程序来处理，但是Blaze-O-Matic

32、对显示帮助的那个程序 ID,5.1.3 集成过程模式的方法,的处理简直就是莫名其妙。而且如果别的程序已经打开了帮助的话，Blaze-O-Matic会关闭他们的帮助但却不打开我们的。我现在正成天跟他们的技术支持电话联系，他们说他们可以为这个问题发来一个补丁，但现在他们正忙着一个新版本，补丁很可能要等到3周后才有结果。 “混蛋！”Mike骂道，“刚才我还告诉老板说两周内全部打包完毕呢！他们就不能快点？”“恐怕不会。”Angela说，她已经在电话上探寻过这种可能性了。“我想这下我们卡住了。” 在等补丁的时候，开发组仍然有大量的事要做。补丁是4周后而不是3周后到达的，产品余下的 25%也是花了6周而不

33、是期望的2周完成的。他们最终是在4个半月的时候完成了产品的交付。 产品交付之后不久，开发组为此作了事后总结，并建议公司再也不要用Blaze-O-Matic。他们得出的结论是，Blaze-O-Matic能够部分加快开发速度，但是使用它又不得不做出太多的设计权衡。程序的实际使用与他们设想的情况大不一样。 一年之后，Angela在同公司其他部门的朋友聊天中发现，朋友居然在他们的项目上也有着使用Blaze-O-Matic的类似经历，而且该项目的开始时间是在Angela的开发组做出事后总结后的一个月。,5.1.4 集成过程模式的产品,1产品描述 对各种中间和最终产品的分类 采用RUP的工件类型划分方法，

34、同时参照其工件模板 各类产品的优先级 可以工作的软件胜于面面俱到的文档（属敏捷过程） 具体程序创建与文档编制两个方面活动的控制原则 软件开发的主要和中心活动就是创建可以工作的软件 直到迫切需要且意义重大时，才进行文档编制 编制的内部文档应尽量短小并且主题突出，满足这种要求的最好的文档形式是模型（属RUP）,5.1.4 集成过程模式的产品,产品度量：产品功能规模+产品质量性能 产品功能规模 强调尽早确定产品功能特性，以产品的功能特性及优先级指导整个项目，因为功能特性代表的就是产品的竞争力 产品质量要求 一种要求：较低的缺陷率 另一种要求：包括所有高质量性能特性，如可读性、易维护性、健壮性、可扩展

35、性、适应性、可移植性、可剪裁性、可重用性等 产品功能规模和质量特性的的控制 应与项目的人员投入、资金投入和进度要求相适应 产品的功能规模与质量性能的控制为缩短计划进度提供了的机会 划分产品各功能/性能特性的优先级又为保证产品的顺利交付降低了风险,5.1.4 集成过程模式的产品,2常见错误实践及规避策略 功能或性能膨胀 案例：微软IE浏览的开发 项目初期收集到大量需求 如果兼顾所有需求，产品会变得异常宠大，项目的开发进度就会一拖再拖 最终确定只应该关注那些用户最常使用的、市场最需要的关键特性需求,5.1.4 集成过程模式的产品,避免功能或性能膨胀的措施 在项目初期：确定产品特性及优先级，作到尽量

36、简单化 在项目中期：对客户需求变更的要求，尽量满足重要的功能，次要的可留至下一版本实现 在项目末期：冻结产品功能和性能需求，甚至在进度落后的情况下可适当删减一些次要功能的实现,5.1.5 集成过程模式的生命周期、人员、方法与产品四要素间的相互关系,1四要素关系描述 四要素的关系： 采用微软过程中的均衡三角形，即发布一个符合客户需求的产品，其关键在于项目组必须在过程进度时间、项目人员与方法工具等资源、产品的功能和性能之间寻求最佳的平衡点。这是一种协同均衡的关系。 项目人员与方法工具的优先级设置： 大体采用敏捷过程的价值观，即项目人员的个体与交互胜过方法和工具,5.1.5 集成过程模式的生命周期、

37、人员、方法与产品四要素间的相互关系,2常见错误实践和规避策略 “既要马儿跑的好，又想马儿不吃草”,想开发出多功能、 高性能的软件产品,不能给予开发项目 组充足的资金投入 （用于网罗高质量 开发人员、创建高 效的工作环境等） 和开发时间投入,这类项目开发 一般以失败告终,5.1.5 集成过程模式的生命周期、人员、方法与产品四要素间的相互关系,可行的解决方案 或者削减产品功能或性能 或者在项目人员和方法工具方面增加资金投入， 再或者就只能是延长生命周期的进度计划时间，三者必须且至少取其一,5.2 集成软件过程模式案例,亲自参与、主持的两个成功的软硬件开发项目和集成项目的实例 体现了集成过程模式的基

38、本思想,5.2.1 高压变电站监控系统开发项目案例,项目概述 项目内容 本系统为针对高压变电站开发的一套集采集、监视、控制为一体的计算机监控系统，属大型软件开发项目 项目意义 它的开发成功将作为该公司从低压领域向高压领域拓展的起点标志 项目关键 按照进度计划如期交付产品，以免错过产品发布的市场时机,5.2.1 高压变电站监控系统开发项目案例,1.项目生命周期 采用RUP的迭代与增量的二维生命周期结构，整个项目历时14个月，各渐进的过程阶段及里程碑如下: 先启阶段 将原有维护软件作为用户接口原型，使用该原型与具有高压变电站项目集成经验的工程人员和现场用户进行有效交流，通过他们多次对原型的反馈修改

39、后确定最终原型和系统总体需求；该阶段历时2个月，结束标志为系统需求分析和可行性论证方案通过电科院和一些省网局电力专家的评审，即达到生命周期目标里程碑 精化阶段 历时1个月，完成详细设计方案，即达到生命周期构架里程碑,5.2.1 高压变电站监控系统开发项目案例,构建阶段 包括3次迭代过程 第1次迭代过程:交付第1批样机，该批样机并不完善，但保证能在公司每年例行的新产品对外展览会上正常演示 第2次迭代过程:交付一批通过国家权威测试机构电科院入网测试的样机 第3迭次代过程:交付可投入现场试运行的样机 3次迭代过程历时7个月，经过3次迭代过程后达到了最初操作性能里程碑 产品化阶段 包括2次迭代过程，分

40、别为小批试运行和批量投产；2次迭代过程历时4个月，经过2次迭代过程后达到了产品发布里程碑,5.2.1 高压变电站监控系统开发项目案例,2.项目人员 项目组工作结构 根据产品特性，整个项目组大体分为硬件小组、软件小组和结构工艺小组 进一步细分，如硬件小组又分为主板组和单板组，软件小组分为软件平台组、数据库组、通讯组、后台监控组等,5.2.1 高压变电站监控系统开发项目案例,人员组成、分工与管理 人员组成 基本上是一种矩阵管理模式，项目组人员是抽调了公司下属的两个事业部不同的硬件平台室、软件平台室、通讯平台室、后台监控室、保护室中的精兵强将组成。其中，硬件小组10人，软件小组9人，结构工艺小组7人

41、，每个小组由一名技术带头人负责 人员分工方面 一个开发人员往往同时担任多个角色，如软件平台开发人员还同时完成部分通讯规约编写任务 在项目进展过程中进度落后的解决的方法 增加人员，但这些人员不是新手，而是具有低压变电站监控系统开发经验的老员工,5.2.1 高压变电站监控系统开发项目案例,人员的激励机制 开发人员的高薪和项目奖金 远离干扰的封闭开发环境 项目组还在距离公司不远的高档写字楼内专门租用了一间大型办公室为开发人员创造封闭开发环境，以免呆在公司内部日常一些不必要的杂事干扰 组织渡假 样机通过电科院入网测试后，组织了一次全体人员可携带家属去风景名胜区度假两天的活动,5.2.1 高压变电站监控

42、系统开发项目案例,3.项目方法 (1)关于需求分析方面 基于用例角度的项目前景/项目范围 项目范围：公司原低压变电站监控系统存在缺陷的改进，原RTU监控系统功能的补充与完善，最终实现这两个监控系统监控平台的统一以实现互连，并与西门子保护产品配套合作进入高压领域。 项目前景：进军电铁与城市轨道交通领域,5.2.1 高压变电站监控系统开发项目案例,动态满足需求 在项目进展前期和中期不断直接走访用户以及搜集来自市场人员的用户反馈，对具有一定普遍意义的新功能需求予以满足 如针对某些站不设置后台的需求而增加了开发网络打印服务器的内容 在产品型号设计方面，为适应不同用户不同的配置要求，对产品型号进行了系列

43、化设计,5.2.1 高压变电站监控系统开发项目案例,(2)关于设计方面 确定整合式复用的建造方法 选择以构架为中心 考虑到为保持产品持续的竞争力，每隔23年就需要往更好的微控制器硬件平台和嵌入式操作系统软件平台移植升级的需要,5.2.1 高压变电站监控系统开发项目案例,(3)关于实现方面与有效工具选用方面 在对华为、北京Motorola等公司使用Rational ClearCase效果的调研基础上，选择了该配置管理工具进行源代码库管理和每日编译集成,5.2.1 高压变电站监控系统开发项目案例,(4)关于测试方面 内部测试与外部测试相结合 内部测试:包括开发人员白盒测试与质检部门的黑盒测试 外部

44、测试:在国家电力产品权威测试机构电科院进行,5.2.1 高压变电站监控系统开发项目案例,4.项目产品 以产品特性及优先级指导整个项目 因此在交付顺序上，优先完成采集、监视、控制、通讯等主要功能，而组态编程、嵌入式WEB服务器功能的实现是在最后的产品发布阶段的完成的，这样进度压力和风险得以一定程度缓解,5.2.1 高压变电站监控系统开发项目案例,5.项目生命周期、人员、方法与产品四要素间的相互关系 在该项目生命周期进度一定的情况下，选择了产品功能&性能，并对人员与方法工具等资源作了必要的调整,5.2.2 热电厂再生废水处理自控系统集成项目案例,项目概述 项目内容 中小型系统集成项目 项目意义 作为敲门砖，通过该项目出色的质量、服务和信誉给客户留下良好的印象，进而期望能够承接该厂即将上马的大型二期工程项 项目关键 完善的系统产品功能和性能,5.2.2 热电厂再生废水处理自控系统集成项目案例,1.项目生命周期 采用RUP的迭代与增量的二维生命周期结构，整个项目历时4个月，各渐进的过程阶段及里程碑如下 : 先启阶段 与多方用