软件项目管理—需求管理.ppt

软件项目管理,王颖,2,软件项目管理,什么 是 项目 ？,如何 获得 项目 ？,如何 管理 项目 ？,怎样 提交 项目 ？,结项后 应做 什么 ？,需求前延,质量检验过程,项目需求的实际验证,课程体系,3,如何管理项目？ (how to manage a project?),4,需求管理基础知识,5,软件项目管理的关键技术,需求管理,项目估算,进度管理,成本管理,配置管理,风险管理,质量管理,资源管理,6,需求管理的内容,什么是需求工程 什么是需求开发 什么是需求管理 需求管理所要完成的任务 需求管理的问题 如何进行需求管理,7,一、什么是需求工程,在项目或产品开发过程中，一般地来讲，把与需求直接相关的活动统称为需求工程。 需求工程的目的是通过与用户广泛地交流确定应用系统的目标。 需求活动以“工程化”的方法被提出、分析和组织，它鼓励用户以一种积极的方式参与需求分析活动中，并在整个软件生命周期强调用户参与和领域专家的指导作用，促使目标系统最大地满足用户需求。,8,软件需求的定义,Rational 把需求定义为“（正在构建的）系统必须符合的条件或具备的功能”。 软件需求： 用户解决某一问题或达到某一目标所需的软件功能。系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。 简单的说，软件需求就是确定系统需要做什么；严格意义上，软件需求是系统或软件必须达到的目标与能力。,9,软件需求与其它软件过程的关系,项目计划过程：需求是制定项目计划的基础，开发资源和进度安排的估计都要建立在对最终产品的真正理解之上。 跟踪控制过程：监控每项需求的状态，以便项目管理者能发现设计和验证是否达到了预期的要求。 变更控制过程：在需求编写成文档以后，所有接下来的变更都应通过确定的变更控制过程来进行，以确保变更的影响是可以接受的、受到变更影响的所有人都接到通知并明白这一点、由合适的人选来做出接受变更的正式决定、资源按需进行调整、保持需求文档是最新版本并是准确的更新文档。,10,软件需求与其它软件过程的关系,系统测试过程：软件需求是系统测试的重要参考。系统测试是一种方法，可以验证计划中所列的功能是否按预期要求实现了。同时，也验证了用户任务是否能正确地执行。 文档编制过程：产品的需求是编写文档的重要参考，低质量和拖延的需求会给编写用户文档带来极大的困难。 系统构建过程：软件项目最终交付的主要是可执行软件，而不是需求说明文档。但需求文档是所有设计、实现工作的基础，需要根据需求文档来确定模块设计，而模块又要作为编写代码的依据。系统构建过程需要跟踪每项需求与相应的设计和软件代码。,11,软件需求的抽象层次,软件设计描述,系统需求,用户需求,原始问题描述,原始问题描述,解决方案空间,12,软件需求的抽象层次,原始问题描述：是对要解决的问题的叙述，它是软件需求的基础。 用户需求：是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束。 系统需求：用详细术语给出系统要提供的服务及受到的约束，系统需求文档应该是精确的，可以为系统的实现提供依据，因而系统需求文档也称为功能描述，可能成为用户和软件开发组织之间合同的重要内容。 软件设计描述：是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述。,软件需求的抽象层次,用户需求：从用户的角度描述系统的需求，原则： 标准的格式 使用一致的语言 使用特殊文本 尽量避免专业术语,13,14,软件需求的抽象层次,系统需求的分类： 功能需求:描述系统所应提供的功能和服务,包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。 非功能需求:是指那些不直接与系统的具体功能相关的一类需求，是功能需求的补充。 领域需求:其来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。领域需求可能是功能需求，也可能是非功能需求，其确定需要领域知识。,软件需求质量评价,我们需要在软件需求规格说明书建立之后，就对软件需求的质量进行评价，一个好的需求集应该包括用户解决问题需要的功能和服务，而且尽量避免涉及软件设计与软件是实现的细节。,15,软件需求质量评价,16,软件需求质量度量的9个元素： 正确性 无歧义 完备性 一致性 根据重要性和稳定性分级 可验证性 可修改性 可跟踪性 可理解性,软件需求质量评价,正确性 需求集是正确的当且仅当其中每条需求都代表了构建软件系统所要完成的事情。,17,需求工程发展历程,20世纪80年代中期，软件工程的子领域需求工程（RE）逐步形成。它是一个包括创建和维护需求文档所必须的所有活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。 对应用问题及其环境进行理解与分析 为问题所涉及的信息和功能建立模型 将用户需求精确化和标准化 编写需求规格说明书 进入20世纪90年代后，需求工程成为研究热点。,18,需求工程发展历程,需求工程的发展趋势是对象化、形式化和自动化，并将向纵深发展和综合发展。,19,20,需求工程需求开发 + 需求管理,需求工程研究内容,21,需求开发与需求管理之间的界限,22,二、什么是需求开发,需求获取,需求获取是需求开发的第一个步骤，是一切工作的开始。从确定需求开发过程，确定如何组织需求的收集、分析、细化并核实的步骤，到将它编写成文档，主要的活动和展现成果有11项。,23,需求获取,确定需求开发过程 编写项目视图和范围文档 用户群分类 选择产品代表 建立核心队伍 确定使用实例 召开应用程序开发联系会议 分析用户工作流程 确定质量属性 检查问题报告 需求重用,24,需求获取 编写项目视图和范围文档,项目视图说明使所有项目参与者对项目的目标能达成共识；范围则是作为评估需求或者潜在特性的参考。,25,需求获取 用户群分类,什么是客户与用户 客户：直接或间接从产品中获得利益的个人或组织。 用户：软件系统的最终用户，是特殊的客户，他们是产品的直接使用者、操作者，是属于客户组织中操作层面上的成员。 用户群分类 不同的用户在很多方面存在着差异，可以根据差异将用户分成用户类，用户类不一定都是指人，其他应用程序或系统接口所用的硬件组件也可以看成是附加用户类的成员。,26,需求分析,需求分析包括提炼、分析和仔细审查已收集到的需求，以确保所有的项目参与者都明白其含义并找出其中的错误、遗漏或其他不足的地方。 绘制关联图 创建用户接口原型 分析可行性 确定需求优先级 建立需求模型 编写数据字典 应用质量功能调配,27,需求分析 数据流图,数据流程图中有以下几种主要元素： ：数据流。数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。 ：数据源（终点）。代表系统之外的实体，可以是人、物或其他软件系统。 ：对数据的加工（处理）。加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。 ：数据存储。表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等,28,需求分析 数据字典,数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。,29,编写需求文档,软件需求文档包括用户需求和详细的系统需求描述，是对软件系统要求的正式陈述。编写需求文档应注意以下几点： 语句和段落尽量简短 表达时采用主动语态 语句要完整，语法、标点等要正确 使用的术语要与词汇表中定义保持一致 陈述时要采用一致的格式 避免模糊的、主观的术语，如性能“优越” 避免使用比较性的词汇,30,需求之用例图,编写需求文档（续）,31,32,编写需求文档（续）,IEEE标准830-1998,编写需求文档（续）,需求文档实例： 进销存系统需求规格说明书 oa办公自动化系统需求规格说明书,33,34,需求验证,需求验证分析需求规格说明的正确性和可行性，检验需求能否反映客户的意愿。 重要性 如果在构造设计开始之前通过验证基于需求的测试计划和原型测试来验证需求的正确性及其质量，就能大大减少项目后期的返工现象。而如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工，因为需求的变化总是带来系统设计和实现的改变，从而使系统必须重新测试，由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大得多。,35,需求验证,目的： 需求规约正确描述了预期的系统行为和特征； 软件需求符合业务需求或其他来源的要求； 需求是完整和高质量的； 所有对需求的看法、观点是一致的； 需求为产品设计、构造和测试提供了坚实的基础 手段： 软件测试 软件评审,36,需求验证步骤,37,需求验证的内容,38,三、什么是需求管理,需求管理是一种获取、组织并记录软件需求的系统化方案，同时也是一个使客户与项目团队对不断变更的软件需求达成并保持一致的过程。 需求管理在需求开发的基础上进行，贯穿于整个软件项目过程，是软件项目管理的一部分。,39,需求管理与其他项目过程的联系,需求管理,制定项目计划,系统测试过程,项目跟踪和 控制过程,变更控制过程,制造过程,用户编制 文档过程,基础,基础,产品可 追溯到,作为 参考,验证实现 的正确性,作为 基线,进行 变更,跟踪 状态,作为 输入,基线确定前缩小范围,请求范围 缩减,40,为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。,四、为什么要进行需求管理,41,需求管理的困难性,开发软件系统最为困难的部分就是准确说明开发什么。 最为困难的概念性工作就是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。,42,需求获取的偏差,客户如此描述需求,项目经理如此理解,分析员如此设计,程序员如此编码,商业顾问如此诠释,项目文档如此编写,安装程序如此简洁,客户投资如此巨大,技术支持如此肤浅,实际需求原来如此,43,需求管理的困难性,需求不总是显而易见的，而且它可来自各个方面。 需求并不总是能容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求的数量将难以管理。 需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。 需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。 需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。 需求会变更。,44,需求管理的目标,需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定： 使软件需求受控，并建立供软件工程和管理使用的需求基线。必须控制需求基线的变动，按照变更控制的标准和规范的过程进行需求变更控制和版本控制。 使软件计划、产品和活动与软件需求保持一致。必须对需求进行跟踪，管理需求和其它联系链之间的联系和依赖，必须就变更和软件项目各小组达成共识，对软件项目计划做出调整，其中包括人员的安排、任务的安排、用户的沟通、成本的调整、进度的调整等。,45,需求管理的原则,需求一定要分类管理 需求必须分优先级 需求必须文档化 需求一旦变化，就必须对需求变更的影响进行评估 需求管理必须与需求工程的其它活动紧密整合,46,需求管理策略,需求一定要与投入有必然的联系 需求的变更要经过出资者的认可 小的需求变更也要经过正规的需求管理流程 精确的需求与范围定义并不会阻止需求的变更,47,五、如何进行需求管理,需求管理的关键技巧 需求管理的工具,48,制定需求管理规划,编写用于需求管理活动的计划。 需求识别 变更管理过程 需求跟踪 自动化工具,49,需求管理活动,50,构建功能交叉的需求团队,与诸如测试或应用程序建模等流程不同（这些流程可在单个业务组中进行管理），需求管理涉及了每一个能够为开发流程提供专门技术的个人； 其中应包括那些代表客户和业务预期的人； 开发经理、产品经理、分析员、系统工程师甚至客户都应该参与进来； 需求团队还应包括创建系统解决方案的人 - 工程师、构架设计师、设计员、程序员、技术文档编写员以及其他提供技术支持的个人； 测试员和其他质量保证人员应当作重要的团队成员。,51,干系人需求知识培训,目的：建立对需求管理过程的共识 作用： 控制客户期望 保证需求过程的质量 保证需求的质量,52,软件客户的权利,要求分析人员使用符合客户语言习惯的表达,要求分析人员了解客户系统的业务及目标,要求分析人员组织需求获取期间所介绍的信息，并编写软件需求规格说明,要求开发人员对需求过程中所产生的工作结果进行解释说明,要求开发人员在整个交流过程中保持和维护一种合作的职业态度,要求开发人员对产品的实现及需求都要提供建议，拿出主意,描述产品使其具有易用、好用的特性,可以调整需求，允许重用已有的软件组件,当需要对需求进行变更时，对成本、影响、得失（ trade-off）有个真实可信的评估,获得满足客户功能和质量要求的系统，并且这些要求是开发人员同意的,53,软件客户的义务,给分析人员讲解业务及说明业务方面的术语等专业问题,抽出时间清楚地说明需求并不断完善,当说明系统需求时，力求准确详细,需要时要及时对需求做出决策,要尊重开发人员的成本估算和对需求的可行性分析,对单项需求、系统特性或使用实例划分优先级,评审需求文档和原型,一旦知道要对项目需求进行变更，要马上与开发人员联系,在要求需求变更时，应遵照开发组织确定的工作过程来处理,尊重需求工程中开发人员采用的流程（过程）,54,范围管理,在需求超出资源能力200%时，“砍”掉50%需求的步骤： 找出25-50个概要需求，先不要精化 排定这些概要需求的价值(Critical, Important, Useful)，Critical需求约占三分之一 初估各个需求的工作量级别(High, Medium, Low) 给出各个需求的风险级别(High, Medium, Low) 综合考虑以上三个因素得出优先级，再划出分界线，线上基本上包括所有Critical和少量Important需求,55,需求的变更管理,1 、需求的变更难于完全避免,需求的变更,56,2、需求变更原因分析,单纯的用户因素 市场形势变化 系统因素 工作环境和要求变化 需求开发的缺陷 需求分析、定义和评审不充分 与用户沟通不畅,需求的变更管理,57,3、需求变更对软件开发的影响, 使变更前开发工作和成果失效 返工成为被迫采取的对策 工作量及资源投入的增加使开发成本提高 项目完成时间后延,需求的变更管理,58,4、需求变更失控可能导致的后果, 未受控的需求 变更引起需求 和实现不一致,需求的变更管理,59, 受控的需求 变更使需求和实现一致,未受控及受控的需求变更,需求的变更管理,60,5、降低需求变更风险的策略, 与用户充分沟通 与用户共同明确确定的需求的意义,向用户说明需求不确切或频繁变更对开发工作的冲击 使用户理解过多变更最终对用户不利,需求的变更管理,61, 与用户共同确定需求，作为合同附件， 签字生效 合同中含有对需求变更的条款 采用原型方法开发，或螺旋模型开发 项目计划中适当留有余地（时间进度、人力投入、费用等） 严格实施变更控制,需求的变更管理,62,6、需求变更控制要求 变更控制的策略 所有需求变更必须遵循需求变更控制规程实施变更。 需求变更提出后是否被接受，应由专门的组织变 更控制委员会（CCBChange Control Board）审查决定。 不得以任何理由删除和修改需求变更的原始文件。 应将已接受的需求变更通知到所有相关人员。 已接受的需求变更应能追溯到批准的变更请求。 对项目的需求赋予状态属性，以利于需求变更的控制。,需求的变更管理,63,需求变更影响的控制 由于分配需求的变更导致软件计划、工作产品和活动的变更，都应对其作： 识别 评价 风险分析 编制文档 制定计划 传达给受影响的小组和人员 跟踪直至结束,需求的变更管理,64,需求的变更管理变更管理过程,变更控制的步骤 提出变更请求 审理变更请求，进行变更影响评估。评估内容包括： 变更所需人力投入 变更对原计划安排的影响 估计变更引起的成本增加 批准变更请求 取得用户的认可 修订项目计划 实施变更 验证变更,需求的变更管理（案例）,需求变更请求表,66,变更需求状态转换图,67,需求的状态,需求要考虑的属性： 需求的创建时间 需求的版本 需求的创建者 需求的批准者 需求状态 需求的原因或根据 需求涉及的子系统 需求涉及的产品版本 需求的验证方式或测试标准 需求的优先级 需求的稳定性,68,需求的状态,已建议：需求已经被有权提出需求的人所建议。 已批准：需求已经被分析，估计了其对项目其余部分的影响；已经用确定的产品版本号或创建编号分配倒相关的基线中；软件开发团队已经同意实现它。 已拒绝：需求已经有人提出，但被拒绝了。拒绝的需求被列出的目的是因为它有可能被再次提出。 已设计：已经完成了需求的设计和评审。 已实现：已经完成了需求功能代码的设计、编写和单元测试。 已验证：已经使用某种方法验证了实现的需求，需求能够达到预期的效果，此时认为需求已经完成。 已交付：需求完成后，已经交付用户进行使用。 已删除：计划的需求已经从基线中删除，但需要给出做出删除决定的人员及删除的原因。,69,需求状态的变迁,已建议,已批准,已删除,提出需求,需求分析 并被接受,需求的设计和评审,从基线中删除,从基线中删除,从基线中删除,已拒绝,被拒绝,需求文档版本控制,需求文档的版本控制就是保证软件项目干系人得到最新版本的需求文档和记录需求的全部历史版本。做好需求文档必须保证以下几点： 统一确定需求文档的每个版本，保证每个成员都能得到当前最新的需求文档版本 清楚地将变更写成文档，并及时通知到项目干系人 为尽量减少困惑、冲突、误传，应只允许指定的负责人来更新需求文档,70,71,需求的可跟踪性管理,在软件能力成熟度模型CMM三级中要求软件团队必须具备需求跟踪的能力，即“在软件工作产品之间，维护一致性。工作产品包括软件计划，过程描述，分配需求，软件需求，软件设计，代码，测试计划，以及测试过程。” 目的： 建立和维护从用户需求开始到测试之间的一致性与完整性 确保所有的实现都以用户需求为基础，而实现的需求也全部覆盖了预期的需求 确保所有的输出与用户需求的符合性 使每一项需求前后继承关系的脉络清晰可见,72,需求的可跟踪性管理,原因： 随着开发工作的进展需求将逐步扩展和演化 各个开发阶段的工作产品之间存在的继承关系，没有一个需求表述是孤立存在的 团队为了确定变更带来的影响，保证系统符合预期，就必须理解、记录并维护这些可追踪性关系。,73,需求的可跟踪性管理,可追溯性信息： 源可追溯性信息:用来说明连接需求到提出需求的项目干系人和产生需求的原因。当需求变更发生的时候，该信息用来发现项目干系人以便能与他们商讨这些变更事宜。 需求可追溯性信息：用来说明连接需求文档中彼此依赖的需求。该信息用来评估一个需求变更会对其余多少需求产生影响以及引发的需求变更的范围和程度。 设计可追溯性信息：用来说明连接需求到其实现的设计模块。该信息用来评估需求变更对系统设计和实现带来的影响。,74,在项目开发周期中跟踪需求状态的分布,75,需求控制流,需求状态及其演变 软件需求在后继阶段开发工作中将逐步展开，加以实现。 在不同的开发阶段软件需求以不同的形式进行着状态的演变。 例如： 需求阶段：从获取的需求到定义的需求 建议阶段：制定出项目计划以后演化为承诺的需求 设计阶段：设计工作完成并在验收后成为设计的需求 编码阶段：完成编码和单元测试后成为实现的需求 测试阶段：完成确认测试后成为完成的需求,76,生存期各阶段需求状态的演变,需求控制流,77,需求的可跟踪性管理,实现方法： 正向跟踪：以用户需求为切入点，检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。 逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处。 需求跟踪矩阵：,78,作用： 可防止遗漏 为评审提供方便 便于进行变更影响追踪、分析和检查,需求跟踪矩阵,79,单跟踪矩阵,80,二维跟踪矩阵,81,两种跟踪矩阵比较,需求的可跟踪性管理（案例）,需求跟踪矩阵,83,需求的可跟踪性管理,作用： 在需求验证中：需求跟踪信息便于确保所有需求被应用 有助于需求变更影响分析 便于需求的维护 便于测试时找出问题所在 便于项目跟踪 减小项目的风险 简化了系统的再设计 易于软件重用,84,需求状态评审,高级管理者和项目经理通过需求状态评审监控需求管理的状态。项目组通过需求状态评审对需求状况达成一致。 报告需求状态 生成需求管理状态报告 举行评审会议 举行需求状态评审会议，对需求的状态进行评估。可作为里程碑评审的一部分。,85,需求评审,评审的两类方式 正式技术评审（也称同行评审） 非正式技术评审 需求评审是一项重要的需求验证技术 需求分析完成后，应由用户和系统分析员共同进行需求评审,86,需求评审的目的,发现缺陷，提高质量 减少软件开发/维护的时间和费用 加强培训，预防缺陷，提高生产率 提高估算准确性 改进开发过程 需求设计阶段的评审发现缺陷的有效性最高达到75%，比测试有效20倍以上 投资回报率从4:1到30:1,87,需求评审注意事项,严格控制每一次评审的文档规模及持续时间 评审工作要分段进行 对讨论的问题进行控制 避免无谓的争吵,88,需求管理的关键技巧,关键技巧 1：分析问题 关键技巧 2：理解涉众需要 关键技巧 3：定义系统 关键技巧 4：管理系统规模 关键技巧 5：改进系统定义 关键技巧 6：管理变更的需求,89,关键技巧 1：分析问题,进行问题分析是为了理解业务问题，确定涉众的最初需要，并提出高层解决方案。这些推理和分析行为找出“隐藏在问题背后的问题”。 在问题分析过程中，将对实际问题的说明取得一致，并确定有关的涉众。初始解决方案的界限和约束从技术和业务两个方面来定义。在适当的时候，项目的商业理由还分析期望从系统获得的投资回报。,90,关键技巧 2：理解涉众需要,需求有许多来源。它们可能来自于对项目结果感兴趣的任何人。客户、合作伙伴、最终用户以及领域专家都是某些需求的来源。而管理人员、项目团队成员、业务策略和管理机构是另外一些需求源。 因此，掌握如何确定哪