Ejercicios: El proceso de desarrollo

Estas fases del desarrollo de un programa están desordenadas: (a) probar el programa con distintos datos, (b) editar el código fuente, (c) depurar los errores encontrados, (d) ejecutar el programa. Ordénalas de forma razonable y explica qué se hace en cada una, teniendo en cuenta que al probar puede ser necesario volver atrás.

Explica qué es un «bug» en un programa y qué es depurar. Pon un ejemplo sencillo de error que podría tener el programa de un cajero automático y qué consecuencia tendría para el usuario.

La figura muestra el ciclo de trabajo del desarrollo de un programa, pero una de sus etapas está tapada con un signo de interrogación, como se muestra en la figura.

Indica qué etapa falta dentro del ciclo, en qué consiste y por qué la flecha de «no» devuelve el trabajo a la edición del código.

Explica qué es un mensaje de traza o registro (log) en un programa y cómo ayuda a encontrar un error (permite ver por dónde pasó el programa y con qué valores).

Los programas tienen versiones (1.0, 1.1, 2.0...). Explica para qué sirve guardar versiones del código y qué puedes hacer si la última versión funciona peor que la anterior.

Explica qué es un caso de prueba y escribe dos casos para un programa que suma dos números: uno con valores normales y otro con algún valor especial, indicando la entrada y el resultado esperado de cada uno.

La documentación acompaña al programa. Explica qué dos cosas debería explicar como mínimo (qué hace el programa y cómo se usa) y por qué un programa sin documentar «envejece» mal cuando trabaja un equipo.

Distingue entre un error que aparece al compilar (el programa ni siquiera arranca) y un error que aparece en ejecución (arranca pero falla con ciertos datos), con un ejemplo de cada tipo.

Explica la diferencia entre un error de sintaxis y un error de lógica, con un ejemplo de cada uno en un programa que calcula la media de tres notas. ¿Cuál de los dos tipos impide ejecutar el programa y cuál deja ejecutarlo pero da resultados incorrectos?

Un programa que divide dos números funciona bien en casi todas las pruebas, pero falla cuando el divisor es 0. Explica qué son los valores límite o casos especiales en las pruebas, por qué hay que probarlos siempre y cita otros dos valores con los que probarías este programa.

Explica qué es la modularización de un programa (dividirlo en funciones o módulos) y analiza dos ventajas que aporta cuando el desarrollo lo hace un equipo de varias personas: piensa en el reparto del trabajo, en las pruebas y en la localización de errores.

Un bucle de un programa no se detiene nunca. Explica dónde colocarías mensajes de escritura temporales para diagnosticarlo (dentro del bucle, mostrando la variable de control en cada vuelta) y qué observarías en esos mensajes para encontrar la causa.

Para probar un programa que aplica un descuento a personas de 65 años o más, define tres casos de prueba: uno con un valor normal, uno con el valor límite exacto y uno con un valor erróneo (edad negativa o imposible), con el resultado esperado de cada uno. Justifica tus elecciones.

Explica qué es refactorizar (mejorar el código sin cambiar lo que hace) y describe dos refactorizaciones típicas (renombrar variables con nombres claros, extraer una función a partir de código repetido), con un ejemplo de cada una.

Un fragmento de código usa las variables x, y2 y zzz para guardar el precio, el IVA y el total. Reescribe esos nombres de forma significativa y explica por qué la elección de nombres es una herramienta contra los errores (el código se autodocumenta).

Dos personas de un equipo editan a la vez el mismo fichero del proyecto y, al unir los cambios, aparece un conflicto. Explica qué es un conflicto de fusión, cómo se resuelve (revisar ambas versiones y decidir) y qué dos hábitos de trabajo en equipo lo previenen (repartir el trabajo por módulos, integrar los cambios a menudo).

Un programa de facturación calcula mal el total solo con algunos pedidos, y nadie sabe por qué. Describe una estrategia de depuración ordenada, paso a paso (reproducir el fallo, acotar los datos que lo provocan, insertar escrituras intermedias o usar el depurador, formular y comprobar hipótesis), explicando el objetivo de cada paso.

Un compañero afirma: «probar el programa es perder el tiempo; si compila, está bien». Rebátelo con argumentos: distingue lo que garantiza la compilación de lo que solo descubren las pruebas, y apóyate en un ejemplo de programa que compila pero hace algo distinto de lo esperado.

Diseña un plan de pruebas para un programa que pide dos números y muestra su división: haz una tabla con al menos seis casos de prueba (pares de valores de entrada, incluyendo valores normales, límite y erróneos), el resultado esperado de cada uno y qué debería hacer el programa si la entrada no es válida. Justifica la elección de cada caso.

Un programa falla aproximadamente una de cada veinte ejecuciones, sin patrón aparente (depende de datos de red y de números aleatorios). Diseña una estrategia para cazar ese error: registro detallado de cada ejecución, fijar la semilla de los aleatorios para reproducir el caso, aislar el dato que lo provoca y comprobar la corrección. Explica el objetivo de cada medida.

Diseña el plan de pruebas de una pantalla de acceso (login): escribe al menos seis casos (clave correcta, clave incorrecta, campos vacíos, usuario inexistente, tres fallos seguidos, clave con mayúsculas distintas) con su resultado esperado, y explica qué riesgo cubre cada caso.

«Esta función tiene cinco líneas; no necesita pruebas». Analiza la afirmación con este ejemplo: una función es_par(n) que devuelve verdadero si el resto de dividir n entre 2 es 0, probada solo con números positivos. ¿Qué casos límite podrían delatar un comportamiento inesperado (el cero, los números negativos)? ¿Qué demuestran sobre probar incluso el código «obvio»?

Un programa de 400 líneas está escrito en una única función gigante. Analiza los problemas que eso genera (localizar errores, probar partes por separado, trabajar varias personas, reutilizar código) y describe con qué criterio lo dividirías en funciones (que cada función haga una tarea concreta y coherente).

Tu clase va a desarrollar una pequeña aplicación en equipo durante un trimestre. Diseña el proceso de desarrollo: fases con sus entregables (análisis, diseño, programación, pruebas, documentación), quién revisa el trabajo de quién y en qué momento se congelan los cambios antes de la entrega.