2013级云计算专业软件工程学期末考试复习大纲

一、 第一章软件工程介绍

（1） 何为软件？

（2） 软件和硬件不同的特性：

① 软件是设计开发的，而不是传统意义上生产制造的。

② 在软件不会“磨损”，但存在退化，硬件失效曲线与软件失效曲线对比

③ 整体向着基于构建的模式发展，但多数仍是按客户需求定制的。

（3） 软件危机（了解）是引入软件工程的原因

（4） 何为软件工程？（IEEE1993的定义）：软件工程是：（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。（2）在（1）中所述方法的研究。

二、 第二章过程综述

（1） 软件工程是一种层次化技术，其包括质量关注点、过程、方法和工具。

（2） 过程框架定义了若干小的框架活动，为完整的软件开发过程建立了基础。

① 通用过程框架活动包括沟通、策划、建模、构建和部署五种。

② 过程框架还包含一些适用于各个软件过程的普适性活动。这样活动主要有软件项目跟踪和控制、风险管理、软件质量保证、正式的技术复审、测量、软件配置管理、可复用管理和工作产品的准备和产生。

三、

第三章过程模型

（1） 软件过程模型是软件开发全部过程、活动和任务的结构框架，也称软件开发模型或软件生存周期模型。

① 惯例过程模型（又称传统过程模型、严格过程模型），强调对过程活动和任务的详细定义、识别和应用。它力求实现结构化和有序。

② 敏捷过程模型提倡弱化软件过程中过于正式的要求，并将自我组织、协作、沟通和可适应性作为主要原则。

③ 惯例软件过程模型主要有瀑布模型、演化过程模型和统一过程模型等类型。

（2） 瀑布模型

① 瀑布模型又被称为经典生命周期，它提出了一个系统的、顺序的软件开发方法。它从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供一个完整的软件并提供持续的技术支持。

② 瀑布模型存在的问题：

 缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发，实际的项目很少遵守瀑布模型提出的顺序。

 客户必须要有耐心，因为只有在项日接近尾声的时候，他们才能得到可执行的程序。

 开发早期存在的问题往往要到交付使用时才发现，维护代价大。

（3） 演化过程模型演化模型是迭代的过程模型，使得软件工程师能够逐步开发出更完整的软件版本。其主要有原型模型和螺旋模型两种。

① 原型模型的主要特点

 快速制订原型开发的计划、快速建模和快速构建

 原型应交付给客户试用，并收集反馈意见，改进原型

②

螺旋模型结合了原型的迭代性质和瀑布模型的系统性和可控性特点。随着演进过程的开始，从圆心开始顺势针方向，执行螺旋上的一圈表示的活动。每次演进都要考虑风险，每个演进过程都要标记里程碑。螺旋模型应用在计算机软件的整个生命周期。是开发大型系统的理想方法，可以有效的应对风险。

 螺旋模型的特点：

 可应用在计算机软件的整个生命周期

 是开发大型系统和软件的理想方法

 把原型开发作为降低风险的机制

（4） 统一过程（UP）是一种“用例驱动、以架构为核心，迭代并却增量”的软件过程。其包括并发进行的起始、细化、构建、转化和生产5个阶段。

 起始阶段包括沟通和策划，定义软件的需求，提出系统的大致框架，并制定开发计划，以保证开发具有迭代和增量的特性。

 细化阶段包括沟通和建模活动。细化阶段扩展了起始阶段定义的用例，并扩展体系结构以包括软件的5种视图：用例模型、分析模型、设计模型、实现模型和部署模型。

 构建阶段于通用软件过程中的构建活动相同，构建采用体系结构模型作为输入，开发系统构建，使最终用户能够操作用例。

 转化阶段包括通用构建活动的后期活动以及部署活动。软件被提交最终用户进行beta测试，并发布支持信息（手册、问题解决指南及安装步骤）。转换阶段结束时，软件增量称为可用的发布版本。

 生产阶段和通用过程的部署活动一致。在该阶段，监控软件持续使用，提供运行环境的支持，提交缺陷报告和变更请求。

四、 第四章敏捷视角下的软件过程

（1） 敏捷联盟的12条原则（了解即可，注意选择题和判断题）

① 尽早交付有价值的软件来让顾客满意。

② 在后期也欢迎变更，利用变更来为客户创造竞争优势。

③ 交付的时间间隔越短越好。

④ 业务人员和开发人员必须天天在一起。

⑤ 围绕受激励的个人构建项目。

⑥ 最有效的信息传递方式是面对面交谈。

⑦ 可工作软件是进度的首要度量标准。

⑧ 提倡可持续的开发速度。

⑨ 关注优秀的技能和好的设计。

⑩ 简单是必要的。

⑪ 好的架构和设计出自于自组织团队。

⑫ 每隔一定时间，反省工作，调整行为。

（2） 建立敏捷过程的三个关键性假设

① 提前预测哪些需求是稳定的和哪些需求会变化非常困难。

② 对很多软件来说，设计和构建是交错进行的。

③ 从制定计划的角度来看，分析、设计、构建和测试并不像我们所设想的那么容易预测。

（3） 极限编程(eXtreme Programming, 简称XP)是一种常用的敏捷过程。它使用面向对象方法作为推荐的开发范型。XP包括策划、设计、编码和测试4个框架活动。

①

策划活动开始于建立一系列描述待开发软件必要特征与功能的“故事”，XP团队成员评估每一个故事并给出以开发周数为度量单位的成本。

② 设计严格遵循KIS原则，适用简单而不是复杂的表述。鼓励适用CRC卡来组织相关的对象和类，鼓励重构。

③

编码的一个关键概念是结对编程。两个人面对同一台计算机共同为一个故事开发代码。实施中两个人担当的角色略有不同。

④ 测试。在编码开始之前建立单元测试是XP的关键因素，所建立的单元测试应当适用一个可以自动实施的框架，易于重复执行，这种方式支持代码修复后的回归测试策略。

（4） Scrum是一种有效解决时间紧张的、需求变化的和业务关键的项目的敏捷过程。Scrum过程定义了计划会议、每日例会、评审会议和回顾会议四种会议。

① Scrum的计划会议

 订出 Sprint 目标和需要完成的Backlog

 对本次Sprint 的Backlog进行必要的细化和任务分割

 会议的结束后，团队将会决定他们能够交付哪些东西，以及验收的标准

② Scrum的每日例会

 团队成员间工作进度的沟通和协调

 昨天做了什么

 存在什么问题

 今天准备做什么

 沟通任务板和燃尽图

③ Scrum的评审会议

 团队在会议中向最终用户展示这次 Sprint工作成果

 评审检查是否已达到 Sprint 的目标

 团队成员得到反馈，并以之创建或变更 Backlog条目

④ Scrum的回顾会议

 继续做„„(保持好的做法)

 停止做„„（去除错误的做法）

 更好地做„„（改进有问题的做法）

五、 第七章需求工程

（1） 需求工程是一个软件工程动作，始于沟通并持续到建模。

（2） 需求工程为以下工作提供了良好的机制：理解用户需要什么、分析要求、评估可行性、协商合理的方案、无歧义的详细说明方案、确认规格说明。

（3） 需求工程过程通过执行起始、导出、精化、协商、规格说明、确认和管理七个不同的活动来完成。

① 在起始阶段，软件工程师会询问一些似乎与项目无直接关系的问题，以建立基本的谅

解。

②

导出需求面临范围问题、理解问题和易变问题。导出需求的主要有协同需求收集、质量功能部署和用户场景三种方法。

③

精化阶段开发精确的技术模型用以说明软件的功能、特征和约束。精化的最终结果是形成一个分析模型，该模型定义了问题的信息域、功能域和行为域。

④ 通过协商过程来调解客户/最终用户提出的过高要求和需求冲突。

⑤ 规格说明是需求工程师完成的最终工作产品。它将作为软件工程师后续活动的基础，它描述了一个基于计算机系统的功能和特性，以及那些将影响系统开发的约束。

⑥ 在确认阶段将对需求工程的工作产品进行质量评估。确认需求时需要检查需求模型的一致性、是否有遗漏以及歧义性。正式技术评审是最主要的需求确认机制。

⑦

需求管理用于帮助项目组在项目进展中标识、控制和跟踪需求以及变更需求的一组活动。

（4） 质量功能部署（QFD）是一种将客户要求转化为软件技术的技术。QFD目的是最大限度的让客户从软件工程中感到满意。它确认三类需求：正常需求、期望需求、令人兴奋的需求。

（5）

需求工程导出的工作产品包括七种：必要性和可行性陈述、系统或产品范围的说明、客户/用户及共利益者的列表、系统技术环境的说明、需求列表及每个需求适用的领域限制、一系列适用场景和任何能够更好定义需求的原型。

（6） 分析模型应为基于计算机的系统提供必要的信息、功能和行为域的说明。分析模型主要包括基于场景的元素、基于类的元素、行为元素和面向信息流的元素。

六、 第八章构建分析模型

（1）

分析模型使用文字和图表的综合形式以相对容易理解的方式描绘需求的数据、功能和行为。更重要的是可以更直接的评审它们的正确性、完整性和一致性。

（2） 分析模型必须实现的三个主要目标：描述客户需要什么、为软件设计奠定基础、定义在软件完成后可以被确认的一组需求。分析模型在系统描述和设计模型之间建立桥梁。

（3） 分析建模的方法主要有面向对象分析和结构化分析两种。前者关注于定义类和影响客户需求的类之间的协作方式。而后者则考虑数据和数据处理的分析建模方法。

（4） 基于场景的建模从用户的角度表现系统；面向流的建模在说明数据对象如何通过处理函数进行转换方面提供了指示；基于类的建模定义了对象、属性和关系；行为建模描述了系统状态、类和事件在这些类上的影响。

 基于场景的模型从用户的角度描述软件需求。用例是主要的建模元素，还可以适用活动图说明场景，泳道图显示了处理流如何分配给不同的用户。

 面向流的建模，常常使用DFD（数据流图）。它开始于环境图，结束于模块规格说明。

 在基于类的建模型中，按职责划分可将类分为实体类、控制类和边界类三种。CRC（类-职责-协作）提供了一个简单的方法，可以识别和组织与系统或产品需求相关的类。CRC卡片被分为三部分，顶部写类名，下面左侧列出类的职责，右侧部分列出类的协作关系。

 可以运用UML的状态图和顺序图进行行为建模。