1

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

« : 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&

2

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

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

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

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

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

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

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

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

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