软件外包项目与需求工程 ——绍兴电力局软件项目外包管理实践探讨

2013-11-27 09:32:21 电力信息化　点击量：评论 (0)

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

另外，为了更好了解每个需求的是否清晰、与其它工作产品的对应关系，并便于跟踪后续的完成情况，我们要求软件承包商为需求进行编号，并能够通过一张索引表（如下表所示）了解以上的相关信息。

需求编号	功能	子功能	需求优先度（高、中、低）	对应的用户需求	备注（依赖关系和清晰状态等）
	Function A	Function A.1
		Function A.2
		…

4.4 规范和改进需求评审活动
对需求文档进行评审是保证项目质量的关键活动。我们将评审的方式分为两类：一类是正式评审，主要由用户方和承包商共同参与的评审；另一类是非正式评审，主要是软件承包商内部的评审。
对于承包商提交的《用户需求说明书》和《产品需求规格说明书》，一般情况下我们都要求至少执行一次正式评审，并安排在我方所在地进行。对于非正式评审，我们都要求由承包商自己内部进行，但我们会跟踪和抽查他们的评审过程和结论，希望他们能事先排除基本的错误，明确主要问题，以提高后续正式评审的效率。
对于正式评审活动，往往会伴随很多问题的产生，并严重影响了评审工作的执行。针对这些问题，我们从自身实践中摸索出一些比较好的解决办法，说明如下：

²        评审工作“虎头蛇尾”
需求评审的确乏味，刚开始评审的时候大家都比较认真，往往越到后面越马虎，特别是需求文档很长时，几乎没有人能够坚持到最后。针对以上问题，我局在自身的需求评审工作中通过以下几点来进行改进：1、评审工作事先有计划，并做好内容分工。每部分内容都有专门的人员进行负责，以减少每个人的阅读工作量。2、作者就评审文档的主要问题点事先和责任人进行沟通，明确需要会上确认的主要问题。这样有助于提高评审效率，尽量减少评审时间。3、会议主持人事先强调需求评审工作的重要性，以提高参与评审人员的注意力和积极性。

²        评审工作量大
需求评审的人员可能比较多，有时候让这么多人聚在一起花费比较长的时间开会并不容易。其实没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行，这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。

²        评审时容易“跑题”
评审时如果会针对一个问题进行激烈讨论，而且会越扯越远，结果评审会议变成聊天会议。此时，一方面主持人应当控制话题，避免大家讨论与主题无关的东西；另一方面，对于有些问题“如何做，如何解决”这样的讨论，要做到适可而止，不要过多地谈论细节，可以放在会后进行，这样有助于节约多数人的时间。

²        评审时过多的“争论”
很多评审会议上，往往会因为某个问题难以达成共识，并分成“几派”各据一方。此时，会议的主持人应该参与进行协调，建议大家站在他人的立场上进行思考，这样一般会很快找到适中的解决办法。

4.5 要求承包商建立需求跟踪报告
在我们对承包商的开发过程进行跟踪和检查的过程中，我们经常需要了解“产品需求是否反映所有用户需求？”、“设计是否反映了产品需求？”、“需求是否有相应的测试用例进行测试？”等等这些问题，并且承包商只有很好地处理了以上问题才能充分保证未来软件产品的质量。为此，我们会在一些重要项目中要求承包商及时建立“需求跟踪报告”（如下表所示），这样有助于后续我们执行相关工作产品的审查工作。