с чего начинается описание системы

Как описать свою ИТ-систему? Советы бывалого автоматизатора

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

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

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

Надеемся, она окажется полезной и для Вас.

МОДЕЛЬ ОПИСАНИЯ ИТ-СИСТЕМЫ

Рисунок 1. Модель описания ИТ-системы

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

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

2.Подсистема – это нечто крупное, то, что определяет собой относительно самодостаточную предметную область. Это может быть:

Рисунок 2. Описание ИТ-системы на примере подсистемы транспортной логистики

3. В подсистеме есть функции. Если рассматривать как пример подсистему транспортной логистики, то в ней есть функции:

4. Операции находятся внутри функций. Операции — это составляющие элементы функции, каждая из которых подкреплена какой-то функциональностью в ИТ-системе.

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

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

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

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

ЧТО ДАЁТ ТАКОЕ ОПИСАНИЕ ИТ-СИСТЕМЫ?

На начальном этапе построения ИТ- системы у нас появляется целевой результат в проекте. Мы точно знаем — к чему идти, какую функциональность мы должны реализовать с ИТ-системе.

Описание как раз помогает всем участникам проекта внедрения/развития ИТ-системы фиксировать результат его завершённости.

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

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

Модель описания ИТ-системы (Рисунок 1) как раз позволяет упорядочить и структурировать весь набор инструкции, которые есть по работе с системой. Как следствие, мы довольно быстро ориентируемся в документации и быстро находим всю необходимую нам информацию.

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

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

Если ИТ-система более-менее крупная, то она не передаётся на сопровождение целиком и за раз. Система запускается по операциям, по функциям, по подсистемам.

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

У любой системы есть планы по её развитию. И это нормально — всегда хочется от системы получать большего.

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

Во-первых, сами уровни являются некоторыми навигаторами развития нашей системы.

Во-вторых, есть возможность оценивать текущее состояние системы и векторы её развития. Мы должны понимать — куда она развивается, в каком именно месте (какие подсистемы, функции, операции) и в каком состоянии развития находится.

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

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

ВМЕСТО ЗАКЛЮЧЕНИЯ

Конечно, в небольшой статье мы не опишем все детали и особенности модели описания ИТ-системы.

У В компании у нас есть внутренние документы, регламентирующие описание ИТ-системы с более точными формулировками каждого уровня и с наличием примеров.

Готовы поделиться с вами этой документацией, если у вас есть интерес к структурированному описанию своей ИТ-системы.

Источник

Как создать шаблон описания системы и начать его использовать

Когда в IT-компании работают 6 человек, которые пилят одну систему и обсуждают её в кулуарах, описание системы и документация кажутся ненужными. Но когда систем уже более 100, без описания не обойтись. Ведь непродуманное изменение UI может остановить создание заказов. Мы создали единый шаблон описания системы, чтобы документация стала максимально полезной.

Меня зовут Александра Камзеева, я работаю системным аналитиком уже 9 лет, из них 3.5 года в Lamoda. Я много читаю, анализирую текущую документацию и создаю новую. В работе я всегда структурирую информацию и делаю её максимально удобной.

Плюсы хорошего описания системы таковы:

Что такое шаблон и зачем он нужен

Для начала я опишу свое понимание шаблона. Давайте представим, что мне надо найти маленькую машинку в неприбранной комнате. Не факт, что я справлюсь. Зато могу случайно наступить на детальку Лего.

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

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

В каких условиях мы работаем с документацией

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

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

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

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

Просто добавь две кнопки

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

У нас был проект Self Order Management (SOM). Мы решили добавить в личный кабинет клиента две кнопки: «Перенос даты доставки» и «Отмена заказа». До этого клиент мог отменить или перенести заказ только звонком в контакт-центр. Понятно, что у некоторых покупателей не было времени или желания общаться с оператором. В итоге торговый представитель мог привезти ненужный заказ или не застать клиента дома. В таких случаях Lamoda несет издержки. Проект был нужный и важный.

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

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

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

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

Проблема чистого листа

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

Как мы создавали шаблон и что получилось

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

Сначала мы определили признаки хорошего шаблона:

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

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

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

Проверяем качество шаблона

Полученный документ мы проверили на наше определение хорошего шаблона в Lamoda:

Самые полезные разделы шаблона

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

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

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

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

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

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

Как я начала использовать шаблон в своей системе

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

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

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

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

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

Как мы распространяли шаблон

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

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

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

Обратная связь о шаблоне

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

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

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

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

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

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

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

Советы себе и желающим повторить наш путь

Источник

С чего начинается описание системы

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

Модель — описание системы, отражающее определенную группу ее свойств.

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

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

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

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

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

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

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

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

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

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

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

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

где T — множество моментов времени, х — множество мгновенных значений входных воздействий, С = — множество допустимых входных воздействий; Q — множество состояний; y — множество значений выходных величин; Y = — множество выходных величин; φ =— переходная функция состояния; η:T×Q → y — выходное отображение; с — отрезок входного воздействия; u — отрезок выходной величины.

Такое описание системы охватывает широкий диапазон свойств.

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

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

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

Процессы i(1)> можно обнаружить на выходе системы. Это процессы взаимодействия со средой. Будем называть их процессами первого уровня и полагать, что они определяются:

Среда имеет непосредственный контакт с подсистемами низших уровней, воздействуя через них на подсистемы более высокого уровня иерархии, так что F_i * = F_i * (k>, l>, p>). Путем построения иерархии (параметры β-го уровня — процессы (β-1)-го уровня — параметры (β-1)-го уровня) можно связать свойства среды с эффективностью системы.

Параметры системы j> могут изменяться при изменении среды, они зависят от процессов в системе и записываются в виде функционалов состояния Q_j 1 (t).

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

Состояние может сохраняться постоянным на некотором интервале времени Т.

Процессы i(2)> не могут быть обнаружены на выходе системы. Это процессы второго уровня, которые зависят от параметров Q(2) подсистем системы (параметров второго уровня). И так далее.

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

Внешние характеристики системы определяются верхним уровнем иерархии, поэтому часто удается ограничиться описанием вида (<Э_i>,<ψ_S>, i(1)>, j(1)>, k>, l>, p>). Число уровней иерархии зависит от требуемой точности представления входных процессов.

Графические способы функционального описания систем

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

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

Целевая функция системы соответствует ее основному функциональному назначению, т.е. целевая (главная) функция — отражает назначение, сущность и смысл существования системы.

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

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

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

Рис. — Описание объекта на языке функций в виде графа

Формулировка функции внутри вершин должна включать 2 слова: глагол и существительное «Делать что».

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

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

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

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

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

Краткое описание методологии IDEF0

Объектами моделирования являются системы.

Описание IDEF0 модели построено в виде иерархической пирамиды, в вершине которой представляется самое общее описание системы, а основание представляет собой множество более детальных описаний.

IDEF0 методология построена на следующих принципах:

Необходимость соблюдения правил и точность передачи информации. При IDEF0 моделировании необходимо придерживаться следующих правил:

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

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

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

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

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

В рамках методологии IDEF0 модель системы описывается при помощи Графических IDEF0 Диаграмм и уточняется за счет использования FEO, Текстовых и Диаграмм Глоссария. При этом модель включает в себя серию взаимосвязанных Диаграмм, разделяющих сложную систему на составные части. Диаграммы более высокого уровня (А-0, А0) — являются наиболее общим описанием системы, представленным в виде отдельных Блоков. Декомпозиция этих Блоков позволяет достигать требуемого уровня детализации описания системы.

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

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

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

Хотя вершиной модели является Диаграмма уровня А-0, настоящей «рабочей вершиной или структурой» является Диаграмма А0, поскольку она является уточненным выражением точки зрения модели. Ее содержание показывает, что будет рассматриваться в дальнейшем, ограничивая последующие уровни в рамках цели проекта. Нижние уровни уточняют содержание функциональных Блоков, детализируя их, но, не расширяя границ модели.

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

Основными элементами на IDEF0 Диаграммах являются Блоки и Дуги.

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

глагол + объект действия + [дополнение].

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

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

Место соединения дуги с блоком определяет тип интерфейса.

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

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

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

За каждой Дугой закрепляется Замечание, которое отображает суть информации или объекта. Замечание формулируется в виде оборота существительного, отвечающего на вопрос: «Что?».

Рис. — Дуги, как ограничивающие и уточняющие факторы Блока

Рис. — Пример А0 диаграммы

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

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

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

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

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

Дуги на IDEF0 Диаграмме изображаются в виде стрелок.

При IDEF0 моделировании используются пять типов взаимосвязей между Блоками, для описания их отношений.

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

Рис. — Взаимосвязь по управлению

Взаимосвязь по входу, — когда выход одного Блока является входом для другого.

Рис. — Взаимосвязь по входу

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

Рис. — Обратная связь по управлению

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

Рис. — Обратная связь по входу

Взаимосвязь «выход-механизм», — когда выход одной функции является механизмом для другой. Иначе говоря, выходная Дуга одного Блока является Дугой механизма для другого. Такой тип связи встречается редко и относится чаще всего к подготовительным операциям.

Рис. — Взаимосвязь «выход-механизм»

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

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

Рис. — Диаграмма верхнего уровня А-0, отражающая целевую функцию системы

Рис. — Диаграмма А0, отражающая декомпозицию целевой функции на основные функции А1, А2, А3

Источник