Промышленная разработка программного обеспечения как часть промышленной разработки сложных систем - высокотехнологичный процесс, в который вовлечено множество различающихся по численности, сфере деятельности и квалификации коллективов разработчиков. Одна из основных задач при совместной работе большого количества разработчиков или их коллективов: обеспечение единой схемы работы, позволяющей планировать выполнение работ, обеспечивать целостность и непротиворечивость различных узлов системы, а также давать гарантии соответствия системы ожиданиям заказчика.
Выполнение этой задачи облегчается при подчинении процесса разработки технологическим требованиям, регламентирующим различные аспекты разработки: жизненный цикл проекта и разрабатываемой системы, требования к процессам разработки, внедрения и сопровождения системы.
При разработке систем различного типа (информационных, встроенных, систем реального времени, систем безопасности) технологические требования могут различаться и освещать те или иные аспекты процесса разработки. Тем не менее, обычно внедрение технологии в разработку преследует одну основную цель - обеспечение и гарантию качества разрабатываемой системы. Это послужило предпосылкой к созданию документов, определяющих требования к технологии разработки систем - стандартов качества.
Согласно подходу стандартов системы качества: качество - это совокупность характеристик объекта, имеющая отношение к его способности удовлетворить установленные и предполагаемые требования потребителя. При этом, что важно, под объектом качества может пониматься как собственно продукция (товары или услуги) или процесс ее производства, так и производитель (организация, система или даже отдельный работник).
В этих стандартах определяются критерии качества продукции, специфичные для каждого из этапов жизненного цикла продукции. Основное назначение стандартов качества - определение требований к технологическим процессам, в т.ч. процессам разработки, соблюдение которых позволяет гарантировать постоянный с точки зрения выбранных критериев уровень качества создаваемых систем (Рис 26.1).
(рис 26.1) Место стандартов качества в разработке системыНеизбежные различия в процессах разработки и эксплуатации систем в разных отраслях послужили предпосылкой создания отраслевых стандартов - стандартов, которые регламентируют процессы разработки и сертификации систем, предназначенных для узкоспециального использования (авиационные двигатели, системы информационной безопасности).
Поскольку область применения стандартов качества достаточно широка (от отдельной отрасли до общей применимости), основным объектом их рассмотрения являются не конкретные методики разработки, а общие технологические процессы.
Большинство стандартов ориентированы на процессы, не зависящие напрямую от конкретного жизненного цикла системы. Для каждого процесса определяются цели и описываются средства удовлетворения этих целей. Для данных жизненного цикла в стандартах представляется описание, которое показывает, что цели удовлетворены.
Основной процесс, рассматриваемый стандартами - выпуск продукции. В случае разработки программных систем этот процесс - проект разработки программного обеспечения, вне зависимости от того, какой
Подпроцессы могут быть отнесены к трем категориям: процесс планирования программного обеспечения; процессы разработки программного обеспечения, которые обычно включают разработку требований к программному обеспечению, проектирование программного обеспечения, кодирование и комплексирование программного обеспечения; и процессы обеспечения целостности, которые включают в себя верификацию программного обеспечения, гарантию качества программного обеспечения, управление конфигурациями программного обеспечения и взаимодействие при сертификации.
Семейство стандартов ISO 9000 - группа международных стандартов, устанавливающих правила менеджмента качества при выпуске продукции. Отечественная группа стандартов, соответствующая международным ISO 9000, получила название ГОСТ Р ИСО 9000 [6]. Под понятие "выпуск продукции" попадает и разработка программного обеспечения.
При этом стандарты ISO 9000 проводят различие между требованиями к системам менеджмента качества и требованиями к продукции. Стандарт не гарантирует качество продукции - качество продукции в стандарте прямо не упоминается, тем самым он отличается от руководящих документов по проверке качества выпуска продукции различного рода (в т.ч. и программных систем).
Требования к системам менеджмента качества установлены в стандарте
Требования к продукции могут быть установлены потребителями или организацией, исходя из предполагаемых запросов потребителей или требований регламентов. Требования к продукции и в ряде случаев к связанным с ней процессам могут содержаться, например в технических условиях, стандартах на продукцию, стандартах на процессы, контрактных соглашениях и регламентах.
Кратко повторимся, сделав важное уточнение - этот стандарт может быть сформулирован следующим образом: все процессы, которые могут существенно повлиять на качество готовой продукции, должны быть документированы, за выполнение этих правил должна быть назначена персональная ответственность, регулярно должна проводиться проверка соответствия реальных процессов документированным требованиям. Важно, что обязательным требованием является установление ответственности за качество процессов.
Итак "система качества" - это совокупность организационной структуры, методик, процессов и ресурсов, необходимых для общего руководства качеством.
В основе ISO 9000 лежат 8 принципов.
Организации зависят от своих потребителей и поэтому должны понимать их текущие и будущие потребности, выполнять их требования и стремиться превзойти их ожидания.
Руководители обеспечивают единство цели и направления деятельности организации. Им следует создавать и поддерживать внутреннюю среду, в которой работники могут быть полностью вовлечены в решение задач организации.
Работники всех уровней составляют основу организации, и их полное вовлечение дает возможность организации с выгодой использовать их способности.
Желаемый результат достигается эффективнее, когда деятельностью и соответствующими ресурсами управляют как процессом.
Выявление, понимание и менеджмент взаимосвязанных процессов как системы содействуют результативности и эффективности организации при достижении её целей.
Постоянное улучшение деятельности организации в целом следует рассматривать как ее неизменную цель.
Эффективные решения основываются на анализе данных и информации.
ISO 9000 определяет следующие основные процессы верхнего уровня:
Система менеджмента качества является основой основ при достижении показателей качества. Основной задачей системы менеджмента качества является определение процессов и их применение во всей организации, последовательность и взаимодействие процессов. Эффективность работы процессов достигается управлением необходимыми для процессов ресурсами и документами. Оценка эффективности ведется при помощи мониторинга, измерения и анализа заданных для процессов критериев результативности. Все требования системы менеджмента качества фиксируются в стандартах предприятия на соответствующие процессы.
Ответственность руководства с точки зрения ISO 9000 заключается в принятии обязательств по внедрению и поддержанию на предприятии системы менеджмента качества. До сведения сотрудников должна доводиться информация о необходимости достижения заданного качества продукции, и также контролируется обеспечение процессов, ориентированных на выпуск продукции, необходимыми ресурсами. Основные документы, разрабатываемые руководством - политика и цели в области качества, определяющие текущие и будущие пути развития предприятия для достижения необходимого уровня качества.
Стандарты качества также регламентируют требования к различным этапам процесса выпуска продукции, направленные на повышение ее качества. Основная суть этих требований заключается в обеспечении максимально прослеживаемого технологического процесса, задокументированного в стандартах предприятия.
Аудит является процессом, позволяющим собирать данные о функционировании системы менеджмента качества для последующего их анализа с целью улучшения существующих на предприятии процессов. Аудиты проводятся периодически, согласно разработанной программе или внепланово, на основании анализа результатов проведенных аудитов.
Внутренние аудиты проводятся силами службы качества предприятия, а аудиторы назначаются из числа опытных сотрудников. Цель таких аудитов - текущий контроль системы менеджмента качества предприятия, позволяющий своевременно выявить проблемы.
Внешние аудиты проводят аудиторы из аудиторской компании, цель таких аудитов - подтверждение соответствия системы менеджмента качества предприятия требованиям стандарта качества.
В отличие от процесса верификации, который проверяет качество разрабатываемой программной системы, аудит в составе процесса управления качеством направлен на проверку технологических процессов - как разработки, так и верификации. Так, верификация отвечает на вопрос "разработана ли программная система в соответствии с требованиями?", а аудит менеджмента качества отвечает на вопрос "соответствовали ли процессы разработки и верификации установленным нормам и схемам технологических процессов, определенных в стандартах проекта и/или предприятия?".
Т.е. аудит качества процессов разработки - это тоже проверка соответствия, но в роли требований здесь выступают стандарты системы менеджмента качества, а в роли проверяемой системы - процессы.
Результаты аудитов используются в качестве одного из информационных потоков для проведения анализа результатов функционирования и соответствия процессов.
После проведения аудита, в случае выявления несоответствий (явно противоречащих стандартам качества случаев) и/или наблюдений (случаев, не противоречащим стандартам качества, но требующих модификации для повышения эффективности работы технологического процесса), предпринимаются корректирующие и/или предупреждающие действия.
В соответствии с требованиями стандарта
Основным документов, определяющим проблему, является записка по качеству, идентифицирующая суть проблемы и сотрудника, выявившего проблему.
Как правило, для решения выявленных и классифицированных проблем применяются три типа мероприятий: коррекция, корректирующее действие и предупреждающее действие. Термин "коррекция" имеет отношение к ремонту, переделке или регулировке и относится к устранению имеющегося несоответствия. Термин "корректирующее действие" относится к устранению причины несоответствия.
Термин "предупреждающее действие" относится к устранению причин потенциального несоответствия, дефекта или другой нежелательной потенциально возможной ситуации с тем, чтобы предотвратить их возникновение.
Таким образом, пришедшая в процесс менеджмента качества записка по качеству либо закрывается, либо порождает корректирующее/предупреждающее действие (КД/ПД), а порой и коррекцию. В зависимости от уровня значимости, поиск решений проблемы может производиться либо на уровне процесса менеджмента качества, либо на уровне руководства предприятия, процесса или отдельного проекта. Заметим, что причин несоответствия может быть несколько, и в ряде случаев единственным способом устранения является коррекция требований (стандартов).
Следует также заметить, что выполнение мероприятий по устранению причин несоответствий (КД/ПД) и самих несоответствий (коррекция) по сути являются такими же работами, как и остальные плановые мероприятия.
Процессы поддержания целостности, рассмотренные в предыдущем разделе, остаются активными в ходе всего
Основная задача данного процесса - обеспечение структурной целостности разрабатываемой системы. Все данные, входящие в проект, рассматриваются как единая конфигурация, структурная целостность которой достигается при помощи контроля всех входящих в нее компонент, обеспечения их физической сохранности, контроля и управления изменениями компонент системы.
Применение процесса конфигурационного управления является основным требованием при разработке систем, к их надежности (т.е., согласно ГОСТ 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, посвященной данным процесса разработки.
Основной задачей процесса конфигурационного управления является обеспечение гарантии того, что организация-разработчик имеет все необходимые данные для подтверждения факта соответствия произведенного продукта требованиям.
Конфигурационное управление можно определить как процесс, с помощью которого руководство проекта имеет возможность на постоянной основе идентифицировать, устанавливать связи, сопровождать и управлять различными компонентами проекта. Этот процесс гарантирует целостность компонент и прослеживаемость всех изменений, возникающих в любой момент жизненного цикла проекта.
Базовым понятием процесса является объект (элемент) конфигурационного управления (ОКУ,
Еще один термин, используемый в процессе конфигурационного управления - базовая конфигурация (Baseline). Под базовой конфигурацией (БК) понимается объект конфигурационного управления (отдельный элемент или совокупность элементов), который прошел процедуру утверждения и может быть изменен только в рамках процедуры управления изменениями.
Базовая конфигурация - это своего рода фотоснимок, "замороженная ситуация" требований, спецификаций или результатов, находящихся в разработке. Базовая конфигурация может быть представлена документом или набором документов. Создание базовой конфигурации обычно представляет собой фиксацию некоторого условия, возникающего при завершении каждого из основных шагов процесса разработки.
Базовая конфигурация может состоять из совокупности однородных документов: например, совокупность требований, коды совокупности программных модулей. Но базовая конфигурация может состоять и из совокупности разнородных по своей сути ОКУ: например, требования и соответствующие программный код, тест-план, результаты
Таким образом процесс конфигурационного управления призван обеспечивать:
Сохранность ОКУ предполагает выполнение действий по архивированию данных, находящихся под опекой процесса конфигурационного управления, и проведение аудитов конфигураций. То есть данные не только должны быть ограждены от случайного (несанкционированнного) искажения, но и сохранены на случай выхода из строя средств хранения (пожары, затопления, разрушение носителей и т.п.).
Конфигурационное управление позволяет команде разработчиков программы или проекта точно определять статус любой компоненты во все время ее жизненного цикла и дает возможность перевоссоздать любую версию в любой момент времени. Компонентами могут быть любые комбинации аппаратуры, программ, обслуживания и обучения.
Конфигурационное управление построено как композиция нескольких подпроцессов, функционирующих совместно:
Следует особенно заметить, что процесс конфигурационного управления отнюдь не заканчивается с завершением работ проекта по производству продукции. Процесс конфигурационного управления продолжает функционировать, и, возможно, весьма значительное время, обеспечивая поддержку сопровождения программного продукта.
Целью процедуры идентификации является присвоение каждому ОКУ уникального имени (кода), обеспечивающего его опознание среди прочих ОКУ. Следует заметить, что процедура идентификации с очевидностью должна предшествовать процедуре прослеживания (трассировки). В тех случаях, когда идентификация объекта не может быть достигнута путем нанесения на него идентификационного кода (например, для объектного кода программы), она должна быть обеспечена косвенным путем, например, идентификационным полем, значение которого может быть проконтролировано вспомогательным программным средством.
Процедура КУ проекта должна устанавливать систему идентификации для каждой отдельно конфигурируемой компоненты программного обеспечения. Поскольку сама компонента может при этом состоять из отдельных составных частей, то идентификация должна рекурсивно распространяться на все ее составные части до достижения уровня атомарного ОКУ (т.е. файла).
Идентификация ОКУ происходит путем помещения этих объектов в базу данных проекта. В самом простом случае база данных проекта может являться общедоступным сетевым каталогом на сервере, идентификация ОКУ и их версий при этом должна проводиться вручную.
Существует ряд систем конфигурационного управления, которые представляют собой инструменты для обеспечения коллективной работы с базой данных проекта. Эти системы берут на себя все основные функции конфигурационного управления, перечисленные выше, в т.ч. сохранность ОКУ, автоматическую нумерацию версий, предотвращение неавторизованных действий над ОКУ и учет состояния ОКУ.
Идентификатором ОКУ служит имя файла в совокупности с путем внутри базы данных. Имя файла присваивается менеджером конфигураций; он же имеет право переименовывать ОКУ.
Чтобы исключить возможность появления в базе данных проекта неправильно поименованных, неправильно размещенных и не подлежащих хранению в репозитории объектов, операции New Folder, Introduce и Rename могут выполнять только руководитель проекта и менеджер конфигураций.
Составные ОКУ идентифицируются путем составления индексов конфигураций, в которых перечисляются ОКУ (с указанием номера версии), входящие в состав конфигурации данного ОКУ. Индекс конфигурации, в свою очередь, является объектом конфигурационного управления и может входить как составная часть в другой ОКУ. Таким образом, ОКУ, в общем случае, образуют иерархию, вершиной которой является конфигурация продукта, включающая в себя все другие ОКУ.
Базовые конфигурации обычно используются как основа для перехода от одной процедуры жизненного цикла проекта к другой. В тот момент, когда процесс разработки переходит от одного шага к другому, специфические для этого шага результаты (документы, спецификации или продукты) инспектируют, чтобы убедиться в их качестве и связях (трассируемость) с предыдущими результатами. Специфические версии объектов конфигурации, принадлежащие им, идентифицируются. Когда (и если) результаты (выходы) шага прошли процедуру инспекции (только после этого), они могут быть объявлены базовой конфигурацией и становятся готовыми к использованию на следующем шаге процесса в качестве входа.
Принципиальным является то факт, что базовая конфигурация может изменяться только через процедуру Управления Изменениями. При этом требования DO-178B обязывают обеспечить прослеживаемость "происхождения" базовой конфигурации. Другими словами, должно быть обеспечено указание того, из какой предшествующей БК получена данная и с помощью какой процедуры.
В документе DO-178B применяется единственный термин "трассируемость". Он используется и для обозначения ссылок от кода программы к требованиям, и для указания на родительскую базовую конфигурацию. Возможно, что в целях более точной идентификации следует в ряде случаев различать понятия "прослеживаемость" (эволюция БК) и "трассируемость" - связи разнотипных документов (отображение преобразования входа производственной процедуры в ее выход). Обычно под трассируемостью понимается возможность идентифицировать и историю, и текущее состояние (статус) каждого объекта конфигурации в любой точке жизненного цикла проекта. Необходимой также является и возможность трассировки объектов конфигурации относительно требований заказчика как первичного входа проекта.
Большинство конфигурационных объектов в ходе жизненного цикла проекта претерпивают изменения. В процессе фиксации этих изменений возникает дерево версий, представляющее варианты объекта по степени его "завершенности". Каждая новая ветвь и лист такого дерева представляют новую версию ОКУ. Только последняя корректная версия любого объекта должна распространяться "по умолчанию" разработчикам в ответ на их запросы, устаревшие версии могут быть архивированы. При этом процедура архивирования должна обеспечивать восстанавливаемость (хранение или вычисление) любой запрошенной версии ОКУ.
Процедура управления изменениями определяет оценку и трассировку запросов на изменения, анализ потенциального влияния изменений и принятие решений по внесению изменений в объекты конфигурации. Эта процедура должна обеспечивать предотвращение "случайного" внесения изменения в базовую конфигурацию.
Реализация запросов на изменения должна включать трассировку данного изменения через процедуру фиксации проблемы, выработки и воплощения изменения, контроля его результатов и фиксации соответствующих данных жизненного цикла проекта.
Результаты процедуры внесения изменений должны инспектироваться, что, собственно, и приводит к возможности утверждения новой базовой конфигурации.
Версии (version) и Редакции (release) - эти термины иногда взаимозаменяемы. В данном документе термин "версия" используется прежде всего для ссылок на каждое новое проявление объекта конфигурационного управления, которому присвоен уникальный идентификационный номер, и подразумевает наличие цепочки ОКУ связанных отношением прослеживаемости. Другими словами, одна версия ОКУ получается из другой через процедуру управления изменениями.
Редакцией здесь называется специфическая версия объекта конфигурации, предназначенная для "внешнего" использования. Как правило, это внешнее использование - загрузка кода программы в целевой процессор или отгрузка результатов заказчику. Редакциями могут быть версии объектов, образующие комплект системы для внутреннего тестирования ("лоады", "
После того, как изменение объекта конфигурации санкционировано, обычно возникает некоторая временная задержка на время реализации изменения. Руководству и участникам проекта необходимо иметь сведения о процессе внесения изменений, а не только о факте его завершения. Процедура вычисления статуса - механизм, используемый для прослеживания эволюции каждого объекта системы и его текущего состояния.
Процедура вычисления статуса должна обеспечивать возможность реководству проекта на основании отслеживания состояний отдельных ОКУ судить о состоянии разработки в целом. Эта процедура обеспечивает проектного менеджера большим количеством данных о его продукте, включая то, как он разрабатывается и все ли требуемые свойства действительно реализованы. В конечном счете, процедура обеспечивает актуальную и объективную информацию о статусе каждого объекта конфигурации в любой момент процесса разработки, которая включает данные следующих типов данных:
Сложность процесса вычисления статусов увеличивается по мере развития разработки. Эта сложность в основном выражается в быстром росте объемов данных, которые записываются и обрабатываются.
Как уже говорилось, процедура архивирования должна обеспечивать восстанавливаемость (хранение или вычисление) любой запрошенной версии ОКУ.
Сохранность данных подразумевает не только возможность восстановления искомой версии ОКУ во все время действия процесса конфигурационного управления, но и защиту данных проекта от несанкционированного доступа. Иными словами, изменения объекта могут производиться только тем лицом, которому это изменение доверено руководством проекта.
Менеджер проекта должен быть уверен, что требуемое управление конфигурацией реализуется - другими словами, все принятые изменения реализованы, а результат представляет собой то, что специфицировано в его проектной документации. Для достижения необходимо высокого уровня доверия он должен планировать регулярные аудиты и обзоры процесса конфигурационного управления и его данных.
Требования для этих аудитов и обзоров обычно специфицируются в плане конфигурационного управления, но также они могут быть заданы в планах проекта или плане гарантии качества, как это покажется подходящим. Ответственность за нормальную реализацию аудитов конфигураций лежит на менеджере конфигураций, если эта должность предусмотрена в проекте, а если нет - на менеджере проекта или менеджере качества.
Аудитам конфигураций адресуются следующие вопросы, относящиеся к измененным объектам конфигурации.
Инструментальные средства, используемые в проекте, должны храниться в репозитории проекта. Исключением могут быть инструментальные средства внешнего происхождения (например, покупные или предоставленные заказчиком), хранение которых в репозитории может оказаться невозможным из-за их большого объема.
Хранению в репозитории проекта подлежат, как минимум, пользовательская документация, исполняемый код инструментального средства, а также иные файлы, необходимые для работы программного средства, такие, как библиотеки, базы данных, параметры настройки и т.п. Если использованию инструментального средства должна предшествовать процедура установки или генерации, то хранению подлежат все файлы, необходимые для выполнения такой процедуры.
Кроме того, инструментальные средства собственной разработки должны храниться вместе с исходным кодом и проектной документацией, а также с прочими данными, необходимыми для воспроизведения исполняемого кода данного инструментального средства.
Процедуры проекта должны точно идентифицировать конфигурацию используемых инструментальных средств. Модификация этой конфигурации допускается только через управление изменениями. Настройки СКУ должны предотвращать несанкционированное изменение инструментальных средств.
Документ DO-178B в третьем разделе седьмой главы выделяет две категории управления данными жизненного цикла программного проекта. Они соответственно названы СС1 и СС2 категории управления данными. Выбор следования той или иной категории определяется приложением А. В упрощенном виде различие между категориями можно проследить по следующим соответствиям:
идентификация объектов (СС1,СС2) формирование базовых конфигураций (СС1) обеспечение трассируемости (СС1,СС2) фиксация проблем (СС1) управление изменениями (фиксация данных) (СС1,СС2) анализ изменений (СС1) вычисление статуса конфигурации (СС1) изменения (СС1,СС2) обеспечение ограничений доступа (СС1,СС2) контроль загрузочных модулей (СС1) хранение данных (СС1,СС2)
Стандарт DO-178B обеспечивает авиационное сообщество руководящими указаниями, предназначенными для установления в конструктивной манере и с приемлемым уровнем достоверности факта того, что программное обеспечение бортовых авиационных систем и оборудование согласуются с требованиями летной годности. [7, раздел 1].
Процесс конфигурационного управления в данном стандарте рассмотрен в разделах 7 (Процесс конфигурационного управления при разработке программного обеспечения), 11.4 (План конфигурационного управления при разработке программного обеспечения) и 12.1.5 (Соображения о конфигурационном управлении при разработке программного обеспечения).
Основные цели процесса конфигурационного управления, согласно требованиям данного стандарта, включают в себя следующие положения [7, раздел 7.1].
В целом процесс конфигурационного управления, охватываемый стандартом DO-178B, направлен на поддержание целостности данных, создаваемых в ходе всех стадий жизненного цикла продукции. Основная специфика процесса КУ, регламентируемого данным стандартом, состоит в учете аспектов сертификации на летную годность, которую должно проходить все программное обеспечение, используемое в бортовых авиационных системах. Данные процесса КУ используются в качестве основных данных, предоставляемых сертифицирующему органу.
Сертифицирующим органам предоставляются индексы конфигураций - списки уникальным образом идентифицированных элементов (исходных текстов, файлов данных, объектного и исполняемого кода), входящих в программное обеспечение. Для подтверждения соответствия качества программного обеспечения заданному уровню критичности бортового ПО представляются результаты его тестирования, проведенные в соответствии с требованиями к данному уровню. Процесс конфигурационного управления должен обеспечивать трассируемость всех требований, исходных текстов, тестов и их результатов.
Для проведения сертификации все элементы конфигурации должны иметь соответствующие пометки о готовности к сертификации, а все проблемы, возникающие в ходе разработки, должны быть тем или иным образом закрыты. Данный аспект сертификации обеспечивается предоставлением информации о ведении проблем и включением сообщений о проблемах и связанных с ними запросов на изменение в индекс конфигурации, подлежащей сертификации.
Все рассмотренные выше требования являются общими требованиям к процессу КУ, но процесс разработки и выполнения бортового ПО имеет одну особенность - средой разработки служат те или иные компьютеры общего назначения, а средой времени выполнения служит соответствующее системное ПО бортового вычислителя. Стандартом DO-178B выдвигаются требования, учитывающие эту особенность: существуют требования по обеспечению поддержки процесса загрузки объектного кода приложения на бортовой вычислитель, который гарантируюет загрузку исполняемого кода с применением соответствующих мер безопасности, обеспечивающих его неизменность и целостность [7, Раздел 4.2.8].
Таким образом, система конфигурационного управления, удовлетворяющая требованиям стандарта DO-178B, должна обеспечивать идентификацию и трассируемость объектов конфигурационного управления (ОКУ), поддержку создания базовых версий (индексов конфигураций), управление сообщениями о проблемах и вызванных ими изменениях, учет состояния конфигурации и ОКУ, а также обеспечивать процессы резервного копирования и восстановления данных и управление процессом загрузки объектного кода на бортовой вычислитель.
Промышленная разработка программного обеспечения как часть промышленной разработки сложных систем - высокотехнологичный процесс, в который вовлечено множество различающихся по численности, сфере деятельности и квалификации коллективов разработчиков. Одна из основных задач при совместной работе большого количества разработчиков или их коллективов: обеспечение единой схемы работы, позволяющей планировать выполнение работ, обеспечивать целостность и непротиворечивость различных узлов системы, а также давать гарантии соответствия системы ожиданиям заказчика.
Выполнение этой задачи облегчается при подчинении процесса разработки технологическим требованиям, регламентирующим различные аспекты разработки: жизненный цикл проекта и разрабатываемой системы, требования к процессам разработки, внедрения и сопровождения системы.
При разработке систем различного типа (информационных, встроенных, систем реального времени, систем безопасности) технологические требования могут различаться и освещать те или иные аспекты процесса разработки. Тем не менее, обычно внедрение технологии в разработку преследует одну основную цель - обеспечение и гарантию качества разрабатываемой системы. Это послужило предпосылкой к созданию документов, определяющих требования к технологии разработки систем - стандартов качества.
Согласно подходу стандартов системы качества: качество - это совокупность характеристик объекта, имеющая отношение к его способности удовлетворить установленные и предполагаемые требования потребителя. При этом, что важно, под объектом качества может пониматься как собственно продукция (товары или услуги) или процесс ее производства, так и производитель (организация, система или даже отдельный работник).
В этих стандартах определяются критерии качества продукции, специфичные для каждого из этапов жизненного цикла продукции. Основное назначение стандартов качества - определение требований к технологическим процессам, в т.ч. процессам разработки, соблюдение которых позволяет гарантировать постоянный с точки зрения выбранных критериев уровень качества создаваемых систем (Рис 26.1).
(рис 26.1) Место стандартов качества в разработке системыНеизбежные различия в процессах разработки и эксплуатации систем в разных отраслях послужили предпосылкой создания отраслевых стандартов - стандартов, которые регламентируют процессы разработки и сертификации систем, предназначенных для узкоспециального использования (авиационные двигатели, системы информационной безопасности).
Поскольку область применения стандартов качества достаточно широка (от отдельной отрасли до общей применимости), основным объектом их рассмотрения являются не конкретные методики разработки, а общие технологические процессы.
Большинство стандартов ориентированы на процессы, не зависящие напрямую от конкретного жизненного цикла системы. Для каждого процесса определяются цели и описываются средства удовлетворения этих целей. Для данных жизненного цикла в стандартах представляется описание, которое показывает, что цели удовлетворены.
Основной процесс, рассматриваемый стандартами - выпуск продукции. В случае разработки программных систем этот процесс - проект разработки программного обеспечения, вне зависимости от того, какой
Подпроцессы могут быть отнесены к трем категориям: процесс планирования программного обеспечения; процессы разработки программного обеспечения, которые обычно включают разработку требований к программному обеспечению, проектирование программного обеспечения, кодирование и комплексирование программного обеспечения; и процессы обеспечения целостности, которые включают в себя верификацию программного обеспечения, гарантию качества программного обеспечения, управление конфигурациями программного обеспечения и взаимодействие при сертификации.
Семейство стандартов ISO 9000 - группа международных стандартов, устанавливающих правила менеджмента качества при выпуске продукции. Отечественная группа стандартов, соответствующая международным ISO 9000, получила название ГОСТ Р ИСО 9000 [6]. Под понятие "выпуск продукции" попадает и разработка программного обеспечения.
При этом стандарты ISO 9000 проводят различие между требованиями к системам менеджмента качества и требованиями к продукции. Стандарт не гарантирует качество продукции - качество продукции в стандарте прямо не упоминается, тем самым он отличается от руководящих документов по проверке качества выпуска продукции различного рода (в т.ч. и программных систем).
Требования к системам менеджмента качества установлены в стандарте
Требования к продукции могут быть установлены потребителями или организацией, исходя из предполагаемых запросов потребителей или требований регламентов. Требования к продукции и в ряде случаев к связанным с ней процессам могут содержаться, например в технических условиях, стандартах на продукцию, стандартах на процессы, контрактных соглашениях и регламентах.
Кратко повторимся, сделав важное уточнение - этот стандарт может быть сформулирован следующим образом: все процессы, которые могут существенно повлиять на качество готовой продукции, должны быть документированы, за выполнение этих правил должна быть назначена персональная ответственность, регулярно должна проводиться проверка соответствия реальных процессов документированным требованиям. Важно, что обязательным требованием является установление ответственности за качество процессов.
Итак "система качества" - это совокупность организационной структуры, методик, процессов и ресурсов, необходимых для общего руководства качеством.
В основе ISO 9000 лежат 8 принципов.
Организации зависят от своих потребителей и поэтому должны понимать их текущие и будущие потребности, выполнять их требования и стремиться превзойти их ожидания.
Руководители обеспечивают единство цели и направления деятельности организации. Им следует создавать и поддерживать внутреннюю среду, в которой работники могут быть полностью вовлечены в решение задач организации.
Работники всех уровней составляют основу организации, и их полное вовлечение дает возможность организации с выгодой использовать их способности.
Желаемый результат достигается эффективнее, когда деятельностью и соответствующими ресурсами управляют как процессом.
Выявление, понимание и менеджмент взаимосвязанных процессов как системы содействуют результативности и эффективности организации при достижении её целей.
Постоянное улучшение деятельности организации в целом следует рассматривать как ее неизменную цель.
Эффективные решения основываются на анализе данных и информации.
ISO 9000 определяет следующие основные процессы верхнего уровня:
Система менеджмента качества является основой основ при достижении показателей качества. Основной задачей системы менеджмента качества является определение процессов и их применение во всей организации, последовательность и взаимодействие процессов. Эффективность работы процессов достигается управлением необходимыми для процессов ресурсами и документами. Оценка эффективности ведется при помощи мониторинга, измерения и анализа заданных для процессов критериев результативности. Все требования системы менеджмента качества фиксируются в стандартах предприятия на соответствующие процессы.
Ответственность руководства с точки зрения ISO 9000 заключается в принятии обязательств по внедрению и поддержанию на предприятии системы менеджмента качества. До сведения сотрудников должна доводиться информация о необходимости достижения заданного качества продукции, и также контролируется обеспечение процессов, ориентированных на выпуск продукции, необходимыми ресурсами. Основные документы, разрабатываемые руководством - политика и цели в области качества, определяющие текущие и будущие пути развития предприятия для достижения необходимого уровня качества.
Стандарты качества также регламентируют требования к различным этапам процесса выпуска продукции, направленные на повышение ее качества. Основная суть этих требований заключается в обеспечении максимально прослеживаемого технологического процесса, задокументированного в стандартах предприятия.
Аудит является процессом, позволяющим собирать данные о функционировании системы менеджмента качества для последующего их анализа с целью улучшения существующих на предприятии процессов. Аудиты проводятся периодически, согласно разработанной программе или внепланово, на основании анализа результатов проведенных аудитов.
Внутренние аудиты проводятся силами службы качества предприятия, а аудиторы назначаются из числа опытных сотрудников. Цель таких аудитов - текущий контроль системы менеджмента качества предприятия, позволяющий своевременно выявить проблемы.
Внешние аудиты проводят аудиторы из аудиторской компании, цель таких аудитов - подтверждение соответствия системы менеджмента качества предприятия требованиям стандарта качества.
В отличие от процесса верификации, который проверяет качество разрабатываемой программной системы, аудит в составе процесса управления качеством направлен на проверку технологических процессов - как разработки, так и верификации. Так, верификация отвечает на вопрос "разработана ли программная система в соответствии с требованиями?", а аудит менеджмента качества отвечает на вопрос "соответствовали ли процессы разработки и верификации установленным нормам и схемам технологических процессов, определенных в стандартах проекта и/или предприятия?".
Т.е. аудит качества процессов разработки - это тоже проверка соответствия, но в роли требований здесь выступают стандарты системы менеджмента качества, а в роли проверяемой системы - процессы.
Результаты аудитов используются в качестве одного из информационных потоков для проведения анализа результатов функционирования и соответствия процессов.
После проведения аудита, в случае выявления несоответствий (явно противоречащих стандартам качества случаев) и/или наблюдений (случаев, не противоречащим стандартам качества, но требующих модификации для повышения эффективности работы технологического процесса), предпринимаются корректирующие и/или предупреждающие действия.
В соответствии с требованиями стандарта
Основным документов, определяющим проблему, является записка по качеству, идентифицирующая суть проблемы и сотрудника, выявившего проблему.
Как правило, для решения выявленных и классифицированных проблем применяются три типа мероприятий: коррекция, корректирующее действие и предупреждающее действие. Термин "коррекция" имеет отношение к ремонту, переделке или регулировке и относится к устранению имеющегося несоответствия. Термин "корректирующее действие" относится к устранению причины несоответствия.
Термин "предупреждающее действие" относится к устранению причин потенциального несоответствия, дефекта или другой нежелательной потенциально возможной ситуации с тем, чтобы предотвратить их возникновение.
Таким образом, пришедшая в процесс менеджмента качества записка по качеству либо закрывается, либо порождает корректирующее/предупреждающее действие (КД/ПД), а порой и коррекцию. В зависимости от уровня значимости, поиск решений проблемы может производиться либо на уровне процесса менеджмента качества, либо на уровне руководства предприятия, процесса или отдельного проекта. Заметим, что причин несоответствия может быть несколько, и в ряде случаев единственным способом устранения является коррекция требований (стандартов).
Следует также заметить, что выполнение мероприятий по устранению причин несоответствий (КД/ПД) и самих несоответствий (коррекция) по сути являются такими же работами, как и остальные плановые мероприятия.
Процессы поддержания целостности, рассмотренные в предыдущем разделе, остаются активными в ходе всего
Основная задача данного процесса - обеспечение структурной целостности разрабатываемой системы. Все данные, входящие в проект, рассматриваются как единая конфигурация, структурная целостность которой достигается при помощи контроля всех входящих в нее компонент, обеспечения их физической сохранности, контроля и управления изменениями компонент системы.
Применение процесса конфигурационного управления является основным требованием при разработке систем, к их надежности (т.е., согласно ГОСТ 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, посвященной данным процесса разработки.
Основной задачей процесса конфигурационного управления является обеспечение гарантии того, что организация-разработчик имеет все необходимые данные для подтверждения факта соответствия произведенного продукта требованиям.
Конфигурационное управление можно определить как процесс, с помощью которого руководство проекта имеет возможность на постоянной основе идентифицировать, устанавливать связи, сопровождать и управлять различными компонентами проекта. Этот процесс гарантирует целостность компонент и прослеживаемость всех изменений, возникающих в любой момент жизненного цикла проекта.
Базовым понятием процесса является объект (элемент) конфигурационного управления (ОКУ,
Еще один термин, используемый в процессе конфигурационного управления - базовая конфигурация (Baseline). Под базовой конфигурацией (БК) понимается объект конфигурационного управления (отдельный элемент или совокупность элементов), который прошел процедуру утверждения и может быть изменен только в рамках процедуры управления изменениями.
Базовая конфигурация - это своего рода фотоснимок, "замороженная ситуация" требований, спецификаций или результатов, находящихся в разработке. Базовая конфигурация может быть представлена документом или набором документов. Создание базовой конфигурации обычно представляет собой фиксацию некоторого условия, возникающего при завершении каждого из основных шагов процесса разработки.
Базовая конфигурация может состоять из совокупности однородных документов: например, совокупность требований, коды совокупности программных модулей. Но базовая конфигурация может состоять и из совокупности разнородных по своей сути ОКУ: например, требования и соответствующие программный код, тест-план, результаты
Таким образом процесс конфигурационного управления призван обеспечивать:
Сохранность ОКУ предполагает выполнение действий по архивированию данных, находящихся под опекой процесса конфигурационного управления, и проведение аудитов конфигураций. То есть данные не только должны быть ограждены от случайного (несанкционированнного) искажения, но и сохранены на случай выхода из строя средств хранения (пожары, затопления, разрушение носителей и т.п.).
Конфигурационное управление позволяет команде разработчиков программы или проекта точно определять статус любой компоненты во все время ее жизненного цикла и дает возможность перевоссоздать любую версию в любой момент времени. Компонентами могут быть любые комбинации аппаратуры, программ, обслуживания и обучения.
Конфигурационное управление построено как композиция нескольких подпроцессов, функционирующих совместно:
Следует особенно заметить, что процесс конфигурационного управления отнюдь не заканчивается с завершением работ проекта по производству продукции. Процесс конфигурационного управления продолжает функционировать, и, возможно, весьма значительное время, обеспечивая поддержку сопровождения программного продукта.
Целью процедуры идентификации является присвоение каждому ОКУ уникального имени (кода), обеспечивающего его опознание среди прочих ОКУ. Следует заметить, что процедура идентификации с очевидностью должна предшествовать процедуре прослеживания (трассировки). В тех случаях, когда идентификация объекта не может быть достигнута путем нанесения на него идентификационного кода (например, для объектного кода программы), она должна быть обеспечена косвенным путем, например, идентификационным полем, значение которого может быть проконтролировано вспомогательным программным средством.
Процедура КУ проекта должна устанавливать систему идентификации для каждой отдельно конфигурируемой компоненты программного обеспечения. Поскольку сама компонента может при этом состоять из отдельных составных частей, то идентификация должна рекурсивно распространяться на все ее составные части до достижения уровня атомарного ОКУ (т.е. файла).
Идентификация ОКУ происходит путем помещения этих объектов в базу данных проекта. В самом простом случае база данных проекта может являться общедоступным сетевым каталогом на сервере, идентификация ОКУ и их версий при этом должна проводиться вручную.
Существует ряд систем конфигурационного управления, которые представляют собой инструменты для обеспечения коллективной работы с базой данных проекта. Эти системы берут на себя все основные функции конфигурационного управления, перечисленные выше, в т.ч. сохранность ОКУ, автоматическую нумерацию версий, предотвращение неавторизованных действий над ОКУ и учет состояния ОКУ.
Идентификатором ОКУ служит имя файла в совокупности с путем внутри базы данных. Имя файла присваивается менеджером конфигураций; он же имеет право переименовывать ОКУ.
Чтобы исключить возможность появления в базе данных проекта неправильно поименованных, неправильно размещенных и не подлежащих хранению в репозитории объектов, операции New Folder, Introduce и Rename могут выполнять только руководитель проекта и менеджер конфигураций.
Составные ОКУ идентифицируются путем составления индексов конфигураций, в которых перечисляются ОКУ (с указанием номера версии), входящие в состав конфигурации данного ОКУ. Индекс конфигурации, в свою очередь, является объектом конфигурационного управления и может входить как составная часть в другой ОКУ. Таким образом, ОКУ, в общем случае, образуют иерархию, вершиной которой является конфигурация продукта, включающая в себя все другие ОКУ.
Базовые конфигурации обычно используются как основа для перехода от одной процедуры жизненного цикла проекта к другой. В тот момент, когда процесс разработки переходит от одного шага к другому, специфические для этого шага результаты (документы, спецификации или продукты) инспектируют, чтобы убедиться в их качестве и связях (трассируемость) с предыдущими результатами. Специфические версии объектов конфигурации, принадлежащие им, идентифицируются. Когда (и если) результаты (выходы) шага прошли процедуру инспекции (только после этого), они могут быть объявлены базовой конфигурацией и становятся готовыми к использованию на следующем шаге процесса в качестве входа.
Принципиальным является то факт, что базовая конфигурация может изменяться только через процедуру Управления Изменениями. При этом требования DO-178B обязывают обеспечить прослеживаемость "происхождения" базовой конфигурации. Другими словами, должно быть обеспечено указание того, из какой предшествующей БК получена данная и с помощью какой процедуры.
В документе DO-178B применяется единственный термин "трассируемость". Он используется и для обозначения ссылок от кода программы к требованиям, и для указания на родительскую базовую конфигурацию. Возможно, что в целях более точной идентификации следует в ряде случаев различать понятия "прослеживаемость" (эволюция БК) и "трассируемость" - связи разнотипных документов (отображение преобразования входа производственной процедуры в ее выход). Обычно под трассируемостью понимается возможность идентифицировать и историю, и текущее состояние (статус) каждого объекта конфигурации в любой точке жизненного цикла проекта. Необходимой также является и возможность трассировки объектов конфигурации относительно требований заказчика как первичного входа проекта.
Большинство конфигурационных объектов в ходе жизненного цикла проекта претерпивают изменения. В процессе фиксации этих изменений возникает дерево версий, представляющее варианты объекта по степени его "завершенности". Каждая новая ветвь и лист такого дерева представляют новую версию ОКУ. Только последняя корректная версия любого объекта должна распространяться "по умолчанию" разработчикам в ответ на их запросы, устаревшие версии могут быть архивированы. При этом процедура архивирования должна обеспечивать восстанавливаемость (хранение или вычисление) любой запрошенной версии ОКУ.
Процедура управления изменениями определяет оценку и трассировку запросов на изменения, анализ потенциального влияния изменений и принятие решений по внесению изменений в объекты конфигурации. Эта процедура должна обеспечивать предотвращение "случайного" внесения изменения в базовую конфигурацию.
Реализация запросов на изменения должна включать трассировку данного изменения через процедуру фиксации проблемы, выработки и воплощения изменения, контроля его результатов и фиксации соответствующих данных жизненного цикла проекта.
Результаты процедуры внесения изменений должны инспектироваться, что, собственно, и приводит к возможности утверждения новой базовой конфигурации.
Версии (version) и Редакции (release) - эти термины иногда взаимозаменяемы. В данном документе термин "версия" используется прежде всего для ссылок на каждое новое проявление объекта конфигурационного управления, которому присвоен уникальный идентификационный номер, и подразумевает наличие цепочки ОКУ связанных отношением прослеживаемости. Другими словами, одна версия ОКУ получается из другой через процедуру управления изменениями.
Редакцией здесь называется специфическая версия объекта конфигурации, предназначенная для "внешнего" использования. Как правило, это внешнее использование - загрузка кода программы в целевой процессор или отгрузка результатов заказчику. Редакциями могут быть версии объектов, образующие комплект системы для внутреннего тестирования ("лоады", "
После того, как изменение объекта конфигурации санкционировано, обычно возникает некоторая временная задержка на время реализации изменения. Руководству и участникам проекта необходимо иметь сведения о процессе внесения изменений, а не только о факте его завершения. Процедура вычисления статуса - механизм, используемый для прослеживания эволюции каждого объекта системы и его текущего состояния.
Процедура вычисления статуса должна обеспечивать возможность реководству проекта на основании отслеживания состояний отдельных ОКУ судить о состоянии разработки в целом. Эта процедура обеспечивает проектного менеджера большим количеством данных о его продукте, включая то, как он разрабатывается и все ли требуемые свойства действительно реализованы. В конечном счете, процедура обеспечивает актуальную и объективную информацию о статусе каждого объекта конфигурации в любой момент процесса разработки, которая включает данные следующих типов данных:
Сложность процесса вычисления статусов увеличивается по мере развития разработки. Эта сложность в основном выражается в быстром росте объемов данных, которые записываются и обрабатываются.
Как уже говорилось, процедура архивирования должна обеспечивать восстанавливаемость (хранение или вычисление) любой запрошенной версии ОКУ.
Сохранность данных подразумевает не только возможность восстановления искомой версии ОКУ во все время действия процесса конфигурационного управления, но и защиту данных проекта от несанкционированного доступа. Иными словами, изменения объекта могут производиться только тем лицом, которому это изменение доверено руководством проекта.
Менеджер проекта должен быть уверен, что требуемое управление конфигурацией реализуется - другими словами, все принятые изменения реализованы, а результат представляет собой то, что специфицировано в его проектной документации. Для достижения необходимо высокого уровня доверия он должен планировать регулярные аудиты и обзоры процесса конфигурационного управления и его данных.
Требования для этих аудитов и обзоров обычно специфицируются в плане конфигурационного управления, но также они могут быть заданы в планах проекта или плане гарантии качества, как это покажется подходящим. Ответственность за нормальную реализацию аудитов конфигураций лежит на менеджере конфигураций, если эта должность предусмотрена в проекте, а если нет - на менеджере проекта или менеджере качества.
Аудитам конфигураций адресуются следующие вопросы, относящиеся к измененным объектам конфигурации.
Инструментальные средства, используемые в проекте, должны храниться в репозитории проекта. Исключением могут быть инструментальные средства внешнего происхождения (например, покупные или предоставленные заказчиком), хранение которых в репозитории может оказаться невозможным из-за их большого объема.
Хранению в репозитории проекта подлежат, как минимум, пользовательская документация, исполняемый код инструментального средства, а также иные файлы, необходимые для работы программного средства, такие, как библиотеки, базы данных, параметры настройки и т.п. Если использованию инструментального средства должна предшествовать процедура установки или генерации, то хранению подлежат все файлы, необходимые для выполнения такой процедуры.
Кроме того, инструментальные средства собственной разработки должны храниться вместе с исходным кодом и проектной документацией, а также с прочими данными, необходимыми для воспроизведения исполняемого кода данного инструментального средства.
Процедуры проекта должны точно идентифицировать конфигурацию используемых инструментальных средств. Модификация этой конфигурации допускается только через управление изменениями. Настройки СКУ должны предотвращать несанкционированное изменение инструментальных средств.
Документ DO-178B в третьем разделе седьмой главы выделяет две категории управления данными жизненного цикла программного проекта. Они соответственно названы СС1 и СС2 категории управления данными. Выбор следования той или иной категории определяется приложением А. В упрощенном виде различие между категориями можно проследить по следующим соответствиям:
идентификация объектов (СС1,СС2) формирование базовых конфигураций (СС1) обеспечение трассируемости (СС1,СС2) фиксация проблем (СС1) управление изменениями (фиксация данных) (СС1,СС2) анализ изменений (СС1) вычисление статуса конфигурации (СС1) изменения (СС1,СС2) обеспечение ограничений доступа (СС1,СС2) контроль загрузочных модулей (СС1) хранение данных (СС1,СС2)
Стандарт DO-178B обеспечивает авиационное сообщество руководящими указаниями, предназначенными для установления в конструктивной манере и с приемлемым уровнем достоверности факта того, что программное обеспечение бортовых авиационных систем и оборудование согласуются с требованиями летной годности. [7, раздел 1].
Процесс конфигурационного управления в данном стандарте рассмотрен в разделах 7 (Процесс конфигурационного управления при разработке программного обеспечения), 11.4 (План конфигурационного управления при разработке программного обеспечения) и 12.1.5 (Соображения о конфигурационном управлении при разработке программного обеспечения).
Основные цели процесса конфигурационного управления, согласно требованиям данного стандарта, включают в себя следующие положения [7, раздел 7.1].
В целом процесс конфигурационного управления, охватываемый стандартом DO-178B, направлен на поддержание целостности данных, создаваемых в ходе всех стадий жизненного цикла продукции. Основная специфика процесса КУ, регламентируемого данным стандартом, состоит в учете аспектов сертификации на летную годность, которую должно проходить все программное обеспечение, используемое в бортовых авиационных системах. Данные процесса КУ используются в качестве основных данных, предоставляемых сертифицирующему органу.
Сертифицирующим органам предоставляются индексы конфигураций - списки уникальным образом идентифицированных элементов (исходных текстов, файлов данных, объектного и исполняемого кода), входящих в программное обеспечение. Для подтверждения соответствия качества программного обеспечения заданному уровню критичности бортового ПО представляются результаты его тестирования, проведенные в соответствии с требованиями к данному уровню. Процесс конфигурационного управления должен обеспечивать трассируемость всех требований, исходных текстов, тестов и их результатов.
Для проведения сертификации все элементы конфигурации должны иметь соответствующие пометки о готовности к сертификации, а все проблемы, возникающие в ходе разработки, должны быть тем или иным образом закрыты. Данный аспект сертификации обеспечивается предоставлением информации о ведении проблем и включением сообщений о проблемах и связанных с ними запросов на изменение в индекс конфигурации, подлежащей сертификации.
Все рассмотренные выше требования являются общими требованиям к процессу КУ, но процесс разработки и выполнения бортового ПО имеет одну особенность - средой разработки служат те или иные компьютеры общего назначения, а средой времени выполнения служит соответствующее системное ПО бортового вычислителя. Стандартом DO-178B выдвигаются требования, учитывающие эту особенность: существуют требования по обеспечению поддержки процесса загрузки объектного кода приложения на бортовой вычислитель, который гарантируюет загрузку исполняемого кода с применением соответствующих мер безопасности, обеспечивающих его неизменность и целостность [7, Раздел 4.2.8].
Таким образом, система конфигурационного управления, удовлетворяющая требованиям стандарта DO-178B, должна обеспечивать идентификацию и трассируемость объектов конфигурационного управления (ОКУ), поддержку создания базовых версий (индексов конфигураций), управление сообщениями о проблемах и вызванных ими изменениях, учет состояния конфигурации и ОКУ, а также обеспечивать процессы резервного копирования и восстановления данных и управление процессом загрузки объектного кода на бортовой вычислитель.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.