分粥的启示：通过设计一套合适的软件过程可以解决开发中的问题 影响软件产品质量和软件项目生产率的共同因素主要有3个：人员、技术和过程。 软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。 重要人物
软件过程的分类与组成 软件基本过程：软件获取、供应、开发、运行和维护的过程，包括需求分析、软件设计、编码等过程。 软件支持过程：对软件主要过程提供支持的过程，包括文档编制过程、配置管理过程、质量保证过程、验证和确认过程（测试过程）、评审过程等。 软件组织过程：对软件主要过程和支持过程的组织保证过程，包括管理过程、基础设施过程、改进过程和培训过程。
CMM PSP/TSP RUP 敏捷过程 极限编程 SCRUM 平衡敏捷与规范
PSP——Personal Software Process，个体软件过程 是一种个体级用于管理和改进软件工程师个人工作方式的持续改进过程
PSP是包括了数据记录表格、过程操作指南和规程在内的结构化框架 一个基本的PSP流程包括策划、设计、编码、编译、单元测试以及总结等阶段 在每个阶段，都有相应的过程操作指南（过程脚本），用以指导该阶段的开发活动 所有的开发活动都需要记录相应的时间日志与缺陷日志
软件系统的整体质量由该系统中质量最差的某些组件所决定； 软件组件的质量取决于开发这些组件的软件工程师，更加确切的说，是由这些工程师所使用的开发过程所决定； 作为合格的软件工程师，应当自己度量、跟踪自己的工作，应当自己管理软件组件的质量； 作为合格的软件工程师，应当从自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践中，也就是说，应当建立持续地自我改进机制。
个体度量过程——PSP0和PSP0.1 个体规划过程——PSP1和PSP1.1 个体质量管理过程——PSP2和PSP2.1 个体循环过程——PSP3(TSP)
PSP基本度量项 时间：时间日志 缺陷：缺陷类型标准、缺陷日志 度量方式：代码行、功能点、PROBE基于代理的估算（模块、类、方法） 规模
通用计划框架 (1) 定义需求 (2) 概要设计 (3) 规模估算 (4) 资源估算 (5) 日程计划 (6) 开发产品
PROBE估算流程 包括概要设计、代理识别、估算并调整程序规模（时间）、计算预测区间等步骤
PROBE应用： 历史数据的处理 有限的历史数据 个别极端数据的处理
简单方法 将每个方法的代码行数进行排序 选择最小值作为VS 选择最大值作为VL 选择中值作为M 选择VS与M的均值作为S 选择VL与M的均值作为L
正态分布 选择所有数据的均值作为M，计算所有数据的标准差 σ S = M - σ, VS = M -2 σ, L = M+ σ, VL = M+2 σ
对数正态分布 大部分人习惯写很多规模很小的程序，少量规模较大的程序；程序的规模不可能出现负数 以e为底计算所有数据的自然对数 (lnX) 计算取对数之后的值的均值M，计算相应标准差 σ S = M - σ ，VS = M - 2 σ ，L = M + σ ，VL = M + 2 σ 取反对数(eY)
对比 简单方法 计算简单，但不稳定，随着新数据的加入会造成相对大小矩阵数据的大幅度调整 正态分布法 相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵，但实际上程序规模的分布并不是正态的 对数正态分布法 更加符合人们对于程序规模的直观感觉，PSP中大部分情况下都使用对数正态分布法来对历史数据进行整理，进而获得相对大小矩阵；需要经常维护和更新相对大小矩阵
Probe方法依赖历史数据，但是实际历史数据有可能： 历史数据少于3个数据点 有足够的历史数据，但是数据的质量不高
相关性描述的是两组变化的数据之间相互关联的程度，通常用字母r来表示 在PSP中为确保估算质量，对于历史数据的相关性要求r≥0.7显著性描述的是上述两组数据的相关关系出现的偶然性 如果显著性接近1，说明出现这样的相关性是非常偶然的现象 显著性越小越好，在PSP中要求显著性s≤0.05在PSP中，应用PROBE方法主要用来估算规模和时间 根据历史数据的数量和质量，PROBE分为A、B、C、D四类方法 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-19quK9Ez-1593873834323)(./images/1591772742778.png)] 参考的历史数据主要是代理规模、计划程序规模和实际程序规模 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mg2OCMRe-1593873834327)(./images/1591772782881.png)] 参考的历史数据主要是代理规模、计划程序规模和实际开发时间
如果出现较高的相关性是极其偶然的现象，不能使用A方法和B方法
一款软件产品的质量取决于该软件系统中质量最差的那个组件 如果希望获得高质量产品，就必须确保组成该软件产品的各个组件都要是高质量的 高质量的产品意味着组成软件产品的各个组件基本无缺陷 一个缺陷在开发过程中停留的时间越久，消除它的代价就越高，而且代价的增长往往是指数增长
用缺陷管理来替代质量管理 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷 各个组件的高质量是通过高质量评审来实现的
个人评审(review)和小组评审(inspection)在发现缺陷的效率上往往高于系统测试 测试消除缺陷的代价显著高于评审发现缺陷的代价 测试中这一步极为耗时：调试程序，找出出错的位置，确定出错原因【极为耗时】 而评审中发现缺陷的同时，也知道了缺陷的位置和原因
Yield指标用以度量每个阶段在消除缺陷方面的效率。 Phase Yield = 100 * (某阶段发现的缺陷个数)/(某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数) Process Yield = 100 * (第一次编译前发现的缺陷个数)/(第一次编译前注入的缺陷个数)
在PSP中，典型的缺陷注入阶段 设计阶段 编码阶段 典型的缺陷消除阶段 设计评审 代码评审 编译 单元测试（修改缺陷的过程中有可能会引入新的缺陷）
无历史数据估算： 将单元测试阶段的Phase Yield设定为50 将缺陷按照比例分配到各个缺陷的注入阶段，重新计算Phase Yield的估算值
A/FR (Appraisal to Failure Ratio)：质检失效比 质量成本(Cost Of Quality, COQ)：用来量化质量问题所带来的成本消耗 COQ的三个主要组成部分： 失效成本：分析失效现象，查找原因、做必要的修改所消耗的成本 质检成本：评价软件产品，确定其质量状况所消耗的成本 预防成本：识别缺陷根本原因、采取措施预防其再次发生所消耗的成本
A/FR = PSP质检成本/PSP失效成本 PSP中定义的失效成本为编译时间和单元测试时间之和 PSP中定义的质检成本为设计评审时间与代码评审时间之和 当A/FR小于2.0时，测试阶段发现的缺陷数目较多 当A/FR大于或者等于2.0时，测试阶段发现的缺陷数目较少 为了确保较高的质量水平，软件工程师应当花费两倍于编译加测试的时间进行评审工作，评审的对象为设计和代码
PQI (Process Quality Index)：过程质量指标 用以度量PSP过程的整体质量 PQI用来全面刻画软件过程质量 它是5个过程质量指标的乘积 设计质量 设计评审质量 代码质量 代码评审质量 程序质量
5个过程质量指标分别基于如下高质量过程特征： 设计质量：设计时间应该大于编码的时间 设计评审质量：设计评审时间应该大于设计时间的50% 代码评审质量：代码评审时间应该大于编码时间的50% 代码质量：代码的编译缺陷密度应当小于10个/千行 程序质量：代码的单元测试缺陷密度应当小于5个/千行
评审速度(Review Rate)是一个用以指导软件工程师开展有效评审的指标 高质量的评审需要软件工程师投入足够的时间进行评审 需要为评审设置一个恰当的速度 大量统计数据表明，代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小时
缺陷消除效率比(Defect-Removal Leverage) 度量的是不同缺陷消除手段消除缺陷的效率 其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是DRL 通常，设计评审发现缺陷的效率与单元测试相当 代码评审发现缺陷的效率往往高于单元测试 用以帮助软件工程师判断缺陷消除效率以及组件质量的一个参考值
低劣的设计是导致在软件开发中出现返工、难以维护以及招致用户不满的主要原因之一 充分的设计可以显著减少最终程序的规模，提升质量 在解决相同问题的时候，程序规模的减少往往有助于缓解软件复杂性所带来的种种问题 设计本身也是一种排错的过程
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-wzUE301K-1593873834330)(./images/1591777092967.png)] PSP设计模板 操作规格模板（Operational Specification Template， 简称OST） 功能规格模板（Functional Specification Template， 简称FST） 状态规格模板（State Specification Template，简称SST） 逻辑规格模板（Logical Specification Template，简称LST） [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-UCQhaLjv-1593873834333)(./images/1591777172503.png)] OST（操作规格模板）：描述系统与外界的交互情形 FST（功能规格模板）：描述系统对外的静态接口 SST（状态规格模板）：描述系统的状态信息 LST（逻辑规格模板）：描述系统的静态逻辑
用例图：用以描述系统外部可见的行为 顺序图：通过描述对象之间发送消息的时间顺序显示多个对象之间的交互动作 类图：用以描述系统的静态结构 状态图/状态机图：描述对象实例的所有状态以及导致状态转换的事件 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Moo9GMO1-1593873834335)(./images/1591777238183.png)] UML的用例图和顺序图提供了与PSP中OST同样的信息 UML中的顺序图和类图所描述的类之间的关系以及对象之间的交互信息在PSP4个设计模板中没有对应的内容 UML类图中记录了方法的型构，然而方法的行为没有描述，这一点在PSP的FST中有相应的内容 PSP中的LST用以描述程序的静态逻辑，这在UML没有对应的图示方法 UML中的状态机图与SST描述的状态图类似，但是SST中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的UML图示方法
软件估算的困难性 估算困难是由于软件的本质带来的，特别是其复杂性和不可见性 软件开发是人力密集型工作，因而不能以机械的观点来看待（人与人之间的差异所带来的影响更大） 传统的工程项目经常会以相近的项目做参考，不同的只是客户和地点，而绝大部分软件项目是独一无二的 新技术的不断出现和应用 缺少项目经验数据，许多组织无法提供原有项目数据，而即使提供了这些项目数据，也未必非常有用 广泛存在的不明确性：某些人试图建立一个过去项目的全软件业的数据库，但是许多词汇意义的不明确使得这种努力没有效果，例如“测试”阶段究竟包括哪些活动就不明确。 估计的主观性：人们容易低估小项目的工作量，而过分夸大大项目的工作量。 估计的政治因素：不同的人有不同的目标，如项目经理会高估项目工作量，许多机构采用独立的估算小组，但是将项目经理和项目成员吸收进估算小组，能够增强他们的责任感。
估算技术 自底向上估算：各个部分的工作量先估算出来，然后进行合成 自顶向下估算：首先定义整个项目的工作量，然后分解到各个部分 类比估算法 专家判断法（Delphi技术） 数学模型（功能点、对象点、COCOMO等）
功能点估算 外部输入(External Input, EI)：通过界面等的输入，插入、更新等操作都是典型外部输入 外部输出(External Output, EO)：提供给用户的面向应用的信息，包括报表、打印等输出 内部逻辑文件(Internal Logical File, ILF)：可以理解为用户看到的一个完整的业务对象，一个逻辑文件可能对应多个数据表 ，也可以对应数据库中的表和一些独立的文件 外部接口文件(External Interface Files, EIF)：与其他系统交换数据 外部查询(External Inquiry/Queries, EQ)：先要输入数据，再根据输入数据即时获得输出，例如查询
功能点的计算公式 FP = UFC * TCF UFC(Unadjusted Function Counting)：未调整功能点计数 TCF(Technical Complexity Factor)：技术复杂度因子
(1) 基本COCOMO模型 基本COCOMO模型是一个静态单变量模型，它用以源代码行数（LOC）为自变量的（经验）函数来计算软件开发工作量。 Effort = c × Size^k (2) 中间COCOMO模型 中间COCOMO模型则在用KLOC或KDSI为自变量的函数计算软件开发工作量（此时称为名义工作量）的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KnKRcQHs-1593873834338)(./images/1591777878119.png)] （3）详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤（分析、设计等）的影响。
c, k的取值根据系统的分类而定： 根据系统的技术特性和开发环境可以分为： (1) 有机模式(Organic Mode): 相对小的团队在一个高度熟悉的内部环境中开发规模较小、功能较简单的软件项目。 开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小，程序的规模不是很大（<50000行）。 信息系统通常属于有机模式。 (2) 嵌入式模式(Embedded Mode)：开发的产品在高度约束的条件下进行，对系统进行修改的成本很高。 要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口、数据结构、算法的要求高。软件的规模大小任意。其中包含一些庞大而复杂的航空航天控制系统、大型操作系统、交通指挥系统等。 实时系统属于嵌入式模式。 (3) 半分离模式(Semi-detached Mode)：介于上述两者之间。 规模和复杂度都属于中等或以上，代码规模可达数十万行。 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0UsBpypB-1593873834340)(./images/1591777804135.png)] Effort单位为人月(PM/MM)：1人月=19人日=152人时 Size单位为千行代码(KSLOC)或KDSI Time单位为月(M)
工作分解结构(Work Breakdown Structure，简称WBS)是以可交付成果为导向的对满足项目目标和开发交付产物的项目相关工作进行的分解 它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义 [PMBOK, 2008] WBS处于计划过程的中心，是控制项目范围以及制定进度计划、资源需求、成本预算、风险管理计划和采购计划等的重要基础
识别风险之后，就应当制定相应的风险管理策略，以应对各类风险 典型的策略包括： 风险转嫁 风险解决 风险缓解
PV: Planned Value, 计划价值 EV: Earned Value, 挣值 AC: Actual Cost，实际成本 BAC表示按照PV值的曲线，当项目完成的时候所需预算或者时间 成本差异CV = EV-AC，表示的是已经完成的工作与所消耗的成本的差异 成本差异指数CPI = EV/AC，表示单位成本创造的价值 日程偏差SV = EV – PV，表示进度偏差 日程偏差指数SPI = EV/PV 预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的进展以及成本消耗情况，整个项目完成的时候所需消耗的成本
基于PMBOK的总结 范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整合管理9大知识域
项目组长 计划经理 开发经理 质量经理 过程经理 支持经理
Scrum是管理软件项目的一个轻量级的敏捷软件方法，名字来源于橄榄球运动中的Scrum过程 Scrum是指橄榄球里的争球 简单，但高度的纪律性 依赖迭代和增量的敏捷方法 Scrum 是一种工作管理的方法，不仅仅限于软件开发，可以用来管理其他活动 Scrum不包含技术方法或实践
划分为多个迭代过程，在Scrum中称为冲刺(Sprint)，通常持续2-4周的时间，开发团队会在此期间内完成所承诺的一组订单项的开发 Sprint的时间是固定的，不能从外部改变正在进行中的Sprint的持续时间和范围 每个Sprint都可以产生可交付的迭代产品，即实现并测试通过文档所包含的功能点 原则上，当产品开发到一定程度时，如果实现了足够的客户价值，项目可以在任何一个Sprint后结束
Scrum项目阶段划分 规划（产品定义）：运行Sprints 所需要的准备、规划和技术分析 执行（执行Sprints）：在增量时间段内实现需求 结束：准备最终发布，结束项目
Scrum定义了许多角色，分为“猪”和“鸡”两组 猪角色：产品负责人(Product Owner)、Scrum Master、开发团队(Scrum Team) 鸡角色：客户、管理层
产品订单(Product Backlog) 产品订单(Product Backlog, PB)是整个项目的概要文档，它包含已划分优先级的、项目将要开发的系统或者产品的需求清单，包括功能和非功能需求及其他假设和约束条件，也可称为User Stories（用户故事） 产品的需求清单是动态的
冲刺订单(Sprint Backlog) 冲刺订单(Sprint Backlog, SB)是产品订单的细化的子集，包含团队如何实现下一个冲刺的需求信息
燃尽图(Burndown Chart) 燃尽图(Burndown chart)是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目
冲刺计划会议(Sprint Planning Meeting)：在每个冲刺之初，由产品负责人讲解需求，并由开发团队进行估算的计划会议。 每日站立会议(Daily Standup Meeting)：团队每天进行沟通的内部短会，因一般只有15分钟且站立进行而得名。 评审会议(Review Meeting)：在冲刺结束前给产品负责人演示并接受评价的会议。 回顾会议(Retrospective Meeting)：在冲刺结束后召开的关于自我持续改进的会议。
任务看板（简称为看板）是一种使用可视化管理的方式，跟踪任务在整个价值流中流经的不同阶段，通常我们会用带贴纸的白板或是电子卡片墙。
可以用来估算产品订单中每个订单项的规模（规模估算：故事点 Story Point）以及冲刺订单中任务的估计（工作量估算：人时）
CMM可以指导软件机构如何控制软件产品的开发和维护过程，以及如何向成熟的软件工程体系演化，并形成一套良性循环的管理文化。 CMM包括5个级：初始级（Initial）；可重复级（Repeatable）；已定义级（Defined）；已管理级（Managed）；优化级（Optimizing）。
CMM的主要用途 (1) 用于软件过程评估(SPA, Software Process Assessment)：在评估中，一组经过培训的软件专业人员确定出一个企业软件过程的状况，找出该企业所面对的与软件过程有关的、最急需解决的所有问题，以便取得企业领导层对软件过程改进的支持。 (2) 用于软件过程改进(SPI, Software Process Improvement)：帮助软件企业对其软件过程向更好的方向的改变，进行计划、制定以及实施。 (3) 用于软件能力评价(SCE, Software Capability Evaluation)：在能力评价中，一组经过培训的专业人员鉴别出软件承包者的能力资格；检查和监察正用于软件开发的软件过程的状况。
CMM中包含5个等级，18个关键过程域KPA 每个KPA都有若干目标(Goal)，共有52个目标 每个KPA包含实现目标所必需的若干个重要活动，称之为关键实践(Key Practice, KP)，共有316个关键实践
5 优化级(2) 4 定量管理级(2) 3 已定义级(11) 2 已管理级(7) 1 初始级(0)
