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

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

Целый ряд исследований показал, что источником примерно половины всех ошибок в программном обеспечении больших систем являются проектные недоработки. Следовательно, именно на стадии проектирования следует ликвидировать пагубные последствия программных ошибок, которые могут проникать в проект либо по вине разработчиков, либо из-за расплывчатой формулировки целей заказчиками программного обеспечения. Однако, каковы бы ни были причины, важно, чтобы они устранялись в самому начале их возникновения.

5.8.1. сквозной-структурный контроль

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

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

Проверка проектных решений должна охватывать лишь верхние уровни разработки, а именно контролировать правильность системной логики и сопряжений модулей. Когда проект утвержден, он не должен содержать ошибок, исправление которых требует корректировки сразу нескольких модулей программы. Такие ошибки должны выявляться на этапе проектирования.

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

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

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

В начале совещания по проверке структуры рецензенты характеризуют степень завершенности проекта в целом, точность выполнения выдвинутых требований и качество проектных решений. Затем разработчик делает краткий обзор всех элементов программного обеспечения. При этом возможна демонстрация работьг программ на контрольных примерах, результаты которых подвергаются групповому анализу. По окончании совещания председательствующий вручает каждому члену группы список выявленных проблем, требующих решения. Разработчик обязан затем разрешить отмеченные проблемы и довести до сведения рецензентов^, какие были предприняты действия по их замечаниям.

Необходимо, однако, установить допустимое количество обнаруживаемых ошибок. Это означает, что, если выявлено 5—10 ошибок, сквозной контроль должен быть приостановлен для проведения тщательного анализа проекта и устранения основных ошибок. Только после этого имеет смысл продолжить сквозной контроль. Нецелесообразно тратить время на выявление двух-трех десятков ошибок, поскольку такое их обилие будет говорить лишь о том, что весь проект нуждается в переделке и его частичная корректировка не спасет положения. Стратегия проведения сквозного структурного контроля хорошо описана в работе [9].