系统集成项目管理工程师历年真题案例分析汇总(5)

【问题2】（5分）

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

【问题3】（5分）

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

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

工作的优点：

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

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

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

工作的缺点：

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

2、用户需求调研的不全面，忽视了系统页面的需求；并且，进行第二版修正时，没有针对页面的需求修改进行确认。

3、设计方案没有进行验证；表现层内耦合的业务逻辑，增加了修改的代价；

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

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

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

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

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

【问题 3】

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

1、

2、

3、

4、

5、

6、

针对甲方的需求，制定实用的项目范围管理计划； 做好范围定义工作（详细列出方法） 做好需求分析工作（方法、过程、工作步骤） 重视范围确认（方法） 严格范围变更（变更流程） 建立完善的项目范围管理制度和规范的范围管理流程

案例二（需求评审 教程 p514 23.1.5）

《系统集成项目管理工程师》教程 p514 第23章-案例分析 23.1.5 答：<软件需求的定义>

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

<上述案例的问题小结>

2 以上的现象可以在很多项目中都可以看到。概括起来，在需求评审中常见的问题是：

◇ 需求报告很长，短时间内评审者根本就不能把需求报告读懂，想清楚； ◇ 没有作好前期准备工作，需求评审的效率很低； ◇ 需求评审的节奏无法控制； ◇ 找不到合格的评审员，与会的评审员无法提出深入的问题；

……

<上述案例的原因分析>

3 问题所在：

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

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

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

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

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

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

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

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

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

建议一：分层次评审

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

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

功能性需求：定义了整个系统必须完成的任务；

操作性需求：定义了完成每个任务的具体的人机交互；

目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。

建议二：正式评审与非正式评审结合

正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。2种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这2种方式。

建议三：分阶段评审

应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。

建议四：精心挑选评审员