第7章IDP项目研发过程.docx

第7章IDP项目研发过程.docx

《第7章IDP项目研发过程.docx》由会员分享，可在线阅读，更多相关《第7章IDP项目研发过程.docx（22页珍藏版）》请在冰豆网上搜索。

第7章IDP项目研发过程

第7章

7.1需求开发与管理

需求开发与管理的目的是通过“调研、分析、定义、评审确认、细化跟踪、变更控制”等活动，使开发方和客户对需求有共同、清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等）。

需求开发与管理的流程如图7-1所示，该流程的主要工作成果和责任人见表7-1。

一般地，在立项之前，产品经理应当撰写《产品需求说明书》，项目销售人员应当撰写《合同项目需求说明书》。

但是此时的需求说明书通常是宏观粗略的，不足以让项目开发团队依据此需求说明书开展设计和编程工作。

需求

调研

评审

确认

需求开发

需求

分析

需求

定义

需求管理

细化跟踪

变更控制

项目开发团队应当在产品经理、销售人员的工作成果基础之上，进一步开展需求调研、分析、定义、评审确认、细化和跟踪活动。

项目经理根据本项目的人力资源来确定需求分析员（通常是项目经理或资深开发工程师担任需求分析员）。

图7-1需求开发与管理的流程

关键活动

主要工作成果

主要责任人

需求调研

需求分析

需求定义

《需求调研记录》

《产品需求说明书》或

《合同项目需求说明书》

需求分析员

需求评审确认

需求评审报告，签字确认

开发方和客户方的责任人

需求细化跟踪

需求跟踪表

需求分析员

需求变更控制

需求变更控制报告

开发方和客户方的责任人

表7-1主要工作成果和责任人

7.1.1需求调研

需求分析员起草需求问题表，将调查重点锁定在该问题表内，否则调研工作将变得漫无边际。

需求分析员确定需求调研的方式，例如：

✧与用户交谈，向用户提问题。

✧参观用户的工作流程，观察用户的操作。

✧向用户群体发调查问卷。

✧与同行、专家交谈，听取他们的意见。

✧分析已经存在的同类软件产品，提取需求。

✧从行业标准、规则中提取需求。

✧从Internet上搜查相关资料。

需求分析员与被访谈者建立联系，确定调查的时间、地点、人员等，要特别留意的是不要漏掉典型的用户。

需求分析员在调研过程中随时填写“客户需求记录”，参考格式如表7-2所示。

提示：

集成化研发管理平台RDMS的“客户需求记录”功能满足此要求。

项目名称

需求分析员

被调研者

调研方式

如面谈，电话交谈等

时间、地点

需求标题

描述

表7-2客户需求记录的参考格式

需求分析员整理所有客户需求记录，归纳与总结共性的需求，为撰写详细的《需求说明书》作准备。

调研过程中获取的需求信息可以作为《需求说明书》的附件。

7.1.2需求分析

需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。

常见的需求分析方法有“问答分析法”和“建模分析法”两类。

问答分析最重要的问题是：

“是什么”和“为什么”。

每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。

如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。

追究“是什么”和“为什么”的目的是获得正确、清楚的需求。

对于某些类型的信息，用图形表示要比文本表示更加有效。

所以将图形与文本结合起来描述需求是很自然的方法。

需求建模就是指用图形符号来表示、刻画需求。

现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。

要注意的是：

在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。

世上不存在一个包罗万象的图用以完整地描述需求。

需求建模不可能取代文字描述。

在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。

建议将模型存放在需求文档的附录中，便于正文引用。

7.1.3需求定义

需求分析员根据需求调查和需求分析的结果，进一步定义准确无误的需求，产生《需求说明书》。

产品需求说明书的模板参见表5-2，合同项目需求说明书的模板参见表5-7。

好的需求说明书有如下特征：

Ø正确：

需求文档应当正确地反映客户的真实意图。

Ø清楚：

清楚的需求让人易读易懂。

Ø无二义性：

每个需求只有唯一的含义。

Ø一致：

需求文档的上下文之间不会发生矛盾。

Ø必要：

需求文档中的各项需求对用户而言应当都是必要的。

Ø完备：

需求文档中没有遗漏必要的需求。

Ø可实现：

需求文档中的各项需求对开发方而言应当都是可实现的。

Ø可验证：

需求文档中的各项需求对客户方而言应当都是可验证的。

7.1.4需求评审确认

一、需求评审

需求分析员邀请项目成员（包括项目经理）和客户代表共同评审《需求说明书》，大家尽最大努力使《需求说明书》能够正确无误地反映用户的真实意愿。

申请

申请人

评审人

需求评审

需求评审会议

执行

执行负责人

需求评审的流程和技术评审流程相同，如图7-2所示。

一般地，需求分析员为申请人，项目经理为评审负责人，项目成员和客户代表可以担任评审员。

所有评审人员认真检查需求文档，力求使需求文档达到正确、清楚、无二义性、一致、必要、完备、可实现、可验证。

图7-2需求评审流程

二、需求确认

需求确认是指当《需求说明书》通过评审之后，开发方负责人和客户方负责人作书面承诺，使之具有商业合同效果。

提示：

书面承诺一般放在《需求说明书》的最后一页。

人们作出书面承诺之前务必要认真阅读文档，一定要明白签字意味着什么。

“书面承诺”的示例如下：

本《需求说明书》建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该《需求说明书》开展。

如果需求发生变化，我们将按照“需求变更控制流程”执行。

我明白需求的变更将导致双方重新协商成本、资源和进度等。

开发方负责人签字

客户方负责人签字

7.1.5需求细化跟踪

在后续开发过程中，人们会对原先的需求文档进行细化。

为了提高工作效率，补充需求细节不必按照需求变更来处理。

需求分析员将补充的需求内容保存在新的文档中，及时通知相关开发人员，只要大家正确理解了新的需求内容即可。

需求分析员要填写需求跟踪表，及时检查后续开发成果是否和需求保持一致。

CMMI建议的“需求跟踪矩阵”要把“需求－设计－代码－测试”的所有关系全部罗列出来，过于复杂和麻烦。

根据作者调查，几乎没有人能够长期使用理想化的“需求跟踪矩阵”。

为了提高需求跟踪的效率，应当简化需求跟踪表，如表7-3所示。

提示：

集成化研发管理平台RDMS的“项目需求管理”功能满足此要求。

项目名称

需求目录

需求变更

对应测试用例

相关缺陷

跟踪记录

表7-3简化的需求跟踪表

7.1.6需求变更控制

对大多数项目而言，需求发生若干次变更似乎是不可避免的。

需求发生变更的起因主要有：

Ø随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。

原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。

Ø市场发生了变化，原先的需求文档可能跟不上当前市场需求，因此要变更需求。

提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。

对项目开发团队而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发团队要为此付出较重的代价。

如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。

需求变更控制的动机是：

（1）如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。

（2）如果需求变更带来的坏处大于好处，那么拒绝变更。

需求的变更应当遵循“变更控制流程”，即“变更申请－>审批－>执行”，详见本书第6.3.2节“变更控制”。

7.2软件系统设计

系统结构设计

软件系统设计

用户界面设计

数据库

设计

系统设计评审

产生《软件系统设计说明书》和“可运行系统框架”

软件系统设计的主要内容有体系结构设计、用户界面设计、数据库设计和设计评审，在需求与代码之间建立桥梁，指导工作人员开发能够满足用户需求的软件系统。

如图7-3所示。

图7-3软件系统设计的示意图

项目经理根据本项目的人力资源来确定系统设计师（可以多人）。

系统设计师撰写《软件系统设计说明书》，并构造可运行的软件系统框架，所有的模块都是在该系统框架上开发和运行。

《软件系统设计说明书》的模板参见表7-4。

软件系统设计说明书

1.系统概述

2.设计约束

3.开发、测试与运行环境

4.软件系统结构图

5.功能模块设计概述

5.1模块汇总

5.2模块之间的关系

6.数据库设计概述

6.1数据库环境说明

6.2数据库命名规则

6.3安全性设计说明

6.4表汇总和表设计（使用表设计工具PowerDesign）

7.用户界面设计概述

8.综合考虑（可选）

8.1稳定性和可扩展性

8.2性能分析

8.3复用和移植

8.4防错与出错处理

8.5其它

表7-4软件系统设计说明书

7.2.1系统结构设计

系统设计师进行系统结构设计：

Ø确定本系统的约束条件；

Ø确定本系统的开发、测试和运行环境；

Ø将系统分解为模块，确定每个模块的功能，以及模块之间的关系，绘制系统结构图。

7.2.2用户界面设计

系统设计师设计和构建用户界面原型，目的是：

Ø加深开发方和客户方对软件需求的理解（界面原型直观地反映了软件需求）；

Ø在编程之前让相关人员看到用户界面原型，不仅可以提高界面的易用性，还提高了程序员的开发效率（避免反复修改界面及其代码）。

第1步绘制界面示意图

系统设计师首先分析用户对界面的需求，例如：

Ø用户的工作习惯

Ø用户对界面有什么喜好

Ø有什么强制要求

Ø是否有范例

系统设计师构思并绘制用户界面示意图，常用方式如下：

Ø在纸张上绘制用户界面示意图（效率高但是不便于保存）

Ø用Word或者Visio等工具绘制线框图（效率低但可以作为文档保存）

第2步制作界面原型

系统设计师制作界面原型（通过编程或者绘图等方式），将所有界面原型的图片保存在指定的文件夹中，并用HTML建立简要的索引，这样做的好处有：

Ø便于其他人员审阅（使用IE浏览）；

Ø需求分析员不必将界面原型图片插入到需求文档中；

Ø修改界面原型图片将不会影响其它文件；

第3步体验和改进

界面设计师邀请项目成员或者用户来体验界面原型，大家给出改进建议，力求使用户界面满足以下10个设计要素：

（1）用户界面适合于展现软件的功能

（2）适合用户群体

（2）容易理解

（3）及时反馈信息

（4）防错处理

（5）合理的布局

（6）合理的色彩

（7）风格一致和必要的个性化

（9）最少操作步骤（最高效率）

（10）国际化、可复用等

7.2.3数据库设计

系统设计师进行数据库设计：

Ø确定数据库的环境说明

Ø确定数据库的命名规则

Ø确定安全性设计方法

Ø使用表设计工具PowerDesign设计主要的表结构

7.2.4系统设计评审

当系统设计师撰写完成《软件系统设计说明书》并构建可运行的系统框架之后，邀请项目成员（包括项目经理）和本公司技术专家开展系统设计评审。

详见“技术评审”的流程。

系统设计评审的目的是，在同行专家的帮助下，尽早地发现本系统中存在的设计缺陷，及时消除设计缺陷。

7.3模块开发和集成

增量模式的模块开发和集成流程如图7-4所示，主要内容有：

“模块需求细化”、“模块设计”和“模块实现和集成”。

模块需求细化

《模块需求说明书》

模块设计

模块实现和集成

《模块设计说明书》

可运行模块，交付测试

增量开发

项目经理分配任务给开发工程师，开发工程师对模块的质量和进度负最大责任。

图7-4模块开发和集成的流程

7.3.1模块需求细化

开发工程师阅读《产品需求说明书》或《合同项目需求说明书》，分析并细化自己承担的模块需求，撰写详细的《模块需求说明书》，模板参见表7-5。

如果发生比较大的需求变更，则按“变更控制流程”执行，向项目经理申请需求变更。

模块需求说明书

项目名称

撰写人/修改人

模块名称

完成日期

1.模块用途和功能介绍

2.模块流程介绍（可选）

3.字段说明

字段名称

必填项*

说明

4.操作说明

操作名称

功能说明

用户角色和权限

……

表7-5模块需求说明书的参考模板

7.3.2模块设计

模块设计的主要内容：

Ø设计模块的接口；

Ø设计模块的数据结构和算法；

Ø设计和细化本模块相关的用户界面；

Ø设计和细化本模板相关的数据库；

对于比较复杂的模块，开发工程师应当撰写必要的《模块设计说明书》，参考模板见表7-6。

模块设计说明书

项目名称

撰写人/修改人

模块名称

完成日期

1.主要编程接口

2.主要数据结构

3.主要算法

4.相关的用户界面设计说明

5.相关的数据库设计说明

……

表7-6模块设计说明书的参考模块

7.3.3模块实现和集成

所有开发工程师按照既定的编程规范来实现自己承担的模块，并在系统框架中和其它模块集成一起。

开发工程师自己必须先进行测试，必须走通模块的功能，消除自己已经发现的缺陷。

开发工程师把待测试的软件包发布到约定的测试机器上，把本模块相关的需求说明书、设计说明书交付给测试人员，并向测试人员解释清楚待测试模块的特征。

7.4测试与改错

测试与改错的目的是在给定的项目条件下（人员、时间、工具等限制）尽可能地找出软件中的缺陷，并及时消除这些缺陷。

测试与改错的流程如图7-5所示，关键活动是“准备测试”、“执行测试”和“消除缺陷”。

建议使用缺陷跟踪工具和测试管理工具，用于记录测试用例和修改Bug的整个过程。

提示：

集成化研发管理平台RDMS的“测试管理”和“缺陷跟踪”功能满足此要求。

图7-5软件测试与改错的流程

7.4.1测试准备

测试准备主要有3件事情：

制定测试计划，设计测试用例，构建测试环境。

一、制定测试计划

测试工程师和项目经理商议测试计划，撰写《测试计划》，最好用软件工具来管理测试工程师的任务。

二、设计测试用例

测试用例是用于检验目标软件是否符合要求的一种“示例”，基本要素有：

前提条件、输入数据或动作、期望的响应。

《测试用例》就是描述各种测试用例的文档，相当于一本“测试操作手册”。

关于测试用例的一些常识如下：

（1）设计测试用例的目的是找出需求、设计、代码中的毛病，因此最好尽可能早地设计。

（2）测试用例的设计需要动脑筋，不见得比“正向设计”简单。

（3）不同的测试用例其用途应当不一样，不要累赘。

（4）显而易见的测试用例不必完整地用文字描述，因为此时文字描述的价值不大、反而消耗时间。

测试工程师根据模块需求说明书和设计说明书，撰写《测试用例》，格式见表7-8。

开发工程师审阅《测试用例》，提出改进建议，双方达成共识。

测试用例

项目名称

用例名称

撰写人

测试工程师

功能描述

前提条件

输入/动作

期望的输出

示例：

典型值…

示例：

边界值…

示例：

异常值…

审阅人

开发工程师

审阅意见

表7-8测试用例的参考模板

三、构建测试环境

测试工程师（和开发工程师）构建测试环境，注意测试环境要尽可能接近用户的运行环境。

7.4.2执行测试

测试人员按照《测试用例》执行测试。

如果发现Bug，则记录在Bug跟踪工具中，并通知项目经理或开发人员。

开发人员及时消除Bug后，更改Bug跟踪工具中的相关信息。

测试人员验证后，关闭该Bug。

7.4.3消除缺陷

消除缺陷的第一步是找出缺陷的根源，如同医生治病，必须先找出病因才能“对症下药”。

开发人员必须从结果出发，逆向思考。

一旦找到了根源，开发人员通常知道如何消除缺陷。

查找缺陷的基本方法是“粗分细找”。

对于隐藏得很深的Bug，应该运用归纳、推理、“二分”等方法先“快速、粗略”地确定错误根源的范围，然后再用调试工具仔细地跟踪此范围的源代码。

开发人员在改错时，要注意以下事项：

（1）找到错误的代码时，不要急于修改，先思考一下：

修改此代码会不会引发其它问题？

如果没有问题，可以放心修改。

如果有问题，那么可能要改动程序结构，而不止一行代码。

（2）有些时候，软件中可能潜伏同一类型的许多错误（例如由不良的编程习惯引起的）。

好不容易逮住一个，应当乘胜追击，全部歼灭。

（3）在改错之后一定要马上重新测试，以免引入新的错误。

改了一个程序错误固然是喜事，但要防止乐极生悲。

更加严格的要求是：

不论原先程序是否绝对正确，只要对此程序作过改动（哪怕是微不足道的），都要重新测试。

（4）上述事情做完后，应当好好反思：

我为什么会犯这样的错误？

怎么能够防止下次不犯相似的错误？

最好能写下心得体会，与他人共享经验教训。

7.5软硬件系统集成

软硬件系统集成既可能是客户的需求（合同项目），也可能是本公司的应用需求。

软硬件系统集成的一般流程如图7-6所示，关键活动是“系统集成方案设计”、“选择设备供应商”、“设备采购和验收”和“设备安装调试”。

图7-6软硬件系统集成的一般流程

7.5.1系统集成方案设计

项目开发团队设计系统集成方案，主要工作：

（1）根据需求，构思设计系统集成方案。

（2）编写《系统集成方案》。

（3）项目开发团队和客户共同评审《系统集成方案》，通过后进入下一步。

7.5.2选择设备供应商

项目经理和采购人员共同“选择设备供应商”，主要工作：

（1）对比分析多家候选供应商的设备。

（2）从多家候选供应商中选择合适的供应商。

（3）和选定的供应商进行合同谈判。

（4）和选定的供应商签订设备采购合同。

7.5.3设备采购和验收

项目经理和采购人员“采购设备并验收设备”，主要工作：

（1）跟踪设备采购，确保供应商在计划时间内送货。

（2）设备验收，确保设备符合质量要求。

（3）根据合同支付相应的款项。

7.5.4设备安装调试

项目经理安排“设备安装调试、软件部署”的工作计划，主要工作：

Ø项目经理协助供应商将设备安装在客户指定的场地。

Ø供应商负责调试设备，项目经理检查，确保设备正常运行。

Ø在“部署试用”过程域中，项目成员将软件部署到指定的环境中，详见7.6节。

7.6部署试用

部署试用过程域的关键活动是“撰写文档”、“软件部署”、“客户培训”和“客户试用”，流程见图7-7，主要工作成果见表7-9。

图7-7部署试用的流程

关键活动

主要工作成果

责任人

撰写文档

软件部署

客户培训

软件部署说明书

安装和使用手册

项目指定人员

客户试用

客户试用反馈

项目经理

表7-9主要工作成果

7.6.1撰写文档

当项目开发完成并经过测试之后，项目经理指定项目成员及时撰写《安装手册》、《使用手册》、《软件部署说明书》等必需文档。

7.6.2软件部署

项目经理审阅《软件部署说明书》，模板参见表7-10，如果发现问题，则及时指正。

项目经理确认无误后，再安排开发工程师为客户（或者本公司）部署软件系统：

✧为客户安装（或更新）软件系统，迁移数据；

✧为客户初始化业务数据，确保软件能够正常运行；

注意：

部署的软件系统必须是从配置库中提取已经测试通过的软件包。

最好通过Internet进行远程部署，节省交通费用和时间。

软件部署说明书

项目（系统）名称

撰写人

1.部署环境说明（硬件和软件系统）

2.需要初始化的数据

3.需要迁移（升级）的数据

4.注意事项

项目经理审阅意见

部署过程中的

主要事项记录

表7-10软件部署说明书

7.6.3客户培训

项目经理指定项目成员（即讲师）负责给客户培训。

讲师和客户商定培训计划（确定时间、地点、人员批次等）。

讲师按照计划给客户培训，并填写《客户培训记录》，格式参见表7-11，作为培训服务的依据。

客户培训记录

讲师

课程名称

培训时间

地点

客户名称

学员

培训内容介绍

相关资料

客户签字确认

表7-11客户培训记录

7.6.4客户试用

对于自主产品，项目成员把软件部署到本公司指定的机器上，产品经理邀请潜在客户试用本软件。

对于合同项目，项目成员把软件部署到客户指定的机器上，客户方人员试用软件。

客户方和开发方在签订合同的时候，应当确定“试用协议”。

如果事先没有商定，双方可以根据软件复杂程度协商后补充“试用协议”。

常见的“试用协议”如下：

当乙方（开发方）为甲方（客户方）部署软件并进行培训后，甲方组织人员进行为期X周的软件试用。

在试用期间内，如果甲方发现软件中存在严重的Bug（如死机、数据丢失、无法运行等），则乙方应当在24小时之内给出解决问题的措施。

如果超过试用期，乙方仍然没有完全消除甲方报告的Bug，那么试用期顺延，直到乙方完全消除甲方报告的Bug为止。

如果甲方在试用期间内没有报告严重Bug，那么试用期结束时，视为顺利通过试用。

如果试用期间，甲方提出改进需求、以及报告了一些不严重的缺陷，乙方作为正常维护工作来处理，不延误甲方验收产品。

客户在试用软件的过程中，将发现的Bug以及对软件的建议及时告知开发方。

项目经理和开发工程师及时处理客户反馈来的Bug和建议。

✧对于客户发现的Bug，开发方应当立即纠正。

✧对于一些难以马上实现的有益建议，由项目经理（或上级领导）决定如何处理。

✧开发方应当及时把处理结果回复给客户，否则客户可能因得不到开发方的重视而降低试用的积极性。

提示：

集成化研发管理平台RDMS的“客户问题受理”功能满足此要求。

7.7软件维护

软件维护可以划分为两大类：

Ø纠错性维护。

由于前期的测试不可能揭露软件系统中所有潜伏的Bug，用户在使用软件时仍将会遇到Bug，诊断和改正这些Bug的过程称为纠错性维护。

Ø完善性维护。

在软件的正常使用过程中，用户还会不断提出新的需求。

为了满足用户新的需求而增加软件功能的活动称为完善性维护。

如果需求变更很大，那么完善性维护将转变为软件新版本的开发（即新的项目）。

接受维护请求

执行软件维护

分析维护请求

客服人员

负责人

维护人员

软件维护的一般流程见图7-8，主要活动有“接受维护请求”、“分析维护请求”和“执行软件维护”。

图7-8软件维护的一般流程

7.7.1接受维护请求

公司应当建立通畅的软件维护通信渠道，包括网站、电话、Email等手段。

客户通过各种渠道向公司的客服人员提出软件维护请求。

本公司客服人员记录这些维护请求。

如果公司有专门的维护小组，那么客服人员把维护请求转发给维护小组，由维护小组负责处理。

如果公司没有专门的维护小组，那么客服人员把维护请求转发给相关的负责人，例如是该软件的项目经理，如果项目已经结束，则转交给开发部门的领导。

7.7.2分析维护请求

负责人接受到维护请求后，进行分析：

（1）对于“纠错性维护”，首先确认Bug的真实情况，然后指定维护人员，协商安排修改Bug的任务进度。

然后告知客户相应的维护计划。

（2）对于“完善性维护”，负责人要综合分析