对非自动化测试的自动化支持

在过去的十多年来，已经看到了在支持需求管理、应用程序设计和开发、代码分析以及单元、系统和部署测试的应用软件方面有了实质的进步。依次来看，这些解决方案已经帮助开发人员改进了质量和加速了驱动核心业务功能的软件应用程序的交付。在熟练用户的控制下，测试自动化工具新的发展使得交付高质量应用软件变得更容易了。然而，尽管取得了这些进步，软件测试的大多数仍然是手工进行的。

业务分析师是测试人员
为什么那么多公司进行自动化测试很困难？一个原因就是，迄今为止，测试自动化工具在很大程度上忽略了最大一类测试软件的人的需求：业务分析师。这些职员扮演了一个关键角色，不但是在定义业务需求上，而且要确保这些需求满足新的过程和系统的开发和部署，包括软件应用程序。

由于业务分析师对一个开发项目背后的业务驱动有深厚的理解，他们在进行确认新应用软件的业务能力－－还有其稳定性和功能时可以“击中要点”。例如进行需求捕获和管理的IBM Rational RequisitePro和进行业务过程建模的IBM WebSphere Business Integrator，可以帮助分析师创建和管理新软件应用的业务用例。但是IBM Rational Manual Tester是真正支持他们的测试活动的第一个自动化工具。

对于业务分析师的测试过程
业务分析师常常执行基于定义软件应用的规格说明或用例文档的测试。这些文档提供了关于应用软件如何进行操作的详细指南，包括其核心和可选工作流。遵循这些规格说明，业务设计师通常手动地测试软件应用程序，并用他们熟悉的格式（例如，Microsoft Word 或 Excel）记录他们的发现。大多数人没有技能和时间对开发人员和专业测试人员使用的测试自动化工具精通掌握。此外，他们经常在开发周期的早期开始测试业务用例，而这时应用软件还没有到达可以进行自动化操作所需要的稳定性。强制要求分析师或其他非技术测试者掌握测试自动化可能也不会产生合适的结果；这会将关注点从“这个应用软件满足我公司的业务需求吗？”转到“我可以使用这个工具自动化哪些测试？”上。因此，如果我们承认手工测试对于分析师，执行验收测试的最终用户，甚至是专业的测试技术人员都是一个有效的方法，那么我们做什么才能提高他们测试的速度和效率呢？

IBM Rational Manual Tester：简要概述
IBM Rational Manual Tester是一个易于使用的自动化工具，用来加速和提高手动测试的正确度。对于使用自动化和手工测试方法的团队来说是合适的，同样也适用于那些没有测试自动化工具的团队。关键能力包括：

• 一个进行测试验证的组件化的，“构建阻塞”方法
  
  
• 简化使用单点更新的测试维护
  
  
• 开发健壮的、易读的手工测试的Rich text 编辑
  
  
• 批量导入Microsoft Word 和 Excel的手工测试文档
  
  
• 提高手工测试执行的准确度和速度的辅助数据入口
  
  
• 在测试执行期间的辅助数据对比
  
  
• 支持分布式团队
  
  

让我们详细看一下每种能力。

一个进行测试验证的组件化的，“构建阻塞”方法
对应用软件开发采用组件化的方法是大多数开发工具支持的一个最佳实践。它允许不同的团队分别工作在不同的构件上，能够使开发人员更迅速地通过重用公共构件组装应用软件。一些自动化测试工具也使用这种方法进行测试开发。它们允许测试人员设计构件，然后他们就可以将这些构件组装起来创建一系列测试来验证整个软件应用程序。这种方法对于手工测试还不太典型，因为传统上用来记录手工测试的这些工具为此进行设计的，没有提供构建阻塞能力。然而，使用IBM Rational Manual Tester，你可以构件的测试集合起来，这些构件记录了测试应用软件一小部分区域的步骤集。你也可以重用每个构件，来组合成多种较大的验证一个应用软件用例的测试。

简化使用单点更新的测试维护
在多个测试之间共享的测试构件被称作是“链接的”。使用IBM Rational Manual Tester，当在测试中对一个应用软件的变化影响了一个用于多个测试中的链接构件时，测试编写者只需要更新测试构件中的步骤一次就可以了。工具会自动地将变化传播到共享该构件的所有手工测试去。通常，测试脚本维护，不论是手工的还是自动的，都是测试资源的最大消耗。这种单点更新能力将会为业务分析师和测试团队带来极大的效率和较低的维护成本。

开发健壮的、易读的手工测试的Rich text 编辑
IBM Rational Manual Tester 提供了使用rich text编辑特性建立手工测试的能力。这使得用户在测试期间将文字变成粗体黑字，来指出要选择的按钮或菜单，使用不同的字体指出要在测试执行期间输入的数据，并使用文件夹来分组步骤的逻辑块和嵌入式图像，这些图像可以提供了测试执行人员执行测试时的另外的详细内容。所有这些能力使得测试在执行期间更容易的进行。

批量导入Microsoft Word 和 Excel的手工测试文档
如果你的手工测试已经在Microsoft Word 或 Excel中记录下来了，使用IBM Rational Manual Tester，你可以批量导入这些内容，开始进行手工测试创建。

提高手工测试执行的准确度和速度的辅助数据入口
对于手工测试，测试执行者通常要向应用程序输入数据，来验证一个业务用例。这就会涉及到大量的数据或数据字符串。使用IBM Rational Manual Tester，你可以通过建立利用工具的辅助数据入口特性的测试，使得这些过程更有效。简单地提供测试执行者可以自动重用的数据，来替代将数据手工地输入到应用程序中。这将会加速数据入口过程，也确保了用于执行测试的数据被正确地输入。

在测试执行期间的辅助数据对比
除了输入数据之外，测试人员需要校验显示的数据或应用程序的输出是否是正确的。使用IBM Rational Manual Tester，测试编写者可以在记录测试时提供预期的输出数据。然后，在执行期间，比较器，这是提供实际的和预期的行为之间的一种可视化差异显示的工具，将会帮助测试人员确保数据输出与预先提供的数据是相同的。这些辅助数据比较有助于验证测试被正确地执行了。

支持分布式团队
今天，开发团队比以前更加分散。组织必须利用所有得到的资源来保持竞争力－－无论这些资源可能在哪里。应用软件测试者经常是广泛分布的。这就是为什么IBM Rational Manual Tester被设计出来，使得对于团队共享测试和结果变得更加容易，并且可以使用颁布控制工具来管理测试的变更。

进行自动化测试的桥梁
对于最终计划采用自动化测试的团队来说，IBM Rational Manual Tester提供了一个极好的桥梁。它介绍给团队成员有关测试自动化工具的最基本原理，例如IBM Rational Functional Tester：组件化测试设计，和数据入口和数据比较辅助工具。你的测试人员可以很容易地学会这些原理，而不用必须掌握一个复杂的测试自动化工具。

实施IBM Rational Manual Tester
IBM Rational Manual Tester的设计坚持了“保持简单”的原则。测试人员不需要忍受一个复杂而冗长的安装过程，或要有效使用工具进行的几周培训和咨询。他们可以集中在编写好的测试上，而不是在指出这个工具如何使用。Rational Manual Tester提供了许多通常在rich text编辑器中可用的技术，这些与简单的拖拽测试构件创建能力是一起的。要帮助用户平滑地迁移到Rational Manual Tester上，还打包了一个产品游览和教程。对于那些想要探究其高级特性的人来说，可以通过IBM Rational University进行一天的培训课程。

应用程序安全是在软件开发中正在形成的一个重要的需求。严重的品牌破坏，可能的财务损失，以及秘密问题，风险敏感客户－－例如金融机构和政府组织－－正在寻找方法来评估他们构建或购买的产品的安全情况，并计划最终保证销售商对他们的软件中的安全问题负责任。这个问题进一步加剧了开发的风险，也如同源程序的共享或开放。

最大的独立软件开发商已经开始关注这个问题的严重性。在2002年，微软开始致力于通过它自己的开发过程提高软件的安全性，包括培训和过程的改进。在这件工作开始的两个月，它的整个开发工作都被禁止对任何产品进行变更，除非有特定目的变更改进了安全性。很多其他的销售商，例如Oracle，也采用类似的方式高度重视软件安全性的影响。

本文介绍了CLASP，一个应用软件安全性过程和对Rational统一过程（RUP）的插件，由Secure Software开发的环境。CLASP提供给组织一种结构化的方法，在软件开发生命周期过程中处理应用软件安全性所关注的事情。

安全性的唯一困难
有效地定位软件安全问题是困难的，因为传统的软件开发生命周期（SDLC）并没有很好地处理这些问题。这是因为软件开发者缺乏结构化的指导；很少有比较新的这方面的书籍，他们只有收集最佳实践。

另外，安全性不是一个较普遍的特性。开发组织通常更倾向于关注核心功能属性，然后在开发过程中以一种特殊的方式处理安全性。但是开发者在安全性方面缺乏经验，只会提供服务的最小集。这通常导致了理解安全技术很匮乏。这样通常会导致过分依赖于糟糕的、大家都知道的安全技术。

比如，SSL是为在网络中传输数据提供数据机密性和完整性服务的最流行的方式。然而，大多数SSL部署会受到网络攻击的影响，因为这项技术普遍地都认识不清。特别是，人们倾向于把SSL看成是传统socket的补充，但是当运用这种方法时，关键服务器验证步骤被忽略了。执行合适的验证通常是一个高度复杂的过程。

开发技术是SSL或Java的组织经常对软件的安全性产生失败的感觉。例如，安全软件是一个非正式的Java程序，安全风险显现了出来，平均起来，一旦有千行的代码，就是一个非常大的数量。

对软件安全性的通常的小规模的方法是，组织经过了他们的认可，希望安全性问题将不会再自己出席，将大多数安全问题推延到他们出现时处理，经常是在软件部署之后进行。这就是所谓的被称为“透过和补丁”模型。

当然，当问题找到后，避免安全解决方案就是在软件开发后，增加一个可靠的模型来修复问题。实际上，IBM研究了在不同情况下选择安全问题的代价。

介绍CLASP
CLASP（Comprehensive， Lightweight Application Security Process）提供了一个组织好的架构。这项技术反映了开发团队六年来处理安全问题的经验，包括Building Secure Software ¹和 Secure Programming Cookbook。 ²

CLASP实际上是一组过程的片断，可以集成到任何软件开发过程。它设计得既高效且容易接受。它采用说明性的手段，证明组织将会采取这样的活动。并且他提供了一个广泛的安全资源，介绍工具用以实现自动过程。

CLASP既可以从一个单独的过程，也可以从RUP环境的一个插件中得到。你可以从http://www.securesoftware.com/CLASP/上找到更多的信息。

一个以活动为中心的方法
在CLASP的核心有三十个新的活动，他们可以集成到一个软件开发过程。表1列出了这些活动的顺序。这项活动描绘了标准的角色，在最右端列出来。

上方的活动属于项目经理。虽然这些职责没有组成一个及其重要的时间承诺，他们反映了CLASP哲学，即有效的安全性实践需要组织极的买入。例如，建立一个安全性敏感程序，应当要比简单的培训将会直接处理安全性功能的开发人员多。在开发生命周期中列出的每个人，应当接受基本的培训，这样将会使他们理解可以影响业务的宏观级问题。很明显，人民需要理解与安全相关活动相关联的直接成本，对一个已改进安全情况的长期利益也一样。否则，当一个项目开始出现问题时，如果他们没有对核心特性集有一个具体影响，安全性活动将会最先被延迟。

表1：在CLASP的核心有三十个新的活动，可以集成到一个软件开发过程

在CLASP中新的安全活动
对需求最主要的安全责任是为应用程序定义一个高水平的核心安全模型。例如，需求定义了确定什么资源困难存在风险，潜在的结果。不仅做这些活动解决特定的安全问题，而且他们也定义了一个项目经历能够应用的框架。

大多数安全活动通常绑定了软件的架构和设计。通过将安全性问题做为架构和设计的一部分，构架不仅仅节约了时间和金钱；他还能够将安全问题集中在几个最集中的开发组织。

正如在表1中注明的，一个安全稽查员拥有几个关键的任务，这在CLASP里是一个新的角色。开发团队能够更接近他们自己的系统来分析他们自己的效率。

CLASP在一些关键的传统软件工程活动里有影响，例如需求分析。CLASP从本质上改变了包含在这些活动里的步骤。

CLASP过程也介绍了一些新的活动，这些工件是完全文档化的，支持样例和模板。

CLASP实施指南
对于那些从来不用正常的方式解决安全问题的组织，CLASP的三十个活动可能看上去是很可怕的。但是，做为RUP的用户会期望，组织不需要执行CLASP定义的所有活动。要减轻负担，CLASP提供了一个实施指南，帮助项目经理来确认是否通过为每个活动提供如下信息来采用特殊的活动：

• 关于活动适用性的信息例如，当进行公共政府事项，或者当构建了将会使用后端数据库的程序，只有几个活动可应用。
• 与没有执行活动相关的风险的讨论相对于其他的CLASP活动，它包括了活动的影响。活动提供了很多价值，反之降低了很多组织里可能执行的活动。
• 指出实施成本根据活动的频率，日历时间，和工时。在很多情况下，活动包括非关键的任务步骤，但能提供更高的保障。另外，资源方面的指南包括指出自动技术的影响。
• 依赖关系的讨论在不同过程片断之间。

为了更进一步帮助浏览活动，CLASP包含了几个样例路标，集中在公共组织的需求。比如，这里有一个“light”路标，帮助组织查找对已有开发影响最小的过程。此外，还有一个对那些构建构建软件的组织的“C+A”路标，软件将进行标准U.S.的政府证明和委派过程。

支持工件
CLASP的活动文档能为组织提供一个灵活的框架。然而，有效的执行活动需要很多人都缺乏的安全经验。

安全性资源。CLASP提供了很多资源，支持所有安全的活动。包括了一个扩展的术语表和更多重要概念、原理的详细描述。这里也提供关于弱点的类的详细的信息。很大程度区别于传统的“弱点数据库”。代替的，这里是一个“root cause”数据库，提供了关于潜在问题的详细信息。

Root-cause数据库CLASP root-cause数据库为每一类问题都提供了全面的背景知识。它显示了阐明问题的代码样例，也给出了关于避免、检测和修复问题的详细信息。CLASP将会阶段性的更新以反映研究员可能发现的任何新类。 Root-cause数据库提供了一个对过程其余部分的强大的基础。还有大量的检查单和支持不同的CLASP定义的活动，并且这些检查单会广泛地影响到root-cause数据库。例如，CLASP为开发人员提供了一个安全代码指南的例子。单独的指南对于那些需要详细信息的人，会影响到root-cause数据库。

不同种类的评估已经成为一个能够更好地理解开发组织的需求的商业工具。评估可以有多或少的细节，它可以集中在过程架构，或者配置和变更管理环境上。当需求的领域跨越多个项目时，很多组织需要确定努力的优先级，即使他们知道在那里开始。

这个两部分的文章可以帮助你理解项目级的评估转换到到组织级的评估的理由，引入的复杂度和提供什么样的价值增值。我们的素材基于我们在一些IBM Rational 在金融、电信、IT、医药工业等的客户那里已经完成的评估。在第一部分，我们讨论动机，引入关键的概念；在第二部分，我们给出如何完成评估的路线图，这个路线图基于我们在IBM 软件开发平台上的解决方案上的经验。

[编者注释：本文最早准备作为IBM Rational Brand Services给IBM用户进行软件爱你开发能力评估的指导。在保持原有目的的同时，作者扩大了它的范围使得任何组织都可以自己进行评估或者请外部机构进行评估]

什么是软件开发能力评估？
IBM Rational tech rep toolbox已经提供了相当多种类的评估。有些评估可以做为现货服务产品，如：metrics assessment package, Rational ClearCase administration assessment package, 和 software development capability assessment package. ¹

软件开发能力评估的概念来自于为用户在组织范围内改善它们的开发能力的工作。评估的原因有很多，下面是一些我们碰到较多的情况：

• 新技术新的技术（例如从COBOL 环境转到Java 和 J2EE）将迫使组织重新思考他们的开发过程和工具环境，人们将构建他们的组织以学习新的工作方法。评估可以帮助定义哪些实践或者组织的哪些部分最需要变更，以及变更活动的优先级。
  
  
• 快速成长 软件开发组织在相当短的时间内快速成长，习惯于使用的非正规的软件开发环境已经不再适用。组织需要了解如何恢复对他们的开发能力的控制，然后转到更进一步的改进。（这种情况以前经常在dotcom领域出现，现在很罕见了）
  
  
• 合并 商业并购需要开发组织进行合并，这就意味着需要合并不同的和有时互相冲突的开发实践。需要创建通用的开发环境，但是经常不清楚应该首先引入哪些变更。
  
  
• 采购开发组织的项目是采购项目，或者需要考虑是否采购。组织通常希望能够改善评估和管理供应商的方法。如果供应商在海外就需要更多的挑战。
  
  
• 能力改善 组织通常需要改善总体的软件开发能力。组织需要理解它的强项和弱项，找到快速回报的方法。组织可以不需要通用工具集的标准化，但是评估可以指出采用标准化的益处。
  
  
• 市场驱动的过程改善 一些组织需要改善它们的软件或者系统开发过程以满足市场竞争的需要。合适的认证（如服从公认的质量标准如CMM, ISO, FDA, 等等）通常是在特定市场寻找机会的强制标准。
  
  
• 系统和产品 在一些工业领域（国防、电信、航天等等），系统从过去简单的机械和电子的简单组合增加为复杂的软件系统。系统开发组不同部分的协作在采用新技术时通常是一个挑战，并且增加系统的复杂度。一个改善的方法是不同的组使用通用的标准和通用的开发架构。
  
  
• 产品线的开发 组织可以开发和维护一条软件或者系统产品线，而不是单一产品。这一般意味着高水平的产品线的重用，过程可以在产品线的每个产品上重用，自动化开发可以帮助控制开发成本。这些产品线上的重复的开发周期也产生了对改善和开发过程持续优化的要求。
  
  

与软件开发能力评估对比，项目评估是改善一个特定项目组的软件开发能力，它不需要考虑跨组织的标准。这里需要处理的相关人员比较少，考虑的问题也较少，因此对哪些问题需要解决容易达成一致意见。

专门技术评估 可以是组织范围的，但是它们集中在专门的技术领域。例如，一个评估可能集中在组织怎样进行度量以确认项目的进展和质量方面。

大范围评估的标准
让我们假定组织想要进行大范围评估而不是项目级或者专门技术评估。那么完成组织范围的软件开发能力评估的标准是什么？

这种范围的评估需要一个组织和评估员的有意义的委托。例如，对于除了他们的软件开发能力之外没有稳定的理由的组织，可能是不值得进行评估的，因为获得评估结果的价值是很困难的。

下面是一些在你决定是否开始评估时需要考虑的：

• 商业驱动 商业驱动是什么？它是成本节约？达到更高的质量？或者能够更快交付？它们的优先级如何？驱动是否强烈得足够有一个变更的委托？如果有的话，委托是否与组织水平对应？
  
  
• 干系人 你的干系人是谁？确保你有不同的组织的观点。一个风险是你花费了太多的时间讨论拥护者--一个人的观点容易得到，但是谁也不可能有对所有位置的观点的描述。
  
  
• 组织的状态 组织的状态是什么？它的成熟的和可接受的变更是什么？在讨论时有哪些失败出现？这些与软件开发能力有关（我们可以帮助），或者与其它事情相关？软件开发能力是否是组织的关键？是否有以前的成功的变更的例子或者改善的进展？
  
  
• 价值机会 变更的价值看起来是什么？项目平均有多大，它们一般运行多长时间，开发组织有多大？软件开发能力的改变如何影响商业结果？组织如何依赖它的软件开发能力？
  
  

是否应该进行组织范围的评估依赖于几个标准。基于上面的描述，这里给出几个建议：

• 应该有强烈的商业驱动和迫切的变更需求 -- 其它的建议都不应该考虑，不值得做这样的评估。组织范围的评估应该领导变更。
  
  
• 在评估时你需要在你的团队包括正确的人。你与这些人的关系应该是稳固的，与客户组织的关系也必须稳固。
  
  
• 你应该给出评估的预算，它与任何考虑在开发工具上的全面投资相比都应该相当小。
  
  
• 应该给组织的管理层一个远景，其中应该包括构建强有力的软件开发能力。
  
  
• 组织应该通过创建管理层的领导变更的协作以展示承诺。
  
  

什么是评估的价值？
组织范围软件开发能力评估的主要目标是给被评估的团队提供价值。由外部人员进行的评估能够提供组织强项和弱项的外部的观点。它可以协助发现问题，基于最佳实践提供改进建议的先后次序。评估过程也将给关键人员提供一个阐述和讨论想法的机会，而他们以前没有时间充分地展示他们的想法。它在组织中构建对变更需求的理解。主要的一点是开发组织必须提供商业的价值。更好的软件开发将带来更好的商业结果。能力的评估意味着价值的改善。

评估的结果将帮助激发对变更的投资，以及帮助构建变更的策略。

最后，评估将作为阐述在组织中实现一个建议的解决方案的很好的基础，这个方案在评估期间完成需求的确定。

干系人和结果因素
有大量的因素影响商业结果，但是软件开发能力评估仅仅集中在那些与软件或者系统开发活动有关的方面：换句话说，那些因素可以由IBM 和 IBM Rational 解决方案实现，并能够增加客户的商业价值。因为因素和期待的结果的数量通常很大，在评估的早期确定合适的干系人对评估结果的期望是很关键的。图 1 给出了客户端的干系人对商业结果的期望：

图 1：评估过程的干系人

正如图1中显示的，在一个视图中有很多不同的干系人对评估成果的看法：

Executive management 关注与商业前景和商业策略，包括IT策略相关的结果。结果应该创建对于变更的紧迫需求，包括与商业驱动、角色定义、组织变更管理、风险管理、通信、和投资回报等相关的看法。

Finance 关注成本驱动、合同管理、价值链的费用、回报率、维护费用。

Supplier management 考虑 COTS使用，例如 B2B、子承包商管理和离岸开发的集成。

Production 关注工业过程自动化，控制和质量。

Sales 和 marketing 关注用户关心的（如CRM -- 客户关系管理），支持，在线服务，供应链集成，后勤，仓储和销售渠道。

Operations 关注商业过程和性能，过程集成，自动化和系统支持，过程和工具支持，质量管理，和跨操作架构的内部关系。

IT 关注组建策略，COTS，过程，工具，重用， Enterprise Architecture Integration (EAI)，采购策略，标准，技术，遗产，维护费用。

Developers 关注更好的软件开发技能，动机，公司文化，创造性，职业发展，授权和团队凝聚力。

Product management 关注通过产品策略产生收入，布置，包装，定价，技术，架构，质量约束，顺从标准，重用策略，质量图景，用户满意度，市场时机，细分，产品和操作的技术，覆盖的人群，创新管理。

所有干系人关注的内容都是相关的，并且相互增强。他们在一个组织中给出不同的观点，并帮助评估组组织评估问题和答案。并不是所有的观点都能够在单一的软件过程能力评估中展现出来，但是我们在规划这样一个评估时要牢记组织的架构。

能力评估框架
在介绍评估路线图之前，我们首先讨论在评估活动中能够提供的指导框架：

• 四个成功项目的协作领域 -- 基于对不同的 engineering disciplines如何互相协作的调查
  
  
• 简化的软件经济模型 -- 例如，基于COCOMO II
  
  
• 六个软件开发的最佳实践 -- 基于对工程实践的调研
  
  

最佳实践的框架在某种程度上通常更加适合于那些已经采用了IBM Rational Unified Process, RUP, 和Rational 技术的组织，否则你可能更加适合使用软件经济学模型或者四个实践领域。你也可以选择它们的组合。因为最佳实践的框架与更多的技术相关，你可以使用那些开发者和项目经理已经很熟悉的Rational技术，在与高层管理者交流时使用软件经济学模型和四个实践领域。

为什么我们没有提及 CMM/CMMI 作为框架之一？ CMM/CMMI ，一般来说，集中在组织中过程是否被使用和改善的过程成熟度上 -- 换句话说，这是一个开发组织的质量的标识，可以用来给它们的客户建立信任。我们这里讨论的评估更加集中在理解什么开发实践在使用，它们在哪里和怎样被改善以影响开发效果上。 ²

四个协作领域
如果评估在组织水平上进行，讨论的框架就集中在可以显著帮助的关键协作领域上。这种类型的框架支持一个好的开发基础架构，它推动跨开发项目所有领域的协作。IBM Rational的Murray Cantor 和 Lynn Mueller 已经定义了这样一个框架，在本文中称为“四个协作领域”：工程，程序/项目管理，业务集成和开发供应商管理。

这些协作领域都可以用在 IT应用开发，也可以用在产品开发。每个领域可以分为一系列的实践，我们评估每个实践意味着对组织成熟度的理解。每个实践的具体细节依赖于评估的开发组织的类型。

工程

讨论下面的实践可以让我们理解在产品/应用工程领域团队如何协作：

• 采用面向对象的系统架构和UML 以获取逻辑和物理设计
  
  
• 使用需求、设计、数据库模型，而不只使用文档
  
  
• 使用通用的集成库保存系统工程产物和产品数据
  
  
• 使用基于管理和专门领域（如硬件，电子等）的设计工具
  
  

程序/项目管理

讨论管理实践提供对组织、计划、成功度量和结果如何监控和通讯的洞察：

• 团队按照逻辑和物理组件划分，而不是功能单元
  
  
• 系统架构组维护整个项目
  
  
• 生命周期基于风险选择，降低完成费用的偏离
  
  
• 组织使用基于能力的，use-case驱动的迭代开发
  
  
• 有一个通用的、组织范围的集成的程序状态、稳定性、质量和财务的度量集合
  
  
• 挣值依赖于可论证的结果，而不是费用花费
  
  
• 有正在进行的系统和部件的集成测试
  
  

业务集成

大部分商业操作依赖于计算机系统，而评估组织考虑的范围和把系统开发作为集成的商业过程是至关重要的。理想情况下，系统开发应该反映组织的特性和商业策略 -- 例如，开发能力（按时间和预算交付高质量的产品的能力）应该考虑作为商业成功的关键因素。在这个协作领域，我们评估下列实践：

• 保证所有商业管理过程映射到工程和管理实践
  
  
• 使用通用的跨产品线的基础架构可以帮助优化操作环境(Service Oriented Architectures -- SOA -- 可以有效地优化商业过程到发布、集成和重用。它还可以帮助降低开发费用。)
  
  

开发供应商管理

在最后一个领域，我们评估供应商如何更有效地与项目生命周期集成，以及如何更有效地管理合同：

• 与供应商的合同映射到项目管理过程和开发生命周期模型（而不是反过来）。
  
  
• 使用共享的工程协作基础架构
  
  
• 使用集成的管理基础架构
  
  

上面描述的四个协作领域的每个的成熟度都可以描述为1到5级，如下所示：

1 = No capabilities（无能力）。 使用不同的方法和过程，几乎没有跨开发组织的集成

2 = Aware（意识）。 现代开发过程已经在知道这些方法的价值的项目组单独使用

3 = Capable（能力）。 现代开发过程已经在一些商业产品线的多个项目组使用，但是没有计划配置跨企业的集成过程

4 = Mature（成熟）。 企业已经开发了配置现代开发过程的计划，已经在选择的产品线上配置。

5 = World Class（世界级）。 企业已经在企业和它的供应商范围采用和配置了现代开发过程。

结果可以表示为一个矩阵 (15 x 5)，但是我们认为它更容易表示为一个可视化的"radar chart"，如图2所示。图2的例子显示了现在的情况和组织将来要达到的目标。

（点击放大）

图 2：开发组织的程度度越高，在图上覆盖的面积越大。由蓝点覆盖的区域表示当前的能力，由红点覆盖的区域表示期望的能力目标

简化的软件经济学模型
一种描述软件开发能力是否达到它们的商业目标的方法是，从软件经济学有关的角度看产品开发项目是如何完成的。为了评估能力和给出建议的目的，我们使用简化的COCOMO II 模型，它由四个关键的软件开发性能参数组成：

Software Development Effort = (Complexity)^(Process)(Team)(Environment)

这些参数对软件开发成果有以下影响：

• Complexity（复杂度）。 构建的大小，可以表示为人产生的素材的多少，包括技术素材，如源代码，也包括其它技术产物。因此评估应该寻找降低软件方案大小的机会，例如，通过增加重用程度来降低。
  
  
• Process（过程）。 过程的成熟度和效率，以及过程避免增加不应该增加的活动的能力，如返工，过多沟通等。当过程系数大于1时，"diseconomy of scale" ³将显著增加。评估应该找到是否有机会改善过程的成熟度和提高过程执行的效率。
  
  
• Team（团队）。 软件开发技巧，经验和团队成员的动力，也会影响团队的能力。评估应该寻找机会加速软件开发、最佳实践和开发工具的熟练程度。
  
  
• Environment（环境）。在软件开发能力中，它表示用来自动化软件开发过程的工具和技术。评估应该寻找机会改善使用集成工具、引入现代工具技术、自动化最佳实践和改进团队协作的环境。
  
  

六个最佳实践的框架
对比组织当前的实践和已经证实的软件最佳实践，是另外一个有用的理解组织当前能力的方法。下面列出的六个最佳实践是Rational在软件工程能领域的学习经验的结果。它们集中描述了帮助理解如何处理软件工程复杂性的领域：

• 迭代化开发。 为了减轻风险，项目组应该增量地开发软件，使用迭代的方法。每次迭代的结果是一个可执行的版本。架构被验证，早期的迭代被基线化。评估应该找到增进风险和计划控制的方法，其中的一个解决方案是引入迭代开发。
  
  
• 管理需求。 需求总是会变更，因此项目组应该使用一些方法，可以让他们有效地和你的干系人之间促进需求变更和有效通讯，并维护同客户的约定。评估应该研究诸如需求是否在控制之下、修正、高质量和可测试性等。需求的解决方案可以包括引入use cases等。
  
  
• 使用基于构件的体系架构。 在基于架构的过程中，目标是尽早地产生一个面对需求变更仍然很灵活的架构。评估应该寻找架构如何可视和存在于开发工作中，架构如何描述，架构能够做到怎样的稳固程度。
  
  
• 可视化建模。 可视的模型将提高抽象的等级，并使得对规格、架构和设计的通讯变得容易。评估应该寻找任何组织通讯的问题，这些问题通常可以通过引入更有效的可视化模型技术来弥补。
  
  
• 持续地质量验证。 在发布后发现和修复软件问题通常需要千百倍的成本。在整个生命周期进行验证和质量管理是在正确的时间完成正确的目标的基础。要使用那些可以把软件进展和有形的质量报告给你的干系人的技术。评估应该寻找这些问题，例如，被评估的开发组织是否有对质量是什么的定义，以及是否有验证质量的策略，测试活动如何被集成到其余的开发活动，测试人员和分析人员是否协作以保证需求的可测试性。
  
  
• 管理变更。 使用那些让你控制项目资产的所有者、状态和一致性的技术。变更控制不仅仅是检入和检出文件。它包括管理变更需求、工作空间、并行开发和集成及Build。评估应该研究组织通常使用哪些变更和配置管理的方针。例如，应该有对变更请求的程序的很好的理解，和对项目资产的更好的控制－－它们的状态和关系。建议的解决方案一般包括定义变更请求的程序，或者实现组织级的变更和配置管理的计划。
  
  

操作框架
即使一般不是软件开发能力评估建议改变组织架构的目标，评估组也需要理解一个组织的目标以便给出评估的建议范围和在评估完成后提出可行的解决方案。并不是所有的软件开发活动在从一个组织到另一个组织时处于同样的重要程度，这依赖于组织的架构和它的商业因素。

每个组织都有它自己的描述它的操作框架或结构的风格，我们在这里给出一个通用的框架，用来讨论和达成对组织范围的软件开发有关的活动如何和在哪里完成的更好理解。

让我们考虑一个通用操作的四个步骤

1. 项目级
   
   
2. 产品线级
   
   
3. 业务单元级
   
   
4. 公司级
   
   

这些级别的定义必须准确调整以对应特定的组织，特别是产品线级包括大部分商业的种类。

图 3 显示了一个组织的框架，嵌套的团队和能力的范围从项目级到公司级。如果评估仅仅处于项目级 ，我们在项目评估考虑它。但是在某些情况下客户需要对它们的组织进行更多的理解，我们可以与几个项目经理谈话，也可以在 产品线级上进行，甚至可以到更高的业务单元级。在有些情况下我们可以参考组织级评估，尽管这种情况可能导致混乱，因为我们仅仅看到了软件开发能力的方面。

图 3： 组织框架

现在，让我们学习如何进行图3中每一步的评估过程。

项目级
框架中最低的等级是项目级，组织中这个级别一般是进行独立的开发项目。项目级是一组同分配的预算到软件的发布之间的活动。它不仅包括发布零售系统和公司使用的系统，也包括任何在一个和几个产品线使用的系统。

图 4 显示了在项目级别通常包括的活动和它们的相互关系。项目级别的评估主要集中在以软件最佳实践为基准的软件开发项目的有效性的理解和评估上。这个级别的评估发生的最多，因为它们的成本很低，评估结果的影响也很容易理解。项目评估通常非常集中在找到帮助项目成功跨越里程碑和最后期限上

图 4：项目过程

产品线级
更高一层的组织框架是产品线级。它阐述了使用商业水平的框架和扩展到俘获那些最适合公司的单一产品线有效操作的活动和相互关系上。

对于那些没有软件开发产品的组织，而开发支持组织自己的系统的组织来说，依赖于系统的复杂程度，这个级别可以存在也可以不存在。如果存在，它可以成为“IT 策略”级。很多在产品开发组织看到的问题仍然存在，但是它们的重点不同。例如，构建支持特定商业过程的能力在这种类型的组织中可能更重要一些。

图 5 描述了通常包括在产品线级的通用的活动和相互关系。产品线级的评估主要集中在：

1. 理解作为产品线、产品开发、产品和供应链操作导入软件开发相关的活动的完成情况。
   
   
2. 对照基准评估实践的有效性。
   
   

不同的包括在产品线级的商业过程的数量可能相当大。在这个级别，操作的架构和集成是主要的焦点。强的集中架构是有竞争力的产品线策略的必须。重用方法影响产品和操作软件。评估将强调特定的架构策略。产品线级跨越组织架构如销售，开发组织，基础架构，产品，供应，和其它与产品线活动相关的组织。

图 5: 产品线过程

业务单元级
更高的级别是业务单元级，对应于特定市场部分。从公司级独立和不同的操作依赖于特定的商业和公司历史，成熟度，和大小。操作根据公司策略可以有很多变化，在一些公司文化中，策略给出一个重要的角色，这将导致在同样的问题方向和问题根源上很难得到一致。评估组必须小心识别正确的角色，给出客观的位置，以保证在分析和评估发现时考虑所有观点。

业务单元级的评估与公司级有相同的目标：理解商业过程，商业驱动和策略，与软件开发费用有关的活动。

公司级
框架的最高层是公司级。它包括这些活动：定义策略，方针，和指导公司所有组织化的操作的策略。一些组织有选择的团体方针如：供应商、过程、工具、标准、方针和标准架构。它们在组织中按照商业、成熟度、历史、公司文化和地理分布而变化。也有一些特定的团体拥有团体方针，例如过程和工具组或者质量组。

在公司级，评估集中在理解当前商业策略，商业驱动和IT策略上。组织被分析以理解与软件开发活动有关的商业过程和费用。

问题分析框架
一般的分析软件能力的方法都基于通过它们的症状识别问题，研究问题的根源和建议的实践。

从评估的观点，你应该试图给出两种信息的分类：

• 症状（Symptoms）或者努力点（pain points）。 这些事情经常折磨人。例如典型的问题是：我们已经两年没有碰到最后期限了，或者，用户一直抱怨我们产品的质量，或者，我们不能控制我们的需求，它们任何时候都会变化，因此我们不能碰到我们的最后期限。
  
  
• 导致症状的行为，根本原因（Root Causes）。 这些是人们每天要做或者不做的事情。引导会见的正确的专门技能和组合是保证收集正确的信息的基础。典型的例子是：我们缺乏通用的变更请求过程，或者我们没有通用的质量的定义。
  
  

图 6: 跟踪到问题根源的症状

一旦你理解的问题的根本原因，你就需要排出优先级。总是有上千个问题你可以改善，但是并不是所有的问题都有大的成果。要确保你理在你评估的组织层面理解症状或者努力点的影响－－它们的成本，如果你什么也不做的话结果是什么。通常，得到一个确定的数字是很困难的，因此你可以用粗略的标准，看多少人碰到过这些症状。要确定根本原因的优先级，你可以看多少症状似乎相关，症状有多严重。

一个理解优先级的技术是看看在组织的不同级别努力点和根本原因是如何强调的，以及它们如何增强补充的。你可以发现在更高级别的根本原因在较低的级别上是努力点。这里我们引入组织的努力点，图7给出一个示例。

图 7: 努力点和相应的根本原因的例子。

确定优先级是很复杂的工作，IBM 研究人员和咨询人员已经共同开发了一个商业的价值模型工具，包括可操作的财务度量。这个工具已经用于软件开发能力评估，它包括COCOMO II成本度量，在前面提过的四个协作领域，共有5个级别，从“无能力”到“世界级”。

努力点和业务评价建模工具你都可以用在评估中，以帮助找到能够帮助改善你的组织的商业价值的建议。

一旦你已经排出了根本原因的优先级，你就可以可以针对这些根本原因给出解决方案。在这里，指出你用来收集评估数据的框架是最好的框架是很重要的。分析的一部分是理解客户如何思考，理解，和组织它们的问题。你揭示的是需要用作用户描述的框架，或者你可以找到用户思考和理解的模式实际上是为什么他们与实际的问题斗争。例如，软件开发组织的绊脚石经常是在开发流程之间进行通讯。在这种情况下，使用最佳实践作为解决方案的框架可能是不合适的，因为实际的问题不是最佳实践本身，而是它们的界面。

你可能会问：为什么我们需要进行这些冗长的分析？在我们已经有最佳实践的时候，为什么我们不简单地建议客户使用？这有两个主要原因：

• 客户需要看到他们自己改变的动机，以及看到它们不改变将会发生什么结果。
  
  
• 很少建议一次采用全部的最佳实践。改变应该仅仅从最需要的领域和最可能成果的领域开始。因此，一个完全的图象，将给出所有领域的能力，允许你确定需要改变的优先级。
  
  

分析框架的三个单元应该与操作框架的水平相关。 症状，根本原因和最佳实践在每个级别看起来都不同。你需要保证不同级别的干系人能够识别他们的看法。在这些干系人不同的理解之间可能得到一些有趣的结论。

把它们放在一起
我们已经介绍了多种软件开发能力评估的框架和工具。在评估时，你可以按照以下意见使用这些框架：

• 在早期与客户的讨论中，通过集中在商业操作框架上（从项目级到团体级）来确定评估的范围，以及评估的结果将产生哪些影响。确定组织中你需要找出会见的人。
  
  
• 引入能力评估框架（协作区域，软件经济学模型，最佳实践区域），并基于客户的意见，确定哪个或者哪些是最有用的。
  
  
• 使用选择的能力评估框架和头脑中的问题问题分析框架，明确在你会见以前需要回答的问题。注意这里不建议你按照严格的脚本进行会见，你想要与会见者进行自由谈话，你可以深入钻研你没有准备的领域。但是有一个简单的问题计划可以帮助你确保能够揭示正确的问题和得到做你的分析所必要的信息。
  
  
• 按照分析框架分析你收集到的信息
  
  
• 描述你建议的解决方案，你可以按照操作级别组织，或者按照客户的组织这些问题的方法进行组织。
  
  

第二部分将给出评估的更详细的步骤。

结论
软件开发能力评估可以进行需要的鉴别和度量以帮助开发组织提供更有商业价值的操作。给出的不同的框架可以帮助确定组织和技术维度的评估范围。在完全的IBM解决方案堆中，评估可以作为一个中间层的组件：

• 商业：商业咨询过程，财务服务
  
  
• 中间件：软件开发实践、工具、中间件、服务
  
  
• 技术：硬件，系统
  
  

在操作框架上完成的评估等级与其它相关的评估类型高度相关。在更高的级别上，单独的软件开发能力并不能够有效地影响组织；在这些级别上，商业的变化和在操作环境上的架构的决策也是关键的因素。在这里，软件开发能力是一个帮助构建更有效率的工具，IBM称为On Demand business（随需应变业务）的一部分。我们想象同其它类型评估（商业过程，价值链，管理，架构，度量）的相互作用，将更加全面的影响组织的价值。

第二部分将描述完成软件开发能力评估的路线图，也讨论了你如何基于你的发现描述一个实现的计划

代码检查工作表CLASP包含一个详细的工作表，它能帮助产生可重复的检查。此工作表不仅仅为安全稽核员提供方法记录一个应用程序的关键数据，它也提供一个检查列表指导检查员通过整个过程。当root-case数据库为发现特殊的弱点提供了详细的指导，代码检查原工作表帮助他确定需要包含哪些root cause

附加的工件。CLASP提供了大量附加的工件来帮助实施，包括：

• 一个公共安全需求的详细清单，需求指定者可以直接合并到他们的工作，但是安全性的检查单涉及到何时构建新的需求。
• 构建补充规约环境安全的指南，包括商业规则的例子和一般的约束。
• 一个应用软件安全情况的调查问卷表，是一个详细的工作表，可以帮助解析出架下的安全性情况的关键信息。对评估技术和如何安全地集成他们是有用的工具，提取关于设计，构建和开发的关键信息，并且常常不是立即可见的。
• 执行构架安全评估指南（常常被称为威胁模型），包括一个详细的检查单，以及一个将映射到CLASP root-cause数据库的一个公共威胁的数据库。
• 一个安全测试检查单，覆盖了所有公共的安全测试方法。
• 一组工具提供了可用工具的指南。集中在开源技术上，而不是检查安全软件的代码保证产品线。
• 一个可视化表示一个系统属性的指南。CLASP提供了一个简单的符号系统。

来自CLASP过程的支持工件提供了丰富的资源来文档化和评估软件的安全属性，这是向传统软件安全迈出的重要一步。

CLASP 状态
在十一月十五日，源程序会发布为RUP发布一个CLASP插件，与核心的CLASP过程文档1.0相符。RUP插件可用从IBM开发者网站下载(http://www.ibm.com/developerworks/rational/products/rup)。插件可用为RUP的用户免费使用。

关于CLASP应用程序安全过程的更多信息可以从这里得到：http://www.securesoftware.com/CLASP。

总结
IBM Rational Manual Tester是目前市面上专门设计用来改进最流行的测试方法：手工测试的唯一的工具。此工具适合于业务分析师、测试人员和执行手工测试的最终用户的技能，可以帮助他们提供测试开发、执行和维护的速度和有效性。它也可以作为当前的手工测试过程和未来的测试自动化之间的一座桥梁。使用Rational Manual Tester，你的团队可以将精力集中在交付一个高质量应用软件上，而忽略构建、执行和维护复杂的、组件化测试的复杂性。

你可以在下面找到有关此新产品的更多信息：
http://www-306.ibm.com/software/awdtools/tester/manual/sysreq/index.html。

关于作者 Sandra Wilkey一直作为软件质量产品方面的专家在IBM Rational软件工作。在处于这个职位之前，她一直作为Rational销售组织的一名销售和技术代表进行工作。她一直是Rational年度用户大会上的例行发言人，同时还有数量众多的软件开发和自动化测试交易展示会和研讨会。