Лаборатория информационных технологий (ИТЛаб) При поддержке фирмы Intel Учебно-исследовательский проект Обзор моделей жизненного цикла разработки программного. - презентация

1 Лаборатория информационных технологий (ИТЛаб) При поддержке фирмы Intel Учебно-исследовательский проект Обзор моделей жизненного цикла разработки программного обеспечения Куратор проекта: Карпенко С.Н. Разработчики: Вершинина Е.В. Гонченко М.С. Нижний Новгород 2004г.

2 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО2 Введение Для разработки продукта в проекте должен применяться процесс. Вместо создания каждого проекта «с нуля» можно выбрать «начальный» жизненный цикл. Жизненный цикл – это «карта-путеводитель» для всех участников проекта. Модель ЖЦ разработки ПО является единственным видом процесса, в котором представлен порядок его осуществления.

3 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО3 Обобщенная схема жизненного цикла Фаза План Спецификация Разработка Эксплуатация Действие Разработка проекта Код Тестирование модуля Тестирование системы

4 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО4 Модели ЖЦ разработки ПО Каскадная V – образная Модель быстрого прототипирования RAD – модель Инкрементная Спиральная Адаптированные модели

5 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО5 Каскадная модель Это была первая модель, которая придала особое значение исходным требованиям и проектированию. Попытки оптимизации данной модели привели к возникновению других циклов разработки ПО. Конспект

6 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО6 Каскадная модель – описание фаз Исследование концепции Процесс системного распределения Процесс определения требований Процесс разработки проекта Процесс реализации Процесс установки Процесс эксплуатации и поддержки Процесс сопровождения Процесс вывода из эксплуатации Интегральные задачи

7 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО7 Каскадная модель – преимущества Хорошо известна потребителям Упорядоченно справляется со сложностями Удобна в применении Стабильность требований Дефекты можно обнаружить на ранних этапах Доступна для понимания Хорошо определены стадии модели Легко проследить ход выполнения проекта

8 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО8 Каскадная модель – недостатки В основе - последовательная линейная структура Требования должны быть известны вначале Процесс обучения происходит в конце ЖЦ Замораживание результативных данных по завершению каждой фазы Интеграция полученных результатов происходит на завершающей стадии работы модели Клиент не может ознакомиться с системой заранее Программный продукт разрабатывается за один раз

9 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО9 Каскадная модель – область применения В ситуациях, в которых требования и их реализация четко определены При переносе уже существующего продукта на новую платформу При выполнении больших проектов, в которых задействовано несколько больших команд разработчиков

10 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО10 V - образная модель В модели особое значение придается действиям, направленным на верификацию и аттестацию продукта После кодирования следуют фазы тестирования Эта модель была разработана как разновидность каскадной модели Конспект

11 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО11 V –образная модель жизненного цикла разработки ПО

12 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО12 V - образная модель – описание фаз Планирование проекта и требований Анализ требований к продукту Архитектура или проектирование на высшем уровне Детализированная разработка проекта Разработка программного кода Модульное тестирование Интеграция и тестирование Системное и приемочное тестирование Производство, эксплуатация и сопровождение Приемочные испытания

13 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО13 V – образная модель – преимущества Особое значение придается планированию Определяет продукты, которые должны быть получены в результате процесса разработки Предусмотрены аттестация и верификация и внешних полученных данных Определение требований – перед разработкой проекта системы Проектирование ПО – перед разработкой компонентов Можно отслеживать ход процесса разработки Проста в использовании

14 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО14 V - образная модель – недостатки Плохо справляется с параллельными событиями Не учтены итерации между фазами Поздно происходит тестирование требований Не предусмотрено внесение требования динамических изменений Не содержит действий, направленных на анализ рисков

15 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО15 V - образная модель – область применения В ситуациях, в которых информация о требованиях доступна заранее В случае, когда доступными являются информация о методе реализации решения и технология В системах, в которых требуется высокая надежность

16 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО16 Модель быстрого прототипирования Конспект

17 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО17 Модель быстрого прототипирования– преимущества Взаимодействие заказчика с системой начинается на раннем этапе разработки В процессе разработки можно внести новые требования Можно выявить проблему до привлечения дополнительных ресурсов Позволяет выполнять гибкое проектирование и разработку Позволяет максимально уменьшить количество неточностей в требованиях Небольшой объем доработок

18 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО18 Модель быстрого прототипирования– недостатки Репутация «разработанного на скорую руку» метода Может быть уделено недостаточно внимания качеству ПО или долгосрочной надежности Решение трудных проблем может отодвигаться на будущее При досрочном завершении проекта у пользователя останется только частичная система Прототипирование вызывает зависимость Нет информации о точном числе итераций

19 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО19 Модель быстрого прототипирования– область применения Требования не известны заранее Требования непостоянны Есть потребность в разработке пользовательских интерфейсов Выполняется не имеющая аналогов разработка Осуществляются временные демонстрации При средней и высокой степенях риска Применяется с каскадной моделью Вместе с элементами анализа и проектирования

20 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО20 Модель быстрой разработки приложений RAD (Rapid Application Development) Пользователь задействован на всех фазах ЖЦ Короткое время перехода от определения требований до создания полной системы Разработка продукта ограничивается 60 днями, называемыми временным блоком Использование мощных инструментальных средств разработки, высокий уровень фактора использования Конспект

21 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО21 Модель RAD – описание фаз

22 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО22 Модель RAD – преимущества Время цикла разработки проекта сокращается Требуется меньшее количество специалистов Уменьшаются затраты Создается обратная связь Повторно используются компоненты уже существующих программ Возможно произвести быстрый изначальный просмотр продукта

23 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО23 Модель RAD – недостатки Необходимо достаточное количество высококвалифицирован- ных разработчиков Неудачна при отсутствии компонент для повторного использования Требуются быстрые действия из-за жестких временных ограничений Необходим эффективный ускоренный процесс разработки; При использовании "вслепую" затраты не ограничены

24 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО24 Модель RAD – область применения В моделируемых и масштабируемых системах Требования хорошо известны При невысокой степени технических рисков В информационных системах При выполнении проектов в сокращенные сроки Пригодные к повторному использованию части можно легко получить В системах небольшого размера Затраты и соблюдение графика не являются самым важным вопросом

25 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО25 Инкрементная модель Это процесс частичной реализации всей системы и медленного наращивания функциональных возможностей. На ранних этапах выполняется конструирование системы в целом Модель эффективна при использовании как в случае чрезвычайно больших, так и в небольших проектов. Конспект

26 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО26 Инкрементная модель Выполнимость системы План и требо- вания к ПО Разработка про- екта продукта Аттестация Инкремент 3 Верифи- кация Инкремент 2Инкремент 1

27 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО27 Инкрементная модель Инкремент Детализирован ная разработка проекта Кодирова- ние Интегра- ция Внедре- ние Эксплуатация и сопровождение Верификация Модульное тестирование Верификация прогр. продукта Системное тестирование Повторная аттестация

28 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО28 Инкрементная модель – описание фаз Кодирование Тестирование Поставка Планирование Анализ Разработка

29 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО29 Инкрементная модель – преимущества Не требуется заранее тратить средства, необходимые для разработки всего проекта При выполнении каждого инкремента получается функциональный продукт Заказчик может высказаться по поводу каждой разработанной версии системы Существует возможность поддерживать постоянный прогресс в ходе выполнения проекта Снижаются затраты на первоначальную поставку программного продукта Снижается риск неудачи и изменения требований Риск распределяется на несколько меньших по размеру инкрементов

30 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО30 Инкрементная модель – недостатки Не предусмотрены итерации в рамках каждого инкремента Определение полной функциональной системы должно осуществляться в начале ЖЦ Может возникнуть оттягивание решений трудных проблем на будущее Для инкрементов трудно выполнить анализ и проверку

31 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО31 Инкрементная модель – область применения Требования можно сформулировать заранее Существует потребность быстро поставить на рынок продукт На выполнение проектов предусмотрен большой период времени разработки При равномерном распределении свойств различной степени важности При выполнении проекта с применением новой технологии

32 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО32 Спиральная модель Воплощает в себе преимущества каскадной модели Включены анализ рисков, управление ими, процессы поддержки и менеджмента Разработка продукта с использованием метода прототипирования или быстрой разработки приложения Каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса. Конспект

33 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО33 Спиральная модель

34 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО34 Спиральная модель – описание стадий Определение целей, альтернативных вариантов и ограничений Оценка альтернативных вариантов, идентификация и разрешение рисков Разработка продукта следующего уровня Планирование следующей фазы

35 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО35 Спиральная модель – преимущества Модель разрешает пользователям "увидеть" систему на ранних этапах Обеспечивается определение непреодолимых рисков Пользователи принимают участие при планировании, анализе рисков, разработке Предусмотрена возможность гибкого проектирования Обеспечивается разбиение большого объема работы по разработке продукта на небольшие части Обратная связь от пользователей к разработчикам выполняется с высокой частотой и на ранних этапах модели Не нужно распределять заранее финансовые ресурсы

36 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО36 Спиральная модель – недостатки При низкой степени риска или небольших размерах, модель может оказаться дорогостоящей Модель имеет усложненную структуру Нужда в высоко профессиональных знаниях для оценки рисков Спираль может продолжаться до бесконечности

37 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО37 Спиральная модель – область применения Для средней или высокой степени риска Когда пользователи не уверены в своих потребностях Когда ожидаются существенные изменения Когда речь идет о применении новой технологии В случае больших проектов При выполнении бизнес- проектов и проектов в области аэрокосмической промышленности, обороны и инжиниринга

38 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО38 Адаптированные модели Быстрое отслеживание. Параллельный инжиниринг. Спиральная модель "Win-Win". Эволюционный/инкрементный принцип. Принцип V-образной инкрементной модели. Конспект

39 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО39 Быстрое отслеживание. Ускоренное прохождение или пропуск фаз жизненного цикла или процессов разработки; Необходимость в применении возникает в случае критической нехватки времени; ЖЦ обычно является менее формальным. Адаптированные модели

40 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО40 Параллельный инжиниринг. Создание продуктов более высокого качества за меньший период времени; Все аспекты ЖЦ проекта учитываются в процессе от проектирования до производства как можно раньше; Состоит из нескольких действий, которые осуществляются одновременно; Необходимо оценивать возможные технические риски при использовании метода. Адаптированные модели

41 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО41 Спиральная модель "Win-Win". К начальной фазе каждого цикла добавляются так называемые действия Теории W; Теория W это принцип менеджмента, при реализации которого особое значение придается ключевым организаторам совместного дела, выполняющим разработку системы (пользователь, заказчик, разработчик, наладчик, создатель интерфейсов и т.д.), которые станут "победителями", если проект окажется успешным. Адаптированные модели

42 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО42 Спиральная модель "Win-Win" – описание фаз Определение участников следующего уровня; Определение условий, необходимых для одержания участниками победы; Согласование "победных" условий; Формулирование целей, ограничений и альтернативных вариантов следующего уровня; Оценка альтернативных вариантов на уровне продукта и процесса, разрешение рисков; Определение следующего уровня продукта и процесса, включая сегментацию; Обоснование определений продукта и процесса; Обзор и комментарии.

43 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО43 Спиральная модель "Win-Win" - преимущества Более быстрая разработка ПО; Уменьшение стоимости программ; Более высокий уровень удовлетворения со стороны участников проекта; Более высокое качество ПО; Исследование большого количества вариантов построения архитектуры на ранних этапах разработки. Адаптированные модели

44 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО44 Эволюционный/инкрементный принцип. Разработка программного продукта при использовании принципа часто затруднена; Каждая инкрементная конструкция реализует небольшую часть возможностей разрабатываемой системы Адаптированные модели

45 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО45 Принцип V-образной инкрементной модели. В модели предпринята попытка сбалансировать потребность в административном контроле с нуждами в технической инновации Контрольные точки представляют собой механизмы, определяющие совместное принятие менеджерами и разработчиками решений по переходу к следующей фазе со стороны Вместе с периодическим проведением руководством обзоров и предварительных просмотров, контрольные точки побуждают к обсуждению вопросов, рисков и альтернатив Адаптированные модели

46 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО46 Выбор приемлемой модели ЖЦ разработки ПО 1. Проанализировать отличительные категории проекта.отличительные категории 2. Ответить на вопросы каждой категории, обведя кружочком слова "да" или "нет". 3. Расположить по степени важности категории или вопросы, относящиеся к каждой категории, относительно проекта. 4. Воспользоваться упорядоченными категориями для разрешения противоречий, возникающих при сравнении моделей. Конспект

47 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО47 Отличительные категории Требования Команда разработчиков Коллектив пользователей Тип проекта и риски

48 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО48 Отличительные категории - требования Требования Каскад- ная V-образ- ная Прототи пирова ние Спира льная RAD Инкрем ентная Являются ли требова- ния легко определи- мыми и/или хорошо известными? Да Нет ДаНет Могут ли требования заранее определяться в цикле? Да Нет Да Часто ли будут изме- няться требования в цикле? Нет Да Нет Нужно ли демонстри- ровать требования с целью определения? Нет Да Нет

49 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО49 Отличительные категории – требования (продолжение) Требования Каскад ная V-образ ная Прототи пирова ние Спира льная RAD Инкрем ентная Требуются ли для де- монстрации возмож- ностей проверка кон- цепции? Нет Да Нет Будут ли требования отражать сложность системы? Нет Да НетДа Обладает ли требова- ние функциональны- ми свойствами на раннем этапе? Нет Да Отличительные категории

50 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО50 Отличительные категории – команда разработчиков Команда разработчиков Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Являются ли пробле- мы предметной облас- ти проекта новыми для большинства раз- работчиков? Нет ДатДаНет Является ли техноло- гия предметной об- ласти проекта новой для большинства раз- работчиков? Да НетДаНетДа Изменяются ли роли участников проекта во время ЖЦ? Нет Да НетДа

51 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО51 Отличительные категории – команда разработчиков (продолжение) Команда разработчиков Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Являются ли инстру- менты, используемые проектом, новыми для большинства разра-ботчиков? Да НетДаНет Могут ли разработчи- ки проекта пройти обучение? НетДаНет Да Является ли структу- ра более значимой для разработчиков, чем гибкость? Да Нет Да

52 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО52 Отличительные категории – команда разработчиков (конец) Команда разработчиков Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Будет ли менеджер проекта строго отсле- живать прогресс ко- манды? Да НетДаНетДа Важна ли легкость распределения ресур- сов? Да Нет Да Приемлет ли команда равноправные обзоры и инспекции, менедж- мент/обзоры заказчи- ка, а также стадии? Да НетДа Отличительные категории

53 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО53 Отличительные категории – коллектив пользователей Коллектив пользователей Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Будет ли присутствие пользователей огра- ничено в жизненном цикле? Да НетДаНетДа Будут ли пользовате- ли знакомы с опреде- лением системы? Нет Да НетДа Буду ли пользователи ознакомлены с проб- лемами предметной области? Нет ДаНетДа

54 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО54 Отличительные категории – коллектив пользователей (продолжение) Коллектив пользователей Каскад- ная V-образ- ная Прототи - пирова- ние Спирал ь ная RAD Инкре- ментна я Будут ли пользовате- ли вовлечены во все фазы жизненного цикла? Нет ДаНетДаНет Будет ли заказчик от- слеживать ход выпол- нения проекта? Нет Да Нет Отличительные категории

55 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО55 Отличительные категории – тип проекта и риски Тип проекта и риски Каскад ная V-образ- ная Прототи пирова ние Спира льная RAD Инкре ментна я Будет ли проект иден- тифицировать новое направление продукта для организации? Нет Да НетДа Будет ли проект име- ть тип системной ин- теграции? НетДа Будет ли проект яв- ляться расширением существующей систе- мы? НетДаНет Да Должна ли быть вы- сокая степень надеж- ности? НетДаНетДаНетДа

56 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО56 Отличительные категории – тип проекта и риски (продолжение) Тип проекта и риски Каскад ная V-образ- ная Прототи пирова- ние Спираль ная RAD Инкре- ментна я Будет ли финансиро- вание проекта ста- бильным на всем про- тяжении ЖЦ? Да НетДаНет Ожидается ли дли- тельная эксплуатация продукта в организа- ции? Да НетДаНетДа Будет ли система из- меняться с применением непредвиденных методов, на этапе со- провождения? Нет Да НетДа Является ли график ограниченным? Нет Да

57 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО57 Отличительные категории – тип проекта и риски (конец) Тип проекта и риски Каскад- ная V-образ- ная Прототи пирова- ние Спира льная RAD Инкрем ентная Будет ли проект иден- тифицировать новое направление продукта для организации? Нет Да НетДа Являются ли "проз- рачными" интерфейс- ные модули? Да Нет Да Доступны ли повтор- но используемые ком- поненты? Нет Да Нет Являются ли доста- точными ресурсы (время, деньги, инст- рументы, персонал)? Нет Да Нет Отличительные категории

58 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО58 Подгонка модели жизненного цикла разработки ПО 1. Ознакомьтесь с различными моделями. 2. Просмотрите и проанализируйте возможные виды работ: разработка, модернизация, сопровождение и т.д. 3. Выберите самый подходящий жизненный цикл, используя матрицы критериев: высокая степень риска, пользовательский интерфейс, высокая надежность, время доставки на рынок/выпуска продукта, приоритеты пользователя, уточнение требований, ожидаемый срок эксплуатации системы, технология, размер и сложность, возможный параллелизм, интерфейсы для существующих и новых систем.

59 (c)ИТЛаб, ННГУ, ВМК, 2004г.Обзор моделей ЖЦ разработки ПО59 Подгонка модели жизненного цикла разработки ПО 4. Проанализируйте, насколько выбранный жизненный цикл соответствует стандартам организации, заказчиков или типа проекта ISO, IEEE и т.д. 5. Сформулируйте набор фаз и действий, образующих каждую фазу. 6. Определите внутренние и внешние производимые продукты. 7. Определите шаблоны и внутреннее содержимое поставляемых продуктов. 8. Определите действия по обзору, инспектированию, верификации и аттестации, а также стадии проекта. 9. Выполните оценку эффективности схемы жизненного цикла и проведите ее модернизацию там, где это необходимо.