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

×


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

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


Сообщения - Григорий Печенкин

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »
271
А вот и хроника с первой конференции. Много кто может себя узнать.
http://youtu.be/ItViqGb-qyk

"Аналитик не может причинить вред организации или своим бездействием допустить, чтобы ей был причинён вред. Но вместо него это сделал Дмитрий Безуглый." :)

272
90% аналитиков - женщины, 90%  разработчиков - мужчины

А откуда эта цифра? Мне всегда казалось, что среди аналитиков мужчин больше. Есть какая-нибудь статистика?

273
Ну вот и тема сформулировалась: "Что скрывается за ГОСТами?" :)

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

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

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


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

275
UML SysML и пр. / Re: В каких случаях UML вреден?
« : 19 Февраля 2013, 22:33:05 »
А чем вам не нравится UML? Может мы докажем или не докажем теорему от противного (ну мы все типа Uml lovers) ;)

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

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

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

Спецификация языка разбухла уже до двух книг суммарным объёмом больше чем в 1000 страниц. Это делает его очень узкоспециализированным. Я думаю, применимость UML как формального языка, нотацию которого нужно специально изучать и строго соблюдать, очень ограничена.

Лично я использую названия диаграмм из UML, никогда фактически не соблюдая нотацию. Для меня UML - это прежде всего способ обмена информацией между людьми. Удачные (с моей точки зрения, конечно) элементы я использую, а неудачные игнорирую.

276
14 дней - это очень мало для ознакомления с СУТ. Ознакомительную лицензию можно при необходимости продлевать?

277
В данном случае, материаловедение как часть инженерной подготовки. Любая ИС содержит разные компоненты, в том числе и материальные, видимо данный вуз считает такую подготовку важной. Я думаю это очень ознакомительный курс в данном случае.
Есть у меня еще подозрение, что это еще и политический ход, чтобы специальность ни каким боком не попала в раздел гуманитарных или экономических.

Я посмотрел сайт университета. Там например есть специальность информационные системы и технологии в металлургии. Казалось бы какая связь :)

Нам читали довольно много дисциплин из радиоэлектроники и радиолокации, просто потому что формально наша группа "мат. обеспечение АСУ" входила в состав факультета радиоэлектронного оборудования.

А в академии Жуковского группа аналогичной специальности относилась к факультету авиационного обрудования, и им, наверное, поэтому приходилось изучать гидравлику, пневаматику и электротехнику.

278
Учусь в институте на специальности 'Системный анализ и управление' и ощущаю, что дисциплины, которые преподаются на этой специальности, больше относятся к математическому моделированию и научно-исследовательской деятельности в области исследования операций, оптимизации, теории принятия решений и т.д., чем к тому системному анализу, который рассматривается как один из этапов ЖЦ ПО.

На мой непрофессиональный взгляд 'Программная инженерия' дает лучшую базу для будущего развития в профессии системного аналитика. Как вы думаете? Стоит в этой ситуации заморачиваться (пока не поздно - 2-й курс) с переводом на другую специальность?


Однозначно лучшую, если вы собираетесь быть системным аналитиком в IT. Я до сих пор не понимаю сферу применения той науки, которую в ВУЗах называют "системным анализом".

279
Я готова обсуждать эти вопросы лично, но не на форуме, по многим причинам, первая которых - ограниченные возможности среды для организации конструктивного продолжительного диалога.
Будете в Питере - заходите на чай, если интересно пообщаться. Будем рады Вас видеть.

А на Analyst Days не планируете быть?
http://it-conf.ru/ru/content/597.htm

280

Для меня Wiki всегда означало Википедия :)
Можно поподробнее что за зверь, полное название или ссылку какую?

Здесь сборка движка MediaWiki, которую развивают в компании Заказные ИнформСистемы (CustIS): http://wiki.4intra.net/Mediawiki4Intranet

Сам сайт wiki.4intra.net построен на этом движке, так что можно посмотреть, как это выглядит, не отходя от кассы.
Сборка включает множество дополнений, облегчающих разработку требований в среде wiki.

281
На данный момент используемый инструментарий - Visio + Word + Excel (спасибо тебе Мелкософт), поверхностные знания методологий и нотаций, опыт написания спецификаций в больших и малых интеграторах с полным или частичным бардаком в орг структуре и процессе разработки требований, да и ПО.

На данный момент пришло понимание, что нужно мне:
- Case средство (Наверно ЕА)
- Средство управления требованиями (Наверно R Requisite)
- Нужно чтобы они были в первую очередь популярными и во вторую попроще осваиваемыми.
- Может быть я еще не пришел к чему-то еще ? Может есть еще какие-то автоматизаторы, улучшайзеры и т.п.? (ну учитывая мой "стартап")


Для управления требованиями рекомендую Team Foundation Server. Это средство командной работы, вокруг которого можно выстраивать все процессы, связанные с управлением требованиями: http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx

Можно попробовать бесплатно в облаке, вообще ничего не устанавливая: http://habrahabr.ru/company/microsoft/blog/157009/

Для собственной установки есть бесплатная редакция TFS Express, но сильно урезанная в возможностях. В частности, нет интегрированного SharePoint, который удобен для организации хранения уже наработанных документов MS Office.


282
Так что тогда, 29-30 июня?

283
С датами проведения, мне почему-то больше нравится начало июля, хотя этому периоду присущи недостатки - начинается высокий сезон. Но плюсов для меня больше - начинается отпуск, а 22-23 всякие ГЭКи, ГАКи, и экзамены, да и вероятность того, что будет теплее. С другой стороны конец июня уже становится традиционным (что-то вроде предпоследней недели июня?)

Вариант: 29-30 июня. Правда, в конце июня уже начинаются массовые отпуска. Но важно застолбить дату как можно раньше.

284
Мои предложения в формате "критикую и предлагаю".

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

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

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

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

4. Предлагаю выбрать 3 объединяющих темы для выступлений, по одной для каждого потока (я надеюсь, что нам удастся организовать три потока, как в прошлом году).
Определить конечную дату сбора предложений по темам: 3 февраля (недели должно хватить), после чего запустить голосование ещё на неделю для выбора самых популярных тем. При соблюдении этих сроков 10 февраля мы сможем бросить клич для приёма заявок на доклады.

5. Дату проведения фестиваля предлагаю определить прямо сейчас, и потом её не менять. В прошлом году мы выбрали дату довольно поздно, когда у многих на это время уже были составлены планы на отпуск. Моё предложение: 22-23 июня.


Предлагаю для включения в список для голосования такие темы.

1) Практики разработки и управления требованиями в интернет-проектах - обмен реальным опытом. (Я всё больше склоняюсь ко мнению, что "традиционный" системный анализ по Вигерсу и Коберну ориентирован на модель автоматизации деятельности предприятий, характерную для Серьёзного Бизнеса aka enterprise. В интернете проекты уже не менее серьёзные, но работа с требованиями в них организована как-то по-другому.)

2) Самодельные инструменты: как мы допиливали системы работы с требованиями под наши нужды. (В мире создано много инструментов для разработки, моделирования, управления требованиями, но до сих пор нет идеального инструмента. Каждой команде приходится собирать из кубиков что-то своё.)


По результатам прошлого ЛАФ, если вы помните, мы проводили опрос: что понравилось, что не понравилось, что можно изменить. Обработанные результаты опроса у меня, ждут своего часа для предъявления орг. комитету.

285
Коллеги, покажите статистику по количеству участников прошлых фестивалей.
Три точки есть — можно строить прогноз на 4-ю.

А по какой формуле можно строить прогноз? imho на количество участников влияет слишком много факторов, чтобы строить прогнозы по предыдущим точкам.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 »