Как построить проект по созданию российской PLM системы?
Авторы:
Андрей Кармишин, вице-президент «Национальной компьютерной корпорации» (НКК).
Дмитрий Прилуцкий, директор по стратегическому развитию TopS Business Integrator (TopS BI).
Андрей Слюняев, директор по разработке TopS Business Integrator (TopS BI).
Задача создания PLM системы тяжелого класса VS существующие методы разработки ПО
Рассмотрим существующие методы разработки программного продуктов с точки зрения применимости в проекте разработки PLM системы тяжелого класса.
Для простоты раскрытия термина «PLM система тяжелого класса» условимся, что к таким системам относятся системы, по классу и уровню функциональности соответствующие признанным западным PLM-продуктам, давно представленным на рынке и используемым для управления данными ЖЦИ на предприятиях среднего и тяжелого машиностроения по всему миру (Siemens Teamcenter/NX, Dassault Systems ENOVIA/CATIA, PTC Windchill/Creo).
Традиционный метод разработки
Традиционный метод разработки (Waterfall) на примере функциональных модулей A, B и C представлен на рисунке ниже.
Андрей Кармишин, вице-президент «Национальной компьютерной корпорации» (НКК).
Дмитрий Прилуцкий, директор по стратегическому развитию TopS Business Integrator (TopS BI).
Андрей Слюняев, директор по разработке TopS Business Integrator (TopS BI).
Задача создания PLM системы тяжелого класса VS существующие методы разработки ПО
Рассмотрим существующие методы разработки программного продуктов с точки зрения применимости в проекте разработки PLM системы тяжелого класса.
Для простоты раскрытия термина «PLM система тяжелого класса» условимся, что к таким системам относятся системы, по классу и уровню функциональности соответствующие признанным западным PLM-продуктам, давно представленным на рынке и используемым для управления данными ЖЦИ на предприятиях среднего и тяжелого машиностроения по всему миру (Siemens Teamcenter/NX, Dassault Systems ENOVIA/CATIA, PTC Windchill/Creo).
Традиционный метод разработки
Традиционный метод разработки (Waterfall) на примере функциональных модулей A, B и C представлен на рисунке ниже.
Традиционный подход к разработке ТЗ предполагает детальное описание функциональных требований к программному обеспечению, к преимуществам традиционного метода разработки относится также и возможность точного планирования сроков и бюджета проекта — состав и порядок выполнения работ определены, изменения крайне нежелательны, место, границы и объем таких изменений заранее определены для каждого этапа разработки.
Считается, что бизнес-требования к инженерному ПО консервативны и могут быть определены заранее. Таким образом, российские разработчики отдельных продуктов в области PLM формируют требования по принципу перечисления функций, содержащихся в отдельных модулях-аналогах PLM систем западных вендоров.
Но разработка модулей/сквозных решений PLM системы тяжелого класса — трудоемкий процесс, требующий реализации как функционирования отдельных модулей, так и совместной согласованной работы нескольких модулей для решения сложных инженерных задач.
Разработка PLM системы тяжелого класса занимает длительный период времени (от нескольких месяцев до нескольких лет), поэтому в процессе разработки ПО появляются дополнительные бизнес-требования, а приоритеты реализации бизнес-требований могут меняться. Таким образом, повышаются риски расхождения требований к системе, утвержденных в ТЗ, с реальными потребностями предприятий на этапе окончания рабочего проекта, а отсутствие единого согласованного технического проекта на раннем этапе разработки ведет к дополнительным переработкам уже существующих модулей с целью обеспечения их совместного функционирования, вплоть до пересмотра их архитектуры и разработки отдельных модулей «с нуля». Как показывает опыт, разработка системы по такому ТЗ, как правило, не приводит к желаемому результату.
Гибкий метод разработки
Гибкий метод разработки (Agile) на примере функциональных модулей A, B и C представлен на рисунке ниже.
Считается, что бизнес-требования к инженерному ПО консервативны и могут быть определены заранее. Таким образом, российские разработчики отдельных продуктов в области PLM формируют требования по принципу перечисления функций, содержащихся в отдельных модулях-аналогах PLM систем западных вендоров.
Но разработка модулей/сквозных решений PLM системы тяжелого класса — трудоемкий процесс, требующий реализации как функционирования отдельных модулей, так и совместной согласованной работы нескольких модулей для решения сложных инженерных задач.
Разработка PLM системы тяжелого класса занимает длительный период времени (от нескольких месяцев до нескольких лет), поэтому в процессе разработки ПО появляются дополнительные бизнес-требования, а приоритеты реализации бизнес-требований могут меняться. Таким образом, повышаются риски расхождения требований к системе, утвержденных в ТЗ, с реальными потребностями предприятий на этапе окончания рабочего проекта, а отсутствие единого согласованного технического проекта на раннем этапе разработки ведет к дополнительным переработкам уже существующих модулей с целью обеспечения их совместного функционирования, вплоть до пересмотра их архитектуры и разработки отдельных модулей «с нуля». Как показывает опыт, разработка системы по такому ТЗ, как правило, не приводит к желаемому результату.
Гибкий метод разработки
Гибкий метод разработки (Agile) на примере функциональных модулей A, B и C представлен на рисунке ниже.
Гибкий метод разработки основывается на постоянном контакте разработчика с пользователем для верификации и валидации требований, и, поэтому лишен такого недостатка, как несоответствие фактического и целевого функционала. Несмотря на затруднения при прогнозировании трудоемкости и сроков реализации, в большинстве случаев гибкий метод демонстрирует более высокую результативность, т.к. имеется возможность формировать последовательность реализации функционала ПО в соответствии с ожиданиями заказчика.
Надо отметить, что ведущие предприятия российского машиностроения, использующие PLM системы тяжелого класса западных вендоров, были глубоко вовлечены в процессы гибкой разработки: представители разработчика и ключевые специалисты предприятий постоянно взаимодействовали для формирования, проработки, валидации требований; авторского надзора; внедрения и поддержки готового функционала; осуществления экспертной и референсной функций в рамках холдинга/отрасли.
Таким образом, у российских машиностроительных предприятий накоплен опыт взаимодействия с разработчиками PLM систем тяжелого класса, а специалисты готовы к участию в Agile-проектах.
Сценарный подход к разработке PLM системы тяжелого класса
Авторы, основываясь на опыте работы с PLM системами западных вендоров и предприятий отечественного машиностроения, предлагают комбинированный метод разработки ТЗ и модулей/решений PLM систем тяжелого класса, основанный на сценарном подходе с использованием преимуществ гибкого метода, в первую очередь, заложенных в постоянном контакте разработчика с пользователем.
Как было отмечено выше, традиционные и гибкие методы разработки программного обеспечения базируются на выполнении функциональных требований к ПО, описанных в ТЗ. Однако, из-за большого количества функций в PLM системе, сложно учесть, какие функции ПО необходимы для выполнения конкретных задач пользователя (например, создание трехмерной модели). Если некоторая функция ещё не реализована (например, ее разработка запланирована на будущее), хотя уже много других функций запланировано и разработано, конкретная задача пользователя все ещё не решается. Комбинаторная сложность разработки всего запланированного функционала системы без применения целевых сценариев запредельно высока и недостижима в условиях ограниченного времени и ресурсов. Сценарный подход позволяет избежать таких «разрывов» в логике, поскольку базой ТЗ является сценарий использования системы, отражающий процесс выполнения задачи пользователем. В сценарном ТЗ реализуются только функции ПО, необходимые для данного сценария. Таким образом, пользователь может выполнять процесс, соответствующий сценарию, полностью от начала до конца после завершения работ по данному сценарию. По мере реализации сценариев функции соединяются, как паззл, в полный функционал программы.
В сценарном подходе бизнес-требования связываются с функциями и объектами модели данных. Это позволяет тестировать и проверять функционал согласно сценариям, что улучшает качество разработки и соответствие ожиданиям заказчика. Сценарный подход также помогает определить приоритеты разработки функционала в соответствии с бизнес-требованиями и особенностями архитектуры системы.
Сценарий использования может быть:
— Головным;
— Пользовательским;
— Функциональным.
Сценарий использования формируется на основе пользовательских историй и представляет собой требование к системе с точки зрения пользователя. Каждому головному сценарию соответствует несколько пользовательских сценариев (по сути происходит декомпозиция головной бизнес задачи на частные бизнес-задачи исполнителя-пользователя системы), головные сценарии для удобства навигации могут быть объединены в разделы. Разделы, головные и пользовательские сценарии описывают бизнес-требования к PLM системе тяжелого класса и составляют основу проекта ТЗ — см. рис.
Надо отметить, что ведущие предприятия российского машиностроения, использующие PLM системы тяжелого класса западных вендоров, были глубоко вовлечены в процессы гибкой разработки: представители разработчика и ключевые специалисты предприятий постоянно взаимодействовали для формирования, проработки, валидации требований; авторского надзора; внедрения и поддержки готового функционала; осуществления экспертной и референсной функций в рамках холдинга/отрасли.
Таким образом, у российских машиностроительных предприятий накоплен опыт взаимодействия с разработчиками PLM систем тяжелого класса, а специалисты готовы к участию в Agile-проектах.
Сценарный подход к разработке PLM системы тяжелого класса
Авторы, основываясь на опыте работы с PLM системами западных вендоров и предприятий отечественного машиностроения, предлагают комбинированный метод разработки ТЗ и модулей/решений PLM систем тяжелого класса, основанный на сценарном подходе с использованием преимуществ гибкого метода, в первую очередь, заложенных в постоянном контакте разработчика с пользователем.
Как было отмечено выше, традиционные и гибкие методы разработки программного обеспечения базируются на выполнении функциональных требований к ПО, описанных в ТЗ. Однако, из-за большого количества функций в PLM системе, сложно учесть, какие функции ПО необходимы для выполнения конкретных задач пользователя (например, создание трехмерной модели). Если некоторая функция ещё не реализована (например, ее разработка запланирована на будущее), хотя уже много других функций запланировано и разработано, конкретная задача пользователя все ещё не решается. Комбинаторная сложность разработки всего запланированного функционала системы без применения целевых сценариев запредельно высока и недостижима в условиях ограниченного времени и ресурсов. Сценарный подход позволяет избежать таких «разрывов» в логике, поскольку базой ТЗ является сценарий использования системы, отражающий процесс выполнения задачи пользователем. В сценарном ТЗ реализуются только функции ПО, необходимые для данного сценария. Таким образом, пользователь может выполнять процесс, соответствующий сценарию, полностью от начала до конца после завершения работ по данному сценарию. По мере реализации сценариев функции соединяются, как паззл, в полный функционал программы.
В сценарном подходе бизнес-требования связываются с функциями и объектами модели данных. Это позволяет тестировать и проверять функционал согласно сценариям, что улучшает качество разработки и соответствие ожиданиям заказчика. Сценарный подход также помогает определить приоритеты разработки функционала в соответствии с бизнес-требованиями и особенностями архитектуры системы.
Сценарий использования может быть:
— Головным;
— Пользовательским;
— Функциональным.
Сценарий использования формируется на основе пользовательских историй и представляет собой требование к системе с точки зрения пользователя. Каждому головному сценарию соответствует несколько пользовательских сценариев (по сути происходит декомпозиция головной бизнес задачи на частные бизнес-задачи исполнителя-пользователя системы), головные сценарии для удобства навигации могут быть объединены в разделы. Разделы, головные и пользовательские сценарии описывают бизнес-требования к PLM системе тяжелого класса и составляют основу проекта ТЗ — см. рис.
Каждый пользовательский сценарий содержит ссылки на реализующие его функциональные сценарии. Разные пользовательские сценарии могут быть связаны с одним и тем же функциональным сценарием. Функциональный сценарий описывает конкретные шаги взаимодействия пользователя с системой и содержит последовательность выполнения отдельных функций, ссылки на описание этих функций, а также ссылки на объекты модели данных и их описание.
Цикл работ по разработке PLM системы тяжелого класса на основе сценарного подхода в общем виде включает следующие основные этапы:
Цикл работ по разработке PLM системы тяжелого класса на основе сценарного подхода в общем виде включает следующие основные этапы:
- Разработка и утверждение ТЗ;
- Проектирование ПО;
- Разработка ПО;
- Разработка методологического обеспечения;
- Разработка нормативного обеспечения;
- Внедрение.
Заключение
Многолетний опыт в области развития PLM систем тяжелого класса западных вендоров в интересах ведущих предприятий отечественного машиностроения позволяет авторам утверждать, что комбинированный метод разработки PLM системы тяжелого класса, основанный на сценарном подходе — наиболее эффективный путь создания программного продукта такого класса, соответствующего требованиям российских машиностроительных предприятий для решения задач цифровизации, возникающих на всех этапах жизненного цикла изделия.
Об организации работ и о том, как строятся функционально-организационные схемы взаимодействия в рамках выполнения проекта разработки PLM системы на основе сценарного подхода, авторы расскажут в следующей статье.
Многолетний опыт в области развития PLM систем тяжелого класса западных вендоров в интересах ведущих предприятий отечественного машиностроения позволяет авторам утверждать, что комбинированный метод разработки PLM системы тяжелого класса, основанный на сценарном подходе — наиболее эффективный путь создания программного продукта такого класса, соответствующего требованиям российских машиностроительных предприятий для решения задач цифровизации, возникающих на всех этапах жизненного цикла изделия.
Об организации работ и о том, как строятся функционально-организационные схемы взаимодействия в рамках выполнения проекта разработки PLM системы на основе сценарного подхода, авторы расскажут в следующей статье.