软件项目论文范文

前言：我们精心挑选了数篇优质软件项目论文文章，供您阅读参考。期待这些文章能为您带来启发，助您在写作的道路上更上一层楼。

第1篇

软件项目管理一个创造性的领域，其以满足客户特定的需求为目标，以团队的形式有效地组织企业项目资源，通过对项目进行管理和控制，实现项目的目标。在我国软件行业起步较晚，但在最近几年里得到了迅速的发展，但在应用项目管理中还存在许多的问题。

1.1对软件项目管理认识程度不足，缺乏整体把握

软件项目经理或管理人员对项目管理的知识体系没有全面的了解和把握，在实际工作中不能很好地指导项目管理实践，依靠个人原有的知识技能对项目进行随意、盲目的工作管理。在软件企业中，项目经理往往是在技术上能独当一面的指挥官，但是他们在项目管理方面知识比较缺乏，对项目管理认识程度不足，导致出现管理混乱现象。一些软件项目管理人员对项目没有一个整体的把握，对总个项目没有系统的认识，不能很全面的做出总体计划、阶段计划。由于项目中有许多不确定的因素存在，项目经理没有系统分析各个不确定因素的内在联系，考虑不周全，做计划是走过场的形式，做出的计划不能适应情况的变化，造成计划与控制管理完全是脱节，衔接不上从而无法进行有效的控制和管理。计划跟不上变化是软件项目管理中常见现象。

1.2管理思想和理念没有得到落实，风险管理不成熟

管理思想和管理理念对软件项目管理起着引导作用，对软件项目管理理论上的不足将可能导致软件项目管理的失败。我国软件项目管理发展较晚，管理人员在管理中多依靠自身的实践经验去开展工作，而对管理理论较为缺乏。部分项目经理不能总体上去管理整个项目，不能充分认识到自己是一个管理者，造成项目管理中工作任务分工不明确、资源浪费现象。从我国当前软件企业中，项目经理大多技术方面的知识扎实，但是项目管理知识、管理技能以及必备的素质都比较缺乏。特别是对软件项目管理中的风险管理认识较为肤浅，有待进一步的学习和提高。由于项目管理人员在项目管理实践中缺乏高效的管理思想，缺乏有效的方式和技巧，项目工作人员之间的团体协作能力较弱，资源整合优势难以有效发挥。

1.3缺乏有效沟通

在软件项目管理中，沟通是维持项目进行的重要条件。若在一些重要信息方面缺乏有效的沟通，将可能导致项目管理出现较多障碍。从当前我国软件企业项目管理的实践来看，普遍存在沟通机制不完善，渠道不够通畅，各相关人员之间在项目管理中制定计划、意见反馈、情况通报、技术成果等等方面沟通不足，容易造成重复劳动，效率低下等情况发生，有的甚至造成的完全可以节省的损失。在软件项目管理中项目经理需要花费大量的时间来沟通和协调，而且要善于沟通，提高沟通意识和效率。

2软件项目管理发展对策

2.1提高项目管理人员计划意识，优化人力资源配置

软件项目管理人员在工作中要以身作则，真正发挥带头作用。在工作中要及时制定符合工作需要的工作计划并认真落实。计划要具有一定的前瞻性，在客观条件发生变换的时候要不断完善细化。软件更新速度较快，企业要在软件行业发展中抢占先机，要求管理人员要重视计划的制定，不断完善和优化工作流程。在软件项目管理中，要不断优化人力资源配置，使得每位员工能够对自身职责有明确的认识，工作责任意识明确，职员之间能够做到优势互补。管理人员要具备强烈的责任心和团队意识，不断发现和培养优秀人才。

2.2树立风险管理理念，强化项目管理培训力度

我们要加强软件项目管理人员对项目管理知识学习，各方面都能充分认识到项目管理的重要性和必要性，让项目经理重视对项目管理的知识的学习和一些常用工具和方法使用。不断树立项目管理人员风险管理理念，充分意识到风险管理的重要性，经过充分分析、预测、评估可能的风险，积极探索应对风险的策略。对计划书中风险管理要具有针对性和具体性，真正发挥风险管理在防范风险中的作用。不断通过项目管理培训来强化管理人员实践能力和知识技能。只有具备管理知识和管理经验的人员才能担任管理人员和技术人员，大幅提高项目管理水平。

2.3加强沟通，从整体上对软件项目管理进行把握

软件项目管理有效开展离不开有效的沟通，这要求要不断提高沟通意识，在企业中制定切实可行的沟通机制，使得各项企业政策能够上下通达。在项目管理沟通方式上要不拘一格，实现沟通方式的多样化，如书面沟通、口头沟通，提高沟通的有效性。对于因沟通不畅导致的损失要明确责任归属，确保企业重要内容信息的有效传达。软件项目管理人员要从整体上对软件项目管理进行把握，综合考虑各因素，作出全面的总体计划、阶段计划。同时对于具体问题也要预留空间，确保管理计划能够紧跟软件管理需要。

3结语

第2篇

有时即使不开展项目管理工作，软件开发项目也能取得成功。但是如果乏项目管理，则难以将成本控制在一定范围内，容易导致软件企业面临着亏损的风险。在开展项目管理工作的过程中，需要借助技术、方法等，管理软件开发活动，如此既有助于实现软件开发目标，又能够控制软件开发的进度以及开发成本。当前，虽然有部分软件企业依据软件工程理论，制定了管理软件开发的制度，但是却没有严格控制软件开发的进度以及成本。这种做法不仅会延长软件开发的时间，还会增加软件公司的经营风险，最终损害到相关用户的利益。而在软件开发过程中，开展项目管理工作，就有助于保证软件开发工作的顺利完成，同时提高软件企业的经营管理效率。

2项目管理在软件开发中的应用现状

在二十世纪六十年代中期，人们发现了在开发软件过程中存在着很多问题，具体的问题表现在以下两个方面：一方面，不规范的生产过程；另一方面，不重视管理工作。为了能够有效解决软件开发过程中存在的问题，人们开始尝试利用过程管理方法。但是到了二十世纪八十年代，还是没有制定管理软件开发过程相关标准。近几年来，在信息技术快速发展的背景下，人们采取项目管理来控制软件开发的质量、软件开发的成本等，以此确保软件开发的质量和成本等因素，符合当时的既定标准。在软件开发过程中，每一个项目组的不同成员都应该承担不同的任务，并且企业管理者应该要求他们要在规定的时间内完成自身的任务，这种明确分工制度，有助于提高员工的工作效率。

3项目管理在软件开发中的应用

每一个软件开发项目都要经过以下几个阶段：提出问题、研究可行性、分析需求、测试等。因此项目管理工作应该贯穿于软件开发的整个过程。

3.1可行性研究

无法开发哪一个项目，都需要进行可行性分析与研究。通过利用项目管理来研究软件开发项目可行性的目的在于：在最短的时间内确定软件开发项目是否具有开发的价值。其中可行性研究的内容包括：

1）、研究技术的可行性。其主要是指：要合理地分析开发项目的功能与性能，分析其中所隐藏的技术风险。

2）、研究经济的可行性。其主要是指：估计所开发的项目给企业带来的经济效益，然后依据所估算的经济效益，确定该项目是否具有投资的价值。

3）、研究社会的可行性。其主要是指：分析此项目的运行方式是否正确，分析当前的人员技术水平以及管理制度是否具有可行性。

3.2软件项目估算

在软件开发过程中，首先要规划软件开发项目，如此便于项目管理人员制定切合实际的估算方案。规划软件开发项目的内容主要包括：明确软件开发的目标、明确软件开发过程中需要用到的各种资源、明确软件开发的进度等。在软件开发过程中，估算起着非常重要的作用。通过估算可以保证软件项目在规定的时间内完成，也可以确保软件项目的成本未超出预算。在估算资源、成本以及进度的时候，要依据自身丰富的经验以及相关的数据。但是当前所使用的估算方法较为单一，此种估算方法容易增加估算风险。对此，研究人员应该努力研究出更多科学、有效的估算方法。

3.3软件项目开发人员的管理

在开展软件项目开发人员管理工作的时候，首先要合理安排人员。通常情况下，是由多个小组成员共同完成软件开发项目。在具体安排人员任务的时候，要依据每位人员的优势进行，并且要明确小组内每一位成员的工作任务以及工作目标。在软件开发过程中，要确定不同的责任人，比如：项目经理、开发经理，并且为每一个小组安排一名组长，如此有助于确保软件开发项目的顺利完成，同时保证所开发出来的软件属于高质量产品。

4结束语

第3篇

1、估算前的规划

当我们的办公室内堆满了杂乱无章的文件时，恐怕无法知道对于我们真正有用的文件在哪里，当我们的软件相目中收集了各种需求、意见、问题时，我们也很难从中估算出整个项目的规模、工作量以及成本。因此，在估算之前我们首先要对众多信息进行整理、归类分析，从而得到一个条理清晰的项目计划，在这个计划提供的框架内，才可能开始正确的估算。精心的规划是任何一个软件开发项目成功与否的关键，有了规划就有如成竹在胸，之后无论风云变幻，都有应对入流的方法。当然只有正确的规划，才能给软件开发指引正确的方向。

软件项目规划的重点是对人员角色、任务进度、经费、设备资源、工作成果等等做出合适的安排，制定出一些计划(包括高层的和细节的)，使大家按照计划行事，最终顺利地达到预定的目标。

1.1、规划的第一步：确定软件范围

确定软件范围，就是确定目标软件的数据和控制、功能、性能、约束、接口以及可靠性。这项工作和需求分析是很类似的，如果之前已经达成需求分析规约，那么可以直接从《需求分析说明书》中把有用的部分拿来使用。如果还没有开始需求分析，关于确定软件范围的方法方面，我们可以采用许多需求分析技术(如需求诱导)，从客户那里得到一个具体的软件范围。当然如果是一次全新的软件边界探索，就应当考虑软件本身可行性问题，包括团队是否具备在技术、财务、时间、资源上游可靠的保障，软件本身在市场上是否有可靠的竞争优势，等等。

获得软件范围，最直接最可靠的来源就是用户对软件的需求描述。例如，在开发一个C/S架构的铁路供电段数据上报系统中，客户向我们提供了以下的目标软件需求描述：

在供电站总部每天结束前要审核下属节点操作员(30~40个)的供电安全数据报表，要求每个节点必须在下午5：30~6：00之间上传数据。总部系统通过自动分析，整理出整个区内的安全形势报表，并自动反馈到每个节点。各个节点之间通过调制解调器拨号(MODEM)用内部电话线相连，每个节点电脑主机配备一个MODEM。上传数据为制式报表出了制式信息外，系统自动附加操作员姓名、上报时间、上报节点名称。信息一旦上传，节点端就不可以对已提交信息进行修改、删除，只能阅读、查询。节点间数据互相隔离，只有总部才具备对各个节点数据的管理权限，但是对于归档数据(一旦审核完毕的数据，就进行归档)总部不具备删改的权限。系统设置数据库管理员，独立于审核权限，其职责是对历史数据的清理维护。

通过上面的描述，我们通过提炼和简化，得到软件的一下功能：

节点数据录入、查询、上传

总部数据汇总、查询、反馈

总部与节点的互联项目管理培训

总部数据库存储

节点数据的本地存储项目管理论坛

在本例中，软件的性能是潜在的。客户虽然没有明确提出，但是由于数据本身的重要性，要求系统在数据上传、反馈、存储过程中安全可靠。客户要求使用MODEM进行拨号连接，那么鉴于MODEM连接过程中可能会出现，由于拨号断开而道导致的数据丢失，在节点本地存放一份数据副本是有必要的。由于系统要求每天上传数据，总部数据库应当是7X24小时不间断服务的，再加上目前总部只有该系统运行接受数据任务，各节点数据量并不大，那么在建议用户选择服务器时，应当考虑性能稳定可靠，但并不一定要购买大容量磁盘阵列和高性能双CPU主机。由于每天上传数据接近下班时间，那么总部汇总数据应当是自动进行的，一旦分析发现重大问题，可以通过与外部网络的设置，向值班人员发送手机讯息、E-MAIL或其他警示。由于不同人员对于上报数据的权限不同，对于系统用户实行分级管理。不同级别的用户，具有对数据的不同管理权力，从而保证在软件使用过程中不发生混乱。

那么现在一个较为清晰的软件模型已经构造完毕，接下来我们需要进入计划的第二步：确定工作所需资源。

1.2、规划的第二步：确定工作所需资源

软件工作所需资源包括：工作环境(软硬件环境、办公室环境)、可复用软件资源(构件、中间件)、人力资源(包括不同各种角色的人员：分析师、设计师、测试师、程序员、项目经理……)。这三种资源的组成比例，可以看作一个金字塔的模式，最上面是人力资源、其次是可复用软件资源、最下面是工作环境。最上面的是组成比例最小的，最下面的是组成比例最大的部分。

■人力资源

一个项目到底需要多少种职务的人员构成、多少数量的人员总量，再能成为最有创造力的团队呢?这恐怕是最让项目经理头疼的事情了。任何一个软件工程，都必须在确定软件的工作量之后，才能清楚地知道究竟需要多少人力才能以最小成本和最高效率完成任务。在这之前，不能盲目地进行人力扩充，而且绝对不能为了给公司抬高门面，盲目招收高学历。

■可复用软件资源

这是一个容易在计划阶段被忽视的重要资源，很多人总是进入编码阶段才发现可复用资源的价值和存在。经过长期的项目积累或是购买，公司的软件资源库中或许已经积累了大量的可复用资源，但在当前任务中，只能选择有价值的资源。根据不同的应用、时间、来源，可复用软件资源被分为以下几种：

可直接使用的构件：已有的，能够从第三方厂商获得或已经在以前的项目中开发过的软件。这些构件已经经过验证及确认且可以直接用在当前的项目中。

具有完全经验的构件：已有的为以前类似于当前要开发的项目建立的规约、设计、代码、或测试数据。当前软件项目组的成员在这些构件所代表的应用领域中具有丰富的经验。因此，对于这类构件进行所需的修改其风险相对较小。

具有部分经验的构件：已有的为以前与当前要开发的项目相关的项目建立的规约、设计、代码、或测试数据，但需做实质上的修改。当前软件项目组的成员在这些构件所代表的应用领域中仅有有限的经验，因此，对于这类构件进行所需的修改会有相当程度的风险。

新构件：软件项目组为满足当前项目的特定需要而必须专门开发的软件构件。

在采用构件的时候，应当以低成本、低风险为使用前提。如果任何一个漂亮的构件的应用，可能会带来潜在出错的风险或者必须经过复杂修改或者效率低下时，我们都应当毫不犹豫地把它抛弃。我们只采用那些能够满足项目的需要且可直接使用的构件，或者具有完全经验的构件，或者经过稍微修改便可使用的构件。项目经理博客

■环境资源

“工欲善其事，必先利其器”，要得到高效的开发过程，就必须向工作人员提供良好的软硬件环境，包括开发工具、开发设备、工作环境、管理制度。一般管理人员都会购买可以满足需要的软件开发工具和硬件平台，但是工作环境和管理制度往往被忽视。项目管理者联盟

站在人件的角度看，向工作人员提供更轻松自在、安静舒适的办公环境的公司员工往往比整天在狭小隔间中工作的公司员工，产生更高的工作效率。而那些拥有灵活人性化的管理制度的公司，比整天加班的公司更能留住高技术的人才。所以如何在有限资金中，规划一个合理的环境是很重要的事情。转

到此为止，估算前的项目计划已经完成，我们已经形成一个工程开发框架。这是一个有界限的框架，虽然还不够精确，但足以进行估算的工作。

2、估算的对象

目前为止，一个较为准确的软件项目估算的定义是：在给定公差范围内，对于姚开发的软件规模的预测，以及对开发软件所需的工作量、成本和日历事件的预测。这个概念指出了一个事实，即估算是一种大约的估计，是将误差限定在一定范围内的估计。

估算主要包括以下几个重要内容：

规模估算

软件估算首先要将整个工程的规模估算出来，才能进行下面的其他估算。规模，就是一个工程可量化的结果，是用具体数字来体现项目的描述。规模估算的信息来源是清晰、有界限的用户需求。

工作量估算

这是对开发软件所需的工作时间的估算，它和进度估算一起决定了开发团队的规模和构建。通常以人时、人天、人月、人年的单位来衡量，这些不同单位之间可以进行合理的转换。

进度估算

进度时项目自始至终之间的一个时间段。进度以不同阶段的里程碑作为标志。进度估算是针对以阶段为单位的估算，而不是对每一个细小任务都加以估算，对任务的适当分解很重要，分解得越细反而会不准确。因为任何一个软件工程，在各个方面都有与生俱来的不确定性。

成本估算

包括人力、物质、有形的、无形的支出成本估算，其中以人力成本为主要部分。比较容易被忽视的使学习成本、软件培训成本、人员变动风险成本、开发延期成本等，一些潜在成本消耗。

3、估算的策略

在软件估算的众多方法中，存在着“自顶向下”和“自底向上”两种不同的策略，两种策略的出发点不同，适应于不同的场合使用。项目管理培训

3.1、自顶向下的策略

这是一种站在客户的角度来看问题的策略。它总是以客户的要求为最高目标，任何估算结果都必须符合这个目标。其工作方法是，由项目经理为主的一个核心小组根据客户的要求，确定一个时间期限，然后根据这个期限，将任务分解，将开发工作进行对号入座，以获得一个估算结果。项目管理者联盟文章

当然由于这完全是从客户要求出发的策略，而由于软件工程是一个综合项目，几乎没有哪个项目能完全保质保量按照预定工期完工，那么这样一个策略就缺少了许多客观性。但是由于这样完成的估算比较容易被客户、甚至被项目经理所接受，在许多公司我们看到这样一个并不科学的策略仍然被坚定地执行着。项目管理培训

3.2、自底向上的策略

与自顶向下的策略完全相反，自底向上的策略是一种从技术、人性的角度出发看问题的策略。在这样一个策略指引下，将项目充分讨论得到一个合理的任务分解。在将每个任务的难易程度，每个任务依照项目成员的特点、兴趣特长进行分配，并要求进行估算。最后将估算加起来就是项目的估算值。

显然自底向上的这种策略具有较为客观的特点，但是它的缺点就是这样一来项目工期就和客户的要求不一致了。而且由于其带来的不确定性，许多项目经理也不会采用这种方法。项目经理圈子

4、估算的方法项目管理者联盟

显然估算是建立在客观实际上，对未来尽可能合理的一种预测。那么估算本身的不确定性，决定了它不可能是百分之百准确无误的。在项目刚开始时，人们对产品需求、技术、市场预期、人员素质等因素的了解还远远不够，在这种情况下人们很难作出准确的估计。但是依据某种方法进行估计显然比瞎猜好得多。项目管理者联盟文章

估算方法有很多，大致分为基于分解的技术和基于经验模型两大类。基于分解的技术的方法包括功能点估算法、LOC估算法、MARKII等;基于经验模型的方法包括IBM模型、普特南模型、COCOMO模型等。

4.1、FP功能点估算法项目管理论坛

功能点估算法是一种在需求分析阶段基于系统功能的一种规模估计方法。通过研究初始应用需求来确定各种输入、输出、计算和数据库需求的数量和特性。这种方法的计算公式是：功能点=信息处理规模x技术复杂度。信息处理规模包括各种输入、输出、查询、内部逻辑文件数、外部接口文件数等等;技术复杂度包括性能复杂度、配置项目复杂度、数据通信复杂度、分布式处理复杂度、在线更新复杂度等等。项目管理论坛

4.2、LOC估算法

这是一种从技术的角度来估算的方法总称，其中又包含许多方法。这类方法以代码(LOC)作为软件工作量的估算单位，在早期的系统开发中较为广泛使用。基于LOC的估算，又有点也有缺点。优点在于方便计算、容易监控、能反映程序员的思维能力;缺点在于代码行数的含糊不清，不能正确反映一项工作的难易程度以及代码的效率。因此在传统的LOC方法进行了许多改进。其中不断被使用，且不断演化的方法包括以下：

PERT功能点估算法：PERT对各个项目活动的完成时间按三种不同情况估计：一个产品的期望规模，一个最低可能估计，一个最高可能估计。用这三个估计用来得到一个产品期望规模和标准偏差的Pert统计估计，Pert估计可得到代码行的期望值和标准偏差SD。项目管理论坛

类比估算法：类比法适合评估一些与历史项目在应用领域、环境和复杂度的相似的项目，通过新项目与历史项目的比较得到规模估计。类比法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比法的前提条件之一是组织建立起较好的项目后评价与分析机制，对历史项目的数据分析是可信赖的。

Delphi估算法：Delphi法是一种专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来，新技术与特定程序之间的差别。对于需要预测和深度分析的领域，依赖于专家的技术指导，可以获得较为客观的估算。通过专家们的互相讨论，还可以博取众长

系统分解：将系统分成若干个易于用LOC估算的部分，将其各个估算结果累加就是LOC的总规模。其中关键是建立起SBS(系统分解结构)，它描述了系统的不同组件。SBS还被使用在其他重要的地方，如系统设计、系统分析等。在进行分解的时候，可以采用自由讨论的形式，可以获得更合理的SBS构成。项目经理圈子

4.3、IBM模型估算法

该模型是Watson和Felix在1977年的，是基于IBM联合系统分布负责的60个项目的总结而得到的模型。该模型是一个静态模型，而参考数据只有60多个项目，因此有很大的局限性。

4.4、COCOMO估算法转自项目管理者联盟

Boehm在其经典著作“软件工程经济学”(softwareengineeringconomics)中，介绍了一种软件估算模型的层次体系，称为COCOMO(构造性成本模型，COnstructiveCOstMOdel)，它代表了软件估算的一个综合经验模型。项目经理博客

COCOMO模型是适用于三种类型的软件项目：(1)组织模式——较小的、简单的软件项目，有良好应用经验的小型项目组，针对一组不是很严格的需求开展工作(如，为一个热传输系统开发的热分析程序);(2)半分离模式——一个中等的软件项目(在规模和复杂性上)，具有不同经验水平的项目组必须满足严格的及不严格的需求(如，一个事务处理系统，对于终端硬件和数据库软件有确定需求);(3)嵌入模式——必须在一组严格的硬件、软件及操作约束下开发的软件项目(如，飞机的航空控制系统)。

4.5、软件方程式估算法项目管理论坛

软件方程式是一个多变量模型，它假设在软件开发项目的整个生命周期中的一个特定的工作量分布。该模型是从4000多个当代的软件项目中收集的生产率数据中导出的公式。初期的方程式较为复杂，通过，Putnam和Myers的努力又提出一组简化的方程式。当然这种方法也是基于长期的参考数据的积累而得到的。

4.6、WBS估算法w

这是一种基于WBS(工作任务分解)的方法，即先把项目任务进行合理的细分，分到可以确认的程度，如某种材料，某种设备，某一活动单元等。然后估算每个WBS要素的费用。采用这一方法的前提条件或先决步骤是：项目管理者联盟

对项目需求作出一个完整的限定。

制定完成任务所必需的逻辑步骤。

编制WBS表。

项目需求的完整限定应包括工作报告书、规格书以及总进度表。工作报告书是指实施项目所需的各项工作的叙述性说明，它应确认必须达到的目标。如果有资金等限制，该信息也应包括在内。规格书是对工时、设备以及材料标价的根据。它应该能使项目人员和用户了解工时、设备以及材料估价的依据。总进度表应明确项目实施的主要阶段和分界点，其中应包括长期定货、原型试验、设计评审会议以及其他任何关键的决策点。如果可能，用来指导成本估算的总进度表应含有项目开始和结束的日历时间。

除了以上介绍的几种方法外，还有一些其他的方法：类比估算、推测估算、Standard-component估算法、普特南估算法等。当然不同的方法适用于不同的具体环境，有些方法虽然很好但并不一定适合当前的任务。只有量体裁衣，具体问题具体分析，才能得到尽量合理的估算。

5、估算的戒律项目管理者联盟

记住：应该满足于事物的本性所能容许的精确度，当只能近似于真理时，不要去寻求绝对的准确??——亚里斯多德

对于任何一个项目经理，都知道要慎重估算，但是我们仍然会看到人力资源的浪费和财力资源的匮乏，在许多项目中存在。对于宝贵的资源，我们不是用得太多，就是根本不够用。因此，有以下前人总结出来的一些经验以供借鉴。

不要追求完美：就像没有人能预测出未来，如果还没有完成，就不要企图完美的结果。更何况估算的太精确，反而会失去灵活机动的空间。

不要为满足预算而估算：如果这个项目的预算根本不能完成100%的任务，那么就不要让你的团队委曲求全。正确地反映客观现状，不仅可以争取应得的权利，而且是完成任务的前提。

不要随意削减估算结果：有很多老板喜欢把项目经理递交的估算，不假思索地砍掉一部分。这是一种不负责任的做法，如果要削减一定要有理由。

客观地估算，不贪多不偷减：就像老板不能随便削减你的估算一样，你也同样不能在估算的时候，贪多或是偷减。贪多必然导致会浪费，偷减必然导致不足。这两个结果恐怕都不是一个合格的项目经理的作为。

客观利用过去的经验：对于以往估算的经验，当然是宝贵的财富，但是如果财富用错了地方就会变成垃圾。在使用经验时，要注意现在和参考经验之间的差异。不要忘记，随着时间的推移，计算机领域技术的更新，许多观念都在发生着改变。项目管理培训

第4篇

一般来说，软件工程师总是非常乐观。当他们在计划软件项目时，经常认为每件事情都会像计划那样运行，或者，又会走向另外一个极端。软件开发的创造性本质意味着我们不能完全预测会发生的事情，因此制定一个详细计划的关键点很难确定。当有预想不到的事情引起项目脱离正常轨道时，以上两种观点都会导致软件项目的失败。

目前，风险管理被认为是IT软件项目中减少失败的一种重要手段。当不能很确定地预测将来事情的时候，可以采用结构化风险管理来发现计划中的缺陷，并且采取行动来减少潜在问题发生的可能性和影响。风险管理意味着危机还没有发生之前就对它进行处理。这就提高了项目成功的机会和减少了不可避免风险所产生的后果。

2什么是风险

所谓“风险”，归纳起来主要有两种意见，主观说认为，风险是损失的不确定性；客观学认为，风险是给定情况下一定时期可能发生的各种结果间的差异。它的两个基本特征是不确定性和损失。IT行业中的软件项目开发是一项可能损失的活动，不管开发过程如何进行都有可能超出预算或时间延迟。项目开发的方式很少能保证开发工作一定成功，都要冒一定的风险，也就需要进行项目风险分析。在进行项目风险分析时，重要的是要量化不确定的程度和每个风险相当的损失程度，为实现这一点就必须要考虑以下问题：

要考虑未来，什么样的风险会导致软件项目失败？

要考虑变化，在用户需求、开发技术、目标、机制及其它与项目有关的因素的改变将会对按时交付和系统成功产生什么影响？

必须解决选择问题，应采用什么方法和工具，应配备多少人力，在质量上强调到什么程度才满足要求？

要考虑风险类型，是属于项目风险、技术风险、商业风险、管理风险还是预算风险等？

这些潜在的问题可能会对软件项目的计划、成本、技术、产品的质量及团队的士气都有负面的影响。风险管理就是在这些潜在的问题对项目造成破坏之前识别、处理和排除。

3风险管理

项目风险管理实际上就是贯穿在项目开发过程中的一系列管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。它能让风险管理者主动“攻击”风险，进行有效的风险管理。

在项目管理中，建立风险管理策略和在项目的生命周期中不断控制风险是非常重要的，风险管理包括四个相关阶段：

风险识别识别风险的方法常用的有风险识别问询法（座谈法、专家法）、财务报表法、流程图法、现场观察法、相关部门配合法和环境分析法等。

风险评估对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：概率分布、外推法、多目标分析法等。

风险处理一般而言，风险处理有三种方法，①风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。②风险自留，当风险量不大时可以余留风险。③风险转移。

风险监控包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。

在IT软件项目管理中，应该任命一名风险管理者，该管理者的主要职责是在制订与评估规划时，从风险管理的角度对项目规划或计划进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是由项目主管以外的人担任。

险识别

风险识别就是企图采用系统化的方法，识别某特定项目已知的和可预测的风险。常用方法是建立“风险条目检查表”，利用一组提问来帮助项目风险管理者了解在项目和技术方面有些风险。在“风险条目检查表”中，列出了所有可能的与每一个风险因素有关的提问，使得风险管理者集中来识别常见的、已知的和可预测的风险，如产品规模风险、依赖性风险、需求风险、管理风险及技术风险等。“风险条目检查表”可以以不同的方式组织，通过判定分析或假设分析，给出这些提问确定的回答，就可以帮助管理或计划人员估算风险的影响。软件项目一般有如下五类风险：

4.1产品规模风险

有经验的项目经理都知道：项目的风险是直接与产品的规模成正比的。与软件规模相关的常见风险因素有：

估算产品的规模的方法（LOC或代码行，FP或功能点，程序或文件的数目）。

产品规模估算的信任度

产品规模与以前产品规模平均值的偏差

产品的用户数

复用的软件有多少

产品的需求改变多少

4.2需求风险

很多项目在确定需求时都面临着一些不确定性和混乱。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造正确的产品。每一种情况都会导致使人不愉快。

与客户相关的风险因素有：

对产品缺少清晰的认识

对产品需求缺少认同

在做需求中客户参与不够

没有优先需求

由于不确定的需要导致新的市场

不断变化需求

缺少有效的需求变化管理过程

对需求的变化缺少相关分析

4.3相关性风险

许多风险都是因为项目的外部环境或因素的相关性产生的。经常我们不能很好地控制外部的相关性，因此缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并且觉察潜在的问题。与外部环境相关的因素有：

客户供应条目或信息

内部或外部转包商的关系

交互成员或交互团体依赖性

经验丰富人员的可得性

项目的复用性

4.4管理风险

尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，并且大部分人都不希望在公共场合暴露自己的弱点。然而，像这些问题可能会使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：

计划和任务定义不够充分

实际项目状态

项目所有者和决策者分不清

不切实际的承诺

员工之间的冲突

4.5技术风险

软件技术的飞速发展和经历丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、雇佣顾问以及为项目团队招聘合适的人才等。主要有下面这些风险因素：

缺乏培训

对方法、工具和技术理解的不够

应用领域的经验不够

新的技术和开发方法

不能正确工作的方法

5风险估计

风险估计，又称风险预测，常采用两种方法估价每种风险。一种是估计风险发生的可能性或概率，另一种是估计如果风险发生时所产生的后果。一般来讲，风险管理者要与项目计划人员、技术人员及其他管理人员一起执行四种风险活动：

（1）建立一个标准（尺度），以反映风险发生的可能性。

（2）描述风险的后果。

（3）估计风险对项目和产品的影响。

（4）确定风险的精确度，以免产生误解。

另外，要对每个风险的表现、范围、时间做出尽量准确的判断。对不同类型的风险采取不同的分析办法。

1．确定型风险估计

（a）盈亏平衡分析

盈亏平衡分析（Break-EvenAnalysis）通常又称为量本利分析或损益平衡分析。它是根据软件项目在正常生产年份的产品产量或销售量、成本费用、产品销售单价和销售税金等数据，计算和分析产量、成本和盈利这三者之间的关系，从中找出它们的规律，并确定项目成本和收益相等时的盈亏平衡点的一种分析方法。在盈亏平衡点上，软件项目既无盈利，也无亏损。通过盈亏平衡分析可以看出软件项目对市场需求变化的适应能力。

（b）敏感性分析

敏感性分析（SensitivityAnalysis）的目的，是考察与软件项目有关的一个或多个主要因素发生变化时对该项目投资价值指标的影响程度。通过敏感性分析，使我们可以了解和掌握在软件项目经济分析中由于某些参数估算的错误或是使用的数据不太可靠而可能造成的对投资价值指标的影响程度，有助于我们确定在项目投资决策过程中需要重点调查研究和分析测算的因素。

（c）概率分析

它是运用概率论及数理统计方法，来预测和研究各种不确定因素对软件项目投资价值指标影响的一种定量分析。通过概率分析可以对项目的风险情况做出比较准确的判断。主要包括解析法和模拟法（蒙特卡罗MonteCarlo技术）两种。

2．不确定型风险估计

主要有小中取大原则、大中取小原则、遗憾原则、最大数学期望原则、最大可能原则。

3．随机型风险估计

主要有最大可能原则、最大数学期望原则、最大效用数学期望原则、贝叶斯后验概率法等。

5.1建立风险清单

风险清单是关键的风险预测管理工具，清单上列出了在任何时候碰到的风险名称、类别、概率及该风险所产生的影响。其中整体影响值可对四个风险因素（性能、支持、成本及进度）的影响类别求平均值（有时也采用加权平均值）。

一旦完成了风险表的内容，就可以根据概率及影响来进行综合考虑，风险影响和出现概率从风险管理的角度来看，它们各自起着不同的作用（见图1）。一个具有高影响但低概率的风险因素不应当占用太多的风险管理时间，而具有中到高概率、高影响的风险和具有高概率及低影响的风险，就应该进行风险分析。

5.2风险评估

在风险分析过程中，我们对风险进行评估时可以建立一个如下的四元数组：

[ri,li,xi，yi]

其中，ri是风险，li为风险出现的概率，xi则表示风险损失大小，yi则表示期望风险。

一种对风险评估的常用技术是定义风险的参照水准，对绝大多数软件项目来讲，风险因素——成本、性能、支持和进度就是典型的风险参照系。也就是说对成本超支、性能下降、支持困难、进度延迟都有一个导致项目终止的水平值。如果风险的组合所产生的问题超出了一个或多个参照水平值时，就终止该项目的工作，在项目分析中，风险水平参考值是由一系列的点构成的，每一个单独的点常称为参照点或临界点。如果某风险落在临界点上，可以利用性能分析、成本分析、质量分析等来判断该项目是否继续工作。图2表示了这种情况。

但在实际工作中，参照点很少能构成一条光滑的曲线，大多数情况下，它是一个区域，而且是个易变的区域。因而在做风险评估时，尽量按以下步骤执行：

（1）定义项目的水平参照值

（2）找出每组[ri,li,xi，yi]与每个水平参照值间的关系

（3）估计一组临界点以定义项目的终止区域

（4）估计风险组合将如何影响风险水平参照值

5.3估计损失的大小

表1是风险分析表的一个例子，可以建立一个用风险、损失概率、损失大小和期望风险这样的风险评估表。

在表1所示的风险估价的例子中，一个理论项目已经识别了从1到20周期间的潜在的几个风险，风险发生的概率范围在5%到50%之间。在现实的项目中，可能会识别出比此表要多得多的风险。

损失的大小常常比概率更容易受到控制。在以上的例子中，可以很精确地估计出完全支持自动从主机更新数据的时间是20个月。根据管理层将在何时讨论项目建议书,可以知道项目不是在2月1日就是3月1日会被批准。如果假定会在2月1日批准，项目被批准的风险大小会比期望的长一些，也就是1个月时间。

如果损失的大小不容易直接估计出来，可以将损失分解为更小的部分，再对其进行评估，然后将各部分评估结果累加，形成一个合计评估值。例如，如果使用3种新编程工具，可以单独评估每种工具未达到预期效果的损失，然后再把损失加到一起，这要比总体评估容易多了。

5.4评估损失的概率

评估损失的概率要比评估损失大小更具有主观性。这里有许多实践方法可以提高主观评估的准确度。有以下方法：

由最熟悉系统的人评估每个风险的发生概率，然后保留一份风险评估审核文件。

使用Delphi法或少数服从多数的方法。使用Delphi法，必须要求每个人对每个风险进行独立地评估，然后讨论（口头或纸上）每个评估的合理性，特别是最高和最低的那个。一轮轮讨论，直到达成共识。?使用“形容词标准”。首先让每个人用表示可能性的形容词短语选择风险的级别，如非常可能、很可能、可能、或许、不太可能、不可能、和根本不可能。然后把可能性的评估转换为数量化的评估（Boehm1989）。

5.5整个项目超限和缓冲

实际上，表1中表示的期望风险的计算数值来源于一个被称为“期望值”的统计术语。设计欠佳引起的风险如果真正发生将花费15周的时间。既然它不是100%地会发生，当然不能预计损失15周时间。但它也不是没有可能发生，所以也不应指望不会发生损失。统计学认为，预计损失的数量是概率乘以损失大小，即15%乘以15周。因此，在这个例子中，预计的是损失2.25周。由于只是谈论计划风险，可以累加所有的风险暴露量来得到项目的全部可预料超标值。这个项目可预料的超标值是12.8到13.2周，这就是如果不做任何风险管理的话有可能超过计划的周数。

超出预期值的大小为整个项目风险控制级别的确定提供了依据。如果例子中的项目是个25周的项目，超出预期值的12.8到13.2周就很明显需要进行风险管理了。

6风险管理策略

风险管理策略就是辅助项目组建立处理项目风险的策略。项目开发是一个高风险的活动，如果项目采取积极的风险管理策略，就可以避免或降低许多风险，反之，就有可能使项目处于瘫痪状态。一般来讲，一个较好的风险管理策略应满足以下要求：

（1）在项目开发中规划风险管理，尽量避免风险

（2）指定风险管理者，监控风险因素

（3）建立风险清单及风险管理计划

（4）建立风险反馈渠道

7风险驾驭和监控

风险的驾驭与监控主要靠管理者的经验来实施，它是利用项目管理方法及其它某些技术，如原型法、软件心理学、可靠性等来设法避免或转移风险。风险的驾驭和监控活动可用图3来表示。

7.1建立风险驾驭与监控计划

从图3中可以看出，风险的驾驭与监控活动要写入RMMP（RiskMonitoringandManagementPlan风险驾驭与监控计划）。RMMP记述了风险分析的全部工作，并且作为整个项目计划的一部分为项目管理人员所使用。

风险管理策略可以包含在软件项目计划中，也可以组织成一个独立的风险缓解、监控和管理计划（RMMP计划）。RMMP计划将所有风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分来使用。一旦建立了RMMP计划，且项目开始启动，则风险缓解及驾驭及监控步骤也开始了。正如前面讨论的，风险缓解是一种问题避免活动。风险驾驭及监控则是一种项目跟踪活动，它有三个主要目标：?判断一个预测的风险是否事实、是否发生。

进行风险再估计，确保针对某个风险而制定的风险消除活动正在使用。

收集可用于将来进行风险分析的信息。

风险驾驭及监控的策略如下：

与在职人员协商，确定人员流动原因。

在项目开始前，把缓解这些流动原因的工作列入风险驾驭计划。

项目开始时，要作好人员流动的思想准备，并采取一些措施确保人员一旦离开时，项目仍能继续。

制定文档标准，并建立一种机制，保证文档及时产生。

对所有工作进行细微详审，使更多人能够按计划进度完成自己的工作。

对每个关键性技术人员培养后备人员。

在考虑风险成本之后，决定是否采用上述策略。

7.2软件项目风险追踪工具

追踪风险的一个办法是将风险输入缺陷追踪系统中，缺陷追踪系统能将风险项目标示为已解决或尚未处理等状态，也能指定解决问题的项目团队成员，并安排处理顺序。可将软件风险项目依序排列出来，按照缺陷存在的时间与负责者等资料排列。这样，缺陷追踪系统就是追踪风险的工作能更好执行并且不那么单调。

第5篇

[关键词]项目管理软件需求开发进度成本质量管理模型

一、引言

软件需求开发是软件工程的一个重要环节，在软件生命周期中的需求、设计、编码、测试和维护等各个阶段中，需求开发处于软件工程的开始部分，它提供构建软件项目的根基，决定软件开发成果满足客户需求的匹配程度。软件需求开发环节的失误会随着开发进度的扩大而蔓延，资料表明，软件项目中由于需求开发管理混乱而造成的返工开销几乎占了总开发的50％。本文应用项目管理理论分析软件需求开发阶段的系统构成，并设计管理模型来提高软件需求开发的管理效率。

二、软件需求开发管理过程

由于计算机技术的迅速发展，使得软件需求具有模糊性、不确定性、变化性、主观性等特点，并带来软件需求开发管理的复杂性。软件需求开发是一定的组织利用有限的资源在规定的时间内完成，可以作为项目来进行管理，其管理过程由需求获取、需求分析、编写软件需求规格和需求验证四个阶段构成。

1.需求获取

需求获取是在问题和最终解决方案之间架设桥梁，其主要任务是和用户方的领导层、业务层人员进行沟通，获取用户的具体需求，并了解用户的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况，同用户建立起良好的沟通渠道和方式。软件需求获取的方法有：与用户交谈，向用户提问题；参观用户的工作流程，观察用户的操作；用户工作的情景分析；现有系统的问题报告和改进要求，事件和响应；市场调查和向用户群体发调查问卷；与同行、专家交谈，听取他们的意见；分析已经存在的同类软件产品，提取需求；从现有产品或竞争产品的文档中提取需求；从行业标准、规则中提取需求；从Internet上搜查相关资料等。

2.需求分析

需求分析主要通过建立业务模型的方式来描述用户的功能需求，为客户、用户、开发方等不同参与者提供一个交流的渠道。业务模型可以映射出软件产品的核心需求，即功能需求。功能需求应描述软件提供的功能和服务、对输入的响应，并描述特定条件下的系统构成等。软件产品本身可能还存在与业务无直接关系的非功能需求，具体与系统的总体特性有关，如可靠性、响应时间、存储空间等。非功能需求定义系统提供服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。通常这两类需求构成软件需求的总集。

3.编制软件需求规格

软件需求规格的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础，需求分析完成的标志就是提交一份完整的软件需求规格说明书。软件需求规格说明书以一种开发人员可用的技术形式阐述软件必须提供的功能和具备的性能，以及必须考虑的限制条件。软件项目客户通过软件需求规格了解软件项目能够提供的软件产品，检查软件需求是否满足需要；项目管理人员根据软件需求规格制定项目的开发计划和管理过程；软件开发人员通过软件需求规格理解要开发的产品及具体要开发的内容；软件测试人员通过软件需求规格验证软件。

4.需求评审

编写的软件需求规格说明书还应当进行需求评审，确保需求确定的科学性。可采用下列指标进行评审：(1)正确性:每条需求都正确代表构建软件系统所要完成的事情。(2)无歧义:每条需求只有一种解释。(3)完备性:需求不能发生遗漏，应全面考虑相关问题。(4)一致性:用户需求必须和业务需求一致，功能需求必须和用户需求一致。(5)重要性和稳定性分级:现有资源不足以实现所有需求时，可以根据级别的高低决定实现的先后，舍弃一些级别低的需求以保证项目的按期交付。(6)可验证性:需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。(7)可修改性:每一条需求都易于完整一致的进行变更，且不改变需求集的结构和风格。(8)可跟踪性:每条需求都是可溯源的，且存在一种机制使得在以后的工作中引用需求是可行的。(9)可理解性:用户和开发人员都完全理解需求集的整体行为、所提供的功能及其中的每条需求的含义。

三、软件需求开发管理模型

1.软件需求开发管理模型构建原则

软件需求开发是一项复杂的系统工程，管理模型的构建应遵循下列原则:(1)程序性原则：软件需求开发管理应遵循固定的业务流程，可将其划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段，前一阶段的工作完成后才能进入下一阶段。(2)系统性原则：软件需求开发要在限定的时间、成本条件约束下达到一定的质量，实现软件系统的最优，要求管理遵循系统管理原则，实现目标最优。(3)简化性原则：化繁为简，将模糊的、潜在的复杂问题明确化，以图表的形式表示出，并以简化的解决方案解决问题，便于项目管理。(4)平衡性原则：管理软件需求开发的具体事务要有一定的侧重。对于需求开发过程事项，应根据影响大小分清主次，关键的事项或者事项里的某个多发问题点，着重管理，达到在管理上的主次平衡。(5)高效性原则:模型的设计必须以促进需求开发目标的实现为前提，提供给相关人员一个展示需求开发管理和有效解决方案的平台。（6）时时控制性原则:及时控制需求开发过程中影响进度、成本、质量等问题，及时发现解决冲突事件，做到事前、事中、事后控制，保证项目按时保质保量完成。(7)动态性原则:开发中应关注信息技术的发展，将先进的技术应用到软件需求开发中，并学习借鉴相关软件需求开发的成果。

2．软件需求开发管理模型

基于以上分析，本文构建了软件需求开发管理模型，见下图：

该模型遵循了软件需求开发的管理流程。启动阶段，软件开发进行了可行性研究，软件项目已立项，项目正式启动。软件需求开发管理阶段是模型的主要部分，按照项目流程，依次划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段。总结阶段，对软件需求开发管理进行总结，并进入到软件程序设计阶段。模型的核心部分是应用项目管理的进度管理、成本管理、质量管理，对软件需求开发进行动态管理。进度管理就是制定出经济合理的进度计划，然后在计划执行过程中，检查实际进度与计划进度之间的差异，并及时找出出现差异的原因，采取有效的补救措施，以确保项目按时按质完成。进度管理应加强沟通，掌握可能延误进度的环节，并严格控制进度变更。成本管理就是对项目所需的成本情况进行详细地分析和估算，编制资源需求计划，并编制项目所需的成本估算和预算，在执行过程中，采取相应的措施对项目成本进行控制。成本管理应严格控制加班、浪费等额外支出。质量管理是为了保证项目的可交付成果能够满足客户的需求，围绕项目质量而进行的计划、协调和控制等活动，其具体内容涉及质量规划、实施质量保证和质量控制。通过进度管理、成本管理和质量管理，使软件需求开发成为进度快、成本低和质量合格的有机统一体。

该模型规范了软件需求开发的业务流程，并在整个软件需求开发的不同环节之间建立联系，明确需求开发过程与自身各任务项之间以及项目其余环节所存在的各种联系。模型各环节间的相关性、可追溯性保证了软件项目需求开发过程，可以遵循统一的管理模式。该模型具备可配置性。每个软件项目，都具有个性化管理需求，在进度管理、成本管理、质量管理等方面有不同的要求，可以针对具体的开发团队，项目要求，管理侧重点，扩增相应的管理模块，将此模型推广到任何一个软件需求开发项目。

3.模型应用

由于软件需求开发具有复杂性，其主要表现为需求描述问题，明确表达需求较难确定，并且难以统一；需求完备问题，需求没有遗漏，难以准确划定系统范围；需求的变更问题，需求变化是永恒，需求不可能是完备。模型应用需做好以下工作：（1）文档化管理。需求必须有文档来记录，该文档必须是正确的，是经过验证的，是在受控的状态下变更的。开发或管理人员常常会在含糊的情况下把认为是相对简单的需求忽视而省略文档记录，其实未必简单，只有想清楚、写清楚、说清楚才说明已经真正把需求整理清楚了，同时方便日后维护工作的展开。需求含糊的情况下要进行会议形式处理，并邀请相关人员参加进行需求澄清及确定，需求在进行多方确定后进行归档。同时软件需求的复用率也是相当高的，可以避免升级时重新将需求再次获取，只需要在原来的基础上作为文挡需求复用升级处理。（2）审核评估需求变更，减少变更的影响。在管理软件开发过程中，需求渐变是必然的，无论需求变化的程度如何，只要需求变更就必须进行评估。在需求变更之前必须由项目管理人员审核，再传给开发人员进行评估等工作。管理人员必需依据对整套系统的了解程度分析需求变更过程中可能受影响的系统及受关联的功能模块，并制定积极应对措施。(3)整体管理。应识别、确定、结合、统一与协调软件需求开发管理过程中所需要进行的各种过程和活动，保证进度、成本、质量等各要素的相互协调。

四、结语

软件需求开发在软件项目管理中具有重要地位。本文应用项目管理理论，设计了软件需求开发管理模型。该模型遵循项目管理流程，将软件需求开发划分启动、需求开发过程、总结三个阶段，并将软件需求开发过程划分为需求获取、需求分析、编写软件需求规格和需求验证四个阶段，模型应用项目管理的进度管理、成本管理、质量管理，对软件需求开发进行动态管理，实现软件需求开发项目目标最优。该模型能够提高软件需求开发管理效率，确保软件开发能够按进度，低成本，高质量地完成。

参考文献：

[1]景慎艳:软件项目需求管理的探索与实践[J].电脑知识与技术，2008（27）

[2]左怀远:软件项目中的风险管理研究[J].世界科技研究与发展，2008（3）

[3]孙琦龙:加强软件项目管理的实践模式[J].科技信息，2008（7）

第6篇

1.TRIZ理论在软件设计类课程教学中的作用

TRIZ是俄语теориирешенияизобретательскихзадач的英文音译缩写，其中文全称是发明问题解决理论。TRIZ理论是由前苏联以阿列赫舒列尔（G•S•Altshuller）为首的研究人员在研究了近250万件涉及各学科领域的发明专利的基础上总结出来的。TRIZ理论成功地揭示了发明创造的内在规律和原理，它是一种创新方法理论体系，运用TRIZ理论可大大加快人们创造发明的进程而且能得到高质量的创新产品。运用TRIZ理论的工具和手段改进教学方法，将TRIZ理论与学生创新能力培养相结合，最终用以进行软件设计类课程创新性教学的实践。这些都将为学生未来的专业发展提供广阔空间，以应对激烈的行业竞争。

2.项目导向教学方式对软件设计类课程教学的作用

项目导向教学方式是在案例教学法之上发展起来的。只不过单纯的案例教学法中案例零散，相互之间没有联系或联系不大。而项目导向教学方式则在整个课程体系中以统一的项目进行引导，对课程内容体系中涉及的所有知识点作为小项目整合入大项目开发中。类似的教学法均属于建构主义理论指导下的教学方法。因为建构主义的观点认为，学生是学习的主体，知识获得的方法主要依靠学生去发现，教师为学生获得知识创设情境，引导和帮助学生通过意义建构获得知识，让学生在意义建构的过程中进行创造。在软件设计类课程中项目导向的教学方式较好地模拟了真正软件项目开发的全过程，能够给学生以任务的刺激，将帮助学生提高学习兴趣，增强主动学习意识，同样有助于学生创新意识的培养。

二、TRIZ理论与项目导向教学方式在软件

设计类课程中的应用对于学生软件设计能力的培养，高等学校计算机相关专业通常都有较为完整的课程体系。一般包括三个层次，即软件工程方面的基础理论课、培养学生软件设计思维的基础语言课、当前流行的软件设计开发工具课程（java、MyEclipse、NET等）。笔者所在院系的教研团队在计算机相关课程中一直采用项目导向的教学方式，并且，通过自己所承担的课程针对TRIZ理论在相应教学环节中进行了一定的实践应用，取得了一定的成果。TRIZ理论与项目导向教学方式在教学中的综合应用对教师教学思维的拓展，对学生学习兴趣、自主学习能力、创新意识和创新能力的培养都起到了较为积极的作用。其相应的应用不仅要具体建立在某门课程中，更应自始至终贯穿在所有的教学与学习环节中。

1．TRIZ理论与项目设计思维在教学中的引入

（1）软件项目的开发过程与重点。任何项目的开发与市场应用均离不开“解决问题的意识”、“针对问题的思考”、“围绕问题的设计”、“具体环节的实施”、“成形项目的市场运作”、“市场反馈与项目支持”以及“对应问题的继续关注”等多个环节的内容。目前的项目教学重点以关注“具体环节的实施”这一步骤为主，从人才系统培养这一角度上来讲显然是片面的、较低级的。因为人才的培养贵在具有解决问题的意识和设计上的创新思想，然后才是通过软件设计类课程中所设计的软件来解决实际的问题。因此，教师在课堂中要不断引导学生在生活中发现问题的习惯。通过TRIZ理论的问题解决策略对问题进行梳理整合，运用软件工程等方面的理论知识进行软件系统的设计，通过相应的语言来实现。这样不仅培养和锻炼了学生创新的思维，同时对学生创新能力的培养起到了推动作用。（2）问题的叠加与解决对学生创新思维的影响。学生学习兴趣与创新意识的引导源头在于“问题”。学贵有疑，小疑则小进，大疑则大进。TRIZ理论与项目设计思维对于学生的影响应该建立在自入学开始的学习与生活中，针对地方高校理工类学生的特点，相应思维方式与意识的引入更应贴进学生生活。例如，在入学第一学期的“计算机文化基础”课程教学过程中，通过与学生日常生活的交流，会发现学生常常抱怨课间时等待电梯时间过长这一情况。那么，教师就可以引导学生进入对这一问题的思考，即你知道电梯的工作原理是什么吗？以及对这一问题最简单的创新解决方法是什么？此时，就可以给出“操作系统的工作原理”以及“TRIZ方法论中的发明原理、冲突矩阵、物场分析等工具”。通过这些内容具体地引导学生了解他们的专业可以解决的问题，深化学生对于其专业知识的理解和应用。

2．软件设计类具体课程中项目的构思与设计过程

（1）项目设计对学生能力的促进。通过有针对性的引导与训练，学生发现问题的主动意识与创新的能力将会有很大程度的提高。此时，教师就可以在相应的软件设计类课程中给出某些不太复杂但针对性较强的项目。项目应符合复杂的现实环境，与实际生活紧密相关，只有这样才能真实反映出完整项目所包含的事件本身、其产生的原因、目前所存在的问题、挑战解决的途径以及资源限制等。学生通过项目必将真正了解工程师在实际设计中所面临的复杂境地以及艰难的抉择。这种项目式教学，既可以增强该课程的整体教学效果，可以运用TRIZ的相关理论进行训练和巩固。学生有针对性的对项目进行分析研究，经过对项目的分析、讨论、决策等环节，进而建立起系统的实践方案。在对项目的构思与设计过程中，学生学习了相关信息的搜集、整理，以及运用TRIZ方法对解决方案进行评估和最终决策的知识。这样的学习有助于训练和提高学生在复杂环境下运用TRIZ来解决实际工程问题的能力。（2）设计团队的组建对学生创新能力和学习效果的影响。现阶段的学生个性差异较大，类别明显，主要分为不同的两种类型：第一种学生思维活跃，易于接受新事务，但与计算机相关的理工类基础知识薄弱。第二种学生思维习惯传统，但相关基础知识掌握的较为系统。目前在地方高校中，第一种学生所占比例为多。教师通过实验教学过程很快就能够掌握学生的不同特性，在软件开发实践环节就可以将不同类型的学生进行整合。由于TRIZ理论来源于大量的专利，对各种场、参数和原则等概念能够真正理解的人才能更好运用TRIZ理论解决实际问题。因此，每个设计小组都由小部分“第二种”学生和大部分的“第一种”学生组成，根据任务的大小进行人数的分配。通过这一方式的应用，学生在系统设计的实践环节所完成大作业的创新性、可转化程度以及设计的质量较之以前按学号分组等情况都有了很大的提高。（3）合理划分项目工作以刺激学生参与意识。地方高校中学生自主学习意识较弱，对项目不能积极参与。针对这种情况，在对指定项目的实施过程中需要按设计小组中的每个人为单位对项目进行合理的划分与整合。例如，在教学楼里排课系统的设计中，小组成员为10人。首先，要选定设计小组长。小组长不一定在技术上全面或某项技术上突出，但应该具备良好沟通能力，并对本小组成员的特点非常了解，这样才能协助教师作好分工协作与管理。然后，通过组长的协助，将项目不同设计周期的任务进行划分。为自主学习意识不强的学生划分简单、技术性不强但非常重要的工作，如对教学楼中的教室面积、桌椅数量、是否是多媒体教室、所属院系等内容进行统计，或者将统计的数据录入数据库、建立数据表等基础且重要的工作。其他成员可根据其特长和能力对项目工作进行划分。通过项目合理的划分就可以使学生在学习的过程中，充分利用现有专业知识选择有效的方法和技术，以项目为对象有兴趣、有责任参与到项目开发和研究的全过程中。学生在参与项目的过程中，运用TRIZ理论的知识方法，从系统的角度处理好整体和局部，集体和个人的关系。（4）积极选取突出的项目设计案例进行成果转化。培养学生发现问题和创新思维意识以及对软件项目设计的能力，其主要动力来源应该是积极促使团队设计成果的转化。可以联系相关部门试用产品，对软件进行市场跟踪。相应的学生对软件工程中软件的整个生命周期会有更深入的了解。

3．注重课程实践对学生创新思维和开发能力的培养

（1）整合课程内容为加大实践课时占比做铺垫。对计算机专业课程，尤其是软件设计类课程的课程内容进行的大胆整合，将整合后让出的理论课时替换为课程实践。例如，原有的C语言、C++和Java分三学期连续讲授。讲的多练的少，学生的思考仅为片段式思考，对三个软件之间的连续性没有深刻认识，对学生创新意识、创新思维和创新开发能力的培养效果并不突出。为此，我们尝试了课程内容的整合，将三学期的教学内容压缩为两个学期。在学生基本掌握了程序设计的思维方式与相应软件的设计方法后，就给出课程设计的任务。只在实践教学引导中给出软件的特色、核心以及需要注意的内容即可，这样不仅加强了课程实践，为学生到企业实训倒出时间，更重要的是能够引发学生自主思考，突出了学生创新能力的培养。（2）教师在课程设计中注重培养自身与学生的创新思维和能力。青年学生思维活跃，作为软件设计专业任课教师一定突破年龄，保持积极活跃的思维才能够在教学的各个环节，尤其是课程设计的环节中有效地发现和引导学生的创新思维和能力。在更高一层次上，教师可以结合教学经验，通过对TRIZ相关内容的不断学习实践，进而合理有效地在实践课中穿插使用TRIZ理论中ARIZ算法等教学工具，引导部分学生在实践过程中对理论内容进行总结与验证，对教材中的现有内容及项目案例进行改进与创新。

三、结语

第7篇

1.1高校开设课程情况

以南京为例，南京理工科院校中开设了土木工程专业路桥方向的高校较多，这些院校中大部分都购买了相应的土木工程方面的软件，如PKPM结构设计软件，鲁班造价类软件，广联达造价类软件，为了满足学士学位授予权评审要求，因此也建立了相应的专业机房，但是专门开设的有软件应用系列课程的并不多，专业机房的利用率也并不是很高，主要是用于课程设计和毕业设计/毕业论文阶段的集中实践环节教学。民办院校和高职高专、大专院校中对于软件技术应用的课程，开设的相对较多。这样有利于学生在校阶段就能充分接受和社会上需求一致的软件操作训练，从而为日后走上工作岗位做好铺垫。

1.2可开设专业软件技术应用的课程

土木工程路桥方向可开设软件技术应用的课程很多，根据市场需求情况，主要有以下几类。

1.2.1道路桥梁方向设计类课程

路桥类可开设软件应用的课程主要有:道路勘测设计，桥梁工程，路基路面工程，专业软件具体又分道路和桥梁计算机辅助设计软件系统两种类型。目前国际主流道路辅助设计软件主要有:CARD/1，Bently，Civil3D。国内常见的道路辅助设计软件主要有:纬地三维道路设计系统，路线大师，EICAD，海地，天正市政道路，鸿业市政道路及路面结构HTDS2003。国内常见的桥梁辅助设计软件主要有:桥梁博士，桥梁大师，桥梁通等等。

1.2.2道路桥梁施工组织及造价类课程

工程施工组织及工程造价类可开设软件应用的课程主要有:土木工程施工，建设工程造价，工程造价管理，工程合同管理，工程招投标等课程。专业软件主要有:同望公路造价软件、海德纵横公路工程造价软件、广联达系列软件、上海鲁班系列软件、清华斯维尔系列软件、神机妙算软件、南京未来清单软件等等。

1.3存在的问题及原因分析

社会上存在的工程类软件如此之多，各个地区及企业的实际情况不同，对软件的购买也不一样。各大高校对于软件的购买以及开设相关课程，也是针对学生就业市场需求，以及学校年度设备采购计划而定。对于高校中，要熟练地掌握这些软件需要学生在课后花费较多的时间去练习，而这往往是很多学生不愿做的，只要教师不作硬性规定或要求，主动学习和应用这些软件的学生凤毛麟角。因此，直到大学毕业，真正能够掌握或部分掌握这些软件的学生极少［3］。鉴于以上的情况，高校路桥方向开设软件信息技术类课程，主要还存在着以下几方面问题。

1.3.1现有软件开发合作不理想

现有软件开发缺乏统一部门的管理，从而导致很多软件功能基本相同，只是适用地区不一样。同时，很多软件公司里面的员工大多数是计算机等专业出身，对工程实际并不很熟悉，从而设计开发出来的软件，在处理真正的工程实际时，会产生一些偏差。

1.3.2教学资源及人才的缺乏

各大高校中的教师，绝大部分是本科—硕士—博士毕业而来，教学经验虽然非常丰富，实际工程经验相对较差，因此教学缺乏与工程实际接轨。

1.3.3学生的主动学习意识还不强

学生在校阶段的学习时间非常有限，对于软件应用类的课程，必须要求学习者经常上机操作，熟能生巧，应用软件来解决实际工程图纸中的问题，这样，软件应用能力才能不断得到提高。

1.3.4地区行业标准相对独立

由于不同的地区有不同的建筑行业标准，这就使得教师在训练学生软件操作时，必须选择采用某一个省份的地区定额作为教学需求，很多教师都是选择学校所在地的省份的定额，但学生来自全国各地，因此，当学生毕业后如果回到家乡，对于工程软件部分就必须按照工程所在地的操作来进行。

2提高专业软件化程度的措施

2.1高校方面

1)高校工程管理专业编制教学计划的时候，就应该充分考虑，在满足学生修满学分，不额外增加学生学习压力的前提下，开设专门的软件应用课程，而不是仅仅在课程设计或毕业设计的时候集中培训。2)对于软件的选择，高校在购买软件的时候，要充分考虑市场对软件的评价或用户的多少，而不能单纯考虑价格，尽量购买专业方向的主流软件。我校在充分调研论证的基础上，先后购买了有关专业软件。如天正建筑CAD、鲁班系列软件、PKPM系列软件，EICAD，桥梁博士。为我院土木工程专业路桥方向学生全面提高计算机专业软件应用能力和水平，实现理论与应用有机结合，路桥方向应用型实践教学体系改革奠定了基础。3)机房的管理。专业教研室应建立自己的专业机房，同时配备专业的维护人员。4)教师培训。学校应鼓励教师参加各种软件培训，然后服务于教学。5)积极参加各种软件开发商举办的高等院校软件竞赛。目的不是在于获得奖励，主要是能和其他兄弟院校的学生同台竞争，从而找出自己的差距。6)校企共建“双师”结构的实践教学团队。通过引进、培养补充紧缺专业人才，加强专业带头人培养和骨干教师队伍建设，强化“双师结构”教师队伍建设。7)加强实习基地建设，提高生产实习、毕业实习和毕业设计水平。

2.2学生方面

1)鼓励学生认真学习路桥方向各种软件，而不是仅仅为了应付考试，因此，对于软件课程的考核，不应采取课堂考试的形式，可采取机房上机考试，或者布置大作业的形式，让学生充分思考后独立完成，才能达到应有的教学效果。目前，计算机辅助设计已广泛应用于土木工程领域，在毕业设计中加入计算机辅助设计的内容，是提高毕业设计质量与学生计算机应用能力的重要途径［4］。我院根据教改项目的构思，在毕业设计中加入了专业软件应用。目前已经在2013，2014届毕业设计中实施，同时计划在往后的毕业设计中进一步加大专业软件的应用。通过毕业设计环节的锻炼，学生专业软件应用能力得到很大提高。2)学工部组织成立软件应用兴趣小组或社团，让学生充分了解软件信息后，才会更认真的学习。3)鼓励学生报名参加各种软件竞赛，走出校园，了解其他兄弟院校的同学情况。同时，对于获奖的学生，应给予表彰。

3结语

第8篇

1）时间：扩大了教学内容，该如何调整有限的课时？增加课程的实践内容意味着应当增加一定的课时，因此必须考虑如何在教务部门限定的课时内，腾出一定时间进行实践。首先我们在继续积极申请扩大课程学时的同时，尽量精简基础教材的理论讲授内容，对落后于时代的内容不做过多扩展，把主要精力放在具有指导实践意义的内容上，并注意理论与实践内容的融合衔接。其次，我们调整教学形式，要求学生不仅在课堂进行主要知识的学习，还要通过作业的形式，在课下补充学习。学生在项目组活动中补充实践所需要的知识，达到课上与课下学习实践的有机结合。大部分实践时间以虚拟项目小组开发活动的形式落实到了课下解决，精简出来的时间用于检查各个虚拟项目小组的阶段成果。各小组制作PPT并自选一名成员进行答辩。

2）组织：如何引导和组织学生建立项目小组以更好地实现教学目标？由于项目组的建立必须在开课之初，这时学生还未接触软件工程的体系内容，因此需要教师妥善引导建立。建议的步骤是：①提前根据授课班级人数确定好合适的小组规模，将小组数量限制在可控范围内。②在第一节课上，布置学生按照规定的小组规模自行分组，每人选好自己在小组中的角色，如项目经理、程序员、需求分析人员等，这涉及个人在小组活动中可能要完成的任务。③分好小组及各自角色后，“项目经理”以电子邮件(各小组的联络信箱)的形式将小组成员及对应角色的名单提交给教师，同时需要提交的还有各虚拟项目小组确定的虚拟开发项目。针对少数学生在项目小组的组合及活动上可能存在偷懒行为，我们建议在布置分组时，提前分组规则。例如，项目小组原则上是班级学生自由组合；布置的实践作业及小组活动阶段答辩要算成绩，成绩的计算方式是以小组为单位，小组成员成绩均等；平时成绩在考试中的占比较大。当意识到项目组成员构成以及成员合作的重要性后，学生会更慎重地选择分组，而且当组内成员偷懒时，为了不影响小组成绩，其他成员也会督促。另外，经验表明，很多小组的成员会在角色上各尽所能，善于言辞的去答辩，善于设计归纳的做PPT，还有的进行资料收集工作。当然，也不排除有的小组有能者多劳现象，但这是学生自己的选择。

3）内容：在有限时间内项目小组围绕自己的虚拟项目该做些什么？要明确在现有条件下需要学生重点体验项目开发实践活动中的哪些内容。我们认为除代码开发外，让学生感受经典软件工程项目开发的主要阶段和其中的一些重要角色，是该课程的重点。因此，项目小组以工程文档编制为主要内容，根据各自指定的虚拟开发项目，定期提交阶段项目文档并针对文档答辩。这在一定程度上加深了学生对最容易忽视的开发文档的认识和理解。当然，教师也要定期发放给学生一些软件工程的标准文档作为参照。

2教学设计

2.1课堂部分目前学院软件工程课程设置48个理论授课学时，每学期16个教学周，每次课包含两小节，即2学时。课程安排为单双周课时方式，即逢单周为一次课，正常进行软件工程基础理论授课；逢双周为两次课，小部分时间进行软件工程基础理论授课，大部分时间进行虚拟项目小组汇报答辩活动。课程选用国外教材[6]，教材内容贴近于实践，甚至可以在实践中当作工作指南来使用，非常适于配合笔者提出的教学模式。

2.2实践部分学生按照教师定期布置的实践内容，在课下围绕所在小组的虚拟开发项目自主完成。教师可以通过汇报答辩环节进行评估检查，同时在期末试题中也可以体现相关内容。在教学实践中，为了规范及督促项目小组的活动，对小组组成及任务给出如下规则：①全班分成若干个项目组，每个项目组5~6个人；②每人都要参与项目组，否则无平时成绩；③各项目组自主制订合适的模拟开发项目(充分发挥想象力)；④项目组的活动围绕软件工程文档进行；⑤项目组安排各阶段任务；⑥项目组内要分工明确；⑦阶段报告及答辩活动需要做PPT配合。

2.3任务布置依据正规、全面的经典软件工程开发模型，要求每个项目小组完成项目开发阶段文档，包括编写项目计划书、可行性分析报告、需求分析报告、项目进度计划、体系结构及总体设计、SQA计划、详细设计、测试计划及测试报告、SQA评审等各种项目文档。在每次阶段汇报活动中，各小组要将所有文档提交给教师。

3考核方式

3.1分值配比及要求按照学校的规定，科目总成绩由平时成绩与期末考试成绩两部分组成。由于软件工程课程实践部分占有较大权重，故设定平时成绩占30%，均以小组为单位，包括出勤、答辩表现及项目文档（代码）；期末成绩占总成绩的70%，以个人为单位，偏重于课程的理论内容。具体要求是：①每人只允许累计缺勤2次，否则没有成绩；②个人缺勤将影响小组成绩；③答辩表现部分按小组整体给分，答辩人由小组自主确定；④作业以小组形式给出，故按小组给分；⑤最终成绩与所在项目组的表现有较大关联。

3.2计分细则（1）出勤。每人每缺勤一次所属小组扣3分，迟到扣1分，从平时成绩里扣除。（2）文档。2分×7次+1分×1次=15分(组内按角色自行安排撰写人)。（3）答辩。2分×7次+1分×1次=15分(组内按角色自行安排答辩人)。（4）与考试关联10分(根据答题情况浮动)。最后一项与答辩情况关联，即隐性的平时成绩，形式是主观论述题，与每个角色的答辩内容有关，评分标准是答辩与答题情况的综合。在实际制订的试题中，除了上述主观题，还有一道题与学生在所属小组里承担的角色有关，涉及角色职能描述，需要学生谈看法和感受，并阐述某项目模拟角色的工作等。

4实施效果及总结

第9篇

WBSR模式是建立在WBS基础之上的，与责任融合后形成的一种新模式。从WBSR角度开展工作，能够确定软件项目的工作及产品范围，为工作顺利开展指明了方向，将工作细化之后，分配给每一个工作人员，促使工作人员明确自身职责，从而为项目计划制定、考核等工作奠定坚实的基础和保障。

2模型具体步骤划分

通过对模型进行深入分析和研究，并结合软件项目特征，能够确定责任范围，对整个项目进行结构分解，得到WBS集；软件项目的开发需要将用户需求作为核心，进而通过模型进行分解，获得PBS集；最后，要制定与项目开发相关的部署，确保每一个环节都能够顺利进行，保证项目进度，为工作提供依据，通过这种方式，不仅能够确保工作有条不紊进行，还能够有效提高工作质量和效率，从而促进软件开发工作进一步发展。

3模型主要应用流程

WBSR模型在软件项目管理中的应用主要涉及对项目的分解、工作目标的确认及更新。首先，建立工作小组，工作人员作为软件项目管理的核心，其成员综合素质直接影响工作能否顺利进行，基于此，小组成员一般选择项目经济、技术人员等，还可以增加用户代表等，以此来确保软件开发的合理、科学性；其次，工作、产品等结构分解，工作分解作为模式应用的基础，应结合实际情况进行合理分解，切勿盲目性，还需要结合成员经验等因素，为工作顺利开展提供支持；软件产品作为参与市场竞争的关键，分解产品开发，能够深度挖掘员工潜力，提高产品适应力，与客户达成共识；最后，还需要结合实际情况对项目范围进行及时调整，如果范围发生变化，相对应的工作流程也需要进行调整，实现统一、系统发展目标。

4模型应用情况

将软件项目管理与WBSR模式结合，将各个工作进行细致划分，能够为软件计划、预估等工作提供依据，确保工作顺利开展，在一定程度上推动了软件项目进一步发展，与此同时，在项目开展过程中，负责人加大对实际工作的监督和控制力度，能够及时发现不足之处，并采取有针对性措施，确保软件产品开发质量，该模式的应用，能够直观的反映组内成员的实际表现，为日后进行绩效考核奠定了基础，从而有效提高管理水平，促进企业可持续、健康发展。

5模式性能评价

通过对WBSR模式在软件项目管理中应用情况调查可知，模式对工作过程及产品开发从不同角度进行合理分解，提高了项目范围的精准性及有效性，避免工作失误情况的发生，并且将工作细化至每一个人受众，形成良性循环，促使员工能够认真、负责完成工作，起到了积极地促进作用。因此，面对社会发展新形势下，企业软件项目管理可以大力推广和普及WBSR模式，提高产品适应力及质量，从而实现企业经济效益最大化目标。

6结论

第10篇

信息项目管理中的九大知识体系中的核心内容与价值工程中功能、成本、价值等概念有很大的相关性。软件开发中的软件复用和模块化概念也是价值工程在软件项目管理中的体现。软件需求分析是将用户需求转化为软件开发理解，以形式化的方式描述用户需求，进行规格说明，需求分析为功能的确认和开发提供检验依据和标准。软件项目强调软件功能中高内聚、低耦合，即是从软件开发出发，降低成本和开发周期，实现产品维护和升级，体现价值工程理论的现实意义。相应地，针对价值工程中的相关概念和软件项目管理中的诸多内容，挖掘其内涵，对产品或项目功能的定义和价值体现具有重要意义。

1.1软件项目功能的识别和度量依据软件项目的开发特点，软件项目功能模块包括基本功能和扩展功能，根据需要还会有衍生的附加功能。它在产品中的作用和价值有很大差异。对整体的投入/产出有很大的影响。如何定义这些功能，并进行合理的功能划分，包括其必要性和可能性、以及交付的时间节点，需要充分考虑用户需求、开发成本、时间因素、质量要求，将这些基本需要和用户真实需求进行匹配和对接，体现价值工程思想在软件项目中的应用和契合。

1.2软件项目成本的识别和度量软件项目成本是指为获取软件功能而付出的成本，主要体现为人力、物力、财力和时间的投入。相应的成本和出，最终都可以从价值论的角度用统一的度量标准、度量方法和度量单位进行分析和度量。在项目生命周期中，启动、规划设计、结束阶段相应的成本较低，实施阶段的成本最高，应该进行有效的评估和设计。通过挣值管理（EVM），了解项目成本、进度的偏差，及时进行纠偏或变更管理。

1.3软件项目价值的识别和度量在价值工程中，价值、功能和成本三者之间的关系应该是：价值=功能（或效用）/成本（或生产费用），用公式可表示为：V=F/C。V代表Value，即为价值；F代表Function，即为功能，C代表Cost，即为费用。从项目管理的角度出发，影响产品的价值不仅是功能和费用，还需要考虑相应的时间成本以及质量要求所带来的成本，综合以上因素，有学者提出其价值可用公式表示为：V=(F+Q)/(C+T)。上式中增加了质量（Q代表Quality）因素和时间（T代表Time）因素在价值中的作用。在实际的操作中，其具体的核算指标依据项目特点会有很大差异。影响价值的因素，除了以上各项，还包括用户体验、供需关系和认可度等诸多方面。

2结论

第11篇

论文关键词：软件项目管理软件产品质量因素

论文摘要：软件项目管理的核心是全面客户满意。其管理体系包括:战略管理、范围管理、成本管理、时间管理、人力资源管理、沟通管理、风险管理和质量管理。

在软件和信息科技行业，项目管理经常决定了一个产品或者企业能否成功。项目管理得到越来越多的企业和政府部门的重视，例如中国于2002年4月召开了有关项目管理的首次国际研讨会。具体操作与项目最根本的不同在于具体操作是具有连续性和重复性的，而项目则是有时限性和唯一性的。项目是一项为了创造某一唯一的产品或服务的时限性工作。所谓时限性是指每一个项目都具有明确的开端和明确的结束;所谓唯一是指该项产品或服务与同类产品或服务相比在某些方面具有显著的不同。各种层次的组织都可以承担项目工作。项目有时只涉及一个组织的某一部分，有时则可能需要跨越好几个组织。项目是执行组织商业战略的关键。

一、软件产品项目管理的重要性

20世纪80--90年代，许多大型企业管理信息系统MIS的开发都以失败而告终。这是为什么?一个重要原因是软件项目管理水平上不去，尤其是需求分析管理水平上不去，使得项目快要验收或交付时，却出了大问题:要么发现用户需求获取不准确，要么发现用户需求变了，致使做好的系统不能用或不好用。20世纪90年代初，上海一家公司在青岛做一个港口MIS项目，北京有一个单位在天津做一个港口MIS项目，都是因为甲乙双方软件工程基本知识不具备，使得项目管理不到位，导致2个大型项目不成功。现在软件应用领域空前广阔，深人到社会和科学研究等领域的各个方面。软件的需求也比以往更加多，软件系统设计也空前复杂。软件的项目管理问题也就因此而产生了。90年代中期，软件项目管理不善的问题仍然严重。据美国软件工程状况调查，只有10%的项目能够在预定的费用和进度下交付。于是软件项目管理成为软件项目发展中最重要的核心问题。为了使软件项目开发获得成功，必须对软件开发项目的工作范围、可能遇到的风险、需要的资源(人、硬件、软件)、要实现的任务、经历的里程碑、花费的工作量(成本)，以及进度安排等做到心中有数。软件项目管理的目的就是提供这些信息，分析信息，并根据分析结果对项目做出调整。软件项目管理开始于技术工作之前，在软件开发的整个过程中持续进行，最后中止于软件过程结束。

二、软件项目管理体系

随着软、硬件技术以及通信技术的日益成熟，软件技术可以与所有的传统产业相结合，促进产品的更新换代，大幅度提高产品的附加值，提高劳动生产率，推动产业结构与产品结构的调整。因此，软件的开发以及应用不仅仅是软件开发机构的任务，更深地涉及软件使用者的切身利益，尤其像管理信息系统MIS(ManagcmentInformationSystem)、计算机集成制造系统CIMS(ComputerIntegrationManufacturingSystem)、企业资源计划ERP(EnterpriseResourcePlanning)及商业智能BI(BusinessIntelligence)等大型的复杂软件更是综合了管理科学、计算机科学、通信技术以及数学等各方面的知识，需要各类人员的协调工作才能完成。因此也就有必要从项目管理的角度去管理软件的开发和运行。从用户的角度来看，软件项目的生命周期应该包括项目前期的论证工作、项目计划、软件开发、运行、维护以及项目后评价。由此可见软件项目管理的范围不仅包括传统的软件开发过程，还应该包括开发之前的准备工作以及运行中的维护工作和对项目的总结工作。同时，在软件项目生命周期中存在着许多活动。根据活动之间的相关性，可以将软件项目的各种活动分为九大类。

(1)战略管理。根据用户的经营目标制定软件项目的策略，以便为其他各方面的活动提供指导。在制定项目策略的时候应该充分考虑用户和其他利益相关者的实际需求和市场因素。另外创造和谐的项目环境和连续改进也是战略管理的重要任务

(2)范围管理。其目的是控制软件项目的全部活动过程都在需求范围内，以确保项目各种资源的高效利用。成功的项目管理离不开用户、软件开发队伍和项目经理的一致理解和协调配合

(3)成本管理。软件项目的成本不仅包括开发成本，也包括开发之前立项阶段以及软件在运行中的费用。操作者的培训费用和项所使用的各种硬件设施费用也都是整个项目成本的一部分。这些成本都需要很好地计划和控制。

(4)时间管理。其内容有确定各项活动之间的时间相关性;估计各项活动的持续时间，跟踪各项活动的进展情况，动态调筷各项活动之间在时间上的协调。

(5)人力资源管理。在软件项目中应该为软件开发人员和管理人员等各类项目人员创造一个和谐良好的工作氛围。使他们能感到项目成功的把握和积极的工作心态，确保项目队伍的稳定性和连续性。

(6)沟通管理。沟通管理是一个收集、存储、配置和项目生命周期内所形成的各种信息的过程为了让每个项目相关人员及时得到所需的信息，需要很好地解决“什么时候、向什么人礼报什么的”的问题，此外软件开发队伍和用户之间的沟通也是沟通管理中的一项重要工作。

(7)风险管理。由于软件项目中存在着很多的不确定因索，也就必然存在着各种风险而且风险有可能造成不良的结果，对风险进行分析和监控贯穿于整个软件项目生命周期。

(8)质量管理。目前软件的质量还是一个模糊的概念并且难以衡量由于软件质量主要是在开发阶段形成的，因此软件项目质量管理的重点应放在系统分析、系统设计和编码阶段，走查、评审、调试和测试是保证软件质量的重要手段软件工程能力成熟度模型CMM(CapabilityMaturityModel)较好地解决了软件开发过程中的质量管理问题。

综合管理。综合管理的任务是对前面讨论的各类管理活动进行协调和控制，使这些活动相互配合。其核心任务是对各种方案进行评价，协调各方面的利益冲突确保项目总体标的最终实现。

三、软件项目管理的核心是全面客户满意

当前，不少软件业管理人上认为，软件开发的问题主要在软件开发的工程化、规范化和软件开发管理体制。他们按照CMM(CapabilityMaturityModel),IS09002的标准来建立他们的管理体系。这里有商业竞争的因素在起作用。但是，他们忽略了商业竞争中取胜最重要的因素—客户满意。他们没有考虑到他们的管理方法能否满足客户不断变化的需求。从长远来看，软件项目真正的成功是客户的全面满意。以客户满意为中心的质量是必需的。漠视质量或只关心产品/服务是否符合需要的方法再也不足以留住和获得客户。因此，软件开发项目组织必须先确定什么产品/服务可以让顾客满意，然后再努力满足客户的需求和期望。要实现此目标，组织必须识别对软件产品的各种特性中哪些是对客户的满意起决定作用的要素。例如，服务器操作系统软件，需要长时间稳定连续工作。稳定性则是该软件产品的关键要素。因此系统的开发管理围绕着这一关键要素来展开。尽管不少的组织明白没有客户一个组织就不能生存和发展，或者说没有客户就没有组织，但在项目实施过程中，仍然存在着客户满意的障碍:

(1)项目管理组织没有发展和完善对客户不断变化的需求和期望作出快速响应的能力。

(2)项目管理组织没有听取客户意见和建议的能力。

(3)项目管理组织努力倾听客户对项目的要求，却没有确认客户的需要和期望。

第12篇

上述文献中存在着两个缺陷：一是虽然在软件开发项目经济分析时考虑了项目内含的实物期权价值，但在项目投资决策分析中却仍然遵循NPV方法的思路，而没有考虑实物期权的执行问题以及何时执行问题；二是缺乏对软件开发项目在生命周期的各个阶段所包含的实物期权作全面、系统的研究，大多只是考虑到项目中的等待期权。本文则对上述问题作了详尽的研究和分析。

二、软件项目的生命周期

从项目管理与项目经济分析的角度看，软件项目的生命周期可归纳为图1所示的一般过程：

在图1中，横坐标是时间，纵坐标是收益或投资成本，t0=0是项目的决策点。在决策时，I是项目可行性研究费用(成本)，相对于项目的整个寿命期，一般来说项目的可行性研究阶段的时间很短，所以假设项目的可行性研究是在瞬间完成。t1是项目开发的起始点，t2-t1是项目前期开发阶段，在这一阶段，项目有一现金流C1支出，C1可能是常量，也可能是随时间的变量C1(t)。从t2时刻起，项目的首期开发完成，项目开始有收益，即现金流B1，B1也可能是常量，更一般的是随时间的变量B1(t)，这一收入可能是企业出售软件或软件相关服务效益的收入。同时，对于大多数成功的软件项目来说，从t2时刻起，该软件项目又开始了进一步的开发，如增加软件的新功能，或将软件移植扩展到其他的计算机操作系统等。从t3-t2阶段是软件项目的第二次开发阶段，在这一过程中所发生的开发费用为C2，C2的特点也与C1相似。从t3到tn，其中可能包括多个与t3-t2阶段相似的软件项目的扩展(二次开发)阶段。T是该软件项目结束的时间。由于技术进步与消费者需求的变化，一般来说一个软件不可能永远继续下去，它可能在某一时刻被完全淘汰。综上分析，t0是项目的决策点，t1是项目的开发起始点，他们可能是同一时间，但大多数情况下可能是不同点。t1-tn是项目的开发阶段，其中t1-t2是项目的纯开发阶段，在这一阶段上，项目无收益。t2-T是项目的收益阶段，在这个时段上项目有现金流入，他们通常大于本阶段上的开发费用。值得指出的是，软件项目在t2-T阶段，企业可以中止并出售该项目，并一次性收取转让费。

三、软件开发项目内含实物期权分析

从图1的分析可以看出，一个软件开发项目包含了多个阶段。把软件项目看作是由一系列序贯开发的小项目所组成，这一观点在软件开发项目管理中已被广泛接受。在软件项目中，前一阶段的决策，决定了后续阶段的开发投资。所以，在前一阶段的经济评价中，应考虑本阶段的决策所带来的后续阶段投资机会的价值。从这一观点出发，可以分析在软件开发项目的不同阶段中项目可能包含的实物期权。

在t0点，即项目投资决策时，项目内含一个等待(wait)或推迟(defer)开始的实物期权，这相当于一个美国式的买方期权(CallOption)。该期权的执行条件是：推迟项目可以使得管理人员获得更多(额外)的有关项目的信息，在此基础上，有利于管理人员采取管理行动，而且，一般来说计算机硬件，软件的价格随时间迅速下降，推迟项目会有利于降低开发成本。但同时也应看到，推迟项目也可能导致项目收入的损失和企业竞争优势的丧失，即推迟项目具有机会成本。在项目决策时，应综合全面考虑这两方面因素。因而，在项目决策时，除了筛选项目外，还应考虑这一实物期权的价值，在时间许可的范围内，决定最佳项目开始时间。

在t0时，除等待期权外，项目还包含有第二阶段投资机会的实物期权。

在t1至tn时项目的开发阶段。在开发阶段上项目具有更大的管理柔性，项目可能包含的实物期权有：1.推迟或中止下一阶段的开发。2.若不期望的情况出现，并且继续下去，则可完全放弃该项目。3.根据新掌握的信息，扩展或缩减项目。4.发现新派生软件(项目)的投资机会。

最后，项目的经营阶段，项目还可能包括中止(出售)的期权，或由于条件的变化，进一步升级软件的机会。

虽然软件项目中所包含的期权不同，但一般情况下，影响他们价值的因素主要包括：1.执行项目中实物期权所产生的收益。对软件开发项目来说，这可能是项目在某一阶段的收益，一般来说，其他条件不变，收益越高，期权的价值也就越大。2.执行实物期权所需要的成本。对于软件开发项目而言，是投资于项目下一阶段的成本，一般来说，其他条件不变，成本越小，期权的价值也就越大。3.收益与成本的不确定性的程度。对于金融期权来说，其价值是建立在市场风险之上的，这个风险反映在证券资产的价格变化上。然而，其中之一变为不确定了，则项目所包含的实物期权价值会相应增加。4.实物期权的截止时间。对于软件项目来说，这一时间就是下一阶段项目管理决策的可能时间。在实践中，它经常是企业因素所决定的。实物期权的截止时间越长，则期权的价值也就越高。5.项目包含的实物期权执行的机会成本。若这一机会成本越高，则期权的价值也就越低。6.无风险折现率。无风险折现率越低，则期权的价值也就越高。

四、软件开发项目经济分析的目标与内容

Trigeorgis等学者提出，在考虑内含实物期权时，投资项目的价值包括两部分：一是传统的、被动的、静态的(static)项目直接现金流的净现值(NPV)。二是管理柔性或灵活性所产生的项目内含实物期权价值。这一思想可归纳为下式：F=NPV+V(1)

(1)式中，F是扩展(Expand)的NPV，也是整个项目投资机会的价值；NPV是按净现值法计算出的项目净现值；V是项目内含期权的价值。

根据项目投资决策的NPV法则，内含实物期权的IT项目，其投资机会的价值大于零时，项目可行；筛选IT项目的多个独立方案时，选择投资机会最大的投资方案。在大多数投资项目的实物期权理论研究以及实证研究的文献中，都遵循这一准则。然而，这类投资项目的决策思路却值得重新审视。

传统的投资项目经济评价中，没有考虑项目中可能包含的实物期权，其经济评价是为其投资决策服务的。而投资决策的特点是在决策时只有投资或不投资两种选择，若项目选择投资，其经济评价的使命便告结束。若选择不投资，项目就放弃了。传统的投资项目决策的内容可归纳为下面三个基本内容：1.决定投资项目是否经济可行；2.若可行的投资项目存在多个相互排斥的投资方案，筛选最佳的投资方案；3.在企业资源(预算)约束的条件下，筛选多个项目的投资组合。然而，若投资项目中包含实物期权，项目经济评价中也考虑了项目内含实物期权的价值，那么投资项目不仅在经济评价的内容与方式上与传统项目的经济评价不同，而且项目的决策内容和方式也与传统项目的决策不同，具体体现在下面三个方面：第一，项目的决策不仅在项目最初的决策阶段(点)进行，而且还应延伸进项目的整个过程之中。第二，在项目最初的决策阶段(点)，管理者不仅要决定项目是否可行，筛选最佳方案和选择投资组合，而且还要依据项目经济评价的结果，决定项目内含期权是否应该执行和何时执行。第三，投资项目内含期权的经济分析，不仅在项目决策阶段进行，而且还应延伸至项目开发的全过程。在项目开发的每一个阶段，根据项目经济分析的结果，决定当时项目所含实物期权是否实施、何时实施。

五、软件开发项目决策框架与准则

从上述分析可以看出，在软件开发项目经济评价中引入实物期权的概念和实物期权定价方法，是软件开发项目经济分析与决策管理的革命，它必然给原有的软件开发项目的管理带来深刻变革。本文构建了软件开发项目的经济分析与管理决策过程的框架，其主要内容是：1.确定本阶段软件开发的范围及下一阶段开发的可能范围，决定是否可引出相关的开发项目。2.构造确定本阶段开发项目包含的实物期权，如推迟开发、进一步扩展开发等。3.预估开发项目成本、收益、时间和无风险折现率，特别应分析确定成本与收益的不确定性特征，如变化方差等。4.根据开发项目的不确定源的特征，选择合理、恰当的市区期权定价模型，确定开发项目内含期权的价值。对于相似于美国式期权的实物期权，还应确定最佳执行时间。一般来说，实物期权定价模型主要包括：已有的期权定价模型、偏微分方程法和动态规划方法等。5.根据项目的经济分析结果作出管理决策。应该指出的是，在软件开发项目的不同阶段，管理决策的内容有所不同，下面详细分析不同开发阶段管理决策的内容与规则。

在软件开发项目的最初决策阶段，决策内容包括两个部分：一是传统项目投资决策内容相同；二是针对项目内含期权的决策。具体可归纳为图2所示：

第13篇

一、软件工程开发中常见的问题

软件工程是一门工程性的学科，其目标主要是成功地建造一个大型软件系统。包括：付出较低开发成本；达到要求的软件功能；取得较好的软件性能；软件易于移植；维护费用较低；能按时完成开发任务；软件可靠性高等。在软件工程开发中遇到的具体问题可以总结为如下几点：

（1）软件模块开发过于独立，各模块没有统一的开发标准，造成系统功能重复，开发平台不统一，系统整合难度大；

（2）系统开发往往针对某一特定功能，没有形成一个完整的系统结构；

（3）总体设计不够细致，各个子系统功能模块风格不统一；

（4）开发人员技术水平、开发能力和时间有限，开发手段相对原始，代码的可重用性低、可读性差；

（5）缺乏有效的软件文档管理。这些问题集中体现在软件项目开发的每一模块中，导致整个项目开发过程中，开发费用超出原定计划，生产的软件系统不能满足用户需求，系统难以简易维护，系统无法高效运行等问题。这里既有技术层面的因素，即开发平台不统一；也有软件开发的组织与管理层面的因素，即程序员对系统功能的定义、规划和设计不明确，往往是开发人员摸着石头过河，仅仅从自己开发的这部分模块来考虑问题，另外开发人员和测试人员不能很好的协调，这些都说明了软件项目管理这一角色的欠缺。

二、项目管理针对软件工程开发的优势

项目管理包括时间、质量、成本三大要素，三者相辅相成，相互制约。时间可等价于软件项目开发中的开发生命周期，即在最终达到开发目标前的各个阶段的总用时。质量可等价于最终开发软件系统的功能性，可用性与达到的客户满意度。成本相当于软件项目开发中的费用，包括人力、地点、工具、系统故障处理等方面的开销。统筹时间、质量、成本三要素，即统筹软件项目开发周期、软件使用客户满意度和开发费用之间的平衡关系，不因忽略某一项指标而导致项目开发目的实现不了或中途中断，也不会为了实现较高的效率，而忽略成本的牺牲，让所有项目开发过程中，所涉及到的因素都可有条不紊地进行。

SPPT是项目管理另一层面上概括的四要素，分别为：战略（Strategy）、人（People）、次序和安排（Process）、工具（Tool）。战略对于软件项目来说，主要概括为模块开发的开发方式，配合方法等；人，毫无疑问，指的是项目开发中的参与者；次序则是项目如何划分模块，以及模块开发的先后次序；工具，即使用工具，包括：辅导设计程序系统、文档编写系统、资源管理系统等。对这四要素的稳定地统筹把握，能更好的协调好项目开发过程中涉及的多个方面，而又不造成某一方面的缺失，导致项目最终目的实现不了或效果不明显。

三、项目管理思想与软件工程开发的结合

根据上述项目管理要素与软件工程开发要素的结合，平衡项目开发过程中的开发要素，能更加简洁高效地完成项目开发目标。IT软件企业处于项目为主导的环境中，每天所面对的将是成百上千不断发生、进行的项目。在这种多项目并发、高技术、快速变化、资源有限的环境下，为了试图满足不断变化的市场需求及应对各种挑战，必须考虑改进项目管理。

以项目为中心有效地将所有资源结合在一起的工作方式将是软件企业，特别是项目经理或企业主管必须面对的、认真思考的课题。一个成熟的软件项目，必须具有一位项目经理做到：了解软件开发项目完整流程；掌握如何制定完整精炼的软件项目计划书；掌握项目管理体系中的各个要素；学会进行项目的跟踪和总结等。除此之外，一个软件项目能否最终达到成功，最关键的是进度控制。对于进度控制而言，计划尤为重要，它影响到资源是否被合理使用，项目能否顺利进行，直接关系到项目的成败。有两个重要方法可以应用到该控制中，一个是里程碑设置，以周为一个小里程碑，以月为中里程碑，以项目初验为一个大里程碑，允许在一定范围内存在进度偏移度。另一个是项目定期汇报。提交工作项目周报，包括项目名称、项目负责人、项目开始时间、项目计划初验时间、項目计划偏移度等。最后，制定周例会制度、建立配置管理和监督体系，也尤为重要。

第14篇

1.1敏捷方法介绍

敏捷方法诞生于2001年初，当时，由于看到开发团队陷入越来越沉重的软件过程当中。业界专家们总结出了一套使团队具有快速工作、响应变化能力的价值观和原则。基于这一套价值观和原则的软件开发方法，被称为敏捷软件开发方法（AgileSoftwareDevelop-ment），而这类方法也发展出相应的敏捷项目管理体系（AgileProjectManagement）。敏捷开发方法及项目管理体系统称为敏捷方法（Agile）。

1.2敏捷方法的优点

敏捷方法是一种以人为核心、迭代、循序渐进的开发及项目管理方法。该方法使用了迭代、增量等方法来优化可预见性并控制风险。它灵活、高效、可持续，可以帮助软件开发团队有效地应对复杂的适应性问题。

该方法受到拥护和流行是因为采用了该方法后，团队得到的收益：据统计，敏捷方法可以让团队的效率提升3～10倍；软件的质量也更有保障；团队成员有良好的发展机会；技术能力和团队协作也得到了提高。

2敏捷项目的快速启动

2.1什么是快速启动？

敏捷软件开发项目通常会通过1～4周的快速启动（QuickStart）工作，制定出迭代开发计划，然后在开发过程中逐渐完善需求。QuickStart是一种高效的项目启动方式，主要用以在项目开始之前识别关键的驱动因素，这种方式能够让关键干系人认可并理解即将交付的产品。如图1所示。

3QuickStart的前期准备

3.1邀请相关参与人员

QuickStart过程中需要邀请参与的人员包括：核心团队、领域专家及用户代表、关键干系人（受益人、高层领导等）。核心团队一般包括产品负责人、需求分析人员、项目负责人及核心团队成员。这些人需要全程参与整个QuickStart，他们是成果的主要贡献者。领域专家及用户代表主要在用户建模、场景建模等环节为团队提供专业的意见和建议。他们可以在某些阶段时参与到QuickStart中来。关键干系人主要参与QuickStart的启动和展示汇报的环节，并对产出成果进行确认，特别是需要对产品目标和计划进行确认和授权。

3.2拟定QuickStart的计划

在QuickStart正式开始之前，项目负责人和产品负责人需要拟定QuickStart的整体计划。以一个2周的QuickStart为例，整个QuickStart计划可以这样安排：

QuickStart启动及业务目标识别（0.5～1天）

参与人员包括：核心团队、领域专家及用户代表、项目领导

产出物：产品目标

识别主要角色及场景（3～5天）

参与人员包括：核心团队、领域专家及用户代表、项目领导

产出物：主要用户角色列表、核心场景及流程、页面设计及原型

需求列表梳理（1～2天）

参与人员包括：核心团队、领域专家及用户代表

产出物：用户故事清单

规模及成本估算（0.5～1天）

参与人员包括：核心团队

产出物：估算结果

迭代/计划制定（0.5～1天）

参与人员包括：核心团队

产出物：迭代/计划

QuickStart的成果汇报（0.5天）

参与人员包括：全体团队成员

产出物：成果汇报材料

4引入的各种流程建模及分析技术

4.1识别业务目标及愿景

业务目标的识别和确定需要符合SMART原则；需要了解问题的背景及上下文信息；需要定义验证问题成功的标准；需要界定问题的范围，例如规模指的是数量还是金额，或者单品规模；需要明确并逐步完善关键干系人信息；需要明确关键资源，例如领域专家或者关键信息等等；还需要明确该问题的各种约束条件。

4.2识别角色及主要场景

用户识别从头脑风暴的形式开始，尽可能识别出更多的用户，然后挑选出主要的用户和角色，并且为用户进行用户画像，并建立用户模型。通过理解用户的目标需求和痛点，梳理出更多的细分用户场景，之后对用户场景进行优先级排序、分析，以发现其中的问题或隐含的机会。

对问题和机会进行结构化的分析可以通过这几个方面来进行：

（1）进行问题/机会的原始描述；

（2）通过事例来说明问题/机会的现象；

（3）对问题/机会进行定量的分析；

（4）对问题/机会进行定义并明确对于问题解决的期望；

（5）将问题和机会的相关分析及描述标识在用户场景描述的周围。

业务流程梳理的过程中可以将之前识别出来的用户场景在进行串联。较高层级的业务流程将各个场景串联起来之后，就可以在场景中进行场景流程的细化和展开，分析出流程步骤和各个步骤的细节。业务流程场景中的步骤细节需要包含这些信息：场景名称、场景入口的背景说明，本场景中需要跟进解决的问题，场景中事件步骤，某个步骤的细节说明，还需要有场景的出口目标。

4.3產出Productbacklog

根据上一环节中梳理出来的用户模型、场景模型、业务流程以及场景细节，开始进行用户故事的梳理，并建立用户故事列表。用户故事是为了方便与用户沟通而记录的信息，它不是需求文档，它需要以用户能理解的方式来进行描述。它的目的是要将用户的关注点从“写”转移到“交流”上，让开发团队做用户真正需要的东西，而不是用户写的东西。

一个用户故事的描述样例是：“作为一个<角色>，我想要<活动>，以便于<商业价值>”。一个用户故事是否成功可以从以下几点（INVEST）来判断：是不是独立的（Independent），是不是可协商的（Negotiable），是不是有价值的（Valuable），是不是可以估算的（Estimable），是不是大小合适、粒度相似的（Sizedappropriately），是不是测试能够测试、业务能够验收的（Testable）。

4.4梳理依赖、估算及优先级排序

核心开发人员对已经梳理出来的用户故事进行初步的技术解决方案分析，确定用户故事的技术实现可行性和一些可能的实现方案。然后从逻辑层面和技术实现层面，对用户故事列表中的故事进行一次检视，对于一些无法避免的用户故事之间的相互依赖，需要在故事卡片上标识出来。对已经梳理出来的用户故事进行估算，估算内容包括故事规模估算、工作量估算等。

估算完成后可以根据用户故事的价值、重要程度、依赖等信息进行用户故事优先级排序。排序的原则是优先考虑那些最有价值的故事、最关键的故事、被其他关键故事依赖最多的故事。

4.5制定交付计划

经过以上各个环节，团队已经得到了了一份标识了优先级、依赖关系、工作量估算等信息的用户故事列表，此时可以开始来制定交付/计划了。根据已经排序的优先级选择并整理每个迭代/版本需要完成的用户故事，使用每个故事上之前已经完成的规模或工作量估算，加上功能联调和集成可能增加投入量的buffer值，整理并安排出整个交付计划。

对于最近的一个交付周期的安排是团队应该投入最多时间进去分析和做进一步估算的。确保第一个交付周期的所有用户故事清晰且被团队理解，并且该周期中的所有用户故事都已经有较明确的技术实现方案，可以在QuickStart结束之后马上进入开发实现。如图2所示。

4.6汇报QuickStart的成果

QuickStart的最后一个环节是召开QuickStart成果汇报的会议，该会议的邀请人员包括项目团队全体成员、项目领导、相关干系人。会议上向项目相关人员汇报QuickStart的成果产出，包括确定项目产品目标及愿景、需求列表及交付计划。在展示项目团队QuickStart成果的同时也获取相关领导及干系人对成果的认可和支持，统一项目团队人员的认识，为汇报结束后立刻投入到需求的開发实现奠定基石。

5结束语

第15篇

Keyword：software； engineering cost；engineering quantity；automatic calculation

进入信息时代，计算机及相关软件在建设工程项目管理领域的应用也越来越广泛。在项目成本管理领域，早已实现工程成本及造价计算过程中定额子目的自动套用、费用的自动计算及人、材、机的自动分析和汇总，但工程量的计算还未能完全实现自动化，各类具有自动算量能够功能的软件在实际应用中也存在各种问题。

1. 当前项目造价（成本）领域软件应用的水平及存在问题分析

1.1. 当前项目造价（成本）领域软件应用发展的水平

当前，在项目造价（成本）领域的应用软件，主要在于实现自动讨价及工料分析。由于工作关系，笔者对目前市面上常用的几款软件都曾试用，总体来讲，上述软件具有准确率高、换算方便、速度快等优点，实现了报表输出的兼容性。也有部分软件对实现自动算量功能做出了有益的尝试，并取得一定的成果。根据笔者的经验，这类软件均较好的解决了建模、自动算量、工程量的汇总及定额的套用等手工计算中费工费时的工作，有些更是具备了能直接调用电子图档的功能，省却了大量的建模时间，取得了较好的应用效果。

1.2.工程量自动计算的意义

传统的手工计算工程量，其基本过程无非是翻阅图纸、熟悉资料、列计算式、计算分项工程量、汇总工程量、套用单价。很显然，这极为费力费时，需要细心和极大的耐心，稍有不慎则容易出错，效率低下。

而工程量的自动计算基本过程如下：建模、校核、自动计算、自动套用定额子目或生成工程量清单项目。

工程量的软件计算最大的优越之处在于实现了工程量的自动化、智能化：

1）实现了构件交接处的自动扣减；

2）实现了工程量的自动分类汇总及报表输出；

3）建模时标准层可直接复制，非标准层可稍加修改，成倍的提高了工效。

相较于手工计算，用软件计算的功效是手工计算的至少4～5倍。笔者本人曾作过专门比较，同一栋框架结构宿舍楼，手工计算工程量到汇总得出分部分项工程量约需2～3天，而用软件计算从建模到输出工程量总共只用了不到10个小时，孰优孰劣，一目了然。

工程量的自动计算，不仅是项目建设初期及竣工阶段造价（成本）管理工作的需要，也是工程项目实施过程中管理工作的需要。项目管理中经常要做到对部分楼层、部分构件或部分材料的分项汇总，用手工计算容易出现统计错误，而软件则可以在几十秒钟之内实现上述功能。不仅如此，在招投标领域实现快速投标、在工程竣工决算审计中能起到减少重复计算、提高功效的作用。正由于此，笔者认为，应在项目造价（成本）领域大力推广工程量的自动计算。

1.3.当前算量类软件在项目造价（成本）领域应用中存在的问题

通过对上述部分具备算量功能的软件的使用，总体感觉目前的此类软件普遍存在如下缺点：

1）软件的智能化程度不高，需大量的人工干预，操作繁琐，容易出错；

2）对于建筑造型独特、不规则的建筑物建模有困难，如对墙面的一些非常规装饰不能方便的建模甚至无法建模；

3）计算公式的输出不规范，不符合人们的手工计算习惯，难以阅读，不便于核对和查错；

4）尽管部分软件声称具备能直接调用设计院的电子图档的功能，但实际应用中其效果并不理想；

5） 部分人士感觉其计算过程 “暗箱”化，对软件的计算结果不完全放心。

现实的情况就是，用传统的手工计算汇总工程量，然后手工录入套价软件。在其他的如工程技术设计领域早已解决的设计过程信息化，在项目造价（成本）领域还是未能实现。

转贴于

2. 当前项目造价（成本）领域信息化发展中存在问题的原因分析

笔者认为，当前在项目造价（成本）领域信息化水平低、造价（成本）管理中工程量的自动计算的自动化程度不高的原因是多方面的，概略分析，主要存在以下几个方面的原因：

2.1由于传统上对项目造价（成本）管理的忽视和方法的失误，导致相当长的一段时间内存在轻视“预决算”人员的倾向，造成长期以来工程造价类专业人士整体素质不高。尽管近年来国家推行“注册造价工程师”考试制度已在一定程度上扭转了这一现象，但现实中也的确存在部分民工或非“科班”出身的人士在从事工程造价管理工作——“预决算”，无疑他们的专业上的综合素养和接受新鲜事物的能力有限，部分甚至有排斥心理，导致造价类应用软件的推广受到极大的限制。

2.2由于算量类软件都需要建模——图形的输入，其操作较为繁琐。多数软件的建模依赖于设计绘图软件诸如PKPM、AutoCAD等图形平台软件的支持，而这一类软件对使用者的起点要求较高，限制了算量软件的广泛应用。

2.3有些声称能直接调用电子图档的软件，在实际应用中其效果不尽理想。由于绘图类软件种类繁多，标准不一，数据接口规范不尽统一，导致造价算量类软件在读入图纸时错误频出、修改量大，使得其宣称的功能大打折扣，影响了软件的推广。

2.4由于算量软件的使用受到诸多限制，加之一些业务部门平时工作任务繁重，认识有限，导致现实中对算量类软件的推广产生了极大的阻力，应用范围非常为有限。销售量的有限导致了其开发和推广成本的居高不下，使得此类软件的售价较高，又更限制了其使用范围的扩大，一定程度上形成了非良性循环。

3.对于推广算量类软件的几点思考

显然，当前我国项目造价（成本）领域计算机及软件应用水平还有待于进一步提高。为做好造价管理中算量软件的推广和应用水平，笔者认为应做好以下几个方面：

3.1 政府及有关管理部门的应加强引导和推广力度

我国建设工程项目管理界每一次大规模、深层次的变革均有政府和相关管理部门的大力推动。因此，在项目造价（成本）领域推广工程量的自动计算也有赖于政府和管理部门的大力引导和推动。各地的造价总站应在软件开发、软件推广、人员培训及资源和信息的共享、标准规范的制订和协调等方面为软件的开发者和使用者提供比以前更大的支持力度。

3.2 加强和其他相关领域的协作

众所周知，一个商业软件的生命力取决于其所能实现的功能和兼容性、易用性、稳定性。如能实现算量软件和设计绘图软件之间数据的无缝链接，真正做到算量软件能直接调用电子图档，简化建模，无疑是功能和兼容性上的一大进步。但兼容性则不是某一家软件公司所能解决的，这就需要国家或行业协会等出面，在设计制图规范、数据接口等方面召集建筑、结构、设备及软件开发等方面专业人士协调，实现数据库规范标准的统一，将能促进工程项目管理界信息的标准化和集成化，减少社会公共成本和重复成本，能极大的促进算量软件的推广和使用。

3.3促进部分软件开发商之间的横向合作

某些自动算量软件在开过程中和绘图软件开发商合作，实现了数据传递的无缝连接，但同一套软件在读入由其他绘图软件绘制的施工图时却需大量的人工干预，费时费力。在政府和管理部门暂时还不能实现对软件开发的协调的情况下，促进绘图类软件开发商和算量软件开发的横向联合，实现数据接口统一规范，不失为解决问题的有效途径。同时应鼓励有实力的绘图软件开发商在自身的图形平台上开发算量功能模块。

4. 结束语

综上所述，笔者认为：

4.1当前，我国的项目造价（成本）领域的软件应用已取得一定成绩，但远不能和其他领域相提并论；目前所存在的主要问题是还未能最终实现工程量的自动计算。

4.2解决上述存在问题，仅靠软件开发者或使用者自身是不够的，需要必要的政府或相关机构的组织协调；实现绘图软件和算量软件、管理软件之间的信息共享、数据接口规范，实现软件开发标准的统一。