Проектирование информационных систем и IDEF0

Большинство публикаций посвященных проектированию автоматизированных информационных систем много внимания уделяют методологии IDEF0, говоря о том что  IDEF0 есть основа проекта, так сказать укрупненная блок-схема будущей системы. Однако, за время изучения дисциплины проектирование информационных систем, а также за время ее преподавания сложилось четкое мнение, что, грубо говоря, IDEF0 "за уши притянуто" к созданию ИС. Многие утверждают, что описывать будущую систему следует используя эту методологию, это в последствии поможет избежать различных трудностей. На самом же деле, часто сначала создается концепция ИС или даже рабочая система, и лишь потом ее пытаются описать с помощью IDEF0, что в свою очередь только увеличивает трудозатраты на весь проект. Конечно же я нисколько не умаляю достоинств данной методологии, она необходима и при проектировании ИС в том числе, но только на начальных этапах. С помощью IDEF0 следует описывать предметную область, а также проблемы в существующей модели бизнес-процессов и варианты решения данной проблемы за счет реинжениринга и автоматизации некоторых процессов; описывать контекст будущей системы, но не ее функционирование. Таким образов, как мне кажется, проектирование информационных систем должно содержать следующие этапы:

• исследование предметной области:
• описание существующих бизнес-процессов (IDEF0);
• выявление недостатков и проблемных мест;
• реинжениринг (по возможности и по необходимости)(результат в IDEF0);
• выявление процессов подлежащих автоматизации;
• описание будущей АИС (не IDEF0).

Возникают следующие вопросы: почему не следует описывать систему с помощью IDEF0? какие средства использовать для проектирования? То что касается первого вопроса можно однозначно сказать, что средства IDEF0 для данной проблемы чрезвычайно ограничены, кроме того такие обязательные объекты методологии (о них многие забывают) как цель моделирования и точка зрения вообще не позволяют однозначно описать будущую систему. То что касается второго вопроса здесь следуют обращать внимание на несколько показателей, в том числе на сложность системы и на непосредственно аналитика, который занимается проектирование. Если система достаточно простая вполне возможно обойтись для программной части нотацией BPMN, если система сложная  придется воспользоваться более мощным средством, например UML. Опять же обращаясь к учебникам видим: для структурного проектирования следует использовать SADT, для объектно-ориентированного UML. Мне же кажется что именно для описания предметной области следует использовать IDEF0, а UML как вариант средства для описания будущей АИС, но никак не заставлять делать выбор между ними.