免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2016年上半年 信息系统项目管理师 下午试卷 案例
  第2题      
  知识点:   V模型   风险管理   开发模型   瀑布模型   项目章程   预算   质量管理

 
阅读下列说明,回答问题1至问题3,将解答填入答题纸的对应栏内。
[说明]
甲公司准备启动某软件项目,在项目可行性研究报告中提到项目可能会面临市场方面的风险,在进行项目可行性研究论证时专家提出应该把该市场风险细化,并提出相应的对策。于是公司在可研报告之外,以会议纪要的方式提出了应对该市场风险的方法,即如果4G技术能够在2015年年底前普及率达到70%及以上,则应该按照较快的进度安排尽快完成该项目,并争取在2016年5月让产品上市,并建议项目采用V模型开发,项目的预算为1000万元;如果届时4G普及率达不到预期的70%;则建议项目采用迭代开发模型,分阶段进行开发,只需要在2016年5月完成部分产品即可,项目到该时点的预算为450万元。并建议将项目的开始时间由原定于2015年8月推迟到2015年12月,以降低项目的可能风险。
李工被临时任命为该项目的项目经理,直接归公司负责营销的王总领导。王总让公司人力资源部门准备了项目章程,通知财务部、人力资源部和销售部的相关人员一起召开了项目启动会,并在会议上正式发布了项目章程和对项目经理的任命。项目章程中包括了项目团队成员、项目的历时、项目经理的权限、项目的预算等内容。其中的项目预算根据王总对市场的理解和判断,为1000万元。项目章程要求项目于2015年8月开始,于2016年5月完成产品研发。
李工在项目执行过程中,发现项目章程中没有任何对于项目风险和开发模型的说明与规定,所以李工就根据自身经验采用了瀑布模型来安排项目工作。当项目进展到2015年12月时,发现4G的普及率没有达70%,公司决定暂缓此项目。但是到此时为止,项目已经进展到了差不多一半,而且项目也不能够分阶段进行开发,否则将前功尽弃。当公司质量管理部门追究相关环节的错误时,李工觉得这样的风险不属于项目层面风险管理的内容,作为项目经理只要按照项目章程的规定执行项目就是尽责了。
 
问题:2.1   制定项目章程的输入项包括什么?并列举说明项目章程中应包含哪些内容?(12分)
 
问题:2.2   请指出制定项目管理计划的输入项包括哪些内容?本案例中一开始提到的会议纪要影响项目管理计划的制定吗?如影响,请指出是如何影响的;如不影响,请说明理由。(7分)
 
问题:2.3   项目经理李工认为“这样的风险不属于项目层面风险管理的内容,作为项目经理只要按照项目章程的规定执行项目就是尽责了”是否正确?为什么?项目风险管理计划中主要应包括哪些内容?(6分)
 
 
 

   知识点讲解    
   · V模型    · 风险管理    · 开发模型    · 瀑布模型    · 项目章程    · 预算    · 质量管理
 
       V模型
        V模型是最具有代表意义的测试模型,如下图所示。V模型最早是由Paul Rook在20世纪80年代后期提出的,V模型在英国国家计算中心文献中发布,旨在改进软件开发的效率和效果。
        在传统的开发模型中,比如瀑布模型,人们通常把测试过程作为在需求分析、概要设计、详细设计和编码全部完成之后的一个阶段,尽管有时测试工作会占用整个项目周期一半的时间,但是有人仍然认为测试只是一个收尾工作,而不是主要的过程。V模型的推出就是对此种认识的改进。V模型是软件开发瀑布模型的变种,它反映了测试活动与分析和设计的关系,从左到右,描述了基本的开发过程和测试行为,非常明确地标明了测试过程中存在的不同级别,并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系,如模型图(下图)中所示,图中的箭头代表了时间方向,左边下降的是开发过程各阶段,与此相对应的是右边上升的部分,即各测试过程的各个阶段。
        
        软件测试V模型
        V模型的软件测试策略既包括低层测试又包括了高层测试,低层测试是为了源代码的正确性,高层测试是为了使整个系统满足用户的需求。
        V模型指出,单元和集成测试是验证的程序设计,开发人员和测试组应检测程序的执行是否满足软件设计的要求;系统测试应当验证系统设计,检测系统功能、性能的质量特性是否达到系统设计的指标;由测试人员和用户进行软件的确认测试和验收测试,追溯软件需求说明书进行测试,以确定软件的实现是否满足用户需求或合同的要求。
        V模型存在一定的局限性,它仅仅把测试过程作为在需求分析、概要设计、详细设计及编码之后的一个阶段。容易使人理解为测试是软件开发的最后的一个阶段,主要是针对程序进行测试寻找错误,而需求分析阶段隐藏的问题一直到后期的验收测试才被发现。
 
       风险管理
        没有绝对安全的环境,每个环境都有一定程度的漏洞和风险。风险是指某种破坏或损失发生的可能性。潜在的风险有多种形式,并且不只同计算机有关。考虑信息安全时,必须重视的几种风险有:物理破坏;人为错误;设备故障;内、外部攻击;数据误用;数据丢失;程序错误,等等。在确定威胁的时候,不能只看到那些比较直接的容易分辨的外部威胁,来自内部的各种威胁也应该引起高度重视,很多时候来自内部的威胁由于具有极大的隐蔽性和透明性导致更加难以控制和防范。
        风险管理是指识别、评估、降低风险到可以接受的程度,并实施适当机制控制风险保持在此程度之内的过程。风险评估的目的是确定信息系统的安全保护等级以及信息系统在现有条件下的安全保障能力级别,进而确定信息系统的安全保护需求;风险管理则根据风险评估的结果从管理(包括策略与组织)、技术、运行三个层面采取相应的安全控制措施,提高信息系统的安全保障能力级别,使得信息系统的安全保障能力级别高于或者等于信息系统的安全保护等级。
               风险分析
               风险分析的方法与途径可以分为:定量分析和定性分析。定量分析是试图从数字上对安全风险进行分析评估的方法,通过定量分析可以对安全风险进行准确的分级,但实际上,定量分析所依靠的数据往往都是不可靠的,这就给分析带来了很大的困难。定性分析是被广泛采用的方法,通过列出各种威胁的清单,并对威胁的严重程度及资产的敏感程度进行分级。定性分析技术包括判断、直觉和经验,但可能由于直觉、经验的偏差而造成分析结果不准确。风险分析小组、管理者、风险分析工具、企业文化等决定了在进行风险分析时采用哪种方式或是两者的结合。风险分析的成功执行需要高级管理部门的支持和指导。管理部门需要确定风险分析的目的和范围,指定小组进行评估,并给予时间、资金的支持。风险小组应该由不同部门的人员组成,可以是管理者、程序开发人员、审计人员、系统集成人员、操作人员等。
               风险评估
               进行风险评估时需要决定要保护的资产及要保护的程度,对于每一个明确要保护的资产,都应该考虑到可能面临的威胁以及威胁可能造成的影响,同时对已存在的或已规划的安全管制措施进行鉴定。仅仅确定资产是不够的,对有形资产(设备、应用软件等)及人(有形资产的用户或操作者、管理者)进行分类也是非常重要的,同时要在两者之间建立起对应关系。有形资产可以通过资产的价值进行分类,如:机密级、内部访问级、共享级、未保密级。对于人员的分类类似于有形资产的分类。信息安全风险评估的复杂程度将取决于风险的复杂程度和受保护资产的敏感程度,所采用的评估措施应该与组织对信息资产风险的保护需求相一致。
               控制风险
               对风险进行了识别和评估后,可通过降低风险(例如安装防护措施)、避免风险、转嫁风险(例如买保险)、接受风险(基于投入/产出比考虑)等多种风险管理方式得到的结果来协助管理部门根据自身特点来制定安全策略。制定安全策略时,首先要识别当前的安全机制并评估它们的有效性。由于所面临的威胁不仅仅是病毒和攻击,对于每一种威胁类型要分别对待。在采取防护措施的时候要考虑如下一些方面:产品费用、设计/计划费用、实施费用、环境的改变、与其他防护措施的兼容性、维护需求、测试需求、修复、替换、更新费用、操作/支持费用。
 
       开发模型
        电子商务应用系统开发模型是描述系统开发过程中各种活动如何执行的模型。系统生命周期模型确立了开发和演绎中各阶段的次序限制以及各阶段或机动的准则,确立开发过程所遵守的规定和限制,便于各种活动的协调,便于各种人员的有效通信,有利于活动重用,有利于活动管理。常见的生命周期模型有如下5个模型。
               瀑布模型(Waterfall Model)
               瀑布模型是将软件生命周期各个活动规定为依线性顺序连接的若干阶段的模型。它包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后、相互衔接的固定次序,如同瀑布流水,逐级下落。
               瀑布模型为软件的开发和维护提供了一种有效的管理模式,根据这一模式制定开发计划,进行成本预算,组织开发力量,以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导,所以它是以文档作为驱动、适合于软件需求很明确的软件项目的模型。
               但是,瀑布模型在大量的软件开发实践中也逐渐暴露出它的严重缺点。它是一种理想的线性开发模式,缺乏灵活性,特别是无法解决软件需求不明确或不准确的问题。
               快速原型模型(Rapid Prototype Model)
               快速原型模型的第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么。
               第二步则在第一步的基础上开发客户满意的软件产品。显然,快速原型方法可以克服瀑布模型的缺点,减少由于软件需求不明确带来的开发风险,具有显著的效果。
               快速原型的关键在于尽可能快速地建造出软件原型,一旦确定了客户的真正需求,所建造的原型将被丢弃。因此,原型系统的内部结构并不重要,重要的是必须迅速建立原型,随之迅速修改原型,以反映客户的需求。
               增量模型(Incremental Model)
               增量模型又称演化模型。大量的软件开发实践表明,许多开发项目在开始时对软件需求的认识是模糊的,因此很难一次开发成功。为了减少因对软件需求的了解不够确切而给开发工作带来的风险,可以在获取了一组基本的需求后,通过快速分析构造出该软件的一个初始可运行版本,这个初始的软件通常称为原型,然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进,获得原型的新版本。在使用增量模型时,第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后,经过评价形成下一个增量的开发计划,它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复,直到产生最终的完善产品。增量模型特别适用于对软件需求缺乏准确认识的情况。
               螺旋模型(Spiral Model)
               对于复杂的大型软件,开发一个原型往往达不到要求。螺旋模型将瀑布模型和增量模型结合起来,加入了两种模型均忽略的风险分析,弥补了这两种模型的不足。
               螺旋模型将开发过程分为几个螺旋周期,每个螺旋周期大致和瀑布模型相符合。在每个螺旋周期分为如下四个工作步骤。
               ①制订计划。确定软件的目标,选定实施方案,明确项目开发的限制条件。
               ②风险分析。分析所选的方案,识别风险,消除风险。
               ③实施工程。实施软件开发,验证阶段性产品。
               ④用户评估。评价开发工作,提出修正建议,建立下一个周期的开发计划。
               喷泉模型(Water Fountain Model)
               喷泉模型是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性。迭代意味着模型中的开发活动常常需要重复多次,在迭代过程中不断地完善软件系统。无间隙是指在开发活动(如分析、设计、编码)之间不存在明显的边界,也就是说,它不像瀑布模型那样,需求分析活动结束后才开始设计活动,设计活动结束后才开始编码活动,而是允许各开发活动交叉、迭代地进行。
 
       瀑布模型
        瀑布模型也称为生命周期法,是结构化方法中最常用的开发模型,它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段,规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。采用瀑布模型的软件过程如下图所示。
        
        软件生存周期的瀑布模型
        (1)软件计划(问题的定义及规划):主要确定软件的开发目标及其可行性。
        (2)需求分析:在确定软件开发可行的情况下,对软件需要实现的各个功能进行详细分析。需求分析阶段是一个很重要的阶段,这一阶段做得好,将为整个软件开发项目的成功打下良好的基础。
        (3)软件设计:主要是指根据需求分析的结果,对整个软件系统进行设计,如系统框架设计和数据库设计等。软件设计一般分为总体设计(概要设计)和详细设计。
        (4)程序编码:将软件设计的结果转换成计算机可运行的程序代码。在程序编写中必须要制定统一的、符合标准的编写规范,以保证程序的可读性和易维护性,提高程序的运行效率。
        (5)软件测试:在软件设计完成后要经过严密的测试,以发现软件在整个设计过程中存在的问题并加以纠正。在测试过程中需要建立详细的测试计划并严格按照测试计划进行测试,以减少测试的随意性。
        (6)软件维护:软件维护是软件生命周期中持续时间最长的阶段。在软件开发完成并投入使用后,由于多方面的原因,软件可能会不能继续适应用户的要求,这时如果要延续软件的使用寿命,就必须对软件进行维护。
        瀑布模型是最早出现的软件开发模型,在软件工程中占有重要的地位,它提供了软件开发的基本框架。瀑布模型的本质是“一次通过”,即每个活动只做一次,最后得到软件产品,也称做“线性顺序模型”或者“传统生命周期”,其过程是从上一项活动接收该项活动的工作对象并作为输入,利用这一输入实施该项活动应完成的内容,给出该项活动的工作成果,然后作为输出传给下一项活动。同时对该项活动实施的工作进行评审,若其工作得到确认,则继续下一项活动,否则返回前项,甚至更前项的活动进行返工。
        瀑布模型有利于大型软件开发过程中人员的组织与管理,有利于软件开发方法和工具的研究与使用,从而提高了大型软件项目开发的质量和效率。然而软件开发的实践表明,上述各项活动之间并非完全是自上而下的,而是呈线性图式,因此,瀑布模型存在严重的缺陷。
        (1)由于开发模型呈线性,所以当开发成果尚未经过测试时,用户无法看到软件的效果。这样,软件与用户见面的时间间隔较长,也增加了一定的风险。
        (2)在软件开发前期未发现的错误传到后面的开发活动中时,可能会扩散,进而可能会导致整个软件项目开发失败。
        (3)在软件需求分析阶段,完全确定用户的所有需求是比较困难的,甚至可以说是不太可能的。
        :瀑布模型适用于需求明确或很少变更的项目。
 
       项目章程
        项目章程是由项目启动者或发起人发布的,正式批准项目成立,并授权项目经理动用组织资源开展项目活动的文件。在项目章程中记录业务需要、假设条件、制约因素、对客户需要和高层级需求的理解,以及需要交付的新产品、服务或成果。
        项目章程的主要内容包括:
        .项目目的或批准项目的原因。
        .可测量的项目目标和相关的成功标准。
        .高层级需求。
        .假设条件和制约因素。
        .高层级项目描述和边界定义。
        .高层级风险。
        .总体里程碑进度计划。
        .总体预算。
        .干系人清单。
        .项目审批要求。
        .委派的项目经理及其权责。
        .发起人或其他批准项目章程的人员的姓名和职权。
 
       预算
        预算是指组织按照一定的业务量水平及质量水平,估计各项成本、计算预算成本,并以预算成本为控制经济活动的依据,衡量其合理性。当实际状态和预算有了较大差异时,要查明原因并采取措施加以控制。编制预算是以预算项目的成本预测及IT服务工作量的预测为基础的。
        预算的编制方法主要有增量预算和零基预算,其选择依赖于企业的财务政策。增量预算是以去年的数据为基础,考虑本年度成本、价格等的期望变动,调整去年的预算。在零基预算下,组织实际所发生的每一活动的预算最初都被设定为零。为了在预算过程中获得支持,对每一活动必须就其持续的有用性给出有说服力的理由。即详尽分析每一项支出的必要性及其取得的效果,确定预算标准。零基预算方法迫使管理当局在分配资源前认真考虑组织经营的每一个阶段。这种方法通常比较费时,所以一般几年用一次。
        .预算项目的成本预测。预算项目一般按照成本项目划分,一旦确定一般要保持稳定,这样一是可以使企业了解其成本变动趋势,进行纵向比较,也可以与其他企业之间进行横向比较,二是为成本管理活动提供了一个简单的处理基础,如折旧可以按照成本类型的不同分别进行处理。
        在预算编制时,各预算项目的成本一般都是未知的,如加班工资、外部网收费等,因此必须对其进行预测。预测这些成本是以从前IT会计年度的成本数据为基础或以未来工作量的预测为基础进行的。IT成本管理必须谨慎地估计不可控制的成本的变化。
        .IT服务工作量预测。IT工作量是成本变化的一个主要原因之一,因此,在编制预算的时候,要预测未来IT工作量。不仅成本管理活动需要估计工作量,在服务级别管理和容量管理中也需要对工作量进行预测。工作量预测将以工作量的历史数据为基础,考虑数据的更新与计划的修改,得出未来的IT工作量。
 
       质量管理
        ISO将质量定义为:“质量是反映实体满足明确和隐含需要的能力的特性总和”。我国国家标准GB/T1900—2000将质量定义为:“质量是一组固有特性满足要求的程度”。这些定义表明质量是通过实体来体现的,质量的实体可以是产品,也可以是某项活动或过程的工作质量,还可以是质量管理体系运行的质量。
        ISO将质量管理定义为:“在质量方面指挥和控制组织的协调活动”。我国国家标准GB/T1900-2000对质量管理的定义是:“在质量方面指挥和控制组织的协调的活动”。在质量方面的指挥和控制活动,通常包括制定质量方针和质量目标以及质量策划、质量控制、质量保证和质量改进。
        我国国家标准GB/T1900—2000对质量保证的定义是:“质量保证是质量管理的一部分,致力于增强满足质量要求的能力”。也就是,质量保证是为了提供足够的信任表明实体能够满足质量要求,而在质量体系中实施并根据需要进行全部有计划和有系统的活动。
        我国国家标准GB/T 1900—2000对质量控制的定义是:“质量管理的一部分,致力于满足质量要求”。质量控制的目标就是确保产品的质量能满足顾客、法律法规等方面所提出的质量要求,如适用性、可靠性和安全性。质量控制的范围涉及产品质量形成全过程的各个环节,如设计过程、采购过程、生产过程和安装过程。
        项目质量管理是为了保证项目最终能够达到预期的质量目标而进行的一系列的管理过程。项目的质量管理可以分解为质量计划编制、质量保证与质量控制三个过程。
        (1)质量计划编制。是指确定与项目相关的质量标准,并决定如何达到这些质量标准。
        (2)质量保证。是定期评估总体项目绩效的活动之一,以树立项目能满足相关质量标准的信心。
        (3)质量控制。是指监控具体的项目结果以判断其是否符合相关的质量标准,并确定方法来消除绩效低下的原因。
        质量管理与项目管理是相辅相成的,例如质量管理和项目管理这两门学科都认识到以下几方面的重要性:
        (1)顾客的满意程度。强调对顾客的需求深刻理解、认真评估、准确定义和严格管理,以便与顾客的期望相符。这就要求既符合要求(项目交付的产品要与它宣布将交付的产品相符)又适于使用(交付的产品或服务要满足实际需求)。
        (2)预防胜于检查。强调预防比检查更重要。防患于未然的代价总是小于检查所发现错误的纠正代价。
        (3)管理层的责任。成功需要项目团队全体成员的参与,然而提供取得成功所需的资源却仍然是管理层的职责。
        (4)持续改进。计划、执行、检查和改进循环是质量改进的基础。执行组织采取的质量改进措施,不仅会改善项目管理的质量,而且也会改进项目产品的质量。
   题号导航      2016年上半年 信息系统项目管理师 下午试卷 案例   本试卷我的完整做题情况  
1 /
2 /
3 /
 
第2题    在手机中做本题