Desarrollo Creativo

En 1999 la NASA perdió la Mars Climate Orbiter, una nave espacial que había costado más de cien millones de dólares. El código no estaba mal escrito. El software de un equipo daba los números en unidades estadounidenses y el de otro equipo los interpretaba como unidades métricas. Cada componente funcionaba por separado; el fallo estaba en la comunicación entre las personas. Esta unidad trata sobre cómo se crean realmente los programas: en grupos, para usuarios, en ciclos repetidos, encontrando y corrigiendo errores durante el proceso.

La computación es una actividad colaborativa. Trabajar en equipo aporta más perspectivas, detecta más errores y produce mejores programas que trabajar solo. Una buena colaboración utiliza construcción de consensos, comunicación clara y las fortalezas de cada miembro. La programación en parejas – dos personas en un computador, una tecleando y otra revisando – es una práctica común. En el examen, debes ser capaz de explicar cómo la colaboración mejoró un programa (más ideas, menos errores, pruebas más amplias).

Una innovación informática es algo nuevo que tiene un programa como parte esencial. Puede ser un objeto físico (un automóvil autónomo), software (un editor de fotos) o un concepto (las compras en línea). Cuando una pregunta dice «innovación informática», cualquiera de los tres sirve.

Por qué importan las diferentes personas. Las personas con distintas experiencias detectan problemas diferentes. Un equipo que incluye diversas perspectivas tiene más probabilidades de evitar el sesgo, porque alguien preguntará «¿qué pasa con los usuarios como yo?». Los desarrolladores también hablan directamente con los usuarios: lo que dicen ayuda al equipo a comprender para qué sirve el programa y para quiénes debe funcionar.

Habilidades y herramientas. Los buenos equipos practican la comunicación, la construcción de consenso, la resolución de conflictos y la negociación. Las herramientas en línea, como los documentos compartidos y los repositorios de código compartidos, permiten dar comentarios desde cualquier lugar.

Ejemplo resuelto. Dos estudiantes construyen una aplicación de cuestionario. Mei escribe el procedimiento de puntuación mientras Tom revisa cada línea mientras ella teclea; más tarde, Tom pide a cinco compañeros que prueben la aplicación, y dos de ellos descubren que una respuesta en blanco la hace fallar. ¿Cómo ayudó la colaboración?

1. Tom revisa el código mientras se escribe (programación en pareja), lo que puede detectar errores de forma temprana.
2. Los compañeros son usuarios con diferentes hábitos; sus pruebas encontraron un caso que ninguno de los programadores había considerado, la respuesta en blanco.
3. Cada beneficio se nombra y se vincula al programa: "más probadores encontraron el fallo con respuesta en blanco" obtiene crédito donde "el trabajo en equipo es bueno" no lo haría.

Ejemplo resuelto: un desacuerdo. Dos integrantes de un equipo no están de acuerdo: Sara quiere un temporizador en cada pregunta del cuestionario y Li dice que un temporizador preocupará a los usuarios nerviosos. ¿Cuál es el mejor paso a seguir?

• Sara y Li votan y quien pierde cede: es rápido, pero ignora a los usuarios.
• Cada uno crea su propia versión y nunca la comparten: el equipo se divide.
• Consultan a algunos usuarios y luego acuerdan una regla, por ejemplo, un temporizador que los usuarios puedan desactivar.

La tercera opción es construcción de consenso: la decisión se basa en pruebas y ambas personas la aceptan.

Cada programa se escribe con un propósito: resuelve un problema o persigue un interés. Un programa recibe una entrada, la procesa y produce una salida. Las entradas pueden provenir de un usuario, un dispositivo, un archivo u otro programa; las salidas pueden ser visuales, auditivas, textuales o una señal para un dispositivo. Poder enunciar el propósito de un programa y describir claramente sus entradas y salidas es una habilidad fundamental (y parte de la tarea de rendimiento Create).

Algunos términos que el examen usa de forma precisa:

• Un programa (también llamado software) es un conjunto de instrucciones que realiza una tarea cuando una computadora lo ejecuta. Un segmento de código es una parte de un programa.
• El comportamiento de un programa es la forma en que actúa mientras se ejecuta; suele describirse según la forma en que un usuario interactúa con él.
• Tanto la entrada como la salida pueden ser táctiles (contacto, vibración), de audio, visuales o de texto.
• La salida suele depender de la entrada y también puede depender del estado previo: los valores que el programa ya almacena.

Puedes describir un programa de forma general (qué hace) o con más detalle (qué hace y cómo lo hacen sus instrucciones). Una respuesta escrita suele requerir la segunda opción.

Ejemplo resuelto. Una aplicación de conteo de pasos lee el movimiento mediante el sensor del teléfono, cuenta los pasos y muestra el total del día y una insignia cuando el usuario alcanza 10,000.

La insignia también muestra cómo funciona el estado previo: la misma entrada de un paso solo produce una insignia si el total almacenado acaba de alcanzar la meta.

Un error común es dar la función como propósito: "cuenta pasos" dice qué hace el programa, no el problema que resuelve.

Los programas se construyen mediante un proceso iterativo, no en una línea recta: investigar el problema y los usuarios, diseñar (a menudo con un diagrama o plan escrito), implementar en código y probar; luego repetir. Un problema grande se divide en partes más pequeñas (descomposición). Los comentarios y la nomenclatura clara documentan el diseño para que otros (y tu yo del futuro) puedan entenderlo. El desarrollo es incremental: construye y prueba una pequeña parte, luego agrega la siguiente.

Las fases habituales son investigar y reflexionar, diseñar, construir un prototipo (un modelo funcional inicial) y probar. El orden puede planificarse de antemano o ser más exploratorio, y un equipo puede volver a una fase anterior en cualquier momento.

Ejemplo resuelto: ¿iterativo o incremental? Las dos palabras suenan parecidas y el examen las distingue.

Un proyecto real suele hacer ambas cosas.

Investigar lo que los usuarios realmente necesitan

Antes de escribir código, el desarrollador investiga el problema y a las personas que usarán el programa. Algunas formas de hacerlo:

• encuestas enviadas a posibles usuarios, que recopilan datos de muchas personas rápidamente;
• entrevistas y observación directa de los usuarios realizando la tarea manualmente;
• pruebas con usuarios, en las que las personas prueban una versión inicial mientras el equipo observa;
• estudiar soluciones existentes para ver qué funciona y qué frustra a la gente.

Los hallazgos se convierten en un diseño. Dos artefactos hacen esto: una lista de requisitos del programa que dice exactamente qué debe hacer el programa, y diagramas que representan el diseño de la interfaz de usuario — bocetos que muestran qué controles aparecen dónde y qué hace cada uno al usarse. Diseñar la interfaz en papel primero es más barato que descubrir después de codificar que los botones están en el lugar equivocado.

La especificación de un programa define sus requisitos. Luego, la fase de diseño planifica cómo cumplirlos. Puede incluir una lluvia de ideas, un guion gráfico (una secuencia de bocetos de lo que ve el usuario), la división del programa en módulos y la planificación de las pruebas.

Eventos y programas que esperan

No todos los programas se ejecutan directamente de principio a fin. Un evento se genera cuando se presiona una tecla, se hace clic con el mouse, se inicia un programa o se produce cualquier otra acción definida. Un evento puede cambiar el flujo de ejecución al activar el código asociado a él, llamado controlador de eventos. En muchos programas gráficos, los eventos esperan en una cola hasta que termina el controlador actual.

Por eso un programa con interfaz gráfica puede parecer inactivo: está esperando el siguiente evento. El orden en que llegan esos eventos depende de las acciones del usuario y de otras fuentes de eventos, por lo que el mismo programa puede ejecutar sus bloques en un orden diferente cada vez que se usa.

Este estilo se llama programación orientada a eventos: las instrucciones se ejecutan cuando se activan, en lugar de hacerlo una tras otra desde el principio. El evento también proporciona datos de entrada, como qué tecla se presionó.

Documentación y reconocimiento de autoría

La documentación de un programa es una descripción escrita de lo que hace un segmento de código, evento, procedimiento o programa y de cómo se desarrolló. Los comentarios son una forma de documentación: se escriben para las personas y no cambian la ejecución del programa. No todos los entornos de programación permiten comentarios, por lo que a veces la documentación está en un archivo separado.

Escribe la documentación durante todo el desarrollo, no al final: te ayuda a ti y a tus compañeros a mantener el programa correcto.

Se debe reconocer la autoría del código de otra persona: indica en la documentación de dónde proviene y el nombre del autor original si lo conoces. Esto también se aplica al código escrito con un compañero.

Un error es un fallo en un programa; la depuración consiste en encontrarlo y corregirlo. El examen menciona cuatro tipos:

• un error de sintaxis viola las reglas del lenguaje, por lo que el programa no se ejecutará;
• un error de tiempo de ejecución provoca un fallo del programa durante su ejecución (p. ej., división por cero);
• un error lógico permite que el programa se ejecute, pero produce un resultado incorrecto;
• un error de desbordamiento ocurre cuando un número está fuera del intervalo que la computadora puede manejar.

Encuentra errores mediante casos de prueba con diferentes entradas, añadiendo instrucciones de impresión para ver los valores y siguiendo manualmente la ejecución del código. Un depurador detiene el programa en una línea elegida para que puedas examinar cada variable, y una visualización, como un gráfico, puede facilitar la detección de un patrón incorrecto. Elige las entradas de prueba de forma deliberada: deben mostrar los distintos resultados esperados en los extremos o justo fuera de ellos: los valores mínimo y máximo que el programa debe aceptar y un valor justo fuera de cada uno. Un programa que funciona con datos habituales falla con frecuencia ante una lista vacía, un cero o un valor inmediatamente posterior al final de un intervalo, por lo que conviene probar primero esas entradas. Corregir un error a la vez y volver a probar es el método más confiable.

Ejemplo resuelto: elegir entradas de prueba. Una página de inscripción a un club debe aceptar edades de 13 a 18. Los requisitos indican el resultado correcto, por lo que puedes elegir entradas y decir qué esperas:

Cinco pruebas son suficientes: 12, 13, 15, 18 y 19. Si el código dice age > 13, solo la prueba con 13 muestra el fallo; la edad 15 se acepta en ambos casos.

Habilidad de examen: ser capaz de nombrar el tipo de error y describir una estrategia de pruebas que lo detectaría — tema recurrente en preguntas de opción múltiple y tareas Create.

Ejemplo resuelto. Un programa diseñado para imprimir el promedio de dos números en su lugar ejecuta avg = a + b / 2. Al rastrear el orden de operaciones, / se ejecuta antes que +, por lo que calcula $a+\tfrac{b}{2}$ en lugar del promedio. Agrega paréntesis para corregirlo: avg = (a + b) / 2. Probar con $a=4,\ b=6$ confirma la corrección: la línea defectuosa produce $4+3=7$, la línea corregida produce $\tfrac{10}{2}=5$. Probar con entradas conocidas es exactamente cómo encuentras y confirmas un error lógico.

Ejemplo resuelto: identifica el error.

Respuestas escritas sobre tu propio programa

La sección II del examen concede 60 minutos para dos preguntas con cuatro consignas escritas, todas sobre el programa que entregaste para la tarea de creación. Puedes ver tus propios segmentos de código en tu Referencia de Proyecto Personalizada, por lo que las respuestas deben referirse a tu programa, no a los programas en general. Imagina que este procedimiento está en el tuyo:

PROCEDURE Average(numbers)
{
   sum ← 0
   FOR EACH n IN numbers
   {
      sum ← sum + n
   }
   RETURN(sum / LENGTH(numbers))
}

En consignas anteriores se ha pedido lo siguiente.

1. Una modificación que cause un error de lógica y cómo cambia el comportamiento. «Si sum ← 0 se cambia por sum ← 1, el procedimiento sigue ejecutándose, pero cada total es una unidad mayor de lo debido. Average([2, 4]) devuelve $3.5$ en lugar de $3$».
2. Una llamada que el procedimiento acepta pero procesa incorrectamente. «Average([]): se acepta la lista vacía, pero LENGTH(numbers) es 0, por lo que la última línea divide entre cero y un error de ejecución detiene el programa». Indica la llamada, el comportamiento incorrecto y el motivo: son tres cosas distintas.
3. Documentación para otro programador. «Un comentario encima del procedimiento que indique que numbers no debe estar vacío. Así, otro programador que reutilice Average sabrá que debe comprobar si la lista está vacía antes de llamar al procedimiento».
4. Una entrada inesperada. Indica una entrada real para tu programa y di qué hace realmente el programa a continuación. Si rechaza la entrada, indica qué línea lo hace.

Errores comunes. Describir en qué consiste una modificación sin indicar qué cambia cuando se ejecuta el programa. Dar una llamada sin valores específicos para los argumentos. Responder sobre un procedimiento distinto del que menciona la consigna.

Responda cada pregunta antes de leer las respuestas siguientes.

1. Una aplicación de conteo de pasos cuenta los pasos y muestra un total diario para que los usuarios puedan alcanzar una meta. Indica el propósito del programa y una de sus funciones.
2. Clasifica cada error como error de sintaxis, de lógica, de ejecución o de desbordamiento: (a) falta un corchete de cierre; (b) se calcula un promedio como sum / (count + 1); (c) se divide entre una variable que vale cero durante la ejecución del programa; (d) se añade $1$ al valor más grande que puede almacenar un número fijo de bits.
3. Un procedimiento devuelve "pass" para puntuaciones de $60$ o más. Elige cuatro entradas de prueba y explica tus elecciones.
4. Indica un beneficio de colaborar al diseñar un programa.
5. Distingue el desarrollo iterativo del desarrollo incremental.
6. Da dos razones para escribir comentarios y otra documentación de un programa.

1. Propósito: ayudar a los usuarios a alcanzar una meta diaria de actividad. Función: por ejemplo, añade $1$ al total cada vez que detecta un paso o muestra el total.
2. (a) Sintaxis; (b) lógica; (c) ejecución; (d) desbordamiento.
3. $59$, $60$ y $61$ ponen a prueba el límite, donde es más probable que haya errores; un valor extremo como $0$ o $100$ permite comprobar los límites de las entradas válidas.
4. Las distintas perspectivas ayudan a encontrar errores y evitar sesgos, de modo que el programa funcione para más usuarios (por ejemplo, la programación en pareja permite detectar errores antes).
5. El desarrollo iterativo repite ciclos de diseño, prueba y mejora, y revisa el programa tras recibir comentarios. El desarrollo incremental construye y prueba el programa en partes pequeñas, añadiendo una parte funcional a la vez.
6. Explica qué hace el código y por qué, para que otras personas (y el autor más adelante) puedan comprenderlo, mantenerlo y depurarlo; también registra las fuentes del código tomado de otros.

• La evaluación incluye preguntas de opción múltiple y el componente Create, con respuestas escritas en el examen AP. Explica tu razonamiento claramente, no solo tu resultado.
• Conozca los beneficios de la colaboración y cómo las perspectivas diversas reducen el sesgo en un programa.
• Usa vocabulario preciso (iterativo, incremental, requisitos del programa) cuando describas un proceso de diseño.
• Haz pruebas en los extremos del rango de entrada y justo fuera de ellos, e indica la salida esperada para cada prueba.
• Dar y recibir retroalimentación de manera constructiva; reconocer a colaboradores y fuentes.
• Divida un problema grande en módulos más pequeños que un equipo pueda construir en paralelo.