Аннотация

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

Анотація

Розглянуто головні особливості процесу формування вимог до інформаційних систем управління підприємством. Визначені аксіоми формування вимог до інформаційної системи та висновки з цих аксіом. На базі запропонованих аксіом та висновків розроблено формалізовані описи метамоделей вимог до інформаційної системи.

Annotation

The basiс features of requirements forming process for management information systems is considered. Requirements forming Axioms and theorems for information system are defined. On these axioms the formalized describes of requirements metamodels for information system.

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

Анализ современных методов сбора и обработки требований к информационной системе. Результаты изучения современных технологий проектирования ИС, рассмотренных в [1-3], показывают, что основной всего процесса проектирования является выдвижение и анализ требований заказчика к создаваемой системе. В связи с этим необходимо рассмотреть основные отличия методики формирования и анализа требований, определенной действующими на Украине ГОСТами группы 34 «Информационные технологии», от методик определения требований, определенных современными зарубежными технологиями проектирования ИС.

В [4] определены основные стадии и этапы проектирования ИС, согласно которым определение требований к проектируемой ИС начинается на стадии «Формирование требований к автоматизированной системе» и заканчивается на стадии «Разработка технического задания на автоматизированную систему». При этом последняя стадия фактически является началом проектных работ по созданию ИС, поэтому основные требования к ИС формируются на двух предпроектных стадиях - стадии «Формирование требований к автоматизированной системе» и стадии «Разработка концепции автоматизированной системы». Требования предприятия-заказчика, формируемые на этих стадиях, излагаются в отчетах о проведенной работе и делятся следующим образом:

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

- обоснование выбора перечня автоматизированных функций и комплексов задач с указанием очерёдности внедрения;

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

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

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

- рекомендации по виду создаваемой автоматизированной системы, её совместимости с другими автоматизированными системами и неавтоматизированной частью соответствующей системы;

- рекомендации по организационной и функциональной структуре создаваемой автоматизированной системы;

- рекомендации по составу и характеристикам подсистем и видов обеспечения автоматизированной системы;

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

- рекомендации по рациональной организации и разработки и внедрения автоматизированной системы;

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

- рекомендации по обеспечению производственных условий создания автоматизированной системы;

- рекомендации другие рекомендации по созданию автоматизированной системы;

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

Требования, приводимые в документе «Техническое задание на разработку автоматизированной системы», более подробно описывают проектируемую ИС и делятся на следующие группы [4]:

- требования к системе в целом;

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

- требования к видам обеспечения.

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

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

В подразделе "Требования к видам обеспечения" в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другим видам обеспечения системы.

В отличие от регламентированной ГОСТами последовательности выявления требований к ИС, современные методики проектирования ИС определяют этот же процесс по-другому. В соответствии с положениями данных методик [3] установление требований - первый этап жизненного цикла разработки ИС. Требования определяют услуги, ожидаемые от ИС (формулировки сервисов), и ограничения, которым ИС должна подчиняться (формулировки ограничений). Формулировки сервисов можно объединить в несколько групп:

- формулировки границ ИС;

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

- требуемые структуры данных (требования к данным).

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

Сбор требований осуществляет аналитик бизнес-процессов или системный аналитик с помощью различных методов. Эти методы разделяют на традиционные и современные [5]. К традиционным методам выявления требований относятся использование интервью и анкет, наблюдение и изучение деловых документов. Это простые и экономичные методы. Однако эффективность использования таких методов обратно пропорциональна риску проекта.

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

К современным методам выявления требованиям относятся:

- использование программных прототипов;

- метод совместной разработки приложений (Joint Application Development - JAD);

- метод быстрой разработки приложений (Rapid Application Development - RAD).

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

Результатом выявления требований является документ: содержащий описания требований. Шаблоны такого рода документов определены различными международными стандартами, однако со временем, каждая из организаций-разработчиков ИС создает своим собственные стандарты, соответствующие особенностям данной организации. Обычно, эти документы содержат текстовые описания требований, которые фиксируются специальным образом с выделением формулировок сервисов. Пример такой фиксации и выделения функциональных требований приведен в [6]. В общем же случае, такой документ состоит из следующих разделов [3]:

- предварительные замечания к проекту (цели и рамки проекта; деловой контекст; участники проекта; идеи в отношении решений; обзор документа);

- системные сервисы (рамки системы; функциональные требования; требования к данным);

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

- проектные вопросы (открытые вопросы; предварительный план-график; предварительный бюджет);

- приложения (глоссарий, деловые документы и формы, ссылки).

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

- действующая на Украине технология построения ИС, определенная ГОСТами группы 34 «Информационные технологии», ориентирована на разработку ИС в соответствии с устаревшей моделью каскадного цикла проектирования ИС;

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

- использование современных ИТ обеспечивает значительное сокращение времени на создание видов обеспечений ИС;

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

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

Варианты решения данной проблемы были предложены в ходе проектных работ отделом ИАС «Университет», в функции которого входит администрирование и поддержание работоспособности ИАС. Эти варианты представляют собой руководящие документы, выполненные в виде методических рекомендаций отдела ИАС «Университет». В данных документах представлены расширения и пояснения требований существующих на Украине ГОСТов к процессам создания проектной и рабочей документации на ИС, позволяющие использовать ИТ автоматизации структурного проектирования ИС. В частности, были разработаны методические рекомендации отдела ИАС «Университет» по созданию проектных документов «Описание постановки задачи», на основании которого предусматривается разработка моделей базы данных ИАС «Университет».

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

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

Одним из путей решения данной проблемы является создание специализированных описаний и формализованных представлений, которые определяют не только синтаксис, но и семантику конкретных реализаций моделей ИС и ее компонентов [7]. Такие описания и формализованные представления один из лидеров в разработке и моделировании современных программных систем М. Фаулер предложил называть метамоделями. Представляется разумным предположить, что реализация метамодели открытой системы включает в себя не только определенные типы структур данных и взаимодействие этих структур, но и определенные типы и способы организации этих взаимодействий, то есть имеет характер сложно организованной, но целостной системы взаимодействий и способов организации этих взаимодействий. Следует заметить, что пока это предположение о характере устройства метамодели лишь рабочая гипотеза.

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

Рис. 1. Схема взаимодействия заказчиков, пользователей, аналитиков и проектировщиков информационной системы

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

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

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

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

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

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

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

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

Рис. 2. Схема процесса формирования и анализа требований к информационной системе

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

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

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

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

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

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

В работе [8] предлагается в качестве формализованного описания метамодели ИС использовать аппарат Общей теории систем Ю.А. Урманцева, который рассматривает систему как единство следующего вида [9]

(1)

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

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

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

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

- подмножество , которое используется для описания функций, определенных на множестве структур данных ;

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

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

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

Тогда метамодель требований к ИС как результат объединения моделей требований можно представить алгеброй следующего вида

 (2)

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

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

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

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

Выводы

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

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

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