
- •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 2 3
1. Проверка документации.
1. Проверка документации.
1. Проверка документации.
2. Проверка разделения ПО и наличия защищенных интерфейсов (на основе анализа документации).
2. Проверка разделения ПО и наличия защищенных интерфейсов (на основе анализа документации и с использованием программных средств).
2. Проверка разделения ПО и наличия защищенных интерфейсов(с использованием программных средств, в том числе на основе анализа исходного кода).
3. Проверка соответствия утвержденному типу (на основе анализа документации).
3. Проверка соответствия утвержденному типу (идентификация) (на основе анализа документации и с использованием программных средств).
3. Проверка соответствия утвержденному типу (идентификация) (на основе анализа документации и с использованием программных средств, в том числе на основе анализа исходного кода).
4. Испытание (тестирование) функций ПО (с использованием аппаратных и программных средств).
4. Испытание (тестирование) ПО с целью u1091 установления правильности функционирования
и определения его свойств и характеристик, в том числе тестирование обработки данных (с использованием аппаратных и программных средств).
4. Испытание (тестирование) ПО с целью установления правильности функционирования и определения его свойств и характеристик и тестирование обработки данных (с использованием аппаратных и программных
средств, в том числе на основе анализа исходного кода).
5. Установление степени защищенности ПО и данных (на основе анализа документации).
5. Тестирование защищенности ПО и данных (с использованием программных средств).
5. Тестирование защищенности ПО и данных (с использованием программных средств, в том
числе на основе анализа исходного кода).
Примечание - Высокая жесткость испытаний с использованием анализа исходного кода применяется в тех случаях, когда имеют дело с ПО сложных и ответственных измерительных систем, в том числе систем, используемых при коммерческих расчетах, или когда к таким системам предъявляются исключительные требования по безопасности их функционирования. В обычных случаях ограничиваются низкой и средней жесткостью испытаний, при которых тестирование ПО осуществляется методом «черного ящика».
Определяются методы испытаний в соответствии с установленной жесткостью испытаний, которые должны найти отражение в тестовых заданиях. Составляются тестовые задания с учетом того, что эти задания
и/или исходные данные для их формирования, а также методы их выполнения должны обеспечить проверку всех основных режимов функционирования испытываемого (тестируемого) ПО, а также его соответствие требованиям нормативной документации.
Тестовые задания разрабатываются с учетом установленных видов испытаний, руководства пользователя, а также другой необходимой технической документации, представляемой на аттестацию. Каждому требованию и/или контролируемой функции u1076 должно соответствовать не менее одного тестового задания.
В тестовых заданиях определяются контролируемые свойства, параметры и характеристики ПО, методы испытаний тестируемого ПО, необходимые для этого исходные данные, программные продукты, с которыми сравниваются результаты, получаемые в процессе испытаний (эталонное ПО), а также критерии, позволяющие производить оценку характеристик тестируемого ПО.
Описывается последовательность действий при проведении процедуры испытаний (тестирования) в соответствии с установленной жесткостью испытаний и перечнем разработанных тестовых заданий.
Результаты испытаний ПО признаются положительными, если:
- программа соответствует функциональным возможностям, описанным в документации, и выполняет в рамках тестовых заданий все функции, декларируемые в документации;
- полученные значения параметров и характеристик программы при выполнении всех тестовых заданий удовлетворяют установленным критериям или находятся в допустимых пределах отклонений от них;
- в программе реализованы необходимые методы защиты и идентификации в соответствии с требованиями;
- программная документация соответствует требованиям нормативных документов.
Если в процессе выполнения какого-либо из тестовых заданий произойдет отказ программы, ее «зависание» или искажение результатов, то данное тестовое задание может быть модифицировано для подтверждения
ошибки функционирования и повторено. Выявленные ошибки фиксируются в протоколе испытаний.
По результатам испытаний ПО СИ составляется акт о результатах его исследования (тестирования) неотъемлемой частью которого является протокол испытаний, подписанный непосредственными исполнителями испытаний (тестирования) .
Дальнейшие разделы рекомендации конкретизируют виды испытаний (тестирования).
Система сертификации программного обеспечения средств измерений и
информационно-измерительных систем Правила функционирования