CMM/CMMI 的优缺点: 优点该模型提供了大量的以行业最佳实践为基础的背景信息和指导信息,如果
使用得当,这些信息可能会很有价值.过程域的层次划分便于以渐进方式进行改进,这会更为有效和持
久.过程域的划分使过程改进活动中心更为突出,也更容易管理.有限的范围可以提供更精深的细节,并
为与项目有关的过程提供指导.CMMI 目标和共性实践的描述方式使其可以适用于很多类组织和项
目.CMMI 提供了成熟度级别(阶段式表示法)和能力级别(连续式表示法)作为确定和评价在过程改进上
所取得的进步的方法.CMMI 对量度特别重视,这有助于确定过程改进活动的投资回报.缺点
CMM/CMMI 的评估耗资不菲,一个 CMM2 级评估就可能达到数百万之巨,而且耗时很长,过程十分复
杂,常常导致效果不太理想.不少企业的认证流于形式,评估完成后就只留下一大堆文档,而真正的软件
开发过程却依然故我.而且,CMM/CMMI 只告诉我们应该怎么做,而没有具体地告诉如何做.
CMMI 1.一个模型:这不是开发模型,这是过程改进的参考模型,CMMI 可以应用在非软件领域.把最佳实
践分组排序的意义:刻画了从不成熟到成熟的路线;帮助一个企业定位,理解所处的位置;帮助企业指引
改进的方向.过程域:做好软件开发的某一个方面,即把最佳实践分组排序的结果.2.两种表现形式:阶段
式和连续式 能力程度:做得怎么样(连续式);成熟程度:做了还是没做(阶段式)3.三种不同的应用
领域/业务形式:(1)软件开发领域的 CMMI 模型:CMMI-DEV (CMMI for development)有 22 个过
程域(2)服务领域的 CMMI 模型:CMMI-SVC(3)为采购提供的 CMMI 模型:CMMI-
ACQ.*SAAS:Software-as-a-Service 软件发布部署 4.把最佳实践分成 4 个类别(1)项目(project)管
理类型(2)过程(process)管理类型(3)工程管理类 engineering (4)支持管理类型 support. 任
何一个过程域一定唯一的属于某一个类别.5.4 个级别 等级一定是阶段式,对应成熟度 本来有 5 级,但
因为第一级没有过程域 把 CMMI-DEV 的 22 个过程域分类:
所有 O 开头的都是过程类的
5 个等级 CMMI 阶段式表现形式的有 5 个成熟级别:1. initial 2.managed(CMM 是 repeated) 3.defined
4.managed(CMM 是 quantitatively managed) 5.optimizing 连续式表现形式单个过程域有 6 个能力
级别:0 级 incomplete(因为它不完整),1 级 performed(指某个特定的过程域里的工作你全都做了) 第二
级管理的三个要素:(1)非常明确清晰的目标定义(目标)(2)状态跟踪(状态)(3)纠正偏差的措施
(纠偏) 一级到二级:有管理总比没有好. OSSP:组织级标准软件过程 PDSP:企业级 二级到三级
(OSSP->PDSP)是为了共享,让开发经验的共享变成必然.第四级高级在哪里?(三级到四级 预测能
力加强,定性到定量) 根据偏差进行纠正背后反映了一个模型,就是根据当前状态进行预测的模型;这
个模型的依据是历史数据.让这个模型更可靠的方法:增加数据量;分类;消除异常数据.第五级 消除
影响过程的根本因素. 过程域的成熟(maturity)级别达到 1 级,那么能力(capability)级别必须达到 1
级;…2,...2;…3,…3;…4,…3;…5,…3;过程域:一组相关实践的集合,为了满足一个或多个目标
required:必须要实现的 expected:期望实现的 informative:补充的信息.GP(generic practices)gp2.1
建立一个指导原则(policy),在实施过程域的时候指导思想是什么 gp2.2 对过程域的工作做一个规
划,怎么做这个过程域 gp2.3 为了确保工作的完成投入足够的资源,人力、环境 gp2.4 有清晰的角色分
配和定义 gp2.5 为了让大家做这个过程域要进行一些培训 gp2.6 这个过程域有一些工作产品的产生,
如何保存 gp2.7 相关干系人怎么协作 gp2.8 按规划去检查,是否有偏差 gp2.9 客观的第三方的检查
gp2.10 高级管理者怎么参与的 gp3.1 建立一个组织级的规范 gp3.2 保存结果,收集过程改进的资料
二级过程域 1.PP(Project Planning).定义:建立和维护定义项目活动的计划.SG(specific goal):建
立估算;开发一个项目计划;获取计划的认可.软件项目估算,最重要的不是估得准不准,而是估算出来的
结果你的管理者、团队等是否接受这个数字;如果是大家都信任的估算,那就是好的估算.问题:为什么
pp 也有 gp2.2?计划的计划.为计划做一个计划,现实中有这个必要,因为项目计划涉及到多个工作人
员的参与,所以需要一个计划来计划它.2.PMC(Project Monitoring and Control)项目监督与控制.状
态跟踪加纠偏 SG:根据计划来监督项目;对纠正偏差的措施进行跟踪管理.里程碑评审 vs 进度评审:
两者看的东西很接近,都得看风险等;前者回答的是这个项目是不是需要继续下去、是否进入下一阶
段--客户跟高级经理一起参与;后者回答的是判断项目是不是按照计划在进展--范围小、频率高;团
队内部开展,不需要管理者、客户参与 问题:为什么 pmc 有 gp2.8?监控的监控.小组的周例会没有很
好的开展;pmc 的 gp2.8 在里程碑评审处做 3.CM(Configuration Management)配置管理.建立和维
护工作产品的完整性,使用配置识别、配置控制、配置状态报告、配置审计.SG:建立基线;跟踪和控
制变更;建立完整性.识别配置项是因为软件开发过程中产生的对象太多,所以要减少要管理的对象.配
置管理的关键在于变更请求、对所有的变更进行跟踪控制,而不在于版本控制.版本控制可以完全自动
化,配置管理不可能完全自动化.问题:CM 的 gp2.6?配置的配置 因为配置也有很多东西需要保存,比
如配置项的变更请求、基线的发布记录等 4.MA(Measurement and Analysis)度量和分析.SG:把度量
和管理目标联系起来;提供度量结果.GQM-goal question metric.问题:MA 度量和分析中的数据收集
和 PMC 中的数据采集分析的差别是什么?MA 的重点构建了一种获取信息的能力,PMC 是有了获取
数据能力之后根据这些数据来决定下一步动作.base measure(基本) VS derived measure(衍生) 缺陷
个数:base;严重缺陷个数:base;严重缺陷百分比:derived;缺陷密度:derived;人月:base 问题:在
满足信息需求的基础上,设计一个度量体系时 base 和 derived 哪个多一点?衍生度量多一点,因为收
集 base 工作量很大 5.PPQA(Process and Product Quality Assurance)过程和产品质量保证 问题:客
观的评价过程和客观的评价工作产品是期望型的(不是必需型的)哪一个是可以被替换的?客观的
评价过程更重要.因为过程的质量决定了最终产品的质量,对过程的评价是通过对产品的评价来进行
的,CMMI 的思想是全面管理质量.问题:PPQA 的 gp2.9?QA 的 QA QA 活动是有一套标准的,QA 检查
表,那么 QA 的执行是否按照定义的流程走是需要检查的,即 QA 的 QA
3. 三级过程域 1.RD(Requirements Development)需求开发.SG:开发客户需求:客户提问题;开发产
品需求:开发团队给答案.分析和确认需求.步骤:提问题、给答案、证明答案是对的 2.技术方案
TS(technical solution) 方案选型、设计、实现 3.PI 产品集成 持续集成和集成测试属于 PI,但是反过
来就不行,因为 PI 一直管到交付,类似单元测试、集成测试、性能测试都可以理解为 PI 的工作.做产品
集成的时候是有策略/顺序的.哪些因素影响顺序?:开发计划、完成模块的质量.sequence 和项目完全
相关,procedure 和 criteria 可能在大部分项目中差不多.问题:待集成的组件可以做集成的标准有哪
些?-必须是稳定版本(配置项的状态是关闭状态、组件来自于配置库而不是工作库)-必须有完整的
接口描述-必须有证据证明通过了单元测试 4.VAL(Validation)确认 目的:产品组件在即将使用它的环
境中是能够满足使用意图的.最终的产品有没有帮客户解决问题(客户需求)VAL 高于 VER
5.VER(Verification)验证 目的:确保被选择的工作产品满足需求.有没有正确的把解决方案给实现(产
品需求) 6.OPD 组织级过程定义 建立了一套标准的流程 7.IPM 集成项目管理(6、7 是一对)小组按
照标准流程指定小组的执行流程 OSSP-OPD PDSP-IPM 8.OPF 组织级过程焦点 对 IPM 执行结果进
行评价审查,识别强项弱项,进行改进 9.OPM 组织绩效管理(原来是 OID 组织级创新与部署)增强版
本的 OPF,是量化的去识别强项弱项(measurely improve XXX)10.OPP 组织过级程性能 需求 需
求评审 设计 设计评审 实现 测试 6 个阶段每个阶段都会注入/解决错误 问题 1:验收测试的时候有 5
个错误,现在重做项目,但是不做需求评审(当时需求评审消除了 10 个错误),最后验收的时候有几个
错误?答:可能大于、等于、小于 15 个 问题 2:非要估算最后的错误个数,需要哪些信息?答:每个阶
段注入的错误个数、每个阶段测试消除的错误个数 baseline:基于子过程的历史数据,计算标准差和均
值 model:需求注入-需求评审消除+设计注入-设计评审消除+实现注入-测试消除 11.QPM 定量项目管
理 OPP 给出管理目标 项目管理管的是子过程,确保每个子过程的能力基线能够实现.
SEMIntro:导论:
1、软件工程定义:1.将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护,即将工
程化应用于软件;2.在 1 中所述方法的研究.
3、软件工程知识域:软件需求、软件设计、软件构造、软件测试、软件维护、软件配置管理、软件工
程管理、软件工程过程、软件工程模型与方法、软件质量、软件工程职业实践、软件工程经济学、计
算基础、数学基础、工程基础
3、软件工程 VS 计算机科学:目标(SE:在资源的限制条件下构建满足用户需求的软件系统 CS:探索计
算和建模方法,改进计算方法)、关注(SE:如何为用户实现价值 CS:软件本身运行原理(时间空间复杂
度、算法正确性))、变化程度、需要的其他知识(SE:相关领域知识 CS:数学)4、软件工程 VS 计算机
程序设计:1.软件工程存在于各种应用中,存在于软件开发的各个方面.而程序设计通常包含了程序设
计和编码的反复迭代的过程,它是软件开发的一个阶段;2.软件工程力图对软件项目的各个方面做出指
导,从软件的可行性分析直到软件完成以后的维护工作.
Ch1 没有银弹
1、主要思想:没有任何一种单纯的技术或管理上的进展,能够独立地承诺十年内使生产率、可靠性或
简洁性获得数量级上的进步;所有大家看到的技术、管理方法都不会给软件开发带来意想不到的效果;
软件开发在根本上就是困难的(Brooks 认为根本困难是固有的概念复杂性)2、根本任务:打造由抽象
软件实体构成的复杂概念结构 3、次要任务:使用编程语言表达这些抽象实体,在空间和时间限制内将
它们映射成机器语言.除非次要任务占了所有工作的 9/10,否则即使全部次要任务的时间缩减到零,也
不会给生产率带来数量级上的提高.(硬件的发展使次要任务越来越容易解决)4、软件项目的现状:常
常看似简单明了的东西,却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物.(软件开发 Vs
硬件开发:不是软件发展慢,是硬件发展太快)6、探寻软件产业发展的问题:按照亚里士多德的观点,
将软件开发的问题分成根本的(essence)—软件特性中固有的困难,次要的(accident)—出现在目前
生产上的,但并非那些与生俱来的困难.一个相互牵制关联的概念结构,是软件实体必不可少的部分,
它包括:数据集合、数据条目之间的关系、算法、功能调用等等.这些要素本身是抽象的,体现在相同的
概念构架中,可以存在不同的表现形式.尽管如此,它仍然是内容丰富和高度精确的.7、软件系统中无
法规避的内在特性:复杂度、不一致性、可变性和不可见性.银弹与软件的内在特性相悖.Brooks 认为
软件开发中困难的部分是规格化、设计和测试这些概念上的结构,而不是对概念进行表达和对实现逼
真程度进行验证,那么软件开发总是非常困难的,天生就没有银弹.1.复杂度:a. 软件实体可能比任何
由人类创造的其他实体都要复杂 b.计算机复杂,状态多,构思、描述、测试困难 c.软件实体扩展是不
同元素实体的添加,复杂度非线性增长.d.软件的复杂度是必要属性,不是次要因素.e.导致了产品瑕
疵、成本超支和进度延迟;列举和理解所有可能的状态十分困难,影响了产品的可靠性;函数调用变得
困难,导致程序难以使用;程序难以在不产生副作用的情况下用新函数扩充;造成很多安全机制状态上
的不可见性 f.复杂度引发管理上的问题:全面理解问题变得困难,从而妨碍了概念上的完整性;所有离
散出口难以寻找和控制;引起了大量学习和理解上的负担,使开发慢慢演变成了一场灾难(对策:信息
隐藏策略)2.不一致性:软件开发面对的复杂度往往是随心所欲、毫无规则可言的,来自若干必须遵循
的人为惯例和系统.软件开发面对的是人,不是上帝;很多复杂性来自保持与其他接口的一致.3.可变
性:软件实体经常会遭受到持续的变更压力.软件很容易修改(它是纯粹思维活动的产物,可以无限扩
展);软件的变更来自于人们要求扩展、更改功能和硬件的变化,软件与整个社会联成一体,后者在不断
变动,它强迫软件也跟着变动.4.不可见性:软件是不可见的和无法可视化的;软件的客观存在不具有
空间的形体特征.限制了个人的设计过程,也严重的阻碍了相互之间的交流(UML).8、没有银弹主要观
点:相对必要任务而言,除非次要任务占了所有工作的 9/10,否则即使全部次要任务的时间缩减到零,
也不会给生产率带来数量级上的提高.
9、当年的银弹:Ada 和其他高级编程语言、面向对象编程(消除了开发过程中的非本质困难,允许设计
人员表达自己设计的内在特性,而不需要表达大量句法上的内容;对于抽象数据类型和层次化类型,它
们都是解决了高级别的次要困难和允许采用较高层次的表现形式来表达设计;使得修改局部化,提高
了可维护性)、人工智能(AI-1:使用计算机来解决以前只能通过人类智慧解决的问题.AI-2:使用启发
式和基于规则的特定编程技术.程序被设计成以人类解决问题的方式来运作)、专家系统(专家系统是
包含归纳推论引擎和规则基础的程序,它接收输入数据和假设条件,通过从基础规则推导逻辑结果,提
出结论和建议,向用户展示前因后果,并解释最终的结果.专家系统最强有力的贡献是给缺乏经验的开
发人员提供服务,用最优秀开发者的经验和知识积累为他们提供了指导.)、 “自动”编程(从问题的一
段陈述说明自动产生解决问题的程序.大多数情况下所给出的技术说明本质上是问题的解决方法,而
不是问题自身)、图形化编程(软件非常难以可视化)、程序验证(是否能够在系统设计级别、源代码
级别消除 bug 呢?是否可以在大量工作被投入到实现和测试之前,通过采用证实设计正确性的“深奥”
策略,彻底提高软件的生产率和产品的可靠性?不能保证节约劳动力;程序验证不意味着零缺陷的程
序;完美的程序验证只能建立满足技术说明的程序,而这时,软件工作中最困难的部分已经接近完成,
形成了完整和一致的说明)、环境和工具(这样的工作是非常有价值的,它能带来软件生产率和可靠性
上的一些提高.但是,由于它自身的特性,目前它的回报很有限)、购买和自行开发(构建软件最可能的
彻底解决方案是不开发任何软件;通用软件)、需求精炼和快速原型(概念性工作中,没有其他任何一
个部分比确定详细的技术需求更加困难;事实上,客户不知道自己需要什么;快速原型明确实际的概念
结构,让用户知道他们需要什么)、增量开发——增长而非搭建系统(Grow not building;客户;士
气;迭代式开发)、卓越的设计人员(软件开发是一个创造性的过程)
10、没有银弹的影响:软件开发本质的认识;软件过程
Ch2 大教堂和市集
《大教堂和市集》以大教堂模式和开放市集模式的比喻将自由软件和商业封闭软件区分开来——“一
种是封闭的、垂直的、集中式的开发模式,反映一种由权利关系所预先控制的极权制度;而另一种则是
并行的、点对点的、动态的开发模式.” 他在文中论证了自由软件不仅仅是一种乌托邦的理想,而是在
开发模式上真正代表着“先进生产力”,代表着历史发展趋势的必然.
1、Fetchmail: Linux 开发模式:1.每一个好的软件的起因都是挠到了开发者本人的痒处(“需要是发
明之母”长久以来就被证明是正确的)2.好程序员知道该写什么,伟大的程序员知道该重写(和重用)
什么(伟大程序员的一个重要特点是建设性的懒惰.他们知道你是因为成绩而不是努力得到奖赏,而且
从一个好的实际的解决方案开始总是要比从头干起容易;)3.计划好抛弃(你常常在第一次实现一个解
决方案之后才能理解问题所在,第二次你也许才足够清楚怎样做好它,因此如果你想做好,准备好推翻
重来一次)4. 如果你有正确的态度,有趣的问题会找上你(你在思考、审视一些你感兴趣的软件时,
你会有新的更好的想法) 5.当你对一个程序失去兴趣时,你最后的责任就是把它传给一个能干的后继
者(在开源软件的开发中)6.把用户当作协作开发者是快速改进代码和高效调试的有效方式 7. 早发
布、常发布、听取客户的建议(多数开发人过去都相信这对大型工程来说是个不好的策略,因为早期版
本都是些充满错误的版本,而你不想耗光用户的耐心;这种信仰强化了建造大教堂开发方式的必要性;
Linus 的创新并不是这个(这在 Unix 世界中是一个长期传统),而是把它扩展到和他所开发的东西的复
杂程度相匹配的地步,而且因为他培育了他的协作开发者基础,比其他任何人更努力地充分利用了
Internet 进行合作,所以这确实能行) 8. Linus 定律:如果有一个足够大的 beta 测试人员和协作开
发人员的基础,几乎所有的问题都可以被快速的找出并被一些人纠正(建造教堂和集市模式的核心区
别,在建造教堂模式的编程模式看来,错误和编程问题是狡猾的、阴险的、隐藏很深的现象,花费几个
月的仔细检查,也不能给你多⼤大确保把它们都挑出来的信心,因此很长的发布周期,和在长期等待之
后并没有得到完美的版本发布所引起的失望都是不可避免的;以市集模式观点来看,在另一方面,我们
认为错误是浅显的现象,或者至少当暴露给上千个热切的协作开发人员,让他们来对每个新发布进行
测试的时候,它们很快变得浅显了,所以我们经常发布来获得更多的更正,作为一个有益的副作用,如
果你偶尔做了一个笨拙的修改,也不会损失太多;Delphi 效应:一群相同专业(或相同无知的)观察者
的平均观点比在其中随机挑选一个来得更加可靠.两种版本:Linus 也做了一些改进,如果有一些严重
的错误,Linux 内核的版本在编号上做了些处理,让用户可以自己选择是运行上一个“稳定”的版本,还
是冒遇到错误的险而得到新特征,这个战略还没被大多数 Linux 黑客所仿效,但它应该被仿效,存在两
个选择的事实让二者都很吸引人)9.聪明的数据结构和笨拙的代码要比相反的搭配工作的更好 10. 如
果像对待最宝贵的资源一样对待 beta 测试员,他们就会成为你最宝贵的资源.11. 想出好主意是好事,
从你的用户那里发现好主意也是好事,有时候后者更好. 12 最有突破和有创新的解决方案常常来自
于你认识到你对问题的概念是错误的. 13.“最好的设计不是再没有什么东西可以添加,而是再也没有
什么东西可以去掉.”14.任何工具都应该达到预期的用处,但是一个伟大的工具提供你没料到的功能
15.当写任何种类的网关型程序时,多费点力,尽量少干扰数据流,永远不要抛弃信息,除非接收方强迫
这么作! 16. 如果你的语言一点也不像是图灵完备的,严格的语法会有好处 17. 一个安全系统只能和
它的秘密一样安全,当心伪安全 18.要解决一个有趣的问题,请从发现让你感兴趣的问题开始(最好的
开发是从作者解决每天工作中的个人问题开始的,因为它对一大类用户来说是一个典型问题,所以它
就推广开来了)19.如果开发协调人员有至少和 Internet 一样好的媒介,而且知道怎样不通过强迫来
领导,许多头脑将不可避免地比一个好(自由软件的将来将属于那些知道怎样玩 Linus 的游戏的人,把
大教堂抛之脑后拥抱市集的人,这并不是说个人的观点与才气不再重要,而是,自由软件的前沿将属于
从个人观点和才气出发的人,然后通过共同兴趣自愿社团的高效建造来扩展)(11-16 来自 fetchmail)
4、Brooks 定律——向一个进度落后的软件项目中增加开发人员只会让它更加落后,他声称项目的复杂
度和通讯开销以开发人员的平方增长,而工作成绩只是以线性增长,在众多软件项目中,缺乏合理的时
间进度是造成项目滞后的最主要原因,它比其他所有因素加起来的影响还要大.但如果 Brooks 定律就
是全部,那 Linux 就不可能成功 (交流与沟通).
5、“忘我(egoless)的编程”中,Weinberg 观察到在开发人员不顽固保守自己的代码,鼓励其他人寻找
错误的地方,软件改进的速度比其他地方有戏剧性的提高.虽然编码是一个人活,真正伟大的工作来自
利用整个社团的脑力,在一个封闭项目中只利用自己脑力的人会落在知道怎样创建一个开放的、进化
的,成百上千的人在其中查找错误和进行修改的环境的开发人员之后.
评论0