Этап планирования и анализа требований

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

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

На этом этапе производитьсяопределение действий на этапах разработки и интегрированном этапе, которые будут посвящены определению системных требований и уровня ПОопределение ЖЦ ПО, включая взаимодействие между этапами, механизм взаимного влияния этапов, критерии оценки ПО при переходе от одного этапа к другомуопределение среды ЖЦ, т.е. методы и инструментальные средства, используемые на каждом этапеформирование дополнительных замечаний к ПОрассмотрение стандартов разработки ПО, соотношение их с системными целями безопасности, относящиеся к разрабатываемому ПОразработка плана создания ПОдоработка и проверка плана создания ПО.Эффективность планирования - определяющий фактор при разработке ПО. Основные руководящие принципы этого этапа следующие.1. План разработки ПО должен быть разработан в такой момент ЖЦ, чтобы обеспечить своевременное управление конкретными действиями на этапе разработки и интегрированном этапе.2. Стандарты разработки ПО, используемые в проекте, должны быть строго определенными и четкими.3. Выбранные методы и инструментальные средства должны быть такие, чтобы обеспечили предотвращение ошибок на этапе разработки или свели их к минимуму.4. Этап планирования разработки ПО должен обеспечить координацию между остальными этапами с целью согласования их стратегий в плане разработки ПО.5. Этап планирования разработки ПО должен включать в себя средства проверки плана на этапе реализации проекта.6. На завершающей стадии этапа планирования, план и стандарты разработки ПО должны быть проанализированы на предмет полноты и непротиворечивости. Другие этапы ЖЦ могут быть начаты до окончания этапа планирования при условии, что имеются планы и процедуры для действий на этих этапах.

Этап разработки Цель - создание архитектуры ПО и требований НУ- выработка производных от них требований для этапа оценки безопасности.

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

Процесс разработки содержит действия и задачи разработчика.

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

Перечень действий Этот процесс состоит из следующих видов деятельности.1. Инструментарий процесс.

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

Действия и задачи этого процесса должны быть выбраны и отображены в модели жизненного цикла.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тестовые требования должны включать испытания программного обеспечения на пределе требований.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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