开发模型

开发模型

1 早期模型

1.1 瀑布模型

有重大缺陷，无法处理需求不明确的项目。

特点：

  • 严格区分阶段，每个阶段的因果紧密相连，
  • 只适用于需求明确的项目

缺点：

  • 软件需求晚自习正确性难确定
  • 要求严格串行化
  • 要很长时间才能看到结果
  • 要求每个阶段一次性完全解决该阶段工===

1.2 原型模型

主要针对需求不明确的项目，做一个简易项目来获取需求，主要用于需求阶段

一般分为2个阶段

  1. 原型开发阶段
  2. 目标软件开发阶段

1.3 V模型

测试驱动的模型

  • 测试贯穿于始终
  • 测试分阶段，测试计划提前

1.4 W模型

可以理解成V模型的变种，由两条V模型组成

测试和开发并行

1.5 增量和迭代

增量：一个一个模块完成

迭代：完成所有模块，逐步精化、

1.6 螺旋模型

以快速模型为基础+瀑布模型

考虑了风险问题

原型1通过一轮瀑布模型的开发形成原型2

原型2通过一轮瀑布模型的开发形成原型3

1.7 构件组装模型

像搭积木一样构建系统。

先开发构件，建立构件库，然后构件应用软件

优点：易拓展、易重用、降低成本、安排任务更灵活

缺点：构建设计需要经验丰富的架构师，设计不好的构件难以重用，强调重用可能会牺牲其他指标，第三方构建质量难控制

基于构件的软件工程（CBSE）

体现了 购买而不是重新构造 的哲学

特征:

  • 可组装性：所有外部交互必须通过公开定义的接口进行
  • 可部署性：构件总是二进制发布的，能作为一个独立实体在平台上运行
  • 文档化：用户根据文档来判断构件是否满足需求
  • 独立性：可以在无其他特殊构件的情况下进行组装和部署
  • 标准化：符合某种标准化的构件模型

构件包含了服务，服务是一种标准化程度更高的构件

构件的组装（借助胶水代码）：

  • 顺序组装：按顺序调用以及存在的构件，可以用两个已经存在的构件来创造一个新的构件(多个构件被轮流调用)
  • 层次组装：被调用构件的”提供”接口必须和调用构件的”请求”接口兼容（外部调用第一个构件，第一个构件调用第二个构件）
  • 叠加组装：多个构件合并形成新构建，新构件整合原构件的功能，对外提供新的接口（多个构件组装成一个新的构件，对外提供一个新的接口）

不兼容的情况

  • 参数不兼容
  • 操作不兼容
  • 操作不完备

1.8 快速应用开发模型（RAD）

用瀑布的流程，引入了**构件化的开发(**快速的原因)，以结构化的思想迅速完成系统的构件。

1.9 统一过程

  • 用例驱动
  • 以架构为中心
  • 迭代和增量

四个步骤循环迭代

  1. 初始（需求阶段）
  2. 细化（设计阶段，设计和确定系统架构）
  3. 构造（开发阶段）
  4. 移交

9个核心工作流

  1. 业务建模
  2. 需求
  3. 分析和设计
  4. 实现
  5. 测试
  6. 部署
  7. 配置和变更管理
  8. 项目管理
  9. 环境

1.10 喷泉模型

面向对象的模型，阶段区分不明显

2 敏捷方法

属于一种开发方法论，有一系列的模型

早期的开发模型会产生很多额外的压力，反而会降低开发效率。

特点：

  • 适应性的
  • 以人为本
  • 增量迭代、小步快跑
  • 适合小型项目（大型项目可以拆成多个小项目）

敏捷宣言：

  • 个体和交互胜过过程和工具
  • 可工作的软件胜过大量的文档
  • 客户合作胜过合同谈判
  • 响应变化胜过遵循计划

2.1 极限编程（XP）

近螺旋式的开发方法

4大价值观：

  • 沟通：加强面对面沟通
  • 简单：不过度设计
  • 反馈：及时反馈
  • 勇气：接受变更的勇气

12条过程实现规则（写论文可以用）

  1. 简单设计
  2. 测试驱动
  3. 代码重构
  4. 结对编程
  5. 持续集成
  6. 现场客户
  7. 发行版本小型化
  8. 系统隐喻
  9. 代码集体所有制
  10. 策略规划
  11. 规范代码
  12. 40小时工作机制

2.2 迭代式增量软件开发过程（SCRUM）

目前用的比较多，影响力较大的，侧重于项目管理

  • 由产品去对接需求，全程跟进，有一个产品待办列表（需求文档）
  • 取出一部分产品待办，形成迭代待办事项，作为这个迭代周期(1-4周)要完成的任务

2.3 其他方法

  • **水晶方法：**提倡”机动性”的方法
  • 特征驱动的开发方法（FDD）：
    • 认为软件开发需要3要素
      1. 人
      2. 过程
      3. 技术
    • 定义了6种关键的项目角色
      1. 项目经理
      2. 首席架构设计师
      3. 开发经理
      4. 主程序员
      5. 程序员
      6. 领域专家
  • 开放式源码：程序开发人员在地域上分布很广（开源项目）
  • ASD方法：核心是三个非线性、重叠的开发阶段：【猜测、合作、学习】
  • 动态系统开发方法：倡导以业务为核心

3 逆向工程

逆向工程是设计的恢复的过程

3.1 流程

先得到一个现有系统，然后从现有工程中，逆向出原来的需求，考虑新需求，结合起来做一个正向工程，就得到了新系统

  1. 现有系统
  2. 再工程
    1. 逆向工程
    2. 分析新需求
    3. 正向工程
  3. 新系统

3.2 层级

软件里的抽象层级由低到高

  • 实现级：包括程序的抽象语法树、符号表、过程的设计表示
  • 结构级：包括程序分量之间相互依赖关系的信息、如调用图、结构图、程序和数据结构
  • 功能级：包括反馈程序段功能及程序段之间的关系，如数据和控制流模型
  • 领域级：抱愧反馈程序分量或程序诸实体与应用领域概念之间对应关系的信息，如实体关系模型（需求分析）

3.3 概念

3.3.1 重构/重组

在同一抽象级别上转换系统描述形式

3.3.2 设计恢复

借助工具，从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息

3.3.3 逆向工程

分析程序，在比源代码更高抽象层此上建立程序的表示过程，逆向工程是设计的恢复过程

3.3.4 正向工程

正向工程是指不仅从现有系统中恢复设计信息，而且使用该信息去改变或者重构现有系统，以改善其整体质量

3.3.5 再工程

对现有系统的重新开发过程

包括【逆向工程、新需求的考虑、正向过程】这三个步骤

4 净室软件工程

形式化开发会涉及到

  • 净室即无尘室，指的是一个受控污染级别的环境
  • 使用盒结构规约（或形式化方法）进行分析和建模，强调将正确性验证而不是测试作为发现和消除错误的主要机制
  • 使用统计的测试来获取认证被交付软件的可靠性所必须的出错率信息

技术手段：

  • 统计过程控制下的增量开发：控制迭代
  • 基于函数的规约和设计：盒子结构
    • 定义三种抽象层次
      1. 行为视图（黑盒）
      2. 有限状态机视图（状态盒）
      3. 过程视图（明盒）
  • 正确性验证：净室软件工程的核心
  • 统计测试和软件认证：使用统计学原理，总体太大时使用抽样方法

缺点：

  • 太理论化，正确性验证的步骤比较困难且耗时
  • 不进行传统的模块测试，不现实
  • 脱胎于传统软件工程，不可避免的带有传统软件工程的一些弊端