06-团队工程开发

1. 需求开发

1.1. 为什么“需求是一切工程活动的基础”

1. 设计活动一定是依据需求而开展的
2. 产品集成活动中，各个组件之间的接口也必须事先满足接口需求，否则会造成接口不匹配
   1. 验证活动是检验产品和产品组件是否满足事先定义的需求规格
   2. 确认活动是确保产品可以满足用户需求和实际场景的要求
3. 需求也是项目计划活动的关键输入，如规模估算、成本估算等必须参考需求

1.2. 需求分类

1. 客户需求：问题，描述的是客户的期望，是客户解决问题的愿望
2. 产品需求：答案，描述的是开发团队所提供的解决方案

1.3. 需求开发过程

1. 需求获取：采用诱导方式获取客户的隐式需求和显式需求，尽可能识别客户的期望与受到的限制
2. 需求汇总：整理各个来源的信息，识别缺失的信息，解决冲突的信息
   1. 需求转化和整理：客户需求->产品需求，产品组件需求
   2. 推导未显式描述的需求内容，例如使用某项技术的附属需求
3. 需求验证：对需求进行分析和确认，保证符合使用者的预期
   1. 建立相关场景
   2. 分析需求，保证必要性、充分性和正确性
   3. 确认需求，在客户环境正常运行
4. 制作需求文档
   1. 需求规格文档目的：用户和开发者对软件的初始规定有一个共同理解，使之成为整个开发工作的基础

2. 团队智慧/设计

2.1. 团队智慧挑战

• 挑战
  • 确定整体架构之前很难进行分工
  • 鼓励团队成员在讨论和评审会议中的参与程度

2.2. 设计考虑点

2.2.1. 设计标准

• 命名规范：项目小组应当设计一个统一的命名规范来命令各个模块并建立系统词典
• 接口标准：组件之间的接口标准和格式也需要作为设计标准的内容之一加以定义
• 系统出错信息：标准化
• 设计表示标准：定义设计工作产物应当满足的标准

2.2.2. 复用性考虑

• 复用接口标准
• 复用文档标准
• 复用质量保证机制

2.2.3. 可测试性的考虑

TDD提高的是设计。先写测试脚本再写代码让开发人员对测试脚本更认真。

• 尽可能减少测试代码的数量
• 制定合理的测试计划

2.2.4. 可用性的考虑

• 设计阶段就开始考虑，而不是推迟到实现阶段
• 针对每一个关键功能都定义关键概念和操作场景
• 分析操作场景以确保软件系统开发完成之后，系统使用者会满意
• 必要时，要求最终用户参与场景的评审，使用模拟、原型等技术，更好把握用户真实意图

2.3. 实现策略

2.3.1. 评审的考虑

1. 设计时采用的策略是自顶向下，逐层精化，有利于建立系统的整体观
2. 实现的时候为了方便实现对结果的评审，建议自底向上，首先实现底层的内容，然后对底层模块评审，有利于复用策略的应用

2.3.2. 复用策略

采用自底向上的开发策略利于复用。

• 经典复用策略
  1. 编码注释： 注释使用统一格式，标明功能、调用方式、异常信息等，利于复用
  2. 站立式会议：团队讨论实现计划，识别可复用组件，了解现有的复用组件库内容

2.3.3. 可测试性考虑

实现计划必须与测试计划一致，不能出现集体测试时还有模块未实现的情况

3. 集成的策略选择

经典定义：把各种组件拼装到一起，测试，一直管到交付

CICD属于逐一添加
鼓励开发人员频繁提交代码，每次提交后都进行自动化测试，有助于发现和修复问题

3.1. 大爆炸集成策略

• 把一堆待继承的组件放在一起，进行一次集成
• 优点：如果组件质量很高，一次集成代价低，需要的测试用例少
• 缺点：如果质量不高，定位问题困难

3.2. 逐一添加策略

• 一次添加一个组件进行集成
• 优点：容易定位问题
• 缺点：测试代价高，需要的测试用例最多

3.3. 集簇集成策略

• 把有相似功能或者有关联的模块优先进行集成，形成可以工作的组件。然后以组件为单位继续较高层次的集成
• 优点：可以尽早获得一些可以工作的组件，有利于其他组件测试工作的开展。
• 缺点：过于关注个别组件，而缺乏系统的整体观，不能尽早发现系统层面的缺陷。

3.4. 扁平化集成策略

• 优先集成高层组件的部件，其他先打桩，然后逐步将各个组件、模块真正的是实现加入系统。打“桩”（stub），即提供一些直接提供返回值的伪实现
• 优点：提前暴露系统级错误，快速把系统跑起来
• 缺点：需要大量打桩；对系统行为的描述很有限，发现错误能力有限

4. 验证和确认(V & V)

4.1. 定义

• 验证（Verification）：产品需求有没有被满足，解决方案有没有被正确地做出来
• 确认（Validation）：客户需求有没有得到解决，问题有没有解决

普遍认为需求评审、验收测试是Validation，单元测试、集成、系统测试是Verification
但是ver和val贯穿始终，都是提高最终产品策略的措施

4.2. 活动

评审
测试

1. 环境准备
2. 对象选择
3. 活动实施
4. 结果分析