Здравствуй, уважаемый Хабр!  Меня зовут Ростислав, я работаю в IT с 2007 года. Начинал системным аналитиком, а последние 10 лет руководил проектами заказной разработки.  Мое представление о low-code платформе мечты сформировано прежде всего на основе опыта работы системным аналитиком, которым я никогда не переставал быть, хотя последние годы занимаюсь в основном управленческими задачами. На иллюстрации представлен «традиционный», или «упрощенный стандартный» процесс разработки – заказчик формулирует высокоуровневые требования, аналитик их декомпозирует, программист выполняет требования в коде, тестировщик проверяет корректность работы, DevOps занимается обновлениями стендов и сопровождением. Управление этим процессом мы выносим за скобки. Также я не стал делить аналитиков на бизнес и системных, т.к. на мой взгляд бизнес-анализ – частный случай анализа системного. При наличии системных аналитиков, бизнесовые, имхо, не нужны. Итак, мы обозначили проблему и показали процесс, в рамках которого она живет.  В качестве решения я хотел бы предложить свое видение. В моем представлении, low-code платформа - инструмент прежде всего для работы системных аналитиков.  Аналитики смогут моделировать предметные области с помощью визуального конструктора сущностей в виде дерева классов и объектов, а набор генераторов платформы позволит создавать из этих моделей различные информационные производные, начиная от исходных кодов работающих веб-приложений, заканчивая проектной документацией, описывающей готовые решения. Созданные аналитиками сгенерированные приложения при необходимости могут быть дополнены разработчиками. Как видно, на иллюстрации из команды представлен только аналитик. Сразу всех успокою – представлено упрощение, другие участники процесса появятся дальше. Но на этом этапе я бы хотел показать, что для решения некоторых классов задач, при наличии подобной платформы и большом желании, можно обойтись одним толковым системным аналитиком и минимальными сроками. За счет чего мы этого добьемся?  Аналитик, имея на входе информацию от заказчика, может не тратить время на подробное документирование требований, т.к. в нашей концепции он сам их будет в основном реализовывать и проверять – соответственно передавать знания дальше по процессу нет необходимости, достаточно иметь их в голове. Документация (в этом идеальном мире) потребуется только для согласования ожиданий с заказчиком и определения бюджета. Разработка решений для некоторых классов задач станет доступна с помощью платформы аналитику. Подробнее об этом в следующих разделах статьи. Необходимость в регресс-тестирование сгенерированных приложений отпадет, т.к. при наличии ошибок в генераторах, они будут «сквозить» по всему приложению, соответственно их будет просто отловить и отладить. Для публикации приложения в облаке аналитику достаточно будет указать доступный сервер и url, все остальное платформа должна сделать сама.  На самом деле, конечно, результаты программирования без программистов и тестирования без тестировщиков на этом этапе оставляют желать лучшего и у нейросетей, и у системных аналитиков.  Вот как будет выглядеть процесс разработки на нашей платформе в реальности:  Заказчик формулирует высокоуровневые требования. Аналитик фиксирует границы и основные требования. Аналитик создает каркас приложения (описания БД, бэка, фронта и их связей) с помощью платформы. Архитектор проводит ревью каркаса приложения. Архитектор и аналитик описывают требования для наполнения тел методов классов и объектов в виде комментариев. В зависимости от типа требований, задачи на разработку выполняются либо непосредственно аналитиком (простые логика и вычисления), либо разработчиками SQL/C#/JS с помощью встроенного редактора методов. Готовая веб-страница собирается и публикуется после выбора доступного сервера и указания url. Тестировщик и аналитик проверяют корректность работы, при необходимости процесс возвращается на шаг 6. Каркас приложения в нашем случае будет представлять собой набор элементов, описывающих структуру БД, бэкенда, фронтенда и их взаимосвязей. Набор элементов будет представлен в виде дерева/графа классов и объектов, унаследованных из ограниченного набора базовых классов. Формирование каркаса будет происходить примерно следующим образом: Создается набор таблиц БД, их колонок и связей, ключей и индексов. При необходимости обработки данных на уровне БД, создается функция, для нее указываются входящие и исходящие параметры. Описывается набор API, предназначенных для работы со структурой БД и функциями, указываются входящие и исходящие параметры, производится их маппинг. Создается объект страницы, в редакторе интерфейса приводится набор элементов UI, предназначенных для работы с описанными API, производится их маппинг. Возможен и обратный порядок, но в случае с учетными системами Data-Driven-Development на моем опыте является оптимальным подходом. Я уже писал выше, что без программистов в разработке пока не обойтись. Но определенные задачи доступны и системным аналитикам – например, возможность передать айдишник из одного запроса в другой, чтобы получить или сохранить связанные сущности с помощью типового набора CRUD API, уже позволит создать что-то функциональное. По мере развития платформы, набор классов задач, доступных для решения аналитиком, будет расширяться. В случае, если речь идет о какой-то сложной логике, процессах, либо вычислениях, платформа должна позволить дополнить созданный аналитиком каркас непосредственно программистам, на любом из уровней стека. Представленное видение - приглашение к диалогу. Сейчас на рынке все больше и больше решений, которые предназначены для упрощения разработки ПО, давайте попробуем вместе разобраться в этом.  CEO «Геном-ИТ»