《(完整word版)软工复习材料.doc》由会员分享，可在线阅读，更多相关《(完整word版)软工复习材料.doc（8页珍藏版）》请在金锄头文库上搜索。
1、软件工程复习材料2.1 软件工程&软件过程概述 什么是软件，软件的特点软件是在计算机系统支持下，能够完成特定功能和性能的程序、数据和相关的文档。（书本）软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据。（课件）软件=知识+程序+数据+文档（书本）软件=程序+规程+数据+文档（课件）软件的特点：软件是抽象的逻辑产品，而不是物理产品。灵活性和不会磨损和老化。1. 软件开发更依赖于开发人员的业务素质、智力、人员的组织、合作和管理。2. 软件存在潜伏错误，硬件错误一般能排除。3. 软件开发成后，只需对原版进行复制。4. 软件在使用过程中维护复杂：（1）纠错性维护-改
2、正运行期间发现的潜伏错误；(2)完善性维护-提高或完善软件的性能；（3）适应性维护-修改软件，以适应软硬件环境的变化；（4）预防性维护-改进软件未来的可维护性和可靠性。（5）软件不会磨损和老化。 什么是软件危机，软件危机的表现软件危机是指在软件开发和维护中所遇到的一系列严重的问题。软件危机的表现（1） 对软件开发成本和进度的估计常常很不准确。（2） 用户对已完成的软件不满意的现象时有发生。（3） 软件产品的质量往往是靠不住的。（4） 软件常常是不可维护的。（5） 软件通常没有适当的文档资料。 软件工程的定义、目标及原则定义是：1 将系统化的、规范化的、可
3、量化的的方法应用于软件的开发、运行和维护的过程；2对1中所述方法的研究目标：是在给定成本，进度的前提下，开发出满足用户或市场需求的高质量的软件产品。原则：抽象、信息隐藏、模块化、局部化、一致性、完全性和可验证性。 软件质量要素产品转移：可移植性、可重用性、互操作性产品运行：正确性、可靠性、效率、完整性、实用性产品校正：可维护性、灵活性、可测试性8个质量要素：（1）正确性（2）可用性（3）可靠性（4）有效性（5）可维护性（6） 可移植性（7）安全性（8）可复用性 人月神话(1)缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。(
4、2) 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。(3) 所有的编程人员都是乐观主义者：“一切都将运作良好”。(4) 由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。(5) 但是，我们的构思是有缺陷的，因此总会有 bug。(6) 我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。(7) 在若干人员中分解任务会引发额外的沟通工作量培训和相互沟通。(8) 关于进度安排，我的经验是为 1/ 3 计划、1/ 6 编码、1/ 4 构件测试以及 1/ 4 系统测试。(9) 作为一个学科，
5、我们缺乏数据估计。(10)因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。(11)Brook 法则：向进度落后的项目中增加人手，只会使进度更加落后。(12)向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。 瀑布模型、快速原型、增量模型、螺旋模型、通用软件过程模型等软件过程模型的特点、适用范围瀑布模型的特点：1.阶段间具有顺序性和依赖性2推迟实现的观点3.质量保证的观点瀑布模型的缺点：1.各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；2.开发过程中
6、很难响应客户的变更要求；3.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。瀑布模型的适用于：1.需求是预知的2软件实现方法是成熟的3项目周期较短4.在开发的早期阶段软件需求被完整确定。快速原型目的：尽早与用户见面，减少开发风险和需求不确定性。快速原型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识。原型是软件的一个早期可运行的版本，它反映了最终系统的部分重要特性。快速原型的缺点：1.原型系统的内部结构可能不好。2.开发人员需要掌握建立快速原型的开发技术和工具。快速原型的适用于：1.小型或中等规模的交互式系统。2.大型系统的某些部分，例如用户
7、界面 3.生命周期较短的系统。增量模型的特点：1.能在较短时间内向用户提交可完成部分工作的产品。 2.逐步增加产品功能可以使用户有效充裕的时间学习和适应新产品，从而减少一恶搞全新的软件可能给用户组织带来的冲击。增量模型的优点：1.整个产品被分解成若干个构件逐步交付，用户可以不断地看到所开发软件的可运行中间版本。2.将早期增量作为原型有助于明确后期增量的需求3.降低开发风险4.重要功能被首先交付，从而使其得到最多的测试。增量模型的缺点：1.需要软件具备开发式的体系结构；2.需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难。3.容易退化为边改方式，使软件
8、过程的控制失去整体性。螺旋模型的优点：1.关注软件的重用；2.关注早期错误的消除3.将质量目标放在首位。4.边学习、边建模、边开发、边使用、边开进。螺旋模型的缺点：1.风险分析需要成本，影响收益，所以只适用于大规模软件项目； 2.客户未必能接受，所以往往适应于内部的大规模软件开发； 3.需要风险评估的经验，否则会带来更大风险。通用软件过程模型形式化方法模型是采用形式化的数学方法将系统描述转化成可执行的程序。形式化适用：特别适合于那些对安全性、可靠性和保密性要求极高的软件系统，这些系统需要在投入运行前进行验证。形式化优点:由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少
9、的缺陷和较高的安全性形式化缺点：1.开发人员需要具备一定技能并经过特殊训练 2.形式化描述和转换是一项费时费力的工作3.现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述。 任务思维与过程思维思维过程包括分析、综合、比较、抽象、概括判断和推理等基本过程。 RUP 软件过程的基本特点、阶段划分、主要工作流RUP阶段划分：1.初始阶段 2.细化阶段 3.构造阶段 4.移交阶段 5.生产阶段主要工作流1.业务建模工作流 2.需求工作流 3.设计工作流 4.实现工作流5.验证和确认（V&V）工作流 6.部署工作流7.配置和变更管理工作流
10、8.项目管理工作流 9.环境工作流2.2 SA&OO结构化分析方法的特点、数据流图作用 对象、类、接口、封装、继承、多态、消息、关联、组合、聚合、依赖、实现对象是现实世界中个体或事物的抽象标识，是其属性和相关操作的封装。类是某些对象的共同特征（属性和操作）的标识。继承，类之间的继承关系是现实世界中遗传关系的直接模拟，它表示类之间的内在联系以及对属性和操作的共享，即子类可以沿用父类（被继承类）的某些特征。聚合部分与整体的关系。多态是指在父类及其子类中，对外接口的定义形式相同，却可以对应多种接口的实现形态。消息传递是对象与其外部世界相互关联的唯一途径。 概念
11、、用途、画法：用例图、类图、对象图、状态图、活动图、顺序图、协作图 类的关系、用例的关系类的关系常见的关系有：继承（Inheritance），关联关系（Association），聚合关系（Aggregation），复合关系（Composition），依赖关系（Dependency）。用例的关系:包含关系:基本用例的行为包含了另一个用例的行为。2.3 需求工程业务需求、用户需求、功能需求和非功能需求、系统需求 的基本概念业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。就是说你做的东西，用户能做什么，对用户有什么帮助，他的价值用户需求：是从用户角度描述的系统功能需
12、求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。用户需求的描述原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式（用例图、用例描述、活动图、领域概念模型）进行描述。问题：自然语言表达容易含糊和不准确。系统需求：是更加详细地描述系统应该做什么，通常包括许多不同的分析模型。（用例图、交互图、分析类图、状态图） 。系统需求主要是面向开发人员进行描述，是开发人员进行软件设计的基础。功能需求：描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。非功能需求：从各个角度对系统的约束和限制，反映了应用对软
13、件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。举例：（1）系统应在20秒之内响应所有的请求。（2）系统每周7天、每天24小时都可以使用。（3）对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。 需求工程的过程模型，每个环节的主要任务（1）需求工程策划（2）需求获取（3）需求分析（4）需求规范化（5）需求验证（6）总结 需求获取的过程模型，每个环节的主要任务（1）定义软件问题 （2）创建框架用例 （3）精化用例 （4）评审用例模型 主要项目干系人的角色及作用 需求
14、调研的常见方法、优缺点、注意事项 什么是用例，正确识别 Actor 及用例，用例识别的误区用例描述了一个完整的系统事件流程，其重点在于参与者与系统之间的交互而不是内在的系统活动，并对参与者产生有价值的可观测结果。用例分析以参与者为中心，用例粒度以完成参与者目的为依据。 框架用例的作用业务用例：业务建模阶段，每个用例以能说明一件完整的事情，可以描述一项完整的业务流程。概念用例：概念建模阶段，每个用例一能描述一个完整的事件流为宜，可以描述一项完整业务中的一个步骤。系统用例：系统建模阶段，每个用例以能够描述操作者与计算机的一次完整交互为宜。一个系统的业务用例定
15、义在多于10个，不超过30个之间。在同一个需求阶段，所有用例的粒度应该是同一量级的。粒度选择的问题本质上是因为边界认定不同而产生的。构建完整用例的步骤（1）重新研究用例名称、用例目标、标识所有执行者（2）标识触发条件和前置条件（3）描述或精化原有的基本交互动作序列（4）提炼并描述扩展的交互动作序列（5）描述用户与系统交互过程中传递的信息项（6）标识后置条件 可行性分析的主要关注点 需求分析的过程模型, 每个环节的主要任务(1)需求优先级分析为每项需求确定优先级（功能性需求，非功能需求）安排待分析用例的优先次序据此编排调整软件开发计划对重要、紧迫的需求（给予更多关注，分配更多的开发资源，确保其优先实现，确保实现质量）(2)用例分析不断加深理解用例模型，更深入理解软件需求用更精确uml语言表述需求（删除需求的模糊性，检查需求的一致性，消除需求的冗余性）引入用例功能的逻辑设计方案（检查需求的可实现性，识别需求的实现风险，提高需求的可验证性）(3)构建快速原型纠结的问题（自然语言可能存在的模糊性、不一致性。UML语言用户理解可能有难度，用户说不出心中所想，开发人员解释不清系统模样）(4)分析模型评审评审用例模型（正确性、完全
