文档管理论文

开篇：写作不仅是一种记录，更是一种创造，它让我们能够捕捉那些稍纵即逝的灵感，将它们永久地定格在纸上。下面是小编精心整理的12篇文档管理论文，希望这些内容能成为您创作过程中的良师益友，陪伴您不断探索和进步。

第1篇

相关热搜：项目管理  软件项目管理  项目管理工程

随着计算机硬件水平的不断提高，计算机软件的规模和复杂度也随之增加。软件项目中一些问题也应运而生：项目无法按期完成、项目合作方的工作难以协调、用户需求经常变动、工作质量难以保证。为了避免愈来愈多的“项目黑洞”给企业带来的损失，各个软件企业都将软件项目管理引入到开发活动中来，对开发实行有效的管理。

一、软件项目引入项目管理的必要性软件项目即软件开发项目，是一个用计算机程序和相关技术文档把思想表达出来的过程。软件项目所涉及到的内容大多是无形的东西，既看不到质，也看不到量，从而使软件项目的管理难度加大。

随着信息技术的飞速发展，软件产品的规模也越来越大，完全由个人完成一个软件项目几乎是不可能的，软件项目的开发都是以项目组为单位完成的，这必然涉及到对软件项目的管理。一个软件项目的成败，不在于其项目组的技术人员的技术水平，而在于是否采用合适的管理方式。好的管理方式不一定能使项目完全成功，但是一个不合适的管理模式肯定会导致软件项目的失败。

项目管理是指在一定资源如时间、资金、人力和设备等约束条件下，对一个有既定目标(质量、投资、进度)要求的任务进行计划和控制的过程。项目管理以系统的观点来对一个项目进行全程的控制，同样也可以用此来完成对软件项目的管理，而且由于软件项目的特殊性，项目管理在应用于软件项目的管理时，也会有其独特的一面。在项目管理应用于软件项目的管理方面，已经有了不少成功的案例。

二、影响软件项目管理的关键要素

(一)可靠的软件需求

软件需求是软件项目的根本所在，需求不明确，工作就没有方向，因此影响软件项目的第一个因素就是项目要有一个可靠的需求。软件需求应当是项目有关的人员一致同意的、清楚的、完整的、详细的、可实现的和可测试的。

需求的确定，开发者应该认真听取用户的意见，并进行记录，反复和用户沟通，不能想当然地把自己的想象当作用户的需求。在确定用户需求的时候，应该尽可能从专业的角度发掘用户的潜在需求，以达到最大限度地满足用户的目标，只有这样才能可能开发有价值的软件项目。一定要强调的是，在项目开始以后，应该尽最大可能不更改需求，要与用户进行很好地沟通，以确保开发工作能按照需求进行，也就是说，只有有了可靠的需求，项目开发才有基本保证。

(二)可行的项目计划

凡事预则立，不预则废。这里的预就是指计划。明确了项目目标，还必须有一个切实可行的计划。软件项目计划的目的是为完成软件工程和管理软件项目。制定合理的计划，它包括以下步骤:估计软件

产品规模及所需的资源，制定时间表，鉴别和评估软件风险和协商约定，而且要标志出几个阶段性的里程碑，这是极为关键的一点。对于软件企业来说，一个可行的计划的重要性是不言而喻的。但是在一些单位，很多人都听过这样的一句话一“计划赶不上变化”。这种变化对某些行业来说也许并不会产生太大的影响，但是对于软件企业来说，却会对软件产品的保证带来严重的负面影响。造成这种现象的原因很多，主要是因为对计划的重视程度不够，计划过于笼统、粗糙，导致可执行性差，再加上一些人为因素的影响，必然会产生一些不良的影响。因此，要想成功进行项目管理，就要对计划高度重视，周密制定，严格执行。只有严格进行计划，才能使项目管理得以成功实施。

(三）规范的操作流程

软件开发流程非常规范和系统化，其流程的可执行性很高，并且能在实践过程中不断改进。流程是保证项目成功的一个关键因素。由优秀的项目成员按照规范的操作流程进行项目开发，才能最大限度地保证项目的成功。一个规范的流程可以保证不是很出色的人开发出来的，产品不至于太差，但不能保证做出精品，而一个不规范的流程很难做出好的产品。

通过流程可以实现一种规范化、流水线、工业化的软件，从而最终实现成功的项目管理。对于软件项目的每一个阶段均要做出工作计划并交有关部门监督执行，在阶段结束之后，要对该阶段的工作活动进行评价，并对后续阶段的时间、人员、资金方面的需求做出估计。每个阶段的工作成果需经项目的技术管理部门审查合格后，方能开始下一阶段的工作。

(四）有效的人员沟通

软件项目的实施对人的依赖性比其他行业更为突出，它是一项知识性极强的工作，因此对人的管理相当复杂，如何加强人员之间的有效沟通，是软件项目成功的一个非常关键的因素。这里的沟通包括两个方面：一个是软件项目组开发人员与用户的沟通;另一个是软件项目组内人员的沟通。只有对用户的需求非常明确，软件项目的实施才有一个坚实的基础。对用户的需求不明确，开发出的软件根本没法用，所以这样的项目在一开始就是失败的。组内人员的沟通有助于在明确了用户需求后，使得项目能按计划进展，最后才有可能完成该软件项目。

没有最好的沟通方式，只有最有效的沟通。因此沟通因人因事而采用不同的沟通方式，才可以达到良好的效果。有时项目组需要和用户沟通，面谈是一种较为花时间的方式，而用户方常常以忙来说明自己没有时间，这时候可以采用电话沟通的方式，这样马上就可以得到答复。有时可以将项目进展情况用邮件的方式发给对方，使得软件开发的工作也成为用户的一种工作，只有这样才能正确把握用户的真正需求，才能使得开发出的软件真正是满足用户需求的软件。而在内部的沟通形式就可以多样，如定期的项目沟通会议、项目进展文档等。

总之，只有加强沟通，才能使得软件项目顺利实施，沟通是成功软件项目管理的很重要的因素。

(五)健全的项目文档

软件项目的文档在整个生命周期中的地位和作用尤为重要，无论怎样强调都不过分。文档作为软件产品的主要形式，集中体现了软件人员的劳动成果，没有文档就称不上软件。但是实际情况是许多软件开发人员从一开始就不注重文档的写作，尤其是当软件项目的工期又很紧张时，在没有任何文档或只有少量文档的情况下就开始了具体的开发工作。有的写了文档，但是在开发过程中需求发生了变更，也没有及时在文档中体现出来，使得过一段时间后开发者对所开发的内容也记得不清了，当项目出现问题时，没有有效的文档可查，致使软件项目延期或失败。

软件开发过程中各阶段的文档不健全，往往在项目接近尾声时为了验收才补写文档。最常见的是有系统分析与概要设计文档，但是没有详细设计文档，在程序开发过程中，开发人员往往最大限度地发挥着自己高超的编程技巧，以至于在后期维护时，因为没有详细的设计文档，给项目的后期维护带来困难。

编写文档的工作量是很大的。有时会占整个项目的40%,所以文档的编写会花费大量的时间和精力，但是有了好的文档，会对后期的开发工作带来很多的便利。健全的文档管理是软件项目成功实施的一个重要因素。

三、软件项目管理的方法

软件项目管理有阶段化管理，量化管理和优化管理三个层面。

(―)阶段化管理

阶段化管理指的是从立项之初直到系统运行维护的全过程，将项目分成小的阶段。比如，通常分为问题定义、可行性研究、需求分析、总体设计、详细设计、编码、狈彳试和维护等几个阶段。每个阶段都有明确的目标和成果验收，以及必要的监督回馈，这样就能够很好地减少项目负责人和客户的分歧，增加项目风险的可控性。在项目负责人提交给客户的需求分析和初始报告里，就已经把每个阶段要完成的工作，可出的成果，甚至具体到有多少个界面，都能清晰的描述出来。这样，在每个阶段完成后，客户和项目负责人都能够比较清楚地了解项目的进展、完成情况，以及客户对项目完成部分的满意程度。同时，也方便进行项目组成员的绩效评估。

(二)量化管理

把项目的方方面面尽可能地进行数量化，做到责任清楚。给客户做软件，时常碰到这种问题：某阶段成果A(比如说，包括A1、A2、A3等不同部分）出来了，客户看了以后，可能认为A1完全符合要求，A2根本就不对，A3虽然有毛病但改改还可用，等等。那么，这其中的问题出在哪里？责任该由谁负?责任又有多大呢?为此，必须把各种目标、投入、成果等分类量化。比如，用明确的模块或子系统表达客户需求，精确计算A1、A2、A3每部分花费人工、物力、财力等等。把各种量化指标存入数据库，就能够轻而易举地解决上述的问题了。而且，每个阶段都有清晰的量化管理，也非常有利于整个项目进程的推进。

(三）优化管理

优化管理就是分析项目每部分所蕴涵的知识、经验和教训，更好地发扬项目进程中的经验，吸取教训，在全公司传播有益的知识。再如前面例子，通过分析发现A1部分的领头人能力强，就可以让他以后多带几个人，使他的知识和经验更好地发挥成效。A2、A3部分为什么不成功？是客户的需求没提清楚，是理解的错误，还是有设计的问题？通过这些分析后，有利于进一步优化项目管理。

四、软件项目管理过程中的几个误区

(一)对需求的修改是必然的，具体细节可在以后的开发过程中填充

在软件项目的需求分析阶段，软件开发人员和项目负责人通常认为开发方与客户方在各种问题的基本轮廓上达成一致即可，具体细节可以在以后填充。理由是无论开始时多么细致，以后对需求的修改几乎是必然的。但在实际操作中，由于需求阶段对问题的描述不够细致，导致后来预算超支或者时间进度达不到要求的情况并不少见。正确的做法应该是:在项目需求分析阶段，双方必须全面地、尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准。在需求分析结束以后，双方还要建立可以直接联系的渠道，以便尽早地对需求变动进行沟通。

(二)软件项目的需求可以持续不断地改变，并且可以很容易地得以实现

在需求分析阶段，还有一个经常出现的问题，就是认为软件项目的需求可以持续不断地改变，而且这些改变可以很容易地实现。在具体实际中由于种种原因，客户方很难在需求分析阶段就能全面而准确地描述所有问题。随着开发进度的推进，往往会有一些需求的改变。现代软件工程理论也利用软件的灵活性特点通过各种方式来适应这种情况。实践表明:随着开发进度的推进，实现软件需求更改所需要的代价呈指数形式增长。假定在需求分析阶段实现需求更改要花费1倍的代价，那么，在系统设计和编码阶段，则需要花费1.5~6倍的代价；在系统测试阶段需要花费10~20倍的代价，在软件版本以后，甚至要花费60~100倍的代价。由此可见，在项目开展过程中，软件需求的改变应当尽早提出。这样才能做到既节省开销，又较容易实现。

(三)在系统详细设计阶段，必须写出所有程序的伪码

在详细设计阶段，起初为了便于代码的维护修改，要求文档工作应该做到写出所有程序的伪码。伪码的最大作用是对程序的算法流程进行描述，便于人们深入了解程序的功能和实现过程。因此，伪码在一定程度上的确有利于对程序代码的维护和修改。但在实际工作中，这种做法却很难实施。为了保证项目文档和程序代码的一一对应关系，维护程序代码的同时也需要对项目文档进行维护。伪码和程序代码非常接近，对伪码进行维护，就相当于进行了加倍的程序代码维护。为了赶进度，这种方法在实践中往往会流于形式。所以，切合实际的方式应该是对一般的程序文档做到程序流程图即可，对涉及了较复杂算法的程序才需要伪码。

(四)编码阶段是整个软件项目中最重要的阶段

在软件开发阶段，项目负责人往往认为软件程序主要由代码组成，因此编码阶段是整个软件项目中最重要的阶段，应该给予大量时间，集中主要资源。与编码阶段相比，需求分析、详细设计以及测试时间较少，容易造成测试不完全及软件上线后的先天不足，给今后的工作造成被动。如今，由于软件的规模和复杂度都较以前有较大的增加，再加上半自动化软件代码开发平台的出现，现代软件项目管理的中心已经发生了转移一不是着重编码阶段，而是着重系统总体/详细设计阶段。一般，系统总体/详细设计阶段应占整个软件开发时间的一半。这样才能充分考虑系统将会出现的各种问题及其解决办法，为以后的编码、测试工作争取主动。

(五)软件所有的内部测试工作应由测试人员完成

在软件测试阶段，由于在项目人员配置中设置了专门的测试人员，人们通常认为软件所有的内部测试工作应该由测试人员完成。但这种做法往往会造成测试不全面，软件交付后经常出现问题的情况。在实际工作中，由于使用“白盒法”对测试人员各方面素质有着较高的要求，进行程序测试时，测试人员总是优先使用“黑盒法'狈j试没有通过才会考虑对程序代码进行“白盒法”测试。显然，这种对“白盒法，有意无意的“逃避”，对软件的可靠性和稳定性构成了威胁。要解决这个问题，一方面需要提高对测试人员的要求;另一方面也需要让程序员完成部分的“白盒法”测试。

(六)软件项目管理只是相关技术部门的事，与公司其他部门无关

在竞争日益激烈的今天，软件项目规模大、复杂度高，而且时间要求紧迫。要想提高公司的软件项目管理水平，就需要提高公司的整体参与意识，需要公司各个部门协同作战。例如，需要会计部门协助进行项目预算、财务管理和费用控制;需要研究部门(技术委员会)指派专家协助进行各种风险评估，提供技术指导;需要后勤部门提供各种保障。

(七)开发进度滞后时，可以聘请更多的程序员加入到开发团队中，通过增加人力资源追赶开发进度

如今，在注重团队开发的时代，开发方应该根据目前的软件项目管理水平慎重考虑这个做法。如果新加入的程序员对目前软件项目的应用行业有一定了角解并且可以很快地适应开发方的项目管理方式、软件开发风格、团队协作氛围，那么“新人”的加入是有益的。否则，可能会“好心却办了坏事”。因为尽管新人的个人能力很高，但为了使其与大家一起协同工作，开发团队不得不分出人手对新人进行与项目有关的技术、业务培训。更重要，也是难度最大的是，还要引导新人融入到整个开发团队中。这可能需要花费开发团队大量的时间和精力，很有可能使项目进度更慢。