Лекция 11. Технология создания программного обеспечения. Rational Unified Process (rup)

Лекция 11. Технология создания программного обеспечения. Rational Unified Process (RUP)

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

И
нструментальное средство

• 
  управление требованиями;
  
• 
  анализ и проектирование ПО;
  
• 
  разработка ПО;
  
• 
  эксплуатация;
  
• 
  сопровождение;
  
• 
  документирование;
  
• 
  управление конфигурацией и изменениями;
  
• 
  тестирование;
  
• 
  управление проектом.
  

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

• 
  Раннее определение рисков и выработка ответных мер. В начале каждой стадии ЖЦ составляется список рисков (примеры: неосвоенная СП, интеграция с унаследованным кодом, орг. проблемы). По каждому риску из списка составляется перечень ответных мер. RUP учитывает изменчивость рисков – на разных этапах проекта списки рисков разные.
  
• 
  Выполнение требований заказчиков. Требования описываются вариантами использования. Варианты использования – это отправная точка создания для модели анализа и проектной модели. Планирование и управление проектом ведется на основе вариантов использования. Варианты использования являются «сырьем» для тестов и пользовательской документации.
  
• 
  Концентрация на работающем коде. Прогресс проекта оценивается по тому, какая часть системы готова и работает. Практика – лучший критерий проверки правильности того или иного решения. Все рабочие продукты проекта за исключением работающего кода являются вспомогательными, поэтому не следует слепо их создавать лишь из-за того, что они указаны в руководствах по RUP.
  
• 
  Готовность к изменениям с самого начала проекта и управление ими. Система слишком сложна, чтобы с самого начала получить верное и окончательное проектное решение. Изменения позволяют улучшать принятые решения. Итеративный процесс позволяет исправлять дефекты, допущенные на ранних итерациях. Стоимость изменений в ходе проекта увеличивается. Управление изменениями позволяет уложиться в бюджет и сроки.
  
• 
  Сборка системы из компонентов. Компонентная архитектура позволяет воспользоваться преимуществами инкапсуляции: повышает модифицируемость системы и возможности повторного использования ее частей. Стоимость разработки системы может быть снижена за счет использования компонентных платформ (J2EE, .NET).
  
• 
  Визуальное моделирование. Графические модели более наглядны, удобны чем тексты на естественных и формальных языках. UML – стандартный язык, так что модели понятны большой аудитории (состоящей не только из людей, но и из CASE-средств), по той же причине имеется больше возможностей для повторного использования моделей.
  
• 
  Обеспечение качества в течение всего ЖЦ. Используется упреждающее тестирование, лозунг которого: «Тесты раньше программ!» Регрессионное тестирование и первоочередная реализация приоритетных вариантов использования обеспечивают надежность ключевой функциональности системы. Качество создается в течение всего жизненного цикла за счет того, что все рабочие продукты критически оцениваются при рецензировании.
  

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

Р
ис. Общее представление RUP

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

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

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

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

• 
  роли;
  
• 
  виды работ;
  
• 
  рабочие продукты;
  
• 
  дисциплины (процессы).
  

• 
  построение бизнес-моделей;
  
• 
  определение требований;
  
• 
  анализ и проектирование;
  
• 
  реализация;
  
• 
  тестирование;
  
• 
  развертывание;
  

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

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

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

• 
  Планирование тестов на каждой итерации.
  
• 
  Составление тестовых вариантов (test-case) и тестовых сценариев (test scripts).
  
• 
  Тестирование с целью обнаружения дефектов.
  

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

Литература к лекции 11

1. 
   Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007
   
2. 
   Полис Г., Огастин Л. и др. Разработка программных проектов на основе Rational Unified Process.: Пер. с англ. – М.: Бином-Пресс, 2005.
   
3. 
   Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 5.
   
4. 
   Кролл П., Крачтен Ф. Rational Unified Process – это легко. Руководство по RUP для практиков. – М.: КУДИЦ-ОБРАЗ. 2004.
   
5. 
   Кратчен Ф. Введение в Rational Unified Process. 2-е изд.: Пер. с англ. – М.: Вильямс, 2002.