Приключения электроника: Разработка ПО (часть 3 – Нотации)
Сегодня существует ряд подходов и стандартов, описывающих бизнес-процессы. Каждым из этих методов пользователю предлагается возможность знакомства с объектами реального мира с помощью определенного языка описания (специально разработанного синтаксиса). Выбор наиболее подходящего метода зависит от конкретной цели создания модели.
Синтаксис (язык) и правила его применения и называются нотациями. Я предлагаю рассмотреть самые распространенные из них.
Будут упомянуты не все нотации, так как пост не имеет цели рассмотреть историю их возникновения и развития.
Для начала стоит четко разграничить понятия нотация, методология, стандарт и средства реализации (CASE-средства).
Данная таблица внесет ясность:
IDEFсемейство
Семейство представлено нотациями:
IDEF0 – для моделирования потоков данных (модель управления);
IDEF3 – для моделирования потоков работ (детализация);
IDEF1x – для проектированияреляционных моделей.
Суть нотации IDEF0 сводится к описанию процесса в виде входа, преобразования и выхода.
Вот так выглядит схема, выполненная в этой нотации:
схема была выполнена мной для защиты дипломной работы
У этих нотаций достаточно много преимуществ. Но основным можно считать декомпозицию.
Декомпозицией называют прием, при помощи которого сложную схему можно представить как более простые взаимосвязанные, вложенные системы. Благодаря такой форме представления, можно анализировать процесс, исключая элементы, лишние для задачи.
Но есть один существенный минус, который перевешивает все плюсы, – это окаменевшая нотация. Она давно не совершенствуется и в связи с этим безнадежно устарела. Ею можно по-прежнему пользоваться, но это нецелесообразно, т.к. есть более новые и совершенные нотации.
eEPC
ARIS. Разработанная в конце 90-х, она стала первой нотацией, основанной на процессном подходе к организации. Ее модели были уже более понятны людям, не связанным с разработкой (например, руководителям). Возможно, именно это и сделало ее популярной в России.
Методология ARIS представляет организацию в виде графических структур:
- организационной;
- функциональной;
- потока данных;
- потока процессов.
При выборе нотации важно помнить, что мало сделать хорошее описание бизнес-процесса, нужно, чтобы его смогли прочесть и понять те, кто будут участвовать во внедрении. И если язык описания известен только одному специалисту, то смысла в таком описании немного. Поэтому предпочтение стоит отдать тому методу, который более широко известен, либо тому, описание которого интуитивно понятно.
Важно также помнить, что описание не является конечным продуктом, это не более чем удобный инструмент. Конечная же цель – оптимизация бизнес-процессов.
Но какой бы ни была выбрана нотация, важнейшим этапом разработки ПО является сбор и обработка информации. Информация эта поступает от участников бизнес-процессов. При этом участники сообщают информацию в виде своего субъективного мнения.
Умение оценить степень субъективности, грамотно проанализировать полученные данные и обнаружить проблему – это то, чем занимается разработчик 75-80% времени.
Вот об этом мы и поговорим в следующий раз…
Посты этой рубрики:
Разработка ПО часть 2 – Методы описания
Разработка ПО часть 1