王莹《软件项目管理教学》软件项目管理（10）.pptVIP

例：需求分析的裁剪指南 4.2-2 详细裁剪指南 4.2-2 详细裁剪指南 4.2-2 详细裁剪指南 4.2-2 详细裁剪指南 编码裁剪指南 一般的变更管理过程 记录变更 分析变更对工作产品的影响 估计变更申请所需的工作量 重新估计交付时间表 执行累计的成本影响风险 如果影响超出一定的限度，则与高级主管一起评审影响 客户不再提出变更申请 修改工作产品 3.3 需求变更管理 跟踪矩阵 3.4 需求跟踪管理 跟踪矩阵的维护和使用——完整性检查 浏览矩阵中的需求数目和需求文档中的需求，确保矩阵中列出所有需求没有遗漏； 在矩阵中指出每一个程序、类和其他单元，保证矩阵中所有程序在最终软件中都是必要的； 通过确保功能需求没有空白列来检查需求的实现； 对于每一个性能需求都应该设计一些测试用例； 集成测试和系统测试计划可以和矩阵一起进行交叉检查 3.4 需求跟踪管理 案例：Steven的烦恼 Steven刚出任项目经理，承接了一个中型软件项目。公司叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。 但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。 而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费3天时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。 随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面， Steven只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。 3.4 需求跟踪管理 案例：Steven的烦恼 专人负责需求变更，需要有明确的的授权 需要对变更进行必要的审核 变更的影响需要有明确的的评估 需要用户确认是否接受变更代价 实践中的总结： 需求优先排序，分批实现 软件开发人员与用户相互协作 双方需要充分交流 安排专职人员负责需求变更管理 合同约束力 增加的需求区别对待 建议以系统原型入手尽量降低需求变更的出现频率 3.4 需求跟踪管理 软件开发过程及描述 过程裁剪 第四章 过程定义和过程裁剪 过程描述/定义 过程描述是项目可以用来遵照执行某些任务的一系列步骤，以及执行这些步骤的指南。 开发过程是提炼用户需求，设计、构建和测试满足这些需求的软件并最终将其交付给客户所需的过程。当开发新的应用或计划为现有的应用进行重要的增强时，就要使用开发过程。 4.1 过程定义 4.1-1 软件开发过程 4.1-1 软件开发过程 4.1-1 软件开发过程 4.1-1 软件开发过程 4.1-1 软件开发过程 给出从计算机的逻辑角度开发针对用户需求的解决方案。 参加者：设计团队、评审团队、客户 输入准则：需求规格文档经过评审并授权 输入：需求规格文档 输出准则：概要设计文档经过评审和授权 输出：概要设计文档、项目标准、概要设计评审记录 度量：概要设计工作量、概要设计缺陷、评审工作量、返工工作量 4.1-2 概要设计 主要步骤： 定义标准，包括编码标准、文档标准和用户接口标准等等 操作环境的决策 进行功能设计： 确定功能 确定事件和功能之间的交叉参考 确定每个功能的处理细节 生成功能体系结构并归档 物理数据库设计 确定数据模型 将实体和关系转化为表和记录类型 执行规模估计：对数据进行规模的估计 执行受控非标准化 确定索引 4.1-2 概要设计 进一步对概要设计中的整体应用分解，分解成模块和程序，对程序进行逻辑设计。 参加者：设计团队 输入准则：概要设计文档经过评审和授权 输入：概要设计文档 输出准则：详细设计文档和单元测试计划已经经过评审和授权 输