软件项目管理研究生考试.docx

资源描述

软件项目管理研究生考试.docx

《软件项目管理研究生考试.docx》由会员分享，可在线阅读，更多相关《软件项目管理研究生考试.docx（16页珍藏版）》请在冰点文库上搜索。

软件项目管理研究生考试.docx

软件项目管理研究生考试

注：

考生属哪种类别请划“√”

（博士、在校硕士√、工程硕士、师资硕士、同等学力、研究生班）

辽宁工程技术大学

研究生考试试卷

考试时间：

考试科目：

软件项目管理

考生姓名：

评卷人：

考试分数：

注意事项

1、考前研究生将上述项目填写清楚

2、字迹要清楚，保持卷面清洁

3、试题、试卷一齐交监考老师

4、教师将试题、试卷、成绩单，一起送研究生学院；

专业课报所在院、系

软件项目管理案例分析报告

随着信息技术的飞速发展，软件产品的规模也越来越庞大，个人单打独斗的作坊式开发方式已经越来越不适应发展的需要。

各软件企业都在积极将软件项目管理引入开发活动中，对开发实行有效的管理。

从概念上讲，软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。

实际上，软件项目管理的意义不仅仅如此，进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展。

在软件项目中有两条非常重要的线索，一条是软件项目开发过程，另外一条是软件项目管理过程。

通常，人们容易注意软件项目开发过程，而忽略软件项目管理过程的线索。

事实上，后者很重要，有时其重要性甚至超过项目开发过程。

项目管理可以让一个项目获得高额的盈利也可以让一个项目损失惨重，而编码的影响力则相对小一些。

现实中由于出色的项目管理，将已经亏损很严重的项目又重新扭亏为盈的例子并不少见。

本次报告用已有的实际案例实践分析软件项目管理过程，带着我们从总体来把握软件项目管理的应用，并就笔者本人了解的以及课上笔记记录的软件项目管理理论对案例进行分析。

这样可以使我们更加深入的了解并更好的应用软件项目管理理论。

用案例实践理论——浪潮山东出入境业务管理系统项目

软件开发是难以预知的过程，它是一个产品从无到有的创造过程。

这个结果是让人感到兴奋和有趣的，但是它的过程就没有那么轻松了。

软件开发的特点就是创造性！

我们要做的就是要实现我们期望的某种功能，而此前又没人做过的东西（除非是自己的案例学习，或者是盗版…在这里不是我们讨论的话题）。

软件项目的这个特点使得它具有了许多不确定性，这也使得软件项目管理不同于其它的各种管理。

也是产生软件项目管理中一些个性问题的一个原因。

2005年7月，浪潮软件拿下了这个项目。

这个系统的旧版本也是浪潮软件做的，但是到这个时候原班人马大多离职，留下的书面材料也很少。

为了应对新项目，事业部东拼西凑了一个10人的项目组开始工作。

2个月后，项目组成员借口天天加班要求增加待遇，未果，项目迟迟没有进展。

8月份，公司将该项目转入行业应用事业部，由原本做烟草行业软件的一个团队接手。

这是一个年轻的队伍，但干劲很大，客户也重燃希望，对项目给予充分重视，派人进驻项目组，一则随时确认需求，二则督促项目进展。

由于采用了一种新技术，初期项目进展顺利，很快拿出核心系统的初步版本，但客户组织评审后发现距离实际要求差异很大，随后进入了无休无止的需求变更阶段，项目预算大大超标。

离系统预定上线时间越来越近，项目组几乎没有时间休息，加之客户方人员对工作指手画脚，双方矛盾日趋激化，尤其是年轻的项目经理虽然是个技术高手，但项目管理经验欠缺，年少气盛的他终于忍无可忍，和客户大吵一架。

客户马上找到公司领导，要求撤换项目经理。

几经协调，事件终于平息，但上线时间一拖再拖。

07年9月，系统终于上线了，但却发现运行速度奇慢，出入境办证大厅人满为患，前来办证的人怨声载道，投诉不断。

出入境的领导急了，找到浪潮领导说如果不尽快解决系统性能问题，他就派人把浪潮门口的路封了。

因为这个案例几乎囊括了所有在软件项目管理中可能会出现的问题并以此给出延伸的案例问题分析。

包括：

团队配置管理问题（人员沟通管理问题）：

原班人马大多离职，留下的书面材料也很少。

成员天天要求加薪未果，项目迟迟没进展。

沟通问题的重要性，也许读者对它的印象还不够深刻，但是它又软件项目管理中的一个重要的个性问题，所以我们有必要把它也当做一个重点来写。

为什么这样说呢，因为软件开发项目的主要资源为人，它往往是要做某个东西的人请另外的一些人帮他们做，我们可以这样通俗地解释：

需要这个东西的人（我们成他为客户）他也许知道自己想要的是怎么样的，但是他也许不知道怎么做这个东西。

做这个东西的人（开发团队）也许知道怎样做，但是他们不明确客户想要的到底是怎样的。

而解决这个问题的方法只有沟通。

此外，软件开发是一个脑力密集型工作，它的成果是需要聚集每一个开发团队成员的想法和智慧。

对于一个大型项目来说，如果团队成员之间不能够进行良好的沟通，把他们的思想融汇到一起，也是难以得到一个完好的成果的。

因此，在软件项目管理中，沟通管理也是一个需要我们足够重视的个性问题。

沟通的好坏将直接影响到软件的质量，甚至软件的成败。

沟通问题解决之道

项目沟通计划是项目整体计划中的一部分，它的作用非常重要，也常常容易被忽视。

经常出现的问题是项目经理凭自己的经验进行口头安排与交待，项目成员按经理的指示被动地、应付式地完成信息沟通工作。

这种问题的原因主要是项目计划阶段项目经理嫌麻烦或不重视没有进行严格的沟通计划。

一种高效的体系不应该仅仅靠口头传授，落实到规范的计划编制中很有必有。

在软件项目管理中，项目干系人众多，没有沟通管理计划，沟通必然混乱。

计划前，团队里应建立起一种相对稳定的、可以重复执行的沟通管理计划，只要能训练成员重复执行，沟通过程必然能逐渐演化和成熟，沟通就有实现可管理的可能。

在软件项目管理中，项目经理应在沟通中担任主持协调者，调解人，聆听者，解释者等诸多角色。

我们可以借助microsoftproject2003作为辅助沟通工具，并通过灵活运用多种沟通方式，直接与项目组成员沟通，避免中间环节，发展良好的沟通技能，善于运用倾听和反馈，召开高效的项目会议等方法和策略进行项目沟通管理。

可以采用的沟通方法有：

1、会议沟通。

这个是一个成本比较大，但是很有效的方法。

通常可以借助它来解决比较重大，复杂的问题。

2、E-mail沟通。

可以用它来解决一些较小的问题，或者资料数据的交流。

特别适用于团队成员内部交流。

3、口头沟通。

这种沟通方法往往能加深彼此之间的友谊，加速问题的冰释。

适用于项目经理与客户之间的沟通。

4、电话沟通。

比较常用而经济的沟通方式。

或许还有其它的一些沟通方式，但是上面这几个是比较有效而且比较适用的方法。

我们可以借助它们来解决软件项目管理中的沟通问题。

这些问题也许在项目进行前很多都预料不到会发生，但是项目一开展，各种问题就出现了。

而这些问题的出现并不是没有预防办法、解决办法。

但是这里举出这个案例并不是要我们深入去研究它，因为我们不能通过研究这个案例就能学到应付所有软件项目管理中的问题的办法，因为其他案例很大可能出现与这里不一样的问题。

我们举这个例子的目的有：

1、说明软件开发的不确定性引发软件项目管理中会出现的各种个性问题。

2、说明软件项目管理主要包括哪几个内容。

3、引出软件项目管理中的个性问题以及他们的解决之道的话题。

上面的案例中出现的问题仅仅是软件项目管理中个性问题的一些实例体现。

本文将从以下几个比较重要的几点讲软件项目管理的个性问题以及相应的解决方法。

需求管理问题：

软件系统进入了无休止的需求变更阶段。

需求不确定性

软件的研制是一种人的智力创造，软件的产品是一种信息的产品,是无形的。

人的认识过程是不断深化的。

所以，在一般情况下，当客户在看到软件最终产品之前是无法判断其是否是所希望的软件产品，一旦他看到最终产品时才发现与自己的期望相差甚远。

它的原因可以归结为以下几点：

1、用户的需求可以分为三个层次，即：

基本的需求、预期的需求和兴奋的需求，其中预期的需求是明示的，而基本的需求和兴奋的需求往往是非明示的。

所谓兴奋的需求是指这些特征在用户的期望范围之外，并且当其存在时将是非常令人满意的。

2、即使是用户明示的需求，往往因应用领域与用户问题的多样性和复杂性，用户在表述需求时常常带有不确定性与模糊性的因素。

3、随着开发进程的推进，用户对所建应用系统理解的不断深入，对原来模糊的或非明示的需求有了新的认识，随时会提出需求的变更，因此需求的变更具有不可预测性。

4、用户要求的实效性和多变性，以及用户所描述的需求本身具有内在的矛盾及其潜在的冲突性，由于开发人员的领域知识的局限性，导致引发需求的误解。

5、用户需求的获取过程与描述形式往往采用非形式化的自然语言，以及自然概念中存在的本质矛盾，使需求的规范描述发生困难。

6、需求分析方法论和分析工具的缺乏，及其应用范围的局限性，也影响着需求的准确性和需求变更的可控制性。

因此，用户需求的不确定性是客观存在的，是不可避免的。

需求不稳定性

解决需求不稳定性的传统方法有采用瀑布式开发模型，快速模型等。

瀑布模型为软件开发和维护提供了一种有效的管理框架，它在消除非结构化软件、降低软件的复杂度、促进软件的工程化方面起着显著的作用，以至于它广为流行。

但是，它并不能有效的解决软件需求不明确或者不正确的问题，缺少解决这些问题的灵活性。

用户常在软件开发完成后才发现所开发的系统不是他们所需要的，由此引发的项目返工和纠正花费高额带价。

快速模型是为了弥补瀑布模型的不足提出的，它针对需求获取的的初级阶段往往不够清晰的情况，将开发活动分成为建立模型和实现最终软件的两个阶段。

建立原型阶段作为试验开发，快速地建立一个待开发软件的原型系统，然后请用户对原型系统进行评价并对软件需求提出修改或确认，这种修改或确认可能会反复多次；实现最终软件阶段是根据最终确认的软件需求，设计和实现软件的最终系统。

显然，原型开发方法在克服瀑布模型缺点、减少由于需求获取的初始阶段软件需求不明确而给开发工作带来风险方面,具有显著效果。

但是，快速原型技术仅解决了初始阶段的需求获取问题，没有解决实现最终软件阶段的需求变更的问题，其原型的适应性和可信度存在一定的问题。

软件发开模型不能很好的解决需求不稳定性的问题。

但是我们可以辅以项目管理的方法来更好的解决它。

在没有建立软件过程管理的软件开发组织中,主要的管理手段是实施项目管理,项目管理的好坏是项目成功的关键。

项目的生命周期分为识别需求、提出解决方案、执行项目和结束项目四个阶段。

识别项目的需求和界定项目的范围是建立项目计划的关键。

项目计划实施过程中必须强调反馈和控制,跟踪项目的需求源,对项目需求的变化进行控制。

同时,项目经理一定要向客户强调一点,项目成功不是开发方努力就可以了,它必须要有客户的紧密合作，把需求的不确定因素纳人项目管理的全过程中。

针对浪潮软件出入境管理系统需求变更时期无休止的情况,课堂上老师也说了,解决这样的问题的方法还有,在项目实施前先跟客户进行足够的沟通,可以事先签署有关需求变更额度的合同,在项目进行的时候双方都遵守这个合同,这可以有效的解决需求变化大和混乱的问题。

我觉得这个也是一个可以帮助解决需求不确定性的方法，也适用于其它软件开发项目。

成本管理问题：

项目预算大大超标。

软件开发是一个难以预知的过程，要给一个未知的，从未进行过的工程进行成本估算，这并不是一个简单的问题。

成本估算的困难很多有一个很重要的原因，那就是软件开发的隐性成本高。

所谓的隐性成本，是指在项目预算时并没有将其考虑在内，但它确实在将来的开发活动中会导致额外的成本开销。

一个软件项目的阶段性完成并不意味着它不会带来后续的成本，因为不同的实现（实现不具唯一性）所带来的软件稳定性和可维护性都将不同，而不良实现所带来的隐性成本往往在预算时无法合理地被考虑，这进一步又意味着什么呢？

第一，它将导致对项目进行计划更困难。

这是显然的，因为看不到隐性成本的存在，自然在计划时不会将其列入其中。

第二则更为严重，由于隐性成本的不可见性，往往很容易造成被忽视，进而不能掌握软件开发的特点，对软件开发中的困难也表现得不理解。

甚至一味地认为只要投入时间和人力就一定能开发出高质量的软件产品，孰不知很有可能因为更多的投入而造就更大的隐性成本。

隐性成本的存在往往很容易导致工程师因为工作而影响生活，而进一步带来更大的隐性成本。

试想，应该没有某个项目在预算时将工程师的生活质量真正地考虑在内，即使有，这种考虑或许也没有考虑到点子上。

成本估算难题解决之道

解决成本估算难题，我们可以采用下面的三种方法，要想使软件开发成本估算问题得到良好的解决，它们都是必须考虑的，具体如下：

1、评估应细致，全面，可参考类似项目的成功案例。

2、适用专业水平高的评估人员进行质量评估。

3、沟通很重要。

软件的隐性成本高是导致成本估算难题的一个重要原因。

因为隐性成本是不可见的，但是它又是存在的，所以我们必须进行细致的评估。

一个表面上好的软件其设计未必就好，而设计不好则早晚会出问题，从而带来隐性成本。

所以，我们也很需要一个专业的质量评估。

这里所说的专业水平不能简单地理解为评估人具有什么样的学历，或通过了什么样的认证，而是需要他对软件行业有深刻的理解和丰富的经验，以及拥有自己的软件设计思想。

通常这类评估人也应当对于软件设计有着精神上的追求（否则他的水平也不会高到哪），很显然这种人是一种稀缺资源！

设计质量评估所需的专业性也正是因为实现不具唯一性这一特点所造成的，合格质量评估者的缺乏使得质量评估变得更加困难。

一个开发团队，如果不具备胜任的质量评估者，则很有可能整个团队在开发过程中不知道软件质量的真实状况，而只是停留在关注被发现的缺陷之上，进而无法涉及质量问题的核心—不良设计。

真正高水平软件工程师的缺乏也加剧了软件行业的困难，由于缺乏这些“领头羊”，项目组在开发过程中无法有目的地朝着高质量设计的方向前进，而只能是以完成工作为目标。

结果很有可能是项目组多走弯路，以及项目面临更高的隐性成本。

此外，沟通在成本估算中也是很重要的，前面也有说道，隐性成本的存在往往很容易导致工程师因为工作而影响生活，而进一步带来更大的隐性成本。

试想，有哪个项目在预算时将工程师的生活质量真正地考虑在内，即使有，这种考虑或许也没有考虑到点子上。

所以，我们需要团队内的多沟通才能帮助解决这个问题。

风险管理问题：

项目经理和客户大吵一架，客户要求撤换项目经理。

任何项目都有一定的不确定性，如果没有很好的风险管理，项目就可能遇到麻烦。

所以，软件项目管理过程中，风险计划同样必不可少。

风险管理中常用的工具是TOP10风险清单，它是通过一系列的风险识别、风险评估、风险规划得到的。

由于笔者在课上讲述的风险控制，所以在此对其做较详细介绍。

图1显示了风险控制的总体分支。

图1风险控制总分支图

下面对各个分支进行详细介绍。

风险管理计划

将风险管理计划和标准项目管理过程结合，确保计划的执行；把风险管理计划的任务安排到项目进度表中。

风险化解

避免风险；将风险从系统的一部分转移到另一部分；购买关于风险的信息；消除产生风险的根源；接受风险；发布风险；控制风险；记住风险。

具体遵循的化解办法见表1。

表1常用的风险化解办法

风险

化解方法

功能蔓延

基于客户，控制功能集，针对变更的设计

需求镀金或开发人员镀金

修正需求，时间锁定，阶段交付，基于进度表

质量不定

给QA留出时间，注重质量保证基础

计划过于乐观

采用多估算实践，基于进度表，增量开发

设计欠佳

清晰设计活动，足够设计时间，进行设计检查

银弹综合症

建立软件度量计划，建立软件工具库

研发导向的开发

不要试图进行研究的同时使开发速度最快

人员薄弱

招募，培训，团队建设

签约商失败

检查参考资料，分析承包能力，管理承包商

研发人员与客户的摩擦

将客户纳入项目组中

风险监控

不断的识别新的风险；不断的分析风险的产生概率；不断的整理风险表；不断的规避优先级别最高的风险。

监控因素

项目组成员对于项目压力的一般态度；项目组的凝聚力；项目组成员彼此之间的关系；与报酬和利益相关的潜在问题；在公司内和公司外工作的可能性；文档。

下面依照上述的具体事例说明风险控制。

风险管理计划

风险管理计划见表2。

表2风险管理计划表

风险

类别

概率

影响

排序

项目经理管理经验不足