Данный шаг тоже нередко пропускается и задача сразу направляется тестировщику.

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

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

А с ним в дальнейшем придется работать (корректировки по результатам испытаний - допусков к ОЭ или ПЭ, по результатам прохождения ОЭ, при модификации функций в ходе сопровождения ИС), в том числе и после сдачи проекта.

Дублирующие функции. Представьте, вы регистрируете операции в ИС в течение определенного периода, а потом делаете промежуточные отчёты - вроде ОК, делаете сводный отчёт, а цифры начинают не биться между ним и промежуточными. Потому что вместо того, чтобы одинаковую логику обрабатывали одни и те же функции, были введены дублирующие. А впоследствии было изменение методики расчета. И эти изменения были отражены в логике работы ИС, но таким образом, что была исправлена только одна из дублирующих функций. И получаем результат, что сводный отчёт был исправлен и считает по новой методике, а часть промежуточных отчётов - считает по старой логике.

А ведь что стоило при внедрении проводить контроль на дублирование? И ладно, когда это всего лишь отчёты, а ведь случаи могут быть и намного серьезнее.

Мусор. Представьте другую ситуацию. Разработчику ставят задачу поменять ту или иную логику. Код старый, документации - нет (кстати, документация это не только бюрократия, это ещё и возможность быстро разобраться какая функция/объект за что отвечает), разработчиков этого кода тоже нет. И вот разработчик начинает разбираться в коде. Минут 20 тратит на разбор очень странной конструкции, которая мало того, что странно реализована, так ещё и написана ровно в 1 строку.

И все бы ничего, но когда она заканчивается чем-то а-ля where (1=0), то есть никогда и ни при каких обстоятельствах ее код не выполняется... В общем, мусор приводит к излишним трудозатратам в дальнейшем, когда система уже находится в промышленной эксплуатации.

Иными словами, перед тем, как отправить задачу в тестирование, нужно проверять код как минимум на правильность оформления, в том числе на наличие комментариев, на отсутствие дублей и мусора в коде.

Полностью цепочка этапов разработки - здесь. Полный перечень результатов по этапам проекта - здесь.