Программное обеспечение и его разработка - [84]
К счастью, в настоящее время уже существует множество инструментальных программ, помогающих нам проводить отслеживание требуемой информации, обеспечивающих легкий доступ к ней и возможности модификаций. И опять при разработке программ приходят на помощь вычислительные машины.
Документация должна в точности соответствовать тем целям, для которых создавалось программное обеспечение. Если программы будут работать на 500 машинах, на борту каждого корабля ВМФ США, их надо документировать более тщательно, чем программы, используемые лишь однажды и затем выбрасываемые. Документацию для этих последних программ можно составлять на оборотной стороне конверта.
Если пользователей у программы нет, составлять пользовательскую документацию не следует. Звучит это довольна глупо, но почему-то часто все-таки случается. В «Стандартах» отмечена необходимость пользовательской документации, т. е. документов, в которых говорится о том-то и том-то, поэтому руководство требует, чтобы эти документы составлялись. И вот создается двухметровая кипа документов, ни один из которых ни разу не будет использован.
Блок-схемы больше не считаются необходимыми при составлении документации, за исключением самых высоких уровней. Готовить их трудно: в клеточки блок-схем можно вписывать весьма ограниченные сведения, занимают блок-схемы много страниц, они редко поддерживаются на уровне самых новых версий. Блок-схемы могут оказать полезную помощь при проектировании, но не при документировании.
Занесение в документацию сведений о причинах принятия тех или иных решений при проектировании оказывается исключительно полезным, когда приходит время вносить в программы исправления. Почему они выбрали именно такое построение? Намеренно ли был выбран определенный путь решения определенных вещей? Почему? Если такие решения хорошо задокументировать, они помогут вносящим изменения избежать дорогостоящих ошибок. На этой стадии история проекта и заметки по решениям, принятым в проекте, могут быть очень полезными.
В общем должен еще раз подчеркнуть, что большие программные системы типа V требуют кучу документации, и так же как для эффективного проведения разработки программного обеспечения абсолютно необходима некоторая инфраструктура, так и для доводки и развития этого обеспечения необходима отличная документация.
Люди постоянно стремятся провести разграничительную линию между понятиями как и что. И это им никогда не удается, поскольку эти понятия едины и неразрывны. Все зависит от того, в каком отношении к этим понятиям вы находитесь.
Документы выполняют сразу две различные роли — во-первых, они нужны для управления разработкой, и, во-вторых, они нужны для управления продолжающейся разработкой, исправлением и использованием. В первом качестве они до некоторой степени опережают события, показывая, что предстоит сделать. С другой стороны, документация до некоторой степени «отстает», в ней фиксируется то, что уже сделано. По мере создания системы такая двойственная роль начинает доставлять все больше неприятностей. Посмотрим, почему это происходит.
Рис. 5.56. Уровни документации, применяемые в системе Министерства обороны США.
После завершения нашей разработки мы получим целую иерархию документов, несколько их уровней, каждый из которых описывает систему все подробнее.
Такие иерархии документов существуют во всех технических отраслях. Министерство обороны установило весьма формализованные правила на составления спецификаций. В общих чертах схема таких спецификаций представлена на рис. 5.56.
По мере продвижения дел в нашем проекте наступает момент, когда мы получаем возможность написать спецификацию системы. Уровень детализации, с которым надо создавать эту спецификацию, весьма проблематичен. Какую же степень подробности нужно считать достаточной?
Чтобы проектировать новую сложную систему, нам нужно подробнейшим образом изучить некоторые важные аспекты этой системы, в особенности ее отличия от предыдущих, это необходимо, чтобы система могла функционировать. Но все эти детали не являются принадлежностью спецификации системы. И все же, поскольку они у нас есть, мы испытываем искушение включить их туда. Однако они чересчур подробны для описания столь высокого уровня. Они раздражают читателя, который не понимает да и не нуждается в таких деталях.
С другой стороны, что нам необходимо для утверждения спецификаций верхнего уровня? Нам может потребоваться большое число разных сведений по различным пунктам, не входящим в данный документ, но собранным в различных местах проекта. Нам могут понадобиться черновики будущих документов или детальные эскизы и описания, содержащиеся в рабочих документах, которые, конечно же, сосредоточены на более низких уровнях.
Еще раз повторяясь, можно сказать, что после достижения некоторого уровня детализации делаются попытки перенести его на документы более высокого уровня. В этом и есть ошибка. Документация высокого уровня должна быть свободна от этих подробностей. Для сопровождения спецификаций высокого уровня можно привлекать внутренние рабочие документы, но объединять документы не следует.
