Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


Совместные технические и административные просмотры



5.11.1 Совместные технические просмотры

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

- просмотр и оценка состояния разработки ПО;

- анализ и оценка предложенных технических решений;

- рассмотрение критических для выполнения контракта ситуаций, связанных с техническими, стоимостными и временными аспектами;

- достижение согласованных стратегий предотвращения критических ситуаций в рамках предоставленных полномочий;

- идентификация проблем, которые будут рассмотрены на совместных административных просмотрах;

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

5.11.2 Совместные административные просмотры

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

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

- разрешение проблем, которые не могли быть решены во время совместных технических просмотров;

- достижение согласованных стратегий предотвращения критических ситуаций, которые не могли быть выработаны во время совместных технических просмотров;

- идентификация и решение проблем административного уровня и критических ситуаций, не рассмотренных во время совместных технических просмотров;

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

Другие действия

5.12.1 Контроль критических ситуаций

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

5.12.2 Показатели управления разработкой ПО

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

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

5.12.3 Защита и секретность

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

5.12.4 Управление субподрядчиком

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

5.12.5 Связь с агентством независимой верификации ПО

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

5.12.6 Координация действий с соисполнителями

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

5.12.7 Изменения в выполнении процессов проекта

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

6 Процесс планирования ПО

6.1 Цели процесса планирования ПО

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

Ц ели процесса планирования ПО:

а) определить конкретные виды работ процессов разработки и интегральных процессов жизненного цикла, которые позволят реализовать системные требования и создать ПО требуемого уровня ( 6.2 );

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

в) выбрать среду поддержки жизненного цикла, включающую в себя методы и инструментальные средства, которые нужно использовать для выполнения работ в каждом процессе жизненного цикла ( 6.4 );

г) в случае необходимости рассмотреть дополнительные аспекты разработки, обсуждаемые в разделе 13;

д) определить стандарты разработки, позволяющие обеспечить требования по безопасности системы в части разрабатываемого ПО ( 6.5 );

е) разработать документы процесса планирования ПО в соответствии с 6.3 и разделом 12;

ж) координировать разработку и изменение планов ПО( 6.3 ).

6.2 Состав работ, выполняемых в процессе планирования ПО

В процессе планирования ПО должны быть выполнены следующие работы:

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

- определение и выбор стандартов разработки ПО, которые будут использованы для данного проекта;

- выбор методов и инструментальных средств, которые позволят в процессах разработки предотвратить внесение ошибок в ПО;

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

- определение процедуры пересмотра и уточнение планов по мере развития проекта;

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

ошибки и обеспечивающих безопасность системы в случае использования многоверсионного неидентичного ПО;

- если предполагается использование отключенного кода ( 7.4.3 ), то в процессе планирования должно быть описано, как отключенный код будет определен, верифицирован и обработан для обеспечения требований безопасности системы;

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

- процесс планирования считают завершенным, если были выполнены контроль изменений и просмотры для всех планов ПО и стандартов разработки ПО ( 6.7 ).

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

6.3 Типы планов ПО

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

- План сертификации в части ПО ( 12.1 ) служит основным средством для согласования предложенных методов разработки с сертифицирующей организацией и определяет средства для выполнения требований данного документа;

- План разработки ПО ( 12.2 ) определяет используемые модели жизненного цикла ПО и среду разработки ПО;

- План верификации ПО ( 12.3 ) определяет средства, с помощью которых будут удовлетворены цели процесса верификации ПО;

- План квалификационного тестирования ПО ( 12.4 ) определяет порядок выполнения квалификационного тестирования ПО;

- План управления конфигурацией ПО ( 12.5 ) определяет средства, с помощью которых будут удовлетворены цели процесса управления конфигурацией ПО;

- План обеспечения качества ПО ( 12.6 ) определяет средства, с помощью которых будут удовлетворены цели процесса обеспечения качества ПО;

- План установки ПО ( 12.7 ) определяет действия по установке разработанного ПО на рабочих местах пользователей, включая подготовку и обучение персонала и адаптацию существующих систем;

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

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

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

- действий интегральных процессов, которые могут потребоваться для обработки этих входных данных;

- необходимых инструментальных средств, методов, стандартов и процедур.

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

Ц ель планирования среды жизненного цикла ПО состоит в определении методов, инструментальных средств, процедур, языков программирования и аппаратных средств, которые будут использованы для выполнения процессов жизненного цикла ПО и подготовки документов жизненного цикла ПО (раздел 12 ). Основными элементами среды жизненного цикла ПО являются среда разработки ПО и среда верификации ПО.

6.4.1 Среда разработки ПО

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

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

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

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

- если сертификационное доверие к использованию определенной комбинации инструментальных средств достаточно высокое, то применение этих инструментальных средств должно быть определено в соответствующем плане;

- если дополнительные возможности (опции) инструментальных средств разработки ПО выбраны для использования в проекте, то эффект их применения должен быть рассмотрен и определен в соответствующем плане.

6.4.2 Язык программирования и компилятор

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

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

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

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

6.4.3 Среда верификации ПО

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

- эмулятор или интерпретатор в некоторых случаях требуется аттестовать как описано в 13.2;

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

Стандарты разработки ПО

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

- удовлетворять требованиям раздела 11;

- обеспечивать единообразие разработки компонентов ПО данного программного продукта или необходимого набора средств;

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

6.6 Ответственность за выполнение планирования

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

- полное планирование для контракта;

- детализированное планирование для текущего построения;

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

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

П римечания

1 Эта формулировка здесь и далее в настоящем стандарте предназначена для того, чтобы:

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

- использовать документ как контрольный список построений, которые покрываются действиями разработки или планирования;

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

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

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

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

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

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

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

6.7 Просмотр результатов процесса планирования ПО

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

Процессы разработки ПО

П роцессы разработки ПО должны быть выполнены в соответствии с процессом планирования ПО (раздел 6 ) и Планом разработки ПО ( 12.2 ). Таблица А.2 содержит резюме целей и результатов процессов разработки ПО в зависимости от уровня ПО. Процессами разработки ПО являются следующие процессы:

- определение требований к ПО;

- проектирование ПО;

- кодирование ПО;

- интеграция.

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

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

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

7.1.1 Цели процесса определения требований к ПО Цели данного процесса состоят в том, чтобы:

а) разработать требования верхнего уровня;

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

7.1.2 Состав работ, выполняемых в процессе определения требований к ПО

В ходными данными для процесса определения требований к ПО являются системные требования, описания аппаратного интерфейса и архитектуры системы (если они не включены в системные требования), определяемые процессами жизненного цикла системы, План разработки ПО и стандарты на разработку требований к ПО, определяемые процессом планирования. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, входные данные используют для разработки требований верхнего уровня к ПО. Требования верхнего уровня включают в себя функциональные требования, требования к эффективности, требования к интерфейсу и требования, связанные с безопасностью. Результатами данного процесса являются документы «Спецификация требований к ПО» ( 12.13 ) и «Спецификация требований к интерфейсу» ( 12.14 ). Процесс определения требований к ПО считают завершенным, когда достигнуты его цели и цели связанных с ним интегральных процессов. Процесс определения требований к ПО должен обеспечить следующее:

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

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

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

- определение всех требований верхнего уровня, соответствующих системным требованиям, которые связаны с предотвращением риска;

- верифицируемость, непротиворечивость и соответствие требований верхнего уровня стандартам на разработку требований к ПО;

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

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

- трассируемость каждого требования верхнего уровня, кроме производных требований к одному или нескольким системным требованиям;

- оценку производных требований верхнего уровня с точки зрения безопасности системы.

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

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

7.2.1 Цели процесса проектирования ПО

Ц ели данного процесса состоят в том, чтобы:

а) разработать архитектуру ПО и требования нижнего уровня на основе требований верхнего уровня;

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

7.2.2 Состав работ, выполняемых в процессе проектирования ПО

В ходными данными процесса проектирования ПО являются требования к ПО, План разработки ПО и стандарты на процесс проектирования ПО. После того как удовлетворены указанные в Плане разработки ПО критерии перехода к данному процессу разработки, эти входные данные используются в процессе проектирования для разработки архитектуры ПО и требований нижнего уровня. Требования нижнего уровня могут включать в себя одно или несколько требований более низких уровней. Основным выходным результатом процесса является документ «Описание проекта ПО» ( 12.16 ), который содержит описание архитектуры ПО и требования нижнего уровня. Если это предусмотрено условиями контракта, часть проекта, имеющая отношение к интерфейсам, может быть включена в документ «Описание проекта интерфейса» ( 12.17 ), а часть проекта, имеющая отношение к базам данных, может быть включена в документ «Описание проекта базы данных» ( 12.18 ). Процесс проектирования ПО считают завершенным, когда удовлетворены его цели и цели связанных с ним интегральных процессов. Процесс проектирования ПО должен обеспечивать следующее:

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

- производные требования должны быть определены и проанализированы для гарантии того, что они не противоречат требованиям верхнего уровня;

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

- необходимо контролировать поток управления и поток данных, когда это связано с требованиями безопасности;

- реакция на отказные ситуации должна быть согласована с требованиями безопасности;

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

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

7.2.3 Проектирование модифицируемого пользователем ПО

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

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

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

7.2.4 Проектные решения уровня ЭКПО

Р азработчик должен определить и зарегистрировать проектные решения уровня ЭКПО. Результаты должны быть включены в раздел проектных решений уровня ЭКПО документов проектирования ПО ( 12.16, 12.17, 12.18 ).

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

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

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

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

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

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

7.3.1 Цели процесса кодирования ПО

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

7.3.2 Состав работ, выполняемых в процессе кодирования ПО

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

- исходный код должен реализовывать требования нижнего уровня и соответствовать архитектуре ПО;

- исходный код должен соответствовать стандартам кодирования ПО;

- исходный код должен быть трассируемым к описанию проекта;

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

Процесс интеграции

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

7.4.1 Цели процесса интеграции

Ц ели процесса интеграции состоят в получении интегрированной системы.

7.4.2 Состав работ, выполняемых в процессе интеграции

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

В ыходной результат процесса интеграции - исполняемый объектный код, описанный в 12.20, и информация о редактировании связей и загрузке. Процесс интеграции является завершенным, когда удовлетворены его цели и цели интегральных процессов, связанных с ним. Требования для этого процесса:

- исполняемый объектный код должен быть генерирован на основе исходного кода и информации о редактировании связей и загрузке;

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

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

7.4.3 Дополнительные задачи интеграции

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

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

- должны быть использованы методы работы с отключенным кодом в соответствии с планами ПО;


Поделиться:



Последнее изменение этой страницы: 2017-05-05; Просмотров: 415; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.087 с.)
Главная | Случайная страница | Обратная связь