软件工程相关概念复习

来源:百度文库 编辑:神马文学网 时间:2024/03/29 06:18:07

软件是计算机系统中与硬件相互依存的另一部分,它是包括程序,数据及其相关文档的完整集合。注意与广义软件概念的区别(P1)。 程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构  文档是与程序开发,维护和使用有关的图文材料

软件的特点. 软件是一种逻辑实体,而不是具体的物理实体。因而它具有抽象性  软件的生产与硬件不同,在它的开发过程中没有明显的制造过程,可以复制,  软件的开发和运行常受到计算机系统的限制,对计算机系统有着不同程度的依赖性   软件的开发至今尚未完全摆脱手工艺的开发方式  本身复杂 且 成本昂贵。

软件功能分:系统,支撑,应用软件。

软件生存期的六个步骤,即制定计划(确定要开发软件系统的总目标,给出功能、性能、可靠性以及接口等方面的要求,完成该软件任务的可行性研究,制定出完成开发任务的实施计划)、需求分析(对待开发软件提出的需求进行分析并给出详细的定义)、设计(把各项需求转换成软件的体系结构,对每个模块要完成的工作进行具体的描述,为源程序编写打下基础)、程序编码(把软件设计转换成计算机可以接受的程序代码)、测试(通过单元模块测试和组装测试,对各项需求进行有效性测试)及运行维护 (改正性维护 适应性维护 完善性维护  )

 

 

 

软件:程序和所有使程序正确运行所需要的相关文档和配置信息。

软件工程:是一门工程学科,不仅涉及软件开发,也涉及软件项目管理、支持软件生产的工具、方法和理论的开发等活动。

软件过程:指制作软件产品的一组活动及其结果。包括软件描述(对软件及其操作的一些约束)软件开发(软件设计和编程实现)软件有效性验证(检查保证客户所需)软件进化(随不同客户和变化市场做修改)

软件过程模型:从一特定角度提出的软件过程的简化描述。1工作流模型(描述软件过程中各种活动的序列及其输入输出和相互依赖性)2数据流或活动模型(软件过程描述成一组活动,每个活动完成一定数据转换)3角色/动作模型(描述参与人员的不同角色和各自负责的活动)

CASE是计算机辅助软件工程的简写。它包括很多种类的软件工具,覆盖面很广,包括支持阮娟过程活动,如需求分析、系统建模、调试和测试等。

 

 

1瀑布模型:采用一些基本过程活动,并且使用单独的过程阶段表现活动。包括:需求分析和定义(通过咨询系统用户建立系统的服务、约束和目标)系统和软件设计(系统设计区分硬件和软件系统的需求,软件设计包括识别和描述一些基本的软件系统的抽象及其之间的关系)实现和单元测试(检验每个单元是否符合描述)集成和系统测试(对系统整体测试确保满足需求)运行和维护。优势在于每个阶段生成文档,并且与其他模型相一致,问题在于将项目生硬分解成这些确切的阶段。委托事项一定要在过程的早期阶段清晰给出,意味它难以响应用户需求的变更。

2迭代式模型:是软件描述、开发和有效性验证活动交替进行的开发方法。先开发出一个原型给用户使用,通过用户反馈意见不断修改系统直到最后成熟。基本类型(探索式开发和抛弃式原型)优势在于让开发活动都能得到快速的反馈信息,缺点在于1过程不可见(管理者要经常性交付把握进度)2系统结构通常较差(连续的变更损坏系统结构)

3基于组件的软件工程(CBSE )假定系统的各个组件已经存在,开发过程焦点在于集成这些组件。阶段:组件分析(给出需求描述,然后搜索能满足需求的组件)需求修改(修改需求以反映可得到的组件)使用复用的系统设计(开始设计系统的框架)开发和集成(集成开发的组件和现成的组件使之成为整体)优势在于减少需要开发的软件数量,降低软件开发成本和风险。缺点在于需求妥协的不可避免,对系统进化的控制不起作用。

Rational统一过程:是一个阶段化了的模型,识别出软件过程当中的四个阶段——开端(目标是建立系统的一个业务案例)细化(增进对问题域的理解,建立系统的体系框架)构造(关心系统设计、编程和测试)转换(关注如何将系统从开发单位转移到用户单位使之在真实环境工作)九个工作流 ——业务建模(用业务用例对业务过程建模)需求(完成对系统需求的建模)分析和设计(使用体系结构模型、组件模型、对象模型和序列模型来创建并记录设计模型)实现(实现系统中的组件并将他们合理安排在子系统中)测试(它的执行与实现紧密联系)部署(创建和分发产品版本并安装到他们的工作场所)配置和变更管理(支持工作流管理对系统的变更)项目管理(支持工作流管理系统开发)环境(用于提供软件开发团队可用的合适软件工具)六个基本实践(反复的开发软件、管理需求、使用基于组件的体系结构、可视化模型软件、验证软件质量、控制对软件的变更)

 

 

软件系统需求常常分为功能需求、非功能需求和领域需求。1功能需求——包括对系统应该提供的服务、如何对输入作出反应以及系统在特定条件下的行为的描述。应该即、既全面(用户所需服务都给出描述)又具有一致性(描述不能前后矛盾)2非功能需求——对系统提供的服务或功能给出的约束。分类:产品需求(叙述产品行为的需求,包括可移植性和可用性需求)机构需求(起源于客户所在的机构和开发者所在的机构中的政策和规定)外部需求(包括所有系统外部因素和开发过程,如操作、法律、道德需求)3领域需求——来自系统的应用领域的需求,反映该领域的特点。

用户需求是从用户角度来描述系统功能和非功能需求,以便让不具备专业技术知识的用户能看懂。编写用户需求的一些原则:1设计一个标准的格式,保证所有的需求定义按照该格式书写。2使用一致的语言。定义强制性需求要使用“必须”;定义希望性需求时使用“应该”。3对文本加亮来突出显示关键性需求。4尽量避免用计算机专业术语。

系统需求:是用户需求的扩展版,是软件工程师开始系统设计的起点。仅仅描述系统的外部行为和对它的操作上的限制,而不包括系统应该如何设计和实现。

 

信息持有者(对系统需求有直接或间接影响力的人)

需求导入和分析:软件开发技术人员要和客户及系统最终用户一起调查应用领域。包括:需求发现(收集准备建立的系统和正在使用的系统的信息,并从这些信息当中提取用户和系统的需求)需求分类和组织、优先排序和冲突解决、需求文档编制(记录需求并将它作为螺旋下一循环的输入,产生形式化的或非形式化的需求文档)

视点:需求工程的面向视点的方法将导出过程和需求本身都用视点来组织。1交互者视点(代表与系统直接交互的人或其他系统)2间接视点(代表那些不使用系统本身但是以某种方式影响需求的信息持有者)3领域视点(代表领域和影响系统需求的那些约束)

场景:描述人如何与一个软件系统交互。

用例:是一种基于场景的需求导出技术,识别与系统的单个交互。

需求管理是一个对系统需求变更了解和控制的过程,需要跟踪各个需求并维护他们与所依赖需求之间的关联关系。分持久和易变的需求。

在需求管理阶段,必须决定一下内容——需求识别、需求管理过程、可追溯策略、CASE工具支持。3类可追溯信息:1源可追溯性信息连接需求到提出需求的信息持有者和这些需求的基本原理2需求可追溯性信息连接需求文档中 依赖的需求3设计可追溯性信息连接需求到其实现的设计模块。需求变更管理三个阶段:1问题分析和变更描述阶段(要对问题或变更提议进行分析以检查它的有效性)2变更分析和成本计算(对被提议的变更产生的影响进行评估并且估计系统设计和实现的成本)3变更实现。

 

体系结构设计是设法建立一个系统组成来满足功能性和非功能性需求。

所开发的体系结构模型会包括:静态结构模型(给出子系统或组件,将其作为一个个独立的单元开发)动态过程模型(给出系统在运行时的过程组成)接口模型(定义每个子系统从它们的公共接口能得到服务)关系模型(给出如子系统间的数据流这样的关系)分布模型(给出子系统在多台计算机上是如何分布的)

模块化分解:将子系统分解为模块,有两种策略:1 面向对象的分解(将系统分解为一组相互通信的对象)一个面向对象的系统体系结构模型是将系统看成一组松散的对象结合,这些对象都有良好的接口定义,对象请求其他对象提供的服务。优势在于其对象间是松散耦合的,对对象实现的修改可以不影响其他对象,缺点在于对象必须明确地给出引用的其他对象的名字及其接口。2 面向功能的流水线操作(将系统分解为一些功能模块,这些功能模块接受输入并转换它们为输出数据)好处在于1支持换换的复用2直观,能将它们的工作理解成输入输出处理3可以简单的再系统中增加新的转换4无论作为顺序的还是并发的系统,其实现容易。其主要缺点是需要一种适合于所有转换的通用格式。

 

数据处理系统是批处理系统,数据的输入和输出时成批地从文件或数据库中取出或存入,而不是对用户终端进行输入和输出。 形成输入—处理—输出结构。

事务处理系统是设计用来处理用户对数据库信息的查询或者请求更新数据库的。

 

快速软件开发的原因:新的软件需要快速开发来顺应新的的机遇,响应竞争压力。事实上很多业务都宁愿牺牲一些软件的质量并降低某些需求来赢得快速软件移交。还因为业务运营于一个变化的环境中,因此实际上通常不可能导出一个完全的稳定的软件需求。

基本特征:1描述、设计和实现过程是并发的2系统通过一系列增量开发出来3系统用户界面通常是采用交互式开发系统开发的。

敏捷方法的基本原则:客户参与(客户应该在开发过程中始终紧密参与其中)增量式移交(软件以增量的方式进行开发,客户指定每个增量中的包含需求)人非过程(开发团队的技术应该得到承认和发扬)接收变更(设计系统使之适应这些变更)保持简单性(致力于所开发的软件和开发过程的简单性)

极限编程的经验:增量式规划(需求记录在脚本上,开发者将脚本分解为开发任务)小版本(首先开发能提供业务价值的一个最小有用集合)简单设计(只进行有限需求设计)测试优先开发(功能实现之前,采用一个自动单元测试框架来书写此新功能的测试)重构(保持代码简单和可维护性)结对编程(检查彼此工作提供支持)集体所有(配对的开发人员参与系统的所有方面,所有开发者享有全部代码)连续集成(任务一完成,就将它集成到大系统中)可忍受速度(不能接受大量超时)在场客户(系统最终用户的代表应该全程满时配合XP团队)

 

检验和有效性验证:实现过程之后,必须对所开发的程序进行验证,它是对这些检查和分析过程的总称。 检验的作用是检查软件是否符合它的描述。应该检查系统是否满足了需求所定义的功能的和非功能的需求。有效性验证却是一个更一般的过程,其目标是保证软件系统能满足客户的期待。

V&V过程中,系统检查和分析有两种互补的方法:1软件审查或配对审查——审查可以辅之以某些对系统源文本或者是相关文档的自动分析,是一种静态的V&V技术,因为你无需再计算机上运行系统。2包括使用测试数据来运行软件的实现,检验软件的输出和它的操作行为,测试是一种动态的V&V技术。在软件过程的不同阶段,有2中截然不同的测试类型:1有效性测试——试图证明软件是用户所期望的即满足需求2缺陷测试——试图使缺陷暴露出来,而不是要仿真它在实际中的使用。发现程序和描述的不一致。

检验和有效性验证过程试图确定软件系统中存在缺陷,程序调试时一个对缺陷定位和修正的过程。

 

软件测试的目标:1向开发者和用户展示软件满足它的需求。2为了找出软件中的缺陷和不足,即软件的活动室不正确的、所不希望的或不符合它的描述的。

测试过程:组件测试(单个程序组件的测试)—系统测试(对一组组件集成的系统进行测试)

系统测试:两个阶段1集成测试(测试小组可以深入到系统源代码)自上而下集成:首先开发系统的框架,然后将组件加入到框架中。自下而上集成:集成基础设施组件,然后添加功能组件.2发布测试(对要发布给用户的系统版本进行测试)

测试原则:是给测试团队提示,以帮助他们选择将揭示系统中的缺陷测试。

接口测试:目标是为了检测由于接口的错误或无效的接口假设所造成的故障.

接口类型1参数接口(数据从一个过程传到另外一个过程).2共享内存接口(内存块为过程或函数所共享.)3程序接口(子系统封装一组程序,这些程序为其他子系统调用.)4消息传递接口(子系统通过传递消息请求其他子系统上的服务)

划分测试:由于类中成员的这些等价行为,这些类通常叫做等价划分或者域.

结构化测试(白盒测试):根据软件的结构知识和实现知识导出测试的测试用例设计方法。

路径测试:目标是要练习组件或程序中的每一条执行路径。

要点:测试只能证明系统中存在错误,它不能说明系统中不再有缺陷.;组件测试是组件开发者的责任,独立的测试团队通常执行系统测试.;集成测试是最初的系统测试活动,发布测试关心的是测试客户版本,应该验证所要发布的系统满足了它的需求.;在缺陷测试时,应根据经验和准则来设计测试用例.;接口测试是要发现组合组件的接口中的缺陷.;等价划分是导出测试用例的一个方法,需要找出输入和输出数据集合上的划分并用这些划分中的数据执行系统.;结构化分析依赖于分析一个程序由此来确定路径.;测试自动化通过使用一系列软件工具支持测试过程,以减少测试过程的花费.

什么是黑盒测试和白盒测试? 任何工程产品(注意是任何工程产品)都可以使用以下两种方法之一进行测试。 黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。 白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。 软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误: 1、是否有不正确或遗漏的功能? 2、在接口上,输入是否能正确的接受?能否输出正确的结果? 3、是否有数据结构错误或外部信息(例如数据文件)访问错误? 4、性能上是否能够满足要求? 5、是否有初始化或终止性错误? 软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查: 1、对程序模块的所有独立的执行路径至少测试一遍。 2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。 3、在循环的边界和运行的界限内执行循环体。 4、测试内部数据结构的有效性,等等。 以上事实说明,软件测试有一个致命的缺陷,即测试的不完全、不彻底性。由于任何程序只能进行少量(相对于穷举的巨大数量而言)的有限的测试,在未发现错误时,不能说明程序中没有错误。

 

配置管理的重要性:涉及程序和标准的发展和应用来管理不断发展的软件产品;配置管理有时候被看做是软件质量管理过程的一部分;当进行配置管理时,受控系统有时也称为基线,因为它们是受控进化的一个起点.

四种主要配置管理活动:

配置管理规划:描述配置管理应该使用的标准和规划。1配置项识别(应该定义文档命名规则,以便类型相同的文档命名也类似)2配置数据库(用于记录与配置有关的所有信息)

 

变更管理:需求不断发生变化,系统也相应作出变更。关注的是对变化保持跟踪,并确保它们用最具成本效益的方式实施.  变更请求表(记录了变更的建议、变更的请求、变更的原因以及变更的迫切性.它还记录了变更评估、影响分析、变更成本和建议.)

 

版本和发布管理:是识别和追踪一个系统的各个版本和发布的过程。

版本  一个系统版本就是一个系统实例,在某种程度上有别于其他系统实例.

变体  有一些版本可能在功能上没有什么区别,只是为了不同的硬件或软件配置而设计.

发布版本:  一个系统的发布版本就是要分发给客户的版本.

版本管理规程应该规定明确的标识每个组件版本的方法.

三种基本的版本标识方法 1版本编号;2基于属性的标识;3面向变更的标识.

 

系统构建:把软件组件编译和连接成一个程序并在特定目标配置上运行的过程.

 

CASE工具可用于支持所有的配置管理活动.

支持配置管理的CASE工具可以是一些独立的工具分别用来支持变更管理、版本管理和系统构建,也可以是集成的系统,为所有的配置管理支持提供一个一致的接口.