Тема 6. Понятие индустриального проектирования
Вспомним основные особенности канонического проектирования
Отражает особенности ручной технологии проектирования;
Предполагает выполнение индивидуального (оригинального) проектирования;
Не предполагает использования средств интеграции;
Соответствует каскадной модели ЖЦ ИС.
Индустриальное проектирование:
Используется для проектирования ИС, автоматизирующей работу с большими и сложными объектами.
Предполагает широкое применение интегрированных средств автоматизации проектирования;
Может использоваться как при выполнении оригинальных, так и типовых проектов;
Обычно сочетается с использованием итерационной модели ЖЦ ИС;
Обычно связано со значительной реорганизацией процессов производства и/или управления ОА.
Ключевые аспекты технологии индустриального проектирования:
Реорганизация (реинжиниринг) бизнес-процессов;
Моделирование предметной (проблемной) области;
Средства автоматизированного проектирования ИС (CASE-средства);
Возможность применения типовых решений (типовое проектирование).
Понятие и виды бизнес-процессов
Под бизнес-процессом (БП) будем понимать совокупность взаимосвязанных операций (работ) по изготовлению готовой продукции или выполнению услуг на основе потребления ресурсов.
Основные черты бизнес-процессов:
Все материальные, финансовые и информационные потоки экономической системы рассматриваются во взаимодействии;
Результаты деятельности экономической системы напрямую зависят от того, насколько эффективно организовано управление бизнес-процессами.
Классификация бизнес-процессов (наиболее распространенный подход):
Основные (ориентированы на производство товаров или оказание услуг, являющихся целевыми объектами создания предприятия; эти процессы обеспечивают получение основного дохода).
Сопутствующие (ориентированны на производство товаров или оказание услуг, являющихся результатами сопутствующей основному производству производственной деятельности предприятия; также обеспечивают получение дохода).
Вспомогательные (предназначены для жизнеобеспечения основных и сопутствующих процессов и ориентированы на поддержку их специфических черт).
Обеспечивающие (предназначены для жизнеобеспечения основных и сопутствующих процессов и ориентированы на поддержку их универсальных черт – процессы финансового обеспечения деятельности, процессы управления кадрами, процессы юридического обеспечения и т. п.).
Процессы управления – охватывают весь комплекс функций управления на уровне каждого бизнес-процесса и предприятия в целом (например, процессы стратегического, оперативного и текущего планирования, процессы формирования и выполнения управляющих воздействий).
Процессы развития – процессы совершенствования производимого товара или услуги, процессы развития технологий, процессы модификации оборудования, инновационные процессы.
Основная проблема оптимального управления бизнес-процессами:
Постоянно возрастающая динамичность рынка товаров и услуг (непрерывное изменение потребностей потребителя, необходимость учитывать их сиюминутные и/или индивидуальные предпочтения и пожелания);
Совершенствование технических возможностей производителей;
Постоянно возрастающая конкуренция.
Все эти проблемы вызвали необходимость сместить акценты с управления отдельными функциональными подразделениями на управление сквозными бизнес-процессами, обеспечивающими эффективную и взаимосогласованную деятельность подразделений предприятия.
Понятие реинжиниринга бизнес-процессов
Реинжиниринг бизнес-процессов (Business Process Reengineering, BPR) – это «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов для достижения коренных улучшений в основных показателях деятельности предприятия, таких как затраты, качество, обслуживание и скорость. (М. Хаммер, Д. Чемпи, 1993).
Содержание РБП: Системная реорганизация материальных, финансовых и информационных потоков. РБП не ограничивается, но может включать в себя следующие мероприятия:
Упорядочение и оптимизация организационной структуры;
Реструктуризация производства;
Автоматизация процессов производства;
Автоматизация процессов управления;
Реинжиниринг ПО и КИС;
Цель РБП: Упрощение организационной структуры, перераспределение и минимизация использования различных ресурсов, сокращение сроков реализации потребностей клиентов, повышение качества их обслуживания.
Важно: сокращение затрат НЕ является единственной либо основной целью РБП. Понятие РБП часто подвергалось критике в западных источниках как раз за то, что, прикрываясь идеей реорганизации БП, руководство копаний производило массовое увольнение сотрудников либо снижение заработной платы.
Задачи РБП:
Определение оптимальной последовательности выполняемых функций для сокращения длительности цикла производства или продажи товаров и услуг, или обслуживания клиентов. Следствие: ускорение оборачиваемости капитала, рост экономических показателей фирмы.
Оптимизация использования ресурсов для минимизации издержек производства. Следствие: сокращение издержек.
Поиск оптимального сочетания различных видов деятельности. Следствие: сокращение издержек.
Построение адаптивных бизнес-процессов, позволяющих быстро адаптироваться к изменениям потребности конечных потребителей, поведению конкурентов. Следствие: сокращение издержек, повышение качества обслуживания клиентов в условиях динамичности внешней среды.
Определение рациональных схем взаимодействия с партнерами и клиентами. Следствие: оптимизация финансовых потоков, сокращение издержек, рост прибыли.
Исполнители РБП: Реинжиниринг бизнес-процессов выполняется совместными командами специалистов компании и консалтинговой фирмы. Для успешного проведения РБП необходимы: 1) специалисты в области ИТ; 2) специалисты в соответствующих предметных областях; 3) бизнес-аналитики (специалисты по управлению бизнес-процессами).
Реинжиниринг бизнес-процессов – это одноактная операция, которая носит «революционный» характер. Существующие бизнес-процессы анализируются и заменяются на новые, более эффективные. Однако, из-за описанных выше проблем, через некоторое время возникает потребность повторного выполнения РБП. Поэтому в целом принято говорить о инжиниринге бизнес-процессов, то есть о периодическом (каждые 5-7 лет) реинжиниринге и последующем непрерывном улучшении бизнес-процессов в соответствии с требованиями внешней среды.
«Реинжиниринг бизнес-процессов отражает новый способ мышления – взгляд на построение компании как на инженерную деятельность. Компания или бизнес рассматриваются как нечто, что может быть построено, спроектировано или перепроектировано в соответствии с инжененрными принципами» (Ойхман, Попов).
Более широким понятием, чем РБП, является понятие управления бизнес-процессами.
Управление бизнес-процессами – это область знаний на пересечении теории менеджмента и информационных технологий, включающая в себя методы, технологии и средства проектирования, реализации, мониторинга и анализа оперативных бизнес-процессов на основе всех доступных источников информации.
Инжиниринг бизнес-процессов и информационные технологии
Концепция РБП невозможна без применения современных информационных технологий. Во-первых, анализ и проектирование новых бизнес-процессов в ходе реинжиниринга можно эффективно провести только с использованием специальных компьютерных средств. Во-вторых, автоматизация сложной системы бизнес-процессов стала возможна только с появлением современных информационных технологий и информационных систем (КИС).
Традиционно выделяют следующие технологии, которые в настоящее время больше всего применяются при построении и управлении БП:
Распределенные базы данных, доступные из разных точек;
Экспертные системы, позволяющие специалистам общего профиля решать узкоспециальные задачи;
Телекоммуникационные сети, обеспечивающие сочетание централизованного и децентрализованного подходов к управлению организацией;
Системы поддержки принятия решений, обеспечивающие реализацию иерархического принципа принятия решений (каждый сотрудник участвует в принятии решения).
Беспроводные технологии и портативные ЭВМ, обеспечивающие возможность работы «виртуальных офисов».
Интерактивные видеоконференции, обеспечивающие эффективный контакт с клиентами даже без личного участия;
Автоматическая идентификация отслеживание, сокращающие издержки на поиск нужных объектов и информации;
Высокопроизводительные вычислительные системы, обеспечивающие возможность оперативного планирования и корректировки планов.
При построении корпоративных информационных систем желательно учитывать, что в будущем бизнес-процессы могут измениться, в том числе путем реинжиниринга (то есть кардинально). По этой причине обычно выдвигаются следующие требования к промышленным КИС:
Модульность построения (ИС проектируется, разрабатывается и внедряется в виде отдельных программных компонентов или комплексов, которые автоматизируют определенные виды деятельности организации);
Интегрируемость модулей ИС между собой и с другими ИС на основе стандартов представления форматов данных и интерфейсов;
Масштабируемость КИС, позволяющая наращивать число автоматизированных рабочих мест, подключенных к информационной системе.
Конфиденциальность, предполагающая настройку прав доступа пользователей к информационной системе в зависимости от уровня компетенции.
Современные производители платформ для построения корпоративных информационных систем (например, SAP) обеспечивают все указанные выше требования и заявляют, что их продукты позволяют эффективно выполнять реорганизацию и улучшение бизнес-процессов.
Принципы реорганизации бизнес-процессов
Не улучшение существующих, а замена существующих процессов – после проведения РБП деятельность компании начинается «с чистого листа» без учета всего, что было раньше. Это позволяет разом отказаться от всех тех недостатков прежних бизнес-процессов, которые сохранялись в организации только в силу привычки работников.
Горизонтальное сжатие процесса – несколько процедур объединяются в одну. Постепенно происходит отказ от системы «сборочного конвейера», когда каждый работник выполняет одну единственную функцию. Вместо этого, акцент делается на создание многофункциональных рабочих мест. При этом автоматизация производственных процессов позволяет существенно ускорить выполнение сложной операции, а также передавать ее менее квалифицированному работнику.
Переход от структурных подразделений к командам бизнес-процессов. Для выполнения важнейших бизнес-процессов организуются постоянно или временно действующие команды, которые отвечают за выполнение той или иной операции. Это обеспечивает тесное взаимодействие всех работников, от которых зависит выполнение бизнес-процесса, а также позволяет быстро найти того работника, который отвечает за результат (руководителя команды или уполномоченного менеджера).
Вертикальное сжатие процесса – работники наделяются большей самостоятельностью для принятия решений. Поскольку в настоящее время есть возможность обеспечивать даже рядовых сотрудников всей необходимой производственной информацией в режиме реального времени, то можно исключить часть согласований из иерархической цепочки и ускорить процесс принятия решений.
Адаптивность (поливариантность) исполняемых бизнес-процессов. Рабочие группы, созданные для выполнения конкретного бизнес-проекта, могут выполнять его, ориентируясь на конкретные потребности клиентов.
Перенесение места выполнения работ туда, где ее целесообразно выполнять.
Уменьшение количества проверок и управляющих воздействий.
Сочетание централизованного и децентрализованного подхода к управлению компанией. Децентрализация обеспечивает автономность подразделений (филиалов) компании. При этом должна быть возможность пользоваться централизованными данными и правилами, в том числе оперативно получать необходимые сведения из центра и от других подразделений.
Причины неудачного завершения РБП:
Акцент делается только на эффективность и технологию реорганизуемых процессов, при этом совершенно не учитываются мнение и положение сотрудников организации, в которой происходит РБП.
Несоответствие целей, достигаемых путем РБП, реальным целям компании.
Начало процедуры РБП не обеспечено достаточной поддержкой со стороны менеджеров компании, что мешает ее проведению.
Ожидания от РБП завышены по сравнению с реальными возможностями компании, что ведет к тому, что эти ожидания, в конце концов, не оправдываются.
Недооценивается противодействие изменениям со стороны сотрудников компании.
Выполняется реализация тех типовых процессов, которые хотя и признаны наилучшими в своем классе, но не соответствуют специфическим потребностям организации.
Слишком большое доверие оказывается стандартам и технологиям РБП.
Процедура РБП выполняется как одноразовая процедура раз и навсегда без учета перспектив развития и/или стратегических задач компании.
Низкий уровень управления проектом (в данном случае РБП).
Этапы реорганизации (реинжиниринга) бизнес-процессов
Идентификация бизнес-процессов.
Уточнение (формулировка) миссии предприятия
Миссия компании – это
Деятельность, осуществляемая предприятием для того, чтобы выполнить функцию, для которой оно было учреждено, – предоставления заказчикам продукта или услуги.
Механизм, с помощью которого предприятие реализует свои цели и задачи.
Можно сказать, что миссия является своеобразной мерой устремлений компании, в том числе, характеризует ее претензии на конкурентном рынке.
Формирование стратегии предприятия
Формирование стратегической концепции развития, исходя из сформулированной миссии компании.
Построение дерева целей.
Определение оптимальной стратегии (на основе метода анализа иерархий Саати и других методов) или дерева стратегий;
Формулировка и описание стратегических задач экономической системы.
Проведение статического описания компании
Формулируется бизнес-потенциал компании, описываются ее функционал и организационная структура.
Бизнес-потенциал компании – это набор видов коммерческой деятельности, направленный на удовлетворение некоторых социально-значимых потребностей рынка.
Функционал – это перечень основных, вспомогательных, обеспечивающих и управленческих функций, требуемых для поддержания тех видов коммерческой деятельности, которые образуют бизнес-потенциал компании.
Выявленные функции (производства, управления и т.д.) распределяются по структурным подразделениям. Содержание бизнес-потенциала, функционала и зон ответственности структурных подразделений компании часто представляется в виде матричных проекций.
Матрица проекций – это модель, представленная в виде матрицы, задающей систему отношений между двумя иерархическими наборами значений (классификаторами) в любой их комбинации.
Примеры: матрица коммерческой ответственности, матрица функциональной ответственности и т.д.
Вся выработанная информация отражается в основополагающих регламентирующих документах компании: базовое Положение об организационно-функциональной структуре компании, Положения об отдельных структурных подразделениях и видах деятельности, должностные инструкции сотрудников.
Проведение динамического описания компании
Выявление основных бизнес процессов – как существующих, так и перспективных (10-15). Как правило, эту задачу решают путем построения процессных потоковых моделей.
Процессные потоковые модели – это модели, описывающие процесс последовательного во времени преобразования материальных и информационных потоков компании в ходе реализации какой-либо ее функции. Описание дается на двух уровнях: на верхнем уровне определяется логика взаимодействия участников процесса, а на нижнем – технология работы отдельных специалистов на своих рабочих местах.
Неформальное описание выявленных бизнес-процессов.
Оценка важности бизнес-процессов по степени влияния на совокупные результаты деятельности компании.
Примечание. Совокупность информационных моделей статического и динамического описания компании (миссия + дерево целей + дерево стратегий + модели статического и динамического описания компании + внутренние регламенты компании + регламенты взаимодействия компании с внешней средой) представляют собой полную организационную бизнес-модель компании. Ее необходимо строить и использовать не только на начальном этапе процедуры РБП, но и на этапах обратного и прямого инжиниринга (см. далее), а также при анализе результатов РБП, и при эволюционном улучшении бизнес-процессов в периодах между этими процедурами. Следует помнить, что подходов к построению бизнес-моделей очень много, и рассмотреть все их в данном курсе не представляется возможным.
Рис. 6.1. Трафарет описания миссии компании
Рис. 6.2. Структура матрицы функциональной ответственности
Определение возможностей и ограничений для проведения реорганизации бизнес-процессов, в том числе:
Связанных с достаточной/недостаточной квалификацией персонала;
Связанных с высоким/низким уровнем технической оснащенности;
Связанных с наличием/отсутствием необходимых информационных и иных технологий.
Определение рисков, связанных с проведением РБП (обеспеченность финансовыми ресурсами, надежность партнеров, относительная стабильность конъюнктуры рынка).
Выбор бизнес-процессов, подлежащих реорганизации; формирование целей и задач РБП;
Формирование команды для проведения РБП;
Планирование работ проекта и выделение (планирование выделения) ресурсов.
Обратный инжиниринг – исследование функционирующих на предприятии бизнес-процессов с целью выявления их «узких мест» и выработки направлений по реорганизации.
Проводится анализ и моделирование существующих бизнес-процессов;
С использованием различных методик проводится оценка эффективности БД, в том числе выясняются наиболее трудоемкие и затратные процессы, процессы, не вносящие вклад в образование прибыли, процессы и функции с низким коэффициентом использования ресурсов и т.п.
Уточняются цели и конкретизируются задачи РБП.
В результате обратного инжиниринга формируется информационная модель предметной области (бизнес-модель компании) «как есть».
Прямой инжиниринг – разработка моделей для новой организации бизнес-процессов. Проектируемые модели определяют новую организационную бизнес-модель компании, поэтому должны обеспечивать как ее статическое, так и динамическое описание. Кроме того, на этапе прямого инжиниринга формируются основные требования к информационной системе.
Прямой инжиниринг обычно выполняется с использованием различных программных средств моделирования, которые можно разбить на три класса:
CASE-средства (Rational Rose);
Модельно-ориентированные средства компонентного проектирования (SAP, BAAN и др.)
Специализированные средства для проведения РБП и управления БП (ARIS)
На этапе прямой инжиниринга обычно проводится анализ нескольких вариантов моделей бизнес-процессов. С использованием различных математических методов среди множества вариантов проводится анализ каждой из моделей: оптимизация параметров, поиск значимых факторов, прогнозирование результатов выполнения того или иного сценария работы, выбор оптимальной модели для заданных начальных условий и т.п. В последнее время для этих целей с успехом применяют методы динамического имитационного моделирования, которые могут использоваться не только на этапе моделирования, но и во время адаптации бизнес-процессов (для прогнозирования и обоснования принимаемых решений).
Реализация проекта РБП – сводится к проектированию и реализации информационной системы и ее обеспечивающих подсистем. Фактически предпроектная стадия ЖЦ ИС заключается в проведении процедуры реинжиниринга и выработке общесистемных требований и решений для информационной системы. Многие работы в этом случае проводятся параллельно. После того, как новая бизнес-модель компании принята к исполнению, начинается работа над всеми подсистемами ИС, в том числе
Для организационного обеспечения:
Разработка новой организационно-штатной структуры предприятия;
Разработка новых должностных инструкций;
Разработка новой системы оплаты труда (включая методы стимулирования работников);
Обучение персонала;
Подготовка иной документации по проекту РБП и ИС.
Для программно-аппаратного обеспечения:
Генерация, настройка, программирование и отладка программных модулей;
Разработка и наполнение информационной базы;
Проектирование информационно-вычислительной сети и установка соответствующего оборудования и систем телекоммуникации.
Разработка систем автоматизированного контроля подготавливаемой проектной документации на соответствие ее разделов друг другу и их своевременное обновление.
Внедрение проекта РБП. Проводится в соответствие с уже рассмотренными принципами и методиками внедрения. Особенную важность приобретает процедура комплексного тестирования модулей ИС, а также система анализа достижения заданных в начале РБП показателей эффективности функционирования предприятия.
Методологии моделирования предметной области
В основе проектирования ИС лежит моделирование предметной области. Для того чтобы получить адекватный предметной области проект ИС в виде системы правильно работающих программ, необходимо иметь целостное, системное представление модели, которое отражает все аспекты функционирования будущей информационной системы.
Под моделью предметной области понимается некоторая система, имитирующая структуру и/или функционирование исследуемой предметной области и отвечающая требованию адекватной этой области.
Проблемная область = предметная область + решаемые в ней задачи.
В случае проектирования ЭИС
Проблемная область = предметная область + механизм управления + субъекты управления + используемые средства автоматизации.
Цель моделирования предметной области:
Сократить время и сроки проведения проектировочных работ;
Получить более эффективный и качественный проект (снизить вероятность допущения ошибок);
Снизить риск затрат на перепроектирование системы.
Требования к моделям предметной области
формализация, обеспечивающая однозначное описание структуры предметной области;
понятность для заказчиков и разработчиков на основе применения графических средств отображения модели;
реализуемость, подразумевающая наличие средств физической реализации модели предметной области в ИС;
обеспечение оценки эффективности построенной модели предметной области на основе определенных методов и вычисляемых показателей.
Для реализации перечисленных требований, как правило, строится система моделей, которая отражает структурный и оценочный аспекты функционирования предметной области.
Структурный аспект предполагает построение:
объектной структуры, отражающей состав взаимодействующих в процессах материальных и информационных объектов предметной области;
функциональной структуры, отражающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
структуры управления, отражающей события и бизнес-правила, которые воздействуют на выполнение процессов;
организационной структуры, отражающей взаимодействие организационных единиц предприятия и персонала в процессах;
технической структуры, описывающей топологию расположения и способы коммуникации комплекса технических средств.
Для отображения структурного аспекта моделей предметных областей в основном используются графические методы, которые должны гарантировать представление информации о компонентах системы. Главное требование к графическим методам документирования — простота. Графические методы должны обеспечивать возможность структурной декомпозиции спецификаций системы с максимальной степенью детализации и согласований описаний на смежных уровнях декомпозиции.
С моделированием непосредственно связана проблема выбора языка представления проектных решений, позволяющего как можно больше привлекать будущих пользователей системы к ее разработке.
Нотация представляет собой совокупность графических объектов, используемых в модели. Нотация является синтаксисом языка моделирования.
Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой стороны, предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему программного обеспечения.
Графическое изображение нередко оказывается наиболее емкой формой представления информации. При этом проектировщики должны учитывать, что графические методы документирования не могут полностью обеспечить декомпозицию проектных решений от постановки задачи проектирования до реализации программ ЭВМ. Трудности возникают при переходе от этапа анализа системы к этапу проектирования и в особенности к программированию.
Главный критерий адекватности структурной модели предметной области заключается в функциональной полноте разрабатываемой ИС.
Оценочные аспекты моделирования предметной области связаны с разрабатываемыми показателями эффективности автоматизируемых процессов, к которым относятся:
время решения задач;
стоимостные затраты на обработку данных;
надежность процессов;
косвенные показатели эффективности, такие, как объемы производства, производительность труда, оборачиваемость капитала, рентабельность и т.д.
Для расчета показателей эффективности, как правило, используются статические методы функционально-стоимостного анализа (ABC) и динамические методы имитационного моделирования.
Обычно модели предметной области строятся на трех уровнях абстракции:
на внешнем уровне (определение требований);
на концептуальном уровне (спецификация требований);
на внутреннем уровне (реализация требований).
Так, на внешнем уровне модель отвечает на вопрос, что должна делать система, то есть определяется состав основных компонентов системы: объектов, функций, событий, организационных единиц, технических средств.
На концептуальном уровне модель отвечает на вопрос, как должна функционировать система? Иначе говоря, определяется характер взаимодействия компонентов системы одного и разных типов.
На внутреннем уровне модель отвечает на вопрос: с помощью каких программно-технических средств реализуются требования к системе?
С позиции жизненного цикла ИС описанные уровни моделей соответственно строятся на этапах анализа требований, логического (технического) и физического (рабочего) проектирования.
Основные элементы моделей предметной области можно охарактеризовать с помощью таблицы:
Элемент модели ПО |
Внешний |
Концептуальный |
Внутренний |
Объект – сущность, которая используется при выполнении некоторой функции или операции. Могут быть динамическими или постоянными |
Выделяются основные виды материальных и информационных объектов |
Проводится классификация объектов, уточняются их атрибуты и взаимосвязи; формируется обобщенная структура ПО |
Формируется физическая модель данных, система выходной и выходной документации, а также система справочников и классификаторов ЭИС |
Функция – некоторое преобразование входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций образует бизнес-процесс. |
Выделяется список основных бизнес-процессов (обычно 15-20) и соответствующих им функций |
Производится декомпозиция функций на подфункции до тех пор, пока каждая подфункция не будет представлять собой неделимую операцию (или множество операций). Таким образом, строится иерархия взаимосвязанных функций. |
Выполняется реализация автоматизируемых функций с учетом их иерархической структуры. |
События – изменения во внешней среде или внутри компании, которые влияют на протекание (реализацию) конкретного бизнес-процесса. С информационной точки зрения события представляют собой сообщения, фиксирующие факт некоторого изменения: выполнения очередной функции, изменения состояния объекта, появления нового объекта и т.п. С процедурной точки зрения, каждой событие должно вызывать некоторую связанную с ним функцию бизнес-процесса. С помощью событий в моделях БП можно реализовывать альтернативные или циклические последовательности бизнес-функций. |
1. Определяется список внешних событий (платежи налогов, поставки по договорам, заявления от клиентов и т.п.). 2. Формируется список общих требований к бизнес-процессам.
|
Формируется список бизнес-правил, определяющих условия вызова функций при возникновении событий и достижении определенных состояний объектов. |
Реализация бизнес-правил в виде программных процедур |
Организационная единица – это подразделение, представляющее собой объединение персонала для выполнения совокупности общих функций (функционально-ориентированная ОЕ) или бизнес-процессов (процессно-ориентированная ОЕ). Совокупность взаимосвязанных ОЕ образуют организационную структуру компании |
Модель предприятия в виде иерархии подчинения ОЕ или списков взаимодействующих подразделений. |
Для каждого подразделения строится организационно-штатная структура должностей (ролей) персонала |
Формируются и реализуются требования к правам доступа персонала к автоматизируемым функциям ИС. |
Топология – территориальное размещение технических средств по структурным подразделениям предприятия. Система коммуникаций – технический способ их взаимодействия. |
Определяются типы технических средств обработки данных и их размещение по структурным подразделениям |
Определяется способ коммуникаций между техническими комплексами структурных подразделений. |
Проектируется и реализуется информационно-вычислительная сеть и распределенная модель ИС |
Методики построения бизнес-моделей
Функциональный подход
Предметная область рассматривается как набор функций (работ, действий, и т.п.), преобразующих поступающие входные потоки в выходные. Процесс преобразования потребляет определенные ресурсы и выполняется в соответствии с некоторыми бизнес-правилами и инструкциями. С функциональными моделями обычно связываются объектные модели данных (например, модели «сущность-связь»).
Достоинства: возможность проектирования по принципу «сверху-вниз», наглядность представления, отделение методов обработки объектов от самих объектов.
Недостатки: неясность выполнения процессов с динамически изменяемыми условиями, опасность дублирования выполнения одних и тех же функций в разных процессах.
Примеры: SADT (IDEF0), DFD
Объектно-ориентированный подход
Организация рассматривается как набор объектов (производственных единиц, предметов, явлений и т.п.) и связей между ними. Взаимодействие между объектами производится путем обмена сообщений между ними. Цель применения объектной методики заключается в выделении множества объектов, полностью описывающих предметную область, и распределении между ними ответственностей за выполняемые действия. Этапы построения объектной модели включают в себя выделение классов объектов (множества однородных по поведению объектов) и определение методов обработки (функциональные процедуры) для различных состояний объектов. Объектно-ориентированные модели обычно соответствуют принципам абстрагирования, инкапсуляции, наследования, полиморфизма и т.п.
Достоинства: возможность точно смоделировать существующую структуру организации, лучше подходит для моделирования динамически изменяющихся бизнес-процессов.
Недостатки: меньший уровень наглядности моделей.
Примеры: модели на основе языка моделирования UML.
Комбинированный подход
Автоматизированное проектирование ИС (CASE-технология)
CASE-технология (Computer Aided Software Engineering) представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения, поддержанную комплексом взаимоувязанных средств автоматизации.
Основные черты CASE-технологии:
Назначение: автоматизация проектирования сложных информационных систем. Изначально CASE-средства были ориентированы на разработку ПО. Сейчас чаще всего под такими средствами подразумевают любые средства проектирования ИС и/или моделирования предметной области.
CASE-средства охватывают все стадии ЖЦ ИС (анализ, проектирование, разработка, сопровождение).
Не создают новых методологий, а повышают эффективность использования существующих – за счет автоматизации.
Цели использования CASE-технологии в индустриальном проектировании ИС:
Улучшение качества разрабатываемой ИС за счет автоматического контроля и генерации отдельных элементов;
Возможность повторного использования компонентов разработки;
Повышение уровня адаптивности и качества сопровождения ИС;
Использование методологии прототипного проектирования;
Ускорение работы за счет автоматизированной генерации кода и автоматизированного документирования проекта;
Возможность коллективной разработки ИС в режиме реального времени.
Содержание CASE-технологии:
Методология – определяет шаги реализации проекта, а также правила используемых при его разработки методов.
Метод – процедура или техника генерации описания компонентов ИС (например, метод проектирования потоков данных).
Модель – совокупность символов (вербальных, математических, графических и т.п.), которая адекватно описывает некоторые свойства моделируемого объекта и отношения между ними.
Нотация – Система условных обозначений, принятая в конкретной модели. Обычно для описания моделей используются графические символы (почему?), а также формальные и естественные языки.
Инструментальные средства – CASE-средства.
CASE-средство – это специальный программный продукт, который поддерживает одну или несколько методологий анализа и проектирования ИС.
Общая архитектура системы CASE-средств включает в себя следующие элементы:
Репозиторий (словарь данных) – специализированная база данных, являющаяся ядром системы. Обеспечивает хранение версий проекта и его отдельных компонентов и объектов, синхронизацию поступающей от проектировщиков информации, контроль метаданных на полноту и непротиворечивость. Репозиторий хранит описания следующих объектов:
Проектировщиков и их прав доступа к различным компонентам системы;
Организационных структур;
Диаграмм, компонентов диаграмм и связей между диаграммами;
Структур данных;
Программных модулей, процедур, библиотек и т.п.
…
Графические средства анализа и проектирования (редакторы диаграмм). Используются для создания иерархически связанных диаграмм – моделей ИС – в заданной графической нотации.
Верификатор диаграмм. Служит для контроля правильности построения диаграмм в заданной методологии проектирования. Основные функции: мониторинга, диагностика, информирование об ошибках.
Неграфические средства проектирования и разработки приложений. Используются для построения моделей ИС на формальных и естественных языках, а также для автоматизированной разработки программ проекта.
Документатор проекта. Позволяет получать информацию о проекте в виде различных отчетов.
Средства администрирования проектом. Представляют собой набор инструментов и служебных программ, необходимых для выполнения таких административных функций, как:
Инициализация проекта;
Задание начальных параметров проекта;
Назначение и управление правами доступа к отдельным элементам проекта;
Мониторинг выполнения проекта.
Служебные средства. Представляют собой набор служебных программ, которые необходимы для обслуживания БД репозитория: архивация, восстановление данных и т.п.
Классификация CASE-средств
По области действия в пределах ЖЦ ИС
Upper CASE – средства, используемые на стадии анализа предметной области;
Middle CASE – средства, используемые на стадии анализа и проектирования структуры ИС;
Примечание. В настоящее время в зарубежной литературе имеет место тенденция объединять средства Upper и Middle CASE в одну группу (Upper CASE).
Lower CASE – средства, используемые на стадиях разработки и внедрения (тестирования).
I-CASE – интегрированная система CASE-средств, которая может использоваться как на ранних, так и на поздних стадиях ЖЦ ИС (т.е. объединяет возможности Upper- и Lower- CASE).
По функциональному назначению:
Средства анализа и проектирования ИС (автоматизация наиболее популярных методологий проектирования);
Средства проектирования баз данных (моделирование данных и генерация схем БД);
Средства разработки приложений (в том числе, средства генерации и рефакторинга программного кода, средства быстрой разработки приложений);
Средства обратного инжиниринга (построение моделей действующей ИС для ее переноса в другую среду);
Средства документирования проекта;
Средства управления тестированием ПО;
Средства планирования и управления проектом.
По поддерживаемым методологиям проектирования:
Функционально-ориентированные;
Объектно-ориентированные;
Комплексные (поддерживают различные методологии).
По степени интеграции:
Отдельные средства, которые могут быть использованы на той или иной стадии проектирования ИС.
Частично интегрированные наборы средств, охватывающие несколько стадий разработки ИС;
Полностью интегрированные системы средств, охватывающие несколько стадий разработки ИС и связанные между собой общим репозиторием.
По реализованной архитектуре:
Локальные;
Корпоративные (с поддержкой взаимодействия по корпоративным информационным сетям и возможностью коллективной разработки проекта).
Методологии проектирования ИС с использованием CASE-средств
В настоящее время существует два основных подхода к проектированию, которые мы уже упоминали:
Функционально-ориентированный (структурный);
Объектно-ориентированный.
В основе функционально-ориентированного подхода лежат две идеи:
Декомпозиция;
Графическое представление.
В настоящее время в качестве основных средств структурного анализа и проектирования используют следующие виды диаграмм:
Business Function Diagram (BFD) – диаграммы функциональных спецификаций. Позволяют представить общую структуру исследуемого объекта, отражающую взаимосвязь различных задач в процессе получения требуемых результатов. Основные элементы BFD – это функции (некоторые действия, необходимые для решения поставленных задач) и декомпозиции функций (разбиение функции на множество подфункций). На практике диаграмма функциональных спецификаций, используется, например, для верификации диаграмм сущность-связь при проектировании базы данных ИС.
Диаграммы SADT (диаграммы работ и объектов).
Диаграммы потоков данных (DFD).
State Transition Diagram (STD) – диаграммы переходов состояний. Моделируют поведение системы во времени в зависимости от произошедших событий. Позволяют осуществить декомпозицию управляющих процессов, происходящих в системе и описать отношение между управляющими потоками. С формальной точки зрения, диаграммы переходов состояний описывают некоторый конечный автомат. К основным элементам диаграммы перехода состояний относятся:
Состояние – устойчивое значение некоторого свойства в течение определенного времени. В каждый момент времени система находится строго в одном состоянии. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в следующее состояние.
Начальное состояние – узел диаграммы, являющийся стартовой точкой для начального системного перехода. В диаграмме может быть множество конечных состояний, но только одно начальное.
Переход – определяет перемещение моделируемой системы из одного состояния в другое. Имя перехода определяется событием, которое вызвало этот переход. Переход может быть вызван каким-либо действием.
Триггер – логическое выражение, написанное на каком-либо макроязыке, которое показывает условие перехода в данное состояние.
Применяется два способа построения ST-диаграммы. Первый способ заключается в идентификации всех возможных состояний и дальнейшем исследовании всех не бессмысленных связей (переходов) между ними. По второму способу сначала строится начальное состояние, затем следующие за ним и т.д. В результате формируется предварительная диаграмма перехода состояний, для которой необходимо выполнить контроль состоятельности. Обычно он заключается в ответе на следующие вопросы;
все ли состояния определены и имеют уникальное имя?
все ли состояния достижимы?
все ли состояния имеют выход?
реагирует ли система соответствующим образом на все возможные условия (особенно на ненормальные)?
все ли входные (выходные) потоки управляющего процесса отражены в условиях диаграммы?
Примеры диаграммы переходов состояний:
См. рис. 1
Диаграммы состояний UML.
Диаграммы инфологических моделей «сущность-связь».
System Structure Diagram (SSD) – Диаграммы структуры программного приложения ИС. Представляют собой иерархическую взаимосвязь программных модулей, которые реализуют ИС. Диаграмма SSD служит «мостом» для перехода от системных требований, которые отображены в таких диаграммах, как BFD, DFD, ERD и STD, к реализации информационной системы.
Основные черты Объектно-ориентированного проектирования
Предметная область моделируется как совокупность взаимодействующих во времени объектов;
Процесс обработки информации представляется как последовательность взаимодействий этих объектов;
Данные и операции моделируются совместно (неразрывно друг от друга);
За основу принимается спиральная модель проектирования. Модели предметной области накапливаются в репозитории и постепенно уточняются.
На основе сформированных моделей может быть автоматически сгенерирована система классов для программного приложения ИС;
Для моделирования широко используется унифицированный язык моделирования UML (Unified Modeling Language).
Самостоятельно:
Изучить, какие основные диаграммы включает в себя система объектно-ориентированных моделей в соответствии с нотациями UML;
Изучить общую характеристику и назначение каждой диаграммы;
Обратить внимание на диаграмму прецедентов, диаграмму состояний, диаграмму деятельности, диаграмму компонентов и диаграмму размещения.
Рассмотреть общую схему проектирования экономических ИС в рамках объектно-ориентированного подхода.
Рис.1. Пример диаграммы перехода состояний.
Типовое проектирование ИС
Ключевые особенности технологии типового проектирования
Причины применения:
Существенно снижаются затраты на проектирование, разработку и даже на модернизацию ИС;
Больше возможностей обеспечивать должный научно-технический уровень разработки ИС (в отличие от технологии индивидуального проектирования).
Сущность: Является одной из разновидностей индустриального проектирования. Заключается в создании информационной системы из готовых типовых элементов.
Область применения: автоматизация деятельности таких объектов, для которых характерны общие правила функционирования и управления. В первую очередь, сюда относятся экономические системы, для которых характерны:
Схожая структура и правила управления;
Единые стандарты отчетности;
Схожие комплексы используемых технических и программных средств;
Единая цель существования: извлечение прибыли.
Содержание: Процесс проектирования ИС состоит из следующих основных этапов:
Разбиение проекта информационной системы на отдельные составляющие (компоненты).
Выбор и приобретения имеющихся на рынке типовых проектных решений (тиражируемых продуктов) для каждого компонента ИС.
Настройка и доработка приобретенных типовых проектных решений в соответствии с требованиями конкретной предметной области.
Условия применения:
Должна быть принципиальная возможность декомпозиции информационной системы на множество составляющих компонентов (комплексов, подсистем, программных модулей и т.д.). В зависимости от уровня декомпозиции информационной системы различают следующие классы типовых проектных решений: элементные, подсистемные, объектные.
Понятие, виды и особенности типовых проектных решений
Типовое проектное решение (ТПР) – это представленное в виде комплекта проектной документации и/или набора программных модулей проектное решение, пригодное к многократному использованию.
Основные черты ТПР:
Типовые проектные решения ориентированы на автоматизацию деятельности множества однородных объектов (путем настройки под конкретные особенности каждого из них).
Основная цель применения ТПР – уменьшение трудоемкости и стоимости проектирования и/или разработки ИС.
Создание ТПР возможно только после тщательного и всестороннего изучения предметной области и предполагает обобщение накопленного в частных случаях опыта (путем классификации, типизации, абстрагирования, унификации и т.п.).
Типовые решения бывают простыми или комбинированными. Простые ТПР охватывают только какой-либо один вид обеспечения ИС, комбинированные – два и более. Примеры простых ТПР: Классификаторы (ИО), прикладные программы общего и специального назначения (ПО), инструктирующие руководства по управлению бизнес-процессами (ОО), рекомендации по составлению ТЗ (МО) и т.п.
Требования, выдвигаемые к типовым проектным решениям:
Возможность использования для создания новой ИС при минимальном участии разработчиков ТПР;
Соответствие требованиям положений и стандартов, распространяемых на информационную системы в целом или ее часть.
Способность удовлетворять максимально возможному числу потребностей в рамках своего функционального назначения.
Возможность адаптации к конкретным условиям проекта путем изменения параметров.
Методы типового проектирования
Элементное проектирование
В качестве типового элемента используются простые ТПР, относящиеся к отдельной задаче ИС. В этом случае ИС комплектуется как множество ТПР по отдельным разрозненным задачам. Дополнительные элементы, для которых отсутствуют ТПР, разрабатываются вручную. Обычно рассматривают три группы ТПР:
Типовые проектные решения, обеспечивающие оптимальный выбор и организацию технических средств;
Типовые проектные решения, относящиеся к основным задачам ИС (алгоритмы решения задач, описание входных и выходных данных, программные модули общего и специального назначения и т.д.);
Типовые проектные решения, описывающие должностные инструкции всех категорий работников, связанных с проектированием и функционированием ИС.
Существенный недостаток метода: между отдельными ТПР, как правило, отсутствует информационная/техническая/программная совместимость (проблема «лоскутной автоматизации»).
Подсистемное проектирование
Типовыми элементами выступают пакеты прикладных программ (ППП), которые применяются для автоматизации отдельных функциональных подсистем ИС. ППП обладают следующими свойствами:
Функциональная полнота;
Минимизация внешних информационных связей;
Параметрическая настраиваемость;
Полная интеграция внутри ППП и более высокий (хотя и не полный) уровень интеграции с другими пакетами и отдельными программными продуктами.
С точки зрения проектировщика ИС ППП представляет собой «черный ящик», который преобразует входные информационный и параметрический потоки в выходной поток результатов. В схеме ППП можно выделить следующие элементы:
Информационный поток – исходные данные в электронном или бумажном виде, предназначенные для обработки пакетом;
Результаты работы – представляются в виде отчетов, графиков или документов (в электронном или бумажном виде);
Блок функционирования – обрабатывает исходные данные.
Параметрический поток – содержит информацию, необходимую для настройки пакета на конкретные условия функционирования. Обычно параметрическая информация предоставляется пользователю в виде справочников и/или конфигурационных таблиц. В зависимости от принципа использования параметрического потока выделяют два способа привязки ППП к конкретным условиям системы:
Принцип интерпретации (поглощается самим ППП);
Принцип генерации (на его основе специальная программа-генератор генерирует ППП, настроенный под конкретные условия).
Блок обработки параметров – интерпретирует значения параметров и переносит их непосредственно в прикладные программы.
Блок адаптации – позволяет пользователю адаптировать существующие типовые решения путем доработки существующих или добавления новых модулей ИС. В блок адаптации обычно включаются такие средства как генераторы отчетов, генераторы форм, встроенные макроязыки и т.п.
Пример ППП: «1С: Предприятие».
Недостаток: недостаточный уровень совместимости различных ППП в рамках единой корпоративной ИС.
Объектный метод
Идея метода заключается в создании и повторном использовании законченного (т.е. с полным набором функциональных и обеспечивающих подсистем) типового проекта для автоматизации управления объектом определенной отрасли. Например, ИС школы, ИС больницы, ИС товарного склада и т.п. Сложность применения объектного метода заключается в огромном разнообразии различных объектов, что требует от разработчиков предусматривать все возможные варианты. Современные типовые проекты должны обладать следующими свойствами:
Ориентированы для применения на объектах с высоким уровнем стабильности;
Открытость архитектуры (возможность использования на различных программно-технических платформах);
Высокий уровень масштабируемости;
Высокий уровень адаптивности (возможность конфигурирования в широких пределах).
Объектный метод по определению обеспечивает полную программную совместимость компонентов системы.
Модельно-ориентированный подход
Одна из реализаций объектного метода проектирования – это модельно-ориентированный подход. Развивается как результат использования знаний о инжиниринге бизнес-процессов, автоматизации проектирования и методах типового проектирования информационных систем. Суть его заключается в следующем. Сначала строится модель предметной области, а затем по ней выполняется моделирование информационной системы, то есть конфигурирование и связывание между собой типовых модулей. Все это проводится с использованием единой системы CASE-средств.
Инструментарий типового проектирования ИС на основе модельно-ориентированной технологии включает в себя следующие элементы:
Репозиторий (база метаинформации) содержит:
Множество типовых моделей, которые поставляются разработчиком системы автоматизированного типового проектирования, и расширяются по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.
Базовую модель, которая содержит описание всех бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил и элементов организационной структуры, которые поддерживаются программными модулями типовой ИС.
Модель конкретного объекта автоматизации, которая, возможно, создается с использованием типовых моделей и на основе которой осуществляется конфигурирование программного обеспечения. Строится как структурированное подмножество базовой модели.
Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").
Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций. Для проверки семантической целостности бизнес-процессов, а также для автоматизации их управления разрабатывается набор бизнес-правил.
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала.
CASE-средства для проектирования модели объекта автоматизации (мы их рассматривали ранее). Эти средства обычно интегрированы в систему автоматизированного типового проектирования.
Конфигуратор ИС – программа, которая автоматически генерирует конфигурацию информационной системы по построенной модели предметной области.
Примеры систем автоматизации типового проектирования: SAP, BAAN.
Критерии оценки типовых программных элементов
Самостоятельно
Понятие и особенности IT-консалтинга
IT-консалтинг – это комплекс услуг, обычно предоставляемый компании сторонними специалистами и нацеленный на наилучшее применение информационных технологий для достижения поставленных целей бизнеса.
Содержание IT-консалтинга:
Анализ и формализация требований к информационной системе;
Разработка технического и (в некоторых случаях) рабочего проекта ИС;
Управление процессом проектирования;
Внедрение (в том числе обучение сотрудников) и администрирование ИС;
Анализ и реорганизация бизнес-процессов (спорный вопрос);
Разработка программного обеспечения для выполненного проекта ИС.
Особенности консалтинговых структур:
Главный и единственный их продукт – информационные услуги;
Опыт персонала накапливается постепенно по мере участия в различных проектах;
Независимость от организации-клиента;
Объективность.
Основные виды консалтинговых услуг:
Анализ предметной области и построение соответствующих моделей (представление деятельности организации и принятых в нем технологий в виде иерархии диаграмм, обеспечивающих наглядность и полноту их отображения);
Формирование (на основании проведенного анализа) предложений по:
реорганизации организационно-управленческой структуры;
упорядочиванию информационных потоков (в том числе – документооборота) внутри предприятия;
построению рациональных схем работы подразделений предприятия и его взаимодействия с «внешним миром».
Анализ требований и проектирование спецификаций корпоративных информационных систем;
Выработка рекомендаций и предложений по применимости и внедрению существующих систем управления предприятиями.