软件开发能力评估Word下载.docx

软件开发能力评估Word下载.docx

《软件开发能力评估Word下载.docx》由会员分享，可在线阅读，更多相关《软件开发能力评估Word下载.docx（8页珍藏版）》请在冰豆网上搜索。

IBMRationaltechreptoolbox已经提供了相当多种类的评估。

有些评估可以做为现货服务产品，女口：

metricsassessmentpackage,

RationalClearCaseadministrationassessmentpackage,和softwaredevelopmentcapabilityassessmentpackage.1软件开发能力评估的概念来自于为用户在组织范围内改善它们的开发能力的工作。

评估的原因有很多，下面是一些我们碰到较多的情况：

新技术新的技术（例如从COBOL环境转到Java和J2EE）将迫使组织重新思考他们的开发过程和工具环境，人们将构建他们的组织以学习新的工作方法。

评估可以帮助定义哪些实践或者组织的哪些部分最需要变更，以及变更活动的优先级。

快速成长软件开发组织在相当短的时间内快速成长，习惯于使用的非正规的软件开发环境已经不再适用。

组织需要了解如何恢复对他们的开发能力的控制，然后转到更进一步的改进。

（这种情况以前经常在dotcom领域出现，现在很罕见了）合并商业并购需要开发组织进行合并，这就意味着需要合并不同的和有时互相冲突的开发实践。

需要创建通用的开发环境，但是经常不清楚应该首先引入哪些变更。

采购开发组织的项目是采购项目，或者需要考虑是否采购。

组织通常希望能够改善评估和管理供应商的方法。

如果供应商在海外就需要更多的挑战。

能力改善组织通常需要改善总体的软件开发能力。

组织需要理解它的强项和弱项，找到快速回报的方法。

组织可以不需要通用工具集的标准化，但是评估可以指出采用标准化的益处。

市场驱动的过程改善一些组织需要改善它们的软件或者系统开发过程以满足市场竞争的需要。

合适的认证（如服从公认的质量标准如CMM,ISO,FDA,等等）通常是在特定市场寻找机会的强制标准。

系统和产品在一些工业领域（国防、电信、航天等等），系统从过去简单的机械和电子的简单组合增加为复杂的软件系统。

系统开发组不同部分的协作在采用新技术时通常是一个挑战，并且增加系统的复杂度。

一个改善的方法是不同的组使用通用的标准和通用的开发架构。

产品线的开发组织可以开发和维护一条软件或者系统产品线，而不是单一产品。

这一般意味着高水平的产品线的重用，过程可以在产品线的每个产品上重用，自动化开发可以帮助控制开发成本。

这些产品线上的重复的开发周期也产生了对改善和开发过程持续优化的要求。

与软件开发能力评估对比，项目评估是改善一个特定项目组的软件开发能力，它不需要考虑跨组织的标准。

这里需要处理的相关人员比较少，考虑的问题也较少，因此对哪些问题需要解决容易达成一致意见。

专门技术评估可以是组织范围的，但是它们集中在专门的技术领域。

例如，一个评估可能集中在组织怎样进行度量以确认项目的进展和质量方面。

回页首大范围评估的标准让我们假定组织想要进行大范围评估而不是项目级或者专门技术评估。

那么完成组织范围的软件开发能力评估的标准是什么？

这种范围的评估需要一个组织和评估员的有意义的委托。

例如，对于除了他们的软件开发能力之外没有稳定的理由的组织，可能是不值得进行评估的，因为获得评估结果的价值是很困难的。

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

商业驱动商业驱动是什么？

它是成本节约？

达到更高的质量？

或者能够更快交付？

它们的优先级如何？

驱动是否强烈得足够有一个变更的委托？

如果有的话，委托是否与组织水平对应？

涉众你的涉众是谁？

确保你有不同的组织的观点。

一个风险是你花费了太多的时间讨论拥护者一个人的观点容易得到，但是谁也不可能有对所有位置的观点的描述。

组织的状态组织的状态是什么？

它的成熟的和可接受的变更是什么？

在讨论时有哪些失败出现？

这些与软件开发能力有关（我们可以帮助），或者与其它事情相关？

软件开发能力是否是组织的关键？

是否有以前的成功的变更的例子或者改善的进展？

价值机会变更的价值看起来是什么？

项目平均有多大，它们一般运行多长时间，开发组织有多大？

软件开发能力的改变如何影响商业结果？

组织如何依赖它的软件开发能力？

是否应该进行组织范围的评估依赖于几个标准。

基于上面的描述，这里给出几个建议：

应该有强烈的商业驱动和迫切的变更需求--其它的建议都不应该考虑，不值得做这样的评估。

组织范围的评估应该领导变更。

在评估时你需要在你的团队包括正确的人。

你与这些人的关系应该是稳固的，与客户组织的关系也必须稳固。

你应该给出评估的预算，它与任何考虑在开发工具上的全面投资相比都应该相当小。

应该给组织的管理层一个远景，其中应该包括构建强有力的软件开发能力。

组织应该通过创建管理层的领导变更的协作以展示承诺。

回页首什么是评估的价值？

组织范围软件开发能力评估的主要目标是给被评估的团队提供价值。

由外部人员进行的评估能够提供组织强项和弱项的外部的观点。

它可以协助发现问题，基于最佳实践提供改进建议的先后次序。

评估过程也将给关键人员提供一个阐述和讨论想法的机会，而他们以前没有时间充分地展示他们的想法。

它在组织中构建对变更需求的理解。

主要的一点是开发组织必须提供商业的价值。

更好的软件开发将带来更好的商业结果。

能力的评估意味着价值的改善。

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

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

涉众和结果因素有大量的因素影响商业结果，但是软件开发能力评估仅仅集中在那些与软件或者系统开发活动有关的方面：

换句话说，那些因素可以由IBM和IBMRational解决方案实现，并能够增加客户的商业价值。

因为因素和期待的结果的数量通常很大，在评估的早期确定合适的涉众对评估结果的期望是很关键的。

图1给出了客户端的涉众对商业结果的期望：

图1：

评估过程的涉众正如图1中显示的，在一个视图中有很多不同的涉众对评估成果的看法：

行政管理（Executivemanagement）关注与商业前景和商业策略，包括IT策略相关的结果。

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

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

供应商管理（Suppliermanagement）考虑COTS使用，例如B2B、子承包商管理和离岸开发的集成。

生产制造（Production）关注工业过程自动化，控制和质量。

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

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

IT关注组建策略，COTS，过程，工具，重用，EnterpriseArchitectureIntegration（EAI），采购策略，标准，技术，遗产，维护费用。

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

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

所有涉众关注的内容都是相关的，并且相互增强。

他们在一个组织中给出不同的观点，并帮助评估组组织评估问题和答案。

并不是所有的观点都能够在单一的软件过程能力评估中展现出来，但是我们在

规划这样一个评估时要牢记组织的架构。

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

四个成功项目的协作领域--基于对不同的engineeringdisciplines如何互相协作的调查简化的软件经济模型--例如，基于COCOMOII六个软件开发的最佳实践--基于对工程实践的调研最佳实践的框架在某种程度上通常更加适合于那些已经采用了IBMRationalUnifiedProcess,RUP,和Rational技术的组织，否则你可能更加适合使用软件经济学模型或者四个实践领域。

你也可以选择它们的组合。

因为最佳实践的框架与更多的技术相关，你可以使用那些开发者和项目经理已经很熟悉的Rational技术，在与高层管理者交流时使用软件经济学模型和四个实践领域。

为什么我们没有提及CMM/CMMI作为框架之一？

CMM/CMMI，一般来说，集中在组织中过程是否被使用和改善的过程成熟度上--换句话说，这是一个开发组织的质量的标识，可以用来给它们的客户建立信任。

我们这里讨论的评估更加集中在理解什么开发实践在使用，它们在哪里和怎样被改善以影响开发效果上。

2四个协作领域如果评估在组织水平上进行，讨论的框架就集中在可以显著帮助的关键协作领域上。

这种类型的框架支持一个好的开发基础架构，它推动跨开发项目所有领域的协作。

IBMRational的Murray

Cantor和LynnMueller已经定义了这样一个框架，在本文中称为“四个协作领域”：

工程，程序/项目管理，业务集成和开发供应商管理。

这些协作领域都可以用在IT应用开发，也可以用在产品开发。

每个领域可以分为一系列的实践，我们评估每个实践意味着对组织成熟度的理解。

每个实践的具体细节依赖于评估的开发组织的类型。

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

采用面向对象的系统架构和UML以获取逻辑和物理设计使用需求、设计、数据库模型，而不只使用文档使用通用的集成库保存系统工程产物和产品数据使用基于管理和专门领域（如硬件，电子等）的设计工具程序/项目管理讨论管理实践提供对组织、计划、成功度量和结果如何监控和通讯的洞察：

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