软件应用生命周期平台应具有的特点

techexcel123 2010-04-19 10:58:15

相对于ERP(Enterprise Resource Planning)和CRM(Customer Relationship Management)而言,软件应用生命周期(ALM: Application Lifecycle Management)是比较新的概念。过去几年间,这方面的研究日新月异,相关的讨论也逐渐热烈。本篇文章主要是和大家分享,笔者在过去十几年,对于ALM行业演进的亲身感受;并分享在挑选ALM工具时所应关注的几个产品特点;希望达到抛砖引玉的效果。

1995年我在美国从事IT工作时,曾以咨询师的身份加入一个几十人的研发团队。当时Jeff是我们的项目经理,所做的项目是用来给汽车厂维修汽车时,做报修估价用的。刚加入团队的时候,我问Jeff:“这个项目什么时候可以完成?”Jeff回答的很自信:“一年半的时间,你就可以看到这个至今为止全国独一无二的产品推向市场。”很快一年半的时间过去了,我看着团队人数由最初的15人增加到45人,但项目并没有完工的迹象。我又问Jeff:“产品要推向市场了吗?”Jeff回答:“项目完成的时间很难估算的。大概还需要半年时间吧!”但是半年过去了,项目还是没法发布。紧接着又过了一年,Jeff宣布说:“产品新功能在开发期间不断增加,以至于很难把握项目的进度。但竞争对手的产品也快完成了,我们不能再等了,只有强行把产品先推向市场了。”由于产品发布完成,不久后,我便离开了该团队。

市场不断地反馈对该产品的新功能需求,该公司在一年后,重新找到我,希望我为产品添加新功能。该团队人员因我早年参与了项目的设计,问了我一些跟产品历史有关的问题。我说:“当年我们写的某设计文档可以回答这些问题,Tom应该有这文档。”当我去跟Tom要这文档时,他说,该文档当时被交接给John了。John却说,Dianna后来对文档做了修改,且放进团队的服务器了。但我们几人不论如何,都找不到那文档了。那文档就这样消失了!

我第三次再回到该公司时做的是该产品的维护工作。产品经理告诉我:“虽然该产品是最早推进市场的,但现在全美的市场占有率,却排在另两个竞争对手之后。主要原因是两个竞争对手的市场嗅觉灵敏,他们总是能比我们更先知道什么新功能是客户最需要的。而我们只能在别人的产品发布后,才匆匆忙忙地把新功能抄袭到我们的系统里。”我问他:“为何我们没能先发现市场所要的新功能?”他答道:“修车厂的管理人员,由于和客户打交道最多,得到的信息也最真实,是最早嗅到市场所要新功能的一批人。他们通常会打电话把需求告诉我们。但需求的数量成千上万,我们很难判断哪个重要哪个不重要。而且,由于接电话的人专业能力不足,写下的需求往往失真,也很凌乱。需求反馈的周期也因此被拉长”我听了后建议该产品经理,专门设计一个网站,用来收集和分析客户的需求。可以让修车厂的管理人员,客户和项目组的成员都参与到网站的信息反馈,帮助项目组了解客户最需要的新功能。该经理欣然地接受了我的建议。但这么晚才做此调整,可能已没法挽回局面了。

上面我所经历的故事,其实在90年代,是一个普遍现象。即便是在美国这样IT高度发展的国家,人们对研发过程管理也是没有任何概念的。市场上一般的工具就是编译器、开发平台和自动测试工具。因为没有研发过程管理工具,项目常常到最后失控。1995年,The Standish Group调查了全球352家软件组织的8000多个软件项目。调查结果表明:31%的项目在完成前被取消,浪费800多亿美元;53%的项目消耗了189%的预估成本,平均时间是原始估算值的222%。只有16%的小企业和9%的大企业按时交付了软件产品。

软件业经过了这十几年,软件应用生命周期管理的领域已发生了巨大的变化。过去这些年,软件的大小呈级数增加。现在一个项目团队有上百人已不是很稀奇的事。随着项目的变大,一个团队对其人力资源、文档、代码,乃至于经费、时间等等的管理,必需借助一套科学且具体的方法。而对这些因素的管理,若要到位,则必需借助使用恰当的工具。正因为这一系列的变化,使得需求管理、项目跟踪或发布管理之类的管理工具在90年代开始被一个个地推到市场。到现在各种工具已算相当全备了。我以为,若要选一套合适的应用生命周期的管理工具,一定要注意它是否具备下列特点:

** 整合的系统(Integrated System) – 现今针对软件应用生命周期中各个阶段的工作管理,虽然可选的管理工具颇多,但它们多半是由不同的公司开发出来,且是各自独立的。这至少造成了以下两个问题。第一,各阶段的数据不能被共享。举例来说,同样的需求会在需求管理工具中记录,又同时需要出现在缺陷跟踪工具里。若要把这些数据要从一个工具拷贝到另一个工具,不但在时间上有延迟,同时在费用上也会增加,而且发生错误的可能性也变大。第二,项目执行的流程无法被固化。由于工具是各自独立的,工具间的流程自然是没法被固化的。如果我们能够找到一套整合的系统,这些问题势必迎刃而解。不但解决了软件应用生命周期中各个阶段工作的管理,而且也解决了阶段性数据的共享。

** 项目的透明度(Visibility)要高 – 由于项目包含了庞大的数据,参与者往往都在雾里。对于关键的数据,看似存在,却无从提取。就如前面故事里的项目经理Jeff,他无法对项目的成本、所需人力以及时间等等进行合理的估算。由于缺乏真实的数据支撑,公司决策层对项目的投资报酬率不清楚,对整体策略步履蹒跚。其他如缺陷修复现状、缺陷率、任务完成时间估算和任务现状等都是项目里提高透明度的一些指标。这些年被敏捷团队所津津乐道的任务时间估算方式是以Burndown Chart来实现的。Burndown Chart通常以时间为横轴,以未完成的工作为纵轴。它显示随时间推移,项目中还剩下多少工作未完成。从而帮助项目管理层掌控项目的执行进展。

** 可追溯性(Traceability)要高 – 理想上,项目成员在生命周期管理系统中,可将相关的文档(包括需求及参考资料等)、测试用例及代码等建立链接,并有办法从其中的任意一个节点,追溯到其他的相关条目。如果生命周期管理系统的各个子系统不是整合的,那这种追溯事实上是不可能完善的。在上头的故事里,Tom、 John和Dianna把重要的设计文档丢失了,就是因为只是单纯的将文档放在服务器上,而没有保存到管理系统中管理,造成无法追溯。在实际的项目执行中,最常发生的例子可能是,研发人员要修复某个缺陷,他常常需要找出原本的设计文档及其他相关缺陷的修复状况。知道了来龙去脉后,他便可以很准确地完成他的工作。

**自动化(Automation)程度要高 – 在项目的执行过程中,很多机械性的工作是可以经由软件系统自动触发的。最常见的例子是,当经理在工作流程中把某研发任务交给某个研发工程师时,一个电子邮件(或短信)就应该自动地邮寄到该工程师信箱(或手机)里。另一个例子是,某个项目要由10个委员在2周内评估完。在2周截止日前3天,系统也可以发个电子邮件通知提醒委员们“只剩3天了”。如提前评估完了,相关人员应该收到电子邮件通知,以便安排下一步工作。若过了截止日期,而评估仍旧未完成,系统也可以发电子邮件,并列出未完成评估的人员。通过引入自动化的机制,势必降低了项目的人力管理成本,同时也提高了项目的执行效率。

除了这些特点外,还有两件事值得一提的。第一,数据的量化和分析是整个平台的基础。比如说,一个项目里有上千个各式各样的需求,我们如何界定哪个该做?哪个不该做?优先顺序又是如何?一个可行的办法是,将这些需求划分到可能的几个方案里,由相关人员投票决定要选哪个方案。在被选上的方案中,各个需求的优先次序再被界定出来;达到项目方案的分析量化。其它可以被量化的至少还包括人力资源管理、变更管理、缺陷管理等等。

另有一个值得一提的新概念是Wiki在需求管理上的应用。Wiki的基本理念是参与者可以自由地浏览、创建、更改文档。这使得团队协作更加快捷流畅。但一般的Wiki工具并没有权限控制。在实际的项目操作上,这可能会造成颇为严重的问题。我知道有几个研发团队曾试图采用免费的Wiki工具来编写需求文档。但经过实践,他们放弃了。主要的原因是,Wiki工具并不能和团队使用的其他管理工具互通,还有就是权限控制的问题。但不论如何,我相信商用的Wiki工具将会被大量的使用,也会成为ALM管理工具里的需求管理的重要部份。

现今不论是国内还是国外,ALM管理工具还是处于早期发展阶段,供应商也在摸索着找出市场能接受的路子。大致上看来,最早接受此类管理工具的团队有以下几类:(1)敏捷团队- 敏捷方法是以快速接受(需求)变更著称的。但过快过多的变更也可能导致项目失控。而且,敏捷团队一般以7到10人为佳。当团队人数多于这上限时,沟通开始不易通畅,敏捷的种种优点也必淡然无存。使用ALM管理工具来追踪变更,并提供一个团队成员间沟通的平台,可以显著地减少这些问题。 (2)以过程为中心(Process-centric)的团队 – 对过程的控制极为严谨的团队,诸如制药厂和航天电子设备,依赖工具来保证其过程没有偏差。(3)分布式团队 – 如果项目的需求、测试及编码是由在不同地域的人共同来完成的,那他们之间的沟通和协调也是需要有个平台。因此,对ALM管理工具的需求也就大了。(4)嵌入式系统的研发团队 – 这类团队同时要处理软件和硬件的研发。典型的嵌入式团队可能有设计、软件研发、软件测试、硬件研发和硬件测试等小组。小组多了后,它们之间的协调和沟通的复杂度呈级数增加,因此也需要有个沟通和协调的平台。

很可能,未来ALM管理工具的发展依旧会围绕这四类客户的基本需求。但有一点我们是知道的:随着客户要求的不断提高,未来在项目管理中引入ALM管理工具的角色将不仅仅是战术性的,更可能提升成战略性的。这意味着,当工具里累积了足够的项目,它的数据将成为企业的智囊库,可作为后续项目在周期、成本、人力及风险管理等方面的重要参考。有前瞻性的公司会用分析结果(如投资回报率)来决定项目的优先次序,并找出公司未来的市场方向。

原文链接:http://www.techexcel.com.cn/newsevents/relatedarticles/20100419.html



...全文
262 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复
什么是软件?它具有哪些区别于硬件的特点? 软件是一系列按照特定顺序组织的计算机数据和指令的集合。软件并不只是包括可以在计算机上的运行的计算机程序,与这些计算机程序相关的文档也被认为是软件的一部分。软件就是程序加文档的集合体。 软件是一种逻辑产品,与硬件产品有本质的区别。硬件是看得见、摸得着的物理部件或设备。软件产品是以程序加文档的形式存在,通过在计算机上运行来体现他的作用。电脑软件分为系统软件和用软件,系统软件和硬件一起提供一个"平台",它们管理和优化电脑资源的用。 2.详细说明"软件生存周期"的概念 软件生存周期(SDLC,软件生命周期)是软件的产生直到报废的生命周期,周期内有问题定义、可行性分析、总体描述、系统设计、编码、调试和测试、验收与运行、维护升级到废弃等阶段,这种按时间分程的思想方法是软件工程中的一种思想原则,即、逐步推进,每个阶段都要有定义、工作、审查、形成文档以供交流或备查,以提高软件的质量。 什么是软件危机?产生原因和主要体现是什么?如何解决? 软件危机:落后的软件生产方式无法满足迅速增长的计算机软件需求,从而导致软件开发与维护过程中出现一系列严重问题的现象。 原

5,177

社区成员

发帖
与我相关
我的任务
社区描述
软件工程/管理 质量管理/软件测试
功能测试压力测试安全性测试 个人社区 湖南省·长沙市
社区管理员
  • 软件测试
  • 虫无涯
  • 小博测试成长之路
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

欢迎大家加入到软件测试的社区,在这里,希望大家勇于发表自己的看法,欢迎大家分享自己在软件测试工作过程中遇到的问题以及工作经验分享。

1.想转行的小伙伴,遇到问题没有及时回复的,可以私聊小博进行反馈

2.大家对社区有好的建议,都可以在社区发帖进行反馈

推荐大家学习的软件测试入门笔记:软件测试入门学习笔记

试试用AI创作助手写篇文章吧