软件工程问题整理版.doc_第1页
软件工程问题整理版.doc_第2页
软件工程问题整理版.doc_第3页
软件工程问题整理版.doc_第4页
软件工程问题整理版.doc_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

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

文档简介

1、 软件危机定义、发生原因、常见表现,如何避免软件危机?(1) 软件危机定义:课本Page 8(开发和维护过程)(2) 发生原因、常见表现:课本Page 8-9,练习册Page 1(3) 如何避免:Page 10 (采用软件工程的方法)答案(由于大部分答案参考ppt,故仅供参考,下同)软件危机定义:是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。表现在:()对于软件开发的成本和进度的估计很不准确。()开发的软件产品不能完全满足用户要求,用户对已完成的软件系统不满意的现象常常发生。()开发的软件可靠性差。()软件通常没有适当的文档。()软件的可维护性差。()软件开发生产率提高的速度,远远跟不上计算机应用普及深入的趋势。原因:()软件的规模愈发庞大;()软件开发的管理困难。()成功的软件开发经验没被很好地应用。()软件开发和维护中千金错误认识和方法的形成可以归结与计算机发展早期软件开发的个体化特点。()软件开发技术落后。()生产方式落后。()开发工具落后,生产率提高缓慢。如何避免(参考,可以自己总结):从软件开发的工程化方法入手,即用现代工程的概念原理、技术和方法去指导软件的开发、管理和维护,这就是软件工程思想和方法。具体措施:(1)使用好的软件开发技术和方法;(2)要有良好的组织、严密的管理,各类人员协同配合,共同完成任务;(3)使用好的软件开发工具,提高软件生产率;(4)建立严格的文档资料,重视软件开发过程的阶段评审。2、软件生命周期模型(软件生命周期?)的组成,每个阶段的内容?(1)组成:Page 21 (2)内容:Page 2225)答案:软件生存周期定义:一个软件从定义到开发、使用和维护,直到最终被弃用,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。软件生存周期一般可分为以下阶段:(1) 问题定义(2)可行性研究(3)需求分析 (4)概要设计(总体设计)(5)详细设计 (6)编码 (7)测试 (8)维护也可以分为四个大的阶段:软件分析、软件设计、编码与测试、运行与维护()软件分析时期;任务:确定软件项目的目标,软件应具备的功能和性能,构造软件的逻辑模型,并制定验收标准。在此期间,要进行可行性论证,并做出成本估计和经费预算,制定进度安排。进行可行性研究和项目开发计划,需求分析。()软件设计时期;任务:a.设计软件的总体结构;b.设计软件具体模块的实现算法;c.软件设计结束之前,也要进行有关评审,评审通过后才能进入编码时期。()编码与测试时期;任务:组织程序员将高驻地的软件“翻译”成计算机可以正确运行的程序;并且要经过按照软件分析中提出需求要求和验收标准进行严格的测试和审查。根据具体软件的特点,决定是否划分成一些阶段,如编码、单元测试、集成测试、验收测试等等。()运行与维护时期。任务:软件运行过程中可能由于各方面的原因,需要对它进行修改。3、瀑布模型、原型模型、增量模型的特点,如何选择这些模型?(1)瀑布模型:Page 25-27(特点:Page 28第二点;使用场合:特点的最后一点)(2)原型模型:Page 27-28(特点:Page 27; 场合:Page 28三点)(3)增量模型:Page 28)参考答案:瀑布模型:(1)定义:是将软件生命周期各活动规定为依线性顺序联接的若干阶段的模型,是一种整体开发模型。里程碑或基线驱动或者说文档驱动。过程逆转性很差,或者说不可逆转。(2)优点:严格按照生命周期的各个阶段来进行开发,强调了每一阶段的严格性。这样就能解决在开发阶段后期修正不完善的需求说明将花费巨大的费用的问题。在消除非结构化软件、降低软件的复杂性、促进软件开发工程化方面起了很大作用。(3)缺点:它是一种理想的线性开发模式,缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题。故适用于功能明确、完整、无重大变化的软件开发。如:编译系统、数据库管理系统和操作系统。(4)适用场合: 在开发时间内需求没有或很少变化。 分析设计人员对应用领域很熟悉。 低风险项目(对目标、环境很熟悉)。 用户使用环境很稳定。 用户除提出需求以外,很少参与开发。原型模型:(1)定义:以某个软件原型为参照模型的开发方法,叫做原型法。(原型驱动)(2)原理:在初步需求分析之后,马上向客户展示一个软件产品原型,对客户进行培训,让客户试用,在试用中收集客户意见,修改原型,再让客户试用,反复循环几次,直到客户确认为止。(3)适用场合: 已有产品/产品原型,只需客户化的项目。 简单而熟悉的行业或领域。 有快速原型开发工具。 进行产品移植或升级。增量模型:(1)定义:增量模型将软件产品看作一组增量构件,每次设计、实现、集成、测试和交付一块构件,直到所有构件全部实现为止。(2)特点:任务或功能模块驱动,可以分阶段提交产品;有多个任务单,这些多个任务单的集合,构成项目的一个总任务书(总用户需求报告)。(3)适用场合: 在开发过程中,客户接受分阶段交付。 开发人员对应用领域不熟悉,难以一步到位。 工期过紧的中等或高风险项目。 用户可参与到整个软件开发过程中。 使用面向对象语言或第四代语言。 软件公司自己有较好的类库、构件库。4、需求的特点?获取的方法?为什么需求获取很困难?如何解决需求获取困难的难题?(1)需求的特点: 可验证性:可验证性是软件需求的基本属性。软件需求必须是可验证的,否则软件的评审和测试就没有相应的依据。但在某些情况下,很难对某些软件需求进行验证或需要的代价很高。软件需求人员和测试人员应以合理的代价实现需求的验证。 优先级:软件需求应具有优先级,可以在有限的资源情况下进行取舍。 唯一性:软件需求应唯一地标识出来,以便在软件配置管理和整个软件生命周期中进行管理。(2)获取方法: 1、面谈和问卷调查; 2、小组讨论;3、情景串联;4、参与、观察业务流程;5、现有产品和竞争对手的描述文档;6、市场资料(3)需求获取困难原因:PPT答案: 用户需求具有动态性,即需求的不稳定性。在整个软件生存周期内,应用软件的需求会随着时间的进展而有所变化。个别用户,甚至是朝三暮四地变化。 用户需求具有模糊性,即需求不准确性。由于用户的素质不是很高,业务流程不很规范,所以需求表达不很清楚也不够明确。 开发者和用户要对需求达成完全一致的认识,用户要在需求报告上签字,要承担责任。 需求复杂并且庞大。现代的软件,规模越来越大,导致需求越来越复杂。课本上答案(Page 62): 需求易变性。用户在开始时提出一些功能需求,当对系统有一定的理解后,会提出一些需求。以后随着理解的深入而不断提出新的需求。用户需求的变动是一个极为普遍的问题,即使是部分变动,也往往会影响到需求分析的全部,导致不一对待性和不完备性。 问题的复杂性; 交流障碍。进行需求分析的人员具备不同的背景知识,处于不同的角度,扮演不同的角色,造成了相互之间交流的困难。 不完备性和不一致性。用户各类人员对于系统的要求所处的角度不一样,对问题的陈述往往是不完备的,其各方面的需求还可能存在着矛盾。(4)解决需求获取困难的方法:把一个复杂问题按功能进行分解并可逐层细化;能够表达和理解问题的数据域和功能域;建立模型5、DFD的画法及如何将DFD图转换成功能结构图?(1) DFD图的画法(课本Page 71)(第四章PPT) 数据流图DFD的描述符号主要只有四种,即: a. 数据源或数据潭 b. 数据流动的连线 c. 数据加工或处理泡 d. 输入或输出文件 图例名称图例说明信息源或信息潭表示信息源或信息潭,即数据流的起点或终点加工或处理表示对流到此处的数据进行加工或处理,即对数据的算法分析与科学计算输入文件/输出文件 _ _表示输入文件或输出文件,说明加工或处理之前的输入文件,记录加工或处理之后的输出文件数据流连线表示数据流的流动方向 方法:采用的是”自顶向下“逐层画法。即先画出的顶层数据流图,再逐层画出的底层数据流图,具体地描述上层系统的细节。 注意事项:加工和处理框上至少有一个输出数据流和一个输入数据流;注意父/子图的平衡(父图中某个加工的输入输出数据流同相应的子图的输入输出相同,也就是说子图中所有输入数据流必须是父图中相应加工的输入)。(2) DFD图转换成功能结构图(课本Page 111-116)(PPT 第七章)具体方法看第七章PPT。变换型系统结构图:通过变换分析技术,将中心变换型的DFD图转换而得的SC图,称为变换型系统结构图。事务型系统结构图:通过事务分析技术,将事务处理型的DFD图转换为的SC图,称为事务型的系统结构图。两类图的区别:变换型系统结构图明显分为输入、中心变化和输出3部分;事务型系统结构图则是某个变换将它的输入分离成若干个发散的输出数据流。变换分析技术(将DFD图转换成变换型系统结构图的方法,DFD图中含有变换流的情况)事务分析技术(将DFD图转换成事务型系统结构图的方法,DFD图中含有事务流的情况)而实际的DFD图往往是既包含变换流又包含事务流(称为混合DFD图)。PPT上的M代表中心加工模块,I代表输入模块,T代表处理加工模块,O代表输出模块。对于变化型系统结构图而言,一个M应该包含一个I、一个T、一个O,属于包含关系,因此箭头应从M分别指向I、T、O(容易出错)。一个功能模块的输入可能是来源于另一个功能模块的输出。6、面向对象的基本特征,并能用实际的例子说明这些特征?面向对象的基本概念: 面向对象不仅是一些具体的软件开发技术与策略,而且是一整套关于如何看待软件系统与现实世界的关系,以什么观点来研究问题并进行求解,以及如何进行系统构造的软件方法学。而面向对象方法是一种运用对象、类、继承、封装、聚合、消息传送、多态性等概念来构造系统的软件开发方法。面向对象方法的基本思想是,从现实世界中客观存在的事物(即对象)出发来构造软件系统,并在系统构造中尽可能运用人类的自然思维方式。面向对象核心概念: (1)对象(2)类(3)继承(4)聚集(5)消息。面向对象 = 对象 + 类 + 继承 + 聚集 + 消息面向对象方法的基本特征: 从问题域中客观存在的事物出发来构造软件系统,用对象作为对这些事物的抽象表示,并以此作为系统的基本构成单位。事物的静态特征(即可以用一些数据来表达的特征)用对象的属性表示,事物的动态特征(即事物的行为)用对象的服务(或操作)表示。对象的属性与服务结合为一体,成为一个独立的实体,对外屏蔽其内部细节(称作封装)。对事物进行分类。把具有相同属性和相同服务的对象归为一类,类是这些对象的抽象描述,每个对象是它的类的一个实例。通过在不同程度上运用抽象的原则(较多或较少地忽略事物之间的差异),可以得到较一般的类和较特殊的类。特殊类继承一般类的属性与服务,面向对象方法支持对这种继承关系的描述与实现,从而简化系统的构造过程及其文档。复杂的对象可以用简单的对象作为其构成部分,称作聚合。对象之间通过消息进行通信,以实现对象之间的动态联系。通过关联表达对象之间的静态关系。7、白盒测试、黑盒测试的定义以及白盒测试具体的方法?练习册Page 318-320;课本Page 457-461;第十章PPT(1)定义:白盒测试:把测试对象看作一个透明的盒子,测试人员能了解程序的内容结构和处理过程,以检查处理过程为目的,对程序中尽可能多的逻辑路径进行测试,在所有的点检验内部控制结构和数据结构是否和预期相同。白盒测试又称为结构测试或逻辑驱动测试。黑盒测试:该方法把被测试对象看成一个黑盒子,测试人员完全不考虑程序的内部结构和处理过程,只在软件的界面上进行测试,用来证实软件功能的可操作性,检查程序是否满足功能要求,是否能很好的接收数据,并产生正确的输出。黑盒测试也称功能测试。(2)白盒测试方法(3种) 逻辑覆盖语句覆盖:-在测试时,设计若干测试用例,运行被测程序,使程序中的每个可执行语句至少执行一次。判定覆盖(又称为分支覆盖):-在测试时,设计若干测试用例,运行被测程序,使程序中的每个判断真假的分支至少遍历一次。条件覆盖:-在测试时,设计若干测试用例,运行被测程序,使程序中的每个条件的可能取值至少满足一次。条件分支覆盖:-在测试时,设计足够的测试用例,使得判断中每个条件的所有可能取值至少出现一次,并且每个判断本身的判定结果也至少出现一次。路径覆盖:- 设计足够多的测试用例,要求覆盖程序中所有可能的路径。 循环覆盖 基本路径覆盖(3)关于黑盒、白盒测试: 白盒测试主要是想对程序模块进行如下检查:1.对程序模块的所有独立的执行路径至少测试一遍;2.对所有的逻辑判定,取真与取假的两种情况都能至少测一遍;3.在循环的边界和运行的界限内执行循环体;4.测试内部数据结构的有效性。 黑盒测试是以用户的角度,从输入数据与输出数据的对应关系出发进行测试的,注重于测试软件的功能需求,主要试图发现下列几类错误:功能不正确或遗漏,界面错误,数据库访问错误,性能错误,初始话和终止错误等。 黑盒测试只关心输入与输出的对应关系,不关心被测程序的内部关系;白盒测试要研究被测程序的源代码结构8、软件维护的定义,主要流程,如何维护软件?(看第11章PPT)(1)定义:课本Page 474PPT答案:所谓软件维护,就是在软件产品安装、实施并交付给用户使用后,在新版本产品升级之前,这段时间里软件厂商向客户提供的服务工作,称为该软件产品的软件维护。(2)主要流程:(课本Page 481) 软件维护活动和软件开发一样,要有严格的规范,才能保证软件的质量,一般执行维护活动的流程如下: 制定维护申请报告; 审查申请报告并批准; 进行维护并做详细记录; 复审。(3)如何维护软件。9、软件质量的定义以及相关理论(1)软件质量的定义:所谓软件质量,就是供方提供的软件产品满足用户明确和隐含需求的能力特性的总和。具体含义如下: 与确定的功能和性能需求的一致性; 与所成文的开发标准的一致性; 与所有专业开发的软件所期望的隐含特性的一致性。(2)相关理论(第12章PPT) 质量度量模型(McCall质量度量模型和ISO软件质量评价模型):(练习册Page 294) 质量管理与控制的三个层次事先的预防措施:制订软件过程开发规范和软件产品质量标准,对软件开发和管理人员进行这方面知识和技能的定向培训;(规范是对行为的约束、标准是对产品的约束、规程是对操作的约束)事中的跟踪监控措施:按照CMM/CMMI或ISO9000的过程管理思想,对软件过程和软件产品的质量控制提供可视性管理;事后的纠错措施:对软件工作产品和软件产品加强评审和检测。评审是在宏观上框住您,在微观上挑剔您,找出不符合项。检测是为了发现Bug,改正错误。结论:软件质量保证措施,应以提前预防和实时跟踪为主,以事后测试和纠错为辅。 从四个方面来改进软件质量力图从编程语言上实现突破。已经从机器语言、汇编语言、面向过程的语言、面向数据的语言,发展到面向对象、面向构架的语言

温馨提示

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

评论

0/150

提交评论