Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы разработки программного обеспечения на примере языка С. Учебник
.pdf
неблагоприятные или потенциально фатальные воздействия для
окружающей среды.
Категория C - существенная: отказная ситуация, приводящая к
снижению возможностей объекта управления или способности
персонала справиться с неблагоприятными эксплуатационными
режимами, при которых могут возникать, например, большое снижение
гарантийных резервов или функциональных возможностей, перегрузки
или условия, вызывающие ухудшение работоспособности персонала.
Категория D - несущественная: отказная ситуация, незначительно
уменьшающая безопасность объекта и требующая действий персонала,
которые осуществимы в пределах их возможностей. Несущественная
отказная ситуация может включать в себя, например, незначительное
уменьшение гарантийных резервов или функциональных
возможностей, незначительное увеличение рабочей нагрузки персонала
или некоторое неудобство для персонала.
Одним из ключевых вопросов разработки является понятие жизненного
цикла. При этом процесс жизненного цикла программного обеспечения
рассматривается как совокупность процессов планирования и
разработки, объединяемых и взаимодействующих посредством
интеграционных процессов.
Задачей процесса планирования является определение и координация
операций процесса разработки и интеграционных процессов. Задачей
процесса разработки является собственно выпуск программного
продукта. А интеграционные процессы обеспечивают корректность,
целостность и доверие к данным разработки.
Различные программные компоненты в плане разработки могут иметь
различные жизненные циклы. Возможный пример иллюстрируется
рисунком 1.5. Так, компонента 1 проходит в процессе реализации
типичный жизненный цикл, а компонента 2 минует фазу
проектирования, что может быть осуществлено из-за ее структурной
простоты, позволяющей произвести кодирование прямо на основании
сформулированных требований. В свою очередь, компонента 3,
являющаяся заимствованным программным кодом, сразу после
определения требований может быть вовлечена в процесс интеграции.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
51
Наиболее сложный пример представлен жизненным циклом
компоненты 4. При этом предполагается, что первичные требования
реализуются и исследуются. Затем происходит уточнение требований,
реализация нового прототипа и повторная интеграция, по итогам
которой формируются окончательные требования. Завершающая стадия
включает проектирование, кодирование и окончательную интеграцию.
Таким образом, компонента 4 проходит две фазы прототипа перед
финальной фазой реализации.
При определении жизненного цикла программного обеспечения
должны быть заданы критерии начала и завершения каждой процедуры
процесса. Другими словами, должно быть сформулировано условие,
выполнение которого по отношению ко входным данным процедуры
позволяет решить вопрос о возможности ее начала. Кроме того, должно
быть сформулировано условие, анализ которого по отношению к выходу
процедуры позволяет судить о том, что процедура завершена.
Задачи процесса планирования включают в себя:
определение процедур процесса разработки и интеграционных
процессов, обеспечивающих выполнение требований к
разрабатываемой системе (требований функциональных и
требований по безопасности);
определение жизненного цикла программного обеспечения;
определение инструментария программного проекта;
определение необходимых стандартов программного проекта;
определение состава документации в соответствии с
требованиями и уровнем критичности программного
обеспечения.
Таблицы - приложения к ГОСТу дают представление о составе
документов, которые должны быть разработаны и находиться под
управлением процесса планирования. Там же определяется уровень
(категория) конфигурационного управления соответствующей
документацией.
Для уровней критичности A, B и C требования по составу документов
идентичны, а для разработки программного обеспечения, относящегося
к уровню D, они значительно упрощены. Так, для уровня D не являются
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
52
обязательными определение критериев перехода от одной процедуры
жизненного цикла к другой, фиксация инструментальных средств,
разработка стандартов. Принципиально необходимым считается только
определение процедур интеграционных процессов и процессов
разработки программного обеспечения.
В свою очередь, требования к конфигурационному управлению
документами процесса планирования идентичны для уровней A и B, но
упрощены для программных проектов уровня C и D.
Процедуры процесса разработки включают в себя:
разработку требований;
проектирование программного обеспечения;
кодирование;
интеграцию программного кода.
В процессе планирования должны быть разработаны планы
(процедуры) сертификации, разработки программного обеспечения,
верификации, управления конфигурациями и обеспечения качества. Все
эти процедуры оказываются завязаны по общим данным так, что
выходы одних являются входами для других или служат своего рода
обратной связью, позволяющей вырабатывать необходимые
корректирующие воздействия.
При планировании должны быть решены вопросы определения
инструментального и методического обеспечения процессов
жизненного цикла, организации коллектива проекта и процедур
гарантии качества.
При этом можно упрощенно рассматривать процесс разработки как
процесс последовательной трансляции:
системных требований в требования высокого уровня к
программному обеспечению;
требований высокого уровня в требования низкого уровня;
требований высокого и низкого уровней в проект (архитектуру)
программного обеспечения;
архитектуры программного обеспечения в его код;
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
53
требований и кода в верификационные (тестовые) планы и т.д.
В процессе проектирования архитектуры обычно появляются
дополнительные требования низкого уровня, часть из которых вообще
не может быть напрямую ассоциирована с требованиями высокого
уровня. Однако в большинстве случаев прослеживаемость проектных
решений сверху вниз существует и должна быть обеспечена средствами
трассируемости документации программного проекта (составная часть
средств управления конфигурациями).
Состав требований к процессу разработки не зависит от уровня
критичности программного обеспечения, вариации уровней
требований предусмотрены только для процедур конфигурационного
управления, которые могут быть ослаблены для проектов категорий C и
D по отношению к документам, описывающим архитектуру (проекта)
программного обеспечения.
Процесс верификации программного обеспечения - это не просто
тестирование. Тестирование не может показать отсутствие необходимой
функциональности. Процедуры процесса верификации должны
обеспечивать:
проверку соответствия разработанных требований к
программному обеспечению требованиям к системе в целом;
проверку соответствия разработанных требований низкого уровня
требованиям высокого уровня и требованиям к системе в целом;
проверку реализации требований высокого и низкого уровней в
архитектуре программного обеспечения;
проверку соответствия требований и реализованного
программного кода.
Средства проверки соответствий могут быть различны: логический
анализ, структурный анализ, формальные инспекции, тестирование. В
процессе планирования должны быть определены процедуры и методы
верификации, применяемые на различных шагах процесса разработки к
различным видам документов.
При доказательстве соответствия требований одного уровня другим
чаще всего используются различные виды анализа, в том числе в форме
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
54
формальной инспекции. Для верификации программного кода обычно
проводят тестирование.
В зависимости от уровня критичности программного обеспечения в
ГОСТ Р 51904-2002 устанавливаются различные уровни детальности
проверки программного кода в процессе верификации:
a) проверка того, что все требования к программному обеспечению
реализованы (100%-е покрытие требований в процессе тести-рования);
b) проверка того, что выполнено требование (а) и при этом все команды
программного кода были выполнены в процессе тестирования (100%ное покрытие кода в процессе тестирования);
c) проверка того, что выполнено требование (b) и при этом все ветви
программного кода были выполнены в процессе тестирования (100%ное покрытие ветвей программного кода в процессе тестирования);
d) проверка того, что выполнено требование (с) и при этом все условия
разветвления программного кода были независимо проверены в
процессе тестирования.
Очевидно, что требование (а) полностью ориентировано на
тестирование программного обеспечения как "черного ящика". Другими
словами, исследователь программного кода при этом рассматривает
объект исследования только снаружи. Он оказывает входные
воздействия, определяемые требованиями, и наблюдает значения на
выходе, сравнивая их с ожидаемыми (вытекающими из требований).
Никаких сведений о внутреннем устройстве (структуре и особенностях
реализации) программного кода при таком подходе не должно
использоваться.
При выполнении тестирования, соответствующего уровням требований
(b) и (с), в ряде случаев удается оставаться в рамках концепции "черного
ящика", по крайней мере, на этапе проверки требований. При таком
подходе считается, что ничего не известно о внутреннем устройстве
программы. Все заключения о ее правильном или неправильном
поведении делаются на основе анализа ее внешних, наблюдаемых
свойств.
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
55
Большинство сред поддержки тестирования (эмуляторов, отладчиков)
позволяют произвести сбор покрытий программного кода и
предоставить необходимую для анализа статистику. Но выявление
причин недостаточного уровня покрытия требует сопоставления
функциональных требований и способа их реализации в программном
коде. По меньшей мере исследованию подвергается граф управления
программы.
Поэтому выполнение тестирования по уровням требований (b) и (c), как
правило, можно рассматривать в рамках концепции "серого ящика".
Такой подход предполагает использование при исследовании объекта
некоторых свойств его структуры. Но надо заметить, что эти сведения
должны привлекаться только для анализа причин непокрытия кода. Ни
в коем случае они не должны использоваться для прогнозирования
ожидаемой реакции программы.
Причинами выявленного непокрытия могут быть как
недокументированные свойства программного кода ("закладки", "баги",
"мертвый код"), так и неполная трактовка (отображение в тесты)
требований к программному коду со стороны тестировщика. В
последнем случае в процедуру тестирования должны быть добавлены
дополнительные тесты.
Одним из важнейших поддерживающих процессов является процесс
конфигурационного управления. Основная задача процесса управления
конфигурациями - обеспечение гарантии того, что организацияразработчик имеет все необходимые данные для подтверждения факта
соответствия произведенного продукта требованиям.
Управление конфигурациями можно определить как процесс, с
помощью которого руководство проекта имеет возможность на
постоянной основе идентифицировать, устанавливать связи,
сопровождать и управлять различными компонентами проекта. Этот
процесс гарантирует целостность компонент и прослеживаемость всех
изменений, возникающих в любой момент жизненного цикла проекта.
Базовым понятием процесса является (Configuration Item) объект
(Элемент) конфигурационного управления (ОКУ). Под объектами
конфигурационного управления могут пониматься все основные
результаты деятельности проекта. Такие результаты идентифицируются
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
56
и контролируются с помощью процесса управления конфигурациями.
Объектами конфигурационного управления могут быть элементы
аппаратуры, программы, документация, процедуры и материалы
обучения, средства обслуживания и т.д. В целях идентификации
объектам конфигурационного управления могут быть присвоены
номера.
Еще один термин, используемый в процессе конфигурационного
управления - базовая конфигурация (Baseline). Под базовой
конфигурацией (БК) понимается объект конфигурационного управления
(отдельный элемент или совокупность элементов), который прошел
процедуру утверждения и может быть изменен только в рамках
процедуры управления изменениями.
Базовая конфигурация - это своего рода фотоснимок, "замороженная
ситуация" требований, спецификаций или результатов, находящихся в
разработке. Она может быть представлена документом или набором
документов. Создание базовой конфигурации - обычно фиксация
некоторого условия, возникающего при завершении каждого из
основных шагов процесса разработки.
Базовая конфигурация может состоять из совокупности однородных
документов, например совокупность требований, коды совокупности
программных модулей. Но базовая конфигурация может состоять и из
совокупности разнородных по своей сути ОКУ, например требования и
соответствующий программный код, тест-план, результаты прогона
тест-плана.
Таким образом, процесс конфигурационного управления призван
обеспечивать следующее:
1. Объективность и контролируемость данных проекта.
2. Доступность и восстанавливаемость данных проекта, включая
объектные коды программ (например, объектный код может не
храниться, но хранится исходный код и зафиксирована процедура
трансляции).
3. Контролируемость входных и выходных данных процедур
проекта, что обеспечивает их целостность и повторяемость.
4. Точки контроля, возможность вычисления статуса конфигурации и
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
57
управления изменениями через управление ОКУ и создание БК.
5. Фиксацию проблем и отслеживание принятых по ним решений.
6. Возможность прослеживания состояния проекта путем контроля
выходных данных его жизненного цикла.
7. Гарантии соответствия производимой продукции предъявляемым
к ней требованиям.
8. Ограничения доступа и сохранность ОКУ
Табл. 2.1 дает представление о составе документов, которые должны
быть разработаны и находиться под контролем процесса управления
конфигурациями. Там же определяется уровень (категория)
конфигурационного управления соответствующей документацией.
Таблица 2.1. Приложение А-8 к ГОСТ Р 51904-2002
Цель процесса управления конфигурацией
Ссылка на
раздел
КК1 КК2
Идентификация конфигурации 9.2.1 * *
Базовая линия
9.2.3 а), б), в), г),
д)
*
Трассируемость 9.2.3 е), ж) * *
Отчетность о дефектах 9.2.4 *
Контроль изменений - целостность и
идентификация
9.2.5 а), б) * *
Контроль изменений - трассируемость 9.2.5 в), г), д) *
Просмотр изменений 9.2.6 *
Отчетность о состоянии конфигурации 9.2.7 *
Получение документа из архива 9.2.8 а) * *
Защита от несанкционированных
изменений
9.2.8 б1) * *
Выбор носителей, обновление,
копирование
9.2.8 б2), б 3),
б4), в)
*
Выпуск версии 9.2.8 г) *
Хранение данных 9.2.8 д) * *
Обозначения:
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
58
* - цель должна быть удовлетворена для документов данной категории;
пробел - удовлетворение цели на усмотрение разработчика.
Различаются два уровня конфигурационного управления
документацией: КК1 и КК2. Уровень КК1 предполагает полный
контроль над конфигурациями проекта. Уровень КК2 допускает
отсутствие большой части элементов и процедур. При КК2
обязательными остаются процедура идентификации, прослеживаемость
(трассируемость), управление изменениями, доступность и сохранность
данных с соблюдением ограничений доступа (предотвращение
несанкционированных изменений).
Синхронизацию всех процессов должен гарантировать процесс
обеспечения качества программной разработки.
Обеспечение (гарантия) качества - это совсем не тестирование и не
верификация результата. Основная задача процесса (Software Quality
Assurance Process) - наблюдение за соблюдением стандартов проекта.
При этом записи, ведущиеся в рамках процесса (quality records),
являются составной частью документации проекта и попадают под
конфигурационное управление.
При выполнении проекта процесс обеспечения качества должен давать
гарантии того, что все необходимые стандарты разработаны в
соответствии с требованиями, все процедуры жизненного цикла
выполняются в соответствии со стандартами, а все отклонения от
утвержденных планов и стандартов выявляются, рассматриваются в
утвержденном порядке и устраняются. Одним из механизмов процесса
является аудит. Заметим, что задача аудита, в отличие от задачи
верификации, - поиск соответствия. Верификация и, в частности,
тестирование ориентированы на выявление несоответствий. При
аудите производится поиск соответствий, а обнаруженные
несоответствия фиксируются (один из видов записей процесса) и
предоставляются на рассмотрение руководству проекта. При этом одной
из задач процесса является предотвращение возможных
несоответствий.
Таким образом, можно рассматривать процесс обеспечения качества как
процесс-наблюдатель за другими процессами. Но это не пассивный
наблюдатель, фиксирующий нарушения. Процесс обеспечения качества
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
59
призван активно участвовать в разработке стандартов и процедур
проекта, обеспечивая выполнение требований заказчика и ГОСТ Р
51904-2002.
Дополнительно в документе определяются требования к используемому
инструментарию, документации по заимствованным компонентам,
правила сертификации и т.п.
Вопросы и задачи для самостоятельного решения
Какие виды требований вам известны?
В чем разница между функциональными и системными
требованиями?
Что такое организационные требования?
Составьте функциональные требования для программы расчета
периметра треугольника.
Что такое интерфейс функции? Относятся ли используемые
функцией глобальные переменные к ее интерфейсу?
Зачем нужна спецификация?
Описывает ли спецификация алгоритм программы?
При помощи каких приемов требования отделяются друг от друга
и от комментариев к ним?
Зачем нумеровать требования? Составьте спецификацию для
программы расчета периметра треугольника.
Что должна обеспечивать трассируемость документации?
Зачем нужен процесс конфигурационного управления?
Основы разработки программного обеспечения на примере языка СС.В. Синицын, О.И. Хлытчиев
60
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]