Работа начинается с этапа "Анализ требований", за который отвечают аналитики. На основании этого осуществляется проектирование решения (архитектором). В случае заказной разработки, с декомпозицией работ, состава команды, сроков и рассчитываемой на этом основании цены. После чего проводится тендер и с выигрывшим подписывется контракт.
Согласно же вашему вопросу, клиент не знает что хочет, в каком составе и хочет ли вообще.
Разница в том, что в организации, в которой работает автор, принято все навешать на одного человека и назвать его архитектором. А, например, в организации, где работаю я, за общение с клиентом отвечают только аналитики, а вот именно архитектурой как раз и занимается архитектор решений.
Поэтому, на мой взгляд, статья содержит ошибочные утверждения, вызванные неправильным разделением ролей у его работодателя.
Выскажусь как Аналитик/Руководитель группы с многолетним стажем. Из моего опыта могу сказать, что сам по себе UML откровенно бесполезная штука, лишь увеличивающая объем работы и генерящий ошибки на проекте. Жаль, что многие Аналитики попросту боятся об этом сказать своему руководству прямо.
Вот сколько раз сталкивался с ситуацией, когда на картинке нарисовано одно, текстом написано другое, а в результате выясняется, что текст поправили, а картинку поправить забыли. Либо даже не забыли, а просто уже задолбались все это перерисовывать.
Теперь давайте пройдемся по вашим диаграммам:
1) UseCase. Вы совершенно правильно написали, что перечень функций ГОРАЗДО проще указать текстом. И что стрелки с этими обобщениями и расширениями кого хочешь запутают и лучше использовать линии. Но еще забыли написать, что когда у вас этих функций с полсотни, а акторов с полтора десятка, у вас вся эта диаграмма прекратится в мусор. А если вся эта «красота» должна будет передана Заказчику в бумажном виде? Значит вам придется все это еще подгонять под формат печатной страницы. А если потребуется добавить новые блоки, то все эти блоки надо будет двигать. Выравнивание всего этого безобразия может занять часы, если не дни. И все ради того, чтобы указать акторов, связанного с этими вариантами использования. А в чем проблема указать это текстом? Да нет в этом никакой проблемы, просто напишите текстом в описании самого варианта использования.
2) Activity diagram. Опять та же самая проблема, что и для UseCase — куча бессмысленной работы по выравниванию/перемещению блоков и стрелок. Я уж не говорю, если требуется написать чуть больше информации, кроме названия действия, например, список передаваемых параметров. И самое-то главное, зачем? Вся эта задача прекрасно решается с помощью записи варианта использования либо в виде структурированного списка, либо путем классической формы оформления записи в две или три колонки.
3) Архитектура системы. Да, вот это вещь ценная. Но! Какое отношение она имеет к UML? Да никакого, вы и сами это написали.
4) Sequence diagram. Вот здесь я с вами действительно соглашусь, эта диаграмма может быть полезна.
5) Диаграмма классов. А вам не кажется, что для проектирования баз данных существуют отдельные, приспособленные для этого нотации, например, Crow’s foot? Зачем тут UML?
В сухом остатке: 2 диаграммы — зло, одна полезная, еще одна использована не по назначению при доступном лучшем аналоге, и одна вообще к UML не относится.
Т.е. 1:4 против UML.
Коэффициент лексического сходства касается сравнения стандартизованного списка слов, которая может тянуться и из общего индоевропейского происхождения. А вовсе не всего языкового разнообразия языка. Вы не тем показателем измеряете.
Работа начинается с этапа "Анализ требований", за который отвечают аналитики. На основании этого осуществляется проектирование решения (архитектором). В случае заказной разработки, с декомпозицией работ, состава команды, сроков и рассчитываемой на этом основании цены. После чего проводится тендер и с выигрывшим подписывется контракт.
Согласно же вашему вопросу, клиент не знает что хочет, в каком составе и хочет ли вообще.
Согласно проф.стандарту системный аналитик работает лишь с требованиями и проектированием не занимается.
А бизнес-аналитик исследует текущие бизнес-процессы (as-is) и делает предложения по их оптимизации (to-be).
Повторюсь, в вашей организации полная путаница с IT-ролями.
Разница в том, что в организации, в которой работает автор, принято все навешать на одного человека и назвать его архитектором. А, например, в организации, где работаю я, за общение с клиентом отвечают только аналитики, а вот именно архитектурой как раз и занимается архитектор решений.
Поэтому, на мой взгляд, статья содержит ошибочные утверждения, вызванные неправильным разделением ролей у его работодателя.
Вот сколько раз сталкивался с ситуацией, когда на картинке нарисовано одно, текстом написано другое, а в результате выясняется, что текст поправили, а картинку поправить забыли. Либо даже не забыли, а просто уже задолбались все это перерисовывать.
Теперь давайте пройдемся по вашим диаграммам:
1) UseCase. Вы совершенно правильно написали, что перечень функций ГОРАЗДО проще указать текстом. И что стрелки с этими обобщениями и расширениями кого хочешь запутают и лучше использовать линии. Но еще забыли написать, что когда у вас этих функций с полсотни, а акторов с полтора десятка, у вас вся эта диаграмма прекратится в мусор. А если вся эта «красота» должна будет передана Заказчику в бумажном виде? Значит вам придется все это еще подгонять под формат печатной страницы. А если потребуется добавить новые блоки, то все эти блоки надо будет двигать. Выравнивание всего этого безобразия может занять часы, если не дни. И все ради того, чтобы указать акторов, связанного с этими вариантами использования. А в чем проблема указать это текстом? Да нет в этом никакой проблемы, просто напишите текстом в описании самого варианта использования.
2) Activity diagram. Опять та же самая проблема, что и для UseCase — куча бессмысленной работы по выравниванию/перемещению блоков и стрелок. Я уж не говорю, если требуется написать чуть больше информации, кроме названия действия, например, список передаваемых параметров. И самое-то главное, зачем? Вся эта задача прекрасно решается с помощью записи варианта использования либо в виде структурированного списка, либо путем классической формы оформления записи в две или три колонки.
3) Архитектура системы. Да, вот это вещь ценная. Но! Какое отношение она имеет к UML? Да никакого, вы и сами это написали.
4) Sequence diagram. Вот здесь я с вами действительно соглашусь, эта диаграмма может быть полезна.
5) Диаграмма классов. А вам не кажется, что для проектирования баз данных существуют отдельные, приспособленные для этого нотации, например, Crow’s foot? Зачем тут UML?
В сухом остатке: 2 диаграммы — зло, одна полезная, еще одна использована не по назначению при доступном лучшем аналоге, и одна вообще к UML не относится.
Т.е. 1:4 против UML.
ru.wikipedia.org/wiki/%D0%97%D0%B0%D0%B8%D0%BC%D1%81%D1%82%D0%B2%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_%D0%B2_%D0%B0%D0%BD%D0%B3%D0%BB%D0%B8%D0%B9%D1%81%D0%BA%D0%BE%D0%BC_%D1%8F%D0%B7%D1%8B%D0%BA%D0%B5
Правда я чуть ошибся — все же 29% из французского и 29% из латинского. Что в сумме — 58%. При том, что из германских — только 26%.
Ну да, совсем «немного» — слой в несколько десятков метров глубиной:
https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%B3%D0%BE%D0%BB%D0%B8%D1%82
Неадекватно оцениваете свою эффективность.
что противоречит дальнейшей фразе:
В оригинале:
Я бы перевел скорее как:
«2018 должен стать последним годом, когда приходится начинать писать новый проект на C или C++»