软件开发能力评估
软件开发能力评估已经成为一个能够更好地理解开发组织的需求的商业工具。本系列两部分将描述从项目级的评估转换到到组织级的评估的理由、引入的复杂度和提供什么样的价值增值。
第一部分: 概念
不同种类的评估已经成为一个能够更好地理解开发组织的需求的商业工具。评估可以有多或少的细节，它可以集中在过程架构，或者配置和变更管理环境上。当需求的领域跨越多个项目时，很多组织需要确定努力的优先级，即使他们知道在那里开始。
这个两部分的文章可以帮助你理解项目级的评估转换到到组织级的评估的理由，引入的复杂度和提供什么样的价值增值。我们的素材基于我们在一些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 显示了一个组织的框架，嵌套的团队和能力的范围从项目级到公司级。如果评估仅仅处于项目级 ，我们在项目评估考虑它。但是在某些情况下客户需要对它们的组织进行更多的理解，我们可以与几个项目经理谈话，也可以在 产品线级上进行，甚至可以到更高的业务单元级。在有些情况下我们可以参考组织级评估，尽管这种情况可能导致混乱，因为我们仅仅看到了软件开发能力的方面。
图 3： 组织框架
现在，让我们学习如何进行图3中每一步的评估过程。
框架中最低的等级是项目级，组织中这个级别一般是进行独立的开发项目。项目级是一组同分配的预算到软件的发布之间的活动。它不仅包括发布零售系统和公司使用的系统，也包括任何在一个和几个产品线使用的系统。
图 4 显示了在项目级别通常包括的活动和它们的相互关系。项目级别的评估主要集中在以软件最佳实践为基准的软件开发项目的有效性的理解和评估上。这个级别的评估发生的最多，因为它们的成本很低，评估结果的影响也很容易理解。项目评估通常非常集中在找到帮助项目成功跨越里程碑和最后期限上
图 4：项目过程
更高一层的组织框架是产品线级。它阐述了使用商业水平的框架和扩展到俘获那些最适合公司的单一产品线有效操作的活动和相互关系上。
对于那些没有软件开发产品的组织，而开发支持组织自己的系统的组织来说，依赖于系统的复杂程度，这个级别可以存在也可以不存在。如果存在，它可以成为“IT 策略”级。很多在产品开发组织看到的问题仍然存在，但是它们的重点不同。例如，构建支持特定商业过程的能力在这种类型的组织中可能更重要一些。
图 5 描述了通常包括在产品线级的通用的活动和相互关系。产品线级的评估主要集中在：
- 理解作为产品线、产品开发、产品和供应链操作导入软件开发相关的活动的完成情况。
- 对照基准评估实践的有效性。
不同的包括在产品线级的商业过程的数量可能相当大。在这个级别，操作的架构和集成是主要的焦点。强的集中架构是有竞争力的产品线策略的必须。重用方法影响产品和操作软件。评估将强调特定的架构策略。产品线级跨越组织架构如销售，开发组织，基础架构，产品，供应，和其它与产品线活动相关的组织。
图 5: 产品线过程
更高的级别是业务单元级，对应于特定市场部分。从公司级独立和不同的操作依赖于特定的商业和公司历史，成熟度，和大小。操作根据公司策略可以有很多变化，在一些公司文化中，策略给出一个重要的角色，这将导致在同样的问题方向和问题根源上很难得到一致。评估组必须小心识别正确的角色，给出客观的位置，以保证在分析和评估发现时考虑所有观点。
业务单元级的评估与公司级有相同的目标：理解商业过程，商业驱动和策略，与软件开发费用有关的活动。
框架的最高层是公司级。它包括这些活动：定义策略，方针，和指导公司所有组织化的操作的策略。一些组织有选择的团体方针如：供应商、过程、工具、标准、方针和标准架构。它们在组织中按照商业、成熟度、历史、公司文化和地理分布而变化。也有一些特定的团体拥有团体方针，例如过程和工具组或者质量组。
在公司级，评估集中在理解当前商业策略，商业驱动和IT策略上。组织被分析以理解与软件开发活动有关的商业过程和费用。
一般的分析软件能力的方法都基于通过它们的症状识别问题，研究问题的根源和建议的实践。
从评估的观点，你应该试图给出两种信息的分类：
- 症状（Symptoms）或者痛点（pain points）。 这些事情经常折磨人。例如典型的问题是：我们已经两年没有碰到最后期限了，或者，用户一直抱怨我们产品的质量，或者，我们不能控制我们的需求，它们任何时候都会变化，因此我们不能碰到我们的最后期限。
- 导致症状的行为，根本原因（Root Causes）。 这些是人们每天要做或者不做的事情。引导会见的正确的专门技能和组合是保证收集正确的信息的基础。典型的例子是：我们缺乏通用的变更请求过程，或者我们没有通用的质量的定义。
图 6: 跟踪到问题根源的症状
一旦你理解的问题的根本原因，你就需要排出优先级。总是有上千个问题你可以改善，但是并不是所有的问题都有大的成果。要确保你理在你评估的组织层面理解症状或者痛点的影响－－它们的成本，如果你什么也不做的话结果是什么。通常，得到一个确定的数字是很困难的，因此你可以用粗略的标准，看多少人碰到过这些症状。要确定根本原因的优先级，你可以看多少症状似乎相关，症状有多严重。
一个理解优先级的技术是看看在组织的不同级别痛点和根本原因是如何强调的，以及它们如何增强补充的。你可以发现在更高级别的根本原因在较低的级别上是痛点。这里我们引入组织的痛点，图7给出一个示例。
图 7: 痛点和相应的根本原因的例子。
确定优先级是很复杂的工作，IBM 研究人员和咨询人员已经共同开发了一个商业的价值模型工具，包括可操作的财务度量。这个工具已经用于软件开发能力评估，它包括COCOMO II成本度量，在前面提过的四个协作领域，共有5个级别，从“无能力”到“世界级”。
痛点和业务评价建模工具你都可以用在评估中，以帮助找到能够帮助改善你的组织的商业价值的建议。
一旦你已经排出了根本原因的优先级，你就可以可以针对这些根本原因给出解决方案。在这里，指出你用来收集评估数据的框架是最好的框架是很重要的。分析的一部分是理解客户如何思考，理解，和组织它们的问题。你揭示的是需要用作用户描述的框架，或者你可以找到用户思考和理解的模式实际上是为什么他们与实际的问题斗争。例如，软件开发组织的绊脚石经常是在开发流程之间进行通讯。在这种情况下，使用最佳实践作为解决方案的框架可能是不合适的，因为实际的问题不是最佳实践本身，而是它们的界面。
你可能会问：为什么我们需要进行这些冗长的分析？在我们已经有最佳实践的时候，为什么我们不简单地建议客户使用？这有两个主要原因：
- 客户需要看到他们自己改变的动机，以及看到它们不改变将会发生什么结果。
- 很少建议一次采用全部的最佳实践。改变应该仅仅从最需要的领域和最可能成果的领域开始。因此，一个完全的图象，将给出所有领域的能力，允许你确定需要改变的优先级。
分析框架的三个单元应该与操作框架的水平相关。 症状，根本原因和最佳实践在每个级别看起来都不同。你需要保证不同级别的涉众能够识别他们的看法。在这些涉众不同的理解之间可能得到一些有趣的结论。
我们已经介绍了多种软件开发能力评估的框架和工具。在评估时，你可以按照以下意见使用这些框架：
- 在早期与客户的讨论中，通过集中在商业操作框架上（从项目级到团体级）来确定评估的范围，以及评估的结果将产生哪些影响。确定组织中你需要找出会见的人。
- 引入能力评估框架（协作区域，软件经济学模型，最佳实践区域），并基于客户的意见，确定哪个或者哪些是最有用的。
- 使用选择的能力评估框架和头脑中的问题问题分析框架，明确在你会见以前需要回答的问题。注意这里不建议你按照严格的脚本进行会见，你想要与会见者进行自由谈话，你可以深入钻研你没有准备的领域。但是有一个简单的问题计划可以帮助你确保能够揭示正确的问题和得到做你的分析所必要的信息。
- 按照分析框架分析你收集到的信息
- 描述你建议的解决方案，你可以按照操作级别组织，或者按照客户的组织这些问题的方法进行组织。
第二部分将给出评估的更详细的步骤。
软件开发能力评估可以进行需要的鉴别和度量以帮助开发组织提供更有商业价值的操作。给出的不同的框架可以帮助确定组织和技术维度的评估范围。在完全的IBM解决方案堆中，评估可以作为一个中间层的组件：
- 商业：商业咨询过程，财务服务
- 中间件：软件开发实践、工具、中间件、服务
- 技术：硬件，系统
在操作框架上完成的评估等级与其它相关的评估类型高度相关。在更高的级别上，单独的软件开发能力并不能够有效地影响组织；在这些级别上，商业的变化和在操作环境上的架构的决策也是关键的因素。在这里，软件开发能力是一个帮助构建更有效率的工具，IBM称为On Demand business（随需应变业务）的一部分。我们想象同其它类型评估（商业过程，价值链，管理，架构，度量）的相互作用，将更加全面的影响组织的价值。
第二部分将描述完成软件开发能力评估的路线图，也讨论了你如何基于你的发现描述一个实现的计划
Enhanced Telecom Operations Map (eTOM) Version 3.0. The Business Process Framework from the TeleManagement Forum Consortium （在http://www.tmforum.com中可得到）
Walker Royce. "Improving Software Development Economics Part I: Current Trends." The Rational Edge, April 2001.
Tom Peters. Thriving on Chaos: Handbook for a Management Revolution. HarperPerennial: 1991
Barry Boehm et al. Software Cost Estimation with Cocomo II. Prentice Hall PTR: 2000
John P. Kotter. Leading Change. Harvard Business School Press: 1996
|
|
Michel Reyrolle是IBM法国的一个技术经理。 |
 |
|
|
|
Maria Ericsson是IBM Rational战略服务组织（SSO）的一个主咨询师。她于1990年在Objectory AB开始工作在软件工程和对象技术领域，并与Ivar Jacobson合著了The Object Advantage: Business Process Re-engineering with Object Technology一书。自从1995年加入了Rational，她一直作为过程、业务建模和需求管理方面的一名指导者和训练者进行工作，并且作为Rational统一过程或RUP开发团队的一员工作了三年。作为SSO的部分，她当前关注于部署策略解决方案上，并成为IBM Rational领域培训团队的一员。她是一个瑞典居民，最早在Kista办事处。 |
Barry Boehm，在他的书Software Engineering Economics中，将"diseconomy of scale"定义为，由于一个项目规模的扩大和项目团队成员的数量增加而引起的生产率下降。
作者:Michel Reyrolle 更新日期:2006-01-01
来源:ibm.com
浏览次数:
相关文章
相关评论 发表评论
- No Comments