第二章 敏捷开发与配置管理

一、软件过程模型

1. 软件过程

一个为建造高质量软件所需要完成的活动、动作和任务的框架。

1.1 软件过程框架

1.2 软件开发过程流

2.软件过程模型

2.1 瀑布模型

将软件开发过程划分为计划、分析、设计、编码、测试等阶段

工作以线性方式进行，上一阶段的输出是下一阶段的输入

优点：简单、易懂、高效

缺点：难以确定用户所有需求，缺乏有效沟通，难以适应需求变更

2.2 增量模型

只要某个需求的核心部分出来，即可进行开发

本质：以迭代方式运用瀑布模型

优点：每次交付满足客户需求的一个子集，提高对用户需求的响应，人员分配灵活，用户有充足时间学习，可规避风险

困难：必须不破坏原来已构造好的东西，协调好各增量之间的关系

2.3 RAD模型

侧重于短开发周期(一般为60~90天)的增量过程模型，是瀑布模型的高速变体，通过基于构件的构建方法实现快速开发;
多个团队并行进行开发，但启动时间有先后，先启动团队的提交物将作为后启动团队的输入。

优点:
充分利用企业已有资产进行项目开发

提高软件交付速度

困难：

需要大量的人力资源
在短时间内为急速完成整个系统做好准备，
系统能被合理的模块化
如果系统需求是高性能，并且需要通过调整构件接口的方式来提高性能，不能采用RAD模型;
技术风险很高

2.4 原型模型

一种专门应对不断演变的软件过程模型

本质:循环、反复、不断调整当前系统以适应需求变化

开发步骤：

– Step 1:双方通过沟通，明确已知的需求
– Step 2:迅速策划一个原型开发迭代并进行建模
– Step 3:对原型进行部署，由客户和用户进行评价
– Step 4:根据反馈进一步细化需求并调整原型
– Step 5:原型系统不断调整以逼近用户需求

优点:
– 方便与客户沟通，提高和改善客户的参与程度;
– 逐步弄清客户的需求，响应用户需求的变化;

问题:
– 没有考虑整体软件的质量和长期的可维护性，系统结构通常较差
– 用户可能混淆原型系统与最终系统，原型系统在完全满足用户需求之后可能会
被直接交付给客户使用
– 额外的开发费用

2.5 迭代模型

2.6 螺旋模型

螺旋模型沿着螺线旋转，在四个象限内表达四个方面的活动:

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

– 风险分析:分析所选方案，考虑如何识别和消除风险;
– 实施工程:实施软件开发;
– 客户评估:评价开发工作，提出修正建议。

优点:

– 结合了原型的迭代性质与瀑布模型的系统性和可控性，是一种风险驱动型的过程模型

问题:
– 适用于大规模软件项目，特别是内部项目，周期长、成本高;
– 软件开发人员应该擅长寻找可能的风险，准确的分析风险，否则将会带来更大的风险。

2.7 统一过程模型（RUP）

RUP的四个技术阶段：

（1）起始(Inception)：
– 通过沟通与策划，定义项目范围、识别业务需求、提出大致的架构、制定开发计划，使用Use Case (用例)描述主要特征功能;

（2）细化(Elaboration)：
– 扩展体系结构及用例，从五个角度来构建软件模型(用例模型、需求模型、设计模型、实现模型和部署模型)，并建立一个baseline(基线);评审与修订项目计划

（3）构建(Construction)：
– 将体系结构模型作为输入，完善上一阶段的分析和设计模型;

– 开发或获取软构件，并对每个构件实施单元测试;
– 构件组装和集成测试;
（4）转换与交付(Transition)：
– 软件被提交给用户进行测试，接收用户反馈报告并进行变更;
– 创建必要的支持信息(如用户手册、安装步骤、FAQ等);

核心工作流程：

（1）6个过程工作流
– 业务建模 – 需求
– 分析设计 – 实现
– 测试 – 部署
（2）3个支持工作流
– 配置和变更管理

– 项目管理
– 环境

二、敏捷开发

1.敏捷过程模型

敏捷开发重视人的作用，以人为本的软件开发方法

1.1 敏捷开发原则

准则1:尽早和持续地交付
准则2:欢迎对需求提出变更
准则3:要不断交付可用的软件

准则4:业务人员与开发人员必须在一起工作
准则5:要善于激励项目人员
准则6:面对面的交谈

准则7:可用的软件是衡量进度的主要指标。
准则8:敏捷过程提倡可持续的开发
准则9:对技术的精益求精以及对设计的不断完善

准则10:要做到简洁
准则11:最佳的架构、需求和设计出自于自组织的团队。
准则12:团队要定期反省

1.2 本质

以快速的增量和迭代方式进行软件开发

2.极限编程XP

一种最广泛应用的敏捷开发方法

2.1 核心实践方式

（1）计划阶段：
形成一组“用户故事(user stories)”，为每个用户故事指定优先级(Priority)，指定为下一次发布的增量，规划整体进度(project velocity)

（2）设计阶段：

遵循KIS原则(Keep It Simple)；面向对象方法，CRC卡片(Class-Responsibility-Collaborator);对设计方案不断重构(Refactoring)

（3）编码与测试阶段：

XP Coding
– 根据用户故事设计单元测试用例;
– 结对编程(Pair programming):两人一起编程，实时讨论、实时评审;

– 测试驱动的开发(TDD):先写测试用例，再写代码;
XP Testing
– 自动化单元测试(Unit test);
– 持续集成(Continuous Integration);

– 持续进行回归测试(Regression test);

– 验收测试(Acceptance test)。

2.2.结对编程

两个程序员肩并肩地、平等地、互补地进行开发工作

驾驶员和领航员不断轮换角色，不宜连续工作超过一小时。领航员要控制时间。

程序各方面的质量取决于 一对程序员中各方面水平较高的那一位。

3. Scrum

一个敏捷开发框架:增量/迭代的开发过程

3.1 基本过程

3.2 三种角色

（1）产品负责人(Product Owner):确定产品的功能，负责维护产品 Backlog、deadline、priority、ROI(产品投资回报率);验收结果;
（2）ScrumMaster:团队leader，保证开发过程按计划进行;组织每日站 会、Sprint计划会议、Sprint评审会议和Sprint回顾会议;通过外在/ 内在协调，确保团队资源完全可被利用并且全部是高产出的;
（3）Scrum团队:在每个Sprint中将产品Backlog中的条目转化成为潜在可 交付的功能增量;规模在5-9人;具备交付产品增量所需要的各种技能

4. 软件过程模型比较

• 瀑布模型:将全部需求以整体方式向前推进，无迭代;——基本模型
• 增量模型:将需求分成多份，串行推进，无迭代;——串行的瀑布
• RAD模型:将需求分成多份，并行推进，无迭代; ——并行的瀑布
• 原型模型:迭代; ——基本模型
• 螺旋模型:按瀑布阶段划分，各阶段分别迭代(原型+风险分析); ——原型+瀑布
• 敏捷模型:将需求分成尽量小的碎片，以碎片为单位进行高速迭代。 ——增量+迭代

三、软件项目管理

1.基本概念

（1）项目(Project):为创建某种特定的产品或服务而组织或设计的临时的、 一次性的行动;通过执行一组活动，使用受约束的资源(资金、人、原 料、能源、空间等)来满足预定义的目标。
（2）项目管理(Project Management, PM):有效的组织与管理各类资源(例如人)，以使项目能够在预定的范围、质量、时间和成本等约束条件下顺利交付(deliver)。

项目特征：

（1）软件产品的不可见性，软件项目复杂和抽象
（2）项目的高度不确定性，预定计划于实际情况存在较大偏差
（3）软件过程的多变化性，不确定、不稳定
（4）软件人员的高技能及其高流动性，风险

2.软件项目管理的4P

2.1 人员(People)

参与人员：

高级管理者、项目管理者、开发人员、客户、最终用户

组织方式：
（1）一窝蜂模式 (chaos team):没有明确分工，存活的时间一般都不长。

（2）主治医师模式: (Chief-Programmer Team, surgical team)

主治医师模式的退化:学校里，软件工程的团队模式往往退化为“一个学生 干活，其余学生跟着打酱油”。

（3）明星模式 (Super-star model)

（4）社区模式 (Community Model):由很多志愿者参与，每个人参与自己感兴趣的项目，贡献力量。

（5）交响乐团模式 (Orchestra)：类似于“工厂”，严格遵循预订的生产流程

（6）爵士乐模式 (Jazz Band)：类似于一群天才构成的敏捷团队， 率性而为。

（7）功能团队模式 (feature team)：具备不同能力的同事平等协作，共同完成一个项目开发;

（8）官僚模式 (bureaucratic model)：成员之间不光有技术方面的合作和领导，同时还混进了组织上的领导和被领 导关系，跨组织的合作变得比较困难。

2.2 产品（product）

2.3 过程（process）

Step 1: 选择合适的软件过程模型 – 存在多种过程模型
Step 2: 根据所选的过程模型，对其进行适应性修改;
Step 3: 确定过程中应包含的工作任务列表;

2.4项目（project）

（1）项目关注的四个方面

– 范围(Scope)
– 时间(Time)
– 成本(Cost)
– 质量(Quality)
（2）项目管理的主要任务
– 项目可行性分析与估算 – 项目进度安排
– 项目风险管理
– 项目质量管理
– 项目跟踪与控制

（3）如何定义关键的项目特性--W5HH原则
– Why
– What
– When
– Who
– Where
– How
– How much

为什么要开发这个系统?
将要做什么?
什么时候做?
某功能由谁来做?
他们的机构组织位于何处?
如何完成技术与管理工作?
各种资源分别需要多少?

3. 可行性分析与估算

得出“该项目是否可行”的结论

3.1 确定范围

范围(Scope):描述了将要交付给最终用户的功能和特性、输入输出数据、用户界面、系统的性能、约束条件、接口和可靠性等，以及期望的时间、成本目标;

3.2 可行性分析

• 技术可行性
• 经济可行性
• 时间可行性
• 资源可行性

3.3.确定资源

– 人力资源
– 可复用的软件资源
– 环境资源

3.4 软件项目估算

估计得越精确，项目成功的可能性就越高

方法：
（1）代码行技术(LOC)

从过去开发类似产品的经验和历史数据出发，估计出所开发软件的代码行数

（2）功能点技术FP

功能点(Function Point, FP)，以功能点为单位来估计软件规模，关注 五个方面的功能:
– 外部输入(EI):用户进行添加或修改数据的UI
– 外部输出(EO):软件为用户产生的输出UI
– 外部查询(EQ):软件可产生的独立查询
– 内部逻辑文件(ILF):软件修改或保存的逻辑记录集合(数据表或文件) – 外部接口(EIF):与其它系统进行信息交换或共享的文件

（3）基于过程的估算

将过程分解为一组较小的任务，并估算完成每个任务所需的工作量

沟通、策划、建模、构建、部署

4. 项目进度计划与监控

4.1 项目进度计划

目标:
– 使软件项目在截止日期之前成功的完成并提交给客户;
活动:
Step 1:将项目划分为多个活动、任务。PBS、WBS
Step 2:确定任务项目依赖性。定义任务网络，网络图
Step 3:时间分配。为任务安排工作时间段，关键路径，甘特图
Step 4:确认任务资源。确认每个任务的资源需求
Step 5:确定责任。确定每个任务的负责人和参与人，人力资源分配图
Step 6:明确结果。明确任务的输出结果(文档或部分软件) Step 7:确定里程碑(milestones)。确定任务与项目里程碑关联

5. 项目风险管理

四、软件配置管理

1.软件演化

• 软件在使用过程中，新的需求不断出现
• 商业环境在不断地变化
• 软件中的缺陷需要进行修复
• 计算机硬件和软件环境的升级需要更新现有的系统
• 软件的性能和可靠性需要进一步改进

软件演化的Lehman定律：

持续变化、复杂度逐渐增大

2.软件维护

定义：(ANSI/IEEE) 在软件产品发行和被投入运行使用之后对其的修改，以改正错误，改 善性能或其他属性，从而使产品适应新的 环境或新的需求。

2.1 软件维护的类型

• 纠错性维护:修改软件中的缺陷或不足
• 适应性维护:修改软件使其适应不同的操作环境，包括硬件变化、操作系统变化或者其他支持软件变化等
• 完善性维护:增加或修改系统的功能，使其适应业务的变化
• 预防性维护:为减少或避免以后可能需要的前三类维护而提前对软件进行的修改工作

2.2 纠错性维护、适应性维护

为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误使用， 应当进行的诊断和改正错误的过程就叫做纠错性维护。

在使用过程中，外部环境(新的硬、软件配置)和数据环境(数据库、数据格式、
数据输入/输出方式、数据存储介质)可能发生变化;为使软件适应这种变化，而去修改软件的过程就叫做适应性维护。

2.3 完善性维护、预防性维护

为了满足新的要求，需要修改或再开发软件，以扩充软件功能、增强软件性 能、改进加工效率、提高软件的可维护性;这种情况下进行的维护活动叫做完善性维护。

预防性维护(Preventive Maintenance):定义为“采用先进的软件工程方法对需要维护的软件或软件中的某一部分 (重新)进行设计、编制和测试”

2.4 成本

实践表明，在几种维护活动中，完善性维护所占的比重最大

软件的维护成本极其昂贵

2.5 困难

大部分问题都可归咎于软件规划和开发方法的缺陷

造成困难的根本原因 ：

• 很难甚至不可能追踪软件版本的进化过程，软件的变化没在相应文档 中反映出来；
• 很难甚至不可能追踪软件的整个创建过程；
• 理解他人的程序非常困难，当软件配置不全、仅有源代码时问题尤为 严重；
• 软件人员流动性很大，维护他人软件时很难得到开发者的帮助；
• 软件没有文档、或文档不全、或文档不易理解、或与源代码不一致；
• 多数软件设计未考虑修改的需要(有些设计方法采用了功能独立和对象 类型等一些便于修改的概念)，软件修改不仅困难而且容易出错；
• 软件维护不是一项有吸引力的工作，从事这项工作令人缺乏成就感。

3.遗留系统(legacy system)

已经运行了很长时间的、对用户来说很重要的、但是目前已无法完全满足 要求却不知道如何处理的软件系统

一种可行的维护方案：软件再工程

4. 软件再工程

– 重新构造或编写现有系统的一部分或全部，但不改变其功能

– 在大型系统中某些部分需要频繁维护时，可应用软件再工程

– 目的：努力使系统更加易于维护，系统需要被再构造和再文档化

4.1 优势

– 减少风险：重新开发一个在用的系统具有很高的风险，可能会有开发问题、 人员问题和规格说明问题

– 降低成本：再工程的成本比重新开发软件的成本要小得多

4.2 再工程的基本活动

• 源代码转换(source code transformation) – 代码从原有的程序设计语言转换到一种新语言
• 逆向工程(reverse engineering) – 分析程序并抽取信息记录其结构和功能
• 程序结构改善(program restructuring) – 分析和修改程序的控制结构，使其更易读和好理解
• 程序模块化(program modulization) – 重新组织程序的结构
• 数据再工程(data restructuring) – 改变程序处理的数据以反映程序的变更(文件存储数据库存储，数据格式 改变，等等)

5. 软件配置管理

5.1 基本定义

软件配置(SCI：Software Configuration)：由在软件工程过程中产生 的所有信息项构成，它可以看作该软件的具体形态(软件配置项)在某一时刻的瞬间影像。

软件配置管理(SCM：Software Configuration Management)：界定 软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。

5.2 SCM的基本元素

• 配置项(Configuration Item, CI)：软件过程的输出信息可以分为三个主要类别： 计算机程序(源代码和可执行程序) 、描述计算机程序的文档(针对技术开发者和用户) 、数据(包含在程序内部或外部) 这些项包含了所有在软件过程中产生的信息，总称为软件配置项(SCI)。
• 基线(Baseline)：已经通过正式评审和批准的软件规格说明或代码，它可以作为进一步开发的基础，并且只有通过正式的变更规程才能修改它。
• 配置管理数据库(CMDB)：用于保存于软件 相关的所有配置项的信息以及配置项之间关系的数据库。
• 备件库(Definitive Hardware Store, DHS)
• 最终软件库(Definitive Software Library, DSL)