
- •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Сертификационные испытания пс
1.1 Перечень объектов, подлежащих сертификации, и их характеристики
Объектами, подлежащими добровольной сертификации, являются:
- программное обеспечение средств измерений как автономное, так и встроенное;
- программное обеспечение измерительных и информационноизмерительных систем;
- программное обеспечение контроллеров и вычислительных блоков, не входящих в состав информационно-измерительных систем.
Каждая позиция в перечне программного обеспечения (программных продуктов), подаваемом заявителем для прохождения процедуры добровольной сертификации, должна содержать следующую информацию:
- описание структуры ПО (ПП) и выполняемых функций, в том числе последовательность обработки данных;
- описание функций и параметров ПО (ПП), подлежащих метрологическому контролю (в соответствии с Рекомендацией МИ 2891-2004);
- описание реализованных в ПО (ПП) расчетных алгоритмов, а также их блок-схемы;
- описание модулей ПО (ПП);
- перечень интерфейсов и перечень команд для каждого интерфейса, включая заявление об их полноте;
- список, значение и действие всех команд, получаемых от клавиатуры, мыши и других устройств ввода;
- описание реализованной методики идентификации ПО (ПП);
- описание реализованных методов защиты ПО (ПП) и данных;
- описание интерфейсов пользователя, всех меню и диалогов;
- описание хранимых или передаваемых наборов данных;
- руководство пользователя;
- характеристики требуемых системных и аппаратных средств, если эта информация не приведена в руководстве пользователя.
Перечень документов, сопровождающих ПО (ПП), может корректироваться соглашением между исполнителем и заказчиком сертификации ПО.
Графическая и текстовая информация в документации выполняется таким образом, чтобы она была пригодна для полного и однозначного понимания.
Характеристиками ПО СИИИС, подлежащими процедуре добровольного подтверждения соответствия, являются характеристики, являющиеся количественными u1080 или качественными представлениями требований, предъявляемых к ПО (ПП) и устанавливаемых НД ПО, а именно:
а) требований к структуре, т.е. к выделению частей, подлежащих метрологическому контролю, а также к наличию и правильности функционирования защищенных интерфейсов;
б) требований к идентификации;
в) требований к защите измерительной и иной хранимой и передаваемой информации;
в) требований к соответствию характеристик тем, которые были установлены и приписаны ПО (ПП) при испытаниях СИ и других устройств с целью утверждения типа;
г) требований к степени влияния на метрологические и информационные характеристики средств измерений, информационноизмерительных систем.
Для подтверждения гарантий обеспечения соответствия ПО (ПП) установленным СДС ПО СИИИС требованиям в любой период деятельности заявителя в организации (фирме) должна быть организована документально оформленная Система контроля ПО СИИИС.
2 Оценка программного обеспечения
Представление всей необходимой документации на u1072 аттестацию в соответствии с требованиями рекомендации МИ 2891, а также стандартов ГОСТ Р ИСО/МЭК 12119 и ГОСТ Р ИСО 9127, является необходимым условием ее проведения. Рекомендуемые виды проверки документации применяются при всех степенях жесткости испытаний.
В соответствии с требованиями указанных нормативных документов проверяется наличие, достаточность и правильность представленной документации. При этом проверяются следующие разделы документации:
Описание структуры ПО и последовательности обработки данных. Структура ПО может быть представлена в виде одного или нескольких взаимосвязанных модулей, реализующих функции ПО, с учетом разделения
ПО. Описание структуры ПО может быть осуществлено в графическом виде с пояснениями и/или в текстовой форме. Описание каждого модуля ПО должно включать:
- наименование модуля;
- функции, реализуемые модулем, и реализованные в модуле алгоритмы;
- данные, используемые и/или изменяемые модулем;
- названия связанных (вызываемых) модулей.
Проверяется описание всех входных и выходных данных, последовательность обработки входных данных в структуре ПО и других программноаппаратных компонентах системы. Данный раздел документации должен содержать информацию о методе связи (интерфейсе) СИ и ПО, о данных, получаемых от и передаваемых в СИ программным обеспечением, описание всех аппаратных и программных компонент СИ, а также описание исполняемых файлов (название, размер в мегабайтах).
Описание всех выполняемых функций и параметров ПО, с учетом выделения частей, подлежащих метрологическому контролю (аттестации) с внесением контролируемых функций и параметров в отдельный список.
Для всех функций ПО должны быть описаны входные и выходные данные, а также результат выполнения.
Описание реализованных в ПО расчетных алгоритмов, а также их блок-схемы.
Должны быть приведены описания или логические схемы алгоритмов, функции, реализуемые алгоритмами в ПО, а также все величины, рассчитываемые с их помощью, и их формулы, данные о степени округления при расчетах (точность алгоритмов).
Описание интерфейсов, меню, диалогов и перечень команд для каждого интерфейса, включая заявление об их полноте, а также список, значение и действие всех команд, получаемых от клавиатуры, мыши и других
устройств ввода.
Описание реализованного метода идентификации ПО. Проверяется наличие информации о методе (алгоритме) идентификации ПО, способах идентификации ПО в соответствии с реализованным методом,
о системе кодификации номера версии.
Описание реализованных методов защиты ПО и данных. Проверяется описание реализованных методов (авторизация пользователя, журнал событий, кодирование данных и т.д.) защиты ПО и данных от не-
допустимых изменений и искажений, а также наличие сообщений об ошибках.
Примечания
1 Некоторые требования к документации в МИ 2891-04 охватывают требования,приведенные в стандартах ГОСТ Р ИСО/МЭК 12119-2000, ГОСТ Р ИСО 9127-94. Поэтому при проверке соответствия документации указанным стандартам, проверяются те требования к документации ПО, которые не регламентируются МИ 2891-04.2 Вся документация ПО проверяется на однозначность понимания и непротиворечивость.
Все данные, в том числе выявленные несоответствия, полученные при анализе документации ПО, заносятся в протоколы испытаний. Перечень документов, сопровождающих ПО, объем и методы проверки документации могут корректироваться соглашением между исполнителем и заказчиком аттестации ПО.
Под проверкой структуры ПО понимается проверка правильности выделения его частей, подлежащих метрологическому контролю (аттестации), а также проверка наличия и правильности функционирования защищенных интерфейсов.
Проверка правильности разделения ПО.
При низкой и средней жесткости испытаний правильность разделения ПО проверяется посредством анализа документации, представленной заявителем аттестации, а также с помощью программных средств.
Все функции и параметры ПО, которые используются при обработке результатов измерений, влияют на них, или используются во вспомогательных функциях должны быть отнесены к части ПО, подлежащей метрологическому контролю (аттестации). На основе документации устанавливается реализованный метод разделения ПО или отсутствие разделения.
Проверяются сведения о наличии защищенного интерфейса между частями ПО, подлежащими и не подлежащими метрологическому контролю (аттестации).
В случае отсутствия разделения, все ПО подлежит метрологическому контролю (аттестации), однако документация должна содержать перечень функций и параметров, относящихся к контролируемым.
Этот перечень функций и параметров также подлежит проверке.
Для встроенного ПО его разделение и проверка разделения не проводятся.
При высокой жесткости испытаний правильность разделения ПО дополнительно проверяется при помощи анализа его исходного кода.
По исходному коду ПО проверяется правильность реализации защищенного интерфейса. Все модули, подпрограммы, процедуры, функции, параметры, переменные и т.д., участвующие в обработке информации должны быть охвачены защищенным интерфейсом.
По исходному коду рекомендуется составить структурную схему ПО (граф), отображающую потоки данных в ПО и способы их управления. Это позволяет проверить поступление измерительной информации только в
части ПО, подлежащие метрологическому контролю (аттестации), а также убедиться в возможности обращения к функциям ПО, к его параметрам и к данным, подлежащим метрологическому контролю (аттестации), только через защищенный интерфейс.
Сведения о разделении ПО заносятся в протокол испытаний. По результатам проверки может быть сделано замечание о неправильном разделении ПО и дана рекомендация о соответствующих коррективах.
Проверка интерфейса(ов) ПО.
Проверяется возможность недопустимого воздействия на ПО и данные через интерфейс(ы) ПО (СИ).
При низкой/средней жесткости, испытания проводятся на основе анализа документации и тестирования ПО с использованием программных средств.
С помощью программных средств выполняются все функции ПО, подлежащие метрологическому контролю (аттестации), и определяется их соответствие представленной документации. Исследуются меню, подменю, диалоги ПО с целью выявления не соответствующих документации функций, параметров и команд.
Проверяется фильтрация ввода данных через интерфейс и возможность введения недопустимых данных.
Для этой проверки в ПО могут вводиться данные:
- из диапазона допустимых значений;
- из диапазона недопустимых значений;
- данные на границах ограничений диапазона ввода;
- комбинации вышеуказанных категорий данных.
При высокой жесткости испытания проводятся на основе анализа исходного кода ПО При этом:- выявляются недокументированные функции, процедуры, параметры, переменные, команды и их использование в ПО;
- проверяется соответствие действия вводимых команд (с помощью диалогов, командной строки и т.д.) представленной документации.
Возможно использование других методов проверки правильности функционирования интерфейса(ов) ПО.
Под проверкой соответствия понимается проверка конкретного ПО на соответствие тому типу, который был утвержден (зафиксирован) при его аттестации, если такая аттестация ранее проводилась, а также проверка методов и способов идентификации.
Проверка соответствия.
При низкой и средней жесткости испытаний проверка соответствия утвержденному типу проводится на основе анализа представленной документации, а также с использованием программных средств. При этом может приниматься во внимание заявление заказчика аттестации об отсутствии изменений и модификаций части ПО, подлежащей метрологическому u1082 контролю (аттестации).
В случаях, когда имеются сомнения в полном соответствии конкретного ПО утвержденному типу, может быть проведено выборочное тестирование тех функций и частей ПО, относительно которых имеются указанные сомнения.
Проверка методов и способов идентификации программного обеспечения.
При низкой и средней жесткости испытаний методы и средства идентификации ПО проверяются на основе документации и выполнения функциональных испытаний (тестирования) ПО.
На основе документации проверяется описание реализованного метода идентификации и способа работы с ним. В случае разделения ПО на программном уровне устанавливается соответствие метода идентификации
принципу разделения ПО.
На основе анализа документации получают информацию обо всех частях (модулях) ПО (с учетом его разделения), охватываемых идентификацией. Все части ПО, подлежащие метрологическому контролю (аттестации) должны быть охвачены алгоритмом идентификации.
Оценивается соответствие метода идентификации уровню требуемой защиты. В качестве метода идентификации ПО может быть рекомендован номер версии с учетом. МИ 2891.
Проверяется наличие номинального значения, идентифицирующего ПО (номер версии, контрольная сумма и др.). Номинальное значение идентификации ПО вносится в свидетельство об аттестации.
Проверяется функция идентификации ПО, например, выводом номера версии на экран.
При высокой жесткости испытаний проводятся дополнительные испытания на основе анализа исходного кода ПО. При этом устанавливается:
- охват идентификацией всех частей ПО, подлежащих метрологическому контролю (аттестации), например, формирование номинального закрепляемого значения идентификации;
- охват идентификацией частей ПО, не подлежащих метрологическому контролю (аттестации);
- соответствие метода идентификации представленной документации.
Примечание - В случае изменения файлов, входящих в состав ПО и охваченных алгоритмом идентификации, изменение значения, идентифицирующего ПО, устанавливается при испытаниях по проверке защиты от искажений ПО и данных.