系统集成工程师考试历年Word格式.docx

系统集成工程师考试历年Word格式.docx

《系统集成工程师考试历年Word格式.docx》由会员分享，可在线阅读，更多相关《系统集成工程师考试历年Word格式.docx（47页珍藏版）》请在冰豆网上搜索。

（6）缺乏有效的项目绩效管理机制；

[问题2]（10分）你认为高级项目经理章某应该如何指导和帮助李某（300字以内）。

（1）章某应明确李某的工作职责，帮助其实现向项目经理角色的转变；

（2）参加小李组织的周例会，以及时发现问题，予以指导；

（3）对李某提供相关工作的指导或培训，尤其是在项目管理方面；

（4）从整体项目层面对各子项目进行协调和计划，对子项目提出具体工作要求；

（5）加强对子项目的日常监督，要项目经理以身作则；

（6）针对子项目中出现的问题，及时提出纠正和预防措施；

[问题3]（5分）请说明李某作为项目经理要承担哪些角色？

（300字以内）

参加书上147－148页内容

（7分）在制订进度计划时，鲍某可能会采取哪些措施使制订的进度计划满

足客户的要求？

（5分）实施项目的系统集成商B目前的组织类型是什么？

如何改进其项目的

组织方式？

如何改进其项目管理的流程？

如何降低管理外地项目的成本？

（3分）在项目实施过程中，负责售前工作的李某应继续承担哪些工作？

答题思路：

【问题1`1】

1）沟通，强调该项目对系统集成商B的重要意义，提高项目优先级。

使用开会方式争取相关部门的建议、支持和承诺。

2）从现有资源和实际情况出发，优化网络图，如重新安排活动之间的顺序，压缩关键路径长度。

3）增加资源，引入经验丰富的员工

4）并行，在现有资源下，子任务并行，内部流程优化。

5）赶工，项目员工通过加班来加快项目进度

6）尽可能地调配非关键路径上的资源用于关键路径上的任务

7）优化外包，采购等环境并全程监控

【问题2】

（1）系统集成商B的组织方式是职能式的。

（2）系统集成商B的组织方式应该改为矩阵型。

（3）最好的办法是项目下阶段的人员提前介入到前一阶段，如在项目的售前阶段，负责项目实施的项目经理正式参与售前工作。

（4）另外，做好项目实施流程间的交接工作，如建立一套完整的项目售前和项目实施阶段之间的交接规范和要求－包括文档、培训、合同等内容。

（5）委托、分包给当地有资质的集成商，或在当地招人。

如果材料和服务在当地采购可降低成本。

压低人员差旅费，事宜虚拟远程的沟通和售后服务手段。

【问题3】

（1）与客户高层沟通，了解客户对项目实施情况的反映，维护客户关系，发掘新的项目机会。

（2）参加周例会，或至少每周首一次周报以了解项目的进展和问题。

（3）参与可能发生的变更的前期评审工作。

（4）负责或者协助收款。

4.3项目组织结构

阅读下面叙述，回答问题1至问题3，将解答填入答题纸的对应栏内。

《系统集成项目管理工程师》教程第23章-案例分析23.1.7

1、强矩阵型组织结构的特点是：

它具有很多项目型组织的特征，具有拥有很大职权的专职项目经理和专职项目行政管理人员。

2、在强矩阵组织中，为协调项目经理和职能部门经理的权责，应：

2.1在公司管理思想和原则上，明确矩阵型组织的特征：

★能够以项目为导向

　　★有了客户问题处理中心

　　★协调工作由项目管理队伍承担

　　★能够明确责任

　　★资源来自各职能部门，并且这些资源可在不同项目中共享

　　★专业人员在技术上可相互支持

★各专业员工组织上仍归属其职能部门，因此项目结束后，员工“有家可归”

2.2在公司制度上，明确职能部门和项目经理之间的权责分配关系：

－－资源、人员日常归职能部门经理管理和考核；

－－在项目实施期间人员、资源由项目经理全权管理和考核；

2.3建立一个清晰的项目管理流程，明确项目经理在项目实施期间的权力和责任；

定义了相关人员和相关部门在项目活动中的工作范围、工作过程和职责。

这个流程一般由项目管理部门起草，经过相关部门讨论修改，最终由项目管理部门、相关职能部门审批，最后由公司管理层终批生效。

例如：

－－严格加强项目章程的规范性和严肃性，任命项目经理的必要性

－－项目所需资源，由项目经理提出申请，职能经理负责委派人员；

－－项目实施期间的考核由项目经理负责，项目结束后，人员回到职能部门，考核

内容也转交给职能经理，最终由职能经理负责全部考核

－－项目管理部经理和资源部门经理对等处理项目过程中项目目标和资源提供的决策问题；

2.4在项目工作安排方面，特别注意管理好各个接口，如项目成员之间或部门之间的工作交接，技术交接、资源交接

2.5加强项目沟通，适量增加项目信息收集、整理、分析和发布的频次，这样能及时发现项目问题，利于及时采取纠正措施。

可以通过电子邮件等手段，及时将项目进展情况、存在的问题和纠正措施通报给全体项目成员、不要忘记抄送给项目成员所属部门的经理，如果有必要，甚至抄送给公司管理层。

4.4项目生命周期模型2009上

阅读下列说明，回答问题1至问题3。

将解答填入答题纸的对应栏内。

小赵是一位优秀的软件设计师，负责过多项系统集成项目的应用开发，现在公司因人手紧张，让他作为项目经理独自管理一个类似的项目，他使用瀑布模型来管理该项目的全生命周期，如下所示：

项目进行到实施阶段，小赵发现在系统定义阶段所制订的项目计划估计不准，实施阶段有许多原先没有估计到的任务现在都冒了出来。

项目工期因而一再延期，成本也一直超出。

（6分）

根据项目存在的问题，请简要分析小赵在项目整体管理方面可能存在的问题。

（6分）

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

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

（3分）

针对本案例，请简要说明项目进入实施阶段时，项目经理小赵应该完成的项目文档工作？

【问题1】

1、软件设计师小赵第一次担任项目经理，独立管理一个项目，缺乏项目整体管理经验和技能；

2、小赵选取瀑布模型作为项目整体管理的生命周期模式，缺乏科学的论证和系统的评估，开发模型的选取没有进行可行性分析和论证；

3、在系统论证阶段制定项目整体计划时，对进度计划没有采用科学的方法，如类比估算法，专家判断，三点估算，应急时间等。

4、对项目需求和功能没有进行严格的需求分析、范围定义；

5、在项目范围上没有制定WBS，规划项目实施范围；

6、小赵没有对项目范围进行严格的范围确认；

导致项目范围界定不清

7、实施阶段，没有对项目范围进行范围控制，遵循规范的范围变更控制管理，导致范围蔓延

【问题2】书上162页

1、瀑布模式的优点是

2、为弥补瀑布模型的缺点，可采用快速原型法、螺旋模型和迭代模型

小赵在项目实施阶段应完成的文档，分两大类：

（1）项目管理过程文档—项目进度计划（变更），项目绩效报告，项目会议记录，项目范围（变更）说明书、变更控制文档、质量分析报告，风险评估报告等等。

（2）项目产品实现文档—概要设计说明书，详细设计说明书，代码规范，程序编码设计书，数据库模型与设计说明书，测试用例，测试报告等等。

第5章立项管理

5.1项目可行性分析—分析报告

阅读下列有关项目可行性分析的说明，回答问题1至问题3。

参考答案：

<

>

第6章项目整体管理

6.1项目整体（综合）管理

A公司是一家中小型系统集成公司，在2006年3月份正在准备对京发证券公司数据大集中项目进行投标，A公司副总裁张某授权销售部的林某为本次投标的负责人，来组织和管理整个投标过程。

林某接到任务后，召集了由公司商务部、销售部、客服部和质管部等相关部门参加的启动说明会，并把各自的分工和进度计划进行了部署。

随后，在投标前3天进行投标文件评审时，发现技术方案中所配置的设备在以前的项目使用中是存在问题的，必须更换，随后修改了技术方案。

最后A公司中标并和客户签订了合同。

根据公司的项目管理流程，林某把项目移交到了实施部门，由他们具体负责项目的执行与验收。

实施部门接手项目后，鲍某被任命为实施项目经理，负责项目的实施和验收工作。

鲍某发现由于项目前期自己没有介入，许多项目前期的事情都不是很清楚，而导致后续跟进速度较慢，影响项目的进度。

同时鲍某还发现设计方案中尚存在一些问题，主要有：

方案遗漏一项基本需求，有多项无效需求，没有书面的需求调研报告；

在项目的工期、系统功能和售后服务等方面，存在过度承诺现象。

于是项目组重新调研用户需求，编制设计方案，这就增加了实施难度和成本。

可是后来又发现采购部仍是按照最初的方案采购设备，导致设备中的模块配置功能不符合要求的情况。

而在A集成公司中，类似现象已多次发生。

（5分）针对说明中所描述的现象，分析A公司在项目管理方面存在的问题（150字以内）。

（5分）针对A公司在该项目管理方面存在的问题，提出补救措施（150字以内）。

（5分）针对A公司的项目管理现状，结合你的实际经验，就A公司项目管理工作的持续改进提出意见和建议（150字以内）。

1、投标前的项目启动会议上，没有邀请技术和实施部门

2、没有把以往的经验教训，归纳和积累，形成组织知识资产

3、没有建立完善的内部评审机制，或虽有评审机制但为有效执行

4、项目中没有实现有效的变更管理

5、公司级的项目管理体系不健全，或执行不好

1、改进项目的组织形式，明确项目团队和职能部门之间的协作关系和工作程序

2、做好项目当前的经验教训收集、归纳工作

3、明确项目工作的交付物，建立和实施项目的质量评审机制

4、建立项目的变更管理机制，识别变更中的利益相关方并加强沟通

5、加强对项目团队成员和相关人员的项目管理培训

1、建立企业级的项目管理体系和工作规范

2、加强对项目工作记录的管理

3、加强项目质量和相应的评审制度

4、加强项目经验教训的收集、归纳、积累和分享工作

5、引入合适的项目管理工具平台，提升项目管理工作效率

6.2项目整体2009上

【说明】

某公司是一家专门从事ERP系统研发和实施的IT企业，目前该公司正在进行的一个项目是为某大型生产单位（甲方）研发ERP系统。

某公司同甲方关系比较密切，但也正因为如此，合同签的较为简单，项目执行较为随意。

同时甲方组织架构较为复杂，项目需求来源多样而且经常发生变化，项目范围和进度经常要进行临时调整。

经过项目组的艰苦努力，系统总算能够进入试运行阶段，但是由于各种因素，甲方并不太愿意进行正式验收，至今项目也未能结项。

【问题1】

请从项目管理角度，简要分析该项目“未能结项”的可能原因。

【问题2】

（5分）

针对该项目现状，请简要说明为了促使该项目进行验收，可采取哪些措施。

【问题3】

（4分）

为了避免以后出现类似情况，请简要叙述公司应采取哪些有效的管理手段。

1、签订合同很简单，没有在合同中明确甲乙双方的职责，明确项目的时间要求，范围界定以及合同违约等条款和内容，缺乏有效的合同管理制度；

2、项目执行较随意，表明其缺乏规范和严格的项目管理制度和方法，规范的项目管理流程，没有严格的进度控制、成本控制和质量保证、风险分析等管理措施。

3、针对甲方组织结构复杂，需求多变的情况，没有进行事前风险分析和制定风险应对措施，对需求没有进行严格的分析、管理措施，对项目范围也没有进行确定，

4、针对项目范围、进度、成本的变化，缺乏必要的变更控制手段和规范的变更控制流程。

5、对应项目的不验收，缺乏有效的沟通管理制度，缺少和甲方必须的沟通方法和措施，在合同中没有规定验收的标准和程序；

6、对应项目出现的情况，缺少应急措施和有效的针对性方法，来解决项目当前的困难。

1、加强和甲方的沟通，针对项目验收的工作内容和方式，流程、时间等问题，积极和甲方进行沟通，争取和甲方就项目验收工作达成一致意见；

2、针对合同中没有明确的验收标准和流程等问题，可以采用备忘录或者补充协议的形式，就项目验收的标准、流程、时间和责任人等内容签署书面的具有法律效力的文件，以便指导项目验收工作。

3、在项目组内部，加强项目管理工作力度，制定验收文档标准，积极准备验收工作，完善验收成果文档，明确项目验收工作的标准和流程，以及团队成员的职责。

1、公司应该建立严格和规范的合同管理制度，签订合同时必须在合同中明确项目的范围、进度以及相关要求，建立完善的合同文本；

2、公司内部应该建立规范和完善的项目管理制度，在项目管理上建立合规的管理流程、方法和标准规范，推行科学的项目管理方法，包括范围管理、时间管理、成本管理、质量管理、人力资源管理方面；

3、在公司内部加强项目管理思想和方法的培训，建立全员的、全面的、全过程的项目管理体系和标准。

4、在项目立项时，建立科学和严谨的项目可行性分析和论证制度，进行风险分析和风险评估，规避项目风险。

第7章项目范围管理

7.1范围定义

《系统集成项目管理工程师》教程第23章-案例分析23.2.1

M公司原本是一家专注于企业信息化的公司，在电子政务如火如荼的时候，开始进军电子政务行业，在电子政务的市场中，接到的第一个项目是开发一套工商审批系统。

由于电了政务保密要求，该系统涉及到两个互不联通的子网：

政务内网和政务外网。

政务内网中储存着全部信息，其中包括部分机密信息；

政务外网可以对公众开放，开放的信息必须御到授权。

系统要求在这两个了网中的合法用户都可以访问到被授权的信息.访问的信息必须是一致可靠，政务内网的信息可以发布到政务外网，政务外网的信息在经过审批后可以进入政务内网系统。

张工是该项目的项目经理，在捕获到这个需求后认为电子政务建设与企业信息化有很大的不同，有其自身的特殊性，若照搬企业信息化原有的经验和方案必定会遭到惨败。

因此采用了严格爆布模型，并专门招聘了熟悉网络互通互联的技术人员设计了解决方案，在经过严格评审后实施。

在项目交付时，虽然系统完全满足了保密性的要求，但用户对系统用户界面提出了较大的异议，认为不符合政务信息系统的风格，操作也不够便捷，要求彻底更换，由于最初设计的缺陷，系统表现层和逻辑层紧密耦合，导致70%的代码重写，而第二版的用户界面仍不能满足最终用户的要求，最终又重写部分代码才通过驶收，由于系统的反复变更，项目组成员产生了强烈的挫折感，士气低落，项目工期也超出原计划的100%。

请不超过150字，对张工的行为进行点评?

请从项目范围管理的角度找出该项目实施过程中的主要管理问题？

不超150字

请结合你本人实际项目经验，指出应如何避免类似问题?

不超过150字

【问题1】请对张工的行为进行点评？

工作的优点：

1、认识到电子政务建设与企业信息化建设的不同，考虑到了项目的独特性的特征；

2、针对业务需求中对内网、外网的互联互通的要求，针对性招聘了网络互联互通的技术人员；

3、满足了用户保密性的要求；

工作的缺点：

1、采用“瀑布模式”的项目生命周期，没有进行论证，武断；

2、用户需求调研的不全面，忽视了系统页面的需求；

并且，进行第二版修正时，没有针对页面的需求修改进行确认。

3、设计方案没有进行验证；

表现层内耦合的业务逻辑，增加了修改的代价；

4、团队管理措施不力，成员产生挫折感；

【问题2】请从项目范围管理的角度找出该项目实施过程中的主要管理问题。

1、没有建立规范的项目范围管理流程和制度。

2、范围定义和需求分析时，工作不细致，忽视了B/S架构下的页面需求

3、需求范围变更中，没有对页面变更进行“确认”，就修改代码

答题的思路和提纲，请将下列答题点细化

1、针对甲方的需求，制定实用的项目范围管理计划；

2、做好范围定义工作（详细列出方法）

3、做好需求分析工作（方法、过程、工作步骤）

4、重视范围确认（方法）

5、严格范围变更（变更流程）

6、建立完善的项目范围管理制度和规范的范围管理流程

7.2需求评审

《系统集成项目管理工程师》教程第23章-案例分析23.1.5

软件需求的定义>

1、软件需求是软件开发的最重要的一个输入，需求风险也常常是软件开发过程中最大的一个风险，降低需求风险的一个重要手段就是需求评审，但是需求评审是所有的评审活动中最难的一个，也是最容易被忽视的一个评审。

上述案例的问题小结>

　　2以上的现象可以在很多项目中都可以看到。

概括起来，在需求评审中常见的问题是：

　　◇需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚；

　　◇没有作好前期准备工作，需求评审的效率很低；

　　◇需求评审的节奏无法控制；

　　◇找不到合格的评审员，与会的评审员无法提出深入的问题；

……

上述案例的原因分析>

　　3问题所在：

●　评审缺乏有效依据和规范，不能保证评审的覆盖率和有效性。

●　产品经理没有把握好会议主题，评审变成了头脑风暴。

●　目标性需求没有沟通好，后面的需求变成空中楼阁。

●　缺乏评审的可操作依据，遗漏评审内容。

●　没有作好前期准备工作，导致评审时间长，效率低。

●　没有选择合适的评审人员，无法获得有价值的反馈。

●　参加人员过多，容易陷入细枝末节的讨论，会议演变成一场人人自由的混战。

　　<

针对以上问题，提出一些建议>

4那么究竟如何做好需求评审呢？

建议一：

分层次评审

我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：

Ø

　目标性需求：

定义了整个系统需要达到的目标；

　功能性需求：

定义了整个系统必须完成的任务；

　操作性需求：

定义了完成每个任务的具体的人机交互；

　　目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。

对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。

如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。

建议二：

正式评审与非正式评审结合

　　正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。

而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。

2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。

因此在评审时，应该更灵活地利用这2种方式。

建议三：

分阶段评审

　　应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。

分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。

比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。

建议四：

精心挑选评审员

　　需求评审可能涉及的人员包括：

需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；

供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。

在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。

为了保证评审的质量和效率，需要精心挑选评审员。

首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。

其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

建议五：

对评审员进行培训

　　在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。

对评审员的培训也可以区分为简单培训与详细培训2种。

简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。

详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。

需要注意的是被评审人员也要被培训。

建议六：

充分利用需求评审检查单

　　需求检查单是很好的评审工具，需求检查单可以分成2类：

需求形式的检查单和需求内容的检查单。

需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。

检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。

建议七：

建立标准的评审流程

　　对正规的需求评审会需要建立正规的需求评