6. Модели жизненного цикла программного обеспечения. Классические и гибкие модели разработки программного обеспечения.

Каскадная модель (классический жизненный цикл)

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

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

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

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

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

Итерационная модель ЖЦ ПС

Модель с промежуточным контролем или моделью с циклическим повторением фаз.

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

Макетирование (прототипирование)

Основная цель макетирования – снять неопределенность в требованиях заказчика. Макетирование (прототипирование) – процесс создания модели требуемого продукта.

Модель может принимать следующие формы.

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

Как показано на рисунке, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.

Достоинства макетирования – возможность обеспечения определения полных требований к системе. Недостатки макетирования:

заказчик может принять макет за продукт;
разработчик может принять макет за продукт.

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

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

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

Инкрементная модель

Она объединяет элементы последовательной водопадной модели с итерационной философией макетирования. Каждая линейная последовательность здесь вырабатывает поставляемый инкремент ПО.

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

По своей природе инкрементный процесс итеративен, но, в отличие от макетирования, инкрементная модель обеспечивает на каждом инкременте работающий продукт.

Схема такой модели ЖЦ ПО приведена на рисунке. Одной из современных реализаций инкрементного подхода является экстремальное программирование (ориентировано на очень малые приращения функциональности).

Спиральная модель ЖЦ ПО

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

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

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

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

повышенные требования к заказчику;
трудности контроля и управления временем разработки.

Рациональный унифицированный процесс

Рациональный унифицированный процесс (Rational Unified Process, RUP) – одна из лучших методологий разработки программного обеспечения. Основываясь на опыте многих успешных программных проектов, RUP позволяет создавать сложные программные системы.

RUP – одна из спиральных методологий разработки программного обеспечения. В качестве языка моделирования в общей базе знаний используется язык Unified Modelling Language (UML). Итерационная и инкрементная разработка программного обеспечения в RUP предполагает разделение проекта на несколько проектов, которые выполняются последовательно, и каждая итерация разработки четко определена набором целей, которые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что набор целей итерации должен в точности совпадать с набором целей, указанных заказчиком продукта, то есть все требования должны быть выполнены.

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

Методология SCRUM

Scrum – переводится с английского как схватка. Команда высокопрофессиональных кросс-функциональных специалистов участвует совместными усилиями в реализации проекта, при этом приветствуется инициатива, скорость выдачи промежуточных результатов, минимум бумажной волокиты. Персонал – основа успеха применения Scrum-методологии, в команду подбирают высоко мотивированных самоорганизующихся универсальных профессионалов, готовых, в том числе по ходу реализации проекта, проявлять инициативу, вносить изменения как в ход реализации, так и в сам продукт. В команде нет единого руководства, нет лидера. Возможные роли в команде: Product owner (владелец продукта): специалист, отвечающий за связь всей команды с заинтересованными сторонами (stakeholders), такими как руководство и сотрудники компании, заказчик, потребители, клиенты и др. Его можно назвать куратором проекта. Scrum-master (скрам-мастер): это специалист по технологии Scrum, который следит за правильностью ее реализации, соблюдением всех принципов, защищает команду от отвлекающих факторов, ведет документацию. Подобно ответственному секретарю на мероприятиях, отвечающему за регламент. Scrum-team (скрам-команда) проекта: все остальные участники команды равноправны в команде и работают над задачами определенными на этапе планирования. В Scrum-методологии стартовым документом является так называемый product backlog – это список пожеланий к результатам, ранжированный по важности и, иногда, по сложности. Каждый элемент списка называется «пользовательской историей» – что отражает клиенто-ориентированный подход к разработке продукта. В течение срока реализации проекта в product backlog могут вноситься изменения скрам-командой. Product backlog – заменяет спецификации в традиционном подходе к планированию проектов, но не идентичен ему: пожелания к проекту («пользовательские истории») могут меняться в течение проекта и даже перевернуть изначальную суть продукта «с ног на голову». Другой ключевой элемент методологии – спринты (sprints) – минимальный временной период (итерация), в течение которого готовится очередная новая версия продукта (прототип и т.п.). Перед стартом спринта формируются sprint backlog (спринт-бэклог) – список задач для спринта из product backlog (список задач для текущей итерации разработки продукта), которые планируются к реализации за время текущего спринта. При реализации проекта в соответствии со Scrum-методологией менеджеры регулярно обращаются к инструментарию «customer development», проверяя гипотезы, тестируя промежуточные идеи и прототипы.

Содержание