项目管理人员继续教育论文

浅谈软件项目中的需求管理

曾创能－332070063

20xx年4月17日

摘要：

需求管理在软件开发项目管理中起着至关重要的作用。本人以曾作为项目经理参与的国内某期货交易所核心结算业务系统（下称“结算系统”）的项目为例，阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。

关键词：

项目管理 需求管理 软件项目开发

引言：

在如今软件开发领域，尽管各种开发技术越来越先进，可利用的软件开发工具和方法也越来越多，但仍然有相当比例的软件项目失败。究其原因，常常是由于在项目开始阶段没有正确地理解、确定和定义需求，或者是由于在项目进展过程中没有正确地管理需求。

众所周知，项目管理的三要求为TQC（时间、质量、成本）。我个人认为，在软件开发项目中，要使TQC目标最大化，范围管理中的需求管理有着至关重要的作用，这与当今中国软件开发的特征有很大关系。当前中国软件开发的领域集中在应用开发领域，多以开发业务管理系统为主。而中国是新型经济体，在企业管理等领域处于逐步摸索、不断变更，以适应国际化竞争的转型初期。在此转型阶段，各企业的管理模式、业务管理方法等有很大不同，且自身也处于不断否定自己的管理、不断变更自己的管理方法和调整业务模式之中。作为软件项目开发承接方，必须适应中国这一各企业“需求各不相同”、“需求多变”的国情。

本人以曾作为项目经理参与的国内某期货交易所核心结算业务系统（下称“结算系统”）的项目为例，阐述需求管理的流程和自己摸索出的一些需求管理方法和心得。

第1页 共7页

项目管理人员继续教育论文

软件需求管理的流程：

软件需求是软件项目开发工作的一个重要源头。需求管理一般由需求分析师和项目经理共同完成的。需求分析师尽可能准确的理解和获取客户需求及潜在需求，编写《需求规格说明书》，而项目经理则需通过加强需求管理，有效的防范和减少不必要的需求变更。按我多年项目开发管理经验，我个人认为，需求阶段准备把握了各类需求（功能、非功能、潜在需求等）并有效地管理需求，项目也就已经成功了一半。

在我负责结算系统时，按需求工程的方法论，将需求管理的流程可划分为如下几部分：

? 制定需求管理计划

需求管理计划往往被软件项目管理人员所忽视，很多项目经理在开发项目时，一上来就是让需求分析师跟客户谈需求去，这样做会导致需求工作的盲目性甚至可能让需求分析师无所适从。

在本项目启动时，我通过如下步骤制定需求管理计划：

1、 确定需求沟通机制；

2、 确定需求变更管理办法；

3、 确定需求跟踪方法；

4、 确定需求管理涉及的干系人，并明确职责；

5、 明确需求管理工具；

6、 编写需求管理计划。

? 需求调研

需求调研是需求分析师一项非常重要的工作。在本项目中，我确定了对期货核心结算业务吃得很透，具有5年以上相关经验的技术人员作为需求分析师负责与客户的需求访谈和调研，并成立需求组，在需求组中还配备了软件设计师和软件测试工程师旁听。我认为，在需求阶段，虽然以需求分析师为主，但软件设计师和软件测试工程师参与非常重要，他们可以了解第一手的需求信息。

? 需求分析和定义

针对获取的用户需求进行分析和整理，并规格化，形成需求规格说明书。针对每项功能需求，定义需求的重要性、优先级、实现的难易程度。

第2页 共7页

项目管理人员继续教育论文

? 需求确认

针对需求规格说明，和客户业务、技术人员起来，通过讲解的方式，确认需求，并最终让客户方需求接口负责人签字确认。

? 管理需求变更

管理需求变更是需求管理中非常重要的一环，也是经验不足的项目经理容易忽视的地方。

在软件项目中，没有不变的需求，不能指望在需求阶段一蹴而就，就此确定下来。随着设计和开发的深入，有些原定的需求本来就可能显得不合理；加之时间的推移会伴随着客户业务的变化和发展，需求变更是不可避免的。管理需求变更，是项目成功的关键因素。

在结算系统项目中，我采用如下方式对需求变更进行管理：

1、需求变更申请需书面提出，并由客户方需求接口人签字认可。当我方收到需求变更申请时，先由项目组经理与客户方需求接口人协商，协商未果，由包括双方领导在内组成的CCB审核，是否接受变更；

2、CCB审核确定接受的需求变更，录入需求管理工具TD，并通知相关方（包括设计组、开发组、测试组），评估影响范围及工作量；

3、针对需求变更，进行相应的设计和开发的调整；

4、验证需求变更是否完成。

? 需求跟踪

针对需求列表，定期对需求进展进行跟踪。

需求跟踪是指跟踪一个需求从定义、实现到验证的全过程，包括编制每个需求同系统各类元素之间的联系文档，这些元素包括其他类型的需求、体系结构、其他设计组件或模块、源代码模块、测试用例、帮助文件等。需求跟踪的目的是建立与维护“需求-设计-编码-测试”之间的一致性，确保所有的工作成果符合用户需求。

如果采用手工操作方式，对需求进行跟踪，将是一个非常繁重的体力活。在本项目中，我们应用TD管理工具，该工具把需求定义、设计（每项设计关联一个或多个需求点）、开发（建立开发模块与需求点的关联矩阵）、测试（每个测试用例关联一个或多个需求点）有机的联系在一起。

第3页 共7页

项目管理人员继续教育论文

我负责专人（本项目以系统集成人员兼职）来定期扫描和跟踪需求的进展，可以让我随时了解项目的进展以及离完全符合客户所有需求还有多远的距离。 软件需求管理的心得体会

? 要充分识别客户的需求和潜在需求

客户的需求各种各样，纷繁复杂，我们要从中将这些需求进行分类。有些需求是现有的业务规则和功能、有些是对现有工作的抱怨、有些是客户根据自己理解设想的业务规则和功能。针对各类需求，我们要有不同的对待方法，尤其要慎重对待对现有工作抱怨的需求，这类客户他对现实不满，但又没有想法设想一套新的业务规则和功能，这时候需要我们充分理解，抓住客户抱怨的本质，通过自身对客户业务的理解，帮助客户设计一套能解决他的抱怨的新的规则和功能。

在本项目开发中，我们有重点地针对客户抱怨较大或较多的需求，内部召集相关人员充分挖掘客户的需求和潜在需求，并运用快速开发工具AxureRP-Pro搭建系统原型，以直观易懂的界面作为交流工具，充分讨论其是否满足客户的真实需求。

? 需求确认非常重要

在以前的项目中，经常在项目验收时存在客户反悔、扯皮的事情，而项目开发时需求文档等各类开发文档却都很齐全。究其原因，跟需求没有正式确认有很大关系。有些项目经理或需求分析人员抱怨项目时间紧，客户需求人员没空，所以免了需求确认这一环节。但我认为这一环节一定不能免。哪怕项目组再忙，客户再忙，一定要想办法让客户书面确认需求并签字。在本项目中，需求分析完成后，我通过给客户逐步讲解需求，同时逐步让客户对需求进行确认。在客户需求变更后，我通过会议纪要、需求变更单等让客户确认签字以保护当前协商的成果。

? 需求双方都要务实

需要双方领导层达成共识，需求是无止境的，项目成功才是关键的。在本项目初期，我请求我方领导和客户方领导多次沟通，定下保证实现项目主要需求，一定要保障项目成功的基调，并为此做了一些物质上的一些激励，即我方拿出项目合同额10%的钱，激励由甲、乙双方共同实际参与此项目的项目人员，当然包括客户方的需求人员，如果项目按时上线，实现所有主要的日常业务功能，那么就可以参与分享此项目奖，否则该项目奖池归零。

第4页 共7页

项目管理人员继续教育论文

? 设计实现别让需求扩大化

追求完美是技术人员的通病。在校期间，课程设计等计算机实现方面，学生追求算法完美可以认为是一种美德，但项目是受多种因素约束的，我们不可能实现完美无缺的项目。我们的设计人员一定不要把需求放大，放到一个更完美，适应性更强的模型中，这样无形中扩大了项目范围，加大了项目的实现成本，对项目对个人都是有害的。我们在提炼客户需求的时候，可以采用“往前跨半步”的方式，满足客户现在以最近的将来可能需要的需求以满足系统的灵活性，切忌追求更加抽象化，更加完美，盲目扩大需求范围，要知道，简单是美，适用的才是最好的。

? 严格规范需求变更控制流程

项目开发中，需求变更是永恒的主题，我们要采取恰当的措施，正视这个问题。以

前项目开发过程中，由于客户方相关人单方面跟项目某一个开发人员指出说原理解的需求不正确，需重新拟定，导致后来需求变更泛滥，项目无法收尾的惨剧。

在本项目中，由双方领导层、双方项目经理等组成变更控制委员会CCB，并要求

开发人员不得私自答应或接受客户某一个需求提出人员的需求变更，所有变更必须以客户方需求接口人汇总整理后，以书面方式提出向开发方项目经理申请，开发方项目经理可以与客户方需求接口人讨论是否接受和拒绝需求变更，当不能达成一致时，交由CCB，由CCB决定是否变更，确有变更的，录入到变更控制系统TD，并通知各方实施变更。通过这套机制，客户要实现需求变更不是那么随便，有很多人会参与监督这一变更过程，客户也害怕自己的形象受损，有效杜绝了客户需求提出人员对需求的朝令夕改和源源不断提出的可有可无的需求的情况发生。

? 别忽视需求跟踪

不要等到UAT时，才发现需求未实现，或实现不全，这样会让验收工作苦笑不得，影响在客户方的形象。在本项目中，我委派系统集成人员兼做定期的需求跟踪，每个月一次，以检查正在进行的设计和开发，其功能点是否符合对应的需求。

? 抓住客户方需求接口人

在项目启动初期，一定要要求客户规定唯一一个需求接口人，这个接口人就是项目开发方的教练（coach）。在需求阶段，需求接口人需始终跟需求组一起，跟客户的各个部门一起讨论客户需求，所有部门的需求需经需求接口人同意。这

第5页 共7页

项目管理人员继续教育论文

样做好处很多，客户方需求接口人起着沟通项目甲乙双方桥梁的作用，甚至算半个乙方（项目开发方）的人。在讨论和汇总客户各部门、各人员的需求时，客户方需求接口人可以帮项目组过滤一些无用或很次要的需求，也可以协调客户部门各人员需求的冲突，更可以协调项目甲、乙双方的需求理解偏差和冲突。客户方需求接口人还可以通过全程参与项目需求管理，了解更多以前没有机会了解的业务，提升自身业务能力，这也是他（她）所乐见的。在项目验收时，客户方需求接口人可以根据自身全程参与，更深入地理解系统需求的重点，在验收或试用阶段如果有实际操作人员有反悔的情况，他（她）可以以更深入地对业务和对系统的理解来调停。

? 苦练内功，适当引导客户需求

有很多时候，项目组开发人员抱怨客户需求太霸道，实现起来很别扭。但究其原因，发现是由于你别客户牵着鼻子走，客户说怎样就怎样，但客户又不是计算机设计专家，导致项目开发人员抱怨不断。我们在项目开发过程中，一定先要虚心听，且要多问几个为什么，然后在自己公司找相关业务专家、行业顾问多咨询，以更简洁、更合理的模型来满足客户需求。如果自己公司缺乏行业经验，一定要聘请业务专家、行业顾问等专业人士，通过行业知识和业务的培训和专业指导等方式，提高项目团队特别是需求分析师对客户需求的把握能力。此外，还可以对客户方业务人员提供免费的计算机和软件开发等基础支持的培训，以便引导客户需求提出人员以更接近技术人员的方式提出合理的需求。

结尾

以上是我在负责国内某期货交易所的结算系统项目中，对需求管理流程的一些认识和心得体会，供广大同行交流，希望能抛砖引玉，为我国信息系统项目管理水平提高做点应有的贡献。

--------------------

第6页 共7页

项目管理人员继续教育论文

参考文献：

《信息系统项目管理师教程（第2版）》

作者简介：

曾创能，35岁，上海某软件公司开发总监，从事银行、证券、期货领域软件项目开发十余年，具有多年的信息系统架构设计和项目管理经验，在项目管理、部门建设方面有许多独到之处，有十余个负责的金融项目曾获得过行业大奖。

第7页 共7页

 

第二篇：有效的软件质量管理

有效的软件质量管理

计算机室 张立霞

摘要：本文简要介绍如何实现有效的软件质量管理，以提高软件产品质量，达到用户满意，并对质量管理所涉及的软件质量计划编制、质量保证和质量控制三个过程域进行阐述。 关键词：质量管理；质量计划；质量保证；质量控制 一、引言

随着社会信息化水平的不断提高，用户对软件功能、性能、可靠性以及可扩展性的要求迅速提高,我们所开发的软件项目的规模和复杂度日益增大,软件产品中越来越多的质量问题也随之暴露出来。 在市场竞争日益激烈的情况下,如何提高软件产品的质量,增强产品的市场竞争力,已经成为关系到软件企业是否能够健康持续发展的一个关键因素。

在实际的项目质量管理中，质量管理可以分解为质量计划编制、质量保证和质量控制三个过程。质量计划是针对质量提升及质量保证这两项而制定的，制定原则是主要结合公司的质量方针，产品描述以及质量标准和规则通过收益、成本分析和流程设计等工具制定出来实施方略，其内容全面反应用户的要求，为质量小组成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。质量保证则是贯穿整个项目全生命周期的有计划和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。质量控制是对阶段性的成果进行检测、验证，为质量保证提供参考依据，它是一个PDCA循环过程。质量保证与质量控制这两个过程通常相互作用，在实际应用中还会发生交叉。

二 质量管理责任分配

我们公司在开发项目上按照规范化软件的生产方式进行生产，在生产流程上采用

ISO9000的标准进行。每个项目除配备了项目开发所需角色外，还专门配备了配置管理小组、测试小组和质量保证小组确保质量管理的实施，下面针对这三种角色进行说明：

1、 配置管理小组职责 配置管理小组依据配置管理规程，结合ISO 9000其它各项支持活动,保证在质量体系的各生存周期活动中全面实施有效的质量管理。其主要职责包括： 完善各部门发送需要存档和进行版本控制的代码、文档（包括外来文件）和阶段性成果； 对代码、文档等进行单向出入的控制； 对所有存档的文档进行版本控制； 提供文档规范，并传达到开发组中，促进项目开发小组之间进行更好的接口和沟通，保证开发过程中关键路径不被阻塞而延滞的前提。

测试小组职责

测试小组作为质量控制的主要手段，负责软件的测试设计和执行工作。如同软件开发一样，测试在执行之前，同样需要进行测试计划和测试策略的设计，通常情况下测试可以分为如下几种类型，如：正确性测试、功能性测试、性能测试、安全测试和系统测试等。而这些测试均需要在测试计划和测试策略中进行描述用以指导测试小组成员进行测试用例编写和测试执行。程序员在交给测试人员之前是进行过一定的单元测试，确保程序编译、运行正确。

测试人员根据详细设计的文档对软件要实现的功能进行一一测试，保证软件的执行正确的实现设计要求，在此也只证明了软件正确的反映了设计思想，但是否真正反映了用户的需求仍需要进一步的功能性测试。 测试人员只有根据软件需求规格说明书所提及的功能进行检测，才能确保项目组开发的软件产品满足用户需求。在正确性测试完成之后，需要测试的是软件的性能，软件的性能在本项目中占有重要的地位，性能要求有可能改变软件的设计，为避免造成软件的后期返工，测试在性能上需要较大的侧重。如果有必要的话，测试小组还需要做安全测试，以确保系统使用安全可靠。

2、 质量保证小组职责

质量保证小组作为质量保证的实施小组，主要职责是保证软件透明开发的主要环节。在项目开发的过程中几乎所有的部门都与质量保证小组有关。质量保证小组对项目经理提供项目进度与项目真正开发时的差异报告，提出差异原因和改进方法。 在项目进度被延滞或质量保证小组认为某阶段开发质量有问题时，提请项目经理、项目负责人等必要的相关人员举行质量会议。解决当前存在的和潜在的问题。质量保证是建立在文档的复审基础之上，因而文档版本的控制，特别是软件配置管理，直接影响软件质量保证的影响力和力度。质量保证小组的检测范围包括：系统分析人员是否正确的反映了用户的需

求； 软件执行体是否正确的实现了分析人员的设计思想； 测试人员是否进行了较为彻底的和全面的测试； 配置管理员是否对文档的规范化进行的比较彻底，版本控制是否有效。

三 质量管理实施

有了良好的资源配备，又如何在项目全生命周期内实施质量保证，让我们从以下几个方面来看质量保证的实施过程：

1、 项目进度的质量保证

项目进度是项目进行是否顺利的最直观表现。显然在项目开始之前，项目开发计划是必须的。如果项目开发计划的制定的是完全合理的，那项目进度也就真正表达了项目与最终的交付使用之间的距离，然而要制定完全合理的项目开发计划几乎不太可能。可见要保证项目进度，首先要保证项目开发计划尽可能合理。 项目计划的合理程度与项目计划制定者从事类似规模和类似业务的项目的经验有直接关系，通过经验往往能够预见潜在的阻碍，这样要求项目计划制定者需要集众人之力来完善计划。

当项目计划制定初期，由质量保证小组组织召开的项目计划评审会，邀请公司技术专家、用户以及项目组小组成员一起讨论项目计划的可行性，会议通常采用头脑风暴法，各抒己见，会后由指定的记录员形成质量记录，发送给相关人员，对其计划中不合理的地方进行修改完善，并由质量保证人员对其结果跟踪，以确保项目计划完整性、可行性，完善后的计划交由配置管理人员进行版本控制。

然而在计划实施过程中，计划不是“固定化”。常有人道，“计划赶不上变化”，但“要跟上变化”。项目计划以里程碑为界限，将整个开发周期划分为若干阶段。根据里程碑的完成情况，适当的调整每一个较小的阶段的任务量和完成的任务时间，这种方式非常有利于整个项目计划的动态调整。也利于项目质量保证的实施。

实际运作中，当质保小组发现计划实施的差异后，报告项目经理，由项目经理组织负责对计划进行周期性维护，对于已经变动的计划由质保小组协助配置管理小组完成版本控制。本公司已经开发湖南移动的集中客服系统，开发中的子项目多达六个，历时十个月，目前多数项目已经开发完毕，系统正在试运行阶段，项目金额数千万元。在这样的项目中，从管理者到开发人员到测试人员都积累了较为丰富的经验，特别是项目开发计划的制定，和项目进度的控制。

2、项目开发各阶段的质量保证

a、需求分析

需求分析是开发人员对系统需要做什么和如何做的定义过程。从系统分析的经验来看，这个过程往往是个循序渐进的过程，一次性对系统形成完整的认识是困难的。只有不断地和客户

领域专家进行交流确认，方能逐步明了用户的需求。从系统开发的过程得知，系统分析时犯下的错误，会在接下来的阶段被成倍的放大，越是在开发的后期，纠正分析时犯下的错误所花费的代价越是昂贵，也越发影响系统的工期和系统的质量。

解决系统分析错误的方法我们公司通常采用邀请用户参与进行需求评定，然后对其用户的意见由质保成员跟踪检测是否纳入需求规格说明书，同时与用户签字确认形成需求基线，交由配置管理员放入配置管理库。

虽然尽早的邀请用户参与，仍然避免不了项目进行中用户的需求变更请求。对于开发过程存在的需求变动，我们要求用户填写变更申请单发送给项目配置管理员，在通过配置配置员转交质保小组，负责组织专家小组和项目组成员一起讨论实施变更的可行性及实施后所带来的影响，小的变更则直接记录入变更记录原因分析项和风险项栏，大的变更则需要形成正式的变更报告，无论那种变更都需要对相应的文档实施同步变更（包括需求规格说明书、详细设计文、安装手册、操作手册等）。但是对于无法实现或是变更会带来巨大的影响而将导致进度的延期，这时，我们将变更报告提交给用户或邀请用户进行协调会议，讨论变更取舍问题或是项目进度变更问题。

决定变更之后，由项目经理组织实施变更，测试人员检测变更结果，而质保小组成员监督变更实施过程并协助配置管理员对变更后的成果物进行版本控制。变更实施完后，上线前还需要指定人员协助用户一同测试并由用户签字后同意方可上线。

b、系统设计

优良的体系结构应当具备可扩展性和可配置性，而好的体系结构则需要好的设计方法，自然设计选型成为了系统设计首要的工作，究竟是采用哪种设计方法好呢？

对于设计选型不能一概而论，需要针对项目的结构、项目的特征和用户的需求来分析，同样也要考虑到参与项目小组成员的素质，如果其中大部分都没有从事过面向对象的设计且项目进对紧迫，这样没有多余的时间来培训小组成员来掌握面向对象的设计方法，尽管众所周知面向对象设计方法的优势，我们还是不如采用面向过程的方式（除用户指定开发设计方式外）可以减少项目承担的技术风险。

我们公司有过一个项目，用户指定需要采用面向对象分析、设计和开发，且开发周期短，在无赖的情况下，项目小组只能选用面向对象的软件开发过程，由于项目小组很少从事过面向对象的开发，经验缺乏，导致项目上马后项目进度延误，项目没有达到预期的效果。

针对此次开发，我们分析其原因，发现小组成员在开发过程中对于新技术互相交流少，各自有各自的理解和想法，造成理解上的不一致性，导致工作重复性高，滞后项目进度。建议解决方法是项目组成员采用集中办公，分块学习，学习的成果马上向项目相关人员发布，再由配置管理员对其发布的文档进行整理、规类放入配置库以供大家共享。这样方便大家的

互相学习，减少重复的工作。在这次开发中我们公司从管理人员、设计人员到开发人员都汲取了很多教训，同时经过此次项目的开发，小组成员也积累了丰富的面向对象的开发经验。

除设计选型，还有一个容易被忽视的问题，就是公共类开发。公共类开发可以减少工作中的重复工作，降低开发成本。这要求我们再设计阶段通过对用户需求的仔细研究，尽可能的识别出公共类，并进行定义指定专人负责设计通知其它设计人员，以减少重复工作。对于项目组提供的设计文档，由质保小组组织技术专家、项目组设计人员、开发人员和测试人员对其设计文档的评审，检测设计文档对其下一阶段工作的可行性，及时发现设计中可能存在的错误，降低项目开发风险，同时确保设计文档能为开发人员、测试人员提供切实的指导。对于可复用的设计进行提取作为公共库设计和开发，提供项目组或整个公司重用。最后交由配置管理员进行设计文档的版本控制。

c、实现

实现也就是代码的生产过程。这里不仅包括代码的产生，同时也包括测试用例的产生。针对上一阶段提供详细设计，程序员开始编码并且调试程序，测试人员则根据设计进行测试用例的设计，设计出来的用例需要得到项目组成员认可由项目经理审核通过才能进入配置库。同时程序员调试完程序提交测试人员进行程序正确性检测。

d、文档管理

文档维护主要是配置管理小组的工作。文档从用途上分主要分为内部文档和外部文档。 内部文档包括： 项目开发计划； 需求分析； 体系结构设计说明； 详细设计说明； 构件索引； 构件成分说明； 构件接口及调用说明； 组件索引； 组件接口及调用说明； 类索引； 类属性及方法说明； 测试报告； 测试统计报告； 质量监督报告； 源代码； 文档分类版本索引； 软件安装打包文件。

外部文档主要包括： 软件安装手册； 软件操作手册； 在线帮助； 系统性能指标报告； 系统操作索引。

如何保证文档的全面性，使其真正为项目的进度提供保证，又不因为文档的写作而耽误项目的进度，这仍然是一个比较难解决的问题。解决此问题，其核心仍然是个"度"的问题。在本项目的开发中，配置管理小组的一个非常重要的任务还是书写文档规范和文档模板。当有文档模板后需要书写文档的人员只剩下"填空"的工作，从某种意义上讲，书写文档的速度会加快。如果书写文档的人员认为文档的更细致的部分可以由他人帮助完成，则该文档即交由他人完成，但此时文档并不算被正式提交，当他人书写完毕之后，必须由文档的初写者进行复审，复审通过后方可以正式提交，进入软件配置管理的循环中。

配置管理小组真正核心的工作是对文档的组织管理。根据文档的不同，文档的来源也不同，有些是通过质量保证小组经过复审之后转交给配置管理小组，有些则会直接从文档的出处到达配置管理小组。文档的管理是一个非常烦琐的工作，但是长远来看它不仅使项目的开发对单个主要人员的依赖减少，从而减少人员流动给项目的带来的风险，更重要的是在项目

进行到后百分之十的时候起到拉动项目的作用。

从以往做大项目的经验来看，写作文档在项目开发的早期可能会使项目的进度比起不写文档要稍慢，但随着项目的进展，各个部门需要配合越来越多，开发者越来越需要知道其他人员的开发思路和开发过程，才能使自己的开发向前推进。一个明显的例子就是系统整合，或者某些环节是建立在其他环节完成的基础之上时，就更显现出文档交流的准确性和高效性。

3、系统维护质量保证

在我们公司，维护小组的任务一方面是保证对项目客户的跟踪服务，另一方面是确保该项目其它的开发人员从项目中尽快的解脱出来以便投入到下一个项目的开发中。所以通常项目维护小组成员主要由项目组的少部分开发人员承担完成。他们不仅了解软件的核心内容，而且与客户也不陌生，以便能够以最快的速度修正错误。对于一般性的错误，如操作不当等引起的问题，全部由维护小组执行完成，但需要用户测试确认上线。如果较大的修改则需要走变更控制流程，用户或者维护人员填写变更申请，经专家会议讨论分析可行方案在由维护小组实施，通过测试后方可提交用户。

维护小组的人员基本上是按项目跟进的。当一个项目刚刚交付用户时，在维护小组有较多的人员进行跟进，随软件的稳定，跟进的人逐步减少，并转移到其它项目中去。