软件项目风险管理研究

软件项目风险管理研究（精选8篇）

软件项目风险管理研究 篇1

摘要： 阐述了软件项目风险的概念和风险定义，并且分析了在软件项目中的风险类型，最后根据风险的定义和类型，分析出相应的风险避免措施。

关键词：风险的概念；风险定义；风险类型；避免措施；

The Analysis Of Software Project Risk

WengHuaBin 10703080227

（ChongQing University Of Technology-Software Engineering）

Abstract: Describes the concept and definitions of software project risk ,And analyzed the types of software projects risk ,Finally, according to the definition and types of Software project risk analysis to avoid the risk of the corresponding measures.Key words: The concept of risk;The definition of risk;The risk types;The avoid measures;

软件行业在社会各界（包括政府、教育机构以及各个企业）的日益剧增的信息化需求下，已经成为高速信息化建设中必不可少的一个元素。所以软件行业要不断的提高稳定程度和运行效率，然而软件项目本身就是一个高风险的项目类型，任何项目都是存在一定的风险性，软件项目更是不例外，所以软件项目需要更好的风险避免措施，只有做到更好更科学的防御措施，才能在最大程度上降低软件项目成本和提高软件项目的成功率。再者，国内外的一些成功的软件项目案例告诉我们，软件项目风险分析是一个相当重要不容忽视的环节，只有做好了软件项目风险分析才能致使软件项目成功地进行，得到用户满意的软件，这也是众多软件公司的最终目的，所以科学的风险分析和必备的防御措施是一个好的软件项目的先决条件。软件项目风险概念

首先，我们知道任何项目都是有一定的不确定性和风险性，然而，软件项目是一个风险 比较大的项目种类，所以总而言之，零风险的项目基本上是不存在，项目中的风险分为多种类型的，只是我们在遇到风险的多少、大小以及严重程度是不同的。

再者，我们分析一下，在软件项目中，我们一般遇到的软件项目风险是怎么样的。在软件项目风险分析中，基本上所有的软件项目管理者都会很大程度上地关注软件项目的进展程度、完成情况以及对成本的控制等等，但是我们必须不可以忽视的问题是我们在项目进行当中遇到的风险，这些风险虽然一时半会可能会隐藏于软件开发中，但是一旦这些问题暴露出来，就会给软件项目带来不可挽回的灾难，任何一个技术人员、管理人员的一个失误或者软件开发中的任何一个负面的因素都有可能成为软件项目成功的威胁，所以我们不能忽视任何的失误，更不能忽视任何一个可能的风险。然后在我们的软件项目中，有可能就是因为一种侥幸的心理往往让我们得不偿失，因为风险本来就是一个不及时出现而又可能本质存在的客观因素，所以我们说它是一种潜在的风险，但是当它真正威胁到我们的时候，也就是我们发现风险存在的时候，这个时候它已经给我们带来了很大的麻烦，并且严重的有可能是不能挽回的损失，所以作为一个软件项目技术人员或者管理人员，我们都应该及时的关注软件的发

展进度，并且的不断的尝试有可能出现的风险的分析。

所以，我们要对软件项目进行规划来查找可能的风险，这样软件项目的期望值才会由低变高，进行了风险分析，这样软件项目的成功率也会大大提高，根据成功软件项目的经验和失败软件项目的教训，我们得知成功的软件项目都必须采取积极的步骤对要发生或者有可能存在的风险进行分析，从而才可能采取有效的措施避免软件项目的失败。软件项目风险定义

风险是潜在的对软件项目的威胁，未来可能发生损失的一种度量，当然也有可能不发生，但是一旦这种危险出现了，就会对软件项目带来很大甚至不可估量的损失，也是对公司的一种负面消极影响。软件项目风险是是未来的一种关注，本来风险就是不确定性的，所以这种潜在的危险就给开发过程中带来了各种决策的选择，另，风险还和人为因素（例如思想、行为）和环境因素（例如时间、地点）有关，等等这些因素都会导致软件项目的风险，所以在对软件项目进行分析的时候这些因素都是不容忽视的。

软件项目风险一旦出现就会影响软件的开发进度、成本，这些都可能导致最后的软件项目的失败，这些都应该是软件项目组所关心的重点。在软件项目的开发过程中，我们都知道现在软件行业的技术是日新月异的，所以必然会用到一些新技术，以及我们的人力方面，这些都是影响项目开发的主要因素，然而正是这些因素的复杂性，也就造就了软件项目风险的复杂性，这些因素本身就是不确定的，当我们面对这些复杂的未知数时，要进行科学的分析得出更加合理的答案，才能使软件项目不断地向成功的方向发展，并且对软件开发做出一个正确的引导，反而言之，项目损失带来的将是项目的无法如期完成或者大量的超出成本预算，这些都将给企业带来直接的损失和消极的影响，所以我们在这里可以定位软件项目风险的重要性。

综合上述的分析，我们可以总结出风险的几个要素，风险首先是一个不确定的风险因素，然后会导致一个风险事件，这样带来的结果就是直接的损失，这样开发出来的软件就和企业以及客户的预期值相差太远，最后就有了风险结果，我们可以用一个图来表示这个风险描述：软件项目风险类型

软件项目风险的类型可以从不同角度进行分类，以下就范围角度和预测角度进行风险类 型的分析：

从范围角度，风险主要分为：商业风险、管理风险、人员风险、技术风险、开发环境风险、客户风险、过程风险和产品规模风险等等。

1）商业风险：是指与管理或市场所加诸的约束相关的风险，主要包括市场风险、策略风险、管理风险和预算风险等；

2）管理风险：是指在项目开发进程中，对潜在的人力和物力以及相关资源的管理风险，这

其中包括对时间、技术人员和项目相关资源的分配不合理，还有对项目计划实施没有做到足够好的预期安排等；

3）人员风险：人员风险主要是指在开发和实施的过程中技术人员自己的相关因素，其中主

要包括技术人员自身的不稳定性和错误判断，还有包括项目参与人员的经验不够丰富以至于做出错误的决定，这些都会影响项目的质量；

4）技术风险：是指在不断更新的软件开发技术中，会有某些不稳定的技术的参与，或者与

正在进行的项目不兼容的现象等等，所以在做技术风险分析的时候，我们先要对技术的稳定性和兼容性进行准确的测试，这样才能给软件项目进行准备的技术定位；

5）开发环境风险：主要是指开发环境以及工具可能会对项目造成的风险；

6）客户风险：在软件项目开发中，我们可以很明确的感觉到用户的需求的确定是一件具有

一定复杂性的工作，这样往往在我们的开发过程中，可能是因为客户的理解的差异造成客户修改需求的风险，这样的风险是最常见的，我们不能随时的变更需求，但是客户又必须要求更改需求的时候，这时候我们的客户风险就大大的出现在软件项目中了，所以为了避免这种风险或者减小这种风险发生的可能性，所以我们在分析客户需求的时候就要尽量想到以后可能会出现的风险；

7）产品风险：产品风险主要是指在产品成型之后，所出现的产品质量与客户或者开发人员

自己所预期的不相符合的情况；

8）过程风险：过程风险是与软件过程被定义的程度以及它们被开发组织所遵守的程度相关的风险；

从预测角度分析风险类型：

1）已知风险：在软件开发过程中，已经知道的风险是通过评估项目计划、开发项目的商业

及技术环境以及其他的可靠的信息来源而得来的；

2）可预测风险：这种风险类型是通过以往的项目经验来进行预测的风险类型；

3）不可预测风险：不可预测的风险往往是隐藏在项目开发过程中，这种风险是很难在其中

得知的，但是这种风险出现几率就没有那么大了，所以一个强大的企业需要有能够承担这种风险的能力；软件项目风险避免措施

当我们了解了风险的概念、定义以及类型以后，就应该根据风险的一些特性制定出相应 的避免措施。

在软件开发的初级阶段，最重要的工作当然是需求分析，当然这个里面包含了风险分析，做一个好的风险分析就等于为软件项目的成功打下了坚实的基础。首先，我们在需求分析的时候，必须要深刻的了解客户的使用情况，要深入到企业或者试用人员的周围调研用户需求，这样得到的需求才是真正的用户需求，如果我们只是一味的听从客户所描述的需求来定义软件需求的话，那么我们就大错特错了，在一般情况下，用户描述需求都不能全面的或者专业的转达他们理解下的需求，所以软件项目人员必须自己做好需求调研工作，这是一个至关重要的阶段，做好了这个阶段，也就减小了后续开发中的风险。其次，在软件开发的过程中，我们应该合理科学地安排技术人员以及其它与项目相关的资源，安排好这些资源后，才能减小开发中人员风险存在的可能性。还要做好其他相关风险的安排和考查工作，这里就每个风险类型不做一一介绍。最后，软件项目参与人员还应该根据已有的成功项目和失败项目的经验和教训，对此加以总结和比较，得出影响软件项目的相关重要因素，并且对这些可能存在的因素进行分析，尽可能地得出已知的和潜在的风险，根据相应的风险类型，及时的做出最合理的避免措施，以至于有效的防止风险的扩大化和普遍化。结束语

本论文主要介绍了软件项目风险的概念、风险的定义、风险的类型以及避免措施。我们 了解了风险的危害性，风险会对项目的成功造成决定性的威胁，所以当我们知道了风险危害性以后，应该怎么地去避免措施，做好合理科学的检查和预测，才能高效的防御风险发生的可能性，所以，要想做好一个软件项目，软件项目中的风险分析是一个重中之重的环节，不容忽视的，我们要总结已有的软件项目的成功和失败之处，然后运用到自己的项目中来，这样才可以最好的做到软件项目风险分析工作。参考文献：

【1】韩万江 姜立新 软件项目管理案例教程（第二版）机械工业出版社，2009.04.【2】卢有杰 卢家仪 项目管理系列教材 清华大学出版社 2001.08

【3】王卓甫 工程项目风险管理 中国水利水电出版社 2003.02

【4】Elaine M.Hall（王海鹏 周靖译）风险管理 清华大学出版社 2002.09

软件项目风险管理研究 篇2

随着软件产业及信息服务外包产业在全球范围内的迅速兴起与发展, 如何培养高素质软件工程人才, 实现高校软件工程专业人才培养与社会需求无缝对接, 已经成为目前各高校软件工程专业人才培养体系所亟待解决的重大问题。“软件项目管理”课程作为各高校计算机软件工程专业的一门重要的专业必修课程, 对于奠定培养软件工程专业技术与管理复合型人才的理论基础起着重要的作用。然而, 软件项目管理课程知识点繁多, 概念、运算枯燥难懂, 学生学习兴趣不足, 难于找到成就感;此外, 由于学生没有工作经验, 对于课堂中学到的理论不知如何在项目中运用。基于以上的问题, 笔者根据多年的企业工作经验, 经过多轮教学的磨合, 总结出一套项目教学的方法。通过教师扮演软件项目的甲方, 学生分组扮演软件项目开发的乙方, 共同完成软件项目的开发管理工作。在项目中, 融入理论讲解, 理论指导实践, 融会贯通。让学生对课程内容产生兴趣, 主动自发的学习课程知识。

2 项目教学过程

课程在介绍项目管理的理论知识的同时, 通过一个《信息管理系统》贯穿始终, 让学生对每个理论知识有个直观的认识, 知道这些理论知识在项目中是如何实际运用的。然后通过8个子项目的实验, 让学生分组合作, 在组中模拟项目中的项目经理, 需求分析人员, 设计编码测试人员, 质量管理人员, 配置管理人员等角色。并在老师指导下, 独立完成项目《图书借阅系统》从启动到结束的全部管理控制过程。8个子项目的内容, 具体如下:

接下来对每个子项目的过程设计如下:

2.1 项目启动。

项目提出:教师模拟项目甲方, 基于学校的信息数字化和现代化的管理需求, 提出《图书借阅管理系统》的项目需求, 给出项目招标书, 希望能在半年的时间内, 由乙方完成该系统的开发工作。由学生自由成组, 模拟乙方, 分析项目后, 写出项目建议书, 参与竞标, 中标后, 即可启动项目。项目知识准备:项目基本概念、项目初始过程、项目授权、生存周期模型。任务实施:a.乙方分析项目b.竞标竞演c.项目立项

2.2 进度管理。

项目提出:项目启动, 项目范围确定后, 接下来我们想想, 我们多长时间能做完这个项目呢?怎么估算和实际情况更接近呢?项目进展过程中, 如果时间上或延迟, 或提前了, 那我们如何把控我们的项目呢?项目知识准备:a.进度管理图示b.进度估算方法c.进度编排方法。任务实施:a.估算项目进度b.关键路径法进行项目进度编制c.会用ms project绘制工程表, 实施进度管理。

2.3 成本管理。

项目提出:我们的项目的报价是怎么产生的?我们项目有哪些成本, 利润又是多少?我们给客户报多少钱, 才不会赔钱?在项目中, 如果钱比预计的花的多, 怎么办?项目知识准备:成本估算方法、成本预算方法、成本控制方法。任务实施:a.成本估算b.成本预算c.成本管理。

2.4 质量和风险管理。

项目提出:项目做完, 进度没有延迟, 花销没有超支, 但客户仍然可能不满意, 为什么呢?因为项目的质量没有达到客户满意的标准。项目中可能存在哪些风险导致项目失败呢?项目知识准备:a.制定质量标准b.进行质量保证工作c.进行质量控制工作d.识别风险e.评估风险f.规划风险g.控制风险。任务实施:a.完成质量计划, 会对质量进行控制b.完成风险计划, 并能对项目中的风险进行应对。

2.5 人力资源和沟通管理。

项目提出:项目中最大的资源是什么资源?是人。每个人都是一个个体, 想让一群人, 高效, 目标一致的做好一个项目, 是个很困难的事。那我们会做哪些工作去建设好一个团队呢?人和人之间需要沟通, 怎么沟通才更有效呢?项目知识准备:a.项目组织结构b.责任分配矩阵c.人员管理计划d.团队管理e.沟通方式f.项目沟通计划。任务实施:a.人力资源管理b.沟通管理。

2.6 配置管理。

项目提出:项目中产生很多代码和文档, 放哪好?代码和文档会多次修改, 有时候想找以前的版本怎么办?多人合作共同开发一个功能, 能不能各自开发各自的, 然后自动整合?其他开发人员未经允许修改了你的代码怎么办?项目知识准备:a.配置管理过程b.配置管理工具VSS的使用方法。任务实施:用VSS进行项目配置管理。

2.7 合同与集成管理。

项目提出:项目最初我们签订了项目合同, 在我们做项目的过程中, 有没有可能去修改合同呢?要修改的话, 如何操作呢?前面我们学习了项目的范围管理、进度管理、成本管理、质量管理、风险管理、人力资源管理、沟通管理、配置管理, 合同管理, 这些管理之间必然有着这样那样的联系, 管理不好, 可能会互相牵制, 互相矛盾。那如何让这些管理相辅相成呢?项目知识准备:a.合同管理b.集成管理。任务实施:a.将《图书借阅系统》的一部分功能外包, 作为合同的甲方写一份合同。b.整理之前的所有项目计划, 形成集成计划, 注意各个计划之间的协调性。

2.8 项目结束。

项目提出:项目最后, 编筐编篓都在收口, 收口阶段要做哪些事呢?项目知识准备:a.合同结束b.项目结束。任务实施:a.乙方整理所有项目成果物, 甲方验收乙方的成果, 验收通过, 宣布合同终止。b.项目提交后, 写项目总结。

3 项目验收与评价

老师 (甲方) 和项目经理共同验收子项目, 评价包括甲方评价, 项目经理评价以及组内成员互评。最终通过答辩的方式, 教师根据学生在组内担当的角色, 以真实项目中的问题提问, 让学生根据所学知识做出案例的分析。

结束语

笔者结合多年的企业工作经验, 将实际的项目开发管理过程贯穿到课堂当中, 通过软件项目开发过程中涉及的管理问题, 一步步引导学生学习软件项目管理知识, 并把理论知识根据自身担当角色, 应用到项目中去。笔者已申报了校级项目教学示范课, 并取得了初步成果, 笔者会在实践中不断完善项目教学过程。

参考文献

[1]李蓉, 叶俊民, 杨艳.基于案例任务驱动的软件项目管理课程实践[J].计算机教育, 2014, 7.

[2]韩万江, 姜立新.软件项目管理案例教程[M].2版.北京:机械工业出版社, 2011.

[3]夏辉, 范书国.基于项目导向和实践考核体系的软件项目管理课程教学模式的研究[J].沈阳师范大学学报·自然科学版, 2014, 1.

[4]刘海, 周元哲.面向专业能力培养的软件项目管理教学研究[J].计算机教育, 2013, 9.

软件项目风险管理研究 篇3

关键词 软件项目；成本管理；问题；对策

中图分类号：F715.53 文件标识码：A 文章编号：1671-489X（2007）12－0068-03

Study on Problems and Measures of Software Project Cost Management//Cai Xuebing

Abstract Combining the real-life situation, this thesis analyses the problems exist in software project management, put forward proper countermeasures to those problems, which aims to improve the management of project in software enterprises according to their own feature.

Key words Software project；Cost management；Problem；Countermeasure

Author’s address School of Economics & Management, Guangdong University of Technology, Guangzhou 510006

软件企业是我国高新技术产业的重要组成部分，软件项目管理和成本控制已经成为软件企业积蓄财力，增强竞争力的核心手段。软件项目成本管理就是根据企业的情况和项目的具体要求，利用公司既定的资源，在保证项目的进度、质量达到客户满意的情况下，对软件项目成本进行有效地组织、实施、控制、跟踪、分析和考核等一系列管理活动，最大限度地降低项目成本，提高项目利润，实现客户、公司、员工三赢，获得更稳定的客户群、更多的公司利润和更稳定的项目队伍。但是，当前国内软件企业在项目成本管理方面比较薄弱，项目经常出现有订单无利润、客户不满意、员工有怨言等现象。本文针对软件项目成本管理过程中存在的问题进行分析和探讨，并提出相应的对策。

1 软件项目成本管理中存在的主要问题

1.1 项目人员经济观念不强，公司缺乏一套行之有效的成本管理体制

目前，我国软件项目人员大多具有软件开发专业技术背景，但是普遍缺乏经济观念，成本意识淡薄，特别是项目不单独核算的企业，项目经理职能更偏重于技术而非管理，简单地将项目成本管理的责任归于财务部门。同时，软件公司通常缺乏行之有效的成本控制和激励体制。很多只是简单的规章制度，至于由谁做、何时做、做到什么程度都没有提及，实际运作起来难度很大。在项目内部，每个成员只从自己的职责角度考虑，项目成本居高不下。如何由“人治”过渡到“法治”，建立一套体制，在项目成本管理中非常重要。另外，项目人员常常在接到软件项目时没有认真做好项目的需求分析，没有认真了解客户的真正需求，为了把项目拿下来，口头上统统答应客户的要求，并没有在合同里把条款细化、量化。而往往客户的需求也是停留在比较笼统的概念上，很难明确化，实际操作起来时，项目不能满足客户的要求，客户就会不断提出新的要求，这时候要更改项目就必须付出很高的代价。例如国寿广州公司委托某软件公司开发代理人综合管理系统时，在项目的需求分析中，国寿信息部只提出相对笼统的概念，软件公司为了尽快拿到此项目，就全部答应，在合同里也没有细化条款。结果在系统做出来以后，总是难以全部满足最初需求，以致项目一再变更，软件公司为此付出很大的代价。

1.2 项目的过程编制薄弱

一些项目成本预算和估算的准确度差，失去控制标准。在项目管理中，相关的管理部门通常要求项目经理做出项目的估算或预算，并以此为标准，进行项目的控制和考核。但在实际工作中，由于项目具有一次性和不确定性的特点，以及项目经理自身的经验和水平的限制，使项目估算或预算的准确性很差，一有变化，项目经理就追加项目预算。预算频频变更，最终失去了项目的控制标准，成本控制也流于形式。等到项目结束时，实际成本和初始计划已经大相径庭。

一些项目缺乏成本绩效的分析和跟踪，缺乏将成本数据和工作量联系的对比数据。项目成本管理中，通常将预算和实际数值进行对比，没有将预算、实际成本和工作量、进度联系起来，考虑实际成本和工作量是否匹配、价值成本等问题。例如一个项目成本花费到总预算的1/3，而进度却是预计进度的1/4，工作量是总工作量的 1/5，这就说明项目成本控制存在问题。如果不采取措施，照此下去，项目一定会超出预算。

1.3 缺乏质量成本、工期成本、资金成本、风险成本的管理和控制

质量成本是指为保证和提高软件质量而发生的一切必要费用，以及因未达到质量标准而蒙受的经济损失。质量成本分为内部故障成本（如返工、停工等引起的费用）、外部故障成本（如保修、索赔等引起的费用）、质量预防费用和质量检验费用等4类。保证质量往往会引起成本的变化，但不能因此把质量与成本对立起来。长期以来，我国软件企业未能充分认识到质量和成本之间的辩证统一关系，习惯于强调软件质量，而对项目成本关心不够，造成质量虽然有了较大提高，但增加了提高质量所付出的质量成本，使经济效益不理想，企业资本积累不足。相反，一些项目经理片面追求经济效益而忽视质量，虽然就单个项目而言，利润指数可能提高，但是因质量标准而付出的额外质量成本，既会增加成本支出，又会对企业信誉造成很坏的影响。

工期成本是指为实现项目工期目标而采取相应措施所发生的一切费用。工期目标是项目管理3大主要目标之一，软件企业能否实现合同工期往往会引起成本的变化。我国软件企业常对工期成本的重视不够，虽然对项目工期有明确的要求，但对工期与成本的关系很少进行深入研究，普遍认为越早越好，有时会盲目地赶工期要进度，造成项目成本的额外增加。

资金成本是指资金的一切费用。由于公司一般项目都是由公司提供资金支持的，因此每个软件项目很少考虑现金流的状况，以及项目投入给公司带来的资金压力和项目本身的资金成本。在以项目为主的软件企业中，项目收入是公司资金流入的主要来源，项目的支出也是公司资金流出的主要内容，所有项目的资金流扣除期间费用后就是公司的资金流。因此，项目的资金流对公司的资金会产生重大的影响。现金流是公司的血脉，特别是对于中小软件公司，如果项目的资金流出现问题，可能会导致公司经营的瘫痪和夭折。

风险成本是指项目的不确定因素导致的项目风险。在项目成本管理中，很少考虑项目风险和潜在的风险成本，而风险一旦出现，会对项目的成本造成巨大的冲击。

2 软件项目成本管理中存在的问题的对策分析

2.1 树立全员经营意识，建立规范的成本管理体制

软件企业必须加大对从项目管理人员到普通员工的经营教育，强化经营意识。根据公司和项目本身的特点，制定有针对性的项目成本管理办法和流程。这些管理办法应该是责任到人、切实可行的具有较强操作性的办法，使项目的成本控制有法可依、有章可循、有据可查。每个项目都要有成本控制的目标——项目预算，都要严格做WBS（工作任务分解），在落实任务的同时，也要落实完成任务所需要的成本预算，并且逐级负责，层层落实。项目经理是项目成本管理的领导，这就形成一个以项目经理为核心的成本管理体系。同时用一定物质奖励去刺激，使每个人的工作、成本和项目的效益挂钩，彻底打破过去那种干好干坏一个样，干多干少一个样的格局，调动职工的积极性和主动性，使大家共同为项目的成本管理献计献策。另外，要做好项目的需求分析，真正了解客户的需求，尽量把客户的每一条要求量化、细化，并明确写入合同，避免以后因客户不断提出新的要求而增加项目成本。

2.2 加强项目过程管理和监控

要进行有效的项目成本估算和预算。项目预算是项目分配资源的计划，也是控制的标准，在项目成本管理中具有重要作用。成本估算和预算是对完成项目各项任务所需要的资源成本的近似估算。在实际工作中通常有3种成本估算方法：（1）自上而下估算。项目经理利用以前类似的项目的实际成本作为基本依据，通过经验做出判断项目整体成本和各个子任务的成本预算。此方法通常在项目的初期或信息不足时进行，需要项目经理有较高的水平和经验。（2）自下而上估算。将项目任务分解到最小单位——工作包，对项目工作包进行详细的成本估算，通过各个成本汇总将结果累加起来得出项目总成本。由于项目相关人员都参与项目的预算，这种方法最为准确，同时避免预算争议，但是耗用的管理成本会相应增加。（3）参数估算。这是一种建模统计技术，如回归分析和学习曲线。此方法需要数据的积累，根据同类项目的管理状况和成本数据，建立模型，在遇到同类项目时可以直接套用。

此3种方式可以根据公司的实际情况和项目的特点使用一种或同时使用。有效的成本估算和预算涉及到各方面的通力合作，需要项目人员进行有效的沟通。另外，即使最好的专家也不可能使预算和实际成本完全一致，因此项目应该预留一定的不可预见成本5%－10%，作为应急项目成本。

2.3 从质量成本、工期成本、资金成本、风险成本管理上要效益

质量成本管理的目标是使4类质量成本的综合达到最低值。一般来说，质量预防费用起初较低，随着质量要求的提高会逐渐增加，当质量达到一定水平再要求提高时，该项费用就会急剧上升。质量检验费用较为稳定，不过随着质量的提高也会有一定程度的增长。而质量损失则不然，开始时因质量较差，损失很大，随着产品质量不断改进，该项损失逐步减少。因此，必须找到一个质量成本最低的点。正确处理质量成本中几个方面的相互关系，即质量损失（内、外部故障损失）、预防费用和检验费用间的相互关系，采用科学合理、先进实用的技术措施，在确保质量达到设计要求水平的前提下，尽可能降低软件项目成本。同时，不能单纯为了提高企业信誉和市场竞争力而出现质量过剩的现象，导致出现完成工作量不少，经济效益低下的被动局面。

工期成本管理的目标是正确处理工期与成本的关系，使工期成本的总和达到最低值。工期成本表现在2个方面，一方面是项目经理为了保证工期而采取的措施费用；另一方面是因为工期拖延而导致的业主索赔成本，这种情况可能是由于外部因素引起的，也可能是内部因素所造成的，如停工、窝工、返工等，因此所引起的工期费用，可称为工期损失。一般来说，工期越短，工期措施成本越小；但当工期缩短至一定限度时，工期措施成本就会急剧上升。而工期损失则不然，因外部因素引起的工期损失，其损失额度相应较小，通常情况下不予赔偿或赔偿额度较小，该部分工期损失可不予考虑；因项目内部因素造成的工期损失，随着时间的推移、经验的积累会逐渐减少。综合工期成本的各种因素，就会找到一个工期成本为最低的理想点，这一点也就是工期最短并且成本最低的最优点。由于外部环境条件及合同条件的制约，保证合同工期和降低成本是一个十分艰巨的任务，因此必须正确处理工期成本的2个方面的相互关系。在确保工期达到合同条件的前提下，尽可能降低工期成本，切不可为了提高企业信誉和市场竞争力，盲目抢工期赶进度，增大项目成本，导致项目亏损。

对于项目现金流的控制，可通过项目的财务现金流分析，判断项目资金收支的时间、资金亏口的时间，便于提前准备资金。同时积极从客户方催款，以便支付各种费用，使得现金的流入大于流出。产品投资项目可采用投资回收期、净现金流来控制。

通过主动的风险控制，防患未然，避免和减少损失。根据拟建软件项目的具体情况，有选择性地进行经济模型盈亏平衡分析、敏感性分析和概率分析、合同控制等。软件项目的各种经济活动，都是以合同或协议的形式出现。如果合同条款不严谨，容易留下漏洞，造成己方蒙受损失时应有的索赔条款不能成立，产生不必要的损失。所以必须细致周密地订立严谨的合同条款。首先，要有相对固定的经济合同管理人员，并且精通经济合同法规有关知识，必要时应持证上岗；其次，要加强经济合同管理人员的工作责任心；三是要制定相对固定的合同标准格式。项目合同基本上有以下几类：软件开发合同、技术服务合同、采购合同、分包合同、劳务合同等。各种合同条款在形成之前应由业务部门参与定稿，使各项条款的内涵清楚，严谨不漏。

3 总结

软件项目变更管理流程 篇4

2.1 摘要.........................................................................................................................................2 2.2 提交变更申请.........................................................................................................................3 2.3 审核变更申请.........................................................................................................................4 2.4 识别变更可行性.....................................................................................................................4 2.5 批准变更申请.........................................................................................................................4 2.6 实施变更申请.........................................................................................................................4 变更任务.................................................................................................................5

3.1 变更申请人.............................................................................................................................5 3.2 变更经理.................................................................................................................................5 3.3 变更可研小组.........................................................................................................................5 3.4 变更审批小组.........................................................................................................................5 3.5 变更实施小组.........................................................................................................................5 5 变更登记.................................................................................................................6 变更模板.................................................................................................................6

Confidential

Page 1 1 概述

描述变更管理的目的。就项目中变更管理的总体流程提供一份概述，如：

变更管理流程是成功交付项目的基础。变更管理流程确保对在项目环境中的每个变更在实施以前都得以恰当的定义、评估和审批。

对项目的变更管理是通过对以下五个关键步骤的实施引入的。，:  提交和接收变更申请  审核和记录变更申请  确定变更申请的可行性  批准变更申请

 实施和结束变更申请变更流程

对将要执行的流程和程序做一个图表概述，以启动、实施项目中的变更并审核其效果。例如：Provide a diagrammatic representation of the processes and procedures to be undertaken in order to initiate, implement and review the effects of changes within the project.An example follows:

2.1 概要

下图对将要执行的变更流程和程序做了一个概述，以有效地管理与项目相关的变更。同时也明确的变更管理中的职责分工。

Confidential

Page 2 ChangeManagementProcessChangeManagementRole1.1 Changerequirementidentified1.0 SubmitChange Request1.2 ChangeRequest FormsubmittedChangeRequestor2.1 ChangeRequest Formreviewed2.0 ReviewChange Request2.2 FeasibilityStudy required?ChangeManagerNoYes3.1 ChangeFeasibility Studyperformed3.0 IdentifyChange Feasibility3.2 ChangeFeasibility StudyapprovedChangeFeasibility Group3.3 Changedocumentationsubmitted4.1 Changedocumentationreviewed4.0 ApproveChange Request4.2 Changeapproved?ChangeApproval GroupNoYes5.1 Changeimplementationscheduled5.2 Changeimplementationtested5.0 ImplementChange Request5.3 ChangeimplementationperformedChangeImplementationGroup5.4 Changeimplementationreviewed5.5 Changeclosed2.2 提交变更申请

本步骤中项目团队中的任何成员都可以提交项目变更申请，需要完成以下工作：

 变更申请人识别项目中任何方面的变更需求（如范围、可交付成果、时限、组织）. 变更申请人完成变更申请表（CRF），并将其呈交变更经理。变更申请表对需要进行的变更做一概述，包括：

 变更描述

 变更原因（包括商业驱动） 变更利益  变更成本

 变更带来的影响  支持性文件

2.3 审核变更申请

本步骤授权变更经理对变更申请表进行审核，以决定是否需要一份充分的可行性研究报告以供变更批准小组评估变更可能带来的全部影响。做出上述决定的基本依据是：

 呈交的可选择变更数目Number of change options presented  申请变更可选反性的复杂程度Complexity of the change options requested  提出的变更解决方案的衡量Scale of the change solutions proposed 变更经理将不会在变更日志中打开一份变更申请并记录是否需要一个变更可行性研究。The Change Manager will open a 慍hange Request’ in the Change Log and record whether or not a change feasibility study is required.2.4 识别变更可行性

本步骤涉及完成一份完整的变更可行性研究，以确保对所有的变更可选项进行调查并上报，变更可行性研究包括对以下各项的定义：

 变更需求

 变更可选项Change options  变更成本及利益

 变更风险及事项Change risks and issues  变更带来的影响  变更的建议和计划

对对可行性研究进行认真审核以确保研究是切题的，同时确保（经过变更后的）最终的可交付成果是可以通过的—那研究报告就可以上报变更审批小组了。变更经理将整理所有变更文件并报变更审批小组做最终审核。这些文件包括：:  原始的变更申请表

 已通过的变更可行性研究报告  所有支持性文件

2.5 批准变更申请

本步骤涉及变更审批小组对变更申请的正式审核。变更审批小组可能做出下列任何一种结论：

 拒绝变更Reject the change  要求与变更相关的更多信息Request more information related to the change  批准变更申请Approve the change as requested  在特定条件下批准变更Approve the change subject to specified conditions

决定是否变更的标准大致为：

 实施变更给项目带来的风险  不实施变更给项目带来的风险

 实施变更对项目产生的影响（时间、资源、财务、质量方面）

2.6 实施变更申请

本步骤涉及对变更的全面实施，包括:       确定变更进度（如：实施变更的日期）

实施前对变更进行测试Testing the change prior to implementation 实施变更

对实施变更的成功度进行审核 就实施变更的成功度进行沟通 在变更日志中结束变更 变更职责

对项目中启动、审核和实施变更所涉及的所有资源（包括项目中或项目之外的资源）的职责和责任进行定义，如：

3.1 变更申请人

变更申请人最初意识到对项目进行变更的必要性并就此需求与变更经理进行正式沟通。其主要职责为:  及早识别对项目进行变更的需求

 通过完成变更需求表来完成对更申请的正式文件  将变更申请表提交变更经理以供审

3.2 变更经理

变更经理对一个项目中所有的变更进行接收、记录、监测和控制。其主要职责为：

 接收所有的变更申请并将其记录于变更登记簿中  将所有的变更申请进行分类、优选

 审核所有变更申请以确定在提交变更审核小组前是否还需增加有关信息  确定是否需要进行一个正式的可行性研究并提交变更审核小组  通过委派变更可行性研究小组来启动变更可行生研

 对所有的变更申请进展情况进行监测以确保项目按时完成  将所有的变更申请问题和风险上报变更审批小组  就变更审批小组做出的所有决定进行下达和沟通

3.3 变更可行性研究（可研）小组

变更可行性小组负责完成由变更经理签发的对于某变更申请的正式的可行性研究，主要职责为：

 通过进行摸拟研究来确定变更可能的要素：成本、利益和变更带来的影响。 将变更可行性研究报告中的所有发现形成文字  对报告进行认真审核并批准交其上报。 将报告转变更经理以提交变更审批小组 

3.4 变更审批小组

变更审批小组决定是否批准变更经理转来的所有变更申请。其主要职责为：

 审核变更经理转来的所有变更申请  考虑所有变更支持性文件

 根据每个变更申请的相关价值决定批准还是拒绝  解决变更争议（当两个或两以上变更撞车时） 解决变更问题Resolving change issues  决定实施变更时间表

3.5 变更实施小组

变更实施小组对项目中所有变更的实施进行计划、落实和审核。变更实施小组主要负责：      计划所有变更的进度（在变更审批小组提供的总体时间框架范围内）)在实施前对所有变更进行测试 实施项目中的所有变更 实施后审核变更的成功度 在变更日志中请求结束变更 变更登记簿

变更登记簿是用于登记、跟踪变更申请进展情况的日志/数据库。描述项目变更登记簿的目的和用途，在下面插入一个真实的变更登记文本 变更模版

《项目管理软件》学习总结 篇5

学习，对于我来说，早已不是一个陌生的词汇。十几年来，随着学习的深入和年龄的增长，我却发现学习能力和效率在逐年下降。《劝学》里说，“君子博学而日参省乎己，则知明而行无过矣”，这里就要求学习者要经常静坐思考，及时调整，重新定位，找到一种最适合自己的学习方法，并不断体会总结，以便融会贯通、学以致用。

本学期我选报了曹刚老师的《项目管理软件》，一是耳闻曹刚老师授课严谨，对学生负责，不容许“混学分”的现象；再者，曹刚老师讲课风趣幽默，教学方法有与众不同之处；当然，最主要的还是我对这门课本身比较感兴趣。由于我对自己所修专业不是太感兴趣，所以在选修课的学习上比较慎重，在选这门课之前，已经对本门课程有了大致了解；并在后期的学习中逐渐深入。

项目是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标或目的，必须在特定的时间、预算、资源限定内，依据规范完成。项目参数包括项目范围、质量、成本、时间、资源。项目管理（PM），就是项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。目前国内企业对项目管理水平和方法越来越重视，而合适的项目管理软件在其中起了极其重要的作用！主要有工程项目管理软件和非工程项目管理软件2大分类。曹刚老师就Microsoft Project 2007为纲，为我们由浅入深、循序渐进地讲解了这门课程，受益匪浅。

我认为，学习一门课程成功与否，不仅仅以掌握本学科专业知识的多少来权衡。更主要的，应该是一种思想，课程本身起着抛砖引玉之效果。项目，我们熟知却不懂管理，就像目标和梦想，不是我们没有，而是我们缺少动机和实现他们步骤及方法。话不多说，从今天起，小至对一门课的学习、一个购物计划；大至一年的学习目标、感情生活，甚至是职业生涯规划，我想我都不会再模里模糊，而是提前打算，有章可循。是的，项目管理，应该成为一种生活习惯。

再细说一下我们老师的授课方法。本门课程采用面授+上机+网授，这样，我们有了一个专属的学习的平台和交友空间。与别的选修课不同，我们在这里能很快熟知班里的同学来自哪个学院，哪个专业，对于相互学习起着很大的促进作用。曹老师还为我们专门设置了讨论区，灌水区，学习之余轻松分享，互通有无。网授空间井井有条，条理清楚，学习重点一目了然，便于“温故知新”。作业平台、考试系统都很方便，老师能对我们一段时间的学习效果及时反馈，以便我们查缺补漏。这本身就是对本门课程的一种管理机制，方便快捷，合理有效。

当然，任何事情都不可能尽善尽美。首先，一开始的时候，我对这种学习方式很不适应，本来就只有8周的学习时间，一节课下来，便有了“时间紧任务重”的感觉；再者，网授仅限于校内局域网，对于一般情况下都用外网的我来说，不是很方便，这样导致同学同学之间和同学老师之间的交流过少，网授不能达到应有的效果；还有，学习任务都是每周上课前才出现在网授平台上，对于没有教材的我们来说，不容易提前对整门课全面统筹，既然有了这个平台，老师可以把整个课程的学习目标、教学进程、课程安排，提前公布出来，以便我们对整个软件学习的全面把握。

软件项目的进度管理大全 篇6

理

[大] [中] [小]发布人：圣才学习网

发布日期：2012-07-13 21:16

信息系统项目管理师论文范例1：论软件项目的进度管理

摘要

本文讨论了《电力行业工作票、操作票系统》的项目管理，在本项目中我作为项目负责人，承担了项目管理工作．

在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的工作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不足。

本文从合理的估算项目的工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面讨论了《电力行业工作票、操作票系统》项目管理的基本活动与方法，有效地控制开发进度，确保项目如期按质量完成．本系统在电力系统已经运行，状况良好，受到一致好评．

正文

2003年2月，我参加了《电力行业工作票、操作票系统》的开发，担任项目管理工作．电力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业相关标准进行工作，《电力行业工作票、操作票系统》就是按照国家有关标准及电力行业操作规程设计的仿真系统。工作人员在施工前按照工作流程在此仿真系统上进行操作，严格遵守电力设施的逻辑闭锁关系，顺序执行．有效地防止不规范操作，确保电力设施及现场工作人员的安全，提高安全意识．

本系统由系统图编辑平台和工作票、操作票签发系统两大部分组成，其中系统图编辑平台主要是编辑变电站、用电系统及变电站控制系统图，每一个电力设施对应一个对象，在系统图上都有相对应的部分，系统图真实地反映电力设施的布局及相互关系，生动形象又合乎技术标准，同时为第二部分提供操作对象．工作票、操作票签发系统主要是在系统图的基础上进行点击操作，每饮点击对应一个对象即一个电力设施，根据电力设施的逻辑闭锁关系自动生成相应的工作票或操作票或提示操作不规范．

在本系统的开发过程中，我通过合理的估算项目工作量及技术难度；识别关键任务；随时了解项目进度，必要时调整进度表等方面对项目进行管理，确保本系统如期按质量完成。

1、合理的估算项目工作量及技术难度

我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则．

本系统采用了面向对象的分析、设计等一系列面向对象技术，在本系统工作量的估算上根据功能点进行估算．将每个功能模块逐步分解，直至基本模块为止．我们将系统分为系统图编辑与工作票、操作票签发两个大的功能分别进行估算。系统图编辑部分主要是一个图形编辑系统．一种电力设施对应一个类，电力设施的技术参数及其操作对应相应类的属性和方法，电力设施图是由线段、圆、曲线、折线、多边形等基本图形组成，这些基本图形分别对应一个类，这些类又继承一个最基本的类．系统图编辑部分的工作量也就是这些类的实现，工作票、操作票签发部分用到了编辑平台的系统图，因此由大量的功能可以复用，这部分的功能划分同系统图编辑部分一样也是采用类作为基本结构，这样就比较准确的进行工作量的估算．

同时我们开发的这个系统是基于C/S结构的，由于C/S结构的系统我们公司有不少成功的案例，因此有不少的案例供我们参考．对于本系统的第二部分我们就是借鉴以前我们做过的基于C/S结构的系统，基于C/S结构的系统的框架基本上是一致的，数据库的设计、前台操作如对数据库进行添加、删除、修改、查询等一系列活动大体相同．正是如此，有大量的东西可供我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改．在工作量的估算上也有很好的借鉴作用．这对工作量的估算也是一个重要的参考，为工作进度安排提供了依据．

在技术上，我们重点考虑本系统与其他C/S 结构的系统的不同之处，相同或相似之处我们认为没有技术难点．系统编辑平台主要是绘图，我们知道MFC的绘图功能确实强大，但是过于繁琐，功能封装不是十分完美，我们采用了Form＋＋这个MFC 扩展类库，这个扩展类库对图形操作封装得很好，大大降低了系统图编辑部分的难度，在界面设计上我们采用了BCG 这个扩展类库，使得VC应用程序界面设计得如同Delphi等工具一样完美．同时减少了工作量，在工作安排上，技术难度相对大一点的部分我们安排经验丰富的程序员，同时也同其他工作组的成员商讨技术细节间题，同他们进行技术探讨．这样不至于因为某一技术细节而影响整个工程进度．

根据上述分析我们制定一个详细的进度表并定义相应的里程碑．

2、识别关键任务

系统图编辑部分是整个系统的基础，因为工作票、操作票签发部分是建立在该部分的基础之上，系统图编辑部分直接影响到整个项目．因此该部分是整个系统的关键部分，在这部分中每种电力设施所对应的类及其父类的定义是关键，因为所定义的类必须完整、准确地反映该电力设施的技术参数和操作．

工作票、操作票签发部分，是用户明确提出的要求实现的功能，直接面对用户，这部分的成功与否直接影响到该系统的质量，因此也是不容忽视的．

如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁．因此是本项目的关键任务．在进度控制时我们将其作为重点对象进行控制．

3、随时了解项目进度，必要时调整进度表

在确定项目开发计划时，我们制定了详细的进度表．我们在确定每一项任务时都确定该任务的工作量、开始时间、持续时间、结束时间．同时让每个小组成员知道自己所承担任务的时间表，小组成员根据自己的任务制定自己的详细工作计划．

工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成品对自己的工作都要做工作日志，对自己每天的工作做详细记录．每周对自己的工作进展做出结论，向项目组汇报．在做结论时，不得使用“差不多”、“大概”、“完成了90%”„ 等模糊字眼．而是采用某任务“已经全部完成”、或者“90%的工作全部完成”或者“再过1 天全部完成”„等方式．每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目计划提供客观基础．

同时我们在项目进度计划中根据项目设计定义了相关的里程碑，在每个里程碑我们都采取小组会议形式对本阶段的工作进行确认、总结，对本阶段的进展情况做出结论，并决定是否调整下一阶段的进度计划．

在系统图编辑部分我们认为各电力设施所对应的类（包括其父类）定义完成为一个里程碑，每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的标准，这些类（包括其父类）的实现完成又为一个里程碑，„ „整个系统图编辑部分完成也是一个里程碑．每个里程碑的标准在系统设计时已经定义好．

结束语

《电力行业工作票、操作票系统》目前已经开发完毕，运行状况良好，受到一致好评。在本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则，因为小组成员的各有特长，面向对象技术不是每个小组成员都熟练掌握，加之面向对象技术在我们公司还不是很成熟，必须有一个过渡，不能一下子转型，因此采用该种策略符合我们公司的现实情况。

软件开发项目进度管理研究 篇7

软件开发项目进度,是指完成整个软件开发项目所需活动的过程和时间周期。软件开发项目进度管理是为了确保项目按时完成而对其各项活动及阶段进行的管理。软件开发项目进度管理包括4个步骤,其中软件开发项目进度计划编制和进度控制是实际工作重点,但编制项目进度计划前,应先分解项目,明确该项目包含的活动,并对项目活动进行排序[1]。下文中“软件开发项目”简称为“项目”。

1 项目工作分解

一个项目提出后,根据项目目标确定项目的研究范围后,应对项目进行分解,将可交付成果和复杂的项目逐步分解成较小的、便于管理的组成部分,并创建工作分解结构图,为项目进度计划打下基础[2]。

1.1 项目工作分解的作用

项目分解的作用主要体现在两个方面:

(1)便于进行综合性方案设计。工作分解就是在项目目标的指导下,在任务范围中从粗到细、从简到繁,逐步分析,直到可执行的最小独立单元,这样能够较好地保持项目的系统性和完整性,策划者据此可以通盘考虑实现项目目标应完成的工作,能够清晰地分辨任务实现的重点和步骤、完成周期、成本费用,并评估风险,同时,也有利于发现潜在的不明确内容,为项目总体设计提供可靠依据。

(2)便于分配任务和明确责任。项目工作分解把项目划分成多个独立性较强的任务单元,明确区分各任务的目标、范围和界限,对每个工作任务提出具体要求,便于在执行项目时,落实责任者或完成单位。既可以作为委托工作或下达任务的依据,也便于观察、了解和控制整个项目过程。

1.2 项目工作分解结构的依据、原则和方法

项目工作分解结构的主要依据是前期取得的项目主要资料和其它相关项目的借鉴性文件,包括项目需求文件、任务(合同)范围说明、本项目的其它资料、其它项目的相关资料等。

工作分解结构的原则是:在各层次上保持项目内容的完整性,不能遗漏任务必要的组成部分;每个项目单元只能从属于某一个上层单元,不能同时交叉从属于两个上层单元;相同层次的项目单元应有相同的性质,各项目单元应有明确的任务界限,保持各项目单元的独立性;项目分解的原则应事先确定,同一层次上分解出的项目单元,其分解的原则应该是一致的。

工作分解的方法有自上而下和自下而上等方法。自上而下法是先明确项目最终产品,然后确定中间可交付成果,再对主要可交付成果细分,直至每一个工作只包含一个可交付成果;自下而上法是首先明确项目的所有可交付成果,然后将可交付成果进行逻辑分组,接着将每组汇总成一个母元素,成为上一层次的元素,再将高一层次的元素进行分组、汇总,以此类推,最终汇成一个母元素。

1.3 项目工作分解结构一般步骤

工作分解首先应识别项目的主要要素,项目的主要要素就是项目的主要交付物,然后对识别出的主要要素作进一步细化,分解出更详细的有形的、可检验的产品或服务,在此基础上,选择自上而下或自下而上的方法编制工作分解结构图(也可以使用单位标准模板或以前项目的模板),编制完工作分解结构图后,应编制详细的结构图说明,说明的内容包括各要素的界定、说明、估算经费、时间、预安排的责任部门、人员等。

1.4 项目工作分解结构输出

项目工作分解的输出结果包括项目结构图和相关说明。项目分解结构图(WBS)是通过分解技术,将项目任务按照其内在性质和结构逐层细化而形成的示意图。它涵盖为完成项目交付物需进行的所有项目工作,为项目责任分配和任务协调提供依据。项目结构说明包括各层要素的详细描述、工作说明、负责组织、进度日期、成本预算等。

2 项目活动确认及排序

完成项目工作分解后,应对所确定的可交付成果的具体活动进行分析确认和排序,为编制项目计划打基础。

2.1 项目活动确认

依据项目工作分解结构的成果、其它关于项目范围的说明性文件、项目约束条件、项目的假设前提、管理计划和单位的历史信息等[3]确认项目活动。对于一些小项目,可通过大家集体研究讨论,集思广益的方法,形成可行的活动清单并估算所需时间,对于较大、较复杂的项目,则需要由相应领域专家研讨或使用一定的工具和方法来确认项目活动,这些方法包括:进一步使用活动分解技术、采用已有模板法、领域专家判断法等。项目活动确认后,形成的结果包括:涵盖项目所有必要活动的项目活动清单、描述项目过程中基本关键点的项目里程碑图等,此外,还应适时更新项目工作分解结构图和项目总体管理计划。

2.2 项目活动排序

确认了项目活动,要识别各项活动的相互关系,项目活动之间的关系也称为项目活动之间的先后信赖关系,包括人们无法改变的硬逻辑关系和需由各种因素综合确定的软逻辑关系,在项目活动排序时,要根据项目活动清单、项目里程碑和一些约束条件,先识别并安排硬逻辑关系,再安排软逻辑关系,同时要考虑项目假设条件和外部条件的影响。项目排序图的编制方法可以采用节点图法或箭线图法。项目排序的最终结果,是描述项目各项活动相互关系的项目网络图及其活动说明,项目网络图应包括项目的主要活动和情况,并明确各活动之间的逻辑关系或依赖关系,在网络图的说明中,应描述活动排序的基本方法,对于特殊的排序应进行说明。

2.3 项目时间估算

项目时间估算是指根据项目范围、资源及相关信息,对项目已标识的各活动持续时间所进行的估计。大多数项目活动时间的长短,取决于人力、物力、财力及资源的多少,同时还受人的能力、物资质量和设备效率的影响。对项目活动时间进行估算时,即要考虑各活动所消耗的实际工作时间,也要考虑活动的延迟时间。因此,一般由熟悉项目活动或有经验的人员或团队,采用专家判断法、类比估算法或模拟估算法完成。

3 项目进度计划编制

编制项目进度计划,是综合分析项目活动排序、持续时间、资源需求和进度约束,确定每一个项目活动及整个项目起始和完成日期,建立一个相对科学可行的项目进度计划的过程。编制项目进度计划是一个迭代过程,需要运用科学的计划方法,将时间、经费、人员、设备及各种资源作统筹安排,还要与其它相关项目协调一致。

3.1 编制依据

编制项目进度计划的依据包括:项目活动排序后得到的项目网络图、项目活动估算得到的时间值、现有的和能取得的资源、项目时限和重要里程碑、项目约束条件以及其它风险和假设前提。

3.2 编制方法

根据不同项目的具体情况采用不同的方法,本文重点介绍编制项目进度计划的3种方法。

(1)甘特图法。甘特图又称横道图或条形图,它是通过赋予时间以含义的横道图形式,列出项目活动工期及其相应的开始和结束时间,以反映项目进度信息的一种可视化计划方法。甘特图左侧列出项目活动和工期,顶部列出时间,横道长短代表活动持续时间长短。甘特图的优点是简单、明了、直观、易于绘制,缺点是不能系统地将项目各项活动之间的逻辑关系表示出来,也不能进行定量分析和计算,更不能指出影响项目的关键所在。

(2)关键路线法。关键路线法也是通过横道图以日历形式列出项目活动、工期、相应的开始结束时间来进行规划。它与甘特图的不同之处在于,它运用特定的、有顺序的网络逻辑方法来预测总体项目历时,是一种数字分析技术。关键路线法的重要功能是确定项目的关键工作和关键路线,关键路线的确定是将项目网络图中每一条路径上的所有项目活动的历时分别相加,最长的那条路径就是关键路线。

(3)计划评审技术。计划评审技术是指当项目或项目某些活动历时估算存在不确定性时,运用加权平均历时估算法,来估算项目历时的网络分析技术。这种技术适用于不可预知因素较多,或从未做过的新项目或复杂项目。计划评审技术网络图的画法与一般网络图画法相同,不同之处在于对项目活动时间的估计和分析[4]。

3.3 编制结果

编制项目进度计划的主要成果用表格或图表形式呈现,项目各项活动都标明了各种日期参数的项目进度计划文档。此外,还应包括进度管理计划,用以明确项目进度计划发生变化时的处理原则。

4 项目进度控制

项目进度控制是进度管理的重要内容和过程,是前期一系列进度计划工作的延伸,是进度管理中与实施并行的实践性关键阶段。

4.1 进度控制依据

项目进度计划是经过论证和批准的,在技术和资源上具有可行性,所以是项目进度控制的主要依据。通过项目跟踪监测和沟通形成的有关项目进度的绩效报告、根据项目进展情况提出的变更请求、编制进度计划时形成的进度管理计划,也都是进行项目进度控制的依据。

4.2 进度控制主要工作

控制项目进度的主要工作是:依据作为项目进度基准的项目进度计划,通过跟踪监测和沟通,采用一定的工具和方法进行分析比较,确定项目进度是否发生了变化,如果发生了变化,找出变化的原因,对影响变化的因素进行控制或制定项目进度的补充计划,从而确保进度变化朝着有利于项目目标实现的方向发展[5]。控制项目进度还可以借助项目管理软件来实现。

4.3 进度控制结果

进度控制的结果有两种,第一种是项目所有进展均按计划顺利进行的理想情况;第二种是发生一些偏差,并制定一系列纠偏措施,之后更新项目进度计划。两种情况均应记录项目控制的经验或教训[6]。

参考文献

[1]关保昌,沈建明.现代国防项目管理[M].北京:军事科学出版社,2011.

[2]祝振铎,董雄报.信息系统项目工作分解结构(WBS)研究[J].硅谷,2011(15):78-78.

[3]方德坚,张杨华.也谈软件项目进度管理[J].赤峰学院学报:自然科学版,2011(5):15-16.

[4]王芙蓉.软件项目进度计划与风险控制研究[D].大连:大连海事大学,2009.

[5]徐飞汀.软件项目进度计划管理研究[D].北京:北京邮电大学,2010.

软件项目的需求变更管理 篇8

需求管理的常见误区

软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。

误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。

从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。

正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。

误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。

从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。

正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求（即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等）和设计约束（即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品）。

误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。

从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。

正确的方法是：要充分认识用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，根据重要性、优先级、特殊性对各类用户进行排序；其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。

误区4：按照“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。

从软件工程角度分析，这是对于需求变更过程缺乏系统的认识的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持一致。实际上，由于需求变更的不可预见性和必然性，各个阶段往往以螺旋的方式渐进。

正确的方法是：需求跟踪应该贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。

做好需求工程

需求分析是软件工程项目最重要、最基础的起始阶段，为后续的规划设计阶段提供参照依据。在软件研发项目过程中一定要树立需求工程的意识，将需求视为一项系统工程。为了能够全面做好需求管理，应根据项目实际情况严格划分项目阶段，清晰界定、定义项目阶段的基线，在每个项目阶段制订、执行阶段性需求管理计划，逐一认真落实。

1．需求工程的结构及目标任务

需求工程是一个包括创建和维护系统需求文档所必需的一切活动的过程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程结构如图1所示，需求开发与需求管理的流程如图2所示。

需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程有3个主要活动：需求调查、需求分析、需求定义。需求开发过程可分为两个阶段：用户需求调查阶段和产品需求定义阶段，两个阶段在逻辑上通常是以迭代的形式进行的。需求开发过程产生的主要文档有《用户需求说明书》、《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）。

需求管理的目的是在用户与开发商之间建立对需求的共同理解，维护需求与软件工作成果的一致性，并控制需求的变更。需求管理过程有三项主要活动：

（1）需求确认:开发商和用户共同对需求文档进行评审，双方就需求达成共识后做出书面承诺，使需求文档具有商业合同效果。

（2）需求跟踪:通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。

（3）需求变更控制:依据“变更申请、审批、实施、重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

需求管理过程产生的主要文档有《需求评审报告》、《需求跟踪报告》、《需求变更控制报告》等。

2．需求的跟踪

需求跟踪的目的是建立与维护“需求、设计、编程、测试”过程的一致性，确保所有的工作成果符合用户需求。需求跟踪有两种方式：

（1）正向跟踪：检查《产品需求规格说明书》中的每个需求是否都能在后继工作成果中找到对应点。

（2）逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》中找到出处。

正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。

组建变更控制管理机构

项目变更是指项目实施过程中由于环境或者其他因素的变化而对项目部分或者全部功能、性能、架构、技术指标、集成方案、进度、质量等方面做出改变。

1．变更控制管理的任务及目标

信息系统项目实施过程中变更是无法避免的。变更控制管理的任务是：建立规范、严格、可行、高效的变更控制体系机制，组建变更控制管理机构，出台变更管理制度；对用户提交的变更请求进行快速的响应、受理；及时分析、研究、评估变更的可行性、成本、代价、范围；对于确定接受的变更请求制订变更实施计划方案及配套应对措施，实施变更任务，进行变更测试检查，做好变更记录。需求变更控制的最终目标是：通过建立严格规范的变更控制管理流程,拒绝不切合实际的变更，减少变更带来的风险，防止变更范围扩大、蔓延，杜绝随意的变更申请及受理过程等。

2．变更控制管理机构的建立

组建有效的变更控制管理机构和制订配套的变更控制管理制度，是进行变更控制管理的重要基础和前提保障，否则变更控制管理将成为一纸空文。变更控制管理机构（形式上可以是“变更控制管理委员会”、“变更控制管理办公室”、“变更控制管理组”等）是一个特殊组织，对项目负责人直接负责，它不受现存的职能组织结构的束缚,可由来自不同机构、不同部门、不同专业、不同岗位的人员组成，各成员划分权限岗位、明确职责、落实责任、协同工作。一般情况下，变更控制管理机构内部应至少配备以下四种角色的成员：

项目管理人员（类似于“项目经理”）：主要负责制订项目管理制度和项目管理计划，督促、检查、落实、考核项目执行过程，做好项目干系人之间的沟通协调工作。

技术负责人员（类似于“总工程师”）：主要负责项目中信息技术平台的分析、建模、设计、测试、实现。

业务管理人员（类似于“业务经理”）：主要负责收集整理业务需求、编写需求说明书、验证和评审需求、管理和控制需求变更。

通信联络人员：主要负责项目组织内部成员之间的信息发布。

需求变更控制 管理工作程序

需求变更的目的是希望软件产品更加符合用户的需求，但是变更涉及的人员多、范围广、影响大，在进行变更控制管理时必须建立严格、规范的变更控制管理工作程序，这样才能使项目始终按照预定的方向、模式、进度进行。

需求变更控制过程中最难办的事情不是“满足用户提出的变更请求”，而是“在用户认同支持、追加项目投资经费的前提下尽快完成变更任务”。用户往往认为提出变更需求是基本权利，而软件开发商往往认为只有义务解决在《用户需求说明书》、《产品需求规格说明书》中预先定义的各类需求，除此以外都应该拒绝或者在用户追加投资的前提下解决。

现实中信息系统项目的目标是具有一定弹性的，这一点尤其重要，用户和软件开发商之间为了达成共同目标不可能针锋相对，项目管理人员需要利用高超的管理艺术、沟通技巧、人格魅力，在对立博弈的关系之中寻求最佳的平衡点。

另外，有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小；变更处理越迟，难度越大，损失也越大。而且，任何变更都必须经过项目建设全部相关方（建设单位、承建单位和监理单位）多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。