系统架构师：软件工程

1. GB8566-88（《软件工程国家标准——计算机软件开发规范》）中将软件生命周期划分为8个阶段：

　　1. 可行性研究与计划

• • 确定开发此软件的必要性
  • 确定软件的目标、范围、风险、开发成本
  • 制定出初步的软件开发计划

　　2. 需求分析（重要阶段）

• • 对软件需求进行细致的分析，确定软件要做成什么样

　　3. 概要设计（技术蓝图）

• • 将需求分析的结果转化为技术层面的方案
  • 确定系统架构
  • 各子系统间的关系
  • 接口规约
  • 数据库模型
  • 编码规范

　　4. 详细设计（非必需）

• • 在概要设计的基础上细化，如 类设计

　　5. 实现

• • 编码
  • 单元测试

　　6. 集成测试（组装测试）

• • 指定集成测试计划

　　7. 确认测试

• • 验证软件是否同需求一致
  • 验证是否达到了预期目标

　　8. 使用和维护

• • 软件维护过程贯穿整个软件使用过程

 

2. 软件开发模型

　　1. 瀑布模型

• • 像瀑布一样，从一个特定阶段流向下一个阶段
  • 阶段划分明确，一个阶段到下一个阶段有明显的界限
  • 每个阶段都有回到前一个阶段的反馈线
    • 在后续阶段发现缺陷时，可以把这个缺点反馈到上一个阶段进行修正
  • 面向文档的软件开发模型
    • 每个阶段结束后，都会有固定的文档或源程序流入下一个阶段
  • 适用：需求明确、稳定
  • 瀑布V模型：每个分析设计阶段都有对应的测试阶段，更强调了测试。
  • 瀑布模型缺陷：
    • 以需求分析的结果为导向，一旦需求分析存在偏差，就会越走越远
    • 软件后期出现需求变化，又要重新开始；所有阶段结束才能交付产品
    • 过程中产生了大量耗费人力且对客户无用的文档

　　2. 演化模型

• • 一个演化模型可以看做若干次瀑布模型的迭代
  • 根据不同的迭代特点，演化模型可以演变为螺旋模型、增量模型和原型法开发

　　3. 螺旋模型

• • 螺旋模型的每一周期包括风险识别、风险分析、风险控制、需求定义、工程实现、评审
  • 支持用户需求的动态变化
  • 适用：庞大而复杂、具有高风险的系统
  • 缺点：
    • 需要丰富的风险评估经验和专业知识，若未能及时标识风险，势必造成重大损失
    • 过多的迭代次数增加开发成本，延迟提交时间

　　4. 增量模型

• • 每一个版本都是一个完整的版本
  • 版本间的增量要均匀
  • 适用：技术架构纯熟、风险较低

　　5. 原型法

• • 每一次迭代都经过一个完整的生命周期
  • 初始原型比较简单，目的在于获得精确的用户需求，验证架构可用性。一般会在后面开发中抛弃原型，重新实现完整系统。

　　6. 构建组装模型

• • 将系统划分成一组构件的集合，明确构件之间的关系
  • 架构的开发是独立的，构件之间通过接口相互协作
  • 开发过程：设计构件组装 ——> 建立构件库 ——> 构建应用软件 ——> 测试与发布
  • 优点：
    • 系统更容易扩展
    • 良好的构建更容易重用
    • 能够并行的独立开发构件
  • 缺点：
    • 考虑重用度时可能性能会做出让步
    • 增加了研发人员学习成本
    • 第三方构件库的质量难以掌握

 

3. 统一过程 Unified Process UP（以架构为中心）

• 横轴表示迭代阶段，纵轴表示9个核心工作流。工作流贯穿每个阶段，但每个阶段各有侧重点。
• 9个核心工作流：
  • 工程活动
    • 业务建模
    • 需求
    • 分析设计
    • 实施
    • 测试
    • 部署
  • 管理活动
    • 配置与变更管理
    • 项目管理
    • 环境
• 生命周期4个里程碑
  • 目标里程碑：开发者明确软件系统的目标和范围
  • 架构里程碑：稳定的系统架构
  • 能力里程碑：系统足够稳定成熟并完成Alpha测试
  • 发布里程碑：已完成系统测试、系统发布、用户培训

 

4. 敏捷方法

　　1. 极限编程  XP （价值观+原则+实践+行为）

• • 四大价值观
    • 沟通：面对面交流
    • 简单：够用即好
    • 反馈：通过持续、明确的反馈来暴露软件状态的问题
    • 勇气：有勇气面对快速开发，可能重新开发
  • 12个最佳实践
    • 计划游戏：快速制定一份概要计划，逐步完善
    • 小型发布：持续集成，小步快走
    • 隐喻：寻求共识、发明共享词汇、创新的武器、描述架构
    • 简单设计
    • 测试先行
    • 重构：目的在于降低变化引发的风险，使得代码优化更容易
    • 结对编程
    • 集体代码所有制
    • 持续集成：是基本支撑条件
    • 每周工作40小时
    • 现场客户
    • 编码标准

　　2. 特征驱动开发  FDD

• • 三要素
    • 人：角色定义
      • 项目经理：组织者，努力为团队提供一个适宜的开发环境
      • 首席架构设计师：负责系统架构的设计
      • 开发经理：负责团队日常开发，解决技术问题与资源冲突
      • 主程序员：带领小组完成特征的详细设计和构建工作
      • 程序员：分开发小组，按照特征开发计划完成开发
      • 领域专家：一般由客户、系统分析员担任
    • 过程：核心过程
      • 开发整体对象模型：系统地完整地面向对象建模（领域专家+首席架构设计师）
      • 构造特征列表
        • 特征：小的、对客户有价值的功能
        • 描述：动作、结果、目标
        • 粒度：两周之内实现
      • 计划特征开发：根据特征列表、特征间依赖关系进行计划、安排开发任务（项目经理）
      • 特征设计：特征小组对特征进行详细设计（主程序员）
      • 特征构建
    • 技术：最佳实践
      • 领域对象建模
      • 根据特征进行开发
      • 类的个体所有：自己维护自己开发的代码
      • 组成特征小组
      • 审查
      • 定期构造
      • 配置管理
      • 结果的可见性

 　　3. Scrum

• • Backlog：按照商业价值排序的需求列表，通常用用户故事来体现
  • Sprint：一个短的迭代周期成为一个Sprint，建议2-4周
  • Scrum团队总是优先开发对客户具有较高价值的需求
  • 5个活动
    • 产品待办事项列表梳理：始终贯穿整个Scrum项目，特别关注即将被实现的事项。
    • Sprint计划会议
      • 决定在Sprint中需要完成哪些工作
      • 决定这些工作如何完成
      • 产出：Sprint Backlog 待办事项列表
    • 每日Scrum会议
      • 上一个每日会议到现在我完成了什么
      • 现在到下一个计划完成什么
      • 有什么阻碍了我的进展
    • Sprint评审会议：围绕完成的产品增量
    • Sprint回顾会议：回顾团队在流程人际关系及工具方面做的如何
  • 5大价值观
    • 承诺
    • 专注
    • 开放
    • 尊重
    • 勇气

　　4. 水晶方法

• • 七大体系特征
    • 经常交付
    • 反思改进
    • 渗透式交流
    • 个人安全
    • 焦点
    • 与专家用户建立方便的联系
    • 配有自动测试、配置管理和经常集成功能的技术环境

　　5. 开放式源码：开发人员地域分布广

　　6. ASD：猜测、合作、学习

 

5. 软件重用

• 软件重用
  • 源代码重用
  • 架构重用
  • 应用框架的重用
  • 业务建模的重用
  • 文档及过程的重用
  • 软构件的重用
  • 软件服务的重用
• 构件技术
  • 构件是一个程序集
  • 构建外部只能通过接口来访问构件
  • 特性
    • 自包容：构件本身是一个功能完整的独立体，可独立配置与使用
    • 可重用：是构件出现的目的
  • 应用
    • CORBA
    • Java Bean/EJB
    • COM/DCOM

 

6. 基于架构的软件设计  ABSD

• 生命周期

 

 

Mccabe方法计算流程图的环形复杂度

V(G) = E - N + 2

E：边数

N：定点数

 

2. RUP(Rational Unified Process)

9个核心工作流：

• 6个核心过程工作流
  • 商业建模：
  • 需求：
  • 分析和设计：
  • 实现：
  • 测试：
  • 部署：
• 3个核心支持工作流
  • 配置和变更管理：
  • 项目管理：
  • 环境：向软件开发组织提供软件开发环境，包括过程和工具。