Поддержка процесса тестирования при промышленной разработке программного обеспечения

26.1.3. Аудит процессов разработки и верификации

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

Внутренние аудиты проводятся силами службы качества предприятия, а аудиторы назначаются из числа опытных сотрудников. Цель таких аудитов - текущий контроль системы менеджмента качества предприятия, позволяющий своевременно выявить проблемы.

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

В отличие от процесса верификации, который проверяет качество разрабатываемой программной системы, аудит в составе процесса управления качеством направлен на проверку технологических процессов - как разработки, так и верификации. Так, верификация отвечает на вопрос "разработана ли программная система в соответствии с требованиями?", а аудит менеджмента качества отвечает на вопрос "соответствовали ли процессы разработки и верификации установленным нормам и схемам технологических процессов, определенных в стандартах проекта и/или предприятия?".

Т.е. аудит качества процессов разработки - это тоже проверка соответствия, но в роли требований здесь выступают стандарты системы менеджмента качества, а в роли проверяемой системы - процессы.

Результаты аудитов используются в качестве одного из информационных потоков для проведения анализа результатов функционирования и соответствия процессов.

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

26.1.4. Корректирующие действия и коррекция процессов

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

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

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

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

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

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

26.2. Конфигурационное управление

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

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

Применение процесса конфигурационного управления является основным требованием при разработке систем, к их надежности (т.е., согласно ГОСТ 13377-75 [22] - свойству объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования), к которым предъявляются повышенные требования, в частности, при разработке бортовых авиационных систем, информационных систем большого масштаба, систем безопасности (см., например, DO-178B [7]).

Основные задачи и цели процессов конфигурационного управления (КУ) состоят в следующем [16].

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

Рассмотрим процесс конфигурационного управления в рамках документа DO-178B (Software Considerations in Airborne Systems and Equipment Certification), определяющего требования к процессам разработки авиационного бортового программного обеспечения. Требования этого стандарта к процессу конфигурационного управления являются достаточно жесткими и в целом сопоставимы с требованиями других стандартов (ISO 10007 [23], IEEE 1042 [24]).

В стандарте DO-178B определяются шесть основных процессов программного проекта, из которых три можно отнести к производственным: планирование, разработка и верификация, а три к поддерживающим: обеспечение качества, взаимодействие с сертифицирующим органом и конфигурационное управление. Производственным процессам посвящены соответственно главы 4, 5 и 6.

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