Стратегии конструирования ПО. RationalUnifiedProcess

Рациональный унифицированный процесс является развитием спиральной модели и представляет процесс разработки в виде эволюционно-инкрементного цикла. Эволюционная составляющая цикла основывается на дополнении требований в ходе работы. Инкрементная составляющая - на планомерном приращении реализации требований.

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

RUP выделяет в процессе разработки 4 этапа:

- начало- определяются цели проекта, руководитель, бюджет, средства выполнения (занимает около 5% трудоёмкости одного цикла и 10% времени);

- развитие- разработка стабильной базовой архитектуры проекта (занимает около 20% трудоёмкости одного цикла и 30% времени);

- конструирование- детальное прояснение требований, разработка системы, удовлетворяющей им на основе спроектированной ранее архитектуры (занимает около 65% трудоёмкости одного цикла и 50% времени);

- внедрение- развёртывание системы в её рабочей среде, бета-тестирование, подгонка мелких деталей (занимает около 10% трудоёмкости одного цикла и 10% времени);

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

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

1. В RUP-модели разработки ПО наибольшие затраты по времени занимает этап:

2. Что в RUP-модели разработки ПО происходит на этапе развития?

Стратегии конструирования ПО. Экстремальное программирование

Так называемый ХР-процесс ориентирован на группы малого и среднего размера, разрабатывающих ПС в условиях неопределённых или быстро меняющихся требований. Идея - устранить высокую стоимость внесения изменений. Достигается путём резкого сокращения длительности отдельных итераций. Базовые итерации: кодирование, тестирование, выслушивание заказчика, проектирование.

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

Методы ХР:

Игра в планирование.Со стороны заказчика - объём работ, приоритет, композиция версий, сроки выпуска версий. Со стороны разработчик - временные оценки, последствия, процесс, подробный график работ

Небольшие версии. Быстрый запуск простой системы. Версия должна быть как можно меньше, но завершённой. Выпуск версии обычно раз в 2 недели.

Метафора. Глобальное «видение» проекта, понятное всем. «Замена» большой архитектуры. Основная идея - сведения об архитектуре.

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

Тестирование. Для любой возможности существуют автоматические тесты (модульные для разработчиков, функциональные для заказчиков). Репозиторий тестов постоянно пополняется. Код разрабатывается вместе или после тестов.

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

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

Коллективное владение. Код является общей собственностью. При необходимости он модифицируется немедленно, независимо от авторского кода.

Непрерывная интеграция. Код интегрируется раз в несколько часов (после прохождения всех тестов).

40-часовая рабочая неделя. Сверхурочные - крайне нежелательны. Если постоянно требуется переработка- неправильно организован проект. Отпуск - обязателен.

Локальный заказчик. В составе команды - представитель заказчика. Он пользователь системы. Отвечает на вопросы разработчиков и расставляет мелкие приоритеты.

Стандарты кодирования. Единый стандарт кодирования. Должен способствовать коммуникациям, и добровольно воспринят командой.

1. Методами экстремального программирования являются:

2. Метод экстремального программирования ориентирован на:

Стратегии конструирования ПО. Методология SCRUM

Основная идея - это экспериментальный факт: проекты, над которыми работают небольшие, кросс-функциональные команды, обычно систематически производят лучшие результаты.

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

Разработка разбивается на этапы определённой длительности (обычно 15-30 дней) -спринты (sprint). Каждому спринту предшествует этап backlog- документирование запросов на выполнение работ. Запросы определяются на этапе совета по планированию спринта -sprintplanningmeeting, -на протяжении которого Владелец Продукта информирует о заданиях, которые должны быть выполнены. Команда определяет, сколько они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта. Во время спринта команда выполняет некоторый список заданий -backlogitems. В это время никто не имеет права изменять список требований, то есть происходит заморозка требований (requirement).

1. В методологии SCRUM разработка делится на этапы, которые называются:

2. Основной идеей методологии SCRUMявляется: