软件质量管理-06-团队工程开发

本文主要内容来自 SpriCoder 的博客，更换了更清晰的图片并根据新的课程设计做了补充和修正。

本讲要解决的问题

1. 团队需求开发是如何进行的？
2. 团队设计应当如何组织？
3. 团队实现有哪些策略需要注意？
4. 团队集成有哪些策略？
5. 验证和确认在开发工作中如何应用？

【2014】【2015B】需求开发

1. 需求是一切工程活动的基础。
2. 需求类别
   1. 客户需求：靠近问题一侧
   2. 产品需求：靠近解决域一侧
   3. 产品组件需求

需求获取

1. 客户所受到的限制也应当作为需求开发过程中需要重点关注的内容。
2. 通常采取所谓的需求“诱导”方式进行。
3. “诱导”一词的含义不仅仅是普通的需求采集，它隐含了应更加积极地、前瞻性地识别那些客户没有明确提供的额外需求。

需求汇总

1. 整理各种来源的信息，识别缺失的信息
2. 解决冲突的需求
3. 需求的整理和转化
4. 推导未显式描述的需求内容

需求验证

1. 对需求进行分析和确认，以确保符合使用者预期
2. 典型活动包括
   1. 建立和维护操作概念和相关的场景
   2. 分析需求
   3. 确认需求

需求文档制作

1. 需求开发工作完成的一个基本标志是形成了一份完整的、规范的、经过评审的需求规格说明书。
2. 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。

优秀需求规格文档特征

1. 内聚特征
2. 完整特征
3. 一致特征
4. 原子特征
5. 可跟踪特征
6. 非过期特征
7. 可行性特征
8. 非二义性特征
9. 强制特征
10. 可验证特征

SRS 示例

1. 引言
2. 系统定义
3. 应用环境
4. 功能规格
5. 性能需求
6. 实现约束
7. 质量描述
8. 其它要求
9. 参考材料
10. 签字认证

团队设计

1. 设计过程与 PSP 基本一致
2. 团队设计面向整体开发，因此需要额外考虑如下内容：
   1. 团队智慧的使用
   2. 设计标准
   3. 设计复用
   4. 设计的可测试性支持
   5. 设计的可用性支持等要求

团队智慧

发挥团队智慧两大挑战：

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

设计标准

1. 命名规范
2. 接口标准
3. 系统出错信息：标准化测试的好处：方便定位错误
4. 设计表示标准

复用性支持

在设计阶段必须要充分考虑复用的可能。为了支持复用，软件项目团队需要建立一套复用管理流程，具体而言，包括：

1. 复用接口标准
2. 复用文档标准
3. 复用质量保证机制

什么时候考虑复用。

可测试性考虑

设计可测试性考虑主要体现在两方面：一是要尽可能减少测试代码的数量；二是要制作合理的测试计划。

可用性考虑

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

设计的文档化

1. 引言
2. 设计文档目的
3. 问题陈述
4. 团队信息
5. 高层设计
   1. 系统架构
   2. 组件分配表
   3. 功能规格说明
   4. 操作场景
   5. 各个模块工作方式的伪码描述
   6. 用户界面
6. 详细设计
   1. 状态机设
   2. 模块内部工作方式的伪码描述
7. 限制条件
   1. 标准兼容
   2. 硬件限制
   3. 开发限制
8. 参考材料

实现策略

1. 评审的考虑
2. 复用策略
3. 可测试性考虑

【2013】【2015A】【2014】集成策略

大爆炸集成策略

1. 定义：将所有已经完成的组件放在一起进行一次集成
2. 优点：需要很少的测试用例
3. 缺点：需要所有有待集成的组件质量非常高，否则会出现难以定位缺陷位置的问题，从而消耗很多测试时间；另外，系统越复杂，规模越大，问题越突出

逐一添加集成策略

1. 与大爆炸集成策略相反，采取一次添加一个组件的方式进行集成
2. 优点：很容易定位缺陷位置，特别是在产品组件质量不高的情况下，每次集成之前都有着坚实的质量基础
3. 缺点：需要测试用例非常多；存在有大量的回归测试，测试时间成本大

集簇集成策略

1. 定义：是对逐一添加集成策略的改进，把有相似功能或者有关联的模块优先进行集成，形成可以工作的组件，然后以组件为单位继续较高层次的集成
2. 优点：可以尽早获得一些可以工作的组件，有利于其它组件测试工作的开展
3. 缺点：过于关注个别组件，而缺乏系统的整体观，不能尽早发现系统层面的缺陷

扁平化集成策略

1. 定义：优先集成高层的部件，然后逐步将各个组件、模块的真正实现加入系统。即尽快构建一个可以工作的扁平化系统
2. 优点：可以尽早发现系统层面的缺陷
3. 缺点：为了确保完成的系统，需要大量的打“桩”（stub），即提供一些直接提供返回值的伪实现。这种方式往往不能覆盖整个系统应该处理的多种状态

【2015B】【2014】验证与确认

验证（Verification）和确认（Validation）都是为了提升最终产品的质量而采取的措施。

验证和确认的目的不同：

1. 验证是目的是确保选定的工作产品与事先指定给该工作产品的需求一致，确保解系统内部的一致性；
2. 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确，确保问题域和解系统的一致性。

验证和确认的目的不同，前者关注的是产品需求是否得到体现、从这个产品需求（即解决方案）设计出来，一直到解决方案的开发完成，整个过程当中有没有偏、解决方案有没有被正确地实现出来；后者更多关注的是你的这个客户需求有没有得到满足，简单来说就是客户期望解决的问题，有没有被解决。

——荣老师复习课

例子：

1. 单元测试：验证
2. 集成：验证
3. 需求评审：确认
4. 验收测试：确认

验证与确认活动

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