扫码阅读
手机扫码阅读
纳入基线管理的经验原则
64 2024-10-03
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:纳入基线管理的经验原则
文章来源:
麦哲思科技任甲林
扫码关注公众号
基线管理原则摘要
原则1:所有交付客户的成果,包括文档、代码、可执行程序以及购买的可复用构件都应该被纳入基线管理。
原则2:任何影响对外承诺的配置项,例如项目的阶段计划,都必须被纳入基线,以便进行有效管理。
原则3:所有对交付产品有显著影响的文档和资料,特别是关键的工程文档如需求和设计文档,都应该加入到基线中。此外,区分主动变化和被动变化,特别是主动变化必须被包含在基线之内。
原则4:仅有变化的文档才需要纳入配置管理,而不变的文档通常不加入基线。
这些基线管理原则的优先级是递减的,并且由项目组的配置管理员和项目经理共同负责确保这些原则得到实施。
想要了解更多内容?
查看原文:纳入基线管理的经验原则
文章来源:
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
420 篇文章
浏览 79.8K
麦哲思科技任甲林的其他文章
《CMMI4级实践问题30问》后记
在写此三十问的过程中,陆续有朋友和我讨论关于4-5级的理解与实施问题,通过这些争论也让我对实践中的问题有更清晰地认识。(1)有朋友指出有些描述有不准确的地方,确实如此,有些观点在业内本身就存在争论,有些观点属于我自己的思考,在写博文时我尽量是力求完备而严谨,虽然反复锤炼,但是肯定能力有限,有颇多争议之处,只是希望对大家有所启发,难以完美。(2)也有朋友讲,有些问题写得有点抽象,仅凭这些内容
CMMI 3级的难点
(1) 需求、设计、代码、测试用例的质量比较差Ø 需求描述不全面、不详细;Ø 设计中错误比较多,遗漏比较多;Ø 设计与实现脱节,实现人员不看设计文档;Ø 代码中隐藏的缺陷比较多,代码的可维护性比较差,其他开发人员难以读懂代码;Ø 测试用例数量太少,对需求、设计的覆盖率比较低(2) 同行评审无法快速发现问题Ø 缺
软件开发经济实用的15条实践
无论是否参考CMMI的模型,在软件开发的过程,我认为如下的15条实践比较经济实用: (1)控制项目组的团队规模不超过10人,人员要少而精。 (2)需求文档化,无论大小项目必须清晰的描述需求。 (3)采用用例、界面原型描述需求,采用这2种手段强制使需求描述的完备而清晰。 (4) 项目的阶段计划与2周计划,阶段计划定义总体承诺,2周计划定义近2周的详细任务安排。 (5)逐日跟踪+周例会,每
做事模式的思考:想、说、写、做
模式一:边做边想没有事先的计划,没有思虑周全,在做的过程中再去寻找好的方法,造成的后果就是质量差或返工多,浪费了时间。很多初级的开发人员在编码时就采用了这种工作模式。磨刀不误砍柴工,先想清楚,再动手做,看似慢,实际快!模式二:想->做 想清楚了总比不想好。此种模式没有和别人沟通,没有文档化,这种模式很可能想的不周全,导致在做的过程中存在问题。三思而后行,如何保证三思的质量呢?沟通与文档化。模式三:想->写->做 想了以后文档化,文档化可以促进自我反思,但是没有其他人进行评审,然后去实现,没有其
如何对质量数据进行分析?
在对质量数据分析时,应该对哪些活动,采集哪些度量数据,采用什么方法进行分析呢?请参考本文给出的系统归纳。
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线