51Testing软件测试论坛

标题: 基线审核？？ [打印本页]

作者: web_web_ 时间: 2005-8-10 15:33
标题: 基线审核？？
想向大家请教一下基线审核的问题！
需求基线和概要设计的审核可以是需求之间的审核，
那么概要设计的基线和详细设计的基线之间要审核那个方面的东西呢？产生什么差异？

[ Last edited by web_web_ on 2005-8-12 at 13:47 ]

作者: web_web_ 时间: 2005-8-11 13:27
斑竹帮忙呀!!

作者: swallow0918 时间: 2005-8-11 16:48
这个问题问的好！基线审核要做起来不知道从何下手，我想具体知道楼主的公司是如何来做基线审核的？越具体越好，谢谢。

作者: web_web_ 时间: 2005-8-11 17:07
就是不知道才问的呀!
目前最多的只做了需求方面的审核，后面的就疏忽很多了!
所以问一下大家，高人指点啊!

作者: luoyear 时间: 2005-8-11 21:21
那我就说说我们公司的基线评审怎么做的：
我们定义了8大基线；
系统需求基线-〉计划基线-〉系统方案基线-〉子系统需求基线-〉子系统概要设计基线-〉子系统详细设计基线-〉对内交付基线-〉对外交付基线-〉转产（成果鉴定）

我们大部分是系统项目，有软件/硬件和工艺结构，所以比纯软件项目多了个系统需求基线和系统方案基线。

我们项目立项时候会生成项目的齐套性清单，也就是项目的文档清单。每个基线阶段到来时候，这些文档成果必须完成评审/入库/会签。

同时，我们在项目启动时候都对该项目设置了质量目标，这些质量目标会按照基线阶段进一步分解。

说了这些背景的东西我就来说说基线评审干点什么：
基线评审的核心目标是从管理上进行把关，把脉项目的状态，决定其前进的方向。所以，在HW的IPD中又称为管理决策点。

项目基线评审会对项目从以下一些方面进行总结汇报：
本基线跨度内的质量情况——主要是质量数据及给予数据的分析；
本基线阶段的工作产品配置管理情况——看看工作产品是不是按时输出并纳入配置管理；
本基线阶段的项目实施数据——如进度/工作量/人力资源投入/风险等状态数据的分析及汇报
本基线阶段的项目过程质量数据——SQA出具项目过程质量数据。如审核情况，不合格项关闭情况等？
如果是项目的对外交付基线，也就意味着项目的close，那么还要求对项目进行复盘，通过一系列的数据复现项目实施，并作出分析总结。

QA在开基线评审会前需要对由各个角色分别提供的这些材料做准入审核，然后才容许提交会议申请。

会有产品高层/项目组成员/相关研发部门领导/组织的高层参加这次评审，并最终给出评审结论，决定项目是否继续往下走，或往下走同时附带何种整改措施。

作者: web_web_ 时间: 2005-8-12 14:17
luoyear:
你所说的在我们公司是SQA的职责
SCM在每个基线完成后，打Label，然后进行审核，对照两个基线的配置库，找出不合法的部分，如果是需求基线、概要设计基线之间进行审核的话，不合法部分指的是需求变更但是在提交的需求申请表中并不存在，即需求人员没有经过申请就改变了需求!

[ Last edited by web_web_ on 2005-8-17 at 17:23 ]

作者: luoyear 时间: 2005-8-12 17:49
对了我还忘了补上一点
基线评审还要汇报的一点是工作产品一致性追踪检查结果
我们这里是由项目转么的需求管理员进行检查的。

我觉得SQA能够做的就是核对或抽检这些报告的内容
如此足够了

作者: swallow0918 时间: 2005-8-15 10:55
感谢luoyear版主，说的内容很有用。我正愁这个基线问题呢。谢啦~

作者: Tender 时间: 2005-8-15 12:13
详细！了解！明确！

作者: jasmine_luck 时间: 2005-8-16 10:10
不是很明白啊,那么SCM输出的成果是什么呢在各个基线评审阶段,只是一些数据表格吗?还有中间过程怎么控制?能否以一个项目为例详细说说如何做的?

作者: luoyear 时间: 2005-8-16 12:38
基线评审本来就是项目状态汇报过程中间过程则是日常项目实施活动和日常SQA活动来保证

作者: wzb521 时间: 2005-8-16 17:15
到底怎么理解基线呢？
基线，不是相当于一个版本吗？
你所说的：“系统需求基线-〉计划基线-〉系统方案基线-〉子系统需求基线-〉子系统概要设计基线-〉子系统详细设计基线-〉对内交付基线-〉对外交付基线-〉转产（成果鉴定）”指的是什么？？

基线确定以后，需求更改是要经过申请，不经过申请是不开放权限的，怎么会出现需求不一致的情况呢？

作者: web_web_ 时间: 2005-8-17 15:30
个人理解为基线审核和基线评审是不一样的
评审就是如版主所说，是对质量的保证，但是没有涉及具体的文档内容。
审核则需要核查不同基线状态的输入输出，不知这样理解是否正确？

作者: luoyear 时间: 2005-8-19 18:04
可以这么理解

作者: msfox 时间: 2005-8-24 09:31
上面看luoyear提到hw的IPD思想，我好象看过的IPD思想中的评审是分决策评审和技术评审，并没有管理决策点吧

作者: web_web_ 时间: 2005-8-24 13:14
确定过了，我们公司的审核和评审确实是不一样的
不知道是不是要视各个公司的具体情况而定
不知道有没有公司和我们的是差不多的
审核主要是需求，后来编码部分主要是基线差异和编译申请表中的对照
问题是：编码审核时由于我们是打基线的方法，所以旧版本的维护和新版本的开发中不太兼容，不知有没有遇到这种情况得到了解决的，给个建议

作者: jany_2005 时间: 2005-8-31 12:25
请问楼主，假如你是在一个比较大

作者: tla 时间: 2005-10-17 18:54
呵呵，好啊

作者: web_web_ 时间: 2005-10-25 14:10
楼上的，和谁打招呼呢?

作者: yoyoa 时间: 2005-12-1 14:05
基线审计包括两个方面：一是物理基线的审计，二是功能基线的审计．
物理基线的审计指的是，检查软件工作产品是否按照标准完成了；功能基线的审计指的是，功能基线是否按照预期实现了．
此外，是应该按照项目的大小，来确定基线审计的多少．如果项目的周期较短，完全可以只设需求和发布两条基线；如果项目周期较长，如超过一年，那么可以多设置几条基线来审核．

作者: yoyoa 时间: 2005-12-1 14:31
基线审核和评审是两件事：
基线，可以是立体的，也可以是面的．面指的是一个工作产品，比如详细需求定义书；面指的是一些工作产品产物组成的，比如发布基线由：发布光盘，用户手册，release notes，操作手册等等．它通常是上一个过程的总结同时，也是下一个过程的依据．
基线审核是要在某个阶段，来确定各方面是否满足需求，满足要求；
而评审的范围很宽广，一个关键技术的实现可以评审，一个工作产品也可以评审，一则设计文档也可以进行同行评审．．．．
而且，两件事情的职责也不同．基线审核通常可以由ＳＣＭ负责人员，ＰＭ，ＳＱＡ等等，在项目计划中就确定下来；而评审要看是评审对象了，再来选择评审员，当然也是在项目计划的时候就确定下来了．

作者: gubinger 时间: 2006-1-5 16:16
不错哦,一个公司能做到这些很不错哦,就是国内大部分企业没有管这些哦,唉...想用都用不上哦

作者: bear 时间: 2006-2-20 09:36
了解一下总是好的，以上的讨论收藏了，谢谢各位

作者: 我爱测试 时间: 2006-4-10 21:25
又学了不少，谢谢！

作者: 海的女儿 时间: 2006-4-17 12:29
基线审核重点：1、按照基线计划该基线化的配置项都已经放入配置库中？2、是否有无关的配置项放入？3、放入的配置项版本是否正确？

作者: andrewchou 时间: 2007-8-3 09:55
请问楼上的，怎么确定放入的配置项版本是否正确呢？

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)