Книжная полка Сохранить
Размер шрифта:
А
А
А
|  Шрифт:
Arial
Times
|  Интервал:
Стандартный
Средний
Большой
|  Цвет сайта:
Ц
Ц
Ц
Ц
Ц

Прикладная информатика, 2006, №5

Покупка
Основная коллекция
Артикул: 444281.02.99
Прикладная информатика, 2006, №5-М.:Синергия ПРЕСС,2006.-144 с.[Электронный ресурс]. - Текст : электронный. - URL: https://znanium.com/catalog/product/426710 (дата обращения: 29.03.2024). – Режим доступа: по подписке.
Фрагмент текстового слоя документа размещен для индексирующих роботов. Для полноценной работы с документом, пожалуйста, перейдите в ридер.
УВАЖАЕМЫЕ КОЛЛЕГИ!

Пятый номер журнала «Прикладная информатика» посвящен обсуждению актуальных
вопросов, относящихся к рубрикам:

ITбизнес (Информационные системы бизнеса, Консалтинг, Ecommerce);
ITменеджмент (Концепция ITуправления, Системы поддержки принятия решений);
IT в государственных программах (Управление отраслью);
IT и образование (Elearning);
Некоммерческие IT (Управление базами знаний);
Вопросы теории (Управление человеческими ресурсами);
Лаборатория (Синтез организационной структуры);
Hardware (Electronics news — Перспективы нанотехнологий).

Данный номер имеет две особенности. Вопервых, значительное место выделено молодым авторам — будущим кандидатам наук (Н.В. Ковальчук, Ю.С. Закусова, С.С. Монахов,
Д.В. Погуляев, С.О. Мамаева).
Вовторых, впервые мы поместили репортаж с крупной конференции по актуальнейшим вопросам реорганизации российского образования, и, в частности, образования по
IT и прикладной информатике. Конференция в виде «круглого стола» состоялась по инициативе нашего журнала на базе Московской финансовопромышленной академии. В ней
приняли участие представители Министерства образования и науки РФ, государственных
служб и агентств, имеющих непосредственное отношение к образованию, учебнометодических объединений и отдельных вузов, научноисследовательских институтов, занимающихся проблемами информатизации, члены экспертных советов ВАК РФ, а также представители компанийработодателей.

Главный редактор
А.А. Емельянов

Читайте в номере

ИНФОРМАЦИОННЫЕ СИСТЕМЫ БИЗНЕСА
Ю.В. Боковой
Особенности методологии проектирования информационных
систем для малого и среднего бизнеса. . . . . . . . . . . . . . . . . . . . 3
КОНСАЛТИНГ
Н.В. Ковальчук
Применение CASEсредств в консалтинговых проектах . . . . . 12
ECOMMERCE
И.М. Годин
Стандартные платежные процедуры как ключевой фактор
развития мобильной коммерции . . . . . . . . . . . . . . . . . . . . . . . . 26

КОНЦЕПЦИЯ ITУПРАВЛЕНИЯ
Ю.С. Закусова
ITсервисы в процессном подходе к управлению. . . . . . . . . . . 33
СИСТЕМЫ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИЙ
Н.Б. Кобелев
Повышение «электронной готовности» принимаемых
решений на основе имитационного моделирования . . . . . . . . 49

УПРАВЛЕНИЕ ОТРАСЛЬЮ
В.М. Куприянов, В.Н. Пронин, С.А. Емельянов
Задачи сохранения знаний в области атомной науки
и техники . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

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

Ю.Б. Рубин
Инструментальные методы elearning: путь к комплексному
укоренению . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

УПРАВЛЕНИЕ БАЗАМИ ЗНАНИЙ
И.А. Брусакова, С.О. Мамаева
Система управления базами измерительных знаний. . . . . . . . 93

Р.А. Шкундина
Интеллектуальная система поддержки принятия решений
на основе онтологии в сложных биосистемах . . . . . . . . . . . . . 98

УПРАВЛЕНИЕ ЧЕЛОВЕЧЕСКИМИ РЕСУРСАМИ
Ю.Н. Селезнев
Анализ повышения квалификации в наукоемкой
промышленности с позиций открытых систем. . . . . . . . . . . . 104

СИНТЕЗ ОРГАНИЗАЦИОННОЙ СТРУКТУРЫ
Г.В. Росс, Д.В. Янкин
Формирование структуры предприятия с позиций
компетенций персонала на основе моделирования
бизнеспроцессов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

ELECTRONICS NEWS
П.Г. Пронкин, О.Н. Сорокина
Современное состояние и перспективы развития
нанотехнологий. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

РЕПОРТАЖ
«Болонский процесс — это в первую очередь технологии,
а не стандарты». . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

. . . . . 140

Редакционная коллегия

Главный редактор

Емельянов А.А. д.э.н., проф.

Заместитель главного редактора

Власова Е.А.

Члены редколлегии

Акперов И.Г.
д.э.н., проф.
Амбросов Н.В. д.э.н., проф.
Бабошин А.В.

Бугорский В.Н. к.э.н., проф.
Буянова Л.Н.
д.э.н., проф.
Волкова В.Н.
д.э.н., проф.
Диго С.М.
к.э.н., проф.
Дик В.В.
д.э.н., проф.
Емельянов С.А.
Звонова А.Н.
к.э.н.
Иванов Л.Н.
д.т.н., проф.
Коршунов С.В.
к.т.н., проф.
Литвинова О.А. к.э.н.
Нешвеев В.В.
к.т.н., доц.

Попов И.И.
д.т.н., проф.
Потемкин А.И.
д.т.н., проф.
Росс Г.В.
д.т.н., д.э.н., проф.
Рубин Ю.Б.
д.э.н., проф.
Салмин С.П.
д.э.н., проф.
Тельнов Ю.Ф.
д.э.н., проф.
Халин В.Г.
к.ф.м.н., проф.
Хубаев Г.Н.
д.э.н., проф.
Чистов Д.В.
д.э.н., проф.
Шахов Э.К.
д.т.н., проф.
Шориков А.Ф.
д.ф.м.н., проф.

Ю.В. Боковой

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

смысление менеджерами компаний
того факта, что в современных условиях невозможно управлять постарому, привело к широкому использованию
информационных систем (ИС) в деятельности предприятий любого масштаба. Широкий спектр задач, требующих использования ИС, и высокая степень актуальности
обусловили появление большого разнообразия программных продуктов и методов,
в той или иной мере помогающих решению
множества прикладных задач. Следствием
этого является многозначность и неясность,
с которыми сталкиваются заказчик и проектировщик новой ИС. Понимание этого и множество неудач в разработке ИС стали причиной появления новых методологий и стандартов проектирования, а также программных
средств автоматизированного проектирования (CASEтехнологий). Крупные фирмы разработчики тиражируемого программного обеспечения (ПО) создали соответствующие базовые программные продукты, обеспечивающие хранение данных и доступ к ним на
низовом физическом уровне.
В последнее время наблюдается интенсивное развитие интегрированных систем,
выполняющих множество функций бизнеспроцессов планирования и управления. Такие информационные системы, получившие
обобщенное название ERPсистем, кроме
основных функций планирования ресурсов, продаж и управления производством,
пополняются функциональными модулями
прогнозирования спроса, управления проектами, управления затратами, управления
составом продукции, ведения технологической информации, а также управления кадрами и финансовой деятельностью предприятия. Естественно, что такие информационные системы являются уникальными,
дорогими, и их проектирование и разработку могут позволить себе только очень крупные компании. Ведущие мировые фирмы —
разработчики программного обеспечения —
Oracle, SAP и другие, внимательно отслеживают эти тенденции развития и предлагают
свои услуги по разработке таких систем на
базе своих же клиентсерверных систем
управления базами данных (СУБД). Примечательно, что в этот процесс включилась
и Microsoft, которая взяла подряд на разработку и внедрение информационной системы для Правительства РФ (по сообщениям
РосБизнесКонсалтинга).
В то же время любой сложный продукт,
тем более ERPсистема, не может поставляться в виде «коробочного» решения. Основная причина этого в том, что каждый заказчик посвоему уникален,
и подход может быть только индивидуальным. Использование
типовых
решений
позволяет
сократить расходы на индивидуальные настройки, но не исключает их в полной мере.
Весьма большое разнообразие и специфика предметных областей малого и среднего бизнеса также не позволяют использовать для их задач полностью готовое решение. В этой ситуации предприятия малого
и среднего бизнеса могут либо использовать ИС на основе тиражируемых СУБД, например, 1С с ограниченным набором строго регламентированных функций, либо создавать или заказывать уникальные ИС на
основе файлсерверных или клиент серверных тиражируемых СУБД, предлагаемых
российскими и зарубежными фирмами.
Разнохарактерность предприятий малого

ITбизнес Информационные системы бизнеса
3

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

Задачи проектирования ИС

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

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

Отражение предметной области деятельности предприятия сосредотачивается
в информационной базе, которая является
ядром ИС. Все остальные компоненты необходимы для обеспечения эффективного использования информации человеком. Теперь
оценим состояние на текущий момент других компонентов для использования в проекте с точки зрения их проработанности
и степени близости к критическому фактору.
Аппаратное
обеспечение
интенсивно
развивается, обладает весьма широкими
возможностями, как по быстродействию,
так и по объемам хранящихся в нем данных.
Его широкий ассортимент представлен на
рынке и позволяет обеспечить любую необходимую аппаратную конфигурацию. Аналогичными условиями характеризуется системное ПО.
Прикладное ПО разделяется на низкоуровневое (аппаратнозависимое) и, собственно, приложение, обеспечивающее пользователю работу с данными — интерфейс
пользователя. Низкоуровневые СУБД разрабатываются крупными производителями
программного обеспечения, широко представлены на рынке и являются базовой
основой для построения ИС, отвечающей
нуждам предприятия, фирмы. Часто российские разработчики ИС (например, системы
«Галактика») также используют в качестве
базовой СУБД системы ведущих мировых
производителей — Oracle, Microsoft и др.
Наиболее эффективным подходом для построения ИС небольшого предприятия является ее проектирование на основе недорогой тиражной СУБД, например Fox Pro,
Paradox или другой подходящей системы.
При этом необходимо учесть ряд особенностей, которые должны обеспечить необходимые качества проекта.

Особенности методологии
процесса поэтапного проектирования
специализированных ИС

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

4
ITбизнес Информационные системы бизнеса

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

анализа предметной области и формирования требований к ИС;
проектирования;
разработки;
тестирования ПО и внедрения.

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

ITбизнес Информационные системы бизнеса
5

Ю.В. Боковой

этого можно исключить формальное выполнение этапа анализа и сразу строить
модель предметной области в варианте
«как должно быть». Дальнейший процесс
проектирования предусматривает несколько этапов. Каждый последующий этап характеризуется снижением уровня абстракции по сравнению с предыдущим. Для стадии проектирования можно выделить три
таких уровня: концептуальный, логический
и физический.
В некоторых источниках [2, 7] рассматривается еще один уровень — внешний.
Этот уровень отражает работу с данными
с точки зрения пользователя. Поскольку
этот вопрос относится к стадии разработки
прикладного программного обеспечения
ИС, то здесь он не рассматривается.
Полученная в результате проработки каждого уровня приведенного перечня соответствующая модель должна быть представлена в виде схемы на основе использования той или иной выбранной нотации.
Рассмотрим некоторые методические
проработки и соответствующий инструментарий, необходимые для выполнения каждого этапа проектирования специализированных ИС. Такое рассмотрение целесообразно начать с конца, т.е. с физической модели, так как при этом лучше проявляются
цели, отвечающие задачам и характерные
особенности каждого этапа.
Физическая модель реляционной базы
данных отображается в виде набора взаимосвязанных таблиц, как правило, отвечающих требованиям третьей нормальной формы или форме Бойса–Кодда. Эта модель является последним шагом проектирования
и ориентирована на реализацию в конкретной СУБД.
Методика и техническая сторона построения реляционной базы данных не
имеет специфики, поэтому она подходит
для ИС любого масштаба, достаточно хорошо формализована и проработана, что отражено во многих источниках, и не требует
более детального рассмотрения в данной
статье. Инструментарий построения физической модели базы данных входит в состав ПО практически любой тиражируемой
СУБД. Имеющиеся на рынке тиражируемые СУБД — Access, Fox Pro и другие —
предоставляют неплохой инструментарий
для формирования физической модели базы данных.
Физическая модель данных строится на
основе более абстрактной модели, которая
привязана не к конкретному программному
обеспечению, а к данным. Эти данные должны быть отражены в виде некоторой схемы
взаимосвязанных блоков, обозначающих
сущности и их атрибуты. В разных источниках такая модель имеет название логической [4], инфологической [3], даталогической [6] и концептуальной [8].
В любом случае даталогическая модель
ориентирована на так называемую ERмодель, иначе модель сущностьсвязь. Основным свойством такой модели является отражение совокупности всех сущностей и их
атрибутов, описывающих предметную область и связи между сущностями. Для построения таких моделей используется инструментарий, позволяющий строить ERдиаграммы (ERD). Некоторые тиражные СУБД
в составе своего ПО имеют специальный
инструментарий, предназначенный для построения таких моделей, как, например,
Power Designer в составе СУБД Sybase.
В некоторых источниках детальное рассмотрение процесса проектирования начинается с этого этапа. При этом предполагается, что анализ предметной области проведен и выявлены все описывающие ее
сущности. Этот упрощенный подход при
проектировании несложных ИС позволяет получить быстрый результат и часто используется прикладными программистами,
но не профессиональными проектировщиками. Игнорирование предварительного подробного описания предметной области, часто приводит к серьезным потерям, если возникает необходимость развития системы
(а такая необходимость возникает практически всегда). Известно, что ошибки в проектировании на ранних этапах обходятся

6
ITбизнес Информационные системы бизнеса

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

существенно дороже, чем на последующих. Обычно основными ошибками являются неверная идентификация сущностей и атрибутов, непродуманный выбор ключевых
сущностей и, как следствие, неправильное
установление связей между ними. Определение набора сущностей и связи между
ними, описывающих предметную область,
для которой проектируется ИС, является
ключевым моментом для построения базы
данных.
Концептуальная модель должна обеспечить выявление необходимого и достаточного набора сущностей. Она не сводится
к представлению только в виде некоторой
схемы, но в данной статье мы будем рассматривать ее именно в таком понимании.
Построение этой модели наиболее сложный и ответственный этап проектирования.
Необходимо формализовать предметную
область, а это творческий и неоднозначный
процесс. Сложность его выполнения обусловлена большим разнообразием предметных областей, поэтому он не поддается
строгой формализации. Актуальность решения подобных задач привела к разработке методологии SADT и набора стандартов
под
общим
названием
IDEF
(Integrated
DEFinition). Эта методология в последнее
время получила широкое распространение. Она характеризуется достаточно хорошо проработанным инструментарием, например в AllFusion Process Мodeler.
Анализ и последующее проектирование
на основе указанной методологии для крупных предприятий большая и трудоемкая работа, требующая выполнить множество итераций в течение достаточно продолжительного времени. Универсальность этой методологии обеспечила ей широкую популярность
и сделала практически необходимым этапом разработки ИС. Целью этого этапа является получение строгой модели функциональной деятельности, полностью описывающей функции ИС в рамках сформулированных задач. В рассматриваемой методологии IDEF такая модель получила название
TOBE (как будет). Для специализированных

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

Особенности процесса проектирования
специализированных ИС

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

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

ITбизнес Информационные системы бизнеса
7

Ю.В. Боковой

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

IDEF0 — функциональное моделирование, когда функции системы представлены независимо от объектов, которые их выполняют;
IDEF1X — используется для инфологического проектирования баз данных;
IDEF3 — используется для моделирования бизнеспроцесса как упорядоченной
последовательности событий;
DFD (Data Flow Diagrams) — диаграммы потоков данных, моделируют систему
как набор действий.

Эти методики позволяют визуализировать
модель в виде диаграмм, имеют специфическую нотацию, и могут использоваться совместно для анализа и проектирования ИС.
Основной задачей информационной системы является информационное сопровождение функционирования компании, а функционирование не что иное, как некоторый
набор последовательных действий. Для ИС
любого масштаба принято, что начальная модель должна описывать функциональную деятельность предметной области. То есть должна быть построена функциональная модель
в виде последовательности действий над материальными объектами как носителями и
преобразователями информации, что может
быть выполнено с помощью методики IDEF0.
В последующем при необходимости могут
быть построены модели, отражающие потоки данных, последовательность процессов,
организационную структуру и т.п. Методика
и инструментарий применения методологии
для всех видов систем достаточно подробно
отражены в ряде источников [4, 8].
Формальный инструментарий указанных
методик, однако не затрагивает конкретики
предметных областей. Его применение эффективно, графический инструментарий построения диаграмм хорошо проработан, но
степень формализации не сводит процесс
проектирования к простому выполнению некоторого набора операций, однозначно приводящих к положительному результату. Обратной стороной универсализма является
расплывчатость и вариабельность в практическом использовании инструментария.
Основополагающий принцип построения
модели предметной области — принцип последовательной декомпозиции при построении иерархии все более подробных и конкретных диаграмм, не должен нарушаться и
при проектировании специализированных ИС.
Учитывая простоту и эффективность
применения для проектирования специализированных ИС, ограничимся только использованием методики IDEF0. Инструментарий, позволяющий строить функциональную модель IDEF0, присутствует в составе
многих программных продуктов, в том числе
и графических, например MS Visio. Подходящим выбором для нашего случая является BPwin, входящий в состав программного
продукта AllFusion Process Мodeler.
Сформулируем методические требования
к проектированию специализированной ИС:

методология — структурный метод;
жизненный цикл процесса проектирования — линейный;
используемая технология — IDEF0;
используемый инструментарий — BPwin;
используемая СУБД — одна из недорогих широко тиражируемых.

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

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

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

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

Обратная связь и ее представление
на диаграммах декомпозиции
Особую роль в информационных системах играет обратная связь. Ее значение
имеет фундаментальный характер для всех
систем управления и для ИС в частности.
Роль обратной связи заключается в передаче информации (а иногда и материальных
объектов как носителей информации) от
объекта управления как части управляемой
подсистемы, управляющему органу, который является частью управляющей подсистемы. В технических системах автоматического управления эта связь обеспечивается физическим образом, а в автоматизированных системах управления, в том числе
и информационных, замыкание цепи обратной связи носит чисто информационный характер и происходит с участием человека,
например, через реализацию функции управления лицом, принимающим решения.
В основополагающей для CASEтехнологий работе [5] предложено рассматривать в SADTметодологии два вида обратной связи — по управлению и по потоку данных. Принимая такой подход, уточним особенности представления этих видов обратной связи для нашего случая.
В любом случае цепь обратной связи может исходить из функционального блока,
функцией которого является выбор альтернативы, т.е. принятие того или иного решения. Следовательно, такой блок должен иметь
более одного выхода. Если функция такого
блока имеет целью распределить поток некоторых материальных объектов по какомулибо признаку, например отбраковка деталей по признаку годен — не годен, то такой
блок должен иметь дугу входа и дугу управления. При этом дуги входа и обоих выходов
должны идентифицировать сущности. В данном случае блок выполняет функцию разделения пути передачи данных, в том числе
и материального объекта, как по прямой, так
и по обратной связи, т.е. с выхода одного
функционального блока на вход другого.
В качестве графического образа представления разветвления информационных потоков предлагается использовать ромб (который широко применяется при составлении
блоксхем алгоритмов). BPwin в арсенале
нотаций IDEF0 допускает возможность альтернативного представления для функциональных блоков, и для использования нетрадиционного представления функционального
блока в виде ромба необходимо использовать опцию контекстного меню — Box Style.
В другом случае, т.е. если функция блока
определена как принятие чисто информационного решения, выходы блока являются
управляющими входами других блоков. Тогда рассматриваемый блок не должен иметь
дуг функциональных входов и выходов,
а только дуги, являющиеся управляющими
для других функциональных блоков.
Известно, что любая схема действий может быть представлена тремя логическими
элементами — «И», «ИЛИ», «НЕ». Но в инструментарии BPwin элемент «НЕ» отсутствует. Ограничения инструментария IDEF0 на
эффективное представление обратных связей может быть преодолено, если при декомпозиции использовать нотацию инструментария IDEF3. Но все же в нашей постановке

ITбизнес Информационные системы бизнеса
9

Ю.В. Боковой

ITбизнес Информационные системы бизнеса

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

Рис. 1. Модель «Работа сборочного цеха»