Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
203997_F8098_lekcii_informacionnye_sistemy.doc
Скачиваний:
42
Добавлен:
24.09.2019
Размер:
2.35 Mб
Скачать
  • К концу 80-х гг. концепция использования ИС вновь изменяется. Они становятся стратегическим источником информации и используются на всех уровнях предприятия любого профиля. ИТ этого периода, предоставляя вовремя нужную информацию, помогают организации достичь успеха в своей деятельности, создавать новые товары и услуги, находить новые рынки сбыта, обеспечивать себе достойных партнеров, организовывать выпуск продукции высокого качества и по низкой цене и др. Стремление преодолеть недостатки предыдущего поколения ИС породило технологию создания и управления базами данных. База данных создается для группы взаимосвязанных задач, для многих пользователей и это позволяет частично решить проблемы ранее созданных ИС. Вначале СУБД разрабатывались для больших ЭВМ, и их количество не превышало десятка. Благодаря появлению ПЭВМ технология БД стала массовой, создано большое количество инструментальных средств и СУБД для разработки ИС, что в свою очередь вызвало появление большого количества прикладных ИС в прикладных областях.

    Основные черты ИС этого поколения:

    • основу ИО составляет база данных,

    • программное обеспечение состоит из прикладных программ и СУБД.

    • технические средства: ЭВМ 3-4 поколения и ПЭВМ.

    • средства разработки ИС: процедурные языки программирования 3-4 поколения, расширенные языком работы с БД (SQL, QBE).

    • архитектура ИС: наиболее популярны две разновидности: персональная локальная ИС, централизованная БД с сетевым доступом.

    1. Большим шагом вперед явилось развитие принципа "дружественного интерфейса" по отношению к пользователю (как к конечному, так и к разработчику ИС). Например, повсеместно применяется графический интерфейс, развитые системы помощи и подсказки пользователю, разнообразные инструменты для упрощения разработки ИС: системы быстрой разработки приложений (RAD-системы), средства автоматизированного проектирования ИС (CASE-средства). К концу 80-хгодов выявились и недостатки систем этого поколения.

    2. Недостатки информационных систем (ИС) этого поколения:

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

      • внедрение ИС столкнулось с инертностью людей, нежеланием конечных пользователей менять привычный стиль работы, осваивать новые технологии;

      • к квалификации пользователей стали предъявляться более высокие требования (знание ПК, конкретных прикладных программ и СУБД, способность постоянно повышать свою квалификацию.

    2.6. Современные информационные системы (ис)

    В связи с указанными выше недостатками постепенно стало формироваться современное поколение ИС. Техническая платформа - мощные ЭВМ 4-5 поколения, использование разных платформ в одной ИС (большие ЭВМ, мощные стационарные ПК, мобильные ПК). Наиболее характерно широкое применение вычислительных сетей - от локальных до глобальных. Информационное обеспечение: ведутся интенсивные разработки с целью повышения интеллектуальности банка данных в следующих направлениях:

    • новые модели знаний, учитывающие не только структуру информации, но и активный характер знаний,

    • средства оперативного анализа информации (OLAP) и средства поддержки принятия решений (DSS),

    • новые формы представления информации, более естественные для человека (мультимедиа, полнотекстовые БД, гипертекстовые БД, средства восприятия и синтеза речи).

    В последнее время появился широкий спектр специализированных ИС - экономические ИТ (ЭИС), бухгалтерские ИТ (БУИС), банковские ИТ (БИС), ИТ рынка ценных бумаг, маркетинговые ИС (МИС) и т.п.

    2.7. Пользователи информационных систем (ис)

    Пользователей ИС (информационных систем) можно разделить на несколько групп:

    • случайный пользователь, взаимодействие которого с ИС не обусловлено служебными обязанностями;

    • конечный пользователь (потребитель информации) - лицо или коллектив, в интересах которых работает ИС. Он работает с ИС повседневно, связан с жестко ограниченной областью деятельности и, как правило, не является программистом, например, это может быть бухгалтер, экономист, руководитель подразделения;

    • коллектив специалистов (персонал ИС), включающий администратора банка данных, системного аналитика, системных и прикладных программистов.

    Состав и функции персонала ИС - информационных систем:

    • Администратор - это специалист (или группа специалистов), который понимает потребности конечных пользователей, работает с ними в тесном контакте и отвечает за определение, загрузку, защиту и эффективность работы банка данных. Он должен координировать процесс сбора информации, проектирования и эксплуатации БД, учитывать текущие и перспективные потребности пользователей.

    • Системные программисты - это специалисты, которые занимаются разработкой и сопровождением базового математического обеспечения ЭВМ (ОС, СУБД, трансляторов, сервисных программ общего назначения).

    • Прикладные программисты - это специалисты, которые разрабатывают программы для реализации запросов к БД.

    • Аналитики - это специалисты, которые строит математическую модель предметной области, исходя из информационных потребностей конечных пользователей; ставит задачи для прикладных программистов. На практике персонал небольших ИС часто состоит из одного - двух специалистов, которые выполняют все перечисленные функции.

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

    Уровни представлений об информации в информационных системах:

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

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

      • инфологическая (информационно-логическая) модель, которая не привязана к конкретной реализации и ориентирована на пользователя;

      • даталогическая модель, которая учитывает требования конкретной СУБД.

    • Внутреннее (физическое) представление - это организация данных на физическом носителе информации. Этот уровень характеризует представления системных программистов и практически используется только тогда, когда СУБД не обеспечивает требуемого быстродействия или специфического режима обработки данных.

    Методы разработки ИС: при традиционном подходе сначала выявлялись информационные потоки на предприятии, а затем к этой структуре привязывалась ИС, повторяя и закрепляя тем самым недостатки организации бизнеса. В конце прошлого века бурно обсуждалась идея бизнес - реинжиниринга, предложенная М. Хаммером. Она состоит в том, что для получения существенного эффекта от ИС необходимо одновременно с разработкой ИС пересмотреть и бизнес-процессы, удалив и упростив некоторые из них.

    Таким образом, современная ИС должна создаваться как часть предприятия, включающая бизнес-архитектуру, персонал и ИТ.

    2.8. Процессы в информационных системах - ис

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

    • ввод информации из внешних или внутренних источников;

    • обработка входной информации и представление ее в удобном виде;

    • вывод информации для представления потребителям или передачи в другую систему;

    • обратная связь - это информация, переработанная людьми данной организации для коррекции входной информации.

    ИС определяется следующими свойствами:

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

    • является динамичной и развивающейся;

    • при построении необходимо использовать СИСТЕМНЫЙ ПОДХОД;

    • выходной продукцией является информация, на основе которой принимаются решения;

    • следует воспринимать как автоматизированную, т.е. человеко-компьютерную систему обработки информации.

    В настоящее время сложилось мнение об информационной системе как о системе, реализованной с помощью компьютерной техники. Хотя в общем случае информационную систему можно понимать и в некомпьютерном варианте.

    Внедрение ИС - информационной системы - может способствовать:

    • получению более рациональных вариантов решения поставленных задач за счет внедрения математических методов и интеллектуальных систем и т.д.;

    • освобождению работников от рутинной работы за счет ее автоматизации;

    • повышение качества производимых товаров и услуг;

    • обеспечению достоверности информации;

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

    • совершенствованию структуры потоков информации и системы документооборота;

    уменьшению затрат на производство продуктов и услуг.

    • уменьшение затрат на производство продуктов и услуг;

    • предоставление потребителям уникальных услуг;

    • отыскание новых рыночных ниш;

    • привязка к фирме покупателей и поставщиков за счет предоставления им разных скидок и услуг.

    Это и есть цели создания ИС(АСОИ) (что можно ожидать (эффект) от внедрения ИС).

    2.9. Необходимость создания ис(асои)

    Введем следующие обозначения: Р – сложность задач управления; В – валовой внутренний продукт страны; Н – численность занятых в народном хозяйстве.

    а) если рассматривать предприятия как автономные единицы народного хозяйства, то Р = а В, где а – коэффициент линейной связи. Таким образом, сложность задач управления растет пропорционально величине ВВП.

    б) в реальных условиях, когда мы учитываем связи между всеми предприятиями Р > а В, т.е. сложность задач управления растет быстрее, чем ВВП.

    в) B > H, ВВП растет быстрее, чем численность.

    г) Р > а В > H.

    Реально, на основе практического опыта было установлено, что P > H2.

    В развитии любой страны наступает момент, когда сложность задач управления превзойдет суммарную способность всех активных членов общества в переработке информации. Эта ситуация называется второй информационный барьер. Наша страна перешагнула этот барьер вместе с другими развитыми странами в середине 60-х годов.

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

    На конкретном предприятии необходимость создания ИС обусловлена:

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

    - на предприятии высокая численность работающих;

    - предприятие является многопрофильным и занимается разными видами деятельности;

    - на предприятии широкий ассортимент выпускаемой продукции или оказываемых услуг;

    - на предприятии высокий объем выпускаемой продукции или оказываемых услуг;

    - продукция предприятия является наукоемкой;

    - выпуск продукции предприятия осуществляется по сложному технологическому циклу и т.д.

    Все вышеперечисленное усложняет задачи управления предприятием и в современных условиях без ИС на предприятиях не обойтись.

    2.10. Роль структуры управления в ис

    Создание и использование ИС для любой организации предназначены для решения следующих задач:

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

    2.ИС должна контролироваться людьми, ими пониматься и использоваться.

    3.Производство достоверной, надежной, своевременной и систематизированной информации.

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

    3. Теория управления

    Одним из основоположников теории управления, сформулировавший основные функции управления, является Анри Файоль (1841-1925) более 30 лет управлял горно-металлургическим синдикатом. Еще в 1916 г . был опубликован его основной труд "Основные черты промышленной администрации – предвидение, организация, распорядительство, координирование, контроль", который затем неоднократно переиздавался на различных языках. Вместе с Фредериком Тейлором, Генри Фордом и рядом других специалистов Анри Файоль работал над созданием научной теории управления.

    Целенаправленные процессы, выполняемые человеком для удовлетворения различных потребностей, представляют собой организованную и упорядоченную совокупность действий – операций, которые делятся на два основных вида: рабочие операции и операции управления. Управление - элемент, функция организованных систем различной природы (биологических, социальных, технических), обеспечивающая сохранение их определенной структуры, поддержание режима деятельности, реализацию их программ и целей. Для правильного и качественного выполнения рабочих операций необходима технология управления, посредством которых обеспечиваются в нужные моменты начало, порядок следования и прекращение рабочих операций, выделяются необходимые для их выполнения ресурсы, придаются нужные параметры самому объекту. Технология управления - совокупность методов, реализуемых в процессе функционирования системы, которые обеспечивают сохранение ее структуры и поддерживают режимы ее деятельности.

    Предприятие является частным случаем иерархической системы. Это значит, что в структуре предприятия можно выделить несколько уровней. Управление предприятием предназначено для сохранения его миссии и осуществляется путем противодействия разрушению предприятия в результате его взаимодействия с внешней средой. Весь процесс управления распределен по уровням. К задаче верхнего уровня относится координация нижнего уровня. Выделяют следующие типовые уровни.

    3.1. Уровни процесса управления

    Структура управления любой организации традиционно делится на три уровня управления: операционный, функциональный и стратегический, которые определяются сложностью решаемых задач. Чем сложнее задача, тем более высокий уровень управления требуется для ее решения. При этом следует понимать, что более простых задач, требующих немедленного (оперативного) решения, возникает значительно большее количество, а значит, и уровень управления для них нужен другой - более низкий, где принимаются решения оперативно. При управлении необходимо также учитывать динамику реализации принимаемых решений, что позволяет рассматривать управление под углом временного фактора.

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

    Операционный уровень управления (нижний)

    Операционный уровень управления обеспечивает решение многократно повторяющихся задач и операций и быстрое реагирование на изменения входной текущей информации. На этом уровне достаточно велики как объем выполняемых операций, так и динамика принятия управленческих решений. Этот уровень управления часто называют оперативным из-за необходимости быстрого реагирования на изменение ситуации. На уровне оперативного (операционного) управления большой объем занимают учетные задачи.

    Пример

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

    Пользователи ИАСУ этого уровня - исполнители и менеджеры низшего звена (бригадиры, инженеры, ответственные исполнители, мастера, нормировщики, техники, лаборанты и т.п.). Основная задача - оперативное реагирование на изменение ситуации. На всех уровнях управления работают как менеджеры, осуществляющие только общие функции, так и менеджеры-специалисты, которые реализуют функции управления в сфере своей компетенции.

    Пример

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

    Функциональный (тактический) уровень управления

    Функциональный уровень управления обеспечивает решение задач, требующих предварительного анализа информации, подготовленной на первом уровне. ИАСУ этого уровня предназначена для менеджеров среднего звена и специалистов (начальники служб, отделов, цехов, начальник смены, участка, научные сотрудники и т.п.). Основная задача - тактическое управление фирмой при решении основных функций в заданной сфере деятельности.

    На этом уровне большое значение приобретает такая функция управления, как анализ. Объем решаемых задач уменьшается, но возрастает их сложность. При этом не всегда удается выработать нужное решение оперативно, требуется дополнительное время на анализ, осмысление, сбор недостающих сведений и т.п. Управление связано с некоторой задержкой от момента поступления информации до принятия решений и их реализации, а также от момента реализации решений до получения реакции на них.

    Пример

    На основании анализа статистических данных по спросу на продукцию, о ценах конкурентов и пр. прогнозируется прибыль и разрабатывается план выпуска продукции на ближайший период (неделю, месяц, квартал). Результаты принимаемых управленческих решений проявляются спустя некоторое время.

    Cтратегический уровень управления

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

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

    Пример

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

    Функции ИАСУ - информационных автоматизированных систем управления

    Функции ИАСУ определяются на основе целей управления, заданных ресурсов для их достижения и ожидаемого эффекта от автоматизации. В функции ИАСУ включаются: планирование и (или) прогнозирование; учет, контроль, анализ; координацию и/или регулирование. Необходимый набор элементов выбирают в зависимости от вида конкретной ИАСУ.

    Рассматривая процесс управления предприятием как технологию, можно представить его совокупностью циклов, выполняемых работниками аппарата управления, на основе разделения труда. В соответствии с элементами управляемого объекта (труд, средства труда, технология производства, предметы труда, экономические связи и отношения) можно определить и содержание процесса управления как:

    • управление процессом труда (основного и вспомогательного персонала предприятия);

    • управление движением и запасами предметов труда (материальными потоками - ресурсами);

    • управление орудиями и средствами труда (зданиями, сооружениями, оборудованием);

    • управление процессами производства (основного и вспомогательного);

    • управление экономическими связями и отношениями как выраженной стоимостной формой производственного процесса.

    Персонал организации

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

    К валификация персонала по уровням управления

    1) Стратегический – менеджеры высшего звена (стратегическое планирование, координация внутрифирменной тактики).

    2) Функциональный (тактический) – менеджеры среднего звена и специалисты (тактическое управление, решение основных функций в сфере деятельности).

    3) Операционный (оперативный) – исполнители, менеджеры низшего звена (оперативное реагирование на изменение ситуации).

    Прочие элементы организации

    Стандартные процедуры в организации – точно определенные правила выполнения заданий в различных ситуациях.

    Субкультура любой организации – совокупность представлений, принципов, типов поведения.

    3.2. Операции и процедуры

    Все элементы объекта управления связаны между собой через труд в рамках определенной кооперации. Поэтому главным в процессе управления является управление системой совместного труда.

    Разделение труда

    Разделение труда - один из главных принципов организации процесса управления. Он основан на функциональном, профессиональном, квалификационном и операционно-технологическом разделении труда. Функциональное разделение труда в процессе управления основано на иерархии функций управления предприятием (исследовательские, проектные, нормативные, плановые, технические, организационные, координационные, обеспечивающие, учетные и сбытовые) и представляет собой сочетание определенных групп, комплексов операций, устойчиво повторяющихся при их выполнении. Профессиональное разделение труда в процессе управления обусловлено усложнением управленческой деятельности и дифференциацией функций управления, что потребовало привлечения в сферу управления различных специалистов. Квалификационное разделение труда в процессе управления предполагает наличие различных по уровню сложности процедур и операций. Это требует использование различных должностных категорий в штате управленческого аппарата. Содержание труда упомянутых категорий работников определяется процессами. Операциями, приемами труда, существующими связями в системе управления, которые возникают при выполнении тех или других функций управления.

    Рациональное комбинирование операций обеспечивает сочетание операций во времени и в пространстве. Операцию управления расчленяют на отдельные элементы, выполнение которых необходимо для выполнения всей операции. Научный подход к анализу и проектированию управленческих операций возможен при условии разработки организационной модели, достаточно хорошо отражающей свойства и характеристики объекта и пригодной для изучения ее качественными и количественными методами. Закономерное, последовательное прохождение операции во времени и пространстве в совокупности составляет процесс управления предприятием. Таким образом, управленческий процесс складывается из большего или меньшего числа последовательных или параллельных операций и процедур, составляющих в целом технологию управления.

    Большое значение имеет анализ, исследование организационных операций, описание их, типизация и стандартизация, а отсюда и проектирование, совмещение однородных операций, перевод их на машинное исполнение в целях снижения трудоемкости процесса управления. Смена операций, их сочетание, взаимосвязь, переход друг в друга определяется процедурами, которые представляют собой совокупность разнообразных управленческих операций, выполняемых по определенной схеме (алгоритму).

    Процедура

    Понятие "процедура" отражает порядок подготовки, рассмотрения, обсуждения, выполнения ряда последовательных и параллельных операций в процессе управления, предписание о порядке выполнения какой-либо работы в аппарате управления. Понятие "технология управления" тесно связано с процессом алгоритмизации операций и процедур в рамках тех или иных функций управляющей системы. Алгоритм исследуемого (проектируемого) организационного или информационного процесса представляет собой правила последовательной организации определенных, связанных друг с другом операций, на которые этот процесс может быть разложен и которые должны быть осуществлены для достижения цели, стоящей перед данной управляющей системой. При этом весь процесс как бы разлагается сверху вниз, т.е. от конкретной функции управленческого аппарата к подфункции (части функции), от подфункции к конкретной процедуре и далее к операции. Управленческая процедура представляет собой систему последовательно реализуемых предписаний (правил) о выполнении в определенном порядке организационных, информационных и других операций, приводящих к решению задач, стоящих перед системой управления.

    Операции и процедуры различаются по ряду признаков и подразделяются на:

    • по должностным признакам: творческие; логические; технические. Удельный вес творческих операций у руководителей составляет до 60%, у специалистов - 40%, у технических исполнителей - до 20%.

    • по содержанию: информационные; логико-мыслительные; организационные.

    • по степени повторяемости: повторяющиеся; неповторяющиеся.

    • по уровню механовооруженности: ручные; механизированные; автоматизированные; машинно-ручные.

    • по характеру сочетания во времени: последовательные; параллельные; последовательно-параллельные.

    3.3. Функции управления

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

    Управление – целенаправленный процесс, включающий в себя некоторые основные элементы, рассматриваемые как основные функции управления. В практике управления различают два вида функций управления.

    Виды функций управления

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

    • конкретные – более обособлены, представляют собой самостоятельные области профессиональной деятельности. Именно на основе анализа конкретных функций формируют структуру управления, осуществляют подбор и расстановку кадров, разрабатывают системы информации, организации делопроизводства. Конкретные функции управления позволят четко определить, что, кому и когда делать. Выполнение конкретных функций в комплексе составляет процесс управления организацией (предприятием). Отсюда можно сделать основной вывод, что выполнение конкретных функций зависит от компетентности, гибкости, оперативности, предприимчивости менеджеров и, как следствие, успешное выполнение производственных заданий, качество работы и продукции, конкурентоспособность выпускаемого продукта.

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

    • установление тесных контактов с отделом исследований и разработок;

    • подготовка новой продукции к запуску в производство;

    • планирование приобретения оборудования и подготовка к работе;

    • стимулирование развития инициативы работников к рационализации;

    • анализ стоимости работ, использования ЭВМ и бюджета отдела.

    Функция производственного отдела можно декомпозировать и определить подфункции:

    • рациональное использование производственных мощностей, инструментов и приспособлений;

    • определение норм времени на изготовление продукции;

    • обеспечение качества работ;

    • подготовка производственной документации;

    • определение сумм капитальных вложений;

    • разработка форм обслуживания потребителей продукции;

    • разработка форм повышения квалификации и переподготовки кадров.

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

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

    Функция управления - учет

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

    Учет - процесс получения объективной информации о складывающейся на объекте ситуации путем сбора фактических значений параметров и их обработки по заданным алгоритмам. После доведения планов до исполнителя, часто оказывается, что предприятие отклоняется от плана. Причины могут быть разными: влияние среды, неточность и неверность исполнения, несовершенство самого планирования. Для того, чтобы вывести предприятие на плановую траекторию, нужно регулировать его деятельность. А для этого нужно собрать данные о работе этого предприятия. Сбором данных для формирования, отчетности занимается фаза учета. Учет использования ресурсов, учет выпускаемой продукции, учет выполнения внешних заказов, учет финансов и многие другие.

    Данная функция управления предназначена для фиксации состояний объекта управления, получение полной информации об объекте в интересующем аспекте, а также формулировку целей, т.е. чего именно требуется достичь. Четко сформулированные цели играют важную роль в управлении и планировании. Цель – идеальное мысленное предвосхищение результата деятельности; желаемый результат, которого стремится добиться человек или целое предприятие, ставящие перед собой эту цель. Были сформулированы некоторые правила постановки целей: цели должны быть конкретными; реальными; гибкими и способными к корректировке; совместимыми; понимаемыми людьми.

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

    Анализ - функция управления

    Анализ или аналитическая функция связана с изучением итогов выполнения планов и заказов, определением влияющих факторов, выявлением резервов, изучением тенденций развития и т.п. Выполняется анализ разными специалистами в зависимости от сложности и уровня анализируемого объекта или процесса. Анализ результатов хозяйственной деятельности фирмы за год и более проводят специалисты, а на уровне цеха, отдела – менеджер этого уровня (начальник или его заместитель) совместно со специалистом – экономистом.

    Анализ - процесс генерирования альтернатив на основании складывающейся на объекте ситуации и желаемых значений параметров, задаваемых на фазе "Планирование", с одной стороны, и постановка диагноза и выявление причин отклонения движения системы от заданной траектории, с другой стороны. На основе учтенных данных формулируются выводы о различных сторонах работы предприятия.

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

    После проведения анализа ситуации выявляются проблемы и свободные ресурсы. При составлении планов проблемы лягут в основу целей, а свободные ресурсы послужат средством к достижению этих целей.

    Планирование - функция управления

    Планирование (плановая функция) состоит в разработке и реализации планов по выполнению поставленных задач. Например, бизнес-план для всей фирмы, план производства, план маркетинговых исследований, финансовый план, план проведения научно-исследовательской работы и т.п. на различные сроки (год, квартал, месяц, день).

    Планирование - это ориентированный в будущее систематический процесс принятия решений, которое вырабатывается на основе целей, формулируемых вышестоящей организацией, и альтернатив, генерируемых на фазе "Анализ". В понятие "планирование" входит определение целей и путей их достижения. В экономике планирование деятельности предприятий осуществляется по таким важным направлениям, как сбыт, финансы производство и закупки. При этом, конечно, все частные планы тесно взаимосвязаны между собой. По мнению многих авторов, планирование – одна из важнейших функций управления.

    Процесс планирования проходит в 4 этапа.

    Этапы процесса планирования

    • разработка общих целей;

    • определение конкретных, детализированных целей на заданный,

    • сравнительно короткий период времени;

    • определение задач и средств их решения;

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

    Планирование всегда ориентируется на данные прошлого, но стремится определить и контролировать развитие предприятия в перспективе, поэтому надежность планирования зависит от точности фактических показателей прошлого.

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

    Пример

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

    Результаты планирования часто оформляют в виде "бизнес-плана". Бизнес-план является одним из первых обобщающих документов обоснования инвестиций и содержит данные о виде и объемах выпуска продукции, характеристики рынков сбыта и сырья, потребность производства в земельных, энергетических и трудовых ресурсах, а также содержит ряд показателей, дающих представление о коммерческой, бюджетной и экономической эффективности рассматриваемого проекта и в первую очередь представляющих интерес для участников-инвесторов проекта.

    Ясно, что реально используемые фирмами технологии планирования достаточно сложны. Обычно им занимаются специальные подразделения. Полезными оказываются математические методы планирования. В 1975 г . Нобелевскую премию по экономике получили советский математик Леонид Витальевич Канторович и американский экономист Тьяллинг Купманс (родился в Нидерландах). Премия была присуждена за разработку теории оптимального использования ресурсов, которая составляет важную часть математического арсенала плановика.

    Функция управления - регулирование

    Регулирование - формирование корректирующих управляющих воздействий, приводящих объект управления в желаемое состояние для реализации выбранного на фазе "Планирование" решения. Также, это подбор, анализ и оценка способов достижения поставленных целей. Анри Файоль считает, что управление, как регулирование, включает в себя и составление перечня необходимых действий, т.е. что конкретно нужно сделать, чтобы осуществить выбранный на предыдущем этапе вариант достижения поставленных целей.

    Контроль - функция управления

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

    Контроль – это сравнение фактического состояния объекта с желаемым. На предприятии могут применяться следующие типы контроля.

    Типы контроля

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

    • решение по планированию – эти решения принимаются чаще, чем организационные. Должны учитывать сложившуюся организацию бизнес процессов на предприятии. И во многом определяют те решения, которые будут приниматься на следующих уровнях.

    • оперативные управленческие – в основном применяются для воздействия на объект управления с целью удерживания плановых показателей. Эти решения принимаются чаще.

    Сколь бы хорошо ни были разработаны планы, они, как правило, не могут быть выполнены так, как были задуманы. Будущее нельзя абсолютно точно предсказать. Неблагоприятные погодные условия, аварии на производстве и на транспорте, болезни и увольнения сотрудников и многие другие причины нарушают планы. Эти нарушения, прежде всего, надо обнаружить с помощью системы контроля. Например, надо регулярно - раз в день, неделю или месяц - возвращаться к плану и выявлять нежелательные отклонения от запланированного. Есть два основных подхода к отклонениям:

    Подходы к отклонениям

    • решения, обусловленные технологией и планом работ - возврату на плановую траекторию развития. Для этого понадобятся дополнительные ресурсы - материальные, кадровые, финансовые. Иногда такие ресурсы создают согласно плану, заранее предвидя возможность осложнений. Но приходится мириться с тем, что в благоприятной обстановке такие ресурсы будут "простаивать"

    • решения при появлении нештатных ситуаций (аварии, конфликты) - изменение плана. Намеченные рубежи заменяются на другие, реально достижимые в создавшейся обстановке. Возможность такого подхода зависит от того, насколько для предприятия важен план - является ли он "законом" или же только "руководством к действию", задающим желательное направление движения.

    Контроллинг

    Современным этапом последней функции является контроллинг. Контроллинг (control - руководство, регулирование, управление, контроль) - новая концепция управления, порожденная практикой современного управления предприятием. Согласно Файолю, "одной из основных причин возникновения и внедрения концепции контроллинга стала необходимость в системной интеграции различных аспектов управления бизнес-процессами в организационной системе (предприятии, фирме, банке, органе государственного управления и др.)". Контроллинг обеспечивает методическую и инструментальную базу для поддержки" (в том числе компьютерной) основных функций управления: планирования, контроля, учета и анализа, а также оценки ситуации для принятия управленческих решений".

    Стимулирование или мотивационная функция – разработка и применение различных методов стимулирования труда подчиненных работников:

    - финансовые стимулы – зарплаты, премия, акции, повышение в должности и т.п.;

    - психологические стимулы – благодарности, грамоты, звания, степени, доски почета и т.п.

    В последние годы в сфере управления стало применяться понятие "принятие решения" и связанные с ним системы, методы, средства поддержки принятия решений.

    Принятие решения – целенаправленное воздействие на объект управления, основанное на анализе ситуации, определении цели, разработке программы достижения этой цели.

    Структура управления любой организации делится на три уровня: операционный, функциональный и стратегический.

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

    3.4. Принципы управления

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

    Субъект управления

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

    Цель управления

    Управления всегда осуществляется с определенной целью, которая всегда конкретная для заданного объекта управления и связанная с состоянием объекта и среды, в котором он находится. Очень важно определить цель управления, которая для каждого управляемого объекта может быть одна и одна и та же. Степень достижения поставленной цели управления определяется по помощи целевой функции управления. Анализ структурной схемы ИАСУ показывает, что для реализации оптимального управления не достаточно иметь целевую функцию управления и заданные для нее ограничения. Нужна также информация о состоянии объекта управления и внешней среды и о великом множестве возможных состояний элементов системы управления. Без информации не существует управления. Больше того, управления именно и являются беспрерывным процессом переработки информации: на основании одной информации вырабатывается другая, которое, в свою очередь, становится материалом для получения новой, и т.д.

    Управляющие действия, которые поступают из управляющей части в управляемую, могут быть разные по характеру: энергетические, материальные, информационные — в зависимости от природы управляемого объекта. Среди всех систем в особенности выделяются системы, управляемым объект которых являются люди или коллективы людей. Такие системы называются системами организационного управления, или организационными. Поскольку управляющие действия в них направленные на организацию (согласования) поведения коллективов людей и есть информационными. Для этих систем исполняется кибернетическое определение управления как процесса целенаправленной переработки информации.

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

    Принцип разомкнутого управления

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

    Близость х к х0 обеспечивается жесткостью характеристик схемы. При наличии значительных возмущающих воздействий f величина х может заметно отклониться от заданной, при этом управление станет непригодным и следует использовать другие принципы управления.

    Такая схема получила распространение, в основном, в вычислительной технике.

    Принцип управления по отклонению

    Принцип управления по отклонению (принцип обратной связи) . Этот принцип является одним из наиболее ранних и широко распространенных принципов управления. В соответствии с этим принципом система управления наблюдает за объектом, на который воздействуют возмущающие факторы. В результате, в поведении объекта возникают отклонения. Система управления отслеживает наблюдаемые параметры (переменные) и на основе наблюдений создает алгоритм управления. Особенность этого принципа заключается в том, что система управления начинает действовать на объект только после того, как факт отклонения уже свершился. Это и есть "обратная связь". Схема управления изображена на рисунке.

    При такой схеме полная компенсация влияния возмущающих воздействий невозможна. Тем не менее, схема управления с обратной связью получила наибольшее распространение на практике. Это объясняется простотой ее реализации.

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

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

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

    Принцип управления по возмущению

    Принцип управления по возмущению - принцип компенсации. Отклонение регулируемой величины зависит не только от возмущающего воздействия, но и от управления. Принцип управления по возмущению основывается на том, что система управления наблюдает за возмущающими факторами и, учитывая их, строит алгоритм управления так, чтобы действие этих факторов на систему компенсировалось. Функциональная схема управления по возмущению показана на рисунке.

    Данная схема применяется в случае, когда влияние возмущающих воздействий существенно, и в случае отсутствия их учета система может сильно отклоняться от желаемого состояния.

    При такой схеме теоретически возможна полная компенсация влияния возмущений, но только по тем воздействиям, по которым ведется учет. Однако в реальной системе невозможно вести учет всех возмущений, поэтому невозможна и полная компенсация их влияния.

    Системы управления по возмущению в сравнении с системами, действующими по отклонению, отличаются обычно большими устойчивостью и быстродействием. К их недостаткам относятся трудность измерения нагрузки в большинстве схем, неполный учет возмущений ( компенсируются только те возмущения, которые измеряются ). Во многих случаях весьма эффективно применение комбинированного управления по возмущению и отклонению, широко используемое, например, для регулирования напряжения мощных синхронных генераторов на крупных электростанциях (компаундирование с коррекцией). Комбинированное управление объединяет достоинства двух принципов, но, естественно, схема управления усложняется, а затраты увеличиваются.

    Принцип оптимального управления

    В соответствии с этим принципом управление должно быть наилучшим. Можно выделить два типа задач оптимального управления:

    • оптимизация конечного состояния объекта управления. Исследуется и оптимизируется конечное состояние объекта, каким "путем" объект пришел в это состояние не учитывается. Задачи этого типа получили распространение в системах организационного и социально – экономического управления. Например, задача планирования выпуска продукции. Решаются такие задачи с использованием методов математического программирования (метода исследования операций).

    • оптимизация динамики (переходного процесса) состояния объекта управления. Рассматривается траектория переходного процесса, а конечный результат не представляет интереса. Эти задачи наиболее применимы в технике и при управлении технологическими процессами. Решаются они на основе вариационного исчисления, таких методов, как принцип максимума Понтрягина, Беллмана и др.

    3.5. Информационные технологии и системы управления

    Качество управления определяется заданным критерием, правилами принятия решения и используемой информацией. То или иное состояние, в которое переходит предприятие при осуществлении своей деятельности на рынке, ставит перед менеджером соответствующие задачи и требует от него принятия адекватных решений. Эти решения могут касаться как изменения целей, стоящих перед организацией, так и способов их достижения. Это вызвано тем, что предприятие подвержено воздействию со стороны окружающей его среды, и вынуждено адаптироваться к ней с помощью обратных связей. Поэтому всякое управленческое решение есть результат отработки менеджером воздействий обратной связи. Принятие решений осуществляется, в основном, уполномоченными на это менеджерами, на основании анализа информации. Поэтому в основе управленческих технологий лежат процессы обработки информации (информационные технологии), и строящиеся на их основе процедуры принятия решений.

    Информационные технологии управления

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

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

    В большинстве случаев ИТ управления направлена на создание отчетов различных видов.

    Виды отчетов

    • регулярные отчеты создаются в соответствии с установленным графиком, определяющим время их создания, например месячный анализ выполнения производственного плана.

    • специальные отчеты создаются по специальным запросам менеджеров или когда на предприятии произошло что-то незапланированное.

    И те, и другие виды отчетов могут иметь форму суммирующих, сравнительных и чрезвычайных отчетов.

    Формы отчетов

    • суммирующие отчеты - данные объединены в отдельные группы, отсортированы и представлены в виде промежуточных и окончательных итогов по отдельным полям;

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

    • чрезвычайные отчеты - содержат данные исключительного (чрезвычайного) характера.

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

    Требования к отчетам

    • отчет должен создаваться только тогда, когда отклонение произошло;

    • сведения в отчете должны быть отсортированы по значению критического для данного отклонения показателя;

    • все отклонения желательно показать вместе, чтобы менеджер мог уловить существующую между ними связь;

    • в отчете необходимо показать количественное отклонение от нормы.

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

    • входная информация поступает из систем операционного уровня

    • выходная информация формируется в виде управленческих отчетов в удобном для принятия решения виде

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

    • данных, накапливаемых на основе оценки операций, проводимых фирмой;

    • планов, стандартов, бюджетов и других нормативных документов, определяющих планируемое состояние объекта управления (подразделения фирмы).

    Информационные системы управления (ису)

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

    Чтобы легче ориентироваться в этих системах вводится 3 классификации

    Классификация

    • по виду решаемой задачи,

    • по масштабу решаемой задачи,

    • по технологическому построению.

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

    Задачи обработки данных

    • оценка планируемого состояния объекта управления;

    • оценка отклонений от планируемого состояния;

    • выявление причин отклонений;

    • анализ возможных решений и действий.

    Информационная автоматизированная система управления (ИАСУ)

    ИАСУ - это многоуровневые иерархические автоматизированные системы, которые обеспечивают комплексную автоматизацию управления на всех уровнях и охватывают весь цикл работ от проектирования до сбыта продукции. Предназначена для обеспечения эффективного функционирования управляемого объекта (системы) путем автоматизированного выполнения заданных функций. Степень автоматизации функций управления определяется производственной необходимостью и возможностями формализации процесса управления. Создание таких систем весьма затруднительно, поскольку требует системного подхода с позиций главной цели, например получения прибыли, завоевания рынка сбыта и т. д.

    Основными классификационными признаками, определяющими вид ИАСУ, являются:

    • сфера функционирования объекта - промышленность, строительство, транспорт, сельское хозяйство, непромышленная сфера и т.д.;

    • вид управляемого процесса - технологический, организационный, экономический и др.;

    • уровень в системе управления - государственный, отраслевой, промышленное, научное или торгово-производственное объединение, предприятие, производство, цех, участок, технологический агрегат или процесс.

    Различают 6 основных типов ИАСУ, тип которых определяется целью, ресурсами, характером использования и предметной областью:

    Типы информационных автоматизированных систем управления (иасу)

    Диалоговая система обработки запросов

    ( Transaction Processing System ) - для реализации текущих, краткосрочных, тактического характера, часто рутинных и жестко структурируемых и формализуемых процедур, например, обработка накладных, ведомостей, бухгалтерских счетов, складских документов и т.д.

    Система информационного обеспечения

    ( Information Provision System ) - для подготовки информационных сообщений краткосрочного (обычно) использования тактического или стратегического характера, например, с использованием данных из базы данных и структурированных, формализованных процедур.

    Система поддержки принятия решений

    ( Decision Support System ) - для анализа (моделирования) реальной формализуемой ситуации, в которой менеджер должен принять некоторое решение, возможно, просчитав различные варианты потенциального поведения системы (варьируя параметры системы); такие системы используются как в краткосрочном, так и в долгосрочном управлении тактического или стратегического характера в автоматизированном режиме.

    Интегрированная, программируемая система принятия решения

    ( Programmed Decision System ) , предназначена для автоматического, в соответствии с программно реализованными в системе структурированными и формализованными критериями оценки и отбора (выбора) решений; используются как в краткосрочном, так и в долгосрочном управлении тактического (стратегического) характера.

    Экспертные системы

    ( Expert System ) - информационные консультирующие и\или принимающие решения системы, основанные на структурированных, часто плохо формализуемых процедурах, использующих опыт, интуицию т.е. поддерживающие или моделирующие работу экспертов, интеллектуальные особенности; системы используются как в долгосрочном, так и в краткосрочном оперативном прогнозировании, управлении;

    Интеллектуальные системы или системы, основанные на знаниях

    (Knowleadge Based System) - системы поддержки задач принятия решения в сложных системах, где необходимо использование знаний в достаточно широком диапазоне, особенно, в плохо формализуемых и плохо структурируемых системах, нечетких системах и при нечетких критериях принятия решения; эти системы наиболее эффективны и используемы для сведения проблем долгосрочного, стратегического управления к проблемам тактического и краткосрочного характера, повышения управляемости, особенно, в условиях многокритериальности. В отличие от экспертных систем, в системах основанных на знаниях следует чаще избегать экспертных и эвристических процедур и прибегать к когнитивным процедурам для минимизации риска. Здесь более существенно влияние профессионализма персонала, ибо при разработке таких систем необходимо сотрудничество и взаимопонимание не только разработчиков, но и пользователей, менеджеров, а сам процесс разработки, как правило, происходит итерационно, итерационными улучшениями, постепенным преобразованием (переходом) процедурных знаний (как делать) в непроцедурные, декларативные (что делать).

    Ис организационного управления (исоу)

    ИС организационного управления, известны также под устаревшим названием «автоматизированные системы организационного управления — АСОУ», уже свыше 20 лет успешно используются в разных областях экономики. За это время их эволюция прошла несколько этапов, начиная от простых систем обработки данных к интегрированным системам, которые построенные на современной аппаратной и программной базе. Перспективные типы ИС построенные на клиент-серверной архитектуре. Они делятся на две основных группы: интегрированные и узкоспециализированные системы.

    Корпоративные информационные системы

    К первому типу относятся корпоративные информационные системы (КИС), которые интенсивно вытесняют традиционные АСУП в сфере управления производством. Они поддерживают конкретные бизнес-процессы предприятий, выполняя наиболее ответственные функции; складывания и анализ консолидированного баланса и аналитических отчетов, управления финансами и персоналом, себестоимостью и торговыми операциями и т.п., их характерная особенность — способность работать в территориально распределенных структурах. В Украине наибольшего распространения приобрели такие корпоративные информационные системы: система R/3 компании SAP AG, система «ГАЛАКТИКА» одноименной корпорации, «BAAN-IV» американско-голландской компании Baan , SCALA шведской компании Bestlutsmodeller AB, пакет бизнес-прикладных программ Oracle Application американской корпорации Oracle , информационная система АВД украинско-русской фирмы «ИНЭК».

    Класс информационных систем второго типа довольно широкий. Сюда можно отнести: информационные системы для автоматизации банковской деятельности, информационные системы в статистике, информационные системы для финансового и бухгалтерского учета (например, ІС, FinExpert , SoNet), информационные системы в маркетинге, информационные системы в инвестиционном менеджменте (например, Project Expert ) и др. Следует заметить, что количество разновидностей таких систем постоянно увеличивается, а диапазон функциональных возможностей их расширяется.

    Предназначены для автоматизации функций управленческого персонала. Учитывая наиболее широкое применение и разнообразие этого класса систем, часто любые ИС понимают именно в данном толковании. К этому классу относятся ИС управления, как промышленными фирмами, так и непромышленными объектами: гостиницами, банками, торговыми фирмами и др.

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

    Большинство систем такого типа появились на рубеже 90-х годов, когда, с получением большей свободы в ведении бизнеса, предприятия и фирмы стали задумываться о компьютеризации. В силу объективных причин рыночной экономики, первыми смогли выделить необходимые финансовые средства предприятия торговли и сферы услуг. Промышленность значительно отставала из-за более длительного цикла оборачиваемости капитала и многих других причин.

    Практически все отечественные ИС начали развиваться как учетные бухгалтерские системы. Многие из них продолжают оставаться чисто учетными, позволяя автоматизировать одну или несколько функций предприятия, но, не давая целостной картины для управления. Автоматизация отдельной функции предприятия, как-то бухгалтерский учет или сбыт готовой продукции, позволяет руководителю среднего звена анализировать результаты своей работы.

    4. Структура ис

    Структуру ИС составляет совокупность отдельных ее частей, называемых подсистемами. Подсистема — это часть системы, выделенная по какому-либо признаку. Если общую структуру ИС рассматривать как совокупность подсистем независимо от сферы применения, то в этом случае подсистемы называют обеспечивающими.

    Среди основных подсистем ИС обычно выделяют информационное, техническое, математическое, программное, организационное и правовое обеспечение (см. рисунок).

    Обеспечивающая часть

    Функциональная часть

    1) Информационное обеспечение

    2) Техническое обеспечение

    3) Математическое обеспечение

    4) Программное обеспечение

    5) Организационное обеспечение

    6) Правовое обеспечение

    7) Лингвистическое обеспечение

    8) Эргономическое обеспечение

    Типовые подсистемы:

    Управление кадрами

    Управление финансами

    Бухгалтерский учет

    Оперативное управление

    Текущее управление

    Стратегическое управление

    Специфические подсистемы:

    Производственные подсистемы

    Управление маркетингом

    Управление сбытом

    Управление снабжением

    Управление автотранспортом

    Управление торговлей

    Операционный день банка и т.д.

    4.1. Виды обеспечений ис

    В состав ИАСУ - информационной автоматизированной системы управления - входят следующие виды обеспечений:

    • информационное обеспечение : классификаторы технико-экономической информации, нормативно-справочная информация, форма представления и организация данных в системе, в том числе формы документов, массивов и логические интерфейсы (протоколы обмена данными);

    • программное обеспечение: программы, необходимые для реализации всех функций ИАСУ в объеме, предусмотренном техническим заданием;

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

    • техническое обеспечение: технические средства, необходимые для реализаций функций ИАСУ: средства получения, ввода, подготовки, обработки, хранения (накопления), регистрации, вывода, отображения, использования, передачи информации и средства реализации управляющих воздействий;

    • организационное обеспечение : документы, определяющие функции подразделений управления, действия и взаимодействие персонала ИАСУ;

    • метрологическое : метрологические средства и инструкции по их применению;

    • правовое обеспечение: нормативные документы, определяющие правовой статус ИАСУ и персонала, правил функционирования ИАСУ и нормативы на автоматически формируемые документы, в том числе на машинных носителях информации;

    • лингвистическое обеспечение: тезаурусы и языки описания и манипулирования данными

    Структуры ИАСУ характеризуют внутреннее строение системы и описывают устойчивые связи между ее элементами. При описании ИАСУ пользуются следующими видами структур, отличающимися типами элементов и связями между ними:

    Виды структур:

    • функциональная структура: элементы – функции, задачи, операции; связи – информационные;

    • техническая: элементы – устройства ввода, хранения, обработки информации и другие; связи – линии связи между устройствами;

    • организационная структура: элементы – коллективы людей и отдельные исполнители; связи – информационные, соподчинения и взаимодействия;

    • алгоритмическая: элементы – алгоритмы; связи – информационные;

    • программная структура: элементы – программные модули; связи – информационные и управляющие;

    • информационная структура: элементы – формы существования и представления информации в системе (файлы, таблицы, массивы, базы данных и т.п.); связи – операции преобразования информации.

    При построении (выборе, адаптации) информационной системы можно использовать две основные концепции, два основных подхода (третья концепция - их комбинации), выбор которых зависит от стратегических (тактических) и/или долгосрочных (краткосрочных) критериев, проблем, ресурсов:

    • ориентация на проблемы, которые необходимо решать с помощью этой информационной системы, т.е. проблемно-ориентированный подход (индуктивный);

    • ориентация на технологию, которая доступна в данной системе, среде, т.е. технолого-ориентированный подход (дедуктивный).

    Ошибки в выборе подхода (проблем, технологии) могут привести не только к ошибочным стратегиям и/или тактике, но и к полному краху. Если вначале изучаются возможности имеющейся технологии, а после их выяснения определяются актуальные проблемы, которые можно решить с их помощью, то необходимо опираться на технолого-ориентированный подход. Если же вначале определяются актуальные проблемы, а затем внедряется технология достаточная для решения этих проблем, то необходимо опираться на проблемно-ориентированный подход.

    4.1.1. Информационное обеспечение ис

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

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

    Разработаны стандарты, где устанавливаются требования:

    - к унифицированным формам документации;

    - к унифицированным формам документов различных уровней управления;

    - к составу и структуре реквизитов и показателей;

    - к порядку внедрения, ведения и регистрации унифицированных форм документов.

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

    - исключение дублирующей и неиспользуемой информации;

    - классификацию и рациональное представление информации.

    Методология построения баз данных состоит из 2-х этапов:

    1-й этап – обследование всех функциональных подразделение фирмы с целью:

    - понять специфику и структуру ее деятельности;

    - построить схему информационных потоков;

    - проанализировать существующую систему документооборота;

    - определить информационные объекты и соответствующий состав реквизитов (параметров, характеристик), описывающих их свойства и назначение.

    2-й этап – построение концептуальной информационно-логической модели данных для обследованной на 1-м этапе сферы деятельности. В этой модели должны быть установлены все связи между объектами и их реквизитами. На основе информационно-логической модели строится база данных.

    Информационное обеспечение. Классификаторы. Методы классификации.

    Назначение подсистемы информационного обеспечения состоит в своевременном формировании и выдаче достоверной информации для принятия управленческих решений.

    Понятие информационное обеспечение

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

    Системы классификации и кодирования информации

    Классификаторы представляют собой систематический свод, перечень каких-либо объектов, позволяющий находить каждому их них свое место, и имеют определенное (обычно числовое) обозначение. Система классификации позволяет сгруппировать объекты выделить определенные классы, которые будут характеризоваться рядом общих свойств. Классификация объектов — это процедура группировки на качественном уровне, направленная на выделение однородных свойств. Применительно к информации как к объекту классификации выделенные классы называют информационными объектами.

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

    Классификатор — систематизированный свод наименований и кодов классификационных группировок.

    Назначение классификатора:

    • систематизация наименований кодируемых объектов;

    • однозначная интерпретации одних и тех же объектов в различных задачах;

    • возможность обобщения информации по заданной совокупности признаков;

    • возможность сопоставления одних и тех же показателей, содержащихся в формах статистической отчетности;

    • возможность поиска и обмена информацией между различными внутрифирменными подразделениями и внешними информационными системами;

    • экономия памяти компьютера при размещении кодируемой информации.

    Разработаны три метода классификации объектов, которые различаются разной стратегией применения классификационных признаков.

    Методы классификации объектов:

    • Иерархический метод классификации

    Учитывая достаточно жесткую процедуру построения структуры классификации, необходимо перед началом работы определить ее цель, т.е. какими свойствами должны обладать объединяемые в классы объекты. Эти свойства принимаются в дальнейшем за признаки классификации. В иерархической системе классификации каждый объект на любом уровне должен быть отнесен к одному классу, который характеризуется конкретным значением выбранного классификационного признака. Для последующей группировки в каждом новом классе необходимо задать свои классификационные признаки и их значения. Таким образом, выбор классификационных признаков будет зависеть от семантического содержания того класса, для которого необходима группировка на последующем уровне иерархии. Количество уровней классификации, соответствующее числу признаков, выбранных в качестве основания деления, характеризует глубину классификации.

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

    • Фасетный метод классификации

    В отличие от иерархической позволяет выбирать признаки классификации независимо как друг от друга, так и от семантического содержания классифицируемого объекта. Признаки классификации называются фасетами (facet — рамка). Каждый фасет содержит совокупность однородных значений данного классификационного признака. Причем значения в фасете могут располагаться в произвольном порядке, хотя предпочтительнее их упорядочение. Схема построения фасетной системы классификации представляется в виде таблицы. Названия столбцов соответствуют выделенным классификационным признакам (фасетам). В каждой клетке таблицы хранится конкретное значение фасета. Процедура классификации состоит в присвоении каждому объекту соответствующих значений из фасетов. Достоинства фасетной системы классификации: возможность создания большой емкости классификации, т.е. использования большого числа признаков классификации и их значений для создания группировок; возможность простой модификации всей системы классификации без изменения структуры существующих группировок. Недостатком фасетной системы классификации является сложность ее построения, так как необходимо учитывать все многообразие классификационных признаков.

    • Дескрипторный метод классификации

    Для организации поиска информации, для ведения тезаурусов (словарей) эффективно используется дескрипторная (описательная) система классификации, язык которой приближается к естественному языку описания информационных объектов. Особенно широко она используется в библиотечной системе поиска.

    • Система кодирования

    Применяется для замены названия объекта на условное обозначение (код) в целях обеспечения удобной и более эффективной обработки информации. Система кодирования - совокупность правил кодового обозначения объектов. Код строится на базе алфавита, состоящего из букв, цифр и других символов. Код характеризуется: длиной - число позиций в коде, и структурой — порядок расположения в коде символов, используемых для обозначения классификационного признака.

    Унифицированные системы документации создаются на государственном, республиканском, отраслевом и региональном уровнях. Главная цель — это обеспечение сопоставимости показателей различных сфер общественного производства. Разработаны стандарты, где устанавливаются требования:

    • к унифицированным системам документации;

    • к унифицированным формам документов различных уровней управления;

    • к составу и структуре реквизитов и показателей;

    • к порядку внедрения, ведения и регистрации унифицированных форм документов.

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

    • чрезвычайно большой объем документов для ручной обработки;

    • одни и те же показатели часто дублируются в разных документах;

    • работа с большим количеством документов отвлекает специалистов от решения непосредственных задач;

    • имеются показатели, которые создаются, но не используются, и др.

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

    Схемы информационных потоков отражают маршруты движения информации и ее объемы, места возникновения первичной информации и использования результатной информации. За счет анализа структуры подобных схем можно выработать меры по совершенствованию всей системы управления.

    Пример.

    Простейшая схема потоков данных – схема, в которой отражены все этапы прохождения служебной записки или записи в базе данных о приеме на работу сотрудника - от момента ее создания до выхода приказа о его зачислении на работу.

    Построение схем информационных потоков, позволяющих выявить объемы информации и провести ее детальный анализ, обеспечивает:

    • исключение дублирующей и неиспользуемой информации;

    • классификацию и рациональное представление информации.

    При этом подробно должны рассматриваться вопросы взаимосвязи движения информации по уровням управления. Следует выявить, какие показатели необходимы для принятия управленческих решений, а какие нет. К каждому исполнителю должна поступать только та информация, которая используется.

    Методология построения БД - баз данных базируется на теоретических основах их проектирования. Для понимания концепции методологии приведем основные ее идеи в виде двух последовательно реализуемых на практике этапов:

    • 1-й этап — обследование всех функциональных подразделений предприятия с целью:

      • понять специфику и структуру его деятельности;

      • построить схему информационных потоков;

      • проанализировать существующую систему документооборота;

      • определить информационные объекты и соответствующий состав реквизитов (параметров, характеристик), описывающих их свойства и назначение.

    • 2-й этап — построение концептуальной информационно-логической модели данных для обследованной на 1-м этапе сферы деятельности. В этой модели должны быть установлены и оптимизированы все связи между объектами и их реквизитами. Информационно-логическая модель является фундаментом, на котором будет создана база данных.

    Для создания информационного обеспечения необходимо:

    • ясное понимание целей, задач, функций всей системы управления организацией;

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

    • совершенствование системы документооборота;

    • наличие и использование системы классификации и кодирования;

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

    • создание массивов информации на машинных носителях, что требует наличия современного технического обеспечения.

    4.1.2. Техническое обеспечение ис

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

    Комплекс технических средств составляют:

    - компьютеры любых моделей;

    - устройства сбора, накопления, обработки и вывода информации;

    - устройства передачи данных и линий связи;

    - оргтехника и устройства автоматического съема информации;

    - эксплуатационные материалы и др.

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

    Можно разделить на три группы:

    - общесистемную, включающую государственные и отраслевые стандарты по техническому обеспечению;

    - специализированную, содержащую комплекс методик по всем этапам разработки технического обеспечения;

    - нормативно-справочную, используемую при выполнении расчетов по техническому обеспечению.

    Формы организации технического обеспечения (ТО).

    Централизованное ТО – использование в ИС больших ЭВМ и вычислительных центров.

    Децентрализация технических средств – реализация функциональных подсистем на ПК непосредственно на рабочих местах.

    Перспективным подходом считается частично-децентрализованный подход – организация ТО на базе распределенных сетей, состоящих из ПК и больших ЭВМ для хранения баз данных, общих для любых функциональных подсистем.

    Техническое обеспечение информационной системы - ис

    Понятие технического обеспечения ИС - информационной системы.

    Техническое обеспечение ИС - информационных систем — это комплекс технических средств, обеспечивающих работу ИС, соответствующей документации на эти средства и технологические процессы.

    В комплекс технических средств входят:

    • компьютеры любых моделей;

    • устройства сбора, накопления, обработки, передачи и вывода информации;

    • устройства передачи данных и линий связи;

    • оргтехника и устройства автоматического съема информации;

    • эксплуатационные материалы и др.

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

    Документацию можно условно разделить на три группы:

    • общесистемную, включающую государственные и отраслевые стандарты по техническому обеспечению;

    • специализированную, содержащую комплекс методик по всем этапам разработки технического обеспечения;

    • нормативно-справочную, используемую при выполнении расчетов по техническому обеспечению.

    4.1.3. Математическое и программное обеспечение ис

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

    К математическому обеспечению относятся:

    - средства моделирования процессов управления;

    - типовые задачи управления;

    - методы математического программирования, математической статистики, теории массового обслуживания и др.

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

    К общесистемному программному обеспечению относятся комплексы программ, ориентированных на пользователей и предназначенных на решения типовых задач обработки информации (ПО для разработки программных комплексов: операционные системы, СУБД, языки программирования). Они служат для расширения функциональных возможностей компьютеров и управления процессом обработки данных.

    Специальное ПО представляет собой совокупность программ, разработанных при создании конкретной ИС (решение конкретных задач пользователя). В его состав входят пакеты прикладных программ (ППП).

    Техническая документация на разработку программных средств должны содержать описание задач, задание на алгоритмизацию, экономико-математическую модель задачи, контрольные примеры.

    Математическое и программное обеспечение информационных систем - ис

    Математическое и программное обеспечение — это совокупность математических методов, моделей, алгоритмов и программ для реализации целей и задач ИС, а также нормального функционирования комплекса технических средств.

    К средствам математического обеспечения относятся:

    • средства моделирования процессов;

    • типовые задачи;

    • методы математического программирования, математической статистики, теории массового обслуживания и др.

    К средствам программного обеспечения (ПО) относятся:

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

    • Специальное ПО - программное обеспечение - представляет собой совокупность программ, разработанных при создании конкретной ИС. В его состав входят пакеты прикладных программ реализующие разработанные модели разной степени адекватности, отражающие функционирование реального объекта.

    • Техническая документация на разработку программных средств должна содержать описание задач, задание на алгоритмизацию, экономико-математическую модель задачи, контрольные примеры.

    4.1.4. Методическое и организационное обеспечение ис

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

    Это методические и руководящие материалы по стадиям разработки, внедрения и эксплуатации информационной системы (предпроектного обследования, технического задания, технико-экономического обоснования, разработки проектных решений, выбора автоматизируемых задач, типовых проектных решений пакетов прикладных программ, внедрения и эксплуатации информационной системы).

    Функции организационного обеспечения:

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

    - подготовка задач к решению на компьютере, включая техническое задание на проектирование ИС и технико-экономическое обоснование ее эффективности;

    - разработка управленческих решений по составу и структуре организации, методологии решения задач, направленных на повышение эффективности системы управления.

    Организационное обеспечение создается по результатам предпроектного обследования на 1-м этапе построения баз данных.

    Организационное обеспечение информационных систем - ис

    Организационное обеспечение — это совокупность методов и средств, регламентирующих взаимодействие работников с техническими средствами и между собой в процессе разработки и эксплуатации ИС.

    Организационное обеспечение реализует следующие функции:

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

    • подготовку задач к решению на компьютере, включая техническое задание на проектирование ИС и технико-экономическое обоснование ее эффективности;

    разработку управленческих решений по составу и структуре организации, методологии решения задач, направленных на повышение эффективности системы управления. Организационное обеспечение создается по результатам предпроектного обследования на 1-м этапе построения БД.

    4.1.5. Правовое обеспечение ис

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

    Главная цель правового обеспечения – укрепление законности.

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

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

    Главной целью правового обеспечения является укрепление законности.

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

    Правовое обеспечение этапов разработки ИС включает нормативные акты, связанные с договорными отношениями разработчика и заказчика и правовым регулированием отклонений от договора.

    Правовое обеспечение этапов функционирования ИС - информационных систем - включает:

    • статус ИС;

    • права, обязанности и ответственность персонала;

    • правовые положения отдельных видов процесса управления;

    • порядок создания и использования информации и др.

    Правовое регулирование на информационном рынке

    Развитие рыночных отношений в информационной деятельности поставило вопрос о защите информации как объекта интеллектуальной собственности и имущественных прав на нее.

    В Российской Федерации принят ряд указов, постановлений, законов, таких как:

    1)«Об информации, информатизации и защите информации» - является основным;

    2)«Об авторском праве и смежных правах»;

    3)«О правовой охране программ для ЭВМ и баз данных»;

    4)«О правовой охране технологий интегральных схем» и др..

    Закон 1) закладывает юридические основы гарантий прав граждан на информацию. Он направлен на урегулирование важнейшего вопроса экономической реформы – формы, права и механизма реализации собственности на накопленные информационные ресурсы и технологические достижения. Обеспечена защита собственности в сфере информационных систем и технологий, что способствует формированию –цивилизованного рынка информационных ресурсов, услуг, систем, технологий, средств их обеспечения.

    4.1.6. Лингвистическое обеспечение ис

    Лингвистическое обеспечение – языки общения с пользователем, язык запросов, язык информационно-поисковых систем (ИПС), языки-посредники в сетях и т.д.

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

    Состав: информационные языки для описания структурных единиц информационной базы (документов, показателей, реквизитов и т.п.); языки управления и манипулирования данными; языковые средства ИПС; языковые средства автоматизации проектирования; диалоговые языки специального назначения и др.; система терминов и определений, используемых в процессе разработки и функционирования автоматизированных систем управления.

    4.1.7. Эргономическое обеспечение ис

    Эргономическое обеспечение – комплекс мероприятий, обеспечивающих максимально комфортные условия использования ИС (выбор специальной мебели, организация картотек для хранения документов, магнитных носителей (дисков)). Функция – уменьшение отрицательного воздействия на человека со стороны ЭВМ.

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

    Эргономическое обеспечение – комплекс мероприятий, обеспечивающих максимально комфортные условия использования АРМ специалистами: выбор специальной мебели для размещения техники, организацию картотек для хранения документации и магнитных носителей. Главная функция ЭО – уменьшение отрицательных воздействий на человека со стороны ПЭВМ.

    4.1.8. Кадровое обеспечение ис

    Кадровое обеспечение – это совокупность методов и средств по организации и проведению обучения персонала приемам работы с ИС. Его целью является поддержание работоспособности ИС и возможности дальнейшего ее развития. Кадровое обеспечение включает в себя методики обучения, программы курсов и практических занятий, технические средства обучения и правила работы с ними и т.д.

    Обучение и сертификация персонала — учебно-методическая документация и набор требований к уровню подготовки персонала, формирование системы отбора и подготовки персонала.

    4.2. Классификация ис по функциональному признаку и уровням управления

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

    Типовыми видами деятельности производственных и коммерческих объектов являются: производственная, маркетинговая, финансовая и кадровая.

    Производственная деятельность связана с непосредственным выпуском продукции и направлена на создание и внедрение в производство научно-технических новшеств.

    Маркетинговая деятельность включает в себя:

    - анализ рынка производителей и потребителей выпускаемой продукции, анализ продаж;

    - организацию рекламной кампании по продвижению продукции;

    - рациональную организацию материально-технического снабжения.

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

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

    Направления деятельности определили типовой набор ИС:

    - производственные системы;

    - системы маркетинга;

    - финансовые и учетные системы;

    - системы кадров (человеческих ресурсов);

    - прочие типы, выполняющие вспомогательные функции в зависимости от специфики деятельности фирмы.

    Функции ИС

    Система маркетинга:

    - исследование рынка и прогнозирование продаж;

    - управление продажами;

    - рекомендации по производству новой продукции;

    - анализ и установление цены;

    - учет заказов.

    Производственные системы:

    - планирование объемов работ и разработка календарных планов;

    - оперативный контроль и управление производством;

    - анализ работы оборудования;

    - участие в формировании заказов поставщикам;

    - управление запасами.

    Финансовые и учетные системы:

    - управление портфелем заказов;

    - управление кредитной политикой;

    - разработка финансового плана;

    - финансовый анализ и прогнозирование;

    - контроль бюджета;

    - бухгалтерский учет и расчет зарплаты.

    Система кадров:

    - анализ и прогнозирование потребности в трудовых ресурсах;

    - ведение архивов записей о персонале;

    - анализ и планирование подготовки кадров.

    Прочие системы, например ИС руководства:

    - контроль за деятельностью фирмы;

    - выявление оперативных проблем;

    - анализ управленческих и стратегических ситуаций;

    - обеспечение процесса выработки стратегических решений.

    По уровням управления ИС подразделяются на:

    ИС оперативного уровня – основной поставщик информации для других ИС. Является связующим звеном между фирмой и внешней средой. Поддерживает специалистов-исполнителей, обрабатывая данные о сделках и событиях (счета, накладные, зарплата, кредиты, поток сырья и материалов). Назначение ИС – отвечать на запросы о текущем состоянии и отслеживать поток сделок в фирме.

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

    ИС специалистов – помогают специалистам, работающим с данными, повышают продуктивность и производительность работы инженеров и проектировщиков. Задача – интеграция новых сведений в организацию и помощь в обработке бумажных документов.

    Можно выделить 2 группы:

    1) ИС офисной автоматизации;

    2) ИС обработки знаний.

    1) – выполняют следующие функции:

    - обработки текстов на компьютерах с помощью различных текстовых процессоров;

    - производство высококачественной печатной продукции;

    - архивация документов;

    - электронные календари и записные книжки для ведения деловой информации;

    - электронная и аудиопочта;

    - видео- и телеконференции.

    2) ИС обработки знаний, в том числе и экспертные системы, вбирают в себя знания, необходимые инженерам, юристам, ученым при разработке и создании нового продукта.

    Ис для менеджеров среднего звена

    Используются работниками среднего управленческого звена для мониторинга (постоянного слежения), контроля, принятия решений и администрирования. Основные функции:

    - сравнение текущих показателей с прошлыми;

    - составление периодических отчетов за определенное время (а не выдача текущих отчетов, как на оперативном уровне);

    - обеспечение доступа к архивной информации и т.д.

    На этом уровне можно выделить 2 типа ИС: управленческие (для менеджмента) и системы поддержки принятия решений.

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

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

    Стратегические ис

    Развитие и успех фирмы во многом определяется принятой в ней стратегией. Под стратегией понимается набор методов и средств решения перспективных долгосрочных задач. Появился новый тип ИС – стратегический.

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

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

    На фирму воздействуют внешние факторы:

    - конкуренты, проводящие на рынке свою политику;

    - покупатели, обладающие разными возможностями по приобретению товаров и услуг;

    - поставщики, которые проводят свою ценовую политику.

    Фирма может обеспечить себе конкурентное преимущество, если будет учитывать эти факторы и придерживаться следующих стратегий:

    - создание новых товаров и услуг;

    - отыскание рынков сбыта;

    - создание прочных связей с покупателями и поставщиками;

    - снижение стоимости продукции.

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

    Практические рекомендации по описанию задач, решаемых функциональными подсистемами

    Бухгалтерия: учет по счетам материалов, основных средств, кассовых и банковских операций и т.д., составление периодической отчетности, проведение инвентаризаций, начисление заработной платы и т.д.

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

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

    Отдел сбыта: реализация готовой продукции, заключение договоров с заказчиками и отслеживание их выполнения, решение споров после отгрузки продукции и т.д.

    Маркетинг: изучение рынка, создание системы сбыта и распределения созданной продукции, реклама, ценообразование, послепродажное обслуживание потребителей и т.д.

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

    Подготовка производстве:

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

    технологическая – разработка технологии производства, составление технологических карт, расчет удельных норм расхода сырья и т.д.

    конструкторская – инженерные расчеты, проектные работы: составление чертежей, схем, планов, моделирование проектируемых объектов и т.д.

    Практически в каждой фирме для обеспечения основной деятельности должен быть реализован базовый набор функций. К этим функциям относятся:

    1) стратегическое планирование и управление;

    2) анализ деятельности и оперативное управление;

    3) финансовые функции;

    40 работа с персоналом;

    5) юридическое обеспечение;

    6) электронная обработка данных;

    7) поддержка проектов;

    8) маркетинг, реклама и выставки;

    9) обеспечение коммуникаций;

    10) транспортное обеспечение;

    11) складское обслуживание;

    12) логистика отгрузок;

    13) логистика снабжения и поставок;

    14) таможенные функции;

    15) секретариат (управление делами);

    16) ведение архива;

    17) протокольные функции;

    18) безопасность;

    19) охрана труда;

    20) хозяйственные операции;

    21) капитальное строительство и ремонт;

    22) взаимодействие с филиалами.

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

    Информационные системы (ис) в фирме

    В любой фирме желательно иметь несколько локальных ИС разного назначения, которые взаимодействуют между собой и поддерживают управленческие решения на всех уровнях.

    Примеры ис, поддерживающих деятельность фирмы

    Управленческие решения на разных уровнях

    ИС

    учета и хранения

    сырья и матери-

    алов

    ИС

    оперативного

    контроля

    за производ-

    стром

    ИС

    взаимодей-

    ствия с постав-

    щиками

    ИС

    маркетинга

    и продаж

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

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

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

    Примеры ис

    ИС по отысканию новых рыночных ниш. ИС регистрирует данные о покупателе, что позволяет:

    - определять группы покупателей, их состав и запросы;

    - посылать потенциальным покупателям различные предложения, рекламу, напоминания;

    - предоставлять постоянным покупателям товары и услуги в кредит, со скидкой, с отсрочкой платежей.

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

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

    ИС автоматизации технологии ("менеджмент уступок"). При том, что доход фирмы остается в рамках рентабельности, потребителю делаются разные скидки в зависимости от количества и длительности контрактов. Потребитель заинтересован во взаимодействии с фирмой, привлекается дополнительное число клиентов. Если же клиент переходит на обслуживание к другой фирме, то его затраты могут возрасти.

    4.3. Принципы и методы создания ис

    Еще в 60-е годы прошлого столетия были сформулированы шесть основополагающих принципов, на которые необходимо опираться в процессе создания ИС: новых задач; системного подхода; первого руководителя; разумной типизации проектных решений; непрерывного развития системы; минимизации ввода-вывода информации. Развитие технической основы создания компьютеров и ИТ привело к переформулированию этих принципов и в ГОСТ РД 50-680-88 к ним отнесены следующие: системность, развитие (открытость), совместимость, стандартизация (унификация) и эффективность.

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

    В настоящее время существует ряд общих методологий разработки ИС. Главное в них – единая дисциплина работы на всех этапах жизненного цикла системы, учет критических задач и контроль их решения, применение развитых инструментальных средств поддержки процессов анализа, проектирования и реализации ИС.

    Принципы создания ис

    Принцип системности.

    По принципу системности ИС следует рассматривать как системы, структура которых определяется функциональным назначением. (ИС рассматривается как система, что позволяет выявить многообразные типы связей между структурными элементами).

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

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

    Нельзя разрабатывать какую-либо задачу автономно от других и реализовывать только отдельные ее аспекты. Задача должна рассматриваться комплексно со всеми возможными информационными связями.

    Пример:

    Отбор персонала на вакантные рабочие места. Ее решение должно осуществляться с учетом следующих моментов:

    • использования результатов периодически проводимого профессионального и психофизиологического тестирования работников;

    • анализа результатов периодически проводимой аттестации рабочих мест;

    • анализа показателей трудовой дисциплины персонала;

    • разработки общих и дополнительных критериев отбора (при наличии нескольких претендентов на одно рабочее место);

    • использования банка данных претендентов, сформированного ранее;

    • индивидуального собеседования;

    • анализа анкетных данных и резюме (если претендент не является членом трудового коллектива).

    Принцип развития (открытости)

    Принцип новых задач (развития) - возможность постоянного пополнения и обновления ИС. Число решаемых задач постоянно увеличивается и меняется методика их решения.

    Заключается в том, что внесение изменении в систему, обусловленных самыми различными причинами (внедрением новых информационных технологии, изменением законодательства, организационной перестройкой внутри фирмы и т. п.), должно осуществляться только путем дополнения системы без переделки уже созданного, т. е. не нарушать ее функционирования. Реализовать данный принцип на практике достаточно сложно, так как он требует очень глубокой аналитической предпроектной работы. Необходимо разделить решаемые задачи на определенные группы и для каждой из них предусмотреть возможные направления развития (например, выход в глобальные сети, применение средств для сканирования документов, шифрование информации).

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

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

    Принцип совместимости

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

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

    Если в локальных сетях относительно несложно установить и соблюдать стандарты "общения" отдельных бизнес-процессов между собой и со смежными системами, то выход в глобальные сети требует:

    • дополнительных ужесточенных мер по защите информации;

    • знания и соблюдения различного рода протоколов, регламентирующих все пилы информационных обменов:

    • знание сетевого этикета, предусматривающего такие правила, как:

      • регулярная проверка своей электронной почты;

      • периодическая чистка своего почтового ящика;

      • корректность в составлении сообщений;

      • указание координат для обратной связи и т.п.

    Принцип стандартизации (унификации)

    Принцип стандартизации и унификации – необходимость применения типовых, унифицированных и стандартизованных элементов функционирования ИС.

    При создании системы должны быть рационально использованы типовые, унифицированные и стандартизованные элементы, проектные решения, пакеты прикладных программ, комплексы, компоненты.

    Задачи необходимо разрабатывать таким образом, чтобы они подходили к возможно более широкому кругу объектов. Игнорирование именно этого принципа привело в свое время к тому, что подсистема УК, несмотря на традиционный перечень задач и алгоритмов их решения, разрабатывалась на каждом предприятии самостоятельно, что привело к совершенно неоправданному расходу трудовых, материальных, финансовых и временных ресурсов.

    В современных разработках пакетов прикладных программ (ППП) рассматриваемый принцип задействован. Однако при знакомстве с конкретным ППП необходимо обращать внимание на сущность реализации типовых решений, поскольку каждый разработчик по-своему "видит" такие решения. Например, во многих пакетах по управлению кадрами присутствует задача "Отбор кадров". Однако в пакете фирмы Infin она реализована достаточно оригинально. Решение ее заключается в следующем. Экран разделен на две половины. Слева выводится достаточно большой список мужских и женских имен, по которому перемещается курсор. Если интересующее имя отмечено, то для него с правой стороны экрана приводится текст, и котором сообщается о том, кого обозначает имя и какими чертами характера обладает человек, имеющий его. Относиться к подобному подходу можно по-разному. Но можно сказать определенно -такого рода информации явно недостаточно для решения задачи и ограничиваться только ею нельзя.

    Принцип эффективности

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

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

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

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

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

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

    4.4. Классификация информационных систем - ис

    Понятие классификация

    Классификация — система распределения объектов (предметов, явлений, процессов, понятий) по классам в соответствии с определенным признаком. Под объектом понимается любой предмет, процесс, явление материального или нематериального свойства. Задача классификации — создать некие удобные образы, позволяющие, например, при выборе систем ограничиться определенным классом или типом.

    Общая классификация систем

    Системы в природе бывают самые разнообразные, тем не менее, все их можно поделить на:

    • Абстрактные

    Абстрактные системы — это продукт человеческого мышления: гипотезы, знания, теоремы.

    • Материальные

    Материальные системы получаются из материальных объектов. Всю совокупность материальных систем можно поделить на неорганические (технические, химические и др.), органические (биологические) и смешанные (где содержатся элементы как органической, так и неорганической природы). В множестве смешанных систем особо следует выделить эрготехнические системы (систем «человек-машина») – это системы, которые состоят из человека-оператора (группы операторов) и машины (машин). В таких системах человек с помощью машины осуществляет трудовую деятельность, связанную с производством материальных благ, услуг, а также с управлением и т.п.

    По временной характеристике системы можно классифицировать:

    • статические системы– это системы, в которых состояние системы с течением времени не изменяется;

    • динамические системы – это системы которые с течением времени изменяют свое состояние;

    • детерминированные - динамические системы, состояние элементов которых в данный момент времени полностью определяет их состояние в любой предыдущий или следующий момент времени;

    • вероятностные (стохастические) - динамические системы, в которых предусмотреть состояние в вышеописанный способ невозможно.

    По характеру взаимодействия системы и внешней (окружающей) среды различают:

    • открытые системы. Открытые системы активно взаимодействуют с окружающей средой, сохраняя благодаря этому высокий уровень организованности и развиваясь в сторону осложнения;

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

    Классификация информационных систем - ис

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

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

    Согласно общепринятой классификации ИС - информационные системы - подразделяются:

    • по масштабам применения - настольные и офисные

    • по признаку структурированности задач - структурированные (формализуемые), не структурируемые (не формализуемые), частично структурируемые. Частично-структурированные делятся на: ИС репортинга и ИС разработки альтернативных решений (модельные, экспертные). Экспертные в свою очередь делятся на:

      • централизованные, децентрализованные и коллективного использования;

      • с интеграцией по уровням управления, по уровням планирования и т.д.

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

    • по квалификации персонала и уровням управления – стратегические (топ-менеджеров), функциональные (менеджеров среднего звена) и оперативные (специалистов);

    • по характеру обработки информации: системы обработки данных, системы управления, система поддержки принятия решений;

    • по оперативности обработки данных – пакетной обработки и оперативные;

    • по степени автоматизации - ручные, автоматические, автоматизированные;

    • по характеру использования информации - на информационно-поисковые, информационно-справочные, информационно-решающие, управляющие, советующие и т.п.;

    • по степени централизации обработки информации — на централизованные, децентрализованные, информационные системы коллективного использования;

    • по характеру использования вычислительных ресурсов – на локальные и распределенные;

    • по сфере деятельности - на государственные, территориальные (региональные), отраслевые, объединений, предприятий или учреждений, технологических процессов;

    • по классу реализуемых технологических операций - на системы с текстовыми редакторами, системы с табличными редакторами, СУБД, СУБЗ, системы с графикой, мультимедиа, гипертекстом;

    • по месту в процессе управления предприятия – на АРМ специалиста, ИС руководителя, ИС внешнего контролера, интегрированные системы, объединяющие в себе часть или все из этих функций;

    • по концепции построения – файловые, автоматизированные банки данных, банки знаний, ХД;

    • по режиму работы - на пакетные, диалоговые и смешанные.

    Рассмотрим классификацию ИС по уровню сложности, предложенную Meta Group:

    1) однопользовательские (Personal);

    2) многопользовательские низкого уровня (Low end Multiuser);

    3) уровня предприятия (Enterprise);

    4) межрегиональные распределенные (Wide Area Distributed);

    5) очень большие (Very Large);

    6) сверхбольшие (Ultra large).

    ИС первого и второго уровня сложности иногда называют автоматизированными рабочими местами – АРМами (в англ. варианте – "desktop" и "webtop").

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

    В настоящее время специалист не обязательно привязан к конкретному рабочему месту и может решать профессиональные задачи, находясь дома, в офисе или в командировке. Поэтому под АРМом чаще всего понимают не само рабочее место, а набор инструкций для конкретного специалиста при работе с ИС и его пользовательский интерфейс.

    Таким образом, АРМ – это подкласс ИС первого и второго уровней сложности.

    ИС третьего и четвертого уровней получили название корпоративных ИС (КИС).

    КИС – это ИС, функционирующая в компьютерной сети масштаба предприятия (enterprise – wide network), признаками которой являются:

    - территориальная распределенность узлов (несколько производственных площадок);

    - гетерогенность вычислительной среды (различные протоколы, операционные платформы, используемые СУБД и др.);

    - разнородность приложений пользователей (разные цели);

    - большое число пользователей различной квалификации.

    В настоящее время ИС уровней 4,5 и 6, чаще всего определяют как ИС, работающие в Интернете и интранете (intranet), где intranet рассматривается как технология, аналогичная Интернету, но в масштабах корпорации или учреждения.

    Далее кратко рассматриваются основные типы и виды ИС в порядке приведенной выше классификации. Особо значимые типы ИС будут детально и подробно рассмотрен в соответствующих разделах.

    4.4.1. Классификация ис по масштабности применения

    По масштабам применения современные ИС подразделяются на:

    • Настольные (одиночные) ИС - информационные системы

    Для работы одного человека. К ним можно отнести автоматизированное рабочее место (АРМ) специалиста (конструктора, технолога, расчетчика на прочность, бухгалтера малого предприятия, расчетчика заработной платы и т.д.) ИС этого уровня позволяют специалистам, работающим с данными повысить продуктивность и производительность работы.

    Внедрение таких программ не вызывает особых трудностей и для хороших систем может исчисляться днями. Настольные ИС реализуются на автономном компьютере, как правило, ПК. Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых "настольных СУБД" (FoxPro, Paradox, dBase, MS Access ) или с помощью файловой системы и диалоговой оболочки для ввода, редактирования и обработки данных.

    Автоматизированные рабочие места (арм)

    В настоящее время для интенсификации умственного и управленческого труда специалистов различных профессий разрабатываются и получают широкое распространение АРМ, которые функционируют на базе ПЭВМ.

    АРМ – профессионально-ориентированные малые вычислительные системы, расположенные непосредственно на рабочих местах специалистов и предназначенные для автоматизации их работ.

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

    • Офисные (групповые) информационные системы - ИС

    Основная цель информатизации офиса - обработка данных, повышение эффективности их работы и упрощение канцелярского труда. Групповые ИС ориентированы на коллективное использование информации членами рабочей группы (одного подразделения). Чаще всего строятся как локальная вычислительная сеть ПК или реже как многотерминальная централизованная вычислительная система.

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

    4.4.2. Классификация ис по признаку структурированности задач

    При создании или при классификации ИС неизбежно возникают проблемы, связанные с формальным - математическим и алгоритмическим описанием решаемых задач.

    Понятие степень формализации

    Степень формализации - это степень математического описания задачи, от которой, во многом зависит эффективность работы всей системы, а также уровень автоматизации, определяемый степенью участия человека при принятии решения на основе получаемой информации. Чем точнее математическое описание задач, тем выше возможности компьютерной обработки данных и тем меньше степень участия человека в процессе ее решения. Это и определяет степень автоматизации задачи.

    Различают три типа задач, для которых создаются ИС: структурированные (формализуемые); не структурируемые (не формализуемые); частично структурируемые.

    • Структурированные задачи

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

    Пример:

    В ИС необходимо реализовать задачу расчета заработной платы. Это структурированная задача, где полностью известен алгоритм решения, Рутинный характер этой задачи определяется тем, что расчеты всех начислений и отчислений весьма просты, но объем их очень велик, так как они должны многократно повторяться ежемесячно для всех категорий работающих.

    • Неструктурированные задачи

    Это задачи, в которых решение связано с большими трудностями из-за невозможности создания математического описания и разработки алгоритма. Возможности использования здесь информационной системы невелики. Решение в таких случаях принимается человеком из эвристических соображений на основе своего опыта и, возможно, косвенной информации из разных источников.

    Пример:

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

    • Частично структурированные задачи

    Это задачи, в которых известна лишь часть их элементов и связей между ними. В практике работы любого предприятия существует сравнительно немного полностью структурированных или совершенно неструктурированных задач. На большинстве предприятий персонал сталкивается с частично структурированными задачами.

    Пример:

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

    • выделение дополнительного финансирования на увеличение численности работающих;

    • отнесение срока окончания работы на более позднюю дату и т.д.

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

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

    • Создание отчета (репортинг)

    Создание отчета путем обработки данных (поиск, сортировку, агрегирование, фильтрацию). Используя сведения, содержащиеся в этих отчетах, специалист принимает решение. ИС, создающие отчеты обеспечивают информационную поддержку пользователя, т.е. предоставляют доступ к информации БД и ее частичную обработку. Процедуры манипулирования данными в ИС должны обеспечивать следующие возможности:

      • составление комбинаций БД, получаемых из различных источников;

      • быстрое добавление или исключение того или иного источника данных и автоматическое переключение источников при поиске данных;

      • управление данными с использованием возможностей систем управления БД;

      • логическую независимость данных этого типа от других БД, входящих в подсистему информационного обеспечения;

      • автоматическое отслеживание потока информации для наполнения БД.

    • ИС, разрабатывающие альтернативы решения

    Принятое решение при этом сводится к выбору одной из предложенных альтернатив. ИС, разрабатывающие альтернативы решений, могут быть модельными или экспертными.

    • Экспертные ИС - информационные системы

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

        • по степени централизации обработки - на информационно-централизованные, децентрализованные, информационной системы коллективные использования

        • по степени интеграции функций — многоуровневые ИС с интеграцией за уровнями управления (цеха – производство, управления - предприятие, предприятие - объединение, объединение — корпорация и т.д.), многоуровневые с интеграцией по уровням планирования и т.п.

    • Модельные ИС - информационные системы

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

        • работа в среде типовых математических моделей, включая решение основных задач моделирования типа "как сделать, чтобы?", "что будет, если?", анализ чувствительности и др.;

        • быстрая и адекватная интерпретация результатов моделирования;

        • оперативная подготовка и корректировка входных параметров и ограничений модели;

        • графическое отображение динамики модели;

        • объяснение пользователю необходимых шагов формирования и работы модели.

    4.4.3. Классификация ис по функциональности

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

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

    Из рисунка видно, что чем выше по значимости уровень управления, тем меньше объем работ, выполняемых специалистом и менеджером с помощью ИС. Однако при этом возрастают сложность и интеллектуальные возможности ИС, и ее роль в принятии менеджером решений. Любой уровень управления нуждается в информации из всех функциональных систем, но в разных объемах и с разной степенью обобщения/

    Основание пирамиды составляют ИС, с помощью которых сотрудники-исполнители занимаются операционной обработкой данных, а менеджеры низшего звена — оперативным управлением. Наверху пирамиды на уровне стратегического управления ИС изменяют свою роль и становятся стратегическими, поддерживающими деятельность менеджеров высшего звена по принятию решений в условиях плохой структурированности поставленных задач.

    В хозяйственной практике производственных и коммерческих объектов типовыми видами деятельности, которые определяют функциональный признак классификации ИС, являются:

    • Производственная

    Связана с непосредственным выпуском продукции и направлена на создание и внедрение в производство научно-технических новшеств;

    • Маркетинговая

    Включает в себя:

      • анализ рынка производителей и потребителей выпускаемой продукции, анализ продаж;

      • организацию рекламной кампании по продвижению продукции;

      • рациональную организацию материально-технического снабжения;

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

    • Кадровая

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

    Указанные направления деятельности определили типовой набор ИС: производственные системы; системы маркетинга; финансовые и учетные системы; системы кадров (человеческих ресурсов); прочие типы, выполняющие вспомогательные функции в зависимости от специфики деятельности фирмы.

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

    Подсистемы производственной ИС - информационной системы

    • конструкторской подготовки производства;

    • технологической подготовки производства;

    • управления материально-техническим снабжением;

    • управления производственным процессом;

    • компьютерного инжиниринга и т.д.

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

    Функции информационных систем

    Система маркетинга

    Производственные системы

    Финансовые и учетные системы

    Система кадров (человеческих ресурсов)

    Прочие системы, (например ИС руководства)

    Исследование рынка и прогнозирование продаж

    Планирование объемов работ и разработка календарных планов

    Управление портфелем заказов

    Анализ и прогнозирование потребности в трудовых ресурсах

    Контроль за деятельностью фирмы

    Управление продажами

    Оперативный контроль и управление производством

    Управление кредитной политикой

    Ведение архивов записей о персонале

    Выявление оперативных проблем

    Рекомендации по производству новой продукции

    Анализ работы оборудования

    Разработка финансового плана

    Анализ и планирование подготовки кадров

    Анализ управленческих и стратегических ситуации

    Анализ и установление цены

    Участие в формировании заказов поставщикам

    Финансовый анализ и прогнозирование

    "

    Обеспечение процесса выработки стратегических решений

    Учет заказов

    Управление запасами

    Контроль бюджета

     

     

     

     

    Бухгалтерский учет и расчет зарплаты

     

     

    4.4.4. Классификация ис по характеру обработки информации

    В соответствии с характером обработки информации в ИС на различных уровнях управления экономической системой (оперативном, тактическом и стратегическом) выделяются несколько типов ИС.

    Типы информационных систем по характеру обработки информации

    Системы обработки данных - СОД

    (EDP - Electronic Data Processing, СОД) предназначены для учета и оперативного регулирования хозяйственных операций, подготовки стандартных документов для внешней среды (счетов, накладных, платежных поручений, расчета заработной платы, статистической отчетности и т.п.). Такие системы наряду с функциями ввода, выборки, коррекции информации выполняют математические расчеты без применения методов оптимизации. Горизонт оперативного управления хозяйственными процессами составляет от одного до несколько дней и реализует регистрацию и обработку событий (оформление и мониторинг выполнения заказов, приход и расход материальных ценностей на складе, ведение табеля учета рабочего времени и т.д.). Эти задачи имеют итеративный, регулярный характер, выполняются непосредственными исполнителями хозяйственных процессов (рабочими, кладовщиками, администраторами и т.д.) и связаны с оформлением и пересылкой документов в соответствии с четко определенными алгоритмами. Результаты выполнения хозяйственных операций через экранные формы вводятся в базу данных.

    Информационные системы - ИС - управления - ИСУ

    (MIS - Management Information System, ИСУ) ориентированы на тактический уровень управления: среднесрочное планирование, анализ и организацию работ в течение нескольких недель (месяцев), например анализ и планирование поставок, сбыта, составление производственных программ. Для данного класса задач характерны регламентированность (периодическая повторяемость) формирования результатных документов и четко определенный алгоритм решения задач, например свод заказов для формирования производственной программы и определение потребности в комплектующих деталях и материалах на основе спецификации изделий. Решение подобных задач предназначено для руководителей различных служб предприятий (отделов материально-технического снабжения и сбыта, цехов и т.д.). Задачи решаются на основе накопленной базы оперативных данных.

    Системы поддержки принятия решений - СППР

    (DSS - Decision Support System, СППР) используются в основном на верхнем уровне управления (руководства фирм, предприятий, организаций), имеющего стратегическое долгосрочное значение в течение года или нескольких лет. К таким задачам относятся формирование стратегических целей, планирование привлечения ресурсов, источников финансирования, выбор места размещения предприятий и т.д. Реже задачи класса СППР решаются на тактическом уровне, например при выборе поставщиков или заключении контрактов с клиентами. Задачи СППР имеют, как правило, нерегулярный характер. Для задач СППР свойственны недостаточность имеющейся информации, ее противоречивость и нечеткость, преобладание качественных оценок целей и ограничений, слабая формализованность алгоритмов решения. В качестве инструментов обобщения чаще всего используются средства составления аналитических отчетов произвольной формы, методы статистического анализа, экспертных оценок и систем, математического и имитационного моделирования. При этом используются базы обобщенной информации, информационные хранилища, базы знаний о правилах и моделях принятия решений.

    Идеальной считается ИС, которая включает все три типа перечисленных ИС.

    4.4.5. Классификация ис по оперативности обработки данных

    ИС (информационные системы) пакетной обработки

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

    ИС оперативного (операционного) уровня

    Предназначены для аналитической работы с информацией и поддержки специалистов-исполнителей в обработке оперативных данных (счета, накладные, зарплата, кредиты, поток сырья и материалов). Назначение оперативной ИС — при функционировании в режиме реального времени отвечать на запросы о текущем состоянии и отслеживать поток сделок в фирме, что соответствует оперативному управлению. Чтобы с этим справляться, информационная система должна быть легкодоступной, непрерывно действующей и предоставлять точную информацию. Задачи, цели и источники информации на операционном уровне заранее определены и в высокой степени структурированы. Решение запрограммировано в соответствии с заданным алгоритмом.

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

    Пример.

    ИС оперативного уровня: бухгалтерская; банковских депозитов; обработки заказов; регистрации авиабилетов; выплаты зарплаты и т.д. ИС офисной автоматизации; ИС обработки знаний.

    4.4.6. Классификация ис по квалификации персонала и управления

    Информационные системы специалистов

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

    В этом классе ИС можно выделить две группы ИС:

    • Системы офисной автоматизации

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

      • обработка текстов на компьютерах с помощью различных текстовых процессоров;

      • производство высококачественной печатной продукции;

      • архивация документов;

      • электронные календари и записные книжки для ведения деловой информации;

      • электронная и аудиопочта;

      • видеоконференции и телеконференции.

    • Системы обработки знаний

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

    ИС менеджеров среднего звена

    ИС менеджеров среднего звена используются для мониторинга (постоянного слежения), контроля, принятия решений и администрирования. Основные функции этих ИС:

    • сравнение текущих показателей с прошлыми;

    • составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;

    • обеспечение доступа к архивной информации и т.д.

    Диапазон программ, применяемых для систем этого уровня весьма широк. Среди них можно выделить следующие основные классы:

    • анализ маркетинга. Моделирование стратегии, анализ положения компании на рынке, разработка плана маркетинга;

    • анализ продаж. Информационная поддержка и анализ процесса продаж, моделирование каналов сбыта.

    Некоторые ИС обеспечивают принятие нетривиальных решений. В случае, когда требования к информационному обеспечению определены не строго, они способны отвечать на вопрос: "что будет, если …?"

    Стратегические ИС - информационные системы

    Эти системы предназначены для топ-менеджеров, поэтому для них существует второе, даже более часто применяемое название КИС (корпоративные информационные системы). Помогают высшему звену управленцев решать неструктурированные задачи осуществлять долгосрочное планирование. Развитие и успех любого предприятия, организации (фирмы) во многом определяются принятой в ней стратегией. Стратегия – это набор методов и средств решения перспективных долгосрочных задач.

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

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

    Понятие стратегическая ИС

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

    Пример

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

    Для того, чтобы понять эффект от использования ИС, нужно понять взаимосвязь фирмы с ее внешним окружением. На рисунке показано воздействие на фирму внешних факторов:

    • конкурентов, проводящих на рынке свою политику;

    • покупателей, обладающих разными возможностями по приобретению товаров и услуг;

    • поставщиков, которые проводят свою ценовую политику, Фирма может обеспечить себе конкурентное преимущество, если будет учитывать эти факторы и придерживаться следующих стратегий:

    • создание новых товаров и услуг, которые выгодно отличаются от аналогичных;

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

    • создание таких связей, которые закрепляют покупателей и поставщиков за данной фирмой и делают невыгодным обращение к другой;

    • снижение стоимости продукции без ущерба качества.

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

    • создание новых товаров и услуг, которые выгодно отличаются от аналогичных;

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

    • создание таких связей, которые закрепляют покупателей и поставщиков за данным предприятием и делают невыгодным обращение к другой;

    • снижение стоимости продукции без ущерба качества.

    4.4.7. Классификация ис по степени автоматизации

    В зависимости от степени автоматизации информационных процессов ИС определяются как ручные, автоматические, автоматизированные.

    Ручные ИС

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

    Автоматизированные информационные системы - АИС

    Автоматизированные ИС (АИС) предполагают участие в процессе обработки информации и человека, и технических средств, причем главная роль отводится компьютеру. В современном толковании в термин "ИС" вкладывается обязательно понятие автоматизируемой системы.

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

    Пример

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

    Основу АИС составляет банк данных, в котором хранится большая по объему информация о какой-либо области человеческих знаний. Территориально этот банк может быть распределенным. Важно, что для пользователя этот банк представляется, как единое хранилище информации, куда он может обратиться с запросом.

    Автоматические ИС

    Автоматические информационные системы выполняют все операции по переработке информации без участия человека.

    4.4.8. Классификация ис по характеру использования информации

    Все ИС, классифицируемые по характеру используемой информации, относятся к автоматизированным информационным системам (АИС). В этот класс систем входят ИС, общая структура которых показана на рисунке в прошлой главе.

    Информационно - поисковые системы (ИПС)

    Информационно-поисковые системы ориентированы на решение задач поиску информации, документа или факта в множестве источников информации (документов). Содержательная обработка информации в таких системах отсутствующая. Производят ввод, систематизацию, хранение, выдачу информации по запросу пользователя без сложных преобразований данных. Например, информационно-поисковая система в библиотеке билетов. В таких системах хранится информационный массив, из которого по требованиям пользователей выдается нужная информация. Поиск информации по требованию пользователя осуществляется либо автоматически, либо вручную.

    Поисковый образ документа (ПОД) получается в результате процесса индексирования, который состоит из двух этапов: выявление смысла документа и описание смысла на специальном информационно-поисковом языке (ИПЯ). Запрос к ИПС описывается также на этом языке. Поиск документа состоит в сравнении множества хранящихся в системе ПОД и текущего поискового образа запроса (ПОЗ), в результате чего пользователю выдается требуемый документ или отказ.

    Информационно-поисковые системы делятся на два типа.

    • Документальные (документографические)

    Это системы, в которой объектом сохранения и обработки есть собственно документы.. В такой ИПС все хранимые документы индексируются некоторым специальным образом. Каждому документу (статье, отчету, протоколу и т.п.) присваивается индивидуальный код, составляющий поисковый образ документа. Поиск идет не по самим документам, а по их поисковым образам, которые содержат информацию (адрес) о местонахождении документа. Именно так ищут книги по заказам читателя в больших библиотеках (в маленьких библиотеках библиотекарь обычно ищет книги сам). По требованию читателя сначала находят карточку в каталоге, а потом по шифру, указанному на ней, отыскивается и сама книга. Различия документографических ИПС определяются тем, как устроен поисковый образ документа. В простейшем случае это просто его индивидуальное название (например, название, автор, год издания книги). В более сложных случаях нет однозначного соответствия между поисковым образом документа и самим документом. Вполне возможен случай, когда поисковый образ документа соответствует нескольким различным документам и, наоборот, один и тот же документ соответствует не одному, а нескольким поисковым образам.

    • Фактографическая информационная поисковая система - ИПС

    Это система, где, объектом или сущностью есть то, что представляет для проблемной сферы многосторонний интерес (сотрудник, договор, изделие и т.п.). Ведомости об этих сущностях могут находиться во множестве разных входных и исходных сообщений.. В отличие от документографических ИПС в ИПС такого типа хранятся не документы, а факты, относящиеся к какой-либо предметной области . Хранимые факты могут быть извлечены из различных документов. В базе фактов они связываются между собой системой разнообразных отношений. Такая сеть в ИПС носит название тезауруса предметной области. Запросы, поступающие в фактографические ИПС, используют тезаурус для поиска ответов на запросы. Поиск осуществляется методом поиска по образцу, широко применяющемуся в базах знаний систем искусственного интеллекта. ИПС фактографического типа постепенно приближаются по своей организации и функционированию к развитым базам данных и знаний.

    Информационно - решающие системы.

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

    Управляющие ИС - информационные системы

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

    Для этих систем характерны тип задач расчетного характера и обработка больших объемов данных. Примером могут служить система оперативного планирования выпуска продукции, система бухгалтерского учета.

    Советующие ИС

    Вырабатывают информацию, которая принимается человеком к сведению и не превращается немедленно в серию конкретных действий. Эти системы обладают более высокой степенью интеллекта, так как для них характерна обработка знаний, а не данных.

    Пример

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

    4.4.9. Классификация ис по сфере деятельности

    Государственные информационные системы (ИС)

    Государственные ИС предназначены для решения важнейших народнохозяйственных проблем страны. На базе использования вычислительных комплексов и экономико-математических методов в них составляют перспективные и текущие планы развития страны, ведут учет результатов и регулируют деятельность отдельных звеньев народного хозяйства, разрабатывают Государственный бюджет, контролируют его выполнения и т.п. К ним относятся автоматизированная система государственной статистики (АСДС), автоматизированная система плановых расчетов (АСПР), государственная ИС финансовых расчетов (АСФР) при Министерстве финансов Украины, система обработки информации из цен (АСОІ цен), система управления национальным банком АСУ банк), система обработки научно-технической информации (АСО НТІ) и т.п.

    Известные и другие государственные ИС, система обработки информации из цен (АСОИ цен), система управления Национальным банком (АСУ банк), система обработки научно-технической информации (АСО НТИ) и другие.

    Территориальные (региональные) ИС

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

    Отраслевые информационные системы управления - ИСУ

    Отраслевые ИСУ предназначенные для управления подведомственными предприятиями и организациями. Отраслевые ИСУ действуют в промышленности и сельском хозяйстве, строительстве на транспорте и др. В них решаются задачи информационного обслуживания аппарата управления отраслевых министерств и их подразделов. Отраслевые ИС различаются за сферами применения — промышленная, непромышленная, научная и т.п.

    4.4.10. Классификация ис по концепции построения

    Файловые системы

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

    Автоматизированные банки данных

    Банк данных -это система специальным образом организованных БД, программных, технических, языковых и организационно -методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.

    В отличие от файловых систем, структура БД меньше зависит от прикладных программ, а все функции по работе с БД сосредоточены в специальном компоненте - системе управления базами данных (СУБД), которая играет центральную роль в функционировании банка данных, так как обеспечивает связь прикладных программ и пользователей, данными. Сведения о структуре БД сосредоточены в словаре-справочнике (репозитории). Этот вид информации называется метаинформацией. В состав метаинформации входит семантическая информация, физические характеристики данных и информация об их использовании. С помощью словарей данных автоматизируется процесс использования метаинформации в ИС.

    Интеллектуальные банки данных (банки знаний, БЗ)

    Это сравнительно новый способ построения ИС, при котором информация о предметной области условно делится между двумя базами. Если БД содержит сведения о количественных и качественных характеристиках конкретных объектов, то БЗ содержит сведения о закономерностях в ПО, позволяющие выводить новые факты из имеющихся в БД; метаинформацию; сведения о структуре предметной области; сведения, обеспечивающие понимание запроса и синтез ответа.

    Если в традиционном банке данных знания о предметной области заложены программистом в каждую прикладную программу, а также в структуру БД, то в интеллектуальном банке данных они хранятся в базе знаний и отделены от прикладных программ. В отличие от данных, знания активны: на их основе формируются цели и выбираются способы их достижения. Например, ИБД в системе складского учета может автоматически реагировать на такое событие, как уменьшение количества деталей на складе до критической нормы, при этом ИБД без участия пользователя генерирует документы для заказа этих деталей и отправляет их по электронной почте поставщику.

    Другое характерное отличие знаний от данных -связность, причем знания отражают как структурные взаимосвязи между объектами предметной области, так и вызванные конкретными бизнес -процессами, например такие связи, как "происходит одновременно", "следует из...", "если -то" и др.

    Наконец, существенную роль в ИБД играет форма представления информации для пользователя: она должна быть как можно ближе к естественным для человека способам обмена данными (профессиональный естественный язык, речевой ввод / вывод, графическая форма).

    Хранилища данных - ХД

    В настоящее время в корпоративных БД накоплены гигантские объемы информации, однако она недостаточно эффективно используется в процессе управления бизнесом, поэтому бурно развивается новая форма построения ИС - склады (хранилища) данных.

    ХД представляет собой автономный банк данных, в котором база данных разделена на два компонента: оперативная БД хранит текущую информацию, квазипостоянная БД содержит исторические данные, например, в оперативной БД могут содержаться данные о продажах за текущий год, а в квазипостоянной БД хранятся систематизированные годовые отчеты и балансы за все время существования предприятия. Подсистема оперативного анализа данных позволяет эффективно и быстро анализировать текущую информацию. Подсистема принятия решений пользуется обобщенной и исторической информацией, применяет методы логического вывода. Для общения с пользователем служит универсальный интерфейс.

    4.4.11. Классификация ис по режиму работы

    Пакетные ИС - информационные системы

    Пакетные ИС работают в пакетном режиме: вначале данные накапливаются, и формируется пакет данных, а затем пакет последовательно обрабатывается рядом программ. Недостаток этого режима - низкая оперативность принятия решений и обособленность пользователя от системы.

    Диалоговые информационные системы

    Диалоговые ИС работают в режиме обмена сообщениями между пользователями и системой (например, система продажи авиабилетов). Этот режим особенно удобен, когда пользователь может выбирать перспективные варианты из числа предлагаемых системой.

    По способу распределения ресурсов

    Локальные информационные системы

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

    Распределенные ИС

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

    4.4.12. Классификация ис по сфере применения

    ИС организационного управления предназначены для автоматизации функций управленческого персонала. Сюда относятся ИС управления промышленными и непромышленными фирмами:

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

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

    ИС автоматизированного проектирования (САПР) предназначены для автоматизации функций инженеров-проектировщиков, конструкторов, архитекторов, дизайнеров при создании новой техники и технологии. Основными функциями являются: инженерные расчеты, создание графической документации (чертежей, схем, планов), создание проектной документации, моделирование проектируемых объектов.

    Географическая информационная система (ГИС) – это информационная система, обеспечивающая сбор, хранение, обработку, доступ, отображение и распространение пространственно-координированных данных, интеграцию данных и знаний о территории для их эффективного использования при решении научных и прикладных географических задач.

    Автоматизированные системы программного обучения (АСПО) ориентированы на обучение в основном по теоретическим разделам курсов и дисциплин. В рамках АСПО реализуются заранее подготовленные квалифицированными преподавателями "компьютерные курсы" и электронные учебники.

    Интерактивные обучающие системы (ИОС) должны обеспечить учебный диалог с пользователем на уровне индивидуальной работы опытного педагога с учащимся. В наиболее общем случае ИОС это не только обучающие, но и обучающиеся системы, основанные на методах искусственного интеллекта и экспертных систем.

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

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

    5. ЖизненнЫй цикл ис

    CALS-технологии – технологии поддержки полного жизненного цикла изделия от проектирования до утилизации.

    Методология проектирования информационных систем описывает процесс создания и сопровождения систем в виде жизненного цикла (ЖЦ) ИС, представляя его как некоторую последовательность стадий и выполняемых на них процессов. Для каждого этапа определяются состав и последовательность выполняемых работ, получаемые результаты, методы и средства, необходимые для выполнения работ, роли и ответственность участников и т.д. Такое формальное описание ЖЦ ИС позволяет спланировать и организовать процесс коллективной разработки и обеспечить управление этим процессом.

    Жизненный цикл ИС можно представить как ряд событий, происходящих с системой в процессе ее создания и использования.

    5.1. Модели жизненного цикла (жц) ис

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

    В настоящее время известны и используются следующие модели жизненного цикла:

    • Каскадная модель (рис. 5.1) предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе.

    • Поэтапная модель с промежуточным контролем (рис. 5.2). Разработка ИС ведется итерациями с циклами обратной связи между этапами. Межэтапные корректировки позволяют учитывать реально существующее взаимовлияние результатов разработки на различных этапах; время жизни каждого из этапов растягивается на весь период разработки.

    • Спиральная модель (рис. 5.3). На каждом витке спирали выполняется создание очередной версии продукта, уточняются требования проекта, определяется его качество и планируются работы следующего витка. Особое внимание уделяется начальным этапам разработки - анализу и проектированию, где реализуемость тех или иных технических решений проверяется и обосновывается посредством создания прототипов (макетирования).

    Рис. 5.1.  Каскадная модель ЖЦ ИС

    Рис. 5.2.  Поэтапная модель с промежуточным контролем

    Рис. 5.3.  Спиральная модель ЖЦ ИС

    На практике наибольшее распространение получили две основные модели жизненного цикла:

    • каскадная модель (характерна для периода 1970-1985 гг.);

    • спиральная модель (характерна для периода после 1986.г.).

    В ранних проектах достаточно простых ИС каждое приложение представляло собой единый, функционально и информационно независимый блок. Для разработки такого типа приложений эффективным оказался каскадный способ. Каждый этап завершался после полного выполнения и документального оформления всех предусмотренных работ.

    Можно выделить следующие положительные стороны применения каскадного подхода:

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

    • выполняемые в логической последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.

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

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

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

    Итеративная разработка отражает объективно существующий спиральный цикл создания сложных систем. Она позволяет переходить на следующий этап, не дожидаясь полного завершения работы на текущем и решить главную задачу - как можно быстрее показать пользователям системы работоспособный продукт, тем самым активизируя процесс уточнения и дополнения требований.

    Основная проблема спирального цикла - определение момента перехода на следующий этап. Для ее решения вводятся временные ограничения на каждый из этапов жизненного цикла, и переход осуществляется в соответствии с планом, даже если не вся запланированная работа закончена. Планирование производится на основе статистических данных, полученных в предыдущих проектах, и личного опыта разработчиков.

    Несмотря на настойчивые рекомендации компаний - вендоров и экспертов в области проектирования и разработки ИС, многие компании продолжают использовать каскадную модель вместо какого-либо варианта итерационной модели. Основные причины, по которым каскадная модель сохраняет свою популярность, следующие [3]:

    1. Привычка - многие ИТ-специалисты получали образование в то время, когда изучалась только каскадная модель, поэтому она используется ими и в наши дни.

    2. Иллюзия снижения рисков участников проекта (заказчика и исполнителя). Каскадная модель предполагает разработку законченных продуктов на каждом этапе: технического задания, технического проекта, программного продукта и пользовательской документации. Разработанная документация позволяет не только определить требования к продукту следующего этапа, но и определить обязанности сторон, объем работ и сроки, при этом окончательная оценка сроков и стоимости проекта производится на начальных этапах, после завершения обследования. Очевидно, что если требования к информационной системе меняются в ходе реализации проекта, а качество документов оказывается невысоким (требования неполны и/или противоречивы), то в действительности использование каскадной модели создает лишь иллюзию определенности и на деле увеличивает риски, уменьшая лишь ответственность участников проекта. При формальном подходе менеджер проекта реализует только те требования, которые содержатся в спецификации, опирается на документ, а не на реальные потребности бизнеса. Есть два основных типа контрактов на разработку ПО. Первый тип предполагает выполнение определенного объема работ за определенную сумму в определенные сроки (fixed price). Второй тип предполагает повременную оплату работы (time work). Выбор того или иного типа контракта зависит от степени определенности задачи. Каскадная модель с определенными этапами и их результатами лучше приспособлена для заключения контракта с оплатой по результатам работы, а именно этот тип контрактов позволяет получить полную оценку стоимости проекта до его завершения. Более вероятно заключение контракта с повременной оплатой на небольшую систему, с относительно небольшим весом в структуре затрат предприятия. Разработка и внедрение интегрированной информационной системы требует существенных финансовых затрат, поэтому используются контракты с фиксированной ценой, и, следовательно, каскадная модель разработки и внедрения. Спиральная модель чаще применяется при разработке информационной системы силами собственного отдела ИТ предприятия.

    3. Проблемы внедрения при использовании итерационной модели. В некоторых областях спиральная модель не может применяться, поскольку невозможно использование/тестирование продукта, обладающего неполной функциональностью (например, военные разработки, атомная энергетика и т.д.). Поэтапное итерационное внедрение информационной системы для бизнеса возможно, но сопряжено с организационными сложностями (перенос данных, интеграция систем, изменение бизнес-процессов, учетной политики, обучение пользователей). Трудозатраты при поэтапном итерационном внедрении оказываются значительно выше, а управление проектом требует настоящего искусства. Предвидя указанные сложности, заказчики выбирают каскадную модель, чтобы "внедрять систему один раз".

    5.2. Стандарты на проектирование ис

    Каждая из стадий создания системы предусматривает выполнение определенного объема работ, которые представляются в виде процессов ЖЦ. Процесс определяется как совокупность взаимосвязанных действий, преобразующих входные данные в выходные. Описание каждого процесса включает в себя перечень решаемых задач, исходных данных и результатов.

    Существует целый ряд стандартов, регламентирующих ЖЦ ПО, а в некоторых случаях и процессы разработки.

    Значительный вклад в теорию проектирования и разработки информационных систем внесла компания IBM, предложив еще в середине 1970-х годов методологию BSP (Business System Planning - методология организационного планирования). Метод структурирования информации с использованием матриц пересечения бизнес-процессов, функциональных подразделений, функций систем обработки данных (информационных систем), информационных объектов, документов и баз данных, предложенный в BSP, используется сегодня не только в ИТ-проектах, но и проектах по реинжинирингу бизнес-процессов, изменению организационной структуры. Важнейшие шаги процесса BSP, их последовательность (получить поддержку высшего руководства, определить процессы предприятия, определить классы данных, провести интервью, обработать и организовать данные интервью) можно встретить практически во всех формальных методиках, а также в проектах, реализуемых на практике.

    Среди наиболее известных стандартов можно выделить следующие:

    • ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла [4].

    • ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов [5].

    • Custom Development Method (методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

    • Rational Unified Process (RUP) предлагает итеративную модель разработки, включающую четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разбита на этапы (итерации), в результате которых выпускается версия для внутреннего или внешнего использования. Прохождение через четыре основные фазы называется циклом разработки, каждый цикл завершается генерацией версии системы. Если после этого работа над проектом не прекращается, то полученный продукт продолжает развиваться и снова минует те же фазы. Суть работы в рамках RUP - это создание и сопровождение моделей на базе UML [6].

    • Microsoft Solution Framework (MSF) сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес-приложений.

    • Extreme Programming (XP). Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов.

    5.3. Процессы жц по

    В соответствии с базовым международным стандартом ISO/IEC 12207 все процессы ЖЦ ПО делятся на три группы:

    1. Основные процессы:

      • приобретение;

      • поставка;

      • разработка;

      • эксплуатация;

      • сопровождение.

    2. Вспомогательные процессы:

      • документирование;

      • управление конфигурацией;

      • обеспечение качества;

      • разрешение проблем;

      • аудит;

      • аттестация;

      • совместная оценка;

      • верификация.

    3. Организационные процессы:

      • создание инфраструктуры;

      • управление;

      • обучение;

      • усовершенствование.

    В таблице 5.1 приведены ориентировочные описания основных процессов ЖЦ. Вспомогательные процессы предназначены для поддержки выполнения основных процессов, обеспечения качества проекта, организации верификации, проверки и тестирования ПО. Организационные процессы определяют действия и задачи, выполняемые как заказчиком, так и разработчиком проекта для управления своими процессами.

    Для поддержки практического применения стандарта ISO/IEC 12207 разработан ряд технологических документов: Руководство для ISO/IEC 12207 (ISO/IEC TR 15271:1998 Information technology - Guide for ISO/IEC 12207) и Руководство по применению ISO/IEC 12207 к управлению проектами (ISO/IEC TR 16326:1999 Software engineering - Guide for the application of ISO/IEC 12207 to project management).

    Таблица 5.1. Содержание основных процессов ЖЦ ПО ИС (ISO/IEC 12207)

    Процесс (исполнитель процесса)

    Действия

    Вход

    Результат

    Приобретение (заказчик)

    • Инициирование

    • Подготовка заявочных предложений

    • Подготовка договора

    • Контроль деятельности поставщика

    • Приемка ИС

    • Решение о начале работ по внедрению ИС

    • Результаты обследования деятельности заказчика

    • Результаты анализа рынка ИС/ тендера

    • План поставки/ разработки

    • Комплексный тест ИС

    • Технико-экономическое обоснование внедрения ИС

    • Техническое задание на ИС

    • Договор на поставку/ разработку

    • Акты приемки этапов работы

    • Акт приемно-сдаточных испытаний

    Поставка (разработчик ИС)

    • Инициирование

    • Ответ на заявочные предложения

    • Подготовка договора

    • Планирование исполнения

    • Поставка ИС

    • Техническое задание на ИС

    • Решение руководства об участии в разработке

    • Результаты тендера

    • Техническое задание на ИС

    • План управления проектом

    • Разработанная ИС и документация

    • Решение об участии в разработке

    • Коммерческие предложения/ конкурсная заявка

    • Договор на поставку/ разработку

    • План управления проектом

    • Реализация/ корректировка

    • Акт приемно-сдаточных испытаний

    Разработка (разработчик ИС)

    • Подготовка

    • Анализ требований к ИС

    • Проектирование архитектуры ИС

    • Разработка требований к ПО

    • Проектирование архитектуры ПО

    • Детальное проектирование ПО

    • Кодирование и тестирование ПО

    • Интеграция ПО и квалификационное тестирование ПО

    • Интеграция ИС и квалификационное тестирование ИС

    • Техническое задание на ИС

    • Техническое задание на ИС, модель ЖЦ

    • Подсистемы ИС

    • Спецификации требования к компонентам ПО

    • Архитектура ПО

    • Материалы детального проектирования ПО

    • План интеграции ПО, тесты

    • Архитектура ИС, ПО, документация на ИС, тесты

    • Используемая модель ЖЦ, стандарты разработки

    • План работ

    • Состав подсистем, компоненты оборудования

    • Спецификации требования к компонентам ПО

    • Состав компонентов ПО, интерфейсы с БД, план интеграции ПО

    • Проект БД, спецификации интерфейсов между компонентами ПО, требования к тестам

    • Тексты модулей ПО, акты автономного тестирования

    • Оценка соответствия комплекса ПО требованиям ТЗ

    • Оценка соответствия ПО, БД, технического комплекса и комплекта документации требованиям ТЗ

    Позднее был разработан и в 2002 г. опубликован стандарт на процессы жизненного цикла систем (ISO/IEC 15288 System life cycle processes). К разработке стандарта были привлечены специалисты различных областей: системной инженерии, программирования, управления качеством, человеческими ресурсами, безопасностью и пр. Был учтен практический опыт создания систем в правительственных, коммерческих, военных и академических организациях. Стандарт применим для широкого класса систем, но его основное предназначение - поддержка создания компьютеризированных систем.

    Согласно стандарту ISO/IEC серии 15288 [7] в структуру ЖЦ следует включать следующие группы процессов:

    1. Договорные процессы:

      • приобретение (внутренние решения или решения внешнего поставщика);

      • поставка (внутренние решения или решения внешнего поставщика).

    2. Процессы предприятия:

      • управление окружающей средой предприятия;

      • инвестиционное управление;

      • управление ЖЦ ИС;

      • управление ресурсами;

      • управление качеством.

    3. Проектные процессы:

      • планирование проекта;

      • оценка проекта;

      • контроль проекта;

      • управление рисками;

      • управление конфигурацией;

      • управление информационными потоками;

      • принятие решений.

    4. Технические процессы:

      • определение требований;

      • анализ требований;

      • разработка архитектуры;

      • внедрение;

      • интеграция;

      • верификация;

      • переход;

      • аттестация;

      • эксплуатация;

      • сопровождение;

      • утилизация.

    5. Специальные процессы:

      • определение и установка взаимосвязей исходя из задач и целей.

    Стадии создания системы, предусмотренные в стандарте ISO/IEC 15288, несколько отличаются от рассмотренных выше. Перечень стадий и основные результаты, которые должны быть достигнуты к моменту их завершения, приведены в таблице 5.2.

    Таблица 5.2. Стадии создания систем (ISO/IEC 15288)

    п/п

    Стадия

    Описание

    1

    Формирование концепции

    Анализ потребностей, выбор концепции и проектных решений

    2

    Разработка

    Проектирование системы

    3

    Реализация

    Изготовление системы

    4

    Эксплуатация

    Ввод в эксплуатацию и использование системы

    5

    Поддержка

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

    6

    Снятие с эксплуатации

    Прекращение использования, демонтаж, архивирование системы

    5.4. Каноническое проектирование ис

    Организация канонического проектирования ИС ориентирована на использование главным образом каскадной модели жизненного цикла ИС. Стадии и этапы работы описаны в стандарте ГОСТ 34.601-90.

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

    Стадии и этапы создания ИС, выполняемые организациями-участниками, прописываются в договорах и технических заданиях на выполнение работ:

    Стадия 1. Формирование требований к ИС.

    На начальной стадии проектирования выделяют следующие этапы работ:

    • обследование объекта и обоснование необходимости создания ИС;

    • формирование требований пользователей к ИС;

    • оформление отчета о выполненной работе и тактико-технического задания на разработку.

    Стадия 2. Разработка концепции ИС.

    • изучение объекта автоматизации;

    • проведение необходимых научно-исследовательских работ;

    • разработка вариантов концепции ИС, удовлетворяющих требованиям пользователей;

    • оформление отчета и утверждение концепции.

    Стадия 3. Техническое задание.

    • разработка и утверждение технического задания на создание ИС.

    Стадия 4. Эскизный проект.

    • разработка предварительных проектных решений по системе и ее частям;

    • разработка эскизной документации на ИС и ее части.

    Стадия 5. Технический проект.

    • разработка проектных решений по системе и ее частям;

    • разработка документации на ИС и ее части;

    • разработка и оформление документации на поставку комплектующих изделий;

    • разработка заданий на проектирование в смежных частях проекта.

    Стадия 6. Рабочая документация.

    • разработка рабочей документации на ИС и ее части;

    • разработка и адаптация программ.

    Стадия 7. Ввод в действие.

    • подготовка объекта автоматизации;

    • подготовка персонала;

    • комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями);

    • строительно-монтажные работы;

    • пусконаладочные работы;

    • проведение предварительных испытаний;

    • проведение опытной эксплуатации;

    • проведение приемочных испытаний.

    Стадия 8. Сопровождение ИС.

    • выполнение работ в соответствии с гарантийными обязательствами;

    • послегарантийное обслуживание.

    Oбследование – это изучение и диагностический анализ организационной структуры предприятия, его деятельности и существующей системы обработки информации. Материалы, полученные в результате обследования, используются для:

    • обоснования разработки и поэтапного внедрения систем;

    • составления технического задания на разработку систем;

    • разработки технического и рабочего проектов систем.

    На этапе обследования целесообразно выделить две составляющие: определение стратегии внедрения ИС и детальный анализ деятельности организации.

    Основная задача первого этапа обследования - оценка реального объема проекта, его целей и задач на основе выявленных функций и информационных элементов автоматизируемого объекта высокого уровня [8]. Эти задачи могут быть реализованы или заказчиком ИС самостоятельно, или с привлечением консалтинговых организаций. Этап предполагает тесное взаимодействие с основными потенциальными пользователями системы и бизнес-экспертами. Основная задача взаимодействия - получить полное и однозначное понимание требований заказчика. Как правило, нужная информация может быть получена в результате интервью, бесед или семинаров с руководством, экспертами и пользователями.

    По завершении этой стадии обследования появляется возможность определить вероятные технические подходы к созданию системы и оценить затраты на ее реализацию (затраты на аппаратное обеспечение, закупаемое программное обеспечение и разработку нового программного обеспечения).

    Результатом этапа определения стратегии является документ (технико-экономическое обоснование проекта), где четко сформулировано, что получит заказчик, если согласится финансировать проект, когда он получит готовый продукт (график выполнения работ) и сколько это будет стоить (для крупных проектов должен быть составлен график финансирования на разных этапах работ). В документе желательно отразить не только затраты, но и выгоду проекта, например время окупаемости проекта, ожидаемый экономический эффект (если его удается оценить).

    Ориентировочное содержание этого документа:

    • ограничения, риски, критические факторы, которые могут повлиять на успешность проекта;

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

    • сроки завершения отдельных этапов, форма приемки/сдачи работ, привлекаемые ресурсы, меры по защите информации;

    • описание выполняемых системой функций;

    • возможности развития системы;

    • информационные объекты системы;

    • интерфейсы и распределение функций между человеком и системой;

    • требования к программным и информационным компонентам ПО, требования к СУБД;

    • что не будет реализовано в рамках проекта.

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

    • инструктивно-методические и директивные материалы, на основании которых определяются состав подсистем и перечень задач;

    • возможности применения новых методов решения задач.

    Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

    • функции - информация о событиях и процессах, которые происходят в бизнесе;

    • сущности - информация о вещах, имеющих значение для организации и о которых что-то известно.

    При изучении каждой функциональной задачи управления определяются:

    • наименование задачи; сроки и периодичность ее решения;

    • степень формализуемости задачи;

    • источники информации, необходимые для решения задачи;

    • показатели и их количественные характеристики;

    • порядок корректировки информации;

    • действующие алгоритмы расчета показателей и возможные методы контроля;

    • действующие средства сбора, передачи и обработки информации;

    • действующие средства связи;

    • принятая точность решения задачи;

    • трудоемкость решения задачи;

    • действующие формы представления исходных данных и результатов их обработки в виде документов;

    • потребители результатной информации по задаче.

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

    • количество документов;

    • место формирования показателей документа;

    • взаимосвязь документов при их формировании;

    • маршрут и длительность движения документа;

    • место использования и хранения данного документа;

    • внутренние и внешние информационные связи;

    • объем документа в знаках.

    По результатам обследования устанавливается перечень задач управления, решение которых целесообразно автоматизировать, и очередность их разработки.

    На этапе обследования следует классифицировать планируемые функции системы по степени важности. Один из возможных форматов представления такой классификации - MuSCoW [9].

    Эта аббревиатура расшифровывается так: Must have - необходимые функции; Should have - желательные функции; Could have - возможные функции; Won't have - отсутствующие функции.

    Функции первой категории обеспечивают критичные для успешной работы системы возможности.

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

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

    Модели деятельности организации создаются в двух видах:

    • модель "как есть"("as-is")- отражает существующие в организации бизнес-процессы;

    • модель "как должно быть"("to-be") - отражает необходимые изменения бизнес-процессов с учетом внедрения ИС.

    На этапе анализа необходимо привлекать к работе группы тестирования для решения следующих задач:

    • получения сравнительных характеристик предполагаемых к использованию аппаратных платформ, операционных систем, СУБД, иного окружения;

    • разработки плана работ по обеспечению надежности информационной системы и ее тестирования.

    Привлечение тестировщиков на ранних этапах разработки является целесообразным для любых проектов. Если проектное решение оказалось неудачным и это обнаружено слишком поздно (на этапе разработки или, что еще хуже, на этапе внедрения в эксплуатацию), то исправление ошибки проектирования обходится очень дорого. Чем раньше группы тестирования выявляют ошибки в информационной системе, тем ниже стоимость сопровождения системы. Время на тестирование системы и на исправление обнаруженных ошибок следует предусматривать не только на этапе разработки, но и на этапе проектирования.

    Для автоматизации тестирования следует использовать системы отслеживания ошибок (bug tracking). Это позволяет иметь единое хранилище ошибок, отслеживать их повторное появление, контролировать скорость и эффективность исправления ошибок, видеть наиболее нестабильные компоненты системы, а также поддерживать связь между группой разработчиков и группой тестирования (уведомления об изменениях по e-mail и т.п.). Чем больше проект, тем сильнее потребность в bug tracking.

    5.5. Содержание технического задания на ис

    Результаты обследования представляют объективную основу для формирования технического задания на информационную систему.

    Техническое задание- это документ, определяющий цели, требования и основные исходные данные, необходимые для разработки автоматизированной системы управления.

    При разработке технического задания необходимо решить следующие задачи:

    • установить общую цель создания ИС, определить состав подсистем и функциональных задач;

    • разработать и обосновать требования, предъявляемые к подсистемам;

    • разработать и обосновать требования, предъявляемые к информационной базе, математическому и программному обеспечению, комплексу технических средств (включая средства связи и передачи данных);

    • установить общие требования к проектируемой системе;

    • определить перечень задач создания системы и исполнителей;

    • определить этапы создания системы и сроки их выполнения;

    • провести предварительный расчет затрат на создание системы и определить уровень экономической эффективности ее внедрения.

    Типовые требования к составу и содержанию технического задания приведены в таблице 5.3.

    Таблица 5.3. Состав и содержание технического задания (ГОСТ 34.602- 89)

    п\п

    Раздел

    Содержание

    1

    Общие сведения

    • полное наименование системы и ее условное обозначение

    • шифр темы или шифр (номер) договора;

    • наименование предприятий разработчика и заказчика системы, их реквизиты

    • перечень документов, на основании которых создается ИС

    • плановые сроки начала и окончания работ

    • сведения об источниках и порядке финансирования работ

    • порядок оформления и предъявления заказчику результатов работ по созданию системы, ее частей и отдельных средств

    2

    Назначение и цели создания (развития) системы

    • вид автоматизируемой деятельности

    • перечень объектов, на которых предполагается использование системы

    • наименования и требуемые значения технических, технологических, производственно-экономических и др. показателей объекта, которые должны быть достигнуты при внедрении ИС

    3

    Характеристика объектов автоматизации

    • краткие сведения об объекте автоматизации

    • сведения об условиях эксплуатации и характеристиках окружающей среды

    4

    Требования к системе

    Требования к системе в целом:

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

    • требования к персоналу (численность пользователей, квалификация, режим работы, порядок подготовки)

    • показатели назначения (степень приспособляемости системы к изменениям процессов управления и значений параметров)

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

    Требования к функциям (по подсистемам) :

    • перечень подлежащих автоматизации задач

    • временной регламент реализации каждой функции

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

    • перечень и критерии отказов

    Требования к видам обеспечения:

    • математическому (состав и область применения мат. моделей и методов, типовых и разрабатываемых алгоритмов)

    • информационному (состав, структура и организация данных, обмен данными между компонентами системы, информационная совместимость со смежными системами, используемые классификаторы, СУБД, контроль данных и ведение информационных массивов, процедуры придания юридической силы выходным документам)

    • лингвистическому (языки программирования, языки взаимодействия пользователей с системой, системы кодирования, языки ввода- вывода)

    • программному (независимость программных средств от платформы, качество программных средств и способы его контроля, использование фондов алгоритмов и программ)

    • техническому

    • метрологическому

    • организационному (структура и функции эксплуатирующих подразделений, защита от ошибочных действий персонала)

    • методическому (состав нормативно- технической документации

    5

    Состав и содержание работ по созданию системы

    • перечень стадий и этапов работ

    • сроки исполнения

    • состав организаций — исполнителей работ

    • вид и порядок экспертизы технической документации

    • программа обеспечения надежности

    • программа метрологического обеспечения

    6

    Порядок контроля и приемки системы

    • виды, состав, объем и методы испытаний системы

    • общие требования к приемке работ по стадиям

    • статус приемной комиссии

    7

    Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие

    • преобразование входной информации к машиночитаемому виду

    • изменения в объекте автоматизации

    • сроки и порядок комплектования и обучения персонала

    8

    Требования к документированию

    • перечень подлежащих разработке документов

    • перечень документов на машинных носителях

    9

    Источники разработки

    документы и информационные материалы, на основании которых разрабатывается ТЗ и система

    Эскизный проект предусматривает разработку предварительных проектных решений по системе и ее частям.

    Выполнение стадии эскизного проектирования не является строго обязательной. Если основные проектные решения определены ранее или достаточно очевидны для конкретной ИС и объекта автоматизации, то эта стадия может быть исключена из общей последовательности работ.

    Содержание эскизного проекта задается в ТЗ на систему. Как правило, на этапе эскизного проектирования определяются:

    • функции ИС;

    • функции подсистем, их цели и ожидаемый эффект от внедрения;

    • состав комплексов задач и отдельных задач;

    • концепция информационной базы и ее укрупненная структура;

    • функции системы управления базой данных;

    • состав вычислительной системы и других технических средств;

    • функции и параметры основных программных средств.

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

    5.6. Содержание технического проекта ис

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

    На этом этапе осуществляется комплекс научно-исследовательских и экспериментальных работ для выбора основных проектных решений и расчет экономической эффективности системы.

    Состав и содержание технического проекта приведены в таблице 5.4.

    Таблица 5.4. Содержание технического проекта

    п\п

    Раздел

    Содержание

    1

    Пояснительная записка

    • основания для разработки системы

    • перечень организаций разработчиков

    • краткая характеристика объекта с указанием основных технико-экономических показателей его функционирования и связей с другими объектами

    • краткие сведения об основных проектных решениях по функциональной и обеспечивающим частям системы

    2

    Функциональная и организационная структура системы

    • обоснование выделяемых подсистем, их перечень и назначение

    • перечень задач, решаемых в каждой подсистеме, с краткой характеристикой их содержания

    • схема информационных связей между подсистемами и между задачами в рамках каждой подсистемы

    3

    Постановка задач и алгоритмы решения

    • организационно-экономическая сущность задачи (наименование, цель решения, краткое содержание, метод, периодичность и время решения задачи, способы сбора и передачи данных, связь задачи с другими задачами, характер использования результатов решения, в которых они используются)

    • экономико-математическая модель задачи (структурная и развернутая форма представления)

    • входная оперативная информация ( характеристика показателей, диапазон изменения, формы представления)

    • нормативно-справочная информация ( НСИ) (содержание и формы представления)

    • информация, хранимая для связи с другими задачами

    • информация, накапливаемая для последующих решений данной задачи

    • информация по внесению изменений ( система внесения изменений и перечень информации, подвергающейся изменениям)

    • алгоритм решения задачи ( последовательность этапов расчета, схема, расчетные формулы)

    • контрольный пример (набор заполненных данными форм входных документов, условные документы с накапливаемой и хранимой информацией, формы выходных документов, заполненные по результатам решения экономико-технической задачи и в соответствии с разработанным алгоритмом расчета)

    4

    Организация информационной базы

    • источники поступления информации и способы ее передачи

    • совокупность показателей, используемых в системе

    • состав документов, сроки и периодичность их поступления

    • основные проектные решения по организации фонда НСИ

    • состав НСИ, включая перечень реквизитов, их определение, диапазон изменения и перечень документов НСИ

    • перечень массивов НСИ, их объем, порядок и частота корректировки информации

    • структура фонда НСИ с описанием связи между его элементами; требования к технологии создания и ведения фонда

    • методы хранения, поиска, внесения изменений и контроля

    • определение объемов и потоков информации НСИ

    • контрольный пример по внесению изменений в НСИ

    • предложения по унификации документации

    5

    Альбом форм документов

    6

    Система математического обеспечения

    • обоснование структуры математического обеспечения

    • обоснование выбора системы программирования

    • перечень стандартных программ

    7

    Принцип построения комплекса технических средств

    • описание и обоснование схемы технологического процесса обработки данных

    • обоснование и выбор структуры комплекса технических средств и его функциональных групп

    • обоснование требований к разработке нестандартного оборудования

    • комплекс мероприятий по обеспечению надежности функционирования технических средств

    8

    Расчет экономической эффективности системы

    • сводная смета затрат, связанных с эксплуатацией систем

    • расчет годовой экономической эффективности, источниками которой являются оптимизация производственной структуры хозяйства (объединения), снижение себестоимости продукции за счет рационального использования производственных ресурсов и уменьшения потерь, улучшения принимаемых управленческих решений

    9

    Мероприятия по подготовке объекта к внедрению системы

    • перечень организационных мероприятий по совершенствованию бизнес-процессов

    • перечень работ по внедрению системы, которые необходимо выполнить на стадии рабочего проектирования, с указанием сроков и ответственных лиц

    10

    Ведомость документов

    В завершение стадии технического проектирования производится разработка документации на поставку серийно выпускаемых изделий для комплектования ИС, а также определяются технические требования и составляются ТЗ на разработку изделий, не изготовляемых серийно.

    На стадии "рабочая документация" осуществляется создание программного продукта и разработка всей сопровождающей документации. Документация должна содержать все необходимые и достаточные сведения для обеспечения выполнения работ по вводу ИС в действие и ее эксплуатации, а также для поддержания уровня эксплуатационных характеристик (качества) системы. Разработанная документация должна быть соответствующим образом оформлена, согласована и утверждена.

    Для ИС, которые являются разновидностью автоматизированных систем, устанавливают следующие основные виды испытаний: предварительные, опытная эксплуатация и приемочные. При необходимости допускается дополнительно проведение других видов испытаний системы и ее частей.

    В зависимости от взаимосвязей частей ИС и объекта автоматизации испытания могут быть автономные или комплексные. Автономные испытания охватывают части системы. Их проводят по мере готовности частей системы к сдаче в опытную эксплуатацию. Комплексные испытания проводят для групп взаимосвязанных частей или для системы в целом.

    Для планирования проведения всех видов испытаний разрабатывается документ "Программа и методика испытаний". Разработчик документа устанавливается в договоре или ТЗ. В качестве приложения в документ могут включаться тесты или контрольные примеры.

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

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

    Приемочные испытания проводят для определения соответствия системы техническому заданию, оценки качества опытной эксплуатации и решения вопроса о возможности приемки системы в постоянную эксплуатацию.

    5.7. Типовое проектирование ис

    Методы типового проектирования ИС достаточно подробно рассмотрены в литературе [10]. В данной книге приведены основные определения и представлено задание для разработки проекта ИС методом типового проектирования (кейс "Проектирование ИС предприятия оптовой торговли лекарственными препаратами").

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

    Типовое проектное решение (ТПР) – это тиражируемое (пригодное к многократному использованию) проектное решение.

    Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

    • элементные ТПР - типовые решения по задаче или по отдельному виду обеспечения задачи (информационному, программному, техническому, математическому, организационному);

    • подсистемные ТПР - в качестве элементов типизации выступают отдельные подсистемы, разработанные с учетом функциональной полноты и минимизации внешних информационных связей;

    • объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

    Каждое типовое решение предполагает наличие, кроме собственно функциональных элементов (программных или аппаратных), документации с детальным описанием ТПР и процедур настройки в соответствии с требованиями разрабатываемой системы.

    Основные особенности различных классов ТПР приведены в таблице 5.5.

    Таблица 5.5. Достоинства и недостатки ТПР

    Класс ТПР Реализация ТПР

    Достоинства

    Недостатки

    Элементные ТПР Библиотеки методо-ориентированных программ

    • обеспечивается применение модульного подхода к проектированию и документированию ИС

    • большие затраты времени на сопряжение разнородных элементов вследствие информационной, программной и технической несовместимости

    • большие затраты времени на доработкуТПР отдельных элементов

    Подсистемные ТПР Пакеты прикладных программ

    • достигается высокая степень интеграции элементов ИС

    • позволяют осуществлять: модульное проектирование; параметрическую настройку программных компонентов на различные объекты управления

    • обеспечивают: сокращение затрат на проектирование и программирование взаимосвязанных компонентов; хорошее документирование отображаемых процессов обработки информации

    • адаптивность ТПР недостаточна с позиции непрерывного инжиниринга деловых процессов

    • возникают проблемы в комплексировании разных функциональных подсистем, особенно в случае использования решений нескольких производителей программного обеспечения

    Объектные ТПР Отраслевые проекты ИС

    • комплексирование всех компонентов ИС за счет методологического единства и информационной, программной и технической совместимости

    • открытость архитектуры — позволяет устанавливать ТПР на разных программно-технических платформах

    • масштабируемость — допускает конфигурацию ИС для переменного числа рабочих мест

    • конфигурируемость — позволяет выбирать необходимое подмножество компонентов

    • проблемы привязки типового проекта к конкретному объекту управления, что вызывает в некоторых случаях даже необходимость изменения организационно-экономической структуры объекта автоматизации

    Для реализации типового проектирования используются два подхода: параметрически-ориентированное и модельно-ориентированное проектирование.

    Параметрически-ориентированное проектирование включает следующие этапы: определение критериев оценки пригодности пакетов прикладных программ (ППП) для решения поставленных задач, анализ и оценка доступных ППП по сформулированным критериям, выбор и закупка наиболее подходящего пакета, настройка параметров (доработка) закупленного ППП.

    Критерии оценки ППП делятся на следующие группы:

    • назначение и возможности пакета;

    • отличительные признаки и свойства пакета;

    • требования к техническим и программным средствам;

    • документация пакета;

    • факторы финансового порядка;

    • особенности установки пакета;

    • особенности эксплуатации пакета;

    • помощь поставщика по внедрению и поддержанию пакета;

    • оценка качества пакета и опыт его использования;

    • перспективы развития пакета.

    Внутри каждой группы критериев выделяется некоторое подмножество частных показателей, детализирующих каждый из десяти выделенных аспектов анализа выбираемых ППП. Достаточно полный перечень показателей можно найти в литературе [10].

    Числовые значения показателей для конкретных ППП устанавливаются экспертами по выбранной шкале оценок (например, 10-балльной). На их основе формируются групповые оценки и комплексная оценка пакета (путем вычисления средневзвешенных значений). Нормированные взвешивающие коэффициенты также получаются экспертным путем.

    Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации.

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

    Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

    Репозиторий содержит базовую (ссылочную) модель ИС, типовые (референтные) модели определенных классов ИС, модели конкретных ИС предприятий.

    Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС.

    Типовые модели описывают конфигурации информационной системы для определенных отраслей или типов производства.

    Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

    Бизнес-правила определяют условия корректности совместного применения различных компонентов ИС и используются для поддержания целостности создаваемой системы.

    Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

    Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

    Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов (подробное описание см. в разделе "Этапы проектирования ИС с применением UML").

    Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

    Внедрение типовой информационной системы начинается с анализа требований к конкретной ИС, которые выявляются на основе результатов предпроектного обследования объекта автоматизации (см. раздел "Анализ и моделирование функциональной области внедрения ИС"). Для оценки соответствия этим требованиям программных продуктов может использоваться описанная выше методика оценки ППП. После выбора программного продукта на базе имеющихся в нем референтных моделей строится предварительная модель ИС, в которой отражаются все особенности реализации ИС для конкретного предприятия. Предварительная модель является основой для выбора типовой модели системы и определения перечня компонентов, которые будут реализованы с использованием других программных средств или потребуют разработки с помощью имеющихся в составе типовой ИС инструментальных средств (например, ABAP в SAP, Tools в BAAN).

    Реализация типового проекта предусматривает выполнение следующих операций:

    • установку глобальных параметров системы;

    • задание структуры объекта автоматизации;

    • определение структуры основных данных;

    • задание перечня реализуемых функций и процессов;

    • описание интерфейсов;

    • описание отчетов;

    • настройку авторизации доступа;

    • настройку системы архивирования.

    5.8. Обзор рынка программных продуктов

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

    В таблице 5.6 приведен перечень наиболее популярных в настоящее время программных продуктов для реализации ИС организационного управления различных классов.

    Таблица 5.6. Классификация рынка информационных систем

    Локальные системы

    Малые интегрированные системы

    Средние интегрированные системы

    Крупные интегрированные системы (IC)

    • БЭСТ

    • Инотек

    • Инфософт

    • Супер-Менеджер

    • Турбо-Бухгалтер

    • Инфо-Бухгалтер

    • Concorde XAL Exact

    • NS-2000 Platinum PRO/MIS

    • Scala SunSystems

    • БЭСТ-ПРО

    • 1C-Предприятие

    • БОСС-Корпорация

    • Галактика

    • Парус

    • Ресурс

    • Эталон

    • Microsoft-Business Solutions - Navision, Axapta

    • J D Edwards (Robertson & Blums)

    • MFG-Pro (QAD/BMS)

    • SyteLine (COKAП/SYMIX)

    • SAP/R3 (SAP AG)

    • Baan (Baan)

    • BPCS (ITS/SSA)

    • OEBS (Oracle E-Business Suite)

    Существует классификация ИС в зависимости от уровня управления, на котором система используется.

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

    Задачи, цели, источники информации и алгоритмы обработки на оперативном уровне заранее определены и в высокой степени структурированы.

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

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

    • сравнение текущих показателей с прошлыми;

    • составление периодических отчетов за определенное время, а не выдача отчетов по текущим событиям, как на оперативном уровне;

    • обеспечение доступа к архивной информации и т.д.

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

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

    С точки зрения программно-аппаратной реализации можно выделить ряд типовых архитектур ИС.

    Традиционные архитектурные решения основаны на использовании выделенных файл-серверов или серверов баз данных. Существуют также варианты архитектур корпоративных информационных систем, базирующихся на технологии Internet (Intranet-приложения). Следующая разновидность архитектуры информационной системы основывается на концепции "хранилища данных" (DataWarehouse) - интегрированной информационной среды, включающей разнородные информационные ресурсы. И, наконец, для построения глобальных распределенных информационных приложений используется архитектура интеграции информационно-вычислительных компонентов на основе объектно-ориентированного подхода.

    Индустрия разработки автоматизированных информационных систем управления зародилась в 1950-х - 1960-х годах и к концу века приобрела вполне законченные формы.

    На первом этапе основным подходом в проектировании ИС был метод "снизу-вверх", когда система создавалась как набор приложений, наиболее важных в данный момент для поддержки деятельности предприятия. Основной целью этих проектов было не создание тиражируемых продуктов, а обслуживание текущих потребностей конкретного учреждения. Такой подход отчасти сохраняется и сегодня. В рамках "лоскутной автоматизации" достаточно хорошо обеспечивается поддержка отдельных функций, но практически полностью отсутствует стратегия развития комплексной системы автоматизации, а объединение функциональных подсистем превращается в самостоятельную и достаточно сложную проблему.

    Создавая свои отделы и управления автоматизации, предприятия пытались "обустроиться" своими силами. Однако периодические изменения технологий работы и должностных инструкций, сложности, связанные с разными представлениями пользователей об одних и тех же данных, приводили к непрерывным доработкам программных продуктов для удовлетворения все новых и новых пожеланий отдельных работников. Как следствие - и работа программистов, и создаваемые ИС вызывали недовольство руководителей и пользователей системы.

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

    Сама идея использования универсальной программы накладывает существенные ограничения на возможности разработчиков по формированию структуры базы данных, экранных форм, по выбору алгоритмов расчета. Заложенные "сверху" жесткие рамки не дают возможности гибко адаптировать систему к специфике деятельности конкретного предприятия: учесть необходимую глубину аналитического и производственно-технологического учета, включить необходимые процедуры обработки данных, обеспечить интерфейс каждого рабочего места с учетом функций и технологии работы конкретного пользователя. Решение этих задач требует серьезных доработок системы. Таким образом, материальные и временные затраты на внедрение системы и ее доводку под требования заказчика обычно значительно превышают запланированные показатели.

    Согласно статистическим данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994 году, неудачными оказались более 30% проектов, общая стоимость которых превышала 80 миллиардов долларов. При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход средств составил 189% от запланированного бюджета.

    В то же время, заказчики ИС стали выдвигать все больше требований, направленных на обеспечение возможности комплексного использования корпоративных данных в управлении и планировании своей деятельности.

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

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

    • обеспечивать создание корпоративных ИС, отвечающих целям и задачам организации, а также предъявляемым требованиям по автоматизации деловых процессов заказчика;

    • гарантировать создание системы с заданным качеством в заданные сроки и в рамках установленного бюджета проекта;

    • поддерживать удобную дисциплину сопровождения, модификации и наращивания системы;

    • обеспечивать преемственность разработки, т.е. использование в разрабатываемой ИС существующей информационной инфраструктуры организации (задела в области информационных технологий).

    Внедрение методологии должно приводить к снижению сложности процесса создания ИС за счет полного и точного описания этого процесса, а также применения современных методов и технологий создания ИС на всем жизненном цикле ИС - от замысла до реализации.

    Проектирование ИС охватывает три основные области:

    • проектирование объектов данных, которые будут реализованы в базе данных;

    • проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

    • учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т.п.

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

    • требуемой функциональности системы и уровня ее адаптивности к изменяющимся условиям функционирования;

    • требуемой пропускной способности системы;

    • требуемого времени реакции системы на запрос;

    • безотказной работы системы;

    • необходимого уровня безопасности;

    • простоты эксплуатации и поддержки системы.

    Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются специфичные для него модели - организации, требований к ИС, проекта ИС, требований к приложениям и т.д. Модели формируются рабочими группами команды проекта, сохраняются и накапливаются в репозитории проекта. Создание моделей, их контроль, преобразование и предоставление в коллективное пользование осуществляется с использованием специальных программных инструментов - CASE-средств.

    Процесс создания ИС делится на ряд этапов (стадий [1]), ограниченных некоторыми временными рамками и заканчивающихся выпуском конкретного продукта (моделей, программных продуктов, документации и пр.).

    Обычно выделяют следующие этапы создания ИС: формирование требований к системе, проектирование, реализация, тестирование, ввод в действие, эксплуатация и сопровождение [1] [2]. (Последние два этапа далее не рассматриваются, поскольку выходят за рамки тематики книги.)

    Начальным этапом процесса создания ИС является моделирование бизнес-процессов, протекающих в организации и реализующих ее цели и задачи. Модель организации, описанная в терминах бизнес-процессов и бизнес-функций, позволяет сформулировать основные требования к ИС. Это фундаментальное положение методологии обеспечивает объективность в выработке требований к проектированию системы. Множество моделей описания требований к ИС затем преобразуется в систему моделей, описывающих концептуальный проект ИС. Формируются модели архитектуры ИС, требований к программному обеспечению (ПО) и информационному обеспечению (ИО). Затем формируется архитектура ПО и ИО, выделяются корпоративные БД и отдельные приложения, формируются модели требований к приложениям и проводится их разработка, тестирование и интеграция.

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

    Задача формирования требований к ИС является одной из наиболее ответственных, трудно формализуемых и наиболее дорогих и тяжелых для исправления в случае ошибки. Современные инструментальные средства и программные продукты позволяют достаточно быстро создавать ИС по готовым требованиям. Но зачастую эти системы не удовлетворяют заказчиков, требуют многочисленных доработок, что приводит к резкому удорожанию фактической стоимости ИС. Основной причиной такого положения является неправильное, неточное или неполное определение требований к ИС на этапе анализа.

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

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

    Конечными продуктами этапа проектирования являются:

    • схема базы данных (на основании ER-модели, разработанной на этапе анализа);

    • набор спецификаций модулей системы (они строятся на базе моделей функций).

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

    • будет ли это архитектура "файл-сервер" или "клиент-сервер";

    • будет ли это 3-уровневая архитектура со следующими слоями: сервер, ПО промежуточного слоя (сервер приложений), клиентское ПО;

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

    • будет ли база данных однородной, то есть, будут ли все серверы баз данных продуктами одного и того же производителя (например, все серверы только Oracle или все серверы только DB2 UDB). Если база данных не будет однородной, то какое ПО будет использовано для обмена данными между СУБД разных производителей (уже существующее или разработанное специально как часть проекта);

    • будут ли для достижения должной производительности использоваться параллельные серверы баз данных (например, Oracle Parallel Server, DB2 UDB и т.п.).

    Этап проектирования завершается разработкой технического проекта ИС.

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

    Этап тестирования обычно оказывается распределенным во времени.

    После завершения разработки отдельного модуля системы выполняют автономный тест, который преследует две основные цели:

    • обнаружение отказов модуля (жестких сбоев);

    • соответствие модуля спецификации (наличие всех необходимых функций, отсутствие лишних функций).

    После того как автономный тест успешно пройдет, модуль включается в состав разработанной части системы и группа сгенерированных модулей проходит тесты связей, которые должны отследить их взаимное влияние.

    Далее группа модулей тестируется на надежность работы, то есть проходят, во-первых, тесты имитации отказов системы, а во-вторых, тесты наработки на отказ. Первая группа тестов показывает, насколько хорошо система восстанавливается после сбоев программного обеспечения, отказов аппаратного обеспечения. Вторая группа тестов определяет степень устойчивости системы при штатной работе и позволяет оценить время безотказной работы системы. В комплект тестов устойчивости должны входить тесты, имитирующие пиковую нагрузку на систему.

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

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

    Необходимость контролировать процесс создания ИС, гарантировать достижение целей разработки и соблюдение различных ограничений (бюджетных, временных и пр.) привело к широкому использованию в этой сфере методов и средств программной инженерии: структурного анализа, объектно-ориентированного моделирования, CASE-систем.

    6. Технология создания информационных систем (ис)

    6.1. Требования к инструментальным средствам

    Рассмотрим основные этапы проектирования ИС (без учета деления на стадии проектирования по ГОСТу):

    1) описание бизнес-логики предметной области;

    2) проектирование архитектуры ИС;

    3) непосредственное создание;

    4) тестирование;

    5) сопровождение.

    При выборе средств и методик проектирования необходимо учитывать следующее:

    - ошибки, допущенные на предыдущей стадии проектирования, обходятся в 10 раз дороже, чем на текущей;

    - жизненный цикл создания сложной ИС без использования инструментальных средств, сопоставим с ожидаемым временем ее эксплуатации;

    - реализация проекта по созданию ИС предполагает коллективную работу;

    - изменение внешних условий при проектировании ИС может потребовать внесения дорогостоящих изменений в проект.

    Требования к инструментальным средствам:

    1) средства должны автоматизировать начальные этапы проектирования;

    2) средства должны в несколько раз уменьшать время на проектирование по сравнению с традиционными подходами;

    3) средства должны быть достаточно гибкими к изменяющимся требованиям;

    4) средства должны поддерживать коллективный режим работы.

    6.2. Что такое case-средства?

    В дословном переводе Computer Aided Software Engineering – разработка программного обеспечения с помощью компьютера.

    В настоящее время термин применяется в более широком смысле.

    CASE-средства – это инструментальные средства автоматизации проектирования ИС.

    Рассмотрим функции проектирования, наиболее часто автоматизируемые в рамках CASE-средств:

    - анализ и формулировка требований к ИС;

    - проектирование баз данных и приложений;

    - генерация программного кода;

    - тестирование;

    - обеспечение качества;

    - управление конфигурацией ИС;

    - управление проектом (организация проектирования самой ИС) и др.

    CASE-система – набор CASE-средств, выполненных в рамках единого программного продукта.

    CASE-технология – методология проектирования ИС с использованием CASE-средств.

    В настоящее время на рынке коммерческих программных продуктов присутствуют и отдельные CASE-средства, и системы, и технологии.

    6.3. Подходы к проектированию ис

    Методики, используемые при проектировании, сначала программ, а затем и систем в целом, формировались в течение длительного промежутка времени. Необходимость таких методик проявлялась при разработке сложных программных систем в условиях дефицита времени на разработку. Подобные ситуации были характерны для крупных промышленных корпораций и учреждений оборонного ведомства, поэтому многие современные методики изначально были, например, внутренними стандартами МО США.

    В основе наиболее известных методик проектирования ИС лежат два подхода: структурный и объектно-ориентированный.

    Структурные методы анализа и проектирования используют иерархические структуры для моделирования объекта исследования.

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

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

    Объектно-ориентированный подход основан на выделении агентов, которые являются либо субъектами действий, либо объектами действий. При объектно-ориентированной декомпозиции каждый объект обладает своим собственным поведением и каждый из них моделирует некоторый объект реального мира.

    По своей сути структурный подход и объектно-ориентированный подход ортогональны, то есть, вряд ли удастся спроектировать сложную систему одновременно двумя способами, но можно применить их последовательно.

    6.4. Методы структурного проектирования

    Структурный подход состоит в декомпозиции (разбиении) системы на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи, и т.д. Процесс разбиения продолжается вплоть до конкретных процедур.

    Все наиболее распространенные структурные методы базируются на следующих принципах:

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

    - принцип организации составных частей в иерархические структуры.

    В рамках структурного подхода наиболее часто используемыми моделями являются:

    - SADT (Structured Analysis and Design Technique) – метод структурного анализа и проектирования – модели и соответствующие функциональные диаграммы, объединенные данным названием;

    - DFD (Data Flow Diagrams) – диаграммы потоков данных;

    - ERD (Entity-Relationship Diagrams) – диаграммы "сущность-связь".

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

    SADT-модели используются для моделирования бизнес-процессов на стадии формирования требований к проектируемой ИС и не предназначены для проектирования программного обеспечения. На этой стадии для отображения потоков данных обычно применяются DFD-диаграммы, а для описания данных на концептуальном уровне – ERD-диаграммы.

    На стадии анализа и проектирования DFD-диаграммы используются для описания структуры проектируемой системы, а ERD-диаграммы – для описания модели данных логического и физического уровней. Кроме перечисленных средств на этой стадии широко используются всевозможные структурные схемы (архитектура ИС, иерархия экранных форм, меню и т.п.).

    В начале 90-ых годов прошлого века в США на основе SADT был принят стандарт моделирования бизнес-процессов IDEF0 (http://www.idef.com). Этот стандарт принят в нескольких международных организациях, в том числе в НАТО и МВФ. С 2000г. Стандарт принят в РФ и является стандартом в области построения функциональных моделей при проектировании ИС (РД IDEF0-2000).

    6.5. Методы объектно-ориентированного проектирования

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

    В объектно-ориентированном подходе рассматривается два типа иерархий: "целое-часть" и "род-вид". Этим иерархиям соответствуют такие понятия, как структура объектов и структура классов. В работах Г.Буча утверждается, что эти два типа структур представляют собой каноническую форму декомпозиции любой сложной системы.

    6.6. Пример взаимодействия case-средств

    На примере пакетов программ BPwin, Erwin, Rational Rose и Paradigm Plus рассмотрим возможности CASE-средств (рис. 6.1).

    CASE-средства ERwin и BPwin были разработаны фирмой Logic Works. После слияния с PLATINUM technology они стали продаваться под новой торговой маркой. Позднее владельцем этих пакетов стала Computer Associates.

    BPwin – средство проектирования верхнего уровня, поддерживает три методологии моделирования: функциональное моделирование (IDEF0); описание бизнес-процессов (IDEF3); диаграммы потоков данных (DFD).

    ERwin – средство проектирования баз данных, поддерживает стандарт IDEF1X.

    Paradigm Plus (Computer Associates) поддерживает язык объектно - ориентированного моделирования UML. Rational Rose (фирма Rational Software) также реализует объектно-ориентированный подход на основе языка UML.

    Power Builder – среда разработки под СУБД Sybase.

    Model Mart – хранилище моделей, обеспечивает коллективный доступ и совместное моделирование, работает в архитектуре клиент-сервер;

    Silverrun (Silverrun technology) -

    Oracle Designer (Oracle) -

    Rational Rose (Rational Software) - .

    Комментарии к линиям связи:

    1 – переход от функциональных моделей к моделям данных (автоматизирован частично);

    2 – прямое проектирование базы данных под конкретную СУБД (физическое моделирование) и обратное проектирование (по имеющейся физической модели восстановление логической модели).

    Взаимодействие CASE-средств

    Рис. 6.1

    3 – автоматическая генерация кода приложения (клиентская часть) под наиболее

    популярные средства разработки (техника генерации кода различна для разных сред);

    4 – сгенерированный программный код может быть выполнен в среде СУБД;

    5 – связь с хранилищем моделей;

    6 – прямая генерация программного кода и обратная генерация объектной модели по программному коду;

    7 – прямое и обратное проектирование структуры базы данных по объектной модели.

    6.7. Развитие методологий проектирования

    Исследования в области построения моделей и методов проектирования ИС не заканчиваются моментом принятия некоторого стандарта.

    Кроме уже упомянутых подходов ведутся разработки в других направлениях, в частности, в связи с вопросами реинжиниринга бизнес-процессов. Реинжиниринг предполагает перестройку существующих бизнес-процессов с целью их оптимизации и должен предшествовать созданию ИС.

    Проводятся исследования в области технологий программирования, позволяющих повысить степень автоматизации процесса программирования.

    В общем случае, все существующие и создаваемые модели и методы можно сгруппировать по их отношению к объектам исследования: ИС, фирме и изделию.

    6.8. Методология функционального моделирования idef0. Общие положения

    (см. РД IDEF0 - 2000)

    Модель – искусственный объект, представляющий собой отображение (образ) системы и ее компонентов.

    М моделирует А, если М отвечает на вопросы относительно А.

    Модель разрабатывают для понимания, анализа и принятия решений о реконструкции (реинжиниринге) или замене существующей системы, либо при проектировании новой системы.

    Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу.

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

    В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями.

    При разработке моделей не рекомендуется "привязывать" функции к существующей организационной структуре объекта исследования. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет оценить ее адекватность и предложить решения по совершенствованию структуры.

    6.9. Синтаксис графического языка

    6.9.1. Блок

    Блок – это графическое представление функций, процессов, действий, операций и т.п. Блок представлен на рис. 6.2.

    Изображение блока

    Рис. 6.2

    6.9.2. Стрелка

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

    Стрелки могут состоять только из горизонтальных и вертикальных отрезков со скругленными стыками.

    Стрелки должны присоединяться к блоку на его сторонах. Присоединение в углах не допускается.

    Стрелки помечаются существительными или оборотами существительных.

    Способы изображения стрелок

    Рис. 6.3

    6.10. Семантика языка idef0

    6.10.1. Семантика блоков и стрелок

    На рис. 6.4. показано стандартное изображение блока.

    Изображение блока со стрелками

    Рис. 6.4

    Вход – это то, что преобразуется или расходуется функцией.

    Выход – это то, что произведено функцией (данные или материальные объекты).

    Управление – это условия, которые необходимы функции, чтобы произвести правильный выход.

    Механизм – это средства, необходимые для выполнения функции.

    Вызов – это переход к другому фрагменту модели.

    Пример приведен на рис. 6.5.

    Пример

    Рис. 6.5

    6.10.2. Контекстная диаграмма

    Контекстная диаграмма – это диаграмма верхнего уровня. Она описывает одну функцию и отображает связи объекта моделирования с внешней средой. Стандартное название контекстной диаграммы А-0.

    Контекстная диаграмма содержит краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель создания системы. Пример диаграммы приведен на рис. 6.6.

    Пример контекстной диаграммы

    А-0

    Рис. 6.6

    6.10.3. Дочерние диаграммы

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

    Все дочерние функции должны находиться в области действия родительской функции.

    На каждой диаграмме должен быть представлен один уровень декомпозиции.

    Между блоками одной диаграммы могут существовать следующие типы отношений:

    • доминирование;

    • управление;

    • выход-вход;

    • обратная связь по управлению;

    • обратная связь по входу;

    • выход-механизм.

    Доминирование. Предполагается, что блоки, расположенные на диаграмме выше и левее, оказывают влияние на блоки, расположенные ниже и правее.

    Управление. Выход доминирующего блока служит управляющим воздействием для блока с меньшим доминированием (рис. 6.7).

    Отношение управления

    Рис. 6.7

    Выход-вход. Выход одного блока с входом другого (рис. 6.8).

    Отношение выход-вход

    Рис. 6.8

    Обратная связь по управлению. Возникает, когда выход некоторого блока создает управляющее воздействие на блок с большим доминированием (рис. 6.9).

    Обратная связь по управлению

    Рис. 6.9

    Обратная связь по входу. Выход блока на вход блока с большим доминированием (рис. 6.10).

    Обратная связь по входу

    Рис. 6.10

    Выход-механизм. Возникает, когда выход одной функции становится средством выполнения другой, например, происходит пополнение ресурсов, изготавливаются инструменты, обучается персонал и т.п. (рис. 6.11).

    Выход-механизм

    Рис. 6.11

    6.10.4. Граничные стрелки

    Стрелки на диаграмме декомпозиции, показывающие связь с внешней средой, называются граничными стрелками. Все граничные стрелки на диаграмме декомпозиции соответствуют стрелкам родительского блока (за исключением стрелок, помещенных в тоннель).

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

    Для сохранения преемственности стрелок используются специальные коды: I (Input), C (Control), O (Output), M (Mechanism), которые соответствуют расположению стрелок на родительской диаграмме.

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

    6.10.5. Тоннелирование стрелок

    Для уменьшения количества стрелок на диаграммах используется их тоннелирование, которое изображается круглыми скобками (тоннель) в начале или конце стрелки.

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

    Тоннель на свободном конце означает, что эти данные отсутствуют на родительской диаграмме.

    6.11. Правила построения диаграмм

    1. Должна быть одна контекстная диаграмма А-0.

    2. Блоки на диаграмме декомпозиции должны располагаться по диагонали от верхнего левого угла до нижнего правого.

    3. Диаграмма декомпозиции должна содержать от трех до шести блоков (оптимальное количество).

    4. Блоки нумеруются от верхнего к нижнему, номер проставляется в правом нижнем углу. Если блоки расположены не по диагонали, то они нумеруются после диагональных с нижнего правого блока против часовой стрелки.

    5. Каждый родительский блок должен иметь ссылку на дочернюю диаграмму, ссылка помещается под правым нижним углом блока.

    6. блоки всегда должны иметь хотя бы одну управляющую стрелку и одну выходную стрелку, но могут не иметь входных стрелок.

    7. Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления, что уменьшает сложность диаграммы.

    8. Можно выполнять слияние и разветвление стрелок, если они имеют сходный смысл.

    9. Каждая диаграмма имеет узловой номер. Контекстная – А-0, первая дочерняя – тоже А-0, следующие – А1, А2, А3, … ,А6; далее – А11, А12, … и т.д.

    6.12. Методика разработки функциональных моделей в среде idef0

    6.12.1. Общие положения

    Любая функция преобразует входы в выходы под действием управлений при помощи механизмов.

    Преобразованию могут подвергаться материальные и информационные объекты, образующие соответствующие потоки.

    Информация, которая участвует в преобразовании, может быть разделена на три группы:

    - ограничительная информация;

    - описательная информация;

    - управляющая информация.

    Ограничительная информация – сведения о том, чего нельзя делать: всегда или в рамках одной функции.

    Например: законы, подзаконные акты, стандарты, положения, регламенты, технические требования, условия и т.п.

    Описательная информация – сведения об атрибутах объекта (потока) преобразуемого функцией. Эта информация содержится в чертежах, описаниях, документах и сама может быть преобразована в результате выполнения функции.

    Управляющая информация – сведения о том, как, при каких условиях и по каким правилам следует выполнять функцию. Содержится в инструкциях, руководствах, документах, определяющих функцию.

    Взаимодействие перечисленных понятий представлено на рис. 6.12.

    Основные понятия

    Рис. 6.12

    Материальный поток и информационный поток везде, где это не вызывает недоразумений, можно изображать одной стрелкой.

    6.12.2. Классификация видов функций

    По уровню декомпозиции можно выделить следующие виды функций:

    • деятельность;

    • процесс;

    • операция;

    • действие;

    • субдеятельность;

    • подпроцесс.

    Для всех функций:

    • части функций могут выполняться последовательно или/и параллельно;

    • все функции потребляют финансовые, энергетические, трудовые и материальные ресурсы;

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

    Деятельность (дело, бизнес) – совокупность процессов. Деятельность осуществляется в соответствии с определенной целью, которая может меняться. На деятельность накладывает ограничения внешняя среда.

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

    Операция (бизнес-операция) – совокупность действий. Операция выполняется в соответствии с директивой, являющейся частью директивы на выполнение процесса. Ограничения для действий – ограничения внешней среды и ограничения со стороны других операций.

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

    Субдеятельность – совокупность нескольких процессов в составе деятельности, объединенных некоторой подцелью основной цели.

    Подпроцесс – группа операций в составе процесса, объединенных технологически или организационно.

    Перечисленные виды функций соответствуют возможным уровням декомпозиции на IDEF0-диаграммах.

    По степени участия в достижении основной цели деятельности функции можно разделить на:

    • основные;

    • вспомогательные.

    Основная функция непосредственно участвует в достижении цели, например, в получении прибыли.

    Вспомогательные функции не создают конечного продукта деятельности и, следовательно, прибыли. Пример вспомогательного процесса приведен на рис. 6.13.

    Вспомогательный процесс

    Рис. 6.13

    6.12.3. Классификация механизмов

    Механизмы можно разделить на следующие виды:

    • организационно-техническая система;

    • организационно-техническая подсистема;

    • организационно-технический комплекс (модуль);

    • организационно-технический блок.

    Организационно-техническая система – организационная структура, персонал и комплекс технических средств, необходимых для осуществления деятельности.

    Организационно-техническая подсистема – часть организационно-технической системы, обеспечивающая протекание процесса (субдеятельности).

    Организационно-технический комплекс – часть организационно-технической подсистемы, предназначенная для выполнения операции.

    Организационно-технический блок – часть организационно-технического комплекса, обеспечивающая выполнение действия.

    При правильном построении функциональной модели деятельности, когда блоки диаграмм связываются с объектами организационно-технической структуры, происходит формирование такой организационно-технической структуры, которая наилучшим образом реализует деятельность. Организационно-техническая структура становится результатом функционального моделирования.

    6.12.4. Классификация управляющих воздействий

    Управление – это разновидность функций, которая определяет условия правильного функционирования блока.

    Для управления возможна следующая классификация:

    • управление деятельностью;

    • управление процессом;

    • управление операцией.

    Управление деятельностью – процесс, состоящий, как минимум, из следующих операций:

    • формулирование целей деятельности;

    • оценка ресурсов, "сколько надо и сколько есть";

    • сбор информации о состоянии деятельности и условиях ее протекания;

    • выработка и принятие решений (распределение ресурсов, оформление решений);

    • реализация решений и контроль исполнения;

    • корректировка ранее сформулированных целей.

    Управление процессом – операция, состоящая, как минимум, из следующих действий:

    • анализ директивы на управление процессом, ее декомпозиция на директивы управления операциями;

    • сбор информации о выполнении операций, ее обобщение и формирование сведений о состоянии процесса; передача данных в подсистему управления деятельностью;

    • анализ информации и выработка локальных решений, направленных на устранение отклонений;

    • корректировка директив на выполнение операций процесса.

    Управление операцией – действие, состоящее в выработке на основании директивы на управление операцией, например, следующих команд:

    • на управление действиями;

    • на выполнение команд;

    • по оценке результатов выполнения;

    • по передаче необходимой информации в комплекс управления процессом;

    • по корректировке команд.

    Блоки управления должны присутствовать на каждой IDEF0-диаграмме. Через них осуществляются управляющие воздействия на остальные блоки диаграммы.

    Стрелки, исходящие из блока управления описывают централизованную схему управления (управление по вертикали). Если выход одного из блоков, не являющегося блоком управления, используется как вход по управлению для другого, то это отображает децентрализованное управление (по горизонтали).

    6.12.5. Типизация функциональных моделей

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

    6.12.6. Выводы по методологии функционального моделирования

    Совокупность схем (IDEF0-диаграмм) образует модель системы. Эта модель носит качественный, описательный, декларативный характер. Она принципиально не может ответить на вопросы о том, как протекают процессы во времени и в пространстве, каковы их характеристики, и в какой мере удовлетворяются требования, предъявляемые к системе. Все эти вопросы с неизбежностью возникают после того, как достигнут нижний уровень декомпозиции.

    В этом случае рекомендуется переходить к другим моделям – математическим, имитационным моделям и др.

    По терминологии, принятой в исследовании операций, IDEF0 – модели относятся к классу концептуальных. Концептуальные модели являются основой построения математических моделей.

    Для моделирования динамических процессов в зарубежной практике используется методология IDEF2, которая не стандартизована в нашей стране.

    Учебники к курсу

    1. Грекул В.И., Денищенко Г.Н., Коровкина Н.Л. Проектирование информационных систем Интернет-университет информационных технологий - ИНТУИТ.ру, 2008.

    2. Данилин А., Слюсаренко А. Архитектура и стратегия. "Инь" и "янь" информационных технологий Интернет-университет информационных технологий - ИНТУИТ.ру, 2005.

    Список литературы

    1. Вендров А.М. Проектирование программного обеспечения экономических информационных систем М: «Финансы и статистика», 2000.

    2. Проектирование информационных систем М: «КомпьютерПресс», №9, 2001.

    3. Колтунова Е. Требования к информационной системе и модели жизненного цикла.

    4. Автоматизированные Системы Стадии создания. ГОСТ 34.601-90. Комплекс стандартов на автоматизированные системы ИПК издательство стандартов. 1997.

    5. ISO/IEC 12207:1995.

    6. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя: Пер. с англ. М.: ДМК, 2000.

    7. Thiele D. Life cycle management using life cycle process standards. Abstract.

    8. Козленко Л. Проектирование информационных систем.

    9. Clegg, Dai and Richard Barker Case Method Fast-track: A RAD Approach Adison-Wesley, 1994.

    10. Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем М.: Финансы и статистика, 2002.

    11. Построение и совершенствование систем управления.

    12. Елиферов В.Г., Репин В.В. Бизнес-процессы: регламентация и управление М.: ИНФРА-М, 2004.

    13. Основы организационного бизнеса (01.2002, Эмитент. Существенные факторы, события, действия).

    14. Кондратьев В.В., Краснова В.Б. Модульная программа для менеджеров. Реструктуризация управления компанией М.: Инфра-М, 2000.

    15. Калянов Г.Н. Теория и практика реорганизации бизнес-процессов М.: СИНТЕГ, 2000.

    16. Калянов Г.Н. Структурный системный анализ М.: Лори, 1996.

    17. Калянов Г.Н. Структурный системный анализ М.: Лори, 1997.

    18. Марка Д.А., МакГоуэн К. SADT — методология структурного анализа и проектирования М.: Метатехнология, 1993.

    19. Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, 2003.

    20. Черемных С.В., Ручкин В.С., Семенов И.О. Структурный анализ систем. IDEF-технологии М.: Финансы и статистика, 2001.

    21. Смирнова Г.Н.,Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем. Учебник М.: «Финансы и статистика», 2002.

    22. ГОСТ 6.01.1-87 Единая система классификации и кодирования технико-экономической информации М.: Изд. стандартов, 1987.

    23. Маклаков С.В. Создание информационных систем с AllFusion Modelling Suite М.: Диалог-МИФИ, 2003.

    24. Буч Г. Объектно-ориентированное проектирование с примерами применения М.: Конкорд, 1992.

    25. Нейбург Э. Д., Максимчук Р.А. Проектирование баз данных с помощью UML М.: Издательский дом «Вильямс», 2002.

    Приложение 1. Постановка задачи

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

    Постановка задачи выполняется в соответствии со следующим планом:

    Организационно-экономическая сущность задачи:

    - наименование задачи, место ее решения;

    - цель решения;

    - назначение (для каких объектов подразделений и пользователей предназначена);

    - периодичность решения и требования к срокам решения;

    - источники и способы поступления данных;

    - потребители результатной информации и способы ее отправки;

    - информационная связь с другими задачами.

    Описание исходной (входной) информации:

    - перечень исходной информации;

    - формы представления (документ) по каждой позиции перечня; примеры заполнения документов;

    - количество документов (информации) в единицу времени, количество строк в документе (массиве);

    - описание структурных единиц информации (каждого элемента данных, реквизита);

    - точное и полное наименование, идентификатор, максимальная разрядность в знаках;

    - способы контроля исходных данных:

    - контроль разрядности реквизита;

    - контроль интервала значений реквизита;

    - контроль соответствия списку значений;

    - балансовый или расчетный метод контроля количественных значений реквизитов;

    - метод контроля с помощью контрольных сумм и любые другие возможные способы контроля.

    Описание используемой условно-постоянной информации:

    - перечень условно-постоянной информации (классификаторов, справочников, таблиц, списков с указанием их полных наименование);

    - формы представления;

    - описание структурных единиц информации (по аналогии с исходными записями);

    - способы взаимодействия с переменной информацией.

    Описание результатной (выходной) информации:

    - перечень результатной информации;

    - формы представления (печатная сводка, видеограмма, машинный носитель и его макет и т.д.);

    - периодичность и сроки представления;

    - количество документов (информации) в единицу времени, количество строк в документе (массиве);

    - перечень пользователей результатной информацией (подразделение и персонал);

    - перечень регламентной и запросной информации;

    - описание структурных единиц информации (каждого элемента данных, реквизита) по аналогии с исходными данными;

    - способы контроля результатной информации:

    - контроль разрядности;

    - контроль интервала значений реквизита;

    - контроль соответствия списку значений;

    - балансовый или расчетный метод контроля отдельных показателей;

    - метод контроля с помощью контрольных сумм и любые другие возможные способы контроля.

    Примечание. Для каждого вида входной и выходной информации дается описание всех элементов информации, участвующих в автоматизированной обработке. Описание строится в виде таблицы, в которой присутствуют: наименование элемента информации (реквизита), его идентификатор и максимальная разрядность.

    Наименование реквизита должно соответствовать документу или вытекать из него.

    Идентификатор - условное обозначение, с помощью которого можно оперировать значением реквизита, сокращенное наименование реквизита.

    Разрядность реквизита указывается количеством знаков (алфавитных, цифровых и алфавитно-цифровых).

    Описание алгоритма решения задачи (последовательности действий и логики решения задачи):

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

    - описание связей между частями, операциями, формулами алгоритма;

    - требования к порядку расположения (сортировке) ключевых (главных) признаков в выходных документах, видеограммах, например по возрастанию значений табельных номеров;

    - алгоритм должен учитывать общий и все частные случаи решения задачи.

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

    Приложение 2. Инструментальная среда bPwin

    BPwin имеет достаточно простой и интуитивно понятный интерфейс пользователя. При запуске BPwin по умолчанию появляется основная панель инструментов, палитра инструментов (вид которой зависит от выбранной нотации) и, в левой части, навигатор модели — Model Explorer (рис. П2.1).

    При создании новой модели возникает диалог, в котором следует указать, будет ли создана модель заново или она будет открыта из файла либо из репозитория ModelMart, затем внести имя модели и выбрать методологию, в которой будет построена модель (рис. П2.2).

    Как было указано выше, BPwin поддерживает три методологии — IDEF0, IDEF3 и DFD, каждая из которых решает свои специфические задачи. В BPwin возможно построение смешанных моделей, т. е. модель может содержать одновременно диаграммы как IDEF0, так и IDEF3 и DFD. Состав палитры инструментов изменяется автоматически, когда происходит переключение с одной нотации на другую.

    Рис. П2.1.  Интегрированная среда разработки модели BPwin

    Рис. П2.2.  Диалог создания модели

    Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работа изображается в виде прямоугольников, данные — в виде стрелок. Если щелкнуть по любому объекту модели левой кнопкой мыши, появляется контекстное меню, каждый пункт которого соответствует редактору какого-либо свойства объекта.

    Построение модели idef0

    На начальных этапах создания ИС необходимо понять, как работает организация, которую собираются автоматизировать. Руководитель хорошо знает работу в целом, но не в состоянии вникнуть в детали работы каждого рядового сотрудника. Рядовой сотрудник хорошо знает, что творится на его рабочем месте, но может не знать, как работают коллеги. Поэтому для описания работы предприятия необходимо построить модель, которая будет адекватна предметной области и содержать в себе знания всех участников бизнес-процессов организации.

    Наиболее удобным языком моделирования бизнес-процессов является IDEF0, где система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.

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

    Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами, другими словами, определить, что будет в дальнейшем рассматриваться как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будут существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ. Другими словами, в начале необходимо определить область моделирования. Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в ходе моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования. При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо помнить об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии с увеличением глубины декомпозиции. После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему.

    Цель моделирования

    Цель моделирования определяется из ответов на следующие вопросы:

    • Почему этот процесс должен быть смоделирован?

    • Что должна показывать модель?

    • Что может получить клиент?

    Точка зрения (Viewpoint).

    Под точкой зрения понимается перспектива, с которой наблюдалась система при построении модели. Хотя при построении модели учитываются мнения различных людей, все они должны придерживаться единой точки зрения на модель. Точка зрения должна соответствовать цели и границам моделирования. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом.

    IDEF0-модель предполагает наличие четко сформулированной цели, единственного субъекта моделирования и одной точки зрения. Для внесения области, цели и точки зрения в модели IDEF0 в BPwin следует выбрать пункт меню Model/Model Properties, вызывающий диалог Model Properties (рис. П2.3). В закладке Purpose следует внести цель и точку зрения, а в закладку Definition — определение модели и описание области.

    Рис. П2.3.  Диалог задания свойств модели

    В закладке Status того же диалога можно описать статус модели (черновой вариант, рабочий, окончательный и т. д.), время создания и последнего редактирования (отслеживается в дальнейшем автоматически по системной дате). В закладке Source описываются источники информации для построения модели (например, "Опрос экспертов предметной области и анализ документации"). Закладка General служит для внесения имени проекта и модели, имени и инициалов автора и временных рамок модели — AS-IS и ТО-ВЕ.

    Модели AS-IS и ТО-ВЕ. Обычно сначала строится модель существующей организации работы — AS-IS (как есть). Анализ функциональной модели позволяет понять, где находятся наиболее слабые места, в чем будут состоять преимущества новых бизнес-процессов и насколько глубоким изменениям подвергнется существующая структура организации бизнеса. Детализация бизнес-процессов позволяет выявить недостатки организации даже там, где функциональность на первый взгляд кажется очевидной. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) — модели новой организации бизнес-процессов.

    Технология проектирования ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, то есть создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ИС.

    Иногда текущая AS-IS и будущая ТО-ВЕ модели различаются очень сильно, так что переход от начального к конечному состоянию становится неочевидным. В этом случае необходима третья модель, описывающая процесс перехода от начального к конечному состоянию системы, поскольку такой переход — это тоже бизнес-процесс.

    Результат описания модели можно получить в отчете Model Report. Диалог настройки отчета по модели вызывается из пункта меню Tools/Reports/Model Report.

    В диалоге настройки следует выбрать необходимые поля, при этом автоматически отображается очередность вывода информации в отчет (рис. П2.4).

    Рис. П2.4.  Диалоговое окно для формирования отчета по модели

    На рис. П2.5 представлен отчет, сформированный по вышеуказанным полям.

    Рис. П2.5.  Предварительный просмотр отчета

    Основу методологии IDEF0 составляет графический язык описания бизнес-процессов. Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе.

    Модель может содержать четыре типа диаграмм:

    • контекстную диаграмму (в каждой модели может быть только одна контекстная диаграмма);

    • диаграммы декомпозиции;

    • диаграммы дерева узлов;

    • диаграммы только для экспозиции (FEO).

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

    Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграмм деревьев узлов может быть в модели сколь угодно много, поскольку дерево может быть построено на произвольную глубину и не обязательно с корня.

    диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения, либо для специальных целей.

    Работы (Activity)обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, "Деятельность компании", "Прием заказа" и т.д.). Работа "Деятельность компании" может иметь, например, следующее определение: "Это учебная модель, описывающая деятельность компании". При создании новой модели (меню File/New) автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом (рис. П2.6).

    Рис. П2.6.  Пример контекстной диаграммы

    Для внесения имени работы следует щелкнуть по работе правой кнопкой мыши, выбрать в меню Name Editor и в появившемся диалоге внести имя работы. Для описания других свойств работы служит диалог Activity Properties (рис. П2.7).

    Рис. П2.П2.  Редактор задания свойств работы

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

    Возникает диалог Activity Box Count (рис. П2.8), в котором следует указать нотацию новой диаграммы и количество работ на ней. Остановимся пока на нотации IDEF0 и щелкнем на ОК. Появляется диаграмма декомпозиции (рис. П2.9). Допустимый интервал числа работ — 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с количеством работ более восьми получаются перенасыщенными и плохо читаются. Для обеспечения наглядности и лучшего понимания моделируемых процессов рекомендуется использовать от трех до шести блоков на одной диаграмме.

    Рис. П2.8.  Диалог Activity Box Count

    Рис. П2.9.  Пример диаграммы декомпозиции

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

    Работы на диаграммах декомпозиции обычно располагаются по диагонали от левого верхнего угла к правому нижнему.

    Такой порядок называется порядком доминирования. Согласно этому принципу расположения в левом верхнем углу помещается самая важная работа или работа, выполняемая по времени первой. Далее вправо вниз располагаются менее важные или выполняемые позже работы. Такое размещение облегчает чтение диаграмм, кроме того, на нем основывается понятие взаимосвязей работ (см. ниже).

    Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована. На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу. В левом верхнем углу изображается небольшая диагональная черта, которая показывает, что данная работа не была декомпозирована. Так, на рис. П2.9 все работы еще не были декомпозированы.

    Стрелки(Arrow) описывают взаимодействие работ и представляют собой некую информацию, выраженную существительными.(Например, "Звонки клиентов", "Правила и процедуры", "Бухгалтерская система".)

    В IDEF0 различают пять типов стрелок:

    Вход(Input) — материал или информация, которые используются или преобразуются работой для получения результата (выхода). Допускается, что работа может не иметь ни одной стрелки входа. Каждый тип стрелок подходит к определенной стороне прямоугольника, изображающего работу, или выходит из нее. Стрелка входа рисуется как входящая в левую грань работы. При описании технологических процессов (для этого и был придуман IDEF0) не возникает проблем определения входов. Действительно, "Звонки клиентов" на рис. П2.6 — это нечто, что перерабатывается в процессе "Деятельность компании" для получения результата. При моделировании ИС, когда стрелками являются не физические объекты, а данные, не все так очевидно. Например, при "Приеме пациента" карта пациента может быть и на входе и на выходе, между тем качество этих данных меняется. Другими словами, в нашем примере для того, чтобы оправдать свое назначение, стрелки входа и выхода должны быть точно определены с тем, чтобы указать на то, что данные действительно были переработаны (например, на выходе — "Заполненная карта пациента"). Очень часто сложно определить, являются ли данные входом или управлением. В этом случае подсказкой может служить информация о том, перерабатываются/изменяются ли данные в работе или нет. Если изменяются, то, скорее всего, это вход, если нет — управление.

    Управление(Control) — правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы. На рис. П2.6 стрелка "Правила и процедуры" — управление для работы "Деятельность компании". Управление влияет на работу, но не преобразуется работой. Если цель работы — изменить процедуру или стратегию, то такая процедура или стратегия будет для работы входом. В случае возникновения неопределенности в статусе стрелки (управление или вход) рекомендуется рисовать стрелку управления.

    Выход(Output) — материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Стрелка выхода рисуется как исходящая из правой грани работы. На рис. П2.6 стрелки "Маркетинговые материалы" и "Проданные продукты" являются выходом для работы "Деятельность компании".

    Механизм(Mechanism) — ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы. На рис. П2.6 стрелка "Бухгалтерская система" является механизмом для работы "Деятельность компании". По усмотрению аналитика стрелки механизма могут не изображаться в модели.

    Вызов(Call) — специальная стрелка, указывающая на другую модель работы. Стрелка вызова рисуется как исходящая из нижней грани работы. На рис. П2.10 стрелка "Другая модель работы" является вызовом для работы "Изготовление изделия". Стрелка вызова используется для указания того, что некоторая работа выполняется за пределами моделируемой системы. В BPwin стрелки вызова используются в механизме слияния и разделения моделей.

    Рис. П2.10.  Стрелка вызова, появляющаяся при расщеплении модели

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

    Для внесения граничной стрелки входа следует:

    • щелкнуть по кнопке с символом стрелки ;

    • в палитре инструментов перенести курсор к левой стороне экрана, пока не появится начальная штриховая полоска;

    • щелкнуть один раз по полоске (откуда выходит стрелка) и еще раз в левой части работы со стороны входа (где заканчивается стрелка);

    • вернуться в палитру инструментов и выбрать опцию редактирования стрелки ;

    • щелкнуть правой кнопкой мыши на линии стрелки, во всплывающем меню выбрать Name и добавить имя стрелки в закладке Name диалога IDEF0 Arrow Properties.

    Стрелки управления, входа, механизма и выхода изображаются аналогично. Имена вновь внесенных стрелок (рис. П2.11) автоматически заносятся в словарь Arrow Dictionary.

    Рис. П2.11.  Диалог IDEF0 Arrow Properties

    ICOM-коды. Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 — это не элемент управления нижестоящими работами. Работы нижнего уровня — это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня — это то же самое, что границы диаграммы декомпозиции. ICOM (аббревиатура от Input, Control, Output и Mechanism) — коды, предназначенные для идентификации граничных стрелок. Код ICOM содержит префикс, соответствующий типу стрелки (I, С, О или М), и порядковый номер.

    BPwin вносит ICOM-коды автоматически. Для отображения ICOM-кодов следует включить опцию ICOM codes на закладке Display диалога Model Properties (меню Model/Model Properties) (рис.П2.12).

    Словарь стрелок редактируется при помощи специального редактора Arrow Dictionary Editor, в котором определяется стрелка и вносится относящийся к ней комментарий (рис. П2.13). Словарь стрелок решает очень важную задачу. Диаграммы создаются аналитиком для того, чтобы провести сеанс экспертизы, т. е. обсудить диаграмму со специалистом предметной области. В любой предметной области формируется профессиональный жаргон, причем очень часто жаргонные выражения имеют нечеткий смысл и воспринимаются разными специалистами по-разному. В то же время аналитик — автор диаграмм должен употреблять те выражения, которые наиболее понятны экспертам. Поскольку формальные определения часто сложны для восприятия, аналитик вынужден употреблять профессиональный жаргон, а чтобы не возникло неоднозначных трактовок, в словаре стрелок каждому понятию можно дать расширенное и, если это необходимо, формальное определение.

    Рис. П2.12.  Включение опции ICOM codes на закладке Display

    Рис. П2.13.  Редактирование словаря стрелок

    Содержимое словаря стрелок можно распечатать в виде отчета (меню Tools/ Report /Arrow Report...) и получить толковый словарь терминов предметной области, использующихся в модели.

    Несвязанные граничные стрелки (unconnected border arrow). При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ. Такие стрелки называются несвязанными и воспринимаются в BPwin как синтаксическая ошибка.

    На рис. П2.14 приведен фрагмент диаграммы декомпозиции с несвязанными стрелками, генерирующийся BPwin при декомпозиции работы "Сборка настольных компьютеров" (см. рис. П2.9). Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и потом по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.

    Рис. П2.14.  Пример несвязанных стрелок

    Внутренние стрелки. Для связи работ между собой используются внутренние стрелки, то есть стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.

    Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. В IDEF0 различают пять типов связей работ.

    Связь по входу(output-input), когда стрелка выхода вышестоящей работы (далее — просто выход) направляется на вход нижестоящей (например, на рис. П2.15 стрелка "Собранные компьютеры" связывает работы "Сборка и тестирование компьютеров" и "Отгрузка и получение").

    Рис. П2.15.  Связь по входу

    Связь по управлению(output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей. На рис. П2.16 стрелка "Заказы клиентов" связывает работы "Продажи и маркетинг" и "Сборка и тестирование компьютеров".

    Рис. П2.16.  Связь по управлению

    Обратная связь по входу(output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов. На рис. П2.17 стрелка "Результаты тестирования" связывает работы "Тестирование компьютеров" и "Отслеживание расписания и управление сборкой и тестированием".

    Рис. П2.1П2.  Обратная связь по входу

    Обратная связь по управлению(output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей (стрелка "Результаты сборки и тестирования", рис. П2.18). Обратная связь по управлению часто свидетельствует об эффективности бизнес-процесса. На рис. П2.18 объем продаж может быть повышен путем непосредственного регулирования процессов сборки и тестирования компьютеров (выхода) работы "Сборки и тестирование компьютеров".

    Рис. П2.18.  Обратная связь по управлению

    Связь выход-механизм(output-mechanism), когда выход одной работы направляется на механизм другой. Эта взаимосвязь используется реже остальных и показывает, что одна работа подготавливает ресурсы, необходимые для проведения другой работы (рис. П2.19).

    Рис. П2.19.  Связь выход-механизм

    Явные стрелки. Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.

    Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.

    Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления (рис. П2.20).

    Рис. П2.20.  Пример именования разветвляющейся стрелки

    Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления (рис. П2.21).

    Рис. П2.21.  Пример именования разветвляющейся стрелки

    Недопустима ситуация, когда стрелка до разветвления не именована, а после разветвления не именована какая-либо из ветвей. BPwin определяет такую стрелку как синтаксическую ошибку.

    Правила именования сливающихся стрелок полностью аналогичны — ошибкой будет считаться стрелка, которая после слияния не именована, а до слияния не именована какая-либо из ее ветвей. Для именования отдельной ветви разветвляющихся и сливающихся стрелок следует выделить на диаграмме только одну ветвь, после чего вызвать редактор имени и присвоить имя стрелке. Это имя будет соответствовать только выделенной ветви.

    Туннелирование стрелок. Вновь внесенные граничные стрелки на диаграмме декомпозиции нижнего уровня изображаются в квадратных скобках и автоматически не появляются на диаграмме верхнего уровня (рис. П2.22).

    Рис. П2.22.  Неразрешенная (unresolved) стрелка

    Для их "перетаскивания" наверх нужно щелкнуть правой кнопкой мыши по квадратным скобкам граничной стрелки и в контекстном меню выбрать команду Arrow Tunnel (рис. П2.23).

    Рис. П2.23.  Выбор команды из контекстного меню

    Появляется диалог Border Arrow Editor (рис. П2.24).

    Если щелкнуть по кнопке Resolve Border Arrow, стрелка мигрирует на диаграмму верхнего уровня, если по кнопке Change To Tunnel — стрелка будет туннелирована и не попадет на другую диаграмму. Туннельная стрелка изображается с круглыми скобками на конце (рис. П2.25).

    Рис. П2.24.  Диалог Border Arrow Editor

    Рис. П2.25.  Типы туннелирования стрелок

    Туннелирование может быть применено для изображения малозначимых стрелок. Если на какой-либо диаграмме нижнего уровня необходимо изобразить малозначимые данные или объекты, которые не обрабатываются или не используются работами на текущем уровне, то их необходимо направить на вышестоящий уровень (на родительскую диаграмму). Если эти данные не используются на родительской диаграмме, их нужно направить еще выше, и т. д. В результате малозначимая стрелка будет изображена на всех уровнях и затруднит чтение всех диаграмм, на которых она присутствует. Выходом является туннелирование стрелки на самом нижнем уровне. Такое туннелирование называется "не-в-родительской-диаграмме".

    Другим примером туннелирования может быть ситуация, когда стрелка механизма мигрирует с верхнего уровня на нижний, причем на нижнем уровне этот механизм используется одинаково во всех работах без исключения. (Предполагается, что не нужно детализировать стрелку механизма, т. е. стрелка механизма на дочерней работе именована до разветвления, а после разветвления ветви не имеют собственного имени). В этом случае стрелка механизма на нижнем уровне может быть удалена, после чего на родительской диаграмме она может быть туннелирована, а в комментарии к стрелке или в словаре можно указать, что механизм будет использоваться во всех работах дочерней диаграммы декомпозиции. Такое туннелирование называется "не-в-дочерней-работе" (рис. П2.25).

    Нумерация работ и диаграмм. Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы i декомпозиции А0 имеют номера А1, А2, A3 и т. д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т. д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию — нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы — номер А0, остальные диаграммы декомпозиции — номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т. е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле. Прежние версии диаграммы можно хранить в виде бумажной копии либо как FEO-диаграмму. (К сожалению, при создании FEO-диаграмм отсутствует возможность отката, т. е. из диаграммы можно получить декомпозиции FEO, но не наоборот.) В любом случае следует отличать различные версии одной и той же диаграммы. Для этого существует специальный номер — C-number, который должен присваиваться автором модели вручную. C-number — это произвольная строка, но рекомендуется придерживаться стандарта, когда номер состоит из буквенного префикса и порядкового номера, причем в качестве префикса используются инициалы автора диаграммы, а порядковый номер отслеживается автором вручную, например МСВ00021.

    Диаграммы дерева узлов и feo

    Диаграмма деревьев узлов показывает иерархию работ в модели и позволяет рассмотреть всю модель целиком, но не показывает взаимосвязи между работами (рис. П2.26).Процесс создания модели работ является итерационным, следовательно, работы могут менять свое расположение в дереве узлов многократно. Чтобы не запутаться и проверить способ декомпозиции, следует после каждого изменения создавать диаграмму дерева узлов. Впрочем, BPwin имеет мощный инструмент навигации по модели — Model Explorer, который позволяет представить иерархию работ и диаграмм в удобном и компактном виде, однако составляющей стандарта IDEF0.

    Рис. П2.26.  Диаграмма дерева узлов

    Для создания диаграммы дерева узлов следует выбрать в меню пункт Diagram/Add Node Tree (рис. П2.27). Возникает диалог формирования диаграммы дерева узлов Node Tree Definition (рис. П2.28, П2. 29).

    Рис. П2.27.  Выбор команды для формирования диаграммы дерева узлов

    Рис. П2.28.  Диалог настройки диаграммы дерева узлов (шаг 1)

    Рис. П2.29.  Диалог настройки диаграммы дерева узлов (шаг 2)

    В диалоге Node Tree Definition следует указать глубину дерева — Number of Levels (по умолчанию — 3) и корень дерева (по умолчанию — родительская работа текущей диаграммы). По умолчанию нижний уровень декомпозиции показывается в виде списка, остальные работы — в виде прямоугольников. Для отображения всего дерева в виде прямоугольников следует выключить опцию Bullet Last Level. При создании дерева узлов следует указать имя диаграммы, поскольку, если в нескольких диаграммах в качестве корня на дереве узлов использовать одну и ту же работу, все эти диаграммы получат одинаковый номер (номер узла + постфикс N, например AON) и в списке открытых диаграмм (пункт меню Window) их можно будет различить только по имени.

    Диаграммы "только для экспозиции" (FEO) часто используются в модели для иллюстрации других точек зрения, для отображения отдельных деталей, которые не поддерживаются явно синтаксисом IDEF0. Диаграммы FEO позволяют нарушить любое синтаксическое правило, поскольку по сути являются просто картинками — копиями стандартных диаграмм и не включаются в анализ синтаксиса. Для создания диаграммы FEO следует выбрать пункт меню Diagram/Add FEO Diagram. В возникающем диалоге Add New FEO Diagram следует указать имя диаграммы FEO и тип родительской диаграммы (рис. П2.30).

    Рис. П2.30.  Диалог создания FEO-диаграммы

    Новая диаграмма получает номер, который генерируется автоматически (номер родительской диаграммы по узлу + постфикс F, например A1F).

    Каркас диаграммы

    На рис. П2.31 показан типичный пример диаграммы декомпозиции с граничными рамками, которые называются каркасом диаграммы.

    Рис. П2.31.  Пример диаграммы декомпозиции с каркасом

    Каркас содержит заголовок (верхняя часть рамки) и подвал (нижняя часть). Заголовок каркаса используется для отслеживания диаграммы в процессе моделирования. Нижняя часть используется для идентификации и позиционирования в иерархии диаграммы.

    Смысл элементов каркаса приведен в табл. П2.1 и П2.2.

    Значения полей каркаса задаются в диалоге Diagram Properties (меню Diagram /Diagram Properties) — рис. П2.32.

    Рис. П2.32.  Диалог Diagram Properties

    Таблица П2.1. Поля заголовка каркаса (слева направо)

    Поле

    Смысл

    Used At

    Используется для указания на родительскую работу в случае, если на текущую диаграмму ссылались посредством стрелки вызова

    Autor, Date, Rev, Project

    Имя создателя диаграммы, дата создания и имя проекта, в рамках которого была создана диаграмма. REV-дата последнего редактирования диаграммы

    Notes 123456789 10

    Используется при проведении сеанса экспертизы. Эксперт должен (на бумажной копии диаграммы) указать число замечаний, вычеркивая цифру из списка каждый раз при внесении нового замечания

    Status

    Статус отображает стадию создания диаграммы, отображая все этапы публикации

    Working

    Новая диаграмма, кардинально обновленная диаграмма или новый автор диаграммы

    Draft

    Диаграмма прошла первичную экспертизу и готова к дальнейшему обсуждению

    Recommended

    Диаграмма и все ее сопровождающие документы прошли экспертизу. Новых изменений не ожидается

    Publication

    Диаграмма готова к окончательной печати и публикации

    Reader

    Имя читателя (эксперта)

    Date

    Дата прочтения (экспертизы)

    Context

    Схема расположения работ в диаграмме верхнего уровня. Работа, являющаяся родительской, показана темным прямоугольником, остальные – светлым. На контекстной диаграмме (А-0) показана надпись ТОР. В левом нижнем углу показывается номер по узлу родительской диаграммы:

    Слияние и расщепление моделей

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

    Таблица П2.2. Поля подвала каркаса (слева направо)

    Поле

    Смысл

    Node

    Номер узла диаграммы (номер родительской работы)

    Title

    Имя диаграммы. По умолчанию — имя родительской работы

    Number

    C-Number, уникальный номер версии диаграммы

    Page

    Номер страницы, может использоваться как номер страницы при формировании папки

    BPwin использует для слияния и разветвления моделей стрелки вызова. Для слияния необходимо выполнить следующие условия:

    • Обе сливаемые модели должны быть открыты в BPwin.

    • Имя модели-источника, которое присоединяют к модели-цели, должно совпадать с именем стрелки вызова работы в модели-цели.

    • Стрелка вызова должна исходить из недекомпозируемой работы (работа должна иметь диагональную черту в левом верхнем углу) (рис. П2.33).

    Рис. П2.33.  Стрелка вызова работы "Сборка и тестирование компьютеров" модели-цели

    • Имена контекстной работы подсоединяемой модели-источника и работы на модели-цели, к которой мы подсоединяем модель-источник, должны совпадать.

    • Модель-источник должна иметь, по крайней мере, одну диаграмму декомпозиции.

    Для слияния моделей нужно щелкнуть правой кнопкой мыши по работе со стрелкой вызова в модели-цели и во всплывающем меню выбрать пункт Merge Model.

    Появляется диалог, в котором следует указать опции слияния модели (рис. П2.34). При слиянии моделей объединяются и словари стрелок и работ. В случае одинаковых определений возможна перезапись определений или принятие определений из модели-источника. То же относится к именам стрелок, хранилищам данных и внешним ссылкам. (Хранилища данных и внешние ссылки — объекты диаграмм потоков данных, DFD, будут рассмотрены ниже.)

    Рис. П2.34.  Диалог Continue with merge

    После подтверждения слияния (кнопка OK) модель-источник подсоединяется к модели-цели, стрелка вызова исчезает, а работа, от которой отходила стрелка вызова, становится декомпозируемой — к ней подсоединяется диаграмма декомпозиции первого уровня модели-источника. Стрелки, касающиеся работы на диаграмме модели-цели, автоматически не мигрируют в декомпозицию, а отображаются как неразрешенные. Их следует туннелировать вручную.

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

    Разделение моделей производится аналогично. Для отщепления ветви от модели следует щелкнуть правой кнопкой мыши по декомпозированной работе (работа не должна иметь диагональной черты в левом верхнем углу) и выбрать во всплывающем меню пункт Split Model. В появившемся диалоге Split Options следует указать имя создаваемой модели. После подтверждения расщепления в старой модели работа станет недекомпозированной (признак — диагональная черта в левом верхнем углу), будет создана стрелка вызова, ее имя будет совпадать с именем новой модели, и, наконец, будет создана новая модель, причем имя контекстной работы будет совпадать с именем работы, от которой была "оторвана" декомпозиция.

    Создание отчетов в BPwin

    BPwin имеет мощный инструмент генерации отчетов. Отчеты по модели вызываются из пункта меню Report. Всего имеется семь типов отчетов:

    1. Model Report. Включает информацию о контексте модели — имя модели, точку зрения, область, цель, имя автора, дату создания и др.

    2. Diagram Report. Отчет по конкретной диаграмме. Включает список объектов (работ, стрелок, хранилищ данных, внешних ссылок и т. д.).

    3. Diagram Object Report. Наиболее полный отчет по модели. Может включать полный список объектов модели (работ, стрелок с указанием их типа и др.) и свойства, определяемые пользователем.

    4. Activity Cost Report. Отчет о результатах стоимостного анализа. Будет рассмотрен ниже.

    5. Arrow Report. Отчет по стрелкам. Может содержать информацию из словаря стрелок, информацию о работе-источнике, работе-назначении стрелки и информацию о разветвлении и слиянии стрелок.

    6. Data Usage Report. Отчет о результатах связывания модели процессов и модели данных. (Будет рассмотрен ниже.)

    7. Model Consistency Report. Отчет, содержащий список синтаксических ошибок модели.

    Стоимостный анализ

    Как было указано ранее, обычно сначала строится функциональная модель существующей организации работы — AS-IS (как есть). После построения модели AS-IS проводится анализ бизнес-процессов, потоки данных и объектов перенаправляются и улучшаются, в результате строится модель ТО-ВЕ. Как правило, строится несколько моделей ТО-ВЕ, из которых по какому-либо критерию выбирается наилучшая. Проблема состоит в том, что таких критериев много и непросто определить важнейший. Для того чтобы определить качество созданной модели с точки зрения эффективности бизнес-процессов, необходима система метрики, т. е. качество следует оценивать количественно.

    BPwin предоставляет аналитику два инструмента для оценки модели — стоимостный анализ, основанный на работах (Activity Based Costing, ABC), и свойства, определяемые пользователем (User Defined Properties, UDP). Функциональное оценивание – ABC – это технология выявления и исследования стоимости выполнения той или иной функции (действия). Исходными данными для функционального оценивания являются затраты на ресурсы (материалы, персонал и т.д.). В сравнении с традиционными способами оценки затрат, при применении которых часто недооценивается продукция, производимая в незначительном объеме, и переоценивается массовый выпуск, ABC обеспечивает более точный метод расчета стоимости производства продукции, основанный на стоимости выполнения всех технологических операций, выполняемых при ее выпуске. Стоимостный анализ представляет собой соглашение об учете, используемое для сбора затрат, связанных с работами, с целью определить общую стоимость процесса. Стоимостный анализ основан на модели работ, потому что количественная оценка невозможна без детального понимания функциональности предприятия. Обычно ABC применяется для того, чтобы понять происхождение выходных затрат и облегчить выбор нужной модели работ при реорганизации деятельности предприятия (Business Process Reengineering, BPR). С помощью стоимостного анализа можно решить такие задачи, как определение действительной стоимости производства продукта, определение действительной стоимости поддержки клиента, идентификация наиболее дорогостоящих работ (тех, которые должны быть улучшены в первую очередь), обеспечение менеджеров финансовой мерой предлагаемых изменений и т.д.

    ABC-анализ может проводиться только тогда, когда модель работы последовательная (следует синтаксическим правилам IDEF0), корректная (отражает бизнес), полная (охватывает всю рассматриваемую область) и стабильная (проходит цикл экспертизы без изменений), другими словами, когда создание модели работы закончено.

    ABC включает следующие основные понятия:

    • Объект затрат — причина, по которой работа выполняется, обычно основной выход работы. Стоимость работ есть суммарная стоимость объектов затрат ("Сборка и тестирование компьютеров", рис. П2.35);

    • Двигатель затрат — характеристики входов и управлений работы ("Заказы клиентов", "Правила сборки и тестирования", "Персонал производственного отдела" рис. П2.35), которые влияют на то, как выполняется и как долго длится работа;

    • Центры затрат, которые можно трактовать как статьи расхода.

    Рис. П2.35.  Иллюстрация терминов ABC

    При проведении стоимостного анализа в BPwin сначала задаются единицы измерения времени и денег. Для задания единиц измерения следует вызвать диалог Model Properties (меню Model), закладка ABC Units (рис. П2.36).

    Рис. П2.36.  Настройка единиц измерения валюты и времени

    Если в списке выбора отсутствует необходимая валюта (например, рубль), ее можно добавить. Диапазон измерения времени в списке Unit of measurment достаточен для большинства случаев — от секунд до лет.

    Затем описываются центры затрат (cost centers). Для внесения центров затрат необходимо вызвать диалог Cost Center Editor из меню Model (рис. П2.37).

    Рис. П2.37.  Диалог Cost Center Editor

    Каждому центру затрат следует дать подробное описание в окне Definition. Список центров затрат упорядочен. Порядок в списке можно менять при помощи стрелок, расположенных справа от списка. Задание определенной последовательности центров затрат в списке, во-первых, облегчает последующую работу при присвоении стоимости работам, а во-вторых, имеет значение при использовании единых стандартных отчетов в разных моделях. Хотя BPwin сохраняет информацию о стандартном отчете в файле BPWINRPT.INI, информация о центрах затрат и UDP сохраняется в виде указателей, т. е. хранятся не названия центров затрат, а их номера. Поэтому, если нужно использовать один и тот же стандартный отчет в разных моделях, списки центров затрат должны быть в них одинаковы.

    Для задания стоимости работы (для каждой работы на диаграмме декомпозиции) следует щелкнуть правой кнопкой мыши по работе и на всплывающем меню выбрать Cost (рис. П2.38). В диалоге Activity Cost указывается частота проведения данной работы в рамках общего процесса (окно Frequency) и продолжительность (Duration). Затем следует выбрать в списке один из центров затрат и в окне Cost задать его стоимость. Аналогично назначаются суммы по каждому центру затрат, т. е. задается стоимость каждой работы по каждой статье расхода. Если в процессе назначения стоимости возникает необходимость внесения дополнительных центров затрат, диалог Cost Center Editor вызывается прямо из диалога Activity Properties/Cost соответствующей кнопкой.

    Рис. П2.38.  Задание стоимости работ в диалоге Activity Properties/Cost

    Общие затраты по работе рассчитываются как сумма по всем центрам затрат. При вычислении затрат вышестоящей (родительской) работы сначала вычисляется произведение затрат дочерней работы на частоту работы (число раз, которое работа выполняется в рамках проведения родительской работы), затем результаты складываются. Если во всех работах модели включен режим Compute from Decompositions (рис. П2.38), подобные вычисления автоматически проводятся по всей иерархии работ снизу вверх (рис. П2.39).

    Рис. П2.39.  Вычисление затрат родительской работы

    Этот достаточно упрощенный принцип подсчета справедлив, если работы выполняются последовательно. Встроенные возможности BPwin позволяют разрабатывать упрощенные модели стоимости, которые, тем не менее, оказываются чрезвычайно полезными при предварительной оценке затрат. Если схема выполнения более сложная (например, работы производятся альтернативно), можно отказаться от подсчета и задать итоговые суммы для каждой работы вручную (Override Decompositions). В этом случае результаты расчетов с нижних уровней декомпозиции будут игнорироваться, и при расчетах на верхних уровнях будет учитываться сумма, заданная вручную. На любом уровне результаты расчетов сохраняются независимо от выбранного режима, поэтому при выключении опции Override Decompositions расчет снизу вверх производится обычным образом.

    Для проведения более тонкого анализа можно воспользоваться специализированным средством стоимостного анализа EasyABC (ABC Technology, Inc.). BPwin имеет двунаправленный интерфейс с EasyABC. Для экспорта данных в EasyABC следует выбрать пункт меню File/Export/Node Tree, задать в диалоге Export Node Tree необходимые настройки и экспортировать дерево узлов в текстовый файл (.txt). Файл экспорта можно импортировать в EasyABC. После проведения необходимых расчетов результирующие данные можно импортировать из EasyABC в BPwin. Для импорта нужно выбрать меню File/Import/Costs и в диалоге Import Activity Costs выбрать необходимые установки.

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

    • внешний осмотр — стоимость 50 руб.;

    • пробное включение — стоимость 150 руб.;

    • испытание на стенде — стоимость 300 руб.

    Предположим также, что с точки зрения технологии очередность проведения работ несущественна, а вероятность выявления брака одинакова (50%). Пусть необходимо проверить восемь изделий. Если проводить работы в убывающем по стоимости порядке, то затраты на получение готового изделия составят:

    300 руб. (испытание на стенде)*8 +150 руб. (пробное включение) *4 + 50 руб. (внешний осмотр) *2 = 3100 руб.

    Если проводить работы в возрастающем по стоимости порядке, то на получение готового изделия будет затрачено:

    50 руб. (внешний осмотр) *8 +150 руб. (пробное включение) *4 + 300 руб. (испытание на стенде) *2 = 1600 руб.

    Следовательно, с целью минимизации затрат первой должна быть выполнена наиболее дешевая работа, затем — средняя по стоимости и в конце — наиболее дорогая.

    Результаты стоимостного анализа наглядно представляются на специальном отчете BPwin, настройка которого производится в диалоговом окне Activity Cost Report (меню Tools/Reports/Activity Cost Report) (рис. П2.40). Отчет позволяет документировать имя, номер, определение и стоимость работ, как суммарную, так и раздельно по центрам затрат.

    Рис. П2.40.  Диалог настройки отчета по стоимости работ

    Результаты отображаются и непосредственно на диаграммах. В левом нижнем углу прямоугольника работы может показываться либо стоимость (по умолчанию), либо продолжительность, либо частота проведения работы. Настройка отображения осуществляется в диалоге Model Properties (меню Model/Model Properties), закладка Display (ABC Data, ABC Units).

    Свойства, определяемые пользователем (udp)

    АВС позволяет оценить стоимостные и временные характеристики системы. Если стоимостных показателей недостаточно, имеется возможность внесения собственных метрик — свойств, определенных пользователем — (User Defined Properties, UDP). UDP позволяют провести дополнительный анализ, хотя и без суммирующих подсчетов.

    Для описания UDP служит диалог User-Defined Property Editor (меню Model/UDP Definition Editor) (рис. П2.7). В верхнем окне диалога вносится имя UDP, в списке выбора Datatype описывается тип свойства. Имеется возможность задания 18 различных типов UDP, в том числе управляющих команд и массивов, объединенных по категориям. Для внесения категории следует задать имя категории в окне New Keyword и щелкнуть по кнопке Add Category. Для присвоения свойства категории необходимо выбрать UDP из списка, затем категорию из списка категорий и щелкнуть по кнопке Update. Одна категория может объединять несколько свойств, в то же время одно свойство может входить в несколько категорий. Свойство типа List может содержать массив предварительно определенных значений. Для определения области значений UDP типа List следует задать значение свойства в окне New Keyword и щелкнуть по кнопке Add Member. Значения из списка можно редактировать и удалять.

    Рис. П2.41.  Диалог описания UDP

    Каждой работе можно поставить в соответствие набор UDP. Для этого следует щелкнуть правой кнопкой мыши по работе и выбрать пункт меню UDP. В закладке UDP Values диалога IDEF0 Activity Properties можно задать значения UDP. Результат задания можно проанализировать в отчете Diagram Object Report (меню Tools/Report/Diagram Object Report) (рис. П2.42).

    Рис. П2.42.  Диалог настройки отчета Diagram Object Report