第一篇：软考论文案例_软件项目成本管理研究
软件项目成本管理研究
[作者] －[证书编号] 2013年4月9日
摘要：有效的软件项目管理可以提高软件产品质量和生产效率，有利于软件企业整体开发能力和开发水平的提高。成本管理是软件项目管理的主要内容之一。本文着重研究软件成本管理的相关内容，探讨了软件项目管理的定义、特性等，研究了一些目前常用的经典成本管理体系和方法。关键词：软件项目 成本管理 成本估算 成本控制
随着信息技术的飞速发展，软件企业在我国高新技术产业中扮演着越来越重要的角色。软件企业进行如那件项目管理有利于将开发人员的个人开发能力转换为企业的开发能力，软件企业的软件开发能力越高，表明这个企业的软件生成越趋于成熟，企业越能够稳定发展（即减小开发风险）。软件项目管理是软件企业提高竞争力的重要手段。成本管理系统是软件项目管理系统的一个子系统。有效的软件项目管理和成本控制可以更好的为软件企业积蓄财力，可以增强如那件企业的竞争力。
软件项目成本管理就是根据企业的情况和项目的具体要求、利用公司既有的资源、在保证项目进度、质量达到客户满意的情况下，对软件项目成本进行有效的组织、实施、控制、跟踪、分析和考核等一系列的管理活动，最大限度的降低项目成本，提高项目利润，实现客户、公司、员工三赢，获得更稳定的客户群，更多的公司利润和更稳定的项目队伍。目前我国软件企业实施软件项目管理的许多技术还很不成熟，只有少数大型软件企业，依据诸如CMM和ISO9000的标准规范以及一些项目管理辅助工具，实施相对规范的软件项目管理。大部分中小型软件企业，尚没有进行规范和有约束力的软件项目管理。尤其是在项目成本管理方面，软件企业的伊始还比较薄弱，经常出现项目进度延迟、成本超支的现象。
在传统的项目管理软件中，一般都是进度安排和跟踪控制，大多都不能进行软件成本估计，缺乏事先成本控制，部分项目管理软件虽然具有一些成本管理的功能，但这些项目管理软件多数是面向工程项目来设计的，真正面向软件项目的项目管理软件很少，由于软件项目自身的特殊性，导致了在应用工程项目管理软
件来管理软件项目时会出现很多的问题。成本管理在实践上主要体现在项目管理软件中，但是当前的项目管理软件并不能满足成本管理的需要。软件项目管理工具应该能偶和成本估计相互协调，不仅利用估计者的数据，还应该能够充分利用历史数据库的数据。当前的软件项目管理工具存在有如下几点不足：
1）不能进行有效的软件成本估计； 2）缺乏事先成本控制；
3）不能和估计数据自动化协调； 4）不能有效地利用历史数据库中的数据。
软件项目管理的对象是软件，它所涉及的范围覆盖了整个软件工程过程。从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段。不论是作坊式开发，还是团队协作开发，这六个阶段都必不可少的。要想对软件项目成本进行有效的管理，必须对软件项目开发的各个阶段进行深入的分析，在开发过程中除了先进的技术和开发方法，还有以整套的管理方法，侧重于软件企业在软件开发过程中对计划安排、项目跟踪、资源分配和成本控制等的管理方式。
软件项目管理的三个要素是时间进度、成本和质量。成本管理是软件项目管理的一个主要内容。成本管理从时间上可以分为初期、中期、后期和结束四个阶段。从运作上可以分为计划、执行和控制三个基本过程以及分析、评估和总结三项基本活动；从内容上涉及进度跟踪、风险分析与识别、有效沟通等方面。项目成本管理包含了所有为了保证项目在预算内完成的过程。一般包括以下过程：
1）资源计划：为了完成项目活动所需的资源种类（人员、硬件设备、软件工具等）及其数量的一种安排。
2）成本估算：开发一个完整项目活动所需要资源的大概成本估计。在传统的项目管理中，一般依靠个人经验估计较小的被分解后的活动，然后求其和为总体成本。成本估算是成本管理中的主要部分。成本估算的关键是对工作量的准确估算。对一个项目的成本做出估算。成本的主要组成部分是人力成本（工作量），此外也有其他的成本，例如出差费用、通讯工具、用于项目的培训、项目团队所使用的软硬件等。这些成本与人力成本一起构建项目的总成本。
3）成本预算：分配整体成本到每一个工作任务。
预算可以采用两种方法：其一是自上而下法，在项目总成本之内按照每一工作包的相关工作范围来考察，按项目总成本的一定比例分到各个工作包中；其二是自下而上法，有每个工作包的具体负责人进行预算估计，然后再进行平衡和调整。
4）成本控制：控制项目预算的变更。
陈本控制工作首先从确定工作分为开始，控制工作范围包括成本预算和工作进度计划。项目启动后，要进行检查和跟踪工作，然后对检查和跟踪的工作进行分析，预测其发展趋势，做出项目进度状态报告及成本发展趋势报告。根据进展状态报告及成本发展趋势报告，采取具体的纠正措施。
成本控制的核心是管理好四个关键指标：TBC、CBC、CAC和CEV【1】。总预算成本TBC（Total Budgeted Cost）表明完成一个项目总共需要多少钱。明确核算出什么级别的人一天的成本是多少，并将需要投入的人力则算成TBC中的“钱”，通过控制项目的成本来提高公司的人员使用效率。
另外三个参数CBC、CAC和CEV都和时间相关，CBC、CAC和CEV三个指标是解决如何描述一个特定时间点的成本状态的问题。
累计预算成本CBC（Cumulative Budgeted Cost）描述了一个项目按照预算在某个特定的时间点上应该话费的成本的总和。
累计实际成本CAC（Cumulative Actual Cost）描述了一个项目在某个特定的时间点世家已经花费的所有成本的总和。
累计实现价值CEV（Cumulative Earned Cost）也称净值，描述了一个项目在某个特定的时间点所有已经完成的工作产品的价值。
TBC是总共需要多少资金，而CBC、CAC和CEV则分别是某个特定时间点上的“总预算”、“总投入”和“总产出”。
三个参数中最重要的是CEV，但实际上如何准确计算CEV正是工作的难点。在软件项目中，因预算难以估算准确（CEV恰恰又以预算为基础进行计算），完工的比例也难以准确计算，所有CEV往往不太容易精确。一种改进的方法是将任务进行细分，直到便于估算、容易测量；另一种方法是不断积累历史数据、利用历史数据提高预算的准确性。
为了对上面得到的数据进行必要的分析以确定项目的状态，需要引进CV、SV、CPI和SPI四个基本概念。
（1）成本偏差CV（Cost Variance）CV=CEV-CAC，它表示当前产出的价值与投入成本的差异。显然，如果该参数为正，说明产出比投入多，项目省钱了；反之，则说明产出比投入少。
（2）进度偏差SV（Schedule Variance）SV-CEV-CBC。CBC不但表示在一个特定时间点的累计预算，启示还隐含表示在这个特定时间点上应该的产出，因此SV表示当前产出的价值与预算阐述价值的偏差。显然，如果该参数为正，说明项目进度已经提前；反之，则说明项目进度已经滞后。
（3）成本绩效CPI（Cost Performance Index）CPI=CEV/CAC，它表示投入单位成本可以产出的价值。
（4）进度绩效SPI（Schedule Performance Index）SPI=CEV/CBC，它表示当前完成的工作量占预计完成工作量的比例，1表示正好完成。
除了对项目进行绩效分析外，还可以进行预测计算FCAC（Forecasted Cost at Completion）以预计完工成本。简单的有三种方法：
（1）方法一：FCAC=TBC/CPI。方法一说明，如果项目继续以当前的成本绩效水平运行，那么到项目完工时所需要的成本有此公式计算。
（2）方法而：ECAC=CAC+(TBC-CEV)。方法二说明，如果项目剩余部分按预算完成，那么到项目完工是所需要成本按此公式计算。
（3）方法三：FCAC=CAC+重估剩余工程预算。这实际上要求完全重新估算。成本分析后可能需要采用必要措施进行调整。确定调整对象时应该优先考虑成本偏差较大、成本绩效差、成本高的工作包，并从近期开始工作任务着手进行调整。纠正措施包括使用合格的但成本较低的人工、派有经验的人指导工作、减少工作范围或降低进度、质量等。
在成本控制过程中可以利用差异分析，差异分析是指确定差异的数额，将其分解为不同的差异项目，并在此基础上调查发生差异的具体原因并提出分析报告。通过差异分析，找到造成差异的原因，分清责任，采取纠正行动，实现降低成本的目的【2】。总之，成本控制首先要规划花费的计划——CBC，然后定期核算CAC和CEV，通过分析偏差和绩效指标弄清项目状态，进而通过成本预算和采取措施确保成本向有利的方向发展。
最后，本人结合自己实际项目管理工作经验，针对软件项目成本管理过程中存在的问题进行分析和探讨。
软件项目成本管理中存在的主要问题有：
1、项目人员经济观念不强，公司缺乏一套行之有效的成本管理体质。目前，我国软件项目人员大多具有软件开发专业技术背景，但是普遍缺乏紧急观念，成本一时单薄，特别是项目不单独核算的企业，项目经理职责更偏重于技术而非管理智能，简单的将项目成本管理的责任归于财务部门。同时，软件公司通常缺乏行之有效的成本控制和激励体制。很多只是简单的规章制度，至于谁做，何时做，做到什么程度都没有提及，实际运作起来难度大。在项目内部，每个成员指从自己的角度考虑，项目成本居高不下。
2、项目的过程控制薄弱。项目管理的过程是计划、实施、监控、纠偏、分析、考核【3】。
项目成本预算和估算精准度差，失去了控制标准。在项目管理中，相关的管理部门通查要求项目经理做出项目的估算或预算，并一次为标准，进行项目的控制和考核，但是在实际工作中，由于项目具有一次性和不确定性的特点，以及项目经理自身的经验和水平的限制，使项目估预算的准确性很差，一变化，项目经理就追加预算，常常是计划跟不上变化，预算频频变更，等项目结束时，实际成本和初始计划已经大相径庭。
3、缺乏“质量成本”、“工期成本”、“资金成本”、“风险成本”的管理和控制。
质量成本是指为了确保和提高软件质量而发生的一切必要费用，以及因未达到质量标准而蒙受的损失。工期成本是指为了实现项目工期目标而采取相应措施所发生的一切费用。资金成本是指资金的一切费用。风险成本是指项目的不确定因素导致项目风险。
为了应对企业软件项目管理中的问题，企业管理者可以从以下三个方面入手：
1、树立全员经济意识，建立规范成本管理体制。
软件企业必须加大宣传力度, 从项目管理人员到普通员工都要进行经济教育, 灌输经济意识, 把一切为了效益的意识深深地铭刻在每个职工的脑海里。
要根据公司和项目本身的特点, 制定有针对性的项目成本管理办法和流程, 这些管理办法应是责任到人、切实可行的具有较强操作性的办法, 使项目的成本控制有法可依, 有章可循, 有据可查。
对于每个项目, 都要有成本控制的目标—项目预算, 都要严格做工作任务分解,在落实任务的同时, 也要落实完成任务所需要的成本预算, 并且逐级负责, 层层落实。项目经理是项目成本管理的领导, 这样形成了一个以项目经理为核心的成本管理体系。
同时用一定物质奖励去刺激, 使每个人的工作、成本和项目的效益挂钩, 彻底打破过去那种干好干坏一个样, 干多干少一个样的格局。调动职工的积极性和主动性, 使大家共同为项目的成本管理献计献策。
2、加强项目过程管理和监控。
3、从质量成本、工期成本、资金成本、风险成本管理上要效益。质量成本管理的目标是使类质量成本的综合达到最低值。一般来说, 质量预防费用起初较低, 随着质量要求的提高逐渐会增加, 当质量达到一定水平再要求提高时, 该项费用就会急剧上升。质量检验费用较为稳定, 不过随着质量的提高也会有一定程度的增长。而质量损失则不然, 开始时因质量较差, 损失很大, 随着产品质量不断改进,该项损失逐步减少。三者交叉的作用, 必须能找到一个质量成本最低的理想点。
正确处理质量成本中几个方面的相互关系即质量损失、预防费用和检验费用间的相互关系, 采用科学合理、先进实用的技术措施, 在确保质量达到设计要求水平的前提下,尽可能降低软件项目成本。同时也不能为了提高企业信誉和市场竞争力而出现质量过剩的现象,导致完成工作量不少, 经济效益 低下的被动局面。
从工期成本控制上要效益。工期成本管理的目标是正确处理工期与成本的关系, 使工期成本的总和达到最低值。工期成本表现在两个方面, 一方面是项目经理为了保证工期而采取的措施费用;另一方面是因为工期拖延而导致的业主索赔成本, 这种情况可能是由于外部因素引起的, 也可能是内部因素所造成的,如停工、窝工、返工等, 因此所引起的工期费用, 可称其为工期损失。一般来说, 工期越短, 上期措施成本越小二但当工期缩短至一定限度时, 工期措施成本就会
急剧上升。而工期损失则不然, 因外部因素引起的工期损失, 其损失额度相应较小, 通常情况下不予赔偿或赔偿额度较小, 该部分工期损失可不予考虑。因项目内部因素造成的工期损失, 随着时间的推移, 经验的积累会逐渐减少。综合工期成本的各种因素, 就会找到一个工期成本为最低的理想点。这一点也就是上期最短并且成本最低的最优点。
由于内外部环境条件及合同条件的制约, 保证合同工期和降低成本是一个十分艰巨的任务。因此, 必须正确处理工期成本的两个方面的相互关系, 即工期措施成本和工期损失之间的相互关系。在确保工期达到合同条件的前提下, 尽可能降低工期成本, 切不可为了提高企业信誉和市场竞争力, 盲目抢工期赶进度, 造成增大项目成本, 导致项目亏损。
项目现金流的控制。通过项目的财务现金流分析, 判断项目资金收支的时间, 资金亏口的时间点, 便于提前准备资金。同时积极地从客户方催款,以便支付各种费用。使得现金的流人大于流出。对于产品投资项目可采用投资回收期、净现金流来控制。
通过主动的风险控制, 防患未然, 避免和减少损失。根据拟建软件项目的具体情况, 有选择性地进行经济模型盈亏平衡分析、敏感性分析和概率分析、合同控制等, 这里强调一下常用到的合同控制。软件项目的各种经济活动, 都是以合同或协议的形式出现。如果合同条款不严谨, 容易让对方钻空子, 造成自己蒙受损失时应有的索条款不能成立, 产生不必要的损失。所以必须细致周密地订立严谨的合同条款。首先, 要有相对固定的经济合同管理人员, 并且精通经济合同法规有关知识, 必要时应持证上岗；其次是要加强经济合同管理人员的工作责任心； 三是要制定相应固定的合同标准格式。项目合同基本上有以下几类：软件开发合同、技术服务合同、采购合同、分包合同、劳务合同等。各种合同条款在形成之前应由业务部门参与定稿, 使各项条款的内涵清楚, 严谨不漏。
软件企业具有知识经济的明显特点, 不同于传统的成本控制, 而软件企业管理具有以项目管理为主的重要特征, 以上是软件企业在成本管理中经常出现的实际问题, 本人根据实际经验提出的对策, 旨在针对软件企业的特点, 提高软件企业的财务管理和项目管理。
参考文献：
[1] 金小云, 软件开发项目的计划和控制管理研究，西北工业大学，硕士学位论文，2003.2，48-49 [2] 付强，沈川，蒋峰 编著，有效的项目管理，中国纺织出版社 [3] 许成绩 主编，现代项目管理教程，中国宇航出版社，2003
作者简介：
***，男，湖南大学计算机应用专业硕士，系统架构师、国家网络工程师、系统集成高级项目经理。具有12年IT从业经验，对软件开发项目运作的各个流程、环节相当有经验，具有丰富的工程实践与管理经验。
第二篇：软件项目成本管理概念
成本管理是软件项目管理的主要内容之一，分析了目前软件开发成本管理过程中存在的问题，提出了将进度和成本联系起来考虑，使工作量和实际成本匹配的方法。结合现有的估算方法，设计成本管理系统并将其应用于软件项目管理平台中，旨在改善软件开发中成本超支的现象，为企业提高效益。
关键词软件项目管理平台 成本估算 成本控制
随着信息技术的飞速发展，软件产业在国民经济中扮演着越来越重要的角色。对软件开发实施有效的管理是决定软件产业发展的至关重要的因素。在软件项目的开发过程中，项目管理日益受到人们的关注。软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。成本管理是软件项目管理的一个主要内容，就目前发展来看，成本管理是软件项目管理中一个比较薄弱的方面，许多软件项目由于成本管理不善，造成了软件造价的成本上升，软件质量得不到保证。针对这些现象，文章提出了一种新的成本管理方法，并将其应用于正在研究中的课题--软件项目管理平台的开发当中，以便于开发有效的软件项目管理工具，为企业节约成本，提高经济效益。成本管理概述
项目成本管理包括确保在批准的预算范围内完成项目所需的各个过程[1]。软件项目成本的管理基本上可以用估算和控制来概括，首先对软件的成本进行估算，然后形成成本管理计划，在软件项目开发过程中，对软件项目施加控制使其按照计划进行。成本管理计划是成本控制的标准，不合理的计划可能使项目失去控制，超出预算。因此成本估算是整个成本管理过程中的基础，成本控制是使项目的成本在开发过程中控制在预算范围之内。
1.1 成本管理的过程
软件项目成本管理就是根据企业的情况和项目的具体要求，利用公司既定的资源，在保证项目的进度、质量达到客户满意的情况下，对软件项目成本进行有效的组织、实施、控制、跟踪、分析和考核等一系列管理活动，最大限度地降低项目成本，提高项目利润。
成本管理的过程包括[1]：
l 资源计划，包括决定为实施项目活动需要使用什么资源（人员、设备和物资）以及每种资源的用量。其主要输出是一个资源需求清单。
l 成本估算，包括估计完成项目所需资源成本的近似值。其主要输出是成本管理计划。
l 成本预算，包括将整个成本估算配置到各单项工作，以建立一个衡量绩效的基准计划。其主要输出是成本基准计划。
l 成本控制，包括控制项目预算的变化。其主要输出修正的成本估算、更新预算、纠正行动和取得的教训。
1.2 软件开发成本管理过程中的主要问题
（1）项目成本预算和估算的准确度差。
由于客户的需求不断变化，使得工作内容和工作量不断变化。一旦发生变化，项目经理就追加项目预算，预算频频变更，等到项目结束时，实际成本和初始计划偏离很大。
此外，项目预算往往会走两个极端：过粗和过细。预算过粗会使项目费用的随意性较大，准确度降低；预算过细会使项目控制的内容过多，弹性差，变化不灵活，管理成本加大。
（2）缺乏对软件成本事先估计的有效控制。
在开发初期，对成本不够关心，忽略对成本的控制，只有在项目进行到后期，实际远离计划出现偏差的时候，才进行成本控制，这样往往导致项目超出预算。
（3）缺乏成本绩效的分析和跟踪。
传统的项目成本管理中，将预算和实际进行数值对比，但很少有将预算、实际成本和工作量进度联系起来，考虑实际成本和工作量是否匹配的问题。
1.3 成本管理方法的改进
目前常用的软件项目管理工具都侧重于某一方面的功能，如微软的Project2000侧重管理、规划任务，并在项目执行过程中跟踪这些任务，偏向于进度安排与跟踪控制；RUP侧重于用户需求的描述；PVCS侧重于软件变更管理。这些软件项目管理工具都在不断的完善其功能，虽然也有成本管理的功能，但总的来说大多数都不能用来进行软件成本估计，缺乏事先成本控制，不能和估计数据自动化协调，不能自动化地利用历史数据库中的数据。当前的项目管理工具并不能满足成本管理的需要。
针对以上成本管理过程中出现的问题，以及目前软件项目管理工具的不足，文章提出了一种改进的管理方法，将进度和成本联系起来考虑使工作量和实际成本匹配的方法。并且结合已有的成本估算方法，同时将过程数据库引入到软件项目管理中，给出成本管理系统的原型设计。系统采用先进的估算方法解决了成本估算准确度差的问题，工作量和实际成本匹配的方法进行成本的绩效分析和跟踪使得项目成本能够控制在预算范围之内。
回答人的补充2009-06-29 22:28成本管理系统的设计
2.1系统总体设计
虽然目前已有不少项目管理软件，但一般只是管理软件进度和跟踪监督，和软件估算是项目独立的，而且目前还没有成型的软件项目成本管理软件，我们以为指南，研究软件开发过程中的特殊性，结合现有的软件成本估算技术和一般行业的项目管理技术，以进度、人员、成本，变更为中心，提出了软件成本管理的具体实施方案。并以此为基础对系统的功能进行分析和设计。图1是系统的基本体系结构图。结论
该文讨论了目前已经有的一些软件项目管理系统的不足，不能把预算、工作量和实际进度联系起来考虑做到有效的成本管理，本文提出了改进的成本管理方法，可以对成本管理进行准确的估算、有效的控制，并且给出了系统的设计。但由于软件项目管理本身的复杂性，虽然本文所提出的方法有助于成本管理中估算
与控制问题的解决，但仍然不可能做到非常好，如果能将成本和进度、质量联系起来取得三者之间的平衡，势必对软件企业的项目管理有很大的实用价值
第三篇：项目成本管理论文（精选）
浅谈工程量清单计价下的施工项目
成本管理
十六项目部 吴宇辉
一、项目成本管理常见问题
目前阶段施工单位对于项目成本管理虽然已经有了分解、执行和考核的普遍做法，但由于长期受计划经济思路的局限，特别是定额计价方式的影响，施工项目成本管理在以清单计价为标志的新竞争环境下明显存在许多问题和不足，如项目组织与成本管理要求不甚协调、缺乏全员全过程成本控制思路、尤其是缺少实际可以减少成本支出的具体措施。
1、项目成本管理体制缺乏责权利统一
项目成本管理体系中应以项目经理为核心，通过给业务部门主管以及管理人员分解相应的成本责任、管理权力及利益分配，建立合作、约束和激励相结合的成本管理组织机构和运行机制。在目前的施工项目成本管理体制中，各岗位职责在成本管理方面没有很好地将责权利三者结合起来：一种情况下，项目将成本管理的责任完全归于成本管理主管，而生产及技术部门以完成进度和质量为考核指标，造成成本管理盲区。例如当因抢工导致质量问题，造成经济损失时责任就不明确，处罚没有针对性；又如技术人员提出了一个经济可行的施工方案，往往奖励又不能到位，在一定程度上挫伤技术发明人的积极性，不利于工程项目的成本管理与控制。另一情况下，项目经理越位承担成本管理主管的工作、实施上独立承担成本管理责任，而由于其核心地位造成决策往往失去有效制约，给项目成本管理带来巨大隐患。
2、缺乏全员、全过程成本控制思路
长期以来，项目技术人员只负责技术和工程质量，工程生产人员只负责施工生产和工程进度，这样表面上看起来分工明确、职责清晰，各司其职，唯独没有了成本的责任控制，结果对成本核算、设计变更、工程索赔等事后控制造成极大的隐患。在这种情况下，即使在施工阶段技术和措施制定得再完美，也起不到控制成本的作用。使各种成本管理措施成为少数人的责任、成为不折不扣的空中楼阁。而在施工中又普遍存在简单地按照以往的工程经验来编制施工组织设计，沿用经验工程的成本降低率编制成本计划和制定目标成本，而忽略了该工程的现场环境以及施工条件和工期的要求；简单的将成本管理看作是实施阶段的管理甚至只是采购阶段的管理，而忽略了前期成本设计、实施监控、方案调整、工程索赔和成本核算其他过程的管理，不利于成本管理可持续性发展。
3、缺少实际可以减少成本支出的具体措施
推行工程量清单计价模式后，由于分部分项工程量清单提供的主要是实物工程量，不限制具体的施工工艺和方法，投标人需主动结合工程实际和自身情况，选择合理经济的施工工艺和方法并在此基础上进行报价，充分竞争。因此目前项目管理主要成本管理措施的问题有：一种情况，高调宣传节约增效，但如何针对清单收入做到节约增效则往往没有实施细则，可操作性不强；另一种情况，常常将成本管理简单看做是物料的低价买高价卖，不能反映清单计价下成本管理的全面性，科学性不强；
1、单价的固定性。工程量清单经投标人填写价格后成为清单报价表，招标人通过中标书的方式确认，工程量清单单价具有法律意义，不能随意变动。工程结算时，如果构成工程实体的数量与清单中的数量有差异，则以实际的工程量乘以清单中的报价构成工程结算价。
2、单价综合性。《计价规范》规定：“工程量清单应采用综合单价计价。”同时，还规定：“综合单价是完成工程量清单中一个规定计量单位项目所需的人工费、材料费、机械使用费、管理费和利润，并考虑风险因素。”以上条款衍生意义中也指单价中综合包含了该工程项目的责任、义务和风险。
3、工程量清单计价工程价款的构成。工程量清单计价工程价款构成包括按招标文件规定，完成工程量清单所列项目的全部费用，即包括分部分项工程费、措施项目费、其它项目费和规费、税金等。其中分部分项工程费基本为构成工程的实体性消耗项目，而措施项目费基本为实现实体而需要投入的实体或非实体性消耗。
四、工程量清单计价下施工成本管理
有了原则和对计价方式的理解，我们可以针对性的提出以下措施以保证成本管理目标的实现。
1、树立全员成本管理意识
工程项目成本管理和控制，不只是管理的问题，而是管理、经济、技术与法律等的综合反映。加大成本管理的宣传力度，将成本分解、责任确定、效益分配及奖罚处理的系列措施贯彻到项目实施的每个人员。从成本管理和控制的优越性方面来引导和深入，将一切影响成本的因素纳入强化管理范畴，力争人人关心，处处把关，层层控制，调动职工的积极性、主动性、创造性，才能形成强大的凝聚力和群体的敬业精神，克服只管干活拿钱、不管投入产出，只管本职岗位、不讲补位配合的传统观念，树立成本和收益是人人都有责、人人得利的大局观念。切实增强全员责任成本意识，才能使成本得到有效控制，实现成本控制的根本转变。
2、完善机构，健全机制，强化全员参与和协作
工程项目成本管理离不开高效的组织机构，这个机构即要树立项目经理的成本管理的核心和决策地位，同时也要建立充分的分工、授权机制，使生产、技术、经营部门主管既各有职责又互相合作，既是项目经理的团队成员同时也是也要就业务成绩对企业各主管部门负责。施工项目在进行成本控制过程中，各业务部门要相互配合，加强横向业务联系，充分发挥成本管理部门的核算监控职能作用，技术部门的龙头作用，计划部门的基础作用，物资、设备、安全等生产部门的落实作用，财务部门的保障作用，纪检部门的法律监督作用，才能确保责任成本控制系统不失灵，成本管理运作能力不断完善和加强。
3、加强工程量清单计价工程中成本构成要素的动态控制
工程量清单计价的工程, 工程造价在正常情况下已基本确定，只是当出现合同条件发生变化（如设计变更、工程量变动等）时，可按合同规定进行调整。工程量清单计价的工程成本控制的重点，是在工程造价已基本确定的前提下，如何对成本构成要素进行管理及控制。（1）对人工费的控制
人工费在建筑产品成本中约占10-15％左右，并且随劳动力市场价格变化而变化。对整个施工期间所需发生的人工费作出切合实际的预测，是控制人工费用支出的前提条件。
首先应根据企业施工进度计划中劳动力消耗量计划，计算出各施工工序合理的用工数量，结合劳动力市场人工单价计算出总的人工费控制指标，并根据工程进度计划，将其分解到各月，形成每月的控制指标，在每月月末，对本月完成的各项工程用工数量与月初计算的控制用工数量对比，考核控制指标完成情况。其次在施工过程中，推行工序单价承包制，依据工程量清单及企业定额，科学、合理地测算每道工序的承包标底价，并引入竞争机制，在班组之间开展竞标，实行优胜劣汰，与善管理、单价低的施工班组签定每道工序的承包单价合同，以达到控制和降低成本的目的。另外，人工费用支出中，要杜绝工程量清单以外又无法签证的用工，因为这些用工是不能得到费用补偿的，这些支出意味控制指标的失控，也就会减少已取得控制成果。（2）材料费用的控制
材料费用在建筑产品成本中约占60-70%左右，是成本控制的重点。材料费用的控制主要应从“量”和“价”两方面进行。根据材料的供应方式不同，“量”和“价”的控制也有所不同。在“量”上，①在合理使用条件下，实行限额领料制度，各班组只能在规定限额内分批领用，如超出限额领料，要分析原因，及时采取纠正措施；②要不断改进和优化施工方案、施工方案和施工部署；③严格控制进料，购料一定要严格办理验收交接手续。对经检验不合格或在运输过程中损坏的材料，应立即与供货方办理更换或退货手续，以免埋下质量隐患；④加强现场管理，材料进场后应妥善堆放保管，避免二次倒运和损失浪费。运用行政、经济的管理手段，健全和完善材料的管理机制，实行统一采购和供应，降低采购价 格。实行材料领用责任制，专料专用，包干控制的方法。
在“价”上，①买价控制，通过采购过程降低材料单价来控制，对量大价高的材料，一方面要发挥企业集团化优势，通过集团采购（如有的材料是企业各分公司或项目都要用的，就可由公司组织，集体采购），降低成本；另一方面要尽量直接向厂家定购，减少中间环节，降低流通成本。对一般性的材料，要在保证材料质量前提下货比三家，以最低的材料价作为采购价格。同时，还应注意市场
信息，随时掌握主材的变化趋势，争取在价格对自己最有利时与材料供应商签订合同。坚持“质量择优、价格择廉、路途择近”的原则，以降低成本；②考虑资金时间价值，争取材料直拨，减少中转环节，计算好经济库存，合理确定进货批量和匹次，并加快货物的周转，减少流动资金的占用，尽可能降低材料储备。③如果市场材料价格已高于投标时考虑的材料价格风险，那么就应及时与业主协商，争取重新签署一个新的材料价格。
此外，对业主供应的材料，重点放在“量”的控制上，要确保足斤足两，并严把质量验收及材料入库环节。另外，在施工过程中，还应积极推广新技术、新工艺、新材料，通过改进施工技术，达到节约材料的目的。月末应把控制后的材料用量和价格同工程量清单上的数量和价格进行对比，考核实际效果，对超控部分要落实清楚，找出原因，并提出解决方案。（3）机械使用费的控制
机械使用费在建筑产品成本中约占5～10%，机械使用费的控制，①主要是控制使用机械的台班数，应根据施工现场具体情况，合理布局、精心安排、充分利用各种机械，使其不超过工程量清单中的机械台班数。②充分利用现有机械的内部合理调度，力求主要机械的利用率，在设备选型中，注意一机多用。③注意技经结合的方案分析，通过方案对比选择租赁还是购置，通过方案组合挑选最优化的设备配置。④严格执行机械的保养程序，减少不必要的修理费。⑤配备技术素质高的机械手，开展机械设备责任制，把油耗和人为损失降到最低点，提高台班出勤率。⑥对主要部件及其保养情况建立档案，保证设备寿命、提高残值。（4）管理费的控制
成本费用除人工费、材料费、机械使用费等直接成本外，还有综合费（包括管理费和利润）、风险金等其他成本费用。这部分已综合在了工程量清单的各子项的综合单价之中，中标后已成既定的数，①在施工过程中应重点注意管理费用的节约，制定切实的预算指标，对每笔开支严格依据预算执行审批手续；提高管理人员的综合素质，作到高效精干，提倡一专多能。②对办公费用的管理，从节约一张纸、减少每次通话时间等方面着手，精打细算，控制费用支出。③对于现场经费管理也是一个重点，调整施工方案、控制试验费用支出；精心安排施工，减少水电费用支出，现场合理布局使其既能满足施工现场的需要，又能满足文明施工的需要，同时减少现场经费支出。
（5）项目措施费用的控制
清单中的措施费是指为完成工程项目施工，发生于该工程施工前和施工过程中非工程实体项目的费用。内容包括环境保护费、文明施工费、安全施工费、临时设施费、夜间施工费、二次搬运费、大型机械设备进出场及安拆费、混凝土、钢筋混凝土模板及支架费、脚手架费、已完工程及设备保护费、施工排水、降水费等。其费用是由施工单位根据工程具体情况按可能发生的措施项目进行的报价。因此，在施工工程中，一方面加强技术与经济的结合，编制出既切实可行又
能节约各项措施费用的施工组织设计和施工方案；另一方面精心布置施工平面布置图，尽量减少临时设施费用，合理布置材料堆场，尽量避免二次搬运；同时加强工人的安全文明意识教育，防止安全事故及城市罚款等不必要支出的发生。（6）设计变更和工程签证的控制
施工过程中，按照建筑施工合同的约定，因设计文件或技术规范修改或业主需要，可对原工程设计进行变更。相应的，施工方在接到工程师（合同中约定的）的变更通知后，对因设计变更而导致的工程任何部分的标高、基线、位置、尺寸的改变；因设计变更或工程规模变化而引起的工程量增减；因设计变更或技术规范改变而导致的工程质量、性质或类型的改变；因规范变更而使得工程任何部分规定的施工顺序或时间安排的改变以及为使工程竣工而必需实施的任何种类的附加工作等都应作出相应的价款变更。同样对施工图以外的内容及停水、停电，或因业主提供的材料供应不及时造成停工、窝工等都需要办理工程签证，并按合同约定，及时办理价款的确认。加强设计变更和工程签证工作是施工企业经济活动中的一个重要组成部分，它可防止应得效益的流失，反映工程真实造价构成，对施工项目管理来说更显得重要。
4、成本管理工作中的一些有效思路
以上从四个方面谈了施工项目成本管理，相辅相成，缺一不可，但还需要结合具体问题具体分析，灵活运用风险转移、技经结合、价值工程等途径来促进成本管理的最优化。例如在笔者经历的市中心某框剪结构写字楼工程中现场十分狭窄，钢筋原材加工、码放、二次搬运和班组交接均会导致损耗率的提高，对比企业内类似工程经验钢筋损耗率在6-8%，也即是每吨成型钢筋价格中净损耗费用160元/吨（加工损耗为280元/吨，废料回收残值约120元/吨），加上钢筋后台加工费180元/吨，每吨成型钢筋比原材增加340元/吨；而通过技经分析，决定钢筋工程采用场外加工方式供应。通过市场招标，选择北京物协公司供应成型钢筋到场，由于其规模化的库存和生产能力了稳定了原材价格和降低加工成本，每吨成品按钢筋市场约定日期供应价格加220元结算，每吨降低费用120元，共节约成本25.33万元；此外合同约定日期结算价格低于供货当期市场价格平均约110元/吨，节约成本23.22万元。另如在某公建临设工程中，对于办公及生活区用房搭设没有简单按照彩钢板房或是砌块砌筑方案执行，而是把各种用房如办公室、厨房、库房、宿舍的功能进行分析，结合彩钢板、水泥预制板、砌块及各种家具的成本进行价值工程分析，计算确定各用房结构选择和内部设施的投入，确定租赁或购置形式，达到即能满足工程需要又不造成浪费，从而有效控制成本的目标，此工程临时用房2600平方米，投入仅48.60万元，仅占工程造价的1.15%、全部临设收入的32%，对比同类工程50%以上的投入水平，成本控制效果良好。
综上所述，清单计价模式下成本管理充满挑战，但我们遵循科学管理的客观规律，发现问题、分析问题再到解决问题，通过施工项目全员努力和制定针对性的新措施、新机制，那么项目管理就会有新机遇，就会在市场竞争中走在前列。
（完）
第四篇：项目成本管理案例分析
第4章 项目成本管理案例
项目的成本是项目的全过程所耗用的各种费用的总和。项目的成本管理对于组织来说非常重要，成本管理并不只是把项目的成本进行监控和记录，而是需要对成本数据进行分析，以发现项目的成本隐患和问题，在项目遭受可能的损失之前采取必要的行动。
项目成本管理希望节约项目的费用，但并不意味着要一味减少成本。例如：在信息系统项目中，减少测试无疑能够减少项目的费用，但没有测试，如同许多曾经进行过的信息系统一样，把用户当做测试者，可能对项目造成灾难性的后果，最终，或者使得项目的成本大为提高，或者让项目走向失败的边缘。
4.1 案例一：成本估算
阅读以下关于信息系统项目管理过程中成本估算方面问题的叙述，回答问题1至问题3。4.1.1案例场景
希赛信息技术有限公司(CSAI主要致力于为国内教育提供信息化服务，成立业内一流的研发中心，不断研究和推出深受用户欢迎的软件产品，客户遍布中国每个省/市/自治区。公司创立8年来，通过不断加强和改进技术管理来完善产品和提升服务品质，已成为中国教育软件研发领域首家通过CMM3评估项目的公司。
张工是CSAI的项目经理，1个月前刚接手某高校学生管理系统研发项目。完成项目需求调研后，张工开始制定详细的进度和成本计划。表4-1和表4-2 分别是张工用两种方法做的项目成本估算，估算货币单位为(元)。
【问题1】(8分)请用200字以内说明信息系统项目管理过程进行成本估算的基本方法。
【问题2】(8分)表4-1和表4一2分别采用了什么估算方法，表中估算成本A, B各为多少？
【问题3】(9分)请结合你本人的实际项目经验，用300字以内文字分析信息系统项目成本估算过程中的主要困难和应该避免的常见错误。4.1.2案例分析
【问题1】
信息系统开发项目中常用的成本估算方法包括自顶向下估算法、自下而上估算法、参数估算法、专家估算法和猜测估算法等，其中自顶向下估算法也称为类比估算法。
(1)自顶向下估算方法
自顶向下估算法是从项目的整体出发，进行类推，即估算人员根据以往完成类似项目所消耗的总成本或工作量，来推算将要开发的信息系统的总成本或工作量。然后，按比例将它分配到各个开发任务单元中，是一种自上而下的估算形式，通常在项目的初期或信息不足时进行。例如，在合同期和市场招标时等。不是非常精确的时候或在高层对任务的总的评估的时候采用这种方法。该方法的特点是简单易行和花费少，但具有一定的局限性，准确性差，可能导致项目出现困难。(2)自下而上估算方法
自下而上估算法是利用工作分解结构图，对各个具体工作包进行详细的成本估算，然后将结果累加起来得出项目总成本。用这种方法估算的准确度较好，通常是在项目开始以后，或者WBS已经确定的开发阶段等，需要进行准确估算的时候采用。它的特点是这种方法最为准确。它的准确度来源于每个任务的估算情况，非常费时费力。估算本身也需要成本支持，而且可能发生虚报现象。(3)参数估算方法
参数估算法是一种使用项目特性参数建立数据模型来估算成本的方法，是一种统计技术，如回归分析和学习曲线。数学模型可以简单也可以复杂。有的是简单的线性关系模型，有的模型就比较复杂。一般参考历史信息，重要参数必须量化处理，根据实际情况，对参数模型按适当比例调整。每个任务必须至少有一个统一的规模单位。例如，平方米(m)，米(m)，台，KLOC，FP，人/天，人/月，人/年等。其中的参数如xx 元/m, xx 元/m, xx元/台，xx 元/KLOC, xx元/FP, xx元/人/天。一般说存在成熟的项目估算模型和具有良好的数据库数据为基础时可以采用。它的特点比较简单，而且也比较准确，是常用的估算方法。但是，如果模型选择不当或者数据不难，也会导致偏差。
通常有两类模型用于估算成本，即成本模型和约束模型。
成本模型是提供工作量或规模的直接估计，常常有一个主要的成本因素，例如规模，还有很多的次要调节因素或成本驱动因素。典型的成本模型是通过历史项目数据，进行回归分析得出的基于回归分析的模型。
约束模型显示出两个或多个工作量参数，持续时间参数或人员参数之间时间变化的关系。例如，PRICE-S和Putman模型。(4)专家估算法
专家估算法是由多位专家进行成本估算，一个专家可能会有偏见，最好由多位专家进行估算，取得多个估算值，最后得出综合的估算值。其中最著名的是Delphi方法，该方法的基本步骤如下：
①组织者发给每位专家一份信息系统的规格说明和一张记录估算值的表格，请他们估算。
②专家详细研究软件规格说明后，对该信息系统提出3个规模的估算值。
．最小值ai； ．最可能值mi ．最大值bi。
③组织者对专家表格中的答复进行整理，计算每位专家的平均值Ei=(ai+4mi+bi)/6然后计算出期望值：E=El+E2+„En/n。
④综合结果后，再组织专家无记名填表格，比较估算偏差，并查找原因。
⑤上述过程重复多次，最终可以获得一个多数专家共识的软件规模。(5)猜测法
猜测法是一种经验估算法，进行估算的人有专门的知识和丰富的经验，据此提出一个近似的数据，是一种原始的方法，只适用于要求很快拿出项目大概数字的情况，对于要求详细估算的项目是不适合的。
在实际软件项目中，进行软件规模成本估算时常常考虑三种模型：自顶向下估算法、自下而上估算法、参数估算法。自下而上法费时费力，参数法比较简单，自下而上法与参数法的估计精度相似。但是各种方法不是孤立的，应该注意相互结合使用。类比法通常用来验证参数法和自下而上法的结果。
最后，介绍一下目前企业软件开发过程中常用的软件成本估算方式，它是一种自下而上和参数法的结合模型，步骤如下。
(1)对任务进行分解。均值avg。
(3)计算每个任务的估算值Ei=(max+4avg+min)/6。(4)计算直接成本=El+E2+„+Ei „ +En。(5)计算估算成本=直接成本＋间接成本。
其中
风险基金＝估算成本×a％(一般情况：a为10-20左右)税=估算成本× b%(一般情况为5左右)间接成本是指直接成本之外的成本。如安装、培训、预防性维护、备份与恢复的费用，以及与运行系统相关的劳务和材料费、管理费、相关补助费用及其他等。
【问题2】
表4-1采用了自下而上的成本估算方法，表4-2采用了参数法成本估算方法。
项目经理的成本是30元/小时,项目经理张工参与项目的时间是500小时,而分析人员的成本参数是
(6)计算总成本＝估算成本＋风险基金＋税。
(2)估算每个任务的最大值max,最小值min,平
2220元/小时,2个分析人员,每人参与项目时间是500小时,编程人员的成本参数是13元/小时,2个编程人员,每人参与项目时间是1000小时，由于参数模型是简单的线性模型，所以，很方便计算出人力成本是61000元；其间接成本包括一般管理费和额外费用,一般管理费是人力成本的35%，额外费用是人力成本和管理成本的20％；这样合计为98820元；还有设备费用及其间接费用13000元,项目成本总计111820元，详见表4-3。
对于表4-1，估计分解之后每个任务的规模，然后总计项目的总规模成本。
采用自下而上的估算方法，用的模型是：
估算总值＝估算值＋风险基金＋税 其中
估算值=直接估算值＋间接估算值
间接估算值=直接估算值× 15% 风险基金=估算值× 20% 税=估算值×5% 要求估算的误差应该保持在－5%～+5% 按照这个算法并根据表4-3的WBS的分析结果图示，估算过程如下：
直接成本＝202000元
间接成本＝202 000 × 0.15＝3030元
估算值＝202 000+3 030＝23230元
总成本＝23 230+23 230 × 20%+23 230 × 5 %＝29037.5元
经过计算，两表中A为202000元，B为111820元。
【问题3】
综合起来，信息系统的项目成本估算的困难主要包括以下方面：
(1)需求信息的复杂性。与其他有些传统项目不同，信息系统要满足的是人的主观需要。由于人的复杂性，给信息系统带来了无数的难以确定的因素。对信息系统的估算自然是个复杂的工作，而现实中往往不允许在项目的初期投入太多的资源，对项目的成本进行估算。而且，随着项目的进展，许多具体情况的明确，项目的成本估算也会相应地有所变化。
(2)开发技术与工具的不断变化。开发工具软件的不断升级，技术方案的不断更新，这些技术的进步让信息系统项目可以提供功能越来越强、使用越来越方便的产品或者服务，但是都给信息系统项目的成本估算带来困难。
(3)缺乏类似的项目估算数据可供参考。有效的项目成本估算是建立在大量的同类项目的成本结算的基础上的。没有大量的同类项目的经验，信息系统项目的成本估算也就非常困难。许多组织并不注意整理和收集本组织内部的信息项目的成本数据，更不要说去收集整理其他组织的成本数据了。
(4)缺乏专业和富有经验的人才。可以根据同类项目的历史成本来估算当前项目的成本，历史项目和当前项目的不同点和相同点是估算过程中需要判断的重要问题，这种判断需要估算人员有丰富的经验和专业知识。
(5)信息系统研发人员技术能力的差异。在信息系统建设的成本中，有很大一部分是人力资源的成本，而不同人员的不同的态度、经验和能力都会造成不同人员的截然不同的效率，这也给信息系统的成本估算带来极大的困难。
(6)管理层的压力与误解。管理层会要求对项目成本进行估算，但是他们所需要的往往是期待一个比他们所预计的要小的值，以便能够赢得合同或者投资。
在对项目进行成本估算时，应该避免以下的常见错误。
(1)草率的成本估算。由于市场和管理层的压力，项目组成员或者管理者被迫在没有进行真正准备的情况下做出成本估算。如何面对管理层的压力，向管理层的压力，向管理层解释如何才能得到较为准确的项目成本估算也是对项目管理者的沟通能力的考验。
(2)在项目范围尚未确定时就进行成本估算。在信息系统中也非常常见，往往是项目组对该做什么，不该做什么还只有一个粗略的概念时就要进行成本估算。
(3)过于乐观或保守的估算。过于乐观的估算会给项目组的项目实施带来很大的压力。而过于保守的估算也会由于Parkinson定律(时间充裕时,工作随之膨胀,收入增加时,花销随之增长)也会对项目造成不利影响,甚至可能让组织放弃本来可能是有利可图的项目。4.1.3参考答案
【问题1】(8分)信息系统项目进行成木估算的基术方法包括：
(1)自顶向下估算法或类比估算法。(2)自下而上估算法。(3)参数估算法。(4)专家估算法。(5)猜测估算法等。
【问题2】(8分)表4-1采用了自下而上的成本估算方法,表4-2采用了参数法成本估算方法。经计算,两表中估算值A为202000元,B为111820元。
【问题3】(9分)综合起来，信息系统的项目成本估算的困难主要包括以下方面：
(1)需求信息的复杂性。(2)开发技术与工具的不断变化。(3)缺乏类似的项目估算数据可供参考。
(4)缺乏专业和富有经验的人才。(5)信息系统研发人员技术能力的差异。(6)管理层的压力与误解。
在对项目进行成本估算时，应该避免以下的常见错误：
(1)草率的成本估算。(2)在项目范围尚未确定时就进行成本估算。(3)过于乐观或者保守的估算。
4.2 案例二：成本估算
阅读以下关于信息系统项目管理过程中成本估算问题的叙述，回答问题1至问题4。4.2.1案例场景
希赛信息技术有限公司(CSAI)凭借丰富的行业经验和精湛的技术优势，坚持沿着产品技术专业化道路，为银行、证券、保险等领域提供完整全面的解决方案。李工是CSAI证券事业部的高级项目经理，目前正负责国内B银行信贷业务系统的开发项目。作为项目经理，李工必须制定高质量的项目管理计划，以有效实现范围、进度、成本和质量等项目管理目标。
项目正式立项后，李工制定了一份初步的项目成本计划。李工估计出了每项工作的工期及所需要的工作量，如表4-4所示。此外，表4-4也给出了每项工作除人力资源费用外的其他固定费用(如硬件设备和网络设备等)。
【问题1】(6分)请计算表4-4中每项工作所需安排的人力资源数量(按每天8小时工作制计算)。
【问题2】(6分)假设每种人力资源的小时成本如下：测试员30元/小时，程序员40元/小时，软件设计师60元/小时，系统分析师100元/小时。请计算每项工作所需的总费用(每周按照5个工作日计算)。
【问题3】(6分)计算每项工作每周的平均费用(每周按照5个工作日计算)。
【问题4】(7分)假设该项目计划的甘特图如图4-1所示，请绘制该项目的费用预算曲线图(时间单位为周，每周按照5个工作日计算)。4.4.2案例分析
甘特图(Gantt chart)是在20世纪初由亨利·甘特开发的。它基本上是一种线条图，横轴表示时间，纵轴表示要安排的活动，线条表示在整个期间上计划的和实际的活动完成情况。甘特图直观地表明任务计划在什么时候进行，以及实际进展与计划要求的对比。图4-2是一个手工绘制的图书出版项目甘特图。
一般的项目管理软件如Primavera公司的p3和Microsoft公司的Project等都提供甘特图自动生成工具。
时间以月为单位表示在图的下方，主要活动从上到下列在图的左边。计划需要确定书的出版包括哪些
活动，这些活动的顺序，以及每项活动持续的时间。时间框里的线条表示计划的活动顺序，空白的现况表示活动的实际进度。甘特图作为一种控制工具，帮助管理者发现实际进度偏离计划的情况。在本案例中，除了打印长条校样以外，其他活动都是按计划完成的。在费用预算方面，如按时间坐标来分析，有两种表现方式：一是费用预算曲线图，二是费用预算累计曲线图。图4-3和图4-4为Project 2000绘制的费用预算曲线图和费用预算累计成本曲线图。
人力资源数=工作量÷8÷工期，如方案设计阶段系统分析师人数=160÷8÷10=2,其他阶段计算类似；
总费用=固定费＋工作量×成本，如详细设计阶段总费用=6 400+160×60=16000, 其他阶段总费用计算类似。各阶段总费用累加得到项目总费用为493000.平均每周费用＝总费用÷(工期÷5),如主界面设计阶段平均每周费用=73000÷(50÷5)=7300。4.2.3参考答案
【问题1】(6分)【问题2】(6分)【问题3】(6分)参考答案见表4-5。
【问题4】(7分)根据图4-1和表4-5计算每周费用总和,如图4-5所示。
4.3 案例三：挣值管理
阅读以下关于信息系统项目管理过程中挣值管理和项目成本管理方面问题的叙述，回答问题1-问题4。4.3.1案例场景
财政基本建设管理信息系统是一套能够为财政服务，提供财政基本建设资金管理，财务监督、审核，为财政的基建科、预算科和国库科等相关部门提供数据互享的工程项目管理的应用系统。系统充分地体现财政部门对基本建设项目的管理，对国家预算安排的基本建设资金的使用的管理，反映财政部门对基本建设项目的管理，更好地实现财政的管理监督的职能作用。
张工是大型电子政务系统集成商希赛信息技术有限公司(CSAI)的项目经理，目前正作为项目经理负责CSAI与某地财政局开发的基本建设管理信息系统项目，项目组成员包括项目经理1人、系统分析师1人、高级程序员3人、程序员3人、软件界面美工1人、测试人员2人、客户方技术人员2人。由于财政等因素，项目的计划工期为40周，预算成本为50万元。根据该项目的需求和进度等要求，项目具有工期紧、技术要求高、业务复杂等特点。为顺利实现项目进度和质量等目标，CSAI项目管理部门和高层领导对该项目格外重视，要求项目组每周汇报进度状态。
在项目的实施过程中，第19周时张工向公司经理报告项目的进展状态，在状态报告中经理列出了第18周(包含第18周)的项目状态数据，详细情况如下：(1)截至项目状态日期，项目实际已完成的工作量为50%.(2)截至项目状态日期，项目已完成工作量的实际成本(AC)为28万元。
(3)截至项目状态日期，项目的计划成本(PV)为26万元。
【问题1】(6分)试确定项目截止到项目状态日期已完成工作量的挣值EV。
【问题2】(6分)预测项目结束时的总成本EAC。
【问题3】(6分)请对该项目在费用控制方面的执行状况进行分析。
【问题4】(7分)项目经理在检查经费超支时发现，有一项任务F还没有开始实施，但为F任务购买设备的支票已经支付，其费用为4万元。另外，还有一张已经支付的支票，其费用为3万元，是作为整个H任务的硬件费用，但H任务在状态日期完成的工作量为40%.根据这一信息再预测项目结束时的总成本。4.3.2案例分析
挣值管理(Earned Value Management)，是一种综合了范围、进度计划、资源和项目绩效度量的方法，它通过对计划完成的工作、实际挣得的收益、实际花费的成本进行比较，以确定成本与进度是否按计划进行，提供分析、决策依据，从而选取不同的应对措施，以保证最终完成项目目标。
根据图4-6在测量时间点上，有必要先了解14个重要的概念，如表4-6所示。(1)应完成多大工作量？
计划成本PV(Planned Value)，也称为计划工作的预算成本(BCWS)。在图4-6中，PV＝1000元。(2)“已完成”工作的成本是多少？
实际成本AC(Actual Cost)，也称为已完成工作的实际成本(ACWP)。在图4-6中，AC＝1100元。(3)已完成多大工作量？
挣值EV(Earned Value)，也称为已完成工作的预算成本(BCWP)。对EV的解释：有一项任务预定在测量时间点上完工，其计划成本为1000元。但只完成这项任务的95%0这样，就完成了950元的工作量，这就是挣值(EV)。(4)成本偏差CV(Cost Variance)： CV＝EV-AC CV是项目任务的挣值与实际成本之间的差异，已完成了950元的工作量(EV)，但为完成这一工作实际花费了1100元(AC)。完成这项工作比原先预想的多花了150元(CV)。(5)进度偏差SV(Schedule Variance)SV＝EV-PV SV是项目或项目任务的挣值与预算值之间的差异。对于一项工作，原先预计到测量时间点为止会完成1000元的工作量(PV)。而实际上完成了950元的工作量(EV)。这样，就比原计划少完成了50元的工作量(SV)。
(6)成本绩效指数CPI(Cost Performance Index)： CPI＝EV÷AC CPI是总挣值除以总成本。仍以图4一6为例，已完成了950元的工作量(EV)，而为完成这项工作花了1100元(AC)。实际花一元完成了0.864元的工作量(成本与绩效之比)。(7)进度绩效指数SPI(Schedule Performance Index)： SPI＝EV÷PV SPI是总挣值除以总预算成本。在图4-6中，已完成了950元的工作量(EV,)，而计划工作的价值是1000元(PV)。这样，计划完成一元工作量，实际完成了0.95元的工作量(进度绩效之比)。(8)全部工作假定价值，即完工预算BAC(Budget At Completion)或称“总预算”。BAC=完成时的预算-项目预计总成本的基线
在图4-6中，BAC＝2000元。
(9)尚未完工部分的估算ETC(Estimate To Completion)价值，即从开始到完成项目将还需要花费多少成本。ETC＝EAC-AC 在图4-6中，ETC为：ETC＝2315-1100＝1215(元)(l0)完工估算EAC(Estimate At Completion),反映了根据项目的进展总成本是多少，如表4-6所示。
最常用的两个公式是EAC=BAC÷CPI和EAC=AC+ETC。在计算过程中，优先使用第一个公式，如果有明确的理由说明第一个公式不可用，则采用第二个公式。在图4-6中，EAC＝2000÷0.864＝2315(元)(11)完工偏差VAC(Variance At Completion)，即全部工作预算价值(BAC)与全部工作概算价值(EAC)之差。VAC＝BAC-EAC 正值是项目组追求的目标，表明成本比预计情况要好。
在图4-6中，有： VAC＝2000-2315＝-315(元)(12)绩效指数TCPI(To Complete Performance Index)： TCPI＝(BAC-EV)÷(BAC-AC)在图4-6中，有：TCPI＝(2000-950)÷(2000-1100)＝1.7 从这一点出发，必须取得效益，即每花费一元要完成1.17元的价值，以便用预计剩下的资金完成余下的工作。
(13)任务完成百分比PC(Percent Complete)，即已完成的工作占总工作量的比例。PC＝EV ÷BAC 在图4-6中，有：PC＝950 ÷2000＝47.5％
(14)成本消耗百分比PS(Percent Spent)是指已经消耗的成本占项目总预算的比例。在图4-6中，有： PS＝1100÷2000＝55％
所有的价值，无论是计划的还是实际的，都用货币值表示偏差。这会使大家认为挣值与货币有关，但它反映的是项目绩效(Project Performance).因此，挣值是沟通管理的一个重要工具，也是项目绩效度量的一个非常有帮助的工具。
进度偏差和成本偏差对项目的影响如表4-7所示。4.3.3参考答案
【问题1】(6分)截至项目状态日期已经完成工作量的预算成本，即挣值EV：EV=50×50%=25万元。
【问题2】(6分)项目结束时的总成本：EAC=28÷50%=56万元。【问题3】(6分)由于AC>PV>EV,说明项目实际费用支出超前，与实际完成工作量相比费用超支，项目实际完成工作量与计划工作量相比出现拖期。
【问题4】(7分)重新预计的项目完工总成本：EAC=(28-4-3×(1-40%))÷50%=44.4万元。
4.4 案例四：成本控制
阅读以下关于信息系统项目管理过程中成本控制方面问题的叙述，回答问题1一问题3。4.4.1案例场景
某A单位的电力信息应用系统(简称A系统)，系统建设总投资是1100万元，其中主机采购、存储系统采购、网络设备采购、配件采购等花费500万元，应用软件开发600万元。2005年4月工程双方签订项目开发合同，由B公司负责承建。项目总工期为25周，计划从2005年5月1甲启动至2005年10月22日全部完工。
B公司是一家民营高科技信息系统集成企业，有高级工程师2人，软件、硬件、网络工程师共36人。B公司安排高工李工负责A系统的建设工作。B公司的绩效考核制度是非常严格的，对项目负责人的考核，项目开工前要制订项目实施计划，项目完工后要对项目计划的执行情况进行考核，项目的进度、质量、成本三大目标都要求控制在计划的范围内。
李工于项目正式启动之前两周开始进行项目建设的准备工作，对工程项目进行了工作分解，在工作分解的基础上，编制了项目资源计划、人员计划、项目质量保障计划、进度计划、项目成本预算和成本控制计划等。李工编制完项目资源计划后，报告公司审批，包括项目小组组建的计划在内的项目资源计划顺利地通过了公司审批。于2005年5月1日项目正式启动时，项目小组也组建完成。李工所组建的项目小组为12人，包括软件设计、编码工程师8人，软件测试工程师4人。
由于软件项目开发的主要成本为人力资源成本，为此，李工制定了详细的人力资源成本控制计划，人力资源计划成本=12人×25周×平均人周成本(1500元)=450 000元。为了将软件开发人力资源费用控制在45万元内，李工制定了详细的工程成本管理计划。
李工所进行的项目工作分解，得到共24个系统功能模块，分别编号为M01、M02、„„、M24，并分别为每个功能模块制定了工期和成本预算。如表4-8所示。
在项目开发的过程中，李工随时跟踪统计项目的开支情况。李工要求每位软件工程师每周报告一次工作进度，如某某模块完成工作量30％，李工据此来估算项目的进度和成本绩效。如表4-9所示。李工根据表4-9的统计数据计算累积完工的工程价值，计算公式为： 累积完工工程价值＝模块单价i完成率i。
i124 【问题1】(6分)请以200字左右回答，李工的成本预算存在哪些问题？李工所采取的成本跟踪管理的方法是什么方法？应用软件系统开发项目中，使用此方法应注意什么特点？
【问题2】(10分)请以200字左右回答，衡量软件开发实际累积人力资源成本的计算公式是什么？怎样改进上述方法才能控制好人力资源成本？怎样得到软件企业实际消耗的人力资源成本？
【问题3】(9分)请以300字内回答，李工采用此方法的具体措施是否存在不足之处？如存在，请指出不足并说明理由，及你的改进意见。4.4.2案例分析
【问题1】
挣值管理方法是应用非常广泛的项目成本管理方法。但是，IT应用系统开发工程项目有其特殊的特点，挣值管理方法的应用必须结合IT工程项目的特点进行，才能够收到理想的效果。另外，IT应用系统工程项目的成本预算也是比较困难的课题，我们往往很难像其他工程项目(如建筑工程项目)那样，将IT应用系统工程项目的成本预算做得准确。
在过去的应用软件工程项目中，很少采用挣值管理来控制项目进度款支付。但随着IT项目管理水平的提高，随着我国IT工程监理制度的推广，将来采用挣值管理控制工程进度款支付也是可期待的。项目经理应当熟练掌握挣值管理方法。
软件项目的合同价格不等于软件项目开发的实际成本，合同价格除了承建单位的软件开发成本外，还包括销售成本、行政费用、税金、利润等，但我们在这里探讨的主要是项目开发成本，即工程成本。
在李工的成本估算中，缺少了对工程量的估算，因此，对人力资源成本的估算也就缺少了依据。对工作量的估算，如M0l模块需要16“人周”，M02模块需要6“人周”，或以“人月”、“人年”为单位来估算工作量，各模块的工作量合起来，就可得到整个项目的工作量。当然，如果要把预算做得更准确，还需要估算各模块的代码量，以历史经验得到每个成员的工作效率来计算各模块所需的工作量，但这种做法目前在我国还没有多少成功的案例，很多IT公司均是靠经验来进行估算的。
【问题2】
对于大多数应用软件开发项目来说，工程成本的主要构成要素是人力资源使用成本。而为了合理有效地控制人力资源使用成本，在组建项目小组的时候，可以根据工程项目的进度情况，分阶段投入人力资源，要做好与其他工程项目协调使用人力资源。我们也可用人力资源成本来计算挣值，人力资源使用成本的实际值可向财务查询所支付的成本，挣值可以这样计算：
累积人力资源成本(挣值)=平均人力周成本
这种计算是在承建单位内部的成本控制。
本题的主要考点在于怎样在软件开发项目中合理、有效地进行挣值管理。要合理使用挣值管理方法，必须同时考虑
i124模块工作量i×完成率i×到软件工程项目的特点。软件工程项目与建筑工程项目有很大的区别。软件工程项目更加类似于科研项目。如表4-10所示。
在建筑工程项目中，工程进度与成本之间的线性比例关系较好，而且进度容易测量。因此，挣值管理方法也使用得比较好。
但在软件工程项目中，要合理、合适地采用挣值分析方法是比较困难的。软件工程项目的成本控制的困难有以下原因。
(1)需求的不确定性：软件项目的范围、需求难以准确地定义，导致项目开发过程中存在大量的变更，从而影响进度和成本。
(2)规模和工作量的不确定性：软件项目的工作量预算难以估计准确。
(3)质量鉴定的不确定性：开发完成并投入运行的软件模块的质量难以鉴定，特别如某个模块完成了30％或80％的工作量，我们无法去鉴定，或用于鉴定的成本可能很高而使开发单位难以接受或不愿意去做这样的鉴定。
(4)把握需求的不确定性：已经编写完成的软件代码，可能隐藏着对需求理解的严重偏差，可能是废品，得全部返工。
(5)难易程度的不确定性：已经编写完成的软件代码可能是很简单的，未完成的可能很难，或反之。(6)人员的不确定性：如果编写软件代码的人员不稳定，熟练员工中途流失将给项目进度、质量管理带来严重影响。新人中途接手未全面完成的、风格不良的软件代码，是一件很困难的工作。员工的敬业精神也难以衡量。
由于以上这些因素的影响，使得在软件工程项目中对工程进度和工程质量的测量变得很困难，因而，我们就不可能像在建筑项目中那样使用挣值管理方法了。
【问题3】
在软件项目的开发管理中采用挣值分析时，可以考察各模块的完成状态，全部完成并且集成测试成功，能够投入初步运行，这样，可以算本模块的工作量完成，可以获得本模块的全部挣值，否则，本模块的挣值计0。考虑到工程整体的集成还需要一定成本，因此，在计算各模块挣值时，还应当扣除一定比例的挣值，作为工程整体集成的工作量的挣值。
但我们在实际工作中，也有很多时候采用估算某模块完成百分之几的做法，但这种做法是粗放式的，项目管理人员可以将这信息作为对项目成本累积的参考，作为粗略估计项目进度的参考，但不是成本核算的依据，也不能作为申请工程进度款支付的依据，需知这种信息的可信度和可控性均较差。4.4.3参考答案
【问题1】(6分)应当先估算各模块的工程量，再以工程量来估算所需的人力资源，如总工程量“**人周”或“**人月”或“**人年”等。李工的项目小组的建设应分阶段进行人力资源投入,如设计阶段所用人力应较少,而详细设计完成后，编码阶段进入，则人力投入是高峰期。
人力资源成本的预算也应当核算一定比例的浮动成本。李工所采用的是挣值管理方法。此方法应用到软件工程项目中，应注意软件开发挣值与投入的非线性比例关系特点。
【问题2】(10分)软件开发人力资源成本挣值统计是能够做到比较准确的，衡量软件开发人力资源成本的计算公式： 累积人力资源成本=i124模块工作量i×完成率i×平均人力周成本
李工所采取的方法应增加各模块工程量的估算，就能够进行人力资源成本控制。如表4-11所示。
实际消耗的人力资源成本可通过财务发放的工资统计得到。
【问题3】(9分)李工根据各工程师的进度报告(进度百分比)来计算挣值，在软件开发中是不可行的。
在软件开发中，各模块的进度百分比通常很难测量准确，而各工程师的汇报往往是很粗略的估计，这种估计只能提供给项目经理控制进度时做参考，但不能作为成本核算或申请工程进度款支付的依据。建议李工以各模块全面完工来进行计算，即各模块要么计算0％，要么计算100%完工，但在进行工作分解的时候，分解的深度和各模块的粒度要合适，便于进行控制。
另外，在核算的时候，要扣除一定的比例，如20%～30%作为各模块集成所需要的工程量，待工程全面完工后进行核算。
4．5案例五：投资决策
阅读以下关于信息系统项目管理过程中投资决策方面问题的叙述，回答问题1一问题3。4.5.1案例场景
刘工是某希赛软件研究所(CSAI)新产品开发部的总工程师，负责为公司调研新的产品预研方向，编制项目开发报告。
2005年5-8月，刘工经过近3个月的时间，对××行业的YY业务系统收集了大量资料，并进行了深入分析，向公司提供了一个项目开发计划，项目开发计划的摘要如下：
××行业的YY业务系统现状描述：(略)。
项目开发A方案的技术经济描述：A方案为一期项目包含6个子系统的建设，项目开发周期为2年，第一年初投资600万元，第二年初投资600万元。项目建成后运行周期为4年，每年年末产生的净现金流入量见表4-12。方案A投资收益如表4-12所示。
项目开发B方案的技术经济描述：B方案分两期建设，两个合同。一期包含3个子系统，开发周期为1年，第一年初投资为600万元，项目建成后即投入运行，第一运行末产生的净现金流入量为160万元。第二期项目投资于第一期项目建成后启动，包含3个子系统，开发周期为1年，投资700万元。第二期项目的建设必须有第一期项目的支持，建成后与第一期项目一起运行，每年年末的净现金流入量见表4-13。方案B投资收益如表4-13所示。
以上计算，设资金的贴现率为8%。
A、B两方案的技术经济比较：通过对A, B两方案的技术经济比较分析，B方案的净现值和净现值指数均优于A方案，因此，刘工得到的结论是B方案优于A方案。
【问题1】(6分)请以200字内回答，刘工对A, B两方案的技术经济分析是否全面？请你给出合理的补充。
【问题2】(9分)请以300字内回答，B方案比A方案的投资多100万元，即使折算到第一年年初的净现值，B方案也比A方案多投入92.59万元。为什么B方案还是比A方案的经济性优越呢？为什么A, B方案建设同样多的功能模块，B方案的投资却比A方案多？请列出可能的影响因素。
【问题3】(10分)请以300字左右，对A,，B两方案的技术经济性进行点评。4.5.2案例分析
【问题1】
开发一套信息应用系统，都是要期待信息系统能够为我们带来经济价值，即使是公益性项目也不例外。信息系统给我们带来的经济价值有高有低，好的建设方案应当带来更大的经济价值。为了选择更好的项目建设方案，就需要通过对项目的技术经济分析进行投资决策。在进行投资决策时所用到的财务评价指标，根据是否考虑了资金的时间价值，有静态评价指标和动态评价指标。
静态评价指标对于技术经济数据不完备、不准确的方案进行初选，或者对于全寿命周期比较短的项目来说，是适合的。常用的静态评价指标有：投资利润率、静态投资回收期(Pt),借款偿还期(Pd),利息备付率、偿债备付率等。
充分地考虑资金时间价值的动态评价指标比较适合于方案最后决策前的详细可行性研究阶段，以及对于寿命周期较长的方案进行评价。常用动态评价指标有：净现值(NPV),净现值指数(NPVR),内含报酬率(IIT)、动态投资回收期((Pt)等。
另外，不同的投资方式，投资资金的风险也不一样，如一次性投资资金的风险一般比分期投资资金的风险要大。建设单位建设资金不充足的情况下，一般采用分期投资的可能性更大些。
【问题2】
现在的应用软件系统开发，我们通常采用螺旋模型开发方式，螺旋模型开发方式的优点是初期投资少，系统建设周期短，建设完成后可以迅速投入应用，给我们带来良好的经济价值。而传统的瀑布模型开发方式，由于开发周期长，一次性投资大，投资收益见效迟缓等缺点，往往在市场竞争的初期会处于不利地位。
软件开发模型对比如表4-14所示。
采用螺旋开发模型，我们可以在较短时间内迅速建设一个应用系统，让系统尽快投入生产，产生经济效益。
但我们同时也应看到，采用螺旋模型开发软件系统也是有缺陷的，采用螺旋模型开发软件，由于在系统建设的初期，我们只考虑一小部分系统功能，很多软件架构设计人员容易忽略将来应用软件对架构的变更要求。由于软件架构的制约，早期建设的系统在应用的过程中,在满足新需求方面,常常遇到很多问题,有时甚至不得不考虑完全废弃以前的架构，重新设计新架构的情况,重新设计就必然导致部分工作的重复、返工，增加工作量,增加投资。
从经济价值方面来考虑，螺旋模型当然是首选，因为其建设周期短，见效快。从系统质量方面来考虑，瀑布模型又具有一定的优势。采用螺旋模型开发应用软件，必然在时间上存在多次功能模块的迭代。而目前在IT行业，人员的流动性非常强，熟练员工的流失常常也带走成熟的技术，而新招聘的员工对应用软件系统开发的规范性、统一的软件架构、质量保证计划、公司的可复用资产的理解是会大大打折扣的，因此，新员工所开发的软件功能模块，在对旧软件功能模块进行迭代的时候，就会存在很多问题，时常引起软件系统故障，即系统质量问题。
螺旋模型在对付需求变更方面，往往能取得良好的效果，但是，IT系统集成公司或项目小组又容易陷入另一种误区，即不重视需求分析，不重视对系统开发的全局考虑，这样必然造成需求分析中存在着很多不足，导致频繁的变更，泛滥的变更，影响质量、成本。
也不乏这样的情况出现，由于信息系统工程质量的隐蔽性特点(功能方面也存在很强的隐蔽性)，建设单位在建设信息系统工程项目的时候，由于主管领导换届，前任已经开发完成的功能，但可能应用部门长期没有使用，新领导由于不知情而重新进行项目建设。这也是螺旋模型开发中，项目管理工作做得不够完善所引发的重复投资问题。
而从系统质量方面来考虑，当然是一次规划，一次性开发更好，因为这种开发模式的统筹性工作将比较螺旋模型会做得更好。传统的瀑布模型需要我们花费大量的精力来做需求分析，要求需求分析做得深入、彻底，以减少软件系统的变更。但由于传统瀑布模型的开发周期长，一次性投资大，投资风险也大，建设单位往往很难接受，软件产品开发商也很难接受，这就导致传统的瀑布模型在市场竞争方面输于螺旋模型。
频繁的变更使得系统质量受到影响，也必然使得应用软件系统的成本投入的增加。
我们建设应用软件系统的投资，除了考虑技术经济性、风险等因素外，还应考虑到非合同因素。工程的甲乙双方在签订项目建设合同的时候，一个大合同通常比若干小合同更合算。用个简单的比喻，好比批发与零售的区别。但分散的小合同风险小，大合同风险大。因此，这方面的因素也应当综合权衡。
因此，当我们在进行软件开发方案决策，选择应用系统开发模型的时候，应当全面考虑以上这些问题。
【问题3】
实际上A, B两方案均是可行的方案，但B方案比A方案风险小，且B方案建设周期短，见效快。如果采用B方案，那么，应当注意系统建设的统筹规划。如果采用A方案，也可以实现一次规划，一个合同，分期建设，这样，效益就会更好。4.5.3参考答案
【问题1】(6分)刘工的分析不全面。全面的经济分析还应考虑“成本回收期”、“追加成本净现值”、“追加成本内部收益率”、“内含报酬率”、“敏感性分析”等。还应当增加投资风险分析，本案例方案B的投资风险比方案A的投资风险小。
【问题2】(9分)B方案分两期建设，两期投入建设资金。由于B方案的一期系统建设在一年建设完成后就投入运行，产生了经济效益。因此，通过净现值指数分析，B方案净现值指数高于A方案，B方案的经济性比A方案优越。
B方案分两期投入，项目风险将会得到一定程度的降低。B方案所投入的资金多于A方案，一般有以下原因：
两个分立的合同，在甲乙商务方面将有一定区别，分立合同的单价往往会做得高一点。
．由于分期建设，在应用系统的体系架构方面，可能有一定程度的重复开发。
．由于分期建设，硬件及采购设备方面可能有部分会被淘汰、升级，从而影响采购投资方面的增加。
．由于分期建设，IT项目市场环境、技术、政策等因素的影响，也会导致投资总额差别。
【问题3】(10分)从技术经济性上讲，A、B两方案均是可行的。但B方案更好。B方案比A方案风险小，且B方案建设周期短，见效快。
采用B方案，应注意应用系统开发的统筹规划就更好了，可以采取一次规划，分期建设，在一期工程建设的时候，对=期工程的建设做比较全面的分析，使一期工程在技术上能够较好地支持=期工程。
如果采用A方案，也可以实现部分功能模块提前投入运行，产生经济效益。甲乙双方只签一个合同，在投资不变的情况下，提前实现收益，使收益增加，提高项目的经济效益。
第五篇：软件项目管理报告案例
1．引言
1.1编写目的
该文档首先给出了整个系统的整体网络结构和功能结构的概貌，试图从总体架构上给出整个系统的轮廓，然后又对功能需求、性能需求和其它非功能性需求进行了详细的描述。其中对功能需求的描述采用了UML的用例模型方式，主要描述了每一用例的基本事件流，若有备选事件流则描述，否则则省略。而且还给出了非常直观的用例图。这些文字和图形都为了本文档能详细准确地描述用户的需求，同时也为用户更容易地理解这些需求的描述创造了条件。
1.2项目背景
a.所建议开发软件的名称：学生信息管理系统
b.项目的任务提出者：xxx学校。c.开发者：xxx软件开发公司。d.用户：全体师生。
e.实现软件的单位：软件3071软件开发公司。f.项目使用的软件：Microsoft access2003。g.系统：本软件应使用Microsoft Windows xp。1.3定义
本文档中没有用到专门术语的定义和缩写词的原文。1.4参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等，VISUAL BASIC程序设计——数据库篇，1999 [3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著，管理信息系统开发与应用，电子工业出版社，2003 [5] 软件工程，人民邮电出版社，2002年3月第一版
[6] 康博工作室，张红军，王红等缟著《Visual Basic中文版高级应用与开发指南》，人民邮电出版社，2001年4月第一版
[7] 林立军，程斌，翁迪恩缟著《Visual Basic 数据库开发指南》，西安电子科技大学出版社，2000年2月第一版
[8] 宋伟，吴建国等编著《中文Visual Basic编程基础》，北京，清华大学出版社
2．可行性研究的前提
2.1要求
通过调查,要求系统需要有以下功能:
⑴
要求有良好的人机界面;
⑵
较好的权限管理;
⑶
原始数据修改简单方便,支持多条件修改 ⑷
方便的数据查询，支持多条件查询;⑸
相应的权限下，删除数据方便简单，数据稳定性好；
⑹
数据计算自动完成，尽量减少人工干预;2.2目标 a.人力与设备费用的节省； b.处理速度的提高；
c.控制精度或生产能力的提高；
d.管理信息服务的改进； e.决策系统的改进； f.人员工作效率的提高。2.3条件、假定和限制
a.开发软件运行的最短寿命为一年。b.进行系统方案选择比较的期限：2周。c.经费来源和使用限制：自筹资金。
d.法律和政策方面的限制：本软件公司版权所有，未经作者允许，非法传播、复制，违者追究法律责任，后果自负。e.硬件CPU p3、内存256M.。f.软件：access2003。
g.运行环境：本软件应使用Windows2003、Windows xp操作系统。
h.开发环境：本软件应使用Windows2003、Windows xp开发。i.开发软件投入使用的最迟时间为2013年10月01日。2.4可行性研究方法
由于本系统管理的对象单一,都是在校学生，且每个数据内容具有较强的关联性，涉及的计算过程不是很复杂。因此，比较适合于采用数据库管理。且学校用于学生管理的微机都是PIII以上的机器，在存储量、速度方面都能满足数据库运行的要求。在技术难度方面，由于有指导老师的指导和相关参考文献，特别是网上资料，特别是参考其它程序的功能，因此完全可以实现
3．对现有系统的分析
3.1处理流程和数据流程 班级管理业务流程图： 档案管理业务流程图： 课程管理业务流程图： 成绩管理业务流程图 3.2工作负荷
现有系统所承担的工作只能实现档案管理的简单功能，无法适应目前工作 中处理大量数据的功能。3.3费用支出
开发这个项目总需三个人，4台计算机，一个可容纳6、7个人的办公室，必须有充足的物质做精神动力，每台计算机上必须有所需要的软件，比如：办公软件、数据库软件、截图软件等，必须有3000万元的准备开支。3.4人员
数据库管理人员1名，维护人员1名。
1、3.5设备
四台计算机,一台备用,一个工作室.一台打印机,扫描仪一台。3.6局限性
现有系统主要存在如下不足： 1）信息分散、共享性差 每个人的时间精力是有限的，大量的信息资源分散在不同的收集者手中，难于共享和发挥作用。还有就是用户毕业和离职时需要到不同的地方开办证明。2）信息的及时性、准确性差
数据的采集和处理部分靠人工，效率低、速度慢、滞后严重、反馈不及时，严重影响信息的反馈速度和质量，不能有效地、及时地提供基层决策需要的定量信息和领导决策需要的宏观定性信息。
4．所建议技术可行性分析 4.1对系统的简要描述
建议系统实现注册、查询等具体功能。4.2处理流程和数据流程
4.3与现有系统比较的优越性
系统实现学生教师查询各种信息。4.4采用建议系统可能带来的影响 4.4.1对现有软件的影响
需将计算机升级为CPU P3、内存256M，添加一台打印机。4.4.2对现有软件的影响
需要将Windows升级为2000以上。4.4.3对系统运行的影响
（1）用户的操作严格按照系统要求规程。
（2）要求创建系统管理员与普通用户两种登录方式，分权限管理。
（3）数据应有系统管理员手动输入系统，普通用户无权输入数据。
（4）对数据有保存要求，并且对数据存储，恢复的处理。
（5）输出报告以报表的形式打印出来。
（6）系统具有恢复和备份的功能。4.4.4对开发环境的影响
1、为了建立数据库，要求提供详细的数据资源。
2、为了开发和测验所建议系统而需要的计算机资源：CPU P3、内存256M。
3、如数据涉及保密与安全问题，应由专人负责录入。4.4.5对经费支出的影响
所建议系统的开发、设计经费开支：5000元。维持运行而需要的经费开支：1000元。4.5技术可行性评价
a.在限制条件下，完成功能目标的实现； b.利用现有技术，功能目标一定能达到；
c.对开发人员数量为5个人,每个人应对数据库知识有明确的了解，我们的组员都具有这种能力,一定按期完成工作；
d.在规定的期限内，开发顺利完成。5．所建议系统经济可行性分析 5.1支出
5.1.1基建投资
1、房屋和设施：500元。
2、ADP设备：1000元。
3、数据通讯设备500元。
4、环境保护设备200元。5.1.2经常性支出
1、设备的租金和维护费用：500元。
2、数据的通讯方面的租金和维护费用500元。
3、人员的工资和奖金开支：3000元。
4、其他经常性的开支：2000元。5.2收益/投资比 收益/投资比为3:1.5.3投资回收周期 投资回收周期为半年.5.4敏感性分析
1、应尽量延长系统生存周期，可延长至3年。
2、应是有效数据全部录入系统，使系统工作负荷量达到饱和。
3、应尽量提高系统的处理速度。
4、应提高设备和软件的配置。6．社会因素可行性分析 6.1法律因素
如果发现有侵权行为,必进行严格的处罚,本公司版权所有,未经作者的允许，禁止非法传播、复制，违者追究法律责任，后果自负。6.2用户使用可行性
本系统使用比较简单,适合普通用户操作,只要用户对说明书进行认真阅读,都可了解。7．其他可供选择的方案
方案有许多但本公司选择了这套方案,他具有自己的优越感,运用编制菜单栏来省去代码,这是界面有好起来,又降低了工作难度,进而宏的运用更简化了工作难度。除提供的建议方案的具体功能外，还需增加网络功能，未被推荐的理由是目前尚不具备开发条件，投入与效益不成比例。8.结论意见
结论意见可能是： a.可着手组织开发；
b.需待若干条件（如资金、人力、设备等）具备后才能开发； c.需对开发目标进行某些修改；
d.不能进行或不必进行（如技术不成熟，经济上不合算等）； e.其他。
三 软件项目计划
1.引言
1.1 编写目的
软件项目开发是一项系统而复杂的工作，它需要一个团队互相配合、分工协作。软件项目管理系统可以规范一个软件开发团队的日常工作，提高工作效率。
为了很好的管理整个开发过程，同时预算整个开发过程的费用及时间的安排，给开发人员，管理人员一个参照物，明白自己在每一个阶段所需要完成的任务，协助他们更好地完成开发工作。
预期的读者：开发人员，项目经理，测试人员 1.2 背景
a.学生信息管理系统 b.提出者：项目经理，开发者：XXX开发团队。1.3 定义
[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。] 1.4 参考资料
[1] 周佩德.《数据库原理及应用》.电子工业出版社
[2] 刘炳文等，VISUAL BASIC程序设计——数据库篇，1999 [3] 李光明.《Visual Basic编程实例大制作》.冶金工业出版社
[4] 李红等编著，管理信息系统开发与应用，电子工业出版社，2003 [5] 软件工程，人民邮电出版社，2002年3月第一版
[6] 康博工作室，张红军，王红等缟著《Visual Basic中文版高级应用与开发指南》，人民邮电出版社，2001年4月第一版
[7] 林立军，程斌，翁迪恩缟著《Visual Basic 数据库开发指南》，西安电子科技大学出版社，2000年2月第一版
[8] 宋伟，吴建国等编著《中文Visual Basic编程基础》，北京，清华大学出版社 2.项目概述 2.1 工作内容 需求分析： 1~3个月 2 概要设计： 2~3个月 3 详细设计： 2~3个月 4 编码: 2~3个月 5 测试： 1个月 发布： 1个月 2.2 主要参加人员 参与者 个人情况
XX 软件工程专业学生，熟悉java语言，数据库编程 XX 软件工程专业学生，熟悉C#语言 XX 软件工程专业学生，有很好的网页设计能力
XX 软件工程专业学生，有良好的界面设计的能力和测试经验 XX 专业为软件工程，从事开发工作一年，能过独立地完成小型项目的整个开发过程
2.3 产品 2.3.1 程序
名称 编程语言 媒体形式 功能及能力
系统功能 C#+SQL Server 2000 文本 管理学生的学籍信息，统计学生的相关信息。学生信息的增加、修改、删除、查询 数据信息管理 C#+SQL Server 2000 文本 学生学籍信息管理，学生选课信息管理
基本业务 C#+SQL Server 2000 文本 学生注册、学籍信息维护，学生选课，老师管理班级信息。
信息浏览与查询 C#+SQL Server 2000 文本
管理员学生学籍信息浏览、查询
数据库 SQL Server 2000 数据库文件 数据库文件可以直接附加到本地的SQL Server 2000中的数据库中
学生学籍管理系统 C#+SQL Server 2000 CD光盘
程序的运行文件，运行之后只要发布之后就可以了 2.3.2.文件
需求说明书，安装指南，用户操作手册，预计可能出现故障及解决办法 2.3.3.服务
培训安装：系统测试完毕之后，2012年10月10日至12日两天的安装和使用的培训时间，主要是让用户适应本系统的运行环境与操作习惯 维护：系统出现故障时，用户可参照手册进行自行解决，如果解决不了，则派维护人员过去，系统的维护期2012年10月14日到2013年10月15日，超过期限将不再派人去维修 2.3.4.非移交的产品
整个系统全部的的代码不必要给用户，所使用的技术及参考的文献也可以自己保留，以及该软件所使用的技术文档，这些都是不用给用户的 3.实施计划
3.1 工作任务的分解与人员分工 1需求分析
负责人： 汪国志 参与人：汪国志 2 概要设计
负责人：汪国志 参与人：汪国志 3 实现
负责人：汪国志
参与人：汪国志，XXX，XXX，XXX，XXX，XXX 4 测试
负责人：汪国志 参与人：汪国志 5 维护及用户培训 负责人：汪国志 参与人：汪国志 3.2 接口人员 负责人：汪国志 参与人：汪国志
职责:统一接口，使不同层之间能通信 3.3 进度 1 需求分析
开始时间：2012-10-01 完成时间：2012-12-30 所需资源：客户的需求
完成标志：完成需求分析说明书 2 设计
开始时间： 2013-01-01 结束时间： 2013-03-01 所需资源： 需求分析说明书 完成标志： 概要设计说明书 3 编码实现
开始时间： 2013-03-01 结束时间： 2013-06-01 所需资源： 概要设计说明书，设配 完成标志： 系统能顺利运行 4 测试
开始时间： 2013-06-01 结束时间： 2013-08-01 所需资源： 能顺利运行的系统 完成标志： 修复现存的bug 5 移交 开始时间： 2013-08-01 结束时间： 2013-10-01 所需资源： beta版系统 6 培训 开始时间： 2013-10-01 3.4 预算
1.采购必要设备的投资： 网络平台的建设，包括了建设方式和联网建筑物数等等方面去计算，这一块需要200万左右；
服务器与存储系统，从发卡量和设备数量等估算，这一块需要100万左右； 射频卡终端，包括读写器与POS机，这一块需要20万左右。2.开发系统的投资：
按目前市场上一卡通管理系统的开发价格来看，开发所需的投大概在50万不等； 4.总计：:350万左右； 3.5 关键问题
本系统的操作过程简单，实现技术要求也不高，所以没有要特别列出的关键问题 4.支持条件 4.1 运行环境
a.开发软件运行的最短寿命为一年。b.进行系统方案选择比较的期限：2周。c.经费来源和使用限制：自筹资金。
d.法律和政策方面的限制：本软件公司版权所有，未经作者允许，非法传播、复制，违者追究法律责任，后果自负。
e.硬件CPU p3、内存256M.。f.软件：access2003。
g.运行环境：本软件应使用Windows2003、Windows xp操作系统。h.开发环境：本软件应使用Windows2003、Windows xp开发。4.2 需由用户承担的工作
数据库的初始化需要用户自己录入，这个应该在测试之前完成，所以编码之前，由开发人员做好数据库，然后由用户安排人录入初始数据库，且必须在2013年6月1日之前完成。4.3 需由外单位提供的条件
本项目希望得到委托商的资金支持，人员支持，如取需求时，能够提供部分食堂为我们的测试的提供支持环境，还有技术支持 5.专题计划要点
专题计划 要点
合同计划
在分析阶段拟定合同书，分析阶段一结束就签订合同，合同包括需求的定义，如出现任何问题，可以根据合同调解，以及费用的支付，在每个阶段结束之后，委托方需支付开发方多少现金
测试计划
包括单元测试，集成测试，系统测试计划，主要参照开发文档，拟定计划，具体到输入的格式，响应的时间，需求的确认
五 进度计划风险列表
1.最常见的进度计划风险
1）功能无限蔓延； 2）质量不定 3）计划过于乐观 4）设计欠佳 5）银弹综合症 6）研发导向开发 7）人员薄弱 8）签约商失败；
10）研发人员与客户的磨擦。2.进度计划风险完整列表
2.1 计划编制风险
1）计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致；
2）计划是优化的，是“最佳状态”； 3）计划忽略了必要的任务；
4）计划基于使用特定的小组成员，而那个小组成员其实指望不上。5）在限定的时间内无法建成已定规模大小的产品； 6）产品规模比估计的要大一些； 7）工作量大于估算数；
8）进度已经拖延的项目在重新评估时过于优化或忽视项目历史； 9）过度的进度压力造成生产率下降；
10）目标日期提前，但没有相应地调整产品范围或可用资源； 11）一个任务的延迟导致相关任务的连锁反应；
12）涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。2.2 组织和管理
1）项目缺乏一个有凝聚力的最高领导人；
2）由于前期乏力，项目长时间被搁置； 3）解雇和削减开支导致项目小组能力下降；
4）仅由管理层或市场人员进行技术决策，导致计划进度延长； 5）低效的项目组结构降低生产率；
6）管理层审查/决策的周期比预期时间长； 7）预算削减打乱项目计划；
8）管理层做出了打击项目组织积极性的决定； 9）非技术的第三方的工作比预期延长（如审批，采购等）； 10）计划性太差，无法适应期望的开发速度；
11）项目计划由于压力而放弃，导致开发混乱、低效；
12）管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。2.3 开发环境
1）设施没有及时到位； 2）设施到位，但不配套； 3）设施拥挤、杂乱或者破损； 4）开发工具未能及时到位；
5）开发工具不如期望那样有效，开发人员需要时间创建工作环境或切换新的工具；
6）开发工具的选择不是基于技术需求，不能提供计划要求的性能； 7）新开发工具的学习期比预期的长，内容繁多。2.4 最终用户
1）最终用户坚持新的需求；
2）最终用户对于最后交付的产品不满意，要求重新设计和重做； 3）最终用户不买进项目产品，无法提供后续支持；
4）最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。
2.5 客户
1）客户坚持新的需求；
2）客户对规划、原型和规格的审核/决策周期比预期长；
3）客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的重复；
4）客户答复的时间比预期长（如回答需求中需澄清的问题）； 5）客户坚持技术决策而导致进度计划延长；
6）客户对开发进度管理过细，导致实际进展变慢；
7）客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作；
8）客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作；
9）客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低；
10）客户不接受交付的软件，尽管它满足了所有的规格； 11）客户期望的开发速度是开发人员无法达到的。2.6 承包商
1）承包商没有按承诺交付组件；
2）承包商递交的组件质量低下无法接收，必须花时间改进质量；
3）承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。
2.7 需求
1）需求已经成为项目基准，但变化还在继续；
2）需求定义欠佳，而进一步的定义会扩展项目范畴； 3）添加额外的需求；
4）产品定义含混的部分比预期需要更多的时间。2.8 产品
1）错误发生率高的模块需要比预期更多的测试、设计和实现工作；
2）校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。
3）在一个或多上新兴领域推广计算机技术使得计划进度的延长不可预 4）由于软件功能的错误，需要重新设计和实现；
5）开发额外不需要的功能（镀金）延长了计划进度；
6）要满足产品规格与速度要求，需比预期更多时间，包括重新设计和实现的时间；
7）严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作；
8）要求与其他系统、复杂系统或不受本项目控制的系统相连，导致无法预料的设计、实现和测试工作。
9）要求在不同操作系统下运行将花费比预期更长的时间；
10）在不熟悉或未经检验的软（硬）件环境中运行产生未预料的问题； 11）开发一种对组织全新的模块将比预期花费更长的时间； 12）依赖正在开发中的技术将延长计划进度。2.9 外部环境
1）产品依赖政府规章，而规章的改变将是不可预期的；
2）产品依赖草拟中的技术标准，而最后的标准将是不可预期的。2.10 人员
1）招聘人员所花时间比预期的长；
2）作为先决条件的任务不能按时完成（如培训、其它项目）； 3）开发人员和管理层之间关系不佳导致决策缓慢，影响全局；
4）项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平；
5）缺乏激励措施，士气低下，降低了生产能力； 6）缺乏必要的规范，增加了工作失误与重复工作；
7）某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言；
8）项目结束前，合同制人员离开团队，或雇员辞职；
9）项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率；
10）项目组成员不能有效地一起工作；
11）由于项目组成员间的冲突，导致沟通不畅、设计欠佳、接口错误和额外的重复工作；
12）有问题的成员没有调离项目组，损害了项目组其他成员的积极性； 13）项目的最佳人选未加入项目组；
14）项目的最佳人选已加入项目组，但因其他原因未能合理使用； 15）没有找到项目急需的具有特定技能的人； 16）关键人物只能兼职参与； 17）项目人员不足；
18）任务的分配与人员技能不匹配； 19）人员工作的进展比预期的慢；
20）项目管理人员怠工导致计划和进度失效；
21）技术人员怠工导致工作遗漏或质量低下，工作需要重做。2.11 设计与实现
1）设计过于简单，无法确定主要事件，并导致重新设计和实现； 2）设计过于复杂，导致一些不必要的工作，影响实现效率； 3）设计质量低下，导致重复设计和实现
4）使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误；
5）产品采用低级语言来实施，导致生产率比预期的低；
6）一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新库或自选开发所要的功能；
7）代码和库质量低下，导致需要额外的测试、错误修正或重做； 8）过高估计了增强型工具对计划进度的节省量；
9）分别开发的模块无法有效集成，需要重新设计或重做。2.12 过程
1）大量的纸面工作导致进程比预期的慢；
2）进程跟踪不准确，导致无法预知项目是否已落后于计划进度； 3）前期的质量保证行为不真实，导致后期的重复工作；
4）质量跟踪不准确，导致无法得知影响进度的质量问题； 5）太不正规，导致沟通不足，质量问题和工作重做； 6）过于正规，导致过多耗时无用的工作；
7）向管理层撰写进度报告占用的开发人员的时间比预期的多； 8）风险管理粗心，导致没有发现重大的项目风险； 9）软件项目风险管理花费的时间比预期的多。
点击咨询 