37 - 49

37 Модель управления урегулирование проблемной

46 Основные факторы возникновения ошибок при

48 Основные факторы возникновения дефектов в

40 Содержание принципа дополнительности в

41 Основные стратегии действий в зависимости от

47 Основные факторы возникновения ошибок при

ситуации

разработке программных систем:

спецификациях

исследовании дефектов цифровой экосреды

уровня неопределенности проблемной ситуации:

разработке программных систем: Персональная позиция;

Модель управления для урегулирования проблемной

Небрежность / невежество.; Замкнутость

Некоторые основные факторы возникновения дефектов

Принцип дополнительности – один из важнейших

накопление опыта (ошибки отсутствия знаний)

Эмоциональная стабильность; Доминирование и

ситуации — это схема или алгоритм действий,

Небрежность / невежество: Нехватка знаний:

в спецификациях: Размытость границ фазы

методологических и эвристических принципов науки,

Когда проблема неясна из-за недостатка

недостаточная бдительность субъектов

направленных на диагностику, анализ и разрешение

разработчик может не знать особенностей

формирования требований. Различное восприятие и

основанный на введении взаимоисключающих классов

информации или опыта (например, никто не знает,

Персональная позиция:Упрямство или гиперконтроль

конфликтов, сбоев, нестабильностей или

используемой технологии, архитектурных принципов

представления о ценностях у участников процесса,

понятий, каждый из которых применим в особых

как работает новая технология), стратегия —

разработчика блокируют альтернативные решения. Это

неопределённостей в системе.

или требований заказчика. Игнорирование

причастных к формированию требований.

условиях, а их совокупность позволяет

учиться на практике: Проводить эксперименты и

снижает адаптивность команды.Пример: лидер отвергает

Этапы (структура модели): 1. Идентификация

стандартов и практик: отказ следовать проверенным

Множественность и неоднородность источников

воспроизведение целостности изучаемых объектов

пилотные проекты. Собирать данные и

использование новой технологии, хотя она решает

проблемной ситуации. Формулирование признаков

методологиям (например, code review, модульное

требований к потребительским свойствам компонент

Сформулирован Н.Бором в 1927 г. для описания

анализировать ошибки. Привлечение экспертов –

проблему.Решение: фасилитация обсуждений и вовлечение

наличия проблемы (отклонения, сбои, жалобы);

тестирование) приводит к ошибкам.Недостаточное

информационно-вычислительных систем. Различие в

квантовомеханических явлений. В контексте

консультации или найм специалистов.

внешних экспертов. Эмоциональная стабильность:

Определение заинтересованных сторон; Установление

тестирование: ошибка может остаться незамеченной

требованиях к качеству реализации функциональных и

исследования дефектов цифровой экосреды принцип

Постепенное масштабирование – избегание

Эмоциональная нестабильность (гнев, тревога) нарушает

масштаба и границ ситуации. 2. Диагностика и анализ

из-за небрежной проверки или отсутствия

нефункциональных свойств у разных пользователей

дополнительности может означать, что при изучении

больших рисков. Обучать команду, используя

рациональное принятие решений. Конфликты в команде

Сбор данных о проблеме: причины, последствия,

автоматизированных тестов. Решение: менторство,

информационно-вычислительных систем.

необходимо учитывать разные точки зрения, так как,

уроки из неудач. Пример: Внедрение новой

усугубляют ситуацию.Пример: спор между разработчиками

частота, участники; Построение причинно-

обязательные тренинги и сертификации.

Неоднозначное толкование участниками формирования

рассматривая части системы, можно упустить целое, а

технологии, стартап в неизученной нише. Методы

приводит к игнорированию бага.Решение: тренинги по

следственных связей; Применение SWOT-анализа,

Замкнутость (отсутствие коммуникации): Плохая

требований содержания разных документов из-за

при изучении целого — не принять во внимание его

для накомпления опыта: запуск упрощенной

эмоциональному интеллекту, медиаторы в команде.

диаграмм Исикавы, метода «5 почему». 3. Постановка

коммуникация в команде: если участники проекта не

неоднозначности многих терминов естественного

составные части. Принцип дополнительности означает,

версии продукта для быстрого получения обратной

Доминирование и недостаточная

цели управления Определение желаемого состояния

делятся информацией, могут возникать недопонимания

языка, на котором составлены документы.

что дефекты цифровой среды (например, ошибки в

связи, Экспериментальные методы: A/B-

бдительность:Лидеры навязывают решения, а команда

системы; Формулировка задач, направленных на

и дублирование ошибок. Отсутствие внешнего

программе или системе) нужно изучать с разных

тестирование – сравнение двух вариантов решений

некритически соглашается, снижая качество проверок.

устранение причины или минимизацию последствий. 4.

обзора: замкнутость на собственное мнение и отказ от

сторон, потому что они связаны и с техникой (код,

(например, интерфейсов). Пилотные проекты.

Это следствие авторитарного управления.Пример:

Разработка управленческого решения Генерация

обратной связи мешают выявлению логических и

алгоритмы), и с людьми (ошибки пользователей,

прогноз рисков на основе исторических данных.

менеджер ускоряет релиз, а команда не проверяет

альтернатив (вариантов решений); Оценка рисков,

архитектурных ошибок. Слабая связь с заказчиком:

разработчиков). Например, сбой в системе может быть

критические баги. Решение: распределенное лидерство,

затрат, ресурсов для каждой альтернативы; Выбор

приводит к искажённому восприятию требований и,

из-за бага в коде и из-за того, что пользователь

обязательные чек-листы перед релизом.

оптимального варианта. 5. Реализация управленческого

как следствие, ошибочной реализации. решение:

неправильно ею пользуется. Для решения надо

воздействия План действий, распределение

регулярные стендапы, парное программирование,

анализировать обе стороны вместе, а не по

ответственности; Внедрение корректирующих

культура открытости.

отдельности.

мероприятий; Управление сопротивлением

изменениям. 6. Мониторинг и корректировка Оценка

эффективности предпринятых мер; При необходимости

— корректировка решений; Фиксация опыта и

формирование базы знаний.

38 Классификация дефектов разработки

45 Основные факторы возникновения ошибок при

39 Модель роста типов дефектов

42 Основные стратегии действий в зависимости от

49 Типы требований. Их содержание ??

информационных моделей. Лимитирующие факторы

44 Ошибки в требованиях / спецификациях; Ошибки

разработке программных систем: Заблуждение;

Суть модели роста типов дефектов заключается в том,

уровня неопределенности проблемной ситуации:

Типы требований в разработке программных систем

дефектов цифровой модели и дефектов объекта

проектирования; Ошибки кодирования; Ошибки

Нарушение правил; Персональная позиция;

чтобы показать, как ошибки (дефекты), допущенные на

ошибки в действиях по правилам

делятся на категории в зависимости от их назначения,

моделирования

тестирования

Эмоциональная стабильность;

ранних стадиях жизненного цикла информационной

Здесь ситуация известна, правила существуют, но

уровня детализации и характера. Ниже — глубокий, но

По природе дефекта: Синтаксические: ошибки в

Ошибки в требованиях/спецификациях: Возникают

Заблуждение:Коренится в когнитивных искажениях

системы или ИТ-сервиса, не исчезают, а продолжают

человек или система либо неправильно их

краткий анализ с акцентом на суть и практическую

структуре или формате модели; Семантические:

из-за неструктурированного сбора требований или

(например, чрезмерная уверенность) или

«жить» и накапливаться, влияя на все последующие

применяет, либо применяет в неверном контексте.

значимость.

несоответствие содержания модели реальному объекту

когнитивных искажений заказчика/аналитика. Часто

недостаточном изучении контекта. Разработчик

стадии. Более того, они могут порождать новые, более

Ошибки происходят не из-за незнания, а из-за

Функциональные требования Описывают, что система

Прагматические: дефекты, связанные с неправильным

это результат слабого анализа домена или

переоценивает свои знания, игнорируя риски.Пример:

сложные дефекты, что существенно увеличивает риски,

некорректного использования инструкций или

должна делать — конкретные функции, действия или

использованием модели в контексте ее применения

игнорирования неявных ожиданий. Решение:

выбор неподходящей библиотеки из-за незнания ее

трудоёмкость устранения и стоимость исправления.

шаблонов.

поведение. Включают входные данные, обработку и

(например, модель не соответствует требованиям

использовать формализованные методы и итеративную

ограничений. Решение: обязательные технические

Основные идеи модели: 1. Дефекты накапливаются

Стратегия: Анализ причин нарушения правил или

выходные результаты. Особенности: Формулируются

пользователя). По источнику возникновения:

валидацию с заказчиком. Ошибки проектирования:

исследования (spikes) перед реализацией.

каскадно. Каждая стадия жизненного цикла использует

их неприменимости. Корректировка, адаптация или

четко, проверяемы (тестируемы), связаны с бизнес-логикой

Человеческий фактор: ошибки проектировщиков,

Связаны с недостаточной абстракцией или

Нарушение правил:

результаты предыдущей. Если на предыдущем этапе

уточнение существующих правил. Обучение

Проблемы: Неоднозначность или игнорирование краевых

аналитиков или разработчиков. Технологические:

игнорированием системных ограничений.

Происходит из-за слабой культуры DevOps или

была допущена ошибка (например, при формировании

правильному применению процедур. Контекстная

случаев.

ограничения инструментов моделирования.

Например, выбор неподходящей архитектуры из-за

давления сроков. Игнорирование стандартов

предложения или контракта), то на следующем она:

оценка: не все правила универсальны — может

Нефункциональные требования Определяют качества

Организационные: недостатки в управлении проектом.

недооценки будущих нагрузок. Решение: применять

увеличивает технический долг. Пример: пропуск

либо не обнаруживается и переносится дальше, либо

потребоваться разработка новых процедур.

системы или ограничения: производительность,

По стадии разработки: Концептуальные: ошибки на

архитектурные шаблоны (DDD, CQRS) и проводить

документирования кода приводит к проблемам при

искажает результат работы следующего этапа, либо

Методы: статистический контроль для

надежность, масштабируемость, безопасность, usability и

этапе анализа и проектирования. Реализационные:

нагрузочное моделирование. Ошибки кодирования:

онбординге новых сотрудников. Решение:

становится причиной новых дефектов, более глубоко

минимизации дефектов, роботы для рутинных

т.д. Особенности: Часто сложнее формализовать, требуют

дефекты, возникающие при реализации модели.

Проистекают из низкой дисциплины кодирования

автоматизация проверок (CI/CD) и строгие гайдлайны.

«вшитых» в систему. 2. Позднее обнаружение —

задач, автоматизация тестирования.

метрик (SMART). Критичны для пользовательского опыта

Эксплуатационные: проблемы, выявленные на этапе

или когнитивной перегрузки разработчика. Часто

Персональная позиция: Связана с эгоцентризмом

дорого и опасно Если дефект обнаружен уже на стадии

43 ошибки в профессиональных действиях

и инфраструктуры. Проблемы: Пропуск или завышенные

использования модели (например, несоответствие

связаны с отсутствием статического анализа или

или сопротивлением командной работе. Разработчик

эксплуатации: его исправление требует переработки

Здесь человек обладает знаниями и опытом,

ожидания без учета ресурсов.

модели изменяющимся условиям). По влиянию:

слабым код-ревью. Решение: внедрить линтеры, юнит-

может отвергать критику, что снижает качество.

всей цепочки решений, 3. Не все дефекты равнозначны

действует на основе профессиональной

Бизнес-требования Описывают высокоуровневые цели

Критические. Значительные. Незначительные.

тесты и парное программирование. Ошибки

Пример: отказ от рефакторинга, потому что "мой код

Модель показывает, что одни и те же дефекты могут

подготовки, но всё равно допускает ошибки.

бизнеса или заказчика, ради чего создается Особенности:

Дефекты информационной среды: 1) Дефекты

тестирования: Вызваны неадекватным покрытием

работает". Решение: внедрить анонимное код-ревью и

появляться на разных этапах, но их влияние и

Причина может быть в субъективности,

Задают контекст для функциональных и

цифровой модели (мир систем): Лимитирующий

сценариев или предвзятостью тестировщика.

культуру открытого фидбэка Эмоциональная

последствия будут разными 4. Нужна ранняя проверка

переоценке компетенций, узком профессиональном

нефункциональных требований. Формулируются

фактор: Ограниченные области применимости

Проблема усугубляется при ручном тестировании

стабильность:Стресс или выгорание снижают

и валидация Модель подчёркивает важность контроля

взгляде или устаревших подходах.

заказчиком или аналитиком. Проблемы: Размытость целей

формальных моделей, неполные, неточные данные,

сложных систем. Решение: использовать

когнитивные способности, что ведет к ошибкам.

качества на всех стадиях, особенно — на самых

Стратегия: Переоценка профессиональных методов

или несогласованность между стейкхолдерами.

недостаток знаний у разработчиков, временные и

автоматизацию тестирования (Selenium, JUnit) и

Эмоциональные всплески нарушают коммуникацию в

ранних: Нужно тщательно формулировать и проверять

и взглядов. Коллективный анализ ошибок,

Системные требования Описывают технические аспекты

бюджетные ограничения.

методики вроде TDD или exploratory testing.

команде. Пример: из-за усталости разработчик

требования, предложения, контракты. Следует

междисциплинарное взаимодействие. Повышение

системы, включая архитектуру, интерфейсы, протоколы,

2) Дефекты объекта управления (жизненный мир).

забывает проверить критическую часть кода. Решение:

использовать итерационные подходы (например, agile),

квалификации, дополнительное обучение.

интеграции. Часто делятся на требования к аппаратному и

Лимитирующий фактор: Ограниченная рациональность

ограничение переработок, психологическая поддержка,

позволяющие выявлять и устранять дефекты сразу

Использование независимых оценок, экспертных

программному обеспечению. Особенности: Важны для

субъектов управления, физические ограничения

тайм-менеджмент.

после их появления, а не в конце проекта. Вывод:

комиссий. Такая стратегия актуальна при работе с

разработчиков и архитекторов. Требуют глубокого

(свойство материала), производственные дефекты,

Модель роста типов дефектов — это метод системного

комплексными, междисциплинарными или новыми

понимания инфраструктуры. Проблемы: Игнорирование

недостатки проектирования, условия эксплуатации.

мышления, позволяющий понять, что: Дефекты не

вызовами, где требуется переосмысление

ограничений (например, старое оборудование) или

исчезают с течением времени, если их не устранять;

подходов. Методы: взаимный контроль

избыточная детализация на ранних этапах.

Каждый этап должен включать средства обнаружения и

кода(коллективные методы), анализ ошибок,

устранения ошибок предыдущих; Чем раньше устранён

управление вниманием.

дефект, тем дешевле и безопаснее это сделать; Важно

проектировать процесс с учётом этого накопления и

предусматривать контрольные точки на всём

жизненном цикле ИТ-сервиса.

1.Место информационной системы в управлении

23.Моделирование натурное и информационное

39.Модель роста типов дефектов

.

бизнес-процессами

24.Роли моделей: корпоративное знание; отображение

40.Содержание принципа дополнительности в

2.Эскалация цифровых и математических моделей

реального объекта; средство коммуникации

исследовании дефектов цифровой экосреды

3.Многоаспектность понятий «конвергенция»:

правообладателей

41.Основные стратегии действий в зависимости от

конвергенция сетей; конвергенция математических и

25.Классы моделей: вербальные; имитационные;

уровня неопределенности проблемной ситуации:

цифровых моделей; конвергенция точек зрения

структурные; математические. Соотношение понятий

накопление опыта (ошибки отсутствия знаний)

правообладателей

«эффективность» и «область адекватности»

42.Основные стратегии действий в зависимости от

4.Многоаспектность понятий «конвергенция»:

26.Классы знаковых моделей, используемых в

уровня неопределенности проблемной ситуации:

конвергенция математических и цифровых моделей

программой инженерии: модели состава; структурные

ошибки в дейстиях по правилам

5.Многоаспектность понятий «конвергенция»:

модели; функциональные модели; потоковые модели;

43.Основные стратегии действий в зависимости от

конвергенция точек зрения правообладателей

модели состояний

уровня неопределенности проблемной ситуации:

6.Понятие «Цифровой двойник технического объекта»

27.Определение задачи. Формы представления задач: в

ошибки в профессиональных действиях

7.Понятие «Цифровой двойник технического

пространстве состояний; Определение задачи. Формы

44.Ошибки в требованиях / спецификациях; Ошибки

предприятия»

представления задач: сводящие задачу к подзадачам

проектирования; Ошибки кодирования; Ошибки

8.Новый класс сложных систем: сети

28.Основные задачи системного моделирования:

тестирования

9.Понятие сетецентрического управления

Описательные информационные модели

45.Основные факторы возникновения ошибок при

10.Основные компоненты сетецентрического

29.Основные задачи системного моделирования:

разработке программных систем: Заблуждение;

управления: сенсоры; цифровая решетка;

Объяснительные модели

Нарушение правил; Персональная позиция;

исполнительные устройства

30.Основные задачи системного моделирования:

Эмоциональная стабильность;

11.Многослойность систем сетецентрического

Предсказательне модели

46.Основные факторы возникновения ошибок при

управления. Каскадные отказы во взаимосвязанных

31.Этапы построения математических моделей. Их

разработке программных систем: Небрежность /

сетях

содержание

невежество.; Замкнутость

12.Системная модель объекта моделирования. Классы

32.Технологии проверки математических моделей:

47.Основные факторы возникновения ошибок при

задач моделирования: дескриптивные модели (примеры)

Контроль размерностей; Контроль порядков; Контроль

разработке программных систем: Персональная

13.Системная модель объекта моделирования. Классы

экстремальных ситуаций ; Контроль граничных условий

позиция; Эмоциональная стабильность; Доминирование

задач моделирования: прогностические модели

(проверку того, что граничные условия действительно

и недостаточная бдительность субъектов

(примеры)