《软件工程综述.docx》由会员分享，可在线阅读，更多相关《软件工程综述.docx（21页珍藏版）》请在三一办公上搜索。
1、软件工程复习提纲第1章软件工程简介3软件是什么3第2章过程综述4软件工程定义4层次化4通用过程框架4第3章过程模型6多木中ii36第4章敏捷视角下B过程8敏捷宣言8第5章系统工程10第6章需求工程11质量功能布署（QFD）11分析模型的元素14第7章构建分析模型14第8章设计工程15第9章进行体系构造设计16体系构造风格的分类16第10章构件级设计建模17第Il章完毕顾客界面设计17黄金规则17第12章软件测试方略18软件测试需要计划和执行一系列的测试环节18第13章测试技术19两个不同样日勺测试用例设计技术19第14章产品度量20第1章软件工程简介软件是什么软件是形成配置的J一组术语或对象，
2、包括：程序(计算机程序)：指令的集合,通过执行这些指令可以满足预期的特性、功能和性能需求数据构造:它使得程序可以充足运用信息文档:描述程序操作和使用B文档(图文资料)1. 举例阐明“意外效应法则”(IaWofUnintendedConSeqUenCeS)在计算机软件方面B应用。某些新科技的发明发明会给其他某些看似无关的技术领域、商业企业、公众甚至整个社会文化带来深远而出人意料的影响和作用。如：2. 用自己B语言描述保证通晓规律(TheLawofConservationofFamiliarity)质量衰减规律(TheLawofDecliningQuality)以及组织稳定性守恒规律(TheLaW
3、OfConservationofOrganizationalStability)。保证通晓性规律(1980):伴随E类型系统的J演化，所有有关人员(如开发人员、销售人员和顾客)都必须清晰地理解演化的内容和过程，以便抵达满意时演化效果。质量衰减规律(1996):假如没有严格的维护和适应性调整使之适应运行环境的变化，E类型系统日勺质量有衰减的趋势。组织稳定性守恒规律(1980):一种不停演化的E类型系统，其组织在全球范围内的平均有效活动率在产品的生命周期中是保持不变的。3. 在交付最终顾客之前，或者第1个版本投入使用之后，许多应用程序都会有频繁的变更。为防止变更引起软件失效，请提出某些有效的处理措
4、施。首先从心态上承认变化是必然的，我们可以通过在软件公布之前进行alpha,beta测试，运用迭代模式，在吸取测试过程中的经验之后，立即改善软件。同步保持和顾客的良好沟通，在提交顾客时进行合适培训，让顾客按照开发思绪进行试用，可以见减少因使用措施不妥引起0变化。第2章过程综述软件工程定义软件工程是：（1）将系统化、规范的、可量化的措施应用于软件的开发、运行和维护，即将工程化措施应用于软件。（2）在（1）中所述日勺措施B研究。层次化工具方法过程模型质量关注点软件工程层次图通用过程框架1.沟通(Communication)2.筹划(Planning)3.建模(Modeling)a)需求分析(Ana
5、lysisofrequirements)b）设计（DeSign）4 .构建（Construction）a）代码生成（COdegeneratiOn）b）测试（TeSting）5 .布署（Deployment）重点：1. Baetjer说过“软件过程为顾客和设计者之间、顾客和开发工具之间以及设计者和开发工具之间提供交互的途径技术。”设计下面问题“设计者应当问顾客的；顾客应当问设计者的；顾客对将要构建的软件H自问；设计者对于软件产品和建造该产品采用的软件过程B自问。（怎样获取需求）2. 为沟通活动设计一种任务集1 .识别重要客户和其他共利益者2 .与客户会谈环境无关日勺话题3 .写一页项目范围4 .
6、评审范围阐明5 .讨论项目大体的阶段6 .约定各个部门日勺代表，并使他们互相认识7 .为计划活动做准备3 .用自己的话描述过程框架。当我们谈到框架活动合用于所有的项目时，与否意味着对于不同样规模和复杂度的项目，可应用相似的工作任务？请解释。过程框架定义了若干小的框架活动，为完整的软件开发过程建立的基础，这些框架活动可以广泛用于所有B软件开发项目，无论这些项目0复杂性和规模怎样，此外，还包括某些合用于各个软件过程的普适性活动。虽然过程框架是普适性的，不过对于不同样规模和复杂度的项目不能应用相似的工作任务。首先在软件开发0不同样阶段，工作任务不同样。另首先不同样B软件项目有不同样日勺需求，有特殊的
7、背景，找不到一种通用日勺工作任务。4 .图21中，基于“质量关注点”指明了软件工程三个层次。这意味着在整个开发组织内采用质量管理活动，如“全面质量管理”。仔细研究，并列出全面质量管理活动中关键原则B大纲。第3章过程模型多种过程模型通例软件过程模型力图给软件开发带来秩序和构造。尽管每一老式过程模型都提议了一种不同样的过程流，但均实现了同样的一组通用框架活动：沟通、计划、建模、构建和布署。瀑布模型提议线性流程的框架活动，与软件世界里现代软件开发实际（持续的变更、演化日勺系统、紧迫的开发时间）不符；但瀑布模型确实合用于需求定义清晰且稳定的软件开发；增量软件过程模型通过一系列B增量公布产生软件。RAD
8、模型迅速应用程序开发，是为大型且必须在严格日勺时间内提交的项目而设计日勺；演化过程模型认识到大多数软件工程项目的迭代特性，其设计的目的是为了适应变更演化模型（如原型模型、螺旋模型），其迅速产生增量的工作产品（或是软件的工作版本），这些模型可以应用于所有的软件工程活动一一从概念开发到长期的J软件维护。基于构建的模型强调构件复用及组装。形式化措施模型倡导采用数学的措施进行软件开发和验证。面向方面的模型目的是处理跨整个软件体系构造的横切关注点；统一过程模型是一种“用例驱动、以体系构造为关键、迭代及增量”日勺软件过程框架，由UML措施和工具支持。统一过程是一种增量模型，定义了五个阶段：起始阶段：包括顾
9、客沟通和计划活动两个方面，强调定义和细化用例，并将其作为重要模型;细化阶段：包括顾客沟通和建模活动，重点是创立分析和设计模型，强调类的定义和体系构造出J体现；构建阶段：细化设计模型，并将设计模型转化为软件构建实现；转化阶段：将软件从开发人员传递给最终顾客，并由顾客完毕Beta测试和验收测试；生产阶段：持续地监控软件日勺运行，并提供技术支持。重点：1. 开发质量“足够好”的软件，其长处和缺陷是什么？当我们追求开发速度胜过产品质量的时候，会产生什么后果？我们总在质量和开发速度之间做取舍，开发质量“足够好”的软件，明显强调质量，长处是使软件符合或超过客户的预期，在性能上，交互上力图做到尽善尽美。缺陷
10、是忽视了开发成本，很轻易导致开发时间延期，影响软件工程后几种阶段B工作，对全局导致不利影响。2. 当沿着螺旋过程流发展B时候，你对正在开发或者维护B软件B见解是什么？在螺旋模式下，开发过程是迭代式日勺，采用循环的方式逐渐加深系统定义和实现的深度，同步减少风险。当软件交付使用后，螺旋模式没有停止，它将永远保持可操作性，每一圈完毕后都会计算成本，可以更好依J维护软件。3. 可以合用几种过程模型吗？假如可以，举例阐明。可以。几种过程模型，都是互相兼容可以互相扩展日勺，如螺旋模型结合了原型的迭代性质和瀑模型的系统性和可控性的特点。在详细项目实行中，对于某一部分可以合用几种过程模型，例如形式语言与自动机
11、演示软件在算法开发过程，就需要使用形式化措施模型，用严格的数学符号定义形式语言和自动机。尚有某些桌面应用程序0前台Ul部分，可以单独使用RAD模型，例如用delphi语言开发桌面窗体就是一种RAD实现。而其他部分可以使用其他如瀑布式模型等措施。第4章敏捷视角下的过程敏捷宣言 个体和交互胜过过程和工具(IndiVidUalSandinteractionsoverprocessesandtools) 可工作软件胜过宽泛的!文档(Workingsoftwareovercomprehensivedocumentation) 客户合作胜过协议谈判(CUStomercollaborationovercon
12、tractnegotiation) 响应变化胜过遵照计划(ReSPOndingtOehaIlgeoVerfolk)WingaPIan)重点：1. 与否每一种敏捷过程都可以用第2章所提及的通用框架性活动来描述？建一张表，将通用活动和每个敏捷过程所定义B活动对应起来。2. 用自己的语言描述(用于软件项目的)敏捷性？普遍存在0变化是敏捷0基本动力，敏捷需要有效日勺响应变化，它鼓励在共利益者之间进行更便利的沟通和协作，强调可运行软件的迅速交付。敏捷容许项目团体调整并合理安排任务，理解易变性并制定计划。精简并维持最基本的工作产品，强调增量交付，迅速提供可运行软件。3. 许多敏捷过程模型推荐面对面交流，实
13、际上，目前软件开发团体组员及其客户在地理上是分散的。你与否认为这意味着这种地理上的分散应当防止？能否想出一种措施克服这个问题。我认为这种地理上的分散是现实，是无法防止的。我认为可以分为客户和开发人员的分散，开发人员内部分散两种状况。对于第一种：产品经理需要同客户建立一条良好的通信信道，如通过email,即时聊天工具进行定期沟通。对于第二种：开发人员需定期组织交流，通过Webgroup消除地理上0分散。4. 为何需求变化这样大，人们究竟无法确定他们想要什么吗？我认为是这样的。其实需求是客户对他们心目中软件的一种描述，由于软件还没有实现，这种描述便是不确定B,模糊的。同步当今世界处在高速变化之中，
14、人们B需求会伴随环境B变化而变化。因此敏捷开发承认变化，认为普遍存在的变化是敏捷的基本动力。第5章系统工程在写下每行代码之前 理解所要处理日勺问题（详见沟通与建模） 理解基本日勺设计原则和概念 选择一种可以满足软件构建以及运行环境规定的编程语言 选择一种能提供工具以简化工作的编程环境 构件级编码完毕后进行单元测试系统工程层次图重点：1 .对你熟悉的系统、产品或服务，建立它们的层次系统。层次应当向下扩展到简朴系统要素（硬件、软件等），至少得到层次树的一种分支。即时聊天系统2 ,系统工程师由3种来源：系统开发人员、顾客或某些外部组织。讨论一下每种来源B利与弊。描述一种理想B系统工程师。3 .研究文
15、献并写出一篇简短文章描述建模和模拟工具是怎样工作的。或者是搜集两个或更多的商用建模或模拟工具B文献，并且比较它们的相似处与不同样处。第6章需求工程质量功能布署（QFD）是一种将客户规定转化成软件技术需求的技术。QFD“目B是最大程度地让客户从软件工程过程中感到满意”，并强调“什么是对客户有价值的”。确认三类需求：正常需求：反应了在和客户开会时确定日勺针对某产品或系统日勺目日勺。假如实现了这些需求，将满足客户（例如：所规定日勺图形显示类型、特定日勺系统功能以及已定义日勺性能级别）。期望需求：隐含在产品或系统中，并且也许是非常基础的以至于客户没有显式地阐明，但缺乏这些将导致客户明显不满（例如：易交
16、互性、可操作性、可靠性、易安装等）。令人兴奋的需求：反应了客户期望之外B特点，但假如实现了这些特点，将会使客户非常满意。重点：1. 为如下活动之一开发一种完整的用例：在ATM提款；在餐厅使用信用卡付费;使用一种在线经纪人账户购置股票;使用在线书店搜索书（某个指定主题）；ATM用例图“ATM取款”用例规约用例名称：ATM取款简述：客户持银行卡（本行或其他行）从ATM提取现金actors:客户和银行主机基本流：1. 客户插入银行卡。2. ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。3. 客户输入密码。4. ATM验证帐号和密码。5. ATM显示包括取款在内的服务功能，客户选择“取款
17、”。6. 输入取款额：客户输入数量为50元的倍数的取款额。7. ATM向银行主机告知卡号、密码、账号和取款额，获得具有最新余额的取款成功确认信息。8. ATM打印并吐出凭条。9. ATM清点并吐出现金，记录取款成功。10. ATM问询客户与否继续服务。IL客户选择否，ATM吐出银行卡，结束用例，否则回到环节5。用例结束备选流：3-7,10a.客户取消服务：ATM记录服务取消，打印凭条，吐出凭条和银行卡，用例失败13,6,11a.客户未及时输入超过30秒：ATM吞卡，用例失败2a.卡无效：ATM吞卡，用例失败2b.读卡器或卡被损坏：ATM吞卡，用例失败4a.密码错：4al.客户重新输入密码a.合
18、计3次密码错误：ATM吞卡，用例失败4b.无此帐号：ATM吞卡，用例失败5a.ATM无现金：ATM不显示“取款”功能，客户可选择其他服务，用例失败16a.取款额超过ATM现金余额：ATM规定客户重新输入取款额。7a.帐户余额局限性：ATM规定客户重新输入取款额。7b.取款额超过当日最高限额：ATM规定客户重新输入取款额。7c.网络或银行主机失效、通讯超时：ATM记录服务取消，打印凭条，吐出凭条和银行卡，用例失败18a.凭条打印失败，纸用完或卡纸：8al.ATM告知银行主机取消取款8a2.ATM记录服务取消，吐出银行卡，用例失败19a.吐现金失败：9al.ATM告知银行主机取消取款9a2.ATM
19、记录服务取消，吐出银行卡，用例失败1Ila.客户未及时取走卡：ATM吞卡，用例失败业务规则：7b单日取款不得超过5000元6c每次取款不得超过2023元2. 为何大量的软件开发人员没有足够重视需求工程？此前有无什么状况让你可以跳过需求工程？首先软件开发人员认为客户已经把需求说清晰了，不过大多数状况初步B需求都是模糊日勺。另首先工程的进度规定很紧迫，软件开发人员迫切但愿投入到代码编写阶段。最终和客户沟通比较困难，使得大多数软件开发人员不重视需求工程。又一次，项目时间很短，规定一种月完毕，我们只是大体上对需求有一种认识，就跳过需求工程开始动手编码，成果当然失败了。3. 简短地讨论一种分析模型B每个
20、元素，指出每个元素对模型B奉献，每个元素为何是唯一的以及每个元素所示的概要信息。分析模型的元素基于场景的元素（用例图）：使用基于场景的措施可以从顾客的视角描述系统。例如基本的用例和基于模板的用例。一般的分析模型B第一步，作为创立其他模型的输入。基于类的元素（类图）：每个使用场景都暗示着当一种参与者与系统交互时所操做B一组对象，这些对象被提成类一一具有相似属性和共同行为B事务集合。行为元素（状态图）：状态指明了在某个特殊事件后采用什么动作。面向信息流的模式：描述信息的转换。第7章构建分析模型重点:1 .简朴用几句话尝试阐明构造化分析和面向对象分析B重要差异？构造化分析考虑数据和处理，其中数据作为
21、独立的实体转换，数据对象建模定义了对象的J属性和关系，操作对象的J处理建模应当表明数据对象在系统内流动时处理怎样转换数据。面向对象分析关注于定义类和影响客户需求0类之间0协作方式。2 .有无也许在分析模型创立后立即开始编码？解释你的答案，然后说服反方。第8章设计工程用心1从分析植驾到设计模皇的为化重点:1 .假如软件设计不是程序（它确定不是），那么它是什么？是一套结实、合用和赏心悦目的J模型或设计体现。它包括数据、类设计，体系构造设计、接口设计、构件设计。2 .当你“编写”程序时你设计软件吗？软件设计和编码有什么不同样吗？设计。软件设计是逐渐细化一种可以工作的模型，而编码是在生成一种可执行的程
22、序。软件设计重要关注与否实现了顾客需求，必须从实现的角度阐明数据域、功能域和行为域，是编码工作的指导。3 .用你自己B话阐明软件体系构造。系统构造是程序构件（模块）B构造或组织，这些构件交互B形式以及这些构件因此数据日勺构造。构件可以被推广，用于代表重要日勺系统元素及其交互。第9章进行体系构造设计体系构造风格的分类以数据为中心的体系构造数据流体系构造：当输入数据通过一系列日勺计算和操作构件日勺变换形成输出数据时，可以应用这种体系构造。信息流被描述为单个数据项，被称为事务，他可以沿多条途径中的一条触发其他数据流。调用和返回体系构造面向对象体系构造层次体系构造重点：1.使用数据流程图和处理论述，描
23、述一种具有明显数据流特性和一种具有明显事务流特性的计算机系统。数据流特性：OPengl管线事务流特性：银行转账以房子或建筑的体系构造作比方，与软件体系构造进行对比。老式的建筑体系构造学科和软件体系构造有何相似之处？有何不同样之处？第10章构件级设计建模构件：系统中某一定型化日勺、可配置日勺和可替代日勺部件，该部件封装并暴露了某些列接口。内聚性：内聚性CoheSiOn意味着构件或者类只封装那些互有关联亲密，以及与构件或类自身有亲密关系日勺属性和操作。耦合性：类之间彼此联络程度的一种定性度量第11章完毕顾客界面设计黄金规则置顾客于控制之下；以不强迫顾客进入不必要日勺或不仅愿日勺动作日勺方式来定义交
24、互模式。提供灵活度日勺交互。容许顾客交互被中断和撤销。当技能级别增长时可以使交互流线化并容许定制交互。使顾客与内部技术细节隔离开来。设计容许顾客与出目前屏幕上的对象直接交互。减少顾客日勺记忆承担；减少对短期记忆日勺规定。建立故意义的缺省。定义直观的快捷方式。界面的视觉布局应当基于真实世界的象征。以不停进展的方式揭示信息。保持界面一致性。容许顾客将目前任务放入故意义日勺环境中。在应用系统家族内保持一致性。假如过去的交互模型已经建立起了顾客期望，除非有不得已的理由，否则不要变化它。重点：1. 试给出两个附加的“减少顾客记忆承担”、“保持界面一致性”的设计原则。2. 假设你被邀请开发一种基于WEB的
25、家庭银行系统。请给出顾客模型、设计模型、心理模型和实现模型。第12章软件测试方略篥成测试单元测试软件测试需要计划和执行一系列的测试环节单元测试集成测试确认测试系统测试重点：1 .用自己B话描述验证与确认B不同样。两者都要使用测试用例设计措施和测试方略吗？验证是保证软件对的0实现某一特定功能的某些列活动；确认是指保证开发的软件可追溯到顾客需求的此外一系列活动。都需要。2 .谁应当完毕确认测试一一是软件开发人员还是软件使用者，阐明你的理由。最终顾客应当完毕确认测试，合理B预期在软件需求规格阐明中定义，顾客是alpha和beta测试B测试人员3 .项目的进度安排是怎样影响集成测试的？集成测试将已经完
26、毕好的构件放在一起进行测试，项目进度的不同样，对于构件就有不同样的完毕时间，集成测试必须要等最终一种构件完毕了才能开始。第13章测试技术两个不同样的测试用例设计技术白盒测试白盒测试侧重于程序控制构造，设计测试用例以保证测试期间程序中所有的语句至少被执行一次，且所有的逻辑条件被检查。基本途径测试是一种白盒测试技术，运用程序图（或图矩阵）生成保证覆盖率的J线性无关的测试机。条件和数据流测试深入检查程序逻辑循环测试补充其他的J白盒测试技术，检查不同样复杂度的循环。黑盒测试黑盒测试用来确认功能需求，而不考虑程序日勺内部构造。黑盒测试技术侧重于软件日勺信息域，通过划分程序日勺输入域和输出域来设计测试用例
27、以提供完全的测试覆盖。等价划分将输入域划分为有也许检查软件特定功能的数据类。边界值分析则检查程序处理边界数据的J能力。重点：1.穷举测试（即便对非常小B程序）与否可以保证程序100%对B?穷举测试是不也许日勺，穷举测试想覆盖所有B逻辑途径，生成测试用例逐一的测试程序逻辑，不过伴随程序中分支的增多，途径0数量呈指数上升，在有限时间内无法完毕穷举测试。第14章产品度软件度量为产品内部属性的J质量评估提供了一种定量的措施，从而可以试软件工程师在产品开发出来之前进行质量评估。重点：1.MCCan的质量原因是在20世纪70年代提出的。自它们提出以来，几乎计算的每个方面改动都很大，并且MCCaH的原因仍然合用于现代软件。你能根据这个事实得出什么结论吗？可维护性可测试性灵活性/产品修正JJtt品转移/产品运行正确性可靠性易用性效率rn完整性书：软件质量的原因不会随时代的变化而变化。（我认为唯一不变的是变化自身，软件质量日勺原因其实很轻易根据客户日勺需求而变化，McCall有效的原因是它的分类十分合理，又易于扩展，涵盖了软件最基本的规定，如对的性，可靠性等，又有对高级属性的J度量，如复用性）
