Процесс управления организацией
Управление определяется как совокупность действий, направленных на оптимизацию деятельности фирмы, ее развитие в соответствии с целью ее функционирования и на основе объективной информации, рис. 1.5.
Рис. 1.5. Схема управления организацией
Контур стратегического управления определяет процессы планирования производства на основе исходных показателей, что позволяет выработать плановые показатели, которые определяют необходимый уровень финансирования, наличие производственных и кадровых ресурсов и т.п., что определяет возможность достижения результатов деятельности.
На объект управления воздействуют различные внешние (незапланированные) воздействия, что может привести к изменению результатов деятельности.
Блок анализа позволяет определить причины отклонения от заданных объемов продукции и внести изменения в планы.
Контур оперативного управления содержит систему учета и контроля деятельности предприятия, что позволяет также анализировать ход производственного процесса и вносить коррективы (регулировать) условия деятельности объекта.
В качестве метода, позволяющего регулировать процесс управления организацией, используются разные подходы (методы управления), среди которых можно выделить следующие:
1) управление на базе учетных показателей;
2) минимизация межоперационных заделов за счет стабилизации поставок и обеспечения оптимальных резервов производственных мощностей (JIТ-концепция «точно в срок»);
3) планирование материальных потребностей (MRP);
4) планирование ресурсов производства (MRPII);
5) компьютеризованное интегрированное производство (CIM);
6) поддержка непрерывного жизненного цикла продукции (CALS-технология);
7) планирование ресурсов предприятия (ERP);
8) планирование ресурсов, синхронизированное с заказами (CSRP), и т.п.
Выбор и оптимизация метода управления производством базируется на положениях системы качества и принципах планирования и управления ресурсами предприятия.
Технология
проектирования ИС
Технология проектирования ИС ‑ это совокупность методологии и средств проектирования ИС, а также методов и средств организации проектирования (управление процессом создания и модернизации проекта ИС).
Основные компоненты технологии проектирования ИС
Характеристика применяемых технологий проектирования
• Сочетание разных признаков систематизации способов проектирования обусловливает нрав применяемой технологии проектирования ИС, посреди которых выделяются два главных класса: каноническая и промышленная технологии.
Параметризация и реструктуризация модели (конфигурация ИС) • Промышленная разработка проектирования, в свою очередь, разбивается на два подкласса: автоматическое (внедрение CASE-технологий) и типовое (параметрически-ориентированное либо модельно-ориентированное) проектирование. • Внедрение промышленных технологий проектирования не исключает использования в отдельных случаях канонической технологии. • Для определенных видов технологий проектирования характерно применение определенных средств разработки ИС, которые поддерживают выполнение, как отдельных проектных работ, шагов, так и их совокупностей. Потому перед разработчиками ИС, обычно, стоит задачка выбора средств проектирования, которые по своим чертам в большей степени соответствуют требованиям определенного предприятия. Средства проектирования должны быть: • в собственном классе инвариантными к объекту проектирования; • обхватывать в совокупы все этапы актуального цикла ИС; • на техническом уровне, программно и информационно совместимыми; • ординарными в освоении и применении; • экономически целесообразными.
Требования, предъявляемые к технологии проектирования ИС
Технология должна поддерживать полный жизненный цикл системы;
технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;
технология должна обеспечивать возможность выполнения крупных проектов в виде подсистем;
технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами;
технология должна обеспечивать минимальное время получения работоспособной ИС;
технология должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;
технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС;
технология должна быть поддержана комплексом согласованных CASE-средств.
Жизненный цикл ИС: этапы и модели
Каскадная модель предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.
Поэтапная модель с промежуточным контролем. Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.
Спиральная модель . На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка.Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).
Каноническое проектирование ИС
Каноническое проектирование ИС отражает особенности ручной технологии индивидуального (оригинального) проектирования, осуществляемого на уровне исполнителей без использования каких-либо инструментальных средств, позволяющих интегрировать выполнение элементарных операций.
Область применения: для небольших локальных ИС.
Модель жизненного цикла ИС: каскадная.
Проектная документация: в соответствии с ГОСТ 34.
Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:
Стадия 1. Формирование требований к ИС.
На начальной стадии проектирования выделяют следующие этапы работ:
обследование объекта и обоснование необходимости создания ИС;
формирование требований пользователей к ИС;
оформление отчета о выполненной работе и тактико- технического задания на разработку.
Стадия 2. Разработка концепции ИС.
изучение объекта автоматизации;
проведение необходимых научно-исследовательских работ;
разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;
оформление отчета и утверждение концепции.
Стадия 3. Техническое задание.
разработка и утверждение технического задания на создание ИС.
Стадия 4. Эскизный проект.
разработка предварительных проектных решений по системе и ее частям;
разработка эскизной документации на ИС и ее части.
Стадия 5. Технический проект.
разработка проектных решений по системе и ее частям;
разработка документации на ИС и ее части;
разработка и оформление документации на поставку комплектующих изделий;
разработка заданий на проектирование в смежных частях проекта.
Стадия 6. Рабочая документация.
разработка рабочей документации на ИС и ее части;
разработка и адаптация программ.
Стадия 7. Ввод в действие.
подготовка объекта автоматизации;
подготовка персонала;
комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);
строительно-монтажные работы;
пусконаладочные работы;
проведение предварительных испытаний ;
проведение опытной эксплуатации ;
проведение приемочных испытаний.
Стадия 8. Сопровождение ИС.
выполнение работ в соответствии с гарантийными обязательствами;
послегарантийное обслуживание.
Методы и инструменты сбора и анализа материалов предпроектного обследования объекта автоматизации.
В «Предпроектной стадии» принято выделять два основных этапа:
сбор материалов обследования;
анализ материалов обследования и разработка технико-экономическогообоснования (ТЭО) и технического задания (ТЗ).
При изучении существующей экономической системы д.б. уточнены границы изучения системы, определен круг пользователей будущей ЭИС различных уровней и выделены классы и типы объектов, подлежащих обследованию и последующей автоматизации.
Важнейшие объекты обследования:
структурно-организационные звенья предприятия (напр, отделы управления, цехи, участки, рабочие места);
функциональная структура, состав хозяйственных процессов и процедур;
стадии (техническая подготовка, снабжение, производство, сбыт)
элементы хозяйственного процесса (средства труда, предметы труда, ресурсы, продукция, финансы).
технологии, методы и технические средства преобразования информации;
Цельи «Сбора материалов обследования»:
выявление осн. параметров предметной области (напр, орг. структура предприятия);
установление условий, в которых будет функционировать проект ЭИС;
выявление стоимостных и временных ограничений на процесс проектирования.
«Сбор материалов» включает в себя следующие работы:
предварительное изучение предметной области;
выбор технологии проектирования;
выбор метода сбора материалов (силами специалистов или проектировщиков; методы опроса, анализа бизнес-процессов и предоставленного материала, метод выборочного хронометража, расчетные методы и др.),
выбор метода обследования (локальное или системное; сплошное или выборочное и т.д.) и метода его проведения (последовательный или параллельный);
разработка программ обследования и календарного плана;
сбор и формализация материалов обследования.
При выполнении «Сбора и формализации материалов обследования» все собранные сведения проверяются совместно с пользователем на их адекватность, после чего формируется «Отчет об обследовании».
На основе формализованного описания предметной области выполняется этап «Анализ материалов обследования».
Состав документов, которые обрабатываются ИС, определяется на этапе формулировки требований к ЭИС. После определения состава документов необходим их анализ, чтобы определить, какая информация об объектах предметной области будет отображаться в ИС.
Целью анализа документов является выявление актуальных, существенных для ИС свойств объектов и их группировка по смыслу.
Анализ документов проводят в следующем порядке:
Анализ структуры документов, выделение существенных признаков, оснований, показателей.
Выявление взаимосвязей между показателями, запись расчетных формул.
Построение графа взаимосвязи показателей.
После этого начинается следующий этап: определение структур данных, хранящихся в базе данных. Для этого чаще всего применяют диаграммы структуры данных (DSD) и ER-диаграммы.
При проектировании структур данных выделяют 3 основных подхода:
Сбор информации об объектах решаемой задачи в рамках одной таблицы (универсального отношения) и последующая ее декомпозиция на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений.
Формулирование знаний о системе и требований к обработке данных, получение с помощью CASE-системы готовой схемы БД или даже готовой прикладной ИС.
Структурирование информации для использования в ИС в процессе проведения системного анализа на основе совокупности правил и рекомендаций.
Технико-экономическое обоснование и техническое задание на проект ИС
После выполнения этапа «Анализ материалов обследования» проектировщики получают количественные и качественные характеристики информационных потоков, описание их структуры и мест обработки, а также объем выполняемых операций и трудоемкость их обработки.
На основе этих материалов разрабатываются два документа:
- Технико-экономическое обоснование проектных решений;
- Техническое задание.
Технико-экономическое обоснование (ТЭО) содержит расчеты и обоснование необходимости разработки ИС для данного предприятия и выбираемые технологические и проектные решения.
В состав технического задания (ТЗ) входят требования к создаваемой ИС и ее отдельным компонентам, а именно:
- программному;
- техническому;
- информационному обеспечению.
Эти документы являются основными для последующего проектирования ИС в соответствии с заданными требованиями.
Понятие типового проектирования ИС
Типовое проектирование ИС предполагает создание системы из готовых типовых элементов. Основополагающим требованием для применения методов типового проектирования является возможность декомпозиции проектируемой ИС на множество составляющих компонентов (подсистем, комплексов задач, программных модулей и т.д.). Для реализации выделенных компонентов выбираются имеющиеся на рынке типовые проектные решения, которые настраиваются на особенности конкретного предприятия.
Типовое проектное решение (ТПР) - это тиражируемое (пригодное к многократному использованию) проектное решение.
классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:
элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);
подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;
объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.
Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.
Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование.
Параметрически-ориентированное проектирование включает следующие этапы: определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач, анализ и оценка доступных ППП по сформулированным критериям, выбор и закупка наиболее подходящего пакета, настройка параметров (доработка) закупленного ППП.
Критерии оценки ППП делятся на следующие группы:
назначение и возможности пакета;
отличительные признаки и свойства пакета;
требования к техническим и программным средствам;
документация пакета;
факторы финансового порядка;
особенности установки пакета;
особенности эксплуатации пакета;
помощь поставщика по внедрению и поддержанию пакета;
оценка качества пакета и опыт его использования;
перспективы развития пакета.
Внутри каждой группы критериев выделяется некоторое подмножество частных показателей, детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП.
Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10-бальной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем.
Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.
Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия.
Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.
Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.
Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС.
Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.
Автоматизированное проектирование ИС с использованием CASE-технологий.
CASE — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов. CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с потребностями пользователей. Большая часть CASE-средств использует методологию структурного (в основном) или ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств.
Преимущества
удачно использовав CASE-технологии в процессе разработки, группа разработчиков получит ряд преимуществ созданной системы:
· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;
· положительное воздействие на некоторые или все из перечисленных факторов: производительность, качество продукции, соблюдение стандартов, документирование;
· приемлемый уровень отдачи от инвестиций в CASE-средства
Проектирование ИС с применением компьютерной поддержки, называется CASE – технологии проектирования. CASE – технологии применяются не только для автоматизации проектирования ИС, но и для разработки моделей бизнес-процессов. Можно выделить следующие основные принципы создания ИС на основе CASE – технологий:
1. принцип всесторонней компьютерной поддержки проектирования.
2. принцип модельного подхода. CASE – система может поддерживать методологию функционально –ориентированного или объектно-ориентированного подхода
3. принцип иерархического представления модели предметной области. Данный принцип выражается в возможности последовательной детализации (декомпозиции) описания системы в соответствии с нисходящим подходом проектирования.
4. принцип наглядности представления модели –означает наличие в составе CASE –технологий визуальных средств проектирования. Система графических изображения и правила, предназначенные для описания структуры системы, элементов данных и т.д., называются нотацией Case – средства.
5. принцип декомпозиции процесса ПИС с применением CASE –технологий на стадии и этапы.
Эффективность применения САSЕ -технологии проектирования ИС проявляется в улучшении качества создаваемого проекта, сокращении стоимостных и временных затрат на всех стадиях жизненного цикла ИС .
Рассмотрим факторы эффективности CASE-технологии.
1. Как отмечалось, САSЕ -технология создает возможность для реинжиниринга бизнеса и предусматривает перенос центра тяжести трудоемкости создания системы на предпроектную и проектную стадии. Тщательная проработка этих стадий в интерактивном режиме с компьютерной поддержкой уменьшает число возможных ошибок проектирования, исправлять которые на последующих стадиях затруднительно.
2. Доступная для понимания пользователей-непрограммистов графическая форма представления модели позволяет следовать принципу пользовательского проектирования, предусматривающему участие пользователей в создании системы. САSЕ -модель способствует взаимопониманию между всеми участниками создания системы (заказчиками, пользователями, проектировщиками, программистами).
3. Наличие формализованной модели системы создает возможность для многовариантного анализа с прототипированием и ориентировочной оценкой эффективности вариантов. САSЕ -модели позволяют осуществлять функционально-стоимостной анализдля выявления и исследования стоимости выполнения той или иной функции. Анализ прототипа системы позволяет скорректировать будущую систему до того, как она будет реализована в окончательном виде. Этот подход ускоряет и удешевляет создание системы.
4. САSЕ -технология позволяет использовать концепцию сборочного проектирования, основанную на повторном использовании типовых проектных решений (компонентов) системы. Сборка прикладной программы из готовых компонентов позволяет значительно сократить стоимость и время разработки ИС.
5. Закрепление и формализованном виде требований к системе избавляет проектировщиков от необходимости многочисленных корректировок в соответствии с новыми требованиями пользователей.
6. Отделение проектирования системы от программирования создает устойчивость проектных решений для реализации на разных программно-технических платформах.
7. Наличие формализованной модели реализации системы и соответствующих средств автоматизации позволяет осуществить автоматическую кодогенерацию программного обеспечения системы и создать рациональную структуру базы данных.
8. На стадии эксплуатации системы появляется возможность внесения изменений на уровне модели, не обращаясь к текстам программ, силами специалистов отдела автоматизации фирмы, т. е. осуществить модификацию проекта.
9. Модель системы может использоваться не только как основа, но и в целях автоматизированного обучения персонала с использованием диаграмм.
10. На основе модели действующей системы может выполняться бизнес-анализ для поддержки управленческих решений и бизнес-реинжиниринг при изменении направления деятельности фирмы.
Классификация CASE средств
Современные CASE-системы классифицируются по следующим признакам:
1) По поддерживаемым методологиям проектирования: функционально (структурно)-ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);
2) По поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;
3) По степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ЭИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);
4) По типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;
5) По режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;
6) По типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).
Рассмотрим классификацию Case-средств по типам и категориям.
Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ и включает следующие типы:
1. Средства анализа и проектирования, предназначенные для построения и анализа как моделей деятельности организации (предметной области), так и моделей проектируемой системы.
К таким средствам относятся BPwin (PLATINUM technology), Silverrun (Silverrun Technologies), Oracle Designer (Oracle), Rational Rose (Rational Software), Paradigm Plus (PLATINUM technology), Power Designer (Sybase), System Architect (Popkin Software).
Их целью является определение системных требований и свойств, которыми система должна обладать, а также создание проекта системы, удовлетворяющей этим требованиям и обладающей соответствующими свойствами. Выходом таких средств являются спецификации компонентов системы и их интерфейсов, алгоритмов и структур данных.
2. Средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL – Structured Query Language – структурированном языке запросов) для наиболее распространенных СУБД. Средства проектирования баз данных имеются в составе таких CASE-средств, как Silverrun, Oracle Designer, Paradigm Plus, Power Designer. Наиболее известным средством, ориентированным только на проектирование БД, является ERwin (PLATINUM technology);
3. Средства управления требованиями, обеспечивающие комплексную поддержку разнородных требований к создаваемой системе.
Примерами таких средств являются RequisitePro (Rational Software) и DOORS – Dynamic Object-Oriented Requirements System – динамическая объектно-ориентированная система управления требованиями (Quality Systems and Software Inc.);
4. Средства управления конфигурацией ПО – PVCS (Merant), ClearCase (Rational Software) и др.;