变更管理的定义范文

导语：如何才能写好一篇变更管理的定义，这就需要搜集整理更多的资料和文献，欢迎阅读由公务员之家整理的十篇范文，供你借鉴。

篇1

关键词：IT企业；项目管理；项目范围管理

中图分类号：F27文献标识码：A

随着信息技术的飞速发展，IT企业作为推动信息技术发展的重要力量，其地位在经济发达国家提到了空前的高度，但经调查研究发现，IT企业项目（以下简称IT项目）的成功率不高、项目实施效果不容乐观。影响IT项目成功因素有很多，但项目范围管理的失控是主要原因之一，在实践中，“需求蔓延”是导致IT项目范围管理失控最常见的因素，IT项目往往在项目启动、计划、执行、甚至收尾时不断加入新功能，从而使项目在时间、资源和质量上都受到严重影响。由此可见项目范围管理的重要性。

一、项目范围管理相关概念

范围的概念包括产品规范和项目范围两方面内容，其中产品规范指产品或服务所包含的特征或功能，项目范围指为了交付具有所指特征和功能的产品必须要做的工作。

项目范围管理是指保证项目范围规定的工作得以顺利完成的所有管理过程。这个过程用于确保项目组和项目干系人对作为项目结果的项目产品以及生产这些产品所用到的过程有一个共同的理解。简而言之，项目范围管理就是：做什么？不做什么？包括什么？不包括什么？

二、项目范围管理的作用分析

在现实的IT项目管理中，可以看到很多范围管理不到位而导致项目失败的例子。现从以下三个方面对项目范围管理的作用进行分析。

1、确定项目范围可提高项目成本、时间和资源估算的准确性。如果项目的具体工作内容不明确，项目的成本、时间和所需资源就不明确，项目完成的不确定因素将大大增加，面临巨大的危机。

2、确定项目范围有助于清楚地分派责任。在明确项目包括那些具体的内容、具体有哪些要求、完成的产品应达到什么要求等内容后，就为清楚地分派任务提供了必要的保障。

3、项目范围、时间、成本三个约束条件是相互影响、相互制约的。时间、成本和范围构成一个稳固的三角形，如图1所示。（图1）

大多数项目都会有明确的完成日期、成本和范围的限制。时间、成本和范围三个要素被称为项目成功的三大要素。

在三角形中，任何一边都不可能孤立地改变，如果项目范围扩大，必然导致项目成本增加和项目工期的延长。不成比例的变化与孤立的改变某一边是一样的，都将破坏三角形的结构，最终招致项目失败。因此，有效的范围管理更像一门艺术，可以帮助项目经理在已经确定的时间和成本下完成项目目标。

三、影响项目范围管理的常见因素分析

影响项目范围管理的因素很多，经分析有以下几种：

1、IT企业没有完善的项目管理体系来指导项目管理工作。此种情况下，项目的成败完全依靠项目经理个人的管理、领导能力，大部分项目都是以失败而告终，因此建立健全项目管理体系是至关重要的。

2、项目范围的定义不够明确，不能量化，可验证程度低。很多时候都是一些定性的要求，例如“用户界面友好，可操作性强，便于使用及维护”等，类似这些模糊的界定往往是导致后续项目扯皮的根源。对项目范围的明确定义，有经验的项目经理及系统分析人员将起到关键性的作用。

3、客户本身原因造成项目范围管理上的困难。主要包括两方面原因：一是客户本身无法确定清晰的范围定义；二是客户有意拖延明确的范围定义。

针对第一种原因，要向客户方介绍或带领其参观已经完成的项目，消除对方的疑虑，清晰对方的思维。针对第二种原因，如果处理不好，不但无法做好范围管理，还会影响双方的合作关系，影响到可能存在的后续业务。此时，项目经理要组织人员做好攻关，软硬兼施，让客户方负责人真心投入，提高对方领导的重视程度，加深项目干系人对各阶段性工作的印象，扩大范围定义在客户方单位的认知度和影响面。

4、合同方面的原因造成项目范围难以管理。在合同签订前销售人员为了能够尽快签单，往往对客户会有一些不切实际的承诺，在客户的印象中项目产品已经是无所不包了，使得客户产生很多不切实际的期望。另外，国内IT企业签订的合同一般都比较简单，很少对项目范围有明确规定，造成项目的范围存在很大的不确定性，留下了很大的隐藏风险。合同签订后项目小组和客户要有一个渐进的项目范围交互、降低期望的过程，否则容易出现观点冲突，对项目的推进造成影响。

四、如何做好项目范围管理

要做好项目范围管理工作必须先了解项目范围管理的一些科学过程，然后认真按照这些科学过程进行项目的范围管理。依据美国项目管理协会（PMI）项目管理知识体系指南（PMBOK）中给出的严格定义，其中包括启动、范围计划、范围定义、范围核实、范围变更控制等内容。

1、项目启动过程。项目启动是正式承认一个新项目的存在或一个已有项目进入下一个阶段的过程。该过程有一个重要的输出文档是项目章程，项目章程粗略地规定项目的范围，这也是项目范围管理后续工作的重要依据。项目章程规定项目经理的权利以及项目组中各成员的职责，还有项目其他干系人的职责，这也是在以后的项目范围管理工作中各个角色如何做好本职工作有一个明确规定，保证后续工作可以更加有序地进行。项目一般是由市场需要、经营需要、客户需要、技术进步、法律要求等一个或多个需要而启动的。

2、项目范围计划过程。范围计划的核心工作是编写正式的项目范围说明书和范围管理计划。范围计划编制是将产生项目产品的所需进行的项目范围渐进明细和归档的过程。做范围计划编制工作需要参考很多信息，通常它对项目范围已经有粗线条的约定，范围计划在此基础上进一步深入和细化。范围说明书在项目干系人之间确认或建立了一个项目范围的共识、作为未来项目决策的文档基准。在进行项目范围规划时，必须慎重考虑与权衡工具、数据来源、方法、过程与程序，以及其他因素，确保为项目而付出的努力与项目的大小、复杂程度和重要性相称。

3、项目范围定义过程。范围定义指的是把项目产出物进一步分解为更小的、更便于管理的许多组成部分。一个好的范围定义可以提高对项目成本、项目工期和项目资源需求估算的准确性；为项目的绩效度量和控制确定一个基准；便于明确和分配项目任务与责任。在这个过程中，项目组要建立一个工作分解结构（WBS）。WBS的建立对项目的意义非常重大，它使得原来看起来非常笼统、模糊的项目目标一下子清晰起来，使得项目管理有依据，项目团队的工作目标清楚明了。如果没有一个完善的WBS或者范围定义不明确时，变更就不可避免地出现，很可能造成返工、延长工期、降低团队士气等一系列不利后果。

4、项目范围核实过程。范围核实是通过参与者的行为正式确定项目范围的过程。它要求回顾生产过程和生产成果，以保证所有项目都能准确、满意地完成。这个过程是范围确定之后，执行实施之前各方相关人员的承诺问题。一旦承诺表明你已经接受该事实，那么你就必须根据你的承诺去实现它。

5、项目范围变更控制过程。范围变更控制是指对有关项目范围的变更实施控制。主要的过程输出是范围变更、纠正行为与教训总结。再好的计划也不可能做到一成不变，关键是对变更进行有效控制。

客户在项目开始之前不能明确所有的需求，随着业务的发展、客户认识的提高，客户的需求也在发生变化，客户提出变更是不可避免的。变更并不可怕，可怕的是随意的、没有控制的变更。为了使变更有序，需要与客户一起，建立变更控制委员会（CCB），制定严格的变更制度、变更流程，将一切非必要、非紧急、不合理、非高层领导意图的“无效变更”屏蔽掉，同时采用变更申请表格和配置管理工具有效地管理变更。

五、总结

影响IT项目最后成功的因素是多方面的，包括项目管理的九大知识领域。有效的IT项目范围管理对项目的成功运作具有重要的意义，范围管理的成功与否直接影响到对项目进度、质量、成本的有效掌控以及对项目风险的控制。

（作者单位：1.合肥工业大学管理学院；2.宣城市委党校）

参考文献：

篇2

关键词：软件需求；开发方法；管理方法；评价

中图分类号：TP311文献标识码：A 文章编号：1009-3044(2008)27-1960-02

The Research and Application on Software Requirements Management in Development of Software Project

JING Shen-yan

(Department of Information Technology Liaoning University of International Business and Economics, Dalian 116052, China)

Abstract: The software requirements is very important in the the entire life cycle of software products, and that has decisive significance for the follow-up of software development and maintenance. In practice, the requirements management can not get sufficient attention. This paper demand from software requirements and software engineering, and analyze the internal and external issues in the management of software requirement, and focus on the effective ways in the development and management of the requirements, and put forward some simple and feasible standards for the analysis and evaluation of software requirements.

Key words: software requirements; development method; management method; evaluation

1 引言

软件需求在软件产品的整个生命周期中占有十分重要的位置。我们应该看到，它是软件项目的依据和出发点，无论是软件的开发还是软件的维护都是以软件需求作为前提的。如果将软件需求比做是一座建筑物的地基，一点都不夸张。因此，重视需求工作，重视软件需求的质量，可以为后续的工作打下良好基础，否则可能会给开发的成本、周期以及产品的质量带来严重的影响，造成不良的后果。据调查显示，在众多失败的软件项目中，需求管理失误原因约占到45%。

在项目开发工作中，很多人对需求的认识还远远不够，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。

2 什么是软件需求和需求工程

2.1 软件需求的定义

按照IEEE-STD-610标准的定义，软件需求是用户为解决某个问题或是为实现某个目标，要求软件必须满足的能力。软件需求可能由分配给软件的需求得到，也可能由用户或最终用户提出。软件需求主要分为3个层次，如图1所示。

1) 业务需求：指客户对软件的高层次目标要求。

2) 用户需求：指用户使用软件必须达到的要求和完成的任务。

3) 功能和非功能需求：规定了开发人员必须实现的需求，它的实现满足上述业务需求和用户需求。通常以需求规格说明书的形式体现。

4) 非功能性需求包括过程需求和外部需求。过程需求包括交付需求、实现需求、遵循的标准，外部需求包括安全性、性能、机密性、互操作性等。

2.2 需求工程的定义

需求工程是系统工程或软件工程中解决需求问题的一个崭新领域。其目标在于使工程得到的产品能够准确、真实的体现客户的需求，令客户满意。需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。

需求开发是指从信息收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：获取需求、分析需求、定义需求和验证需求。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法。它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。

3 需求开发过程中存在的问题

需求开发过程中存在的任何问题，最终导致的结果都是需求变更。为了顺利的提供高质量的软件产品，按照开发人员的观点，软件需求应该是清晰、正确、稳定的。所谓稳定是指：希望用户一次提供所有需求，并且以后不再改变，但这往往是不现实的。用户在开发过程中变更先期确定的需求的现象非常普遍，也就是说需求变更是不可完全避免的。从开发人员的角度来看，可以把需求变更的原因分为两类：

3.1 内部原因

由于开发人员需求开发工作的缺陷使得需求发生了变更，主要有两种情况：

1) 需求分析、定义、评审工作不够充分，使得需求规格说明书中隐含着问题，到下一阶段才发现。例如：为了赶工期忽视了需求的质量、需求开发的方法不当。

2) 需求开发过程中，与客用户的沟通不充分或开发人员的经验缺乏，没有挖掘出用户的潜在需求。

3.2 外部原因

外部原因是指开发人员外部的原因引起的需求变更，主要是用户的原因。

1) 随着用户对需求的理解逐渐深入，可能会有新的想法，所以会要求改变原来的需求。

2) 业务变化导致软件需求发生变化。计算机运行环境发生变化，导致需求发生变更。如计算机硬件、系统软件等发生了变化。

3) 相关制度、法律法规发生了变化导致需求变更。

无论何种原因引起的需求变更，开发人员都要积极面对。因为需求绝对不变更是不可能的。好的需求开发方法和管理的方法会对降低需求变更对系统开发产生的影响。

4 需求开发与管理的一些方法

需求开发是一项复杂的工作，使用的方法也很多，不同的开发方式有不同的方法，这里简单介绍一些相关的方法。

4.1 需求开发方法

需求开发有很多最佳实践以及好的方式方法，下面根据实践经验介绍几种有效的方法。

1) RUP与UML的结合

RUP（Rational Unified Process）：Rational公司推出的一种软件考法过程框架，UML（Unified Modeling Language）：统一建模语言。业界已经证实，RUP与UML的结合是一种最佳实践。因为RUP过程框架，能够有效的指导我们，有条不紊的进行需求开发工作。同时UML又能直观、形象的表达出我们想要表达的意思。图形化的需求建模会让开发人员和用户对需求的理解保持一致。这对于需求质量的提高会有很大的帮助。

2) 绘制关联图

绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。

3) 可行性分析

在允许的成本、性能要求下，分析每项需求实施的可行性，提出需求实现相关风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

4) 需求优先级

确定功能实现的优先级。根据优先级来确定每个产品版本要实现的需求。

5) 系统原型法

原型法是一个非常有用的获取需求的方法，不论系统规模的大小，都非常适用。有时用户用语言难以表达出他们的意思，所以通过真实的应用界面会更好的引导用户提出他们的潜在需求。

6) 图形分析模型

绘制图形分析模型是编制软件需求规格说明重要手段。它们能帮助分析人员理清数据、业务模式、工作流程以及他们之间的关系，找出遗漏、冗余和不一致的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

7) 数据字典

数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员和用户使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项，确保客户与开发小组是使用一致的定义和术语。

4.2 需求管理方法

需求管理主要是对需求变更、需求状态的管理。主要包括以下几个方面：

1) 确定需求变更控制过程。

制定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此过程。

2) 进行需求变更影响分析。

评估每项需求变更，以确定它对项目计划安排和其它需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于需求变更控制部门做出更好的决策。

3) 建立需求基准版本和需求控制版本文档。

确定需求基准，这是项目各方对需求达成一致认识时刻的一个快照，之后的需求变更遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。

4) 维护需求变更的历史记录。

将需求变更情况写成文档，记录变更日期、原因、负责人、版本号等内容，及时通知到项目开发所涉及的人员。为了尽量减少困惑、冲突、误传，应指定专人来负责更新需求。

5) 跟踪每项需求的状态。

可以把每一项需求的状态属性（如已推荐的，已通过的，已实施的，或已验证的）保存在数据库中，这样可以在任何时候得到每个状态类的需求数量。

6) 衡量需求稳定性。可以定期把需求数量和需求变更（添加、修改、删除）数量进行比较。过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚。

5 需求分析评价标准

如何判断需求规格说明的好坏，不同的软件工程规范都有自己的一套标准，这里向大家介绍一个比较常见的NASA SEL推荐方法，它是由美国国家航空和航天局软件工程实验室开发的五大常用国际软件工程规范之一，它对软件需求过程的评价标准是：清晰、完整、一致、可测试。

1) 清晰：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性，所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。需求分析中的描述一定要简单，千万不要采用疑问句、修饰这些复杂的表达方式。 除了语言的二义性之外，注意不要使用行话，就是计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。

2) 完整：需求的完整性是非常重要的，如果有遗漏需求，则不得不返工，在软件开发过程中，最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是，需求的遗漏是常发生的事情，这不仅仅是开发人员的问题，更多发生在用户那里。要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各个方面，贯穿整个过程，从最初的需求计划制定到最后的需求评审。

3) 一致：一致性是指用户需求必须和业务需求一致，功能需求必须和用户需求一致。在需求过程中，开发人员需要把一致性关系进行细化，比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。

4) 可测试：一个项目的测试从什么时候开始呢？有人说是从编码完成后开始，有人说是编码的时候同时进行单元测试，编码完成后进行系统测试，这些结论都不完全正确。实际上，测试是从需求分析过程就开始了，因为需求是测试计划的输入和参照。这就要求需求分析是可测试的，只有系统的所有需求都是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。

6 结束语

需求管理是软件开发的整个生命周期中最基础、最关键的部分，随着软件开发研究与实践水平的推进，需求开发也越来越受到企业与开发管理人员的重视。本文提出的需求技术与需求管理方法意在让更多的人能够充分意识到需求管理的决定性作用，能够在长期的实践中对需求技术与需求管理方法进行不懈的探索与研究，推进软件开发水平与开发能力的飞跃和提高。

参考文献：

[1] 李明.需求管理中数据和信息的关系及应用[J].UML软件工程组织技术期刊,2008,(4).

[2] 毛明志,沈贤义,黄春贤.基于特性的软件需求管理工具的研究与应用[J].计算机技术与发展,2007(5).

篇3

【论文摘要】盈余管理就是企业当局在遵循会计准则的基础上,通过对企业对外报告的会计收益信息进行调整或控制,以达到主体自身利益最大化的行为。上市公司通过会计估计的变更以达到粉饰财务报表并进行盈余管理的目的,这种现象在中国资本市场屡见不鲜。本文对此进行实例分析,提出政策建议,以杜绝管理层利用会计估计变更进行盈余管理。

盈余管理是目前国外经济学和会计学广泛研究的课题。对盈余管理的概念,会计学界存在着诸多不同意见,从以下两个权威性的定义可以看出盈余管理的基本涵义。

一是美国会计学家斯考特(William·K·Scott)认为,盈余管理是指“在GAAP‘GENERALLYACCEPTEDACCOUNTINGPRINCIPLES’的缩写,翻译为公认的会计准则)允许的范围内,通过对会计政策的选择,使经营者自身利益或企业市场价值达到最大化的行为”。二是美国会计学家凯瑟琳·雪珀(KathehneSchipPer)认为,盈余管理实际上是企业管理人员通过有目的地控制对外财务报告过程,以获取某些私人利益的“披露管理”。

根据以上两个权威性的定义可以看出,盈余管理主要具备这样一些涵义:第一,盈余管理的主体是企业管理当局,它包括董事会和经理成员。尽管董事会和经理成员进行盈余管理的动机并不完全一致,但他们对企业会计政策和对外报告盈余都有重大影响,企业盈余信息的披露由他们各自作用的合力所决定。第二,盈余管理的客体是企业对外报告的盈余信息(即会计收益)。在雪珀的定义中,盈余管理不仅仅指对会计收益的调整和控制,而且包括对其他会计信息的披露的管理,但是对会计收益以外的财务数据的操纵并不具有普遍的意义,它所具有的经济后果相对而言要小得多。如果将其纳入盈余管理的范畴,反而会影响对盈余管理本质的把握。第三,盈余管理的方法是在GAAP允许的范围内,综合运用会计和非会计手段来实现对会计收益的控制和调整,它主要包括会计政策、会计估计的变更,收入的确认,交易时间的改变,合并范围的变化等。第四,盈余管理的目的是盈余管理主体自身利益的最大化。其中又包括管理人员自身利益的最大化和董事会成员所代表的股东利益的最大化。综上所述,盈余管理就是企业管理当局在遵循GAAP(或会计准则)的基础上,通过对企业对外报告的会计收益信息进行控制或调整,以达到主体自身利益最大化的行为。

以满足利润管制为目的的盈余管理是我国上市公司最普遍的行为之一。会计估计变更行为是会计政策选择的核心内容之一。会计估计的变更通常与公司盈余管理行为紧密结合在一起。尤其在当前全球金融危机的背景下,企业经营形势严峻,微观主体的经营或多或少会发生一些困难,企业的应收账款可能会无法收回,坏账因此会相应增加。

上市公司定期对外提供财务报表的时候,如果会计估计设计的基础发生了变化,或者由于取得了新的信息,积累了更多的经验,就可能需要对会计估计进行修订或变更。因此,会计估计变更是周期性财务报表编制的必然产物。由于信息的不对称,外部信息使用人很难判断是否属于公司特定的盈余管理行为。

会计估计变更的主要内容包括:固定资产折旧率的变更、固定资产折旧年限的延长或缩短以及计提坏账准备比例的变更。在2008年年报拉开序幕之际,笔者已经关注到变更会计估计的上市公司,如一汽夏利(SZ.000927)、济南钢铁(SH.600022)、胜利股份(SZ.000407)、ST华发(SZ.000020)、合加资源(SZ.000826)等等。比较典型的是广宇发展(SZ.000537)。这家上市公司修改了坏账准备的计提方法,由期末余额百分比法及个别认定相结合的方法修订为账龄分析法与个别认定法。由于此项会计估计的变更,导致合并报表净利润减少1.78亿元,归属于母公司的净利润减少1.72亿元。为此,北京五联方圆会计师事务所出具了专项审计报告。值得注意的是,从披露的审计报告附表可以看出,该公司5年以上的其他应收款占其他应收款总额的26.22%。审计报告明确指出:该审计报告并非对内部控制的有效性发表意见,仅是处于职业判断,会计估计变更明细表不存在重大错报。那么,公司在内部控制或经营上的深层次的问题人们是无法获知的。显然,公司现在的管理层想把前几年被掩盖的问题暴露。为此,根据监管要求,该上市公司召开了股东大会,并且采取了网络投票方式,从公开披露的股东大会决议可以看到,参加投票的前十名股东中有六名股东投了反对票。虽然股东大会通过了此项议案,但是流通股股东的投票情况显示了股东们对会计估计变更的质疑。

我国新《企业会计准则第28号——会计政策、会计估计变更和差错更正》在对会计估计的变更方面给管理层预留了较大的空间。《准则》规定:企业据以进行估计的基础发生了变化,或者由于取得新信息积累的更多经验以及未来的发展变化,可能需要对会计估计进行修订。会计估计变更的依据应当真实、可靠。对会计估计的变更的定义为:由于资产和负债的当前状况及与其经济效益和义务发生了变化,从而对资产或负债的账面价值或资产的定期消耗金额进行调整。笔者认为:盈余管理并不是一个贬义词,给管理层预留此空间也未尝不可,关键是看盈余管理的目的。从财务报表稳健以及公司可持续发展的角度看,在政策允许的范围内调整一下对公司、对股东也是有利的。但是如果管理层不诚信,采用盈余管理来达到自己的目的,则是资本市场所不允许的。例如净利润低于奖金方案的下限,管理者就有可能进一步降低净利润。这样,下一年度得到奖金的概率就会增加。相反,如果净利润高于奖金方案的上限,管理者在计算报告利润时就会尽量去除超过上限的部分,因为这部分利润得不到奖金。只有当净利润在奖金方案的上限和下限之间时,管理者才会有增加报告利润的动机。此外,管理者在卸任之前通常会选择有利的会计政策调增报告利润,以获取最后一次高额奖金。同样,业绩较差的企业管理者在任期将到时,为防止或推迟被解雇,也会利用盈余管理来粉饰真实业绩。但是,一旦管理者的变动得到确定,管理者便可能降低当期利润,以增加未来盈利的可能性。在实行承包制的企业中,管理者进行盈余管理以达到获取个人利益的目的的可能性更大。管理者报酬与会计利润挂钩的制度原本是用来消除股东与企业管理者之间的“信任危机”,但实施的结果却事与愿违,非但没有消除危机,反而加深了危机。最终的结果是管理者通过盈余管理获取了巨大的私人利益,而股东、底层雇员却成了名副其实的受害者。

现在又值上市公司公开披露年报之时,笔者建议对会计估计的变更监管要求增加以下内容,以便投资者增强判断能力,进而判断出哪些属于恰当的会计估计的变更,而哪些属于会计估计变更不当。新晨

建议一:增强会计估计的信息披露内容。

新《企业会计准则第28号》应用指南指出:会计估计的变更需要经股东大会或董事会、经理(厂长)会议或类似机构批准,并报备。但在《企业会计准则第28号》第五章披露中并未作出要求,笔者建议《企业会计准则第28号》明确要求在会计附注披露中增加该变更事项的审批程序。

建议二:明确会计估计的审批权限。

深圳证券交易所《上市公司信息披露工作指引第7号——会计政策及会计估计变更》规定上市公司变更重要会计估计的,应在董事会审议批准后比照自主变更会计政策履行披露义务;达到以下标准之一的,应当提交专项审计报告并在定期报告披露前提交股东大会审议:

1.会计估计变更对定期报告的净利润的影响比例超过50%的;2.会计估计变更对定期报告的所有者权益的影响比例超过50%的;3.会计估计变更对定期报告的影响致使公司的盈亏性质发生变化。上市公司在召开前述股东大会期间,必须向投资者提供网络投票渠道。

但是,具体到哪些需要董事会批准,那些需要经理层批准并未明确规定,而且对未来影响数的判断基本是未经审计的,这样就会容易产生猫腻。

建议三:由于信息的不对称,会计估计变更的原因往往含糊其辞,如金融危机、未来的不确定性、由于各种客观原因影响、原预计使用年限与实际存在的情况存在较大差异等,笔者建议在会计估计变更次年的年度报告中披露上一年会计估计变更对公司盈利情况影响的说明。

建议四:增加准则执行的监督环节,增强外部监管者的职业判断能力,准确判断公司变更会计估计的动机,并对盈余管理行为起到制约作用。外部审计师必须把信息的完整性放在首位,不允许以追求效率为借口,采用忽视效果的审计方法以取代必要的审计程序。

《独立审计具体准则第8号——错误与舞弊》指出,错误包括原始记录和会计数据的计算、抄写错误和对事实的疏忽和误解,而蓄意使用不当的会计政策则属于舞弊行为。笔者认为:会计估计变更中的异常现象更值得人们认真思考。

【参考文献】

[1]韩洪灵,颜志元.会计估计变更公司的盈余管理分析[J].浙江大学学报(人文社会科学版),2008,38(2).

[2]贾剑锋,李淑花.盈余管理与利润操纵的差异[J].财会月刊,2001(14):25-26.

[3]王静,陶晓敏.上市公司盈余管理的负面影响及其对策[J].南京经济学院学报,2001(5):52-55.

篇4

关键词：载人航天器；软件需求；变更控制；改进流程

中图分类号：TP301文献标识码：A文章编号：1672-7800（2013）006-0023-03

作者简介：李皖玲（1980-），女，硕士，中国空间技术研究院载人航天总体部工程师，研究方向为载人航天器信息系统。

0引言

软件需求在软件产品的整个生存期中占有重要位置，是软件工程项目的依据和出发点，无论是软件开发还是软件维护，都是以满足软件需求为最终目的[1，2]。

在实际工程研制中，用户需求变更的现象不可避免。美国Standish Group 公司对8 400个软件项目的调查和研究指出3种最经常使项目遇到困难的因素，其中，不断改变的需求和规格说明占所有项目的12%[3]。同时，ESPITI机构根据3 800个调查人的回答，管理（更改）需求是被调查者回答的软件研制过程中最难解决的两个最大问题之一[4，5]。以航天某型号的某个子系统为例，共有软件配置项14个，全生命周期共发生需求变更34次，涉及软件11个，占到软件总数的78.6%，发生过4次及4次以上需求变更的软件有4个，占到软件总数的28.5%。

如何及时、有效地控制软件需求变更问题，已成为软件工程化管理不可回避的课题。如果不能对需求变更进行及时有效的控制管理，很可能对整个软件项目造成“牵一发而动全身”的影响[6]。

1需求变更原因及管理现状

1.1需求变更原因

载人航天器软件工程化的一项重要工作是对变更进行控制，以将变更对工作量、工期和质量的影响降低到最小。根据型号研制工作经验，造成需求变更的原因可总结为以下方面：

（1）系统复杂导致需求理解不完整、不明确。载人航天器研制是个庞大的系统工程，由13个分系统构成，一个系统级功能及任务需层层分解至某个软件或某几个软件来实现，带来软件内部、软件与软件之间信息流设计复杂、信息交互频繁。系统需求的复杂性，带来了对软件需求理解的不确定性及不完险。

载人航天器软件需求分析需经过系统级、分系统级、配置项级三级开展，在需求分析阶段，若系统级或分系统级未对软件需求进行深入论证、分析，软件研制人员也未重视分系统级及系统级人员的参与，导致需求分析工作各自独立，没有设计出良好的软件结构适应变化，造成后期频繁的需求变更。

（2）工程周期长导致需求不断加以完善。载人航天器的软件研制需经历初样、正样阶段，一般研制周期为2～3

年。在初样阶段，建立初步的软件功能基线后，开发工作即开始启动。随着软件研制工作的深入，分系统会提出新的需求。同时，载人航天器系统与子系统按照同一节点进行开发，即使建立的功能基线是无遗漏的、明确的，但随着工程深入，其中的某个子系统发生任务变更，由此带来该子系统软件或其相关软件需求发生变化。

（3）软件需求本身特点。软件需求作为整个软件项目的最关键的一个输入，同硬件产品不同，具有模糊性、不确定性、变化性和主观性等特点，它的自身特点就决定了变化的可能[5]。

1.2需求变更管理存在的问题

载人航天器软件工程化的需求管理方法经过近10年的运行和实践，确保了多艘航天器软件安全、稳定运行，详细流程见图1所示。但目前需求变更控制流程仍然存在待改进地方，主要体现在以下方面：

（1）需求变更控制方式单一。载人航天器软件工程化对需求变更的控制方式单一的主要表现，其一是未区分软件研制不同阶段需求变更的处理流程，对需求变更控制和管理均是按照图1所示的流程进行，实际上，初样和正样阶段的需求变更，对计划和质量的影响是完全不同的；其二是对所有的需求变更一视同仁，未区分关键性需求和改进性需求，致使需求变更频繁发生，导致工作量和资源投入的不理性增加。

（2）变更影响域分析滞后。对于分系统提出的变更，多是从技术的角度出发，经过系统级、分系统两级论证通过后，以技术要求方式下达。一旦软件研制单位接收到技术要求，按照软件工程化要求进行软件变更及影响域分析时，发现由于此次需求变更对软件架构和研制进度带来较大影响，并引入了质量风险，也只能按照影响域分析结果进行变更。

2需求变更管理流程改进

设计一个清晰的、明确的、可控的、有效管理的需求变更工作流程，有利于促进软件开发过程中的人员分工和合作；有利于对需求变更的处理阶段进行实时监控和跟踪[7]。

需求变更控制改进后流程见图2所示。

2.1变更申请

软件需求变更申请可由需求方（分系统级）提出，也可由开发方（软件研制方）提出。

提出的软件需求变更由开发方归入“需求变更池”进行管理，“需求变更池”由需求变更时间、需求变更定义、变更原因、提出变更人等信息组成。

根据软件研制特点和软件进展阶段，需求方定义需求变更周期，每一个需求变更周期对“需求变更池”的需求进行统一处理。如在初样尚未进入编码阶段，需求变更周期定义为两周，若在初样已完成编码阶段，需求变更周期定义为一个月，在正样阶段，将“需求变更池”的处理周期定义为事件驱动。在每一个需求变更周期内，需求方将与开发方一同，对“需求变更池”内的需求处理一次。

采取“需求变更池”管理的好处是将需求变更流程变为周期性，既能确保所有需求申请都能够得到及时处理并经历正规的需求管理流程，又能尽可能地减少对软件研制过程的干扰。

2.2影响域分析论证

当需求变更周期到达时，需求方和开发方将一同进行变更的影响域分析。

若需求方提出需求更改申请，需与软件经理共同编制需求更动论证及影响分析报告。需求方从更动的必要性、可行性及变更带来的影响方面进行论证，即是否必须进行设计变更才能满足预期的性能指标要求和使用要求，或是对此有明显改善、提出的变更技术上是否合理，工程上是否可行，变更对产品的可靠性、安全性及接口的影响。开发方根据需求跟踪矩阵，标识并实施因分配需求的更改而引起的项目计划、软件工作产品（包含文档和代码）和活动的更改。开发方的影响分析包含软件功能、性能等技术类分析，还应包含管理类的非技术影响分析。

若开发方提出需求更改申请，开发方单独编写需求更动论证及影响分析报告，需重点从软件配置项角度论述更改带来的影响。

在该流程中，影响域分析论证由需求方和开发方在申请得到响应的第一时间内共同完成，需求变更影响域分析将更全面、更系统也更具体。同时，通过影响域分析，将需求方变更也纳入到了工程化管理，既对需求方更改进行了控制，以减少不必要的软件变更，又使得开发方能够及早地参与影响域分析论证，及时应对需求变更。

2.3需求变更评审

软件配置控制委员会（SCCB）（组成人员中包含需求方、软件专家）评估需求变更论证及影响分析报告。

2.4需求变更分级管理实施

在进行需求变更评审时，需对需求变更进行定级，针对定级情况实行分级管理，以达到对需求变更的控制和管理。

根据变更影响域分析，可将需求变更定义为4个级别。一级为变更关键性需求，如若不变更，意味着整个项目不能正常交付使用，前期工作也会被全部否定；二级变更影响后续关键性需求，不影响前面工作内容的交付，但不变更，新的项目内容无法提交或继续；三级变更为后续重要需求，如果不被满足会令整体项目工作的价值和开发人员技术价值下降；四级需求是改良性或可选性需求，没有实施变更并不影响已有功能的使用，代表个人喜好[8，9]。

一二三等级变更，需实施更改；对于四级需求，如果时间和资源条件允许，可实施更改或是后续版本更改。

需求方提出的变更申请，需求方对分配需求进行更改，将变更后的《软件任务书》批准、受控，下发至软件研制单位。开发方接收到正式变更要求，类同开发方提出的变更申请，按照软件工程化管理规定，办理更改的三单审批流程，实施更改。

2.5通报和跟踪

SCCB确认需求已进行实际的变更。软件配置管理工程师通知所有受影响的小组和个人。开发方将因更改而引起的情况通报给受影响的组和个人，对已标识的相关更改进行跟踪，直到更改结束。

3需求变更管理实践

上述需求变更管理流程，已被成功应用到某型号某软件研制过程，该软件为嵌入式C程序，代码规模约为12 000～15 000行。在实践过程中，初样阶段 “需求变更池”处理周期为1个月，正样阶段处理周期定义为“新的需求提出”。至软件交付时，该软件共发生软件需求变更15项，需求方提出需求变更6项，开发方提出需求变更9项，通过需求变更评审，需求变更一级为3项、二级为4项、三级为2项、四级为6项。

通过需求变更管理，该软件共发生的15项需求变更中，实施了13项，有效地控制了软件需求变更比率。在未增加开发人员和资源情况下，同软件开发计划相比，软件过程文档编写数量减少了16份以上，初步预算节省软件工程组人员工时80人时以上；同时软件研制过程可见、受控，软件研制进展顺利，交付进度较计划时间提前了约60天；软件在交付使用后，其功能性能满足用户需求。

4结语

通过分析软件项目开发过程中需求变更产生的原因，提出了软件工程化管理过程中存在的问题，并在此基础上提出了需求变更管理主流程， 该流程保证变更实施在可控范围内进行，将影响域分析提至系统级层面，并将需求变更实施分级管理，从而将变更带来的影响尽可能地降到最小。需求变更管理流程真正将需求方、开发方与需求变化、变更请求和项目管理紧密结合在一起。通过某型号某软件3年的软件工程化管理实践，证实该管理流程使需求变更在项目开发中得到了有序有效管理， 保证了项目的顺利完成， 提高了项目的质量。

参考文献：

[1]韩万江，姜立新.软件项目管理案例教程[M].北京：机械工业出版社，2005.

[2]张海藩.软件工程[M].第1版. 北京：清华大学出版社，2006.

[3]ERACAR Y A， MIECZYSLAW. An architecture for software that adapts to changes in requirement [J] . Journal of System and Software，2000（50）.

[4]STANDISH GROOP. User survey report[R]. European Software Process Improvement Training Initiative， 1995.

[5]秦众森，李娟.需求变更管理过程机器工具分析与展望[J].计算机工程与设计，2009（11）.

[6]SUZANNE ROBERTSON， JAMES ROBERTSON.掌握需求过程[M].王海鹏，译.北京：人民邮电出版社，2003.

篇5

关键词：项目管理；范围管理；质量管理；进度管理；成本管理

当今世界充满“变化”，信息化产业尤为突出，技术创新速度越来越快，用户需求与市场不断变化，人员流动也大大加快。在这种环境下，企业需要应对的变化和挑战大大增加，管理也面临很多问题和挑战。软件行业是一个极具挑战性和创造性的新行业，管理上没有成熟的经验可供借鉴。项目管理是行之有效的管理方法。因此，项目管理在软件开发中的应用日益受到重视。

1 项目管理概述

1.1 项目定义及特性

根据PMBOK（项目管理知识体系）中的定义，项目是为创造某种独特产品或服务所做的一次性努力。项目不论大小都具有下列特性：

⑴项目都有明确的目标，即满足特定的要求

⑵项目具有唯一性

⑶项目必须在一定时间内完成

符合这三个特性的都称之为项目，均可以采用先进的项目管理技术对其进行科学有效的管理。

1.2 项目管理定义

PMI-PMBOK中项目管理定义为：将知识、技能、工具、技术应用于项目活动，以期满足或者超越项目利益相关者的需求和期望。结合其它相关资料，总结的项目管理定义为：项目管理就是以项目为对象的系统管理方法，通过一个临时性的、专门的柔性组织，对项目进行高效率的计划、组织、指导和控制，以实现项目全过程的动态管理和项目目标的综合协调与优化。

1.3 项目管理目标

项目在实施过程中，时间、人力、物力等任何资源都是有限的，对质量的要求也是有止境的。争取在有限的资源内，做到质量最好，成本最低，进度最快。平衡好项目质量、进度与成本之间的关系是每一个项目管理的最终目标。

1.4 项目管理过程

⑴启动过程

认识到一个项目或阶段应该启动并负责开始执行。

⑵计划过程

制定并调整一个可实施的、用于完成项目所实现商业目标的计划。

⑶执行过程

协调人力和其他资源去完成计划。

⑷控制过程

通过监督和核查项目的进展，并在必要时采取正确的处理措施，来保证项目的实现。

⑸结束过程

使项目或阶段的结果接收正式化，并将这种接收变为有序的结束。

1.5 项目管理要素

C=f（Q，T，S） 公式1

在公式1中，C、Q、T、S的含义分别如下：

Cost成本：项目工作的成本，与项目使用的人力资源和自然资源直接相关。

Quality 质量：所完成工作的质量。

Time时间：项目必须满足的进度要求。

Scope范围：要执行的任务的幅度。

从图3看到：项目的整个过程是从确定目标开始，接着是界定项目范围。之后，开始实施具体的项目活动。组织是该项目干系人集合的统称。在整个项目实施过程中，组织始终围绕着时间、成本、质量这三个要素在进行权衡、分配等工作。

2 海上船舶监控系统简介

2.1 海上船舶监控系统的意义

我国有473万平方公里海域，海上运输和渔业捕捞在国计民生中占有重要地位，因此在管理中引入海上船舶监控系统意义重大：首先，系统的通信距离在600海里以内，基本满足船舶海区通信距离需求；其次，及时监控船舶的信息，便于在船舶遇险时实施远程救援；最后，便于海上运输和渔业管理部门有效监控、指挥、调度作业船舶，从而保证船舶的航行、停泊、作业安全，助推海上救助信息化和平安渔场建设。

2.2 海上船舶监控系统的功能

以电子海图为背景，通过GPS短波通信方式实时获得船舶信息（位置、方向、速度、状态等），向船舶发送控制命令（监控、改变信道等）和短信，使船舶的管理更加直观，并且大大提高了实时性和交互性；提供船舶信息管理，使船舶的管理实现信息化；提供“船舶工具”（轨迹回放、船舶锁定等）功能，便于以轨迹的方式回顾船舶历史信息，实时跟踪船舶；提供“船舶查询”功能，使用户能够迅速的了解某船舶的当前、历史信息及通信情况；系统提供很多图形查看、测距功能，使图形更加友好、方便，更好的为船舶定位系统服务；系统还提供了网络数据共享服务，便于本系统与其它数据平台进行数据共享，以满足不同客户单位的管理需求。

3 海上船舶监控系统的项目管理

海上船舶监控系统的项目管理包括很多方面，这里仅以范围管理、质量管理、进度管理、成本管理为例进行介绍。

3.1 海上船舶监控系统的范围管理

确定项目范围是项目起始阶段的战略工作之一，有效的范围管理是保证项目成功和企业成长的重要前提。

范围管理是定义项目的范畴。本项目范围管理从以下方面入手：搞清需求、准确界定范围、变更控制要严。

3.1.1 需求分析

（1）熟悉背景，加强沟通。通过与项目所有“利益相关者”广泛、深入的沟通，领会项目发起人的真正意图、明确组织（企业）的具体要求、找到用户需求的关键点，将三者统一起来（平衡点），或者至少要在关键的问题上达到一致。

（2）培养正确的需求意识，设定优先级。挑选懂管理、精业务、会技术的多种人才参加项目需求分析，并对他们及其他相关人员进行培训，提高他们重要性认识、准确描述需求和沟通与交流的能力，增强相互配合的意识；之后，按照需求的重要性和紧迫性进行优先级排序，对需求进行主动管理，确定满足项目优先级的执行方案，确保项目整体功能的实现。

（3）规范项目需求分析流程，如图5所示。

3.1.2 界定范围

对项目的范围进行描述，项目做什么、怎么做、做到什么程度都要讲清楚。本项目采用工作分解结构（WBS）界定项目的范围。工作分解结构是最常用的方法和工具，也是最有价值的工具之一，在使用时注意以下三点：

（1）深化认识，强化四种观念：

a.树立“可计划量”概念。能够作为WBS分解元、进入项目计划图的信息即为“可计划量”。

b.重视“边界问题”。明确范围是WBS、实施计划（基线计划）和对各种边界的认可。

c.项目工作范围是无形的又是可控的。对范围的限制主要来自三个方面：成本预算、计划时间和质量标准。

d.按分解的规律去办。WBS是工作逻辑的有机体，不同类型的项目分解，有不同的要求，因此，要按照项目自身的规律去办。

（2）规范工作分解流程，如图6：

（3）抓好关键层（第一级和第二级）的分解。

3.1.3 变更控制

变更控制是指在项目生命周期的整个过程中，对变更的识别、评价和管理等工作。范围变更是对已批准的工作分解结构项目范围进行修正。范围变更控制必须与时间控制、成本控制、质量控制等其他控制过程结合起来。

项目的范围计划做得再好，也可能发生改变。它为项目管理者提供重新计划项目、纠正不足和改进管理的机会。但是，变更一旦失去控制，就会不断地产生意料之外的风险。所以，需要规范的变更控制程序，本项目采用的变更控制流程如图7所示。

3.2 海上船舶监控系统的质量管理

质量管理有助于提高企业的生产能力，节省资源，提高软件和服务的竞争力。高质量软件维护成本低，并售出价格高。本项目质量管理采用ISO9000认证体系，采用的开发控制程序大体如下：（1）设计和开发策划；（2）接口管理；（3）设计和开发的输入；（4）设计和开发输出；（5）设计和开发评审；（6）设计和开发验证；（7）设计和开发确认；（8）设计和开发更改的控制。

在开发过程中根据控制程序生成各种文档。并且在软件的单元测试、集成测试；功能测试、性能测试、压力测试；设备联调测试、工程组网测试等方面设计测试用例，严格测试，并生测试报告，极大的保证软件的质量到，得到用户的高度认可。

3.3 海上船舶监控系统的进度管理

3.3.1 进度管理特点及方法

进度是项目管理的基本组成部分，做好项目进度的安排，根据进度组织实施、控制项目的进展、协调处理相关任务是项目能否成功的重要保障。进度是组织、控制与协调的依据。随着计算机技术的发展，涌现了许多项目进度管理软件，本系统开发过程中采用了Microsoft Project Standard进行项目管理。它集成了国际上许多现代的、成熟的管理理念和管理方法，能够帮助项目经理高效准确的定义和管理各类项目。

3.3.2 工程资源与费用管理

在进度编制完成后，将工程所需的资源与费用加载进度作业中，以便对所编制的计划进一步的分析与优化。

3.3.3 进度计划的动态控制

进度计划是项目执行的基准，是项目实施阶段控制项目的依据。进度计划的动态控制是项目能否实现预定目标的关键，主要完成以下工作：监控实际进度，及时、定期更新进度计划，预测出项目将提前还是落后于预定进度。

3.4 海上船舶监控系统的成本管理

本项目的管理和控制包括范围、质量、进度和成本四大控制，而成本费用控制是其中的关键，因为范围、质量和进度这三方面的控制最终均与费用控制发生密切关系，所以在项目的执行过程中必须严格进行成本控制才能获得最佳效益的目标。必须在需求、设计、开发、测试、维护等各个阶段严格进行控制，在满足合同要求的前提下，尽可能的降低项目费用。为实现成本费用控制的目标，在本项目的执行过程中，采用成本计划及绩效理论对成本进行分析和控制，取得了良好的效果。

3.4.1 成本确定

本项目成本价包含设备材料费、设计费、安装费、调试费、项目管理费及项目人员的工资、补助、奖励、办公费、差旅费等等。

3.4.2 成本控制

成本控制主要包括：分析成本绩效以确定需要采取的纠正措施；决定采取那些纠正措施；修订项目进度，包括工期和成本计划，综合筹划纠正措施。

4 结束语

在“海上船舶监控系统”的项目管理开发过程中，结合项目管理的相关知识着重对软件的范围、质量、进度和成本进行管理，使我认识到项目管理是个系统工程，它是管理技术与具体项目过程相结合的产物。它不但是一种管理技术，同时又是一种应用技术。项目管理技术必须与具体的业务领域相结合，才能产生巨大的经济与管理效益，忽略任何一方都不利于企业与组织项目管理体系的建设与能力的提高。项目管理需要不断的尝试，不断的改进，不断的总结。我们要把眼光放远一点，看看世界上发达国家的项目管理，找到真正的差距，在以后的管理和实践中努力探索不断提高项目管理的水平。

[参考文献]

[1]计算机信息系统集成项目管理基础，中国软件评测中心，电子工业出版社，2004.03.01.

篇6

[关键词]军用型号软件；GJB 5000A；需求；管理；软件工程化

doi：10.3969/j.issn.1673 - 0194.2015.18.122

[中图分类号]TP311 [文献标识码]A [文章编号]1673-0194（2015）18-0-02

0 引 言

随着国际关系局势日益严峻，近年来，军用型号软件项目数量剧增，且功能不断扩充，但军用软件运行的高可靠性、安全性仍是保证部队作战的首要战略指标。在软件研发团队人员及水平相对固定的情况下，按照以往过多依赖于个人能力和“游击队”式的开发模式，不但不能满足型号软件工程化管理要求，并且为软件后期运行维护带来了极大隐患，故需要对软件研制过程各项活动进行分析及把关，提高交付软件质量，保证交付进度。通过梳理，近年来军用型号研制过程中出现的质量问题，主要原因有如下几方面：第一，部分软件后期由于与相关系统的接口需求分析不明确造成软件运行错误；第二，开发方过度承诺，后期需求变更无法控制且版本混乱；第三，大多数系统和软件项目的投入，有一半以上纯属浪费；第四，用户提供给开发方的需求清单不能反映真实需求；第五，系统测试阶段发现的错误，80%是由不正确的需求或遗漏的需求造成的；第六，项目主管对需求分析和定义的基本原理和重要性缺乏认识，忽视对需求的投入；第七，缺乏有效的需求分析工具支持需求分析和需求管理。

与传统的、有形的、可描述清晰的以及可具体检测的硬件生产制造需求相比，软件需求具有模糊性、变化性和主观性的特点。正因为软件需求的这些特点，对于一个软件项目的开发来讲，最困难的部分就是准确说明软件需求，在用户和开发团队之间建立对需求的共同理解，维护需求与各阶段工作产品达到一致性，并控制需求的变更。由此可见，软件需求分析及实现作为项目研制最重要的一个组成部分，对其过程管理的好坏很大程度上决定了软件开发的成败。

1 基于GJB 5000A建立本地化的需求管理模型

通过多年探索和研究发现，在运用GJB 9001B实现对软件研制各阶段产品进行有效考核的基础上，借助GIB 5000A可帮助军工单位加强软件研制过程管控，满足软件工程化要求，确保软件研发进度及质量。GJB 5000A-2008《军用软件研制能力成熟度模型》是参照《软件能力成熟度模型》（CMMI）1.2版制定的。其目的是帮助军用软件研发组织对软件研制过程进行管理和改进，增强开发与改进能力，它为改进一个组织的软件开发过程提供了单一的集成化框架，二级分为7个过程域，各域继相互独立又相辅相成。其中需求管理是一个单独的过程域，主要由5个专用实践来描述。这5个专用实践围绕着“管理需求”这个专用目标开展，如图1所示是基于GJB 5000A的需求管理模型。

1.1 软件需求管理基本过程定制

根据我所型号软件工程化大纲要求及软件研制具体流程，对需求管理过程进行了本地化定制，其中，专用实践SP1.1和SP1.2在实际执行过程中关联性较强，且时间较集中，采用“需求的理解和承诺”活动来描述，重点细化明确了需求提供者准则，将型号项目组定位为用户方，软件研究室定位为开发方，系统总体及软件生产人员定位为软件部署和维护人员；考虑到以往软件研制过程“重代码轻文档”的弊端，对系统需求的颗粒度划分原则进行了定义，并将其细化入《软件任务书评审要素表》及《软件任务书检查表》具体条目，为确保软件需求的可追溯落到实处奠定了基础。在订制过程中，随着对体系的理解不断加深，也采用了使用替代实践的方式简化本地化执行步骤，如为了简化需求承诺的流程使其具有可操作性，裁剪掉了软件需求承诺单，用软件评审结论报告签署页及软件任务书审签流程替代；将需求管理计划并入软件项目开发计划，确保需求管理过程策划与项目开发主计划的一致性。

SP1.4和SP1.5所关注的内容，贯穿软件研制过程的各个阶段，且存在前后依赖关系，执行时间点为阶段工作完成时和需求发生变更时，故采取用“需求跟踪”活动来描述，航天科技集团北京航天发射技术研究所（以下简称我所）软件多为非独立工作模式，主要运行于整个CAN总线通信网络或以太网通信网络中，与其他软件有频繁的数据交互，故在需求跟踪实践中，除了关注软件本身的功能、性能在各级工作产品中完成情况，也强调与相关联软件的通信接口即横向需求的追踪，对于软件需求输入中非技术类条目的追踪，在项目管理PMC过程域中通过项目例会及相关评审活动实现。对于需求追踪的形式制定了需求正反向追踪记录表―需求跟踪矩阵―项目问题追踪表―项目问题报告及纠正单的统一化流程处理方式。并明确需求追踪不一致性的发现渠道，除软件项目组成员，还包括第三方测试人员、利益相关方、项目QA人员及同行专家。

由于SP1.3需求的变更对后续软件质量、顾客满意度、批产及运行维护过程都有很大影响，故对需求变更活动，进行了强化说明，并细分具体的操作步骤。通过软件需求变更情景划分定义了不同的软件需求变更流程，对于研制过程中产生的变更，按照软件更改申请单提交―型号指挥批准（SCCB组长）―软件更改研制―软件回归测试―版本升级受控流程来实现，对于软件外场参加大型试验及运行维护时发生地变更，按照填写软件需求沟通备忘录，填写外场软件状态更改记录单―例外放行情况确认―补录技术偏离单、软件更改申请单及更改单―入库受控流程实现。

1.2 适用于不同生存周期模型的需求管理过程

随着软件编程语言、运行环境的扩展，结合型号研制进度紧、用户需求变更频繁的特点，传统的瀑布模型已经不能满足目前多型号软件并行开发的局面，通过梳理我所型号软件研制特点，结合《QJA 30A（2013）航天型号软件工程化要求》中定义的航天软件研制类型，对新研软件进行了分类，除传统瀑布模型外，充分借鉴敏捷开发方法，结合航天企业文化特点，新增原型开发模型、迭代模型及增量模型，可单独使用也可组合使用，并可在定义模型基础上根据型号研制阶段特点对模型进行衍生及细分，覆盖各型号软件研制任务，可根据软件开发人员能力梯度及项目组成员组成选用不同的开发模型。

对于迭代模型及原型开发模型中迭代阶段的需求开发及实现，采用需求沟通备忘录及需求正反向追踪表确保需求的可追踪性，弱化需求变更的流程控制，迭代过程中软件版本入开发库管理，当迭代阶段完成后，回归瀑布模型研制模式，严格遵守软件需求变更流程，必要时需形成软件更改影响域分析报告，并通过会议评审，确保需求更改的可行性。

1.3 软件需求过程管理过程与其他过程域的集成

基于GJB 5000A的软件工程化建设是一个各个过程域相互影响、共同促进的过程，软件需求管理过程的不断推进也离不开相关过程域的支持。主要有：需求变更对项目策划过程的影响，将需求的变更转化为进度偏差，根据进度偏差超阈值的多少来进行合适的计划变更；需求变更需要依赖测量与分析过程统计相关数据，方便项目研制过程中项目负责人宏观把握需求状态的情况，也为组织级生存周期模型选型指南及决策支持提供了保证；配置管理过程为需求承诺及变更输入的有效性提供了支持，确保了软件需求追踪及变更活动不是无源之水。

2 软件需求管理平台建设

由于软件规模庞大造成的需求颗粒较多，对需求追踪及变更的有效性带来了实际执行困难，采用以往的Excel表格填写方式，不但严重耗费一线技术人员的时间和精力，而且不能保证追踪的有效性，久而久之，需求管理的执行有效性下降，以往项目运行的各种弊端重新凸显。我所与相关单位合作，尝试研发订制了软件需求管理工具，经试用，对提高人员效率，确保需求管理执行落到实处起到了促进作用。如：采用需求影响域分析，自动对变更工作产品的需求追踪关系进行分析，对于未变更的需求项，工具自动继承与上级工作产品的追踪关系，对于变更的功能项，用红色在需求跟踪矩阵中标注出来，需求管理人员只需根据红色标注索引即可对更改需求项的追踪关系重新定义，即可完成新一轮的需求追踪活动，工具会自动生成新版本的需求跟踪矩阵；针对表格化的需求跟踪矩阵不直观分析困难的特点，采取需求追踪关系图的表现形式，一列代表一个阶段的工作产品，列与列之间通过连线表现相关工作产品的追踪关系，当需求发生变更时，需求管理人员只需直接拖动并改变连线即可实现对追踪关系的重新定义。当发生需求追踪不一致情况时，只需根据本阶段需求实现要素与之前各阶段工作产品的需求项关联情况，逐级检查出中间环节未追踪上或未实现的需求条目。效果如图2所示。

3 结 语

通过为期1年的GJB 5000A二级全面运行，我所型号软件工程化水平有了显著提高，并实现了各型号软件均能够按期交付，靶场无低层次质量问题出现，EPG组对本地化流程及管理模式也有了更深层次的理解。在现有本地化需求管理过程的基础上，深化体系的本地化订制，使其与本单位实际情况更加贴合，促进执行力度。

第一，简化需求正反向追踪记录表，在各阶段软件设计文件中体现，无需再生成表单，简化设计人员的工作量，避免了多处产生同一张表带来内容不一致的隐患；

第二，对不同生存周期模型的需求管理活动的测量项进行梳理和定义，对于采用敏捷方法开发的软件弱化对需求变更情况的统计，加强对软件质量问题及研制进度的测量与分析；

篇7

一、变更管理的标准流程

商业银行在不断发展中，不可避免地会存在各种各样的变更活动，无论是自行开发的软件版本投产，还是修改供应商提供的软硬件参数，或是改变系统、网络部署模式、搬迁机房等操作，如何对以上各类变更活动进行有效管理？一般情况下，建议通过规范化、标准化变更管理流程的方式，对变更申请、审批、准备、实施等全流程进行精细化管理以减小变更可能引发的生产事件及对业务连续性产生的影响。具体流程如图1所示。（1）变更申请变更申请作为变更流程的第一步，应由需求方向实施方提出正式的变更申请，通常要填写统一的变更申请表并注明申请人、申请时间、详细的变更需求、原因及内容、期望变更完成时间等。对于中高风险变更，需求方还应评估该变更可能产生的影响。最后，变更申请表经由需求方的负责人审核后提交给实施方。（2）变更准备实施方接收到变更申请后，根据变更需求制定详细的实施方案，内容应包括：实施过程的详细步骤、实施完成的验证方案、实施不成功的回退方案等。实施方案应由技术部门负责人进行审批。对于中高风险变更，还应由技术专家对实施方案进行评审后提交给管理人员进行审批。（3）变更实施实施部门应安排有经验的技术人员实施变更，实施人员应严格按照实施方案实施，并保障双人操作，一人实施，一人复核。实施完成后，必须认真审核结果并进行技术验证。（4）变更反馈变更实施完成后，由需求方进行需求验证，验证通过后，应反馈给实施人。对于未成功实施的变更，应及时联系实施人，分析变更失败原因，准备进行下次变更。

对于以上标准流程，还应重点关注以下几点：（1）准确定义变更风险度不同的变更风险引起的关注程度是不一样的，对于高风险变更需要各方面的业务骨干、技术专家，甚至高层领导一同研究实施方案，确认实施步骤。但是对于低风险变更，一个技术人员即可确定如何进行操作。因此，准确定义变更风险度对于提供所需的技术及人力资源极其重要。同时，如果一个高风险变更被定义成了低风险，并未引起大家的足够重视，则可能会引起重大的生产事故。（2）变更实施时间的选择对于有计划的变更，应充分考虑时间安排的合理性，应选择在基本不影响业务的情况下实施，例如一些重要柜面业务系统的变更，为保障不影响正常业务的开展，应选择在周末的夜间进行。对于紧急变更，也应尽可能的在满足时间要求的情况下，选择在对系统影响最小的时候实施，例如在正常工作日要实施紧急变更以解决某个业务系统的bug，此时，应在该业务系统交易量最小的时刻进行操作，以防止由于高峰时段业务的突然中断而产生巨大影响。（3）高度重视变更审批变更审批决定着做不做变更，以及怎样做。在变更申请中，需求的审批应在进行了充分的业务影响分析的情况下完成，以保障变更确实能在风险可控的情况下达到预期目标。在变更准备中，审批者需尽职尽责，严格审核实施方案，以保障实施结果的正确性并保障在产生问题时能及时回馈。对于由方案不完善、不准确这类原因所导致的变更失败等问题，变更审批人员甚至应承担比实施方案制定人员及实施人员更多的责任。（4）紧急变更应参照标准流程执行对于紧急变更，可通过邮件或电话先进行审批，实施完成后可再按照正式流程进行加补申请。但是对于变更方案的制定、实施及反馈仍需按照标准流程进行，并需要有资质的人员进行把关审核，保障紧急变更能以对业务影响程度最小的形式进行。

二、变更管理中应关注的其他方面

1.建立一套全面完善的制度规范体系为提高变更管理的有效性，规范变更的处理流程，合理有效地调配资源，防范变更风险，建立一套广泛适用于全行的变更制度规范体系是不可或缺的。其中，应包括以下强制规定：（1）各个变更相关部门及岗位的职责；（2）变更各个阶段的活动内容及相关要求，并细化到针对不同类型、不同风险程度的变更管理，采用不同流程；（3）变更实施方案的编写要求与具体步骤，比如实施方案中不能含有客户敏感信息，网络类实施方案应精确到指令级等；（4）应明确各种例外情况的处理方法，特别是对紧急变更要给出一套行之有效的流程方案。通常，变更管理作为一个单独完整的制度被提出，但有时可能也与问题管理、事件管理等IT服务共同组成一套体系规范。

2.培训的重要性在变更管理的过程中，加强人员培训是必不可少的关键环节。不论是对制度规范的理解，还是技术水平的提高，都应该有规划、有组织地进行系统化的培训。同时，还应进行安全意识的培训，重点关注变更管理中的安全方面，例如保护客户信息敏感性的重要性，关注生产环境与测试环境的网络隔离、防止变更人员的客户端感染病毒等。

3.对变更的审计为保障变更管理按照制度流程执行的规范性，需要指定专人定期对变更进行审计。审计主要关注以下方面：（1）变更申请、准备、审批、实施、验证、反馈等各环节的合规性；（2）变更实施方案的质量，包括生产变更方案是否细化到指令级，应急方案和回退方案是否具有可操作性，变更内容是否符合变更需求，变更实施方案是否审批到位等；（3）紧急变更流程，重点审计变更实施未经任何形式的审批，也就是未经变更流程实施变更，这种情况极易产生生产事件，对于这种情况，审计程序应先找到发生变更的事实，可通过信息系统日志记录，然后从中去寻找是否有变更申请，是否有未经过变更审批就进行操作实施的不符合项。需要注意的是，变更审计人员应保持独立性，不能执行自己所参与变更的审计任务。此外，变更审计结果应引起各级领导的高度重视并积极加以整改。

篇8

有明确的项目范围管理的积极作用有如下几点：1、公司通过客户的需求来整理分析好业务的范围，把这些资料记录下来，方便公司以后对这些客户的了解，把所有的内容都确立好，这样项目所要开展的范围就有一个很好的边界，就有明确的定义。2、经过批准的项目为创建WBS奠定了基础，两者相辅相成，共同构成了项目的基本标准，只要项目的范围和内容都确立了，那么就为完成这个项目所要的成本、时间、资源有一个大概的计算，这为下一步公司要打算实行的项目奠定一个基础，为自己的公司未来发展的情况有一个大致的想法。3、项目的范围管理的清晰度这决定着是否能够按时完成这个项目，如是没有明确的定义，含糊不清的话，这中间可能要发生许多的问题，可能做到一半的时候会有其他的内容要变更，或者是需要返工。这延长了完成这个项目所需要花费的时间，让下一个项目的开展也无法按照预期所想的那样去完成，一步错，步步错。所以说，好的范围管理是项目成功的重要基础。

二、项目范围管理的方法

项目范围的管理方法有以下几种：1、确定工作要求，这是很重要的，企业的信息化建设涉及到了企业内部的许多内容，在一般情况下，客户只能根据以往的经验及工作的现状，提出一些要求，特别是在石油这个信息行业中显得特别明显，石油的运用涉及的范围是非常广阔的，现在很多的工厂的发展都离不开石油，石油是一种非常重要的资源，它影响了很多的企业工作，很多时候，用户信息也是不完整的，也是含糊不清的，这就需要企业要在信息化这里下很大的工夫，分析讨论总结重点，项目小组要团结合作。调研小组要仔细的调查市场信息，信息化建设项目并不仅仅是计算机信息系统的开发集成，还必要要满足企业的需求发展，不断的提高企业生产的管理需求。2、在收集资料的过程中，相关人员都要了解自己需要调查的项目是什么，怎么样去调查，要理清所有的东西，若是有含糊不清的话这就有可能在后面出现无法预料的问题，到时候处理起来也是比较麻烦的，措手不及。所以，在调研中需要每个成员的细心，有一个明确的目标，防止后面出现很多的问题。3、范围的核实。范围的核实是一个项目开展的标志，是说正式开发这个项目，确立之后，项目各方就应该按照承诺去实现它，这样项目才能很好的进行下去，这样也能够避免不必要的情况发生，到时候引来不必要的损失，避免在项目进行的过程中引起变更。4、结合WBS技术定义范围。项目的明确定位是非常重要的，但是，不同的用户自己审视的观点总是有差别的，在项目中也有着隐含的意义，这是导致用户变更的一个重要的原因，没有去理解好用户的意思，所以，在一开始确立的时候就应该问清楚用户，不要自己默认用户的需求到底是什么，自己想要的只有自己最清楚，不过利用WBS可以很好的有效的去解决这个问题，这在很大的程度上能够帮助项目干系人明确项目范围内容是什么，工作的要求是什么，很容易就能够被大家理解。

三、结语

篇9

关键词：项目管理，工程造价，项目范围管理

Abstract: in this paper the author to project cost management as the starting point, through application project management technology, from the project scope management, quality management and cost management three aspects analyzes the engineering cost control in the role and method, etc.

Key words: the project management, engineering cost, project scope management

中图分类号：TU723.3文献标识码：A 文章编号：

引言

随着我国加入WTO，建筑业也加紧了行业内的改革，以适应世界经济发展的需要，提高我国建筑业抵抗外部影响的能力，其重中之重即是工程造价管理的全面改革。建设工程造价管理贯穿于工程建设全过程，从工程建设立项到工程项目决策每个环节都存在着造价管理。因此应用项目管理技术，加强工程造价管理，合理确定和有效控制工程造价，提高投资效益是全过程管理工程项目的主要内容。

项目范围管理技术在工程造价中的作用

项目范围管理的概念

项目是为完成产品或服务所做的一次性努力，因此范围的概念包含两方面 一个是产品范围 即产品或服务所包含的特征或功能，另一个是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。产品范围决定项目范围，而成本管理的前提就是项目范围的确定与科学的管理。一巳项目范围确定了 根据相关的成本计算规则，成本也就初步确定了。这也是成本控制的关键，是以后的成本基准线。对于建筑工程来说，开始的项目招标书、投标书、工程图纸等都是确定工程范围的依据。

项目范围管理的方法以及对成本控制的影响

项目范围管理的基本内容包括范围计划编制、范围定义、范围核实、范围变更控制，其中相对成本控制最为重要的是范围定义和范围变更控制。范围定义的输出关键是工作分解结构（WBS），即根据项目目标将一个项目分解成易于管理的几个部分或几个细目，以确保找出完成项目工作范围所需的所有工作要素，它是项目团队在项目期间要完成和生产出的最终细目的等级树。

根据WBS结构图，制订出每个工作包的资源需求，如劳动力、原材料、机械使用、分包商以及相应的差旅交通费，根据资源需求和相应的资源单价就可以编制出成本估算和成本管理计划。 在进行成本估算时，可根据WBS采用类比估算、参数模型、自下而上的成本估算方法。与此同时编制出的成本管理计划则说明如何管理成本偏差，它从资金的角度反映了项目的范围，并运用范围的管理方法来间接地管理成本，两者相辅相成、互相制约，同时构成项目计划的一部分。

根据工作分解结构编制出成本估算后，还应再次根据WBS以及风险管理计划编制出成本预算，即将项目总成本中的各个要素分配到工作分解结构中适当的工作包中，并为每个工作包建立总预算成本（Total budgeted cost，TBC）。建立TBC也有自上而下、自下而上等方法。由此生成的成本预算就是成本控制的关键输出——成本基准计划。

范围管理的另一个重要过程是范围变更控制。在范围管理过程中必须通过监督绩效报告、当前进展情况等来分析和预测可能出现的范围变更，在发生变更时遵循规范的变更程序来管理变更。规范和掌握了范围变更管理，则是抓住了影响项目目标的源泉，同时也就能有效地进行成本控制。 依据范围变更的程序，及时掌握由此引起的成本变更，从而全面控制工程造价，而不是将工程造价孤立地、片面地进行控制管理。

项目质量管理技术在工程造价中的作用

2.1 项目质量管理的目标以及质量成本的概念

项目的质量是项目成功因素中又一个重要环节。保证质量是企业信誉的关键。但产品质量并非越高越好，超过合理水平时，属于质量过剩。根据PMBOK的观点，质量管理的目标是满足规范要求和适用性，不要镀金膜，满足双方一致同意的客户要求。因此无论质量不足或过剩，都会造成质量成本的增加，都要通过质量成本管珲加以调整。质量管理包括质量计划编制、质量保证、质量控制，并在其中提到了质量成本的概念。

质量成本是为了保证工程质量而发生的工程成本。质量成本分为预防成本、鉴定成本（评价，目的是确认质量和过程）、故障成本（纠正错误引起的成本)，故障成本又分为内部费用和外部费用，它们之间的关系可看出，总质量成本曲线为故障成本曲线和预防、鉴定成本曲线之和，其最低点即为最佳质量成本。质量成本管理的目标是使三类质量成本的综合达到最低值由可知，质量预防费用起初较低，随着质量要求的提高会逐渐增加，当质量达到一定水平再要求提高时，该项费用就会急剧上升。质量鉴定费用较为稳定，不过随着质量的提高也会有一定程度的增长。而质量故障成本则不然，开始时因质量较差，损失很大，随着产品质量不断改进，该项损失逐步减少。三者交叉作用，必然能找到一个质量成本最低的理想点，而这个点就是我们控制工程造价的准则。

2.2 正确处理质量成本对控制工程造价的作用

正确处理质量成本中几个方面的相互关系，即质量故障费用(内、外部故障损失)、预防费用和鉴定费用问的相互关系，采用科学合理、先进实用的技术措施，在确保施工质量达到设计要求水平的前提下，尽可能降低工程成本。决不能为了提高企业信誉和市场竞争力而使工程全面出现质量过剩现象，导致完成工程量不少，但经济效益低下的被动局面。在满足客户要求的前提下，以合理的造价提供适用的产品，这才是我们采用项目管理技术管理工程最终的目的。根据分析可知，项目产出物(或项目本身)价值的增加，可以通过增加项目产出物的功能、降低项目造价两种基本方式，以及由这两种基本方式派生出来的其他各种方式实现。例如，同时降低功能和造价，但是功能降低的较小，造价降低较大；或者同时增加功能和造价，但是造价增加较小，而功能增加很大。这些都是提高项目价值的方法，也都是在项目质量与造价综合控制需要遵照和采用的方法。运用这些方法综合考虑和安排项目质量与造价，即可确定出项目的经济质量指标和项目的合理造价指标，然后就可以合理的确定出与质量相符合的工程造价了。

项目时间管理技术在工程造价中的作用

项目的时间管理也即我们通常意义上的施工项目的进度、工期管理。对于现代建筑施工企业，项目经理比较注重施工项目的工期、进度，按时乃至提前完工是工程投标时的重要法宝。但项目经理往往忽略了在非正常合理的工期背后往往是工程成本的大幅度增加。项目造价和工期是一对基本的、紧密相关的要素。在项目管理中，“时间就是金钱”是一条颠扑不破的真理，因为工期的提前或拖后会给项目带来完全不同的后果。对于项目管理而言，不考虑工期对造价影响的造价管理方法和不计成本代价的工期管理方法都是不科学的。因此应该开展项目工期与造价的综合管理运用。这要求在制定和执行项目工期计划时不能单一地考虑项目的工期和进度，必须同时考虑项目的造价因素。

美国提出的“造价／工期控制系统规范”和已获价值管理方法是综合控制项目工期与造价的一种先进方法。美国著名的项目分析师Abba教授对已获价值变量的定义是：“已获价值就是将项目已完成的作业和未完成的作业的计划价值和实际价值进行比较所作出的一种度量。”由此可见已获价值变量实际是一个表示已完成作业(项目工期进度)价值大小的中间变量，其公式如下：已获价值(挣值EV)=实际完成作业量X已完成作业的预算造价，根据美国《项目管理体系指南PMBOK（2004）》：SV=EV—PV，其中：SV表示进度偏差；EV表示已获价值(挣值)，即在即定时间段内计划活动或WBS组件的实际完成工作的预算费用；PV表示计划价值，即到即定时间点前计划完成活动或WBS组件工作的预算费用。当SV>0表示进度提前，SV

篇10

［关键词］ 会计准则 盈余管理 研究透视

以我国2006年2月15日对39项新会计准则重新修订为契机，结合目前国内外上市公司盈余管理的新动向，将研究视角转向对以制约盈余管理的关键因素“会计准则”作为切入点来研究问题的论述日益引起会计学术界的浓厚兴趣，国内学者更是借此良机纷纷撰写论文，本文主要结合基于盈余管理治理下的会计准则制定建设与完善以及会计准则如何抑制盈余管理两者之间相互博弈的研究进行综述。

一、国内外有关盈余管理的基础理论框架的简单回顾

西方财务会计理论界自20世纪80年代开始致力于盈余管理的研究，盈余管理成为西方国家尤其是美国实证会计研究的重点之一。国外以美国斯考特（Scott，2000）、雪普（Schipper，1989）、Paul M.Healy & James M.Wahlen （Healy &Wahlen，1999）、戴维森等、Brown（Brown，1999）、Johnson（Johnson，1999）和Lynn Turner（Lynn Turner，2002）为代表的会计学者从不同视角给盈余管理下了定义，其中戴维森、Brown、Johnson及Lynn Turner均着眼于财务报告的披露与制定是否遵循会计准则出发来研究问题。而在我国以魏明海（魏明海，会计研究，2000）、吴江涛、顾兆峰、陈建歧、陆建桥、章永奎与刘峰等为代表的针对盈余管理所下定义众说纷纭，存在分歧。从国内外研究盈余管理定义中可看出，主要存在盈余管理是否是在会计准则允许范围内进行和盈余管理的手段是否应该包括诸如时间安排和交易构建等此类非会计方法这两方面的分歧；企业管理当局为了获取某种私人利益，在公认会计原则范围内运用会计方法和非会计方法，通过职业判断和规划交易手段干预对外报告过程的实现披露管理的行为活动构成了盈余管理。从经济收益观和信息观两个角度出发分析盈余管理行为存在的必然性，主要由于信息不对称、投资者的“功能锁定”现象以及会计准则本身的局限性等诸多原因；盈余管理行为的动机分析中，国外研究中主要存在契约动机、资本市场动机、迎合监管动机等的观点分析；国内研究中主要以企业自身物质利益的驱动、企业管理者的政治动机、企业筹措资金及纳税方面的动机、推卸责任及隐瞒违法行为等多种研究观点；当然，还有大量的文献研究盈余管理的方法等问题。

显然，上述有关盈余管理研究成果是非常的丰富，其研究主要针对盈余管理定义、存在的必然性及原因、动机及其方法，主要解决“盈余管理是什么”(概念)、“为什么”(动机)和“怎么样”(方法)等问题。

二、基于盈余管理治理的会计准则研究

从会计学术研究文献来看，学术界有广义与狭义的会计准则之说。为方便系统讨论和国际比较，大多学者在研究时将使用狭义的会计准则概念，将其限定为专门的财务会计信息规范，仅指我国强制执行的《企业会计准则》。由于会计准则涉及到诸多会计基本问题和矛盾，自会计准则产生以来，对性质讨论一直是理论界研究焦点，尚无定论。

1.从会计准则的特殊性质来看，会计准则是约束机制与剩余选择权适度平衡的结果

现代公司制两权分离，公司管理层必须通过递交财务报告来反映公司的财务状况和经营成果，以便与外部利害关系人进行商业沟通。为控制管理当局的逆向选择（隐藏信息）和道德风险（隐藏行动）问题，作为公认的会计准则，能为双方的沟通提供一种成本相对低廉且可信的手段。会计准则的约束对象主要是企业的会计行为。会计准则是会计信息生成的基础，具有一定的强制约束力，会计实务中企业需按会计准则的要求对每一交易或事项予以确认、计量、记录和报告，以保证会计信息的可靠性和相关性。从技术层面上，限制了管理当局利用信息不对称操纵会计信息的自由。由于会计准则并不直接约束相关利益主体的经济行为，而是通过为管理当局提供技术规范约束会计主体的会计行为，确保会计信息质量，故会计准则的约束程度是有限的，不能完全限制管理当局对会计信息的不规范处理。这就赋予管理当局在会计准则规范会计信息生成过程中的一定的灵活职业判断权利，即会计准则的剩余选择权。它是一种客观存在，是规范性(约束机制)与灵活性(剩余选择权)的适度平衡的结果。

2.有效结合主流观点，确保会计准则科学性和政策性的平衡统一

特别是随着制度经济学、博弈论等新兴学科的兴起，学者们对会计准则性质的探讨则更为丰富。代表观点主要有两种:(1)“技术观”。该观点从纯技术角度出发，认为会计准则是一种技术性的规范手段，是客观的约束机制，流行于会计准则产生之初。在这种观点指引下，建立一套科学完善一致的会计原则，并据此推导会计处理方法成为会计准则制定者的首要任务。他们相信只要借助科学、合理的理论和有效的准则制定程序，会计准则就可能达到完善，充分发挥理想的规范作用。但在会计实践中，“纯技术观”并未经受住考验，非但形成的概念(原则)框架未能达到完善和逻辑一致的地步，在具体准则制定时还多次出现背离框架要求的情况，可见会计准则并非完全中立。(2)“非技术观”。该观点具体从不同角度(会计准则的实施影响、制定过程、交易费用理论)有“经济后果观”、“政治程序观”和“公共契约观”等，其中“经济后果观”被广泛采用。在“纯技术观”无法合理解释特殊经济现象时，会计学者又从社会属性上重新思考会计准则的性质问题。会计准则具有经济后果（Stephen A.Zeff，1978，《经济后果学说的兴起》），由于经济后果的存在，会计准则不再是一种纯粹的技术手段。不同的准则将生成不同的会计信息，从而影响到不同主体的利益。

由上分析得知，对准则制定者而言，“技术观”由于目的明确，更容易指导会计准则制定，突显准则制定机构的独立性和权威性，但忽视经济后果的做法，会加大会计准则推行的难度，特别是招致企业管理当局的抵制和变通。相反，如果单纯采用“经济后果观”忽视会计准则概念框架和具体准则的构建，则可能造成会计处理方法的前后矛盾和会计实务的混乱。因此，有效结合“技术观”和“非技术观”，确保会计准则科学性和政策性的平衡统一，是各国准则制定方向。

三、会计准则对盈余管理影响研究综述

从我国这几年的会计准则对盈余管理影响研究分析来看，主要集中于对以下会计准则内容进行研究：

1.重要性水平的判断左右盈余管理

重要性水平受到环境和会计主体特征的影响，由于缺乏重要性水平的权威指南，为了便于操作，一些公司就凭借经验估计的方法制定了重要性水平的数量界限，这些界限一般用一定比例来表示。但是对重要性判断一旦数量化，就可能被利用，如中国上市公司净资产收益率的10%、6%现象。

2.利用资产减值准备影响盈余管理

由于减值准备计提过程中存在较大的选择和判断空间，使该政策在执行过程中成为某些公司盈余管理的工具。利用资产减值准备进行盈余管理的方式主要有追溯调整、巨额总额、减值计提不足和变更减值准备计提比例等。

3.利用关联方交易影响盈余管理

由于历史原因，在我国大多数上市公司都是由国有企业改制或从母公司优质资产中剥离而来，第一大股东对上市公司有绝对控制权，上市公司与母公司、子公司、联营公司等之间存在着天然联系。关联方之间进行的购销、资金往来、担保和抵押、租赁、特许权使用等交易活动普遍存在。由于信息不对称，外部投资者无从了解关联交易的真正目的和交易价格的公允性，所以，关联交易成为上市公司盈余管理的首选途径。关联购销、转移费用、托管经营、计收资金占用费、资产置换是我国上市公司利用关联交易调节利润的主要方式。

4.利用会计政策、会计估计变更和差错更正影响盈余管理

会计准则赋予企业在限定范围内再选择会计政策和估计的权利，但变更的影响要在会计报表附注中说明。会计政策、会计估计的变更成本与会计准则的约束程度、证券监管部门的监管程度、外部信息使用者的接受程度等密切相关。会计政策变更常见手法有：利用存货计价方法、坏帐核算方法、产品开发费核算方法、固定资产折旧方法、无形资产核算方法、长期投资核算方法等会计核算方法的选用或变更，来影响利润。会计准则明确规定企业会计估计变更采用未来适用法，不必追朔调整以前年度损益。故在会计估计大量存在，而它本身具有主观性情况下，该手段比会计政策变更容易加以利用。会计估计变更主要通过改变八项准备金计提比例方式进行盈余操控。

5.上市公司利用非经常性损益调节盈余管理

非经常性损益在利润表上会体现在“投资收益”、其他业务利润“、营业外收支”、“补贴收入”等会计科目，因此也是企业盈余组成部分。对正常经营企业而言，非经常性损益占利润总额的比重较小，主营业务收入是企业获利能力的主要来源，否则，企业将面临较大的投资风险和经营风险。但目前在我国上市公司中，非经常性损益已成为盈余管理的重要手段，有很多上市公司特别是ST公司在主营业务盈利甚微出现大额亏损时，往往刻意安排一些偶发性的非经常性损益摆脱困境或达到监管标准。目前，出售资产、股权转让、资产置换、债务重组、税收补贴、利息减免、政府补贴等是我国上市公司利用非经常性损益进行盈余管理的具体手段。而且大都在会计年度即将结束，企业主营业务获利能力明显不佳时采用。

6.利用或有事项与调节盈余管理

根据会计核算谨慎性原则和权责发生制的要求，应对企业经营过程中的预计负债以合理的估计金额在利润表上予以确认，或有损失作为期间费用抵减本年利润，对不符合确认条件的或有负债在会计报表附注中披露。该项规定本是为公正地反映企业的财务状况和经营成果，但它却成为很多上市公司调节盈余的有效手段。由于外界对或有事项的确认条件无从辨别合理性，因此，实际中一些上市公司可利用该原则控制如退货、贷款损失、保修费用等或有事项的负债金额，经营状况好时，多确认预计负债存储利润，而在利润不佳时，利用不合实际的假设，将本达到确认标准的负债转成或有负债不在利润表中确认。

7.利用潜亏资产挂账进行盈余管理

企业资产账户中，三年以上的应收账款，递延资产、待摊费用及待处理财产损失基本或很小可能给企业带来未来经济利益，属于不良潜亏资产。上市公司为提升当期经营业绩，都不愿处理潜亏资产的账户余额，长期挂帐的潜亏资产使上市公司资产质量大打折扣，利润水分极大。我国会计准则虽公布了资产减值准备，由于采用成本与市价孰低原则，上市公司对资产减值准备计提数额有绝对的主动权，完全可通过多提、少提或转回等手段影响当期损益。