扫码阅读
手机扫码阅读
开发过程中的八种确认方法
749 2024-10-04
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:开发过程中的八种确认方法
文章来源:
麦哲思科技任甲林
扫码关注公众号
确认活动是确保项目方向正确,满足客户需求的重要过程。它可以在项目的任何阶段进行,特别强调持续性和质量的前移。项目前期的确认活动侧重于需求的质量检测,而项目后期则是验证最终系统是否符合客户的实际需求。
在开发过程中,常见的八种确认手段分别为:
- 原型确认:通过构建系统原型,让客户判断其是否满足需求。
- COSMIC度量需求规模:应用COSMIC方法确保需求描述到可测试程度,明确数据对象、属性等,以避免需求模糊不清。
- 同行评审:让不同职能的同事评审需求文档,以多角度识别潜在问题。
- 编写测试用例:通过高层次的测试用例,确保需求的完备性和明确性。
- 增量交付:分步骤交付产品,早期获取客户反馈,避免最后阶段才发现问题。
- 模拟环境测试:在模拟环境中测试系统,检测可能的问题。
- 真实环境试运行:在实际环境中试运行,让客户体验以检查需求满足度。
- 系统上线后的反馈:收集客户在系统上线后的使用反馈,尽管时机较晚,但是它是确认系统满足需求的最终手段。
需要区分的是,代码走查、集成测试、静态扫描、设计评审等属于验证行为,并非确认活动。
想要了解更多内容?
查看原文:开发过程中的八种确认方法
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
425 篇文章
浏览 103.5K
麦哲思科技任甲林的其他文章
七种场景下的软件工作量估算步骤
场景一:合同前的工作量估算场景描述:(1) 没有实施过CMMI2级(2) 合同未签,需要给客户报价(3) 有客户的概要需求,有类似的项目数据可供参考(4) 需要估计整个项目的总工作量,以便于估算总成本,给客户报价估算步骤:(1)寻找类似的历史项目,进行项目的类比分析,根据历史项目的工作量凭经验估计本项目的总工作量;(2)进行WBS分解,力所能及地将整个项目的任务进行分解;(3)参考类似项目的数据,
两个浪漫的人,一本理性的书
“两个浪漫的人,一本理性的书”是我对《重构极限编程》一书的评价。 书买了有一段时间了,浏览过一遍,感觉很受启发。今天是第2遍读,边读边乐边反思。 两位作者很浪漫,每个章节的开头,都改编了一首歌曲作为前言; 两位作者很幽默,在文章里轻松、犀利地调侃极限编程的缺点; 两位作者也很理性,对极限编程的某些优点也进行了充分的肯定。 第一次读此书时,只注意了作者的理性,没有去读书里的歌词与调侃,第二遍读时,仔
我说CMMI2.0之验证与确认(VV)
验证verification与确认validation是两个不同的概念,在CMMI 1.3版本中是两个不同的PA,在2.0版本中合并成了一个PA,命名为VV。验证与确认的区别,可以通过下表来描述: 验证Verification 确认Validation 目的 确保所选择的工作产品满足指定的需求...
我说CMMI之八:过程的基本概念
我们做过程管理,天天都在讲过程二字,真要给过程下个定义却没有那么容易。正如我们天天说某某是好人,某某是坏人,啥是好人,啥是坏人很难明确定义。但是这却是无法回避的问题,因此我们必须给过程下一个定义。 在CMMI-DEV V1.3模型P449中对过程下了一个定义,全文如下:A set of interrelated activities, which transform inputs into outputs, to achieve a given purpose. (See also “process
需求变更对软件质量的影响
根据我们的经验,需求变更越多,造成的软件修改越多,bug也就会越多,事实是否如此呢?需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数,参见下表,基于这些历史数据我们分析一下,看看我们的经验结论是否成立。表一:需求变更的历史数据 ID 需求变更数 代码规模LOC 总缺陷数 测试缺陷密度bugs/KLOC
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线