软件外包项目与需求工程.docx
- 文档编号:25858227
- 上传时间:2023-06-16
- 格式:DOCX
- 页数:16
- 大小:28.92KB
软件外包项目与需求工程.docx
《软件外包项目与需求工程.docx》由会员分享,可在线阅读,更多相关《软件外包项目与需求工程.docx(16页珍藏版)》请在冰豆网上搜索。
软件外包项目与需求工程
软件外包项目与需求工程
作者结合自身工作实践,深入探讨了在软件外包项目管理过程中,如何有效地进行“需求工程”的相关工作,从而保证承包商获取完整并符合用户真实意愿的项目需求,以及减少因需求变更失控带来的可能危害。
一、需求的重要性
何为“需求”?
广泛的讲,软件项目中的需求源于用户的一些“需要”,这些“需要”被分析、确认后形成完整的文档,该文档详细地说明了软件产品“必须或应当”做什么。
从重要性来看,软件项目中“需求、设计、编码、测试”四者哪个更重要?
这个问题不好回答。
四者都是软件开发过程中必不可少的环节,光做好其中一个环节并不能产生好的系统,但是做坏了其中任何一个环节,必定对系统产生坏影响。
若从风险管理的角度讲,我认为需求开发和管理是最重要的环节。
因为需产品的根源,需求工作的优劣对产品影响最大,而且会带来最大的返工成本。
举例来说,软件项目开发过程就像一条河流,如果河流的源头(需求)被污染了,那么整条河流也就被污染了。
开发软件系统最困难的部分就是准确说明开发什么。
最困难的工作是编写出详细的需求,以及包括所有面向用户、面向机器和其他软件系统的接口。
此工作一旦做错,将会给系统带来极大的损害,并且以后的弥补也极为困难。
二、需求工作的问题分析
电力行业这几年正迎来信息化建设新浪潮,每个电力企业每年都有大量的软件项目需要开发,一些项目是由本企业自主开发,另外很大一部分是外包给其他软件公司进行开发,我们在这里可以将其称为“软件外包项目”。
从我个人的了解和切身体会来看,国许多电力企业的软件项目开发状况并不理想,很多项目进度反复延期、大量的返工、产品质量总是不能满足项目预期和用户的要求。
而作为信息化建设的主流模式,软件外包项目更会因为跨地域、沟通不到位、承包商不成熟、组织利益不同等原因而产生更多的问题。
分析导致软件项目失败的众多原因,其中最主要的一条就是项目的开发方和用户方对“需求工作”不重视或缺少一套有效的方法论。
一方面开发方的很多人员并不知道如何把需求工作做好,而另一方面用户方往往也忽略需求,不能积极提供完整详细的需求说明,而且很多需求确认或评审工作也是草草了事。
为了改进软件项目以上所述现状,电力局从2004年起和沙迪克软件一起就软件外包项目开发管理过程进行规和整改,并取得了非常理想的成效。
我们首先来了解一下软件外包项目中需求工作存在的种种问题。
2.1用户说不清楚需求
用户说不清楚需普遍现象,这是让开发商非常头痛的问题。
这种情况下,如果软件承包商以此为借口草率地对待需求工作,会连累整个项目的开发。
无论什么原因导致用户说不清楚需求,承包商都必须设法搞清楚用户的真实需求,这是他们的职责。
2.2态度问题
相当多软件承包商的开发人员习惯于被动地对待需求工作。
每当遇到麻烦、挫折时,总是发牢骚,并找出用户的很多问题。
这是普遍现象,并不是承包商懒惰所造成的,而是不正确的观念误导了他们。
很多承包商错误地认为:
需用户的事情,不是我们的事情。
我们为用户开发软件,难道用户不该告诉我们应当开发什么吗?
如果用户说不清楚需求或者经常变更需求,因此引起的问题是用户造成的,应当由他们自己负责。
软件承包商应该让自己的开发人员了解到:
需求分析员的天职就是在有限的时间获取准确而细致的用户需求,如果做不到就是失职,不要找借口。
2.3双方对需求的误解
对用户描述的需求,不同的人员可能有不同的理解。
如果需求分析员误解了需求,那会导致后续的开发人员错误的开发。
不论是复杂的项目还是简单的项目,需求分析员和用户都有可能误解需求,因此需求文档和评审工作必不可少。
用户经常变更需求
需求变更通常会对项目的进度、成本、资源产生很大的影响,这是软件承包商非常畏惧的问题。
很多情况下用户方也具有不可推卸的责任,如:
在项目初始阶段不愿意认真地整理需求、确认需求,总是想着“以后反正可以修改,以后再说…”,这样做的结果可想而知,大量的需求变更,频繁的返工,导致承包商丧失工作激情,以致项目最终不了了之。
从以上列举的几点来看,要减少因为需求导致项目失败的几率,需要软件外包项目的双方好好反省,认真学习需求工作方法,建立一套有效的软件项目需求开发管理过程体系和方法。
三、需求工程的概念
为了进行有效的改进,我们首先需要划分并定义清楚需求相关工作的主要容及其目标。
上述阐述中多次提到的“需求工作”,指的是所有与需求直接相关的活动,业界术语又称为“需求工程”。
需求工程中的活动可以分为两大类,一类属于需求开发,另一类属于需求管理。
需求工程的结构如下图所示。
需求开发的目的是通过调查和分析,获取用户需求并定义产品需求。
需求开发过程域有3个主要活动:
·需求调查
需求调查的目的是通过各种途径获取用户的需求信息,产生《用户需求说明书》;
·需求分析
需求分析的目的是对各种需求信息进行分析,消除错误,刻画细节等。
·需求定义
需求定义的目的是根据需求调查和需求分析的结果,进一步定义准确无误的产品需求,产生《产品需求规格说明书》。
系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其他工作成果的一致性,并控制需求的变更。
需求管理过程域有3个主要活动:
·需求确认
需求确认是指开发方和客户共同对需求文档进行评审,双方对需求达成共识后做出书面承诺,使需求文档具有商业合作效果。
·需求跟踪
需求跟踪是指比较需求文档与后续工作产品之间的对应关系,建立与维护“需求跟踪矩阵”,确保产品依据需求文档进行开发。
2需求变更控制
需求变更控制是指依据“变更申请-审批-更改-重新确认”的流程处理需求的变更,防止需求变更失去控制而导致项目发生混乱。
四、电力局进行“需求工程”改进的实践探讨
4.1甲方需建立合理的项目组织结构
为了有效地进行需求开发和管理活动,我局根据企业自身特点配套建立一套职责清晰、分工明确的项目组织结构。
其中对于需求开发和管理工作,我们专门设置了“甲方需求联络员”这样一个岗位,负责用户需求的提出,以及向软件承包商进行用户需求的解释工作,如图。
“甲方需求联络员”岗位的设置,保证了甲方有足够的时间和人力资源用于用户需求的获取、整理、解释和确认工作,同时又做到了需求归口统一,最终理解的一致性。
对于软件承包商而言,“甲方需求联络员”的设置大大减少了承包商需求分析员组织协调的时间,便于最高效地获取用户的真实需求。
4.2从合同和项目计划开始进行改进
软件承包商和用户的合作关系对需求而言是至关重要的。
因此,我们在软件外包项目的合同和项目计划阶段,就要求明确双方的合作关系,主要体现在:
责任到人、职责明确、过程规。
甲方(发包方或用户):
明确需求联络员、典型和关键用户;
项目前期尽可能从自身理解出发,整理出一份完整的用户需求原始文档;
要求积极配合乙方需求分析员进行采访,在不泄漏的前提下,尽可能地回答他们希望了解的问题;
要求积极配合乙方需求分析员共同评审需求文档,确保需求文档准确地反映用户真实的意愿;
不轻易变更需求。
如果需要变更需求的话,按照“需求变更控制规程”执行,而非强迫承包商接受;
甲方将派专人(如:
甲方SQA)负责对与需求工程有关的双方活动定期进行检查,如果发现问题向双方提出并跟踪其改进结果;
如果条件允许的话,建议承包商为甲方举办有关需求工程的培训,以减少今后的摩擦,以使需求相关人员明白需求的重要性,以及忽视需求的危害性,从而使甲方积极友善地参加需求工程中的各项活动。
乙方(软件承包商):
要求乙方派遣合格的需求分析员和相关人员;
要求乙方采用用户熟悉的语言和甲方提供的统一格式来描述需求,如一般情况下会要求乙方提供《用户需求说明书》和《产品需求规格说明书》两篇需求文档;
如果甲方想变更需求,有权要求乙方对该变更将产生的影响进行真实可信的评估,以便甲方确定是否变更需求;
要求乙方完全遵循合同和项目计划中约定的需求开发和管理过程进行工作。
4.3规软件承包商的需求开发活动
为了确保承包商获取项目的真实需求,我们对承包商的需求活动进行规并进行定期的跟踪,要求他们按照规执行,并定期提交相关工作产品以便于我方进行检查。
具体包括:
需求开发活动活动容和相关工作产品
1.用户需求调查
1.1准备调查确认关键和典型用户、确认调查方式、准备调查问卷、确认调查对象。
1.2调查与记录调查用户需求,随时记录调查过程中所获取的需求信息。
1.3分析需求信息分析已经获取的需求信息,消除错误,归纳与总结共性的用户需求。
1.4撰写《用户需求说明书》按照指定的文档模板撰写《用户需求说明书》,主要容包括:
产品介绍、用户群体的特征、产品应当遵循的标准或规、描述产品的功能性需求、描述产品的非功能性需求,如用户界面、软硬件环境、质量等需求。
2.产品需求定义
2.1细化并分析用户需求对《用户需求说明书》进行细化,以便产生详细的产品需求。
此外,对比较复杂的用户需求进行建模分析,以帮助软件开发人员更好地理解需求。
2.2撰写《产品需求规格说明书》按照指定的文档模板撰写《产品需求规格说明书》,主要容包括:
产品介绍、用户群体的特征、定义产品的围、产品应当遵循的标准或规、定义产品中的角色、定义产品的功能性需求、定义产品的非功能性需求,如用户界面、软硬件环境、质量等需求。
另外,为了更好了解每个需求的是否清晰、与其它工作产品的对应关系,并便于跟踪后续的完成情况,我们要求软件承包商为需求进行编号,并能够通过一索引表(如下表所示)了解以上的相关信息。
需求编号功能子功能需求优先度(高、中、低)对应的用户需求备注(依赖关系和清晰状态等)
FunctionAFunctionA.1
FunctionA.2
…
4.4规和改进需求评审活动
对需求文档进行评审是保证项目质量的关键活动。
我们将评审的方式分为两类:
一类是正式评审,主要由用户方和承包商共同参与的评审;另一类是非正式评审,主要是软件承包商部的评审。
对于承包商提交的《用户需求说明书》和《产品需求规格说明书》,一般情况下我们都要求至少执行一次正式评审,并安排在我方所在地进行。
对于非正式评审,我们都要求由承包商自己部进行,但我们会跟踪和抽查他们的评审过程和结论,希望他们能事先排除基本的错误,明确主要问题,以提高后续正式评审的效率。
对于正式评审活动,往往会伴随很多问题的产生,并严重影响了评审工作的执行。
针对这些问题,我们从自身实践中摸索出一些比较好的解决办法,说明如下:
评审工作“虎头蛇尾”
需求评审的确乏味,刚开始评审的时候大家都比较认真,往往越到后面越马虎,特别是需求文档很长时,几乎没有人能够坚持到最后。
针对以上问题,我局在自身的需求评审工作过以下几点来进行改进:
1、评审工作事先有计划,并做好容分工。
每部分容都有专门的人员进行负责,以减少每个人的阅读工作量。
2、作者就评审文档的主要问题点事先和责任人进行沟通,明确需要会上确认的主要问题。
这样有助于提高评审效率,尽量减少评审时间。
3、会议主持人事先强调需求评审工作的重要性,以提高参与评审人员的注意力和积极性。
评审工作量大
需求评审的人员可能比较多,有时候让这么多人聚在一起花费比较长的时间开会并不容易。
其实没有必要把所有事情挤在一块做,需求开发是循序渐进的过程,需求评审也可以分段进行,这样每次评审的时间比较短,参加评审的人员也少一些,组织会议就比较容易。
评审时容易“跑题”
评审时如果会针对一个问题进行激烈讨论,而且会越扯越远,结果评审会议变成聊天会议。
此时,一方面主持人应当控制话题,避免大家讨论与主题无关的东西;另一方面,对于有些问题“如何做,如何解决”这样的讨论,要做到适可而止,不要过多地谈论细节,可以放在会后进行,这样有助于节约多数人的时间。
评审时过多的“争论”
很多评审会议上,往往会因为某个问题难以达成共识,并分成“几派”各据一方。
此时,会议的主持人应该参与进行协调,建议大家站在他人的立场上进行思考,这样一般会很快找到适中的解决办法。
4.5要求承包商建立需求跟踪报告
在我们对承包商的开发过程进行跟踪和检查的过程中,我们经常需要了解“产品需否反映所有用户需求?
”、“设计是否反映了产品需求?
”、“需否有相应的测试用例进行测试?
”等等这些问题,并且承包商只有很好地处理了以上问题才能充分保证未来软件产品的质量。
为此,我们会在一些重要项目中要求承包商及时建立“需求跟踪报告”(如下表所示),这样有助于后续我们执行相关工作产品的审查工作。
序号需求编号需求文档(版本、日期)设计文档(版本、日期)代码(版本、日期)测试用例(版本、日期)缺陷
标题或标识符,说明标题或标识符,说明文件名,标题或标识符,说明文件名,标题或标识符,说明缺陷编号
001FR-A-0017.A.1用户登录成功 XT-A001-01XT-A002-02
4.6建立需求变更控制过程
很多项目需求发生若干次变更似乎是不可避免的。
很多情况下,是由于用户和承包商对需求的了解越来越深入,原来定义的需求可能存在错误或不足,因此需要变更需求。
提出需求变更的动机是好的,但管理不好往往会带来很严重的负面影响,很多情况下会发生“变更带来的好处远远小于因此导致的坏处”,如:
原先好用的功能因为个别人的习惯问题被修改掉,导致大多数人难以使用;个别需求变更,导致开发工作大量返工,严重影响后续的测试工作,导致项目质量低下甚至延期。
为了有效地管理和控制需求变更,我局建立一套规的需求变更控制过程,并做到:
需求变更提出
用户或承包商提出的变更均采用规定方式进行提交(如:
需求变更控制报告或沙迪克ALESH系统需求管理功能),这样便于专人集中统一管理。
需求变更分析
对于提出的重大需求变更,要求承包商采用规定方式做出详细的影响分析,包括:
变更容、变更需要耗费的工作量、对项目交货期的影响等容。
这样便于项目双方人员了解变更带来的相关影响,并以此作为变更与否的重要依据。
需求变更审批
对于需要进行的重大变更,需要承包商和甲方共同认可,并签字确认。
五、结束语
需求问题是软件外包项目成败的关键因素,以上是电力局在长期的实践过程中,借鉴和总结出的一些成功需求开发和管理方法。
在整个改进的过程中,我们遇到了很多的实际问题,但在单位领导和沙迪克软件咨询顾问的大力支持下我们一直坚持过来,找到了很多很好的解决办法,并在实践中取得了很好的效果。
今后,希望能够和广大软件项目管理人员一起进行探讨和研究,为我国电力行业信息化建设摸索出一条能够适合电力企业特点、简单而又具有实效的改进道路和实践方法。
////////////////////////////////////////////////////////////////////////////////
外包软件项目管理经验总结
建立良好合作模式
外包开发的软件不能达到企业的质量要求,我们往往会在第一时间把罪过推给外包商。
但实际经验告诉我们,很多失败的原因是企业本身没有提供一套完整的软件系统规格说明、没有跟进开发的进度、没有定期与外包商沟通与协调、没有在开始时建立好质量指标和测试流程或者没有做出适当的技术和开发环境的评估。
但最重要的一点,是没有在决定软件外包时处理好双方合作模式与关系的建立。
千万不要认为软件外包可以减少企业的管理时间。
相反,外包项目有时需要双倍的管理时间。
在我们决定外包软件开发的时候,我们首要决定是整个应用系统的开发由外包商承包,还是只有部分应用模块的程序交由外包商编写。
前者需要管理整个外包项目的生命周期,跟企业部软件开发的管理没有差异,只是开发的地点、环境和资源比较陌生而已;后者则需要了解企业本身是否能提供优质的规格说明、是否能够提供外包商所需的质量标准和测试数据、外包商是否有类似企业本身的开发平台和环境,以及外包商的技术资源水平是否与企业部开发时所需的技术指数相符。
明确自身所需和服务要求,是决定外包项目的先决条件。
选择适合的外包商,并不能单以服务价格来做最终决定。
优质的服务需要付出较高的代价。
企业应根据自身对软件质量的要求来决定服务的代价。
按照国际企业的衡量指标,外包投入比本身开发的净投资(以各技术员工的基本薪资为标准,并不包括企业对员工所提供的福利、假期和奖励计划等开支)多付15%~20%。
也就是说,如果企业本身开发需要30万元的话,那么合理的外包服务价格大概是34万元到36万元。
既然外包不能立竿见影地带来经济利益,为什么还要外包呢?
最主要的原因是企业在项目完成后不需要继续照顾这批开发人员,不需要为这些开发人员提供福利条件。
外包费用是一次性的营运开支,不像雇员薪资这样成为企业的长期营运成本。
假如企业有些一次性的大型项目需要马上启动,但缺乏足够的资源,或者企业本身没有相应的技术人员来执行的时候,外包不失为一个可行的解决办法。
如何进行外包项目的管理
一些项目经理往往认为外包开发项目与企业部开发项目的管理没有多大分别,唯一不同是外包项目需要更多时间去沟通、协调、跟进和监控。
总体来说,这种想法是对的,但事实上外包项目的管理比企业部开发项目的管理更复杂,担负更大的风险,需要更紧密的进度和质量监控。
(相关文章:
如何控制信息技术外包的风险?
)
保障沟通
部开发项目所需人力资源大致分为两组:
一是技术人员,另一组是配合技术人员的业务人员(他们是所建信息系统的潜在用户)。
外包项目除了需要部分技术人员和用户群体参与外,更增加了一组外包商的资源。
有些外包商更会指派一名联络人员负责联系与协调,而他们的技术人员只在后方负责项目的开发。
这种运作模式要尽量避免,因为外包商指派负责联系的人员往往是业务人员的背景,对技术的细节不能全面把握,把有关信息传达到技术人员的时候便会有所差异。
所以我们的首要任务是让外包商明白负责项目联系的人员必须是开发小组的主管。
这名开发小组主管是直接参与开发项目的主要人员,如此才能够有效地进行沟通和监控。
做好计划
项目经理首先需要做出一个详细的、完整的项目计划,并在计划中详细地列清楚每一件工作需要哪方面的哪些人力来共同执行。
在计划中的每一个进度都需要进行确认才能继续。
例如外包商在完成系统分析后,需要把分析的结果让客户理解,好让企业能够确认外包商对整个系统的理解和分析与企业本身对项目的需求和分析达成一致,这样才能让外包商进行其后的模块设计。
不然设计出来的模块组合便有可能与企业的需求不太一样,存在质量和最后上的差异。
这些差异也将会引发企业将来在系统维护、更新、增加功能模块、升级、集成等各方面的严重问题。
避免延误
要避免项目发生延误,计划中要预留足够的时间来进行上述确认工作。
由于双方工作地点的缘故,原本只需一天的确认会议便可能耗费两天或三天的时间来完成。
议程中所达到的共识也可能需要时间来让外包商做出适当的修改才能让企业正式确认。
也只能在正式确认后才能够进一步继续接下来的工作。
如果没有预留足够的时间用于协商,当一个项目经过七八个确认会议之后,也许已经延误了一个月的时间。
/////////////////////////////////////////////////////////////////////
IT外包项目管理杂谈
2005-9-2122:
52:
33【作者】畅享网
摘要:
“IT国际化,向外走出去”在我国已经被提出好几年了,而“外包”被许多国IT精英认定的“IT(软件)国际化”的跳板,随之而来的IT外包项目管理也就成了讨论甚至争论的焦点。
本文从宏观分析国“外包”项目现状入手,分析目前国“外包”项目的痛痒之所在,然后进一步从五个方面阐述了如果针对目前的“外包”项目的特点,对不同的“外包”项目类型如何进行项目管理。
关键字:
外包,外包项目,外包项目管理,包工制,外包项目服务
一、当前国IT外包市场状况
来自IDC的数据显示,2003年中国IT外包服务市场比上年增长了34.2%,首次超越3亿美元的数字关口达到3.18亿美元,虽然目前外包市场占整个IT服务市场的份额还不到10%,但是未来五年将保持着强劲的增长态势,年均增长可望达到44.2%以上,超出IT服务业平均增长率近一倍以上。
由此可见,外包市场潜力巨大,不仅是规模大,而且稳定,利润空间也远较国IT销售要丰厚的多。
就那软件业来说,中国拥有巨大的软件时常,是世界公认的软件开发资源,Gartner研究公司预测,在2007年到2010年期间,中国将成为世界上最大的外包市场。
据去年的数据报告,各国发包量中美国发包量1100亿美元;日本发包量337亿美元;印度软件出口77亿美元;中国软件出口8亿美元。
因此目前国一些大的软件开发公司都在尝试做外包。
比如对日软件外包市场的“井喷式”发展,让我国企业欣喜若狂。
对日软件外包,已悄然成为产业界的一种时尚。
目前,国软件公司所接的包多数是非核心模块的设计编码或只管编码或进行本地化等,另外还有一类包就是软件测试的包。
前几年“软件测试包””是被捆绑在“本地化包”中进行,而现在,“软件测试包”被单独提出来来外包给中国的软件公司,而且由于软件测试是一项业务复杂也工作量极大的工作,在国迅速发展且将来具有广阔的发展潜力。
二、国企业IT外包项目的痛痒何在?
如此广阔的市场,如此庞大的市场商机,国的IT企业应该欣喜若狂,但是现实的烦恼总比意料中的要多些。
即便是目前对日外包最成功的企业,也总是在美好的远景与自身的虚弱感之间徘徊。
一种发自生理和心理深处的多重“痒”感,正在撩拨整个产业的神经。
现阶段中国的软件外包还处在初始阶段,有很多很弱的方面,比如软件外包运作不成熟,因为外语的约束太大而使沟通不畅,项目管理水平落后,缺乏软件测试的质量管理经验,不熟悉国外软件开发和测试的管理模式,软件开发体系化管理方面做得不好,由于企业规模小无法接大的包等等,是国企业在接包过程中的痛痒之处。
在所有这些痛痒之中,最让人痛的也是痛之源头是人才的短缺。
中国软件企业要扩大规模,首先要克服人才瓶颈。
可以说,人才的缺乏,是中国企业长不大的根本症结所在。
编码人才固然缺乏,但更缺的还是中高端的设计人才以及管理人才。
道理很简单,一个管理人才可以带10个人的队伍,而10个管理人才则可以组建100人的“舰队”,因此高端人才的重要性不言而喻。
否则,中国的软件企业只能拘泥于“包工制”,原因很简单,因为项目管理水平上不去,无法承接固定价格的外包合同,即使接了不是质量不行就是时间拖延,或是因成本太高而使企业没有赢利甚至亏本。
就拿软件测试的外包来说吧,软件测试包不同于软件本地化的包,软件测试更是一类灵活的抽象的不太好衡量的服务,而且其质量控制、安全、双方沟通等要求更高,所以,就目前国软件的项目管理水平,很少有企业能把这种包用固定价格合同的形式接过来做成功。
因此,目前很多公司接到的像微软、IBM、HP、NEC、东芝等这些大型国际外企的包,都是以“包工制”的形式进行合作,即以实际工作日来付费。
三、如何进行有效的软件测试外包项目的管理?
既然清楚了中国企业IT外包项目有这么多的痛痒,那么我们又应该如何面队国外抛送过来的包呢?
难道就就是长期以“包工制”形式一直做下去?
答案是否定的。
有人说企业分三个层次,高层次的企业拥有主动权,靠提供服务机会就能赚钱(如垄断性产品);中层次企业相对主动,靠提供服务手段和途径赚钱(如集成方案);低层次企业是被动,靠实现服务赚钱(如劳务)。
三类企业境界不同,寿命也就不同。
很显然,我们的“包工制”外包项目就是靠实现服务赚钱,如果长此以
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 外包 项目 需求 工程