软件质量工程 10

NASA 的 CMM 实践

• NASA 软件分类 (NASA Software Classification):
  • Class A: 载人航天软件系统 (Space Flight Human Rated Software Systems)
  • Class B: 非载人航天软件系统 (Non-Human Space Rated Software Systems)
  • Class C: 任务支持软件与设施 (Mission Support Software & Facilities)
  • Class D: 分析与分发软件 (Analysis and Distribution Software)
  • Class E: 开发支持软件 (Development Support Software)
  • Class F-H: 通用计算软件，分别适用于多中心、多项目、单中心或桌面环境 (General Purpose Computing Software)
• NASA 软件工程要求 (NASA Software Engineering Requirements, NPR 7150.2A):
  • 软件工程是 NASA 任务和基础设施的核心能力 (Software engineering is a core capability and a key enabling technology)
  • 提供软件获取、开发、维护、退役、操作和管理的最低要求 (A minimal set of requirements for software acquisition, development, maintenance, retirement, operations, and management)
  • CMMI 要求 (CMMI Requirements):
    • Class A 软件: 需达到 CMMI-DEV 成熟度 3 级或以上 (CMMI-DEV Maturity Level 3 Rating or higher)
    • Class B 软件: 需达到 CMMI-DEV 成熟度 2 级或以上，覆盖以下流程领域 (CMMI-DEV Maturity Level 2 Rating or higher in specific process areas):
      • 需求管理 (Requirements Management)
      • 配置管理 (Configuration Management)
      • 流程与产品质量保证 (Process and Product Quality Assurance)
      • 测量与分析 (Measurement and Analysis)
      • 项目规划 (Project Planning)
      • 项目监控 (Project Monitoring and Control)
      • 供应商协议管理 (Supplier Agreement Management, if applicable)
    • Class C 软件: 由中心或项目定义具体要求 (Defined per Center or project requirements)
  • 注意事项:
    • 组织需保持有效的 CMMI 评级，定期重新评估 (Organizations must maintain an active CMMI appraisal rating posted on the SEI website)
    • Class A 软件开发组织可通过 NASA 批准的改进计划获得过渡期 (A transition period is allowed for organizations developing Class A software)
    • Class B 软件可通过评估替代 CMMI 评级 (An evaluation by a qualified evaluator can be conducted if the provider lacks the required CMMI rating)

NASA 的 CMM/CMMI 经验教训

• 关键经验:
  • 评估准备: 准备 CMMI 评估是获得可衡量改进的关键 (Preparing for an appraisal drives measurable process improvement)
  • 工具集: 开发模板和工具集加速项目合规性 (An extensive set of tools helps projects reach compliance faster)
  • 导师支持: 导师协助项目定制流程和工件 (Mentors help tailor artifacts and initiate tool use)
  • 管理支持: 跨部门赞助和高层管理支持至关重要 (Sponsorship across departments and a Management Steering Group are critical)
  • 数据管理: 集中存储 PIID 和工件便于访问和审查 (Maintaining PIIDs and artifacts on a server for ease of access)
• 挑战:
  • 中层管理者难以“拥有”改进计划 (Mid-level managers struggle to own the improvement program)
  • 测量与分析是重大挑战 (Measurement and analysis is a big challenge)
  • 小型项目需要轻量级流程以避免负担过重 (Smaller projects need lightweight processes to avoid being overwhelmed)
• 影响:
  • 降低风险: 提高任务安全性，减少软件失败 (Reduces risk of software failure and increases mission safety)
  • 改进成本估算: 项目在 CMMI 框架下成本估算更准确，资源增长较少 (Increased accuracy in cost estimates and smaller resource growth)
  • 提升质量: 更早发现和移除缺陷 (More defects found and removed earlier)
  • 统一管理: 改善计划、审查、测试计划和状态报告的统一性 (More uniformity in management plans, reviews, test plans, status reporting)
  • 文化变革: 建立广泛的指导计划，显著提升软件工程社区的知识和技能 (Significant cultural changes and improved knowledge and skills)

敏捷与 CMM 的混合模型

• 问题: 敏捷与 CMM 能否在安全关键软件环境中共存？ (Can Agile and CMM co-exist in a safety-critical software context?)
• 关键考虑因素:
  • 流程控制: 敏捷提供更多适应客户需求的灵活性，CMM 则强调严格的流程控制 (Agile offers more control to adapt to customer requirements, while CMM follows rigorous documentation)
  • 文档要求: 敏捷仅在必要时记录，CMM 要求全面文档 (Agile has minimal documentation, CMM requires rigorous documentation)
  • 项目结构: 敏捷采用持续对话和小型发布，CMM 在项目初期定义结构 (Agile uses constant dialogue and small releases, CMM defines structure at the start)
  • 开发实践: 敏捷强调简单设计、持续重构、结对编程和持续集成，CMM 则较少采用这些实践 (Agile emphasizes simple design, constant refactoring, pair programming, and continuous integration)
• 比较表:

敏捷开发设计周

• 敏捷开发总结:

  • 短增量开发: 每周完成一个增量 (Develop in short increments, completed in one week)
  • 用户与开发者协作: 共同定义需求和反馈 (Users and developers work together)
  • 最小化文档: 仅包括源代码文档和用户文档 (Minimal documentation: source code and user documentation at the end of the week)
  • 测试驱动开发: 包括单元测试和集成测试，确保代码在周末可工作 (Test-driven development with unit and integration testing)
  • 结对编程: 提高代码质量 (Pair programming)
  • 用户演示: 周末向用户展示成果并收集反馈 (Demonstrate to users/customers)

• 示例敏捷周计划:

gantt
    title 示例敏捷开发周 (Sample Agile Week)
    dateFormat  YYYY-MM-DD
    section 周一 (Monday)
    需求会议、计划、软件结构、测试计划 :a1, 2025-06-02, 3.5h
    开始编码 :a2, after a1, 3.5h
    section 周二 (Tuesday)
    会议 :b1, 2025-06-03, 1h
    编程 :b2, after b1, 2.5h
    测试代码 :b3, after b2, 3.5h
    section 周三 (Wednesday)
    会议 :c1, 2025-06-04, 1h
    编程 :c2, after c1, 2.5h
    测试代码 :c3, after c2, 3.5h
    section 周四 (Thursday)
    会议 :d1, 2025-06-05, 1h
    集成已有代码 :d2, after d1, 2.5h
    集成测试 :d3, after d2, 3.5h
    section 周五 (Friday)
    准备演示、验收标准 :e1, 2025-06-06, 3.5h
    演示与反馈 :e2, after e1, 3.5h

• 设计一周敏捷开发工作流程:
  • 任务: 为产品设计、测试和部署一个新功能，管理 6 人团队，每周分为 8 个 3.5 小时的会话 (Design a workflow to last one week to apply agile methodology for a new functionality)
  • 初始结构:

其他资源

• 认证建议:
  • ISTQB 基础级别认证 (ISTQB Foundation Level)
  • 敏捷测试认证 (Agile Testing Certification, e.g., ICAgile)
• 职业准备:
  • 准备简历并练习测试工程师常见面试问题 (CV/resume preparation and common interview questions for test engineers)

知识点可能考法与示例考题

可能考法

1. 定义与比较: 要求定义敏捷开发和 CMM 的关键特征，并比较两者的优缺点。
2. 敏捷实践: 描述敏捷开发中的核心实践（如 TDD、CI、结对编程）及其对质量的影响。
3. NASA 案例分析: 分析 NASA 如何在软件工程中应用 CMM，以及其经验教训。
4. 敏捷周设计: 设计一个敏捷开发周的工作流程，说明每日的活动和目标。
5. 马尔可夫链应用: 解释如何从产品日志中推导马尔可夫链概率及其在质量保证中的作用。

示例考题

1. 问题: 比较敏捷开发 (Agile Development) 和能力成熟度模型 (CMM) 在软件质量保证中的方法，并列出至少三个主要区别。
   参考答案:

   • 中文:
     敏捷开发和 CMM 在软件质量保证中有不同方法。敏捷开发通过持续测试、测试驱动开发（TDD）和持续集成（CI）内建质量，强调团队共同责任和最小化文档。CMM 则通过严格的流程控制、全面文档和定义的项目结构确保质量。
     主要区别：
     1. 文档要求：敏捷仅在必要时记录，CMM 要求全面文档。
     2. 灵活性：敏捷更灵活适应客户需求，CMM 流程较为固定。
     3. 开发实践：敏捷采用结对编程和持续集成，CMM 通常不使用这些实践。
   • English:
     Agile Development and CMM adopt different approaches to software quality assurance. Agile builds quality through continuous testing, Test-Driven Development (TDD), and Continuous Integration (CI), emphasizing shared team responsibility and minimal documentation. CMM ensures quality through rigorous process control, comprehensive documentation, and a defined project structure.
     Key differences:
     1. Documentation: Agile documents only as needed, while CMM requires rigorous documentation.
     2. Flexibility: Agile is more adaptable to customer requirements, while CMM follows a fixed process.
     3. Practices: Agile uses pair programming and continuous integration, which CMM typically does not.

2. 问题: 设计一个为期一周的敏捷开发周期，说明每日活动及如何确保质量。
   参考答案:

   • 中文:
     以下是一个为期一周的敏捷开发周期，管理 6 人团队，每日分为上午和下午两个 3.5 小时会话：
     • 周一：上午 - 需求分析与规划会议，定义新功能和测试计划；下午 - 开始编码，编写单元测试。
     • 周二：上午 - 每日站会，审查进度；下午 - 编程与单元测试。
     • 周三：上午 - 每日站会，讨论问题；下午 - 编程与测试代码。
     • 周四：上午 - 每日站会；下午 - 集成已有代码，进行集成测试。
     • 周五：上午 - 准备演示和验收标准；下午 - 向用户演示，收集反馈。
       质量保证：通过 TDD 确保代码质量，CI 减少集成错误，每日站会促进团队沟通，用户反馈验证需求满足。
   • English:
     Below is a one-week Agile development cycle for a 6-person team, with daily 3.5-hour AM and PM sessions:
     • Monday: AM - Requirements and planning meeting to define new functionality and test plan; PM - Start coding and write unit tests.
     • Tuesday: AM - Daily stand-up to review progress; PM - Programming and unit testing.
     • Wednesday: AM - Daily stand-up to discuss issues; PM - Programming and testing code.
     • Thursday: AM - Daily stand-up; PM - Integrate existing code and perform integration testing.
     • Friday: AM - Prepare demo and acceptance criteria; PM - Demo to users and collect feedback.
       Quality Assurance: TDD ensures code quality, CI reduces integration errors, daily stand-ups enhance communication, and user feedback validates requirements.

3. 问题: 解释 NASA 为何在软件工程中采用 CMMI，并列出至少两个关键影响。
   参考答案:

   • 中文:
     NASA 采用 CMMI 以确保软件系统的可靠性和安全性，降低任务失败风险。CMMI 提供基于行业最佳实践的流程改进框架，帮助 NASA 成为更聪明的软件采购者和管理者。
     关键影响：
     1. 降低风险：提高任务安全性，减少软件失败 (Reduces risk of software failure and increases mission safety)。
     2. 改进成本估算：提高成本估算准确性，减少资源增长 (Increased accuracy in cost estimates and smaller resource growth)。
   • English:
     NASA adopts CMMI to ensure the reliability and safety of software systems, reducing mission failure risks. CMMI provides a process improvement framework based on industry best practices, making NASA a smarter buyer and manager of software.
     Key impacts:
     1. Risk Reduction: Increases mission safety and reduces software failure risks.
     2. Improved Cost Estimation: Enhances cost estimate accuracy and reduces resource growth.