2356

Конференции Семинары и Тренинги / Re: [Скайп-тренинги] Моделирование на UML

« : 03 Февраля 2009, 17:40:21 »

А сколько народу было??

2357

Примеры / Re: EA - описание среды с примером

« : 03 Февраля 2009, 14:23:31 »

Ирр,

Как скажите, если Вас двоих это устраивает, тогда вперед. Но думаю я еще внесу свои 5 копеек

2358

Примеры / Re: EA - описание среды с примером

« : 03 Февраля 2009, 12:47:02 »

Может Вас перенести в раздел Примеры?

2359

Примеры / Re: EA - описание среды с примером

« : 03 Февраля 2009, 12:45:19 »

Отличия БВИ и СВИ в первую очередь в смысле, а потом уже в изображении на Д:
http://www.uml2.ru/index.php?option=com_content&task=view&id=75&Itemid=47

Посмотрите еще выполнение примера по изображению ДВИ:
http://www.uml2.ru/forum/index.php?topic=286.0

2360

Конференции Семинары и Тренинги / Re: [Скайп-тренинги] Моделирование на UML

« : 03 Февраля 2009, 12:16:05 »

Денис,

Как кстати прошел первый скайп-семинар?

2361

Примеры / Re: Выполнение примера описания требований для ИС "Аттестации Студентов"

« : 03 Февраля 2009, 10:58:37 »

Коллеги,

Если никто не против, то девушки в соседней ветке будут формировать модель нашего текстового описания требований к ИС "Аттестация студентов".
Пока мне не совсем понятно какие модели они будут использовать, но звучит хорошо

З.Ы. сегодня-завтра посмотрю описание ЗЛ, Проблем и Целей и можно двигаться дальше.

З.З.Ы. Эд, нужно бы ответить на вопросы Аналитиков!

2362

Работа / Re: Изменения рынка труда за 2008

« : 03 Февраля 2009, 10:41:20 »

Ну еще немного о позитиве... Даже если кризис будет 1-2 года, то к лету уже народ устанет ныть и начнет зарабатывать, крутиться, и всем станет полегче

2363

Примеры / Re: EA - описание среды с примером

« : 02 Февраля 2009, 23:29:02 »

а можно я предложу набор ЮМЛ Диаграмм для проекта ИС "Аттестация студентов"?

2364

UML SysML и пр. / Re: Как проверить свои знания по UML?

« : 02 Февраля 2009, 16:25:19 »

посмотрите внимательно эту тему:
http://www.uml2.ru/forum/index.php?topic=198.msg10541#msg10541

2365

ПО Аналитика / Re: ORACLE BPM

« : 02 Февраля 2009, 15:37:34 »

Ну это я данную тему поместил в раздел CASE средств. Нужно видимо расширять уже тематику данного раздела в "Средства поддержки разработки ПО" или "Инструменты Аналитика"

2366

Примеры / Re: EA - описание среды с примером

« : 02 Февраля 2009, 14:59:11 »

В поставке ЕА (если мы говорим о Sparx ЕА) есть пример полноценной модели. Файл называется EAExample.eap

2367

Конференции Семинары и Тренинги / Re: [Подготовка] к семинару "Альтернативные инструменты Управления Требованиями"

« : 02 Февраля 2009, 12:09:21 »

Стас описал ценовую политику покупки\внедрения LUXProject'а:
http://sepg.livejournal.com/21969.html

2368

Управление Проектом / Re: Управление изменениями в реальной практике

« : 29 Января 2009, 18:35:35 »

Как я понял, наиболее массово-распространенный способ управления изменениями выглядит примерно так, как описал bas:

требования попадают в единый реестр ... их можно приоритизировать и делать наиболее важные

Я ничего против такого подхода не имею, сам так делал много раз. Но для него имхо ни чейндж-реквесты, ни анализ влияния (в терминах сроков/стоимости) не нужны.

Сорри, я описался. Имел в виду не "требования", а "запросы на изменение", т.е. чендж реквесты. Ну как ты тогда себе представляешь процесс управления изменениями без Запросов на изменение??
А Анализ влияния может быть выполнен не обязательно с помощью супер модных СУТ, УП и т.д., а с помощью воспаленного мозга Аналитика, Разработчика и Тестировщика. Т.е. определить хоть примерно - время доработки и следовательно стоимость. Потом приоритезировать все эти Запросы ВМЕСТЕ с Заказчиком и понять - что даст наибольший эффект с минимум затрат.

Открытый вопрос у меня остается - определение важности или нужности изменения. А точнее, согласование этого параметра с заказчиком. С тем, что "надо делать важный функционал, не отвлекаясь на бантики", никто не будет спорить. Но вот что считать "важным фунционалом", а что "бантиком" - вопрос совершенно неоднозначный. Может быть, то, что аналитик проекта считает "придурью заказчика" ("бантик однозначно") как раз и является для заказчика солью проекта, а важный, с точки зрения аналитика, функционал как раз не представляет для заказчика особой ценности?

Конечной последней инстанцией в определении именно важности не может быть ни Аналитик ни МП со стороны Исполнителя (как внутреннего так и внешнего), а должен быть ИМЕННО Заказчик! А вот уже Аналитику нужно понять - почему этот Запрос на изменение важен Заказчику с помощью последнего. Если Аналитик не понимает - значит либо он дурак, либо Запрос действительно не очень важный и тогда надо говорить с людьми принимающими решение. Если последние говорят, что это важно, то все-таки Аналитик дурак (если Заказчик адекватный), п.ч. он не понимает действительных потребностей Заказчика. Тут же опять встает вопрос о качественной проработке Проблем Заказчика, путей их решения и вообще Целей разработки, т.е. Концепции ПО. Если на этом этапе схалтурили, то "убийственных" требований не избежать. Опять же итеративность разработки нам поможет: сделали часть - сразу показали, если что-то не так, то можем изменить курс.
Если же мы говорим о подряде, то во-первых всегда закладывается определеный бюджет на такого рода Риски, а во вторых нужно тут уже договариваться с Заказчиком и желательно заранее о разделении рисков\стоимости Разработки м\у Заказчиком и Исполнителем.
Т.е. в определении важности\нужности изменений складывается не только из одного фактора, он многогранен (ошибки Исполнителей, ошибки Заказчиков, внешние влияния и т.д.). И серебренной пули здесь нет.

З.Ы. надеюсь понял вопрос

2369

Обучение / Re: Журнал для аналитиков "AnalyzeIT"

« : 29 Января 2009, 15:45:49 »

Виталий,

Еще раз хочу сказать, что эта идея просто супер и этого нам (ресурсу) очень не хватало.
Возможно потом он вырастит в полноценный журнал по всей России

Приглашаем всех желающий для участия в выпуске этого журнала.

Еще раз повоторю свое пожелание - было бы супер еще переводить англоязычные статьи и там публиковать!

2370

Управление Проектом / Re: Управление изменениями в реальной практике

« : 29 Января 2009, 15:40:40 »

Михаил,

Очень нужный и своевременный вопрос. Как раз сегодня про него рассказывал ...
Действительно, если гуру Анализа говорят, что изменения неизбежны (и это в т.ч. индикатор вовлеченности и заинтересованности ЗЛ) и что нельзя сильно сопротивляться им, то зачем ими управлять!?

А вот зачем (+ к Виталию):
1. Если требования попадают в единый реестр, то их можно приоритизировать и делать наиболее важные, НЕ забывая об остальных. В этом случае легче разговаривать с Заказчиком и говорить ему, что мы ничего не забываем, а делаем сейчас наиболее важные, потом займемся и остальными. А остальные со временем могут сами отмереть или станут не такие важные как при звонке
2. Позволяет глубже проанализировать проблему, а не сразу реализовывать ее. Бывали случаи, что нужно внести изменения в отчет, а этот отчет использовался только для формирования другого, так не лучше убрать вообще первичный отчет и сразу формировать второй?!
3. Не хвататься сразу за реализацию, а накопить их и делать их скопом для одного куска и делать, так дешевле
4. Разговаривать с Заказчиком об разделении рисков между Разработчиком и Заказчиком, например 50% на 50% при появлении новых требований и возможно убедить Заказчика заплатить за фичи не входящие в скоуп. Это еще вопрос к хорошей проработке Концепции.
5. Позволяет провести Анализ ошибок, кто виноват - Аналитик, что не выявил требования или Пользователь, который хочет совершенно новую фичу. Может пересмотреть квалификацию Аналитика.
6. Если одно и тоже требования часто меняется, то есть смысл задуматься - а в чем проблема, Аналитик дурак или у Заказчика бардак (не устоялся БП), а как известно автоматизация бардака - это автоматизированный бардак. Может отложить это требование?!
7. Изменять первичные требования, а не иметь кучу ченьж реквестов и не понятно что же должна делать ИС
8. Оповещать всех участников проекта об изменении
9. Не делать одно и тоже  (например от разных Пользователей) - дважды.
10. А если у нас идет разработка коробочного ПО и оно еще кастомизируется (дорабатывается) под каждого конкретного Клиента, то все вышеперечисленные проблемы можно умножить на 10

З.Ы. У меня в практике был известен случай когда два программиста делали один и тот же (похожие) запрос на изменение и почему-то в разных кусках ИС