121

Вакансии / Re: Требуется аналитик, продуктовая разработка в области трехмерной графики и CAD

« : 07 Апреля 2011, 09:10:50 »

Не очень понятно каким боком аналитик имеет отношение к следующим задачам

- Решение задач по развитию функциональности информационной системы исходя
из бизнес-требований
 - Активное участие в развитии функционала системы

Это задачи архитектора и разработчиков

- Выполнение модификаций в системе согласно ТЗ

Это задачи разработчиков

Возможно участие в качестве программиста в цикле разработки программных модулей для программной платформы. Язык C#

А еще он может на машинке крестиком вышивать...

Ни слова про требования к навыкам аналитика, владения CASE-средствами, компетенциям в области СА и БА.
Получается что вам нужен разработчик с опытом или задатками аналитика.

122

Работа / Re: Начало фрилансерской карьеры

« : 05 Апреля 2011, 16:25:17 »

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

Только вот потом у таких специалистов возможны проблемы с устройством в серьезные компании разработчики, остается только свободное плавание или переход в стан Заказчика.

123

Работа / Re: Начало карьеры биз. аналитика, как не прогадать с выбором компании?

« : 05 Апреля 2011, 16:06:25 »

Вопросы:
1) Что бы вы могли мне как молодому специалисту порекомендовать? С одной стороны у меня нету практики работы по гостам и моделям по типу UML, ARIS (т.к. внедрения для малого бизнеса обычного проще, чем кажется), с другой стороны практика работы все таки тоже имеется. Не пойму на что претендовать, то ли на должность стажера в компаниях интеграторах (скорее всего пока российских, мой английский еще не дотягивает до уровня fluent, но литературу читаю свободно да и процент понимания со слуха высокий, практики общения не хватает). Толи же пытаться пробиться на начальные должности, или быть может на должности помощника бизнес аналитика, чтобы изучить корпоративную среду и стандартные которые в ней используются.
2) Стоит ли вообще трать время на небольшие компании, которым требуются бизнес аналитики, или все же лучше порыть и попасть в большую компанию?
3) На что лучше сделать упор, на системного аналитика или же на бизнес аналитика в начале карьеры? Я понимаю что через год два работы можно переквалифицироваться. Но все же.
Последним вопросом я бы хотел у вас спросить о вашей удовлетворенности как специалистов, стоит ли тратить десятки лет на бизнес аналитику (а в дальнейшем консультировании по стратегическому развитию) ?

1. Ищите позиции стажер системного аналитика или младший аналитик в интеграторах или "внедренцах" (возможно не крупных)

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

3. Решите для себя заранее, перескочить потом из СА в БА, сбросить с себя амплуа "компьютерщика" не так то просто.
Также следует учитывать что существует путаница понятий СА и БА.
http://livehh.ru/fedorovia/entry/biznes-vs-sistemnyy-analitik-podborka

Судя вашим сообщениям Вы больше тяготеете к БА. Как вариант можно начать с СА ставя конкретную цель получить необходимые практические навыки для перехода в БА. Вашим плюсом будет то что вы понимаете как устроены ИС, как они проектируются, как организованы процессы.
http://livehh.ru/fedorovia/entry/kak-stanovyatsya-analitikami

4. IMHO - стоит. Перескочить с БА в консультанты по управлению или директором по стратегическому развитию, при наличии стремления и желания развиваться в этом направлении вполне реально.

124

Другие Методологии / Re: Методика моделирования конфигураций 1С в

« : 31 Марта 2011, 18:03:12 »

А зачем указаны зависимости между ДЛ. Не бывает зависимостей между оными. Только отношения обобщения.
К тому же почему разделяется понятие пользователь и роль? Актер - это и есть роль, на мой взгляд.

Спасибо за вопрос.
Постараюсь ответить.
Согласен что в общем случае нужно использовать отношение обобщения поскольку Пользователь наследуется возможности Ролей. Однако мне кажется что использование обобщения в этом случае не передает особый смысл связи этих двух понятий системы 1С.
В методике есть такое допущение которое говорит о том что с одной стороны Роль является сущностью относящейся к системе и в принципе не может быть отнесена к актерам, но с другой стороны сам по себе пользователь может взаимодействовать только в теми ВИ (документами) которые доступны для Роли которая ему назначена.
Одному пользователю могут быть назначены несколько Ролей, также могут быть ситуации когда есть два пользователя для которых Роли частично совпадают, поэтому я предложит отразить как актеров и пользователей и Роли и отношением зависимости показать что Пользователь зависит от Роли, то есть пользователь получает доступ к функциональности опосредованно через Роль.

125

Другие Методологии / Re: Методика моделирования конфигураций 1С в

« : 31 Марта 2011, 17:47:56 »

С ДК все понятно. А вот с ДВИ вы явно намудрили. ВИ совсем не для того, что Вы написали. И практическое применение таких ДВИ под большим вопросом.
Лучше это показать на ДК с помощью зависимости со стереотипом "trace"

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

126

Другие Методологии / Re: Методология моделирования конфигураций 1С 8 с использованием UML

« : 31 Марта 2011, 13:36:59 »

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

Спс, подправил.

127

Другие Методологии / Методика моделирования конфигураций 1С в

« : 31 Марта 2011, 10:43:13 »

Добрый день, коллеги хотел бы вынести на обсуждение методику моделирования конфигураций 1С 8 в нотации UML.

Методика разработана на основе практического опыта и систематизирована в рамках подготовки выпускной аттестационной работы.

Тезисы к выпускной работе: http://ильяфедоров.рф/ANH_ITM18_IAFedorov_Thesis.pdf
Выпускная работа: http://ильяфедоров.рф/ITMANE_ITM18_IAFedorov_DiplomPublication.pdf
Отзыв руководителя (А.В. Леоненков) на выпускную работу: http://ильяфедоров.рф/ITMANE_ITM18_Leonenkov_Otziv_For_IAFedorov.pdf
Хотел бы "услышать" Ваши комментарии, замечания, вопросы.

Спасибо.

128

Задачи студентов / Re: комплексный пример проектирования

« : 28 Марта 2011, 11:25:32 »

У меня такая проблема в Eclipse UML2 Tools. Когда на ДВИ разбиваю ВИ по пакетам. Не получается нарисовать границы системы. Когда формируется пакет с ВИ его нельзя превратить в под пакет пакета System. Там есть элемент Subsystem но туда пакеты не запихать. Как идеологически рисуются границы системы? На диаграмме ДВИ в этой теме они правильно нарисованы?

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

129

Проектирование / Re: Использование UML при проектировании задач в 1С

« : 28 Марта 2011, 09:30:03 »

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

Добрый день, коллеги.
Рискну предложить вам своё видение использования возможностей UML в проектах 1С 8.2.
Данная методика в первую очередь предназначена для аналитиков владеющих UML, но ранее не сталкивавшихся с системой 1С:Предприятие 8.*.

http://www.ильяфедоров.рф/ITMANE_ITM18_IAFedorov_DiplomPublication.pdf

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

130

Сообщество Аналитиков / Re: Ваше образование

« : 24 Марта 2011, 13:14:54 »

Интересный такой вопрос, а какое образование у форумчан?

"ПРИМАТ", МЭСИ 1998 (www.mesi.ru).
Бизнес-аналитик, менеджер проектов, АНХ 2011 (www.itmane.ru)

131

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

« : 22 Марта 2011, 11:41:58 »

А откуда мне узнать как система должна себя вести? Откуда мне знать что будет если то то?? Самому придумать из воздуха?
Или нужно ознакомиться с какой-то документацией? Может быть что-то нужно проанализировать?
Пожалуйста, помогите выбрать правильное направление.

Да если опыта нет придется придумывать из воздуха.
Проанализируйте наиболее типовые ситуации которые могут произойти, предложите способы контроля и исправления этих ситуаций.
Основные проблемы которые как правило могут возникнуть при интеграции:
- отправленные данные не дошли до системы получателя
- отправленные данные дошли не полностью или некорректно загрузились в систему получателя
- при попытке загрузке возникли коллизии (такие данные уже загружены частично или полностью)
Эти вопросы решаются путем реализации дополнительных алгоритмов контроля целостности интеграции.

132

Тестирование / Re: Тестовые примеры

« : 18 Марта 2011, 11:48:15 »

Да, конечно, первый вариант. 

Если Заказчик готов платить за это Исполнителю то почему бы и нет.
Для избежания тех ситуаций о которых упомянул Galogen, необходимо четко ограничить зону ответственности Исполнителя по данной задаче (и зафиксировать это документально в регламенте проекта):
"Задача Исполнителя предложить Заказчику методику проведения испытаний и план тестирования основанный на документации по проекту (в частности на функциональных и не функциональных требованиях)."
Но подписаться под представленным вариантом должен все таки Заказчик.

133

Примеры / Re: Диаграма класов: обработка изображения

« : 17 Марта 2011, 14:36:22 »

А стосовно остальних диаграм UML они тоже будут!!!! диаграмой класов я показую методи работи.

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

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

134

UML SysML и пр. / Re: Почему Вы используете или не используете UML?

« : 09 Марта 2011, 12:13:45 »

Предлагаю ответить всем, кто хочет высказаться по этом поводу. Ваш ответ очень ценен для меня.
Желательно указать возрастную категорию: до 20, 21-30, 31-40, 41-50 и т.д.

На предыдущей работе использовал эпизодически в основном для описания Use Cases и диаграмм деятельности верхнего уровня описывающего процесс работы пользователя в системе в рамках конкретного бизнес процесса.
На новой работе (3 месяца) использую более плотно в проекте 1С 8.
  Диаграммы анализа для выделения ролей - boundary, документов - control, справочников - entity.
  Диаграммы классов для описания объектов конфигурации и связи между ними (как прикладных так и базовых).
  Диаграммы вариантов использования для описания функциональности в рамках роли.
  Диаграммы деятельности для описания алгоритмов работы обработок (с углублением в основные процедуры и функции реализующих значимые алгоритмы).
В рамках этой деятельности и обучения в АНХ (www.itmane.ru) выбрал тему выпускной работы "Разработка методики моделирования приложений 1С для платформы 8.2 с использованием нотаций UML".
Защита в конце марта. Тезисы к работе доступны здесь http://www.ильяфедоров.рф.
Возраст: 31-40.

135

Задачи студентов / Re: комплексный пример проектирования

« : 05 Марта 2011, 09:51:19 »

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

Не правильно.
То что вы отобразили достаточно отобразить коментариями (note).
Вообще у вас названия ВИ непонятные.
Что такое прием платежей, Изменение настроек, Работа с архивом.
Нужно выразить так название чтобы было понятно какое действие или процесс в системе выполняется, чтобы была понятна цель действия и что именно делает система.

Прием платежей       -  Регистрация поступления платежей. Цель понятна - зарегистрировать платеж в системе
Изменение настроек - какая цель этого ВИ? Почему изменение настроек связано с приемом платежей, назначение связи? 
Работа с архивом     - слишком абстрактно, какая цель этого ВИ?