Тема: Жизненный цикл программного обеспечения. Последовательность этапов
Модель жизненного цикла ПО (слайд) - структура, определяющая последовательность выполнения и взаимосвязи процессов, этапов, действий и задач на протяжении жизненного цикла.
Модель ЖЦ разработки ПО схематически объясняет, каким образом будут выполняться действия по разработке ПО, посредством описания «последовательности» этих действий. Такая последовательность может быть или не быть линейной, поскольку этапы могут следовать друг за другом, повторяться или происходить одновременно.
Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Существует три модели жизненного цикла программных систем, в которых последовательность этапов разработки ПО меняется по-разному.
Каскадная модель
Каскадная модель жизненного цикла была принята в 70-х годах. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. (слайд).
Первая модель – Каскадная (водопадная) Названа так, в связи с тем, что проводится аналогия с водопадом. Вода, оторвавшись о края водопада летит вниз, пролетая различные точки этого водопада, однако назад она не может вернуться ни в коем случае. Аналогично и в разработке ПО. Начав один этап и закончив его, мы не сможем вернуться к этому этапу второй раз. Этапы идут строго последовательно: анализ, проектирование, разработка, тестирование, развертывание.
Достоинства данной модели (слайд)
- Позволяет предсказать затраты на проект (сколько потребуется людей, денег, времени)
- управляемость проекта (считается, что проект является управляемым, так как назначены четкие сроки и этапы сдачи различных фрагментов проекта)
- четкие сроки сдачи
- обеспечение строгого контроля
Недостатки данной модели:
- отсутствие гибкости (например: Поменялась окружающая среда, конъюнктура рынка, а продолжается создание системы, которая уже не нужна.)
- заказчик не может ознакомится с предварительной версией
- все требования должны быть известны в начале проекта
У каскадной модели есть своя область применения (слайд):
1. В случае с небольшим проектом ставится задача, допустим на три месяца, очень не велик шанс, что за это время что-то очень серьезно поменяется, поэтому можно четко расставить все контрольные точки и необходимо всем этим контрольным точкам следовать. А если что-то поменяется, то через 3 месяца можно ситуацию исправить или свернуть проект и начать новый, если это необходимо.
2. В большом проекте все происходит наоборот. Мы не можем создать систему иначе. Скажем требуется создать перспективную систему, внедрение которой планируется через 5 лет и дальнейшая эксплуатация еще в течение 20 ти лет. Необходимо предположить какие методы и технологии будут через 15 лет. Для этого приходится вести очень серьезный анализ. Например, сам по себе анализ требований к системе может занимать несколько месяцев, а то и целый год. Этим будет заниматься специальная крупная лаборатория. Они должны просмотреть вперед, понять, что необходимо от системы с учетом перспективных требований. После того, как поняли, что именно необходимо создать, требуется создать проект. Система большая, поэтому этим занимается НИИ или группа НИИ. Нужно создать проекты на несколько тысяч человек, которые будут выполняться в течении нескольких лет. Дальше ведется разработка, которая может вестись от 1 –го до нескольких лет. После того, как ее создадим, это может быть будет революция в индустрии, поэтому работаем над этой системой целой группой исследователей. В общем если у нас важная задача, на которую мы можем не жалеть времени и средств, то каскадная модель здесь может подойти.
Ситуации, когда требования четко определены и понятны. Модель хорошо работает при ее применении в циклах разработки ПО, в которых используется неизменяемое определение продукта и вполне понятные технические методики.
Управляемость проекта является кажущейся. Все мы люди, нам свойственно ошибаться, мы могли ошибиться и на этапе проектирования заложить неправильные сроки, следовательно в сроки мы уже не укладываемся. Или выясняется, что какая то функция не работает, она не может быть реализована с заданными требованиями, по каким –то причинам мы опустили, что требования противоречивы и на этапе тестирования выясняется, что из-за этого система не может быть собрана. И непонятно что делать в этой ситуации. Каскадная модель на все эти вопросы не отвечает – если мы начали делать что-то, то мы обязаны это закончить.
Итерационная модель
Что же делать в ситуации когда необходимо вернуться к предыдущему проекту? В этом случае существует еще одна модель, Модель с возвратами.
Итерационная модель была принята в 80-85 годы. В данной модели разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки. (слайд)
Итерация – это повторение какого-либо действия.
Итерация в программировании — организация обработки данных, при которой действия повторяются многократно, не приводя при этом к вызовам самих себя. (слайд)
Т. е. предположим, если мы в ходе проектирования, заметили, что требования у нас плохие и их надо разрабатывать заново, что слишком много несовместимых требований, нужен повторный анализ предметной области и внешней среды, получается надо вернуться на этап анализа. Самое страшное, если это выясняется на этапе внедрения, когда мы устанавливаем ПО на оборудовании заказчика и выясняется что программа на этом оборудовании работать не будет, например не соответствует энергоемкость, мы делали программу, рассчитанную на 220 вольт, а у заказчика 128. Но в любом случае, когда мы обнаружили, что требования поменялись мы вернулись на соответствующий этап, возможно надо перепроектировать систему или поменять что-то в процессе разработки. Мы возвращаемся на этап, который нам необходим и проводим дополнительные работы на данном этапе.
Достоинства: (слайд)
1. Гибкость разработки: возможность возврата к предыдущему этапу
2. Высоки шансы получить, то что требовалось (Получаем то, что надо, а не то, что думали в начале, возможно мы думали не то и не так.)
Недостатки:
1. Неизвестно сколько потребуется возвратов, то есть времени и средств
2. Трудно оценить качество
(Один из страшных минусов. Заказчик спрашивает за какое время будет разработана система, отвечаем? «за полгода, но возможно, что за два». Кто будет работать с таким разработчиком?)
Область применения модели. Лучше всего использовать, когда не известны точные требования к программному обеспечению.
Перевод терминов
Модель - қалып
Модель жизненного цикла программного обеспечения - бағдарламалық қамсыздандырудың өмірлік топтамасының қалыбы
Каскадная модель - Каскадты қалып
Итерация - итерация
Итерационная модель - Итерациялық қалып
Спиральная модель
Спиральная модель - была принята в 1988 году. Отображает базовую концепцию, которая заключается в том, что каждый цикл представляет собой набор операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса. (слайд)
Более гибкими являются спиральные модели, когда мы четко осознаем, что возвраты неизбежны. Ее суть состоит в том, что мы несколько раз повторяем весь этап, т. е. предположим, что систему можем разработать за три года, бы разбиваем ее на 6 циклов по пол года и каждая из итераций ведется фактически каскадной модели. Анализируем то, что получилось, проектируем, разрабатываем, внедряем, смотрим, что получилось, опять анализируем и т. д. То есть если вдруг требования поменялись, а за пол года они могут не сильно поменяться, заказчик может записывать требования, а когда мы приступим к созданию системы в рамках новой итерации, заказчик может прийти и рассказать о своих вновь появившихся требованиях. В основу спиральной модели положен цикл (слайд)
Т. е. мы планируем, что собираемся делать, анализируем предметную область, проектируем, создаем, тестируем, внедряем и действуем в рамках этой системы. После того, как поработали с системой, понимаем, что надо что-то менять, планируем изменения, интерпретируем их и работаем уже с новой системой.
Плюсы: (слайд)
1. Предсказуемость процесса разработки на короткий период (когда планируем действия, мы четко осознаем что и когда должно быть сдано, все сроки прописаны)
2. Повышенная гибкость затрат (имеем результаты внедрения системы, по результатам тестов можем повернуть систему в другую сторону
3. Минимизация затрат
Минусы:
1. Неопределенность разработки (мы планируем, что потребуется пол года, но если в 6 этапах мы дадим задержку на месяц, то в итоге потребуется 3,5 года, и в связи с этим неизвестно что получим в итоге, сколько затрат, времени, людей и т. д.
Область применения спиральной модели: (слайд)
– возможность адаптации модели;
– частое изменение требований заказчика в ходе разработки;
– нечеткие требования;
– разработка новой функции или новой серии продуктов;
– большие проекты;
– частичное периодическое финансирование работ;
– для демонстрации качества и надежности;
– в промышленности в больших проектах.
Подведем итоги нового материала
Как мы смогли убедиться, этапы хоть мы и излагаем последовательно, однако они идут так не всегда, их последовательность может меняться, т. к. нам необходимо и единого решения здесь нет.
Есть маленький проект и мы хотим гарантировать сроки – нам нужна каскадная модель или наоборот, очень большой проект, то мы должны четко спланировать, как мы собираемся в течении нескольких лет этот проект реализовывать, можно использовать каскадную модель.
Если небольшой проект: несколько программистов и заказчик, который не совсем сам понимает, что он хочет, то мы в разработке по итерационной модели будем выяснять то, что нам сейчас нужно, будем пытаться реализовать эту систему.
Если хотим гарантировать промежуточные результаты, то необходима спиральная модель.
Закрепление материала
Выступление двух учащихся: заказчик и разработчик с домашним заданием, определившим требования к разработке ПО: «Автоматизированное рабочее место сотрудника биржи труда»
Разделить на три микрогруппы
Задание для двух микрогрупп: Определить модель разработки интернет сайта для фирмы, занимающейся продажей недвижимости.
Для команды заказчиков необходимо составить список требований, которые они хотят увидеть на сайте и при его разработке
Для команды разработчиков необходимо составить список вопросов, которые им важны для уточнения модели проектирования системы
Время для обсуждения в группе – 3 минуты.
Задание для третьем микрогруппы: записать основные термины и понятия, которые им запомнились на уроке в течении трех минут.
После обсуждения происходит диалог между заказчиком и разработчиком, в ходе которого необходимо выяснить детали проектирования для определения модели ЖЦПО.
Дается 2 минуты разработчикам для определения модели и причин выбора этой модели.
Третья микрогруппа читает записанные термины и дает им пояснение.
После обсуждения происходит диалог между заказчиком и разработчиком, в ходе которого необходимо выяснить детали проектирования для определения модели ЖЦПО.
Дается 2 минуты разработчикам для определения модели и причин выбора этой модели.
Третья микрогруппа читает записанные термины и дает им пояснение.
