概述

软件危机 软件工程

软件开发四大本质困难和挑战

  • 复杂性
    • 软件是人类制造的最复杂的系统之一。
      • 非线性扩展： 软件实体的规模增加时，其相互作用的复杂性是以指数级而非线性增加的
      • 状态爆炸： 软件内部存在海量的状态转换，很难穷举和完全测试，这导致了理解、维护和修改的极大难度
  • 不可见性
    • 软件是抽象的，没有物理实体。
      • 难以可视化： 建筑师可以看蓝图，机械师可以看零件模型，但软件的逻辑流、数据流和依赖关系是无形的
      • 沟通障碍： 因为看不见，开发者之间、开发者与客户之间的沟通很容易产生误解
  • 可变性
    • 软件被认为是“软”的，因此人们总是期待它能随时被修改。
      • 持续受压： 软件必须随着硬件的升级、用户需求的变化以及业务环境的调整而不断演进
      • 牵一发而动全身： 由于复杂性，微小的改动往往会引发意想不到的连带错误（Regression errors）
  • 一致性
    • 软件不能独立存在，它必须与外部环境保持一致。
      • 环境适配： 软件必须遵循各种现有的接口、协议、复杂的法律法规以及老旧系统的限制。
      • 缺乏统一规律： 与物理学不同，这些外部限制往往是人为定义的，缺乏逻辑上的统一性，开发者必须被迫去适配这些“不合常理”的外部条件。

软件危机

  • 落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象

软件工程

  • 软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科
  • 两大视角
    • 管理视角
      • 能否复制成功
    • 技术视角
      • 是否可以将问题解决得更好

软件项目管理

管理的三大关键要素

  • 目标
  • 状态
  • 纠偏

软件项目管理

  • 典型的三大目标：成本、质量、工期
  • 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程
  • 估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理，等等

成功是否可以复制

  • 软件过程
    • 软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合
    • 这组实践之间往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标
  • 生命周期模型
    • 对软件过程的一种人为的划分

广义软件过程

理论基石

  • 软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量

广义软件过程包括

  • 技术
  • 人员
  • 狭义过程

Tips：用什么技术 + 由什么人员 + 按照什么步骤（狭义过程） 来开发软件

广义软件过程同义词：软件开发方法 软件开发过程

  • 净室Cleanroom方法、极限编程方法、SCRUM方法、Gate方法
  • 敏捷软件过程/方法 轻量型过程/方法 重型过程/方法

生命周期模型与软件过程

区别和联系

  • 生命周期模型是对一个软件开发过程的人为划分
  • 生命周期模型是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分
  • 生命周期模型往往不包括技术实践

典型生命周期模型

  • 瀑布模型 迭代式模型 增量模型 螺旋模型 原型法

软件过程管理

  • 管理对象是软件过程
  • 管理的目的是为了让软件过程在开发效率、质量等方面有着更好性能

软件过程管理与软件过程引进

截屏2026-04-20 23.40.49

  1. 最底层：元模型 (Meta-models) —— 哲学的根基

这是最基础、最抽象的方法论，它甚至不是专门为软件行业发明的，而是整个现代质量管理的基石。

  • 代表：PDCA 循环（右上角的图）
    • 这是由质量管理大师戴明提出的。它代表 Plan (计划) -> Do (执行) -> Check (检查) -> Act (行动/处理)。
    • 核心思想： 做任何事都要先计划，做了之后要检查效果，发现问题就总结经验，然后进入下一个循环。这是一个不断螺旋上升的改进过程。
  • 代表：IDEAL 模型（右下角的图）
    • 这是专门针对软件过程改进扩展出来的模型。分为启动 (Initiating)、诊断 (Diagnosing)、建立 (Establishing)、执行 (Acting) 和调整 (Leveraging) 五个阶段。它本质上是 PDCA 在软件工程领域的“威力加强版”。
  1. 中间层：参考模型 (Reference Models) —— 行业的标尺

如果你只告诉项目经理“你要去 PDCA”，这太抽象了。所以行业专家们基于这些元模型，制定了具体的“评级标准”。

  • 代表：CMM/CMMI (能力成熟度模型集成)、SPICE
    • 它们就像是软件开发团队的“段位系统”或“考试大纲”。比如 CMMI 把软件企业的成熟度分为 1 到 5 级（从初级的“混乱无序”到最高级的“持续优化”）。
    • 核心思想： 它告诉你一个“好”的软件团队在不同阶段应该具备什么特征，让你有一个明确的对标对象，但它不强制规定你具体用什么工具。
  1. 最上层：具体方案 —— 企业的落地实践

倒三角的最上面，面积最大，代表着无限的自定义可能。

  • 核心思想： 每个公司（甚至每个项目组）的人员素质、业务类型都不同。有了底层的“改进哲学 (PDCA)”，参考了中层的“行业标准 (CMMI)”，最终企业需要制定出符合自己实际情况的具体规章制度、开发规范和工具链。

课后练习

  1. 软件过程管理是软件项目管理应该要实现目标。
  • 判断：错误
  • 为什么？ 混淆了“项目管理”和“过程管理”的层级和目标。
    • 项目管理的关注点是“特定的事”： 目标是在既定的时间、成本和范围内，成功交付某一个特定的软件产品（实现铁三角的平衡）。项目结束，管理也就告一段落。
    • 过程管理的关注点是“组织的长期能力”： 目标是建立、维护和改进一套体系，让公司在开发所有项目时都能保持稳定、高效。
    • 关系： 过程管理为项目管理提供规则和土壤。项目管理是在这片土壤上种出一棵树，而不是为了创造这片土壤本身。
  1. “在公司导入敏捷过程是我们今年过程改进的主要目标。”
  • 判断：错误（或者说描述极不规范）
  • 为什么？ 混淆了“手段”与“目的”。
    • 导入敏捷过程（如 Scrum 或 XP）只是一种手段（解决方案）。
    • 过程改进的真正目标必须是可度量的业务收益或质量提升。例如：“将产品交付周期缩短 20%”、“将线上 Bug 率降低 15%” 或者是 “提高客户满意度”。为了达成这些业务目标，我们选择导入敏捷过程。如果只为“敏捷而敏捷”，往往会导致流于形式的失败。
  1. XP 与 CMM/CMMI 是对立的两种软件开发方法。
  • 判断：错误
  • 为什么？ 它们根本不在同一个维度上（回忆一下上一张幻灯片的“倒三角模型”）。
    • CMM/CMMI 是中间层的“参考模型”： 它是一个评估标准，告诉你一个优秀的团队“应该做什么”（例如：需要有需求管理、配置管理），但不强制规定你怎么做。
    • XP（极限编程）是顶层的“具体方案/敏捷过程”： 它是非常具体的微观实践（如结对编程、测试驱动开发），告诉你“具体怎么做”。
    • 关系： 它们完全可以结合使用。一个公司完全可以通过严格执行 XP 的各项敏捷实践，来达到 CMMI 高级别的质量和成熟度要求。它们是互补的，而非对立的。
  1. CMM/CMMI 不适合当今互联网环境的项目管理需求。
  • 判断：错误
  • 为什么？ 这是一种常见的刻板印象。
    • 早期的 CMM 确实给人以“重文档、偏向瀑布流、适合外包和军工”的印象。但如今的 CMMI（特别是 V2.0 及以后版本）已经发生了巨大变化，它原生且深度地融合了敏捷（Agile）思想。
    • 互联网环境同样需要质量把控、风险管理和持续改进。CMMI 提供的是一套管理思想的“体检表”，互联网公司完全可以用轻量级、敏捷的实践方式来满足 CMMI 的核心目标。
  1. PDCA 和 IDEAL 不适合在敏捷环境中使用。
  • 判断：错误
  • 为什么？ 恰恰相反，敏捷的核心灵魂就是 PDCA 循环！
    • PDCA 是所有质量管理的哲学基石。 敏捷开发中的“迭代（Sprint）”就是一个完美的微型 PDCA 循环：
      • P (Plan): 迭代计划会议（Sprint Planning）
      • D (Do): 日常开发与结对编程
      • C (Check): 每日站会（Daily Standup）检查进度，迭代评审会议（Sprint Review）检查产品
      • A (Act): 迭代回顾会议（Sprint Retrospective）总结经验，调整下一步行动
    • 敏捷不是没有规章制度的盲目开发，它是建立在高频的 PDCA 循环之上的一种快速反馈机制。
  1. 不同的软件开发过程应该使用不同的生命周期模型，反之亦如此。
  • 判断：错误
  • 为什么？ 混淆了宏观的“生命周期”与微观的“具体过程实践”（也就是你上一张图问的“生命周期不包括技术实践”的原因）。
    • 这两者是解耦的。同一种生命周期模型可以搭配不同的开发过程： 例如，在一个宏观的“迭代生命周期”中，团队 A 可能使用 Scrum 过程，团队 B 可能使用 Kanban（看板）过程。
    • 同一种开发过程实践也可以用在不同的生命周期中： 例如，“代码审查（Code Review）”或者“持续集成（CI）”这样的优秀实践，无论你是在用古老的瀑布模型，还是最新的敏捷模型，都可以并且应该去使用。它们不是绑定的。