[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 1 из 1
  • 1
Форум » Чердак » Учеба » Проектный практикум
Проектный практикум
АлексейДата: Среда, 12.11.2014, 10:11 | Сообщение # 1
Продвигающийся
Группа: Администраторы
Сообщений: 318
Награды: 4
Репутация: 1
Статус: Оффлайн
Шаблон формирования функционала компании (основных бизнес-функций)На основании списка бизнесов, с помощью матричной проекции ( рис. 4.8) формируется классификатор бизнес-функций компании.


Рис. 4.8. Шаблон формирования основных бизнес-функций
Для формирования основных функций менеджмента компании сначала разрабатываются и утверждаются два базовых классификатора - "Компоненты менеджмента" (перечень используемых на предприятии инструментов/контуров управления) и "Этапы управленческого цикла" (технологическая цепочка операций, последовательно реализуемых менеджерами при организации работ в любом контуре управления). Далее аналогично, с помощью матрицы проекций, формируется список основных функций менеджмента. На рис. 4.9приведены примеры классификаторов, на основании которых построена матрица - генератор основных функций менеджмента.


Рис. 4.9. Шаблон формирования основных функций менеджмента
Представленные матричные проекции ( рис. 4.8рис. 4.9)) позволяют формировать функции любой степени детализации путем более подробного описания как строк, так и столбцов матрицы.
Шаблон формирования зон ответственности за функционал компанииФормирование зон ответственности за функционал компании выполняется с помощью матрицы организационных проекций ( рис. 4.10).


Рис. 4.10. Шаблон распределения функций по организационным звеньям
Матрица организационных проекций представляет собой таблицу, в строках которой расположен список исполнительных звеньев, в столбцах - список функций, выполняемых в компании. Для каждой функции определяется исполнительное звено, отвечающее за эту функцию.
Заполнение такой таблицы позволяет по каждой функции найти исполняющие ее подразделения или сотрудника. Анализ заполненной таблицы позволяет увидеть "пробелы" как в исполнении функций, так и в загруженности сотрудников, а также рационально перераспределить все задачи между исполнителями и закрепить как систему в документе "Положение об организационной структуре".
Положение об организационной структуре - это внутрифирменный документ, фиксирующий: продукты и услуги компании, функции, выполняемые в компании, исполнительные звенья, реализующие функции, распределение функций по звеньям.
Таблица проекций функций на исполнительные звенья может иметь весьма большую размерность. В средних компаниях это, например, 500 единиц - 20 звеньев на 25 функций. В больших компаниях это может быть 5 000 единиц - 50 звеньев на 100 функций.
Аналогично строится матрица коммерческой ответственности.
Шаблон потокового процессного описанияШаблон потокового процессного описания приведен на рис. 4.11. Такое описание дает представление о процессе последовательного преобразования ресурсов в продукты усилиями различных исполнителей на основании соответствующих регламентов.


Рис. 4.11. Потоковая процессная модель
Методики построения процессных моделей будут приведены ниже.
 
АлексейДата: Среда, 12.11.2014, 10:11 | Сообщение # 2
Продвигающийся
Группа: Администраторы
Сообщений: 318
Награды: 4
Репутация: 1
Статус: Оффлайн
Построения организационно-функциональной модели компанииОрганизационно-функциональная модель компании строится на основе функциональной схемы деятельности компании рис. 4.12.


Рис. 4.12. Функциональная схема компании
На основании миссии формируются цели и стратегии компании. С их помощью определяется необходимый набор продуктов и, как следствие - требуемые ресурсы. Воспроизводство продукции происходит за счет переработки ресурсов в основном производственном цикле. Его компоненты формируют необходимые бизнес-функции для поставки ресурсов, производства продуктов и их распределения в места реализации. Для управления указанным процессом воспроизводства формируется совокупность компонентов менеджмента, которая порождает набор функций управления. Для поддержания процессов воспроизводства и управления формируются наборы соответствующих функций обеспечения (охраны, технического оснащения, профилактики и ремонта и пр.). Такой подход позволяет описать предприятие с помощью универсального множества управленческих регистров (цели, стратегии, продукты, функции, организационные звенья и пр.). Управленческие регистры представляют собой иерархические классификаторы. Объединяя классификаторы в функциональные группы и закрепляя между собой элементы различных классификаторов с помощью матричных проекций, можно получить модель организационной структуры компании.
Для построения организационно-функциональной модели используется всего два типа элементарных моделей.
Древовидные модели (классификаторы) - точные иерархические списки выделенных объектов управления (организационных звеньев, функций, ресурсов, в том числе исполнительных механизмов для бизнес-процессов, документов и их структуры, и т.п.). Каждый элемент классификатора может быть дополнительно охарактеризован рядом атрибутов: тип, шкала, комментарий и т.п. Фактически, классификаторы представляют собой набор управленческих регистров, содержащих, в основном, неколичественную информацию, совокупность которых задает систему координат для описания деятельности компании. Количество таких списков-классификаторов определяется целью построения модели.
Матричные модели - это проекции, задающие систему отношений между классификаторами в любой их комбинации. Связи могут иметь дополнительные атрибуты (направление, название, индекс, шкала и вес).
В начальной модели применяется всего несколько классификаторов предметной области:
  • основные группы продуктов и услуг компании;
  • ресурсы, потребляемые компанией в ходе своей деятельности;
  • функции (процессы), поддерживаемые в компании;
  • организационные звенья компании.


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


Главной функцией компании является предоставление продуктов и услуг, поэтому сначала производится формальное описание, согласование и утверждение руководством предприятия перечня его бизнесов (направлений коммерческой деятельности), продукции и услуг. Из этого классификатора внешним контрагентам должно быть понятно, чем предприятие интересно рынку, а для внутренних целей - для чего нужен тот или иной функционал компании.
В результате этих операций производится идентификация функционала и создается единая терминология описания функций предприятия, которая должна быть согласована всеми ведущими менеджерами. При составлении классификатора оргзвеньев важно, чтобы уровень детализации функций соответствовал уровню детализации звеньев. После формирования всех базовых классификаторов с помощью матричных проекций производится их закрепление за оргзвеньями предприятия:
Процесс формирования матрицы проекций функций на оргзвенья на практике напоминает игру в крестики-нолики (рис. 4.10).
По строчкам таблицы указываются подразделения, по столбцам - функции, составляющие содержание процесса управления или бизнес-процесса в данной компании. На пересечениях функций и подразделений, которые ответственны за выполнение функции, ставится крестик. Для проекций большой размерности используется механизм расстановки связей между двумя классификаторами, представленных списками.
Стандартная практика построения моделей организационно-функциональной структуры компаний поддерживает два уровня детализации:
  • агрегированную модель;
  • детализированную модель.
    Агрегированная модель - модель организационной структуры, учетные регистры которой имеют ограничение по степени детализации до 2-3 уровней.
    Целью построения данной модели является предоставление информации об организационной структуре высшим руководителям компании для проведения стратегического анализа, анализа соответствия данной структуры стратегии и внешнему окружению компании. Модель может также предоставляться внешним пользователям (например, потенциальным инвесторам как иллюстрация к бизнес-плану, крупным клиентам и др.).
    Детализированная модель - модель организационной структуры, детализация учетных регистров которой производится на более глубоких уровнях, чем в агрегированной модели. Степень детализации в модели обусловлена конкретными потребностями компании (создание определенных организационных регламентов).
    Целью построения данной модели является предоставление информации о распределении функциональных обязанностей между подразделениями компании, а также об организации бизнес-процессов в компании. Построение детализированной модели позволяет создавать различные внутрифирменные регламенты: Положения об организационной структуре рис. 4.13.
    Ниже приведен пример описания фрагментов организационно-функциональной модели производственного предприятия рис. 4.14 и торгового предприятия рис. 4.15. Приведенные матрицы проекций являются основой для выделения бизнес-процессов предприятия и их владельцев на последующих этапах создания ИС.


    Рис. 4.13. Схема создания Положения об организационно- функциональной структуре компании


    Рис. 4.14. Распределение функций по подразделениям производственного предприятия


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


    Распределение функций по структурным подразделениям в разрезе отдельных функциональных областей деятельности по управлению производственным предприятием представлено на рис. 4.14.
    Функции подразделений торгового предприятия рассматриваются в рамках иных функциональных областей (см. рис. 4.15).
  •  
    АлексейДата: Среда, 12.11.2014, 10:11 | Сообщение # 3
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Инструментальные средства организационного моделирования. 
    Применение современных технологий для организационного моделирования позволяет значительно ускорить организационное проектирование. В начале 1990-х годов на Западе появились первые программы для решения задач, связанных с организационными проблемами управления предприятием. Orgware - новый класс программ - был ориентирован на решение задач систематизации, хранения и обработки "неколичественной" информации об организации бизнеса, которые раньше не имели адекватной компьютерной поддержки.
    Первый российский продукт - БИГ-Мастер - был создан как компьютерный инструмент для поддержки определенной концепции управления предприятием, получившей название регулярного менеджмента. Главной задачей orgware был переход к строго документированным процедурам и регламентам деятельности. В основу компьютерной парадигмы регулярного менеджмента был положен следующий подход: "Надо создавать не систему взаимосвязанных документов, а систему взаимосвязанных информационных моделей предприятия, которые и будут порождать требуемые документы".
    Концептуальной основой БИГ-Мастера стал современный процессный подход к организации деятельности компании. На верхнем уровне система процессов обычно описывается деревом функций - для его обозначения часто используется термин функционал. Функции здесь рассматриваются в качестве "свернутых" процессов. Все процессы-функции, как минимум, должны быть определены (т.е. идентифицированы как вид деятельности, имеющий некую цель и результаты) и классифицированы по видам (основные, обеспечивающие, процессы управления). Также должны быть распределены ответственность и полномочия для управления процессами на регулярной основе. На этом уровне для описания компании в БИГ-Мастере применяются два типа моделей:древовидные модели (классификаторы) и матричные модели (проекции).
    На нижнем уровне выделенные ("ключевые") процессы могут быть описаны как технологическая последовательность операций (для получения требуемых результатов). Для этого применяются потоковые модели бизнес-процессов, назначение которых - описание горизонтальных отношений в организации, связывающих между собой описанные ранее объекты посредством информационных и материальных потоков. Для структурного анализа и проектирования процессов, описываемых потоковыми моделями, БИГ-Мастер поддерживает методологию SADT (IDEF). Наличие механизма матричных проекций позволяет определить и описать процессы компании как целостную взаимосвязанную систему.
    За счет иерархической структуры классификаторов бизнес-модель одновременно содержит отношения "функция-исполнитель" всех степеней детализации, что позволяет с помощью встроенного генератора отчетов настраивать "разрешение" взгляда на компанию применительно к конкретной управленческой задаче. Система проекций позволяет отразить в отчете любые дополнительные свойства, относящиеся к данному объекту (например, квалификационные требования для персонала, задействованного в процессе). Кроме того, взгляд на компанию может быть связан с любой "координатой отсчета" - например, от документа или сотрудника - в каких процессах и как они участвуют и т.п.
    Классификаторы, проекции и потоковые модели бизнес-процессов поддерживаются различными способами их визуализации. Для классификаторов - в виде списков и деревьев (орграфов), для проекции - в виде связанных списков и транспонируемых матриц, а дляпотоковых моделей бизнес-процессов - в виде диаграмм IDEF0 (IDEF3) и текстового описания, что облегчает понимание задач участниками процессов. При этом конструирование самих потоковых моделей происходит в привычных табличных формах.
    В модели возможно формирование неограниченного количества новых классификаторов, проекций и потоковых моделей, а следовательно, отчетов и документов для описания и, что особенно важно, создания регламентов деятельности компании.
    Наличие в БИГ-Мастере нескольких инструментов моделирования является чрезвычайно полезным. Матричные модели поддерживают вертикальную интеграцию - подробное системно-целевое описание компании, выстроенное по иерархии управления и исполняемым функциям. В процессной модели преобладает функционально-технологический подход - горизонтальная интеграция бизнес-операцийпо процедурам. Все вышеперечисленные возможности БИГ-Мастера делают его удобным инструментальным средством организационного моделирования.
     
    АлексейДата: Среда, 12.11.2014, 10:13 | Сообщение # 4
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Процессные потоковые модели.
    Разработка требований к проектируемой ИС строится на основе статического и динамичного описания компании. Статическое описание компании, рассмотренное в лекции 4, проводится на уровне функциональных моделей и включает описание бизнес-потенциала, функционала и соответствующих матриц ответственности.
    Дальнейшее развитие (детализация) бизнес-модели происходит на этапе динамичного описания компании на уровне процессных потоковых моделей.
    Процессные потоковые модели — это модели, описывающие процесс последовательного во времени преобразования материальных и информационных потоков компании в ходе реализации какой-либо бизнес-функции или функции менеджмента. На верхнем уровне описывается логика взаимодействия участников процесса, на нижнем — технология работы отдельных специалистов на своих рабочих местах. Процессные потоковые модели отвечают на вопросы кто—что—как—кому (см. лекцию 4 рис. 4.3).
    Современное состояние экономики характеризуется переходом от традиционной функциональной модели деятельности компании, построенной на принципах разделения труда, узкой специализации и жестких иерархических структурах, к модели процессной, основанной на интеграции работ вокруг бизнес-процессов.
    Главными недостатками функционального подхода являются:
    • разбиение технологий выполнения работы на отдельные фрагменты, иногда между собой несвязанные, которые выполняются различными структурными подразделениями;
    • отсутствие целостного описания технологий выполнения работы;
    • сложность увязывания простейших задач в технологию, производящую реальный товар или услугу;
    • отсутствие ответственности за конечный результат;
    • высокие затраты на согласование, налаживание взаимодействия, контроль и т. д.;
    • отсутствие ориентации на клиента.


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


    Согласно стандарту "Основные Положения и Словарь — ИСО/ОПМС 9000:2000" (п. 2.4) понятие " Процессный подход " определяется как:
    "Любая деятельность, или комплекс деятельности, в которой используются ресурсы для преобразования входов в выходы, может рассматриваться как процесс. Чтобы результативно функционировать, организации должны определять и управлять многочисленными взаимосвязанными и взаимодействующими процессами. Часто выход одного процесса образует непосредственно вход следующего. Систематическая идентификация и менеджмент применяемых организацией процессов, и особенно взаимодействия таких процессов, могут считаться " процессным подходом ".Основной принцип процессного подхода определяет структурирование бизнес–системы в соответствии с деятельностью и бизнес-процессами предприятия, а не в соответствии с его организационно-штатной структурой. Именно бизнес-процессы, обеспечивающие значимый для потребителя результат, представляют ценность и для специалистов, проектирующих ИС. Процессная модель компании должна строиться с учетом следующих положений:
  • Верхний уровень модели должен отражать только контекст диаграммы – взаимодействие моделируемого единственным контекстным процессом предприятия с внешним миром.
  • На втором уровне должны быть отражены тематически сгруппированные бизнес-процессы предприятия и их взаимосвязи.
  • Каждая из деятельностей должна быть детализирована на бизнес-процессы.
  • Детализация бизнес-процессов осуществляется посредством бизнес –функций.
  • Описание элементарной бизнес–операции осуществляется с помощью миниспецификации.
    Процессный подход требует комплексного изучения различных сторон жизни организации — правовых основ и правил деятельности, организационной структуры, функций и показателей результатов их исполнения, интерфейсов, ресурсного обеспечения, организационной культуры. В результате анализа создается модель деятельности "как есть". Обработка этой модели с помощью различных аналитических методов позволяет проверить, насколько деловые процессы рациональны, а также определить, является ли та или иная операция ориентированной на общественно значимый конечный результат или излишней бюрократической процедурой.
    В ходе анализа деловых процессов детально исследуются сферы ответственности подразделений ведомства, его руководителей и сотрудников. Это позволяет установить адреса владельцев деловых процессов, в результате чего процессы перестают быть бесхозными, создаются условия для разработки и внедрения систем стимулирования и ответственности за конечные результаты, определяются моменты и процедуры передачи ответственности. Анализ и оценка деловых процессов позволяют подойти к обоснованию стандартов их выполнения, допустимых рисков и диапазонов свободы принятия решений исполнителями, предельных нормативов затрат ресурсов на единицу эффекта.
    Однако чисто "процессная компания" является скорее иллюстрацией правильной организации работ. В действительности все бизнес-процессы компании протекают в рамках организационной структуры предприятия, описывающей функциональные компетентности и отношения.
    Управление всей текущей деятельностью компании ведется по двум направлениям — управление функциональными областями, которые поддерживают множество унифицированных бизнес-процессов, разделенных на операции, и управление интегрированными бизнес-процессами, задачей которого является маршрутизация и координация унифицированных процессов для выполнения как оперативных заказов потребителей, так и глобальных проектов самой организации (рис. 5.1).


    Рис. 5.1. Схема управления деятельностью компании
    Фактически основной задачей организационного проектирования является выбор оптимального соотношения между эффективностью использования ресурсов и эффективностью процессов. Жесткая специализация подразделений экономит ресурсы организации, но снижает качество реализации процессов. Создание "процессных" команд, включающих собственных специалистов по всем ключевым операциям, обходится достаточно дорого, но при этом значительно сокращается время и повышается точность выполнения процесса. Иногда организации могут позволить себе выбрать этот путь, особенно в тех случаях, когда создается высокая ценность процесса, за которую потребитель согласен платить. Но, как правило, ищется какой-то компромисс на основе процессно-матричных структур. Когда компания начинает ориентироваться на процессы, исключительно важной становится роль владельцев интегрированных межфункциональных процессов, касающихся многих функциональных областей. Кроме того, новая парадигма деятельности предприятия вызывает появление большого числа процессов управления, распределенных по всему предприятию, а не сосредоточенных в специализированных организационных единицах: это системы качества, бюджетирования, маркетинга и т.п. Поэтому постановка бюджетирования как организационной, а не только финансовой задачи предполагает делегирование полномочий, т.е. власти (с которой нелегко расстаются). На более низкие уровни делегируется ответственность за принятие финансовых решений: о заключении сделки-договора, об оплате, о закупке, о скидках и отпуске в кредит и т.п. Это позволяет упростить связи между подразделениями и снизить количество уровней вертикального прохождения документов, т.е. является необходимым условием реализации классической схемы реинжиниринга. Таким образом, процессная ориентация ведет к перестройке организационной структуры, делает организационную структуру компании более "плоской", что иллюстрирует тесную связь между "вертикальным" описанием организации (как структуры распределения ответственности, полномочий и взаимоотношений) и ее "горизонтальным" описанием, как системы процессов.
  •  
    АлексейДата: Среда, 12.11.2014, 10:14 | Сообщение # 5
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Основные элементы процессного подхода
     
    АлексейДата: Среда, 12.11.2014, 10:15 | Сообщение # 6
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Выделение и классификация процессов
     
    АлексейДата: Среда, 12.11.2014, 10:15 | Сообщение # 7
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Референтная модель бизнес-процесса
     
    АлексейДата: Среда, 12.11.2014, 10:16 | Сообщение # 8
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Проведение предпроектного обследования предприятий.
     
    АлексейДата: Среда, 12.11.2014, 10:16 | Сообщение # 9
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Результаты предпроектного обследования
     
    АлексейДата: Среда, 12.11.2014, 10:17 | Сообщение # 10
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Структурная модель предметной области
     
    АлексейДата: Среда, 12.11.2014, 10:18 | Сообщение # 11
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Объектная структура.
    Объект — это сущность, которая используется при выполнении некоторой функции или операции (преобразования, обработки, формирования и т.д.). Объекты могут иметь динамическую или статическую природу: динамические объекты используются в одном цикле воспроизводства, например заказы на продукцию, счета на оплату, платежи; статические объекты используются во многих циклах воспроизводства, например, оборудование, персонал, запасы материалов.
    На внешнем уровне детализации модели выделяются основные виды материальных объектов (например, сырье и материалы, полуфабрикаты, готовые изделия, услуги) и основные виды информационных объектов или документов (например, заказы, накладные, счета и т.д.).
    На концептуальном уровне построения модели предметной области уточняется состав классов объектов, определяются их атрибуты и взаимосвязи. Таким образом строится обобщенное представление структуры предметной области.
    Далее концептуальная модель на внутреннем уровне отображается в виде файлов базы данных, входных и выходных документов ЭИС. Причем динамические объекты представляются единицами переменной информации или документами, а статические объекты — единицами условно-постоянной информации в виде списков, номенклатур, ценников, справочников, классификаторов. Модель базы данных как постоянно поддерживаемого информационного ресурса отображает хранение условно-постоянной и накапливаемой переменной информации, используемой в повторяющихся информационных процессах.
     
    АлексейДата: Среда, 19.11.2014, 09:44 | Сообщение # 12
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн

     

    Структурная модель предметной области

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

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

    К моделям предметных областей предъявляются следующие требования:

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

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

    Структурный аспект предполагает построение:

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

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

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

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

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

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

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

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

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

     
    АлексейДата: Среда, 19.11.2014, 09:47 | Сообщение # 13
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Структуры модели предметной области

    Цитата

    Объектная структура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Организационная структура

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

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

    На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).

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

    Техническая структура

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

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

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

    На внутреннем уровне строится модель "клиент-серверной" архитектуры вычислительной сети.

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

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

    Структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – "разделяй и властвуй" и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых "черных ящиков") и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа.

    Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.

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

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

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

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

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

     
    АлексейДата: Среда, 19.11.2014, 09:50 | Сообщение # 14
    Продвигающийся
    Группа: Администраторы
    Сообщений: 318
    Награды: 4
    Репутация: 1
    Статус: Оффлайн
    Функциональная методика потоков данных

    Цитата

    Целью методики является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram — DFD), обеспечивающей правильное описание выходов (отклика системы в виде данных) при заданном воздействии на вход системы (подаче сигналов через внешние интерфейсы). Диаграммы потоков данных являются основным средством моделирования функциональных требований к проектируемой системе.

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

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

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

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

    Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя должно содержать существительное, например, "склад товаров". Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.

    Кроме основных элементов, в состав DFD входят словари данных и миниспецификации.

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

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

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

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

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

    1.     процесс имеет два-три входных и выходных потока;

    2.     процесс может быть описан в виде преобразования входных данных в выходные;

    3.     процесс может быть описан в виде последовательного алгоритма.

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

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

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

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

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

    К преимуществам методики DFD относятся:

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

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

     
    Форум » Чердак » Учеба » Проектный практикум
    • Страница 1 из 1
    • 1
    Поиск: