ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 04.02.2024
Просмотров: 297
Скачиваний: 2
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Стандарты не определяют метода показа трассировки, нужно только чтобы трассировка была продемонстрирована каким-либо образом. Например, с помощью различных ссылок одних документов на другие. Поэтому очень важно, чтобы все документы имели уникальную идентификацию, включающую, помимо прочего, и версию документа.
Разработка надежного ПО также не может обойтись без трассировки.
Определение критериев перехода между процессами
Процессы, входящие в жизненный цикл разработки, могут использовать результаты работы одних процессов и передавать результаты своей работы другим процессам. Если не определить правила, когда каждый из процессов может считаться завершенным, и результаты его работы могут быть использованы другими процессами, то можно нарушить описанный выше принцип трассировки. Например, мы не можем перейти к процессу созданию низкоуровневых требований, если мы еще не создали соответствующие им высокоуровневые требования. Для того чтобы понять, когда следует завершать один процесс и переходить к другому, служат критерии перехода между процессами.
Критерии перехода устанавливают, что должно быть сделано соответствующим процессом и какие минимально-достаточные условия должны быть выполнены, чтобы считать процесс завершенным, и чтобы можно было переходить к другому процессу. Например, если все изменения кода выполнены, то можно переходить к тестированию. Процесс обеспечения качества надежного ПО должен использовать эти критерии для оценки успешного завершения каждого из процессов, входящих в жизненный цикл разработки.
Процесс верификации
Наверно, есть разработчики, которые, создавая программное обеспечение, не допускают ни одной ошибки, и их программы работают правильно во всех возможных ситуациях. Если вы не относитесь к такому типу разработчиков, без процесса верификации вам не обойтись.
Процесс верификации как раз и занимается выявлением и информированием об ошибках, которые могут появиться на всем протяжении жизненного цикла ПО. Для надежного ПО этот процесс должен проверять не только программный код, но и результаты работы других процессов жизненного цикла, в том числе он должен отслеживать ошибки в требованиях, дизайне, тестирующих примерах, процедурах и результатах тестирования.
При создании надежного программного обеспечения этот процесс, кроме тестирования, должен использовать такие методы верификации, как ревизия и анализ. Под ревизией понимается инспекция выходной информации исследуемого процесса в соответствии с контрольным перечнем, который должен быть составлен заранее. Анализ экзаменует функциональность, производительность, источники требований, полноту тестирования, безопасность компонента ПО, а также его взаимоотношения с другими компонентами ПО. Анализ может выявить противоречия и несоответствия в спецификации, стандартах, требованиях, дизайне и коде.
Как проходит и какие цели выполняет процесс верификации, должно быть определено в соответствующем плане. Стандарты разработки критического ПО требуют, чтобы план верификации включал описания:
-
Как происходит верификация. -
Кто персонально занимается верификацией. -
Какие методы должны быть использованы для ревизии, анализа и тестирования -
Какие процедуры будут задействованы для тестирования, какие тестовые данные будут созданы, и какие тестовые процедуры используются. -
Какое окружение используется для верификации: инструменты, аппаратная часть, процедуры и все что нужно для верификации. -
Критерии перехода: когда начинается процесс верификации; -
Как делается повторная верификация, что делать, если процесс уже завершен, и была найдена ошибка.
Процесс управления конфигурацией
Бесконтрольный доступ и изменение данных жизненного цикла ПО может привести к полной его остановке или потере всех созданных артефактов. Поэтому в любой жизненный цикл разработки надежного ПО обязательно должен входить процесс управления конфигурацией, контролирующий все то, что создается на всем протяжении жизненного цикла разработки ПО.
Процесс управления конфигурации занимается идентификацией всех конфигурационных элементов, контролем их изменений и доступа, созданием базовых линий для отслеживания последующих модификаций; он осуществляет действия по оповещению, трассировке и коррекции проблем. Он также отвечает за архивацию и восстановление всех конфигурационных элементов, включая программное обеспечение.
Процесс управления конфигурации начинается в тот момент, когда принято решение, что накопленные материалы, такие как чертежи, схемы, требования, любые другие документы, достаточны для начала процесса планирования. Этот процесс действует на всем протяжении жизненного цикла ПО в соответствии с разработанным планом. Стандарты DO178B/DO178С требуют, чтобы план управления конфигурации описывал:
-
Какие инструменты используются для управления конфигурацией. -
Все типы контролируемых данных. -
Как данные будут храниться и выдаваться, например, выдача данных может осуществляться по интернету в зашифрованном виде. -
Как хранится и контролируется код, в том числе описание того, на каких физических носителях он хранится, как осуществляются процедуры резервного копирования и восстановления кода.
Процесс обеспечения качества
При разработке программного обеспечения всегда есть вероятность, что что-то идет не так, что какой-то из процессов, входящих в жизненный цикл, работает неправильно, и что есть расхождения с установленным планом. Процесс обеспечения качества занимается выявлением таких проблем. Надежное программное обеспечение нельзя создать, если в жизненный цикл его разработки не включен этот процесс.
Процесс обеспечения качества должен отслеживать, что все процессы идут в соответствии с намеченными планами, что они выполняют все установленные цели, что требования стандартов соблюдаются, переходы между процессами осуществляются в соответствии с установленными критериями, все артефакты соответствуют установленной спецификации. При возникновении проблем во время жизненного цикла разработки процесс обеспечения качества должен гарантировать, что они будут рассмотрены и по ним будут приняты соответствующие решения, и в конечном итоге они будут разрешены.
Процесс верификации оценивает деятельность всех процессов, входящих в жизненный цикл разработки, с помощь различных аудитов и ревизий. Результатами работы процесса являются его записи. Они содержат информацию об проведенных аудитах, записи о санкционированных отклонениях и записи, подтверждающие проведение ревизий. Процесс верификации проводится в соответствии с разработанным планом, который для критического ПО должен включать следующие описания:
-
Окружение обеспечения качества, а именно: инструменты, процедуры, стандарты, в чем заключается обеспечение качества, как организован процесс обеспечения качества, и кто за что в нем отвечает и перед кем. -
Действия по обеспечению качества: аудиты, рапорты, инспекции, мониторинг, контроль процессов жизненного цикла, отслеживание запросов на изменение и проблемных рапортов, и их мониторинг. -
Критерии перехода для процесса обеспечения качества, контрольные списки того, что должно быть проверено. -
Частота и последовательность действий процесса обеспечения качества. -
Список всех данных, создаваемых за время работы процесса, например протоколы митингов, записи проверок, записи установленных отклонений от процессов.
Ведение истории разработки программного обеспечения
Любые действия, проводимые на всем протяжении жизненного цикла разработки ПО, должны быть отражены в соответствующих документах. Необходимо также хранить информацию, кем они были совершены, и результаты этих действий. Все артефакты, произведенные за время ЖЦ разработки, составляют ее историю. История продукта должна показать, как поэтапно было создано программное обеспечение, что это за программное обеспечение, зачем оно нужно, какие системные и функциональные требования были в нее заложены, как осуществлялся процесс ее создания, контроля и проверки, почему данная система является надежной, как это было доказано.
Для критического программного обеспечения история создания ПО имеет очень важное значение, поскольку она может быть использована для расследования инцидентов, произошедших на системах, где это ПО было использовано. Может возникнуть ситуация, когда в суде нам придется рассказывать поэтапную работу над созданием нашего ПО и доказывать, что все что мы сделали, является правильным. Поэтому если задать вопрос авиационному сертифицирующему органу, какую информацию, какие данные и какие документы нужно хранить для сертификации программного обеспечения, они отвечают: все, что касается проекта и любых действий, проводимых в его рамках, включая даже и неформальную информацию, такую как мнения, обсуждения, записи переговоров и так далее.
Для надежного ПО требование по хранению всей созданной за время разработки информации является чрезмерными. Но все, что непосредственно касается проекта, должно быть сохранено.
Независимое проведение процедур проверки
Для сертификации критического программного обеспечения стандарты DO178B/DO178С устанавливают 5 различных уровней безопасности ПО, от катастрофического, когда ошибочная работа программного обеспечения может привести к гибели людей, до уровня, когда ПО никак не может повлиять на безопасность полета. Сертификации ПО для разных уровней существенно отличается, и одним из основных отличий является то, как проходят процессы верификация и валидация. Чем выше уровень критичности ПО, тем выше требования к тому, чтобы процессы верификации и валидации на различных этапах разработки проводили люди, не имеющие прямого отношения к процессу разработки проверяемого ПО. Для сертификации на самые критические уровни безопасности требуется, чтобы всю верификацию и валидацию проводили только независимые от разработчика данного ПО люди.
Для создания надежного программного обеспечения принцип независимости также имеет существенное значение. Необходимо, чтобы процедуру верификации и валидации результатов работы различных процессов (в том числе и тестирование) проводили люди, непосредственно не участвующие в их создании. Это не обязательно должны быть люди со стороны, из другой организации или компании. Это могут быть люди, входящие в команду разработки данного программного обеспечения, но не принимающие участие в создании того, что они проверяют.
Тесты должны базироваться на требованиях
Процесс верификации включает в себя процесс тестирования. Этот процесс является наиболее интенсивной частью процесса разработки. Тестирование, в свою очередь, делится на два процесса: определение теста, когда решается, что собой будет представлять тест, и выполнение теста. Обычно тестирование можно разделить на две части: неформальное тестирование, когда тестирование проводится самими разработчиками во время написания кода, и формальный процесс тестирования. Как правило, трудностей при создании неформальных тестов не возникает, поскольку сам программист знает, что и как нужно тестировать, но могут возникнуть сложности в определении тестовых процедур для формального тестирования.