CMMI第05课2003.ppt

SP1.3需求管理的变更 典型成果 需求的状态记录 需求数据库 需求决策数据库 如何实现对变更的管理？ SP1.4维护需求的双向可追溯性 典型成果 需求跟踪矩阵 为什么？如何实现？ SP1.5识别项目工作与需求的不一致性 典型成果 用文档记录不一致处 相应的纠正措施 为什么？如何实现？ 需求管理是管理一个过程或一个组与别的过程或组间的需求传递，并且追踪工作产品和需求的完整性 如何实现需求管理，困难在哪儿？ 需求管理：确认、跟踪、变更控制 需求确认（评审和承诺） 需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求评审困难在哪儿？ 需求管理：确认、跟踪、变更控制 需求评审面临的困难 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。 需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。 开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。 开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。 人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。 需求管理：确认、跟踪、变更控制 需求承诺 需求承诺是指开发方和客户方的责任人对通过了正式技术评审的《产品需求规格说明书》作出承诺，该承诺具有商业合同的效果。 需求承诺的“八股文”如下： 本《产品需求规格说明书》建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该《产品需求规格说明书》开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。 甲方签字 乙方签字 人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。 需求管理：确认、跟踪、变更控制 需求跟踪 需求跟踪的目的是建立与维护“需求－设计－编程－测试”之间的一致性，确保所有的工作成果符合用户需求。 需求跟踪管理 在整个生命期需求的可能状态 被建议，根据需求的来源，责任人和相关人提出了需求 被拒绝，在一系列需求开发过程后，该需求没有被认可 被批准，在需求（特别是变更需求）被分析后，评估了合理性、可行性、成本、影响等要素，被确认可接受，被标注了新的版本号、给出了新的标号等属性，被加入到需求基线库中，进入实现过程 被实现，已实现设计、编码、单元测试 被验证，根据验收标准，已经通过集成以上的测试，被验证实现了需求的要求，被放置进配置基线库，表明需求已经被实现 被丢弃，被批准的需求已经从基线库中被丢弃，，记录下丢弃的原因和决定责任人 被交付，通过用户的验收测试，需求以交付物的形式向用户提交 需求的可能状态 如何知道需求状态之间的转变？ 需求跟踪前提条件？ 需求跟踪方法？ 需求管理：确认、跟踪、变更控制 需求跟踪有两种方式： 正向跟踪。检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。 需求变更管理 需求变更的原因？ 导致的问题？ 如何实现需求变更管理？ 需求管理：确认、跟踪、变更控制 需求发生变更的起因主要有： 随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。 市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。 提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。 需求管理：确认