25 Модели жц быстрой разработки

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

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

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

26 Требования доверия безопасности; оценка профилей защиты и заданий по безопасности: основные сведения, стандарты

Требования изложены в третьей части ГОСТ Р ИСО/МЭК 15408.

Требования доверия безопасности охватывают весь ЖЦ про­дуктов и систем информационных технологий (ИТ) и предпола­гают выполнение следующих действий: 1)оценку заданий по безопасности (ЗБ) и профилей защиты (ПЗ), являющихся источниками требований безопасности; 2) анализ различных представлений проекта и соответствия между ними, а также соответствия каждого из них требованиям безопасности; 3 )проверку процессов и процедур безопасности, их применения; 4)анализ документации; 5) верификацию представленных доказательств; 6) анализ тестов и их результатов; 6) анализ уязвимостей; 7) проведение независимого тестирования. Каждое требование (элемент) доверия принадлежит одному из трех типов: 1)элементы действий разработчика (помечаются буквой «D» после номера элемента). 2) элементы представления и содержания свидетельств (поме­чаются буквой «С»); 3 )элементы действий оценщика (помечаются буквой «Е»). Одна из целей ГОСТ Р ИСО/МЭК 15408 состоит в минимиза­ции усилий разработчиков и оценщиков, направленных на обеспечение заданного уровня доверия.

Оценка профилей защиты и заданий по безопасности. Цель требований, вошедших в классы АРЕ (оценка профиля защиты) и ASE (оценка задания по безопасности), - проверить и полноту, непротиворечивость и реализуемость ПЗ или ЗБ. Класс АРЕ состоит из шести однокомпонентных семейств, соответствующих предписанной структуре ПЗ. Семейство APE_DES (описание объекта оценки) специфициру­ет, что описание объекта оценки должно включать в себя, как ми­нимум, тип продукта и его общую характеристику. Требования семейства APE_ENV (среда безопасности) указы­вают на необходимость идентификации и объяснения всех допу­щений о предполагаемом применении объекта оценки и среде ис­пользования, всех угроз, от которых нужна защита, и всех поли­тик безопасности, обязательных для исполнения. Согласно требованиям семейства APE_OBJ (цели безопасно­сти) разработчик должен не только сформулировать цели безо­пасности для объекта оценки и его среды, но и представить их логическое обоснование. Основное содержание профиля защиты составляют требования безопасности. К этой части применимы семейства APE_REQ (требования безопасности ИТ) и APE_SRE (требования безопас­ности ИТ, сформулированные в явном виде).Класс ASE устроен аналогично классу АРЕ, некоторые отличия вызваны большей конкретностью ЗБ в сравнении с ПЗ и наличием дополнительных разделов. Модифицированы требования шести рассмотренных выше семейств, и добавлены два новых. Семейство ASE_TSS (краткая спецификация объекта оцен­ки) определяет в самом общем виде функции безопасности и меры доверия, предназначенные, соответственно, для выполнения функциональных требований и требований доверия. Если ЗБ является конкретизацией некоторых ПЗ, к нему применяются требования семейства ASE_PPC (утверждения о соответствии профилям защиты).