Файл: Этапы создания и проектирования информационной системы.pdf

2.1 Каскадная модель

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

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

Рисунок 1 – Каскадная схема разработки программного обеспечения

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

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

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

Каскадный подход хорошо зарекомендовал себя в построении программного обеспечения, имеющего возможность в самом начале разработки достаточно полной и точной формулировки всех требований для предоставления разработчикам свободы их лучшей реализации с технической точки зрения. В данную категорию попадают системы реального времени, сложные расчетные системы и другие подобные системы. Но при использовании этого подхода обнаруживается ряд его недостатков, которые вызваны отличиями реального процесса создания программного обеспечения от полного укладывания в такую жесткую схему. При создании программного обеспечения постоянно возникает потребность в пересмотре или уточнении ранее принятых решений и возврате к предыдущим этапам. В результате реальный процесс создания программного обеспечения принимал следующий вид поэтапной модели с промежуточным контролем [7, 8, 9].

2.2 Поэтапная модель с промежуточным контролем

Для преодоления проблем каскадной модели была предложена поэтапная модель с промежуточным контролем.

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

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

Основным недостатком каскадного и поэтапного подходов является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, которые планируются после завершения каждого этапа работы, требования к информационной системе фиксированы в виде технического задания на все время создания системы. Таким образом, пользователи могут внести свои замечания только после полного завершения работы над программой. В случае изменения требований или их неточного изложения в течение длительного периода создания программного обеспечения, пользователи получают программу, которая не удовлетворяет их потребностям. Модели объекта могут устаревать одновременно с их утверждением [8, 10, 11].

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

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

Рисунок 2 – Поэтапная схема разработки программного обеспечения с промежуточным контролем

Рисунок 3 – Инкрементная схема разработки программного обеспечения

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

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

Недостатки и достоинства данной стратегии совпадают с каскадной моделью. За исключением более ранней видимости результатов заказчиком. Уже после результатов разработки и внедрения первой версии он имеет возможность незначительно изменять требования к разработке, предлагать разработку более совершенного продукта при заключении нового договора или совсем отказаться от нее [7, 11, 12].

2.4 Спиральная модель

Спиральная модель, также называемая эволюционной или итерационной моделью, была изобретена Барри Боэмом в 1988 году. Данная модель подразумевает разработку в виде последовательности версий, но при начале проекта требования определены не окончательно, и они уточняются в результате разработки версий.

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

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

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

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

Спиральная схема разработки программного обеспечения представлена на рисунке 4.

Рисунок 4 – Спиральная схема разработки программного обеспечения

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

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

Недостатками данной модели является увеличение неопределенности у разработчика в перспективах развития проекта и затруднение операции ресурсного и временного планирования всего проекта в целом. Для решения данной проблемы вводятся временные ограничения на каждый этап жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе полученных в предыдущих проектах статистических данных и личного опыта разработчиков [8, 12, 13, 14].

2.5 Сравнительный анализ моделей

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

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

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