DIG4-S01 · El ordenador por dentro · Learn

Back to your course / DIG4-S01

Digitalisation · 4.º ESO · Learn

Inside the computer

A computer brings together components that cooperate to perform tasks. You will connect their functions with observations, distinguish a symptom from a cause and compare improvements using data and explicit limits.

14 planned lessonsDIG4-S01
Understand the idea. Design, test and explain your solution.

Your mission

In pairs, prepare a computer diagnosis and improvement proposal: functional inventory, compatibility, a three-incident decision tree and before/after tests. Compare repair, reuse and replacement using the classroom assumptions. A01 contains the design and an executed small diagnosis; A02 contains the three cases, a revised hypothesis and the recommendation. Practice work prepares these two submissions.

Original illustration of students planning and testing a computing project.
Ilustración original de apoyo visual · Sintaxis Divergente, 2026.

Read the explanation, study the diagram and try the activity in each section. You can choose another version at any time.

Your tools

Use Google Docs for written explanations and diagrams.net for diagrams. Save the editable file as well as the evidence requested in each task.

1.1. The computer as a system of components

Learn · theory and practice

A computer is a system because its components work together to transform inputs into results. This cooperation brings together hardware, the physical parts, and software, the instructions and data organised to perform tasks. The CPU executes instructions, and RAM holds the working information that programs need. Storage preserves files when the power is off. The motherboard enables components to communicate through interfaces, while the power supply provides suitable energy. Peripherals, such as a keyboard and display, make it possible to enter information or receive results.

These functions become clearer when we follow a task. Editing a poster involves the program, CPU, RAM and display; preserving the changes also involves the save operation and its storage destination. Seeing the poster therefore establishes that there is visible output, but not that the file has been saved. If the application is remote, the pathway also includes network dependencies. A single task needs several functions, and observing one does not automatically verify the others.

A functional inventory connects this pathway with a particular computer: it identifies the model, function and intended task. A specification therefore gains meaning through what it enables and how it relates to the whole system. System information and the authorised computer’s technical documentation allow details to be checked without collecting serial numbers or taking parts apart to discover information that is already available to consult.

  1. Input
  2. Program and CPU
  3. Working RAM
  4. Saved file
  5. Output
Original diagram · Sintaxis Divergente

A worked example

In a school library, a record looks correct but reopens without the changes. The display showed the work; that says nothing about its preservation. Following the pathway suggests checking the file, its destination and the save operation before blaming the monitor. The example connects function and observation without yet confirming a cause.

Computer motherboard with sockets, connectors and electronic circuits.
La placa base conecta varios componentes de un ordenador; la distribución depende del modelo. Foto de Saipul bakrie / Wikimedia Commons, CC BY-SA 4.0; versión a menor tamaño.
Computer motherboard with sockets, connectors and electronic circuits.
Ranuras para módulos de memoria: no todos los modelos ni generaciones son compatibles. Foto de Project Kei / Wikimedia Commons, CC BY-SA 4.0; versión a menor tamaño.

Qué es software y qué es hardware | Computación y programación

Published by: LearnFree en Español · Open on YouTube

Watch in short sections. Connect one explanation with the diagram and try the example in this section. The written theory lets you complete the activity without playing the video.

The video keeps its original spoken language. Use the captions available in the player if they help.

Your turn

  1. Consult System Information on the practice computer and create a Google Docs record of CPU, RAM, storage, motherboard or model and relevant peripherals.
  2. In diagrams.net, draw the pathway for opening, editing, saving and reopening a document; label the functions.
  3. Check two details against the technical documentation and mark anything you cannot yet confirm.
Pause and check

What observation distinguishes a visible document from a preserved document? Connect it with a component and an operation.

↑ Back to the index

1.2. Memory, storage and units

Learn · theory and practice

RAM and storage can express capacity in bytes, although they serve different functions. Ordinary RAM is volatile working memory: its contents are lost when the power is off. Storage preserves files, so having free space does not mean having enough memory for the current task. A bit is a binary unit, and a byte contains eight bits. Decimal multiples use powers of one thousand: 1 kB equals 1000 bytes. Binary multiples use powers of 1024: 1 KiB equals 1024 bytes. The label tells us which quantity the number represents.

Besides the unit, what is being measured matters. Capacity expresses how much can fit, and occupancy expresses how much space is used relative to the total. Activity describes work over an interval. An occupancy percentage and an activity percentage may therefore match without describing the same situation. Transfer speed relates information to time, as in MB/s. An isolated RAM percentage is insufficient too: it needs the task and time of observation.

Interpreting indicators means connecting them with working conditions. Comparing several resources during an equivalent task helps identify possible limitations without immediately attributing them to a fault. The record preserves the indicator’s name, unit, denominator where applicable, task and time. This separates observation from provisional explanation while retaining tools’ original labels when comparing capacities.

RAMStorageData in current useFiles retainedNeeds powerRetains without power
Working memory and persistent storage serve different purposes.
  1. Indicator
  2. Unit and denominator
  3. Comparable task
  4. Limited interpretation
Original diagram · Sintaxis Divergente

A worked example

One tool shows occupied disk space and another shows disk activity during an export. Both report 90%, but their denominators differ: total capacity and activity over the interval. They cannot be exchanged in the report. Recording the indicator’s name, unit, task and time supports relevant questions; writing only “disk at 90%” loses the information that distinguishes the situations.

A DDR4 RAM module used as the computer’s working memory.
RAM: memoria de trabajo. Fotografía de ElooKoN / Wikimedia Commons, CC BY-SA 4.0; versión a menor tamaño.

How Computers Work: CPU, Memory, Input & Output

Published by: CodeAI · Open on YouTube

Watch in short sections. Connect one explanation with the diagram and try the example in this section. The written theory lets you complete the activity without playing the video.

The video keeps its original spoken language. Use the captions available in the player if they help.

Your turn

  1. In Google Docs, record capacity, available space and one RAM indicator from the practice computer, including units and task.
  2. Consult the NIST prefix table and compare kB with KiB without changing the observed labels.
  3. Observe two prepared workload states and distinguish observation, possible limitation and missing information.
Pause and check

Why do high activity and high occupancy percentages not justify the same conclusion?

↑ Back to the index

1.3. Compatibility before buying or replacing

Learn · theory and practice

Compatibility brings together the conditions that allow components and software to work together. Having the same function or an apparently matching connector is insufficient. For memory, check generation, form factor, supported capacity and configuration. For storage, interface, dimensions and system support matter. Physical, electrical and logical compatibility must be checked against the specific model’s documentation, rather than a photograph of a similar computer.

A compatible improvement must also address the observed need. A bottleneck is a resource that limits a task under particular conditions; it can change when the workload changes. Adding capacity to a resource that does not limit the task may achieve little. Connect requirement, specification and evidence before comparing options. The classroom cost assumption supports reasoning, but is not a market price. A recommendation includes outstanding questions and conditions that would invalidate it, allowing someone else to review its usefulness before an intervention.

  1. Need
  2. Model specification
  3. Compatibility
  4. Usefulness for the task
Original diagram · Sintaxis Divergente

A worked example

A computer needs to connect a projector for an accessible presentation. One proposal offers more storage, although capacity is sufficient and the difficulty concerns video output. The part might be compatible but does not address that requirement. Choosing an adapter would also require checking ports, supported signal and documentation. Usefulness and compatibility are different questions that must be answered together.

Your turn

  1. In Google Docs, connect one computer requirement with two specifications you would need to confirm.
  2. Consult the model’s official technical documentation provided in class and record the page or section supporting each condition.
  3. Compare an incompatible option with a compatible but unhelpful option; explain which information distinguishes them.
Pause and check

Which two different checks are needed before calling an upgrade suitable?

↑ Back to the index

1.4. Symptom, hypothesis, test and conclusion

Learn · theory and practice

A symptom is what you observe: a task takes time, a file is missing or there is no image. A hypothesis proposes a provisional cause that can be tested. The test should produce different observations depending on whether it is correct. Before running it, write what you expect and which result would make you revise the explanation. This avoids selecting only favourable information afterwards.

Start with reversible, low-impact checks suited to the symptom. Keep the task comparable and change one condition at a time when possible. Record environment, action, result and next decision. Improvement after a change supports a relationship, but does not automatically identify a defective part: alternative explanations may exist. If the symptom cannot be reproduced, preserve the test conditions. The aim is to reduce uncertainty and verify the final task, rather than guess a component immediately or make a chain of changes that hides which one mattered.

  1. Symptom
  2. Alternative hypotheses
  3. Discriminating test
  4. Result
  5. Revision
Original diagram · Sintaxis Divergente

A worked example

A file opens slowly from a shared location. The provisional hypothesis concerns remote access. The test compares a local practice copy with the same remote file, keeping application and computer unchanged. A difference would point towards that pathway but would not yet distinguish network from server. The record must retain that uncertainty and propose another check, rather than declare the disk faulty.

Your turn

  1. In Google Docs, write two hypotheses for a prepared incident and one test that could distinguish them.
  2. Run the authorised reversible check and record expected result, observation and conditions.
  3. Revise or qualify a hypothesis and identify the next test; keep results that show no improvement too.
Pause and check

Which result could refute your hypothesis, and why is keeping it useful?

↑ Back to the index

1.5. Three incidents and a diagnostic tree

Learn · theory and practice

A diagnostic tree represents decisions that depend on observations. Each question should separate pathways and lead to a check, rather than an automatic purchase. “It does not work” needs precision: no visible power, power but no image, or an image with a failing task. These situations do not support the same cause. External connections and recent context may provide information before an internal intervention.

The laboratory retains three cases: slowness with many tabs, failure to save to a full destination and no image after moving the computer. For each, connect symptom, possible causes and an authorised test; then verify the original operation. Label fictional records separately from real observations. Internal inspection is limited to the prepared computer, disconnected where appropriate and under supervision. Do not open the power supply or measure mains electricity. Documenting this scope allows the reasoning to be repeated without causing faults.

  1. Observation
  2. Decision question
  3. Test branches
  4. Correction
  5. Original task
Original diagram · Sintaxis Divergente

A worked example

A tree for a peripheral starts by asking whether the system recognises it. If it does but one application does not offer it, the next pathway examines that application; if it is absent from the system, the authorised connection and documentation are checked. The question changes the next test. A branch that always ends with “buy another” neither distinguishes causes nor checks recovery.

Your turn

  1. In diagrams.net, build the tree for cases A, B and C using observable questions and reversible tests.
  2. In Google Docs, record one run per case using the prepared computer or records; identify the evidence type.
  3. Ask another pair to follow a branch and check whether its final verification repeats the failing task.
Pause and check

Which question in your tree genuinely separates two hypotheses, and how does its answer change the test?

↑ Back to the index

1.6. Repair, reuse and life cycle

Learn · theory and practice

The life cycle includes obtaining materials, manufacturing, transport, use, maintenance and end-of-life management. Energy during use is only part of the impact. Power expresses the rate of consumption and is measured in W; energy accumulated over time can be expressed in Wh or kWh. For constant assumed power, energy equals power multiplied by time. A maximum power label is not a measurement of actual consumption during a task.

Compare keeping, repairing, upgrading, repurposing and replacing according to need, compatibility, support, accessibility and destination. Extending use requires continued suitability and maintainability. The classroom amounts of 35 and 280 monetary units are fictional repair and replacement comparison data, not commercial quotations. Also state which consumption values are assumptions. Without manufacturing and other life-stage data, usage savings cannot establish a total footprint. When a computer reaches end of life, identify the authorised electronic-waste management channel.

  1. Power and hours
  2. Usage energy
  3. Other life stages
  4. Bounded comparison
Original diagram · Sintaxis Divergente

A worked example

A record compares two computers over the same period of use. Its energy calculation can use only the power and hours declared in the scenario, with consistent units. Even if one needs less energy during that period, manufacturing, repair and lifetime data are missing. The recommendation can consider that partial saving without presenting it as proof of a smaller total environmental impact.

Your turn

  1. In Google Docs, compare repair at 35 with replacement at 280 monetary units, including requirements, support, accessibility and missing data.
  2. Use the teacher’s provided power and hours to calculate usage energy; retain units and label assumed values.
  3. Add a reuse option and the authorised waste channel, explaining which information could change your decision.
Pause and check

What does your energy calculation include, and which stages remain outside its conclusion?

↑ Back to the index

1.7. A reviewable proposal and documented laboratory

Learn · theory and practice

A technical report lets readers reconstruct the relationship between need, evidence and recommendation. Separate observations, inferences and proposals: recording a number is neither interpreting its cause nor deciding a purchase. The inventory, tree and tests should share names and conditions so another person can follow the pathway. A provisional conclusion is valid when it explains what is known, what is missing and which evidence would require a change.

The laboratory integrates the three cases and a revised hypothesis; it creates no third submission. A01 contains design, testable requirements and an already executed small diagnosis. A02 preserves the editable product, before/after tests, correction and a verified improvement. Another pair uses part of the guide and records where help is needed. This review checks communication and procedure as well as appearance. Each member explains a decision and predicts a result for a variation of the case. Screenshots support the record but replace neither running the test nor preserving reviewable files.

  1. Need
  2. Recorded tests
  3. Provisional recommendation
  4. Peer review
  5. Verified improvement
Original diagram · Sintaxis Divergente

A worked example

A report says “an upgrade is advisable” without naming the task. Its revision adds the requirement, workload observation, compatibility documentation and a condition for change: if another test shows that the remote service was the limitation, the proposal must be reconsidered. This structure does not predetermine the solution; it exposes the reasoning and lets another pair check whether the recommendation remains supported.

Your turn

  1. In Google Docs, organise the report with inventory, three cases, the tree exported from diagrams.net, a revised hypothesis and comparison of options.
  2. Exchange part of the guide with another pair and record one difficulty and the resulting correction.
  3. Individually explain a decision and predict what would change for a different usage requirement; include this in A02.
Pause and check

Can another person distinguish what you observed, assumed and recommended in your report? Identify evidence of each kind.

↑ Back to the index

Your project and submissions

A01 · Design the solution

  1. In Google Docs, define the problem, audience, requirements and functional inventory; cite the documentation used.
  2. In diagrams.net, draw the planned tree for three incidents and justify the order of reversible tests.
  3. Run and record an authorised small diagnosis and a check of a usage or accessibility requirement; distinguish hardware from simulation.
  4. Compare options by compatibility, assumed cost, support and impact; include sources, permissions and individual contributions.

What to submit

  • Editable dossier with functional record, hypotheses, tree and an executed test including result and next decision.
  • Options matrix covering accessibility, compatibility, cost and impact; data and units labelled as observed or assumed.
  • Individual explanation and sources that make the proposal reviewable; practice work belongs to this same submission.

A02 · Computer diagnosis and improvement proposal

  1. Complete the inventory and run the three diagnoses in the prepared environment, recording expectation, observation and conclusion.
  2. Revise at least one hypothesis and repeat the original task after a correction.
  3. Justify keeping, repairing, upgrading, reusing or replacing; document compatibility, accessibility, fictional costs, energy and impact limits, and waste destination.
  4. Test the guide with another pair, incorporate a verified improvement and collect editables, instructions, sources and each member’s explanation.

What to submit

  • Three before/after records with test conditions and tests that distinguish hypotheses.
  • A reformulated hypothesis and verification of the solution in the original task.
  • A reviewable recommendation comparing options, with declared data or estimates and responsible waste management.
  • DIG4-S01 folder with editable product, tree, guide, received review and improvement; each member explains a decision and predicts a variation.

Before you submit

  • I connect functions with components without confusing RAM and storage.
  • I preserve units and distinguish occupancy, activity, power and energy.
  • I choose reversible tests that allow a hypothesis to be revised and the final task repeated.
  • I defend an option using compatibility, accessibility, lifetime and data limits; these are student self-assessment descriptors, not a new statutory rubric.

Templates and files

Open the blank A01 or A02 template and make your own copy in Google Docs. Keep the editable file from your project platform as well.

These reusable templates help you organise your work. Follow the specific instructions and evidence list for this unit; remove fields that do not apply. The blank master is read-only. Keep your answers private and share them only as your teacher instructs.

A01 · Design the solution

  • Editable dossier with functional record, hypotheses, tree and an executed test including result and next decision.
  • Options matrix covering accessibility, compatibility, cost and impact; data and units labelled as observed or assumed.
  • Individual explanation and sources that make the proposal reviewable; practice work belongs to this same submission.

A02 · Computer diagnosis and improvement proposal

  • Three before/after records with test conditions and tests that distinguish hypotheses.
  • A reformulated hypothesis and verification of the solution in the original task.
  • A reviewable recommendation comparing options, with declared data or estimates and responsible waste management.
  • DIG4-S01 folder with editable product, tree, guide, received review and improvement; each member explains a decision and predicts a variation.

Classroom rubrics

The classroom assessment reference is preserved below in its original Spanish. Use the checklist above to prepare your work and ask your teacher about any descriptor you need to clarify.

Consultar la rúbrica de A01

Diseño y microprueba

DIG.4.1.3 Diagnóstico técnico por hipótesis y pruebas

Identificar y resolver problemas técnicos sencillos, analizando componentes y funciones de los dispositivos digitales, evaluando las soluciones de manera crítica y reformulando el procedimiento, en caso necesario, fomentando un consumo y reposición de los sistemas digitales y/o tecnológicos de manera sostenible y responsable.

Evidencia. Ficha funcional, hipótesis y microdiagnóstico ejecutado en entorno preparado.

BandaDesempeño observable
1–2,9Atribuye el fallo a la antigüedad sin analizar componentes ni realizar una prueba pertinente.
3–4,9Nombra componentes, pero las pruebas no distinguen sus hipótesis o confunde ocupación y actividad.
5–6,9Relaciona componentes y funciones, formula hipótesis y ejecuta una prueba reversible, registrando resultado y siguiente decisión.
7–8,9Contrasta una hipótesis alternativa y reformula el procedimiento cuando la evidencia contradice la primera.
9–10,0Justifica el orden de pruebas por capacidad de discriminar causas, coste y reversibilidad y anticipa un caso nuevo.

DIG.4.4.4 Accesibilidad, vida útil y decisión ecosocial

Analizar la necesidad y los beneficios globales de un uso y desarrollo ecosocialmente responsable de las tecnologías digitales, teniendo en cuenta criterios de accesibilidad, sostenibilidad e impacto.

Evidencia. Matriz de decisión con accesibilidad coste impacto y microcomprobación de una necesidad.

BandaDesempeño observable
1–2,9Recomienda sustituir por novedad o usa una cifra de energía como impacto ambiental total.
3–4,9Considera precio o consumo, pero omite accesibilidad, vida útil o supuestos de su comparación.
5–6,9Analiza mantener, reparar o sustituir con accesibilidad, sostenibilidad e impacto y verifica una necesidad funcional con supuestos y unidades explícitos.
7–8,9Compara alternativas y distingue consumo estimado de uso y efectos de fabricación no medidos.
9–10,0Justifica una recomendación revisable para otro usuario considerando barreras, soporte y escenario de uso.
Consultar la rúbrica de A02

Producto pruebas y mejora

DIG.4.1.3 Diagnóstico técnico por hipótesis y pruebas

Identificar y resolver problemas técnicos sencillos, analizando componentes y funciones de los dispositivos digitales, evaluando las soluciones de manera crítica y reformulando el procedimiento, en caso necesario, fomentando un consumo y reposición de los sistemas digitales y/o tecnológicos de manera sostenible y responsable.

Evidencia. Tres casos de diagnóstico con antes después, solución y revisión de una hipótesis.

BandaDesempeño observable
1–2,9La solución no corresponde al síntoma y no hay evidencia de diagnóstico.
3–4,9Ensaya cambios sin aislar causas o declara solucionado sin repetir la tarea.
5–6,9Resuelve casos sencillos con pruebas, analiza componentes y reformula una hipótesis, comprobando la solución y justificando reparación responsable.
7–8,9Distingue causa confirmada y provisional y compara otra solución con criterios de compatibilidad y coste.
9–10,0Resuelve un caso nuevo con procedimiento razonado y evalúa críticamente cuándo conservar, reparar o sustituir según evidencias.

DIG.4.4.4 Accesibilidad, vida útil y decisión ecosocial

Analizar la necesidad y los beneficios globales de un uso y desarrollo ecosocialmente responsable de las tecnologías digitales, teniendo en cuenta criterios de accesibilidad, sostenibilidad e impacto.

Evidencia. Recomendación de mejora, datos o estimaciones declarados y destino de residuos.

BandaDesempeño observable
1–2,9La propuesta excluye necesidades de uso o afirma beneficios ambientales sin base identificable.
3–4,9Incluye ahorro o reciclaje, pero no relaciona accesibilidad, utilidad y límites de las estimaciones.
5–6,9Justifica reparación o renovación considerando accesibilidad, sostenibilidad e impacto, separa medidas y estimaciones y concreta destino responsable de residuos.
7–8,9Contrasta otra alternativa y revisa su recomendación ante un dato de soporte o uso distinto.
9–10,0Evalúa el escenario de comparación y explica qué evidencia adicional haría cambiar la decisión, sin equivalencias ambientales inventadas.

Videos, resources and sources

How Computers Work: Hardware and Software

Published by: CodeAI · Open on YouTube

Watch in short sections. Connect one explanation with the diagram and try the example in this section. The written theory lets you complete the activity without playing the video.

The video keeps its original spoken language. Use the captions available in the player if they help.

Keep learning

Editorial revision: October 2026.