软件工程-总结.doc

《软件工程-总结.doc》由会员分享，可在线阅读，更多相关《软件工程-总结.doc（60页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、Four short words sum up what has lifted most successful individuals above the crowd: a little bit more.-author-date软件工程-总结软件工程复习提纲软件工程复习提纲第1章软件工程介绍2软件是什么2第2章过程综述2软件工程定义2层次化3通用过程框架3第3章 过程模型4各种过程模型4第4章 敏捷视角下的过程6敏捷宣言6第5章 系统工程7第6章 需求工程8质量功能部署（QFD）8分析模型的元素11第7章 构建分析模型11第8章 设计工程11第9章 进行体系结构设计12体系结构风格的分类12

2、第10章 构件级设计建模13第11章 完成用户界面设计13黄金规则13第12章 软件测试策略14软件测试需要计划和执行一系列的测试步骤14第13章 测试技术15两个不同的测试用例设计技术15第14章 产品度量15第1章软件工程介绍软件是什么软件是形成配置的一组术语或对象，包括：程序(计算机程序): 指令的集合,通过执行这些指令可以满足预期的特征、功能和性能需求数据结构:它使得程序可以充分利用信息文档:描述程序操作和使用的文档（图文资料）1. 举例说明“意外效应法则”（law of unintended consequences）在计算机软件方面的应用。某些新科技的发明创造会给其他一些看似无关的

3、技术领域、商业企业、公众甚至整个社会文化带来深远而出人意料的影响和作用。如：2. 用自己的语言描述保证通晓规律（ The Law of Conservation of Familiarity）、质量衰减规律（ The Law of Declining Quality ）以及组织稳定性守恒规律（ The Law of Conservation of Organizational Stability ）。保证通晓性规律 (1980): 随着E类型系统的演化，所有相关人员（如开发人员、销售人员和用户）都必须清楚地了解演化的内容和过程，以便达到满意的演化效果。 质量衰减规律 (1996): 如果没有严

4、格的维护和适应性调整使之适应运行环境的变化，E类型系统的质量有衰减的趋势。组织稳定性守恒规律 (1980): 一个不断演化的E类型系统，其组织在全球范围内的平均有效活动率在产品的生命周期中是保持不变的。3. 在交付最终用户之前，或者第1个版本投入使用之后，许多应用程序都会有频繁的变更。为防止变更引起软件失效，请提出一些有效的解决措施。首先从心态上承认变化是必然的，我们可以通过在软件发布之前进行alpha , beta 测试，利用迭代模式，在吸取测试过程中的经验之后，立刻改进软件。同时保持和用户的良好沟通，在提交用户时进行适当培训，让用户按照开发思路进行试用，可以见减少因使用方法不当引起的变化。

5、第2章过程综述软件工程定义软件工程是：（1）将系统化、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。（2）在（1）中所述的方法的研究。层次化通用过程框架1. 沟通（Communication）2. 策划（Planning）3. 建模（Modeling）a) 需求分析（Analysis of requirements）b) 设计（Design）4. 构建（Construction）a) 代码生成（Code generation）b) 测试（Testing）5. 部署（Deployment）重点：1. Baetjer说过“软件过程为用户和设计者之间、用户和开发工具之间

6、以及设计者和开发工具之间提供交互的途径技术。”设计下面问题“ 设计者应该问用户的； 用户应该问设计者的； 用户对将要构建的软件的自问； 设计者对于软件产品和建造该产品采取的软件过程的自问。（如何获取需求）2. 为沟通活动设计一个任务集1. 识别主要客户和其他共利益者2. 与客户会谈环境无关的话题3. 写一页项目范围4. 评审范围说明5. 讨论项目大致的阶段6. 商定各个部门的代表，并使他们相互认识7. 为计划活动做准备3. 用自己的话描述过程框架。当我们谈到框架活动适用于所有的项目时，是否意味着对于不同规模和复杂度的项目，可应用相同的工作任务？请解释。过程框架定义了若干小的框架活动，为完整的软

7、件开发过程建立的基础，这些框架活动可以广泛用于所有的软件开发项目，无论这些项目的复杂性和规模如何，此外，还包括一些适用于各个软件过程的普适性活动。虽然过程框架是普适性的，但是对于不同规模和复杂度的项目不能应用相同的工作任务。首先在软件开发的不同阶段，工作任务不同。其次不同的软件项目有不同的需求，有特殊的背景，找不到一种通用的工作任务。4. 图2-1中，基于“质量关注点”指明了软件工程三个层次。这意味着在整个开发组织内采用质量管理活动，如“全面质量管理”。仔细研究，并列出全面质量管理活动中关键原则的大纲。第3章 过程模型各种过程模型惯例软件过程模型力图给软件开发带来秩序和结构。尽管每一传统过程模

8、型都建议了一种不同的过程流，但均实现了同样的一组通用框架活动：沟通、计划、建模、构建和部署。瀑布模型建议线性流程的框架活动，与软件世界里当代软件开发实际（持续的变更、演化的系统、紧迫的开发时间）不符；但瀑布模型确实适用于需求定义清楚且稳定的软件开发；增量软件过程模型通过一系列的增量发布产生软件。RAD模型快速应用程序开发，是为大型且必须在严格的时间内提交的项目而设计的；演化过程模型认识到大多数软件工程项目的迭代特性，其设计的目的是为了适应变更演化模型（如原型模型、螺旋模型），其快速产生增量的工作产品（或是软件的工作版本），这些模型可以应用于所有的软件工程活动从概念开发到长期的软件维护。基于构建

9、的模型强调构件复用及组装。形式化方法模型提倡采用数学的方法进行软件开发和验证。面向方面的模型目的是解决跨整个软件体系结构的横切关注点；统一过程模型是一种“用例驱动、以体系结构为核心、迭代及增量”的软件过程框架，由UML方法和工具支持。统一过程是一种增量模型，定义了五个阶段：起始阶段：包括用户沟通和计划活动两个方面，强调定义和细化用例，并将其作为主要模型；细化阶段：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示；构建阶段：细化设计模型，并将设计模型转化为软件构建实现；转化阶段：将软件从开发人员传递给最终用户，并由用户完成Beta测试和验收测试；生产阶段：持续地监控

10、软件的运行，并提供技术支持。重点：1. 开发质量“足够好”的软件，其优点和缺点是什么？当我们追求开发速度胜过产品质量的时候，会产生什么后果？我们总在质量和开发速度之间做取舍，开发质量“足够好”的软件，明显强调质量，优点是使软件符合或超出客户的预期，在性能上，交互上力图做到尽善尽美。缺点是忽视了开发成本，很容易造成开发时间延期，影响软件工程后几个阶段的工作，对全局造成不利影响。2. 当沿着螺旋过程流发展的时候，你对正在开发或者维护的软件的看法是什么？ 在螺旋模式下，开发过程是迭代式的，采用循环的方式逐步加深系统定义和实现的深度，同时降低风险。当软件交付使用后，螺旋模式没有停止，它将永远保持可操作

11、性，每一圈完成后都会计算成本，可以更好的维护软件。3. 可以合用几种过程模型吗？如果可以，举例说明。可以。几种过程模型，都是相互兼容可以相互扩展的，如螺旋模型结合了原型的迭代性质和瀑模型的系统性和可控性的特点。在具体项目实施中，对于某一部分可以合用几种过程模型，比如形式语言与自动机演示软件在算法开发过程，就需要使用形式化方法模型，用严格的数学符号定义形式语言和自动机。还有一些桌面应用程序的前台UI部分，可以单独使用RAD模型，比如用delphi语言开发桌面窗体就是一种RAD实现。而其他部分可以使用其他如瀑布式模型等方法。第4章 敏捷视角下的过程敏捷宣言l 个体和交互胜过过程和工具（Indivi

12、duals and interactions over processes and tools ）l 可工作软件胜过宽泛的文档（Working software over comprehensive documentation） l 客户合作胜过合同谈判（Customer collaboration over contract negotiation）l 响应变化胜过遵循计划（Responding to change over following a plan ）重点：1. 是否每一个敏捷过程都可以用第2章所提及的通用框架性活动来描述？建一张表，将通用活动和每个敏捷过程所定义的活动对应起来。2

13、. 用自己的语言描述（用于软件项目的）敏捷性？普遍存在的变化是敏捷的基本动力，敏捷需要有效的响应变化，它鼓励在共利益者之间进行更便利的沟通和协作，强调可运行软件的快速交付。敏捷允许项目团队调整并合理安排任务，理解易变性并制定计划。精简并维持最基本的工作产品，强调增量交付，快速提供可运行软件。3. 许多敏捷过程模型推荐面对面交流，实际上，现在软件开发团队成员及其客户在地理上是分散的。你是否认为这意味着这种地理上的分散应当避免？能否想出一个办法克服这个问题。我认为这种地理上的分散是现实，是无法避免的。我认为可以分为客户和开发人员的分散，开发人员内部分散两种情况。对于第一种：产品经理需要同客户建立一

14、条良好的通信信道，如通过email,即时聊天工具进行定期沟通。对于第二种：开发人员需定期组织交流，通过web group 消除地理上的分散。4. 为什么需求变化这么大，人们终究无法确定他们想要什么吗？ 我认为是这样的。其实需求是客户对他们心目中软件的一种描述，因为软件还没有实现，这种描述便是不确定的，模糊的。同时当今世界处于高速变化之中，人们的需求会随着环境的改变而改变。所以敏捷开发承认变化，认为普遍存在的变化是敏捷的基本动力。第5章 系统工程在写下每行代码之前l 理解所要解决的问题(详见沟通与建模)l 理解基本的设计原则和概念l 选择一种能够满足软件构建以及运行环境要求的编程语言l 选择一种

15、能提供工具以简化工作的编程环境l 构件级编码完成后进行单元测试系统工程层次图重点：1. 对你熟悉的系统、产品或服务，建立它们的层次系统。层次应该向下扩展到简单系统要素（硬件、软件等），至少得到层次树的一个分支。 即时聊天系统2. 系统工程师由3种来源：系统开发人员、用户或一些外部组织。讨论一下每种来源的利与弊。描述一个理想的系统工程师。3. 研究文献并写出一篇简短文章描述建模和模拟工具是如何工作的。或者是收集两个或更多的商用建模或模拟工具的文献，并且比较它们的相似处与不同处。第6章 需求工程质量功能部署（QFD）是一种将客户要求转化成软件技术需求的技术。QFD“目的是最大限度地让客户从软件工程

16、过程中感到满意”，并强调“什么是对客户有价值的”。确认三类需求：l 正常需求：反映了在和客户开会时确定的针对某产品或系统的目标。如果实现了这些需求，将满足客户（例如：所要求的图形显示类型、特定的系统功能以及已定义的性能级别）。l 期望需求：隐含在产品或系统中，并且可能是非常基础的以至于客户没有显式地说明，但缺少这些将导致客户明显不满（例如：易交互性、可操作性、可靠性、易安装等）。l 令人兴奋的需求：反映了客户期望之外的特点，但如果实现了这些特点，将会使客户非常满意。重点：1. 为如下活动之一开发一个完整的用例： 在ATM提款； 在餐厅使用信用卡付费； 使用一个在线经纪人账户购买股票； 使用在线

17、书店搜索书（某个指定主题）；ATM用例图“ATM取款”用例规约用例名称：ATM取款简述：客户持银行卡（本行或其他行）从ATM提取现金actors:客户和银行主机基本流：1. 客户插入银行卡。2. ATM从银行卡读入卡号（含银行标识和账号），验证卡的有效性。3. 客户输入密码。4. ATM验证帐号和密码。5. ATM显示包括取款在内的服务功能，客户选择“取款”。6. 输入取款额：客户输入数量为50元的倍数的取款额。7. ATM向银行主机通知卡号、密码、账号和取款额，获得含有最新余额的取款成功确认信息。8. ATM打印并吐出凭条。9. ATM清点并吐出现金，记录取款成功。10. ATM询问客户是否

18、继续服务。11. 客户选择否，ATM吐出银行卡，结束用例，否则回到步骤5。用例结束备选流：3-7，10a. 客户取消服务：ATM记录服务取消，打印凭条，吐出凭条和银行卡，用例失败3,6,11a. 客户未及时输入超过30秒：ATM吞卡，用例失败2a. 卡无效：ATM吞卡，用例失败2b. 读卡器或卡被损坏：ATM吞卡，用例失败4a. 密码错：4a1. 客户重新输入密码a. 累计3次密码错误：ATM吞卡，用例失败4b. 无此帐号：ATM吞卡，用例失败5a. ATM无现金：ATM不显示“取款”功能，客户可选择其他服务， 用例失败6a. 取款额超过ATM现金余额：ATM要求客户重新输入取款额。7a. 帐

19、户余额不足：ATM要求客户重新输入取款额。7b. 取款额超过当日最高限额：ATM要求客户重新输入取款额。7c. 网络或银行主机失效、通讯超时：ATM记录服务取消，打印凭条，吐出凭条和银行卡，用例失败8a. 凭条打印失败，纸用完或卡纸：8a1. ATM通知银行主机取消取款8a2. ATM记录服务取消，吐出银行卡，用例失败9a. 吐现金失败：9a1. ATM通知银行主机取消取款9a2. ATM记录服务取消，吐出银行卡，用例失败11a. 客户未及时取走卡： ATM吞卡，用例失败业务规则：7b 单日取款不得超过5000元6c 每次取款不得超过2000元2. 为什么大量的软件开发人员没有足够重视需求工程

20、？以前有没有什么情况让你可以跳过需求工程？首先软件开发人员认为客户已经把需求说清楚了，但是大多数情况初步的需求都是模糊的。其次工程的进度要求很紧迫，软件开发人员迫切希望投入到代码编写阶段。最后和客户沟通比较困难，使得大多数软件开发人员不重视需求工程。又一次，项目时间很短，要求一个月完成，我们只是大体上对需求有一个认识，就跳过需求工程开始动手编码，结果当然失败了。3. 简短地讨论一个分析模型的每个元素，指出每个元素对模型的贡献，每个元素为什么是唯一的以及每个元素所表示的概要信息。分析模型的元素基于场景的元素(用例图)：使用基于场景的方法可以从用户的视角描述系统。例如基本的用例和基于模板的用例。通

21、常的分析模型的第一步，作为创建其他模型的输入。基于类的元素（类图）:每个使用场景都暗示着当一个参与者与系统交互时所操做的一组对象，这些对象被分成类具有相似属性和共同行为的事务集合。行为元素(状态图)：状态指明了在某个特殊事件后采取什么动作。面向信息流的模式：描述信息的转换。第7章 构建分析模型重点：1. 简单用几句话尝试说明结构化分析和面向对象分析的主要差别？结构化分析考虑数据和处理，其中数据作为独立的实体转换，数据对象建模定义了对象的属性和关系，操作对象的处理建模应当表明数据对象在系统内流动时处理如何转换数据。面向对象分析关注于定义类和影响客户需求的类之间的协作方式。2. 有没有可能在分析模

22、型创建后立即开始编码？解释你的答案，然后说服反方。第8章 设计工程重点：1. 如果软件设计不是程序（它确定不是），那么它是什么？是一套坚固、适用和赏心悦目的模型或设计表示。它包括数据、类设计，体系结构设计、接口设计、构件设计。2. 当你“编写”程序时你设计软件吗？软件设计和编码有什么不同吗？设计。软件设计是逐步细化一个可以工作的模型，而编码是在生成一个可执行的程序。软件设计主要关注是否实现了用户需求，必须从实现的角度说明数据域、功能域和行为域，是编码工作的指导。3. 用你自己的话说明软件体系结构。系统结构是程序构件（模块）的结构或组织，这些构件交互的形式以及这些构件所以数据的结构。构件可以被推

23、广，用于代表主要的系统元素及其交互。第9章 进行体系结构设计体系结构风格的分类以数据为中心的体系结构数据流体系结构：当输入数据经过一系列的计算和操作构件的变换形成输出数据时，可以应用这种体系结构。信息流被描述为单个数据项，被称为事务，他可以沿多条路径中的一条触发其他数据流。调用和返回体系结构面向对象体系结构层次体系结构重点：1. 使用数据流程图和处理叙述，描述一个具有明显数据流特征和一个具有明显事务流特性的计算机系统。数据流特征：opengl管线事务流特性：银行转账以房子或建筑的体系结构作比喻，与软件体系结构进行对比。传统的建筑体系结构学科和软件体系结构有何相似之处？有何不同之处？第10章 构

24、件级设计建模构件：系统中某一定型化的、可配置的和可替换的部件，该部件封装并暴露了一些列接口。内聚性：内聚性cohesion 意味着构件或者类只封装那些相互关联密切，以及与构件或类自身有密切关系的属性和操作。耦合性：类之间彼此联系程度的一种定性度量第11章 完成用户界面设计黄金规则 置用户于控制之下；以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。 提供灵活度的交互。 允许用户交互被中断和撤销。 当技能级别增长时可以使交互流线化并允许定制交互。 使用户与内部技术细节隔离开来。 设计允许用户与出现在屏幕上的对象直接交互。 减少用户的记忆负担； 减少对短期记忆的要求。 建立有意义的缺省。

25、 定义直观的快捷方式。 界面的视觉布局应该基于真实世界的象征。 以不断进展的方式揭示信息。 保持界面一致性。允许用户将当前任务放入有意义的环境中。 在应用系统家族内保持一致性。 如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它。重点：1. 试给出两个附加的“降低用户记忆负担”、“保持界面一致性”的设计原则。2. 假设你被邀请开发一个基于WEB的家庭银行系统。请给出用户模型、设计模型、心理模型和实现模型。第12章 软件测试策略软件测试需要计划和执行一系列的测试步骤 单元测试 集成测试 确认测试 系统测试重点：1. 用自己的话描述验证与确认的不同。两者都要使用测试用例设计

26、方法和测试策略吗？验证是确保软件正确的实现某一特定功能的一些列活动；确认是指确保开发的软件可追溯到用户需求的另外一系列活动。都需要。2. 谁应该完成确认测试是软件开发人员还是软件使用者，说明你的理由。最终用户应该完成确认测试，合理的预期在软件需求规格说明中定义，用户是alpha 和beta 测试的测试人员3. 项目的进度安排是如何影响集成测试的？集成测试将已经完成好的构件放在一起进行测试，项目进度的不同，对于构件就有不同的完成时间，集成测试必须要等最后一个构件完成了才能开始。第13章 测试技术两个不同的测试用例设计技术 白盒测试 白盒测试侧重于程序控制结构，设计测试用例以保证测试期间程序中所有

27、的语句至少被执行一次，且所有的逻辑条件被检查。 基本路径测试是一种白盒测试技术，利用程序图（或图矩阵）生成保证覆盖率的线性无关的测试机。 条件和数据流测试进一步检查程序逻辑 循环测试补充其他的白盒测试技术，检查不同复杂度的循环。黑盒测试黑盒测试用来确认功能需求，而不考虑程序的内部结构。黑盒测试技术侧重于软件的信息域，通过划分程序的输入域和输出域来设计测试用例以提供完全的测试覆盖。等价划分将输入域划分为有可能检查软件特定功能的数据类。边界值分析则检查程序处理边界数据的能力。重点：1. 穷举测试（即便对非常小的程序）是否能够保证程序100%正确？穷举测试是不可能的，穷举测试想覆盖所有的逻辑路径，生

28、成测试用例逐个的测试程序逻辑，但是随着程序中分支的增多，路径的数量呈指数上升，在有限时间内无法完成穷举测试。第14章 产品度量软件度量为产品内部属性的质量评估提供了一种定量的方法，从而可以试软件工程师在产品开发出来之前进行质量评估。重点：1. McCall的质量因素是在20世纪70年代提出的。自它们提出以来，几乎计算的每个方面改动都很大，而且McCall的因素仍然适用于现代软件。你能根据这个事实得出什么结论吗？书：软件质量的因素不会随时代的变化而变化。（我认为唯一不变的是变化本身，软件质量的因素其实很容易根据客户的需求而改变，McCall 有效的原因是它的分类十分合理，又易于扩展，涵盖了软件最基本的要求，如正确性，可靠性等，又有对高级属性的度量，如复用性）-