【软件工程(一)】软件工程概述+软件生命周期模型

软件工程概述

软件的定义

IEEE定义：软件是计算机程序、规程以及运行计算机系统所需要的文档和数据。
Wirth中指出：
在结构化程序设计：程序＝算法＋数据结构
在软件工程中：软件＝程序＋文档。
另一种对软件的公认解释是：软件是包括程序、数据及其相关文档的完整集合。

软件的分类

• 根据软件服务对象的范围不同：
  • 通用软件：操作系统、数据库等；
  • 定制软件：企业ERP、办公自动化系统等；
• 根据软件完成功能所处的层次不同：
  • 应用软件、中间件软件、系统软件
• 系统软件：指能与硬件紧密配合在一起，使计算机系统各个部件、相关的软件和数据协调、高效地工作
  • 操作系统
  • 设备驱动程序
  • 数据库管理系统等

软件工程要素、目标和原则

软件工程三要素：方法、工具和过程。

• 方法：提供了“如何做”的技术
• 工具：提供了自动或半自动的软件支撑环境
• 过程：将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的

软件工程的目标可概括为：生产具有正确性、可用性以及开销适宜的软件产品。
软件工程的最终目的是摆脱手工生产软件的状况，逐步实现软件研制和维护的自动化。

软件工程知识体系知识域

软件生命周期模型

工程过程

• 工程项目有三个基本的目标：
  合理的进度；
  有限的经费；
  一定的质量；
• 美国质量管理专家戴明博士针对工程项目的质量目标，提出了PDCA循环，称为戴明环
  Plan, Do, Check, Action
  
  

传统模型种类

瀑布模型

瀑布模型为软件开发和软件维护提供了一种有效的管理模式，它在软件开发早期为消除非结构化软件、降低软件复杂度、促进软件开发工程化方面起着显著的作用

瀑布模型中的每一个开发活动具有下列特征：

• 本活动的工作对象来自于上一项活动的输出，这些输出一般是代表该阶段活动结束的里程碑式的文档。
• 根据本阶段的活动规程执行相应的任务。

优点	缺点
降低了软件开发的复杂程度，提高了软件开发过程的透明性及软件开发过程的可管理性。	模型缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
推迟了软件实现，强调在软件实现前必须进行分析和设计工作。	模型的风险控制能力较弱。
以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。	瀑布模型中的软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量；而且当管理人员以文档的完成情况来评估项目完成进度时，往往会产生错误的结论。

演化模型

• 使用瀑布模型人们认识到，由于需求很难调研充分，所以很难一次性开发成功。

• 演化模型提倡两次开发：

  • 第一次是试验开发，得到试验性的原型产品，其目标只是在于探索可行性，弄清软件需求；
  • 第二次在此基础上获得较为满意的软件产品。
  • 

• 演化模型的特点：

  • 优点：明确用户需求、提高系统质量、降低开发风险；
  • 缺点：
    • 难于管理、结构较差、技术不成熟；
    • 可能会抛弃瀑布模型的文档控制优点；
    • 可能会导致最后的软件系统的系统结构较差 ；

• 演化模型适用范围：

  • 需求不清楚；
  • 小型或中小型系统；
  • 开发周期短

增量模型

喷泉模型

• 喷泉模型也称迭代模型，认为软件开发过程的各个阶段是相互重叠和多次反复的，就像喷泉一样，水喷上去又可以落下来，既可以落在中间，又可以落到底部。
• 各个开发阶段没有特定的次序要求，完全可以并行进行，可以在某个开发阶段中随时补充其他任何开发阶段中遗漏的需求。
• 优点：
  提高开发效率
  缩短开发周期
• 缺点：难于管理

V模型和W模型

螺旋模型

构件组装模型

快速应用开发模型

原型方法

瀑布模型以及基于瀑布模型的软件生命周期模型，都需要精确的需求才能很好地执行后续的开发活动。
然而完整而准确的需求规格说明是很难一次性得到，因为：

• 在开发早期用户往往对系统只有一个模糊的想法，很难完全准确地表达对系统的全面要求
• 随着开发工作的推进，用户可能会产生新的要求
• 开发者又可能在设计与实现的过程中遇到一些没有预料到的实际困难，需要以改变需求来解脱困境

定义：

• 原型指模拟某种最终产品的原始模型；
• 原型方法指在获得一组基本需求后，通过快速分析构造出一个小型的软件系统原型，满足用户的基本要求。
• 用户通过使用原型系统，提出修改意见，从而减少用户与开发人员对系统需求的误解，使需求尽可能准确。
• 原型方法主要用于明确需求，但也可以用于软件开发的其他阶段。

种类：
废弃策略

• 探索型：弄清用户对目标系统的要求，确定所期望的特性；探讨多种实现方案的可行性。主要针对需求模糊、用户和开发者对项目开发都缺乏经验的情况。
• 实验型：用于大规模开发和实现之前，考核技术实现方案是否合适、分析和设计的规格说明是否可靠。

追加策略

• 进化型：在构造系统的过程中能够适应需求的变化，通过不断地改进原型，逐步将原型进化成最终的系统。它将原型方法的思想扩展到软件开发的全过程，适用于需求经常变动的软件项目。

优点：

原型提供了用户与开发人员良好的沟通手段，易于被人们接受：

• 原型方法有助于快速理解用户对于需求的真实想法 ；
• 可以容易地确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果 ；
• 软件原型的最终版本，有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，这样有利于建成最终系统。

原型法的适用范围和局限性：

• 大型系统如不经过系统分析得到系统的整体划分，而直接用原型来模拟是很困难的。
• 对于大量运算的、逻辑性较强的程序模块，原型方法很难构造出该模块的原型来供人评价。
• 对于原有应用的业务流程、信息流程混乱的情况，原型构造与使用有一定的困难。

原型方法存在的问题：

• 文档容易被忽略。
• 建立原型的许多工作会被浪费掉 。
• 项目难以规划和管理。

应用:

新型软件生命周期模型

RUP

• RUP（Rational Unified Process）是由Rational公司（现被IBM公司收购）开发的一种软件工程过程框架，是一个基于面向对象的程序开发方法论 。
• RUP既是一种软件生命周期模型，又是一种支持面向对象软件开发的工具，它将软件开发过程要素和软件工件要素整合在统一的框架中 。

敏捷及极限编程

• 敏捷建模（Agile Modeling，AM）是由Scott W. Ambler从许多的软件开发过程实践中归纳总结出来的一些敏捷建模价值观、原则和实践等组成的，它是快速软件开发的一种思想代表，具体的应用有极限编程、SCRUM、水晶、净室开发等。
• 2001年敏捷联盟成立，其主要特点就是具有快速及灵活的响应变更的能力。

RUP的四个主要阶段

RUP中的软件生命周期在时间上被分解为四个顺序的阶段：初始阶段（Inception）、细化阶段（Elaboration）、构造阶段（Construction）和交付阶段（Transition）。

每个阶段结束于一个主要的里程碑(Major Milestones)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

一.RUP 初始阶段

阶段目标是通过业务场景（business case）了解业务并确定项目的边界。包括项目的验收规范、风险评估、所需资源估计、阶段计划等。

• 要确定项目边界，需识别所有与系统交互的外部实体，主要包括识别外部角色（actor）、识别所有用例并详细描述一些重要的用例。
• Milestone：软件目标里程碑。包括一些重要的文档，如：项目愿景（vision）、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务场景等。
• 需要对这些文档进行评审，以确定正确理解用例需求、项目风险评估合理、阶段计划可行等。

二.RUP 细化阶段

阶段目标是分析问题领域，建立适合需求的软件体系结构基础，编制项目计划，完成项目中技术要求高、风险大的关键需求的开发。
Milestone：体系结构里程碑。

• 包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。

通过评审确定软件体系结构的稳定性、确认高风险的业务需求和技术机制已经解决、修订的项目计划可行等。

三.RUP 构造阶段

阶段目标是将所有剩余的技术构件和稳定业务需求功能开发出来，并集成为产品，所有功能被详细测试。
从某种意义上说，构造阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。
Milestone：运行能力里程碑。

• 包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。

此刻，要确定软件、环境、用户是否可以开始系统的运行。

四.RUP 移交阶段

移交阶段的重点是确保软件对最终用户是可用的。交付阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。
Milestone：产品发布里程碑。
此时，要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。

RUP的特点

以用例为驱动，软件体系结构为核心，应用迭代及增量的新型软件生命周期模型。

RUP的核心活动

• UP由9个核心工作流构成每一个迭代的主要活动
• 6个核心过程工作流
  • 业务建模（Business Modeling）
    需求（Requirements）
    分析和设计（Analysis & Design）
    实现（Implementation）
    测试（Test）
    部署（Deployment）
• 3个核心支持工作流：
  • 配置和变更管理（Configuration & Change Management）
    项目管理（Project Management）
    环境（Environment）

RUP 最佳实践

短时间分区式的迭代：2～4周，不鼓励时间推迟；
适应性开发：小步骤、快速反馈和调整；
在早期迭代中解决高技术风险和高业务价值的问题，建立内聚的核心架构。
不断地验证质量；尽早、经常和实际地测试；
使用用例驱动软件建模：用例是获取需求、制定计划、进行设计、测试、编写终端用户文档的驱动力量。
可视化软件建模：使用UML进行软件建模。
仔细地管理需求：不要草率地对待需求，而要有机地进行需求的提出、记录、等级划分、追踪。拙劣的需求管理是项目陷入麻烦的一个常见原因。
实行变更请求和配置管理

敏捷建模

敏捷建模（Agile Modeling，AM）是由Scott W. Ambler从许多的软件开发过程实践中归纳总结出来的一些敏捷建模价值观、原则和实践等组成的，它是快速软件开发的一种思想代表，具体的应用有极限编程、SCRUM、水晶、净室开发等。
2001年敏捷联盟成立，其主要特点就是具有快速及灵活的响应变更的能力。http://agilemanifesto.org/

eXtreme Programming 极限编程

1996年三月，Kent Beck在为Daimler Chrysler所做的一个项目中引入了新的软件开发观念：XP。
XP是一种轻量级的软件开发方法，是一种以实践为基础的软件工程过程和思想。
它使用快速的反馈，大量而迅速的交流，经过保证的测试来最大限度的满足用户的需求。
XP强调用户满意，开发人员可以对需求的变化作出快速的反应。

极限的工作环境

• 为了在软件开发过程中最大程度地实现和满足客户和开发人员的基本权利和义务，XP要求把工作环境也做得最好。
• 每个参加项目开发的人都将担任一个角色（项目经理、项目监督人等等）并履行相应的权利和义务。
• 所有人都在同一个开放的开发环境中工作
  • 最好是所有人在同一个大房子中工作，还有茶点供应；
    每周40小时，不提倡加班；
    每天早晨，所有人一起站着开个短会；
    墙上有一些大白板，所有的Story卡、CRC卡等都贴在上面，讨论问题的时候可以在上面写写画画；
    下班后大家可以一起玩电脑游戏……。

极限的需求

• 开发人员和客户一起，把各种需求变成一个个小的需求模块（User Story）；
• 这些模块又会根据实际情况被组合在一起或者被分解成更小的模块，且它们都被记录在一些小卡片（Story Card）上；
• 客户根据每个模块的商业价值来指定它们的优先级；
• 然后，开发人员确定每个需求模块的开发风险；
• 经过开发人员和客户的评估后，它们被安排在不同的开发周期里，客户将得到一个尽可能准确的开发计划；
• 客户为每个需求模块指定验收测试（功能测试）。

极限的设计

• 从开发的角度来看，XP内层的过程是一个基于Test Driven Development周期，每个开发周期都有很多相应的单元测试。
• 随着这些测试的进行，通过的单元测试也越来越多。通过这种方式，客户和开发人员都很容易检验，是否履行了对客户的承诺。
• 同时，XP还大力提倡设计复核（Review）、代码复核以及重整和优化（Refectory），所有的这些过程其实也是优化设计的过程；

极限的编程

• XP提倡配对编程（Pair Programming），而且代码所有权是归于整个开发队伍（Collective Code Ownership）。
• 程序员在写程序和重整优化程序的时候，都要严格遵守编程规范。
• 任何人都可以修改其他人写的程序，修改后要确定新程序能通过单元测试。

极限的测试

• XP提倡在开始写程序之前先写单元测试。
• 开发人员应该经常把开发好的模块整合到一起（Continuous Integration，持续集成），每次整合后都要运行单元测试；
• 做任何的代码复核和修改，都要运行单元测试；
• 发现了BUG，就要增加相应的测试。
• 除了单元测试之外，还有整合测试，功能测试、负荷测试和系统测试等。
• 所有这些测试，是XP开发过程中最重要的文档之一，也是最终交付给用户的内容之一。

课后思考题

• 结合本章节的主要内容，各小组思考本次作业哪种模型比较合适？
• 可否采用其他模型？
• 根据已决定的模型，小组内的人员如何分配？
  • 课程作业模式
  • 实际的工程项目
• 各小组针对已了解的需求内容，请考虑技术解决方案。