效能与质量
研发阶段和效率价值金字塔
需求调研和评审>技术方案设计和评审>研发>测试
度量
CMMI级别中和BUG率相关的信息
| CMMI级别 | BUG率 |
|---|---|
| CMM1级 | 11.95‰ |
| CMM2级 | 5.52‰ |
| CMM3级 | 2.39‰ |
| CMM4级 | 0.92‰ |
| CMM5级 | 0.32‰ |
考核千行代码Bug率的问题
代码行数<>价值
考核标准：Bug率数值越小就说明越好->尽量增大代码行数
考核阶段：Bug率的数据主要产出在研发阶段的后期，及提交测试后产出bug数->从项目的研发阶段和效率价值金字塔来看，其对项目的整体质量方面更多的聚焦在微观层面问题，整体的质量的影响范围会较小。
更合理的度量质量
需求的评审
架构设计方案评审
代码模块设计，包的依赖的规划，接口的设计的review
代码的review的机制
测试用例评审
使用代码检测工具，自动发现问题
过程评审是最有效也是成本最低的质量和效率保证和提升的手段。另外，过程评审还是迅速提高新人能力及其成果物的规范性的一个有效手段。
系统质量是要靠上游工程做出来的
上游的工作质量会更为重要，上游的问题的影响范围将更广，对效率和价值的影响更大，应该是我们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关，是十分低效，而且代价是非常昂贵的。
需求
需求管理
1.需求要被管理，被管理的意思又有两层：一是需求要被确认，二是要控制需求变更
2.需求要用来指导下游的工作产品，如：计划、设计、测试等
常见问题
1.因为项目进度赶等原因，在很多需求还没有明确情况下，便开始开发的工作。
2.开始客户只能提出模糊的需求，客户喜欢先让你做个东西给他看，然后他才可能逐渐提出真正的需求，而需求调研人员，对此没有什么好的处理办法。
3.客户以种种原因不签需求，项目组在不签需求的情况下，便开始开发工作。
4.客户不承认之前提出来的需求，项目组又不能得失客户，项目成员苦不堪言。
5.需求经常变化，无法控制。
6.设计、代码与需求不对应，特别是需求变更时，不知道应该修改哪部分，也不知道会有哪些影响
优秀的需求管理要素：
开发者应该理解需求
通过客户确认（记录）
需求变更管理（记录确认，影响清单确认）
需求双向跟踪维护（纵向：上下游工作产品之间的跟踪关系。横向：需求与需求之间的关系、设计与设计之前的关系、代码与代码之间的关系等）
需求与下游工作产品差异识别（需求变更时：双向跟踪表影响内容同步修改；编写写或者修改计划、设计、代码、测试计划、测试用例等需求下游工作产品时：要与需求保持一致）
实现
工具赋能：需求管理平台<->aido
需求开发
用系统的方法获取真正的全面的能实现的需求
常见问题
没有把握好客户需求，直接进入软件的细节，去讨论要做什么功能，界面要怎样设计去了，而忘记了软件的根本目的是为了解决什么问题。
明确客户需求后，就应该把客户需求转变成产品需求和产品组件需求，客户需求一般都是比较高层次的，而且描述也会比较简单，不能作为日后验收的标准，我们需要对软件的规格进行说明。一般来说，我们写的软件规格说明书都会包含产品需求和产品组件需求的。我们导出产品需求和产品组件需求的时候，要注意产品需求和产品组件需求，必须和客户需求对应起来，通常是多对多的关系。为什么要对应起来？我们要保证，软件的每一个界面，每一个功能都是有用的，都是“源自”客户需求的，这样才能保证我们做的事情都是正确的事情，防止被不相干的事情干扰。
客户需求
可以理解成客户为什么要做本系统，要解决什么问题，客户对系统有怎样的期望，希望能具备一些怎样的特点，简单的说，就是客户的需要是什么。
产品需求
是能满足客户需求，并对软件产品规格进行了详细描述的需求，软件设计师可以根据产品需求进行设计、编码等工作。
产品组件需求
是对产品需求的进一步细化，产品可能会分割成几个子系统、几个部分，每个子系统每部分要具备怎样的功能、要具备怎样的性能、接口要求等，这些可以认为是产品组件需求。
另外一个角度，需求可以分为功能性需求和非功能性需求两类，功能性需求就是系统具备怎样的功能，能做什么事情，而非功能性需求就是指系统要具备怎样的性能、安全级别等方面的要求。客户需求、产品需求和产品组件需求，都会包含功能需求和非功能需求。
优秀的需求开发要素：
干系人的需要、期望、约束和接口要求被收集并转化为客户需求
让客户能完整无遗漏准确地表达出他的想法：（原型、图示、类比、问卷）系统的目标、范围、解决什么问题、希望系统具备怎样的一些特性，满足一些什么接口要求和约束条件等
把客户原始的需求信息整理成正式的客户需求：通常会包括对系统目标、范围、解决问题、软件特性、接口要求等有详细的描述。
客户需求是精确和详细的，以用来开发产品需求和产品组件需求
产品和产品组件需求：对软件规格的描述，详细描述软件与用户是怎样交互的，用户需要输入什么，系统输出等都会比较详细描述出来。可做验收标准
分配需求给每一个产品组件：所有的需求应该与设计的产品组件对应，保证需求驱动后续的设计工作，同时也保证设计都是为需求服务定义接口需求：包括系统与第三方的系统的接口要求，也包括系统本身各组件、各子系统、各部分之间的接口要求
需求被分析和确认，并定义出具体的功能性需求
操作场景与功能定义：描述出具体需求的操作场景、上下文，具体的操作步骤，对功能的详细描述等。通常我们可以通过序列图等来表达这些内容
分析需求：准确性、全面性、可实现性，平衡约束条件，确保需求符合最终的使用场景要求。通常是通过需求评审
开发
技术方案
常见问题
1)无设计文档
2)有设计文档，但形同虚设
3)设计时没有考虑可以重用以前项目或者第三方的代码或组件
4)没有用需求来驱动设计
5)设计没有考虑多过一个的方案
6)没有考虑清楚设计的原则和标准
7)设计的弹性不够、架构落后？
8)代码与设计脱节？
9)到处都是面条式代码
优秀的技术方案要素：
从候选方案中选择产品或者产品组件的解决方案
先考虑好我们设计方案的选择标准，并找出可能的候选方案
对产品的规格进行详细的表述，操作概念、场景、环境、操作模式和操作状态等
根据选择标准选出最佳方案
开发产品或者产品组件设计
概要设计：建立产品功能和框架，包含产品组成区块、产品组件界定、系统状态与模式、主要的内外部接口和界面设计（功能模块设计、数据库设计包括逻辑设计和物理设计及安全性能设计、模块接口和界面设计）
详细设计：完整定义产品组件的结构和功能，详细描述实现方法、算法
建立和维护技术数据包：（需求、设计资料等）为开发者提供开发产品或组件的综合性描述，以及产品架构描述、分配需求、产品组件的描述、产品相关生命周期过程描述、关键产品特性、必需的物理特征和约束、接口需求、用于确保实现需求的验证准则等。
设计合适的产品组件接口：考虑外部接口和内部接口；与原来系统的关系；
产品组件开发、购买或者重用评估：技术状况
实施产品组件的设计
编码：适当的标准与准则，走查，单元测试
用户文档：用户手册、安装手册、管理员手册、在线帮助等
产品集成
常见问题
时序
优秀的产品集成要素：
完成产品集成的准备工作
建立并维护产品组件的产品集成流程
建立并维护产品组件集成与评估标准
建立并维护产品组件的确认与交付标准
确保产品内部与外部的接口是兼容的
检查接口描述，保证覆盖性和完整性：通常通过评审接口说明。包括产品组件接口，产品集成所有环境的接口（定期）
管理产品和产品组件的内部和外部接口的定义、设计及变更：管理各组件之间的关系，保证组件间保持一致（配置库）
组合已集成的产品组件，并交付已集成、已验证、已确认的产品
在产品集成前，确定要集成的产品的产品组件已被确认、并依据其说明执行，并且确定产品集成接口符合接口说明
根据产品集成顺序和相关过程集成产品组件
评估产品组件的接口兼容性
打包组装已集成的产品或组件，并交付给适当的客户
实现
工具赋能：统一环境管理，持续集成，持续交付