1

Сообщество Аналитиков / Re: Темы для встречи в Москве

« : 06 Марта 2013, 22:16:00 »

Согласен, велик соблазн заиграться.

2

Консалтинг и Внедрение / Re: ERP обзор

« : 06 Марта 2013, 11:04:10 »

Но в данном случае причем тут оргструктура?

Это был ответ на сообщение:

создание 3Д модели - это не управление проектом, это технология проектирования (кажется, я уже где-то как-то когда-то Вам про это писал - поищите,плиз, в анналах). оргструктура отдела, а тем более предприятия к этому не имеет никакого (справедливости ради, почти никакого) отношения.

Возможно дело в том, что Водолей имеет ввиду проектирование конструкции изделия (теория машин и механизмов, сопромат), а p_safin имел ввиду процесс управления проектом "Разработка изделия 123 и подготовка к его производству".
На этот процесс разработки и подготовки и влияет оргструктуруа предприятия. WorkFlow используется для описания этого процесса. Но также должна быть система отчетов, позволяющая проследить на каком этапе находится процесс, кто его задерживает и т.д. Это уже ближе к управлению проектами.

Нет, MES мне точно не нужна.

Все-таки, это функционал PLM-системы, MS Project здесь не будет работать, т.к. наибольший объем входной информации представляет собой состав изделия, а это основной функционал PLM/PDM. Так что, p_safin, Windchill (Teamcenter,  Enovia, ЛОЦМАН) Вам в помощь.

3

Сообщество Аналитиков / Re: Темы для встречи в Москве

« : 06 Марта 2013, 10:52:36 »

и к каким последствиям это приводит?

Когда строится уникальное здание, архитектор осуществляет авторский контроль, т.к. конечная цель связки архитектор-строители является здание для заказчика.
Разве при разработке ПО не так же? Я, конечно, понимаю про тестирование, но неужели роль аналитика заканчивается на разработке требований? Кто в итоге отвечает за пиджак? Я понимаю про "отвечает за все руководитель проекта", но, на мой взгляд, аналитик должен участвовать в приемке приложения и возможно в функциональном тестировании и разработке документации.
 

Требования и предметная модель — это разве одно и тоже?

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

Насколько выиграет? Откуда информация об этом — у вас есть опыт или читали про чужой?

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

Это гипотеза или опыт?

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

Чем это принципиально отличается от MDA (Model-Driven Architecture) и DDD (Domain Driven Design)?

Возможно ничем. Спасибо за наводку, буду читать. Почитал по диагонали, очень похоже.

«Можем разработать логически связанную структуру большого ПО» — за какое время? Откуда возьмётся информация для такой структуры?

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

Как поддерживается процесс развития системы?

Метамодель (возможно DDD и/или MDA) позволит при внесении изменений понять масштаб бедствия. Обычно такие знания находятся в голове разработчиков, заманчиво иметь хотя бы часть этих знаний "на бумаге". Соответственно, не забываем и про трассировку.

Вы с какой позиции рассуждаете — архитектора, аналитика, менеджера, заказчика, ИТ-директора?

Формально, с точки зрения аналитика. Но коллектив небольшой, роли размыты. Например, ранее часть структуры БД проектировал я, сейчас, правда, разработчики. Код я не пишу, и никогда не писал.
Хотя, на мой взгляд, вещь полезна для всех ролей разработчиков.

4

Сообщество Аналитиков / Re: Темы для встречи в Москве

« : 05 Марта 2013, 20:19:06 »

Напишите пожалуйста, какие вопросы и темы вас сейчас интересуют.

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

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

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

Тут немного расписано: http://habrahabr.ru/post/154891/.

5

Консалтинг и Внедрение / Re: ERP обзор

« : 05 Марта 2013, 19:22:08 »

Нет, MES мне точно не нужна.

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

Зачастую эта функциональность доступна в PLM-системах (например, в Windchill - ProjectLink). Однако не везде она используется из-за функциональной оргструктуры предприятия/отдела.

Вот я сейчас и ищу доступный и нужный мне инструмент.

p_safin, чем дело закончилось? За год что-то изменилось? Уж очень интересно.
Почитал тему, на мой взгляд, ваша точка зрения верна. По крайней мере, тренд на "проектное" управление КТПП наблюдается.
На предприятии есть два основных вида процессов: производственные и инжиниринговые. Целью производственных процессов является продукция. Первые автоматизируются (MRP, MRPII, ERP, just-in-time, теория ограничений), про вторые зачастую забывают.
Инжиниринговые процессы необходимы для осуществления производственных процессов, это т.н. конструкторско-технологическая подготовка производства (КТПП). В принципе, в советское время она была затронута некоторыми ГОСТами, например http://standartgost.ru/%D0%93%D0%9E%D0%A1%D0%A2%2014.004-83. Но плановая экономика не предполагала явного управление проектами (хотя графики внедрения в производство нового изделия все-таки были). В условиях рыночной экономики это жизненно необходимо для обеспечения сроков выполнения заказа и минимизации рисков вылезания из бюджета проекта.
По сути, подготовка производства - это такой же процесс, как и производственный, только выдающий в виде результата инструкции производственному процессу. Он как бы стоит на уровень выше производственного. Прямо аналогия наблюдается в виде метамоделирования, когда на выходе имеем метамодель, которая реализует  различные предметные модели.

создание 3Д модели - это не управление проектом, это технология проектирования (кажется, я уже где-то как-то когда-то Вам про это писал - поищите,плиз, в анналах). оргструктура отдела, а тем более предприятия к этому не имеет никакого (справедливости ради, почти никакого) отношения.

Все-таки оргструктура  влияет на процесс подготовки производства. Самый распространенный пример: на одних предприятиях техпроцессы разрабатывают в специальном отделе ОГТ, а потом передают технологию в цех, и далее ее не ведут, на других предприятиях технологию разрабатывают технологи, находящиеся непосредственно в цехах.
Пример WorkFlow описания подготовки производства: .

PS. Поднял старую тему, т.к. во первых интересно, а во вторых, нужно набрать 10 сообщений ))). Прошу прощения за портянку.

6

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

« : 22 Февраля 2013, 14:50:50 »

Это если система относительно простая.
В сложном инженерном ПО ради выполнения определенной задачи требуется определенная последовательность действий. Интуитивно понятный интерфейс здесь не спасет. Нужно обучение или чтение справки.

7

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

« : 22 Февраля 2013, 12:36:24 »

На самом деле в каждом релизе интерфейс хоть чуть-чуть, но меняется.
В тулбар вставили новую иконку и все, скрин не актуален.

Мы вообще, поначалу, из-за неопытности в заголовке формы вставляли версию продукта, что означало переделку всех картинок.
Но даже без заголовка формы в новом релизе (выходит обычно раз в год) писателем переделывается 80-90% скринов.

Сейчас глянул справку EA, наобум смотрю раздел "Create Project Scenario". Полных скринов формы нет, только часть  меню с командой "New Project". Вообще побегав бегло по разделам справки EA, скринов формы вообще не нашел. Диаграмм много, кусочки меню есть, но полных картинок нет. Тертые ребята, минимизируют издержки.

8

Управление Проектом / Re: Может ли менеджер IT проектов успешно управлять проектом, не зная самого ПО?

« : 22 Февраля 2013, 11:02:33 »

Больная тема в нашем обществе.
Слушал пару лет назад интервью Рошаля, в котором он костил Голикову. По его словам министром здравоохранения должен быть в первую очередь врач, а во вторую менеджер. Т.е. более правильно, если врач переучится на менеджера, а не наоборот. Рошаль, кстати, упоминал и Глушко, и Королева, и всех министров здравоохранения (все, кроме Голиковой были ранее врачами).

На мой взгляд, управленец должен знать предметную область. Он ее, кстати, и будет изучать, хочет он этого или нет. Есть же устоявшееся мнение, что менеджер становится хорошим менеджером за 7 лет работы. Так что, Elf, надо просто подождать ))). А пока что "...и планы проектов буду заполнять я...".

Есть практика, когда управленец, не знающий предметку, работает в паре с techleader'ом (по сути, главным инженером), который отвечает только за технику. Управленец - за сроки, ресурсы и финансы.

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

Но бывают ситуации, обратные Вашей. Например, в моей конторе руководителем проекта, можно сказать всей разработки, назначили опытного программиста, по сути разработчика.
Он в IT понимает все на 100%, в предметной области заказчика тоже разбирается прилично. В итоге получился контроль и полное отсутствие делегирования задач.
Задачи валятся подробные, вплоть до "в такой-то таблице добавить такие-то записи". Так тоже работать не комфортно, хотя  "работодатель оплачивает ваше время", люди не хотят работать винтиками.

Сложно в такой ситуации что-либо советовать. Возможно, нужно "подождать 7 лет", хотя какой МП работает столько на одном месте, у них ведь основная мотивация - карьерный рост.
Скорее всего, нужно поднимать вопрос перед руководством о роли techleader'а в дополнении к МП. Elf, ведь вы по сути выполняете эту роль, т.е. работаете "за того парня".

PS. Если руководство ситуацию не будет решать, то возможно проще уйти. Читал у одного известного человека цитату (не помню у кого), которая мне понравилась «Если вы по-настоящему любите свою работу, будьте готовы в любой момент попросить расчет». Основная идея - уметь отстаивать свою позицию.

9

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

« : 21 Февраля 2013, 22:11:24 »

У таких контор другая проблема - мультиязычная справка и ее обновление при каждом релизе.
Я вот заметил такую тенденцию - чем больше пользователей продукта и если они разговаривают на разных языках, тем скуднее справка. Смотрю chm-справку отечественной CAD-системы - все расписано достаточно подробно, много скринов и примеров (хотя в этом случае много не бывает). Смотрю on-line справку импортной аналогичной системы (объемы продаж отличаются на порядки) -  написано мало, ни одного лишнего слова, скриншотов нет (еще бы, иначе их придется обновлять в каждом релизе). Или они минимизируют затраты на документирование, либо таким образом кормят своих дилеров.

PS. Наверное по этим же причинам не очень распространена справка в виде видеороликов.

10

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

« : 21 Февраля 2013, 13:43:30 »

* AuthorIT - очень хорошо стоит
* Robohelp - хорошо стоит

Это сложные пакеты для разработки доки. Основная их идея - разработка доки в специализированных редакторах, а затем импорт в PDF, CHM, HTML.
Macrobject Help Authoring Suite (бывший Word-2-CHM) работает как простой конвертор:
1. разрабатываем в Word обычную доку, используем заголовки, перекрестные ссылки, картинки вставляем как обычно, без сохранения отдельно на диске.
2. запускаем конвертор, который из doc файла сделает chm и/или html, при этом сгенерируется файл с номерами топиков (топики соответствуют заголовкам в word), которые прописываются в коде для вызова справки в нужном месте. 

PS. Покупали через софтлайн, за сумму 50-100$, точно не помню.

11

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

« : 19 Февраля 2013, 20:19:40 »

На прошлой работе пользовался Macrobject Help Authoring Suite.
Стоит недорого, экономит кучу времени. Написав один документ в  MS Word, получаем PDF-руководство и chm-справку. По идее это разные документы, но ради экономии, на мой взгляд, подойдет один документ на обе роли.
Умеет генерировать chm и/или html, в зависимости от конфигурации программы, подробнее здесь: http://www.macrobject.com/products.htm.