软件开发能力评估

软件开发能力评估

在IBM Bluemix 云平台上开发并部署您的下一个应用。开始您的试用

不同种类的评估已经成为一个能够更好地理解开发组织的

需求的商业工具。评估可以有多或少的细节，它可以集中在过程架构，或者配置和变更管理环境上。当需求的领域跨越多个项目时，很多组织需要确定努力的优先级，即使他们知道在那里开始。这个两部分的文章可以帮助你理解项目级的评估转换到到组织级的评估的理由，引入的复杂度和提供什么样的价值增值。我们的素材基于我们在一些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.1软件开发能力评估的概念来自于为用户在组织范围内改善它们的开发能力的工作。评估的原因有很多，下面是一些我们碰到较多的情况：新技术新的技术（例如从COBOL 环境转到Java 和J2EE）将迫使组织重新思考他们的开发过程和工具环境，人们将构建他们的组织以学习新的工作方法。评估可以帮助定义哪些实践或者组织的哪些部分最需要变更，以及变更活动的优先级。快速成长软件开发组织在相当短的时间内快速成长，习惯于使用的非正规的软件开发环境已经不再适用。组织需要了解如何恢复对他们的开发能力的控制，然后转到更进一步的改进。（这种情况以前经常在dotcom领域出现，现在很罕见了）合并商业并购需要开发组织进行合并，这就意味着需要合并不同的和有时互相冲突的开发实践。需要创建通用的开发环境，但是经常不清楚应该首先引入哪些变更。采购开发组织的项目是采购项目，或者需要考虑是否采购。组织通常希望能够改善评估和管理供应商的方法。如果供应商在海外就需要更多的挑战。能力改善组织通常需要改善总体的软件开发能力。组织需要理解它的强项和弱项，找到快速回报的方法。组织可以不需要通用工具集的标准化，但是评估可以指出采用标准化的益处。市场驱动的过程改善一些组织需要改善它们的软件或者系统开发过程以满足市场竞争的需要。合适的认证（如服从公认的质

量标准如CMM, ISO, FDA, 等等）通常是在特定市场寻找机会的强制标准。系统和产品在一些工业领域（国防、电信、航天等等），系统从过去简单的机械和电子的简单组合增加为复杂的软件系统。系统开发组不同部分的协作在采用新技术时通常是一个挑战，并且增加系统的复杂度。一个改善的方法是不同的组使用通用的标准和通用的开发架构。产品线的开发组织可以开发和维护一条软件或者系统产品线，而不是单一产品。这一般意味着高水平的产品线的重用，过程可以在产品线的每个产品上重用，自动化开发可以帮助控制开发成本。这些产品线上的重复的开发周期也产生了对改善和开发过程持续优化的要求。与软件开发能力评估对比，项目评估是改善一个特定项目组的软件开发能力，它不需要考虑跨组织的标准。这里需要处理的相关人员比较少，考虑的问题也较少，因此对哪些问题需要解决容易达成一致意见。专门技术评估可以是组织范围的，但是它们集中在专门的技术领域。例如，一个评估可能集中在组织怎样进行度量以确认项目的进展和质量方面。回页首大范围评估的标准让我们假定组织想要进行大范围评估而不是项目级或者专门技

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

价值是很困难的。下面是一些在你决定是否开始评估时需要考虑的：商业驱动商业驱动是什么？它是成本节约？达到更高的质量？或者能够更快交付？它们的优先级如何？驱动是否强烈得足够有一个变更的委托？如果有的话，委托是否与组织水平对应？涉众你的涉众是谁？确保你有不同的组织的观点。一个风险是你花费了太多的时间讨论拥护者--一个人的观点容易得到，但是谁也不可能有对所有位置的观点的描述。组织的状态组织的状态是什么？它的成熟的和可接受的变更是什么？在讨论时有哪些失败出现？这些与软件开发能力有关（我们可以帮助），或者与其它事情相关？软件开发能力是否是组织的关键？是否有以前的成功的变更的例子或者改善的进展？价值机会变更的价值看起来是什么？项目平均有多大，它们一般运行多长时间，开发组织有多大？软件开发能力的改变如何影响商业结果？组织如何依赖它的软件开发能力？是否应该进行组织范围的评估依赖于几个标准。基于上面的描述，这里给出几个建议：应该有强烈的商业驱动和迫切的变更需求-- 其它的建议都不应该考虑，不值得做这样的评估。组织范围的评估应该领导变更。在评估时你需要在你的团队包括正确的人。你与这些人的关系应该是稳固的，与客户组织的关系也必须稳固。你应该给出评估的预算，它与任何考虑在开发工具上的全面投资相比都应该相当小。应该给组织的管理层一个远景，其中

应该包括构建强有力的软件开发能力。组织应该通过创建管理层的领导变更的协作以展示承诺。回页首什么是评估的价值？组织范围软件开发能力评估的主要目标是给被评估的

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

的基础，这个方案在评估期间完成需求的确定。涉众和结果因素有大量的因素影响商业结果，但是软件开发能力评估仅仅集中在那些与软件或者系统开发活动有关的方面：换句话说，那些因素可以由IBM 和IBM Rational 解决方案实现，并能够增加客户的商业价值。因为因素和期待的结果的数量通常很大，在评估的早期确定合适的涉众对评估结果的期望是很关键的。图 1 给出了客户端的涉众对商业结果的期望：图1：评估过程的涉众正如图1中显示的，在一个视图中有很多不同的涉众对评估成果的看法：行政管理（Executive management）关注与商业前景和商业策略，包括IT策略相

关的结果。结果应该创建对于变更的紧迫需求，包括与商业驱动、角色定义、组织变更管理、风险管理、通信、和投资回报等相关的看法。财务（Finance）关注成本驱动、合同管理、价值链的费用、回报率、维护费用。供应商管理（Supplier management）考虑COTS使用，例如B2B、子承包商管理和离岸开发的集成。生产制造（Production）关注工业过程自动化，控制和质量。销售和市场（Sales and 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 ，一般来说，集中在组织中过程是否被使用和改善的过程成熟度上-- 换句话说，这是一个开发组织的质量的标识，可以用来给它们的客户建立信任。我们这里讨论的评估更加集中在理解什么开发实践在使用，它们在哪里和怎样被改善以影响开发效果上。2四个协作领域如果评估在组织水平上进行，讨论的框架就集中在可以显著帮助的关键协作领域上。这种类型的框架支持一个好的开发基础架构，它推动跨开发项目所有领域的协作。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'3 将显著增加。评估应该找到是否有机会改善过程的成熟度和提高过程执行的效率。Team（团队）。软件开发技巧，经验和团队成员的动力，也会影响团队的能力。评估应该寻找机会加速软件开发、最佳实践和开发工具的熟练程度。Environment（环境）。在软件开发能力中，它表示用来自动化软件开发过程的工具和技术。评估应该寻找机会改善使用集成工具、引入现代工具技术、自动化最佳实践和改进团队协作的环境。六个最佳实践的框架对比组织当前的实践和已经证实的软件最佳实践，是另外一个有用的理解组织当前能力的方法。下面列出的六个最佳实践是

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

否有验证质量的策略，测试活动如何被集成到其余的开发活动，测试人员和分析人员是否协作以保证需求的可测试性。管理变更。使用那些让你控制项目资产的所有者、状态和一致性的技术。变更控制不仅仅是检入和检出文件。它包括管理变更需求、工作空间、并行开发和集成及Build。评估应该研究组织通常使用哪些变更和配置管理的方针。例如，应该有对变更请求的程序的很好的理解，和对项目资产的更好的控制－－它们的状态和关系。建议的解决方案一般包括定义变更请求的程序，或者实现组织级的变更和配置管理的计划。回页首操作框架即使一般不是软件开发能力评估建议改变组织架构的目标，评估组也需要理解一个组织的目标以便给出评估的建议范围和在评估完成后提出可行的解决方案。并不是所有的软件开发活动在从一个组织到另一个组织时处于同样的重要程度，这依赖于组织的架构和它的商业因素。每个组织都有它自己的描述它的操作框架或结构的风格，我们在这里给出一个通用的框架，用来讨论和达成对组织范围的软件开发有关的活动如何和在哪里完成的更好理解。让我们考虑一个通用操作的四个步骤项目级产品线级业务单元级公司级这些级别的定义必须准确调整以对应特定的组织，特别是产品线级包括大部分商业的种类。图 3 显示了一个组织的框架，嵌套的团队和能力的范围从项目级到公司级。如果评估仅仅处于项目级，我们在项目评估考虑