- Главная
- Разное
- Дизайн
- Бизнес и предпринимательство
- Аналитика
- Образование
- Развлечения
- Красота и здоровье
- Финансы
- Государство
- Путешествия
- Спорт
- Недвижимость
- Армия
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Прогностические модели процесса разработки. (Лекция 3) презентация
Содержание
- 1. Прогностические модели процесса разработки. (Лекция 3)
- 2. Модели процесса разработки Наиболее интересной фазой жизненного
- 3. Модели процесса разработки Модель процесса разработки ПО
- 4. Выбор модели разработки Реальный процесс разработки обычно
- 5. Каскадная модель Наиболее широко известной и применяемой
- 6. Каскадная модель Предполагает строго последовательное поэтапное выполнение
- 7. Каскадная модель * Модели процесса разработки
- 8. Характеристика модели Достоинства модели: упорядоченность процесса разработки
- 9. Итеративные модели Итеративный подход – это выполнение
- 10. Инкрементная модель Предусматривает дробление продукта на относительно
- 11. Инкрементная модель * Модели процесса разработки
- 12. Достоинство модели Достоинством данной модели по сравнению
- 13. Недостатки модели Деление на функциональные блоки в
- 14. Недостатки модели Существенно усложняется управление проектом в
- 15. Спиральная модель Предложена в 1988 г. Барри
- 16. Спиральная модель * Модели процесса разработки
- 17. Основные действия модели Планирование заключается в определении
- 18. Основные действия модели Конструирование – это основное
- 19. Риски Отличительной особенностью спиральной модели является специальное
- 20. Риски При разработке ПО неудовлетворительным результатом может
- 21. Итерации и риски С каждой итерацией связан
- 22. Показатель риска Для ранжирования рисков по степени
- 23. Управление рисками Включает 6 действий: идентификация риска
- 24. Управление рисками разрешение риска – устранение риска;
- 25. Список рисков по Боэму дефицит специалистов;
- 26. Список рисков по Боэму недостатки в работах,
- 27. Характеристика модели Достоинства спиральной модели: данная модель
- 28. Характеристика модели Недостатки спиральной модели: повышенные требования
- 29. RUP-процесс разработки ПС RUP является развитием
- 30. Этапы разработки RUP выделяет в процессе разработки
- 31. Этапы и итерации В рамках каждого из
- 32. Контрольные вехи Каждый этап и итерация завершаются
- 33. Этап начала проекта (Inception) Основная цель этой
- 34. Ход работ для этапа Inception
- 35. Этап развития (Elaboration) Основная цель данного этапа
- 36. Ход работ для этапа Elaboration
- 37. Этап конструирования (Construction) Основная цель данного этапа
- 38. Ход работ для этапа Construction
- 39. Этап перехода (Transition) Цель данного этапа —
- 40. Ход работ для этапа Transition
- 41. Рабочие потоки Каждая итерация включает несколько рабочих
- 42. Распределение объемов работ
- 43. Моделирование предметной области В результате моделирования предметной
- 44. Определение требований Задачи этого рабочего потока: понять,
- 45. Анализ и проектирование Задачи этого рабочего потока:
- 46. Анализ и проектирование В результате проектирования должна
- 47. Реализация Задачи рабочего потока: определить структуру исходного
- 48. Тестирование Задачи рабочего потока Тестирование: поиск
- 49. Развертывание (Deployment) Задачи рабочего потока Развертывание: установка
- 50. Структура типовой итерации
- 51. Артефакты Каждый рабочий поток определяет набор связанных
- 52. Зависимости между артефактами
- 53. V-модель Концепция V-образной модели была разработана Германией
- 54. Схема V-модели * Модели процесса разработки
- 55. Особенности модели V-Model делает упор на тестирование
- 56. Достоинства Минимизация рисков V-модель делает проект более
- 57. Достоинства Уменьшение стоимости проекта Ресурсы на разработку,
- 58. Недостатки Модель не предусматривает работу с параллельными
- 59. Конец лекции * Модели процесса разработки
Слайд 2Модели процесса разработки
Наиболее интересной фазой жизненного цикла ПО с точки зрения
технологии программирования является фаза разработки
Особенности применяемых методов разработки описываются с помощью моделей процесса разработки ПО
Особенности применяемых методов разработки описываются с помощью моделей процесса разработки ПО
*
Модели процесса разработки
Слайд 3Модели процесса разработки
Модель процесса разработки ПО выделяет конкретные наборы видов деятельности,
артефактов, ролей и их взаимосвязи, а также дает рекомендации по организации процесса в целом
*
Модели процесса разработки
Слайд 4Выбор модели разработки
Реальный процесс разработки обычно жестко не увязывается с какой-либо
одной моделью, хотя одна из них может быть ведущей
Выбор модели определяется:
объемом и сложностью проекта;
количеством и качеством команды разработчиков
квалификацией заказчика, его способностью обеспечить достаточно четкую постановку задачи
Выбор модели определяется:
объемом и сложностью проекта;
количеством и качеством команды разработчиков
квалификацией заказчика, его способностью обеспечить достаточно четкую постановку задачи
*
Модели процесса разработки
Слайд 5Каскадная модель
Наиболее широко известной и применяемой долгое время оставалась так называемая
каскадная или водопадная (waterfall) модель жизненного цикла
Впервые четко сформулирована в 1970 году Уильямом Ройсом (W.W.Royce) и затем закреплена в стандартах Министерства обороны США
Впервые четко сформулирована в 1970 году Уильямом Ройсом (W.W.Royce) и затем закреплена в стандартах Министерства обороны США
*
Модели процесса разработки
Слайд 6Каскадная модель
Предполагает строго последовательное поэтапное выполнение различных видов деятельности с четким
определением границ между этапами
Набор документов, созданный на предыдущем этапе, передается в качестве входных данных для следующего этапа
Набор документов, созданный на предыдущем этапе, передается в качестве входных данных для следующего этапа
*
Модели процесса разработки
Слайд 7Каскадная модель
*
Модели процесса разработки
Выработка системных требований
Проектирование
Кодирование
Тестирование
Выработка требований к ПО
Анализ
Эксплуатация
Слайд 8Характеристика модели
Достоинства модели:
упорядоченность процесса разработки
возможность его строгого планирования во времени
Недостатки модели:
необходимость
точной и полной формулировки требований к ПС перед началом разработки
невозможность изменения решений, принятых на предыдущих этапах
результаты проекта становятся доступны заказчику только по завершении работ
невозможность изменения решений, принятых на предыдущих этапах
результаты проекта становятся доступны заказчику только по завершении работ
*
Модели процесса разработки
Слайд 9Итеративные модели
Итеративный подход – это выполнение работ параллельно с непрерывным анализом
полученных результатов и корректировкой предыдущих этапов
Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка
Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка
*
Модели процесса разработки
Слайд 10Инкрементная модель
Предусматривает дробление продукта на относительно независимые составляющие, которые разрабатываются и
вводятся в эксплуатацию по отдельности
*
Модели процесса разработки
Слайд 12Достоинство модели
Достоинством данной модели по сравнению с каскадной является возможность передать
заказчику работающий прототип системы до полного завершения процесса разработки
*
Модели процесса разработки
Слайд 13Недостатки модели
Деление на функциональные блоки в целом замедляет процесс, так как
возникает необходимость обеспечения их взаимодействия
Для многих решений этот метод неприменим, поскольку из них нельзя вычленить отдельные составляющие, которые могут быть поставлены и функционировать независимо
Для многих решений этот метод неприменим, поскольку из них нельзя вычленить отдельные составляющие, которые могут быть поставлены и функционировать независимо
*
Модели процесса разработки
Слайд 14Недостатки модели
Существенно усложняется управление проектом в связи с усложнением задач по
координированию работ над отдельными составляющими системы
Увеличивается стоимость внесения изменений в готовые компоненты, которые уже установлены и работают у заказчика
Увеличивается стоимость внесения изменений в готовые компоненты, которые уже установлены и работают у заказчика
*
Модели процесса разработки
Слайд 15Спиральная модель
Предложена в 1988 г. Барри Боэмом (Barry W. Boehm) и
является классическим примером реализации эволюционной стратегии.
Модель определяет четыре действия:
планирование,
анализ рисков,
конструирование,
оценивание
Модель определяет четыре действия:
планирование,
анализ рисков,
конструирование,
оценивание
*
Модели процесса разработки
Слайд 17Основные действия модели
Планирование заключается в определении целей очередной итерации процесса разработки,
выборе вариантов решения и оценки ограничений
Анализ рисков – анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов
Анализ рисков – анализ вариантов решения и оценка связанных с ними рисков, т.е. возможностей получения неудовлетворительных результатов
*
Модели процесса разработки
Слайд 18Основные действия модели
Конструирование – это основное действие, заключающееся в создании следующей
версии ПО
Оценивание – оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований
Оценивание – оценка заказчиком качества очередной версии ПО, внесение им предложений по модификации продукта, корректировка требований
*
Модели процесса разработки
Слайд 19Риски
Отличительной особенностью спиральной модели является специальное внимание рискам
Риском называется возможность получения
неудовлетворительного результата в том или ином виде деятельности
*
Модели процесса разработки
Слайд 20Риски
При разработке ПО неудовлетворительным результатом может быть:
превышение бюджета,
низкая надежность продукта,
неправильное функционирование
и пр.
Слайд 21Итерации и риски
С каждой итерацией связан некоторые начальные риски, которые уменьшаются
при успешном завершении итерации
Началу следующей итерации предшествует пересмотр и новая оценка рисков
Началу следующей итерации предшествует пересмотр и новая оценка рисков
Слайд 22Показатель риска
Для ранжирования рисков по степени значимости используют величину показатель риска
RE (Risk Exposure)
RE=P*L,
где P – вероятность неудовлетворительного результата, L – потеря (в10 или 100-балльной шкале) при получении неудовлетворительного результата
RE=P*L,
где P – вероятность неудовлетворительного результата, L – потеря (в10 или 100-балльной шкале) при получении неудовлетворительного результата
Слайд 23Управление рисками
Включает 6 действий:
идентификация риска – выявление риска в проекте;
анализ риска
– оценка вероятности и величины потери;
ранжирование рисков – упорядочение по степени влияния;
планирование управления рисками – подготовка к работе с каждым риском;
ранжирование рисков – упорядочение по степени влияния;
планирование управления рисками – подготовка к работе с каждым риском;
Слайд 24Управление рисками
разрешение риска – устранение риска;
наблюдение рисков – отслеживание динамики изменения
рисков, выполнение корректирующих действий
Боэм формулирует десять наиболее распространённых (по приоритетам) рисков
Боэм формулирует десять наиболее распространённых (по приоритетам) рисков
Слайд 25Список рисков по Боэму
дефицит специалистов;
нереалистичные сроки и бюджет;
реализация несоответствующей
функциональности;
разработка неправильного пользовательского интерфейса;
«золотая сервировка», ненужная оптимизация и оттачивание деталей;
непрекращающийся поток изменений;
нехватка информации о внешних компонентах;
разработка неправильного пользовательского интерфейса;
«золотая сервировка», ненужная оптимизация и оттачивание деталей;
непрекращающийся поток изменений;
нехватка информации о внешних компонентах;
*
Модели процесса разработки
Слайд 26Список рисков по Боэму
недостатки в работах, выполняемых внешними ресурсами;
недостаточная производительность
получаемой системы;
«разрыв» в квалификации специалистов разных областей знаний
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде
«разрыв» в квалификации специалистов разных областей знаний
Большая часть этих рисков связана с организационными и процессными аспектами взаимодействия специалистов в проектной команде
*
Модели процесса разработки
Слайд 27Характеристика модели
Достоинства спиральной модели:
данная модель отображает процесс разработки ПО в наиболее
реальном виде;
позволяет явно учитывать риски на каждом витке эволюционного процесса и принимать различные управленческие решения вплоть до прекращения работ
позволяет явно учитывать риски на каждом витке эволюционного процесса и принимать различные управленческие решения вплоть до прекращения работ
*
Модели процесса разработки
Слайд 28Характеристика модели
Недостатки спиральной модели:
повышенные требования к заказчику;
трудности контроля и управления временем
разработки
*
Модели процесса разработки
Слайд 29RUP-процесс разработки ПС
RUP является развитием спиральной модели и представляет процесс
разработки ПО в виде эволюционно-инкрементного цикла
Эволюционная составляющая цикла основывается на дополнении требований в ходе работы
Инкрементная составляющая – на планомерном приращении реализации требований
Эволюционная составляющая цикла основывается на дополнении требований в ходе работы
Инкрементная составляющая – на планомерном приращении реализации требований
Слайд 30Этапы разработки
RUP выделяет в процессе разработки 4 этапа:
начало (Inception)
развитие (Elaboration)
конструирование (Construction)
внедрение
(Transition)
Слайд 31Этапы и итерации
В рамках каждого из этапов возможно проведение нескольких итераций
Итерация
– это полный цикл разработки, имеющий своим результатом промежуточный продукт
На каждой итерации промежуточный продукт инкрементно усложняется, постепенно превращаясь в конечную систему
На каждой итерации промежуточный продукт инкрементно усложняется, постепенно превращаясь в конечную систему
Слайд 32Контрольные вехи
Каждый этап и итерация завершаются контрольной вехой
Контрольная веха – это
проверка состояния разработки с целью определения степени достижения ключевых целей
Слайд 33Этап начала проекта (Inception)
Основная цель этой этапа — достичь компромисса между
всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов
Определяются основные цели проекта, руководитель и бюджет, основные средства выполнения — технологии, инструменты, ключевые исполнители
Определяются основные цели проекта, руководитель и бюджет, основные средства выполнения — технологии, инструменты, ключевые исполнители
Слайд 35Этап развития (Elaboration)
Основная цель данного этапа — исходя из основных требований
разработать стабильную базовую архитектуру продукта
Эта архитектура в дальнейшем используется как основа разработки системы
Эта архитектура в дальнейшем используется как основа разработки системы
Слайд 37Этап конструирования (Construction)
Основная цель данного этапа — детальное прояснение требований и
разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры
В результате должна получиться система, реализующая все выделенные варианты использования
В результате должна получиться система, реализующая все выделенные варианты использования
Слайд 39Этап перехода (Transition)
Цель данного этапа — сделать систему полностью доступной конечным
пользователям
Здесь происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей.
Здесь происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей.
Слайд 41Рабочие потоки
Каждая итерация включает несколько рабочих потоков:
моделирование предметной области (Business Modeling);
определение
требований (Requirements);
анализ и проектирование (Analysis and Design);
реализация (Implementation);
тестирование (Test);
развертывание (Deployment);
анализ и проектирование (Analysis and Design);
реализация (Implementation);
тестирование (Test);
развертывание (Deployment);
Слайд 43Моделирование предметной области
В результате моделирования предметной области должна появиться ее модель
в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы)
Модель предметной области служит основой модели проектирования
Модель предметной области служит основой модели проектирования
Слайд 44Определение требований
Задачи этого рабочего потока:
понять, что должна делать система, и убедиться
во взаимопонимании по этому поводу между заинтересованными лицами;
определить границы системы;
создать основу для планирования проекта и оценок затрат ресурсов в нем.
Требования принято фиксировать в виде модели вариантов использования
определить границы системы;
создать основу для планирования проекта и оценок затрат ресурсов в нем.
Требования принято фиксировать в виде модели вариантов использования
Слайд 45Анализ и проектирование
Задачи этого рабочего потока:
разработка архитектуры системы на основе требований
убедиться,
что данная архитектура может быть основой работающей системы в контексте ее будущего использования
Слайд 46Анализ и проектирование
В результате проектирования должна появиться модель проектирования, включающая:
диаграммы классов
системы,
диаграммы ее компонентов,
диаграммы взаимодействий между объектами в ходе реализации вариантов использования,
диаграммы состояний для отдельных объектов,
диаграммы развертывания
диаграммы ее компонентов,
диаграммы взаимодействий между объектами в ходе реализации вариантов использования,
диаграммы состояний для отдельных объектов,
диаграммы развертывания
Слайд 47Реализация
Задачи рабочего потока:
определить структуру исходного кода системы,
разработать код ее компонентов
протестировать компоненты,
интегрировать систему в работающее целое
Слайд 48Тестирование
Задачи рабочего потока Тестирование:
поиск и описание дефектов системы (проявления недостатков
ее качества),
оценка ее качества в целом,
оценка степени выполнения гипотез, лежащих в основе проектирования,
оценка степени соответствия системы требованиям
оценка ее качества в целом,
оценка степени выполнения гипотез, лежащих в основе проектирования,
оценка степени соответствия системы требованиям
Слайд 49Развертывание (Deployment)
Задачи рабочего потока Развертывание:
установка системы в ее рабочем окружении,
оценка ее
работоспособность на том месте, где она должна будет работать
Слайд 51Артефакты
Каждый рабочий поток определяет набор связанных с ним артефактов
Артефакты, вырабатываемые в
ходе проекта, могут быть представлены:
в виде баз данных и таблиц с информацией различного типа,
разных видов документов,
исходного кода и объектных модулей,
моделей, состоящих из отдельных элементов
в виде баз данных и таблиц с информацией различного типа,
разных видов документов,
исходного кода и объектных модулей,
моделей, состоящих из отдельных элементов
Слайд 53V-модель
Концепция V-образной модели была разработана Германией и США в конце 1980-х
годов независимо друг от друга
Немецкая V-модель была разработана аэрокосмической компанией IABG, американская – Национальным советом по системной инженерии и предназначалась для спутниковых систем
Немецкая V-модель была разработана аэрокосмической компанией IABG, американская – Национальным советом по системной инженерии и предназначалась для спутниковых систем
*
Модели процесса разработки
Слайд 55Особенности модели
V-Model делает упор на тестирование как составную часть всех этапов
разработки, а также на разработку прототипов конечного продукта
Основной принцип V-модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени
Основной принцип V-модели заключается в том, что детализация проекта возрастает при движении слева направо, одновременно с течением времени
*
Модели процесса разработки
Слайд 56Достоинства
Минимизация рисков
V-модель делает проект более прозрачным и повышает качество контроля проекта,
что позволяет выявлять отклонения в проекте и риски на ранних стадиях
Повышение качества
V-модель является стандартизованной моделью разработки, что позволяет добиться от проекта результатов желаемого качества
Повышение качества
V-модель является стандартизованной моделью разработки, что позволяет добиться от проекта результатов желаемого качества
*
Модели процесса разработки
Слайд 57Достоинства
Уменьшение стоимости проекта
Ресурсы на разработку, производство, управление и поддержку могут быть
заранее просчитаны и проконтролированы.
Повышение качества коммуникации между участниками проекта
Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта
Повышение качества коммуникации между участниками проекта
Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта
*
Модели процесса разработки
Слайд 58Недостатки
Модель не предусматривает работу с параллельными событиями
В модель не входят действия,
направленные на анализ рисков
Результат разработки становится понятным только при достижении низа буквы V
Результат разработки становится понятным только при достижении низа буквы V
*
Модели процесса разработки
