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.
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.

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.
- Input
- Program and CPU
- Working RAM
- Saved file
- Output
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.


Qué es software y qué es hardware | Computación y programación
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.
- Consult System Information on the practice computer and create a Google Docs record of CPU, RAM, storage, motherboard or model and relevant peripherals.
- In diagrams.net, draw the pathway for opening, editing, saving and reopening a document; label the functions.
- Check two details against the technical documentation and mark anything you cannot yet confirm.
What observation distinguishes a visible document from a preserved document? Connect it with a component and an operation.
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.
- Indicator
- Unit and denominator
- Comparable task
- Limited interpretation
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.

How Computers Work: CPU, Memory, Input & Output
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.
- In Google Docs, record capacity, available space and one RAM indicator from the practice computer, including units and task.
- Consult the NIST prefix table and compare kB with KiB without changing the observed labels.
- Observe two prepared workload states and distinguish observation, possible limitation and missing information.
Why do high activity and high occupancy percentages not justify the same conclusion?
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.
- Need
- Model specification
- Compatibility
- Usefulness for the task
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.
- In Google Docs, connect one computer requirement with two specifications you would need to confirm.
- Consult the model’s official technical documentation provided in class and record the page or section supporting each condition.
- Compare an incompatible option with a compatible but unhelpful option; explain which information distinguishes them.
Which two different checks are needed before calling an upgrade suitable?
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.
- Symptom
- Alternative hypotheses
- Discriminating test
- Result
- Revision
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.
- In Google Docs, write two hypotheses for a prepared incident and one test that could distinguish them.
- Run the authorised reversible check and record expected result, observation and conditions.
- Revise or qualify a hypothesis and identify the next test; keep results that show no improvement too.
Which result could refute your hypothesis, and why is keeping it useful?
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.
- Observation
- Decision question
- Test branches
- Correction
- Original task
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.
- In diagrams.net, build the tree for cases A, B and C using observable questions and reversible tests.
- In Google Docs, record one run per case using the prepared computer or records; identify the evidence type.
- Ask another pair to follow a branch and check whether its final verification repeats the failing task.
Which question in your tree genuinely separates two hypotheses, and how does its answer change the test?
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.
- Power and hours
- Usage energy
- Other life stages
- Bounded comparison
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.
- In Google Docs, compare repair at 35 with replacement at 280 monetary units, including requirements, support, accessibility and missing data.
- Use the teacher’s provided power and hours to calculate usage energy; retain units and label assumed values.
- Add a reuse option and the authorised waste channel, explaining which information could change your decision.
What does your energy calculation include, and which stages remain outside its conclusion?
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.
- Need
- Recorded tests
- Provisional recommendation
- Peer review
- Verified improvement
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.
- In Google Docs, organise the report with inventory, three cases, the tree exported from diagrams.net, a revised hypothesis and comparison of options.
- Exchange part of the guide with another pair and record one difficulty and the resulting correction.
- Individually explain a decision and predict what would change for a different usage requirement; include this in A02.
Can another person distinguish what you observed, assumed and recommended in your report? Identify evidence of each kind.
Your project and submissions
A01 · Design the solution
- In Google Docs, define the problem, audience, requirements and functional inventory; cite the documentation used.
- In diagrams.net, draw the planned tree for three incidents and justify the order of reversible tests.
- Run and record an authorised small diagnosis and a check of a usage or accessibility requirement; distinguish hardware from simulation.
- 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
- Complete the inventory and run the three diagnoses in the prepared environment, recording expectation, observation and conclusion.
- Revise at least one hypothesis and repeat the original task after a correction.
- Justify keeping, repairing, upgrading, reusing or replacing; document compatibility, accessibility, fictional costs, energy and impact limits, and waste destination.
- 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
Make your own copy in Google Docs · View the blank template
- 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
Make your own copy in Google Docs · View the blank template
- 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.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Atribuye el fallo a la antigüedad sin analizar componentes ni realizar una prueba pertinente. |
| 3–4,9 | Nombra componentes, pero las pruebas no distinguen sus hipótesis o confunde ocupación y actividad. |
| 5–6,9 | Relaciona componentes y funciones, formula hipótesis y ejecuta una prueba reversible, registrando resultado y siguiente decisión. |
| 7–8,9 | Contrasta una hipótesis alternativa y reformula el procedimiento cuando la evidencia contradice la primera. |
| 9–10,0 | Justifica 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.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | Recomienda sustituir por novedad o usa una cifra de energía como impacto ambiental total. |
| 3–4,9 | Considera precio o consumo, pero omite accesibilidad, vida útil o supuestos de su comparación. |
| 5–6,9 | Analiza mantener, reparar o sustituir con accesibilidad, sostenibilidad e impacto y verifica una necesidad funcional con supuestos y unidades explícitos. |
| 7–8,9 | Compara alternativas y distingue consumo estimado de uso y efectos de fabricación no medidos. |
| 9–10,0 | Justifica 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.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | La solución no corresponde al síntoma y no hay evidencia de diagnóstico. |
| 3–4,9 | Ensaya cambios sin aislar causas o declara solucionado sin repetir la tarea. |
| 5–6,9 | Resuelve casos sencillos con pruebas, analiza componentes y reformula una hipótesis, comprobando la solución y justificando reparación responsable. |
| 7–8,9 | Distingue causa confirmada y provisional y compara otra solución con criterios de compatibilidad y coste. |
| 9–10,0 | Resuelve 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.
| Banda | Desempeño observable |
|---|---|
| 1–2,9 | La propuesta excluye necesidades de uso o afirma beneficios ambientales sin base identificable. |
| 3–4,9 | Incluye ahorro o reciclaje, pero no relaciona accesibilidad, utilidad y límites de las estimaciones. |
| 5–6,9 | Justifica reparación o renovación considerando accesibilidad, sostenibilidad e impacto, separa medidas y estimaciones y concreta destino responsable de residuos. |
| 7–8,9 | Contrasta otra alternativa y revisa su recomendación ante un dato de soporte o uso distinto. |
| 9–10,0 | Evalú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
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
- Microsoft Support: Todo acerca de la memoria del equipo
- NIST: Prefixes for binary multiples
- Canonical: Ubuntu Desktop documentation
- European Environment Agency: Circular economy
Editorial revision: October 2026.
