软件工程总结_第1页
软件工程总结_第2页
软件工程总结_第3页
软件工程总结_第4页
软件工程总结_第5页
已阅读5页,还剩23页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、1. 软件是计算机系统中与硬件相互依存的另一部分,它是包括程序、数据及其相关文档的完整集合。2. 软件危机是指:在计算机软件的开发和维护过程中所遇到的一系列严重问题。3. 1993年IEEE更全面更具体的定义:“软件工程是:把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程,也就是把工程应用于软件;研究中提到的途径。”4. 软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程。5. 软件工程的本质特性: 软件

2、工程关注大型程序的构造;i. 软件工程的中心课题是控制复杂性;ii. 软件经常变化;iii. 开发软件的效率非常重要;iv. 和谐地合作是开发软件的关键;v. 软件必须有效地支持它的用户;vi. 软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。(*)6. 软件工程的基本原理:a) 用分阶段的生命周期计划严格管理b) 坚持进行阶段评审。i. 一大部分错误是在编码之前造成的ii. 错误发现与改正的越晚,所需付出的代价也越高c)实行严格的产品控制:实习基准配置管理(变动控制)d)采用现代化程序设计技术e)结果应能清楚地审查f)开发小组的人员应该少而精开发小组人员的素质和数量是

3、影响软件产品质量和开发效率的重要因素g)承认不断改进软件工程实践的必要性7. 软件工程方法学a) 软件工程包括技术和管理两方面的内容,是技术和管理紧密结合所形成的工程学科b) 三要素:方法,工具,过程c) 传统方法学(生命周期方法学或结构化范型)。采用结构化技术来完成软件开发的各项任务,并使用适当的软件工具或软件工程环境来支持结构化技术的应用。没有既面向数据又面向行为的结构化技术d) 面向对象方法学。把数据和行为看成是同等重要的是一种以数据为主线,把数据和对数据的操作紧密的结合起来的方法。面向对象=类+对象+继承+通信e) 软件工程涉及的人员分为三种角色:客户,开发者,用户8. 软件生命周期:

4、由软件定义,软件开发,软件维护组成i. 软件定义:问题定义,可行性研究,需求分析ii. 软件开发:总体设计,详细设计,编码和单元测试,综合测试iii. 软件维护:一次压缩和简化了的软件定义和开发过程a) 适应性维护。修改软件以适应环境的变化b) 改正性维护。诊断和改正使用过程发现的软件错误c) 完善性维护。根据用户的需要改进或扩充软件使它更完善d) 预防性维护。修改软件,为将来的维护活动预先做准备9. 软件生命周期:(软件过程)是为了获得高质量软件所需要完成但我一系列任务的框架,它规定了完成各项任务的工作步骤。a) 瀑布模型(线性模型或传统生命周期模型)i. 本质是一次性通过ii. 是文档驱动

5、模型(瀑布模型成功的很大因素)iii. 阶段间具有顺序性和依赖性iv. 推迟实现的观点v. 质量保证的观点vi. 适用于规模较大,需求明确,或很少变更的项目b) V模型i. 瀑布模型的改进,强调测试活动与分析和设计之间的关联ii. 是活动驱动模型iii. 是把瀑布模型中一些隐含的迭代过程明确出来iv. 使抽象等级的概念更明显v. 和瀑布模型一样,都是对软件开发过程过分简单理想化的抽象vi. 对需求变化的适应性差c) 快速原型模型i. 是一个可以实际运行的模型,是最终产品的子集ii. 保证用户的真实需求得到满足iii. 不带反馈环iv. 软件产品的开发基本上线性进行的v. 有助于需求的定义和确认

6、,获知用户的真正需求d) 增量模型i. 短时间内向用户提交可完成不部分工作的产品ii. 适用于人员配备不充裕,不能再软件项目期限之前实现一个完全版本的情况iii. 有计划的管理技术风险iv. 使问题修正易用进行v. 可以针对不同领域开发不同版本vi. 可以提前开始培训,提前开拓市场e) 螺旋模型i. 基本思想:通过使用原型或其他手段降低风险ii. 理解为在每个阶段都增加了风险分析的快速原型模型iii. 是对瀑布模型的发展iv. 主要适用于内部开发的大规模软件项目v. 是风险驱动的vi. 进度:制定计划,风险分析,实施工程,客户评估f) 喷泉模型i. 体现了面向对象软件开发过程迭代和无缝的特性i

7、i. 是典型的面向对象的软件过程模型iii. 为避免使用喷泉模型开发软件开发过程过于无序,应该把一个线性过程(快速原型模型)作为总目标iv. 经常对开发活动进行迭代或求精10. 软件工程模式:是软件过程中生命周期,人员,方法,产品四大要素相关联的有机整体a) Rational统一过程1. RUP开发经验(最佳实践)六条:23页2. 静态结构:9个核心工作流,前6个为核心过程工作流,后三个为核心支持工作流3. 动态结构:四个阶段a) 初始阶段:建立用例和确定项目的范围-生命周期目标里程碑b) 精华阶段:建立稳定的架构-生命周期架构里程碑c) 构建阶段:-初始可操作性能里程碑d) 移交阶段:-产品

8、发布里程碑4. RUP迭代开发a) 整个开发项目由多个迭代过程组成b) 每次迭代只考虑一部分系统需求c) 每个迭代都是风险驱动的d) 每个迭代都可以看作是一个“小型的瀑布模型”过程e) 每次迭代以不同的重点和强度访问核心工作流5. RUP生命周期a) 用于需求不明确,不稳定的项目开发b) 用力驱动,以架构为中心,迭代和增量的c) 是可配置的,具有通用性6. RUP的方法a) 用例及用例驱动b) 以架构为中心c) 采用UML可视化建模d) 面向对象的设计与构件实现7. RUP的工具a) Rational Solutionsb) 敏捷过程i. 强调适应而非预测变化ii. 以人为中心iii. 价值观

9、1. 个体和交互胜过过程和工具2. 可以工作的软件胜过面面俱到的文档3. 客户合作胜过合同谈判4. 响应变化胜过遵循计划5. 敏捷过程a) 适合需求模糊而且经常改变的场合b) 敏捷过程是一个一维的迭代过程c) RUP是一个二维、双重的迭代过程d) 对不确定性反应更快速,更敏捷e) 针对商业环境下通常具有有限资源和有限时间约束的小型项目,提出了一些独具特色的、操作性较强的解决方案c) 微软过程i. 软件生命周期:构思,计划,开发,稳定,部署ii. 五个阶段:1. 构思阶段-前景/范围认可里程碑2. 计划阶段-项目计划认可里程碑3. 开发阶段-范围完成里程碑4. 稳定阶段-发布就绪认可里程碑5.

10、部署阶段-部署完成里程碑11. 可行性研究a) 目的:用最小的代价,在尽可能短的时间内确定问题是否能够解决b) 实质:是一次压缩,简化了的系统分析和设计的过程c) 最根本的任务:对以后的行动方针提出建议d) 应着重考虑:技术可行性,经济可行性,操作可行性,法律可行性,开发方案的选择性研究e) 成本一般为预期总成本的5%10%f) 成本估计:代码行技术,任务分解技术,自动估计成本技术g) 度量效益值得方法i. 货币的时间价值:,现在存入P元,年利率为i,n年后得到的钱是P元ii. 投资回收期iii. 纯收入iv. 投资回收率12. 软件需求a) 在软件生命周期中,一个错误发现的越晚,修复错误的费

11、用越高b) 在需求阶段,代表性的错误为疏忽,不一致和二义性c) 功能性需求:描述系统必须支持的功能和过程d) 非功能性需求:为如何实现这些需求设定约束e) 需求的特征:正确性,一致性,完整性,现实性,实用性,可检验性,可回溯性f) 分析系统的数据要求i. 建立数据模型:E-R图ii. 复杂数据结构的描述:数据字典,层次方框图,Warnier图iii. 数据库:数据规范化g) 需求分析的任务是:借助于当前系统的逻辑模型导出目标系统的逻辑模型h) 需求过程:i. 需求提取方法:1. 访谈:最早开始使用获取用户需求的技术2. 结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法3. 简单的

12、应用规格说明技术:面向团队的需求收集法4. 场景分析(use case):一个use case是一个描述软件如何被用于给定情绪的场景5. 原型化方法:向用户演示系统提供的功能a) 需求提取阶段的原型:针对难以理解,不好把握的需求b) 需求确认阶段的原型:能用于试验的系统原型6. 需求过程的总结:需求提取,需求分析。形成需求文档,需求确认。ii. 需求分析和协商iii. 需求确认i) 软件需求的表达方法i. 系统模型:行为模型(功能模型和动态模型)和结构模型(静态模型)ii. 静态表达方法:E-R图,数据抽象,对象模型iii. 动态表达方法:判定表,状态迁移图,时序图,Petri图iv. 层次技

13、术:Warnier图v. 传统结构化分析方法(是面向数据流自顶向下逐层分解的需求分析方法)1. 核心:数据字典2. 实体关系图(ERD):数据建模3. 数据流图(DFD):功能建模4. 状态变迁图(STD):行为建模vi. 数据及数据库需求的表达方法j) 数据流图的层次结构(按照系统的层次结构进行逐步分解并以分层的数据流图反应这种层次结构):画数据流图需要注意的几个问题i. 画数据流图不是画流程图ii. 父图和子图的平衡问题iii. 局部文件的问题:数据流图中引入的文件都是局部文件iv. 分解的深度和层次问题:一个加工的分解最好不要超过7(9)个子加工;尽量减少分解层次;分解要均匀v. 命名问

14、题:数据流的名字应代表整个数据流;加工命名最好由宾语和谓语组成,通常名字中仅包含一个动词k) 数据流图的用途:i. 作为交流信息的工具ii. 作为分析和设计的工具iii. 可以从数据流图出发映射出软件结构l) 数据词典(DD)数据词典与数据流图配合,能清楚的表达数据处理的要求m) 用于写加工逻辑说明的工具i. 结构化英语:是一种介于自然语言和形式化语言之间的语言ii. 判定表:列表示序列号1,2,3.。;行表示条件和操作iii. 判定树:有时候比判定表更直接iv. IPO图:是输入,处理,输出图的简称n) 验证软件需求的正确性i. 一致性ii. 完整性iii. 现实性iv. 有效性o) 软件需

15、求规格说明书通常用自然语言完整,准确具体的描述系统的数据要求,功能需求,性能需求,可靠性和可用性需求,出错处理需求,接口需求,约束逆向需求以及将来可能出现的要求第五章 总体设计(概要设计或初步设计)13. 软件设计过程a) 概要设计:将软件需求转化为数据结构和软件的系统结构,即系统的模块划分b) 详细设计:通过对系统的结构表示(每个模块的内部工作进行细化),得到软件的详细数据结构和算法c) 总体设计的两个主要阶段:i. 系统设计阶段:确定系统的具体实现方案ii. 结构设计阶段:确定软件结构d) 典型的总体设计的九个步骤:i. 设想供选择的方案:需求分析阶段的数据流图是总体设计的极好的出发点ii

16、. 选取合理的方案:通常至少选取低成本,中等成本,高成本的3种方案iii. 推荐最佳方案:iv. 功能分解:对于复杂的大程序,通常分为两个阶段完成。结构设计(总体设计阶段的任务)和过程设计(详细设计阶段的任务)v. 设计软件结构:通常程序中的一个模块完成系统的一个子功能,软件结构(即由模块组成的曾层系统)可以用层次图或结构图来描绘vi. 设计数据库vii. 制定测试计划viii. 书写文档:系统说明,用户手册,测试计划,详细的实现计划,数据库设计结果ix. 审查和复审14. 软件设计原理模块:可单独命名和可编址的部分a) 模块化:就是把程序划分成独立命名而且可独立访问的模块,每个模块完成系统的

17、一个功能,将这些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求b) 抽象:抽出事物的本质而暂时不考虑它们的细节c) 逐步求精:一种自顶向下的设计策略;为了能够集中精力解决主要问题而尽量推迟对问题细节的考虑;Miller法则:一个人在任何时候都只能把注意力集中在(7+-2)个知识快上;求精实际上是细化过程;抽象与求精是一堆互补的概念d) 信息隐藏和局部化:隐藏的模块的实现细节;局部化是指把一些关系密切的软件元素物理地放的彼此靠近e) 模块独立:是模块化,抽象,信息隐藏,局部化概念的直接结果模块独立的两个定量标准:a) 耦合:衡量不同模块彼此间互相依赖(连接)的紧密程度;模块间联系越紧

18、密越多,耦合度就越高,模块的独立性就越差i. 非直接耦合:无直接联系;耦合性最低,独立性最强ii. 数据耦合:一个模块访问另一个模块时,彼此是通过简单的数据参数(不是控制参数,公共数据结构或外部变量)来交换输入,输出信息的;低耦合iii. 标记耦合:一组模块通过参数表(数据结构,不是简单变量)传递信息iv. 控制耦合:如果一个模块传递的信息中有控制信息,明显的控制选择另一模块的功能;中等耦合v. 特征耦合:当把整个数据结构作为参数传递而被调用的模块只是其中的一部分数据元素时vi. 外部耦合:一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息;若不可避免

19、,则尽量集中(例如extern)vii. 公共耦合:若一组模块都访问同一个公共数据环境来相互作用;危险,慎用;(如FORTRAN语言中的COMMON区)viii. 内容耦合:一个模块直接访问另一个模块的内部数据;一个模块有多个入口;耦合度最高,现代高级语言基本上不允许出现内容耦合针对耦合的设计原则:a) 尽量使用数据耦合b) 少用控制耦合和特征耦合c) 限制公共环境耦合的范围d) 完全不用内容耦合b) 内聚:衡量一个模块内部各个元素彼此结合的紧密程度;一个模块各个元素彼此结合的越紧密,内聚度就越高,模块的独立性就越强低内聚i. 偶然内聚:模块各部分之间没有联系,或者即使有联系,这种联系也很松散

20、;内聚度最低ii. 逻辑内聚:把几种相关的功能组合在一起,每次调用时,由传送给模块的判定参数来确定该模块应执行哪一种功能;例如错误处理模块;调用它时要传递参数,形成控制耦合iii. 时间内聚:模块的各个功能的执行与时间有关;例如初始化模块和终止模块中内聚iv. 过程内聚:如果一个模块内的处理是相关的,而且必须以特定的次序执行,则成这个模块是过程内聚模块;例如流程图中的循环部分,判定部分,计算部分;程序流程图的一部分v. 通信内聚:如果一个模块内各功能部分都使用了相同的输入数据,或产生了相同的输出数据;通过数据流图来定义的;数据是联系的纽带高内聚vi. 顺序内聚:元素必须顺序执行,通常一个处理元

21、素的输出数据是作为下一个处理元素的输入数据;根据数据流图划分模块时得到,接近单一vii. 功能内聚:如果模块内多有处理元素属于一个整体,完成一个单一的功能;只做一件事15. 启发规则a) 改进软件结构提高模块独立性:通过模块分解或合并,力争降低耦合提高内聚b) 模块规模应该适中:过大的模块往往分解不充分过小的模块开销大于有效操作c) 深度,宽度,扇出,扇入都应适当:顶层扇出比较高,中层扇出较少,底层扇入高d) 模块的作用域应该在控制域之内:把做判定的点上移,把在作用域不再控制欲内的模块移到控制域内e) 力争降低模块接口的复杂度f) 设计单入口和单出口的模块:避免出现内容耦合g) 模块的功能应该

22、可以预测,避免对模块施加过多限制16. 描述软件结构的图形工具a) 层次图:用来描述系统的层次结构;适用于自顶向下软件设计过程b) HIPO图:层次图家输入/处理/输出图c) 结构图:主要内容是模块和模块之间的调用关系d) 层次图和结构图并不严格表示模块的调用次序,通常用层次图作为描绘软件结构的文档17. 面向数据流的设计方法通常所说的结构化设计方法(SD)就是基于数据流的设计方法;面向数据流的设计方法是把信息流(变换流和事物流)映射成软件结构a) 变换流:书上105页;工作步骤-取得数据,变换数据,给出数据b) 事物流:同上变换分析步骤a) 复查基本系统模型b) 复查并精华数据流图c) 确定

23、数据流图具有变换特性还是事务特性d) 确定输入流和输出流的边界,从而鼓励出变换中心e) 完成“第一步分解”f) 完成“第二步分解”g) 使用设计度量和启发式规则对第一次分割得到的软件结构进一步精化如果数据流怒具有显著的事物特点,最好使用白话分析;反之,如果具有明显的事物中心,则应该采用事物分析技术18. 软件体系结构定义:是对子系统,软件系统构建以及它们之间相互关系的描述构件:软件系统的一个封装构件之间的关系:连接器;可以是过程调用,管道,远程过程调用视图:显示一个软件系统的特定属性数据流风格:批处理序列:管道和过滤器风格;a) 构件:过滤器b) 连接件:数据流传输的管道c) 约束:过滤器必须

24、是独立的实体,它不能与其他的过滤器共享状态d) 语义模型:e) 应用:Unix Shell,编译器调用返回风格:主程序/子程序;数据抽象与面向对象风格;层次风格a) 将数据的表示和相关操作封装在一个抽象数据类型或对象中b) 构件:对象(抽象数据类型的实例)c) 连接件:对象的方法,过程的调用d) 约束:对象要负责保证其数据表述的完整性;对象的数据表示对其他对象来说是隐藏的层次系统风格a) 层次系统组织成一个层次结构,每一层为上层服务并作为下层的客户b) 构件:各层次内部包含的构件c) 连接件:层间交互的协议d) 拓扑机构:分层e) 拓扑约束:对相邻层间交互的约束f) 应用:分层通信系统,数据库

25、系统,操作系统。g) 优点:支持基于抽象程度递增的系统设计;支持功能增强;支持重用;对标准化的支持独立构件风格:进程通讯,事件系统 基于事件/隐式调用风格a) 思想是构件不直接调用一个过程,而是发布或广播一个或多个事件b) 构件:是这样一些模块:它们的接口既提供了一些过程,也有一些事件的集合。这些过程既可以用一般的方式调用,也可能被注册为与某些事件相关。c) 连接件:对过程的显示或隐式调用d) 应用:在编程环境中用于集成各种工具;在数据库管理系统中确保数据的一致性约束;在用户界面中分离数据和表示;在编辑器中支持语法检查。仓库风格:数据库系统;黑板系统a) 构件:中央数据结构说明当前状态,一组独

26、立构件对中央数据结构进行操作b) 连接件:仓库和独立构件间的交互c) 黑板系统:由知识源,黑板数据结构,控制器组成;举例:语音识别虚拟机风格:解释器,基于规则的风格解释器风格a) 构件:转换伪代码和模拟它所代表的程序的解释引擎;包含待解释伪代码的存储器;解释引擎的当前状态;正在模拟的程序的当前状态。b) 连接件:过程调用和直接存储器访问c) 优点:有助于应用程序的可移植性和程序设计语言的跨平台能力d) 应用:程序语言的编译器;基于符规则的系统,脚本语言其他类型的枫哥哥:客户/服务器风格a) 构件:客户构件,服务器构件b) 连接件:某种进程间通信机制,通常是基于RPC的交互协议。c) 基于资源不

27、对等为实现共享而提出第六章 详细设计19. 详细设计概要a) 根本目标:确定应该够怎样具体的实现所要求的系统b) 包括:接口设计(人机界面),过程设计20. 人机界面设计a) 黄金原则:赋予用户控制权,减少用户的记忆负担,保持界面一致b) 设计过程:用户、任务和环境分析及建模,界面设计,界面构造,节目确认c) 一般问题:系统响应时间,用户帮助设施,出错信息处理,命令方式21. 过程设计技术和工具a) 结构化程序设计技术是详细设计的逻辑基础b) 程序的三种控制结构:顺序,选择,循环过程设计工具a) 程序流程图(程序框图)。i. 不易表示数据结构ii. 本质上不是逐步求精的好工具iii. 只能使用

28、物种基本的控制结构:顺序型,选择型,先判定型循环(DO-WHILW),后判定型循环(DO-UNTIL),多情况选择型(CASE)b) 盒图(N-S图)c) PAD图i. 用二维树形结构的图来表示程序的控制流ii. 五种控制结构,并允许递归使用iii. 使用PAD符号所设计出来的程序必然是结构化程序iv. 判定表d)i. 当算法中包含多重嵌套的条件选择时使用判定表ii. 判定表用于表示程序的静态逻辑。iii. 能够简洁、无二义性地描述所有的处理规则。e) 判定树i. 判定树是判定表的变种。ii. 形式简单,比判定表更直观iii. 简洁性不如判定表;f) 过程设计语言(PDL)22. 面向数据结构

29、的设计方法a) Jackson方法b) Warnier方法23. 程序复杂程度的定量度量利用McCabe方法计算环形复杂度a) 流图中的区域数等于环形复杂度。b) V(G)EN+2c) V(G)P+1特点:a) 简单IF语句与循环语句的复杂性同等看待;b) 嵌套IF语句与简单CASE语句的复杂性是一样的;c) 模块间接口当成一个简单分支一样处理;d) 一个具有1000行的顺序程序与一行语句的复杂性相同。e) 环路复杂度是可加的。f) 在McCabe复杂度为10的附近,存在出错率的间断跃变。利用Halstead方法计算环形复杂度A)它根据程序中运算符和操作数的总数来度量程序的复杂程度。第七章 实

30、现24. 编码a) 程序的质量主要取决于软件设计的质量,但所选用的程序设计语言的特点及编码风格也将对程序的可靠性、可读性、可测试性和可维护性产生深远的影响。b) 编码风格i. 源程序文档化:程序内部的文档包括适当的标识符,适当的注解和程序的视觉组织ii. 数据说明方法:数据说明的次序应当规范化,使用注释说明赋值数据结构iii. 语句构造:一行一条语句;尽量减少 “非”条件的测试;避免大量使用循环嵌套和条件嵌套;利用括号使逻辑表达式或算术表达式的运算次序清晰直观;输入/输出方法;除非对效率有特殊的要求,程序编写要做到清晰第一,效率第二;首先要保证程序正确,然后才要求提高速度。让编译程序做简单的优

31、化;避免使用临时变量而使可读性下降;尽可能使用库函数;iv. 程序效率:程序的效率是指程序的执行速度(处理机时间)及程序占用的内存的存储空间(存储器容量)。25. 软件测试基础a) 软件测试是为了发现错误而执行程序的过程。b) 根本目标:尽可能多地发现并排除软件中潜藏的错误c)Pareto原理说明,测试发现的错误中的80很可能是由程序中20的模块造成的。25. 软件测试步骤a) 模块测试(单元测试):测试每个模块,发现的往往是编码和详细设计的错误。b) 子系统测试(集成测试):着重测试模块的接口c) 系统测试(集成测试):发现的往往是软件设计中的错误,也可能发现需求说明中的错误。d) 验收测试

32、(确认测试):目的是验证系统确实能够满足用户的需要。发现的往往是系统需求说明书中的错误。e) 平行运行:是同时运行新开发出来的系统和将被它取代的旧系统,以便比较新旧两个系统的处理结果。f) 通常由程序员负责调试26. 单元测试a) 检测对象:模块b) 检测方法:主要使用白盒测试技术c) 检测重点:模块接口,局部数据结构,重要的执行通路,出错处理通路。边界条件d) 实际测试方法:非执行测试:桌前检查,走查(比审查步骤少,不那么正式),审查(比走查更深入),程序的正确性证明;执行测试:计算机测试(需要驱动程序和存根程序)26. 集成测试把经过单元测试的模块放在一起形成一个子系统来测试,着重测试模块

33、的接口。a) 一次性集成i. 当所有组件都单独测试完毕之后,将它们一次性混合起来组成最终的系统,查看其是否能够运行成功。ii. 需要存根程序和驱动程序来测试独立的组件。b) 自顶向下集成i. 从主控制模块开始,沿着程序的控制层次向下移动,逐渐把各个模块结合起来。ii. 能够在测试的早期对主要的控制或关键的抉择进行检验。 iii. 使用深度优先,可以在早期实现软件的一个完整的功能并且验证这个功能。iv. 不需要驱动程序,需要存根程序c) 自底向上集成i. 自底向上测试从“原子”模块(即在软件结构最低层的模块)开始组装和测试,ii. 不需要存根程序。iii. 当底层有许多组件是有多种用途的公用例程

34、而经常被其他组件调用时、当设计是面向对象的或当系统由大量孤立的复用的组件组成时,自底向上方法是很有用的。iv. 底层模块可以并行测试d) 三明治集成i. 将自顶向下策略与自底向上策略结合起来,在顶层使用自顶向下方法,而在较低的层使用自底向上方法。ii. 允许在测试的早期进行集成测试。27. 确认测试a) 目标是验证软件的有效性。b) 需求阶段产生的需求规格说明书或类似文档是软件有效性的标准,也是进行确认测试的基础。c) 以用户为主来进行d) 使用黑盒测试法e) 重要内容是复查软件配置。f) 复查的目的是保证软件配置的所有成分都齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节

35、,而且已经编好目录。 g) Alpha测试由用户在开发者的场所进行,受控的环境h) Beta测试由软件的最终用户们在一个或多个客户场所进行,真实的环境27. 白盒测试测试对象看做一个透明盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序的所有逻辑路径进行测试。a) 逻辑覆盖i. 语句覆盖:使得每一可执行语句至少执行一次ii. 判定覆盖:使得程序中每个判定的取真分支和取假分支至少经历一次iii. 条件覆盖:每个判定中的每个条件的可能取值至少执行一次。iv. 判定/条件覆盖:使得判定表达式中的每个条件都取到各种可能的值,而且每个判定表达式也都取到各种可能的结果。(由于

36、条件隐藏,使得逻辑表达式中的错误不一定都能查得出来。)v. 条件组合覆盖:使得每个判定中条件的所有可能组合至少出现一次,最强覆盖标准vi. 点覆盖:点覆盖标准和语句覆盖标准是相同的。 vii. 边覆盖:通常边覆盖和判定覆盖是一致的。 viii. 路径覆盖:每条可能路径都至少执行一次b) 结构控制测试i. 基本路径测试:可以保证程序中的每条语句至少执行一次,而且每个条件在执行时都将分别取真、假两种值。ii. 条件测试:能够检查程序模块中包含的逻辑条件。iii. 循环测试:简单循环,嵌套循环,串接循环28. 黑盒测试(在程序接口上测试)把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构

37、和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。a) 等价划分i. 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖的有效等价类,重复这一步,直到所有的有效等价类都被覆盖为止ii. 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步,直到所有的无效等价类都被覆盖为止b) 边界值分析:大量的错误是发生在输入或输出范围的边界上c) 错误推测:人们也可以靠经验和直觉推测程序中可能存在的各种错误d) 因果图:如果在测试时必须考虑输入条件的各种组合,可使用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来设计测试用例,测试策略:A) 在任何情况下

38、都必须使用边界值分析方法B) 要时用等价类划分方法补充一些测试用例C) 用错误推测法再追加一些测试用例。D) 如果程序的功能说明中含有输入条件的组合情况,则一开始就可选用因果图法。29. 调试软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同,调试的任务是进一步诊断和改正程序中潜在的错误。a) 蛮干法(强行排错)b) 回溯法c) 原因排除法:有对分查找法,归纳法,演绎法30. 软件可靠性a) 软件可靠性:是程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。系统的稳态可用性为:Ass=MTTF/(MTTF+MTTR)MTTF:系统平均无故障时间 MTTR:平均维修时间b)

39、 软件可用性:是程序在给定的时间点,按照规格说明书的规定成功地运行的概率。 第八章 软件维护31. 软件维护的定义a) 软件维护:就是在软件已经交付之后,为了改正错误或者满足新的需求而修改软件的过程b) 完善性维护,适应性维护,改正性维护,预防性维护32. 软件维护的特点a) 结构化维护:有完整的软件配置,能够提高维护的整体质量b) 非结构化维护:缺少文档使得维护的的代价巨大33. 软件维护的过程a) 软件组织内部应该制定出一个软件修改报告34. 软件的可维护性a) 定义:维护人员理解,改正改动或改进这个软件的难易程度b) 因素:可理解性,可测试性,可修改性,可移植性,可重用性c) 可维护性复

40、审:i. 在需求分析阶段的复审过程中,应该对将来要改进的部分和可能会修改的部分加以注意并指明;应该讨论软件的可移植性问题,并且考虑可能影响软件维护的系统界面ii. 在正式的和非正式的设计复审期间,应该从容易修改、模块化和功能独立的目标出发,评价软件的结构和过程;设计中应该对将来可能修改的部分预做准备iii. 代码复审应该强调编码风格和内部说明文档这两个影响可维护性的因素iv. 在测试结束时进行最正式的可维护性复审,这个复审称为配置复审。配置复审的目的是保证软件配置的所有成分是完整的、一致的和可理解的,而且为了便于修改和管理已经编目归档了v. 在完成了每项维护工作之后,都应该对软件维护本身进行仔

41、细认真的复审35. 预防性维护a) 把今天的方法学应用到昨天的系统上,以支持明天的需求36. 软件工程再工程a) 库存目录分析b) 文档重构c) 逆向工程:在比源代码更高的抽象层次上创建出程序的某种表示的过程,也就是说,逆向工程是一个恢复设计结果的过程d) 代码重构e) 数据重构f) 正向工程:改变或重构现有系统第十三章 软件项目管理37. 软件项目管理概述a) 有效的项目管理集中于:人员,产品,过程,项目38. 软件项目中的人员与组织结构a) Brooks定律:向已经延期的软件项目中添加人手只会使进度更加落后。b) Boehm根据经验指出:软件项目的开发时间最多可以减少到正常开发时间的75c

42、) 项目组组织得越好,其生产率越高,而且产品质量也越好d) 民主制程序组-民主分散式:组员们享有充分民主,有利于攻克技术难关e) 主程序猿族-控制集中式:专业化和层次性f) 现代程序员组-集中式:适用于大型项目,简单重复的问题,模块化程度高的问题,周期固定,较短的大项目g) 分散式:复杂,创新的问题,模块化较低的问题,小项目,周期长的项目39. 软件项目的成本与工作量估算a) 代码行技术指标i. 生产率 KLOCPM(人月)ii. 成本 元LOCiii. 质量 错误数KLOCiv. 文档 文档页数KLOCb) 功能点技术:对软件信息域和软件复杂性来评估,功能点(FP),对象点指标i. 生产率 FPPM(人月)ii. 成本 元FPiii. 质量 错误数FPiv. 文档 文档页数FP40. 软件项目的风险核心风险a) 进度安排的先天错误b) 需求膨胀c) 人员的流失d) 规约崩溃41. 软件项目进度计划Gantt(甘特)a) 不能显式地描绘各项作业彼此间的依赖关系b) 进度计划的关键部分不明确c) 计划中有潜力的部分及潜力的大小不明确工程网络a

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论