Desarrollo de software

Un ciclo de vida del desarrollo 开发生命周期 es el conjunto de etapas desde la idea hasta un software terminado y mantenido. Existe para planificar, gestionar y controlar un proyecto: construir el producto correcto, a tiempo y con buena calidad.

Por qué se necesita un ciclo de vida

La lista del examinador sobre "el propósito de un ciclo de vida del desarrollo": divide un proyecto grande en etapas que pueden planificarse y gestionarse; asegura que los requisitos 需求 se identifiquen y aprueben antes de comenzar el diseño y la codificación; incluye pruebas y documentación en lugar de dejarlas para el final; permite al equipo seguir el progreso frente a hitos y gestionar riesgos; y ofrece al cliente puntos definidos para revisar el trabajo. Sin uno, un equipo programa primero y descubre tarde que ha construido lo incorrecto.

Por qué existen diferentes tipos

Ningún único ciclo de vida sirve para todos los proyectos, por lo que hay varios ciclos de vida del desarrollo. La elección depende del tamaño y la complejidad, qué tan claros estén los requisitos 需求 al inicio, cuánto cambio se espera, el nivel de riesgo, el equipo y el plazo.

Modelos comunes

• Waterfall 瀑布模型 — una secuencia lineal (Análisis → Diseño → Codificación → Pruebas → Mantenimiento), donde cada etapa se termina antes de comenzar la siguiente. Claro y bien documentado; bueno para requisitos estables, pero poco apto para manejar cambios a mitad del proyecto, y el cliente no ve nada funcionando hasta el final.
• Modelo iterativo 迭代模型 — pasadas repetidas, cada una produciendo una versión parcial que se revisa y refina. Detecta problemas temprano; bueno cuando los requisitos se descubren con el tiempo, pero más difícil de estimar.
• Desarrollo Rápido de Aplicaciones 快速应用开发 (RAD) — uso intensivo de un prototipo 原型 y retroalimentación del usuario. Entrega muy rápida de la primera versión; bueno para requisitos cambiantes, pero depende de la disponibilidad del usuario y se adapta mejor a sistemas pequeños.
• Agile 敏捷 — iteraciones cortas ("sprints"), colaboración constante y pruebas. Flexible y adaptable, pero requiere un cliente comprometido y un equipo capacitado.

Principios, beneficios y desventajas — según enumera la guía de calificación.

Ejemplo resuelto. Una empresa debe ser la primera en lanzar un sitio web para una nueva consola de videojuegos, y el diseño cambiará a medida que se anuncien las características de la consola. Nombre el ciclo de vida más adecuado y justifíquelo.

RAD. Se puede construir y mostrar un prototipo del sitio a los usuarios en cuestión de días, y refinarlo a medida que cambian los requisitos; el sitio es pequeño suficiente para un enfoque impulsado por prototipos, y la velocidad de entrega es el requisito principal. Waterfall fijaría los requisitos antes de construir cualquier página y no entregaría nada hasta el final.

Las etapas estándar

Cada etapa tiene un propósito, una salida y actividades típicas —una pregunta de "describir la … etapa" busca dos o tres de estos elementos.

• análisis — averiguar qué debe hacer el programa. Actividades: entrevistas, cuestionarios y observación del sistema actual; un estudio de viabilidad; acordar la especificación de requisitos, contra la cual se verifica cada etapa posterior.
• diseño — decidir cómo lo hará. Salidas: el diagrama de estructura (módulos y parámetros), diagramas de flujo o pseudocódigo para cada módulo, tablas de identificadores y estructuras de datos, diseños de pantallas y archivos, y el plan de pruebas escrito ahora, desde la especificación, antes de que exista código.
• codificación (implementación 实现) — escribir el programa en un lenguaje de alto nivel, módulo por módulo, siguiendo el diseño; cada módulo se prueba a medida que se escribe.
• pruebas — ejecutar el programa según el plan de pruebas (datos normales, anormales, extremos y de límite) y corregir los errores encontrados; le siguen pruebas de integración, alpha, beta y aceptación.
• mantenimiento 维护 — después del lanzamiento, corregir fallos, adaptar el programa a nuevo hardware, software o leyes, y mejorarlo (ver abajo).

Ejemplo resuelto. Complete el diagrama Waterfall Análisis → ? → ? → ? → Mantenimiento y describa qué sucede en la etapa de diseño.

Las etapas faltantes son Diseño, Codificación, Pruebas. En la etapa de diseño, los requisitos se convierten en un plan para el programa: el problema se descompone en módulos (un diagrama de estructura), el algoritmo de cada módulo se escribe como pseudocódigo o diagrama de flujo, se eligen las estructuras de datos e identificadores, se diseñan las pantallas y archivos, y se redacta el plan de pruebas desde la especificación.

Diagrama de estructura

Un diagrama de estructura 结构图 muestra la descomposición jerárquica 分解 de un programa en módulos (subrutinas 子程序) y los parámetros 参数 que se transmiten entre ellos. Cada módulo es un rectángulo; líneas conectan al llamador (arriba) con el llamado (abajo); pequeñas flechas muestran los datos bajando y los resultados subiendo. El diseño luego puede convertirse en pseudocódigo 伪代码 equivalente.

                CalculatePay
            /        |         \
       GetEmployee  CalculateBonus  CalculateTax
       Returns:     Takes: sales    Takes: gross
       employeeID   Returns: bonus  Returns: tax

Es una herramienta de la etapa de diseño, y puedes leer las firmas de procedimiento directamente de él.

Los símbolos que el examinador pide. Una caja es un módulo; una línea enlaza a un solicitante (arriba) con los módulos que llama (abajo), leyéndose de izquierda a derecha en el orden en que se invocan. Una pequeña flecha con un círculo abierto en su cola es un par de datos: un parámetro pasado hacia abajo dentro de un módulo o un valor devuelto hacia arriba; una flecha con un círculo relleno es un par de control, una bandera (generalmente BOOLEAN) que informa al solicitante de lo ocurrido. Un rombo en una bifurcación indica selección: solo uno de los módulos debajo es llamado, dependiendo de una condición. Una flecha curva que barre sobre las líneas significa iteración: los módulos bajo ella se llaman repetidamente en un bucle.

Ejemplo resuelto. Se definen cuatro módulos como PROCEDURE Main(), PROCEDURE ReadData(BYREF Count : INTEGER), FUNCTION IsValid(Value : INTEGER) RETURNS BOOLEAN y PROCEDURE Report(Total : INTEGER, Count : INTEGER). Main llama a ReadData, luego llama a IsValid una vez por cada valor leído, y finalmente llama a Report. Describa el diagrama de estructura.

Main en la parte superior; ReadData, IsValid y Report en una fila debajo, de izquierda a derecha según el orden de llamada. En la línea de ReadData hay un par de datos ascendente Count (un parámetro BYREF regresa). En la línea de IsValid hay un par de datos descendente Value y un par de control ascendente (el resultado BOOLEAN), con una flecha curva de iteración sobre esa línea porque se llama para cada valor. En la línea de Report hay dos pares de datos descendentes, Total y Count. Leyendo en sentido inverso, una función es cualquier módulo que devuelve un valor: su cabecera necesita RETURNS y el tipo devuelto.

Diagrama de transición de estados

Un diagrama de transición de estados 状态转换图 muestra los estados 状态 en los que puede encontrarse un sistema y los eventos que lo mueven entre ellos — útil para máquinas expendedoras, semáforos e interfaces de usuario. Los diagramas de transición de estados se utilizan para documentar el comportamiento de un algoritmo o sistema. Cada estado es un círculo; cada transición es una flecha etiquetada con el evento.

   coin inserted               item selected
[Idle] --------------→ [Awaiting selection] ----------→ [Dispensing]

Facilita detectar transiciones faltantes ("¿qué pasa si se introduce una segunda moneda mientras se espera la selección?").

Lectura y dibujo. Cada transición está etiquetada como entrada | salida (o condición | acción): qué ocurrió, seguido de lo que hace el sistema al cambiar de estado. Una pregunta presenta una tabla de estado actual, entrada, salida, próximo estado y pide el diagrama, o viceversa: cada fila de la tabla corresponde exactamente a una flecha. Verifique que cada estado tenga una flecha saliente para cada entrada posible, incluidas las que dejan el estado sin cambios (una flecha que vuelve sobre sí mismo).

Ejemplo resuelto. Un controlador de bomba tiene estados bomba apagada y bomba encendida. En bomba apagada, la entrada nivel bajo detectado produce la salida activar bomba y pasa a bomba encendida; en bomba encendida, nivel normal detectado produce desactivar bomba y pasa a bomba apagada. Cualquier otra entrada deja el estado sin cambios. Dibuje la tabla.

Las dos filas de "sin cambio" se convierten en flechas de bucle en el diagrama; omitirlas resulta en pérdida de puntos por incompletitud.

• error de sintaxis 语法错误 — rompe la gramática del lenguaje (corchete faltante, palabra clave mal escrita). Se captura durante la traducción; el programa no ejecutará hasta que se corrija.
• error de tiempo de ejecución 运行时错误 — ocurre durante la ejecución (división por cero, archivo no encontrado, índice de matriz fuera de rango). El programa se bloquea o genera una excepción; se corrige añadiendo comprobaciones.
• error lógico 逻辑错误 — el programa se ejecuta pero da resultados incorrectos (usar + en lugar de -, un bucle de error de uno, condiciones en orden incorrecto). Es el más difícil de encontrar; la única señal es la salida errónea, así que use pruebas cuidadosas y trazado.

Exposición y prevención de fallos. Los fallos son expuestos mediante pruebas contra un plan de prueba, mediante una ejecución en seco o tabla de trazado, mediante una revisión con colegas y mediante el depurador del IDE (puntos de interrupción, paso a paso, observación de variables). Se previenen diseñando antes de programar (diagrama de estructura, pseudocódigo), mediante código modular con identificadores y comentarios significativos, mediante la validación de todas las entradas, manejando excepciones en lugar de dejar que un error de tiempo de ejecución bloquee el programa, y mediante las comprobaciones de sintaxis dinámica del IDE mientras escribe.

Ejemplo resuelto. Indique el tipo de error en cada caso y cómo se manifiesta. (a) Result <- STR_TO_NUM(x) / STR_TO_NUM(y) se ejecuta con y = "0". (b) La misma línea se ejecuta con x = "12a". (c) Un bucle escrito como FOR i <- 1 TO 9 procesa una matriz de diez elementos. (d) A OUTPUT "Total: " Total le falta una coma.

(a) Error de tiempo de ejecución — división por cero; el programa se bloquea cuando se ejecuta esta línea con esos datos. (b) Error de tiempo de ejecución — la cadena no puede convertirse en número. (c) Error lógico — el programa se ejecuta pero el décimo elemento nunca se procesa, por lo que la salida es incorrecta. (d) Error de sintaxis — la instrucción viola las reglas del lenguaje y es reportada por el traductor antes de ejecutar el programa.

Ejemplo resuelto. Corrija los errores en este pseudocódigo, que debería mostrar el promedio de diez calificaciones.

Total <- 0
FOR i <- 1 TO 10
    INPUT Mark
    Total <- Total + Mark
NEXT i
Average <- Total / 9
OUTPUT "Average" Average

La división debe ser por 10, no por 9 (error lógico); la línea de salida necesita una coma o un & entre la cadena y el valor (error de sintaxis); y Average nunca se declara como REAL (error de sintaxis o tiempo de ejecución, según el lenguaje). Indique qué línea y cuál es la línea corregida: Average <- Total / 10.

• ejecución en seco 手工跟踪 — tracee el código en papel, escribiendo el valor de cada variable en una tabla.
• revisión 走查 — una revisión en equipo del código.
• prueba de caja blanca 白盒测试 — diseñada a partir de la estructura interna del código, cubriendo cada instrucción, rama y bucle.
• prueba de caja negra 黑盒测试 — diseñada únicamente a partir de la especificación: introduzca entradas y compruebe salidas.
• prueba de integración 集成测试 — combine módulos y pruebe las interfaces entre ellos.
• prueba alfa α测试 — realizada por los desarrolladores/interna antes del lanzamiento; prueba beta β测试 — realizada por un grupo limitado de usuarios reales en su propio entorno.
• prueba de aceptación 验收测试 — realizada por el cliente para decidir si el producto cumple su propósito.
• stub 桩 — un marcador de posición para un módulo que aún no existe, para poder probar la estructura de forma descendente.

¿Qué método, cuándo. Una prueba en seco y un recorrido no requieren computadora — la prueba en seco es cuando tú trazas el algoritmo con una tabla de trazado; el recorrido es una reunión en la que el autor explica el código línea por línea y los colegas buscan errores, por lo que también difunde el conocimiento del código entre el equipo y lo verifica contra el diseño. Las pruebas de caja blanca son escritas por alguien que puede ver el código y tiene como objetivo ejecutar todos los caminos; las pruebas de caja negra se escriben a partir de la especificación y verifican solo las entradas contra las salidas esperadas, por lo que un usuario o un probador separado pueden realizarlas. La prueba de integración sigue a la prueba de módulos: los módulos que pasan individualmente aún pueden fallar cuando los datos pasados entre ellos tienen el tipo incorrecto o están en el orden equivocado. La prueba alfa es interna; la prueba beta entrega un candidato a versión a una muestra de usuarios reales, quienes reportan errores desde su uso real; la prueba de aceptación es cuando el cliente verifica el producto terminado contra los requisitos antes de pagar por él. Un stub permite iniciar las pruebas de arriba hacia abajo antes de que exista cada módulo.

Ejemplo resuelto. Después de que el programa pasó sus pruebas internas, se le entregó a un grupo de usuarios para que lo probaran antes del lanzamiento. Nombra este tipo de prueba y establece qué sucede después.

Prueba beta — usuarios reales en su propio entorno, reportando errores que los desarrolladores no encontraron. Los errores se corrigen, luego el cliente lleva a cabo la prueba de aceptación contra los requisitos y se lanza el programa; los errores encontrados en uso en vivo son gestionados entonces mediante mantenimiento correctivo.

Ejemplo resuelto. Da tres beneficios de probar un programa mediante un recorrido.

Los errores son encontrados por personas que no escribieron el código y por lo tanto lo leen sin suposiciones; la lógica se verifica contra el diseño y la especificación, no solo contra los datos de prueba; varias personas aprenden cómo funciona el código, lo que ayuda en el mantenimiento posterior; y no se necesitan datos de prueba ni una computadora funcional, por lo que puede realizarse temprano.

Una estrategia de prueba es el enfoque de alto nivel — qué tipos de pruebas, quién las realiza, cuándo, y los criterios para avanzar. Un plan de prueba es la lista detallada de pruebas — cada una con datos de entrada, salida esperada y una columna para la salida real.

Qué contiene cada uno. Una estrategia de prueba indica qué métodos de prueba se usarán en qué etapa (pruebas de módulo por el programador, luego integración, alpha, beta, aceptación), quién es responsable de cada una, qué datos de prueba se requieren y los criterios para pasar a la siguiente etapa. Un plan de prueba enumera las pruebas individuales: para cada una, el módulo o función bajo prueba, los datos de entrada, la razón por la que se eligió el dato (normal, anormal, extremo, límite), el resultado esperado, un espacio para el resultado real y qué hacer si difieren. El plan se escribe en la etapa de diseño, basado en la especificación, para que pruebe lo que el programa debería hacer en lugar de lo que simplemente hace.

Elegir datos de prueba

Para cada campo o condición, incluye tres clases:

• datos normales — valores típicos dentro del rango válido (para calificaciones 0–100: 50, 75).
• datos anormales — valores que deberían ser rechazados (-10, 200, "abc").
• datos extremos — los valores más grandes y más pequeños que aún son aceptados (0 y 100).
• datos límite — valores en los bordes, donde se esconden los errores de "fuera de uno" (cada valor extremo aceptado y el valor rechazado justo fuera de él: 0/-1, 100/101).

Ejemplo resuelto. Un campo acepta una calificación de examen de 0 a 100. Da datos de prueba de cada clase con su resultado esperado. Normal: 50 - aceptado, un valor típico dentro del rango. Anormal: -10, 200, "abc" - todos rechazados, al estar fuera del rango o tener el tipo de datos equivocado. Extremo: 0 y 100 - el valor más grande y el más pequeño que aún son aceptados. Límite: los pares que cruzan cada borde - -1 rechazado junto con 0 aceptado, y 100 aceptado junto con 101 rechazado. Cada valor debe llevar su resultado esperado, de lo contrario el plan de prueba no demuestra nada. Extremo y límite son el par más confundido frecuentemente: un valor extremo se sitúa dentro y es aceptado, mientras que una prueba límite siempre es un par a ambos lados del borde - que es exactamente donde se esconden los errores de "fuera de uno".

Ejemplo resuelto. Un componente pasa si su peso, medido al gramo más cercano, está dentro de 3 g del objetivo de 50 g, es decir, de 47 g a 53 g inclusive. Prepara las filas del plan de prueba para la verificación.

Cada fila debe decir por qué se eligió el valor y qué debería ocurrir; una lista simple de números no obtiene puntos.

La mayor parte del costo de vida útil de un programa está en el mantenimiento. Tres clases:

• mantenimiento perfectivo — mejorar el rendimiento o características aunque funcione correctamente (una consulta más rápida, una nueva opción).
• mantenimiento adaptativo — mantenerlo funcionando en un entorno cambiante (un nuevo sistema operativo, una nueva API, un cambio legal).
• mantenimiento correctivo — corregir errores encontrados en uso.

Un programa puede necesitar los tres durante toda su vida.

Por qué se necesita cada uno — las razones que lista la rúbrica de calificación. Correctivo: se reporta un fallo por un usuario después del lanzamiento, o se nota una salida incorrecta en circunstancias particulares que las pruebas no cubrieron. Adaptativo: se actualiza el sistema operativo, el hardware o el navegador; cambia una ley o regla corporativa (tasas impositivas, requisitos de protección de datos); el programa debe funcionar con un nuevo sistema externo o formato de archivo. Perfectivo: los usuarios piden funciones adicionales o una mejor interfaz; se hace el programa más rápido o reduce el uso de memoria; se limpia el código para facilitar cambios futuros.

Ejemplo resuelto. (a) Un programa lanzado produce un valor incorrecto bajo ciertas circunstancias. (b) Se reemplaza el hardware que ejecuta un programa. (c) Los clientes solicitan que el programa de fidelidad de la cafetería envíe un mensaje en el cumpleaños del cliente. Nombra el tipo de mantenimiento en cada caso.

(a) Correctivo — se está corrigiendo un fallo en el programa entregado. (b) Adaptativo — el programa se modifica para ejecutarse en su nuevo entorno. (c) Perfectivo — se añade una función a un programa que ya funciona.

Cuando se pide agregar una función o corregir un error:

1. Lee el código existente hasta que comprendas el algoritmo y el flujo de datos.
2. Encuentra dónde va el cambio — en qué subrutina, en qué líneas.
3. Haz el cambio lo más pequeño posible — no reescribas código que funcione.
4. Actualiza las partes relacionadas — cada invocador de una lista de parámetros cambiada, cada rutina que use una estructura de datos modificada.
5. Prueba el nuevo comportamiento y el antiguo (pruebas de regresión 回归测试 — verifica que no has roto nada).
6. Documenta el cambio.

Comentarios claros, nombres significativos, subrutinas descompuestas y un diagrama de estructura hacen que un programa sea mucho más fácil de modificar — por eso importan las herramientas de diseño incluso después del primer lanzamiento.

Analizar un programa que no escribiste. Comienza con la tabla de identificadores y los encabezados de módulo: te dicen qué recibe y devuelve cada módulo antes de leer una sola línea de su cuerpo. Luego traza el algoritmo con una tabla de trazado para una entrada pequeña, tomando nota de dónde proviene cada valor de salida. Solo entonces decide dónde va la mejora — usualmente un nuevo módulo llamado desde el existente, para alterar el código funcional lo menos posible — y escribe el pseudocódigo para el cambio y los datos de prueba que lo demuestren.

Una pregunta de definición se califica según un texto fijo. Aprende estas definiciones exactamente, y da solo una respuesta.

• Compara los modelos de desarrollo (cascada, iterativo, RAD) por principio, beneficio, desventaja, y conoce las cinco etapas del ciclo de vida del desarrollo de programas y qué produce cada una.
• Distingue los errores sintácticos, lógicos y en tiempo de ejecución por cuándo se manifiestan: durante la traducción, en la salida, durante la ejecución.
• Elige datos de prueba de todo tipo — normales, anormales, extremos y límites — y proporciona el motivo y el resultado esperado para cada valor.
• Distingue los tipos de mantenimiento (correctivo, adaptativo, perfectivo) por por qué se realiza el cambio.
• En un diagrama de estructura, nombra cada símbolo: caja, línea de llamada, acople de datos, acople de control, diamante de selección, flecha de iteración. Al leer los encabezados de módulo de un diagrama, recuerda que una función tiene RETURNS.

Errores comunes

• Describir una etapa del ciclo de vida solo por su nombre ("en la etapa de diseño se diseña el programa"). Di qué se produce: diagrama de estructura, pseudocódigo, plan de pruebas.
• Lamar "error en tiempo de ejecución" a una salida incorrecta. Si el programa llega al final, es un error lógico.
• Dar datos límite solo como los extremos. La calificación requiere los valores en ambos lados del borde.
• Tratar las pruebas alpha y beta como si fueran lo mismo. Alpha es interna por parte de los desarrolladores; beta es por parte de usuarios reales externos.
• Confundir el mantenimiento adaptativo y perfectivo. El adaptativo responde a un cambio externo al programa; el perfectivo mejora un programa que nadie tuvo que cambiar.
• Dibujar un diagrama de estructura con los módulos en cualquier orden. Se leen de izquierda a derecha en el orden en que se invocan, y cada parámetro necesita su flecha.