Рис. 4.1. Представление технологической операции проектирования.
4.1. ОБЩИЕ МЕТОДЫ И ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ИС
В информационных системах методы реализуются через конкретные информационные технологии и поддерживающие их стандарты, инструкции и инструментальные средства, которые обеспечивают выполнение процессов жизненного цикла ИС.
Методы проектирования ИС подразумевают использование определённых программных и аппаратных средств, составляющих инструментальные средства программирования ИС.
Метод проектирования включает совокупность трёх составляющих:
1) пошаговой процедуры, определяющей последовательность технологических операций проектирования (рис. 4.1);
2) критериев и правил, используемых для оценки результатов выполнения технологических операций;
3) нотаций (графических и текстовых средств), используемых для описания проектируемой системы.
Рис. 4.1. Представление технологической операции проектирования.
Практически любой технологический процесс может быть частью сложного процесса. Он может включать в себя набор простых (менее сложных) технологических процессов и операций. Он может начинаться с любого уровня и не включать, например, этапы или операции, а состоять только из действий. Для реализации этапов технологического процесса могут использоваться разные программные среды и технологические операции и инструкции.
Технологическую операцию считают элементарным (простым) технологическим процессом. При этом, информационная операция – это отдельная законченная часть процесса (изменение содержания областей смыслового пространства субъекта) или инструкция.
Технологические инструкции, составляющие основное содержание технологии, состоят из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.
При проектировании ИС должны быть сформированы общие требования к ней (один из ключевых факторов успеха), поскольку изменения одних блоков, элементов и задач может повлечь за собой изменение к другим, связанным с ними элементам и процессам. При этом возникает риск, что система не сможет полностью или частично реализовать поставленные перед ней задачи, а неконтролируемые изменения и затраты на них могут привести к бесконечному переделыванию и доделыванию системы.
Чем больше число задач, требующих изменения, чем больше они критичны для проектируемой системы, тем должен быть выше уровень компетенции её разработчиков и ИТ-специалистов организации, в которой предполагается внедрить такую систему.
Поскольку требования к системе могут часто и значительно меняться, необходимо организовать доступ всем участникам проекта к информации о проекте, оперативный обмен информацией между ними, а также сбор и систематизацию требований и решений. В этом случае должна существовать инфраструктура сопровождения и развития системы, включающая средства управления требованиями и изменениями, контроль версий и др.
Реальное применение любой технологии проектирования, разработки и сопровождения ИС невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К ним относят стандарты:
Проектирование вообще и ИС в частности обычно осуществляется поэтапно. В общем случае основные этапы проектирования, заключаются в проведении некоторой последовательности исследований (рис. 4.2).
Рис. 4.2. Этапы (последовательность) исследований.
Исследования заканчиваются формированием требований и разработкой на их основе технического задания (ТЗ), в разделе конкретных видов деятельности которого формулируются цели и задачи, области применения и пользователи АИС, устанавливаются источники исходных данных, определяются информационные потребности пользователей и др.
Наиболее часто при проектировании ИС используют технологии и методы системного проектирования.
Системное (предварительное, концептуальное) проектирование включает в себя следующие стадии:
1) определение общих целей проектирования с формированием локальных (отдельных) целей разработки;
2) формирование концепции системы (объекта исследования) и подготовки данных для создания модели объекта;
3) разработки описания системы в виде структур объекта проектирования и построения функциональных подсистем объекта;
4) формализация задач проектирования, в том числе формирование области поиска решений, систем предпочтений и ограничений, требований к объекту и т.п.
Результатом системного (концептуального) проектирования является разработка ТЗ и, при необходимости, технико-экономического обоснования.
Рассмотрим более подробно аспекты, связанные с концептуальным проектированием.
КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Концептуальное проектирование порой называют техническим. Его основными этапами являются:
1) предварительное проектирование,
2) эскизное (рабочее или техно-рабочее) проектирование,
3) изготовление, испытания и доводка опытного образца системы (рис. 4.3).
Рис. 4.3. Этапы концептуального проектирования.
Стадия концептуального проектирования начинается с детального анализа первичных данных и уточнения концептуальной модели данных, после чего проектируется архитектура системы. При этом оценивается возможность использования существующих ИС и выбирается соответствующий метод их преобразования. После построения проекта уточняется исходный бизнес-план. Выходными компонентами этой стадии являются концептуальная модель данных, модель архитектуры системы и уточнённый бизнес-план.
В ходе выполнения последующих стадий проектирования предполагается более глубокая и детализированная проработка решений, выработанных на данной стадии. При этом не исключается появление необходимости их существенного изменения. Хотя действующие нормативные документы предусматривают возможность, внесение изменений в проект или программу (концепцию), как правило, это связано с потерями финансовых, материальных и трудовых ресурсов как со стороны “Заказчика”, так и “Разработчика”. Указанные потери могут оказаться весьма значительными, если необходимо вносить весомые изменения в первоначальные проектные решения и чем позже эта потребность возникает. Отсюда следует особая значимость данной стадии проектирования для успешного создания АИС, а также ответственность Разработчиков и Заказчика при выполнении работ и согласовании итогового документа.
На стадии разработки, интеграции и тестирования должна быть создана тестовая БД и тесты. Проводится разработка, прототипирование и тестирование баз данных и приложений в соответствии с проектом. Отлаживаются интерфейсы с существующими системами. Описывается конфигурация текущей версии ПО. На основе результатов тестирования проводится оптимизация БД и приложений. Приложения интегрируются в систему, проводится их тестирование в составе системы и испытания системы. Основными результатами стадии являются готовые приложения, проверенные в составе системы на комплексных тестах, текущее описание конфигурации ПО, скорректированная по результатам испытаний версия системы и эксплуатационная документация на систему.
В результате такого проектирования должна быть получена логическая структура системы (подсистемы, модуля и др.), схемы вводы, вывода, представления, преобразования данных и т.п.
В соответствии с уставными правилами и документацией проекта заключительный этап создания системы предполагает комплексное тестирование всех её компонентов, обучение пользователей, постоянное администрирование и др.
Стадия внедрения включает в себя действия по установке и внедрению баз данных и приложений. Основной результат стадии – готовая к эксплуатации и перенесенная на программно-аппаратную платформу Заказчика версия системы, документация сопровождения и акт приёмочных испытаний по результатам опытной эксплуатации.
На стадии эксплуатации осуществляется постоянный (лучше – автоматический) контроль работоспособности системы (мониторинг) с целью отслеживания состояния объектов, своевременного выявления ошибок и нештатных ситуаций, её развития.
Стадии сопровождения и развития включают процессы и операции, связанные с регистрацией, диагностикой и локализацией ошибок, внесением изменений и тестированием, проведением доработок, тиражированием и распространением новых версий ПО в места его эксплуатации, переносом приложений на новую платформу и масштабированием системы. Стадия развития фактически является повторной итерацией стадии разработки.
Результатом концептуальной стадии проектирования АИС является итоговый документ – “Концептуальный проект”, “Аванпроект”, “Пилотный проект” или “Концепция и программа создания…”. В дальнейшем будут преимущественно использоваться термины “Концептуальный проект” и “Концепция” или “программа создания…”.
Концептуальное проектирование системы характеризуется сжатыми сроками. По этой причине выполнение работ, связанных с ним и предпроектным обследованием объекта могут осуществляться параллельно или перекрываться по времени их выполнения.
При проектировании, в т.ч. при решении проблем автоматизации процессов, обычно изначально принимается один из двух вариантов: создание системы решающей сиюминутные задачи или включающей и перспективные задачи (“на вырост”), учитывающие будущие потребности.
В первом случае можно выбрать недорогое решение и быстро его реализовать. Однако высока вероятность, что достаточно скоро такую систему потребуется в значительной степени модернизировать или заменить.
Во втором случае потребуется более серьёзная проработка требований и технических решений, влекущая за собой увеличение сроков выполнения и стоимости проекта. Но в этом случае возможно на гораздо больший период времени продлить эффективное функционирование созданной таким образом системы. Однако большие инвестиции сопряжены с бóльшими рисками. Поэтому рекомендуется разбивать предстоящие работы на небольшие этапы, реализация которых способна принести конкретный и ощутимый результат, обеспечивающий решение поставленной задачи. В этом случае при минимальных инвестициях можно обеспечить быструю отдачу и создать фундамент дальнейшего развития системы, способствующий, в том числе, изучению полученных результатов, корректировки дальнейших действий и т.п. Таким образом, разработка системы приобретает цикличный характер. И хотя подобный подход несколько более затратный, чем комплексное решение масштабной задачи, он позволяет уменьшить высокие риски, связанные с изменениями требований к разрабатываемой системе.
Не следует упускать из виду, что быстрое развитие науки, техники и технологий приводит к быстрому старению используемых методов и систем, что отрицательно влияет на эффективность их использования. При этом поэтапно вносить изменения в отдельные компоненты системы значительно проще, чем заменять её полностью. Кроме того, обычно требуется обеспечить быстрый возврат инвестиций, что достаточно сложно организовать при внедрении комплексных решений.
Можно выделить три основных вида проектирования объектов и систем по степени их сложности, объёму и ряду других показателей: крупные, средние и малые (мелкие) проекты.
При реализации крупных проектов обычно прибегают к помощи хорошо зарекомендовавших себя крупных компаний-интеграторов, в том числе консалтинговых и внедренческих организаций.
Для реализации средних проектов стараются обойтись своими силами и (или) используют готовые решения, которые стремятся адаптировать под конкретные требования организации-заказчика.
Малые проекты характеризуются использованием готовых решений и, в ряде случаев, адаптацией их под конкретные условия использования.
Проектирование ИС начинается с составления в текстовой и (или) графической форме плана работ. На первом этапе проектирования необходимо выяснить требования пользователей к системе и, на основании этих требований, сформировать макет системы. Предпочтительно осуществлять проектирование модульным методом. Проектирование информационных систем непосредственно связано с их программированием, поэтому значительная часть проектных работ связана с программированием ИС.
Модульное программирование – метод разработки программ, предполагающий разбиение программы на независимые модули. Считается, что модуль должен обладать оптимальными размерами (как правило, целиком помещаться на экране дисплея) и что разделение большой программы на модули облегчает её разработку, отладку и сопровождение.
Программный модуль, объединяющий в себе данные (свойства) и операции над ними (методы), называют объектом.
Объект – абстрактное множество предметов, все предметы которого имеют одни и те же характеристики.
На выбор средств проектирования могут существенно повлиять следующие особенности методов проектирования:
ER-модели
Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В 1976 году Чен (Chen) предложил для проектирования ИС (баз данных) использовать ER-модели (Entity Relationship model – модель «сущность-связь»), представляющие концептуальные модели данных. Они получили широкое распространение в современных CASE-системах, поддерживающих автоматизированное проектирование ИС и обычно используются на этапе информационно-логического моделирования.
ER-модель наглядно изображает структурные блоки информации и логические взаимосвязи между ними. Основными понятиями являются сущность, связь и атрибут (см. Таблицу).
Таблица понятий: сущность, связь и атрибут.
| Понятие | Трактовка | Примеры
| Сущность
| (Entity) Некоторый отличимый объект
| 1. Поставщик, деталь, поставка
| 2. Работник, отдел, человек 3. Произведение, концерт, оркестр, дирижер Свойство
| (Property) Элемент информации, описывающий сущность
| 1. Номер поставщика, поставляемое количество
| 2. Отдел работника, рост человека 3. Тип концерта Связь
| (Relationship) Сущность, которая служит для обеспечения взаимодействия между двумя или более другими сущностями
| 1.Поставка: поставщик – деталь
| 2.Должность: работник – отдел 3.Запись: произведение – оркестр – дирижер |
Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь «Руководство» имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь «Участие» имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать много сотрудников. На рисунке приведен пример ER-диаграммы.
На основе ER-моделей последовательно формируют реляционные БД.
Важным параметром ИС является простота её использования, включающая обеспечение качества проектной документации. При проектировании следует ориентироваться на следующие документы:
ГОСТ 24.602-86. Автоматизированные системы управления. Состав и содержание работ по стадиям создания. (Введён с 01.01.89.–М.: Изд-во стандартов, 1986.–12 с.).
ГОСТ 34.601-90. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания ( Введён с 29.12.90, 24.601-86. 24.602-86. 1997 г.).
ГОСТ 34.602-89. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Введ. 01.01.90.
ГОСТ 34.603-92. Информационная технология. Виды испытаний автоматизированных систем.
РД 50-640-87. Системы автоматизированного проектирования. Порядок выполнения работ при создании систем: Инструкция.–М.: Изд-во стандартов, 1987.–28 с. и др.