【软件设计师—基础精讲笔记5】第五章软件工程基础

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

二、软件过程模型

典型的软件过程模型有瀑布模型、增量模型、演化模型(原型模型、螺旋模型)、喷泉模型、基于构件的开发模型和形式化方法模型等。

1、瀑布模型

瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、运行与维护。

瀑布模型的特点：容易理解，管理成本低，每个阶段都有对应的成果产物，各个阶段有明显界限划分和顺序要求，一旦发生错误，整个项目推倒重新开始。

适用于需求明确的项目，一般表述为需求明确、或二次开发，或者对于数据处理类型的项目

2、V模型

强调测试贯穿项目始终，而不是集中在测试阶段。是一种测试的开发模型。

3、喷泉模型

典型的面向对象的模型。特点是迭代、无间隙。会将软件开发划分为多个阶段，但各个阶段无明显界限，并且可以迭代交叉。

4、原型模型

典型的原型开发方法模型。适用于需求不明确的场景，可以帮助用户明确需求。

5、增量模型

融合了瀑布模型的基本成分和原型实现的迭代特征，可以有多个可用版本的发布，核心功能往往最先完成，在此基础上，每轮迭代会有新的增量发布，核心功能可以得到充分测试。强调每一个增量均发布一个可操作的产品。

6、螺旋模型

典型特点是引入了风险分析。结合了瀑布模型和演化模型的优点，最主要的特点在于加入了风险分析。它是由制定计划、风险分析、实施工程、客户评估这一循环组成的，它最初从概念项目开始第一个螺旋。属于面向对象开发模型，强调风险引入。

【模型总结】

瀑布：易理解、成本低；有界限，有顺序；需求要明确。二次开发

V模型：一种测试开发模型，测试贯穿始终

喷泉：属对象，可迭代；无间隙，无界限

原型：需求不明确时

增量：核心先完成，得到充分测试。每个增量发布一个产品。

螺旋：面向对象，有风险

7、统一过程

（在考试中 UP、RUP 都指统一过程）：

典型特点：用例和风险驱动、以架构为中心、迭并且和增量。

统一过程把一个项目分为四个不同的阶段：

起始阶段：包括用户沟通和计划活动两个方面，强调定义和细化用例，并将其作为主要模型。里程碑：生命周期目标
精化阶段：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示。里程碑：生命周期架构
构建阶段：将设计转化为实现，并进行集成和测试。里程碑：初始运作功能
移交阶段：将产品发布给用户进行测试评价，并收集用户的意见，之后再次进行迭代修改产品使之完善。里程碑：产品发布

8、敏捷方法

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，适用于小团队和小项目，具有小步快跑的思想。常见的敏捷开发方法有极限编程法、水晶法、并列争球法和自适应软件开发方法。

（1）极限编程：是一种轻量级的开发方法，

四大价值观：沟通、简单、反馈、勇气。

五大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作。

十二个最佳实践：计划游戏、隐喻、小型发布、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作 40 小时、现场客户和编码标准。

（2）水晶法：强调经常交付，认为每一种不同的项目都需要一套不同的策略、约定和方法论。

（3）并列争球法：核心是迭代、增量交付，按照30天进行迭代开发交付可实际运行的软件。

（4）自适应软件开发：核心是三个非线性的，重叠的开发阶段：猜测、合作、学习。

（5）敏捷统一过程AUP：采用“在大型上连续”以及“在小型上迭代”的原理来构建软件系统

三、需求分析

软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。

1、需求分析的任务是解决做什么的问题。

2、需求的分类：

（1）功能需求-考虑系统要做什么，在何时做，在何时以及如何修改或升级。

（2）非功能需求：考虑软件开发的技术性指标，例如存储容量限制、执行速度、响应时间及吞吐率等。

（3）设计约束：除了功能需求和非功能需求以外的需求，例如操作系统限制、开发语言限制等。

3、需求分析的工具有判定表、判定树、数据流图和数据字典。

4、需求分析的产物有：需求规格说明书 SRS。

四、系统设计

1、软件设计的任务是解决怎么做的问题。

2、软件设计包括体系结构设计、接口设计、数据设计和过程设计。

过程设计：系统结构部件转换成软件的过程描述。结构设计：定义软件系统各主要部件之间的关系。
接口设计（人机界面设计）：软件内部，软件和操作系统间以及软件和人之间如何通信。
数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。

3、系统设计的基本任务大体上可以分为概要设计和详细设计两个步骤。

1、概要设计

设计软件系统总体结构：基本任务还是采用某种设计方法，将一个复杂的系统按功能划分成模块；确定每个模块的功能；确定模块之间的调用关系；确定模块之间的接口，即模块之间传递的信息；评价模块结构的质量。

数据结构及数据库设计：在需求分析阶段对数据的组成、操作约束和数据之间的关系进行了描述，概要设计阶段要加以细化，详细设计阶段则规定具体的实现细节。

编写概要设计文档：概要设计说明书、数据库设计说明书、用户手册以及修订测试计划。

评审：对设计部分是否完整地实现了需求中规定的功能、性能等要求，设计的可行性，关键的处理以及外部接口定义的正确性、有效性、各部分之间的一致性等都一一进行评审。

2、详细设计

对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。
对模块内的数据结构进行设计。
对数据库进行物理设计，即确定数据库的物理结构。
其他设计：根据软件系统的类型，还可能需要进行代码设计、输入/输出格式设计，用户界面设计等。
编写详细设计说明书。
评审：对处理过程的算法和数据库的物理结构都要评审。

五、系统测试

系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。

有效的软件测试实际上分为4步进行，即单元测试、集成测试、确认测试和系统测试。

1、单元测试

也称模块测试，在模块编写完成且无编译错误后就可进行。单元测试侧重于模块中内部处理逻辑和数据结构。如果选用机器测试，一般用白盒测试法。

具有5个特征：模块接口、局部数据结构、重要的执行路径、出错处理、边界条件。

2、集成测试

集成测试就是把模块按系统设计说明书的要求组合起来进行测试。

（1）自顶向下集成测试

自顶向下集成测试是一种构造软件体系结构的增量方法。模块的集成顺序为从主控模块(主程序) 开始，沿着控制层次逐步向下，以深度优先或广度优先的方式将从属于 (或间接从属于) 主控模块的模块集成到结构中。

（2）自底向上集成测试

自底向上集成测试就是从原子模块（程序结构的最底层构件）开始进行构造和测试。

（3）回归测试

在集成测试策略的环境下，回归测试是重新执行已测试过的某些子集，以确保变更没有传播不期望的副作用。

3、确认测试

α测试是由有代表性的最终用户在开发者的场所进行。软件在自然的环境下使用，开发者站在用户的后面观看，并记录错误和使用问题。α测试在受控的环境下进行。

β测试在一个或多个最终用户场所执行。与α测试不同，开发者通常不在场，因此，β测试是在不被开发者控制的环境下软件的“现场”应用。最终用户记录测试过程中遇见的所有问题（现实存在的或想象的)，并定期地报告给开发者。接到β测试的问题报告之后，开发人员对软件进行修改，然后准备向最终用户发布软件产品。

4、系统测试

系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种集成测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方。

（1）恢复测试

（2）安全性测试

（3）压力测试

（4）性能测试

（5）部署测试

5、测试方法

（1）方法分类

【1】静态测试：【非运行态】桌前检查、代码走查、代码审查。

【2】动态测试：【运行态】

（2）黑盒测试法

黑盒测试也称为功能测试，在完全不考虑软件的内部结构和特性的情况下，测试软件的外部特性。

【1】等价类划分。等价类划分法将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，这样就可以用少量代表性的测试用例取得较好的测试效果。等价类划分有两种不同的情况：有效等价类和无效等价类。在设计测试用例时，要同时考虑这两种等价类。

【2】边界值分析。输入的边界比中间更加容易发生错误，因此用边界值分析来补充等价类划分的测试用例设计技术。边界值划分选择等价类边界的测试用例，既注重于输入条件边界，又适用于输出域测试用例。

【3】错误推测。错误推测是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例的方法。其基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。

【4】因果图。因果图法是从自然语言描述的程序规格说明中找出因（输入条件）和果（输出或程序状态的改变)，通过因果图转换为判定表。

（2）白盒测试法

白盒测试也称为结构测试，根据程序的内部结构和逻辑来设计测试用例，对程序的路径和过程进行测试，检查是否满足设计的需要。

【1】逻辑覆盖。逻辑覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖和路径覆盖6种。

语句覆盖。语句覆盖是指选择足够的测试数据，使被测试程序中的每条语句至少执行次。语句覆盖对程序执行逻辑的覆盖很低，因此一般认为它是很弱的逻辑覆盖。
判定覆盖。判定覆盖是指设计足够的测试用例，使得被测程序中的每个判定表达式至少获得一次“真”值和“假”值，或者说是程序中的每一个取“真”分支和取“假”分支至少都通过一次，因此判定覆盖也称为分支覆盖。判定覆盖要比语句覆盖更强一些。
条件覆盖。条件覆盖是指构造一组测试用例，使得每一判定语句中每个逻辑条件的各种可能的值至少满足一次。
判定/条件覆盖。判定/条件覆盖是指设计足够的测试用例，使得判定中每个条件的所有可能取值 (真/假) 至少出现一次，并使每个判定本身的判定结果 (真/假) 也至少出现一次。
条件组合覆盖。条件组合覆盖是指设计足够的测试用例，使得每个判定中条件的各种可能值的组合都至少出现一次。满足条件组合覆盖的测试用例是一定满足判定覆盖、条件覆盖和判定/条件覆盖的。
路径覆盖。路径覆盖是指覆盖被测试程序中所有可能的路径

【2】循环覆盖。

【3】基本路径测试。

白盒测试原则：

程序模块中的所有独立路径至少执行一次。
在所有的逻辑判断中，取“真”和取“假”的两种情况至少都能执行一次。
每个循环都应在边界条件和一般条件下各执行一次。
测试程序内部数据结构的有效性等。

六、运行和维护

1、系统转换

新系统试运行成功之后，就可以在新系统和旧系统之间互相转换。新旧系统之间的转换方式有直接转换、并行转换和分段转换。

2、系统维护

系统可维护性评价指标：可理解性、可测试性、可修改性

软件维护类型（★★★★）

【1】更正性维护：针对真实存在并已经发生的错误进行的维护行为。

【2】预防性维护：针对真实存在但还未发生的错误进行的维护。

【3】适应性维护：指使应用软件适应信息技术变化和管理需求变化而进行的修改。企业外部市场环境和管理需求不断变化也使得各级管理人员不断提出新的信息需求。

【4】完善性维护：扩充功能和改善性能而进行的修改。对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。

3、系统评价

按评价的时间与信息系统所处的阶段的关系又可从总体上把广义的信息系统评价分成立项评价、中期评价和结项评价。

七、项目管理

1、项目估算

【1】COCOMO 估算模型

COCOMO 模型是一种精确的、易于使用的成本估算模型。COCOMO 模型按其详细程度分为基本 COCOMO 模型、中级 COCOMO 模型和详细 COCOMO 模型。

基本 COCOMO 模型。基本 COCOMO 模型是一个静态单变量模型，用于对整个软件系统进行估算。
中级 COCOMO 模型。中级 COCOMO 模型是一个静态多变量模型，它将软件系统模型分为系统和部件两个层次。
详细 COCOMO 模型。它将软件系统模型分为系统、子系统和模块 3 个层次。

【2】Putnam 估算模型

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

2、进度管理

软件项目进度管理的目的是确保软件项目在规定的时间内按期完成。进度安排的常用图形描述方法有 Gant 图(甘特图)和项目计划评审技术(PERT)图。

（1）Gantt 图

Gantt图是一种简单的水平条形图，它以日历为基准描述项目任务。水平轴表示日历时间线，每个条形表示一个任务，任务名称垂直地列在左边的列中，图中水平条的起点和终点对应水平轴上的时间，分别表示该任务的开始时间和结束时间，水平条的长度表示完成该任务所持续的时间。当日历中同一时段存在多个水平条时，表示任务之间的并发。

Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性。但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。

（2）PERT 图

PERT 图是一个有向图，图中的箭头表示任务，它可以标上完成该任务所需的时间。图中的结点表示流入结点的任务的结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点。一个事件有一个事件号和出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始：最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。每个任务还可以有个松弛时间，表示在不影响整个工期的前提下完成该任务有多少机动余地。为了表示任务间的关系，在图中还可以加入一些空任务(用虚线箭头表示)，完成空任务的时间为0。

PERT 图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系以及如期完成整个工程的关键路径。但是，PERT 图不能反映任务之间的并行关系。