1

Вакансии / Re: Вакансии системного/бизнес аналитика

« : 13 Сентября 2012, 20:13:01 »

Обращаться можно через hh.ru или мне напрямую в личку

2

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 19:51:02 »

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

Хорошая ссылка!
Некоторые из приемов я как раз и применяю на практике.
БП формулируются в виде Supplementary Requirements, на которые ссылается UC.

Создать задание

1. Менеджер выбирает создать задание.
2. Менеджер вводит атрибуты задания в соответствии с SUP-2.1 "Правила заполнения/ отображения/ валидации атрибутов при создании нового задания".
3. Система определяет возможность размещения необходимого количества рекламных макетов (в соответствии с SUP-2.8 "Алгоритм проверки возможности выполнения заявки")
4. Система создает задание и переводит его в состояние "Открыто".
5. Система изменяет количество свободных и зарезервированных тележек в гипермаркете соответствии с SUP-2.9 "Алгоритм выбора тележек для задания".

3

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 19:45:06 »

Моё мнение. Я бы в таком случае классифицировал диаграммы по типам пользователей. Для каждого пользователя создал бы отдельную ДВИ -- было бы проще.

Тогда вы создаете одинаковые UC для каждого из  пользователей. Дублируется описание. Если будут изменения -- придется править везде.
Если же вы имеете ввиду на разных диаграммах показывать одни и те же UC, но с разными экторами -- то у UC будет несколько праймари экторов, что недопустимо.

4

Вакансии / Вакансии системного/бизнес аналитика

« : 13 Сентября 2012, 17:52:02 »

День добрый.

В компании i-Free (Питерский офис) на постоянную full-time работу требуются системные/бизнес аналитики.
Нам нужны аналитики разного уровня квалификации и разных компетенций.

Минимальные требования:

Опыт работы системным/бизнес аналитиком или техническим писателем в области разработки коммерческого ПО от 2 лет.
Глубокое знание современных IT-технологий, основных особенностей построения типовых программных решений (в том числе для Web, для мобильных устройств, промышленных копроративных систем, серверных решений ).
Способность создавать ясные и хорошо структурированные документы.
Владение UML как минимум на уровне разработки UC модели.
Системность мышления, самостоятельность, исполнительность и аккуратность.
Знакомство с принципами ООП.

Особенности работы
Большое количество проектов.
Заказная разработка.
Совершенно разные предметные области (мобильные сервисы, индустрия развлечений, брендированные продукты, web порталы, приложения для телевизоров. игры и т.д. ).
Совершенно разные технологии разработки (клиент-сервер, трех звенные архитектуры, мобильные приложения, WEB сервисы, NFC/AR технологии, J2EE/iOS/Android/PHP/Ruby/Perl... и т.д.  ).
Адаптированные процессы к разным проектам.
По большей части продукты для индустрии развлечений.

Подробнее -- на собеседовании.

Вакансия на hh.ru:
http://spb.hh.ru/vacancy/5804299?query=%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B9%20%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%20i-free&

5

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 14:55:57 »

Но, по крайней мере, здесь все равно пять UC!

Да, редактировать заказ -- это тоже отдельный UC. Точнее "Редактировать параметры заказа"

6

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 14:54:22 »

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

Именно  это мне и приходиться делать(
БП + предусловия.
Минус: диаграмма "не говорящая"

7

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 14:14:05 »

Вот смотрите ребята, реальный пример
Собственно тут возникает следующая сложность:
В системе 4 эктора. Есть UC которые выполняют только определенные экторы, скажем
"Разморозить заказ" может Заказчик и Администратор.
"Заморозить заказ" может Заказчик и Исполнитель
"Отменить заказ" может Администратор и Исполнитель
"Передать заказ другому исполнителю" может Администратор, Заказчик, Исполнитель
"Просмотреть заказ "/"Посмотреть список заказов" может Интересант, Исполнитель, Администратор, Заказчик
и так далее..


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

8

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 12:30:28 »

Добрый день!

Я где-то вычитал, что "хороший UC - это простой UC".

При рассмотрении Вашего примера мне показалось, что Вы в плену слова "редактирование". На самом деле, экторы в вашем примере имеют разные цели: "создать заказ", "детализировать информацию заказа", "назначить заказ исполнителю", "создать проект выполнения заказа", "закрыть заказ" и т.п. Различные цели - различные (достаточно простые) UC.
Конечно, эти UC имеют одинаковые фрагменты, например, "выбор заказа". Выделите его в UCI, и никакого дублирования не будет!

Дополнительно:
Название "Редактировать заказ исполнителем", мне кажется, неудачное:
1) Вы указываете эктора в названии UC (дублируете информацию диаграммы, на которой, наверное, Вы нарисуете этого эктора).
2) Слово "Редактировать" в названии UC какое-то аморфное; оно мало что говорит о действительной цели.

1. Все перечисленные вами UC есть в системе. Создать, назначить, закрыть...тут вопросов нет.
2. Я могу привести другой пример, раз "Редактировать заказ" вам кажется аморфным. Например "Просмотреть детальную информацию о заказе". Это могут сделать все пользователи, но, скажем, только заказчик, может на этапе просмотра заказа "Добавить задачу для заказа", т.е. запустить расширяющий UC.

9

UML SysML и пр. / Re: Нюансы разработки модели UC

« : 13 Сентября 2012, 12:20:23 »

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

10

UML SysML и пр. / Нюансы разработки модели UC

« : 12 Сентября 2012, 23:50:57 »

Привет коллеги.
Хочу посоветоваться с вами по практике использования UC.

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

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

Это еще не сложный пример, бывает поведение UC еще больше разнится, в зависимости от того, кто является инициатором.

Тут, естественно, есть два пути:

• Обобщить экторов в нового эктора  и соединить его с нашим UC. Далее навесить бизнес правила/доп. требвоания/права доступа к  UC, где уточнить кто, что и когда может. Но это все ровно не решает проблемы extend и include других UC. В зависимости от экторов у нашего UC  может быть разный набор таких взаимосвязей. Кроме того бывает, что сами шаги UC сильно зависят от эктора. Далее -- в большой системе придется достаточно много вводить таких виртуальных группирующих экторов, ровно столько, сколько будет сочетаний экторов между собой. Модель станет перегруженной и громоздкой
• Выделять UC а ля "Редактировать заказ исполнителем". Т.е для каждого эктора -- свой UC. Минусы очевидны, дублирование описания поведения системы

Другие варианты?
Спасибо!