软件评测师：软件工程基础知识_软件维护类别

软件工程的基本目标：开发高质量软件！

软件工程的基本要素：方法，工具，过程！

第一节 软件工程概述

软件维护（四类）

（1）正确性维护：又叫做改正性维护，是指改正在系统开发阶段已发生而系统测试阶段未发现的错误。

（2）适应性维护：是指使应用软件适应信息技术变化和管理需求变化而进行的修改。

        例题：由于硬件配置的变化，如机型、终端或打印机等导致软件系统需要进行修改维护，这类维护属于（B）。

（A） 改正性                 （B） 适应性                  （C） 完善性                  （D）预防性

（3）完善性维护：又叫做改善性维护，这是为扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能与性能特征。

        例题：修改现有软件系统的设计文档和代码以增强可读性，这种行为属于（C）维护。

（A） 正确性                  （B） 适应性                  （C） 完善性                  （D） 预防性

        例题：对现有软件系统中一些数据处理的算法进行改进，已提高效率，从而更快地响应用户的服务要求。这种行为属于（C）维护。

 （A） 正确性                  （B） 适应性                  （C） 完善性                  （D） 预防性

（4）预防性维护：为了改进应用软件的可靠性和可维护性，为了适应未来的软/硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。

        例题：在软件维护阶段，将专用报表功能改成通用报表功能，以适应将来可能的报表格式变化，则该维护类型为（D）维护。

（A） 正确性                  （B） 适应性                  （C） 完善性                  （D） 预防性

敏捷开发

        敏捷软件开发宣言：

        相对于过程和工具，更强调个人和交互；

        相对于严格的文档，更重视可工作的软件；

        相对于合谈判，更注重与客户的合作；

        相对于遵循计划，更专注于对变化的响应。

        存在很多敏捷过程的典型方法，每一种方法都基于一套原则，这些原则实现了敏捷宣言。

其中极限编程XP是敏捷方法中最普遍的一种，由价值观、原则、实践和行为四份部分组成，有四份价值观，即沟通、简单性、反馈和勇气。

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

1、极限编程（XP）

极限编程的12个最佳实践为：

（1）计划游戏（规划策略）

（2）小型发布（小版本发布）

（3）隐喻

（4）简单设计

（5）测试先行（测试驱动开发）

（6）重构（Refactoring）

（7）结对编程

（8）集体代码所有制

（9）持续集成

（10）每周工作40个小时

（11）现场客户（客户测试）

（12）编码标准

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

        例题：一下关于极限编程（XP）的叙述中，正确的是（A），XP的12个最佳实践不包括（C ）。

1问题：

（A）XP是激发开发人员创造性、使管理负担最小的一组技术

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

（C）多个自组织和自治小组并行地递增实现产品

（D）有一个使命作为指导，它设立了项目的目标，但并不描述如何达到这个目标

2问题：激发开发人员创造性、使管理负担最小的一组技术。

（A）重构           （B）结对编程           （C）精心设计          （D）隐喻

        试题解析：

        1、极限编程XP是激发开发人员创造性、使管理负担最小的一组技术。

        2、水晶法Crystal认为每一个不同的项目都需要一套不同的策略、约定和方法论。

        3、并列争球法（Scrum）使用迭代的方法，其中吧每30天一次的迭代称为个冲刺，并按需求的优先级来实现产品多字自组织和自治小组并行地递增实现产品，协调是通过简短的日常情况会议进行。

        4、自适应软件开发（ASD）有六个基本原则：

        （1）在自适应软件开发中，有一个使命作为指导，它设立了项目的目标，但不描述如何达到这个目标；

        （2）特征被视为客户键值的关键，因此，项目时围绕着构造的构件来组织并实现特征；

        （3）过程中的迭代是很重要的，因此重做与做同样重要，变化也包含其中；

        （4）变化不视为是一种更正，而是对软件开发实际情况的调整；

        （5）确定的交付时间迫使开发人员认真考虑每一个生产版本的关键需求；

        （6）风险也包含其中，它使开发人员首先跟踪最艰难的问题。

软件设计

  概念设计

        一个优秀的概念设计应包含下列特性：用客户的语言编写;不包含技术行话；描述的是系统的功能;与实现无关;与需求文档链接起来。而一旦客户认可概念设计，就可以开始技术设计。

  技术设计  

        技术设计通常包含：对主要硬件部分及其功能的描述；软件结构的层次和功能；数据结构和数据流。

   1、软件设计原则

        （1）考虑独立性要强些，模块内高内聚，低耦合，模块间的耦合程度要低

        （2）系统的模块之间应该呈树状结构，模块之间存在上下级关系，但不允许同级之间横向联系，也不希望有复杂的网状结构或交叉调用关系

        （3）对所有模块必须严格分类编码并建立归档文件

        例题：在进行软件设计时，以下结构设计原则中，不正的是（B）。

        （1）模块化    （2）抽象  （3）封装  （4）信息隐藏

        （A） (1)(2)(3)(4)             （B） (1)(2)(4)            （C） (2)(3)(4)            （D）(1)(2)(3)

        解析：封装只是软件设计的手段，它的目的是要达到信息隐藏。

        （A） 模块应具有较强的独立性，即高内聚和低耦合                 

        （B） 模块之间的连接存在上下级的调用关系和同级之间的横向联系                 

        （C） 整个系统呈树状结构，不允许网状结构或交叉调用关系出现

        （D） 所有模块都必须严格地分类编码并建立归档文件

   2、设计模式的分类

设计模式可以分为三种类型，共23种，按照设计模式的目的可以分为以下三大类：

（1）创建型模式：单例模式吗、抽象工厂模式、生成器模式、工厂模式、原型模式。

（2）结构型模式：适配器模式、桥接模式、装饰器模式、组合模式、外观模式、享元模式、代理模式。

（3）行为型模式：模板方法模式、命令模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式，状态模式、策略模式、责任链模式、访问者模式。

 2.1 设计模式的应用

3、耦合的知识

        一般来说，模块之间的耦合有七种类型，根据耦合性从低到高分为非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合和内容耦合。

（1）非直接耦合（无直接耦合）：

        例题：已知两个模块之间没有直系，它们之间的联系完全是通过主模块的控制和调用来实现的。这两个模块的耦合类型为（A）耦合。

（A） 非直接                 （B） 数据                  （C） 外部                  （D） 内容

（2）数据耦合: 若一个模块访问另一个模块时，彼此之间是通过数据参数(不是控制参，公共数据结构或外部变量)来交换输入、输出信息。

        例题：A模块通过简单数据类型（如整型）参数访问B模块，该参数在B模块内用于数据计算，则A、B模块之间存在（A）。

（A） 数据耦合                 （B） 标记耦合              （C） 控制耦合              （D） 外部耦合

（3）标记耦合：模块通过参数表传递记录信息，两个以上的模块都需要其余某一数据结构子结构时，不使用全局变量方式，而是使用记录传递的方式。

（4）控制耦合：一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能。

（5）外部耦合：模块间通过软件之外的环境联结(如I/O将模块耦合到特定的设备、格式、通信协议上)

（6）公共耦合: 指通过一个公共数据环境相互作用的那些模块间的耦合。

（7）内容耦合：一个模块直接访问另一个模块的内部数据，或者通过非正常入口转入另一个模块内部，或者两个模块有一部分程序代码重叠，又或者一个模块有多种入口。

4、内聚的知识

一般模块的内聚度分为7种类型，从低到高依次为:

（1）偶然(巧合)内聚: 模块完成的动作之间没有任何关系，或者仅仅是一种非常松散的关系。

（2）逻辑内聚: 指模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。

（3）时间(瞬时)内聚: 模块内部的各个组成部分所包含的处理动作必须在同一时间间隔内执行，例如初始化模块。

（4）过程内聚: 指一个模块完成多个任务，这些任务必须按指定的过程执行。过程内聚不利于模块的重用。

        例题：模块A的功能为：从数据库中读出产品信息，修改后存回数据库，然后修改记录写到维护文件中。该模块内聚类型为（C）内聚。

（A） 逻辑                  （B） 时间                  （C） 过程                  （D） 功能

（5）通信(信息)内聚: 指模块内的所有处理元素都在同一个数据结构上操作，或者各处理使用相同的输入数据或者产生相同的输出数据。

（6）顺序内聚: 指一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一功能元素的输入。

（7）功能内聚: 指模块内的所有元素共同作用完成一个功能，缺一不可，这是最强的内聚。

软件架构基础知识

（1）管道/过滤器模式的优缺点：

        优点：（1）高内聚，低耦合；（2）多过滤器简单合成；（3）功能模块重用；（4）便于维护；（5） 支持特定分析；（6）支持并行操作。

        缺点：（1）导致系统成批操作；（2）需协调数据流；（3）性能下降，实现复杂。

 软件架构

        1、三层架构与MVC模式

        MVC模式是软件工程中常见的一种软件架构模式，该模式把软件系统（项目）分为三个基本部分：模型（Model）、视图（View）和控制器（Controller）。

        MVC模式的优势：

        （1）简化后期对项目的修改、扩展等维护操作；

        （2）使项目的某一部分变得可以重复利用；

        （3）使项目的结构更加直观。

        视图（View）：负责界面的显示，以及与用户的交互功能，例如表单、网页等。

        控制器（Controller）：可以理解为一个分发器，用来决定对于视图发来的请求，需要用哪一个模型来处理，以及处理完后需要跳回到哪一个视图。即用来连接视图和模型。

        模型（Model）：模型持有所有的数据、状态和程序逻辑。模型接受视图数据的请求，并返回最终的处理结果。

        实际开发中，通常用封装数据的JavaBean和封装业务的JavaBean来实现模型层。

        MVC模式的流程：

        浏览器通过视图向控制器发出请求，控制器接收到请求之后通过选择模型进行处理，处理完请求以后再转发到视图，进行视图界面的渲染并做出最终响应，如图所示。

        在MVC模式中，视图View可以用JSP/HTML/CSS实现，模型Model可以用JavaBean实现，而控制器Control就可以用Servlet来实现。

第二节 结构化开发方法

        在结构化分析中，用数据流图描述：数据在系统中如何被传送或变换，以及如何对数据流进行变换。

        结构化开发方法：由结构化分析、结构化设计和结构化程序设计构成。是一种面向数据流的开发方法，其基本思想是：自顶向下、逐层分解，基本原则是功能的分解和抽象。

        例题：（A）是一种面向数据流的开发方法，其基本思想是软件功能的分解和抽象。

（A） 结构化开发方法                  （B） Jackson系统开发方法

（C） Booch方法                          （D）UML（统一建模语言）

        试题解析：

        结构化开发方法：是传统的、也是应用较为广泛的一种软件开发方法，它是基于数据流进行需求分析和软件设计，用抽象模型的概念，按照软件内部数据传递和转换关系，对问题和功能自顶向下逐层分解。        

        Jackson系统开发方法：是一种典型的面向数据结构的分析和设计方法，以活动为中心，一连串活动的顺序组合成一个完整的工作进程。

        Booch方法：是一种面向对象的软件开发方法。

        UML：仅仅是一种建模标准语言，规定了构成软件的各个元素和构件的图示规范。

        例题：在采用结构化开发方法进行软件开发时，设计阶段接口设计主要依据需求分析阶段的( 问题1：A )。接口设计的任务主要是( 问题2：C )。

问题1：

（A） 数据流图                               （B）E-R图

（C） 状态-迁移图                          （D）加工规格说明

问题2：

（A） 定义软件的主要结构元素及其之间的关系

（B） 确定软件涉及的文件系统的结构及数据库的表结构

（C） 描述软件与外部环境之间的交互关系，软件内模块之间的调用关系                          （D）确定软件各个模块内部的算法和数据结构

        例题：结构化分析（Structured Analysis，SA）是面向数据流的需求分析方法，（C）不属于SA工具。

（A） 分层的数据流图      （B） 数据字典         

（C） 问题分析图             （D）描述加工逻辑的结构化语言、判定表或判定数

        试题解析：

        结构化方法（Structured Method）是强调开发方法的结构合理性以及所开发团建的结构合理性的软件开发方法。针对软件生存周期各个不同阶段，它包括结构分析（SA）、结构化设计（SD）和结构化程序设计（SP）等方法。结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等，其中不包含问题分析图。

1、加工

        加工描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流。

        例题：当采用数据流图对银行客户关系管理进行分析时，（D）是一个加工。

（A） 工作人员                  （B） 账户                  （C） 余额                  （D）存款

体系结构设计：

数据设计：

接口设计：依据数据流图来进行接口设计，

过程设计：主要包含对数据结构和算法的设计，对算法设计时，其主要依据来自“加工规格说明”；算法描述，可以用自然语言、数字语言或预订的符合来描述，如流程图、伪代码、决策表、决策树等。

2、重要模型

        2.1 数据流图（Data Flow Diagram，DFD）

        描述数据在系统中如何被传送或变换，没有任何具体的物理部件，只描绘数据在软件中流动和被处理的逻辑过程。反映系统必须完成的逻辑功能，用于功能建模；

        数据流图包括外部实体（数据源）、加工、数据存储和数据流。每个加工必须既是输入流又有输出流；一个加工可以有多个数据流流向另一个加工，一个加工可以有两个相同的输出数据流流向两个不同的加工。在将父图分解为子图时，必须要保持数据流的平衡。

        例题：在结构化分析方法中，依据（A）来进行接口设计。

（A） 数据流图          （B） 实体-关系图        （C） 数据字典           （D）状态-迁移图

实体——联系图：用于数据建模；

状态——迁移图：用于行为建模；

第三节 面向对象开发方法

1、UML之用例图

        用例图（use case diagram）：展现了一组用例、参与者（actor）以及它们之间的关系。用例图给出系统的静态用例视图。这些图对系统的行为进行组织和建模是非常重要的。

        用例图展现了一组用例、参与者以及他们之间的关系；通常包括：用例，参与者，扩展关系，包含关系。

        用例图对系统的静态用例视图进行建模时，可用下列两种方式类使用用例如。

        （1）对系统的语境建模。

        （2）对系统的需求建模。        

        用例模型描述的外部执行者所理解的系统功能，用于需求分析阶段，UML的用例图可以对系统的功能需求建模。

        扩展：对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。在用例图中使用带箭头的虚线表示（在线上标注<<extend>>），箭头从子用例指向基用例。

        包含：include为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。include关系在用例图中使用带箭头的虚线表示（在线上标注<<include>>），箭头从基用例指向子用例。

        例题：在同一建模语言（UML）中，（B）用户描述系统与外部系统及用户之间的交互。

（A）类图        （B）用例图        （C）对象图        （D）协作图

        例题：以下用例图中，A1和A2为（问题1：A）。A1和A2的关系为（问题2：）

问题1：

        （A） 参与者

        （B） 人        

        （C） 系统           

        （D） 外部系统

问题2：

        （A） 关联

        （B） 泛化        

        （C） 包含           

        （D） 扩展

        

        试题解析

        本题考查面向对象技术和UML的基本概念和基础知识。

        上述图是UNL用例图。用例图根据系统和系统的环境之间的交互，描述客观察到的、用户发起的功能。A1和A2是参与者，空心箭头表示两者之间是泛化的关系。

        例题：以下关于用例图的叙述中，不正确的是（问题1：B）。图书馆管理系统需求中包含“还书”用例和“到书通知”用例，对于“还书”用例，应先查询该书是否有人预定，若有则执行“到书通知”。“还书”用例和“到书通知”用例是（问题2：B）关系，以下用例图中，（问题3：B）是正确的。管理员处理“还书”用例时，需要先执行“验证身份”用例，那么“还书”用例和“验证身份”用例之间是（问题4：C）关系。

问题1：

        （A） 系统用例图反映了整个系统提供的外部可见服务

        （B） 系统用例图对系统的协作建模        

        （C） 用例图主要包含用例、参与者及其之间关系三个要素           

        （D）系统用例图对系统的要求建模

问题2：

        （A） 关联

        （B） 扩展        

        （C） 包含           

        （D） 泛化

问题3：

        （A） 一

        （B） 二        

        （C） 三           

        （D） 四

问题4：

        （A） 关联

        （B） 扩展        

        （C） 包含           

        （D） 泛化

   

        例题：以下关于用例图的叙述中，不正确的是（B）。

        （A） 系统用例图反映了整个系统提供的外部可见服务

        （B） 系统用例图对系统的协作建模        

        （C） 用例图主要包含用例、参与者及其之间关系三个要素           

        （D）系统用例图对系统的要求建模

        试题解析

        用例模型描述的外部执行者所理解的系统功能，用于需求分析阶段，可以对系统的需求建模。但是系统用例图无法对系统的协作建模。

1）泛化

        概念：若两类事物之间存在特殊/一般关系，则用继承机制表示该关系，即UML中的泛化关系。

 2）多态

        概念：是多种表现形式。多态性的实现，一般通过在派生类中重定义基类的虚函数来实现。

        例题：用面向对象方法设计了一个父类File和两个子类DiskFie和TapeFile，这两个子类继承了其父类的open方法，并给出不同的实现。不同的子类执行open方法时，有不同的行为，这种机制称为(B)。

（A） 继承          （B） 多态        （C） 消息传递           （D）关联

        试题解析

        本题中给定一个方法，不同的子类行为不同，这是多态机制。

3）多重继承

        多重继承是指一个类有多个父类。多重继承可能造成混淆的情况，出现二义性的成员。

         例题：在面向对象方法中，两个及以上的类作为一个类的超类时，称为( 问题1：A )，使用它可能造成子类中存在( 问题2：D）的成员。

问题1：

（A） 多重继承          （B） 多态        （C） 封装           （D）层次继承

问题2：

（A） 动态                 （B） 私有        （C） 公共           （D）二义性

2、UML之类图

        类图（class diagasn）：展现了一组对象、接口、协作和他们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出了系统的静态进程视图。

        类图：主要是对系统词汇建模，或者对简单的协作建模，或者对逻辑数据库模式建模。

        类图中：类和类之间的关系有依赖关系、关联关系、聚集关系、组合关系和泛化关系，起重工具体关系和组合关系式表示更强的关联关系，表示整体和部分的关系，而组合关系的类之间具有相同的生命周期。

 

        1）类和类之间的关系

        类是用户定义的类型，与语言定义的基本类型一样，有了类型后，就可以定义（创建）该类型的变量，其含义是系统为变量分配存储空间。对与程序中定义的类，并不要求一定要创建其实例，对实例的数目也没有限制。创建类的实例时，系统需要为该实例分配存储空间。

        类之间存在继承、关联、聚合和组装等关系。

        1）继承关系对父类和子类进行建模，其中父类和子类之间共享数据和方法的机制。

        2）关联关系表示类之间的一种连接关系，如员工类和公司类之间具有关联关系。

        3）聚合关系表示客观事物之间的整体和部分的关系，如汽车和发动机的关系。

        4）组装关系是一种更强的聚合关系，一个部分类的对象在一个时刻必须仅属于这个整体类的对象，且整体类的对象管理它的部分类的对象。整体类不存在了，部分类也就不复存在。

        例题：在面向对象方法设计中，用类图给出系统的静态设计试图，其应用场合不包括（问题1：D）。下图是一个UML类图，其中类University和类School之间是（问题2：C）关系，类Person和类PersonRecord之间是（问题3：A）关系，表示Person与Person Record（问题4：A）。

问题1：

（A） 对系统的词汇建模          

（B） 对简单的协作建模        

（C） 对逻辑数据库模式建模           

（D） 对系统的需求建模

问题2：

（A） 依赖          

（B） 关联        

（C） 聚合           

（D） 泛化

问题3：

（A） 依赖          

（B） 关联        

（C） 聚集           

（D） 泛化

问题4：

（A） 之间的语义关系，其中PersonRecord发生变化会影响Person的语义          

（B） 之间的一种结构关系，描述了一组链，即对象之间的联系        

（C） 整体和部分的关系           

（D） 是一般和特殊的关系

        试题解析

        本题中，类University和类School之间是聚合关系，类Person和类PersonRecord之间是依赖关系，表示Person与PersonRecord之间的语义关系，其中PersonRecord发生变化会影响Person的语义:

2）类属性及说明总结

3、UML之对象图

        对象图（object diagram）：展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图相同，这些图给出系统的静态设计视图或静态进程视图，但是他们是从真实的或原型案例的角度建立的。

4、UML之序列图

        序列图（sequence diagram）：是场景（scenario）的图形化表示，描述了以时间顺序组织的对象之间的交互活动。

5、UML之协作图

        协作图：强调收发信息的对象的结构组织。序列图和协作图都是交互图。交互图展现了一种交互，它由一组对象和它们之间的关系组成，包括它们之间可能发送的消息。交互图关注系统的动态视图。序列图和协作图是同构的，它们之间可以相互转换。

6、UML之状态图

        状态图（statechart diagram）：展现了一个状态机，它有状态、转换、事件和活动的流程。状态图关注于系统的动态视图，它对接口、类和协作的行为建模尤为重要，它强调对象行为的事件顺序。

7、UML之活动图

        活动图（activity diagram）：是这一种特殊的状态图，它展现了在系统内从一个活动到另一个活动的流程。活动图专注于系统的动态视图。它对于系统的功能建模特别重要，并强调对象间的控制流程。

8、UML之构建图

        构件图（component diagram）：展现了一组构件之间的组织和依赖。构件图专注于系统的静态实现视图。它与类图相关，通常把构件映射为一个活多个类、接口或协作。

9、UML之部署图

        部署图（deployment diagram）：展现了运行处理结点以及其中的构件的配置。部署图给出了体系结构的静态实施视图。它与构件图相关，通常一个节点包含一个或多个构建。

10、面向对象分析模型

        用类图构建系统的基本模型，该基本模型为系统的静态模型，描述系统的结构特征；

        用顺序图、活动图和状态图等建立系统的行为模型；

        用包图组织系统的模型。包属于分组事务。

        协作图：也称为“通信图”，用于描述相互合作的对象的交互和链接关系。与顺序图的区别：虽然都是描述对象间的交互关系，但是顺序图着重体现交互的时间顺序，协作图着重体现交互对象间的静态链接关系。

        例题：在面向对象分析模型中，___A__不属于系统的行为模型。

（A） 类图          （B） 顺序图        （C） 活动图           （D）状态图

第四节 软件开发模型

1、增量模型

        增量模型：可以把软件产品作为一系列的增量构建来设计、编码、集成和测试，系统功能在增量中不断完善或者增加。

        例题：某开发小组欲开发一个软件系统，实现城市中不同图书馆的资源共享，包括实体资源和电子资源，共享规则可能在开发过程中有变化。客户希望开发小组能尽快提交可运行的软件，且可以接受多次交互。这种情况下最适宜采用（C）开发过程模型。

（A） 瀑布          （B） 原型        （C） 增量           （D）螺旋

        试题解析

        题干中明确说明希望快速开发，同时可以接受多次交互。这种情况下适合增量模型。这样可以款式开发地一交互产品、交互，然后再开发、再交互。

2、原型模型

        原型模型：允许开发人员快速地构造整个系统或系统的一部分以理解或澄清问题。

        原型模型：快速构造软件的原型，在此基础上开发最终软件产品。

        原型化（Prototyping）方法：是一类动态定义需求的方法。与结构化方法相比，原型化方法更需要熟练的开发人员，衡量原型开发人员能力的重要标准是快速获取需求。

        原型化方法基于这样一种客观事实：并非所有的需求在系统开发之前都能准确地说明和定义。因此，它不追求也不吭呢要求对需求的严格定义，而是采用了动态定义需求的方法。

        具有广泛技能、高水平的原型化人员是原型实施的重要保证。原型人员应该具有经验与才干、训练有素的专业人员。衡量原型化人员能力的重要标准是他是否能够从用户的模糊描述中快速获取实际的需求。

        例题：某开发小组欲开发一个大型软件系统，需求变化较小，此时最不适宜采用（B）过程模型。

（A） 瀑布          （B） 原型        （C） 增量           （D）螺旋

        试题解析：

瀑布模型、增量模型和螺旋模型都适宜大型软件系统的开发，原型模型更常用于小规模且需求变化较大的软件系统的开发。

3、瀑布模型

        瀑布模型从一种非常高层的角度描述了软件开发过程中进行的活动，并且提出了要求开发人员经过的事件序列。

        瀑布模型将开发阶段描述为从一个阶段瀑布般地转换到另一个阶段的过程。

        瀑布模型的优点：

        （1）可强迫开发人员采用规范化的方法；

        （2）严格地规定了每个阶段必须提供的文档；

        （3）要求每个阶段交出的所有产品都必须是经过验证的。

        瀑布模型的缺点：

        （1）每个阶段开发几乎完全依赖于书面的规格说明，因此可能导致开发出的软件产品不能满足用户需求；

        （2）适用于项目开始时需求就确定的情况。

        例题：瀑布模型表达了一种系统的、顺序的软件开发方法。以下关于瀑布模型的叙述中，正确的是（D）。

（A） 瀑布模型能够非常快速地开发大规模软件项目         

（B） 只有很大的开发团队才使用瀑布模型

（C） 瀑布模型已不再适合于现今的软件开发环境           

（D）瀑布模型适用于软件需求确定，开发过程能够采用线性方式完成的项目

        试题解析

        瀑布模型是一种系统的、顺序的软件开发方法，它适用于软件需求确定，开发过程能够以线性化的方式完成那些软件开发项目。能否适用于某个项目或者快速开发某个项目并不取决于所开发的软件项目的规模或开发团队的规模，而且只软件需求确定，开发过程能够采用线性方式完成，现今的软件开发仍然可以使用瀑布模型。

4、螺旋模型

        螺旋模型明确地考虑了开发中的风险。把开发活动和风险管理结合起来，以将风险减到最小并控制风险，在该过程模型中，风险被明确地提了出来。

        螺旋模型综合了瀑布模型和演化模型的优点，并增加了这两种模型忽略的风险分析。

        螺旋模型师软件开发的高级策略，它不仅适合结构化方法，而且更适合面向对象方法。它的实施将对软件开发组织的工作模式、人员素质、管理和技术水平产生深远的影响，是最有前途的过程模型之一。

        采用螺旋模型时，软件开发沿着螺线自内向外旋转，每转一圈都要对风险进行识别和分析，并采取相应的对策。螺旋线第一圈开始可能是一个概念项目。从第二圈开始，一个新产品开发项目开始了，新产品的演化沿着螺旋线进行若干次迭代，一直运转到软件生命期结束。

5、V模型

        V模型师瀑布模型的变种，它说明测试活动是如何与分析和设计相关联的。

6、喷泉模型

        喷泉模型：以用户需求为动力，以对象作为驱动，适合于面向对象的开发方法。

        喷泉模型主要用于描述面向对象的开发过程。“喷泉”一词体现了面向对象开发过程以下2个特征：

        （1）迭代：意味着模型中的开发活动需要多次重复，每次重复都会增加或明确一些目前系统的性质，但不是对先前工作结果本职性的改动。

        （2）无间隙：指在开发活动之间不存在明显的边界，允许各个开发活动交叉、迭代地进行。

7、演化模型

        演化模型：在获取一组基本的需求后，通过快速分析构造出该软件的一个初始可运行的版本，然后足部演化成最终软件产品。

第五节 软件质量管理

 1、软件需求

        软件需求是为了解决用户的问题和实现用户的目标，用户所需要的软件必须满足的能力和条件。从不同的角度，软件需求有不同的分类。

（1）业务需求：描述使用软件系统要达到什么目标。

（2）系统需求：为了满足需求，系统或系统成分必须满足或具有的条件或能力。

（3）功能需求：规模软件必须实现的功能性要求，即软件产品必须要完成的任务。可以用UML建模语言的用例图对功能需求进行建模。

（4）质量需求：也称为非功能需求，在满足功能需求的基础上，要求软件系统还必须具有的特性。

（5）设计约束：规定软件开发过程中的设计决策或限制问题解决方案的设计决策。

        例题：某软件系统的原始需求包括：“当某个查询请求是不适当或非法的，应提示用户”，该需求属于__C__。

（A） 功能需求                  （B） 质量需求                  （C） 设计约束                  （D）过程约束

（6）非功能需求：描述软件解决方案必须具有的质量特性，如性能、安全等。

（7）过程约束：用于构建系统的技术和资源的限制。

2、软件质量保证

        软件质量保证是通过预防、检查与改进来保证软件质量，是软件生命周期的管理积极验证软件是否满足规定的质量和用户的需求。

        它着眼于软件开发活动中的过程、步骤和产物，而不是对软件进行剖析，找出问题或进行评估。它不负责生产高质量的软件产量和指定质量计划，这些都是软件开发的工作，它的责任是审计软件经理和软件工程组的质量活动并鉴别活动中出现的偏差。它的内容不包括“收集软件产品、软件过程中存在的不符合项，在项目总结时进行分析”。        

软件质量保证的目标：

（1）通过监控软件开发过程保证产品质量

（2）保证软件产品、软件过程中存在的问题得到处理，必要时将问题反映给高级管理者

（3）确保项目组制定的计划、标准和规程适合项目组需要，同时满足评审和审计需要

3、软件评审

        软件评审的目的：

        为了使软件开发按软件工程提出的过程循序进行，在软件各颜值阶段结束时，检查该阶段工作是否完成，所提交的软件阶段产品是否达到了规定的质量和技术要求，决定是否可以转入下一阶段研制工作。

        （1）内部评审

                组织方：承建单位组织并实施

                评审人员：由软件开发组、质量管理和配置管理人员组成，可邀请业主单位参加

                主持人：本单位的人

                评审团规模：根据软件的规模等级和安全性关键等级组成5~9人的评审组进行

                评审内容：软件开发各阶段

        对规模等级大和安全性关键等级高的软件必须进行外部评审

        （2）外部评审

                组织方：承建单位组织，成立评审委员会

                评审人员：评审委员会，由业主单位，承建单位和一定数量（占评审委员会总人数的50%以上）的软件专家组成员组成，人数为7人以上（单数），设主任一人、副主任若干人。评审委员会与软件专家组共同进行评审。评审分专家组审查和评委会评审两步完成。软件专家组进行审查，评审委员会进行评审。

                主持人：业主单位

                评审团规模：人数为7人以上（单数）

                评审内容：

4、软件复审

        可维护性是所有软件都应具有的基本特点。必须在开发阶段保证软件具有可维护的特点。

        （1）在系统分析阶段的复审过程中，应该指出软件的可移植性问题以及可能影响软件维护的系统界面；

       （2） 在系统设计阶段的复审过程中，应该从同一修改、模块化和功能独立的目的出发，评价团建的结构和过程；

        （3）在系统实施阶段的复审期间，代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素。

4、软件复杂度

        软件复杂性是度量软件的一种重要指标，其参数主要包括规模、难度、结构、智能度等。

（1）规模：即总指令数，或源程序行数；

（2）难度：通常由程序中出现的操作数数目所决定的量表示；

（3）结构：通常用与程序结构有关的度量来表示；

（4）智能度：即算法的难易程度。

5、产品评价 - 软件样品登记

评价者对产品部件进行管理和登记的内容：

（1）部件或文档的唯一标识符

（2）部件的名称或文档标题

（3）文档的状态（包括物理状态或变异状态）

（4）请求者提供样品的版本、配置和日期信息

（5）接收的日期

注：除非请求者有另外的许可，否则，评价者将保守全部产品部件和相关文件的秘密

软件过程管理

        RUP对软件开发过程的描述：RUP应用了角色、活动、制品和工作流4种重要的模型元素，其中角色表述“谁做”，制品表述“做什么”，活动表述“怎么做”，工作流表述“什么时候做”。

        RUP中每个阶段产生的制品：

        初启阶段结束：产生一个构想文档、一个有关用例模型的调查、一个初始的业务用例、一个早期的风险评估和一个可以显示阶段和迭代的项目计划等制品；

        精化阶段结束：产生一个补充需求分析、一个软件架构描述和一个可执行的架构原型等制品；

        构建阶段结束：是一个准备交到最终用户手中的产品、用户手册和对当前版本的描述；

        移交阶段结束：产生移交给用户产品发布版本。

        软件成熟度模型（CMM）:

        5个成熟度等级：

        初始级（1级）：

        阶段定义级（2级）：管理和工程两方面的软件已经文档化、标准化，并综合成整个软件开发组织的标准软件过程。

        集成级（3级）：

        管理和度量级（4级）：

        优化、缺陷预防和质量控制级（5级）：

        可重复级核心：建立基本的项目管理和实践来跟踪项目费用、进度和功能特性；有必要的过程准则来重复以前在同类项目中的成功。

        已定义级核心：使用标准开发过程（或方法论）构建（或集成）系统；

        管理级核心：管理层寻求更主动地应对系统的开发问题；

        优化级核心：连续地监督和改进标准化的系统开发过程

1、软件生命周期模型

1）、瀑布模型

        瀑布模型将开发阶段描述为从一个阶段瀑布办地转换到另一个阶段的过程。

2）、原型模型

        开发人员款苏地构造整个系统或者系统的一部分以理解或澄清问题。

3）、螺旋模型

        将开发活动和风险管理结合起来，以减小风险。螺旋模型综合了瀑布模型和演化模型的优点，增加了这两种模型忽略的风险分析。

4）、喷泉模型

        开发过程模型以需求为动力，以对象为驱动，适合于面向对象的开发方法。

 2、软件生命周期各活动任务

        （1）可行性分析和项目开发计划主要确定软件的开发目标及其可行性，要进行问题定义、可行性分析，指定项目开发计划。

        （2）需求分析阶段，的任务时准确地确定软件系统必须要做什么，确定软件系统必须具备哪些功能。

        需求分析的产物：《软件需求规格说明书》

        （3）软件设计，是团建工程的技术核心，其任务时确定如何实现软件系统，包括模块分解，确定软件的结果，模块的功能和模块直接的接口，以及全局数据结构的设计，设计每个模块的实现细节和局部数据结构。

        详细设计主要任务：

        （1）对每个模块进行详细的算法设计。

        （2）对模块内的数据结构进行设计。

        （3）对数据库进行物理设计，即确定数据库的物理结构。

        （4）其他设计。根据软件系统的类型，还可能要进行一下设计：

                a.代码设计。b.输入输出设计。c.用户界面设计。

        （5）编写详细设计说明书。

        （6）评审。

          概要设计（软件系统设计）的主要任务：

         （1）确定模块之间的接口。

         （2）设计软件系统总体结构。

         （3）

        概要设计的产物：《概要设计说明书》

        （4）编码的任务，是用某种程序设计语言为每个模块编写程序。

         例题：确定采用哪种软件体系结构是在（C）阶段进行的。

（A） 需求分析                  （B） 概要设计                  （C） 详细设计                  （D）软件实现