
- •1.12. Лекция: Процесс разработки программного обеспечения
- •1.1.1[Править] Процесс
- •1.1.2[Править] Совершенствование процесса
- •1.1.3[Править] Классические модели процесса
- •1.2[Править] 3. Рабочий продукт, дисциплина обязательств, проект
- •1.2.1[Править] Рабочий продукт
- •1.2.2[Править] Дисциплина обязательств
- •1.2.3[Править] Проект
- •1.3Интегрированная система поддержки жизненного цикла
- •1.4Введение
- •Определение ис
- •Классификация ис
- •Классификация по масштабу
- •Классификация по архитектуре
- •Классификация по характеру использования информации
- •Классификация по системе представления данных
- •Классификация по поддерживаемым стандартам управления и технологиям коммуникации
- •Классификация по степени автоматизации
- •Роль требований в задаче внедрения аис
- •1.5Понятие требования. Классификации требований
- •1.5.1Определение понятия требования
- •1.5.2Классификация требований
- •Требования к продукту и процессу
- •Уровни требований
- •Системные требования и требования к программному обеспечению
- •Функциональные, нефункциональные требования и характеристики продукта
- •Классификация rup
- •1.5.3Методологии и стандарты, регламентирующие работу с требованиями
- •1.6Свойства требований
- •Полнота.
- •Ясность (недвусмысленность, определенность, однозначность спецификаций).
- •Корректность и согласованность (непротиворечивость).
- •Верифицируемость (пригодность к проверке).
- •1.7Процесс анализа требований
- •1.7.1Рабочий поток анализа требований
- •1.7.2Почему нужно анализировать требования?
- •1.7.3Кто создает и использует требования
- •1.7.4Организация работы с требованиями на примере msf
- •1.8Контекст задачи анализа требований
- •1.8.1Анализ требований, бизнес-анализ, анализ проблемной области
- •Роль глоссария при ат.
- •1.8.2Методологии бизнес-анализа
- •1.8.3Требования и архитектура аис
- •1.8.4Анализ требований и другие рабочие потоки программной инженерии
- •1.9Выявление требований
- •1.9.1Источники требований
- •1.9.2Стратегии выявления требований Интервью
- •1. Подготовка
- •2. Проведение опроса
- •Завершение
- •Что нужно помнить при опросе
- •Анкетирование
- •Наблюдение
- •Самостоятельное описание требований
- •Совместные семинары
- •Прототипирование
- •1.10Формирование видения
- •1.10.1Видение продукта и границы проекта
- •1.10.2Концепция в гост рф
- •1.10.3Видение в rup
- •1.10.4Видение / рамки в msf
- •1.11Классификация и специфицирование требований
- •1.11.1Акторы и варианты использования
- •1.11.2Глоссарий
- •1.11.3Спецификация варианта использования
- •Свободный формат
- •Шаблон полного описания варианта использования по а. Коберну
- •Табличные представления варианта использования
- •Шаблон варианта использования rup
- •1.12Расширенный анализ требований. Моделирование
- •1.12.1Какие модели использовать
- •1.12.2Модели uml, поясняющие функциональность системы Диаграмма вариантов использования
- •Диаграмма действий
- •Диаграмма состояний
- •1.12.3Диаграммы uml, поясняющие внутреннее устройство системы
- •Диаграмма классов
- •1.12.4Альтернативные языки моделирования Диаграмма потоков данных
- •Другие виды моделей
- •1.13Расширенный анализ требований. Иллюстрированные сценарии и прототипы
- •1.13.1Цели прототипирования
- •1.13.2Классификация прототипов
- •Горизонтальный прототип
- •Вертикальный прототип
- •Одноразовый прототип
- •Эволюционный прототип
- •Бумажный прототип
- •Раскадровка
- •1.13.3Иллюстрированные сценарии прецедентов
- •Ориентиры
- •Средние значения атрибутов и объемы объектов
- •Средняя интенсивность использования
- •1.14Документирование требований
- •1.14.1Документирование требований в соответствие с гост рф
- •Структура тз в соответствие с гост 34.602-89
- •Описание требований к системе в соответствие с гост 34.602-89
- •1.14.2Документирование требований в rup
- •1.14.3Документирование требований на основе ieee Standard 830-1998
- •1.14.44. Требования к внешнему интерфейсу
- •4.1 Интерфейсы пользователя
- •4.2 Интерфейсы оборудования
- •4.3 Интерфейсы по
- •4.4 Интерфейсы передачи информации
- •1.14.55. Другие нефункциональные требования
- •5.1 Требования к производительности
- •1.14.6Документирование требований в msf
- •1.15Проверка требований
- •1.15.1Верификация и валидация
- •1.15.2Некоторые типичные проблемные ситуации процесса формирования и оценки требований Двусмысленность требований
- •"Золочение" продукта
- •Минимальная спецификация
- •Пропуск типов пользователей
- •1.15.3Методы и средства проверки требований
- •Неофициальные просмотры требований
- •Инспекции
- •Разработка тестов
- •Определение критериев приемлемости
- •1.16Введение в управление требованиями.
- •1.16.1Принципы и приемы управления требованиями Базовая версия требований
- •Процедуры управления требованиями
- •Контроль версий
- •Атрибуты требований
- •Контроль статуса требований
- •Измерение трудозатрат, необходимых для управления требованиями
- •1.16.2Управление изменениями Управление незапланированным ростом объема
- •Процесс контроля изменений
- •Анализ влияния изменения
- •Трассируемость требований
- •1.17Совершенствование процессов работы с требованиями
- •1.17.1Модели совершенствования
- •Область процессов "Управление требованиями"
- •Область процессов "Разработка требований"
- •1.17.2Принципы совершенствования
- •1.17.3Процесс совершенствования
- •Оценка текущих приемов
- •Планирование
- •Создание и апробация новых процессов
- •Оценка результатов и принятие решений
- •1.18Требования в управлении проектом
- •1.18.1От рамок проекта к экспресс-планированию
- •1.18.2Планирование проекта на основе требований, путь rup
- •1.18.3Требования в гибких методологиях
- •Артефакты для работы с требованиями в гибких методологиях
- •Планирование на основе требований на примере xp
- •Планирование версий и итераций
- •1.18.4Анализ требований и управление рисками
- •1.18.5Стратегии и работы по управлению риском
- •1.19Заключение
- •1.19.1Современные тенденции в развитии аис и технологий их создания
- •1.19.2Покупное или заказное по - критерии выбора
- •1.19.4Процесс выбора решения
- •1.20Список литературы
- •Белые страницы msf
- •Microsoft Solutions Framework. Модель процессов msf, версия 3.1
- •Гост 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания
- •Гост 19.201-78 "Техническое задание, требования к содержанию и оформлению"
- •Гост 34.602-89 "Техническое задание на создание автоматизированной системы" (тз на ас)
- •1 Аттестации и программного обеспечения
- •1.1 Перечень объектов, подлежащих сертификации, и их характеристики
- •2 Оценка программного обеспечения
- •3 Системы сертификации программного обеспечения и ее стандарты
- •4 Виды испытаний программного обеспечения
- •Стандарты в области промышленного обеспечения.
- •Структура современного рынка программных средств
- •2Введение в программную инженерию
- •2.1Программная инженерия
- •2.2Связь программной инженерии с другими сферами науки
- •3Жизненный цикл пс
- •4Процесс создания пс
- •4.1Стадии разработки пс
- •4.2Понятие метода и технологии проектирования пс
- •4.2.1Определение метода и технологии
- •4.2.2Требования к технологии
- •5Подходы к проектированию по
- •5.1Нисходящий и восходящий подходы к разработке программ
- •5.2Макетирование
- •5.3Структурное программирование
- •5.4Модульное программирование (мп)
- •5.5Формирование структуры модулей программы
- •5.6Подход к разработке программных средств, используемых для автоматизации организационных процессов
- •6Управление требованиями
- •6.1Определение требования и заинтересованного лица
- •6.2Пирамида Требований
- •6.3Трассировка (Связь) между Требованиями
- •6.4Характеристики Хорошего Требования
- •6.5Процесса Управления Требованиями
- •7Модели жизненного цикла пс
- •7.1Каскадный жизненный цикл
- •7.2Спиральная модель
- •7.3Подход rad
- •8Ресурсы для жизненного цикла сложных программных средств
- •9Показатели качества программных средств
- •10Модели качества процессов конструирования
- •10.2Стандарты iso
- •10.3Шесть сигм
- •11Стандартизация пс
- •11.1Стандартизация программных продуктов
- •11.2Виды стандартных программных документов
- •11.3Стандартизация программных документов
- •12Тестирование пс
- •12.1Аттестация пс
- •12.2Испытания пс
- •12.3Оценка пс
- •12.4Виды испытаний по
- •13Сертификация пс
- •13.1Правовые акты по сертификации программных продуктов
- •13.2Сертификация пс
- •13.3Перечень объектов, подлежащих сертификации и их характеристики
- •13.4Сертификационные испытания пс
3 Системы сертификации программного обеспечения и ее стандарты
Схема организационной структуры СДС ПО СИИИС представлена в Приложении.
Организацией, создавшей систему, является ФГУП «ВНИИМС», разработавшее ГОСТ Р 8.596-2002 «ГСИ. Метрологическое обеспечение из мерительных систем. Общие положения» и рекомендацию МИ 2891-2004
«ГСИ. Общие требования к программному обеспечению средств измерений».В качестве органа по сертификации выступает Автономная некоммерческая организация «Межрегиональный испытательный центр» (АНО «МИЦ»), имеющая статус юридического лица, печать, штамп и расчетный счет в банке.
Реквизиты органа по сертификации представлены в Приложении.
Организация, создавшая СДС ПО СИИИС, выполняет следующие функции:
- разрабатывает и утверждает Правила функционирования СДС ПО СИИИС, знак соответствия СДС ПО СИИИС и порядок его применения, а также другие внутренние документы Системы;
- участвует в рассмотрении u1089 спорных вопросов, возникающих при функционировании СДС ПО СИИИС, и принимает по ним решения;
- осуществляет подготовку экспертов СДС ПО СИИИС. В соответствии с требованиями указанных нормативных документов проверяется наличие, достаточность и правильность представленной документации. При этом проверяются следующие разделы документации:
Описание структуры ПО и последовательности обработки данных. Структура ПО может быть представлена в виде одного или нескольких взаимосвязанных модулей, реализующих функции ПО, с учетом разделения
ПО. Описание структуры ПО может быть осуществлено в графическом виде с пояснениями и/или в текстовой форме. Описание каждого модуля ПО должно включать:
- наименование модуля;
- функции, реализуемые модулем, и реализованные в модуле алгоритмы;
- данные, используемые и/или изменяемые модулем;
- названия связанных (вызываемых) модулей.
Проверяется описание всех входных и выходных данных, последовательность обработки входных данных в структуре ПО и других программноаппаратных компонентах системы. Данный раздел документации должен содержать информацию о методе связи (интерфейсе) СИ и ПО, о данных, получаемых от и передаваемых в СИ программным обеспечением, описание всех аппаратных и программных компонент СИ, а также описание исполняемых файлов (название, размер в мегабайтах).
Описание всех выполняемых функций и параметров ПО, с учетом выделения частей, подлежащих метрологическому контролю (аттестации) с внесением контролируемых функций и параметров в отдельный список.
Для всех функций ПО должны быть описаны входные и выходные данные, а также результат выполнения.
Описание реализованных в ПО расчетных алгоритмов, а также их блок-схемы.
Должны быть приведены описания или логические схемы алгоритмов, функции, реализуемые алгоритмами в ПО, а также все величины, рассчитываемые с их помощью, и их формулы, данные о степени округления при расчетах (точность алгоритмов).
Описание интерфейсов, меню, диалогов и перечень команд для каждого интерфейса, включая заявление об их полноте, а также список, значение и действие всех команд, получаемых от клавиатуры, мыши и других
устройств ввода.
Описание реализованного метода идентификации ПО. Проверяется наличие информации о методе (алгоритме) идентификации ПО, способах идентификации ПО в соответствии с реализованным методом,
о системе кодификации номера версии.
Описание реализованных методов защиты ПО и данных. Проверяется описание реализованных методов (авторизация пользователя, журнал событий, кодирование данных и т.д.) защиты ПО и данных от не-
допустимых изменений и искажений, а также наличие сообщений об ошибках.
В соответствии со ст. 21 Федерального закона «О техническом регулировании» орган по сертификации:
- осуществляет подтверждение соответствия объектов добровольного подтверждения соответствия, в том числе при необходимости создает или привлекает на договорной основе испытательные лаборатории, в которых организует проведение испытаний ПО (ПП) по согласованным с заказчиком методикам;
- выдает Сертификаты соответствия на объекты, прошедшие добровольную сертификацию;
- предоставляет заявителю право на применение знака соответствия;
- приостанавливает или прекращает действие выданных им Сертификатов соответствия.
Испытательные лаборатории выполняют следующие функции:
- проводят испытания ПО (ПП) по согласованным с заказчиком методикам;
- оформляют результаты испытаний соответствующими протоколами, на основании которых орган по сертификации принимает решение о выдаче или об отказе в выдаче Сертификатов соответствия.
Порядок проведения сертификации программного обеспечения (программных продуктов) в СДС ПО СИИИС включает:
- подачу заявки на сертификацию;
- принятие решения по заявке на сертификацию, в том числе назначение экспертов на проведение основных работ по сертификации из числа экспертов органа по сертификации;
- оформление договора на проведение работ по сертификации;
- проведение сертификационной проверки ПО СИИИС, в том числе при необходимости проведение испытаний ПО (ПП) по согласованным с заказчиком методикам;
- принятие решения о выдаче Сертификата соответствия и разрешения использования знака соответствия либо об отказе в выдаче Сертификата соответствия;
- выдача Сертификата соответствия и разрешения использования знака соответствия;
- занесение юридического лица или индивидуального предпринимателя и перечня сертифицированного ПО (ПП) в Реестр СДС ПО СИИИС;
Все данные, в том числе выявленные несоответствия, полученные при анализе документации ПО, заносятся в протоколы испытаний. Перечень документов, сопровождающих ПО, объем и методы проверки документации могут корректироваться соглашением между исполнителем и заказчиком аттестации ПО.
Под проверкой структуры ПО понимается проверка правильности выделения его частей, подлежащих метрологическому контролю (аттестации), а также проверка наличия и правильности функционирования защищенных интерфейсов.
Проверка правильности разделения ПО.
При низкой и средней жесткости испытаний правильность разделения ПО проверяется посредством анализа документации, представленной заявителем аттестации, а также с помощью программных средств.
Все функции и параметры ПО, которые используются при обработке результатов измерений, влияют на них, или используются во вспомогательных функциях должны быть отнесены к части ПО, подлежащей метрологическому контролю (аттестации). На основе документации устанавливается реализованный метод разделения ПО или отсутствие разделения.
Проверяются сведения о наличии защищенного интерфейса между частями ПО, подлежащими и не подлежащими метрологическому контролю (аттестации).
В случае отсутствия разделения, все ПО подлежит метрологическому контролю (аттестации), однако документация должна содержать перечень функций и параметров, относящихся к контролируемым.
Этот перечень функций и параметров также подлежит проверке.
Для встроенного ПО его разделение и проверка разделения не проводятся.
При высокой жесткости испытаний правильность разделения ПО дополнительно проверяется при помощи анализа его исходного кода.
По исходному коду ПО проверяется правильность реализации защищенного интерфейса. Все модули, подпрограммы, процедуры, функции, параметры, переменные и т.д., участвующие в обработке информации должны быть охвачены защищенным интерфейсом.
По исходному коду рекомендуется составить структурную схему ПО (граф), отображающую потоки данных в ПО и способы их управления. Это позволяет проверить поступление измерительной информации только в
части ПО, подлежащие метрологическому контролю (аттестации), а также убедиться в возможности обращения к функциям ПО, к его параметрам и к данным, подлежащим метрологическому контролю (аттестации), только через защищенный интерфейс.
Сведения о разделении ПО заносятся в протокол испытаний. По результатам проверки может быть сделано замечание о неправильном разделении ПО и дана рекомендация о соответствующих коррективах.
Проверка интерфейса(ов) ПО.
Проверяется возможность недопустимого воздействия на ПО и данные через интерфейс(ы) ПО (СИ).
При низкой/средней жесткости, испытания проводятся на основе анализа документации и тестирования ПО с использованием программных средств.
С помощью программных средств выполняются все функции ПО, подлежащие метрологическому контролю (аттестации), и определяется их соответствие представленной документации. Исследуются меню, подменю, диалоги ПО с целью выявления не соответствующих документации функций, параметров и команд.
Проверяется фильтрация ввода данных через интерфейс и возможность введения недопустимых данных.
Для этой проверки в ПО могут вводиться данные:
- из диапазона допустимых значений;
- из диапазона недопустимых значений;
- данные на границах ограничений диапазона ввода;
- комбинации вышеуказанных категорий данных.
При высокой жесткости испытания проводятся на основе анализа исходного кода ПО При этом:- выявляются недокументированные функции, процедуры, параметры, переменные, команды и их использование в ПО;
- проверяется соответствие действия вводимых команд (с помощью диалогов, командной строки и т.д.) представленной документации.
Возможно использование других методов проверки правильности функционирования интерфейса(ов) ПО.
Под проверкой соответствия понимается проверка конкретного ПО на соответствие тому типу, который был утвержден (зафиксирован) при его аттестации, если такая аттестация ранее проводилась, а также проверка методов и способов идентификации.
Проверка соответствия.
При низкой и средней жесткости испытаний проверка соответствия утвержденному типу проводится на основе анализа представленной документации, а также с использованием программных средств. При этом может приниматься во внимание заявление заказчика аттестации об отсутствии изменений и модификаций части ПО, подлежащей метрологическому u1082 контролю (аттестации).
В случаях, когда имеются сомнения в полном соответствии конкретного ПО утвержденному типу, может быть проведено выборочное тестирование тех функций и частей ПО, относительно которых имеются указанные сомнения.
Проверка методов и способов идентификации программного обеспечения.
При низкой и средней жесткости испытаний методы и средства идентификации ПО проверяются на основе документации и выполнения функциональных испытаний (тестирования) ПО.
На основе документации проверяется описание реализованного метода идентификации и способа работы с ним. В случае разделения ПО на программном уровне устанавливается соответствие метода идентификации
принципу разделения ПО.
На основе анализа документации получают информацию обо всех частях (модулях) ПО (с учетом его разделения), охватываемых идентификацией. Все части ПО, подлежащие метрологическому контролю (аттестации) должны быть охвачены алгоритмом идентификации.
Оценивается соответствие метода идентификации уровню требуемой защиты. В качестве метода идентификации ПО может быть рекомендован номер версии с учетом. МИ 2891.
Проверяется наличие номинального значения, идентифицирующего ПО (номер версии, контрольная сумма и др.). Номинальное значение идентификации ПО вносится в свидетельство об аттестации.
Проверяется функция идентификации ПО, например, выводом номера версии на экран.
При высокой жесткости испытаний проводятся дополнительные испытания на основе анализа исходного кода ПО. При этом устанавливается:
- охват идентификацией всех частей ПО, подлежащих метрологическому контролю (аттестации), например, формирование номинального закрепляемого значения идентификации;
- охват идентификацией частей ПО, не подлежащих метрологическому контролю (аттестации);
- соответствие метода идентификации представленной документации.
- проведение инспекционного контроля сертифицированного ПО (ПП).
При разработке методик сертификационных испытаний ПО (ПП) СИИИС могут быть использованы ГОСТ Р 8. 596-2002 «ГСИ. Метрологическое обеспечение измерительных систем. Общие положения», а также рекомендации:
МИ 2955-2005. «ГСИ. Типовая методика аттестации программного обеспечения средств измерений и порядок ее проведения»,
МИ 2174-91. «ГСИ. Аттестация алгоритмов и программ обработки данных при измерениях. Основные положения»,
МИ 2517-99. «ГСИ. Метрологическая аттестация программного обеспечения средств измерений параметров физических объектов и полей с использованием компьютерных программ генерации цифровых тестовых сигналов»,
МИ 2518-99. «ГСИ. Метрологическая аттестация алгоритмов и программ генерации цифровых тестовых сигналов».