6. 开发方法

《系统架构师》第六章 开发方法思维导图学习笔记。

软件开发方法

• 软件生命周期
  • 可行性研究和计划
  • 需求分析
  • 概要设计
  • 详细设计
  • 实现
    • 编码
    • 单元测试
  • 集成测试
  • 确认测试
  • 使用和维护
• 软件开发方法
  • 结构化法
  • 原型法
  • 面向对象方法
  • 面向服务方法
• 软件开发模型
  • 瀑布模型
    • 核心思想：
      • 软件开发阶段划分明确，每个阶段之间都有明显的界线 阶段之间会有固定的文档或者源程序
    • V模型
      • 瀑布模型中，最后的测试无法完全保证软件没有缺陷
      • 针对瀑布模型的需求分析、总体设计、详细设计，提出了系统测试、集成测试、单元测试
    • 缺点：
      • 需求分析是一切活动的基础，一旦需求存在偏差，则会发生错误
      • 难以适应变化
      • 在所有阶段都结束后才能交付软件产品
      • 产生一大堆文档，但是很多文档对用户都没有意义
  • 演化模型
    • 若干次瀑布模型的迭代 软件在这样的迭代过程只能够演化、完善
  • 螺旋模型
    • 结合了瀑布模型和演化模型
      • 需求定义
      • 风险分析
      • 工程实现
      • 评审
    • 强调风险分析，在每一个“瀑布”开发之前，引入一个非常严格的风险识别、分析和控制
    • 优点
      • 适用于庞大而复杂、具有高风险的系统
      • 支持用户需求的动态变化
    • 缺点
      • 需要丰富的风险评估经验和专业知识
      • 过多的迭代会增加开发成本
  • 增量模型
    • 策略
      • 增量发布
        • 系统技术架构成熟、风险低的时候，可以采用增量的方式进行开发，将系统划分为若干个不同的版本，每一个版本都是一个完整的系统
          • 每一个版本都是一个完整的版本
          • 版本间的增量要均匀
      • 原型法
        • 针对一般需求进行快速实现，精确获取用户需求，或者验证架构的可用性
  • 构件组装模型
    • 经过需求分析定义的软件功能后，将对构件的组装结构进行设计，将系统划分为一组构件的集合，明确构件之间的关系
    • 开发过程
      • 设计构件组装
      • 建立构件库
      • 构建应用软件
      • 测试与发布
    • 优点
      • 系统扩展性增强
      • 良好的构件更容易被重用，降低软件开发成本
      • 开发任务更加灵活，可以独立开发构件
    • 缺点
      • 需要经验丰富的架构师
      • 考虑软件重用度时，往往会对一些指标进行妥协
      • 开发人员需要熟悉构件，增加学习成本
      • 第三方构件的质量无法掌控
• 统一过程
  • 二维模型
    • UP任何一个阶段的工作都不是绝对的，都是相互配合的，但每一个阶段都有侧重点
    • 阶段
      • 初始
        • 界定系统范围、明确系统目标
          • 业务建模、需求
      • 细化
        • 分析设计
          • 抽象软件模型
          • 设计软件架构
      • 构建
        • 系统构建
          • 实施和测试
      • 交付
        • 重构、修改、测试、部署
    • UP核心工作流
      • 业务建模
      • 需求
      • 分析设计
      • 实施
      • 测试
      • 部署
      • 配置与变更管理
      • 项目管理
      • 环境
  • 生命周期
    • 目标里程碑
    • 架构里程碑
    • 能力里程碑
    • 发布里程碑
  • 特点
    • 每一个阶段都可以进行需求、设计等活动
    • 不同迭代方式的UP可以演变成演化模型或增量模型
    • 更容易控制软件开发的风险
    • UP是一个迭代的开发模型，但UP本身并不属于敏捷方法。一般认为，未经裁剪的UP是一个重载过程
    • 实际过程中可以对UP进行裁剪以适应各种规模的软件开发和团队
• 敏捷方法
  • 极限编程
    • 特点
      • 更短周期，更早的提供具体、持续的反馈信息
      • 首先迅速生成一个总体计划，然后再整个项目开发过程中不断的发展它
      • 依赖于自动测试程序监控开发进度，并及早捕获缺陷
      • 依赖于口头交流、测试和源程序进行沟通
      • 倡导持续的、演化式的设计
      • 依赖于开发团队内部的紧密协作
      • 尽可能达到程序员短期利益和项目长期利益的平衡
    • 四大价值观
      • 沟通
      • 简单
      • 反馈
      • 勇气
    • 12个最佳实践
      • 计划游戏
      • 小型发布
      • 隐喻
      • 简单设计
      • 测试先行
      • 重构
      • 结对编程
      • 集体代码所有制
      • 持续集成
      • 每周工作40小时
      • 现场客户
      • 编码标准
  • 特征驱动开发
    • 概念
      • 迭代开发模型
      • FDD每一步都强调质量，不断交付可运行的软件，并以很小的开发提供精确的项目进度报告和状态信息
      • 弱化了过程在软件开发中的地位
    • 三要素
      • 人
      • 过程
      • 技术
    • 角色定义
      • 项目经理
        • 开发组织者
      • 首席架构设计师
        • 负责系统架构的设计
      • 开发经理
        • 负责团队日常的开发
        • 解决技术问题和资源冲突
      • 主程序员
      • 程序员
      • 领域专家
        • 对业务领域精通的人，一般由客户、系统分析员等担当
    • 核心过程
      • 开发整体对象模型
        • 系统、完整的面向对象建模
      • 构造特征列表
        • 特征指细化的对客户有价值的功能
        • 采用动作、结果和目标来描述特征
      • 计划特征开发
      • 特征设计
      • 调整构建
  • scrum
    • 定义
      • 一个用于开发和维护复杂产品的框架
      • 是一个增量的、迭代的开发过程
    • 五个主要活动
      • 产品待办事项列表梳理
        • 产品待办事项范围大
        • 需求变更多
        • 优先级会变更
      • sprint计划会议
        • 会议内容
          • 在sprint中完成什么工作
            • 产品代办事项数目由开发团队决定
          • 怎么完成工作
      • 每日scrum会议
        • 上一日完成了什么
        • 今日计划完成什么
        • 有什么困难
      • sprint评审会议
        • sprint结束时，scrum团队和相关人员一起评审sprint的产出
        • 展示当前产品增量的概况
      • sprint回顾会议
        • sprint结束后，scrum团队会聚在一起开sprint回顾会议 回顾团队在流程人机关系及工具方面做得如何
          • 什么做得好
          • 找出潜在的改进事项，为将来改进制定计划
  • 水晶方法
    • 透明水晶
      • 经常交付
      • 反思改进
      • 渗透式交流
        • 子主题
      • 个人安全
        • 指出问题时不会受到报复
      • 焦点
        • 明确首先做什么，然后安排时间，以平很好的心态开展工作
      • 与专家用户建立方便的联系
      • 配有自动测试、配置管理和经常集成功能的技术环境
  • 开放式源码
    • 程序开发人员在地域上分布很广
    • 查错排障的高度并行性
  • ASD（adaptive software development）
    • 三个非线性、重叠的开发阶段
      • 猜测
      • 合作
      • 学习
• 软件重用
  • 源码重用
  • 架构重用
  • 应用框架重用
  • 业务建模的重用
  • 文档及过程重用
  • 软件服务的重用
• 基于架构的软件设计 ABSD
  • 基础
    • 功能分解
      • 使用已有的基于模块的内聚和耦合技术
    • 通过选择架构风格来实现质量和业务需求
    • 软件模板的使用
  • 过程
    • 需求分析
    • ABSD方法
    • 实际构件设计
  • 基于架构的软件开发模型
    • 过程
      • 需求
        • 需求获取
        • 标识构件
          • 生成类图
          • 对类进行分组
          • 把类打包成构件
        • 需求评审
      • 设计
        • 提出架构模型
        • 映射构件
          • 把在架构需求阶段标识的构件映射到架构中
        • 分析构件相互作用
        • 产生架构
        • 设计评审
      • 文档化
      • 复审
      • 实现
      • 演化
        • 需求变动归类
        • 制定架构演化设计
        • 修改、增加或删除构件
        • 更新构件的相互作用
        • 构件组装与测试
        • 技术评审
        • 产生演化后的架构
• 形式化方法