方法概要
1975年，M．A．Jackson提出了一类至今仍广泛使用的软件开发方法。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。
Jackson方法有时也称为面向数据结构的软件设计方法。
1
分析并确定输入数据和输出数据的逻辑结构，并用Jackson结构图来表示这些数据结构
分析并确定输入数据和输出数据的逻辑结构，并用Jackson结构图来表示这些数据结构。
2
找出输入数据结构和输出数据结构中有对应关系的数据单元
找出输入数据结构和输出数据结构中有对应关系的数据单元。
3
按既定规则由输入、输出的数据结构导出程序结构
规则一：对每对有对应关系的数据单元，按照它们在数据结构图中的层次在程序结构图的相应层次画一个处理框。
规则二：根据输入数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。
规则三：根据输出数据结构中剩余的每个数据单元所处的层次，在程序结构图的相应层次分别为它们画上对应的处理框。
4
列出基本操作与条件，并把它们分配到程序结构图的适当位置
列出基本操作与条件，并把它们分配到程序结构图的适当位置
5
用伪码写出程序
与三种基本结构对应的伪码是：
顺序结构：
A seq
B
C
D
A end
选择结构：
A select cond1
B
A or cond2
C
A or cond3
D
A end
重复结构：
A iter until (或while) cond
B
A end
示例:
图中的“O”表示选择，“*”表示重复；在顺序结构中，表示A由B和C两部分组成；在选择结构中，表示A可以包古B或c；在循环结构中，表示A由B重复H次组成。
Jackson图具有如下优点：
(1) 便于表示层次结构，是对结构进行自顶向下分解的有力工具。
(2) 形象直观可读性好。
(3) 既能表示数据结构也能表示程序结构（因为程序结构也只有上述三种基本类型）。
缺点是:
用这种图形工具表示选择或重复结构时,选择条件或循环结束条件不能直接在图上表示出来,影响了图的表达能力,也不易直接把图翻译成程序,此外,框间连线为斜线,不易在行式打印机上输出.为了解决上述问题,我们建议使用改进的Jackson图.
面向数据流的分析方法
1975年，英国人M.A.Jackson提出了软件工程领域中著名的Jackson方法，当时它只用于软件设计。1983
年，Jackson又对它进行了多方面的扩充和完善，最终发展成为一种需求分析方法。其核心思想是：根据作用于数据的行为序列的结构（顺序、选择、重复），建立目标软件系统的模型，然后在软件设计阶段将模型转换为相应的程序结构 。
Jackson方法在需求分析阶段的主要步骤是：
（1）标识实体与行为。
（2）生成实体结构图。
（3）创建软件系统模型。
类似于面向对象分析中对象及其行为的识别，Jackson方法针对初步需求分析形成的用户需求描述进行语法分析：
名词及名词短语——潜在的实体，
相关的动词——构成实体的潜在行为。
分析人员根据应用问题的边界及自己的理解，决定对潜在实体和行为的取舍。
在Jackson方法中，实体结构是指实体在时间坐标系中的行为序列。这种序列以顺序、选择和重复三种结构
进行复合。Jackson给出的实体结构图的表示机制如图所示。其中的子结点既可以是行为，也可以是
子实体。在后一种情况下，子实体应该继续分解，不能作为实体结构图的叶结点。
参见:
http://210.42.160.49/wangluokejian/%E8%AF%BE%E4%BB%B6PPT/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B%E6%9C%AC%E7%A7%91/%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8BPPT/%E7%AC%AC%E4%BA%94%E7%AB%A0.ppt 面向数据结构的设计方法
http://211.64.47.133/web/kcghjs/wwb_rjgc/subject/kejian/7.pdf 面向数据的分析方法
Continue reading Jackson设计方法和JACKSON分析方法
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）
图 1:开发项目
我们有一个目标，这个目标是针对福特的需要创建一个健壮的并且注重实效的面向对象的开发过程。我们同时还确立了这样的目标：定制 RUP 、开发培训和定义一个支持的组织。我们的时间限定在六个月，我们拥有三个资源：三个方法专家将工作在这个项目中。
我们所要执行的步骤被列在图 2 中。
图 2:在开发项目中的步骤
通过我们对 RUP 的实施 ，那六个我们尝试的项目，我们确定了 USDM 的进入标准。在福特信贷公司中所有的项目都必须使用对象技术。对于我们来说，就是 J2EE 。我们通过浏览 RUP 的产物准备我们过程中的产物，然后决定哪一个是我们需要的，哪一个是我们不需要的。之后我们为过程方法添加了福特特有的一些过程。在福特公司我们有很多我们自己的工作产物和被需要的过程。
我们文档化了服务团队的角色和职责以及这些不同的团队应该在一个项目中包括过程的哪些方面。我们也通过识别进入和退出初始、细化、构建和转换阶段意味着什么定义了阶段的出口标准。此外，我们创建了简化的工作流。我们接受了 RUP 中已有的工作流程，一些工作流程按照 RUP 中的定义那样使用，另一些被我们进行了有意义的简化。
我们细化了词汇表并合并添加了一个推荐的读物列表。我们创建了一些培训材料。此外，我们搜集了一些工作产物的样例并定义了我们的支持组织。最重要的是，我们创建了一个 Web 网站。所有的结果产物构成了 USDM 。
我们通过创造拥有权的感觉和将服务团队作为 SME 包含在项目当中合并了服务团队（组织外部的提供服务和向应用团队提供产品的应用团队）。然后我们确定服务团队过程的入口点 — 他们应该什么时候进入项目。这是非常重要的并且添加了很大的价值。接下来我们将服务团队的职责映射到了适当的活动或者工作流程中。我们建立了与服务团队管理层的良好关系，这一点对我们是非常重要的。
每一个项目都面临着挑战。我们遇到了组织的复杂性和鸡与蛋的问题。当我们尽力的改进我们过程时我们必须要进行培训，同时我们有好怀疑的指导团队的参与者。在我们尝试 RUP 实现过程中与我们一起工作的指导团队的一些经理是顽固的。经理们想要看到接下来六个月项目计划的每一个最终的细节，否则他们是不满意的。他们想预先知道每一件事情。我们必须说服他们这与他们管理的项目类型的做法是不同的。
在我们的 SME 中也存在着不一致的看法。无论什么时候进入专家们讨论的房间，你都会听到很多的看法，这些看法都是明确的针对我们的案例的。我们也很难协调在福特公司和福特信贷公司之间的工作（比如，什么时间在哪里我们应该进行会议）。
我们也很难拥有在福特公司和福特信贷公司的项目管理方法论。因为那些福特公司的管理人员，甚至虽然他们是我们项目的发起者，并不理解我们项目的管理方法论，因此对我们来说产生了一些问题。他们不理解什么应该被包括在项目中、一个项目的发起者意味着什么和他们的职责是什么。
总而言之，在 USDM 中我们有大约 20 个工作产物。我们也拥有定义良好的与服务团队的连接点。我们拥有简化了的工作流程。我们拥有定义良好的支持组织，包括指导服务，我们发现指导服务是极其重要的。我们的整个过程都在一个全面的网站上被描述出来。
当我们定制 RUP 的一个关键产物时我们引入了一个项目的章程，这个项目章程代替了 RUP 中的远景文档。我们创建了一个系统架构文档。我们采用了 RUP 中的系统架构文档，并对这个文档进行了一些重要的改变以满足福特公司和福特信贷公司的需要，同时也改变了文档的名字。我们也创建了一个有用的被称为风险用例映射的产物，它被用于根据用例划分风险的等级或者优先级。
图 3 显示了一些关键的产物。
图 3:核心的产物
图 4 显示了我们定制的过程流程中的一个。
图 4:需求工程流程
我们采用了 RUP 的工程流程，并和我们的领域问题专家一起检查了这些流程，然后我们在流程中添加了一些我们决定被需要的额外活动。
然后我们必须让组织了解 USDM ，这可以通过浏览我们建立的全面的网站来完成。我们也为高层和中层的管理人员进行了关于 USDM 的介绍。我们引导大家来了解 USDM 并在公司的面向对象的兴趣论坛中对 USDM 进行了介绍。这可以帮助我们使整个组织了解我们将要部署的新的方法论。
回页首
部署
在我们开发了 USDM 这后，我们需要将它部署到我们的组织中。这个工作也被作为一个项目来实施，见图 5 。
图 5:部署项目
我们的目标是实现能够提供所有必要的支持和指导服务的 USDM 支持中心，以便 USDM 能够被容易的理解并在组织中使用。
我们的目标是建立一个支持中心的过程，产生和交付适当的培训材料，并且伴随过程的度量方法。
部署的步骤被显示在图 6 中。
图 6:部署项目
部署交付物
我们建立了一个变更控制过程。我们定义了一个指导认证的过程和指导的程序。当我们想让服务团队了解我们的过程是怎样的并且他们应该在什么时候和如何使用我们的过程时，我们也为我们的服务团队开发了培训材料。然后我们定义并签署了服务团队协议。（这些协议的一个是关于框架团队的，我们知道他们希望在项目的早期就被包含进来）。最重要的是，我们向合格的项目交付和部署了指导服务。
我们的支持组织有两种武器，如图 7 所示。
图 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 作为方法框架
版本控制工具中平时使用的较多的是提交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 分支，标签，版本，补丁
书上抄网上，网上互相抄，一模一样的话，就是没看懂，还是这个解释的稍微清楚点：
应用层集成
应用层集成主要是指在通过应用接口对应用系统实现集成。应用接口（Application Programming Interface - API）是通用应用系统以及客户自建系统为方便和外部应用系统连接而对外开放的软件接口。目前时常上的一些标准商业软件，例如ERP系统，CRM系统，电子商务系统等，都有非常成熟的API。通过采用API层的应用集成，用户可以不对应用的数据库直接进行操作。
过程集成
过程集成是将不同单位部门、或不同企业的不同业务流程利用应用集成技术集成在一起，实现跨部门、跨系统、跨企业的流程共用。
Continue reading EAI中的应用集成和过程集成
1、"开－闭"原则——模块应对扩展开放，而对修改关闭。
2、里氏代换原则——如果调用的是父类的话，那么换成子类也完全可以运行。里氏代换原则是继承复用的一个基础。
3、合成复用原则——要少用继承，多用合成关系来实现。 --这也造成结构复杂，实现成本增加
4、依赖倒转原则——抽象不应该依赖与细节，细节应当依赖与抽象。 要针对接口编程，而不是针对实现编程。
5、接口隔离原则——每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。
6、单一职责
7、迪米特法则——最少知识原则。不要和陌生人说话。--但这也造成不同模块通信效率低，产生大量传递简介调用的小方法。
这不过是对面向对象精髓的阐述：模块化，抽象，信息隐藏，高内聚，低耦合。
Continue reading 面向对象的原则
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?
