Способы управления жизненного цикла

Система управления жизненным циклом

Пространства имён

Действия на странице

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

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

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

Содержание

СУЖЦ vs PLM

Системная инженерия редко использует понятие «управление жизненным циклом», но это понятие часто используется поставщиками программных систем PLM (Product Life cycle Management).

В России сейчас проходит серия межотраслевых и международных мероприятий (совещаний, конференций и т.д.), где активно используется название «система управления жизненным циклом» (СУЖЦ), вводимое взамен PLM (product lifecycle management). Эта замена термина требует некоторой расшифровки.

Слово «продукт» из PLM в СУЖЦ пропало не случайно, ибо речь идет о сложных инженерных объектах – если вертолёт еще можно с натяжкой назвать «продуктом» в силу его серийности, то атомная станция «продуктом» обычно уже не называется. Поэтому «жизненным циклом» какой именно системы тут «управляется», нужно уточнять в каждом конкретном случае. «Система УЖЦ системы» немного запутывает, но именно это и имеется ввиду.

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

По-новому сформулированная СУЖЦ не использует 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, сооружение с поставками «точно вовремя», порождающее проектирование и сооружение, а также многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. СУЖЦ должна хорошо делать своё дело, а не плохо решать огромный набор произвольно выбираемых чужих задач.

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

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

Источник

Пять принципов управления жизненным циклом приложения

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

Обзор

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

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

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

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

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

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

Действия, которых следует избегать

Рекомендуемые действия

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

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

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

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

Используйте планы, которые полностью интегрированы с выполнением проекта.

Убедитесь в том, что все планы доступны и открыты каждому участнику команды проекта.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действия, которых следует избегать

Рекомендуемые действия

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

Не переусердствуйте в создании трассировочных связей или выполнении трассировки просто ради самой трассировки.

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

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

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

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

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

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

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

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

Не выбирайте репозитории УЖЦ с проприетарными интеграциями.

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

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

Выбирайте поставщика продуктов, который понимает и поддерживает трудные задачи интеграции при управлении жизненным циклом.

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

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

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

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

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

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

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

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

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

Действия, которых следует избегать

Рекомендуемые действия

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

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

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

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

Не игнорируйте мнение заинтересованных лиц и не предполагайте, что вы и так знаете, чего они хотят.

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

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

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

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

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

Рис. 11. Предпросмотр по ссылке из мини-панели

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

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

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

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

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

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

Вот наши рекомендации относительно практики измерений:

Действия, которых следует избегать

Рекомендуемые действия

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

Установите метрики производительности, подходящие вашей организации.

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

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

Не пытайтесь определить сразу все метрики проекта.

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

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

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

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

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

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

Действия, которых следует избегать

Рекомендуемые действия

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

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

Не поддавайтесь искушению улучшить все и сразу.

Не пытайтесь слишком точно определить процесс за один раз.

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

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

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

Избегайте слишком жесткого контроля процесса.

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

Не определяйте улучшений процесса, не видя конечного результата.

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

Не стоит ожидать, что вы с первого раза сделаете все правильно.

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

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

Рис. 14. Типы элементов работы, поддерживающих Scrum, по умолчанию присутствуют в Rational Team Concert

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

Выбор решения УЖЦ для вашей команды

Выбирайте решение для УЖЦ, которое поддерживает и стимулирует сотрудничество вне зависимости от роли, организации или географического местоположения. Решение IBM Rational для совместного управления жизненным циклом (IBM Rational Solution for Collaborative Lifecycle Management) соответствует пяти принципам, описанным выше. Это решение содержит три основных продукта: IBM Rational Team Concert, IBM Rational Quality Manager и IBM Rational Requirements Composer.

Rational Team Concert интегрирует отслеживание элементов работ, управление исходным кодом, непрерывные сборки, планирование итераций и широкие возможности по настройке процесса для адаптации под ваш способ работы, предоставляя разработчикам, архитекторам, менеджерам проекта и владельцам проекта возможности для эффективной совместной работы. Поддерживается кросс-платформенная разработка, например, на Java, .NET, и для мейнфреймов. У Rational Team Concert есть встроенные интеграции как с Requirements Composer и Quality Manager, так и со многими другими популярными инструментами разработки. Узнайте больше на странице интеграций проекта на Jazz.net.

Команды, которым необходимо определение требований с использованием различных визуальных и текстовых способов и управление требованиями, используют Rational Requirements Composer. Requirements Composer продолжает активно развиваться для того, чтобы обеспечивать определение и управление требованиями для работающих в быстром темпе, ориентированных на рынок проектных команд. Requirements Composer обладает встроенными интеграциями с Team Concert, Quality Manager и многими другими популярными инструментами. Узнайте больше об интеграциях Requirements Composer на Jazz.net.

Команды, которые хотят улучшить свою способность достигать целей качества, используют Rational Quality Manager, в котором есть встроенные интеграции с Rational Team Concert и Rational Requirements Composer. IBM Rational Quality Manager помогает организациям оптимизировать качество в проекте путем предоставления единого центра для управления тестированием, который обеспечивает интегрированную поддержку жизненного цикла практически для любой целевой платформы и типа тестирования. Он реализует настраиваемое решение, основанное на ролях, для планирования тестирования, создания и выполнения тестов, а также для контроля последовательности работ, управления и сквозной трассировки.

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

1 Capers Jones, «Measurement, Metrics and Industry Leadership,» 2009, and Software Engineering Best Practices , McGraw Hill, 2010.

Об авторе

Кэролин Пампино — руководитель программы стратегических предложений, фокусирующейся на разработке программного обеспечения для информационных технологий. Она член команды «ALM leadership team» в IBM Rational, работает вместе с лидерами команды Jazz, определяя план и стратегию развития для решения по совместному управлению жизненным циклом. Кэролин — автор постов в блоге и демонстраций на Jazz.net, соавтор электронной книги под названием «Масштабирование гибких методологий с помошью совместного управления жизненным циклом», а также соавтор IBM Redbook под названием «Совместное управление жизненным циклом с помощью продуктов IBM Rational». Она одна из основателей команды, определяющей стратегии для интеграции продуктов Rational и Tivoli, а также активный участник приобретения Build Forge. Перед работой в IBM Кэролин была директором по управлению продуктами, разработке и анализу деятельности конкурентов в BroadVision, Inc.

Кэролин благодарит Erich Gamma, Kim Peter, Robyn Gold, и Fariz Saracevic за их вклад в эту статью, как и все команды платформы Jazz и приложений для совместного управления жизненным циклом за создание потрясающих решений!

Ссылки по теме

Помощь

	Задать вопрос
программы
обучение
экзамены
компьютеры
	ICQ-консультанты
	Skype-консультанты
Общая справка
Как оформить заказ
Тарифы доставки
Способы оплаты
Прайс-лист
Карта сайта

О нас

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