码迷,mamicode.com
首页 > 其他好文 > 详细

第二十九章 集成

时间:2019-09-28 12:46:41      阅读:88      评论:0      收藏:0      [点我收藏+]

标签:有用   同步   软件开发   形式   工作   系统   顺序   接口   开发人员   

集成是指一种软件开发行为:将一些独立的软件组合为一个完整系统。

集成方式的重要性

从周到的继承中,你能预期获得某些下列的益处:

  • 更容易诊断缺陷;
  • 缺陷更少;
  • 脚手架更少;
  • 花费更少的时间获得第一个能工作的产品;
  • 更短的整体开发进度表;
  • 更好的顾客关系;
  • 增强士气;
  • 增加项目完成的机会;
  • 更可靠地估计进度表;
  • 更准确的现状报告;
  • 改善代码的质量;
  • 较少的文档。

集成频率——阶段式集成还是增量集成

阶段式集成

它遵循下列明确的步骤:

  1. 设计、编码、测试、调试各个类。这一步称为单元开发;
  2. 将这些类组合为一个庞大的系统;
  3. 测试并调试整个系统。这称为系统瓦解。

增量集成

增量集成遵循以下步骤:

  1. 开发一个小的系统功能部件;
  2. 设计、编码、测试、调试某个类;
  3. 将这个新的类集成到系统骨架上。测试并调试骨架和新类的结合体,在进一步添加任何新类前,确保该结合体能工作。如果做完了剩余的所有工作,就回到步骤2开始重复这一过程。

增量集成的益处

  • 易于定位错误;
  • 及早在项目里取得系统级的成果;
  • 改善对进度的监控;
  • 改善客户关系;
  • 更加充分地测试系统中各个单元;
  • 能在更短的开发进度计划内建造出整个系统。

增量继承的策略

  • 自顶向下集成;
  • 自底向上集成;
  • 三明治集成;
  • 风险导向的集成;
  • 功能导向的集成;
  • T型集成;

Daily Build与冒烟测试

  • 每日构建;
  • 检查失败的build;
  • 每天进行冒烟测试;
  • 让冒烟测试与时俱进;
  • 将daily build和冒烟测试自动化;
  • 成立build小组;
  • 仅当有意义时,才将修订加入build中,但是别等太久;
  • 要求开发人员在把他的代码添加到系统之前,进行冒烟测试;
  • 为即将添加到build的代码准备一块暂存区;
  • 惩罚破话build的人;
  • 在早上发布build;
  • 即使有压力,也要进行daily build和冒烟测试。

核对表:集成

集成策略

  • [ ] 该策略是否指明了集成子系统、类、子程序时应该采用的最优顺序?
  • [ ] 集成的顺序是否与构建顺序协调,以便在适当的时候准备好供集成的类?
  • [ ] 该策略是否易于诊断缺陷?
  • [ ] 该策略是否使脚手架最少?
  • [ ] 所选的策略是否好于其他方式?
  • [ ] 组件之间的接口是否有明确定义?

daily build与冒烟测试

  • [ ] 项目是否经常build——理想情况下,每天build一次——以支持增量集成?
  • [ ] 每次build之后是否都支持冒烟测试,让你直到这个build能否工作?
  • [ ] 你是否以使build和冒烟测试自动进行?
  • [ ] 开发人员是否频繁地check in他们的代码——两次check in之间最多间隔一两天?
  • [ ] 冒烟测试是否与代码同步更新,随代码发展而发展?
  • [ ] 破坏build是汉奸的事件吗?
  • [ ] 是否在有压力的情况下,也对软件进行build和冒烟测试?

要点

  • 构建的先后次序和集成的步骤会影响设计、编码、测试各类的顺序;
  • 一个经过充分思考的集成顺序能减少测试的工作量,并使调试变得容易;
  • 增量继承有若干变型,而且——除非项目微不足道的——任何一种形式的增量集成都比阶段式集成好;
  • 针对每个特定的项目,最佳的集成方式通常是自顶向下、自底向上、风险导向及其他集成方法的某种组合;
  • daily build能减少集成问题,提升开发人员的士气,并提供非常有用的项目管理信息。

第二十九章 集成

标签:有用   同步   软件开发   形式   工作   系统   顺序   接口   开发人员   

原文地址:https://www.cnblogs.com/liam-ji/p/11602397.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!