评审
- 基本信息
CMMI是Capability Maturity Model Integration的简称，即软件能力成熟度模型集成。由SW-CMM（软件能力成熟度模型）演化而来。子模型分为开发模型、服务模型、采购模型。我们常说的开发模型。
- 宗旨和意义
一个引领组织获得高绩效运营的过程改进框架模型。不是一个单一的过程，而是集成了软件工程、系统工程、项目管理、过程管理、供应商管理、集成产品开发、敏捷软件开发等领域的最新实践，是几十年来全球软件工程、系统工程的最佳实践的总结。它把软件工程过程中的每个可能的环节、步骤活动进行详细的定义、规范，但是它并没有告诉我们应该怎样做，而只是告诉我们应该做些什么（Not how to do, but what to do）。
- 能力级别
初始级Initial 、已管理级managed、已定义级Managed Defined 、量化管理级 Quantitatively、 持续优化级Optimizing，国内大部分三级？？？
初始级：大致是管理混乱，组织病态，个人主义，成功经验不可复制。
已管理级： 大致是有稳定开发环境，项目可控，排除任务完成的随机性，保证项目都会成功。
已定义级： 已经有适合企业和项目的标准流程。并把流程规范化。开始有项目经验积累。
量化管理级：顾名思义，大致所有的结果可预测，所有过程可量化。
持续优化级： 数据挖掘与创新了。
- 过程域分类
开发模型分为四大类22个小类。
4大类： 项目管理类、工程类、支持类、过程管理类。
22小类：
【项目管理类】 REQM需求管理、PP项目计划、PMC项目监控、SAM供应商协议管理、IPM集成项目管理、RSKM风险管理、QPM量化项目管理。
【工程类】RD需求开发、TS技术解决方案、PI产品集成、VER验证、VAL确认。
【支持类】PPQA过程与产品质量保证、CM配置管理、MA度量与分析、DAR决策分析与解决、CAR原因分析与解决。
【过程管理类】OPF组织过程焦点、OPD组织过程定义、OT组织培训、OPP组织过程性能、OPM组织绩效管理。
- 角色简称
EPG ： 过程改进小组
OT： 培训
CM： 配置管理
QA： 质量管理
需求：需求
开发：开发
测试：测试
- 开发人员的小册子
Q1: 开发过程域？
A1： DAR/TS/PI/VER SP2.1/2.2/2.3、公共实践GP。
Q2：是否知道组织级的方针，有没接受过培训？
A2： 有组织级的方针，对于开发来说主要有TS, PI, VER 方针，有接受过方针和过程的培训。
Q3： 是否制定了计划？
A3：制定了开发计划。对整个项目划分阶段，每个阶段的明细任务落实到人头，也按照前端后端对任务进行划分。按照既定计划进行开发。
Q4: 用到了哪些工具、资源？
A4：OFFICE、IDE集成开发工具idea|eclipse、数据库客户端连接工具navicat|toad、服务器连接工具xshell|SecureCRT、版本管理工具git、打包工具maven|ant、比较工具beyond compare、反编译工具jad-ui,以及网络上可靠的开源库等。
Q5：你的职责是什么？是否清楚定义？
A5：我的职责主要服务于项目的工程构建，包括详细设计、概要设计的编写，功能的编码，系统的集成。
Q6： 都参加过哪些培训？
A6：参加过CMMI的培训，学习CMMI的宗旨和意义。参加过公司技术基础平台升级的培训、参加过公司实用工具培训、参加过公司业务范围培训。
Q7：过程有哪些产出？
A7: git管理的代码，详细设计文档，概要设计文档，代码，用户操作手册。
Q8：都有哪些人参与到了此项活动中？
A8：EPG、QA、PM、CM都是于此活动相关的人员。
Q9: 谁监控该过程?如何监控？
A9: 项目经理会进行监控，有周报，月报，里程碑报告。
Q10: PPQA是否审计过你的工作？
A10: QA进行审计，有审计检查单。根据文档体系对风险和质量进行设计。
Q11: 高层有没有参与过评审？高层经理是如何关注过程的？
A11：高层经理会在立项时参加评审，也会参与里程碑报告，我们项目内无法解决的问题，也会回报给高层经理解决。
Q12: 是否遵循了组织的过程定义？
A12: 有裁剪，详设和概设合并。
Q13:有没提过改进建议？举例说明提了一个什么建议？
A13：有，第一、针对实现同一个功能，各个工程师有不同的实现方式，程序质量良莠不齐。建议构建一个工具库，只收纳解决某个问题的可靠代码插件。技能保证程序质量，也可以提升工作效率。
----------------------------------------------TS【技术解决方案】----------------------------------------------------
Q14 ： 识别了几个技术方案，如何进行识别的？
A14： 一般是制定两个或两个以上的候选方案，主要通过市场调研、技术分析和网络搜寻等方式来制定方案，并且编写测试DEMO验证可行性。
Q15：选择准则及其权重是怎样制定的？
A15：选择准则通常来自于客户/公司高层的需求、约束、限制，比如：开发周期；开发成本；技术限制；性能要求等并根据这些准则的重要程度设定不同的权重。
Q16 ： 用什么方法选择技术方案？
A16：使用DAR方法进行技术方案的选择。邀请专家根据评价准则对候选方案进行打分，得出每个方案的最终分值，分数高的为最佳方案。
Q17 ： 如何做设计的？
A17：根据需求->概设->详计->编码。
Q18：设计评审是怎么做的？
A18：邀请专家通过会议的方式进行设计说明书的评审，有使用评审检查单来评审。记录评审发现的问题，并进行解决。
Q19：技术数据包包含哪些内容？如何使用技术数据包？
A19：技术数据包是编码的基础，使用技术数据包进行编码工作。技术数据包包含项目计划，需求说明书，设计说明书，编码规范，接口设计原则等。业务方面严格按照需求说明书来进行功能实现，代码质量方面严格按照编码规范来完成。
Q20：如何设计接口？
A20：根据接口设计原则进行接口的设计，有单一职责、迪米特法则、依赖倒置原则、里氏替换原则、接口隔离原则、开闭原则。主要做到低耦合，高内聚。接口设计原则有可靠性，稳定性、可修改性、可测试性、易理解性、可扩展性等。接口包括内外部接口。内部接口：为系统各模块间的接口：外部接口为系统与外部系统间的接口，以及集成、测试环境的接口等。
Q21：什么时候做制作、购买、复用分析？
A21：在设计阶段进行制作、购买、复用分析。因为公司没有把软件外包出去，因此采购是不会考虑的，因此根据项目时间、资源、成本进行分析，如果有可复用的模块或组件或进行优先考虑，如果没有会进行开发。目前２个项目都是自行开发。
Q22：用什么语言编码？
A22：使用JAVA和React语言进行编码。公司有提供编码规范，对于新手要经过编码规范的培训与学习，通常在项目编码前，开发人员会碰个头进行编码规范的约定，如果大家都非常熟悉则不用这个活动。
Q23：代码评审是怎么做的？单元测试是怎么做的？
A23：代码评审通常使用非正式的评审方式，例如，开发人员互查，项目经理检查等。通过构造假数据、用SWAGGER或者POSTMAN 进行单元测试。
Q24：都编写了哪些用户使用的文档？
A24： 操作手册\安装手册\在线帮助\维护手册等。
Q25：都编写了哪些用户使用的文档？
A25：用户手册。
----------------------------------------------TS【技术解决方案】----------------------------------------------------
----------------------------------------------DAR【决策分析与解决】-----------------------------------------------
Q26：为什么要建立决策分析指南？哪些问题将要进行决策分析？
A26：建立决策分析指南的目的就是要澄清哪些问题需要遵循正式的决策流程，如中高风险的决策；引起进度延期达到一定百分比率或天数，如：15%，10天等；影响项目目标的达成；技术方案的选择；能够重大的降低成本、提高质量、缩短开发周期、降低风险的问题；采购金额达到一定数值时需要决策，如30万。
自己话：有风险可能、有延期可能、影响项目目标、技术方案选型、特别降低成本。
Q27：如何建立评价准则？
A27:评价准则一般为：客户需求；项目\组织环境影响；项目假设和约束；技术限制；风险；项目周期成本等限制，并根据准则的重要程度设定不同的权重。
Q28：如何识别的候选方案？识别了几个候选方案？
A28：1.和相关干系人一起头脑风暴、研讨会等，2.进行市场，技术调查研究，一般识别2个候选方案。
Q29：选用了什么评价方法评价候选方案？
A29：专家讨论打分法，评价过程记录在《DAR评价表》中。
Q30: 如何进行的决策？
A30：选取三个专家，项目经理，开发人员，高层经理根据所定义的评价准则对每个方案进行打分，然后计算每个方案的最终得分，分数最高的为最佳方案。
Q31 ： 最终选择的方案是怎么做决定的？是否考虑了选择的方案相关的风险？
A31：选择得分最高的方案为最佳方案，选择的方案记录在DAR报告中。
----------------------------------------------DAR【决策分析与解决】-----------------------------------------------
----------------------------------------------VER【验证】--------------------------------------------------------------
Q32： 如何准备同行评审？
A32： 首先，确认是一个正式的或非正式的评审，确定评审专家，准备评审检查单，发送评审通知，把评审材料和评审检查单给评审专家进行提前预审，记录预审发现的问题。之后进行会议进行评审。
Q33： 都（进行）参与过哪些同行评审？
A33：参加过项目计划，需求，设计，代码，测试用例，用户手册的评审。 在现场的评审的时候，评审专家一起讨论预审所发现的问题，并识别新的问题，记录评审结果在评审报告中，跟踪问题的解决。
Q34 ： 有没有对同行评审的数据进行分析？
A34 ： 分析预审和正式评审所花费的工作量，评审材料的规模，和发现的问题数，计算评审效率：BUG数/人时和评审速率：LOC/h。
----------------------------------------------VER【验证】--------------------------------------------------------------
-----------------------------------------------PI【产品集成】----------------------------------------------------------
Q35： 是否建立了集成策略？如何进行的产品集成工作？
A35：有产品集成计划，确定了集成顺序和集成策略。（可跟据实际情况作答，是一次性集成还是增量集成？是边集成边测试还是集成完后再测试，有没有集成的先后顺序？）
Q36：集成的时候都需要哪些环境，是怎么准备的？
A36: 在集成计划中确定了集成环境，包括各种软硬件工具、设备。
Q37: 项目/组织级的集成步骤是怎样的？集成的入口、出口准则是怎样的？
A37: 集成计划中确定了集成的步骤和准则。所有模块均通过模块测试后才能集成，出口就是通过冒烟测试。
Q38 : 如何管理接口？
A38: 接口作为设计文档的一部分也要纳入基线管理；当发生变更时要走变更流程。在项目的里程碑评审时要关注接口情况，确保接口是完整的、正确的。
Q： 如何保证内外部接口是兼容的？是否评审了接口描述？
A：接口在需求和设计文档中有定义，在进行需求和设计评审的时候就对接口进行了评审，来保证接口的完整性和覆盖性。并通过集成测试确保接口的兼容性。
Q39 : 集成前是否确认过各个构件是否可用？如何进行确认的？
A39:集成前要确认各个模块均通过测试，然后进行集成
Q: 如何做集成的？
A : 按集成计划中定义的集成顺序、集成步骤进行集成，从下到上（一次性集成）
Q40: 集成测试是怎么做的？
A40: 一边集成，一边测试：
Q41: 交付前要准备什么？交付的方式是怎样的? 交给客户哪些内容？
A41:
1.交付前的准备
1.交付、安装、操作环境要部署好
2.评审需求、设计、产品、测试结果，确保打包交付的顺利进行
2.交付的方式
1.直接部署软件/产品到用户的使用环境中，由用户试运行或验收
3交付的内容
打包的可执行程序、用户手册等支持文档
-----------------------------------------------PI【产品集成】----------------------------------------------------------
E 1 : 过去一年中，CMMI改公司带来的好处和坏处分别有哪些？或公司近一年的最大的改进？
E2：你想要看到什么改进，如办公环境，工作方式方法，企业文化等？
