扫码阅读
手机扫码阅读
评审的分类
200 2024-10-02
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:评审的分类
文章来源:
麦哲思科技任甲林
扫码关注公众号
软件企业评审分类摘要
软件企业的评审可分为管理类评审和技术类评审,两者目的、流程、参与人员以及准则各有差异。管理类评审的目的是发现和解决管理问题,涉及到项目监督控制、过程审计和过程评估。而技术类评审则旨在发现工作产品中的缺陷和进行技术决策,包括走查、技术复审和审查三种形式。
管理类评审
- 项目监督控制评审:涉及各种周期性会议,目标是监督项目执行情况。
- 过程审计:由PPQA人员对照标准和规范进行监督。
- 过程评估:评估组织的标准与规范是否适合实际情况,以发现改进点。
技术类评审
技术类评审又称为同行评审,根据严格程度分为:
- 走查:不需要提前准备,由作者主持,结论较为宽松。
- 技术复审:由技术负责人主持,多位专家参加,要求事先准备。
- 审查:由专门主持人主持,多位专家参与,需要正式的评审报告。
这些评审方式通过目的、入口准则、评审材料数量、参与人员数量、评审主持人等方面进行区分。它们在不同企业中可以进化为不同的评审方式,如邮件评审、个人评审、会议评审等。
实践中,管理类评审和技术类评审常被合并执行,但这种做法是不提倡的。两类评审应保持独立,以免降低评审效率和质量。
想要了解更多内容?
查看原文:评审的分类
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 134.4K
麦哲思科技任甲林的其他文章
我说CMMI之八:过程的基本概念
我们做过程管理,天天都在讲过程二字,真要给过程下个定义却没有那么容易。正如我们天天说某某是好人,某某是坏人,啥是好人,啥是坏人很难明确定义。但是这却是无法回避的问题,因此我们必须给过程下一个定义。 在CMMI-DEV V1.3模型P449中对过程下了一个定义,全文如下:A set of interrelated activities, which transform inputs into outputs, to achieve a given purpose. (See also “process
数据、现象与原因
某公司积累了最近2年24个项目缺陷发生率的历史数据(缺陷发生率为系统测试发现的缺陷个数除以开发的工作量),如下表所示: 对上述的历史数据,按年份画箱线图比较分析如下: 针对上述的箱线图,是否可以下结论认为2013年开发质量提升了,开发人员犯的错误就少了呢? 其实未必。 如果对年份与项目的开发方式做卡方分析,则有如下的结论:汇总统
系统测试成功的关键点
(1)系统测试人员参与需求评审 (2)定义明确的测试需求 (3)测试人员要在需求阶段介入项目组 (4)系统测试用例要覆盖所有的场景 (5)建立产品需求与测试用例的跟踪矩阵 (6)评审测试用例 (7)利用回归测试工具 (8)
一表搞定最小可行产品(MVP)与最小可市场化特性(MMF)
MVP是最小可行产品,MMF是最小可市场化特性,这是精益与敏捷中的两个术语,很多人不能准确理解这2个概念的差别,我试图用一个表格对这2个概念进行概括总结: MVP(Minimum Viable Product),最小可行产品 MMF(minimum marketable feature),最小可市场化特性 含义 最小:抓住用户核心诉求提供最优解,控制需求范围和项目预算,降低产品创新试错成本。 可行:提供足够的价值,客户愿意花钱(或其他货币,如个人信息)……...
需求变更对软件质量的影响
根据我们的经验,需求变更越多,造成的软件修改越多,bug也就会越多,事实是否如此呢?需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数,参见下表,基于这些历史数据我们分析一下,看看我们的经验结论是否成立。表一:需求变更的历史数据 ID 需求变更数 代码规模LOC 总缺陷数 测试缺陷密度bugs/KLOC
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线