免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2015年下半年 信息系统项目管理师 下午试卷 案例
  第3题      
  知识点：   方案设计   评估   信息系统项目   需求分析   需求管理   预测

 
[说明]
某公司2014年初承接了一个周期为一年的OA信息系统项目，并指派项目经理小张负责。该项目属于定制型项目，涉及的用户方较多，小张根据自己的经验预测到项目可能会涉及频繁的需求变更，因此小张在将项目组分成了业务组、实施组、开发组后，定义了如下需求管理及控制流程：
(1)指派专门的业务组进行需求分析，分析完成后马上与用户进行需求确认，确认后填写需求状态表（包括需求提交日期、需求状态、是否属于变更等）；
(2)实施组获得需求分析文档后，一周内进行技术方案设计；
(3)技术方案完成后，业务组视情况与用户进行二次沟通确认，确认后填写需求状态表（包括需求技术方案提交日期、需求技术方案状态）；
(4)需求分析、技术方案完成后，开发组每周对已确定需求进行工作量评估，形成月度开发计划；
(5)开发组根据开发计划进行定制开发工作；
(6)每周开发组根据需求状态库的需求、方案进行工作量重新评估，更新开发计划。
项目进行过程中，发生了如下事件，导致项目延期半年才完成：
[事件1]根据20 14年初的计划开发完成了OA信息系统项目并上线，但用户役有真正使用。2014年底推广使用的时候发现，业务流程有缺失，程序有BUG，于是项目组重新按照以上流程梳理了需求，并重新开发上线。
[事件2] 2014年底，开发组提出需求分析在深度、广度上不够，导致开发返工任务多。
 
问题：3.1   结合案例及你的工作经验，请说明项目经理小张在需求管理及控制过程中存在哪些不足？
 
问题：3.2   结合案例，围绕需求管理，请将下面(1)～(2)处的答案填写在答题纸的对应栏内。案例中，2014年底推广使用的时候发现，业务流程有缺失，这一现象是由于缺乏(1)中的(2)。
 
问题：3.3   结合案例和个人经验，简要叙述项目中需求可能存在的几种状态。
 
问题：3.4   如果你是小张的经理，请帮助小张改进需求管理及控制过程中的不足。
 
 
 

   知识点讲解    
   · 方案设计    · 评估    · 信息系统项目    · 需求分析    · 需求管理    · 预测
 
       方案设计
        系统方案设计包括总体设计和各部分的详细设计。
        .系统总体设计：包括系统的总体架构方案设计、软件系统的总体架构设计、数据存储的总体设计、计算机和网络系统的方案设计等。
        .系统详细设计：包括代码设计、数据库设计、人机界面设计、处理过程设计等。
 
       评估
        评估测试不只针对物理设备，更重要的是要评估、比较各种网络技术。通常使用模拟测试配置和模拟负载进行子系统（如路由器）和网络技术（如ATM或FDDI等）的评估。评估测试不适用于全局网络，因为全局网络拓扑负载、网络设备太多，不好准确定位引起问题的原因和位置，不能进行有效的比较。多数评估测试在专用的子网测试环境中进行。
        很多公司都有其固定合作的网络设备供应商，如路由器、集线器或交换机的供应商，通常很少再做设备比较测试，但网络技术的比较测试需要经常进行。企业经常面对选择哪种技术以及怎样比较不同技术的问题，所以技术评估是评估测试中很重要的一项。
        在比较设备与技术时，除了使用专用于待测设备或技术的工程负载外，有经验的程序员也使用真实负载，使用真实负载可以了解待测设备或技术在特定环境下的运行性能。通过两种负载模式检测结果的比较，可以获知待测设备还有多少多余容量。
        评估测试与设备或技术的功能／特征测试一样，用于比较待测设备或技术的性能、稳定性、特性、易用性配置和管理等方面的功能。
        评估测试实质是衰减测试的基础，评估测试中对几种设备或技术进行比较；衰减测试中对同一设备的不同版本进行比较。测试中选择设备的标准也完全可作为验证升级版本工作正常与否的标准。尽可能多地集成在计划／设计阶段进行测试是非常好的方法，最初的产品评估测试可以被开发阶段的可接受性测试和升级阶段的衰减性测试所借鉴。
        评估测试是最常进行的测试，在设备选型、技术选型，以及网络系统升级过程中都要进行或多或少的评估测试。
        用于评估测试的负载模式和测试脚本要能有效覆盖被检测的设备和技术。常使用最好情形（工程负载）和真实负载模式进行测试，两种方式都提供了唯一的、重要的检测结果，测试人员要能够理解、解释测试结果间的不同。
        工程检测结果是被测设备和技术在最理想的情形下测试得到的结果，因此不能在真实运行环境里显示它们的运行性能；真实检测结果能很好地显示待测设备或技术在运行网络环境中的性能，但无法预测设备的总容量。如果时间允许，两种测试都要做。通常测试人员只有时间进行一种测试，一般进行最好情形的测试。许多公开发行的测试报告都是基于最好情形（工程负载）下的测试结果。
        所有的测试配置都是模拟的。用于设备比较的测试配置不一定要代表运行网络的典型配置，任何有效、公正的测试配置都能对被测产品进行很好的比较。然而，测试配置和负载越接近运行网络的配置和负载，测试的结果越能反映被测设备在运行网络中的运行情况。
        在安装和配置测试网络时必须注意：要确保配置中所有测试组件都是最新版本，使测试尽可能地公正和统一，以取得最好的测试结果。在测试非正式版时一定要小心，因为发布日期经常有错误。测试配置中安装了非正式版后，它还可能会变，所以非正式版的测试结果和正式版的测试结果经常不一致，分析非正式版的设备经常会延误项目的进行。
        进行评估测试时，除了被测设备，测试配置中的所有网络组件都要保持不变。这一点非常重要，只有这样才能保证被测设备可以进行公平比较。对于子网，这一点很容易做到（一个网络设备很容易被另一个设备所替代）。
        网络技术评估要比较各种网络技术，因而测试配置中的几个网络组件都需要更换。重要的是不要改变源或目标配置。在配置中不仅通信线路需要更换，路由器也需要更换。传输负载和端点的配置要保持不变。
        需要评估测试计划中的各个测试任务，逐步完成测试、数据收集和数据解释。在评估测试中，各测试进行的先后次序没有关系，因为它们不是线性关系，而是多次重复进行的。当在测试中发现了新的信息时，以前所做的测试可能要重新进行以确定它的测试结果，或要对以前的测试稍作改变以检验网络运行的其他方面。此外，在评估期间设备提供商经常发布新的版本或非正式的版本，所以各种基于这种设备的测试都要重新进行。
        制定网络设备、技术比较或取舍标准时，不仅要参考评估测试所得的测试结果数据，还要综合考虑其他一些信息，如各设备的性能价格比，但由于没有运行网络的持续和峰值负载要求，所以缺少比较基准，往往将产品评估测试引入歧途。
        最后要根据评估测试所得的数据和图表对网络系统作出总结性评估，并撰写网络系统评估报告。
 
       信息系统项目
               项目的基本概念
               什么是项目？简单地说，安排一场演出、开发一种新产品、建一幢大房子都可以被称为一个项目。所谓项目，简单地说，就是在既定的资源和要求的约束下，为实现某种目的而相互联系的一次性工作任务。这个定义包括三层意思：一定的资源约束、一定的目标、一次性任务。这里的资源包括时间资源、经费资源、人力资源等。
               对项目的概念有了一定了解的基础上，我们来看一下项目的基本特征。
                      明确的目标
                      项目是一种有着明确目标——一种期望的产品或希望得到的服务的一次性活动。这里的目标包括几个方面。
                      （1）时间目标如在规定的时段内或规定的时间点之前完成。
                      （2）成果目标如提供某种规定的产品、服务或其他成果。
                      （3）其他需满足的要求包括必须满足的要求和应尽量满足的要求。
                      目标允许有一个变动的幅度，也就是可以修改的。不过一旦项目目标发生实质性变化，它就不再是原来的项目了，而将产生一个新的项目。
                      独特的性质
                      每一个项目都是唯一的、独特的。或者项目的成果与其他项目不同；或者项目的成果与其他项目类似，然而其时间和地点，内部和外部的环境，自然和社会条件有别于其他项目，总之项目总是独一无二的，没有两个项目是完全相同的。项目没有可以完全照搬的先例，也不会有完全相同的复制。
                      有限的生命周期
                      项目有具体的时间计划，它有一个开始时间和目标必须实现的截止日期。虽然不同项目可以划分为不同的具体阶段，不过，大多数项目的生命周期都可以划分为启动、规划、实施、结尾4个阶段。
                      特定的委托人
                      它既是项目结果的需求者，也是项目实施的资金提供者。他可能是一个人，或一个组织；委托人可能是企业外部的，被称作外部客户，也可能是企业内部的，比如企业内的别的部门，被称作内部客户。不管是外部客户还是内部客户，都是项目的委托人或项目成果的使用者。
                      实施的一次性
                      一次性是项目与其他常规运作的最大区别。项目有确定的起点和终点，项目不能重复。
                      组织的临时性和开放性
                      项目开始时要组建项目团队，项目团队在项目进展过程中，其人数、成员、职责在不断变化。某些成员是借调来的，项目终结时团队要解散，人员要转移。参与项目的组织往往有多个，甚至几十个或更多。他们通过协议或合同以及其他的社会关系结合到一起，在项目的不同时段以不同的程度介入项目活动。可以说，项目组织没有严格的边界，是有弹性的、模糊的、开放的。这一点与一般企事业单位和政府机构很不一样。
                      项目的不确定性和风险性
                      项目以所需的时间估计、成本估计、各种资源的有效性为项目计划的假定条件，这种假定带来了一定程度的不确定性，这种不确定性为项目的实现带来一定的风险。项目是一次性任务，做坏了没有机会重来。项目必须保证成功，因此必须精心设计、精心制作和精心控制，以达到预期目标。
                      结果的不可逆转性
                      不论结果如何，项目结束了，结果也就确定了。
               信息系统项目的概念
               通过上一节对项目的介绍，我们知道信息系统的建设也是一类项目。因为信息系统的建设符合项目的定义。我们知道，项目的定义中包含三层意思：一定的资源约束、一定的目标、一次性任务。首先，信息系统的建设是一次性的任务，有明确的任务范围和质量要求，有时间和进度的要求，有经费和资源的限制。因此，信息系统的建设是一类项目的建设过程。
               信息系统项目除了具有项目的特征之外，还具有自己的特点。
                      信息系统项目的目标不精确、任务边界模糊，质量要求主要由项目团队定义
                      在信息系统开发初期，项目团队调研时，客户只能提出一些初步的功能要求，提不出确切的需求。信息系统项目的任务范围在很大程度上取决于项目组所做的系统规划和需求分析。另外，因为大部分客户方都不是从事信息技术的人员，对信息技术的各种性能指标并不熟悉，所以，信息系统项目所应达到的质量要求也更多地由项目组定义，客户则尽可能地进行审查。为了更好地定义或审查信息系统项目的任务范围和质量要求，客户方可以聘请第三方的信息系统监理或咨询机构来监督项目的实施情况。
                      在信息系统项目开发过程中，客户的需求不断被激发，不断地被进一步明确，或者客户需求随项目进展而变化，从而导致项目进度、费用等计划的不断更改
                      尽管已经做好了系统规划、可行性研究，签订了较明确的技术合同，然而随着项目的进展，客户的需求不断地被激发，被进一步明确，导致程序、界面以及相关文档需要经常被修改。而且在修改过程中又可能产生新的问题，这些问题很可能经过相当长的时间后才会被发现。这就要求项目经理在项目开发过程中不断监控和调整项目计划的执行情况，尤其注重项目的变更管理。
                      信息系统项目是智力密集、劳动密集型项目，受人力资源影响最大，项目成员的结构、责任心、能力和稳定性对信息系统项目的质量以及是否成功有决定性的影响
                      信息系统项目工作的技术性很强，需要大量高强度的脑力劳动。尽管近年来信息系统辅助开发工具的应用越来越多，但是项目各阶段还是渗透了大量的手工劳动。这些劳动十分细致、复杂和容易出错，因而信息系统项目既是智力密集型项目，又是劳动密集型项目。并且，由于信息系统开发的核心成果——应用软件是不可见的逻辑实体，如果人员发生流动，对于没有深入掌握软件知识或缺乏信息系统开发实践经验的人来说，很难在短时间里做到无缝地承接信息系统的后续开发工作。
                      另外，信息系统的开发是项目团队整体的工作，为了高质量的完成项目，要充分发掘项目成员的才能和创新精神，不仅要求他们具有一定的技术水平和工作经验，还要求他们具有良好的心理素质和责任心，尤其要具有团队合作精神。项目经理在项目开发过程中，也应该注重项目成员之间的沟通协调，要将人力放到与进度和成本一样高的地位来看待。
 
       需求分析
        需求分析的方法种类繁多，不过如果按照分解的方式不同，可以很容易地划分出几种大类型：
        （1）结构化分析方法。本节后续内容将详细讨论SA的内容。
        （2）面向对象分析方法。将在10.3节中进行详细介绍。
        （3）面向问题域的分析（Problem Domain Oriented Analysis, PDOA）方法。PDOA更多地强调描述，而少强调建模。它的描述大致分为关注问题域和关注解系统的待求行为这两个方面。问题框架是PDOA的核心元素，是将问题域建模成为一系列相互关联的子域。也可以把问题框架看作是开发上下文图，但不同的是上下文图的建模对象是针对解系统，而问题框架则是针对问题域。也就是说，问题框架的目标就是大量地捕获更多有关问题域的信息。PDOA方法现在还在研究阶段，并未广泛应用。
               业务流程分析
               业务流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系和每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。
               业务流程分析的步骤如下：
               （1）通过调查掌握基本情况。
               （2）描述现有业务流程（绘制业务流程图）。
               （3）确认现有业务流程。
               （4）对业务流程进行分析。
               （5）发现问题，提出解决方案。
               （6）提出优化后的业务流程。
               在业务流程图中使用的基本符号如下图所示。
               数据流图
               DFD是结构化分析中的重要方法和工具，是表达系统内数据的流动并通过数据流描述系统功能的一种方法。DFD还可被认为是一个系统模型，在信息系统开发中，一般将它作为需求说明书的组成部分。
               
               业务流程图符号
               DFD从数据传递和加工的角度，利用图形符号通过逐层细分地描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能。具体来说，DFD的主要作用如下：
               （1）DFD是理解和表达用户需求的工具，是系统分析的手段。由于DFD简明易懂，理解它不需要任何计算机专业知识，因此通过它同客户交流很方便。
               （2）DFD概括地描述了系统的内部逻辑过程，是系统分析结果的表达工具，因而也是系统设计的重要参考资料，是系统设计的起点。
               （3）DFD作为一个存档的文字材料，是进一步修改和充实开发计划的依据。
               在DFD中，通常会出现4种基本符号，分别是数据流、加工、数据存储和外部实体（数据源及数据终点）。数据流是具有名字和流向的数据，在DFD中用标有名字的箭头表示。加工是对数据流的变换，一般用圆圈表示。数据存储是可访问的存储信息，一般用直线段表示。外部实体是位于被建模的系统之外的信息生产者或消费者，是不能由计算机处理的成分，它们分别表明数据处理过程的数据来源及数据去向，用标有名字的方框表示。下图是一个典型的DFD示例。
               
               办理取款手续的DFD
               为了表达数据处理过程中的数据加工情况，用一个DFD是不够的。稍微复杂的实际问题，在DFD中常常出现十几个甚至几十个加工。这样的DFD看起来很不清楚。层次结构的DFD能很好地解决这一问题。按照系统的层次结构进行逐步分解，并以分层的DFD反映这种结构关系，能清楚地表达整个系统。
               下图给出分层DFD的示例。数据处理S包括3个子系统1、2、3。顶层下面的第一层DFD为DFD/L1，第二层的DFD/L2.1、DFD/L2.2及DFD/L2.3分别是子系统1、2和3的细化。对任何一层数据流图来说，它的上层图称为父图，在它下一层的图则称为子图。
               
               分层数据流图
               概括地说，画DFD的基本步骤，就是“自顶向下，逐层分解”。检查和修改的原则如下：
               （1）DFD中的所有图形符号只限于前述4种基本图形元素。
               （2）顶层DFD必须包括前述4种基本元素，缺一不可。
               （3）顶层DFD中的数据流必须封闭在外部实体之间。
               （4）每个加工至少有一个输入数据流和一个输出数据流。
               （5）在DFD中，需按层给加工框编号。编号表明了该加工处在哪一层，以及上下层的父图与子图的对应关系。
               （6）规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡。
               （7）可以在DFD中加入物质流，帮助用户理解DFD。
               （8）图上每个元素都必须有名字。
               （9）DFD中不可夹带控制流。
               数据字典
               数据字典是关于数据的信息的集合，也就是对DFD中包含的所有元素的定义的集合。DFD和数据字典共同构成系统的逻辑模型。没有DFD，数据字典难以发挥作用；没有数据字典，DFD就不严格。只有把DFD和对DFD中每个元素的精确定义放在一起，才能共同构成系统的规格说明。
               数据字典的设计包括：数据流设计、数据元素字典设计、数据处理字典设计、数据结构字典设计和数据存储设计。这些设计涵盖了数据的采集和范围的确定等信息。在数据字典的每一个词条中应包含以下信息：名称、别名或编号、分类、描述、何处使用。
               对加工的描述是数据字典的组成内容之一，常用的加工描述方法有结构化语言、判定树及判定表。
               （1）结构化语言：介于自然语言和形式语言之间的一种半形式语言，在自然语言基础之上加了一些限度，使用有限的词汇和有限的语句来描述加工逻辑。结构化语言是受结构化程序设计思想启发而扩展出来的。结构化程序设计只允许3种基本结构。结构化语言也只允许3种基本语句，即简单的祈使语句、判断语句和循环语句。与程序设计语言的差别在于结构化语言没有严格的语法规定，与自然语言的不同在于它只有极其有限的词汇和语句。结构化语言使用3类词汇：祈使句中的动词、数据字典中定义的名词及某些逻辑表达式中的保留字。
               （2）判定树：若一个动作的执行不只依赖一个条件，而与多个条件有关，那么这项策略的表达就比较复杂。如果用结构化语言的判断语句，就有多重嵌套，层次一多，可读性就会下降。用判定树来表示，可以更直观一些。
               （3）判定表：一些条件较多、在每个条件下取值也较多的判定问题，可以用判定表表示。判定表能清晰地表达复杂的条件组合与应做动作之间的对应关系，判定表的优点是能够简洁、无二义性地描述所有的处理规则。但判定表表示的是静态逻辑，是在某种条件取值组合情况下可能的结果，它不能表达加工的顺序，也不能表达循环结构，因此判定表不能成为一种通用的设计工具。
 
       需求管理
        需求管理通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。根据考试大纲和培训指南的规定，本节要求考生掌握需求变更、需求跟踪和需求变更风险管理3个方面的知识。本节只简单介绍有关需求跟踪方面的知识。有关定义需求基线和需求变更的知识，请阅读12.7.3节；有关风险管理方面的知识，请阅读12.11节。
        需求跟踪的主要目的如下：
        （1）审核。跟踪能力信息可以帮助审核确保所有需求被应用。
        （2）在增加、删除、修改需求时可以确保不忽略每个受到影响的系统元素。
        （3）使得维护时能正确、完整地实施变更，从而提高生产率。
        （4）获得计划功能当前实现状态的记录。
        （5）再工程。可以列出旧系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。
        （6）重新利用跟踪信息可以帮助开发人员在新系统中对相同的功能利用旧系统相关资源。
        （7）可以减少由于关键成员离开项目带来的风险。
        （8）可以在测试出错时指出最可能有问题的代码段。
        在信息系统项目中，需求变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。
        需求跟踪包括编制每个需求与系统元素之间的联系文档。这些元素包括别的需求、约束、其他设计部件、源代码模块、测试、帮助文件、文档等。需求跟踪分为正向跟踪和逆向跟踪，一般合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。它跟踪的是已明确的需求的实现过程，不涉及需求开发人员的职责，也无法用于防止变更矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。
 
       预测
        随着项目进展，项目团队可根据项目绩效，对完工估算（EAC）进行预测，预测的结果可能与完工预算（BAC）存在差异。如果BAC已明显不再可行，则项目经理应考虑对EAC进行预测。预测EAC是根据当前掌握的绩效信息和其他知识，预计项目未来的情况和事件。预测要根据项目执行过程中所提供的工作绩效数据来产生、更新和重新发布。工作绩效信息包含项目过去的绩效，以及可能在未来对项目产生影响的任何信息。
        有关预测的相关计算会在15.4节中详细说明。
   题号导航      2015年下半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第3题    在手机中做本题