Это

авторВозможность взаимосявзи функциональной и информационной модели. (Можно ли разработав структуру данных и процессы, например в ERWin и BPWin соответственно, связать их модели в одну, т.е. чтобы данные из структуры использовались в процессе).

с этиим

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

не соотносится, т.к. требование к инструментарию.

IDEF по воспоминаниям изучения в институте содержит в себе рекомендации к построению диаграмм. Как и что за чем следует - такого нет. Не знаю какие типы диаграмм существуют в IDEF 3, но в IDEF 0 вроде как 1 тип диаграммы, что явно не раскроет суть дела. Стандарт правда не для разработки бизнес модели, для этого IDEF 3, если я не ошибаюсь

ARIS считается нотацией для моделирования бизнеса с целью дальнейшего внедрения на основе модели готового приложения. Есть нотация последовательности моделирования и т.п.

RUP нотация служит для построения модели чего угодно от бизнеса до работы платежного терминала. Язык развит - диаграмм достаточно для построения любой модели любой области деятельности. Нотация в чем схожа с ARIS, но служит для разработки программных средств, а не их внедрения.

Это в кратце.

Если вы выбираете методологию - необходимо знать что вы предполагете моделировать. К примеру интрукции пользователя можно смоделировать автоматически из какой то нотации IDEF или составить диаграммы на основе которых IT может понимать бизнес (или ещё что). Если вы планируете приобрести готовое решение и не знаете толком как его потом "есть" - это ARIS, AIM. Если вы планируете затевать процессы разработки собственными силами - RUP.

byur, методология, не нотация, не то понаписал я. Читающим рефрешить мою писанину корректируя с замечанием товарища byur Сорри.

Товарищ Kosteles, я никуя не понял последнее ваше выступление, если честно. По IBM Rational Suite можно сходить на interface. Данный пакет применим для полного цикла разработки. По IDEFXX и прочей хрени и правилам построения моделей я не шарю, мне по уши хватает UML диаграмм.
Критерии обзора я не понял. Этап планирования - часть фазы проекта. Есть другие итерации: анализ, управление требованиями, построение, разработка, слив данных, обучение и т.д. Планирование тут может даже и не участвовать, т.к. управление проектом и управление внедрением готового приложения по оракловым методологиям вообще 2 разные вещи: AIM, PJM. В Rational Unificated Process я не помню шага чтобы "планирование и определение рамок проекта". Ваша кафедра ведь выпустила свое видение применимо к чему-то? Резюм: не знаю как кафедра, но я разделяю управление проектом (аплицируемо к обоим последующим видам), управление внедрением (приобретенный продукт и вендер) и управление разработкой (все сами - делфи форева и ниеб-т). Тогда можно и об инструментах поговорить.

авторЯ рассматриваю управление проектом ТОЛЬКО для процесса моделирования ПО.


Вот мое видение данного действа по ролям:

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

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

автор... Все собрали, выкатили заказчику - тот в ужасе, волосы на попе дыбом: Что это за говно ???!!!

Товарищ, ретивым мэнам приобретаются бритвы. Баблоиды не глупые люди, все всё понимают. Никто никого гасить не будет - отношения прозрачны.