76

Примеры / Re: Robustness Diagramm - Диаграмма пригодности(ICONIX)

« : 02 Февраля 2012, 14:32:18 »

По теме нашёл интересный документ: http://www.emapix.com/Robustness_DiagramV2.pdf

77

Sparx / Re: Тренинг по Sparx Enterprise Architect

« : 01 Февраля 2012, 20:01:40 »

Паша, а ты чего бы ожидал от треннинга по спраксу? Предложение неплохое, реализуемое.
Нужно
1. чтобы у участников были компы
2. у треннера подготовлена виртуалка или ЕА триальной версии - ставится просто, но мало ли
3. совместнная работа к сожалению исключается, больно много всякий действия и возможных неувязок, нужно найти компы объединить в сеть (будет ли на этой ЛАФ такая возможность?)

Чего бы хотелось:

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

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

Сам имею пока поверхностное представление о данном продукте, поэтому какие-либо формулировки могут быть не точными. Спасибо.

78

Sparx / Re: Тренинг по Sparx Enterprise Architect

« : 01 Февраля 2012, 14:58:12 »

Коллеги, а можно ли вынести эту тему на ЛАФ-2012? Я буду "За", даже если тренинг будет стоить каких-либо денег.

79

Методологии / Re: Зоны ответственности аналитика, архитектора и менеджера проекта.

« : 23 Января 2012, 12:18:14 »

где-то на форуме и в сети гуляет документ обязанностей и компетенций системного аналитика.

См. вложение.

80

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 20 Января 2012, 10:27:11 »

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

Марина, здравствуйте. Понял.

81

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 19 Января 2012, 00:16:26 »

Безусловно

Добавлен. Следующий на очереди - блог Натальи Желновой.

82

О Сайте и Форуме / Re: Лента внешних блогов аналитиков

« : 17 Января 2012, 11:39:47 »

Предлагаю добавить в общий фид ЖЖ Галины Карабановой: http://infiniti-gk.livejournal.com/

83

Поздравления / Re: Поздравления с Новым 2012 Годом

« : 30 Декабря 2011, 16:04:34 »

Коллеги, с наступающим!

84

Теория моделирования и нотации / Re: цветное моделирования

« : 28 Декабря 2011, 19:13:58 »

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

Для IDEF цвет вообще актуален, т.к. в огромном количестве пересекающихся стрелок можно попросту потеряться.

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

85

Методологии / Re: Методология PDM-систем; управление проектами на промышленном предприятии

« : 19 Декабря 2011, 15:33:26 »

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

Здравствуйте. Возможно, Вы правы.

В целом, Водолей, спасибо за "лекцию". Многое что для себя понял и уяснил. Просто, понятно и доходчиво.

Что касается

Мне нравится проводить аналогию проектирования к.-либо изделия с разработкой софта. тогда для технологии проектирования аналогией будет нечто вроде RUP, ресурсы и управление проектом будут иметь тот же смысл, проектная документация - соответственно, документация на софт, а модель изделия соответствует разработанному софту.
с точки зрения инструментов тоже можно провести аналогию CAD - редактор кода/RAD/компилятор и остальная шняга.
Такая схема вполне конкретно определяет место каждого компонента технологии разработки проектирования.
Но где же тут PDM/PLM? Все очень просто PDM = Source Safe.

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

86

Методологии / Re: Методология PDM-систем и управление проектами на промышленном предприятии

« : 15 Декабря 2011, 18:05:12 »

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

Собственно, так оно и есть на том же факультете самарского СГАУ.

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

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

Функционал хорошей PLM системы покрывает 95% потребностей почти любого предприятия.

А вот это для меня действительно открытие...

Тут я не соглашусь. Требования, как правило предъявляются к готовому узлу, а не к отдельным деталям, и если на проектирование детали не требуется 60+ часов, выделять ее в отдельный проект нет особого смысла... Ну и еще имеет значение возможность декомпозиция проектируемой сборки на агрегаты и узлы..

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

87

Методологии / Re: Методология PDM-систем и управление проектами на промышленном предприятии

« : 15 Декабря 2011, 17:12:03 »

Имелось в виде не управление проектами а сам процесс проектирования деталей/сборок. Процесс рекомендовался итерационный, с параллельной работой проектировщика (CAD), расчетчика (CAE), и расчетчика (CAM), для сокращения цикла производства, ну и т.д.

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

А в чем заключалась итерационность процесса: сначала создавалась первоначальная CAD-модель, потом она следовала на расчёты CAE-специалисту, а потом создавался техпроцесс в CAM-системе, затем модель дорабатывалась после прохождения этих стадий и снова проходила расчёты и доработку техпроцесса? Или как-то по-другому?

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

Собственно, вы дали ответ на мой 1-й вопрос в инициирующем сообщении этой темы. Из него можно сделать вывод, что какой-то конкретной методологии изначально в PLM/PDM-систему не заложено. Я с вами соглашусь.

То есть, первоначально можно разделить работы по проектам внедрения PLM-системы в следующем виде (глобально):

1. Аналитика процессов компании.
2. Настройка и оптимизация бизнес-процессов с помощью PLM-системы. Выяснение перечня необходимых доработок.
3. Доработка дополнительных модулей и интеграция с существующими системами (с существующим ПО). Вот здесь и можно применять методологии и средства разработки уже ПО.

В университете сложно эту тему раскрывать... У нас сотрудники преподавали в университете целиком на опыте нашего предприятия. Опять же, суть решаемых задач целиком зависит от конкретного проекта внедрения. Если интересно - могу перечислить, какие задачи решались у нас.

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

Уважаемый Tinner, спасибо за информацию. Мне интересно увидеть перечень задач, которые вы решали.

88

Методологии / Re: Методология PDM-систем и управление проектами на промышленном предприятии

« : 15 Декабря 2011, 14:55:04 »

PDM система, в которой я работал, поддерживала все стадии, от формирования требований, до сопровождения и послепродажного обслуживания. Также в самой системе были средства для организации работ по проектам - диаграммы ганта, назначение ресурсов и т.п.

Не Windchill + Pro/E случаем?

2. Да, реально, некоторые методологии даже очень близки к тем, что рекомендованы производителем системы.

А какие, например, методологии управления проектами предлагают производители систем? Как извлечь эту информацию из системы, ведь, по сути, эта информация заложена глубоко в ней, а пользователям доступны только инструкции в виде алгоритма. При этом вся суть остается не ясной.

Кстати, это на самом деле довольно большая и современная проблема. В университетах учат тыкать мышкой, выполняя какой-либо сценарий, хотя суть решаемых системой задач остается непонятной.

Коллеги, спасибо за ответы.

89

Методологии / Методология PDM-систем; управление проектами на промышленном предприятии

« : 15 Декабря 2011, 12:28:12 »

Коллеги, обращаюсь к вам с советом. Ваше мнение и советы будут очень важны и ценны для меня.

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

Мне же будут интересны следующие моменты:

1. Какие методологии и стандарты заложены в промышленные программные средства (PDM, CAD, CAE, CAM)? Больше всего, наверное, будут интересны методологии, по которым "построены" и организованы PDM-системы.

2. Реально ли использовать IT-шные принципы и методологии управления проектами в промышленности (например, для организации работы какого-либо проектного бюро по разработке какого-либо агрегата)?

Прошу поделиться опытом и своими мыслями.

Спасибо за внимание.

90

Для всех / Re: Руководство администратора: структура документа

« : 12 Декабря 2011, 14:16:26 »

Есть  такая статья

Да, спасибо.