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

Главная / Менеджмент /
Основы информационных систем / Тест 1

Упражнение 1:


Номер 1

Что отражает модель жизненного цикла информационной системы?

Ответ:

(1) все события, происходящие с системой в процессе ее создания и использования 

(2) процесс создания системы 

(3) процессы, связанные с использованием системы 

(4) все события в системе во время ее эксплуатации 


Номер 2

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

Ответ:

(1) нет 

(2) да, всегда 

(3) это зависит от проекта 


Номер 3

Какой порядок создания системы предусматривает спиральная модель жизненного цикла?

Ответ:

(1) предусматривает создание прототипов системы в соответствии с изменяющимися требованиями 

(2) спиральная модель не использует понятие жизненного цикла 

(3) предусматривает создание прототипов системы только на этапе ее разработки 


Упражнение 2:


Номер 1

Для чего производится предварительное обследование объекта автоматизации?

Ответ:

(1) для формирования концепции создания системы 

(2) для создания прототипа системы 

(3) для выяснения готовности предприятия к автоматизации 

(4) для формирования команды, которая будет работать над созданием системы 


Номер 2

Укажите основную цель детального обследования объекта автоматизации.

Ответ:

(1) формирование технического задания на систему 

(2) подбор исполнителя для создания системы 

(3) определение целей автоматизации 

(4) выбор технических и программных инструментов 


Номер 3

Отметьте методы сбора информации при проведении обследования объекта автоматизации.

Ответ:

(1) анкетирование 

(2) интервьюирование 

(3) метод аналогий 

(4) создание «фотографии рабочего дня» 

(5) метод проб и ошибок 

(6) метод Монте-Карло 


Упражнение 3:


Номер 1

Осуществляется ли оценка ресурсов операции при планировании времени исполнения проекта?

Ответ:

(1) да 

(2) только при дефиците ресурсов 

(3) нет 


Номер 2

Укажите типы зависимостей между работами проекта.

Ответ:

(1) жесткая 

(2) нежесткая 

(3) внешняя 

(4) гибкая 

(5) внутренняя 


Номер 3

Какие типы зависимостей между работами могут изменяться в процессе выполнения проекта?

Ответ:

(1) нежесткая 

(2) внешняя 

(3) гибкая 

(4) внутренняя 

(5) жесткая 


Упражнение 4:


Номер 1

Что такое "Критический путь проекта"?

Ответ:

(1) самая длинная цепочка работ в проекте 

(2) самая короткая цепочка работ в проекте 

(3) самая дорогая цепочка работ в проекте 

(4) самая дешевая цепочка работ в проекте 


Номер 2

Имеются ли резервы времени у работ, расположенных на критическом пути проекта?

Ответ:

(1) нет 

(2) зависит от пути 

(3) зависит от проекта 

(4) да, имеются всегда 


Номер 3

Имеются ли резервы времени у работ, не расположенных на критическом пути проекта?

Ответ:

(1) да 

(2) нет 

(3) зависит от пути 

(4) зависит от проекта 


Упражнение 5:


Номер 1

Какие ресурсы обозначаются термином "материалы" в проекте?

Ответ:

(1) невозобновляемые 

(2) возобновляемые 

(3) бесплатные 

(4) результаты производства 


Номер 2

Какие типы ресурсов выделяются в управлении проектами?

Ответ:

(1) возобновляемые 

(2) невозобновляемые 

(3) бесплатные 

(4) человеческие 


Номер 3

Как принято в управлении проектами называть "невозобновляемые ресурсы"?

Ответ:

(1) материалы 

(2) сотрудники 

(3) такого понятия не существует 

(4) время 


Упражнение 6:


Номер 1

Какой показатель отражает  ожидаемую величину потерь при реализации риска?

Ответ:

(1) угроза риска 

(2) бюджет проекта 

(3) дефицит бюджета 

(4) такого показателя нет 


Номер 2

Что означает термин "миграция рисков"?

Ответ:

(1) изменение угрозы риска по мере выполнения проекта 

(2) такого термина нет 

(3) исчезновение рисков 

(4) перемещение рисков от одного проекта к другому 


Номер 3

Что включает в себя формулировка риска?

Ответ:

(1) условие и последствие реализации риска 

(2) необходимое и достаточное условие появления рисков 

(3) бюджет для преодоления рисков 

(4) условие преодоления рисков 


Упражнение 7:


Номер 1

Какие виды планов создаются при управлении проектом?

Ответ:

(1) предварительный 

(2) базовый 

(3) текущий 

(4) временный 

(5) окончательный 


Номер 2

Какие планы имеет право изменять руководитель проекта?

Ответ:

(1) текущие 

(2) предварительный 

(3) базовый 

(4) временный 


Номер 3

Имеет ли право руководитель проекта изменять базовый план проекта?

Ответ:

(1) нет 

(2) да, всегда 

(3) это зависит от проекта 

(4) да, если это предусмотрено в плане 


Упражнение 8:


Номер 1

Для чего используется методика оценки освоенного объема в управлении проектом?

Ответ:

(1) она обеспечивает интегрированный и прогнозирующий анализ сроков и стоимости проекта 

(2) она обеспечивает соблюдение бюджета проекта 

(3) для формирования финансового отчета 

(4) для контроля над денежными потоками 


Номер 2

Отметьте методы построения оценок затрат в проекте:

Ответ:

(1) «Сверху – вниз» 

(2) «Снизу – вверх» 

(3) «По аналогам» 

(4) «Параметрический» 

(5) «Слева-направо» 


Номер 3

Позволяет ли методика освоенного объема получить оценку времени завершения проекта?

Ответ:

(1) да 

(2) нет 

(3) это зависит от сложности проекта 


Упражнение 9:


Номер 1

Какие данные обрабатываются в фактографических информационных системах?

Ответ:

(1) структурированные данные в виде текстов и чисел 

(2) любые изображения 

(3) только числовые 

(4) исторические факты 


Номер 2

В информационных системах какого типа не обеспечивается 100-% полнота и точность поиска данных?

Ответ:

(1) в документальных информационных системах 

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

(3) в информационных системах для решения структурированных задач 

(4) в информационных системах для решения финансовых задач 


Номер 3

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

Ответ:

(1) для информационно-поисковых систем 

(2) для документальных информационных систем 

(3) для финансовых и учетных систем 

(4) для любых производственных систем 


Упражнение 10:


Номер 1

Какая модель жизненного цикла наиболее объективно отражает реальный процесс создания сложных систем?

Ответ:

(1) спиральная модель 

(2) каскадная модель 

(3) итерационная модель 

(4) поэтапная модель с промежуточным контролем 


Номер 2

Какую модель жизненного цикла следует использовать при создании простых ИС?

Ответ:

(1) спиральная модель 

(2) каскадная модель 

(3) итерационная модель 

(4) поэтапная модель с промежуточным контролем 


Номер 3

Какие модели жизненного цикла ИС предусматривают возможности пересмотра результатов отдельных этапов проекта?

Ответ:

(1) спиральная модель 

(2) каскадная модель 

(3) итерационная модель 

(4) поэтапная модель с промежуточным контролем 


Упражнение 11:


Номер 1

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

Ответ:

(1) для возможности обобщения информации при обработке 

(2) для удобства 

(3) для формирования отчетов 

(4) для возможности упорядочивания 


Номер 2

Какая система классификации предусматривает группировку объектов по множеству признаков?

Ответ:

(1) многоаспектная 

(2) фасетная 

(3) дискрипторная 

(4) иерархическая 


Номер 3

Какая система классификации предусматривает последовательную группировку объектов по одному признаку?

Ответ:

(1) иерархическая 

(2) многоаспектная 

(3) фасетная 

(4) дискрипторная 


Упражнение 12:


Номер 1

Что такое "референтная модель" бизнес-процесса?

Ответ:

(1) эталонная схема организации бизнеса 

(2) модель, предполагающая работу с конкурентами 

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

(4) это модель, содержащая набор ссылок 


Номер 2

Какая методика моделирования бизнес-процессов основана на представлении функций в виде "черных ящиков"?

Ответ:

(1) структурное моделирование 

(2) объектно-ориентированное моделирование 

(3) визуальное моделирование 

(4) функциональное моделирование 


Номер 3

Какая методология моделирования систем использует понятие "Прецедент"?

Ответ:

(1) методология объектно-ориентированного моделирования 

(2) структурное моделирование 

(3) визуальное моделирование 

(4) функциональное моделирование 


Главная /
Менеджмент /
Основы информационных систем

Основы информационных систем — ответы на тесты Интуит

Правильные ответы выделены зелёным цветом.
Все ответы: Проверка базовых знаний в области информационных систем.

Что отражает модель жизненного цикла информационной системы?

(1) все события, происходящие с системой в процессе ее создания и использования

(2) процесс создания системы

(3) процессы, связанные с использованием системы

(4) все события в системе во время ее эксплуатации

Для чего производится предварительное обследование объекта автоматизации?

(1) для формирования концепции создания системы

(2) для создания прототипа системы

(3) для выяснения готовности предприятия к автоматизации

(4) для формирования команды, которая будет работать над созданием системы

Осуществляется ли оценка ресурсов операции при планировании времени исполнения проекта?

(1) да

(2) только при дефиците ресурсов

(3) нет

Что такое «Критический путь проекта»?

(1) самая длинная цепочка работ в проекте

(2) самая короткая цепочка работ в проекте

(3) самая дорогая цепочка работ в проекте

(4) самая дешевая цепочка работ в проекте

Какие ресурсы обозначаются термином «материалы» в проекте?

(1) невозобновляемые

(2) возобновляемые

(3) бесплатные

(4) результаты производства

Какой показатель отражает ожидаемую величину потерь при реализации риска?

(1) угроза риска

(2) бюджет проекта

(3) дефицит бюджета

(4) такого показателя нет

Какие виды планов создаются при управлении проектом?

(1) предварительный

(2) базовый

(3) текущий

(4) временный

(5) окончательный

Для чего используется методика оценки освоенного объема в управлении проектом?

(1) она обеспечивает интегрированный и прогнозирующий анализ сроков и стоимости проекта

(2) она обеспечивает соблюдение бюджета проекта

(3) для формирования финансового отчета

(4) для контроля над денежными потоками

Какие данные обрабатываются в фактографических информационных системах?

(1) структурированные данные в виде текстов и чисел

(2) любые изображения

(3) только числовые

(4) исторические факты

Какая модель жизненного цикла наиболее объективно отражает реальный процесс создания сложных систем?

(1) спиральная модель

(2) каскадная модель

(3) итерационная модель

(4) поэтапная модель с промежуточным контролем

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

(1) для возможности обобщения информации при обработке

(2) для удобства

(3) для формирования отчетов

(4) для возможности упорядочивания

Что такое «референтная модель» бизнес-процесса?

(1) эталонная схема организации бизнеса

(2) модель, предполагающая работу с конкурентами

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

(4) это модель, содержащая набор ссылок

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

(1) нет

(2) да, всегда

(3) это зависит от проекта

Укажите основную цель детального обследования объекта автоматизации.

(1) формирование технического задания на систему

(2) подбор исполнителя для создания системы

(3) определение целей автоматизации

(4) выбор технических и программных инструментов

Укажите типы зависимостей между работами проекта.

(1) жесткая

(2) нежесткая

(3) внешняя

(4) гибкая

(5) внутренняя

Имеются ли резервы времени у работ, расположенных на критическом пути проекта?

(1) нет

(2) зависит от пути

(3) зависит от проекта

(4) да, имеются всегда

Какие типы ресурсов выделяются в управлении проектами?

(1) возобновляемые

(2) невозобновляемые

(3) бесплатные

(4) человеческие

Что означает термин «миграция рисков»?

(1) изменение угрозы риска по мере выполнения проекта

(2) такого термина нет

(3) исчезновение рисков

(4) перемещение рисков от одного проекта к другому

Какие планы имеет право изменять руководитель проекта?

(1) текущие

(2) предварительный

(3) базовый

(4) временный

Отметьте методы построения оценок затрат в проекте:

(1) «Сверху – вниз»

(2) «Снизу – вверх»

(3) «По аналогам»

(4) «Параметрический»

(5) «Слева-направо»

В информационных системах какого типа не обеспечивается 100-% полнота и точность поиска данных?

(1) в документальных информационных системах

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

(3) в информационных системах для решения структурированных задач

(4) в информационных системах для решения финансовых задач

Какую модель жизненного цикла следует использовать при создании простых ИС?

(1) спиральная модель

(2) каскадная модель

(3) итерационная модель

(4) поэтапная модель с промежуточным контролем

Какая система классификации предусматривает группировку объектов по множеству признаков?

(1) многоаспектная

(2) фасетная

(3) дискрипторная

(4) иерархическая

Какая методика моделирования бизнес-процессов основана на представлении функций в виде «черных ящиков»?

(1) структурное моделирование

(2) объектно-ориентированное моделирование

(3) визуальное моделирование

(4) функциональное моделирование

Какой порядок создания системы предусматривает спиральная модель жизненного цикла?

(1) предусматривает создание прототипов системы в соответствии с изменяющимися требованиями

(2) спиральная модель не использует понятие жизненного цикла

(3) предусматривает создание прототипов системы только на этапе ее разработки

Отметьте методы сбора информации при проведении обследования объекта автоматизации.

(1) анкетирование

(2) интервьюирование

(3) метод аналогий

(4) создание «фотографии рабочего дня»

(5) метод проб и ошибок

(6) метод Монте-Карло

Какие типы зависимостей между работами могут изменяться в процессе выполнения проекта?

(1) нежесткая

(2) внешняя

(3) гибкая

(4) внутренняя

(5) жесткая

Имеются ли резервы времени у работ, не расположенных на критическом пути проекта?

(1) да

(2) нет

(3) зависит от пути

(4) зависит от проекта

Как принято в управлении проектами называть «невозобновляемые ресурсы»?

(1) материалы

(2) сотрудники

(3) такого понятия не существует

(4) время

Что включает в себя формулировка риска?

(1) условие и последствие реализации риска

(2) необходимое и достаточное условие появления рисков

(3) бюджет для преодоления рисков

(4) условие преодоления рисков

Имеет ли право руководитель проекта изменять базовый план проекта?

(1) нет

(2) да, всегда

(3) это зависит от проекта

(4) да, если это предусмотрено в плане

Позволяет ли методика освоенного объема получить оценку времени завершения проекта?

(1) да

(2) нет

(3) это зависит от сложности проекта

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

(1) для информационно-поисковых систем

(2) для документальных информационных систем

(3) для финансовых и учетных систем

(4) для любых производственных систем

Какие модели жизненного цикла ИС предусматривают возможности пересмотра результатов отдельных этапов проекта?

(1) спиральная модель

(2) каскадная модель

(3) итерационная модель

(4) поэтапная модель с промежуточным контролем

Какая система классификации предусматривает последовательную группировку объектов по одному признаку?

(1) иерархическая

(2) многоаспектная

(3) фасетная

(4) дискрипторная

Какая методология моделирования систем использует понятие «Прецедент»?

(1) методология объектно-ориентированного моделирования

(2) структурное моделирование

(3) визуальное моделирование

(4) функциональное моделирование

Ответы на курс: Основы информационных систем

Что включает в себя формулировка риска?

Имеются ли резервы времени у работ, расположенных на критическом пути проекта?

Имеются ли резервы времени у работ, не расположенных на критическом пути проекта?

Что означает термин «миграция рисков»?

В информационных системах какого типа не обеспечивается 100-% полнота и точность поиска данных?

Какую модель жизненного цикла следует использовать при создании простых ИС?

Какая методика моделирования бизнес-процессов основана на представлении функций в виде «черных ящиков»?

Имеет ли право руководитель проекта изменять базовый план проекта?

Укажите основную цель детального обследования объекта автоматизации.

Какие планы имеет право изменять руководитель проекта?

Какой порядок создания системы предусматривает спиральная модель жизненного цикла?

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

Позволяет ли методика освоенного объема получить оценку времени завершения проекта?

Осуществляется ли оценка ресурсов операции при планировании времени исполнения проекта?

Что отражает модель жизненного цикла информационной системы?

Для чего используется методика оценки освоенного объема в управлении проектом?

Какие ресурсы обозначаются термином «материалы» в проекте?

Для чего производится предварительное обследование объекта автоматизации?

Какая модель жизненного цикла наиболее объективно отражает реальный процесс создания сложных систем?

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

Какой показатель отражает ожидаемую величину потерь при реализации риска?

Какие данные обрабатываются в фактографических информационных системах?

Что такое «Критический путь проекта»?

Что такое «референтная модель» бизнес-процесса?

Система модели «чёрного ящика»

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

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

Определение

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

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

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

Устройство модели «чёрного ящика»

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

Замечание

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

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

Пример

Бытовая модель телевизора такая: входы – шнур электропитания, антенна, кнопки управления на пульте; выходы – экран и звуковые колонки.

Касательно других случаев, то необходимо более детально описать количественные факторы всех входов и выходов. В стремлениях максимально формализовать модель чёрного ящика, нужно задать всего два множества X и Y и выходных переменных. Важно, что никаких других отношений между ними фиксировать нельзя, в противном случае эта система примет вид уже не чёрного ящика, а скорее прозрачного или белого.

Людмила Салютова

Экономист. Преподаватель экономической теории

ВЫ СТУДЕНТ ММУ (Московский Международный Университет) и ОБУЧАЕТЕСЬ ДИСТАНЦИОННО?
На ЭТОМ сайте, Вы найдете ответы на вопросы тестов ММУ.
Регистрируйтесь, пополняйте баланс и без проблем сдавайте тесты ММУ.

ПРЕИМУЩЕСТВА ПОЛЬЗОВАНИЯ САЙТОМ ЗДЕСЬ

Как посмотреть ответ ИНСТРУКЦИЯ 

У ВАС ДРУГОЙ ВУЗ, НЕ БЕДА…..
ПОСМОТРИТЕ ДРУГИЕ НАШИ САЙТЫ С ОТВЕТАМИ — СПИСОК
Если в списке нет Вашего вуза, вернитесь сюда и купите найденный Вами вопрос, иногда предметы полностью совпадают в разных вузах.

Какая методика моделирования бизнес-процессов основана на представлении функций в виде «черных ящиков».

Выберите один ответ:

a. визуальное моделирование

b. структурное моделирование

c. объектно-ориентированное моделирование

d. функциональное моделирование

ОТВЕТ предоставляется за плату. Цена 4 руб. ВОЙТИ и ОПЛАТИТЬ

ПРЕДМЕТ: Информатика (1/2)

КУПЛЕНО РАЗ: 171

/informatika-1-2/86928-kakaya-metodika-modelirovaniya-biznes-protsessov-osnovana-na-predstavlenii-funktsij-v-vide-chernykh-yashchikov

Моделирование бизнеса. Основные подходы

Время на прочтение
9 мин

Количество просмотров 77K

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

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

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

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

Основные подходы

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

  • Функциональный;
  • Процессный;
  • Ментальный (с применением ментальных карт).

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

Функциональное моделирование

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

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

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

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

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

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

Процессное моделирование (моделирование бизнес процессов)

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

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

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

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

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

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

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

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

Ментальный подход (ментальные карты)

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

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

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

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

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

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

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

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

Методология и языки бизнес-моделирования

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

Методология — это система принципов и стандартов описания бизнес моделей и их последующего анализа. В то время как язык бизнес-моделирования – это не более чем инструмент для разработки моделей бизнеса.

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

Отличие языков разработки бизнес-моделей в от языков проектирования систем

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

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

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

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

Преимущества разработки моделей бизнеса

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

На самом деле, стандарты и правила – это огромный плюс:

  1. Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает простоту восприятия.
  2. Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить – это намного быстрее, чем каждый раз придумывать и пояснять собственный набор обозначений.
  3. Снижается число возможных ошибок. Сами элементы системы уже будут «подсказывать» перечень возможных и необходимых действий. А в случае создания исполняемых моделей или неисполняемых, но в строгих рамках правил, всегда можно проверить работу бизнес-модели в исполняемой среде и провести отладку, как при программировании.

Применение моделей бизнеса на практике

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

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

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

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

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

Анализ предметной области. Основные понятия системного и структурного анализа.

Анализ предметной области

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

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

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

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

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

Анализ деятельности крупной организации, такой, как банк с сетью региональных отделений, нефтеперерабатывающий завод или компания, производящая автомобили, дает огромные объемы информации. Из этой информации надо уметь отбирать существенную, а также надо уметь находить в ней пробелы — области деятельности, информации по которым недостаточно для четкого представления о решаемых задачах. Значит, всю получаемую информацию надо каким-то образом систематизировать. Для систематизации сбора информации о больших организациях и дальнейшей разработки систем, поддерживающих их деятельность, применяется схема Захмана (автор — John Zachman) или архитектурная схема предприятия (enterprise architecture framework).

Схема Захмана

Таблица 1. Схема Захмана. Приведены примеры моделей для отдельных клеток.

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

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

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

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

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

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

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

Схема деятельности компании в нотации Йордана-ДеМарко

Рисунок 1. Схема деятельности компании в нотации Йордана-ДеМарко.

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

Используются несколько систем обозначений для перечисленных элементов, наиболее известны нотация Йордана-ДеМарко (Yourdon-DeMarco) и нотация Гэйна-Сарсона (GaneSarson), обе предложенные в 1979 году. Рис. 1 показывает диаграмму потоков данных, которая описывает деятельность компании, управляющей небольшим магазином. Эта диаграмма изображена в нотации Йордана-ДеМарко: процессы изображаются кружками, внешние сущности — прямоугольниками, а хранилища данных — двумя горизонтальными параллельными линиями. На Рис. 2 изображена та же диаграмма в нотации Гейна-Сарсона: на ней процессы — прямоугольники со скругленными углами, внешние сущности — прямоугольники с тенью, а хранилища данных — вытянутые горизонтально прямоугольники без правого ребра.

Схема деятельности компании в нотации Гэйна-Сарсона

Рисунок 2. Схема деятельности компании в нотации Гэйна-Сарсона.

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

Детализация процесса "Управление персоналом"

Рисунок 3. Детализация процесса «Управление персоналом».

Диаграммы потоков данных появились как один из первых инструментов представления деятельности сложных систем при использовании структурного анализа. Для представления структуры данных в этом подходе используются диаграммы сущностей и связей (entityrelationship diagrams, ER diagrams), изображающие набор сущностей предметной области и связей между ними. И сущности, и связи на таких диаграммах могут иметь атрибуты. Пример такой диаграммы представлен на Рис. 4.

Модель сущностей и связей

Рисунок 4. Модель сущностей и связей.

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

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

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

Основные понятия системного анализа

  • Задачи структурного системного анализа
  • Истоки структурного моделирования
  • Идеи и принципы ССА
  • Другие принципы ССА
  • Инструментарий ССА
  • Принципы построения ИС

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

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

Задачи структурного системного анализа

В менеджменте перед ССА ставятся следующие задачи:

  • описать существующее положение вещей (объект управления), т.е. построить так называемую модель «как есть» («AS-IS»);
  • предложить новые решения по структуре управления или технологии выполнения бизнес-процессов, т.е. построить модель «как должно быть» («ТО-ВЕ»). При этом предприятие рассматривается в качестве сложной бизнес-системы, функционирующей на основе определенного множества бизнес-процессов. Задачей реорганизации является перевод предприятия в некоторое целевое состояние, характеризующееся, как правило, качественно более высоким уровнем организации работы за счет:
    • повышения эффективности бизнес-процессов;
    • создания организационной структуры, направленной на поддержку выполнения бизнес-процессов;
    • создания информационной системы поддержки выполнения бизнес-процессов.

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

В процессе ССА рассматриваются функциональные, информационные и динамические модели, а также модели функционально-стоимостного анализа (АВС-модели).

Истоки структурного моделирования

В основе ССА лежит графическое представление исследуемого или проектируемого объекта.
Основы современных методов структурно-функционального анализа и моделирования сложных систем были разработаны в трудах профессора Массачусетского технологического института Дугласа Росса, который впервые использовал понятие «структурный анализ» в конце 60-х годов. О дальнейшем развитии идеи описания сложных объектов с помощью относительно небольшого набора типовых элементов свидетельствовало появление методологии структурно-функционального моделирования и анализа сложных систем (SADT), которая постоянно совершенствовалась и широко использовалась для эффективного решения целого ряда проблем (управление финансами и материально-техническим снабжением крупных фирм; разработка программного обеспечения АСУ телефонными сетями; долгосрочное и стратегическое планирование деятельности фирм; проектирование вычислительных систем и сетей и др.).

Идеи и принципы ССА

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

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

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

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

Методы ССА основаны на следующих принципах, помогающих преодолеть сложности, возникающие при описании систем:

  • расчленение систем на части «черные ящики»;
  • иерархическая организация этих «черных ящиков»;
  • использование графических средств.

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

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

Второй важной идеей, лежащей в основе структурных методов, является идея иерархии.

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

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

Другие принципы ССА

Методология ССА строится на общих (базовых) принципах. Но существуют также и другие принципы, без учета которых не возможно проведение ССА:

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

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

Классы моделей ССА:

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

Инструментарий ССА

В качестве компьютерного инструмента ССА используются CASE-средства.

CASE-cpедcmвa — комплекс средств автоматизации для анализа, проектирования, разработки и сопровождения сложных систем.

В основе CASE лежат такие понятия, как методология, метод, нотация и средство.

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

Метод — процедура или техника описания компонентов объекта исследования, программного обеспечения или ИС.

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

Средства — инструментарий для поддержки и усиления методов.

Принципы построения ИС.

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

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

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

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

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

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

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

Принцип единого информационного пространства:

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

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

Принцип надежности, защищенности и безопасности:

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

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

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

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

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

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

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

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

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

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


Рассмотренные базовые принципы дополняются не менее важными организационно-технологическими, без которых невозможна разработка новых информационных технологий. Наиболее применяемые организационно-технологические принципы создания АИТ:

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

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

Пример описания предметной области «Фитнесс-центр»

Программа для фитнес-центра по распределению фитнес – расписания и контроля его соблюдения

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

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

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

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

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

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

Контрольные вопросы

  1. Что такое «CASE-cpедcmвa»
    Перечислите понятия, лежащие в основе CASE
  2. Назовите основополагающие принципы создания АИС
  3. Назовите базовые принципы проектирования
  4. Назовите организационно-технологические принципы создания АИТ

Like this post? Please share to your friends:
  • Какая модель жизненного цикла компании является на сегодняшний день наиболее популярной модель врума
  • Какие аспекты бизнес стратегии влияют на стратегию вознаграждения глобализация ориентация унификация
  • Какие аспекты бизнес стратегии оказывают влияние на стратегию вознаграждения глобализация ориентация
  • Какие варианты размещения на бланке постоянных реквизитов вы знаете каковы особенности их оформления
  • Какие виды работ не запрещено проводить на погрузочных площадках во время слива или налива сжиженого