团队需求开发是如何进行的？
- 需求开发 – 需求获得 – 需求汇总 – 需求验证
- 需求是一切工程活动的基础
- 客户需求 ：这个客户他需要解决什么样的问题（平台的限制，法规法律的限制等）
- 产品需求 ： 解决这个问题的解决方案
团队设计应当如何组织？
- 团队设计面向整体开发，因此需要考虑如下：
- 团队智慧的使用
- 设计标准
- 复用性支持
- 复用方法的是时候，只需要看说明性的文字。所以复用文档应该用标准化的方式描述清晰
- 可测试性支持
- TDD ：帮助开发质量提升，开发质量的一种手段。事实上，团队感受到质量的提升是因为他一开始的时候单元测试做的太差。这个提升不是真正的提升，是一个改正了原来的差的地方
- TDD的结论是”它不能提升质量，但是对软件系统的设计有显著的帮助”, 因为”可测试”是设计的质量某一个属性
- 可用性支持
- 针对每一个关键功能都定义操作概念和操作场景
团队实现有哪些策略需要注意？
- 设计的策略 - 自顶向下
- 开发的策略 - 自底向上
- 因为评审的角度来说，限制范围更好
- 自顶向下实现的方式找到复用的机会小
- 从可测试性的角度来考虑，希望尽可能的已经完成的具体功能，然后去做测试
团队集成策略
- 产品集成 ： 已经开发好的代码放在一起
- 大爆炸集成策略
- 已经做好了20个模块，把这20个模块放在一起，做一次集成，做一轮测试
- 好处 ：如果每一个组件质量都非常好的话，非常经济，快速，有效的手段
- 缺点 ：如果质量不那么好的情况下用大爆炸，定位缺陷通常会非常困难
- 逐一添加（Step by Step）集成策略
- 假设有20个模块（编号1～20）。第一次，只测1号模块。测完了之后，把2号模块加进来，再做一次测试。继续这样做 ，，，那么一号模块被测了20遍
- 好处 ：查找定位错误通常会比较快
- 缺点 ：测试太多，经济性不够理想 👉 为了解决这个问题有一种技术 ：持续集成（CI）
- 持续集成 ： 把单元测试的测试用例跟原来的用例并起来，然后做自动化测试
- 持续集成建立的假设是它可以自动化。如果持续集成集成完了之后，还是要人工的去测试，持续集成不能解决测试大的问题
- 注意 ：功能测试不能用自动化
- 所以持续集成只是解决一部分测试的要求（原来的单元测试）
- CI技术的引入仅仅是在逐一添加集成策略上面，一定程度下降低了测试代价，用一些自动化手段。
- 集簇（Cluster）集成策略
- 有关系紧密的一个一个的模块集成为更大的模块。最后变成一个系统
- 我们把相互之间有关联的小的模块先放在一起集成，集成就成为大的模块。有关系紧密的一个一个大的模块再进一步再集成为更大的模块。最后变成一个系统。
- 好处 ： 可以尽早获得一些可以工作的组件，有利于其他组件测试工作的开展
- 缺点 ：过于关注个别组件，而缺乏系统的整体观，不能尽早发现系统级的缺陷
- 特征 ：自底向上，它是为了改进逐一添加策略
- 扁平化集成策略
- 要求尽快构建一个可以工作的扁平化系统。也就是说，优先集成高层的部件，然后逐步将各个组件、模块的真正实现加入系统
- 首先打“桩”（stub）比如说返回固定的返回值，然后打桩的东西真实的模块去替代。所以不是自底向上一层一层的概念
- 好处 ：这种方式可以尽早发现系统级的缺陷
- 缺点 ：因为使用的固定的返回值，都限制了整个系统描述它真实行为的能力，因此对于系统的错误发现能力其实是不够的（该策略的缺陷是为了确保完成的系统，需要大量的打“桩”（stub），这种方式往往不能覆盖整个系统应该处理的多种状态）
- 实际的集成的时候通常是多种策略的混合。这种多种策略的混合怎么去体现呢？– 体现在集成计划
- 集成计划描述了打算怎么样来完成。比如我们发现PQI指标都非常好，可能应该选择大爆炸集成策略。如果PQI看起来接近0了，可能要考虑换一个方式
V&V : 验证(Verification) 🆚 确认(Validation)
- 严格来说两个目的不同
- 验证指的是你的解决方案有没有被你正确的实现出来。(针对产品需求)
- 确认指的是客户想要解决的方案解决了没有，解决了怎么样。(针对客户需求)
- 单元测试，集成测试大部分情况下都是属于“验证”
- 验收测试，需求验证在大部分场景下是“确认”
- 另一方面，验证和确认又是相互依存、关系紧密的两个活动
验证与确认活动
- 环境准备 - 对象选择 - 活动实施 - 结果分析
- 通常对于工作产品一般叫开着活动叫“验证”。对于产品，必须要“确认”活动
《Reference》
- 2020年(秋) 软件质量与管理 : 荣国平