11. Сквозной структурный контроль

Первым серьезным испытанием проектных решений должна быть их сквозная проверка некоторой группой специалистов.         Часто на этом этапе могут быть вскрыты весьма существенные ошибки. Однако цель здесь состоит не в том, чтобы обязательно доказать необходимость переделки программы, а в том, чтобы выявить вероятные ошибки. Если ошибки обнаружены, тогда разработчики должны пересмотреть программу, и весь цикл может быть повторен сначала. Не следует бояться многократного повторения этой последовательности действий, так как нужно помнить, что исправление ошибок на стадии проектирования обходится недорого. Гораздо дороже будет стоить ошибка, оставшаяся необнаруженной вплоть до заключительной проверки готовой программы. Поэтому важно выработать правильное отношение к процедуре выявления ошибок в проектных решениях и не заниматься критикой разработчиков, а помогать им получить “чистый” проект. Очевидно также, что при негативном отношении к проекту со стороны группы контроля гораздо труднее бывает обеспечить эффективное сотрудничество всех участников разработки. Именно по этой причине руководителей проекта обычно исключают из участия в процессе структурного контроля. Поддержание деловой атмосферы, когда целью проверки не .является отыскание виновных в допущенных ошибках, должно способствовать более тщательному поиску ошибок каждым специалистом, включая и самих разработчиков.

Прежде всего проводите ручную проверку.

       Проверка проектных решений должна охватывать лишь верхние уровни разработки, а именно контролировать правильность системной логики и сопряжений модулей. Когда проект утвержден, он не должен содержать ошибок, исправление которых требует корректировки сразу нескольких модулей программы. Такие ошибки должны выявляться на этапе проектирования.         Еще один широко распространенный способ проверки правильности проектных решений — это предварительное написание программ системы на языках APL или БЕЙСИК. Хотя такой подход связан с довольно большим объемом дополнительной работы, это окупается в случае необходимости внесения изменений в проект.

Старайтесь проверять правильность принципов построения системы на ее простом варианте.

       Структурный контроль должен тщательно планироваться самим разработчиком с учетом того, что необходимо иметь от четырех до шести рецензентов в качестве которых обычно выступают испытатели, проектировщики и документалисты. Предполагаемые рецензенты должны получать материалы за 4—6 дней до проведения совещания по их рассмотрению, чтобы иметь возможность ознакомиться с ними и быть готовыми к обсуждению любых проблем. При проведении совещания всегда следует руководствоваться определенной целью и ограничиваться по времени двумя часами. Если этого времени недостаточно, то лучше запланировать дополнительную встречу. Председательствующий должен обеспечить рабочую обстановку и составление полного списка ошибок, неувязок и противоречий, которые отнюдь не должны быть устранены сразу же, в ходе совещания. Разработчик обязан заняться этим позже и сообщить о принятых мерах.         В начале совещания по проверке структуры рецензенты характеризуют степень завершенности проекта в целом, точность выполнения выдвинутых требований и качество проектных решений. Затем разработчик делает краткий обзор всех элементов программного обеспечения, При этом возможна демонстрация работы программ на контрольных примерах, результаты которых подвергаются групповому анализу. По окончании совещания председательствующий вручает каждому члену группы список выявленных проблем, требующих решения. Разработчик обязан затем разрешить отмеченные проблемы и довести до сведения рецензентов, какие были предприняты действия по их замечаниям.         Необходимо, однако, установить допустимое количество обнаруживаемых ошибок. Это означает, что, если выявлено 5—10 ошибок, сквозной контроль должен быть приостановлен для проведения тщательного анализа проекта и устранения основных ошибок. Только после этого имеет смысл продолжить сквозной контроль. Нецелесообразно тратить время на выявление двух-трех десятков ошибок, поскольку такое их обилие будет говорить лишь о том, что весь проект нуждается в переделке и его частичная корректировка не спасет положения. Стратегия проведения сквозного структурного контроля хорошо описана в работе.