软件工程期末复习

软件工程

一、 软件工程概述

软件工程定义：

Software Engineering is a discipline which researches software production, that is, sound engineering principles applied to economically
produce reliable and effective in the actual machine running the software
软件工程是指研究软件生产的一门学科，也就是将完善的工程原理应用于经济地生产既可靠又能在实际机器上有效运行的软件。

software engineering : software engineering are the system approaches which develops, operates, maintains and repairs the software, the “software” is defined as: computer programs, methods, rules,
related documentation, as well as the necessary data which runs on the computers.
软件工程是开发、运行、维护和修复软件的系统方法，其中“软件”的定义为：计算机程序、方法、规则、相关的文档资料以及在计事机上运行时所必需的数据。

软件生存期定义 The Survival of software

As any other things, the software also has a survival of the process of gestation, birth, growth, maturity, decline and fall, commonly called as As any other things, the software also has a survival of the process of gestation, birth, growth, maturity, decline and fall, commonly called as computer software survival.
如同任何其他事物一样，软件也有一个孕育、诞生、成长、成熟、衰亡的生存过程，一般称之为计算机软件的生存期。
In general, the survival of software is composed of three phases of software definition, software development and* software maintenance*, each phase can be further divided into several stages.
一般说来，软件生命期由软件定义、软件开发和软件维护三个时期组成，每个时期又可进一步划分成若干个阶段。

常用的软件过程模型

1. 瀑布模型 *
   The “waterfall” model (瀑布模型):The software life cycle
   activities are defined as numbers of stages of work which in
   accordance with a fixed order to connect, like the water falls,
   and ultimately get software products.
   
   （1）阶段间具有顺序性和依赖性
   ①必须等前一阶段的工作完成之后，才能开始后一阶段的工作；
   ②前一阶段的输出文档就是后一阶段的输入文档
   （2） 推迟实现的观点
   瀑布模型在编码之前设置了系统分析与系统设计阶段
   （3）质量保证的观点
   ①每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
   ②每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

优点：可强迫开发人员采用规范的方法（例如，结构化技术）； 严格地规定了每个阶段必须提交的文档；要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证。
缺点:它是一种文档驱动的模型，几乎依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。

2. 快速原型模型
   The Rapid Prototyping is a program which is setup quickly and can run on the computer, its functions is often a subset of the whole functions of the final product.

快速原型：是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

3. 增量模型 Incremental model
一个编辑软件的开发过程：
第一个增量构件：往往实现软件的基本需求，提供最核心的功能。
第二个增量构件：提供更完善的编辑和文档生成功能
第三个增量构件：实现拼写和语法检查功能；
第四个增量构件：完成高级的页面排版功能。
特点：能在较短时间内向用户提交可完成部分工作的产品；逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。

4. 螺旋模型 Spiral model
   Is the cycle of increased risk analysis process of rapid prototype model
   循环的、增加了风险分析过程的快速原型模型
   
   · 软件重用：有利于已有软件的重用；
   · 减少风险：减少了过多测试或测试不足所带来的风险；
   · 维护与开发：因为维护只是模型的另一个周期，在维护和开发之间并没有本质区别；
   · 应用领域：主要适用于内部开发的大规模软件项目。

5. 喷泉模型*Fountain Model
   喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。
   
   该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分。无间隙指在各项活动之间无明显边界，如分析和设计活动之间没有明显的界限，由于对象概念的引入，表达分析、设计、实现等活动只用对象类和关系，从而可以较为容易地实现活动的迭代和无间隙，使其开发自然地包括复用。

喷泉模型的优点
喷泉模型不像瀑布模型那样，需要分析活动结束后才开始设计活动，设计活动结束后才开始编码活动。该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程

喷泉模型的缺点
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。

6. RUP模型
   Rational 统一过程（ Rational Unified Process）
   开发过程可以用二维结构或沿着两个坐标轴来表达：
   1)横轴代表了制订开发过程时的时间，体现了过程的动态结构。它以术语周期（cycle）、阶段(phase)、迭代（iteration）和里程碑(milestone)来表达。
   2）纵轴表现了过程的静态结构：如何用术语活动（activity）、产物(artifact)、 角色(worker)和工作流(workflow)来描述。

时间轴—代表阶段和迭代
------- 这是开发过程沿时间的动态组织结构。
------- 软件生命周期被分解为周期，每一个周期工作在产品新的一代上。Rational Unified Process将周期又划分为四个连续的阶段。
------- 初始阶段、细化阶段、构造阶段、交付阶段
------- 每个阶段终结于良好定义的里程碑–某些关键决策必须做出的时间点，因此关键的目标必须被达到。
------- 每个阶段均有明确的目标

二、问题定义

问题定义的任务

Part 1: a clear background, the development of the system, the status quo, the development of the reasons and conditions
Part 2: system requirements, general requirements, the nature, the type and the scope of the problem, the target of the project
Part 3: function’s scale, the solution of the project, the development conditions, and environmental requirements, and so on
Part 4: and then, write a report on the definition of the problem (or system definition of the report) for the feasibility study.
Part1: 明确问题的背景、开发系统的现状、开发的理由和条件
Part 2: 开发系统的问题要求、总体要求、问题的性质、类型、范围、要实现的目标
Part 3: 功能规模、实现目标的方案、开发的条件、环境要求等等
Part 4: 然后写出问题定义报告（或称系统定义报告），以供可行性分析阶段使用。

可行性分析的主要内容

1. The task: the task is to study the feasibility of using the minimum price in the shortest possible time to determine whether the problem can be solved.
   任务：可行性研究的任务是用最小的代价、在尽可能短的时间内确定问题是否能够解决。
2. The principle: After clarifying the definition of the problem, analysts must first export the logical model, and then from the logic of the system model, to explore a number of options for the main solution (that is, the system program). Finally, examine the feasibility of each solution.
   方法：在澄清了问题定义之后，分析员首先应该导出系统的逻辑模型，然后从系统逻辑模型出发，探索出若干种可供选择的主要解法（即系统实现方案）。最后仔细研究每种解法的可行性。

• (1) technical feasibility: the ability of using existing technology to complete the project.
  (2) economic feasibility: by cost-benefit analyzing, ensure the benefit will be greater than the cost of the future system.
  (3) Operation feasibility: users can use the system comfortable.
  (4) social factors to consider: judge whether the software development is infringement or illegal.

一般说来，研究可行性应该从下述几方面进行：
技术可行性，使用现有的技术能实现这个系统吗?
经济可行性，这个系统的经济效益能超过它的开发成本吗?
操作可行性，系统的操作方式在这个用户组织内行得通吗?
社会和法律可行性，软件开发是否会侵犯他人、集体或国家的利益，是否违反国家的法律并可能由此而承担法律责任。

三、需求工程

需求工程分析阶段的任务

• Task 1
  to determine the comprehensive requirements of system
  * Functional requirements
  * performance requirements
  * reliability and availability requirements * Error processing requirements
  * Interface requirements
  * Constraint * Reverse demand
  * the future requirement

确定对系统的综合要求
功能需求、性能需求、可靠性和可用性需求
出错处理需求、接口需求、约束
逆向需求、将来可能提出的要求

• Task 2

analysis system data requirements
. Using Data structure to describe logic between data elements
. Using data dictionary to define data fully and accurately
· Using graphic tools to describe data structure * Level block diagram * Warnier map

分析系统的数据要求
. 数据结构表示数据元素之间的逻辑关系 . 利用数据字典可以全面准确地定义数据 . 辅助描绘数据结构工具 * 层次方框图 * Warnier图

• Task 3
  export system logic model
  Based on results upward,produce System logic model, DFD, E-R Diagram, state transition map, DD and the main processing algorithms to describe the logic model

导出系统的逻辑模型
综合上述两项分析的结果导出系统逻辑模型
数据流图、实体-联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型

• Task 4
  to amend the system development program

修正系统开发计划和工程进度表。
重新估计对各类开发人员和各种资源的需要情况
指明什么时候使用以及使用多长时间。
重新估计系统生命周期每个阶段的成本。
修正项目开发全过程的详细进度表和成本估计。

需求分析的工作步骤

• to communicate with users （沟通）
  * Step 1 访谈
  * Step 2 面向数据流自顶向下求精 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。
  * Step 3 简易的应用规格说明技术
  * Step 4 快速建立软件原型
• Creating Data Model — E-R图
• Creating Functional Model – DFD
• Creating Behavior Model – 状态转换图
• Analyzing and Modeling, repeatly (反复修订)
• Writing reports and specifications (书写文档）

数据流图

用例图

三、软件概要设计

软件设计的启发式规则有哪些

(1) to improve the software architecture to enhance the independence of modules
改进软件结构提高模块独立性
(2) Module scale should be moderate
模块规模应该适中 (通常不超过60行语句)
(3) the depth, width, and the fan-in-fan-out should be moderate
深度、宽度、扇出和扇入应适中

深度表示软件结构中控制的层数，它往往能粗略地标志一个系统的大小和复杂程度。
宽度是软件结构内同一个层次上的模块总数的最大值。一般宽 度越大越复杂。
扇出是指一个模块直接控制(调用)的模块数目，扇出过大则宽增加；扇出过小(例如总是1)深度增加。通常取3或4。扇出太大时应该适当增加中间层次的控制模块。
扇入表明有多少个上级模块直接调用它，扇入越大则共享该模块的上级模块数目越多

(4) module scope should be in the control
模块的作用域应该在控制域之内

模块的作用域：受该模块内一个判定影响的所有模块的集合。
模块的控制域：是这个模块本身以及所有直接或间接从属于它的其它模块的集合。
要求：最好仅限于自身及它的直属下级模块。

(5) strive to reduce the complexity of the module interface
力争降低模块接口的复杂程度
(6) design the module with single entrance, single export
设计单入口、单出口的模块
(7) module’s function should be predicted
模块功能应该可以预测

• 如果一个模块可以当做一个黑盒子，也就是说，只要输入的数据相同就产生同样的输出，这个模块的功能就是可以预测的。

耦合和内聚的7种形式

Coupling is connected between the modules close degree of measurement. 耦合是模块之间的互相连接的紧密程度的度量。
Cohesion is a module strength (a module within the various elements combine to work closely with each other level) measurement. 内聚是模块功能强度(一个模块内部各个元素彼此结合的紧密程度)的度量。
Module independence of the modules should be relatively strong cohesion and low coupling module.
模块独立性比较强的模块应是高内聚、低耦合的模块
1. 耦合

• Nondirect Coupling （非直接耦合）
  如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最强。
• 数据耦合 (Data Coupling)如果一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的，则称这种耦合为数据耦合。
• 标记耦合 (Stamp Coupling)如果一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。
• Control coupling （控制耦合）：
  如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
• 外部耦合（External Coupling）一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
• 公共耦合（Common Coupling）若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
  公共耦合的复杂程度随耦合模块的个数增加而显著增加。若只是两模块间有公共数据环境，则公共耦合有两种情况。松散公共耦合和紧密公共耦合。
• 内容耦合 (Content Coupling)：
  如果发生下列情形，两个模块之间就发生了内容耦合 (1) 一个模块直接访问另一个模块的内部数据; (2) 一个模块不通过正常入口转到另一模块内部; (3) 两个模块有一部分程序代码重迭(只可能出现在汇编语言中); (4) 一个模块有多个入口
• 内聚
  - 功能内聚 (Functional Cohesion)：
  一个模块中各个部分都是完成某一具体功能必不可少的组成部分，或者说该模块中所有部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。则称该模块为功能内聚模块。
• 信息内聚 (Informational Cohesion)
  这种模块完成多个功能，各个功能都在同一数据结构上操作，每一项功能有一个唯一的入口点。这个模块将根据不同的要求，确定该执行哪一个功能。由于这个模块的所有功能都是基于同一个数据结构（符号表），因此，它是一个信息内聚的模块。
• 通信内聚 (Communication Cohesion)：
  如果一个模块内各功能部分都使用了相同的输入数据，或产生了相同的输出数据，则称之为通信内聚模块。通常，通信内聚模块是通过数据流图来定义的。
  - 过程内聚（Procedural Cohesion）：
  使用流程图做为工具设计程序时，把流程图中的某一部分划出组成模块，就得到过程内聚模块。例如，把流程图中的循环部分、判定部分、计算部分分成三个模块，这三个模块都是过程内聚模块。
• 时间内聚（Temporal Cohesion）：
  时间内聚又称为经典内聚。这种模块大多为多功能模块，但模块的各个功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。例如初始化模块和终止模块。
• 逻辑内聚（Logical Cohesion）：
  这种模块把几种相关的功能组合在一起，每次被调用时，由传送给模块的判定参数来确定该模块应执行哪一种功能。
• 巧合内聚（Coincidental Cohesion ）：
  巧合内聚又称为偶然内聚。当模块内各部分之间没有联系，或者即使有联系，这种联系也很松散，则称这种模块为巧合内聚模块，它是内聚程度最低的模块。

画软件结构图*

画类图*

画状态转换图*

五 、软件详细设计

画程序流程图*

NS图*

PAD图*

流图*

计算环形复杂度*

六、软件测试

软件测试定义

The definition of software testing:
Software testing is a procedure to find errors in program.

测试的定义：为了发现程序中的错误而执行程序的过程。

黑盒测试法与白盒测试法定义

Black Box Testing : Program is tested according to the requirement specification without considering the internal structure of program.

黑盒测试法：黑盒测试时完全不考虑程序内部的结构和处理过程，只按照规格说明书的规定来检查程序是否符合它的功能要求。黑盒测试是在程序接口进行的测试，又称为功能测试。

white-box testing :
Program is tested according to the internal structure of program. Programmer must know the program in detail.

白盒测试: 将程序看作是一个透明的盒子，也就是说测试人员完全了解程序的内部结构和处理过程。所以测试时按照程序内部的逻辑测试程序、检验程序中的每条通路是否都能按预定的要求正确工作。白盒测试又称为结构测试。

软件可靠性定义

软件可靠性的定义
software reliability：
Software Reliability is the probability of success running in a period of time, in accordance with the requirement specification.
软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。

等类划分法和边界值分析法设计测试用例*

• 等价类划分
  原理：等价类的划分在很大程度上依靠的是测试人员的经验，下面给出几条基本原则：
  （1）输入条件的取值范围 （2）输入数据的个数限定
  （3）相同处理的一组输入 （4）无效的等价类
  （5）空值检查

划分等价类的标准：
1)完备测试、避免冗余;
2)划分等价类重要的是：集合的划分;
并是整个集合：完备性;
子集互不相交：保证一种形式的无冗余性;
3)同一类中标识（选择）一个测试用例，同一等价类中，往往处理相同，相同处理映射到"相同的执行路径"。

• 边界值分析

Different from Equivalent Class Partitioning Technology, design test-case using values which is equal, greater, less than the boundary value.

选取恰好等于、小于和大于边界的值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。

选取恰好等于、小于和大于边界的值作为测试数据，而不是选取每个等价类内的典型值或任意值作为测试数据。
选择测试用例的原则：
一、如果输入条件规定了值的范围，则应该取刚达到这个范围的边界值，以及刚刚超过这个范围边界的值作为测试输入数据；
二、如果输入条件规定了值的个数，则用最大个数、最小个数、比最大个数多1个、比最小个数少1个的数做为测试数据；

逻辑覆盖法和基本路径测试法设计测试用例*

• Logical Coverage Method (逻辑覆盖法) is a typical white-box testing technology. It includes following conditions:
  它要求测试人员十分清楚程序的逻辑结构，考虑的是测试用例对程序内部逻辑覆盖的程度。根据覆盖的目标，逻辑覆盖又分为：

  • 条件组合覆盖：

  • Statement coverage语句覆盖
    语句覆盖就是设计足够的调试用例，使得程序中的每个语句至少执行一次。

  • Decision Coverage 判定覆盖
    使得程序中每个判定的取“真”分支和取“假”分支至少都执行一次，判定覆盖又称分支覆盖。

  • Condition coverage 条件覆盖
    使得程序判定中的每个条件能获得各种可能的结果。

  • Decision / condition coverage 判定／条件覆盖
    使得判定中的每个条件都取到各种可能的值，而且每个判定表达式也都取到各种可能的结果。

  • Condition combination coverage条件组合覆盖
    条件组合覆盖就是设计足够的测试用例，使得每个判定中的条件的各种可能组合都至少出现一次。

• 基本路径法
  Method of Design logical coverage from Flow Chart. It is a basic white-box testing.利用流图导出逻辑覆盖的方法

基本路径测试法 :
利用流图导出逻辑覆盖的方法
Step 1. 从程序流程图导出控制流图（简称：流图）.
Step 2. 设计测试用例实现点覆盖使得程序执行路径至少经过流图的每个结点一次（点覆盖标准和语句覆盖标准是相同的）
确定环形复杂性度量V（G）
Step 3. 设计测试用例实现边覆盖
至少经过流图中每条边一次（边覆盖和判定覆盖是一致的）
Step 4. 设计测试用例实现路径覆盖
选取足够多测试数据，使程序的每条可能路径都至少执行一次(如果程序图中有环，则要求每个环至少经过一次)

七、软件维护

软件维护定义

软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。

软件的可维护性定义

Definition of software maintainability:
It is the difficulty level to understand and improve the software for maintenance personnel.

可维护性定性地定义为： 维护人员理解、改正、改动或改进这个软件的难易程度。

软件维护的种类

Types of software maintenance. (维护的种类)
Corrective maintenance
Adaptive maintenance
Improve maintenance
Preventive maintenance

改正性维护：把诊断和改正错误的过程。
适应性维护：也就是为了和变化了的环境适当地配合而进行的修改软件的活动，是既必要又经常的维护活动。
完善性维护：在使用软件的过程中用户往往提出增加新功能或修改已有功能的建议，还可能提出一般性的改进意见。
预防性维护：当为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件。

八、 软件管理

软件质量的定义

Software Quality (软件质量)
Software developed should be consistent with specific and connotative needs of the user.

概括地说，软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

软件的配置是什么

Software configuration item (软件配置项)
① programs;
② documents describing the programs ;
③ data

软件过程的输出信息可以分为3类：
①计算机程序（源代码和可执行程序）；
②描述计算机程序的文档（供技术人员或用户使用）；
③数据（程序内包含的或在程序外的）。
上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。

什么是软件配置管理

Software configuration management
软件配置管理是在软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来：
①标识变化；
②控制变化；
③确保适当地实现了变化；
④向需要知道这类信息的人报告变化。

基线

Baseline (基线)

Definition of Baseline : It is a template software or specification that has been pass the review. It also can be the base of future development and changed only by the formal quality control.

基线定义为： 已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。

能力成熟度模型，级别

能力成熟度模型的基本思想是，帮助软件开发机构建立一个有规律的、成熟的软件过程。改进后的软件过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。

The procedure goes improved 5 grade gradually. - The initial level (also known as 1 level)

• repeatable level (also known as 2 level)
• Defined level (also known as 3 level)
• manageable level (also known as 4 level)
• optimized level (also known as 5 level)

CMM把软件过程从无序到有序的进化过程分成5个阶段，并把这些阶段排序，形成5个逐层提高的等级。

• 初始级（又称为1级）
• 可重复级（又称为2级）
• 已定义级（又称为3级）
• 已管理级（又称为4级）
• 优化级（又称为5级）