Программное обеспечение встроенных систем. Общие требования к разработке и документированию - [4]

Шрифт
Интервал

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.2.3 Программные средства многократного использования

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

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

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

4.2.4 Отработка критических требований

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

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


Еще от автора ГОСТ
Пакеты программ. Требования к качеству и тестирование

Настоящий стандарт содержит полный аутентичный текст международного стандарта ИСО/МЭК 12119-94 «Информационная технология. Пакеты программ. Требования к качеству и тестирование»ГОСУДАРСТВЕННЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИГОСТ Р ИСО/МЭК 12119-2000Information technology. Software packages. Quality requirements and testing.


Система технической документации на АСУ. Общие требования к выполнению текстовых документов

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


Процессы жизненного цикла программных средств

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


Общие требования к компетентности испытательных и калибровочных лабораторий

Настоящий стандарт представляет собой полный аутентичный текст международного стандарта ИСО/МЭК 17025-99 «Общие требования к компетентности испытательных и калибровочных лабораторий»Настоящий стандарт является результатом большого опыта внедрения Руководства ИСО/МЭК 25 и ЕН 45001, взамен которых он теперь действует. В нем содержатся все требования, которым испытательные и калибровочные лаборатории должны соответствовать, если они намерены показать, что у них действует система качества, что они технически компетентны и способны получать технически обоснованные результаты.Органам по аккредитации, признающим компетентность испытательных и калибровочных лабораторий, следует основывать свою деятельность на настоящем стандарте.


Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания

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


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

United system for program documentation. Technical specification for development. Requirements to contents and form of presentation Настоящий стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.Стандарт полностью соответствует СТ СЭВ 1627-79.Переиздание (Ноябрь 1987 г.) с Изменением № 1, утвержденным в июле 1981 г (ИУС 7-81)


Рекомендуем почитать
Профессия "Технический писатель", или "Рыцари клавиатуры"

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


История инженерного дела. Важнейшие технические достижения с древних времен до ХХ столетия

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


Юный техник, 2015 № 04

Популярный детский и юношеский журнал.


Юный техник, 2015 № 03

Популярный детский и юношеский журнал.


Юный техник, 2014 № 02

Популярный детский и юношеский журнал.


Технический регламент о требованиях пожарной безопасности. Федеральный закон № 123-ФЗ от 22 июля 2008 г.

Настоящий Федеральный закон принимается в целях защиты жизни, здоровья, имущества граждан и юридических лиц, государственного и муниципального имущества от пожаров, определяет основные положения технического регулирования в области пожарной безопасности и устанавливает общие требования пожарной безопасности к объектам защиты (продукции), в том числе к зданиям, сооружениям и строениям, промышленным объектам, пожарно-технической продукции и продукции общего назначения. Федеральные законы о технических регламентах, содержащие требования пожарной безопасности к конкретной продукции, не действуют в части, устанавливающей более низкие, чем установленные настоящим Федеральным законом, требования пожарной безопасности.Положения настоящего Федерального закона об обеспечении пожарной безопасности объектов защиты обязательны для исполнения: при проектировании, строительстве, капитальном ремонте, реконструкции, техническом перевооружении, изменении функционального назначения, техническом обслуживании, эксплуатации и утилизации объектов защиты; разработке, принятии, применении и исполнении федеральных законов о технических регламентах, содержащих требования пожарной безопасности, а также нормативных документов по пожарной безопасности; разработке технической документации на объекты защиты.Со дня вступления в силу настоящего Федерального закона до дня вступления в силу соответствующих технических регламентов требования к объектам защиты (продукции), процессам производства, эксплуатации, хранения, транспортирования, реализации и утилизации (вывода из эксплуатации), установленные нормативными правовыми актами Российской Федерации и нормативными документами федеральных органов исполнительной власти, подлежат обязательному исполнению в части, не противоречащей требованиям настоящего Федерального закона.