2021-软件质量管理-Lec-6 团队工程开发

Lec-6 团队工程开发

1. 本讲要解决的问题

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

2. 需求开发

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

2.1. 需求获取

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

2.2. 需求汇总

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

2.3. 需求验证

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

2.4. 需求文档制作

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

2.5. 优秀需求规格文档特征

看PPT备注

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

2.6. SRS示例

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

3. 团队设计

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

3.1. 团队智慧

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

3.2. 设计标准

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

3.3. 复用性支持

1. 在设计阶段必须要充分考虑复用的可能。为了支持复用，软件项目团队需要建立一套复用管理流程，具体而言，包括
   1. 复用接口标准
   2. 复用文档标准
   3. 复用质量保证机制
2. 什么时候考虑复用

3.4. 可测试性考虑

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

3.5. 可用性考虑

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

3.6. 设计的文档化

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

4. 实现策略

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

5. 集成策略

1. 大爆炸集成策略
2. 逐一添加集成策略
3. 集簇集成策略
4. 扁平化集成策略

6. 验证与确认

1. 验证(Verification)和确认(Validation)都是为了提升最终产品的质量而采取的措施。
2. 验证和确认的目的不同。
   1. 验证是目的是确保选定的工作产品与事先指定给该工作产品的需求一致。
   2. 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确。
3. 例子：
   1. 单元测试：验证
   2. 集成：验证
   3. 需求评审：确认
   4. 验收测试：确认
4. 验证与确认活动
   1. 环境准备
   2. 对象选择
   3. 活动实施
   4. 结果分析