Основные элементы программной документации
Все приказы отдавайте устно. Не оставляйте записей и документов, которые могут обернуться против вас.
Технология создания ПО требует выполнить определенные работы, связанные с составлением проектной документации. Новичкам часто кажется, что написание спецификаций является не очень важной частью процесса разработки или даже ненужной тратой времени. Однако это не так, документация проекта содержит в себе все основные мысли, решения, принятые в ходе бесконечных обсуждений, договоренности и требования заказчика. Кроме того, четкая фиксация информации помогает выявить неточности и противоречия, а также определить ясную и четкую политику, которая может стать доступной всему коллективу в документальном виде. Сама же документация становится достаточно формальным описанием будущей системы и позволяет впоследствии проводить верификацию.
2.1. Состав и взаимосвязи документов
В ходе каждого процесса (этапа) разработки формируется определенный набор документов (выходные данные), которые являются входными данными для следующих процессов (этапов). Практически каждый документ базируется на ранее созданных документах и включает в себя дополнительные уточнения описания конечного продукта или связанных с его построением процессов.
В свое время Г. Майерсом [5] была предложена модель разработки ПО как модель трансляции одного описания программного продукта в другое. Если встать на эту позицию, то надо предполагать, что первичные требования заказчика - описание продукта на языке очень высокого уровня. Коллектив разработчиков просто транслирует его поэтапно, постепенно доводя это описание до уровня машинной реализации. При этом, кроме формально исполняемых документов - программ, создаются и другие документы - эксплуатационные. Часть из них - инструкции по эксплуатации исполняют люди.
Таким образом, для процесса "Разработка требований" можно определить следующий набор документов:
- системные требования;
- требования к ПО;
- требования к аппаратному обеспечению;
- требования к информационному обеспечению;
- организационные требования.
Для процесса "Проектирование" характерны следующие документы:
- описание модулей;
- описание архитектуры моделей.
Процесс "Реализация" формирует на выходе код программы.
"Тестирование" включает в себя создание таких документов, как:
- тест-требования;
- тест-план;
- отчет о тестировании (прогоне теста).
На рис. 2.1 приведены основные документы и результаты, получаемые в ходе разработки ПО. Здесь рассматривается обобщенная модель и обобщенные типы документов. Из соображений компактности изображения названия закодированы латинскими буквами. В реальной разработке их количество существенно больше, часто возникают ситуации замены приведенных документов другими типами, добавления новых видов документов или невыполнения части этапов при разработке.
На начальном этапе формируется общее представление о потребностях в будущем продукте и ставится задача разработки (SOW - Statement Of Work). Это обычно и есть первичное описание необходимого продукта.
Далее идет разработка системных требований, т.е. требований ко всему разрабатываемому изделию, детально определяющих все свойства будущего продукта (SYS - System requirements). Далее обычно удается определить, какую часть работы в системе будет выполнять аппаратура, какую - программное обеспечение, а какую - человек.
Поэтому на основе SYS-документации составляются требования к ПО (SRD - Software Requirements Document), которые детализируют все требования SYS, относящиеся к программной части. Эти требования также являются частью конечного продукта. Основная задача требований к ПО - определить, что должна делать система, а не как она это будет делать. Параллельно идет уточнение требований к аппаратной части (HRD - Hardware Requirements Document) и разработка организационных требований (ORD), включающих в себя описание необходимых документов, и установление протокола взаимодействия пользователей с программной системой.
На основе требований к ПО вся программная система разбивается на набор функциональных областей, требования к каждой области детализируются в документе, описывающем архитектуру программной системы. Здесь же описываются интерфейсы функциональных областей, и этот документ нужно рассматривать как часть конечного продукта.
Каждая функциональная область делится на модули, которые в свою очередь могут снова делиться на модули. Требования к модулю, описание его работы и его интерфейсы приводятся в документе DDD (Detailed Design Description), который также входит в состав конечного продукта. Здесь уже можно определять, как должен работать модуль, однако и тут степень детализации может быть разной, и часть алгоритмических решений может быть оставлена кодировщику.
Под интерфейсом модуля (или функциональной области) понимаются все функции, типы, константы и переменные, используемые для взаимодействия модуля с другими модулями, т.е. все, что связывает модуль с "внешним миром".
Таким образом, возможно отделение реализации модуля от "внешнего мира". Для других модулей будет доступен только интерфейс, а про реализацию они могут ничего не знать. Если реализация некоторого объекта недоступна для других модулей, а доступ происходит лишь на уровне экспортируемых модулем функций, то можно говорить об абстрактном или скрытом типе. Использование абстрактных типов упрощает разработку и повышает надежность общей системы.
На основе описаний модулей выполняется кодирование и интеграция уже с использованием особенностей выбранного языка программирования. Результат этого этапа - исполняемая программа (загрузочный модуль), соответствующая требованиям к ПО.
После разработки кода программы начинается этап тестирования (верификации), заключающийся в проверке соответствия поведения кода отдельных модулей DDD-требованиям, собранных функциональных областей - требованиям к функциональным областям (FA - Functional Areas TEST), собранной в целом системе функциональных областей - SRD-требованиям к ПО. Готовая система тестируется совместно с аппаратной частью, определенной в HRD, и в совокупности проверяется соответствие требованиям к системе SYS. На каждом этапе формируются отчеты о тестировании (или отчеты о прогоне тестов). Иногда такие отчеты могут составлять часть конечного продукта или входить в состав документации, предоставляемой сертифицирующему органу.
Необходимо заметить, что все этапы разработки не являются независимыми, а наоборот, постоянно происходит "трансляция" одного описания в другое - более детальное. При этом на каждом этапе разработки требований идет проверка соответствия текущих требований требованиям, уже определенным в предыдущем документе, т.е. соответствие SYS - SRD, соответствие SRD архитектуре программной системы и т.д. Часто ведется трассировка требований, т.е. для любого требования последующего документа можно проследить требование, из которого оно было определено в предшествующем документе. При этом первичными требованиями является SYS.
Ф. Брукс [10] дает следующую оценку трудоемкости для основных этапов ЖЦ разработки ПО:
- 1/3 - планирование и разработка требований (R);
- 1/6 - архитектура и кодирование (D+C);
- 1/4 - тестирование модулей (I);
- 1/4 - системное тестирование (I).
Считая, что оба вида тестирования относятся к (I) интеграционному процессу, получаем диаграмму распределения трудозатрат, приведенную на рис. 2.2
Из приведенной оценки и необходимых для разработки системы документов видно, что процесс кодирования является не самым большим и не самым трудоемким этапом разработки ПО, однако ключевым. Именно в ходе кодирования создается конечный продукт, ради получения которого и проводятся все вышеописанные действия.
Отметим важное свойство программного текста - пишется один раз (на этапе кодирования), а читается много раз как на всех последующих этапах разработки, так и при внесении изменений в код. Поэтому "читабельность" - важнейшая черта программного текста.