Главная
Архив новостей
Шаблоны
Студенту
Статьи по стандартам
Файлы
Ссылки
Форум
О проекте
История проекта

Открытое управление жизненным циклом приложений (ALM)

Автор: interface.ru
Источник: interface.ru

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

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

Предсказуемая разработка ПО: миссия невыполнима?

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

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

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

  1 Такие основные тенденции в отрасли, как ускоренное внедрение среды улучшения процессов CMM/CMMI и расширение использования моделей разработки с привлечением сторонних ресурсов, тесно связаны с этим очевидным преобразованием отрасли разработки ПО.

Появление ALM

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

Измеримость

• Возможность определения систем мер для оценки качества, продуктивности, прогресса и риска.

• Анализ этих метрик и создание отчетов в процессе выполнения проекта.

Согласование

• Согласование бизнес-специализации и приоритетов в области ИТ.

• Согласование результатов проекта с ожиданиями конечных пользователей.

Дисциплина

• Соответствие определения, развертывания и отслеживания программным процессам.

• Повышение строгости процесса изменений в управлении и прогнозирование их последствий.

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

Индустрия ALM

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

• Для нужд руководителей предусмотрены панели инструментов уровня портфелей проектов, которые охватывают важные метрики проекта: риск, прогресс и качество.

• Для нужд менеджеров проектов предусмотрены инструменты для планирования и контроля проекта, анализа возможных альтернатив и распределения ресурсов.

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

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

• Для нужд разработчиков предусмотрены различные среды программирования, а также средства обеспечения качества на уровне программного кода (например, профайлеры выполнения, а также средства для тестирования модулей и автоматизированного аудита кода).

• Для нужд инженеров по качеству предусмотрены средства для создания и управления тестами, для регрессионного и функционального тестирования, а также средства для автоматизированного тестирования производительности.

• Для решений общих проблем всей группы служит коллективная инфраструктура. Она предоставляет средства для совместной работы, руководства процессами, управления изменениями и контроля версий.

• Для нужд руководителей процесса создания ПО предусмотрены средства моделирования и применения набора корпоративных технологических стандартов.

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

Технология ALM, по общему признанию, стала большим шагом в развитии индустрии средств разработки приложений и ее заказчиков. Интересно, что последний отчет "Chaos report" от Standish Group показывает, что уровень неудачно завершенных проектов по созданию ПО за прошедшее десятилетие снизился вдвое. Это улучшение можно частично отнести и на счет ALM. Однако более глубокое исследование нужд заказчиков показывает, что, несмотря на очевидные преимущества ALM, полный потенциал этой технологии реализовать по-прежнему трудно. Для этого нужно сменить фундаментальный подход, который используется для интеграции процессов и средств, задействованных в жизненном цикле ПО.

Потенциал ALM для бизнеса в основном не реализован

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

Корпоративная среда ИТ: проблема гетерогенности

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

• Миграция с монолитных специализированных приложений, работающих на мэйнфреймах, на новые средства разработки для корпоративных распределенных платформ, а именно J2EE и .NET.

• Миграция с пакетированных корпоративных приложений, созданных на базе устаревших архитектур, к таким средам выполнения процессов и композитных приложений, как SAP NetWeaver и Oracle Fusion.

• Использование для определенных нужд специализированных платформ. Это, например, языки сценариев для веб-приложений с использованием баз данных (PHP, Ruby и т.д.), или платформы для разработки приложений с разнообразными функциями работы с Интернетом и мультимедиа (например, Adobe® Flash®/Flex™).

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

Будет разумно предположить, особенно в отношении корпораций среднего и крупного размера, что в обозримом будущем каждая корпоративная ИТ-среда будет включать в себя хотя бы три из перечисленных платформ для развертывания: мэйнфрейм, распределенная среда (J2EE или .NET) и система для автоматизации бизнес-процессов (SAP или Oracle). Также похоже (и это становится все более очевидным), что некоторые организации развертывают ПО и на платформу J2EE, и на .NET. 2

Конфликтующие программы

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

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

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

o Композитные приложения или службы, которые включают в себя мэйнфрейм, пакетированные приложения и разработанные своими силами распределенные приложения.

o Гибриды J2EE/.NET, которые используют возможности и пользовательский интерфейс .NET на стороне клиента. На стороне сервера они используют масштабируемость, управляемость и безопасность технологии J2EE. Этот архитектурный шаблон особенно часто встречается в финансовой вертикали. Он используется для высокопроизводительных торговых платформ, поскольку на Уолл-Стрит Windows - это стандарт де-факто для настольных компьютеров.

o Гибриды Flash/J2EE. Они объединяют возможности Adobe Flash в качестве платформы для потокового видео и многофункциональных Интернет-приложений с преимуществами технологии J2EE для серверов. Это позволяет добиваться высокой степени масштабируемости и реализовать интерфейс с широкими возможностями работы с мультимедиа.

• Сокращение затрат на разработку. Организации пытаются снизить затраты на разработку ПО и его развертывание, комбинируя инструменты и программы как с открытым исходным кодом, так и собственной разработки. В этой связи стоит упомянуть растущую популярность комплекта LAMP (Linux, Apache, MySQL, PHP) и его все более широкое применение в организациях.

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

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

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

 2 Такие основные тенденции в отрасли, как ускоренное внедрение среды улучшения процессов CMM/CMMI и расширение использования моделей разработки с привлечением сторонних ресурсов, тесно связаны с этим очевидным преобразованием отрасли разработки ПО. Отчет IDC Insight по использованию J2EE и .NET Стива Макклура (Steve McClure) утверждает следующее. 10,4% текущих пользователей .NET ожидают, что в течение ближайших 12 месяцев они будут использовать и J2EE/J2ME; 11,9% пользователей J2EE/J2ME ожидает, что в течение ближайших 12 месяцев они будут вовлечены в разработку .NET.

Гетерогенность ИТ: величайшая проблема для ALM

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

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

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

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

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

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

• Возможность использовать смесь рабочих платформ наиболее оптимальным с точки зрения их бизнес-целей образом.

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

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


Для удовлетворения этого сложного набора требований нужен новый подход к ALM. Подход, который позволит заказчикам полностью использовать возможности ALM в гетерогенной среде ИТ. Компания Borland недавно анонсировала свой подход и стратегию продуктов под названием Open ALM. Этот подход непосредственно предназначен для решения этой задачи. Это единственное решение ALM, которое изначально предназначено для того, чтобы позволить организациям ИТ предсказуемо создавать ПО в установленные ими самими сроки.

Преодоление гетерогенности: последний рубеж ALM

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

Преимущества Open ALM

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

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

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

• Свобода выбора или проектирования процессов разработки, которые наилучшим образом подходят к их проектам и выбранным платформам, а также соответствуют

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

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

• Прекрасное многомерное и настраиваемое представление метрик прогресса, качества и риска проектов и портфелей, которое обеспечит поддержку управления проектами и инициатив по улучшению процессов.

• "Чаша Грааля": полный оперативный контроль и отслеживание жизненного цикла. Это позволит добиться реального согласования бизнес-целей и действий в процессе разработки, обеспечит лучшую связь между ожиданиями конечных пользователей и итогами проекта, а также предоставит лучшие возможности для управления проектом с помощью точного и всестороннего анализа последствий.

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


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

Управление портфелем проектов (Project Portfolio Management, PPM). Средства и автоматизированные процессы для управления разработкой всей стратегии создания ПО, а также для управления выполнением портфеля проектов по разработке ПО.

Определение требований и управление ими (Requirements Definition and Management, RDM). Набор средств и лучших методик, которые обеспечивают следующее: требования к проекту точны и полны, их можно эффективно отследить вплоть до бизнес-целей, и они оптимально охвачены тестами ПО.

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

Управление изменениями (Change Management, CM). Инфраструктура и средства, которые помогают предсказать последствия изменений. Они также помогают управлять ресурсами и действиями, связанными с изменениями в ходе жизненного цикла, как в многоузловых, так и в одноузловых моделях.

Решение Borland Open ALM

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


Архитектура решения Borland Open ALM


Открытая бизнес-аналитика для ALM

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

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

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

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

Открытое управление процессом для ALM

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

Открытое управление процессом для ALM (Open Process Management for ALM, OPM4ALM) предоставляет компоненты инфраструктуры и набор приложений, которые используются для моделирования, развертывания и внедрения различных программных процессов в гетерогенной среде разработки приложений. OPM4ALM идет гораздо дальше обеспечения руководства и распределения заданий между участниками процесса. Этот метод также использует уровень автоматизации процесса, который служит основным "клеем" для интеграции клиентской стороны, серверной стороны и методики согласно правилам, зафиксированным в моделях процессов. С этой точки зрения интеграция между средствами разработки приложений на самом деле обеспечивается процессами более низкого уровня. Это становится фундаментальной основой для эффективной работы коллектива.

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


Приложения OPM4ALM обеспечивают отдачу от уровня инфраструктуры процессов. Они обеспечивают следующие возможности.

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

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

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

• Измерения и отчетность на базе специальных метрик для каждого процесса.

Открытый контроль для ALM

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

OT4ALM предоставляет приложения, которые преобразуют собранные контрольные данные в информацию для принятия решений.

• Автоматизированное планирование, анализ последствий изменений, точные предсказания затрат и бюджета.

• Контроль границ - раннее оповещение об отклонении от заданных границ (например, ресурсы, которые не удовлетворяют требованиям) и нереализованных требованиях.

• Анализатор повторного использования - позволяет многократно использовать целые деревья ресурсов (от требований и моделей до программного кода и тестов) вместо простого повторного использования модулей программного кода.

• TraceView - интерактивные средства просмотра контрольной информации для различных проектов. Это помогает находить все ресурсы процессов и сравнивать их с другими ресурсами.

Общая инфраструктура платформ

Инфраструктура Open ALM содержит два компонента, которые используются во всех областях решения.

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

Уровень интеграции ALM. Расширяемый и встраиваемый механизм интеграции и пакет SDK. Он определяет стандартный способ работы средств ALM, сбора метрик ALM и создания диаграмм для контроля ресурсов. Для поддержки и участия в платформе ALM инструмент должен предоставлять подключаемый к платформе модуль, который удовлетворяет стандартному API Open ALM. Также можно использовать специальный адаптер, который подключает инструментальное средство к остальным средам разработки приложений через процессы, которые оркестрируются платформой Open ALM.


Дорога к Open ALM

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

• управление портфелем проектов (PPM);

• определение требований и управление ими (RDM);

• управление жизненным циклом приложений (LQM);

• управление изменениями (CM).

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

Почему Borland?

На протяжении своей долгой истории компания Borland постоянно сотрудничала со своими клиентами, обеспечивая им возможность создавать ПО наиболее удобным способом. Компания Borland привержена идеям разработки на основе стандартов и поддержки различных платформ. Она предложила организациям ИТ гибкость и свободу выбора, в которых они нуждаются. С появлением Open ALM Borland поднимает свои традиционные ценности на совершенно новый уровень. Это явно выделяет компанию среди других производителей решений ALM и некоммерческих инициатив в области ALM.

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

В противоположность этому подходу компания Borland всегда настаивала на поддержке стандартов Java и J2EE, и предлагала сильную и интегрированную поддержку платформы, языков и средств разработки Microsoft. Borland продолжает явным образом расширять решение Microsoft для ALM. Компания Borland вложила значительные средства в поддержку новейших технологий Microsoft. Например, продукт CaliberRM, который является первым полностью интегрированным решением для управления требованиями для Team System, рекомендован компанией Microsoft для расширения базовой функциональности по управлению требованиями, которая предоставляется инструментальным средством VSTS. Borland продолжит расширять совместную работу платформ Java и .NET. Планируется предоставить дополнительные возможности, например, генерацию кода из UML в C# и поддержку Microsoft Domain Specific Languages (альтернатива Microsoft для замены UML).


Движение в сторону открытого исходного кода также связано с проблемами, которые гетерогенность создает для ALM. Цель нескольких инициатив Eclipse (Application Lifecycle Framework (ALF), Corona и Eclipse Process Framework (EPF)) похожа на цели Borland Open ALM. Хотя Borland понимает мотивы, движущие этими проектами, компания считает их подход недостаточным. И ALF, и Corona пытаются предоставить лишь компоненты инфраструктуры Open ALM. Однако Open ALM представляет собой более целостный подход. Этот подход также позволяет клиентам извлекать выгоду для бизнеса из готовых инфраструктур благодаря набору дополнительных приложений. В своем движении к Open ALM Borland идет дальше других производителей решений ALM. Недавно компания расширила свои горизонты и стремится охватить дополнительные домены разработки приложений. Также Borland ищет наилучший подход к поддержке проектов по разработке пакетированных приложений на платформах SAP NetWeaver и Oracle Fusion.

Заключение

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

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

:: К списку статей ::

 Developing.ru  - клуб программистов Клуб разработчиков программных систем Rambler's Top100 Рейтинг@Mail.ru Каталог ресурсов ListTop.Ru Яндекс цитирования Rambler's Top100
© 2001-2017. Сopyright by "Отдел автоматизации и разработки ПО"
Перепечатка любых материалов без разрешения авторов сайта запрещена.
Сергей Мякишев©, o'Xana - Дизайн и разработка сайта
Kost - Программирование, Системное Администрирование