Конспект лекций, страница 23

Описание файла

PDF-файл из архива "Конспект лекций", который расположен в категории "лекции и семинары". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 23 страницы из PDF

Вовремя начальной стадии вырабатывается бизнес-план проекта, определяется, сколькоприблизительно он будет стоить и какой доход принесет. Определяются также границыпроекта, и выполняется некоторый начальный анализ для оценки размеров проекта.Результатами начальной стадии являются:• общее описание системы: основные требования к проекту, его характеристики иограничения;• начальная модель вариантов использования (степень готовности - 10-20%);• начальный проектный глоссарий (словарь терминов);• начальный бизнес-план;• план проекта, отражающий стадии и итерации;• один или несколько прототипов.На стадии разработки выявляются более детальные требования к системе,выполняется высокоуровневый анализ предметной области и проектирование дляпостроения базовой архитектуры системы, создается план конструирования иустраняются наиболее рискованные элементы проекта.Результатами стадии разработки являются:• модель вариантов использования (завершенная по крайней мере на 80%),определяющая функциональные требования к системе;• перечень дополнительных требований, включая требования нефункциональногохарактера и требования, не связанные с конкретными вариантами использования;• описание базовой архитектуры будущей системы;• работающий прототип;• уточненный бизнес-план;4•план разработки всего проекта, отражающий итерации и критерии оценки для каждойитерации.Стадия разработки занимает около пятой части общей продолжительности проекта.RUP представляет собой итерационный и пошаговый процесс разработки, в которомпрограммное обеспечение разрабатывается и реализуется по частям.

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

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

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

Во время нее тольковылавливаются ошибки и шлифуется качество. Хорошим примером для стадии вводав действие может служить период времени между выпуском бета-версии и окончательнойверсии продукта.Статический аспектСтатический аспект RUP представлен четырьмя основными элементами:• роли;• виды работ;• рабочие продукты;• дисциплины (процессы).Понятие «роль» (role) определяет поведение и ответственность личности или группыличностей, составляющих проектную команду. Одна личность может играть в проектемного различных ролей.Видом работы конкретного исполнителя понимается элементарная работа –5технологическая опреация, выполняемая им.Дисциплина (discipline) соответствует понятию технологического процесса ипредставляет собой последовательность работ, приводящую к получению значимогорезультата.В рамках RUP определены шесть основных дисциплин:• построение бизнес-моделей;• определение требований;• анализ и проектирование;• реализация;• тестирование;• развертывание;и три вспомогательных:• управление конфигурацией и изменениями;• управление проектом;• создание инфраструктуры.По большей части, содержание основных дисциплин мы рассмотрелина предыдущих лекциях.

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

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

В результате должна появиться модельпроектирования, включающая в себя диаграммы классов системы, диаграммы еекомпонентов, диаграммы взаимодействия между объектами в ходе реализации вариантовиспользования, диаграммы состояний для отдельных объектов и диаграммыразвертывания, а также модель развертывания и документ – описание архитектуры.Подробное рассмотрение дисциплины см. в лекциях 6, 7 и 9.Дисциплина реализации решает следующие задачи – определить структуруисходного кода системы, разработать код ее компонентов и протестировать их,6интегрировать систему в работающее целое. Она включает в себя:• Реализацию архитектуры (переход от проектной модели к модели реализации,представленной в виде диаграмм компонент и диаграмм пакетов).• Выработку плана сборки для каждой итерации.• Распределение компонентов системы по узлам вычислительной среды.• Реализацию кода классов и подсистем.• Покомпонентное тестирование.Реализацию архитектуры осуществляет архитектор.

Заключается она в трассировкепроектных классов, пакетов и подсистем в компоненты и установлении связей(зависимостей) между компонентами.План сборки описывает функциональность, которая должна быть реализована вбилде (сборке) и те компоненты, которые входят в билд. Планы составляет системныйинтегратор.За реализацию кода отвечает инженер по компонентам.Покомпонентное тестирование – это раздельное тестирование компонент системы.Осуществляет его инженер по компонентам путем тестирования спецификации («черныйящик») и тестирования структуры («белый ящик»).Дисциплина тестирования решает следующие задачи – найти и описать дефектысистемы (проявления недостатков ее качества), оценить ее качество в целом, оценитьвыполнены или нет гипотезы, лежащие в основе проектирования, оценить степеньсоответствия системы требованиям. Она включает в себя:• Планирование тестов на каждой итерации.• Составление тестовых вариантов (test-case) и тестовых сценариев (test scripts).• Тестирование с целью обнаружения дефектов.Тестовый вариант включает входные данные, условия выполнения отдельных шагови корректные ответы системы для всякого шага, на котором ответ системы можнонаблюдать.

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

Свежие статьи
Популярно сейчас