Содержание
- 2. Слияние виртуального и реального миров с образованием гибридного мира мираобразованием
- 3. Industry 4.0 | Что это? Концепция четвертой промышленной революции («Индустрии 4.0») была сформулирована в 2011 году
- 4. Industry 4.0 | Где человек? ПУМСС-2018, 03-06 сентября 2018, г. Самара
- 5. Industry 4.0 | Ключевые компоненты* Cyber-Physical Systems (CPS) Internet of Things (IoT) Internet of Services Smart
- 6. ВОПРОС 1: РОЛЬ ЗАДАЧ УПРАВЛЕНИЯ ФУНКЦИОНАЛЬНОЙ БЕЗОПАСНОСТЬЮ В ОБЕСПЕЧЕНИИ ЭФФЕКТИВНОГО ФУНКЦИОНИРОВАНИЯ АПК
- 7. 1 Ошибка в космическом агентстве В июне 1996 года специалисты Европейского космического агентства осуществляли запуск ракеты
- 8. Ошибка в контролирующем программном обеспечении, написанном на языке программирования Ada, вызвало самоликвидацию ракеты через 37 секунд
- 9. Сбой в медицинском оборудовании Сбои случались и в медицинском оборудовании. В 1980-годы несколько пациентов погибли после
- 11. Света не было не только в домах граждан, но и в больницах, школах, на вокзалах. Не
- 12. Авария в Мексиканском заливе: возможна ли программная ошибка?
- 13. В статье, появившейся в Houston Chronicle от 19 июля 2010 года, утверждается, что "экраны дисплеев на
- 14. Вопрос 2: Место системы информационной поддержки управления в обеспечении функционирования сложных систем
- 15. Объект управления Управляющая система Окружающая объект управления среда Данные и информация, характеризующие состояние объекта управления Информационные
- 16. Вывод: Необходимо рассматривать как единое целое Hard+soft+brain
- 17. Место программной компоненты в управлении сложными техническими системами ПО Компонент системы Компонент системы Компонент системы Компонент
- 18. Основные подходы к обеспечению безопасности программных систем
- 19. Вывод: Необходимо совершенствование технологий разработки, позволяющих обеспечивать защиту изделий как от злонамеренных действий, так и от
- 20. Вопрос 3: В чем причина кризиса в IT?
- 21. Статистические данные о текущей эффективности реализации программных проектов (по данным, относящимся к США) Источники данных The
- 23. About The Standish Group
- 24. The Standish Group is a primary research advisory organization that focuses on software project performance. Using
- 25. The Standish Group was formed in 1985 with a vision of innovating group refection using case-based
- 26. Эффективность реализации программных проектов по данным 2010 г.
- 27. Динамика эффективности реализации программных проектов
- 28. Последствия недостаточного качества реализации программных проектов
- 29. Реальная востребованность возможностей программного продукта Источник:The Standish Group Report CHAOS. Project Smart, 2014
- 30. Статистические данные о эффективности реализации программных проектов (по данным, относящимся к США) Ежегодные затраты на реализацию
- 31. Статистические данные о эффективности реализации программных проектов (по данным, относящимся к США, продолжение) 4. Среднее превышение
- 32. Основной вывод отчетаThe Standish Group Report CHAOS. Project Smart, 2014 В настоящее время недочетов в программных
- 33. Факторы, приводящие к провалу проекта
- 34. Факторы успеха проекта и их значимость
- 35. Вывод: ...В следующий раз, услышав о провале проекта по внедрению корпоративной информационной системы, подумайте прежде всего
- 36. Конус неопределенности программного продукта 4х 2х х 0,5х 0,25х Точность оценки стоимости и времени Анализ требований
- 37. Роль дисциплины при проектировании сложных программных систем
- 38. Роль моделирования при реализации программных проектов
- 39. Возможности модели жизненного цикла программной системы (потенциальность модели) должна соответствовать сложности реализации программного продукта. Сложность реализации
- 40. Некоторые модели жизненного цикла
- 42. Содержание MDA
- 43. Примеры классов (фреймов) моделей программных систем
- 44. Code-and-fix model Реализация программного продукта сводится к непосредственному кодированию задачи в том виде, как она понимается.
- 45. Stagewise model Разработка программного продукта сводится к следующей последовательности действий: Планирование разработки. Разработка операционной спецификации. Кодирование.
- 48. Общий вид V-модели жизненного цикла Ветка конструирования Ветка требований
- 49. Взаимосвязь разработки и испытаний 1. Это две стороны одной медали: разработки и тестирование неделимое целое 2.
- 50. Куликов С.С. Тестирование программного обеспечения. Базовый курс.- Минск, Четыре четверти, 2017.-312 с.
- 51. Краткий очерк истории тестирования 50-60 годы Концепция «исчерпывающего тестирования» (exhausting testing): проверка всех возможных путей выполнения
- 52. Краткий очерк истории тестирования (продолжение) 70-е годы Возникли две фундаментальные идеи тестирования: (а). Доказательство работоспособности программ
- 53. Философия «белого» и «черного» ящиков «Белый» ящик. Цель – проверить каждый путь алгоритма. При этом спецификация
- 54. Стратегии тестирования интеграции Восходящее тестирование Нисходящее тестирование Модифицированный нисходящий метод Метод сэндвича Метод «большого скачка» Источник:
- 55. Краткий очерк истории тестирования (продолжение) 80-е годы 1. Ключевое изменение места тестирования в разработке ПО: вместо
- 56. Краткий очерк истории тестирования (продолжение) 90-е годы Переход от тестирования к более всеобъемлющему процессу, именуемому «Управление
- 59. Различие между SQA и SVV Процессы Продукты
- 60. Краткий очерк истории тестирования (продолжение) 2000-е годы Поиск новых подходов к обеспечению качества Автоматизация тестирования Во
- 61. Project Triangle (PMI-1994) Budget Time Required features & Functions
- 62. Project Triangle (Standish Group-2015) Budget Time Target, Goal, Value & Satisfaction ?
- 63. Краткий очерк истории тестирования (продолжение) Текущее состояние Гибкие методологии и гибкое тестирование Глубокая интеграция процессов испытаний
- 64. Основные выводы 1. Границы, критерии качества систем, требования к потребительским свойствам становятся все более размытыми. 2.
- 66. Разноаспектные подходы к тестированию программных средств (классические подходы)
- 70. Виды тестирования
- 72. Понятия альфа- тестирования …После того, как отдельные программные модули готовы, они объединяются в некое единое целое.
- 73. Понятие бета-тестирования По окончании работы с альфа-версией выпускается бета-версия. Она представляет собой реально работающую версию программы
- 74. Место альфа- и бета тестирования в испытании ПО
- 75. Сценарное тестирование Сценарное тестирование- классическое тестирование по предварительно написанным и задокументированным сценариям. В пользу сценарного тестирования:
- 76. Новые подходы к тестированию программных средств
- 77. Cloud, Fog, Edge computing
- 78. Ad hoc тестирование
- 79. Содержание Ad hoc тестирования Свободное тестирование (ad-hoc testing) – это вид тестирования, который выполняется без подготовки
- 80. Виды свободного тестирования (ad-hoc testing) Buddy testing – процесс, когда 2 человека, как правило разработчик и
- 81. Основные преимущества ad-hoc testing Нет необходимости тратить время на подготовку документации. Самые важные дефекты зачастую обнаруживаются
- 82. Исследовательское тестирование (Exploratory testing)
- 84. Понятие исследовательского тестирования Исследовательское тестирование (exploratory testing) — это одновременное изучение программного продукта, проектирование тестов и
- 85. Когда следует применять исследовательское тестирование? Когда нужно обеспечить быструю обратную связь для нового продукта или новой
- 86. Предпосылки к использованию исследовательского тестирования в чистом виде Мало времени : если тестовая документация написана, но
- 87. Использование исследовательского тестирование в дополнение к сценарному тестированию Тестировщики постоянно проходят одни и те же тестовые
- 88. Использование исследовательского тестирование в дополнение к сценарному тестированию (продолжение) Пришел внезапный запрос на изменения Времени на
- 89. Когда одним исследовательским тестированием не обойтись Приложение стандартизованное: Приложения, работающие по стандартам и гостам, а также
- 90. Когда одним исследовательским тестированием не обойтись (продолжение) Тестовые сценарии отдаются на в стороннюю организацию. Контролировать поставленную
- 91. Системное сочетание исследовательского и сценарного тестирования Исследовательское тестирование — не означает полное отсутствие документации и хаос,
- 94. Содержание регрессионного тестирования Регрессионное тестирование (regression testing) – это механизм проверки, который направлен на обнаружение различных
- 95. Тема : Стандартизация – путь к успеху программных проектов
- 97. Различие между SQA и SVV Процессы Продукты
- 98. Вывод: Следование положениям стандартов обеспечивает «правильную» реализацию программного проекта в случае стабильного состояния объекта управления Испытания
- 99. Направления стандартизации ЖЦ СОД и У Организуется и стимулируется Международной организацией по стандартизации (ISO – International
- 100. Направления стандартизации ЖЦ СОД и У (продолжение) 2. Направление, развиваемое институтом инженеров электротехники и радиоэлектроники (IEEE
- 101. Направления стандартизации ЖЦ СОД и У (продолжение) 3. Третье направление стимулируется министерством обороны США (Department of
- 102. Структура стандартов ESA PSS-05-XX
- 104. Методология «развертывание функций качества» - Quality Function Deployment-QFD
- 105. Четырехфазная модель American Supplier Institute-АSI
- 106. Анализ коренных причин (Root Cause Analysis)
- 109. Принципы SMART Решение задач в рамках RCA основано на принципах SMART : Specific :учет специфики проблемы;
- 110. Краткое описание содержания задач RCA Определение проблемы. Корректное определение проблемной ситуации является критически важным фактором успеха
- 111. Краткое описание содержания задач RCA (продолжение) 2. Понимание проблемы. Основой решения этого класса задач является структуризация
- 112. Краткое описание содержания задач RCA (продолжение) 3. Немедленное действие. Фокусом этой задачи является незамедлительная реализация мер
- 113. Краткое описание содержания задач RCA (продолжение) 4. Корректирующие действия. Определение и ранжирование наиболее возможных причин проблемы.
- 114. Краткое описание содержания задач RCA (продолжение) 5. Подтверждение правильности решения. После определения способов воздействия на коренные
- 115. Базовые положения RCA 1. RCA должен выполняться на систематической основе; допущения, возможные причины и заключение должны
- 116. Базовые положения RCA 4. Должны быть либо понятны отношения между коренными причинами. Выявление этих отношений позволит
- 117. Инструментарий и технологии RCA.
- 118. «Пять Почему?»
- 119. Парето – анализ
- 120. Диаграмма причинно – следственных связей
- 123. Контрольные диаграммы (отдельный процесс)
- 124. Контрольные диаграммы (совокупность процессов)
- 125. Тема: Реализация системного подхода при испытаниях программных систем
- 127. IEEE Std 1012 - 2004 IEEE Standard for Software Verification and Validation Recognized as an American
- 129. Структурирование вариантов использования на основе целей пользователей Вариант использования представляет собою текстовое описание шагов, которые выполняет
- 130. Формальные приемы структурного анализа 1. Количество ошибок в программном модуле прямо пропорционально сложности модуля Источник: В.В.Липаев
- 131. МОДЕЛЬ СММ
- 132. Пять уровней зрелости СММ
- 133. Начальный уровень Уровень 1 - означает, что процессы создания ПО на предприятии не формализованы. Они не
- 134. повторяемый уровень Уровень 2. Внедрены внедрить формальные процедуры выполнения основных этапов процесса разработки. Результаты выполнения процесса
- 135. Определенный уровень Уровень 3. Требует, чтобы все элементы процесса были определены, стандартизованы и задокументированы. Основное отличие
- 136. Управляемый уровень Уровень 4. На предприятии используются количественные показатели качества как программных продуктов, так и процесса.
- 137. Оптимизирующий уровень Уровень 5. Подразумевает, что главной задачей предприятия становится постоянное улучшение и повышение эффективности существующих
- 139. Скачать презентацию