软件开发能力评估.doc
《软件开发能力评估.doc》由会员分享,可在线阅读,更多相关《软件开发能力评估.doc(19页珍藏版)》请在咨信网上搜索。
1、软件开发能力评估 在 IBM Bluemix 云平台上开发并部署您的下一个应用。开始您的试用不同种类的评估已经成为一个能够更好地理解开发组织的需求的商业工具。评估可以有多或少的细节,它可以集中在过程架构,或者配置和变更管理环境上。当需求的领域跨越多个项目时,很多组织需要确定努力的优先级,即使他们知道在那里开始。这个两部分的文章可以帮助你理解项目级的评估转换到到组织级的评估的理由,引入的复杂度和提供什么样的价值增值。我们的素材基于我们在一些IBM Rational 在金融、电信、IT、医药工业等的客户那里已经完成的评估。在第一部分,我们讨论动机,引入关键的概念;在第二部分,我们给出如何完成评估的
2、路线图,这个路线图基于我们在IBM 软件开发平台上的解决方案上的经验。编者注释:本文最早准备作为IBM Rational Brand Services给IBM用户进行软件爱你开发能力评估的指导。在保持原有目的的同时,作者扩大了它的范围使得任何组织都可以自己进行评估或者请外部机构进行评估什么是软件开发能力评估?IBM Rational tech rep toolbox已经提供了相当多种类的评估。有些评估可以做为现货服务产品,如:metrics assessment package, Rational ClearCase administration assessment package, 和 s
3、oftware development capability assessment package.1软件开发能力评估的概念来自于为用户在组织范围内改善它们的开发能力的工作。评估的原因有很多,下面是一些我们碰到较多的情况:新技术 新的技术(例如从COBOL 环境转到Java 和 J2EE)将迫使组织重新思考他们的开发过程和工具环境,人们将构建他们的组织以学习新的工作方法。评估可以帮助定义哪些实践或者组织的哪些部分最需要变更,以及变更活动的优先级。快速成长 软件开发组织在相当短的时间内快速成长,习惯于使用的非正规的软件开发环境已经不再适用。组织需要了解如何恢复对他们的开发能力的控制,然后转到更进
4、一步的改进。(这种情况以前经常在dotcom领域出现,现在很罕见了)合并 商业并购需要开发组织进行合并,这就意味着需要合并不同的和有时互相冲突的开发实践。需要创建通用的开发环境,但是经常不清楚应该首先引入哪些变更。采购 开发组织的项目是采购项目,或者需要考虑是否采购。组织通常希望能够改善评估和管理供应商的方法。如果供应商在海外就需要更多的挑战。能力改善 组织通常需要改善总体的软件开发能力。组织需要理解它的强项和弱项,找到快速回报的方法。组织可以不需要通用工具集的标准化,但是评估可以指出采用标准化的益处。市场驱动的过程改善 一些组织需要改善它们的软件或者系统开发过程以满足市场竞争的需要。合适的认
5、证(如服从公认的质量标准如CMM, ISO, FDA, 等等)通常是在特定市场寻找机会的强制标准。系统和产品 在一些工业领域(国防、电信、航天等等),系统从过去简单的机械和电子的简单组合增加为复杂的软件系统。系统开发组不同部分的协作在采用新技术时通常是一个挑战,并且增加系统的复杂度。一个改善的方法是不同的组使用通用的标准和通用的开发架构。产品线的开发 组织可以开发和维护一条软件或者系统产品线,而不是单一产品。这一般意味着高水平的产品线的重用,过程可以在产品线的每个产品上重用,自动化开发可以帮助控制开发成本。这些产品线上的重复的开发周期也产生了对改善和开发过程持续优化的要求。与软件开发能力评估对
6、比,项目评估是改善一个特定项目组的软件开发能力,它不需要考虑跨组织的标准。这里需要处理的相关人员比较少,考虑的问题也较少,因此对哪些问题需要解决容易达成一致意见。专门技术评估 可以是组织范围的,但是它们集中在专门的技术领域。例如,一个评估可能集中在组织怎样进行度量以确认项目的进展和质量方面。回页首大范围评估的标准让我们假定组织想要进行大范围评估而不是项目级或者专门技术评估。那么完成组织范围的软件开发能力评估的标准是什么?这种范围的评估需要一个组织和评估员的有意义的委托。例如,对于除了他们的软件开发能力之外没有稳定的理由的组织,可能是不值得进行评估的,因为获得评估结果的价值是很困难的。下面是一些
7、在你决定是否开始评估时需要考虑的:商业驱动 商业驱动是什么?它是成本节约?达到更高的质量?或者能够更快交付?它们的优先级如何?驱动是否强烈得足够有一个变更的委托?如果有的话,委托是否与组织水平对应?涉众 你的涉众是谁?确保你有不同的组织的观点。一个风险是你花费了太多的时间讨论拥护者-一个人的观点容易得到,但是谁也不可能有对所有位置的观点的描述。组织的状态 组织的状态是什么?它的成熟的和可接受的变更是什么?在讨论时有哪些失败出现?这些与软件开发能力有关(我们可以帮助),或者与其它事情相关?软件开发能力是否是组织的关键?是否有以前的成功的变更的例子或者改善的进展?价值机会 变更的价值看起来是什么?
8、项目平均有多大,它们一般运行多长时间,开发组织有多大?软件开发能力的改变如何影响商业结果?组织如何依赖它的软件开发能力?是否应该进行组织范围的评估依赖于几个标准。基于上面的描述,这里给出几个建议:应该有强烈的商业驱动和迫切的变更需求 - 其它的建议都不应该考虑,不值得做这样的评估。组织范围的评估应该领导变更。在评估时你需要在你的团队包括正确的人。你与这些人的关系应该是稳固的,与客户组织的关系也必须稳固。你应该给出评估的预算,它与任何考虑在开发工具上的全面投资相比都应该相当小。应该给组织的管理层一个远景,其中应该包括构建强有力的软件开发能力。组织应该通过创建管理层的领导变更的协作以展示承诺。回页
9、首什么是评估的价值?组织范围软件开发能力评估的主要目标是给被评估的团队提供价值。由外部人员进行的评估能够提供组织强项和弱项的外部的观点。它可以协助发现问题,基于最佳实践提供改进建议的先后次序。评估过程也将给关键人员提供一个阐述和讨论想法的机会,而他们以前没有时间充分地展示他们的想法。它在组织中构建对变更需求的理解。主要的一点是开发组织必须提供商业的价值。更好的软件开发将带来更好的商业结果。能力的评估意味着价值的改善。评估的结果将帮助激发对变更的投资,以及帮助构建变更的策略。最后,评估将作为阐述在组织中实现一个建议的解决方案的很好的基础,这个方案在评估期间完成需求的确定。涉众和结果因素有大量的因
10、素影响商业结果,但是软件开发能力评估仅仅集中在那些与软件或者系统开发活动有关的方面:换句话说,那些因素可以由IBM 和 IBM Rational 解决方案实现,并能够增加客户的商业价值。因为因素和期待的结果的数量通常很大,在评估的早期确定合适的涉众对评估结果的期望是很关键的。图 1 给出了客户端的涉众对商业结果的期望:图 1:评估过程的涉众正如图1中显示的,在一个视图中有很多不同的涉众对评估成果的看法:行政管理(Executive management) 关注与商业前景和商业策略,包括IT策略相关的结果。结果应该创建对于变更的紧迫需求,包括与商业驱动、角色定义、组织变更管理、风险管理、通信、和
11、投资回报等相关的看法。财务(Finance) 关注成本驱动、合同管理、价值链的费用、回报率、维护费用。供应商管理(Supplier management) 考虑 COTS使用,例如 B2B、子承包商管理和离岸开发的集成。生产制造(Production) 关注工业过程自动化,控制和质量。销售和市场(Sales and marketing) 关注用户关心的(如CRM - 客户关系管理),支持,在线服务,供应链集成,后勤,仓储和销售渠道。运作(Operations) 关注商业过程和性能,过程集成,自动化和系统支持,过程和工具支持,质量管理,和跨操作架构的内部关系。IT 关注组建策略,COTS,过程,
12、工具,重用, Enterprise Architecture Integration (EAI),采购策略,标准,技术,遗产,维护费用。开发人员(Developers) 关注更好的软件开发技能,动机,公司文化,创造性,职业发展,授权和团队凝聚力。产品管理(Product management) 关注通过产品策略产生收入,布置,包装,定价,技术,架构,质量约束,顺从标准,重用策略,质量图景,用户满意度,市场时机,细分,产品和操作的技术,覆盖的人群,创新管理。所有涉众关注的内容都是相关的,并且相互增强。他们在一个组织中给出不同的观点,并帮助评估组组织评估问题和答案。并不是所有的观点都能够在单一的软
13、件过程能力评估中展现出来,但是我们在规划这样一个评估时要牢记组织的架构。回页首能力评估框架在介绍评估路线图之前,我们首先讨论在评估活动中能够提供的指导框架:四个成功项目的协作领域 - 基于对不同的 engineering disciplines如何互相协作的调查简化的软件经济模型 - 例如,基于COCOMO II六个软件开发的最佳实践 - 基于对工程实践的调研最佳实践的框架在某种程度上通常更加适合于那些已经采用了IBM Rational Unified Process, RUP, 和Rational 技术的组织,否则你可能更加适合使用软件经济学模型或者四个实践领域。你也可以选择它们的组合。因为
14、最佳实践的框架与更多的技术相关,你可以使用那些开发者和项目经理已经很熟悉的Rational技术,在与高层管理者交流时使用软件经济学模型和四个实践领域。为什么我们没有提及 CMM/CMMI 作为框架之一? CMM/CMMI ,一般来说,集中在组织中过程是否被使用和改善的过程成熟度上 - 换句话说,这是一个开发组织的质量的标识,可以用来给它们的客户建立信任。我们这里讨论的评估更加集中在理解什么开发实践在使用,它们在哪里和怎样被改善以影响开发效果上。2四个协作领域如果评估在组织水平上进行,讨论的框架就集中在可以显著帮助的关键协作领域上。这种类型的框架支持一个好的开发基础架构,它推动跨开发项目所有领域
15、的协作。IBM Rational的Murray Cantor 和 Lynn Mueller 已经定义了这样一个框架,在本文中称为“四个协作领域”:工程,程序/项目管理,业务集成和开发供应商管理。这些协作领域都可以用在 IT应用开发,也可以用在产品开发。每个领域可以分为一系列的实践,我们评估每个实践意味着对组织成熟度的理解。每个实践的具体细节依赖于评估的开发组织的类型。工程讨论下面的实践可以让我们理解在产品/应用工程领域团队如何协作:采用面向对象的系统架构和UML 以获取逻辑和物理设计使用需求、设计、数据库模型,而不只使用文档使用通用的集成库保存系统工程产物和产品数据使用基于管理和专门领域(如硬
16、件,电子等)的设计工具程序/项目管理讨论管理实践提供对组织、计划、成功度量和结果如何监控和通讯的洞察:团队按照逻辑和物理组件划分,而不是功能单元系统架构组维护整个项目生命周期基于风险选择,降低完成费用的偏离组织使用基于能力的,use-case驱动的迭代开发有一个通用的、组织范围的集成的程序状态、稳定性、质量和财务的度量集合挣值依赖于可论证的结果,而不是费用花费有正在进行的系统和部件的集成测试业务集成大部分商业操作依赖于计算机系统,而评估组织考虑的范围和把系统开发作为集成的商业过程是至关重要的。理想情况下,系统开发应该反映组织的特性和商业策略 - 例如,开发能力(按时间和预算交付高质量的产品的能
17、力)应该考虑作为商业成功的关键因素。在这个协作领域,我们评估下列实践:保证所有商业管理过程映射到工程和管理实践使用通用的跨产品线的基础架构可以帮助优化操作环境(Service Oriented Architectures - SOA - 可以有效地优化商业过程到发布、集成和重用。它还可以帮助降低开发费用。)开发供应商管理在最后一个领域,我们评估供应商如何更有效地与项目生命周期集成,以及如何更有效地管理合同:与供应商的合同映射到项目管理过程和开发生命周期模型(而不是反过来)。使用共享的工程协作基础架构使用集成的管理基础架构上面描述的四个协作领域的每个的成熟度都可以描述为1到5级,如下所示:1 =
18、 No capabilities(无能力的)。 使用不同的方法和过程,几乎没有跨开发组织的集成2 = Aware(有意识的)。 现代开发过程已经在知道这些方法的价值的项目组单独使用3 = Capable(有能力的)。 现代开发过程已经在一些商业产品线的多个项目组使用,但是没有计划配置跨企业的集成过程4 = Mature(成熟的)。 企业已经开发了配置现代开发过程的计划,已经在选择的产品线上配置。5 = World Class(世界级的)。 企业已经在企业和它的供应商范围采用和配置了现代开发过程。结果可以表示为一个矩阵 (15 x 5),但是我们认为它更容易表示为一个可视化的radar char
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 开发 能力 评估
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【精****】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【精****】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。