返工返修管理制度5篇(全文).pdf

返工返修管理制度5篇(全文)返工返修管理制度(精

选5篇)

返工返修管理制度第1篇

返工/返修复检记录

XX/JL-151-A/0

No:

产品名称

规格型号

批

次

订单号

复检日期

数

量

复检原因：

以下为检查项目和结果序检验项目要求实测结论1

检验员：

主

管：

一种抵御开发返工的项目管理研究第2篇

1总体设计

为避免开发人员多余开发客户不需要的功能，或遗漏开发

客户最紧迫的功能，基于领域建模的软件需求分析要求需求分

析人员通过六个关键步骤深入理解客户需求。这六个步骤表现

为：第一、全面沟通，速记引导。第二、需求整理，筛选主次。

第三、领域建模，设计类图。第四、测试先行，程序编码。第

五、及时验证，打扰沟通。第六、全面调整，循环迭代。

2详细思路

2.1全面沟通速记引导

因为软件开发方起初对客户的需求一无所知，所以双方应

以正式的形式进行全面沟通。其沟通关键在于速记和引导。首

先，必须快速记录客户提出的需求，避免客户滋生不耐烦情绪。

其次，在客户不能准确表达需求时，要及时引导客户挖掘出真

实需求。

2.2需求整理筛选主次

此时的需求仍处于没有主次的盲目状态，若急于开发UI界

面、数据库，无形中提高软件的返工率，后果表现为“多余开

发”、“遗漏开发”。所以，开发方应进一步整理筛选，其整

理的关键在于根据需求的优先级筛选主次。通常情况下，优先

级可分为高中低三档。必不可少的紧迫功能，其优先级为高。

允许延后的必要功能，其优先级为中。锦上添花的功能，其优

先级为低，如表1所示。

2.3领域建模设计类图

需求分析有三个现实难题，分别是问题领域复杂、用户参

与不够、需求容易变更。为克服这三个难题，开发方应进一步

领域建模，其关键在于设计类图。因为类图有助于通过将复杂

问题分而治之，简化问题。也有助于通过理顺思路，引导客户

参与。还有助于通过定位变化点，处理需求变更。

2.4测试先行程序编码

为准确把握客户需求，应及早测试先行，验证领域模型，

从中发现需求细节，把握技术难点。其关键在于用控制台应用

程序编码。之所以选用控制台应用程序，是因为它不存在图形

界面，不受UI技术的影响，是纯粹关注客户需求的敏捷开发方

式。

这里给出一个体现测试先行价值的案例。如：需求采集时客

户分别提及员工和驾驶员。这在类图中，将被映射成两个独立

的类，分别是“员工”类和“驾驶员”类。在程序编码实现时

代码如下。

此时，根据代码可发现一个细节问题，即“驾驶员是否就

是一种特殊的员工”。若是，可使“驾驶员”类继承“员工”

类，在类结构方面保持高度一致性，便于后期维护。

通过案例可知，许多细节问题都能在测试先行后被发现，

从而在一定程度上提前预防软件返工。

2.5及时验证打扰沟通

对测试先行环节产生的细节问题，若采用传统的定期沟通

方式，必将存在三个弊端：(1)一段时间下来，细节问题多而

杂，易混乱，甚至遗漏。(2)集中特定时间咨询客户，易使其

滋生不耐烦情绪。(3)细节问题不能及时得到解决往往导致开

发滞后。所以，开发方应及时验证，其关键在于打扰式沟通。

这种沟通强调通过各种灵活多变的方式，如QQ、飞信、电

话等，在发现问题后第一时间联系客户，解决问题。如上述

“驾驶员是否就是一种特殊的员工”这样的细节问题，只需一

条短信即刻解决。

2.6全面调整循环迭代

虽然局部修改相对独立，但任何一次修改都会影响至全局，

所以必须进行全面调整，才能保持开发的一致性。而全面调整

的关键在于循环迭代，旨在根据打扰式沟通的反馈结果重新整

理需求、领域建模、测试先行、及时验证。开发方只有经历多

次循环，才能从看清需求过渡到看透需求，提高开发成功率。

3基于测试先行的合理应用设计模式

以上六步，以测试先行最为重要，主张直接编码实现用户

基本功能。之后便以“用简单代码实现复杂功能”为依据调整

代码结构，最终达到在潜移默化中合理使用设计模式的目标。

例如，第一次编码实现特定功能用了10