自学考试王立福2011版软件工程读书笔记

软件工程读书笔记

2011最新版 课程代码：2333 主编：王立福

前言

<1>. 软件危机：

20世纪60年代，随着计算机的广泛应用，软件生产率，软件质量越来越难以满足社会发展的需求，成为制约社会、经济的制约因素，人们把这一现象称为软件危机；

<2>. 软件的发展历史：

20世纪60年代末至80年代初，软件系统规模，复杂性以及在关键领域的广泛应用促进了软件的工程化开发和管理；这一时期主要围绕软件项目开展了有关开发模型，开发方法和支持工具的研究； 20世纪80年代以来，基于已开展的大量软件工程实践，围绕对软件工程过程的支持，开展了大量有关软件生产技术特别是软件复用技术和软件生产管理的研究和实践；

<3>. 软件工程：

软件工程是应用计算机理论与技术，工程管理的原则和方法，按照预算和进度实现满足用户要求的软件的工程，或以此为研究的学科；

<4>. 软件，软件的本质：

软件是对特定问题域的抽象，是被开发出来的一个逻辑实体，而不是一个有形的物理部件；

软件的本质是实现问题域中的术语和处理逻辑到解空间的术语和逻辑的映射；

<5>. 所要做的工作：

一是如何实现映射，这是技术层面的问题，又可分为过程方向，即求解软件的开发逻辑，如各种模型；和过程途径，即求解软件的开发手段，如结构化方法，面向对象方法等；

二是如何管理这些映射，这是管理层面的问题；

系统建模是运用所掌握的知识，经过抽象，给出系统的一个结构——系统模型；

<6>. 基本途径：

求解一个问题的基本途径是系统建模；

所谓系统建模，是根据已掌握的知识，通过抽象给出系统的一个结构——系统模型；

模型是一个抽象，该抽象是在意图所确定的视角和抽象层上对物理系统的描述，描述其中的成分以及各成分之间所具有的特殊语义关系，还包括对系统边界的描述；

在软件设计领域，系统模型分为概念模型和软件模型；概念模型描述了软件是什么；软件模型描述了实现概念模型的软件解决方案；软件模型又可分为设计模型，实现模型和不熟模型等；

OUTLINE:

软件需求分析

2. 需求

（1）. 需求的定义：

一个需求是一个有关要予构造的陈述，它描述了待开发产品/系统功能上的能力，性能参数或其它性质；

（2）. 需求的属性：

必要性：该需求用户所要求的； 无歧义性：该需求只能用一种方式解释； 可测性：该需求是可进行测试的； 可测量性：该需求是可测量的；

可跟踪性：该需求可以从一个开发阶段跟踪到另一个阶段；

（3）. 需求的分类：

功能需求：规约了系统或系统构件必须执行的功能；

性能需求：规约了系统或系统构件在性能方面必须具有的一些特性；

外部接口需求：规约了系统或系统构件必须与之交互的用户、硬件、软件或数据库元素；

设计约束：是一种需求，它限制了软件系统或软件系统构件设计方案的范围；

质量属性：规约了软件产品所具有的一个性质必须达到其质量方面所期望的一个水平；

（4）. 需求发现技术：

自悟； 交谈； 观察； 小组会； 提炼；

在使用以上技术时，还都可以辅以诸如原型构造等其它方法； 在实际使用中，往往组合地使用以上技术；

执行需求发现这项活动的人，其技能水平对这项活动的成功具有重大影响；

3. 需求规约：

（1）. 需求规约的定义：

需求规约是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个产品/系统的概念模型；

（2）. 需求规约的性质：

重要性和稳定性程度； 可修改的； 完整的； 一致的；

（3）. 需求规约的作用：

需求规约是软件开发小组同用户之间一份事实上的技术合同书，是产品功能和环境的体现；

对产品/系统开发，需求规约是一个正式的受控的起始点； 对于项目的其余大多数工作，需求规约是一个管理控制点； 需求规约是创建产品验收测试计划和用户指南的基础；

（4）. 需求规约的表达方式：

非形式化的需求规约； 半形式化的需求规约； 形式化的需求规约；

OUTLINE:

（2）. 详细设计

目标是给出系统模块结构中各个模块的内部描述过程，即模块内部的算法设计；

详细设计的表格有： ? 程序流程图； ? 盒图N-S图； ? PAD图； ? 类程序设计语言；

结构图：

2. 过程1. 基本数据流 加工 建立系统环境图，确定系统语境； 3. DFD3.1 数据流起着连接其它实体的作用； 抽象

自顶向下，逐步描述系统模型的工软件1. 总体1.1初始1.2 精化1. 变换1. 复审和精化系1. 模块1. 模块结统概念模型 化； 构图； 2. 层图； 2.详细设1. 程序流程图； 2. N-S图 面向对象设计UML

基于的理论是：世界是由客体组成的，客体都有自己的属性和习惯操作。客体之间的相互依赖和相互作用构成了世界的各个系统。 面向对象设计是根据客体之间的相互关系来建立系统模型的系统工具。

类图

顺序图 用况图

状态图

关联（聚合，依赖（引入，

泛化 精化

访问 引入

类，对主动类

包

接口 协作 用况

构件 制品 节点

名称 图例 定义 作用

6. 表达客观事务的术语

<1>. 类和对象

A. 类，对象；

B. 类是一组具有相同属性，操作，关系和语义的对象的描述。对象是

类的实例。 C. 图示： ? 名称：

类：中间对齐，黑体字/斜体字，首字母大写； 属性：左对其，正常/下划线，首字母小写；

操作：左对齐，正常/斜体字/下划线，首字母小写，大写； ? 格式：

类： 类域：：类；对象：类； 属性：±Name:[]={}

操作：±Name():{},(in/out Name:=) ? 图示：

? 可见性： +：public,公有的； #：protect,保护的； -：private,私有的；

类名/对属性 操作

~：包内的； D. 作用：

模型化问题域中的概念； 建立系统的职责分布模型； 模型化建模中使用的基本类型；

<2>. 主动类

A. 主动类：Active Class；

B. 主动类是一种至少具有一个进程或线程的类； C. 图例：

D. 模型化系统中的并发行为；

<3>. 包

A. 包， B. 定义 C. 图例：

D. 作用：控制信息组织复杂性；

<4>. 接口

A. 接口，Interface；

B. 接口是操作的一个集合，其中每个操作描述了类，构件，子系统所

提供的一个服务； C. 图例：

《interface》

《useD. 模型化系统/产品中的接缝；

<5>. 协作

A. 协作

B. 协作是一个交互，包括交互各方、交互内容和交互方式； C. 图列： D. E.

F. 用于表达由一组特定元素参与的具有特定行为的结构，抽象协作性

行为；

<6>. 用况

A. 用况，Use Case

B. 用况是对一组动作序列的描述，系统执行这些动作应产生对特定参

与者有值的可观察的结果； C. 图例：

D. 模型化系统中的并发行为；

<7>. 构件

A. 构件，Component；

B. 构件是系统/产品设计中的一种模块化部件，通过外部接口隐藏了

内部实现； C. 图例：

D. 表达解空间中可独立标识的成分；

<8>. 制品

A. 制品，Artifact

B. 制品是包含物理信息的可替代的物理部件； C. 图例：

D. 通常用于表达有关源代码信息或运行时信息的一个物理打包，抽象

工作产品；

《artifact》

9.

RUP

RUP的特点：以用况为驱动，以体系结构为中心，迭代，增量式开发；

其中每一个特点中都包含需求，分析，设计，实现，测试阶段； 迭代中分为初始阶段，精化阶段，构造阶段，移交阶段；

10. 基本模型

基本术语 过程指导 系统模型 11. 每个阶段的大概轮廓，包括横向三项，每项又纵向3层

基本术语 分析活动 分析模型的分析用况分析实体控制边界类的用况包的体系结

12. 所有活动的规律的整理：

系统模型 体系结构 用况 基本元素

获取

发现并描述参与确定用况的优先精化用况 构造用户界面原用况模型的结构

标识分析包

分析

处理分析类之间标识服务包 定义分析类之间表示节点和网络

设计

表示子系统和接

标识重要的实体标识公共特定需

用况分析 类的分析 包的分析

标识有意义的设标识一般性的设

用况设计 类的设计 子系统设计

<1>. 对获取阶段，主要表现为需求的收集，精化和结构化；

<2>. 在分析阶段，把用况分成大块并表示大块之间的关系，再细分成小块，详细描述小块； <3>. 在设计阶段，把大块转化成子系统，并层次化成软件体系，之间的关系转化为接口；

小块进一步细化，方向上是从上层和左边进化，即依照上层中同列的用况进化，按照左边大块中的情况进化；

13. 详细的过程：

如需求获取包括：详细每个表格参看课本；

RUP使用用况技术来获取需求；其目的是使用UML中的用况，参与者以及依赖等术语来抽象客观实际问题，创建系统需求获取模型，以及在该模型下的体系结构描述。

用况模型是系统的一种概念模型，是对系统功能的抽象，包括系统参与者，系统用况以及他们之间的关系。 阶段 1.列出候选需求 2.理解系统语境 3.捕获系统功能需求 4.捕获非功能需求

产生制品 特征列表 领域模型和业务模型 用况模型 其它需求或针对特定需求的用况

其中捕获系统需求阶段的活动又可分为： 输入 活动 人员 输出 特征表，领域模型和业务模1.发现和描述系统分析用况模型[概述]，术型，补充需求 参与者 2.发现和描述用况 用况模型[概述]，术语表，3.确定用况优体系设计体系结构描述[用况补充需求 先级 者 模型视角] 人员 语表 用况模型[概述]，术语表，4.精化用况 补充需求 用况描述用况[精化] 者 用况[精化]，用况模型[概5.构造用户界人机接口人机接口 述]，术语表，补充需求 面原型 设计者 用况[精化]，用况模型[概6.用况模型的系统分析用况模型[精化] 述]，术语表，补充需求

结构化 员 软件测试

软件测试 软件测试技 软件测试

14. 软件测试

<1>. 软件测试：

按照特定规程发现软件错误的过程；软件测试步

<2>. 软件测试过程模型：

环境 环境NO 对象 对象测试比YES 素质 错误

15. 软件测试技术；

<1>. 路径测试技术；

A. 控制流程图；

过程块，判定，节点，链； B. 测试策略；

语句覆盖（P1）≤分支覆盖（P2）≤条件和条件组合覆盖≤路径覆盖（PX）；

C. 路径选择和用例设计；

? 选择最简单的、具有一定功能含义的入口、出口路径； ? 在已选择的基础上，选择没有循环的路径，选择短路径，简单路径；

? 选择没有明显功能含义的路径，并考虑这样的路径为什么能够存在，为什么没有通过功能上合理的路径得到覆盖；

<2>. 事务流测试技术；

A. 事务流程图；

操作，分支，节点，链； B. 与控制流程图的区别：

? 基本模型元素所表达的语义不同； ? 一个事务不同于路径测试中的一个路径；

? 事务流程图中的分支和节点可能是一个更加复杂的过程： 分支，汇集； 并生，吸收； 丝分裂，结合； C. 测试步骤： ? 获得事务流程图； ? 浏览、复审； ? 用例设计； ? 测试执行；

<3>. 等价类划分；

A. 划分等价类；

有效对无效：一对一，一对多，多对一； B. 设计测试用例：

? 为每一个等价类规定一个唯一的编号；

? 设计一个新的测试用例，使其尽可能多的覆盖尚未被覆盖的有效等价类，重复这一步直到所有等价类都被覆盖；

? 设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，知道所有无效等价类都被覆盖；

16. 软件测试过程；

A. 单元测试；

? 关注单个模块的结构和功能，还要建立驱动模块和承接模块； ? 模块接口：测试穿过模块接口的控制流； ? 局部数据结构：执行数据结构测试； ? 重要的执行路径：执行执行路径选择测试； ? 错误的执行路径：边界测试； B. 集成测试；

? 从顶向下的集成测试，需要编制承接模块；

? 从底向上的集成测试，直到放上最后一个模块程序才成为一个对立的整体； C. 有效性测试；

? 发现软件实现的功能与需求规格说明书不一致的错误； D. 系统测试；

软件生存周期

12207-20 过程组分类生存周期模过程建立 过程监控 过程描述：6

17. ISO/IEC 12207-2008 系统/软件工程-软件生存周期模型

<1>. 背景

ISO/IEC 12207-1995： 最早的软件生存周期模型，过程分为基本过程，支持过程，组织过程；

ISO/IEC 15288：系统生存周期模型；

ISO/IEC 12207-2008，系统/软件工程-软件生存周期模型，由上两种结合而来；

<2>. 过程分类及其内在关系：

项目过程

驱动，支持： 保障：

对项目的执行提供基本保障；

技术过程组织上项软件实现软件复用软件支持协议过程系统语境支持软件开发的特殊化为： 支持：

提升能力：

<3>. 过程描述：

? 软件实现过程： 活动：软件实现策略

任务1：选择并建立适合项目的生存周期模型；

任务2：建立输入文档并置于配置管理过程之下，按配置管理的过程执行变更；

任务3：选择，裁剪和使用组织为执行或支持此过程而建立的标准、方法、工具或计算机编程语言； 任务4：计划该活动过程；

任务5：确保交付的软件产品的运行和维护不依赖非交付项；

? 软件需求分析过程 活动：软件需求分析； 任务1：建立软件需求和文档；

任务2：评估软件需求，并建立相应的评估结果文档； 任务3：按软件评审过程评审软件需求；

? 软件体系结构设计 活动：软件体系结构设计；

任务1：将软件项的需求转化为一种体系结构，描述其顶层构架并表

示其中的软件构件，建立相应的文档；

任务2：为软件项的外部接口和软件构件之间的接口开发顶层设计，并建立相关的文档；

任务3：为数据库开发顶层设计，并建立相关的文档； 任务4：开发用户文档的初始版本；

任务5：定义初始测试需求和系统集成进度，并建立相关的文档； 任务6：评估软件项的体系机构设计，接口设计，数据库设计，并建立相关的文档；

任务7：按评审过程进行评审；

? 软件验证过程 活动1：过程实现；

任务1.1：确定项目是否需要一项验证过程以及独立程度； 任务1.2：如果项目承当验证过程，则应为验证软件产品建立相关的验证过程；

任务1.3：如果项目需要独立的验证过程，则应选择一个有资格的组织执行验证；

任务1.4：确定需要验证的生存周期活动和软件产品，并选择合适的验证过程和任务以及执行这些任务相关的方法，技术和工具； 任务1.5：计划验证过程，并建立相关的文档； 任务1.6：实现验证过程；

活动2：验证过程； 任务2.1：需求验证； 任务2.2：设计验证； 任务2.3：代码验证； 任务2.4：集成验证； 任务2.5：文档验证；

? 软件确认活动 活动1：过程实现；

任务1.1：确定项目是否需要一项确认工作以及独立程度； 任务1.2：如果项目承担确认工作，则应为确认软件产品建立相应的确认过程，并定义确认任务以及相关联的方法、技术和工具； 任务1.3：如果项目需要独立的确认工作，则应选择一个有资格的组织负责该工作；

任务1.4：开发确认计划，并建立相应的文档； 任务1.5：实现确认计划；

活动2：确认；

任务2.1：编制选择的测试需求、测试案例和测试规格说明，以分析测试结果；

任务2.2：确保这些测试需求、测试案例和测试规格说明反映特定期望所使用的特殊需求；

任务2.3：按照任务1和2执行测试；

任务2.4：确定软件产品是否满足所期望的使用； 任务2.5：测试软件产品是否适合所选择的目标环境；

? 剪裁过程

任务1：标识并记录剪裁可能造成的影响；

任务2：考虑与系统关键特征相关的维度和生存周期结构； 任务3：从剪裁过程所影响的所有各方获得输入； 任务4：按照决策管理过程做出剪裁决定；

任务5；选择生存周期过程，剪裁并删除所选择的结果、活动和任务；

18. 软件生存周期模型

? 瀑布模型：

把软件生存周期各项活动规定为按固定顺序连接的若干阶段工作，形成瀑布流水，最终得到软件产品；

系统需求，软件需求，需求分析，设计，编码，测试，运行； 对支持结构化开发，控制软件开发的复杂性，促进软件开发的工程化起着重要的作用；

? 增量模型：

将需求分组，形成一个个增量，对每一个增量实施瀑布式开发； 前提是需求可结构化；

? 演化模型：

基于核心需求开发核心系统，根据用户反馈实施开发的迭代过程； 主要用于事先不能完整定义需求的软件开发；

? 螺旋模型：

制定计划，风险分析，实施工程，客户评估；

在瀑布模型和演化模型的基础上，增加了他们所忽略的风险分析；

? 喷泉模型：

体现了软件创建所固有的迭代和无间隙的特征； 主要用于支持面向对象技术的软件开发；

19. 过程规划和管理；

在组织上项目使能过程组中有过程创建，过程评估，过程改进等过程，强调了PDCA，即过程规划，过程执行，过程检测，过程调整；

<1>. 关于过程创建；

A. 选择软件生存周期模型： 第一步：标识项目可用的SLCM；

第二步：在预期的最终系统或开发环境中，标识影响选择SLCM的属性；

第三步：标识所有为选择SLCM而需要的约束；

第四步：基于以往的经验和组织能力，评估第一步中所标识的SLCM； 第五步：选择最能满足项目属性和约束的SLCM；

B. 细化所选择的软件生存周期模型：

依据所选择的软件生存周期模型的需求和项目的需求，执行剪裁过程，表示需要的活动和不需要的活动； C. 为每一个各活动或任务表示合适的实例数目； D. 确定活动的时序关系，并检查信息流；

<2>. 关于软件生存周期监控过程

A. 软件生存周期监控过程； ? 进度和进展的跟踪； ? 质量数据趋势的检查；

? 设计、编码和测试计划的复审记录和动作的检查； ? 变更要求和测试异常报告趋势的检查； ? 关键资源的有效使用； ? 与项目组成员的交谈；

B. 软件生存周期活动变更的影响的评估； 考虑的因素： ? 所要求的返工； ? 资源需求； ? 实施时间；

? 对项目和用户的益处； ? 员工情绪；

可采用的动作； ? 什么都不做； ? 强化过程； ? 调整过程； ? 替换过程； ? 以上方式的组合； C. 改变的实施： ? 规划改变； ? 实施改变；

能力和成熟度模型

能力、熟度概念 各级特各级目标CMMICMMI模CMMI模过过程 过程改过程制CMCMMI概念 分类

20. 过程：

<1>. 过程：

? 过程是一种手段，通过该手段可将人员，规程和方法，工具和设备进行集成，以开发所期望的系统，生产所期望的产品，提供所期望的服务；

<2>. 过程改善：

? 过程改善是人为设计的一个活动程序，其目的是改进组织的过程性能和成熟度，并改进这一程序的结果；

<3>. 过程制度化：

? 过程制度化是过程被渗透到所执行工作的方式中，执行的工作有一定的承诺，并且在组织范围内是一致的；

21. CMMI概述：

<1>. 前身：

? 软件能力成熟度模型，SW-CMM，SEI； ? 系统工程能力模型，SECM，EIA；

? 集成产品开发能力成熟度模型，IPD-CMM，SEI；

<2>. CMMI

? CMMI集成化能力成熟度模型是针对系统产品开发的能力成熟度模型，它包含一些最佳实践，覆盖了产品从概念到交付和维护的整个生存周期，强调了构造和维护当今产品所必要的工作；

<3>. CMMI分类：

? 针对获取；

? 针对开发； ? 针对服务；

22. CMMI模型：

A. 模型构成： 专用实 子实

典型工作子实共用实践的共用实专用共用意图陈简介性相关过过程 B. 概念：

? 过程域：是一个业务域一束相关的实践，当他们一起得以实现时，就满足被认为对该过程域的改善具有重要作用的一组条件；分为项目管理类，工程类，支持类，过程管理类；

? 专用目标：用来描述满足该过程域必须呈现的一些独有特征； ? 共用目标：用来描述实现制度化的该过程必须呈现的特征；

C. 能力等级的应用： GG/GP 原句；

补充中将“该过程”替换成应用的过程； 如项目规划过程应用于能力等级2： 把该过程制度化为一个已管理的过程；

制度化项目管理过程，使其成为一个已管理的过程；

D. 各能力等级，成熟度等级所应达到的共有目标和专有目标的对应： GG/GP独立，能力等级是各GG/GP的向下递归；

SG/SP独立，成熟度是SG/SP的向下递归后过程域的能力等级；

23. CMMI的能力等级和成熟度等级

<1>. 能力等级；

A. 定义：

能力等级是一种过程改善路径，该路径使组织针对单一过程域不断改进该过程域；

指的是在单一过程域中达到的过程改善； B. 各等级基本特征：

? 未完成级：该过程是一个没有执行或部分执行的过程，没有满足任何一个或多个过程目标；

? 已执行级：该过程是一个已执行的过程，即该过程达到了该过程域的专用目标；

? 已管理级：该过程是一个已管理的过程，存在支持该过程的基本基础设施；具体来说，该过程有计划，并按策略执行；执行该过程的人员为了生产受控输出，具有一定的技能并具有充分的资源；该过程有相关利益攸关方的参与；该过程得以监视，执行，审查；并对其是否符合过程描述进行了评估；

? 已定义级：该过程是一个已定义的过程，该过程是依据组织的过程剪裁指南从一个标准过程集剪裁而来的，并且该过程对组织的过程资产提供了有意义的工作产品，测量和其它过程改善信息； ? 已定量管理级：该过程是一个已定量管理的过程；通过统计技术和其它定量技术控制过程性能；建立了有关质量和过程性能的量化目的，并作为管理过程的准则；在整个过程期间，采用统计术

语的质量和过程性能的定量表达，是可理解并得以管理的； ? 持续优化级：该过程是一个已持续优化的过程；基于对该过程中内在偏差的共性原因的理解，通过增强，技术改进，不断改进过程性能的程度；

C. 各级别的共用目标和共用实践：

GG1.达到专用目标：该过程通过将认同的输入工作产品转化为认同的输出工作产品，支持该过程域并使其达到其专用目标；

GP1.执行专用实践：执行该过程域的专用实践，以开发工作产品，并为达到该过程域的专用目标服务；

GG2.把该过程制度化为一个已管理的过程：制度化该过程，使其成为一个已管理的过程；

GP2.1建立组织策略：为规划和执行该过程，建立并维护组织策略； GP2.2 规划该过程：建立并维护执行该过程的计划；

GP2.3 提供资源：为执行该过程，以开发工作产品，并为该过程提供服务，提供充足的资源；

GP2.4 指定责任：为执行该过程，开发工作产品，并为该过程提供服务，指定责任和权利；

GP2.5 培训人员：必要时，培训执行该过程或支持该过程的人员； GP2.6 管理配置：把该过程指定的工作产品放到配置管理适当的控制层上；

GP2.7 标识相关利益攸关方的参与：在制定计划期间，标识参与该

本文来源：https://www.bwwdw.com/article/xbw8.html