软考—软件设计师（软件工程基础知识）

1. 软件生存周期

同任何事物一样，一个软件产品或软件系统也要经历孕育、诞生、成长、衰亡的许多阶段，一般称为软件生存周期。把整个软件生存周期划分为若干阶段，使得每个阶段有明确的任务，使规模大、结构复杂和管理复杂的软件的开发变得容易控制和管理。通常，软件生存周期包括可行性分析与项目开发计划、需求分析、设计（概要设计和详细设计）、编码、测试、维护等活动，可以将这些活动以适当的方式分配到不同的阶段去完成。

1.可行性分析与项目开发计划

这个阶段主要确定软件的开发目标及其可行性。必须要回答的问题是：要解决的问题是什么？该问题有可行的解决办法吗？若有解决的办法，则需要多少费用？需要多少资源？需要多少时间？要回答这些问题，就要进行问题定义、可行性分析，制定项目开发计划。 可行性分析与项目计划阶段的参加人员有用户、项目负责人和系统分析师。该阶段产生的主要文档有可行性分析报告和项目开发计划。

2.需求分析

需求分析阶段的任务不是具体地解决问题，而是准确地确定软件系统必须做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。该阶段的参加人员有用户、项目负责人和系统分析师。该阶段产生的主要文档有软件需求说明书。

3.概要设计

在概要设计阶段，开发人员要把确定的各项功能需求转换成需要的体系结构。在该体系结构中，每个成分都是意义明确的模块，即每个模块都和某些功能需求相对应，因此，概要设计就是设计软件的结构，明确软件由哪些模块组成，这些模块的层次结构式怎样的，这些模块的调用关系是怎样的，每个模块的功能是什么。同时，还要设计该项目的应用系统的总体数据结构和数据库结构，即应用系统要存储什么数据，这些数据是什么样的结构，它们之间有什么关系。 概要设计阶段的参加人员有系统分析师和软件设计师。该阶段产生的主要文档有概要设计说明书。

4.详细设计

详细设计阶段的主要任务是对每个模块完成的功能进行具体描述，要把功能描述转变为精确地、结构化的过程描述。即该模块的控制结构是怎样的，先做什么，后做什么，有什么样的条件判定，有什么重复处理等，并用相应的表示工具把这些控制结构表示出来。 详细设计阶段的参加人员有软件设计师和程序员。该阶段产生的主要文档有详细设计文档。

5.编码

编码阶段就是把每个模块的控制结构转换成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。

6.测试

测试是保证软件质量的重要手段，其主要方式是在设计测试用例的基础上建厂软件的各个组成部分。测试阶段的参加人员通常是另一部门（或单位）的软件设计师或系统分析师。该阶段产生的主要文档有软件测试计划、测试用例和软件测试报告。

7.维护

软件维护是软件生存周期中时间最长的阶段。已交付的软件投入正式使用后，便进入软件维护阶段，它可以持续几年甚至几十年。在软件运行过程中可能由于各方面的愿意需要对它进行修改，其原因可能是运行中发现了软件隐含的错误而需要修改；也可能是为了适应变化了的软件工作环境而需要做适当变更；也可能是因为用户业务发生变化而需要扩充和增强软件的功能；还可能是为将来的软件维护活动做预先准备等。 总结上文为表格：

名称	阶段工作	参与的人员	产生的文档
可行性分析与项目开发计划	主要确定软件的开发目标及其可行性	用户、项目负责人和系统分析师	可行性分析报告和项目开发计划
需求分析	此阶段的任务不是具体地解决问题，而是准确地确定软件系统必须做什么，确定软件系统的功能、性能、数据和界面等要求，从而确定系统的逻辑模型。	用户、项目负责人和系统分析师	软件需求说明书
概要设计	开发人员要把明确的各项功能需求转换成需要的体系结构。	系统分析师和软件设计师	概要设计说明书
详细设计	对每个模块完成的功能进行具体描述，要把功能描述转变为精确地、结构化的过程描述。	软件设计师和程序员	详细设计文档
编码	把每个模块的控制结构转化成计算机可接受的程序代码，即写成某种特定程序设计语言表示的源程序清单。	程序员	源程序清单
测试	保证软件质量的重要手段，其主要方式是在设计测试用例的基础上检查软件的各个组成部分。	通常是另一部门（或单位）的软件设计师或系统分析师	软件测试计划、测试用例和软件测试报告
维护	软件生存周期中时间最长的阶段。在软件运行过程中可能由于各方面的原因需要对它进行修改。	维护人员

2.软件过程模型

软件过程模型习惯上也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。

1.瀑布模型（Waterfall Model）

瀑布模型是将软件生存周期中的各个活动规定为依线性顺序链接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落，如下图所示。

瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模型指定开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
瀑布模型假设，一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现完成之前产生。
瀑布模型的一个变体是V模型，如下图所示。V模型描述了质量保证活动和沟通、建模相关活动以及早起构建相关的活动之间的关系。随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其实际上是执行了一系列测试（质量保证活动），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。V模型提供了一种将验证确认活动应用于早起软件工程工作中的方法。

瀑布模型的优点是，容易理解，管理成本低；强调开发的阶段性早起计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或3个阶段中，很难评估真正的进度状态；当接近项目结束时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统的能力。在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。

2.增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日城市间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如下图所示。当使用增量模型时，第一个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点：第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了第一个版本，因此可以减少用户需求的变更；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。
增量模型有以下不足之处：如果没有对用户的变更要求进行规划，那么差生的初始增量可能会造成后来增量的不稳定；如果需求不像早起思考的那样稳定和完整，那么一些增量就可能需求重新开发，重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

3.演化模型（Evolutionary Model）

软件类似于其他复杂的系统，会随着时间的推移而演化。在开发过程中，常常会面临以下情形：商业和产品需求经常发生变化，直接导致最终产品难以实现；严格的交付时间使得开发团队不可能圆满地完成软件产品，但是必须交付功能有线的版本以应对竞争或上页压力；很好地理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。在上述情况和类似情况下，软件开发人员需要一种专门应对不断演变的软件产品的过程模型。
演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。

3.1原型模型（Prototype Model）

大量的实践表明，在开发初期很难得到一个完整的、准确地需求规格说明。这主要是由于客户往往不能准确地表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常 是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型（rapid portotype）这种新的开发方法。
原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其母的是能快速、低成本地构建原型。原型模型如下图所示。

原型模型开始于沟通，其目的是定义软件的总体目标，标识需求，然后快速指定原型开发的计划，确定原型的目标和范围，采用快速设计的方式对其进行建模，并构建原型。被开发的原型应交付给客户使用，并收集客户的反馈意见，这些反馈意见可在下一轮中对原型进行改进。在前一个原型需要改进，或者需要扩展其范围的时候，进入下一轮原型的迭代开发。
根据使用原型的目的不同，原型可分为探索型原型、实验型原型和演化型原型3中。探索型原型的目的是要弄清楚目标的要求，确定所希望的特性，所探讨多种方案的可行性。实验型原型的摸得是验证方案或算法的合理性，是在大规模开发和实现前，用于考察方案是否合适、规格说明是否可靠等。演化型原型的目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。

3.2螺旋原型（Spiral Model）

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了着两种模型的不足。
螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，如下图所示。每个螺旋周期分为如下4个工作步骤。
（1）制定计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。
（2）风险分析。分析所选的方案，识别风险，消除风险。
（3）实施工程。实施软件开发，验证阶段性产品。
（4）用户评估。评估开发工作，提出修正建议，建立下一个周期的开发计划。

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应。因此，该模型特别适用于庞大、复杂并且具有高风险的系统。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专业知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。

4.喷泉模型（Water Fountain Model）

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代型和无间隙性，如下图所示。迭代以为着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。无间隙是指在开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说，它不像瀑布模型那样，在需求分析活动结束后才开始设计活动，在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。

喷泉模型的各个阶段没有明显的界限，开发人员可以同步进行。其优点是可以提高软件项目的开发相率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外，这种模型要求严格管理文档，使得审核的难度加大。

5.基于构件的开发模型（Component-based Development Model）

基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以试组织内部开发的构件，也可以使商品化成品（Commercial Off-The_shelf,COTS）软件构件。基于构件的开发模型具有很多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建构件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。
一种基于构件的开发模型如下图所示，包括领域工程和应用系统工程两部分。

领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。为达到此目的，首先要进行领域分析，分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构，表示领域的候选构件，对候选构件进行可变性分析，以适应多个应用系统的需要，最后构建可复用构件，经严格测试和包装后存入可复用构件库。
应用系统工程的目的是使用可复用构件组装应用系统。首先进行应用系统分析，设计应用系统的体系结构，表示应用系统所需的构件，然后在可复用构件库中查找合适的构件（也可以购买第三方构件），这些选取的构件需进行特化，必要时做适当的修改，以适应该应用系统的需要。对于那些未找到合适构件的应用部分，仍需单独开发，并将其与特化修改后的构件组装成应用系统。在此过程中，还需要对可复用构件的复用情况进行评价，以改进可复用构件，同时对新开发的部分进行评价，并向领域工程推荐候选构件。
综上总结表格如下：

模型名称	模型工作过程	优点	缺点	适用模型
瀑布模型	将软件生存周期中的各个活动规定为依线性顺讯连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序，如瀑布流水逐级下落。	容易理解，管理成本低；强调开发阶段性早期计划及需求调查和产品测试。	客户必须能够完整、正确和清晰地表达他们的需要，在开始的2个或3个阶段中，很难评估真正的进度状态；当接近项目接受时，出现了大量的集成和测试工作；直到项目结束之前，都不能演示系统的能力。需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常 延期完成，开发费用超出预算。	它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
增量模型	融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。	具有瀑布模型的所有优点，还具有第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布第一个版本，因此可以减少用户需求的变更；运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。	如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整 ，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。
原型模型	目的是快速、低成本地构建原型。			适用于需求不明确的开发
螺旋模型	螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。	支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。	过多的迭代次数会增加开发成本，延迟提交时间。	适用于庞大、复杂并且具有高风险系统。
喷泉模型	是一种以用户需求为动力，以对象作为驱动的模型。	可以提高软件项目的开发效率，节省开发时间。	需要大量的开发人员，不利用项目的管理，此外，要求严格管理文档，是的审核的难度加大。	适合于面向对象的开发方法。

3.ISO/IEC9126的软件质量模型

其中包括6个质量特性和21个质量子特性。

功能性	可靠性	可用性	效率	可维护性	可移植性
功能性是指与软件所具有的各项功能及其规定性质有关的一组属性	可靠性是指在规定条件下和规定时间周期内，与软件维护其性能级别的能力有关的一组属性。反映的是软件中存在的需求错误、设计错误和实现错误而造成的失效情况	可用性是指根据规定用户或隐含用户的评估所作出的与使用软件所需要的努力程度有关的一组属性	效率是指在规定条件下，与软件性能级别和所用资源总量之间的关系有关的一组属性	可维护性是指与对软件进行修改的难易程度有关的一组属性	可移植性是指与把一个软件从一个环境转移到另一个环境运行的能力有关的一组属性
适合性 准确性 互操作性（互用性） 依从性 安全性	成熟性 容错性 可恢复性	可理解性 易学性 可操作性	时间特性 资源特性	可分析性 可改变性 稳定性 可测试性	适应性 可安装性 遵循性（一致性） 可替换性

4.内聚与耦合

高内聚、低耦合是软件设计的一个原则，其中内聚是指模块内部各元素之间联系的紧密程度，也就是代码功能的集中程度。耦合是指模块之间相互联系的紧密程度。 模块的内聚类型通常可以分为7中，根据内聚度从高到低排序如下表：

内聚类型	描述
功能内聚	完成一个单一功能，各个部分协同工作，缺一不可
顺序内聚	处理元素相关，而且必须顺序执行
通信内聚	所有处理元素集中在一个数据结构的区域上
过程内聚	处理元素相关，而且必须按特定的次序执行
瞬时内聚	所包含的任务必须在同一时间间隔内执行（如初始化模块）
逻辑内聚	完成逻辑上相关的一组任务
偶然内聚	完成一组没有关系或松散关系的任务

模块的耦合性类型通常分为7种，根据耦合度从低到高排序如下表：

耦合类型	描述
非直接耦合	没有直接联系，互相不依赖对方
数据耦合	借助参数表传递简单数据
标记耦合	一个数据结构的一部分借助于模块接口被传递
控制耦合	模块间传递的信息中包含用于控制模块内部逻辑的信息
外部耦合	与软件以外的环境有关
公共耦合	多和模块引用同一个全局数据区
内容耦合	一个模块访问另一个模块的内部数据 一个模块不通过正常入口转到另一模块内部 两个模块有一部分程序代码重叠 一个模块有多个入口

注：软件文档

转件文档可以分开发文档、管理文档和用户文档三大类。

名称	具体内容
开发文档	《功能要求》、《投标方案》、《需求分析》、《技术分析》、《系统分析》、《数据库文档》、《功能函数文档》、《界面文档》、《编译手册》、《QA文档》、《项目总结》等
管理文档	《产品简介》、《产品演示》、《疑问解答》、《功能介绍》、《技术白皮书》、《评测报告》等
用户文档	《安装手册》、《使用手册》、《维护手册》、《用户报告》、《销售培训》等