Джозеф Фокс - Программное обеспечение и его разработка

понимании функций, которые должны выполняться системой,

обнаружении узких мест системы — временных ограничений и неустойчивости, вызванной входными параметрами, проектировании серии упражнений, приводящих систему в действие,

определении в тестирующей системе как аппаратных, так и программных компонент, построении тестирующей системы,

планировании фактического проведения тестирования и дирижирования им.

Для всего этого требуется и изобретательность, и широкие познания.

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

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

Часть усилий при проектировании следует направлять на то, чтобы сделать программное обеспечение легко тестируемым.

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

Структурированные программы делятся на абзацы, при их написании следуют строгим правилам, в них включаются специальные примечания. Если к тому же размеры модулей невелики, не больше 30–50 операторов на модуль, мы получаем очень хорошо читаемые программы. Прекрасным способом проведения проверок на протяжении всего процесса разработки является инспектирование программ, называемое сквозным контролем.

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

Если подобные инспекции проводятся регулярно, то в течение всего запланированного времени можно избежать любых, самых неприятных сюрпризов. Руководство становится более наглядным и простым.

Преимущества этого метода велики. Свежий взгляд позволяет избежать положения, когда «из-за деревьев не видно леса». Появились новые подходы и предостережения, позволяющие избегать ошибок.

Важным фактором становится «рабочая гордость», так как теперь видны не только результаты работы программы, но и каждая команда программы. Многие программисты сообщают, что там, где раньше они позволяли себе проявлять беспечность и небрежность при программировании (хотя никто из них этого раньше не замечал), теперь изо всех сил стараются делать все наилучшим образом. Повышенная аккуратность в работе приводит к повышению качества программ.

Член группы программистов учится у других членов своей группы, изучая их работу; он перенимает методы программирования, возможности языка, тонкости прикладной тематики. Постепенно пробелов в знаниях не остается. Инспекция программ должна стать неотъемлемой частью каждого более или менее крупного программного проекта. Подобные обзоры надо проводить не только для уже написанных программ, их следует регулярно осуществлять на всех стадиях процесса разработки. (См. рис. 5.47.)

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

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

Когда в 1965 г. приводнился корабль «Джемини V», мир затаил дыхание, ведь произошло это в 100 милях от заранее рассчитанной точки приводнения. Телевизионные комментаторы заставили весь мир поверить, что капсула может утонуть. К капсуле устремились авианосцы; через час после приводнения капсула была обнаружена вертолетами.

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

Спецификации для вычисления были правильные, однако программист решил пойти более короткой дорогой. Для вычислений следовало определить количество дней, часов, минут и секунд, прошедших со времени запуска, и, принимая Солнце в качестве неподвижного центра, рассчитать положение Земли в этой инерциальной системе. И все будет прекрасно. Программист выбрал более короткое решение и просто исключил из рассмотрения число дней полета (он разделил число часов на 24), «логично» рассудив, что по отношению к Солнцу Земля через каждые 24 ч оказывается в одинаковом положении. Это неправильно. Это было бы правильно, если Земля вращалась бы только вокруг собственной оси, а ведь она вращается и вокруг Солнца. Орбитальное движение вносит небольшие изменения в период возвращения Земли в ту же точку по отношению к Солнцу. Этот период не точно равен 24 ч. Этот «просчет» и привел к стомильной ошибке в определении места приземления.

Чья же это была ошибка? Конечно, программиста — он отклонился от проекта. Короткий путь оказался «заминированным». Но в самой программе ошибки не было; она была в формулировке решения. Сквозной контроль мог и, наверное, должен был привести к обнаружению ошибки. По крайней мере было бы обнаружено, что реализация не совсем точно следовала за проектом.

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