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

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

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

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

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

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

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

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

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

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

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