Гм, польщён сопоставлением моей скромной заметки с солидной книгой-обзором Одинцова. Этого делать, наверное, не стоит - я записывал конкретные идеи по интересующим лично меня моментам, не более. А именно: пытался наметить "карту" для анализа средств и механизмов какого-нибудь языка применительно к какой-нибудь сфере задач.
Я извиняюсь за большой поток мыслей ниже, просто затронуло. Воспринимайте как мысли вслух.Слова "методология", "парадигма" - всё это очень условно.... В ИТ царит большой бардак, и люди, которые хоть как-то пытаются это упорядочить, разумеется, будут делать это по-разному - разными словами и т.п.
По поводу жизненного цикла ПО - там всё с этими этапами ясно: это конкретные этапы, использующиеся в конторах-конвейерах, типа крупных аутсорсеров и т.п. Я это вообще не брал во внимание, во-первых, потому, что собственного опыта "конвейера" не имею, во-вторых, потому, что мне это малоинтересно. Собственно, в случае сложных задач и сильной небольшой команды все эти этапы интегрированы очень плотно и выполняются постоянно.
Выскажу своё имхо: в случае массовой разработки ПО самым слабым этапом оказывается именно программирование (по сто раз обсуждённым причинам низкой подготовки масс). Эта низкая подготовка сочетается ещё и с трудной управляемостью. Если о первом как-то стыдливо молчат, то о втором написано немало, в стиле "как же пасти этих котов". Что делать бедным манагерам? Изолировать программёров в конкретном звене процесса. На входе сажаются аналитики-прикладники. На выходе - тестеры. Тогда манагер может по-прежнему не вмешиваться в звено программирования ("пусть эта банда работает, как хочет..."), но программёры оказываются зажатыми жёсткими документированными КПП на входе и выходе. Что, конечно, не позволяет получить высококачественный результат, но съедобный продукт + управляемый процесс для массовых задач - вполне.
На самом же деле, возьмём то же тестирование. Классическая дисциплина разработки предполагает тестирование не чёрного, а белого ящика (т.е. с известным внутренним устройством), притом теми же людьми, которые его разрабатывают (которые от и до понимают, какие именно критические точки и граничные случаи следует проверять). Правильность гарантируется не тестами, а обоснованным построением программы + defensive-style реализацией. Тесты разрабатываются во многом ещё ДО написания программы - и в первую очередь помогают понять саму спецификацию задачи, выловить подводные камни для проектирования (те самые критические точки и граничные случаи), проверить правильность используемой модели. А уже в конце они срезают небольшое количество случайных ляпов на уровне "опечаток" в коде.
Испытания же "чёрного ящика" (т.е. отделённое от разработчиков и без учёта внутреннего устройства системы) вообще в инженерии выполняется обычно на стороне заказчика, при приёмке. И служит не выявлению ошибок, а в первую очередь демонстрационным целям и "для галочки". Просто в области софтвера даже собственная компания часто вынуждена ставить себя в положение внешнего заказчика по отношению к программёрам, "запертым в изолированной палате".
Касательно списка парадигм - ещё раз говорю: всё это очень условно. Не воспринимайте это как классификацию, а просто как перечисления того, что есть и что знает конкретный автор...
Вот есть ООП, + кроме mainstream есть оно в чисто рафинированном виде, как отдельное интересное направление (языки типа Smalltalk) - и пишет Одинцов пунктик "ООП". И воспринимать этот пунктик надо не как некую фундаментальную категорию, а просто как переданную вам "зарубку" о том, что есть вот такая вот отдельная штука...
А вообще говоря, и "чистое ООП" тоже предполагает явное описание последовательности событий - а значит, вроде бы, императивно. А с другой стороны, "нечистое ООП", как именно концепция и возможности - это возможность расширения системы без её переписывания (поддержка принципа "рыба-селёдка" и возможности в систему, работающую с "рыбами", вводить разных "селёдок" без изменения уже существующей части) - и поэтому вообще можно говорить об наличии или отсутствии ОО при абсолютно любой парадигме, хоть императивной, хоть неимперативной.
А если Вам хочется именно строгой и аккуратной классификации.... То с этим трудно. В конечном счёте, классификация - это обычно точка зрения на проблему. Построенная с конкретными целями. Правда, точки зрения тоже бывают более или менее объективными.
Можно точно сказать, что хорошая классификация никогда не будет включать в себя длинные списки а) б) в) г).... (это просто перечисление, см. выше - и хороший автор всегда это явно укажет, а не будет имитировать наукообразие словом "классификация").
Наиболее чётко делить вообще, наверное, можно дихотомически, надвое - тогда можно подбирать некий индикатор, признак - "горит-не горит, есть-нету". Поэтому деление на императив-декларатив, видимо, неплохое деление. Чёткий признак есть (задаётся преимущественно последовательность событий либо задаются преимущественно информационнные соотношения). А попытки дотыкивать кучу пунктов, как то - отдельно ФП, отдельно ООП и т.п. - видимо, не слишком полезная затея. (Это вот как в ветке о двух умотипах: Info21 ввёл некое чётко наблюдаемое и полезное деление, с ясным индикатором; а многим хочется сразу наплодить уровней 1-2-3-4-5...).
(Позволю себе ещё абзац "лирики": у харьковско-белгородской школы теории систем (проф. С.И. Маторин и коллеги его) есть гипотеза о том, как получать естественную классификацию: если для некоей "вилки" в этой классификации А есть такая же (изоморфная, мат. языком) "вилка" в классификации В свойств, присущих объектам из классификации А. Интересная мысль, и конкретные результаты у них есть - в частности, альтернативу УДК они делали и некоторые классификации для госструктур типа МЧС).
Ещё раз пардон за многословие.