Здравствуйте, Sinix, Вы писали:

V>>Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
S>В своё время — да. На сегодня любые попытки использовать паттерны "как есть" неизменно кончаются лютым фейлом типа этого

Автор: Sinix
Дата: 28.03.14

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

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


V>>Какой в опу глобус? Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
S>Не катит. Потому что SEMAT пытается слепить в один том "взвод, отделение, танк" и "батальон, рота" (про ч.1 не будем, ибо гриф).

Ничего не понял по теме. Могу сказать лишь по твоей аналогии — современный мотострелковая бригада имеет всё перечисленное (ты еще забыл гаубичные батальоны, зенитные батальоны, батальоны связи и материального обеспечения) и "всё это" обязательно "слеплено" в одну "единицу" согласно Уставу.

Зачем вообще нужен Устав? Чтобы каждый командир не придумывал свои организационные "велосипеды", только и всего. В этом смысле RUP и MSF — полноценные "уставы".


S>Тот же "стейкхолдер предъявляет требования" скрывает под собой принципиально разные подходы, от проверкой кодом в тру-agile через верификацию моделью в DDD к традиционной аналитике в "тяжёлых" методиках. Как их можно в один инвариант запихивать?

ХЗ, чтобы не плодить сущности, вестимо. Как можно присваивать одно и то же звание командиру аэромобильной бригады и мотострелковой? )) Одна из них действует "тяжеловесным фронтом", а другая в стиле "тру-agile".

Я думаю, что ты попытался прицепиться к интуитивно понятному, а это заявка на поражение в споре, т.к. критиковать стоит интуитивно непонятное.


V>>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО.
S>Не работает Я наблюдал и каноничнейший сертифицированный RUP, рассыпавшийся именно из-за следования процессам, и самоорганизацию из бардака в процессы, вполне укладывающиеся в CMMI3. Единственная корреляция — уровень адекватности принимающего решения. Т.е. тот самый человеческий фактор.

Ну, дык, степень подготовленности командира никто не отрицает. Если человек идиот, ему никакой Устав не поможет. Только Устав тут не при чем, заметь. Это не всемогуттер, это просто циркуляр, подсказка, методичка, сборник практик и выработанных опытом других людей ограничений. Более того, в современной разработке тебе "ничего не будет", если ты не блюдешь устав, поэтому, сложновато оценить — действительно ли устав кривой, или люди только делали вид, что блюли устав, а сами только просиживали штаны и проедали бабло? В армии ведь тоже бывает — вроде, всё по Уставу, а нихрена не делается. "Итальянская забастовка" хорошо описывает причины того, почему порой даже самые лучшие практики не работают в некоторых конкретных командах. Я наблюдал в реальной жизни САБОТАЖ коллег, когда их, болезных, "заставляли" делать не то, что им бы хотелось. Согласись, что тут никакая организация процесса не поможет, если сам человек делает всё, чтобы завалить собственную работу.


V>>(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
S>Нее, ты видимо забыл первые выступления-статьи-конференции на тему RUP+UML == наше всё.

Я ничего не забыл и сам тогда критиковал именно такую постановке вопроса, что, мол, одно наличие UML порешает все проблемы. Конечно, это наивно. Но так же наивно думать, что графические нотации не нужны вовсе. Эти нотации, примененные к месту, — очень даже гут. Для меня UML — это лишь некое семейство языков графических нотаций, не более. Вот так к нему и надо относится. По букварю с одними картинками читать научиться невозможно, согласен, но когда букварь вообще без картинок — автор дебил. )) И это я еще не прошелся по ЛЮБОЙ более-менее вменяемой документации на программные системы, там без графической нотации ваапще никак. Правда, не всегда используется именно UML, но для специалиста с хоть какой-то подготовкой это и не принципиально.


S>Закончилось тем, что классический UML мы видим разве что в сопроводительной документации

А я регулярно вижу графические нотации в документация для разработчика, а это отнюдь не "сопроводительная документация". Этот тот самый "артефакт проектирования" согласно UP.


S>А "старые" методики остались только в учебниках, ибо MSF сегодня и MSF 20 лет назад — две оччень большие разницы. Хотя судя по этому:
S>

S>RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью

S>ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.

Ты серьезно? Ты возьмешься сейчас показать мне место в этих методологиях, где есть требование "проектировать в UML"?

Роза — лишь инструмент, автоматизирующий разработку и поддержку артефактов проектирования. Артефакты не обязаны быть ТОЛЬКО графическими. Именно за этим я послал тебя в предыдущем абзаце — попытаться найти такое требование.)) Не ищи, не найдешь. А составлять представление о RUP через Розу — но это уже за гранью добра и зла. Это всё-равно что составлять представление о фотографировании по Фотошопу, хотя последний (или его аналог) нужен в 99% случаев в современной фотографии.

Ну и еще такой момент, для составления текстовой документации полно текстовых процессоров и без Розы.


V>> Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
S>Ты_не_поверишь. Ровно то же самое мне рассказывали про RUP EUP лет эдак двенадцать назад. Не помогло.

Кому не помогло? Для "водопадной" разработки UP — это наиболее естественный процесс до сих пор. Его используют в военке, космосе, авиации, при разработке финансовых систем и т.д.

Фишка в том, что ВСЕ более-менее крупные системы разрабатываются по "водопаду". Но при разработке различных подсистем (особенно GUI пользователя или внешнего программного интерфейса/АПИ), зачастую используют классику Agile, т.е. происходит акцент на итерации через фидбэк от конечных пользователей/заказчиков или даже просто тестеров, их эмулирующих. Характерно тут то, что UP не запрещает и никак не конфликтует с такой расстановкой "акцентов" на некоем этапе разработки.


Ну и пример:

http://jobs-boeing.com/various-locations/boeing/jobid7048305-project-manager-4-jobs

Knowledge and Skills:
Software development projects.
Strong familiarity with all aspects of software requirements, design, implementation, testing, deployment, and maintenance.
Strong familiarity with RUP (Rational Unified Process) and Agile software methodologies.