
- •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Сертификационные испытания пс
13.3Перечень объектов, подлежащих сертификации и их характеристики
Объектами, подлежащими добровольной сертификации, являются:
программное обеспечение средств измерений как автономное, так и встроенное;
программное обеспечение измерительных и информационно-измерительных систем;
программное обеспечение контроллеров и вычислительных блоков, не входящих в состав информационно-измерительных систем.
Каждая позиция в перечне программного обеспечения (программных продуктов), подаваемом заявителем для прохождения процедуры добровольной сертификации, должна содержать следующую информацию:
описание структуры ПО (ПП) и выполняемых функций, в том числе последовательность обработки данных;
описание функций и параметров ПО (ПП), подлежащих метрологическому контролю (в соответствии с Рекомендацией МИ 2891-2004);
описание реализованных в ПО (ПП) расчетных алгоритмов, а также их блок-схемы;
описание модулей ПО (ПП);
перечень интерфейсов и перечень команд для каждого интерфейса, включая заявление об их полноте;
список, значение и действие всех команд, получаемых от клавиатуры, мыши и других устройств ввода;
описание реализованной методики идентификации ПО (ПП);
описание реализованных методов защиты ПО (ПП) и данных;
описание интерфейсов пользователя, всех меню и диалогов;
описание хранимых или передаваемых наборов данных;
руководство пользователя;
характеристики требуемых системных и аппаратных средств, если эта информация не приведена в руководстве пользователя.
Перечень документов, сопровождающих ПО (ПП), может корректироваться соглашением между исполнителем и заказчиком сертификации ПО.
Графическая и текстовая информация в документации выполняется таким образом, чтобы она была пригодна для полного и однозначного понимания.
Характеристиками ПО СИИИС, подлежащими процедуре добровольного подтверждения соответствия, являются характеристики, являющиеся количественными или качественными представлениями требований, предъявляемых к ПО (ПП) и устанавливаемых НД ПО, а именно:
требований к структуре, т.е. к выделению частей, подлежащих метрологическому контролю, а также к наличию и правильности функционирования защищенных интерфейсов;
требований к идентификации;
требований к защите измерительной и иной хранимой и передаваемой информации;
требований к соответствию характеристик тем, которые были установлены и приписаны ПО (ПП) при испытаниях СИ и других устройств с целью утверждения типа;
требований к степени влияния на метрологические и информационные характеристики средств измерений, информационно-измерительных систем.
Для подтверждения гарантий обеспечения соответствия ПО (ПП) установленным СДС ПО СИИИС требованиям в любой период деятельности заявителя в организации (фирме) должна быть организована документально оформленная Система контроля ПО СИИИС.
13.4Сертификационные испытания пс
Для удостоверения качества, надежности и безопасности применение сложных, критических ИС используемые в них ПС следует подвергать обязательной сертификации аттестованными, проблемно-ориентированными испытательными лаборатория»» Такие испытания необходимо проводить, когда программы управляют сложными процессами или обрабатывают столь важную информацию, что дефекты в них или недостаточное качество могут нанести значительный ущерб. Сертификационные испытания должны устанавливать соответствие комплексов программной документации и допускать их к эксплуатации в пределах изменения параметров внешней среды, исследованных при проведении проверках. Эти виды испытаний характеризуются наибольшее строгостью и глубиной проверок и должны проводиться специалистами, не зависимыми от разработчиков и заказчиков (пользователей). Испытания ПС должны опираться на стандарты, формализованные методики и нормативные документы разных уровней. Множество видов испытаний целесообразно упорядочивать и проводить поэтапно в процессе разработки для сокращения затрат на завершающихся сертификационных испытаниях.
Сертификация комплексов программ является их испытанием в наиболее жестких условиях тестирования особым третейским коллективом специалистов, имеющим право на официальный государственный или ведомственный контроль функций и качеств ПС и гарантирующим их соответствие стандартам и другим нормативным документам, а также надежность и безопасность применения. Получение и обобщение результатов испытаний, а также принятие решения о выдаче сертификата являются прерогативой испытательных лабораторий. Они должны быть специализированными для проведения испытаний объектов определенных классов, целенаправленно и систематически работать по созданию и совершенствованию методик и средств автоматизации испытаний ПС конкретного функционального назначения.
Специалисты–сертификаторы имеют право на расширение условий испытаний и на создание различных критических и стрессовых ситуаций в пределах нормативной документации, при которых должны обеспечиваться заданное качество и надежность рвения предписанных задач. Если все испытания проходят успешно, то на соответствующую версию ПС оформляется специальный документ – сертификат соответствия. Этот документ официально подтверждает соответствие стандартам, нормативен и эксплуатационным документам функций и характеристик «пытанных средств, а также допустимость их применения в определенной области.
Методология принятия решений о допустимости выдачи сертификата на ПС определяется оценкой степени его соответствия действующим и/или специально разработанным документам. В исходных нормативных документах должны быть сосредоточены все функциональные и эксплуатационные характеристики ПС, обеспечивающие заказчику и пользователям возможность корректного применения сертифицированного объекта во всем многообразии его функций и показателей качества. Выбор и ранжирование показателей должны проводиться с учетом классов ПС, и функционального назначения, режимов эксплуатации, степени критичности и жесткости требований к результатам функционирования и проявлениям возможных дефектов и ошибок. При этом могут привлекаться документы предшествующих этапов испытаний и документы, подтверждающие соблюдение аттестованных технологий при разработке программ на всех этапах. Испытания ПС в конкретных проблемно-ориентированных системах проводятся по правилам и методикам, принятым для соответствующих классов критических информационных систем, например, Авиационных или космических комплексов.
Работы по сертификации объединяются в технологический процесс, на каждом этапе которого регистрируются документы, отражающие состояние и качество результатов разработки ПС. В зависимости от характеристик объекта сертификации на ее выполнение выделяются ресурсы различных видов. В результате сложность программ, а также доступные для сертификации ресурсы становятся косвенными критериями или факторами, влияющими на выбор методов испытаний, а также на достигаемые качество и надежность ПС.
Сертификационные испытания удостоверяют качество и надежность ПС только в условиях, ограниченных конкретными стандартами и нормативными документами, с некоторой конечно» вероятностью. В реальных условиях эксплуатации принципиально возможны отклонения от характеристик внешней среды функционирования ПС за пределы, ограниченные сертификатом. ситуации, не проверенные при сертификационных испытания. Эти обстоятельства способны вызывать катастрофические последствия, угрожающие надежности функционирования и безопасности применения ПС. Наличие сертификата у ПС для критически систем является необходимым условием их допуска к эксплуатации. Однако любой сертификат на сложные системы не может гарантировать абсолютную их надежность применения, и всегда остается некоторый риск возникновения отказов.