1、IDP 项目研发过程项目研发过程项目研发过程第第第 7 章章章第 7 章 IDP 项目研发过程27.1 需求开发与管理 .47.1.1 需求调研 57.1.2 需求分析 67.1.3 需求定义 67.1.4 需求评审确认 .77.1.5 需求细化跟踪 .87.1.6 需求变更控制 .87.2 软件系统设计 .97.2.1 系统结构设计 .107.2.2 用户界面设计 .107.2.3 数据库设计 .117.2.4 系统设计评审 .127.3 模块开发和集成 .127.3.1 模块需求细化 .127.3.2 模块设计 137.3.3 模块实现和集成 147.4 测试与改错 .147.4.1 测试
2、准备 147.4.2 执行测试 167.4.3 消除缺陷 167.5 软硬件系统集成 .177.5.1 系统集成方案设计 .177.5.2 选择设备供应商 17Error! No text of specified style in document. 37.5.3 设备采购和验收 187.5.4 设备安装调试 .187.6 部署试用 .187.6.1 撰写文档 197.6.2 软件部署 197.6.3 客户培训 207.6.4 客户试用 207.7 软件维护 .217.7.1 接受维护请求 .217.7.2 分析维护请求 .227.7.3 执行维护 22第 7 章 IDP 项目研发过程47.
3、1 需求开发与管理需求开发与管理的目的是通过“调研、分析、定义、评审确认、细化跟踪、变更控制”等活动，使开发方和客户对需求有共同、清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等） 。需求开发与管理的流程如图 7-1 所示，该流程的主要工作成果和责任人见表 7-1。一般地，在立项之前，产品经理应当撰写产品需求说明书 ，项目销售人员应当撰写合同项目需求说明书 。但是此时的需求说明书通常是宏观粗略的，不足以让项目开发团队依据此需求说明书开展设计和编程工作。项目开发团队应当在产品经理、销售人员的工作成果基础之上，进一步开展需求调研、分析、定义、评审确认、细化和跟踪活动。项目经理
4、根据本项目的人力资源来确定需求分析员（通常是项目经理或资深开发工程师担任需求分析员） 。图 7-1 需求开发与管理的流程关键活动 主要工作成果 主要责任人需求调研需求分析需求定义需求调研记录产品需求说明书或合同项目需求说明书需求分析员需求评审确认 需求评审报告，签字确认 开发方和客户方的责任人需求细化跟踪 需求跟踪表 需求分析员需求变更控制 需求变更控制报告 开发方和客户方的责任人表 7-1 主要工作成果和责任人需求调研评审确认需求开发需求分析需求定义需求管理细化跟踪变更控制Error! No text of specified style in document. 57.1.1 需求调研需求
5、分析员起草需求问题表，将调查重点锁定在该问题表内，否则调研工作将变得漫无边际。需求分析员确定需求调研的方式，例如： 与用户交谈，向用户提问题。 参观用户的工作流程，观察用户的操作。 向用户群体发调查问卷。 与同行、专家交谈，听取他们的意见。 分析已经存在的同类软件产品，提取需求。 从行业标准、规则中提取需求。 从 Internet 上搜查相关资料。需求分析员与被访谈者建立联系，确定调查的时间、地点、人员等，要特别留意的是不要漏掉典型的用户。需求分析员在调研过程中随时填写“客户需求记录” ，参考格式如表 7-2 所示。提示：集成化研发管理平台 RDMS 的“客户需求记录”功能满足此要求。项目名称
6、需求分析员被调研者调研方式 如面谈，电话交谈等时间、地点需求标题 描述表 7-2 客户需求记录的参考格式需求分析员整理所有客户需求记录，归纳与总结共性的需求，为撰写详细的需求说明书作准备。调研过程中获取的需求信息可以作为需求说明书的附件。第 7 章 IDP 项目研发过程67.1.2 需求分析需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。问答分析最重要的问题是：“是什么”和“为什么” 。每个需求都应当用陈述句说明“是什么” ，如果“是什么”的内涵不够清晰，则应补充说明“不是什么” 。如果“是什么”和“不是什么”并不是“理所当
7、然”的，那么应当解释“为什么” ，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。现代建模工具如 Rose 有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。世上不存在一个包罗万象的图用以完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型
8、存放在需求文档的附录中，便于正文引用。7.1.3 需求定义需求分析员根据需求调查和需求分析的结果，进一步定义准确无误的需求，产生需求说明书 。产品需求说明书的模板参见表 5-2，合同项目需求说明书的模板参见表 5-7。好的需求说明书有如下特征： 正确：需求文档应当正确地反映客户的真实意图。 清楚：清楚的需求让人易读易懂。 无二义性：每个需求只有唯一的含义。 一致：需求文档的上下文之间不会发生矛盾。 必要：需求文档中的各项需求对用户而言应当都是必要的。 完备：需求文档中没有遗漏必要的需求。Error! No text of specified style in document. 7 可实现：需
9、求文档中的各项需求对开发方而言应当都是可实现的。 可验证：需求文档中的各项需求对客户方而言应当都是可验证的。7.1.4 需求评审确认一、需求评审需求分析员邀请项目成员（包括项目经理）和客户代表共同评审需求说明书 ，大家尽最大努力使需求说明书能够正确无误地反映用户的真实意愿。需求评审的流程和技术评审流程相同，如图 7-2 所示。一般地，需求分析员为申请人，项目经理为评审负责人，项目成员和客户代表可以担任评审员。所有评审人员认真检查需求文档，力求使需求文档达到正确、清楚、无二义性、一致、必要、完备、可实现、可验证。图 7-2 需求评审流程二、需求确认需求确认是指当需求说明书通过评审之后，开发方负责
10、人和客户方负责人作书面承诺，使之具有商业合同效果。提示：书面承诺一般放在需求说明书的最后一页。人们作出书面承诺之前务必要认真阅读文档，一定要明白签字意味着什么。 “书面承诺”的示例如下：本需求说明书建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求说明书开展。如果需求 发生变化，我 们将按照“需求 变更控制流程”执行。我明白需求的变更将导致双方重新协商成本、 资源和进度等。开发方负责人签字客户方负责人签字申请申请人 评审人需求评审需求评审会议执行执行负责人第 7 章 IDP 项目研发过程87.1.5 需求细化跟踪在后续开发过程中，人们会对原先的需求文档进行细化。为了提高工作效率
11、，补充需求细节不必按照需求变更来处理。需求分析员将补充的需求内容保存在新的文档中，及时通知相关开发人员，只要大家正确理解了新的需求内容即可。需求分析员要填写需求跟踪表，及时检查后续开发成果是否和需求保持一致。CMMI 建议的“需求跟踪矩阵”要把“需求设计代码测试”的所有关系全部罗列出来，过于复杂和麻烦。根据作者调查，几乎没有人能够长期使用理想化的“需求跟踪矩阵” 。为了提高需求跟踪的效率，应当简化需求跟踪表，如表 7-3 所示。提示：集成化研发管理平台 RDMS 的“项目需求管理”功能满足此要求。项目名称需求目录 需求变更 对应测试用例 相关缺陷 跟踪记录表 7-3 简化的需求跟踪表7.1.6
12、 需求变更控制对大多数项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有： 随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。 市场发生了变化，原先的需求文档可能跟不上当前市场需求，因此要变更需求。提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发团队而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发团队要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。Error! No text of specified style in
13、 document. 9需求变更控制的动机是：（1）如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。（2）如果需求变更带来的坏处大于好处，那么拒绝变更。需求的变更应当遵循“变更控制流程” ，即“变更申请审批执行” ，详见本书第6.3.2 节“变更控制” 。7.2 软件系统设计软件系统设计的主要内容有体系结构设计、用户界面设计、数据库设计和设计评审，在需求与代码之间建立桥梁，指导工作人员开发能够满足用户需求的软件系统。如图 7-3 所示。图 7-3 软件系统设计的示意图项目经理根据本项目的人力资源来确定系统设计师（可以多人） 。系统设计师撰写软件系
14、统设计说明书 ，并构造可运行的软件系统框架，所有的模块都是在该系统框架上开发和运行。 软件系统设计说明书的模板参见表 7-4。软件系统设计说明书1. 系统概述2. 设计约束3. 开发、测试与运行环境4. 软件系统结构图5. 功能模块设计概述5.1 模块汇总5.2 模块之间的关系系统结构设计软件系统设计用户界面设计数据库设计系统设计评审产生软件系统设计说明书和“可运行系统框架”第 7 章 IDP 项目研发过程106. 数据库设计概述6.1 数据库环境说明6.2 数据库命名规则6.3 安全性设计说明6.4 表汇总和表设计（使用表设计工具 PowerDesign）7. 用户界面设计概述8. 综合考虑
15、（可选）8.1 稳定性和可扩展性8.2 性能分析8.3 复用和移植8.4 防错与出错处理8.5 其它表 7-4 软件系统设计说明书7.2.1 系统结构设计系统设计师进行系统结构设计： 确定本系统的约束条件； 确定本系统的开发、测试和运行环境； 将系统分解为模块，确定每个模块的功能，以及模块之间的关系，绘制系统结构图。7.2.2 用户界面设计系统设计师设计和构建用户界面原型，目的是： 加深开发方和客户方对软件需求的理解（界面原型直观地反映了软件需求） ； 在编程之前让相关人员看到用户界面原型，不仅可以提高界面的易用性，还提高了程序员的开发效率（避免反复修改界面及其代码） 。第 1 步 绘制界面示
16、意图系统设计师首先分析用户对界面的需求，例如： 用户的工作习惯Error! No text of specified style in document. 11 用户对界面有什么喜好 有什么强制要求 是否有范例系统设计师构思并绘制用户界面示意图，常用方式如下： 在纸张上绘制用户界面示意图（效率高但是不便于保存） 用 Word 或者 Visio 等工具绘制线框图（效率低但可以作为文档保存）第 2 步 制作界面原型系统设计师制作界面原型（通过编程或者绘图等方式） ，将所有界面原型的图片保存在指定的文件夹中，并用 HTML 建立简要的索引，这样做的好处有： 便于其他人员审阅（使用 IE 浏览） ；
17、需求分析员不必将界面原型图片插入到需求文档中； 修改界面原型图片将不会影响其它文件；第 3 步 体验和改进界面设计师邀请项目成员或者用户来体验界面原型，大家给出改进建议，力求使用户界面满足以下 10 个设计要素： （1）用户界面适合于展现软件的功能（2）适合用户群体（2）容易理解（3）及时反馈信息（4）防错处理（5）合理的布局（6）合理的色彩（7）风格一致和必要的个性化（9）最少操作步骤（最高效率）（10）国际化、可复用等第 7 章 IDP 项目研发过程127.2.3 数据库设计系统设计师进行数据库设计： 确定数据库的环境说明 确定数据库的命名规则 确定安全性设计方法 使用表设计工具 Powe
18、rDesign 设计主要的表结构7.2.4 系统设计评审当系统设计师撰写完成软件系统设计说明书并构建可运行的系统框架之后，邀请项目成员（包括项目经理）和本公司技术专家开展系统设计评审。详见“技术评审”的流程。系统设计评审的目的是，在同行专家的帮助下，尽早地发现本系统中存在的设计缺陷，及时消除设计缺陷。7.3 模块开发和集成增量模式的模块开发和集成流程如图 7-4 所示，主要内容有：“模块需求细化” 、 “模块设计”和“模块实现和集成” 。项目经理分配任务给开发工程师，开发工程师对模块的质量和进度负最大责任。图 7-4 模块开发和集成的流程7.3.1 模块需求细化开发工程师阅读产品需求说明书或合
19、同项目需求说明书 ，分析并细化自己承担的模块需求细化模块需求说明书模块设计模块实现和集成模块设计说明书可运行模块，交付测试增量开发Error! No text of specified style in document. 13模块需求，撰写详细的模块需求说明书 ，模板参见表 7-5。如果发生比较大的需求变更，则按“变更控制流程”执行，向项目经理申请需求变更。模块需求说明书项目名称 撰写人/ 修改人模块名称 完成日期1. 模块用途和功能介绍2. 模块流程介绍（可选）3. 字段说明字段名称 必填项* 说明4. 操作说明操作名称 功能说明 用户角色和权限表 7-5 模块需求说明书的参考模板7.3.
20、2 模块设计模块设计的主要内容： 设计模块的接口； 设计模块的数据结构和算法； 设计和细化本模块相关的用户界面； 设计和细化本模板相关的数据库；对于比较复杂的模块，开发工程师应当撰写必要的模块设计说明书 ，参考模板见表7-6。模块设计说明书项目名称 撰写人/ 修改人模块名称 完成日期1. 主要编程接口2. 主要数据结构第 7 章 IDP 项目研发过程143. 主要算法4. 相关的用户界面设计说明5. 相关的数据库设计说明表 7-6 模块设计说明书的参考模块7.3.3 模块实现和集成所有开发工程师按照既定的编程规范来实现自己承担的模块，并在系统框架中和其它模块集成一起。开发工程师自己必须先进行测
21、试，必须走通模块的功能，消除自己已经发现的缺陷。开发工程师把待测试的软件包发布到约定的测试机器上，把本模块相关的需求说明书、设计说明书交付给测试人员，并向测试人员解释清楚待测试模块的特征。7.4 测试与改错测试与改错的目的是在给定的项目条件下（人员、时间、工具等限制）尽可能地找出软件中的缺陷，并及时消除这些缺陷。测试与改错的流程如图 7-5 所示，关键活动是“准备测试” 、 “执行测试”和“消除缺陷” 。建议使用缺陷跟踪工具和测试管理工具，用于记录测试用例和修改 Bug 的整个过程。提示：集成化研发管理平台 RDMS 的“测试管理”和“缺陷跟踪 ”功能满足此要求。图 7-5 软件测试与改错的流
22、程测试准备消除缺陷执行测试测试人员缺陷跟踪审核关闭开发人员Error! No text of specified style in document. 157.4.1 测试准备测试准备主要有 3 件事情：制定测试计划，设计测试用例，构建测试环境。一、制定测试计划测试工程师和项目经理商议测试计划，撰写测试计划 ，最好用软件工具来管理测试工程师的任务。二、设计测试用例测试用例是用于检验目标软件是否符合要求的一种“示例” ，基本要素有：前提条件、输入数据或动作、期望的响应。 测试用例就是描述各种测试用例的文档，相当于一本“测试操作手册” 。关于测试用例的一些常识如下：（1）设计测试用例的目的是找出需
23、求、设计、代码中的毛病，因此最好尽可能早地设计。（2）测试用例的设计需要动脑筋，不见得比“正向设计”简单。（3）不同的测试用例其用途应当不一样，不要累赘。（4）显而易见的测试用例不必完整地用文字描述，因为此时文字描述的价值不大、反而消耗时间。测试工程师根据模块需求说明书和设计说明书，撰写测试用例 ，格式见表 7-8。开发工程师审阅测试用例 ，提出改进建议，双方达成共识。测试用例项目名称用例名称 撰写人 测试工程师功能描述前提条件输入 / 动作 期望的输出示例：典型值示例：边界值示例：异常值审阅人 开发工程师第 7 章 IDP 项目研发过程16审阅意见表 7-8 测试用例的参考模板三、构建测试环
24、境测试工程师（和开发工程师）构建测试环境，注意测试环境要尽可能接近用户的运行环境。7.4.2 执行测试测试人员按照测试用例执行测试。如果发现 Bug，则记录在 Bug 跟踪工具中，并通知项目经理或开发人员。开发人员及时消除 Bug 后，更改 Bug 跟踪工具中的相关信息。测试人员验证后，关闭该Bug。7.4.3 消除缺陷消除缺陷的第一步是找出缺陷的根源，如同医生治病，必须先找出病因才能“对症下药” 。开发人员必须从结果出发，逆向思考。一旦找到了根源，开发人员通常知道如何消除缺陷。查找缺陷的基本方法是“粗分细找” 。对于隐藏得很深的 Bug，应该运用归纳、推理、“二分”等方法先“快速、粗略”地确
25、定错误根源的范围，然后再用调试工具仔细地跟踪此范围的源代码。开发人员在改错时，要注意以下事项：（1）找到错误的代码时，不要急于修改，先思考一下：修改此代码会不会引发其它问题？如果没有问题，可以放心修改。如果有问题，那么可能要改动程序结构，而不止一行代码。（2）有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起的） 。好不容易逮住一个，应当乘胜追击，全部歼灭。（3）在改错之后一定要马上重新测试，以免引入新的错误。改了一个程序错误固然是喜事，但要防止乐极生悲。更加严格的要求是：不论原先程序是否绝对正确，只要对此程序作过改动（哪怕是微不足道的） ，都要重新测试。Error! No
26、text of specified style in document. 17（4）上述事情做完后，应当好好反思：我为什么会犯这样的错误？怎么能够防止下次不犯相似的错误？最好能写下心得体会，与他人共享经验教训。7.5 软硬件系统集成软硬件系统集成既可能是客户的需求（合同项目） ，也可能是本公司的应用需求。软硬件系统集成的一般流程如图 7-6 所示，关键活动是“系统集成方案设计” 、 “选择设备供应商” 、“设备采购和验收”和“设备安装调试” 。图 7-6 软硬件系统集成的一般流程7.5.1 系统集成方案设计项目开发团队设计系统集成方案，主要工作：（1）根据需求，构思设计系统集成方案。（2）编写
27、系统集成方案 。（3）项目开发团队和客户共同评审系统集成方案 ，通过后进入下一步。7.5.2 选择设备供应商项目经理和采购人员共同“选择设备供应商” ，主要工作：系统集成方案设计选择设备供应商设备采购和验收设备安装调试方案编写方案评审设备询价选择供应商签订合同采购跟踪设备验收合同付款设备安装设备调试软件部署第 7 章 IDP 项目研发过程18（1）对比分析多家候选供应商的设备。（2）从多家候选供应商中选择合适的供应商。（3）和选定的供应商进行合同谈判。（4）和选定的供应商签订设备采购合同。7.5.3 设备采购和验收项目经理和采购人员“采购设备并验收设备” ，主要工作：（1）跟踪设备采购，确保供
28、应商在计划时间内送货。（2）设备验收，确保设备符合质量要求。（3）根据合同支付相应的款项。7.5.4 设备安装调试项目经理安排“设备安装调试、软件部署”的工作计划，主要工作： 项目经理协助供应商将设备安装在客户指定的场地。 供应商负责调试设备，项目经理检查，确保设备正常运行。 在“部署试用”过程域中，项目成员将软件部署到指定的环境中，详见 7.6 节。7.6 部署试用部署试用过程域的关键活动是“撰写文档” 、 “软件部署” 、 “客户培训”和“客户试用” ，流程见图 7-7，主要工作成果见表 7-9。图 7-7 部署试用的流程合同项目验收客户试用产品宣传销售撰写文档软件部署客户培训Error!
29、 No text of specified style in document. 19关键活动 主要工作成果 责任人撰写文档软件部署客户培训软件部署说明书安装和使用手册项目指定人员客户试用 客户试用反馈 项目经理表 7-9 主要工作成果7.6.1 撰写文档当项目开发完成并经过测试之后，项目经理指定项目成员及时撰写安装手册 、 使用手册 、 软件部署说明书等必需文档。7.6.2 软件部署项目经理审阅软件部署说明书 ，模板参见表 7-10，如果发现问题，则及时指正。项目经理确认无误后，再安排开发工程师为客户（或者本公司）部署软件系统： 为客户安装（或更新）软件系统，迁移数据； 为客户初始化业务数据
30、，确保软件能够正常运行；注意：部署的软件系统必须是从配置库中提取已经测试通过的软件包。最好通过 Internet进行远程部署，节省交通费用和时间。软件部署说明书项目（系统）名称 撰写人1. 部署环境说明（硬件和软件系统）2. 需要初始化的数据3. 需要迁移（升级）的数据4. 注意事项项目经理审阅意见部署过程中的第 7 章 IDP 项目研发过程20主要事项记录表 7-10 软件部署说明书7.6.3 客户培训项目经理指定项目成员（即讲师）负责给客户培训。讲师和客户商定培训计划（确定时间、地点、人员批次等） 。讲师按照计划给客户培训，并填写客户培训记录 ，格式参见表 7-11，作为培训服务的依据。客
31、户培训记录讲师课程名称培训时间地点客户名称学员培训内容介绍相关资料客户签字确认表 7-11 客户培训记录7.6.4 客户试用对于自主产品，项目成员把软件部署到本公司指定的机器上，产品经理邀请潜在客户试用本软件。对于合同项目，项目成员把软件部署到客户指定的机器上，客户方人员试用软件。客户方和开发方在签订合同的时候，应当确定“试用协议” 。如果事先没有商定，双方可以根据软件复杂程度协商后补充“试用协议” 。常见的“试用协议”如下：Error! No text of specified style in document. 21当乙方（开发方）为甲方（客户方）部署软件并进行培训后，甲方组织人员进行为
32、期 X 周的软件试用。在试用期间内，如果甲方发现软 件中存在严重的 Bug（如死机、数据丢失、无法运行等），则乙方应当在 24 小时之内给出解决 问题的措施。如果超过试 用期，乙方仍然没有完全消除甲方报告的 Bug，那么试用期顺延，直到乙方完全消除甲方 报告的 Bug 为止。如果甲方在试用期间内没有报告严重 Bug，那么 试用期结束时，视为顺利通过试用。如果试用期间，甲方提出改进 需求、以及 报告了一些不严重的缺陷，乙方作为正常维护工作来处理，不延误甲方验收产 品。客户在试用软件的过程中，将发现的 Bug 以及对软件的建议及时告知开发方。项目经理和开发工程师及时处理客户反馈来的 Bug 和建议
33、。 对于客户发现的 Bug，开发方应当立即纠正。 对于一些难以马上实现的有益建议，由项目经理（或上级领导）决定如何处理。 开发方应当及时把处理结果回复给客户，否则客户可能因得不到开发方的重视而降低试用的积极性。提示：集成化研发管理平台 RDMS 的“客户问题受理” 功能满足此要求。7.7 软件维护软件维护可以划分为两大类： 纠错性维护。由于前期的测试不可能揭露软件系统中所有潜伏的 Bug，用户在使用软件时仍将会遇到 Bug，诊断和改正这些 Bug 的过程称为纠错性维护。 完善性维护。在软件的正常使用过程中，用户还会不断提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。如果需
34、求变更很大，那么完善性维护将转变为软件新版本的开发（即新的项目） 。软件维护的一般流程见图 7-8，主要活动有“接受维护请求” 、 “分析维护请求”和“执行软件维护” 。图 7-8 软件维护的一般流程接受维护请求 执行软件维护分析维护请求客服人员 负责人 维护人员第 7 章 IDP 项目研发过程227.7.1 接受维护请求公司应当建立通畅的软件维护通信渠道，包括网站、电话、Email 等手段。客户通过各种渠道向公司的客服人员提出软件维护请求。本公司客服人员记录这些维护请求。如果公司有专门的维护小组，那么客服人员把维护请求转发给维护小组，由维护小组负责处理。如果公司没有专门的维护小组，那么客服人
35、员把维护请求转发给相关的负责人，例如是该软件的项目经理，如果项目已经结束，则转交给开发部门的领导。7.7.2 分析维护请求负责人接受到维护请求后，进行分析：（1）对于“纠错性维护” ，首先确认 Bug 的真实情况，然后指定维护人员，协商安排修改 Bug 的任务进度。然后告知客户相应的维护计划。（2）对于“完善性维护” ，负责人要综合分析“客户需求建议”的价值，以及本公司的开发资源，然后决定“何人、何时”修改软件。7.7.3 执行维护维护人员根据商定的计划执行维护（修改 Bug 或改进软件） 。注意事项：（1）维护人员修改软件后，必须通过测试，确保没有引入新的错误之后，再去更新那些受影响的客户的软件，例如发行“软件补丁” 。（2）维护人员必须严格遵循“软件配置管理”规范，避免软件代码版本发生混乱。（3）维护人员及时填写“维护记录” ，说明自己做了什么事情和相应的工作量，不仅便于对维护工作进行统计分析，将来在业绩考核时候也用得上。提示：集成化研发管理平台RDMS 的“维护服务记录”功能满足此要求。
