02. Tipos, licencias y selección de software

Abrir las diapositivas de apoyo: Tipos, licencias y selección de software (pantalla completa)

En el bloque anterior vimos los servicios y la arquitectura del SO. Su evolución ayuda a entender por qué existen sistemas con prioridades distintas; sus licencias y requisitos permiten elegir una solución para cada entorno.

2.1. Evolución de los sistemas operativos

Los sistemas operativos no aparecieron de golpe. Respondieron a problemas concretos de cada época: aprovechar equipos muy caros, permitir varios trabajos, facilitar el uso personal y conectar dispositivos muy distintos.

Etapa	Necesidad principal	Aportación
Equipos sin SO	Ejecutar un único programa preparado manualmente.	La persona programadora controlaba directamente el hardware.
Procesamiento por lotes	Reducir tiempos muertos entre trabajos.	Los trabajos se agrupaban y ejecutaban uno tras otro.
Multiprogramación	Mantener la CPU ocupada mientras un programa esperaba E/S.	Varios programas podían residir en memoria y alternarse.
Tiempo compartido	Dar respuesta a varias personas usuarias.	Reparto rápido de CPU y terminales interactivos.
Sistemas personales e interfaz gráfica	Hacer el ordenador accesible a público no especializado.	Escritorio, ventanas, ratón y aplicaciones de propósito general.
Redes, móviles y nube	Conectar equipos, servicios y dispositivos variados.	Administración remota, movilidad, virtualización y servicios distribuidos.

En los primeros ordenadores, preparar una ejecución podía exigir cablear paneles o cargar manualmente soportes físicos. El tiempo de la CPU era valioso y no debía quedar inactivo mientras se cambiaba de programa. Los sistemas por lotes automatizaron parte de esa secuencia.

La multiprogramación introdujo una idea fundamental para esta unidad: si un proceso espera la lectura de un disco o la llegada de datos, la CPU puede atender a otro. Esto hace necesario saber qué procesos existen, en qué estado están y cuál debe ejecutarse. La planificación de CPU nace precisamente de ese problema.

Unix consolidó una arquitectura multitarea y multiusuario que influyó en muchos sistemas posteriores. GNU aportó numerosas herramientas y utilidades libres; el kernel Linux es el núcleo que, combinado habitualmente con componentes GNU y otros proyectos, forma distribuciones GNU/Linux. En paralelo, los sistemas personales popularizaron las interfaces gráficas y los sistemas móviles adaptaron el SO a pantallas táctiles, sensores y consumo energético limitado.

Vídeo de apoyo: historia y evolución de los sistemas operativos. Relaciona las etapas que aparecen en el vídeo con la necesidad que resuelve cada una en la tabla anterior.

La historia explica por qué hoy hay sistemas operativos tan distintos. El siguiente paso es clasificarlos según cómo administran los recursos y para qué contexto se han diseñado.

2.2. Clasificación de los sistemas operativos

Un mismo sistema operativo puede pertenecer a varias categorías. Por ejemplo, un servidor GNU/Linux puede ser multitarea, multiusuario, multiprocesador y orientado a red al mismo tiempo.

2.2.1. Según el número de tareas

Monotarea: ejecuta una tarea principal cada vez. Su diseño puede ser sencillo y predecible, pero limita la interacción.
Multitarea: mantiene varios procesos y alterna la CPU entre ellos. En un equipo actual, navegador, editor, antivirus y servicios pueden ejecutarse de forma concurrente.

La multitarea no significa que todos los programas se ejecuten literalmente a la vez en un único núcleo. El sistema alterna tan rápido entre ellos que la persona usuaria percibe simultaneidad.

2.2.2. Según el número de personas usuarias

Monousuario: diseñado principalmente para una persona usuaria activa en un momento dado.
Multiusuario: permite cuentas separadas, sesiones y recursos compartidos con aislamiento y permisos.

Un equipo personal puede tener varias cuentas locales, pero un sistema multiusuario adquiere especial importancia cuando varias personas acceden simultáneamente a un servidor.

2.2.3. Según los procesadores o núcleos

Monoprocesador: diseñado para trabajar con una CPU o un núcleo de ejecución.
Multiprocesador: aprovecha varios procesadores o núcleos para ejecutar tareas en paralelo.

La planificación de procesos sigue siendo necesaria en ambos casos. Con varios núcleos, el sistema debe decidir además qué proceso asignar a cada núcleo y equilibrar la carga.

2.2.4. Según la respuesta temporal

Sistemas de propósito general: buscan buen rendimiento y buena experiencia global, sin garantizar un plazo exacto para cada tarea.
Sistemas de tiempo real: deben responder dentro de un límite temporal definido. Se usan, por ejemplo, en control industrial, automoción o dispositivos médicos.

2.2.5. Según el ámbito de uso

Ámbito	Prioridades habituales	Ejemplos de familias
Escritorio	Interfaz gráfica, periféricos, ofimática, aplicaciones de usuario.	Windows, macOS, distribuciones GNU/Linux.
Servidor	Estabilidad, red, servicios, administración remota y seguridad.	GNU/Linux, Windows Server, BSD.
Móvil	Batería, sensores, conectividad móvil y tienda de aplicaciones.	Android, iOS.
Embebido	Tamaño reducido, consumo y función específica.	Linux embebido, FreeRTOS, sistemas propietarios.
Tiempo real	Respuesta determinista ante eventos.	QNX, VxWorks, variantes especializadas.

Esta clasificación permite pasar de una pregunta genérica, “¿qué sistema es mejor?”, a una pregunta profesional: “¿qué sistema responde mejor a estos requisitos?”.

2.3. Aplicaciones, requisitos y licencias

Una vez que el sistema operativo ofrece servicios, pueden instalarse aplicaciones para necesidades concretas. Elegir software exige valorar su finalidad, sus requisitos y las condiciones legales de uso.

2.3.1. Software según su propósito

Tipo	Finalidad	Ejemplos
Software de base	Hacer utilizable el hardware y ofrecer servicios comunes.	SO, drivers, utilidades de diagnóstico.
Software de aplicación	Resolver una tarea de usuario o de empresa.	Ofimática, diseño asistido por ordenador (CAD), navegador, gestión de recursos empresariales (ERP), editor de vídeo.
Software de desarrollo	Crear, probar y mantener software.	Entorno integrado de desarrollo (IDE), compilador, intérprete, depurador, control de versiones.

Una misma herramienta puede cubrir más de una necesidad. Por ejemplo, un IDE es software de desarrollo por su propósito, pero también es una aplicación que utiliza servicios del SO. La separación base/aplicación del bloque 01 describe su papel respecto al sistema; aquí destacamos qué tarea resuelve. Por eso clasificar un IDE como aplicación y precisar que se utiliza para desarrollo es compatible, siempre que expliques el eje utilizado.

2.3.2. Requisitos y compatibilidad

Que un programa resuelva nuestra necesidad no significa que pueda funcionar en cualquier ordenador. Por ejemplo, una aplicación disponible solo para Windows no se instala directamente en GNU/Linux, y un programa que necesita más memoria de la disponible puede funcionar con mucha lentitud o no iniciarse. Por eso debemos contrastar las características del equipo y del sistema con los requisitos del programa.

Antes de instalar un sistema o una aplicación, hay que comprobar al menos:

Arquitectura compatible: procesador y versión de 32 o 64 bits cuando aplique.
Memoria RAM, almacenamiento disponible y requisitos gráficos.
Versión del sistema operativo y actualizaciones necesarias.
Controladores o periféricos compatibles.
Dependencias: bibliotecas, entornos de ejecución, navegador o servicios requeridos.
Necesidades de red, cuentas, permisos y licencia.

Los requisitos mínimos son las condiciones que declara el proveedor para una versión y un uso determinados. Cumplirlos no garantiza que el programa responda bien con cualquier carga; los recomendados orientan una experiencia de uso más adecuada. Antes de convertir una cifra en requisito, identifica producto, versión y documentación de origen. En un entorno profesional también importan soporte, mantenimiento, copias, compatibilidad con formatos y continuidad del proveedor o comunidad.

2.3.3. Licencias de software

La licencia define qué se permite hacer con un programa: usarlo, copiarlo, modificarlo, redistribuirlo o integrarlo con otros componentes. El precio no define por sí solo la licencia: un programa gratuito puede seguir siendo propietario, y uno libre puede ofrecer servicios de pago.

Modelo o licencia	Idea principal	Ejemplo de implicación
Propietario	El titular conserva el control del código y fija condiciones de uso.	Normalmente se acepta un contrato de licencia de usuario final.
Software libre	Garantiza libertades de uso, estudio, modificación y distribución bajo sus condiciones.	Puede auditarse y adaptarse, cumpliendo la licencia.
Código abierto	El código fuente está disponible bajo una licencia aprobada como abierta.	Permite revisar e integrar según las condiciones concretas.
Freeware	Puede utilizarse sin coste, pero no implica acceso al código fuente.	Gratuito no equivale a libre.
Shareware o prueba	Uso limitado en tiempo o funciones.	Puede requerir compra tras el periodo de prueba.
GPL	Licencia libre de tipo copyleft.	Las redistribuciones de obras derivadas deben conservar condiciones compatibles.
BSD o Apache	Licencias permisivas.	Permiten reutilización amplia manteniendo avisos y condiciones.
EULA	Contrato de licencia de usuario final.	Establece condiciones de uso de software propietario, y a veces de otros modelos.

Ampliación: GPLv3, MIT y Apache 2.0 en un proyecto de desarrollo

La selección básica exige reconocer propósito, libertades y condiciones de uso. La siguiente lectura amplía las obligaciones al distribuir proyectos de desarrollo; no necesitas resolver un análisis jurídico de dependencias para completar las actividades de esta unidad.

Cuando se incorpora una biblioteca de terceros, no basta con comprobar que es gratuita o que su código está disponible. Hay que identificar su licencia, conservar los avisos que exige y revisar qué ocurrirá si el proyecto se distribuye a otras personas o empresas.

Licencia	Tipo y obligación práctica al redistribuir	Qué debe revisar un equipo de desarrollo	Ejemplo real
GPLv3	Copyleft. Al distribuir una obra derivada, deben mantenerse las condiciones de la GPLv3 y ponerse a disposición el código fuente correspondiente.	Si la dependencia se integra de un modo que forme una obra derivada y el producto se va a distribuir, hay que comprobar la compatibilidad con la licencia del proyecto.	El kernel Linux ilustra el copyleft, pero usa GPLv2-only, no GPLv3. No debe citarse como ejemplo de GPLv3.
MIT	Permisiva. Permite usar, modificar, sublicenciar y redistribuir, incluso en software propietario, conservando el aviso de copyright y la licencia.	Incluir los avisos de licencia de las dependencias en el repositorio o en la documentación de distribución.	React se distribuye bajo licencia MIT.
Apache 2.0	Permisiva. Al redistribuir exige entregar la licencia, señalar los archivos modificados y conservar los avisos aplicables; si la obra incluye `NOTICE`, hay que reproducir sus atribuciones pertinentes en alguna de las formas permitidas. Incluye una concesión expresa de patentes de quienes contribuyen.	Revisar las condiciones del apartado 4 y los avisos de la distribución concreta.	Kubernetes usa Apache 2.0. Android Open Source Project (AOSP) usa Apache 2.0 para la mayor parte de su software de espacio de usuario; el kernel incluido sigue GPLv2.

En Apache 2.0, apartado 4, la copia legible de las atribuciones de NOTICE puede acompañar a la distribución, figurar en su documentación o mostrarse donde aparezcan normalmente avisos de terceros. No se exige conservar siempre un archivo con ese nombre ni presentar NOTICE como si cambiara la licencia.

La diferencia más visible es que MIT y Apache 2.0 permiten normalmente integrar componentes en una aplicación con otra licencia, siempre que se respeten sus avisos y condiciones. La GPLv3 busca que las libertades se mantengan cuando se distribuye una obra derivada. El resultado exacto depende de cómo se integre el componente y de si se distribuye el producto; por eso no se deben extraer conclusiones legales solo a partir del nombre de una licencia.

Caso de desarrollo: añadir una dependencia

Una dependencia es un componente de software de terceros que nuestro programa necesita para realizar alguna función. Incorporarla evita programar esa función desde cero, pero también obliga a revisar sus requisitos y su licencia.

Por ejemplo, un equipo desarrolla una aplicación web para reservar clases de una autoescuela. La pantalla debe consultar al servidor qué horas quedan libres y enviar la reserva elegida. Para realizar esas peticiones puede utilizar Axios, una biblioteca de JavaScript. La aplicación aporta la lógica de reservas; Axios se ocupa de facilitar la comunicación mediante peticiones HTTP. Puedes reconocer su función en la documentación de Axios.

Antes de incorporarla, el equipo sigue estos pasos:

Identificar el componente y su origen. Localiza el repositorio oficial y el archivo LICENSE de la versión elegida. Como muestra de lectura, el archivo de licencia de Axios 1.7.9 recoge las condiciones MIT. Esta versión se cita para consultar un documento concreto, no como recomendación de instalación.
Registrar qué se incorpora. Anota nombre, versión exacta, origen, licencia y función. Por ejemplo: «Axios; versión elegida por el equipo; repositorio oficial; MIT; consultar horarios y enviar reservas». En un inventario real se sustituye “versión elegida” por su número concreto.
Decidir cómo se entregará el programa. En este caso, la autoescuela recibirá una copia de la aplicación que incluye la biblioteca. Por tanto, el equipo debe revisar las condiciones de redistribución, además de comprobar que funciona.
Cumplir las condiciones. MIT permite integrar la biblioteca en una aplicación propia, incluso propietaria, pero exige conservar el aviso de copyright y el texto de permiso en las copias o partes sustanciales del componente. El equipo puede reunirlos en un documento de licencias de terceros que acompañe a la aplicación. También revisa las licencias de las demás dependencias que se incluyan: no todas tienen por qué ser MIT.

El resultado no es simplemente «Axios es gratis». Es una decisión documentada: sabemos qué función resuelve, de dónde procede, qué versión usamos y qué avisos deben acompañar a la entrega. Elegir una biblioteca con licencia MIT no obliga por sí solo a publicar todo el código propio de la aplicación.

El propósito y la licencia son dos clasificaciones distintas. Una base de datos puede ser software de aplicación y, a la vez, distribuirse bajo una licencia libre o propietaria.

2.4. Comparación de sistemas operativos según ámbito de uso

Comparar sistemas operativos no consiste en declarar uno ganador. Consiste en relacionar requisitos, aplicaciones necesarias, experiencia del equipo técnico, coste, soporte y restricciones legales con un caso de uso.

2.4.1. Criterios de comparación

Para justificar una elección, conviene valorar:

Hardware disponible y consumo de recursos.
Aplicaciones imprescindibles y compatibilidad de formatos.
Tipo de usuario: oficina, desarrollo, administración, diseño o atención al público.
Necesidades de red, seguridad, cuentas y gestión centralizada.
Licencia, coste de adquisición, soporte y mantenimiento.
Formación previa del equipo y documentación disponible.
Estabilidad, actualizaciones y ciclo de vida.

2.4.2. Casos de uso profesionales

Entorno	Necesidades principales	Elección razonada posible
Aula de programación	IDE, compiladores, terminal, herramientas de red y facilidad de recuperación.	Distribución GNU/Linux en equipos o máquinas virtuales, complementada si se requiere software específico.
Oficina administrativa	Suite ofimática, correo, navegador, impresoras, formatos compartidos y soporte cercano.	Sistema de escritorio compatible con las aplicaciones y periféricos de la organización.
Servidor web	Estabilidad, red, actualizaciones controladas, administración remota, logs y servicios web.	Sistema orientado a servidor, habitualmente GNU/Linux o Windows Server según la pila tecnológica y la experiencia disponible.
Estación de diseño	Rendimiento gráfico, almacenamiento rápido, aplicaciones creativas y controladores certificados.	Sistema compatible con la suite de diseño elegida y el hardware gráfico.
Dispositivo industrial	Arranque rápido, función limitada, consumo reducido y respuesta predecible.	Sistema embebido o de tiempo real, según los plazos exigidos.
Desarrollo móvil	Kit de desarrollo de software (SDK), emuladores, control de versiones y compilación.	Sistema compatible con el SDK y las herramientas oficiales del ecosistema objetivo.

Caso guiado: pequeña empresa de desarrollo web

Una empresa tiene diez puestos para desarrollar aplicaciones web, un servidor que publicará una intranet y personal administrativo que usa documentos compartidos.

Una propuesta razonada puede combinar:

Equipos de desarrollo con un SO que ejecute cómodamente editor, terminal, navegador, contenedores o máquinas virtuales y herramientas de control de versiones.
Un servidor con un SO estable, administración remota, actualizaciones controladas y soporte para el servidor web y la base de datos seleccionados.
Puestos administrativos con aplicaciones ofimáticas compatibles con los formatos y flujos de la empresa.

La elección final no depende solo de una marca o de la preferencia personal. Debe justificar aplicaciones, requisitos, licencias, personal disponible y mantenimiento.

2.5. Propósito y licencia

RA7.a.

Relaciona las afirmaciones con los conceptos freeware, copyleft, EULA y licencia permisiva, como MIT. Explica por qué precio y libertad son ejes distintos.

Los enlaces permiten consultar la definición de freeware y copyleft, ejemplos de contratos de usuario final de Microsoft y el texto de MIT. Freeware y copyleft son conceptos; EULA es un tipo de contrato; MIT es una licencia concreta. Para resolver la tabla, identifica qué condición describe cada afirmación.

Afirmación	Concepto	Justificación
Se permite el uso sin pagar, sin conceder derecho de modificar el código.	Freeware (ejemplo resuelto).	El programa puede usarse sin pagar, pero eso no concede permiso para modificar su código. El precio es gratuito; las libertades dependen de la licencia.
Redistribuir una obra derivada exige mantener determinadas libertades.
El contrato define las condiciones de uso para la persona usuaria final.
Se permite reutilización amplia, conservando avisos y condiciones.

Clasifica además un IDE y una hoja de cálculo por propósito. ¿Podría una empresa usar software libre y contratar soporte? Entrega la tabla y una explicación breve; no debes deducir obligaciones de una licencia concreta solo por su precio.

2.6. Propuesta informática Aules

Trabajo individual · RA principal: RA7.a y RA7.b · CE relacionado: RA2.c.

Una pequeña empresa va a preparar seis puestos administrativos. Ha recibido una propuesta informática, pero su responsable sospecha que contiene errores.

Tu trabajo consiste en revisar la propuesta, explicar los problemas y presentar una alternativa que responda a las necesidades de la empresa. No tienes que instalar programas ni elaborar un presupuesto.

La empresa y sus necesidades

Las seis personas trabajadoras necesitan:

Utilizar una aplicación de gestión para consultar clientes y registrar pedidos.
Crear y modificar documentos y hojas de cálculo.
Intercambiar archivos .docx y .xlsx con otras empresas.
Consultar el correo mediante un navegador.
Imprimir documentos en una impresora de red.

La empresa ya dispone de seis ordenadores de 64 bits, con 8 GiB de RAM y SSD de 256 GB cada uno. Quiere aprovecharlos y evitar compras innecesarias, pero necesita que las aplicaciones funcionen y que alguien pueda atender las incidencias.

Información disponible para revisar la propuesta

Utiliza estas fichas como datos del ejercicio. Las condiciones de la aplicación de gestión y de las ofertas son ficticias, creadas para esta actividad.

Elemento	Información que conocemos
Aplicación de gestión GestiónPlus	Se instala en cada ordenador. El proveedor solo garantiza su funcionamiento y ofrece asistencia en Windows. Antes de instalar, debe confirmar la edición y versión admitidas. No existe una versión web.
Licencia de GestiónPlus	Cada licencia permite instalar y utilizar el programa en un único equipo. Los seis puestos necesitan utilizarlo.
Requisitos de GestiónPlus	El proveedor indica un mínimo de 8 GiB de RAM. También debe comprobarse su funcionamiento junto con las demás aplicaciones que utilizará la empresa.
Windows	Sistema operativo propietario. Hay que comprobar la edición y versión necesarias y si los equipos ya disponen de licencias válidas.
Distribución GNU/Linux	Sistema operativo compuesto por programas con distintas licencias. Puede utilizarse con aplicaciones libres y contratar asistencia técnica. El proveedor de GestiónPlus no ofrece soporte para su aplicación en este sistema.
LibreOffice	Suite ofimática libre que puede utilizarse en una empresa sin pagar por cada instalación. Se distribuye bajo MPL 2.0 e incluye componentes con otras licencias. Permite estudiar y modificar su código respetando las condiciones aplicables. Puede trabajar con archivos `.docx` y `.xlsx`, pero debe comprobarse la conservación del formato y de las funciones que utilice la empresa. El soporte profesional puede contratarse por separado.
Navegador y correo	El correo de la empresa funciona desde un navegador. Esto no sustituye a GestiónPlus, que necesita su propia instalación.
Impresora	Antes de decidir la configuración definitiva, hay que comprobar que existen controladores compatibles con el sistema elegido.

La ficha de LibreOffice se apoya en su información oficial de licencias. Las condiciones ficticias de GestiónPlus no describen las licencias de otros productos reales.

La propuesta que debes revisar

La empresa ha recibido el siguiente informe. Combina decisiones razonables con conclusiones que necesitan corregirse o justificarse mejor. No debes rechazar cada apartado por completo: distingue qué conservarías y qué cambiarías.

Propuesta de preparación de los seis puestos administrativos

1. Sistema operativo y aplicación de gestión

Proponemos instalar una distribución GNU/Linux con soporte vigente para aprovechar los equipos existentes y reducir las compras de licencias. Antes de extender la instalación, prepararemos un puesto de prueba e intentaremos ejecutar GestiónPlus mediante una herramienta de compatibilidad. Si conseguimos abrir el programa y registrar un pedido, consideraremos validada la solución para los seis puestos y daremos por cubierta la asistencia del proveedor.

2. Licencias de la aplicación de gestión

La empresa adquirirá una licencia de GestiónPlus a su nombre. Instalaremos el programa en los seis ordenadores para que cada persona pueda trabajar desde su puesto. Como los equipos pertenecen a la misma organización y los datos se utilizarán dentro de ella, consideramos que una única licencia empresarial será suficiente. Solo ampliaríamos la compra si se incorporase otra empresa o una segunda sede.

3. Ofimática y documentos compartidos

Instalaremos LibreOffice en los seis puestos, ya que permite el uso empresarial sin pagar por cada instalación. Para facilitar el intercambio con clientes y proveedores, configuraremos .docx y .xlsx como formatos habituales de guardado. Comprobaremos que se abre un documento de texto y una hoja de cálculo nuevos; si ambos funcionan, consideraremos compatibles también las plantillas, fórmulas y documentos que la empresa ha acumulado durante los últimos años.

4. Capacidad de los ordenadores

Mantendremos los equipos actuales porque sus 8 GiB de RAM coinciden con el mínimo publicado para GestiónPlus. Así evitaremos ampliar memoria antes de empezar. Ese dato permite asegurar que cada puesto podrá utilizar simultáneamente GestiónPlus, LibreOffice y varias pestañas del navegador sin problemas de rendimiento; las pruebas con una jornada de trabajo real podrán dejarse para después de la puesta en marcha.

5. Software libre y coste de mantenimiento

La combinación de GNU/Linux y LibreOffice permite reducir el gasto en licencias de los puestos. Al disponer de su código y poder utilizarlos libremente, no será necesario reservar presupuesto para asistencia, formación o resolución de incidencias. La empresa podrá asumir esas tareas con sus propios empleados, aunque todavía no hemos comprobado su experiencia con las herramientas propuestas.

6. Actualizaciones y continuidad del trabajo

Una vez que el puesto de prueba funcione, utilizaremos la misma configuración en los otros cinco equipos. Para evitar diferencias y cambios inesperados durante el trabajo, dejaremos desactivadas las actualizaciones automáticas. Revisaremos el software cuando se produzca una avería o cuando GestiónPlus exija una nueva versión; mientras los programas sigan abriéndose, mantendremos la configuración inicial.

Parte 1. Detecta y explica los problemas

Revisa las seis recomendaciones y completa la tabla. Para cada una:

Distingue la decisión razonable de la conclusión incorrecta o insuficientemente justificada.
Explica qué consecuencia podría tener para la empresa.
Escribe una corrección concreta.

No basta con responder «está mal» o copiar una frase de las fichas: relaciona el problema con lo que necesita la empresa.

Recomendación	¿Qué conservarías y qué corregirías?	¿Qué problema podría provocar?	¿Cómo la corregirías?
1
2
3
4
5
6

Parte 2. Presenta una propuesta corregida

Ahora selecciona el sistema operativo y las aplicaciones que propondrías. Utiliza la información de las fichas y distingue entre una decisión que ya puedes justificar y un dato que todavía necesitas comprobar.

Necesidad	Software o solución que propones	Propósito: base o aplicación	Licencia o condiciones de uso conocidas	¿Qué falta comprobar?
Hacer funcionar los seis ordenadores
Gestionar clientes y pedidos
Crear y modificar documentos y hojas de cálculo
Consultar el correo
Utilizar la impresora

Puedes dejar pendiente el producto concreto del navegador o el controlador de la impresora. En ese caso, indica qué función necesitas y qué compatibilidad comprobarías.

Cuando las fichas no permitan conocer un precio, una versión o una condición, escribe «pendiente de confirmar» y explica qué preguntarías. No inventes esos datos.

Parte 3. Justifica tu decisión

Escribe un párrafo final de unas 150–200 palabras dirigido a la persona responsable de la empresa. Explica:

Qué sistema operativo propones y qué requisito determina tu elección.
Por qué descartas el otro sistema como sustituto directo en este caso.
Qué aplicaciones necesita la empresa y qué condiciones de licencia debes respetar.
Qué comprobarías antes de instalar en los seis equipos.
Cómo organizarías las actualizaciones y la atención de incidencias.

Tu explicación debe permitir entender por qué la propuesta responde al caso, además de nombrar los programas elegidos.

2.6.1. Qué debes entregar y criterios de corrección

Entrega un único documento con:

La tabla de revisión de las seis recomendaciones.
La tabla de la propuesta corregida.
El párrafo de justificación.

Se valorará que distingas las decisiones válidas de las conclusiones incorrectas, expliques sus consecuencias, selecciones software adecuado, clasifiques su propósito y licencia, y señales las comprobaciones pendientes. Debes justificar la comparación de sistemas y diferenciar precio, libertades y costes de mantenimiento.

La propuesta se reutilizará en UD04 para preparar la instalación.

Elegir un SO prepara su instalación, pero antes estudiaremos qué ocurre cuando los programas elegidos se ejecutan y compiten por recursos.