软件项目工程复习资料提纲.doc

-/ v 1.什么是软件？ v 是一系列按照特定顺序组织的计算机数据和指令的集合，包括程序、数据和文档。 v 附：软件的特征：成本高、风险大、维护困难 v v 2.什么是软件危机，其内容主要是指什么？ v 原因：1、与软件本身的特点有关；2、与软件开发人员有关； 定义： 在计算机软件开发和维护过程中所遇到的一系列严重的问题。 1）对软件开发成本和进度的估计常常不准确。 2）用户对“已完成”系统不满意的现象经常发生。 3）软件产品的质量不可靠。 4）软件的可维护程度非常之低。 5）软件通常没有适当的文档资料。 6）软件的成本不断提高。 7）软件开发生产率无法满足人们对软件的生产要求，软件开发生产率的提高落后于硬件的发展。 3.什么是软件工程？ 开发、运行和维护软件的系统方法 • 软件工程主要研究软件生产的客观规律性，建立与系统化软件生产有关的概念、原则、方法、技术和工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本 、改进软件产品质量、提高软件生产率水平的目标。 4.软件工程的目标（ PP.41 ）及其组成部分。方法、工具和过程。 • 软件工程的目标是：在给定成本、进度的前提下，开发出具有适用性、有效性、可修改性、可靠性、可理解性、可维护性、可重用性、可移植性、可追踪性、可互操作性和满足用户需求的软件产品。 方法: 是指产生某些结果的形式化过程， • 工具: 是用更好的方式完成某件事情的设备或自动化系统，如各种集成开发环境、编译工具、测试工具等。 • 过程: 生产特定产品的工具和技术的结合 • 软件工程方法学包含3个要素：方法、工具和过程。 5.软件开发方法的定义。 通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学。 比如SASD方法、面向对象的软件开发方法。 6.好的软件的一些主要衡量指标。例如McCall 的质量模型。 （1）质量,它的衡量：产品的质量、过程的质量、商业环境背景下产品的质量。 McCall 的质量模型： • 需求分析员: 与客户合作，确定并文档化客户需求 • 设计人员: 生成系统描述:系统要做什么 • 程序员: 编写事先指定需求的代码 • 测试人员: 发现错误 • 培训人员: 向用户说明如何使用这个系统 • 维护小组: 修复系统验收之后出现的错误 • 资料管理员: 准备和存储软件需求文档等 • 配置管理团队: 保持各工件之间的通信 附：开发团队的成员 第二章 1.什么是软件生命周期？主要分为哪些阶段？各个阶段的主要任务及产生的主要制品？ 定义：当过程是在开发软件产品时，把这种软件开发过程称为软件生命周期。 阶段： (1)可行性研究与计划 任务：对于问题是否有行得通的解决方法（技术、经济、操作、社会） 制品：可行性论证报告 初步的项目开发计划 (2)需求分析 任务：为了解决这个问题，目标系统必须做什么 制品：软件需求规格说明书 (3)总体（概要）设计 任务：概括地说，应该怎样实现目标系统 制品：概要设计规格说明书 数据库或数据结构设计说明书 集成测试计划 (4)详细设计 任务：应该怎样具体地实现这个系统 制品：详细设计规格说明书 单元测试计划 (5)实现 任务：写出正确的容易理解、容易维护的程序模块 制品：源程序代码 (6)集成测试 任务：根据概要设计规格说明书，将经过单元测试的模块逐步进行集成和测试 制品：生成满足概要设计要求、可运行的系统源程序和系统集成测试报告 (7)确认测试 任务：根据软件需求规格说明书，测试软件系统是否满足用户的需求 制品：可供用户使用的软件产品(文档，源程序) (8)使用和维护 任务：通过各种必要的维护活动使系统持久地满足用户的需要 制品：版本更新的软件产品 2.需求分析的定义。 – 确定用户对待开发软件系统的需求包括： • 功能 • 性能 • 运行环境约束 3.典型的软件开发过程模型的特点（优缺点）及要求，特别是原型法、瀑布模型、增量和迭代等 （1）瀑布模型：需求分析->系统设计->程序设计->编码->单元测试和集成测试->系统测试->验收测试->运行和维护； 优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶段交出的产品必须经过验证； 缺点：对如何处理开发中产品和活动的变化没有提供相关的指导 • 将软件开发视为制造而不是创造 • 创造一个产品没有迭代的活动 • 需要等待很长时间 （2）V模型： • 用单元测试验证程序设计 • 用系统测试验证系统设计 • 用验收测试验证需求 • 如果在验证和确认过程中发现了问题，那么在再次执行右边的测试步骤之前，重新执行左边的步骤以修正左边 （3）原型化模型： • 允许需求或设计反复调查 • 减少开发中的风险和不确定性 • • 原型模型存在的问题 • ⑴ 为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。 • ⑵ 为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。 • ⑶ 开发过程不便于管理。 （3）增量开发: 先定义一个小的功能子系统，再在每个新的发布中增加新功能 迭代开发: 一开始就提交完整的系统，再在每一个新的发布中改变每个子系统的功能 • 减少循环时间 • 系统一部分一部分地交付 • 两个系统功能可以并行 4. 原型法的特点以及分类：探索型原型、实验型原型和演化型 原型法定义 原型法是指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。 • 演化型原型 – 不仅帮我们回答问题，而且还要演变为最终产品 – 原型必须展现最终产品的质量需求，并且这些质量的要求不能改进 5.极限编程的特点 – 交流: 保持客户和开发者的交换看法 – 简单性: 选择简单设计和实现 – 勇气: 尽早并经常性交付功能(敢于承诺并信守诺言) – 反馈:开发过程中各种活动循环 第三章 v 1. 了解项目计划和管理的主要内容和常用的方法。 v Ppt71到81 v v 2.软件可行性研究的内容。 v 技术、经济、操作、社会四个可行性 v v 3. 估算工作量的主要方法：代码行、任务分解技术、自动估算成本技术。 v 1）代码行技术 v 软件成本 = 每行代码的平均成本估计的源代码总行数 估算方法： • 由多名有经验的软件工程师分别做出估计。 • 每个人都估计程序的最小规模(a)、最大规模(b)和最可能的规模(m)， • 分别算出这3种规模的平均值、和之后，再用下式计算程序规模的估计值： • L=（a的平均值+4*m的平均值+b的平均值）/6 单位： LOC或KLOC。 代码行技术的优点： • 代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数； • 有大量参考文献和数据 。 代码行技术的缺点： • 源程序仅是软件配置的一个成分，由源程序度量软件规模不太合理； • 用不同语言实现同一个软件所需要的代码行数并不相同； • 不适用于非过程性语言。 • 2）任务分解技术 • 软件开发项目分解为若干个相对独立的任务，分别估计每个单独任务的成本： • 单独任务成本 = 任务所需人力估计值每人每月平均工资； • 软件开发项目总成本估计 = 各个单独任务成本估计值之和。 • 3）自动估计成本技术 采用自动估计成本的软件工具估计 第四章 v 1.了解需求的重要性及需求分析阶段的主要产物。 v 如果开发过程的早期没有检测到并修复需求错误，那么会造成很高的代价，甚至使项目失败。 v 产物：软件需求规格说明书 v v 2.需求的类型：功能需求、非功能需求或质量需求、设计约束、过程约束。 v 功能需求: 根据要求的活动描述需求行为 v 质量需求或非功能需求: 描述软件必须拥有的质量特征 v 设计约束: 已经做出的设计决策或对问题解决方案集的限制的设计决策 v 过程约束: 对用于构建系统的技术和资源的限制 v v 3. 两种需求文档：需求定义文档和需求规格说明书。 v 需求定义: 用户想要得到的每一件事情的完整列表。 v 描述打算构建的系统将要安装的环境中的实体 v 需求规格说明: 将需求重新陈述为关于要构建的系统将如何运转的规格说明 v v 4. 需求规格说明书的主要内容。 v 详细描述输入和输出 ，包括 v 输入的源 v 输出的目的地, v 有效范围 v 输入输出的数据格式 v 数据协议 v 窗口格式和组织 v 计时约束 v 根据接口的输入输出重新陈述要求的功能 v 对用户的质量需求，设计适配标准 v v v 5. 常用的需求建模表示方法：ER图、事件跟踪、状态机、Petri网、数据流图、用例图和原型法。 v ER图： v 一种表示概念模型的流行图形表示法 v 三个核心结构 v 实体: 表示为矩形，代表具有共同性质和行为的现实世界对象构成的集合 v 关系: 表示为两个实体之间的边，边中间有一个菱形，表示关系的类型 属性: 是实体的注释，描述实体相关的数据或性质 事件跟踪： • 关于现实世界实体之间交换的时间序列的图形描述 – 垂直线: 不同实体的时间线，其名字出现在线的顶部 – 水平线: 两个实体之间的一个事件或交互 – 时间按从顶到下跟踪进展 • 每一个图描述一个跟踪，表示只是若干个可能行为中的一个 • 事件跟踪语义相对简单，易于理解 状态机： • 是一种图形描述，描述了系统与其环境之间的所有对话 – 点(状态) 表示存在于事件发生之间的一个稳定的条件集合 – 边(转移) 表示由于一个事件的发生而产生的行为或条件的变化 • 在表示动态行为方面，以及在描述在响应已经发生的历史事件时行为将如何变化方面很有用 Petri网: • Petri 网是状态-转移表示法的一种形式，用于建模并发活动以及他们之间的交互。 • 圆圈：位置 • 条：变迁 • 弧：箭头 • 点：令牌 数据流图: • 数据流图 (DFD) 建模功能以及从一个功能到另一个功能数据流 – 一个泡泡表示： 一个 加工 – 箭头表示： 数据流 – 平行线：数据存储: 正式的库或信息库 – 矩形：表示参与者: 提供输入数据或接受输出的实体 用例图: • 构成 – 大的方框: 系统边界 – 方框外的小人: 参与者，人或者系统 – 方框内的椭圆: 用例，表示必须的主要功能及其变种 – 参与者和用例之间的线: 参与者参与了该用例 • 用例不一定建模系统应该提供的所有任务，而是用于说明用户对重要系统行为的观察 v 6. v （1）UML的作用：是为软件系统的制品进行描述（specifying）、可视化（visualizing）、构造（constructing）、文档化（documenting）的一种语言。 v v （2）UML中的4＋1视图：用例视图，设计视图，进程视图，实现视图， 分布视图。 v v （3）UML中的三种扩展机制 构造型Stereotype,标记值 tagged value,约束 contraint. v （4）UML中所包含的10种图形及各自的作用。 v v （5）用例图的作用。 v 用例图用来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用户提供的功能。 v 用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。 v v （6）用例图的主要构成部分。 v 执行者、系统边界和用例 第五章 5.获取需求 • 概念设计：告诉客户系统将做什么 数据来自哪里?系统中数据会发生什么情况?对用户来说，系统将会是什么?向用户提供的选择是什么?事件的计时是什么?报表和屏幕是什么样的?） • 技术设计：告诉变成这系统将做什么 对主要硬件部分及其功能的描述 软件构件的层次和功能 数据结构 数据流 好设计的衡量：耦合和内聚 耦合度： • 高度耦合：当两个构件之间有大量依赖关系的时候 • 松散耦合：当两个构件具有某种程度的依赖，但他们之间的相互连接比较弱 • 非耦合：构件之间不存在相互连接 耦合度的类型： • 内容耦合：当一个构件修改了另一个构件的内部数据项时，或一个构件内的分支转移到另外一个构件中的时候，可能出现内容耦合 • 公共耦合：对公共数据的改变意味着需要通过反向跟踪所有访问过该数据的构件来评估该改变的影响 • 控制耦合 • 标记耦合 • 数据耦合 • 内聚：如果构件的所有元素都是直接面向执行同一个任务的并且必须的，那么该构件是内聚的 6.细述对象 1. OOM中的典型特征，其中特别是封装、继承和多态。 • 标识 • 抽象 • 分类 • 封装 • 继承 • 多态 • 持久性 • 对象的概念： 对象是指某个事物，大多对应于真实世界中的某个客观实体；但有些对象在真实世界中没有直接的对应物，是人们对某个事物的一种抽象描述。对象的基本特征可以归纳为对象的属性和行为两类。 类的概念： 类是指对一组具有相同特征的对象的抽象描述；任何对象都是某个类的实例。 类图的作用： 类图技术是OO方法的核心技术，应用非常广泛，其中类、对象以及它们之间的关系是最基本的建模元素。类模型和对象模型揭示了系统的结构。 2.了解类之间的各种关系：关联、依赖、继承或泛化、组合/聚合等。 v 关联用来表示来表示两个（或多个）类的对象之间的结构关系，它在代码中表现为一个类以属性的形式包含对另一个类的一个或多个对象的引用。 v 泛化关系：(继承关系)定义类和包之间的一般元素和特殊元素之间的分类关系。 v 继承(Inheritance): 泛化关系的一种实现机制 并非所有的泛化关系都适合用继承关系实现 v 聚合：是表示类和类之间的“整体－部分”关系，用空心菱形表示。聚合表示类之间的整体与部分的关系。聚合意味着一个类拥有但共享另一个类的对象 组合是聚合的一种特殊情形，用实心菱形表示。与聚合相比，它有两个特点： 1. 一个部分类最多只能属于一个整体类 2. 当整体类不存在时，部分类将同时被销毁。 3.了解类图的基本建模步骤。 v （1）寻找出需求中的名词(候选对象)。 v （2）合并含义相同的名词，排除范围以外的名词，并寻找隐含的名词。 v （3）去掉只能作为类属性的名词。 v （4）剩下的名词就是要找的分析类（候选类)。 v （5）根据常识、问题域、系统责任确定该类有那些属性。 v （6）补充该类动态属性，如状态、对象间联系（如聚合、关联）等属性。 v （7）从需求中的动词、功能或系统责任中寻找类的操作（候选操作）。 4. 接口和抽象类的定义及各自的特点。 v 抽象类是指那些不具有任何对象的类，其作用是为其他的类描述它们的公共属性和行为。通常，抽象类具有一组抽象操作。一个拥有至少一个抽象操作的类必定是一个抽象类。 v 接口是一组没有实现的操作的集合。接口只提供操作的声明，不提供任何相应的功能代码。具体的功能代码由使用该接口的类实现，这叫作实现关系。 一个类和一个接口不同：一个类可以有它形态的真实实例，然而一个接口必须至少有一个类来实现它。 5.交互图的分类：顺序图和协作图。这两种图形各自的优缺点。注意UML 2.0中协作图改称通信图。 序列图主要用来描述对象之间信息交换时的时间顺序，它强调的是消息发送的时间的先后顺序 而协作图则用来描述系统对象之间如何协作共同完成系统功能的要求。协作图描述对象之间消息的连接关系，侧重说明哪些对象之间有消息传递。与序列图相比，通过编号来看消息的执行顺序比较困难，但协作图中对象间灵活的空间布局可以更方便地展示动态连接关系等有用信息。 序列图和协作图都属于交互图,用来描述对象之间的动态关系。 序列图强调消息的时间顺序，协作图强调参与交互的对象的组织关系。 序列图和协作图在语义上是等价的，两者可以相互转换。 相同点： 1.它们都表现出了对象之间的交互信息。 2.两个图对象的绘制方式相同 不同点： 1.顺序图反映了对象之间交互的时间关系，而通信图反映了对象之间交互的空间关系。 2.顺序图用于展示特定的业务场景，而通信图用来展示详细的业务过程。 3.顺序图的对象在图形的顶部一字排开，而通信图对象的摆放位置在二维空间只要选择合适的位置即可。 4.通信图不能表现组合片段。 6. 状态图和活动图各自的作用。注意活动图中泳道的作用。 v 状态图：描述交互对对象内部的影响，交互图中的消息在这里变成外部事件对对象发出的命令，对象对这些命令的响应导致对象的状态发生变化。因此，从这个意义上说，状态图是顺序图的进一步细化，并且是对核心对象（选择核心对象的依据是看是否在多个交互图中有多个消息指向该对象）的细化。 v 活动图是一种特殊形式的状态机，用于对计算流程和工作流程建模. v 与交互图相比：活动图着重表现活动的控制流，描述在对象之间传递的操作；交互图着重表现的是对象到对象的控制流，描述在对象之间传递的消息 v 泳道是活动图里对其中的活动按照其职责上的关联进行的划分。泳道在活动图内是一系列的垂直的隔断（这也是泳道这个名字的由来） 7.组件图的作用以及组件与接口间的关系。 组件是系统的一个物理的和可替代的组成部分，该组成部分遵循并实现了一组给定的接口。组件属于实现视图 8. 部署图的作用。 用来描述软件产品在计算机硬件系统和网络上的 - 安装 - 分发（delivery ） - 分布（distribution ） 1. 主要的面向对象设计原则及各自的原理： 设计原则名称 简介 重要性 里氏替换原则LSP 任意父类可以出现的地方，子类也可以出现 开闭原则OCP 对扩展开发，对修改关闭 单一职责原则SRP 类的职责单一 依赖倒转原则DIP 针对抽象（或接口）编程，而不针对具体编程 接口隔离原则ISP 使用多个专门接口要优于使用单一的接口 组合聚合原则CRP 优先使用组合或聚合关系，不要过于使用继承关系 迪米特原则LoD 一个软件实体对其他实体的引用越少越好。 2. LSP中的子类型与继承的关系及区别。 软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的 特征： 对于扩展是开放的（Open for extension）：模块的行为可以扩展，当应用的需求改变时，可以对模块进行扩展，以满足新的需求 对于更改是封闭的（Closed for modification）：对模块行为扩展时，不必改动模块的源代码或二进制代码 开闭原则的思想及关键。 OCP（The Open-Close Principle, 开放-封闭原则） 软件实体（类、模块、函数等）应该是可扩展的，但是不可修改的 特征： 对于扩展是开放的（Open for extension）：模块的行为可以扩展，当应用的需求改变时，可以对模块进行扩展，以满足新的需求 对于更改是封闭的（Closed for modification）：对模块行为扩展时，不必改动模块的源代码或二进制代码 4. 设计模式的分类。 创建型 结构型 行为型 5. 设计模式与面向对象设计原则之间的关系，特别是OCP原则。 6. 掌握各种工厂模式的设计思想及其原理，了解如何从OCP的角度进行分析。 //蓝色的字指的是ppt上没有的问题。黄色是了解内容 7.编写程序 1. 注意编程程序过程中应遵循一定的标准和过程。 对单个开发人员的标准 编写代码文档的方法 对其他开发人员的标准 集成人员, 维护人员, 测试人员 文档序言 对代码分析的自动化工具 设计和实现的匹配 低耦合, 高内聚, 定义明确的接口 2. 了解一些编程指导原则。 l 控制结构 使程序容易阅读 根据模块化的块来构建程序 不要让代码太过特殊，也不要太过普通 用参数名和注释来展现构件之间的耦合度 构件之间的关系必须是可见的 l 算法 重点关注: 性能 效率可能会伴随着一些隐藏的代价 编写更快代码的代价 测试代码的代价 用户理解代码的代价 修改代码的代价 l 数据结构 有几种使用数据结构的技术提出应该怎样对程序进行组织 保持程序简单 用数据结构来决定程序结构 l 保持程序简单 (continued) n 通用性指导原则 局部化输入和输出 包含伪代码 改正和重写，而不是打补丁 复用 生产者复用: 在设计的构建要在以后的应用中进行复用 消费者复用: 正在使用的构件是原先为其他项目开发的构件 3. 注意实现容错技术的主要手段是冗余，冗余通常分为四类:(1)结构冗余。 (2)信息冗余 (3)时间冗余和（4）冗余附加技术。 4.软件中的注释主要分：序言性注释和功能性注释两种。 8. 测试程序和9.测试系统 1. 测试的目标和衡量标准。 测试目标: 发现错误 只有当发现了错误时，测试才被认为是成功的 故障识别是确定由哪一个故障或哪些故障引起失效的过程 故障改正是修改系统使得故障得以去除过程 2. 测试的分类（或组织）。各种类型的测试的主要任务及所依赖的文档。 模块测试、构件测试、单元测试 集成测试 功能测试 性能测试 验收测试 安装测试 Alpha测试 Beta测试 3. 黑盒测试和白盒测试的思想，了解白盒测试中的基本路径测试等方法。 闭盒或黑盒: 测试对象的功能 开盒或白盒: 测试对象的结构 黑盒优点 免于受强加给测试对象内部结构和逻辑的约束 缺点 不可能总是进行完备的测试 4. 单元测试的主要内容。 检查代码 代码走查 代码审查 典型的审查准备时间和会议时间 错误发现率 证明代码的正确性 形式化证明技术 符号执行 自动定理证明 测试与证明 证明: 在假设环境下 测试: 实际操作环境下运转的相关信息 选择测试用例的步骤 确定测试目标 选择测试用例 定义测试 测试的完全性 语句测试 分支测试 路径测试 定义使用的路径测试 所有使用的测试 所有谓词使用/部分计算使用的测试 所有计算使用/部分谓词使用的测试 5. 集成测试的类型及主要的测试策略。 自底向上的测试 自顶向下测试 一次性测试 三明治测试 改进的自顶向下测试: 进行合并之前每一个层的构件进行单独测试 改进的三明治测试: 允许在将较上层的构件和其他构件合并前，先对这些较上层的构件进行测试 6. 了解测试计划的主要内容。 计划的目的 构建测试目标 设计测试用例 编写测试用例 测试测试用例 执行测试 评估测试结果 计划的内容 测试的目标是什么 怎样进行测试 用什么标准确定何时测试完成 7. 测试系统中的测试过程：功能测试、性能测试、验收（或确认）测试、安装测试，及它们的内容。 功能测试: 集成系统是否按照需求规格说明执行它的功能? 性能测试: 是否满足非功能需求? 验收测试: 系统是客户期望的吗？ 安装测试: 系统能在客户端运行吗 ? 11. 系统维护 1. 维护活动的类型：改正性、适应性、完善性、预防性。 2. 各种维护活动的主要内容和目标。 改正性: 维护对日常的系统功能的控制 适应性: 维护对系统修改的控制 完善性: 完善现有系统 预防性: 防止系统性能下降到不可接受的程度 3. 软件再生：文档重构、重组、逆向工程、再工程，以及它们各自的内容和含义。 文档重构: 对原代码进行静态分析，给出更多的信息 重组: 改变代码结构 逆向工程: 根据代码重新创建设计和规格说明信息 再工程: 对现有工程进行逆向工程，接着再改变规格说明和设计以完成逻辑模型 ；然后，根据修改的规格说明和设计生成新的系统 其他 1. 了解产品评估的几种方法：特征分析、调查、案例研究和正式的试验。 特征分析: 对属性进行评分和排列 调查: 记录数据 确定项目参与者对某一方法、工具或技术的反应是怎样的 确定趋势或关系 获取产品或项目的相关信息 记录构件规模、故障数目、花费的工作量 案例研究 确定可能影响活动的结果的关键因素，随后记录下它们 包括一系列步骤: 概念、设计、准备、执行、分发以及决策 将一种情形和另一种情形进行比较 正式试验 操纵自变量 用一些方法来减少偏见和消除混杂因素 通常测量一个活动的复制实例 实例具有代表性: 通过变量研究样本 2. 了解几种主要的产品质量模型：Boehm 的模型、ISO 9126和Dromey 的模型。 产品质量模型 Boehm 的质量模型 反映了对质量的一种理解 软件做了用户想要它做的事情 软件正确、有效地使用了计算机 软件易于用户学习和使用 软件是设计良好的、代码良好的，并且易于测试和维护 ISO 9126 质量模型 是一个层次结构的模型，具有6个影响质量的主要属性 每一个右边的特性都严格与左边的一个属性相联系 Dromey 质量模型 产品质量很大程度上由组成产品的构件、构件组成部分的实际性质决定的 正确的属性 内部属性 上下文性质 描述性性质 ISO 9126的6种属性 可复用性属性 机器无关性 可分离性 可配置性 过程成熟度属性包括 客户倾向 良好定义 保证 有效性 3. 了解常用的过程评估模型：CMM、SPICE、CMMI和ISO 9000等。 过程和能力成熟度 CMM ISO 9000 SPICE 4. 了解软件工程与计算机科学的关系。 软件工程即涉及计算机科学又涉及工程学 l 计算机科学 集中于数据、数据转换和算法 高级课程介绍特定领域的设计和编程技术 l 软件工程 集中于构建软件产品 考虑开发一个软件系统所涉及的所有活动（从初始想法到最终的产品） 设计概念往往集中于通用的设计原理、模式和标准 高级的课程介绍适应于大型的软件系统的设计和分析技术 1 第1部分：软件工程概论要求掌握： ●软件的概念，软件的本质特征是什么？ 软件：是相对硬件而言的，是计算机系统中的程序、数据，及其相关文档的总称。软件的本质是:对人的意识的反映 软件的特征:抽象性、智能性、无形性、依附性、复杂性、泛域性、非损性、复制性、演化性●软件工程概念 软件工程是采用工程概念、原理、技术和方法来指导计算机软件开发和维护的工程学科，该学科运用到计算机科学、数学、管理学等原理和方法，遵循系统化的思想，运用工程化方法，指导软件开发和维护工作。 ●软件工程提出的原因，软件危机的主要表现形式 答:因软件危机提出了软件工程 表现形式:◆软件开发不能按照计划进行控制和完成，普遍存在拖延工期的现象；◆软件开发生产率满足不了巨大的市场需要；◆开发出来的软件满足不了用户的需求；◆软件投资严重超出预算；◆软件可靠性和可用性差。 ●软件工程学科的发展过程，各阶段的时间范围，以及在每一个发展阶段突出的特征软件工程学科的发展可以粗略划分为四个时期：1.软件工程准备期：20世纪40年代中-60年代末 特征：程序是软件的核心内容；强调程序的艺术化和个性化；软件概念出现；软件危机出现。2.软件工程形成期：20世纪60年代末-80年代中 特征：软件工程概念出现；没有形成完整软件工程学科体系；以软件开发方法研究带动整个软件工程的发展,出现了典型的结构化方法,JSD方法等经典软件开发方法；程序设计方法深入研究:程序设计=算法+数据结构；数据结构,操作系统,数据库技术发展3.软件工程发展期：20世纪80年代末-90年代中 特征：软件需求旺盛,软件产业形成；微机、网络等技术出现并飞速发展；软件开发集成环境；面向对象方法开始受到重视；文件服务器模式，C/S模式出现。4.软件工程纵深期：20世纪90年代末-今天 特征：WWW技术出现并趋于成熟；软件体系结构；软件工程过程以UML为代表的软件建模语言和软件建模技术出现；云计算和物联网。 ●软件工程学科的基本内容，在什么时间提升为一级学科？ 答:内容:软件工程理论，软件工程技术，软件工程管理，软件服务工程,在2011年. ●软件生存期模型，都有哪些形式，每一种模型的特征及优缺点 答:1.瀑布模型：各阶段明确任务、自上而下、顺序固定、逐级过渡的结构模式，各阶段的联系就象瀑布流水一样自上而下、不可逆返。 特点：软件各阶段之间具有顺序性和依赖性的观点；问题放大效应的观点；推迟实现的观点；质量保障的观点 缺点：开发过程不允许往返，缺乏灵活性；在软件开发出来之前，用户无法知道软件的真实面目。2.演化模型 特点：针对事先不能完整地定义需求；针对用户的核心需求,开发核心系统；根据用户的反馈,实施活动的迭代。 优点：解决了瀑布模型不允许阶段返回的问题；适合不能及时确定需求的开发场景；缺点：每一个迭代期，仍然以瀑布模型为基础。3.增量模型 优点：每个阶段交付一个可用的产品；减少一个全新产品给客户带来的心理上的影响；分阶段地交 BAIDU_CLB_fillSlot( 920314 ); 2 付产品不需要大的资金支出；需求经常变化，增量模型的灵活性使其具有更加优越的适用性。 缺点：需要一个开放的结构，方便构件的加入；增量模型本身就是一个矛盾的名词。4.螺旋模型：分步推进、逐步深化的螺旋方式 优点：更符合人们的认知规律；容易确定某个软件产品何时测试完成。缺点：开发和维护的界限变得不十分清晰；仅适应于大型软件开发。5.喷泉模型 特点：软件生存期需要划分成为多个相对独立的阶段，但各个阶段之间的界限并不是十分明确，相邻阶段之间存在明显的重迭和交叉。6.智能模型 ●什么叫软件工程过程，国际标准化组织规定了有哪些过程？RUP的含义是什么？它有哪些典型特征？答：软件工程过程：是指软件在其生命周期中，一系列相关活动按照确定的次序演绎变化的进程. 包括：◆获取过程◆运作过程◆供应过程◆维护过程◆管理过程◆支持过程◆开发过程◆裁剪过程统一软件开发过程RUP 时间维:初始、细化、构建、移交4个阶段。 工作维：领域分析、需求分析、系统设计、实现和测试等核心工作。第2部分：软件建模技术概论要求掌握：●软件模型的概念 答：软件模型:是指通过软件建模语言，对软件的功能和性能等外特性，软件的要素和结构，以及软件的动态行为特性所给出的抽象和规范描述。●软件模型的基本内容 答：1）从软件反映的侧面看软件模型的内容：功能模型、对象模型、数据模型、过程、交互、状态、架构、界面。 2）从软件开发的工作看软件模型的内容：业务、需求、分析、测试、设计。●UML的中文含义是什么？ 答：统一建模语言（UnifiedModelingLanguage）●在2.0版本之后，UML共定义了哪些图？答： ●用例图、类图、活动图、顺序图、状态图的画法，这些图的作用是什么 答：1.用例图：用例图用来描述软件的功能，作用是：展现软件功能；展现软件使用者和软件之间的关系；展现软件功能相互之间的关系。 BAIDU_CLB_fillSlot( 920966 ); 3 2．类图：作用:描述一组类之间的关系。用于结构和静态建模. 3.活动图：作用:描述活动流过程。 4.顺序图：作用:描述一个交互，强调消息之间的时间顺序。 5.状态图：作用:描述一个模型要素所处的状态及其变化。 BAIDU_CLB_fillSlot( 920970 ); 4 第3部分：软件策划●软件为什么要进行策划？ 答：软件策划的含义：是在开发一个软件之初，所进行的谋划、打算和计划。 工作包括：提出软件开发的问题；定义和描述问题；可行性分析；软件规划；软件计划。●可行性分析的主要内容是什么？答：经济、技术、社会。●如何进行软件规划？ 答:软件的背景、环境及性质；软件的基本需求；软件的目标和范围；软件的框架和构成；软件建设的长期发展设想；软件开发的近期计划安排。●如何制定软件计划？ 答:1.软件项目总述:包括软件项目的名称、项目提出的背景、软件目标、软件的性质、范围、基本需求、基本环境、基础条件和时限要求等. 2.软件的工作任务:按工作阶段，工作任务把分解出来的具体任务列出来。3.软件的资源需求(1）人力资源： （2）环境资源：计算机及相关设备、网络、支撑软件、场地资金等其他资源 4进度计划 第4部分：软件需求分析要求掌握：●什么叫软件需求？ 答：需求是指明系统能为用户做什么，能够给用户解决什么问题的说明。它描述了系统能够给用户提供什么功能和服务，并且以怎样方式来完成这些功能和服务，以及的系统性质、行为和特性●软件需求的基本内容 答：总体需求；功能需求；非功能需求；环境性需求 5 ●结构化方法的基本思想，结构化方法用什么工具进行需求分析？答：模块化、自