В процессе разработки программного обеспечения найдется место и искусству талантливых программистов, и качественному ремеслу других участников процессов создания программного продукта, однако сегодня ключевым стало осознание того факта, что в этой деятельности нет места для бессвязности, недокументированности и диктата индивида. Под знаком осознания важности перехода разработки ПО на индустриальные рельсы прошло все первое десятилетие этого века, и не случайно одной из наиболее заметных тенденций этого периода стало появление ALM.

Управление жизненным циклом приложений (Application Lifecycle Management, ALM) позволяет привнести в разработку дисциплину управления, рассматривая создание программного продукта как бизнес-процесс и учитывая его циклический характер. Работа над любым программным решением не заканчивается на этапе его ввода в эксплуатацию: система модернизируется и совершенствуется, выходят ее новые версии, что инициирует каждый раз очередной виток жизненного цикла приложения.

Аналитики Forrester Research сравнивают ALM c ERP для программной индустрии, правда, история ALM гораздо короче и не может пока похвастаться сравнимым списком успешных внедрений. Аналитики признают, что, несмотря на объективную необходимость в подобных решениях, средства ALM пока находят ограниченное применение, а их рынок по-прежнему фрагментирован. Обозреватели рынка считают, что ни одно из существующих на сегодняшний день предложений в области ALM не реализует в полной мере все потенциальные преимущества и возможности средств автоматизации управления жизненным циклом приложений. Однако развитие разработки в сторону управляемых, предсказуемых, эффективных процессов создания надежного и качественного ПО не может не сопровождаться появлением соответствующих платформ автоматизации этих процессов.

 

Азы ALM

Эксперт в области ИТ Дэвид Чеппел предостерегает от упрощенного взгляда на ALM, которое часто отождествляют лишь с жизненным циклом разработки программного обеспечения (Software Development LifeCycle, SDLC): инициация, итеративный цикл разработки, выпуск релиза продукта и внедрение. Дисциплина ALM охватывает более широкий круг задач, рассматривая все аспекты существования такого корпоративного ресурса, как приложения. По определению Чеппела, жизненный цикл приложения включает в себя все этапы, на которых организация так или иначе вкладывает средства в этот ресурс, от исходной идеи программного решения до утилизации отслужившего свой срок ПО.

Предельно детализируют это определение в HP – по версии компании, цикл SDLC составляет лишь один из этапов полноценной модели ALM – этап доставки приложения (рис. 1), а кроме него есть еще планирование, эксплуатация и вывод из эксплуатации. Цикл замкнут — до момента, когда организация приходит к окончательному выводу о ненужности приложения, оно продолжает совершенствоваться. Грамотная реализация ALM направлена в том числе на то, чтобы продлить срок эффективной работы программного решения и, как следствие, обеспечить сокращение затрат на покупку или создание принципиально новых программных продуктов.

Рис. 1. Жизненный цикл приложения

Чеппел развертывает картину жизненного цикла в линейную (рис. 2), выделяя три основные области ALM – руководство (governance), разработка (development) и эксплуатация (operations). Соответствующие этим областям процессы протекают, перекрываясь, от зарождения идеи нового приложения или модернизации существующего к этапу его развертывания до полного завершения функционирования.

Рис. 2. Три области ALM

Руководство в ALM реализуется на протяжении всего жизненного цикла приложения и включает в себя все процессы и процедуры, которые относятся к принятию решений и управлению проектом. Главная задача здесь – обеспечение соответствия приложения тем или иным целям бизнеса, что определяет значимость этого компонента ALM. К процессам руководства Чеппел относит: разработку детального инвестиционного предложения ("бизнес-кейс"), содержащего анализ затрат, выгод и рисков, связанных с будущим приложением, которое предшествует стадии разработки; управление разработкой с помощью методов и средств управления проектами и портфелями (Project Portfolio Management, PPM); управление работающим приложением в рамках управления портфелем приложений предприятия (Application Portfolio Management, APM).

Разработка приложения происходит между моментом возникновения идеи и развертыванием готового решения. Процессы разработки реализуются также после развертывания при появлении необходимости в модернизации приложения или выпуске новых версий. Разработка включает в себя определение требований, проектирование, кодирование и тестирование, причем все эти процессы, как правило, реализуются в несколько итераций.

К эксплуатации относятся процессы мониторинга и управления работающим приложением, которые планируются и стартуют незадолго до окончания разработки и продолжаются до утилизации. Включение в жизненный цикл ПО эксплуатационных процессов является ключевым моментом – именно разрозненность команд разработчиков и операционного персонала считается одной из самых острых проблем корпоративных приложений, а их интеграция с помощью ALM обещает серьезное повышение эффективности использования программного обеспечения бизнеса. Беда лишь в том, что в ALM-средах такая интеграция пока остается благой целью, а не реальным воплощением.

Описанная общая картина ALM на практике трансформируется в необходимость планирования и автоматизации множества этапов жизненного цикла ПО. Идеальная среда ALM позволяет интегрировать всех участников жизненного цикла приложения, обеспечить им согласованный доступ к соответствующим ресурсам и задачам и при этом понимать контекст работы каждой отдельной роли, предоставляя ее исполнителям нужные инструменты. В расширенный список ролей участников процессов ALM и выполняемых ими задач, которые должны поддерживаться соответствующим инструментарием, входят:

  • топ-менеджеры – управляют портфелями проектов и с помощью инструментальных панелей контролируют ключевые метрики жизненного цикла ПО, включая риски и качество продукта;
  • менеджеры проектов – планируют и контролируют выполнение проекта, анализируют возможные риски и отвечают за распределение ресурсов;
  • аналитики – осуществляют взаимодействие с бизнес-пользователями, определяют требования к программному продукту, управляют требованиями и их изменениями на протяжении всего проекта;
  • архитекторы – моделируют архитектуру программной системы, включая ее функциональные компоненты, данные и процессы;
  • разработчики – пишут код, используя интегрированные среды разработки и различные инструменты обеспечения качества ПО на этапе кодирования;
  • инженеры отдела качества – создают и управляют тестами, выполняют функциональное, регрессионное тестирование, тестирование производительности, в том числе с помощью средств автоматизированного тестирования;
  • операционный персонал – выполняет мониторинг и управление приложением и осуществляет обратную связь с командой разработки по поводу возникающих проблем;
  • бизнес-пользователи – с помощью специализированных средств получают возможность формулировать требования, сообщать о дефектах приложения и отслеживать статус вносимых изменений.

Единая программная среда ALM призвана обеспечить инструменты для совместной работы и руководства процессами на базе управления конфигурациями и изменениями и контроля версий ПО. В целом внедрение подходов и инструментов ALM позволяет сформировать стандартные процессы создания и эксплуатации приложений, контролировать соответствие им во всех проектах, реализовать строгий процесс управления изменениями, прогнозировать их влияние на ИТ-среду и бизнес в целом, сформировать систему метрик качества, продуктивности и рисков разработки, отслеживать и анализировать эти метрики на протяжении всего жизненного цикла и, в конечном итоге, обеспечить реальное соответствие создаваемых приложений задачам бизнеса.

 

ALM 2.0

Аналитики Butler Group считают, что концепция ALM получила признание в середине завершившегося десятилетия, хотя первые программные решения этого класса начали появляться раньше. В 2002 году компания Borland, один из наиболее активных пропагандистов идей ALM, расширила свой портфель, ориентированный только на разработчиков, инструментами для других ролей в процессах жизненного цикла ПО. Еще одним пионером ALM была компания Rational Software, ставшая частью IBM. К первопроходцам рынка затем присоединились и другие производители, в том числе Microsoft, Telelogic, Mercury, Serena, Compuware и CollabNet.

Общим недостатком первых ALM-систем была слабая интеграция модулей для разных этапов жизненного цикла, как в рамках платформы одного производителя, так и, тем более, решений разных поставщиков. Не имея возможности использовать комплексную ALM-платформу, заказчики собирали ее из разрозненных частей, что в результате вынуждало их реализовывать сквозное управление процессами жизненного цикла вручную, тем самым нивелируя основное потенциальное преимущество автоматизации ALM. Поэтому в качестве главного направления совершенствования сред ALM четыре года назад аналитики Forrester прогнозировали появление интегрированных платформ ALM 2.0, которые бы предоставляли общие сервисы средствам поддержки разных ролей в жизненном цикле, использовали единый физический или виртуальный репозиторий артефактов разработки, управляли микро- и макропроцессами жизненного цикла, обеспечивали интеграцию в единую среду инструментария для разных ролей, поддерживали сквозные возможности отчетности для разных этапов жизненного цикла.

Действительно, отчасти прогнозы сбылись — основной вектор развития рынка ALM сегодня направлен именно в сторону создания комплексных платформ, что соответствует и настроению пользователей. Однако аналитики Forrester сдержанны в оценках текущей ситуации на рынке ALM, считая, что пока ни один из производителей не достиг идеальной реализации платформы ALM 2.0, а переход пользователей к комплексным средам ALM сдерживается опасениями необходимости серьезных изменений процессов создания приложений, сложностями реализации масштабных программных платформ и связанными с этим большими затратами. А более экономичной реализации гетерогенной среды ALM мешает отсутствие стандартов интеграции инструментов для разных этапов жизненного цикла, таких, например, которые вводили бы единую схему данных для сбора информации по ключевым метрикам процессов жизненного цикла или позволяли бы оркестровать сквозные процессы разработки, охватывающие локальные подпроцессы, автоматизированные на уровне инструментария для различных этапов ALM.

Сегодня возникают новые требования к ALM, и определяющую роль в этом играет широкое распространение «скорых» (agile) методов разработки. Когда около четырех лет назад создатель одной из наиболее известных скорых методик Scrum Джефф Сазерленд заявил о грядущей тотальной адаптации идей скорой разработки, это казалось преувеличением, но прогноз оказался верным – по данным совместного исследования аналитиков Capgemini Group и подразделения HP Software&Solutions, в 2010 году свыше 60% компаний уже используют или планируют использовать разработку в стиле agile, а среди участников опроса Forrester лишь 6% признались, что пока еще только присматриваются к скорым методам, все же остальные применяют их в той или иной степени, причем 39% считают свои реализации вполне зрелыми.

Несмотря на распространенное, но поверхностное представление об agile-процессах как о свободном, слабо детерминированном, не связанном строгими правилами стиле разработки, скорые методы требуют дисциплины, выполнения большого количества строгих правил и при этом достаточно сложны в реализации по сравнению, например, с традиционным «водопадным» методом. Сложность связана не только с ускорением процессов разработки и тестирования и необходимостью поиска баланса между скоростью и качеством, минимальным документированием и эффективной отчетностью, но и с серьезными изменениями в организации взаимодействия команды создателей продукта с бизнес-заказчиками, которые также активно вовлекаются в процесс. Это повышает востребованность ALM и одновременно создает для такой платформы новые задачи. Как отмечают в Forrester, построенные на коротких итерациях, каждая из которых решает ограниченный круг задач, но приводит к созданию готового решения, скорые методы опираются на принципы управления задачами для организации, планирования и контроля управления работ в команде. Соответственно, управление задачами для скорой разработки становится универсальным механизмом для интеграции между собой требований, сборок продукта, тестов и изменений, в то время как в традиционных подходах ALM для этого используются сложные взаимозависимости между артефактами разработки.

Получение на каждой итерации готового продукта в скором процессе и реализация принципа непрерывной интеграции предъявляют особые требования к автоматизации процессов управления сборками и тестирования ПО. В скорых процессах также особое внимание уделяется управлению проектом, принципы которого применяются от итерации к итерации, а также интеграции соответствующих инструментов в среду ALM, что реализовано далеко не всеми поставщиками решений этого класса. Акцент на совместную работу требует от ALM 2.0 поддержки более современных, но менее формализованных возможностей сотрудничества всех участников жизненного цикла, смещая внимание со строгих процессов документирования на всех стадиях на взаимодействие с помощью вики-ресурсов и выявление неявных знаний в командном общении.

Еще одна важная тенденция, способная оказать решающее влияние на развитие современных ALM-платформ, – все возрастающая необходимость в интеграции этапов разработки и эксплуатации приложения. Хотя мы определили этап эксплуатации как неотъемлемую часть ALM, на деле эксплуатация и разработка в большинстве организаций существуют отдельно. Различия действительно глубоки и имеют как культурно-организационные, так и технологические корни. Разработчики видят свою миссию в создании новых возможностей для бизнеса, и изменения в коде составляют суть их деятельности. Разработчики нацелены на выпуск готового программного релиза к определенному сроку, тестируя его в более простой по сравнению с реальной среде, подчас слабо отражающей фактические условия эксплуатации. Ключевые метрики, определяющие процесс разработки, фокусируются на реализации определенной функциональности, минимизации ошибок и завершении процесса разработки в заданный срок. С другой стороны, миссия операционного персонала – это нормальная работа приложений, обеспечение необходимой им производительности и безопасности, гарантирующих работоспособность бизнеса. Любое развертывание новой функциональности или модернизация существующих решений несет в себе угрозу непредсказуемых изменений в эксплуатационной среде, чреватой серьезными рисками.

Разработчики применяют скорые методы и передают продукт в эксплуатацию, которая не учитывает реалии «скорой» разработки, что создает серьезные препятствия для скорости реакции работающих приложений на изменения требований бизнеса и, как следствие, гибкости (agility) самого бизнеса. Невозможность или нежелание операционного персонала реагировать на изменения прикладной среды, вносимые разработчиками, часто связаны с недостатками документации, которая передается с этапа на этап, не отражая ключевых зависимостей между компонентами выпускаемого программного релиза, и, более глобально, с отсутствием надежного и автоматизированного канала связи между разработчиками и операционным персоналом. Эта проблема только усугубляется с распространением современных средств автоматизации управления ЦОД и новых подходов к реализации ИТ-инфраструктур, включая облака. Предельно автоматизированные и рассчитанные на максимально быстрое развертывание приложений, такие среды не смогут реагировать на изменения при отсутствии автоматизированного канала передачи информации и без реализации сквозных процессов между этапами разработки и эксплуатации.

Осознание остроты проблемы и тенденция поиска средств ее решения даже породили новый термин DevOps, для обозначения концепций и технологий улучшения взаимодействия между разработкой и эксплуатацией. Основные надежды на реализацию этих идей аналитики возлагают на ALM-среды нового поколения, которые на деле, а не в теории, обеспечат интеграцию ключевых этапов жизненного цикла приложений. Создаваемые приложения сегодня во многих случаях композитны и интегрируют на сервисных принципах компоненты, реализованные на разных языках программирования для разных платформ, а также код внешних систем и унаследованные решения. Для управления их жизненным циклом среда ALM должна поддерживать различные среды разработки и платформы выполнения (например,. NET и J2EE), а также обеспечивать возможность контроля исходного кода, лицензирования и статуса разработки внешних компонентов приложения.

Среди признаков широкой адаптации agile-процессов аналитики отмечают отход организаций от ортодоксальности в отношении этих методов. Разработчики не боятся сочетаний разных процессов, если это позволяет им оптимизировать работу над новыми системами, поэтому среда ALM 2.0 должна поддерживать различные процессы и методики в области разработки, управления портфелями и обеспечения качества продукта. Последнее особенно важно – автоматизация сквозных процессов управления качеством, от определения требований до тестирования и эксплуатации, может стать одной из наиболее сильных сторон комплексной платформы ALM.

 

Jazz, Visual Studio, ALM 11 и другие

Линейка продуктов Rational для поддержки различных этапов жизненного цикла ПО всегда выделялась широтой и фокусом на интегрированность модулей между собой. Аналитики Butler Group оценили комплекс решений IBM Rational Software and Systems Delivery как наиболее полный из представленных на рынке по спектру реализованных компонентов ALM. Этот комплекс включает в себя продукты для управления портфелями проектов, проектирования и разработки на базе моделей, управления требованиями, управления конфигурациями и изменениями, управления качеством, управления сборками и релизами, оркестровки процессов жизненного цикла ПО и обеспечения отчетности и документации по этим процессам. Слово Systems в названии появилось после приобретения компании Telelogic, решения которой ориентированы на поддержку процессов системной инженерии и теперь интегрированы в портфель Rational. Их включение в ALM-среду IBM отражает тенденцию сближения процессов разработки ПО и систем и формирования для них единой среды управления жизненным циклом.

Но наиболее существенным вкладом компании IBM в развитие технологий ALM является долгосрочный проект Jazz по созданию серверной инфраструктуры для реализации интегрированной корпоративной платформы управления жизненным циклом приложений. На данный момент целый ряд продуктов семейства Rational уже интегрированы с платформой Jazz, выпущено несколько новых решений, изначально созданных для работы на базе Jazz, и в перспективе будет обеспечена поддержка инфраструктуры Jazz во всех компонентах линейки Rational.

Ядром Jazz является платформа Jazz Foundation, объединяющая сервер Jazz Team Server и ряд дополнительных модулей интеграции. Jazz Team Server демонстрирует новый для ALM подход к интеграции компонентов для разных этапов жизненного цикла (рис. 3). Если традиционно такая интеграция базировалась на точечной связи между отдельными продуктами, то в Jazz реализована открытая распределенная сервисная архитектура на базе стандарта REST, которая обеспечивает простое взаимодействие инструментальных компонентов между собой (своего рода ALM Web). Интерфейс RESTful позволяет представлять в виде сервисов данные и функциональность разнообразных модулей. Использование подхода на базе стандартов Web обеспечивает хорошую масштабируемость Jazz, делая платформу универсальным решением, способным поддерживать задачи ALM в небольших командах и в крупных коллективах разработчиков.

Рис. 3. Архитектура платформы Jazz

Jazz Foundation предоставляет общие для всех компонентов ALM сервисы, позволяющие реализовать ключевые возможности современной среды управления жизненным циклом приложений. Это, например, сервисы совместной работы, обеспечивающие взаимодействие различных участников команды в процессе решения общих задач, поддерживающие взаимосвязи между разными этапами жизненного цикла и при этом учитывающие контекст каждой конкретной роли в ALM. Инструменты сотрудничества на базе Jazz используют средства мгновенных сообщений, средства организации длительных обсуждений, механизмы вики и другие популярные возможности Web 2.0. При этом все взаимодействия между членами команды рассматриваются как проектные ресурсы, которые хранятся в связи с теми артефактами, которые послужили источником этих взаимодействий (например, дефектами или тестовыми примерами).

Сервисы Jazz Foundation также позволяют определять и выполнять процессы в соответствии с различными методиками, включая Rational Unified Process и разные варианты скорой разработки. Для этого предоставляются средства нотификации о событиях, поддержка связи членов команды в выполнении определенных потоков работ, задание и проверка выполнения правил, автоматизация базовых задач, организация потоков работ с использованием инструментария для разных этапов жизненного цикла. Большое внимание уделяется обеспечению прозрачности процессов жизненного цикла и руководству процессами, для чего вводятся точные процессные метрики по статусу, проблемам и рискам проекта и предоставляются инструментальные панели для их отслеживания, в том числе в реальном времени, на различных уровнях, от отдельных участников процессов до команды и уровня управления портфелями. Среди других сервисов Jazz Foundation можно отметить поисковые механизмы, средства безопасности, ролевой доступ, распределенный репозиторий для всех ресурсов разработки.

Из наиболее ярких новинок в семействе Rational, созданных специально для работы на базе Jazz, – система Rational Team Concert (RTC), представляющая собой комплекс продуктов для организации совместной работы и автоматизации процессов жизненного цикла ПО, полностью построенный в архитектуре Jazz. Система RTC реализует управление конфигурациями ПО, управление задачами и сборками, а также планирование итераций и отчетность по проекту, обеспечивает определение различных типов процессов разработки и интегрируется с другими продуктами Rational для поддержки полного жизненного цикла ПО. В 2009 году IBM также выпустила Rational Quality Manager – портал для управления тестированием на базе Jazz – и инструмент управления эффективностью Rational Insight, реализованный для платформы Jazz с использованием аналитических технологий Cognos и предназначенный для задач высокоуровневого управления портфелями проектов разработки.

Кроме того, в IBM уже несколько лет работают над разрушением «берлинской стены» между разработкой и эксплуатацией, интегрируя решения семейства Rational с продуктами для управления ИТ-инфраструктурой семейства Tivoli.

Стоит также отметить, что IBM инициировала разработку стандарта Open Services for Lifecycle Collaboration (OSLC), призванного обеспечить совместимость продуктов автоматизации различных этапов ALM от разных производителей. OSLC задуман как совокупность общих форматов и протоколов для определения различных ресурсов ALM, таких как требования, тестовые примеры и др., а также организации взаимодействия между модулями на базе стандартов Web. Инициатива, без сомнения, представляет собой благое начинание для обеспечения пользователям возможности без особых усилий строить гетерогенные среды ALM. Однако аналитики Forrester отмечают, что OSLC без энтузиазма воспринимается индустрией — готовые спецификации используют преимущественно сама IBM как базу для реализации инфраструктуры Jazz.

Обозреватели рынка замечают, что одним из признаков роста значимости ALM является интерес Microsoft к этой области. Возможности командной разработки и интеграции разных этапов жизненного цикла приложений компания начала реализовывать еще пять лет назад в модуле Team System платформы Visual Studio 2005. В версии Visual Studio 2010 функциональность ALM была сильно расширена. Центром поддержки управления жизненным циклом приложений на платформе Visual Studio является система Team Foundation Server (TFS), которая предоставляет репозиторий контроля версий, базу данных управления тестовыми сценариями, средство отслеживания задач, шаблоны для определения различных процессов разработки, механизм управления метриками проекта и средства автоматической сборки проектов и отчетности на базе SQL Server Reporting Services.

Как отметил один из создателей платформы, вице-президент Microsoft по технологиям Брайан Харри, в новой версии TFS был реализован комплекс улучшений в средствах управления проектом, среди которых поддержка иерархии задач, настраиваемые типы связей для более эффективного контроля выполнения работ, автоматическая конфигурация Scrum, более широкие возможности использования портала SharePоint для отчетности и реализации инструментальных панелей, усовершенствования в системе контроля версий. Кроме того, для TFS сделано «обратное» масштабирование – если изначально система была ориентирована на крупные корпоративные команды, то новую версию могут использовать и небольшие группы разработчиков.

В Visual Studio 2010 также усовершенствована поддержка определенных ролей ALM, в частности, добавлены новые инструменты архитектора. Многое сделано для более эффективного управления тестированием, в том числе реализован специальный модуль Visual Studio Lab Management 2010 и улучшены средства взаимодействия между тестировщиками и разработчиками. Visual Studio интегрирует модули для отдельных ролей ALM между собой и с сервером TFS. Однако некоторые роли по-прежнему не включены в ALM-среду на базе Visual Studio 2010, в частности, бизнес-аналитики не найдут здесь специальных инструментов для управления требованиями.

Если платформа IBM Jazz поддерживает в качестве клиентов интегрированные среды разработки Eclipse и Visual Studio для платформ Java и. NET соответственно, то ALM-среда Microsoft ориентировалась преимущественно на разработчиков. NET, однако очень часто в компаниях соседствуют разные среды разработки, и популярность открытой Java-среды Eclipse достаточно высока. Чтобы не ограничивать пользователей возможностями разработки только на собственной платформе, в Microsoft приобрели активы компании SourceGear, связанные с инструментами разработки Teamprise, которые поддерживают использование Eclipse на базе ОС Unix, Linux и Mac OS X.

Активным игроком на поле ALM показала себя компания HP, сделав упор на управление качеством разрабатываемого продукта на всех этапах ALM, а также на тесную интеграцию этапов разработки и эксплуатации. Реализовать эти идеи на практике HP позволяет обширный портфель продуктов в области управления проектами (Project and Portfolio Management Center) и обеспечения качества ПО (Quality Center и различные решения для автоматизации тестирования) и их интеграция с комплексами решений по управлению ИТ-сервисами, автоматизации управления ЦОД и управления сервисными архитектурами. Специальный продукт Agile Accelerator предназначен для автоматического конфигурирования, настройки различных элементов и управления проектами скорой разработки.

У HP нет собственного инструментария разработки, поэтому в своей ALM-стратегии компания делает ставку на интеграцию, поддерживая Microsoft Visual Studio, Eclipse, а также систему управления процессами разработки в распределенных командах TeamForge компании CollabNet. В конце 2010 года HP сделала следующий шаг к реализации полностью интегрированной среды ALM, представив платформу ALM 11, объединившую новые версии существующих и ряд новых продуктов компании для управления жизненным циклом ПО.

Не очень ясной остается судьба ALM-решений компании Borland, которая, как и IBM, была одной из создателей этого рынка — еще пять лет назад в портфеле компании был обширный набор продуктов, включающий не только популярные средства разработки на разных платформах и языках программирования, но и решения для других этапов жизненного цикла ПО. В 2007 году Borland анонсировала стратегию OpenALM по созданию платформы управления жизненным циклом, позволяющей интегрировать на базе общих сервисов как свои продукты, так инструментарий внешних производителей. Однако традиционный для Borland бизнес инструментария разработки был продан, а совсем недавно сама компания вошла в состав Micro Focus, которая стала обладателем большого портфеля решений в области ALM, включая инструментарий управления качеством, приобретенный у компании Compuware, — правда, стратегия его интеграции и развития пока четко не определена.

Для полноты картины стоит также отметить, что на рынке появляются ALM-решения, предоставляемые по модели SaaS, например, компаниями Atlassian и ThoughtWorks, а также ведется интересный проект с открытым кодом Mylyn по созданию ALM-среды, ориентированный на разработчиков, использующих IDE Eclipse.