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

文章目录

• 软件工程概述
• • 软件的定义
  • 软件的分类
  • 软件工程要素、目标和原则
  • 软件工程知识体系知识域
• 软件生命周期模型
• • 工程过程
  • 传统模型种类
  • • 瀑布模型
    • 演化模型
    • 增量模型
    • 喷泉模型
    • V模型和W模型
    • 螺旋模型
    • 构件组装模型
    • 快速应用开发模型
    • 原型方法
  • 新型软件生命周期模型
  • • RUP的四个主要阶段
    • RUP的特点
    • RUP的核心活动
    • RUP 最佳实践
    • 敏捷建模
    • eXtreme Programming 极限编程
  • 课后思考题

软件工程概述

软件的定义

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

软件的分类

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

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

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

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

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

软件工程知识体系知识域

软件生命周期模型

工程过程

• 工程项目有三个基本的目标：
  合理的进度；
  有限的经费；
  一定的质量；

传统模型种类

瀑布模型

演化模型的特点：

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

增量模型

喷泉模型

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

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的核心活动

• 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开发过程中最重要的文档之一，也是最终交付给用户的内容之一。

课后思考题

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