Презентации / Lecture03p

«Тяжелые» и «гибкие» процессы разработки

•«Тяжелые» процессы

•Фокус на отчуждении как можно большего объема знаний о системе от разработчиков

•Аккуратное документирование всех решений

•Представитель: унифицированный процесс (Rational Unified Process, RUP)

•Проблемы: бюрократизация, увеличение затрат на небольшие изменения

•«Гибкие»/agile процессы

•Фокус на максимальном снижении затрат на внесение изменений

•Опора на знания и опыт команды

•Представитель: экстремальное программирование (eXtreme Programming, XP)

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

RUP – история

•1970-е – Ericsson (I. Jacobson)

•1987 – Ojectory AB

•1995 – Rational (W. Royce, P. Kruchten)

•2003 – IBM

RUP – основные идеи

•Итеративная разработка для своевременной отработки изменений

•Итерации с общей структурой – спиральная модель ЖЦ

•Анализ рисков различных изменений и подготовка к наиболее существенным из них

•Фиксация как можно большего числа решений и знаний, в основном, в виде графических моделей (UML)

•Фиксация требований в виде моделей вариантов использования (use cases)

•Фиксация архитектуры в виде архитектурных моделей

RUP – структура итераций

•Фаза начала (inception)

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

•10% времени и 5% трудозатрат

•Фаза проектирования/уточнения (elaboration)

•Цель – выработка архитектуры, удовлетворяющей наиболее важным требованиям

•30% времени и 20% трудозатрат

•Фаза построения (construction)

•Цель – полная проработка требований и создание системы

•50% времени и 65% трудозатрат

•Фаза внедрения (transition)

•Цель – получение готовой к эксплуатации системы в рабочем окружении

•10% времени и 10% трудозатрат

RUP – виды моделей

•Модель требований

•Варианты использования (use cases)

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

•Часть сценариев – успешные, часть – нет

RUP – виды моделей

•Модель требований

•Модель анализа

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

Классы анализа – понятия предметной области, алгоритмы и интерфейсы Класс данных, управляющие и интерфейсные

RUP – виды моделей

•Модель требований

•Модель анализа

•Модель проектирования

•Модель классов, составляющих код Класс модели анализа обычно превращается в группу классов модели проектирования

Классы модели проектирования зависят от используемых технологий

•Модель реализации

•Модель развертывания

•Модель тестирования

RUP – виды моделей

•Модель требований

•Модель анализа

•Модель проектирования

•Модель реализации

•Модель компонентов Компонент – атомарная единица развертывания

Часто это исполнимые файлы или скрипты (+ необходимые конфигурационные)

•Модель развертывания

•Описывает размещение компонентов по узлам (устройствам и машинам) системы, физические соединения между узлами и их характеристики

•Модель тестирования

RUP – виды моделей

•Модель требований

•Модель анализа

•Модель проектирования

•Модель реализации

•Модель развертывания

•Модель тестирования

•Набор тестовых вариантов и тестовых процедур

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

•Каждому варианту использования соответствует несколько тестовых вариантов, с условиями на входные данные и выполняемыми на некоторых шагах проверками

•Тестовая процедура – формализованное/исполнимое описание выполнения тестового варианта