软件工程复习资料.docx
《软件工程复习资料.docx》由会员分享,可在线阅读,更多相关《软件工程复习资料.docx(33页珍藏版)》请在冰豆网上搜索。
软件工程复习资料
第一章软件工程概述
一、软件危机
1.概念:
软件危机是指在计算机软件开发、使用与维护过程中遇到的一系列严重问题。
2.为什么会产生软件危机?
当软件开发技术的进步不能跟上硬件技术的进步,未能满足发展的要求,致使软件开发中遇到的问题找不到解决的办法,使问题积累起来,形成了尖锐的矛盾,因而导致了软件危机。
3.软件危机的表现:
⏹经费预算经常突破,完成时间一再拖延
⏹开发的软件不能满足用户要求
⏹开发的软件可维护性差
⏹开发的软件可靠性差
4.产生软件危机的原因:
⏹软件的规模越来越大,结构越来越复杂
⏹软件开发管理困难而复杂
⏹软件开发费用不断增加
⏹软件开发技术落后
⏹软件的生产方式、开发工具落后,生产率提高缓慢
⏹其它,如:
软件本身的特点、没有适当的文档资料、用户需求的不明确、缺乏好的开发方法和手段等
5.缓解软件危机的途径——软件工程
二、软件工程
1.软件工程定义
用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程。
2.软件工程三要素
⏹方法:
研究软件开发“如何做”的技术。
⏹工具:
研究支撑软件开发方法的环境。
⏹过程:
将方法、工具综合起来,以达到合理、及时进行计算机软件开发的目的。
3.目标
⏹付出较低的开发成本,达到要求的软件功能;
⏹取得较好的软件性能;
⏹开发的软件易于移植;
⏹需要较低的维护费用;
⏹能按时完成开发任务,及时交付使用;开发的软件可靠性高
(即在保证质量和效率的同时,尽量缩短开发期,降低成本,最终要高性能与可靠性。
目的是使软件生产规范化和工程化。
)
三、软件生存周期
1.定义
指从提出软件开发要求开始,直到该软件报废不用为止的整个时期。
这个时期又分为若干个阶段,对软件生产的管理和进度控制有重要作用,使软件的开发有相应的模式、流程、工序和步骤。
2.划分
可将软件生存周期划分为3个过程共8个阶段:
*3个过程是:
软件定义、软件开发、软件维护。
*8个阶段有:
问题定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试、维护
3.各阶段的基本任务:
通常包括以下4类基本过程:
1.软件规格说明:
规定软件的功能及其运行环境。
2.软件开发:
产生满足规格说明的软件。
3.软件确认:
确认软件能够完成客户提出的要求。
4.软件演进:
为满足客户的变更要求,软件必须在使用的过程中演进。
四、软件工程过程
1.软件开发模型:
(软件生存周期模型、软件过程模型)
——软件开发全部过程、活动和任务的结构框架。
它能直观表达软件开发全过程,明确规定要完成的主要活动、任务和开发策略。
2.软件开发模型的几种类型:
⏹以软件需求完全确定为基础的瀑布模型;
⏹在开发初期仅给出基本需求的渐进式模型,如原型模型、螺旋模型、喷泉模型等;
⏹以形式化开发方法为基础的变换模型、基于四代技术的模型;基于知识的智能模型等等。
⏹基于知识的智能模型
Ø瀑布模型
基本思想:
根据软件生命周期各阶段的任务,从问题定义开始,逐步进行阶段性变换,就像瀑布一样从上流下来,称为瀑布型。
它规定了各阶段的任务和应提交的成果及文档,每一阶段的任务完成后,都必须对其阶段性产品(主要是文档)进行评审,通过后才能开始下一阶段的工作。
因此,它是一种以文档作为驱动的模型。
特点:
①阶段间具有顺序性和依赖性
②推迟实现的观点
③质量保证的观点。
缺点:
1)在开发初期就要给出全部的需求,是不大容易确定的。
2)这种预先定义需求的方法不能适应用户需求的不断变化。
3)开发周期长,承担的风险也比较大。
4)缺乏灵活性,对开发过程中很难发现的错误,只有在最终产品运行时才能暴露出来,从而使软件产品难以维护,不适应实际的开发过程。
适应的场合:
瀑布模型一般适用于功能、性能明确、完整、无重大变化的软件系统的开发。
例如操作系统、编译系统、数据库管理系统等系统软件的开发。
应用有一定的局限性。
Ø增量模型
基本思想:
瀑布模型属于整体开发模型,而增量模型属于非整体开发模型。
开发软件时,把软件产品作为一系列增量构件来设计、编码、集成和测试,每个构件由若干个相互协作的模块组成,并且能完成相对独立的功能。
特点:
能在较短的时间内向用户提交可完成部分工作的产品;逐步增加产品功能,从而使用户有较充裕的时间学习和适应新产品,减少一个全新的软件给客户组织带来的冲击。
缺点:
要求软件工程师必须具有较高的技术水平,能设计出开放式的软件体系结构。
适应的场合:
瀑布模型适合于需求明确的软件项目,而增量模型适合于需求不明确的软件项目。
Ø螺旋模型
基本思想:
将瀑布模型和增量模型相结合,并加入了风险分析,沿螺旋线自内向外每旋转一圈便开发出更为完善的一个新的软件版本。
在每个螺旋周期内分为制定计划、风险分析、开发实施和用户评估四个步骤。
⏹制定计划:
确定目标、选定方案、弄清开发的限制条件
⏹风险分析:
评价方案、识别风险、消除风险。
⏹开发实施:
实施软件开发
⏹客户评估:
评价开发工作,提出修正建议。
特点:
⏹模型结合性
⏹过程迭代性
⏹减少了过多测试或测试不足带来的风险
缺点:
⏹开发过程复杂,给过程管理和控制带来难度
⏹使用该模型需要有相当丰富的风险评估经验和专门知识,要求开发队伍水平较高。
⏹适应的场合:
⏹吸收了软件工程“演化”的概念,适合于大型软件的开发
Ø喷泉模型
基本思想:
它是以用户需求为动力,以对象来驱动的模型,适合以面向对象的软件开发方法。
特点:
⏹各阶段相互重叠,反映了软件过程并行性的特点
⏹在开发过程有4个阶段,即分析、系统设计、软件设计和实现
⏹开发过程具有迭代性和无间隙性
缺点:
过程在喷泉模型中已被弱化
Ø快速原型模型
基本思想:
快速原型模型是针对瀑布模型的缺点提出来的。
在项目的早期就尽快生产出一个简化且便宜的原型版本。
即在软件开发初期先从用户的基本功能出发,开发构造系统的原型,并由系统使用者试用,从中发现需求的错误或遗漏的地方,从而确定需求并保证需求的有效性。
开发的途径:
1)仅模拟软件系统的人机界面和人机交互方式。
2)开发一个工作模型,实现软件系统中重要的或容易产生误解的功能。
3)利用一个或几个类似的正在运行的软件向用户展示软件需求中部分或全部功能。
特点:
⏹原型驱动性:
通过围绕原型来确认用户需求,反复修改最终得到用户确认的软件定义。
⏹过程的交互性和迭代性:
开发人员和用户之间不断评价原型而进行的一个交互过程,且不断改进和完善的迭代过程。
⏹允许用户完善对软件系统的需求,开发周期相对缩短、成本较低。
⏹是一种自外向内型的设计过程
缺点:
⏹是用户和设计人员交换最频繁的方法,频繁的需求变化会使开发进程难于管理和控制;
⏹这种模型对技术要求较高
适应的场合:
它适合于那些不能预先确切定义需求的软件系统的开发,更适合于那些项目组成员(包括分析员、设计员、程序员和用户)不能很好交流或通信有困难的情况。
Ø其它模型:
⏹变换模型——基于形式化规格说明语言及程序变换的软件开发模型。
⏹基于四代技术的模型——一种面向问题而非面向过程的语言。
✧应用题
假设你被任命为一家软件公司的项目负责人,你的工作是管理该公司已经被广泛应用的字处理软件个新版本开发。
由于市场竞争激烈,公司规定了严格的完成期限并且已经对外公布。
你打算采用哪种软件生命周期模型?
为什么?
第二章需求工程
一、为什么要进行需求分析?
⏹开发人员往往急于求成
⏹希望对开发进行指导
⏹希望开发人员对用户的要求理解
⏹希望用户理解开发人员
⏹测试部门有理可依——该阶段定义的标准将成为软件测试阶段的测试目标
二、基本任务和主要工作
1.基本任务:
准确的定义新系统目标,为了满足用户需要,回答系统必须“做什么”的问题。
2.主要工作:
1)问题识别。
双方确定对问题的综合需求。
2)分析与综合,导出软件的逻辑模型。
分析人员对获取的需求,进行一致性的分析检查,划分成各个子功能,确定系统的构成及主要成份,并用图文结合的形式,建立起新系统的逻辑模型。
3)编写文档。
最终结果是产生“需求规格说明书”、编写初步用户使用手册、编写确认测试计划、修改完善软件开发计划。
3.需求获取非常困难的主要原因有:
⏹用户需求的复杂性
⏹涉及各方面人员引起的交流障碍
⏹用户对需求陈述的不完备性和不一致性
⏹需求的易变性
4.需求分析的步骤
⏹分析系统的各种需求
⏹建立系统的逻辑模型
⏹修正开发计划
⏹开发原型系统
⏹验证软件需求的正确性
⏹编写软件需求规格说明书
Ø结构化分析方法(SA)
1.SA法的基本思想——“分解”和“抽象”
分解:
对于一个复杂的系统,为了将复杂性降低到可以掌握的程度,可以把大问题分解成若干小问题,然后分别解决。
抽象:
分解可以分层进行,即先考虑问题最本质的属性,暂把细节略去,以后再逐层添加细节,直至涉及到最详细的内容,这种用最本质的属性表示一个系统的方法就是“抽象”。
2.SA方法分析策略:
自顶向下逐步求精
3.SA法的步骤:
1调查了解当前系统的工作流程,建立当前系统的具体模型
2抽象出当前系统的逻辑模型,建立当前系统的逻辑模型
3对当前系统的逻辑模型进行分析,建立目标系统的逻辑模型
4完善目标系统,写出目标系统的软件需求规格说明书
5对软件需求规格说明书进行评审
4.SA法的优缺点
优点:
结构化分析方法是软件需求分析中公认的、有成效的、技术成熟、使用广泛的一种方法,它较适合于开发数据处理类型软件的需求分析。
该方法利用图形等半形式化工具表达需求,简明、易读,也易于使用,为后一阶段的设计、测试、评价提供了有利的条件。
缺点:
(1)SA方法的主要工具DFD体现了系统“做什么”的功能,但它仅仅是一个静态模型,不适合描述实时控制系统。
(2)对于一些频繁的人机交互的软件系统,DFD不适合描述人机界面系统的需求。
(3)描述软件需求的精确性有待提高。
ØSA法的描述方法
1.分层的数据流图(DFD图)
2.数据词典
3.判定表及判定树
4.描述加工逻辑的结构化语言
1.数据流图——基本图形符号:
✧应用题:
定货系统:
假设一家工厂的采购部每天需要一张定货报表,报表按需件编号排序,表中列出所有需要再次定货的零件。
对于每个需要再次定货的零件,应该列出下述数据:
零件编号、零件名称、定货数量、目前价格、主要供应者、次要供应者、零件入库或出库称为事务。
通过放在仓库中的CRT终端把事务报告给定货系统。
当某种零件的库存数量少于库存量临界值时就应该再次定货。
第一步:
从问题描述中提取数据流图的四种成分:
源点或终点、处理、数据存储、以及数据流。
(1)数据的源点/终点
采购员是数据终点,仓库管理员是数据源点。
(2)处理
①采购部需要报表→说明没有报表→要有一个“产生报表”的处理。
②零件库或出库(事务)→改变零件库存量→要有“事务加工”处理。
(3)数据流
①要求系统把定货报表送给采购部→“定货报表”是一个数据流。
②事务要从仓库送到系统中→“事务”是另一个数据流。
(4)数据存储
①当有五个事务发生时立即要处理,但每天只产生一次定货报表→说明“事务加工”与“产生报表”这两个