软件工程

软件工程

软件：软件是指计算机系统中的程序及其文档。

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

软件危机：软件生产率、软件质量远远满足不了社会发展的需求，成为社会，经济发展的制约因素，人们通常把这一现象称为“软件危机”。

软件开发的本质就是实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射。

实施软件开发的基本途径是系统建模。所谓系统建模，是指运用所掌握的知识，通过抽象，给出该系统的一个结构——系统模型。

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

软件开发中所涉及的模型可分为两大类，一类称为概念模型，描述了系统是什么；另一类统称为软件模型，描述了实现概念模型的软件解决方案。

软件开发所涉及的两大类技术：一是求解软件的开发逻辑，二是求解软件的开发手段。

软件需求

软件需求以一种技术形式，描述了一个产品/系统应该具有的功能、性能和其它性质。

需求定义：一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统功能上的能力、性能参数或其他性质。

需求分类：1.功能需求 2.非功能需求

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

非功能需求：非公能需求是性能需求、外部接口需求、设计约束和质量属性这4类需求的统称。

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

需求的基本性质：

1） 必要的，该需求是用户所要求的。

2）无歧义的，该需求只能用一种方式解释。

3）可测的，该需求是可进行测试的。

4）可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段。

5）可测量的，该需求是可测量的。

需求规约的基本性质：

1）重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级。

2）可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。

3）完整的：没有被遗漏的需求。

4）一致的：不存在互斥的需求。

需求发现技术：有5种常用的需求发现技术，自悟、交谈、观察、小组会和提炼。

需求规约的3种基本形式：

（1） 非形式化的需求规约。非形式化的需求规约即以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。

（2） 半形式化的需求规约。半形式化的需求规约即以半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约。

（3） 形式化的需求规约。形式化的需求规约即以一种基于良构数学概念的符号体系来编制需求规约，一般往往伴有解释性注释的支持。

软件需求规约的内容有：引言、总体描述、特定需求、附录、索引。

需求规约的作用可概括为以下4点：

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

     2）对于项目的其余大多数工作，需求规约是一个管理控制点。

     3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。

     4）需求规约是创建产品验收测试计划和用户指南的基础。

需求规约和项目需求的不同：

需求规约和项目需求是两个不同的概念。需求规约是软件开发组织和用户之间一份事实上的技术合同书，即关注产品需求，回答“交付给客户的产品/系统是什么”；而项目需求是客户和开发者之间有关技术合同——产品/系统需求的理解，应记录在工作陈述中或其他某一项目文档中，即关注项目工作与管理，回答“开发组要做的是什么”。

结构化方法

需求分析：一般来说，分析是系统地使用信息，对一个问题的估算。软件需求分析是这一概念的特化，即系统化地使用“数据流”、“加工”、“数据存储”、“数据源”和“数据潭”等术语所表达的信息，对待建系统“是什么”给出一个估算――系统概念模型。

需求分析工作面临的三大挑战：1、问题空间理解；2、人与人这间的通信；3、需求的变化性。

软件设计：在需求分析的基础上，定义满足需求所需要的结构，即针对给定的问题，给出该问题的软件解决方案，确定“怎么做”的问题。

结构化方法基本术语：数据流、加工、数据存储、数据源和数据潭。

数据流图：表达功能模型的工具，即数据流图（Dataflow Diagram） 简称DFD图，简单的说，DFD图是一种描述数据变换的图形化工具，其中的元素可以是数据流、数据存储、加工、数据源和数据潭等

变换型数据流图：具有较明显的输入部分和变换（主加工）部分之间的界面变换部分和输出部分之间界面的数据流图

事务型数据流图：数据到达一个加工T，该加工T根据输入数据的值，在其后的基干动作序号（称为一个事务）中选出一个来执行

模块：执行一个特殊任务的一个过程以及相关的数据结构

控制域：模块本身以及所有直接或间接从属于它的模块的集合。

作用域：受该模块内的一个判定所影响的所有模块的影响

常见模块耦合类型：内容耦合、公共耦合、控制耦合、标记耦合、数据耦合等；(耦合内聚全部类型)

设计原则：如果模块间必须存在耦合，就尽量使用数据耦合，少用控制耦合，限制公共耦合，避免内容耦合

软件体系结构图主要有三种：1、模块结构图（MSD图）；2、层次图；3、HIPO图。

详细设计工具：1、程序流程图；2、盒图（N-S图）；3、PAD图。

HIPO图是由H图和IPO图两部分组成，H图就是层次图，IPO即为模块的输入/处理/输出。

面向对象-UML 

UML是软件需求规约、设计和实现的工具。

UML八大术语：类与对象、接口、协作、用况、主动类、构件、制品、节点。

四个关系：关联(association)、泛华(generalization)、细化/实现(realization)、依赖(dependency)。

图：结构图、行为图

结构图：类图、对象图、构件图、包图、部署图、组合结构图

行为图：usecase图、活动图、状态图、交互图（顺序图、通信图、交互概观图、定时图）

统一软件过程(RUP)

UML是一种可视化的建模语言，而不是一种特定的软件开发方法学。作为一种软件开发方法学，为了支持软件开发活动，例如软件设计，至少涉及三方面的内容：一是应定义设计抽象层，即给出该层的一些术语(用于表达基本信息的术语)，二是应给出该层的模型表达工具(用于组织基本信息的表达格式)，三是应给出如何把需求层的模型映射为设计层的模型，即过程(不同抽象层之间的映射)。UML仅包括前两方面的内容，即给出了一些可用于定义软件开发各抽象层的术语（符号），给出了各层表达模型的工具。

RUP的本质

本质: 是“一般的过程框架 ” . 即:
--为软件开发，进行不同抽象层之间“映射”，安排其开发活动的次序，指定任务和需要开发的制品，提供了指导；
--为对项目中的制品和活动进行监控与度量，提供了相应的准则。

换言之，RUP比较完整地定义了将用户需求转换成产品所需要的活动集，并提供了活动指南以及对产生相关文档的要求。
适用于：大多数软件系统的开发，涉及
-不同应用领域 -不同类型的组织
-不同的技能水平 -不同的项目规模
可见, RUP 和UML 是“统一”的方法学。

RUP的特点

是一种以用况（Use Case）为驱动的、以体系结构为中心的、迭代、增量式开发。

软件测试

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

两种常用的软件测试技术：基于程序路径的“白盒”测试技术和基于规约的“黑盒”测试技术；“白盒”测试技术，又称为结构测试技术，典型的是路径测试技术；“黑盒”测试技术，又称为功能测试技术，包括基于事务流的测试技术、状态测试技术、定义域测试技术、等价类划分、边界值分析、因果图。

测试的目标：1、预防错误；2、发现错误；

软件测试过程模型：环境模型、对象模型和错误模型；

路径测试技术的策略：语句覆盖、分支覆盖、条件覆盖和条件组合覆盖、路径覆盖。

语句覆盖：设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。

判定覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。

条件覆盖：设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。

判定/条件覆盖：设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断中的每个条件的可能取值至少执行一次。 

条件组合覆盖：设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。

路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径。

测试覆盖的基本关系：语句覆盖<分支覆盖<条件组合覆盖<…路径覆盖。

步骤：单元测试、集成测试、有效性测试、系统测试。
单元测试，关注每个独立的模块。
集成测试，关注模块的组装。
有效性测试，关注检验是否符合用户所见的文档。
系统测试，关注检验系统中所有元素之间的协作是否合适，整个系统的性能、功能是否达到。

软件生存周期过程与管理

软件生存周期模型主要包括：瀑布模型，增量模型，演化模型，螺旋模型，喷泉模型。

瀑布模型将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到产品。适应情况：需求已被很好的理解，并且开发组织非常熟悉为实现这一模型所需求的过程。

瀑布模型

优点：1、可强迫开发人员采用规范化的方法；2、严格地规定了每个阶段必须提交的文档；3、要求每个阶段交出的所有产品都必须是经过验证的。

缺点：1、由于瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要；2、瀑布模型只用于开始时需求已确定的情况。

增量模型

优点：1、第一个可交付版本所需要的成本和时间是较少的，从而可减少开发由增量表示的小系统承担的风险；2、由于很快发布第一个版本，因此可以减少用户需求的变更；3、允许增量投资，即在项目开始时可以仅对一个或两个增量投资。

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

演化模型：主要针对事先不能完整定义需求的软件开发。

螺旋模型：是瀑布模型与演化模型的基础上，加入两者所忽略的风险分析所建立的一种软件开发模型。

螺旋模型与其它模型之间的主要区别

1、螺旋模型关注解决问题的基本步骤，即标识问题，标识一些可选方案，选择一个最佳方案，遵循动作步骤并实施后续工作，突出特征，在开发的迭代中实际上只有一个迭代过程真正开发了可交付的软件；

2、与深化模型和增量模型相比，同样使用了瀑布模型作为一个嵌入的过程，即分析、设计、编码、实现和维护的过程，并且在框架和全局体系结构方面是等同的。但是，螺旋模型所关注的阶段以及它们的活动是不同的，如增加一些管理活动和支持活动。尽管增量模型也有一些管理活动，但它基于以下假定：需求是最基本的、并且是唯一的风险源，因而在螺旋模型中增大了决策和风险的空间，螺旋模型扩大了增量模型的管理范围。

3、如果项目的开发风险很大或客户不能确定系统需求，在更广泛的意义上来讲，还包括一个系统或系统类型的要求，这时螺旋模型就是一个好的生存周期模型。

喷泉模型：主要用于支持面向对象技术的软件开发。

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

能力成熟度模型(Capability Maturity Model)

集成化能力成熟度模型是以下三个模型的演化结果：软件能力成熟度模型(SW-CMM)、集成产品开发能力成熟度模型(IPD-CMM)和系统工程能力模型(SECM)。

CMMI基本思想：该模型基于过程途径思想，通过过程把软件质量的3个支撑点——受训的人员、规程和方法、工具和设备进行集成，以开发所期望的系统/产品。为此，CMMI紧紧围绕开发、维护和运行，把经过证明的“最佳实践”放在一个结构中

CMMI的模型部件：过程域、专用目标、共用目标、专用实践、共用实践、典型工作产品、共用实践的精化、子实践、意图陈述、简介性注释、相关过程域

能力等级：是指单一过程域中已达到的过程改善，能力等级是为了管理，对过程改善程序所设定的几个“台阶”。

六个能力等级：0级：未完成级；1级：已执行级；2级：已管理级；3级：已定义级；4级：已定量管理级；5级：持续优化级。

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

成熟度等级：是指达到预先定义的一组过程域所有目标的一种过程改善等级。可以说，一个成熟度等级是由预先定义的一个过程域集及其相关的一些专用实践和共用实践组成的。

五个成熟度等级：1级：初始级；2级：已管理级；3级：已定义级；4级：已定量管理级；5级：持续优化级。

每一成熟度等级所包含的过程域

1级：无组织管理。2级：包含7个过程域：配置管理、测量与分析、项目监控、项目规划、过程和产品质量保证、需求管理、提供方协议管理。3级：包含11个过程域：决策分析与解决、集成项目管理、组织过程定义、缓缓过程关注、组织培训、产品集成、需求开发、风险管理、技术解决方案、验证、确定。4级：组织过程性能和定量项目管理。5级：原因分析与解决和组织创新

流程图：一个开始多个结束

协作图：多个事物之间通信有返回包