ALM - Application Lifecycle Management - Управление жизненным циклом приложений. Понятие методологии управления жизненным циклом приложений - ALM (Application Lifecycle Management)

И т.д..

«Управление жизненным циклом» сводится к необходимости освоения привычных для системной инженерии практик:

• управление информацией («нужная информация должна быть у нужных заинтересованных сторон вовремя, и в доступной для её использования форме»),
• управление конфигурацией («проектная информация должна соответствовать требованиям, информация «как построено» должна соответствовать проекту, в том числе проектным обоснованиям, физическая система должна соответствовать информации «как построено», а разные части проекта при этом должны соответствовать друг другу», иногда часть этой практики назвают «управление изменениями »).

СУЖЦ vs PLM

По-новому сформулированная СУЖЦ не использует PLM как обязательный класс программных средств, вокруг которого такая система строится. В крупных инженерных проектах обычно используется сразу несколько (чаще всего существенно "недоосвоенных") PLM разных вендоров, и при создании СУЖЦ речь идёт обычно уже об их межорганизационной интеграции. Конечно, при этом решаются и вопросы, как интегрировать в СУЖЦ информацию и тех систем, которые еще не имеют связи с какой-то из PLM систем расширенного предприятия. Термином «расширенное предприятие» (extended enterprise) обычно называют созданную посредством системы контрактов организацию из ресурсов (людей, инструментов, материалов) участвующих в конкретном инженерном проекте различных юридических лиц. В расширенных предприятиях ответ на вопрос, в какую именно PLM интегрируются данные какой именно из систем CAD /CAM /ERP /EAM /CRM /и т.д.. становится нетривиальным: владельцам разных предприятий не предпишешь использовать программные средства одного поставщика.

А поскольку PLM-система всё-таки являтся программными средствами, а "система управления" из СУЖЦ явно понимается в том числе как "система менеджмента", то термин СУЖЦ подразумевает явно и организационный аспект, а не только аспект информационных технологий. Тем самым фраза "использование PLM для поддержки системы управления жизненным циклом" вполне осмыслена, хотя может запутывать при дословном переводе в ней “PLM” на русский.

Тем не менее, понимание "системы управления жизненным циклом", когда ею занимаются специалисты из IT-служб, немедленно нивелируется назад к "только софту", подозрительно напоминающему программные средства PLM. И после этого переупрощения начинаются трудности: «коробочная» система PLM от какого-то поставщика программных средств автоматизации проектирования обычно сразу представляется конструктивно, как набор программных модулей из каталога этого поставщика, вне связи с поддерживаемыми инженерными и менеджмерскими функциями, и рассматривается как тройка из следующих компонент:

• датацентрический репозиторий данных жизненного цикла,
• «система документооборота» (workflow engine) для поддержки «управления»,
• «портал» для просмотра содержимого репозитория и состояния документооборота.

Назначение СУЖЦ

Главное назначение: СУЖЦ обнаруживают и предотвращают коллизии , неизбежные при коллаборативной разработке. Все остальные функции СУЖЦ являются производными, поддерживающими эту главную функцию.

Главная идея любой современной СУЖЦ - это использование аккуратного и непротиворечивого представления системы и окружающего её мира в неизбежно разнородных и изначально несовместимых между собой компьютерных системах расширенной организации. Использование виртуальных макетов, информационных моделей, датацентрических репозиториев проектной информации обеспечивает выявление коллизий при "сооружении в компьютере", "виртуальной сборке", а не при выносе чертежей и других моделей проекта в материальную реальность в ходе действительного сооружения «в металле и бетоне» и пуска в эксплуатацию.

Идея СУЖЦ не имеет тем самым отношения к разнообразным «автоматизациям проектирования», прежде всего – к «порождающему проектированию » (generative design) и «порождающему производству » (generative manufacturing). СУЖЦ озабочена более не синтезом, а анализом: обнаруживает и/или предотвращает коллизии в результатах проектирования отдельных подсистем, когда их будут собирать вместе по самым разным технологиям:

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

Моделеориентированный подход

Использование СУЖЦ подразумевает отказ не только от бумаги в проектировании, но и от "электронной бумаги" (.tiff или других растровых форматов) и переход к датацентрическому представлению информации. Сравнить две модели, существующие на бумаге в каких-то нотациях и найти в них несоответствия много сложнее и дольше, нежели предотвращать коллизии в структурированных электронных документах, использующих не растровую графику, а инженерные модели данных.

Модель данных может быть разработана в соответствии с каким-то языком, например:

• в терминах стандарта описания метода разработки ISO 24744),
• метамодель (в терминах консорциума стандартизации OMG),
• модель данных/справочные данные (в терминах стандарта интеграции данных жизненного цикла ISO 15926).

Именно такой переход к структурно представляемым моделям, существующим уже на ранних стадиях проектирования и называется «Системной инженерией на основе моделей » (MBSE, model-based systems engineering). Снимать коллизии при помощи компьютерной обработки данных становится возможным уже на самых ранних стадиях жизненного цикла, еще до появления полноценных 3D моделей конструкции.

СУЖЦ должна:

• обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое – причем в электронном структурированном виде, а не в виде «пачки электронной бумаги». Передача данных из одной инженерной информационной системы (с четким пониманием откуда, куда, когда, что, зачем, как) - это часть обеспечиваемой СУЖЦ функциональности. Тем самым СУЖЦ должна поддерживать workflow (ход работ, который частично выполняется людьми, а частично компьютерными системами).
• контролировать версии , то есть предоставлять функцию управления конфигурацией - как моделей, так и физических частей системы. СУЖЦ поддерживает таксономию требований разного уровня и предоставляет средства для проверки коллизии разноуровневых проектных решений и их обоснований с этими требованиями. В ходе инженерной разработки любое описание системы, любая её модель изменяются и дополняются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна гарантировать, что для текущей работы используется только правильное сочетание этих версий.

Архитектура СУЖЦ

Архитектурных решений для СУЖЦ может быть множество, одна и та же функция может быть поддержана различными конструкциями и механизмами работы. Можно выделить три вида архитектуры:

1. Традиционные попытки создать СУЖЦ – это обеспечить важнейшие передачи данных по принципу "точка-точка" между разными приложениями. При этом может быть использована какая-нибудь специализированная система поддержки workflow (BPM engine, «движок управления бизнес-процессами»), или система обработки событий (complex event processing engine). К сожалению, объем работы по обеспечению обменов «точка-точка» оказывается просто грандиозным: каждый раз требуются специалисты, разобравшиеся в обоих связываемых системах и методе передаче информации.
2. Использование стандарта интеграции данных ЖЦ ISO 15926 по методу «ISO 15926 outside», когда для каждого инженерного приложения разрабатывается адаптор в нейтральное представление, соответствующее стандарту. Тем самым, все данные получают возможность встретиться в каком-то приложении и коллизия между ними может быть обнаружена – но для приложения требуется разработать лишь один адаптер передачи данных, а не несколько таких адаптеров (по числу других приложений, с которыми нужно обеспечить связь).
3. PLM (Teamcenter, ENOVIA, SPF, NET Platform и т.д.) - используется стандартизованная архитектура, за тем лишь исключением, что используемая в каждой из этих PLM модель данных менее универсальна в плане отражения любой предметной области инжиниринга, а также не является нейтральным и доступным всем форматом. Так что использование ISO 15926 в качестве базового представления при передаче данных в СУЖЦ можно считать дальнейшим развитием идей, по факту реализованных в современных PLM.

По архитектуре управления конфигурацией , СУЖЦ можно разделить на три вида:

• «репозиторий» (актуальное хранение всех данных проекта в одном репозитории СУЖЦ, куда копируются данные оттуда, где они были разработаны),
• «регистр» (СУЖЦ поддерживает список адресов данных жизненного цикла в многочисленных репозиториях других САПР , систем инженерного моделирования, PLM , ERP и т.д.),
• «гибридная архитектура» -- когда часть данных копируется в центральный репозиторий СУЖЦ, а часть данных доступна из других мест по ссылкам.

Архитектора СУЖЦ должна также описывать:

• «портал» (в том числе «веб-портал»), его функциях и способ реализации. Само наличие портала позволяет успокоить топ-менеджеров демонстрируя отсутствие коллизий. К архитектурным решениям по «порталу СУЖЦ» предъявляются специфические требования.
• алгоритмы проверки целостности/непротиворечивости данных жизненного цикла, а также описание работы этих алгоритмов:
  • стандартный модуль в отдельном приложении, работающий над данными в репозитории этого приложения – будь это САПР или PLM ;
  • специально разработанное для СУЖЦ программное средство проверки коллизий, имеющее доступ к данным разных приложений, находящихся в центральном репозитории СУЖЦ;
  • специально разработанное программное средство, обращающееся через интернет по защищенному каналу к разным хранилищам данных , находящимся в разных организациях;
  • специально запрограммированные проверки с контролем коллизий при загрузке разных инженерных наборов данных в центральный репозиторий СУЖЦ;
  • комбинация из всех перечисленных методов – разных для разных типов коллизий; и т.д.
• способ взаимодействия пользователей СУЖЦ (инженеров-проектантов, закупщиков, монтажников, менеджеров проекта сооружения и т.д.), и как именно программное обеспечение СУЖЦ поддерживает это взаимодействие способом, предотвращающим появление коллизий. Стандарты системной инженерии (в частности, стандарт практик системной инженерии ISO 15288) требуют выбора вида жизненного цикла для инженерии сложных объектов и указания того, какие варианты практик системной инженерии будут использованы. Модель жизненного цикла является одним из основных артефактов, которые служат для организационных договоренностей по координации работ расширенной организации инженерного проекта. Скоординированные работы в ходе коллаборативной разработки (collaborative engineering) – это залог малого числа проектных коллизий. Как именно поддержит модель жизненного цикла СУЖЦ? Так, системы PLM обычно не находят место моделям жизненного цикла, и уж тем более моделям организации. Поэтому для СУЖЦ нужно искать другие решения по программной поддержке этих моделей.
• Организационный аспект перехода к использованию СУЖЦ . Переход к использованию СУЖЦ может вызвать существенное изменение в структуре и даже кадровом составе инжиниринговой компании: не всех землекопов берут в экскаваторщики, не всех извозчиков берут в таксисты.

Главное для СУЖЦ – насколько предлагаемое решение способствует раннему обнаружению, а то и предотвращению коллизий. Ежели речь заходит о чём-то другом (содержательный выбор вида жизненного цикла в соответствии с профилем риска проекта, управление старением, управление стоимостью и реформа сметной системы, освоение axiomatic design , сооружение с поставками «точно вовремя », порождающее проектирование и сооружение, а также многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. СУЖЦ должна хорошо делать своё дело, а не плохо решать огромный набор произвольно выбираемых чужих задач.

У архитектора СУЖЦ тем самым две основные задачи:

• породить некоторое количество лучших архитектур-кандидатов и их гибридов
• совершить многокритериальный выбор из этих архитектур.
  • содержательное рассмотрение (содержательность критериев выбора)
  • оформление результата (обоснование).

Критерии выбора архитектурного решения для СУЖЦ

1. Качество выполнения СУЖЦ своего основного предназначения: обнаружения и предотвращения коллизий Главный критерий: насколько может быть ускорен ход инженерных работ за счёт ускорения обнаружения или предотвращения коллизий при использовании предлагаемой архитектуры СУЖЦ? А если время работ не может быть сокращено, то насколько за то же время можно увеличить объем работ при использовании тех же ресурсов? Рекоммендуются следующие методологии:
   • Теория ограничений Голдратта (TOC, theory of constraints) – архитектура должна указывать, какие системные ограничения она снимает на критическом ресурсном пути инженерного проекта (не путать с критическим путём).
   • ROI (return on investments) для инвестиций в СУЖЦ на стадии оформления результата содержательного рассмотрения архитектур-кандидатов.
   Важно выбрать границы рассмотрения: общая скорость выполнения инжинирингового проекта может быть замерена только на границе рассматриваемой организационной системы. Границы какого-то одного юрлица могут не совпадать с границами расширенного предприятия, осуществляющего масштабный инженерный проект, а участвующее лишь на одной стадии жизненного цикла предприятие может неправильно оценить свою полезность и критичность для полного жизненного цикла системы и неправильно выбрать способ своей интеграции в СУЖЦ. Тогда может выясниться, что создание СУЖЦ не влияет на общие сроки и бюджеты проекта, ибо самые неприятные коллизии продолжат себя являть неадресованные новой СУЖЦ.
2. Возможность принятия инкрементального жизненного цикла разработки СУЖЦ Инкрементальным в ISO 15288 называется такой жизненный цикл, при котором функциональность пользователю выдаётся не сразу вся, а постадийно - но и вложения в разработку также происходят не одномоментно, а постадийно. Конечно, при этом нужно учитывать закон убывающей полезности: каждый инкремент СУЖЦ (каждый новый тип обнаруживаемых заранее коллизий) обходится дороже, а пользы от него всё меньше, пока продолжающаяся много лет разработка СУЖЦ не затухнет сама собой. Если выясняется, что для какой-то из предложенных архитектур нужно одномоментно вложить в создание СУЖЦ много денег, но пользу можно будет получить сразу в размере 100% и только через пять лет "под ключ", то это плохая архитектура. Если выясняется, что можно разработать и ввести в эксплуатацию какое-то компактное ядро СУЖЦ, и далее много-много однотипных модулей для разных типов коллизий с понятным механизмом их разработки (например, основанным на использовании ISO 15926), то это очень хорошо. Речь не столько о том, чтобы применять «гибкую разработку» (agile methodologies), сколько предусмотреть модульную архитектуру СУЖЦ и предложить план реализации приоретизированного списка модулей – сначала самых насущных, затем менее насущных, и т.д. Не путать с ICM (incremental commitment model), хотя смысл тут такой же: лучше та архитектура, при которой можно получить какую-то рассрочку платежей за систему, а нужную функциональность получать как можно раньше – чтобы пользу получить (хотя бы маленькую) пораньше, а платить за позднюю пользу попозже.
3. Принципиальная финансовая и интеллектуальная возможность освоить и поддерживать технологию Если посчитать траты не только на собственно СУЖЦ, но и на всю потребную для осуществления проекта кадровую и иную инфраструктуру, то нужно понять, сколько этих вложений в образование, компьютеры и организационные усилия останется плательщику и собственнику СУЖЦ, а сколько осядет вовне – у многочисленных контракторов, которые, конечно, будут благодарны сначала за получение ими «стипендии» на освоение новой технологии, а затем за сопровождение созданной ими системы. Новое обычно крайне затратно, и не потому что оно само дорого стоит, а потому что вызывает лавину вызываемых им изменений. Именно этот пункт у меня учитывает полную стоимость владения СУЖЦ, и этот же пункт включает рассмотрение полного жизненного цикла уже не инженерной системы с её предотвращаемыми коллизиями, но самой СУЖЦ.
4. Масштабируемость архитектуры СУЖЦ Этот критерий актуален для крупных инженерных проектов. Поскольку вы хотите, чтобы системой пользовались все тысячи сотрудников расширенной организации, она должна будет быстро расти до этих масштабов. Насколько "пилот" или "полигон" СУЖЦ смогут быстро вырасти без принципиальных архитектурных изменений? Скорее всего, они вырасти не смогут. Поэтому архитектурно нужен не "пилот" или "полигон", а сразу "первая очередь". Требование критерия масштабирования тесно пересекается с требованием критерия инкрементальности, но затрагивает чуть-чуть другой аспект - не столько растяжка создания СУЖЦ по времени, сколько возможность растяжки по накрываемому объему. Опыт показывает, что на тестовых объемах проектных данных справляются все системы, а вот на промышленных - не справляются. Как нелинейно будет расти стоимость аппаратуры и программных средств при росте объемов/скорости? Как долго будут отрабатывать регламенты, когда выяснится, что через какое-то рабочее место проходит бОльшее число данных, чем может быть осмысленно просмотрено одним человеком? Плохая масштабируемость может подстерегать не только с технической стороны архитектуры программно-аппаратного решения, но и со стороны финансовой его архитектуры. Так, небольшая цена на лицензию на каждое рабочее место СУЖЦ, или даже небольшая цена на каждое новое соединение на сервере-репозитарии могут превратить более-менее симпатичное решение для десяти рабочих мест в абсолютно финансово неподъемное для целевой тысячи рабочих мест.
5. Возможность учитывать неизбежные организационные проблемы в том числе отношение к любимым унаследованным (legacy) системам в расширенной организации. Как много предлагаемая централизованная или распределенная архитектура потребует "отдавать функций другим подразделениям", "отдавать наших данных" и вообще чего-то "отдавать" по сравнению с текущей ситуацией без СУЖЦ? Мейнфреймы массово проиграли соревнование мини-компьютерам, а те - персональным. Назад (к централизованным системам, каковой неизбежно представляется СУЖЦ) пути почти нет, ибо все данные лежат в отдельных приложениях, и вытащить эти данные в новые системы представляется сложнейшей организационной задачей. Как устроена архитектура СУЖЦ: она замещает текущие унаследованные инженерные приложения, она надстраивается над текущей IT-инфраструктурой, она устанавливается "задарма" разным службам? Сколько организационных/менеджерских/консультационных усилий потребуется для того, чтобы "пропихнуть" новую технологию? Сколько людей уволить, сколько найти и принять новых специалистов? Этот критерий организационной приемлемости тесно связан не только с централизацией/децентрализацией, но и с рассмотрением системы мотивации в расширенном предприятии, т.е. оценка архитектуры СУЖЦ по этому критерию далеко выходит за рамки узкого рассмотрения только СУЖЦ, но требует тщательного анализа принципов построения расширенной организации – вплоть до пересмотра принципов, лежащих в основе контрактов, по которым она создана. Но это и есть суть системного подхода: любая целевая система (в данном случае - СУЖЦ) рассматривается прежде всего не "вглубь, из каких частей", а "наружу, часть чего" - не ее конструкция и механизм работы интересны прежде всего, а поддерживаемая СУЖЦ функция предотвращения коллизий во внешней надсистеме - и цена, которую внешняя надсистема готова платить за эту новую функцию. Поэтому возможные архитектуры СУЖЦ и рассматриваются прежде всего не с точки зрения "приличных используемых технологий, например от поставщика программных средств XYZ" (это по умолчанию: все предлагаемые варианты архитектуры обычно приличны технологически, иначе они не варианты!), а с точки зрения вышеописанных пяти критериев.

Функции СУЖЦ

1. Предотвращение коллизий
   1. Управление конфигурацией
      1. Идентификация (классификации, кодировки)
      2. Учёт конфигурации (все возможные baseline - ConOp, Architecture, design, as built), в том числе передача данных в репозиторий СУЖЦ, в том числе поддержка workflow изменений, в том числе поддержка параллельного инжиниринга (работа в условиях неполных baseline)
      3. Версионирование (включая forks)
   2. Отсутствие ручного переввода данных (передача входных и выходных данных между уже имеющимися островками автоматизации, включая передачу данных из островков "подъема в цифру" старых проектных наработок)
   3. Конфигурация НСИ
   4. Система поддержки коллаборативного инжиниринга (видео-конференции, удаленные проектные сессии и т.д. - возможно, не та, которая используется для создания самой системы СУЖЦ)
2. Выявление коллизий
   1. Поддержка регистра проверяемых видов коллизий и соответствующих регистру технологий проверки
   2. Передача данных для проверки коллизий между островками автоматизации (без сборки в репозитории СУЖЦ, но средствами интеграционной технологии СУЖЦ)
   3. Прогон workflow проверки разных видов коллизий
      1. в репозитории СУЖЦ
      2. не в репозитории, но средствами интеграционной технологии СУЖЦ
   4. Запуск прогона workflow устранения найденной коллизии (рассылка уведомлений о коллизиях, ибо прогон workflow устранения – не забота СУЖЦ)
   5. Поддержка актуального списка неустранённых коллизий
3. Развиваемость (тут СУЖЦ рассматривается как автопоэтическая система, ибо «инкрементальность реализации» входит в число важнейших свойств самой СУЖЦ -- так что это функция самой СУЖЦ, а не функция обеспечивающей системы для СУЖЦ)
   1. Обеспечение коммуникации по поводу развития СУЖЦ
      1. Планирование работ развития СУЖЦ (roadmap , разработка плана мероприятий)
      2. Функционирование проектного офиса СУЖЦ,
      3. Ведение регистра видов проверок коллизий (сам регистр "хотелок" и roadmap реализации проверок)
      4. Орг-техническое моделирование (Enterprise Architecture) для СУЖЦ
      5. Инфраструктура коммуникации разработчиков СУЖЦ (интернет-конференции, видеосвязь, управление знаниями и т.д. -- возможно, не та, которая используется в ходе коллаборативного инжиниринга с использованием СУЖЦ)
   2. Единообразность технологии интеграции данных (например, технология ISO 15926)
      1. Использование нейтральной модели данных
         1. Поддержка библиотеки справочных данных
         2. Разработка справочных данных
      2. Технология поддержки адаптеров к нейтральной модели данных
   3. Единообразность технологии интеграции workflow/BPM (в масштабах расширенного предприятия)
4. Безопасность данных (в масштабах информационных систем, работающих в рамках СУЖЦ)
   1. Обеспечение единства доступа (один логин и пароль ко всем информационным системам, участвующим в workflow)
   2. Управление правами доступа к элементам данных
   3. Резервное копирование

Кэролин Пампино (Carolyn Pampino, IBM)
На основе приложений: Rational Team Concert Beta 3, Rational Quality Manager Beta 3, Beta 3

Обзор

Жесткая конкуренция заставляет многие организации создавать продукты за более короткие сроки, при этом делая их еще более инновационными. Разработка программного обеспечения сама по себе является сложной задачей, поэтому чрезвычайно сложны и системы, создаваемые организациями-разработчиками информационных систем и устройства. Команды, находящиеся в условиях сжатых сроков, должны делать это без ущерба качеству или увеличения бюджета. Для этого их стратегией должно быть улучшение эффективности разработки программного обеспечения. Решение этой дилеммы состоит в улучшении взаимодействия в жизненном цикле при помощи управления жизненным циклом (УЖЦ) приложений.

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

Наиболее важное преимущество решения для УЖЦ состоит в возможности координировать людей, процессы, информацию и инструменты, задействованные в проекте, для того, чтобы создавать инновационные продукты для заинтересованных лиц проекта. Поскольку не существует универсального решения, подходящего всем, мы советуем нашим клиентам сосредоточиться на следующих принципах при внедрении управления жизненным циклом, наиболее соответствующего культуре и окружению в их организации:

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

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

Мы занимаемся планированием, потому что хотим прийти к определенной цели и хотим знать, когда она будет достигнута. Существует единственный способ узнать, когда работа завершена. Для этого необходимо обеспечить, чтобы планы были полностью интегрированы с выполнением проекта и всегда были актуальны. В следующей таблице перечислены несколько типичных действий, связанных с планированием, которые стоит или не стоит делать.

На следующем изображении показано, как быстрое обновление потраченного времени напрямую из элемента работ облегчает поддержание точности планов.

Рис. 1. Обновление потраченного времени из элемента работ поддерживает точность планов

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

Рис. 2. На представлении запланированного времени видно, когда у одних участников команды работы больше, чем у других

Рис. 3. Представление электронной доски задач может быть использовано гибкими командами, разнесенными территориально

Рис. 4. Представление плана развития отображает распределение задач по дням и неделям в более традиционном виде

Изображение ниже демонстрирует план выпуска (Release Plan) в Rational Team Concert со ссылками на связанный с ним журнал предложений (Product Backlog), коллекции требований в Rational Requirements Composer и план тестирования в Rational Quality Manager .

Рис. 5. С планированием связаны коллекции требований и планы тестирования

Решение IBM Rational для совместного управления жизненным циклом включает полностью интегрированное планирование в реальном времени.

Трассировка жизненного цикла

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

Решение для УЖЦ, позволяющее осуществлять трассировку между артефактами жизненного цикла, помогает командам получать ответы на сложные вопросы относительно статуса их проекта. Создание связей между артефактами позволяет командам легче отвечать на такие вопросы, как: "На какие требования влияют дефекты?" и "Какие элементы работ готовы к тестированию?"

Рис. 6. Важные вопросы, на которые дает ответ решение для УЖЦ

Трассировка помогает каждому члену команды понимать, что делают остальные и как это влияет на объем работы в целом. Если вы работаете в окружении с внешним регулированием, трассировка поможет вам отвечать на такие вопросы со стороны аудиторов, как "Какие изменения включены в эту сборку, какие тесты были проведены и с каким результатом?"

Ниже приведены типичные действия, которые стоит или не стоит делать, связанные с трассировкой:

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

Рис. 7. План выпуска, охватывающий разработку, требования и тестирование

Когда трассировочные связи установлены, решение IBM Rational для совместного управления жизненным циклом (IBM Rational Collaborative Lifecycle Management) автоматически создает на их основе трассировочные связи с дефектами, выявляемыми в ходе проведения тестирования. На изображении ниже показан дефект с созданными для него трассировочными связями. При добавлении дефекта в ходе тестирования, автоматически создаются трассировочные связи дефекта с результатами теста, тестовым набором, планом тестирования, элементом плана и требованием.

Рис. 8. Связи жизненного цикла, созданные автоматически для дефекта, отображают тестовые наборы, элементы плана и требования, на которые он влияет

Взаимодействие в контексте

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

Также инструменты для взаимодействия помогают командам фокусироваться на том, что важно. Команды должны находить любые возможности для автоматизации ручных и не творческих задач. Хорошее решение для УЖЦ включает в себя автоматизацию для сборок и выполнения тестов, но также должно включать автоматизацию создания отчетов о состоянии и доступ к информации. Информационные панели проекта и персональные информационные панели играют важную роль в автоматическом снабжении команды необходимой информацией, обеспечивая прозрачность работы команды и доступ к актуальным данным при помощи командных отчетов и запросов. Хорошо спроектированный пользовательский интерфейс автоматизирует доступ к информации, доставляя информацию пользователям напрямую и не заставляя их "менять контекст", переключаясь на работу с другим приложением. В такой форме автоматизация напрямую способствует лучшему взаимодействию.

Изображение ниже демонстрирует набор информационных панелей с виджетами, содержащими информацию из Rational Team Concert , Rational Requirements Composer и Rational Quality Manager . Данные на информационных панелях отображают актуальный статус проекта.

Рис. 9. Информационные панели с данными из различных источников, обеспечивают прозрачность работ для всех функциональных команд

На изображении ниже показана мини-информационная панель, которая всегда доступна сбоку пользовательского интерфейса и может быть закреплена слева или справа. Она выполняет функции персональной мини информационной панели, которая следует за пользователем повсюду в рамках решения для УЖЦ, и может быть скрыта или показана в любой момент времени.

Рис. 10. Мини-панель доступна из любой точки пользовательского интерфейса

Следующее изображение демонстрирует персональную мини-панель в Rational Team Concert . На этой панели есть виджет, отображающий изменения требований в Rational Requirements Composer . Это пример мини-панели с информацией из различных источников. При наведении мышки на требование появляется предпросмотр с информацией о статусе требования в Requirements Composer. Пользователи, которым необходим быстрый доступ к информации, быстро привыкнут к мини-панелям.

Бизнес аналитика для разработки

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

Согласно Кейперсу Джонсу (Capers Jones 1), проекты, в которых практики измерений широко используются, достигают гораздо больших успехов, чем те, в которых подобные практики не используются.

Рис. 12. Проекты, использующие практики измерений, имеют больший шанс на успех

Например, три приведенных ниже метрики используются менее чем в 50% организаций по исследованиям Кейперса Джонса:

• Метрики качества 45%
• Метрики продуктивности 30%
• Метрики готовности 15%

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

Рис. 13. Информационная панель с отчетами и метриками для измерения улучшений

Информационные панели и отчеты - ключевая составляющая решения для УЖЦ, отвечающая за измерения и реагирование на текущий прогресс команды.

Непрерывное улучшение процесса разработки

Процесс - это нечто большее, чем документированный набор действий. Мы разрабатываем процессы на основе лучших практик, взятых из опыта индустрии, как средство улучшения взаимодействия команды и повышение ее шансов на успех. Поведение по большей части определяется привычкой. Когда вы определяете или меняете процесс, вы фактически просите всю команду изменить свои привычки и перенять поведение, которое может на первый взгляд быть им непонятно. Довольно сложно изменить привычки одного человека. Для изменения процесса зачастую необходимо изменить способы мышления и модели поведения у множества людей. Хорошо спроектированное решение для УЖЦ позволяет вам менять процесс постепенно, улучшая динамику команды и продолжать движение к большей эффективности.

Анализируя развитие рынка средств разработки за последние 10-15 лет, можно отметить общую тенденцию смещения акцентов от технологий собственно написания программ (которые с начала 90-х годов ознаменовались появлением RAD-инструментов - "быстрая разработка приложений") к необходимости комплексного управления всем жизненным циклом приложений - ALM (Application Lifecycle Management) .

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

· определение требований (Requirements);

· проектирование и анализ (Design & Analysis);

· разработка (Development);

· тестирование (Testing);

· развертывание и сопровождение (Deployment & Operations).

Каждый из этих этапов должен тщательно отслеживаться и контролироваться. Правильно организованная ALM-система позволяет:

· сократить сроки вывода продуктов на рынок (разработчикам приходится заботиться лишь о соответствии их программ сформулированным требованиям);

· повысить качество, гарантируя при этом, что приложение будет соответствовать потребностям и ожиданиям пользователей;

· повысить производительность труда (разработчики получают возможность делиться передовым опытом разработки и внедрения);

· ускорить разработку благодаря интеграции инструментов;

· уменьшить затраты на сопровождение, постоянно поддерживая соответствие между приложением и его проектной документацией;

· получить максимальную отдачу от инвестиций в навыки, процессы и технологии.

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

Этими задачами занимались многие компании, однако бесспорным лидером здесь была компания Rational, которая более двадцати лет, с момента своего создания, специализировалась на автоматизации процессов разработки программных продуктов. В свое время, именно она стала одним из пионеров широкого использования визуальных методов проектирования программ (и практически автором языка UML, принятого де-факто в качестве стандарта в этой сфере), создала общую ALM-методологию и соответствующий набор средств. Можно сказать, что к началу нынешнего века Rational была единственной компанией, имевшей в своем арсенале полный спектр продуктов для поддержки ALM (от бизнес-проектирования до сопровождения), за исключением, правда, одного класса инструментов - обычных средств написания кода. Однако, в феврале 2003-го, она перестала существовать как независимая организация и стала подразделением корпорации IBM, получившим название IBM Rational.

Еще совсем недавно Rational являлась практически единственным производителем комплексных средств разработки класса ALM, хотя конкурирующие инструменты от других поставщиков для отдельных этапов создания ПО были и есть. Однако пару лет назад о намерении составить ей реальную конкуренцию публично заявила корпорация Borland, которая всегда имела сильные позиции как раз в области традиционных средств разработки приложений (Delphi, JBuilder и пр.), фактически являющихся основой ALM-комплекса корпорации, расширение которого шло путем приобретения других компаний, выпускающих аналогичные продукты. В этом состоит принципиальное различие бизнес-моделей двух компаний, открывающее потенциальные возможности для реальной конкуренции. После вхождения Rational в состав IBM компания Borland позиционирует себя как единственного на сегодняшний день независимого поставщика комплексной ALM-платформы (т. е. продвижением собственных ОС, языков и пр. она не занимается). В свою очередь конкуренты отмечают, что Borland пока не сформулировала четкую методологию ALM, дающую базу для объединения имеющихся у нее инструментов.

Еще одним серьезным игроком на поле средств разработки является корпорация Microsoft. Пока она не замахивается на создание собственной ALM-платформы; продвижение в данном направлении идет только в рамках сотрудничества с другими поставщиками, теми же Rational и Borland (обе они стали первыми участниками программы Visual Studio Industry Partner). В то же время созданное Microsoft ключевое средство разработки Visual Studio .NET постоянно расширяет функциональность за счет использования высокоуровневых средств моделирования и управления проектами, в том числе путем интеграции с Microsoft Visio и Microsoft Project.

Следует отметить, что на сегодняшний день практически все ведущие компании–разработчики технологий и программных продуктов (кроме перечисленных выше, можно назвать Oracle, Computer Associates и др.) располагают развитыми технологиями создания ПО, которые создавались как собственными силами, так и за счет приобретения продуктов и технологий, созданных небольшими специализированными компаниями. И хотя, подобно корпорации Microsoft, создание собственной ALM-платформы ими пока не планируется, выпускаемые этими компаниями CASE-средства находят широкое применение на отдельных этапах ЖЦ ПО.

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

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

В ИТ-индустрии любят поговорить насчет барьеров между ИТ и бизнесом, однако внутри самой ИТ-структуры существует масса менее заметных барьеров, которые могут встать на пути неосторожного системного интегратора.

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

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

Для успешного внедрения ALM-методологии системный интегратор должен подняться над уровнем взаимных обвинений в ИТ-департаменте. Как считает Джина Пул, вице-президент по маркетингу отделения IBM Rational Software , это означает поиск и привлечение к работе ИТ-директора или финансового директора, способного осознать, сколько денег теряет заказчик из-за отсутствия слаженной работы всех служб ИТ-департамента. Исправление ошибок в приложении на поздних стадиях проекта разработки означает чрезвычайно высокие расходы. Если необходимость такого исправления вызвана сделанными ранее предположениями разработчика о том, в какой среде будет функционировать приложение, и эти предположения оказываются в конечном счете неверными, то стоимость всего проекта возрастает в разы или же заказчик будет вынужден соответствующим образом модернизировать свою инфраструктуру.

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

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