第7章 idp项目研y发过程.docVIP

 7.1 需求开发与管理 4 7.1.1 需求调研 5 7.1.2 需求分析 6 7.1.3 需求定义 6 7.1.4 需求评审确认 7 7.1.5 需求细化跟踪 8 7.1.6 需求变更控制 8 7.2 软件系统设计 9 7.2.1 系统结构设计 10 7.2.2 用户界面设计 10 7.2.3 数据库设计 11 7.2.4 系统设计评审 12 7.3 模块开发和集成 12 7.3.1 模块需求细化 12 7.3.2 模块设计 13 7.3.3 模块实现和集成 14 7.4 测试与改错 14 7.4.1 测试准备 14 7.4.2 执行测试 16 7.4.3 消除缺陷 16 7.5 软硬件系统集成 17 7.5.1 系统集成方案设计 17 7.5.2 选择设备供应商 17 7.5.3 设备采购和验收 18 7.5.4 设备安装调试 18 7.6 部署试用 18 7.6.1 撰写文档 19 7.6.2 软件部署 19 7.6.3 客户培训 20 7.6.4 客户试用 20 7.7 软件维护 21 7.7.1 接受维护请求 21 7.7.2 分析维护请求 22 7.7.3 执行维护 22 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 需求定义 需求分析员根据需求调查和需求分析的结果，进一