CC BY
352
Ив52006
Ю.В. Боковой
Особенности методологии проектирования информационных систем для малого и среднего бизнеса
Осмысление менеджерами компаний того факта, что в современных условиях невозможно управлять по-старому, привело к широкому использованию информационных систем (ИС) в деятельности предприятий любого масштаба. Широкий спектр задач, требующих использования ИС, и высокая степень актуальности обусловили появление большого разнообразия программных продуктов и методов, в той или иной мере помогающих решению множества прикладных задач. Следствием этого является многозначность и неясность, с которыми сталкиваются заказчик и проектировщик новой ИС. Понимание этого и множество неудач в разработке ИС стали причиной появления новых методологий и стандартов проектирования, а также программных средств автоматизированного проектирования (CASE-технологий). Крупные фирмы разработчики тиражируемого программного обеспечения (ПО) создали соответствующие базовые программные продукты, обеспечивающие хранение данных и доступ к ним на низовом физическом уровне.
В последнее время наблюдается интенсивное развитие интегрированных систем, выполняющих множество функций бизнес-процессов планирования и управления. Такие информационные системы, получившие обобщенное название ERP-систем, кроме основных функций планирования ресурсов, продаж и управления производством, пополняются функциональными модулями прогнозирования спроса, управления проектами, управления затратами, управления составом продукции, ведения технологической информации, а также управления кадрами и финансовой деятельностью пред-
приятия. Естественно, что такие информационные системы являются уникальными, дорогими,и их проектирование и разработку могут позволить себе только очень крупные компании. Ведущие мировые фирмы — разработчики программного обеспечения — Oracle, SAP и другие, внимательно отслеживают эти тенденции развития и предлагают свои услуги по разработке таких систем на базе своих же клиент-серверных систем управления базами данных (СУБД). Примечательно, что в этот процесс включилась и Microsoft, которая взяла подряд на разработку и внедрение информационной системы для Правительства РФ (по сообщениям РосБизнесКонсалтинга).
В то же время любой сложный продукт, тем более ERP-система, не может поставляться в виде «коробочного» решения. Основная причина этого в том, что каждый заказчик по-своему уникален, и подход может быть только индивидуальным. Использование типовых решений позволяет сократить расходы на индивидуальные настройки, но не исключает их в полной мере.
Весьма большое разнообразие и специфика предметных областей малого и среднего бизнеса также не позволяют использовать для их задач полностью готовое решение. В этой ситуации предприятия малого и среднего бизнеса могут либо использовать ИС на основе тиражируемых СУБД, например, 1С с ограниченным набором строго регламентированных функций, либо создавать или заказывать уникальные ИС на основе файл-серверных или клиент серверных тиражируемых СУБД, предлагаемых российскими и зарубежными фирмами. Разнохарактерность предприятий малого
Особенности методологии проектирования информационных систем для малого и среднего бизнеса
№>52006
и среднего бизнеса и их бизнес-функций обусловливает актуальность разработки для них собственных ИС.
Поскольку нет строгого подходящего термина, в дальнейшем информационные системы для малого и среднего бизнеса будем называть «специализированные ИС» в смысле противопоставления масштабу корпоративных ИС, и только частично в смысле широты охвата предметной области.
Задачи проектирования ИС
Под проектированием понимается обычно некоторый унифицированный подход, который определяет пути решения поставленной задачи. Целью проектирования является создание проекта такой системы, которая будет удовлетворять заданным, возможно неформальным, требованиям, что предполагает необходимость иметь техническое задание на проектирование ИС. Собственно само проектирование должно начинаться с составления технического задания на проект. Тем не менее, ясно, что не существует такого универсального метода, который позволил бы разработчику пройти однозначный последовательный путь от требований к сложной системе до их выполнения. Проектирование сложной системы отнюдь не сводится к слепому следованию некоторому набору действий. Это, как правило, постепенный и итеративный процесс, но все же использование методологии проектирования вносит в процесс разработки определенную организованность.
Определим обобщенный функциональный состав ИС, независимо от ее размера и сложности, как набор следующих компонентов:
• информационная база (в первую очередь — база данных);
• система хранения и управления данными, интерфейс пользователя (прикладное ПО);
• системное ПО;
• аппаратное обеспечение;
• человек, как пользователь и/или лицо принимающее решение.
Отражение предметной области деятельности предприятия сосредотачивается в информационной базе, которая является ядром ИС. Все остальные компоненты необходимы для обеспечения эффективного использования информации человеком. Теперь оценим состояние на текущий момент других компонентов для использования в проекте с точки зрения их проработанности и степени близости к критическому фактору.
Аппаратное обеспечение интенсивно развивается, обладает весьма широкими возможностями, как по быстродействию, так и по объемам хранящихся в нем данных. Его широкий ассортимент представлен на рынке и позволяет обеспечить любую необходимую аппаратную конфигурацию. Аналогичными условиями характеризуется системное ПО.
Прикладное ПО разделяется на низкоуровневое (аппаратно-зависимое) и, собственно, приложение, обеспечивающее пользователю работу с данными — интерфейс пользователя. Низкоуровневые СУБД разрабатываются крупными производителями программного обеспечения, широко представлены на рынке и являются базовой основой для построения ИС, отвечающей нуждам предприятия, фирмы. Часто российские разработчики ИС (например, системы «Галактика») также используют в качестве базовой СУБД системы ведущих мировых производителей — Oracle, Microsoft и др. Наиболее эффективным подходом для построения ИС небольшого предприятия является ее проектирование на основе недорогой тиражной СУБД, например Fox Pro, Paradox или другой подходящей системы. При этом необходимо учесть ряд особенностей, которые должны обеспечить необходимые качества проекта.
Особенности методологии процесса поэтапного проектирования специализированных ИС
Технологический процесс проектирования как для больших, так и для малых ИС состоит из ряда стадий, таких как стадия:
Ив5 2006
• анализа предметной области и формирования требований к ИС;
• проектирования;
• разработки;
• тестирования ПО и внедрения.
Рассмотрим более подробно лишь стадию проектирования.
Сама стадия проектирования ИС состоит из нескольких этапов и выполняется путем построения иерархии моделей, начиная с концептуальной модели предметной области и заканчивая физической моделью информационной базы. Далее будем придерживаться этого подхода, имея в виду, что для его реализации существует широкий набор инструментальных методов под общим названием CASE-технологии. В общем случае методы реализации CASE-технологий ориентированы на проектирование интегрированных корпоративных систем, но использование их для проектирования небольших и даже локальных ИС также достаточно эффективно.
Общепризнано, что перед началом выполнения проекта необходимо иметь полное представление о предметной области, т.е. иметь некоторую описывающую ее модель. Идеи и подходы к анализу и проектированию ИС на основе семантического моделирования оказались весьма плодотворными и широко, хотя и с некоторыми изменениями, используются в качестве инструментария во многих современных СУБД.
Рассмотрим особенности построения набора моделей с точки зрения их эффективного использования применительно к нашей задаче.
Методы моделирования разделяются на объектно-ориентированные и структурные («алгоритмический подход» по терминологии Г. Буча [1]). Хотя обе схемы решают одну и ту же задачу, но делают они это разными способами. Несмотря на то что концептуальный уровень моделирования является аппаратно-независимым, все же вид и свойства концептуальной модели зависят от вы-
бранного метода моделирования. К реализации объектной модели приводит разработка информационной модели, опирающейся на описание объектов предметной области совместно с их свойствами. Описание объектов как сущностей и атрибутов отдельно от описания их свойств реализуется в структурной модели. Выбор метода моделирования предусматривает и дальнейшую ориентацию на использование того или иного подхода к проектированию и возможности использования различных соответствующих программных средств. Объектноориентированный подход позволяет не придерживаться строгой последовательности выполнения этапов проектирования и предполагает итеративный характер работы над проектом. Он обладает несомненными достоинствами для крупных проектов, работа над которыми выполняется большими коллективами программистов. В этом случае проект разбивается на части, каждая из которых выполняется отдельной группой разработчиков.
Логично предположить, что информационные потребности бизнеса предприятия малого масштаба в большинстве случаев могут быть представлены в виде реляционной базы данных. Это обусловливает выбор структурного метода для моделирования предметной деятельности малого и среднего бизнеса. Этого подхода будем придерживаться далее.
Следующим вопросом, возникающим при планировании проектирования специализированных ИС, является определение начального этапа с которого следует начать проработку проекта.
При стандартном подходе к проектированию ИС на первом этапе анализируют предметную область и строят модель, описывающую функциональную деятельность компании. В нашем случае для специализированных ИС, следует принять во внимание, что топ-менеджеры малого и среднего бизнеса обычно полностью и в деталях представляют технологический процесс функционирования своей фирмы. С учетом
N__5
Ю.В.Боковой
Особенности методологии проектирования информационных систем для малого и среднего бизнеса
Nb5 2006
этого можно исключить формальное выполнение этапа анализа и сразу строить модель предметной области в варианте «как должно быть». Дальнейший процесс проектирования предусматривает несколько этапов. Каждый последующий этап характеризуется снижением уровня абстракции по сравнению с предыдущим. Для стадии проектирования можно выделить три таких уровня: концептуальный, логический и физический.
В некоторых источниках [2, 7] рассматривается еще один уровень — внешний. Этот уровень отражает работу с данными с точки зрения пользователя. Поскольку этот вопрос относится к стадии разработки прикладного программного обеспечения ИС, то здесь он не рассматривается.
Полученная в результате проработки каждого уровня приведенного перечня соответствующая модель должна быть представлена в виде схемы на основе использования той или иной выбранной нотации.
Рассмотрим некоторые методические проработки и соответствующий инструментарий, необходимые для выполнения каждого этапа проектирования специализированных ИС. Такое рассмотрение целесообразно начать с конца, т. е. с физической модели, так как при этом лучше проявляются цели, отвечающие задачам и характерные особенности каждого этапа.
Физическая модель реляционной базы данных отображается в виде набора взаимосвязанных таблиц, как правило, отвечающих требованиям третьей нормальной формы или форме Бойса-Кодда. Эта модель является последним шагом проектирования и ориентирована на реализацию в конкретной СУБД.
Методика и техническая сторона построения реляционной базы данных не имеет специфики, поэтому она подходит для ИС любого масштаба, достаточно хорошо формализована и проработана, что отражено во многих источниках, и не требует более детального рассмотрения в данной статье. Инструментарий построения физи-
ческой модели базы данных входит в состав ПО практически любой тиражируемой СУБД. Имеющиеся на рынке тиражируемые СУБД — Access, Fox Pro и другие — предоставляют неплохой инструментарий для формирования физической модели базы данных.
Физическая модель данных строится на основе более абстрактной модели, которая привязана не к конкретному программному обеспечению, а к данным. Эти данные должны быть отражены в виде некоторой схемы взаимосвязанных блоков, обозначающих сущности и их атрибуты. В разных источниках такая модель имеет название логической [4], инфологической [3], даталогиче-ской [6] и концептуальной [8].
В любом случае даталогическая модель ориентирована на так называемую ER-модель, иначе модель сущность-связь. Основным свойством такой модели является отражение совокупности всех сущностей и их атрибутов, описывающих предметную область и связи между сущностями. Для построения таких моделей используется инструментарий, позволяющий строить ER-диаграммы (ERD). Некоторые тиражные СУБД в составе своего ПО имеют специальный инструментарий, предназначенный для построения таких моделей, как, например, Power Designer в составе СУБД Sybase.
В некоторых источниках детальное рассмотрение процесса проектирования начинается с этого этапа. При этом предполагается, что анализ предметной области проведен и выявлены все описывающие ее сущности. Этот упрощенный подход при проектировании несложных ИС позволяет получить быстрый результат и часто используется прикладными программистами, но не профессиональными проектировщиками. Игнорирование предварительного подробного описания предметной области, часто приводит к серьезным потерям, если возникает необходимость развития системы (а такая необходимость возникает практически всегда). Известно, что ошибки в проектировании на ранних этапах обходятся
№>52006
существенно дороже, чем на последующих. Обычно основными ошибками являются неверная идентификация сущностей и атрибутов, непродуманный выбор ключевых сущностей и, как следствие, неправильное установление связей между ними. Определение набора сущностей и связи между ними, описывающих предметную область, для которой проектируется ИС, является ключевым моментом для построения базы данных.
Концептуальная модель должна обеспечить выявление необходимого и достаточного набора сущностей. Она не сводится к представлению только в виде некоторой схемы, но в данной статье мы будем рассматривать ее именно в таком понимании. Построение этой модели наиболее сложный и ответственный этап проектирования. Необходимо формализовать предметную область, а это творческий и неоднозначный процесс. Сложность его выполнения обусловлена большим разнообразием предметных областей, поэтому он не поддается строгой формализации. Актуальность решения подобных задач привела к разработке методологии SADT и набора стандартов под общим названием IDEF (Integrated DEFinition). Эта методология в последнее время получила широкое распространение. Она характеризуется достаточно хорошо проработанным инструментарием, например в AllFusion Process Мodeler.
Анализ и последующее проектирование на основе указанной методологии для крупных предприятий большая и трудоемкая работа, требующая выполнить множество итераций в течение достаточно продолжительного времени. Универсальность этой методологии обеспечила ей широкую популярность и сделала практически необходимым этапом разработки ИС. Целью этого этапа является получение строгой модели функциональной деятельности, полностью описывающей функции ИС в рамках сформулированных задач. В рассматриваемой методологии IDEF такая модель получила название TO-BE (как будет). Для специализированных
ИС предприятий малого и среднего бизнеса предлагается начинать проектирование с формирования этой модели.
Таким образом, проект может быть отражен в наборе моделей, начиная с концептуальной модели предметной области TO-BE и заканчивая физической моделью, лежащей в основе разрабатываемой ИС.
Особенности процесса проектирования специализированных ИС
Планируя разработку проекта необходимо оценить его трудоемкость, стоимость и продолжительность выполнения. Также надо оценить риск, т. е. неопределенность доведения проекта до конца. Если для крупных компаний риск приводит к дополнительным расходам и затягиванию сроков внедрения, то для малых — это вопрос существования. Чтобы снизить риск целесообразно провести предварительное обоснование оценки трудоемкости проекта. Он должен быть максимально проработан, в нем не должно быть отложенных на потом, разделов. Такой подход возможен, конечно же, только для некрупных проектов, так как он не предусматривает использование итеративного метода проектирования и ориентирован на линейный жизненный цикл. Немаловажным фактором, обеспечивающим эффективность ИС, является простота ее внедрения и эксплуатации.
Проектируя специализированные ИС необходимо учитывать следующие особенности:
• большое разнообразие специфик предметной области;
• возможность последующего расширения функций;
• жесткий бюджет;
• целостность и завершенность проекта, минимум риска;
• соблюдение заданного срока;
• исключение по возможности итераций;
• простота эксплуатации;
• минимум затрат на обучение пользователей.
N__7
Ю.В.Боковой
Особенности методологии проектирования информационных систем для малого и среднего бизнеса
№>52006
Выбор метода и особенности использования инструментария моделирования
Методология структурного моделирования имеет целый арсенал методов, применение которых зависит от конкретной специфики объекта моделирования. Наиболее широко применяются следующие методики:
• IDEF0 — функциональное моделирование, когда функции системы представлены независимо от объектов, которые их выполняют;
• IDEF1X — используется для инфологи-ческого проектирования баз данных;
• IDEF3 — используется для моделирования бизнес-процесса как упорядоченной последовательности событий;
• DFD (Data Flow Diagrams) — диаграммы потоков данных, моделируют систему как набор действий.
Эти методики позволяют визуализировать модель в виде диаграмм, имеют специфическую нотацию, и могут использоваться совместно для анализа и проектирования ИС.
Основной задачей информационной системы является информационное сопровождение функционирования компании, а функционирование не что иное, как некоторый набор последовательных действий. Для ИС любого масштаба принято, что начальная модель должна описывать функциональную деятельность предметной области. То есть должна быть построена функциональная модель в виде последовательности действий над материальными объектами как носителями и преобразователями информации, что может быть выполнено с помощью методики IDEF0.
В последующем при необходимости могут быть построены модели, отражающие потоки данных, последовательность процессов, организационную структуру и т. п. Методика и инструментарий применения методологии для всех видов систем достаточно подробно отражены в ряде источников [4, 8].
Формальный инструментарий указанных методик, однако не затрагивает конкретики предметных областей. Его применение эффективно, графический инструментарий по-
строения диаграмм хорошо проработан, но степень формализации не сводит процесс проектирования к простому выполнению некоторого набора операций, однозначно приводящих к положительному результату. Обратной стороной универсализма является расплывчатость и вариабельность в практическом использовании инструментария.
Основополагающий принцип построения модели предметной области — принцип последовательной декомпозиции при построении иерархии все более подробных и конкретных диаграмм, не должен нарушаться и при проектировании специализированных ИС.
Учитывая простоту и эффективность применения для проектирования специализированных ИС, ограничимся только использованием методики IDEF0. Инструментарий, позволяющий строить функциональную модель IDEF0, присутствует в составе многих программных продуктов, в том числе и графических, например MS Visio. Подходящим выбором для нашего случая является BPwin, входящий в состав программного продукта AllFusion Process Мodeler.
Сформулируем методические требования к проектированию специализированной ИС:
• методология — структурный метод;
• жизненный цикл процесса проектирования — линейный;
• используемая технология — IDEF0;
• используемый инструментарий — BPwin;
• используемая СУБД — одна из недорогих широко тиражируемых.
Рассмотрим более детально особенности использования имеющегося инструментария и уточним некоторые детали его нотации для моделирования специализированных ИС. Это позволит более формализовано, а значит с меньшими затратами сил, средств и времени, построить эффективную концептуальную модель.
Заложенная в BPwin нотация методики IDEF0 несколько ограничена для эффективного отражения предметной области рассматриваемой задачи, так как представлена только стрелками-дугами и прямоуголь-
№>52006
никами — функциональными блоками. В то же время имеется расплывчатость в отражении функционального назначения дуг на диаграммах IDEF0, поскольку одна дуга может отражать несколько сущностей, а разным атрибутам одной и той же сущности могут соответствовать разные дуги [4].
Чтобы обойти возникающие вследствие этого затруднения при построении модели специализированных ИС, предлагается соблюдать следующие правила:
• придать выходным дугам на диаграммах декомпозиции однозначное толкование как сущностям;
• заканчивать процесс декомпозиции только тогда, когда будет выполнено указанное требование;
• следить за тем, чтобы наименование выходной дуги являлось результатом выполнения функции, обозначенной в функциональном блоке, и точно его отражало.
Обратная связь и ее представление на диаграммах декомпозиции
Особую роль в информационных системах играет обратная связь. Ее значение имеет фундаментальный характер для всех систем управления и для ИС в частности. Роль обратной связи заключается в передаче информации (а иногда и материальных объектов как носителей информации) от объекта управления как части управляемой подсистемы, управляющему органу, который является частью управляющей подсистемы. В технических системах автоматического управления эта связь обеспечивается физическим образом, а в автоматизированных системах управления, в том числе и информационных, замыкание цепи обратной связи носит чисто информационный характер и происходит с участием человека, например, через реализацию функции управления лицом, принимающим решения.
В основополагающей для СДвЕ-техно-логий работе [5] предложено рассматривать в SADT-методологии два вида обратной связи — по управлению и по потоку данных. Принимая такой подход, уточним осо-
бенности представления этих видов обратной связи для нашего случая.
В любом случае цепь обратной связи может исходить из функционального блока, функцией которого является выбор альтернативы, т.е. принятие того или иного решения. Следовательно, такой блок должен иметь более одного выхода. Если функция такого блока имеет целью распределить поток некоторых материальных объектов по какому-либо признаку, например отбраковка деталей по признаку годен — не годен, то такой блок должен иметь дугу входа и дугу управления. При этом дуги входа и обоих выходов должны идентифицировать сущности. В данном случае блок выполняет функцию разделения пути передачи данных, в том числе и материального объекта, как по прямой, так и по обратной связи, т.е. с выхода одного функционального блока на вход другого. В качестве графического образа представления разветвления информационных потоков предлагается использовать ромб (который широко применяется при составлении блок-схем алгоритмов). BPwin в арсенале нотаций IDEF0 допускает возможность альтернативного представления для функциональных блоков, и для использования нетрадиционного представления функционального блока в виде ромба необходимо использовать опцию контекстного меню — Box Style.
В другом случае, т. е. если функция блока определена как принятие чисто информационного решения, выходы блока являются управляющими входами других блоков. Тогда рассматриваемый блок не должен иметь дуг функциональных входов и выходов, а только дуги, являющиеся управляющими для других функциональных блоков.
Известно, что любая схема действий может быть представлена тремя логическими элементами — «И», «ИЛИ», «НЕ». Но в инструментарии BPwin элемент «НЕ» отсутствует. Ограничения инструментария IDEF0 на эффективное представление обратных связей может быть преодолено, если при декомпозиции использовать нотацию инструментария IDEF3. Но все же в нашей постановке
Ю.В.Боковой
1Т-бизнес # Информационные системы бизнеса
\
*
си
I
О)
ПРИКЛАДНАЯ ИНФОРМАТИКА
№>52006
задачи и в этом случае для всех дуг подходящих и отходящих от функциональных блоков следует придерживаться правил, накладываемых методикой IDEF0. Для описания ветвления процесса предлагается использовать нотацию в виде разветвления исключающего «ИЛИ» — |х|. При этом все входящие и исходящие дуги должны соответствовать атрибутам, а не самим сущностям.
В моделях учетных ИС также может быть использована обратная связь, а для построения модели — указанная нотация.
Методические требования к построению концептуальной модели
Таким образом, с учетом изложенного можно подытожить требования, которым должна отвечать эффективная диаграмма декомпозиции:
• Каждая входная и выходная дуга функционального блока должна определять сущность.
• Блоки разделяются на только функциональные и функциональные с принятием решения.
• Название каждой дуги должно точно соответствовать выполнению функции, заявленной в названии функционального блока.
• Обратная связь всегда является результатом принятия решения и замыкающая ее дуга должна быть одним из выходов соответствующего функционального блока с принятием решения.
• Функциональный блок, выполняющий только операцию принятия решения, не должен иметь входной дуги (а только управляющую дугу), но должен иметь два выхода, один из которых должен замыкаться на вход предшествующего функционального блока (обратная связь).
• Если функциональный блок не содержит входных дуг, то дуга его выхода представляет атрибут, а не сущность.
• Если используется инструментарий BPwin, то диаграмму декомпозиции следует выполнять с помощью нотации IDEF3, но в соответствии с правилами IDEF0.
В качестве примера реализации этих требований рассмотрим модель TO-BE, описывающую работу сборочного цеха, выполненную с помощью BPwin (рис. 1). Наглядность диаграммы позволяет не приводить словесного описания задачи, тем более что она имеет модельный характер.
Для моделирования работы склада как поставщика комплектующих деталей и узлов номенклатура сущностей, отражающих хранимые и учитываемые материальные ценности, шире, но функционально работа проще (здесь не рассматривается).
На основе приведенной диаграммы декомпозиции можно выделить все сущности, характеризующие бизнес-процесс и некоторые атрибуты сущностей. Таким образом, построение инфологической модели на базе этих сущностей существенно облегчается. Формирование полного набора атрибутов для каждой сущности, применительно к данной задаче и с учетом требований бизнес-процесса, теперь является техническим вопросом и не представляет особых затруднений.
Литература
1. Буч Г. Объектно-ориентированный анализ и проектирование. М.: Бином, 1998.
2. Диго С. М. Базы данных: проектирование и использование. Учебник. М.: Финансы и статистика, 2005.
3. Карпова Т. Базы данных. СПб.: Питер, 2002.
4. Маклаков С. В. Создание информационных систем с AllFusion Modeling Suite. М.: Диалог-МИФИ, 2003.
5. Марка Д.А., МакГоунК. Методология структурного системного анализа и проектирования SADT / Пер. с англ. М.: Метатехнология, 1993.
6. Петров В.Н. Информационные системы. Учебник для вузов. СПб.: Питер, 2003.
7. Роб П., Коронел К. Системы баз данных: проектирование, реализация и управление. СПб.: «БХВ-Петербург», 2004.
8. ЧеремныхС.В., Семенов И.О., Ручкин B.C. Структурный анализ систем: IDEF-технологии. М.: Финансы и статистика, 2003.
Ю.В.Боковой
