Resumen Ingeniería Software: Fundamentos y Calidad

RESUMEN PRIMER PARCIAL INGENIARIA SW
LIBRO DE SOMMERVILLE CAP 1 Y BRIANO APUNTE 1
El papel del software en el mundo moderno
Es imposible operar el mundo moderno sin software. Esto se debe a que las infraestructuras nacionales y los
servicios públicos son controlados mediante sistemas basados en computadoras, y la mayoría de los productos
eléctricos incluyen una computadora y un software de control. Por lo tanto, la ingeniería de software es
fundamental para que las sociedades funcionen, tanto a nivel nacional como internacional.
La naturaleza abstracta del software
Los sistemas de software son intangibles, es decir, no tienen una forma física y no están sujetos a las mismas reglas
que los objetos materiales o las leyes de la física. Esto hace que la ingeniería de software sea más flexible, porque no
hay limitaciones físicas. Sin embargo, esta falta de restricciones también puede hacer que los sistemas de software
sean más complejos, difíciles de comprender y caros de modificar
Causas de las fallas en los proyectos de software
A pesar de los avances en ingeniería de software, todavía ocurren muchos fallos en los proyectos. Según el autor,
estos fallos se deben a dos razones principales:
1. Demandas crecientes: Con el tiempo, los sistemas necesitan ser más grandes, más complejos y construidos
más rápido. Las técnicas actuales de ingeniería de software no siempre son suficientes para cumplir con
estas nuevas demandas, lo que hace necesario desarrollar nuevas técnicas.
2. Expectativas bajas: Muchas empresas no usan los métodos adecuados de ingeniería de software, lo que
resulta en productos más caros y menos confiables. Para evitar estos problemas, es importante mejorar la
educación y la capacitación en ingeniería de software
Desarrollo de software profesional
En desarrollo profesional de software, los programas no se escriben solo para una persona, sino para que otras
personas los usen y cambien. Por eso, además de escribir el código, es esencial desarrollar documentación, guías de
usuario y archivos de configuración para asegurar que el sistema funcione correctamente.
Tipos de productos de software
Existen dos tipos principales de productos de software:
1. Productos genéricos: Son sistemas desarrollados para un mercado abierto. Ejemplos incluyen bases de
datos, procesadores de texto, y sistemas de contabilidad. Estos productos se venden en el mercado y están
destinados a cualquier cliente.
2. Productos personalizados: Son desarrollados específicamente para un cliente en particular. Ejemplos
incluyen sistemas de control para dispositivos electrónicos o sistemas que apoyan procesos empresariales
específicos, como el control de tráfico aéreo.
La calidad del software
1
La calidad del software no se refiere solo a su funcionalidad, sino también a cómo se comporta el software durante
su ejecución y a la estructura y organización de su código y documentación. Algunos atributos importantes del
software incluyen:




Mantenimiento: El software debe poder evolucionar para adaptarse a las necesidades cambiantes.
Confiabilidad y seguridad: El software debe ser confiable, seguro y no causar daño en caso de fallos.
Eficiencia: El software debe utilizar los recursos del sistema (como memoria y procesamiento) de manera
eficiente.
Aceptabilidad: El software debe ser comprensible y fácil de usar para los usuarios.
Necesidad de Formalización (Crisis del software)
Los métodos informales eran efectivos en proyectos pequeños, pero inadecuados para sistemas grandes. Se
dependía de programadores autodidactas, sin estandarización. La solución: un enfoque disciplinado y estructurado.
Era esencial:




Profesionalizar el desarrollo.
Aplicar principios de ingeniería.
Crear estándares y metodologías.
Formar profesionales especializados.
Así nació la Ingeniería de Software, una disciplina que abarca:




Diseño
Implementación
Pruebas
Mantenimiento
Todo para asegurar calidad y manejar la complejidad.
Ingeniería de software
La ingeniería de software es una disciplina de ingeniería que se enfoca en todos los aspectos de la producción de
software, desde la especificación hasta el mantenimiento del sistema después de que está en operación.
Se destacan dos puntos clave de la ingeniería de software:
1. Disciplina de ingeniería: Los ingenieros aplican teorías, métodos y herramientas para resolver problemas
prácticos, teniendo en cuenta limitaciones organizacionales y financieras.
2. Todos los aspectos de la producción del software: Esto incluye gestión de proyectos, desarrollo de
herramientas, y la teoría y métodos que apoyan el proceso.
La ingeniería de software busca obtener productos de alta calidad dentro del tiempo y presupuesto establecidos, lo
que a menudo implica hacer compromisos.
Proceso de software
El proceso de software es un conjunto de actividades que conducen a la creación de un producto de software. Las
actividades clave son:
1. Especificación del software: El cliente y los ingenieros definen lo que el software debe hacer y sus
restricciones.
2. Desarrollo del software: Se diseña y programa el software.
3. Validación del software: Se verifica que el software cumpla con los requisitos del cliente.
2
4. Evolución del software: El software se modifica para adaptarse a los cambios en las necesidades del cliente
o el mercado.
Existen tres desafíos comunes en el desarrollo de software:
1. Heterogeneidad: El software debe poder operar en sistemas distribuidos que incluyan diferentes tipos de
computadoras y dispositivos. Además, debe integrarse con sistemas antiguos y nuevos.
2. Cambio empresarial y social: Los negocios y la sociedad cambian rápidamente, y el software debe
evolucionar de acuerdo con estos cambios.
3. Seguridad y confianza: El software debe ser confiable, especialmente en sistemas remotos a los que se
accede a través de la web.
Estos desafíos requieren nuevas herramientas y técnicas de ingeniería de software para asegurar que los sistemas
sean confiables, seguros y fáciles de adaptar a los cambios.
Diversidad de la ingeniería de software
La ingeniería de software es un enfoque sistemático para crear software, considerando costo, fecha de entrega,
confiabilidad y las necesidades de clientes y fabricantes de software. No existen métodos universales, ya que varían
según la organización, el tipo de software y las personas involucradas.
El tipo de aplicación que se desarrolla es clave para determinar las técnicas que se utilizarán. Aunque hay diferencias
entre estos sistemas, comparten fundamentos comunes de ingeniería de software:
Principios fundamentales:
1.
2.
3.
4.
Proceso de desarrollo claro y administrado.
Confiabilidad y desempeño son esenciales.
Gestión de requisitos para satisfacer las expectativas de los usuarios.
Reutilización de software existente cuando sea posible.
Estos principios son fundamentales para el desarrollo profesional del software, independientemente del tipo de
sistema.
Ética en la ingeniería de software
La ingeniería de software implica responsabilidades éticas más allá de las habilidades técnicas. Los ingenieros deben
actuar con honestidad e integridad, y respetar normas como:
1.
2.
3.
4.
Confidencialidad: Mantener la información privada de clientes y empleadores.
Competencia: No aceptar trabajos fuera de sus capacidades.
Propiedad intelectual: Respetar las leyes de patentes y derechos de autor.
Mal uso de computadoras: No usar sistemas ajenos de manera indebida.
En resumen, la ética en ingeniería de software no solo implica habilidades técnicas, sino también tomar decisiones
responsables en situaciones complejas.
La Naturaleza del Software
En su libro “Ingeniería de Software, un enfoque práctico”, Roger Pressman explica por qué el desarrollo de software
es diferente de la fabricación de productos tradicionales. Estas diferencias son clave para entender por qué no
siempre se pueden aplicar métodos clásicos al mundo del software.
1. El Software se Desarrolla con el Intelecto: El software no se fabrica como los productos físicos, sino que se
desarrolla mediante el intelecto humano. A diferencia de la industria tradicional, que usa materias primas y procesos
industriales, el software se construye a partir de ideas, lógica y código.
3


En productos físicos, un defecto puede hacer que el producto final no sirva.
En software, los errores pueden corregirse sin desechar todo el producto.
2. El Costo se Calcula de Forma Diferente: En productos físicos, el costo incluye: Materia prima + Mano de obra +
Fabricación. En software, el costo está en:


Los recursos humanos (desarrolladores)
El tiempo de desarrollo
La primera copia de un software puede ser costosa, pero hacer más copias cuesta En proyectos personalizados, el
cliente paga todo el costo. Si el software se revende después, casi todo es ganancia.
3. Se Avanza hacia la Reutilización de Componentes: En software, también se pueden reutilizar componentes
(bibliotecas, módulos, interfaces), lo que permite:



Ahorro de tiempo
Menos errores
Enfoque en lo novedoso
Aunque todavía muchos proyectos se hacen desde cero, usar componentes reutilizables mejora la eficiencia y la
calidad del producto.
Los componentes de software siempre funcionan como nuevos y suelen estar probados y optimizados, lo que los
hace incluso mejores que desarrollos nuevos.
El Software No se Desgasta
A diferencia del hardware, el software no se desgasta con el tiempo. No se ve afectado por factores físicos. Para
entender esto mejor, vamos a analizar el siguiente gráfico.
Explicación del Gráfico: La Curva de la Bañera
Esta curva muestra cómo es la tasa de fallas del hardware a lo largo del tiempo. Su forma característica se parece a
una bañera
Partes de la curva:
1. Fallos iniciales (Izquierda, parte alta de la curva): Ocurren al principio de la vida del hardware. Se deben a
defectos de diseño o fabricación. Ejemplo: un chip mal soldado falla apenas se empieza a usar.
4
2. Fallos normales o constantes (Parte baja, plana de la curva): Una vez corregidos los problemas iniciales, la
tasa de fallas se estabiliza. Durante esta fase, el hardware funciona correctamente. Se llama también vida
útil.
3. Fallos de desgaste (Derecha, parte alta de la curva): Después de mucho uso, el hardware comienza a
deteriorarse. La tasa de fallas vuelve a aumentar.
¿Qué pasa con el Software?
A diferencia del hardware:



El software no tiene partes físicas, por lo tanto, no sufre desgaste.
Si se instala en una máquina nueva, funcionará igual que siempre, e incluso mejor.
No le afectan el tiempo ni el uso, a menos que tenga errores lógicos (que no dependen del "desgaste").
Conclusión:


El hardware se deteriora con el tiempo, el software no.
Lo único que puede afectar al software son los errores humanos durante su desarrollo, pero no se desgasta
con el uso.
Tasa de Error en el Software a lo Largo del Tiempo
El software, aunque no se desgasta como el hardware, puede presentar fallas al principio de su uso. Estas fallas
están relacionadas con errores de programación que no fueron detectados durante las pruebas. Sin embargo, a
diferencia del hardware, una vez que se corrigen estos errores, el software puede funcionar indefinidamente sin
fallas nuevas.
Explicación del Gráfico: Tasa de Error del Software
Este gráfico muestra la tasa de error (en el eje vertical) del software a medida que pasa el tiempo (eje horizontal).
Partes de la curva:
1. Inicio: Alta tasa de error: Al principio, el software puede tener muchos errores no detectados durante las
pruebas.Estos errores causan fallas frecuentes cuando el software empieza a utilizarse.
2. Corrección de errores: Disminución rápida: A medida que se detectan y corrigen estos errores, la tasa de
fallas baja rápidamente. Esta etapa es clave para mejorar la estabilidad del software.
5
3. Fase estable: Tasa de error constante y baja: Después de corregir los errores principales, el software entra
en una etapa donde funciona correctamente. La tasa de fallas se mantiene plana y baja. Esta situación
puede durar indefinidamente mientras el software no se modifique.
Cambios en el Software y Nuevas Fallas
Aunque el software no se desgasta, sí puede sufrir cambios y actualizaciones durante su vida útil. Estos cambios
hacen que se introduzcan nuevos errores, por lo tanto, la tasa de error aumenta temporalmente después de cada
modificación.
Explicación del Gráfico: Curva Real vs Curva Ideal
Este gráfico muestra dos curvas que representan cómo varía la tasa de error a lo largo del tiempo, dependiendo de
si el software sufre cambios o no.
1. Curva Ideal (línea inferior recta): Representa lo que pasaría si el software no se modificara nunca. Luego de
corregir los errores iniciales, la tasa de error baja y se mantiene constante y baja por siempre. Es la situación ideal,
pero rara vez ocurre.
2. Curva Real (línea con subidas y bajadas): Refleja lo que realmente sucede cuando se hacen cambios al software.
Cada vez que se hace un cambio (actualización, mejora, nueva versión), se introducen errores colaterales. Esto hace
que la tasa de error aumente bruscamente justo después del cambio.
Proceso tras cada cambio:
1.
2.
3.
4.
Se introduce un cambio → Aparecen errores nuevos → La tasa de error sube.
Se corrigen esos errores → La tasa de error baja nuevamente.
Se repite este ciclo cada vez que se modifica el software.
Como consecuencia, a largo plazo, la tasa de error tiende a aumentar si no se tiene cuidado.
Conclusión Clave


Aunque el software no se desgasta, sí puede empeorar si se realizan muchos cambios sin control.
Cada cambio puede generar errores nuevos, que requieren tiempo y recursos para ser corregidos.
Desafíos en el Desarrollo de Software
1) Tiempo de Desarrollo Largo: El desarrollo de software no tiene un tiempo exacto. Es un proceso complejo, y a
menudo toma más tiempo del esperado. Esto ocurre porque los proyectos de software son muy variados y no
siempre se pueden predecir con exactitud los tiempos de entrega.
6
2) Estimación de Costos y Plazos: Calcular el costo y el plazo de un proyecto de software es complicado. Los cambios
inesperados durante el proceso, como nuevas características o necesidades no previstas, pueden alterar tanto el
presupuesto como el tiempo de entrega original.
3) Medición del Progreso: Es difícil medir el avance de un proyecto de software mientras se desarrolla. La naturaleza
intangible del software y las interacciones entre sus diferentes partes hacen que no sea fácil ver cuán avanzado está
realmente el proyecto.
4) Altos Costos de Desarrollo: Los costos de desarrollar software suelen ser mucho mayores a los inicialmente
planeados. A veces, se presenta un presupuesto sin tener toda la información necesaria para calcular los costos de
manera precisa, lo que puede llevar a sorpresas en el camino.
5) Errores Imposibles de Eliminar Completamente: Aunque se realicen pruebas exhaustivas, nunca se puede
garantizar que el software esté completamente libre de errores. Siempre existe la posibilidad de que algunos
problemas se escapen, y esto es un desafío constante en el desarrollo de software.
6) Mantenimiento Costoso: Una vez entregado el software, gran parte del esfuerzo se destina a su mantenimiento.
Se estima que entre el 60% y el 80% del tiempo y recursos dedicados al software ocurren después de que se entrega
al cliente, ya sea para solucionar problemas o mejorar funcionalidades.
7) Expectativas de los Clientes: Los clientes suelen esperar que el software se entregue en plazos muy cortos, a veces
incluso más rápidos de lo que es posible. Esto genera presión sobre los equipos de desarrollo, que deben cumplir con
plazos muy ajustados.
El Software como Ventaja Competitiva
El software es el componente que puede generar una verdadera ventaja competitiva. A diferencia del hardware y las
redes, que son fácilmente accesibles para cualquier empresa, el software puede ser personalizado para ofrecer algo
único que los competidores no pueden replicar.
La Cadena de Valor y la Ventaja Competitiva
Michael Porter propuso que las actividades de una empresa deben agregar más valor al producto final de lo que
cuesta realizarlas. Esto ayuda a obtener una ventaja competitiva, que puede lograrse mediante:
1. Reducción de costos
2. Diferenciación del producto
El software juega un papel fundamental en ambos enfoques, ya que permite optimizar procesos, reducir costos y
ofrecer productos únicos.
¿Qué Genera una Ventaja Competitiva?



Hardware: No es un diferenciador importante, ya que es un commodity y accesible para todos.
Redes de Comunicación: También son similares entre competidores.
Software: Aquí es donde se puede marcar la diferencia. Un software a medida o bien implementado puede
ofrecer un valor único, como en el caso de empresas que personalizan servicios como Google Maps o SAP.
La Importancia del Software
Un software superior mejora el servicio, reduce costos y ofrece valor agregado. Sin embargo, si el software tiene
fallos, errores o problemas de seguridad, puede dañar gravemente el negocio. La ingeniería de software es el
proceso organizado y sistemático de desarrollar software de alta calidad, es necesario seguir principios rigurosos y
planificar todo el ciclo de vida del software. El software bien diseñado y desarrollado a través de ingeniería de
software puede ser una ventaja competitiva clave para las empresas, ayudándolas a destacar frente a sus
7
competidores. Sin embargo, su calidad y mantenimiento son cruciales para evitar problemas y asegurar el éxito a
largo plazo.
El Proceso de Desarrollo del Software
El proceso de desarrollo de software es el ciclo mediante el cual las necesidades del usuario se traducen en un
producto funcional. En general, este proceso abarca las siguientes etapas:
1. Definición Inicial: Se define el proyecto y los resultados esperados. Se establece un presupuesto y los
acuerdos básicos para comenzar.
2. Análisis de Requerimientos y Viabilidad: Se recopilan los requisitos del cliente y se determina si el proyecto
es viable desde el punto de vista técnico y económico
3. Diseño General y Detallado: Se planifica la estructura del software, desde su arquitectura hasta los
componentes más específicos. Esto actúa como un plano que guiará el desarrollo.
4. Codificación: Se programa el software basado en el diseño detallado, utilizando lenguajes de programación.
5. Pruebas: Se verifica que el software funcione correctamente, cumpla con los requerimientos y no contenga
errores.
6. Implementación: El software se instala en los sistemas del usuario, y se proporciona la capacitación
necesaria para su uso.
7. Evolución: Después de la implementación, pueden ser necesarias modificaciones para corregir errores o
añadir nuevas funcionalidades.
Actividades "Sombrilla" para Asegurar la Calidad
El proceso de desarrollo no se limita a estas etapas secuenciales. También es necesario realizar una serie de
actividades simultáneas que aseguren la calidad del software durante todo el ciclo de vida del proyecto. Estas
actividades incluyen:
1. Seguimiento y Control del Proyecto: Monitorear el progreso del proyecto y corregir desviaciones del plan
original.
2. Gestión del Riesgo: Evaluar los riesgos que puedan afectar el proyecto y tomar medidas para mitigarlos.
3. Aseguramiento de la Calidad: Definir normas y estándares para garantizar que el software cumpla con los
requisitos de calidad.
4. Revisiones Técnicas: Inspeccionar y evaluar los productos de trabajo para detectar y corregir errores antes
de que pasen a la siguiente fase.
5. Mediciones y Métricas: Recolectar datos que ayuden a evaluar el estado del proyecto y detectar posibles
problemas.
6. Gestión de la Configuración: Gestionar los cambios y las actualizaciones del software durante todo su
desarrollo.
7. Administración de la Reutilización: Fomentar la reutilización de componentes de software en futuros
proyectos.
8. Preparación y Producción del Producto: Asegurarse de que todos los entregables estén listos, como
documentos, modelos y registros.
CAPITULO 2 SOMMERVILLE
¿Qué es un proceso de software?
Un proceso de software es un conjunto de actividades organizadas que se llevan a cabo para desarrollar un producto
de software. El desarrollo de software empresarial rara vez se hace desde cero. En su mayoría, las empresas trabajan
con sistemas ya existentes y los modifican o integran con nuevos componentes.
Actividades Fundamentales en un Proceso de Software
8
A pesar de que hay diferentes tipos de procesos de software, todos ellos deben incluir cuatro actividades esenciales:
1. Especificación del software: En esta fase se definen dos aspectos importantes:


Las funcionalidades que tendrá el software, es decir, qué podrá hacer.
Las restricciones de operación.
2. Diseño e implementación del software: Aquí se desarrolla el software con base en la especificación previa.


Se crea el diseño del sistema considerando la arquitectura y la interacción entre sus componentes.
Se lleva a cabo la programación del software siguiendo el diseño establecido.
3. Validación del software
El software debe ser verificado y validado para asegurarse de que cumple con las necesidades del cliente.

Se realizan pruebas de funcionalidad.

Se revisa si el software cumple con lo especificado en la etapa de diseño.
4. Evolución del software
El software no es un producto estático; debe adaptarse con el tiempo para cubrir nuevas necesidades.

Se realizan actualizaciones y mejoras.

Se agregan nuevas funciones para mantener el software relevante y útil.
Estas actividades están presentes en todos los procesos de software, pero cada una puede ser dividida en
subactividades.
Actividades de Soporte en un Proceso de Software
Además de las cuatro actividades fundamentales, existen otras actividades que soportan y facilitan el desarrollo del
software, tales como:





Validación de requerimientos: Asegurarse de que las especificaciones iniciales sean correctas.
Diseño arquitectónico: Determinar la estructura general del software.
Pruebas de unidad: Evaluar el correcto funcionamiento de cada módulo del software.
Documentación: Registrar información detallada sobre el software para facilitar su mantenimiento.
Manejo de configuración del software: Controlar los cambios y versiones del software.
Descripción de los Procesos de Software
Cuando se habla de procesos de software, se describen las actividades que lo componen y el orden en que se llevan
a cabo. Estas descripciones incluyen:
1. Productos: Son los resultados tangibles de cada actividad dentro del proceso.
2. Roles: Cada persona involucrada en el proceso tiene un rol específico con ciertas responsabilidades. Algunos roles
comunes son:



Gerente de proyecto: Supervisa y coordina el desarrollo del software.
Gerente de configuración: Controla las versiones y cambios en el software.
Programador: Escribe y prueba el código del software.
3. Precondiciones y postcondiciones
9
Son condiciones necesarias antes y después de una actividad en el proceso.


Ejemplo de precondición: Antes de comenzar el diseño arquitectónico, el cliente debe haber aprobado
los requerimientos.
Ejemplo de postcondición: Después de finalizar el diseño, deben revisarse los modelos UML que
describen la arquitectura.
¿Por qué los Procesos de Software son Importantes?
Los procesos de software no son simples listas de pasos, sino que dependen de la experiencia y el juicio de las
personas que los ejecutan.




No existe un proceso de software ideal, ya que cada organización diseña su propio proceso de
desarrollo.
Los procesos evolucionan según las necesidades de la empresa y los sistemas que se están
desarrollando.
Para sistemas críticos, se requieren procesos altamente estructurados.
Para sistemas con cambios constantes, es más útil un proceso flexible.
Tipos de Procesos de Software
Los procesos de software se pueden clasificar en dos categorías principales:
1. Procesos dirigidos por un plan ("Plan-Driven")



Todas las actividades del proceso se planifican con anticipación.
Se mide el avance del desarrollo comparándolo con el plan establecido.
Son útiles en proyectos con requerimientos bien definidos.
2. Procesos ágiles



La planificación es incremental y se adapta a cambios constantes.
Se diseñan para responder a requerimientos cambiantes del cliente.
Son ideales para entornos donde las necesidades evolucionan rápidamente.
Mejora de los Procesos de Software
Muchas empresas aún utilizan procesos obsoletos que no aprovechan las mejores prácticas de la ingeniería de
software.
Algunas maneras de mejorar los procesos incluyen:




Estandarización de procesos: Reducir la diversidad de métodos dentro de la organización.
Mejor comunicación entre los equipos de desarrollo.
Reducción del tiempo de capacitación de nuevos empleados.
Uso de herramientas automatizadas para optimizar el desarrollo.
El Modelo en Cascada
Etapas del Modelo en Cascada


Análisis y definición de requerimientos: Se establecen los servicios y restricciones del sistema con la ayuda
del usuario.
Diseño del sistema y software: Se define la estructura del software y se asignan los requerimientos.
10



Implementación y prueba de unidad: Se desarrollan los módulos del software y se prueban individualmente.
Integración y prueba del sistema: Se combinan los módulos y se verifica que funcionen correctamente.
Operación y mantenimiento: Se implementa el software y se realizan mejoras a lo largo del tiempo.
Este modelo sigue una estructura secuencial, donde cada fase debe completarse antes de avanzar a la siguiente.
Limitaciones del Modelo en Cascada



No permite cambios fácilmente una vez que se avanza a la siguiente fase.
Puede generar altos costos si se necesitan modificaciones tardías.
En la práctica, las fases suelen traslaparse y nutrirse entre sí, generando un proceso menos rígido.
Desarrollo Incremental
El desarrollo incremental es un método de desarrollo de software en el que el sistema se crea en etapas o versiones
sucesivas, en lugar de diseñar todo de una sola vez.
¿Cómo funciona el desarrollo incremental?
1. Se diseña una implementación inicial del software.
2. Se presenta al usuario para recibir sus comentarios y sugerencias.
3. Se desarrollan versiones mejoradas del software basadas en esa retroalimentación.
4. Se repite el proceso hasta obtener un sistema adecuado.
Este proceso permite que las actividades de especificación, desarrollo y validación ocurran simultáneamente en
lugar de estar separadas, generando una retroalimentación rápida.
Ventajas del desarrollo incremental
El desarrollo incremental es más eficiente que el modelo en cascada, especialmente para sistemas de: empresas,
comercio electrónico y uso personal
en lugar de tener una solución perfecta desde el inicio, se avanza gradualmente y se hacen ajustes cuando aparecen
errores.
Desarrollar software de manera incremental tiene varios beneficios:



Adaptabilidad a cambios: Si los requerimientos del cliente cambian, hacer modificaciones es más barato y
fácil, ya que solo se altera el incremento actual sin afectar el sistema completo.
Retroalimentación constante: Los clientes pueden ver avances en demostraciones del software y opinar
sobre lo que se ha implementado, en lugar de basarse en documentos técnicos difíciles de interpretar.
Entrega rápida: Aunque el software no esté completo, se pueden entregar funcionalidades útiles al cliente,
lo que le permite empezar a usarlo antes de que todo el sistema esté terminado.
Problemas del desarrollo incremental
A pesar de sus ventajas, este modelo también enfrenta algunos desafíos:
1. Resistencia organizacional: En empresas grandes, los procedimientos burocráticos pueden chocar con un
proceso iterativo y ágil. Algunas normativas externas, como las regulaciones contables, requieren procesos
formales difíciles de cambiar.
11
2. Falta de visibilidad en el proceso: Los administradores necesitan entregas periódicas para medir avances.
Como el software se desarrolla rápido, crear documentos para cada versión puede ser costoso e ineficiente.
3. Deterioro de la estructura del sistema: A medida que se agregan nuevos incrementos, la arquitectura del
software puede volverse compleja y desordenada, dificultando futuras modificaciones.
Estos problemas son más serios en sistemas grandes y de larga duración, ya que involucran múltiples equipos
trabajando en diferentes partes del sistema. En estos casos, se necesita una arquitectura estable desde el inicio para
evitar desorganización.
Ingeniería de Software Orientada a la Reutilización
La ingeniería de software orientada a la reutilización se basa en el uso de componentes de software existentes
para construir nuevos sistemas, en lugar de desarrollar todo desde cero.
¿Cómo funciona la reutilización de software?
1. Búsqueda de componentes: Se buscan fragmentos de código o sistemas que puedan cumplir con los
requerimientos.
2. Modificación de requerimientos: Si no hay una coincidencia exacta entre lo que se necesita y los
componentes disponibles, se ajustan los requerimientos para adaptarse a los componentes encontrados.
3. Diseño del sistema con reutilización: Se organiza el software para integrar los componentes reutilizados de
la mejor manera posible.
4. Desarrollo e integración: Se programa el software que no se pudo encontrar como componente reutilizable
y se combinan todos los elementos en un único sistema.
Ventajas de la reutilización de software


Menos desarrollo desde cero, lo que reduce costos y riesgos.
Entrega más rápida del software al cliente.
Desventajas de la reutilización de software


Compromiso con los requerimientos: el software puede no ajustarse exactamente a las necesidades del
usuario.
Pérdida de control: si se usan componentes externos, la empresa no puede controlar las actualizaciones o
cambios en esos elementos.
Conclusión


El desarrollo incremental permite entregas rápidas y flexibilidad ante cambios, pero puede generar
problemas en la organización y en la arquitectura del software.
La reutilización de software reduce costos y tiempos de desarrollo, pero implica compromisos en los
requerimientos y menor control sobre el sistema final.
Actividades del Proceso de Desarrollo de Software
Los procesos de desarrollo de software incluyen una serie de actividades técnicas, colaborativas y administrativas
con el objetivo de especificar, diseñar, implementar y probar un sistema de software.
Las actividades principales del proceso de software son:

Especificación
12



Desarrollo
Validación
Evolución
Dependiendo del modelo de desarrollo utilizado, estas actividades pueden organizarse de diferentes maneras:


En el modelo en cascada, las actividades se realizan en secuencia.
En el desarrollo incremental, las actividades se entrelazan y se desarrollan de manera más flexible.
Especificación del Software
La especificación del software, también llamada ingeniería de requerimientos, es el proceso de definir y comprender
los servicios que debe ofrecer el sistema y las restricciones que tendrá en su operación y desarrollo. Es una etapa
crítica del desarrollo de software, ya que cualquier error en esta fase afectará el diseño e implementación del
sistema.
Proceso de Ingeniería de Requerimientos
El objetivo principal es generar un documento de requerimientos que especifique qué necesita el usuario y cómo lo
cumplirá el sistema.
Existen dos niveles de requerimientos:


Requerimientos de alto nivel, dirigidos a clientes y usuarios finales.
Requerimientos detallados, destinados a los desarrolladores.
El proceso de ingeniería de requerimientos consta de cuatro actividades principales:
1. Estudio de Factibilidad: Se analiza si las necesidades del usuario pueden ser cubiertas con la tecnología actual y si
el sistema es viable en términos de costo y beneficio.
El estudio debe ser rápido y económico, y su resultado determinará si el proyecto sigue adelante o no.
2. Obtención y Análisis de Requerimientos: Consiste en recopilar información mediante: Observación de sistemas
existentes, Entrevistas con usuarios y proveedores, Análisis de tareas.
3. Especificación de Requerimientos: Se transcriben los requerimientos en un documento formal que contiene:
Requerimientos del usuario: descripción general del sistema para clientes y usuarios finales. Requerimientos del
sistema: especificación detallada de las funcionalidades del software.
4. Validación de Requerimientos: Se verifica que los requerimientos sean realistas, coherentes y completos. Durante
esta etapa, es común encontrar errores en el documento de requerimientos, por lo que se deben corregir antes de
continuar.
Herramientas de Desarrollo de Software
Las herramientas de desarrollo de software son programas que automatizan actividades del proceso de ingeniería
de software.
✔ Desarrollo de modelos gráficos de sistemas para la especificación de requerimientos o el diseño del software.
✔ Generación de código a partir de modelos gráficos.
✔ Creación de interfaces de usuario de forma interactiva..
Diseño e Implementación del Software
La implementación consiste en transformar la especificación del software en un sistema ejecutable.
13
Incluye dos actividades clave:


Diseño del Software
Programación
Diseño del Software
El diseño del software es una descripción de la estructura del sistema, incluyendo:



Modelos y estructuras de datos.
Interfaces entre componentes del sistema.
Algoritmos utilizados.
El diseño se desarrolla de manera iterativa, con retroalimentación constante para corregir y mejorar las versiones
anteriores.
Entradas del Diseño:
✔ Plataforma de software en la que se ejecutará el sistema.
✔ Especificación de requerimientos.
✔ Datos existentes que debe procesar el sistema.
Actividades de Diseño:




Diseño Arquitectónico: Se define la estructura del sistema y los componentes principales.
Diseño de Interfaces: Se especifican las conexiones entre los componentes del sistema.
Diseño de Base de Datos: Se estructura la organización y almacenamiento de datos.
Diseño de Componentes: Se detallan los módulos individuales del sistema.
Salidas del Diseño:
✔ Especificación de la arquitectura del sistema.
✔ Especificación de interfaces entre componentes.
✔ Descripción de la base de datos.
✔ Especificación de componentes individuales.
Validación de Software
Es el proceso mediante el cual se asegura que un sistema cumple con:


Sus especificaciones técnicas.
Las expectativas del cliente.
Las pruebas del programa son la técnica principal de validación. Estas pruebas consisten en ejecutar el sistema con
datos de prueba simulados. Sin embargo, la validación también puede incluir otros procesos como:

Inspecciones.

Revisiones en cada etapa del desarrollo, desde la definición de requerimientos hasta la implementación
del programa.
Fases de la Validación de Software
Para sistemas grandes, no se recomienda hacer pruebas como una única unidad, ya que esto dificultaría la detección
de errores. En su lugar, se sigue un proceso de prueba en tres etapas:
14



Pruebas de los componentes del sistema: Se prueban las partes individuales del software.
Pruebas del sistema integrado: Se combinan los componentes y se prueba su funcionamiento en conjunto.
Pruebas con datos reales del cliente: Se verifica el funcionamiento del sistema en condiciones reales de uso.
¿Por qué es importante este enfoque?



Detectar errores en los componentes individuales antes de integrarlos.
Encontrar problemas de interfaz entre componentes cuando el sistema está integrado.
El proceso es iterativo: si se detectan errores, se deben corregir y volver a probar, lo que puede implicar
repetir algunas fases.
Etapas del Proceso de Pruebas
1. Pruebas de Desarrollo
Las personas que desarrollan el sistema prueban cada uno de sus componentes por separado.

Cada componente se prueba de manera independiente (sin los otros componentes del sistema).

Estos componentes pueden ser:
o
o
o
Funciones.
Clases de objetos.
Agrupaciones coherentes de estos elementos.
2. Pruebas del Sistema
Aquí se integran los diferentes componentes del software y se evalúa su funcionamiento en conjunto.
El objetivo es detectar:




Errores derivados de la interacción entre componentes.
Problemas en las interfaces entre componentes.
Si el sistema cumple con los requisitos funcionales y no funcionales.
Si el sistema tiene propiedades emergentes inesperadas.
3. Pruebas de Aceptación
Esta es la última etapa antes de que el software sea aceptado para su uso.
Aquí el sistema se prueba con datos reales proporcionados por el cliente, en lugar de datos simulados.
Estas pruebas permiten:



Detectar errores u omisiones en los requerimientos del sistema.
Evaluar si el software realmente satisface las necesidades del usuario.
Medir el rendimiento real del sistema.
Desarrollo y Pruebas: Un Proceso Interconectado
Las pruebas y el desarrollo del software están estrechamente relacionados.


Los programadores crean sus propios datos de prueba y prueban el código mientras lo desarrollan.
En un desarrollo incremental, cada nueva versión del software debe probarse conforme avanza.
Evolución del Software
15
El software es flexible, lo que significa que puede modificarse en cualquier momento, incluso después de su
desarrollo. Por esta razón, los sistemas complejos incluyen cada vez más software, ya que este permite realizar
cambios de manera más económica.
Diferencia entre Desarrollo y Mantenimiento
Históricamente, el desarrollo y mantenimiento del software se consideraban procesos separados:

Desarrollo de software: Se ve como una actividad creativa. Consiste en diseñar un sistema desde un
concepto inicial hasta un producto funcional.

Mantenimiento de software: Se considera menos interesante. En realidad, puede ser más costoso que el
desarrollo inicial.
Hoy en día, esta separación está desapareciendo, pocos sistemas son completamente nuevos. Es mejor ver la
ingeniería de software como un proceso evolutivo continuo.
En este enfoque:


El software cambia constantemente para adaptarse a nuevos requerimientos y necesidades del cliente.
No hay una distinción clara entre desarrollo y mantenimiento, sino un flujo continuo de mejoras.
El Cambio en los Proyectos de Software
El cambio es inevitable en cualquier gran proyecto de software. Esto se debe a varios factores:


Variaciones en los requerimientos: Las empresas necesitan que el sistema se adapte a nuevas prioridades
administrativas o a presiones externas.
Avances tecnológicos: Surgen nuevas herramientas y técnicas que permiten mejorar el diseño e
implementación del software.
Dado que el cambio es constante, cualquier modelo de proceso de software debe ser capaz de adaptarse a estas
modificaciones.
Impacto del Cambio en el Desarrollo de Software
El cambio aumenta los costos en el desarrollo del software, porque implica que se deba rehacer parte del trabajo ya
realizado. A este proceso se le llama rehacer.
Para reducir los costos del rehacer, existen dos enfoques principales:
1. Evitar el Cambio: Este enfoque busca anticiparse a posibles modificaciones antes de que el cambio sea demasiado
costoso. Se pueden desarrollar prototipos para que los clientes prueben el sistema antes de comprometerse con la
versión final.
2. Tolerancia al Cambio: Se diseña el proceso de desarrollo de modo que los cambios puedan implementarse con
costos reducidos. Se utilizan metodologías de desarrollo incremental, donde los cambios se aplican en partes del
sistema aún no desarrolladas. O, si el cambio no se puede implementar en una parte nueva, entonces se modifica
solo un pequeño segmento del sistema en lugar de todo el software.
Estrategias para Enfrentar el Cambio
1. Prototipo de Sistema: Se crea una versión inicial del sistema o de una parte de él para: Comprobar los
requerimientos del cliente y Evaluar la factibilidad de algunas decisiones de diseño. Este enfoque ayuda a evitar
cambios costosos, ya que permite a los clientes experimentar con el sistema antes de finalizarlo.
16
2. Entrega Incremental: Se entregan versiones parciales del sistema al cliente, lo que permite: Evitar comprometerse
demasiado pronto con los requerimientos y Realizar modificaciones a bajo costo en las siguientes versiones del
software.
3. Refactorización: La refactorización es la mejora de la estructura y organización de un programa sin cambiar su
funcionalidad. Esto hace que el software sea más flexible y fácil de modificar, apoyando la tolerancia al cambio.
Creación de Prototipos
Un prototipo es una versión inicial del software que se usa para:




Probar conceptos.
Explorar opciones de diseño.
Identificar problemas y soluciones antes del desarrollo final.
Permitir que los interesados experimenten con el software antes de su finalización.
Beneficios del Prototipo



Permite que los usuarios vean cómo funciona el sistema en la práctica.
Ayuda a identificar problemas y mejoras en los requerimientos iniciales.
Evita errores de diseño, ya que permite probar la interfaz de usuario antes de finalizar el software.
El Proceso de Desarrollo de Prototipos
1. Establecimiento de Objetivos: Desde el inicio del proceso, se debe definir el propósito del prototipo. Un prototipo
no puede cumplir todos los objetivos al mismo tiempo, por lo que es importante definir qué se espera lograr con él.
2. Definición de la Funcionalidad: Se decide qué características incluir en el prototipo y cuáles dejar fuera. Para
ahorrar costos y acelerar el desarrollo, se pueden omitir algunas funciones.
3. Desarrollo del Prototipo: Se construye una versión inicial del sistema con las funcionalidades seleccionadas. No se
incluyen detalles como manejo de errores o estándares de calidad estrictos, a menos que sean objetivos específicos
del prototipo.
4. Evaluación del Prototipo: Se capacita a los usuarios para que prueben el sistema. Se identifican errores y se
recopilan comentarios para futuras mejoras. Se ajustan los requerimientos con base en la retroalimentación.
Problemas con los Prototipos
A pesar de sus beneficios, los prototipos pueden tener desventajas si no se manejan correctamente:
1. No siempre se usan de la misma manera que el sistema final: Los usuarios pueden interactuar con el
prototipo de forma distinta a como usarían el producto real. Si el prototipo es lento, los usuarios pueden
evitar ciertas funciones, lo que puede generar una percepción errónea del sistema final.
2. Presión para Convertir Prototipos en Productos Finales En ocasiones, los administradores exigen que un
prototipo desechable se convierta en la versión final del software debido a retrasos en el desarrollo.
BRIANO APUNTE 1, PUNTO 8
El Proceso de Desarrollo del Software: El proceso de desarrollo de software es el conjunto de pasos en los que las
necesidades del usuario son transformadas en un producto final funcional. Se parte de los requerimientos del
cliente, que se convierten en un diseño, luego en código, el cual se prueba, documenta y finalmente se certifica para
su uso.
Etapas del Proceso de Desarrollo de Software
17
1. Definición Inicial: En esta etapa se establece la visión general del proyecto y los resultados esperados. Se definen
los acuerdos básicos con el cliente, incluyendo un presupuesto preliminar, lo que permite comenzar con el proyecto.
2. Análisis de los Requerimientos y su Viabilidad: Aquí se recopilan y analizan todos los requerimientos del cliente,
identificando además cualquier restricción que pueda afectar el desarrollo. Es importante determinar si el proyecto
es viable antes de continuar.
3. Diseño General y Detallado: Se construye el diseño de la aplicación en base a los requerimientos recopilados. Se
definen:


La arquitectura general del software.
El detalle de cada componente de la aplicación.
El diseño debe ser lo suficientemente preciso para guiar la programación, de manera similar a cómo un plano guía la
construcción de un edificio.
4. Codificación: Se lleva a cabo la programación del software, es decir, los diseños creados en la etapa anterior se
transforman en código utilizando un lenguaje de programación.
5. Pruebas: Se verifica que el software funcione correctamente, asegurando que:

No contenga errores.

Cumpla con los requerimientos definidos en el análisis inicial.
6. Implementación: Se instala el software en los dispositivos del usuario y se asegura que el sistema funcione
correctamente. Es fundamental que los usuarios reciban capacitación para poder utilizarlo de manera efectiva.
7. Evolución: Una vez en uso, el software puede necesitar modificaciones debido a:


Corrección de errores no detectados durante las pruebas.
Incorporación de nuevas funcionalidades según las necesidades del usuario.
¿Son suficientes estas etapas para garantizar un software de calidad?
La respuesta es NO. Para asegurar un producto de alta calidad, el responsable del proyecto debe llevar a cabo
actividades adicionales que acompañen el desarrollo. (actividades sombrilla). El desarrollo de software no se limita
solo a las etapas tradicionales, sino que requiere de actividades complementarias para asegurar la calidad y éxito
del producto final. Estas actividades acompañan todo el proceso y permiten detectar problemas a tiempo, gestionar
cambios y mejorar continuamente.
APUNTE 2 BRIANO
En muchas profesiones existen protocolos o guías que ayudan a definir cómo se deben realizar las tareas de manera
efectiva. Siguiendo esta misma lógica, el desarrollo de software no es simplemente escribir código de inmediato. Se
necesita un proceso estructurado para garantizar que el proyecto tenga éxito y el software final sea de calidad. Para
guiar a los desarrolladores en este proceso, existen diversos modelos de desarrollo de software. Estos modelos
funcionan como marcos de referencia que han sido probados en distintos proyectos. Aunque su uso no es
obligatorio, seguirlos aumenta la probabilidad de éxito.
Dado que existen muchos modelos de desarrollo, es importante elegir el más adecuado según:



El tipo de sistema a construir.
La organización donde se implementará.
El contexto específico del proyecto.
18
Desarrollo Dirigido por Plan vs. Metodologías Ágiles
El autor Ian Somerville, en su libro Ingeniería de Software, menciona que los proyectos pueden abordarse de dos
maneras principales:


Desarrollo basado en un plan (Plan-Driven).
Metodologías ágiles.
A continuación, explicaremos cada una en detalle.
Desarrollo basado en un plan (Plan-Driven)
Este enfoque es el paradigma tradicional del desarrollo de software. Se basa en la idea de que:



Primero se analizan las necesidades del cliente.
Luego se elabora un plan detallado para el desarrollo del software.
El plan guía el desarrollo en etapas sucesivas hasta que el sistema esté listo.
Ventajas del enfoque basado en un plan
✅ Permite calcular costos y tiempos con mayor precisión.
✅ Hace que el desarrollo sea más predecible porque sigue pasos secuenciales.
✅ Los requisitos se establecen al inicio del proyecto y son los que se verán reflejados en el software final.
Desventajas del enfoque basado en un plan
❌ En la mayoría de los proyectos de software, los requerimientos no son estáticos y pueden cambiar con el
tiempo.
❌ Poca interacción con el cliente, lo que puede llevar a malentendidos o a que el producto final no sea el
esperado.
❌ Si hay errores en las primeras etapas, se trasladan a las etapas posteriores, lo que dificulta corregirlos.
❌ No es ideal para proyectos grandes o complejos que requieren más flexibilidad.
útil en organizaciones donde los procesos han funcionado de la misma manera durante años y no necesitan
cambiar con frecuencia. Para este tipo de entidades, el enfoque basado en un plan es la mejor opción.
Metodologías Ágiles
En la actualidad, muchas organizaciones operan en entornos cambiantes donde los procesos deben adaptarse
constantemente. Los sistemas evolucionan y requieren actualizaciones frecuentes. En estos casos, el enfoque
basado en un plan no es eficaz, y es aquí donde entran en juego las metodologías ágiles.
Características de las metodologías ágiles
✅ Se basan en entregas incrementales, es decir, el software se desarrolla en partes funcionales que se van
mejorando con el tiempo.
✅ Permiten una mayor interacción con el cliente, quien puede dar retroalimentación en cada fase del desarrollo.
✅ Son ideales para proyectos en entornos cambiantes donde los requisitos pueden modificarse durante el proceso.
A pesar de la popularidad de las metodologías ágiles, no todas las organizaciones pueden adoptarlas
completamente.
Cómo elegir entre un enfoque basado en un plan o metodologías ágiles
Somerville propone una serie de preguntas clave para decidir cuál método usar en un proyecto:
19
Pregunta
Si la respuesta es SÍ
Si la respuesta es
NO
¿Es importante tener
un diseño muy
detallado antes de
empezar?
Usar un enfoque
basado en un plan.
Usar metodologías
ágiles.
¿Es viable hacer
entregas
incrementales?
Usar metodologías
ágiles.
Usar un enfoque
basado en un plan.
¿El sistema a
desarrollar es
grande?
Usar un enfoque
basado en un plan.
Usar metodologías
ágiles si es un
proyecto pequeño.
¿El sistema requiere
mucho análisis antes
de implementarse?
Usar un enfoque
basado en un plan.
Usar metodologías
ágiles si no hay
restricciones
complejas.
¿El equipo de
desarrollo está
distribuido o hay
partes
subcontratadas?
Usar un enfoque
basado en un plan.
Usar metodologías
ágiles si el equipo
está junto y se
comunica de
manera informal.
¿Existen normas
culturales que
prefieran enfoques
tradicionales?
Usar un enfoque
basado en un plan.
Usar metodologías
ágiles si la cultura
organizacional lo
permite.
¿El software debe
cumplir regulaciones
externas?
Usar un enfoque
basado en un plan,
ya que requiere
documentación
detallada.
Usar metodologías
ágiles si no hay
regulaciones
estrictas.
Desarrollo de Sistemas Dirigidos por un Plan – El Enfoque Clásico
La teoría de construcción de sistemas establece que, para que un proyecto de software sea exitoso, debe seguir una
serie de actividades sucesivas. Este enfoque es conocido como modelo lineal, modelo clásico o modelo secuencial.
Características del Modelo Clásico



Se basa en etapas encadenadas, es decir, una vez que se termina una etapa, se pasa a la siguiente.
No se puede avanzar a la siguiente etapa sin haber completado la anterior.
Aunque algunos autores incluyen etapas adicionales, como relevamiento o mantenimiento, el concepto
principal es el mismo: un modelo estructurado y secuencial hasta obtener el producto final.
20

Las etapas pueden tener distintos nombres según el autor (por ejemplo, implementación o implantación en
lugar de puesta en marcha), pero mantienen su esencia.
Etapas del Modelo Clásico
A continuación, se describen las etapas fundamentales del modelo clásico:
Este enfoque es útil en proyectos donde los requerimientos son claros desde el inicio y no se esperan grandes
cambios a lo largo del desarrollo.
Limitaciones del Modelo Clásico




No incluye una evaluación previa de factibilidad, lo que puede llevar a proyectos inviables.
No contempla la planificación detallada antes de iniciar el desarrollo.
No integra mecanismos de control de calidad desde el principio.
No aborda la etapa de garantía ni el mantenimiento posterior.
Para superar estas limitaciones, se propone un modelo integral que amplía y redefine las etapas del desarrollo de
software.
Propuesta Integral para el Desarrollo de Software
La propuesta integral introduce nuevas etapas y redefine algunas del modelo clásico, brindando un enfoque más
completo. A continuación, se describen en detalle las siete etapas que conforman este modelo:
1. Comunicación Inicial: Antes de comenzar el desarrollo, es fundamental establecer un primer contacto entre el
equipo de desarrollo y el cliente.



Se identifican los objetivos generales del proyecto.
Se definen los requisitos iniciales y las expectativas del cliente.
Se aclaran restricciones como presupuesto, tiempo y tecnología a utilizar.
Esta etapa permite comprender las necesidades reales del usuario y alinear el proyecto con sus expectativas.
2. Estudio de Factibilidad: Antes de invertir tiempo y recursos en el desarrollo, es necesario evaluar si el proyecto es
viable. En esta fase se analizan tres aspectos clave:
Factibilidad Técnica
21


¿Existen las herramientas y tecnologías necesarias?
¿Se puede desarrollar con los recursos disponibles?
Factibilidad Económica


¿El costo de desarrollo es viable para el cliente?
¿El proyecto generará beneficios suficientes para justificar su inversión?
Factibilidad Organizacional


¿El software puede ser implementado correctamente dentro de la organización?
¿Los usuarios están capacitados para adoptarlo?
Si el estudio de factibilidad indica que el proyecto es viable, se pasa a la siguiente etapa.
3. Plan y Presupuesto: En esta etapa se establece la planificación del proyecto en detalle:





Definición del equipo de trabajo (programadores, diseñadores, testers, etc.).
Asignación de recursos (hardware, software, herramientas).
Selección del modelo de desarrollo más adecuado (Cascada, Ágil, Incremental, etc.).
Elaboración del cronograma con fechas y entregables.
Estimación de costos para definir el presupuesto.
Un plan detallado reduce riesgos y permite gestionar mejor los recursos.
4. Construcción Aplicando un Modelo: Aquí se lleva a cabo el desarrollo del software siguiendo el modelo elegido en
la planificación. Se incluyen las cinco etapas tradicionales:
4.1. Ingeniería de Requerimientos (antes "Análisis")



Se recopilan los requisitos detallados del sistema.
Se identifican necesidades funcionales y no funcionales.
Se documentan todos los aspectos técnicos y de usuario.
4.2. Diseño



Se define la arquitectura del software.
Se diseñan interfaces de usuario y bases de datos.
Se seleccionan herramientas y tecnologías a utilizar.
4.3. Codificación


Se convierte el diseño en código ejecutable.
Se implementan las funcionalidades y requisitos definidos.
4.4. Pruebas


Se realizan pruebas unitarias, de integración y de aceptación.
Se verifican errores y problemas de compatibilidad.
4.5. Despliegue (antes "Puesta en Marcha")



Se instala el software en el entorno de producción.
Se capacita a los usuarios finales.
Se realiza el seguimiento inicial para detectar fallos tempranos.
22
5. Protección de la Calidad: Para asegurar que el software cumple con los requisitos establecidos, se implementan
estrategias de gestión de calidad, como:




Revisiones de código y auditorías.
Pruebas automatizadas para detectar errores rápidamente.
Monitoreo del rendimiento del sistema.
Validaciones con usuarios finales para asegurar la usabilidad.
Un software de calidad reduce costos de mantenimiento y mejora la satisfacción del cliente.
6. Garantía: Después del despliegue, pueden surgir errores o problemas no detectados en la fase de pruebas. La
garantía implica:



Corrección de fallos sin costo adicional para el cliente.
Soporte técnico en caso de problemas.
Aseguramiento de que el sistema funciona como se esperaba.
Un periodo de garantía brinda confianza al cliente y permite corregir imprevistos sin costos elevados.
7. Mantenimiento: El software necesita actualizaciones y mejoras constantes. Esta fase se divide en tres tipos de
mantenimiento:



Mantenimiento Correctivo: Se corrigen errores o fallos detectados después de la entrega.
Mantenimiento Adaptativo: Se modifica el software para funcionar en nuevos entornos o con tecnologías
actualizadas.
Mantenimiento Evolutivo: Se agregan nuevas funcionalidades según las necesidades del cliente.
El mantenimiento es esencial para extender la vida útil del software y mantener su funcionalidad.
Comparación con el Modelo Clásico
Modelo Clásico
Propuesta Integral
Análisis
Comunicación Inicial + Ingeniería de Requerimientos
Diseño
Plan y Presupuesto
Codificación
Construcción Aplicando un Modelo
Prueba
Protección de la Calidad
Puesta en Marcha Despliegue
No incluido
Estudio de Factibilidad, Garantía y Mantenimiento
Las principales ventajas de este modelo son:
✅ Mayor planificación y reducción de riesgos.
✅ Enfoque en la calidad desde el inicio.
✅ Garantía de funcionamiento y mantenimiento asegurado.
Este enfoque mejora la eficiencia del desarrollo de software y aumenta la satisfacción del cliente al entregar un
producto más estable y de mejor calidad.
Importancia de un plan en el desarrollo de software
23
Contar con un plan en el desarrollo de software tiene varias ventajas, como la posibilidad de estimar plazos,
presupuestos y garantizar que el sistema cumpla con su propósito. Este enfoque es similar al de la construcción de
edificios u otras estructuras físicas. Sin embargo, los sistemas de software son diferentes entre sí, incluso si son
similares en su naturaleza. Cada organización tiene su propia cultura, procesos y formas de implementar sistemas.
Por lo tanto, un único modelo de construcción, como el enfoque clásico o secuencial, no puede adaptarse a todos los
tipos de software y a las necesidades específicas de cada organización.
Necesidad de enfoques flexibles
Es necesario evaluar:
✅ Las características del proyecto
✅ Las necesidades de la organización
✅ Enfoques flexibles que permitan ajustarse a los cambios y lograr mejores resultados
Factores que complican el desarrollo de software
Existen varios factores que pueden desviar un proyecto de sus estimaciones iniciales, entre ellos:
1. Tamaño del software a desarrollar

Un software pequeño y uno grande pueden tener funcionalidades y complejidades similares, pero
desarrollarlos no es lo mismo.

Un software grande implica:
o
o
o
o
o
o
o
o
Más líneas de código
Más usuarios
Más requerimientos
Mayor cantidad de recursos asignados
Mayor despliegue en la implementación
Más capacitación
Más horas de prueba
Más documentación
🔹 Un software pequeño suele contar con presupuesto limitado, lo que obliga a que el desarrollo sea lo más
sencillo posible.
2. Complejidad para obtener requerimientos
Los sistemas buscan resolver problemas organizacionales, pero antes es necesario conocer:
🔹 Cuáles son los problemas
🔹 Cuáles son los requerimientos de los usuarios
🔹 Restricciones para resolverlos
Sin embargo, estos requerimientos no siempre son fáciles de obtener debido a diversos factores:




Dificultad de comunicación entre especialistas en informática y clientes.
Usuarios sin conocimientos técnicos que pueden:
o No tener claras sus necesidades.
o No saber expresarlas correctamente.
Analistas que pueden no comprender los términos específicos de la organización.
Procesos más complejos que aumentan las dificultades.
24

Errores en la interpretación de requerimientos:
o

No siempre lo que el analista entiende es exactamente lo que el usuario explicó.
Omisiones o resistencias intencionales:
o
Un usuario puede ocultar información por:



Temor a perder su puesto
 Mantenimiento de cierto poder dentro de la organización
Falta de tiempo de los usuarios para reunirse con analistas.
Requerimientos que cambian con el tiempo.
📌 Importante:
Es esencial asegurar que los requerimientos sean bien comprendidos y coincidan con las necesidades reales de la
organización.
3. Complejidad técnica
Desarrollar software implica desafíos técnicos, como:
✅ Uso de un nuevo sistema operativo
✅ Uso de nuevos lenguajes de programación
✅ Desarrollo para dispositivos específicos (celulares, equipos industriales, etc.)
✅ Requerimientos tecnológicos impuestos por el cliente
📌 Impacto:
Estos desafíos pueden dificultar el desarrollo si los programadores no tienen experiencia en esas tecnologías.
4. Tiempo disponible
Un proyecto de software debe estimar y presupuestar el tiempo de desarrollo. Sin embargo, en muchas ocasiones,
las organizaciones necesitan el software en una fecha específica, por ejemplo:




Lanzamiento de un nuevo producto
Cambio de período fiscal
Competencia con otras empresas
Apertura de una nueva sucursal
📌 Consecuencia:
Los plazos de desarrollo se convierten en un requerimiento y pueden limitar el proyecto significativamente.
5. Riesgos en el desarrollo de software
Todo proyecto de software implica cierto nivel de riesgo.
Los factores mencionados anteriormente (tamaño, requerimientos, complejidad técnica y tiempo) generan
diferentes niveles de riesgo.
Además, existen otros riesgos específicos, que pueden hacer que un proyecto deba redefinirse o incluso cancelarse.
Ejemplos de riesgos en un proyecto de software:



Pérdida de apoyo político dentro de la empresa
Cambios en el personal
Cambios en el presupuesto
25





Cambios en la legislación
Cambios en el mercado
Lanzamiento de nuevo hardware o software
Actualización de un sistema de la competencia
Venta o fusión de la empresa
Costo en el desarrollo de software
El costo es un factor clave en el desarrollo de software, pero no debe ser el único criterio al elegir un modelo de
desarrollo.
💰 Aspectos a considerar en el costo total de un sistema:

Algunos modelos requieren más recursos y pueden ser costosos inicialmente.

Un modelo más costoso al inicio puede generar ahorros a largo plazo, evitando:
o
o
Reprogramaciones innecesarias
Costos adicionales por errores en los requerimientos
📌 Conclusión final:
Aún con presupuestos limitados, se debe elegir el modelo más adecuado para el proyecto y no necesariamente el
más barato.
📌 Resumen final
✔️ El desarrollo de software no sigue un único modelo, ya que cada proyecto es diferente.
✔️ Factores como tamaño, requerimientos, complejidad técnica, tiempo y riesgos influyen en el éxito del desarrollo.
✔️ El costo debe evaluarse considerando los beneficios a largo plazo y no solo el presupuesto inicial.
✔️ Se deben analizar diferentes modelos de desarrollo para elegir el que mejor se adapte al proyecto.
Modelo Lineal Secuencial (“En Cascada” o “Ciclo de Vida”)
El modelo lineal secuencial, también conocido como modelo en cascada o modelo de ciclo de vida, es una
metodología tradicional para el desarrollo de software. Excelente opción cuando se trabaja en sistemas pequeños y
simples. Este modelo se divide en cinco etapas, las cuales siguen un orden específico y comparten similitudes con
los modelos clásicos de desarrollo de software. A continuación, se detallan cada una de estas fases.
Etapas del Modelo Lineal Secuencial
1. Ingeniería de Requerimientos: Esta etapa es equivalente a la fase de análisis, pero va más allá de solo recopilar
información de los usuarios.
🔹 Se adopta una actitud proactiva para identificar todos los problemas y obtener los requerimientos de manera
detallada y precisa.
🔹 A menudo, los usuarios no conocen o no mencionan todos los requisitos del sistema, por lo que se deben utilizar
diferentes estrategias para obtener información oculta.
🔹 Es necesario analizar:



Documentación existente
Normativas vigentes
Procesos internos de la organización
26
El objetivo de esta fase es definir con total claridad qué necesita el cliente antes de pasar a la siguiente etapa.
2. Diseño: El diseño es la primera actividad técnica en el desarrollo del software.
🔹 Se crea una solución basada en los problemas y necesidades identificadas en la etapa anterior.
🔹 Se elabora un modelo que servirá como base para la programación del software.
🔹 En esta fase se definen:




Estructuras de datos
Arquitectura del sistema
Interfaces de usuario
Componentes necesarios para la programación
Este diseño debe ser completo y detallado para evitar errores en las siguientes etapas.
3. Codificación: Aquí es donde el software realmente se construye.
🔹 Los programadores traducen el diseño en código, utilizando un lenguaje de programación adecuado.
🔹 Se deben seguir pautas y directrices establecidas para garantizar que el software sea funcional y eficiente.
El resultado de esta fase es el programa ejecutable, que luego se someterá a pruebas.
4. Prueba
El objetivo de esta etapa no es demostrar que el software funciona, sino encontrar errores.
🔹 Se somete el sistema a condiciones extremas para descubrir fallos.
🔹 Se busca identificar errores que no fueron detectados durante la codificación.
🔹 Se realizan distintos tipos de pruebas, como:



Pruebas funcionales (ver si cumple los requisitos)
Pruebas de estrés (ver cómo responde en condiciones exigentes)
Pruebas de seguridad (detectar vulnerabilidades)
La calidad del software depende de esta fase, ya que ayuda a corregir problemas antes del despliegue.
5. Despliegue: También conocida como implementación, puesta en marcha o implantación.
🔹 Se instala el software en el entorno productivo del cliente.
🔹 Se realizan tareas adicionales para asegurar que el sistema esté 100% operativo, como:



Instalación de servidores y redes
Configuración de hardware y software
Entrega de manuales y documentación
Un aspecto fundamental es la capacitación de los usuarios para que puedan utilizar el sistema correctamente.
Ventajas y Desventajas del Modelo Lineal Secuencial
A continuación, se presenta un cuadro comparativo con los principales beneficios y desventajas de este modelo:
Ventajas
Desventajas
✅ Es simple, probado y fácil de entender.
❌ No se adapta bien a proyectos grandes.
27
✅ Para proyectos pequeños, es rápido y
económico.
❌ Los errores de las primeras etapas afectan a todo el
proceso.
✅ Cada fase se completa antes de avanzar a la
siguiente, lo que proporciona estructura.
❌ Los clientes no ven el software hasta que está
terminado, lo que puede generar insatisfacción.
❌ No permite cambios a mitad del desarrollo.
❌ Si el cliente olvida especificar un requisito al inicio, es
difícil corregirlo después
Modelo Lineal Secuencial Iterativo o Incremental
¿Qué es el Modelo Lineal Secuencial Iterativo o Incremental?
Este modelo es una variante del modelo lineal secuencial (en cascada), pero con una característica clave:

En lugar de desarrollar el sistema completo de una sola vez, se divide en versiones parciales e
incrementales.

Esto significa que se entrega una primera versión con algunas funcionalidades básicas, y luego se van
desarrollando nuevas versiones que agregan más características.
El modelo sigue los mismos principios del modelo en cascada, pero en cada iteración se entrega un sistema
funcional y operativo.
¿Por qué se usa este modelo?
Hay situaciones en las que no es viable desarrollar y entregar un sistema completo de una sola vez, ya sea por:

Tamaño del proyecto: Un sistema muy grande puede ser difícil de construir de una sola vez.

Tiempo de entrega: Se necesita que el usuario tenga acceso a ciertas funcionalidades lo antes posible.

Razones operativas: Se busca evitar riesgos, entregando partes del sistema para probarlas antes de
completar el proyecto.
En este modelo, el sistema se desarrolla en partes y en cada iteración se usa nuevamente el modelo en cascada para
mejorar y completar el sistema.
Diferencias con otros enfoques
1. Diferencia con la División Modular
Es importante no confundir este modelo con la división modular. La diferencia clave es que:

En el modelo incremental: Cada iteración entrega un sistema completo y operativo, aunque con
funcionalidades limitadas.

En la división modular: Se construyen módulos individuales que, por sí solos, no funcionan completamente
sin los demás.
2. Diferencia con el Desarrollo Ágil
Este modelo tampoco debe confundirse con las metodologías ágiles, ya que tienen diferencias fundamentales:
28
Por lo tanto, el modelo incremental tiene más planificación y estructura desde el principio que el desarrollo ágil.
Ejemplo del Modelo Incremental
Para entender cómo funciona este modelo, imaginemos que estamos desarrollando un sistema para un comercio
minorista.
En lugar de hacer un único desarrollo grande, el sistema se implementa en versiones sucesivas:
Versión
Funciones Incluidas
Primera versión
Permite emitir facturas y controlar la caja.
Segunda versión Se agrega la capacidad de registrar clientes y manejar cuentas corrientes.
Tercera versión
Ahora el sistema permite registrar compras y gestionar proveedores.
Cuarta versión
Se incluye un control de stock automatizado.
De este modo, el negocio puede empezar a usar el sistema desde la primera versión, sin necesidad de esperar a que
todas las funcionalidades estén listas.
Ventajas y Desventajas del Modelo Incremental
Ventajas
✅ Las entregas parciales reducen la complejidad del proyecto y permiten una mejor estimación del tiempo y
recursos necesarios.
✅ El usuario recibe rápidamente una primera versión del software, con sus necesidades más urgentes cubiertas.
✅ Se requiere menos personal en simultáneo, ya que el desarrollo se divide en fases.
✅ Las implementaciones parciales son más sencillas que hacer una implementación total de un solo golpe.
Desventajas
❌ Sigue siendo un modelo secuencial, lo que significa que sigue dependiendo de completar cada etapa antes de
pasar a la siguiente.
❌ Los errores de las primeras etapas pueden arrastrarse a las siguientes, si no se detectan a tiempo.
❌ Todavía pueden producirse bloqueos, aunque en menor medida que en el modelo en cascada, ya que las etapas
son más cortas.
Modelo de Prototipos
¿Qué es el Modelo de Prototipos?
29
El Modelo de Prototipos es una estrategia de desarrollo de software que se basa en la creación de una versión
preliminar o simplificada del sistema final.
Este modelo se usa cuando:

Los requerimientos no están completamente definidos o son difíciles de comprender.

Existen dudas técnicas sobre la viabilidad de ciertos procesos dentro del software.

Se necesita validar la interacción con el usuario, asegurando que los desarrolladores y los clientes están
alineados en la visión del producto.
Un prototipo es una versión incompleta del software que sirve para representar cómo funcionará el sistema final.
No es un producto terminado, sino una herramienta para la comunicación y el refinamiento de requisitos.
Ejemplo para Entenderlo Mejor
Imaginemos que un arquitecto diseña una casa. Antes de empezar la construcción, crea una maqueta para que el
cliente pueda visualizar el resultado final y hacer cambios si es necesario.
De la misma manera, en software se crea un prototipo que representa la aplicación, permitiendo al cliente ver su
diseño, probar su funcionamiento básico y sugerir mejoras antes de construir el producto real.
¿Cómo Funciona el Modelo de Prototipos?
Un prototipo no tiene todas las funcionalidades del sistema final, sino solo las más representativas. Su propósito es:
✅ Probar interfaces y funcionalidades clave.
✅ Validar si es posible desarrollar funciones técnicas complejas.
✅ Aclarar los requerimientos para que el usuario y el desarrollador estén alineados.
Por ejemplo, si se está creando una aplicación para controlar dispositivos móviles, antes de desarrollar el sistema
completo, se puede hacer un prototipo que solo pruebe si la app puede conectarse al dispositivo y enviar
comandos.
Tipos de Prototipos
Existen diferentes formas de construir un prototipo:

Software funcional: Puede programarse una versión reducida que el usuario pueda probar.

Diseños de pantalla: Se crean imágenes de la interfaz para visualizar cómo se verá el sistema.

Herramientas de prototipado: Se usan plataformas que permiten hacer simulaciones sin necesidad de
programar.
El prototipo puede cambiar varias veces antes de que los requerimientos queden completamente definidos. Una
vez aprobado, se desecha y se comienza el desarrollo del software real utilizando otro modelo de desarrollo, como
el Modelo en Cascada o Incremental.
Fases del Modelo de Prototipos
Este modelo sigue un proceso estructurado con varias etapas:
Etapa
Descripción
30
1. Relevamiento Rápido
Se identifican los requerimientos más importantes que serán incluidos en el prototipo.
No se busca obtener todos los requerimientos, sino solo los más representativos.
2. Diseño del Prototipo
Se planifica cómo será el prototipo, qué funciones incluirá y cómo se mostrará al
usuario.
3. Generación del
Prototipo
Se construye el prototipo usando programación, herramientas de diseño o modelos
gráficos. Puede usarse el mismo lenguaje que el sistema final o una herramienta
específica de prototipado.
4. Prueba
Si el prototipo es funcional, se hacen pruebas para detectar posibles errores.
5. Despliegue y
Retroalimentación
El usuario revisa el prototipo junto con el desarrollador y aporta sugerencias. Se hacen
ajustes si es necesario, hasta definir los requerimientos finales.
💡 Nota:
El prototipo no se entrega al cliente como un producto final. Solo sirve como una herramienta de validación y
refinamiento de ideas.
Ventajas y Desventajas del Modelo de Prototipos
✅ Ventajas
✔️ Mejor definición de requerimientos: Ayuda a evitar malentendidos entre el usuario y el desarrollador.
✔️ Reduce la incertidumbre: El cliente puede visualizar cómo será el sistema antes de su desarrollo final.
✔️ Permite probar funciones técnicas difíciles: Se pueden validar algoritmos o interacciones complejas antes de
desarrollar el software completo.
❌ Desventajas
❌ El cliente puede querer usar el prototipo como producto final: Debe quedar claro que el prototipo no es
funcional ni seguro para su uso real.
❌ El desarrollador puede intentar modificar el prototipo en lugar de hacer un desarrollo adecuado: Esto puede
generar problemas de calidad y seguridad.
❌ Algunas funciones del prototipo pueden no estar en la versión final: Hay características que pueden ser
inviables o difíciles de implementar en el entorno real.
Conclusión
El Modelo de Prototipos es una estrategia útil cuando los requerimientos no están claros o hay dudas técnicas en el
desarrollo.

Permite visualizar y probar un sistema antes de su construcción real.

Facilita la comunicación entre usuarios y desarrolladores.

Evita errores costosos al detectar problemas en etapas tempranas.
Sin embargo, debe usarse con precaución, asegurándose de que el prototipo no se convierta en un producto final
improvisado, sino que solo sirva como una herramienta para mejorar el diseño del software antes de su
construcción definitiva. 🚀
Modelo en Espiral
31
El Modelo en Espiral es una metodología de desarrollo de software que integra elementos del modelo iterativo y
del modelo basado en análisis de riesgo. Su nombre proviene de la representación gráfica del proceso en forma de
espiral, donde cada ciclo representa una fase del desarrollo.
¿Por qué se usa el Modelo en Espiral?
Este modelo se diseñó para proyectos con alto nivel de riesgo e incertidumbre, ya que permite evaluar
constantemente si es conveniente seguir con el desarrollo o no. Fue propuesto por Barry Boehm en 1988 y busca
garantizar que los proyectos no fracasen debido a riesgos mal gestionados.
Cada iteración de la espiral puede representar una primera versión del software o el desarrollo de un prototipo. A
medida que se avanza, el software se vuelve más completo hasta llegar a su versión final.
Características principales del Modelo en Espiral
La gran diferencia de este modelo con otros es que incorpora el análisis de riesgos en cada una de sus fases.
Dependiendo de los resultados de este análisis, el proyecto puede:

Continuar con el desarrollo normal.

Ser modificado o ajustado para mitigar los riesgos.

Ser pausado temporalmente si hay problemas que requieren solución.

Ser cancelado definitivamente si los riesgos hacen inviable el desarrollo.
Esto significa que, a diferencia de otros modelos que siguen un camino fijo, el modelo en espiral permite tomar
decisiones en el camino y adaptarse a las circunstancias.
Fases del Modelo en Espiral
El modelo en espiral se divide en varias etapas, que se repiten en cada iteración. Las más importantes son:
Etapa
Descripción
Ingeniería de
Requerimientos
Se definen las necesidades del cliente y se establecen los componentes que
formarán parte de la primera versión del software. También se identifican
los riesgos potenciales que podrían afectar el desarrollo.
Diseño
Se diseña la arquitectura y los componentes principales del software para la
primera iteración.
Análisis de Riesgo
Es la fase más importante del modelo. Aquí se analizan los posibles riesgos
que podrían hacer que el proyecto fracase. Si el análisis indica que el
proyecto no es viable, se puede cancelar antes de perder más recursos.
Codificación
Se programa el software con las primeras funcionalidades acordadas.
Pruebas
Se realiza la verificación del software para identificar errores o fallas en esta
primera versión.
Despliegue
Se implementa la primera versión del sistema, con las funcionalidades
básicas. Con cada nueva iteración, se agregan más funciones al software.
Ventajas y Desventajas del Modelo en Espiral
32
Ventajas
✅ Apto para proyectos riesgosos: Al incluir el análisis de riesgo en cada etapa, permite tomar decisiones
tempranas y evitar pérdidas de recursos.
✅ Modelo flexible: Se puede ajustar el desarrollo según las necesidades y problemas detectados.
✅ Permite entregas incrementales: El cliente recibe versiones funcionales del software con cada iteración, lo que
facilita recibir retroalimentación y mejorar el producto.
✅ Se puede usar en todo el ciclo de vida del software: A lo largo del tiempo, se pueden hacer mejoras y
actualizaciones al sistema mediante nuevas iteraciones.
Desventajas
❌ Medir los riesgos no es sencillo: Un mal análisis puede llevar a decisiones equivocadas, cancelando proyectos
viables o continuando proyectos que luego fallarán.
❌ El cliente puede no entender su funcionamiento: Al tener varias etapas y cambios, puede generar confusión
sobre cuándo el producto estará realmente terminado.
❌ Es costoso: El análisis de riesgos requiere tiempo y recursos adicionales, lo que puede aumentar los costos del
desarrollo. Sin embargo, también puede generar ahorros si se toman las decisiones correctas a tiempo.
⚠ Nota: No hay que confundir la fase de "Análisis de Riesgo" del modelo en espiral con la "Gestión de Riesgos"
general de un proyecto. En este modelo, los riesgos analizados pueden llevar a la cancelación del desarrollo si es
necesario.
Modelo de Desarrollo Rápido de Aplicaciones (RAD)
Este modelo surge debido a la necesidad de desarrollar software en tiempos más cortos sin comprometer la
calidad. Se basa en el uso de herramientas avanzadas de desarrollo que permiten:

Generar código rápidamente.

Automatizar pruebas.

Reutilizar componentes de software existentes.

Facilitar el desarrollo colaborativo.
¿Cómo funciona el modelo RAD?
El desarrollo en RAD se divide en partes para que diferentes equipos trabajen en paralelo. Esto reduce
significativamente los tiempos de entrega y permite generar aplicaciones funcionales en un período de 30 a 90 días.
Este modelo no debe confundirse con metodologías ágiles, ya que en RAD la planificación ocurre al inicio y el
objetivo es desarrollar una única versión del software en poco tiempo.
Fases del Modelo RAD
Etapa
Descripción
Ingeniería de
Requerimientos
Se identifican las necesidades del cliente y se define la división del sistema en partes
que serán desarrolladas por diferentes equipos en paralelo.
Diseño
Se crea el diseño basado en herramientas RAD, identificando qué componentes pueden
reutilizarse y cuáles deben programarse desde cero.
33
Codificación
Se utiliza software especializado para generar código automáticamente en uno o más
lenguajes de programación.
Prueba
Se realizan pruebas tradicionales y también pruebas automatizadas con herramientas
específicas de RAD.
Despliegue
Se instala el software en el entorno del cliente.
Ventajas y Desventajas del Modelo RAD
Ventajas
✅ Reducción del tiempo de desarrollo.
✅ Pruebas más rápidas y eficientes gracias a la automatización.
✅ Mayor portabilidad del software a diferentes entornos y sistemas operativos.
Desventajas
❌ Requiere más recursos humanos y mayor compromiso del cliente.
❌ No todos los proyectos pueden dividirse para trabajarse en paralelo.
❌ El código generado automáticamente puede ser menos eficiente y consumir más recursos.
❌ Difícil de aplicar en proyectos grandes debido a la necesidad de coordinar muchos equipos al mismo tiempo.
Otros Modelos de Desarrollo de Software
Además de los modelos anteriores, existen otras metodologías utilizadas en el desarrollo de software, como:
Desarrollo Basado en Componentes
Este modelo se basa en la reutilización de software preexistente. En lugar de desarrollar todo desde cero, se
ensamblan módulos o componentes ya creados.
Ventajas:

Mayor rapidez en la implementación.

Ahorro de costos.

Fácil actualización y mantenimiento.

Posibilidad de ofrecer software en la nube.
Métodos Formales
Este modelo se basa en el uso de modelos matemáticos para garantizar software sin errores. Se usa en proyectos
donde la precisión es crítica, como:

Software para diagnósticos médicos.

Control de vehículos autónomos.

Sistemas de aviación y maquinaria pesada.
No es un modelo utilizado en software comercial, ya que su desarrollo es muy complejo y costoso.
Elección del Modelo de Desarrollo Adecuado
34
No existe un único modelo que sea el mejor para todos los proyectos. La elección dependerá de factores como:

Tipo de software a desarrollar.

Nivel de riesgo e incertidumbre.

Experiencia del equipo de desarrollo.

Presupuesto y tiempo disponible.

Requerimientos del cliente.
Además, se pueden combinar modelos según las necesidades del proyecto. Por ejemplo, se podría hacer un
prototipo inicial y luego usar RAD para la versión final.
CAPITULO 3 SOMMERVILLE
Desarrollo ágil de software
Objetivos del capítulo
El objetivo de este capítulo es introducirte en los métodos ágiles de desarrollo de software. Al estudiar este
capítulo, aprenderás lo siguiente:

Razones de los métodos ágiles de desarrollo de software, el manifiesto ágil, y las diferencias entre el
desarrollo ágil y el desarrollo dirigido por un plan.

Las prácticas clave en la programación extrema y cómo se relacionan con los principios generales de los
métodos ágiles.

El enfoque de Scrum para la administración de proyectos ágiles.

Los conflictos y problemas al escalar los métodos ágiles para sistemas de software grandes.
Contenido
1. Métodos ágiles
2. Desarrollo dirigido por un plan y desarrollo ágil
3. Programación extrema
4. Administración de un proyecto ágil
35
5. Escalamiento de métodos ágiles
Desarrollo ágil de software
Las empresas actualmente operan en un entorno global de cambios rápidos, por lo que deben responder
rápidamente a nuevas oportunidades y mercados, cambios económicos, y la aparición de productos y servicios
competitivos. El software es parte esencial de las operaciones industriales, y su desarrollo rápido es crucial para
aprovechar estas oportunidades.

El software debe desarrollarse rápidamente para responder a la amenaza competitiva. Muchas empresas,
por lo tanto, priorizan la rapidez en la entrega y desarrollo, incluso si eso significa comprometer la calidad
del software o los requerimientos iniciales.
Problemas con enfoques tradicionales
En los enfoques tradicionales de desarrollo de software, como el enfoque en cascada o basado en especificaciones,
se busca especificar completamente los requerimientos antes de comenzar el diseño y la implementación. Sin
embargo, este tipo de enfoque se alarga a medida que los requerimientos cambian, ya que el software no se entrega
hasta mucho después de lo previsto inicialmente.

Este tipo de enfoque puede funcionar bien para sistemas críticos, como los sistemas de control para la
seguridad, donde se necesita un análisis exhaustivo del sistema.

En ambientes empresariales de rápido movimiento, los enfoques tradicionales causan problemas graves ya
que los requerimientos cambian rápidamente, haciendo que el software se vuelva obsoleto.
Métodos ágiles
El concepto de desarrollo ágil de software surgió en la década de 1990, debido a la insatisfacción con los enfoques
tradicionales de ingeniería de software, especialmente en proyectos pequeños y medianos. Los métodos ágiles
permiten que el equipo de desarrollo se enfoque en el software en lugar de en el diseño y la documentación.

Métodos ágiles utilizan un enfoque incremental, lo que significa que el software se desarrolla en pequeñas
iteraciones, permitiendo que cada versión del software tenga nuevas funcionalidades.

Estos métodos buscan entregar el software operativo rápidamente, de modo que los clientes puedan
probarlo y proporcionar retroalimentación para modificar los siguientes incrementos del sistema.
Características de los métodos ágiles
1. Procesos entrelazados: No existe una especificación detallada y la documentación es mínima. La
especificación y el diseño se desarrollan de manera continua y progresiva a lo largo del proceso de
implementación.
2. Desarrollo en versiones incrementales: El software se desarrolla en versiones, permitiendo que los usuarios
finales proporcionen retroalimentación y proponer nuevos requerimientos para cada versión posterior.
36
3. Interacción continua con el usuario: Los usuarios interactúan frecuentemente en el proceso de desarrollo, lo
que permite ajustar el producto según los cambios de requerimientos.
Manifiesto Ágil
El Manifiesto Ágil es un conjunto de principios fundamentales que guían el desarrollo ágil. Estos principios enfatizan:

Las personas y las interacciones sobre los procesos y herramientas.

El software funcionando sobre la documentación exhaustiva.

La colaboración con el cliente sobre la negociación del contrato.

La respuesta al cambio sobre el seguimiento de un plan.
Aunque los métodos ágiles valoran los elementos de la derecha, dan mayor importancia a los de la izquierda.
Métodos ágiles conocidos

Programación extrema (Extreme Programming, XP): Uno de los métodos ágiles más conocidos. Se enfoca en
la programación colaborativa, la retroalimentación continua y la entrega rápida.

Scrum: Un marco de trabajo ágil para la administración de proyectos, donde el trabajo se divide en
pequeños incrementos llamados "sprints".

Otros enfoques ágiles incluyen: Crystal, DSDM, y el desarrollo dirigido por características.
Principios de los métodos ágiles

Participación del cliente: Los clientes deben estar involucrados de manera continua durante el desarrollo,
priorizando nuevos requerimientos y evaluando las versiones del software.

Entrega incremental: El software se desarrolla en incrementos, con cada nueva versión que incluye nuevas
funcionalidades.

Enfoque en las personas: Aprovechar las habilidades del equipo de desarrollo, sin imponer procesos
estrictos.

Adaptación al cambio: Los métodos ágiles esperan cambios en los requerimientos y diseñan sistemas que
puedan adaptarse a esos cambios de manera continua.

Simplicidad: Mantener el sistema lo más simple posible, evitando soluciones complejas que no sean
necesarias.
Con este enfoque ágil, se logra una mayor flexibilidad para manejar requerimientos cambiantes y permitir una
entrega más rápida del software, priorizando la colaboración constante con los usuarios y la adaptación continua a
sus necesidades.
3.2 Desarrollo Dirigido por un Plan y Desarrollo Ágil
37
En el desarrollo de software, existen dos enfoques principales: desarrollo dirigido por un plan y desarrollo ágil. A
continuación, se explican las diferencias y cómo funcionan.
Enfoque de Desarrollo Dirigido por un Plan
En un enfoque basado en un plan, el proceso de desarrollo está dividido en etapas separadas, con salidas asociadas
a cada una. Las salidas de una etapa se usan como base para planear la siguiente. Este enfoque tiene una estructura
más rígida y las actividades se planifican cuidadosamente desde el inicio.
1. Requerimientos: Primero se definen los requerimientos, que evolucionan y culminan en una especificación
de requerimientos.
2. Diseño e Implementación: Una vez definidos los requerimientos, se pasa a la fase de diseño e
implementación, donde se crean los componentes del sistema basándose en la especificación.
La iteración en este enfoque ocurre dentro de las actividades, y la comunicación entre etapas se hace mediante
documentos formales. Esto significa que todo el proceso está bien documentado, desde los requerimientos hasta el
diseño, para mantener un control detallado y un seguimiento del progreso.
Enfoque de Desarrollo Ágil
En contraste, el enfoque ágil se basa en iteraciones rápidas y flexibles. Las actividades como los requerimientos y el
diseño no se desarrollan por separado, sino que se hacen de manera conjunta. La idea central es que el desarrollo
del sistema es iterativo y flexible, lo que permite adaptarse mejor a los cambios que puedan surgir.
1. Iteración entre actividades: Los requerimientos y el diseño se desarrollan en paralelo, y a medida que
avanza el proyecto, se van ajustando.
2. Desarrollo continuo: En lugar de una planificación detallada desde el principio, se hace un desarrollo
incremental. Esto significa que el software se desarrolla por partes, y cada parte se entrega en incrementos,
con una retroalimentación continua del cliente.
Diferencias Clave entre Desarrollo Dirigido por un Plan y Desarrollo Ágil
Aspecto
Desarrollo Dirigido por un Plan
Desarrollo Ágil
Etapas
Etapas separadas, con salidas claras
para cada una.
Iteración continua y simultánea de actividades.
Documentación Uso de documentos formales para la
comunicación entre etapas.
Documentación mínima y evolutiva, centrada en el
código.
Iteración
Ocurre dentro de cada etapa, no entre
etapas.
Ocurre entre actividades, desarrollando
continuamente nuevas versiones.
Entrega
El sistema se entrega una vez que se ha
completado todo el diseño.
El sistema se entrega en pequeños incrementos,
permitiendo retroalimentación rápida.
Consideraciones para Elegir un Enfoque
A la hora de decidir entre un enfoque basado en un plan o uno ágil, se deben considerar varios factores:
1. Especificación detallada: Si es importante tener una especificación y un diseño detallado antes de comenzar
con la implementación, se debería optar por un enfoque basado en un plan.
38
2. Estrategia de entrega incremental: Si se busca una entrega rápida y retroalimentación continua del cliente,
un enfoque ágil es más adecuado.
3. Tamaño del sistema: Para sistemas pequeños, los métodos ágiles son más eficaces, pero para sistemas
grandes, los enfoques basados en un plan pueden ser necesarios.
4. Tipo de sistema: Sistemas que requieren un análisis exhaustivo antes de la implementación (por ejemplo,
sistemas en tiempo real) probablemente necesiten un diseño detallado, lo que sugiere un enfoque basado
en un plan.
5. Durabilidad del sistema: Los sistemas con una vida útil prolongada pueden necesitar más documentación de
diseño para mantenimiento a largo plazo. Sin embargo, los métodos ágiles argumentan que la
documentación no siempre se mantiene actualizada.
6. Tecnología disponible: Los métodos ágiles suelen beneficiarse de buenas herramientas que apoyan el
desarrollo flexible. Si no se cuenta con estas herramientas, podría ser necesario más diseño formal.
7. Organización del equipo: Si el equipo está distribuido o subcontratado, es posible que se necesiten
documentos de diseño para facilitar la comunicación entre los miembros del equipo.
8. Problemas culturales: Algunas organizaciones prefieren enfoques basados en un plan debido a la tradición y
la cultura organizacional.
9. Habilidades del equipo: Los métodos ágiles pueden ser más efectivos en equipos con altos niveles de
habilidad, mientras que los enfoques basados en un plan son más adecuados para equipos con habilidades
variadas.
10. Regulación externa: Si el sistema debe cumplir con regulaciones externas (por ejemplo, software crítico para
aeronaves), se puede requerir más documentación detallada.
Resumen
No existe un enfoque único que sea adecuado para todos los proyectos de software. De hecho, muchos proyectos
combinan prácticas de ambos enfoques, adoptando métodos ágiles y planificados según lo que sea más adecuado
para cada situación.
3.3 Programación Extrema (XP)
La programación extrema (XP) es uno de los métodos ágiles más conocidos y ampliamente utilizados. Fue
desarrollado por Kent Beck en el año 2000, y se basa en llevar a niveles extremos las prácticas de desarrollo
iterativo.
Características Principales de XP

Desarrollo Incremental: Se realizan pequeñas y frecuentes liberaciones del sistema. Los requerimientos se
expresan como historias de usuario, que son escenarios que se implementan como tareas.

Programación en Pares: Los programadores trabajan en pareja, revisando el trabajo del otro para garantizar
calidad y colaborar estrechamente.

Desarrollo de la Primera Prueba: Antes de escribir el código, los programadores desarrollan pruebas para
cada tarea.
39

Integración Continua: Cada vez que se completa una tarea, se integra en el sistema y se verifica mediante
pruebas automáticas.
Ciclo de Liberación en XP
El ciclo de liberación en XP es rápido y permite que el sistema se desarrolle en ciclos pequeños, con entregas
regulares al cliente para obtener retroalimentación. En este ciclo:
1. Selección de historias de usuario.
2. Desglosar las historias en tareas.
3. Planificar la liberación.
4. Desarrollar, integrar y poner a prueba el software.
5. Liberación del software.
Principios de XP
Principio/Práctica
Descripción
Planeación Incremental
Los requerimientos se registran en tarjetas de historia.
Liberaciones Pequeñas
Se desarrolla el conjunto mínimo de funcionalidad útil.
Diseño Simple
El diseño cubre solo los requerimientos actuales.
Desarrollo de la Primera
Prueba
Se escriben pruebas para cada nueva funcionalidad antes de
implementarla.
Refactorización
Mejora constante del código, manteniéndolo simple y mantenible.
Programación en Pares
Dos desarrolladores trabajan juntos, revisándose mutuamente.
Propiedad Colectiva
Todos los desarrolladores se responsabilizan del código.
Integración Continua
Se integra y prueba el código continuamente en el sistema.
Tarjetas de Historia en XP
Las tarjetas de historia son breves descripciones de los escenarios que el cliente quiere en el sistema. Estas tarjetas
son utilizadas para la planeación del proyecto y guían el desarrollo de nuevas funcionalidades. Cada tarjeta es
desglosada en tareas más pequeñas y priorizadas para su implementación.
Este enfoque permite que el cliente participe activamente en la priorización y especificación de los requerimientos
del sistema, asegurando que el sistema desarrollado sea exactamente lo que el cliente necesita.
Prescripción de Medicamentos
Contexto General: Kate es una médica que necesita prescribir medicamentos a un paciente en una clínica. Para ello,
utiliza un sistema informático que le permite seleccionar y verificar los fármacos que va a recetar. Este proceso está
diseñado para garantizar la seguridad y exactitud de la prescripción, verificando, entre otras cosas, la dosis adecuada
del medicamento.
Opciones para Prescribir un Medicamento:
40
1. Medicamento Actual:
o
Cuando Kate selecciona “medicamento actual”, el sistema le pide que compruebe la dosis prescrita
previamente.
o
Si necesita cambiar la dosis, Kate la ingresa y luego confirma la prescripción.
2. Medicamento Nuevo:
o
Si selecciona “medicamento nuevo”, el sistema asume que Kate sabe qué medicamento prescribir.
Kate debe ingresar las primeras letras del nombre del medicamento.
o
El sistema mostrará una lista de posibles medicamentos que empiezan con esas letras. Kate
selecciona el medicamento deseado y verifica que sea el correcto.
o
Luego, ingresa la dosis y confirma la prescripción.
3. Formulario:
o
Si selecciona “formulario”, el sistema muestra un cuadro de búsqueda para encontrar el
medicamento aprobado.
o
Kate busca el medicamento, selecciona el correcto y verifica que sea el adecuado.
o
Luego, ingresa la dosis y confirma la prescripción.
Verificación de la Dosis:
El sistema siempre verifica que la dosis prescrita esté dentro del rango aprobado. Si la dosis es incorrecta
(demasiado alta o baja), el sistema le solicita a Kate que la modifique.
Después de que Kate confirma la prescripción, se despliega para su verificación. Ella tiene dos opciones:

“OK”: Si selecciona esta opción, la prescripción se registra en la base de datos de auditoría.

“Cambiar”: Si selecciona esta opción, vuelve al proceso de prescripción para modificar los detalles.
Seguridad en la Prescripción de Medicamentos:
La verificación de dosis es una medida de seguridad para evitar que Kate recete una dosis que sea peligrosamente
baja o alta. El sistema compara la dosis prescrita con el rango mínimo y máximo recomendado para el medicamento
y muestra un mensaje de error si está fuera de estos límites.
Desarrollo de Software en Programación Extrema (XP)
1. Desarrollo Incremental y "Picos" (Spikes):
o
Durante el desarrollo del software, a veces surgen problemas que no pueden resolverse fácilmente.
En estos casos, el equipo puede crear un prototipo para explorar posibles soluciones. Estos
problemas se denominan "picos" (spikes), que no implican programación directa, sino investigación
para resolver problemas complejos, como la diseño de arquitectura o la documentación del
sistema.
41
2. Enfoque de Programación Extrema:
o
En programación extrema (XP), el desarrollo de software se hace de manera incremental, con
versiones del sistema liberadas varias veces al día. Las nuevas versiones se entregan a los clientes
aproximadamente cada dos semanas. Las fechas límite siempre se cumplen, y si surgen problemas,
se consultan con los clientes para eliminar funcionalidades si es necesario.
3. Refactorización Continua:
o
En XP, se promueve la refactorización continua del código. Esto significa que el equipo busca
constantemente mejorar el código y optimizarlo, incluso si no es urgente. La refactorización implica
tareas como:

Eliminar código duplicado.

Reorganizar jerarquías de clases.

Sustituir código por métodos más eficientes.
Tareas en el Proceso de Prescripción de Medicamentos:

Tarea 1: Cambiar dosis del medicamento prescrito.

Tarea 2: Selección del formulario.

Tarea 3: Verificación de la dosis.
La verificación de dosis es crucial para asegurar que no se prescriba una dosis peligrosa. El sistema verifica que la
dosis esté dentro del rango recomendado para el medicamento.
Desafíos del Desarrollo Incremental:
Uno de los problemas del desarrollo incremental es que puede degradar la estructura del software con el tiempo.
Con el avance del desarrollo, el código se duplica, se reutiliza de manera inadecuada y la estructura general se
deteriora. XP aborda este problema refactorizando continuamente el software para mantenerlo limpio y eficiente.
Pruebas en Programación Extrema (XP)
1. Enfoque de Pruebas en XP:
o
En XP, las pruebas son fundamentales para evitar errores en el sistema. Se utilizan varias técnicas,
entre ellas:

Desarrollo de primera prueba: Las pruebas se escriben antes que el código.

Pruebas incrementales: Se desarrollan a partir de escenarios específicos.

Involucramiento del usuario: Los usuarios colaboran en la creación de pruebas.

Marcos de pruebas automatizadas: Se usan herramientas para automatizar las pruebas.
2. Desarrollo de Primera Prueba:
42
o
Desarrollo de primera prueba es una de las innovaciones más importantes de XP. Consiste en
escribir las pruebas antes de escribir el código, lo que ayuda a identificar problemas durante el
desarrollo y reduce las malas interpretaciones de los requerimientos.
3. Pruebas de Aceptación:
o
Las pruebas de aceptación son un proceso en el que el cliente ayuda a validar que el sistema cumpla
con sus necesidades. En XP, estas pruebas son incrementales y se desarrollan conforme se avanza en
el desarrollo del sistema.
Caso de Prueba para la Verificación de la Dosis
Prueba 4: Comprobación de Dosis
Entrada:

Un número en miligramos (mg) que represente la dosis del medicamento.

Un número que indique la frecuencia de dosis diaria.
Pruebas:
1. Verificar cuando la dosis individual es correcta, pero la frecuencia es muy alta.
2. Verificar cuando la dosis individual es demasiado alta o baja.
3. Verificar cuando la dosis individual multiplicada por la frecuencia está fuera del rango permitido.
4. Verificar cuando la dosis total está dentro del rango recomendado.
Salida esperada:

“OK” si la dosis está dentro del rango de seguridad.

Mensaje de error si la dosis está fuera del rango de seguridad.
Dificultades en las Pruebas de Aceptación en XP
El rol del cliente en las pruebas de aceptación es crucial. El cliente ayuda a desarrollar pruebas para validar que el
sistema cumpla con sus necesidades. Sin embargo, a menudo el cliente tiene una disponibilidad limitada, lo que
puede dificultar el proceso de pruebas.
Resumen: Este proceso describe cómo Kate, una médica, utiliza un sistema para prescribir medicamentos de manera
eficiente y segura. A través de varias opciones de selección de medicamentos y verificación de dosis, el sistema
asegura que la prescripción sea correcta y dentro de los límites seguros. Además, se aborda el desarrollo de software
ágil en XP, que incluye técnicas como el desarrollo incremental, la refactorización continua y la prueba de primera
prueba para garantizar la calidad del sistema.
3.4 Administración de un proyecto ágil
Responsabilidad de los administradores de proyectos ágiles
43
La responsabilidad principal de los administradores de proyectos de software es dirigir el proyecto de manera
eficiente, para asegurar que el software se entregue a tiempo y dentro del presupuesto planificado. Estos
administradores supervisan el trabajo de los ingenieros de software y monitorean el avance del desarrollo del
software.
Enfoque estándar vs. Enfoque ágil
El enfoque tradicional de administración de proyectos es el basado en un plan. Este enfoque se apoya en un plan
detallado que define qué debe entregarse, cuándo debe entregarse y quién será responsable de cada tarea. En este
tipo de administración, el administrador tiene una visión general del proyecto y de los procesos de desarrollo. Sin
embargo, este enfoque no es ideal para los métodos ágiles, ya que en estos métodos, los requerimientos se
desarrollan de forma incremental y el software se entrega en pequeños incrementos rápidos. Además, en el
enfoque ágil, los cambios en los requerimientos y el software son normales.
Administración en proyectos ágiles
El desarrollo ágil debe ser administrado de manera eficiente para aprovechar al máximo el tiempo y los recursos del
equipo. Esto requiere un enfoque de administración que se adapte al desarrollo incremental y a las características
de los métodos ágiles.
Scrum: Un marco ágil de administración
El enfoque Scrum (Schwaber, 2004) es un método ágil de administración que se centra en el desarrollo iterativo.
Este enfoque no prescribe prácticas técnicas específicas, sino que se enfoca en la gestión del desarrollo. Scrum
puede ser utilizado junto con otros enfoques ágiles más técnicos, como XP (Extreme Programming), para ofrecer un
marco administrativo robusto.
Fases de Scrum
Scrum tiene tres fases principales:
1. Planeación del bosquejo y diseño arquitectónico: En esta fase, se definen los objetivos generales del
proyecto y el diseño de la arquitectura del software.
2. Ciclos Sprint: Un ciclo de trabajo donde se desarrolla un incremento del sistema. Cada ciclo entrega una
versión funcional del software.
3. Cierre del proyecto: En esta fase se concluye el proyecto, se completa la documentación requerida y se
valoran las lecciones aprendidas.
Ciclos Sprint en Scrum
La fase clave de Scrum es el ciclo llamado Sprint. Un Sprint es una unidad de planificación en la que se valoran las
tareas, se asignan prioridades, se seleccionan los requerimientos a desarrollar, y se desarrolla el software. Al final
de cada Sprint, la funcionalidad desarrollada se entrega a los participantes del proyecto. Los puntos clave de los
Sprints son:
1. Duración fija: Los Sprints suelen durar entre dos y cuatro semanas.
2. Carpeta del producto: Este es un listado de todo lo que debe hacerse en el proyecto, y se utiliza para asignar
prioridades y riesgos en cada Sprint.
3. Selección de tareas: El equipo del proyecto trabaja con el cliente para decidir qué tareas se desarrollarán
durante el Sprint.
44
4. Reuniones diarias: Para revisar el progreso y ajustar prioridades, se realizan reuniones diarias muy breves
donde todos los miembros del equipo comparten sus avances, problemas y planes.
5. El maestro de Scrum: Es el facilitador que organiza las reuniones, monitorea el progreso, y se comunica con
el cliente y otros administradores fuera del equipo.
Reuniones diarias en Scrum
Las reuniones diarias son un aspecto fundamental de Scrum. En estas reuniones:

Todos los miembros del equipo participan.

Cada miembro comparte lo que ha hecho, los problemas encontrados y los planes para el día siguiente.

Estas reuniones son breves y no tienen una estructura jerárquica. No hay dirección descendente; todos
participan en la planificación.
Ventajas de Scrum
Scrum ofrece varias ventajas, como:
1. El producto se desglosa en partes más manejables y comprensibles.
2. Los requerimientos inestables no retrasan el progreso.
3. Mejora la comunicación entre todos los miembros del equipo, ya que todos conocen lo que sucede.
4. Los clientes reciben entregas periódicas, lo que permite obtener retroalimentación.
5. Establece confianza entre clientes y desarrolladores, y crea una cultura positiva en el equipo.
Scrum en entornos distribuidos
Originalmente, Scrum fue diseñado para equipos coasignados, donde todos los miembros trabajan en el mismo
lugar. Sin embargo, en la actualidad, muchos equipos de desarrollo están distribuidos en diferentes partes del
mundo. Por ello, existen experimentos para adaptar Scrum a entornos distribuidos, utilizando videoconferencias,
correos electrónicos, y otras herramientas de comunicación para mantener la colaboración entre equipos ubicados
en diferentes lugares.
3.5 Escalamiento de métodos ágiles
Desarrollo ágil en equipos grandes
Los métodos ágiles fueron diseñados principalmente para equipos pequeños, donde los miembros pueden
comunicarse de manera directa e informal. Sin embargo, debido a la necesidad de entregar software rápidamente,
estos métodos también deben adaptarse para sistemas grandes desarrollados por grandes organizaciones.
Escalamiento de los métodos ágiles
El escala de métodos ágiles se refiere a la adaptación de estos métodos para grandes sistemas de software. A
medida que el sistema se hace más grande, los equipos pueden estar distribuidos y trabajar en diferentes zonas
horarias. Los métodos ágiles deben adaptarse a estos cambios para seguir siendo eficaces.
Desafíos en el desarrollo de grandes sistemas
El desarrollo de grandes sistemas de software difiere del desarrollo de sistemas pequeños en varios aspectos clave:
45
1. Sistemas distribuidos: Los grandes sistemas suelen estar formados por sistemas separados que se
comunican entre sí, lo que significa que los equipos no siempre tienen una visión completa del sistema.
2. Sistemas abandonados: Muchos grandes sistemas incluyen y interactúan con sistemas existentes. Estos
sistemas tienen requerimientos rígidos y no siempre se prestan al desarrollo incremental.
3. Integración de sistemas: Gran parte del trabajo en grandes sistemas se dedica a la configuración del
sistema, en lugar de al desarrollo de código original.
4. Regulaciones externas: Los grandes sistemas a menudo están sujetos a reglas externas, lo que limita la
forma en que se pueden desarrollar y requiere una documentación detallada.
5. Tiempo prolongado de desarrollo: Los grandes sistemas tienen tiempos de desarrollo largos, lo que puede
dificultar la coherencia del equipo.
6. Participantes diversos: En proyectos grandes, hay muchos participantes involucrados, y no es posible
involucrar a todos en el proceso de desarrollo.
Perspectivas en el escalamiento de métodos ágiles
Existen dos perspectivas principales en el escalamiento de los métodos ágiles:
1. Escalamiento hacia arriba (Scaling up): Se enfoca en el uso de métodos ágiles para el desarrollo de grandes
sistemas de software que no pueden ser manejados por equipos pequeños.
2. Escalamiento hacia afuera (Scaling out): Se refiere a introducir los métodos ágiles en organizaciones
grandes con experiencia en el desarrollo de software.
Adaptaciones para el desarrollo de grandes sistemas
Para los grandes sistemas, se deben realizar varias adaptaciones en los métodos ágiles. Algunas de estas
adaptaciones incluyen:
1. Mayor diseño y documentación: Para proyectos grandes, no es suficiente solo con escribir código. Es
necesario diseñar la arquitectura del sistema y producir documentación detallada.
2. Mecanismos de comunicación: Es fundamental establecer canales de comunicación entre equipos. Esto
incluye videoconferencias, correos electrónicos, mensajería instantánea, etc., para mantener a todos los
equipos actualizados sobre el progreso.
Resumen
En resumen, la administración ágil de proyectos se basa en adaptarse a los cambios y trabajar de manera iterativa.
Scrum ofrece un marco flexible para organizar y gestionar proyectos ágiles, enfocado en la colaboración y la
comunicación constante entre los miembros del equipo. Para proyectos de gran escala, los métodos ágiles deben
adaptarse mediante un mayor enfoque en el diseño, la comunicación y la documentación para asegurar el éxito en
sistemas grandes y complejos.
APUNTE 3 BRIANO
Explicación Detallada del Texto sobre Desarrollo Ágil
1. Introducción
En el contexto actual, muchas organizaciones operan en entornos dinámicos donde los cambios son
constantes. Para mantenerse competitivas, estas organizaciones deben ser flexibles y adaptarse
46
rápidamente a nuevos desafíos y oportunidades. Esto implica que tanto los procesos de producción como
las estrategias de comercialización deben evolucionar frecuentemente.
Necesidad de Nuevos Modelos
El desarrollo de software también debe alinearse con estos cambios. Es irreal esperar que una
planificación inicial se mantenga estable durante largos períodos. Por lo tanto, surge la necesidad de
explorar nuevos modelos que permitan llevar a cabo proyectos de software exitosos en escenarios
cambiantes.
Metodologías Ágiles
En lugar de seguir un enfoque rígido, es crucial adoptar metodologías ágiles que fomenten:

Flexibilidad

Adaptabilidad

Entrega temprana de valor
Los métodos ágiles permiten responder rápidamente a los cambios y ajustar el enfoque a medida que se
adquieren nuevos conocimientos sobre las necesidades del cliente.
Mejora Continua
Adoptar una mentalidad de mejora continua y aprendizaje es fundamental. A través de ciclos iterativos y
feedback constante, se puede adaptar el desarrollo de software, maximizando el valor entregado al
cliente.
Producción Rápida de Software
Los modelos de desarrollo ágil permiten la producción rápida de software útil y de calidad en períodos
cortos. Esto se basa en la idea de que el software no se desarrolla como una única entidad, sino como una
serie de incrementos que añaden gradualmente nuevas funcionalidades.
Equipos Reducidos
El desarrollo ágil se lleva a cabo mediante equipos pequeños de profesionales altamente capacitados que
comparten la visión general del producto. A partir de esta visión, se realizan pequeños incrementos según
las prioridades del cliente, en ciclos breves llamados iteraciones o sprints.
Etapas de la Iteración
Cada iteración incluye etapas como:

Planificación

Análisis de requerimientos

Diseño

Codificación

Revisión
47

Implementación

Documentación
Sin embargo, estas tareas no se llevan a cabo con la misma formalidad que en los modelos tradicionales,
priorizando la comunicación y la entrega temprana de valor.
Adaptación Continua
Los requerimientos del cliente se recopilan y se les asignan prioridades. En cada iteración, no es necesario
agregar muchas funcionalidades para justificar una nueva versión. Se seleccionan solo aquellas que pueden
implementarse en el corto plazo del sprint. El objetivo es tener un producto operativo y en mejora
continua.
2. Modelos Tradicionales versus Ágiles
Comparación de Modelos
Los modelos tradicionales son considerados lentos, pesados y burocráticos, mientras que los modelos
ágiles son rápidos y livianos. Sin embargo, no todas las organizaciones operan en entornos dinámicos.
Situaciones Específicas
Existen casos donde se requieren análisis exhaustivos y la entrega de un producto completo, como en
sistemas críticos que gestionan maquinaria o en sistemas bancarios que necesitan garantizar altos niveles
de seguridad.
Selección del Modelo Adecuado
Ambos enfoques tienen ventajas y desventajas, y es crucial seleccionar el modelo más adecuado según las
características específicas del proyecto.
Resumen Comparativo
Modelos Tradicionales
Modelos Ágiles
Útiles para entornos estables y software crítico. Útiles para entornos cambiantes y flexibles.
Requisitos definidos al inicio.
No hay especificación inicial detallada.
Sin posibilidad de cambios.
Cambios frecuentes durante el desarrollo.
Entrega completa del sistema.
Sistema en constante desarrollo.
El usuario no participa activamente.
El usuario participa durante todo el proceso.
3. El “Manifiesto Ágil”
El "Manifiesto Ágil" es un documento fundamental que aborda técnicas y procesos para el desarrollo de
software. Fue redactado en febrero de 2001 por Kent Beck y otros desarrolladores críticos de enfoques
tradicionales.
Valores del Manifiesto Ágil
48
Se destacan cuatro valores fundamentales:
1. Individuos e interacciones sobre procesos y herramientas.
2. Software funcionando sobre documentación extensiva.
3. Colaboración con el cliente sobre negociación contractual.
4. Respuesta ante el cambio sobre seguir un plan.
Principios del Desarrollo Ágil
1. Satisfacción del cliente a través de la entrega temprana de software.
2. Bienvenida a los requisitos cambiantes.
3. Entregas frecuentes de software funcional.
4. Colaboración diaria entre personas del negocio y desarrolladores.
5. Proyectos en torno a individuos motivados.
6. Comunicación cara a cara.
7. Software funcionando como medida de progreso.
8. Desarrollo sostenido.
9. Atención a la excelencia técnica.
10. Simplicidad en el diseño.
11. Autoorganización de equipos.
12. Reflexión regular para mejorar la efectividad.
4. Programación Extrema (XP)
La programación extrema (Extreme Programming, XP) es un método ágil que incluye un conjunto de
prácticas para mejorar el desarrollo de software.
Valores de XP
1. Simplicidad: Se busca simplificar el diseño para facilitar el desarrollo.
2. Comunicación: Fundamental para crear un ambiente de cooperación.
3. Retroalimentación: Frecuente y concreta del cliente y del equipo.
4. Coraje y valentía: Implica programar para hoy, no para mañana.
5. Respeto: Esencial para aplicar efectivamente el modelo.
Prácticas de XP

Planeación del incremento: Requerimientos en tarjetas de historia.

Liberaciones pequeñas: Desarrollo del conjunto mínimo de funcionalidad.
49

Diseño simple: Solo suficiente para cubrir requerimientos actuales.

Desarrollo de pruebas: Pruebas de unidad frecuentes.

Refactorización: Mejora continua del código.

Programación en pares: Colaboración entre desarrolladores.

Propiedad colectiva: Responsabilidad compartida del código.

Integración continua: Integración inmediata de tareas completadas.

Ritmo sustentable: Evitar horas extras excesivas.

Cliente en sitio: Representante del usuario integrado al equipo.
Roles en XP

Entrenador (Coach): Guía el proceso XP.

Programador: Escribe pruebas y produce el código.

Cliente: Encargado de escribir historias de usuario.

Encargado de pruebas (Tester): Diseña y ejecuta pruebas funcionales.

Encargado de seguimiento (Tracker): Asegura el cumplimiento de estimaciones.

Consultor: Proporciona conocimiento específico.

Gestor (Big Boss): Coordina el vínculo entre clientes y programadores.
Esta explicación detalla los conceptos fundamentales del desarrollo ágil, resaltando su importancia en un
entorno cambiante y la necesidad de adaptabilidad en el desarrollo de software.
Ciclo de Desarrollo de la Programación Extrema
Introducción a la Programación Extrema
La programación extrema (XP) es una metodología ágil que se centra en mejorar la calidad del software y
la capacidad de respuesta ante los cambios. Uno de los aspectos más destacados de XP es su ciclo de
desarrollo, donde los requerimientos de software se expresan en historias de usuario.
Historias de Usuario
Definición y Formato
Las historias de usuario son descripciones simples de los requerimientos desde la perspectiva del usuario.
Suelen seguir el siguiente formato:

COMO <rol>

QUIERO <descripción de eventos que queremos que ocurra>

PARA <descripción de funcionalidad>
Ejemplo en un Banco
50

COMO Oficial de atención al cliente

QUIERO Presionar una tecla y acceder a los productos que el cliente tiene contratados

PARA Ofrecerle nuevos productos
Proceso de Desarrollo
Una vez definidas las historias de usuario, el equipo de desarrollo:
1. Desglosa las historias en tareas.
2. Estima los recursos y esfuerzos necesarios para cada tarea.
Los programadores trabajan en parejas y crean pruebas para cada tarea antes de comenzar a escribir el
código. Todas las pruebas deben ejecutarse satisfactoriamente al integrar el nuevo código en el sistema.
Rol Activo del Cliente
El cliente tiene un papel activo en el desarrollo, siendo responsable de definir las pruebas necesarias para
la aceptación final del software. El software se considera aceptado cuando todas las pruebas se ejecutan
exitosamente, lo que establece la base para la siguiente iteración del sistema.
Pruebas en XP
Una fortaleza de la programación extrema es el desarrollo de pruebas automatizadas antes de crear una
característica del programa. Las características clave de las pruebas en XP son:

Desarrollo de la primera prueba: Las pruebas se elaboran antes de escribir el código, permitiendo
detectar errores durante el desarrollo.

Desarrollo de pruebas incrementales: El cliente ayuda a desarrollar pruebas de aceptación para las
historias que se implementarán en la siguiente liberación del sistema.

Involucramiento del usuario: El cliente escribe pruebas conforme avanza el desarrollo, asegurando
que el código nuevo cumpla con sus necesidades.

Uso de marcos de pruebas automatizadas: Estos marcos facilitan la escritura y ejecución de
pruebas. Las pruebas deben ser independientes y verificar que el resultado cumple con las
especificaciones.
Ventajas de la Automatización
Con la automatización, se pueden ejecutar pruebas rápidamente cada vez que se agrega funcionalidad al
sistema, permitiendo identificar problemas de inmediato.
Programación en Pares
Concepto y Roles
La programación en pares es una práctica innovadora en XP donde dos programadores trabajan juntos en
un mismo esfuerzo de desarrollo. Los roles son:

Conductor: Implementa el código.
51

Acompañante: Observa, corrige errores y sugiere mejoras.
Ventajas de la Programación en Pares
1. Propiedad colectiva: El software es responsabilidad del equipo, no de individuos.
2. Revisión informal: Dos personas revisan cada línea de código, lo que ayuda a detectar errores.
3. Refactorización: Facilita el mejoramiento continuo del software.
4. Enseñanza: Mejora la distribución del conocimiento entre los miembros del equipo.
5. Contribución múltiple: Ayuda a encontrar mejores soluciones en problemas difíciles.
6. Mayor disciplina: Mantiene el enfoque en las tareas.
Ventajas y Desventajas de XP
Ventajas

Se adapta al desarrollo de sistemas tanto pequeños como grandes.

Optimiza el tiempo de desarrollo.

Permite el trabajo en parejas, complementando conocimientos.

El código es sencillo y entendible, a pesar de la poca documentación necesaria.
Desventajas

No se define el costo y el tiempo de desarrollo, lo que puede llevar a cambios inesperados.

Requiere la presencia constante del usuario, lo cual es difícil de lograr.

Algunos desarrolladores pueden ser celosos de su código y no aceptar modificaciones.

Necesita un mayor número de programadores entrenados, que suelen ser costosos y difíciles de
conseguir.
Adaptación de XP en la Práctica
Las compañías que adoptan XP pueden personalizar las prácticas según sus necesidades. Por ejemplo:

Algunas empresas pueden preferir programación individual y revisiones.

Pueden optar por no realizar refactorizaciones en partes del sistema que no desarrollaron.

En lugar de historias de usuario, pueden utilizar requerimientos convencionales.
Sin embargo, la mayoría de las empresas que adoptan XP siguen principios como:

Liberaciones pequeñas

Desarrollo basado en pruebas

Integración continua
52
Este enfoque flexible permite a las organizaciones adaptar la metodología a sus contextos específicos,
mejorando así la eficiencia y la calidad del desarrollo de software.
Scrum
Introducción a Scrum
El modelo Scrum es uno de los enfoques más utilizados en el desarrollo ágil. A diferencia de otros modelos
que se enfocan exclusivamente en la construcción de software, Scrum es una metodología ágil que se
centra en la gestión general de proyectos. Se caracteriza por su estructura iterativa e incremental, lo que
permite adaptarse a cambios y mejorar continuamente.
El Proceso Scrum
El proceso de Scrum se divide en tres fases bien definidas:
1. Planeamiento del Sprint
En esta fase, conocida como “sprint planning”, se establecen los objetivos generales del proyecto y se
diseña la arquitectura de software. Esta etapa es fundamental ya que sienta las bases para el desarrollo
posterior del sistema.
2. Sprints
Los sprints son ciclos de trabajo que permiten al equipo enfocarse en desarrollar un incremento del
sistema. Durante la planificación del sprint, se seleccionan las características o funcionalidades específicas
a desarrollar, y se implementa el software correspondiente. Al finalizar cada sprint, se entrega la
funcionalidad completa a los participantes.
3. Revisión del Sprint
La última fase es la Revisión del Sprint, donde el equipo evalúa exhaustivamente el trabajo realizado. Se
identifican áreas de mejora y se definen acciones para el próximo ciclo. Este proceso de revisión y mejora
continua asegura que el equipo se adapte y aprenda de cada iteración, optimizando su desempeño.
Resumen del Proceso Scrum
Fase
Descripción
Planeamiento del
Sprint
Establecimiento de objetivos y diseño de la arquitectura del software.
Sprints
Desarrollo de incrementos del sistema, con selección de características a
implementar.
Revisión del Sprint
Evaluación del trabajo realizado, identificación de mejoras y planificación del
siguiente ciclo.
Características Clave del Proceso Scrum
53
1. Longitud Fija de los Sprints: Generalmente de dos a cuatro semanas. Esta duración no debe
cambiarse, ya que establece el ritmo de trabajo.
2. Product Backlog: Es la lista de trabajo pendiente del proyecto. Los nuevos requerimientos se
incorporan a esta lista y se revisan al comenzar un sprint para priorizar las tareas a desarrollar.
3. Selección de Tareas: Implica a todo el equipo y al cliente para priorizar y elegir las características a
desarrollar.
4. Reuniones Diarias Breves: Se realizan para revisar el progreso y re-asignar prioridades si es
necesario. Estas reuniones suelen hacerse sin sillas para mantenerlas cortas y efectivas.
5. Trabajo Variado: La forma exacta en que se realiza el trabajo puede variar dependiendo del
problema y del equipo.
6. Revisión y Presentación: Al final del sprint, el trabajo se revisa y se presenta a los interesados,
continuando con el siguiente sprint.
Roles en Scrum
Los roles en Scrum se dividen en dos categorías:
1. Roles Directamente Comprometidos con el Proyecto

Product Owner: Responsable de maximizar el valor empresarial del proyecto y de articular los
requisitos del cliente. Representa la voz del cliente en el proyecto.

Equipo Scrum: Grupo de personas responsables de comprender los requisitos especificados por el
Product Owner y de crear los entregables del proyecto.

Scrum Master: Facilitador que asegura un ambiente propicio para el éxito del proyecto. Guía y
enseña las prácticas de Scrum, elimina impedimentos y asegura el seguimiento de los procesos.
2. Otros Roles Involucrados
Estos roles son importantes pero no participan directamente del proceso Scrum. Ejemplos incluyen a los
stakeholders (clientes, usuarios, accionistas).
Ceremonias del Scrum
Cada sprint consta de cinco ceremonias o eventos:
1. Sprint Planning: Reunión inicial donde el Product Owner presenta el Backlog actualizado y
priorizado para que el equipo estime las tareas a incluir en el próximo sprint.
2. Daily Meeting: Reuniones rápidas diarias donde cada miembro informa sobre la tarea que realizará
y si tiene impedimentos.
3. Sprint Review: Reunión final al terminar el sprint, donde se presenta el incremento terminado a los
stakeholders para su inspección.
4. Sprint Retrospective: Reflexión sobre el sprint finalizado, identificando áreas de mejora y
analizando lo que salió bien y lo que se puede hacer de manera más eficiente.
54
5. Refinamiento del Product Backlog: Reunión adicional para depurar el listado de pendientes y
aclarar historias de usuario que quedaron pendientes.
El Tablero Scrum
El tablero Scrum es una herramienta esencial en esta metodología, permitiendo visualizar y gestionar el
flujo de trabajo. Cada columna del tablero representa una etapa del proceso, y las tarjetas representan las
historias de usuario o tareas a realizar.
Estructura del Tablero Scrum
Columna
Descripción
Por hacer
Tareas que aún no han sido iniciadas.
En progreso
Tareas en las que un miembro del equipo está trabajando.
Testeo
Tareas que están siendo probadas.
Terminadas
Tareas que han pasado exitosamente las pruebas.
Personalización del Tablero
El tablero puede adaptarse a las necesidades específicas del equipo y el proyecto, permitiendo agregar
columnas adicionales como "En revisión", "En espera" o "Bloqueadas". Esto ayuda a identificar y abordar
cuellos de botella o problemas que requieren atención.
Beneficios del Tablero Scrum

Visualización Clara: Proporciona una representación visual del progreso de cada tarea, facilitando
la identificación de áreas de mejora y la gestión de tareas.

Colaboración y Sincronización: Mantiene a todos los miembros del equipo informados sobre el
estado del proyecto, promoviendo la colaboración y la toma de decisiones conjuntas.

Distribución Equitativa del Trabajo: Permite que cuando una persona completa una tarea, pueda
pasar a la siguiente, evitando la acumulación de trabajo en una sola persona.

Herramientas Informáticas: Existen herramientas en línea que permiten crear y gestionar tableros
Scrum, facilitando la colaboración y el seguimiento del progreso, incluso de forma remota.
Conclusión
Scrum es una metodología ágil poderosa que permite a los equipos de desarrollo gestionar proyectos de
manera efectiva, adaptándose a cambios y mejorando continuamente. Su estructura clara, roles definidos
y ceremonias bien establecidas aseguran que el proceso sea colaborativo y centrado en el cliente, lo que
resulta en un desarrollo de software más eficiente y de mayor calida
¿Por qué utilizar Scrum?
55
Scrum es una metodología ágil que ofrece varias ventajas significativas al ser implementada en proyectos.
A continuación, se detallan las principales ventajas de utilizar Scrum:
Ventajas de Scrum
1. Adaptabilidad:

Las entregas iterativas permiten que los proyectos sean adaptables y abiertos a la
incorporación de cambios. Esto significa que, a medida que se avanza en el desarrollo, el
equipo puede ajustar sus objetivos y prioridades según las necesidades del cliente.
2. Transparencia:

A través del Tablero de Scrum, se visualiza el avance de cada sprint. Este tablero
es compartido, lo que fomenta un ambiente de trabajo abierto y colaborativo, donde todos
los miembros del equipo pueden ver el progreso y los obstáculos.
3. Retroalimentación continua:

La retroalimentación se proporciona mediante reuniones diarias y revisiones al finalizar
cada sprint. Esto permite que el equipo reciba comentarios constantes sobre su trabajo, lo
que facilita la mejora continua.
4. Mejora continua:

Los entregables se mejoran progresivamente en cada sprint a través del proceso
de priorización del Product Backlog. Esto asegura que el equipo esté siempre enfocado en
las tareas más importantes y valiosas para el cliente.
5. Entrega continua de valor:

Los procesos iterativos permiten la entrega continua de valor, tan frecuentemente como el
cliente lo requiera. Esto significa que el cliente puede comenzar a utilizar partes del
producto antes de que esté completamente terminado.
6. Ritmo sostenible:

Los procesos de Scrum están diseñados para que las personas involucradas puedan trabajar
a un ritmo cómodo que, en teoría, se puede mantener indefinidamente. Esto ayuda a evitar
el agotamiento del equipo.
7. Motivación:

Las reuniones diarias y las retrospectivas del sprint conducen a mayores niveles
de motivación entre los empleados. Los miembros del equipo se sienten más implicados en
el proceso y en el éxito del proyecto.
8. Resolución rápida de problemas:

La colaboración de equipos multifuncionales permite resolver problemas de manera más
rápida y eficaz. La diversidad de habilidades y perspectivas en el equipo ayuda a abordar los
desafíos desde diferentes ángulos.
56
9. Entregables efectivos:

La creación del Product Backlog y las revisiones periódicas aseguran que las entregas sean
efectivas y cumplan con las expectativas del cliente.
Críticas a la metodología Scrum
A pesar de sus ventajas, Scrum también enfrenta críticas y desafíos en su implementación:

Complejidad de implementación:


Estrés del equipo:


Al centrarse en la entrega de incrementos de trabajo, puede ser difícil medir el progreso y
evaluar el éxito del proyecto para los interesados externos. Se requiere un experto en Scrum
para monitorear su cumplimiento.
Involucramiento del cliente:


Scrum se centra en la flexibilidad, pero puede tener problemas para gestionar proyectos
con plazos fijos o fechas de entrega estrictas. Esto puede generar conflictos entre las
expectativas del cliente y la capacidad de respuesta del equipo Scrum.
Medición del progreso:


Aunque Scrum es efectivo en proyectos simples, puede tener dificultades para abordar
proyectos complejos o con requisitos altamente detallados. En tales casos, otros marcos de
trabajo podrían ser más efectivos.
Gestión de plazos fijos:


Scrum se basa en equipos autoorganizados que toman decisiones de manera colaborativa.
Esto puede ser complicado en entornos donde los miembros del equipo carecen de
experiencia en autogestión.
Dificultades en proyectos complejos:


El equipo puede experimentar estrés debido a la constante presión de estar en un ciclo de
sprint. Es recomendable introducir sprints que impliquen tareas más relajadas de vez en
cuando para mantener el bienestar del equipo.
Desafíos en la autoorganización:


Aunque Scrum puede parecer simple en teoría, su implementación efectiva puede
ser desafiante. Requiere un cambio cultural y una adopción completa por parte del equipo
y la organización, lo que puede llevar tiempo y esfuerzo significativos.
Aunque Scrum presupone un alto nivel de involucramiento del cliente, sus
responsabilidades pueden dificultar mantener este nivel constante a lo largo del tiempo.
Pérdida de productividad por reuniones:
57

Muchas reuniones, aunque sean cortas, pueden ocasionar pérdidas de productividad. Es
importante gestionar el tiempo de estas reuniones para que no afecten el trabajo del
equipo.
Scrum, no solo para desarrollo de Software
Aunque Scrum fue desarrollado originalmente para resolver problemas en el desarrollo de software, su
aplicación se ha extendido a otros ámbitos. Las organizaciones utilizan modelos ágiles en diversos
procesos, adaptando las ceremonias, artefactos y roles según sea necesario. Algunos ejemplos son:

Marketing:


Gestión de proyectos:


Equipos encargados de organizar eventos, como conferencias o festivales, pueden utilizar
metodologías ágiles para gestionar tareas, asignar responsabilidades y hacer seguimiento
del progreso.
Enseñanza:


Los equipos de I+D pueden beneficiarse de modelos ágiles al abordar proyectos complejos.
Aplican principios como la colaboración multidisciplinaria y la retroalimentación continua
para agilizar el proceso de innovación.
Planificación de eventos:


Las metodologías ágiles son ampliamente utilizadas en la gestión de proyectos en diferentes
industrias. Los equipos dividen proyectos en tareas más pequeñas, establecen plazos
realistas y realizan entregas incrementales, lo que permite mayor flexibilidad.
Investigación y desarrollo:


Los equipos de marketing pueden aplicar metodologías ágiles para gestionar campañas
publicitarias, lanzamientos de productos o estrategias de contenido. Utilizan
tableros Kanban para visualizar tareas, asignar prioridades y hacer seguimiento de plazos.
Educadores pueden aplicar principios ágiles para organizar y llevar a cabo clases. Utilizan
metodologías como Scrum para planificar contenido del curso y gestionar el progreso de los
estudiantes.
Tareas del hogar:

En un entorno doméstico, las metodologías ágiles se pueden aplicar para organizar y
distribuir tareas de manera efectiva. Se pueden utilizar tableros Kanban o aplicaciones de
gestión de tareas para asignar responsabilidades y hacer seguimiento del progreso.
Estos ejemplos demuestran que los modelos ágiles no se limitan al desarrollo de software, sino que
pueden aplicarse efectivamente en una amplia variedad de contextos. La clave es comprender los
principios fundamentales de agilidad y adaptarlos adecuadamente a cada situación específica.
Otras metodologías ágiles
58
Si bien Scrum y XP son las metodologías más utilizadas, no son las únicas. Existen otras metodologías ágiles
que también siguen los principios del manifiesto ágil.
Metodología Crystal
Creada por Alistair Cockburn, Crystal es un conjunto de metodologías que ofrecen alternativas según el
tamaño del equipo y la dificultad del proyecto. Se centra en:

Aspecto humano del equipo: La efectividad del equipo es crucial para el éxito del proyecto.

Tamaño del equipo: La metodología considera el número de componentes en el equipo.

Comunicación: Fomenta una comunicación efectiva entre los miembros del equipo.

Espacio físico adecuado: Proporciona un entorno de trabajo óptimo.

Políticas claras: Establece normas y directrices para el trabajo en equipo.
Los valores de Crystal incluyen:

Entrega frecuente de software operativo.

Comunicación constante entre los miembros del equipo.

Reflexión y mejora continua.
Método de Desarrollo de Sistemas Dinámicos (DSDM)
El DSDM surgió en Inglaterra en los años 90, buscando enfrentar la problemática de desarrollar software
en entornos con agendas y presupuestos apretados. Este método promueve el uso de herramientas RAD y
destaca cinco etapas:
1. Estudio de viabilidad: Evaluar si el proyecto puede llevarse a cabo con un enfoque RAD.
2. Estudio comercial: Verificar que el sistema planificado cumpla con los requisitos solicitados.
3. Iteración del modelo funcional: Construir un prototipo del sistema.
4. Diseño e iteración de la estructura: Construir y probar la solución definitiva.
5. Implementación: Desplegar el sistema.
Los principios de DSDM son coherentes con los del manifiesto ágil, incluyendo:

Involucrar al cliente en el proceso.

Permitir que el equipo tome decisiones importantes.

Centrar el desarrollo en la entrega frecuente de productos.

Mantener un enfoque iterativo e incremental.
Conclusión
Scrum y otras metodologías ágiles ofrecen un enfoque flexible y efectivo para la gestión de proyectos en
diversas industrias. Su adaptabilidad, enfoque en la colaboración y mejora continua son clave para el éxito
59
en un entorno de trabajo en constante cambio. Al comprender y aplicar estos principios, las organizaciones
pueden optimizar sus procesos y mejorar la calidad de sus entregables
Ventajas, Dificultades y Limitaciones de las Metodologías Ágiles
Las metodologías ágiles ofrecen tanto ventajas como desventajas en su aplicación. A continuación, se
detallan estos aspectos de manera exhaustiva.
Ventajas de las Metodologías Ágiles
1. Rápida Respuesta a Cambios:

Las metodologías ágiles permiten una rápida adaptación a los cambios de requisitos
durante el desarrollo del proyecto. Esto se debe a su proceso iterativo, donde el software
está en un estado de cambio permanente.
2. Visibilidad del Progreso:

El cliente puede observar el avance del proyecto y proporcionar opiniones sobre su
evolución. Esto fomenta una relación más cercana entre el equipo de desarrollo y el cliente.
3. Entregas Parciales:

La posibilidad de ofrecer entregables parciales permite abordar primero los objetivos más
sencillos. Esto ayuda a ganar tiempo y experiencia, facilitando posteriormente el abordaje
de objetivos más complejos.
4. Menor Impacto de Cambios:

Al trabajar con entregas en intervalos cortos de tiempo, cualquier cambio que desee realizar
el cliente tendrá un menor impacto. En comparación con las metodologías tradicionales,
donde los cambios pueden resultar costosos, en ágil se pierde solo una porción del trabajo.
5. Reducción de Tiempos y Costos de Capacitación:

Dado que el cliente participa en el diseño y conoce el producto desde su desarrollo, se
reducen los tiempos y costos de capacitación e implementación.
6. Involucramiento de Stakeholders:

Se involucra a todos los stakeholders desde el principio, dándoles un rol activo en el
proceso de desarrollo.
Dificultades en la Aplicación de los Principios Ágiles
1. Disponibilidad del Cliente:

Aunque el involucramiento del cliente es atractivo, a menudo los representantes designados
deben seguir realizando sus propias tareas en la organización. Esto puede dificultar
su disponibilidad para el equipo de Scrum.
2. Personalidad de los Miembros del Equipo:
60

Algunos miembros del equipo pueden no tener la personalidad adecuada para participar
intensamente en los métodos ágiles, lo que dificulta la interacción efectiva con otros
integrantes. Muchos desarrolladores están acostumbrados a trabajar de manera solitaria.
3. Dificultad en la Priorización de Cambios:

Priorizar cambios puede ser complicado, especialmente en sistemas con muchos
participantes, cada uno con diferentes prioridades. Es necesario consensuar las necesidades
operativas con las políticas de la organización.
4. Mantenimiento de la Simplicidad:

Mantener la simplicidad en el desarrollo requiere esfuerzo adicional. Bajo presión de fechas
de entrega, los miembros del equipo pueden carecer de tiempo para realizar
simplificaciones deseables.
5. Cambio Cultural en Organizaciones Grandes:

Las grandes empresas pueden tardar años en cambiar su cultura organizacional para
adoptar procesos informales definidos por equipos de desarrollo, lo que dificulta la
transición hacia metodologías ágiles.
Limitaciones de las Metodologías Ágiles
1. Falta de Documentación:

Generalmente, la única documentación disponible consiste en algunos comentarios en el
código. Esto puede complicar la reusabilidad de componentes.
2. Problemas de Certificación:

La falta de procesos rigurosos y documentación escrita puede generar problemas si el
software necesita ser certificado o auditado.
3. Comunicación Oral:

La comunicación oral puede dar lugar a malentendidos. Lo que se dice es fácil de olvidar,
mientras que lo escrito es más difícil de modificar.
4. Desalineación de Desarrollo y Prioridades:

El desarrollo no siempre sigue la secuencialidad ni las necesidades de las prioridades fijadas,
lo que puede requerir implementar funcionalidades no planificadas.
5. Restricciones en Proyectos Críticos:

Existen limitaciones en cuanto al tamaño de los proyectos, especialmente para software de
seguridad crítica o implementaciones geográficamente dispersas.
6. Falta de Documentación en Proyectos Fracasados:

Si un proyecto ágil fracasa, puede haber muy poca documentación para aprender de los
errores, lo que dificulta la comprensión del sistema.
61
7. Dificultades en Contratos y Subcontrataciones:

Los contratos suelen ser por tiempo insumido, lo que puede complicar su administración y
control. Además, la subcontratación y la presupuestación son difíciles.
Casos de Estudio
En la materia de Ingeniería de Software, se solicita a los alumnos que expongan casos reales basados en su
experiencia laboral. A continuación, se analizan algunos casos que ilustran cómo se aplican las
metodologías ágiles en diferentes empresas.
Caso A: Éxito en Metodología Scrum en un Banco
Un banco necesitaba una herramienta para que su equipo de analistas de datos pudiera buscar
información en el Data Warehouse. Para ello, se creó un equipo dedicado a desarrollar un asistente virtual
utilizando Scrum.

Sprints de 2 semanas: Se establecieron sprints de dos semanas y entregas productivas cada dos
sprints.

Desarrollo inicial: Se desarrolló una interfaz sencilla conectada a servicios cognitivos, permitiendo
al negocio probar el asistente virtual.

Mejoras incrementales: Las mejoras se realizaron en la interfaz y en los entrenamientos cognitivos,
ayudando a descubrir necesidades futuras.
Caso B: Dificultades en la Transición a Metodologías Ágiles
Un banco privado en Argentina enfrentó varios problemas al intentar hacer la transición de un modelo de
desarrollo tradicional a uno ágil.

Resistencia al cambio: Gran parte del sector se aferró al viejo modelo de desarrollo,
mostrando falta de adaptabilidad.

Falta de planificación: No se contaba con un plan de proyecto para realizar estos cambios, lo que
llevó a un desperdicio de recursos.
Caso C: Scrum en la Industria Automotriz
Una empresa automotriz decidió migrar de un sistema antiguo a uno nuevo utilizando metodologías ágiles.

Migración de COBOL/DB2 a Java/Oracle: Se realizaron cambios frecuentes y nuevos pedidos
durante el desarrollo.

Pruebas continuas: Se realizaron pruebas de forma continua durante el desarrollo, lo que permitió
corregir errores antes de la producción.
Caso D: Problemas en una Institución Pública
Una institución pública enfrentó problemas debido a la incorrecta aplicación de metodologías ágiles.

Reuniones ineficaces: Se sustituyeron reuniones diarias por semanales, lo que resultó en una falta
de identificación de impedimentos.
62

Mal relevamiento de requerimientos: Esto llevó a nuevas reuniones para refinar historias de
usuario mal relevadas.
Caso E: Pérdida de Tiempo y Dinero en un Banco
Un banco intentó desarrollar una plataforma de Homebanking utilizando una combinación de
metodologías Scrum y enfoques tradicionales.

Falta de pruebas: Se descuidaron las pruebas, lo que llevó a fallas acumuladas en el producto final.

Retrabajo: La falta de atención a las incidencias provocó un retraso significativo en el proyecto y
pérdidas económicas.
Conclusión
Los casos analizados muestran que la correcta aplicación de las metodologías ágiles es crucial para el éxito
de los proyectos. Adaptar una metodología no debe llevar a desvirtuarla, ya que esto puede resultar en
fracasos significativos. Es fundamental que las organizaciones comprendan y apliquen adecuadamente los
principios ágiles, manteniendo siempre su esencia. La voluntad de adaptabilidad y una planificación
cuidadosa son esenciales para implementar cambios exitosos en el desarrollo de software
63