Nikita_90Уважаемые знатоки, помогите разобраться! Руководство готово закупить несколько лицензий какого-нибудь CASE-средства и меня озадачили выбором самого подходящего. В основном у нас используется UML, но в некоторых проектах встречаются BPMN, ER-диаграммы и даже IDEF0. Желательно выбрать продукт, который поддерживает большинство из этих нотаций (Visio не предлагать :) )


Вывод. Если Вам нужен UML и еще немного всякого разного при ограниченном бюджете, то смотрите ARIS.

Пояснение:

ERWin (IDEF1X есть, есть и прочие вариации на тему IDEF, а вот UML ТОЧНО НЕТ),
Rational Suite (по-моему, только UML),
ARIS (UML есть точно, ERM, DFD был какой-то кривой лет 8 назад, но я последний раз ARIS видел N лет назад).

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

По факту 95% я рисую в BPMN c помощью Visio, 5% составляет просмотр и правка (преимущественно) вариаций на тему IDEF в технической документации.

Причины такие:
1. Результат (за исключением попсового BPMN) может прочитать только человек, который знает нотацию. Большая часть разработчиков и высоких руководителей с нотациями не знакомы. Смысл? Сначала тратить время, чтобы нарисовать, потом, чтобы объяснить смысл нарисованного? Плюс BPMN типа стандарт во многих крупных конторах (в BRD). Просто и сердито, в чем можно разобраться за полчаса.

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

3. Трудоемкость правки кода, который генерят кейс инструменты, до вменяемого состояния занимает больше времени, чем написание его с нуля. Мой опыт показывает, что с автогенерацией бесполезно работать даже в случае с продвинутыми ETL-машинами (которые решают куда более узкие задачи, и в которых этому вопросу уделяется куда больше внимания).

4. Функционально стоимостный анализ можно делать и в Excel. Проблема обычно не в инструменте, а в отсуствии ключевых данных для такого анализа (о причинах сего феномена я могу трактат написать). И в трудоемкости детального описания (см. выше). А по порядку величины я затраты проекта на листке бумаги оценить могу. После анкетирования и сайзинга и обсуждения BFRD c парой подрядчиков, обычно в этой оценке оказывается верной и первая значащая цифра. В теории это могло бы пригодиться для оптимизации бизнеса, но в России его состояние таково (с точки зрения зрелости процессов), что обычно достаточно просто здравого смысла и нет никакого смысла искать какую-то мелочевку, которая улучшит показатели на 2%, когда из-за явных косяков бизнес на десятки процентов проседает.

LSVВсе сабжевые средства - баловство для попила бюджета. :)

Нужной гибкости все равно не будет.
Рисуйте IDEF0 хоть в ВОРДе (я так и делал). По крайней мере можно кому-то отправить и показать. :)

+1. В конце 90-х это было просто модно. Потом бизнес нажрался этой... моды до отвала и энтузиазм быстро угас. Изучение нотаций мозг немного дисциплинирует, если Вы занимаетесь оптимизацией процессов, но ИМХО для оптимизации бизнеса нужно хорошее знание предметной области, а не нотаций. Плюс опыт и умение общаться с людьми. Рисование схемок полезно, когда ты в самом начале пытаешься понять, как все это должно работать и не более того. Что можно сделать и что делать точно не надо, как должны быть организованы потоки данных или материальных ценностей, где возможны узкие места. BPMN или даже его упрощенных вариантов для этого достаточно. Но это должен делать кто-то, кто хорошо знает бизнес конкретно этой компании и кому доверяют. Те, кто отвечает на вопросы, и высшее руководство. Иначе этой схемой потом можно только подтереться, если речь не идет о какой-то тривиально задаче, где вся эта возня со схемами нафиг не нужна.

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