ГОСТ 51904-2002

Второй этап работы

Соображения

Работа над программной реализацией должна начинаться с проектирования основной последовательности действий и/или основных информационных объектов, подлежащих обработке. Последнее предпочтительней, так как дает хорошее основание к модульной декомпозиции программы. Если проще представить себе процедурную форму описания, то, записав последовательность проектируемых действий в виде предложений естественного языка, можно затем проанализировать глагольные группы и существительные. Существительные, особенно подлежащее, часто являются хорошими кандидатами для информационных объектов. Глаголы - кандидаты в процедуры (операции над объектами). Например, в нашем случае:

(1) вести входную строку;

(2) если строка пустая, то закончить работу;

(3) преобразовать входную строку;

(4) вывести преобразованную строку;

(5) ввести очередную входную строку и вернуться к действию (2).

Даже самый простой предварительный анализ подобного описания позволяет нам выделить основной объект - входную строку и список действий: ввести, преобразовать, а также операцию проверки состояния "строка пустая". Если продолжать декомпозицию дальше, то легко можно выделить объект сообщение и соответствующую ему операцию - вывести. Конечно, многие проектные решения определяются программистом на основании его собственного опыта, интуиции, но во всех случаях рекомендуется рассматривать и оценивать несколько вариантов. Например, форма представления строки - список в связном прелставлении или массив; параметр процедуры вывести сообщение - текст сообщения или его номер и т. п.

Выводы

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

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

Одним из принципиальных моментов, является использование не «водопадной» модели жизненного цикла проекта, выделяющей его отдельные стадии (этапы), а процессной модели. Таким образом, в рамках ГОСТ 51904-2002 и DO-178B программный проект и производство программного продукта рассматриваются как совокупность параллельно текущих и взаимодействующих процессов.

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

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

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

Прослеживание тассируемости должно обеспечивать проверку того, что

- все требования отображаются на архитектуру ПО и отражены в требованиях более низкого уровня;

- все требования реализованы в программном коде;

- все требования проверены в процессе верификации ПО;

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

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

Категория A – катастрофическая: отказная ситуация, которая препятствует безопасному функционированию объекта управления.

Категория B – опасная/критическая: отказная ситуация, которая приводит к уменьшению возможностей объекта управления или способности персонала справится с неблагоприятными эксплуатационными режимами, при которых возникают:

- большое снижение гарантийных резервов или функциональных возможностей;

- крайне тяжелое положение или перегрузки, которые могут вызвать неточное или неполное выполнение задачи:

- неблагоприятные или потенциально фатальные воздействия для окружающей среды.

Категория C – существенная: отказная ситуация, которая приводит к снижению возможностей объекта управления или способности персонала справится с неблагоприятными эксплуатационными режимами справится, при которых могут возникать, например, большое снижение гарантийных резервов или функциональных возможностей, перегрузки или условия вызывающие ухудшение работоспособности персонала.

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

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

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

Различные программные компоненты могут иметь различные жизненные циклы. Возможный пример иллюстрируется рисунком 3. Так, компонента 1 проходит в процессе реализации типичный жизненный цикл, а компонента 2 минует фазу проектирования, что может быть осуществлено из-за ее структурной простоты, позволяющей произвести кодирование прямо на основании сформулированных требований. В свою очередь, компонента 3, являющаяся заимствованным программным кодом, сразу после определения требований может быть вовлечена в процесс интеграции.

Рисунок 6. Варианты жизненных циклов программных компонент

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

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

Задачи процесса планирования включают в себя:

- определение процедур процесса разработки и интеграционных процессов, обеспечивающих выполнение требований к разрабатываемой системе (требований функциональных и требований по безопасности);

- определение жизненного цикла программного обеспечения;

- определение инструментария программного проекта;

- определение необходимых стандартов программного проекта;

- определение состава документации в соответствии с требованиями и уровнем критичности программного обеспечения.

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

Не вдаваясь в детали требований приложения можно сказать, что для уровней критичности A, B и C, требования по составу документов идентичны. А для разработки программного обеспечения, относящегося к уровню D, они значительно ослаблены. Так для уровня D не является обязательным определение критериев перехода от одной процедуры жизненного цикла к другой, фиксация инструментальных средств, разработка стандартов. Принципиально необходимым считается только определение процедур интеграционных процессов и процессов разработки программного обеспечения.

В свою очередь требования к конфигурационному управлению документами процесса планирования идентичны для уровней A и B, но упрощены для программных проектов уровня C и D.

Процедуры процесса разработки включают в себя:

- разработку требований;

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

- кодирование;

- интеграцию программного кода.

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

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

При этом можно упрощенно рассматривать процесс разработки как процесс последовательной трансляции

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

- требований высокого уровня в требования низкого уровня;

- требований высокого и низкого уровней в проект (архитектуру) программного обеспечения;

- архитектуры программного обеспечения в его код;

- требований и кода в верификационные (тестовые) планы и т.д.

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

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

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

- проверку соответствия разработанных требований к программному обеспечению требованиям к системе в целом;

- проверку соответствия разработанных требований низкого уровня требованиям высокого уровня и требованиям к системе в целом;

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

- проверку соответствия требований и реализованного программного кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Объективность и контролируемость данных проекта;

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

3. Контролируемость входных и выходных данных процедур проекта, обеспечивая их целостность и повторяемость;

4. Точки контроля, возможность вычисления статуса конфигурации и управления изменениями через управление ОКУ и создание БК;

5. Фиксацию проблем и отслеживание принятых по ним решений;

6. Возможность прослеживания состояния проекта путем контроля выходных данных его жизненного цикла;

7. Гарантии соответствия производимой продукции предъявляемым к ней требованиям;

8. Ограничения доступа и сохранность ОКУ.

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

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

Синхронизацию всех процессов во многом обеспечивает процесс обеспечения качества программного обеспечения

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

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

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

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

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

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