1

Примеры / Re: СКУД в школе

« : 22 Ноября 2013, 17:59:41 »

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

Прошу не путать активити и ДВИ. Использовать разную детализацию в разных диаграммах не преступление. Кроме этого, можно показать на активити диаграмме взаимодействие между компонентами системы, это даст представление о том, что происходит в целом, откуда какие отказы появляются. Например на диаграмме уважаемого DEEPshadow не показан случай, когда карту не удалось считать, кто из вас ни разу не прикладывал не ту карту в метро или не пытался открыть дверь неправильным магнитным ключом?

Это не вопрос детализации, а вопрос замусоривания диаграммы неспецифическими для неё элементами. Use Case модель это способ представления функциональных требований к системе. Зачем на диаграмме нужны лишние экторы или ВИ если они не будут реализованы в системе?

Снова, при чем здесь UC и варианты использования?

Из книги G. Booch, J. Rumbaugh, and I. Jacobson, 1998. UML User Guide:
"A language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system"
Этим авторам я больше верю.

Не вижу противоречия =) Модель, написанная на языке UML для всего этого и предназначена. А вообще я больше верю своим глазам, чем авторам, какими бы именитыми они не были. И какой бы хорошей не была задумка, когда начинали разрабатывать сам язык UML, он сейчас используется иначе.

Что по Вашему "Малая часть UML" и "узкоспециализированный контекст"? Я лишь говорил о том, что у Коберна сама система упоминается как действующее лицо, но разрабатывамая система не является эктором и не отображается на диаграмме ВИ.
Цитата из RUP про эктора: "This artifact defines a coherent set of roles that users of the system can play when interacting with it"
То есть по определению сама система не является эктором.

Прошу указать мне место, где я на диаграмме ВИ предлагаю использовать эктора "Система". Я считаю это большой проблемой аналитиков, зашоренность во взглядах: Если UML, то обязательно ДВИ и фиксация и выявление требований. Применяется UML для описания системы в целом. Есть замечательная книжка Uml 2 and unified process, в котором описано применение UML на всех стадиях разработки ПО, а не только при анализе, надеюсь ее прочтение расширит кругозор.

2

Примеры / Re: СКУД в школе

« : 19 Ноября 2013, 13:59:10 »

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

В задании четко поставлена задача - описать процесс получения доступа в виде активити диаграммы. У приведенных мной сущностей есть состояния действий, которые можно отобразить на диаграмме. Тогда почему, в данном контексте нельзя на диаграмме отобразить их на отдельных дорожках?
Напоминаю:
 - Конечная цель - не создать модель всей системы в целом (кроме определения main use cases), а выполнить конкретные задания курсового.
 - Детализация может быть разной в разных диаграммах, в зависимости от цели создания конкретной модели.
 - UML - не язык сбора и фиксирования требований, а язык моделирования, а модель может отражать часть требований к системе, но никак не наоброт.
 - Главная цель UML (то, во что она со временем вылилась, и единственная реальная, которую я встречал в жизни) - это обеспечение одинакового понимания задачи всей командой проекта. Соответственно, отойдя от Коберна и компании, которые используют лишь малую часть UML в очень ускоспециализированном контексте, прошу указать мне, чем мое предложение по реализации Активити диаграммы плохо?
Прошу поправить меня, если я не прав, заранее спасибо.

3

Примеры / Re: СКУД в школе

« : 19 Ноября 2013, 01:14:46 »

Народ, опомнитесь! Что ж вы делаете с бедным студентом!? =)

Итак, начну с общего - модель всегда должна соответствовать цели ее создания. Цель, если я правильно ее понимаю, продемонстрировать знание нотации UML и понимание ее роли при проектировании ПО.


Исходя из данной цели, предлагаю пройтись по заданию:

1. Создать activity diagram для описания что произойдет когда кто нибудь попробует получить доступ к одной из зон школы, которая оснащена свайп карт ридером.

Для именно этого кейса, исходя из цели моделирования, правильно будет определить 4 действующих лица:

• Субъект, пытающийся получить доступ
• Карт ридер
• Система
• Дверь (турникет и т.п.)

Соответственно необходимо создать 4 дорожки, в которой описать действия каждого из акторов данного кейса в четком следовании нотации UML.

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

2. Предоставить use case model для NSAC системы описываемой сценарии из 1 сообщения.
  а. Определить main use cases
  b. Предоставить use case diagram. Она должна включать систему, actors, use cases а так же внутренние и внешние связи (include, extend), так же как и use case and/or actor generalisation в вашей диаграмме.
  с. Разработать use case спецификации описывающий процесс когда свайп карта была создана для нового сотрудника, который устроился в школу. Если ваша диаграмма содержит больше чем 1 use case для достижения требуемого, тогда опишите для всех их. Это означает, что вы должны описать внешние и внутренние use cases.

Тут сообщество уже дало много хороших рекомендаций. Вопрос на засыпку: я правильно понимаю из диаграммы, что HR и Security не являются сотрудниками школы, и доступ им никуда не нужен?

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

3. Разработайте class diagram для вашей системы. Включая атрибуты, операторы, ассоциации, множественность (miltiplicities).

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

По текущей диаграмме очень много замечаний. Советую вслух проговорить все что описано на диаграмме, с учетом формальности языка. Например 2 класса сверху слева: У каждой персоны может быть 1 карта. У каждой карты есть от 1 до бесконечности владельцев (бред!).

Не забудь о том, что записи можно изменять, а не только создавать и удалять. Добавь CRUD для карт. Точка доступа это сама дверь или карт ридер?? Где логи? Слишком мудришь с сотрудниками и студентами (пытаешься сразу объять необъятное), лучше оставить только класс Persona, и перенести в нее атрибут privilege level - сотрудник, школьник и т.п.

4

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 08 Августа 2013, 14:02:02 »

Я считаю, что скорее объект автоматизации включает в себя АС, при этом сам видоизменяясь.

Возьмем, для примера автоматизацию процесса ведения документооборота в организации.

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

Как правило, при написании ТЗ, автоматизируемые процессы сразу описываются "как будет", основываясь на процессах "как есть", но не анализируя их. Так же редко учитывается переход с существующих на видоизмененные бизнес-процессы, что приводит к различным проблемам на этапе внедрения, не связанным напрямую с АС (например принтер, которые печатает штрих-коды, наклеиваемые на входящие документы, один на 2 обособленных здания и на 20 человек). В наших реалиях, стадию бизнес анализа часто пропускают, просто ставится задача - цель разработки системы, и разработчики, вместе с аналитиками сломя голову бегут ее решать. Понятно, что это само по себе проблема, и на бизнес анализ почти никто, по моему опыту, не выделяет ни средств ни времени... В общем, все печально =)

5

Примеры / Re: Как на диаграмме Последовательности описать независимый от основного процесс?

« : 05 Августа 2013, 13:54:11 »

Ну так вот, процесса «мониторинга готовности паспорта» не должно быть в принципе, т.к. это пустая потеря времени, а должно быть информирование о статусе по смс или электропочте.

От мониторинга готовности паспорта нельзя отказаться по ряду причин:
1. Сменился номер телефона
2. Забыл пароль почты
3. Сбой при доставки письма/СМС
4. Большая протяженность по времени (сколько можно будет дожидаться ответа на запрос от ФОИВ?).
  а. Можно уведомлять о промежуточных статусах (анкета получена, анкета проверена, подтверждение личных данных запрошено, паспорт изготавливается, паспорт готов) но это лишний спам.
  б. Не учитываются возможные сбои ПО и снижается контроль со стороны получателя услуги.
И можно еще кучу причин придумать. Оповещение может быть лишь как впомогательная функция.

По теме согласен с отписавшмися ранее, можно описать словами.

6

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 02 Августа 2013, 17:57:02 »

У меня аналогично, когда объект называют процессом. Дайте определение для "объекта" и "процесса", чтоб у нас не было разногласий.

Я не объект называю процессом, а наоборот, процесс объектом, что вполне допустимо:

Объект управления — обобщающий термин кибернетики и теории автоматического управления, обозначающий устройство или динамический процесс, управление поведением которого является целью создания системы автоматического управления.

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

7

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 01 Августа 2013, 12:48:38 »

"Усложнять просто, упрощать сложно" (с). Я не очень понял в чем несогласие? Вы просто взяли и раздвинули рамки (границы) системы. С таким же успехом, можно взять отрасль в целом ... и что, высказывать несогласие с вашим примером?

В том то и разница подхода, я не раздвинул рамки системы, система осталась прежней - автоматизация деятельности дровосека. Проблема в том, что отписавшиеся ранее смотрели на сферического дровосека в вакууме, потому и были разногласия в определениях, каждый видит абстрактную деятельность дровосека по своему. Я лишь сначала описал контекст, и откуда вытекла цель системы и показал общую иерархию "Цель->Задачи->Назначение->Функции->Работы". И если применить бесконечное количество вопросов "Зачем?" к любому звену из этой цепи, мы выйдем на чуть ли не единственную цель любой коммерческой организации - получение прибыли.
При этом цель - повышение выработки леса за смену далеко не самая лучшая, ведь можно повысить выработку, получив худшего качества древесину, затратив море денег на саму автоматизацию и расходники и в итоге оказаться в минусе. Можно было бы сформулировать цели следующим образом:
- Повышение дохода от деятельности дровосека 20% (при этом надо определить критерии оценки)
- Ускорить окупаемость разработки нового участка леса с 4 до 3 месяцев
- и т.п.

Кроме этого, у меня возникает жуткий батхерт, когда объектом автоматизации называют какую-то сущность, а не процесс, в данном случае дровосека а не процесс добычи дерева.
На нашем примере объект автоматизации - процесс рубки деревьев.
Допустим раньше дровосек забирался на дерево, садился с топором на ветку и обрубал ее, падал, залезал снова, пока все ветки не обрублены, потом уже брался за ствол. Конечная цель - получение древесины достигается.
И тут приходим мы, и организуем процесс по другому, сначала рубим ствол, потом ветки у лежащего дерева тем же топором. Вроде ничего не изменилось, а автоматизация есть, однако. При этом в 3-4 раза повышается выработка и в 1000 раз снижается травматичность.

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

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

8

Системный Анализ и Требования / Re: ТЗ по ГОСТ 34: Назначение и цели создания системы

« : 31 Июля 2013, 17:38:24 »

Немного не согласен с высказываемым в этой теме.

Для обсуждения предлагаю мою интерпретацию ситуации с дровосеком.

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

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

Соответсвенно проводится анализ проблемы (низкая производительность труда) и рассматриваются варианты ее решения:
- Автоматизация процесса рубки
- Повышение мотивации рабочих
- Снижение времени простоя рабочих
- и т.п.

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

Объектом автоматизации является процесс рубки деревьев.
Цель системы - повышение средней производительности труда лесорубов с 200 до 400 кубов за смену в течение следующих 2 месяцев.
Задача системы - рубка деревьев.
Назначение системы (та подцель или подцели, которые были выбраны) - автоматизация процесса рубки
Функции системы
- Рубка деревьев
- Заправка бензопил
- Замена расходных материалов (цепей) бензопил
- Обеспечение безопасности лесорубов
- и т.д.
Работы в рамках создания системы:
- Закупка бензопил
- Закупка средств индивидуальной безобасности
- Закупка топлива
- Закупка расходных материалов
- Обеспечение логистики СИБ, топлива, расходников
- Проведение инструктажа по безопасности
- Обучение использованию бензопил
- и т.д.

На самом деле, целей будет больше и рассматриваться система будет более глобально. Как пример дополнительной цели - снижение травматизма на производстве с 6 до 2 случаев в год в течение следующих 2 лет, и т.п.

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

Соответственно эта большая система может быть лишь частью чего-то еще более общего.

9

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

« : 28 Апреля 2012, 12:48:52 »

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

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

Т.е. в целом эти два требования так же говорят про унификацию, но размыто...

10

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

« : 28 Апреля 2012, 12:06:17 »

В зависимости от темы ТЗ нарекание вызывает только

-   должна быть удобная, интуитивно понятная навигация в интерфейсе пользователя;

Удобство и интуитивную понятность никак не измерить и не проверить. Если это важно для системы - нужно расписать, что под этим подразумевается, например:

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

11

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

« : 19 Декабря 2011, 14:23:00 »

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

12

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

« : 19 Декабря 2011, 11:08:32 »

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

13

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

« : 16 Декабря 2011, 11:41:15 »

Итак задачи, которые решала PLM система у нас (что сразу вспомнилось, уже не работаю там...):

1 Базовые задачи
 1.1 Хранение всех данных об изделии в одном месте, с организацией удобного и быстрого доступа к ним и разграничение прав доступа. Цель - сокращение затрат времени на поиск связанно й информации, обеспечение актуальности информации по всему предприятию и отсутствие дублирования хранимой информации, обеспечение доступности информации только тем лицам, которым она нужна.
 1.2 Хранение НСИ в отдельной базе. Цель - обеспечить актуальность справочной информации по предприятию (станки, инструменты, и т.п.) и по всему холдингу (стандартные изделия, материалы и т.п.).
 1.3 Хранение двухуровневой версионности файлов, с указанием статусов версий. Цель - обеспечить хранение информации по всему жизненному циклу изделия в соответствии с конструкторской документацией. Первый уровень версионности - хранение указанного количества измененных файлов, с описанием объекта, для обеспечения возможности отката на предыдущее сохранение. Второй уровень - создание модификаций (ревизий) объекта, с назначением статусов, и указанием порядковых номеров изделий, либо диапозона дат выпуска, когда действовала эта ревизия.
 1.4 Создание workflow процессов выпуска, изменения, утверждения и т.п. деталей, в соответствии с бизнес-процессами предприятия. Цель - сократить сроки согласования изменений в конструкторской и технологической документации.
 1.5 Обеспечение взаимодействия внутри холдинга. Цель - обеспечить быструю и корректную передачу актуальной информации от разработчика к подрядчикам.

2 Продвинутые задачи (доработки разной сложности)
 2.1 Выгрузка информации по конкретным экземплярамизделия. Цель - обеспечения взаимодействия со смежными системами (ERP, SCMO).
 2.2 Автоматизация формирования технологической документации, в соответствии с хранимой в системе информации. (РТК, ТП). Цель - сокращение затрат времени расчетчика и технолога на оформление результатов работы.
 2.3 Автоматизация формирования конструкторской документациии, в соответствии с хранимой в системе информации. (спецификация, чертеж, извещение об изменении, и т.п.).  Цель - сокращение затрат времени конструктора на оформление результатов работы.

3 Перспективные задачи
 3.1 Ведение проектов внутри системы.
 3.2 Ведение расцеховки в системе (было реализовано своими способами, в последней версии программы модуль manufacturing был улучшен настолько, что его для этого можно использовать)
 3.3 Хранение конфигураций изделия

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

14

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

« : 15 Декабря 2011, 18:19:11 »

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

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

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

15

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

« : 15 Декабря 2011, 17:49:40 »

Начну с конца...

Но, согласитесь, опыт практиков не всегда бывает удачным.

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

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

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

В целом все так, когда уже есть некоторое решение.
Единственное в пункте 2 идет оптимизация бизнес-процессов в Компании, потом уже их реализация в PLM системе.

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

И небольшая ремарка по 3-му пункту: Функционал хорошей PLM системы покрывает 95% потребностей почти любого предприятия. Доработки в основном касаются экранных форм, упрощения работы в системы, консолидация полученной архитектуры модели данных в самостоятельный модуль. И остается формирование отчетности. Поскольку ГОСТЫ на спецификацию, извещения об изменении и т.п. являются лишь рекомендованными - может возникнуть необходимость разрабатывать их под каждого заказчика.

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

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

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

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

По решаемым задачам - отвечу чуть позже..