Опубликован: 05.11.2013 | Доступ: свободный | Студентов: 543 / 46 | Длительность: 11:51:00
Лекция 3:

Основные элементы программной документации

Ключевые слова: ПО, требования заказчика

Все приказы отдавайте устно. Не оставляйте записей и документов, которые могут обернуться против вас.

Артур Блох

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

2.1. Состав и взаимосвязи документов

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

В свое время Г. Майерсом [5] была предложена модель разработки ПО как модель трансляции одного описания программного продукта в другое. Если встать на эту позицию, то надо предполагать, что первичные требования заказчика - описание продукта на языке очень высокого уровня. Коллектив разработчиков просто транслирует его поэтапно, постепенно доводя это описание до уровня машинной реализации. При этом, кроме формально исполняемых документов - программ, создаются и другие документы - эксплуатационные. Часть из них - инструкции по эксплуатации исполняют люди.

Таким образом, для процесса "Разработка требований" можно определить следующий набор документов:

  • системные требования;
  • требования к ПО;
  • требования к аппаратному обеспечению;
  • требования к информационному обеспечению;
  • организационные требования.

Для процесса "Проектирование" характерны следующие документы:

  • описание модулей;
  • описание архитектуры моделей.

Процесс "Реализация" формирует на выходе код программы.

"Тестирование" включает в себя создание таких документов, как:

  • тест-требования;
  • тест-план;
  • отчет о тестировании (прогоне теста).

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

На начальном этапе формируется общее представление о потребностях в будущем продукте и ставится задача разработки (SOW - Statement Of Work). Это обычно и есть первичное описание необходимого продукта.

Основные документы, создаваемые при разработке ПО

Рис. 2.1. Основные документы, создаваемые при разработке ПО

Далее идет разработка системных требований, т.е. требований ко всему разрабатываемому изделию, детально определяющих все свойства будущего продукта (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

Распределение трудозатрат

Рис. 2.2. Распределение трудозатрат

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

Отметим важное свойство программного текста - пишется один раз (на этапе кодирования), а читается много раз как на всех последующих этапах разработки, так и при внесении изменений в код. Поэтому "читабельность" - важнейшая черта программного текста.