и к каким последствиям это приводит?
Когда строится уникальное здание, архитектор осуществляет авторский контроль, т.к. конечная цель связки архитектор-строители является здание для заказчика.
Разве при разработке ПО не так же? Я, конечно, понимаю про тестирование, но неужели роль аналитика заканчивается на разработке требований? Кто в итоге отвечает за пиджак? Я понимаю про "отвечает за все руководитель проекта", но, на мой взгляд, аналитик должен участвовать в приемке приложения и возможно в функциональном тестировании и разработке документации.
Требования и предметная модель — это разве одно и тоже?
Под предметной моделью в данном контексте я понимаю диаграммы классов, в которых аналитик расписывает артефакты предметной области (я пока про статику, без потоков и процессов) и которые используются при описании функциональных требований.
Насколько выиграет? Откуда информация об этом — у вас есть опыт или читали про чужой?
К сожалению, по этой теме теории я читал мало. Потому и разместил сообщение в данной ветке. Да, опыт небольшой был, с коллегами год разрабатывали метамодель будущей системы, без строчки кода. С точки зрения проработки аналитики приложения, мы за этот год сделали больше, чем за предыдущие 9.
Лично для своего случая вижу два плюса: прочитав и поняв метамодель любой разработчик (и аналитик) понимает общую концепцию системы. Второй плюс - мы разрабатываем коробочный продукт для открытого рынка, т.е. заказчик конкретизируется после покупки и начала внедрения. При внедрении происходят различные "уточнения требований". Если изначально предметную модель зашить в коде, то "уточнение" практически невозможно. Поэтому при разработке приходится предполагать различные будущие изменения и разрабатывать настраиваемое ПО. Раньше делали все на интуиции, но почитав немного (к сожалению немного), я понял, что есть некие теоретические знания, которые могут помочь в этом. Насколько я понимаю, можно на основе нескольких предметных моделей (описанных и предполагаемых) построить метамодель, в которой эти модели легко реализовать при настройке у конкретного пользователя.
Это гипотеза или опыт?
Имелся опыт (выше описал), но, к сожалению, не доведенный до конца по организационно-экономическим причинам.
Denis Beskov, я разделяю Ваш скепсис, который Вы высказывали в другой ветке. Действительно можно заиграться в метамоделирование и спроектировать "базу данных в 4-6 таблиц для всего и вся". На мой взгляд, в статье на хабре тоже перегнули палку (вроде речь про НИИ шла, тогда понятно), разрабатывая серии виртуальных машин под различные предметные области.
Чем это принципиально отличается от MDA (Model-Driven Architecture) и DDD (Domain Driven Design)?
Возможно ничем. Спасибо за наводку, буду читать. Почитал по диагонали, очень похоже.
«Можем разработать логически связанную структуру большого ПО» — за какое время? Откуда возьмётся информация для такой структуры?
Так про это и речь, если жизненный цикл разработки и развития ПО превышает 10 лет (условно говоря более 10 версий по 1 разу в год), то к десятому году что-либо внести в систему проблематично. Появляются куски кода, которые никто из существующих на данный период времени разработчиков не видел. Ситуация "в одном месте поправил, в других отвалилось" становится типичной.
Как поддерживается процесс развития системы?
Метамодель (возможно DDD и/или MDA) позволит при внесении изменений понять масштаб бедствия. Обычно такие знания находятся в голове разработчиков, заманчиво иметь хотя бы часть этих знаний "на бумаге". Соответственно, не забываем и про трассировку.
Вы с какой позиции рассуждаете — архитектора, аналитика, менеджера, заказчика, ИТ-директора?
Формально, с точки зрения аналитика. Но коллектив небольшой, роли размыты. Например, ранее часть структуры БД проектировал я, сейчас, правда, разработчики. Код я не пишу, и никогда не писал.
Хотя, на мой взгляд, вещь полезна для всех ролей разработчиков.
Темы для встречи в Москве