Здравствуйте, Sinix, Вы писали:
V>>Это фундаментальные инженерные процессы, которые относятся не только к разработке ПО. Ничего нового они не выдумали, но собираются упорядочить уже имеющееся. Так же неплоха ориентация на полноту методологии, в отличие от всяких модных-однобоких.
S>Эта бла-бла-грамма выше ещё больший сфероконизм чем паттерны от GoF.
Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
S>А тут всё заканчивается ИБД + кучей трюизмов, они не станут теорией всего, как ты их на глобус не натягивай.
Блин, иногда хочется коллегам сказать "заткнись и внимай". ))
Какой в опу глобус? Ничего нового я у них не увидел, но увидел попытку обобщить имеющееся. Я в разные годы отсылал коллег к 19-м и 34-м ГОСТ-ам. Почему? Не секрет, что в любой более-менее серьезной конторе полно своих правил по организации рабочего процесса. Зачастую эти правила рождаются в муках, путём проб и ошибок. Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Например, одно дело опытные разработчики с 15-20-летним стажем, другое дело — команда из относительно молодых спецов, которая будет вынуждена запарывать проекты вовсе не из-за недостаточной технической подготовки, а именно из-за недостаточной организационной. Современный разработчик обычно очень хорошо знает, что делать на стадии макетирования и технического эксперимента, знает как решать конкретные технические вопросы, но плохо представляет себе весь процесс разработки программных систем уровня выше мелких (по современным меркам) проектов. Т.е., "чуйка" и техническая подготовка зачастую плохо работают в командах из более 5-ти человек. По многим вопросам происходит "буксование" только из-за того, что нет опытного управленца, которому можно доверить хотя бы 20 спецов.
Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО. Мне довелось в начале своей карьеры поучаствовать в разработке программных систем по 19-м ГОСТ-ам, — проникся. Отпадает надобность во внешнем "кнуте и прянике" в виде достаточно опытной в управлении личности, который должен разбираться с тараканами каждого конкретного разработчика. Это как методичка к курсовому проекту, например, где для студента расписан необходимый план работ. И что мне больше всего импонировало, что эта "методичка" не исключает так любимых всеми нами стадий решения тех самых "вкусных" технических проблем. Наоборот, она помогает всем этим наработкам не трансформироваться в "работу в стол", а жесткая привязка к итеративности процесса не позволяет слишком увлечься "любимой задачей".
S>Универсальные полные тяжеловесные методики мы уже проходили 15 лет назад. Популярность msf, rup и прочих uml-driven как бы намекает, что не надо так делать.
Тем не менее, эти методологии появились не из воздуха, это реальные "циркуляры", по которым была осуществлена разработка очень больших программных систем. MSF и RUP очень близки, MSF даже тяжеловесней RUP, они обе хороши тем, что обладают полнотой, т.е. описывают полный цикл разработки, начиная от "наколенных" поделок, а так же обладают неплохой масштабируемостью, т.е. подходят как командам из 2-х человек, так и командам из 20-ти человек.
(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
S>Они все как одна сыпятся на самом нижнем уровне из-за чрезмерной детализации и оверменеджмента.
Наоборот, эти методологии появились как результат борьбы с микроменеджментом (особенно ярко это наблюдается в MSF), чтобы над каждым разработчиком не стоял дядя-PM и не говорил ему каждый день, что ему делать дальше. Это просто "методички" по самоорганизации процесса разработки ПО.
S>Перспектива на сегодня если и есть за чем, то за скрещиванием процессного подхода сверху и управляемого бардака снизу. Читай, kanban, lean, и кадавры из тяжеловесной биз-аналитики и любого agile-подхода. Но нет, мы снова будем пытаться свести в систему носки и капусту, просто потому, что можем
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью (кроме таких вещей из XP, как "парное программирование" — это слишком субъективная хрень, т.е. сильно зависимая от человеческого фактора практика, которая работает далеко не для всех "пар").
Извини, но весь этот пост говорит о том, что ты не удовлетворил свою эрудицию ни разу даже по такой вещи, которую неявно рекламируешь, — по Agile. Сама постановка вопроса "противопоставление Agile и MSF" говорит о том, что тебе не стоило высказываться по этой теме до изучения азов MSF в том числе. Цимус в том, что одна из популярных Agile на сегодня — это MSF Agile, которую используют в самой MS.
Более того, Agile Manifestoне включает в себя каких-либо практик и был составлен практиками, использующими РАЗНЫЕ методологии разработки ПО. Это просто набор советов для расстановки приоритетов в рамках ЛЮБОЙ законченной методологии проектирования. Медитировать до просветления, как грится.
Даже взять SCRUM — его можно рассматривать как урезанный по артефактам RUP, где из всего RUP оставили, собственно, итеративную часть разработки. Это ВСЁ. Т.е. это ЧАСТЬ методологии, но не вся она, т.к. она не обладает полнотой, т.к. описывает лишь часть жизненного цикла ПО. Еще можно вспомнить наши 19-е и 34-е ГОСТ-ы, которые тоже предоставляли возможность разного по уровню "углубления" в подробности методологии. Т.е. при том, что "общий рисунок" по ГОСТ-ам оставался тем же, некоторые стадии могли быть реализованы с произвольной (т.е. необходимой для каждого конкретного случая) глубиной.
И да, возвращаясь с кабжу. Чем мне сразу импонирует SEMAT — это "иерархической" моделью представления модели методологии. Сорри, это не масло маслянное, а именно так. Начиная от самых общих штрихов, от каркаса самого процесса, по каждой детали можно углубляться в подробности настолько, насколько это требуется. Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Если у них это в итоге выгорит — они покроют как бык корову все эти ГОСТ-ы, MSF, RUP и семейство Agile, по понятным причинам.
V>Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая.
В своё время — да. На сегодня любые попытки использовать паттерны "как есть" неизменно кончаются лютым фейлом типа этого
(всю тему целиком тоже можно посмотреть). Потому что или игнорируем особенности языка-фреймворка (и вместе с водой выплёскиваем ребёнка), или от паттернов остаются только названия, да и то их постоянно путают.
V>Какой в опу глобус? Знаешь, как военный устав всегда писался кровью и только кровью реальных людей. В этом смысле ГОСТ-ы, RUP, MSF были (и есть) таким же "уставом, писанным кровью".
Не катит. Потому что SEMAT пытается слепить в один том "взвод, отделение, танк" и "батальон, рота" (про ч.1 не будем, ибо гриф).
Тот же "стейкхолдер предъявляет требования" скрывает под собой принципиально разные подходы, от проверкой кодом в тру-agile через верификацию моделью в DDD к традиционной аналитике в "тяжёлых" методиках. Как их можно в один инвариант запихивать?
V>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО.
Не работает Я наблюдал и каноничнейший сертифицированный RUP, рассыпавшийся именно из-за следования процессам, и самоорганизацию из бардака в процессы, вполне укладывающиеся в CMMI3. Единственная корреляция — уровень адекватности принимающего решения. Т.е. тот самый человеческий фактор.
V>(UML здесь никаким боком от слова вообще, это из разряда "слышал звон, да не знаю, где он".)
Нее, ты видимо забыл первые выступления-статьи-конференции на тему RUP+UML == наше всё. Один в один было. И универсальность, и генерация всего по диаграммам, и one meth fith all. Туда не то что UML — CORBA приплетали. Закончилось тем, что классический UML мы видим разве что в сопроводительной документации (всё-таки то, что обычно рисуют на досках тянет разве что на "по мотивам UML"). А "старые" методики остались только в учебниках, ибо MSF сегодня и MSF 20 лет назад — две оччень большие разницы. Хотя судя по этому:
RUP и MSF не могут быть противопоставлены Agile, потому что являются надмножеством практик из Agile, т.е. включают их в себя полностью
ты сейчас про современные версии, а не про оригиналы времён расцвета Розы? Тогда всё правильно, кроме того, что речь вообще-то шла про каноничные "бронебойные" методики.
V> Т.е., я ожидаю от ЭТОЙ попытки, наконец, возможность изучать "методичку" ровно с такой степенью подробности, которая будет соответствовать "размеру" разрабатываемого ПО, и не более. Думаю, именно с этой целью товарищи и подошли к станку на этот раз.
Ты_не_поверишь. Ровно то же самое мне рассказывали про RUP EUP лет эдак двенадцать назад. Не помогло.
Re[5]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО.
Влажная мечта плохого руководителя — собрать группу говнокодеров и говноменеджеров, и с помощью магического процесса разработки получить от них годный продукт.
Плохая новость — это не работает. Вообще никогда не работает.
Здравствуйте, craft-brother, Вы писали:
CB>А что-то про SEMAT тут никто еще не написал? Исправляем.
Люди никогда не создадут ни единого бога, ни единой валюты ни единого аудиовидео-формата, ни всеобщего счастья.
Забудьте за слово "Единая". Да ещё и теория
Re[6]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, petr_t, Вы писали:
V>>Так вот, все эти ГОСТ-ы, RUP-ы и то, что я видел по ссылке — это попытка уменьшить влияние человеческого фактора на процесс разработки ПО.
_>Влажная мечта плохого руководителя — собрать группу говнокодеров и говноменеджеров, и с помощью магического процесса разработки получить от них годный продукт. _>Плохая новость — это не работает. Вообще никогда не работает.
Я не могу комментировать чьи-то мечты. Описанная тобой ситуация ни разу не новость. Гораздо обидней, когда собираются спецы, а проект заваливают. Подсказка сработала или опять мимо?))
Re[6]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, Sinix, Вы писали:
V>>Паттерны от GoF никакой не сфероконизм. Это сборник уже имеющихся на тот момент полезных практик. Полезность GoF — в попытке упорядочить эти практики, классифицировать и дать им именования, некий "алфавит". Любая предметная область начинается с терминологии и в этом плане заслуга GoF отнюдь не сфероконическая. S>В своё время — да. На сегодня любые попытки использовать паттерны "как есть" неизменно кончаются лютым фейлом типа этого
(всю тему целиком тоже можно посмотреть). Потому что или игнорируем особенности языка-фреймворка (и вместе с водой выплёскиваем ребёнка), или от паттернов остаются только названия, да и то их постоянно путают.
Ну я сам регулярно выступаю против "проектирования от паттернов". Т.е. выступаю не против них самих, а против бытующего одно время заблуждения об их всегомущей силе, что, мол, если архитектура построена сплошь на паттернах, то она уже неплоха. По мне это тоже, что заявлять, что если некий говнотекст использует некий популярный алфавит, то он заведомо шедевр... вот что-то типа этого.
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 не запрещает и никак не конфликтует с такой расстановкой "акцентов" на некоем этапе разработки.
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.
Re[2]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, beyv, Вы писали:
CB>>А что-то про SEMAT тут никто еще не написал? Исправляем. B>Люди никогда не создадут ни единого бога, ни единой валюты ни единого аудиовидео-формата, ни всеобщего счастья. B>Забудьте за слово "Единая". Да ещё и теория
Странно. А у дискретной математики получилось. Не сразу, но вышло в итоге и было признано. ))
И даже есть "Единая" теория функциональных систем, на которое ныне всё зиждется в нашей профессии и разделы которой читают прямо в ВУЗ-ах.
Re[3]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
V>Странно. А у дискретной математики получилось. Не сразу, но вышло в итоге и было признано. )) V>И даже есть "Единая" теория функциональных систем, на которое ныне всё зиждется в нашей профессии и разделы которой читают прямо в ВУЗ-ах.
Думаю значение математики сильно преувеличено, наверное самими математиками
В жизни ведь не всё дискретно.
Вы уверены что 1 + 1 = 2? Да, для двух спичек это верно — если сложить одну и одну спички получим две спички, а для двух капель воды это неверно, если сложить две капли воды получим одну каплю воды logic_error
Здравствуйте, vdimas, Вы писали:
V>Странно. А у дискретной математики получилось. Не сразу, но вышло в итоге и было признано. )) V>И даже есть "Единая" теория функциональных систем, на которое ныне всё зиждется в нашей профессии и разделы которой читают прямо в ВУЗ-ах.
Так уж и все?
До сих пор встретить реализацию КА, в которой в процессе разработки/допиливания до рабочего состояния не случилось пары-тройки state explosion, практически невозможно.
Re[7]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, petr_t, Вы писали:
V>>Гораздо обидней, когда собираются спецы, а проект заваливают. _>Видел я и такое. Как правило, когда спецы ударяются в какую-нибудь секту Теорию Разработки. Или оказываются спецами только на словах.
Не на словах. Просто "спецы" могут увлечься, могут проигнорировать составление и следование планам и графикам и т.д.
Re[4]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, landerhigh, Вы писали:
L>До сих пор встретить реализацию КА, в которой в процессе разработки/допиливания до рабочего состояния не случилось пары-тройки state explosion, практически невозможно.
Так это проблема теории или проблема людей, составивших схему неэквивалентного требуемому автомата?
Re[9]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, beyv, Вы писали:
B>Думаю значение математики сильно преувеличено, наверное самими математиками B>В жизни ведь не всё дискретно.
Математика тоже не вся дискретная
Re[5]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
L>>До сих пор встретить реализацию КА, в которой в процессе разработки/допиливания до рабочего состояния не случилось пары-тройки state explosion, практически невозможно.
V>Так это проблема теории или проблема людей, составивших схему неэквивалентного требуемому автомата?
Говорят, что теория без практики мертва. Тут именно такой случай. Формализация КА через понятия вроде алфавита, функции перехода и прочие <псевдо>научные понятия, вещь хорошая, когда нужно рассматривать парсеры или прочие абстрактные автоматы в вакууме. Только этот шум наливает столько воды, что большинство программистов банально теряют способность увидеть за разрабатываемый ими алгоритмом простой КА. Из простой и очень понятной концепции сделали неизвестно что неизвестно зачем.
Но на деле у инженеров не-программерских специальностей с КА дела обстоят на порядки лучше.
Re[6]: SEMAT – Единая Теория Всего Программирования?
L>Но на деле у инженеров не-программерских специальностей с КА дела обстоят на порядки лучше.
Бред сивой кобылы. Была специальность 2201, сейчас 220100, там с автоматами полный порядок. Более того, только на этой специальности преподают КА на должном уровне. Ни на какой другой специальности такого всеобъемлющего изучения этой дисциплины банально нет по программе.
Re[7]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, vdimas, Вы писали:
L>>Но на деле у инженеров не-программерских специальностей с КА дела обстоят на порядки лучше.
V>Бред сивой кобылы. Была специальность 2201, сейчас 220100, там с автоматами полный порядок. Более того, только на этой специальности преподают КА на должном уровне. Ни на какой другой специальности такого всеобъемлющего изучения этой дисциплины банально нет по программе.
Бред сивой кобылы. Банальным 110301 теорию управления и автоматику преподают так, что с автоматами проблем в принципе нет. Это если не упоминать всяких АСУТП и прочих, где изучают PLC и промавтоматизацию, где КА — это вообще основа всего.
Мои многолетние наблюдения, в том числе и за рубежом, показывают, что тру-программеров, окончивших CS специальность, способных самостоятельно реализовать нечто выходящее за рамки двух состояний, и при этом не наворотить кошмара в коде, практически не существует. Тут тебе и ад в собственно реализации, и state explosion, и превращение КА в генератор, и недостижымые и тупиковые состояния, и чаще всего все это вместе взятое.
Re[8]: SEMAT – Единая Теория Всего Программирования?
Здравствуйте, landerhigh, Вы писали:
L>Банальным 110301 теорию управления и автоматику преподают так, что с автоматами проблем в принципе нет.
Там только ТАУ/САУ дают более глубоко, что к теории автоматов никаким боком.
L>Мои многолетние наблюдения, в том числе и за рубежом, показывают, что тру-программеров, окончивших CS специальность
Мои наблюдения западных коллег показывают, что вообще непонятно, чему там учат программистов. Языкам и библиотекам, походу.
L>способных самостоятельно реализовать нечто выходящее за рамки двух состояний, и при этом не наворотить кошмара в коде, практически не существует. Тут тебе и ад в собственно реализации, и state explosion, и превращение КА в генератор, и недостижымые и тупиковые состояния, и чаще всего все это вместе взятое.
А у нас многие программисты имеют непрофильное образование. Просто программирование здесь заметно лучше кормит (в сравнении с другими инженерными дисциплинами) и многие в итоге переучиваются на программеров, от физиков/математиков до радиотехников.
Re[8]: SEMAT – Единая Теория Всего Программирования?
Не хочешь поделиться опытом, хотя бы в двух словах. Применяли ли НКА вместо ДКА, например? Или, как в классике, насильно вводили "эквивалентные процессы", то бишь, разбивали автомат на подавтоматы, то бишь, отказывались от конечности автомата, получая почти МТ в итоге? ))
Я наблюдал и каноничнейший сертифицированный RUP, рассыпавшийся именно из-за следования процессам, и самоорганизацию из бардака в процессы, вполне укладывающиеся в CMMI3. Единственная корреляция — уровень адекватности принимающего решения. Т.е. тот самый человеческий фактор.
