PCon全球产品创新大会(北京站)来啦~了解最新日程 了解详情
写点什么

应用程序生命周期管理软件方案的评估指南

  • 2016 年 2 月 22 日
  • 本文字数:6537 字

    阅读完需:约 21 分钟

许多软件开发者在从事越来越复杂的产品开发工作时仍旧在使用一些单点的陈旧解决方案,这些方案往往并不是为了这种复杂度和产品而设计的,而采用一种应用程序生命周期管理(ALM)平台能够有效地为开发者提供帮助。许多公司与团队仍然依赖于一些陈旧的工具以追踪他们的开发流程,这使他们在试图跟上软件开发不断增长的步伐与复杂性时不得不面对更多的挑战。

越来越多的公司已经认识到 ALM 解决方案能够在协作、可追踪性、快速推向市场以及软件质量等方面带来诸多的益处。但是,各种软件商提供的 ALM 工具可谓不计其数,而你所选择的平台对于你的软件开发过程(以及公司的成功)将产生巨大的影响。因此,选择一种能够对你的当前以及未来的流程提供最佳的支持,并简化这种流程的 ALM 工具是至关重要的。本文旨在帮助你对于各种选择进行评估,并在购买 ALM 软件时帮助你做出合理的决策。

介绍

为了跟上不断扩大的市场的需求,软件开发者们如今所面对的软件方案的复杂性正在不断提高。InfoQ 的大多数读者们已经了解了这一点,其中有很大一部分或许还在这个问题上挣扎。而从传统的瀑布式模型向敏捷实践的转型也在不断地增长,对于读者中的大多数人而言这一点应该也并不陌生。

越来越多的软件开发公司开始意识到,依赖于不合适的陈旧工具以及大量的手工操作已经不可行了。像 MS Office(Word 与 Excel)、Bugzilla、Mantis 等工具依然普遍用于需求、问题、变更,乃至于整个开发流程的管理。而这些工具不仅功能上非常受限,并且必需进行大量的手工操作,才能够对各种交付品(源代码、测试用例等等)进行集成,以及生成能够表现出交付品的可追踪性的链接。

实际上,软件开发者所面对的普遍问题就包括流程的不清晰、流程管理的不合理、缺乏协作(或是不够自然)、以及为了确保可追踪性所必需的繁重的人为流程。这些问题对于那些安全至上的设备,例如用于汽车、医学以及航空产业中的设备中嵌入的软件的开发团队尤其明显。这些安全至上的市场建立了各种标准与规定,以实现完全的透明度以及无间隙的端到端可追踪性。因此,使用“旧式”的单点工具实际上是不可能完成这种开发任务的。

ALM 将拯救这一切

生产软件开发平台的软件商很早就认识到了这方面的需求,并推出了各种解决方案以应对这些挑战,这一切显得很自然。欢迎来到应用程序生命周期管理的世界,ALM 工具提供了形形色色的功能,使软件开发生命周期合理化,并且让这些复杂的流程变得更清晰。毫无疑问,各行各业对于 ALM 软件的采用率将不断上升,并且这种趋势在今后几年内还将继续。

应用程序生命周期管理工具的作用包括改进软件质量、降低成本、加快推向市场的速度、并通过清晰定义的工作流增进协作。它将使你在整个生命周期中对于交付品与流程有着全盘掌握。此外,高级的整合 ALM 解决方案还为报表的导出提供了简单的方式,对于之前所提到的那些高度关注安全性的产业来说,这种能力能够大大地促进在合规性方面的审计工作。

好,现在,对于你所面对的最迫切的困难来说,已经出现了一个解决方案(或至少能够为你带来很大的帮助)。那你是否应当马上冲到商店里,从货架上取走一份 ALM 平台工具,然后就坐在椅子上等着数钱呢?

事情是这样的:应用程序生命周期管理软件有着各种不同的类型与规模,在其中找到一个能够完美地适合你的流程的工具并不容易。为了迎合不断发展的市场需求,ALM 这一领域本身也在持续发展中,他们对于相同的问题可能会给出不同的答案,因此对 ALM 方案进行对比也是一件困难的任务。

如果以上这些观点不够有说服力,那么还有一点:你需要为将来做好准备。举例来说,你目前或许依赖于某种瀑布模型或 V 模型,但越来越多的软件开发公司正在、或即将转向敏捷流程。你所选择的 ALM 应当是不会过时的,它不仅能够支持你现有的流程,并且还要支持未来可预见的各种开发方面的变化。因此,完美的 ALM 平台应当足够灵活,以满足你不断变化的需求,它支持你现有的流程,而不是告诉你应该如何开展工作。

如何选择正确的 ALM 工具?

首先,也是最重要的一点是建立计划。如果你能够进行一些事前的思考,在寻找工具之前先找到你的优先事项与需求,就能够避免许多麻烦。虽然这一点听起来很简单,但你或许需要拓展一下思维。先暂缓一下,从一个客观的、外部的视角审视一下你的流程。以下这个检查清单将帮助你充分地为流程做好准备。

一旦你拟定了特定的需求之后,准备一份征求意见书(Request for Proposal - RFP) 是一个不错的点子,它是你选择 ALM 工具与软件商的第一个依据。请记住一点,你不需要一个人完成所有工作:ALM 的软件商将迫不及待地为你推销他们的商品,因此你的团队无需遍历整个市场,人为地选择各种可用的 ALM 平台。你应当利用好一个事实:你才是预算的持有者,放心地让软件商们去操心那些事吧。尽管如此,但 RFP 也是一把双刃剑:软件商将尽力表现出他们的优势,而对产品的劣势避而不谈。因此,你必须仔细地编写 RFP,以确保它完整地涵盖了所有需求。

策略、技术与业务需求

通常来说,你需要考虑三种类型的需求,这几种需求将以不同的程度影响你的决策。在决定了需求规格的优先级之后,不妨建立一种简单的打分系统,以评判这些 ALM 方案。你可以为每个特性或功能点给出 1 分至 10 分中的一个数值,这种方式可以让你方便地评估不同的软件平台的得分。

策略优先级

现有流程

虽然优秀的 ALM 方案能够帮助你对于流程进行改进与合理化,但你或许并不想一次性全部推倒重来。因此,理想的平台应该能够以灵活的方式进行配置,以适应现有的内部流程。并且在你能够预见的将来,它应当能够支持更高级的工作流。

现有的生态系统与集成

与现有的流程类似,有一些现有的工具是你想在新的方案中继续保留的,而你所选择的 ALM 平台应该能够与这些工具集成。此外,还要注意一点,你可能必须与其他团队、部门甚至是外部的合作伙伴进行交流,而他们可能会使用其他类型的工具,甚至是已过时的工具。

即使你在团队内部可能会使用新的 ALM 软件中包含的高级需求管理功能,但如果这些人依然在使用 MS Excel 进行需求的管理,那么你的 ALM 工具也必须能够处理.xls 文件。你与合作伙伴或承包商之间仍然需要交流需求方面的内容,因此在这一个例子中,对 Excel 的支持是必不可少的。

另一个要考虑的部分是:你所选择的解决方案是否本身就提供了与你使用的其他工具进行集成的功能,还是提供一些 API 以创建自定义的集成能力。

支持的方法学

正如之前所说,ALM 并不仅仅针对敏捷流程,许多现有的 ALM 产品同样支持瀑布式流程。即使是那些安全至上的产业也在越来越多地转向敏捷流程,你或许会考虑在将来的某一天替换现有的流程及方法学,以拥抱敏捷方法所带来的各种益处。有些开发团队在转换过程中会选择一种混合型的途径,以揉合敏捷与瀑布方法的各种实践。因此,如果你还不确定会采用哪种方法,那么最好的方式是找到一种能够同时支持这两种方法的 ALM 工具,使你能够采用混合型的转换途径。

特定于产业的解决方案及多生命周期的管理

你需要仔细地考虑一下是否需要一种特定于产业的解决方案。举例来说,对于从事高合规性产业,例如医学及汽车领域的开发者来说,他们能够从预配置的流程模板及仪表板等工具中受益良多,这将帮助他们在配置与合规性的审计过程中节省大量的时间。而提供这种解决方案的软件商也会在这些领域具备相当的知识,因此,如果这一点对你来说很重要,请确保在你的计分系统中反映这一点。

对于医学设备中的嵌入软件来说,他们对于风险管理方面的功能的需求比起做瑜珈应用的公司来说显然要更为迫切。不同的软件商对于开发流程中的风险管理提供了不同的解决方案(有一些软件商决定在 ALM 系统中完全忽略这一部分)。FMEA(失效模式和效果分析)、具体的风险跟踪、风险矩阵图、风险可跟踪性等等都是你需要注意的内容。

开发 IOT 产品的公司必须同时应对硬件、软件和服务的创新以及开发。不仅管理这些相互牵连的生命周期非常困难,它对于 ALM 软件商来说也是一个新的领域。因此,并非市场上所有解决方案都已为这种并行的生命周期管理的支持做好了准备。还是那句话,如果这一点适用于你的组织,请确保你已调查过所选择的方案如何支持并行的开发流。

技术规格

集成的架构

使用 ALM 的目的就是为了巩固对某个平台整个生命周期的管理。因此,你需要确保所选择的 ALM 方案支持开发过程中的各种流程。除了需求管理之外,软件开发与测试(及质量保障)的功能也是最基本的。最好还能够提供一些额外的功能,例如某些 ALM 工具能够提供强制需求管理模块、支持发布管理、DevOps,可能还会提供其他各类的特性。

有一点需要指出的是,这些功能不应仅仅把独立的模块简单地拼接在一起。你所需要的是一个集成的架构,它应使用一个单一的集中式 repository 以保存所有模块的数据。这能够帮助你确保数据在整个生命周期中的一致性,为参与这一生命周期的所有团队和团队成员提供一个单一的信任源。

可配置性、可灵活地自定义的交付品以及工作流

理想的 ALM 解决方案应当提供不同类型的预配置工作项,同时又允许你对交付品进行自定义。这样一来,你就能够对 ALM 进行调整,以符合自身的需求,在数据源与各种跟踪功能间进行区别,并将所有相关数据保存在你的工作项中。

同样的道理也适应于流程:举例来说,虽然对于需求建立一种预定义的批准流程是一件好事,但你的实际流程与 ALM 方案中所自带的模板往往并不匹配。提供一些默认的选项虽然是好事,但重要的是你选择的方案能够让你配置自身的工作流,并允许你强制应用他们(通过条件式逻辑及电子签名等等防卫性手段实现)。

可追踪性

可追踪性是对于 ALM 软件最基本的需求之一,无论你身处哪个行业,这一点都是必需的。它允许你创建整个生命周期中对于所有交付品(包括需求、任务、源代码、测试用例、发布、bug 等等)之间的链接,并且进行记录和浏览操作,以保证以下几点:

  • 每个需求都已经进行正确地实现(已开发了相应的特性,并进行了充分的测试)
  • 在已发布的软件中的每行代码都可以追溯到一个具体的需求,以解释代码的目的。

可追踪性对于软件的质量非常关键,对于安全至上的产业来说尤其重要,因为其标准和规定需要公司提供完整的、端到端的可追踪性。高级 ALM 方案所提供的集成性能够确保整个生命周期中无间隙的可追踪性。

需求管理

长话短说吧,充分的需求管理是成功的基本。因此,在你的 RFP 中最好为与需求相关的功能中专门列出一个重要的部分。

在决定你的选择之前应多比较几家不同的软件商,以了解他们所提供的功能,你可能尚未意识到某个具体的特性(例如对需求进行投票决定)对于你的实用性。如果你的 ALM 方案还能够在各种需求与其他交付品之间建立链接就更好了。如果能够与一些广泛使用的替代方案(例如 MS Word 与 Excel)进行双向集成,那么这种特性也能够促进提供者之间的协作。这种例子还包括对来自于某个库的需求进行保存与重用(例如你正在管理多个相似的产品)。

软件开发

一般来说,你的 ALM 方案应当提供源代码管理功能(通过 Git、Subversion、Mercurial 或任一种你使用的工具进行版本控制)、对于所有的工作项设立基准线的特性、以及变更及 repository 管理的特性。对于这一话题很难给出一般性的指南,因为它在很大程度上取决于你的特定内部流程。

QA 与测试

质量保证是另一个重要的课题。根据你的测试与 QA 流程的不同,你可能需要进行自动化测试、可重用的测试用例、参数化的测试、测试覆盖率分析以及其他一些相关的特性。还是那句话,确保你已经对内部的流程进行分析,并在 RFP 中对你的需求进行详细地描述。

协作式的任务、项目以及团队管理

你的 ALM 方案应当能够处理不同的项目,在每个项目中各自设立团队与成员,并且能够为每个团队成员分配任务。每个任务应当能够和发布进行关联,这种方式能够让你的团队中的每位成员对于项目的进展有一定程度的(视觉上的)理解。而一个可自定义的看板板对于促进任务管理也能够起到一定作用。

有些 ALM 中还可以实现更多的协作特性,例如留言、可触发的通知(内置的通知系统或 email 通知)、对某些工作项进行投票与评分、或是 ALM 中的在线聊天功能等等。有些软件商还提供了某种形式的服务台特性,以帮助你管理与客户之间的交流,并支持问题的管理(例如客户提交的 bug、变更需求等等)。

文档与报表

在开发过程中所发生的每件事都应当进行日志或文档记录,而文档更容易导出为易用的格式。它在审计阶段能够起到很大的作用,如果你的终端产品(及流程)需要符合业界的规定或标准,那么你就需要证明你的合规性。

自定义的指标与报表应该是可配置的,最好能够以一种对用户友好的仪表板的方式加以呈现。仪表板能够帮助你监督整个开发流程,以及各种指标和可视化的数据,例如预计时间与花费时间、燃尽图等等。

业务需求

托管选择

软件商通常会为他们的方案提供本地或 SaaS(云托管)的版本,有时还将同时提供两种选择。你需要对基础设施及环境进行分析,以确定哪种选择更适合你。此外,你还应考虑是否需要追加对基础设施的投入(例如一台全新的服务器),因为必要的硬件升级对于你的 ALM 平台的价格将是一次不菲的开销。公司的安全政策、防火墙、伸缩性需求,以及分散于各地的团队(影响服务器的响应时间)种种因素都将影响你的决策,你需要在最终采购之前进行认真思考。

支持、培训与顾问

无论整个流程看上去多么漫长、多么复杂,购买一个 ALM 方案也只是万里长征的第一步而已。你首先要将这个方案与你的开发环境进行集成,并在使用之前对所有的流程与工作流等内容进行配置。应确保选择的软件商能够提供部署与顾问服务(最好是上门服务),以简化整个流程。

你还需要为你的团队进行培训,以帮助他们认识 ALM 的真正价值,因此在你为这个平台所确定的最终价格中,也应当包括初步的培训价格。此外,软件商也应当提供顾问服务的选择,帮助你充分利用新版本中更多的特性,并解决来自团队所提交的各种问题。如果软件商还能够定期地提供网上教学以帮助你利用 ALM 的特性,那是再好不过了。

总体拥有成本及可选的许可计划

最后,你需要记住这一切的目的都是为了增进效率。最起码,你所使用的 ALM 工具应当帮助你提高生产力,并改进团队或组织的整体盈利能力。成本并非最重要的因素,请记住,如果你选择了一种不理想的方案,那从长远来看,它的成本将会高得多(降低的效率、浪费的时间与精力)。

此外,在许可价格之外可能还存在顾问、培训、支持和其他成本,因此计算总体拥有成本(TCO)十分重要。基本上,这一过程将持续 2 到 6 年时间,然后总结这段期间内可预见的与 ALM 相关的开销。正如某个有经验的销售人员所说:“不要关注价格,而是关注成本。”

ALM 工具通常会提供多种不同的许可选择。有些软件商会提供针对性的许可(仅限几个特定的用户)或是不固定的许可,即可以由多个用户使用,但同一时间只有一个人可以使用。还有一种选择是“租用”解决方案(对许可、升级、支持等交付年费),而不是购买永久性的许可以及独立的支持服务(在这种场合下,你永久地买下了这个软件,但需要为其他服务交付年费)。此外,对于某些模块、特性或权限来说,可能还存在各种不同的许可类型。在理想的情况下,软件商将帮助你确定需求,对于你需要的许可类型的最佳组合提供一个具有竞争力的价格。

实现 ALM 解决方案

总的来说,对于 ALM 解决方案的评估与采购是向前迈出的一大步,因此不可轻率待之。你需要全面地考虑以上所述的内容,以及你可能会产生的额外需求,然后再开始落实选择适合的应用程序生命周期管理平台的过程。

不过,正如 ALM 实施的快速发展所表现出的趋势,它的益处将远远超过所付出的成本,前提是你选择了正确的软件方案。审慎的挑选所付出的时间与精力将得到适当的回报。我们的最后一个建议是:别忘了还价!也许你选择的方案还有各种折扣,但软件商显然不会提醒你注意这些条款。

关于作者

Kristof Horvath是来自于 Intland Software 的一位应用程序生命周期管理传教士,他也是 codeBeamer 的开发者,这是一个综合的、一体化的、端到端的整体 ALM 方案。Kristof 经常在博客中发表关于生命周期管理、敏捷方法和 IoT 产品开发的文章。欢迎通过他的电子邮件 kristof.horvath@intland.com 与他取得联系。

查看英文原文: An Evaluation Guide to Application Lifecycle Management Software Solutions

2016 年 2 月 22 日 17:10
用户头像

发布了 428 篇内容, 共 156.3 次阅读, 收获喜欢 27 次。

关注

评论

发布
暂无评论
发现更多内容

第六周 技术选型 作业一

应鹏

极客大学架构师训练营

框架设计原则

笨笨程序猿

架构设计 极客大学架构师训练营 接口隔离

架构师训练营第 1 期 - 第 6 周 - 学习总结

wgl

架构师训练营第 1 期第 6 周总结

du tiezheng

极客大学架构师训练营

第 5 周 这东西也有标准化答案???

Pyr0man1ac

第六周课后总结

天天向上

极客大学架构师训练营

MULE 无法接收TCP报文问题分析

东风微鸣

APM

架构师训练营 1 期第 6 周:技术选型(二) - 作业

灵霄

极客大学架构师训练营

week2学习总结

幸福小子

Week 2 :框架设计(作业一)

shuyaxx

第六周总结

【架构师训练营第 1 期 06 周】 学习总结

Bear

极客大学架构师训练营

架构师训练营 - 第六周作业

一个节点

极客大学架构师训练营

架构师训练营第二期 - 第二周课后练习

xiaomao

算法训练营第二期:第二周总结

xiaomao

week6

张兵

极客大学架构师训练营

架构师训练营第六周命题作业

一马行千里

极客大学架构师训练营 命题作业

1.请简述 CAP 原理。

张荣召

第六周作业

碎碎念

大头虾

6.1分布式关系数据库(上)

张荣召

与前端训练营的日子--Week01

SamGo

学习

Week2作业

幸福小子

架构师训练营第 2 期 第二周总结

月下独酌

依赖倒置原则、接口隔离原则优化类的设计

CJian

极客大学架构师训练营

架构师训练营第二周学习总结

张小胖

极客大学架构师训练营

第六周作业

熊桂平

极客大学架构师训练营

第六周 技术选型 学习总结

应鹏

学习 极客大学架构师训练营

技术选型(2)课后作业

ABS

第六周总结

_

极客大学架构师训练营 第六周总结

11/1-第二周-作业

张冬冬

学习

TDSQL前沿技术进展和趋势——数据异常基础理论研究

TDSQL前沿技术进展和趋势——数据异常基础理论研究

应用程序生命周期管理软件方案的评估指南-InfoQ