软件外包项目与需求工程

2009-02-25 来源：网络

作者结合自身工作实践，深入探讨了在软件外包项目管理过程中，如何有效地进行“需求工程”的相关工作，从而保证承包商获取完整并符合用户真实意愿的项目需求，以及减少因需求变更失控带来的可能危害。

一、需求的重要性
何为“需求”？广泛的讲，软件项目中的需求源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了软件产品“必须或应当”做什么。
从重要性来看，软件项目中“需求、设计、编码、测试”四者哪个更重要？这个问题不好回答。四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏影响。若从风险管理的角度讲，我认为需求开发和管理是最重要的环节。因为需求是产品的根源，需求工作的优劣对产品影响最大，而且会带来最大的返工成本。举例来说，软件项目开发过程就像一条河流，如果河流的源头（需求）被污染了，那么整条河流也就被污染了。
开发软件系统最困难的部分就是准确说明开发什么。最困难的工作是编写出详细的需求，以及包括所有面向用户、面向机器和其他软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后的弥补也极为困难。

二、需求工作的问题分析
电力行业这几年正迎来信息化建设新浪潮，每个电力企业每年都有大量的软件项目需要开发，一些项目是由本企业自主开发，另外很大一部分是外包给其他软件公司进行开发，我们在这里可以将其称为“软件外包项目”。从我个人的了解和切身体会来看，国内许多电力企业的软件项目开发状况并不理想，很多项目进度反复延期、大量的返工、产品质量总是不能满足项目预期和用户的要求。而作为信息化建设的主流模式，软件外包项目更会因为跨地域、沟通不到位、承包商不成熟、组织利益不同等原因而产生更多的问题。
分析导致软件项目失败的众多原因，其中最主要的一条就是项目的开发方和用户方对“需求工作”不重视或缺少一套有效的方法论。一方面开发方的很多人员并不知道如何把需求工作做好，而另一方面用户方往往也忽略需求，不能积极提供完整详细的需求说明，而且很多需求确认或评审工作也是草草了事。
为了改进软件项目以上所述现状，绍兴电力局从2004年起和上海沙迪克软件有限公司 一起就软件外包项目开发管理过程进行规范和整改，并取得了非常理想的成效。
我们首先来了解一下软件外包项目中需求工作存在的种种问题。
2.1 用户说不清楚需求
用户说不清楚需求是普遍现象，这是让开发商非常头痛的问题。这种情况下，如果软件承包商以此为借口草率地对待需求工作，会连累整个项目的开发。无论什么原因导致用户说不清楚需求，承包商都必须设法搞清楚用户的真实需求，这是他们的职责。
2.2 态度问题
相当多软件承包商的开发人员习惯于被动地对待需求工作。每当遇到麻烦、挫折时，总是发牢骚，并找出用户的很多问题。这是普遍现象，并不是承包商懒惰所造成的，而是不正确的观念误导了他们。
很多承包商错误地认为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求或者经常变更需求，因此引起的问题是用户造成的，应当由他们自己负责。
软件承包商应该让自己的开发人员了解到：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。
2.3 双方对需求的误解
对用户描述的需求，不同的人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的开发人员错误的开发。不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求，因此需求文档和评审工作必不可少。
2.4 用户经常变更需求
需求变更通常会对项目的进度、成本、资源产生很大的影响，这是软件承包商非常畏惧的问题。很多情况下用户方也具有不可推卸的责任，如：在项目初始阶段不愿意认真地整理需求、确认需求，总是想着“以后反正可以修改，以后再说 … ”，这样做的结果可想而知，大量的需求变更，频繁的返工，导致承包商丧失工作激情，以致项目最终不了了之。
从以上列举的几点来看，要减少因为需求导致项目失败的几率，需要软件外包项目的双方好好反省，认真学习需求工作方法，建立一套有效的软件项目需求开发管理过程体系和方法。

三、 需求工程的概念
为了进行有效的改进，我们首先需要划分并定义清楚需求相关工作的主要内容及其目标。
上述阐述中多次提到的“需求工作”，指的是所有与需求直接相关的活动，业界术语又称为“需求工程”。需求工程中的活动可以分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构如下图所示。

需求开发 的目的是通过调查和分析，获取用户需求并定义产品需求。需求开发过程域有3个主要活动：
• 需求调查
需求调查的目的是通过各种途径获取用户的需求信息，产生《用户需求说明书》；
•需求分析
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。
•需求定义
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
需求管理 的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其他工作成果的一致性，并控制需求的变更。需求管理过程域有3个主要活动：
•需求确认
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后做出书面承诺，使需求文档具有商业合作效果。
• 需求跟踪
需求跟踪是指比较需求文档与后续工作产品之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
• 需求变更控制
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。

四、 绍兴电力局进行“需求工程”改进的实践探讨
4.1 甲方需建立合理的项目组织结构
为了有效地进行需求开发和管理活动，我局根据企业自身特点配套建立一套职责清晰、分工明确的项目组织结构。其中对于需求开发和管理工作，我们专门设置了“甲方需求联络员”这样一个岗位，负责用户需求的提出，以及向软件承包商进行用户需求的解释工作，如图。

“甲方需求联络员”岗位的设置，保证了甲方有足够的时间和人力资源用于用户需求的获取、整理、解释和确认工作，同时又做到了需求归口统一，最终理解的一致性。对于软件承包商而言，“甲方需求联络员”的设置大大减少了承包商需求分析员组织协调的时间，便于最高效地获取用户的真实需求。
4.2 从合同和项目计划开始进行改进
软件承包商和用户的合作关系对需求而言是至关重要的。因此，我们在软件外包项目的合同和项目计划阶段，就要求明确双方的合作关系，主要体现在：责任到人、职责明确、过程规范。
甲方（发包方或用户）：
明确需求联络员、典型和关键用户；
项目前期尽可能从自身理解出发，整理出一份完整的用户需求原始文档；
要求积极配合乙方需求分析员进行采访，在不泄漏机密的前提下，尽可能地回答他们希望了解的问题；
要求积极配合乙方需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿；
不轻易变更需求。如果需要变更需求的话，按照“需求变更控制规程”执行，而非强迫承包商接受；
甲方将派专人（如：甲方SQA）负责对与需求工程有关的双方活动定期进行检查，如果发现问题向双方提出并跟踪其改进结果；
如果条件允许的话，建议承包商为甲方举办有关需求工程的培训，以减少今后的摩擦，以使需求相关人员明白需求的重要性，以及忽视需求的危害性，从而使甲方积极友善地参加需求工程中的各项活动。
乙方（软件承包商）：
要求乙方派遣合格的需求分析员和相关人员；
要求乙方采用用户熟悉的语言和甲方提供的统一格式来描述需求，如一般情况下会要求乙方提供《用户需求说明书》和《产品需求规格说明书》两篇需求文档；
如果甲方想变更需求，有权要求乙方对该变更将产生的影响进行真实可信的评估，以便甲方确定是否变更需求；
要求乙方完全遵循合同和项目计划中约定的需求开发和管理过程进行工作。
4.3 规范软件承包商的需求开发活动
为了确保承包商获取项目的真实需求，我们对承包商的需求活动进行规范并进行定期的跟踪，要求他们按照规范执行，并定期提交相关工作产品以便于我方进行检查。具体包括：
需求开发活动活动内容和相关工作产品
1. 用户需求调查　
1.1 准备调查确认关键和典型用户、确认调查方式、准备调查问卷、确认调查对象。
1.2 调查与记录调查用户需求，随时记录调查过程中所获取的需求信息。
1.3 分析需求信息分析已经获取的需求信息，消除错误，归纳与总结共性的用户需求。
1.4 撰写《用户需求说明书》按照指定的文档模板撰写《用户需求说明书》，主要内容包括：产品介绍、用户群体的特征、产品应当遵循的标准或规范、描述产品的功能性需求、描述产品的非功能性需求，如用户界面、软硬件环境、质量等需求。
2．产品需求定义　
2.1 细化并分析用户需求对《用户需求说明书》进行细化，以便产生详细的产品需求。此外，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。

2.2撰写《产品需求规格说明书》按照指定的文档模板撰写《产品需求规格说明书》，主要内容包括：产品介绍、用户群体的特征、定义产品的范围、产品应当遵循的标准或规范、定义产品中的角色、定义产品的功能性需求、定义产品的非功能性需求，如用户界面、软硬件环境、质量等需求。
另外，为了更好了解每个需求的是否清晰、与其它工作产品的对应关系，并便于跟踪后续的完成情况，我们要求软件承包商为需求进行编号，并能够通过一张索引表（如下表所示）了解以上的相关信息。
需求编号功能子功能需求优先度（高、中、低）对应的用户需求备注（依赖关系和清晰状态等）
　Function A Function A .1 　　　
　　Function A .2 　　　
　　… 　　　
4.4 规范和改进需求评审活动
对需求文档进行评审是保证项目质量的关键活动。我们将评审的方式分为两类：一类是正式评审，主要由用户方和承包商共同参与的评审；另一类是非正式评审，主要是软件承包商内部的评审。
对于承包商提交的《用户需求说明书》和《产品需求规格说明书》，一般情况下我们都要求至少执行一次正式评审，并安排在我方所在地进行。对于非正式评审，我们都要求由承包商自己内部进行，但我们会跟踪和抽查他们的评审过程和结论，希望他们能事先排除基本的错误，明确主要问题，以提高后续正式评审的效率。
对于正式评审活动，往往会伴随很多问题的产生，并严重影响了评审工作的执行。针对这些问题，我们从自身实践中摸索出一些比较好的解决办法，说明如下：
评审工作“虎头蛇尾”
需求评审的确乏味，刚开始评审的时候大家都比较认真，往往越到后面越马虎，特别是需求文档很长时，几乎没有人能够坚持到最后。针对以上问题，我局在自身的需求评审工作中通过以下几点来进行改进：
1、评审工作事先有计划，并做好内容分工。每部分内容都有专门的人员进行负责，以减少每个人的阅读工作量。
2、作者就评审文档的主要问题点事先和责任人进行沟通，明确需要会上确认的主要问题。这样有助于提高评审效率，尽量减少评审时间。
3、会议主持人事先强调需求评审工作的重要性，以提高参与评审人员的注意力和积极性。
评审工作量大
需求评审的人员可能比较多，有时候让这么多人聚在一起花费比较长的时间开会并不容易。其实没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行，这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。
评审时容易“跑题”
评审时如果会针对一个问题进行激烈讨论，而且会越扯越远，结果评审会议变成聊天会议。此时，一方面主持人应当控制话题，避免大家讨论与主题无关的东西；另一方面，对于有些问题“如何做，如何解决”这样的讨论，要做到适可而止，不要过多地谈论细节，可以放在会后进行，这样有助于节约多数人的时间。
评审时过多的“争论”
很多评审会议上，往往会因为某个问题难以达成共识，并分成“几派”各据一方。此时，会议的主持人应该参与进行协调，建议大家站在他人的立场上进行思考，这样一般会很快找到适中的解决办法。
4.5 要求承包商建立需求跟踪报告
在我们对承包商的开发过程进行跟踪和检查的过程中，我们经常需要了解“产品需求是否反映所有用户需求？”、“设计是否反映了产品需求？”、“需求是否有相应的测试用例进行测试？”等等这些问题，并且承包商只有很好地处理了以上问题才能充分保证未来软件产品的质量。为此，我们会在一些重要项目中要求承包商及时建立“需求跟踪报告”（如下表所示），这样有助于后续我们执行相关工作产品的审查工作。
序号需求编号需求文档（版本、日期）设计文档（版本、日期）代码（版本、日期）测试用例（版本、日期）缺陷
　　标题或标识符，说明标题或标识符，说明文件名，标题或标识符，说明文件名，标题或标识符，说明缺陷编号
001FR-A-0017.A.1用户登录成功　　XT-A001-01 XT-A002-02　
4.6建立需求变更控制过程
很多项目需求发生若干次变更似乎是不可避免的。很多情况下，是由于用户和承包商对需求的了解越来越深入，原来定义的需求可能存在错误或不足，因此需要变更需求。
提出需求变更的动机是好的，但管理不好往往会带来很严重的负面影响，很多情况下会发生“变更带来的好处远远小于因此导致的坏处”，如：原先好用的功能因为个别人的习惯问题被修改掉，导致大多数人难以使用；个别需求变更，导致开发工作大量返工，严重影响后续的测试工作，导致项目质量低下甚至延期。
为了有效地管理和控制需求变更，我局建立一套规范的需求变更控制过程，并做到：
需求变更提出
用户或承包商提出的变更均采用规定方式进行提交（如：需求变更控制报告或沙迪克ALESH系统需求管理功能），这样便于专人集中统一管理。
需求变更分析
对于提出的重大需求变更，要求承包商采用规定方式做出详细的影响分析，包括：变更内容、变更需要耗费的工作量、对项目交货期的影响等内容。这样便于项目双方人员了解变更带来的相关影响，并以此作为变更与否的重要依据。
需求变更审批
对于需要进行的重大变更，需要承包商和甲方共同认可，并签字确认。
五、 结束语
需求问题是软件外包项目成败的关键因素，以上是绍兴电力局在长期的实践过程中，借鉴和总结出的一些成功需求开发和管理方法。在整个改进的过程中，我们遇到了很多的实际问题，但在单位领导和上海沙迪克软件有限公司咨询顾问的大力支持下我们一直坚持过来，找到了很多很好的解决办法，并在实践中取得了很好的效果。今后，希望能够和广大软件项目管理人员一起进行探讨和研究，为我国电力行业信息化建设摸索出一条能够适合电力企业特点、简单而又具有实效的改进道路和实践方法。