676

Конференции Семинары и Тренинги / Re: Семинар по прецедентам - Подготовка

« : 06 Июня 2007, 11:52:12 »

Ориентир по дате - последняя неделя июня.

Вот по дате нужно будет согласовать отдельно ...

677

Сообщество Аналитиков / Re: Присоединение к Сообществу Аналитиков России

« : 05 Июня 2007, 17:03:24 »

http://ignatovaolga.moikrug.ru/

1. Цели - расти в профессиональном плане
2. Помощь - чем смогу, помогу. Могу поделиться материалами, мыслями, проблемами и их решениями

Все-таки тут (http://www.uml2.ru/forum/index.php?topic=225.msg2147#msg2147), я угадал ваше место работы :-) ... кто ж еще в России станет пользоваться такими экзотическими методологиями.

678

Системный Анализ и Требования / Re: Как выявить способности к аналитической деятельности

« : 05 Июня 2007, 16:51:17 »

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

На самом деле можно подойти очень даже просто. Это как вопросы для самоконтроля в учебниках :-). Просто их цель -- акцентировать внимание на действительно важных вещах.

679

Системный Анализ и Требования / Re: Как выявить способности к аналитической деятельности

« : 04 Июня 2007, 23:48:46 »

Хм ... вобщем англоязычные тесты я действительно видел ... . И вобщем-то тесты не столько на аналитические способности, сколько направленные на выявление усвоения материалов тренингов по теме Разработка и управление требованиями.

680

Консалтинг и Внедрение / Re: Проблемы консалтинга "по-русски"

« : 03 Июня 2007, 16:35:10 »

Есть еще вариант - не приглашение независимого от вендора консультанта (вопрос его компетенции в системе, как заметил Денис, весьма сомнителен), а работа с консультантом, обладающий экспертизой во всех основных ERP.

1. Совершенно не понятно почему ставится абсолютный знак равенства между наведением порядка в управленческом учете и внедрением SA/OBS/...?
2. Для начала его, порядок, нужно просто навести. Если наводить его ПУТЕМ внедрения ERP, то это, пардон, как правило скачок через 2 уровня зрелости, что приводит к практически к 70% вероятности неудачи, о чем, в компаниях занимающихся внедрением ERP прекрасно осведомлены.
3. Отсюда вывод -- чтобы умменьшить риски, связанные с перестройкой системы управления, нужно "есть слона по-кусочку". Для начала построить модель управленческого учета, которая будет подходить для данного предприятия. Я видел такие модели и в Excel, и именно на этих прототипах отрабатывются основные риски. Потом, когда организация более четко понимает. что ей таки нужно -- будет более осмысленно подходить к выбору ERP. Я говорил именно про это, и то, что такие модели успешно делают и компании не связанные с производителями ERP. И они же формируют основные требования к ERP, уже зная специфику предприятия и оценивая риски.

Например, мы  (GMCS) - партнеры всех 4 основных вендоров ERP - SAP, Oracle, Microsoft, BAAN (SSA). У нас практикуются проекты по консалтингу БП и выбору системы, в которых участвуют специалисты всех 4 практик. Таким образом, повышается вероятность оптимального выбора системы.

А вот и не повышается, все равно впариваете то что больше денег принесет вам, а аргументы они всегда есть -- либо заказчик не зрелый и слушает вас, либо .. сами знаете что. ... Да и не только вы одни такие ... те же БДО тоже всех вендоров окучивают, вот и IBS туда же метит, хотя им даже до БДО далеко. Проблема в том, что все равно как правило нет одной головы в которой все эти 4 системы сидят или другая вещь ... все эти 4 системы кастомизируемы и в принципе любая прокатит :-).

Интерес клиента в том, что он получает независимый консалтинг по выбору системы, а наш интерес в том, что при выборе любой из систем, велика вероятность, что проект по внедрению останется за нами

Консалтинг по выбору системы то он может и получает, а вот постановку управленического учета, и как результат решение основных проблем -- не факт :-).

681

Системный Анализ и Требования / Re: комиксы как инструмент иллюстрации требований?

« : 03 Июня 2007, 15:43:03 »

Я же пишу - типичные артефакты не задают контекста использования. Из скриншотов не очевидны эргономические требования. Если человек работает с формой, тут у него заплакал ребёнок, он отошёл и вернулся через 15 минут, а система ему - говорит - "ваша сессия закончилась, введите данные заново", то такие исключительные ситуации гораздо проще выявить через механизм обыгрывания комиксов, чем через шаблон Use-Case.

Скажем так, что те же юзкейсы задают именно контекст использования ... другой вопрос, что они не "заточены" на ДЕТАЛИ юзабилити. Хотя юзабилити в широком смысле они могут учитывать. Другой вопрос, что разрабатывая юзкейс нужно уже четко иметь предстваление о юзабилити -- одно дело коропративная учетная система (на мой взгляд у той же Axaptа юзвабилити не на самом высоком уровне ... и ничего, привыкают работают), другое дело -- когда юзабилити -- один из стратегических факторов успеха продукта/услуги (например какой-нить электронный магазин). Т.к. заполняя форму и отлучась к ребнку увидев что сессия закончена -- не факт что потом придешь в этот эл. магазин еще раз. А операционист в банке -- пока не закончит обслуживать клиента НИКУДА отлучиться не может с раб. места.

682

Системный Анализ и Требования / Re: комиксы как инструмент иллюстрации требований?

« : 03 Июня 2007, 15:34:45 »

Storyboarding он и в Африке storyboarding ... На самом деле совершенно не важно какой мы используем механизм для того чтобы вовлечь заинтересованных лиц в активное обсуждение. Это могут быть обычные карточки, мультики/комиксы, средства проигрывания сценариев типа Borland DefineIT и иже с ними -- когда можно иллюстрировать картинками шаги. Важно одно: а) вовлечь в процесс б) управлять процессом имея внятную цель, чего мы хотим выудить, если это не первая встреча в) не давать увлекаться в ненужные для данного этапа детали (хотя фиксировать для себя интерес к этим деталям следует, для планирования следущих активностей). Реально -- что потом эти мультики/комиксы нужно просто выкидывать и не поддерживать их актуальность, когда мы добъемся понимания чего таки нужно стейкхолдерам, а переходить к спецификациям требований.
Есть другая проблема -- приучив стейкхолдеров к мультикам -- сложно потом заставить их воспринимть что-то другое, те же документы, ибо тут им все разжевали. Тогда придется "ТЗ в картинках" делать :-). Хотя если именно за это готов заплатить заказчик  why not? :-)

683

Книги, статьи и ресурсы / Re: http://softcraft.ru/

« : 27 Мая 2007, 02:03:42 »

Вспоминается то как на SECR 2005 "автоматнки" пытались всем доказать что UML это лажа :-) ... вот народ потешился.
Обратил внимание, что сейчас пошла новая маркетинговая волна ... захожу в магазин, вижу квас и лимонад. Квас -- написано "это тот же квас, который был в старые добрые времена в бочках с надписью КВАС ..", и про лимонад "знакомый с детсва вкус" и ГОСТ прилеплен ... только вот одна незадачка ... у этого лимонада срок хранения 1 год ... а старого советского -- 7 дней был!!!!
Таким образом можно сделать простой вывод ... что отрицание или как минимум некая оппозиция к "новомодным современным веяниям" -- суть такая же МАРКЕТИНГОВАЯ позиция, как и сами эти "веяния" :-) ... со всеми вытекающими.

684

Варианты Использования (Use Case) / Re: Статья: Варианты Использования. Обсуждение.

« : 26 Мая 2007, 00:30:50 »

1 Речь идет не о подмене спецификаций GUI сценариями. Речь идет о сценариях, опирающихся на элементы GUI.

Что очень часто приводит именно к тому, что описываем движение по интерфейсу, вместо движения к цели ... и это увы реальность (часто видел такое). И приводит к усложнению юзкейсов.

Один из тезисов статьи, если я правильно понял,  "чем больше уровень абстракций, тем лучше". Вот с этим я не согласен. Я исхожу из того, что цель аналитика, как и любого другого в команде, быстро и качественно реализовать проект. Если для этого требуется отходить от Коберновских стандартов - это нужно делать.

Невозможно реализовать проект быстро и одновременно качественно в условиях ограниченных ресурсов :-). Можно лишь с заданным уровнем качества. Остается определить каков этот уровень :-). А Коберн не задает стандартов ... он лишь вводит определенные практики написания. И никто не говорит что это истина в последней инстанции. Просто нужно ОЧЕНЬ внимательно изучить его практики и желательно не только по книге а и курс его послушать, если компания конечно оплатит, ибо самому -- очень дорогое удовольствие.

А на счет поддержки таких требований - это опять же по обстоятельствам. Если в проекте три аналитика, то почему бы и нет. К тому же, большой вопрос на что потратишь больше времени: на поддержку детальных требований или на объяснение программистам, как это хотелось бы видеть.

Практика показывает, что даже к не очень простому GUI при наличии хороших тренингов пользователи привыкают достаточно быстро. Вы видили пользовательский интерфейс Axapta? Жуть как все сложно ... а ничего .. работают :-).

Практика показывает, что если ты что-то не прописываешь, то это додумывают за тебя. И обычно это не совпадает с твоим видением.

А что тут можно не дописать, когда речь идет о GUI элементах в юзкейсе? Название кнопки поставят вместо "ОК" -- "Принять изменения", это смертельно и потребует больших усислий по переделке?

2 Согласен - демонстрация картинок это не решение проблем заказчика. Однако, сами понимаете, что большинство ориентируются на визуальную сторону. Так проще, хотя бы, начать разговор.

Ну и дайте им эту визуальную сторону ... storyboarding для этого и существует :-), причем РЯДОМ с юзкейсами а не в самих юзкейсах.

GUI как пример я выбрал, т.к. это самая банальная вещь. Можно привести пример другой ситуации: системе необходимо по запросу пользователя скачать файлы с удаленного сервера и проверить их целостность.

Писать можно и так:
1) Пользователь активирует загрузку
2) Система копирует объекты, взаимодействуя с системой N
3) Система проверяет целостность объектов

Это скорее всего вызовет больше вопросов. Если знаешь, что здесь лучше использовать протокол ftp - пиши ftp. Используй термины вроде "загрузка", "логин", "пароль", "адрес сервера" и всем будет проще.

Для начала Гл. успешный сценарий написан некорректно ... другая система будет как мининмум secondary actor и нужно делать отдельный шаг по взаимодействию с ней. Кроме этого вы НИЧЕГО не сказали о параметрах которые должен указать пользователь при активации загрузки .. посему "Пользователь активирует загрузку" больше тянет на Триггер а в первом шаге нужно указать что пользователь дает системе -- типа указывает URL или еше что-то ... Это действительно будет "абстрактный" юзкейс, если вы не упомяните еще все то о чем сказали в других слотах спецификации юзкейса ... про FTP/HTTP например в слоте Вариации технологий и данных ...
Вобщем пример IMHO либо сильно умышленно утрирован (понятно что для целей демонстрации идеи), либо не очень удачный.
Т.о. то что вы привели как пример не имеет ничего общего с рекомендациями Коберна.
[/quote]

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

Аналитик должен работать в т.ч. по принципу "не навреди" ... ибо то что он напишет может быть воспринять буквально .. что не всегда лучше того, что додумают за него :-).

685

Варианты Использования (Use Case) / Re: Статья: Варианты Использования. Обсуждение.

« : 25 Мая 2007, 01:45:19 »

1. Если писать юзкейсы как описание движения по пользовательскому интерфейсу, то очень скоро они станут а) сложными для восприятия б) их станет много и ими будет тяжело управлять в) вы замучаетесь вносить в них изменения на каждое пожелание заказчика видеть "тут зеленую кнопку, а тут шрифт должен быть 18 кеглем".  Подменяя спецификацию GUI юзкейсами, и пытаясь убить 2 зайцев одним выстрелом вы сами себя загоните в угол тем, что в конечном итоге работы только прибавиться и вы в конце концов плюнете на актуальность этих т.н. "GUI юзкейсов".
2. О la la!!! мотвация включения GUI в описания юзкейсов и в пределе описание движения по интерфейсу по причине того, что зкакзчик мыслит в терминах GUI стоит у меня на первом месте в коллекции причин! Я это слышу в каждой 3-й компании куда прихожу разбираться с практикой работы с требованиями. После того как войдешь в нормальные доверительные отношения со специалистами этой компании, выясняется, что ЭТО ТОЖЕ ТОЛКОМ НЕ ПОМОГАЕТ в решении проблемы "мыслящего в терминах GUI заказчика", т.е. не эффективно. Ибо все равно заказчик будет говорить о юзабилити больше, чем о том как это будет работать :-). И у этой проблемы есть свои очень простые, не требующие серьезных затрат методы решения, которые вполне работоспособны.
3. Да, бывает ситуация, когда нужно идти на некий компромисс ... например жесткие требования заказчика делать именно так -- не вопрос, за его деньги сделаем ему и с включением GUI, мы же прагматики, не так ли :-) ?
А манипулирование уровнем "абстракции" -- это тоже инструмент аналитика между прочим ..., особенно актуально если "в предметке не сечешь" :-) на первых шагах работы с требованиями. Так что не так плох абстракционизм, как его боятся.

686

Бизнес-анализ и Целеполагание / Re: IDEF ( or ARIS) vs Use Cases при описании БП

« : 24 Мая 2007, 16:38:00 »

Если речь идет об оптимизации, то мы как минимум должны говорить о критериях эффективности БП ... это могут быть определенные бизнесовые KPI например. В этом случае, чтобы доказать, что процесс более оптимален -- придется делать его имитационную модель, с тем, чтобы те самые KPI посчитать. А это уже иной уровень, одного описания (сценариев) будет не достаточно, нужны срдества динамического моделирования.
Говоря об аппарате описания БП, то это все-таки классика -- а именно IDEF, который по сути для этого и был создан. Хотя я бы сказал что должен быть документ-спецификация процессов, и как приложение -- диаграммы. В документе как раз и можно отразить те самые KPI и их значения которые будут приемлемы. И еще один момент -- инжиниринг бизнес-процессов -- это тема не совсем ИТ-шная я бы сказал, хотябы потому, что ИТ там выступает как интсрумент ... вместо компьютера вполне могут быть 1000 китайцев :-), которые будут например бегать с бумажками. Другой вопрос -- если "бизнес = ИТ", как то информационные порталы, инет-магазины, услуги по коммуникациям (та же e-mail) и т.п. ... тут составляющая ИТ в бизнесе очень высока, даже я бы сказал критическая. Но KPI процессов все равно бизнесовые будут :-).

687

Бизнес-анализ и Целеполагание / Re: IDEF ( or ARIS) vs Use Cases при описании БП

« : 23 Мая 2007, 23:24:05 »

"Самая короткая дорога та, которую знаешь" (с) ... На самом деле я бы не стал позиционировать юзкейсы какаппарат для описания бизнес-процессов как таковых. А позиционировал бы по-другому -- "можно ли при помощи юзкейсов описать документороот предприятия?" -- ответ -- "да можно" :-). А если ставить вопрос, а можно ли описать вообще бизнес-процессы, то и ответ будет тоже "можно". Другой вопрос для каких целей мы описываем эти самые бизнес-процессы, и какие аспекты БП хотим отразить в описании ...

688

Сообщество Аналитиков / Re: Встреча Сообщества Аналитиков №3

« : 20 Мая 2007, 23:29:40 »

Я могу рассказать про Иркутск, в качестве "наказания" :-) ... даже на Байкал удосужился съездить ... правда пришлось арендовать такси и отдать практически 100$ за поездку. Но зато омуля попробовал. А вообще -- ребята с которыми там общался по делам -- молодцы -- просто взяли и адаптировали RUP под себя, без "пальцев" и не мудурствуя лукаво... Мне они понравились ;-). Может в блоге на МойКруг о впечатлениях напишу ... как только разгребусь немного.

689

Системный Анализ и Требования / Re: Wiki в коллективной разработке требований

« : 18 Мая 2007, 23:58:24 »

Я бы еще разделил на Пользовательские требовния и Функциональные .. по классике ;-)

690

Сообщество Аналитиков / Re: Встреча Сообщества Аналитиков №3

« : 18 Мая 2007, 23:33:36 »

Привет всем ... сорри что я таки не смог прийти -- меня "обложили со всех сторон" -- то в Иркутск летал, то теперь приходится разгребать то, что накопилось за время отсутсвия. Вчера согласовывали с заказчиком до упора консолидированную позицию на 3-х сторонних переговорах (я играю за закачика ;-)) ... а сегодня были собственно эти переговоры, причем о том что они будут именно сегодня, стало понятно только вчера после 17-00 ... так что не взыщите. Приложу все усилия, чтобы таки быть на след. встрече ...