Кейс-стади · Кейс-стади

Поддерживаемая фокусная точка HL. Первая оценка 2027 целевой показатель; официальный PDF возвращает 403; ранее приобретенный краткий план является финальной оценкой 2026. Оставшиеся руководство, оценка и практические требования сохраняют свои зарегистрированные удержания.

Предварительные требования: прочитайте указанные количества и единицы измерения, используйте арифметику и нижеприведённые условия модели. Каждый урок осваивает собственный метод перед независимым переносом.

Это оригинальные или явно вымышленные учебные примеры, а не фактические измерения или завершённые оценочные исследования учащихся.

Что могло бы объяснить это наблюдение?

• Предложенная система бронирования в школе выглядит эффективной, но ее рекомендация зависит от пользователей, ограничений и доказательств. Одного правдоподобного технического термина недостаточно для обоснованного решения.
• Начните с гипотезы. Укажите величины или признаки, которые вы будете сравнивать, затем определите, какие доказательства могут различить два объяснения.

Постройте модель

• Случайный анализ помещает вычислительные выборы в описанный сценарий. Определите заинтересованные стороны, требования, доступные доказательства и ограничения перед тем, как рекомендовать архитектуру или алгоритм. Различайте факт сценария, предположение и прогноз. Компромиссы могут касаться производительности, надежности, доступности, конфиденциальности, обслуживания и стоимости.
• пропускная способность: Выполненная работа за единицу времени при указанной нагрузке; тест принятия: Тест на соответствие заданному пользовательскому требованию.

Выберите доказательства для проверки гипотезы

• Рекомендация должна связывать требование с механизмом и наблюдаемым тестом. Например, проблема конкурентного доступа требует стратегии предотвращения конфликтующих обновлений, а также тестов, демонстрирующих инвариант. Утверждение о более быстром отклике требует сопоставимых измерений нагрузки, а не только метки сложности. Оценивайте альтернативы в одних и тех же заявленных условиях.
• Используйте оригинальный сценарий, утвержденный школой, и синтетические данные. Составьте матрицу утверждения, подтверждающих доказательств из сценария, технического объяснения, ограничений и теста принятия. Явно отметьте отсутствующие факты и покажите, как изменится рекомендация, если предположение окажется неверным. Это готовит к рассуждению на основе кейсов без воспроизведения недоступного для IB оценочного кейса или изобретения его критериев экзамена.

Работайте с известными величинами

• Укажите известные значения и их единицы измерения. Выберите соотношение, предположения которого подходят к данному случаю, затем преобразуйте формулу перед подстановкой.
• Известно: вымышленный прототип обрабатывает 120 успешных запросов за 30-секундное наблюдение. Пропускная способность составляет 120/30=4 успешных запросов/с. Второй прототип обрабатывает 150 за 30 секунд, или 5/с. У второго прототипа пропускная способность выше на 25%, но без этих измерений нельзя сделать вывод о задержке, частоте отказов или производительности под большей нагрузкой.

Пример:

Вымышленная система успешно обрабатывает 210 запросов за 30 с. Рассчитайте пропускную способность. Используйте ту же последовательность: известные величины → модель → соотношение → подстановка → единицы и интерпретация.

Проверьте вывод и его границы применимости

• Пропускная способность — это не время отклика. Сильная рекомендация указывает условия, при которых она должна работать, и доказательства, которые могли бы опровергнуть её. Текущие официальные требования к кейсам по информатике необходимо проверять на соответствие применимой версии оценки.
• Вернитесь к первоначальному наблюдению. Объясните, что подтверждает результат, при каких условиях он верен и каким образом можно проверить конкурирующее объяснение.

Предупреждение:

Более высокая наблюдаемая пропускная способность автоматически доказывает меньшее время отклика для каждого запроса. Это утверждение ложно: пропускная способность — это не время отклика. Сильная рекомендация указывает условия, при которых она должна работать, и доказательства, которые могли бы опровергнуть её. Текущие официальные требования к кейсам по информатике необходимо проверять на соответствие применимой версии оценки.

Ключевые моменты:

Компьютерный случайной анализ: оценка предлагаемой системы: Рекомендация должна связывать требование с механизмом и наблюдаемым тестом. Например, проблема конкурентного доступа требует стратегии предотвращения конфликтующих обновлений, а также тестов, демонстрирующих инвариант. Утверждение о более быстром отклике требует сопоставимых измерений нагрузки, а не только метки сложности. Оценивайте альтернативы в одних и тех же заявленных условиях.

Работоспособная трассировка и границы

for successful, attempted, seconds in [(240, 300, 30), (270, 300, 30)]:
    if seconds <= 0 or attempted <= 0:
        raise ValueError("Positive exposure required")
    throughput = successful / seconds
    failure_fraction = (attempted - successful) / attempted
    print(throughput, failure_fraction)

Ожидаемый вывод:

8.0 0.2
9.0 0.1

Процент успешных транзакций и доля ошибок используют разные знаменатели. Нулевое время или нулевое количество попыток не могут поддерживать такие показатели. Эти вымышленные сводки не предоставляют доказательств задержек, стоимости или репрезентативной нагрузки.