Файл: Инфрам.pdf

125 бюджета и в срок, требует постоянной координации большого количе- ства действий между многочисленными специалистами. За последние
15 лет разработка программных продуктов стала полноценной индуст- рией, в ней нет места для недокументированного, сугубо индивидуаль- ного подхода, поэтому закономерно, что заметной тенденцией стало появление методологии управления жизненным циклом приложений
[23]. Безусловно в процессе разработки программного обеспечения най- дется место искусству талантливых программистов, и профессиональ- ному мастерству других участников процессов создания программного продукта, однако сегодня стало ключевым осознание того факта, что в этой деятельности нет места для бессвязности, недокументированности и диктата индивида. Одной из наиболее заметных тенденций первого десятилетия этого века в индустрии создания программных систем ста- ло появление ALM (Application Lifecycle Management, ALM) – управле- ния жизненным циклом приложений [23].
Такой подход должен привнести в разработку дисциплину управле- ния, рассматривая создание программного продукта как бизнес-процесс и учитывая его циклический характер. В соответствии с идеей ALM работа над любым программным решением не заканчивается на этапе его ввода в эксплуатацию: система модернизируется и совершенствует- ся, выходят ее новые версии, что инициирует каждый раз очередной виток жизненного цикла приложения.
Аналитики Forrester Research сравнивают ALM c ERP для программ- ной индустрии, правда, история ALM гораздо короче и не может пока похвастаться сравнимым списком успешных внедрений. Аналитики признают, что, несмотря на объективную необходимость в подобных решениях, средства ALM пока находят ограниченное применение, а их рынок по-прежнему фрагментирован. Обозреватели рынка считают, что ни одно из существующих на сегодняшний день предложений в области
ALM не реализует в полной мере все потенциальные преимущества и возможности средств автоматизации управления жизненным циклом приложений. Однако развитие разработки в сторону управляемых, предсказуемых, эффективных процессов создания надежного и качест- венного ПО не может не сопровождаться появлением соответствующих платформ автоматизации этих процессов.
Производители решений ALM предоставляют различные средства и технологии для поддержки процесса разработки ПО. Эти средства вы- ходят далеко за рамки традиционных инструментов для повышения производительности отдельного разработчика. Они направлены на пре- доставление методик и инструментов, ориентированных на коллектив- ную работу по созданию ПО. Чтобы создать жизнеспособное решение для ALM, производители должны учитывать потребности "расширен- ной" группы разработчиков ПО и включать в свои продукты роли, кото- рые участвуют в более широком процессе.
Эксперт в области ИТ Дэвид Чеппел предостерегает от упрощенного взгляда на ALM, которое часто отождествляют лишь с жизненным цик- лом разработки программного обеспечения (Software Development

126
LifeCycle, SDLC): инициация, итеративный цикл разработки, выпуск релиза продукта и внедрение. Дисциплина ALM охватывает более ши- рокий круг задач, рассматривая все аспекты существования такого кор- поративного ресурса, как приложения. По определению Чеппела, жиз- ненный цикл приложения включает в себя все этапы, на которых орга- низация так или иначе вкладывает средства в этот ресурс, от исходной идеи программного решения до утилизации отслужившего свой срок
ПО [15].
Предельно детализируют это определение в HP – по версии компа- нии, цикл SDLC составляет лишь один из этапов полноценной модели
ALM – этап доставки приложения (рис. 3.14), а кроме него есть еще планирование, эксплуатация и вывод из эксплуатации. Цикл замкнут – до момента, когда организация приходит к окончательному выводу о ненужности приложения, оно продолжает совершенствоваться. Грамот- ная реализация ALM направлена в том числе на то, чтобы продлить срок эффективной работы программного решения и, как следствие, обеспечить сокращение затрат на покупку или создание принципиально новых программных продуктов.
Рис. 3.14. Модель ALM
Чеппел развертывает картину жизненного цикла в линейную (рис.
3.15), выделяя три основные области ALM – руководство (governance), разработка (development) и эксплуатация (operations). Соответствующие этим областям процессы протекают, перекрываясь, от зарождения идеи нового приложения или модернизации существующего к этапу его раз- вертывания до полного завершения функционирования.

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

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

129 управления изменениями, прогнозировать их влияние на ИТ-среду и бизнес в целом, сформировать систему метрик качества, продуктивно- сти и рисков разработки, отслеживать и анализировать эти метрики на протяжении всего жизненного цикла и, в конечном итоге, обеспечить реальное соответствие создаваемых приложений задачам бизнеса.
Изначально одними из немногих новаторов, которые поняли важ- ность 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% признались, что пока еще только присматриваются к скорым мето-

130 дам, все же остальные применяют их в той или иной степени, причем
39% считают свои реализации вполне зрелыми [15].
Разработчики применяют скорые методы и передают продукт в экс- плуатацию, которая не учитывает реалии «скорой» разработки, что соз- дает серьезные препятствия для скорости реакции работающих прило- жений на изменения требований бизнеса и, как следствие, гибкости
(agility) самого бизнеса. Невозможность или нежелание операционного персонала реагировать на изменения прикладной среды, вносимые раз- работчиками, часто связаны с недостатками документации, которая пе- редается с этапа на этап, не отражая ключевых зависимостей между компонентами выпускаемого программного релиза, и, более глобально, с отсутствием надежного и автоматизированного канала связи между разработчиками и операционным персоналом. Эта проблема только усу- губляется с распространением современных средств автоматизации управления ЦОД и новых подходов к реализации ИТ-инфраструктур, включая облака. Предельно автоматизированные и рассчитанные на максимально быстрое развертывание приложений, такие среды не смо- гут реагировать на изменения при отсутствии автоматизированного ка- нала передачи информации и без реализации сквозных процессов между этапами разработки и эксплуатации.
Осознание остроты проблемы и тенденция поиска средств ее реше- ния даже породили новый термин DevOps, для обозначения концепций и технологий улучшения взаимодействия между разработкой и эксплуа- тацией. Основные надежды на реализацию этих идей аналитики возла- гают на ALM-среды нового поколения, которые на деле, а не в теории, обеспечат интеграцию ключевых этапов жизненного цикла приложений.
Создаваемые приложения сегодня во многих случаях композитны и ин- тегрируют на сервисных принципах компоненты, реализованные на разных языках программирования для разных платформ, а также код внешних систем и унаследованные решения. Для управления их жиз- ненным циклом среда ALM должна поддерживать различные среды разработки и платформы выполнения (например,. NET и J2EE), а также обеспечивать возможность контроля исходного кода, лицензирования и статуса разработки внешних компонентов приложения.
Среди признаков широкой адаптации agile-процессов аналитики от- мечают отход организаций от ортодоксальности в отношении этих ме- тодов. Разработчики не боятся сочетаний разных процессов, если это позволяет им оптимизировать работу над новыми системами, поэтому среда ALM 2.0 должна поддерживать различные процессы и методики в области разработки, управления портфелями и обеспечения качества продукта. Последнее особенно важно – автоматизация сквозных про- цессов управления качеством, от определения требований до тестирова- ния и эксплуатации, может стать одной из наиболее сильных сторон комплексной платформы ALM.
Линейка продуктов Rational для поддержки различных этапов жиз- ненного цикла ПО всегда выделялась широтой и фокусом на интегриро- ванность модулей между собой. Аналитики Butler Group оценили ком-