软考中级-软件设计师-14.上午题-软件工程(10分左右)14.1 软件过程 14.1.1 能力成熟度模型(CMM) 1

14.1 软件过程

14.1.1 能力成熟度模型(CMM)

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

14.1.2.1 阶段式模型

14.1.2.2 连续式模型

14.2 软件过程模型

14.2.1 瀑布模型

以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导；

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

优点：容易理解，管理成本低；强调开发的阶段在早期计划及需求调查和产品测试；缺点：客户必须能够完整、正确和清晰地表达他们的需要。

14.2.2 V模型

V模型描述了质量保证活动和沟通、建模相关活动以及早期构建相关的活动之间的关系；

14.2.3 增量模型

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

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

优点：第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布第一个版本，因此减少用户需求的变更；

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

14.2.4 演化模型

14.2.4.1 原型模型

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

可以有效的捕获系统需求；

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

14.2.4.2 螺旋模型

是多种模型的混合，针对需求不明确的项目，与原型类似，但是增加了风险分析，这也是其最大的特点；

工作步骤：制定计划——风险分析——实施工程——用户评估

适用性：该模型特别适用于庞大、复杂并且具有高风险的系统。

支持用户需求的动态变化；为项日管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险；在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。过多的选代次数会增加开发成本，延迟提交时间。

14.2.5 喷泉模型

是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性；喷泉模型克服了瀑布模型不支持软件重用和多项开发活动集成的局限性；模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统；开发活动(如分析、设计、编码)之间不存在明显的边界。

14.3 统一过程模型(RUP)

用例和风险驱动，以架构为中心，迭代并且增量；

开发的四个阶段：

起始阶段（项目的初始活动，如确认需求和风险评估等）
精化阶段（需求分析和架构设计等)
构建阶段（系统的构建，产生实现模型等)
移交阶段（软件提交方面的工作，产生软件增量，进行β测试，交付系统等）

四个阶段对应的里程碑：

起始阶段：生命周期目标
精化阶段：生命周期架构
构建阶段：初始运作功能
移交阶段：产品发布

统一过程的典型代表是RUP，RUP应用了角色、活动、制品和工作流，其中角色表述谁做，制品表述做什么，活动表述怎么做，工作流表述什么时候做；

UP的每一次迭代都是一次完整的软件开发过程，包括整个软件开发生命周期，有五个核心工作流（需求、分析、设计、实现、测试)。

14.4 敏捷方法

14.4.1 极限编程(XP)

XP 是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生有周期。

4大价值观：沟通、简单性、反馈、勇气
5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作
12个最佳实践：计划游戏(快速制定计划、随着细节的不断变化而完善)、小型发布(系统的设计要能够尽可能早地交付)、隐喻(找到合适的比喻传达信息)、简单设计(只处理当前的需求，使设计保持简单)、测试先行(先写测试代码，然后再编写程序)、重构(重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求)、结对编程、集体代码所有制、持续集成(可以按日甚至按小时为客户提供可运行的版本)、每周工作 40 个小时、现场客户和编码标准。

14.4.2 水晶法

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

14.4.3 并列争求法

并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”。

14.4.4 自适应软件开发(ASD)

ASD有6个基本的原则：有一个使命作为指导；特征被视为客户价值的关键；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。

14.4.5 敏捷统一过程(AUP)

AUP采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。采用经典的UP阶段性活动(初始、精化、构建和转换)，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给最终用户。每个 AUP迭代执行以下活动：建模，实现，测试，部署，配置及项目管理，环境管理；

14.5 需求分析

14.5.1 软件需求

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

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

(3)用户或人的因素。考虑用户的类型。例如，各种用户对使用计算机的熟练程度，需要接受的训练，用户理解、使用系统的难度，用户错误操作系统的可能性等

(4)环境需求。考虑未来软件应用的环境，包括硬件和软件。对硬件设备的需求包括机型外设、接口、地点、分布、湿度、磁场干扰等；对软件的需求包括操作系统、网络、数据库等。

(5)界面需求。考虑来自其他系统的输入，到其他系统的输出，对数据格式的特殊规定，对数据存储介质的规定。

(6)文档需求。考虑需要哪些文档，文档针对哪些读者。

(7)数据需求。考虑输入、输出数据的格式，接收、发送数据的频率，数据的准确性和精度，数据流量，数据需保持的时间。

(8)资源使用需求。考虑软件运行时所需要的数据、其他软件、内存空间等资源；软件开发、维护所需的人力、支撑软件、开发设备等。

(9)安全保密要求。考虑是否需要对访问系统或系统信息加以控制，隔离用户数据的方法用户程序如何与其他程序和操作系统隔离以及系统备份要求等

(10)可靠性要求。考虑系统的可靠性要求，系统是否必须检测和隔离错误;出错后，重启系统允许的时间等，

(11)软件成本消耗与开发进度需求。考虑开发是否有规定的时间表，软/硬件投资有无限制等。

(12)其他非功能性要求。如采用某种开发模式，确定质量控制标准、里程碑和评审、验收标准、各种质量要求的优先级等，以及可维护性方面的要求。

14.6 系统设计

14.6.1 概要设计

设计软件系统总体结构结构：

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

软件系统总体结构是概要设计关键步骤；

编写概要设计文档：

设计说明书、数据库设计说明书、用户手册以及修订测试计划

14.6.2 详细设计

对每个模块进行详细的算法设计；

14.7 测试

14.7.1 系统测试

14.7.1.1 系统测试的意义、目的及原则

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

目的：以最少的人力和时间发现潜在的各种错误和缺陷。

原则：

应尽早并不断地进行测试；
测试工作应避免由开发软件的人或小组承担；
在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期输出结果；
在设计测试用例时，不仅要设计有效、合理的输入条件，也要包含不合理、失效的输入条件。
严格按照测试计划来进行，避免测试的随意性；
妥善保存测试计划、测试用例，作为软件文档的组成部分，为维护提供方便；
测试例子都是精心设计出来的，可以为重新测试或追加测试提供方便。
系统测试阶段的测试目的来源于需求分析阶段；

14.7.2 单元测试

单元测试侧重于模块内部处理逻辑和数据结构。如果采用机器测试，一般采用白盒测试法；

测试内容：

模块接口：保证测试模块的数据流可以正确的流入、流出；

局部数据结构：

重要的执行路径：单元测试中对路径的测试是基本的任务；
出错处理
边界条件

单元测试过程：

由于模块不是独立运行的程序，各模块之间存在调用与被调用的关系；需要两种模块：驱动模块，桩模块。

14.7.3 集成测试

自顶向下集成测试

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

不需要编写驱动模块，需要编写桩模块。

自底向上集成测试

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

不需要编写桩模块，需要编写驱动模块。

回归测试

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

冒烟测试

14.7.4 测试方法

14.7.4.1 黑盒测试

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

等价类划分

等价类划分法将程序的输入域划分为若干等价类，然后从每个等价类中选取一个代表性数据作为测试用例。每一类的代表性数据在测试中的作用等价于这一类中的其他值，这样就可以用少量代表性的测试用例取得较好的测试效果。

边界值分析
错误推测
因果图

14.7.4.2 McMabe度量法

计算有向图G的环路复杂性的公式为:V(G)=m-n+2，V(G)是有向图G中的环路个数，m是G中的有向弧数，n是G 中的节点数。

代码行数是度量软件复杂性的一个重要参数。

14.7.4.3 白盒测试

白盒测试技术：逻辑覆盖、循环覆盖、基本路径测试

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

14.8 系统维护

14.8.1 系统可维护性概念

14.8.1.1 评价指标

可理解性。
可测试性。
可修改性。

14.8.1.2 维护与软件文档

文档是软件可维护性的决定因素；

在软件工程的每一个阶段都应该考虑软件的可维护；进行质量保证审核可提高软件产品的可维护性。

14.8.2 系统维护的内容和类型

系统维护包括：硬件维护、软件维护、数据维护

软件维护：

正确性维护。正确性维护是指正在系统开发阶段已发生而系统测试阶段尚未发现的错误；
适应性维护。适应性维护是指使应用软件适应信息技术变化和管理需求变化而进行的修改；
完善性维护。扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能和性能特征；
预防性维护。为了改进应用的可靠性和可维护性，为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统使用各类变化而不被淘汰。

14.8.3 软件可靠性、可用性、可维护性

可靠性是指一个系统对于给定的时间间隔内，在给定条件下无失效运作的概率，可以用MTTF / (1 + MTTF) 来度量，其中MTTF为平均无故障时间。

可用性是在给定时间点上，一个系统能够按照规格说明正确运作的概率。可以使用MTBF / (1 + MTBF) 来度量，其中MTBF为平均失效间隔时间。

可维护性是在给定的使用条件下，在规定的时间间隔内，使用规定的过程和资源完成维护活动的概率。可以使用

1 / (1 + MTTR) 来度量，其中MTTR为平均修复时间。

14.8.4 沟通路径

n个人的沟通路径共：n * (n -1) / 2 条；

特殊：n个人，1个主程序员，n-1个普通程序员：则有n-1条沟通路径；

14.9 软件项目估算

14.9.1 COCOMO估算模型

基本COCOMO模型是一个静态单变量模型，用于对整个软件系统进行估算；
中级COCOMO模型是一个静态多变量模型，他将软件系统模型分为系统和部件两个层次，系统是由部件构成，他把软件开发所需要的人力成本看做是程序大小和一系列“成本驱动属性”的函数；
详细COCOMO模型他将系统模型分为系统、子系统和模块3个层次。