软件构造(02)：软件开发过程模型

由于笔者是计算机类非软件工程专业的学生，在将来本科阶段的学习中应该不会非常系统地学习软件工程管理方面的知识，所以借学习软件构造这门课程的机会，拓展了一些软件开发过程模型的内容，在这篇博客中写下自己的一些总结和体会。

绝大多数的的软件开发都不是在短时间内完成的，每个软件团队在软件开发过程中都会遇到很多问题。针对这些问题，如果软件开发团队能够得到已有的经过验证的解决方案，将有助于他们快速地分析和解决问题。软件开发的过程模式提供了一个模板——一种在软件过程的背景下统一描述问题解决方案的方法。通过通过模式组合，软件团队可以解决问题并定义最符合项目需求的开发过程。

“正确的过程产生正确的结果。”
????????????——Takashi Osada

文章目录

• • 传统的软件开发过程模型
  • • 两种基本过程类型
    • 如何选择过程模型li>
    • 瀑布模型
    • • 定义
      • 优点
      • 缺点
      • 适用的软件系统
    • 增量模型
    • • 定义
      • 优点
      • 缺点
      • 适用的软件系统
    • V字模型
    • • 定义
      • 优点
    • 原型模型
    • • 定义
      • 优点
    • 螺旋模型
    • • 定义
      • 优点
      • 缺点
      • 适用的软件系统
  • 敏捷开发
  • • 极限编程(XP)
    • • 计划
      • 设计
      • 编码
      • 测试
      • 实例
    • Scrum
    • • 形成任务列表
      • 冲刺
      • 每日站会
      • 演示
  • 敏捷开发与传统软件开发的区别

传统的软件开发过程模型

两种基本过程类型

按照软件开发的一系列活动之间的拓扑结构，分为以下两类：

• 线性过程：各个开发环节工作过程之间采用线性工作流方式，按部就班，一个阶段一个阶段依次地进行软件开发。
• 迭代过程：整体上还是一个线性模型，但是在某些环节上进行回退和迭代。
  例如在设计阶段中发现之前做的需求分析有错误，则回退到需求分析阶段；
  在实现阶段中发现之前做的设计有错误，则回退到设计阶段。

后面介绍的过程模型，虽然理念和基本技术各不相同，但从基本的拓扑结构上来看都属于以上两类。

如何选择过程模型h3>

具体问题具体分析：
依据：

• 用户参与程度有多大适应变化的能力
• 开发效率/管理复杂度——二者的均衡
• 开发出的软件的质量
• 工期、经费、人员等

举例：

• 如果软件的业务过程非常稳定，则选用瀑布模型；如果业务过程经常发生变化，则选用含迭代的模型；
• 如果要求开发高质量的软件，则选用螺旋模型或瀑布模型；如果对软件质量要求不是非常高，允许一些小的Bug，则选用开发效率较高的模型。

瀑布模型

定义

瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。

需求获取–>设计–>实现–>测试、验证–>运维

优点

1. 线性推进
2. 阶段划分清楚
3. 管理简单，易于实现，只要保证上一个阶段的结果符合要求，就可以实施下一个阶段

缺点

1. 无法适应需求增加/变化。

1）客户通常难以清楚地描述所有的需求。而瀑布模型却需要客户明确需求，因此很难适应在许多项目开始阶段必然存在的不确定性。
2）客户必须要有耐心，因为只有在项目接近尾声的时候，他们才能得到可执行的程序。对于系统中存在的重大缺陷，如果在可执行程序评审之前没有被发现，将可能造成惨重损失。

2. 实际的项目很少遵守瀑布模型提出的顺序。虽然线性模型可以加入迭代，但是它是用间接的方式实现的，结果是，随着项目的推进，变更可能造成混乱。
3. 在分析一个实际项目时，经典生命周期模型的线性特性在某些项目中会导致“阻塞状态”，由于任务之间的依赖性，开发团队的一些成员要等待另一些成员工作完成。

适用的软件系统

瀑布模型适用于对一个已经存在的系统进行明确定义的适应性调整或是增强的时候（比如政府修改了规则，财务软件必须进行相应修改），也可能发生在很少数新的开发工作上，但是需求必须是准确定义和相对稳定的。

目前，软件工作快速进展，经常面临永不停止的变化流，特性、功能和信息内容都会变化，
瀑布模型往往并不合适这类工作．尽管如此，当需求确定、工作采用线性的方式完成的时候，
瀑布模型是一个很有用的过程模型。

增量模型

定义

把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。在每个增量开发的过程中仍采用瀑布模型。
本质上仍然是一个瀑布模型（多个瀑布的串行）

优点

1. 比较容易适应需求的增加。
2. 可以灵活分配人员
   如果在项目既定的商业期限之前找不到足够的开发人员，在这种情况下增量模型显得特别有用。早期的增量可以由少量的人员实现。如果核心产品的口碑不错，可以为下一个增量投入更多的人力。
3. 可以规避技术风险。例如，一个系统需要利用到某个正在开发的新硬件，而这个新硬件的交付日期不确定。因此可以在早期的增量中避免使用这个硬件，这样可以保证部分功能按时交付给最终用户，不至于造成过分的延期。

缺点

1. 相对于传统的瀑布模型而言，比较容易适应需求的增加，可以单独增加需求。但没有从根本上解决瀑布模型的缺点，无法对已有的需求进行变化
2. 要求在软件的架构中，后开发的增量可以容易地加入到前面的增量中进行集成，导致增量模块的接口变得复杂。

适用的软件系统

1. 初始的软件需求有明确的定义，但是整个开发过程却不宜单纯运用线性模型。
2. 迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。

V字模型

定义

瀑布模型的扩展，将验证/确认动作应用于早期软件工程工作中的方法。如图所示，随着软件团队工作沿着V模型左侧步骤向下推进，基本问题需求逐步细化，形成问题及解决方案的技术描述，其中每一个阶段形成的结果都应该是可测试的。一旦编码结束，团队沿着V模型右侧的步骤向上推进工作，其本质上是执行了一系列测试（质量保证动作），这些测试验证了团队沿着V模型左侧步骤向下推进过程中所生成的每个模型。

优点

软件开发的质量高

缺点

1. 管理复杂
2. 对于短周期的开发，螺旋模型无法运转
3. 它依赖大量的风险评估专家来保证成功。如果如果存在较大的风险没有被发现和管理，将会发生问题。

适用的软件系统

大型、长周期的软件开发，如Microsoft Office。

敏捷开发

2001年，Kent Beck和其他16位知名软件开发者，软件工程作家以及软件咨询师（称为敏捷联盟）共同签署了“敏捷软件开发宣言”。该宣言声明：

我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的软件开发之路，通过这项工作，我们认识到：
个人和这些个人之问的交流胜过了开发过程和工具
可运行的软件胜过了繁杂的文档
客户合作胜过了合同谈判
对变更的良好响应胜过了按部就班地遵循计划
也就是说，虽然上述右边的各项很有价值，但我们认为左边的各项具有更大的价值．

敏捷开发的过程，概括起来就是：
通过快速迭代和小规模的持续改进，以快速适应变化。

Agile = 增量 + 迭代，每次迭代处理一个小规模增量

极限的用户参与：
用户直接参与到开发中来，将需求的变化及时反馈给开发者
极限的小步骤迭代：
快速迭代，快速看到结果
极限的确认/验证：
补偿小步骤迭代计划的不完备，每做出一个成果，都进行快速确认和验证(测试优先原则)，保证软件的质量

极限编程(XP)

在计划、设计、编码、测试的一系列开发过程中进行快速、反复的迭代，在上述各个环节中的敏捷方面做到“极限”

计划

计划是一个需求获取活动，该活动要使XP团队技术成员理解软件的商业背景以及充分感受要求的输出和主要特征及主要功能。

1. 倾听产生一系列“用户故事”，也就是用户的需求，包括建立的软件的需要的输出，特征以及功能。用户故事还包括什么样的实现才算达到了用户的要求，如测试通过的标准等。
2. 给出一个小规模的迭代计划

设计

针对每一个小任务进行设计。

1. 做出基础的方案。XP推荐立即建立这部分设计的可执行原型，实现并评估设计原型（被称为Spike解决方案），其目的是在真正的实现开始时降低风险，对可能存在设计问题的故事确认其最初的估计。

编码

1. 重构。重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。通过不断地改进代码质量来提高软件质量
2. 结对编程。XP建议两个人面对同一台计算机共同为一个故事开发代码。这一方案提供了实
   时解决问题（两个人总比一个人强）和实时质量保证的机制（实时评审），同时也使得开发者能集中精力于手头的问题。实施中不同成员担任的角色略有不同，例如，一名成员考虑设计特定部分的编码细节，而另一名成员确保编码遵循特定的标准或者（XP所要求的那些），确保故事相关的代码能够通过相对于故事而开发的单元测试。

测试

敏捷开发轻设计、轻文档的特性可能会影响软件质量，为了保证快速迭代中软件的高质量，需要强调单元测试，持续集成，自动测试，不断验收、提交、发布

实例

看板
使用看板作为敏捷团队每天站会的讨论的核心，及时变更看板各个用户故事的状态，通过看板，敏捷团队可以清楚的了解其它成员的工作状况及和自己相关工作的进展。

在状态墙上，除了用户故事、 bug之外，还会有一些诸如重构、搭建测试环境这样的不直接产生业务价值的任务，这三类任务用不同颜色的卡片，放到状态墙上统一管理。

燃尽图
在图表中绘制两条线段，一条表示期望的工作进度，另一条记录实际的工作进度，把工作拆分成若干工作要点，完成一个就减去一个，以此来衡量工作距离全部完成的剩余时间。

当实际工作曲线低于期望值时，则表示工作可能提前完成，相反的情况则可能会延期。 如果每次绘制的图标，实际进度曲线都在期望值下方，则表示计划做的过于保守，可以适当缩短；相反的情况则表示计划过于激进，应当适当延长。也可以通过多次的记录统计，了解工作团队的工作效率是否有一定的提升，找出提高效率的办法。

敏捷开发与传统软件开发的区别

敏捷开发的优点是轻量级、简单、可快速交付、最大的特点是高度透明、检验和适应，注重开发团队之间以及开发团队与客户的及时沟通，主张响应需求变化，但是不够系统。

传统软件架构的优点在于预见性和系统性，能在正式开发前预见软件的功能需求和非功能需求，最大的特点是重视文档和结构明显，主张固定的流水开发，很难响应客户需求的变化，难以保证开发的灵活性。

参考文献：
Software Engineering a Practitioner’s Approach 7th edition
软件工程——瀑布模型、快速原型模型、增量模型、螺旋模型
敏捷开发的看板
敏捷开发与传统开发方式的比较