Управление жизненным циклом приложений

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

Безусловно, в процессе разработки программного обеспечения найдется место искусству талантливых программистов и профессиональному мастерству других участников процессов создания программного продукта, однако сегодня стало ключевым осознание того факта, что в этой деятельности нет места для бессвязности, недокументированности и диктата индивида. Одной из наиболее заметных тенденций первого десятилетия этого века в индустрии создания программных систем стало появление ALM (Application Lifecycle Management, ALM) - управления жизненным циклом приложений [23].

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

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

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

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

Предельно детализируют это определение в НР - по версии компании, цикл составляет лишь один из этапов полноценной модели

АЬМ - этап доставки приложения (рис. 3.14), а кроме него есть еще планирование, эксплуатация и вывод из эксплуатации [15]. Цикл замкнут: до момента, когда организация приходит к окончательному выводу о ненужности приложения, оно продолжает совершенствоваться. Грамотная реализация АЬМ направлена в том числе на то, чтобы продлить срок эффективной работы программного решения и, как следствие, обеспечить сокращение затрат на покупку или создание принципиально новых программных продуктов.

Анализ потребностей бизнеса

Приоритетность и инвестиции

Уор4дленне ШШДоиШ „Мониторинг программ

Совершенствование

Планирование

Руководящие решения

Исправление

ошибок

Мониторинг

настройка

Эксплу

атация

Полный

жизненный ЦИКЛ приложения

Практики

Соответствие

требованиям

Повторное

ислопкюванис

Инициация

терации разработки

Доставка

Вывод из экс плуатации

Выпуск

недрение

Рис. 3.14. Модель ALM

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

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

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

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

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

В расширенный список ролей участников процессов ALM и выполняемых ими задач, которые должны поддерживаться соответствующим инструментарием, входят:

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

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

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

Изначально одними из немногих новаторов, которые поняли важность ALM и изменили свои стратегии выпуска продуктов в сторону явной ее поддержки, были Borland и IBM Rational. Отреагировав на очевидные возможности, к победившей концепции ALM примкнули и другие компании: Microsoft, Telelogic, Mercury, Serena, Compuware, CollabNet и Mercury [15]. Сегодня ALM - это установившаяся тенденция и растущая индустрия, признанная аналитиками. Производители решений ALM предоставляют различные средства и технологии для поддержки процесса разработки ПО. Эти средства выходят далеко за рамки традиционных инструментов для повышения производительности отдельного разработчика. Они направлены на предоставление методик и инструментов, ориентированных на коллективную работу по созданию ПО. Чтобы создать жизнеспособное решение для ALM, производители должны учитывать потребности расширенной группы разработчиков ПО и включать в свои продукты роли, которые участвуют в более широком процессе.

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

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

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

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

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

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

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

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

Project and Team Structure

ll

u

Search

Event Notification

Jazz Team Server

Defects

Requirements Items and relationships IlJ Event history,

^Use'^cases...... Item history trends

.....Builds Source code. Test-cases Test results

Jazz Repository

Conversation

Rational

ClearCase

r

W L - " - t

Rational

ClearQuest

Process

Enactment

Security and Access

Рис. 3.15. Интегрированная корпоративная платформа управления жизненным циклом приложений

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

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

Платформа Jazz обеспечивает интеграцию со средой разработки Eclipse, предоставляя ряд представлений и проекций. Некоторыми компонентами Jazz поддерживаются также веб-клиенты. Платформой Jazz предоставляются два значимых представления для Eclipse: Team Central и Team Artifacts. Оба представления служат для сбора информации и могут дополняться компонентами платформы Jazz. Разработки Eclipse, некоторые компоненты платформы Jazz позволяют пользователям обращаться к серверу Jazz непосредственно из веб-обозревателя [26].

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

Из наиболее ярких новинок в семействе Rational, созданных специально для работы на базе Jazz, - система Rational Team Conceit (RTC), представляющая собой комплекс продуктов для организации совместной работы и автоматизации процессов жизненного цикла ПО, полностью построенный в архитектуре Jazz. IBM Rational Team Concert является полноценной средой, предназначенной для организации разработки информационных систем в мультипроектном окружении, в котором уча-сгвует множество разработчиков. Инструмент позволяет объединить усилия специалистов в области разработки, организовать их эффективное взаимодействие и сохранить высочайший уровень контроля над всей проектной деятельностью на всем протяжении проекта [19].

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

Широкие возможности в области интеграции IBM Rational Team Concert делают данный инструмент абсолютно уникальным. Среди существующих интеграций следует отметить следующее.

• 1. Интеграцию с IBM Rational Requirements Composer в рамках совместной разработки приложений (Collaborative application lifecycle management, или CALM), которая позволяет связывать рабочие задания с требованиями, порожденными или измененными на основе этих заданий, и наоборот, требования с заданиями, созданными для планирования работ по реализации данных требований.
• 2. Интеграцию с IBM Rational Quality Manager в рамках совместной разработки приложений (Collaborative application lifecycle management), на основе чего становится возможным организовать дефект-трекинг по результатам выполненных тестов в ходе тестирования выпускаемых программных продуктов.
• 3. Интеграцию с IBM Rational ClearQuest для синхронизации рабочих заданий и запросов на изменения, определенных в классическом средстве управления разработкой IBM Rational ClearQuest.
• 4. Интеграцию с IBM Rational ClearCase для синхронизации артефактов версионного и конфигурационного управления между двумя указанными средствами.

Открытая архитектура Jazz Integration Architecture, лежащая в основе IBM Rational Team Concert, позволяет вести дополнительную разработку новых механизмов интеграции с другими системами, которые могут быть развернуты и активно использоваться в организации. Одним из вариантов интеграции с данными системами может являться использование продукта RTC Email Reader от компании «Финэко Софт», который обеспечивает синхронизацию рабочих заданий IBM Rational Team Concert в соответствии с email-сообщениями предопределенного формата. При этом возможна и обратная синхронизация благодаря встроенной подсистеме оповещений IBM Rational Team Concert.

Надо также отметить, что управление версиями и конфигурациями на базе IBM Rational Team Concert может быть организовано практически в любом проекте, даже если среда разработки (IDE) не имеет непосредственной интеграции с этим инструментом. Это становится возможным благодаря совместному использованию «толстого клиента» IBM Rational Team Concert и неинтегрируемого IDE. Так, если для Eclipse IDE, IBM Rational Software Architect, IBM Rational Application Developer и Microsoft Visual Studio такие интеграции существуют, то уже, например, с Delphi придется дополнительно использовать «толстый клиент» IBM Rational Team Conceit, что не представляет больших трудностей.