软件工程概述、软件过程模型、软件开发方法、软件工具与软件开发环境、软件项目管理、软件风险管理、软件度量

CMM，Capability Maturity Model，能力成熟度模型

CMMI，Capability Maturity Model Integration，能力成熟度模型集成

大纲

软件工程概述

• 软件工程基本原理：用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制、采用现代程序设计技术、结果应能清楚的审查、开发小组的人员应少而精、承认不断改进软件工程实践的必要性。

• 软件工程的基本要素：方法、工具、过程。

• 软件生存周期：可行性分析与项目开发计划、需求分析、概要设计（选择系统解决方案，规划子系统）、详细设计（设计子系统内部具体实现）、编码、测试、维护。

软件过程

能力成熟度模型CMM

• 能力成熟度模型CMM：CMM是对软件组织成熟度阶段的描述，它随着软件组织定义、实施、测量、控制和改进其软件过程，逐步提高软件组织的能力。

• CMM五级

  CMM级别	描述
  初始级（Initial）	软件过程杂乱无章，缺乏明确定义的步骤，项目成功依赖个人努力和核心人物的英雄作用。
  可重复级（Repeatable）	建立了基本的项目管理过程，可跟踪项目费用、进度和功能特性。需要的过程准则以重复先前成功的经验。
  已定义级（Defined）	软件过程和产品质量文档化、标准化，并综合为整个软件开发组织的标准软件过程。所有项目采用标准过程。
  已管理级（Managed）	制定了软件过程和产品质量的详细度量标准。软件过程的产品质量由组织成员管理。
  优化级（Optimized）	强化定量分析，通过过程质量反馈和新观念、新技术的反馈，持续改进过程。旨在实现持续的过程改进和优化。

能力成熟度模型CMMI

• 能力成熟度模型CMMI：CMMI将已有的几个CMM模型结合在一起，构建了一个集成模型，该模型支持多个工程学科和领域，提供系统化、一致的过程改进框架，以满足现代工程的需求和特点，从而提高过程质量和工作效率。

• CMMI两种表示方法

  1. 阶段式模型：类似于CMM，关注组织的成熟度，包括以下五个成熟度模型：

     CMMI 成熟度级别	描述
     初始的	过程不可预测且缺乏控制。
     已管理的	过程为项目服务。
     已定义的	过程为组织服务。
     定量管理的	过程已度量和控制。
     优化的	集中于过程改进。

  2. 连续式模型：关注每个过程域的能力，一个组织可以在不同的过程域达到不同的过程域能力等级。

统一过程UP

• 统一过程模型：是一种开发过程，特性如下：

  • 三大特点：用例和风险驱动、以架构为中心、送代并增量。
  • 四个阶段：开发的四个阶段包括：起始（项目的初始活动，如确认需求和风险评估等）、精化（需求分析和架构设计等）、构建（系统的构建，产生实现模型等）、移交（软件提交方面的工作，产生软件增量，进行β测试，交付系统等）。
  • 五个工作流：UP的每一次选代都是一次完整的软件开发过程，包括整个软件开发生命周期，有五个核心工作流（需求、分析、设计、实现、测试）。

例题

软件过程模型

基本概念

• 软件过程模型：即软件开发模型，是软件开发全部过程、活动和任务的结构框架。

常见模型

• 瀑布模型（SDLC)：结构化方法中的模型是结构化的开发，开发流程如同瀑布一般，一步一步的走下去，直到最后完成项目开发，只适用于需求明确或者二次开发（需求稳定），当需求不明确时，最终开发的项目会错误，有很大的缺陷。

  

• V模型：是瀑布模型的一个变体。特点是增加了很多轮测试，并且这些测试贯穿于软件开发的各个阶段，不像其他模型都是软件开发完再测试，很大程度上保证了项目的准确性。V模型开发和测试级别对应如图：

  

• 演化模型：

  • 演化模型原型：即快速原型开发，与瀑布模型相反，原型针对的就是需求不明确的情况，首先快速构造一个功能模型，演示给用户看，并按用户要求及时修改，中间再通过不断的演示与用户沟通，最终设计出项目，就不会出现与用户要求不符合的情况，采用的是选代的思想。

    

  • 螺旋模型：是多种模型的混合，针对需求不明确的项目，与原型类似，但是增加了风险分析，这也是其最大的特点。四步：制定计划-风险分析-实施工程-用户评估。

    

• 增量模型：首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。

  • 特点：但由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品，而原型的构造一般是为了演示。
  

其他模型

• 喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。

• 基于构件的开发模型CBSD：利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。

  • 特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。
  • 构件是可复用的软件模块

• 形式化方法模型：建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。

例题

软件开发方法

结构化方法

• 结构化方法：流程固定，针对需求明确的项目，自顶向下，逐层分解，面向数据流将数据流映射为软件系统的模块结构，数据流类型包括变换流型和事务流型，不同类型的数据流有不同的映射方法。以瀑布模型为代表，一旦开发完成，将难以修改，不利于复用及后续版本的开发，现在被面向对象法给代替了。

• 结构化方法的设计：体系结构设计是宏观架构设计：数据设计是数据流的设计；接口设计关注模块间的连接设计：过程设计是模块内的具体实现过程的数据结构和算法的设计。

• Jackson方法：面向数据结构的开发方法，适合于小规模的项目。

• 原型方法：适合于需求不明确的开发，以原型模型为代表。

• 面向对象方法：强调复用性，构建全面合理的模型，供不同项目使用，方便修改节省开发时间和效率，增强复用性，以构件组装模型为代表

敏捷开发

• 针对中小型项目，主要是为了给程序员减负，去掉一些不必要的会议和文档。指的是一组模型（极限编程、自适应升级、水晶方法…），这些模型都拥有相同的原则和价值观，具体如下图（要求对该图熟悉，并掌握重要概念）：

  

  • 开发宣言：个体和交互胜过过程和工具、可工作的软件胜过面面俱到的文档、客户合作胜过合同谈判、响应变化胜过遵循计划。

  • 结对编程：一个程序员开发，另一个程序员在一旁审查代码，能够有效地提高代码质量，在开发同时对代码进行初步审查，共同对代码负责。

  • 自适应开发：强调开发方法的适应性（Adaptive）。不像其他方法那样有很多具体的实践做法，它更侧重为软件的重要性提供最根本的基础，并从更高的组织和管理层面来阐述开发方法为什么需要具备适应性。

  • 水晶方法：每一个不同的项目都需要一套不同的策略、约定和方法论。

  • 特性驱动开发：是一套针对中小型软件开发项目的开发模式。是一个模型驱动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

  • 极限编程XP：核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，为了将以后出现 bug 的几率降到最低。

  • 并列争球法SCRUM：是一种迭代的增量化过程，把每段时间（30天）一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。

例题

软件工具与开发环境

软件工具

• 软件开发工具：对于于软件开发过程的各种活动。包括需求分析工具、设计工具、编码与排错工具、测试工具。

• 软件维护工具：辅助软件维护过程中活动的软件，辅助维护人员对软件代码及其文档进行各种维护活动。包括版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。

• 软件管理和软件支持工具：辅助管理人员和软件支持人员的管理活动和支持活动以确保软件高质量的完成。包括项自管理工具、配置管理工具、软件评价工具。

开发环境

• 软件开发环境：指支持软件产品开发的软件系统，由软件工具集和环境集成机制构成。工具集用于支持软件开发的相关过程、活动和任务：环境集成机制为工具集成和软件开发、维护和管理提供统一的支持。

• 开发支持环境（环境信息库，过程控制和消息服务，用户界面规范）

软件项目管理

软件评估

• 有效的项自管理集中在4P上：人员、产品、过程、项目。

• 软件项目估算方法：成本估算方法

  • 自顶尚下估算：文称类比估算法，确定一个总金额，再向下分摊到每一个功能点。
  • 自底向上估算：从底层功能点开始估算成本，向上累加。
  • 差别估算法：与以前项目比较，找出不同点重新估算，相同点则直接估算。
  • 专家估算：聘请专家以其经验对项目整体费用进行估算。

• COCOMO模型：常见的软件规模估算方法。常用的代码行分析方法作为其中一种度量估计单位，以代码行数估算出每个程序员工作量，累加得软件成本。

  • 模型按其详细程度可以分为三级：基本COCOMO模型，中间COCOMO模型，详细COCOMO模型。其中基本COCOMO模型是是一个静态单变量模型，它用一个以已估算出来的原代码行数（LOC)为自变量的经验函数计算软件开发工作量。中级COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。

• COCOMOⅡ模型：COCOMO的升级，也是以软件规模作为成本的主要因素，考虑多个成本驱动因子。该方法包括三个阶段性模型，即应用组装模型（软件工程前期阶段使用）、早期设计阶段模型（需求已经稳定并且基本的软件体系结构已经建立时使用）和体系结构阶段模型（软件的构造过程中使用）。

• Putnam估算模型：一种动态多变量模型，假设在软件开发的整个生存周期中工作量有特定的分布。

进度管理

• 基本原则：划分、相互依赖、时间分配、工作量确认、确定责任、明确输出结果、确定里程碑。

• Gantt图：又称为横道图，横轴表示时间，纵轴表示活动，以时间顺序表示活动能反应活动间的并行关系，但无法反应活动之间的依赖关系，因此也难以清晰的确定关键任务和关键路径。

  

• PERT图：类似于前趋图，是有向图，反应活动之间的依赖关系，有向边上标注活动运行的时间，但无法反应活动之间的并行关系。

  

图的关键路径

• PERT图：是一个有向图，图中箭头表示任务，它可以标上完成该任务的时间，图中的节点表示流入节点的任务的结束，并开始流出结点任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现。

  • 特点：不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系。
  

• 关键路径重要概念：

  • 最早开始时间ES：取所有前驱活动最早完成时间EF的最大值。
  • 最早完成时间EF：最早开始时间ES+活动本身时间DU。
  • 关键路径（项目总工期）：项目中耗时最长的一条线路。
  • 最晚完成LF：取后续活动最晚开始时间的最小值。
  • 最晚开始时间LS：最晚完成LF-活动本身时间DU。
  • 松弛时间：某活动的最晚开始时间-最早开始时间（或最晚完成时间-最早完成时间），也即该活动最多可以晚开始多少天。

• 例题

  

  • 方式1：列表法

    

  • 方式2：

    • 题目求的是松弛时间，我们可以用关键路径-包含FG的最长段的路径
    • 我们可以看出START-D-F-H-FINISH是最长的，即关键路径
    • 现在找包含FG的最长段，可以发现START-D-F-G-FINISH是包含FG的最长段，其长度为20
    • 我们用关键路径减去此段，为48-28=20

软件项目的组织

• 组织结构模式：项目型（项自经理绝对领导）、职能型（部门领导为主）、矩阵型（二者结合，既有项目经理也有部门领导，但权利分割不同）。

• 程序设计小组的组织方式：

  • 主程序员制小组：主程序员全权负责，后援工程帅必要时能替代主程序员，适合大规模项目
  • 民主制小组：也即无主程序员小组，成员之间地位平等，任何决策都是全员参与投票，适合于项目规模小，开发人员少，采用新技术和确定性较小的项目
  • 层次式小组：两个层次，一名组长领导若干个高级程序员，每个高级程序员领导若干个程序员

软件质量管理

ISO/IEC9126软件质量模型

• ISO/IEC9126软件质量模型：质量特性和子特性

  

  • 功能性（Functionality）：与一组功能及其指定的性质的存在有关的一组属性，功能是指满足规定或隐含需求的那些功能。

    特性	说明	Translation
    适应性	软件能够提供一组功能并适合完成指定任务。	Suitability
    准确性	软件能够提供正确或相符的结果或效果。	Accuracy
    互操作性	软件能够与其他指定系统进行交互操作。	Interoperability
    依从性	软件能够符合相关标准、约定、法规和类似规定。	Compliance
    安全性	软件能够防止未经授权的故意或意外访问程序和数据。	Security

  • 可靠性（Reliability）：与在规定的一段时间内和规定的条件下软件维持在其性能水平有关的能力。

    特性	说明	Translation
    成熟性	软件故障引发失效的频率。	Maturity
    容错性	软件能够在出现错误或违反指定接口的情况下维持性能水平。	Fault Tolerance
    易恢复性	软件能够在故障发生后重新建立性能水平和恢复受影响数据，以及为达到此目的所需的时间和努力。	Recoverabilit

  • 易用性（Usability）：与为使用所需的努力和由一组规定或隐含的用户对这样使用所做的个别评价有关的一组属性。

    特性	说明	Translation
    易理解性	用户理解逻辑概念及其应用所需的努力。	Understandability
    易学性	用户学习应用（如操作控制、输入和输出）所需的努力。	Learnability
    易操作性	用户进行操作和操作控制所需的努力。	Operability

  • 效率（Efficiency）：在规定条件下，与软件的性能水平与所用资源量之间的关系有关的软件属性。

    特性	说明	Translation
    时间特性	与响应时间、处理时间以及软件执行功能时的吞吐量有关。	Time Behavior
    资源特性	与软件执行功能时所使用的资源量以及使用资源的持续时间有关。	Resource Behavior

  • 可维护性（Maintainability）：与进行规定的修改所需要的努力有关的一组属性。

    特性	说明	Translation
    易分析性	诊断缺陷或失效原因、判断待修改的部分所需的努力。	Analyzability
    易改变性	进行修改、排错或适应环境变化所需的努力。	Changeability
    稳定性	修改可能导致未预期效果的风险。	Stability
    易测试性	确认经修改的软件是否正确所需的努力。	Testability

  • 可移植性（portability）：与软件可从某一环境转移到另一环境的能力有关的一组属性。

    特性	说明	Translation
    适应性	软件转移到不同环境时的处理或手段。	Adaptability
    易安装性	在指定环境下安装软件所需努力。	Installability
    一致性	软件服从与可移植性相关的标准或约定。	Conformance
    易替换性	软件用于替代指定的其他软件的可能性和努力。	Replaceability

McCall质量模型

• 三个方面，11个质量特性

• 给出了三层框架模型：质量特性、评价标准、度量指标

  

  • 3个要点：

    • 软件必须满足用户需求，与用户需求不一致的软件无质量可言；
    • 软件应遵循规定的一系列开发标准，不遵循这些准则的软件，其质量难以得到保证；
    • 软件还应满足某些隐含的需求（如可理解性、可维护性，未明确写在用户需求中）。

  • 7个任务：应用技术方法（把软件质量设计到产品中而非事后保证）、正式的技术评审、测试软件、标准的实施（遵循标准）、控制变更、度量（收集软件度量）、记录保存和报告。

软件容错管理

• 通常将质量理解为用户满意程度，为了使用户满意，有两个必要条件：设计的规格说明书符合用户标准，称为设计质量。程序按照设计规格说明书所规定的情况正确执行，称为程序质量。

• 设计质量评审、程序质量评审。

• 软件容错技术：

  • 容错就是软件遇到错误的处理能力，实现容错的手段主要有几种，包括下面四种冗余技术：
    • 结构冗余：分为静态（通过表决和比较，少数服从多数）、动态（多重模块待机备份，故障时切换备份机）、混合冗余（二者综合）三种。
    • 信息冗余：为了检错和纠错在数据中加上一段额外的信息，例如校验码原理。
    • 时间冗余：遇到错误时重复执行，例如回滚，重复执行还有错，则转入错误处理逻辑。
    • 冗余附加技术：冗余附加技术是指为实现结构、信息和时间冗余技术所需的资源和技术，包括程序、指令、数据：存放和调动它们的空间和通道等。

软件配置管理

• 基线：在软件开发过程中，基线是特定的关键点，通常对应于项目生命周期中的各个阶段结束时的重要节点，也被称为里程碑。这些基线反映了每个阶段的成果和状态。

• 软件配置项：软件工程中的信息项，它们是配置管理的基本单位。

  配置项可以包括各种类型的文档、代码、工具等，主要分为以下六种类型：环境类（与系统开发环境相关的配置项）、定义类（需求分析与系统定义阶段的配置项）、设计类（设计阶段的配置项）、编码类（编码及单元测试阶段的配置项）、测试类（系统测试完成后的配置项）、维护类（维护阶段的配置项）。这些配置项包括了产品组成部分的工作成果，以及项目管理和机构支撑过程域产生的文档等。

• 版本控制：也称为软件配置项的版本控制，是确保配置项状态可控的关键过程。配置项可以处于三个状态：草稿、正式和修改。如下：

  

• 版本命名规则：

  

• 变更控制：软件开发过程中的每一次修改都要纳入变更，以防止版本混乱，需要用到基线和配置数据库的概念。配置数据库分为下面三种：

  

软件风险管理

软件风险的基本概念

• 软件风险有两个主要特性：不确定性（可能发生也可能不发生）和损失（如果发生，可能导致严重后果）。

• 项目风险对项目计划构成威胁。如果项目风险发生，可能会延迟项目进度并增加项目成本。这些风险涉及多个方面，包括预算、进度、人员、资源、利益相关者、需求等，以及它们对软件项目的潜在影响。项目的复杂性、规模和结构的不确定性也属于项目风险因素。

• 技术风险威胁着软件质量和交付时间。如果技术风险发生，开发工作可能会变得非常困难甚至不可能完成。这些风险涉及设计、实现、接口、验证和维护等多个方面的潜在问题。此外，规格说明的歧义、技术的不确定性、技术陈旧以及使用尚未成熟的“前沿”技术也是技术风险因素。

• 商业风险威胁到要开发软件的生存能力，包括下面五种：

  

风险管理

• 风险管理过程如下：

  • 风险识别：识别出项自中已知和可测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项自可以产生风险，形成一个风险列表。
  • 风险预测：文称为风险估计，从两个方面预测风险，即风险可能发生的概率和风险发生产生的后果，因此有风险曝光度=风险发生的可能性*风险发生会带来的损失。
  • 风险评估：定义风险参照水准，将识别出来的风险评估分类。
  • 风险控制：辅助项目组建立处理风险的策略，包括风险避免、风险监控、RMMM计划（风险缓解、监控和管理计划）。

软件度量

• 软件的两种属性：外部属性指面向管理者和用户的属性，可直接测量，一般为性能指标。内部属性指软件产品本身的的属性）如可靠性等，只能间接测量。

• McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m-n+2

• 注意m和n代表的含义不能混滑，可以用一个最简单的环路来做特殊值记忆此公式。另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点。

• 注意，只有入度没有出度的线不算！！！