Презентация на тему "Модели разработки ПО"

Содержание

• 
  Слайд 1

  Модели разработки ПО

  Тема 2.1

• 
  Слайд 2

  Модели разработки ПО

• 
  Слайд 3

  Семейство каскадных моделей: простая каскадная модель

• 
  Слайд 4

  Принципы каскадной модели

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

• 
  Слайд 5

  Преимущества каскадной модели

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

• 
  Слайд 6

  Недостатки каскадной модели

  Попытка вернуться на одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному увеличению затрат и сбою в графике Интеграция компонент, на которой обычно выявляется большая часть ошибок, выполняется в конце разработки, что сильно увеличивает стоимость устранения ошибок Запаздывание с получением результатов – если в процессе выполнения проекта требования изменились, то получится устаревший результат

• 
  Слайд 7

  Семейство каскадных моделей: каскадно - возвратная модель

• 
  Слайд 8

  Семейство итерационных моделей: спиральные модели

• 
  Слайд 9

  Основные принципы спиральной модели

  Разработка вариантов продукта, соответствующих различным вариантам требований с возможностью вернуться к более ранним вариантам Создание прототипов ПО как средства общения с заказчиком для уточнения и выявления требований Планирование следующих вариантов с оценкой альтернатив и анализом рисков, связанных с переходом к следующему варианту Переход к разработке следующего варианта до завершения предыдущего в случае, когда риск завершения очередного варианта (прототипа) становится неоправданно высок. Использование каскадной модели как схемы разработки очередного варианта Активное привлечение заказчика к работе над проектом. Заказчик участвует в оценке очередного прототипа ПО, уточнении требований при переходе к следующему, оценке предложенных альтернатив очередного варианта и оценке рисков

• 
  Слайд 10

  Спиральная разработка

• 
  Слайд 11

  Преимущества спиральной модели

  Более тщательное проектирование (несколько начальных итераций) с оценкой результатов проектирования, что позволяет выявить ошибки проектирования на более ранних стадиях. Поэтапное уточнение требований в процессе выполнения итераций, что позволяет более точно удовлетворить требованиям заказчика Участие заказчика в выполнении проекта с использованием прототипов программы. Заказчик видит, что и как создается, не выдвигает необоснованных требований, оценивает реальные объемы финансирования Планирование и управление рисками при переходе на следующие итерации позволяет разумно планировать использование ресурсов и обосновывать финансирование работ. Возможность разработки сложного проекта «по частям», выделяя на первых этапах наиболее значимые требования.

• 
  Слайд 12

  Недостатки спиральной модели

  Сложность анализа и оценки рисков при выборе вариантов. Сложность поддержания версий продукта (хранение версий, возврат к ранним версиям, комбинация версий) Сложность оценки точки перехода на следующий цикл Бесконечность модели – на каждом витке заказчик может выдвигать новые требования, которые приводят к необходимости следующего цикла разработки

• 
  Слайд 13

  Семейство итерационных моделей: каркасная модель разработки

• 
  Слайд 14

  Другие модели: сборочное программирование

• 
  Слайд 15

  Другие модели: исследовательское программирование

• 
  Слайд 16

  Модель разработки Microsoft Solution Framework

  В технологии MSF большое внимание уделяется анализу проблем заказчика и разработке вариантов системы для поиска решения этих проблем

• 
  Слайд 17

  «Вехи» MSF

  Модель MSF ориентирована на “вехи” (milestones) – ключевые точки проекта, характеризующие достижение какого-либо существенного результата Результат может быть оценен и проанализирован, что подразумевает ответ на вопрос: “А достигли ли мы целей, поставленных на этом шаге?» В модели предусматривается наличие основных вех (завершение главных фаз модели) и промежуточных, отражающих внутренние этапы главных фаз

• 
  Слайд 18

  Фазы MSF: выработка концепции

  Создание общей картины приложения (Envisioning).На этом этапе решаются следующие основные задачи: оценка существующей ситуации; определение состава команды, структуры проекта, бизнес-целей, требований и профилей пользователей; разработка концепции решения и оценка риска. Устанавливаются две промежуточные вехи: "Организован костяк команды" и "Создана общая картина решения".

• 
  Слайд 19
  
• 
  Слайд 20

  Фазы MSF: Планирование (Planning)

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

• 
  Слайд 21

  Фазы MSF: Разработка (Developing)

  Создается вариант решения проблемы, в виде кода и документации очередного прототипа, включая спецификации и сценарии тестирования. Основная веха этапа - "Окончательное утверждение области действия проекта". Продукт готов к внешнему тестированию и стабилизации. Заказчики, пользователи, сотрудники службы поддержки и сопровождения, а также ключевые участники проекта могут предварительно оценить продукт и указать все недостатки, которые нужно устранить до его поставки.

• 
  Слайд 22

  Фазы MSF: Стабилизация (Stabilizing)

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

• 
  Слайд 23

  Фазы MSF: Развертывание (Deploying)

  Выполняется установка решения и необходимых компонентов окружения, проводится его стабилизация в промышленных условиях и передача проекта в руки группы сопровождения. Анализируется проект в целом на предмет уровня удовлетворенности заказчика.

• 
  Слайд 24

  Ключевые идеи RUP

  весь ход работ направляется итоговыми целями проекта, выраженными в виде вариантов использования (usecases) – сценариев взаимодействия результирующей программной системы с пользователями или другими системами, при выполнении которых пользователи получают значимые для них результаты и услуги. Разработка начинается с выделения вариантов использования и на каждом шаге контролируется степенью приближения к их реализации; основным решением, принимаемым в ходе проекта, является архитектура результирующей программной системы. Архитектура устанавливает набор компонентов, из которых будет построено ПО, ответственность каждого из компонентов (т.е. решаемые им подзадачи в рамках общих задач системы), четко определяет интерфейсы, через которые они могут взаимодействовать, а также способы взаимодействия компонентов друг с другом; архитектура является одновременно основой для получения качественного ПО и базой для планирования работ и оценок проекта в терминах времени и ресурсов, необходимых для достижения определенных результатов. Она оформляется в виде набора графических моделей на языке UML; основой процесса разработки являются планируемые и управляемые итерации, объем которых (реализуемая в рамках итерации функциональность и набор компонентов) определяется на основе архитектуры.

• 
  Слайд 25

  Фазы жизненного цикла RUP

  Фаза начала проекта (Inception) Фаза проектирования (Elaboration) Фаза построения (Construction) Фаза внедрения (Transition)

• 
  Слайд 26

  Фаза начала проекта

  Основная цель этой фазы – достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов. На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения – технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта. На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла.

• 
  Слайд 27

  Пример хода работ на фазе начала проекта

• 
  Слайд 28

  Фаза проектирования

  Основная цель этой фазы – на базе основных, наиболее существенных требований разработать стабильную базовую архитектуру продукта, которая позволяет решать поставленные перед системой задачи и в дальнейшем используется как основа разработки системы. На эту фазу может уходить около 30% времени и 20% трудоемкости одного цикла.

• 
  Слайд 29

  Пример хода работ на фазе проектирования

• 
  Слайд 30

  Фаза построения

  Основная цель этой фазы – детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования. На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.

• 
  Слайд 31

  Пример хода работ на фазе построения

• 
  Слайд 32

  Фаза внедрения

  Цель этой фазы – сделать систему полностью доступной конечным пользователям. На этой стадии происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей. На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.

• 
  Слайд 33

  Пример хода работ на фазе внедрения

• 
  Слайд 34

  Основные артефакты проекта по RUP и потоки данных между ними

• 
  Слайд 35

  Дисциплины RUP: определение

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

• 
  Слайд 36

  Рабочие дисциплины RUP

  Моделирование предметной области (бизнес-моделирование, Business Modeling) Задачи этой деятельности – понять предметную область или бизнес-контекст, в которых должна будет работать система, и убедиться, что все заинтересованные лица понимают его одинаково, осознать имеющиеся проблемы, оценить их возможные решения и их последствия для бизнеса организации, в которой будет работать система. В результате моделирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы). Эта модель служит основой модели анализа. Определение требований (Requirements) Задачи – понять, что должна делать система, и убедиться во взаимопонимании по этому поводу между заинтересованными лицами, определить границы системы и основу для планирования проекта и оценок затрат ресурсов в нем. Требования принято фиксировать в виде модели вариантов использования. Анализ и проектирование (Analysis and Design) Задачи – выработать архитектуру системы на основе требований, убедиться, что данная архитектура может быть основой работающей системы в контексте ее будущего использования. В результате проектирования должна появиться модель проектирования, включающая диаграммы классов системы, диаграммы ее компонентов, диаграммы взаимодействий между объектами в ходе реализации вариантов использования, диаграммы состояний для отдельных объектов и диаграммы развертывания. Реализация (Implementation) Задачи – определить структуру исходного кода системы, разработать код ее компонентов и протестировать их, интегрировать систему в работающее целое. Тестирование (Test) Задачи – найти и описать дефекты системы (проявления недостатков ее качества), оценить ее качество в целом, оценить, выполнены или нет гипотезы, лежащие в основе проектирования, оценить степень соответствия системы требованиям.

• 
  Слайд 37

  Поддерживающие дисциплины

  Развертывание (Deployment) Задачи – установить систему в ее рабочем окружении и оценить ее работоспособность на том месте, где она должна будет работать. Управление конфигурациями и изменениями (Configuration and Change Management) Задачи – определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. Управление проектом (Project Management) Задачи – планирование, управление персоналом, обеспечение взаимодействия на благо проекта между всеми заинтересованными лицами, управление рисками, отслеживание текущего состояния проекта. Управление средой проекта (Environment) Задачи – подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте.

• 
  Слайд 38

  Распределение работ между различными дисциплинами в проекте по RUP

• 
  Слайд 39

  Экстремальное программирование

  возникло как эволюционный метод разработки ПО "снизу вверх" является примером так называемого метода "живой" разработки (Agile Development Method) в группу "живых" методов входят, помимо экстремального программирования, методы SCRUM, DSDM (Dynamic Systems Development Method, метод разработки динамичных систем), Feature-Driven Development (разработка, управляемая функциями системы) и др.

• 
  Слайд 40

  Основные принципы "живой" разработки ПО

  Люди, участвующие в проекте, и их общение более важны, чем процессы и инструменты. Работающая программа более важна, чем исчерпывающая документация. Сотрудничество с заказчиком более важно, чем обсуждение деталей контракта. Отработка изменений более важна, чем следование планам.

• 
  Слайд 41

  Схема потока работ в XP

• 
  Слайд 42

  Достоинства и недостатки

  Достоинствами XP, если его удается применить, является большая гибкость, возможность быстро и аккуратно вносить изменения в ПО в ответ на изменения требований и отдельные пожелания заказчиков, высокое качество получающегося в результате кода и отсутствие необходимости убеждать заказчиков в том, что результат соответствует их ожиданиям. Недостатками этого подхода являются невыполнимость в таком стиле достаточно больших и сложных проектов, невозможность планировать сроки и трудоемкость проекта на достаточно долгую перспективу и четко предсказать результаты длительного проекта в терминах соотношения качества результата и затрат времени и ресурсов. Также можно отметить неприспособленность XP для тех случаев, в которых возможные решения не находятся сразу на основе ранее полученного опыта, а требуют проведения предварительных исследований.