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

Средства проверки соответствий могут быть различны: логический анализ, структурный анализ, формальные инспекции, тестирование. В процессе планирования должны быть определены процедуры и методы верификации, применяемые на различных шагах процесса разработки к различным видам документов.

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

В зависимости от уровня критичности программного обеспечения в ГОСТ Р 51904-2002 устанавливаются различные уровни детальности проверки программного кода в процессе верификации:

a) проверка того, что все требования к программному обеспечению реализованы (100%-е покрытие требований в процессе тести-рования);

b) проверка того, что выполнено требование (а) и при этом все команды программного кода были выполнены в процессе тестирования (100%-ное покрытие кода в процессе тестирования);

c) проверка того, что выполнено требование (b) и при этом все ветви программного кода были выполнены в процессе тестирования (100%-ное покрытие ветвей программного кода в процессе тестирования);

d) проверка того, что выполнено требование (с) и при этом все условия разветвления программного кода были независимо проверены в процессе тестирования.

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

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

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

Поэтому выполнение тестирования по уровням требований (b) и (c), как правило, можно рассматривать в рамках концепции "серого ящика". Такой подход предполагает использование при исследовании объекта некоторых свойств его структуры. Но надо заметить, что эти сведения должны привлекаться только для анализа причин непокрытия кода. Ни в коем случае они не должны использоваться для прогнозирования ожидаемой реакции программы.

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

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

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

Базовым понятием процесса является (Configuration Item) объект (Элемент) конфигурационного управления (ОКУ). Под объектами конфигурационного управления могут пониматься все основные результаты деятельности проекта. Такие результаты идентифицируются и контролируются с помощью процесса управления конфигурациями. Объектами конфигурационного управления могут быть элементы аппаратуры, программы, документация, процедуры и материалы обучения, средства обслуживания и т.д. В целях идентификации объектам конфигурационного управления могут быть присвоены номера.

Еще один термин, используемый в процессе конфигурационного управления - базовая конфигурация (Baseline). Под базовой конфигурацией (БК) понимается объект конфигурационного управления (отдельный элемент или совокупность элементов), который прошел процедуру утверждения и может быть изменен только в рамках процедуры управления изменениями.

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

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

Таким образом, процесс конфигурационного управления призван обеспечивать следующее:

1. Объективность и контролируемость данных проекта.
2. Доступность и восстанавливаемость данных проекта, включая объектные коды программ (например, объектный код может не храниться, но хранится исходный код и зафиксирована процедура трансляции).
3. Контролируемость входных и выходных данных процедур проекта, что обеспечивает их целостность и повторяемость.
4. Точки контроля, возможность вычисления статуса конфигурации и управления изменениями через управление ОКУ и создание БК.
5. Фиксацию проблем и отслеживание принятых по ним решений.
6. Возможность прослеживания состояния проекта путем контроля выходных данных его жизненного цикла.
7. Гарантии соответствия производимой продукции предъявляемым к ней требованиям.
8. Ограничения доступа и сохранность ОКУ

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

Обозначения:

* - цель должна быть удовлетворена для документов данной категории; пробел - удовлетворение цели на усмотрение разработчика.

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

Синхронизацию всех процессов должен гарантировать процесс обеспечения качества программной разработки.

Обеспечение (гарантия) качества - это совсем не тестирование и не верификация результата. Основная задача процесса (Software Quality Assurance Process) - наблюдение за соблюдением стандартов проекта. При этом записи, ведущиеся в рамках процесса (quality records), являются составной частью документации проекта и попадают под конфигурационное управление.

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

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

Дополнительно в документе определяются требования к используемому инструментарию, документации по заимствованным компонентам, правила сертификации и т.п.

Вопросы и задачи для самостоятельного решения

• Какие виды требований вам известны?
• В чем разница между функциональными и системными требованиями?
• Что такое организационные требования?
• Составьте функциональные требования для программы расчета периметра треугольника.
• Что такое интерфейс функции? Относятся ли используемые функцией глобальные переменные к ее интерфейсу?
• Зачем нужна спецификация?
• Описывает ли спецификация алгоритм программы?
• При помощи каких приемов требования отделяются друг от друга и от комментариев к ним?
• Зачем нумеровать требования? Составьте спецификацию для программы расчета периметра треугольника.
• Что должна обеспечивать трассируемость документации?
• Зачем нужен процесс конфигурационного управления?