1. 软件开发的四大本质难题

1.1. 四大本质难题是什么

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

1.2. 四大本质难题之间的关系

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

1.3. 几个注意点

软件开发四大本质难题永远存在，不可能彻底解决，在不同时期凸显程度有差异。
软件开发本质上是智力劳动，开发者心理方面的因素不可忽视

1.4. 考试题目

【2020-mid】关于Brooks提及的软件开发本质难题，下列说法中不准确的是:(AB)
1. 本质难题总共有四个，分别为复杂、不可见、可变和质量挑战
2. 既然是本质难题，那就说明是根植于软件开发本身，因而是不可能在软件开发当中得到缓解.
3. 严格来说，只有不可见才是真正的“本质”难题，其他三个因项目而异
4. 四大本质难题贯穿软件发展的不同历史阶段，但是在不同历史阶段，相互凸显程度不一样

2. 软件发展

软件发展的两个趋势
1. 软件项目规模日益扩大：使得软件越来越难做。
2. 软件在整个系统中的比重日益增加：将软件质量问题的影响上升到前所未有的高度。
软件危机：指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。主要体现有：
1. 软件开发费用和进度失控
2. 软件可靠性差
3. 生产出来的软件难以维护
4. 用户对“已完成”系统不满意现象经常发现
软件发展的三大阶段
1. 软硬件一体化阶段：软件完全依附于硬件，软件作坊（50年代到70年代）
2. 软件成为独立的产品（70年代到90年代）
3. 络化和服务化（90年代中期至今）

2.1. 软硬件一体化阶段

软件完全依赖于硬件
1. 软件应用典型特征：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更。
2. 软件开发典型特征：硬件太贵、团队以硬件工程师和数学家为主。
3. 典型软件过程和实践
  1. 非常线性
  2. 三思而后行（measure twice，cut once）
软件作坊
1. 软件应用典型特征：功能简单、规模小。
2. 软件开发典型特征：很多非专业领域人员涌入软件、高级程序语言出现、质疑权威文化盛行。
3. 典型软件过程和实践：
  1. Code and Fix
  2. 编码 + 改错
【2020-mid】下列软件应用和开发的典型特征中属于软硬件一体化阶段的是BC)
1. 可以通过引入操作系统，摆脱了硬件束缚：软件成为独立的产品
2. 几乎不需要考虑需求变更
3. 缺乏科班的软件工程师
4. 系统兼容对应软件开发的成败非常关键：软件成为独立的产品

2.2. 软件成为独立的产品

软件应用典型特征：摆脱了硬件的束缚（OS）、功能强大、个人电脑出现 -> 普通人成为软件用户 -> 需求多变、兼容性要求、来自市场的压力
典型软件过程和实践
1. 形式化方法：将所有的方法当作数学方法，做数学化的检验，主要解决质量和正确性问题。
2. 结构化程序设计和瀑布模型
  1. 自顶向下，逐步求精。
  2. 问题和不足（效率和质量）
    1. 形式化在扩展性和可用性方面存在不足。
    2. 瀑布模型成为一个重文档、慢节奏的过程。

2.3. 络化和服务化

2.3.1. 络化和服务化

软件应用典型特征：功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方法的变化（SaaS）
典型软件过程和实践：
1. 迭代式（90年代中后期）大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来交付。
2. 雪鸟会议和敏捷宣言
  1. 个体和互动胜过流程和工具
  2. 可以工作的软件胜过详尽的文档
  3. 客户合作胜过合同谈判
  4. 响应变化胜过遵循计划
  5. 尽管右项有价值，但是我们更重视左项的价值
3. XP eXtreme Programming 方法：偏重于一些工程实践的描述
4. Scrum：管理框架和管理实践。
5. KanBan
  1. 精益生产（丰田制造法）的具体实现
  2. 可视化工作流、限定WIP、管理周期时间
6. 开源软件开发方式：
  1. 一种基于并行开发模式的软件开发的组织与管理方式。
  2. Linus 定律：如果有足够多的beta测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。

2.3.2. 更深化的络化和服务化

软件应用典型特征
1. 进一步服务化和络化（移动是主流）随处可见（pervasive）
2. 用户需求的多样性进一步凸显
3. 软件产品和服务的地位变化
4. 错综复杂的部署环境。
5. 近乎苛刻的用户期望
  1. 多：功能丰富，个性化
  2. 快：快速使用，及时更新，快速解决问题
  3. 好：稳定，可靠，安全，可信
  4. 省：用户的获得成本低，最好免费
软件开发的典型特征
1. 空前强大的开发和部署环境：XaaS，IaaS、PaaS、SaaS
2. 盛行开源和共享文化
3. 盛行敏捷开发
4. 软件工程的潜在支撑力量获得了长足进步（AI、大数据、云计算）
典型软件过程和实践：DevOps
1. 开发运维一体化
2. 方法论的基础是软件敏捷开发、精益思想和看板KanBan方法
3. 以领域驱动设计为指导的微服务架构方式
4. 大量虚拟化技术的使用
5. 一切皆服务XaaS的理念指导
6. 构建了强大的工具链，支持高水平自动化。

2.4. 考试题目

【2018】软件发展三大阶段的特点和主流开发方法
1. 软硬件一体化
  1. 特点：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更
  2. 主流开发方法：三思而后行；Code and Fix；编码 + 改错
2. 软件成为独立的产品
  1. 特点：摆脱了硬件的束缚(操作系统)、功能强大、个人电脑出现、需求多变、兼容性要求、来自市场的压力
  2. 主流开发方法：形式化方法、结构化程序设计和瀑布模型
3. 络化和服务化
  1. 特点：功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方式的变化、进一步的服务化和络化、盛行开源和共享文化
  2. 主流开发方法：迭代式开发、敏捷开发(XP、Scrum、Kanban)、开源软件开发方式、DevOps
【2020-mid】请结合软件发展的三大阶段，描述不同阶段的典型软件开发方法和实践
1. (3’)软硬件一体化：线性顺序过程、事实上是硬件开发流程，measure twice cut once
2. (3’)软件成为独立产品：结构化程序设计、瀑布声明周期模型、成熟度运动
3. (4’) 络化和服务化：迭代式开发、敏捷运动

3. 软件工程

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

3.1. 管理

管理的三大关键要素：目标、状态(是在接近目标还是在原理目标)和纠偏。
大部分情况下，管理仅仅是视图复制其他地方(场景)的成功，但是这种复制一般不容易
软件项目管理是为了降低/减少各种无谓的损耗来实现本该有的性能。
软件过程改进是为了达到更好的效能，其中质量/缺陷是首要目标或限制。

3.1.1. 软件项目管理

典型的三大目标：成本、质量和工期。
定义：软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
1. 软件项目管理包括估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理等等。
2. 软件项目管理的对象是各类软件项目
可以细分为两种管理视角：软件过程与生命周期模型
【2020-mid】下列哪些项不属于管理活动应该包含的要素ABD)
1. 成本
2. 质量
3. 目标
4. 工期

3.1.2. 软件过程管理

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

3.1.3. 软件过程管理与软件过程改进

两者含义接近
软件过程管理参考模型 CMM/CMMI，SPICE等。
软件过程改进参考元模型 PDCA、IDEAL等。

3.1.4. 考试题

【2018】软件项目管理和软件过程管理
1. 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
2. 软件过程管理是为了让软件过程在开发效率、质量等方面有着更好性能绩效。

3.2. 软件过程

软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这一组实践往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。

3.2.1. 广义软件过程

理论基石：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。
包括：技术、人员以及狭义过程。
同义词：软件开发方法、软件开发过程。
1. 净室Clean Room方法、极限编程方法、Scrum方法、Gate方法
  1. clean room工程过程和CMM管理过程互为补充
  2. clean room比cmm更注重质量，更偏向于使用一些数学工具
2. 更一般的，敏捷软件过程/方法、轻量型过程/方法及重型过程/方法等描述也是恰当的。

3.2.2. 生命周期模型

生命周期模型是对软件过程的一种人为划分。
典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等。

3.2.3. 考试题目

【2018】【2020-mid】生命周期模型与软件过程的区别和联系
1. (3’)生命周期模型是对一个软件开发过程的人为划分。
2. (3’)生命周期模型是软件开发过程的框架，是对软件开发过程的一种粗粒度划分。
3. (2’)生命周期模型往往不包括技术实践。
【2020-mid】我们如何理解瀑布模型
1. (4’)瀑布模型不是单一模型，是一系列模型，覆盖最简单场景(过程元素少)到最复杂的场景(过程元素多)
2. (4’)软件项目应该结合实际情况选择合适过程元素的瀑布模型，基本原则是，项目面临困难和挑战越多，选择的模型应该越复杂
3. (4’)软件项目团队往往低估项目的挑战，选择了过于简单的不适用的瀑布模型
【2020-mid】下列名词和术语中不属于软件过程的有哪些BD)
1. SCRUM
2. CMM/CMMI
3. GATE方法
4. IDEAL
软件过程管理是软件项目管理应该要实现目标：软件过程管理和软件项目管理完全是两回事，项目过程管理应当有专门的人去做。因此并不是实现目标，错误的。
在公司导入敏捷过程是我们今年过程改进的主要目标：过程管理和过程改进是类似的，这个说法在概念上是合适的，但是操作的时候可能存在问题。
XP与CMM/CMMI是对立的两种软件开发方法：
1. CMM和CMMI并不是软件开发方法，而是软件过程管理和改进，CMM和CMMI是没有较大区别的，错误的。
2. XP的观念确实与严格的CMM/CMMI是对立的
3. XP是软件开发方法，敏捷的
CMM/CMMI不适合当今互联环境的项目管理需求：CMM/CMMI是用来做过程管理和改进的，根本不是满足项目管理需求的手段，正确的。
PDCA和IDEAL不适合在敏捷环境中使用：PDCA，IDEAL是软件过程改进参考元模型，因此是适合在敏捷环境中使用的，错误的。
不同的软件开发过程应该使用不同的生命周期模型，反之亦如此：生命周期模型是由人类划分的，不一定，错误的，

3.2.4. 软件过程管理/改进模型：CMM

定义：CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。
级别：分为五个级别，一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

3.2.5. 等级一：初始级 Initial

特点：处于该级别的组织基本上没有健全的软件工程管理制度。
1. 每件事情都用特殊的方法去做：如果特定工程遇到有能力的管理员和一个优秀的软件开发组来做，则可能是成功的。
2. 大多数的行动知识应付危机，而非事先计划好的任务。通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。
3. 软件过程完全取决于当前的人员配置，具有不可预测性。
要精确地预测产品的开发实践和费用之类重要的项目，是不可能的。

3.2.6. 等级二：可重复级 Repeatable

特点：有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验。
1. 采取了一些措施，这些措施是实现一个完备过程所必不可缺少的第一步。
  1. 典型措施包括：仔细地追踪费用和进度。
  2. 不像第一级那样，在危机状态下才行动，管理人员在问题出现时便可发现，并立即采取修正行动，防止它们变成危机。
2. 关键一点：没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中财务的措施也可以为未来的项目拟定实现的期限和费用计划。

3.2.7. 等级三：已定义级 Defined

特点：为软件生产的过程编制了完整的文档。
1. 软件过程管理方面和技术方面已经做了明确的定义，并且按需要不断地改进过程。
2. 采用评审的方法来保证软件的质量。
这个级别可以引用CASE环境来进一步提高质量和产生率。
在第一级的过程中，高技术会使得该危机驱动过程更加混乱。

3.2.8. 等级四：已管理级 Managed

特点：公司对每个项目都设定质量和生产目标。
1. 这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。
2. 利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离。
统计质量控制措施的一个简单例子：是每千行代码的错误率，相应的目标就是随时间推移减少这个量。

3.2.9. 等级五：优化级 Optimizing

目标：连续地改进软件过程。
1. 使用统计质量和过程控制技术作为指导。
2. 从各方面获得的知识将被运用在以后的项目中，从而使软件过程融入正反馈循环，使生产率和质量得到稳步的改进。

3.2.10. 考试题

【2015B】CMM的创始哪位_____
1. Boehm
2. Juran
3. Humphrey
4. Crosby

3.3. 软件过程管理/改进模型：CMMI Capability Maturity Model Integration 能力成熟度集成模型

刻画了软件团队/组织从不成熟到成熟的每个阶段的特征(也就是roadmap)
等级2和等级3关注的是当前状态
等级4和等级5是根据结果(未来)来进行管理

3.3.1. 等级一：初始级

开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行

软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。
由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务，项目实施是否成功主要取决于实施人员。

3.3.2. 等级二：已管理级

项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等。

软件组织对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。
软件组织在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对项目相关的实施人员进行相应的培训，对整个流程进行监测与控制，并联合上级单位对项目与流程进行审查。
从2级升级到3级的原因：固化最佳实践，对小组而言是能够更快地学习其他的做法。

3.3.3. 等级三：已定义级

公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司内分享。

软件组织能够根据自己的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。
软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。
科学管理成为软件组织的一种文化，成为软件组织的财富。

3.3.4. 等级四：定量管理级

构建预测模型，已统计过程控制的手段来管理过程

软件组织的项目管理实现了数字化。
通过数字化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
在这个级别我们希望能够看到一个预测模型。

3.3.5. 等级五：优化级

继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题

软件组织能够充分利用信息资料，对软件项目在项目实施的过程中可能出现的次品予以预防。
能够主动地改善流程，运用新技术，实现流程的优化。

3.3.6. 一些理解

CMM/CMMI不适用于软件开发的原因
1. CMM/CMMI并不是一种具体的软件过程或者软件开发方法
  1. CMM/CMMI建立了一组有效地描述成熟软件组织特征的准则。
  2. CMMI是过程改进模型而非软件过程或者软件过程模型：CMMI指导软件过程改进，不指导开发。
  3. 按照CMM/CMMI模型的要求，一个软件组织应当定义使用本软件组织特点的软件过程，并且不断优化该过程，来更好地实现软件组织的商业目标。
2. CMM/CMMI并不能作为检验软件过程优劣的标准：过程改进对不同企业的含义不一样，成熟度等级无法脱离企业环境直接横向比较。
3. CMM/CMMI与其他软件过程或者软件开发方法的比较是没有任何意义的。
一些误解：
1. CMMI模型需要适当裁剪以适应公司的实际情况：需要裁剪的是公司内部定义的组织级开发流程和开发规范。
2. CMMI模型太重了，不适合互联时代的轻量级开发：这个说法的错误之处在于，不一定是CMMI重或者轻，而是，CMMI根本就不是开发模型。
3. CMMI模型只适合大公司、大项目，不适合小项目：首先没人检验过；其次，项目的大小衡量本身也缺乏值得信赖的参考依据；最后，接受这种说法的人还是把CMMI当成是一种特殊的开发模型。
4. CMMI模型只适合需求不变或者很少变化的场合，不适合需求不确定，变化很多的场合：CMMI不是开发模型，与需求变化与否无关，谈不上适应或者不适应。
CMMI不是过程优劣的标准，也不适合用作公司之间的能力比较，说法怎么样的，CMMI本身是有评级。（美国国防部订单招标要求企业至少达到CMMI的3级。因为公司的能力需要绝对东西，也就是能力强，能力弱，而CMMI衡量的是相对的水平，CMMI仅仅关注在本公司的目标下的等级
更多讨论：试论CMM/CMMI不适合在当前软件开发当中应用的原因

3.3.7. 考试题

【2020-mid】请描述CMMI模型的5个等级的特征，并且解释为何CMMI模型不应该是敏捷方法的对立面：
1. 五个等级的特征
  1. Initial 原始级别：开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行
  2. Managed 已管理级别：项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等
  3. Defined 已定义级别：公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司共享。
  4. Quantitatively Managed 定量管理级别：构建预测模型，已统计过程控制的手段来管理过程
  5. Optimizing 优化级：继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题。
2. 原因解释：
  1. CMMI是过程改进模型，刻画了软件组织从不成熟到成熟的路线图。
  2. 大部分敏捷方法都是开发方法
  3. 因此两者是完全不同性质的事物，将两者对立是不合适的。

【2015B】【2016】请描述PDCA模型的主要步骤（5分）

3.5. 软件过程改进模型：IDEAL模型

IDEAL模型解决了软件组织在各种质量改进环境下的需要。它包括了软件过程改进周期中的五个阶段，IDEAL是代表这五个阶段的单词的母。
1. I: Initiating 初始
2. D: Diagnosing 诊断
3. E: Establishing 建/li>
4. A: Acting 执/li>
5. L: Leveraging 调整

Scrum中的文档
1. 产品订单(product backlog)：整个项目的概要文档，包含了已划分优先等级的、项目要开发的系统或产品的需求清单，是动态的。
2. 冲刺订单(sprint backlog)：细化了的文档，包含了团队如何实现下一个冲刺的需求信息。
  1. 哪些产品订单会加入一次冲刺由冲刺计划会议决定。会议中，产品负责人告诉开发团队他们需要完成产品订单中的哪些订单项，开发团队决定在下一次冲刺中承诺完成多少订单项。
  2. 在冲刺的过程中，没有人能够变更冲刺订单(sprint backlog)，这意味着在一个冲刺中需求是被冻结的。
3. 燃尽图(burn down chart)
Scrum中角色
1. 产品负责人，代表利益所有者
  1. 产品负责人的职责是将开发团队开发的产品价值最大化。
  2. 产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
    1. 清晰地表述产品待办列表项；
    2. 对产品待办列表项进行排序，使其最好地实现目标和使命；
    3. 优化开发团队所执行工作的价值；
    4. 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及
    5. 确保开发团队对产品待办列表项有足够深的了解。
2. Scrum Master，类似于项目经理，负责维护过程和任务
  1. 促进和支持 SCRUM
  2. 帮助每个人理解 SCRUM 理论、实践、规则和价值
  3. SCRUM Master 是一位服务型领导。
    1. 帮助 SCRUM 团队之外的人了解如何与 SCRUM 团队交互是有益的
    2. 改变SCRUM 团队之外的人与 SCRUM 团队的互动方式来最大化 SCRUM 团队所创造的价值。
  4. Scrum Master 服务于产品负责人，包括：
    1. 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
    2. 找到有效管理产品待办列表的技巧；
    3. 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
    4. 理解在经验主义的环境中的产品规划；
    5. 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
    6. 理解并实践敏捷性；以及，
    7. 当被请求或需要时，引导 Scrum 事件。
  5. Scrum Master 以各种方式服务于开发团队，包括
    1. 作为教练在自组织和跨职能方面给予开发团队以指导；
    2. 帮助开发团队创造高价值的产品；
    3. 移除开发团队工作进展中的障碍；
    4. 按被请求或需要时，引导 Scrum 事件；以及，
    5. 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
  6. Scrum Master 以各种方式服务于组织，包括：
    1. 带领并作为教练指导组织采纳 Scrum；
    2. 在组织范围内规划 Scrum 的实施；
    3. 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
    4. 引发能够提升 Scrum 团队生产率的改变；以及，
    5. 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。
3. 开发团队
  1. 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
  2. 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。开发团队具有下列特点：
    1. 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
    2. 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
    3. Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
    4. Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
    5. 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
Scrum常见活动
1. Sprint Planning Meeting
2. Daily standup meeting
3. review meeting
4. retrospective meeting
5. sprint
Empirical Process Control VS. Statistical Process Control，不同于统计过程控制方法（也叫预测式、计划式）不能解决不可预见的需求变化问题，Scrum采用的实证过程控制承认问题无法完全理解或定义，即用户可以在项目过程中变更需求，关注于如何使开发团队快速推出和响应需求变化的能力最大化
Scrum VS. XP
1. 迭代周期不同。XP迭代周期为1_{2周，而Scrum迭代周期为2}4周
2. 迭代中是否允许需求变更。XP中只要变更需求与原需求所需时间资源相等即可变更，而Scrum在迭代中需求被冻结
3. 迭代中，需求是否严格按照优先级来实现。XP中务必遵守优先级别，Scrum中则比较灵活，原因是可能有需求依赖问题
4. 过程工程化。Scrum开发过程并未工程化，要求开发者自觉保证，但XP则对开发流程定义严格，例如TDD，结对编程，重构等

4.1.4.3. Kanban方法

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

4.1.4.4. 考试题

【2015B】XP规定开发每周时间不超过___，连续加班不可以超过两周，以免降低率B)
1. 30
2. 40
3. 50
4. 60
【2020-mid】下列不属于看板方法典型实践的是BD)
1. 可视化工作流
2. 站立式会议
3. 限定WIP
4. 重构
【2015B】【2016】请结合SCRUM这种敏捷论述敏捷应该具备的特征时解释为何常见的若描述敏捷对的的特征（例如，严格、重型、计划驱动等等）并不合适0’
1. 特征
  1. 期迭代
  2. 快速响应变更
  3. 价值交付
  4. 化
2. 特征解释：
  1. 严格：所有优秀的和实践都是严格的。
  2. 重型：如上，此外，轻量级和重型其实并没有刻画具体，何为重型，并没有严格定义；，对于变更这件事情，所有都是限制，因此，很难说敏捷是轻量级。
  3. 计划驱动：所有正式的项是计划驱动的，否则计划的作法体现
【2015A】敏捷方法的特征有哪些些关于敏捷特征的说法施加于敏捷方法之上是不合适的什么0’
1. 特征：小周期迭代式持续交付、敏捷宣言
2. 关于敏捷方法的一些特征表述可能带着一定的误导，例如:
  1. 轻量级方法:这是对以XP为代表的一类方法的误导，事实上，这类方法对工程规范有着极为严格的要求;
  2. 拥抱变更、变更驱动：仅仅是口，对待变更，所有软件工程方法都是限制和管理的态度。
  3. TDD可以提供更高的开发质量:并没有足够的证据支持。
【2014】为何说将“规范方法”、“计划驱动方法”等特征作为敏捷方法的对立面带有很大的误导性质何通过多种维度改进这种对各类开发过程的理解0’
1. 敏捷：敏捷目的、敏捷价值观、敏捷原则
2. 影响敏捷与规范方法选择的五个维度
  1. 如果只有强有力的规范而缺乏敏捷，将导致官僚作风，进而停滞不前。团队将陷入为了测量而测量的处境之中，缺乏创新。
  2. 缺乏创新的敏捷则如同一个新创公司在盈利之前的不负责任的狂热
  3. 计划驱动的开发人员必须敏捷，敏捷开发人员必须规范。
【2016】Devops三个步骤
【2018】Devops的特点，为什么流行/li>
【2018】什么是云原生关的重要的概念
【2018】精益屋的两大支柱/li>
【2018】JIT及时生产，价值流和价值拉动的关系

4.1.4.5. 概念解释

【2016】CI
【2016】CD/CD
【2016】Pipeline Orchestration
【2016】Container
【2016】Micro Service
【2016】A/B Testing
【2016】GitFlow

4.1.4.6. 描述用途

【2016】Docker
【2016】Jenkins
【2016】JIRA
【2016】SonarQube
【2016】Git

5. PSP 个体软件过程

5.2. PSP基本原理（为什么要有PSP）

软件系统的整体质量由该系统中质量最差的某些组件所决定
软件组件的质量取决于开发工程师所使用的开发过程。
软件工程师应当自己度量、跟踪自己的工作流程，并建立持续的自我改进机制（在自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践），自己管理软件组件的质量。

上述基本原理除了继续肯定“过程质量决定最终产品质量“这一软件过程改进的之外，更加突出了个体软件工程师在管理和改进自身过程中的能动性。这就形成了PSP的理论基础。

5.3. PSP的成熟度级别

上述框架中，那些步骤必须人为的干预
1. 定义需求
2. 概要设计：划分由人为开始，规模划分好之后估算是自动产生的
3. 日程计划
这会带来什么的好处较容易扛住别人的质疑。
1. 攻击点：资源和时间是否被高估了
2. 解决：估算没有代码行PROBE只有功能点是大中小。
考试题：【2020-mid】请简要描述按照通用计划框架，为了开发合理的项目计划，应该要做哪些估算ROBE方法充当什么角色。
1. 估算框架如上图
2. 虚线框即为PROBE，用来完成规模和资源的评估

5.4.6.5. PROBE估算过程

概要设计
1. 确定产品功能，以及产生这些功能所需的程序组件/模块
2. 将程序组件/模板与你之前写的程序相比较，估算它们的规模
3. 最后将程序组件/模块估算综合给出总规模
估算要点：
1. 尽可能划分详细一些：估算多个部件的时候，总的误差会比各个部件的误差的总和小
2. 建立对结果的信心
3. 依赖数据
4. 估算要的是过程，而非结果，估算的过程是相关干系人达成一致共识的过程。

5.4.6.6. 注意点1：整理历史数据

以估算规模为例，可以假定代理规模与实际程序规模之间存在简单关系映射、正态分布、对数正态分布，也可以假定不知道两者之间的关系，按照线性回归方法进行计算。

简单方法
1. 内容：最小值作为VS、最大值作为VL、中值作为M,VS与M均值作为S、VL与M均值作为L
2. 优点：计算简单
3. 缺点：不稳定
正态分布法
1. 内容：均值作为M，计算标准差σ，则S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ
2. 优点：相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵
对数正态分布法:
1. 内容：
  1. 以e为底计算所有数据的自然对数
  2. 取对数之后的值的均值作为M，计算相应标准差σ;S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ
  3. 取反对数

软件质量管理-复习总结

1. 软件开发的四大本质难题

1.1. 四大本质难题是什么

1.2. 四大本质难题之间的关系

1.3. 几个注意点

1.4. 考试题目

2. 软件发展

2.1. 软硬件一体化阶段

2.2. 软件成为独立的产品

2.3. 络化和服务化

2.3.1. 络化和服务化

2.3.2. 更深化的 络化和服务化

2.4. 考试题目

3. 软件工程

3.1. 管理

3.1.1. 软件项目管理

3.1.2. 软件过程管理

3.1.3. 软件过程管理与软件过程改进

3.1.4. 考试题

3.2. 软件过程

3.2.1. 广义软件过程

3.2.2. 生命周期模型

3.2.3. 考试题目

3.2.4. 软件过程管理/改进模型：CMM

3.2.5. 等级一：初始级 Initial

3.2.6. 等级二：可重复级 Repeatable

3.2.7. 等级三：已定义级 Defined

3.2.8. 等级四：已管理级 Managed

3.2.9. 等级五：优化级 Optimizing

3.2.10. 考试题

3.3. 软件过程管理/改进模型：CMMI Capability Maturity Model Integration 能力成熟度集成模型

3.3.1. 等级一：初始级

3.3.2. 等级二：已管理级

3.3.3. 等级三：已定义级

3.3.4. 等级四：定量管理级

3.3.5. 等级五：优化级

3.3.6. 一些理解

3.3.7. 考试题

3.5. 软件过程改进模型：IDEAL模型

4.1.4.3. Kanban方法

4.1.4.4. 考试题

4.1.4.5. 概念解释

4.1.4.6. 描述用途

5. PSP 个体软件过程

5.2. PSP基本原理（为什么要有PSP）

5.3. PSP的成熟度级别

5.4.6.5. PROBE估算过程

5.4.6.6. 注意点1：整理历史数据

相关推荐

2.3.2. 更深化的络化和服务化