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

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

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

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

- системные требования;

- требования к ПО;

- требования к аппаратному обеспечению;

- требования к информационному обеспечению

- организационные требования.

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

- описание модулей;

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

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

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

- тест требования;

- тест-план;

- отчёт о тестировании (прогоне теста).

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

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

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

Далее идёт разработка системных требований, т.е. требований ко всему разрабатываемому изделию, детально определяющих все свойства будущего продукта (SYS – System requirements). Далее, обычно, удаётся определить, какую часть работы в системе будет выполнять аппаратура, какую программное обеспечение, а какую человек.

Поэтому, на основе SYS-документации составляются требования к ПО (SRD – Software Requirements Document), которые детализируют все требования SYS, относящиеся к программной части. Эти требования также являются частью конечного продукта. Основная задача требований к ПО – это определить что должна делать система, а не как она это будет делать. Параллельно идёт уточнение требований к аппаратной части (HRD – Hardware Requirements Document) и разработка организационных требований, включающих в себя описание необходимых для разработки документов и установление процессов взаимодействия в команде разработчиков.

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

Каждая функциональная область делится на модули, которые в свою очередь могут снова делиться на модули. Требования к модулю, описание его работы и его интерфейсы описываются в документе DDD (Detailed Design Description), который также входит в состав конечного продукта. Здесь уже можно определять как должен работать модуль, однако и тут степень детализации может быть разной и часть алгоритмических решений может быть оставлена кодировщику.

Под интерфейсом модуля (или функциональной области) понимаются все функции, типы, константы и переменные используемые для взаимодействия модуля с другими модулями, т.е. все что связывает модуль с «внешним миром».

Таким образом возможно отделение реализации модуля от «внешнего мира», для других модулей будет доступен только интерфейс, а про реализацию они могут ничего не знать. Если реализация некоторого объекта не доступна для других модулей, а доступ происходит лишь на уровне экспортируемых модулем функций, то можно говорить об абстрактном или скрытом типе. Использование абстрактных типов упрощает разработку и повышает надёжность общей системы.

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

После разработки кода программы начинается этап тестирования (верификации), заключающийся в проверке соответствия поведения кода отдельных модулей DDD-требованиям, собранных функциональных областей требованиям к функциональным областям, собранной в целом системе функциональных областей – SRD-требованиям к ПО. Готовая система тестируется совместно с аппаратной частью определённой в HRD, и в совокупности проверяется соответствие требованиям к системе SYS. На каждом этапе тестирования формируются отчёты о тестировании (или отчёты о прогоне тестов). Иногда такие отчёты могут составлять часть конечного продукта или предоставляться представителям сертифицирующего органа.

Необходимо заметить, что все этапы разработки не являются независимыми, а наоборот постоянно происходит «трансляция» одного описания в другое – более детальное. При этом на каждом этапе разработки требований так же идёт проверка соответствия текущих требований требованиям уже определённым в предыдущем документе, т.е. соответствие SYS – SRD, соответствие SRD архитектуре программной системы, и т.д. Часто ведётся трассировка требований – т.е. для любого требования можно проследить требование, из которого оно было определено. При этом первичными требованиями является SYS.

Ф. Брукс [10] даёт следующую оценку трудоёмкости для основных этапов ЖЦ разработки ПО:

- 1/3 – планирование и разработка требований;

- 1/6 – архитектура и кодирование;

- 1/4 – тестирование модулей;

- 1/4 – системное тестирование.

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

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

Дата добавления: 2014-12-26