项目管理与评价作业

2015 年春季学期研究生课程考核（读书报告、研究报告）考核科目:项目管理与评价学生所在院（系）:X X X学院学生所在学科:X X X学生姓名:学号:学生类别:考核结果阅卷人第 1 页（共9 页）一、选择一个你所了解的项目, 结合所学课程内容分析该项目成功经验或失败的教训。

1.项目概况M集团是希赛信息技术有限公司(CSAI )多年的客户，CSAI已经为其开发了多个信息系统。

最近，M又和CSAI签订了新的开发合同，以扩充整个企业的信息化应用范围，张工担任该项目的项目经理。

张工组织相关人员对该项目的工作进行了分解，并参考了公司同M曾经合作的项目，评估得到项目，总工作量60人月，计划工期6个月。

项目刚刚开始不久，张工的高层经理S找到张工。

S表示，由于公司运作的问题，需要在4个月内完成项目，考虑到压缩工期的现实，可以为该项目在增派两名开发人员。

张工认为，整个项目的工作量是经过仔细分解后评估得到的，评估过程中也参考了历史上与K企业合作的项目度量数据，该工作量是客观真实的。

目前项目已经开始，增派的人手还需要一定的时间熟悉项目情况，因此即使增派两人也很难在四个月内完成。

如果强行要求项目组成员通过加班等方式追逐4个月完成的目标，肯定会降低项目的质量，造成用户不满意。

因此，张工提出将整个项目分为两部分实现，第一部分使用三个半月的时间，第二部分使用三个月的时间，分别制定出两部分的验收标准。

这样，不增派开发人员也可以完成。

高层经理认为该方案可以满足公司的运作要求，用户也同意按照这种方案进行实施。

六个月以后，项目在没有增加人员的前提下顺利地完成，虽然比最初计划延长了半个月的工期，但既达到了公司的要求，客户对最终交付的系统也非常满意，项目组的成员也没有感受到很大的压力。

2.项目分析这是一个成功的项目管理案例，项目经理张工有效的运用范围管理，在不同的项目干系人中达成一致，使项目的结果同时满足了高层经理、客户和项目组成员的要求。

作为一个项目管理者，必须熟练掌握和应用项目管理九大领域涵盖的知识与技能，对于进行信息系统开发项目而言，范围管理是其中最重要的技能之一。

软件项目的范围主要是由系统需求构成的，而系统需求既是难以把握的，也是容易调整和控制的。

软件系统的需求来源于用户需求，在软件项目目标是满足用户需求的情况下，对于相同的用户价值可以定义出不同的系统需求。

举一个简单的例子，用户的需求是“解决口渴的问题”，那么最简单的系统需求可以是递上一杯水，复杂一些的可能是递上一杯热水，更复杂的是递上一杯经过多层过滤的纯净水，当然也可以是打一桶虎跑泉的水，然后沏上一杯龙井茶。

用户当然希望用买矿泉水的钱换一杯正宗的龙井茶，但这样的项目范围肯定会导致项目失败。

聪明的软件项目经理总是从范围管理开始，先界定系统的边界，然后再在明确的范围内进行时间、成本、风险等的管理。

在项目中，时间、成本和范围构成了一个稳固的三角形，如图1所示。

范围图1对于该三角形来说，任何一边都不可能孤立地改变。

换句话说，我们不可能固定其中两边而试图缩短第三边。

其实这也是很容易理解的问题，如果项目需要做的东西已经确定(项目范围固定)，项目的人员也已经确定(项目成本固定)，那么项目需要的时间就也是固定的。

同理，已经固定的项目投入和项目时间也只能做出固定的工作。

对于这个三角形而言，非但不可能孤立地改变某一边的长短，就是三边的变化比例不一致也不可能。

不成比例的变化与孤立的改变某一边是一样的，都将破坏三角形的结构，违反项目的客观规律，最终招致失败。

因此有效的范围管理更像一门艺术，可以帮助项目经理在已经确定的时间和成本下完成项目目标。

在本案例中，高层经理S就提出了试图打破这个三角形的要求。

他要求，项目组可以增加部分资源，但要提前两个月完成。

初一看，并没有在不增加投入的情况下要求项目提前完成，似乎合情合理，比起既要马儿跑又不让马儿吃草的要求好得多，但细一想，增加的资源和提前的时间还是不成比例。

项目经理张工深知此中奥妙，因此在听到高层经理的要求后，马上意识到这是一个不可能完成的任务。

那么该如何解决这个矛盾呢？还是要从这个三角形入手。

既然时间和资源的变化已经打破了项目规律，那么不妨根据新的时间和资源来重新划定合理的项目范围，保证项目的正常运作。

于是，张工将这个项目拆分为两部分，重新定义这两部分的项目范围，使每一部分的范围都可以与已经确定的资源和时间匹配起来，让项目的运作又重新满足了项目的客观规律，最终取得了成功。

在案例中，还有一些细节需要考生注意。

张工最初估算整个项目需要花费60人月的总工作量，但如果考虑到拆分为两个阶段后会增加设计的复杂度，增加了额外的验收过程等因素，超出原计划半个月是正常的。

计划在6个月内完成。

在把项目拆分后，实际是用了6个半月的时间，也就是花费了65人月完成了项目。

对于上面介绍的时间、成本和范围的关系而言，仅是在理想情况下成立，即项目成员始终能以固定的成本完成固定的工作。

而在实际情况下，项目的工期、复杂度等因素都会对项目造成影响。

在案例中，虽然看似两部分工作的总和等于没有拆分前的项目，但这仅对于最终目标而言，拆分后的项目增加了若干中间成果，项目的范围实际上还是扩大了。

因为软件项目的范围直接与需求相关，所以，很多人误认为控制项目范围就是控制需求，而控制的方法就是减少需求的内容。

这种理解是完全错误的。

范围控制体现在软件开发的各个阶段，很多范围控制并非是针对客户的要求而进行的。

例如，本案例中，范围控制就是针对高层经理的要求进行的。

再比如，在设计中，我们既可以设计刚刚够用甚至略有欠缺，通过牺牲系统的扩展性、维护性等方面来简化设计，也可以对系统进行充分良好的设计，甚至可能是过度设计。

采取哪一种设计策略也是软件项目范围管理的一部分。

项目经理可以根据目前的项目的目标与环境出发，综合考虑质量和成本的约束，制定明确的项目范围，保证项目的成功。

根据笔者的经验，即时需求已经确定，通过有效的范围管理仍能给项目带来很大的收益，可以在不牺牲软件质量的前提下通过范围管理来降低项目成本，缩短项目工期。

上面主要针对张工在范围控制方面进行了分析，实际在整个案例中，张工还进行了其他的范围管理工作。

首先，在项目刚刚开始，张工就对项目范围进行了定义，进而划分了WBS 并对项目进行了估算和计划。

在S提出需要缩短工期的要求后，张工首先进行了项目范围的控制，缩小了第一步需要完成的项目范围。

紧接着张工又对两阶段需要完成的项目范围进行了重新定义，制定了验收标准。

最后，张工对重新定义的范围进行了确认，与客户和高层经理达成一致。

对于项目而言，仅仅管理范围仍不能保证项目的成功。

在这个案例中，张工也运用了其他的管理手段。

其中包括，张工对项目进行了估算，这属于项目时间管理的范畴；张工协调了多个项目干系人之间的矛盾，这属于沟通管理的范畴。

3.总结与启示这是一个成功的项目管理案例，项目经理张工有效的运用范围管理，在不同的项目干系人中达成一致，使项目的结果同时满足了高层经理、客户和项目组成员的要求。

项目经理首先对最初的项目范围进行了清晰的定义，并根据定义对工作进行了分解，制定了WBS。

项目经理对项目进行了估算，且估算结果真实可信，对项目工作量有量化的把握。

在出现新的项目目标后，项目经理对项目进行了范围控制，缩小了第一阶段实现的范围。

项目经理对重新定义的项目范围进行了确认，与高层经理和客户达成一致。

项目经理对项目进行了沟通管理，协调了多个项目干系人之间的矛盾。

二、假设你要上一个项目，简要描述一下拟开展的项目，并分析一下对该项目进行评价与管理的重点。

拟开展的项目某地区政府部门拟建设一个面向综合性网络应用系统，对现有的分布在各个服务器上的多个管理系统和服务平台进行重组和整合，整个项目由政府的信息部门统一负责统一规划、分期建设，由各个共建单位的主要领导组成了领导小组，招标了某IT技术公司负责承建该应用系统。

评价与管理的重点需求分析大致可分成三步来完成。

(1)需求信息的收集。

(2)需求信息的分析整理，对收集到的信息要做分析整理工作。

(3)需求信息的评审。

开发过程中的每一个阶段都要经过评审，确认任务是否全部完成，避免或纠正工作中出现的错误和疏漏。

需求评审通过，产生规格说明书是需求分析阶段结束的标志，评审可能导致需求分析过程回溯，甚至会反复多次。

但是，一定要使全部的预期目标都达到，才能让需求分析阶段的工作暂告一个段落。

从客户角度而言，识别需求是项目启动过程和整个项目生命周期的最初活动，客户通过识别商业或市场需求、机会、确定投资方向和项目机会，在这个过程中，将给项目的目标确定、可行性分析和项目立项提供直接、有效依据，为需求建议书的撰写提供基础。

从承建方的角度而言，识别需求是得到客户的需求建议书，或只是得到客户初步需求意向后，项目团队从技术实现、应用和项目实施角度识别客户的实际存在的问题、基本意图和真实想法，从而达到与客户有效的沟通，准确分析需求和问题，为制订可行、合理、正确的技术及实施解决方案提供依据。

在软件项目开始启动的初期，用户会向开发方提交需求描述，内容包括：目标产品的工作环境描述及用户对目标产品的初步展望，其目的仅在于向开发人员解释其需求。

需求规格说明书与需求描述完全不同，它是由开发人员经需求分析后形成的软件文档，其内容更为系统、精确和全面。

软件测试是有计划、有组织和有系统的软件质量保证活动，而不是随意、松散、杂乱地实施过程。

为了规范软件测试内容、方法和过程，在对软件进行测试之前，必须创建软件测试计划。

软件测试计划是指导测试过程的纲领性文件，包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。

借助软件测试计划，参与测试的项目成员，尤其是测试管理人员，可以明确测试任务和测试方法，保持测试实施过程的顺畅沟通，跟踪和控制测试进度，应对测试过程中的各种变更。

试阶段的划分应该与开发阶段划分相对应，如需求分析相对应的是确认测试，与概要设计相对应的是集成测试，与详细设计相对应的是单元测试。

测试也就是模块测试。

通常被放在编码阶段，由程序员完成这个模块后对他自己写的模块内代码进行测试，检查它是否实现了详细设计说明书中规定的模块功能和算法。

单元测试是验证详细设计(各个模块)正确性的测试，通常由开发组成员的自测和交叉测试完成。

一般的测试流程为：编写软件单元测试说明，执行软件单元测试，编写软件单元测试报告。

除了单元测试，还有集成测试和确认测试。

集成测试又称组装测试，是在开发环境下，验证概要设计正确性的测试。

集成测试按照测试计划和用例，由测试组成员完成。

确认测试是在运行环境下，由用户参与验证需求规格说明书的正确性的测试，主要测试软件功能与用户需求是否一致。

项目时间管理项目管理的首要任务是制定一个构思良好的项目计划，以确定项目的范围、进度和费用。