EagleBear2002 的博客

这里必须根绝一切犹豫，这里任何怯懦都无济于事

软件质量管理-02-软件过程的历史演变和经典工作

发表于 更新于 分类于
本文字数： 3.8k 阅读时长 ≈ 3 分钟

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

再读《没有银弹》

软件开发有很多困难，但是本质难题是：

  1. 不可见性：软件项目是一个逻辑实体
  2. 复杂性：实体数量众多
  3. 可变性
  4. 一致性

进一步分析：

  1. 除了不可见性以外，其他三个本质难题因项目而异。
  2. 四大本质难题互相促进。
  3. 本质难题变化带动软件方法（过程）演变。

本质难题无法彻底解决。

软件发展

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

  1. 软件开发费用和进度失控
  2. 软件可靠性差
  3. 生产出来的软件难以维护
  4. 用户对“已完成”系统不满意现象经常发现

软件发展三大阶段

软件发展的两个趋势：

  1. 软件项目规模日益扩大：使得软件越来越难做。
  2. 软件在整个系统中的比重日益增加：将软件质量问题的影响上升到前所未有的高度。

  1. 软硬件一体化阶段（50 年代到 70 年代）
    1. 软件完全依附于硬件
    2. 软件作坊
  2. 软件成为独立的产品（70 年代到 90 年代）
  3. 网络化和服务化（90 年代中期至今）

软件完全依附于硬件

典型特征

  1. 软件应用典型特征：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更。
  2. 软件开发典型特征：硬件太贵、团队以硬件工程师和数学家为主。

典型软件过程和实践

  1. Measure twice, cut once：这句话强调了在应用更改之前仔细检查代码以在问题成为主要问题之前识别和纠正问题的重要性
  2. 相同的软件工程实践：code review & inspection
  3. 整个过程非常线性

软件作坊

典型特征

  1. 软件应用典型特征：功能简单、规模小；
  2. 软件开发典型特征：很多非专业领域的人员涌入软件开发领域、高级程序语言出现、质疑权威文化盛行。

典型软件过程和实践

  1. Code And Fix
  2. 软件危机和软件工程：Code And Fix 不适合大型软件项目开发

软件成为独立产品

典型特征

软件应用特征：摆脱了硬件束缚（OS）、功能强大、规模和复杂度剧增、个人电脑出现 \(\to\) 普通人成为软件用户 \(\to\) 需求多变和兼容性要求、来自市场的压力。 #### 软件典型过程和实践

方法之一：形式化方法

将所有的方法当作数学方法，做数学化的检验，主要解决质量和正确性问题。

方法之二：结构化设计和瀑布模型

上图是瀑布模型，每个阶段都有一个往回的箭头；下图不是生命周期模型。

  1. 自顶向下，逐步求精。
  2. 问题和不足（效率和质量）：
    1. 形式化在扩展性和可用性方面存在不足。
    2. 瀑布模型成为一个重文档、慢节奏的过程。
生命周期模型

  1. 是什么：一个对软件过程的人为划分

  2. 主要作用：便于传达，复制成功

  3. lean development 说：其实 royee 提出瀑布生命周期模型的本意是该生命周期模型不适合软件开发

  4. royee：

    1. 本意是瀑布模型不是一个单一的生命周期模型，是很多的元素的融合，是系列的生命周期模型，包括编码改错、改进等等。
    2. 软件团队在选择生命周期模型时，应当结合上下文选择生命周期模型，往往越复杂，有越多的元素，自己选择最合适的。
    3. 大部分的项目团队轻视了项目的复杂和挑战，选择了一个简单的不适用的瀑布模型。

  5. 问题和不足（效率和质量）

    1. 形式化存在扩展性和可用性方面存在不足
    2. 瀑布模型成为一个重文档，慢节奏的过程。

成熟度模型（最开始是 CMM，现在是 CMMI）
  1. 什么是有管理的：状态获取？
  2. 管理的是三个要素：目标、状态和纠偏
  3. CMMI 的 3 级中的标准化目的不是简单的替换
  4. CMMI 从 2 级升级到 3 级的原因：固化最佳实践，对小组而言则是能够更快地学习其他的做法
  5. CMMI 3 级的重点是已定义
  6. CMMI 4 级我们希望能够看到一个预测模型
  7. 4 级和 5 级更多是根据结果（未来）来进行管理
  8. 2 级和 3 级关注的是当前的状态

  1. 分级
    1. 第一级：初始级别
    2. 第二级：和项目有关
    3. 第三级：促成共享，来自于团队标准
    4. 第四级：定量管理，提升对未来结果的一种预测，对偏差的预测
  2. 一些讨论：https://www.jianshu.com/p/b7407257eedb
概念 解析
CMMI 是过程改进模型而非软件过程或者软件过程模型 CMMI 指导软件过程改进，不指导开发
CMMI 不是过程优劣的标准，也不适合用作公司之间的能力比较 CMMI 本身是有评级。美国国防部订单招标要求企业至少达到 CMMI 的 3 级。因为公司的能力需要绝对东西，也就是能力强，能力弱，而 CMMI 衡量的是相对的水平，CMMI 仅仅关注在本公司的目标下的等级
为什么 CMMI VS. Agile 是一个伪命题？ TODO

网络化和服务化

典型特征

软件应用特征：功能更复杂，规模更大、用户数量急剧增加（这会带来什么问题？）、快速演化和需求不确定、分发方式的变化（SaaS）。

典型软件过程和实践

  1. 迭代式：大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来完成交付。
  2. 【2022Fall】【2021Fall】【2020-mid】雪鸟会议和敏捷宣言
    1. 个体和互动胜过流程和工具
    2. 可以工作的软件胜过详尽的文档
    3. 客户合作胜过合同谈判
    4. 响应变化胜过遵循计划
    5. 也就是说，尽管右项有其价值，我们更重视左项的价值。
    6. 请务必关注最后一句话，非常重要

十二条敏捷原则：

  1. 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
  2. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
  3. 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
  4. 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
  5. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
  6. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
  7. 可工作的软件是进度的首要度量标准。
  8. 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
  9. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
  10. 以简洁为本，它是极力减少不必要工作量的艺术。
  11. 最好的架构、需求和设计出自自组织团队。
  12. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。

  1. XP（eXtreme Programing） 方法：偏重于一些工程实践的描述
  2. SCRUM：管理框架和管理实践
  3. Kanban：
    1. 精益生产（丰田制造法）的具体实现
    2. 可视化工作流、限定 WIP、管理周期时间
    3. 马丁提出了微服务架构
  4. 开源软件开发方法：是一种基于并行开发模式的软件开发的组织与管理方式
    1. Linus 定律：如果有足够多的 beta 测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。
    2. 早发布，常发布，倾听用户的反馈 、把你的用户当成开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径、设计上的完美不是没有东西可以再加，而是没有东西可以再减
    3. 代码管理：严格的代码提交社区审核制度、内部开源（inner source）、众包（Crowdsourcing）

当前软件发展：更深化的网络化和服务化

软件应用典型特征

  1. 进一步服务化和网络化（移动是主流）、随处可见（pervasive）
  2. 用户需求多样化进一步凸显
  3. 软件产品和服务的地位变化
  4. 错综复杂的部署环境
  5. 近乎苛刻的用户期望
    1. 多：功能丰富，个性化
    2. 快：快速使用，及时更新，快速解决问题
    3. 好：稳定，可靠，安全，可信
    4. 省：用户的获得成本低，最好免费

软件开发的典型特征

  1. 空前强大的开发和部署环境——XaaS
    1. IaaS
    2. PaaS
    3. SaaS, FaaS
  2. 盛行共享和开源
  3. 潜在支撑获得了长足进步（AI，Bigdata， Cloud，etc.）

【2021Fall】【2018Fall】典型软件过程和实践：DevOps

  1. 方法论基础是敏捷软件开发、精益思想以及看板 Kanban 方法。
  2. 以领域驱动设计为指导的微服务架构方式
  3. 大量虚拟化技术的使用
  4. 一切皆服务 XaaS（X as a Service）的理念指导
  5. 构建了强大的工具链，支持高水平自动化

敏捷软件开发

敏捷中也有计划驱动

敏捷目的

为了使软件开发团队具有高效工作和快速响应变化的能力。

敏捷原则

  1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要
  2. 欢迎需求的变化
  3. 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好
  4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
  5. 最好的信息传达方式是面对面的交谈

敏捷宣言（重要）

  1. 敏捷软件开发宣言的 4 个简单的价值观：
    1. 个体和交互 胜过 过程和工具
    2. 可以工作的软件 胜过 面面俱到的文档
    3. 客户合作 胜过 合同谈判
    4. 响应变化 胜过 遵循计划
  2. 也就是说，尽管右项有其价值，我们更重视左项的价值

敏捷软件开发方法

极限编程 XP

eXtreme Programming，极限的含义是指把好的开发实践运用到极致。

极限编程的有效实践：

  1. 客户作为开发团队的成员——客户代表
  2. 使用用户素材
  3. 短交付周期
  4. 验收测试
  5. 结对编程——结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。
  6. 测试驱动开发——极限编程强调“测试先行”。在编码之前，应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。
  7. 集体所有
  8. 持续集成
  9. 可持续的开发速度 <=40h/week
  10. 开放的工作空间
  11. 重构
  12. 使用隐喻

Scrum

TODO：

Kanban 方法

  1. 精益生产（丰田制造法）的具体实现
  2. 可视化工作流、限定 WIP、管理周期时间
  3. 马丁提出了微服务架构

课程小论文（2023Fall 没有）

从软件发展的三大历史阶段以及软件过程的演变当中，我们可以总结出哪些规律性的东西？