• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

敏捷建模与统一过程(一)

发布: 2008-2-03 14:55 | 作者: Scott W. Ambler 翻译:李 | 来源: 51CMM | 查看: 124次 | 进入软件测试论坛讨论

领测软件测试网

Discipline律条 Purpose目的

Business Modeling

业务建模

The purpose of this discipline is to model the business context, the scope, of your system. Common modeling activities include the development of:

该律条的目的是为你系统的业务环境和范围建模。通常的建模活动包括:

· A context model (often a data flow diagram) showing how your system fits into its overall environment 描述系统如何匹配它的整体环境的环境模型(通常是一个数据流程图)

· A high-level business requirements model (often an essential use case model) 高层业务需求模型(通常是一个基本的用况模型)

· A glossary defining critical business terms 一个定义关键业务术语的词汇表

· A domain model (often a class diagram or data diagram) depicting major business classes or entities 描述主要业务类或实体的领域模型(通常是一个类图或者数据图)

· A business process model (often a data flow diagram or activity diagram) depicting a high-level overview of the business process to be supported by your system. This diagram is one level of detail greater than your context diagram

描述系统所支持的业务过程的高层视图(通常是一个数据流图或活动图)。该图处于高于环境图的更详细级别。

Requirements

需求

The purpose of this discipline is to engineer the requirements for your project, including the identification, modeling, and documentation of those requirements. The main deliverable of this discipline is the Software Requirements Specification (SRS), also referred to as the Requirements Model, which encompasses the captured requirements.

该律条的目的是为你的系统确定需求,包括需求辨认、建模和文档化。该律条的主要可交付物是软件需求说明书(Software Requirements Specification,SRS),也称为需求模型(Requirements Model),它包括了捕捉到的需求。

Analysis & Design

分析与设计

The purpose of this discipline is to evolve a robust architecture for your system based on your requirements, to transform the requirements into a design, and to ensure that implementation environment issues are reflected in your design. 该律条的目的是使你的基于需求的系统演化出一个健壮的架构,把需求转变为设计,并确保实现环境在你的设计中得到反映。

Enterprise Management (EUP only)

企业管理(仅适用于EUP)

This discipline encompasses activities that are outside of the scope of a single project, including:该律条包括单独项目范围之外的活动,它们是:· Enterprise requirements modeling, the act of creating and evolving models that reflect the high-level requirements of your organization.企业需求建模,它是创建和演化能反映你组织的高层需求模型的活动。 · Enterprise architectural modeling, the act of creating and evolving models that depict the business and technical infrastructure of your organization.企业架构建模,它是创建并演化能描述你组织的业务与技术基础结构模型的活动。

How Good is the Fit Between AM and UP?
AM和UP能配合的多好?

Now that we understand the basics of how modeling in the UP works, we can examine how well AM fits in with it. Luckily many of AM’s principles and practices are arguably a part of the UP already, although perhaps not as explicitly as I would like. Table 2 presents an examination of how well each individual AM practice is currently implemented in the UP, if at all, and discusses how to adopt the practice within the scope of the UP. My experience is that it is relatively straightforward for UP teams to adopt AM practices if they choose to do so. This is because the UP is very flexible, one of its underlying principles is that you should tailor it to meet your unique needs, making it easy to merge AM practices into the UP.
既然我们了解了UP的建模基础,我们就能考察AM对它有多合适。幸好,AM的许多律条和实践已经成为UP的一部分,尽管可能还没有到我希望的那么明显。表2考察了每个单独的AM实践在当前UP中的实现情况,并讨论了如何在UP的范围里采用这些实践。我的经验是,如果他们选择这么做的话,UP团队采用AM实践是相对简单的。这是因为UP是非常灵活的,它有一个潜在律条就是你应该剪裁它以适合你自己的独特需要,而这使它易于把AM实践融合到UP中。
Table 2. The Fit Between UP and AM.

Practice实践 Fit配合

Active Stakeholder Participation

积极的干系人员参与

AM has a wide definition for project stakeholders, including users, management, operations staff, and support staff to name a few one that is compatible with the UP. The UP clearly includes project stakeholders, such as users and customers, throughout most of it disciplines. To be successful UP project teams should allow project stakeholders to take on modeling roles such as Business Process Designer and Requirements Specifier as appropriate, there is nothing in the RUP preventing this by the way. The more active project stakeholders are the less of a need there will be for reviews, management presentations, and other overhead activities that reduce your team’s development velocity.AM

对项目干系人的定义很广,包括与之兼容的UP中定义过的用户、管理者、操作人员和支持人员等等。UP中明确定义的项目干系人,比如用户和客户、始终贯穿于它的律条。想成为成功的UP项目团队,就应该允许项目干系人承担建模角色,比如业务过程设计员和需求指定者,在RUP中从不排斥这种做法。更积极的项目干系人更小需要复核,管理者表述和其它高层活动会降低你团队的开发速度。

Apply Modeling Standards

应用建模标准

The application of modeling standards, in particular the diagrams of the Unified Modeling Language (UML), is a significant part of the UP. Furthermore the RUP product (Rational Corporation, 2001) includes guidelines for the creation of many modeling artifacts, guidelines that your teams should consider adopting and following as appropriate, and explicitly suggests that you tailor the guidelines that they provide for your exact needs. To remain agile, however, UP teams should recognize that you often need to bend the guidelines and standards ? in other words, don’t let them become a straight jacket.

建模标准的应用,尤其是UML,是UP的一个重要部分。此外,RUP产品(Rational Corporation, 2001)还包含了创建多种建模工件的指南、团队应该考虑采纳和遵循的指南以及对你剪裁指南以符合你准确需求的建议。要保持敏捷,UP团队应该知道通常需要灵活使用指南和标准。换句话说,不要让它们成为硬性的指标。

Apply Patterns Gently

逐渐应用模式

UP teams are free to apply modeling patterns, the RUP product describes many common modeling patterns, as part of their efforts for any of the modeling disciplines. This practice enhances the UP with its advice to ease into the application of a pattern, the UP does not make this concept as explicit as it could.

UP团队可以自由使用建模模式作为他们任何建模律条工作的一部分,因为RUP产品描述了多种常用的建模模式。这种实践通过建议轻松使用模式来促进UP,因为UP并没有尽可能明显地提出这个概念。

Apply The Right Artifact(s)

应用正确工件

One of the strengths of the UP is that provides some advice for when to create each type of model, and recent incarnations of the RUP product includes significant advice for non-UML artifacts such as data models and user interface storyboards (UI flow diagrams).

UP的一个优势是它提供了一些关于何时创建每类模型的建议,而且最近的RUP具体产品还包括关于非UML工件的重要建议,比如,数据模型和用户界面情节串联版(UI流图)。

Collective Ownership

集体所有

AM’s concept of collective ownership can be used to enhance the efforts on UP projects, assuming that the team culture supports the concept of open and honest communication. The UP supports collective ownership with its strong focus on configuration management issues, it has a discipline dedicated to this task, although its change management processes may potentially get in your way if developers and project stakeholders are unable to distinguish when to formalize change control and when not to. To be fair, this is a problem regardless of when you apply AM on an UP project, or on any type of project forthat matter. UP teams should turn the configuration management dial up a few notches and allow anyone on the project to access and work on any artifact that they wish, including models and documents.

如果团队文化支持开放和诚实的沟通,AM的集体所有概念能够提升UP项目的成果。UP通过对配置管理项的强调支持集体所有的概念。即使倘若开发人员和项目干系人不能识别何时需要规范化变更控制,它的变更管理过程也会潜在地起作用,因为UP有一个针对该任务的律条。公平的说,这是一个不论何时在UP项目或与之类似的任何项目中应用AM都会遇到的问题。UP团队应该把配置管理量化,允许项目中的任何人都能访问他们想用的任何工件,包括模型和文档。

Consider Testability

考虑可测试性

The UP includes a Test discipline in its lifecycle, making testing an explicit issue that everyone should keep in mind as they are working. The UP also includes many opportunities to review modeling artifacts, if you choose to follow this form of validation. To fully adopt this practice the consideration——Is it testable?——should be included in all modeling activities.

UP在它的生命周期中包括一条测试律条,即让测试成为一个每个人都能在工作中留意的显性事项。如果你选择遵循这种确定性,UP就会包括很多复核建模工件的机会。要完全采用这种实践,就要在所有的建模活动中经常考虑一个问题——“它是可测试的吗?”

Create Several Models in Parallel

创建若干可并行的模型

The UP clearly includes this concept, one only has to look at the activity diagrams depicting each discipline to see that several artifacts are potentially being worked on in parallel. However, this concept could be communicated better because the near-serial flow in its activity diagrams presented for each major modeling activity doesn’t communicate this concept well.There is a larger issue as well when you consider the lifecycle as a whole.Because the UP has organized its modeling efforts into separate disciplines, for very good reasons, it isn’t as apparent that not only could you work on several business modeling artifacts in parallel but you could also work on requirements-oriented artifacts, analysis-oriented artifacts, architecture artifacts, and design artifacts too. UP teams can turn the dial up a few notches by reading between the lines of the discipline activity diagrams and the UP lifecycle diagram and choosing to perform activities from several disciplines simultaneously when it makes sense to do so.

UP明确包括这个概念,即一个人仅需要查看描述每个律条的活动图就能发现若干潜在的并行工作的工件。然而,该概念可以得到更好的沟通。因为活动图中的表达每个主要建模活动的准顺序图无法在这个概念上沟通良好。当你从整体上考虑生命周期时,这就是个大问题。因为UP已经把它的建模工作组织成独立的律条,由于这个原因,它并不明显地支持你并行地在若干业务建模工件上工作,以及让你在面向需求的工件、面向分析的工件、架构工件和设计工件上工作。UP团队能通过在律条活动图和UP生命周期图之间读取以及选择在必要时对若干律条同时工作来使之量化。

Create Simple Content

创建简单内容

This practice is a choice made by the modeler(s), albeit one that must be implicitly supported by the rest of the development team. UP teams will need to adopt modeling guidelines that allow models that are just good enough and the customers of those models (including programmers, project stakeholders, and reviewers) must also be willing to accept simple models. This is a cultural issue, one that is often difficult for many organizations to adopt.

这项实践是建模者的一个选择,尽管它必须隐含地被开发团队的其他人支持。UP团队会需要采用建模指南,它拥有足够好的模型,并且那些模型的客户(包括程序员、项目干系人以及复核员)也必须想采用简单模型。这是一个文化问题,通常难以被很多组织采用。

Depict Models Simply

简单描述模型

See Create Simple Content.

参见创建简单内容

Discard Temporary Models

抛弃临时模型

Modelers on UP teams are free to discard anything that they wish. As with the simplicity practices your organization’s culture must be accept the concept of traveling light, of developing and maintaining just enough models and documents and no more.

UP团队的建模人员可以自由地抛弃任何他们想抛弃的东西。由于使用简单实践,你的组织文化必须接受轻装行进的概念,即只开发和维护足够用的模型和文档。

Display Models Publicly

公开展示模型

UP teams are free to follow this practice. UP teams can turn the communication dial up a notch by following the principle Open and Honest Communication by making all artifacts available to everyone as well as to publicly display the critical models used by the project team.

UP团队可以自由的遵循这项实践。UP团队应遵循公开和坦诚的沟通原则,让所有工件对每个人都可用,并且公开展示项目团队使用的关键模型。这样就能把沟通量化。

Formalize Contract Models

规范化契约模型

The UP includes the concept of integrating with external systems, these systems are typically identified on use case models and the RUP suggests introducing boundary classes to implement the interface to these systems. At the time of this writing the RUP appears weak with respect to activities such as legacy system analysis and enterprise application integration (EAI). The explicit adoption of this practice clearly strengthens the UP’s integration activities and fits in well with it’s concepts of use case realizations 。The interaction between systems could be specified with one or more use cases and then the corresponding use case realization would be the formalized contract model.

UP包括集成外部系统的概念,这些系统是典型由用况模型确定的。RUP建议引入边界类来实现这些系统的接口。在编写时,RUP在比如遗留系统分析和企业应用集成(EAI)方面比较弱。而这项实践的直接采用可以明显增强UP的集成活动,并与它的用况实现概念配合起来。在系统间交互能够用一个或多个用况来说明,然后把相应的用况实现成规范的契约模型。

Iterate To Another Artifact

迭代到另一个工件

This practice can be easily adopted by an UP team. As mentioned previously, the unfortunate depiction of UP modeling activities as quasi-serial processes and the division of modeling activities into separate disciplines can hinder the iterative mindset required of agile modelers.

这项实践可以被UP团队很容易采纳。正如前面提到的,UP建模活动的准顺序过程和把建模活动分割为独立的律条,会隐藏敏捷建模者需要的可迭代思想。

Model in Small Increments

以小增量方式建模

This practice is clearly an aspect of the UP,the UP’s support for iterations implies that you will be incrementally developing your model throughout your project. UP teams can easily turn the iterative and incremental dial up a few notches by preferring smaller, simpler models that quickly lead to implementation and testing.

这项是实践明显是UP的一个方面。UP对迭代的支持暗示你将在项目中以增量方式开发你的模型。UP团队能很容易地通过更小更简单的模型迅速引导实现和测试,把迭代和增量工作量化。

Model to Communicate

为沟通而建模

The UP implicitly includes this practice. UP teams can turn the communication dial up a few notches by following the principle Model With a Purpose by knowing who their audience for the model is and what they require of the model.

UP隐含包括了这项实践。UP团队应该遵循有目的的建模原则,知道谁是模型的观看者以及他们对模型的要求是什么。这样就能把沟通量化。

Model to Understand

为理解而建模

See Model to Communicate.

参见为沟通而建模

Model With Others

与他人一同建模

The UP implicitly includes this practice. Every modeling discipline clearly includes several roles, each role being filled by one or more people. UP teams can turn the communication dial up a few notches by adopting tools that support team modeling, such as whiteboards and collaborative modeling tools (see the Communication essay) over single-user modeling tools.

UP隐含包括了这项实践。每个建模律条都明确的包括若干角色,每个角色都会由一个或多个人承担。UP团队能够通过采用支持团队建模的工具,比如在单用户建模工具上使用白色书写板或协作建模工具来实现沟通的量化。

Prove it With Code

用代码证明

The UP explicitly includes this practice. At the end of every iteration, except perhaps for the ones during the Inception phase, the UP specifically states that you should have a working prototype. Furthermore, the UP insists that you have a working end-to-end prototype at the end of the Elaboration phase that proves your architecture.

UP显式包含了这项实践。在每次迭代的末尾,除了在Inception阶段中的一些,UP都详细指出你应该有的有效的原形。此外,UP强调你应该在Elaboration阶段的末尾有一个有效的端到端原形以证明你的架构。

Reuse Existing Resources

重用现有资源

Reuse is an implicit part of the UP, and reuse management is an explicit part of the Enterprise Unified Process (EUP). UP teams can turn the reuse dial up a few notches by actively preferring to reuse existing resources instead of building them from scratch, including but not limited to existing models, existing components, open source software (OSS), and existing tools.

重用是UP的隐含部分,而重用管理是企业统一过程(EUP)的显式部分。UP团队能通过积极的重用现有资源还不是从草案开始就构建,包括但不限于现有的模型、现有的组件、开源软件(OOS)以及现有的工具。

Update Only When It Hurts

只在受损害时更新

In theory this can be an easy concept for UP teams to adopt as it dramatically reduces the effort expended to keep your artifacts up to date. However, in practice many organizations prove to have a problem with this concept, particularly if they have a strong traceability culture. Traceability is the ability to relate aspects of project artifacts to one another, the support for which is a strong feature of the UP as it is an important aspect of its Configuration and Change Management discipline. Furthermore, the RUP product includes tool mentors for working with Rational RequisitePro, a requirements traceability tool, making it appear easy to maintain a traceability matrix between artifacts. My experience is that organizations with traceability cultures will often choose to update artifacts regularly, even if it isn’t yet painful to have the artifacts out of date, and update the traceability matrix relating everything to one another. To turn their productivity dial up several notches UP teams should choose to travel light, to loosen up a bit and allow project artifacts to get out of sync with one another, and to maintain a traceability matrix between artifacts only when there is clear benefit to do so AND their project stakeholders understand the issues involved as well as authorize the effort. A traceability matrix is effectively a document and is therefore a business decision to be made by project stakeholders.

理论上,这是一个UP团队易于采用的概念,因为它极大地减少了更新工件的工作量。然而,在实际中,很多组织在这个概念上有问题,尤其当他们具有强大的可跟踪性习惯时。可跟踪性是一种使项目工件之间联系起来的能力,对它的支持要靠UP团队强大的配置和变更管理律条。此外,RUP产品包括与需求跟踪工具——Rational RequisitePro一起工作的工具,使得它易于在工件之间维护一个跟踪矩阵。我的经验是,有可跟踪性习惯的组织通常选择有规律的更新工件并更新把事物联系在一起的跟踪矩阵,即使让工件过期并非带来损害。要量化生产力,UP团队应该选择轻装行进,并允许项目工件之间取消同步,且只在的确有好处和项目干系人理解并同意执行时才维护跟踪矩阵。跟踪矩阵是有效的文档,并进而是项目干系人做出的业务决策。

Use the Simplest Tools

使用最简单的工具

The RUP product includes tool mentors that make it easier for teams to work with tools sold by Rational Corporation. However, the reality is that UP teams are welcome to use any development tool that they want and Rational tools compete on their merits just like the products of any other company. UP teams can turn their productivity dial up several notches by expanding their horizons to include simple tools such as whiteboards, index cards, and Post-It notes in addition to CASE tools.

RUP产品包括可以让团队容易使用的Rational公司提供的工具。然而,UP团队的实质是喜欢使用任何他们想用的开发工具,使用Rational工具和使用其他任何公司的产品是一样的。UP团队可以使用CASE工具之外的工具,比如白色书写板、索引卡片、Post-It记录来扩展他们的视野。这样可以把生产率量化。

Something that is important to understand is that for AM to be successful the culture of your organization must be open to the concepts, values, and principles of agile software development. The problem is that the UP is often adopted by organizations that either implicitly or explicitly do not accept the values of agile software development. Their focus is often on following processes and using tools, the RUP product (Rational Corporation, 2001) clearly defines many processes and describes how to apply Rational’s tools effectively on software projects, and therefore the RUP is clearly attractive to them. Unfortunately this goes against the agile value of preferring individuals and interactions over processes and tools. When the culture of an organization is documentation centric they may find the UP appealing because you can instantiate it in such a way as to result in the creation of significant amounts of documentation (you can also instantiate it to result in very little documentation, remember, the UP is flexible). If an organization is documentation centric then this aspect of its culture goes against agile software development’s value of preferring working software over comprehensive documentation. This organization may still successfully adopt, tailor, and instantiate the UP but be unable to follow many of AM?s principles and practices effectively because it does not have an agile culture (see the essay When Does(n't) AM Make Sense). My point is that how well AM and UP will fit together in your organization depends largely on your organization?s culture and not so much on the UP itself. You can easily use the techniques of AM to improve your UP modeling efforts, but to be effective you will find that you need to overcome cultural challenges within your organization.
有些东西必须要理解,即要想AM成功,你的组织文化必须能开放的面对敏捷软件开发的概念、价值和原则。但问题是,组织UP通常或隐式或显式的采用UP,却并没有接受敏捷软件开发的价值。他们关注的通常是过程和工具,即RUP产品(Rational Corporation, 2001)明确定义的许多过程以及描述的在软件工程中被有效应用的Rational工具。于是,RUP对他们有明显的吸引力。不幸的是,这和在过程和工具上倾向独立和交互的敏捷价值相互冲突。当一个组织的文化是以文档为中心时,他们会发现UP很吸引人。因为他们能以创建大量文档的方式实现它(你也能以创建少量文档的方式实现,记住,UP是灵活的)。如果一个组织是以文档为中心的,那么组织文化就与倾向在可理解文档上开发软件的敏捷软件开发价值相互冲突。这种组织仍然可以成功采用、剪裁并实现UP,但是却无法有效遵循很多AM的原则和实践,因为它并没有一种敏捷文化(see the essay When Does(n't) AM Make Sense)。我的观点是,在你的组织中如何把AM和UP结合到一起将主要取决于你的组织文化而不是UP本身。你可以很容易地使用AM技术改进你的UP建模工作,但是为了有效,你会发现你需要克服来自你组织中的文化挑战。

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

22/2<12

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备2023014753号-2
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网