软件工程期末知识点2016版.doc

试卷结构：填空题1*20 判断题1*10 简答题8*7 大题1*14（需求设计和分析，用例图和类图）概述+软件过程 20% 软件工程技术 50% 软件工程管理 30%平时成绩20% 期末80%Chapter1 软件工程介绍 软件：指令的集合（计算机程序），数据结构：文档。软件特性：软件是设计的，而非制造的，不会“磨损”，但会退化；大多数软件还是采用用户定制的方式软件分类：系统软件、应用软件、工程、科学软件、嵌入式软件、产品线软件、web应用软件、人工智能软件（给定一个软件需要能判断出所属分类）软件退化：不断的变更是软件退化的根本原因软件危机：软件的可靠性没有保障、维护费用不断上升、进度无法预测、成本增长无法控制、程序员无限度增加等、形成软件开发局面失控的状态Chapter2 过程综述*软件工程定义：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护、即将工程化方法应用于软件。（2）在（1）中所述方法的研究;软件工程是计算机科学,工程学,管理学三个学科的综合四个阶段: 传统软件工程 面向对象软件工程 软件过程工程 基于构件的软件开发*软件过程：软件开发中所遵循的路线图，可以定义为一系列模式的组合，这些模式定义了一系列的软件开发中所需的活动、工作任务、工作铲平及相关的行为。*过程定义了一个框架，为有效支付软件工程技术，这个框架必须建立，软件过程构成了软件项目管理控制的基础，并且建立了一个环境以便于技术方法的采用、工作产品的产生、里程碑的建立、质量的保证、正常变更的正确管理。*框架活动framework activities: 沟通、策划、建模(需求分析 设计)、构建(编码 测试)、部署。好处:每个过程有feedback,更好的控制产品质量.*伞活动 Umbrella Activities: 软件项目管理 正式技术评测 软件质量保证 软件配置管理 Work product preparation and production 复用性管理 度量方法 风险管理.CMMI(Capability Maturity Model Integration): 能力成熟度模型集成 四大类过程域(PA) 过程管理 项目管理 工程管理 支持管理*过程评估和改进：用于过程改进的标准CMMI评估方法，提供了五步的过程评估模型，包括启动、诊断、建立、执行和学习；用于组织内部过程评估的一系列要求；软件的CMMI作为评估的根据，提供了一种诊断方法，用以分析软件或软件开发组织的相对成熟度: ISO/IEC 15504 (SPICE)该标准定义了软件过程评估的一系列要求；软件ISO9001:2000 这是一个通用标准，任何开发组织如果希望提高所提供的铲平、系列或服务的整体质量，都可采用这个标准。Chapter3 过程模型软件生命周期：是指从形成开发软件概念起，所开发的软件使用以后，直到失去使用价值消亡为止的整个过程.分析 设计 编码 维护 / 确定应用需求 规范软件需求 构架设计 细节设计 编码实现 整合 维护与软件过程的关系 软件生命周期从时间角度把软件开发和维护的复杂问题分解,划分为有相对独立的任务的若干阶段,逐步完成任务.帮助建立软件过程模型.*瀑布模型：适用于清楚了解问题需求，工作以线性方式进行 优点：为项目提供了按阶段划分的检查点；当前一阶段完成后，只需要去关注后续阶段； 缺点：实际项目很少遵循线性模型；客户常难以清楚描述所有需求；只有在项目接近尾声时，才能看到可执行程序；重大缺陷若在评审之前未被发现会造成惨重损失；容易造成阻塞状态*增量模型：适用于没有足够开发人员的情况，以迭代方式运用瀑布模型，第一个增量往往是核心产品 优点：若开发前期找不到足够的人员，早起的增量可以由少量人员完成，若核心产品口碑不错，可以为下一个增量投入更多人力；可以规避技术风险 缺点：至始至终开发者和客户纠缠在一起，直到完全版本出来；尽管其灵活性能适应需求变化，但也容易退化成边做边改模型，使软件过程缺乏整体性（与原型不同，侧重于每个增量提供一个可操作产品）*原型模型：使用于需求模糊的项目，质量不能保证，是为定义需求而服务。优点：在客户提出了软件的一些基本功能但是没有详细定义输入，处理和输出需求；开发人员可能对算法的效率，操作系统的兼容性和人机交互的形式等不确定情况实施最好的解决方法；客户能对实际系统有直观的认识，能根据反馈不断调整以满足用户需求，采用迭代技术，也使开发者逐步清楚用户需求。 缺点：没有考虑软件的整体质量和长期的可维护性；客户不满意的达不到质量要求的产品可能被抛弃，而采用新的模型重新设计；系统可能不是很完美；构建需要的周期不能确定。*螺旋模型：具有原型的迭代和瀑布模型的系统和可控制性，在每个演讲过程要标记里程碑，适用于大型开发系统和软件。优点：设计灵活,应用于开发的整个生命周期，保持可操作性，更好地应对风险。 缺点：很难说服客户演进方法的可控制性；依赖大量的风险评估专家来保证成功；若有较大的风险没被发现和管理，会出现很大问题；不是交付之后就结束了，应用在软件的整个生命周期。*喷泉模型：该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。优点：可以提高软件项目开发效率，节省开发时间；适用于面向对象的软件开发过程。缺点：由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档、使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况。*统一过程：是一种“用例驱动，以体系结构为核心，迭代及增量”的软件过程框架，由UML方法和工具支持，统一过程是一种增量模型。五个阶段：起始、细化、构建、转化、生产。优点：建立在非常优秀的软件工程原则基础上的，例如迭代，需求驱动，基于结构化的过程开发；提供了几个方法，例如每一次迭代产生一个工作原型，在每一个阶段的结束决定项目是否继续，这些方法提供了对开发过程的非常直观的管理；rational公司已经并将继续对RUP进行开发，使这个基于html的软件工程能够被裁剪为适合你的组织的实际需要。缺点：仅仅包含了开发过程；不支持组织内的多项目开发，导致组织内的大范围的重用无法实现；缺少开发商的支持Chapter4 敏捷视角下的过程*软件工程的敏捷理念 强调四个关键问题：具有控制力的自我组织团队对所开展工作的重要性；团队成员之间，开发参与者与用户之间的交流和合作；对“变更代表基机遇“的认识；强调快速软件交付以让客户满意敏捷开发宣言 个人与交互重于开发过程与工具；可用的软件重于复杂的文档；寻求客户的合作重于对合同的谈判；对变化的响应重于始终遵循固定的计划.*XP 极限编程是应用最广泛的敏捷过程，按照计划，设计，编码和测试的四个框架活动组织，XP建议一系列新颖有力的技术，保证敏捷团队创建能体现客户指定优先级特征和功能的频繁软件发布Chapter6 系统工程*系统工程概念：关注目标系统各种相关要素的分析、设计、并将其组织成有机的系统 (有机 像生命体一样， 各个部分密切配合 有序演化 达到系统的总体目标)计算机系统要素：软件、硬件、人员、数据库、文档和规程计算机系统工程是一个问题求解的活动,其目的是分析基于计算机的系统的功能性能等要求,并把它们分配到计算机系统的各个系统元素中,确定它们的约束条件和接口.系统建模： 部署图 活动图 类图 完成（1）定义在所考虑视图中满足需要的过程（2）描述过程行为和该行为所依据的假设（3）明确定义模型的外在和内在输入（4）描述有助于工程师理解视图的全部联系（包括输出） 制约因素：假设，简化，限制，约束，客户偏好，本质上倾向于分级分层系统模型分类（1）Hatley-Pirbhai 建模 利用用户界面，输入，系统功能和控制，输出，维护和自检的表达方式，可以建立一个系统构建模型，为后面每个工程规范步骤建立良好基础（2）UML系统建模 部署图每个三位方和描述一个属于系统物理架构的硬件要素 活动图圆角矩形：特定的系统功能 箭头：系统流程 菱形：分支 水平线：并发事件 类图和用例图：椭圆表示一个用例Chapter7 需求工程需求工程任务 提供一种适当的机制,以了解客户想要什么，分析要求，评估可行性，协商合理的解决方案，无歧义地规约解决方案，确认规约，以及在开发过程中管理这些被确认的需求规约的过程.需求工程工作产品 需求定义文档(客户角度) 需求规格说明(技术人员角度) 配置管理文档(支持两个文档之间的对应); 必要性和可行性陈述：系统或产品范围的界限说明；参与需求导出的客户，用户和其他共利益者的列表；系统技术环境的说明；需求列表（推荐按照功能加以组织）以及每个需求使用的领域限制；一系列使用场景，有助于深入了解系统或产品在不同运行环境下的使用；任何能够更好的定义需求的原型需求工程开发方法 需求获取:起始1 stakeholders 2从不同视角收集信息 导出3 stakeholders协同合作收集需求(访谈调查会议问卷原型系统) 4 创建用户场景构建用例面向对象的需求获取: 1 识别stakeholders 2 用例驱动分析画出用例 3 解析用例,添加活动图描述需求分析(精化过程建立精确的技术模型) 面向过程: 综合-功能-数据-建模数据字典DD 数据流图DFD 实体关系图ERD 控制流程图CFD 状态转换图STD 核心 功能建模 数据建模 行为建模 行为建模面向对象: 基于UML :类图 包图 对象图 实体建模; 状态图 顺序图 协作图 活动图 行为建模需求处理(协商 形成需求规格说明书)需求确认(评审)Chapter8 构建分析模型分析模型的作用：分析建模使用文字和图表的综合形式，以相对容易理解的方式描绘需求的数据，功能和行为，更重要的是，可以直接地评审它们的正确性，完整性和一致性。分析模型的构造原则（1）模型应关注在问题域或业务域内可见度的需求，抽象的级别应该相对高一些（2）分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域和系统行为的深入理解（3）基于基础结构和其他非功能的模型应推延到设计阶段再考虑（4）最小化整个系统内的关联（5）确认分析模型为所有共利益者都带来价值（6）尽可能保持模型简洁数据建模：数据建模的基本元素：数据对象，属性和关系。数据属性特性（1）为数据对象的实例命名（2）描述这个实例（3）建立对另一个表中的另一实例的引用 作用：数据建模工具为软件工程师提供表现数据对象，数据对象的特点和数据对象的关系的能力，主要用于大型数据库系统和其他信息系统项目，数据建模工具以自动化的方式创建全面的实体关系图，数据对象词典以及相关模型*场景建模：从用户的角度描述软件需求。用例-参与者和软件之间的某个交互的叙述或模板驱动说明-是主要的建模元素。在需求获取过程中提取的用例，定义了特定功能或交互的关键步骤。用例的形式化和详细程度各不相同，但是最终结果为所有的其他分析建模或钉提供了必需的输入。还可以使用活动图说明场景，描述在特定场景中的处理流，泳道图显示了处理如何分配给不同的用户和类*类建模：使用从基于场景和面向流的建模元素中提取的信息确定分析类，可以使用语法分析从文本叙述中提取候选类，属性和操作，并制定了用于定义类的标准，CRC索引卡可以用于定义类之间的联系。此外，可以使用各种UML建模符号定义类之间的层次，联系，关联，聚合和。使用分析包可以将类分类和分组，在某种意义上为大型系统提供了更好管理。*行为建模：描述了软件的动态行为，使用基于场景，面向流和基于类的元素作为输入，从整体上表现分析类和系统的状态，要实现这一点，要识别状态，定义导致类或系统做出状态转移的事件，以及确认当转移完成时所发生的动作。状态图和顺序图常使用。流建模：关注当数据对象通过处理函数转换成功时的流动。在结构化分析的过程中提取的刘模型使用数据流图，即一种建模符号，描述当数据对象在系统中移动时输入如何转变为输出。使用处理规格说明来说明转换数据的每一个软件功能，除了数据流，该建模袁术还说明了控制流，这是显示事件如何影响系统行为的一种表现形式Chapter9 设计工程*四种设计模型：体系结构设计，数据结构设计，接口设计，构件级设计抽象:抽出事物的本质特性而暂时不考虑它们的细节 从特殊到一般 上层是下层的抽象 下层是上层的精化细化体系结构：软件体系结构关注系统的一个或多个结构,包含软件部件 部件对外可见的属性以及部件间的关系;具有一定形式的结构化元素，即构件的集合，包括处理构件，数据构件和连接构件模式：描述了在其某个特定场景中解决某个特定的设计问题的设计结构 (结构模式 设计模式 编码模式)逐步求精：在原始陈述上细化，并伴随每个精化的持续进行将提供更多的细节模块化：按照设计原则将系统划分为若干个较小的模块(构件); 软件被划分为独立命名的，可寻址的构建，有时被称为模块，集成在一起可以满足问题的需求信息隐藏：每个模块对其他所有模块都隐藏自己的内部实现细节;抽象/模块化机制的基本支撑模块独立：每个模块仅涉及需求的某个特定的功能，只有一个简单的接口逐步求精: 将现实问题经过几次抽象（细化）处理，最后到求解域中只是一些简单的算法描述和算法实现问题。即将系统功能按层次进行分解，每一层不断将功能细化，到最后一层都是功能单一、简单易实现的模块。求解过程可以划分为若干个阶段，在不同阶段采用不同的工具来描述问题。在每个阶段有不同的规则和标准，产生出不同阶段的文档资料。重构：不改变代码的外部行为，改变其内部结构，使其更易被理解和维护Chapter10 体系结构设计为何进行体系结构设计（1）软件体系结构的表示有助于对计算机系统开发感兴趣的各方开展交流（2）体系结构突出了早期设计决策，这些决策对随后的所有软件工程工作有深远的影响，同时对系统作为一个课运行实体的最后成功有重要作用（3）体系结构构建了一个相对较小的，易于理解的模型，该模型描述了系统如何构成以及其构件如何一起工作体系结构设计风格：以数据为中心的体系结构；一些数据保存在整个结构的中心,被其他部件频繁使用数据流体系结构；输入数据经处理转化成输出数据调用和返回体系结构; 面向对象体系结构；封装数据操作数据方法 部件之间交互协调通过消息传递层次体系结构 定义多个层次,每层完成了相对外层更靠近机器指令的操作Chapter11 构件级设计建模什么是构件，结构化，OO 构件：系统中某一定型化的，可配置的和可替换的部件，该部件封装了实现并暴露一系列接口构建的设计原则（对OO适用）：开关原则，对扩展开放对修改关闭替换原则，基类一定可以被子类替换依赖倒置原则，程序要依赖于抽象接口，不要依赖于具体实现.接口分离原则，设计时采用多个与特定客户类有关的接口比采用一个通用的接口要好构件设计方法 传统:(1)分析模型体系结构构件,确定每个构件算法(2)确定每个构件数据结构(3)构件级设计说明书面向对象(1)标识类(2)标识基础类(3)细化类接口属性操作(4)说明持久数据源(5)开发并细化类行为表示(6)细化部署图(7)迭代重构异：传统（设计需要充分表示出数据结构，接口和程序块的算法以指导变成语言源码的产生，可使用图形、表格或文本格式一个构件就是程序的一个功能要素，细化控制模型、问题域模块和基础设施模块三种）OO（以类为基础，构件包括一个协作类集合，注重细化来自问题域和基础设施域的射击类） 同：都来自于分析模型，都需要应用哪些导致高质量软件的基本设计原则和概念Chapter13-14 测试测试概念：利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试工具，设计和维护测试系统，对测试方案可能出现的问题进行分类和评估。执行测试用例后，需要跟踪故障，以确保开发的产品适合需求。Validation vs. Verification（验证与确认）：验证：我们把程序写对了么？确认：我们是在写那个我们想要的程序吗？相同点：使用方法基本相同；不同点：目的 对象 修改的参考不同（验证：阶段性验证其正确性, 用上一步的结构做参考; 确认：在运行环境中 客户参与下确保符合用户需求）测试策略：1单元测试：侧重于软件设计的最小单元的验证工作（单元测试考虑、单元测试规程）检查程序模块内部的逻辑 算法 数据处理结果的正确性 面向对象: 最小单元 类中的方法 测试类2集成测试: 传统:1所有构件事先连接在一起，全部程序作为一个整体进行测试;2增量方法，自顶向下:模块的集成顺序从主控模块开始，沿着控制层次结构逐步向下，利用深度优先或广度优先的方式将从属于主控模块的模块集成到结构中去; 自底向上:从程序结构最底层模块开始,集成上层模块测试 OO 无明显的层次控制结构, 基于线程:每个线程单独集成测试 基于使用:独立-依赖-全体. 回归测试: 对已经测试过的子集重新执行 冒烟测试 在将新代码加入产品之前提前测试,尽早发现错误3确认测试：确认软件与软件需求规约是否不一致.全部功能 文档完整 其他需求4系统测试：对完整集成的产品和解决方案进行测试,用来评价系统对具体需求规格说明的功能性和非功能性的符合性的测试.产品级测试用例：（1）以设计或源代码为基础，画出相应的流图（2）确认所得流图的环复杂性（3）确认线性独立路径的基本集合（4）准备测试用例，强制执行基本集合中的每条路径。用例内容有输入，输出，条件测试技术： 黑盒测试：也称行为测试，用来考察数据的输入 条件限制 输出数据，而不考虑程序的内部结构等价类划分 边界值分析 因果图 错误推断法 决策表方法 正交试验法白盒测试：也称结构测试或逻辑驱动测试, 基于内部逻辑结构,针对语句 路径 变量状态测试 检查程序各分支条件是否满足 个执行路径是否按预定要求正确工作. 桌面检查 代码走查 代码审查 逻辑覆盖 基本路径测试手工测试 对模块源代码差错.不需要对代码编译和仿真运行的静态测试只能用手工测试. (逻辑 验收 实用性 交互性 测试) 85%发现缺陷率高 容易实施 创造性 灵活性 覆盖率量化困难 重复测试效率低 不一致性 可靠性低 人力资源自动化测试 往往通过真正运行程序发现测物,通过有效测试用例对应输入输出关系分析被测程序的动态测试使用这一方法 (单元 集成 系统负载或性能 可靠性 测试) 15%速度快 准确 高复用性 永不疲劳 可靠 激励士气 机械难以发现缺陷 一次性投入大相互补充Chapter21 项目管理4Ps: 组织人员，确定产品范围，根据项目特征和项目团队需求选择框架下制定开发过程，科学管理实施有计划可控制的软件项目W5HH：why开发这个系统？需要做出what？when要完成？其功能由who负责？他们的机构组织位于where？how to科学的和管理的完成工作？需要耗费how much资源？Chapter15&22 度量Measures, Metrics, Indicators 测量，度量和指标：Measures (n.测度) 为产品或过程的某些属性的程度，数量，维数，容量或大小提供量化的指示. 这个样本中大于x, x是测度(v.测量) 确定测度的动作。 Measurement(n.测量) 确定测度的动作Metrics (n.度量): 一个系统，构件或过程具有给定属性量化测试程度。 函数返回bool样本是否大于x测度Indicators (n.指标): 一个度量或多个度量的组合，它提供了对软件过程，软件项目或产品本身的深入理解 四种方法实现一个目标,发现两个更正式的方法速度更快. 可以确定一种指标: 正式的方法比其他方法的投资回报大度量的作用：为了有效的采用定量的方式来进行管理,了解软件工程的执行情况和产品质量.Chapter23 估算项目计划任务 1、规定项目范围 2、确定可行性 3、分析风险 4、确定需要的资源（a、确定需要的人力资源；b、确定可重用的软件资源 c、标识环境资源） 5、估算成本和工作量（a、分解问题b、使用规模，功能点，过程任务或用例等方法进行两种以上恩德估算c、调和不同的估算）6、制定项目进度计划（a、建立一组有意义的任务集合b、定义任务网络c、使用进度计划工具指定时间表d、定义进度跟踪机制）项目计划内容估算，进度安排，风险分析，质量管理计划和变更管理计划LOC&FP面向规模的度量和面向功能的度量：LOC以代码行作为其他测量的规范化因子，FP则是从信息域测量及对问题复杂度的主观评估中导出的。均已问题分解为基础 要求WBS每个工作包可以分别独立估算,都有基线生产率度量可以参考或估算Chapter24 进度项目工作量分配原则40-20-40 总体工作量的40%分配给前期的分析和设计，20%用于编码，40%用于后期测试任务网络、关键路径r的优点：很好地展示优先关系；定义关键路径的能力；执行“如果”分析的能力 缺点：默认模型假定资源是无限的，我们需要夹紧资源以来关系当确定自己的“真正”的关键路径；难以跟随大的项目甘特图：定义人员责任,任务结果,确定里程碑,通过适当工具建立进度计划 通过图形的方式更直观的表现出任务安排以及任务之间的关联性,方便管理里程碑：协助范围的审核，给项目执行提供指导，敏捷、详细、可度量、可分配、现实性、期间时限Chapter25 风险被动和主动风险管理被动: 项目团队只有发生风险才会做出反应 缓解-为补救计划额外的资源 修复失败-只有在风险出现时才寻找资源补救 危机管理-当项目风险大是不会为错误投入资源主动: 进行正式的风险分析 从根源预防风险发生 TQM概念和统计SQA 考虑从软件之外来源的风险 培养处理变化的技能Risk Management Paradigm(风险管理过程）*风险管理范例：（循环）识别-分析-规划-(跟