Мифический человеко-месяц или как создаются программные системы

ОглавлениеДобавить в закладки К обложке

Глава 6 Донести слово

Он сядет здесь и будет распоряжаться: «Сделайте это! Сделайте то!» А дело и с места не сдвинется.

ГАРРИ С. ТРУМЕН. «О ПРЕЗИДЕНТСКОЙ ВЛАСТИ»[1]

Как менеджеру, имея опытных дисциплинированных архитекторов и достаточное число исполнителей, добиться того, чтобы все услышали, поняли и выполнили решения архитектора? Как группе из 10 архитекторов поддерживать концептуальную целостность системы, над которой трудится 1000 человек? Для достижения этого при осуществлении программы проектирования аппаратной части System/360 была разработана целая технология, которая в равной степени применима для проектов создания программного обеспечения.

Письменные спецификации — руководство

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

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

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

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

Единство «Принципов работы System/360» проистекает из того, что у них было лишь два автора: Джерри Блау и Андрис Падега. Авторами идей являются порядка десяти человек, но если требуется соблюсти согласованность описания и продукта, отливку решений в прозаические спецификации должны осуществлять не более двух человек. Для написания определения требуется принять массу мини-решений, которые не столь важны, чтобы выносить их на всеобщее обсуждение. Для System/360 примером служат подробности того, как после каждой операции устанавливается код условия. Однако задача всеобщей согласованности таких мини-решений не является тривиальной.

Думаю, что лучший виденный мной образец руководства — это написанное Блау приложение к «Принципам работы System/360». В нем тщательно и точно описаны границы совместимости System/360. Дано определение совместимости, предписывается, к чему нужно стремиться, и перечислены те области внешних проявлений, где архитектура намеренно молчит, и где результаты, полученные на разных моделях, могут отличаться между собой, где разные экземпляры одной модели могут дать различные результаты и даже один и тот же экземпляр может давать различия после конструктивных изменений. Это уровень точности, к которому стремятся составители руководств. Они должны одинаково описывать как то, что можно делать, так и то, что делать нельзя.

Формальные определения

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

Рассмотрим достоинства и слабости формальных определений. Как отмечалось, формальные определения являются точными. Они тяготеют к полноте: пробелы заметнее, а потому скорее восстанавливаются. Их недостаток — трудность понимания. На английском языке можно описать структурные принципы, очертить структуры по этапам или по уровням и привести примеры. Легко отметить исключения и подчеркнуть противоположности. Еще важнее, что можно объяснить причины. Предлагавшиеся до сих пор формальные определения вызывали восхищение своей элегантностью и уверенность в их точности. Но они требовали текстуальных пояснений для облегчения изучения своего содержания. По этой причине я полагаю, что в будущем спецификации будут состоять как из формальных, так и из текстовых описаний.


-= 24 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня