Все новости от 19 апреля 2005 г.

“Цифровой дом” и открытая проектная документация

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

Считается, что известный Интернет- ресурс, как http://sourceforge.net, содержит десятки тысяч проектов. Однако с инженерной точки зрения их на этом ресурсе на порядки меньше, так как большинство из них не содержит проектной документации. Еще отметим, что в инженерной практике (в отличие от программирования) проектов без проектной документации не бывает.

Можно ли себе представить проекты серийного автомобиля или здания, на которые не выпущена документация? Ответ однозначен — нет. А вот относительно “цифрового дома”, созданием которого сейчас озабочены ведущие ИT-фирмы мира, ответ не столь очевиден. При этом все, что связано со словом “дом”, предполагает проектную документацию, а все, что связано со словом “цифровой”, делится на две части: аппаратную, которую без проектной документации не создать, и программную — она обычно разрабатывается и без такой документации. На то, что проектная документация на программное обеспечение необходима на других этапах его жизненного цикла, в погоне за прибылью зачастую продолжают не замечать. Однако, как будет показано ниже, признаки “потепления” в этом вопросе налицо.

Я думаю, что сегодняшняя ситуация с проектной документацией — временная, ведь люди строят дома очень давно, а программируют сравнительно недавно. Можно себе представить, как выглядела “документация” на колесо через пятьдесят лет после его изобретения. Сейчас она выглядит явно иначе.

Близкий по своей сути взгляд на этот вопрос высказан в работе [5]: “Программирование, несомненно, относится к точным наукам, однако принято не доказывать правильность программ, а тестировать их. Автор программы обычно действует по некоторому алгоритму (или без оного) и после прогона ряда тестов считает, что она правильная. Затем он отправляет программу на бета-тестирование, предлагая ее посмотреть “всему миру”. Вот и все доказательства.

Если “мир” широк, как, например, у корпорации Microsoft, то многие ошибки, скорее всего, будут обнаружены. Для более узкого “мира” — так и умрем или с ошибками, или от них, если, например, проектируем программное обеспечение (ПО) для самолета, на котором полетим.

Очень часто при разработке программного обеспечения, как и в математике, правдоподобие принимают за правильность.

Математики, решая подобную проблему в течение полутора тысяч лет, придумали такой методологический прием, как доказательство. У нас нет тысячи лет, так как огромное число микропроцессоров уже проникло в различные бытовые устройства и “бунта” стиральных машин [6] и других составляющих “цифрового дома”, в которые загружены недостаточно проверенные программы, можно ожидать каждый день.

Хорошая проектная документация повышает достоверность и понятность программы. Попробуйте объяснить конструктору, что чертеж является достаточно полным решением задачи, — вам не поверят. Так почему же вам верят, когда вы предоставляете программу без документации, без объяснений не только того, как, но и почему (каким образом) она работает?

Осознавая это, в последнее время все большее значение стали придавать программной инженерии [7—9], для которой проектная документация должна являться краеугольным камнем. Ее наличие особенно важно при создании ПО для ответственных систем.

“В Лаборатории реактивного движения NASA предпринимаются попытки внедрить среди разработчиков дисциплину создания программного обеспечения. Сейчас лаборатория инвестирует 4 млн. долл. в год в реализацию инициативы, направленной на обеспечение качества ПО, которая призвана дать разработчикам возможность систематизировать и использовать набор “лучших” практических решений. При этом считается, что инициатива будет успешной лишь в том случае, если разработчиков удастся убедить в необходимости документировать свои решения.

Для рассматриваемых объектов, если пропустить срок, определяемый законами небесной механики, полет придется отложить надолго, и поэтому за точное выполнение сроков запуска приходится дорого платить, как, например, это было при создании аппарата, успешно опустившегося на поверхность Марса в 1997 г., когда ПО для него в значительной степени осталось без документации” [10].