软件工程概论第13章 软件项目管理.ppt

为克服甘特图的缺点，将 甘特图做了一些修改，形 成了时标网状图（time Scalar network）。 图中的任务以有向线段表 示，其指向点表示任务间 的衔接点，并且都给予编 号，可以显示出各子任务 间的依赖关系。它显示出 比甘特图具有优越性。 时标网状图 计划评审技术（program evaluation and review techique，PERT）也称网络图方法，或简称PERT图方 法，它的另一名称是关键路径法（critical path method， CPM）。 PERT图 PERT图 PERT图中以有向的箭头作为边表示子任务，它是有名称（即子任务名）、有长度（即完成此项子任务所需的时间）的向量； 以有编号的圆圈作为结点，它应该是子任务向量的始发点或指向点； 由若干条边和若干个结点构成了网状图，于是我们可以沿相互衔接的子任务形成的路径，进行路径长度的计算、比较和分析，从而实现项目工期的控制。 实例 PERT图 实例 PERT图 实例 分层PERT图 系统需求与软件需求 需求工程 需求变更 需求变更控制 可追溯性管理 13.5 需求管理 系统和系统需求分配 系统：通常考虑的系统是指基于计算机的系统或计算机控制的系统，它是在计算机控制下完成特定功能的系统。例如，航空管制系统、飞行器惯性导航系统、生产控制系统等。 系统需求分配：系统工程组面对用户，负有开发系统的责任。系统工程组在从用户那里取得系统需求以后，应将系统需求进行分解，也就是把已确定的系统需求分配给系统的各个组成部分。 13.5.1 系统需求与软件需求 系统和系统需求分配 13.5.1 系统需求与软件需求 系统和系统需求分配 13.5.1 系统需求与软件需求 软件需求 按IEEESTD610标准的定义，软件需求是用户为解决某个问题或为实现某个目标，要求软件必须满足的条件或能力。 软件需求的3个层次如下： 1）业务需求：客户对软件的高层目标要求。 2）用户需求：用户使用软件必须达到的要求和完成的任务。通常在用例(use case)或方案脚本(scenario)中加以说明。 3）功能和非功能需求。规定了开发人员必须实现的需求，它的实现将满足上述业务需求和用户需求。通常以需求规格说明(requirement specification)的形式给以详尽描述。 13.5.1 系统需求与软件需求 软件需求 非功能需求包括以下两种： 1）过程需求：交付需求、实现需求、遵循的标准。 2）外部需求：互操作性、伦理性、机密性、安全性等。 13.5.1 系统需求与软件需求 软件需求 质量功能展开（QFD）：QFD是将客户的要求转化为软件技术需求的质量管理方法，于1970年在日本推出。 QFD将客户的需求分为3类：。 1）常规需求：它是客户明确提出的需求，软件开发组织必须千方百计设法将其实现，使客户得到起码的满足。 2）期望需求：这是一些隐含而未被客户明确提出的需求。也可称此为客户的潜在需求。 3）兴奋需求：客户完全没有想到的需求，如果产品中未将其实现，客户并不抱怨；但若真的实现了，就会超出客户的想象，他们会感到十分惊讶和非常满意。 13.5.1 系统需求与软件需求 需求工程是系统工程或软件工程中解决需求问题的一个崭新领域。其目标在于使得到的产品能够准确、真实地体现客户的需求，令客户满意。 需求工程包括两个 方面：需求开发与 需求管理。 13.5.2 需求工程 需求开发与需求管理的关系 13.5.2 需求工程 需求变更难于完全避免 系统需求或软件需求往往在开发工程中发生变更，提出变更有可能在开发的任何阶段。 13.5.3 需求变更 13.5.3 需求变更 需求变更原因分析 单纯的用户因素。 市场形势变化引发的需求变更。 系统因素。在系统内部，如计算机硬件、系统软件或数据等的变更要求软件与其相适应。 工作环境因素。与软件运行相关的工作制度或法规、政策的变更，或业务要求变更导致的需求变更。 需求开发工作有缺陷，可能有两种情况：一是需求分析、定义和评审工作不够充分，致使需求规格说明中隐含着问题；二是需求开发中开发人员与用户沟通不够充分。 13.5.3 需求变更 需求变更对软件开发工作的影响 使得变更前的开发工作和成果失效。 使得返工成为不得不采取的对策。 势必带来软件开发计划的相应变更、开发成本的相应增加和开发工作量及资源投入的追加。 13.5.3 需求变更 需求变更失控可能导致的后果 可能导致开发出的产品不符合变更了的需求，也就是得到的产品并不是用户所需要的产品这样的严重后果。 13.5.3 需求变更 降低需求变更风险的策略 在需求开发工作中要与客户充分沟通。 与用户共同确定需求。 开发组织和用户双方签署的项目开发合同中应包括对出现需