Прогностические процессы. Адаптивные модели процесса разработки программного обеспечения

Адапт ивны е модели процесса разработ ки программного обеспечения Прогност ические процессы Все ранее рассмотренные модели соответствуют так называемым прогностическим ( тяжеловесным ) процессам разработки ПС  Они предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации  05.09.22 Модели процесса разработки 2 Прогност ические процессы   Основная цель таких процессов – отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять Многочисленные вспомогательные действия имеют целью выполнение успешной разработки с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами 05.09.22 Модели процесса разработки 3 Адапт ивны е процессы Альтернативой такому подходу являются адаптивные или облегченные, «живые» (agile) процессы разработки  Они не требуют столь жесткой регламентации, допускают возможность частых и существенных изменений требований заказчиков  05.09.22 Модели процесса разработки 4 Адапт ивны е процессы Адаптивные процессы делают упор на использование хороших разработчиков, а не хорошо отлаженных процессов разработки  Они избегают фиксации четких схем действий, чтобы обеспечить большую гибкость в каждом конкретном проекте и не требуют создания дополнительных промежуточных документов  05.09.22 Модели процесса разработки 5 Ист ория В феврале 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты несколько известных разработчиков ПО (Kent Beck, Martin Fowler, Alistair Cockburn и др.) пришли к соглашению о необходимости документального оформления новых идей в организации процесса разработки  Ими был согласован и представлен профессиональному сообществу документ под названием Agile Manifesto  05.09.22 Модели процесса разработки 6 Текст Agile-маниф ест а «Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим.  Благодаря проделанной работе мы смогли осознать, что:  05.09.22 Модели процесса разработки 7 Идеи      Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.» 05.09.22 Модели процесса разработки 8 Принципы  Agile Manifesto декларирует следующие 12 принципов «живой» разработки:   05.09.22 наивысшим приоритетом является удовлетворение заказчика посредством ранней и постоянной поставки ценного ПО; изменяющиеся т ребования приветствуются, даже на поздних стадиях разработки; Модели процесса разработки 9 Принципы    05.09.22 част ая пост авка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработ чиками на протяжении всего проекта; проектом занимаются мотивированны е личност и, которые обеспечены нужными условиями работы, поддержкой и доверием; Модели процесса разработки 10 Принципы    05.09.22 самым эффективным методом передачи информации команде разработчиков и внутри неё является личное общение; работ ающее программное обеспечение — лучший измеритель прогресса; спонсоры, разработчики и пользователи должны все время выдерживать постоянны й темп; Модели процесса разработки 11 Принципы     05.09.22 постоянное внимание улучшению технического маст ерст ва и удобному дизайну ; прост от а — искусство не делать лишней работы; лучшие технические требования, дизайн и архитектура получаются у самоорганизующейся команды; пост оянная адаптация к изменяющимся обстоятельствам. Модели процесса разработки 12 Адапт ивны е мет одологии  Crystal Methods (1992 г.) – семейство методологий, послужившее отправной точкой в развитии идей адаптивной разработки; наиболее известная методология этого семейства Crystal Clear 05.09.22 Модели процесса разработки 13 Адапт ивны е мет одологии Agile Unified Process – упрощенная версия RUP, разработанная Скоттом Амблером  Agile Data Method – группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кроссфункциональных команд  05.09.22 Модели процесса разработки 14 Адапт ивны е мет одологии DSDM (Dynamic Systems Development Method, 1994 г.) – итеративный и инкрементный подход, придающий особое значение продолжительному участию в процессе пользователя/потребителя; основан на концепции быстрой разработки приложений (RAD)  Экстремальное программирование (XP, 1995 г.) – декларирует двенадцать основных приёмов программирования  05.09.22 Модели процесса разработки 15 Адапт ивны е мет одологии  Feature driven development (FDD, 1997 г.) — функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели» 05.09.22 Модели процесса разработки 16 Адапт ивны е мет одологии  Scrum (1995 г.) – методология, делающая основной акцент на общении с заказчиком, на общении внутри команды, на достижении самоорганизации и высокого уровня самосовершенствования 05.09.22 Модели процесса разработки 17 XP-МОДЕЛЬ 05.09.22 Модели процесса разработки 18 Экст ремальное программирование Экстремальное программирование (eXtreme Programming, XP-процесс) – одна из наиболее популярных адаптивных моделей  Авторы методологии – Кент Бек, Уорд Каннингем, Мартин Фаулер и другие  XP-процесс ориентирован на разработку качественного продукта группами малого и среднего размера в условиях неопределенных или быстро меняющихся требований  05.09.22 Модели процесса разработки 19 XP-процесс   Основная идея XP-процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций Базовыми действиями являются:     05.09.22 кодирование, тестирование, выслушивание заказчика, проектирование Модели процесса разработки 20 Принципы XP  Высокий динамизм разработки обеспечивается следующими принципами:     05.09.22 непрерывная связь с заказчиком, простота выбираемых решений, быстрая обратная связь на основе оперативного тестирования, профилактика рисков Модели процесса разработки 21 Практ ики XP  Реализация этих принципов достигается за счет использования следующих методов:   05.09.22 Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система Простое проектирование – принимаются наиболее простые из возможных проектные решения Модели процесса разработки 22 Практ ики XP    05.09.22 Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения Парное программирование – код пишется двумя программистами на одном компьютере Модели процесса разработки 23 Практ ики XP   05.09.22 Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований Модели процесса разработки 24 Практ ики XP   05.09.22 Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы Модели процесса разработки 25 Х Р в карт инках 05.09.22 Модели процесса разработки 26 SCRUM-МОДЕЛЬ 05.09.22 Модели процесса разработки 27 Scrum-модель Является еще одним примером адаптивного процесса разработки  Основные идеи модели сформулировали Хиротака Такеути и Икудзиро Нонака в 1986 году  05.09.22 Модели процесса разработки 28 Основная идея  Экспериментальный факт: проекты, над которыми работают небольшие, кроссфункциональные команды, обычно систематически производят лучшие результаты 05.09.22 Модели процесса разработки 29 Основная идея Такеуки и Ноната объяснили это как «подход регби» и ввели и сам термин «scrum» «толкотня; схватка вокруг мяча (в регби)»  Впервые метод Scrum был представлен в документированном виде в 1996 году совместно Сазерлендом и Швабером  05.09.22 Модели процесса разработки 30 Роли  Главные действующие роли:    05.09.22 ScrumMaster, тот кто занимается процессами и работает в качестве руководителя проекта, Владелец Продукта, человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон, Команда, которая включает разработчиков Модели процесса разработки 31 Эт апы разработ ки  Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно,15-30 дней)  Каждому спринту предшествует этап, который называется product backlog – документирование запросов на выполнение работ 05.09.22 Модели процесса разработки 32 Планирование спринт а  Запросы на выполнение работ определяются на этапе совета по планированию спринта – sprint planning meeting Модели процесса разработки 05.09.22 33 Планирование спринт а На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены  Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта  05.09.22 Модели процесса разработки 34 Вы полнение спринт а   Во время спринта команда выполняет определенный фиксированный список заданий - backlog items, наращивая функциональность программного продукта На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать, как заморозку требований (requirements) во время спринта 05.09.22 Модели процесса разработки 35 Scrum в карт инках 05.09.22 Модели процесса разработки 36 RAD-МОДЕЛЬ 05.09.22 Модели процесса разработки 37 RAD-модель Модель быстрой разработки приложений (Rapid Application Development) является примером адаптивного процесса в рамках реализации инкрементной стратегии  Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойема и Скотта Шульца  05.09.22 Модели процесса разработки 38 Цели RAD-модели  Основными целями RAD-модели процесса разработки ПО являются:    05.09.22 высокая скорость разработки; низкая стоимость; высокое качество Модели процесса разработки 39 Основны е принципы RAD 1. 2. 05.09.22 Работа ведется группами; типичный состав группы - руководитель, аналитик, два программиста, технический писатель. Разработка базируется на моделях; моделирование позволяет оценить проект и выполнить его декомпозицию на составные части, каждая из которых может разрабатываться отдельной RAD-группой. Модели процесса разработки 40 Основны е принципы RAD 3. 4. 05.09.22 Разработка системы и предъявление ее заказчику осуществляется в виде последовательности развиваемых прототипов RAD-группа всегда работает только над одним прототипом. Это обеспечивает единство целей, лучшую наблюдаемость и управляемость процессом разработки Модели процесса разработки 41 Основны е принципы RAD 5. 6. 7. 05.09.22 RAD-группы должны использовать общие стандарты Обязательно финальное тестирование полной системы Обязательно использование инструментальных средств, автоматизирующих процесс разработки – визуальных сред проектирования и программирования Модели процесса разработки 42 RAD-модель 1-я группа разработчиков Моделирование предметной области Моделирование данных 2-я группа разработчиков Моделирование предметной области Моделирование обработки Моделирование данных Генерация приложения Моделирование обработки Генерация приложения Объединение и тестирование 05.09.22 Модели процесса разработки 43 Прот от ипы Любой из прототипов реализует определенную часть функциональности, требуемой от конечного продукта; каждый последующий прототип включает всю функциональность, реализованную в предыдущем прототипе, с добавлением новой  Число прототипов определяется на основе учета разных параметров – размера проекта, анализа рисков, пожеланий заказчика и т. д.  05.09.22 Модели процесса разработки 44 Прот от ипы  Традиционно для проектов ПО средней сложности разрабатываются три прототипа:    05.09.22 первый содержит весь пользовательский интерфейс с нулевой функциональностью; он дает возможность утвердить у заказчика экранные и отчетные формы; второй прототип содержит реализованную на 7080% функциональность системы третий прототип содержит полностью реализованную функциональность Модели процесса разработки 45 Ит ерации  Основаниями для очередной итерации в процессе разработки являются:  05.09.22 Замечания заказчика. Если замечания носят характер исправлений, они учитываются в следующем прототипе, если же изменяются требования, то выполняется переоценка проекта и корректируются сроки и стоимость проекта Модели процесса разработки 46 Ит ерации   05.09.22 Детализация. Выполняется программирование нереализованной части системы в соответствии с составленным планом. Анализ результатов программирования. Исправляются ошибки, повышается эффективность программного кода и т. д. Модели процесса разработки 47 Когда применяет ся RAD  Применение технологии RAD целесообразно, когда:   05.09.22 требуется выполнение проекта в сжатые сроки (90 дней); быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня нечетко определены требования к ПО; в большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО Модели процесса разработки 48 Когда применяет ся RAD   05.09.22 проект выполняется в условиях ограниченности бюджета; разработка ведется небольшими RADгруппами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения интерфейс пользователя (GUI) есть главный фактор; RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта Модели процесса разработки 49 Когда применяет ся RAD   05.09.22 проект большой, но поддается разделению на более мелкие функциональные компоненты ПО не обладает большой вычислительной сложностью Модели процесса разработки 50 RAD не применяет ся В проектах, где требования к программному продукту четко определены и не должны меняться, и, следовательно, вовлечение заказчика в процесс разработки не требуется  В проектах, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик  05.09.22 Модели процесса разработки 51 Сравнение двух моделей 05.09.22 Модели процесса разработки 52 Х аракт ерист ика модели Основным достоинством модели является уменьшение сроков разработки  Ее главный недостаток заключается в необходимости использования большого числа квалифицированных разработчиков, что может существенно повысить стоимость разработки  05.09.22 Модели процесса разработки 53 Конец лекции 05.09.22 54