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