Презентация - Модели жизненного цикла разработки ПО

Смотреть слайды в полном размере
Презентация Модели жизненного цикла разработки ПО


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

Презентация содержит 37 слайдов и доступна для скачивания в формате ppt. Размер скачиваемого файла: 991.50 KB

Просмотреть и скачать

Pic.1
Модели жизненного цикла разработки программного обеспечения Графов Павел, Литвинов Антон, Бутов Макс
Модели жизненного цикла разработки программного обеспечения Графов Павел, Литвинов Антон, Бутов Максим.
Pic.2
В истории технологии программирования можно выделить три этапа: Осмысление опыта разработки больших
В истории технологии программирования можно выделить три этапа: Осмысление опыта разработки больших систем. Разработка новых технологических подходов Принятие стандартов на состав процессов жизненного цикла программного обеспечения
Pic.3
Классификация технологических подходов Подходы со слабой формализацией. (code & fix) Cтрогие (кл
Классификация технологических подходов Подходы со слабой формализацией. (code & fix) Cтрогие (классические, жесткие, предсказуемые) подходы. (waterfall model, spiral model, etc. ) Гибкие (адаптивные, легкие) подходы. (evolutionary prototyping, iterative delivery, extreme programming, etc. )
Pic.4
Code & fix (подход со слабой формализацией) + нет затрат времени на проектирование - ошибки треб
Code & fix (подход со слабой формализацией) + нет затрат времени на проектирование - ошибки требуют повторного кодирования Как правило, это учебные или маленькие несложные проекты
Pic.5
WaTerFall model (каскадные технологические подходы – русск. ) анализ->проектирование->программ
WaTerFall model (каскадные технологические подходы – русск. ) анализ->проектирование->программирование->тестирование->сопровождение
Pic.6
Каскадный подход Его достоинства: модель доступна для понимания, проста и удобна; легко осуществлять
Каскадный подход Его достоинства: модель доступна для понимания, проста и удобна; легко осуществлять контроль; Его недостатки: линейная структура => возврат на одну или несколько фаз назад приводит к удорожанию проекта; пользователь принимает участие в процессе разработки только в самом начале — при сборе требований, и в конце — во время приемочных испытаний; может создать ошибочное впечатление о работе над проектом
Pic.7
Разновидности каскадной модели waterfall with overlapping
Разновидности каскадной модели waterfall with overlapping
Pic.8
Каскадно-возвратный подход Каскадно-возвратный подход
Каскадно-возвратный подход Каскадно-возвратный подход
Pic.9
V- образная модель
V- образная модель
Pic.10
V – образная модель демонстрирует комплексный подход к определению фаз процесса разработки ПО. В ней
V – образная модель демонстрирует комплексный подход к определению фаз процесса разработки ПО. В ней подчеркнуты взаимосвязи, существующие между аналитическими фазами и фазами проектирования, которые предшествуют кодированию, после которого следуют фазы тестирования. Пунктирные линии означают, что эти фазы необходимо рассматривать параллельно. V – образная модель демонстрирует комплексный подход к определению фаз процесса разработки ПО. В ней подчеркнуты взаимосвязи, существующие между аналитическими фазами и фазами проектирования, которые предшествуют кодированию, после которого следуют фазы тестирования. Пунктирные линии означают, что эти фазы необходимо рассматривать параллельно. Преимущества: в модели предусмотрены аттестация и верификация всех внешних и внутренних полученных данных, а не только самого программного продукта; в V-образной модели определение требований выполняется перед разработкой проекта системы, а проектирование ПО — перед разработкой компонентов; модель определяет продукты, которые должны быть получены в результате процесса разработки, причем каждые полученные данные должны подвергаться тестированию; благодаря модели менеджеры проекта может отслеживать ход процесса разработки, так как в данном случае вполне возможно воспользоваться временной шкалой, а завершение каждой фазы является контрольной точкой; модель проста в использовании (относительно проекта, для которого она является приемлемом). Недостатки: с ее помощью непросто справиться с параллельными событиями; в ней не учтены итерации между фазами; в модели не предусмотрено внесение требования динамических изменений на разных этапах жизненного цикла; в модель не входят действия, направленные на анализ рисков.
Pic.11
Спиральная модель
Спиральная модель
Pic.12
Эволюционная модель Идея данной модели состоит в следующем: Разработка первоначальной версии програм
Эволюционная модель Идея данной модели состоит в следующем: Разработка первоначальной версии программного продукта, которая передаётся на испытание пользователям. Доработка программного продукта с учётом мнения пользователей после чего получается промежуточная версия продукта, которая также проходит испытание пользователем. Повторная доработка продукта, которая может происходить несколько раз, до тех пор, пока не будет получен необходимый программный продукт. Отличительной чертой данной модели является очень тесное взаимодействие с клиентом. Различают два подхода к реализации эволюционной модели разработки ПО: Подход пробных разработок Прототипирование
Pic.13
Модели жизненного цикла разработки ПО, слайд 13
Pic.14
Достоинства эволюционной модели: Достоинства эволюционной модели: Более эффективен, чем подход, пост
Достоинства эволюционной модели: Достоинства эволюционной модели: Более эффективен, чем подход, построенный на основе каскадной модели. Спецификация может разрабатываться постепенно, по мере того как заказчик сформулирует те задачи, которые должно решать ПО. Значительное снижение риска для проекта. Конечный продукт удовлетворяет потребности заказчика и рынка в большей степени. Недостатки модели: Многие этапы процесса создания ПО не документированы. Система часто получается плохо структурированной. Часто требуются специальные средства и технологии разработки ПО.
Pic.15
Эволюционная модель наиболее приемлема для разработки небольших программных систем (до 100000 строк
Эволюционная модель наиболее приемлема для разработки небольших программных систем (до 100000 строк кода) и систем среднего размера (до 500000 строк кода) с относительно коротким сроком жизни. Эволюционная модель наиболее приемлема для разработки небольших программных систем (до 100000 строк кода) и систем среднего размера (до 500000 строк кода) с относительно коротким сроком жизни. Для больших долгоживущих систем рекомендуется использовать смешанный подход. Например: Для прояснения труднопонимаемых мест в системной спецификации и проектирования пользовательского интерфейса можно использовать прототипирование. Часть системных компонентов, для которых полностью определены требования, может создаваться на основе каскадной модели.
Pic.16
Модель «Чистой комнаты» Данная модель представляет процесс разработки ПО не как метод программных пр
Модель «Чистой комнаты» Данная модель представляет процесс разработки ПО не как метод программных проб и ошибок, а как инженерный процесс с математическим обоснованием. Она применяет технологии, основанные на теории, такие как: Спецификация типа, ящичная структура, функций использования и архитектуры системных объектов. Функционально-теоретическое проектирование и проверка корректности. Статистическое тестирование использования для аттестации качества. Модель «Чистой комнаты» основана на инкрементной разработке и аттестации процессов реализации функциональной и пользовательской спецификации, результаты которой суммируются в виде конечного продукта.
Pic.17
Модель «Чистой комнаты» Модель «Чистой комнаты» является одной из моделей формальной разработки сист
Модель «Чистой комнаты» Модель «Чистой комнаты» является одной из моделей формальной разработки систем. Другими моделями данного класса являются Модель разработки Венна (DVM) и нотация Зи (Z notation). Процессы данной модели приводятся в исполнение малыми, независимыми группами разработки и аттестации ПО. В данной модели всё тестирование основано на предсказывании того, как заказчик будет использовать конечный продукт. Между данным подходом и каскадной моделью существуют следующие отличия: Спецификация системных требований имеет вид детализированной формальной спецификации, записанной с помощью специальной математической нотации. Процессы проектирования, написания программного кода и тестирования модулей заменяются процессом, в котором формальная спецификация трансформируется в исполняемую программу.
Pic.18
Модели жизненного цикла разработки ПО, слайд 18
Pic.19
Модель «Чистой комнаты» Достоинства модели: Высокое качество и надежность конечного продукта. Высока
Модель «Чистой комнаты» Достоинства модели: Высокое качество и надежность конечного продукта. Высокая производительность Улучшенная возможность сопровождения Спецификации сильно детализированы и ясны. Недостатки модели: Данная модель является слишком теоретизированной и требует глубоких знаний в области математики. Большая часть усилий разработчиков уходит на создание спецификаций. Отказ от тестирования отдельных программных модулей.
Pic.20
Модель «Чистой комнаты» Модель «Чистой комнаты» подходит для очень определённых типов программного о
Модель «Чистой комнаты» Модель «Чистой комнаты» подходит для очень определённых типов программного обеспечения таких где, возможность появления риска наличия ошибок неприемлема. То есть модель обычно применяется для разработки систем, которые должны удовлетворять строгим требованиям надёжности, безотказности и безопасности.
Pic.21
Модель разработки ПО на основе ранее созданных компонентов За последние несколько лет данная модель
Модель разработки ПО на основе ранее созданных компонентов За последние несколько лет данная модель успешно зарекомендовала себя в различных областях разработки ПО. Она применялась в распределённых и web-ориентированных приложениях. В эволюционной модели для ускорения процесса создания ПО данная модель применяется достаточно часто. Данная модель основана на наличии большой базы существующих программных компонентов, которые можно интегрировать в создаваемую новую систему. Подобными компонентами являются свободно продаваемые на рынке программные библиотеки для форматирования текста, числовых вычислений и т. п.
Pic.22
Модели жизненного цикла разработки ПО, слайд 22
Pic.23
Модель разработки ПО на основе ранее созданных компонентов Достоинства модели: Сокращение количества
Модель разработки ПО на основе ранее созданных компонентов Достоинства модели: Сокращение количества непосредственно разрабатываемых компонентов. Уменьшается общая стоимость создаваемой системы. Увеличение производительности процесса разработки ПО. Недостатки модели: Законченная система может не удовлетворять всем требованиям заказчика. При произведении модернизации системы отсутствует возможность влиять на появление новых версий компонентов, используемых в системе.
Pic.24
Модель прототипирования жизненного цикла разработки ПО Определения прототипирования Согласно Джону К
Модель прототипирования жизненного цикла разработки ПО Определения прототипирования Согласно Джону Коннэллу (Connell) и Линде Шафер (Shafer), эволюционным уско­ренным прототипом является "легко поддающаяся модификации и расширению рабочая модель предполагаемой системы, не обязательно представляющая собой все свойства сис­темы, благодаря которой пользователи данного приложения получают физическое пред­ставление о ключевых частях системы до ее непосредственной реализации; это — легко создаваемая, без труда поддающаяся модификации, максимально расширяемая, частично заданная рабочая модель основных аспектов предполагаемой системы" . Бернард Боар (Bernard Boar) определил прототип как "метод, предназначенный для определения требований, при котором потребности пользователя извлекаются, представляются и разрабатываются посредством построения рабочей модели конеч­ной системы — быстро и в требуемом контексте". Прототипирование — это процесс построения рабочей модели системы. Прототип — это эквивалент экспериментальной модели или "макета" в мире аппаратного обеспечения.
Pic.25
Структурная эволюционная модель быстрого прототипирования
Структурная эволюционная модель быстрого прототипирования
Pic.26
Преимущества конечный пользователь может "увидеть" системные требования в процессе их сбор
Преимущества конечный пользователь может "увидеть" системные требования в процессе их сбора командой разработчиков; таким образом, взаимодействие заказчика с сис­темой начинается на раннем этапе разработки; снижается возможность возникновения путаницы, искажения информации или недоразумений при определении системных требований, что несомненно приво­дит к созданию более качественного конечного продукта; в процесс разработки можно внести новые или неожиданные требования пользо­вателя, что порой необходимо, так как реальность может отличаться от концепту­альной модели реальности; модель представляет собой формальную спецификацию, воплощенную в рабо­чую модель; модель позволяет выполнять гибкое проектирование и разработку, включая не­сколько итераций на всех фазах жизненного цикла; при использовании модели образуются постоянные, видимые признаки прогресса в выполнении проекта, благодаря чему заказчики чувствуют себя уверенно; возможность возникновения разногласий при общении заказчиков с разработчи­ками минимизирована; ожидаемое качество продукта определяется при активном участии пользователя в процесс на ранних фазах разработки; благодаря меньшему объему доработок уменьшаются затраты на разработку; благодаря тому что проблема выявляется до привлечения дополнительных ресур­сов сокращаются общие затраты; обеспечивается управление рисками; документация сконцентрирована на конечном продукте, а не на его разработке;
Pic.27
Недостатки модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о &
Недостатки модель может быть отклонена из-за создавшейся среди консерваторов репутации о ней как о "разработанном на скорую руку" методе; разработанные "на скорую руку" прототипы, в отличие от эволюционных уско­ренных прототипов, страдают от неадекватной или недостающей документации; если цели прототипирования не согласованы заранее, процесс может превратить­ся в упражнение по созданию хакерского кода; с учетом создания рабочего прототипа, качеству всего ПО или долгосрочной эксплуатационной надежности может быть уделено недостаточно внимания. иногда в результате использования модели получают систему с низкой рабочей харак­теристикой, особенно если в процессе ее выполнения пропускается этап подгонки; при использовании модели решение трудных проблем может отодвигаться на бу­дущее. В результате это приводит к тому, что последующие полученные продукты могут не оправдать надежды, которые возлагались на прототип; если пользователи не могут участвовать в проекте на итерационной фазе быст­рого прототипирования жизненного цикла, на конечном продукте могут отра­зиться неблагоприятные воздействия, включая проблемы, связанные с его каче­ственной характеристикой; на итерационном этапе прототипирования быстрый прототип представляет со­бой частичную систему. Если выполнение проекта завершается досрочно, у ко­нечного пользователя останется только лишь частичная система; несовпадение представлений заказчика и разработчиков об использовании прото­типа может привести к созданию другого пользовательского интерфейса;
Pic.28
Модель быстрой разработки приложений RAD (Rapid Application Development) Благодаря методу RAD пользо
Модель быстрой разработки приложений RAD (Rapid Application Development) Благодаря методу RAD пользователь задействован на всех фазах жизненного цикла разработки проекта – не только при определении требований, но и при проектировании, разработке, тестировании, а также конечной поставке про­граммного продукта. Характерной чертой RAD является короткое время перехода от определения требований до создания полной системы. Метод основывается на последовательно­сти итераций эволюционной системы или прототипов, критический анализ которых обсуждается с заказчиком. В процессе такого анализа формируются требования к продукту.
Pic.29
Модель быстрой разработки приложений
Модель быстрой разработки приложений
Pic.30
Фазы модели RAD Модель RAD проходит через следующие фазы: этап планирования требований — сбор требов
Фазы модели RAD Модель RAD проходит через следующие фазы: этап планирования требований — сбор требований выполняется при использо­вании рабочего метода, называемого совместным планированием требований (Joint requirements planning, JRP), который представляет собой структурный ана­лиз и обсуждение имеющихся коммерческих задач; пользовательское описание — совместное проектирование приложения (Joint application design, JAD) используется с целью привлечения пользователей; на этой фазе проектирования системы, не являющейся промышленной, работающая над проектом команда зачастую использует автоматические инструментальные сред­ства, обеспечивающие сбор пользовательской информации; фаза конструирования ("до полного завершения") — эта фаза объединяет в себе детализированное проектирование, построение (кодирование и тестирование), а также поставку программного продукта заказчику за определенное время. Сроки выполнения этой фазы в значительной мере зависит от использования генера­торов кода, экранных генераторов и других типов производственных инстру­ментальных средств; перевод на новую систему эксплуатации — эта фаза включает проведение пользо­вателями приемочных испытаний, установку системы и обучение пользователей.
Pic.31
Преимущества время цикла разработки сокращается благодаря использо­ванию мощных инструментальных сре
Преимущества время цикла разработки сокращается благодаря использо­ванию мощных инструментальных средств; требуется меньшее количество специалистов (поскольку разработка системы вы­полняется усилиями команды, осведомленной в предметной области); существует возможность произвести быстрый изначальный просмотр продукта; умень­шаются затраты (благодаря сокращенному времени цикла и усовершенствованной технологии, а также меньшему количеству задействованных в процессе разработчиков); благодаря принципу временного блока уменьшаются затраты и риск, связанный с соблюдением графика; обеспечивается эффективное использование имеющихся в наличии средств и структур; постоянное присутствие заказчика сводит до минимума риск неудовлетворения продуктом и гарантирует соответствие системы коммерческим потребностям и надёжность программного продукта в эксплуатации; в состав каждого временного блока входит анализ, проектирование и внедрение (фазы отделены от действий);
Pic.32
Недостатки Непостоянное участие пользователя может негативно сказаться на конечном продукте; при исп
Недостатки Непостоянное участие пользователя может негативно сказаться на конечном продукте; при использовании этой модели необходимо достаточное количество высоко­квалифицированных разработчиков, (умеющих воспользо­ваться выбранными инструментальными средствами разработки для ускорения времени разработки); использование модели может оказаться неудачным в случае отсутствия пригодных для повторного использования компонент; могут возникать затруднения при использовании модели совместно с наследственными системами и несколькими интерфейсами; возникает потребность в системе, которая может быть смоделирована корректным образом; для реализации модели требуются разработчики и заказчики, которые готовы к быстрому выполнению действий ввиду жестких временных ограничений; для обеспечения быстрой реакции на информацию, поступающую в результате на­лаженной обратной связи с пользователем, необходим эффективный ускоренный процесс разработки. при использовании модели "вслепую" на затраты и дату завершения работы над проектом ограничения не накладываются;
Pic.33
Инкрементная модель жизненного цикла разработки ПО Инкрементная разработка представляет собой процес
Инкрементная модель жизненного цикла разработки ПО Инкрементная разработка представляет собой процесс частичной реализации всей системы и медленного наращивания функциональных возможностей. Этот подход позволяет уменьшить затраты, понесенные до момента достижения уровня исходной производительности. Инкрементная модель действует по принципу каскадной модели с перекрытиями, благодаря чему функциональные возможности продукта, пригодные к эксплуатации, формируется раньше.
Pic.34
Инкрементная модель
Инкрементная модель
Pic.35
Преимущества не требуется заранее тратить средства, необходимые для разработки всего проекта (поскол
Преимущества не требуется заранее тратить средства, необходимые для разработки всего проекта (поскольку сначала выполняется разработка и реализация основной функции или функции из группы высокого риска); в результате выполнения каждого инкремента получается функциональный продукт; заказчик располагает возможностью высказаться по поводу каждой разработанной версии системы; правило по принципу "разделяй и властвуй" позволяет разбить возникшую про­блему на управляемые части, благодаря чему предотвращается формирование громоздких перечней требований, выдвигаемых перед командой разработчиков; существует возможность поддерживать постоянный прогресс в ходе выполне­ния проекта; снижаются затраты на первоначальную поставку программного продукта; ускоряется начальный график поставки (что позволяет соответствовать возрос­шим требованиям рынка); снижается риск неудачи и изменения требований; заказчики могут распознавать самые важные и полезные функциональные воз­можности продукта на более ранних этапах разработки; риск распределяется на несколько меньших по размеру инкрементов (не сосре­доточен в одном большом проекте разработки);
Pic.36
Недостатки в модели не предусмотрены итерации в рамках каждого инкремента; определение полной функци
Недостатки в модели не предусмотрены итерации в рамках каждого инкремента; определение полной функциональной системы должно осуществляться в начале жизненного цикла, чтобы обеспечить определение инкрементов; формальный критический анализ и проверку намного труднее выполнить для инкрементов, чем для системы в целом; заказчик должен осознавать, что общие затраты на выполнение проекта не будут снижены; поскольку создание некоторых модулей будет завершено значительно раньше других, возникает необходимость в четко определенных интерфейсах; использование на этапе анализа общих целей, вместо полностью сформулирован­ных требований, может оказаться неудобным для руководства; для модели необходимы хорошее планирование и проектирование: руководство должно заботиться о распределении работы, а технический персонал должен со­блюдать субординацию в отношениях между сотрудниками. может возникнуть тенденция к оттягиванию решений трудных проблем на будущее с целью продемонстрировать руководству успех, достигнутый на ранних этапах разработки;
Pic.37
Список литературы S. Kan. Metrics and Models in Software Quality Engineering. Addison Wesley, 2002.
Список литературы S. Kan. Metrics and Models in Software Quality Engineering. Addison Wesley, 2002. И. Соммервилл. Инженерия программного обеспечения. Издательский дом «Вильямс», 2002. С. Орлов. Технологии разработки программного обеспечения. СПб:Питер, 2002. В. Липаев. Программная инженерия. Издательство «ТЕИС», 2006. E. May, B. Zimmer. The Evolutionary Development Model for Software // Hewlett-Packard Journal, August 1996. R. Linger. Cleanroom Software Engineering for Zero Defect Software // IEEE, 1993.


Скачать презентацию

Если вам понравился сайт и размещенные на нем материалы, пожалуйста, не забывайте поделиться этой страничкой в социальных сетях и с друзьями! Спасибо!