5 Комментариев к записи “Как разработать Техническое задание. Часть 2. Виды работ при сборе требований к системе учета и информации для описания бизнес-процессов.”
Борис
Александрович:
11.04.2012 в 3:22 пп
Жаль, что используете нотацию EPS. Её, по сути дела, кроме SAP AG никто и не поддерживает. Правда, к ней близка нотация BPMN. Медотология SADT (IDEF x) намного лучше описывает технологические процессы.
Ответить
chavalah:
12.04.2012 в 12:16 пп
Почему «жаль?». Это очень практичная нотация. Она проще понимается обычными менеджерами, легко адаптируется под специфичные требования, быстро строятся диаграммы. Что конкретно она не позволяет Вам отобразить?
Ответить
andr:
12.04.2012 в 3:35 пп
В SADT-технологии в стандарте IDEF 0 отражаются потоки данных (информационных и материальных данных). Там много так называемого потенциального (естественного) параллелизма, который не всегда практически реализуется. Поэтому был введен стандарт IDEF 3, который позволяет строго огворить необходиммый последовательный и параллельный порядок выполнения действий (поток управления). В нотациях Приложения 1 и Приложения 2 кажется просматриваются элементы паралелизма (или есть такая возможность). 1) Действительно это так? 2) Где можно ознакомиться с описаниеями этих двух нотаций?
Ответить
chavalah:
13.04.2012 в 3:41 пп
В приложении 1 приведен пример описания в нотации eEPC. Это очень популярная нотация, ознакомиться с ней можно просто набрав «нотация EPC» в любом поисковике. Например, вот http://www.interface.ru/home.asp?artId=4269 неплохая статья на эту тему. По сути у IDEF 3 и EPC одно назначение, т.е цели их разработки были одинаковые. Мне больше нравится EPC, т.к. она не ограничена жесткими требованиями и позволяет вводить свои элементы. Подробнее на эту тему я планирую сделать отдельный выпуск. Если говорить о «паралелизме», действительно это возможно.
В приложении 2 используется не нотация. Можно, конечно, так ее назвать, но это не является каким-то общеизвестным инструментом. Там приведен пример диаграммы использования программного продукта. Обычно такие схемы рисуют так, как удобно в конкретном случае, т.е. сами специалисты определяют эти правила. Хотя, существуют и нотации для тех же целей. Например, UML схема «Use case» так и называется «диаграмма использования». В данном примере приведена схема из реального проекта на платформе 1С. Там отображены конкретные объекты конфигурации: справочники, документы и пр и как они в предположении будут использоваться. Конкретно этот способ был придуман мной. Очень удобно.