Введение

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

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

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

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

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

Концептуальные основы создания ИС предприятия

Основополагающая концепция

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

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

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

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

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

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

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

За последние несколько лет сформировалось новое направление в программотехнике - CASE (Computer Aided System/Software Engineering). Хотя в настоящее время не существует общепринятого определения CASE, и содержание этого понятия обычно определяется перечнем решаемых задач, а также совокупностью применяемых методов и средств, грубо можно сказать, что CASE представляет собой совокупность методологий анализа, разработки и сопровождения сложных систем (в основном заказных систем программного обеспечения АСУ), поддержанную комплексом взаимосвязанных средств автоматизации. CASE - это инструментарий для системных аналитиков и программистов, позволяющий автоматизировать процессы анализа, проектирования и реализации систем.

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

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

Основными пользователями CASE-систем являются:

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

Существует мнение, что CASE, наряду с системами визуального программирования, является наиболее перспективным направлением в программотехнике. С этим можно спорить, но то, что CASE - наиболее динамично развиваемое направление, является в настоящее время неоспоримым фактом. Практически не один серьезный американский или японский программный проект не осуществляется без использования CASE-средств. Известная методология структурного системного анализа SADT - Structured Analysis and Design Technique (точнее ее подмножество IDEF0) принята в качестве стандарта на разработку средств программного обеспечения Министерством обороны США. Более того, среди менеджеров и руководителей компьютерных фирм считается чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.

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

Жизненный цикл ИС

В основе деятельности по созданию и использованию ИС лежит понятие жизненного цикла.

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

Опыт создания и использования заказных ИС позволяет условно выделить следующие основные этапы их жизненного цикла:

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

Этапы разработки, тестирования и внедрения ИС обозначаются единым, объемлющим термином - реализация.

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

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

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

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

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

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

Структурный анализ

Анализ является первым этапом создания ИС, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается ответ на вопрос: "Что должна делать будущая система?". Именно здесь лежит ключ к успеху всего проекта.

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

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

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

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

Вторая стадия работы, к которой привлекаются заинтересованные представители заказчика, а при необходимости и независимые эксперты, состоит в анализе модели "как есть", выявлении ее недостатков и узких мест, определение путей совершенствования системы управления на основе выделенных критериев качества.

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

Заканчивается процесс разработкой "карты автоматизации", представляющей собой модель реорганизованной предметной области, на которой обозначены "границы автоматизации".

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

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

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

Принципы структурного анализа

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

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

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

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

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

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

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

Выделение двух базовых принципов инженерии информационных систем не означает, что остальные принципы являются второстепенными. Отметим основные из них.

1. Принцип концептуальной общности - заключается в следовании единой философии на всех этапах жизненного цикла.
2. Принцип полноты - заключается в контроле на присутствие лишних элементов.
3. Принцип непротиворечивости заключается в обоснованности и согласованности элементов системы.
4. Принцип абстрагирования - заключается в выделении существенных аспектов системы и отвлечение от несущественных с целью представления проблемы в более простом, общем виде.
5. Принцип упрятывания - заключается в упрятывании несущественной на конкретном этапе информации: каждая часть "знает" только необходимую ей информацию.
6. Принцип логической независимости заключается в концентрации внимания на логическом описании системы, обеспечении независимости от ее физической реализации.
7. Принцип независимости данных заключается в том, что модели данных могут быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.

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

Средства структурного анализа

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

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

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

Среди всего многообразия средств решения указанных задач в методологиях структурного анализа наиболее часто и эффективно применяемыми являются:

• FDD (Functional Decomposition Diagrams) - диаграммы функциональной декомпозиции;
• DFD (Data Flow Diagrams) - диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь"

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

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

CASE-технология

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

1. Проведение функционального и информационного обследования системы управления (административно-управленческой деятельности) предприятия:

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

2. Разработка моделей деятельности структурных элементов и системы управления в целом:

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

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

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

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

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

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

1. Она включает в себя модель существующей неавтоматизированной технологии, принятой на предприятии. Формальный анализ этой модели позволяет выявить узкие места в управлении предприятием и сформулировать рекомендации по его улучшению (независимо от того, предполагается ли дальнейшая разработка автоматизированной системы или нет).
2. Она независима и отделяема от конкретных разработчиков, не требует сопровождения и может быть безболезненно передана другим лицам. Более того, если по каким-либо причинам предприятие не готово к реализации проекта в данный момент времени, модель может быть "положена на полку" до тех пор, пока в ней не возникнет необходимость.
3. Она позволяет осуществлять эффективное обучение новых работников конкретным направлениям деятельности предприятия, так как соответствующие технологии содержатся в модели.
4. С ее помощью можно осуществлять предварительное моделирование перспективных направлений деятельности предприятия с целью выявления новых потоков данных, взаимодействующих процессов и структурных элементов.
5. Она обеспечивает распространение накопленного опыта на других предприятиях, дает возможность унифицировать административно-управленческую и финансовую деятельность этих предприятий.

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

Часть 2