软件工程概论
基础知识
软件危机
定义
• 在计算机软件的开发和维护过程中，所遇到的一系列严重问题
• 如何开发软件以满足软件日益增长的需求
• 如何维护数量不断增长的已有软件
表现形式
• 对软件开发的成本和研制进度估计常常不是很准确。
• 已完成的软件不能满足用户要求。
• 软件产品质量差，可靠性得不到保证。
• 软件产品可维护性差
• 软件产品供不应求
软件的定义
软件不是程序，而是程序，数据，已经开发，使用和维护程序所需要所有文档的完整集合。
软件的特点
软件是一种逻辑产品，而不是具体的物理实体，具有抽象性
软件产品的生产主要是开发研制，没有明显的制造过程。
软件产品在使用过程中，不存在磨损，消耗，老化等问题。
软件产品的开发主要是脑力劳动，还未完全摆脱手工开发方式，大部分产品是定做的，生产效率低。
软件产品的成本相当昂贵。
软件对硬件和环境有不同程度的依赖性。
具有复杂性。
软件的开发和运行，都离不开相关计算机系统环境。
软件的种类
按功能划分
• 系统软件
• 应用软件
• 支撑软件
从用途划分
• 服务类软件
• 面向用户
• 维护类软件
• 面向计算机维护
• 操作管理类软件
• 面向计算机操作和管理
软件工程定义
软件工程是指导计算机软件开发和维护的一门工程学科，软件工程采用工程的概念，原理，技术和方法来开发和维护软件。
目标
在给定成本进度的前提下，开发出具有适用性，有效性，可修改性，可靠性，可理解性，可维护性，可移植性，可追踪性，可互操作性和满足用户需求的软件产品，追求这些目标有助于提高软件产品质量和开发效率，减少维护的困难
降低开发成本。
满足用户要求的全部软件功能。
符合用户要求，令用户满意的软件性能。
具有较好的易用性，可重复性和可移植性。
胶体的维护成本，较高的可靠性。
按合同要求完成开发任务，及时交付用户使用。
软件生存周期
定义
• 是指某一软件项目从被提出并着手实现开始，直到该软件报废或停止使用为止所经历的时间。
分类
[if !vml]
[endif]
• 软件计划
• 问题定义
• 可行性研究
• 软件开发
• 需求分析
• 软件设计
• 概要设计
• 详细设计
• 编码
• 测试
• 软件运行
• 维护
软件开发模型
瀑布模型
[if !vml]
[endif]
• 特点
• 各阶段之间有依赖性和严格的顺序性
• 推迟实现
• 严格的阶段质保
• 文档驱动
• 将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型
• 应用最广泛，以文档作为驱动
• 适合于需求很明确的软件项目开发模型
• 存在的问题
• 实际的项目中很难顺序严格
• 用户往往难以给出具体正确完整的要求
• 开发人员阻塞状态严重
• 产品出现晚
快速原型模型
[if !vml]
[endif]
• 适用于需求不确定的开发过程
• 优点
• 出品速度快
• 逐步求精
• 开发和迭代快
• 缺点
• 实现过程中不应有的折中方案
• 开发者急于完成原型而忽略整体设计和可维护性
• 用户参与过多造成了软件开发管理的混乱
增量模型
[if !vml]
[endif]
• 适用于软件要求不明，设计方案有一定风险的软件项目
• 又称渐增模型，是瀑布模型的顺序特征和快速原型法的迭代特征相结合的产物
• 是一种非整体开发的模型
螺旋模型
• 适用于庞大，复杂且具有高风险的系统
• 是一种风险驱动模型
• 是一种迭代模型，把开发过程分为几个螺旋周期，每迭代一次，螺旋线就前进一周
喷泉模型
• 主要用于面向对象软件开发项目
• 一种比较典型的，面向对象软件开发模型，以用户需求为动力，以对象作为驱动的模型
基于构件的开发模型
• 具有螺旋模型的特点
• 利用预先封装的软件来构造应用软件系统，从而提高软件的重复性和可靠性
统一过程(RUP)模型
• 基于面向对象统一建模语言UML的一种面向对象的软件过程模型
基于形式化的开发模型
• 变换模型
• 结合形式化软件开发方法和程序自动生成技术的一种软件开发模型
• 净室模型
• 一种形式化增量开发模型
可行性研究
目的
用最小的代价在尽可能短的时间内，确定问题是否能够解决。
实质上是进行一次大大压缩简化了的系统分析和设计的过程。
任务
初步确定项目的规模、目标和限制条件。一般从4个方面来研究每种解法的可行性
1.经济可行性
2.技术可行性
3.操作可行性
4.法律可行性
步骤
1.复查并确定系统规模和目标
2.研究目前正在使用的系统
3.建立新系统的高层逻辑
4导出和评价各种方案
5.推荐可行方案
6.草拟初步的开发计划
7.编写可行性研究报告提交审查
程序流程图的符号与应用
[if !vml]
[endif]
系统流程图的习惯画法是使信息在图中自顶向下或从左向右流动
[if !vml]
[endif]
样例
[if !vml]
[endif]
需求分析
需求分析
任务
1.确定对系统的综合需求
• 功能需求
• 性能需求
• 环境需求
• 接口需求
• 用户界面需求
• 另外还有可靠性，安全性，保密性，约束，可移植性和可维护性等方面需求
2.分析系统的数据需求
• 通常采用建立数据模型的方法（实体联系图(e-p图)）
3.建立软件的逻辑模型
• 数据流图，数据字典及处理算法
4.编写软件需求规格说明书
• 对软件进行确认和验收的基准
5.需求分析评审
• 发现需求分析的错误和缺陷，然后修改开发计划
步骤
需求获取：调查研究
需求提炼：分析建模
需求描述：编写SRS
需求验证
需求获取
客户访谈
建立联合分析小组
问题分析与确认
快速建立软件原型模型来获取需求
需求分析
功能分裂方法
结构化分析方法
信息建模方法
• 从数据的角度来实现对现实世界建立模型，模型是现实系统的一个抽象
• 基本工具：实体联系图
面向对象方法
• 把实体联系图中的概念与面向对象程序设计语言中的概念结合体在一起形成的一种分析方法
结构化分析方法
自顶向下逐层分解的分析策略
结构化分析描述工具
数据流图
SA方法中用于表示系统逻辑模型的一种工具，它以直观的图形清晰地描述了系统数据的流动和处理过程
→ 箭头，表示数据流
○
圆或椭圆，表示变换数据的处理
□
方框，表示数据的三原点或终点＝双杠或单杠，表示数据存储（文件）
*
星号表示数据之间的关系（同时存在）＋加号表示"或"的关系⊕表示只能从中选一个（互斥的关系）
• 画数据流图的基本原则
• 数据流图中所有的符号必须是前面所述的4种基本符号和附加符号。数据流图的主图（顶层）必须含有前面所述的4种符号，缺一不可。数据流图主图上数据流必须封闭在外部实体之间（外部实体可以是一个，也可以是多个)。加工（变换数据处理）至少有一个输人数据流和一个输出数据流，反映出此加工数据的来源与加工的结果。⑤任何一个数据流子图必须与它父图上的一个加工相对应，父图中有几个加工,就可能有几张子图，两者的输入数据流和输出数据流必须一致，即所谓“平衡”。图上的每个元素都必须有名字（流向数据存储或从数据存储流出的数据流除外）
• 步骤
• 1.先找到外部实体(可以是人，物或其他软件)
2.
找出外部实体的输入与输出数据流
3.
在图的边上画出系统的外部实体
4.
从外部实体的输出流（源点）出发，按照系统的逻辑需求，逐步画出一系列变换数据的加工
5.
按照上述选择进行检查和修改最后按照上述步骤画出所有子图
• 注意事项
• 画数据流图时，只考虑数据流的静态关系，不考虑其动态关系（如启动、停止等与时间有关的问题)，也不考虑出错处理问题。画数据流图时，只考虑常规状态，不考虑异常状态，这两点一般留在设计阶段解决。画数据流图不是画程序流程图，二者有本质的区别。数据流图只描述“做什么”，不描述“怎么做”和做的顺序，而程序流程图表示对数据进行加工的控制和细节。不能期望数据流图一次画成，而是要经过各项反复才能完成。描绘复杂系统的数据流图通常很大，对于画在几张纸上的图很难阅读和理解。一个比较好的方法是分层的描绘这个系统。在分层细画时，必须保持信息的连续性，父图和子图要平衡，每次只细画一个加工。
数据字典
对数据流图中所包含元素的定义集合
组成内容
• 数据流
• 数据流分量（数据基本项）
• 组成数据流和数据存储的最小单位项
• 数据存储（文件）和加工（处理）
使用符号
• ＝表示被定义为或等价于由…组成
• ＋表示"与"（和），用来连接两个数据元素
•
[if !vml]
[endif]
实现
• 利用计算机辅助建立或通过手工建立
加工逻辑
结构化语言
• 自然语言（汉语或英语）加上结构化的形式
• 可以使用顺序，选择，循环3种控制结构
判定表
• 适用于各个条件复杂组合的判定问题
[if !vml]
[endif]
判定树
• 适用于各个条件复杂组合的判定问题
[if !vml]
[endif]
需求分析图形工具
层次方框图
由一系列多层次的树形结构的矩形框组成，用来描述数据层次结构，层次方框图顶层是一个单独的矩形框，代表数据结构的整体，下面各层矩形框代表这个数据结构的子集，最底层的各个框表组成这个数据的不能再分割的基本元素
•
[if !vml]
[endif]
维纳图
表示信息层次体系的一种图形工具，同层次方框图类似，也可以用来描述树形结构的信息可以指出一类信息或一个信息是重复出现的，也可指明信息是有条件出现的
符号
• {}用来区分信息层次
• 异或符号⊕指出一个信息类或一个数据元素在一定条件下出现，符号上，下方的名字代表的数据只能出现一次
•
[if !vml]
[endif]
• 圆括号（）指出这类数据重复出现的次数
IPO图
输入-处理-输出图
•
[if !vml]
[endif]
数据库内容需求分析（E-P图）
信息需求
用户需要从数据库中获得的信息的内容和性质，信息需求是软件数据需求中最基本的需求
处理需求
用户要求软件系统完成的功能，以及对系统功能的处理事件方式等方面的要求，如是要求批处理还是链接处理的。
使用需求
包括使用数据库，是在安全性，完整性，和一致性等方面的限制。查询方式，输入输出格式和多用户等方面的要求。相应速度故障恢复等性的要求。
建立各局应用的E-R模型
建立全局E-R模型
作用
• 帮助设计者准确获取数据需求
构成E-R图的基本要素
• 实体型
• 属性
• 联系
• 一对一联系
• 部门和经理
• 一对多联系
• 教师与课程
• 多对多联系
• 借书人与图书
结构化分析方法综合应用
软件设计
软件总体设计
基本目标
确定系统中的每个程序是由哪些模块组成的
回答："概括的说，系统应该如何实现"
任务
软件体系结构设计
软件模块设计
软件结构设计准则
软件体系结构设计准则
• 体系结构是对复杂事物的一种抽象
• 体系结构在一定时间内保持稳定。
• 良好的体系结构意味着普通，高效和稳定。
软件模块设计准则
• 降低模块之间的耦合性，提高模块的内聚性
• 模块结构的深度，宽度，扇出和扇入应适当
• 模块的作用范围应该在控制范围内
• 模块接口设计要简单，以便降低复杂程度和冗余度
• 设计功能可预测并能得到验证的模块
• 适当划分模块规划，以保持其独立性。
总体设计过程应该遵循的基本原理
模块和模块化
• 模块是软件结构的基础，是软件元素，是能够单独明明独立完成一定功能的程序语句的集合。如高级语言中的过程，函数，子程序等。
• 模块化是使得软件能够对付复杂问题所具备的属性。模块化是指解决一个复杂问题，是自顶向下逐层把软件系统划分成若干模块的过程。模块化的目的是为了降低软件复杂性。
抽象
• 模块反映了数据和过程的抽象
信息隐蔽和局部化
• 信息隐蔽设计原理和确定模块原则应该是的，包含在模块内信息（过程和数据），对于不需要这些信息的模块是不能访问的。
模块独立性及其度量
• 耦合
• 无直接耦合
• 数据耦合
• 标记耦合
• 控制耦合
• 尽量使用数据耦合，少用标记耦合和控制耦合，限制公共环境耦合的范围，完全不用内容耦合
• 公共环境耦合
• 内容耦合
• 内聚
• 偶然内聚
• 逻辑内聚
• 时间内聚
• 通信内聚
• 顺序内聚
• 功能内聚
软件结构设计
软件体系结构设计准则
• 结构体系是对复杂事物的一种抽象。
• 结构体系在一定时间内保持稳定。
• 良好的体系结构意味着普通，稳定，高效。
软件模块设计准则
• 降低模块之间的耦合性，提高模块的内聚性。
• 模块结构的深度，宽度，扇出和扇入应适当
• 深度指软件结构中模块的层次数
• 宽度指同一层次中最大的模块个数一般情况下宽度越大，系统结构越复杂。
• 顶层扇出高，中层扇出较少，底层模块有高扇入
软件结构设计的图形工具
软件结构图
[if !vml]
[endif]
• 模块：用方框表示，方框中写上模块的名字，模块名最好能反映模块功能
• 模块的调用关系：两个模块之间用单向箭头或直线连接起来表示它们的调用关系，一般总是会与上方的模块调用位于下方的模块。所以不用箭头也不会产生二义性，为方便起见，软件结构图中只用直线而不用箭头表示模块之间的调用关系。在调用线两旁通常还有注释的箭头或模块调用过程中来回传递信息，箭头指明传送的方向。
• 以同一名字命名的模块在结构图中仅允许出现一次。调用关系只能从上到下，调用次序可以依据数据传递关系来确定，一般由左向右。结构图要尽量画在一张纸上，且保持结构的清晰性。
[if !vml]
[endif]
层次图
• 用来描绘软件的层次结构。
[if !vml]
[endif]
• 层次图使用于在自定向下设计软件结构过程中使用，而且通常用层次图来作为描绘软件结构的文档。
HIPO图
[if !vml]
[endif]
• 层次图（H图）概要IPO图详细IPO图
软件详细设计
目的
确定应该怎样具体实现所要求的系统。为软件结构图中每一个模块确定采用的算法和块内数据结构，用某种选定的详细设计工具等详细的描述。从而在编码阶段可以把这些描述直接翻译成某种程序设计语言书写的源程序。
任务
设计出程序的蓝图。
结构化程序设计
若一个程序代码块，仅仅通过顺序，选择，循环三种基本控制结构进行连接，并且每个代码块只有一个入口和出口，则称这个程序是结构化程序设计
自顶向下，逐步求精
单入口，单出口的控制结构
详细的设计工具
图形类
• 程序流程图
•
[if !vml]
[endif]
• 优点
• 表达直观，结构清晰，易于理解，易于修改。
• 缺点
• 过早考虑控制流程，忽略整体结构不受约束，随意转移控制，容易造成非结构化的程序结构。不宜表示数据结构和层次结构。
• N-S图
[if !vml]
[endif]
• 优点
• 功能域明确容易确定局部和全局数据的作用域不可能随意更改控制层次结构清晰是软件设计人员遵守结构化的程序设计规定，养成良好的成语设计风格。
• 缺点
• 随着嵌套层次增多，图片清晰度降低。
• 手工修改麻烦
• PAD图（问题分析图）
•
[if !vml]
[endif]
• 优点：设计出的必然是结构化程序结构清晰支持自顶向下，逐步求精。易读易懂易记，使用方便不仅可以表示程序逻辑，还可描绘数据结构可自动生成程序
•
[if !vml]
[endif]
表格类
• 判定表
• 判定树
语言类
• PDL（过程设计语言）
• 也称伪码，是一种用于描述模块算法设计和处理细节的语言
• 特点
• 所有的关键字都有固定语法描述处理过程的说明性语言没有严格的语法控制具有数据说明机制具有模块定义和调用机制
人机界面设计
问题
• 系统响应时间用户帮助设施出错信息处理命令交互
原则
• 让用户驾驭软件，而不是软件驾驭用户尽可能减少用户的记忆负担保持界面一致性
过程
• 建立任务的目标和意图
• 目标和意图明确后，建立界面需求规格模型
• 以界面需求模型为依据创建用户界面原型
• 用户试用并评估该界面原型
• 设计者根据用户的意见修改设计并实现下一原型
• 不断进行下去，直到用户感到满意为止
结构化设计方法的综合应用
是一种把在需求分析阶段得到的数据流图，如何映射为软件结构图的一种基于数据流的设计方法
软件编码
程序设计语言
分类
基础语言
• FORTRAN语言
• 公式翻译语言
• COBOL语言
• 面向商业的公用语言
• BASIC语言
• 初学者通用符号指令代码
• ALGOL语言
• 结构化语言的前驱
结构化语言
• Pascal语言
• 第1个系统体现结构化程序设计概念的高级语言。
• 功能强，数据类型丰富，可以执行好写出的程序，简明清晰易读，便于查找和纠正错误等特点。
• C语言
• 功能丰富，表达能力强，控制结构与数据结构完备，使用灵活方便有丰富的运算符和数据类型外，尤其可移植性好，编译质量高，目标程序效率高，既有高级语言的优点，又具有低级语言的许多特点。
• Ada语言
• 包含数字计算，非标准的输入和输出以上处理数据抽象等特点外，根据文本，它还提供了程序模块化，可以执行可扩充性等特点。
面向对象语言
C＋＋语言
• 保留了传统语言C语言的特征，同时又融合了面向对象的能力
C
＋＋增加了数据抽象，继承，封装，多套性，消息传递等概念实现的机制。
JAVA语言
• 面向对象的，分布式的，安全的，高效的，易移植的语言
程序设计语言的选择
目的
• 为了使程序容易测试和维护，以减少软件开发的成本选用的高级语言，应该具有比较理想的模块化机制以及可读性好的控制结构和数据结构。为了便于调试和提高软件的可靠性，语言的特点，应该是编译程序能够尽可能的发现程序中的错误。为了降低软件开发和维护的成本，应选用的语言，应该有良好的独立编译机制。
实用标准
• 开发的领域
• 用户的要求
• 软件运行环境
• 软件开发人员的知识
风格
程序内部文档
• 标识符的选取
• 名字长度适当不宜太长。
• 如果名字使用缩写，缩写规则一定要一致。并且应该给每个名字加上注解。
• 程序的注解
• 序言性注解
• 描述中模块的整体功能主要算法，接口特点，重要数据含义以及开发简史等
• 功能性注解
• 描述程序段或语句的处理功能
• 功能性注解主要描述的是程序块，而不是解释每行代码
• 程序的布局
• 适当利用阶梯形式，使程序的逻辑结构清晰，易读
数据说明
• 数据说明的次序应该标准化
• 当一个说明语句说明多个变量时，最好按字典顺序排列
• 如果设计时便用了一个复杂的数据结构，则应加注解说明用程序设计语言实现这个数据结构的方法和特点
语句构造
• 不要为了节省储存空间，把多个语句写在同一行。
• 尽量避免复杂的条件测试，尤其减少对“非”条件的测试。
• 尽量避免使用循环嵌套语句和条件嵌套语句。
• 利用圆括号使逻辑表达式或算术表达式的运算次序清晰直观。
• 变量说明不要遗漏变量的连线长度传输以及初始化要程序。
• 让非编码人看的懂
输入/输出
• 对所有输入数据进行校检，以保证每个数据的有效性，并可以避免用户错误输入。
• 检查输入项重要组合的合法性。
• 保持简单的输入法是，为方便用户使用，可以在提示中加以说明，或用表格方式提供输入位置。
• 输入一批数据是使用数据和文件结束标志，不要用计数来控制，更不能要求用户自己指定输入项或记录数
• 人机交互式输入时要详细说明可用的选择范围和边界值。
• 当程序设计语言对输入或输出格式有要求时，应保持输入格式与输入语句的要求一致。
• 输出报表的设计要符合用户要求，输出数据，尽量表格化，图形化。
• 给所有的输出数据加标志并加以必要的注解。
效率
• 指处理机工作时间和内存容量两方面的利用率
• 1.代码效率
• 2..存储效率
• 3.输入/输出效率
软件测试
软件测试的目标
是为了发现错误而执行程序的过程。
一个好的测试用例能够发现至今尚未发现的错误。
一个成功的测试是发现了至今尚未发现的错误的测试。
软件测试的原则
测试用例既要有输入数据，又要有对应的输出结果。
测试用例不仅要选用合理的输入数据，还要选择不合理的输入数据。
除了检查程序，是否做了他应该做的工作，还应该检查程序是否做了他不应该做的工作。
应远在测试开始之前就制定测试计划。
测试计划，测试用例，测试报告必须作为文档长期保存。
Pare to原理说明，可以把Pare
to原理应用到软件测试中
应该由独立的第三方从事测试工作
软件测试方法及分类
一般把被测程序在机器上运行，称为动态测试。不在机器上运行被测程序称为静态分析。
静态测试与动态测试
静态测试
• 即静态分析，是指被测程序不在机器上运行，对模块的源代码进行研读，查找错误或收集一些度量数据，采用人工检验和计算机辅助静态设计手段，对程序进行检测，只进行特性分析。
• 人工测试
• 计算机辅助静态分析
动态测试
• 通过运行程序发现错误
黑盒测试与白盒测试
黑盒测试法
• 也称功能测试或数据驱动测试
• 主要发现的错误
• 是否有不正确或遗漏了的功能
• 在接口上能否正确地接收输入数据，能否产生正确的输出信息
• 访问外部信息是否有错
• 性能上是否满足要求
• 界面是否有错，是否美观，友好
白盒测试法
• 也称结构测试或逻辑驱动测试，不可能进行完全的测试
• 对程序中所有逻辑路径进行测试，并检验内部。控制结构是否有错，确定实际的运行状态与预期状态是否一致
软件测试用例的设计
[if !vml]
[endif]
白盒技术
[if !vml]
[endif]
白盒测试是以程序的结构为依据，所以被测对象基本上是原程序，以程序的内部逻辑结构为基础设计测试用例。
逻辑覆盖
• 语句覆盖
• 判定覆盖
• 条件覆盖
循环覆盖
• 单循环
• 嵌套循环
基本路径测试
•
[if !vml]
[endif]
软件测试过程
软件产品在交付使用之前，一般要经过单元测试，系统测试，确认测试和系统测试4个阶段。
软件测试过程中需要的三类信息。
软件配置
测试配置
测试工具
单元测试
单元测试的任务
模块接口测试
模块局部数据结构测试
模块出错处理通路测试
模块中重要的执行路径测试
模块边界条件测试
单元测试的方法
为被测试模块设计驱动模块和装模块
[if !vml]
[endif]
• 驱动模块
• 模拟上机模块调用被测模块的模块，即模拟出程序。
• 桩模块
• 用来代替由被测模块所调用的模块，也可以称为“虚拟子程序”
集成测试
渐增式测试
非渐增式测试
自顶向下集成方法
[if !vml]
[endif]
从顶层模块开始，沿着软件的控制层次向下移动，逐步把各个模块结合起来
深度优先的结合方法
• 首先把软件结构的一条主控制路径上的模块一个个结合起来进行测试
宽度优先的测试
• 逐层结合直接下属的所有模块
自底向上集成方法
[if !vml]
[endif]
从软件结构的最底一层模块开始装配和测试
确认测试
有效性测试
从质量的角度，在功能，性能，可靠性，易用性等方面对软件进行全面的质量检测。
软件配置报告
保证软件开发的所有文件资料齐全正确，文档与程序完全一致，为软件投入运行后，软件维护工作做好充分的准备。
系统测试
α测试
有用户在开发者的场所进行，在实际运行环境和正式应用过程中开发者对用户进行"指导"性测试，来发现测试阶段没有发现的缺陷。
β测试
子公司外部的典型用户，在开发者不能控制的环境中"真实"应用，并要求用户报告异常情况，提出批评意见
调试
调试的目的和任务
目的
• 找出软件中存在的错误，其通过测试来发现错误，而调试的目的是为了解决存在的错误及对错误定位分析，并找出原因改正错误，因此调试也被称为纠错。
任务
• 通过外部表现找出原因
常用调试技术
简单的调试技术
消去原因法
• 归纳法
•
[if !vml]
[endif]
• 演绎法
•
[if !vml]
[endif]
总结
软件测试在软件开发项目中花费的精力较多，也是保证软件质量的最后一个阶段。软件测试的目的是发现程序的错误，而不是证明程序没有错误。软件测试的原则是选用最少的测试数据，发现尽可能多的错误。为达到这个目的，就要选择相应的测试方法。软件测试方法有动态测试方法和静态测试方法。动态测试方法又分为白盒测试方法和黑盒测试方法。在软件测试中通常以动态测试方法为主，动态测试要先选择测试用例，然后上机运行程序，将得到的实际运行结果和预期结果比较，从而发现错误。测试用例设计方法有逻辑覆盖法、边界值分析法、等价类划分法、错误推测法和因果图法等。在进行软件测试时，首先进行单元测试，然后进行集成测试，再进行确认测试，最后进行系统测试。单元测试可以发现模块中的问题。集成测试可以发现模块接口之间接口的问题。确认测试是从质量的角度，在功能、性能、可靠性和易用性等方面对软件做全面的质量检测。系统测试则放在安装与验收阶段进行。经过软件测试，如果发现软件中有隐藏的错误，就要查找错误的位置和错误的原因，即进行软件调试，调试和测试经常交替进行。软件调试也叫做排错，涉及诊断和排错两个步骤。常用的调试策略有试探法、回溯法、折半查找法、归纳法和演绎法。软件调试也是一种非常困难的工作，因为软件错误的种类和原因非常多，目前还没有十分有效的调试方法。
软件维护
软件维护概述
软件维护的定义
软件系统交付使用以后，为了改正软件运行错误，或以满足新的需求而加入新功能修改软件的过程
软件维护的分类
改正性维护
• 开发过程中采用新技术，利用应用软件包，提高系统结构化程度，进行周期性维护审查
适应性维护
• 有对可能变化的因素进行配置管理，强行环境变化，而必须修改的部分区域化，即局限于某些程序模块等
完善性维护
• 采用功能强，使用方便的工具，采用原型化的开发方法。
预防性维护
• 采用提前实现，软件重用等技术。
软件维护的过程
结构化维护与非结构化维护
[if !vml]
[endif]
维护组织
[if !vml]
[endif]
维护工作的流程
建立维护机构
编写软件维护申请报告
确定软件维护工作流程
• 确认维护类型
• 实施相应维护
[if !vml]
[endif]
• 维护评审
整理软件维护文档
维护工作的组织管理
[if !vml]
[endif]
软件可维护性
定义
纠正软件系统出现的错误和缺陷，以及未满足新的要求进行修改，扩充或压缩的容易程度。
•
[if !vml]
[endif]
• 可理解性
• 维护人员通过阅读源代码和相关文档理解软件的结构，接口，功能和内部过程的单一程度。
• 可测试性
• 证实程序正确写的难易程度，程序越简单，证明其正确性也就越容易。
• 可修改性
• 修改程序的难易程度
• 可靠性
• 软件成长工作平均时间
• 可移植性
• 程序从计算机环境移动到另一个计算机环境的适应能力。
• 可使用性
• 从用户观点出发，把可使用性定义为程序方便，实用以及易于使用的程度。
• 效率
• 表明一个程序能执行预定功能而又不浪费机器资源的程度
度量方法
质量检查表
质量测试
质量标准
提高软件可维护性的方法
建立明确的软件质量目标和优先级
使用提高软件质量的技术和工具
• 模块化方法
• 结构化方法
• 面向对象的方法
选择便于维护的程序设计语言
•
[if !vml]
[endif]
采用明确的，有效的质量保证审查措施
• 在检查点进行复审
•
[if !vml]
[endif]
• 验收检查
• 周期性的维护审查
• 对软件包进行检查
完善程序的文档
再工程与逆向工程
再工程与逆向工程的概念
再工程
• 增进对软件的理解
• 准备或直接提高软件的可维护性，复用性或演化性
逆向工程
• 拆卸成品进行反向研究
•
[if !vml]
[endif]
为什么要实施软件再工程
再工程可帮助软件机构降低软件演化的风险。
再工程可帮助软件机构补偿软件的投资。
再工程科是的软件易于进一步变更
再工程有广阔的市场。
软件再工程技术
[if !vml]
[endif]
• 改进软件
• 理解软件
• 获取，保护以及扩充软件的已有知识
小结
软件系统开发完成，经测试达到可靠性指标后，就交给用户，进入软件生存周期的最后一个阶段，即运行维护阶段。软件维护阶段是软件生存周期中时间最长的一个阶段，也是所花费精力和费用最多的一个阶段。软件维护有4种类型，即改正性、适应性、完善性和预防性维护。软件维护过程需要建立相应的维护组织，按照一定的维护流程进行结构化维护工作。软件可维护性是衡量软件质量的重要指标，主要通过可理解性、可测试性、可修改性等7个特性来度量，提高软件可维护性需要从5个方面入手完善维护工作。软件维护工作本身的特性决定了软件维护工作的困难，同时软件维护也可能带来修改代码、数据和文档等方面的副作用，因此，维护人员更应遵守软件维护的流程。软件维护阶段还有一个重要工作是进行软件再工程，实施软件再工程首先需要理解系统，此外还会涉及软件再工程的一些相关技术。
面向对象的方法
面向对象方法概述
基本原则
尽可能模仿人类习惯的思维方式，是开发软件的方法与过程，尽可能的接近人类解决问题的方法与过程。
把程序看作相互协作而又彼此独立的对象的集合，每个对象如同一个小程序段，有自己的数据，操作，功能和目的。
同时使用对象，类，继承和消息的方法，才是真正的面向对象的方法。
面向方法学的优点与不足
优点
• 与人类习惯的思维方式一致
• 软件稳定性好
• 可重用性好
• 较易开发大型软件产品
• 可维护性好，易于测试
不足
• 相对面向过程而言比较麻烦，需要写更多代码。
• 占用空间比较多，程序效率比较低。
• 非常耗时
• 初学者不易接受，难学。
• 测试难度大
面向对象基本概念。
对象
[if !vml]
[endif]
• 对问题域中客观存在的事物的抽象，是一组属性和在这些属性上的操作的封装体
• 属性
• 用来描述对象静态特征
• 操作
• 用来描述对象的动态特征
类
• 具有相同属性和操作的一组相似对象（实体）的集合
消息
• 面向对象系统中对象之间交互的途径
封装
• 把对象的属性和操作结合成一个独立的系统单位，并尽可能隐藏对象的内部细节
• 封装是对象和类的一个基本特性，又称信息隐藏。
• 作用
• 使对象形成接口和实现两个部分
•
[if !vml]
[endif]
• 封装的信息隐藏将所声明的功能（行为）与内部实现（细节）分离
• 封装可以保护对象，避免用户误用，也可以保护客户机，对象实现过程的改变不会影响到相应客户机的改变
对象，类及类之间的关系的分析
• 类与对象的关系
• 对象又称为类的一个"实例"，类又称为对象的模板
[if !vml]
[endif]
• 类是静态的，类的语义和类之间的关系的在程序执行之前就已经定义。
• 对象是动态的，在程序执行过程中可以动态的创建和删除对象。
• 类是代表一类抽象的概念或事物
• 类与类之间的关系
• 继承
• 继承是子类自动地共享父类中定义的数据和方法的机制
[if !vml]
[endif]
• 从子类抽取共同通用的特征形成父类的过程也叫做泛化
• 多态性
• 指的是一个实体在不同上下文条件下具有不同意义用法的能力。
• 发给不同的对象的同一条消息会引起不同的结果。
•
[if !vml]
[endif]
• 关联
• 两个类之间语义级别的一种强依赖关系。
[if !vml]
[endif]
• 依赖
• 一个类a使用到了另一个类b
[if !vml]
[endif]
• 实现
• 用来规定接口和实现接口的类之间的关系。
[if !vml]
[endif]
• 聚集与组合
[if !vml]
[endif]
• 一个类有时可以由一个或多个部分类组成，这种表示组成关系的整体与部分类之间的关联就可以细分为聚集合组合。
• 关联和聚合在代码上的表现是一致的，只能从语义级别来区分。
• 关联的两个对象之间一般是平等的。
• 聚集一般不是平等的，表示一个对象是另一个对象的组成部分
• 关联是一种结构化的关系，指一种对象和另一种对象有关系。
• 总的来说，继承与实现体现的是一种类与类，或类与结构之间的纵向关系。
• 强弱关系：组合＞聚集＞关联＞依赖
典型开发方法
Booch方法
[if !vml]
[endif]
Booch方法并不是一个开发过程，只是在开发面向对象系统时应遵循的一些技术和原则，Booch方法是从外部开始，逐步求精每个类，直到系统被实现，因此，他是一种分治发，支持循环开发，缺点在于不能有效的找出每个对象和类的操作
•
[if !vml]
[endif]
Coad/Yourdon方法（OOAD方法）
[if !vml]
[endif]
OOA(面向对象分析)
• 把系统横向划分为5个层次
OOD(面向对象设计)
• 把系统纵向划分为4个部分
适用于小型系统的开发
OMT/Rumbaugh方法
[if !vml]
[endif]
OMT方法覆盖了应用开发的全过程，是一种比较成熟的方法，用于几种不同的观念来适应不同的建模场合，他在许多重要观念上受到关系数据库设计的影响，适用于数据密集型的信息系统开发，是一种比较完善和有效的分析与设计方法
OOSE方法/JJacobson方法
[if !vml]
[endif]
能较好地描述系统需求，是一种实用的面向对象的系统开发方法，适用于商务处理方面的应用开发
Wirfs-Brock方法
评估客户规约
使用语法分析从规约中抽取候选类
组合类以试图标识超类
为每个类定义责任
为每个类赋予责任
标识类之间的关系
定义类之间基于责任的协作
构造类的层次表示以显示继承的关系
构造系统的协作图
不明确区分分析和设计任务，从评估客户规格说明到设计完成，是一个连续的过程
统一建模语言UML
[if !vml]
[endif]
UML定义及主要内容
UML的语义
• 元元模型层
• 由UML最基本的元素事物组成，表示要定义的所有事物
• 元模型层
• 由UML的基本元素组成，包括面向对象和面向构件的概念。该层的每个概念都是元元模型中事物概念的实例
• 模型层
• 由UML模型组成，该层的每个概念都是元模型层中概念的实例，一般称为类模型或类型模型
• 用户模型层
• 该层每个概念都是模型层的一个实例，也是元模型层概念的一个实例，通常称为对象模型或实例模型
UML的表示方法
• 视图
• 图
• 模型元素
• 公共机制
UML的构成
• 基本构造块
• 事物
• 结构事物
• 行为事物
• 分组事物
• 注释事物
• 关系
• 依赖
• 关联
• 泛化
• 实现
• 图
• 规则
• 公共机制
UML的特点与用途
• 特点
• 统一的标准
• 面向对象
• 可视化，表示能力强大
• 独立于过程
• 易于掌握应用
• 用途
• 需求分析阶段
• 系统设计阶段
• 编码阶段
• 测试阶段
UML模型视图简介
[if !vml]
[endif]
• 静态图
• 类图
• 对象图
• 用例图
• 构件图
• 部署图
• 包图
• 结构组合图
• 动态图
• 动态图
• 顺序图
• 通信图
• 活动图
• 计时图
• 交互概览图
面向对象分析过程
抽取和整理用户需求并建立问题领域精确模型的过程。
用例模型
从用户需求的角度来描述系统，指明系统应该做什么，直接反映用户对目标系统的需求，描述数据在系统中的变化过程以及系统的功能。有助于软件开发人员更深入的理解问题域，改善和完善自己的分析和设计过程。
对象模型
通过对象类的属性操作以及其相互联系的描述，给出系统静态结构的刻画。在UML中常用类图和对象图来描述
动态行为模型
表示瞬时的行为化的系统的控制性质，定义对象模型中对象的合法变化序列，描述系统中不同对象类之间的交互
物理实现模型
从实现子系统和实现元素（构件）的角度来表现系统实现的物理组成。
4种模型之间的关系
（1）针对每个类建立的动态模型，描述类实例的生存周期或运行周期。（2）状态转换驱使行为发生，这些行为在数据流图中被映射成处理，在用例图中被映射成用例，它们同时与类图中的服务相对应。（3）用例（功能）模型中的用例（或处理）对应于对象模型中的类所提供的服务。（4）数据流图中的数据存储及数据的源点/终点通常是对象模型中的对象。（5）数据流图中的数据流往往是对象模型中对象的属性值，也可能是整个对象。（6）用例图中的参与者可能是对象模型中的对象。（7）用例（功能）模型中的用例（或处理）可能产生动态模型中的事件。（8）对象模型描述数据流图中的数据流、数据存储及数据源点/终点的结构。（9）物理实现模型中的构件通常对应对象模型中的类。
建立用例模型
需求分析与用例建模
确定系统范围和系统边界
确定参与者
确定用例
[if !vml]
[endif]
确定用例之间的关系
包含关系
[if !vml]
[endif]
扩展关系
[if !vml]
[endif]
泛化关系
[if !vml]
[endif]
使用关系
[if !vml]
[endif]
软件项目管理
估算软件规模
人员组织
质量保证
能力成熟度模型
软件能力成熟度模型（CMM）
cmm内容。
• 定义
• 对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各发展阶段的描述。
[if !vml]
[endif]
•
[if !vml]
[endif]
关键过程域（KPA）
[if !vml]
[endif]
CMM实施中应注意的问题
工作量估算
进度计划
软件复用技术
软件复用概念及分类
概念
• 为了复用的目的而设计的软件
• 可复用软件是指为了复用目的而设计的软件
• 分类
• 依据复用的组织方式
• 系统化的（有计划的）复用
• 个别复用
• 依据所应用的范围
• 横向复用
• 在多个不同的应用领域内寻找共同点，目的是复用不同领域内的软件元素。
• 横向复用的应用相对较少。
• 纵向复用
• 在同一个应用领域，或者在同一类具有较多共性的应用领域之间进行软制品复用
• 有助于提取出系统的通用模型
软件复用的关键技术和复用粒度
软件复用的3个问题
• 必须有可复用的对象
• 复用的对象必须是有用的
• 复用者需知道如何去使用被复用的对象。
关键技术
• 软件构件技术
• 领域工程
• 软件构架技术
• 软件再工程技术
• 开放系统技术。
• 软件过程
• CASE技术
• 以及众多非技术因素
复用粒度
• 代码和设计拷贝
• 源代码复用
• 设计和软件体系结构复用
• 应用程序生成器的使用
• 领域特定的软件体系结构的复用等
基于构建的软件工程技术
中间件的概念是为了解决网络情况下，分布式应用程序的异构问题而提出来的概念。
构件（组件）技术。在最初的时候，更多是作为一种思想存在，构件的发展在某种程度上，极大的依赖与中间件技术，中间件是构件存在的基础。同时软件构件技术是支持软件复用的核心技术。
软件过程与标准化
软件过程是改进软件治疗和组织性能的主要因素之一。
软件过程及改进
iso9000标准。
软件能力成熟度模型（CMM）
cmm内容。
• 定义
• 对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各发展阶段的描述。
关键过程域（KPA）
CMM实施中应注意的问题
软件能力成熟度模型（CMM）
cmm内容。
• 定义
• 对于软件组织在定义，实现，度量，控制和改善其软件过程的进程中各发展阶段的描述。
关键过程域（KPA）
CMM实施中应注意的问题
PSP,TSP和CMMI
个体软件过程(PSP)
小组软件开发过程(TSP)
能力成熟度集成模型（CMMI）
敏捷软件开发过程
快速交付可用的软件
推崇的观点
让客户满意和软件尽早增量发布
小而高效自主的项目团队
非正式的方法
最小化软件工程工作产品
整体精简开发
敏捷及敏捷过程相关概念。
敏捷过程在软件业中的提出
• 可工作软件胜过面面俱到的文档。
• 客户合作胜过合同谈判。
• 响应变化胜过遵循计划
敏捷的概念
• 软件需求经常变化或需求变化比较大。
• 项目团队用户之间进行沟通比较容易
• 项目开发风险比较高。
• 规模比较小，一般项目组成员在50人之内。
• 项目团队的成员能力比较强，且具有责任感。
• 项目的可测试性比较好。
敏捷宣言所遵循的12条原则。
• ①人们最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。②即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。③经常性的交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。④在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。⑤围绕被激励起来的个体来构建项目。给它们提供所需的环境和支持，并且信任它们能够完成工作。⑥在团队内部，最具有效果并且富有效率的传递信息的方法就是面对面的交谈。⑦工作的软件是首要的进度度量标准。⑧敏捷过程提倡可持续的开发进度。责任人、开发者和用户应保持一个长期恒定的开发速度。⑨不断关注优秀的技能和好的设计会增强敏捷能力。⑩简单——使未完成的工作最大化的艺术——是根本的。11.最好的构架、需求和设计出自于自组织的团队。
12
每隔一定时间，团队会在如何才能更有效的工作方面进行反省，然后相应地对自己的行为进行调整。
敏捷软件过程的特性
• 轻载软件过程
• 基于时间
• 够用就好
• 并行
• 基于构件的软件工程
• 敏捷软件过程模型＝功能模型＋合作模型＋资源模型＋产品模型
典型的敏捷过程模型
• 极限编程（XP）
[if !vml]
[endif]
• 争球队形模型方法（Scrum方法）
[if !vml]
[endif]
• 特征驱动开发（FDD）
[if !vml]
[endif]
web软件工程
基于Web的系统和应用的属性和特点
网络密集性
访问并发性
性能要求苛刻
可用性
安全性要求苛刻。
数据驱动
内容敏感化
持续演化
及时性
美观性
web工程过程
客户交流阶段
计划阶段
建模阶段
构建阶段
部署阶段
如果要做一些企业级的WebApp，下面的这些基本的规则应比较适用:（1）即使WebApp的细节是模糊的，也要花一些时间去理解商业需求和产品目标；（2）用基于用例的方法去描述用户如何与WebApp交互；（3）即便很简短，也要做一个项目计划；（4）花些时间对要做的内容建模；（5）考察模型的一致性和质量；（6）使用一些能使你去构建带有尽可能多可重用构件的系统的工具和技术；（7）设计一些综合性的测试，并在系统发布前执行它们。
Web软件需求分析
内容模型
交互模型
功能模型
配置模型
导航模型
Web软件的设计
WebApp界面设计
• 始终处于用户的操纵控制之下
• 减少用户记忆负担
• 保持界面一致性
美学设计
• 字体，字号，风格，补充媒体的使用。
内容设计
体系结构设计
• 线性结构
•
[if !vml]
[endif]
• 网络结构
• 层次结构
•
[if !vml]
[endif]
导航设计
• 单独的导航链接
• 水平导航条
• 垂直导航列
• 标签
• 网站地图
构件级设计
[if !vml]
[endif]
• 可执行本地化处理，从而动态的产生内容和导航能力。
• 可以提供适合于WebAPP业务领域的计算或数据处理能力
• 可以提供高级的数据库查询和访问
• 可以建立与外部协作系统的数据接口。
Web软件的测试
内容
功能
结构
易用性
导航性
性能
兼容性
互操作性
安全性
软件产品线技术
[if !vml]
[endif]
软件产品线基本概念
软件产品线的三大基本活动
[if !vml]
[endif]
•
[if !vml]
[endif]
软件产品线的特点
• 缩短开发周期，降低研发成本，减少产品更新和维护的难度，提供更好的质量，进而在竞争中处于领先地位，获取更大的利润。
•
[if !vml]
[endif]
根据标准架构来开发和利用产品线构件来开发。
.blo�C�4gw,
网友评论