软件工程
大占比!
软件工程的基本要素:方法、工具、过程
软件过程
能力成熟度模型(CMM)
将软件过程改进为5个成熟度级别:(每达到成熟度的一个等级,建立起软件过程的一个相应成分,组织过程能力有增长)
1)初始级:软件过程的特点杂乱无章,几乎没有明确定义的步骤,项目的成功全完成依赖个人的努力和英雄式核心人物的作用
2)可重复级:建立了基本的项目管理过程和实践来跟踪项目费用、进度、功能特性,有必要的过程准则来重复以前在同类项目中的成功
3)已定义级:管理和工程两方面的软件过程已经文档化、标准化,并综合成整体软件开发组织的标准软件过程。所有的项目都采用根据实际情况修改后得到的标准软件过程来开发和维护组织
4)已管理级:制定了软件过程和产品质量的详细度量标准。软件过程的产品质量都被开发组织的成员所理解和控制
5)优化级:加强了定量分析,通过来自过程质量反馈和来自新观念、新技术的反馈过程能不断持续地改进
能力成熟度模型集成(CMMI)
表达方法:阶段式模型、连续式模型
1)阶段式模型:关注组织的成熟度
- 初始的:过程不可预测且缺乏控制
- 已管理的的:过程为项目服务
- 已定义的:过程为组织服务
- 定量管理的:过程已度量和控制
- 优化的:集中于过程改进
2)连续性模型:关注每个过程域的等级(能力)CL
- CL0(未完成的):过程域未执行或未得到CL1中定义的所有目标
- CL1(已执行的):将可标识的输入工作产品 转换 成可标识的输出工作产品,以实现支持过程域的特定目标
- CL2(已管理的):集中于已管理的过程的制度化
- CL3(已定义级的):集中于已定义的过程制度化
- CL4(定量管理的):集中于可定量管理的过程的制度化
- CL5(优化的):使用**量化(统计学)**手段改变和优化过程域
*软件过程模型
(软件开发模型)
瀑布模型
各个活动为依线性顺序 连接的若干阶段的模型,它是以文档 作为驱动、适合于软件 需求很明确 的软件项目的模型(回滚回来又继续很麻烦,回炉重造)
- V模型(瀑布模型的一个变体)
描述了质量保证活动(测试)和沟通、建模相关活动以及早期构建相关的活动之间的关系
- 增量模式(瀑布模型的一个变体)
将需求分段为一系列增量产品,每一增量可以分别开发,客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能,不断重复,直达产生了最终的完善产品。该模型采用随着时间的进展而交错的线性序列(融合了瀑布模型的基本成分和原型实现的迭代特征,具有瀑布模型的所有优点)
第一个交付的版本(第一个增量往往是核心产品)需要的时间和成本很少——适用于商业模型
演化模型
迭代的过程模型,使得软件软件人员能够逐步开发出更完整的软件版本。
演化模型特别适用于对软件需求缺乏认识的情况
- 原型模型
- 适用于用户需求不清、需求经常变化的情况(系统规模不大、不太复杂时)。
- 能快速、低成本地构建原型
- 开始于“交流”,用户可以根据框架提出自己地需求
- 螺旋模型
-
适用于复杂、庞大并且具有高风险的系统
-
螺旋模型将瀑布模型和演化模型结合起来,加入了风险分析 ;支持用户需求的动态变化;过多的迭代次数会增加软件开发成本,延迟提交时间
-
螺旋周期:①制定计划 ②风险分析 ③实施工程 ④用户评估
喷泉模型
- 一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法
- 开发过程中具有迭代性(重复多次)和无间隙性(不存在明显的边界),即允许各开发活动交叉、迭代地运行
- 开发过程中需要大量的开发人员,不利于项目的管理;要求严格管理文档,使得审核难度加大
统一过程(UP)模型
- ”用例和风险驱动,以架构为中心,迭代并且增量“的开发过程
- 整个软件开发项目划分为许多个小的”袖珍项目“,每个”袖珍项目“都包含正常软件的所有元素:计划、分析和设计、构造、集成和测试,内部和外部发布
- 4个技术阶段:
- 初始阶段:生命周期目标
- 精化阶段:生命周期架构
- 构建阶段:初始运作功能
- 移交阶段:产品发布
- RUP是UP的商业扩展
敏捷方法
每一种方法基于一套原则
- 极限编程(XP)
-
一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方式(彼此相互依赖、关联)
-
4大价值观:沟通、反馈、简单性、勇气
-
5个原则:快速反馈、简单性假设、逐步修改、提倡更改、优质工作
-
12个最佳实践:计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准
- 水晶法:每一个不同的项目都需要一套不同的策略、约定和方法论
- 并列争求法:使用迭代的方法,把30天一次的迭代称为一个”冲刺“
- 自适应软件开发ASD
- 敏捷统一过程AUP:
- 使用”在大型上连续“以及”在小型上迭代“的原理来构建系统
- 采用经典的UP阶段活动:初始化、精化、构件和转换
- 每个AUP迭代执行以下活动:建模、实现、测试、部署、配置及项目管理、环境管理
软件需求
- 功能需求
- 性能需求
- 用户或人的因素:考虑用户的类型
- 环境需求
- 界面需求
- 文档需求
- 数据需求
- 资源使用需求
- 安全保密要求
- 可靠性要求
- 软件成本消耗与开发进度需求
- 其他非功能性要求
*系统设计
系统设计的结果是一系列的系统设计文件,这些文件是物理实现一个信息系统的重要基础
概要设计
- *设计软件系统总体结构:
- 基本任务:将一个复杂的系统按功能划分成模块、确定每个模块的功能、确定模块之间的调用关系、确定模块之间的接口(传递的信息)、评价模块结构的质量
- 软件系统总体结构是概要设计关键的一步
- 数据结构及数据库设计
(1)数据结构的设计
(2)数据库的设计:①概念设计 ②逻辑设计 ③物理设计
- *编写概要设计文档:概要设计说明书、数据库设计说明书、用户手册以及修订测试计划
- 评审
详细设计
(1)对每个模块进行详细的算法设计
(2)对模块内的数据结构进行设计
(3)对数据库进行物理设计(确定数据库的物理结构)
(4)其他设计:(根据软件系统的类型)代码设计、输入/输出设计、用户界面设计
(5)编写详细设计说明书
(6)评审
*系统测试
- 意义:为了发现错误而执行程序的过程,成功的测试——发现了至今尚未发现的错误的测试
- 目的:希望能以最少的人力和时间发现潜在的各种错误和缺陷
- 系统测试保证系统质量和可靠性的关键步骤,是对系统开发过程中的系统分析、系统设计和实施的最后复查
- 信息系统测试包括软件测试、硬件测试、网络测试
- 进行信息系统测试应遵循以下基本原则:
- 尽早并不断地进行测试
- 测试工作应该避免由原开发软件的人或小组承担,测试工作应由专门人员进行
- 实际输出结果与预期结果相比较发现测试对象是否正确
- 测试的用例也要包含不合理、失效的输入条件
- 测试程序是否做了多余的工作
- 严格按照测试计划进行
- 妥善保存测试计划、测试用例
- 精心设计测试用例。当纠正错误、系统功能扩充后,都需要重新开始测试
- 系统测试阶段的测试目标来自于需求分析阶段
软件测试
单元测试
(模块测试)模块编写无误后进行,侧重于米快内部处理逻辑和数据结构
测试内容的5个特征
(1)模块接口
(2)局部数据结构
(3)重要的执行路径
(4)出错处理
(5)边界条件
单元测试过程
提高模块的内聚度可以简化单元测试
- 驱动测试:相当于一个主程序,接受测试例子的数据,将这些数据送到测试模块,输出测试结果
- 桩模块(存根模块)用来代替测试模块中调用的子模块,其内部进行少量的数据处理,目的是为了检验入口,输出调用和返回的信息
集成测试
- 自顶向下集成测试
一种构造软件体系结构的增量方法(从抽象到具体)
- 集成顺序从主控模块(驱动模块)开始,沿着控制层逐步向下
- 不用编写驱动模块,需要编写桩模块
- 自底向上集成测试
从桩模块开始进行构造和测试(从具体到抽象)
- 不需要编写桩模块,需要编写驱动模块
- 回归测试
当软件发生变更时,会进行重新测试,回归测试能保证变更不引入无意识行为或额外的错误
- 冒烟测试
测试方法
分为静态测试和动态测试(动态测试指通过运行程序发现错误)
静态测试:人工测试、计算机辅助静态分析
动态测试:黑盒测试、白盒测试
*黑盒测试
(功能测试)在完全不了解软件内部结构和特性的情况下,测试软件的外部特性(即只需关系输入和输出的数据,组件内部不清楚)
常用的黑盒测试技术:
- 等价类划分
将程序的输入域划分为若干个等价类,然后从每个等价类中选取一个代表性数据作为测试用例。
分为两种不同的情况:有效等价类和无效等价类(要同时考虑这两类)
测试用例中的数据都不合理——不好的用例
- 边界值分析
输入的边界比中间更加容易发生错误,用边界值分析来补充等价类划分的测试用例设计技术
- 错误推测
基于经验和直觉推测出程序中所有可能存在的各种错误,是有针对性地设计测试用例的方法
- 因果图
从自然语言描述的程序规格说明中找出输入条件和输出条件,通过因果图转换为判定表
*McCabe度量法
通过定义环路复杂度,建立程序复杂性的度量,它基于一个程序模块的程序图中环路的个数
- 计算有向图G的环路复杂性的公式:V(G)=m-n+2 (闭合区域+1)
[V(G):有向图G中的环路个数,m:G中的有向弧数,n是G中的节点数]
*白盒测试
(结构测试)根据程序的内部结构 和逻辑 来设计测试用例。对程序的路径和过程进行测试,检查是否满足设计需要
常用的技术:
- *逻辑覆盖:
- 语句覆盖:选择足够的测试用例,使得测试程序中的每条语句至少执行一次(逻辑覆盖很弱)
- 判定覆盖(分支覆盖):选择足够的测试用例,使得被测程序中的每一个取“真”分支和取“假”分支至少都通过一次
- 条件覆盖:构造一组测试用例,使得每一判定语句中的每个逻辑条件的各种可能的值至少满足一次
- 判定/条件覆盖:设计足够的测试用例,使得判定结构中的每个条件 的所有可能取值(真/假)至少出现一次,并使得每个判定 本身的判定结果(假/真)也至少出现一次
- 条件组合覆盖:设计足够的测试用例,使得每个判定中条件的各种可能值的组合都至少出现一次
- 路径覆盖:覆盖测试程序中的所有尽可能的路径(最强的覆盖)
-
循环覆盖:使得循环中的每个条件都得到验证
-
基本路径测试
系统维护
软件生命周期的最后一个阶段,不属于系统开发过程
- 系统可维护性 的评价指标
①可理解性 ②可测试行 ③可修改性
- 维护与软件文档
- 文档是软件可维护性的决定因素
- ”可维护性“是衡量软件质量的一个重要特性
- 可维护性是所有软件都应该具有的基本特点,必须在开发阶段 保证软件具有可维护性的特点
- 软件可维护性 从可理解性、可靠性、可测试性、可行性、可移植性等方面进行度量
- 软件文档
- 编写高质量文档可以提高软件开发的质量,高质量文档对于软件产品的效益有着重要的意义
- 文档是软件产品的一部分,没有文档的软件就不能称之为软件
- 软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量
- 总的来说,软件文档只好不坏
软件维护
①正确性维护:改正正在系统开发阶段已发生而系统测试阶段尚未发现的错误
②适应性维护:应用软件适应信息技术变化和管理需求变化而进行的修改(硬件环境、运行环境、市场环境、管理需求)
③完善性维护:为扩充功能和改善性能而进行的修改,还要将相关的文档资料加入到前面相应的文档中(占整个维护工作的50%~70%)(对已有的软件系统增加新功能和新性能特征)
④预防性维护:主动增加预防性的新的功能,以适应各类变化不被淘汰
软件的质量属性
可靠性、可用性、可维护性是软件的质量属性【用0-1之间的数来度量】
-
可靠性:一个系统对于给定的时间间隔内、在给定条件下无失效 运作的概率。
【MTTF/(MTTF+1)来度量,MTTF为平均无故障时间】
-
可用性:在给定的时间点上,一个系统能够按照规格说明 正确运作的概率
【MTBF/(MTBF+1)来度量,MTBF为平均失效间隔】
-
可维护性:在给定的使用条件下、在规定的时间间隔内,使用规定的过程和资源完成维护活动 的概率
【1/(1+MTTR)来度量,MTTR为平均修复时间】
沟通路径
- 有n个人
- 主程序员与普通程序员
软件项目估算
COCOMO估算模型
一种精确的、易于使用的成本估算模型
(1)基本COCOMO模型:一个静态单变量模型
(2)中级COCOMO模型:一个静态多变量模型,将软件系统模型分为系统、部件
(3)详细COCOMO模型:将软件系统模型分为系统、子系统、模块3个层次
COCOMOⅡ模型
软件成本估算模型,分为3个阶段(3种不同的规模估算选择)
(1)应用组装模型————>对象点
(2)早期设计阶段模型————>功能点
(3)体系结构阶段模型————>代码行
进度安排的常用图形:甘特图(Gantt)、项目计划评审技术图
甘特图
一种简单的水平条线图,以日历为基准描述项目任务
当日历中同一时段存在多个水平条件时,表示任务之间的并发
优点:清晰地描述每个任务从何时开始,到何时结束,任务进展情况以及各个任务之间的并行性
缺点:不能清晰地反映出个任务之间的依赖关系,难以确定整个项目的关键所在,不能反映计划中有潜力的部分
PERT图
- 一个有向图,图中的箭头表示任务,它可以标上完成该任务所需的时间
- 图中的结点表示流入结点的任务的结束,并开始流出结点的任务(结点也称为事件)
- 只有当流入该结点的所有任务都结束时,结点所表示的事件才出现,流出结点的任务才可以开始
- 最早时刻表示在此时刻之前 该事件出发的任务不可能开始;最迟时刻(表示从该事件出发的任务最迟必须在此时刻开始【最早时刻选最大值,最迟时刻选最小值】
- 松弛时间=最迟时刻-最早时刻;松弛时间——活动的宽限时间(此延迟不会影响整个项目);松弛时刻由终点倒推
- 开始时间=0;
- 完成该工程的关键路径——松弛时间=0的路径
- 优点:给出了每个任务的开始时间、结束时间、完成该任务所需的时间、给出了任务之间的关系
- 缺点:不能反映任务之间并行关系
- 缩短关键路径上的活动才能缩短项目工期
*项目活动图
与PERT图非常相似
顶点表示项目里程碑,连接顶点的边表示活动,边上的值表示完成活动所需要的时间
出题:关键路径、关键路径的长度、某个顶点/活动是否在关键路径上
软件配置管理
- 软件配置管理其主要目标(活动):变更识别、变更控制、版本控制、确保变更正确的实现、变更报告
- 软件配置管理其主要内容:版本管理、配置支持、变更支持、过程支持、团队支持、变化报告、审计支持
- 软件配置管理其主要内容(不同版本):软件配置标识、变更管理、版本控制、系统建立、配置审核、配置状态报告
- 配置数据库可以分三类:开发库、受控库、产品库
*风险管理
软件风险包含两个特性:不确定性和损失
- 不确定性:风险可能发生也可能不发生
- 损失:如果风险发生,就会产生恶行后果
不同风险的类型:
- 项目风险:威胁到项目计划,有可能拖延项目的进度和增加项目的成本。预算、进度、人员、资源、利益相关者、需求等问题;项目复杂度、规模及结构不确定性也属项目风险因素
- 技术风险:威胁到要开发软件的质量及交付时间(很难解决)。设计、实现、接口、验证、维护等问题;规格说明的歧义性、技术的不确定性、技术陈旧、“前沿”技术也属技术风险因素
- 商业风险:威胁到要开发软件的生存能力。
风险识别
指出对项目计划(估算、进度、资源分配等)的威胁。
识别已知风险和可预测风险后,尽可能回避风险、控制风险,有些风险不能被消除
风险预测
(风险评估)从两个方面评估一个风险:风险发生的概率、风险产生的后果
-
整体的风险显露度(RE):RE=P×C (P:风险发生的概率,C:风险产生的后果/成本)
-
评估风险影响的因素:风险的本质(带来的问题)、风险的时间(持续时间)、风险的范围(严重性/分布情况)
-
风险预测活动:项目计划人员、技术人员、管理人员一起进行
风险评估
一种对风险评估很有用的技术就是定义风险参照水准(ri,li,xi)
r:风险;l:风险发生的概率;x:风险产生的影响
风险控制
目的是辅助项目建立处理风险的策略
一个有效的策略必须考虑以下3个问题:
(1)风险避免:主动避免风险(风险发生前采取措施)——应对风险最好的办法
(2)风险监控:项目管理者监控某些因素,如压力、凝聚力、报酬、利益等
(3)RMMM计划:风险管理策略可以包含在软件项目计划中,风险管理步骤可以组织成独立的风险缓解(风险规避活动)、监控(项目跟踪活动)、管理计划(RMMM计划);风险监测的另一任务——试图找到“起源”
*软件质量
软件质量特性:
(1)* ISO/IEC 9126软件质量模型
(2)Mc Call软件质量模型
从软件产品的运行、修正、转移3个方面
软件评审
【正式的技术评审——完成质量评估的中心活动,一旦形成规格说明和设计,就要对它们进行质量评估;其唯一目的就是揭露质量问题(发现错误)】
“质量”——>“用户满意说明书",为了使得用户满意;有两个必要条件:设计质量和程序质量
(1)设计质量的评审内容:
- 评价软件的规格说明 是否符合用户的要求
- 评审可靠性:是否能避免输入异常、硬件失效及软件失效所产生的失效,一旦发生有应对手段
- 评审 保密措施实现情况
- 评审 操作特性实施情况
- 评审 性能实现情况
- 评审软件 是否 具有可修改性、可扩充性、可互换性、可移植性
- 评审软件 是否 具有可测试行
- 评审软件 是否 具有复用性
(2)程序质量的评审内容
开发者的角度进行评审,与开发技术直接相关
软件的结构:功能结构(数据结构、功能结构、数据结构与功能之间的对应关系)、功能的通用性、模块的层次、模块结构(控制流结构、数据流结构、模块结构与功能结构之间的对应关系)、处理过程的结构
(3)与运行环境的接口:与硬件的接口、与用户的接口【运行环境包括硬件、其他软件、用户】
软件容错技术
对某些无法避开的差错,使其影响减至最小的技术
容错的一般方法:(主要手段——冗余)
-
结构冗余:静态冗余、动态冗余、混合冗余
-
信息冗余:为检测或纠正信息在运算或传输中的错误需外加一部分信息
-
时间冗余:以重复执行指令或程序来消除瞬间错误带来的影响
-
冗余附加技术:冗余技术所需的资源和技术
-
在屏蔽硬件错误的容器技术中,冗余附加技术包括:
①关键程序和数据的冗余存储及调用
②检测、表决、切换、重构、纠错和复算的实现
-
在屏蔽软件错误的容器系统中,冗余附加技术包括:
①冗余备份程序的存储及调用
②实现错误检测和错误恢复的程序
③实现容错技术所需的固化程序
-
软件工具
用来辅助软件开发、运行、维护、管理和支持等过程中的活动的软件
- 软件开发工具:需求分析工具、设计工具、编码与排错工具、测试工具等
- 软件维护工具:(辅助软件维护阶段的软件)版本控制工具、文档分析工具、开发信息库工具、逆向工程工具 、再工程工具