《软件工程》第二章学习笔记

1. 软件过程模型
   软件过程模型又叫做软件开发模型、软件生存期模型，是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。常见的软件过程模型有瀑布模型、增量模型、原型模型、螺旋模型、RUP和敏捷开发等。是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。
   瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。
2. 瀑布模型
   （1） 瀑布模型的产生背景
   1970年温斯顿?罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
   （2） 瀑布模型的基本策略
   瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
   （3） 瀑布模型的适用范围及特点
   瀑布模型具有顺序性和依赖性：前结束，后开始；前输出，后输入。
   瀑布模型具有推迟实现的观点：前阶段工作必须做扎实，方可展开后续工作。
   瀑布模型具有质量保证的观点：必须完成规定文档；必须对完成的文档进行评审，以便尽早发现问题。
   （4） 瀑布模型的局限性
   由于各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
   由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。此外，瀑布模型通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
   瀑布模型的突出缺点是不适应用户需求的变化，且最终才能见到可执行系统，风险较高。
3. 增量模型
   （1）增量模型简介
   增量模型又称为渐增模型，也称为有计划的产品改进模型，它从一组给定的需求开始，通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求，下一个版本纳入更多的需求，依此类推，直到系统完成。每个中间版本都要执行必需的过程、活动和任务。
   （2）增量模型的基本策略
   增量模型是瀑布模型和原型进化模型的综合，它对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中，则将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用。
   如同原型进化模型一样，增量模型逐步地向用户交付软件产品，但不同于原型进化模型的是，增量模型在开发过程中所交付的不是完整的新版软件，而只是新增加的构件。
   （3）增量模型的适用范围及特点
   增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点，增量模型具有以下优点。
   ①将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
   ②以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
   ③开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
   增量模型适用于具有以下特征的软件开发项目：
   ① 软件产品可以分批次地进行交付。
   ② 待开发的软件系统能够被模块化。
   ③ 软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。
   ④ 项目管理人员把握全局的水平较高。
   （4）增量模型的局限性
   增量模型的缺点是要求待开发的软件系统可以被模块化，其系统体系结构必须最先确定，并在增量式开发中保持稳定。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。
4. 原型模型
   （1）原型模型简介
   80年代后，随着计算机辅助设计的应用，产品造型和设计能力得到极大提高，然而在产品设计完成后，批量生产前，必须制出样品以表达设计构想，快速获取产品设计的反馈信息，并对产品设计的可行性作出评估、论证。在市场竞争日趋激烈的今天，时间就是效益。为了提高产品市场竞争力，从产品开发到批量投产的整个过程都迫切要求降低成本和提高速度。原型模型的出现，为这一问题的解决提供了有效途径，倍受国内外重视。
   （2）原型模型的基本策略
   原型模型又称快速原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。例如，客户需要一个ATM机软件，可以先设计一个仅包含刷卡、密码检测、数据输入和账单打印的原型软件提供给客户，此时还不包括 络处理与数据库存取以及数据应急、故障处理等服务。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
   （3）原型模型的适用范围及特点
   通过快速开发工具短时间构造出可运行“样品”。
   通过运行原型可更好解决开发中的不确定性因素。
   需求工程阶段有助于启发和验证系统需求，软件设计阶段有助于探索和验证设计方案。
   原型最终结局：被抛弃；作为最终产品发布。
   （4）原型模型的局限性
   原型的快速开发往往忽略了非功能方面的因素，如性能、健壮性和可靠性等；
   缺乏必要的开发文档，不利于后期维护。
5. 螺旋模型
   （1）螺旋模型产生背景
   1988年，巴利?玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
   （2）螺旋模型的基本策略
   原型模型又称快速原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。例如，客户需要一个ATM机软件，可以先设计一个仅包含刷卡、密码检测、数据输入和账单打印的原型软件提供给客户，此时还不包括 络处理与数据库存取以及数据应急、故障处理等服务。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
   （3）螺旋模型的适用范围及特点
   螺旋模型将风险分析与处理引入到软件开发中，有助于降低软件的开发风险， 适合于大型软件开发。其设计上的灵活性,可以在项目的各个阶段进行变更，以小的分段来构建大型系统,使成本计算变得简单容易。客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性。随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互，客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
   （4）螺旋模型的局限性
   螺旋模型强调风险分析，并做出相关反应是不容易的。往往仅适应于内部的大规模软件开发。
   软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则将会带来更大的风险。
6. RUP
   （1）RUP产生背景
   软件统一过程（RUP）是Rational软件公司（Rational公司被IBM并购）创造的软件工程方法。RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。
   （2）RUP的基本策略
   RUP包含6个过程工作流(Process Workflow)和3个支持工作流(Supporting Workflow)。
   1. 商业建模(Business Modeling)： 对系统的商业环境和范围进行建模，确保所有参与人员对开发系统有共同的认识。
   2. 需求分析(Requirements)：定义系统功能及其他非功能需求，成果是软件需求说明书(SRS)。
   3. 分析与设计(Analysis and Design)：根据系统需求给出实现方案，成果为软件设计说明书(SDS)。
   4. 实施(Implementation)： 定义代码的组织结构、实现代码、单元测试、系统集成。
   5. 测试(Test) ： 验证各子系统的交互和集成。测试分别从可靠性、功能性和系统性能来进行。
   6. 部署(Deployment)： 成功的生成版本并将软件分发给最终用户
   7. 配置和变更管理(Configuration and Change Management)： 管理并行开发、分布式开发；自动化创建工程；记录产品修改原因、时间、人员、审计记录 。
   8. 项目管理(Project Management)： 为计划、执行和监控软件开发项目提供有效支持
   9. 环境(Environment)： 为组织提供过程管理和工具的支持
      （3）RUP的适用范围及特点
      RUP综合了多种软件开发过程的优点，全面考虑了软件开发过程的技术因素和管理因素。
   10. 面向对象： 从技术角度， RUP的软件系统开发是基于面向对象技术的。 RUP使用和支持面向对象，且建立的设计、实现模型均是对象模型。
   11. Use Case驱动： 系统开发从建立业务领域的用例模型开始。用例模型表达了系统的需求，后面的各种工作围绕如何实现用例模型展开。
       3.以体系结构为中心： 系统开发过程中，体系结构用作开发的基石。系统的概念化、构造和管理均围绕系统的体系结构进行。
   12. 迭代式、增量式的开发过程： RUP采迭代式、增量式的思想，开发过程由一连迭代增量构成。
   13. 以质量控制和风险管理为目标： 质量控制贯穿于软件开发的全过程。在每一次迭代周期，都要进行质量评估；在软件项目立项之初，就尽可能识别项目的开发风险，找出避免、克服或减少风险的对策。
   14. 与UML配套： UML的概念和表示方法与RUP相结合形成一种高效的软件系统开发方法和技术。
   15. 适用性强： RUP可适用于各类型和各种规模的软件开发。 RUP采用管理与技术相结合的二维方法，特别适合处理需求变动比较大的高风险项目。
7. 敏捷开发
   （1）敏捷开发产生背景
   传统的开发方法有详细的项目规划，受控的过程管理和严格的质量保证，在规划、设计及文档编写方面投入巨大，仅适合大型、长寿命周期的软件开发，无法满足中小型软件的开发需要。
   敏捷开发（Agile Development）提出在20世纪90年代， 该方法以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发，从而让开发团队将主要精力集中在软件本身而不是在设计和编写文档上。
   敏捷开发适合系统需求在开发过程中快速变化的应用类型。
   （2）敏捷基本原则
   1. 尽早、持续的(几周到几个月)交付有价值的软件。
   2. 欢迎改变需求，保持客户的竞争优势。
   3. 业务人员全程参与开发过程。
   4. 最有效果的信息传达方式是面对面的交谈。
   5. 可以工作的软件是进度的主要度量标准。
   6. 敏捷过程提倡可持续开发。
   7. 不断追求卓越技术与良好设计有助于提高敏捷性。
   8. 简单——尽可能减少工作量的艺术至关重要。
   9. 最好的架构、需求和设计都源自自我组织的团队。

（3）敏捷项目管理
项目管理（Project Management, PM）是项目在预算范围内按期完成的关键。传统项目管理无法适用于敏捷开发灵活的项目开发管理需要。 Scrum是专注于迭代式软件开发管理的敏捷项目管理方法， 包含一系列的实践和预定义角色的过程框架。 确定产品目标
8. 极限编程
（1）极限编程简介
极限编程（Extreme Programming, XP; Kent Beck, 2000）为目前最流行的敏捷开发方法。该方法推行最佳工程实践，如迭代式开发、结对编程、 测试驱动开发等，致力于积极响应用户需求变化，并能高效率开发出高质量软件。 XP适合于小团队开发。
（2）极限编程的几个要素
工作环境、需求、简单设计、结对编程和测试。