331

Вакансии / Re: ВАКАНСИЯ Системный Аналитик (Москва)

« : 10 Сентября 2014, 14:36:54 »

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

И крутякам наступит рынок...

Вот так всегда: ходишь, ходишь крутяком на работу, а потом — бац! — и вторая смена.

Почти (с).

332

Вакансии / Re: ВАКАНСИЯ Системный Аналитик (Москва)

« : 10 Сентября 2014, 11:43:02 »

Думаю, как избавиться от нашего крутяка

Паренек дождется этого момента, и поднимет свой ценник кратно. Рынок-с.

333

Вакансии / Re: ВАКАНСИЯ Системный Аналитик (Москва)

« : 09 Сентября 2014, 15:02:37 »

...Если Вам не нравится - проходите мимо   =)

Справедливо. А эта европейская компания, случаем, не GmbH "Тёщин дом"?

334

Примеры / Re: UML диаграммы по BPMN

« : 09 Сентября 2014, 14:38:25 »

С каких диаграмм лучше начать? А то я что то совсем в "упадке".

Я не умею думать диаграммами. И не советовал бы другим. Начать лучше с формирования понимания:
1. Зачем все это нужно. Цели и задачи, которые будут способствовать их достижению.
2. Что там происходит (текущая ситуация, основные процессы, обязательные по тем или иным причинам артефакты).
3. Как контролируется (какие показатели, периодичность).
4. Перспективы развития (что можно усовершенствовать).

При наличии понимания по этим пунктам, рисование любых диаграмм становится делом техники.
Если в виде исходных данных у нас BPMN-картинки, сути это не меняет. Нужно разобраться, что там нарисовано и почему нарисовано именно так. Например, для чего отдельно выделяется "отдел продаж". То-ли кто-то поспешил/перестраховался, то-ли хотели сказать что-то важное.

335

Вакансии / Re: ВАКАНСИЯ Системный Аналитик (Москва)

« : 09 Сентября 2014, 12:41:03 »

В штат крупной европейской компании ищем Системного аналитика на проект развития ERP системы по части логистики

- Управление проектами по разработке нового функционала бизнес-приложений;
- Стратегия проекта...
- ...отчетность\планирование;
- Управление сроками проекта и ресурсами проекта.
...
- Знания методологий управления проектами;

Аналитика? Системного?

Владение MS Office (в том числе MS Project);

Органично. MS Project примерно так же относится к MS Office, как стратегия проекта - к системному анализу.

Ищем Специалиста нацеленного на долгосрочное сотрудничество, нам НЕ подойдут кандидаты, меняющие работу чаще, чем раз в три года.
...
Оклад  110000 - 120000 руб. gross + премии;

Т.е. примерно 95-105 на руки + обещания. Впечатляет. Таки просто сказка.

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

336

Примеры / Re: UML диаграммы по BPMN

« : 09 Сентября 2014, 12:16:16 »

Доброе утро!
Я начал с диаграммы классов, так как у меня постоянно с ней много вопросов. Но другие диаграммы я не забросил, хотя тоже немало вопросов, и попытался изобразить. Во что в итоге получилось.  Иной раз, кажется, что все диаграммы не связанны ни как между собой.

Все связаны. Изменения в диаграмме последовательности или вариантов использования запросто может сказаться на диаграмме классов. И наоборот. Дело не в видах диаграмм, а в "системности" самой системы. Потянешь с одного конца - что-то изменится на другом.

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

А пока выглядит как попытка изобразить на одной картинке помесь логической модели и модели базы данных.

337

Примеры / Re: UML диаграммы по BPMN

« : 08 Сентября 2014, 12:31:41 »

Так же немного подкорректировал модель предметной области.

- Почему покупатель связан с товаром, но не доставкой?
- Товар (на схеме) - это что? Некая сферическая атомарная сущность (например, "куртка"), которую может захотеть приобрести покупатель, или фиксированный набор таких сущностей, с фиксированным же характеристиками, которые определил покупатель (куртка кожаная черная - 3 шт., чайник пластиковый зеленый 1,8 л. - 2 шт.)?
- Почему заявка, счет, проект и заказ поставщику не связаны с товаром?
- Доставка может быть только от одного поставщика?
- Почему менеджер по продажам не связан (прямо) с отделом продаж?

P.S. Попытки изобразить течение процессов на ER диаграммах, обычно ведут к грустным результатам.

338

Проектирование / Re: Сравнение трёхзвенки (MVC) и варианта с переносом части бизнес-логики в СУБД

« : 09 Августа 2014, 20:39:35 »

Я сварщик не настоящий, но... Из некоторых проектов вынес следующее:
1. Логика на хранимых процедурах - это дешево (в разработке), быстро (в исполнении) и дает возможность задействовать весьма приятные фишки от разработчиков СУБД.
2. Часть логики на хранимых процедурах, часть на сервере приложений - сплошные неудобства в документировании и страшный геморрой, когда дело касается развития системы через год-другой (когда большая часть "тех, кто помнит" уже разбежалась на другие проекты).

Соответственно, если надо дешево и сердито - вперед в хранилки. Если детище надо сопровождать и развивать - возможно, стоит потратиться на классическое разбиение.

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

P.S. 150к запросов в день и 20 активных пользователей - это мелочи. Любая из раскрученных СУБД такое (и не такое) осилит на раз.

339

Работа / Re: Изменения на рынке труда

« : 07 Августа 2014, 12:16:16 »

Могу добавить 5 копеек по госсектору.

1. Ожидаю заметного сокращения финансирования всякого "баловства", к которому относится солидная часть ИТ-проектов. В 2008-2009 проходили.

2. Осенью потребность в аналитиках, как правило, проистекает из двух источников:
- сдача контрактов (бумаготворчество, участие в испытаниях);
- подготовка к контрактам следующего года (разработка концепций, техтребований под контракты, всяческая "пресейловая" активность).
С учетом ожидаемого сокращения второй составляющей, конторы-разработчики вполне могут постараться обойтись собственными силами (за счет высвобождения ресурсов по мере сдач).

3. Весной потребность в аналитиках растет с марта примерно до начала лета, когда становится понятно, кто взял контракты и кому посчастливится готовить технорабочие проекты. По тем же причинам, что и в п.2, в следующем году "весеннего обострения" не ожидаю.

Косвенно рассуждения подтверждены тем, что мой нынешний работодатель (1000+ человек) последние несколько месяцев аналитиков не набирает.

340

Для всех / Re: Общая схема информационных потоков

« : 07 Августа 2014, 11:52:30 »

Здравствуйте !
Я не являюсь системным аналитиком, но данное направление мне очень интересно. И вот я получил задание, с помощью которого смогу приобрести начальный опыт в данной сфере. Задание такое: Схематично описать информационные потоки на предприятии. Данная схема будет использоваться для автоматизации информационных потоков. Схема должна быть  просто линейной без декомпозиций - "на одном листе".
Прошу следующих советов:
1. Какой инструмент использовать, я планирую использовать  Visio 2010.
2. Какие условные обозначения лучше выбрать для объектов схемы. Объекты такие: документ, отчет, справочник, обработка (например банк-клиент)
3 Вопрос скорее на перспективу какую нотацию вы порекомендуете UML или IDEF

Исхожу из следующих предпосылок:
1. Вы не являетесь системным аналитиком - следовательно, результата со всеми профессиональными "бантиками" от Вас не ждут.
2. Схема "на одном листе" ориентирована в первую очередь на создание у человека цельного впечатления о предмете.
3. Схемы "на одном листе" часто показывают и "первым лицам".

Так вот, могу порекомендовать:
1. Не связываться со знаменитыми нотациями, если только потребителями не заявлена такая необходимость. Особенно с сильно формализованными и глубоко проработанными.
Во-первых потому, что без опыта налажаете. Во-вторых, потому, что "первые лица" в нотациях не особо разбираются, что приведет либо к непониманию нарисованного, либо к дискомфорту от осознания собственной "неполноценности" (со всеми вытекающими).

2. Про выбор условных обозначений. Картинка "на одном листе" должна быть понятна интуитивно. Желательно, даже дворнику. Поэтому используйте максимально простые элементы - например, подписанные прямоугольники. Или даже картинки - спросите у яндекса что-нибудь вроде "документ картинка" или "справочник иконка".

3. Визио вполне годится. Он достаточно простой, удобный, широко распространенный (в смысле, бигбосс с высокой вероятностью откроет присланный ему файл без проволочек с вызовом админа и последующим поиском дистрибутива и кряка к super-enterprise-designer-limited-edition-v3.17.02, в котором нарисована картинка).

4. Про перспективу: на мой взгляд, выбирать не надо. Почитайте про IDEF. Про UML. Про eEPC. Про [вставить свое название]. Они все чем-то хороши, чем-то - наоборот Не надо пытаться с наскоку изучить их "от и до", устройте себе обзорную экскурсию. Понимание их отличий, сильных и слабых сторон, целесообразности применения в том или ином случае придет с практикой.

341

Теория моделирования и нотации / Re: Описание процесса создания учетных записей пользователей

« : 31 Июля 2014, 18:56:11 »

Какой диаграммой лучше воспользоваться для описания вышеописанного процесса?

Неплохо будет смотреться кросс-функционалка (которая с "дорожками" по участникам) с обычными элементами блок-схемы.

342

Для всех / Re: Какие типы диаграм используются для учета расчетов со страховыми

« : 28 Июля 2014, 13:07:57 »

А также развеять идею опытных участников форума, что анализ = аналитика

Да, это тоже можно. Главное, не развеять ее у тех, кто за нее платит.

343

Для всех / Re: Какие типы диаграм используются для учета расчетов

« : 28 Июля 2014, 11:10:16 »

Эд, расскажи, как могут расчёты (выполнение математических операций над числами) могут включать в себя диаграммы.

Справедливости ради стоит заметить, что у автора речь шла про учет расчетов, а не сами расчеты. Соответственно, можно говорить о том:
- что учитываем (в виде диаграммы классов, например);
- как учитываем (статусные модели, диаграммы активностей);
- с кем и в каком порядке делимся учтенным (в жизни - протоколы взаимодействия/информобмена, в UML, наверное, последовательности).
А также:
- зачем учитываем;
- кто и как участвует в процессе (можно попробовать кейсами).
Да хоть на чем учитываем (под это дело в UML вроде бы есть диаграммы развертывания).

Так что замоделироваться можно "по самое не могу". Другое дело, что UML там не везде одинаково полезен, да и не совсем понятно, что же именно нужно начинающему аналитику (а не чего он просит). Ну, кроме как развеять идею, что UML=аналитика.

344

Работа / Re: Помогите с характеристикой работодателя

« : 23 Июля 2014, 11:13:56 »

Лично не работал. Сталкивался неоднократно "на просторах" и общался с коллегами оттуда. Последние года 2-3 из-за специфики текущей конторы слышу о них реже, так что актуальность ниженаписанного может быть не сильно высокой.

1. Компания с очень хорошим "административным ресурсом". За счет чего:
- получает довольно большое количество контрактов (иногда в областях, ей несвойственных - было бы желание).
- в порядке вещей нагибает и кидает конкурентов и временных союзников.
- не сильно беспокоится (организационно и материально) о персонале: даже если напортачат, этап "закроют" в силу п.1.

2. Отзывы коллег:
- зарплаты посредственные;
- присутствуют переработки, включая выходные;
- присутствуют внезапные скачки из одной предметной области в другую;
- общее качество результатов работы - удовлетворительное.

По последним трем подпунктам п.2 не сказал бы, что у других крупных интеграторов-разработчиков картина заметно отличается.

Если подходить с позиций "тяжело в учении, легко в бою" - весьма неплохая контора для "начинающего специалиста". Скучно вряд ли будет.

345

Примеры / Re: Диаграмма классов - подкорректируйте\ подскажите

« : 11 Июля 2014, 15:00:06 »

быть может в связи страхуемый - клиент, страхуемый - справочники добавить интерфейс чтоб показать что это скорее получение полей

Я бы не стал. Не надо пытаться засунуть действия в ER-диаграмму, фигня получится. Я бы предложил:

1. Если данные подтягиваются откуда-то извне, и затем раскладываются в местное хранилище - лучше изобразить полноценными классами.
2. Если данные в свою систему не сохраняются, а просто устанавливается связь с внешним объектом (хранится только ссылка) - у себя рисуем "свернутый" (без атрибутов) класс и посылаем читателя туда, где этот класс описан. Это избавит от массы потенциальных граблей с актуализацией (в т.ч. на этапе сдачи работы).
2а. Если настолько лаконично, как в п.2, никак нельзя, то в класс включаем только критичные для нас атрибуты, остальное - в виде троеточия. И посылаем.

Как такой подход соотносится с расовой чистотой UML - понятия не имею, тут кто-нибудь подскажет. Но работает.

для договора это просто поля в случае клиента уже заполненные(инфо из базы), в случае справочника пустые... как это показать?

Этого здесь не требуется показывать. Ну, если очень хочется - можно поиграть связями. Показать, например, что физик, юрик и объект связаны с договором в виде [1 - 0..1]. А уж в каком случае и как - это вопрос процессов.