升级到SOA中的系统需求工程框架

　　想知道如何升级到面向服务的体系结构（Service-Oriented Architecture，SOA）中的系统需求工程框架（requirements engineering framework，REF）吗？了解与转换到该框架、软目标可操作化以及使用约束、风险和更改来完成该框架相关的问题。developerWorks的作者Judith Myerson为您提供了开发软目标的示例，并建议了使目标可操作化的方法。

　　引言

　　“使用多重SOA来消除企业系统之间的差异”探索了如何从一个或多个SOA中重用Web服务——以数据为中心和业务逻辑——并将它们合并到组合应用程序中。“SOA中的紧密耦合Web Services”研究了紧密耦合和松散耦合Web服务的优点和缺点，以及紧密耦合所带来的规模上的最终变化。

　　这些文章讨论了SOA开发的不同方面。本文介绍应该如何调整系统REF以适应构成SOA应用程序的各个Web服务，以此作为使用多个SOA来缩小系统差距的方式。了解业务和系统需求工程如何改进由SLA Web服务组成的SOA应用程序的性能和系统安全性，这些Web服务大部分是松散耦合的，只有一小部分是紧密耦合的。

　　传统需求工程

　　作为软件开发流程中的第一步，传统需求工程确定新产品或系统所必须满足的功能性和非功能性需求或条件。

　　·功能性需求指定系统或产品必须具有的行为或功能。
　　·非功能性需求指定用于确定系统如何运行或工作的质量标准。

　　定义需求工程并没有解释软件开发流程的为什么问题；它只是告诉您需要做什么，以及应该如何在需求工程的引出、分析、验证和文档说明方面继续下去。

　　转换到系统需求工程框架

　　要解释流程，可以转换到系统REF。此框架从作为需求的输入的系统上下文和目标开始，并使用需求的约束和风险完成其运行。该框架响应系统上下文、目标、约束和风险方面的重大更改而重复执行流程。

　　不要在该框架中忽略的是参与到设计一个或多个目标的涉众（stakeholder）。涉众的参与允许分析人员权衡不同涉众对制定需求（以响应SOA约束和风险方面的变化）的不同目标意见。

　　系统上下文考虑有关构建SLA Web服务的需求引出、协商和文档说明所必需的需求源。系统上下文的更改可能使目标更改变得必要。一些系统上下文更改示例包括：

　　·用于实现更快响应的高速带宽升级。
　　·企业收购和合并导致的企业网络扩充。
　　·实施SOA以缩小企业系统差距。
　　·紧密耦合的SLA Web服务组件。
　　·利用未使用资源的网格计算。

　　必须对所有更改进行版本管理、验证、文档说明和监视。

　　使软目标可操作

　　目标并非始终是确定和可测量的；有些目标还是软目标。分析人员需要将软目标转换为可实现的需求。在该框架中，在对需求进行实现、验证和版本管理之后，或在对系统上下文施加新的约束之后，您可以在将软目标转换为可实现的需求之前整合新的更改。传统需求工程不允许您在实现需求之后整合新的更改。

　　例如，您指定了某个Web服务必须使服务可用的硬目标；该服务充当自动SLA Web服务。同时，目标发起者或代理之间的协议集中于三个软目标变量（举例而言），系统分析人员可以将这些变量转换为可实现的需求。其中包括正常运行时间可用性、异常和可用性变量。您以后可以进行更改。

　　第一个软目标：正常运行时间可用性

　　第一个软目标指定必须保证达到99%（举例而言）或更多的正常运行时间可用性。目标发起者或分析人员决定要在可用时间低于保证时间时施加什么惩罚，以及要在可用时间在给定时间段内实现了目标时给予什么激励。

　　第二个软目标：异常

　　第二个软目标指定异常，例如计划的故障、拒绝服务、计划的维护、网络中断和服务提供商控制内的网络问题。在确定提供商做出的哪些服务停用惩罚不公平和不合理之后，目标发起者或分析人员将关注这些异常。当第一个软目标的条件显著更改时，分析人员可以添加新的异常或从第二个目标中去掉现有的异常。

　　对于某些异常，目标发起者可以指定客户公司获取合理的补偿。太多的异常会导致客户选择竞争者的SLA Web服务，只要那些服务提供更少的异常、更多的正常业务运行时间和更好的服务保证。该软目标应该为客户提供机会以选择服务提供商允许的异常。

　　第三个软目标：可用性变量

　　第三个软目标指定服务可用性变量。表1显示了可用性变量的列表以及每个变量的说明。

　　表1. 服务可用性变量

 
　　当第一或第二软目标更改时，可用性变量的类型将更改。

　　可操作化示例

　　下面查看一个示例，看看如何操作某个有关访问可用性变量的软目标。为了将该软目标转换为可实现的需求，您需要构建一个质量模型，然后填充该模型。

　　例如在构建该模型时，分析人员应该允许涉众判断服务的可用性有多迅即。涉众能够确定使某个服务对组织可用所需要的时间，以及在服务不中断的时候下载文档的时间。

　　然后分析人员使用涉众所需要的系统行为的相关数据来填充质量模型。拥有正确访问授权的涉众可能要求该服务在99%的时间内可用，并且每个文档页的下载时间不超过四秒。类似地，要使某个文档可访问，涉众可能要求他们访问该文档所花的时间不超过20秒。

　　如果涉众发现服务可用性惩罚不公平和不合理，例如计划的维护、拒绝服务和不在提供商控制之内的网络中断，则涉众和目标分析人员必须就要在质量模型中包括有关异常的什么数据达成一致。此外，质量模型数据应该包括有关状态性、访问、响应时间、版本管理、超时和其他SLA Web服务可用性变量的数据。

　　约束、风险和更改

　　为了在第一回合中完成该框架，您需要执行几个额外的步骤。首先，您需要验证需求以确保它们按最初预期的那样正确工作，并假设系统上下文的约束还没有变化。作为验证过程的一部分，如果打算通过Internet提供由紧密耦合和松散耦合的SLA Web服务组成的SOA应用程序，您需要评估服务可用性风险。如果结果表明风险概率很高，您可能希望更改目标和需求，以将风险缓解到更加可接受的级别。

　　然而，如果监视表明在完成验证过程和缓解风险之后出现了新的环境约束，那些约束可能造成负面影响或限制需求。这意味着您需要重新评估施加在系统上下文上的新约束是什么，哪些当前约束不再适用，以及目标和需求的哪些部分可以重用。

　　然后将目标作为新的输入来添加、删除或转换为可实现的需求，并在框架中重复执行验证和风险缓解过程。只需确保在框架的每个阶段中对所有更改流程做文档说明，以允许分析人员和其他角色根据需要执行影响分析。

　　结束语

　　您需要一个由开发人员、系统管理员和需求开发人员组成的项目团队，以协作升级到SOA中的系统REF。提前计划到REF的转换，并将软目标转换为可实现的需求。使用约束、风险缓解和变更管理来解决完成该框架所涉及的问题，从而使得更容易转换到该框架。

　　您的团队可以使用IBM Rational RequisitePro来管理需求、改进可跟踪性、加强协作、降低项目风险和提高质量。可以将此软件与IBM Rational Portfolio Manager集成在一起，以提供业务案例管理和活动的定期管理和战略检查。还可以使用IBM Rational Method Composer来改进已确定更改时的流程，以及使用IBM Rational ClearQuest来通过缩短测试时间提高工作效率。

1.jpg

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780828/viewspace-407095/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14780828/viewspace-407095/