【转】一个学习案例: 使用 IBM Rational Unified Process 作为方法框架

ibm上的文章,不知道为什么G内不能访问,故此转载http://www.ibm.com/developerworks/cn/rational/r-rup-fw/index.html 其实我是想找这个口头上非常火的RUP的实际实践,但是确实很难找,只找到这么个国外的文章,内心里我很反感这种虚火的东西。不管敏捷也好,CMMI也好,什么其他衍生出来的乱七八糟的方法学也好。炒作过头了反倒说明了内在的空虚!软件开发不同工程制造,人的智慧因素很重要,因此程序员以及管理者的智商情商那才是基础因素,说白了就是人的因素。方法学和管理学必须建立在这个基础上才有用。软件做得好首先是人的功劳,不是什么几十年,几年前前定的个方法学管理学好。这些只是辅助手段,是种工具而已。基础不好,想通过这些工具来起作用,那只能是厨子不好怪灶歪!
 

一个学习案例: 使用 IBM Rational Unified Process 作为方法框架

Maureen Field ([email protected]), Group Leader, IT Project Office, Ford Credit

Venkat Alladi, Process Methodologist, Ciber, Inc.

简介: 本文来源于 2003 年 Rational 用户大会的一个演讲稿,这个学习案例的研究讨论了一个公司成功的开发和部署以 IBM RUP 作为过程框架的迭代开发方法的真实经验。实现一个标准的过程和这个过程为开发组织提供的未来机会也将在本文中被关注。

介绍

本文被划分为五个部分。首先是一个简要的介绍,然后我们将讨论我们的开发工作,随后我们将讨论我们的部署工作、经验教训和对本文的总结。

这个案例研究是一个现实世界的真实的经历,它是关于我们的团队如何成功的开发和部署一个使用 RUP® 作为过程框架的迭代开发的方法的。这是福特公司和福特金融信贷公司共同工作的结果。福特金融信贷公司是福特公司的一个全资控股子公司,并且是汽车金融的最大供应商。我们在四十个国家为超过 11,000 个经销商提供车辆金融服务,并且自从 1959 年以来我们已经为超过五千万量汽车提供了贷款服务。我们以福特金融而闻名,通常媒体称我们为福特信贷。我们拥有超过 700 个职员的庞大的 IT 队伍。

我们的动机是什么呢?

我们很难跨越项目实现项目交付产物的共享。每一个团队都拥有自己的一套模板和他们自己的方法。当职员被从一个团队调到另一个团队时,他们必须学习新的方法。同时我们也很难利用公共团队。这些团队是外部的应用团队,他们提供良好的产品和项目服务。服务团队的例子包括象 DA 、DBA 、框架团队和构建团队。每个服务某一方面的应用团队都有不同的交付产物集合,因此他们没有一个公共的过程框架。

我们也有些晚的在项目中包含这些服务团队,因此导致了一些问题。人们在需要进入产品化阶段时才想起构建团队,而不是在适当的时候联系他们。

此外,我们的框架架构师一直被过程问题压的喘不过来气。框架架构师的工作是设计并维护我们的设计模式;相反他们一直被询问如何组织一个项目、什么过程应该被使用和项目应该有多少迭代。那不是他们的工作。

项目也正感觉到了另一个痛处:过晚的项目风险的识别。我们有一个必须连接数据仓库和为报告目的返回信息的项目。他们将这个需求留到了最后的时刻,并发现应用的性能不是足够快的。这对项目造成了很大的影响。

最重要的是,这种对拥有一个公共过程的努力是一个拉动的工作,而不是一个推动的工作。我们并没有在我们的组织中推进这种方法。而是我们被要求实施一个公共的软件开发过程。

我们为什么选择 RUP ?

在我们的组织中我们拥有一些在 RUP 方面的技术专长。我们也知道 RUP 是可以定制的。一些框架团队的人员说他们非常了解 RUP ,并起草了一份一页纸的 RUP 的概要,这显然是被过份的裁剪了。

我们也知道无论在公司内还是公司外我们都已经拥有丰富知识的资源。我们知道 RUP 提供了一个丰富的被在工业中清晰定义和良好理解的术语集合,我们也知道这是 RUP 真正的优势。RUP 的工业领先的位置给了我们和我们的管理层很大的信心。 RUP 是可以高度定制的,并且我们知道我们必须要做什么。

我们将如何按照我们的路线开始呢?

首先我们在六个项目中尝试使用 RUP ,这些项目覆盖了四个不同的业务领域。然后我们在公司论坛中推动大家对 RUP 的了解。RUP 已经在一些项目人员群体中有了一定的立足空间了,这给了我们很大的鼓励。我们确定了公司中的领域问题专家(SME)。然后我们开始了两个项目:一个负责开发 RUP 的自定义版本,另一个负责部署开发出来的自定义的 RUP 版本。我们的产出结果是我们称作为统一方案交付方法或者 USDM 的过程实例。它是基于 RUP 的,但是对于福特公司特定的组织和项目是需要定制的。例如,我们必须包括内部的控制考虑和我们的数据和记录的保留政策。此外,我们必须包括按照福特公司熟知的工作家族来定义角色。

USDM 也是非常注重实效的以保证实现真正的价值,甚至是对于快进度的项目,并且它也是足够灵活的以便我们能够使用它来满足我们众多项目的需要。

回页首

开发

我们将开发工作作为一个项目来实施。(见图 1)

3093_fig1

图 1:开发项目

我们有一个目标,这个目标是针对福特的需要创建一个健壮的并且注重实效的面向对象的开发过程。我们同时还确立了这样的目标:定制 RUP 、开发培训和定义一个支持的组织。我们的时间限定在六个月,我们拥有三个资源:三个方法专家将工作在这个项目中。

我们所要执行的步骤被列在图 2 中。

3093_fig2

图 2:在开发项目中的步骤

通过我们对 RUP 的实施 ,那六个我们尝试的项目,我们确定了 USDM 的进入标准。在福特信贷公司中所有的项目都必须使用对象技术。对于我们来说,就是 J2EE 。我们通过浏览 RUP 的产物准备我们过程中的产物,然后决定哪一个是我们需要的,哪一个是我们不需要的。之后我们为过程方法添加了福特特有的一些过程。在福特公司我们有很多我们自己的工作产物和被需要的过程。

我们文档化了服务团队的角色和职责以及这些不同的团队应该在一个项目中包括过程的哪些方面。我们也通过识别进入和退出初始、细化、构建和转换阶段意味着什么定义了阶段的出口标准。此外,我们创建了简化的工作流。我们接受了 RUP 中已有的工作流程,一些工作流程按照 RUP 中的定义那样使用,另一些被我们进行了有意义的简化。

我们细化了词汇表并合并添加了一个推荐的读物列表。我们创建了一些培训材料。此外,我们搜集了一些工作产物的样例并定义了我们的支持组织。最重要的是,我们创建了一个 Web 网站。所有的结果产物构成了 USDM 。

我们通过创造拥有权的感觉和将服务团队作为 SME 包含在项目当中合并了服务团队(组织外部的提供服务和向应用团队提供产品的应用团队)。然后我们确定服务团队过程的入口点 — 他们应该什么时候进入项目。这是非常重要的并且添加了很大的价值。接下来我们将服务团队的职责映射到了适当的活动或者工作流程中。我们建立了与服务团队管理层的良好关系,这一点对我们是非常重要的。

每一个项目都面临着挑战。我们遇到了组织的复杂性和鸡与蛋的问题。当我们尽力的改进我们过程时我们必须要进行培训,同时我们有好怀疑的指导团队的参与者。在我们尝试 RUP 实现过程中与我们一起工作的指导团队的一些经理是顽固的。经理们想要看到接下来六个月项目计划的每一个最终的细节,否则他们是不满意的。他们想预先知道每一件事情。我们必须说服他们这与他们管理的项目类型的做法是不同的。

在我们的 SME 中也存在着不一致的看法。无论什么时候进入专家们讨论的房间,你都会听到很多的看法,这些看法都是明确的针对我们的案例的。我们也很难协调在福特公司和福特信贷公司之间的工作(比如,什么时间在哪里我们应该进行会议)。

我们也很难拥有在福特公司和福特信贷公司的项目管理方法论。因为那些福特公司的管理人员,甚至虽然他们是我们项目的发起者,并不理解我们项目的管理方法论,因此对我们来说产生了一些问题。他们不理解什么应该被包括在项目中、一个项目的发起者意味着什么和他们的职责是什么。

总而言之,在 USDM 中我们有大约 20 个工作产物。我们也拥有定义良好的与服务团队的连接点。我们拥有简化了的工作流程。我们拥有定义良好的支持组织,包括指导服务,我们发现指导服务是极其重要的。我们的整个过程都在一个全面的网站上被描述出来。

当我们定制 RUP 的一个关键产物时我们引入了一个项目的章程,这个项目章程代替了 RUP 中的远景文档。我们创建了一个系统架构文档。我们采用了 RUP 中的系统架构文档,并对这个文档进行了一些重要的改变以满足福特公司和福特信贷公司的需要,同时也改变了文档的名字。我们也创建了一个有用的被称为风险用例映射的产物,它被用于根据用例划分风险的等级或者优先级。

图 3 显示了一些关键的产物。

3093_fig3

图 3:核心的产物

图 4 显示了我们定制的过程流程中的一个。

3093_fig4

图 4:需求工程流程

我们采用了 RUP 的工程流程,并和我们的领域问题专家一起检查了这些流程,然后我们在流程中添加了一些我们决定被需要的额外活动。

然后我们必须让组织了解 USDM ,这可以通过浏览我们建立的全面的网站来完成。我们也为高层和中层的管理人员进行了关于 USDM 的介绍。我们引导大家来了解 USDM 并在公司的面向对象的兴趣论坛中对 USDM 进行了介绍。这可以帮助我们使整个组织了解我们将要部署的新的方法论。

回页首

部署

在我们开发了 USDM 这后,我们需要将它部署到我们的组织中。这个工作也被作为一个项目来实施,见图 5 。

3093_fig5

图 5:部署项目

我们的目标是实现能够提供所有必要的支持和指导服务的 USDM 支持中心,以便 USDM 能够被容易的理解并在组织中使用。

我们的目标是建立一个支持中心的过程,产生和交付适当的培训材料,并且伴随过程的度量方法。

部署的步骤被显示在图 6 中。

3093_fig6

图 6:部署项目

部署交付物

我们建立了一个变更控制过程。我们定义了一个指导认证的过程和指导的程序。当我们想让服务团队了解我们的过程是怎样的并且他们应该在什么时候和如何使用我们的过程时,我们也为我们的服务团队开发了培训材料。然后我们定义并签署了服务团队协议。(这些协议的一个是关于框架团队的,我们知道他们希望在项目的早期就被包含进来)。最重要的是,我们向合格的项目交付和部署了指导服务。

我们的支持组织有两种武器,如图 7 所示。

3093_fig7

图 7:支持组织

一种武器是研究行业并开发和维护过程的产品。他们是支持团队持续改进的部分。另一种武器能够帮助应用团队。我们拥有指导人员来提供培训,我们觉得培训真的是非常的重要,并且已经使我们成功的应用过程。

我们也创建了一个描述变更控制过程如何工作的流程图。我们想包括适当的人员,利用已有的工具进行跟踪和记录我们的建议,并且建立一个变更控制委员会。变更控制委员会包括方法专家、项目指导人员、来自服务团队的领域问题专家和管理人员。这个小组决定建议是被采纳还是被拒绝。

指导

就像我们所提及的那样,我们的过程的一个重要的特点就是指导。好的指导能够帮助平滑的示范迁移。福特公司的大部分人员从事需求方面的所有工作、根据需求签署和约、分析和设计的工作、编码的工作和并交付能够在项目末尾阶段被集成在一个的软件产物。在我们的组织中有一些从事 Cobol 编程的人员,他们不懂任何关于面向对象编程的知识。存在大量的学习曲线要克服,我们的指导服务能够帮助消除这些学习曲线。

我们想要为这个过程确保跨组织的一致性。我们想要确保团队以项目的方式应用我们方法论,而不是在人们自己的思想趋向上使用他们。通过指导,我们获得了在过程上的立即反馈。我们希望积极的而不是被动的工作。我们想要在项目的一开始就参与其中,而不是当项目遇到麻烦时。我们的指导向各个团队展示了如何执行过程,甚至如果团队需要技术上的帮助,我们会帮助他们创建 UML 图。

过去我们仅仅是将一堆过程交给团队,然后说按照他们去做吧。结果却是非常的不好。我们也雇佣了一些顾问。他们向我们出售了一个大的过程,这过程成生了一个复杂的工作计划。过程中包括了很多任务,并且任务的名字与我们一直使用的名字是不同的。这一次我们决定我们需要手把手的指导来帮助我们的团队应用这个方法论,并且到此为止我们是成功的。

对于项目指导人员的要求是我们希望他们能够向对待病人一样始终如一的对待项目团队。他们需要具有坚实的方法论的经验。他们需要在 RUP 方面是训练有素的。他们也必须是迭代开发方面的专家。他们需要传授给项目团队可信性的技术上的经验。他们必须精通使用 UML 进行面向对象的分析与设计,并且知道如何进行项目管理。

通过我们与服务团队的协调,我们的指导人员被包括进了项目中。服务团队告诉我们项目开始时需要一名指导人员。作为一个可选的方法,我们在我们的网站上设置了一个请求按钮,以便项目能够请求一个指导人员。项目的管理沟通也应该包括指导人员。然而,我们认为指导人员的引入应该在项目管理和优先过程之前进行,而不是在项目随意的过程中引入指导人员。从开始和成为优先过程和项目管理的一部分,我们处于引入指导人员的早期阶段。福特信贷公司也有项目管理的指导人员。当项目管理的指导人员被引入到项目中时,我们希望我们的 USDM 指导人员也被引入到项目中。

我们如何度量我们指导服务的成功呢?

项目团队的感觉是一个衡量成功的方法。我们在细化和构建阶段结束时对我们指导的团队进行了调查。我们知道我们是成功的另一种方法是当我们认为我们的服务团队能够更早的在过程中工作时,我们就已经成功了。

还有一种确认我们成功的方法是在细化阶段后对指导的要求减少了。团队能够按部就班的工作,并且他们知道他们应该做什么,他们正确的去做了。在细化阶段结束时我们的指导人员已经不被需要了。我们已经拥有按时被完成并且被良好的开始使用项目。

今天我们在哪里与 USDM 一致?

自从 2002 年 5 月我们已经在 18 个项目中采用了 USDM 。由于指导的要求我们已经增强了从事支持的人员,我们雇佣了其他的指导人员,并且继续保持对管理的强有力的支持。我们也发现对于需求开发的培训要求。我们正在开始培训一些业务人员,以便当他们进入项目时知道如何开发用例。我们想预先的培训他们,使他们了解在定义需求方面领导工作是他们的职责。我们已经实现了很多的变更请求,虽然我们已经有了将变得更大的记录。

什么是我们计划增强的事情?

我们计划制定一个供所有福特信贷公司的项目使用的标准配置管理计划。我们觉得这将为项目添加大量的价值。每一个人都将按照相同的方式做事情。他们将拥有相同的构建结构和相同的目录结构并且这将为我们带来真正的好处。我们也拥有一个标准的参考实现模型以便我们所有的项目都能够从相同的系统架构框架开始。我们正着眼于为我们的外包工作制定过程。我们已经有了一个将六个 Sigma 的概念纳入我们过程的计划。我们有一个新的基于用例的项目计划。我们也有一个项目人员安排辅助和缺陷管理过程,他们将很快的被并入到 USDM 中。

回页首

经验教训

我们觉得我们没有正确的完成的事情之一是在开发和固定软件开发过程之前直到项目管理过程被完全制度化我们一直在等待。我们的项目经理们知道管理项目是什么样子。我们实际上使用了这个项目管理过程来管理我们的开发和部署项目。我们在所有的层次上获得了管理层的支持。中层管理人员是非常重要的,因为他们是与项目最接近的管理人员。我们将开发和部署工作独立出来。我们在早期就引入了服务组织的领域问题专家。我们雇佣了经验丰富的指导人员,他们拥有真正的资产。我们保持事情的简单化并适时的提供培训。

所范的错误

象很多项目一样,我们在得到适当的资源之前就承诺了日期。我们直到我们进入项目环境之前我们一直在等待培养业务团体。我们应该提早一点通知他们。我们花费了太多的时间来定制工作产物。我们过份的强调了我们已有产物和模板的重用,我们几乎总是回到 RUP 中,并对 RUP 的产物进行一些改动。我们花费了太多时间来讨论我们的入口标准。我们有大量的不同意见,尤其是与福特公司的人员。在我们开发这个方法论期间,我们也接受了一些具有错误技能的项目资源,并且我们低估了一些我们的项目交付产物,尤其是网站的开发。

回页首

结论

RUP 是一个良好的开始方法。它是一个非常好的框架,可以为福特这样的公司提供所有工具和必要的信息。这个框架是非常容易定制以满足我们的需要的。我们发现的一个重要的事情是集成是关键。 RUP 是一个打包的解决方案。如果你将它带入你的组织,你仍然必须做一些工作。你不能直接为一个项目使用它。在福特信贷公司我们拥有自己的项目管理过程和其他必须集成的过程。定制是重要的。最重要的是,对于我们来说指导是制度化象 RUP 这样的过程的基本要素。

我们得到的下一个结论是保持过程的简单性。我们有项目管理、六个 Sigma 、拥有自己过程的服务团队和 RUP 。我们应该尽量简洁、清晰的显示这些过程的连接点,这样可以产生更少的产物和有限的文书工作。

在最后的分析中我们觉得与你正在通过得到有价值的反馈支持的团队享受你们的成功乐趣是重要的。

网站演示 — 关键的特点

USDM 的一个关键特点是开发案例,一个我们用来为项目配置过程的重要产物。我们识别出了三个不同的项目类型:构建新应用的项目;对一个应用系统范围进行增强的项目;修改 bug 的维护项目。

使用用例模型,我们识别出对于哪些个迭代哪些用例要被开发。然后我们进行了初始的计划,计划中安排了迭代的时间。这就是我们如何开始每一个项目的。我们了解项目的范围,然后通过对时间线和迭代如何被定义的理解来创建定制的开发案例。然后开发我们的工作计划(进度表)。

基于项目的类型,我们建议哪些产物应该被使用。这是一个协作的团队工作。作为指导人员,我们与团队站在同一立场上,并讨论项目的需要。此外,在每次迭代和阶段的结束我们来确定被使用的产物是否是有价值的。如果产物没有提供价值,我们将停止使用它。

USDM 的另一个特点是为不同类型的项目工作流程的定制。对于增强或者维护项目的工作来说,你可能仅仅需要一定的活动;因此你可以重用已有的产物。例如,在增强路径的活动中,“设计用户界面”,我们也许只是检查已有的 GUI 以确定用户的交互,从而了解增强如何能够被集成到这个流程中。对于所有的工作流程或者活动,我们为增强类型的项目识别关键的事情。

过程的下一个关键特点是一个服务团队连接点的 Web 页面。我们为福特公司和福特信贷公司各建立了一个页面,因为我们每个公司有不同的服务要求。再一次说明,服务团队是提供公共资源的项目外的组织。服务团队的例子比如 DA/DBA 、可重用的团队、框架架构师、构建团队和生产管理。当应用团队使用服务团队连接点网页时他们了解在过程中服务团队应该在什么时候被联系。

USDM 的另一个关键特点是针对过程改进指导人员的使用。指导人员能够带来很大的帮助,因为他们能够始终如一的和不断的提供关于什么产物正在被使用、什么过程正在被使用和什么没有被有效的使用方面的反馈。我们就像记录变更请求一样记录了被建议的改进。然后变更控制委员会对于变更请求说可以或者不可以。如果答案是可以,我们就实施变更。

此外,我们保存了一个指导请求日值。当一个指导人员被分配到一个项目中时,我们记录一些信息,比如指导人员被估计参与项目指导的时间和针对项目的指导人员的资源分配。我们计划使用这些信息进行度量。我们正尽力的构建允许我们执行趋势分析的统计数据。我们希望使用这些信息来改经我们的过程。我们也从我们的用户得到过程改进的建议。他们使用一个简单的网站反馈表单来提交建议的改进。然后这些建议被提交到变更控制委员会。

对于培训,当团队开始一个项目时,我们为他们提供几个过程的展示。我们没有打印的过程指南。以前,福特公司的开发过程包括巨大的活页封面,有时是几卷的纸张。这一次我们决定将过程的每一件事情发布到网站上,并提供可下载的页面。这是节约成本的方法,但它的更大的好处是我们每两个月就要更新一些东西。人们可以访问这个网站,并可以得到他们需要的更新材料。我们认为这是一个有效的沟通过程和在过程中交流知识的方法。

USDM 过程的另一个特点是指导人员的网站。这个网站为我们的指导人员收藏了信息,包括一个文档化的指导过程。过程列出了当指导人员参加项目时他们要做的事情。他们要做的事情从初始阶段就开始了,也包括其他三个阶段。这是一个我们的指导人员要遵守的以在指导工作中促进一致性的指导方针。我们也有一个指导认证程序,新加入的指导人员必须通过这个认证过程以确保他们理解了福特公司和福特信贷公司特定的组织过程,从而使他们能够一致的指导我们的应用团队。

我们的 USDM 网站非常类似于 RUP 的过程工具,但用起来更加简单。在 RUP 中有更多的特性,我们主要是为我们的指导人员使用这些特性作为辅助的工具。我们的所有的工作产物和模板都存储在 USDM 网站上。

问题 & 解答

你什么时候开发 Web 网站,你使用了 WorkBench 或者 任何其他的 Rational 工具了吗?

我们唯一使用的工具是 RUP 的过程工具。我们没有使用 WorkBench 或者其他的工具。我们开发了我们自己的 Web 网站; RUP 不在下面。我们作为方法专家在我们的桌面是有 RUP ,但是团队并不能访问它。

在未来你将包括遗留的、非面向对象的开发吗?

目前来看,我们还没有这方面的计划。组织,福特公司,也有另一个 SDM ,被叫作 Classic SDM ,我们使用它来进行我们的主机系统和瀑布型的开发。那就是我们现在的计划,虽然我们有对 USDM 进行一些变化以使我们能够为两种开发使用我们的基于 RUP 的过程的想法,但是从策略上看还不能立即实施。目前来看,我们只是对我们的使用了对象技术的开发项目使用 USDM 。

在应用 RUP 后,你看到了在时间和质量上的改进了吗?

我的确看到了在质量上的改进。项目按时完成了,客户对项目更加的满意了。商业客户自始自终的被包括在项目中。他们能够更早的在细化阶段对系统进行测试,这导致在项目的后期有更少的痛苦。

什么样类型的信息被用来定义方法论的成功?

我们有一个正在进行的工作来定义一个能够证明价值和捕获一些其他关系的信息的度量模型。我们目前的基本反馈来自于我们的客户、我们的服务团队和我们指导管理的会议。此外,在项目结束的时候,我们有一个总结经验教训的会议,在会议中我们可以直接得到回复。我们有一个提交给项目经理和项目团队成员的评估表格,他们能够在过程和指导工作中提供反馈。

在时间上你的最大挑战是什么?

这个过程是非常简单的,并且很多人都想用它,但是我们没有足够多的支持人员。因为在福特信贷公司,一个非常大的组织,这个过程正慢慢的变成主流,我们没有足够的支持服务来为所有需要帮助的团队提供支持。第二点是我们只关注在 基于 OO 的项目、使用 J2EE 平台的项目和使用组件架构的项目上。如果你正工作在一个大的组织中,所有数据都被存储在主机系统中,那对我们来说将这个过程扩展到遗留类型的项目上挑战是巨大的。

你为什么将开发和部署分离开来?这样做对我们有什么意义?

我们做的第一件事是开发方法论。我们用了六个月开发这个方法论,然后用了另外五个月将它部署到我们的组织中。我们的 Web 网站在开发项目结束时是可得到的,然后在部署项目期间我们建立了指导服务。我们确定了指导的过程是怎样的,培训了我们的服务团队,并且与我们的服务团队达成了协定。

你指导的项目使用什么类型的迭代时间周期?

这依赖于项目,但是我们尽量的保持那些迭代在两周到六周,迭代的周期也依赖于什么被包括在项目中。指导人员与团队一起来帮助确定迭代的周期。

作者简介

Maureen Field has authored this article

Venkat Alladi has co-authored this article

 

参考:

http://topic.csdn.net/u/20090226/15/948dfe5d-9333-4396-b8b1-c510e47e27a8.html 这里面的有些观点值得考量

Continue reading 【转】一个学习案例: 使用 IBM Rational Unified Process 作为方法框架

【链】敏捷外包工程系列之三:固定合同(敏捷外包工程,敏捷开发,产品负责人,客户价值)

很实际的一篇关于敏捷的文章:
敏捷外包工程系列之一:序言(敏捷外包工程,敏捷开发,CMMI,软件外包,政府项目,银行项目,电信项目)

http://blog.csdn.net/cheny_com/article/details/6622656

 

摘录:

与敏捷开发相比,CMMI是更专业的外包管理模型,因为它的初衷就是“为美国国防部选择和管理供应商设定标准”。此标准具有法律效力,按照国防部规定只有3级以上企业才可称为承包商。但也正因为有了“美国”“国防部”“标准”这些定语和中心词,导致我们在一般外包中使用CMMI会感到困难。

对于这句话我觉得还是不能以外包与否来判断,而是说甲方对软件的需求严格程度,文中后面也谈到电信行业,银行行业,也存在属于外包类型的。还是“管理和技术永远要服从于业务”这句话经典!

 

管理和技术永远要服从于业务,从这一点上CMMI整体覆盖了部分业务和大多数管理和技术,而敏捷覆盖了部分管理和部分技术。笔者推荐以CMMI为整体模型,内部配合敏捷开发实践,而不是“用敏捷开发代替CMMI”

 

敏捷开发整体上适合小团队、产品研发(所以才有product owner一称)的环境,而外包软件开发中常常存在的则相反,因此在创建团队的时候要充分认识到这一点。

 

 

参见:

 敏捷开发沉思(真实对话) http://www.blogjava.net/pengpenglin/archive/2011/09/20/351552.html

硝烟中的Scrum和XP  http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches

敏捷不是过程,SCRUM只是框架,XP也是别人的实践 http://www.uml.org.cn/SoftWareProcess/2201012165.asp

RUP和敏捷方法的优缺点 http://www.szpm.org/forum/thread-33-1-1.html

Continue reading 【链】敏捷外包工程系列之三:固定合同(敏捷外包工程,敏捷开发,产品负责人,客户价值)

branch,tag,version,patch 分支,标签,版本,补丁

版本控制工具中平时使用的较多的是提交commit,更新update……,对于分支,标签,版本,补丁这些概念不是经常用,这篇文章介绍了分支版本,标签的使用场景:

CVS Branch 和 Merge 在 Eclipse 中的使用 http://blog.csdn.net/sanshiqiduer/article/details/2423936

Branch:

我们在version Release_1_0建立一个branch,比如叫做“Release_1_0_Branch”, 这时CVS会同时建立一个regular tag “Root_of_Releas_1_0_Branch”,这个“Root_of_Releas_1_0_Branch” tag的用途是为了以后branch 合并到main trunk时提供一个参考点。

之后开发新版本的人员就基于main trunk工作,而fix bug的人员就基于Release_1_0_Branch工作。
一旦在Release_1_0_Branch上将Release_1_0的bug修复了,我们就可以将Release_1_0_Branch合并到main trunk中来,从而一次性remove the bugs。

Merge:

fix bug之后,这时我们要把 Brank  merge main trunk 了。

1、选择 project -> Right click your project name, choose Replace With > Another Branch or Version from the context menu,
Then select the HEAD to replace with your current version in your workplace。

2、Select the project and choose Team > Merge.

在随后出现的对话框中,你首先选择regular tag ”Root_of_Releas_1_0_Branch”,然后在下一步中选择你的Branch“Release_1_0_Branch”。

3、Synchronize view中的操作

在第二步结束后,Synchronize view中将显示“all the differences between the branch and your workspace version(that is the HEAD version)”,你必须在Synchronize view中通过菜单中提供的“Update, Override and Update, or Mark as Merged”手工决定合并到你工作区的change。

4、在所有期望的changes都被merge到你的工作区后,你就可以“commit”the changes to the repository了。

 

tag作用:
1.指示你正工作在那个branch上。(因为每个branch都有一个tag.
2.如果你不想更新一个大目录树的一部分,你可以利用sticky   tag.
(sticky   tag的定义:If   you   check   out   a   certain   revision   (such   as   1.4)   it   will   become   sticky.  Subsequent   cvs   update   commands   will   not   retrieve   the   latest   revision   until   you   reset   the   tag   with   cvs   update   -A.)

什么情况下用branch:
若release1.0已经发布,现在正在开发2.0.这时发现在1.0中发现严重bug,但2.0的code还没有稳定,你就要从1.0建立一个branch.创建branch的时也要指定一个tag,同时文件的版本号都会改变。

补丁程序(patch)

是一个包含了某一资源的资源库实例和该资源的工作空间实例之间差别的文件。补丁程序可表示出一个单独文件(或完整项目)中的差别。补丁程序允许您共享尚未提交到CVS的更改。有很多原因使得补丁程序非常有用。

●       由于您没有向CVS提交资源的权限,所以您需要将该补丁程序发送给具有资源提交权限的人,然后再由他向CVS提交资源。

●       您需要为所遇到的问题准备一个应急修改或临时工作空间。

●       在将重要的更改提交到CVS之前,您可能想让别人对您的更改进行校验。在这种情况下,您可以将补丁程序发送给校验人以让他们进行测试。

通过使用快捷菜单Team | Create Patch…,我们就可以创建补丁文件。该操作会调用Create Patch向导来指导您完成补丁文件的创建。若要应用某补丁程序,则使用快捷菜单Team | Apply Patch…。该操作会调用Apply Patch向导。Eclipse联机文档Workbench User Guide的Working with patches 一节中有关上述两个操作的描述非常精彩。

补丁生成的是一个文本文件。包含了本地环境与已提交版本的区别,使用apply可以依据已提交版本再次生成本地环境。

Continue reading branch,tag,version,patch 分支,标签,版本,补丁

EAI中的应用集成和过程集成

书上抄网上,网上互相抄,一模一样的话,就是没看懂,还是这个解释的稍微清楚点:

应用层集成
应用层集成主要是指在通过应用接口对应用系统实现集成。应用接口(Application Programming Interface - API)是通用应用系统以及客户自建系统为方便和外部应用系统连接而对外开放的软件接口。目前时常上的一些标准商业软件,例如ERP系统,CRM系统,电子商务系统等,都有非常成熟的API。通过采用API层的应用集成,用户可以不对应用的数据库直接进行操作。

过程集成
过程集成是将不同单位部门、或不同企业的不同业务流程利用应用集成技术集成在一起,实现跨部门、跨系统、跨企业的流程共用。

Continue reading EAI中的应用集成和过程集成

面向对象的原则

1、"开-闭"原则——模块应对扩展开放,而对修改关闭。
2、里氏代换原则——如果调用的是父类的话,那么换成子类也完全可以运行。里氏代换原则是继承复用的一个基础。
3、合成复用原则——要少用继承,多用合成关系来实现。 --这也造成结构复杂,实现成本增加
4、依赖倒转原则——抽象不应该依赖与细节,细节应当依赖与抽象。 要针对接口编程,而不是针对实现编程。
5、接口隔离原则——每一个接口应该是一种角色,不多不少,不干不该干的事,该干的事都要干。
6、单一职责
7、迪米特法则——最少知识原则。不要和陌生人说话。--但这也造成不同模块通信效率低,产生大量传递简介调用的小方法。

 

这不过是对面向对象精髓的阐述:模块化,抽象,信息隐藏,高内聚,低耦合。

Continue reading 面向对象的原则

NoSQL对REST的影响,无状态,扩展性

infoq文章 http://www.infoq.com/news/2011/10/nosql-rest 谈到noSql可能对REST产生的影响。

REST要求状态要么被放入资源状态中,要么保存在客户端上。而这个资源就可以使用NoSql来存储,像Redis。

无状态通信最直接的理由就是可伸缩性—— 如果服务器需要保持客户端状态,那么大量的客户端交互会严重影响服务器的内存可用空间(footprint)。

 

参见:

http://www.infoq.com/cn/articles/rest-introduction  深入浅出REST

http://a-kuei.iteye.com/blog/706836  对REST中无状态(stateless)的理解

Continue reading NoSQL对REST的影响,无状态,扩展性

REST 将替代 SOAP?

infoq上看到这篇文章http://www.infoq.com/articles/rest-soap,其统计数据表明REST(在SOA中)越来越占主导优势。并在文章结尾为mule打了个广告,原来作者是MuleSoft的创始人。文章评论很多,打头的把emule和mule混淆,认为eMule(应该是mule)仍然解决不了根本的集成问题,后面的拿这个开涮!

写这篇文章时我对REST早闻其名,最近也用过,但是自己还觉得没怎么透彻的理解。不过由于早年深受webservice欺骗和xml的虐待,对soap一直深恶痛绝。使用rest基于json格式的服务后,感觉如此之美。

大执概括一下这篇文章:

Web API越来越火从2005的105个到2011的5000以上。

REST风格从2008年开始急剧上身(60%->74%),而SOAP上升缓慢(25%->15%)。

REST的上升要得益于客户端访问的便捷,json格式要比xml格式易懂,易用,简洁。目前大部分api都提供或只提供json格式。

后面就开始说各Api集成问题,然后提出使用mule解决。

Continue reading REST 将替代 SOAP?

冒烟测试 smoke test

没听过这个词的认为说它的人很牛X,了解了后会认为是装X,原来就是这么easy。

冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。

上面一句话很经典,冒烟测试:

  • 费时很短,吸根烟的功夫。
  • 是正式测试前的检验步骤,这个都没通过那就不能进行测试流程。
  • 关注改动,由编译人员或是修改者执行。

Continue reading 冒烟测试 smoke test

三级封锁协议两段锁以及隔离级别

并发控制的主要方法是封锁(Locking)。就是要用正确的方式调度并发操作,使一个用户的事务在执行过程中不受其他事务的干扰,从而避免造成数据的不一致性。
封锁是使事务对它要操作的数据有一定的控制能力。封锁通常具有3个环节:第一个环节是申请加锁,即事务在操作前要对它将使用的数据提出加锁申请;第二个环节是获得锁,即当条件成熟时,系统允许事务对数据进行加锁,从而事务获得数据的控制权;第三个环节是释放锁,即完成操作后事务放弃数据的控制权。
基本的封锁类型有以下两种: 锁是事务实现并发控制隔离级别的实现方法
1.排它锁(Exclusive Locks,简称X锁)
排它锁也称为独占锁或写锁。一旦事务T对数据对象A加上排它锁(X锁),则只允许T读取和修改A,其他任何事务既不能读取和修改A,也不能再对A加任何类型的锁,直到T释放A上的锁为止。
2.共享锁(Share Locks,简称S锁)
共享锁又称读锁。如果事务T对数据对象A加上共享锁(S锁),其他事务只能再对A加S锁,不能加X锁,直到事务T释放A上的S锁为止。
在对数据进行加锁时,另外需要约定并执行一些规则和协议,其中包括何时申请锁,保持锁的时间以及何时释放等,这些规则就称为封锁协议(Locking Protocol){谁定义的?-确实找不出来,也许就是理论基础},其总共分为以下三级:
(1)一级封锁协议。一级封锁协议是事务T在修改数据之前必须先对其加X锁,直到事务结束才释放。 防止丢失更新。
(2)二级封锁协议。二级封锁协议是事务T对要修改数据必须先加X锁,直到事务结束才释放X锁;对要读取的数据必须先加S锁,读完后即可释放S锁。 防止丢失更新和脏读

 T1T2 
 Slock A  
 读A=20
unlcok A 事务还没完成,但是读完了马上释放
  
  Xlock A 
  A = 60 
  Unclock A
事务提交
 
 SlockA  
 A=60
不可重复读
  
 T1事务造成了不可重复读  

(3)三级封锁协议。三级封锁协议是事务T在读取数据之前必须先对其加S锁,在要修改数据之前必须先对其加X锁,直到事务结束后才释放所有锁。 防止丢失更新,脏读,不可重复读

相对于二级锁,Slock的范围加长了,开销自然大了。

执行了封锁协议之后,就可以克服数据库操作中的数据不一致所引起的问题。

参看图4。

Snap2

从图4的情况我们看到事务T1在执行过程中独自占用并加X锁,直到处理完之后再释放锁,T2虽然也需要使用,但是在封锁协议的约束之下,T2所要求的X 锁就被拒绝,因此必须处于等待状态,直到T1释放之后,T2才获得使用的权利,这样就不会发生使用冲突,避免了数据的丢失。这里我们看到,此处实际上是执行了一级封锁协议。

下面我们看图5。

Snap3

通过图5,能够清楚的看到,由于施行了封锁协议,使事务T1使用了共享锁占用A,B两块数据,这样T2需要加上的X锁就无法实现,(如果是S锁,虽然可以加上,但也不能够随便修改数据,只是读取一下数据。)当T1释放锁之后,T2就可以得到并使用锁了,这样读取的数据B仍然还是100,不影响A+B的结果,这就是可重复读取。因此我们看到,其实这里用的就是三级封锁协议

 

参看图6,事务T1在对数据C修改之前,先加上了X锁,修改后写回数据库,这时T2请求在C上添加S锁,因为T1加了X锁,T2只好等待,当T1因为某种原因撤销了修改的数据后,C就恢复了原来的数据100,等T1释放 X锁后T2获得C上的S锁,读到的还是C=100,因此避免了读出“脏”数据。这里使用的其实就是二级封锁协议。

Snap1

 

两阶段封锁协议

对锁机制,保证事务可串行性的最常用协议是两阶段封锁协议。该协议要求每个事务分两个阶段提出加锁和解锁申请:

(1)增长阶段。事务可以获得锁,但不能释放锁。

(2)缩减阶段。事务可以释放锁,但不能获得锁。

一开始,事务处于增长阶段,事务根据需要获得锁。一旦该事务释放了锁,它就进入缩减阶段,不能再发出加锁请求。

两阶段封锁协议实现了事务集的串行化调度,但同时,一个事务的失败可能会引起一连串事务的回滚。为避免这种情况的发生,我们需要进一步加强对两阶段封锁协议的控制,这就是:严格两阶段封锁协议和强两阶段封锁协议。

严格两阶段封锁协议除了要求封锁是两阶段之外,还要求事务持有的所有排它锁必须在事务提交之后方可释放。这个要求保证未提交事务所写的任何数据,在该事务提交之前均以排它锁封锁,防止其他事务读取这些数据。

强两阶段封锁协议,要求事务提交之前不得释放任何锁。使用锁机制的数据库系统,要么使用严格两阶段封锁协议,要么使用强两阶段封锁协议。

两阶段封锁协议并不保证不会发生死锁,数据库系统必须采取其他的措施,预防和解决死锁问题。

 

数据库并发操作存在的异常情况:

1. 更新丢失(Lost update):事务 T1 读取数据 A,然后对 A 进行运算修改,最后写回数据库。如果在 T1 读取和写回数据库之间,有其他事务修改了 A 值,就造成了丢失更新,因为 T1 是在旧的数据上进行的运算。

第一类丢失更新(lost update): 在完全未隔离事务的情况下,两个事物更新同一条数据资源,某一事物异常终止,回滚造成第一个完成的更新也同时丢失。

第二类丢失更新(second lost updates):是不可重复读的特殊情况,如果两个事务都读取同一行,然后两个都进行写操作,并提交,第一个事务所做的改变就会丢失。

说他是第二类更新,又说他其实是不可重复读的特例,实际上在隔离级别上又和不可重复读相同,大部分分类根本不提这个第二类丢失更新。

2. 脏读取(Dirty Reads):一个事务读取了另一个未提交的并行事务写的数据。事务 T1 修改了数据 A,然后事务 T2 读取了数据 A,然后事务 T1 回滚了事务。则T2读的是错误的数据。

3. 不可重复读取(Non-repeatable Reads):一个事务对同一行数据重复读取两次但是却得到了不同结果。例如在两次读取中途有另外一个事务对该行数据进行了修改并提交

4. 幻读(Phantom Reads):也称为幻像(幻影,虚读)。事务在操作过程中进行两次查询,第二次查询结果包含了第一次查询中未出现的数据(这里并不要求两次查询SQL语句相同)这是因为在两次查询过程中有另外一个事务插入数据造成的。

幻读和不可重复读可认为是同类的,但是在控制上有区别。要控制不可重复读只需要控制记录的修改,而要控制幻读则要控制记录的添加和删除。所以,隔离级别可重复读取不能禁止幻读,而串行则可以。

 

事务隔离级别:

为了避免上面出现几种情况在标准SQL规范中定义了4个事务隔离级别,不同隔离级别对事务处理不同 。

1. 未授权读取(Read Uncommitted):也称未提交读。防止更新丢失(这不对应一级锁吗),如果一个事务已经开始写数据则另外一个数据则不允许同时进行写操作但允许其他事务读此行数据。该隔离级别可以通过“排他写锁”实现。事务隔离的最低级别,仅可保证不读取物理损坏的数据。与READ COMMITTED 隔离级相反,它允许读取已经被其它用户修改但尚未提交确定的数据。

2. 授权读取(Read Committed):也称提交读。1之上防止脏读取(这不对应二级锁吗)。这可以通过“瞬间共享读锁”和“排他写锁”实现,读取数据的事务允许其他事务继续访问该行数据,但是未提交写事务将会禁止其他事务访问该行。SQL Server 默认的级别。在此隔离级下,SELECT 命令不会返回尚未提交(Committed) 的数据,也不能返回脏数据。

3. 可重复读取(Repeatable Read):2之上防止不可重复读取(这不对应三级锁吗)。但是有时可能出现幻影数据,这可以通过“共享读锁”和“排他写锁”实现,读取数据事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务。在此隔离级下,用SELECT 命令读取的数据在整个命令执行过程中不会被更改。此选项会影响系统的效能,非必要情况最好不用此隔离级。

三级封锁协议并不能阻止幻读,修改的不能再被读取,但是新增(删除)的记录数可以统计。

4. 串行(Serializable):也称可串行读(这不对应两段锁吗)。提供严格的事务隔离,它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行。如果仅仅通过 “行级锁”是无法实现事务序列化的,必须通过其他机制保证新插入的数据不会被刚执行查询操作事务访问到。事务隔离的最高级别,事务之间完全隔离。如果事务在可串行读隔离级别上运行,则可以保证任何并发重叠事务均是串行的。

 

 LU丢失更新DR脏读NRR非重复读SLU二类丢失更新PR幻像读
未提交读 RUYYYYY
提交读 RCNNYYY
可重复读 RRNNNNY
串行读 SNNNNN

ORACLE的默认事务级别:READ COMMITTED

ORACLE支持的事务隔离级别:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET TRANSACTION ISOLATION LEVEL READ ONLY;

少数数据库默认的隔离级别为Repeatable Read, 如MySQL InnoDB存储引擎
即使是最低的级别,也不会出现 第一类 丢失 更新问题 .

查看InnoDB系统级别的事务隔离级别:

mysql> SELECT @@global.tx_isolation;
+-----------------------+
| @@global.tx_isolation |
+-----------------------+
| REPEATABLE-READ       |
+-----------------------+
1 row in set (0.00 sec)

查看InnoDB会话级别的事务隔离级别:

mysql> SELECT @@tx_isolation;
+-----------------+
| @@tx_isolation  |
+-----------------+
| REPEATABLE-READ |
+-----------------+
1 row in set (0.00 sec)

修改事务隔离级别:

mysql> set global transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)
mysql> set session transaction isolation level read committed;
Query OK, 0 rows affected (0.00 sec)

InnoDB的可重复读隔离级别和其他数据库的可重复读是有区别的,不会造成幻象读(phantom read)。

 

Oracle对隔离级别的支持:

Oracle 明确地支持READ COMMITTED(读已提交)和SERIALIZABLE(可串行化)隔离级别,因为标准中定义了这两种隔离级别。不过,这还不是全部。SQL标准试图 建立多种隔离级别,从而允许在各个级别上完成的查询有不同程度的一致性。REPEATABLE READ(可重复读)也是SQL标准定义的一个隔离级别,可以保证由查询得到读一致的(read-consistent)结果。在SQL标准的定义 中,READ COMMITTED不能提供一致的结果,而READ UNCOMMITTED(读未提交)级别用来得到非阻塞读(non-blocking read)。

不 过,在Oracle中,READ COMMITTED则有得到读一致查询所需的所有属性。在其他数据库中,READ COMMITTED查询可能(而且将会)返回数据库中根本不存在的答案(即实际上任何时间点上都没有这样的结果)。另外,Oracle还秉承了READ UNCOMMITTED的“精神”。(有些数据库)提供脏读的目的是为了支持非阻塞读,也就是说,查询不会被同一个数据的更新所阻塞,也不会因为查询而阻 塞同一数据的更新。不过,Oracle不需要脏读来达到这个目的,而且也不支持脏读。但在其他数据库中必须实现脏读来提供非阻塞读。

        除 了4个已定义的SQL隔离级别外,Oracle还提供了另外一个级别,称为READ ONLY(只读)。READ ONLY事务相对于无法在SQL中完成任何修改的REPEATABLE READ或SERIALIZABLE事务。如果事务使用READ ONLY隔离级别,只能看到事务开始那一刻提交的修改,但是插入、更新和删除不允许采用这种模式(其他会话可以更新数据,但是READ ONLY事务不行)。如果使用这种模式,可以得到REPEATABLE READ和SERIALIZABLE级别的隔离性。
        所以,Oracle对隔离级别的支持如下:
1.SERIALIZABLE:支持
2.READ ONLY:Oracle特有的级别,利用它来实现对REPEATABLE READ的支持
3.READ COMMITTED:支持
4.READ UNCOMMITTED:不明确且不完全地支持

 

参见:

http://seaizon.iteye.com/blog/571139

http://wenku.baidu.com/view/2f89710879563c1ec5da7130.html

http://yjhexy.iteye.com/blog/658706

http://www.cnblogs.com/ityfei/articles/1502153.html

http://heysql.com/mysql/%E5%9F%BA%E7%A1%80%E7%9A%84%EF%BC%9A%E5%B0%81%E9%94%81%E5%8D%8F%E8%AE%AE%EF%BC%8C%E9%94%81%E7%B1%BB%E5%9E%8B%EF%BC%8C%E8%84%8F%E8%AF%BB%E3%80%81%E4%B8%8D%E5%8F%AF%E9%87%8D%E5%A4%8D%E8%AF%BB%E5%92%8C/

Continue reading 三级封锁协议两段锁以及隔离级别

Notepad++ 使用技巧

早就听说过Notepad++大名,最近用了下,觉得挺不错。

可以使用主题配色,看文本舒服多了。我最喜欢Rubyblue。

配合插件NppFTP: notepad++ ftp插件,查看服务端日志方便多了。修改文本文件自然不在话下。我想用这个修改服务器上的php文件岂不很好。

之前格式化个xml还要用专门的xml工具,使用nodepad++的xml tools插件,使用它的pretty print(line break)功能就能很好的格式化。

要格式化json或者javascript,可以使用jsmin插件中的jsformat功能。

常用快捷键:

Ctrl+L 删除行

Ctrl+D复制行

Ctrl+W关闭当前编辑页

Ctrl+Alt+鼠标 纵列选择

Ctrl+M批量修改文件

Continue reading Notepad++ 使用技巧

Pagination


Total views.

© 2013 - 2020. All rights reserved.

Powered by Hydejack v6.6.1