信息系统项目管理师案例经验总结教案.docVIP

A项目范围管理 1．范围管理中存在的问题 a. 没有制定范围管理计划并按照计划管理，或领导的部署不能代替范围管理计划 b. 需求阶段结束后未对需求进行正式评审或项目的范围未得到客户的确认，或领导的批准 不能代替范围确认 c. 范围的定义和分解时未包含分包出去的工作，或分包出去的工作未纳入范围管理计划进 行管理 d. 对领导提出的变更要求未形成书面记录 e. 领导提出变更要求后，未对变更产生的影响进行充分的评估便实施了变更 f. 变更请求应由变更控制委员会审批，不应由项目经理独自决定 g. 项目经理缺乏和领导以外的公司其他用户的沟通 2．后续可采取的应对措施 a. 制定项目范围管理计划，按照计划管理和控制项目的范围 b. 组织公司用户代表对系统的需求进行评审，对项目的范围进行确认 c. 加强和分包单位的联系，将其纳入项目的计划和范围控制 d. 按照变更流程处理包括领导在内的公司所有用户提出的变更请求 e. 加强后续项目的范围控制工作 3．简要叙述产品范围和项目范围的区别和联系 a. 产品范围是表示产品、服务或结果的特征和功能； b. 项目范围是为了完成具有规定特征和功能的产品，服务或成果而必须完成的项目工作 c. 项目范围包含产品范围，还包含产品范围所不包含的项目管理工作本身。 4. 判对错 a. 范围控制的目的是避免项目做过多的工作，即避免项目范围扩大 （错） b. 变更控制委员会是决策机构，不是职能机构，其组成人员可以是一人，甚至是兼职人 员 （对） c. 范围确认也叫范围核实，是项目组成员根据项目管理计划对项目的计划工作进行逐一 检查和落实的过程。（错） d. 项目范围管理的目标是“圈定”项目的范围，产生全面、准确、可实施的范围说明书。 e. 范围确认与质量控制不同，范围确认一般在质量控制之前完成，也可以并行进行。（错） f. 项目经理在变更中的主要作用包括决定变更的接受或拒绝，组织变更的确认和结果发布。（错） B项目整体及配置管理 1.发现问题 a. 缺乏项目整体管理 b. 缺乏整体变更控制规程 c. 缺乏项目干系人之间的沟通 d. 缺乏配置管理 e. 缺乏整体版本管理 f.缺乏单元接口测试和集成测试 2.如何解决问题 a. 针对目前系统建立或调整基线； b. 梳理变更脉络，确定统一的最终需求和设计； c. 梳理配置项及其历史版本； d. 对照最终需求和设计逐项分析现有配置项及历史版本的符合情况； e. 根据分析结果由相关干系人确定整体变更计划并实施； f. 加强单元接口测试与系统的集成测试或联调； g. 加强整体版本管理。 3.相关理论性问答题 a. 制定配置管理计划。确定方针，分配资源，明确职责，计划培训，确定干系人，制定配置识别准则，制定基线计划，制定配置库备份计划，制定变更控制规程，制定审批计划。 b. 配置项识别。识别配置项，分配唯一标识，确定配置项特征，记录配置项进入时间，确定配置项拥有者职责，进行配置项登记管理。 c. 建立配置管理系统。建立分级配置管理机制，存储和检索配置项，共享和转换配置项，进行归档、记录、保护和权限设置。 d. 基线化。获得授权，建立或发布基线，形成文件，使基线可用。 e. 建立配置库。建立动态库，受控库和静态库。 f. 变更控制。包括变更的记录、分析、批准、实施、验证、沟通和存档。 g. 配置状态统计。统计配置项的各种状态。 h. 配置审计。包括功能配置审计和物理配置审计。 C进度管理 1.发现问题 a.销售部门没有及时让软件部门人员参加到项目早期工作，需求分析耗时长； b.项目经理经验不足，进度估算不准确； c.项目资源配置不足，缺乏专门的系统分析人员和设计人员； d.工作安排没有充分利用分配的项目资源，资源有闲置； e.在安排进度时可能未考虑法定节假日的因素。 2.如何解决问题 a. 向职能经理申请增加特定资源，特别是要增加系统分析设计人员； b. 临时加班、赶工，尽可能补救耽误的时间或提升资源的利用效率； c. 将部分阶段的工作改为并行进行； e. 对后续工作的工期重新进行估算，并考虑节假日问题，修订计划，尽量留有余地； f. 加强沟通，争取客户能够对项目的范围以及需求、设计、验收标准进行确认，避免后期频繁出现变更； g. 加强对阶段性工作的检查和控制，避免后期出现返工； h. 此外还有外包和缩减范围等办法，不在此案例考虑之内 3.相关理论性问答题 进度管理的过程： a. 活动定义，把工作包一步步分解为活动，以方便进度管理。活动定义的方法有分解、模板、专家判断等，主要输出是项目活动清单。 b. 活动排序，确定各活动之间的依赖关系，并形成文档。项目活动排序