Методологии визуального моделирования/проектирования (с помощью, например, UML) охватывают сегодня 0% проектов

Методологии визуального моделирования/проектирования (с помощью, например, UML) охватывают сегодня 0% проектов. Возможно, в томах документации где-то и найдутся красивые диаграммки, чтобы морочить голову заказчикам, но к реальному процессу разработки они обычно никакого отношения не имеют.

Модель зрелости процессов разработки софта CMM Карнеги-Меллона охватывает сегодня 0% проектов, что означает фактически, что всякая организация работает на уровне CMM-1 (хаос и бардак).

Метод Шлаера и Меллора (объектно-ориентированный системный анализ) на русском вообще не найти. ООАП Бертрана Мейера чуть-чуть на слуху (и то наверное, только одними моими усилиями :).

Методология RUP (Rational Unified Process) — ноль.

Свод знаний по управлению PMBoK — зеро.

Более "приземлённые" iLogic Rhapsody, Borland Together или IBM/Rational Rose — нигде.

Причём это всё довольно бумерские вещи (иных уж нет, а те далече), за последние 1-2 десятка лет тут ничего нового не появилось, а старое успешно забывается. В университетах для получения зачёта, возможно, надо вызубрить несколько фраз по этим аббревиатурам, и всё.

Когда я говорю "ноль", имею в виду совсем крошечные доли, ну может быть, даже несколько процентов, на фоне общего шума.

=

Существует гигантский разрыв между программистам и методологами. Почему? Что случилось со всеми достижениями программной инженерии?

Большинство из нас просто слишком заняты, чтобы внедрять инновационные подходы к работе. Когда вы трудитесь по 60 часов в неделю, чтобы выпустить продукт к сроку, трудно найти несколько недель (а то и месяцев) для внедрения новых схем разработки. А так как начальство почти всегда относится к ИТ-отделу как к необходимому злу и расходной статье, то ничего и не вкладывает в улучшение рабочих процессов.

Однако по мере роста масштаба и стоимости ИТ-проектов — уже на миллиарды рублей, даже самые невежественные менеджеры начинают понимать, что "классические" (читай: героические) методы практически не масштабируются. Более-менее адекватные руководители отчаянно ищут альтернативные подходы, и некоторые из них действительно могут значительно повысить качество продукта и сократить время его выпуска.

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

Без цифр поставщики подобных систем, по сути, просят своих клиентов просто им довериться ни с того ни с сего, и заплатить большие деньги за кота в мешке. Но инженерам нужны цифры, данные, факты. Продать ИТ-директору слепую веру трудно.

=

Сегодня по запросу "uml моделирование программы 2022" можно нагуглить обзоры десятков решений, однако почти все они стали бесплатными, что означает, что это всё по сути — вторичная/второсортная продукция с соответствующим уровнем поддержки и развития. Можете поэкспериментировать, но в такой ситуации ответ на вопрос "Сэкономит ли визуальное моделирование ваше время и деньги?" стал ещё более мутным. Возможно, даже вероятно; но я ещё не видел финансовых аргументов в их пользу, которые бы действительно заставили руководителя компании радостно закивать своей головой. Даже если сама система доступна по цене, обучение такой непростой теме потребует заметного времени (и оно тем больше, чем меньше цена, т.к. делать качественные обучалки у производителя нету никакой мотивации). А фаза внедрения на некоторое время точно снизит общую производительность.

Даже в те прекрасные времена, когда в ИТ существовал полноценный рынок инструментов разработчика, компании в основном покупали те инструменты, которые были необходимы безусловно: компиляторы. отладчики, IDE и тому подобное. Лишь немногие покупали продукты по методологии и качеству кода. Причина этому лишь в том, что поставщики плохо доказывали ценность своих систем, которая, безусловно, при правильном применении весьма высока. В те годы я писал довольно много статей о подобных тяжёлых средствах моделирования, и вот парадокс, что когда они стоили тысячи долларов за одно рабочее место, их как-то покупали и внедряли, а когда они стали бесплатными, то вообще стали никому не нужны.

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

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

P. S. Эти рассуждения, кстати, относятся и ко множеству других "корпоративных" систем самого разного назначения, о нужности которых их производители подчас не могут даже двух фраз связать, какие уж там аргументированные выкладки...

Источник: vk.com

Комментарии: