~~点滴积累~~~

我的最新日志

  • 什么是CMM和CMMI？(转)

    2008-8-18

    CMM是由美国软件工程学会(Software Engineering Institute)制定的一套专门针对软件产品的质量管理和质量保证标准。该标准最初是为美国军方选择软件产品提供商时评价软件企业的软件开发质量保证能力而制定，所以称为软件企业能力成熟度模型(Capability Maturity Model,简称CMM）。该标准将软件企业的能力成熟度划分为５个等级，级别越高表明该企业在提供合格软件产品方面的能力越强。 
    m Tf@~Q0   CMM（Capability Maturity Model）是能力成熟度模型的缩写。CMM的工作最早开始于1986年11月，当时为了满足美国联邦政府评估软件供应商能力的要求，美国卡内基·梅隆大学的软件工程研究院SEI牵头，在Mitre公司的协助下，于1987年9月发布了一份能力成熟度框架（Capability Maturity Framework)以及一套成熟度问卷（Maturity Questionnaire)．很多人认为这套问卷就代表了CMM模型，其实它只是用于探索软件过程成熟度的一个工具，真正的模型出现在四年以后。SEI总结了自1987年以来对成熟度框架和初版成熟度问卷的实战经验，并以此为基础，推出了CMM1.0版。这个推出于1991年的CMM1.0集中了四年来对软件公司评估的经验以及广泛的用户反馈，在成熟度框架的基础上建立了一个可用的模型，这个模型可以更加有效地帮助软件企业建立和实施过程改进计划。51Testing软件测试网!N4mC!_{T
       CMM1.0版使用两年之后，于1992年四月进行了一个研讨会，参加研讨会的有约两百名富有经验的软件专业人员。在广泛听取了他们的反馈意见之后，SEI于1993年推出了CMM1.1 版。近几年来，CMM又推出了2.0版本，同时进入了ISO体系，称为 ISO/IEC15504 或SPICE。SPICE从1995年起进入实地测试阶段，可能于2001年发布 。

        五级的具体定义如下:

        初级(initial)：软件开发过程中偶尔会出现混乱的现象,只有很少的工作过程是经 过严格定义的,开发成功往往依靠的是某个人的智慧和努力。 

        可重复的(repeatable)：建立了基本的项目管理过程。按部就班地设计功能、跟踪 费用 ,根据项目进度表进行开发。对于相似的项目,可以重用以前已经开发成功的部分。

        被定义的(defined.)：软件开发的工程活动和管理活动都是文档化、标准化的,它 被集成为一个组织的标准的开发过程。所有项目的开发和维护都在这个标准基础上进行定 制。

        被管理的(managed.)：对于软件开发过程和产品质量的测试细节都有很好的归纳, 产品和开发过程都可以定量地分解和控制。

        优化的(optimizing)：通过建立开发过程的定量反馈机制,不断产生新的思想,采用 新的技术来优化开发过程。
    /Q l._4a0O3I-w7F0 
    r^@a L~0    模型的等级从低到高，可以预计企业的开发风险越来越低，开发能力越来越高。除模型的第1级外，其他每个等级都由不同的过程区域构成，而每个过程区域又由各种目标构成，每个目标由各种实践支持（实践分为该目标特有的特殊实践和各种目标均适用的通用实践两种形式）。51Testing软件测试网(c8Z3I9i6i&E~~
     51Testing软件测试网+BJ7I9O-P2?m
         一个组织只要开始从事软件开发，即自动处于第1级，要通过其他等级，就需要达到统一的标准，即相对应等级中的各个区域过程。
    Y?e^Tgh_0 51Testing软件测试网9Z?S$u6x_
         CMM2级过程区域有7个：需求管理、项目策划、项目监督和控制、供方协定管理、测量和分析、过程和产品质量保证、配置管理。
    L*O$bKBR c0 
    SL(O.iQ-mo E@ f J"{0     CMM3级过程区域有11个：需求开发、技术解决、产品集成、验证、确认、组织过程聚焦、组织过程定义、组织培训、集成项目管理、风险管理以及决策分析和决定。 51Testing软件测试网HV R,Ym-?S{
         CMM4级过程区域有2个：组织过程性能和定量项目管理。
    MeOc2C0     CMM5级过程区域有2个：组织革新和部署、原因分析和决定。51Testing软件测试网 Z:U8k/Pn`2Ta/g9i
         当一个软件组织按照CMM的要求贯彻活动，并达到预期的效果，该组织就可以被认为是达到CMM的要求。

        cmm和iso9001的出发点都是通过对生产过程进行管理,来确保产品的质量。虽然它们 之间有很多区别,但也有相似之处。比如,通过iso9001认证的组织,可以基本满足cmm二级 的标准和很多cmm三级的要求。因为cmm中的很多要求并没有列入iso9000标准之中,所 以,cmm一级的组织也可能获得iso9001的登记,defined.同样,有些iso9001规定的内容并没 有列入cmm标准。一个cmm三级组织获得iso9001认证几乎没有困难,cmm二级组织申请 iso9001认证也有明显优势。51Testing软件测试网*xN9PTyt.? zYv ]
        引进CMM的意义有两个方面
    :P;NX5X#XG0 
    k f&Cb*MK0１．对软件企业： 提高软件开发的管理能力：CMM提供了软件企业自我评估的方法和自我提高的手段；提高软件生产率；加强软件生产的国际竞争力。
    ~Ao9r$d2Kf0 
    :u1z;s;w)}Y$|0２．对软件项目发包单位和软件用户： 提供了对软件开发商开发管理水平的评估手段，有助于软件开发项目的风险识别。
    +dOYLb0 51Testing软件测试网#NY/i8R_ a/V
        何谓CMMI？
    0l S"i{;h1c!f,cY+hE W0     CMMI全称是Capbility Maturity Model Integration，即集成的能力成熟度模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制，与2002年4月推出了系统工程和软件工程的集成成熟度模型。CMMI是一套融合多学科的、可扩充的产品集合，同时也是工程实践与管理方法。 51Testing软件测试网P@2U7NK3f6h
    　　CMMI能够解决现有的不同CMM模型的重复性、复杂性，并减少由此引起的成本、缩短改进过程，她将软件CMM2.0版草案(SW-CWW)、EIA过渡标准731(系统工程CMM)及IPD-CMM集成为一体，同事还与ISO15504相兼容。与原有的能力成熟度模型CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。

    　　CMMI自出道以来，它所达到的目标就没有变过，第一个是质量，第二个是时间表，第三就是要用最低的成本。不过特别强调的是，CMMI不是传统的、仅局限于软件开发的生命周期，它应该被运用于更广泛的一个范畴——工程设计的生命周期。TSP的建立，也是为了支持CMMI的这样一个系统。

    　　那么CMMI究竟是什么呢？它并不是一个过程，也不是告诉你怎么去做一件事情。如果用一句话来概括什么是CMMI，它就是各个进程的一个关键的元素，在很多领域里面一个集成的点。它是这样的一个基本架构，能够用来度量你的有效性和实用性；能够找出这样的一些机会，继续改进的机会，包括在商业目标、策略还有降低项目的风险等方面。

    　　CMMI与CMM的区别呢？CMMI即CMM集成，是系统工程和软件工程的集成成熟度模型，CMMI更适合于信息系统集成企业。CMMI是在CMM基础上发展起来的，它继承并发扬了CMM的优良特性，借鉴了其他模型的优点，融入了新的理论和实际研究成果。它不仅能够应用在软件工程领域，而且可以用于系统工程及其他工程领域。

    查看(46) 评论(0)

  • 工作流现状

    2008-8-06

    前言

        如果数据库系统（ database systems）像受人尊敬的智者讲述的条理清晰的故事，那么工作流（workflow）就像一群乳臭未干的小子在大谈各自的“哲理”。之所以这样讲，我是想指出，工作流系统 （workflow management systems）还处于技术发展曲线（ technology hype curve）上的初级阶段。在这个领域我们将面临一个激动人心的阶段。 为了描述这一点，可以将工作流和关系数据库系统（RDBMS）做一个对比。当在软件开发团队中谈论RDBMS时，大部分人会有一个清晰的概念，在你和他们交流的时候，人们会通过轻微的点头表示认可或理解你所说的。可当使用工作流术语讨论工作流时，他们会摇头表示不同意，因为每个人对工作流术语都有不同的理解。

    the technology hype graph
    Figure 1: Workflow vs. RDBMS positioned in the hype-curve

        导致形成这种状况的原因之一，是在工作流中使用了过多的概念。在这个领域中的大量规范和工具没有一个是相似的。当然，它们相互之间有重叠并且会相互参考引证。
        在介绍工作流时有一个话题必须包括，那就是工作流和业务流程管理（BPM）的关系。术语“工作流”通常描述人与计算机系统的一系列相关交互。在开发人员中，工作流经常被提及。有时，工作流的意思是指一些不同的UI界面。业务流程管理的范围比较广，相比之下工作流多半局限于技术领域。业务流程管理还从管理人员的角度涉及了非技术问题，比如分析、组织的效率。

        在本文中，我首先解释什么是工作流管理系统，然后介绍业务流程管理的优点。接下来描述一下为什么工作流市场乍看起来如此混乱。本文给出的主要结论是：选择工作流系统是想用工作流系统的公司，将要面对的最困难的事情。为此，本文的核心部分描述了一个流程定义（process definition）的四个层次，为你选择工作流提供一个基础。本文还用中立的语言描述了工作流和BPM的通用概念。最后，给出了一些规范和工具的指导性描述。

    什么是工作流管理系统（WFMS）

    定义

        工作流系统是以规格化的流程描述作为输入的软件组件,它维护流程的运行状态,并在人和应用之间分派活动。

        为了后面的描述，我们先定义一些基本的术语：流程定义（process definition）和流程实例（process instance）. 一个流程定义是一个业务流程或过程的规格化描述。一个流程实例是流程定义的一个运行实体。 都目前为止，概念还比较清晰是不是？但当再深入一步时，我们就要小心使用文字了。如何阐述流程中的步骤，现在还没有一个统一的方式。这是各种工作流规范和工具之间主要的分歧。

    为什么应当禁止使用术语“活动（activity）”...
        流程定义通常用一些活动表述。我认为这是导致工作流领域所有混乱的主要原因。我告诉你为什么：因为术语“活动”混淆了状态（state）和动作（action）之间的差异。在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。在流程运行时，这意味着流程引擎必须等待，直到外部参与者通知工作流管理系统指定的状态完成了。比如，等待可进一步运行的认可。动作是在流程运行过程中，工作流系统为响应指定事件（event）运行的一段程序逻辑（programming logic）。当流程运行过程中指定的事件发生时，工作流系统启动并执行这些动作。比如，当状态分配给一个参与者时，发一封Email。你也能看出，状态和动作是如此不同，因此使用同样的术语去描述这些概念是一个坏习惯。我的建议是避免使用术语“活动”，使用“状态”或者“动作”代替它。

        工作流系统另一个重要的职责是维护每一个流程运行的上下文信息。 流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。如，休假申请的开始日期、数据库中一条记录的键值、文档管理系统中一篇文档的索引等。通常在流程定义中声明这些变量，然后在流程实例生成时，这些流程变量被实例化。所有成熟的工作流管理系统都支持定制的变量类型。

    目标领域（Target usage）

        使用工作流管理系统的目的之一是作为企业应用系统集成（EAI）的平台。在当前大部分企业级IT架构中，各种各样的异构（heterogeneous）应用和数据库运行在企业内网中。在这些系统被应用到组织时，都有一个清晰的目标。例如，客户管理、文档管理、供应链、订单、支付、资源计划等等。让我们称这些系统为专门应用（ dedicated applications）。每一个专门应用都包含它们所支持业务流程的领域知识。这些专门应用中的自动化流程，被拼装到企业中更大的非自动化流程中。每当一个这样的专门应用安装并投入使用，都会带来涉及其他多个应用的新功能需求。企业应用系统集成（EAI）就是通过使用多个专门应用满足软件新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。可以这么说，在你购买专门应用时，你是购买了一组固定的自动化业务流程。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活（当然你也要花精力编写业务流程的规格化描述）。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。如果专门应用支持你所需要的业务流程，那么使用专门应用。在此讨论的工作流系统的第一种使用方式就是：结合所有的专门应用，使用工作流系统构建一个EAI平台。

        工作流系统能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。对于专注于ISO 或者CMM认证的组织，采用这种方式使用工作流系统能够显著提高生产率。 不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化（如使用基于Web的应用）。

        工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在前面我们谈到，专门应用将指定问题域相关的业务流程固化在软件中。开发专门应用的公司也可以将工作流引擎嵌入到他们的软件中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用（不重复发明轮子）和应用软件的可维护性。

    The case for workflow

        对于引入工作流的组织，能够在软件开发和业务两个层次受益。

    方便开发

        工作流管理系统能够简化企业级软件开发甚至维护。

    • 降低开发风险 - 通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。
    • 实现的集中统一 -业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中 。
    • 加快应用开发 - 你的软件不用再关注流程的参与者，开发起来更快，代码更容易维护。

    业务流程管理 (BPM)

        在自动化业务流程之前，分析并将它们规格化是一件艰苦但会有很好回报的工作。e-workflow.org对于分析流程能够带了的益处有不错的阐述：

    • 提高效率 - 许多流程在自动化过程中会去除一些不必要的步骤
    • 较好的流程控制 - 通过标准的工作方法和跟踪审计，提高了业务流程的管理
    • 改进客户服务 - 因为流程的一致性，提高了对客户响应的可预见性
    • 灵活 - 跨越流程的软件控制，使流程可以按照业务的需要重新设计。
    • 业务流程改进 - 对流程的关注，使它们趋向于流畅和简单

        我认为他们还遗漏了一个使用工作流系统最重要的因数：提高对迭代开发的支持。如果软件中业务流程部分不容易更改，组织就会花很大的精力在开发前的业务流程分析中，希望一次成功。但可悲的是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。

    缺失的一环（Missing link）

        我确实认为工作流系统是企业应用开发中缺失的一环。将企业业务流程逻辑在企业级软件中实现的缺省方式是分散的。这意味着业务流程逻辑散布在各种系统中，如EJB、数据库触发器、消息代理等等。这样得到的软件难于维护，结果，企业只能将改变业务流程软件作为最后的选择。他们经常能够做的是，改变流程以适应软件。上述问题也适用于采用大型外部ERP软件包的企业。进一步，假设我们认识到这个问题，并打算将一个流程相关的代码都集中起来。对于一个流程来说这很不错，但当你要实现多个流程时，你会看到管理状态和流程变量的代码被到处复制。最后，我们会整理这些代码放到一个集中的库中。好，...这就是一个工作流管理系统了，不用费心自己来实现，你可以从本文后面的列表中选择一个。

    A closer look

    WFMS interfaces

        一个工作流管理系统以流程定义作为输入。在这里，可以将流程定义看作UML活动图、UML状态图或者有限状态机。在提交一张费用单据、申请休假、要求一个报价、...之后，工作流系统负责维护这些流程定义的执行状态和上下文。为此，需要通知工作流系统状态的变化。运行流程的状态变化可以记录下来，以备监控管理。


    Figure 2: Interfaces of a WFMS

    • 定义   工作流系统的定义接口使流程开发人员能够部署流程定义。注意，这里的“流程开发人员”可以是业务分析师和软件开发人员的组合。

      圈套（Pitfall）
      许多工作流管理系统的开发商想使你相信，通过使用他们的图形化流程开发工具，只要业务分析师就可以生成流程定义。这种幻想源于“编程很难”这样的事实。开发商的销售人员喜欢说“看，你不用写一行代码”。不用写代码是好事，可大部分开发商在这点上走的太远，忽略了在某些场合提供一种将代码集成到流程定义中的机制是很适合的。在将工作流系统作为EAI平台时，必须在流程中集成代码。开发流程定义需要业务分析师和软件开发人员的合作。一个好的图形流程设计工具应该能够支持这种合作。

    • 执行   执行接口使用户和系统可以操作流程实例。流程实例是流程定义的执行。流程定义的控制流通过状态机描述。执行接口的两个主要方法是启动一个流程实例和通知工作流系统一个状态结束了。
    • 应用   应用接口代表了由工作流系统发起的工作流系统和外部系统之间的交互。当一个用户或系统操作一个流程实例的运行时，会生成一些事件（如一个迁移的执行）。流程定义中可以指定一段响应一个事件的可执行代码逻辑，这段代码和组织内外部的其他系统打交道。
    • 监控   管理人员通过监控接口获得流程运行的确切数据。有时，运行日志也可用于审计。
        这些是WfMC参考模型（reference model of the WfMC）中定义的五个接口中的四个。

    流程定义的四个层次

        在下面这部分，我尝试回答这样的问题“什么是流程定义包括的内容？”。这是从各种规范和工具所使用模型的原则和概念中总结得来的，反映了大部分模型中通用的基本思想。流程定义的内容可以分为四个不同的层次：状态（state）、上下文（context）、程序逻辑（programming logic）和用户界面（UI）。

    状态层

        所有状态和控制流的表述，都属于业务流程的状态层。标准编程语言中的控制流来源于Von Neuman体系。控制流定义了必须被执行的指令的顺序，控制流由我们书写的命令、if语句、循环语句等确定。在业务流程中的控制流基本与此一致。但在业务流程中不是使用命令而是使用状态作为基本元素。

        在流程中，状态 (或者说等待状态)代表了一种对外部参与者（actor）的依赖。状态的意思就像“现在X系统或某某人必须作某些事，在此等待直到参与者通知这些任务已完成”。状态定义了一种对外部提供结果的依赖。状态典型的例子是批准步骤（step）。

        流程定义中的状态也指定了执行依赖于哪个参与者。在活动图中，泳道（swimlanes）的标注代表这些参与者的名字。工作流系统使用这些信息构建任务列表，这是一般工作流系统都有的功能。如前所述，参与者可以是人也可以是系统。对于需要人参与的状态，工作流系统必须在运行时计算出具体的个人。这样的计算使工作流系统必须依赖于组织结构信息。关于这方面的一篇非常有趣的文章是在further reading section提到的“工作流应用中的组织管理”（ 'Organizational Management in Workflow Applications'）。

        流程定义的控制流包含一组状态和它们之间的关系。状态之间的逻辑关系描述了哪些执行路径可以同时执行，那些不可以。同步执行路径用分叉（forks）和联合（joins）建模，异步执行路径用判断（decisions）和合并（ merges）建模。注意在大多数模型中，在每个状态之前都有一个隐式合并。

        UML活动图经常被用来做业务流程建模。作为一种直观和通用的表达，活动图在图形表述上有一个主要问题，就是没有区分状态和动作，它们都用活动来表示。缺少这种区分（导致状态概念的缺失）是学术派对UML活动图的主要批评。UML活动图的第二个问题是在UML2.0版中引入的。当多个迁移（transitions）到达一个活动时，以前的版本规定这是一个缺省合并（merge），在2.0版中规定这是一个需要同步的缺省联合（join）。在我看来，UML活动图的图形部分仍旧可以用来对业务流程状态层次建模，只要使用时对两条构建语义作如下的变化：

    1. 在用图形表述业务流程时，只建模状态层（状态和控制流），不要包括动作。这意味着图形中的矩形都是状态而不是活动
    2. 如果多个迁移到达一个状态，缺省定义为不需要同步的合并（merges）

        在流程运行过程中，工作流系统用一个令牌（token）作为指针跟踪流程的状态。这相当于Von Neuman体系中的程序计数器。当令牌到达一个状态时，它被分配给工作流系统等待的外部参与者。外部参与者可以是个人、组织或者计算机系统。我们定义流程运行的执行人或系统为“参与者”（actor）。只有在工作流系统将令牌分配给一个参与者时，才需要访问组织结构信息。工作流系统通过分配令牌构建任务列表。

    上下文层

        流程上下文变量（process context variable） ，或简称变量，是与流程实例相关的变量。流程开发人员可以使用流程变量存储跨越流程实例整个生命周期的数据。一些工作流管理系统有固定数目的数据类型，另一些你可以定义自己的数据类型。

        注意变量也可以用来存放引用（ references）。一个变量可以引用如数据库中的记录、网络上的文件。什么时候使用引用，取决于使用引用数据的其他应用。

        和流程变量相关的另一个令人感兴趣的方面是：工作流系统如何将数据转化为信息。工作流是用于组织内部跨越各种异构系统实现任务和数据协同的。对于业务流程中人工执行的任务，工作流系统负责从其他相关系统，如SAP、数据库、CRM系统、文档管理系统收集数据。在业务流程的每一个人工步骤，只有相关联的数据项被从异构系统中收集和计算。通过这种方式，从不同系统来的数据被转换并展现为信息。

    程序逻辑层

        如前所述，动作是在流程运行过程中，工作流系统响应指定的事件（event）执行的一段程序逻辑（programming logic）。程序逻辑可以是二进制或源代码形式的、用任何语言或脚本编写的软件。程序逻辑层是所有这些软件片断和关于在什么事件发生时调用它们的信息的组合。程序逻辑的例子包括发Email、通过消息代理发消息、从ERP系统中拿数据和更新数据库。

    用户界面层

        一个参与者通过向流程变量中填充数据的事件，来触发结束一个状态。比如，在请假的例子中，老板提供“同意”或“不同意”数据到流程中。某些工作流系统允许指定哪些数据可以填充到流程中，以及它们如何在流程变量中存储。通过这些信息，可以生成从用户收集信息的UI表单。基于流程定义生成用户提交表单的Web应用例子，可以访问the jBpm online demo。

    工作流全景

    可执行流程与工作流管理系统的比较（Executional processes versus a WFMS）

        当前在BPM领域中，关于可执行业务流程的规范有趋向于统一集中的趋势。 XLANG, WSFL 和BPML合并为基于交互（消息交换）的BPEL。BPEL在面向服务体系结构(SOA)的大背景下定义。它的前提条件之一是涉及的服务必须用WSDL声明。BPEL规定了一套XML语法，这套语法可以看作一种编程语言，用来描述包括对WSDL定义的服务调用的控制流。

        在可执行业务流程和基于状态的工作流管理系统所使用的方法中，我注意到了三点主要的区别：

    • 基于状态与面向消息：基于状态的工作流系统以状态（或者活动）概念为中心。工作流引擎维护状态并计算从一个状态到另一个状态的迁移。另一方面，像BPEL这样的可执行流程以对输入消息响应的定义为中心。一组这些响应外加其他信息（other bells and whistles）可以看作一个业务流程。这也解释了为什么BPEL可以看作是对基于状态的工作流系统的某些方面的补充。一个响应输入消息的BPEL onMessage事件处理器，可以在工作流状态之间的迁移中执行。
    • 流程实例ID与消息相关处理：可执行业务流程的复杂性之一来自消息相关性的处理。流程描述的一部分必须说明BPEL引擎如何从输入消息中确定具体流程的标识。这必须基于输入消息的一个数据项。而工作流系统在每个流程实例生成同时生成了实例ID，客户端在后续调用引擎API时使用这个ID。
    • 工作流引擎API与抽象服务端点（endpoint）：工作流系统提供一组集中的API，客户端通过调用API完成与所有流程实例的交互。在可执行业务流程中，每个流程表现为一个服务。这意味着对于每个流程定义都有一个不同的访问点。

    学术界

        学术界对工作流的研究可以回溯到上个世纪七十年代。在当前，研究领域趋向于认为petr 网是所有流程定义语言之母。关于petri网已有大量先进的分析技术，去年在 2003 conference on Business Process Management上我有幸会晤了Petri教授。对于大部分人能够访问和理解的有关Petyri网最好的研究之一是工作流模式(workflow patterns)。工作流模式比较了大量的工作流管理系统并以petri网的术语表述了通用流程建模概念。

    开放源代码项目

        最后我们看看真实世界中的工作流管理系统。选择一个工作流管理系统是一件困难的事情，但有选择总比没有选择好。:-) 本文阐述工作流基本概念的目的之一，就是使你能够作更好的选择。但我也意识到，对于现在的软件架构师来说，选择工作流系统是一件最具挑战性的工作。

        下面的列表来源于三个地方：my previous article, the list of Carlos E Perez, 和 list by Topicus.

    • jBpm - jBpm是本文作者编写的一个灵活可扩展的工作流管理系统。作为jBpm运行时server输入的业务流程使用简单强大的语言表达并打包在流程档案中。jBmp将工作流应用开发的便利性和杰出的企业应用集成（EAI）能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件，可以作为J2EE应用集群部署。
    • OpenEbXML - OpenebXML项目致力于提供一个ebXML框架，主要支持不久将由 UN/CEFACT和OASIS发布的ebXML规范2.0版。
    • Werkflow - Werkflow是一个灵活可扩展的基于流程和状态的工作流引擎。它的目标是满足可以想象的所有工作流程，从企业级的业务流程到小范围的用户交互流程。通过使用可插拔和分层结构，可以方便地容纳各种工作流语义。
    • OSWorkflow - OSWorkflow最独到之处是绝对的灵活。
    • wfmOpen - WfMOpen是WfMC和OMG中所谓工作流设施（workflow facility） (工作流引擎)的J2EE实现。工作流通过扩展的XPDL描述。
    • OFBiz - OFBiz工作流引擎基于WfMC和OMG的规范，使用XPDL作为流程定义语言。
    • ObjectWeb Bonita - Bonita是一个符合WfMC规范、灵活的协同工作流系统。 对于各种动作如流程概念建模、定义、实例化、流程控制和用户交互等提供了全面的集成图形工具。 100% 基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。基于活动预测模型的第三代工作流引擎。
    • Bigbross Bossa -速度非常快、轻量级的引擎，使用富有表达能力的Petri网定义工作流，不要求关系数据库，使用简单，能和Java应用集成。事实上，它是按嵌入式设计的。
    • XFlow - XFlow运行于EJB和servlet容器中。
    • Taverna - Taverna项目的目标是提供一种语言和软件工具，方便在eScience中使用工作流和分布计算技术。
    • Enhydra Shark - Shark完全基于WfMC和OMG标准，使用 XPDL作为工作流定义语言。流程和活动的存储使用Enhydra DODS。
    • PowerFolder - PowerFolder包括开发人员使用的studio，管理环境和一个运行时引擎。
    • Breeze - Breeze一个轻量级、跨平台、基于组件的工作流引擎原型。
    • Open Business Engine - Open Business Engine是一个开放源码的Java工作流引擎，支持WfMC规范，包括接口1（XPDL）、接口2/3（WAPI）和接口5。OBE为活动的运行提供了一个可控的集中环境。OBE主要基于J2EE实现。
    • OpenWFE - OpenWFE是一个开放源码的Java工作流引擎。 它包括可升级的三个组件：引擎、工作列表和Web界面。它的流程定义语言虽然使用XML格式，其灵感来源于 Scheme，一种Lisp方言。
    • Freefluo - Freefluo是一个使用Web Service的工作流协同工具，可以处理WSDL的Web Service调用。支持两种XML格式的工作流语言：IBM的WSFL和XScufl。Freefluo非常灵活，它的核心是不与任何工作流语言或执行架构关联的可重用协同框架。 Freefluo包括可执行使用WSFL一个子集描述的工作流的运行库。
    • ZBuilder - ZBuilder3是第二代工作流开发管理系统，也是一个开放源码产品。它为不同的工作流引擎和工作流定义了一组标准的JMX管理接口。
    • Twister - Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。
    • Con:cern - con:cern工作流引擎基于扩展的案例（case）处理方法，流程由一组具有前后条件的活动组成。

    商业软件提供商

    工具目录

    规范

        Michael zur Muehlen作了一个所有工作流相关规范的介绍性的幻灯片，很不错。

        我同意John Pyke 和 Wil van der Aalst 的观点：工作流标准还处于制定阶段。现在存在大量相互丛叠的规范。

        在我看来，导致规范如此之多而同时每个规范的应用又很有限的原因是，在工作流最基础概念上大家达成的共识很少。工作流是最容易让你感到心烦的话题，因为工作流本身的概念会和其他相关概念和技术混淆在一起。可以举一个具体的例子，比如说工作流完全是对Web Service的补充。你可以通过暴露接口以Web Service的方式访问一个工作流管理系统，但是不能假定总是必须通过Web Service接口访问工作流系统接口。一些规范造成了这样的假设。除了Web Service，其他容易混淆的概念和技术包括：Email、流程之间的通讯、Web应用和组织结构。

        在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC)，开始于 1993。 WfMC发布的参考模型很不错，它定义了工作流管理系统和其他相关部分之间的接口。WfMC的另一项成果是XPDL规范。 XPDL定义了描述工作流声明部分（declarative part）的XML结构。我个人认为，参考模型和XPDL是目前最好的规范。

    • JSR 207: Java的流程定义 -是由Java Community Process (JCP) 发起，如何在J2EE应用服务器中实现业务流程自动化的标准。其基本模型是定义一个特殊类型的ejb session bean，作为一个业务流程的接口。JSR207标准化一组XML元标记（meta tags）作为JSR175元数据的一部分。JSR207 将session bean和元数据作为ejb容器的输入，然后生成绑定方法的代码，这些方法在元数据中描述。此规范还处于初级阶段，没有发布任何内容。专家小组成立于 March 2003.
    • WfMC's XPDL - WfMC是由约300家成员参加的组织，基于参考模型定义了一系列的标准。参考模型用用例（use case）的形式描述了工作流系统和其他相关部分之间的关系。XPDL是WfMC制定的描述业务流程控制流（control flow ）的XML格式规范。
    • ebXML's BPSS - ebXML是协同流程的相关标准集，主要关注不同公司流程之间的通讯。可以看作EDI的继承者。 ebXML是由OASIS和UN/CEFACT联合发起。 BPSS 是ebXML的规范，其中的概念和本文阐述的很接近。
    • BPMI's BPML & WSCI - (Intalio, Sun, SAP, ...)BPMI 也定义了一个规范 (BPMN) ，描述如何将“可执行”业务流程可视化的表现。
    • BPEL - (Microsoft, BEA, IBM, SAP & Siebel) BPEL由一系列基于消息交换的规范（ XLANG, WSFL, BPML）产生。还有一个将此规范引入到Java的提案: BPELJ。 此规范描述如何处理输入的消息，而不是对流程状态进行建模。就像本文提到的，它不是一个关于业务流程规格化定义的规范。简单的说，可以将它看作XML形式的编程语言，提供将WSDL-Services组合成控制流的能力。顾名思义，此规范重点在（也不只限于）Web Service。
    • OMG's Workflow management facility - 基于WfMC规范，定义如何向CORBA转换。
    • UML - UML定义了建模和设计软件系统的9类图。每类图包括可视化的表示和语义。其中活动图的目的就是要可视化的表现业务流程。 注意到在一个流程定义包含四个层次的内容，我想指出的是：一个流程定义包含的内容远远多于它的可视化部分。UML只涉及了可视化部分。
    • RosettaNet - RosettaNet主要定义了一组 Partner Interface Processes (PIP). 一个 PIP 描述了一个有两个交易参与者、包括消息格式的流程。
    • UBL - The Universal Business Language (UBL)定义了用于不同组织间通讯的XML文档标准库。可以看作是对ebXML的补充，因为ebXML只定义了建立组织间流程的基础。此规范的竞争对手是 RosettaNet标准中的一个子集。

    结论

        我在本文中指出工作流市场还属于年轻而又混乱（young and wild）的阶段，但已经有可靠的工具存在了:

    1. 到目前，像J2EE和.NET这样成熟的集成平台才可用。在这样一个平台上运行工作流管理系统才能真正发挥工作流系统的附加价值。这也是为什么只有在今天，工作流系统才被重新发现。
    2. 在 'The case for workflow'一节，我们介绍了引入工作流管理系统，是如何同时在技术和业务上带来投资回报的。
    3. 工作流在技术发展曲线的位置表明，BPM和工作流中使用的概念还需要明确。
    4. “开放源代码项目”和“商业软件提供商”列表中的工具，可以让你获得工作流和业务流程管理的益处。

        从以上所有这些中能得到的结论是：

    1. 规范还没有成熟，没有标准被大范围采用
    2. 对于现在想应用BPM的公司来讲，比较工作流系统是一个极其困难的挑战
    3. 尽管标准化工作慢了一拍，可好的工作流管理系统还是有的。这对于已经在挑选工作流系统的组织来说是一个好消息。

        我希望本文能够激发你对工作流的兴趣并且能够为你进行有效的对比提供正确的背景知识。

    Further reading

    查看(19) 评论(0)

  • 工作流概览

    2008-8-06

    什么是工作流
    　　工作流（Work Flow）就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者任务。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。我们可以将整个业务过程看作是一条河，其中流过的就是工作流。
    　　工作流属于计算机支持的协同工作（Computer Supported Cooperative Work，CSCW）的一部分。后者是普遍地研究一个群体如何在计算机的帮助下实现协同工作的。
    　　许多公司采用纸张表单，手工传递的方式，一级一级审批签字，工作效率非常低下，对于统计报表功能则不能实现。而采用工作流软件，使用者只需在电脑上填写有关表单，会按照定义好的流程自动往下跑，下一级审批者将会收到相关资料，并可以根据需要修改、跟踪、管理、查询、统计、打印等，大大提高了效率，实现了知识管理，提升了公司的核心竞争力。

    工作流的适用行业

    　　消费品行业，制造业，电信服务业，银证险等金融服务业，物流服务业，物业服务业，物业管理，大中型进出口贸易公司，政府事业机构，研究院所及教育服务业等，特别是大的跨国企业和集团公司。


    工作流的具体应用
    　　1.关键业务流程：订单、报价处理、采购处理、合同审核、客户电话处理、供应链管理等
    　　2.行政管理类:出差申请、加班申请、请假申请、用车申请、各种办公用品申请、购买申请、日报周报等凡是原来手工流转处理的行政表单。
    　　3.人事管理类：员工培训安排、绩效考评、职位变动处理、员工档案信息管理等。
    　　4.财务相关类：付款请求、应收款处理、日常报销处理、出差报销、预算和计划申请等。
    　　5.客户服务类：客户信息管理、客户投诉、请求处理、售后服务管理等管理等。
    　　6.特殊服务类：ISO系列对应流程、质量管理对应流程、产品数据信息管理、贸易公司报关处理、物流公司货物跟踪处理等各种通过表单逐步手工流转完成的任务均可应用工作流软件自动规范地实施。


    工作流与重规划
     

    　　从逻辑上，对工作流的关注和研究可以看作是对业务过程重规划（BPR）的一种深化。BPR的观点，要求我们将眼光投向实际业务进行的过程，但这个过程应当是什么样的，怎样分析、构造？工作流就是一个具体的、操作性的答案，它可以令我们从神秘的、难以预测和控制的“头脑风暴式”的“艺术的”业务过程创造，变成解析的、技术的、可控制和预测的工程化过程，如此，才真正体现出re-engineering中engineering的意义。
    　　工作流与BPR的概念，已经被几乎所有的研究者联系在一起研究和应用。在这个领域有一个非常活跃的组织，即国际工作流与重规划协会（Workflow And Reengineering International Association, WARIA）。


    工作流与企业工程
     

    　　无论从理论、方法上，还是对象、内容上，我们都有理由将“工作流”看作是企业工程的一部分。实际上，已有的关于工作流体系的描述，本身就是一个通用的业务模型框架。仅仅囿于工作流是不够的，必须对整个体系的目标及所有相关要素综合考虑——这正是企业工程。

    工作流与IT应用体系
     

    　　与以往已经被采用的企业IT应用体系，例如MRPII或ERP相比，WFMS是一个相当重要的里程碑。从用户的角度，WFMS带来（或将要带来）的变化是极其强烈的，甚至可以形容为一种用户“梦想”的实现。
    　　在一些老的“模块化”的产品中，系统的设计是通常是基于任务分割的，作业项目之间是分裂的。面向对象的技术，并不能直接解决这个的问题，相反，往往使系统变得更加混乱和琐碎。从操作上，典型地，我们必须不断地在层次结构的功能表（比如下拉菜单）或对象之间“进进退退”，或者在“神出鬼没”的对象以及相关菜单中捉迷藏。
    　　工作流管理系统是一个真正的“人-机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务分派和任务的完成状态，可以被最大程度地电脑化和受到控制。
    　　现在的典型工作流产品是客户-服务软件。而日益增长的重要途径是通过万维网界面，它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化工具，依照业务过程实例的情况定义相应工作的安排。

    查看(14) 评论(0)

  • 界面测试的方方面面

    2008-8-06

    界面是软件与用户交互的最直接的层，界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作，起到向导的作用。同时界面如同人的面孔，具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉，相反由于界面设计的失败，让用户有挫败感，再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。目前界面的设计引起软件设计人员的重视的程度还远远不够，直到最近网页制作的兴起，才受到专家的青睐。而且设计良好的界面由于需要具有艺术美的天赋而遭拒绝。
    　　目前流行的界面风格有三种方式：多窗体、单窗体以及资源管理器风格，无论那种风格，以下规则是应该被重视的。
    　　
    　　1：易用性：
    　　按钮名称应该易懂，用词准确，屏弃没楞两可的字眼，要与同一界面上的其他按钮易于区分，能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。
    　　
    　　易用性细则：
    　　1):完成相同或相近功能的按钮用Frame框起来，常用按钮要支持快捷方式。
    　　2):完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
    　　3):按功能将界面划分局域块，用Frame框括起来,并要有功能说明或标题。
    　　4):界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
    　　5):界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
    　　6):同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
    　　7):分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
    　　8):默认按钮要支持Enter及选操作，即按Enter后自动执行默认按钮对应操作。
    　　9):可写控件检测到非法输入后应给出说明并能自动获得焦点。
    　　10):Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
    　　11):复选框和选项框按选择几率的高底而先后排列。
    　　12):复选框和选项框要有默认选项，并支持Tab选择。
    　　13):选项数相同时多用选项框而不用下拉列表框。
    　　14):界面空间较小时使用下拉框而不用选项框。
    　　15):选项数叫少时使用选项框，相反使用下拉列表框。
    　　16):专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
    　　2： 规范性：
    　　通常界面设计都按Windows界面的规范来设计，即包含“菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式，可以说：界面遵循规范化的程度越高，则易用性相应的就越好。小型软件一般不提供工具厢。
    　　
    　　规范性细则：
    　　1):常用菜单要有命令快捷方式。
    　　2):完成相同或相近功能的菜单用横线隔开放在同一位置。
    　　3):菜单前的图标能直观的代表要完成的操作。
    　　4):菜单深度一般要求最多控制在三层以内。
    　　5):工具栏要求可以根据用户的要求自己选择定制。
    　　6):相同或相近功能的工具栏放在一起。
    　　7):工具栏中的每一个按钮要有及时提示信息。
    　　8):一条工具栏的长度最长不能超出屏幕宽度。
    　　9): 工具栏的图标能直观的代表要完成的操作。
    　　10):系统常用的工具栏设置默认放置位置。
    　　11):工具栏太多时可以考虑使用工具厢。
    　　12):工具厢要具有可增减性，由用户自己根据需求定制。
    　　13):工具厢的默认总宽度不要超过屏幕宽度的1/5。
    　　14): 状态条要能显示用户切实需要的信息，常用的有：
    　　目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等，如果某一操作需要的时间较长，还应该显示进度条和进程提示。
    　　15)：滚动条的长度要根据显示信息的长度或宽度能及时变换，以利于用户了解显示信息的位置和百分比。
    　　16)：状态条的高度以放置五好字为宜，滚动条的宽度比状态条的略窄。
    　　17)：菜单和工具条要有清楚的界限;菜单要求凸出显示，这样在移走工具条时仍有立体感。
    　　18)：菜单和状态条中通常使用5号字体。工具条一般比菜单要宽，但不要宽的太多，否则看起来很不协调。
    　　19):右键快捷菜单采用与菜单相同的准则。
    　　
    　　
    　　3：帮助设施：
    　　系统应该提供详尽而可靠的帮助文档，在用户使用产生迷惑时可以自己寻求解决方法。
    　　
    　　帮助设施细则：
    　　1)：帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明，让人困惑)。
    　　2)：打包新系统时，对作了修改的地方在帮助文档中要做相应的修改。
    　　3)：操作时要提供及时调用系统帮助的功能。常用F1。
    　　4)：在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
    　　5)：最好提供目前流行的联机帮助格式或HTML帮助格式。
    　　6)：用户可以用关键词在帮助索引中搜索所要的帮助，当然也应该提供帮助主题词。
    　　7)：如果没有提供书面的帮助文档的话，最好有打印帮助的功能。
    　　8 )：在帮助中应该提供我们的技术支持方式，一旦用户难以自己解决可以方便的寻求新的帮助方式。
    　　
    　　4：合理性：
    　　屏幕对角线相交的位置是用户直视的地方，正上方四分之一处为易吸引用户注意力的位置，在放置窗体时要注意利用这两个位置。
    　　
    　　合理性细则：
    　　1)：父窗体或主窗体的中心位置应该在对角线焦点附近。
    　　2)：子窗体位置应该在主窗体的左上角或正中。
    　　3)：多个子窗体弹出时应该依次向右下方偏移，以显示窗体出标题为宜。
    　　4)：重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
    　　5)：错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
    　　6)：与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示，没法使用该按钮)。
    　　7)：对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
    　　8)：非法的输入或操作应有足够的提示说明。
    　　9): 对运行过程中出现问题而引起错误的地方要有提示，让用户明白错误出处，避免形成无限期的等待。
    　　10):提示、警告、或错误说明应该清楚、明了、恰当。
    　　5：美观与协调性：
    　　界面应该大小适合美学观点，感觉协调舒适，能在有效的范围内吸引用户的注意力。
    　　
    　　美观与协调性细则：
    　　1): 长宽接近黄金点比例，切忌长宽比例失调、或宽度超过长度。
    　　2): 布局要合理,不宜过于密集，也不能过于空旷，合理的利用空间。
    　　3): 按钮大小基本相近，忌用太长的名称，免得占用过多的界面位置。
    　　4): 按钮的大小要与界面的大小和空间要协调。
    　　5): 避免空旷的界面上放置很大的按钮。
    　　6)：放置完控件后界面不应有很大的空缺位置。
    　　7): 字体的大小要与界面的大小比例协调, 通常使用的字体中宋体9-12较为美观，很少使用超过12号的字体。
    　　8): 前景与背景色搭配合理协调，反差不宜太大，最好少用深色，如大红、大绿等。常用色考虑使用Windows界面色调。
    　　9): 如果使用其他颜色，主色要柔和，具有亲和力与磁力，坚决杜绝刺目的颜色。
    　　10): 大型系统常用的主色有"#E1E1E1"、"#EFEFEF"、"#C0C0C0"等。
    　　11): 界面风格要保持一致，字的大小、颜色、字体要相同，除非是需要艺术处理或有特殊要求的地方。
    　　12): 如果窗体支持最小化和最大化或放大时，窗体上的控件也要随着窗体而缩放；切忌只放大窗体而忽略控件的缩放。
    　　13)：对于含有按钮的界面一般不应该支持缩放，即右上角只有关闭功能。
    　　14): 通常父窗体支持缩放时，子窗体没有必要缩放。
    　　15)：如果能给用户提供自定义界面风格则更好，由用户自己选择颜色、字体等。
    　　
    　　6：菜单位置：
    　　菜单是界面上最重要的元素，菜单位置按照按功能来组织。
    　　
    　　菜单设测试细则：
    　　1)：菜单通常采用“常用--主要--次要--工具--帮助”的位置排列，符合流行的Windows风格。
    　　2):常用的有“文件”、“编辑”，“查看”等，几乎每个系统都有这些选项，当然要根据不同的系统有所取舍。
    　　3):下拉菜单要根据菜单选项的含义进行分组，并切按照一定的规则进行排列，用横线隔开。
    　　4): 一组菜单的使用有先后要求或有向导作用时，应该按先后次序排列。
    　　5): 没有顺序要求的菜单项按使用频率和重要性排列，常用的放在开头， 不常用的靠后放置；重要的放在开头，次要的放在后边。
    　　6): 如果菜单选项较多，应该采用加长菜单的长度而减少深度的原则排列。
    　　7): 菜单深度一般要求最多控制在三层以内。
    　　8): 对常用的菜单要有快捷命令方式，组合原则见8。
    　　9):对与进行的操作无关的菜单要用屏蔽的方式加以处理，如果采用动态加载方式——即只有需要的菜单才显示——最好。
    　　10)：菜单前的图标不宜太大，与字高保持一直最好。
    　　11):主菜单的宽度要接近，字数不应多于四个，每个菜单的字数能相同最好。
    　　12)：主菜单数目不应太多，最好为单排布置。
    　　。7:独特性：
    　　如果一味的遵循业界的界面标准，则会丧失自己的个性.在框架符合以上规范的情况下，设计具有自己独特风格的界面尤为重要。尤其在商业软件流通中有着很好的迁移默化的广告效用。
    　　
    　　1):安装界面上应有单位介绍或产品介绍，并有自己的图标。
    　　2):主界面，最好是大多数界面上要有公司图标。
    　　3):登录界面上要有本产品的标志，同时包含公司图标。
    　　4):帮助菜单的“关于”中应有版权和产品信息。
    　　5):公司的系列产品要保持一直的界面风格，如背景色、字体、菜单排列方式、图标、安装过程、按钮用语等应该大体一致。
    　　
    　　8：快捷方式的组合
    　　在菜单及按钮中使用快捷键可以让喜欢使用键盘的用户操作得更快一些 在西文Windows及其应用软件中快捷键的使用大多是一致的。
    　　菜单中：
    　　1):面向事务的组合有:
    　　Ctrl-D 删除 ；Ctrl-F 寻找 ；Ctrl –H替换；Ctrl-I 插入 ；Ctrl-N 新记录 ；Ctrl-S 保存 Ctrl-O 打开。
    　　2)：列表:
    　　Ctrl-R ，Ctrl-G定位；Ctrl-Tab下一分页窗口或反序浏览同一页面控件；。
    　　3):编辑:
    　　Ctrl-A全选；Ctrl-C 拷贝；Ctrl-V 粘贴；Ctrl-X 剪切；Ctrl-Z撤消操作；Ctrl-Y恢复操作。
    　　4)文件操作:
    　　Ctrl-P 打印；Ctrl-W 关闭。
    　　5):系统菜单
    　　Alt-A文件；Alt-E编辑；Alt-T工具；Alt－W窗口；Alt－H帮助。
    　　6):MS Windows保留键:
    　　Ctrl-Esc 任务列表 ；Ctrl-F4 关闭窗口； Alt-F4 结束应用；Alt-Tab 下一应用 ；Enter 缺省按钮/确认操作 ；Esc 取消按钮/取消操作 ；Shift-F1 上下文相关帮助 。
    　　按钮中：
    　　可以根据系统需要而调节，以下只是常用的组合。
    　　Alt-Y确定(是)；Alt-C取消；Alt-N 否；Alt-D删除；Alt-Q退出；Alt-A添加；Alt-E编辑；Alt-B浏览；Alt-R读；Alt-W写。
    　　这些快捷键也可以作为开发中文应用软件的标准,但亦可使用汉语拼音的开头字母。
    　　9:安全性考虑：
    　　在界面上通过下列方式来控制出错几率，会大大减少系统因用户人为的错误引起的破坏。开发者应当尽量周全地考虑到各种可能发生的问题,使出错的可能降至最小。如应用出现保护性错误而退出系统,这种错误最容易使用户对软件失去信心。因为这意味着用户要中断思路,并费时费力地重新登录,而且已进行的操作也会因没有存盘而全部丢失。
    　　
    　　
    　　安全性细则：
    　　1)：最重要的是排除可能会使应用非正常中止的错误。
    　　2)：应当注意尽可能避免用户无意录入无效的数据。
    　　3)：采用相关控件限制用户输入值的种类。
    　　4)：当用户作出选择的可能性只有两个时,可以采用单选框。
    　　5)：当选择的可能再多一些时,可以采用复选框,每一种选择都是有效的,用户不可能输入任何一种无效的选择。
    　　6)：当选项特别多时，可以采用列表框，下拉式列表框。
    　　7)：在一个应用系统中,开发者应当避免用户作出未经授权或没有意义的操作。
    　　8)：对可能引起致命错误或系统出错的输入字符或动作要加限制或屏蔽。
    　　9):对可能发生严重后果的操作要有补救措施。通过补救措施用户可以回到原来的正确状态。
    　　10):对一些特殊符号的输入、与系统使用的符号相冲突的字符等进行判断并阻止用户输入该字符。
    　　11)：对错误操作最好支持可逆性处理，如取消系列操作。
    　　12):在输入有效性字符之前应该阻止用户进行只有输入之后才可进行的操作。
    　　13):对可能造成等待时间较长的操作应该提供取消功能。
    　　14)：特殊字符常有；;’”><,｀‘：“［”｛、\|｝］+=)-(_*&&^%$#@!~,.。?/还有空格。
    　　15)：与系统采用的保留字符冲突的要加以限制。
    　　16)：在读入用户所输入的信息时，根据需要选择是否去掉前后空格。
    　　17)：有些读入数据库的字段不支持中间有空格，但用户切实需要输入中间空格，这时要在程序中加以处理。
    　　
    　　10:多窗口的应用与系统资源：
    　　设计良好的软件不仅要有完备的功能，而且要尽可能的占用最底限度的资源。
    　　1)： 在多窗口系统中，有些界面要求必须保持在最顶层，避免用户在打开多个窗口时，不停的切换甚至最小化其他窗口来显示该窗口。
    　　
    　　2)：在主界面载入完毕后自动卸出内存，让出所占用的WINDOWS系统资源。
    　　3)：关闭所有窗体，系统退出后要释放所占的所有系统资源 ，除非是需要后台运行的系统。
    　　4)：尽量防止对系统的独占使用。
    　　

    查看(25) 评论(0)

  • 如何根据需要搭建软件测试环境

    2008-8-04

    去搭建测试环境是软件测试实施的一个重要阶段，测试环境适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境

    一 确定测试环境的组成：

    1．所需要的计算机的数量，以及对每台计算机的硬件配置要求，包括CPU的速度、内存和硬盘的容量、网卡所支持的速度、打印机的型号等；

    2. 部署被测应用的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

    3. 用来保存各种测试工作中生成的文档和数据的服务器所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

    4. 用来执行测试工作的计算机所必需的操作系统、数据库管理系统、中间件、WEB服务器以及其他必需组件的名称、版本，以及所要用到的相关补丁的版本；

    5. 是否需要专门的计算机用于被测应用的服务器环境和测试管理服务器的环境的备份；

    6. 测试中所需要使用的网络环境。例如，如果测试结果同接入Internet的线路的稳定性有关，那么应该考虑为测试环境租用单独的线路；如果测试结果与局域网内的网络速度有关，那么应该保证计算机的网卡、网线以及用到的集线器、交换机都不会成为瓶颈；

    二、管理测试环境

    1. 设置专门的测试环境管理员角色

    每个测试项目或测试小组都应当配备一名专门的测试环境管理员，其职责包括：测试环境的搭建。包括操作系统、数据库、中间件、WEB服务器等必须软件的安装，配置，并做好各项安装、配置手册的编写；记录组成测试环境的各台机器的硬件配置、IP地址、端口配置、机器的具体用途，以及当前网络环境的情况；测试环境各项变更的执行及记录；测试环境的备份及恢复；操作系统、数据库、中间件、WEB服务器以及被测应用中所需的各用户名、密码以及权限的管理；

    2. 记录好测试环境管理所需的各种文档：

    测试环境的各台机器的硬件环境文档，测试环境的备份和恢复方法手册，并记录每次备份的时间、备份人、备份原因以及所形成的备份文件的文件名和获取方式；用户权限管理文档，记录访问操作系统、数据库、中间件、WEB服务器以及被测应用时所需的各种用户名、密码以及各用户的权限，并对每次变更进行记录

    3. 测试环境访问权限的管理

    为每个访问测试环境的测试人员和开发人员设置单独的用户名和密码。访问操作系统、数据库、WEB服务器以及被测应用等所需的各种用户名、密码、权限，由测试环境管理员统一管理；测试环境管理员拥有全部的权限，开发人员只有对被测应用的访问权限和查看系统日志（只读），测试组成员不授予删除权限，用户及权限的各项维护、变更，需要记录到相应的“用户权限管理文档”中

    4. 测试环境的备份和恢复

    测试环境必须是可恢复的，否则将导致原有的测试用例无法执行，或者发现的缺陷无法重现，最终使测试人员已经完成的工作失去价值。因此，应当在测试环境（特别是软件环境）发生重大变动时进行完整的备份，例如使用Ghost对硬盘或某个分区进行镜像备份。

    查看(12) 评论(0)

  • apache server和apache 基金会

    2008-8-03

    Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上。

    Apache源于NCSAhttpd服务器，经过多次修改，成为世界上最流行的Web服务器软件之一。Apache取自“a patchy server”的读音，意思是充满补丁的服务器，因为它是自由软件，所以不断有人来为它开发新的功能、新的特性、修改原来的缺陷。Apache的特点是简单、速度快、性能稳定，并可做代理服务器来使用。

    本来它只用于小型或试验Internet网络，后来逐步扩充到各种Unix系统中，尤其对Linux的支持相当完美。Apache有多种产品，可以支持SSL技术，支持多个虚拟主机。Apache是以进程为基础的结构，进程要比线程消耗更多的系统开支，不太适合于多处理器环境，因此，在一个Apache Web站点扩容时，通常是增加服务器或扩充群集节点而不是增加处理器。到目前为止Apache仍然是世界上用的最多的Web服务器，市场占有率达60%左右。世界上很多著名的网站如Amazon.com、Yahoo!、W3 Consortium、Financial Times等都是Apache的产物，它的成功之处主要在于它的源代码开放、有一支开放的开发队伍、支持跨平台的应用（可以运行在几乎所有的Unix、Windows、Linux系统平台上）以及它的可移植性等方面。

    Apache的诞生极富有戏剧性。当NCSA WWW服务器项目停顿后，那些使用NCSA WWW服务器的人们开始交换他们用于该服务器的补丁程序，他们也很快认识到成立管理这些补丁程序的论坛是必要的。就这样，诞生了Apache Group，后来这个团体在NCSA的基础上创建了Apache。

    Apache web服务器软件拥有以下特性：

    支持最新的HTTP/1.1通信协议

    拥有简单而强有力的基于文件的配置过程

    支持通用网关接口

    支持基于IP和基于域名的虚拟主机

    支持多种方式的HTTP认证

    集成Perl处理模块

    集成代理服务器模块

    支持实时监视服务器状态和定制服务器日志

    支持服务器端包含指令(SSI)

    支持安全Socket层(SSL)

    提供用户会话过程的跟踪

    支持FastCGI

    通过第三方模块可以支持Java Servlets

    如果你准备选择Web服务器，毫无疑问Apache是你的最佳选择。

      Apache软件基金会（也就是Apache Software Foundation，简称为ASF），是专门为运作一个开源软件项目的 Apache 的团体提供支持的非盈利性组织，这个开源软件项目就是 Apache 项目。这个组织把自己作为有着相同目标的开发者与用户的团体，而不是简单的共享在一个服务器上的一组项目的组织团体。在它所支持的 Apache 项目与子项目中，所发行的软件产品都遵循 Apache许可证（Apache License）。

           Apache软件基金会（ASF）正式创建于1999年，它的创建者是一个自称为“Apache 组织”的群体。这个“Apache 组织”在1999年以前就已经存在很长时间了，这个组织的开发者爱好们聚集在一起，在美国伊利诺斯大学超级计算机应用程序国家中心（National Center for Supercomputing Applications，简称为NCSA）开发的 NCSA HTTPd 服务器的基础上开发与维护了一个叫 Apache 的 HTTP服务器。
           最初 NCSA HTTPd 服务器是由 Rob McCool 开发出来的，但是它的最初开发者们逐渐对这个软件失去了兴趣，并转移到了其他地方，造成了没有人来对这个服务器软件提供更多的技术支持。因为这个服务器的功能又如此强大，而代码可以自由下载修改与发布，当时这个服务器软件的一些爱好者与用户开始自发起来，互相交流并分发自己修正後的软件版本，并不断改善其功能。为了更好进行沟通，Brian Behlendorf 自己建立了一个邮件列表，把它作为这个群体（或者社区）交流技术、维护软件的一个媒介，把代码重写与维护的工作有效组织起来。这些开发者们逐渐地把他们这个群体称为“Apache 组织”，把这个经过不断修正并改善的服务器软件命名为 Apache 服务器（Apache Server）。
           这个命名是根据北美当地的一支印第安部落而来，这支部落以高超的军事素养和超人的忍耐力着称，19世纪後半期对侵占他们领土的入侵者进行了反抗。为了对这支印第安部落表示敬仰之意，取该部落名称（Apache）作为服务器名。但一提到这个命名，这里还有流传着一段有意思的故事。因为这个服务器是在 NCSA HTTPd 服务器的基础之上，通过众人努力，不断地修正、打补丁（Patchy）的产物，被戏称为“A Patchy Server”（一个补丁服务器）。在这里，因为“Patchy”与“Apache”是谐音，故最後正式命名为“Apache Server”。
    後来由于商业需求的不断扩大，以 Apache HTTP 服务器为中心，启动了更多的与 Apache 项目并行的项目，比如mod_ perl、PHP、Java Apache等等。随着时间的推移、形势的变化，Apache软件基金会的项目列表也不断更新变化中－－不断的有新项目启动，项目的中止以及项目的拆分与合并。比如一开始，Jakarta 就是为了发展 JAVA 容器而启动的 Java Apache 项目，後来由于升阳公司（SUN）的建议，项目名称变为 Jakarta 。但当时该项目的管理者也没有想到 Jakarta 项目因为 JAVA 的火爆而发展到如今一个囊括了众多基于 JAVA 语言开源软件子项目的项目。以至後来，不得不把个别项目从 Jakarta 中独立出来，成为 Apache软件基金会的顶级项目，Struts 项目就是其中之一。
           最近，为了避免 SCO 与 UNIX 开源社区之间的发生纠纷降临在 Apache 软件基金会（ASF）身上。Apache软件基金会（ASF）里面开始采取一些措施，让众多的项目进行更多协调的、结构化管理，并保护自己的合法利益，避免一些潜在的合乎法律的侵犯（potential legal attacks）。

          主要成果：HTTP Server，Ant，DB，iBATIS，Jakarta，Logging，Maven，Struts，Tomcat，Tapestry等等。

    查看(4) 评论(0)

  • 软件测试的22种类型

    2008-7-24

      黑盒测试：不基于内部设计和代码的任何知识，而是基于需求和功能性。

            白盒测试：基于一个应用代码的内部逻辑知识，测试是基于覆盖全部代码、分支、路径、条件。

            单元测试：最微小规模的测试；以测试某个功能或代码块。典型地由程序员而非测试员来做，因为它需要知道内部程序设计和编码的细节知识。这个工作不容易作好，除非应用系统有一个设计很好的体系结构; 还可能需要开发测试驱动器模块或测试套具。

            集成测试：一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。

            功能测试：用于测试应用系统的功能需求的黑盒测试方法。这类测试应由测试员做，这并不意味着程序员在发布前不必检查他们的代码能否工作(自然他能用于测试的各个阶段)。

            累积综合测试：当一个新功能增加后，对应用系统所做的连续测试。它要求应用系统的不同形态的功能能够足够独立以可以在全部系统完成前能分别工作，或当需要时那些测试驱动器已被开发出来; 这种测试可由程序员或测试员来做。

            系统测试：基于系统整体需求说明书的黑盒类测试；应覆盖系统所有联合的部件。

            端到端测试：类似于系统测试；测试级的“宏大”的端点；涉及整个应用系统环境在一个现实世界使用时的模拟情形的所有测试。例如与数据库对话，用网络通讯，或与外部硬件、应用系统或适当的系统对话。

            比较测试：与竞争伙伴的产品的比较测试，如软件的弱点、优点或实力。

            Alpha 测试：在系统开发接近完成时对应用系统的测试；测试后，仍然会有少量的设计变更。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

            Beta 测试：当开发和测试根本完成时所做的测试，而最终的错误和问题需要在最终发行前找到。这种测试一般由最终用户或其他人员员完成，不能由程序员或测试员完成。

            健全测试：典型地是指一个初始化的测试工作，以决定一个新的软件版本测试是否足以执行下一步大的测试努力。例如，如果一个新版软件每5分钟与系统冲突，使系统陷于泥潭，说明该软件不够“健全”，目前不具备进一步测试的条件。

            衰竭测试：软件或环境的修复或更正后的“再测试”。可能很难确定需要多少遍再次测试。尤其在接近开发周期结束时。自动测试工具对这类测试尤其有用。

            接受测试：基于客户或最终用户的规格书的最终测试，或基于用户一段时间的使用后，看软件是否满足客户要求。

            负载测试：测试一个应用在重负荷下的表现，例如测试一个 Web 站点在大量的负荷下，何时系统的响应会退化或失败。

            强迫测试：在交替进行负荷和性能测试时常用的术语。也用于描述象在异乎寻常的重载下的系统功能测试之类的测试，如某个动作或输入大量的重复，大量数据的输入，对一个数据库系统大量的复杂查询等。

            性能测试：在交替进行负荷和强迫测试时常用的术语。理想的“性能测试”(和其他类型的测试)应在需求文档或质量保证、测试计划中定义。

            安装/卸载测试：对软件的全部、部分或升级安装/卸载处理过程的测试。

            恢复测试：测试一个系统从如下灾难中能否很好地恢复，如遇到系统崩溃、硬件损坏或其他灾难性问题。

            安全测试：测试系统在防止非授权的内部或外部用户的访问或故意破坏等情况时怎么样。这可能需要复杂的测试技术。

            可用性测试：对“用户友好性”的测试。显然这是主观的，且将取决于目标最终用户或客户。用户面谈、调查、用户对话的录象和其他一些技术都可使用。程序员和测试员通常都不宜作可用性测试员。

            兼容测试：测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。

    查看(22) 评论(0)

  • 如何根据LR的计数器显示结果判断系统瓶颈

    2008-7-23

    判断应用程序是否存在处理器瓶颈的方法：如果Processor Queue Length　显示的队列长度保持不变（>＝２）个并且处理器的利用率%Processor Time 超过90%，那么很有可能存在处理器瓶颈。

    如果发现Processor Queue Length 显示的队列长度超过2，而处理器的利用率却一直很低，那么或足额更应该去解决处理器阻塞问题，这里处理器一般不是瓶颈。

    如果系统由于应用程序代码效率低下或者系统节后设计有缺陷而导致大量的上下文切换（ContextSwitches/sec 显示的上下文切换次数比较大），那么就会占用大量的系统资源。如果系统的吞吐量降低并且CPUde 使用率很高，并且比现象发生时切换水平在1500以上，那么意味着上下文切换次数过高。

    同时还可以比较ContextSwitches/sec 和%Privileged Time来判断上下文切换是否过量。如果后者的值超过40%，且上下文切换的速率也很高，那么应该检查为什么会产生这样高的上下文切换。

    查看(23) 评论(0)

  • Loadrunner中web_reg_save_param的使用详解（转载）

    2008-7-15

    【摘要】利用实际案例说明如何使用Mercury LoadRunner提取包含在 HTML 页内的动态信息并创建参数。

    【关键词】性能测试，压力测试，Mercury LoadRunner

    • 应用范围

    在使用Loadrunner进行性能测试时，经常遇到一种情况，需要通过web页面修改某事务的状态。于是需要首先读出当前的事务的状态，再进行修改，此时便可以使用到web_reg_save_param了。可以通过它先将事务的状态读出写入一个自定义的变量中，根据变量的值来决定下一步的动作。

    • 简要说明

    语法：

    int web_reg_save_param(const char *ParamName, <list of Attributes>, LAST);

    参数说明:

    • ParamName: 存放得到的动态内容的参数名称
    • list of Attributes: 其它属性，包括：Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, SaveLen。属性值不分大小写
      • Notfound: 当在返回信息中找不到要找的内容时应该怎么处理
      • Notfound=error: 当在返回信息中找不到要找的内容时，发出一个错误讯息。这是缺省值。
      • Notfound=warning: 当在返回信息中找不到要找的内容时，只发出警告，脚本也会继续执行下去不会中断。
      • LB( Left Boundary ) : 返回信息的左边界字串。该属性必须有，并且区分大小写。
      • RB( Right Boundary ): 返回信息的右边界字串。该属性必须有，并且区分大小写。
      • RelFrameID: 相对于URL而言，欲查找的网页的Frame。此属性质可以是All或是数字，该属性可有可无。
      • Search : 返回信息的查找范围。可以是Headers，Body，Noresource，All(缺省)。该属性质可有可无。
      • ORD : 说明第几次出现的左边界子串的匹配项才是需要的内容。该属性可有可无，缺省值是1。如为All，则将所有找到的内容储存起来。
      • SaveOffset : 当找到匹配项后，从第几个字元开始存储到参数中。该属性不能为负数，缺省值为0。
      • SaveLen ：当找到匹配项后，偏移量之后的几个字元存储到参数中。缺省值是-1，表示一直到结尾的整个字串都存入参数。
      • Convert : 可取的值有以下两种:

    HTML_TO_URL : 将 HTML-encoded 资料转成 URL-encoded 资料格式

    HTML_TO_TEXT : 将 HTML-encoded 资料转成纯文字资料格式

    • 实例讲解

    目的：取得页面中的商品状态，如果状态是正常态就改为注销态，否则改为正常态。

    录制脚本使用的是URL based scrīpt

    将返回的数据记录到日志

    • 直接手工访问页面，检查URL

    该页面上点击右键，选择属性

    看到URL，对照录制下的脚本中有：
    web_url("modifyOfferingStatePage.do",
    "URL={url}/web/businessAccept/order/modifyOfferingStatePage.do?offeringId=
    282172&offeringSpecId=1&offeringSpecName=    普通宽带（ADSL/LAN）&customerName=
    {clientname}&nodeId=260000&pos1=    定购管理&pos2=修改商品状态",

    "Resource=0",
    "RecContentType=text/html",
    "Referer={url}/web/businessAccept/order/orderMenu.do",
    "Snapshot=t23.inf",
    "Mode=HTTP",
    LAST);
    于是在这段代码前添加注册函数：
    web_reg_save_param("oldstate",
    "LB/IC=    原有商品状态：</td>",
    "RB/IC=</td>",
    "Search=body",
    "Ord=1",
    "RelFrameId=1",
    "SaveOffset=57",
    "SaveLen=4",
    LAST);
    web_url("modifyOfferingStatePage.do",
    "URL={url}/web/businessAccept/order/modifyOfferingStatePage.do?offeringId=
    282172&offeringSpecId=1&offeringSpecName=
    普通宽带（ADSL/LAN）&customerName={clientname}&nodeId=
    260000&pos1=    定购管理&pos2=修改商品状态",

    "Resource=0",
    "RecContentType=text/html",
    "Referer={url}/web/businessAccept/order/orderMenu.do",
    "Snapshot=t23.inf",
    "Mode=HTTP",
    LAST);
    ...............
    //    将得到的内容存入日志用于检查
    lr_log_message("getvalue : %s",lr_eval_string ("{oldstate}"));

    if ( lr_eval_string ("{oldstate}") == "正常"){
    web_submit_data("modifyOfferingState.do",
    "Action={url}/web/businessAccept/order/modifyOfferingState.do",
    "Method=POST",
    "RecContentType=text/html",