Конспект лекций (1158677), страница 23
Текст из файла (страница 23)
Вовремя начальной стадии вырабатывается бизнес-план проекта, определяется, сколькоприблизительно он будет стоить и какой доход принесет. Определяются также границыпроекта, и выполняется некоторый начальный анализ для оценки размеров проекта.Результатами начальной стадии являются:• общее описание системы: основные требования к проекту, его характеристики иограничения;• начальная модель вариантов использования (степень готовности - 10-20%);• начальный проектный глоссарий (словарь терминов);• начальный бизнес-план;• план проекта, отражающий стадии и итерации;• один или несколько прототипов.На стадии разработки выявляются более детальные требования к системе,выполняется высокоуровневый анализ предметной области и проектирование дляпостроения базовой архитектуры системы, создается план конструирования иустраняются наиболее рискованные элементы проекта.Результатами стадии разработки являются:• модель вариантов использования (завершенная по крайней мере на 80%),определяющая функциональные требования к системе;• перечень дополнительных требований, включая требования нефункциональногохарактера и требования, не связанные с конкретными вариантами использования;• описание базовой архитектуры будущей системы;• работающий прототип;• уточненный бизнес-план;4•план разработки всего проекта, отражающий итерации и критерии оценки для каждойитерации.Стадия разработки занимает около пятой части общей продолжительности проекта.RUP представляет собой итерационный и пошаговый процесс разработки, в которомпрограммное обеспечение разрабатывается и реализуется по частям.
На стадииконструирования построение системы выполняется путем серии итераций. Каждаяитерация является своего рода мини-проектом. На каждой итерации для конкретныхвариантов использования выполняются анализ, проектирование, кодирование,тестирование и интеграция («мини-каскад»). Итерация завершается демонстрациейрезультатов пользователям и выполнением системных тестов для контроля корректностиреализации вариантов использования.При итеративной разработке на каждой итерации выполняются все процессы, чтопозволяет оперативно справляться со всеми возникающими проблемами.
Итерации настадии конструирования являются одновременно инкрементными и повторяющимися.В конце каждой итерации должна выполняться полная интеграция. С другой стороны,интеграция может и должна выполняться еще чаще. Приложения следует интегрироватьпосле выполнения каждой сколько-нибудь значительной части работы. Во время каждойинтеграции должен выполняться полный набор тестов.Главная особенность итерационной разработки заключается в том, что она жесткоограничена временными рамками, и сдвигать сроки недопустимо. Смысл такихограничений – поддерживать строгую дисциплину разработки и не допускать переносасроков.Результатом стадии конструирования является продукт, готовый к передачеконечным пользователям. Как минимум, он содержит следующее:• ПО, интегрированное на требуемых платформах;• руководства пользователя;• описание текущей реализации.Назначением стадии ввода в действие является передача готового продуктав распоряжение пользователей.
Данная стадия включает:• бета-тестирование, позволяющее убедиться, что новая система соответствуетожиданиям пользователей;• параллельное функционирование с существующей (legacy) системой, котораяподлежит постепенной замене;• конвертирование баз данных;• оптимизацию производительности;• обучение пользователей и специалистов службы сопровождения.На стадии ввода в действие продукт не дополняется никакой новойфункциональностью (кроме самого необходимого минимума).
Во время нее тольковылавливаются ошибки и шлифуется качество. Хорошим примером для стадии вводав действие может служить период времени между выпуском бета-версии и окончательнойверсии продукта.Статический аспектСтатический аспект RUP представлен четырьмя основными элементами:• роли;• виды работ;• рабочие продукты;• дисциплины (процессы).Понятие «роль» (role) определяет поведение и ответственность личности или группыличностей, составляющих проектную команду. Одна личность может играть в проектемного различных ролей.Видом работы конкретного исполнителя понимается элементарная работа –5технологическая опреация, выполняемая им.Дисциплина (discipline) соответствует понятию технологического процесса ипредставляет собой последовательность работ, приводящую к получению значимогорезультата.В рамках RUP определены шесть основных дисциплин:• построение бизнес-моделей;• определение требований;• анализ и проектирование;• реализация;• тестирование;• развертывание;и три вспомогательных:• управление конфигурацией и изменениями;• управление проектом;• создание инфраструктуры.По большей части, содержание основных дисциплин мы рассмотрелина предыдущих лекциях.
Повторим кратко.Задачи построения бизнес-моделей – понять предметную область или бизнесконтекст, в которых должна будет работать система, и убедиться, что всезаинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценитьих возможные решения и их последствия для бизнеса организации, в которой будетработать система. В рамках этой дисциплины создаются следующие рабочие продукты:• видение бизнеса;• глоссарий деятельности предприятия;• модель бизнес-процессов (описывающая контекст бизнеса и бизнес-процессыпредприятия на диаграмме вариантов использования);• модель бизнес-анализа (описывающая протекание бизнес-процессов, т.
е. ихреализацию, на диаграммах взаимодействия, участниками которых являютсяисполнители и бизнес-сущности, а также на диаграммах деятельности);• описания бизнес-целей, бизнес-правил и бизнес-событий;• дополнительная спецификация бизнеса.Полученные модели служат основой для моделей требований и анализа. Подробнодисциплина рассматривалась на лекции «Моделирование бизнес-процессов».Задачи определения требований – понять, что должна делать система, и убедиться вовзаимопонимании по этому поводу между заинтересованными лицами, определитьграницы системы и основу для планирования проекта и оценок затрат ресурсов в нем.Требования принято фиксировать в виде модели вариантов использования иразличных документов: описаний вариантов использования, концепции системы,глоссария системы, дополнительной спецификации, отражающей нефункциональныетребования. Подробно дисциплина рассматривалась на лекции «Требования кпрограммному обеспечению».Задачи анализа и проектирования – выработать архитектуру системы на основетребований, убедиться, что данная архитектура может быть основой работающей системыв контексте ее будущего использования.
В результате должна появиться модельпроектирования, включающая в себя диаграммы классов системы, диаграммы еекомпонентов, диаграммы взаимодействия между объектами в ходе реализации вариантовиспользования, диаграммы состояний для отдельных объектов и диаграммыразвертывания, а также модель развертывания и документ – описание архитектуры.Подробное рассмотрение дисциплины см. в лекциях 6, 7 и 9.Дисциплина реализации решает следующие задачи – определить структуруисходного кода системы, разработать код ее компонентов и протестировать их,6интегрировать систему в работающее целое. Она включает в себя:• Реализацию архитектуры (переход от проектной модели к модели реализации,представленной в виде диаграмм компонент и диаграмм пакетов).• Выработку плана сборки для каждой итерации.• Распределение компонентов системы по узлам вычислительной среды.• Реализацию кода классов и подсистем.• Покомпонентное тестирование.Реализацию архитектуры осуществляет архитектор.
Заключается она в трассировкепроектных классов, пакетов и подсистем в компоненты и установлении связей(зависимостей) между компонентами.План сборки описывает функциональность, которая должна быть реализована вбилде (сборке) и те компоненты, которые входят в билд. Планы составляет системныйинтегратор.За реализацию кода отвечает инженер по компонентам.Покомпонентное тестирование – это раздельное тестирование компонент системы.Осуществляет его инженер по компонентам путем тестирования спецификации («черныйящик») и тестирования структуры («белый ящик»).Дисциплина тестирования решает следующие задачи – найти и описать дефектысистемы (проявления недостатков ее качества), оценить ее качество в целом, оценитьвыполнены или нет гипотезы, лежащие в основе проектирования, оценить степеньсоответствия системы требованиям. Она включает в себя:• Планирование тестов на каждой итерации.• Составление тестовых вариантов (test-case) и тестовых сценариев (test scripts).• Тестирование с целью обнаружения дефектов.Тестовый вариант включает входные данные, условия выполнения отдельных шагови корректные ответы системы для всякого шага, на котором ответ системы можнонаблюдать.
С вариантом тестирования связан один или более тестовых сценариев.Тестовый сценарий – способ выполнения одного или нескольких тестовых наборов врамках тестового варианта. Выполняется вручную или автоматически.Тестовые варианты и сценарии разрабатываются инженерами по тестированию.Некоторые тестовые варианты предназначены для интеграционного тестирования, онипроверяют целостность сборки, т. е. правильность взаимодействия компонент, вошедшихв сборку. За тестирование целостности отвечает тестировщик целостности.