Нотации и методологии (IDEF0, UML, BPMN). Часть 1: поверхностное знакомство

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

Если обрисовывать простыми словами, то Системный аналитик - это некоторый посредник между клиентом и командной программистов. Он выполняет роль не только связующего звена. В его обязанности зачастую входит написание технического задания (ТЗ). Описание бизнес требований (БТ) и функциональных требований (ФТ). Тестировка готового софта, коммуникации с заказчиком. Как вы уже поняли, это востребованная позиция в компаниях создающих ПО. Если посмотреть на рынок, то средняя ЗП по Москве, если имеется опыт работы 1 года более 100 тыс. рублей. Разместив свое резюме, даже без опыта, я получил порядка 100 просмотров. и 5 приглашений на собеседования. Но не стоит обольщаться, это лишь на первый взгляд все хорошо. Отбор достаточно жесткий, из-за отсутствия на рынке экспертов с опытом, работодатели вынуждены искать кандидатов с минимальными знаниями.

Рассмотрев основные обязанности Системного аналитика выше, можем подробнее остановиться на некоторых моментах. Для написания ТЗ используются классические шаблоны, создаваемые компанией, по которым работает Системный аналитик или ГОСТ 34 и др. Для описания БТ и ФТ требуются знания моделирования бизнес процессов. Стадия описания на рисунке.
Вот тут и всплывают пугающих многих понятия нотация и методология.

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

Это проясняет понимание того, что содержится в UML, BPMN, ARIS, IDEF0 и IDEF3. А точнее это каким образом мы обозначаем (Например в BPMN: событие - это кружок, стрелка это поток, может быть поток сообщения, управления и другое) то или иное действие, обьект и прочее. Методология в данном случае, то какие принципы построения (пример - абстрактный: сначала рисуются обьекты, потом выстраиваются связи, далее отношения между обьектами, выбор ответственных лиц, то есть порядок действий).

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