- •Структура курса «Управление качеством»
- •Место курса «Управление качеством» в подготовке IT- специалистов
- •Ошибка в контролирующем программном обеспечении, написанном на языке программирования Ada, вызвало самоликвидацию ракеты
- •Сетецентрическое управление системами
- •MANET, VANET and FANET.
- •High-Level JAUS system architecture ( Joint Architecture for Unmanned Systems )
- •A FANET scenario to extend the scalability of multi-UAV systems
- •A FANET application scenario for reliable multi-UAV communication network.
- •Architecture of MBSS containing mesh STAs, APs and portals as designed in IEEE
- •Использования беспроводных технологий четвертого поколения
- •Коммуникационная инфраструктура GIG
- •Схема информационных взаимодействий в сети DTN
- •Обобщённая модель сетецентрического подхода в военном деле
- •Эффект GIG
- •Интероперабельность информационных систем различного назначения
- •Обеспечение интероперабельности – основная тенденция в развитии открытых систем
- •Интероперабельность информационных систем различного масштаба
- •Р.П. Быстров, В.Н. Корниенко, А.Я. Олейников Интероперабельность, информационное противоборство и радиоэлектронная борьба//“Успехи современной
- •Соотношение основных понятий, связанных с проблемой итероперабельности
- •Industry 4.0 | Что это?
- •Слияние виртуального и реального миров с образованием гибридного мира мираобразованием
- •Industry 4.0 | Где человек?
- •Industry 4.0 | Ключевые компоненты*
- •Новая реальность: сетецентрические системы
- •Цифровая экосреда «умного
- •Определение SoS
- •Свойства SoS
- •Парадокc SoS
- •Концептуальная основа графодинамических систем
- •Вопрос
- •Статистические данные о текущей эффективности реализации программных проектов
- •About The Standish Group
- •The Standish Group is a primary research advisory organization that focuses on software
- •The Standish Group was formed in 1985 with a vision of innovating group
- •Эффективность реализации программных проектов по данным 2010 г.
- •Динамика эффективности реализации программных проектов
- •Последствия недостаточного качества реализации программных проектов
- •Реальная востребованность возможностей программного продукта
- •Статистические данные о эффективности реализации программных проектов
- •Статистические данные о эффективности реализации программных проектов
- •Основной вывод отчетаThe Standish Group
- •Факторы, приводящие к провалу проекта
- •Факторы успеха проекта и их значимость
- •Вывод:
- •Общие положения Total Quality Management (TQM)
- •Эволюция подходов к управлению качеством
- •Что такое качество ?
- •Project Triangle
- •Project Triangle
- •Пещера Платона
- •Компоненты TQM
- •Содержание TQM
- •Содержание «Цикла Деминга»
- •Цикл Деминга
- •Базовые положения TQM
- •Базовые положения TQM
- •Базовые положения TQM
- •Роль дисциплины при проектировании сложных программных систем
- •Содержание MDA
- •Место спецификации требований в жизненном цикле программной системы
- •Куликов С.С. Тестирование программного обеспечения. Базовый курс.- Минск, Четыре четверти, 2017.-312 с.
- •Краткий очерк истории тестирования
- •Краткий очерк истории тестирования (продолжение)
- •Реализация классических подходов
- •Виды тестирования
- •Философия «белого» и «черного» ящиков
- •Стратегии тестирования интеграции
- •Краткий очерк истории тестирования (продолжение)
- •Краткий очерк истории тестирования (продолжение)
- •Петля обратной связи как инструмент контроля реализации проекта
- •Содержание регрессионного тестирования
- •Сценарное тестирование
- •Краткий очерк истории тестирования (продолжение)
- •Новые подходы к тестированию программных средств
- •Понятия альфа- тестирования
- •Понятие бета-тестирования
- •Сценарное тестирование
- •Ad hoc тестирование
- •Содержание Ad hoc тестирования
- •Виды свободного тестирования (ad-hoc testing)
- •Основные преимущества ad-hoc testing
- •Исследовательское тестирование
- •Понятие исследовательского тестирования
- •Когда следует применять исследовательское тестирование?
- •Предпосылки к использованию исследовательского тестирования в чистом виде
- •Использование исследовательского тестирование в дополнение к сценарному тестированию
- •Использование исследовательского тестирование в дополнение к сценарному тестированию (продолжение)
- •Когда одним исследовательским тестированием не обойтись
- •Когда одним исследовательским тестированием не обойтись
- •Системное сочетание исследовательского и сценарного тестирования
- •Краткий очерк истории тестирования (продолжение)
- •Краткий очерк истории тестирования (продолжение)
- •Менеджмент на основе качества
- •Принципы менеджмента на основе качества
- •Принципы менеджмента на основе качества (продолжение)
- •Точки зрения на проект в рамках методологии MSF
- •PMBOK
- •Анализ коренных причин (Root Cause Analysis)
- •Принципы SMART
- •Краткое описание содержания задач RCA
- •Краткое описание содержания задач RCA (продолжение)
- •Краткое описание содержания задач RCA (продолжение)
- •Краткое описание содержания задач RCA (продолжение)
- •Краткое описание содержания задач RCA (продолжение)
- •Базовые положения RCA
- •Базовые положения RCA
- •Инструментарий и технологии RCA.
- •«Пять Почему?»
- •Парето – анализ
- •Диаграмма причинно – следственных связей
- •Контрольные диаграммы (отдельный процесс)
- •Контрольные диаграммы (совокупность процессов)
- •Краткие рекомендации по применению RCA
- •Краткие рекомендации по применению RCA
- •Возможные причины неудачного применения RCA
- •Возможные причины неудачного применения RCA (продолжение)
- •Ситуации повторяются
- •Системы, состоящие из частей абсолютно разной природы, имеющих совершенно несхожие функции, подчиняются одним
- •Гоме́р — древнегреческий поэт-сказитель, создатель эпических поэм «Илиада» и «Одиссея». Предположительно, был рапсодом*.
- •Определение
- •Базовые конструкции системных архетипов
- •Направления применения архетипов
- •Архетип 1. Уравновешивание с задержкой
- •Архетип 2. Пределы роста:
- •Пределы роста (пределы улучшений)
- •Противодействие приходит либо из неподконтрольных подразделений, либо из внешней среды
- •Шаги по урегулированию ситуации
- •Подмена проблем (Shifting the Burden)
- •Содержание системного архетипа
- •Шаги по урегулированию ситуации
- •Эрозия целей
- •Эрозия целей (1)
- •Шаги по урегулированию ситуации
- •Нормативное обеспечение управления проектами, портфелями, программами
- •Роли проекта
- •Назначение проекта как модели создаваемого объекта
- •Принципы проектирования
- •Принципы проектирования (продолжение)
- •Принципы проектирования (продолжение)
- •Принципы проектирования (продолжение)
- •Роль стандартизации жизненного цикла в управлении качеством СОД и У
- •Наиболее значимые стандарты
- •Базовые этапы (процессы) ЖЦ СОД и У
- •Направления стандартизации ЖЦ СОД и У
- •Направления стандартизации ЖЦ СОД и У (продолжение)
- •Направления стандартизации ЖЦ СОД и У (продолжение)
- •Структура стандартов ESA PSS-05-XX
- •МОДЕЛЬ СММ
- •Пять уровней зрелости СММ
- •Начальный уровень
- •повторяемый уровень
- •Определенный уровень
- •Управляемый уровень
- •Оптимизирующий уровень
- •ПЛАНИРОВАНИЕ ПРОЕКТА
- •Различие между SQA и SVV
- •Петля обратной связи как инструмент контроля реализации проекта
- •Роль модели ЖЦ программного продукта в управлении его качеством
- •См. курс «Моделирование» - «внешняя и внутренняя среды программного проекта»
- •Концептуальная основа гарантированного управления качеством
- •Планирование проекта
- •Компоненты плана проекта
- •Показатели реалистичности плана проекта (дефекты планирования)
- •Объекты контроля на стадии валидации и верификации программного продукта
- •Системные Архетипы
- •Ситуации повторяются
- •Системы, состоящие из частей абсолютно разной природы, имеющих совершенно несхожие функции, подчиняются одним
- •Определение
- •Базовые конструкции системных архетипов
- •Архетип 1. Уравновешивание с задержкой
- •Архетип «Уравновешивание с задержкой»
- •Пример реализации архетипа «Уравновешивание с задержкой»
- •Архетип 2. Пределы роста:
- •Пределы роста (пределы улучшений)
- •Архетип «Пределы Роста»
- •Пример учета стоимости устранения дефектов
- •Пример архетипа «Пределы роста»
- •Архетип 3. Подмена проблемы
- •Эрозия целей
- •Несбалансированность параметров проекта по показателю количества дефектов
- •Несбалансированность проекта по показателю бюджета
- •КОНЕЦ ЛЕКЦИЙ
Направления стандартизации ЖЦ СОД и У
1.Организуется и стимулируется Международной организацией по стандартизации (ISO – International Standard Organization) и международной комиссией по электротехнике (IEC – International Electrotechnical Commission). Стандартизации подвергаются наиболее общие технологические процессы, имеющие значение для международной кооперации
Направления стандартизации ЖЦ СОД и У (продолжение)
2. Направление, развиваемое институтом инженеров электротехники и радиоэлектроники (IEEE – Institute of Electrotechnical and Electronics Engineers) совместно с Американским национальным институтом стандартизации (American National Standards Institute – ANSI).
Стандарты ISO\IEC и ANSI / IEEE в основном имеют рекомендательный характер
Направления стандартизации ЖЦ СОД и У (продолжение)
3. Третье направление стимулируется министерством обороны США (Department of Defense – DOD). Стандарты DOD имеют обязательный характер для фирм, работающих по заказу Министерства обороны США.
Структура стандартов ESA PSS-05-XX
МОДЕЛЬ СММ
181
Пять уровней зрелости СММ
182
Начальный уровень
Уровень 1 - означает, что процессы создания ПО на предприятии не формализованы. Они не могут строго планироваться и отслеживаться, их успех носит случайный характер. Результат работы целиком
и полностью зависит от личных качеств отдельных сотрудников. При увольнении таких сотрудников проект останавливается.
183
повторяемый уровень
Уровень 2. Внедрены внедрить формальные процедуры выполнения основных этапов процесса разработки. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства
планирования и управления дают возможность повторения ранее достигнутых успехов.
184
Определенный уровень
Уровень 3. Требует, чтобы все элементы
процесса были определены, стандартизованы и задокументированы. Основное отличие от уровня 2 заключается в том, что все этапы процесса уровня 3 планируются и управляются на основе единого стандарта предприятия. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей.
185
