| 出版日期：2005-02-28 总期号：1390 本年期号：13 |
|
 |
掌握需求管理中的需求
文 刘杰编译 本文讨论对应用于“小型”Web应用的模式语言的研究，它的目的是描述出开发Web应用的原理性框架。为什么仅仅是“概念性的框架”？因为许多Web应用可能不需要一个复杂的应用服务器框架，只需要用于特殊任务如模板处理的微型框架。主要的应用可以在一个标准的开放源码平台如LAMP（(Linux、Apache、MySQL and Perl/PHP/Python）的顶端来开发。 在一个全面框架的复杂性和应用需求之间存在着平衡，框架通常具有很大的特征集，因而也有不合理的学习曲线，开发也比较困难。例如，当一些Web应用可能需要一个内容管理系统时，大多数情况下，一个模板处理程序可能就可以满足要求。 另一方面，一个概念上的构架可以提供有关如何建立一个定制的应用服务器模式，并且告诉你何时应用处理特别任务的微型框架。本文中的概念性框架是作为一种模式语言进行论述的。这些模式按照小型到中型的大小顺序加以连接，目的是论述包含有典型设计的通用实践。 在这些设计的论述中包含有应用程序与用户之间相互作用的流程，处理用户请求，在应用程序的调用之间保存应用程序的状态。 定义需求管理 需求管理过程要实现两个目标：第一，要确保项目所涉及的人员都能够意识到自己有哪些需求；第二，要使他们确定的自己的需求全部都已被表达出来。绝大多数情况下，无效的需求收集过程是导致项目失败和软件缺陷的根源。而且，修补缺陷的成本随着时间的推移而成指数增长态势。影响它的时间因素包括，在随后的开发过程中发现这一缺陷的时间，以及组织开始寻求改进开发过程的时间，但是，需求因素却常常被人们忽略。扎实可靠的需求过程是整体过程有效实施的基础，要实现质量和生产力的不断增长，公司就必须从需求过程做起。 我们可以从文本、表格或图形模型中获取需求。最高层次的需求管理不但要求具备全方位收集和管理需求的能力，还要求集成各种各样的生命周期管理工具。上述对集成的要求促使人们开发了多种用于构建完整生命周期的产品。主流工具通过驱动分析模型和建立测试用例来激活需求。集成和可跟踪性不仅能够促进开发过程的平稳运行，而且还能确保需求得到成功满足。需求管理是风险管理的关键部分，而且，项目风险的上升也提高了对需求过程稳定性的要求。 贯穿过程的需求 需求的成熟度并不取决于某一具体的过程。一般来说，正式的方法更易于与CMM对应起来，因为它们有足够程度的细节表述。使用需求管理工具还可以实现标准化编号、可跟踪性等，但是它却有可能使开发流程断裂，或是当开发者所依赖的卡片被修改而工具中没有同步反映出这一修改时，会产生阻碍。灵活性，以及与过程其它部分实现完美集成的工具包，仍然是优秀的需求工具的标志。软件开发市场向敏捷方法方向发展，产生了两大不同类别的工具，一类是以传统的自上而下的工程方法为核心，另一类是以协作和同步开发为核心。 很重要的一点是，必须认识到需求过程应当与项目的规模相适应。大型项目会涉及更多的资源，而且这些资源会对其它软硬件资源产生更大的影响（如图1所示）；小型项目则要减少文档的类型，要做到这一点，打破文档的分层是最简单的方法。 对于不同类型的项目，需求管理也会有所不同。软件维护、程序包安装、深度开发都要以现有的状况为基础。通常来说，维护活动是不包含在传统的需求过程之中的，因为需求可以在缺陷管理或桌面帮助系统中获得。虽然维护活动也可以得到需求数据，但是，它却不能代替使用传统管理工具进行需求改动的过程，也不能代替将需求与某一具体项目联系起来的过程。 需求工具的价值 对于管理工具的价值和为什么要使用它们，人们还有许多疑问。使用办公套件，如电子制表软件和文档处理软件，IT组织可以创建可重复的过程，并对文档和格式进行标准化。然而，这些文档对于整个开发和管理过程来说价值不大，对于实现协作也没有太大效用。在协作环境中，人们通过分类、工作流程和讨论/协作加强了文档管理，提高了文档的使用价值。一个更好的方法，就是使用需求管理工具，收集有用数据并进行跟踪管理。我们还开始关注需求工具与开发过程其他阶段的集成，这种集成能够使组织更好地综合生命周期各个环节所作的努力，并提高工具的效用。团队成员工作地点的分散造成交流不便，从而导致效率低下，而且，虽然开发过程的迭代性和协作性逐渐上升，传统工具仍然只是用于瀑布模型。这样，需求的低效获得和流通不畅就造成了开发过程中断层出现和用户满意度的降低。 虽然工具为所收集到的需求提供了记录格式，并帮助人们生成统一的报告，但这仍然不能说明人们有效地获得了需求。因此，组织不但需要选用需求工具或是标准化模板，还要将重点放在需求的获取上，并应意识到，有效的需求收集并不是一个简单的步骤就可以完成的工作。需求的格式应该多样化：文本描述、图形和原型及法定规则。需求工具为不同类型的需求和数据提供不同程度的支持，而且在设计和开发阶段，对应于加强需求的能力的不同要求，都有不同的工具。不断深入的集成虽然可以推动过程改进，然而，集成的一般方式却是移动信息或图像，并只在较晚的功能和集成测试的时候才进行检查。 需求工具至少应该具备以下功能： 对每一项需求均给出标识；需求的分类和委派到目标；需求修订标识/基线；基本的数据接口、更加完善的工具提供可跟踪性，协作支持，以及建模、测试和开发系统的建模。 虽然工具提供商都认同可跟踪性，但是不同的工具提供的服务是不一样的。可跟踪性大多用于不同的需求之间。用户要选择那些提供对所有历史资料进行跟踪的工具，不仅包括对需求的跟踪，还包括对模型、代码和测试的跟踪。 需求和估算 需求的一个作用，就是进行软件成本估算。要进行成本估算，就必须明确需求应该达到的细节程度，从而判断项目的成本，判断需求是否必须使用标准的度量指标如功能点，来进行标识。有趣的是，在敏捷过程中，如极限编程，一个关键的因素就是判定项目时间进程的能力。应该明确一点，软件开发是一门非精确性的科学。估算是贯穿项目始终并不断变化的，当开发者对各种各样的问题有了更深刻的认识，当细节从其他阶段被集中起来（建模、开发、测试）时，都要对先前的估算作出相应的修改。对IT组织来说，规定具体的有关估算精确度的标准，是十分关键的。主流需求工具要求风险与任务密切相连，不使用具体工具的组织应该识别整体项目中存在的各项风险以及个别特性的特定风险。 （UMLChina供稿）（B6） 
图1 需求层次图：滴漏效应 |
||||||||||||||||
