Чтение онлайн

3.65 статический анализатор: Программное инструментальное средство, которое позволяет получать определенные характеристики программы без ее выполнения.

3.66 тестирование: Процесс выполнения системы или компонента системы в целях проверки того, что она/он удовлетворяет заданным требованиям, и обнаружения ошибок.

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

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

3.69 требование: Характеристика того, чем система или ЭКПО должны обладать, чтобы быть приемлемыми для заказчика.

3.70 требования верхнего уровня: Требования к ПО, разработанные на основании анализа системных требований и требований, связанных с безопасностью системы.

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

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

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

3.74 условие: Логическое выражение, не содержащее логических операций.

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

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

3.77 элемент конфигурации аппаратуры (ЭКА): Совокупность компонентов аппаратных средств, которая обеспечивает конечную функцию использования и предназначается заказчиком для независимого от других элементов управления конфигурацией.

3.78 элемент конфигурации ПО (ЭКПО): Совокупность компонентов ПО, которая обеспечивает конечную функцию использования и предназначается заказчиком для независимого от других элементов управления конфигурацией.

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

4 Общие требования

4.1 Жизненный цикл ПО

4.1.1 Процессы жизненного цикла ПО

В настоящем стандарте рассмотрены следующие процессы жизненного цикла ПО:

Процесс планирования, который определяет и координирует действия процессов разработки и интегральных процессов для данного проекта (раздел 6).

Процессы разработки, в ходе выполнения которых создается программное средство. Этими процессами являются:

— процесс определения требований к ПО;

— процесс проектирования ПО;

— процесс кодирования ПО;

— процесс интеграции.

Процессы разработки описаны в разделе 7.

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

— процесс верификации ПО;

— процесс управления конфигурацией ПО;

— процесс обеспечения качества ПО;

— процесс сертификационного сопровождения.

Интегральные процессы выполняются одновременно с процессами разработки ПО (разделы 8-11).

4.1.2 Установление модели жизненного цикла ПО

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

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

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

4.1.3 Критерии перехода между процессами

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

4.2 Общие требования для разработки ПО

4.2.1 Методы разработки ПО

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

4.2.2 Стандарты ПО

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