Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 | Следующая страница реферата

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

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

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

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

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

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

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

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

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

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

разместить результаты (выходы) в процессе конфигурации и выполнить контроль изменений в соответствии с этим;

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

другие сопроводительные процессы , как определено в контракте.

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

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

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

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

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

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

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

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

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

различимость системных требований;

согласованность с системными требованиями;

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

Рекомендуем скачать другие рефераты по теме: пример курсовой работы, решебники скачать бесплатно.



Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9  10  11 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки