目录

软件开发常用方法

软件开发是软件工程生命周期中很重要的一部分。

从方法学的角度看，软件开发方法有自顶向下和自底向上的开发方法。自顶向下开发过程是由问题到解决、从总体到局部、从抽象到具体的过程；而自底向上开发方法一般从基础入手，由简单到复杂，逐层迭代构造，最终得到完整的软件产品。

从性质上看，有形式化和非形式化；形式化是在实现阶段采用严格的数学语言，有较精确的数学语义，很好的避免系统的歧义、不完整、不一致，每一步都是严谨可靠的；

软件自动化方法，也逐渐发展成效，通过借助计算机系统、人工智能实现软件开发的方法，但目前更多还是一些模板化的自动化实现，当前大部分产品都需要定制化，需要人工编码实现，也许不久的将来产品会更将模板化统一化，出现软件产品生产机器的可能性很高。

软件开发发展到今天，常用的都有哪些开发方法？

净室方法

净室方法就是一种形式化方法，并不强调测试，而是通过一组场景进行正确性验证。净室方法比较严格，强调正确性可靠性的数学验证，要求目标结果是非常低的出错率。

结构化方法

结构化方法，基本思想就是自顶向下、逐步求精。结构化提出了一些准则，比如抽象与分解，模块化，信息隐蔽等

结构化方法最早最成熟的应用教广泛的一种软件工程化方法，面向用户，充分理解用户需求及业务，保持跟进用户需求与业务变更，严格区分各个阶段，按照自顶向下完成系统的设计开发；

结构化方法虽然教成熟，但开发周期较长，过于注重系统功能而忽略数据结构，开发初期较抽象，难以明确功能要求。

面向对象方法

java、c++、php等面向对象语言的普及，推动面向对象开发方法，面向对象方法可以细分成大量不同的方法，比如OMT、Booch等方法。面向对象开发方法包括OOA、OOD、OOP即面向对象分析、面向对象设计、面向对象编程。面向对象更贴近自然事物，包含一些基本的概念：对象、类、继承、封装、消息、多态性等

后续我们再详细介绍面向对象开发方法：UML、用例模型、分析模型、面向对象设计等

原型法

成熟互联网行业，追求快速高效成型市场化，而结构化和面向对象的开发方法有一个共同点：在系统开发初期必须明确系统功能要求，明确系统边界，从以往工程学角度看，这是很自然的，但由于软件产品依赖于用户需求，需求大多动态变化的；需求可以看做矛盾，涵盖主要矛盾与诸多次要矛盾，系统优先解决主要矛盾，进而逐步解决次要矛盾，直到系统成熟稳定，进一步挖掘用户需求发现矛盾，满足需求解决矛盾，周而复始，所以一开始就明确问题本身不是一件轻松的事情。

原型开发方法中的原型是软件早期可运行的版本，解决了系统的主要矛盾，反映了最终系统的部分重要特性。

团队在获得一组基本需求后，快速分析需求主次，并构造最小可行性产品，满足用户的基本需求，让用户在试用时，提出亲身感受、意见、建议、启发与评价等，团队在用户反馈的基础上对原型进一步改进，通过不断的试用、评价、迭代完善，逐步完成一个贴近用户需求的产品，过程迭代快，细腻精准迅速，产品最终质量更高。

我们常见到的几种原型开发方法：

  • 水平原型：通常是功能的导航，并不实现真实功能，相当于一个框架
  • 垂直原型：用于突破主要功能难点，常用于复杂的算法实现
  • 抛弃型原型：一般用于探索可行性，一旦探索得到预期目的，原型被抛弃
  • 演化型原型：相对于抛弃型原型，演化型，属于增量式开发，一旦探索可行，将继续迭代实现，适合易于升级与优化的项目

根据我们系统需要选择适合的原型开发方法，不用拘泥于理论。

原型开发方法生命周期：

  • 快速分析：得到系统基本要求
  • 构造原型：尽快实现最小可行性系统
  • 试用评价：内部或用户试用及评价原型，得到建议、意见
  • 完善改进：根据使用评价的反馈，快速完善改进原型
  • 原型完成：达到原型预期目的，得到参与试用评价者一致认可，原型迭代可以结束
  • 整理原型及文档

原型开发方法，可以提供一种完整、灵活、高效、快速的迭代方法，让系统可以快速尝试、验证必要性与可行性，解决系统开发初期系统需求不明确的问题，大部分系统多多少少会使用到原型开发方法，缩短开发周期，降低开发风险，让用户更多参与和决策，更贴近用户实际需求（不是嘴巴上的需求）。

软件重构

我们经常听开发说重构，重构是对代码、数据进行调整修改，使得系统架构更清晰、代码更容易阅读、修改、维护，以便适应后续需求变更。

  • 代码重构，目的是实现功能相同代码质量更高的模块或系统。
  • 数据重构，数据一般属于更加抽象层次，数据结构清晰明确有依据，更有利于上层逻辑代码的组织

软件重构目的是提高软件质量，降低软件复杂度与可维护性外，还能提高开发效率，减少维护工作量。

再工程

再工程是对系统的重新开发，重新实现已经存在的系统，同时根据实际需要加入新的功能、改进功能或改善性能。再工程需要系统级别的全面理解。

我们常说的二开或是开源项目的分支，可以看做是再工程的一种形式。

逆向工程

逆向工程，也就是反向工程，通过工具从已有系统代码抽取数据结构、体系架构等系统设计信息。

软件常用开发模型

方法与模型

前面我们介绍了一些开发方法，这里又提到开发模型，很多人应该会有些疑惑，开发方法与开发模型有什么区别？

这里的方法与模型边界是比较模糊的，两者重叠的地方比较多，边界不清晰。

开发方法我们可以理解成一种原理/方法学，开发模型基于开发方法经过很多项目的实践逐步积累完善形成的一套有规划性的相对稳定的模板套路或叫框架，对软件开发具有比较明确的指导意义，我们根据开发方法与实际产品项目情况灵活套用开发模型。

开发方法更偏向于设计与编码实现，开发模型完整关注这个系统开发生命周期。

典型的瀑布模型是基于结构化开发方法提出的一种开发模型；基于原型方法，业界也提出演化模型、增量模型、迭代模型等开发模型，虽然有些知识和原型方法沾边，但确实从原型方法中得到启发。

瀑布模型

瀑布模型是很经典的一个开发模型，早期相当成熟的应用比较广泛的开发模型，由于模型的每个阶段都清晰明确，我们也称为生命周期法，是结构化开发方法中的一种开发模型。

模型有6个阶段，每个阶段自上而下相互衔接，如同瀑布：

- 系统计划
    - 需求分析
        - 软件设计
            - 编码实现
                - 软件测试
                    - 运行维护
  • 系统计划：确认必要性、可行性、确定目标与边界
  • 需求分析：对各个功能进行详细的分析，好的开始是项目成功的一半
  • 软件设计：一般有概要设计与详细设计
  • 编码实现：实现功能的同时，要求性能、安全性、易维护性、可扩展性等质量属性
  • 软件测试：在设计阶段就开始准备测试计划、用例，严格执行测试计划，避免测试的随意性，避免盲目测试，导致难以控制掌握软件质量
  • 运行与维护：由于发展是永恒的，所以维护也是一个长期性质的阶段任务

瀑布模型，在现在看来比较保守古板，但在当时是有利于大型系统开发中的人员组织与管理，也能有效提高系统质量与开发效率；随着互联网的发展，瀑布模型也逐渐暴露出未与时俱进的一些弊端：

  • 开发周期长，用户需要在系统运行时，才能见到，容易出现返工风险
  • 由于6个阶段自上而下衔接，如果前期未发现错误，后期的活动中才发现，会导致系统返工甚至失败
  • 瀑布模型很需要前期完整确定用户需求，在现在看来是很困难的，瀑布模型在如今快准狠迭代的需求下，很难展开。
  • 瀑布模型更适合于需求明确、变更较少的系统项目

瀑布模型虽然不再适合当前大部分项目，但瀑布模型也有一些可借鉴地方，比如螺旋模型将瀑布模型与演化模型相结合，结合双方的优点，增加风险分析。

V模型

V模型是以测试为中心的开发模型。

需求分析                            验收测试
    \                               /
    概要设计                    系统测试
        \                       /
        详细设计            集成测试
            \               /
            编码实现    单元测试
                \       /

快速应用开发模型RAD

RAD模型是瀑布模型基于构件的开发模型，通过大量使用构件快速开发，对模块化要求较高，一般适用于信息系统开发，不适用于技术风险高的产品项目。

比如不论to c或to b的产品都会有个运营管理系统，这种信息管理类系统，完全可以将组件模块化，根据实际项目需要进行组装微调，快速得到可用的信息管理系统。

快速应用开发区别于瀑布模型就是使用大量构件快速开发。

敏捷方法

由于瀑布模型周期长，且要求需求明确，难以满足快速变化的需求及短期的市场。

敏捷方法强调团队与业务需求方或专家之间紧密的联系协作，频繁迭代交付新版本，敏捷紧凑灵活可自我调整的团队。

敏捷开发基本原则：

  • 短平快会议：比如站立会议
  • 频繁迭代发布
  • 简化文档
  • 重于协作
  • 用户参与
  • 自动化测试
  • 适应性计划
  • 结对编程：是一种理想化的方式，根据其目的可以演化为互相code review（高手团队）
  • 测试驱动开发
  • 持续集成
  • 重构

敏捷开发出现很多不同的分支，比较出名的有极限编程XP，XP适用于小型或中性开发团队。

极限编程有4个价值观很值得开发团队学习：

  • 沟通
  • 简单
  • 反馈
  • 勇气

快速记忆价值观：勇于反馈，简单沟通.

极限编程还有多个值得学习的原则：

  • 快速反馈
  • 简单性假设
  • 逐步完善
  • 提倡更改
  • 高效开发
  • 小步快走

敏捷开发是一种类似最佳实践的模型，并不适合所有项目，需要的项目可以根据实际情况微调整，当然原则是理想化的指导，并不一定能完全得到贯彻执行，因此不论什么模型，我们都应该基于实际项目的需求与目的，取其精华去其糟粕，将敏捷方法与其他方法相结合，重复实践得到适合团队项目自己的开发模型。

现在不论大公司还是小公司都提倡小团队（5-7人）敏捷开发，船小顺风流，船小好调头。

统一过程UP

Unified Process 是一个通用过程框架，统一过程是由Rational公司提出的，所以也常被叫RUP，基于构件开发，有4个阶段：

  • 初始阶段：确定项目边界
  • 细化阶段：分析问题领域，建立架构
  • 构建阶段：将构件集成产品（部分构件需要再开发）
  • 交付阶段

RUP采用UML进行建模，RUP有3个特点：用例驱动、以基本架构为中心、迭代增量式开发。

其他开发模型

  • 演化模型
  • 螺旋模型
  • 喷泉模型
  • 智能模型
  • 增量模型
  • 迭代模型

软件工程生命周期

  • 问题的定义
  • 系统规划分析
    • 必要性分析
    • 可行性分析
    • 成本效益分析
    • 竞品分析
  • 需求整理与分析
    • 需求开发
    • 需求获取
    • 需求分析
    • 需求管理
  • 概要设计
    • 架构设计
  • 详细设计
    • UI设计
    • 开发设计
  • 编码与测试
  • 集成与测试
  • 运行与维护

@tsingchan 9ong.com