Введение
С точки зрения компании IBM Rational / Telelogic, совместное использование таких процессов как управление жизненным циклом приложений (Application Lifecycle Management, ALM) и разработка на основе моделей (Model-Driven Development, MDD) играет существенную роль в улучшении руководства разработками, в соблюдении нормативов и правил, а также упрощении отчетности в разрабатывающей компании.
ALM развилось в целую экосистему интегрированных процессов и доменных технологий, используемых в жизненном цикле разработки инженерных систем или программного обеспечения. MDD - высокоэффективный и испытанный метод управления самыми современными и сложными системными приложениями. Сочетание ALM и MDD формирует богатую среду взаимосвязанных процессов и взаимодействующих решений, что является абсолютно бесценным вкладом в дело успешного завершения проектов по разработке инженерных систем или программного обеспечения.
Нас часто спрашивают, действительно ли мы и сами пользуемся теми же инструментами, в полезности которых убеждаем других?
Другими словами, - наша точка зрения о полезности инструментов - это всего лишь рекламный ход или мы действительно "едим с вами из одной миски"?
Этот документ подробно описывает систему интегрированных процессов ALM и MDD, а также используемые технологии и инструменты компании IBM Rational / Telelogic, которые применяются производственной лабораторией Таи в рамках управления жизненным циклом разработки приложений для создания, сборки и выпуска программных средств семейства IBM Rational / Telelogic Tau.
Практика применения MDD и ALM в компании IBM Rational / Telelogic
Производственная лаборатория Таu
Производственная лаборатория Таu отвечает за разработку и поддержку целого списка различных программных средств, включая:
• IBM Rational / Telelogic Tau
• IBM Rational / Telelogic Modeler
• IBM Rational / Telelogic SDL Suite
• IBM Rational / Telelogic TTCN Suite
• IBM Rational / Telelogic Tester
• IBM Rational / Telelogic DOORS®/Analyst
• IBM Rational / Telelogic System Architect UML2 Editing Service
• IBM Rational / Telelogic Licensing Common Component
Большая часть проблем управления релизами, которые возникают у наших заказчиков, встречается и в нашей работе. Релизы для каждого из наших продуктов выпускаются, как минимум, дважды в год и это при том, что параллельно с выпускаемыми релизами осуществляется деятельность и по разработке последующих.
Лаборатория рассредоточена на большой территории, охватывающей разные часовые пояса и континенты. Если точнее, то лаборатория состоит из четырех групп, разбросанных по всему земному шару, как это изображено на рис. 1. При этом здесь не показаны некоторые вспомогательные группы специалистов, например, по товарному маркетингу, технические писатели, руководители тестировщиков, руководители по сборке и выпуску релизов, которые тоже принимают участие в нашей работе.
Рис. 1. Территориальное распределение производственной лаборатории Таи
Из-за такой разбросанности на лабораторию ложится огромная нагрузка. Для того, чтобы иметь возможность работать со всеми используемыми продуктами и технологиями, управлять разрозненными группами специалистов, учитывать график выпуска релизов всех вышеперечисленных программных средств необходимо максимально автоматизировать и интегрировать жизненный цикл разработки.
Процесс разработки
Как это видно из рис. 2, процесс разработки на верхнем уровне весьма прост. Мы применяем методологию, ставящую в главу угла работу с требованиями, включающую множество циклов, но при этом достаточно гибкую. При таком подходе для каждого запланированного релиза продуктов используется один и тот же цикл разработки, а это значит, что в любой момент времени в лаборатории существуют несколько активных циклов - на разных стадиях завершения.
Рис. 2. Схема процесса разработки
Даже в рамках одного программного продукта эти этапы накладываются друг на друга - пока завершается выпуск одного релиза, уже ведется работа над следующим. Все это еще может усложняться и тем, что реализация некоторых функций может растягиваться на несколько релизов.
С некоторой периодичностью эти плановые процессы прерываются аварийным выпуском "заплат" (patches), которые необходимы для решения возникших у заказчиков серьезных или срочных проблем. Для работы над этими неожиданно возникающими проблемами специально зарезервировано некоторое время, поскольку поддержка заказчиков есть для нас первостепенная важность.
Процесс сбора и селекции требований в общих чертах отображен на рис. 3. Требования различного рода собираются из множества источников, анализируются, приоритезируются и, наконец, нормализуются в виде списка пользовательских требований (User Requirements Document, URD).
На этом этапе широкое участие в работе принимают специалисты по товарному маркетингу и менеджеры по продуктам. Общее направление развития продукта, которое обязательно принимается во вниманиие и учитывается при селекции требований, определяется группой стратегического контроля.
Рис. 3. Сбор и селекция требований
По окончании работ над URD начинается процесс формирования релизов. Помимо менеджера по продукту, в этом процессе принимают участие руководитель проекта и архитекторы. На этом этапе первичные пожелания к продукту превращаются уже в конкретный план, детально расписывающий, что должно входить в данный релиз и каким образом это будет выполняться. Эта часть процесса изображена на рис. 4. Основным результатом этого этапа является список системных требований (System Requirements Document, SRD).
Рис. 4. Определение требований
Далее SRD используется уже как набор входных данных для фактической разработки, в процессе которой планы превращаются в законченый продукт - новый релиз Таu. Процесс выпуска релиза изображен на рис. 5.
Рис. 5. Выпуск релиза
Следует заметить, что процесс разработки, сборки и тестирования Таu происходит непрерывно. Как только заканчивается одна итерация сборки, тут же начинается другая, и при этом постоянно ведется тестирование продукта, чтобы исключить какие-либо ошибки.
Непрерывный процесс сборки ускоряет последующую интеграцию. Если разработчик выполняет check-in рано утром, то результаты интеграционной сборки и тестов он может получить уже днем. Это значительно улучшает взаимодействие в группе и повышает эффективность ее работы. Такой подход также улучшает качество продукта и снижает затраты на разработку благодаря раннему обнаружению ошибок, когда их еще можно исправить легко и без особых затрат. Мы используем термин автопилот, который достаточно полно характеризует этот подход, при котором многочисленные сборки и тесты происходят непрерывно и автоматически.
В самом начале работ руководители проекта встречаются еженедельно, чтобы контролировать выполнение проекта (его статус) и решать вопросы, связанные с внесением изменений. Ближе к завершению проекта встречи проводятся ежедневно и в режиме он-лайн, как дополнительная гарантия того, что все участники проекта будут быстро и успешно проинформированы о любых возможных изменениях.
Процесс селекции требований
Оставшаяся часть данного документа более подробно описывает предназначение каждого шага процесса разработки и объясняет как при этом используются продукты компании IBM Rational / Telelogic. Общая схема всего процесса показана на рис. 6.
Обращаем ваше внимание на тот факт, что в данном контексте Таu используется не только как продукт разработки, но и как продукт для разработки, т.е. Таu разрабатывается и поддерживается с помощью того же Таu.
Рис. 6. Основной рабочий процесс выпуска продукции
Первая фаза нового проекта по выпуску релиза начинается со сбора требований. В этом контексте под термином требование мы понимаем любой приходящий запрос (запрос на изменение - Change Request, запрос на улучшение - Enhancement Change Request, сообщение о проблеме или дефекте, или даже само требование), который в итоге должен трансформироваться в изменение, вносимое в продукт.
Дело еще в том, что у нас никогда не бывает проблем с нехваткой требований - наоборот, проблема состоит в том, чтобы суметь обработать весь объем информации и отобрать из него только те требования, которые можно или нужно реализовать в определенном релизе.
Сбор требований
Запросы на улучшение и изменение продуктов семейства Таu приходят и формируются из самых разных источников:
• Регулярные конференции ведущих заказчиков
• Совет руководителей направлений по продуктам
• Анализ продаж
• Конкурентная информация
• Подразделения поддержки заказчиков, сообщения о неисправностях
• Потребности бизнеса
• Стратегические коммерческие требования
• Требования к технологии
• Товарный маркетинг, управление продуктами
• Архитекторы и разработчики
• Ранее отложенные требования
Одним из наиболее очевидных источников поступления новых требований являются подразделения поддержки заказчиков (Customer Support). Здесь все входящие запросы раскладываются по двум "корзинам": сообщения о найденных дефектах идут в одну корзину, а запросы на улучшение, содержащие пожелания о новых функциях или усовершенствовании уже существующих, - в другую.
Другим источником - возможно, не столь очевидным, но весьма важным - является анализ потребностей бизнеса. Это происходит тогда, когда руководители по продажам и менеджеры по продукту принимают совместные решения о реализации или улучшении каких-либо определенных характеристик и функций, чтобы удовлетворить нужды заказчиков или повысить уровень продаж.
Регулярно проводимые конференции ведущих заказчиков собирают большинство основных пользователей продукта Таu и также являются важным источником запросов в отношении продукта. Представители разных компаний периодически встречаются с руководителями по продукту Таu, чтобы обсудить будущие требования к продукту и приоритезировать их.
Совет руководителей направлений по продуктам существует с той же целью; но его единственное отличие лишь в том, что он является внутренней структурой компании IBM Rational / Telelogic и на встречах совета мнениями обменивается высший управляющий персонал компании. Работа этих двух групп обеспечивает пользователям продукта Таu преимущественное право голоса в процессе его разработки.
Специалисты по товарному маркетингу и менеджеры по продукту формируют стратегические требования к продукту и контролируют весь процесс его развития. Стратегические требования основываются на:
• Взаимодействии с активными специалистами по продажам
• Анализе тенденций рынка
• Определении новых рыночных потребностей
• Изучении конкурентной среды
• Общих стандартах, устанавливаемых различными стандартизирующими органами и государственными организациями
• Корпоративном стратегическом направлении, определяемом исполнительным органам компании IBM Rational / Telelogic.
Появление на рынке новых технологий, - например, новой платформы Vista или новой рабочей среды Java ЕЕ 5, - зачастую также оборачивается новыми требованиями к продукту.
Все эти разного рода требования из любых источников собираются, фиксируются и обрабатываются в инструменте, который носит название IBM Rational / TelelogicFocalPoint. Пример окна Focal Point для ввода требования показан на рис. 7.
Рис. 7. Запись требований в Focal Point
Члены Совета руководителей и менеджеры по продукту Таu хорошо знакомы с Focal Point и широко используют это решение для управления продуктом и портфелем продуктов, а также для приоритезации определенных характеристик Таu и требований к нему.
Приоритезация функционала
Поскольку запросов на внесение в продукт нового функционала и исправление обнаруженных дефектов всегда так много, что реализовать их в один заход просто невозможно, то следующим шагом является приоритезация поступивших запросов с тем, чтобы определить - какие именно из них будут включены в последующие ближайшие релизы Таu.
Одним из наиболее эффективных методов приоритезации, который предлагается Focal Point, является метод сравнений (сопоставлений), при котором все требования сравниваются попарно и вы и ваши коллеги сами решаете, какое из двух более важно и имеет больший приоритет.
В рамках конференций или встреч с ведущими заказчиками руководители разных уровней часто проводят семинары, на которых одним из заданий является попарная приоритезация с помощью этого метода. Маркетологи и менеджеры по продуктам также постоянно используют этот метод. На рис. 8 показан пример использования метода сопоставлений, который по сути своей является привычным голосованием.
Рис. 8. Попарная приоритезация требований в Focal Point
После всеобщего "голосования" и подведения итогов голоса обрабатываются, взвешиваются и конечный результат отображается в том или ином варианте, один из которых продемонстрирован на рис. 9.
Рис. 9. Демонстрация взвешенных результатов приоритезации требований в Focal Point
Конечным результатом применения этого метода является приоритезированный список всех потенциальных пользовательских требований, с которыми следует продолжать работать.
Создание и ведение списка пользовательских требований
Приоритезированные пользовательские требования используются далее либо для пополнения URD, который поддерживается IBM Rational / Telelogic DOORS, либо для обновления в нем имеющихся данных, поскольку в URD уже содержатся требования, оставшиеся от предыдущего релиза, а также требования, уже распределенные по будущим релизам. Все эти требования затем фильтруются и уточняются с целью планирования текущего релиза.
В процессе распределения требований по релизам каждому выбранному пользовательскому требованию ставится в соответствие атрибут, указывающий к какому релизу оно относится. Этот процесс относится и к требованиям, которые ранее были отложены по каким-либо причинам.
Используя этот атрибут, имеющийся в DOORS функционал обеспечивает формирование специального вида, который, например, может быть настроен на отображение лишь тех пользовательских требований, которые относятся к интересующему вас определенному запланированному релизу.
Пример отображения пользовательских требований к Таu для одного из конкретных релизов приведен на рис. 10.
Рис. 10. Отображение URD в DOORS
Следует отметить, что URD представляет собой основной набор входных данных для последующего процесса формирования релизов.
Процесс формирования релиза и проектное планирование
Как только пользовательские требования становятся доступными для последующей работы, в дальнейший процесс активно вовлекается производственная лаборатория. Так, например, архитекторы анализируют требования с точки зрения их затратности и выполнимости. В процессе анализа могут создаваться вспомогательные документы, объединенные названием "предварительные исследования", которые могут содержать наброски проектной информации и первичные решения, а также иную информацию, которая затем может понадобится остальным членам команды.
Результаты этих предварительных исследований хранятся в IBM Rational / Telelogic Synergy - системе управления конфигурацией - и автоматически реплицируются на внутренний веб-сайт проекта (подробнее об этом далее).
Важной характеристикой этого этапа является определение временных затрат, которые могут потребоваться на реализацию каждого конкретного требования. Это время всегда очень приблизительно и оно всегда выражается в часах, даже если на разработку потребуется несколько недель. Когда в ходе работы над проектом потребуется соотнести имеющееся в наличии свободное рабочее время с набором характеристик или функций продукта, которые требуется реализовать, эти цифры будут играть чрезвычайно важную роль.
После того, как пользовательское требование соотнесено с релизом, его необходимо детализировать в одно или несколько системных (или иных вторичных) требований. Зачастую для этих целей в Таu используется моделирование, которое позволяет более четко представить, что - с технической точки зрения - может понадобится для реализации данного требования.
На рис. 11 приведена простейшая модель, как составная часть предварительных исследований такого рода.
Рис. 11. Моделирование в Таи для предварительных исследований
В процессе определения системных требований формируется трассировка - построение связей между системными и соответствующими пользовательскими требованиями. На этом этапе для каждого системного требования также определяются и факторы риска, потому что, например, реализация некоторых требований напрямую может зависеть от выполнения других требований.
Набор системных требованиий, отнесенных к определенному релизу, образует SRD (System Requirements Document).
После получения списка системных требований менеджеры по продуктам, руководитель проекта и главный архитектор внимательно его прорабатывают, выясняя, имеет ли смысл реализовывать все отобранные требования и впишется ли разработка в выделенный бюджет. Кроме того, группа стратегического контроля управляет общей стратегией по каждому продукту и помогает руководить процессом выбора требований.
В результате такого мозгового штурма появляется "итоговый" SRD проекта. Следует заметить, что обычно в последующем процессе разработки и сам SRD претерпевает изменения, но данный процесс управляется уже отдельно. (Пример SRD представлен на рис. 16).
В соответствии с итоговым SRD разрабатывается план и график выпуска релиза (рис. 12).
Рис. 12. График выпуска релиза
Для улучшения обмена информацией в процессе работы, непосредственно перед запуском проекта создается специализированный внутренний Веб-портал, содержащий всю информацию, имеющую отношение к данному проекту, - предварительные исследования, требования, модели, результаты тестов и т.д. На рис. 13 представлен пример заглавной страницы такого внутреннего сайта.
Рис. 13. Домашняя страница проекта
Теперь обратим внимание на структуру производственной лаборатории.
Общее представление о подразделениях лаборатории Таu и их предназначении можно получить из рис. 14.
Рис. 14. Структура производственной лаборатории Таи
Хочется обратить ваше внимание на тот факт, что в нашей лаборатории за наличие всех требований, необходимых группе разработчиков для завершения своей работы, несет ответственность подразделение архитекторов.
Разработка программного обеспечения
Разработка продукта Таu протекает в рамках технологического процесса, который хранится и контролируется IBM Rational / TelelogicChange- решением для управления изменениями, - разработанным компанией IBM Rational / Telelogic.
Отправной точкой этого процесса является формирование, - исходя из системных требований, - запросов на изменения (Change Requests, CR), в которых формулируется и определяется что именно должно быть разработано. CR также используется для контроля за текущим статусным состоянием изменения.
Наиболее важные состояния процесса управления изменениями изображены на рис. 15.
Рис. 15. Процесс изменений
Как видно, процесс состоит из пяти основных состояний (статусов), присущих любому запросу на изменение:
• Entered ( Поступил )
• Confirmed ( Подтвержден )
• Implementation ( Выполняется )
• Fixed ( Решен )
• Verified ( Проверен )
Первые два соотносятся, в большей степени, с областью управления проектом, а остальные - с областью разработки продуктов.
Этот жизненный цикл управления изменениями един и для всех других производственных лабораторий компании IBM Rational / Telelogic, которые используют Change.
Управление дефектами
Когда со второй линии пользовательской поддержки (от инженеров, принимающих звонки в Центре поддержки компанииIBM Rational / Telelogic) поступает информация о предполагаемом дефекте, то из нее сразу же формируется запрос, которому тут же присваивается статус "Поступил".
Если третья линия поддержки, - перепроверив поступившую информацию, - подтверждает, что дефект на самом деле существует, то статус CR меняется на "Подтвержден" (или "Дублирован", если эта информация уже поступала ранее). Если же наличие дефекта не подтверждается, то запрос на изменение переводится в разряд "Отклонен". Если случается так, что запрос приходит в форме вопроса, то после ответа ему присваивается статус "Отвечено". Следует заметить, что сведениям о дефектах и запросам на улучшение функционала продукта присваиваются разные коды (атрибуты) в целях независимого их отслеживания, сбора метрических данных, последующей отчетности, любой другой обработки.
На своих еженедельных собраниях специальный Совет по запросам на изменения примеряет CR к находящимся в разработке релизам и решает, - будет ли обнаруженный дефект исправлен в текущем релизе или это будет отложено до более позднего релиза.
Перед тем, как принять решение о переводе CR в разряд "Выполняется", обязательно просчитываются возможные риски и затраты. Помимо возможной задержки выпуска текущего релиза, во внимание принимается и множество других факторов, которые могут оказывать влияние на это решение, например, - значимость изменения, влияние изменения на другие модули, которые тоже надо будет редактировать, придется ли обновлять формат хранения данных, существует ли вероятность потери данных и т.д.
Поэтому чем ближе дата выпуска текущего релиза, тем меньше шансов, что CR будет в нем реализован. Скорее всего этот CR будет либо переведен в разряд "Отложен" и ждать своего часа, либо будет реализован только в следующем релизе, разработка которого обычно ведется параллельно с текущим.
Вполне возможно возникновение такой ситуации, при которой исправление дефекта требует длительного времени, но значимость этого настолько велика, что реализацию CR нельзя откладывать. В этом случае возникает необходимость корректировки графика выпуска релизов. Информация об изменениях в расписании релизов обязательно доводится затем до сведения всех заинтересованных лиц - производственных групп и стратегических советов.
Запросы на улучшение и новый функционал
В отличие от запросов, связанных с неисправностями и "сваливающихся" всегда неожиданно, реализация пользовательских запросов на улучшение или реализацию новых функций продукта обычно планируется заранее.
Такого рода CR формируются менеджером по продукту, исходя из требований в SRD, и только лишь после принятия решения о включении их в релиз статус этих запросов может меняться на "Подтвержден". При формировании списка из новых запросов, которые предполагается включать в релиз, анализируются и ранее отложенные CR, имеющие статус "Отложен", и те из них, которые выбираются для реализации, также меняют свой статус на "Подтвержден".
При планировании будущих релизов менеджер по продукту, руководитель разработки и менеджер проекта полностью отвечают за включение в проект тех или иных запросов, решая свою главную задачу - выпуск продукта в установленные сроки и надлежащего качества. Все CR, выбранные для включения в релиз, затем следуют обычным для всех запросов путем, как это описанно выше.
На рис. 16 показан SRD, в котором хранятся системные требования, из которых впоследствии формируются запросы для включения в релиз.
Puc. 16. Отображение SRD в DOORS
После формирования запросов статус любого из них можно легко проследить в Change. Автоматическое и наглядное отображение информации о статусе любого CR, которое дает Change (см. рис. 17), существенно облегчает жизнь разработчиков и архитекторов, снижая их потребность в создании специализированных отчетов.
Рис. 17. Отображение списка запросов в Change
И хотя приведенный выше журнал (отчет) отражает информацию лишь "верхнего" уровня, но при необходимости по каждому конкретному CR может быть получена и более детальная информация, например, - ссылка на исходное системное требование, скрипт входящего сообщения (звонок, mail), комментарии о конференциях пользователей и многое другое (см рис. 18).
Любой участник процесса может добавить в этот журнал информацию или приложить файлы, необходимые для понимания обсуждаемой проблемы и ее решения. Однако журнал защищен и открывается в нередактируемом режиме, так что вся история внесенных изменений обязательно сохраняется. Иногда из-за этого журнал становится очень "толстым"!
Puc . 18. Подробная информация о CR ' e Change
Создание заданий на разработку
Вслед за переводом CR в статус "Выполняется", формируется задание на разработку, выполнение которой находится под полным контролем IBM Rational / Telelogic Synergy - решения для управления конфигурацией.
Synergy очень тесно интегрирован с Change, так что задача (task) автоматически связывается с CR и в дальнейшем отслеживается только в ассоциации с ним. С одним CR может быть связано несколько задач, если большой объем работ необходимо разделить на более мелкие элементы или поручить решение проблемы несколькими разработчиками. С этого момента ответственность за продолжение работ над CR (выполнение поставленных задач) переходит уже к архитекторам и разработчикам.
Процесс реализации CR можно отслеживать в Change (см. рис. 19).
В окне Change отображается информация и о любых других артефактах, которые ассоциируются с выполнением задания (вплоть до изменений исходного кода), если в них вносились изменения или они заново создавалась разработчиком. Обратите внимание на то, что в нижней части окна Change автоматически регистрирует файлы, в которые разработчиком вносились изменения, необходимые для реализации данного CR.
Потом, когда CR будет реализован и сменит статус на "Проверен", входящие в него задачи (tasks) становятся частью процесса сборки (build). Благодаря такому подходу можно легко удалить из процесса сборки любые файлы (изменения), относящиеся к данному CR, если позже в нем все-таки будут вдруг обнаружены ошибки.
Рис. 19. Задание в Change
Возможность работать и отслеживать изменения вышеописанным способом значительно облегчает ведение параллельной разработки. Если, например, какой-либо CR нуждается в срочной заплатке (patch), то для решения этой проблемы менеджер сборки формирует новую задачу (task), -создавая ответвление от основного процесса разработки, - которая потом автоматически "подтянет" в сборку все требуемые файлы.
Такой метод контроля за CR автоматизирует поиск информации (отчетность) о том, что находится в сборке (или, - что иногда более важно, - что не находится в сборке). Например, если группа тестировщиков точно знает, что именно находится сейчас в стадии сборки, они будут тестировать лишь тот функционал, которые разработчики и архитекторы уже реализовали, и не терять время, сообщая о неисправностях или отказах при испытаниях, проверяя еще нереализованные функции.
В качестве дополнительного преимущества эта технология предоставляет нам возможность автоматически выполнять анализ сквозной трассировки. Если код находится в файле, который привязан к задаче (task), а она, в свою очередь, залинкована с CR, и при этом CR может быть прослежен до системного требования, которое связано с пользовательским требованием (и возможно, даже с изначально зарегистрированным обращением пользователя по телефону в Центр поддержки), то такая цепочка позволяет найти все артефакты, получившиеся из пользовательского требования или запроса в процессе разработки.
Цикл разработки
Фактически, на цикл разработки приходится три состояния CR:
• Implementation {Выполняется), во время которого разрабатываются код и модели
• FixReadyForReview (Решение готово к рассмотрению), когда реализация CR выполнена и дожидается проверки и одобрения архитектора
• Fixed (Решен), который говорит тестировщику, что реализация CR одобрена группой разработчиков и CR готов к тестированию
Если при этом, находясь в состоянии "Решение готово к рассмотрению", CR по каким-либо причинам не получает одобрения, то ему вновь возвращается статус "Выполняется".
Следует заметить, что на этих последних стадиях разработки статус "Решение готово к рассмотрению" должен присутствовать и использоваться в обязательном порядке - CR не может из разряда "Выполняется" сразу перепрыгнуть в разряд "Решен". Такой подход дает некоторую уверенность в том, что в последний момент ничего не будет разрушено случайной ошибкой.
Важным моментом является тот факт, что на стадии разработки единственный доступ к коду - как выполнение поставленного задания - возможен исключительно через задачи (task) в Synergy (см. рис. 20). Как только выполнение задачи завершается, соответствующие коды фиксируются и версии файлов автоматически проходят операцию check-in, чтобы затем включиться в процесс следующей интеграционной сборки.
Рис. 20. Окно Synergy - задачи ( tasks ), запросы ( CR ), проекты, файлы
Руководители проекта и менеджеры по продукту легко отслеживают текущее состояние разработки благодаря автоматически создаваемым отчетам о деятельности команды, как это показано, например, на рис. 21.
Такого рода отчеты отображают полную трассировку: требования в SRD - файлы, содержащие исходные код, в который вносились изменения, - автоматически собираемые базовые версии (baselines) продукта, в которых появляется реализованное изменение.
Puc . 21. Отчет о деятельности группы
На протяжении всего процесса разработки непрерывно ведется параллельная сборка (build) для всех поддерживаемых платформ. Этот автоматический процесс описывается ниже.
Моделирование, код, спецификации
Для разработки большинства своих продуктов производственная лаборатория Таи использует язык C++. В целях обеспечения совместимости разработок с различными платформами в лаборатории принят при нци п платформо-независимого программирования. Основной используемой средой разработки является Microsoft Visual Studio 2005.
Во многих случаях - и это особенно актуально, если речь идет об объектной модели, - код автоматически генерируется напрямую из UML® с помощью IBM Rational / TelelogicTau, в состав которого входит кодо-генератор C++.
Кодогенерация, будучи основой Таu, находит свое отражение во всех пользовательских интерфейсах продукта, программных интерфейсах приложений (API) и даже в самом представлении UML, используемом Таu.
Например, все программные интерфейсы API продукта сгенерированы из UML, включая TCL, C++ и COM API. Помимо этого, генерация кода задействуется и в тех опциях Таu, которые ориентированы на работу с состояниями, например, при запуске опции Model Verifier для проверки правильности функционирования создаваемой модели.
И более того, Таu позволяет значительно уменьшить процент рутинной работы по документированию, - автоматизируя создание сопутствующей документации из объектной модели.
Все возможные представления (виды) моделей в Таu, включая и элементы графической нотации самого UML, создаются с помощью UML-моделей, как это показано для одного из случаев на рис. 22.
Рис. 22. Объектная модель в Таи
Эти модели называют метамоделями, поскольку они управляют работой самого Таu, поясняя ему что именно во время исполнения программы инструмент должен отображать, как задействовать и интерпретировать артефактам модели и использовать их. По сути эти метамодели служат неким фильтром, позволяющим увидеть лежащую в их основе объектную модель.
Например, метамодель способна контролировать типы диаграмм, которые могут быть отображены, их название и содержание, а также меню, вид панели инструментов и палитры элементов, которые сопровождают эти диаграммы. Модели также контролируют суть иерархического дерева модели - что на нем отображается, как дерево сформировано, а также что может быть создано и что может храниться в каждом из элементов.
В Таu включены и многие другие представления, например, поддерживающие DoDAF, SysML или некоторые другие представления, характерные для языка Java или различных технологий на основе XML - например, схемы или язык описания Веб-сервисов (WSDL). Эти представления уже встроены в Таu, поставляются с продуктом и в дальнейшем их можно кастомизировать для удовлетворения конкретных потребностей пользователей.
В нашей производственной лаборатории Таu также используется и для визуализации существующего или вновь создаваемого кода с целью последующего анализа и документирования. В этом случае производится реинжиниринг кода C++ и файлов Microsoft SLN, в результате которого создаются диаграммы, отображающие взаимосвязи различного рода. На рис. 23 показано несколько диаграмм, полученных прямым реинжинирингом кода C++.
Рис. 23. Код C++, визуализированный в виде диаграммы классов
Код, прошедший реинжиниринг, обычно дополняется описаниями определенных взаимодействий или характеристик и свойств состояний, как показано на рис. 24.
Рис. 24. Диаграмма состояний
Поскольку разработка продукта распределена по континентам и временным зонам (см. рис. 1), то использование системы управления конфигурацией чрезвычайно важно - можно даже сказать, критично - и для моделей, и для кодов, и для любых спецификаций. Для этих целей производственная лаборатория выбрала Synergy, поскольку выдающиеся возможности этого продукта позволяют поддержать работу географически распределенных команд и обеспечить автоматическую синхронизацию баз данных в фоновом режиме. При этом совместное использование Synergy и Change позволяет улучшить контроль за разработками и повысить эффективность взаимодействия благодаря использованию функционала, как раз поддерживающего работу распределенных групп.
Каждый разработчик несет полную ответственность за получение положительного результата блочного и некоторых видов интеграционного тестирования, прежде чем изменение, над которым они работали, будет отнесено к разряду "Решение готово к рассмотрению".
Выпуск продукта, тестирование, управление релизами
Сборки (builds) ведутся непрерывно для всех поддерживаемых платформ, включая Windows, Solaris и Linux. Процесс сборки управляется из Synergy.
После удачного завершения сборки всем членам команды рассьшается электронное уведомление с информацией о статусе сборки, сопровождаемое ссылками на файлы инсталляции, отчетами об изменениях, отчетами по задачам и прочей важной информацией (см. рис. 25).
Puc. 25. Уведомления о статусе сборки
Каждую сборку сопровождает собственный журнал и, если что-то в процессе сборки идет не по плану, сообщение об этом ответственные разработчики получают по электронной почте. Более того, для каждого отдельного проекта автоматически создаются Веб-страницы, где любой желающий может ознакомиться с текущим статусом сборки.
Тут же содержатся и ссылки на подробные отчеты о том, что включено в сборку (см. рис. 26).
Puc. 26. Результаты сборки
В журнале сборки также содержится информация о том, какие задачи (tasks) были выполнены в составе каждой конкретной сборки. Эта информация, в частности, весьма полезна для тестировщиков, поскольку подсказывает им, какие функции уже готовы к проверке (см. рис. 27).
Puc . 27. Список завершенных задач конкретной сборки
Эта информация может быть также полезна любому человеку, который хочет испытать какую-либо интеграционную сборку или продемонстрировать работающую сборку заказчику, если нужен отзыв о промежуточном результате или работе вновь созданной функции.
После каждого успешного - и это обязательное условие - завершения сборки для конкретной платформы автоматически запускаются многочисленные последовательности тестов, результаты прогонов которых также публикуются на Веб-страницах, связанных с проектом. Рис. 28 как раз и демонстрирует одну из таких страниц, на которой отображены результаты тестов для различных сборок и различных плаформ.
Рис. 28. Результаты тестирования
Если тестировщик считает, что конкретный CR был действительно реализован и удовлетворяет первичным требованиям, то CR переводится в статус "Проверен", что однозначно трактуется как факт завершения работ и готовности включения CR в очередной пользовательский релиз. На завершающем этапе статус "Проверен" должны иметь все CR. В противном случае те из них, что не могут быть вовремя проверены перед включением в релиз, должны иметь письменное мотивированное объяснение, почему этого не призошло.
Новая базовая версия (baseline) продукта будет создана только лишь после подтверждения успешного завершения сборки. Такой подход улучшает производительность, упрощает будущие сборки и оптимизирует различные запросы.
Поскольку автоматическое тестирование не может полностью охватить все возможные сценарии, то во всех проектах, связанных с выпуском релизов, ближе к их завершению стартует, так называмая, тестовая кампания, в рамках которой для выполнения многочисленных тестовых сценариев и исследовательских испытаний даже нанимается временный персонал. Такое широкое тестирование включает в себя не только различные проверки пользовательских интерфейсов по утвержденным сценариями, но и тестирование самых разнообразных специфических ситуаций, которые могут иметь место. Иногда, если в релиз включаются существенные изменения, может быть организована даже более, чем одна тестовая кампания.
Кроме этого существуют и эксплуатационные (так называемые, полевые) программы тестирования, в которых принимают участие опытные инженеры и консультанты по приложениям. В ходе таких испытаний заранее отобранным заказчикам предоставляется бета-версия программы с целью выявления в ней потенциальных проблем в эксплуатационном режиме.
Ближе к завершению проекта определяются релиз-кандидаты для включения их в финальный релиз и проводится интеграционное тестирование. На этой стадии внесение каких бы то ни было изменений контролируется особенно тщательно.
После формирования финальной версия релиза, в заранее назначенный день он выгружается на Веб-сайт поддержки ( https :// support . telelogic . com ) и становится доступным для использования. Большая часть относящихся к релизу документов - комментариев, документации, описаний решенных проблем, возможных ограничений использования - генерируются автоматически, исходя из данных, хранящихся в Change.
Заключение
Производственная лаборатория Таu ведет большую работу, одновременно разрабатывая несколько продуктов, несколько их версий, под несколько языков, для разных платформ. Для выполнения этой работы в условиях распределенной среды, когда ресурсы расположены в разных точках и временных поясах земного шара, с максимальным объемом параллельной сборки и максимальной частотой автоматического тестирования, абсолютно необходима высочайшая степень автоматизации всех работ.
Для обеспечения требуемого уровня автоматизации разработки производственная лаборатория Таи использует целый ряд решений, включающих в себя в том числе и продукты IBM Rational / Telelogic:
• Таu для разработки на основе моделей, генерации кода и документации;
• FocalPoint для управления и приоритезации разрабатываемого функционала;
• DOORS для управления требованиями;
• Changeдля контроля за изменениями;
• Synergy для управления конфигурацией и сборкой;
• Logiscope для соблюдения стандартов качества кода, получеия метрик кода и отчетности.
Совместное использование MDD (Model-Driven Development) и ALM (Application Lifecycle Management) позволяет компании IBM Rational / Telelogic, - поддерживая высокую производительность и эффективность, - разрабатывать и поддерживать целую линейку продуктов, прекрасно зарекомендовавших себя на рынке в разных индустриях.