系统集成项目策划管理工程师历年真题案例分析

TOC\o"1-2"\h\z\u案例分析方法 I《系统集成项目治理工程师教程》知识体系 2第2章信息系统服务治理 3案例一（IT服务，2011上试题五） 3第4章项目治理一般知识 4案例一（项目的组织结构、治理流程、进度打算） 4案例二（项目的组织结构、项目经理与职能经理的工作） 5案例三（项目生命周期模型2009上试题五） 6第5章立项治理 9案例一（项目可行性分析2011下试题一） 9第6章项目整体（综合）治理 10项目整体治理流程图 10案例一（项目治理中存在的问题及改进措施） 10案例二（项目整体2009上试题四） 11案例三（项目整体2010上试题四） 13第7章项目范围治理 15项目范围治理流程图（5过程） 15案例一（范围治理教程p51823.2.1） 15案例二（需求评审教程p51423.1.5） 16案例三（范围治理2009下试题二） 19案例四（涉及范围治理、进度治理和变更治理2010下试题一） 20案例五（范围治理2010下试题四） 21案例六（范围治理2011上试题一） 22第8章项目进度治理 25项目进度治理流程图（6过程） 25案例一（项目进度，重点资源配置对进度的制约） 25案例二（项目的工期估算、进度压缩、进度跟踪） 27案例三（进度打算包括的种类和用途2009年上试题一） 28案例四（如何制定项目进度打算2009年上试题二） 29案例五（项目进度操纵的技术和工具2009年下试题三） 30案例六（项目进度历时2011年下试题二） 32第9章项目成本治理 33项目成本治理流程图（3过程） 33重要参数 33案例一（成本操纵的要紧工作内容、挣值计算2009下试题四） 34案例二（现金流、动态回收期、净现值分析教程p51223.1.2） 35案例三（挣值分析2010上试题二） 36案例四（挣值分析2010下试题二） 37案例五（挣值分析2011上试题二） 38案例六（挣值分析、预测分析教程p51323.1.4） 39第10章项目质量治理 41项目质量治理流程图（3过程） 41案例一（质量治理打算、质量操纵） 41案例二（质量操纵方法或工具2009年上试题三） 43案例三（质量操纵过程、制定项目质量打算的方法或工具2009下试题五） 44案例四（质量治理、质量操纵工具和技术2010上试题三） 45案例五（质量治理流程、术语2011上试题三） 47案例六（QA、质量操纵工具和技术2011下试题三） 48第11章项目人力资源治理 49项目人力资源治理流程图（4过程） 49案例一（项目团队治理） 49案例二（激励理论） 50案例三（冲突治理） 52案例四（人力资源负荷优化教程p51023.1.1） 52第12章项目沟通治理 55项目沟通治理流程图（4过程） 55案例一（沟通治理打算） 55案例二（有效沟通措施－项目例会） 56案例三（项目干系人（客户关系）教程p52023.2.4） 58第13章项目合同治理 60合同治理的要紧内容 60案例一（合同治理） 60案例二（合同索赔流程2009下试题一） 61案例三（合同治理、变更治理、范围治理2010上试题一） 62案例四（合同治理2011下试题四） 63第15章信息文档和配置治理 65配置治理流程 65配置治理打算的要紧内容 65案例一（配置治理的要紧工作） 65案例二（配置治理、项目治理2010上试题五） 67案例三（配置治理2010下试题五） 68案例四（配置治理中完整的变更处置流程） 69第16章变更治理 71变更治理工作程序 71案例一（变更操纵教程p51723.1.8） 71案例二（2011年下试题五） 71第18章风险治理 73项目风险治理流程图（6过程） 73案例一（风险识不和操纵教程p51523.1.6） 73案例二（整体治理、风险识不和操纵2010年下试题三） 74第19章项目收尾治理 76案例一（2011年上试题四） 76案例分析方法一般地，具体的案例内容：陈述背景（其中蕴含了问题的线索）：在那个过程中出现某种项目治理的现象，让考生分析现象的缘故与解决的方法通用做题方法：流程图：通过流程图能够查出问题的缘故出在流程的哪个环节上，从而以流程为线索把产生问题的所有环节上的缘故都找出来。（因此每一章的过程流程图专门有参考价值）因果图：形象地展示了可能导致问题的多种可能缘故。【注】各个时期的工作流程与工作内容是必看的

《系统集成项目治理工程师教程》知识体系基础知识信息化基础（第1章）信息系统服务治理（第2章）信息系统集成专业技术知识（第3章）项目治理一般知识（第4章）核心知识域整体治理（第6章）范围治理（第7章）进度治理（第8章）成本治理（第9章）质量治理（第10章）信息安全治理（第17章）保障域人力资源治理（第11章）合同治理（第13章）采购治理（第14章）信息（文档）安全治理（第15章）风险治理（第18章）知识产权治理（第20章）法律法规标准规范（第21章）职业道德规范（第22章）伴随域沟通治理（第12章）变更治理（第16章）过程域：科研与立项、启动、打算、执行、监控、收尾项目立项治理（第5章）项目收尾治理（第19章）一般讲来，要把一个项目治理好，至少需要4种过程：技术类工作技术过程要解决“研制特定产品，完成特定成果或提交特定服务的具体技术过程”，要回答如何在技术上完成？如：信息系统项目的技术过程有需求分析、总体设计、编码、测试、维护、布线、组网等。治理类工作按出现得时刻先后划分，治理过程能够被分为启动、打算、执行、监控和收尾过程。支持类工作配置治理改进类工作总结经验教训、部署改进等过程。

第2章信息系统服务治理案例一（IT服务，2011上试题五）【讲明】某系统集成企业最近与某法院信息中心签订了一个法院综合信息系统运维项目合同，并签订了服务级不协议，对服务内容和具体要求进行了约定。协议中要求运维项目从解决问题过程到操纵问题过程及公布过程要与法院服务治理流程专门好的衔接，并建立服务台。而法院信息中心对系统的运维治理特不重视，于2010年10月通过ISO20000的认证。该系统集成企业的小张被任命为该运维项目的项目经理。小张如何运用学到的项目治理和IT服务治理方面的知识做好流程梳理和队伍建设对治理好该项目至关重要。【问题1】（5分）结合本案例，推断下列选项的正误（填写在答题纸的对应栏内，正确的选项填写“√”，错误的选项填写“×”）（1）GB/T24405.1-2009与ISO20000.1-2005内容是一致的。（）（2）该运维合同与服务级不协议没有关系。（）（3）服务级不协议中的服务响应时刻是决定服务收费的要紧依据之一。（）（4）运维服务中配置治理完全是系统集成企业的责任。（）（5）服务台确实是热线电话。（）【问题2】（3分）按照IT服务治理规范，请指出操纵过程和公布过程包含哪些内容。【问题3】（3分）小张在流程梳理的前期调研时，发觉某职员不能发送邮件。该问题处置过程往往要通过：问题提出→服务台记录问题→工程师调查问题→解决问题→假如该现象经常出现要调查缘故→批准和更新设施或软件。按照IT服务治理规范，请选择恰当选项按照顺序填入空白处，构成IT服务治理流程。（1）服务台（2）______（3）______（4）变更治理（5）______备选项：A.事件治理B.能力治理C.问题治理D.服务报告E.公布治理【问题4】（4分）请简述IT服务治理的业务价值。答：【问题1】（1）√（2）×（3）√（4）×（5）×【问题2】（1）操纵过程组：包括配置治理、变更治理。（2）公布过程组：包括公布治理。【问题3】（2）A（3）C（4）E【问题4】确保IT流程支撑业务流程，整体上提高了业务运营的质量；通过事故治理流程、变更治理流程和服务台等提供了更可靠的业务支持；客户对IT有更合理的期望，并更加清晰为达到这些期望他们所需要的付出；提高了客户和业务人员的生产率；提供更加及时有效的业务持续性服务；客户和IT服务提供者之间建立更加融洽的工作关系；提高了客户中意度。第4章项目治理一般知识案例一（项目的组织结构、治理流程、进度打算）阅读下面叙述，回答问题1至问题3，将解答填入答题纸的对应栏内。【讲明】某系统集成商B最近正在争取某钢铁公司A的办公网络迁移到外地的项目。李某是系统集成商B负责捕捉项目机会的销售经理，鲍某是系统集成商B负责实施的项目经理。由于以往项目销售经理的过度承诺给后继的实施工作带来了专门大困难，此次鲍某主动为该项目做售前支持。该办公网络迁移项目的工作包括钢铁公司A新办公楼的综合布线、局域网络系统升级、机房建设、远程视频会议系统、生产现场的闭路监控系统等5个子系统。钢铁公司A对该项目的招标工作在2006年8月4日开始。该项目要求在2006年12月29日完成，否则将严峻阻碍钢铁公司A的业务。时刻已到2006年8月8日，钢铁公司A希望系统集成商B能在【问题1】（7分）在制订进度打算时，鲍某可能会采取哪些措施使制订的进度打算满足客户的要求？【问题2】（5分）实施项目的系统集成商B目前的组织类型是什么？如何改进其项目的组织方式？如何改进其项目治理的流程？如何降低治理外地项目的成本？【问题3】（3分）在项目实施过程中，负责售前工作的李某应接着承担哪些工作？答题思路：【问题1】沟通，强调该项目对系统集成商B的重要意义，提高项目优先级。使用开会方式争取相关部门的建议、支持和承诺。从现有资源和实际情况动身，优化网络图，如重新安排活动之间的顺序，压缩关键路径长度。增加资源，引入经验丰富的职员并行，在现有资源下，子任务并行，内部流程优化。赶工，项目职员通过加班来加快项目进度尽可能地调配非关键路径上的资源用于关键路径上的任务优化外包，采购等环境并全程监控【问题2】系统集成商B的组织方式是职能式的。（补充：组织方式有4种—职能型、项目型、矩阵型、复合型）系统集成商B的组织方式应该改为矩阵型。最好的方法是项目下时期的人员提早介入到前一时期，如在项目的售前时期，负责项目实施的项目经理正式参与售前工作。另外，做好项目实施流程间的交接工作，如建立一套完整的项目售前和项目实施时期之间的交接规范和要求－包括文档、培训、合同等内容。托付、分包给当地有资质的集成商，或在当地招人。假如材料和服务在当地采购可降低成本。压低人员差旅费，事宜虚拟远程的沟通和售后服务手段。【问题3】与客户高层沟通，了解客户对项目实施情况的反映，维护客户关系，发掘新的项目机会。参加周例会，或至少每周首一次周报以了解项目的进展和问题。案例二（项目的组织结构、项目经理与职能经理的工作）《系统集成项目治理工程师》教程第23章-案例分析23.1.7案例场景某软件公司以产品开发和项目为其要紧业务。公司目前进展势头良好，正在建设的项目有5个左右，差不多立项的有10个左右，还有若干项目正处于验收和后期维护时期。公司实行的是强矩阵式治理模式，专职的项目经理往往一个人带多个项目，职能部门的内部也有担任项目经理工作的人员。然而，资源的调配成了项目经理、职能部门经理在项目实施过程中最棘手的问题。项目经理每个人都身兼数职，对项目进度难以操纵，而多数项目在进行时，资源的调配是由各个职能部门经理安排的，职能部门经理对质量进行监督，项目经理要做进度操纵，但是却没有分配资源的权力，从而引发出关于公司内部治理流程和职责定位的问题。【问题】在强矩阵式治理模式下，项目经理与职能部门经理对公司资源的调用如何协调？答题思路：1、强矩阵型组织结构的特点是：它具有专门多项目型组织的特征，具有拥有专门大职权的专职项目经理和专职项目行政治理人员。在强矩阵组织中，为协调项目经理和职能部门经理的权责，应：2.1在公司治理思想和原则上，明确矩阵型组织的特征：★能够以项目为导向★有了客户问题处理中心★协调工作由项目治理队伍承担★能够明确责任★资源来自各职能部门，同时这些资源可在不同项目中共享★专业人员在技术上可相互支持★各专业职员组织上仍归属其职能部门，因此项目结束后，职员“有家可归”2.2在公司制度上，明确职能部门和项目经理之间的权责分配关系：－－资源、人员日常归职能部门经理治理和考核；－－在项目实施期间，人员、资源由项目经理全权治理和考核；2.3建立一个清晰的项目治理流程，明确项目经理在项目实施期间的权力和责任；定义了相关人员和相关部门在项目活动中的工作范围、工作过程和职责。那个流程一般由项目治理部门起草，通过相关部门讨论修改，最终由项目治理部门、相关职能部门审批，最后由公司治理层终批生效。例如：－－严格加强项目章程的规范性和严肃性，任命项目经理的必要性－－项目所需资源，由项目经理提出申请，职能经理负责委派人员；－－项目实施期间的考核由项目经理负责，项目结束后，人员回到职能部门，考核内容也转交给职能经理，最终由职能经理负责全部考核－－项目治理部经理和资源部门经理对等处理项目过程中项目目标和资源提供的决策问题；2.4在项目工作安排方面，特不注意治理好各个接口，如项目成员之间或部门之间的工作交接，技术交接、资源交接2.5加强项目沟通，适量增加项目信息收集、整理、分析和公布的频次，如此能及时发觉项目问题，利于及时采取纠正措施。能够通过电子邮件等手段，及时将项目进展情况、存在的问题和纠正措施通报给全体项目成员、不要不记得抄送给项目成员所属部门的经理，假如有必要，甚至抄送给公司治理层。【补充】：组织结构对项目的阻碍项目特点职能型组织矩阵型组织项目型组织弱矩阵型组织平衡矩阵型组织强矩阵型组织项目经理的权利专门小或没有有限小∼中等中等∼大大∼全权组织中全职参与项目没有0∼2515∼6050∼9585∼100工作的职员比例（%）项目经理的职位部分时刻部分时刻全时全时全时项目经理的一般头衔项目协调员项目协调员项目经理项目经理项目经理/项目主管/项目主管/项目主任/打算主任/打算主任项目经理行政人员部分时刻部分时刻部分时刻全时全时案例三（项目生命周期模型2009上试题五）阅读下列讲明，回答问题1至问题3。将解答填入答题纸的对应栏内。【讲明】小赵是一位优秀的软件设计师，负责过多项系统集成项目的应用开发，现在公司因人手紧张，让他作为项目经理独自治理一个类似的项目，他使用瀑布模型来治理该项目的全生命周期，如下所示：项目进行到实施时期，小赵发觉在系统定义时期所制订的项目打算可能不准，实施时期有许多原先没有可能到的任务现在都冒了出来。项目工期因而一再延期，成本也一直超出。

【问题1】（6分）

依照项目存在的问题，请简要分析小赵在项目整体治理方面可能存在的问题。

【问题2】（6分）

（1）请简要叙述瀑布模型的优缺点。

（2）请简要叙述其他模型如何弥补瀑布模型的不足。

【问题3】（3分）

针对本案例，请简要讲明项目进入实施时期时，项目经理小赵应该完成的项目文档工作？【问题1】1.软件设计师小赵第一次担任项目经理，独立治理一个项目，缺乏项目整体治理经验和技能；2.小赵选取瀑布模型作为项目整体治理的生命周期模式，缺乏科学的论证和系统的评估，开发模型的选取没有进行可行性分析和论证；3.在系统论证时期制定项目整体打算时，对进度打算没有采纳科学的方法，如类比估算法，专家推断，三点估算，应急时刻等。4.对项目需求和功能没有进行严格的需求分析、范围定义；5.在项目范围上没有制定WBS，规划项目实施范围；6.小赵没有对项目范围进行严格的范围确认；导致项目范围界定不清7.实施时期，没有对项目范围进行范围操纵，遵循规范的范围变更操纵治理，导致范围蔓延【问题2】书上162页瀑布模式的优点：时期划分次序清晰，各时期人员的职责规范、明确，便于前后活动的衔接，有利于活动重用和治理瀑布模式的缺点：是一种理想性的线性开发模式，缺乏灵活性（或风险分析），无法解决需求不明确或不准确的问题为弥补瀑布模型的缺点，可采纳快速原型法、螺旋模型和迭代模型。原型法模型，用于解决需求不明确的情况；螺旋模型，是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中操纵的和系统化的方面结合起来。4个象限分不标志每个周期的4个时期：制定打算、风险分析、实施工程和客户评估。该模型强调风险分析，特不适合庞大而复杂的、高风险的系统。迭代模型：每个时期都执行一次传统的、完整的串行过程串，执行一次过程串确实是一次迭代，每次迭代涉及的过程都包括不同比例的所有活动。【问题3】小赵在项目实施时期应完成的文档，分两大类：1.项目治理过程文档项目进度打算（变更）项目绩效报告项目会议记录项目范围（变更）讲明书变更操纵文档质量分析报告风险评估报告等等。2.项目产品实现文档概要设计讲明书详细设计讲明书代码规范程序编码设计书数据库模型与设计讲明书测试用例测试报告等等。

第5章立项治理案例一（项目可行性分析2011下试题一）阅读以下讲明，请回答问题1至3，将解答填入答题纸的对应栏内。【讲明】某大型企业集团拟在生产园区建立一套无线网络，覆盖半径大约1.5公里，要求能够支持高速数据传输、无线漫游以及多种类型数据业务等。集团总经理责成信息中心主任李某负责此事。李某找到曾经承担集团内部网络系统工程的系统集成商A公司，提出了集团的需求。A公司治理层开会研究后命令项目经理张某积极跟进，与李某紧密联系。张某通过上网搜索，发觉外企B公司最近推出的一种基于WIMAX技术的无线网络系统比较符合要求，国外也有类似的成功案例。张某亲自到B公司的国内代理商C公司进行了实地考察，并在C公司进行了产品演示实验，感到效果良好。随后，张某和李某沟通后，A公司正式与C公司签订了采购合同，并专门快进行了系统的安装部署。但是当无线网络系统正式投入运行后不久，就出现了一系列问题，比如：无线网络覆盖存在盲区，不支持某些类型的数据业务，用户较多时数据传输率急剧下降，间或发生莫名其妙的断网现象，等等。更苦恼的是，当地无线电治理部门认为他们没有取得无线电频使用执照，要求该集团立即停止运行该无线网络，同时要对他们进行处罚。现在C公司传来消息，称B公司因为内部缘故立即退出中国大陆市场，接着提供该系统的技术支持服务比较困难。【问题1】（6分）在本案例中，张某未进行充分的项目可行性研究以致项目出现危机，请指出具体体现在哪些方面（将正确选项对应的字母填入答题纸对应栏内，多选扣分）：A.投资必要B技术可行性C财务可行性D组织可行性E社会可行性F经济可行性G风险因素分析及对策【问题2】（3分）请简要列举进行项目可行性研究的要紧步骤。【问题3】（6分）假如你被A公司任命为该项目的项目经理，请用300字以内文字简要叙述你应如何应对目前的困境。答：【问题1】BEG【问题2】项目可行性研究的要紧步骤：初步可行性研究详细可行性研究项目论证项目评估项目可行性研究报告的编写、提交和获得批准

第6章项目整体（综合）治理项目整体治理流程图案例一（项目治理中存在的问题及改进措施）阅读下列讲明，回答问题1至问题3。将解答填入答题纸的对应栏内。【讲明】A公司是一家中小型系统集成公司，在2006年3月份正在预备对京发证券公司数据大集中项目进行投标，A公司副总裁张某授权销售部的林某为本次投标的负责人，来组织和治理整个投标过程。林某接到任务后，召集了由公司商务部、销售部、客服部和质管部等相关部门参加的启动讲明会，并把各自的分工和进度打算进行了部署。随后，在投标前3天进行投标文件评审时，发觉技术方案中所配置的设备在往常的项目使用中是存在问题的，必须更换，随后修改了技术方案。最后A公司中标并和客户签订了合同。依照公司的项目治理流程，林某把项目移交到了实施部门，由他们具体负责项目的执行与验收。实施部门接手项目后，鲍某被任命为实施项目经理，负责项目的实施和验收工作。鲍某发觉由于项目前期自己没有介入，许多项目前期的情况都不是专门清晰，而导致后续跟进速度较慢，阻碍项目的进度。同时鲍某还发觉设计方案中尚存在一些问题，要紧有：方案遗漏一项差不多需求，有多项无效需求，没有书面的需求调研报告；在项目的工期、系统功能和售后服务等方面，存在过度承诺现象。因此项目组重新调研用户需求，编制设计方案，这就增加了实施难度和成本。但是后来又发觉采购部仍是按照最初的方案采购设备，导致设备中的模块配置功能不符合要求的情况。而在A集成公司中，类似现象已多次发生。【问题1】（5分）针对讲明中所描述的现象，分析A公司在项目治理方面存在的问题（150字以内）。【问题2】（5分）针对A公司在该项目治理方面存在的问题，提出补救措施（150字以内）。【问题3】（5分）针对A公司的项目治理现状，结合你的实际经验，就A公司项目治理工作的持续改进提出意见和建议（150字以内）。答题思路：【问题1】1、投标前的项目启动会议上，没有邀请技术和实施部门2、没有把以往的经验教训，归纳和积存，形成组织知识资产3、没有建立完善的内部评审机制，或虽有评审机制但为有效执行4、项目中没有实现有效的变更治理5、公司级的项目治理体系不健全，或执行不行【问题2】1、改进项目的组织形式，明确项目团队和职能部门之间的协作关系和工作程序2、做好项目当前的经验教训收集、归纳工作3、明确项目工作的交付物，建立和实施项目的质量评审机制4、建立项目的变更治理机制，识不变更中的利益相关方并加强沟通5、加强对项目团队成员和相关人员的项目治理培训【问题3】1、建立企业级的项目治理体系和工作规范2、加强对项目工作记录的治理3、加强项目质量和相应的评审制度4、加强项目经验教训的收集、归纳、积存和分享工作5、引入合适的项目治理工具平台，提升项目治理工作效率案例二（项目整体2009上试题四）阅读下面叙述，回答问题1至问题3，将解答填入答题纸的对应栏内。【讲明】H某公司是一家专门从事ERP系统研发和实施的IT企业，目前该公司正在进行的一个项目是为某大型生产单位（甲方）研发ERP系统。某公司同甲方关系比较紧密，但也正因为如此，合同签的较为简单，项目执行较为随意。同时甲方组织架构较为复杂，项目需求来源多样而且经常发生变化，项目范围和进度经常要进行临时调整。通过项目组的困难努力，系统总算能够进入试运行时期，然而由于各种因素，甲方并不太情愿进行正式验收，至今项目也未能结项。【问题1】（6分）请从项目治理角度，简要分析该项目“未能结项”的可能缘故。【问题2】（5分）针对该项目现状，请简要讲明为了促使该项目进行验收，可采取哪些措施。【问题3】（4分）为了幸免以后出现类似情况，请简要叙述公司应采取哪些有效的治理手段。答：【问题1】缺乏有效的合同治理制度，案例中签订合同专门简单，没有在合同中明确甲乙双方的职责，明确项目的时刻要求，范围界定以及合同违约等条款和内容；没有严格的进度操纵、成本操纵和质量保证、风险分析等治理措施，案例中项目执行较随意，表明其缺乏规范和严格的项目治理制度和方法，规范的项目治理流程；针对甲方组织结构复杂，需求多变的情况，没有进行事前风险分析和制定风险应对措施，对需求没有进行严格的分析、治理措施，对项目范围也没有进行确定，针对项目范围、进度、成本的变化，缺乏必要的变更操纵手段和规范的变更操纵流程。对应项目的不验收，缺乏有效的沟通治理制度，缺少和甲方必须的沟通方法和措施，在合同中没有规定验收的标准和程序；对应项目出现的情况，缺少应急措施和有效的针对性方法，来解决项目当前的困难。【问题2】加强和甲方的沟通，针对项目验收的工作内容和方式，流程、时刻等问题，积极和甲方进行沟通，争取和甲方就项目验收工作达成一致意见；针对合同中没有明确的验收标准和流程等问题，能够采纳备忘录或者补充协议的形式，就项目验收的标准、流程、时刻和责任人等内容签署书面的具有法律效力的文件，以便指导项目验收工作。在项目组内部，加强项目治理工作力度，制定验收文档标准，积极预备验收工作，完善验收成果文档，明确项目验收工作的标准和流程，以及团队成员的职责。【问题3】公司应该建立严格和规范的合同治理制度，签订合同时必须在合同中明确项目的范围、进度以及相关要求，建立完善的合同文本；公司内部应该建立规范和完善的项目治理制度，在项目治理上建立合规的治理流程、方法和标准规范，推行科学的项目治理方法，包括范围治理、时刻治理、成本治理、质量治理、人力资源治理方面；在公司内部加强项目治理思想和方法的培训，建立全员的、全面的、全过程的项目治理体系和标准。在项目立项时，建立科学和严谨的项目可行性分析和论证制度，进行风险分析和风险评估，规避项目风险。建立良好的沟通机制；引入监理机制；做好有效的变更操纵。案例三（项目整体2010上试题四）【讲明】老陆是某系统集成公司资深项目经理，在项目建设初期带领项目团队确定了项目范围，后因工作安排太忙，无暇顾及本项目，因此他要求：本项目各小组组长分不制定组成项目治理打算的子打算；本项目各小组组长各自监督其团队成员在整个项目建设过程中子打算的执行情况；项目组成员坚决执行子打算，且原则上不同意修改。在执行三个月后，项目经常出现各子项目间无法顺利衔接，需要大量工时进行返工等问题，目前项目进度差不多远远滞后于预定打算。【问题1】（4分）请简要分析造成项目目前状况的缘故。【问题2】（6分）请简要叙述项目整体治理打算应包含哪些内容？【问题3】（5分）为了完成该项目，请从整体治理的角度讲明老陆和公司可采取哪些补救措施？答：【问题1】项目缺少整体打算。本案例中的做法只完成了项目治理打算中的子打算，并没有形成真正的项目整体治理打算，即确定、综合与协调所有子打算所需要的活动，并形成文件。项目缺少整体的报告和监控机制，各项目小组各自为政。项目缺少整体变更操纵流程和机制。治理打算本身是通过变更操纵过程进行不断更新和修订的，不同意修改是不切合实际的。【问题2】所使用的项目治理过程。每个特定项目治理过程的实施程度。完成这些项目的工具和技术的描述。选择的项目的生命周期和相关的项目时期。如何用选定的过程来治理具体的项目。包括过程之间的依靠与交互关系和差不多的输入输出等。如何执行流程来完成项目目标。如何监督和操纵变更更。如何实施配置治理。如何维护项目绩效基线的完整性。与项目干系人进行沟通的要求和技术。为项目选择的生命周期模型，关于多时期项目，要包括所定义时期是如何划分的。为了解决某些遗留问题和未定的决策，关于其内容、严峻程度和紧迫程度进行的关键治理评审。【问题3】建立整体治理机制。老陆应分配更多的精力来进行项目治理，或由其他合适的人员来承担整体治理的工作。理清各子项目组目前的工作状态。例如其工作进度、成本、资源配置等。重新定义项目的整体治理打算，并与各子项目打算建立明确关联。按照打算要求，重新进行资源平衡。建立或加强项目的沟通、报告和监控机制。加强项目的整体变更操纵。

第7章项目范围治理项目范围治理流程图（5过程）案例一（范围治理教程p51823.2.1）《系统集成项目治理工程师》教程第23章-案例分析23.2.1p518M公司原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业，在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。由于电了政务保密要求，该系统涉及到两个互不联通的子网：政务内网和政务外网。政务内网中储存着全部信息，其中包括部分机密信息；政务外网能够对公众开放，开放的信息必须得到授权。系统要求在这两个了网中的合法用户都能够访问到被授权的信息.访问的信息必须是一致可靠，政务内网的信息能够公布到政务外网，政务外网的信息在通过审批后能够进入政务内网系统。张工是该项目的项目经理，在捕获到那个需求后认为电子政务建设与企业信息化有专门大的不同，有其自身的专门性，若照搬企业信息化原有的经验和方案必定会遭到惨败。因此采纳了严格爆布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在通过严格评审后实施。在项目交付时，尽管系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求完全更换，由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70%的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写部分代码才通过驶收，由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原打算的100%。【问题1】（5分）请不超过150字，对张工的行为进行点评?【问题2】（5分）请从项目范围治理的角度找出该项目实施过程中的要紧治理问题？不超150字【问题3】（5分）请结合你本人实际项目经验，指出应如何幸免类似问题?不超过150字【问题1】请对张工的行为进行点评？工作的优点：1、认识到电子政务建设与企业信息化建设的不同，考虑到了项目的独特性的特征；2、针对业务需求中对内网、外网的互联互通的要求，针对性招聘了网络互联互通的技术人员；3、满足了用户保密性的要求；工作的缺点：1、采纳“瀑布模式”的项目生命周期，没有进行论证，武断；2、用户需求调研的不全面，忽视了系统页面的需求；同时，进行第二版修正时，没有针对页面的需求修改进行确认。3、设计方案没有进行验证；表现层内耦合的业务逻辑，增加了修改的代价；4、团队治理措施不力，成员产生挫折感；【问题2】请从项目范围治理的角度找出该项目实施过程中的要紧治理问题。没有建立规范的项目范围治理流程和制度。范围定义和需求分析时，工作不细致，忽视了B/S架构下的页面需求需求范围变更中，没有对页面变更进行“确认”，就修改代码【问题3】答题的思路和提纲，请将下列答题点细化针对甲方的需求，制定有用的项目范围治理打算；做好范围定义工作（详细列出方法）做好需求分析工作（方法、过程、工作步骤）重视范围确认（方法）严格范围变更（变更流程）建立完善的项目范围治理制度和规范的范围治理流程案例二（需求评审教程p51423.1.5）《系统集成项目治理工程师》教程p514第23章-案例分析23.1.5答：<软件需求的定义>1、软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段确实是需求评审，然而需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。<上述案例的问题小结>2以上的现象能够在专门多项目中都能够看到。概括起来，在需求评审中常见的问题是：

需求报告专门长，短时刻内评审者全然就不能把需求报告读明白，想清晰；

没有作好前期预备工作，需求评审的效率专门低；

需求评审的节奏无法操纵；

找不到合格的评审员，与会的评审员无法提出深入的问题；……<上述案例的缘故分析>3问题所在：评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。产品经理没有把握好会议主题，评审变成了头脑风暴。目标性需求没有沟通好，后面的需求变成空中楼阁。缺乏评审的可操作依据，遗漏评审内容。没有作好前期预备工作，导致评审时刻长，效率低。没有选择合适的评审人员，无法获得有价值的反馈。参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。<针对以上问题，提出一些建议>4那么究竟如何做好需求评审呢？建议一：分层次评审我们明白用户的需求是能够分层次的，一般而言能够分成如下的层次：目标性需求：定义了整个系统需要达到的目标；功能性需求：定义了整个系统必须完成的任务；操作性需求：定义了完成每个任务的具体的人机交互；目标性需求是企业的高层治理人员所关注的，功能性需求是企业的中层治理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区不的，参与评审的人员也是不同的。假如让具体的操作人员去评审目标性需求，可能会专门容易地导致“捡了芝麻，丢了西瓜”的现象，假如让高层的治理人员也去评审那些操作性需求，无疑是一种资源的白费或者就会出现案例三的情形。建议二：正式评审与非正式评审结合正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络谈天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发觉问题。因此在评审时，应该更灵活地利用这2种方式。建议三：分时期评审应该在需求形成的过程中进行分时期的评审，而不是在需求最终形成后再进行评审。分时期评审能够将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如能够在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。建议四：精心选择评审员需求评审可能涉及的人员包括：需方的高层治理人员、中层治理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大伙儿所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心选择评审员。首先要保证使不同类型的人员的都要参与进来，否则专门可能会漏掉了专门重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则专门可能使评审的效率降低或者最终不切实际的修改了系统的范围。建议五：对评审员进行培训在专门多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行，同样关于主持评审的治理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够操纵评审活动的节奏，提高评审效率，幸免发生案例一和案例二中出现的现象。对评审员的培训也能够区分为简单培训与详细培训2种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的差不多原则，需要注意的常见问题讲清晰。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时刻，是一个独立的活动。需要注意的是被评审人员也要被培训。建议六：充分利用需求评审检查单需求检查单是专门好的评审工具，需求检查单能够分成2类：需求形式的检查单和需求内容的检查单。需求形式的检查能够由QA人员负责，要紧是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，要紧是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单能够关心评审员系统全面地发觉需求中的问题，检查单也是随着工程财宝的积存逐渐丰富和优化的。建议七：建立标准的评审流程对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件，评审需要提交的资料，每次评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。通过评审流程执行可能会幸免出现案例五之类的问题。建议八：做好评审后的跟踪工作在需求评审后，需要依照评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些能够不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的治理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。建议九：充分预备评审评审质量的好坏专门大程度上取决于在评审会议前的预备活动。常出现的问题是，需求文档在评审会议前并没有提早下发给参与评审会议的人员，没有留出更多更充分的时刻让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率专门低，质量专门差。对评审的预备工作，也应当定义一个检查单，在评审之前对比检查单落实每项预备工作。案例三（范围治理2009下试题二）阅读下列讲明，针对项目的范围治理，回答问题1至问题3，将解答填入答题纸的对应栏内。【讲明】C公司是一家从事电子商务的外国公司，为了在中国开展业务，派出S主管和W翻译来中国查找合适的系统集成商，试图在中国建设一套业务系统。S主管精通软件开发，然而不明白汉语，而W翻译对计算机相关技术知之甚少。W翻译通过中国朋友介绍，找到了从事系统集成的H公司。H公司指派杨工为该业务系统建设项目经理，与C公司进行交流。通过需求调研，杨工认为，C公司想要建设一个视频谈天网站，并据此完成了系统方案。在W的翻译下，S批阅并认可了H公司的系统方案。通过进一步的谈判，C公司和H公司签订了合同，并把该系统方案作为合同附件，作为今后项目验收的标准。合同签订后，杨工迅速组织人力投入系统开发。由于杨工系统集成经验丰富，开发过程进展顺利，对项目如期完工专门有把握。系统开发期间，S主管和W翻译忙于在全国各地开拓市场，与H公司没有再进行接触。就在系统开发行将结束之际，S主管和W翻译来到H公司查看开发进度。当看到杨工演示的立即完工的业务系统时，S主管却表示，视频谈天只是系统的一个差不多功能，系统的核心功能则是通过视频谈天实现网上交易的电子商务活动，要求H公司完善系统功能并如期交付。杨工拿出系统方案作为证据，据理力争。W翻译承认此前他的工作有误，导致双方对项目范围的认识产生了偏差，并讲服S主管将交付日期延后2个月。为了完成合同，杨工同意对系统功能进行扩充完善，并重新修订了系统方案。然而，此后C公司又多次提出范围变更要求。杨工发觉，不断修订的系统方案差不多严峻偏离了原始方案，系统如期交付差不多是不可能的任务了。【问题1】（6分）请结合案例简要讲明，详细的项目范围讲明书应包含哪些内容，并指出C公司和H公司对哪些方面的理解出现了重大偏差。【问题2】（6分）请指出S主管的要求是否恰当？什么缘故？并请结合本案例简要分析导致C公司多次提出范围变更的可能缘故。【问题3】（3分）作为项目治理者，杨工现在应关注的范围变更操纵的要点有哪些？〔问题1〕详细的项目范围讲明书应包含如下内容：1、项目的目标；2、产品（或服务）的范围描述；3、项目的可交付物；4、项目边界；5、产品验收标准；6、项目的约束条件；7、项目的假定。C和H在如下几个方面出现了严峻偏差：1、项目的目标：H以为是实现视频谈天网站，而C期望是通过视频谈天实现网上交易的电子商务；2、项目的可交付物：同上；3、验收标准：H把未经确认的存在严峻偏差的“系统方案”作为验收标准。〔问题2〕S主管的要求是恰当的。因为双方在需求（项目范围）理解上存在重大偏差，而H公司未把详细的项目范围讲明书（需求分析讲明书），提交给C公司（S主管）确认签字。或：S主管的要求是不恰当的，因为双方已签订了合同，H公司按照合同进行开发，并无不妥。导致C公司多次提出范围变更的可能缘故：1、W翻译对计算机相关技术知之甚少，未能准确转达S主管的需求；2、杨工收集需求时，理解出现偏差，未能准确把握需求；3、杨工编制的需求分析讲明书，未进行内部评审；4、需求分析讲明书（或项目范围讲明书）未与C公司达成一致，未提交给S主管确认签字；5、杨工在范围操纵上做得不行。〔问题3〕1、确定范围变更是否差不多产生；2、对造成范围变更的因素施加阻碍，以确保这些变更得到一致的认可。3、当范围变更发生时，对实际的变更进行治理。案例四（涉及范围治理、进度治理和变更治理2010下试题一）试题一[讲明]某信息系统集成公司（承建方）成功中标当地政府某部门（建设方）办公场所的一信息系统软件升级改造项目。项目自2月份初开始，工期1年。承建方项目经理制订了相应的进度打算，将项目工期分为四个时期：需求分析时期打算8月底结束；设计时期打算9月底结束；编码时期打算11月底结束；安装、测试、调试和运行时期打算次年2月底结束。当年2月底，建设方通知承建方，6月至8月这3个月期间因某种缘故，无法配合项目实施。经双方沟通后达成一致，项目仍按原合同约定的工期执行。由于该项目的按时完成对承建方特不重要，在双方就合同达成一致后，承建方领导赶忙对项目经理做出指示：（1）招聘新人，加快需求分析的进度，赶在6月底之前完成需求分析；（2）6月至8月期间在本单位内部完成系统设计工作。项目经理虽有不同意见，但依旧依照领导的指示立即修改了进度治理打算并招募了新人，要求项目组按新打算执行，但项目进展缓慢。直到7月底项目组才刚刚完成需求分析和初步设计。【问题1】（3分）除案例中描写的具体事项外，承建方项目经理在进度治理方面能够采取哪些措施？A、开发抛弃型原型B、绩效评估C、偏差分析D、编写项目进度报告E、确认项目范围F、公布新版项目章程【问题2】（6分）基于你的经验，请指出承建方领导的指示中可能存在的风险，并简要叙述进行变更的要紧步骤。【问题3】（6分）针对项目现状，请简述项目经理能够采纳的进度压缩技术，并分析利弊。答案：【问题1】BCD【问题2】盲目增加人力未必能够加快项目进度，尤其是增加没有经验的职员，反而可能会拖延进度。项目的风险是否能够规避，需要按照风险治理的方法进行风险识不、风险分析和风险监控。进行变更操纵：依照领导指示的内容，向变更操纵委员会提出相关变更申请；推动变更操纵委员会对变更进行评估，分析变更造成的阻碍和风险；依照变更决策推动变更的实施，包括更新进度打算、招聘新人和相关活动；执行或推动变更的确认，开展变更后的项目活动。【问题3】进度压缩的技术有以下两种：（1）赶进度：对费用和进度进行权衡，确定如何在尽量减少费用的前提下缩短项目所需时刻.利：有可能在尽量减少费用的前提下缩短项目所需的时刻；弊：赶进度并非总能产生可行的方案，有可能反而使费用增加；（2）快速跟进：同时进行按先后顺序的时期或活动。利：适当增加费用，能够缩短项目所需的时刻；弊：以增加费用为代价换取时刻，并因缩短项目进度时刻而增加风险。案例五（范围治理2010下试题四）【讲明】某公司为当地一家书店开发图书资料垂直搜索引擎产品，双方详细约定了合同条款，包括合同金额、产品验收标准等。此项目是该公司独立承担的一个小型项目，项目经理小张兼任项目技术负责人，项目进行到设计时期后，由于小张从未参与过垂直搜索引擎的产品开发，产品设计方案通过两次评审后仍未能通过。公司决定将小张从该项目组调离，由小李接任该项目的项目经理兼项目技术负责人。小李认真查阅了小张组织撰写的项目范围讲明书和产品设计方案后，进行了修改。小李将原定从头开发的方案修改为通过学习和重用开源代码来实现的方案。小李还相应地修改了小张组织编写的项目范围讲明书，将其中按照项目生命周期分解得到的大型分解目录列表形式的WBS改为按照要紧可交付物分解的树形结构图形式，减少了WBS的层次。小李提出的涉及方案和项目范围讲明书得到了项目干系人的认可，通过了评审。【问题1】（5分）结合本案例，推断下列选项的正误。项目范围操纵需要按照项目整体变更操纵过程来处理。（）项目范围讲明书通过了评审，标志着完成了项目范围确认工作。（）小李修改了项目范围讲明书，但原有的项目范围治理打算不需要变更。（）小李编写的项目范围讲明书中应该包括产品验收标准等重要合同条款。（）通过评审后，新项目范围讲明书将成为该项目的范围基准。（）【问题2】（4分）请简述小李组织编写的项目范围讲明书中WBS的表示形式与小张组织编写的项目范围讲明书中WBS的表示形式各自的优缺点及适用场合。【问题3】（6分）结合项目现状，请简述在项目后续工作中小李应如何做好范围操纵工作。答：【问题1】（1）√（2）×（3）×（4）√（5）√【问题2】小李组织编写的项目范围讲明书中WBS的表示形式为分级的树型结构图。树型结构图的WBS层次清晰，特不直观，结构性专门强，然而不易修改；关于大的，复杂的项目也专门难表示出项目的全景。由于其直观性，一般在一些中小型的应用项目中用的比较多。小张组织编写的项目范围讲明书中WBS的表示形式为分级目录（列表形式）。该表格能反映出项目所有的工作要素，但直观性差，有些项目分解后内容分类较多，容量较大。常用在一些大的，复杂的项目中。【问题3】（1）小李首先要负责建立项目的范围基准；（2）维护项目的范围基准，必要时按照公司变更流程变更项目范围；（3）还要负责组织实施项目范围变更、确认变更结果，以及后续项目范围操纵。案例六（范围治理2011上试题一）【讲明】M公司承担了某大学图书馆存储及治理系统的开发任务，任务周期4个月。小陈是M公司的职员，半年前入职。在校期间，小陈跟随导师做过两年的软件开发，具有专门好的软件开发基础。领导对小陈专门信任，任命小陈担任该项目的项目经理。项目立项前，小陈参与了用户前期沟通会议，并承担了需求分析工作。会议结束后，相关部门按照要求整理会议所形成的决议和共识，并发给客户等待确认。为了节约时刻，小陈依照自己在沟通会议上记录的结果，当晚组织有关人员撰写了软件需求规格讲明。次日便要求设计人员开始进行系统设计，并指出项目组成员必须严格按照进度打算执行，以不辜负领导的期望与嘱托。项目进行了2个月后，校方主管此业务的新领导上任，并提出了新的信息化治理要求。小陈进行变更阻碍分析，认为成本超支严峻，因此小陈决定不进行范围变更，并将结果通知客户，引起了客户的不满。项目进入测试时期后，M公司开展内部治理审查活动，此项目作为在建项目同意了审查，项目审查员给该项目提出了多个问题，范围治理方面的问题尤为突出。【问题1】（5分）结合本案例，分析小陈在此项目中项目范围治理方面可能存在的不足。【问题2】（6分）小陈组织人员撰些项目WBS如下请讲明上述WBS结构是将作为第一层进行分解，除了上述方法，还能够采纳哪些方式进行分解。从上图来看，完整的WBS中除了实现最终产品或服务所必须进行的技术工作，还需要包括。创建WBS时要遵循哪些原则？供选择答案（将正确选项的字母填入答题纸对应栏内）在各层次上保持项目的完整性，幸免遗漏必要的组成部分。一个工作单元能够从属于某些上层单元。相同层次的工作单元能够具有不同性质。工作单元应能分开不同责任者和不同工作内容。便于项目治理进行打算和操纵的治理需要。最底层工作应具有可比性，是可治理的，可定量检查的。分解到相同颗粒度的工作包。WBS不包括分包出去的工作。【问题3】（4分）（1）请指出本案例中引起范围变更的缘故。（2）一般情况下，造成项目范围变更还有哪些要紧缘故。答：【问题1】没有制定项目的项目范围治理打算；缺乏项目范围定义工作。软件需求规格讲明书未经评审，也没有得到客户的签字确认。缺乏范围确认工作。项目执行过程中产生的会议纪要、软件规格讲明、时期性工作成果等都没有得到客户及时的签字确认。当项目中出现范围变更请求时，小陈没有把变更的潜在阻碍告知相关的项目干系人，而仅仅是把其决定的结果通知客户，从而造成了客户的不满。当项目中出现范围变更请求时，小陈也未获得相关人员或机构（如：CCB）的审批，擅自拒绝。【问题2】adef项目生命周期的时期，可交付物、子项目项目的治理工作adef【问题3】（1）本案例中引起范围变更的缘故是：客户对项目、项目产品或服务的要求发生变化。没有详细的项目范围治理打算（2）一般情况下，造成项目范围变更的要紧缘故包括：项目外部环境发生变化，如政府政策的问题；项目范围的打算编制不周密详细，有一定的错误或遗漏；市场上出现了或是设计人员提出了新技术、新手段或新方案；项目实施组织本身发生变化；客户对项目、项目产品或服务的要求发生变化。

第8章项目进度治理项目进度治理流程图（6过程）案例一（项目进度，重点资源配置对进度的制约）【讲明】某系统集成公司现有职员50多人，业务部门分为销售部、软件开发部、系统网络部等。通过近半年的酝酿后，在今年一月份，公司的销售部直接与某银行签订了一个银行前置机的软件系统的项目。合同规定，6月28日之前系统必须投入试运行。在合同签订后，销售部将此合同移交给了软件开发部，进行项目的实施。项目经理小丁做过5年的系统分析和设计工作，但这是他第一次担任项目经理。小丁兼任系统分析工作，此外项目还有2名有1年工作经验的程序员，1名测试人员，2名负责组网和布线的系统工程师。项目组成的成员均全程参加项目。在承担项目之后，小丁组织大伙儿制定了项目的WBS，并依照以往的经历制订了本项目的进度打算，简单描述如下：1、应用子系统1）1月5日～2月5日需求分析2）2月6日～3月26日系统设计和软件设计3）3月27日～5月10日编码4）5月11日～5月30日系统内部测试2、综合布线2月20日～4月20日完成调研和布线3、网络子系统4月21日～5月21日设备安装、联调4、系统内部调试、验收1）6月1日～6月20日试运行2）6月28日系统验收春节后，在2月17日小丁发觉系统设计刚刚开始，由此推测3月26日专门可能完不成系统设计。【问题1】（4分）请用150字以内的文字，分析问题发生的可能缘故。【问题2】（5分）请用150字以内的文字，建议小丁应该如何做以保证项目整体进度不拖延。【问题3】（6分）请用200字以内的文字，概述典型的信息系统集成项目的进度／时刻治理的过程和方法以及资源配置对进度的制约。答：【问题1】销售部没有及时让软件开发部参与项目早期工作，需求分析耗时过长；项目经理首次担任，经验不足，进度估算不准确；项目资源配置不足，项目经理兼任系统分析，缺乏专门的系统分析和设计人员工作安排没有充分利用分配的项目资源，资源有闲置；在安排进度时可能未考虑法定节假日的因素【问题2】（1）向职能经理申请增加特定资源，特不是增加系统分析设计人员；（2）将部分时期的工作改为并行进行，以节约时刻（3）临时加班/赶工，尽可能补救耽搁的时刻（4）对后续工作的工期重新进行估算，并考虑节假日问题，修订打算，尽量留有余地（5）加强沟通，争取客户能够对项目范围以及需求、设计、验收标准进行确认，幸免后期频繁出现变更。（6）加强对时期性工作的检查和操纵，幸免后期出现返工。此外，如有可能还可采取外包和缩减范围等方法，只是不建议在本案例中采纳【问题3】1、进度治理的过程2、资源对进度的阻碍（1）一般情况下，项目活动历时与投入的资源数量成反比，即投入的资源数量越多，活动历时越短。然而，当针对某一活动的资源投入数量达到一定规模时，再增加资源的投入可不能进一步缩短项目活动历时，也确实是资源投入递减规律（2）非关键路径上的活动历时只对项目产生较小的阻碍或不产生阻碍，而关键路径上活动历时的延误，则会直接阻碍到项目工期。因此每当缩短项目工期时，应对首先考虑在关键路径活动上增加资源。案例二（项目的工期估算、进度压缩、进度跟踪）阅读下列讲明，回答问题1至问题3。将解答填入答题纸的对应栏内。【讲明】J公司2008年3月中标某市公安局的人口治理系统开发项目，因该市要在2008年11月举办某大型国际会议，因此公安局要求人口治理系统一定要在2008年7月1日之前投入使用。强某是负责那个项目的项目经理，尽管他进公司才不到3年，但他已成功地治理过2个类似的项目，被大伙儿称之为“救火队长”，而强某也对自己信心十足。但这次和以往不同的是强某还同时治理着另外两个项目，而那个人口治理系统项目的工期要求紧、他能调用的人手少。该人口治理系统项目属于升级项目。原来的系统为J公司开发，是C/S结构，只能治理本地城区常住人口。新的人口治理系统要求是B/S结构，要既能治理城区常住人口又能治理郊区常住人口、市辖县常住人口和流淌人口，而公安局要求该新系统首先把流淌人口治理起来。该项目从技术角度可分为网络改造和软件开发，而软件又分界面、业务流程和数据库三个子系统。他们团队有6人，其中有人做过类似的C/S结构的项目，而公司刚结束的一个网络项目与本次承担的网络改造项目在技术架构方面几近相同，只是规模不同。公安局要求新系统能够支持移动接入，而项目团队中没有一人接触过移动接入技术。强某凭直觉明白依现有的人员在2008年7月1日之前完成项目是不可能的。【问题1】（5分）请讲明强某能够用什么方法和技术来估算项目的工期（150字以内）？【问题2】（5分）请讲明强某能够采取哪些方法来压缩工期，以使项目能够在2008年7月1日【问题3】（5分）请讲明强某能够采纳哪些方法来跟踪项目的进度