Технологии проектирования информационных систем

В результате освоения шестой главы студент должен:

знать

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

уметь

• • использовать технологии и средства проектирования информационных систем;
• • применять методы оценки качества в процессе проектирования информационных систем;

владеть

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

Методология проектирования информационных систем

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

Из определения системы следует, что системы функционируют как целое, что порождает у них свойства, отличающиеся от свойств составляющих ее частей. Эти свойства известны как эмерджентные (возникающие)I. Разделив систему на компоненты, мы никогда не обнаружим ее существенных свойств, они проявляются только в результате действия целостной системы. Эмерджентные свойства являются важными в понимании сущности анализа и синтеза. Разбиение системы на составляющие части для познания принципов ее функционирования называется анализом. С помощью анализа мы получаем знания, однако теряем возможность понимания свойств. Дополнением анализа является синтез — создание целого из частей. С помощью синтеза мы обретаем понимание [8].

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

По виду элементов информационная система относится к системам типа «процесс» (элементами являются информационные процессы).

Отметим другие важные определения.

Структура — совокупность элементов и их связей.

Цель — состояние, к которому стремится система.

Среда — метасистема, в которой рассматриваемая система входит составной частью.

Функционирование системы — работа системы в рамках заданной структуры.

Развитие системы — работа системы в условии острых противоречий, которые могут вызвать изменение структуры.

Управление — целенаправленный перевод системы из одного состояния в другое желаемое.

Проектирование — процесс, который дает начало изменениям в искусственной среде.

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

Рис. 6.1. Процесс проектирования.

В процессе проектирования выделяют следующие фазы:

• 1) дивергенция — расширение границ проектной ситуации с целью обеспечения более обширного пространства поиска решения;
• 2) трансформация — стадия создания принципов и концепций (исследование структуры проблемы);
• 3) конвергенция — охватывает традиционное проектирование (кодирование, отладка, проработка деталей).

Трудности проектирования:

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

Под проектированием ИС понимается процесс преобразования входной информации об объекте, методах и опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом (34.601—90 «Автоматизированные системы. Стадии создания») в проект ИС.

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

Основными особенностями исходных данных для проектирования ИС являются следующие:

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

Отличительная черта проектирования ИС — коллективное проектирование.

Технология проектирования ИС — это совокупность методологии и средств проектирования ИС, а также методов и средств его организации (управление процессом создания и модернизации проекта ИС).

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

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

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

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

Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и точного описания этого процесса и применения современных методов и технологий создания ИС на всем жизненном цикле ИС — от замысла до реализации.

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

1. Классическое проектирование ИС берет свое начало в 1970;х гг. Одно из первых направлений получило название каскадной схемы проектирования (рис. 6.2). Она широко использовалась при проектировании ИС и включала следующие стадии проекта: разработка требований, проектирование, реализация, тестирование, ввод в действие (внедрение). Основной особенностью данной методики является последовательная организация работ при разбиении структуры ИС на заранее определенный ряд подсистем: организационное, методическое, информационное, программное и аппаратное обеспечения. В западной литературе такая схема организации работ получила название «водопадной модели» (waterfall model) и включала дополнительно итерационные процедуры уточнения требований к системе и рассмотрения вариантов проектных решений. Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

Основными недостатками каскадной схемы проектирования являются запаздывание получения конечных результатов и низкая эффективность.

Рис. 6.2. Каскадная модель проектирования ИС.

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

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

контролем.

3. В процессе совершенствования разработки ИС появилась схема непрерывной (спиральной) разработки (рис. 6.4), использовавшаяся при реализации больших проектов фирмы IBM в 1970—1980;х гг.

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

Рис. 6.4. Спиральная модель проектирования ИС.

Методы проектирования ИС можно классифицировать по степени использования средств автоматизации, типовых проектных решений, адаптивности к предполагаемым изменениям.

Так, по степени автоматизации методы проектирования разделяются:

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

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

• • оригинальное (индивидуальное), когда проектные решения разрабатываются «с нуля» в соответствии с требованиями к АИС. Характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все его особенности;
• • типовое, предполагающее конфигурирование ИС из готовых типовых проектных решений (программных модулей). Выполняется на основе опыта, полученного при разработке индивидуальных проектов. Типовые проекты как обобщение опыта для некоторых групп организационно-экономических систем или видов работ в каждом конкретном случае связаны со множеством специфических особенностей и различаются по степени охвата функций управления, выполняемым работам и разрабатываемой проектной документации.

По степени адаптивности проектных решений выделяют методы:

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

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

В основе канонического проектирования лежит каскадная модель жизненного цикла ИС. Процесс каскадного проектирования в жизненном цикле ИС в соответствии с применяемым в нашей стране ГОСТ 34.601−90 «Автоматизированные системы. Стадии создания» делится на следующие семь стадий:

• 1) исследование и обоснование создания системы;
• 2) разработка технического задания;
• 3) создание эскизного проекта;
• 4) техническое проектирование;
• 5) рабочее проектирование;
• 6) ввод в действие;
• 7) функционирование, сопровождение, модернизация.

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

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

Стадия 1. Формирование требований к ИС. На начальной стадии проектирования выделяют следующие этапы работ:

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

Стадия 2. Разработка концепции ИС.

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

Стадия 3. Техническое задание:

• разработка и утверждение технического задания на создание ИС.

Стадия 4. Эскизный проект:

• • разработка предварительных проектных решений по системе и ее частям;
• • разработка эскизной документации на ИС и ее части.

Стадия 5. Технический проект:

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

Стадия 6. Рабочая документация:

• • разработка рабочей документации на ИС и ее части;
• • разработка и адаптация программ.

Стадия 7. Ввод в действие:

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

Стадия 8. Сопровождение ИС:

• • выполнение работ в соответствии с гарантийными обязательствами;
• • послегарантийное обслуживание.

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

Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.

Типовое проектное решение (далее — ТПР) — это тиражируемое (пригодное к многократному использованию) проектное решение. Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

• • элементные ТПР — типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
• • подсистемные ТПР — в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
• • объектные ТПР — типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование.

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

Критерии оценки ППП делятся на следующие группы:

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

Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

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

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

Реализация типового проекта предусматривает выполнение следующих операций:

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

Следствием недостатков классических методов проектирования явился переход к системному проектированию.

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

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

Архитектурное описание самым тесным образом связано с процессом проектирования ИС, причем в ряде определений термина «архитектура» на этот факт указывается в явном виде.

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

• 1) стиль, основанный на календарном планировании (Calendardriver0;
• 2) стиль, основанный на управлении требованиями (Requirementsdriven);
• 3) стиль, в основу которого положен процесс разработки документации (Documentation-driven);
• 4) стиль, основанный на управлении качеством (Quality-driven);
• 5) архитектурный стиль (Architecture-driven).

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

Стиль, основанный на управлении требованиями или чертами

(features'), предполагает, что основное внимание уделяется функциональным характеристикам системы, при этом часто недостаточно внимания уделяется нефункциональным характеристикам, таким как масштабируемость, портабельность, поддерживаемость и другим, определенным в ISO 9126. Проектные решения принимаются преимущественно исходя из локальных целей, связанных с реализацией тех или иных функций. Данный подход достаточно эффективен, в случае если требования определены и не изменяются в процессе проектирования. Основными недостатками данного подхода являются следующие: недостаточное внимание уделяется требованиям стандарта ISO 9126 (управление качеством); разрабатываемые архитектуры, как правило, не являются стабильными, так как каждая из реализуемых функций отображается на один или несколько функциональных компонентов. Это обстоятельство усложняет добавление к системе новых требований. Данный подход позволяет успешно отслеживать требования в плане реализации требуемой функциональности, однако использование его для долгосрочных проектов является неэффективным.

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

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

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

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