软件工程知识点.doc_第1页
软件工程知识点.doc_第2页
软件工程知识点.doc_第3页
软件工程知识点.doc_第4页
软件工程知识点.doc_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

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

文档简介

1、 软件危机“软件危机”(Software crisis)的出现是由于软件的规模越来越大,复杂度不断增加,软件需求量增大。而软件开发过程是一种高密集度的脑力劳动,软件开发的模式及技术不能适应软件发展的需要。致使大量质量低劣的软件涌向市场,有的花费大量人力财力,而在开发过程中就夭折。“软件危机”主要表现在两个方面: (1)软件产品质量低劣,甚至开发过程就夭折。(2)软件生产率低,不能满足需要。2、 软件工程的定义软件工程是一门新兴的边缘学科,涉及的学科多,研究的范围广,研究的主要内容有以下几方面: 软件开发技术软件开发方法、技术软件开发工具及环境软件管理技术 软件管理技术软件规范(国际规范)3、 软件生命周期以瀑布模型为例:软件包括程序及软件开发过程所产生的所有文档。问题定义编 码需求分析软件设计可行性研究运行与维护测 试开发时期运行时期计划时期(目标与范围说明书)(可行性论证论告)(测试报告)(程序)(设计文档)(需求说明书)软件生命期模型4、 常见的软件过程模型 目前典型的软件开发模型有: 瀑布模型、增量模型、螺旋模型、喷泉模型、变换模型和基于知识的模型等。 不同的开发方法有不同的软件过程模型。瀑布模型、可行性研究可行性论证论告需求分析需求规格说明书运行与维护维护报告测 试测试报告编 码 程序详细设计详细设计文档概要设计 概要设计文档开发阶段运行阶段计划时期 瀑布模型在软件开发的前期起到重要作用,但逐渐暴露出其缺陷,即将充满回溯的软件开发过程硬性分割为几个阶段。增量模型、定义概要需求把需求分配给需要设计系统结构开发系统增量验证增量组装增量验证系统系统不完全最终系统增量模型是一种非整体开发的模型。是一种进化式的开发过程。根据增量的方式和形式的不同,分为:基于瀑布模型的渐增模型基于原型的快速原型模型该模型具有较大的灵活性,适合于软件需求不明确、设计方案有一定风险的软件项目。螺旋模型、对大型软件,需要多个原型描述系统的生存期,螺旋模型将瀑布模型与原型化模型结合起来,并加入了风险分析。螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期可分为4个工作步骤: 第一,确定目标、方案和限制条件; 第二,评估方案、标识风险和解决风险; 第三,开发确认产品; 第四,计划下一周期工作。喷泉模型、 分 析系 统 设 计软 件 设 计 实 现 喷泉模型该模型是由B.H.Sollers和J.M.Edwards于1990年提出。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性,喷泉模型使开发过程具有迭代性和无间隙性。适宜面向对象的方法。其特点如下: . 开发过程有分析、系统设计、软件设计和实现4个阶段。 .各阶段相互重叠,它反映了软件过程并行性的特点。 .以分析为基础,资源消耗成塔型。 .反映了软件过程迭代性的自然特性,从高层返回低层无资源消耗。 .强调增量开发,整个过程是一个迭代的逐步提炼的过程。 速成原型模型 速成原型的工作模型是一个循环的模型。运行评价构造快速分析修改1.快速分析 快速确定软件系统的基本要求,确定原型所要体现的特征(界面、总体结构、功能、性能)2.构造原型 考虑主要特征,快速构造一个可运行的系统。有三类原型:用户界面原型、功能原型、性能原型。3.运行和评价原型 4.修改与改进循环模型为了对瀑布模型进行改进,描述软件开发过程中可能的回溯,采用循环模型。智能模型(intelligent model)也称为基于知识的软件开发模型,是知识工程与软件工程相结合的软件开发模型。获取需求需求分析具体描述优化程序调整验证维护知识库专家系统程序智能模型5、 需求分析的重要性和必要性软件需求无疑是当前软件工程中的关键问题,没有需求就没有软件。应用领域的广泛性,它的实施无疑与各个应用行业的特征密切相关。非功能性需求建模技术的缺乏,及其与功能性需求有着错综复杂的联系,大大增加了需求工程的复杂性。沟通上的困难,由于系统分析员、需求分析员等各方面人员有不同的着眼点和不同的知识背景,给需求工程的实施增加了人为的难度6、 可行性研究可行性研究的目的不是解决问题,而是确定问题是否值得去解决可行性研究实质上是要进行一次大大压缩简化了的系统分析和设计的过程,也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。可行性研究最根本的任务是对以后的行动方针提出建议 可行性研究需要的时间长短取决于工程的规模。一般说来,可行性研究的成本只是预期的工程总成本的5%10%。7、 主流的软件体系结构(分布式结构、分布式对象结构、中间件)件体系结构确定了系统的组织结构和拓扑结构,显示了系统需求和构成系统的元素之间的对应关系,提供了一些设计决策的基本原理。体系结构的设计过程的主要活动:1.系统分解将系统分解为若干相互作用的子系统。2.控制建模建立系统各部分间控制关系的一般模型。3.模块分解 将子系统进一步划分为模块。注意:往往子系统与模块之间没有明显界限.一、仓库模型(The repository model) 也称“容器模型 ”,是一种集中式的模型。中央数据仓库存储各个子系统共享的数据,其它的子系统可以直接访问这些共享数据。子系统之间紧密耦合。 各子系统共享中央数据库中的数据共享容器模型 各子系统有自己的数据库,子系统之间通过消息传递实现数据交换。二、 客户机/服务器模型(Client/Server Architectural Model) C/S结构是一种分布式模型,采用发请求、得结果的模式:客户机 向服务器发出请求(数据请求、网页请求、文件传输请求等等),服务器 响应请求,进行相应的操作,将结果回传给客户机,客户机再将格式化后的结果呈现给用户。、分布式对象结构(Distributed Objects Architecture)采用分布式对象结构 : “对象(Object)”提供服务的系统组件(System Component)。 每个对象在逻辑上是平等的,它们可以互相为对方提供所需的服务。 提供服务的对象就是服务器,而提出服务请求的对象就是客户。 四、 抽象机模型称为分层模型,通常用于建立子系统的接口模型。每层提供一组服务,定义一个抽象机。典型的例子:控制摸型8、 SOA的原理面向服务的体系结构(service-oriented architecture,SOA)是一个构件模型,它将应用程序的不同功能单元(称为服务)通过定义良好的接口和契约联系起来9、 云计算10、 软件测试的基本概念和原则松耦合在该体系架构中,客户端不和任何服务器相关联,它只和服务相联系,所以客户端和服务器的集成不影响客户端应用程序。无论老的或者新的功能模块都可以被封装成服务构件被发布。功能构件和它们的接口分离,所以新的接口可以非常方便地插入。在复杂的应用程序里,业务过程的控制可以被隔离:引入一个业务规则引擎用来控制已经定义好的业务过程流。引擎根据工作流的状态调用各种不同的服务。服务可以在运行时动态地合成进来。通过配置文件进行绑定,所以可以非常容易地适应各种新的需要SOA的特点无状态的服务设计服务质量需要重点考虑SOA带来的好处利用现有的资产更易于集成和管理复杂性更快的响应和上市速度减少成本和增加复用说到做到9云计算云计算(Cloud Computing ):是分布式处理(Distributed Computing)、并行处理(Parallel Computing)和网格计算(Grid Computing)的发展,或者说是这些计算机科学概念的商业实现。是指基于互联网的超级计算模式-即把存储于个人电脑、移动电话和其他设备上的大量信息和处理器资源集中在一起,协同工作。在极大规模上可扩展的信息技术能力向外部客户作为服务来提供的一种计算方式10软件测试的基本概念和原则11软件测试的方法(白盒法、黑盒法)白盒测试/白箱测试把测试对象看作一个透明的盒子,根据程序内部的逻辑结构及有关信息设计测试用例又称为结构测试把测试对象看作一个透明的盒子,测试人员根据程序内部的逻辑结构及有关信息设计测试用例,检查程序中所有逻辑路径是否都按预定的要求正确地工作。主要用于对模块的测试常用的测试方法基本路径覆盖测试根据程序或设计图画出控制流图,并计算其区域数,然后确定一组独立的程序执行路径,最后为每一条基本路径设计一个测试用例逻辑覆盖测试考察使用测试数据运行被测程序时对程序逻辑的覆盖程度数据流测试根据程序中变量的定义(赋值)和引用位置来选择测试用例循环测试简单循环、嵌套循环、串接循环和非结构循环黑盒测试/黑箱测试把测试对象看做一个黑盒子,完全不考虑程序内部的逻辑结构和内部特性黑盒测试是依据软件的需求规约,检查程序的功能是否符合需求规约的要求。主要测试方法等价类划分将所有可能的输入数据划分成若干个等价类,然后在每个等价类中选取一个代表性的数据作为测试用例边界值分析挑选那些位于边界附近的值作为测试用例比较测试分别开发二个软件版本,用相同的测试用例对二个版本的软件分别进行测试,比较其测试结果错误猜测凭直觉和经验推测某些可能存在的错误,从而针对这些可能存在的错误设计测试用例因果图既考虑输入条件的组合关系,又考虑输出条件对输入条件的依赖关系11、 软件测试的策略12、 软件维护的类型完善性维护(Perfective Maintenance)扩充原有系统的功能,提高原有系统的性能,满足用户的实际需要。纠错性维护(Corrective Maintenance)对在测试阶段未能发现的,在软件投入使用后才逐渐暴露出来的错误的测试、诊断、定位、纠错以及验证、修改的回归测试过程。适应性维护(Adaptive Maintenance) 要使运行的软件能适应运行环境的变动而修改软件的过程。 预防性维护(Preventive Maintenance) 为了进一步

温馨提示

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

评论

0/150

提交评论