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

Термин CASE (Computer Aided Software Engineering) означает "компьютерная поддержка проектирования программного обеспечения" и связан с появлением так называемых CASE-средств - программных продуктов нового типа, предназначенных для автоматизации разработки ИС.

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

Можно выделить следующие составляющие CASE-технологий - регламент (последовательность этапов проектирования), методология и инструментальные средства поддержки. Рассмотрим регламент технологического процесса проектирования ИС и используемые методологии, обращая особое внимание на использование в них системного подхода.

Последовательность проектирования ИС (регламент)
Регламент - руководящие указания по составу этапов проектирования, их последовательности, правила распределения и использования операций и методов. Нужно отметить, что регламенты различных технологий проектирования ИС незначительно отличаются друг от друга. Фактически сложилась некоторая типовая последовательность проектирования (ТПП), используемая различными технологиями в той или иной вариации.

Типовая последовательность проектирования и использования ИС сложилась еще в начале 70-х гг. и включает в себя следующие укрупненные этапы, соответствующие этапам жизненного цикла системы:

1. Анализ - определение требований, функций системы.

2. Проектирование - определение подсистем и их интерфейсов.

3. Реализация (программирование) - разработка подсистем и их интерфейсов.

4. Компоновка (интеграция) - соединение подсистем в единое целое.

5. Тестирование (верификация) - проверка работы системы.

6. Внедрение (инсталляция) - введение системы в действие.

7. Эксплуатация - использование системы, сопровождение и анализ опыта эксплуатации.

В разное время и в разных "школах" проектирования разрабатывались более детальные технологии. При этом разбиение работ на этапы и их названия менялись. Соответствующие технологии организации работ рекомендовались официально, фиксировались в стандартах (ГОСТы, ANSI, ISO), описывались в монографиях, учебниках и во многих отраслях широко использовались. Несмотря на все различия предлагаемых технологий можно выделить этапы, общие для большинства методик. В таблице 5.1 приведена такая типовая последовательность этапов проектирования, составленная Е.З. Зиндером [19]. Для сравнения в таблице 5.1 приведена технология SSADM, официально принятая в качестве государственного стандарта Великобритании [20].

Таблица 5.1

Технологии разработки информационных систем

Технология по Зиндеру

Технология SSADM

Запуск: организация основания для деятельности и запуск работ - договор, задание на выполнение работ Обследование: предпроектный анализ, общий анализ ситуации, разработка обоснования целесообразности создания ИС Концепция, Техническое задание: исследование требований, выработка рекомендаций, ТЗ на всю систему и отдельные подсистемы Эскизный проект: разработка архитектуры будущей ИС Опытный вариант ИС: разработка пилотного проекта будущей ИС, его опытное использование ТП: Разработка технического проекта ИС РП: Разработка рабочей документации проекта Ввод в действие: внедрение ИС

Оценивание реализуемости: предварительное технико-экономичес-кое обоснование проекта Анализ требований: предпроектное обследование, описание существующей системы Выбор варианта автоматизации Разработка технического задания: полностью определяются требования к выбранному варианту ИС, разработка демонстрационного прототипа Выбор варианта технической реализации: выбор технической и программной сред реализации ИС Разработка логического проекта: разработка и увязывание постановок задач, схем диалогового взаимодействия Физическое проектирование: описание данных на физическом уровне, руководящие указания по программированию

Создание промышленной информационной технологии SSADM (Structured System Analysis and Design Method), координируемое и финансируемое Государственным агентством по информатике и вычислительной технике Великобритании, началось еще с середины 70-х годов. В 1981 году данная технология была объявлена открытым отраслевым стандартом. В течение 80-х годов технология SSADM получила широкое распространение сначала в Великобритании, а затем и за ее пределами. Этому способствовало создание CASE-средств поддержки - инструментальных программных средств проектирования. В середине 1993 года технология SSADM была официально принята в качестве государственного стандарта Великобритании [20]. Если состав этапов, их назначение за прошедшие четверть века менялись незначительно, то схема их применения, порядок следования этапов и организация работ менялись кардинально.

Традиционная схема, используемая в 70-е - начало 80-х гг., называемая каскадной или водопадной моделью, предполагает строгое детерминированное следование этапов анализа, проектирования, реализации, внедрения и эксплуатации ИС по единому заранее разработанному плану. Положительные стороны данной схемы [19]:

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

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

Однако каскадная модель имеет и существенные недостатки:

- "несоответствие требованиям" - согласование с пользователями предусматривалось только по завершению этапов, в результате зачастую разрабатывалась не та ИС, которую хотел заказчик и пользователь;

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

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

Существенно сглаживает указанные недостатки другая модель, так называемая спиральная или схема непрерывной разработки, получившая распространение в 80-х гг. Характерной особенностью данной модели является непрерывный процесс разработки и развития ИС с планируемыми точками передачи в эксплуатацию новых версий и новых функциональных блоков [19, 20].

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

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

Постепенно сложилась некоторая смешанная схема, лежащая где-то посредине между каскадной и спиральной моделями, которую можно назвать "макетной" или схемой "быстрого прототипирования" (rapid prototyping или fast-track). Последовательность этапов в данной модели внешне выглядит как каскадная, однако содержание технологических этапов таково, что многие проектные решения в процессе разработки ИС подвергаются многократным уточнениям и корректировкам, как это предусмотрено спиральной моделью [20]. Такой компромисс достигается за счет:

- постоянного вовлечения будущих пользователей в процесс выработки решений на всех этапах создания продукта;

- создания на различных этапах разработки ИС вместо законченных прототипов макетов, представленных хотя бы и на бумаге, и оперативно проверяемых у пользователей;

- параллельного (хотя бы частично) выполнения этапов и отдельных работ в рамках каждого этапа.

Различия в последовательности проведения основных этапов разработки информационных систем для различных технологий (каскадной, спиральной и макетной) наглядно отображены на рис. 5.1.

Рис. 5.1. Последовательность разработки информационных систем:
а) каскадная схема; б) спиральная схема; в) макетная схема

Методологии и инструментальные средства проектирования ИС
Методология - это систематическая процедура или техника генерации описаний компонент ИС, таких как функциональная структура, потоки и структуры данных, спецификации, словари и т.д. Каждая методология использует некоторую нотацию - языковые, модельные средства описания компонент - графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки. Как правило, большинство существующих CASE-технологий ориентировано на применение одной или 2-3-х методологий проектирования, поддерживаемых соответствующими CASE-средствами, зачастую объединенными в интегрированные пакеты.

К настоящему времени разработаны десятки методологий и инструментов проектирования. Перечислим основные функции, выполняемые с помощью CASE-средств [18]:

• формирование функциональной модели информационной системы. Наиболее распространенный метод реализации данной функции – метод SADT (технология IDEF0), позволяющий описать процесс в ИС в виде иерархии функций, связанных между собой входящими/исходящими потоками (материальными, финансовыми, информационными), управляющими воздействиями, исполнителями;
• формирование информационной модели, в том числе выделение объектов, описание их поведения и связей друг с другом. Наиболее распространенный метод реализации данной функции – метод IDEF1X, с помощью которого создается описание информационного пространства выполнения бизнес-процессов, содержащего информационные объекты (сущности), их свойства (атрибуты), отношения с другими объектами (связи);
• формирование архитектуры информационной системы. Наиболее распространенный метод реализации данной функции - DFD (Data Flow Diagrams – диаграммы потоков данных) - методология структурно- функционального анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных;
• структурирование (моделирование) данных, в том числе создание концептуальной модели структуры базы данных, автоматическая генерация физической модели БД и др. Наибольшее распространение получили: метод построения ER (Entity-Relationship)-диаграмм Чена и методология Уорнера-Орра DSSD (Data Structured Systems Development);
• быстрая разработка приложений (визуальное программирование). Средства, обеспечивающие данную функцию, называются RAD-средствами (Rapid Application Development). Они представляют собой визуальные дизайнеры приложений с автоматической кодогенерацией и позволяют создавать приложения в интерактивном режиме с помощью набора визуальных средств.