软考项目管理案例分析题过关必背.docx

软考项目管理案例分析题过关必背.docx

《软考项目管理案例分析题过关必背.docx》由会员分享，可在线阅读，更多相关《软考项目管理案例分析题过关必背.docx（10页珍藏版）》请在冰点文库上搜索。

软考项目管理案例分析题过关必背

软考项管和系统集成案例分析题万金油

项目沟通管理

发现问题

十九、缺乏对项目组成员的沟通需求和沟通风格的分析；

二十、缺乏完整的会议议程，会议目的、议程、职责不清、缺乏控制，导致会议效率底下，缺乏效果；

二十一、会议没有产生记录；

二十二、会议没有引发相应的活动；

二十三、沟通方式单一；

二十四、没有进行冲突管理。

二十五、未获得用户确认就实施了需求变更

二十六、分工不明确或者虽然有分工但没有落实

二十七、项目管理部门没有履行自己的全部职责

二十八、销售部门未能将正确的客户需求传递给研发部门

二十九、没有建立完善的需求管理的相关流程

如何解决问题

十五、首先应对项目组成员进行沟通需求和沟通风格的分析；

十六、对于具有不同沟通需求和沟通风格的人员组成设置不同的沟通方式；

十七、除了项目例会之外，可以通过电话、电子邮件、项目管理软件、OA软件等工具进行沟通；

十八、正式沟通的结果应形成记录，对于其中的决定应有人责任落实；

十九、可以引入一些标准的沟通模板；

二十、在项目组内培养团结的氛围并注意冲突管理。

二十一、需要和销售部门作清晰的确认

二十二、明确和销售部门的分工和权限，真正承担对外接口的角色

二十三、需求和客户进行细节的澄清和确认

二十四、将确认的需求正确地传递给研发部门

二十五、管理产品的需求变更

二十六、与研发部门进行验证，确保产品符合客户需求高效会议方案

一、事先制定一个例会制度；

二、放弃可开可不开的会议；

三、明确会议的目的和期望结果；

四、发布会议通知；

五、在会议之前将会议资料发到参会人员；

六、可以借助视频设备；

项目质量管理：

发现问题

一、没有为项目制定一个可行的质量管理计划并积极地实施之；

二、仅向用户提交测试报告而没有提交全面质量管理进展情况的报告，沟通方式单一、容易误导用户、容易导致客户/用户不必要的担心。

如何解决问题

相关理论性问答题

管理项目质量管理的基本原则：

1、质量就是满足客户需求；

2、项目全员参与、质量责任明确到人；

3、不许镀金；

4、预防胜于检查：

质量出自计划、设计和建造，而不仅仅出自检查；

5、质量应持续改进。

质量管理计划：

1、描述组织的项目质量管理体系，包括组织结构、责任、程序、过程和资源等；

2、确认所获得的各种控制、过程、设备、资源和技能；

3、设计、生产过程、安装、服务、检查和测量程序以及其他适应文档的兼容性；

4、必要时对质量控制、检测和测量技术等的更新；

5、识别出的测量要求，包括超出现有技术水平的能力、开发所需能力所需时间；

6、项目实施过程中特定阶段所需的适当的审核要求；

7、质量标准。

项目人力资源管理

发现问题

三十、缺乏足够的项目管理能力和经验；

三十一、身兼二职位，经历和时间不够用；

三十二、没有进入到管理角色，缺乏项目管理；

三十三、高级项目经理缺乏对新人的事先培训和全程的跟踪和监控；

如何解决问题

一、事先要制订岗位的要求、职责和选人的标准，并选择合适的人选；

二、高级项目奖励应对新人工作全面估算，提供必要的指导，解决稀缺资源；

三、要事前沟通、对新人明确要求、明确角色的轻重缓急，促使新人尽快转换角色；

项目范围管理：

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.项目经理在变更中的主要作用包括决定变更的接受或拒绝，组织变更的确认和结果发布。

（错）

进度管理

发现问题

九、销售部门没有及时让软件部门人员参加到项目早期工作，需求分析耗时长；

十、项目经理经验不足，进度估算不准确；

十一、项目资源配置不足，缺乏专门的系统分析人员和设计人员；

十二、工作安排没有充分利用分配的项目资源，资源有闲置；

十三、在安排进度时可能未考虑法定节假日的因素。

如何解决问题

八、向职能经理申请增加特定资源，特别是要增加系统分析设计人员；

九、临时加班、赶工，尽可能补救耽误的时间或提升资源的利用效率；

十、将部分阶段的工作改为并行进行；

十一、对后续工作的工期重新进行估算，并考虑节假日问题，修订计划，尽量留有余地；

十二、加强沟通，争取客户能够对项目的范围以及需求、设计、验收标准进行确认，避免后期频繁出现变更；

十三、加强对阶段性工作的检查和控制，避免后期出现返工；

十四、此外还有外包和缩减范围等办法，不在此案例考虑之内

相关理论性问答题

进度管理的过程：

一、活动定义。

把工作包一步步分解为活动，以方便进度管理。

活动定义的方法有分解、模板、专家判断等，主要输出是项目活动清单。

二、活动排序，确定各活动之间的依赖关系，并形成文档。

项目活动排序的工具和技术有前导图法、箭线图法、进度计划网络模板、确定性依赖关系等，主要输出时项目计划网络图。

三、活动资源估算。

包括决定什么资源和每一样资源应多少，以及何时使用资源来有效地执行项目活动。

它必须和成本估算相结合。

项目活动资源估算的工具和技术有专家判断法、替换方案确定、公开的估算数据、估算软件、自下而上的估算等，主要输出是活动资源需求。

四、活动历时估算。

活动历时估算直接关系到各事项、各工作网络时间的计算和完成整个项目任务所需的总时间。

项目活动历时估算的工具和技术有专家判断、类比估算法、基于定额的历时、历时的三点估算、预留时间、最大活动历时等，主要输出是定量的活动历时估算结果。

五、制定进度计划。

制定进度计划就是决定项目活动的开始和完成的日期。

制定进度计划的工具和技术有关键路径法、进度压缩、仿真、资源平衡、关键链、项目管理软件、编码结构、所采用的日历、超前和滞后、计划评审技术等，主要输出是项目进度计划。

六、进度控制。

项目进度控制是依据项目进度计划对项目的实际进展情况进行控制，使项目能够按时完成。

进度控制的工具和技术有进展报告、进度变更控制系统、绩效测量、项目管理软件、偏差分析、计划比较甘特图等，主要输出是进度计划（更新）、变更需求、建议的纠正措施、取得的教训。

资源对进度的影响：

在一般情况下，项目活动的历时与项目规模成正比，与投入的资源数量成反比。

即投入的资源数量越多，活动的历时越短。

但是要注意任何活动都具有压缩点，当活动的历时已达到自身的压缩点之后，增加再多的资源也无法进一步缩短活动历时。

在一个非关键活动的一个较大时间延误也许只对项目产生较小的影响或不产生影响，而在关键活动的较小延误也许就需要马上采用纠正措施。

因此每当缩短项目工期时，应当首先考虑在关键活动上增加资源，以加快进度缩短项目工期。

一、明确定义项目的工作分解结构。

二、由于是升级项目，所以部分工作的工期估计方法可以采用“类比估算法”

三、对于新增的移动接入模块，可以联系业界专家，采用“德尔菲法”进行估算

四、对于WBS进行足够细化后，可依据历史数据采用“参数估算”或“三点估算”进行进一步历时估算。

1、与客户进行沟通，梳理业务需求中的关键需求，与客户进行协商能否在期限前先完成关键需求，其他部分分期交付；

2、制定出合理可靠的技术方案，对其中不熟悉的部分，可以采用外包的方法；

3、清晰定义各功能模块之间的接口，然后可以加大并行工作的程度；

4、明确目标、责任和奖惩机制，提高员工的工作绩效；

5、必要时进行赶工。

一、基于WBS和工时估算制定活动网络图，制定项目工作计划；

二、建立对项目工作的监督和测量机制；

三、确定项目的里程碑，并建立有效的评审机制；

四、对项目中发现的问题，及时采用纠正和预防措施，并进行有效变更管理；

五、使用有效的项目管理工具，提升项目管理的工作效率。

变更控制管理

发现问题

十四、对用户的要求未进行记录；

十五、对变更请求未进行足够的分析，也没有获得批准；

十六、在修改过程中没有注意进行版本管理；

十七、修改完成后未进行验证；

十八、修改的内容未和项目干系人进行沟通

可能导致的问题

缺乏对变更请求的记录可能会导致产品的变更历史无法追溯，并导致对工作产品产物的整体变化情况失去把握；

缺乏对变更请求的分析可能会导致后期的变更工作出现工作缺失、与其他工作不一致等问题，对项目的进度、成本、质量方面也会产生一定的影响；

在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原，造成成本损耗和进度拖延，另一方面，对于组织财富和经验的积累也是不利；

修改完成后不进行验证则难以变更是否正确实现，未变更付出的工作量也无法得到承认。

未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处，进而影响项目的整体质量；

相关理论性问答题

变更流程：

变更申请，应记录变更的提出人、日期、申请变更的内容等信息。

变更评估:

对变更的影响范围，严重程度，经济和技术可行性进行系统分析。

变更决策：

由具有相应权限的人员或机构决定是否实施变更。

变更实施：

由管理者指定的工作人员在受控状态下实施变更。

变更验证：

由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。

沟通存档，将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。

如提出的变更在决策时呗否决，其初始记录也应予以保存。

项目整体及配置管理

发现问题

一、缺乏项目整体管理

二、缺乏整体变更控制规程

三、缺乏项目干系人之间的沟通

四、缺乏配置管理

五、缺乏整体版本管理

六、缺乏单元接口测试和集成测试

如何解决问题

一、针对目前系统建立或调整基线；

二、梳理变更脉络，确定统一的最终需求和设计；

三、梳理配置项及其历史版本；

四、对照最终需求和设计逐项分析现有配置项及历史版本的符合情况；

五、根据分析结果由相关干系人确定整体变更计划并实施；

六、加强单元接口测试与系统的集成测试或联调；

七、加强整体版本管理。

相关理论性问答题

一、制定配置管理计划。

确定方针，分配资源，明确职责，计划培训，确定干系人，制定配置识别准则，制定基线计划，制定配置库备份计划，制定变更控制规程，制定审批计划。

二、配置项识别。

识别配置项，分配唯一标识，确定配置项特征，记录配置项进入时间，确定配置项拥有者职责，进行配置项登记管理。

三、建立配置管理系统。

建立分级配置管理机制，存储和检索配置项，共享和转换配置项，进行归档、记录、保护和权限设置。

四、基线化。

获得授权，建立或发布基线，形成文件，使基线可用。

五、建立配置库。

建立动态库，受控库和静态库。

六、变更控制。

包括变更的记录、分析、批准、实施、验证、沟通和存档。

七、配置状态统计。

统计配置项的各种状态。

八、配置审计。

包括功能配置审计和物理配置审计。

更多软考考试资讯，请到希赛软考学院。