软件工程重点复习

第一章 软件工程概述

1.1什么是软件？

软件是计算机系统中与硬件相互依存的另一部分，它是包括程序、数据及其相关文档的完整集合。

其中： 程序是按事先设计的功能和性能要求执行的指令序列

数据是使程序能正常操纵信息的数据结构 文档是与程序开发、

维护和使用有关的图文材料

1.2软件的特点

软件是一种逻辑实体，而不是具体的物理实体： 它具有抽象性

软件的生产与硬件不同 ：在它的开发中没有明显的制造过程

                                        对软件的质量控制，必须着重在软件开发方面下功夫

软件在运行和使用期间也与硬件不同 ：没有机械磨损、老化问题

硬件磨损 ：可以用备用零件替换

软件出故障 ：无法用备用零件替换来解决 是因为设计开发过程中存在错误

软件维护比硬件维护更复杂，它与硬件的维修有本质差别：虽然软件不存在磨损与老化，但它存在退化问题。软件退化缘于修改。

2.1软件危机

在程序系统阶段，软件技术的发展不能满足需要，“软件危机”就这样出现了。

软件危机是指：在计算机软件的开发和维护过程中所遇到的一系列严重问题。

几乎所有软件都不同程度地存在这些问题。 大体上，这些问题分为两方面：

如何开发软件，以满足对软件日益增长的需求；

如何维护数量不断膨胀的已有软件。

2.2软件危机的主要表现

对软件开发成本和进度的估计常常很不准确；

用户对“已完成的”软件系统不满意的现象经常发生；

软件产品的质量往往靠不住； 软件常常是不可维护的；

软件通常没有适当的文档资料；

软件成本在计算机系统总成本中所占的比例逐年上升；

软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

2.3产生软件危机的原因

一方面是由于软件本身的特点： 软件的逻辑性 ，程序的复杂性、规模庞大

另一方面是由于软件开发与维护的方法不正确：

忽视软件需求分析的重要性

认为软件开发就是写程序并设法使之运行

轻视软件维护

2.4软件神话-错误认知

管理者：

我们已经有了关于建造软件的标准和规程的书籍，难道它们不能给人们提供所有其需要知道的信息吗？

我们已经有了很多很好的软件开发工具，而且，我们为它们购买了最新的计算机。

如果我们已经落后于计划，可以增加更多的程序员来赶上进度。

用户：

 有了对目标的一般描述就可以开始写程序了—我们可以以后再补充细节。

项目需求总是在不断变化，但这些变化能够很容易的满足，因为软件是灵活的。

开发者:

一旦我们写出了程序并使其正常运行，我们的工作就结束了。

在程序真正运行之前，没有办法评估其质量。

一个成功项目唯一应该提交的就是运行程序。

3.1软件工程定义

软件工程学科涉及到为高效率地构建满足客户需求的软件系统所需的理论、知识和实践的应用。（中国计算机科学与技术学科教程2002）

软件工程是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

3.2软件工程的本质特性

软件工程关注大型程序的构造（规模）

软件工程的中心课题是控制复杂性 ：复杂性的来源：规模、不确定性、认知困境

软件经常变化

开发软件的效率非常重要

和谐地合作是开发软件的关键

软件必须有效地支持它的用户（价值）

软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品（两个空间）

3.3软件工程的基本原理

著名的软件工程专家B．W．Boehm于1983年提出了软件工程的七条基本原理（最小集合）：

用分阶段的生命周期计划严格管理 ：

把软件生命周期划分成若干阶段，并相应制定出切实可行的计划 严格按照计划对软件的开发与维护工作进行管理

坚持进行阶段评审 ：

大部分错误是在编码之前造成的 例如，根据Boehm等人的统计，设计错误占软件错误的63％，编码错误仅占37％ 错误发现与改正得越晚，所需付出的代价也越高

实行严格的产品控制：

当改变需求时，为了保持软件各个配置成分的一致性，必须实行严格的产品控制，其中主要是实行基准配置管理

所谓基准配置又称为基线配置 它们是经过阶段评审后的软件配置成分(各个阶段产生的文档或程序代码)

基准配置管理也称为变动控制 一切有关修改软件的建议，特别是涉及到对基准配置的修改建议，都必须按照严格的规程进行评审，获得批准以后才能实施修改

采用现代程序设计技术：

实践表明，采用先进的技术既可提高软件开发和维护的效率，又可提高软件产品的质量

结果应能清楚地审查 ：

为了提高软件开发过程的可见性，更好地进行管理，应        该根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，从而使得所得到的结果能够清楚地审查

开发小组的成员应该少而精 ：

开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素

承认不断改进软件工程实践的必要性 ：

要积极主动地采纳新的软件技术 要注意不断总结经验，评价新的软件技术的效果，指明必须着重开发的软件工具和应该优先研究的技术

3.4软件工程方法学包含三个要素： 方法 工具 过程

方法：完成软件开发的各项任务的技术方法，回答“怎样做”的问题

工具：软件工具为软件工程方法提供了自动或半自动的软件支撑环境 如果这些工具能够集成起来，即一个工具产生的信息可被另一个工具使用时，称这样的支持软件开发的系统为CASE（计算机辅助软件工程）

过程：是指为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的步骤，将软件工程的方法和工具综合起来以达到合理、及时地进行软件开发的目的。它定义了： 方法使用的顺序 要求交付的文档资料 为保证质量和适应变化所需要的管理 软件开发各个阶段完成的里程碑

经典方法学：传统方法学和面向对象方法学

3.5传统方法学（又称过程式方法学、生命周期方法学或结构化范型）

采用结构化技术（结构化分析、结构化设计和结构化实现）

把软件生命周期的全过程划分为若干个阶段（严格标准，每个阶段结束之前都必须进行正式严格的技术审查和管理复审）

存在问题：根源： 把原本密切相关的数据和操作人为地分离成了两个独立的部分，增加了软件开发与维护的难度

3.6面向对象方法学（以数据为主线，把数据和对数据的操作紧密地结合起来的方法）

四个要点：面向对象=对象+类+继承+通信

把对象作为融合了数据及在数据上的操作行为的统一的软件构件

把所有对象都划分成类

按照父类与子类的关系，把若干个相关类组成一个类层次结构，位于下层的类继承了上层中某类的特点

对象彼此间仅能通过发送消息互相联系

优点：

降低了软件产品的复杂性； 提高了软件的可理解性 ；简化了软件的开发和维护工作； 促进了软件重用

4.1软件生命周期

概括地说，软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步划分成若干个阶段。

软件定义时期：

问题定义阶段：界定问题的范围，确切地定义问题；

可行性研究阶段：研究问题的范围，探索这个问题是否值得去解，是否有可行的解决办法；

需求分析阶段：确定目标系统必须具备哪些功能； 另外，要估计完成该项工程所需要的资源和成本，制定工程进度表。

软件开发时期(具体设计和实现在前一个时期定义的软件);

总体设计阶段：设计出实现目标系统的几种可能的方案，权衡利弊推荐一最佳方案，并制定实现最佳方案的详细计划，以及设计软件的体系结构；

详细设计阶段：设计出程序的详细规格说明； 编码和单元测试阶段：写出正确的、容易理解、容易维护的程序模块；

综合测试阶段：通过各种类型的测试使软件达到预定的要求。

运行维护时期：

改正性维护：诊断和改正使用过程中发现的软件错误

适应性维护：修改软件以适应环境的变化

完善性维护：根据用户需要改进或扩充软件使之更完善

预防性维护：修改软件从而为将来的维护活动做好准备

第二章 软件过程

1.1软件过程： 为建造高质量软件所需完成的任务的框架，它规定了完成各项任务的工作步骤

区分于软件工程：软件工程方法学包含三个要素： 方法 工具 （软件）过程

软件工程实践应该是由有创造力、有知识的人在定义好的、成熟的软件过程中进行的，该过程适合于他们建造的产品和他们的市场需要

软件过程定义了软件开发中采用的方法，但软件工程还包含该过程中应用的其他技术和工具

区分于软件生命周期：

软件过程与软件生命周期的关系： 软件过程是在软件生命周期中所实施的一系列活动的集合

软件生命周期与选择的软件过程有关，不同的软件过程可能对应不同的软件生命周期

2.经典软件过程模型

2.1瀑布模型（成功之处在于是一种文档驱动的模型）

特点：

阶段间具有顺序性和依赖性

推迟实现的观点：清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现

质量保证的观点：每个阶段交文档，且对其评审

优点：

可强迫开发人员采用规范的方法（例如，结构化技术）

严格地规定了每个阶段必须提交的文档

要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证

缺点：

要求不实践就提出准确需求不实际

静态规格声明难以正确认识动态的软件产品

非线性过程人为线性化，不符合实际

可运行版本得到晚，有错误代价大

这可能导致最终开发出的软件产品不能真正满足用户的需要

2.2V模型（以活动驱动）

本质是把瀑布模型中一些隐含的迭代过程明确出来 使开发活动和验证活动的相关性更加明显

模型使抽象等级的概念也更明显：

和瀑布模型一样，都是对软件开发过程过份简单、理想化的抽象，对需求变化的适应性差。

2.3原型/快速原型模型

定义：所谓原型，是一个可以实际运行的模型，它在功能上可以看作是最终产品的一个子集（展示了目标系统的关键功能）。

优势：

 快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的。原因如下 ：原型系统已经通过与用户交互而得到验证 开发人员通过建立原型系统已经学到了许多东西

利用原型能统一客户和开发人员对软件项目需求的理解，有助于需求的定义和确认

可以考虑结合瀑布模型，二者互补性强 用快速原型做为需求分析的一种技术，用于收集客户的真实需求，然后把客户满意了的原型再作为瀑布模型的输入，从而达到优势互补。 

注意：

客户：不可把原型当作软件的正式运行版本

开发人员：同上，还必须牢记原型中没有考虑质量因素的部分

使用前要与用户达成一致：原型只是模型而已

2.4阶段式开发（演化模型）

阶段式开发大体分为两种：

渐增式开发：第一个增量构件往往实现软件的基本需求，提供最核心的功能

优点：（工作人员少+风险小+短时间能使用+便于用户适应）

适用于人员配备不充裕、不能在软件项目期限之前实现一个完全版本的软件的情况

能有计划地管理技术风险

每个增量都发布了一个高质量的可操作的版本，用户能在较短时间内使用上部分功能

逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品 减少一个全新的软件可能给客户带来的冲击

难点：（无缝集成，不破坏原有，困难+结构得开放，设计难+矛盾，又要整体又要独立）

迭代式开发（螺旋式开发）：使用原型及其他方法来尽量降低风险

看作在每个阶段之前都增加了风险分析过程的快速原型模型

四个任务螺旋上升：

制定计划──确定软件目标，选定实施方案，弄清项目开发的限制；

风险分析──分析所选方案，考虑如何识别和消除风险；

实施工程──实施软件开发；

客户评估──评价开发工作，提出修正建议，并计划下一个阶段的任务；

优点：（质量好+测试确定性增强+重视维护）

引入了风险分析和客户评审

缺点：（更适用内部开发+大型软件项目+风险分析能力要求高）

主要适合内部开发 否则风险分析必须在签订合同前完成 或者争取客户的最大理解

只适合大型软件项目的开发 否则，每个阶段的风险分析将占用很大一部分资源，增加成本

对开发人员的风险分析能力是极大的考验 否则，模型将退化到瀑布模型，甚至更糟

2.5螺旋模型（上面）

2.6喷泉模型（长得和黄菠萝路上那个高喷泉一样）

3.现代软件过程模型

3.1RUP软件过程模型

以用例驱动、架构为中心、迭代和增量式开发为核心思想，适用于复杂软件系统的开发。

过程框架、详细规范性过程模型 ：

    元过程（Meta Process）

    必须定制化才能使用

软件工程知识库：

    基本上涵盖了软件开发的所有活动

    为面向对象设计和开发提供了定义明确的结构 基于面向对象方法和UML（统一建模语言）

RUP之中的设计和文档记录都使用UML ：

    文档充分，量很足（重量级过程）

RUP六项最佳实践：

1.迭代式开发 :容纳需求变更/减少风险

先解决关键风险 ；初始迭代支持早期用户反馈 ；持续测试集成 ；目标里程碑； 评估实施情况确定进度；可以部分部署

次迭代都是风险驱动的：

    性能风险； 集成风险（不同的供应商、工具等）； 概念风险（找出分析和设计中的缺陷）

执行一个“迷你瀑布式”项目 ：

    以交付切实可行的代码结束，供相关方审查 单次迭代的结果是一个增量

迭代的生命周期：一个迷你小瀑布

2.管理需求 :使用用例和脚本

用例图捕捉业务需求

3.基于构件的架构

预先设计的体系结构，定义良好的接口

4.可视化建模

结构和行为的组合，一致性

5.（持续）验证质量 :质量评估内建在贯穿于整个开发过程的、由全体成员参与的所有活动中

为每个关键场景创建测试，以确保所有需求都得到正确实现

不可接受的应用程序性能和不可接受的可靠性一样有害

验证软件可靠性-内存泄漏、瓶颈

每次迭代都要测试-使用自动化测试！

6.变更控制管理

控制、跟踪和监控变更以支持迭代开发，安全工作区（隔离），为集成和构建管理做自动化

RUP软件开发生命周期

4大阶段：

Inception（初始） 建立业务模型，定义最终产品视图（目标），确定项目的范围

主要里程碑：生命周期目标

Elaboration（精化/细化） 设计并确定系统的体系结构，制定项目计划，确定资源需求

主要里程碑：生命周期体系结构

Construction（构建） 开发所有构件和程序，集成为客户需要的产品，测试所有功能！需要资源最多

主要里程碑：初始操作能力

Transition（转移/交付/产品化） 把开发出的产品提交给用户使用

主要里程碑：产品发布

9个 核心工作流

工程工作流（6）：

1.业务建模->定义目标组织的业务过程、角色等（使用商业用例/对象）

2.需求->描述系统应做什么，与用户达成共识，明确问题描述和系统边界

3分析与设计->导出目标系统的设计，开发健壮的架构并使之与环境匹配，优化其性能

4.实现->子系统分层结构对应代码结构，以组件的形式(源文件、二进制文件、可执行文件)实现类和对象，组件单元测试、子系统集成为可执行系统

5.测试->验证对象交互、组件的正确集成，验证并确认需求已被正确实现，识别并确认缺陷，确保在部署之前将缺陷解决

6.部署->生成目标系统的可运行版本，移交给用户

支持工作流（3）：

7.配置与变更管理->跟踪维护开发过程中Artifacts的完整性和一致性

8.项目管理->提供项目管理框架，为软件开发项目制定计划、人员配备、执行和监控等方面的使用.准则，并为风险管理提供框架

9.环境提供->软件开发环境，包括过程管理和工具支持

注意：

RUP中的每个阶段都可以进一步分解为几次迭代， 一次迭代是一个完整的开发循环，产出可执行产品的一个内部或外部发布

一次迭代中，有可能经历所有工作流

3.2敏捷过程

原则：

1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

2.即使到了开发的后期,也欢迎改变需求 敏捷过程利用变化来为客户创造竞争优势

3.经常性地交付可以工作的软件 交付的间隔可以从几周到几个月，交付的时间间隔越短越好

4.在整个项目开发期间，业务人员和开发人员必须天天都在一起工作

5.围绕被激励起来的个人来构建项目 ：给他们提供所需要的环境和支持，并且信任他们能够完成工作

6.在团队内部,最具有效果并且富有效率的传递信息的方法,就是面对面的交谈

7.工作的软件是首要的进度度量标准

8.敏捷过程提倡可持续的开发速度 ：责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度

9.不断地关注优秀的技能和好的设计会增强敏捷能力

10.简单是根本的

11.最好的架构、需求和设计出自于自组织的团队

12.每隔一段时间，团队就会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整

最常用的工作方法：

SCRUM（54%）

极限编程（XP):广泛应用于需求模糊且经常改变的场合

      特点：对变化和不确定性反应更快速，更敏捷 ；快速的同时保持可持续的开发速度

      有效实践：

       客户作为开发团队的成员

       使用用户素材 短交付周期（每两周完成一次迭代）

       验收测试 结对编程 测试驱动的开发（TDD, Test Driven Dev.）

       集体所有（程序代码属于整个开发小组，每个成员都有修改代码的权利，都对全部代码负责）

       持续集成（一日内多次集成，不断回归测试） 

       可持续的开发速度（周工作时间不超过40小时，连续加班不超过两周）

       开放的工作空间 及时调整计划

       重构

       使用隐喻（隐喻是把整个系统联系在一起的全局视图，描述系统如何运做，如何把新功能加入                     到系统中）

3.3微软过程模型

微软团队模型的最佳实践：

小型（≤10人）专业化团队

同一地点工作，方便内部交流

要求客户加入团队 所有重要活动必须全体参加、全体知情

对于复杂项目，“程序管理”角色分解为“项目管理”和“系统架构师”