1.7.-Proceso de desarrollo
1.7. Fases y modelos de desarrollo de software¶
Idea principal
Desarrollar software no consiste solo en programar. Es un proceso organizado que transforma una necesidad en un producto útil, probado, documentado y mantenible. Las fases son comunes; el modelo de desarrollo decide cómo se ordenan y se repiten.
Una aplicación de gestión de pedidos, por ejemplo, puede fallar aunque su código sea correcto si no resuelve la necesidad del negocio, no se prueba en condiciones realistas o no se puede mantener. La ingeniería del software aporta procesos, métodos y herramientas para reducir estos riesgos y obtener software útil, fiable, seguro, mantenible y sostenible.
El objetivo de este tema no es memorizar una lista de etapas o siglas, sino distinguir qué se hace en cada fase, qué resultados produce y cuándo conviene un enfoque secuencial o iterativo. Esta visión permite situar las herramientas estudiadas en la unidad y participar con criterio en un proyecto real.
Según la normativa del módulo Entornos de Desarrollo, este contenido contribuye al resultado de aprendizaje y a los criterios siguientes:
| Código | Descripción |
|---|---|
| RA 1 | Reconoce los elementos y herramientas que intervienen en el desarrollo de un programa informático, analizando sus características y las fases en las que actúan hasta llegar a su puesta en funcionamiento. |
| CE 1.b | Se han identificado las fases de desarrollo de una aplicación informática. |
| CE 1.g | Se han identificado las características y escenarios de uso de las metodologías ágiles de desarrollo de software. |
Qué deberías saber al terminar
Al acabar este apartado deberías poder:
- explicar el propósito y los resultados de las fases de un ciclo de vida del software;
- diferenciar análisis, diseño, codificación, pruebas, despliegue, explotación y mantenimiento;
- comparar los modelos en cascada, iterativo-incremental y en espiral;
- reconocer los valores ágiles y los elementos básicos de Kanban, XP y Scrum;
- proponer un modo de trabajo razonado para un proyecto sencillo.
Mapa del tema
Seguiremos esta secuencia:
- ciclo de vida y fases del desarrollo;
- modelos para organizar el proceso;
- enfoques ágiles: Manifiesto, Kanban y XP;
- Scrum como marco de trabajo ágil;
- criterios para elegir y aplicar un enfoque.
1. El ciclo de vida del desarrollo de software¶
Conceptos básicos
La ingeniería del software es la disciplina que aplica métodos, procesos, herramientas y conocimientos para especificar, diseñar, construir, probar, desplegar y mantener software. El proceso de desarrollo de software reúne las actividades realizadas desde que surge una necesidad hasta que el producto se retira.
Las fases no son compartimentos estancos. Una incidencia encontrada en producción puede obligar a revisar un requisito, cambiar el diseño, modificar el código y volver a probar. Además, la documentación y la gestión de la calidad acompañan a todo el ciclo.
1.1. Planificación inicial¶
Se delimita el problema: objetivos, alcance, personas implicadas, presupuesto, calendario, recursos y riesgos. También se realiza un estudio de viabilidad técnica, económica, legal y operativa. El resultado puede incluir una estimación, un plan de proyecto y una decisión fundamentada sobre si se inicia o no el trabajo.
Planificar no significa adivinar el futuro ni fijar un plan inamovible. Significa hacer explícitas las hipótesis y preparar cómo se revisarán cuando aparezca información nueva.
1.2. Análisis de requisitos: decidir qué construir¶
El análisis identifica y aclara las necesidades de las personas usuarias, del cliente y de otros grupos implicados. Su pregunta central es qué debe hacer el sistema, no cómo se programará. Una comunicación continua evita construir una solución técnicamente correcta para el problema equivocado.
Una especificación de requisitos de calidad debe ser completa, concisa, comprensible, verificable, priorizada y sin ambigüedades. Debe evitar adelantar decisiones de diseño y separar, al menos, estos tipos de requisitos:
| Tipo | Describe | Ejemplo en una tienda en línea |
|---|---|---|
| Funcional | Servicios y comportamientos del sistema. | Registrar clientes, añadir productos al carrito y emitir facturas. |
| No funcional | Restricciones y atributos de calidad. | Responder en menos de dos segundos, proteger pagos y cumplir la normativa aplicable. |
| De información | Datos de entrada necesarios y salidas que se ofrecerán. | Guardar existencias y mostrar el estado de cada pedido. |
El resultado habitual es la Especificación de Requisitos del Software (ERS). Puede recoger objetivos, alcance, requisitos, prioridades, criterios de aceptación, calendario de revisiones y contradicciones resueltas. Es una base de acuerdo entre quien encarga el producto y quien lo desarrolla, no un documento que sustituya la comunicación.
De una petición vaga a requisitos comprobables
Ante «necesito una aplicación para pedir comida», el equipo no debería empezar por elegir un lenguaje. Primero concreta, por ejemplo: «Una persona registrada puede añadir productos de un restaurante a un carrito y confirmar el pago». Después añade condiciones: «El pago no almacenará datos de tarjeta» y «el catálogo se mostrará en menos de dos segundos con la carga prevista». Así será posible diseñar, probar y aceptar el resultado.
1.3. Diseño: decidir cómo construirlo¶
Una vez conocido el qué, el diseño define el cómo: divide el sistema en componentes, establece sus relaciones y concreta las decisiones técnicas. Incluye diseño arquitectónico, detallado, de datos, de interfaces y, cuando procede, de seguridad e integración.
En esta fase se pueden decidir las entidades y relaciones de la base de datos, las interfaces de una API, las tecnologías, los módulos y las reglas de interacción. Sus resultados suelen ser el documento de arquitectura y las especificaciones de módulos, funciones, datos e interfaces. Un buen diseño sirve de guía para codificar, probar y mantener; no obliga a conservar una decisión que la evidencia posterior haya demostrado inadecuada.
1.4. Codificación o implementación¶
La codificación transforma el diseño y los algoritmos en código fuente. El equipo programa componentes, integra dependencias y utiliza compiladores, intérpretes, control de versiones, analizadores y automatización de construcción. En esta unidad ya se ha visto que el código puede pasar por estados como fuente, objeto y ejecutable o bytecode.
Un código profesional debe aspirar a estas características:
- Modularidad: separa responsabilidades en componentes manejables.
- Corrección: cumple los requisitos y criterios de aceptación acordados.
- Legibilidad: usa nombres expresivos, estructura coherente y convenciones compartidas.
- Eficiencia: utiliza los recursos de forma proporcionada a las necesidades reales.
- Portabilidad: puede ejecutarse o adaptarse a los entornos previstos.
El resultado principal es código fuente integrado y preparado para ser verificado; «haber terminado de programar» no equivale a haber terminado el producto.
1.5. Pruebas: buscar evidencias y defectos¶
Las pruebas buscan descubrir defectos y aportar evidencia de que el software satisface los requisitos. No pueden demostrar que no exista ningún error, pero sí reducen la incertidumbre al ejecutar casos relevantes y contrastar resultados esperados.
| Tipo de prueba | Alcance y finalidad |
|---|---|
| Unitaria | Verifica una función, método o clase de forma aislada. |
| Integración | Comprueba la colaboración entre componentes, servicios o bases de datos. |
| Funcional o de sistema | Valida comportamientos completos frente a los requisitos. |
| Estructural | Examina aspectos técnicos, como rutas de código, carga, rendimiento o seguridad. |
| Aceptación o beta | Personas usuarias o cliente validan el producto en un entorno realista antes o durante su adopción. |
Tras las pruebas unitarias se obtienen componentes verificadas; tras las de integración, un sistema integrado; y tras la aceptación, evidencia para decidir su puesta en servicio. Las pruebas se desarrollarán con mayor profundidad en unidades posteriores.
1.6. Documentación¶
La documentación conserva el conocimiento necesario para usar, desplegar, modificar y mantener el producto. Debe actualizarse junto con el software: un manual perfecto que describe una versión anterior resulta perjudicial.
- Guía técnica: para personal de desarrollo y mantenimiento; explica arquitectura, código, pruebas, configuración y decisiones relevantes.
- Guía de uso: para personas usuarias; explica funciones, primeros pasos y ejemplos de uso.
- Guía de instalación o despliegue: para quien implanta la aplicación; recoge requisitos, configuración, pasos y solución de incidencias habituales.
La documentación facilita la reutilización, el trabajo en equipo y el mantenimiento. No se opone a los enfoques ágiles: estos priorizan documentación útil y actualizada frente a documentación extensa que no aporta valor.
1.7. Despliegue y explotación¶
El despliegue instala, configura y verifica la aplicación en la infraestructura donde funcionará. Puede incluir migraciones de datos, configuración de secretos, monitorización, copias de seguridad y un plan de reversión. La explotación comienza cuando las personas usuarias emplean el sistema en su contexto real.
Conviene formar y acompañar a las personas usuarias, verificar el comportamiento con cargas realistas y recoger incidencias. Una prueba beta puede aportar información valiosa, pero no debe convertirse en una excusa para desplegar sin controles ni sin un plan de soporte.
1.8. Mantenimiento¶
El mantenimiento suele ocupar la mayor parte de la vida del software. Abarca el control, la mejora y la adaptación del producto después de su puesta en servicio.
| Tipo | Finalidad | Ejemplo |
|---|---|---|
| Correctivo | Corregir un defecto. | Evitar que una cantidad negativa cierre la aplicación. |
| Perfectivo | Mejorar una función existente o su calidad. | Reducir el tiempo de carga del catálogo. |
| Evolutivo | Incorporar necesidades nuevas. | Añadir cupones de descuento. |
| Adaptativo | Ajustarse a un cambio externo. | Adaptar el sistema a una nueva normativa o versión de una plataforma. |
Los informes de errores, las solicitudes de cambio y el historial de versiones son resultados esenciales de esta fase.
1.9. Retirada del software¶
Un producto llega al final de su vida útil cuando mantenerlo o ampliarlo deja de ser viable o rentable. Retirarlo de forma responsable implica comunicar el cierre, migrar o conservar los datos que correspondan, desactivar servicios y proteger la información. Con frecuencia, la necesidad que cubría inicia un nuevo ciclo mediante la adquisición o el desarrollo de una solución sustituta.
2. Modelos de desarrollo de software¶
Un modelo de desarrollo es un marco para planificar, organizar y controlar las fases anteriores. No hay un modelo universalmente mejor: la elección depende de la estabilidad de los requisitos, el riesgo, el tamaño del equipo, la regulación, el presupuesto y la necesidad de obtener feedback temprano.
2.1. Modelo en cascada¶
El modelo en cascada organiza el trabajo en fases predominantemente secuenciales: análisis, diseño, implementación, pruebas y entrega. Es útil cuando los requisitos son muy estables, el alcance está bien definido o existen exigencias formales de documentación y aprobación.
- Cascada rígida: apenas contempla volver a una fase previa. Es difícil de aplicar en proyectos reales porque los requisitos y el conocimiento técnico cambian.
- Cascada con realimentación: permite revisar fases anteriores cuando aparece un error o cambio. Reduce la rigidez, aunque volver atrás puede ser costoso si se descubre tarde.
No confundir secuencia con ausencia de comunicación
Que un proyecto tenga fases ordenadas no justifica esperar al final para mostrar resultados. Validar requisitos y prototipos de forma temprana reduce el riesgo de rehacer trabajo.
2.2. Modelos evolutivos¶
Los modelos evolutivos construyen una versión inicial, la exponen a evaluación y la refinan en sucesivas versiones. La especificación, el desarrollo y las pruebas se repiten; por tanto, el feedback llega antes que en una entrega única al final.
2.2.1. Modelo iterativo e incremental¶
El trabajo se organiza en periodos breves llamados iteraciones. Cada una funciona como un miniproyecto: selecciona requisitos priorizados, los analiza, diseña, implementa, prueba, documenta y deja un resultado potencialmente entregable.
- Incremental: cada entrega añade nuevas capacidades completas al producto.
- Iterativo: cada entrega revisa y mejora capacidades existentes a partir del feedback.
Por ejemplo, una primera iteración de una tienda puede entregar registro e inicio de sesión completos; la siguiente, catálogo y carrito; y una tercera, pago. No consiste en programar un 10 % de cada módulo: eso no entrega una funcionalidad que se pueda usar ni validar. Priorizar por valor y riesgo permite abordar antes lo más importante.
2.2.2. Modelo en espiral¶
Propuesto por Barry Boehm, el modelo en espiral combina la repetición de versiones con un análisis explícito de riesgos. En cada vuelta se realizan estas actividades:
- Determinar objetivos y alternativas de la iteración.
- Analizar y reducir riesgos, a menudo mediante prototipos.
- Desarrollar y validar la solución elegida.
- Revisar y planificar la siguiente vuelta.
Es adecuado para proyectos complejos y con riesgos importantes, pero requiere experiencia para identificar, evaluar y gestionar esos riesgos.
3. Metodologías ágiles¶
Las metodologías ágiles agrupan enfoques que favorecen la colaboración, la entrega frecuente de valor y la adaptación al cambio. Son especialmente útiles cuando existe incertidumbre y se puede involucrar a quienes conocen las necesidades del producto. No eliminan planificación, diseño, pruebas ni documentación: los realizan de forma continua y proporcionada.
3.1. Valores y principios del Manifiesto Ágil¶
El Manifiesto Ágil valora más:
- los individuos y las interacciones que los procesos y las herramientas;
- el software funcionando que la documentación extensiva;
- la colaboración con el cliente que la negociación contractual;
- la respuesta al cambio que seguir un plan.
La parte situada a la derecha conserva valor. Por ejemplo, el software necesita documentación útil, pero no conviene retrasar una validación importante solo para producir documentación que quedará obsoleta.
Sus doce principios desarrollan estas prioridades: satisfacer mediante entregas tempranas y continuas; aceptar cambios; entregar software funcional frecuentemente; colaborar a diario con negocio; apoyar a personas motivadas; favorecer la comunicación directa; medir el progreso con software funcionando; mantener un ritmo sostenible; cuidar la excelencia técnica y el buen diseño; simplificar; permitir que equipos capaces se autoorganicen; y reflexionar periódicamente para mejorar.
3.2. Kanban¶
Kanban visualiza el flujo de trabajo en un tablero, por ejemplo: «Pendiente», «En curso», «En pruebas» y «Terminado». Surgió en la industria de Toyota y aplica ideas lean para entregar valor evitando acumulaciones y esperas.
Un mecanismo importante es limitar el trabajo en curso (Work In Progress, WIP). Si hay un máximo de tres tareas «En curso», el equipo debe terminar o desbloquear una antes de iniciar otra. Esto reduce el cambio de contexto y hace visibles los cuellos de botella. Kanban no exige sprints: puede aplicarse a un flujo continuo.
3.3. XP o eXtreme Programming¶
XP es un enfoque ágil orientado a la calidad técnica. Se apoya en simplicidad, comunicación, retroalimentación, coraje y respeto. Entre sus prácticas destacan el diseño sencillo, mejoras pequeñas y continuas, pruebas automatizadas, refactorización, integración continua, estándares de código, propiedad colectiva del código y programación por parejas.
La programación por parejas no consiste en que dos personas repitan mecánicamente el mismo trabajo: una puede escribir mientras la otra revisa, plantea alternativas y detecta problemas; ambas intercambian papeles. Requiere acordar cuándo aporta valor —por ejemplo, en tareas complejas, críticas o formativas— y cuándo una tarea individual resulta suficiente.
4. Scrum: un marco de trabajo ágil¶
Scrum es un marco de trabajo ligero para ayudar a equipos a generar valor ante problemas complejos. Se basa en el empirismo: tomar decisiones a partir de lo observado. Sus pilares son transparencia, inspección y adaptación. Facilita reducir el tiempo de llegada al mercado y validar un producto mínimo viable (MVP), pero no garantiza por sí solo el éxito ni sustituye las prácticas técnicas.
Scrum se popularizó en la década de 1990 a partir del trabajo de Jeff Sutherland y Ken Schwaber; no debe confundirse con el Manifiesto Ágil, publicado en 2001. Comparte con el agilismo la importancia de estos cinco valores: compromiso con los objetivos, foco en el trabajo del Sprint, apertura sobre el progreso y los problemas, respeto entre las personas del equipo y coraje para afrontar decisiones difíciles.
4.1. El Equipo Scrum y sus responsabilidades¶
El Equipo Scrum es un equipo pequeño, autoorganizado y multifuncional. Incluye tres responsabilidades:
| Responsabilidad | Aportación principal |
|---|---|
| Product Owner | Maximiza el valor del producto y ordena el Product Backlog. |
| Scrum Master | Ayuda a que Scrum se entienda y se aplique; elimina impedimentos y mejora la efectividad del equipo. No es el jefe del equipo. |
| Developers | Crean el Incremento, deciden cómo realizar el trabajo y adaptan su plan cada día. |
El Product Owner puede representar las necesidades de múltiples personas interesadas, pero la responsabilidad de ordenar el Product Backlog es única y clara. Los Developers no tienen por qué ser solo programadores: pueden incluir perfiles de prueba, análisis, diseño o cualquier especialidad necesaria para producir un incremento de valor.
4.2. Sprints y eventos¶
El Sprint es un periodo de duración fija, de un mes o menos, que contiene el trabajo necesario para crear valor. Un nuevo Sprint empieza inmediatamente después del anterior. Durante él no se realizan cambios que pongan en peligro el Sprint Goal; el alcance puede aclararse y renegociarse con el Product Owner a medida que se aprende.
| Evento | Propósito |
|---|---|
| Sprint Planning | Definir por qué es valioso el Sprint, qué se puede hacer y cómo se realizará. Produce el Sprint Goal y un plan inicial. |
| Daily Scrum | Inspección diaria de los Developers para adaptar el plan hacia el Sprint Goal. Está limitado a 15 minutos. |
| Sprint Review | Inspeccionar el Incremento con las personas interesadas y adaptar el Product Backlog según el feedback. |
| Sprint Retrospective | Mejorar la calidad y la efectividad del trabajo del equipo antes del siguiente Sprint. |
El refinamiento del Product Backlog es una actividad continua, no un evento formal de Scrum. Sirve para descomponer y aclarar elementos, estimarlos y ordenarlos. Es recomendable reservar tiempo para ello, sin imponer una cifra universal.
Sobre la Daily Scrum
Las preguntas «¿qué hice ayer?, ¿qué haré hoy?, ¿qué impedimentos tengo?» son una técnica útil, no una obligación de Scrum. Lo importante es que los Developers inspeccionen el progreso hacia el Sprint Goal y adapten su plan. Los debates que afecten solo a parte del equipo se continúan después.
4.3. Artefactos y compromisos¶
Los artefactos hacen visible el trabajo y el valor. Cada uno tiene un compromiso que aumenta la transparencia:
| Artefacto | Qué contiene | Compromiso |
|---|---|---|
| Product Backlog | Lista emergente y ordenada de lo necesario para mejorar el producto. | Product Goal: estado futuro que el producto pretende alcanzar. |
| Sprint Backlog | Elementos seleccionados, Sprint Goal y plan de trabajo de los Developers. | Sprint Goal: objetivo único que da foco al Sprint. |
| Incremento | Parte usable del producto que cumple la Definition of Done. | Definition of Done: criterios compartidos para considerar un trabajo terminado. |
El Sprint Backlog evoluciona durante el Sprint porque los Developers aprenden y ajustan el plan. No es correcto añadir trabajo unilateralmente ni declarar terminada una tarea que no cumple la Definition of Done. Si el Sprint Goal deja de tener sentido, el Product Owner puede cancelar el Sprint.
4.4. Ventajas, límites y escenarios de uso de Scrum¶
Scrum favorece entregas frecuentes, feedback temprano, visibilidad del progreso y adaptación en proyectos con requisitos cambiantes. Es especialmente valioso cuando la solución no se conoce por completo al inicio y se puede colaborar con las personas interesadas.
También exige una cultura de colaboración, transparencia y mejora continua. Puede fallar si se usa como una lista de reuniones sin producto entregable, si el Product Owner no puede ordenar el trabajo, si se interrumpe continuamente al equipo o si se descuidan pruebas, integración y calidad técnica. Cuando los requisitos son muy estables, el trabajo es predecible o una regulación exige fases formales, un enfoque secuencial o híbrido puede ser más adecuado.
5. Elegir y aplicar un enfoque con criterio¶
Para decidir cómo organizar un proyecto, conviene seguir un razonamiento explícito:
- Analizar el contexto: estabilidad de requisitos, riesgos técnicos, regulación, presupuesto, equipo y necesidad de entrega temprana.
- Elegir el modelo: cascada para contextos estables y muy formalizados; iterativo-incremental o Scrum cuando el feedback y la adaptación aporten valor; espiral ante riesgos relevantes que requieren análisis específico.
- Definir qué significa terminado: acordar criterios de calidad, pruebas, documentación y condiciones de despliegue antes de iniciar una entrega.
- Recoger evidencia y mejorar: usar el feedback de pruebas, personas usuarias y métricas del flujo para adaptar el producto y la forma de trabajar.
Decisión para una aplicación de reservas
Una empresa quiere una aplicación de reservas, pero aún desconoce qué funciones valorarán más sus clientes. Un enfoque iterativo con Sprints de dos semanas puede entregar primero búsqueda y reserva básica, recoger feedback y priorizar pagos o cancelaciones después. Cada incremento debe estar probado, documentado en lo necesario y ser desplegable; no basta con mostrar pantallas sin funcionamiento real.
6. Buenas prácticas¶
- Validar pronto los requisitos: usar ejemplos, prototipos y criterios de aceptación para reducir interpretaciones distintas.
- Entregar incrementos realmente utilizables: incluir pruebas, integración, documentación necesaria y condiciones de despliegue en la Definition of Done.
- Priorizar por valor y riesgo: abordar antes lo que aporta más utilidad o puede comprometer el proyecto.
- Mantener documentación viva: actualizar guías, decisiones y procedimientos al cambiar el producto.
- Inspeccionar y adaptar con datos: convertir incidencias, pruebas y feedback en mejoras concretas, no en reuniones sin consecuencias.
7. Errores frecuentes¶
| Error frecuente | Por qué ocurre | Cómo evitarlo |
|---|---|---|
| Empezar a programar con requisitos vagos. | Se confunde velocidad inicial con progreso real. | Acordar requisitos, prioridades y criterios de aceptación antes de implementar. |
| Confundir análisis con diseño. | Ambos se realizan antes de codificar. | Recordar: análisis responde al «qué»; diseño, al «cómo». |
| Considerar terminado un incremento sin pruebas o documentación necesaria. | Se mide solo el código escrito. | Definir y aplicar una Definition of Done compartida. |
| Interpretar «ágil» como «sin planificación ni documentación». | Se simplifican los valores del Manifiesto Ágil. | Planificar y documentar de forma continua, útil y proporcionada. |
| Usar Scrum como un conjunto rígido de reuniones. | Se ignoran el Sprint Goal, la transparencia y la mejora. | Revisar el valor entregado y adaptar el proceso al contexto respetando el marco. |
8. Resumen¶
En este tema has aprendido que:
- el ciclo de vida incluye planificación, análisis, diseño, codificación, pruebas, documentación, despliegue, explotación, mantenimiento y retirada;
- el análisis define qué necesidad se resuelve y el diseño concreta cómo se construirá la solución;
- los modelos en cascada, evolutivo e iterativo-incremental organizan las fases de forma diferente, y el modelo en espiral pone el foco en el riesgo;
- las metodologías ágiles favorecen colaboración, entregas frecuentes y adaptación, sin renunciar a la calidad ni a la documentación útil;
- Scrum organiza el trabajo empírico mediante Sprints, responsabilidades, eventos, artefactos y compromisos transparentes.
Idea clave
Una metodología no sustituye el trabajo técnico: ayuda a organizarlo. El valor aparece cuando el equipo entiende la necesidad, entrega software que cumple criterios de calidad y aprende del feedback para mejorarlo.
9. Para seguir practicando¶
- Realiza la Práctica 003: Aplica Scrum elaborando un Product Backlog, un Sprint Goal y un Sprint Backlog para el juego de bingo.
- Elige una aplicación que conozcas e identifica un requisito funcional, uno no funcional y una posible tarea de mantenimiento de cada tipo.
Bibliografía y fuentes¶
- Manifiesto por el Desarrollo Ágil de Software.
- The Scrum Guide (2020), Ken Schwaber y Jeff Sutherland.
- Kanban Guide, Kanban Guides.
- Boehm, B. W. (1988). «A Spiral Model of Software Development and Enhancement», Computer.