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

Категория: Устройства и комплектующие
Нажмите для полного просмотра!
Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №1Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №2Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №3Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №4Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №5Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №6Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №7Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №8Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №9Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №10Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №11Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №12Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №13Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №14Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №15Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №16Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №17Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №18Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №19Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №20Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №21Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №22Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №23Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №24Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №25Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №26Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №27Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №28Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №29Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №30Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №31Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №32Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №33Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №34Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №35Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №36Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №37Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №38Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №39Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №40Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №41Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №42Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №43Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №44Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №45Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №46Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №47Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №48Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №49Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №50Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №51Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №52Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №53Адаптивные модели процесса разработки программного обеспечения. (Лекция 10), слайд №54
Скачать

Содержание ▲

Вы можете ознакомиться и скачать презентацию на тему Адаптивные модели процесса разработки программного обеспечения. (Лекция 10). Доклад-сообщение содержит 54 слайдов. Презентации для любого класса можно скачать бесплатно. Если материал и наш сайт презентаций Mypresentation Вам понравились – поделитесь им с друзьями с помощью социальных кнопок и добавьте в закладки в своем браузере.

Слайды и текст этой презентации

Слайд 1


Адаптивные модели процесса разработки программного обеспечения Лекция 10
Описание слайда:
Адаптивные модели процесса разработки программного обеспечения Лекция 10

Слайд 2


Прогностические процессы Все ранее рассмотренные модели соответствуют так называемым прогностическим ( тяжеловесным ) процессам разработки ПС Они предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации
Описание слайда:
Прогностические процессы Все ранее рассмотренные модели соответствуют так называемым прогностическим ( тяжеловесным ) процессам разработки ПС Они предполагают планирование всего объема работ и, соответственно, достаточно большой объем документации

Слайд 3


Прогностические процессы Основная цель таких процессов – отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять Многочисленные вспомогательные действия имеют целью выполнение успешной разработки с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами
Описание слайда:
Прогностические процессы Основная цель таких процессов – отделить успешные практики разработки и сопровождения ПО от конкретных людей, умеющих их применять Многочисленные вспомогательные действия имеют целью выполнение успешной разработки с помощью имеющихся работников, не обязательно являющихся суперпрофессионалами

Слайд 4


Адаптивные процессы Альтернативой такому подходу являются адаптивные или облегченные, «живые» (agile) процессы разработки Они не требуют столь жесткой регламентации, допускают возможность частых и существенных изменений требований заказчиков
Описание слайда:
Адаптивные процессы Альтернативой такому подходу являются адаптивные или облегченные, «живые» (agile) процессы разработки Они не требуют столь жесткой регламентации, допускают возможность частых и существенных изменений требований заказчиков

Слайд 5


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

Слайд 6


История В феврале 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты несколько известных разработчиков ПО (Kent Beck, Martin Fowler, Alistair Cockburn и др.) пришли к соглашению о необходимости документального оформления новых идей в организации процесса разработки Ими был согласован и представлен профессиональному сообществу документ под названием Agile Manifesto
Описание слайда:
История В феврале 2001 года на лыжном курорте The Lodge at Snowbird в горах Юты несколько известных разработчиков ПО (Kent Beck, Martin Fowler, Alistair Cockburn и др.) пришли к соглашению о необходимости документального оформления новых идей в организации процесса разработки Ими был согласован и представлен профессиональному сообществу документ под названием Agile Manifesto

Слайд 7


Текст Agile-манифеста «Мы постоянно открываем для себя более совершенные методы разработки  программного обеспечения, занимаясь разработкой непосредственно и помогая  в этом другим. Благодаря проделанной работе мы смогли осознать, что:
Описание слайда:
Текст Agile-манифеста «Мы постоянно открываем для себя более совершенные методы разработки  программного обеспечения, занимаясь разработкой непосредственно и помогая  в этом другим. Благодаря проделанной работе мы смогли осознать, что:

Слайд 8


Идеи Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.»
Описание слайда:
Идеи Люди и взаимодействие важнее процессов и инструментов Работающий продукт важнее исчерпывающей документации Сотрудничество с заказчиком важнее согласования условий контракта Готовность к изменениям важнее следования первоначальному плану То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.»

Слайд 9


Принципы Agile Manifesto декларирует следующие 12 принципов «живой» разработки: наивысшим приоритетом является удовлетворение заказчика посредством ранней и постоянной поставки ценного ПО; изменяющиеся требования приветствуются, даже на поздних стадиях разработки;
Описание слайда:
Принципы Agile Manifesto декларирует следующие 12 принципов «живой» разработки: наивысшим приоритетом является удовлетворение заказчика посредством ранней и постоянной поставки ценного ПО; изменяющиеся требования приветствуются, даже на поздних стадиях разработки;

Слайд 10


Принципы частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
Описание слайда:
Принципы частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;

Слайд 11


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

Слайд 12


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

Слайд 13


Адаптивные методологии Crystal Methods (1992 г.) – семейство методологий, послужившее отправной точкой в развитии идей адаптивной разработки; наиболее известная методология этого семейства Crystal Clear
Описание слайда:
Адаптивные методологии Crystal Methods (1992 г.) – семейство методологий, послужившее отправной точкой в развитии идей адаптивной разработки; наиболее известная методология этого семейства Crystal Clear

Слайд 14


Адаптивные методологии Agile Unified Process – упрощенная версия RUP, разработанная Скоттом Амблером Agile Data Method – группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд
Описание слайда:
Адаптивные методологии Agile Unified Process – упрощенная версия RUP, разработанная Скоттом Амблером Agile Data Method – группа итеративных методов разработки программного обеспечения, в которых требования и решения достигаются в рамках сотрудничества разных кросс-функциональных команд

Слайд 15


Адаптивные методологии DSDM (Dynamic Systems Development Method, 1994 г.) – итеративный и инкрементный подход, придающий особое значение продолжительному участию в процессе пользователя/потребителя; основан на концепции быстрой разработки приложений (RAD) Экстремальное программирование (XP, 1995 г.) – декларирует двенадцать основных приёмов программирования
Описание слайда:
Адаптивные методологии DSDM (Dynamic Systems Development Method, 1994 г.) – итеративный и инкрементный подход, придающий особое значение продолжительному участию в процессе пользователя/потребителя; основан на концепции быстрой разработки приложений (RAD) Экстремальное программирование (XP, 1995 г.) – декларирует двенадцать основных приёмов программирования

Слайд 16


Адаптивные методологии Feature driven development (FDD, 1997 г.) — функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели»
Описание слайда:
Адаптивные методологии Feature driven development (FDD, 1997 г.) — функционально-ориентированная разработка. Используемое в FDD понятие функции или свойства (feature) системы достаточно близко к понятию прецедента использования, существенное отличие — это дополнительное ограничение: «каждая функция должна допускать реализацию не более, чем за две недели»

Слайд 17


Адаптивные методологии Scrum (1995 г.) – методология, делающая основной акцент на общении с заказчиком, на общении внутри команды, на достижении самоорганизации и высокого уровня самосовершенствования
Описание слайда:
Адаптивные методологии Scrum (1995 г.) – методология, делающая основной акцент на общении с заказчиком, на общении внутри команды, на достижении самоорганизации и высокого уровня самосовершенствования

Слайд 18


XP-МОДЕЛЬ
Описание слайда:
XP-МОДЕЛЬ

Слайд 19


Экстремальное программирование Экстремальное программирование (eXtreme Programming, XP-процесс) – одна из наиболее популярных адаптивных моделей Авторы методологии – Кент Бек, Уорд Каннингем, Мартин Фаулер и другие XP-процесс ориентирован на разработку качественного продукта группами малого и среднего размера в условиях неопределенных или быстро меняющихся требований
Описание слайда:
Экстремальное программирование Экстремальное программирование (eXtreme Programming, XP-процесс) – одна из наиболее популярных адаптивных моделей Авторы методологии – Кент Бек, Уорд Каннингем, Мартин Фаулер и другие XP-процесс ориентирован на разработку качественного продукта группами малого и среднего размера в условиях неопределенных или быстро меняющихся требований

Слайд 20


XP-процесс Основная идея XP-процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций Базовыми действиями являются: кодирование, тестирование, выслушивание заказчика, проектирование
Описание слайда:
XP-процесс Основная идея XP-процесса – устранить высокую стоимость внесения изменений. Это достигается путем резкого (до двух недель) сокращения длительности отдельных итераций Базовыми действиями являются: кодирование, тестирование, выслушивание заказчика, проектирование

Слайд 21


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

Слайд 22


Практики XP Реализация этих принципов достигается за счет использования следующих методов: Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система Простое проектирование – принимаются наиболее простые из возможных проектные решения
Описание слайда:
Практики XP Реализация этих принципов достигается за счет использования следующих методов: Метафора – вся разработка ведется на основе простой, общедоступной истории о том, как работает система Простое проектирование – принимаются наиболее простые из возможных проектные решения

Слайд 23


Практики XP Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения Парное программирование – код пишется двумя программистами на одном компьютере
Описание слайда:
Практики XP Непрерывное тестирование как отдельных модулей, так и системы в целом; входным критерием для написания кода является отказавший тестовый вариант Реорганизация ( Refactoring ) – улучшение структуры системы при сохранении ее поведения Парное программирование – код пишется двумя программистами на одном компьютере

Слайд 24


Практики XP Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований
Описание слайда:
Практики XP Коллективное владение кодом – любой разработчик может улучшить код любого модуля системы Непрерывная интеграция – система интегрируется как можно чаще; непрерывное регрессионное тестирование гарантирует сохранение функциональности при изменении требований

Слайд 25


Практики XP Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы
Описание слайда:
Практики XP Локальный заказчик – в группе все время должен находиться компетентный представитель заказчика Стандарты кодирования – должны выдерживаться правила, обеспечивающие одинаковое представление кода во всех частях системы

Слайд 26


ХР в картинках
Описание слайда:
ХР в картинках

Слайд 27


SCRUM-МОДЕЛЬ
Описание слайда:
SCRUM-МОДЕЛЬ

Слайд 28


Scrum-модель Является еще одним примером адаптивного процесса разработки Основные идеи модели сформулировали Хиротака Такеути и Икудзиро Нонака в 1986 году
Описание слайда:
Scrum-модель Является еще одним примером адаптивного процесса разработки Основные идеи модели сформулировали Хиротака Такеути и Икудзиро Нонака в 1986 году

Слайд 29


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

Слайд 30


Основная идея Такеуки и Ноната объяснили это как «подход регби» и ввели и сам термин «scrum» - «толкотня; схватка вокруг мяча (в регби)» Впервые метод Scrum был представлен в документированном виде в 1996 году совместно Сазерлендом и Швабером
Описание слайда:
Основная идея Такеуки и Ноната объяснили это как «подход регби» и ввели и сам термин «scrum» - «толкотня; схватка вокруг мяча (в регби)» Впервые метод Scrum был представлен в документированном виде в 1996 году совместно Сазерлендом и Швабером

Слайд 31


Роли Главные действующие роли: ScrumMaster, тот кто занимается процессами и работает в качестве руководителя проекта, Владелец Продукта, человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон, Команда, которая включает разработчиков
Описание слайда:
Роли Главные действующие роли: ScrumMaster, тот кто занимается процессами и работает в качестве руководителя проекта, Владелец Продукта, человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон, Команда, которая включает разработчиков

Слайд 32


Этапы разработки Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно,15-30 дней) Каждому спринту предшествует этап, который называется product backlog –документирование запросов на выполнение работ
Описание слайда:
Этапы разработки Процесс разработки разбивается на отдельные этапы определенной длительности – спринты (обычно,15-30 дней) Каждому спринту предшествует этап, который называется product backlog –документирование запросов на выполнение работ

Слайд 33


Планирование спринта
Описание слайда:
Планирование спринта

Слайд 34


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

Слайд 35


Выполнение спринта Во время спринта команда выполняет определенный фиксированный список заданий - backlog items, наращивая функциональность программного продукта На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать, как заморозку требований (requirements) во время спринта
Описание слайда:
Выполнение спринта Во время спринта команда выполняет определенный фиксированный список заданий - backlog items, наращивая функциональность программного продукта На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать, как заморозку требований (requirements) во время спринта

Слайд 36


Scrum в картинках
Описание слайда:
Scrum в картинках

Слайд 37


RAD-МОДЕЛЬ
Описание слайда:
RAD-МОДЕЛЬ

Слайд 38


RAD-модель Модель быстрой разработки приложений (Rapid Application Development) является примером адаптивного процесса в рамках реализации инкрементной стратегии Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойема и Скотта Шульца
Описание слайда:
RAD-модель Модель быстрой разработки приложений (Rapid Application Development) является примером адаптивного процесса в рамках реализации инкрементной стратегии Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойема и Скотта Шульца

Слайд 39


Цели RAD-модели Основными целями RAD-модели процесса разработки ПО являются: высокая скорость разработки; низкая стоимость; высокое качество
Описание слайда:
Цели RAD-модели Основными целями RAD-модели процесса разработки ПО являются: высокая скорость разработки; низкая стоимость; высокое качество

Слайд 40


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

Слайд 41


Основные принципы RAD Разработка системы и предъявление ее заказчику осуществляется в виде последовательности развиваемых прототипов RAD-группа всегда работает только над одним прототипом. Это обеспечивает единство целей, лучшую наблюдаемость и управляемость процессом разработки
Описание слайда:
Основные принципы RAD Разработка системы и предъявление ее заказчику осуществляется в виде последовательности развиваемых прототипов RAD-группа всегда работает только над одним прототипом. Это обеспечивает единство целей, лучшую наблюдаемость и управляемость процессом разработки

Слайд 42


Основные принципы RAD RAD-группы должны использовать общие стандарты Обязательно финальное тестирование полной системы Обязательно использование инструментальных средств, автоматизирующих процесс разработки – визуальных сред проектирования и программирования
Описание слайда:
Основные принципы RAD RAD-группы должны использовать общие стандарты Обязательно финальное тестирование полной системы Обязательно использование инструментальных средств, автоматизирующих процесс разработки – визуальных сред проектирования и программирования

Слайд 43


RAD-модель
Описание слайда:
RAD-модель

Слайд 44


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

Слайд 45


Прототипы Традиционно для проектов ПО средней сложности разрабатываются три прототипа: первый содержит весь пользовательский интерфейс с нулевой функциональностью; он дает возможность утвердить у заказчика экранные и отчетные формы; второй прототип содержит реализованную на 70-80% функциональность системы третий прототип содержит полностью реализованную функциональность
Описание слайда:
Прототипы Традиционно для проектов ПО средней сложности разрабатываются три прототипа: первый содержит весь пользовательский интерфейс с нулевой функциональностью; он дает возможность утвердить у заказчика экранные и отчетные формы; второй прототип содержит реализованную на 70-80% функциональность системы третий прототип содержит полностью реализованную функциональность

Слайд 46


Итерации Основаниями для очередной итерации в процессе разработки являются: Замечания заказчика. Если замечания носят характер исправлений, они учитываются в следующем прототипе, если же изменяются требования, то выполняется переоценка проекта и корректируются сроки и стоимость проекта
Описание слайда:
Итерации Основаниями для очередной итерации в процессе разработки являются: Замечания заказчика. Если замечания носят характер исправлений, они учитываются в следующем прототипе, если же изменяются требования, то выполняется переоценка проекта и корректируются сроки и стоимость проекта

Слайд 47


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

Слайд 48


Когда применяется RAD Применение технологии RAD целесообразно, когда: требуется выполнение проекта в сжатые сроки (90 дней); быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня нечетко определены требования к ПО; в большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО
Описание слайда:
Когда применяется RAD Применение технологии RAD целесообразно, когда: требуется выполнение проекта в сжатые сроки (90 дней); быстрое выполнение проекта позволяет создать систему, отвечающую требованиям сегодняшнего дня нечетко определены требования к ПО; в большинстве случаев заказчик весьма приблизительно представляет себе работу будущего программного продукта и не может четко сформулировать все требования к ПО

Слайд 49


Когда применяется RAD проект выполняется в условиях ограниченности бюджета; разработка ведется небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения интерфейс пользователя (GUI) есть главный фактор; RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта
Описание слайда:
Когда применяется RAD проект выполняется в условиях ограниченности бюджета; разработка ведется небольшими RAD-группами в короткие сроки, что обеспечивает минимум трудозатрат и позволяет вписаться в бюджетные ограничения интерфейс пользователя (GUI) есть главный фактор; RAD-технология дает возможность продемонстрировать интерфейс в прототипе, причем достаточно скоро после начала проекта

Слайд 50


Когда применяется RAD проект большой, но поддается разделению на более мелкие функциональные компоненты ПО не обладает большой вычислительной сложностью
Описание слайда:
Когда применяется RAD проект большой, но поддается разделению на более мелкие функциональные компоненты ПО не обладает большой вычислительной сложностью

Слайд 51


RAD не применяется В проектах, где требования к программному продукту четко определены и не должны меняться, и, следовательно, вовлечение заказчика в процесс разработки не требуется В проектах, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик
Описание слайда:
RAD не применяется В проектах, где требования к программному продукту четко определены и не должны меняться, и, следовательно, вовлечение заказчика в процесс разработки не требуется В проектах, сложность которых определяется необходимостью реализации сложных алгоритмов, а роль и объем пользовательского интерфейса невелик

Слайд 52


Сравнение двух моделей
Описание слайда:
Сравнение двух моделей

Слайд 53


Характеристика модели Основным достоинством модели является уменьшение сроков разработки Ее главный недостаток заключается в необходимости использования большого числа квалифицированных разработчиков, что может существенно повысить стоимость разработки
Описание слайда:
Характеристика модели Основным достоинством модели является уменьшение сроков разработки Ее главный недостаток заключается в необходимости использования большого числа квалифицированных разработчиков, что может существенно повысить стоимость разработки

Слайд 54


Конец лекции
Описание слайда:
Конец лекции

Скачать

Похожие презентации
Mypresentation.ru
Загрузить презентацию