Рубрики

Свежие записи

Разработка прикладного программного обеспечения с использованием RUP на Иркутском Авиационном заводе. Черновой вариант

GD Star Rating
loading...
GD Star Rating
loading...




На сайте СМ-Консалт мы недавно открыли раздел саксес-стори, в сами котором заказчики описывают процесс внедрения методологии и инструментов IBM или Microsoft, говорят о достигнутых результатах и прочем. Идея не новая, но мы до этого публиковали только отзывы о внедрении, которые нам подписывали заказчики после выполненного проекта. Наверное, нам повезло с заказчиками — трудностей в получении отзывов никогда не было. Возможно, и потому, что и больших проблем не было на этапе внедрения :) Так вот, во вновь открытом разделе мы опубликовали статью Иркутского Авиа-Завода Разработка прикладного программного обеспечения с использованием Rational Unified Process на Иркутском Авиационном заводе — http://cmcons.com/articles/success_story/IAZ/

Это уже выверенная статья, подготовленная к внешней публикации. Но сама статья прошла несколько интересных метаморфоз: сначала мы я, Евгений Гаран и Галина Карабановаготовили некий материал о внедрении, потом выяснилось, что ИАЗ сам пишет статью о внедрении RUP. В итоге все свои черновые материалы мы передали в Иркутск и сотрудники ИАЗ выпустили две версии  материала: финальную (которая размещена на сайте СМ-Консалт) и черновую (представленную вашему вниманию).

Мне кажется, что в черновом варианте есть несколько интересных аспектов. только потому я ее решился опубликовать в своем блоге. Смотрите обе версии, высказывайте мнения :) Черновик не правил… так что возможны Ашипки и ачипятки…

Предпосылки внедрения

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

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

В результате анализа проблем было принято решение перестроить процесс разработки таким образом, чтобы разработку продукта можно было делать по частям. Выбор пал на итерационный подход к разработке ПО. К моменту выбора процесса наиболее развитым и полным являлся процесс от IBM Rational – RUP.

Подходы к внедрению

Для получения корпоративного стандарта была выбрана следующая модель агрегации лучшего:

Основой корпоративного стандарта стал RUP 2001А, в частности: итерационный подход, состав фаз и дисциплин и так далее (Таблица 1).

В дополнение к методологии RUP, при внедрении, учитывались требования модели качества CMMI уровней 2-3 для получения конечных целей, ориентированных на качество процесса.

Отдельные позиции были взяты из стандарта ИСО МЭК12207 и руководства по его внедрению, так как ИСО 12207 имеет статус стандарта, как в РФ, так и в мире, и содержит важные рекомендации по имплементации, которые достаточно хорошо сочетаются с RUP.

Отдельно были рассмотрены ГОСТы 34 и 19, но только в разрезе содержания формальных документов: Техническое задание и Программа и Методика Испытаний

Таблица 1. Компоненты процесса и их источники

Источник

Компонент

RUP

Итерационность

Управление рисками

Проектная и организационная структура

Шаблоны документов

Инструменты поддержки процесса

Инструкции по использованию инструментов

Метрики

CMMI

Требования к процессу

Контрольные точки

Эталонные ориентиры

ISO 12207

Общие требования к процессу

Детализация вспомогательных процессов

Формализация подхода внедрения методологии

Рисунок 1. Составляющие внедрения

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

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

Рисунок 2 — Структура и состав документов

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

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

Выбор подхода к внедрению

ИСО МЭК 12207 определяет два типа внедрений: горизонтальное и вертикальное (см. Рисунок 3):

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

Рисунок 3. Горизонтальное и вертикальное внедрение

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

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

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

 

Очередность внедрения

ИСО МЭК 12207 и Rational Unified Process накладывают определенные ограничения в порядке внедрения дисциплин, но оставляют определенную свободу действий.

Все дисциплины RUP делятся на 2 типа: основные и вспомогательные.

Основные дисциплины внедряются в строгой последовательности

Вспомогательные могут быть внедрены как до основных, так и вместе с ними

В результате очередность внедряемых дисциплин выглядела так:

  • Управление требованиями, анализ и проектирование
  • Параллельно с небольшим смещением во времени управление конфигурациями и среда
  • Тестирование
  • Развертывание

Рисунок 4. Внедрение на практике.

По оси Х выстроена временная шкала пилотного проекта. По оси У внедряемые дисциплины. Смещения дисциплин показывают порядок их внедрения. Затемненная часть ряда дисциплин показывает привлечение консультантов.

Выбор пилотного проекта

При выборе проекта и команды для пилота учитывались следующие критерии:

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

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

 

Для проведения пилотного проекта была создана рабочая группу из сотрудников следующих подразделений:

  • отдела системного моделирования и поддержки ИТ-проектов
  • отдела автоматизации систем управления конструкторской и технологической информации.

 

Цели и задачи пилотного проекта

Цели:

Были выработаны следующие цели пилотного проекта:

  • Отработать на примере проекта по подсистеме НСДД основные процессы жизненного цикла разработки по .
  • Создать предпосылки для повышения эффективности и прозрачности процессов разработки, тестирования и сопровождения ПС.
  • Отработать технологию и методы построения прозрачного и управляемого процесса разработки ПС.
  • Отработать технологию переноса существующих проектных данных и материалов в новую технологическую среду.
  • Продемонстрировать работоспособность предлагаемых решений на базе IBM Rational в условиях ИАЗ.
  • Сформировать основы нормативно-методического обеспечения процесса разработки ПС.
  • Сформировать технологическую базу для внедрения средств автоматизации IBM Rational в ИАЗ.

Задачи пилотного проекта:

Для достижения целей пилотного проекта предполагалось выполнить следующие задачи:

  • Создать полный архив материалов проекта (проектный Репозиторий);
  • Разработать Нормативно-методическое обеспечение (НМО) для каждого процесса, используемого в пилотном проекте, в составе следующих документов:
    • Положение по порядку управления по каждому процессу;
    • План управления Конфигурациями и Изменениями;
    • План управления требованиями;
    • План тестирования;
  • Создать и утвердить механизм контроля внесения изменений, обеспечивающий:
    • возможность ускорения процесса разработки и внесения изменений за счет параллельной работы исполнителей с одними и теми же материалами;
    • определение узких мест проекта и своевременное перераспределение ресурсов для их устранения;
    • использование критериев определения текущей загрузки исполнителей по заданиям и поручениям
      и
      анализ их производительности.
  • Создать и утвердить механизм управления версиями и релизами, в том числе:
    • Разработать и утвердить схему управления релизами и версиями ПС;
    • Разработать скрипты политик процесса и доступа к репозиторию.
  • Создать и утвердить механизм управления требованиями, в том числе:
    • Описать концепцию Системы НСДД в терминах требований к ПС;
    • Сформировать требования методом реверс-инжиниринга;
    • Обеспечить основу для планирования итераций проекта;
    • Обеспечить анализ требований, сценариев использования и формирование тестовых требований.
  • Создать и утвердить механизм проведения функционального тестирования, в том числе:
    • Регламентировать процедуры тестирования ПС на основе утвержденных требований;
    • Разработать критерии успешности тестирования и его завершения;
    • Определить и разработать шаблоны  документов тестирования;
    • Определить методы подготовки данных для тестирования;
    • Разработать спецификации тестовых процедур и наборы тестовых данных;
    • Создать автоматизированные скрипты функционального тестирования;
    • Сформировать отчеты о ходе тестирования;
    • Обеспечить развертывания стенда тестирования.
  • Обучить специалистов, участвующих в пилотном проекте, практике использования предлагаемых технологий.

 

Оснащение АРМ

Для задач пилотного проекта предлагается установить на АРМ участников следующие комплекты инструментальных средств IBM Rational:

Рисунок 5.  Комплектация АРМ средствами IBM Rational (перерисовано по представленному списку, список удалил, так как он повторяет рисунок)

Привлечение консультантов

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

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

В качестве достижений можно было отметить наличие подразделения, отвечающего за поддержку процессов проектного управления. Процесс проектного управления в достаточной степени не анализировался, однако можно было сказать, что они в организации поддерживаются, используется инструментальное средство проектного управления. Это же подразделение несет ответственность за разработку регламентов верхнего уровня процесса разработки. Было отмечено использование в пилотном проекте итеративного подхода к процессу разработки, практическое применение процессов «Управление требованиями», «Анализ и проектирование». Для этих процессов были разработаны и применялись на практике нормативные документы, использовались инструментальные средства.

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

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

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

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

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

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

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

Консультантами было предложено провести дополнительный комплекс работ по интеграции средства УИ ClearQuest со смежными системами: системой проектного управления Open Plan и подсистемой управления инцидентами Remedy. Однако, было решено, что необходимость этих работ будет оценена по результатам эксплуатации имеющихся инструментальных средств в зависимости от объема перетекающей между системами информации.

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

 

Проблема К чему приводила Реализованное решение
1 Cхема ClearQuest не отвечает требованиям процесса Не используется средство управления изменениями ClearQuest Доработана схема
2 Отсутствует связь между инструментом управления требованиями и инструментом УИ Нет возможности понять какие требования по запросу сформированы.
Нет связи задачи и требований по задаче
Настроена интеграция ClearQuest и RequisitePro
3 Нет интеграции инструментария УИ и средства управления проектами Сложность синхронизации информации между инструментариями УИ и управления проектами По результатам эксплуатации систем оценить необходимость разработки средства автоматической синхронизации
4 ClearCase развернут на контроллере домена Нестабильная работа ClearCase.
Медленная работа ClearCase
Развернут специализированный сервер для инструментальных средств
5 Отсутствует выделенное подразделение тестирования и управления качеством Недостаточное качество тестирования.
Качество ПО становится второстепенной проблемой проекта.
Сформировано выделенное подразделение тестирования
6 Проведение тестирования на сервере разработки, а не в специализированной среде тестирования
Отсутствуют средства автоматизированного тестирования
Сложность подготовки данных для тестирования
Отсутствует регрессионное тестирование
Развернуты средства автоматизированного тестирования, разработаны регламенты тестирования, разработаны скрипты автоматизированного тестирования
7 Не используется инструментарий УИ (как средство багтрекинга), протоколы тестирования не сохраняются Процесс исправления дефектов не прозрачен.
Не проводится анализ выявленных дефектов ПО. Тестирование проводится до устранения всех ошибок, однако много ошибок выявляется в процессе эксплуатации
Схема ClearQuest доработана с учетом багтрекинга, разработан регламент процесса, разработан комплект отчетов для анализа дефектов.
8 Отсутствует связь между версионным хранилищем и процессом управления заданиями Сложно определить в связи с чем изменен исходный код ПО Настроена интеграция ClearQuest и ClearCase.
9 Нет единой технологии контроля версий При возрастании числа проектов или росте размера проекта падает управляемость, при исправлении ошибок тратится слишком много времени на поиск файлов для внесения исправлений;
Сложно оперативно вносить изменения в ПС;Не возможно распараллелить работу по одним и тем же файлам, что удлиняет сроки работ
Сформирована единая структура хранилищ для проектов
Доработан план управления конфигурациями
10 Отсутствие интеграции инструментального средства УИ и инструментального средства Remedy Потеря дефектов от пользователей, поступающих из системы Remedy По результатам эксплуатации систем будет принято решение о необходимости разработки инструментального средства интеграции
11 Качество требований недостаточное
Качество проектирования недостаточное
Организация документирования процесса разработки поставлена в недостаточной степени, и отсутствие любого ключевого сотрудника сказывается на общей успешности разработки Разработаны регламенты верификации требований и моделей разработчиками и тестировщиками на предмет полноты и тестируемости.

 

Результаты проекта

Этот раздел в черновике был пуст. В финальной же версии статьи все присутствует. Читайте далее Разработка прикладного программного обеспечения с использованием Rational Unified Process на Иркутском Авиационном заводе — http://cmcons.com/articles/success_story/IAZ/

 

Разработка прикладного программного обеспечения с использованием RUP на Иркутском Авиационном заводе. Черновой вариант, 10.0 out of 10 based on 1 rating

Связные и просто интересные записи:

Метки:ibm, rational, бизнес, внедрение, выполненно, завод, иаз, иркутск, консалтинг, консультанты, проекты, см-консалт, тренинг, успех

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Spam protection by WP Captcha-Free