《第7章IDP项目研发过程》由会员分享，可在线阅读，更多相关《第7章IDP项目研发过程（23页珍藏版）》请在金锄头文库上搜索。
1、第7章IDP项目研发过程7.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 数据库设计 127.2.4 系统设计评审 127.3 模块开发和集成 127.3.1 模块需求细化 127.3.2 模块设计 137.3.3 模块实现和集成 147.4 测试与改错 147.4.1 测试准备 157.4.2 执行测试 167.4.3 消除缺陷 167.5 软硬件系统集成177.5.
2、1 系统集成方案设计 187.5.2 选择设备供应商 187.5.3 设备采购和验收 187.5.4 设备安装调试 187.6 部署试用 197.6.1 撰写文档 197.6.2 软件部署 197.6.3 客户培训 207.6.4 客户试用 217.7 软件维护 227.7.1 接受维护请求 227.7.2 分析维护请求 227.7.3 执行维护 237.1 需求开发与管理需求开发与管理的目的是通过“调研、分析、定义、评审确认、细化跟踪、变更控制”等活动，使开发方和客户对需求有共同、清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等）。需求开发与管理的流程如图7-1所示，该
3、流程的主要工作成果和责任人见表7-1。一般地，在立项之前，产品经理应当撰写产品需求说明书，项目销售人员应当撰写合同项目需求说明书。但是此时的需求说明书通常是宏观粗略的，不足以让项目开发团队依据此需求说明书开展设计和编程工作。项目开发团队应当在产品经理、销售人员的工作成果基础之上，进一步开展需求调 研、分析、定义、评审确认、细化和跟踪活动。项目经理根据本项目的人力资源来确定 需求分析员（通常是项目经理或资深开发工程师担任需求分析员）表7-1主要工作成果和责任人7.1.1 需求调研需求分析员起草需求问题表，将调查重点锁定在该问题表内，否则调研工作将变得 漫无边际。需求分析员确定需求调研的方式，例如
4、：与用户交谈，向用户提问题。参观用户的工作流程，观察用户的操作。向用户群体发调查问卷。与同行、专家交谈，听取他们的意见。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。从Internet上搜查相关资料。需求分析员与被访谈者建立联系，确定调查的时间、地点、人员等，要特别留意的 是不要漏掉典型的用户。需求分析员在调研过程中随时填写“客户需求记录”，参考格式如表 7-2所示。提示:集成化研发管理平台RDMS的“客户需求记录”功能满足此要求。项目名称需求分析员被调研者调研方式如面谈，电话交谈等时间、地点需求标题描述表7-2客户需求记录的参考格式需求分析员整理所有客户需求记录，归纳与总
5、结共性的需求，为撰写详细的需求 说明书作准备。调研过程中获取的需求信息可以作为需求说明书的附件。7.1.2 需求分析需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。问答分析最重要的问题是： “是什么”和“为什么” 。每个需求都应当用陈述句说明“是什么” ，如果“是什么”的内涵不够清晰，则应补充说明“不是什么” 。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么” ，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与
6、文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。现代建模工具如 Rose 有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。世上不存在一个包罗万象的图用以完整地描述需求。 需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。 建议将模型存放在需求文档的附录中，便于正文引用。7.1.3 需求定义需求分析员根据需求调查和需求分析的结果， 进一步定义准确无误的需求， 产生 需求说明书 。产品需求说明书的模板参
7、见表5-2 ，合同项目需求说明书的模板参见表5-7 。好的需求说明书有如下特征：?正确：需求文档应当正确地反映客户的真实意图。?清楚：清楚的需求让人易读易懂。?无二义性：每个需求只有唯一的含义。?一致：需求文档的上下文之间不会发生矛盾。?必要：需求文档中的各项需求对用户而言应当都是必要的。?完备：需求文档中没有遗漏必要的需求。?可实现：需求文档中的各项需求对 开发方 而言应当都是可实现的。可验证：需求文档中的各项需求对客户方 而言应当都是可验证的。7.1.4 需求评审确认一、需求评审需求分析员邀请项目成员（包括项目经理）和客户代表共同评审需求说明书 大家尽最大努力使需求说明书能够正确无误地反映
8、用户的真实意愿。需求评审的流程和技术评审流程相同，如图7-2所示。一般地，需求分析员为申请人，项目经理为评审负责人，项目成员和客户代表可以担任评审员。所有评审人员认真 检查需求文档，力求使需求文档达到正确、清楚、无二义性、一致、必要、完备、可实 现、可验证。m执行负责人申请需求评审执行需求评审会议图7-2需求评审流程二、需求确认需求确认是指当需求说明书通过评审之后，开发方负责人和客户方负责人作书面承诺，使之具有商业合同效果。提示：书面承诺一般放在需求说明书的最后一页。人们作出书面承诺之前务必要认真阅读文档,定要明白签字意味着什么。“书面承诺”的示例如下:本需求说明书建立在双方对需求的共同理解基
9、础之上，我同意后续的开发工作 根据该需求说明书开展。如果需求发生变化，我们将按照“需求变更控制流程”执 行。我明白需求的变更将导致双方重新协商成本、资源和进度等。7.1.5 需求细化跟踪在后续开发过程中，人们会对原先的需求文档进行细化。为了提高工作效率，补充需求细节不必按照需求变更来处理。需求分析员将补充的需求内容保存在新的文档中，及时通知相关开发人员，只要大家正确理解了新的需求内容即可。需求分析员要填写需求跟踪表，及时检查后续开发成果是否和需求保持一致。CMMI建议的“需求跟踪矩阵”要把“需求一设计一代码一测试”的所有关系全部罗列出来， 过于复杂和麻烦。根据作者调查，几乎没有人能够长期使用理
10、想化的“需求跟踪矩阵”7-3所示。提示：集成化研为了提高需求跟踪的效率，应当简化需求跟踪表，如表 发管理平台 RDMS的“项目需求管理”功能满足此要求。项目名称需求目录需求变更对应测试用例相关缺陷跟踪记录表7-3简化的需求跟踪表7.1.6 需求变更控制对大多数项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因 主要有：? 随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原 先的需求文档可能存在这样那样的错误或不足，因此要变更需求。? 市场发生了变化，原先的需求文档可能跟不上当前市场需求，因此要变更需求。提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。
11、对项目开发团 队而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发团队 要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能 按时完成。需求变更控制的动机是：(1)如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更 规程执行，以免变更失去控制。(2)如果需求变更带来的坏处大于好处，那么拒绝变更。需求的变更应当遵循“变更控制流程”，即“变更申请审批 执行”，详见本书第6.3.2节“变更控制”。7.2软件系统设计软件系统设计的主要内容有体系结构设计、用户界面设计、数据库设计和设计评审，在需求与代码之间建立桥梁，指导工作人员开发能够满足用
12、户需求的软件系统。如图7-3所示。产生软件系统设计说明 书和“可运行系统框架”图7-3软件系统设计的示意图项目经理根据本项目的人力资源来确定系统设计师(可以多人)。系统设计师撰写 软件系统设计说明书，并构造可运行的软件系统框架，所有的模块都是在该系统框架上开发和运行。软件系统设计说明书的模板参见表 7-4。软件系统设计说明书1 .系统概述2 .设计约束3 .开发、测试与运行环境4 .软件系统结构图5 .功能模块设计概述5.1 模块汇总5.2 模块之间的关系6 .数据库设计概述6.1 数据库环境说明6.2 数据库命名规则6.3 安全性设计说明6.4 表汇总和表设计（使用表设计工具PowerDes
13、ign ）7 .用户界面设计概述8 .综合考虑（可选）8.1 稳定性和可扩展性8.2 性能分析8.3 复用和移植8.4 防错与出错处理8.5 其它表7-4软件系统设计说明书7.2.1 系统结构设计系统设计师进行系统结构设计：? 确定本系统的约束条件；? 确定本系统的开发、测试和运行环境；? 将系统分解为模块，确定每个模块的功能，以及模块之间的关系，绘制系统结 构图。7.2.2 用户界面设计系统设计师设计和构建用户界面原型，目的是：? 加深开发方和客户方对软件需求的理解（界面原型直观地反映了软件需求）? 在编程之前让相关人员看到用户界面原型，不仅可以提高界面的易用性，还提 高了程序员的开发效率（
14、避免反复修改界面及其代码）。第1步绘制界面示意图系统设计师首先分析用户对界面的需求，例如：?用户的工作习惯?用户对界面有什么喜好?有什么强制要求?是否有范例系统设计师构思并绘制用户界面示意图，常用方式如下：?在纸张上绘制用户界面示意图（效率高但是不便于保存）?用 Word 或者 Visio 等工具绘制线框图（效率低但可以作为文档保存）第 2 步 制作界面原型系统设计师制作界面原型 （通过编程或者绘图等方式） ， 将所有界面原型的图片保存在指定的文件夹中，并用 HTML 建立简要的索引，这样做的好处有：?便于其他人员审阅（使用 IE 浏览） ；?需求分析员不必将界面原型图片插入到需求文档中；?修改界面原型图片将不会影响其它文件；第3 步 体验和改进界面设计师邀请项目成员或者用户来体验界面原型，大家给出改进建议，力求使用户界面满足以下10 个设计要素：（ 1 ）用户界面适合于展现软件的功能（ 2 ）适合用户群体（ 2 ）容易理解（ 3 ）及时反馈信息（ 4 ）防错处理（ 5 ）合理的布局（ 6 ）合理的色彩（ 7 ）风格一致和必要的个性化（ 9 ）最少操作步骤（最高效率）（ 10）国际化、可复用等7.2.3 数据库设计系统设计师进行数据库设计：? 确定数据库的环境说明? 确定数据库的命名规则? 确定安全性设计方法? 使用表设计工具PowerDes
