CMM(能力成熟度模型)

CMM 将软件过程改进分为 5 个成熟的级别:

  1. 初始级(Initial)

软件过程的特点是杂乱无章,有时甚至混乱,几乎没有明确定义的步骤,项目成功的完全依赖个人的努力和英雄式核心任务的作用。

  1. 可重复级(Repeatable)

建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性,有必要的过程准则来重复以前在同类项目中的成功。

  1. 已定义级(Defined)

管理和工程两方面的软件过程已经文档化、标准化,并综合成整个软件开发组织的标准软件过程。所有项目都采用根据实际情况修改后得到的标准软件过程来开发和维护软件。

  1. 已管理级(Managed)

制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制。

  1. 优化级(Optimized)

加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续改进。

CMMI(能力成熟度集成模型)

CMMI 提供了两种表示方法:阶段式模型连续式模型

  1. 阶段式模型

模型结构类似于 CMM,关注组织的成熟度,分为 5 个成熟度等级。

  • 初始的:过程不可预测且缺乏控制。
  • 已管理的:过程为项目服务。
  • 已定义的:过程为组织服务。
  • 定量管理的:过程已度量和控制。
  • 优化的:集中于过程改进。
  1. 连续式模型

关注每个过程域的能力,一个组织对不同的过程域可以达到不同的过程域能力等级(CL)。CMMI 中包含 6 个过程域能力等级,等级号为 0 ~ 5。能力等级包括共性模板及相关的共性实践,这些实践在过程域内被添加到特定模板和实践中。当组织满足过程域的特定模板和共性目标时,就说该组织达到了那个过程域的能力等级。

能力等级可以独立应用于任何单独的过程域,任何一个能力等级都必须满足比它等级低的能力等级的所有准则,各能力等级的含义如下:

  • CL0(未完成的):过程域未执行或未得到 CL1 中定义的所有目标。
  • CL1(已执行的):其共性目标是过程将可标识的输入工作产品转换为可标识的输出工作产品,已实现支持过程域的特定目标。
  • CL2(已管理的):其共性目标集中于已管理的过程的制度化。根据组织级政策规定过程的运作将使用哪个过程,项目遵循已文档化的计划和过程描述,所有正在工作的人都有权使用足够的资源,所有工作任务和工作产品都被监控、控制和评审。
  • CL3(已定义级的):共性目标集中于已定义的过程的制度化。过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的,还必须收集过程资产和过程的度量,并用于将来对过程的改进。
  • CL4(定量控制的):共性模板集中于可定量管理的过程的制度化。使用测量和质量保证控制和改进过程域,建立和使用关于质量和过程执行的定量目标作为管理准则。
  • CL5(优化的):使用量化(统计学)收单改变和优化过程域,以满足客户要求的改变和持续改进计划中的过程域的功效。

总结的内容如下:

  • 能力等级 0CL0)指未执行过程,表明过程域的一个或多个符足目仍没有被满足。
  • 能力等级 1CL1)指过程通过转化可识别的输入工作产品,产生可识别的输出工作产品,关注于过程域的特定目标的完成。
  • 能力等级 2CL2)指过程作为已管理的过程制度化,关注于针对单个过程实例的能力。
  • 能力等级 3CL3)指过程作为已定义的过程制度化,关注过程的组织级标准化和部署。
  • 能力等级 4CL4) 指过程作为定量管理的过程制度化。
  • 能力等级 5CL5) 指过程作为优化的过程制度化,表明过程得到很好地执行且持续得到改进。

瀑布模型

瀑布模型的优点:易理解、管理成本低、强调开发的阶段性早期计划及需求调查和产品测试。

瀑布模型的不足:客户必须能完整、正确、清晰表达他们的需求,在开始的两到三个阶段中,很难评估真正的进度状态。当接近项目结束时,出现大量的集成和测试工作。直到项目结束前,都不能演示系统的能力。在瀑布模型中,需求设计中的错误往往只有到了项目后期才能被发现,对于项目风险的控制能力较弱。从而导致项目常常延期,开发费用超出预算。

瀑布模型

V 模型是瀑布模型的一个变体,描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系。随软件团队工作沿着 V 模型左侧步骤向下推进,基本问题需求逐步细化,形成问题及解决方案的技术描述。一旦编码结束,团队沿着 V 模型右侧的步骤向上推进工作,其实际上是执行了乙烯利测试(质量保证活动)。

V 模型

总结而言:瀑布模式适合开发需求明确,需求大致固定不会随意变更的系统。V 模式的关键在于质量保证活动和沟通,基本问题逐步细化。

增量模型

融合了瀑布模型的基本成分和原型实现的迭代特征,它假设可以将需求分段位一系列增量产品,每一增量可以分别开发。模型采用随着日程时间的进展而交错的线性序列,每个线性序列产生软件的一个可发布的“增量”。使用怎两模型时,第 1 个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特性和功能,这个过程在每个增量发布后不断重复,直到产生最终的完善产品。增量模型强调每个增量均发布一个可操作的产品。

增量模型

增量模型作为瀑布模型的一个变体,具有瀑布模型的所有优点。此外还有以下优点

  1. 第一个可交付版本所需的成本和时间较少。
  2. 开发由增量表示的小系统所承担的风险不大。
  3. 由于很快就发不了第一个版本,因此可以减少用户需求的变更。
  4. 运行增量投资,即在项目开始前,可以仅对一个或两个增量投资。

缺点

  1. 如果 未对用户的变更要求进行规划,则产生的初始增量可能会造成后来增量的不稳定。
  2. 如果需求不像早期思考的那样稳定和完整,那么一些增量就可能需要重新开发,发布。
  3. 管理发生的成本、进度和配置的复杂度可能会超出组织的能力。

总结:增量模型拥有瀑布模型的所有优点,同时还可以快速构造可运行的产品

原型模型

原型模型

由于并非所有的需求都能预先定义,所以在开发初期很难得到一个完整的、准确的需求规格说明,这主要是因为客户无法准确表达对未来系统的全面要求,开发者对要解决的应用问题模糊不清,以至于形成的需求规格说明常是不完整、不准确的,有时甚至是有歧义的。此外,在整个开发过程中,用户可能会产生新的需求,导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化,,于是出现了快速原型(Rapid Prototype)这种新的开发方法。

原型方法比较适合于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时,采用该方法较好。

总结:原型模型不适合大规模的系统开发。

螺旋模型

喷泉模型

喷泉模型

一种以用户需求为动力,以对象为驱动的模型,适合于面向对象的开发方法。克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。

迭代意味着模型中的开发活动常需要重复多次,在迭代过程中不断完善软件系统。无间隙是指在开发活动(分析、设计、编码)之间不存在明显的边界,也就是说,不像瀑布模型那样,在需求分析活动结束后才开始设计活动,在设计活动结束后才开始编码活动,而是允许各开发活动交叉、迭代地进行。

喷泉模型的各阶段无明显界限,开发人员可以同步进行。优点是可以提高软件项目的开发效率,节省开发时间。由于喷泉模型在各个开发阶段是重叠的,在开发过程中需要大量的开发人员,不利于项目的管理。此外,这种模型要求严格管理文档,使得审核的难度加大。