Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Наталья Желнова

Страницы: « 1 2 3 »
16
Ну, МГТУ в ДВОЙКУ ведущих вузов не входит, факт.

Работодатель ищет прежде всего тех людей, чей менталитет ему ближе - немудрено, что ребята из МГУ и МФТИ ориентируются на свой вуз.

Про МГТУ - как-то скромно, двое лучших системных программистов, которых я знала, были выпускниками МВТУ (он тогда назывался так). Не знаю, правда, как там с бизнес-аналитиками, знала только двух неплохих, но вот что бизнес-анализ - не самая сильная сторона МФТИ, это факт.

МГУ и МФТИ на самом деле довольно средне уживаются в одном коллективе. МИФИ и МГУ гораздо лучше и дольше живут и работают вместе, как показывает мой опыт.

Но МИФИ и МФТИ я бы не стала заставлять работать в одной команде - ничего хорошего из этого пока не получалось.

17
видимо это вот этот курс: http://www.russee.com/index.phtml?aid=50020627
Не совсем.
Вот общая программа: http://www.russee.com/index.phtml?cid=5020176
И вот краткое содержание курса: http://www.russee.com/index.phtml?cid=25020329

18
Что-то анкеты я не увидел там
Действительно. Когда-то там была анкета, и некоторые из моих бывших коллег её заполняли. Анкета была какая-то не очень внятная, и меня часто спрашивали: "а что здесь писать?"
Значит, ее убрали, и это я по старой памяти. Извините.
Но можно написать напрямую Елене Арсеньевой или мне (если Елене Арсеньевой писать почему-то не хочется).

19
респект ;)
Главное - никого не бояться :)

20
А Вы там и там себе замену ищете?? :)


А у вас даются для инструкторов какие-то курсы, которые нацелены на повышения именно качеств тренера?

Извините, после редактуры стало не совсем ясно, "кто, где и когда".

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

Так что в ближайшее время мне, по-видимому, придется брать реванш в Питере...
Хотя обычно мы подбираем инструкторов так, чтобы в Питере, Минске и Киеве было хотя бы по одному человеку на курс.

Про курсы, которые нацелены на повышение именно качеств тренера врать не буду: таких курсов нет. Пока нет. Я буду работать над этим.
Но подготовка инструктора перед тренингом проводится и моральная поддержа обеспечивается.

Подготовка инструктора обычно происходит так:
1. Встреча с коллегой, который уже читал этот курс. Передача материалов курса и подробный разговор о недостатках курса. Общение с бывшим инструктором: кому, когда, зачем читали этот курс. Какие были отзывы, какие вопросы интересовали аудиторию.
2. Сбор замечаний по курсу от "новенького", ответы на вопросы.
3. Переработка и дополнение курса (если необходимо).
4. Пробное прочтение определенной главы курса в присутствии экспертной комиссии (инструкторов и руководства TEKAMA). Выбор темы, как правило, остается за экспертной комиссией.
5. В случае положительного исхода - боевое крещение.

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

И мотивация была та же, что у Вас: вспомнить старое доброе время...

О TEKAMA у меня немного неоднозначное мнение - врать не буду, скажу прямо. Логистика в последнее время бывает ниже допустимого уровня (сюда входит и своевременное предупреждение инструктора о перемене времени и места проведения курса, и техническое оснащение аудитории), но мне все-таки удавалось проводить занятия так, что даже люди из ДойчБанка с 12-летним опытом в IT-индустрии оставались довольны этим курсом.

21
А наберусь-ка я наглости и попробую найти здесь искомое.

Ищу себе замену - инструктора на курс по управлению требованиями в RUSSEE.
В связи с переходом на другую работу (с RUSSEE, тем не менее, не расстаюсь).

Идеальный кандидат должен:
  • иметь практический опыт работы системным аналитиком/старшим системным аналитиком не менее 4 лет;
  • иметь опыт анализа, разработки и управления требованиями;
  • иметь практический опыт работы с современными средствами автоматизации управления требованиями (Requisite Pro, Doors, другие системы);
  • иметь практический опыт работы с CASE-средствами.

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

На этот курс нам нужны инструкторы в Москве и Санкт-Петербурге.

Оплата зависит от квалификации инструктора, обсуждается индивидуально с менеджером по продуктам компании TEKAMA.

Способ связи: natalia.zhelnova("собачка")tekama.com

Кроме того, RUSSEE расширяет линейку продуктов и ищет инструкторов и разработчиков на другие курсы в рамках программ iCanegie (подробности: http://www.russee.com/index.phtml?cid=50020336) и SEP (подробности: http://www.russee.com/index.phtml?cid=5020176).

Вы можете отправить резюме на адрес job@russee.com, а можете задать вопросы мне и Елене Арсеньевой (elena.arsenieva("собачка")tekama.com), менеджеру по продуктам компании TEKAMA.

Заранее спасибо!

22
Хм ... писать на таком RAD как Delphi (интересно, а он лицензионный? ... я уж про BPWin, ErWin и Rose и спрашивать боюсь :-)) и активно использовать UML ... хотел бы я взглянуть как это происходит, а то есть сомнения ...

В Тройке-Диалог в конце незабываемых 1990-х использовался RAD - правда, не Delphi, а Power Builder.
Но UML они использовали активно при этом. Причем не совсем на детском уровне.

23
Да у них есть академическая версия - что-то около 60 или 100 баков.
О, как интересно. А в чем ограничения академической версии? Например, у Microsoft многие академические версии - это те же trials, только без ограничений по сроку использования. Что просто ужасно: те же глюки - но за деньги! Нет слов.

Вообще у меня идея: для покупки можно найти Спонсора.
Я поговорю со своими спонсорами :)
Они меня кормят-поят, холят и денег дают (правда, за работу, не просто так) на протяжении уже долгих лет... Так неужели ж не потратятся на благие и высокие цели?

24
Для меня это важно было для того, чтобы получить сквозную модель требований и архитектуры. Когда все слои от ключевых проблем пользователей до архитектурных элементов лежат в одной модели и там же провязаны трассировками.
Сейчас трассировка (технически) - не проблема, даже если мы используем разные инструменты для моделирования бизнес-процессов и архитектуры. Telelogic и IBM это делают, насчет остальных - сама не пробовала, но подозреваю, что тоже умеют.
Что конкретно использовать - думаю, здесь просто нужно посмотреть, что будет удобнее. И к чему привыкла Ваша команда. Потому что переходить от одного инструмента для моделирования к другому нужно все-таки не потому, что "так хочется" или "кто-то считает это более прогрессивным", а после:
* детальной проработки требований к этому инструменту (т.е. формулирования принципа, "почему нам без этого не обойтись")
* обучения всех участников процесса работе с этим инструментом.
* выполнения как минимум одного пилотного проекта с использованием этого инструментария.

25
По всем пунктам - уточнения:
IDEF и CASE - разные вещи. :-)
SADT и CASE - тоже. :-) SADT - это всего лишь "идеологическая основа" для IDEF, насколько я понимаю.
1-я редакция IDEF0 - начало 80-х, а не 90-х. В это время люди еще вовсю на FORTRAN'е писали. Не все, конечно, но многие. Например, в CERN "официальным языком" той поры был FORTRAN :-) А у некоторых прихвостней Западапрогрессивных организаций в ходу был ANSI C.
Сейчас, конечно, все перешли на C++. Даже те, кто не смог освоить C++, оставили FORTRAN и пишут на ANSI C. Ну или на Java, на худой конец.
Маклаков - умный дядька. Я тоже часто так делаю (о чем, собственно, и речь была в начале).
Про UML в описании БП - ну, я не спорю, при помощи универсального, мощного языка пожно описать все что угодно.
Но
бизнес-модель включает в себя следующие ключевые компоненты
* бизнес-функции, описывающие, ЧТО делает бизнес;
* бизнес-процессы, описывающие, КАК предприятие выполняет свои бизнес-функции;
* организационную структуру, определяющую, ГДЕ исполняются бизнес-функции и бизнес-процессы;
* фазы, определяющие, КОГДА (в какой последовательности) должны быть внедрены те или иные бизнес-функции;
* роли, определяющие, КТО исполняет бизнес-процессы;
* правила, определяющие связь между ЧТО, КАК, ГДЕ, КОГДА и КТО.
Для описания БП необходимо включить в модель бизнес-процессов следующие атрибуты процессов:
* воздействия, инициирующие каждый шаг бизнес-процесса;
* исполнителей каждого шага;
* воздействия, регламентирующие данный шаг;
* результат, получаемый на выходе конкретного шага бизнес-процесса.

Если пункт второй (исполнители) с грехом пополам еще можно нарисовать в UML, то что делать с остальными - непонятно.
А вот в IDEF0 с ними ясно, что делать.


26
Я относился к SEO в нашем случае скептически, пока не увидел, что ресурс по поисковому слову "UML" - 7-й в Яндексе и 103-й в Гугле.

Pagerank надо поднимать, методы озвучивать пока не буду.
Зарегистрироваться на Google AdSense.
И будет Счастье.
Google всем, кто активно участвует в этом жутком деле, автоматически сильно повышает PageRank. Оно и понятно - надо же на чем-то деньги зарабатывать.

27
А есть возможность увидеть где-нибудь спецификации всех этих IDEFX? А то я маньяк-коллекционер :-)
Спецификации IDEF(0-3) - в архиве в PDF на той странице, которая явилась поводом для дебатов. Ссылка под названием "Текст стандартов IDEF".
Насчет всех - пока не знаю.

28
А как тогда понимать IDEF4 - Object-Oriented Design, IDEF10 - Implementation Architecture Modeling, IDEF11 - Information Artifact Modeling, IDEF12 - Organization Modeling, IDEF13 - Three Schema Mapping Design, IDEF14 - Network Design?
А вот для всего этого (с 4-го по 14-й) и существует UML :-)
За исключением User Interface Modeling.
IDEF4 - схемы получились очень поверхностными. На них не отображается некоторая существенная и важная для разработчика часть информации, которая отображается на диаграммах классов в UML и на диаграммах последовательностей (инициализация объекта). Кроме того, некоторые вещи разбиты на 4 разных вида диаграмм в IDEF4. Это сколько же времени нужно потратить, сколько листов бумаги перевернуть... IMHO, "слишком много букафф" - это тоже не есть хорошо. Информация должна подаваться в концентрированном виде.
И потом, опять же, рассеивать информацию по 10 разным видам диаграмм или попытаться собрать ее  в 4-х или 5-ти видах - есть разница, правда?
Словом, все, что выше 3-ки в IDEF - довольно тяжеловесно.
Поэтому Буч, Рембо и Якобсон не зря потратили свое время. Кстати, одним из самых выдающихся ходов в UML я считаю разделение диаграмм на статические и динамические. На динамических в концентрированном виде преподносится все то, что мы хотели бы узнать о поведении модели.
В IDEF же, мне кажется, несколько наивный подход: есть такая вещь как классы - рисуем классы. Есть такая вещь как методы - рисуем методы. А есть аргументы - рисуем и их. На разных диаграммах, причем. Это как раз то, что в первую очередь может прийти в голову человеку с аналитическим складом ума.
А вот у создателей UML, как мне кажется, все-таки преобладает синтетическое мышление.

29
Я ограничусь ответом только на самую существенную часть Вашего вопроса, которая показалась мне наиболее интересной:
"Может просто не повезло IDEF? Появился UML и другие передовые нотации, в этом может дело?"
Нет. UML - не замена IDEF, и он не "более прогрессивен".
Просто у IDEF и UML - разные задачи. IDEF - это функциональный подход. В фокусе процесс, а не объект (за исключением разве что IDEF1x). Понятно, что для проектирования системной архитектуры такой подход мало пригоден. Но для того, скажем, чтобы быстро оценить масштабы разрабатываемой системы (понять, что туда входит, а что остается за кадром), выделить ее основные функции, проследить связи между ними, определить, какие ресурсы при этом используются и какие ограничения ставятся, оптимизировать процессы прежде чем приступать к проектированию системы - IDEF незаменим (особенно в коллективной работе).
Это первый этап анализа. Архитектура системы здесь остается за рамками модели, причем она совершенно осознанно остается за рамками.
Далее, не всегда функциональное моделирование имеет перед собой цель создать какую-то информационную систему. Возможно, мы всего лишь решили повысить эффективность работы какого-либо бизнес-подразделения, оптимизировав бизнес-процессы - например, исключив лишние операции, разбив один сложный и запутанный процесс на несколько простых, объединив используемые источники данных по принципу общих потребителей и общей информации, которая им необходима, и т.д. Во всех этих случаях нам может помочь IDEF.
Когда мы переходим к проектированию системы, в фокусе уже не процессы, а объекты и взаимодействия между ними. UML возник тогда, когда объектно-ориентированный подход к программированию стал нормой, и предназначен именно для того, чтобы строить архитектурные модели. Использовать его в каких-то других целях, наверное, можно, но лично мне представляется нецелесообразным.
Я видела, разумеется, попытки использовать UML (точнее, Use Cases) для функционального описания системы, но...
В фокусе Use Case - не функция. В фокусе Use Case - цель, ради которой выполняется то-то и то-то. Попытки подменить одно другим, как правило, приводят к очень печальному результату.

30
Это как? Просто я темный в этих вопросах, откуда доход пойдет?
Извините, у меня сегодня был очень тяжелый (напряженный, в смысле) рабочий день :-)
Поэтому я ограничусь примитивным ответом: Google AdSense - там в общем-то все достаточно подробно описано (на мой взгляд).
Соль в том, что Google платит деньги за контекстную рекламу, которую он размещает на сайтах, зарегистрированных в Google AdSense - сети контекстной рекламы.
Проявляется это в следующем: только пользователь Интернет, скажем, решил развеяться, посетив сайт www.love.ru - Google AdSense тут же показывает ему на той странице, которую он просматривает, кузькину мать в кружевных панталонахнесколько ссылок, тематика которых близка к ключевому слову love - ссылки ведут на сайты "облегченные развлечения", "досуг в Москве", "VIP-знакомства", "свахи 24х7", "Бог любит тебя" и т.д.
На авто-сайтах - показывают рекламу (ссылки, разумеется, а не баннеры) про "самые выгодные кредиты на автомобили", "магазин автозапчастей", "моторное масло online" и т.д.; на сайтах, посвященных обзорам финансовых рынков, - "кредиты для Вас", "ипотека - дешевле не бывает" и "полноценное финансовое образование за 22,5 часа". Ну и в общем, все примерно в том же духе.
Разумеется, такое случается только при посещении тех страниц и сайтов, которые "включились" в AdSense. При этом страницы этих сайтов не содержат статических ссылок на рекламируемые компании/сервисы. Ссылки Google добавляет динамически на основании тех ключевых слов, которые указал владелец сайта, и тех, которые встречаются в индексированном содержимом этого сайта.
Google платит деньги владельцам этих сайтов за показ своей рекламы. Деньги перечисляются на указанный при регистрации (как правило, виртуальный - т.е. webmoney) счет - или выписываются чеки, насколько я  помню.
В свою очередь, самому Google платят деньги те, кто рекламирует свои товары и услуги (т.е. владельцы бизнесов "облегченные развлечения", "досуг в Москве", "VIP-знакомства", "свахи 24х7", "Бог любит тебя" и далее по списку).
Разница между тем, сколько Google берет с рекламодателя, и сколько он выплачивает тому владельцу сайта, на котором показывается реклама, составляет прибыль Google от контекстной рекламы. Да-да, именно "на эти 2%" Google и живет :-)

Страницы: « 1 2 3 »