• 尚大品牌
    • 尚大网校|在线考试|证书查询|成绩查询
    登录   |   注册
     
     
        准考证打印   论文投票   报考指南   论文辅导   软考培训   郑重申明  
    您现在的位置：  首页 > 软考学苑 > 系统集成项目管理工程师 > 中项下午案例分析 > 范围 >> 正文
    正文
    项目范围管理案例之范围定义案例
    来源： 作者： 时间;2017-10-17 16:51:21 点击数： 尚大软考交流群：376154208
    阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题1至问题3。案例场景 尚大科技有限公司，接到的第一个项目是开发一套工商审批系统。由于电子政务保密要
    <尚大教育，教育至上，人才为大：sdedu.cc>

     阅读以下关于信息系统项目管理过程中范围管理方面问题的叙述，回答问题1至问题3。

    案例场景

       尚大科技有限公司，接到的第一个项目是开发一套工商审批系统。由于电子政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网可以对公众开放，开放的信息必须得到授权。系统要求在这两个子网中的合法用户都可以访问到被授权的信息，访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。
        张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采用了严格瀑布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换。由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70％的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写的部分代码才通过验收。由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100％。
        【问题1】(10分)
        请不超过300字，对张工的行为进行点评？
        【问题2】(9分)
        请从项目范围管理的角度找出该项目实施过程中的主要管理问题？不超过200字回答。
        【问题3】(6分)
        请结合你本人实际项目经验，指出应如何避免类似问题？不超过200字回答。

    2.1.2案例分析

        这是一个失败的项目，张工在项目管理中既有闪光点，也有失败的地方。但项目管理中的任何差错都会影响项目的结果，而范围管理的失误对项目的影响更为明显。模糊的项目范围定义、错误的工作分解、缺失的范围确认和无力的范围控制都将严重影响项目的结果。
        张工对项目范围有一定的把握。在范围定义中，张工发现了不同行业间具有不同的特点，电子政务行业对系统运行环境有着特殊的要求。根据国家对电子政务的要求，政务内网与政务外网是该行业一致的标准，这与企业信息化是完全不同的。张工捕获到该需求，并对这个需求进行了清晰的定义，根据瀑布模型的要求，对设计和实现都进行了严格的控制，因此在系统交付时完全满足了用户对保密性的要求。在这一点上，张工是成功的。如果在范围定义时忽略了行业标准，项目肯定会招致更大的失败。
        但用户界面的风格和操作的便捷性也属于系统范围的一部分。与系统运行环境一样，我们通常称这类需求为隐性需求。这类需求往往不是由用户直接提出，而且受行业特点决定的范围所约束。对于电子政务来说，系统保持一致的风格非常重要。作为政府对公众开放的窗口而言，并不需要很强的个性化，但一致的界面风格可以体现出政务的严肃性。考虑到全体民众层次差异较大，大多数访问系统的用户一般都没有接受过系统使用的培训，操作的便捷性也是政务系统必须实现的功能之一。很明显，对于这些系统的隐性需求张工没有充分考虑，从而导致一而再，再而三的变更。
        对于软件项目，所有的需求都必须经过清晰的定义，这些需求都是项目范围的一部分。张工仅仅注意了其中的一部分，而忽略了用户界面，最终导致项目的失败。
        对于电子政务信息系统，尤其是面向公众开放的信息系统，范围定义更加困难。这些系统的最终用户几乎不会参加需求开发的工作，他们的需求都是间接的，通过政府部门的负责人传递到项目组。但最终用户的意见对项目的结果会有巨大的影响，这是就对范围管理提出了更高的要求。
        除了在范围定义方面的问题外，张工在范围确认和范围控制方面也存在不小的失误。当系统第一次更改时，就应该意识到系统界面风格和操作便捷性的重要性。这时应该清晰地定义系统的界面风格和操作风格，并设法进行确认。如果采取了恰当的措施，第二次的变更是完全可以避免的。
        在刚刚进入一个陌生领域的时候，其中充满了各种各样的风险。隐性的行规和行业特点都是项目范围的风险。面对这些风险，即使再细致的调研也无法完全避免，也不能完整定义系统的范围。因此可以考虑采取原型法等方式来提前暴露风险，减少风险带来的损失。因此在案例中，张工也没有进行充分的风险管理，采用严格的瀑布模型增加了风险发生后带来的损失。
        对于这个案例，缺乏良好的设计也是很明显的缺陷。用户界面中耦合了大量的业务逻辑，这必然增加变更的代价，从而导致大部分代码重写。若在项目初期意识到界面变更的风险，随之采用良好的设计，将表现层和业务逻辑彻底分开，系统变更的代价也会小得多。
        综上所述，项目经理张工在整个案例中，针对范围管理做了一些工作，但不全面，在风险管理和质量管理上也都存在缺陷。
        有了上面的分析，这道题就很容易作答。项目的闪光点在于对系统运行环境进行了清晰的定义，并最终满足了用户的要求；但不充分的范围定义和范围  确认招致了项目的失败，而采用了抗风险能力较弱的瀑布模型和低质量的设计又雪上加霜，最终导致项目延期100%.
        因此第一题答案的要点就很明确了：
        (1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。
        (2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付的重大变更。
        (3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。
        (4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。
        (5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。
        对于第二题，是在第一题的基础上考察对范围管理的理解，因此可以忽略在其他领域的问题。在范围管理中主要包括如下内容：
        (1)范围管理计划。
        (2)范围定义。
        (3)工作分解。
        (4)范围确认。
        (5)范围控制。
        在本案例中，没有专门设计到范围管理计划和工作分解的内容。从表面上看，范围定义存在明显的缺陷。但案例中提到系统又发生了第二次变更，由此可见，张工在范围确认和范围控制上也存在不足。若在问题第一次出现时就进行有效的范围确认和范围控制，则完全可以避免第二次的变更。因此，第二题的答案要点如下：
        (1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。
        (2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。
        (3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。
        在完成第二题后，第三题就是水到渠成了，第三题的要点见参考答案，此处不再赘述。
        项目管理是一个系统工程，没有哪种单一的手段可以有效地改善项目，反之管理中的任何疏忽都可能招致严重的后果，造成项目的失败。而软件项目的复杂性又决定了项目中的工作环环相扣，问题也总是相互关联的。在发现问题后，也需要采取多种手段才能彻底解决问题。这对信息系统的项目经理来说是重大的挑战。

    2.1.3参考答案

        【问题1】(10分)
        (1)张工注意到了系统运行环境的特殊性，在良好设计和实现的情况下满足了用户的要求。(2分)
        (2)张工忽略了系统用户的潜在要求，在用户界面和操作的风格上范围定义不清晰，造成系统交付时的重大变更。(2分)
        (3)张工在第一次问题发生后仍没有对范围进行有效的管理，造成了系统第二次的变更。(2分)
        (4)张工没有对用户界面是否能够满足要求的风险进行有效的管理，而是采用了对风险适应性较差的瀑布模型组织开发。(2分)
        (5)张工没有对设计质量进行有效的控制，造成表现层中耦合了业务逻辑，增加了修改的代价。(2分)
        【问题2】(9分)
        (1)张工没有挖掘到系统的全部隐性需求，缺乏精确的范围定义。(3分)
        (2)在发生第一次变更时，张工仍没有有效的范围管理，从而造成系统的二次变更。(3分)
        (3)重复的系统变更说明张工对系统范围控制不足，导致一而再再而三的反复。(3分)
        【问题3】(6分)
        有效的范围管理包括了从范围定义到范围控制等多方面的工作，每一项工作都是重要的。对于本案例，要结合行业特点进行需求分析，挖掘系统潜在的需求，同时通过原型等方法来辅助需求的定义，避免范围定义不清晰的问题。
        在发生需求变更时需要进行有效的需求控制，尽量在满足用户需求的前提下缩小需求范围，坚决避免需求的再次变更。
    <尚大教育，教育至上，人才为大：sdedu.cc>
     
       各省软考办 
     
    来顶一下
    返回首页
    返回首页
    上一篇：信息系统范围管理案例--W和M签订了一份新的合同，合同的主要内容是处理
    下一篇：项目范围管理案例之工作要点案例
     相关文章
     
     
    跟贴共条
    查看完整评论
    笔 名 ：   验证码：
    网友评论仅供其表达个人看法，并不表明尚大教育同意其观点或证实其描述
    距离2023年05月27-28日软考考试还有 天
    尚大软考交流群：376154208
    软考各地考务机构
    更多>>
    全国 北京 天津 河北 山西
    内蒙古 辽宁 吉林 黑龙江 上海
    江苏 浙江 安徽 福建 江西
    山东 河南 湖北 湖南 广东
    广西 海南 重庆 四川 贵州
    云南 西藏 陕西 甘肃 青海
    宁夏 新疆 香港 澳门 宁波
    大连 兵团 报名入口 联系方式
    历年真题汇总
    更多>>




    各省市软考报名简章
    软考动态
    更多>>
    PMI, PMP, Project Management Professional, PgMP, PfMP, PMI-ACP, PMI-PBA, PMBOK and the PMI Registered Education Provider logo are registered marks of the Project Management Institute, Inc.   京ICP备12019404号  Copyright© 2008-2021 北京翰林尚大教育科技有限公司