Основы проектирования экономических информационных систем

Введение Эффективность применения экономических информационных систем (ЭИС) для управления экономическими объектами зависит от широты охвата и интегрированности на их основе функций управления, от способности оперативно подготавливать управленческие решения, адаптироваться к изменениям внешней среды и информационных потребностей. Усложнение архитектуры современных информационных систем предполагает разработку и использование эффективных технологий проектирования, обеспечивающих ускорение создания, внедрения и развития проектов ЭИС, повышение их функциональной и адаптивной надежности. В курсе лекций рассматриваются методы и средства проектирования экономических информационных систем, а также управления процессом проектирования. ЛЕКЦИЯ 1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ (ЭИС) ПОНЯТИЕ И КЛАССИФИКАЦИЯ ЭИС Методологическую основу проектирования ИС составляет системный подход, в соответствии с которым любая система представляет собой совокупность взаимосвязанных объектов (элементов), функционирующих совместно для достижения общей цели. Для системы характерно изменение состояний объектов, которое происходит с течением времени в результате взаимодействия объектов в различных процессах и с внешней средой. В результате такого поведения для системы характерно соблюдение следующих принципов: эмерджентности – целостности системы на основе общей структуры, когда поведение отдельных объектов рассматривается с позиции функционирования всей системы; гомеостазиса – обеспечение устойчивого функционирования системы и достижение цели; обучаемости путем изменения структуры системы в соответствии с изменением целей системы. В любой ЭС выделяют: систему управления; объект управления; информационные потоки (ИП), которые в свою очередь делятся: 1) ИП из системы управления во внешнюю среду; 2) ИП из внешней среды в систему управления; 3) прямую связь: плановая, нормативная информация; 4) обратную связь: учетная информация о состоянии объекта. ЭИС представляет собой совокупность организационных, технических, программных и информационных средств, объединенных в единую систему с целью сбора, хранения, обработки и выдачи необходимой информации, предназначенной для выполнения функций управления. ЭИС связывает объект и систему управления между собой и с внешней средой через информационные потоки. В соответствии с характером обработки информации в ЭИС на различных уровнях управления ЭС (оперативном, тактическом, стратегическом) выделяют следующие типы ИС: • системы обработки данных (EDP – Electronic Data Processing); • информационная система управления (MIS – Management Information System); • система поддержки принятия решений (DSS Decision Support System). Идеальной считается система, которая включает все три типа перечисленных ИС. В зависимости от охвата функций и уровней управления различают корпоративные (интегрированные) и локальные ЭИС. Корпоративная ЭИС автоматизирует все функции управления на всех уровнях управления. Такая ЭИС является многопользовательской, функционирует в распределенной вычислительной сети. .Локальная ЭИС автоматизирует отдельные функции управления на отдельных уровнях управления. Такая ЭИС может быть однопользовательской, функционирующей в отдельных подразделениях объекта управления. Рис. 1. Структура информационной системы В ЭИС выделяют функциональные и обеспечивающие подсистемы. Функциональные подсистемы ЭИС информационно обслуживают определенные виды деятельности ЭС (предприятия), характерные для подразделений предприятия. Интеграция функциональных подсистем в единую систему достигается за счет создания и функционирования обеспечивающих подсистем, таких как информационная, программная, математическая, техническая, технологическая, организационная и правовая подсистемы. Вопросы для самоконтроля 1. Назовите принципы системного подхода к созданию ЭИС? 2. Какова структура экономической системы? 3. Какие виды ЭИС существуют? 4. Как можно определить понятия «локальная» и «корпоративная» ЭИС? 5. Дайте определение функциональной и обеспечивающей подсистем. 6. Какие существуют принципы выделения функциональных подсистем? ЛЕКЦИЯ 2 МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ ЭИС. ТЕХНОЛОГИЯ ПРОЕКТИРОВАНИЯ ЭИС Современные ИТ предоставляют широкий набор способов реализации ЭИС, выбор которых может меняться в процессе разработки. Процесс проектирования ЭИС - это процесс принятия проектно–конструкторских решений, направленных на получение описания системы (проекта ЭИС), удовлетворяющего требованиям заказчика. Под проектом ЭИС понимают проектно–конструкторскую документацию, в которой представлено описание проектных решений по созданию и эксплуатации ЭИС в конкретной программно–технической среде. Под проектированием ЭИС понимается процесс преобразования входной информации об объекте проектирования, о методах проектирования и об опыте проектирования объектов аналогичного назначения в соответствии с ГОСТом. С этой точки зрения проектирование ЭИС сводится к последовательности формализации проектных решений на различных стадиях жизненного цикла ЭИС: планирования, анализа требований, технического рабочего проектирования, внедрения и эксплуатации ЭИС. Объектами проектирования ЭИС являются отдельные элементы функциональных и обеспечивающих частей или их комплексы. Так, функциональными элементами в соответствии с традиционной декомпозицией выступают задачи, комплексы задач и функции управления. В составе обеспечивающей части ЭИС объектами проектирования служат элементы или их комплексы информационного, программного и технического обеспечения ИС. Субъектами проектирования ЭИС выступают коллективы специалистов, которые выполняют проектную деятельность. Форма участия соисполнителей в разработке проекта системы может быть различной. Наиболее распространенной является форма, при которой каждый исполнитель выполняет проектные работы от начала и до конца для какой–либо части разрабатываемой системы. Обычно это функциональные подсистемы или взаимосвязанный комплекс задач. Реже встречается форма участия, при которой отдельные соисполнители выполняют работы на отдельных этапах процесса проектирования. Возможен вариант, при котором функции заказчика и разработчика совмещаются (ЭИС проектируется собственными силами). Осуществление проектирования ЭИС предполагает использование проектировщиками определенной технологии проектирования, соответствующей масштабу и особенностям разрабатываемого проекта. Технология проектирования ЭИС - это совокупность методологии и средств проектирования ЭИС, а также методов и средств организации проектирования. В основе технологии проектирования лежит технологический процесс, который определяет действия, их последовательность, состав исполнителей, средства и ресурсы, необходимые для выполнения этих действий. Все действия могут быть: • собственно проектировочными – формируют и модифицируют результаты проектирования; • оценочными – вырабатывают по установленным критериям оценки результатов проектирования. Технология проектирования задается последовательностью технологических операций, выполняемых в процессе создания проекта на основе того ли иного метода. К основным требованиям, предъявляемым к выбираемой технологии проектирования, относятся следующие: • созданный с помощью этой технологии проект должен отвечать требованиям заказчика; • выбранная технология должна максимально отражать все этапы жизненного цикла проекта; • выбираемая технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта; • технология должна обеспечивать надежность процесса проектирования и эксплуатации проекта; • технология должна способствовать росту производительности труда проектировщика; • технология должна способствовать простому ведению документации. Основу методологии проектирования ЭИС составляет методология, которая определяет сущность, основные отличительные технологические особенности. Методология проектирования предполагает наличие некоторой концепции, принципов проектирования, которые, в свою очередь, должны поддерживаться некоторыми средствами проектирования. Организация проектирования предполагает определение методов взаимодействия проектировщиков между собой и с заказчиком в процессе создания проекта ЭИС. Методы проектирования ЭИС можно классифицировать следующим образом: 1. По степени использования средств автоматизации: 1) методы ручного проектирования – проектирование компонентов ЭИС осуществляется без использования специальных инструментальных программных средств, а программирование – на алгоритмических языках; 2) методы компьютерного проектирования – генерация или конфигурация (настройка) проектных решений производится на основе использования специальных инструментальных программных средств; 2. По степени использования типовых проектных решений: 1) оригинальное (индивидуальное) проектирование - проектные решения разрабатываются «с нуля» в соответствии с требованиями к ЭИС; 2) типовое проектирование – конфигурация ЭИС из готовых типовых проектных решений (программных модулей). Оригинальное проектирование - характеризуется тем, что все виды проектных работ ориентированы на создание индивидуальных для каждого объекта проектов, которые в максимальной степени отражают все особенности объекта. Типовое проектирование выполняется на основе опыта, полученного при разработке индивидуальных проектов. 3. По степени адаптивности к предполагаемым изменениям: 1) методы реконструкции – адаптация проектных решений выполняется путем переработки соответствующих компонентов (перепрограммирование программных модулей); 2) методы параметризации – проектные решения настраиваются в соответствии с изменяемыми параметрами; 3) методы реструктуризации – изменяется модель проблемной области, на основе которой автоматически перегенерируются проектные решения. Сочетание различных признаков классификации методов проектирования обусловливает характер используемой технологии проектирования ЭИС, среди которых выделяются два основных класса: каноническая и индустриальная технологии. Индустриальная технология, в свою очередь, разбивается на два подкласса: автоматизированное (использование CASE – технологий) и типовое (параметрически – ориентированное или модельно - ориентированное) проектирование. Использование индустриальных технологий не исключает использования в отдельных случаях канонической технологии. Для конкретных видов технологий проектирования свойственно применение определенных средств разработки ЭИС, которые поддерживают выполнение как отдельных проектных работ, этапов, так и их совокупностей. Поэтому перед разработчиками ЭИС, как правило, стоит задача выбора средств проектирования, которые по своим характеристикам в наибольшей степени соответствуют требованиям конкретного предприятия. Средства проектирования должны быть: • в своем классе инвариантными к объекту проектирования; • охватывать в совокупности все этапы жизненного цикла ЭИС; • технически, программно и информационно совместимыми; • простыми в освоении и применении; • экономически целесообразными. Средства проектирования ЭИС можно разделить на два класса: с использованием ЭВМ и без использования ЭВМ. Средства проектирования без использования ЭВМ применяются на всех стадиях и этапах проектирования ЭИС. Как правило, это средства организационно–методического обеспечения операций проектирования и в первую очередь различные стандарты, регламентирующие процесс проектирования систем. Сюда же относятся единая система классификации и кодирования информации, унифицированная система документации, модели описания и анализа потоков информации. Средства проектирования с использованием ЭВМ могут применяться как на отдельных, так и на всех стадиях и этапах проектирования ЭИС и соответственно поддерживают разработку элементов проекта системы, разделов проекта системы, проекта системы в целом. Средства проектирования с использованием ЭВМ делят на четыре подкласса. К первому подклассу относятся операционные средства, которые поддерживают проектирование операций обработки информации. К данному подклассу средств относятся: • алгоритмические языки, • библиотеки стандартных подпрограмм и классов объектов, • генераторы программ типовых операций обработки данных, • средства расширения функций операционных систем (утилиты). В данный класс также включаются такие простейшие инструментальные средства проектирования, как средства для тестирования и отладки программ, поддержки процесса документирования проекта. Особенность последних программ заключается в том, что с их помощью повышается производительность труда проектировщиков, но не разрабатывается законченное проектное решение. Средства данного подкласса поддерживают отдельные операции проектирования и могут применяться независимо друг от друга. Ко второму подклассу относятся средства, поддерживающие проектирование отдельных компонентов проекта системы. К данному подклассу относятся средства общесистемного назначения: • СУБД; • методоориентированные пакеты ПП (решение задач дискретного программирования, математической статистики); • табличные, текстовые, графические процессоры; • статистические ППП; • оболочки ЭС; • интегрированные ППП. Для перечисленных средств характерно их использования для разработки технологических подсистем ЭИС: ввода информации, организации хранения и доступа к данным, вычислений, анализа и отображения данных, принятия решений. К третьему подклассу относятся средства, поддерживающие проектирование разделов проекта ЭИС. В этом подклассе выделяют функциональные средства проектирования (ФСП). ФСП направлены на разработку автоматизированных систем, реализующих функции, комплексы задач и задачи управления. К ФСП систем обработки информации относятся типовые проектные решения, функциональные ППП, типовые проекты. К четвертому подклассу средств проектирования относятся средства, поддерживающие разработку проекта на стадиях и этапах процесса проектирования ЭИС (CASE – средства). Современные CASE – средства, в свою очередь, классифицируются по двум признакам: • по охватываемым этапам процесса разработки ЭИС; • по степени интегрированности: ◦ отдельные локальные средства (tools); ◦ набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС (toolkit); ◦ полностью интегрированные средства, связанные с общей базой проектных данных – репозиторием (workbench). ФОРМАЛИЗАЦИЯ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ ЭИС Основой формализации технологии проектирования ЭИС является формальное определение технологической операции (ТО) проектирования в виде четверки: • V – вход; • W – выход; • П – преоразователь; • R – ресурсы; • S – средства. Технологические операции графически представляются в виде блоков-прямоугольников, внутри которых дается наименование ТО, перечень используемых средств и ссылки на используемые ресурсы. Вход и выход ТО представляются идентификаторами внутри кружков, от которых и к которым идут стрелки, указывающие входные и выходные потоки. В качестве компонентов входа и выхода используются документы, параметры, программы, универсальные множества – универсумы. Для любых компонентов входа и выхода должны быть заданы формы их представления в виде твердых копий или в электронном варианте. Документ (D) – это описатель множества взаимосвязанных факторов. Документы определяют исходные, результирующие и промежуточные результаты проектирования и внедрения ЭИС. Параметр (P) – это описатель одного факта. Параметр рассматривается как частный случай документа. Параметры, как правило, выступают в роли ограничений или условий процесса проектирования. Программа (G) – частный случай документа, представляющего описание алгоритма решения задачи: от спецификации программы до машинного кода. Универсум (U) – это конечное и полное множество фактов (документов) одного типа. Обычно с помощью универсума описывается множество альтернатив, выбор из которого конкретного экземпляра определяет характер дальнейших проектных решений. В качестве универсумов могут рассматриваться описания технических, программных средств, технологий проектирования. Преобразователь (П) – это некоторая методика или формализованный алгоритм, или машинный алгоритм преобразования входа ТО в ее выход. Для формализации преобразователей используются математические модели, эвристические правила, блок-схемы, псевдокоды. Ресурсы (R) - набор людских, компьютерных, временных и финансовых средств, которые позволяют выполнить ТО. Средства проектирования (S) – это специальный вид ресурса, включающий методические и программные средства выполнения ТО. Если преобразователь является ручным, то средство проектирования представляет методику выполнения работы, и в описании ТО дается ссылка на соответствующий бумажный или электронный документ. Если преобразователь является автоматическим или автоматизированным, в описании ТО указывается ссылка на название и описание программного средства, а также руководство по эксплуатации. На основе ТО строится технологическая сеть проектирования (ТСП), под которой понимается взаимосвязанная по входам и выходам последовательность ТО проектирования, выполнение которых приводит к достижению требуемого результата – созданию проекта. ТСП могут строится с различной степенью детализации. Наиболее детализированная ТСП, в которой каждая ТО является ручной, называется канонической. Каноническая ТСП наиболее пригодна для проектировщиков – исполнителей, для которых ТСП является руководством к проектированию. Для укрупнения ТСП применяются технологические операции – агрегаты, которым соответствуют фрагменты канонической ТСП. Вопросы для самоконтроля 1. Что включает в себя технология проектирования ЭИС? 2. Что такое технологический процесс проектирования ЭИС? 3. Как классифицируются методы проектирования ЭИС? 4. Что понимается под организацией проектирования ЭИС? 5. Перечислите признаки, характеризующие каноническое, автоматизированное, типовое проектирование. 6. Какие существуют модели жизненного цикла ЭИС? 7. Как строится технологическая сеть проектирования ЭИС? ЛЕКЦИЯ 3 КАНОНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ. СТАДИИ И ЭТАПЫ КАНОНИЧЕСКОГО ПРОЕКТИРОВАНИЯ ЭИС Каноническое проектирование ЭИС отражает особенности ручной технологии индивидуального (оригинального) проектирования без использования каких – либо инструментальных средств. В основе канонического проектирования лежит каскадная модель жизненного цикла ЭИС. Процесс каскадного проектирования в соответствии с ГОСТ 34601-90 «Автоматизированные системы стадий создания» делится на семь стадий: 1. Исследование и обоснование создания системы. 2. Разработка ТЗ. 3. Создание эскизного проекта. 4. Техническое проектирование. 5. Рабочее проектирование. 6. Ввод в действие. 7. Функционирование, сопровождение, модернизация. Эти стадии можно сгруппировать в часто используемые на практике четыре стадии процесса разработки ЭИС: 1) предпроектная стадия; 2) стадия проектирования; 3) стадия внедрения; 4) стадия эксплуатации и сопровождения. СОСТАВ И СОДЕРЖАНИЕ РАБОТ НА ПРЕДПРОЕКТНОЙ СТАДИИ СОЗДАНИЯ ЭИС При каноническом проектировании основной единицей обработки данных является задача. Поэтому функциональная структура проблемной области изучается в разрезе решаемых задач и комплексов задач. При этом задача рассматривается как совокупность операций преобразования некоторого набора исходных данных для получения результатной информации. В большинстве случаев исходные данные и результаты представляются в форме экономических документов. На предпроектной стадии выделяют два этапа: I. Сбор материалов обследования; II. Анализ материалов обследования и разработка технико-экономического обоснования (ТЭО) и технического задания (ТЗ). В результате выполнения первого этапа получают материалы обследования, которые должны содержать полную и достоверную информацию о предметной области. После выполнения второго этапа получают количественные и качественные характеристики информационных потоков, описание их структуры и мест обработки, трудоемкость их обработки. На основе этих материалов разрабатываются два документа: ТЭО проектных решений, содержащее расчеты и обоснование необходимости разработки ЭИС и выбираемых технологических проектных решений, и ТЗ, в состав которого входят требования к создаваемой системе и ее отдельным компонентам: программному, техническому, информационному обеспечению. Основной целью I этапа Сбора материалов обследования является: • выявление основных параметров предметной области; • установление условий функционирования проект ЭИС; • выявление стоимостных и временных ограничений проектирования. На этом этапе решаются следующие задачи: предварительное изучение предметной области; выбор технологии проектирования; выбор метода проведения обследования; выбор метода сбора материалов обследования; разработка программы обследования; разработка плана-графика сбора материалов; сбор и формализация материалов обследования. Обследование проводится в трех направлениях. Первое направление обследования предусматривает получение представления об объекте изучения в целом, включая выяснение целей функционирования этой системы, выявление значений основных параметров деятельности предприятия. Второе направление обследования предусматривает изучение и описание организационно – функциональной структуры объекта. При этом изучаются функции, выполняемые в структурных подразделениях, хозяйственные процессы и процедуры, выявляются комплексы задач, обусловленные выполняемыми функциями, определяется состав входной и выходной информации. Третье направление предусматривает изучение и описание структуры информационных и (или) материальных потоков, частоты их возникновения, объемов за определенный период, направления движения потоков, процедур обработки, в которых участвуют эти компоненты. Описание информационной структуры выполняется на уровне экономических документов и показателей. Для организации труда проектировщиков во время сбора материалов обследования и его анализа необходима разработка «Плана–графика выполнения работ на предпроектной стадии». «План–график» служит инструментом планирования и оперативного управления выполнением работ на предпроектной стадии. Последней операцией на этом этапе является Проведение сбора и формализации материалов обследования, в процессе которого необходимо собрать сведения о методах и алгоритмах реализации функций, составе обрабатываемых и рассчитываемых показателей; собрать формы документов, отражающих хозяйственные процессы и используемые классификаторы, макеты файлов, проконтролировать вместе с пользователем их правильность, сформировать Отчет об обследовании. Сбор материалов проводят с помощью документов, которые удобно читать и обрабатывать. Рис. 2. Формы документов для формализации материалов обследования На основе формализованного описания предметной области выполняется этап Анализа материалов обследования, целью которого являются: • сопоставление всей собранной информации с теми требованиям, которые предъявляются к объекту, определение недостатков функционирования объекта; • выработка основных направлений совершенствования работы объекта обследования на базе внедрения проекта ЭИС, выбор инструментария и оценка эффективности применения данного инструментария; • обоснование выбора решений по основным компонентам проекта ЭИС и определение общесистемных, функциональных, локальных требований к будущему проекту и его частям. Данный этап предполагает выполнение следующих операций: 1. Анализ и определение состава объектов автоматизации. 2. Анализ и определение состава задач в автоматизируемом объекте. 3. Анализ и предварительный выбор комплекса технических средств. 4. Анализ и предварительный выбор типа ОС. 5. Выбор способа организации информационной базы (ИБ) и программного средства ведения ИБ. 6. Выбор средства проектирования ПО системы. 7. Разработка ТЭО и ТЗ. Анализ материалов обследования позволяет проектировщику выделить и составить список автоматизируемых подразделений. При выявлении списка автоматизируемых задач, для которых необходимо разработать проекты, должны учитываться следующие факторы: • важность решения задачи для объекта; • трудоемкость и стоимость расчета основных показателей задачи; • информационная связь рассматриваемой задачи с другими задачами; • недостаточная оперативность расчета показателей; • низкая достоверность получаемых данных; • недостаточное количество аналитических показателей, получаемых на базе первичных документов. Кроме этого осуществляется выявление очередей проектирования решаемых задач. К задачам первой очереди относят самые трудоемкие задачи и задачи, обеспечивающие информацией все остальные задачи. Далее выбирается комплекс технических средств с учетом факторов, которые можно объединить в группы. 1. Факторы, связанные с параметрами входных информационных потоков: объем информации, тип носителя информации, характер представления информации. 2. Факторы, определяемые техническими характеристиками ЭВМ: производительность процессора, емкость оперативной памяти, поддерживаемая операционная система, возможность подключения других устройств. 3. Факторы, зависящие от характера решаемых на ЭВМ задач и их алгоритмов: срочность решения, возможность подразделения задачи на подзадачи, количество файлов с условно – постоянной информацией. 4. Факторы, относящиеся к эксплутационным характеристикам ЭВМ: требуемые условия эксплуатации, необходимый штат обслуживания, его квалификация. 5. Факторы, учитывающие стоимостные оценки затрат на приобретение, на содержание персонала, на проведение ремонтных работ. При выборе типа ОС учитывают необходимое число поддерживаемых программных продуктов; требования к аппаратным средствам; возможность использования различных устройств ввода – вывода; требования поддержки сетевой технологии; простоту использования, быстродействие, совместимость с другими ОС. При выборе способа организации ИБ возможен способ организации в виде совокупности локальных файлов либо в виде баз данных. Программные средства выбирают, исходя из класса систем хранения данных: системы управления файлами либо системы управления базами данных. Выбор методов и средств проектирования напрямую зависит от выбранной технологии проектирования: структурное проектирование, модульное проектирование и другие. Основными факторами, влияющими на выбор методов является их совместимость, сокращение времени и стоимостных затрат на проектирование, получение качественного продукта. Этап завершается составлением ТЭО и формированием ТЗ. К основным компонентам ТЭО относятся: • характеристика исходных данных; • обоснование цели создания ЭИС; • обоснование автоматизируемых подразделений, комплекса автоматизируемых задач, выбора комплекса технических средств; • разработка перечня организационно–технических мероприятий по проектированию ЭИС; • вывод о техническом уровне проекта и возможности дальнейших разработок. На основе ТЭО составляется Техническое задание согласно ГОСТ 34.602-89 «ТЗ на создание автоматизированной системы». Основные разделы ГОСТ были рассмотрены в курсе «Разработка и стандартизация программного обеспечения». СОСТАВ И СОДЕРЖАНИЕ РАБОТ НА СТАДИИ ТЕХНО-РАБОЧЕГО ПРОЕКТИРОВАНИЯ Работы на стадии «Техно-рабочего проектирования» выполняются на основе утвержденного «ТЗ». Разрабатываются основные положения проектируемой системы, принципы ее функционирования и взаимодействия с другими системами; определяется структура системы; разрабатываются проектные решения по обеспечивающим частям системы. На этой стадии выполняются два этапа работ: техническое и рабочее проектирование. На этапе технического проектирования выполняется логическая проработка функциональной и системной архитектуры ЭИС, в процессе которой строится несколько вариантов всех компонентов системы; проводится оценка вариантов по стоимости, трудоемкости, достоверности получаемых результатов. На этом этапе выполняются операции. 1. Разработка основных положений по новой системе. 2. Изменение организационной структуры. 3. Разработка функциональной структуры и перечня задач. 4. Разработка принципов организации ИО и внутримашинной ИБ. 5. Разработка постановки подзадач для подсистем. 6. Разработка форм документов и системы их ведения. 7. Разработка классификаторов и кодов. 8. Разработка структуры входных и выходных сообщений. 9. Разработка макетов и структур файлов. 10. Разработка внемашинной и внутримашинной технологии решения каждой задачи. 11. Уточнение состав периферийной техники. 12. Уточнение состава аппаратной платформы проекта. 13. Разработка проектно – сметной документации. 14. Расчет экономической эффективности ЭИС. 15. Разработка плана мероприятий по подготовке к внедрению системы. 16. Окончательное оформление проекта. Все работы первого этапа можно разбить на две группы. К первой группе относится разработка общесистемных проектных решений (пункты 1-3, 13-15). Ко второй группе работ относятся разработки локальных проектных решений (пункты 4-12). Основным компонентом локальных проектных решений является Постановка задачи. Этот документ содержит три составные части: • характеристику задачи; • описание входной информации; • описание выходной информации. Рис. 3. Постановка задачи Под целью автоматизации решения задачи подразумевается получение определенных значений экономического эффекта, снижение затрат на обработку информации, получение косвенного и прямого эффекта от внедрения данной задачи. Под экономической сущностью решаемой задачи понимаются состав экономических показателей, рассчитываемых при ее решении, документы, в которые заносятся эти показатели, перечень исходных показателей, необходимых для получения результат и состав первичных документов, в которых они содержатся. Организационная сущность задачи – это описание порядка решения задачи; режима решения; способа получения и ввода первичной информации; формы вывода результата. Описание алгоритма включает формализованное описание входных и результатных данных, перечень формул расчета или описание математической модели. Результатом работ на данной стадии является утвержденный «Технический проект», состав и содержание которого регламентируются стандартом (ГОСТ 34.201-89). На этапе рабочего проектирования осуществляется техническая реализация выбранных наилучших вариантов и разрабатывается документация рабочего проекта. В состав выполняемых работ входят: 1) разработка программного обеспечения задач для подсистем. 2) разработка технологических документов и инструкций. 3) разработка правовых документов. 4) оформление рабочего проекта. Наиболее ответственной работой на этом этапе является кодирование и составление программной документации (пункт 1). В ее состав входят следующие компоненты: • описание программы; • тексты программ; • контрольные примеры; • инструкции для системного программиста, оператора и пользователя. Технологическая документация разрабатывается в соответствии с требованиями ГОСТ 3.11.09-82 «Система технологической документации. Термины и определения основных понятий». СОСТАВ И СОДЕРЖАНИЕ РАБОТ НА СТАДИЯХ ВНЕДРЕНИЯ, ЭКСПЛУАТАЦИИ И СОПРОВОЖДЕНИЯ ПРОЕКТА На стадии внедрения проекта проводятся подготовка и постепенное освоение разработанной проектной документации ЭИС заказчиками системы. В процессе выполнения работ на этой стадии выявляются недоработки в проектном решении. Внедрение может осуществляться с использованием следующих методов: • последовательный метод, когда последовательно внедряется одна подсистема за другой, и одна задача следует за другой задачей; • параллельный метод, при котором все задачи внедряются во всех подсистемах одновременно; • смешанный подход, согласно которому проектировщики, внедрив несколько подсистем первым методом, приступают к параллельному внедрению системы. Недостатком первого подхода является увеличение длительности внедрения, что ведет за собой рост стоимости проекта. При использовании второго подхода сокращается время внедрения, но возникает возможность пропуска ошибок в проектной документации, поэтому чаще всего используют смешанный метод внедрения проекта ЭИС. Внедрение проекта осуществляется в три этапа: подготовка объекта к внедрению; опытное внедрение; сдача проекта в промышленную эксплуатацию. На этапе подготовки объекта к внедрению осуществляются следующие операции: • изменяется организационная структура объекта (предприятия); • набираются кадры соответствующей квалификации в области обработки информации и эксплуатации системы и сопровождения проектной документации; • оборудуется здание под установку вычислительной техники; • выполняются закупка и установка вычислительной техники; • в цехах, отделах устанавливаются средства сбора, регистрации первичной информации и передачи по каналам связи; • осуществляется установка каналов связи; проводится разработка новых документов и классификаторов; • осуществляется создание файлов информационной базы с нормативно-справочной информацией. На вход этого этапа поступают компоненты «Технического проекта» в части плана мероприятий по внедрению, решения по техническому и информационному обеспечению, технологические и инструкционные материалы «Рабочего проекта». В результате выполнения этапа составляется акт готовности объекта к внедрению проекта ЭИС. Затем формируется состав приемной комиссии, разрабатывается Программа проведения опытного внедрения и издается приказ о начале опытного внедрения. Второй этап - опытное внедрение. На этом этапе внедряются проекты нескольких задач в нескольких подсистемах. В процессе опытного внедрения выполняются следующие работы: • подготовка исходных оперативных данных для задач, кото­рые проходят опытную эксплуатацию; • ввод исходных данных в ЭВМ и выполнение запланированного числа реализаций; • анализ результатных данных на предмет наличия ошибок. В случае обнаружения ошибок осуществляются поиск причин и источников ошибок, внесение коррективов в программы, в технологию обработки информации, в работу технических средств, в исходные оперативные данные и в файлы с условно-постоянной информацией. Кроме того, выявляется неквалифицированная работа операторов, что служит основанием для проведения комплекса мер по улучшению подготовки кадров. После устранения ошибок получают Акт о проведении опытного внедрения, который служит сигналом для начала следующего этапа. На третьем этапе сдаче проекта в промышленную эксплуатацию используют следующую совокупность документов: • договорная документация; • приказ на разработку ЭИС; ТЭО и ТЗ; • исправленный «Техно-рабочий проект»; • приказ о начале промышленного внедрения; • программа проведения испытаний; • требования к научно-техническому уровню проекта системы. Вопросы для самоконтроля 1. Что такое каноническое проектирование и каковы особенности его содержания? 2. Перечислите этапы проектирования ЭИС. 3. Перечислите факторы отбора объектов для проведения автоматизации работ и выбора состава автоматизируемых задач? 4. Каковы назначение и состав разделов технико-экономического обоснования? 5. Каковы назначение и содержание документа «Техническое задание»? 6. Каков состав компонентов этого документа «Постановка задачи»? 7. Каковы факторы выбора способов организации хранения данных в информационной базе и типов СУБД? 8. Каковы назначение и состав операций стадии «техно-рабочее проектирование»? ЛЕКЦИЯ 4 ПРОЕКТИРОВАНИЕ КЛАССИФИКАТОРОВ ТЕХНИКО-ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИИ ОСНОВНЫЕ ПОНЯТИЯ КЛАССИФИКАЦИИ ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИИ Экономическая информация, как один из ресурсов предприятия, имеет следующие особенности: • большие объемы ежегодно создаваемой, обрабатываемой и хранимой информации; • символьное представление информации, слабо приспособленное для логической и арифметической обработки; • высокая стоимость затрат на поиск и обработку информации. Для того чтобы приспособить экономическую информацию для эффективной обработки, ее сначала классифицируют (упорядочивают), а затем формализуют (кодируют) с помощью классификаторов. Классификатор – это документ, с помощью которого осуществляется формализованное описание экономической информации в ЭИС, содержащий наименования объектов, наименования классификационных группировок и их кодовые обозначения. Экономическая информация существует в двух формах: в виде документов и в форме экономических показателей. Экономический показатель является составной единицей информации, отражающей характеристику некоторого процесса предметной области в виде реквизитов – признаков и реквизитов – оснований. Реквизиты–основания подразделяются по типу алгоритмов их получения на количественные, стоимостные, проценты и другие. Реквизиты – признакы по степени формализации делится на два подмножества: • справочные реквизиты–признаки - наименования, предназначенные для понимания показателя пользователем – экономистом; • группировочные реквизиты–признаки – закодированные аналоги справочных признаков для логической обработки информации на ЭВМ. Рис. 4. Структура экономических показателей. Основными объектами классификации и кодирования являются справочные реквизиты-признаки, описывающие процессы, место, время выполнения процессов, субъекты и объекты действий, наименования показателей, документов. Целью разработки классификаторов является установление соответствия между значениями справочных и описательных признаков какого–либо элемента или процесса и значениями группировочных признаков (например, между значением реквизита Фамилия и значением Табельный номер). Для кодирования объектов их необходимо упорядочить по некоторым признакам. Результат упорядоченного распределения объектов заданного множества носит название классификации, а совокупность правил распределения объектов – системой классификации. Множество, объединяющее часть объектов классификации по одному или нескольким признакам, носит название классификационной группировки. Основанием классификации называется признак, по которому ведется разбиение на определенной ступени классификации. Ступень классификации – это результат очередного распределения объектов классификационной группировки. Уровень классификации – это совокупность классификационных группировок, расположенных на одних и тех же ступенях классификации. Глубина системы классификации – это количество уровней классификации, допустимое в данной системе. Каждая система классификация характеризуется гибкостью, емкостью и степенью заполненности системы. Гибкость системы – это способность допускать включение новых признаков, объектов без нарушения структуры классификатора Гибкость системы определяется временем жизни системы. Емкость системы – это наибольшее количество классификационных группировок, допускаемое в данной системе классификации (Р). Степень заполненности системы (Кзап) определяется как частное от деления фактического количества группировок (Qф) на величину емкости системы (Р): Кзап=Qф/Р. В настоящее время чаще всего применяются два типа систем классификации: иерархическая и многоаспектная, которые были рассмотрены в курсе «Информатика». КОДИРОВАНИЕ ИНФОРМАЦИИ Для полной формализации экономической информации проводят процедуру кодирования. Кодирование – это процесс присвоения условных обозначений объектам и классификационным группам по соответствующей системе кодирования. Система кодирования – это совокупность правил обозначения объектов и группировок с использованием кодов. Код – это условное обозначение объектов или группировок в виде знака или группы знаков в соответствии с принятой системой. Код базируется на алфавите. Число знаков алфавита называется основанием кода. Различают цифровой, буквенный и смешанный алфавиты. Код характеризуется следующими параметрами: • длиной (L); • основанием кодирования (А); • структурой кода, под которой понимают распределение знаков по признакам и объектам классификации; • степенью информативности (I), вычисляемой как частное от деления общего количества признаков (R) на длину кода: I=R/L; • коэффициентом избыточности (Кизб), который определяется как отношение максимального количества объектов (Qmax) к фактическому количеству объектов (Qфакт): Кизб=Qmax/Qфакт. Все системы кодирования можно сгруппировать в два подмножества: регистрационные и классификационные. Они были рассмотрены в курсе «Информатика». ПРОЕКТИРОВАНИЕ КЛАССИФИКАТОРОВ Все классификаторы имеют эталонную и рабочую формы. Эталонная форма классификатора – это официальное издание классификатора на бумажном носителе, удобное для его ведения. Рабочая форма – весь классификатор или его раздел, занесенный на машинный носитель и удобный для обработки информации. Весь процесс разработки классификатора разбивают на четыре этапа. На первом этапе выполняются две работы. 1. На основе анализа реквизитного состава первичных и результатных документов и выделения всей совокупности реквизитов-признаков определяется перечень классификаторов. Далее определяют назначение классификатора (однозначная идентификация объекта, поиск, логическая обработка первичной информации). 2. Определяются требования к классификатору и определяется состав исходных данных. К исходным данным при проектировании классификатора относят: • состав задач, для которых разрабатывается классификатор; • состав объектов классификации и мощность исходного множества; • состав признаков классификации и число значений каждого признака; • наименования отдельных группировок и объектов. К требованиям, которым должен удовлетворять классификатор относят: • полноту охвата объектов и признаков классификации каждым классификатором; • согласованность признаков деления множеств объектов с алгоритмами обработки экономической информации; • взаимную однозначность наименований объектов и их кодовых обозначений; • простоту кодирования и возможность автоматизации классификации и кодирования; • возможность увязки с другими классификаторами; • эффективность использования классификатора при обработке информации. Содержанием второго этапа является разработка основных критериев и принципов построения каждого классификатора. К критериям построения классификатора относят: • критерий отнесения того или иного объекта к конкретному классификационному множеству; • степень охвата кодируемого множества объектов. Принципы построения определяются структурой классификатора, т.е. количеством ветвей, выходящих из каждой классификационной группировки, количеством ступеней и числом уровней классификации. Классификатор считается однородным, если на каждой ступени из каждой классификационной группировки выходит одинаковое число ветвей. Кроме того, на этом этапе разрабатывается система взаимодействия классификаторов разных уровней, предназначенных обеспечивать взаимодействие ЭИС с внешней средой. Эта работа представляет собой разработку некоторого транслятора перехода от одного классификатора к другому. Но для его создания необходимо выбрать систему взаимодействия различных классификаторов. Существуют следующие системы взаимодействия. Система равноправных классификаторов – на каждом уровне управления используется свой локальный классификатор, а для получения или передачи информации из внешней среды используется соответствующий транслятор. Недостаток данной системы заключается в том, что та система, которая имеет на входе наибольшее количество потоков информации от различных источников, должна иметь наибольшее количество трансляторов. Система приоритетных классификаторов – применяется для предприятий одной отрасли. При этом на каждом предприятии и на каждом уровне управления имеются локальные классификаторы. Обмен информацией осуществляется в терминах классификатора вышестоящего уровня. Недостаток: возникают трудности при передаче потоков информации между предприятиями разных отраслей. Система классификаторов-посредников – применяется при межотраслевом управлении. На каждом объекте любого уровня управления обработка ведется в терминах локального классификатора, а обмен – в терминах одного классификатора-посредника. Преимущества такой системы заключаются в необходимости создания только одного транслятора для каждого предприятия и в обеспечении возможности централизованного ведения классификатора – посредника. На этом же этапе выполняется разработка методик построения классификаторов, отражающих методы и последовательность выполнения отдельных операций по созданию классификаторов. Третий этап связан с работами по организации сбора и обработки исходных данных, необходимых для составления классификаторов. К их числу относятся: • разработка инструктивных материалов по сбору и обработке исходных данных: • определение решаемых задач, использующих классификаторы; • выделение классифицируемых объектов; • определение состава признаков классификации и значений признаков; • согласование используемой терминологии данных с ГОСТами; • сбор и обработка данных согласно инструкциям. Определение состава, назначения и сферы действия классификатора Этап 1 Определение состава исходных данных и требований к классификатору Разработка ТЗ на проектирование Разработка основных принципов построения классификатора Этап 2 Разработка методики построения классификатора Разработка методических материалов проектирования Разработка инструктивных материалов по сбору и обработке данных Этап 3 Сбор и обработка данных Организация сбора и обработки исходных данных Построение эталонной и рабочей формы классификатора и системы ведения Этап 4 Экспериментальная проверка и внесение коррективов Составление классификатора и системы его ведения Утверждение и издание классификатора Рис. 5. Процесс разработки классификаторов На четвертом этапе выполняется построение эталонной и рабочей форм классификатора. Эталонный классификатор должен быть согласован, отпечатан типографским способом и распространен всем пользователям для кодирования информации первичных документов. Рабочие классификаторы наносятся на машинные носители в необходимых разрезах, передаются пользователям и заносятся в файлы справочников баз данных для автоматического заполнения машинных форм первичных документов и для декодирования результатной информации. Система ведения классификаторов подразумевает актуализацию классификатора, постоянное пополнение и изменение объектов классификации, пересмотр структуры классификаторов, оповещение пользователей о происходящих изменениях. Вопросы для самоконтроля 1. С какой целью разрабатываются классификаторы? 2. Какие бывают классификаторы? 3. Какие существуют системы классификации7 4. Что включается в систему ведения классификаторов? ЛЕКЦИЯ 5 ПРОЕКТИРОВАНИЕ СИСТЕМЫ ЭКОНОМИЧЕСКОЙ ДОКУМЕНТАЦИИ ПОНЯТИЕ УНИФИЦИРОВАННОЙ СИСТЕМЫ ДОКУМЕНТОВ Основной компонентой внемашинного информационного обеспечения ЭИС является система документации, применяемая при управлении экономическим объектом. Под документом понимается определенная совокупность сведений, используемая при решении экономических задач, расположенная на машинном носителе в соответствии с установленной формой. Система документации – совокупность взаимосвязанных форм документов, регулярно используемая в управлении экономическим объектом. Существующие системы документации, характерные для неавтоматизированных ЭИС, отличаются разнообразием типов форм, большим объемом потоков документов, их запутанностью. Для упрощения системы документации используют два подхода: • проведение унификации и стандартизации документов; • введение безбумажной технологии, основанной на использовании электронных документов и новых информационных технологий их обработки. Унификация документов выполняется путем введения единых форм. Вводится единообразие в наименования показателей, единиц измерения и терминов, в результате чего получается унифицированная система документации. Унифицированная система документации (УСД) - это рационально организованный комплекс взаимосвязанных документов, который отвечает единым правилам и требованиям и содержит информацию, необходимую для оптимального управления некоторым экономическим объектом. Унификации подлежат: • стандарты и технические условия; • проектно-конструкторская и технологическая документация; • проектная документация по капитальному строительству; • плановая документация; • статистическая отчетность; • первичная учетная документация; • финансовая первичная и отчетная документация; • бухгалтерская документация бюджетных организаций и объе­динений; • организационно-распорядительная документация; • документация по материально-техническому снабжению; • документация по ценообразованию и торговле По уровням управления, для которых разрабатываются УСД, они делятся на межотраслевые системы документации, используемые на всех предприятиях страны, отраслевые, применяемые только на предприятиях конкретной отрасли, и на системы документации локального уровня, т.е. обязательные для использования в рамках предприятий или организаций. Любой тип УСД должен удовлетворять следующим требованиям: • документы, входящие в состав УСД, должны разрабатываться с учетом их использования в системе взаимосвязанных ЭИС; • УСД должна содержать полную информацию, необходимую для оптимального управления объектом, для которого разрабатывается система; • УСД должна быть ориентирована на использование средств вычислительной техники для сбора, обработки и передачи информации; • УСД должна обеспечить информационную совместимость ЭИС различных уровней; • все документы, входящие в состав разрабатываемой УСД, и все реквизиты-признаки в них должны быть закодированы с использованием международных, общесистемных или локальных классификаторов. ПРОЕКТИРОВАНИЕ УСД При разработке системы документации в ЭИС решаются следующие проблемы: проектирование новых документы; отбор документов, которые будут использоваться в ЭИС без изменений; выявление в существующей системе тех документов, которые надо унифицировать. В процессе проектирования можно выделить три этапа работ: • построение новых форм документов; • унификация всей системы документации; • разработка инструкций и методических материалов, регламентирующих работу пользователей с системой документации. На первом этапе выполняются шесть работ. Содержание первой работы Определение состава результатных показателей зависит от того, какие формы документов проектируются. Выделяются первичные и результатные документы, состав которых выявляется после разработки всех постановок задач. При этом в первую очередь проектируются формы результатных документов, а затем первичных. При выполнении второй работы «Определение состава первичных показателей» выявляется полный состав первичных - исходных показателей, на базе которых рассчитываются результатные показатели, отражаемые в формах результатных документов. При выполнении третьей работы Разбиение показателей по формам документов определяется содержание форм результатных и первичных документов. Разбиение показателей по формам осуществляется по семантической близости показателей и по их алгоритмической увязке при расчете результатных показателей. Для формы результатных документов критерий алгоритмической увязки показателей является главным. При выполнении четвертой работы осуществляется Выбор типа носителя для документа. Если документы первичные, то носителем является бумага формата А4 или А5. Если проектируются результатные документы, то тип и форма выдачи результатной информации зависят от типа решаемой задачи. При выполнении пятой работы Определение способа нанесения информации в документы выбирается способ нанесения информации, который зависит от того, как считывается информация с первичного документа: визуальным способом или автоматическим. Если применяется автоматический способ считывания, то необходимо выбрать устройства считывания и типы шрифтов для нанесения информации в документ. Содержание шестой работы Проектирование форм документов зависит от типа проектируемого документа. На втором этапе выполняются работы по унификации всех документов, включая вновь созданные и уже существующие. Для этого необходимо выявить и проанализировать полный состав системы документации, составить перечень документов по функциональным подсистемам, выявить характеристики документов (периодичность составления, тип задач, адресат, количество показателей, частота использования), исключить из первичных документов производные показатели и показатели, многократно вводимые в ЭВМ, ввести единую терминологию путем составления словаря (тезауруса), установить единые единицы измерения, провести классификацию и кодирование документов, реквизитного состава документов, уточнить используемые формы и построить единые формы документов. На третьем этапе составляются технологическая документация и инструкции, описывающие правила заполнения, передачи, использования и хранения документов, схемы документооборота, отражающие все операции, выполняемые над документами, и подразделения, в которых они происходят, начиная от выписки и кончая сдачей их в архив. ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ ФОРМ ПЕРВИЧНЫХ ДОКУМЕНТОВ Первичные документы предназначены для отражения процессов в материальной сфере и поставляют всю постоянную и оперативную информацию, необходимую для решения экономических задач и выработки управленческих решений. К числу основных требований, предъявляемых к первичным документам, можно отнести следующие: неизбыточность и полноту информации для решения задач, высокую достоверность и своевременность собираемой информации. Кроме того, первичная информация должна быть расположена в документе таким образом, чтобы учитывались требования удобства для последующей обработки данных в ЭВМ. При проектировании форм первичных документов должны учитываться следующие принципы: • отсутствие в первичных документах постоянной информации, для которой необходимо создание самостоятельных файлов; • отсутствие дублирования показателей в документах; • выделение реквизитов, имеющих одно или несколько значе­ний на документ, т.е. выделение однозначных и многозначных реквизитов; • выделение справочных, группировочных реквизитов и реквизитов-оснований; • логичность построения, т.е. старшие по объему понятий признаки должны предшествовать младшим (например, наименование предприятия наименование цеха  номер участка); • согласование последовательности реквизитов в документе с макетами размещения информации на экране ЭВМ и в файлах. Процесс разработки первичных документов имеет особенности в каждой организации и выполняется в следующей последовательности. 1. Определение полного реквизитного состава каждого документа. 2. Классификация реквизитов: однозначные и многозначные; признаки и основания; справочные и группировочные; переносимые и не переносимые на машинные носители. 3. Установление логической соподчиненности реквизитов первичных документов. 4. Выбор какой-либо формы первичного документа. 5. Осуществление размещения реквизитов по выбранной форме в соответствии с проведенной классификацией. 6. Выполнение расчета размеров документа по вертикали и горизонтали с учетом размера полей. 7. Выбор формата бумажного носителя. 8. Построение эскиза документа соответствующей формы. 9. Выделение толстой линией реквизитов, переносимых на машинный носитель. 10. Редактирование шапок документов в соответствии со словарем-тезаурусом. 11. Как правило, используют три типовых формы документов: линейную, табличную, анкетную. ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ ФОРМ ДОКУМЕНТОВ РЕЗУЛЬТАТНОЙ ИНФОРМАЦИИ В результате решения задачи рассчитываются результатные показатели, которые требуется выдать в виде, удобном для пользователя. Так как результатный документ используется для осуществления процессов управления, то он должен отвечать следующим требованиям: • полнота информации, т.е. результатные документы должны содержать в себе первичные (исходные) и результатные показатели; • количество результатных показателей должно соответствовать количеству группировочных признаков (количество итогов должно быть равно количеству ключей сортировки); • своевременность предоставления информации управленческому персоналу; • достоверность предоставляемой информации; • хорошая читаемость (логичность построения форм и наличие хорошо отредактированного текста шапок документов); • отсутствие показателей, рассчитываемых вручную. Построение результатных документов должно выполняться в следующей последовательности. 1. Определение полного реквизитного состава документа. 2. Классификация реквизитов-признаков: на справочные и группировочные; реквизитов-оснований - на первичные и результатные, а результатных оснований - по степеням итогов. 3. Выбор формы документа. 4. Размещение реквизитов в форме согласно их логической соподчиненности. 5. Подсчет длины строки в табличной зоне (Lдок) с учетом пробелов между реквизитами и разделительных линий граф по формуле: Lдок=L1+ L2+ …+ Ln+ k*d, где Li – длина i-го реквизита, k – число колонок в таблице, d – число пробелов между колонками. Если длина строки документа, т.е. его ширина, больше ширины каретки печатающего устройства (с учетом возможного уменьшения размеров шрифта), то перегруппировка реквизитов таблицы осуществляется с использованием следующих методов: • вынос итоговых колонок в итоговые строки; • перенос не уместившихся в листе колонок на новый лист с продолжением нумерации колонок (такие документы затем склеиваются). При этом осуществляется выделение в правой части специальной области для служебных реквизитов (количество листов в документе, номер текущего листа, количество экземпляров, номер экземпляра). Вопросы для самоконтроля 1. Какие функции выполняет документ в ЭИС? 2. Какие виды документов можно выделить в системе документации? 3. Что такое УСД и каким требованиям она должна удовлетворять? 4. Перечислите требования, предъявляемые к построению первичных документов. 5. Каковы принципы и требования к построению форм результатных документов. 6. Каковы особенности построения форм первичных документов? 7. Каков состав операций проектирования форм результатных документов? ЛЕКЦИЯ 6 ПРОЕКТИРОВАНИЕ ВНУТРИМАШИННОГО ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ ПРОЕКТИРОВАНИЕ ЭКРАННЫХ ФОРМ ПЕРВИЧНЫХ ДОКУМЕНТОВ Под электронными формами документов понимается не изображение бумажного документа, а изначально электронная (безбумажная) технология работы; она предполагает появление бумажной формы только в качестве твердой электронной копии. Электронная форма документа (ЭД) - это страница с пустыми полями, оставленными для заполнения пользователем. Формы могут допускать различный тип входной информации и содержать командные кнопки, переключатели, выпадающие меню или списки для выбора Электронная (безбумажная) технология подразумевает не заполнение бумажных форм и их последовательную обработку, а работу с электронными формами сразу с этапа заполнения до этапа извлечения данных и их сбора в определенной базе данных (или экспорт этих данных в какое-либо специализированное приложение). Программы обработки электронных документов позволяют: • вносить элементы настройки типа «персонифицированных» командных кнопок, но базовые формы не могут быть изменены; • быстро имитировать бумажные формы; • использовать функции автоматизации, включающие связь с различными базами данных; • использовать для выполнения вычислений в электронных формах как стандартные операции, так и специальные финансовые и статистические функции; • использовать средства для установления связи между формами; • включать макросы или языки высокого уровня, что позволя­ет разрабатывать и включать процедуры последовательной обработки электронных документов. К недостаткам электронных документов можно отнести неполную юридическую проработку процесса подписи формы: использование электронной подписи с защитой формы от последующих изменений. Проектирование форм электронных документов, т.е. создание шаблона формы с помощью программного обеспечения проектирования форм, обычно включает в себя выполнение следующих шагов: • первый шаг - создание структуры ЭД, который заключается в рисовании линий, создании графических элементов (например, логотипов), т. е. подготовке внешнего вида с помощью графических средств проектирования; • второй шаг - определение содержания формы ЭД, т.е. выбор способов, которыми будут заполняться поля. Поля могут быть заполнены вручную или посредством выбора значений из какого-либо списка, меню, базы данных. В последнем случае дизайнер форм должен связать форму с базой данных. Для определения перечня макетов экранных форм по каждой задаче проектировщик анализирует постановку каждой задачи, в которой приводятся перечни используемых входных документов с оперативной и постоянной информацией и документов с результатной информацией. В процессе анализа определяется, будут ли создаваться макеты под каждый документ или будет осуществляться интеграция нескольких входных документов в один макет. В результате получается перечень макетов экранных форм входных и результатных документов. Содержание макетов определяется на основе анализа состава реквизитов первичных документов с постоянной и оперативной информацией и результатных документов. Содержание макетов - это перечни полей, значения которых должны находиться в файлах с оперативной и результатной информацией, и типы форматов этих полей. При выполнении третьей операции осуществляются выбор типа формы для каждого макета и проектирование их логической структуры. Под логическим проектированием макетов подразумеваются распределение полей по зонам выбранной формы документа и определение последовательности полей в каждой зоне. На входе операции используется универсум типов форм документов. При построении структур макетов для первичных документов с оперативной информацией используют форму документа, максимально приближенную к той, которая была использована для построения самого документа. Расположение полей должно быть в последовательности, соответствующей логической структуре документа и файлов с оперативной информацией, сокращающей трудоемкость операции загрузки ин­формации в информационную базу. При построении макетов для документов с постоянной информацией следует иметь в виду, что эти макеты используются для ввода и актуализации записей информационной базы, поэтому для их проектирования применяют, как правило, анкетную форму расположения реквизитов, удобную для выполнения этих операций. Макеты, предназначенные для вывода на экран результатной информации, строятся по методике проектирования результатных документов. В основе выбора формы макета лежат принципы минимальной трудоемкости и стоимости ввода информации в ЭВМ, максимальной степени читабельности результатной информации, выводимой на экран, и максимальной надежности и достоверности выполнения этих операций. Работа заканчивается выполнением операции Программирование разработанных макетов экранных форм и их отладка с использованием выбранного языка программирования и апробацией их работы. В процессе проектирования и программирования макетов проектировщик должен делить экранное поле на две части: информационную, предназначенную для собственно самого макета, и служебную для дополнительной информации. Информационная часть должна отвечать следующим требованиям: • иметь хороший обзор; • не должна быть перегружена справочными реквизитами, значения которых следует выдавать на экран в виде списков для просмотра при наборе значений группировочных признаков; • значения группировочных признаков также следует выдавать на экран из справочников при переходе указателя в данное поле или при наборе неправильных значений этих признаков; • каждое поле должно быть снабжено подсказкой, которую следует выдавать на экран при неправильных действиях пользователя; • должна быть обеспечена возможность исправления ошибок в наборе; • продвижение указателя должно быть обеспечено в прямом и обратном направлении по вертикали и по горизонтали с воз­можностью экранной прокрутки всего документа; • текущее время и дата должны проставляться автоматически; • общий цвет информационной части должен быть спокойных тонов, не вызывающих усталости пользователя при многочасовой работе с ним; • цвет полей, подлежащих вводу с клавиатуры, должен отличаться от цвета информационной части; • цвет активного поля должен отличаться от основного цвета информационной части и от цвета этого поля в пассивном состоянии. • служебная часть макета, как правило, помещается в нижней части экрана и должна быть отделена от информационной части графически и цветом. Она предназначается для включения подсказок об использовании тех кнопок, с помощью которых пользователь может работать с этим макетом: • производить откат на одно поле назад; • отказываться от ввода; • производить загрузку введенной записи в базу данных; выдавать на печать и т.д. Кроме того, каждый макет должен иметь в этой части экрана инструкционную часть для пользователя со справочной информацией о порядке заполнения макетов и всех видах ошибок, которые могут возникнуть при работе с ними, и способами их исправления. СПОСОБЫ ОРГАНИЗАЦИИ ИНФОРМАЦИОННОЙ БАЗЫ Основной частью внутримашинного информационного обеспечения является информационная база. Информационная база (ИБ) - это определенным способом организованная совокупность данных, хранимых в памяти вычислительной системы в виде файлов, с помощью которых удовлетворяются информационные потребности управленческих процессов и решаемых задач. Файл - это множество записей однородной структуры, предназначенное для решения экономических задач. Запись - это набор полей определенного формата, объединенных по общему ключевому полю. Все файлы ЭИС можно классифи­цировать по следующим признакам: • по этапам обработки (входные, базовые, результатные); • по типу носителя (на промежуточных носителях - гибких магнитных дисках и магнитных лентах и на основных носителях -жестких магнитных дисках, магнитооптических дисках и др.); • по составу информации (файлы с оперативной информацией и файлы с постоянной информацией); • по назначению (по типу функциональных подсистем); • по типу логической организации (файлы с линейной и иерархи­ческой структурой записи, реляционные, табличные); • по способу физической организации (файлы с последовательным, индексным и прямым способом доступа). Входные файлы создаются с первичных документов для ввода данных или обновления базовых файлов. Файлы с результатной информацией предназначаются для вывода ее на печать или передачи по каналам связи и не подлежат долговременному хранению. К числу базовых файлов, хранящихся в информационной базе, относят основные, рабочие, промежуточные, служебные и архивные файлы. Основные файлы должны иметь однородную структуру записей и могут содержать записи с оперативной и условно-постоянной информацией. Оперативные файлы могут создаваться на базе одного или нескольких входных файлов и отражать информацию одного или нескольких первичных документов. Файлы с условно-постоянной информацией могут содержать справочную, расценочную, табличную и другие виды информации, изменяющейся в течение года не более чем на 40. Файлы со справочной информацией должны отражать все характеристики элементов материального производства (материалы, сырье, основные фонды, трудовые ресурсы и т.п.). Как правило, справочники содержат информацию классификаторов и дополнительные сведения об элементах материальной сферы, например, о ценах. Нормативно-расценочные файлы должны содержать данные о нормах расхода и расценках на выполнение операций и услуг. Табличные файлы содержат сведения об экономических показателях, считающихся постоянными в течение длительного времени (например, процент удержаний, отчислений и пр.). Плановые файлы содержат плановые показатели, хранящиеся весь плановый период. Рабочие файлы создаются для решения конкретных задач на базе основных файлов путем выборки части информации из нескольких основных файлов с целью сокращения времени обработки данных. Промежуточные файлы отличаются от рабочих файлов тем, что они образуются в результате решения экономических задач, подвергаются хранению с целью дальнейшего использования для решения других задач. Эти файлы, так же как и рабочие файлы, при высокой частоте обращений могут быть также переведены в категорию основных файлов. Служебные файлы предназначаются для ускорения поиска информации в основных файлах и включают в себя справочники, индексные файлы и каталоги. Архивные файлы содержат ретроспективные данные из основных файлов, которые используются для решения аналитических, например прогнозных, задач. Архивные данные могут также использоваться для восстановления информационной базы при разрушениях. Организация хранения файлов в ИБ должна обеспечивать полноту хранимой информации для выполнения всех функций управления и решения экономических задач; непротиворечивость данных при вводе информации в ИБ; своевременность и одновременность обновления данных во всех копиях данных; удобство языкового интерфейса, позволяющее быстро формулировать запрос к ИБ, разграничение прав доступа. Существуют следующие способы организации ИБ: совокупность локальных файлов, поддерживаемых функциональными пакетами прикладных программ, и интегрированная база данных, основывающаяся на использовании универсальных программных средств загрузки, хранения, поиска и ведения данных, т.е. системы управления базами данных (СУБД). Локальные файлы вследствие специализации структуры данных под задачи обеспечивают, как правило, более быстрое время обработки данных. Однако недостатки организации локальных файлов, связанные с большим дублированием данных в информационной системе и, как следствие, несогласованностью данных в разных приложениях, а также негибкостью доступа к информации, перекрывают указанные преимущества. Поэтому организация локальных файлов может применяться только в специализированных приложениях, требующих очень высокую скорость реакции, при импорте необходимых данных. Интегрированная ИБ, т.е. база данных (БД), - это совокупность взаимосвязанных, хранящихся вместе данных при такой мини­мальной избыточности, которая допускает их использование оптимальным образом для множества приложений. Централизация управления данными с помощью СУБД обеспечивает совместимость этих данных, уменьшение синтаксической и семантической избыточности, соответствие данных реальному состоянию объекта, разделение хранения данных между пользователями и возможность подключения новых пользователей. Но централизация управления и интеграция данных приводят к необходимости усиления контроля вводимых данных, обеспечения соглашения между пользователями по поводу состава и структуры данных, разграничения доступа и секретности данных. Основными способами организации БД являются создание централизованных и распределенных БД. Основным критерием выбора способа организации ИБ является достижение минимальных трудовых и стоимостных затрат на проектирование структуры ИБ, программного обеспечения системы ведения файлов, а также на перепроектирование ИБ при возникновении новых задач. К организации БД предъявляются следующие основные требования: • логическая и физическая независимость данных (программ от изменений структуры БД); • контролируемая избыточность данных; • стандартизация данных за счет использования классификаторов; • наличие словаря данных; • специализация интерфейса для администратора БД и пользователя системы; • контроль целостности данных; • защита данных от несанкционированного доступа; наличие вспомогательных программных средств (утилит) проектирования и эксплуатации БД. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ БАЗЫ Процесс проектирования ИБ как совокупности локальных файлов начинается с операции Определения информационной потребности каждой задачи, которую составляют входные и результатные документы, и выявляют, анализируя Постановку задачи. В результате выполнения этой операции получают Перечень документов. Далее выполняется операция Определения периодичности решения задач и получается Список задач и периодичности их решения. На третьей операции Составления списка файлов выявляется полный состав файлов и проводится их классификация, в результате получается полный перечень имен файлов ИБ. На основе полученного списка файлов, а также документа и универсума форм входных и результатных документов выполняется операция Определения содержания файлов по формированию состава полей записей файлов. При выполнении этой операции учитывается ряд основных принципов создания файлов: • алгоритмическая направленность создания информационных файлов; • семантическая и синтаксическая однородность файлов; • упорядоченность хранения файлов по ключу; • универсализация файлов. После определения состава и содержания полей каждого файла производятся Определение характеристик файлов и получение таблицы характеристик файлов, включающей в себя: наименование файла; длину логической записи файла; количество логических записей; объем файла в байтах; частоту использования файла; порядок обработки файла (последовательный, прямой); периодичность обновления файла; объем обновлений файла в байтах; длительность хранения; тип носителя; объем памяти. Далее, осуществляется Выбор логической организации файлов на основе универсума способов логической организации с получением таблицы описаний. Затем осуществляется «Выбор носителей» для каждого файла из универсума машинных носителей. Далее выполняется операция «Выбор физической организации файлов», используя данные списка выбранных носителей и универсума способов физической организации файлов ИБ, в результате получаем таблицу описания физической организации файлов. Проектирование БД имеет свои особенности на всех стадиях и этапах проектирования, рассмотренные в курсе «Базы данных и знаний». Вопросы для самоконтроля 1. Каков состав внутримашинного обеспечения? 2. Что такое электронный документ? 3. Что такое макет экранной формы и каковы типы макетов? 4. Какие виды файлов существуют в ЭИС? 5. Что такое информационная база и каковы требования, которым она должна удовлетворять? 6. Принципы и способы организации ИБ как совокупности локальных файлов. 7. Принципы и способы организации интегрированной БД. ЛЕКЦИЯ 7 ИНДУСТРИАЛЬНОЕ ПРОЕКТИРОВАНИЕ КОРПОРАТИВНЫХ ЭИС РЕИНЖЕНИРИНГ БИЗНЕС-ПРОЦЕССОВ НА ОСНОВЕ КОРПОРАТИВНОЙ ЭИС Под бизнес–процессом (БП) понимают совокупность взаимосвязанных операций (работ) по изготовлению готовой продукции или выполнению услуг на основе потребления ресурсов. Современные предприятия имеют сложную структуру, обусловленную многопрофильностью, большим числом связей с партнерами. В этих условиях происходит смещение с акцентов управления отдельными подразделениями и ресурсами на управление сквозными процессами, связывающими воедино деятельность взаимосвязанных подразделений предприятия. При этом в ходе управления бизнес–процессами все материальные, финансовые, информационные потоки рассматриваются во взаимодействии. Реинжиниринг бизнес-процессов (РБП) определяется как фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения коренных улучшений в основных показателях деятельности предприятия. Целью РБП является системная реорганизация материальных, финансовых, информационных потоков, направленная на упрощение организационной структуры, перераспределение и минимизацию использования различных ресурсов, сокращение сроков реализации потребностей клиентов, повышение качества их обслуживания. РБП обеспечивает решение следующих задач: • определение оптимальной последовательности выполняемых функций, которое приводит к сокращению цикла изготовления и продажи товаров и услуг, обслуживания клиентов; • оптимизация использования ресурсов, в результате чего минимизируются издержки и обеспечивается оптимальное сочетание различных видов деятельности; • построение адаптивных БП, нацеленных на быструю адаптацию к изменениям потребностей конечных потребителей продукции; • определение рациональных схем взаимодействия с партнерами и клиентами. ИБП включает в себя реинжиниринг БП, проводимый с периодичностью в 5-7 лет, выполняется на основе применения инженерных методов и современных программных инструментальных средств моделирования БП. РБП возможен только на основе интегрированных корпоративных ИС, которые обеспечивают поддержку управлению деловыми процессами на всех уровнях. В отличие от канонического подхода к автоматизации отдельных функций управления в виде отдельных АРМов, не изменяющих существующую технологию управления, использование КЭИС предполагает изменение системы управления на основе концепции автоматизации управления сквозными БП. Причем адаптация структуры КЭИС к изменениям потребностей системы управления должна быть непрерывной. Общими требованиями к созданию КЭИС, обеспечивающих эффективный РБП предприятий являются: • модульность, предполагающая разработку и внедрение ЭИС по отдельным программным комплексам, которые автоматизируют определенные виды деятельности предприятия и взаимодействуют между собой; • интегрируемость, позволяющая осуществлять информационный обмен между программными комплексами через общую БД на основе стандартов представления форматов данных и интерфейсов; • адаптивность, обеспечивающая настраиваемость программных комплексов на различные схемы организации БП; • масштабируемость, позволяющая наращивать число АРМ ЭИС по мере внедрения программных комплексов и расширения предприятия без потери эффективности эксплуатации ЭИС; • открытость (переносимость), реализующая сопряжение программных комплексов со стандартными программными приложениями; • конфиденциальность, предполагающая настройку прав доступа пользователей к системе в зависимости от уровня компетенции. РБП предполагает изменение архитектуры ЭИС, которая должна: • на оперативном уровне обеспечить ускорение информационных потоков, связывающих участников деловых процессов, и улучшить синхронизацию одновременно выполняемых процессов; • на тактическом уровне способствовать повышению качества принимаемых управленческих решений, позволяющих адаптировать деловые процессы к изменению внешней среды; • на стратегическом уровне обеспечивать процесс принятия решений относительно проектирования новых и перепроектирования существующих БП. На оперативном уровне упрощение организации осуществляется на основе принципов горизонтального и вертикального сжатия процессов. Горизонтальное сжатие процесса подразумевает объединение нескольких рабочих процедур в рамках создания многофункционального АРМ, подключаемой к комплексной системе автоматизации управления. Например, при приеме заказа от клиента выполняется не только его регистрация, но и планирование выполнения. В ходе планирования проверяется достаточность всех ресурсов, осуществляется их выделение, назначаются сроки выполнения, корректируется общий план–график работ. Кроме того, с помощью ЭС в случае дорогостоящих заказов может быть выполнена проверка финансового состояния клиента. Вертикальное сжатие процесса это – организация и контроль выполнения делового процесса со стороны менеджеров на основе использования ЛВС с архитектурой «клиент – сервер», систем управления потоками работ и распределенных БД. Таким образом, сокращаются затраты времени на межоперационные переходы, достигается более гибкое планирования и использование имеющихся ресурсов. На тактическом уровне управления для оптимизации выполнения БП требуется применение автоматизированных систем планирования и управления, которые позволяют своевременно выявлять потребность в ресурсах и обеспечить ее реализацию. К таким системам относятся системы управления ресурсами следующих классов: • планирование потребности в материалах под производственную программу или заказ; • планирование производства, включая определение потребности в материалах, производственных мощностях, трудовых ресурсах; • комплексное планирование работы предприятия, включая обеспечение финансовыми ресурсами в соответствии с производственной программой. На стратегическом уровне обоснование принятия решений по выпуску новой и модернизации существующей продукции, расширению или сокращению финансово–хозяйственной деятельности предполагает широкое использование СППР на базе применения ЭММ моделирования, ЭС, статистических методов прогнозирования, интеллектуального анализа данных. Для реализации перечисленных требований многие методы канонического проектирования ЭИС, предназначенные для локальной автоматизации управленческих процессов, становятся непригодными, и только методы и средства индустриального проектирования ЭИС на основе применения CASE, RAD и компонентной технологий позволяют осуществлять быструю разработку и адаптацию проектных решений в соответствии с динамически изменяющимися потребностями. ЭТАПЫ РЕИНЖИНИРИНГА БИЗНЕС-ПРОЦЕССОВ В моделях жизненного цикла ЭИС предполагалось, что требования организационно–экономической системы к ЭИС, как правило, четко определяются к моменту начала проектирования ЭИС, т.е. система функционирует к моменту разработки ЭИС. РПБ предполагает, что реорганизация системы не может быть успешно проведена без создания адекватной ЭИС. Поэтому ЭИС не просто автоматизирует существующие деловые процессы «как есть», а обеспечивает поддержку изменений организационно–экономической системы на принципах «как должно быть». Вследствие этого реорганизация системы и проектирования ЭИС идут параллельно. Параллельность жизненного цикла разработки ЭИС означает также, что большинство основных реорганизуемых БП проектируется одновременно, что вызывает необходимость параллельной координации проводимых работ в части разработки общих обеспечивающих подсистем. Таким образом, общесистемные требования формируются в процессе реализации требований по отдельным БП. Имеет место следующая последовательность этапов проведения бизнес–реинжиниринга. На стадии идентификации выделяются ключевые БП, реорганизация которых обеспечивает кардинальное повышение эффективности функционирования организационно - экономической системы (предприятия). На стадии обратного инжиниринга осуществляется моделирование существующих деловых процессов с целью формулирования предложений по их реорганизации. Стадия прямого инжиниринга включает построение моделей новой организации деловых процессов и их реализацию в виде рабочего проекта. Модели новой организации деловых процессов доказывают возможность достижения сформулированных на этапе идентификации критериев эффективности. В дальнейшем модели деловых процессов воплощаются в виде положений и инструкций по организации работ персонала и техно – рабочего проекта ИС. Внедрение предполагает комплексное тестирование разработанных компонентов проекта, обучение персонала и поэтапный ввод в действие перепроектированных БП. ИДЕНТИФИКАЦИЯ БП Работы по идентификации БП инициируют менеджеры верхнего звена управления предприятием – лица, принимающие решения. На этом этапе осуществляется постановка задач РБП, которая определяется ключевыми проблемами предприятия (например, снижение объема продаж, высокая текучесть кадров, межоперационные простои). Постановка задач включает: 1. Формулирование (уточнении) миссии предприятия. 2. Определение критических факторов успеха (7 – 8 факторов) или критериев эффективности организации БП. 3. Выявление основных видов БП, как существующих, так и перспективных (10 – 15 процессов). 4. Описание отличительных особенностей выявленных БП. 5. Оценка важности БП по степени влияния на реализацию критических факторов успеха. 6. Определение ограничений, связанных с уровнем квалификации персонала фирмы, технической оснащенности производства, наличием ИТ, финансовых ресурсов. 7. Описание возможных сценариев развития предприятия: появление новых технологий, ресурсов, изменение поведения клиентов, партнеров, конкурентов. 8. Определение внешних рисков обеспечения финансовыми ресурсами, надежности партнеров, конъюнктуры рынка. 9. Ранжирование БП для проведения РБП в соответствии с полученной оценкой важности, ограничениями, рисками и перспективами. Для подготовки принятия решений по проведению РБП или уточнения сформулированных задач РБП может быть проведена работа по обобщенному анализу финансово–хозяйственной деятельности предприятия с использованием современных ИТ. Так, формулирование миссии предполагает решение задач качественного анализа деловых процессов, связанных с определение стратегии поведения предприятия на рынке в части расширения границ рынка или глубокого проникновения на рынок, повышения качества товаров, услуг. В качестве основных методов формирования стратегии предприятия используются методы анализа иерархий Саати, нечеткой логики Заде, а инструментальных средств – статистические ЭС с возможностью обработки качественных (нечетких) оценок, такие, как Expert Choice, Guru, Level5, Nexpert Objects. Выбор БП выполняется на основе анализа сегментов рынка, с помощью которого конкретизируются стратегические цели предприятия для определения регионов, потребителей, каналов распределения продуктов и услуг. Основными методами исследования на этом этапе выступают методы статистического анализа и прогнозирования, методы интеллектуального анализа данных. Наиболее мощными инструментальными средствами анализа и прогнозирования для выявления основных сегментов рынка являются ППП SAS, Oracle Express, Business Objects, SPSS. Оценка ограничений и рисков, связанных с проведением РБП, выполняется в ходе решения задач бизнес–планирования. В частности, для выделенных БП осуществляется оценка возможностей предприятия в плане эффективности распределения капиталовложений по различным проектам. Для решения этой задачи обычно используются ЭММ и методы оптимизации. К наиболее известным относятся ППП Project Expert, PROSPIN. После принятия решения о проведении РБП выполняется планирование работ на всех стадиях жизненного цикла проекта, выделяются материальные, людские, финансовые ресурсы. Планирование РБП осуществляется с помощью методов и средств управления проектами. С помощью простейших программных средств управления проектами типа TimeLine, Microsoft Project строятся сетевые календарные графики выполнения работ. ОБРАТНЫЙ ИНЖИНИРИНГ Обратный инжиниринг предполагает исследование функционирующих на предприятии БП. Цель этого этапа заключается в проведении диагностики «узких мест» в организации существующих БП и формировании направлений их реорганизации. Задача упрощается, если на предприятии имеется документация о функционирующих процессах после предыдущей реорганизации. На этом этапе уточняется постановка задач, выполненная на этапе идентификации, проводится корректировка целей. Используются методы и средства структурного анализа деловых и информационных процессов, которые реализованы в ППП: Design/IDEF, ErWin, ARIS Toolset. РАЗРАБОТКА МОДЕЛЕЙ НОВОЙ ОРГАНИЗАЦИИ БП. Прямой инжиниринг предполагает разработку моделей новой организации БП. При этом модели могут строиться в нескольких вариантах, из которых выбираются наиболее эффективные с точки зрения реализации критических факторов успеха. В конечном счете, составляют два варианта моделей новой организации БП: • идеальную модель, которая может быть достигнута в перспективе и к которой следует стремиться; • реальную модель, которая может быть достигнута в обозримом будущем с учетом имеющихся ресурсов и ограничений. Причем реальная модель БП должна быть такой, чтобы можно было в перспективе перейти к идеальной модели, т.е. обе модели должны быть концептуально близки друг к другу. Моделирование проблемной области БП выполняется в два подэтапа: 1) определяется объективная структура новой организации БП: состав объектов, функций и событий; 2) объекты и функции БП распределяются по структурным подразделениям предприятия, и определяют требования к ИС. Для обоснования варианта организации БП используются методы динамического имитационного моделирования. Динамический анализ предполагает рассмотрение во времени множества одновременно выполняющихся БП. Имитационное моделирование БП позволяет формировать такие характеристики, как производительность (объемы производства, сбыта), временные и стоимостные характеристики отдельных функций, степень и стоимость использования ресурсов. Целями имитационного моделирования БП могут быть: • сравнение средних значений и дисперсий динамических характеристик различных альтернатив процессов при одинаковых исходных данных (один сценарий моделирования – несколько моделей); • отыскание оптимальных значений переменных на множестве возможных значений (несколько сценариев моделирования – одна модель); • определение зависимостей между различными факторами процессов в результате специального анализа полученной статистики. РЕАЛИЗАЦИЯ ПРОЕКТА РЕИНЖИНИРИНГА БП После определения моделей новой организации БП осуществляется разработка обеспечивающих подсистем, поддерживающих функционирование предприятий в новых условиях. Для изменения структуры ОЭС осуществляется: • разработка организационно–штатной структуры предприятия; • разработка должностных инструкций; • разработка системы стимулирования работников; • обучение персонала; • подготовка рабочей документации. Для создания новой ИС осуществляются: • генерация, настройка, программирование и отладка программных модулей; • разработка и наполнение БД; • установка оборудования. Для быстрой разработки ИС используются CASE – средства автоматизации проектирования или средства конфигурации комплексных систем управления ресурсами предприятия. В том и другом случае для разработки оригинального программного обеспечения могут потребоваться средства быстрой разработки приложений (RAD – технология) и языки программирования. ВНЕДРЕНИЕ ПРОЕКТА РЕИНЖИНИРИНГА БП Внедрение проекта РБП, как правило, осуществляется поэтапно в соответствии с приоритетами, установленными на этапе идентификации БП. Большое значение на этапе внедрения отводится комплексному тестированию компонентов проекта, для чего используются специальные программные средства. Внедрение проекта РБП предполагает его сдачу приемочной комиссии, в которую входят представители лиц, принимающих решения и будущие менеджеры процессов. После внедрения спроектированных БП в реальную практику очень важно организовать анализ достижения заданных в начале реинжиниринга критериев эффективности функционирования предприятия, на основе которых можно своевременно принимать решения о необходимости адаптации БП к изменяющейся внешней среде. Вопросы для самоконтроля 1. Что такое бизнес-процесс и чем процесс управления бизнес-процессом отличается от управления ресурсами 2. Что понимают под реинжинирингом бизнес-процессов. Какие задачи решает реинжиниринг? 3. Перечислите основные этапы реинжиниринга бизнес-процессов. 4. Что понимают под моделью проблемной области. 5. Какие требования предъявляют к модели проблемной области. 6. Какие существуют критерии для оценки модели проблемной области? ЛЕКЦИЯ 8 АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС (CASE – ТЕХНОЛОГИИ) ОСНОВНЫЕ ПОНЯТИЯ И КЛАССИФИКАЦИЯ CASE – ТЕХНОЛОГИЙ CASE–технологии с самого начала развивались с целью преодоления ограничений при использовании структурной методологии проектирования (сложности понимания, высокой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации) за счет ее автоматизации и интеграции поддерживающих средств. Большинство существующих CASE–систем ориентировано на автоматизацию проектирования программного обеспечения и основано в основном на методологиях структурного или объектно-ориентированного проектирования и программирования, использующих спецификации в виде диаграмм или текстов для описания системных требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств. Наибольшая потребность в использовании CASE–систем испытывается на начальных этапах разработки, а именно на этапах анализа и спецификации требований к ЭИС. Так как цена ошибок, допущенных на этих этапах, превышает цену ошибок, допущенных на последующих стадиях разработки. Преимущества CASE–технологии по сравнению с традиционной технологией оригинального проектирования: • улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации; • возможность повторного использования компонентов разработки; • поддержание адаптивности и сопровождения ЭИС; • снижение времени создания системы, возможность получения на ранних стадиях прототипа системы и его оценки; • освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор. CASE – средства имеют следующую архитектуру. Ядром системы является база данных проекта – репозиторий (словарь данных). Он представляет собой специализированную базу данных, предназначенную для отображения состояния проектируемой ЭИС в каждый момент времени. Объекты всех диаграмм синхронизированы на основе общей информации словаря данных. Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следующих объектов: • проектировщиков и их прав доступа к различным компонентам системы; • организационных структур; • диаграмм; • компонентов диаграмм; • связей между диаграммами; • структур данных; • программных модулей; • процедур; • библиотеки модулей. Графические средства моделирования предметной области позволяют разработчикам АИС в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями. Все модификации диаграмм, выполняемых разработчиками в диалоговом режиме, вводятся в словарь данных, контролируются с общесистемной точки зрения и могут использоваться для дальнейшей генерации действующих функциональных приложений. В любой момент времени диаграммы могут быть распечатаны для включения в техническую документацию проекта. Графический редактор диаграмм предназначен для отображения в графическом виде в заданной нотации проектируемой ЭИС. Он позволяет выполнять следующие операции: • создавать элементы диаграмм и взаимосвязи между ними; • задавать описания элементов диаграмм; • задавать описания связей между элементами диаграмм; • редактировать элементы диаграмм, их взаимосвязи и описания. Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции: • мониторинг правильности построения диаграмм; • диагностику и выдачу сообщений об ошибках; • выделение на диаграмме ошибочных элементов. Документатор проекта позволяет получать информацию о состоянии проекта в виде различных отчетов. Отчеты могут строиться по нескольким признакам: по времени, автору, элементам диаграмм, по проекту в целом. Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций: • инициализации проекта; • задания начальных параметров проекта; • назначения и изменения прав доступа к элементам проекта; • мониторинга выполнения проекта. Сервис представляет набор системных утилит по обслуживанию репозитория. Данные утилиты выполняют функции архивации, восстановления данных, создания нового репозитория. Современные CASE–системы классифицируются по следующим признакам: • по поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные, комплексно-ориентированные (набор методологий проектирования); • по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями, с наиболее распространенными нотациями; • по степени интегрированности: ◦ tools (отдельные локальные средства); ◦ toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС); ◦ workbench (полностью интегрированные средства, связанные с репозиторием); • по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на ЛВС, Ориентированные на ГВС, смешанного типа; • по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов; • по типу ОС. Помимо поддержки начальных этапов разработки важное значение приобретают CASE-системы, ориентированные на проектирование и генерацию БД и пользовательских интерфейсов. ФУНКЦИОНАЛЬНО – ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС Основными идеями функционально-ориентированной CASE-технологии являются идеи структурного анализа и проектирования ИС. Они заключаются в следующем: 1. декомпозиция всей системы на некоторое множество иерархически подчиненных функций; 2. представление всей информации в виде графической нотации. Систему всегда легче понять, если она изображена графически. В качестве инструментальных средств структурного анализа и проектирования выступают следующие диаграммы: • BFD – диаграмма бизнес-функций (функциональные спецификации): позволяют представить общую структуру ИС, отражающую взаимосвязь различных задач (процедур) в процессе получения требуемых результатов. Основными объектами этих диаграмм являются: ◦ Функция – некоторое действие ИС, необходимое для решения экономической задачи; ◦ Декомпозиция функций – разбиение функций на множество подфункций; • SAG нотация: • DFD – диаграмма потоков данных (ДПД); ДПД, как правило, жестко ориентированы на какую-либо технологию обработки данных и отражают передачу информации от одной функции к другой в рамках заданной технологии обработки. В узлах диаграммы потоков данных (прямоугольниках) отображаются процедуры, а стрелками между узлами показываются потоки данных (над стрелками указываются имена передаваемых/используемых единиц информации – документов, экранных форм, файлов). • STD – диаграмма переходов состояний (ДПС - матрицы перекрестных ссылок); ДПС моделируют поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчетного периода). Такие диаграммы позволяют осуществить декомпозицию управляющих процессов, происходящих в системе, и описать отношение между управляющими потоками. С помощью ДПС можно моделировать последующее функционирование системы, исходя из предыдущих и текущего состояния. • SSD – диаграмма структуры программного приложения задает взаимосвязь функций и программных модулей, которые их реализуют. Представляет собой иерархическую взаимосвязь программных модулей, которые реализует ИС. Служит мостом для перехода от системных требований, которые отображены в предыдущих диаграммах, к реализации информационной системы. Фрагмент SSD-диаграммы в нотации SAG для задачи аналитического учета на складах имеет вид: • ERD – ER-модель данных предметной области (информационно-логические модели «сущность – связь»): ориентирована на разработку БД, структура которой не зависит от конкретных информационных потребностей и позволяет выполнять любые запросы пользователей. ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС Структурная декомпозиция ЭИС на основе объектно-ориентированного подхода отличается от функционально-ориентированного подхода лучшей способностью отражать динамическое поведение системы в зависимости от возникающих событий. В этом плане модель проблемной области рассматривается как совокупность взаимодействующих во времени объектов. Тогда конкретный процесс обработки информации формируется в виде последовательности взаимодействий объектов. Одна операция обработки данных может рассматриваться как результат одного взаимодействия объектов. Конечным результатом процесса ООП должно стать множество классов объектов с присоединенными методами обработки атрибутов. Если в функциональном подходе модели данных и операции разрабатываются относительно независимо друг от друга и только координируются между собой, то ОО подход предполагает совместное моделирование данных и процессов. При этом модели проблемной области в репозитории постепенно уточняются. В связи с этим система ОО моделей постепенно разворачивается по направлению от модели общего представления функциональности ЭИС к модели динамического взаимодействия объектов, на основе которой могут быть сгенерированы классы объектов конкретной программно-технической среде. Для ОО моделирования используется унифицированный язык моделирования (UML). Система ОО моделей в соответствии с нотациями UML включает в себя следующие диаграммы: 1. Диаграмму прецедентов использования (Use-case diagram), которая отображает функциональность ЭИС в виде совокупности выполняющихся последовательных транзакций; 2. Диаграмму классов объектов (Class diagram), которая отображает структуру совокупности взаимосвязанных классов объектов аналогично ER-диаграмме функционально-ориентированного подхода; 3. Диаграммы состояний (Statechart diagram), каждая из которых отображает динамику состояний объектов одного класса и связанных с ним событий; 4. Диаграммы взаимодействия объектов (Interaction diagram), каждая из которых отображает динамическое взаимодействия объектов в рамках одного прецедента использования; 5. Диаграммы деятельностей (Activity diagram), которые отображают потоки работ во взаимосвязанных прецедентах использования (могут декомпозироваться на более детальные диаграммы); 6. Диаграммы пакетов (Package diagram), которые отображают распределение объектов по функциональным или обеспечивающим подсистемам (могут декомпозироваться на более детальные диаграммы); 7. Диаграмму компонентов (Component diagram), которая отображает физические модули программного кода; 8. Диаграмму размещения (Deployment diagram), которая отображает распределение объектов по узлам вычислительной сети. Диаграмма прецедентов использования (ДПИ) ДПИ выявляет основные БП как последовательности транзакций, которые должны выполняться целиком, когда выполнение обособленного подмножества действий не имеет значения без выполнения всей последовательности. Прецеденты использования инициируются из вешней среды пользователями ЭИС, называемыми актерами. На этом уровне моделирования не раскрывается механизм реализации процессов. Представленные сущности имеют следующие графические обозначения: Актер – внешний пользователь процесса Прецедент использования (БП) Актер инициирует выполнение прецедента использования и получает от него результаты. Взаимодействие (ассоциация) актеров с прецедентом использования осуществляется в результате события, которое обозначается поименованной стрелкой. Один актер может участвовать в нескольких прецедентах использования, а в одном ПИ может быть занято несколько актеров Информирование об отложенном заказе Информирование о заказе на закупку формирование заказа удаление подтверждение Менеджер заказа заказа Менеджер по продажам ввод по закупкам данных оформление договора Рис. 6. Пример ДПИ В реализации прецедентов использования (ПИ) возможно выделение нескольких потоков событий: • основной поток событий, который приводит к требуемому результату наиболее коротким путем, например выполнение заказа без задержек; • альтернативные потоки событий, например временное откладывание или полный отказ от выполнения заказов. Основной и альтернативный потоки событий в модели прецедентов использования описываются в виде текстовых комментариев. Несколько ПИ могут иметь общую часть, выделяемую в самостоятельный ПИ, с которым устанавливаются отношения использования (uses). С другой стороны, некоторые прецеденты использования могут быть расширены деталями. В таком случае создается дополнительный прецедент использования, с которым устанавливаются отношения расширения (extends). ввод uses данных Менеджер оформление uses договора extends extends Рис. 7 Пример применения отношений использования и расширения Диаграммы классов объектов (ДКО) ДКО отображают статическую структуру классов объектов. Эта диаграмма рассматривает внутреннюю структуру проблемной области, иерархию классов объектов, статические связи объектов. Классы объектов могут иметь различные стереотипы поведения: объекты-сущности, управляющие объекты, интерфейсные объекты: Интерфейсный объект – Управляющий объект - Сущность – активный объект форма взаимодействия ИС с пользователем (экранная форма, меню, кнопка) активный объект, координирующий выполнение функций пассивный объект над которым выполняются операции обработки Объекты, отражаемые в диаграмме классов объектов, связываются статическими отношениями, которые отражают постоянные связи между объектами независимо от выполнения конкретного БП. К статическим отношениям относятся обобщение, агрегация, ассоциация объектов. Диаграммы состояний (ДС) ДС отображает поведение объектов одного класса в динамике, связь состояний объектов с событиями и определяет: • типичные состояния проходит объект; • события, ведущие к изменению состояния объекта; • действия выполняемые, когда он получает сообщение об изменении состояния; • объекты создаются и уничтожаются (входные и выходные точки диаграммы). Используются следующие обозначения: Входная точка Состояние Переход состояний Выходная точка Входная точка определяет событие, которое образует начальное состояние объекта. В точку входа нельзя перейти из состояния объекта. Выходная точка определяет завершение существования объекта. Из нее нет перехода состояния. Состояние представляет ситуацию, в течение которой выполняется непрерывная деятельность или объект находится в стационарном положении. Состояние определяется как набор значений атрибутов и отношений, связанных с объектом. Имя состояния должно быть уникальным только внутри класса объекта, для которого оно определяется. С каждым состоянием связано одно событие или более, которые могут его изменить. Для состояния задаются имена всех связанных с ним переходов в другие состояния. Переход состояний определяет изменение в состоянии объекта, которое происходит в результате события, возникающего в то время, когда объект находился в данном состоянии. Каждый переход состояний должен иметь уникальное имя. Переход состояний описывается следующими атрибутами: • назначение – состояние объекта, в которое перейдет объект после перехода состояния. • вызов – имя события, которое вызывает переход состояний. Имена событий должны быть идентичными в определении класса и состояния. Вызываемые события могут быть либо внешними, осуществляемыми актерами, либо внутренними, связанными с поведением других объектов, либо временными, связанными с истечением заданного интервала времени. • условие перехода – это логическое выражение, связанное с атрибутами объекта, которое должно быть проверено для выбора перехода состояния. Условие перехода задается в том случае, если происходит событие, в результате которого может произойти неоднозначный переход состояний. Условия переходов для одного исходного состояния должны быть взаимоисключающими. • действие – атрибут, информационно описывающий сущность действия, которое должно выполняться при переходе состояний. Этому действию будет соответствовать некоторая процедура, реализующая метод класса объектов. Переход состояний графически помечается меткой линии, на которой задается, по крайней мере, один из следующих атрибутов: Вызов, Условие перехода, Действие. Диаграмма взаимодействия объектов Для каждого прецедента использования может быть построена модель динамического взаимодействия объектов, которая представляется в одной из двух форм: • в форме диаграммы последовательностей, показывающей последовательность взаимодействий на графе; • в форме кооперативной диаграммы, показывающей взаимодействие объектов в табличной форме. В диаграмме последовательностей взаимодействие объектов отображается в виде стрелки между объектами, которая соответствует событию или сообщению от одного объекта к другому, вызывающего выполнение метода, реагирующего на событие (сообщение) объекта. Номер стрелки соответствует номеру события в последовательности. Диаграмма кооперативного поведения представлена в табличном виде по следующим правилам. 1. В столбцах таблицы указываются объекты всех типов, участвующие в реализации прецедента использования. Порядок расположения активных и пассивных объектов произволен и должен быть удобен для понимания модели. Актеры прецедента использования отображаются на правой и левой границах таблицы. 2. По горизонтали проводятся поименованные стрелки, отображающие взаимодействие (коммуникацию) объектов в рамках данной операции. Эта стрелка означает, что первый объект в рамках выполняемой операции посылает сообщение второму объекту о необходимости выполнения действия. При получении сообщения второй объект выполняет действие. 3. На пересечении строк и столбца вертикально отображается условный отрезок времени, в течение которого выполняется то или иное действие над объектом. Диаграмма деятельностей Диаграммы взаимодействия не отражают детально порядок выполнения операций в части разветвлений, циклических повторений, параллельности/произвольности действий. Диаграмма деятельностей исправляет эти недостатки. Под деятельностью понимают некоторую работу, которая может быть декомпозирована на совокупность действий. Диаграмма деятельностей может отражать взаимодействие объектов из нескольких прецедентов использования, в частности реализующих отдельные стандартные и альтернативные пути обработки объектов. Блок, соответствующий одной деятельности, может отражать несколько событий и быть декомпозирован аналогично блоку функционально-ориентированного подхода. Имеют место следующие обозначения: Деятельность Выход Поток от деятельности к деятельности Итерация Синхронизация Решение Разделение потока на деятельности, выполняемые параллельно или произвольно Диаграммы пакетов В объектно-ориентированном подходе пакет содержит множество взаимосвязанных классов объектов и соответствует понятию «подсистема функционально-ориентированного подхода». Один прецедент использования может требовать классы объектов из разных пакетов. Класс объектов обычно назначается одному пакету, но с позиции достижения разных подцелей может входить в состав разных пакетов. Пакетная технология группирования классов объектов позволяет: • упростить разработку и эксплуатацию ЭИС; • применить гибкую адаптацию типовых компонентов с позиции их повторного использования; • оптимизацию клиент-серверной архитектуры ЭИС. Обычно ЭИС разбивается на функциональные и обеспечивающие пакеты. Функциональные пакеты, соответствующие решаемым проблемам (задачам), объединяются в один общий пакет «Проблемная область». Каждый пакет, в свою очередь, может быть разбит на подпакеты в соответствии с семантической близостью и теснотой взаимодействия классов объектов. Обычно пакеты проблемной области содержат иерархии обобщения и агрегации. Классы объектов, требуемые в нескольких подсистемам выделяются в самостоятельные пакеты. В одном пакете, как правило, выделяется не более 20 компонентов. С обеспечивающей точки зрения ЭИС разбивают на пять основных пакетов: • Интерфейс, объекты которого реализуют функции взаимодействия пользователей с ЭИС по вводу-выводу информации и обмен сообщениями между системами; • БД, объекты выполняющие доступ к данным внешней памяти; • Управление задачами, объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов, например, в системе управления рабочими потоками; • Утилиты, объекты которого осуществляют вспомогательные функции, например преобразование форматов данных; • Обеспечивающие пакеты, т.е. работающие по принципу клиент-серверной архитектуры, выполняющие серверные функции для функциональных объектов-клиентов. Таким образом, обеспечивающие пакеты освобождают пользователя от знания деталей программно-технической реализации ЭИС. Диаграммы компонентов и размещения Диаграмма компонентов отображает зависимости программных компонентов, которые представляются в виде исходных, откомпилированных и исполняемых программных кодов объектов. Один компонент, как правило, соответствует программному коду одного пакета класса объектов. Компонент в своем составе имеет интерфейсный класс объектов, через которые осуществляется доступ к остальным классам объектов компонента. С помощью интерфейса объекты других компонентов обращаются не к конкретным объектам рассматриваемого компонента, а к его интерфейсному объекту. Таким образом, упрощается взаимодействие компонентов между собой, когда при доступе к компоненту из других компонентов не требуется знать внутреннюю структуру этого компонента. Компонент, к которому осуществляется обращение, может быть не объектно-ориентированным. Достаточно, чтобы у такого компонента был только один интерфейсный класс объектов, который транслирует запросы к компоненту в вызовы обычных процедур. У компонентов может быть несколько интерфейсов. В модели размещения отображается топология расположения компонентов по узлам вычислительной сети. Технологическая сеть объектно–ориентированного проектирования ЭИС включает следующие операции: анализ системных требований, логическое проектирование, физическое проектирование, реализация. Рассмотрим подробнее эти операции. Анализ системных требования к ЭИС На входе этапа анализа системных требований используется описание организационно-экономической системы, полученное в ходе работ по анализу и проектированию БП. Эти материалы содержат описание организационной структуры, структуры материальных, финансовых, информационных потоков, которое может быть выполнено либо с помощью традиционных средств графического отображения, либо с помощью определенных методологий бизнес-реинжиниринга (например, с помощью объектно–ориентированной методологии). ТС анализа системных требований к ЭИС имеет следующий вид. Рис. 8. ТСП анализа системных требований к ЭИС Так, в объектно-ориентированной (ОО) методологии анализа и проектирования предусматриваются: • описание БП как прецедентов использования, актерами которых служат внешние участники БП (клиенты, поставщики). • задание порядка разработки и автоматизации БП в соответствии с определенными критериями, например, наибольшим эффектом для заказчика, простотой и быстротой разработки. • неформальное словесное описание БП. Структура основных БП и их взаимодействий описывается в соответствии с требованиями модели классов объектов. Анализ системных требований начинается с идентификации основных прецедентов использования и объектов-сущностей, которые будут применяться в ИС. Работы по идентификации прецедентов использования классов объектов-сущностей, как правило, выполняются параллельно. В случае ОО оформления результатов предпроектного обследования данная работа упрощается в силу однозначности соответствия БП и прецедентов использования ЭИС, бизнес-объектов и объектов сущностей. Разработка диаграммы прецедентов использования ЭИС предполагает выделение тех последовательностей транзакций, которые будут автоматизировать БП. При этом определяются основные пользователи-актеры, взаимодействующие с прецедентами использования. Разработка диаграммы классов объектов предполагает задание состава атрибутов и определение характера взаимосвязей классов объектов. Разработка диаграммы состояний объектов осуществляется только для классов объектов со сложным поведением. При этом рассматриваются все прецеденты использования, в которых объекты данного класса используются и меняют свои состояния. Разработка диаграммы пакетов осуществляется путем группировки классов объектов по подсистемам. На этапе анализа системных требований определяется состав пакетов, относящихся к пакету «Проблемная область». При этом выделяются функциональные пакеты, которые объединяют классы объектов, реализующие функции управления, и базовые пакеты с нормативно-справочной информацией, общие для функциональных пакетов. Логическое проектирование ЭИС На этапе логического проектирования ЭИС осуществляются детализация моделей прецедентов использования, классов объектов, состояний пакетов и разработка моделей взаимодействия объектов и деятельностей, которые определяют характер методов (процедур) обработки пакетов. Детализация диаграммы прецедентов использования предполагает разработку основных и альтернативных потоков событий, которые могут быть представлены самостоятельными диаграммами прецедентов использования. Кроме того, могут быть выделены прецеденты использования, расширяющие набор функций основных прецедентов, или из нескольких прецедентов использования могут быть выделены общие функции в самостоятельные прецеденты. При этом соответственно задаются отношения расширения и использования. Рис 7. Технологическая схема логического проектирования Детализация диаграммы классов объектов выполняется путем уточнения классов-объектов. Интерфейсные классы объектов соответствуют актерам прецедентов использования, а управляющие классы объектов – координирующим функциям обработки объектов-сущностей. Уточнение диаграммы состояний объектов выполняется в связи с детализацией диаграммы прецедентов использования и диаграммы классов объектов. Разработка диаграммы взаимодействия выполняется для каждого прецедента использования с учетом построенных диаграмм классов объектов и состояний. В частности, сообщение от одного объекта к другому в диаграмме взаимодействия должно соответствовать событию, вызывающему переход состояния объекта получателя сообщения в диаграмме состояний. Аналогично внешнее событие в диаграмме взаимодействий, вызываемое актером, соответствует событию, осуществляющему переход состояния объекта в диаграмме состояний. Разработка диаграммы деятельностей уточняет характер взаимодействия объектов не в одном, а в нескольких прецедентах использования. Если диаграммы взаимодействий объектов формируют набор методов обработки объектов, то диаграммы деятельностей дают спецификацию алгоритмов для последующего программирования этих методов. Детализация диаграммы пакетов связана с уточнением состава классов объектов-сущностей и появлением интерфейсных и управляющих классов объектов. Например, интерфейсные и управляющие классы объектов могут быть выделены в самостоятельные обеспечивающие пакеты. Физическое проектирование На этапе физического проектирования происходит детализация диаграмм классов объектов и пакетов с позиции их реализации в конкретной программно-технической среде. Рис. 9. Технологическая схема физического проектирования Спецификация физической реализации диаграммы классов объектов предусматривает определение форматов данных для атрибутов и методов реализации отношений (ключей, указателей, процедур) классов объектов. Детализация диаграммы пактов предполагает разработку обеспечивающих компонентов: базы данных, управления задачами, вспомогательных функций. Разработка диаграммы компонентов и диаграммы размещения компонентов реализует клиент-серверную технологию и определяет схему размещения компонентов по узлам ВС. Реализация ЭИС На этапе реализации ЭИС осуществляются кодогенерация классов объектов, программирование процедур методов классов объектов, наполнение БД и размещение компонентов по узлам ВС. Рис. 10. Технологическая схема реализации ЭИС Генерация классов объектов в конкретной ОО программной среде (С++, VB), выбираемой из универсума ОО ЯП, осуществляется на основе диаграммы классов объектов. Генерация шаблонов процедур методов класса объектов в конкретной ОО программной среде, выбираемой из универсума ОО ЯП производится на основе диаграммы взаимодействий объектов. Программирование процедур методов класса объектов с помощью ОО ЯП выполняется на основе шаблонов процедур методов классов объектов по спецификациям диаграмм деятельностей и состояний объектов. ПРОТОТИПНОЕ ПРОЕКТИРОВАНИЕ ЭИС (RAD – ТЕХНОЛОГИИ) С появлением КЭИС, базирующихся на архитектуре «клиент-сервер», появляется возможность ускорения разработки приложений за счет параллельного создания клиентской и серверной частей. Однако реально использовать преимущества такой архитектуры оказалось очень непросто из-за резко возросшей сложности создания приложений в гетерогенной среде. Кроме естественной сложности создания приложений в неоднородной среде существует тенденция к усложнению приложений с течением времени. В этих условиях процесс разработки ИС традиционным каскадным методом может затянуться на длительное время, а соответствие результата потребностям заказчика не гарантируется. Основное желание заказчика ЭИС – получить готовое приложение высокого качества быстро и при минимальных затратах на его разработку. Кроме того, вкладывая значительные средства на создание системы, заказчики желают контролировать процесс разработки. Критерием качества должно быть наиболее полное удовлетворение требований заказчиков на момент введения системы в эксплуатацию. Одним из условий обеспечения высокого качества создаваемых ИС является активное вовлечение конечных пользователей в процесс разработки предназначенных для них интерактивных систем, что нашло отражение в методологии прототипного проектирования. Ядром этой методологии является быстрая разработка приложений RAD. При создании сложных ЭИС пользователям необходимо работать совместно с проектировщиками на всем протяжении периода разработки, что достигается использованием технологии прототипного проектирования. Данная технология обеспечивает на ранней стадии реализацию действующей интерактивной модели системы (системы-прототипа), позволяющей наглядно продемонстрировать пользователю будущую систему, уточнит его интерфейсные элементы: формы ввода сообщений, меню, выходные документы, структуру диалога, состав реализуемых функций. В процессе работы с системой-прототипом пользователь реально осознает возможности будущей системы и определяет наиболее удобный для него режим обработки данных. Осуществляются проверка принципиальных проектных решений по составу и структуре ЭИС и оценка основных ее эксплуатационных характеристик (замечания, дополнения). Согласованная система-прототип служит спецификацией для дальнейшей разработки ЭИС, что позволяет на ранних этапах проектирования выявить возможные ошибки проектирования и определить параметры будущей системы. Все приемы для быстрой разработки приложений служат одновременно для обеспечения высокого качества продукта и низкой стоимости разработки. К числу этих приемов относятся: 1) разработка приложения итерациями; 2) необязательность полного завершения работ на каждом из этапов жизненного цикла для начала работ на следующем; 3) обязательное вовлечение пользователей в процесс проектирования и построения системы; 4) высокая параллельность работ; 5) повторное использование частей проекта; 6) необходимое применение CASE-средств, обеспечивающих техническую целостность на этапах анализа и проектирования; 7) применение средств управления конфигурациями, облегчающее внесение изменений в проект и сопровождение готовой системы; 8) использование автоматических генераторов (мастеров); 9) использование прототипирования, позволяющего полнее выяснить и удовлетворить потребности конечного пользователя; 10) тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа. Каждое из перечисленных положений в отдельности способствует повышению скорости, улучшению качества, но только их совместное использование вызывает качественные изменения в процессе разработки. Главная задача – как можно скорее показать пользователям готовый продукт. Для определения состава, объема работ, необходимого числа разработчиков, распределения работ между участниками используется автоматизация планирования. Основная проблема - определение момента перехода на следующий этап. Для ее решения вводят временные ограничения на каждый этап жизненного цикла. Переход на следующий этап выполняется даже в том случае, если предыдущий не закончен, а отведенное время истекло. Для реализации технологии типового проектирования необходимо применять высокоуровневые инструментальные средства, которые позволяют быстро преобразовывать прототип системы в функционирующую версию и внести в нее в дальнейшем необходимые изменения. Такие инструментальные средства можно условно разделить на два класса: инструменты быстрой разработки приложения в развитых СУБД (класс DEVELOPER) и интегрированные инструменты быстрой разработки приложений (класс BUILDER). К инструментам этих классов можно отнести генераторы компонентов приложений: • генераторы таблиц БД; • генераторы форм ввода-вывода; • генераторы запросов; • генераторы отчетов; • генераторы меню. Такие генераторы существуют почти во всех СУБД, как в персональных Access, FoxPro, так и в окружении промышленных серверов БД (Oracle, Informix). Отличительной чертой класса BUILDER является то, что инструменты данного класса легко интегрируются с CASE-средствами и представляют собой единую среду быстрой разработки приложения. К интегрированным инструментам этого класса можно отнести Delphi, Builder C++. Жизненный цикл создания ЭИС на основе RAD-технологии предполагает после формирования ТЗ и декомпозиции системы независимую разработку подсистем с последующей сборкой, тестированием и внедрением комплексной ЭИС. Существует два базовых варианта использования организационно-технологического процесса проектирования с использованием систем прототипов. В первом варианте создание системы-прототипа используется для лучшей спецификации требований к разработке ЭИС, после разработки которых сам прототип оказывается ненужным. В этом случае традиционно разрабатывается Постановка задачи, документация которой является спецификацией системы-прототипа. После демонстрации пользователю и доработки прототипа разрабатывается новая Постановка задачи, которая служит основой создания действующей ЭИС. В соответствии с технологической сетью проектирования на основе ТЗ и описания предметной области выполняется разработка постановки задачи. Вторая технологическая операция с преобразователем служит для разработки системы-прототипа на основе спецификаций постановки задачи и выбранного средства из универсума средств быстрой разработки приложений. Выходом из операции является готовое приложение-прототип. Результаты работы приложения–прототипа демонстрируют заказчику, после чего формируются замечания и уточненные требования к ЭИС и происходит доработка прототипа. На основании результатов доработки прототипа формируется новая постановка задачи. Технологическая операция с преобразователем предназначена для разработки действующего программного приложения. Основной недостаток этого варианта – неэффективное использование системы-прототипа (не используются в дальнейшем). Второй вариант предполагает итерационное развитие системы-прототипа в готовый для эксплуатации программный продукт. Итерации разработки системы-прототипа включают создание/модификацию системы-прототипа, ее демонстрацию пользователю и согласование, разработку новых спецификаций-требований к системе, новую модификацию, пока не будет создано новое приложение. Документацию компонентов системы-прототипа непосредственно составляют спецификации, которые являются требованиями к программной реализации системы и определяют характер взаимоотношений с заказчиком на этапе сдачи готовой системы. На основе ТЗ, описания предметной области, выбранного средства быстрой разработки выполняется разработка системы-прототипа. Выходом операции является готовое приложение-прототип. Результаты работы приложения-прототипа демонстрируются заказчику, после чего либо формируются замечания и уточненные требования к ЭИС и происходят доработка прототипа и разработка новых спецификаций-требований, либо система-прототип полностью удовлетворяет требованиям, и она документируется и сдается в виде готового программного приложения с соответствующей документацией. Технологическая сеть проектирования на стадии техно-рабочего проектирования имеет вид. Рис. 11 ТСП на стадии техно-рабочего проектирования имеет вид. Вопросы для самоконторля 1. Дайте определениеCASE-технологии проектирования ЭИС. 2. Какова структура CASE-средств? 3. Какие классы CASE-средств существуют? 4. Какие диаграммы выступают в качестве инструментальных средств функционально-ориентированного анализа проектирования? 5. Определите основные понятия и элементы диаграммы потоков данных? 6. Определите основные понятия и элементы диаграммы функциональных спецификаций. 7. Определите основные понятия и элементы системной структурной диаграммы. 8. Какие диаграммы выступают в качестве инструментальных средств объектно-ориентированного анализа проектирования? 9. Определите основные понятия и элементы диаграммы прецедентов использования. 10. Определите основные понятия и элементы диаграммы классов. 11. Определите основные понятия и элементы диаграммы состояний. 12. Определите основные понятия и элементы диаграммы взаимодействия объектов. 13. Определите основные понятия и элементы диаграммы деятельностей. 14. Определите основные понятия и элементы диаграммы пакетов. 15. Определите основные понятия и элементы диаграммы компонентов и размещения. 16. В чем заключается сущность прототипной (RAD) технологии. 17. Дайте классификацию инструментальных средств быстрого прототипирования ЭИС? ЛЕКЦИЯ 9 ТИПОВОЕ ПРОЕКТИРОВАНИЕ ЭИС ОСНОВНЫЕ ПОНЯТИЯ И КЛАССИФИКАЦИЯ МЕТОДОВ ТИПОВОГО ПРОЕКТИРОВАНИЕ Методы типового проектирования ЭИС предполагают создание системы из готовых покупных типовых элементов (типовых проектных решений). Для этого проектируемая ЭИС должна быть декомпозируема на множество составляющих компонентов (подсистем, комплексов задач, программных модулей), для которых подбираются и закупаются имеющиеся на рынке типовые проектные решения. Далее закупленные типовые элементы, как правило, включающие программные продукты, настраиваются на особенности конкретного предприятия или дорабатываются в соответствии с требованиями проблемной области. Под типовым проектным решением (ТПР) понимают представленное в виде проектной документации, включая программные модули, проектное решение, пригодное к многократному использованию. В качестве проектного решения может выступать реализация как отдельных компонентов ЭИС (программных модулей, функциональных задач, АРМ, локальных БД), так и взаимосвязанных комплексов компонентов (функциональных и обеспечивающих подсистем, ЭИС в целом). Типовые проектные решения также называют тиражируемыми продуктами. В зависимости от уровня декомпозиции системы различают элементный, подсистемный и объектный методы типового проектирования. При элементом методе типового проектирования ЭИС в качестве типового элемента системы используется типовое решение по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному). Задача Информационное обеспечение Программное обеспечение Техническое обеспечение Математическое обеспечение Организационное обеспечение БД, файлы ОС, СУБД, ЯП На какой технике Математические методы Методические материалы по работе персонала Рис. 12. Виды элементов типового проектирования . Сущность применения ТПР при элементом методе заключается в комплектации ЭИС из множества ТПР по отдельным разрозненным задачам. Если данного множества недостаточно для того, чтобы спроектировать систему, необходимые модули дорабатываются вручную. Достоинство элементного метода типового проектирования ЭИС связано с применением модульного подхода к проектированию и документированию ЭИС. К недостаткам применения этого метода относятся большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимость ТПР, а также плохая адаптивность (настраиваемость) элементов к особенностям предприятия. Следствием перечисленных недостатков являются большие затраты времени на доработку и комплексирования ТПР отдельных элементов, сопоставимые со временем ручного оригинального проектирования ЭИС. В настоящее время элементные ТПР в основном применяются в качестве библиотек методо-ориентированных программ (библиотек классов объектов), например, при разработке графических интерфейсов, применении вычислительных и служебных функций. При использовании подсистемного метода ТП ЭИС в качестве элементов типизации выступают отдельные подсистемы, которые обеспечивают функциональную полноту, минимизацию внешних информационных связей, параметрическую настраиваемость, альтернативность схем в пределах значений входных параметров. При этом достигается более высокая степень интеграции типовых элементов ЭИС. ТПР для функциональных подсистем реализуются в виде ППП, которые позволяют осуществить: • модульное проектирование; • параметрическую настройку программных компонентов на различные объекты управления; • сокращение затрат на проектирование и программирование взаимосвязанных компонентов; • хорошее документирование отображаемых процессов обработки информации. Вместе с тем адаптивность ТПР в виде функциональных ППП недостаточна с позиции непрерывного инжиниринга деловых процессов. Также возникают проблемы в комплексировании ППП разных функциональных подсистем, особенно в случае использования ППП нескольких производителей программного обеспечения, для которых, как правило, характерна их информационная, программная, техническая несовместимость между собой при построении единой КЭИС. Пример (1С). При объектном методе ТП ЭИС в качестве типового элемента используется типовой проект для объектов управления определенной отрасли, который включает полный набор функциональных и обеспечивающих подсистем ЭИС. Современные типовые проекты отличаются: • открытостью архитектуры, позволяющей устанавливать проекты на разных программно-технических платформах; • масштабируемостью, допускающей конфигурацию ЭИС для переменного числа рабочих мест; • конфигурируемостью, позволяющей выбирать подмножество компонентов, которые необходимы для конкретной проблемной области и параметрически настраиваются на особенности объекта управления. Преимущество объектного метода перед подсистемным заключается в комплексируемости всех компонентов за счет методологического единства и информационной, программной, технической совместимости компонентов. Примеры: «Галактика», «Парус». Метод типового проектирования реализуется параметрически-ориентированным и модельно-ориентированным подходами. ПАРАМЕТРИЧЕСКИ – ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС При проектировании ЭИС на основе параметрической настройки ППП последний рассматривается как «черный ящик». На вход ППП подаются параметрический (ПП) и информационный (ИП) потоки, а выходом служит результат работы пакета (РП). ППП включает следующие блоки: функционирования, обработки параметров, адаптации. Рассмотрим взаимосвязь основных потоков и компонентов ППП. Информационный поток представляет собой исходные данные, которые обрабатываются и необходимы для получения результатов работы пакета. ИД для функционирования пакета могут быть представлены в виде различных документов, причем как бумажных, так и электронных. Результаты работы пакета могут быть представлены в виде отчетов, графиков, электронных документов, которые могут направляться во внешнюю среду. Блок функционирования обрабатывает ИД и формирует результаты работы пакета. Графически блок функционирования представляется деревом программных модулей, которые автоматизируют функции обработки данных. Параметрический поток – информация, необходимая для настройки пакета на конкретные условия функционирования. ПП включает информацию, которая задается один раз при установке этого пакета. Изменяя параметры, можно включать и выключать какие-либо модули или влиять на их режим работы. Для архитектуры «клиент-сервер» в ПП описываются пользователи и их уровни доступа к программным модулям и ко всему пакету в целом. Параметрическая информация предоставляется: • в справочниках (классификаторах с задаваемым числом уровней классификации, например, в справочниках номенклатурных изделий и услуг, видов расчетов, валют); • в таблицах описаний конфигурации программных модулей (например, условия включения/выключения модуля, режимы ручного и автоматического обновления полей данных, методы расчетов показателей). Блок обработки параметров представляет собой совокупность специальных модулей по интерпретации значений параметров. В частности блок обработки параметров переносит установки пользователя непосредственно в прикладные программы и используемую БД. Проводимая настройка ППП позволяет использовать его для широкого класса объектов. Блок адаптации взаимодействует с блоком функционирования и может добавлять модули и модифицировать их. Необходимость применения блока адаптации связана с потребностями доработки программных модулей ППП под воздействием внешних условий функционирования. Поэтому в состав ППП включается инструментарий адаптации существующих типовых проектных решений. В качестве таких инструментов, доступных квалифицированному пользователю (не программисту), используются: • генераторы программ ЭИС на основе языковых средств RAD-технологии; • макроязыки проектирования и настройки типовых модулей. Сущность применения метода типового проектирования ЭИС на основе параметрической настройки ППП заключается в определении критериев оценки ППП, оценке множества ППП-претендентов по сформулированным критериям, выбору и закупке ППП с наивысшей интегральной оценкой, а далее – собственно настройке параметров и возможной доработке закупленного ППП. Технологическая сеть проектирования с помощью параметрической настройки функционального ППП включает следующие операции. 1. Определение критериев оценки функционального ППП. 2. Оценка рынка и закупка функционального ППП. 3. Настройка и внедрение ФППП. 4. Обучение персонала. 5. Эксплуатация ФППП. 6. Адаптация к внешним изменениям. Определение критериев оценки функционального ППП Перечень критериев выбора ППП для конкретной подсистемы определяется в зависимости от следующих характеристик проблемной области: срока разработки ИС, денежных ресурсов, технической оснащенности ОУ, существующих и функционирующих ППП, программного, сетевого оснащения. Анализ технической документации по ППП позволил выявить перечень критериев, характеризующих в различных аспектах применение ППП, которые можно сгруппировать в подмножества и разработать для них систему классификации. В частности, выделяют следующие группировки критериев, характеризующие ППП: 1. Назначение и возможности пакета: 1.1. Предметная область использования. 1.2. Степень обеспечения функций управления. 1.3. Общий или специализированный. 1.4. Коллективного или индивидуального использования. 1.5. Возможности оптимизации расчетов. 1.6. Возможность взаимозаменяемости ТС. 1.7. Универсальность. 1.8. Применимость для пользователей различной квалификации. 2. Отличительные признаки свойства и пакета: 2.1. Входной язык. 2.2. Управляющий язык. 2.3. Способ хранения, доступа данных. 2.4. Способы проверки данных. 2.5. Диалоговый режим. 3. Требования к программным и техническим средствам: 3.1. Вычислительная система. 3.2. Объем ОП. 3.3. Тип ОС. 3.4. Совместимость с СУБД; 4. Документация пакета: 4.1. Общее руководство по использованию. 4.2. Руководство системного и программного уровня. 5. Факторы финансового порядка: 5.1. Затраты на приобретение пакета. 5.2. Затраты на установку пакета, обучение персонала. 5.3. Экономическая эффективность использования пакета. 6. Особенности установки, эксплуатации пакета: 6.1. Объем работ по установке. 6.2. Время установки. 6.3. Трудоемкость организации информационной базы. 7. Помощь поставщика по установке и поддержанию пакета: 7.1. Обучение персонала. 7.2. Участие поставщика при внедрении пакета. 7.3. Переход от старой системы к новой. 7.4. Корректировка системы ошибок. 7.5. Внесение модификаций. 8. Оценка качества пакета и опыт его использования: 8.1. Источник появления. 8.2. Число и характер переделок пакета. 8.3. Число организаций, пользующихся пакетом. 8.4. Сравнение с аналогичными пакетами. 9. Перспективы развития пакета: 9.1. Подключение новых функциональных возможностей. 9.2. Расширение интерфейса, переход на совершенные ТС. 9.3. Совместимость со старой версией. Каждая из групп критериев, в свою очередь, разбивается на некоторое подмножество критериев, более полно раскрывающих каждый из выделенных аспектов анализа выбираемых ППП. Оценка рынка функциональных ППП Осуществляется по программным средствам, имеющимся на рынке, на основе выделенных групп критериев и может производиться по методик оценки эргономических характеристик продуктов. По данной методике предполагается усреднение оценок группы экспертов, оценивающих ППП. Для каждой характеристики на основе оценок нескольких экспертов по 10 бальной шкале устанавливаются средневзвешенные весовые коэффициенты значимости, которые нормируются внутри группы: , где - комплексный валовой коэффициент; – комплексный нормированный весовой коэффициент; – номер комплексного весового коэффициента; – количество комплексных весовых коэффициентов. – единичный весовой коэффициент; – единичный нормированный весовой коэффициент; – номер единичного весового коэффициента; – кол-во единичный весовой коэффициентов, входящих в i-ый комплексный весовой коэффициент; По каждому ППП осуществляется экспертная оценка в разрезе отдельных характеристик по 10-бальной шкале. Далее оценки автоматически умножаются на весовые коэффициенты и нормируются внутри группы: , где – взвешенная оценка i-й единичной характеристики; – среднее значение бальных оценок экспертов i-й характеристики; – среднее значение весовых коэффициентов i-й характеристики. – взвешенная оценка i-й комплексной характеристики. - интегральная оценка по ППП. Взвешенные оценки характеристик суммируются по группам и в целом по ППП. ППП, получивший наибольшую взвешенную характеристику, является претендентом на принятие решения о закупке. В результате принятия решения о закупке фирмой-разработчиком заключается договор о поставке и сопровождении ППП вместе с технической документацией. Настройка функциональности ППП Настройка ППП по технической документации начинается с заполнения нормативно-справочной информации, необходимой для выполнения функций объекта, и далее происходит последовательное заполнение всех справочников. На вход преобразователя поступает информация предметной области, необходимая для заполнения справочников. Выходом являются заполненные справочники. Далее происходит настройка модулей ППП, которая заключается в параметризации функций пакета. В качестве входной информации используются данные предметной области, а также техническая документация пакета. Результатом настройки модулей является пакет прикладных программ, готовый к эксплуатации. Обучение персонала Эта операция необходима для ознакомления, выработки навыков использования ППП. На вход поступает техническая документация пакета и сам ППП. Результатом обучения персонала являются прохождение различных контрольных мероприятий (тестов, экзаменов) и получение документов, свидетельствующих о готовности персонала к эксплуатации ППП. Эксплуатация ППП Операция отражает автоматизированное выполнение функции управления с помощью ППП. Входом данной технологической являются: информация проблемной области и ППП. Выходом – статистика работы пакета, которая используется для анализа эффективности функционирования ППП и выработки рекомендаций по его перенастройке. Адаптация типовой конфигурации ППП с использованием инструментальных средств На вход поступают операции: 1) описание внешних изменений функционирования ППП; 2) техническая документация ППП; 3) инструментальные средства адаптации ППП. Выходом данной технологической операции является новая, адаптированная версия ППП и обновленная техническая документация. При изменении условий функционирования используются следующие инструменты адаптации ППП: • генераторы отчетов; • макроязыки настройки функций ППП; • встроенные ЯП. Таким образом, параметрически-ориентированное проектирование ЭИС на основе использования ППП по сравнению с оригинальным проектированием дает возможности более быстрого и гибкого внедрения ИС. Однако существует ряд проблем, сдерживающих распространение данной технологии. К ним можно отнести: • психологические и организационные трудности внедрения ППП; • достаточно высокую стоимость приобретения ППП и обучения персонала; • отсутствие глобальной модели объекта управления, что ведет к затратам по увязке различных ППП в рамках КЭИС. МОДЕЛЬНО – ОРИНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС Сущность модельно-ориентированного проектирования ЭИС сводится к адаптации компонентов типовой ЭИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ЭИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними. Ядром типовой ЭИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специальной базе метаинформации–репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ЭИС сводится, прежде всего, к построению модели проблемной области и ее периодической корректировке. Для моделирования проблемной области и последующих конфигураций ИС из отдельных компонентов (программных модулей) используется специальный программный инструментарий (SAP Business Engineering Workbench, BAAN Enterprise Modeler). Несомненным достоинством применения модельно-ориентированных компонентных систем перед CASE – технологиями является накапливание опыта проектирования ИС для различных отраслей и типов производства в виде типовых моделей, которые поставляются вместе с программным продуктом в форме наполненного репозитория. Таким образом, вместе с программным продуктом пользователи приобретают базу знаний об эффективных методах организации и управлении БП, которые можно адаптировать в соответствии со спецификой конкретного экономического объекта. Репозиторий КЭИ, использующей модельно-ориентированную технологию проектирования, в общем случае содержит метаинформацию базовой модели функциональности типовой системы, типовой модели определенных классов ЭИС и модели предприятия, получаемой на основе базовой или типовых моделей. Базовая модель репозитория содержит описания БФ, БП, БО, организационной структуры, которые используются в программных модулях типовой ЭИС. при этом большое значение в базовой модели имеет задание бизнес-правил поддержания целостности ИСЮ определяющих условия проверки корректности совместного применения различных компонентов ЭИС. Таким образом, многообразия и гибкость определения БП и соответствующих конфигураций ИС задаются с помощью набора бизнес-правил. Типовые модели описывают конфигурации ИС для определенных отраслей (автомобильной, нефтегазовой) или типов производства (единичного, серийного). Модель предприятия (проблемной области) строится путем привязки фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия. Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. Далее по модели предприятия автоматически осуществляется конфигурация ИС, в ходе которой выполняется семантический контроль по бизнес-правилам. Модель предприятия включает: модель функций, модель процессов, модели объектов, модель организационной структуры, модели бизнес-правил. Модель функций Модель функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия. На первом уровне иерархии обычно указываются основные виды функциональных подсистем: сбыт, производство, сервис, финансы. На следующем уровне иерархии для каждой функциональной подсистемы показываются функциональные модули: планирование, потребность в материалах. Для функциональных моделей задаются наборы бизнес-функций, для каждой из которых в дальнейшем определяются бизнес-процессы. Например, для функционального модуля «закупки» определяются бизнес-функции: оформление договоров, оформление заказов, выписка счетов. Модель процессов Модель БП отражает последовательность выполнения работ (операций) для функций самого нижнего уровня модели бизнес-функции, которая позволяет провести конфигурацию программных модулей ИС в соответствии с характерными особенностями конкретной проблемной области. Для представления БП используется аппарат сетей Петри, позволяющий отображать управление процессами в зависимости от событий: работа выполняется в том случае, если известно состояние системы. Модели объектов (данных) В модельно-орентированной технологии проектирования ЭИС интегрирование различных БП осуществляется на основе бизнес-объектов (БО). БО – компоненты уровня проблемной области, которые используются в различных приложениях в произвольных комбинациях и не зависят от них. При этом приложение обеспечивает среду для функционирования БО. С одной стороны, БО – это объекты-сущности, например заказы, счета, материалы. С другой стороны, в отличие от обычных объектов-сущностей БО являются самодостаточными, т.е. имеют стандартный интерфейс, написанный на языке описания интерфейсов, с помощью которого БО могут взаимодействовать друг с другом. Например, при оформлении заказа от клиента к поставщику могут использоваться следующие стандартные методы БО: выбор группы изделий в каталоге; просмотр описания изделия; выбор изделия из группы; создание заказа. Модель организационной структуры Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала. Назначение моделирования организационной структуры применительно к ИС заключается в распределении автоматизируемых функций по работникам подразделения и определении полномочий доступа к ИС. В модели БП явно указывается закрепление автоматизируемых функций по подразделениям. Связь модели БП и модели организационной структуры задается через указатели роли, которые могут выполняться различными организационными единицами. Через указатели роли сотрудников устанавливается связь организационной структуры с БП. Указатель роли определяет тип работника, который может выполнять ту или иную работу (экономист, бухгалтер). Для каждой роли определяются полномочия выполнения функций, права доступа к информации, должностные инструкции. При назначении работы конкретному работнику всегда осуществляется проверка роли, которую он может выполнять. Если при этом тип конкретного работника не соответствует роли, то последний не получает доступа к выполнению работы. Модели бизнес-правил Бизнес-правила – это специальные сведения в области типовой ЭИС, которые хранятся в репозитории и используются для контроля корректности построенной модели предприятия и процессов конфигурации и эксплуатации ЭИС. Модели бизнес-правил могут быть встроены в бизнес-объекты или выделены в самостоятельные компоненты. Правила целостности модели предприятия Правила целостности используются для проверки согласованности модели предприятия с точки зрения полноты и непротиворечивости бизнес-функций. Например, если присутствует вариант бизнес-функции Прямой поставки, тогда бизнес-функции Обработки заказа на приобретение и Обработки заказа на сбыт должны быть представлены в модели. Правила преобразования моделей бизнес-функций в модели бизнес-процессов Модель БФ может быть автоматически преобразована в модель бизнес-процесса посредством правил преобразования, которые задают соответствие БФ и бизнес-процесса. Например, если был определен вариант БФ Обработки заказа на приобретение с контрактами, необходимо выбрать бизнес-процесс Обработки контрактов. Правила конфигурации (установки параметров) Правила конфигурации используются для присвоения значения параметру в зависимости от его наличия в БФ, БП или их комбинациях. Например, если был определен вариант БФ Обработки заказа на покупку в режиме ЭОД, то значение параметра ЭОД настраивается на «да». Правила установки статических условий Правила установки статических условий осуществляют выбор варианта БП в зависимости от выполнения условия. Если значение условия правила ложно, то данный вариант в процессе эксплуатации не выполняется и на диаграмме процесса соответствующая неактивная ветвь дерева изображается в затененном виде. Например, если БФ оформление аккредитива не используется в фазе внедрения, то запретить процесс оформления. Технологическая сеть модельно-ориентированного проектирования ЭИС В силу сложности комплексной типовой ИС для МО проектирования характерны следующие особенности. 1. Привязка типовой ИС к условиям конкретного экономического объекта осуществляется в результате совместных усилий фирмы-производителя программного продукта и проектной группы предприятия. 2. Консультанты со стороны фирмы-производителя программного продукта принимают участие на всех этапах внедрения системы и, особенно на этапе анализа требований. 3. Возрастает роль руководства предприятия в организации и контроле за созданием ИС. Технологическая сеть МО проектирования ЭИС включает операции: 1) выбор типовой ЭИС; 2) разработка проектной модели; 3) реализация проекта; 4) ввод в эксплуатацию. Выбор типовой ЭИС – анализ требований Внедрение типовой ИС начинается с анализа требований конкретной ОЭ системы предприятия к ЭИС. В частности на основе результатов предпроектного обследования Д1 формируется предварительная модель предприятия Д2, которая объединяет требования к функциональности ИС (множеству автоматизируемых функций) и на основе которой выполняется выбор наиболее адекватного программного комплекса. Данная работа может быть выполнена в рамках проведения предварительного реинжиниринга БП. Возможен и другой вариант анализа требований, которые определяются существующей организацией БП. Во втором случае реально существующая модель предприятия будет адаптироваться на этапе эксплуатации ИС с целью оптимизации функционирования ОЭ системы. Предприятия, внедряющее типовую ИС, стремится выбрать наилучший программный продукт, соответствующий конкретным условиям. Поэтому на этапе выбора типового проекта в конкурсе может участвовать несколько программных продуктов, которые оцениваются не только по рассмотренной методике, но и с позиции реализации прелагаемой модели предприятия. В результате анализа требований выбирается конкретная типовая ЭИС, компоненты которой используются на последующих стадиях внедрения проекта. Рассмотрим стадию Выбора типовой ЭИС более детально. ТС построения предварительной модели предприятия имеет вид: 1. Построение модели БФ. 2. Построение модели БО. 3. Построение модели БП. 4. Построение модели организационной структуры. Сущность операции Построения модели БФ сводится к определению набора БФ, которые должны быть автоматизированы с позиции наибольшего влияния на достижение основных бизнес-целей (БЦ) (критериев эффективности функционирования предприятия) при условии соблюдения ресурсных ограничений. Данная операция выполняется на уровне руководителей предприятия при непосредственном участии консультантов фирм-производителей типовых ИС, которые демонстрируют модели из набора. На выходе операции формируется список выбранных БФ, представленных в графической модели. Далее к построению предварительной модели предприятия подключаются ключевые пользователи предприятия – руководители линейных и функциональных подразделений. Консультанты, опрашивая ключевых пользователей, на основе сформированных БФ, используя референтные модели, строят модели БО, БП и организационной структуры. Причем модель организационной структуры строится с учетом построенных моделей БП и БО, а также существующей организационно структуры. В предварительной модели предприятия ее элементы могут быть представлены достаточно обобщенно, детализация модели предприятия произойдет после выбора типовой ЭИС. После завершения этапа построения предварительной модели предприятия руководство предприятия принимает решение о выборе типовой ИС, модель предприятия которой в наибольшей степени соответствует целям автоматизации и набору остальных критериев. Далее на основе принятого решения выполняется оформление договора с фирмой производителем ТИС о продаже, проведению работ по внедрении, собственно закупка, формирование проектной группы, формирование календарного графика работ. В результате формируется технико-экономическое обоснование и ТЗ на внедрение ТЭИС. Разработка проектной модели предприятия Для МО технологии проектирования ЭИС характерна привязка модели предприятия к функциональности типовой ЭИС, на основе которой в последующем автоматически выполняется конфигурация ИС. Поэтому на входе задаются предварительная модель предприятия, референтная модель функциональности типовой ЭИС и набор бизнес-правил отображения модели, а на выходе формируется проектная модель предприятия, в которой определяются компоненты типовой ЭИС, компоненты других программных продуктов и компоненты, которые должны быть специально разработаны с помощью инструментальных средств. На этапе разработки проектной модели предприятия выполняются следующие работы: 1) инсталляция программного продукта, реализующего типовую ЭИС; 2) проведение обучения проектной команды; 3) привязка модели предприятия к компонентам типовой ИС; 4) проектирование внешних интерфейсов системы. Рассмотрим ТС привязки модели предприятия к компонентам типовой ИС, состоящую из операций: 1) уточнение модели предприятия; 2) привязка модулей ТЭИС к БП; 3) привязка БО к модулям; 4) привязка организационных единиц к модулям БП. В начале разработки проектной модели консультанты по ТИС совместно с проектной группой на основе предварительно построенной модели БФ и референтной модели уточняют модель БФ. Правильность выбора БФ контролируется на основе использования бизнес-правил. Далее осуществляется привязка программных модулей ТЭИС к функциональным блокам модели БП, связанным с моделью бизнес-функций. Для оригинальных компонентов в модели БП задаются спецификации на разработку программных модулей. Корректность выбора БП для БФ и условий привязки и выполнения программных модулей проверяется по бизнес-правилам. В операции Привязки бизнес-объектов к программным модулям характер программных модулей уточняется составом используемых БО. В результате формируется структура используемых БО. В объектно-ориентированном представлении данная операция выполняется путем задания имен методов в определениях классов объектов, в функционально-ориентированном представлении для соответствующих процедур задается список входных и выходных объектов. Корректность привязки контролируется с помощью бизнес-правил. В заключении осуществляется привязка исполнителей процесса (единиц модели организационной структуры) к используемым программным модулям При этом устанавливаются роли исполнителей для выполнения той или иной работы и создаются спецификации интерфейса пользователя. Корректность операции проверяется также с использованием бизнес-правил. Реализация типового проекта ЭИС Реализация типового проекта ЭИС сводится к конфигурации ЭИС и генерации интерфейсов пользователей, т. е. получению готовых для эксплуатации программ функций обработки данных и интерфейсов, а также определения структуры БД. Настройка программного комплекса ТЭИС и генерация интерфейса пользователей осуществляются автоматически на основе бизнес-правил и проектной модели предприятия. В исключительных случаях требуется доработка или создание новых программных модулей, которые производятся с помощью инструментальных средств программного комплекса. Реализация типового проекта предполагает установку следующих параметров: • глобальных параметров; • структуры компании; • структуры основных данных; • функций и процессов; • интерфейсов; • системы отчетов; • системы архивирования; • системы авторизации доступа. ТС конфигурации ЭИС включает операции: 1. Конфигурация программных модулей; 2. Генерация интерфейсов; 3. Настройка таблиц объектов БД; 4. Доработка модулей и интерфейсов. Конфигурация программных модулей осуществляется путем установки параметров по модели БП, которая осуществляется либо автоматически, либо вручную аналогично параметрической настройке отдельных ППП. Настройка таблиц объектов БД осуществляется по определению БО, либо автоматически на основе использования БП, либо вручную путем определения подмножества необходимых атрибутов. Генерация пользовательских рабочих мест (интерфейсов) выполняется автоматически по модели взаимодействий исполнителей и программных модулей (описанию ролей пользователей). Доработка программных модулей или разработка новых программных модулей функций и интерфейсов выполняется на основе определенных ранее спецификаций на доработку программных модулей и интерфейсов с учетом сконфигурированных других программных модулей, структур БД или БО, интерфейсов с использованием специальных языковых средств или других программных инструментов. В завершении стадии реализации осуществляется комплексное тестирование всех компонентов КЭИС. Ввод в эксплуатацию Ввод в эксплуатацию типового проекта осуществляется поэтапно в соответствии с определенным планом. Перед началом эксплуатации должны быть выполнены следующие работы: 1) создание документации конечных пользователей и их обучение; 2) установка программно-технической среды эксплуатации ЭИС; 3) наполнение информацией новых БД или подключение и конвертация существующих БД. В процессе эксплуатации ЭИС осуществляется системная поддержка для устранения возникающих замечаний. Особое внимание на стадии эксплуатации придается развитию проекта ЭИС. Для этого система должна накапливать статистику о характере функционирования ИС, на основе которой происходит технологическая отладка эффективности эксплуатации ЭИС. Важно также осуществлять анализ эффективности организации с помощью ИС БП на основе контроля экономических показателей, который приводит к непрерывному совершенствованию проектной модели предприятия, а, следовательно, к адаптации ЭИС к необходимым изменениям. Вопросы ля самоконтроля 1. В чем заключается сущность типового проектного решения (ТПР)? 2. Какова классификация методов типового проектирования? 3. Определите основные понятия и сущность типового элементного метода проектирования. 4. Определите основные понятия и сущность типового подсистемного метода проектирования. 5. Определите основные понятия и сущность типового объектного метода проектирования. 6. В чем состоит отличие параметрически-ориентированного и модельно-ориентированного подходов к конфигурации типовых ЭИС? 7. Дайте определение функционального ППП. 8. Какова структура функционального ППП? 9. Каковы критерии выбора функционального ППП? 10. В чем заключается сущность параметрической настройки ППП? 11. В чем заключается сущность адаптации ППП? 12. Что такое базовая, референтная, проектная модели предприятия? ЛЕКЦИЯ 10 УПРАВЛЕНИЕ ПРОЕКТИРОВАНИЕМ ЭИС ОРГАНИЗАЦИОННЫЕ СТРУКТУРЫ ПРОЕКТИРОВАНИЯ ЭИС ОБЩАЯ СТРУКТУРА ОРГАНИЗАЦИИ РАБОТ ПО ПРОЕКТИРОВАНИЮ ЭИС Процесс проектирования включает в себя большое количество взаимосвязанных элементов и предполагает построение соответствующей системы правления. В качестве объекта разработки проекта могут выступать либо вся ЭИС для предприятия заказчика, либо отдельная подсистема или совокупность систем, либо отдельные работы (например, установка ВС, оценка эффективности ИС). Проект как вид деятельности проектирующей организации имеет следующие особенности: • направлен на достижение конкретных действий; • включает в себя координированное выполнение взаимосвязанных действий; • имеет ограниченную протяженность во времени с определенным началом и концом; • все проекты в определенной степени неповторимы и уникальны. К причинам, обуславливающим сложность процессов разработки проекта, относятся: • масштабы ЭИС; • взаимосвязь различных по своей природе элементов проекта ЭИС (информационные, программные средства и технические средства обработки информации, экономико–математические модели, специалисты–разработчики); • факторы старения указанных элементов; • длительность процесса проектирования системы; • коллективный характер труда многих специалистов различной квалификации. Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях во времени, денежных средствах, качеству конечных результатов проекта. Управление как процесс характеризуется следующими компонентами: • целью управления; • ограничениями; • объектом и субъектом управления; • контуром управления; • методами и средствами управления. Глобальной целью управления проектированием ЭИС является получение проекта с заданными пользователем параметрами. Ограничения – сроки, требуемые ресурсы. Объект управления – процесс проектирования ЭИС как деятельность коллектива разработчиков системы, состояние используемых ресурсов. Процесс проектирования ЭИС имеет специфические особенности, которые определяют специфику управления проектированием: 1. Процесс проектирования ЭИС по своему характеру является процессом творческим. Поэтому при отсутствии достаточно полного формализованного перечня операций проектирования и состояний проекта в процессе его разработки управление проектированием носит ситуационный характер. 2. Пользователь на этапе разработки системы может изменять требования к качеству системы, срокам и затратам проектирования. Затруднен контроль качества оценки проектных решений (нет общепринятых надежных способов). 3. Стремление разработчиков к индивидуальному характеру труда приводит к невысокой степени организации контроля и координации деятельности сотрудников. Выделение субъекта управления связано с разделением труда в группе специалистов в процессе проектирования. Управление проектными работами может осуществляться на нескольких уровнях: 1. Руководства проектной организацией. 2. Руководства обеспечивающих подразделений (например, планово – производственного отдела). 3. Руководства функциональными подразделениями. 4. Руководителей проектов. 5. Руководителей проектных групп (ответственных исполнителей). На каждом уровне управления проектными работами существует определенное представление о процессе проектирования, частных целях и задачах, что определяется кругом должностных обязанностей, характером выполняемых функций. Управление проектированием, как правило, рассматривают в двух аспектах: организационном и функциональном. В организационном аспекте управление проектированием рассматривается по уровням организационно – административной структуры с соответствующими правами и обязанностями субъектов процесса управления. В функциональном аспекте управление проектированием рассматривается как применение соответствующих методов и средств организации и ведения проектных работ. ОРГАНИЗАЦИОННЫЙ АСПЕКТ Организация работ по проектированию ЭИС определяется порядком взаимодействия между несколькими сторонами, участвующими в этом процессе: пользователем, заказчиком, администратором, разработчиком. Пользователь – это организация или группа подразделений, которые используют результаты обработки информации на ЭВМ. Для ЭИС под пользователем понимают прежде всего административно – управленческий аппарат, для которого создается эта система. Пользователь выполняет следующие функции: 1) формирует исходные данные для проектирования и обработки; 2) определяет состав задач для автоматизации; 3) определяет основные требования к задачам и режим функционирования системы. Заказчик – это ответственное лицо, под которым понимается организация ил подразделение, которое выполняет следующие функции: 1) формирует требования к системе и ее частям; 2) выдает техническое задание, финансирует разработку ЭИС; 3) обеспечивает проведение комплекса мероприятий по ее созданию; 4) проводит внедрение и прием проекта ЭИС. При этом заказчик несет ответственность перед пользователем за соответствие состава и характеристик решаемых задач, режима функционирования ЭИС исходным данным пользователя, правильность использования ресурсов во время проектирования. Администратор – ответственное лицо, которое выполняет эксплуатацию программно–технических средств и информационно–методологического обеспечения ЭИС (технологические и инструкционные карты). Администратор несет ответственность перед пользователем за правильность результатов работы ЭИС и их своевременность, а перед заказчиком и разработчиком – за соблюдение условий эксплуатации, требований к технической документации. Разработчик – это ответственное лицо (организация, подразделение), которое выполняет следующие функции: 1) разрабатывает ЭИС по техническому заданию заказчика; 2) принимает участие во внедрении; 3) осуществляет сдачу проекта заказчику; 4) осуществляет авторское сопровождение проекта. Разработчик несет ответственность перед заказчиком за правильность реализации требований ТЗ на ЭИС, научно–технический уровень разработки, сроки проведения работ, качество проектной документации, правильность расхода денежных средств. Существует несколько типов схем организации работ с участием четырех сторон, выбор которых зависит от объема заказа. Если заказ имеет небольшие размеры по стоимости и по продолжительности работ, то принимают первую схему, в которой в одном лице выступают заказчик, разработчик и администратор. К преимуществу данной схемы можно отнести минимальное кол-во организаций – участников процесса и минимальные сроки и стоимость работ. Однако совмещение в одной организации функций разрабатывающей и принимающей сторон имеет ряд недостатков: отсутствует действенный контроль за научно–техническим уровнем разработки, сроками выполнения работ; не достигается высокий профессиональный уровень разработчиков. Пользователь Исходные данные для проектирования Исходные данные для обработки Результаты обработки данных Заказчик, разработчик, администратор Рис. 13. Схема организации работ для небольших заказов Для больших и сложных заказов применяют схему, согласно которой функции разработчика отделяют от функций заказчика и администратора и выполняются другой организацией. Схема организации работ имеет вид: Пользователь Исходные данные для проектирования Данные для обработки Результаты обработки данных Заказчик, администратор ТЗ, исходные данные для проектирования и финансирования Проектная документация ТП Разработчик Рис. 14. Схема организации работ при наличии сложного заказа К преимуществам данной схемы можно отнести: рациональное распределение функций между сторонами, участвующими в создании и эксплуатации ЭИС; возможность привлечения к разработке специализированных организаций (НИИ, СКБ). Однако эта схема имеет недостатки: 1) отсутствие прямой связи между разработчиком и пользователем, что создает трудности в своевременном получении и детализации исходных данных для проектирования; 2) определенные трудности при приеме проекта в эксплуатацию из-за желания администраторов получить методологическое обеспечение задач, максимально соответствующее идеальным условиям эксплуатации, что в свою очередь, требует больших сроков и объемов по доработке проекта. В том случае, если заказчик – большая организация, которая курирует разработку нескольких проектов ЭИС, применяют следующую схему. Пользователь Данные для обработки Исходные данные для проектирования Администратор Эксплуатационная документация Заказчик ТЗ, исходные данные для проектирования и финансирования Проектная документация ТП Разработчик Рис. 15. Схема организации работ при полном разделении функций участвующих сторон Данная сема характеризуется тем, что на заказчика возлагаются функции сопровождения, заказа и приемки проектов нескольких ЭИС. Преимуществами данной схемы являются: 1) более высокая степень специализации работников, следовательно, более высокий профессиональный уровень; 2) возможность организованного контроля за сроками и качеством работ. Отделение заказчика от разработчика позволяет последнему привлекать к своей работе организации – соисполнителей разных уровней иерархии, что в свою очередь позволяет использовать труд специализированных и профессиональных организаций. Основными документами, регулирующими отношения заказчика и проектировщика, являются ТЗ и договор на проведение работ. Заказчик ТЗ Договор Головная организация Частное ТЗ Частный договор Организация – исполнитель 1-го уровня Положение о взаимодействии соисполнителей Частное ТЗ Частный договор Организация – исполнитель 2-го уровня Рис. 16. Схема организации работ с использованием организаций-исполнителей ОРГАНИЗАЦИОННЫЕ ФОРМЫ УПРАВЛЕНИЯ ПРОЕКТИРОВАНИЕМ ЭИС В общем случае организационная структура управления проектированием регулирует взаимоотношения подразделений и должностных лиц в организации, устанавливает распределение ролей, полномочий и ответственности между ними, порядок функционально – технических связей, возникающих в процессе управления. Формы управления, применяемые в организациях – разработчиках ЭИС, зависят от выполняемых работ. Формирование организационных форм управления осуществляется по функциональному и проектному (целевому) и матричному принципам. Функциональный принцип построения структуры организации используется при выполнении задач проектирования постоянного характера. Для выполнения каждого вида задач (постановки задачи, создание информационного обеспечения) формируются функциональные подразделения из специалистов определенного профиля. Подобная структура организации обладает высокой степенью централизации управления. Встречается весьма редко. Наиболее часто используется проектный принцип. На основе этого принципа формируется организационное подразделение – проектная группа, предназначенная для одноразовой разработки ЭИС. Специалисты проектной группы образуют автономную организационную единицу, руководитель которой имеет соответствующие полномочия и несет полную ответственность за результаты деятельности проектного коллектива, который после выполнения работ может быть расформирован. Матричное построение организационных структур предполагает формирование в организации – разработчике ЭИС из специалистов функциональных подразделений проектных групп для разработки конкретных проектов. При этом специалисты не теряют принадлежности к соответствующему функциональному подразделению и находятся в двойном подчинении: у руководителя проекта (ответственность по проекту) и у руководителя функционального подразделения (организационная ответственность). Проект ЭИС состоит из разнородных элементов: информационных, программных, технических, поэтому возникает объективная потребность в разделении труда в коллективе разработчиков. Разделение , как правило, осуществляется на основе одного из двух следующих принципов: пооперационного (технологического) или подсистемного. Разделение труда на пооперационной основе базируется на свойстиве декомпозиции процесса проектирования ЭИС на технологические операции, которые выполняются отдельными специалистами. В этом случае требуется четкая регламентация взаимодействий между операциями (системный аналитик, программист, оператор). Разделение труда на технологической основе затруднительно по следующим причинам: 1) невысокий уровень типизации технологических операций проектирования ЭИС; 2) невозможность получения объективно – точной качественной оценки промежуточных результатов проектирования; 3) отсутствие объективных критериев нормирования труда специалистов; 4) низкая степень стандартизации и унификации компонентов ЭИС. Подсистемное разделение труда базируется на свойстве декомпозируемости проекта на подсистемы, каждая из которых независимо от числа технологических операций проектирования разрабатывается отдельной группой специалистов. В этом случае предполагаются стандартизация и унификация интерфейсов между подсистемами на каждом этапе процесса проектирования ЭИС Это приводит к системной специализации разработчиков (специалисты по экспертным системам., техническому обеспечению). На практике при разделении труда в проектных коллективах возможно использование обоих вышеназванных принципов. Выбор целесообразного разделения труда зависит от ряда факторов, влияющих с разной степенью на решение проблемы. Наиболее существенными являются следующие: 1) потенциал коллектива разработчиков; 2) объем и сложность разрабатываемых проектов; 3) технология проектирования системы; 4) модель жизненного цикла системы. Степень влияния каждого фактора в конкретных случаях приводит к большому разнообразию разделения труда и связанных с ним организационных форм управления проектированием ЭИС. При этом, как правило, используются три типовые организационные структуры проектной группы: открытая, централизованная, децентрализованная. Открытая организационная структура отличается тем, что закрепленного организационного распределения обязанностей нет. Каждый член коллектива является неформальным руководителем на этапе разработки системы, где он более других квалифицирован. Обязанности на отдельных этапах распределяются между разработчиками в соответствии с их знаниями, опытом, способностями. Административный руководитель в группе осуществляет, как правило, следующие действия: 1) взаимоотношения с заказчиком; 2) планирование и контроль сроков; 3) распределение ресурсов и координация работ; 4) отчетность перед руководством организации. Такая организационная группа формируется из 7–10 человек для творческих решений задач и рекомендуется для выполнения работ на ранних стадиях проектирования системы – проведения обследования предметной области, анализе и разработке концепции проекта. Такая численность проектировщиков дает возможность полного обмена информацией между ними, а также возможность иметь относительно невысокие затраты на администрирование. Открытая структура позволяет варьировать количество разработчиков, привлекая для выполнения работ более квалифицированных специалистов, что способствует повышению качества проекта. Централизованная организационная структура проектной группы предусматривает в качестве руководителя специалиста высокой квалификации, осуществляющего администрирование и техническое руководство. Он же является основным посредником между группой, заказчиком проекта и внешними организациями. Данная структура наиболее приемлема для решения задач, имеющих жесткие ограничения по срокам и затратам на разработку системы. Численность такой группы до 7 человек. Особенностью является четкое распределение функций и полномочий между специалистами. Результаты работы каждого предоставляются в распоряжение всех участников процесса проектирования. Недостаток заключается в отсутствии проявления инициативы конкретных исполнителей. Примером централизованной организационной структуры может служить группа главного специалиста. В такой роли может выступать главный конструктор проекта. В его группу входят главный специалист, его заместитель, аналитики (постановщики задач), программисты. Главный специалист выполняет следующие функции: 1) отвечает за разработку концепции проектируемой ЭИС и соответствие проектных решений требованиям пользователя; 2) выполняет совместно с аналитиками декомпозицию системы; 3) контролирует сроки проектирования и полноту проектной документации; 4) несет ответственность за разработку проекта во всех аспектах. Главный специалист осуществляет непосредственное управление проектом и определяет стратегию проектирования. Заместитель главного специалиста ориентирован на тактические вопросы проектирования ЭИС, на анализ альтернатив в разработке проектных решений. Заместитель находится в курсе всех вопросов проекта и любой момент может взять на себя роль руководителя. Аналитики и программисты осуществляют непосредственно разработку частей проекта. Достоинствами данной организации труда являются применение нисходящего проектирования, повышение качества проектных решений, интенсивное обучение и эффективное использование начинающих разработчиков. В этом случае предъявляются высокие требования к квалификации и организаторским способностям главного специалиста. Децентрализованная организационная структура имеет свойство двух вышеизложенных структур. Данная организационная структура применяется в коллективах с большой численностью сотрудников (более 10), осуществляющих проектирование больших ЭИС, декомпозируемых на подсистемы (контуры, модули) и комплексы задач. В этом случае руководитель проекта осуществляет управление группой старших специалистов, отвечающих за разработку крупных частей системы, а те, в свою очередь, осуществляют руководство младшими специалистами, которые поддерживают между собой горизонтальные связи в процессе проектирования. Как правило, подгруппы объединены по технологической специализации. Вопросы для самоконтроля 1. Каковы особенности разработки проекта как вида деятельности? 2. Каковы стадии жизненного цикла проекта как вида деятельности проектной организации? 3. Что понимается под управлением проектом? 4. Каков состав лиц, участвующих в разработке и эксплуатации проекта ЭИС? 5. Перечислите принципы разделения труда в проектных организациях. 6. Определите особенности централизованной и децентрализованной организационной структуры проектной группы. ЛЕКЦИЯ 11 ПЛАНИРОВАНИЕ И КОНТРОЛЬ ПРОЕКТНЫХ РАБОТ ОСНОВНЫЕ КОМПОНЕНТЫ ПРОЦЕССА УПРАВЛЕНИЯ ПРОЕКТИРОВАНИЕМ ЭИС Управление проектирование ЭИС в функциональном аспекте рассматривается как совокупность взаимосвязанных процессов. Под процессами управления понимают действия, связанные с решением конкретных задач или реализацией функций управления, к которым относятся: 1. Процессы инициации, связанные с принятием решения о начале выполнения проекта или какого – либо очередного этапа или его фазы; 2. Процессы планирования – совокупность процедур, связанных с определение целей и критериев успеха проекта и разработкой рабочих схем их достижения; 3. Процессы исполнения, предназначенные для координации людей и других ресурсов для выполнения плана; 4. Процессы анализа, дающие возможность определить соответствие плана и исполнения проекта поставленным целям и критериям и принять решение о необходимости корректирующих воздействий; 5. Процессы оперативного управления и регулирования – совокупность процедур, предназначенных для определения необходимых корректирующих мер, их согласования, утверждения, применения; 6. Процессы завершения – процессы формализации выполнения проекта и составления отчетности. Процессы управления проектами накладываются друг на друга и происходят с разной степенью интенсивности на всех стадиях проекта. Кроме того, процессы управления связаны между собой результатами; результат выполнения одного – информация для выполнения другого. Процессы управления связаны между собой входами и выходами. Входы – документы или документированные показатели, согласно которым процесс исполняется Выходы – документы, являющиеся результатом процесса. Методы и средства – механизмы преобразования входа в выход. Рассмотрим состав и содержание выделенных групп процессов. Процессы инициации Инициация включает единственный подпроцесс – авторизацию, т.е. решение начать следующую фазу проекта. Процессы планирования Планирование имеет большое значение для проекта и включает сравнительно много процессов. К основным относятся: 1) планирование целей – разработка постановки задачи (проектное обоснование, основные этапы и цели проекта); 2) декомпозиция целей – разделение этапов проекта на более мелкие и более управляемые компоненты для обеспечения более действенного контроля; 3) определение состава операций (работ) проекта – составление перечня операций для различных этапов проекта; 4) определение взаимосвязей операций – составление и документирование технологических взаимосвязей между операциями; 5) оценка длительностей и объемов работ – оценка кол-ва рабочих временных интервалов либо объемов работ, необходимых для завершения отдельных операций; 6) определение ресурсов (людей, оборудования) проекта – определение общего количества ресурсов всех видов, которые могут быть использованы на работах проекта и их характеристики; 7) назначение ресурсов – определение ресурсов, необходимых для выполнения отдельных операций проекта; 8) оценка стоимости – определение составляющих стоимости операций проекта, оценка этих составляющих для каждой операции, ресурса и назначения; 9) составление расписания выполнения работ – определение последовательности выполнения работ проекта, длительности операций и распределения во времени потребностей в ресурсах и затрат с учетом наложенных ограничений и взаимосвязей; 10) оценка бюджета – приложение оценок стоимости к отдельным компонентам проекта (этапам, фазам, срокам); 11) разработка плана исполнения проекта – интеграция результатов остальных подпроцессов для составления полного документа; 12) определение критериев успеха – разработка критериев оценки исполнения проекта. Кроме перечисленных основных процессов планирования имеется ряд вспомогательных, необходимость использования которых зависит от конкретного проекта. Такие процессы включают: • планирование качества – определение того, какие стандарты качества использовать в проекте, и того, как этих стандартов достичь; • планирование организации – определение, документирование и назначение ролей, ответственности и взаимоотношений отчетности в организации; • назначение персонала – назначение человеческих ресурсов на выполнение работ проекта; • планирование взаимодействия – определение потоков информации и способов взаимодействия, необходимых для участников проекта; • идентификация риска – определение и документирование событий риска, которые могут повлиять на проект; • оценка риска – оценка вероятностей наступления событий риска, их характеристик и влияния на проект; • разработка методов реагирования – определение необходимых действий для предупреждения рисков и реакции на угрожающие события; • планирование поставок – определение того, что, как и когда должно быть поставлено; • подготовка условий – выработка требований к поставкам и определение потенциальных поставщиков. Процессы исполнения и контроля Под исполнением понимают процессы реализации составленного плана. Исполнение проекта должно регулярно измеряться и анализироваться для выявления отклонений от намеченного плана и оценки их влияния на проект. Как и в планировании, процессы можно подразделить на основные и вспомогательные. К основным можно отнести сам процесс Исполнения плана проекта. Среди вспомогательных процессов можно отметить: 1) учет исполнения – подготовку и распределение необходимой для участников проекта информации с требуемой периодичностью; 2) подтверждение качества – регулярную оценку исполнения проекта с целью подтверждения соответствия принятым стандартам качества; 3) подготовку предложений – сбор рекомендаций, отзывов, предложений, заявок; 4) выбор поставщиков – оценку предложений, выбор поставщиков и подрядчиков, заключение контрактов; 5) контроль контрактов – контроль исполнения контрактов поставщиками и подрядчиками; 6) развитие команды проекта – повышение квалификации участников команды проекта. Процессы анализа Процессы анализа включают анализ плана и анализ исполнения проекта. Анализ плана означает определение того, удовлетворяет ли составленный план исполнения проекта предъявляемым к проекту требованиям и ожиданиям участников проекта. Он выражается в оценке показателей плана командой и другими участниками проекта. На стадии планирования по результатам анализа плана может быть принято решение о необходимости изменения начальных условий и составлении новой версии плана либо принятие разработанной версии в качестве базовой. В дальнейшем под процессами анализа понимают процессы анализа исполнения. Процессы анализа исполнения предназначены для оценки состояния и прогноза успешности исполнения проекта согласно критериям и ограничениям, определенным на стадии планирования. Для большинства проектов в число основных ограничений и критериев успеха входят цели, сроки, качество, стоимость работ проекта. При отрицательном прогнозе принимается решение о необходимости корректирующих воздействий, выбор которых осуществляется в процессах управления изменениями. Процессы анализа также можно подразделить на основные и вспомогательные. К основным относятся те процессы анализа, которые непосредственно связаны с целями проекта и показателями, характеризующими успешность исполнения проекта: 1) анализ сроков – определение соответствия фактических и прогнозных сроков исполнения операций проекта; 2) анализ стоимости – определение соответствия фактической и прогнозной стоимости операций и фаз проекта; 3) анализ качества – мониторинг результатов с целью их проверки на соответствие принятым стандартам качества и определение путей устранения причин нежелательных результатов исполнения качества проекта; 4) подтверждение целей – процесс формальной приемки результатов проекта его участниками. Вспомогательные процессы анализа связаны с анализом факторов, влияющих на цели и критерии успеха проекта. Эти процессы включают: 1. Оценку исполнения – анализ результатов работы и распределения проектной информации с целью снабжения участников проекта данными о том, как используются ресурсы для достижения целей проекта; 2. Анализ ресурсов – определение соответствия фактической и прогнозной загрузки и производительности ресурсов запланированным, а также анализ соответствия фактического расхода материалов, машинного времени и т.д. плановым значениям. В результате анализа либо принимается решение о продолжении исполнения проекта по намеченному ранее плану либо определяется необходимость корректирующих действий. Процессы оперативного управления Управление исполнением проекта – это определение и применение необходимых управляющих воздействий с целью успешной реализации проекта. Если исполнение проекта идет в соответствии с намеченным планом, то управление сводится к доведению до участников проекта плановых заданий и контролю за их реализацией. Эти процессы включаются в процессы исполнения. В том случае, если возникли отклонения, то требуется: 1) найти оптимальные корректирующие воздействия; 2) скорректировать план оставшихся работ; 3) согласовать намеченные изменения со всеми участниками проекта. Процессы оперативного управления предназначаются для определения, согласования и внесения необходимых изменений в план проекта. Такие процессы часто называются управлением изменениями и инициируются процессами анализа. К основным процессам оперативного управления относятся: 1. Общее управление изменениями – определение, согласование, утверждение и принятие к исполнению корректирующих воздействий и координация изменений по всему проекту; 2. Управление ресурсами – внесение изменений в состав и назначение ресурсов на работы проекта; 3. Управление целями – корректировка целей проекта по результатам процессов анализа; 4. Управление качеством – разработка мероприятий по устранению причин неудовлетворительного исполнения. Среди вспомогательных процессов управления выделяют: 1) управление рисками – реагирование на события и изменение рисков в процессе выполнения проекта; 2) управление контрактами – координация работы подрядчиков, корректировка контрактов, разрешение конфликтов. Процессы завершения Завершение проекта сопровождается следующими процессами: 1. Закрытием контрактов – завершением и закрытием всех контрактов, включая разрешение споров. 2. Административным завершением – подготовкой, сбором и распределением информации, необходимой для формального завершения проекта. МЕТОДЫ ПЛАНИРОВАНИЯ И УПРАВЛЕНИЯ ПРОЕКТАМИ И РЕСУРСАМИ С целью повышения эффективности проектирования ЭИС разрабатывают систему управления проектом (СУП). СУП представляет собой организационно – технологический комплекс методических, технически, программных и информационных средств, направленный на поддержку и повышение эффективности процессов планирования и управления проектом. СУП содержит набор функциональных средств, которые помогают менеджеру планировать работы, временные, ресурсные и стоимостные оценки выполнения комплекса работ, а затем в процессе выполнения отслеживать ход работ и корректировать план. СУП можно представит в виде модели, отражающей план разработки, в котором фиксируется ход событий для достижения конечной цели при заданных условиях. Составленная модель должна быть адекватна моделируемой системе. Существует несколько способов формализованного представления выполняемой совокупности работ. Диаграмма Ганта Диаграмма Гантта (циклограмма) – горизонтальная линейная диаграмма, на которой работы проекта представляются протяженными по времени отрезками, характеризующимися датами начала и окончания, задержками и, возможно, другими временными параметрами. Код работы Начало Конец Длительность в единицах времени Временные периоды в единицах времени 1 1.10 2.10 1 2 2.10 5.10 3 3 5.10 9.10 4 4 6.10 9.10 3 Рис. 17. Диаграмма Ганта Получаемый график отличается статичностью и громоздкостью, по результатам отображения работ нельзя оперативно получать информацию о ресурсах, поэтому может применяться лишь при небольших объемах работ. Существенными недостатками являются: неспособность в полной мере отражать взаимосвязи отдельных операций; недостаточная гибкость линейной модели; трудность ее корректировки при изменившихся условиях; ограниченные возможности прогнозирования дальнейшего хода работ, что снижает эффективность процесса управления. От этих недостатков свободны сетевые модели. Они легко поддаются обработке на ЭВМ, позволяют более эффективно осуществить планирование, контроль и управление процессом создания сложных систем. Методика СПУ – развитая система планирования и управления, предусматривающая выявление и использование резервов времени и материальных ресурсов, дающая возможность прогнозирования и предупреждения возможных срывов в ходе выполнения программы. Это метод Уолкера – Келли (метод критического пути МКП) и метод анализа и оценки программ (PERT). Сетевые диаграммы моделирует логические зависимости между отдельными элементами работ. Существую следующие виды диаграмм: 1) граф – сеть типа «вершина – работа» (диаграмма предшествования): вершины – работы, связанные линиями – взаимосвязи между работами; 2) сеть типа «вершина – событие». Работа представляется в виде линии между двумя событиями (узлами графа), которые в свою очередь, отображают начало и конец этой работы. Сетевые методы планирования хорошо декомпозируются на упорядоченную последовательность работ, используют хорошо отработанный математический аппарат расчетов на сетевых графиках. Можно выделить следующие особенности использования системы методов СПУ. 1. Системный подход к решению вопросов организации управления процессом создания новых систем. 2. Использование информационно–динамической модели особенного вида (сетевой модели комплекса операций) для логико–математического описания процесса создания системы и алгоритмизации расчетов параметров этого процесса (продолжительности, трудоемкости, стоимости). 3. Применение ЭВМ с целью обработки исходных и оперативных данных для расчета плановых показателей и получения необходимых аналитических и отчетных сводок. 4. Комплексы работ, для которых применяют методы СПУ, могут иметь одноцелевой и многоцелевой характер. При построении сетевого графика необходимо знать операции, предшествующие и следующие за рассматриваемой. Сеть выражает соотношения порядка, существующие на множестве работ, характеризующиеся временем выполнения, и событий, которые характеризуются временем начала и временем окончания. Существуют правила построения моделей. 1. Любая работа обозначается стрелкой, которая соединяет только два события и отражает процесс перехода от одного события к другому. 2. Событие, из которого выходит стрелка, называется начальным или предшествующим по отношению к дальнейшей работе. Событие, в которое стрелки входят, является конечным или последующим. 3. Начало стрелки показывает, с какого события данная работа начинается, а конец – в каком событии она заканчивается. 4. Работы имеют временные оценки, которые проставляются на стрелках. Событие считается свершившимся тогда, когда будет закончена самая длительная из всех входящих в него работ. 5. Размеры ресурсов, требуемые для выполнения работы, указываются на стрелках в скобках. Максимальный по продолжительности полный путь в сети называется критическим; работы, лежащие на этом пути, называются критическими (на графике отображаются двойными стрелками). Выявление критического пути позволяет установить работы (операции), определяющие ход проекта. Критические работы в ходе проектирования должны выполняться строго по графику. Именно длительность критического пути определяет наименьшую общую продолжительность работ по проекту в целом. Метод критического пути позволяет рассчитать возможные календарные графики выполнения комплекса работ на основе описанной логической структуры сети и оценок продолжительности каждой из работ, определить критический путь проекта. Длительность выполнения всего проекта может быть сокращена за счет сокращения длительности работ, лежащих на критическом пути. Критических путей может быть несколько. Пути, продолжительность которых приближается к критическом, называются субкритическими. Остальные пути – некритические. Наличие критического пути позволяет использовать его в качестве основы для оптимизации плана. Работы, лежащие на некритическом пути обладают резервом времени. Временной резерв (запас времени) – это разность между возможным сроком завершения работ и самым поздним сроком ее выполнения. Управленческий смысл временного резерва заключается в том, что при необходимости можно задержать работу без влияния на общую продолжительность проекта и продолжительность связанных с ней задач. ТЕХНОЛОГИЯ ПРИМЕНЕИЯ МЕТОДА СПУ ДЛЯ РАЗРАБОТКИ ПРОЕКТА ЭИС Перед началом разработки проекта составляется организационный план проведения работ. Он состоит из трех разделов. 1. Исходный план – план-график выполнения работ проекта, содержащий исходные сведения об основных временных и стоимостных параметрах работ, который принят к исполнению. В исходном плане обычно фиксируют объемы работ, плановые даты начала и окончания задач проекта, длительность задач, расчетные стоимости задач. Он составляется в виде сетевого графика. 2. План материально – технической базы проектирования, в котором отражены вопросы, связанные с обеспечением проектировщиков необходимым инструментарием: бумагой, бланками документов, рабочим местом, машинными носителями. 3. Квалификационный план разработчиков, где указывается форма проведения проектировочных работ. Устанавливается перечень исполнителей по проектированию, должность, оклад, формы и методы контроля за работой проектировщиков, возможности взаимной увязки материалов различных бригад. Все три раздела организационного плана оформляются в виде записки и представляют заказчику на обсуждение и утверждение. Процессы планирования и управления проектами с применением методов СПУ охватывают три основных этапа. 1. Разработка первоначального исходного сетевого плана. 2. Оптимизация плана и приведение его в соответствие с ограничениями. 3. Оперативное управление и систематический контроль за ходом работ. Рассмотрим содержание работ, выполняемых на каждом этапе. Этап 1 Цикл управления проектированием ЭИС начинается с определения состава проектных работ по стадиям и этапам проектирования. В основе такой работы лежит модель жизненного цикла ЭИС. Состав проектных работ зависит от глубины декомпозиции процесса проектирования по уровням управления. Декомпозиция может выполняться относительно отдельных частей проекта или всего проекта в целом, но всегда в соответствии с выбранной технологией проектирования. Основная задача – выбор единицы проектных работ. Следующие требования являются для возможных вариантов определения такой единицы: 1) выполнение работы можно поручить одному специалисту или группе специалистов; 2) выполнение работы должно быть удобным для планирования и контроля; 3) объем и характер работ должны давать возможность объективной оценки необходимых ресурсов и результатов. Существует несколько способов решения этой задачи, которые зависят от применяемых методов определения значений плановых показателей. После завершения подготовительной работы, располагая исходными данными, приступают к построению первого варианта сетевого графика. Его цель – наглядно, во взаимосвязи показать весь процесс проектирования ЭИС. Этот вариант позволяет выделить важнейшие узловые проектные работы и подготовить материал для обсчета сетевого графика. Последовательность разработки сетевого графика для выполнения всего объема проектировочных работ сводится к выполнению трех групп операций. Первая группа операций выполняется «сверху – вниз» с целью разукрупнения графика и определения состава работ каждого уровня управления, начиная с верхнего, и расчета директивных сроков их выполнения: • на уровне главного конструктора, на котором в качестве работ выступают работы над проектом 1, 2, …, 10; • на уровне планового отдела, где в качестве событий выступают отдельные этапы проектирования; • на уровне руководителя проекта, на котором существенным являются сроки исполнения отдельных частей проекта; • на уровне руководителей отделов, в разрезе работ по получению информационного, математического и других видов обеспечения; • на уровне работ, выполняемых конкретными специалистами по элементам проекта, на котором получают совокупность детальных сетевых графиков. Затем проводится дифференциация процесса проектирования двумя способами: 1) по отдельным наименованиям работ – попредметный способ; 2) по временным этапам – последовательность выполнения работ. Результаты такого логического разбиения всего комплекса проектировочных работ сводятся в начальный план – график. После завершения каждой работы должен быть получен определенный результат, а начало и окончание каждой работы должны соответствовать событию – результату. В этом случае можно получить непрерывную технологическую последовательность проектировочных работ, т. е. полный путь событий от исходного до завершающего. Далее строят график, узлами которого будут события, а путями, соединяющими отдельные события – работы, имеющие определенную протяженность. При разработке варианта сетевого графика также определяется возможность начала выполнения отдельных работ после частичного завершения предыдущих. В этом случае предыдущая операция делится на две самостоятельные работы. Этим достигается сокращение выполнения всего цикла работ и предотвращается искусственная задержка начала следующего комплекса. При этом каждая работа расчленяется так, чтобы она имела конечный результат, являющийся началом для другой работы. После построения сетевых графиков на нижнем уровне происходит выполнение группы операций второго уровня – сшивка детальных графиков и постепенная их интеграция методом «снизу – вверх» с целью получения интегрированного графика для высших уровней руководства, который на третьем этапе оценивается по времени. Так как график используется и для контроля за выполнением работ, то за каждым участком закрепляется определенная группа лиц проектировщиков, что позволяет определить количественный состав. В спецификации к первому варианту графика указываются краткие наименования, которые в дальнейшем берутся за основу определения продолжительности выполнения работ, а при необходимости раскрываются в виде самостоятельных комплексов. Исходный вариант спецификации нуждается в дополнительном уточнении. В окончательном варианте переименовываются уже все необходимые работы в их предметной и временной последовательности и взаимной увязке, им присваиваются номера, которыми они будут обозначаться на сетевом графике. После этого выполняется третья группа операций по разработке сетевого графика, когда данные передаются для обработки на ЭВМ с целью получения основных показателей. К основным показателям сетевого графика относятся следующие: 1) продолжительность каждой работы t(i-j); 2) раннее время свершения события tp(i); 3) позднее время свершения события tп(i); 4) время раннего начала работы tp(i-j); 5) время позднего начала работы tпн(i-j); 6) время раннего окончания работы tpo(i-j); 7) время позднего окончания работы tпо(i-j); 8) полный резерв времени R(i-j); 9) частичный резерв времени работы r(i-j); 10) частичный резерв времени события r(i). Как правило, сетевой график состоит из набора сетевых графиков, соответствующих отдельным этапам проектирования. При разработке сетевого графика большое значение придается выбору показателя времени, затрачиваемого на выполнение работ. Такой показатель не может быть точным, поэтому при построении сетевого графика исходят из средней продолжительности выполнения работ и принимают за единицу времени неделю, декаду или месяц. Каждая работа сетевого графика имеет временную оценку – продолжительность t(i-j), выражающуюся в единицах времени. При этом продолжительность известна заранее или может быть определена расчетным путем. Для часто повторяющихся работ имеются нормативные продолжительности, установленные в зависимости от характера работы (операции) и применяемых ресурсов, которые рассчитываются пол формуле: , где – начальное и конечное события работы E(i-j); – трудоемкость работы, чел/дн; – количество исполнителей, занятых выполнением работы – коэффициент перевода рабочих дней в календарные,f=0,85. Такие сети с однозначными временными оценками получили название детерминированных. Для сетей, по которым объективные и установленные нормы отсутствуют, временные оценки приходится устанавливать в условиях полной неопределенности. В таких условиях для оценки продолжительности каждой работы применяют вероятностный метод, который позволяет учесть степень неопределенности путем распределения ее вероятности в намеченный срок. Это достигается с помощью трех временных оценок вместо одной, а сети называются стохастическими. Рассчитывается математическое ожидание или статистическое среднее значение времени выполнения работы E(i-j)-tож на основе следующих трех оценок по формуле: , где – минимальная (оптимистическая оценка времени) – наиболее вероятное время – максимальная (пессимистическая) оценка времени. В стохастических сетях определяют следующие показатели: величину дисперсии , т.е. меру неопределенности, связанную с этой продолжительностью: . Любая последовательность работ в сетевом графике, в котором конечное событие предшествующей работы совпадает с начальным событием последующей, называется путем. Продолжительность (длина) любого пути равна сумме продолжительностей составляющих его работ. В сетевом графике несколько путей. Сравнивая их длины, можно выделить путь с наибольшей продолжительностью – критический путь : . Критический путь определяет время, необходимое для выполнения программы всех проектных работ, включенных в график. Все работы, лежащие на этом пути, являются критическими, и от их выполнения будет зависеть наивыгоднейший срок выполнения программы проектирования. Сетевой график дает возможность представить именно такую последовательность работ, которая определит общий срок выполнения проекта, и использовать его для оптимизации плана. В самих временных оценках, как правило, закладывается резерв, который может компенсировать отдельные неточности предварительного планирования и позволяет избежать отклонений фактического выполнения работ от запланированного. Ранний и поздний сроки свершения конкретного события (,) определяются по максимальному из путей, проходящих через событие: , где – путь, предшествующий событию i. , где – последующий путь. Для критического пути При определении ранних сроков начала и окончания работы следует помнить, что первый показатель определяется продолжительностью максимального пути от исходного до начального события данной работы, т.е. самый ранний срок начала работы равен раннему сроку наступления начального события данной работы: , где - время раннего начала работы ; - раннее время свершения события . Второй показатель равен сумме раннего срока начала и продолжительности данной работы: , где - время раннего окончания работы ; - длительность работы . При определении поздних из допустимых сроков начала и окончания работы учитывают, что позднее начало работы может быть определено как разность между поздним окончанием данной работы и ее продолжительностью: , где - время позднего начала работы ; время позднего окончания работы . Поздний срок окончания работы, при котором продолжительность критического пути не изменится, равен позднему сроку наступления конечного события данной работы: . Для критического пути характерны следующие соотношения: После составления и расчета сетевого графика решается задача планирования использования разнообразных ресурсов. На основе структурной схемы устанавливается перечень частей системы, событий и работ, отвечающих различным уровням руководства. Осуществляется разработка календарных планов, указывающих сроки проектирования с наличными ресурсами (по каждой работе – стоимость, материалы, трудовые затраты). Этап 2 Происходит процесс корректировки исходного сетевого графика, который называют оптимизацией (улучшение с целью достижения заданного срока или равномерного распределения ресурсов). Задачей системы СПУ и ее дальнейшего развития является обеспечение соответствия между установленными сроками работ и отпущенными для их выполнения ресурсами. Как правило, оптимизация осуществляется по следующим критериям: 1) время () 2) затраты материальных ресурсов; 3) затраты денежных ресурсов; 4) технико – экономические показатели. Первоначально сеть корректируется по критерию «время» без учета ограничений. Существует несколько путей совершенствования сетевых графиков. Один из них основан на оценке величины директивных сроков окончания работ . Если , то возникает дополнительный резерв времени: . Дополнительный резерв времени может быть использован для увеличения продолжительности отдельных критических работ при последующей оптимизации. Если, то пересматривают сеть с целью ее уплотнения. Главная задача – ускорение тех работ, из которых в каждом случае складывается критический путь. Уплотнение сетевого графика или его перепланировка производятся обычно методом последовательных приближений, т.е. многократным сжатием очередного критического пути, пока не будет достигнут удовлетворительный результат. Существует несколько методов приведения сетевого графика в соответствие с заданными сроками: 1) изменение временных оценок путем замены информативной продолжительности сокращенной продолжительностью; 2) изменение топологии сети путем пересмотра выполнения работ; 3) расчленение работ и их совмещение по времени. Общий срок выполнения программы следует сокращать за счет изменения продолжительности критических работ, так как он не связан с изменением топологии сети. Рекомендуется уменьшать продолжительность не только критических работ, но и работ, лежащих на подкритических путях, так как они могут стать критическими. Уменьшение временных оценок идет за счет переброски соответствующих ресурсов с ненапряженных работ, имеющих значительный резерв времени. Если не удается уменьшить срок за счет времени, то прибегают к изменению топологии сети. Это возможно т.к . некоторые работы могут выполняться разными методами. Многовариантная технология позволяет отыскивать новую последовательность выполнения работ и новые взаимосвязи. Чаще всего проводят оптимизацию сети на основе расчета резервов времени для работ, находящихся на некритическом пути. При определении резервов времени учитывают, что полный резерв времени работы – срок, на который можно передвинуть данную работу, не увеличивая , который определяется по формуле: Частный резерв времени работы – срок, на который можно передвинуть данную работу, не влияя на другие характеристики сети, выражается зависимостью: Резерв времени события - срок, на который можно сдвинуть свершение данного события, не увеличивая продолжительности всей разработки, составит: . Следующим методом является распараллеливание работ критического пути, если есть трудовые ресурсы. При сокращении срока за счет тех или иных мероприятий и выявления нескольких вариантов в сетевом графике обеспечивается выполнение работ в заданный срок. Необходимо сравнить эти варианты и выбрать лучший. Одновременно с сокращением критического пути уменьшаются и резервы времени, в результате чего возникает все больше критических путей и работ. Определить степень напряженности выполнения каждой некритической группы работ можно с помощью коэффициента напряженности работ Kн(i-j). Коэффициент определяется отношением несовпадающих с критическим путем отрезков максимального пути, проходящего через данную работу, к критическому пути: , где – совпадающая с критическим путем величина отрезка; – протяженность максимального пути, проходящего через данную работу. Если после всех принятых мер по сокращению продолжительности выполнения программы директивный срок не достигнут, ставится вопрос перед руководством об изменении этого срока. Составленный план должен быть оптимизирован не только по срокам, но и по всем видам ресурсов. При планировании проектировочных работ можно разработать различные варианты улучшения и ускорения проектирования с учетом временного критерия, характеризующего работы. Однако часто оказывается, что оптимальные по времени варианты разработок являются на практике труднореализуемыми, так как они не учитывают, например, ограничений по трудовым ресурсам. Поэтому после расчета временных параметров укрупненного сетевого графика производится его на анализ на соответствие параметров другим ресурсам. Основным способом оптимизации плана при учете ограничений на ресурсы служит снятие ресурсов и переброска их на критический путь с целью сокращения времени на критическом пути. Поэтому процедура перераспределения ресурсов продолжается до тех пор, пока сроки не станут меньше директивных или равны им. Потребность в ресурсах по сетевому графику определяется путем изображения сетевого графика в масштабе времени по ранним или поздним срокам начала и окончания работ, т.е путем построение линейного календарного плана . Код работы t(i-j) R(i-j) (r(i-j) Дни 1 2 3 4 5 6 7 8 9 10 11 1-2 1 10 1-3 5 20 20 20 20 20 2-3 3 1 10 10 10 R=1 2-4 2 8 8 8 R=8 3-4 6 19 19 19 19 19 19 3-5 5 1 11 11 11 11 11 R=1 Рис. 16 Пример линейного календарного плана В этом календарном плане указываются коды работ, продолжительности работ, циклограмма, отражающая в ленточном виде время начала, окончания, продолжительности работ, величину их резерва. Под календарным планом составляют эпюру (гистограмму) потребности в ресурсах. В ней по оси Х откладывают временные промежутки выполнения работ, а по оси Y – колеблемость суммарной потребности в трудовых ресурсах на всех отрезках времени около линии ограничения их использования. Распределение ограниченных ресурсов с постоянной интенсивностью потребления, т.е. количеством ресурса, используемым в единицу времени в данной работе, сводится к нахождению рационального распределения его за счет снижения пиковых суммарных интенсивностей потребления до заданного уровня. Однако при правильном решении проблемы часто удается привести потребление ресурса в соответствии с заданным ограничением без увеличения продолжительности критического пути. Это достигается упорядочиванием численности людей за счет использования частных резервов времени некритических работ. Помимо основных работ, в исходный план проектирования должны быть включены процедуры контроля за проектной деятельностью. Их необходимо планировать по содержанию и по времени. Календарный план проведения контроля представляет собой перечень моментов времени контрольных точек, в которых целесообразно проводить контроль состояний проекта. Поэтому сетевой график должен содержать контрольный моменты в виде запланированных сроков представления результатов проектирования. После этого сетевой график рассматривается и утверждается руководством проектирования и предприятия, для которого проводятся работы. Этап 3 Сетевой график удобно применять в процессе оперативного управления проектированием, которое осуществляется на основе периодического выполнения процессов контроля, так как сетевой график приходится пересчитывать исходя из изменений ситуаций в сроках и ресурсах в процессе проектирования. ВЫБОР СИСТЕМЫ ДЛЯ УПРАВЛЕНИЯ ПРОЕКТАМИ Важной составной частью системы управления проектами являются инструментальные средства, с помощью которых реализуются методы СПУ и МКП, представляющие собой совокупность программных средств, направленных на поддержку и повышение эффективности процессов планирования и управления проектом. Выбор типов программного обеспечения по управлению проектами осуществляют в следующей последовательности: 1) анализ требования пользователей; 2) анализ рынка; 3) выбор программного обеспечения. В системе управления проектами можно выделить три уровня управления проектами, соответствующих определенным категориям пользователей ПО, выполняющих специфические функции. 1) Уровень высшего руководства, на котором происходит определение целей и задач предприятия, принимается решение о финансировании, оценивается приоритетность проектов. 2) Стратегический уровень, состоящий из профессионалов по управлению проектами, занимающихся планированием и контролем корпоративных проектов. В своей работе они опираются на программное обеспечение по управлению проектами. 3) Уровень операций, для которого работа с программным обеспечением по управлению проектами вторична. Это ответственные за проекты на местах, руководители групп. На уровне операций требуется инструмент по управлению и контролю за проектом, но на небольшие отрезки времени. К программным средствам по управлению проектами предъявляются следующие требования. Уровень высшего руководства: легкость в применении; возможность получать демонстрационные отчеты; мощные возможности обобщения сведении; процедуры для планирования «сверху – вниз». Стратегический уровень: средства временного, ресурсного, стоимостного планирования, анализа рисков; возможность интеграции с другими приложениями; средства для свертывания данных по проекту (предоставление отчетов руководству) и углублению для планирования на более детальном уровне; средства для контроля за реализацией проекта; Гибкость при настройке выходных форм отчетности. Уровень операций: простота использования; легкость изучения; прозрачность процедур ввода данных; наглядность. К числу основных факторов, предопределяющих выбор инструментального средства для управления проектами, можно отнести следующие: 1) тип задач, для которых требуется система управления проектами; 2) характер деятельности организации с точки зрения возможности и целесообразности применения проектной формы планирования; 3) тип деятельности, которая может планироваться в виде проектов; 4) уровень детальности, до которого необходимо планировать и контролировать проекты. Для поддержки различных управленческих задач используются различные программные средства. Для укрупненного описания и анализа проекта на прединвестиционной стадии в большей мере подходит специализированное ПО анализа проектов, которое позволяет выполнить оценки основных показателей рентабельности проекта в целом и обосновать эффективность капиталовложений. Примером системы анализа проектов является программа Project Expert фирмы PRO – INVEST – Consulting. Если управление проектами в организации не завершается обоснованием инвестиций и существует потребность в контроле за ходом реализации проекта, то необходимо переходить к использованию ПО управления проектами. Project Expert имеет возможность обмена данными с пакетами управления проектами MS Project и Time Line. Если принципиальное решение об использовании системы для управления проектами (УП) принято, то для выбора пакета необходимо ответить на вопросы, связанные с выяснением состава функций планирования и управления, которые требуется реализовать: • только планирование или планирование и контроль за ходом проекта; • планирование и контроль лишь сроков выполнения работ; • планирование и контроль финансовых вложений без детального планирования использования ресурсов; • детальное планирования использования ресурсов; • многопроектное управление. Далее следует определить также требования к следующим компонентам проекта: • к размерности проектов и детальности планирования; • организационной структуре управления и отчетности; • сколько проектов будет вестись одновременно и будут ли они взаимозависимыми • каково примерное количество задач в одном проекте; • сколько видов ресурсов будет задействовано в одном проекте; • как будут распределяться ресурсы между проектами. Кроме того, на выбор пакета могут повлиять специфические требования управления в конкретной предметной области (например, специальные требования к отчетности, необходимость интеграции с другими приложениями или нормативными базами). Существенным является также квалификация персонала, который будет использовать ПО. Большие возможности пакетов – более высокая квалификация. Выбираемое средство управления проектами должно включать следующие базовые функциональные возможности. 1. Средства описания комплекса работ проекта, связей между работами и их временных характеристик. 1.1. Средства описания и типы планирования: a) выполнить работу «как можно раньше»; b) выполнить работу «как можно позже»; c) работы с фиксированной датой начала – окончания; d) возможность привязки длительностей задач к объему назначаемых ресурсов; e) вычисляемые резервы времени (полный, свободный). 1.2. Средства установки логических связей между задачами. 1.3. Многоуровневое представление проекта. 1.4. Поддержка календаря проекта, поддержка календарей ресурсов. 2. Средства поддержки информации о ресурсах и затратах по проекту и назначения ресурсов и затрат по отдельным работам проекта. 2.1. Ведение списка наличных ресурсов, возможность задания нормального и максимального объема ресурса. 2.2. Поддержка ресурсов с фиксированной стоимостью и ресурсов, стоимость которых зависит от длительности их использования. 2.3. Расчет требуемых объемов ресурсов. 2.4. Ресурсное планирование (выделение перегруженных ресурсов и использующих их задач, автоматическое/командное выравнивание профилей загрузки ресурсов с учетом ограничений по времени или с учетом ограничений на ресурс, с учетом приоритетов задач). 3. Средства контроля заходом выполнения проекта. 3.1. Средства отслеживания состояния задач проекта (фиксация плана расписания проекта, средства ввода фактических показателей состояния задач (процент завершения)). 3.2. Средства контроля за фактическим использованием ресурсов (бюджетное количество и стоимость ресурса, количество и стоимость ресурсов, требуемых для завершения работы). 4. Графические средства представления структуры проекта, средства создания различных отчетов по проекту. 4.1. Диаграмма Ганта 4.2. PERT – диаграмма (сетевая диаграмма). 4.3. Средства создания необходимых для планирования отчетов. К числу таких систем относятся Microsoft Project, Time Line, Primavera, Artemis Views, Spider Project, Open Plan. Вопросы для самоконтроля 1. Что является целью ограничениями и объектом управления при разработке проекта ЭИС? 2. Каковы состав процессов управления проектами и их содержание? 3. Что такое система управления проектами и каков состав ее компонентов? 4. Каковы методы формализованного представления состава проектных работ? 5. В чем сущность использование метода диаграмм Ганта, его преимущества и недостатки? 6. Каковы особенности и преимущества использования метода СПУ и метода критического пути? 7. Что такое сетевая диаграмма, состав ее компонентов, правила построения? 8. Что такое ресурсы, их виды? Что понимается под ресурсным календарным планированием? 9. Какова методика управления проектированием с использованием метода СПУ? 10. Какова последовательность разработки сетевого графика проектных работ? 11. Каков состав показателей оценки разработки сетевого графика? 12. Каковы методы формирования временных оценок продолжительности выполнения работ? 13. Каков состав работ по организации контроля за качеством разрабатываемого проекта? 14. Какова последовательность работ по выбору инструментальных средств управления проектированием Заключение Информационная система является системой информационного обслуживания работников управленческих служб и выполняет технологические функции по накоплению, хранению, передаче и обработке информации. Она складывается и функционирует в регламенте, определенном методами и структурой управленческой деятельности, принятой на конкретном экономическом объекте, реализует цели и задачи, стоящие перед ним. Создание автоматизированных информационных систем способствует повышению эффективности производства экономического объекта и обеспечивает качество управления. Определяя автоматизированную информационную систему как организованную для достижения общей цели совокупность специалистов, средств вычислительной и другой техники, математических методов и моделей, интеллектуальных продуктов и их описаний, а также способов и порядка взаимодействия указанных компонентов, следует подчеркнуть, что главным звеном и управляющим субъектом был и остается человек, специалист. Несмотря на всю важность технических решений ценность и уникальность автоматизированных информационных систем составляют интеллектуальные продукты, разрабатываемые участниками проектирования и последующих доработок. БИБЛИОГРАФИЧЕСКИЙ СПИСОК 1. Г.Н.Смирнова, А.А.Сорокин, Ю.Ф.Тельнов. Проектирование экономических информационных систем: Учебник. - М.:Финансы и статистика, 2001. 2. А.М.Вендров Проектирование программного обеспечения экономическх информационных систем: Учебник. – М.: Финансы и статистика, 2000. 3. Г.А.Титоренко. Автоматизированные информационные технологии в экономике: Учебник. – М.: Компьютер, ЮНИТИ, 1998. 4. В.В.Дик. Информационные системы в экономике: Учебник. – М.:Финансы и статистка, 1996. СОДЕРЖАНИЕ ЛЕКЦИЯ 1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ (ЭИС) 1 ЛЕКЦИЯ 2 МЕТОДОЛОГИЧЕСКИЕ ОСНОВЫ ПРОЕКТИРОВАНИЯ ЭИС 4 ЛЕКЦИЯ 3 КАНОНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ 13 ЛЕКЦИЯ 4 ПРОЕКТИРОВАНИЕ КЛАССИФИКАТОРОВ ТЕХНИКО-ЭКОНОМИЧЕСКОЙ ИНФОРМАЦИИ 26 ЛЕКЦИЯ 5 ПРОЕКТИРОВАНИЕ СИСТЕМЫ ЭКОНОМИЧЕСКОЙ ДОКУМЕНТАЦИИ 33 ЛЕКЦИЯ 6 ПРОЕКТИРОВАНИЕ ВНУТРИМАШИННОГО ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ 41 ЛЕКЦИЯ 7 ИНДУСТРИАЛЬНОЕ ПРОЕКТИРОВАНИЕ КОРПОРАТИВНЫХ ЭИС 51 ЛЕКЦИЯ 8 АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ ЭИС (CASE – ТЕХНОЛОГИИ) 61 ЛЕКЦИЯ 9 ТИПОВОЕ ПРОЕКТИРОВАНИЕ ЭИС 88 ЛЕКЦИЯ 10 УПРАВЛЕНИЕ ПРОЕКТИРОВАНИЕМ ЭИС 111 ЛЕКЦИЯ 11 ПЛАНИРОВАНИЕ И КОНТРОЛЬ ПРОЕКТНЫХ РАБОТ 123 Заключение 152 БИБЛИОГРАФИЧЕСКИЙ СПИСОК 153