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

Важно сразу уточнить, что совсем без разработчиков в информационных технологиях (ИТ) обойтись не получится. Но в некоторых сферах разработки ПО, на мой взгляд, могут произойти серьёзные перемены. Давайте для определённости рассмотрим корпоративную разработку и попробуем проследить и экстраполировать путь её развития с учётом стремления уменьшить затраты.

И ещё. Предлагается не NoCode или LowCode, а скорее, оченьдаже-Code. В общем, это – другое!

Настоящая сложность на потоке – Enterprise-методологии

Начиналась наша история примерно в начале 90х с одиноких энтузиастов, которые используя какой-нибудь dBase, FoxPro, Paradox и прочие подобные инструменты, автоматизировали конкретно свои или «соседние» рабочие места. Ох! Какое это было замечательное время – сидишь себе один и «клепаешь на коленке» ПО, которое работало!

Всё было хорошо, пока руководство, обратив внимание на «компьютерного гения», не просило его разработать более-менее комплексную систему автоматизации хотя бы одного отдела. Вот тут и выяснялось, что новая сложность не совместима с одиночной разработкой, т.к. было необходимо учесть слишком много деталей и подготовить сложную программно-аппаратную инфраструктуру. Пришлось договариваться с компаниями – системными интеграторами. Эти компании, кроме поставки и настройки инфраструктуры, также занимались разработкой ПО для автоматизации деятельности предприятий.

Для того, чтобы избежать провала таких проектов (статистика и сейчас весьма тревожна, а тогда было ещё хуже), компании-разработчики были вынуждены строго придерживаться современных на тот момент методологий разработки: RUP, MSF и других. Используя эти методологии, корпоративная разработка всё чаще стала достигать успеха. Эти методологии стали называть Enterprise-методологиями. Именно благодаря им с середины 90х до конца 10х годов был осуществлён настоящий прорыв в автоматизации крупных предприятий, имеющих не только сложную предметную область, но и разветвлённую сеть филиалов.

Давайте рассмотрим жизненный цикл разработки по Enterprise-методологиям и выясним, в чём причина успеха и источник проблем.

На рисунке представлена упрощённая схема жизненного цикла разработки ПО при использовании обобщённой Enterprise-методологии. На схеме многочисленные этапы разработки собраны в три основных:

• сбор требований/замечаний,

• детализация требований,

• разработка и тестирование.

Для выполнения каждого этапа привлекались различные роли. На схеме представлены далеко не все роли, обычно участвующие в проекте, а только основные. Также, для упрощения анализа я обобщил в роли «заказчик» не только самого заказчика из договора, но и всех его представителей.

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

По сути, каждый артефакт являлся моделью предметной области, а при каждом переходе на следующий этап эта модель подвергалась искажениям. И хоть и существовали различные способы компенсации этих искажений (тестирование: бизнес-тестирование, верификация; методики управления: требованиями, рисками, изменениями, ожиданиями и пр.), всё равно заказчик как правило на выходе жизненного цикла получал, мягко говоря, не совсем то, что хотел. Именно по этой причине рекомендовалось проект разделять на этапы, привлекать заказчика к обсуждениям и т.д. и т.п.  А также сокращать длительность жизненного цикла. Однако из моего опыта работы в подобных проектах я не знаю случая, когда итерация жизненного цикла была менее трёх месяцев. Чаще всего – дольше.

В результате очень часто затраты на разработку превышали запланированные. А отсюда и печальная статистика.

Решение проблемы производительности – Agile

Со временем автоматизация разработки росла и стали появляться идеи пересмотреть концепцию разработки с целью радикального сокращения итерации жизненного цикла и в целом затрат. Среди таких идей очень популярной стала идеология Agile, хотя переход на неё для компаний-разработчиков был не простым – очень уж сильно она отличалась от старых методологий. Всё переворачивалось «с ног на голову», ведь убиралась база – часть артефактов! Невероятная ересь с точки зрения системного аналитика, всю дорогу реализующего проекты в привычном стиле.

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

Команды разработки стали юркими мобильными крейсерами по сравнению с командами-ледоколами, работающими по Enterprise-методологиям. При этом, если ранее заказчик оставался на берегу, то теперь его взяли на борт, выделили уютную каюту, но на мостик пускают редко.

Если вернуться к ассоциации артефактов с моделью предметной области, то при выполнении проекта по Agile-style методологии перестало быть необходимым переводить первоначальное описание модели предметной области на язык разработки (в виде функциональной спецификации и заданий), поскольку разработчики вместе с заказчиком участвуют в процессе описания модели, изучают предметную область и стараются говорить на её языке. Их основной задачей является максимально точно перевести это описание в продукт, хотя искажения всё равно остаются.

Автоматизация разработки на марше – ЯОП

А теперь давайте представим, что мы описываем предметную область на языке, который может быть сразу интерпретирован, или по которому может выполняться компиляция/генерация/развёртывание ПО без дополнительного участия человека. В этом случае мы уберём этап кодирования, точнее, перенесём его в начало, совместив со сбором требований. В итоге, сократится время жизненного цикла и сократятся общие затраты на разработку. Также ещё проще станет управлять требованиями, изменениями и ожиданиями.

Теперь наш проект – изящная яхта, у руля которой стоят заказчик, разработчик и интеллектуальная система навигации. И больше на борту никто не нужен.

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

Или можно создать язык на базе хорошо себя зарекомендовавшего подхода к разработке корпоративных приложений, например, Domain-Driven Design (DDD). То есть, у нас может быть язык описания корпоративных предметных областей. В этом случае каждый раз разрабатывать новый язык не придётся, и тратить время на его доработку тоже. Ключевые слова этого языка будут терминами DDD, а переменные, названия методов и модулей – понятиями предметной области.

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

Одной из проблем может стать изменение структуры предметной области на одной из итераций жизненного цикла, которая приводит к неоднозначности конвертирования накопленных в результате эксплуатации данных или к их потере (Помните? – У нас непрерывное развёртывание!). Ранее, на этапе разработки для этой цели вручную создавались специальные сценарии преобразования и переноса данных. Но в нашем случае для этого можно заготовить обобщённые алгоритмы преобразования данных. А в случае риска искажения или потери данных анализатор нашего языка должен выдавать соответствующее сообщение об ошибке ещё на этапе изменения описания предметной области.

А нужен ли разработчик? – AI

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

Остаётся понять, как при данной конфигурации разработки управлять требованиями, рисками, ожиданиями и изменениями. Вероятно, требованиями и рисками придётся управлять через язык и AI, с ожиданиями сам заказчик разберётся за счёт резкого сокращения времени итерации. А вот изменениями придётся управлять, скорее всего, через механизмы типа SaaS, IaaS и пр. Так ли это невероятно?

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

А может быть совершилось превращение и теперь заказчик стал разработчиком? Как вам такой сюжет?

Заключение

Итак, мы сократили всю команду разработки из жизненного цикла создания корпоративных приложений. На мой взгляд подобный сценарий вполне возможен и не столь отдалён.

Попробую в следующей статье предложить вариант языка описания корпоративных предметных областей на базе подхода DDD. С использованием платформы SIMODO, конечно.

Что скажите? :-)