Компания ПСС ГРАЙТЕК обладает более 29-летним опытом разработки ПО, в том числе 15-летним под САПР, автоматизируя и упрощая деятельность проектировщиков. Выполнили множество собственных тиражируемых программных продуктов, а также продуктов на заказ.
Данная статья рассказывает о ключевых вещах в Разработке программного обеспечения под САПР на примере Разработки плагина под систему автоматизированного проектирования.
Задача плагина под САПР
Обычно задачей плагина под САПР является автоматизирование расстановки оборудования и получение спецификации.
Например, возьмем кабеленесущую продукцию. Находясь в привычной системе автоматизированного проектирования, проектировщику достаточно будет выбрать тип кабельного лотка, затем построить кабеленесущую трассу, а все несущие конструкции для трассы смоделируются автоматически с подбором ширины консоли, расстоянием между консолями, необходимыми креплениями (балочными, настенными, потолочными), с выводом спецификации и т.д.
Такой плагин будет состоять из двух основных элементов:
- Электронные BIM модели (цифровые двойники) каталога продукции, сформированные для определенной системы автоматизированного проектирования
- Плагин к системе автоматизированного проектирования, автоматизирующий моделирование с помощью цифровых двойников.
Какие роли необходимы в команде Разработки ПО для реализации первой версии данного плагина и какова их загрузка?
- 100% – Разработчик семейств каталога продукции Заказчика.
- 100%–Программист, который сможет воспользоваться базой семейств и создать плагин.
- 50%–Тестировщик со знанием предметной области: это должен быть инженер-проектировщик конкретного раздела проектирования.
- 30%–Руководитель проекта для коммуникации с Заказчиком и мотивации команды.
- 10-30%–Дизайнер.
- 30%– Бизнес-аналитик, который сможет оценить требования заказчика и превратить их в техническое задание.
Можно ли объединять роли?
Можно. Это несет больше проектных рисков с точки зрения устойчивости команды на длительном промежутке времени. Однако Руководитель проекта вполне может выполнить роль и бизнес-аналитика.
Какими еще компетенциями должен обладать Руководитель проекта?
Руководитель проекта должен обладать компетенциями разработчика ПО, он должен понимать в алгоритмах и различных путях решения задачи. Для чего? Например, чтобы однозначно понимать, можно ли выполнить требования Заказчика, в каком виде: в том ли, в котором Заказчик и Бизнес-аналитик изначально предлагают.
Пример: необходимо вывести в спецификацию крепления крышек лотков с учетом их материала.
Как известно, САПР выводит в спецификацию только то, что смоделировано. Соответственно,это является задачей для Разработчика семейств, который должен скрупулезно добавить все мелкие крепления в каждое семейство крышеклотков. При этом требуется дополнительное время на разработку и тестирование, ведь такая детализация семейства увеличивает его в размерах и осложняет процесс его поддержки.
Что должен сделать грамотный Руководитель проекта, осознавая это?
Руководитель проекта должен понять, можно ли, не моделируя элемент, получить его в спецификации. Вопрос заказчику на совещании: «Стандартизовано ли количество креплений для лотков?»Если оказывается, что да, тогдаможно легко посчитать количество креплений, так как каждый тип лотка имеет вполне определенное количество, и даже учесть их материал, ведь есть специальная таблица соответствия материалов крепления в зависимости от лотка.
ИТОГ: Задача перемещена от Разработчика семейств Программисту. Семейство не перегружено деталями, в спецификации присутствуют позиции креплений.
Процесс разработки, казалось бы, простого плагина становится сложной, но посильной задачей, если:
А) Руководитель проекта обладает навыками программирования и коммуникационными навыками для решения Задач Заказчика и мотивации команды.
Б) Бизнес-аналитик понимает требования Заказчика, превращает их в ТЗ, а руководитель проекта находит элегантные решения каждого требования.
В) Программист и Разработчик семейств обладают высоким уровнем ответственности и не бросят проект на полпути.
Г) Тестировщик понимает предметную область и то, как все должно работать.
Каковы сроки разработки первой версии плагина?
Сроки разработки первой версии варьируются от 3 до 12 месяцев при указанной выше загрузки персонала.
Последующие версии с высокой долей вероятности уже не будут требовать такого количества человек и загрузки. Плагин переходит в стадию поддержки и планомерного постоянного улучшения, в том числе с учетом новых версий ПО, операционных систем, железа и т.д.
Важно помнить:
- Команда разработки Плагина должна быть распределена на несколько ролей и несколько человек. ИначеКомпания Заказчик и Компания Программист несут существенные ресурсные риски, особенно на длинной дистанции, встают в зависимость от одного человека.
- Выполнение самой простой задачи можно «случайно» заметно усложнить неэффективным путем ее реализации. Чтобы этого не допустить, должен быть опытный Руководитель проекта.
- Программист должен понимать, как писать код правильно, а Руководитель проекта уметь проверять. Если код написан без должного рефакторига, каждая новая функция будет занимать кучу времени для ее реализации.
- Не стоит забывать про коммуникации.
