软件工程期末重点

第一章、软件工程学概述

软件危机

软件危机: 是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件危机包含下述两个方面的问题:

  1. 如何开发软件,以满足对软件日益增长的需求。
  2. 如何维护数量不断膨胀的已有软件。

软件工程学

软件工程 :指导计算机软件开发和维护的一门工程学科。
软件工程: 包括技术和管理两方面的内容,是技术与管理紧密结合所形成的工程学科。
软件工程学的一个重要的目标: 就是提高软件的可维护性,减少软件维护的代价。

通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学 ,也称为泛型 。
软件工程方法学(包括传统方法学、面向对象方法学)包含三个要素: 方法、工具和过程。

软件生命周期: 软件生命周期由软件定义、软件开发和运行维护三个时期组成。
软件定义: 问题定义、可行性研究和需求分析。
软件开发 :总体设计,详细设计,编码和单元测试,综合测试。

软件的组成: 程序、数据和文档。

  1. 程序: 是能够完成预定功能和性能的可执行的指令序列。
  2. 数据: 是使程序能够适当地处理信息的数据结构。
  3. 文档 :是开发、使用和维护程序所需要的图文资料。

生命周期模型包括 :瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型

  1. 瀑布模型:
    瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。
    缺点:
    1)各个阶段的划分完全固定,阶段之间产生大量的文档,极大地增加了工作量。
    2)由于开发模型是线性的,用户只有等到整个过程的末期才能见到开发成果,从而增加了开发风险。
    3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
    4)瀑布模型的突出缺点是不适应用户需求的变化。

  2. 快速原型: 是快速建立起来的、可以在计算机上运行程序,它所能完成的功能往往是最终产品能完成功能的一个子集。
    优点:有助于所开发出的软件产品满足用户的真实需求。

  3. 增量模型: 它分批地逐步向用户提交产品,整个软件产品被分解成许多个增量构件,开发人员一个构件一个构件地向用户提交产品。

  4. 螺旋模型: 基本思想是使用原型及其他方法来尽量降低风险。理解这种模型的一个简单方法,是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。(使用于内部开发的大规模软件项目)

  5. 喷泉模型: 是典型的面向对象的软件过程模型之一。充分体现了面对对象软件开发过程迭代和平滑过渡的特征。

第二章 、可行性研究

可行性研究的目的: 是用最小的代价在尽可能短的时间内研究并确定客户提出的问题是否有行得通的解决办法。
可行性研究的目的不是解决问题,而是确定问题是否值得去解决。

对每种解法都应该仔细研究它的可行性,一般说来,至少应该 从下述 3 个方面研究每种解法的可行性:
1)技术可行性 2)经济可行性 3)操作可行性

第三章、需求分析

需求分析的任务是: 准确地回答“系统必须做什么”这个问题。

通常对软件系统有以下几方面的综合要求:

  1. 功能需求
  2. 性能需求
  3. 可靠性和可用性需求
  4. 出错处理需求
  5. 接口需求
  6. 约束
  7. 逆向需求
  8. 将来可能提出的要求

可以概括为功能需求和非功能需求。

结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

快速建立软件原型是最准确、最有效、最强大的需求分析技术。
快速原型 就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。
快速原型应该具备的特性: 1.快速 2.容易修改

需求分析过程应该建立三种模型: 数据模型(实体 -联系图)、功能模型(数据流图)和行为模型(状态转换图)。
实体联系图,描绘数据对象及数据对象之间的关系,是用于建立数据模型的图形。
数据流图是建立功能模型的基础。
状态转换图描绘了系统的各种行为模式和在不同状态间转换的方式。

软件需求规格说明是需求分析阶段得出的最主要的文档。

第五章、总体设计

总体设计过程通常由两个主要阶段组成:

  1. 方案设计,确定系统的具体实现方案;
  2. 体系结构设计,确定软件系统中每个程序是由哪些模块组成的,以及这些模块之间的相互关系。

【什么是模块化br> 就是把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,把这些模块集成起来够成一个整体,可以完成指定的功能满足用户的需求。
【模块独立】
开发具有独立功能而且和其他模块之间没有过多的相互作用的模块,就可以做到模块独立。
模块的独立程度可以由两个定性标准度量,这两个标准分别称为内聚和耦合。耦合衡量不同模块彼此间相互依赖(连接)的紧密程度;内聚衡量一个模块内部各个元素彼此结合的紧密程度。
【耦合】
耦合是对一个软件结构内不同模块之间互连程度的度量。耦合的强弱取决于模块间接口的复杂程度,进入或访问一个模块的点,以及通过接口的数据。
模块间典型的耦合关系:

  1. 非直接耦合
  2. 数据耦合
    如果两个模块彼此间通过参数交换信息,而且交换的信息仅仅是数据,那么这种耦合称为数据耦合。
  3. 控制耦合
    如果传递的信息中有控制信息,则这种耦合称为控制耦合。
    数据耦合是低耦合。 控制耦合是中等程度的耦合,它增加了系统的复杂程度。
  4. 特征耦合
    当把整个数据结构作为参数传递而被调用的模块只需要使用其中一部分数据元素时,就出现了特征耦合。
  5. 外部耦合
  6. 公共环境耦合
    当两个或多个模块通过一个公共数据环境相互作用时,它们之间的耦合称为公共环境耦合。
    公共环境可以是全程变量、共享的通信区、内存的公共覆盖区、任何存储介质上的文件、物理设备等。
    公共环境耦合的复杂程度随耦合的模块个数而变化,当耦合的模块个数增加时复杂程度显著增加。
  7. 内容耦合。耦合程度最高的耦合关系。
    (1)一个模块访问另一个模块的内部数据
    (2)一个模块不通过正常入口而转到另一个模块的内部。
    (3)两个模块有一部分代码重叠。
    (4)一个模块有多个入口。

在软件设计中应该追求尽可能松散耦合的系统。模块间耦合松散,有助于提高系统的可理解性、可测试性、可靠性和可维护性。
设计原则:尽量使用数据耦合,少用控制耦合和特征耦合,限制公共环境耦合的范围,完全不用内容耦合。
【内聚】
内聚: 标志着一个模块内各个元素彼此结合的紧密程度,它是信息隐藏和局部化概念的自然扩展。
低内聚有如下三类:

  1. 偶然内聚: 如果一个模块完成一组任务,这些任务彼此间即使有关系,关系也是很松散的,就叫做偶然内聚。
  2. 逻辑内聚: 如果一个模块完成的任务在逻辑上属于相同或相似的一类,则称为逻辑内聚。
  3. 时间内聚: 如果一个模块包含的任务必须在同一段时间内执行,就叫时间内聚。

中内聚主要有以下两类:

  1. 过程内聚: 如果一个模块内的处理元素时相关的,而且必须以特定次序执行,则称为过程内聚。
  2. 通信内聚: 如果模块中所有元素都使用同一个输入数据和产生同一个输出数据,则称为通信内聚。

高内聚也有两类:

  1. 顺序内聚 :如果一个模块内的处理元素和同一个功能密切相关,而且这些处理必须顺序执行,则称为顺序内聚。
  2. 功能内聚: 如果模块内所有处理元素属于一个整体,完成一个单一的功能,则称为功能内聚。功能内聚是最高程度的内聚。

设计软件时应力求做到高内聚(功能类聚和顺序内聚),内聚和耦合是密切相关的,模块内的高内聚往往意味着模块间的松耦合。

描绘软件结构的图形工具:

  1. 层次图
  2. 结构图

面向数据流的设计方法的目标: 是给出设计软件结构的一个系统化的途径。
信息流有下述两种类型 :变换流和事务流。

第六章、详细设计

详细设计的根本目标: 是确定应该怎样具体地实现所要求的系统,也就是说,经过这个阶段的设计工作,应该得出对目标系统的精确描述,从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。

详细设计阶段的任务还不是具体地编写程序,而是要设计出程序的“蓝图”,以后程序员将根据这个“蓝图”写出实际的程序代码。

程序的三种基本控制结构: 顺序、选择和循环。

结构程序设计的经典定义如下所述: “如果一个程序的代码块仅仅通过顺序、选择和循环这三种基本控制结构进行连接,并且每个代码块只有一个入口和一个出口,则称这个程序是结构化的。”

面向数据结构的设计方法的最终目标是: 得出对程序处理过程的描述。
最著名的两个面向数据结构的设计方法: Jockson 和 Warnier 方法。
Jockson方法的逻辑关系包括: 顺序、选择和重复。

程序复杂度的定量度量: McCabe 方法和 Halstead 方法
McCabe 方法: 根据程序控制流的复杂程度定量度量程序的复杂程度,这样度量出的结果称为程序的环形复杂度。
Halstead 方法: 是一个著名的方法,它根据程序中运算符和操作数的总数来度量程序的复杂程度。

第七章、实现

通常把编码和测试统称为实现。

7.1 编码

源程序代码的逻辑简明清晰,易读易懂是好程序的一个重要标准。

7.2 软件测试与调试

测试阶段的根本目的是尽可能多地发现并排除软件中潜藏的错误,最终把一个高质量的软件系统交给用户。

7.2.1 测试

【测试的定义】
测试为了发现程序中的错误而执行程序的过程。
【测试的目标】
测试的目标是发现软件中迄今为止尚未发现的错误。

7.2.2 调试

【调试的定义】
调试是在测试发现错误之后排除错误的过程。

7.3 黑盒测试与白盒测试

【黑盒测试】
黑盒测试(又称功能测试)把程序看作一个黑盒子,完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试,只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能接收输入数据并输出正确的信息,程序运行过程中能否保持外部信息(例如数据库或文件)的完整性。黑盒测试又称为功能测试。
【白盒测试】
白盒测试(又称结构测试)是把程序看成装在一个透明的白盒子里,测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定要求正确工作。白盒测试又称为结构测试。
【设计黑盒测试方案的三种技术】

  1. 等价划分
  2. 边界值分析
  3. 错误推断
    【设计白盒测试方案两种技术】
  4. 逻辑覆盖
    (1)语句覆盖
    (2)判定覆盖
    (3)条件覆盖
    (4)判定/条件覆盖
    (5)条件组合覆盖
    (6)点覆盖
    (7)边覆盖和路径覆盖
  5. 控制结构测试
    (1)基本路径测试
    (2)条件测试
    (3)循环测试

7.4 软件可靠性与软件可用性

【软件的可靠性】
程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。
【软件可用性】
程序在给定的时间点,按照规格说明书的规定,成功地运行的概率。

第八章、维护

8.1 软件维护的定义

软件维护就是在软件已经交付使用之后,为了改正错误或满足新的需要而修改软件的过程。
其基本任务是保证软件在一个相当长的时期内能够正常运行。

【软件维护的4项活动】

  1. 改正性维护: 为了纠正在使用过程中暴露出来的错误。
  2. 适应性维护: 为了适应外部环境的变化。
  3. 完善性维护: 为了改进原有的软件。完善性维护占整个维护过程的50%以上。
  4. 预防性维护: 为了改进将来的可维护性和可靠性。它实质上是软件再工程。

8.2 软件维护的特点

维护代价高昂,大型软件的维护成本高达开发成本的四倍左右。
维护是软件生命周期的最后一个阶段,也是持续时间最长、代价最大的一个阶段。

8.4 软件的可维护性

【软件可维护性的定义】
维护人员理解、改正、改动或改进这个软件的难易程度。

8.4.1 决定软件可维护性的因素

  1. 可理解性
    模块化(高内聚、低耦合)、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言
  2. 可测试性
    维护人员应该能够得到开发阶段的测试方案,以便进行回归测试。
  3. 可修改性
    耦合、内聚、信息隐藏、局部化、控制域和作用域的关系
  4. 可移植性
    把程序从一种计算环境(硬件配置和操作系统)移植到另一种计算环境的难易程度。
  5. 可重用性
    不做修改或稍加改动就能在不同环境中多次使用

下述 3 类活动有可能成为预防性维护的对象:

  1. 预定将使用多年的程序
  2. 当前正在成功地使用着的程序
  3. 在最近的将来可能要做重大修改或增强的程序。
    典型的软件再工程过程模型定义了 库存目录分析、文档重构、逆向工程、代码重构、数据重构和正向工程 6 类活动。

第十三章、软件项目管理

13.1 估算软件规模

13.1.1 代码行技术(LOC)

13.1.2 功能点技术(FP)

  1. 输入项数: 用户向软件输入的项数,这些输入给软件提供面向应用的数据。
  2. 输出项数: 软件向用户输出的项数,它们向用户提供面向应用的信息,
  3. 查询数: 查询即是一次联机输入,它导致软件以联机输出方式产生某种即时响应。
  4. 主文件数:逻辑主文件(即数据的一个逻辑组合,它可能是大型数据库的一部分或是一个独立的文件)的数目。
  5. 外部接口数:机器可读的全部接口(例如,磁盘或磁带上的数据文件)的数量,用这些接口把信息传送给另一个系统。

13.2 估算工作量

根据软件规模可以估算出完成该项目所需的工作量, 常用的估算模型为静态单变量模型、 动态多变量模型和 COCOMO2模型。

13.6 软件配置管理

13.6.1 软件配置管理的定义

软件配置管理是在软件的整个生命期内管理变化的一组活动,是应用于整个软件过程中的保护性活动。

13.6.2 基线的定义

基线是已经通过了正式复审的规格说明或中间产品,它可以作为进一步开发的基础,并且只有通过正式的变化控制过程才能改变它。

13.6.2 软件配置管理的任务

  1. 标识软件配置中的对象
  2. 版本控制
  3. 变化控制
  4. 配置审计
  5. 状态 告

13.7 能力成熟度模型

能力成熟度模型CMM:用以测量软件机构的软件过程成熟度和评价其软件过程能力的模型。
能力成熟度模型的5个等级从低到高依次是:

  1. 初始级
  2. 可重复级
  3. 已定义级
  4. 已管理级
  5. 优化级

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2020年11月14日
下一篇 2020年11月14日

相关推荐