软件工程导论（第6版）期末重点总结

一、软件工程概述
一句话：用工程的思想指导软件项目开发

软件危机：
计算机软件的开发和维护过程中遇到的一系列严重问题。这些问题或难题并不限于那些“不能正常运行”的软件。包括两方面的内容：如何开发软件，满足对软件日益增长的需求。如何维护数量不断膨胀的已有软件。
软件危机的典型表现：
(1)对软件开发成本和进度的估计常常不准确
(2)用户对“已完成的”软件系统不满意的现象经常发生
(3)软件产品的质量往往靠不住
(4)软件常常是不可维护的
(5)软件通常没有适当的文档资料
(6)软件成本在计算机系统总成本中所占的比例逐年上升
(7)软件开发生产的速率，跟不上计算机应用迅速普及深入的趋势
产生软件危机的原因：
软件本身的特点 2.软件人员本身的素质 3.硬件设计中的长期一贯制
软件本身的特点：逻辑产品；不会因为使用的时间过长而被“用坏”。
保证软件具有可理解性，可测试性，可修改性三种因素
软件生命周期的3个时期，8个阶段：
三个周期：软件定义，软件开发，和运行维护。
软件开发八个阶段：1问题定义2可行性研究3需求分析 4总体设计 5详细设计 6编码和单元测试7综合测试 8软件维护
软件生命周期6个阶段：可行性研究与计划、需求分析、设计、编程、测试、运行与维护
开发模型：
瀑布模型：计划期，开发期，运行期
原型模型：速原型模型Rapid Prototype Mod
增量模型：多模块，分阶段
螺旋模型：尽量降低风险，制定计划，风险分析，实施工程，客户评估
喷泉模型
Rational统一过程 迭代式开发
敏捷过程与极限编程
微软过程：零缺陷目标
问题定义 问题是什么？ 关于规模和目标的报告书
可行性研究 有可行的解吗？ 系统的高层逻辑模型：数据流图、成本／效益分析
需求分析 系统必须做什么？ 系统的逻辑模型：数据流图、数据字典、算法描述 需求规格说明书，用户需求说明书
总体设计 概括地说，应该如何解决这个问题？ 可能的解法： 系统流程图、成本/效益分析、推荐的系统结构：层次图或结构图 概要设计说明书，总体设计说明书
详细设计 怎样具体地实现这个系统？ 编码规格说明：HIPO图或 PDL
编码/单元测试 正确的程序模块 源程序清单；单元测试方案和结果
综合测试 符合要求的软件 综合测试方案和结果；完整一致的软件配置
维护 持久地满足用户需要的软件 完整准确的维护记录

二、可行性研究
目的：用最小的代价在尽可能短的时间内确定问题是否能够解决。

可行性研究包括哪些可行性： 技术，经济，运行，操作，法律
概念模型，逻辑模型，物理模型
系统流程图（描绘物理系统）：用图形符号以黑盒子形式描绘系统里面的每一个部件。包括程序、文件、数据库、表格、人工过程等。它表达了信息在系统各部件之间的流动情况。（整个系统处理事务的基本过程）

数据流图（描绘逻辑模型|DFD）：没有任何具体的物理元素。表示信息在系统中流动和处理的情况（子块之间数据传递）
由数据源点或终点（实体），变换数据的处理（过程），数据存储，数据流组成。
数据字典：（数据库中的对照表） 数据字典是关于数据信息的集合。数据字典是数据流图中所有元素（包括数据流、数据流分量\数据元素、数据存储、处理）严格定义的场所。
数据流图+数据字典=需求说明书
组成数据的方式：顺序，选择，重复，可选
成本\效益分析：
代码行技术、任务分解技术
货币的时间价值：现在值，将来值互换。利率：（1+i）^n
投资回收期：是工程累计的经济效益等于最初投资所需要的时间。
纯收入
投资回收率：年利率平均值
用途
实现
数据流图与系统流程图的区别
三、需求分析
需求分析的目的和任务：明确系统做什么。提出系统必须完成的全部所有功能。写出软件需求规格说明书。
对系统的综合要求：功能需求、性能需求、可靠性和可用性需求、出错处理需求、接口需求、约束、逆向需求、将来可能提出的要求。
实体-联系图（ER图）：实体（矩形），联系（菱形），属性（椭圆）
状态转换图：描述系统对内部或者外部事件响应
层次方框图：用树形结构的一系列多层次的矩形框描绘数据的层次结构。
IPO图：描述输入数据、处理数据和输出数据
结构化分析方法（SA）就是面向数据流自顶向下逐步求精进行需求分析的方法。简单实用，使用广泛的方法。它适用于分析大型的数据处理系统
控制复杂性：分解和抽象。分解：把大问题分割成若干个小问题，然后分别解决。抽象：抽出事物的本质特性，不考虑过多的细节。
“逐层分解”体现了分解和抽象的原则，它使我们不至于一下子陷入细节，而是有控制地逐步地了解更多的细节，这是有助于理解问题的。
SA方法采用了介于形式语言和自然语言之间的描述方式。

四、总体设计（概要设计）
目的：建立一个符合用户要求的软件系统.
任务：将软件需求转化为数据结构和软件的系统结构。是软件结构的建立过程。
基本任务：
·将软件系统划分成模块
·决定每个模块的功能
·决定模块的调用关系
·决定模块的界面，即模块间传递的数据
过程：
1．设想供选择的方案：需求分析阶段得出的数据流图是总体设计的根本出发点。
逻辑模型->物理模型
2．选取合理的方案
3．推荐最佳方案
4．功能分解
对于大型系统的设计一般分为两步：
结构设计 —— 总体设计阶段的任务
确定由哪些模块组成以及模块之间的关系
过程设计 —— 详细设计阶段的任务
确定每个模块的处理过程

5．设计软件结构：软件结构可以用层次图或者结构图来描述
6．数据库设计：设计数据库的表，表的结构就是数据的存储结构，对表中的数据进行操作。数据关系的复杂程度和数据量的大小决定数据库设计的难度。
7．制定测试计划
8．书写文档
9．审查和复审

总体设计通常由系统设计和结构设计两个阶段组成。系统设计阶段确定系统的具体实现方案，结构设计阶段确定软件的结构。
模块是数据说明、可执行语句等程序对象的集合，它是单独命名的，可通过名字来进行访问。
一个模块具有输入和输出、功能、内部数据和程序代码等四个特性。
模块化：先分解，再集成
软件模块化设计的指导思想是分解、抽象、逐步求精、信息隐蔽和模块独立性。
模块独立的概念：
模块化，抽象，信息隐藏和局部化
信息隐藏：一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。
局部化：是指把一些关系密切的软件元素物理地放得彼此靠近。
独立性作用：模块化程度较高的软件容易编制，容易测试和维护。
模块的独立程度定性度量标准：耦合和内聚
耦合：两个模块完全独立，数据耦合，控制耦合，公共环境耦合，内容耦合
数据耦合：交换的信息只有数据
控制耦合：交换的信息中有控制信息
公共环境耦合： 两个模块之间通过一个公共数据环境进行数据的存取
内容耦合：包括：一个模块访问另一个模块的内部数据；一个模块不通过正常入口而转到另一个模块的内部；代码重叠；多个入口
<注>尽量使用数据耦合，少用控制耦合，限制公共环境耦合的范围，完全不用内容耦合。

内聚：
偶然内聚，逻辑内聚：逻辑上相似，时间内聚：必须在同一时间执行
过程内聚：处理元素相关，通信内聚：模块中所有的元素都使用相同的数据结构
顺序内聚： 一个模块中所有处理元素都是为完成同一功能而必须执行的
功能内聚：所有处理元素都完成一个，而且仅完成一个功能

启发规则：模块提高独立性，大小适中，深度，宽度，扇入，扇出
软件结构一般要求顶层扇出较大，中层扇出较少，底层扇入较大为好。
力争降低模块接口的复杂程度
设计单入口单出口的模块
描绘软件结构的图形工具：HIPO图（层次，输入，处理，输出），结构图
结构图描述了程序的模块结构，表示了一个系统的层次分解关系，反映了块间联系和块内联系等特征及控制信息的传递关系。
软件结构的标准形式：变换型、事务型
变换型：数据流图基本上线性，明显地分为输入，加工，输出三部分。
事务型：数据流图呈辐射状，事务中心将它的输入分离成若干种发散的数据流，选择其中一条路径处理。
软件结构设计优化：在满足信息要求的情况下，力求做到在有效结构之下，使模块最少，接口最简单。
·在不考虑时间因素的前提下开发并精化软件结构
·在详细设计阶段选出最耗费时间的那些模块，仔细地设计它们的处理过程，以求提高效率
·使用高级程序设计语言编写程序
·在软件中孤立出那些大量占用处理机资源的模块
·必要时重新设计或用依赖于机器的语言重写上述大量占用资源的模块的代码，以求提高效率

五、详细设计
详细设计的内容：
·给出软件结构中各个模块内部过程的描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。
详细设计的任务：
·确定每个模块的算法
·确定每一个模块的数据组织
·确定每个模块的接口
·为每个模块设计一组测试用例
根本目标：确定应该怎样具体地实现所要求的系统（设计出程序的蓝图）
结构程序设计
经典定义：代码块仅仅通过顺序，选择，循环这三种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口。
全面定义：尽可能少用GO TO语句，金浩尽在检测出错误时才使用GO TO语句，并且工改总是使用前向GO TO语句。
LEAVE BREAK结构实质上是受限制的前向GO TO语句
经典的结构程序设计：只用顺序，IF_THEN_ELSE,DO_WHILE三种基本控制结构
扩展的结构程序设计：还允许使用DO_CASE多分支结构和DO_UNTIL循环结构
修正的结构程序设计：再允许LEAVE和BREAK

结构化程序基本特征：一个入口，一个出口，程序中无死语句，无死循环
结构设计是一种应用最广泛的系统设计方法，是以数据流为基础、自顶向下、逐步求精和模块化的过程。
结构化程序设计应遵循的基本原则：
·采用自顶向下、逐步求精的模块化方法设计程序
·尽量使用基本结构编程
·限制转向语句的使用
详细设计的工具：
·程序流程图（程序框图）
·盒图（N-S图）
·PAD图（problem analysis diagram问题分析图）
·判定表
·判定树
·过程设计语言（PLD 伪码）：用正文形式表示数据和处理过程
面向数据结构的设计方法
Jackson图（描述数据结构）：三种基本的层次结构：顺序，选择，重复

六、实现（综合+选择）
通常把编码和测试统称为实现
任务：编码的任务是为每个模块编写程序，也就是说将详细设计的结果转换成用某种程序设计语言写的程序。
编程水平=代码风格（清晰>效率）+编程效率
序言性注释出现在模块的首部，其内容一般包括：
·有关模块功能的说明
·界面描述。包括调用语句格式，所有参数的解释和该模块需调用的模块名等。
·一些重要变量的使用、限制和一些其它信息。
·开发历史。如作者、复查者、复查日期、修改日期和叙述等。
描述性注释：嵌在程序之中。包括功能性和状态性。
功能性注释说明程序段的功能，通常可放在程序段之前。
状态性注释说明数据的状态，通常可放在程序段之后。
·注释应该与程序一致
·注释应该提供一些从程序本身难以得到的信息，而不是重复程序语句
·是对语句段做注释，而不是对每个语句作注释
提高程序效率的根本途径在于设计阶段选择良好的数据结构和算法。

测试的根本目标：尽可能多的发现并排除软件中隐藏的错误，最终把一个高质量的系统原件交给用户使用。
好的测试：极可能发现迄今为止尚未发现的错误的测试方案
成功的测试：发现了迄今为止尚未发现的错误的测试
测试不能证明程序的正确的
测试准则:
1.追溯到用户需求
2.尽早开始
3.Pareto原理：测试发现的错误中的80%很可能是由程序中20%的模块造成的
4.小规模->大规模
5.穷举测试是不可能的
6.由独立的第三方从事测试工作
测试方法：
黑盒：知道产品应该具有的功能，在程序接口进行测试，功能测试
<注>如果想用黑盒法发现程序中所有的错误，则必须用输入数据的所有可能值来检查程序是否都能产生正确的结果。
白盒：知道产品的内部工作过程，知道程序的结构和处理算法，按照程序内部的逻辑测试程序，结构测试。
<注>使用白盒法时还应该认识到：即使试遍所有的路径，仍不能保证程序符合它的功能要求，因为程序中有些错误是与数据有关的。
测试步骤：
1.模块测试（单元测试）
2.子系统测试（集成测试1）
3.系统测试（集成测试2）
4.验收测试（交付测试）：使用实际数据（系统将来要处理的信息）进行测试，通常由用户来做，
5.平行运行：同时运行新开发出来的系统和将被它取代的旧系统
软件测试过程：（基础：需求分析阶段产生的软件需求规格说明书）
·单元测试：
集中检测软件设计的最小单元------模块
·集成测试：在装配的过程中对组装的模块进行测试，包括了子系统测试和系统测试两个过程。
自顶向下
自底向上
·确认测试（验收测试）：任务：软件的有效性。基础：软件有效的标准
目标：检查系统的功能、性能要求是否已达到用户所要求的那样，文档资料是否正确、完整，系统的可移植性、兼容性、错误的恢复能力和易维护性等是否满足。

Alpha和Beta测试

设计测试方案（设计测试用例）：
逻辑覆盖法\路径覆盖法（白盒测试）： 逻辑覆盖是以程序内部逻辑为基础的测试技术，它考虑测试用例对程序内部逻辑覆盖的程度。
语句覆盖：走遍每个方框
判定覆盖（分支覆盖）：走遍每一条线
条件覆盖：选过每个条件，进行组合
判断/条件覆盖：同时满足前两种覆盖标准，但不一定强于条件覆盖
条件组合覆盖：覆盖标准最强。每种组合至少出现一次。

等价划分法（黑盒测试）：每类中的一个典型值在测试中的作用与这一类中所有其他值的作用相同。
等价类划分是用黑盒法设计测试用例的一种技术。把所有可能的输入数据（有效的和无效的）划分成若干个等价类，从每个等价类中只取一组数据作为测试数据。选取少量的有代表性的输入数据，以较小的代价暴露出较多的程序错误。
先划分等价类（给等价类编号）（有效等价类、无效等价类），再设计测试用例。

边界值分析法（黑盒测试）：使用刚好等于、小于或大于边界值的数据来进行测试，有较大的可能发现错误。
错误推测技术
调试：
目标：寻找如啊年错误的原因并改正错误
蛮干法
回溯法
原因排除法：对分查找法，归纳法，演绎法
软件可靠性
定义：程序在给定的时间间隔内，按照规格说明书的规定成功运行的概率。
软件可用性的定义：程序在给定的时间点，按照规格说明书的规定，成功运行的概率。
MTTF：软件的平均无故障时间（mean time to failures）
MTTF=
1/K*(测试前错误总数/程序长度-改正的错误总数/程序长度)
估计错误总数的方法：
植入错误法
分别测试法
七、维护
维护：
在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。是软件生存周期的最后一个阶段，它是在软件交付使用之后，为了改正错误或满足新的要求而修改软件的过程，因此不属于系统开发过程。
维护分类：
改正性维护：改正错误（21%），不会导致文档的修改
适应性维护：适应环境（25%），会导致文档的修改
完善性维护：修改和扩充（50%），会导致文档的修改
预防性维护：（4%）
软件可维护性：
·决定软件可维护性的因素：
可理解性
可测试性
可修改性
可移植性
可重用性
·文档
用户文档
系统文档
·可维护性复审：在每个阶段结束前的技术审查和管理复审中对可维护性进行复审。
八、软件项目管理

九、实现&工程工具
UML：统一建模语言/标准建模语言
用例图
时序图
协作图
活动图
类图
组件图
配置图

系统结构图（功能模块图）
系统数据流图
E-R图