|
前面文章聊过IBM的一些人一些事，这个IT行业的百年老店，大方向来说对计算机的发展其作用如树根，基石。小领域譬如软件工程其作用如先知，先行。两位大神级的人物：Frederick Brooks和Watts Humphrey均由IBM出品。前面已立文介绍过两位，印象不深的可以选择回放。 以今天的视角来看，两位大师的成果也有局限也有不足，但其在软件工程发展史的地位无人能撼。今天我要写的是，把两位大师的成果做个串烧，从十个方面对“人月神话”和CMMI做个比较，促进我们理解CMMI实践追求的目的，能够回答“为什么”的问题，而正确读懂模型的价值是有效使用它改进软件工程的基础。在做比较之前，我有个基本假设：开发团队是一个技术强悍的团队。这也是两位大师结论的前提。
打破软件“人月神话”的Brooks 软件质量和CMMI之父Humphrey 人月神话结论一：开发系统软件产品的难度比开发个人使用，独立开发的软件困难得多。产品的通用性，系统的协同性让我们顾此失彼，导致开发的产品不是用户真正需要的！Brooks明确指出，系统软件产品的开发成本是开发具备同样功能的独立软件构件的9倍！ CMMI应对策略一：CMMI给出了成功开发系统软件产品的重要要素：如需要梳理清楚需求的应用场景，开发的约束条件；管理好模块间的接口；建立统一架构支持功能开发；通过评审让相关角色对需求、架构要求、规范要求、缺陷、等达成一致的理解；通过部件级，系统级，使用环境的充分测试确保系统产品的可靠及适用性；在整个开发过程中，管理好不确定的风险，管理好团队之间的协调沟通，管理好共享资源；同时在开发过程中，维护必要的需求可追溯性，并为系统产品提供必要完备的文档，使程序变得易用，易修改，易扩展。很多人都认为CMMI仅代表重量过程，这是因为它是为最复杂场景制定的。殊不知其可裁剪性及其它灵活性使之也可以指导建立、完善为简单场景服务的轻量过程。
人月神话结论二：缺乏合理的时间进度是造成项目滞后的最主要原因。很多人忽略了一个基本事实：煲锅好汤是需要时间的，是无法在不损害结果的情况下加快速度的。人月（man month）为单位的估算是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以互换的。为进度滞后的项目追加人手，只会让项目更加滞后。
CMMI应对策略二：估算是模型中的一个重要环节（CMMI2.0将其上升为一个独立的实践域），它要求团队必须根据系统产品及开发过程活动的重要属性完成估算。在追加人手时，团队必须考虑培训新人及人员沟通的工作量。对计划维护的要求，意味着团队必须不断根据实际情况，做必要的重估算，以保证进度目标的合理性。CMMI四级提出的量化质量目标以及SPC的使用，使得团队无法为了赶进度去削弱必要的质量控制活动。Brooks说：不论你加多少人来帮忙，一个母亲都需要10个月生出一个健康的孩子。CMMI说如果你要一个健康的孩子，必须走完必要的步骤，按历史经验让母亲在第10个月进产房。
人月神话结论三：软件开发需要更加科学，作为一门学科，它缺乏数据支持，估算并不精确。但数据显示出工作量和规模之间存在关系；不同类别软件开发的生产率会在一定范围内浮动；维护成本和开发成本之间存在一定关系；开发工作量和引入的缺陷数量也存在一定关系；系统产品开发生产率比我们想象的要低得多。 CMMI对应策略三：CMMI将建立维护能够支持管理信息需求的度量体系作为科学管理的基础，并给出了一套系统的方法。而量化管理的核心就是掌握开发过程中重要的量化关联关系，并将这些知识用在项目管理及过程改进中去。
人月神话结论四：概念完整性是系统设计中最重要的考虑因素，必须有一个精英团队控制这些概念，一拥而上的开发模式造成软件开发的高成本、低效、延时，而开发出的产品无法实现在概念上的集成。好的设计（如接口少）能减少缺陷，也能减少维护成本；糟糕的架构往往导致系统重构。至少考虑两种以上的实现方式，能让架构定义更加整洁、规范。
CMMI对应策略四：模型要求将架构的选定作为技术解决方案的核心工作，并明确要求给出多种备选方案，并平衡重要标准进行评估。而接口是整个生命周期必须关注的重点。对系统设计做严格有效的评审，也是进过验证的有效做法。
人月神话结论五：由其它人设定目标，必须依靠自己无法控制的东西，责任和权利的分离，也是软件开发面临的挑战。软件项目的失败往往是因为缺乏交流以及支持交流的组织，共享的正式项目工作手册和常规的例会是开发过程中必要的投入。项目是怎样被延期的：一天一天延的。如果进度表和里程碑定义的非常明确，开发人员就无法就进度弄虚作假，关键路径是进度计划的不可替代品；
CMMI对应策略五：相信熟悉模型的朋友，立即可以对应到模型中项目管理的对应策略。 |
|
|
来自： wanglh5555 > 《待分类》
