16

Примеры / Re: Модель прецедентов использования - практический вопрос

« : 09 Апреля 2012, 11:43:59 »

Предлагаю свой вариант.
1. все описанное вами, т.е. создание, просмотр, редактирование и удаление принято собирать в так называемый CRUD Use Case (Create, Read, Update, Delete);
2. очевидно, что есть несколько актеров, которые используют один и тот же функционал (вопрос полномочий оставляем за рамками UC. Это можно описать в предусловиях, в БП, и т.д. К самим шагам UC это уже не относится - UC уже работает);
3. логично было бы создать один UC, содержащий описание всех основных, описанных выше, операций и ассоциировать этот UC с двумя актерами ("Автор трансляции" и "Модератор"). Это абсолютно нормальная ситуация - назначать одному UC несколько актеров. Это означает лишь то, что в выполнении данной задачи заинтересованы несколько актеров; 
4. поскольку модератор имеет возможность делать все то же самое, что и Автор трансляции, за исключением только одной операции - создания трансляции, то логично создать общий CRUD UC, в котором действия по созданию трансляции будут описаны с необходимой детальностью. Все остальные действия по редактированию и удалению трансляции в данном UC описаны одним шагом и являются по сути ссылкой на второй UC. Второй UC детально описывает шаги по редактированию и удалению трансляции. Данная связь между UC будет <include>;
5. Актером первого наиболее полного UC является Автор трансляции. Актером второго - Модератор.
6. Что касается опасений, что один UС содержит сразу несколько равноправных операций (по созданию, удалению, редактированию...), которые не обязательно будут выполняться все и последовательно, или предположений, что первый (более общий UC) не отработает, пока "обязательно!" не отработает второй, то это вопрос написания самого  UC. Есть несколько общепринятых приемов для решения такой проблемы, в частности написания CRUD UC. Не буду здесь грузить. Будет интересно - пишите в личку.
Картинку прилагать не буду - она простая.
Еще рекомендация: не используйте термин "прецедент". Это просто неверный перевод термина USE CASE. И уже очень давно не используется.
Удачи!

17

Вакансии / Re: Ищем системного аналитика на разовую(пока что) работу

« : 06 Апреля 2012, 23:35:48 »

написал в личку

18

Обучение / Re: BABOK Study Group в Киеве

« : 03 Апреля 2012, 21:21:48 »

Добрый день.
Молодцы, что создали свой чаптер, молодцы, что начали обучение, молодцы, что движетесь к сертификации ваших участников.
В рамках Учебного Центра Люксофт разработан первый курс из цикла курсов, рассматривающих BABOK. Курс прошел пилотное прочтение. Отзывы, с учетом замечаний, положительные (http://www.uml2.ru/forum/index.php?topic=4624.0). Мы готовы к сотрудничеству с вами, готовы делиться опытом, обсуждать вопросы освещения BABOK.
Я посмотрел вашу презентацию (ссылка в вашем посте). Там говорится о начале перевода BABOK. Если я правильно понял, перевод планируется начать с перевода глоссария. Если речь идет о переводе на русский язык, то работа по переводу глоссария на русский уже проведена членами сообщества UML2 (http://lib.uml2.ru/%D0%9F%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B5_%D0%90._%D0%93%D0%BB%D0%BE%D1%81%D1%81%D0%B0%D1%80%D0%B8%D0%B9). Сейчас идет неспешный ( ) процесс обсуждения переводов. Если вам это интересно, присоединяйтесь к этой работе.

19

Примеры / Re: Robustness Diagramm - Диаграмма пригодности(ICONIX)

« : 07 Марта 2012, 11:41:35 »

Use Case Driven Object Modeling with UML: Theory and Practice, by  Doug Rosenberg and Matt Stephens
http://iiba.books24x7.com/toc.aspx?bookid=34073

20

Обучение / Re: Курс по BABOK v 2.0 на русском

« : 17 Февраля 2012, 12:02:17 »

Денис, спасибо за отклик.

1. Кто разработал курс?

Курс разработал я.

2. Кто ведёт?

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

3. Почему 16 часов (2 рабочих дня) названы курсом?

Курс будет читаться 4 дня по 4 часа. Это максимум на что мне удалось уговорить руководство УЦ. Хотя, я по прежнему считаю, что это мало.  В любом сдучае, пилотное чтение покажет. Я думаю, что после прочтения можно будет изменить как продолжительность, так и подправить содержание.

4. Какая в курсе практическая составляющая?
Показывать и рассказывать метамодели из книжки мы все умеем.
Чему реально научатся люди?

В практическую составляющую я включил разбор почти всех техник, которые упоминаются в BABOK в данной Knowledge Area. Мы разработаем все основные артефакты: "план бизнес анализа", "список заинтересованных лиц, их обязанности и полномочия" и т.д. В качестве примеров я буду использовать реальные документы, разработанные во время последней командировки к заказчику в конце прошлого года.
Что касается "метамоделей", то сами по себе они не очень информативны. Дополнительно к ним я разработал модели структуры рассматриваемых элементов. Для большей наглядности они разработаны в виде Mind Map - этот формат очень подходит для изображения сложных структур. Кроме этого, я использовал графические модели, купленные мною у Aotea  (http://aoteastudios.com/products/business-analysis/)
Вообще, содержание курса - это не просто прямой перевод BABOK, слава богу у наших аналитиков с английским все в порядке. Я использовал достаточно большое количество дополнительной литературы (только список этой литературы в презентации занимает три слайда). Одним из основных источников была замечательная книга Susan Weese, Terri Wagner, CBAP/CCBA certified Business Analysis, Study Guide  - своего рода "катехизис" по BABOK, одно из лучших руководств по подготовке к сдаче сертификационного экзамена

5. Выпускник курса будет уметь создавать план аналитических работ с детальностью разбиения задач не более 4 часов и с точностью исполнения своими силами +-20% отклонений по времени?

В УЦ существуют две категории курсов: Теоретические (с практическиими занятиями) и Мастер Классы. Вторая категрия - это чисто практические курсы, которые обычно проводятся после прохождения теоретического курса, поскольку теория уже не читается, люди занимаются только практическими вещами. Курс, о котором мы сейчас говорим - это теоретический курс. Его цель - подробно ознакомиться с темой, некоторые принципиальные моменты попробовать практически. Более глубокая практика - это на практическом курсе. Будет этот курс или нет, зависит от того, насколько это будет интересно потенциальным слушателям

21

Обучение / Курс по BABOK v 2.0 на русском

« : 16 Февраля 2012, 18:02:23 »

Коллеги, в Учебном Центре Luxoft разработан и включен в каталог курс, разработанный на основе материалов BABOK v 2.0.
Данный курс посвящен подробному рассмотрению задач, элементов, техник, описанных в Knowledge Area "Business Analysis Planning and Monitoring".
Практически все техники, рекомендуемые к использованию в рамках данной области знаний, будут подробно рассммотрены на практических занятиях.
Курс содержит большое количество диаграмм, взятых из первоисточника (BABOK v 2.0). Также используются диаграммы из внешних источников и диаграммы, разработанные автором курса.
Курс по структуре полностью соотвествует структуре данной области знаний.
Курс разработан на русском языке. В ближайшее время будет собран английский вариант этого курса.
Желающие пройти данный курс могут подавать  заявки: http://www.luxoft-training.ru/training/catalog/course.html?ID=31383

22

Конференции Семинары и Тренинги / Re: Встреча Сообщества по обсуждению чаптера ИИБА, Мск, 14 июля - ОТМЕНЕНА

« : 16 Февраля 2012, 16:15:37 »

Коллеги, отписываюсь здесь, дабы не создавать новую ветку.
Идея создания IIBA Russian Chapter продолжает зреть в аналитических умах и не только членов UML2. Письма с такими предложениями регулярно приходят в соотвествующее подразделение IIBA. В конце концов, нам было предложено связаться между собой и как-то консолидировать наши усилия.
Я предлагаю откликнуться тех, кому интересна эта тема, и для кого плюсы от такого сотрудничества очевидны.
Для создания российского подразделения необходимо выполнить ряд условий (требований). Первое, и самое сложное, с моей точки зрения, это необходимость собрать не менее 50 зарегистрированных членов IIBA (Completion of a petition signed by a minimum of 50 registered International IIBA members)
Поэтому, я предлагаю всем зарегистрированным членам IIBA (http://www.iiba.org/imis15/IIBA/Membership/IIBA_Website/Membership/Membership.aspx?hkey=5d0e22ee-02e0-49c7-b5fe-ae3e54a9143b) и заинтересованным в создании подразделения прислать мне информацию о себе в следующем формате:

First Name |

Last Name|

Company |

Position |

IIBA Member ID (expiry date) |

Contact information (tel. number, e-mail)|

Информацию можно отписать мне в личке, либо по почте capry6565@gmail.com               
Всю собранную информацию я буду концентрировать в табличке в Google Docs. Поэтому, желающие смогут получить доступ к этому файлу

23

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 31 Января 2012, 19:49:42 »

Я признаться не верю, что ПМу важно количество часов, отработанных аналитиком...

В нашей компании также принято "шарить" сотрудников между проектами на определенный процент, либо количество часов, приняв 40 часов в неделю за 100%.
С учетом этого процента занятости сотрудника в проекте составляются планы, и контролируется их исполнение.
Это абсолютно нормальная практика формального урегулирования вопросов, связанных с использованием разделяемых человеческих ресурсов.

Кажется тема поста начинает "мутировать". Если тема управления разделяемыми ресурсами так интересна, может завести отдельный пост?

24

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 31 Января 2012, 11:44:03 »

... они [этапы] имеют между собой "мостики", являющиеся продуктами этого этапа...

Согласен. Безусловно, результатом работы каждого этапа Project LifeCycle являетя набор артефактов. Каков набор этих аретфактов, какова степень их детализации и формализации, кто участвует в их разработке, кто их утверждает, каков процесс управления их изменениями... все это определяется на ранних этапах проекта, и зависит от типа проекта (разработка нового софта, расширение существующей системы и т.п.), от типа используемой методологии ("Водопад", Agile...), от стандартов, принятых в компаниях разработчике и заказчике и т.д.  Все это очень хорошо описано в BABOK.
Можно подходить к описанию проекта с точки зрения разрабатываемых арефактов, можно декомпзировать собственно работы с помощью WBS, можно описать основные этапы проекта ... Это вопрос привычки. С моей точки зрения, этапы это наиболее высокоуровневое описание проекта, по сравнению с  декомпозицией работ с помощью WBS, и более стабильное, по сравнению с разрабатываемыми арефактами. Поэтому я воспользовался именно этим подходом 

25

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 30 Января 2012, 09:59:41 »

Не-не-не..., боже меня упаси, раскрывать "пункты должностных обязанностей"! В этом сысле я совершенно согласен с коллегой DIV - должностные инструкции в каждой компании свои, и описывают они, чаще всего, конкретные процессы, которые сложились в данной компании. Я лишь постарался донести своё мнением относительно тех активнойстей, которые вы описали.
Что касается ПМ-а и Архитектора, то тут я врядли смогу вам помочь - я имею представления только о тех активностях, которые они выполняют совместно с Аналитиком. Я уверен, что для них тоже существуют свои форумы. Эти вопросы лучше адресовать туда.
Рад был помочь.
Если остались вопросы, касательно работы Аналитика, спрашивайте, чем сможем - поможем
Кстати, было бы очень интересно узнать ваше мнение

26

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 27 Января 2012, 13:59:08 »

Приветствую.
Ни для кого не секрет, что существует достаточно большое количество подходов к определению этапов жизненного цикла (ЖЦ) IT проекта. Эти самые ЖЦ описаны в работах Вигерса и других известных авторов, работающих в этой теме, описан свой подход в RUP, есть классификация этапов ЖЦ в BABOK. Названия этапов варьируются, но по смыслу они все примерно говорят об одном и том же.
Мне кажется, что если отнести пункты, приведенные ниже, к более или менее формализованным этапам ЖЦ проекта, это поможет точнее ответить на заданный вопрос.
Давайте попробуем:

1.Обследование предметной области;

Это этап Бизнес Моделирования (Анализа) (Business Analysis).  Это, безусловно, обязанность Бизнес Аналитика

2.Определение требований;

Это этап работы с требованиями (Requirements). Часто его разделяют на этапы "Получения, извлечения" требований(Requirements Elicitation) и "Разработки или управления" требованиями (Requirements Management). Но, как бы там ни было - это работа Аналитика, Бизнес или Аналитика Требований, если таковой выделен в компании (такая ситуация часто возникает в проектах с "импортными" заказчиками со сложной предметной областью. Они предпочитают выделять своих специалитстов в предметной области (SME) в качестве Бизнес Аналитиков, проектной же команде оставляют работу по разработке собственно требований).

3.Обоснование необходимости внедрения, смета затрат, предполагаемый экономический эффект и время окупаемости;

"Обоснование необходимости" - это то, что выполняется на этапе "Предварительного анализа" (Preliminary Analysis), когда проводят анализ проблемы (Problem Analysis), которая, собственно и явилась причиной старта проекта, или возможности (Opportunity), которую хочет реализовать компания, заказывающая проект. Все это является частью более глобального этапа - Бизнес Анализа. Т.е. это тот же этап, что мы упоминали для первого пункта.
"Смета затрат", вот тут нужно быть аккуратными. Бизнес Аналитик обязан разрабатывать планы проведения этапа Бизнес Анализа, оценивать ресурсы, необходимые для его реализации, но... деньги проекта, глобальное планирование ресурсов на все этапы проекта, не только Бизнес Анализа, - это прерогатива Руководителя Проекта. Соотвественно, такие "денежные" показатели как "предполагаемый экономический эффект" и "время окупаемости" - это все-таки зона отвественности человека, стоящего повыше Аналитика. Повторюсь, Аналитик не располагает информацией о всех проектных ресурсах, не решает политических (денежных) вопросов с заказчиком, поэтому - это не его.

4.Разработка ТЗ; подготовка сопроводительной документации;
5.Создание необходимые диаграмм;

Если ТЗ то, в общепринятом смысле содержит требования, то это этап Работы с Требованиями. Разработка диаграмм, строго говоря, не тянет на отдельный, самостоятельный этап, поскольку "диаграммы" являются артефактами, которые разрабатываются для разработки требований - облегчение понимания, обсуждение с заказчиком и т.д. Чаще всего, самостоятельным артефактом (независимым от других артефактов, например от требований), который принимается заказчиком, включается в поставку они не являются. Это всего лишь иллюстрация. Но, сразу оговорюсь, что степень формализации документации требований определяется типом проекта, обсуждается с заказчиком и поэтому очень может быть, что в каком-нибудь Agile проекте диаграммы будут, по договоренности с заказчиком, приняты как необходимый и достаточный документ требований.

6.Разработка шаблонов проектирования;

Это этап Системного Анализа и Проектирования (System Analysis and Design).  Это этап, на котором подключаются две новые роли - Системный Аналитик и Системный Дизайнер. Это люди не от Бизнес Анализа. Это люди от программирования, поскольку речь идет уже о разработке базы для будущей реализации: определение будущих классов, интерфейсов и т.д. Более того, некоторые шаблоны проектирования являются платформенно зависимыми. Что это означает? Это означает, что существуют отдельные шаблоны проектирования для Java, для C++ и т.д.
Не во всех компаниях Системные Аналитики отделены от Бизнес Аналитиков. Не во всех компаниях, где такие роли (должности) выделены (у нас они называются Архитекторы), эти "Архитекторы" занимаются Системынм Анализом и Дизайном. Зачастую они ограничиваются разработкой технических решений по выбору платформы для реализации, проектированием БД, проектированием общей архитектуры (сервера, сетка) и т.д. Обязанности же по проведению Системного Анализа и Дизайна делят между собой Аналитик и разработчики.

7.Разработка тест-кейсов;

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

8.Участие в тестировании и сдаче продукта заказчику;

Этап тестирования проводят Тестеры. Аналитик только наблюдает за процессом. Необходимо знать, все ли требования, вошедшие в Base Line протестированы, какие успешно прошли, какие завернули и т.п. поскольку, при нормальной организации работы с требованиями, все это отражается на статусе требования

9.Участие во внедрении и сопровождении программного продукта.

Аналогично предыдущему

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

27

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 26 Января 2012, 16:06:16 »

"Никто не забыт, ничто не забыто"
Коллеги, спасибо всем за участие в переводе и обсуждении Глоссария BABOK. Я думаю, что эта работа, проведенная под эгидой UML2, будет очень полезна для всего русскоговорящего аналитического сообщества.
Я думаю, мы все заинтересованны в том, что бы мы могли совершенно открыто, законно, цивилизованно, не нарушая чьих-либо авторских прав, пользоваться результатами этого труда.
Я сейчас, воспользовавшись паузой в проектах, провожу работу по легазации с точки зрения IIBA работы, проведенной членами сообщества UML2. Очевидно, что это не произойдет мгновенно. Это потребует некоторого времени.
Пока эта работа не закончена, я еще раз призываю принять участие в ревью и обсуждении аналитических терминов. Чем больше специалистов примет участие в этом начинании, тем представительней будет результат.
Тех, кто еще не участвовал в обсуждении, очень прошу не полениться и пролистать данную ветку форума, что бы ознакомиться с правилами обсуждения: где оставлять свои предложения и коментарии, как их оформлять и т.д.
Еще раз подчеркну, что данную ветку форума хотелось бы оставить для обсуждения общих и организационных вопросов, обсуждение собственно терминов лучше проводить на соотвествующих страницах Глоссария (http://lib.uml2.ru/BABOK)

28

Термины и Определения / Re: Терминологическая база Бизнес Анализа (перевод BABOK Glossary)

« : 20 Октября 2011, 12:15:14 »

Да, Ок.
Просто сам процесс обсуждения и принятия мне видится состоящим из двух этапов:
1. все желающие вычитывают выложенные переводы, и оставляют свои замечания, предложения на странице термина, на закладке "Обсуждение" (не здесь в форуме!). Этот процесс так или иначе уже идет, нужно только его активизировать. Именно для этого ревью я и предполагал привлечь еще и коллег из дружественных сообществ;
2. после этого можно приступить собственно к обсуждению и принятию окончателного варианта перевода. На этом этапе будут обсуждаться перевод и все предложенные альтернативные варианты. Вот тут нужно хорошо подумать, как это провести. Это могут быть круглые столы или телеконференции проводимые на постоянной основе (например, составить график обсуждения букв и регулярно их проводить), либо будет какой-то представительный комитет, которому будут делегированы эти права... Не, знаю. Такого опыта у меня пока нет, поэтому и нет готового проверенного рецепта.
И, еще раз, очень важно выработать комплекс критериев принятия того или иного варианта. Иначе опять начнется: "У нас так работают... У нас в компании это все так называют... Мне так привычней...". Мы это уже проходили!

В общем, вот так... Жду твоих предложений 

29

Обучение / Re: Предложили работать аналитиком сами, и зацепило

« : 19 Октября 2011, 18:23:40 »

to Elf
Там было что-то про зоны ответственности...

30

Обучение / Re: Предложили работать аналитиком сами, и зацепило

« : 19 Октября 2011, 17:27:01 »

http://livehh.ru/entsiklopekarye/entry/sistemnyy-analitik
http://livehh.ru/fedorovia/entry/biznes-vs-sistemnyy-analitik-podborka
http://livehh.ru/fedorovia/entry/klassicheskiy-primer-biznes-analitika-sherlok
http://livehh.ru/fedorovia/entry/kak-stanovyatsya-analitikami

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