ЖЦ разработки – основные документы

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

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

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

• системные требования;
• требования к ПО;
• требования к аппаратной части;
• организационные требования. Для процесса «Проектирование» характерны следующие документы:
• описание модулей;
• описание архитектуры моделей.

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

На рисунке (рис. 4) приведены основные документы и результаты, получаемые в ходе разработки ПО. Здесь рассматривается обобщенная модель и обобщенные типы документов. В реальной разработке, их количество существенно больше, часто возникают ситуации замены приведенных документов другими типами, добавление новых видов документов или не выполнения части этапов при разработке.
На начальном этапе формируется общее представление о будущем продукте и ставится задача (SOW – Statement Of Work). Это есть первичное описание необходимого продукта.

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

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

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

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

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

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

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

• 1/3 – планирование и разработка требований;
• 1/6 – архитектура и кодирование;
• 1/4 – тестирование модулей;
• 1/4 – системное тестирование.

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