Гост 54582-2011

У нас вы можете скачать гост 54582-2011 в fb2, txt, PDF, EPUB, doc, rtf, jar, djvu, lrf!

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

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

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

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

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

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

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

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

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

Любая система, соответствующая определенному уровню безопасности, может маркироваться как совмесгимая. Методология ХЮреп отличается от трех других методологий АА. Строгое тестирование соответствия требованиям безопасности определяет метод тестирования безопасных систем по общедоступной спецификации — обычно по стандарту. Комплексные тесты систематизированы с целью подчеркнуть реализацию тестов. Исходной точкой проведения тестов является абстрактное задание по безопасности АЗБ , включенное в базовый стандарт по безопасности.

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

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

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

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

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

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

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

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

На сегодняшний день была добавлена дисциплина поиска поставщика. Carnegie — Mellon University. Базовые практики подразделяют на: Классификация основана на оценке конкретного примера процесса. Все типы оценки поддерживаются. Software and system engineering. В модели зрелости возможностей организации вотношении программных процессовописаны принципы и практики, лежащие в основе ихэрелости и предназначенные для содействия занимающимся ПО организациям в повышении зрелости ее программных процессов.

Уровень 1 — начальный. Программный процесс характеризуется как произвольный, иногда даже как хаотический. Определено очень мало процессов, и успешность их выполнения зависит от индивидуальных усилий и решительных действий. Уровень 2 — повторяемый.

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

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

На сегодняшний день это мнение поддерживается эмпирическими доказательствами. За исключением уровня 1. КЧП на уровне 2 связаны с проблемами проекта по разработке ПО. КЧП на уровне 2 являются: В КЧП на уровне 3 рассматриваются проблемы какпроекта. КЧП на уровне 3 являются: КЧП на уровне 4 сосредоточены на установлении количественного согласования программного процесса и создаваемой программной продукции. КЧП на уровне 4 являются количественный менеджмент процесса и менеджмент качества ПО.

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

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

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

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

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

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

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

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

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

Могут появляться новые методы обеспечения доверия, а также модифицироваться и совершенствоваться уже существующие. Из настоящего стандарта разработчики, оценщики, менеджеры по качеству и покупатели могут выбирать методы обеспечения доверия к программному обеспечению и системам безопасности ИКТ, определяя требования доверия, оценивая продукты, измеряя аспекты безопасности и т.

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

В настоящем стандарте также проведен анализ методов обеспечения доверия, не уникальных для безопасности ИКТ; однако руководство, приведенное в настоящем стандарте, ограничено требованиями безопасности ИКТ.

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

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

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

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

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

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

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

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

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

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

Таким образом, система класса В2 соответствует каждому функциональному требованию класса C2 и имеет более высокий уровень доверия. Уровнем доверия является совокупность классов см. FAQ часто задаваемые вопросы концепций критериев, вопрос 1].

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

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

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

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

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

FTLS является высокоуровневой спецификацией системы, записанной на формальном математическом языке для формирования гипотез из теорем демонстрирующих соответствие спецификации системы ее формальным требованиям и их формального доказательства. Для соответствия расширенному проекту и анализу проекта ТСВ, необходимых для систем класса А1, требуется более строгое конфигурационное управление и формирование процедур безопасного распределения системы по местам эксплуатации.

Администратору безопасности системы должна быть оказана поддержка. Они были разработаны четырьмя европейскими странами: Францией, Германией, Нидерландами и Великобританией. Однако разделение между функциональными требованиями и требованиями доверия в ITSEC допускает большую гибкость.

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

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

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

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

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

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

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

На каждом уровне имеется набор функциональных требований и требований доверия KISEC, которым должны соответствовать оцениваемые межсетевые экраны и системы обнаружения вторжения.

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

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

В зависимости от функциональных требований и требований доверия оценочный уровень делится на семь уровней. Низший уровень представлен К1, высший - К7. Ниже приведены характеристики каждого оценочного уровня: Также должны быть в наличии задание по безопасности и функциональные спецификации; - уровень К2 должен соответствовать требованиям уровня К1 и быть способным создавать и сохранять записи аудита деятельности, связанной с безопасностью.

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

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

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

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

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

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

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

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

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

Результаты оценивания по ТРЕР публикуются ежеквартально в перечне оцененных продуктов EPL в разделе 4 Каталога услуг и продуктов по обеспечению безопасности информационных систем. Примечание - ТРЕР была заменена программой оценки доверенных технологий. Схема постоянно обновляется и улучшается для отражения самого последнего опыта и развития лучших практик. В отличие, например, от ИСО "пустая" схема RUP заполнена руководством, процессами, методами, средствами, шаблонами, инструментарием и примерами, из которых можно создать конкретную схему процесса, управлять ею и улучшать ее.

Подобно производимым им программным продуктам сам RUP спроектирован и документирован с помощью универсального языка моделирования UML.

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

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

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

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

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

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

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

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

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

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

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

V-модель жизненного цикла структурирована по трем частям: В данной части содержатся обязательные положения относительно предполагаемых шагов действий и их результатов продуктов ; - часть 2: Данная часть существует как для вооруженных сил Германии, так и для федеральной администрации. В ней содержатся инструкции по применению модели процессов жизненного цикла в той или иной области; - часть 3: В данной части содержится набор руководств, относящихся к конкретным темам, таким как безопасность ИКТ или использование ориентированных на объект языков.

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

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

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

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

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

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

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

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

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

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

You Might Also Like