"SUP.9 问题解决管理"过程的目的是确保问题被识别、分析、管理和控制,以解决问题。
我们需要讨论的第1个Topic就是:哪些问题需要被管理起来呢?
我们可以查一下ASPICE PAM V3.1中的描述,其中提到SUP.9的内容如下图所示:
从上图可以看出:静态分析和测试检测到的产品缺陷、验证(评审)发现的产品问题、质量保证活动中识别的产品问题需要遵照SUP.9的要求进行管理。
采用系统化的方式进行问题管理的目的是为了“可控”及降低风险。从这方面来考虑的话:”SUP.9 问题解决管理“的另外一个考虑纬度就是,当问题满足如下两个条件的时候,一般需要纳入SUP.9进行管理:
问题的解决需要多人参与,例如:测试人员识别的问题,需要开发人员解决,然后需要测试人员进行确认。
不能被立即解决的问题,需要记录和管理起来(中国有句俗话:好记性不如烂笔头~~)
根据问题类型的重要度,一般来说:
客户提出的问题 & 独立测试组测试检测到的缺陷:必须完全严格按照SUP.9进行管理
开发团队自行测试发现的缺陷:建议完全严格按照SUP.9进行管理
评审发现的问题:可选
(1) 问题解决策略
<ASPICE模型要求>
SUP.9.BP1: 制定问题解决管理策略 / Develop a problem resolution management strategy
制定问题解决管理策略,包括问题解决活动、问题的状态模型、警报通知、执行这些活动的责任和紧急解决策略。定义受影响方的接口并维护该定义。
Develop a problem resolution management strategy, including problem resolution activities, a status model for the problems, alert notifications, responsibilities for performing these activities and an urgent resolution strategy. Interfaces to affected parties are defined and definitions are maintained
问题解决策略:
需明确问题管理的范围:哪些问题需要进行怎样的管理?
需考虑各个学科(如:系统、软件等)和各个领域(如:应用层软件、底层等)
需考虑所有的相关方,如客户、供应商、内部相关方等
需考虑不同学科、领域、相关方以及不同Loation之间的问题管理和信息交互
需定义问题处理流程及问题状态模型
需根据问题的原因和影响对问题进行分类
需定义紧急问题的处理策略,包括判定准则(什么样的问题是紧急问题?)
需定义必要时的影响通知机制,包括判定准则(什么样的问题需要进行通知?)
需要定义问题修改时,与变更请求或基线的对应方法
[SUP.9.RL.1] If the strategy does not include all aspects above, the indicator BP1 must not be rated F.
老杨解读:如果策略中没有包括上述的各点,则BP1的打分不能是F。
[SUP.9.RL.2] If the strategy does not address interfaces between multisite organizations/projects, subprojects, and/or groups in case of correspondingly complex projects, the indicator BP1 must not be rated higher than P.
老杨解读:如果策略中没有包括在复杂项目组织结构的场景下的不同组织/项目、子项目/子组,则BP1的打分不能高于P。
(2) 确定问题原因和影响分析
<ASPICE模型要求>
SUP.9.BP4: 诊断问题的原因,确定问题的影响 / Diagnose the cause and determine the impact of the problem
调查问题并确定其原因和影响,以便对问题进行分类并确定适当的行动。
Investigate the problem and determine its cause and impact in order to categorize the problem and to determine appropriate actions
SUP.9.BP6: 发出警报通知 / Raise alert notifications
根据策略,如果问题对其它系统或其他受影响方有很大影响,则需要根据策略发出警报通知
If according to the strategy the problem has a high impact on other systems or other affected parties, an alert notification needs to be raised also according to the strategy
[SUP.9.RL.3] If the impact analysis does not adequately address potential side effects due to insufficient involvement of relevant stakeholders, the indicator BP4 must not be rated F.
老杨解读:在问题的影响分析时,如果由于没有让问题的相关方参与分析,而使得影响分析的不充分,则BP4的打分不能是F。
[SUP.9.RL.4] If the impact analysis is incomplete due to missing consideration of similar problems in the same application or potential effects on other systems, the indicator BP4 must not be rated F.
老杨解读:在问题的影响分析时,如果由于未考虑相同应用中的类似问题或对其它系统的潜在影响而导致影响分析不完整,则BP4的打分不能为F。
[SUP.9.RL.5] If affected work products are not identified by the impact analysis, the indicator BP4 must not be rated F.
老杨解读:在问题的影响分析时,如果没有识别影响的工作产品,则BP4的打分不能为F。
[SUP.9.RL.6] If there is no evidence for required alert notifications due to missing consideration of potential effects on clones, variants or oth-er systems, the indicator BP6 shall be downrated.
老杨解读:在问题的影响分析时,如果未考虑代码拷贝、不同变体等对其它系统的影响,而没有进行警告通知,则应减低BP6的打分。
(3) 问题状态模型和问题处理工作流
问题处理的工作流:是指问题需要经过哪些“处理活动”,每个处理活动的责任人、处理内容、活动进入和结束标准等。
问题状态模型:当问题经过“某一个处理活动”后,其状态应有所变化,以反映问题的进展。比如:测试人员“登录”问题后,问题的状态变为"已登录"。
不同的组织、不同的项目结构、不同的角色人员,其问题处理的工作流和问题状态模型是不尽相同的。
需要遵循的原则是:
某一个活动,不能由2个及以上的角色共同负责。
如:测试人员负责缺陷的"登录",开发经理负责对缺陷进行初步分析,然后将缺陷分配给具体的工程师。在这种场景下,不能把测试人员的处理活动与开发经理的处理活动合并为一个活动(比如:登录及分析分配)。
1个角色在处理问题时,问题的状态不能变化2次。
如:在一个小的开发团队里面,有3个开发人员,1个测试人员,测试人员对开发人员的职责分工非常了解。测试人员负责缺陷的"登录",然后将缺陷分配给具体的工程师。在这个场景下,没有必要分别定义“缺陷登录”和"缺陷分配"两个活动。可以将其合并为1个活动(如:登录及分配)
下图是一个问题状态模型的示例,供大家参考(可以关注一下:里面有两个Close状态,1个是Close Developmentn,1个是Close Customer)
该图源自:《Automotive SPICE in Practice》
接下来言归正传,看一看VDA Guideline中的内容
<ASPICE模型要求>
SUP.9.BP3: 记录问题状态 / Record the status of problems
根据状态模型,给每个问题分配状态以便于跟踪
A status according to the status model is assigned to each problem to facilitate tracking.
SUP.9.BP8: 跟踪问题至关闭 / Track problems to closure
跟踪问题的状态至关闭,包括所有相关的变更请求。在问题关闭前必须有授权的正式验收
Track the status of problems to closure including all related change requests. A formal acceptance has to be authorized before closing the problem.
[SUP.9.RL.7] If the strategy does not include the definition of a status model, workflow, criteria for status changes, stakeholder and their authorization, the indicator BP1 shall be downrated.
老杨解读:如果策略中没有包括状态模型的定义、工作流、状态跳转条件/准则、相关方及其责任或授权,则应减低BP1的打分。
[SUP.9.RL.8] If the status model and workflow does not fit to the actual way of working or is not applied correspondingly, the indicator BP3 must not be rated higher than P.
老杨解读:如果状态模型和工作流不适合实际的工作或没有被恰当的应用,则BP3的打分不能高于P。
[SUP.9.RC.1] If the initiator of the problem is not also authorizing the closure of the problem, the indicator BP8 should be downrated.
老杨解读:如果问题的提出者没有被赋予关闭问题的权利,则可以降低BP8的打分。