Модели проектирования АСОИУ

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

Поскольку для конечных пользователей любая АСОИУ или ИС представлена в форме пакета прикладных программ, по существу процесс ее проектирования и разработки заканчивается созданием программного продукта, готового к эксплуатации. Поэтому в качестве моделей проектирования рассматриваются модели Жизненного цикла программного обеспечения (ЖЦПО) или модели Жизненного цикла программного продукта. Барри Боэм представляет ЖЦПО в виде последовательности следующих этапов [5, с. 49]:

• 1) Анализ существующей системы (предусматривает Подтверждение);
• 2) Планирование и анализ требований к ПО (предусматривает Подтверждение);
• 3) Проектирование ПО (предусматривает Верификацию);
• 4) Детальное проектирование (предусматривает Верификацию);
• 5) Кодирование (предусматривает Автономную отладку);
• 6) Комплексирование (предусматривает Верификацию изделия);
• 7) Внедрение (предусматривает Системную отладку);
• 8) Функционирование (эксплуатация) и сопровождение (предусматривает Повторное подтверждение).

Идея представления процесса проектирования и разработки ПО в виде соответствующих графических схем была предложена во второй половине 1960;х гг. в публикациях ВВС США [5, с. 49]. Кратко рассмотрим основные из них.

1. Каскадная (водопадная) модель. Эта модель показана на рис. 1.2.

Рис. 1.2. Каскадная модель проектирования АСОИУ [3, с. 26].

Особенности данной модели проектирования следующие.

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

Процесс проектирования представляется достаточно «прозрачным» (при жестком соблюдении очередности этапов). Это упрощает процесс управления проектом, включая, главным образом, управление затратами.

Исторически модель использовалась в период создания относительно простых локальных автоматизированных систем в 1950 — 1970;е гг.

Ошибки в требованиях сложно поддавались исправлениям. Это обусловливалось тем, что информация в те годы была представлена в файлах с жесткой структурой записи. Поэтому исправления в структуре одного файла влекли за собой изменения во всех программах, которые использовали информацию из такого файла и, как следствие, — необходимость отладки всех соответствующих программных взаимодействий внутри системы. Существовала обязательная очередность проектирования, разработки и внедрения системы и каждая очередь включала в себя совокупность взаимосвязанных задач по подсистемам (первая очередь: реализация задач 1 — N1, вторая очередь: реализация задач N2 — Мит. д.). Все выявленные недочеты в уже реализованных требованиях и появление новых требований приводило к необходимости создания по существу новой системы.

Наличие регламентированного перечня задач позволяло устанавливать реалистичные сроки по продолжительности проекта.

2. Поэтапная модель с промежуточным контролем (итерационная или инкрементная модель). Изображена на рис. 1.3.

Рис. 1.3. Поэтапная с промежуточным контролем модель проектирования.

АСОИУ [3, с. 27].

Особенности данной модели проектирования следующие.

При выполнении каждого из этапов при необходимости возможен возврат на любой из предыдущих этапов.

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

Итеративность в реализации проекта усложнила определение его точных сроков, что часто приводило к их увеличению и, как следствие, повышало затраты.

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

3. Спиральная модель. Представлена на рис. 1.4.

Особенности данной модели проектирования следующие.

Используется со второй половины 1980;х гг. по настоящее время.

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

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

Рис. 7.4. Спиральная модель проектирования АСОИУ [3, с. 27].

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

«Под гибкой разработкой (agile development) подразумевают набор методов разработки ПО, обеспечивающих постоянное сотрудничество между заинтересованными лицами и быстрый и частый выпуск функциональности небольшими порциями. Существует много разных типов гибкой разработки, вот лишь самые популярные: Scrum, Extreme Programming, Lean Software Development, Feature-Driven Development, Kanban. Методы гибкой разработки основаны на интерактивных и инкрементальных подходах к разработке ПО, которые существуют уже много лет…» [6, с. 454].

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