16

Вакансии / Re: БА в Ситроникс

« : 27 Мая 2013, 14:53:38 »

В прошлом году почти завербовалась в киевский Ситроникс на проект для МТС.
Собеседование с Москвой прошла влет, а на месте поняла, что работать невозможно 

Надеюсь, в Москве условия получше )

я вот утром прилетел в Киев и сейчас сижу в киевском Ситро как раз на этом проекте МТС)
конечно в Москве условия получше. кстати, в Киев тоже можно попробовать схантиться если есть желание. тут тоже вакансии аналитиков открыты.

17

Вакансии / Re: БА в Ситроникс

« : 27 Мая 2013, 14:35:56 »

Про "бизнес-процессы грабежа и угона" мне очень понравилось :-))). Это как в анекдоте "милиция - те же бандиты, только их отличить проще, они в форме ходят ... " (с)

да
на самом деле очень интересная и челенджовая задача: по сути, мы модернизируем существующую систему "план перехват"

18

Вакансии / Re: БА в Ситроникс

« : 27 Мая 2013, 01:29:30 »

именно. FORIS-то из CBOSS по-сути отпочковался вначале в медиател, потом в Ситроникс.
Бизнес МТС созрел до конвергента, когда скупил МГТС и Комстар - и мы устремились
отличие от CBOSS в том, что мы не коробочный конвергент делаем, а под требования МТС и сугубо для МТС - это накладывает определённые ограничения на проектирование.

19

Вакансии / Re: БА в Ситроникс

« : 27 Мая 2013, 01:04:33 »

привет, Денис.
единый биллинг для фиксированной и мобильной связи. женим МГТС, МТС и Комстар
все бизнес-процессы, по сути, становятся общими и абонент может пользоваться услугами как мобильной, так и фиксированной связи под одним лицевым счётом. например, так называемые услуги Double/Triple play: телефон, интернет, телевидение.
там много интересных требований.
уникальный опыт в своём роде - построение конвергентного OSS/BSS решения.

20

Вакансии / БА в Ситроникс

« : 26 Мая 2013, 22:23:01 »

Он же Нвижн Групп, дивизион BSS

Коллеги, к нам в отдел нужны бизнес-аналитики.

предметная область: разработка конвергентного биллинга МТС, внедрение OSS/BSS решений в местах присутствия МТС. автоматизация ГУВД: бизнес процессы грабежа и угона
ну, и, его величество, пресейл

требования:
- ВО
- опыт в роли аналитика(системного/бизнес) от двух лет: сюда входит и знание тех.процессов разработки ПО(MSF/RUP), понимание нотаций IDEF, UML и остальные качества, которые помогли вам успешно проработать в роли аналитика от двух лет
- можем рассматривать недавних выпускников IT-специальностей без опыта, но интересующихся развитием в качестве аналитиков, с мозгами и шилом в заднице

ЗП: по результату собеседования. если по скиллам и личным качествам подойдёте - то не ниже средней по рынку.
кидаю клич сюда, ибо пока набирают в компании по внутренним каналам, а из тестирования или техподдержки аналитики редко получаются.

затравка: работа очень интересная, система крайне сложная(никто не будет спорить, же, что OSS/BSS системы операторов связи - одни из сложнейших ИС в мире), потрясающий коллектив и атмосфера, отличные условия для труда и роста ввысь и вширь
кидайте резюме и вопросы мне на мыло lemelyanov@nvision-group.com и в zloy.bayan@gmail.com

объявление размещаю только здесь

upd: не подкупайтесь на лёгкость изложения - вакансия серьёзная, компания более чем серьёзная, и задачи стоят чудовищно сложные и интересные 

21

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

« : 22 Ноября 2012, 11:20:45 »

С Cradle мы связывались. не впечатлил он моё руководство.
у нас требования к интеграции не только в том, чтобы сынтегрить две системы, но и в том, чтобы не сломать существующую аналитику в тфс - отчёты, выгрузки и прочее.
Вчера встречались с IBM - нашли они способ поженить RRC и TFS - есть малоизвестная буржуйская контора - TaskTop - они разработали шину для интеграции RRC и TFS. вчера нам показали архитектуру. вроде всё очень даже устраивает.
что до остальных вопросов - да, мы не ведём учёт атомарных требований в тфс. это чудовищно, понимаю, но это так
Каждый аналитик на своей задаче как ему удобно ведёт учёт требований. или не ведёт. полная демократия)
я пришёл сюда год назад и инициировал эту бучу с RRC.
как костыли перед внедрением СУТ, предложил руководству использовать excel для управления требованиями и генерации реквайрментов в тфс под задачами. кто-то впечатлился, кто-то нет. у нас специфика особая - мы иногда даже предложения по реализации пишем вообще без требований :-) 
что до трассировок в ТФС - это надо потратить довольно много времени и написать все скрипты для минимизации заведения айтемов в нём. под это нет внутреннего заказчика у нас, ибо "и так работает" и требования мы не учитываем в тфс. но если IBM не нашёл бы решения, то, скорее всего к этому бы мы и пришли - продумали актуальную иерархию артефактов тфс с учётом трассирования, визуализировали и прочее.
под любое усовершенствование, внедрение или пересмотр существующего функционала внутри компании-разработчика всегда должен быть внутренний заказчик(потребность в усовершенствовании/Изменении) без этого все предложения обречены на провал.

22

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

« : 21 Ноября 2012, 11:32:06 »

поковырялся. если скриптами долбить таски-требования и выгружать во внешние системы для управления и ведения связей, то жить, в принципе, можно попробовать
но всё-равно это криво и убого, на мой взгляд.

23

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

« : 21 Ноября 2012, 10:50:08 »

Мне кажется, что разработчики TFS не предполагали такого его применения. TFS хорошо работает, когда КП (это же "комплексный проект", да, или что-то в таком роде?) - это Project Collection, проект - это Project, требование - это Requirement, если вы работаете по CMMI, или User Story, если по Agile. В вашем случае, судя по всему - CMMI.
А вы смотрели примеры по ссылке Process Guide, которая образуется в корне сайта проекта TFS (шаблон CMMI 5.0) сразу после его создания?

КП - это коммерческое предложение. да, мы по CMMI работаем, но через задницу
извините, разве вы не согласны, что в ТФС работа с требованиями совершенно неудобна, или скорее невозможна, ибо ничего с этими ворк айтемами больше сделать нельзя. ни матрицу трассирования создать, ни вменяемое дерево трассировок, кроме как классические чайльд-парент. а плодить айтемы под каждую хотелку, а потом таски под каждый реквайрмент - мы с нашей спецификой только месяцев пять будем тратить на заведение и манагерство всей этой эпичной структуры.
может, это работает для сравнительно небольших проектов с явными границами автоматизации. у нас своя специфика - в год мы  выпускаем 2-3 релиза, в которые набиваются все задачки, которые заказчик смог пропихнуть за оговоренный бюджет и срок. соответственно поток хотелок и требований у нас мощн, порывист и беспощаден в виду того, что OSS/BSS решение одного немаленького оператора связи - очень и очень сложная система и релизы, как правило, затрагивают комплексно все подсистемы.

конечно нам, как аналитикам и архитектуре, хотелось бы упростить жизнь и иметь полноценную СУТ. на базе ТФС бесполезно даже пытаться рассматривать управление требованиями в том объёме, в котором нам приходится работать с ними.
может, конечно, я не прав и есть способ забодать ТФС в этом плане, но, когда я плотно исследовал этот вопрос, я на него нашёл только отрицательный ответ - мелкософт сами признаются, что полноценного функционала СУТ в ТФС нет.
открыт для обсуждения
признаться вы меня своим вопросом про process guide поставили в тупик. поковырялся, что-то не нашёл. бегло в инете тоже не нашёл.

24

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

« : 20 Ноября 2012, 18:13:52 »

Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял,  Work Item Type = Requirement и Work Item Type = Change Request не используется?

у нас не совсем так. подписанный с заказчиком КП делется на requirements, каждый проект живёт под requirement, под ним задачи на предложение по реализации, HLA, ПМИ, разработку по модулям, подсистемам и прочее формируются в виде leadtask.
CR-ы - да, мы не используем.

25

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

« : 20 Ноября 2012, 18:08:56 »

Ссылки интересные, спасибо, почитаем.
Для анализ и разработки требований у нас Sparx Enterprise Architect, затем самопальная утилита конвертирует их в TFS. Шаблон проекта от Microsoft MSF for CMMI 5.0 со своими доработками вроде бы обеспечивает устраивающую всех трассируемость требований - от бизнес-требований продуктового департамента до системных и требований к компонентам. Таски для разработчиков (Work Item Type = Task) подвешиваются под требования (Work Item Type = Requirement).
Воркфлоу тасков и требований разных типов разный.
А у вас, как я понял,  Work Item Type = Requirement и Work Item Type = Change Request не используется?

ну так это не ТФС, а EA+ самопал.
у нас почти такой же процесс. только без ЕА. я модельки в нём набиваю, но смутно представляю себе как вести учёт и трассировку требований к проекту в нём. когда совсем задница мы в екселе ведём трассировки с синхронизацией с ТФС.
а так пока управляем требованиями с помощью силы головы и какой-то матери
а можно подробнее про ваш процесс управления требованиями и EA?

26

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

« : 20 Ноября 2012, 18:03:34 »

с айтемами понимаю, а зачем Вам документы туда-сюда таскать? Может достаточно одного места для хранения документов, по такой схеме

Документы (СУТ) <-> items (СУТ) <==> items (TFS)?

документы таскать туда-сюда нужно, ибо помимо аналитики есть архитектура, разработка и тестирование.
фишка в том, что в СУТ артефактом является требование или его реализация в виде ФТ или ВИ или TC. СУТ оперирует на уровне этих сущностей. при необходимости из артефактов собирается документ по шаблону.
ТФС же хранит артефакты как документы. плодить айтемы в ТФС под каждую задачу, когда у нас, бывает, МТС по сотне требований в рамках одной задачи выкатывает за аналитическую фазу, а задач в релизе - несколько десятков - не совсем удобно и опасно для головы. особенно учитывая ту форму, в которой айтемы живут в ТФС.
другими словами, как реализовать общий процесс для всей разработки, а не только для архитектуры и анализа: если мы оперируем уровнем артефактов СУТ, то они должны быть доступны на любой стадии процесса разработки, если мы от них отказываемся, то нужно придумать, как жить с двумя независимыми системами. в общем, проблема пока не поддаётся решению средствами IBM. посмотрим, что они завтра скажут

27

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

« : 20 Ноября 2012, 16:40:40 »

соответствие артефактов СУТ артефактам ТФС и взаимное импортирование артефактов документов и просто документов. в той реализации, которую нам предложил IBM - интеграция обуславливалась ручным перекладыванием файликов из репозитория СУТ в репозиторий ТФС с последующей генерацией айтемов в ТФС.

28

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

« : 20 Ноября 2012, 14:59:41 »

Вроде бы TFS включает в себя систему управления требованиями, трассировки требований там реализованы.

ахаха))) вы делаете мне смешно
к сожалению, ТФС не располагает никакими средствами управления требованиями. только, как я выше написал, excel и ведение матриц трассировок ручками с синхронизацией с айтемами ТФС.

Вы используете еще одну систему управления требованиями в дополнение к TFS? Какие задачи она решает? Нельзя ли их решить с помощью TFS ?
Вопрос для меня очень актуальный, т.к. наша компания как раз сейчас переносит управление требованиями в TFS.

ТФС совершенно не заточена под анализ и не предполагает управление требованиями. политика ТФС в том, что аналитики и архитекторы выступают для разработки и тестирования в роли заказчиков и формируют "требования" - таски на разработку. в этапах разработки и тестирования ТФС хорош. многие процессы он автоматизирует и упрощает.
но в качестве системы управления требованиями он вообще никакой.
в нашей компании вопрос управления требованиями стоит очень остро и я ответственный от аналитики по реализации СУТ у нас. мы уже полгода ведём переговоры с IBM но пока поженить их СУТ с TFSdoc не получается. завтра, вот, они встречу организовали - может нашли решение.
Майкрософт мне написал следующее: да, ТФС в этом плане некомильфо, юзайте решения, интегрированные с TFS
http://www.edevtech.com/products.html
 http://www.technosolutions.com/topteam_analyst.html

29

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

« : 19 Ноября 2012, 12:40:46 »

Предыдущий пост совершенно правильный. существуют системы управления требованиями. в них есть такая архиполезнейшая вещь, как матрицы трассировки требований - двумерный массив взаимосвязей между элементом разработки в различных документах.
и они довольно дорого стоят.а если вы используете в разработке долбанный ТФС, то выбор таких систем очень сужается.
можно не покупать систему и попытаться реализовать матрицу трассирования в excel. это более чем реально и ещё более чем геморройно
для этого вам придётся ввести спортивную кодификацию артефактов документов.

30

Для всех / Re: обратная связь по документации с помощью опросника

« : 19 Ноября 2012, 12:28:53 »

Наболевшее