第二章软件工程

软件过程

软件的诞生和生命周期是一个过程，我们总体上称这个过程为软件过程

软件生命周期

软件产品的生命周期是指从设计该产品的构想开始，到软件需求的确定、软件设计、软件实现、产品测试与验收、投入使用以及产品版本的不断更新，到最终该产品被市场淘汰的全过程。

生命周期的划分原则
- 各阶段的任务应尽可能相对独立;
- 同一阶段各项任务的性质尽可能相同。
划分生命周期的优点
- 有利于软件开发工程的组织和管理
- 降低了整个软件开发过程的困难程度
- 对每个阶段都可选用最优的管理方法
- 保证软件质量、提高生产效率.
划分
- 软件定义
  - 问题的定义与可行性研究
  - 需求分析
- 软件开发
  - 软件设计
  - 程序编码
  - 软件测试
- 软件维护

软件过程模型

人们通过建立抽象的软件开发模型（也称软件过程模型或软件生命周期模型），把软件生命周期中的各个活动或步骤安排到一个框架中，将软件开发的全过程清晰、直观地表达出来

软件开发模型的内在特征有以下4点：

（1）软件开发模型描述了主要的开发阶段
（2）软件开发模型定义了每个阶段要完成的主要任务和活动
（3）软件开发模型规范了每个阶段的输入和输出
（4）软件开发模型提供了一个框架，把必要的活动映射到这个框架中

瀑布模型

优点
- 过程模型简单，执行容易
缺点
- 无法适应变更。
适用情况
- （1）在软件开发的过程中，需求不发生或很少发生变化，并且开发人员可以一次性获取到全部需求
- （2）软件开发人员具有丰富的经验，对软件应用领域很熟悉。
- （3）软件项目的风险较低。瀑布模型不具有完善的风险控制机制。
变体
- v模型

快速原型模型

快速原型的基本思想是快速建立一个能反映用户主要需求的原型系统，让用户在计算机上试用它，通过实践来了解目标系统的概貌。

优点
- 不带反馈环
适用情况
- （1）已有产品或产品的原型（样品），只需客户化的工程项目。
- （2）简单而熟悉的行业或领域。
- （3）有快速原型开发工具。
- （4）进行产品移植或升级。

增量模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件

优点
- （1）将待开发的软件系统模块化，可以分批次提交软件产品，使用户可以及时了解软件项目的进展。
- （2）以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
- （3）开发顺序灵活。开发人员可以对构件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时调整实现顺序。
缺点
- 要求待开发的软件系统可以被模块化。
适用情况
- （1）软件产品可以分批次地交付。
- （2）待开发的软件系统能够被模块化。
- （3）软件开发人员对应用领域不熟悉，难以一次性地开发系统。
- （4）项目管理人员把握全局的水平较高。

螺旋模型

螺旋模型是一种用于开发风险较大的大型软件项目的开发模型。该模型将瀑布模型与快速原型模型结合起来，并且加入了这两种模型忽略了的风险分析。

优点
- 将风险分析扩展到各个阶段中，大幅度降低了软件开发的风险。
缺点
- 控制和管理较为复杂
- 可操作性不强
- 对项目管理人员的要求较高。

喷泉模型

在分析阶段，定义类和对象之间的关系，建立对象-关系和对象-行为模型。在设计阶段，从实现的角度对分析阶段模型进行修改或扩展。在编码阶段，使用面向对象的编程语言和方法实现设计模型。在面向对象的方法中，分析模型和设计模型采用相同的符号标示体系，各阶段之间没有明显的界限，而且常常重复、迭代地进行。

适用情况
- 喷泉模型主要用于面向对象的软件项目
- 软件的某个部分通常被重复多次
- 相关对象在每次迭代中随之加入渐进的软件成分。

基于组件的开发模型

基于组件的开发模型使用现有的组件以及系统框架进行产品开发，由于现有组件大多已经历实际应用的反复检验，因此其可靠性相对新研发组件高出很多。

优点
- 极大地提高了产品开发效率
- 质量也得到了提高

统一软件开发过程模型

统一软件开发过程（Rational Unified Process，RUP）模型是基于UML（统一建模语言）的一种面向对象软件开发模型。采用迭代和增量递进的开发策略，并以用例驱动为特点，集中了多个软件开发模型的优点。RUP模型是迭代模型的一种。

敏捷过程与极限编程

敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程方法，它更强调软件开发过程中各种变化的必然性，通过团队成员之间充分的交流与沟通以及合理的机制来有效地响应变化。

四个价值观
- 个体与交互高于过程和工具
- 可运行软件高于详尽的文档
- 与客户协作高于合同(契约)谈判
- 对变更及时响应高于遵循计划
12条原则
- （1）首先要做的是通过尽早和持续交付有价值的软件来让客户满意。
- （2）需求变更可以发生在整个软件的开发过程中，即使在开发后期，我们也欢迎客户对于需求的变更。敏捷过程利用变更为客户创造竞争优势。
- （3）经常交付可工作的软件。交付的时间间隔越短越好，最好2～3周一次。
- （4）在整个的软件开发周期中，业务人员和开发人员应该天天在一起工作。
- （5）围绕受激励的个人构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。
- （6）在团队的内部，最有效果和效率的信息传递方法是面对面交谈。
- （7）可工作的软件是进度的首要度量标准。
- （8）敏捷过程提倡可持续的开发速度。责任人、开发人员和用户应该能够保持一种长期稳定的开发速度。
- （9）不断地关注优秀的技能和好的设计会增强敏捷能力。
- （10）尽量使工作简单化。
- （11）好的架构、需求和设计来源于自组织团队。
- （12）每隔一定时间，团队应该反省如何才能有效地工作，并相应调整自己的行为。
实践方式
- 极限编程（eXtreme Programming，XP）
- 自适应软件开发（Adaptive Software Development，ASD）
- 动态系统开发方法（Dynamic System Development Method，DSDM）
- ScrumCrystal和特征驱动开发（Feature Driven Development，FDD）
极限编程
- 极限编程是一种实践性较强的规范化的软件开发方法，它强调用户需求和团队工作。
- 适用情况
  - 软件需求模糊且容易改变
  - 开发团队少于10人
  - 开发地点集中