设计复审问题

nixiaohui

项目采用瀑布模型，现已进行到系统测试阶段，检查发现设计复审没有完成。这种情况下是否可以补做设计复审，从质量保证角度来看是否有意义呢？

按照瀑布模型，设计复审应该在编码之前进行，这时再补做设计复审已过时机。但从质量保证角度来看，现在补做设计复审，如果发现问题还可以在系统设计阶段按照bug的方式进行修正。

以上观点，请大家斧正。sdlkfj2

小白帆

这个需要具体问题具体分析啊sdlkfj2

1. 首先，为什么当时没有做设计复审？项目经理认为时间紧，跳过了；系统架构是在以前项目基础上；系统架构相对简单。。。
2.是什么阶段的设计复审，HLD？DLD？
3.你们除了系统测试，还有单元测试和集成测试环节么？

如果这是一个全新的项目，在很大的时间压力下，没有做设计复审，同时只有系统测试环节，我个人认为一定有必要补做的，因为往往系统测试只是从功能角度，用户需求角度用穷举法进行测试，对于设计存在的一些问题，如接口，性能，还有exception情况不一定能完全覆盖。同时做设计复审如果发现问题，及时修改，还可以大大节约系统测试的时间

但是，如果前面的假设不成立或者部分成立，那你需要基于项目的情况进行分析，是不是补做，采取什么形式补做

nixiaohui

这个需要具体问题具体分析啊sdlkfj2

1. 首先，为什么当时没有做设计复审？项目经理认为时间紧，跳过了；系统架构是在以前项目基础上；系统架构相对简单。。。
--项目经理认为时间紧
2.是什么阶段的设计复审，HLD？DLD？
--规定在详细设计结束后进行设计复审。
3.你们除了系统测试，还有单元测试和集成测试环节么？
--单元测试和集成测试是开发组自己完成，系统测试需要移交到测试组在测试环境下进行。现在项目已经移交到测试组进行系统测试。



如果这是一个全新的项目，在很大的时间压力下，没有做设计复审，同时只有系统测试环节，我个人认为一定有必要补做的，因为往往系统测试只是从功能角度，用户需求角度用穷举法进行测试，对于设计存在的一些问题，如接口，性能，还有exception情况不一定能完全覆盖。同时做设计复审如果发现问题，及时修改，还可以大大节约系统测试的时间

但是，如果前面的假设不成立或者部分成立，那你需要基于项目的情况进行分析，是不是补做，采取什么形式补做

谢谢小白帆，那么哪些情形下设计复审不需要补做了呢？

Iolia

分析的不错，顶了

小白帆

原帖由 nixiaohui 于 2007-6-21 12:48 发表
这个需要具体问题具体分析啊sdlkfj2

1. 首先，为什么当时没有做设计复审？项目经理认为时间紧，跳过了；系统架构是在以前项目基础上；系统架构相对简单。。。
--项目经理认为时间紧
2.是什么阶段的设计复 ...

我个人认为你项目这种情况，最好补做设计复审，但是形式需要仔细考虑下
最好拿开发的单元测试报告和集成测试报告分析一下，可以考虑和项目经理或者开发的team leader一起
然后确定是否要复审和复审的形式

同时如果现在系统测试阶段已经发现了一些问题，也可以作为参考依据
个人意见，希望对你有帮助sdlkfj2

china_breezy

顶！

yiding_he

为什么设计复审被项目经理抵制？项目经理应该是对项目风险了解最深的，而他却抵制复审这道工序，这样的复审本身是否存在问题？

luoyear

在这种情况下，可以考虑结合实际情况作一些针对性的补救措施，可能的情况与对策有：
1，没有做评审，但是一次性就把事情做对了。很好啊，豁免。
2，没有做设计评审，系统测试策略有必要就此问题做一些针对性的补救。可能需要衡量一下集成测试，单元测试的质量表现，看看是否存在质量数据异常波动。决定对质量重灾区采取某类补救措施：如对该功能模块执行更严格的覆盖率要求，回溯作质量评审。

nixiaohui

目前项目执行过程中,对复审是存在抵触情绪.
这有两方面原因:
一是,项目组认为外部复审并没有给项目有效地检查出问题、识别出风险，组内成员间的讨论更加有效。所以不愿意按照规范组织外部复审。
二是，由于公司的组织架构方面的原因，设计复审中的复审人员属于不同部门，有时还在不同的地域，组织一次会议是比较困难的。很多项目组采用邮件形式来进行复审活动，但邮件又容易被复审人员忽视，影响复审质量。这也是项目组不愿意进行外部复审的原因。

每到项目组复审时，都要好说歹说，就像求他们一样。但是现实是公司的组织架构不会轻易改变的，在这种情形下如何变通复审流程使复审能达到应有效果。或者说，要改进复审流程的话，该从哪里入手？

nixiaohui

原帖由 luoyear 于 2007-6-25 21:21 发表
在这种情况下，可以考虑结合实际情况作一些针对性的补救措施，可能的情况与对策有：
1，没有做评审，但是一次性就把事情做对了。很好啊，豁免。
2，没有做设计评审，系统测试策略有必要就此问题做一些针对性的 ...

“一次性就把事情做对了”--这个如何评判？
“可能需要衡量一下集成测试，单元测试的质量表现，看看是否存在质量数据异常波动。”--这需要组织的历史数据做支持吧，如果没有历史数据，可以从哪些方面评判是否存在质量数据异常波动呢？

jlminghui

学习 ：）

小白帆

原帖由 nixiaohui 于 2007-6-26 23:38 发表
目前项目执行过程中,对复审是存在抵触情绪.
这有两方面原因:
一是,项目组认为外部复审并没有给项目有效地检查出问题、识别出风险，组内成员间的讨论更加有效。所以不愿意按照规范组织外部复审。
二是，由于公 ...

软件质量活动如果没有效果，往往会流于形式也会受到项目组的抵触，这是很正常的

对于复审一点建议，可以参考：
1. 项目组可以组织内部评审，但是要注意内部评审一样需要有效的组织，要有评审记录，要对评审记录进行跟踪。如果只是组内成员的讨论，但没有任何记录和评审意见的跟踪，往往陷入讨论无果，或者意见无法一致的情况

2.对于外部评审，要谨慎选择参加评审的人员，不要有点关系，或者关系不大也参加，这样评审人员太多，反而没有效果。同时，也是要注意评审记录，即使是邮件评审，也要有完整的记录，需要给作者和评审员相应的结果，这样的评审才有意义

同时，最好在项目的开始阶段就和项目经理进行讨论，定义需要评审的东东和评审的形式。注意是讨论，不要把QA的意志强加给项目经理，要把评审的意义和效果很好的和项目经理进行沟通。毕竟，是项目经理对整个项目的产出和产品负责，以我个人经验，大部分项目经理还是会积极听取QA的建议的，因为这是对项目有利的。

如果QA只是一味的强求遵守流程，而不考虑对于项目的实际效果，或者在执行过程中过于本本主义，就容易引起项目经理和项目组成员的抵触情绪。即使勉强进行了评审，效果也不好。

总之一句话，质量保证工作是为了保证项目在有限的时间内提供质量更好的产出，而不是质量最好的。所以，QA需要从项目角度出发，考虑如何以更好的形式让项目组成员更快的接受质量活动，这样才对项目有意义

andrewchou

评审方面项目经理应该不会拒绝的。
要通过制度来督促项目经理组织相关人员进行项目评审工作