软件工程模型

你在工作中, 软件的开发流程是怎样的? 你是否想过, 除了你当前使用的流程, 还存在其他怎样的流程? 现在的流程有哪些问题, 又能够如何解决? 别说, 前辈们已经给出了一些项目流程的模型, 既软件工程. 可以简单了解一下, 带动一下我这生了锈的脑子.

在很久以前, 一个软件的从想法到落地, 还没有什么可供参考的流程, 基本上就是边提需求边开发, 毫无章法. 对于当时的项目来说, 因为规模不大, 这种方式就已经 OK 了. 但随着后面功能越来越复杂, 项目越来越大, 就逐渐暴露出了一些问题, 整个项目开发流程不可控, 无法进行有效的计划, 同时项目没有分工合作, 也不利于大型项目的开发等等.

为了解决这些问题, 前辈们提出了软件工程. 一个项目由想法到发布, 大概可以划分为这么几个步骤(这几个步骤可能并不准确, 我自己想的..):

1. 构思
2. 将构思进行书面表达
3. 对构思进行功能的细化
4. 设计产品的展示(某些无界面的产品不用)
5. 进行开发
6. 测试
7. 发布
8. 后期维护

根据这些步骤, 发明了瀑布模型.

瀑布模型

瀑布模型, 顾名思义, 像一个瀑布一样, 将流程分为若干个阶段, 完成一个阶段之后, 流向下一个阶段. 瀑布模型包括如下几个阶段:

1. 提出问题
2. 需求分析
3. 软件设计
4. 编码
5. 测试
6. 后期维护

使用瀑布模型来管理软件之后, 效果立竿见影, 项目的管理流程化了, 同时也可以针对各个阶段进行评估, 来估算项目的整体进度.

瀑布模型和装修有些类似, 先确认需求, 然后进行设计, 最后具体实施. 但是毕竟是两个不同的领域, 在盖房子的过程中, 基本不会有需求变更的时候, 而在软件开发中, 变更需求简直就是家常便饭. 而瀑布模型又无法快速的对需求的变更进行响应.

简单总结一下瀑布模型的优缺点.

优点: 可以按照阶段进行检查, 在前一阶段无误后, 全力开启下一个阶段. 同时项目总体进度可控, 可以有计划的进行.

缺点:

• 难以及时响应需求的变化
• 工作分布不均衡, 前期开发人员无法参与, 后期又完全靠开发测试
• 任何一环的出现问题导致时间过长, 会导致连锁反应, 后面环节的时间都要压缩.

虽然瀑布模型存在这一些缺点, 但也比之前的游击队要好的多了.

快速原型模型

在需求分析阶段, 为了进行需求的确认, 可以简单快速的搭一个demo, 用户需求变化之后, 可以快速进行响应并将其添加到软件中. 当然, 为了追求速度是需要牺牲质量的.

在需求确认之后, 对于原型可以选择丢弃, 因为他已经完成了它的使命.

不过建造原型不一定需要开发, 对于一些界面应用, 有简单可行的工具, 进行简单的拖拽就能实现简单的界面与交互, 同样可以达到确认需求的目的.

小瀑布模型

瀑布模型因为周期比较长, 所以无法及时响应需求的变动, 如果将一个大瀑布拆分成多个小瀑布, 就可以分阶段交付.

那么问题来了, 如果将一个瀑布拆分成多个呢?

1. 按照模块进行划分, 划分为多个模块, 可以并行开发多个模块来提高效率. 同样无法及时响应需求变动.
2. 简化需求, 先实现一个版本一, 然后再进行下一个阶段, 直至达到最终效果. 想了想, 产品上线后的更新迭代不就是了.

其中每个小瀑布都包含瀑布模型的完整流程.

敏捷开发

以上几种模型, 都是基于瀑布模型进行的改进, 传统的瀑布模型周期长, 难以响应变化, 针对这些问题, 提出了敏捷开发.

你一定听说过一个东西: 敏捷宣言. 就是下面这个:

链接: http://agilemanifesto.org/

敏捷宣言中并没有给出具体的实施步骤, 只是提出了一些思想.

不难发现, 敏捷宣言中右侧的内容, 都是传统的瀑布模型中强调的内容. 其大概就是通过不断的快速交付软件, 收集新的需求, 不断进行完善. 其强调拥抱需求的变化.

打个比方, 我们开始一个新的项目, 按照传统的瀑布模型, 在开发过程中是不会轻易修改需求的, 而这明显违背了敏捷开发的价值观: 客户合作高于合同谈判, 响应变化高于遵循计划.

而为了达到以上的目的, 也提出了一些方法.

1. 需求就是一个小故事

没有详细的需求文档, 只是提出: 我想要一个 xxx. 开发人员再开发过程中, 不断进行完善并确认细节. 如此就减少了大量需求文档的编写, 但同时, 也会造成需求理解错误, 最终效果差别较大.

可以将所有的故事放到一个列表中, 并标明状态(待办/处理中/已完成等), 开发人员根据优先级去完成列表中的任务即可. 同时也可以追踪哪些任务提了很久都没做, 已经不需要可以直接去掉.

2. 定期重构

因为每次只做部分需求, 所以无法在一开始就将整体架构完善, 迭代次数一多, 架构就跟不上业务了, 所以要进行重构来满足新的业务.

3. 自动化测试

通过单元测试, 集成测试等, 在开发的过程中完成部分测试的任务.

4. 每日站立会议

每天上班时, 先一起开一个站立会议, 目的是同步一下项目进度, 是否需要他人支持, 是否遇到困难等.

5. 小版本发布

每个版本只添加一些小功能, 就可以快速完成并发布. 发布多个版本之后达到一个较复杂的功能. 可以多次发布版本, 及时对业务进行调整.

等等

那么敏捷开发和上面简化需求持续迭代的小瀑布模型有什么区别么? 我是这样理解的, 在瀑布模型中, 需要经过整个从提出问题到测试发布的过程. 而敏捷开发没有这些繁琐的流程, 开发人员直接拿到一个需求的想法, 就可以开始编码发布了.

敏捷开发也有一些提出的具体流程, 比如极限编程/Scrum等(个人觉得极限编程的想法有点扯). 但我觉得主要还是借鉴其思想.

以上几种开发流程, 其实就是2种, 传统的瀑布模型, 和较新的敏捷开发. 瀑布模型基本上就是流水线作业, 项目进度较为直观, 基本上是从传统工业上面借鉴的思路. 而敏捷开发给我的感觉更适合软件行业一些. 倒也不是说那个好那个不好, 甭管黑猫白猫, 能抓到耗子就是好猫. 在具体实施中, 可以将多个模型相结合, 相互借鉴想法, 打造出适合自己的流程.

简单了解一下, 只听说过敏捷开发, 但没有具体了解过.