Étude de cas · Étude de cas

Focus HL soutenu. Première évaluation 2027 cible ; retours PDF officiels 403 ; le bref acquis plus ancien est l'évaluation finale 2026. Le guide restant, l'évaluation et les exigences pratiques conservent leurs retenues enregistrées.

Prérequis : lisez les quantités et unités indiquées, utilisez l'arithmétique et les conditions du modèle ci-dessous. Chaque leçon développe sa propre méthode avant un transfert autonome.

Ce sont des exemples pédagogiques originaux ou explicitement fictifs, pas des mesures réelles ni des enquêtes évaluées achevées par des apprenants.

Qu'est-ce qui expliquerait cette observation ?

• Un système de réservation scolaire proposé semble efficace, mais sa recommandation dépend des utilisateurs, des contraintes et des preuves. Un terme technique plausible seul ne constitue pas une décision justifiée.
• Commencez par une prédiction. Énoncez les quantités ou caractéristiques que vous compareriez, puis décidez quels éléments de preuve pourraient distinguer deux explications.

Construire le modèle

• Une étude de cas place les choix computationnels dans un scénario énoncé. Identifier les parties prenantes, les exigences, les preuves disponibles et les contraintes avant de recommander une architecture ou un algorithme. Distinguer un fait du scénario d'une hypothèse et d'une prédiction. Les compromis peuvent concerner la performance, la fiabilité, l'accessibilité, la confidentialité, la maintenance et le coût.
• débit : Travail accompli par unité de temps sous une charge de travail énoncée ; test d'acceptation : Test vérifiant si une exigence utilisateur spécifiée est satisfaite.

Choisir des preuves capables de le tester

• Une recommandation doit relier une exigence à un mécanisme et à un test observable. Par exemple, un problème de concurrence nécessite une stratégie empêchant les mises à jour conflictuelles, ainsi que des tests démontrant l'invariant. Une affirmation concernant une réponse plus rapide exige des mesures de charge de travail comparables plutôt qu'un simple label de complexité. Évaluer les alternatives dans les mêmes conditions énoncées.
• Utiliser un scénario approuvé par l'école et des données synthétiques. Construire une matrice de revendication, preuves du scénario supportant, explication technique, limitation et test d'acceptation. Marquer explicitement les faits manquants et montrer comment la recommandation changerait si une hypothèse échouait. Cela prépare le raisonnement basé sur des cas sans reproduire une étude de cas d'évaluation IB indisponible ni inventer son barème de correction d'examen.

Travailler à partir de quantités connues

• Énoncez les valeurs connues et leurs unités. Choisissez la relation dont les hypothèses s'adaptent à ce cas, puis réarrangez-la avant de substituer les valeurs.
• Données connues : un prototype fictif traite 120 demandes réussies durant une observation de 30 secondes. Le débit est 120/30=4 demandes/s. Un second prototype traite 150 en 30 secondes, soit 5/s. Le second présente 25% de débit enregistré supérieur, mais aucune conclusion concernant la latence, le taux de défaillance ou la performance sous une charge plus élevée ne peut être tirée sans ces mesures.

Exemple :

Un système fictif traite avec succès 210 requêtes en 30 s. Calculer le débit. Utiliser la même séquence : quantités connues → modèle → relation → substitution → unité et interprétation.

Vérifier la conclusion et ses limites

• Le débit n'est pas le temps de réponse. Une forte recommandation énonce les conditions dans lesquelles elle est censée fonctionner et les preuves qui pourraient l'infirmer. Les exigences officielles actuelles en matière d'études de cas en informatique doivent être vérifiées par rapport à la version d'évaluation applicable.
• Revenez à l'observation initiale. Expliquez ce que le résultat soutient, quelles conditions il suppose, et une manière de tester une explication concurrente.

Avertissement :

Un débit observé plus élevé prouve automatiquement un temps de réponse inférieur pour chaque requête. Cette affirmation est fausse : Le débit n'est pas le temps de réponse. Une forte recommandation énonce les conditions dans lesquelles elle est censée fonctionner et les preuves qui pourraient l'infirmer. Les exigences officielles actuelles en matière d'études de cas en informatique doivent être vérifiées par rapport à la version d'évaluation applicable.

Clé :

Analyse de cas en informatique : évaluer un système proposé : Une recommandation doit relier une exigence à un mécanisme et à un test observable. Par exemple, un problème de concurrence nécessite une stratégie empêchant les mises à jour conflictuelles, ainsi que des tests démontrant l'invariant. Une affirmation concernant une réponse plus rapide exige des mesures de charge de travail comparables plutôt qu'un simple label de complexité. Évaluer les alternatives dans les mêmes conditions énoncées.

Trace exécutable et limite

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)

Sortie attendue :

8.0 0.2
9.0 0.1

Le débit de succès et la fraction d'échec utilisent des dénominateurs différents. Un temps nul ou un nombre d'essais nul ne peut supporter ces taux. Ces résumés fictifs ne fournissent aucune preuve de latence, de coût ou de charge représentative.