Лидер в Стратегическом консалтинге
и цифровизации бизнес-процессов
Организаций Строительной отрасли
8 (800) 707-48-14

Разработка ПО под САПР. Важно знать.

Компания ПСС ГРАЙТЕК обладает более 29-летним опытом разработки ПО, в том числе 15-летним под САПР, автоматизируя и упрощая деятельность проектировщиков. Выполнили множество собственных тиражируемых программных продуктов, а также продуктов на заказ.

Данная статья рассказывает о ключевых вещах в Разработке программного обеспечения под САПР на примере Разработки плагина под систему автоматизированного проектирования.

Задача плагина под САПР

Обычно задачей плагина под САПР является автоматизирование расстановки оборудования и получение спецификации.

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

Такой плагин будет состоять из двух основных элементов:

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

Какие роли необходимы в команде Разработки ПО для реализации первой версии данного плагина и какова их загрузка?

  1. 100% – Разработчик семейств каталога продукции Заказчика.
  2. 100%–Программист, который сможет воспользоваться базой семейств и создать плагин.
  3. 50%–Тестировщик со знанием предметной области: это должен быть инженер-проектировщик конкретного раздела проектирования.
  4. 30%–Руководитель проекта для коммуникации с Заказчиком и мотивации команды.
  5. 10-30%–Дизайнер.
  6. 30%– Бизнес-аналитик, который сможет оценить требования заказчика и превратить их в техническое задание.

Можно ли объединять роли?

Можно. Это несет больше проектных рисков с точки зрения устойчивости команды на длительном промежутке времени. Однако Руководитель проекта вполне может выполнить роль и бизнес-аналитика.

Какими еще компетенциями должен обладать Руководитель проекта?

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

Пример: необходимо вывести в спецификацию крепления крышек лотков с учетом их материала.

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

Что должен сделать грамотный Руководитель проекта, осознавая это?

Руководитель проекта должен понять, можно ли, не моделируя элемент, получить его в спецификации. Вопрос заказчику на совещании: «Стандартизовано ли количество креплений для лотков?»Если оказывается, что да, тогдаможно легко посчитать количество креплений, так как каждый тип лотка имеет вполне определенное количество, и даже учесть их материал, ведь есть специальная таблица соответствия материалов крепления в зависимости от лотка.

ИТОГ: Задача перемещена от Разработчика семейств Программисту. Семейство не перегружено деталями, в спецификации присутствуют позиции креплений.

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

А) Руководитель проекта обладает навыками программирования и коммуникационными навыками для решения Задач Заказчика и мотивации команды.

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

В) Программист и Разработчик семейств обладают высоким уровнем ответственности и не бросят проект на полпути.

Г) Тестировщик понимает предметную область и то, как все должно работать.

Каковы сроки разработки первой версии плагина?

Сроки разработки первой версии варьируются от 3 до 12 месяцев при указанной выше загрузки персонала.

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

Важно помнить:

  1. Команда разработки Плагина должна быть распределена на несколько ролей и несколько человек. ИначеКомпания Заказчик и Компания Программист несут существенные ресурсные риски, особенно на длинной дистанции, встают в зависимость от одного человека.
  2. Выполнение самой простой задачи можно «случайно» заметно усложнить неэффективным путем ее реализации. Чтобы этого не допустить, должен быть опытный Руководитель проекта.
  3. Программист должен понимать, как писать код правильно, а Руководитель проекта уметь проверять. Если код написан без должного рефакторига, каждая новая функция будет занимать кучу времени для ее реализации.
  4. Не стоит забывать про коммуникации.
Автор: Балобанов П.М., Генеральный директор ПСС ГРАЙТЕК
24.05.2023
Вы можете обратиться к нам прямо сейчас:
+7 (812) 407-28-14
Или приходите к нам в гости лично!
Наш офис в Санкт-Петербурге:
Невский пр., д. 104, литера А, БЦ «Tempo», 5 этаж на карте
Вы можете обратиться к нам прямо сейчас:
+7 (495) 374-65-89
Или приходите к нам в гости лично!
Наш офис в Москве:
Вы можете обратиться к нам прямо сейчас:
+7 (383) 388-46-92
Или приходите к нам в гости лично!
Наш офис в Новосибирске: