Metodologia de Desarrollo de Software

Hola bienvenidos a esta nueva entrada el día de hoy hablaremos de las Metodologías de Desarrollo de Software, ¿Pero que es una metodología? Bueno según conceptodefinicion.de se puede definir como:

Metodología: Es el grupo de mecanismos o procedimientos racionales, empleados para el logro de un objetivo

Ya habíamos hablado de que como podíamos definir mecanismos en una entrada pasada, así que vamos al grano, una metodología es practicamente un conjunto de procedimientos o instrucciones guardadas para solucionar o desarrollar algo.

Se, una vez que te metes al mundo de la programación y desarrollo de software te das cuenta de que todo tiene que ver con desarrollar algo o solucionar un problema.

En fin, retomando el punto de la entrada, podemos definir a las Metodologias de Desarrollo de Software como aquellos procedimientos o marcos (técnicas o instrucciones dada la redundancia) que nos permitirán crear software de calidad. Cabe destacar que estos métodos no son impuestos, tu como desarrollador puedes elegir seguirlos o no, solo son recomendaciones que se aconseja seguir para mejorar nuestro trabajo. Son básicamente un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información. Estas son basicamente usadas con los siguientes objetivos:

Definir actividades a llevarse a cabo en un Proyecto.
Unificar criterios en la organización para el desarrollo del proyecto.
Proporcionar puntos de control y revisión
Asegurar la uniformidad y calidad tanto del desarrollo como del sistema en sí
Satisfacer las necesidades de los usuarios del sistema
Conseguir un mayor nivel de rendimiento y eficiencia del personal asignado al desarrollo
Ajustarse a los plazos y costos previstos en la planificación
Generar de forma adecuada la documentación asociada a los sistemas
Facilitar el mantenimiento posterior de los sistemas

Existen dos clases de metodologías en resumidas cuentas Ágiles y Clásicas, pero hablemos un poco de cada una de ellas.

Metodologías Ágiles:

Las Metodologías Ágiles son aquellas que permiten adaptar la forma de trabajo a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las circunstancias específicas del entorno.

En esencia, las empresas que apuestan por esta metodología consiguen gestionar sus proyectos de forma eficaz reduciendo los costes e incrementando su productividad.

Las metodologías Ágiles cuentan con las siguientes características:

Mejora la motivación e implicación del equipo de trabajo: Es importante escuchar las opiniones tanto del cliente como de los desarrolladores incluidos en el equipo, toda opinión es útil para la realización del proyecto.
Mejoran la satisfacción del cliente: En este tipo de metodologías es común trabajar activamente con el cliente, escuchando sus opiniones y mostrándole avances constantes del proyecto.
Ahorrar tiempo en costes: En estas metodologías se toma en cuenta mucho el hecho de mantenerse dentro del presupuesto y dentro de los tiempos de entrega.
Se trabaja con mayor velocidad y eficiencia: Cada cierto periodo de tiempo corto se entrega una muestra de los avances del proyecto en versiones funcionales, lo que permite corregir errores e implementar mejoras de acuerdo a comentarios del equipo o cliente, además de mejorar así la calidad y eficiencia de trabajo.
Eliminación de características innecesarias del producto: Al escuchar constantemente las opiniones del cliente se pueden eliminar características o necesidades que realmente no son necesarias o prioritarias en el desarrollo del proyecto.
Mejora la calidad del Producto: La interacción entre el cliente y los desarrolladores tiene como objetivo crear un proyecto que cumpla las necesidades justas del cliente.
Alertar rápidamente tanto de errores como de problemas: Se detectan facilmente situaciónes como errores o bugs, excesos de presupuesto o tiempos de desarrollo.

Como podemos leer, las Metodologias Agiles son aquellas que basicamente se basan en interactuar directamente con el cliente desarrollando y entregando avances parciales del trabajo hasta tener la versión final del mismo.

Existen diferentes tipos de Metodologias de Desarrollo Agil, hablemos poco a poco de cada una de ellas. Empecemos:

Scrum:

Scrum es una metodologia Agil y flexible que trata de ser de utilizar en proyectos dond el nivel de incertidumbre es alto. Su objetivo será controlar y planificar proyectos con un gran volumen de cambios de última hora, en donde la incertidumbre sea elevada.

La metodología Scrum se centra en ajustar sus resultados y responder a las exigencias reales y exactas del cliente. De ahí, que se vaya revisando cada entregable, ya que los requerimientos van variando a corto plazo.

Entre las principales características de la metodología Scrum , desataca que es un desarrollo incremental en lugar de la clásica planificación del desarrollo completo de un producto o servicio. Sus equipos de trabajo se caracterizan por ser auto-organizados. Y se centra en el producto final, en la calidad del mismo.

¿Cuando utilizar Scrum?

Cuando se tienen proyectos en entornos complejos.
Cuando se necesitan obtener resultados en cortos plazos de tiempo.
Donde los requisitos del proyecto son cambiantes o poco definidos.
Donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.
Cuando no se esta entregando al cliente lo que requiere.
Cuando las entregas se aplazan demasiado.
Donde la calidad no es aceptable.
Donde se disparan los costes del proyecto.
Cuando la moral de equipo de trabajo es baja y existe una rotación alta.

¿Como implementamos Scrum en nuestro proyecto?

Para poder implementar Scrum es necesario saber que esta se basa basicamente en hacer reuniones periodicas con base a ver los avances del proyecto, es decir se realizan reuniones para asegurar el cumplimiento de los objetivos establecidos, a este tipo de reuniones en este modelo se le conocen como Sprints, estos son el corazón de Scrum, es el contenedor de los demás eventos. Todo lo que ocurre para entregar valor está dentro de un Sprint. La duración máxima es de 1 mes, el tiempo se determina en base al nivel de comunicación que el cliente quiere tener.

De esta menera se puede tener un desarrollo iterativo pues los Sprints deben de llevarse acabo periodicamente. En pocas palabras un Sprint es un conjunto de reuniones que se realizan durante el desarrollo del proyecto.

Un Sprint consta de los siguientes pasos:

Sprint planning - Planificación del Sprint

En ella, se divide el tiempo de duración del Sprint, así como el objetivo y entregable del mismo. Además, el equipo de desarrollo deberá saber cómo realizarlo. En pocas palabras es la fase inicial de la reunión, donde se establece que temas se estarán tratando y que objetivos se pretenden lograr. La primera reunión que se hace en el sprint, tiene una duración de 8 horas para Sprints de 1 mes.

Daily meeting - Reunión diaria

Se basa en poner en común y sincronizar actividades para elaborar el plan del día. Es una reunión diaria dentro del Sprint, que tiene como máximo 15 minutos de duración. En ella debe participar, si o si, el equipo de desarrollo.

En esta reunión diaria el equipo de desarrollo hace las siguientes 3 preguntas:

¿Qué hice ayer?
¿Qué voy a hacer hoy?
¿Tengo algún impedimento que necesito que me solucionen?

Esta reunión es la más oportuna para poder inspeccionar al equipo, y poder adaptarse en caso de que haya cambio de tareas dentro de un Sprint.

Sprint review - Revisión del Sprint

Reunión con el cliente o dueño del proyecto, en la que se estudia y revisa el proyecto. Su duración es de 4 horas para Sprints de 1 mes, y es la única reunión de Scrum a la que puede asistir el cliente. En ella el Product Owner presenta lo desarrollado al cliente, y el equipo de desarrollo muestra su funcionamiento. El cliente valida los cambios realizados, y además nos brinda feedback sobre nuevas tareas.

Sprint retrospective - Retrospectiva del proyecto

La retrospectiva es el último evento de Scrum, tiene una duración de 3 horas para Sprints de 1 mes, y es la reunión del equipo en la que se hace una evaluación de cómo se ha implementado Scrum en el finalizado Sprint.

Es una gran oportunidad para el equipo Scrum de inspeccionarse a si mismo, proponiendo mejoras para el siguiente Sprint. En pocas palabras es una revisión del trabajo realizado y la propuesta de mejoras.

Roles:

En Scrum existen 3 roles:

Product owner - Dueño del Proyecto:

Es la persona que tiene asignado el proyecto, es básicamente el responsable (el que da la cara) del mismo. Se encarga de maximizar el valor del trabajo del equipo de desarrollo. La maximización del valor del trabajo viene de la mano de una buena gestión del Product Backlog.

Es el único rol que habla constantemente con el cliente, lo que le obliga a tener muchos conocimientos sobre negocio. Un equipo Scrum debe tener solo 1 Product Owner, y este además puede ser parte del equipo de desarrollo.

Scrum Master - Facilitador:

Es el responsable de que Scrum sea comprendido y aplicado en la organización. Es el manager de Scrum, pero en ningún momento se le puede considerar un jefe. Líder servil que se encarga de eliminar impedimentos o inconvenientes que tenga el equipo dentro de un sprint, aplicando las mejores técnicas para fortalecer el equipo de marketing digital.

Dentro de la organización, el Scrum Master tiene la labor de ayudar en la adopción de esta metodología en todos los equipos.

Development Team Member - Equipo de Desarrollo:

Son los encargados de realizar las tareas priorizadas por el Product Owner. Es un equipo multifuncional y auto-organizado. Son los únicos que estiman las tareas del product backlog, sin dejarse influenciar por nadie.

Los equipos de desarrollo no tienen sub-equipos, o especialistas. La finalidad de esto es transmitir la responsabilidad compartida si no se llegan a realizar todas las tareas de un sprint.

Son básicamente los encargados de crear el producto para que pueda estar listo con los requerimientos necesarios. Se recomienda que sea un equipo multidisciplinar, de no más de 10 personas. Sin embargo, empresas como Google disponen de unos 15.000 desarrolladores trabajando en una rama del código. Y con una metodología Scrum. La automatización en el testeo explica sobre por qué este gran volumen en el equipo.

Conceptos agregados del Scrum:

Product Backlog:

Básicamente, el Product Backlog es el listado tareas que engloba todo un proyecto. Cualquier cosa que debamos hacer debe estar en el Product Backlog, estimado por el equipo de desarrollo.

La responsabilidad exclusiva de ordenar el Product Backlog es del Product Owner, que se encuentra en constante comunicación con el cliente para asegurarse de que las prioridades están bien establecidas.

La ordenación también es 100% responsabilidad del Product Owner, donde las tareas que están más arriba son las de mayor prioridad.

El equipo de desarrollo elige tareas del Product Backlog en el Sprint Planning para generar tanto el Sprint Backlog como el Sprint Goal.

Sprint Backlog:

Es el grupo de tareas del Product Backlog que el equipo de desarrollo elige en el Sprint Planning junto con el plan para poder desarrollarlas.

Debe ser conocido por todo el equipo, para asegurarse que el foco debe estar en este grupo de tareas.

El Sprint Planning no cambia durante el sprint, solo se permite cambiar el plan para poder desarrollarlas.

Ventajas de Scrum

Scrum es muy fácil de aprender, los roles, eventos y artefactos son claros y tienen un objetivo muy relacionado a nuestra manera diaria de trabajar.
El cliente puede comenzar a usar su producto rápidamente.
Se agiliza el proceso, ya que la entrega de valor es muy frecuente.
Menor probabilidad de sorpresas o imprevistos, porque el cliente está viendo frecuentemente el proyecto.

Desventajas de Scrum

Aunque Scrum sea fácil de aprender, es muy difícil poder implementarlo. Esto supone una predisposición y un cambio de cultura de la organización que debe ir desde los altos mandos hasta los clientes.
La necesidad de tener equipos multi-disciplinares puede ser un problema, ya que es difícil encontrar personas que sean capaces de hacer todo el trabajo de un equipo.
El equipo puede tender a realizar el camino más corto para conseguir el objetivo de un Sprint, el cual no siempre es el de mayor calidad.

¿Qué podemos conseguir con Scrum?

Temprana y constructiva retroalimentación para realizar ajustes.
El intercambio de conocimientos y la comunicación interna frecuente para mejorar nuestro desempeño.
Los equipos inspeccionan cada iteración a fondo y se adaptan rápidamente.
Mitigar los riesgos y resolver problemas fácil y rápidamente.
Salidas casi instantáneas de parches para problemas críticos.

Scrum es una metodología apropiada para proyectos con requisitos inestables que requieran rapidez y flexibilidad y cuente con equipos autogestionados y multidisciplinares.

Metodologia XP

“Extreme Programming” o “Programación Extrema” es una de las llamadas metodologías Ágiles de desarrollo de software más exitosas.

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es el más destacado de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más énfasis en la adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.

Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

El modelo XP define cuatro variables para cualquier proyecto de software: costo, tiempo, calidad y alcance. El método especifica que de estas cuatro variables, tres de ellas podrán ser fijadas arbitrariamente por actores externos al grupo de desarrolladores (clientes y jefes de proyecto), y el valor de la restante deberá será establecida por el equipo de desarrollo, quien establecerá su valor en función de las otras tres.

Por ejemplo, si el cliente establece el alcance y la calidad, y el jefe de proyecto el precio, el grupo de desarrollo tendrá libertad para determinar el tiempo que durará el proyecto. Se trata de establecer un equilibrio entre las cuatro variables del proyecto.

Valores XP

XP define un conjunto de valores que establecen el fundamento para todo trabajo realizado como parte de XP. Cada uno de estos valores se usa como un motor para actividades, acciones y tareas específicas de XP.

Simplicidad XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación. Es mejor hacer hoy algo simple, que hacerlo complicado y probablemente nunca usarlo mañana.
Comunicación Algunos problemas en los proyectos tienen origen en que alguien no dijo algo importante en algún momento. XP hace casi imposible la falta de comunicación.
Realimentación Retralimentación concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.
Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si funciona…mejóralo).

Ciclo de vida XP

Al igual que otras metodologías de gestión de proyectos, tanto Ágiles como tradicionales, el ciclo XP incluye:

Entender lo que el cliente necesita > Fase de Exploración
Estimar el esfuerzo > Fase de Planificación
Crear la solución > Fase de Iteraciones
Entregar el producto final al cliente > Fase de puesta en producción

Lo que caracteriza a XP, al igual que al resto de métodos Ágiles es un ciclo de vida dinámico. ¿Cómo lo logra XP? Ciclo XP Mediante ciclos de desarrollo cortos (llamados iteraciones), al fin de los cuales se generan unos entregables funcionales.

En cada iteración se realiza un ciclo completo de análisis, diseño, desarrollo y pruebas, pero utilizando un conjunto de reglas y prácticas especificas de XP. Un proyecto con XP, implica de entre a 10 a 15 iteraciones habitualmente.

PRÁCTICAS BÁSICAS DE LA PROGRAMACIÓN EXTREMA

Para que todo esto funcione, la programación extrema se basa en doce "prácticas básicas" que deben seguirse al pie de la letra. Aquí tienes un pequeño resumen de ellas.

Equipo completo: Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto. Generalmente los equipos están conformados por almenos 12 personas.
Planificación: Se hacen las historias de usuario y se planifica en qué orden se van a hacer y las mini-versiones. La planificación se revisa continuamente.
Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.
Versiones pequeñas: Las mini-versiones deben ser lo suficientemente pequeñas como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan algo útil al usuario final y no trozos de código que no pueda ver funcionando.
Diseño simple: Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.
Pareja de programadores: Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
Desarrollo guiado por las pruebas automáticas: Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.
Integración continua: Deben tenerse siempre un ejecutable del proyecto que funcione y en cuanto se tenga una nueva pequeña funcionalidad, debe recompilarse y probarse. Es un error mantener una versión congelada dos meses mientras se hacen mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qué es lo que falla de todo lo que hemos metido.
El código es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.
Normas de codificación: Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.
Metáforas: Hay que buscar unas frases o nombres que definan cómo funcionan las distintas partes del programa, de forma que sólo con los nombres se pueda uno hacer una idea de qué es lo que hace cada parte del programa. Un ejemplo claro es el "recolector de basura" de java. Ayuda a que todos los programadores (y el cliente) sepan de qué estamos hablando y que no haya mal entendidos.
Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener indefinidamente. Esto quiere decir que no debe haber días muertos en que no se sabe qué hacer y que no se deben hacer un exceso de horas otros días. Al tener claro semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el objetivo cercano de terminar una historia de usuario o mini-versión.

Ventajas:

Programación organizada.
Menor taza de errores.
Satisfacción del programador.

Desventajas:

Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.

Kanban:

Actualmente, el término Kanban ha pasado a formar parte de las llamadas metodologías ágiles, cuyo objetivo es gestionar de manera general cómo se van completando las tareas. Kanban es una palabra japonesa que significa “tarjetas visuales”, donde Kan es “visual”, y Ban corresponde a “tarjeta”.

Las principales ventajas de esta metodología es que es muy fácil de utilizar, actualizar y asumir por parte del equipo. Además, destaca por ser una técnica de gestión de las tareas muy visual, que permite ver a golpe de vista el estado de los proyectos, así como también pautar el desarrollo del trabajo de manera efectiva.

La metodología Kanban se basa en una serie de principios que la diferencian del resto de metodologías conocidas como ágiles:

Calidad garantizada. Todo lo que se hace debe salir bien a la primera, no hay margen de error. De aquí a que en Kanban no se premie la rapidez, sino la calidad final de las tareas realizadas. Esto se basa en el hecho que muchas veces cuesta más arreglarlo después que hacerlo bien a la primera.
Reducción del desperdicio. Kanban se basa en hacer solamente lo justo y necesario, pero hacerlo bien. Esto supone la reducción de todo aquello que es superficial o secundario (principio YAGNI).
Mejora continua. Kanban no es simplemente un método de gestión, sino también un sistema de mejora en el desarrollo de proyectos, según los objetivos a alcanzar.
Flexibilidad. Lo siguiente a realizar se decide del backlog (o tareas pendientes acumuladas), pudiéndose priorizar aquellas tareas entrantes según las necesidades del momento (capacidad de dar respuesta a tareas imprevistas).

Pasos para configurar tu estrategia de Kanban
La aplicación del método Kanban implica la generación de un tablero de tareas que permitirá mejorar el flujo de trabajo y alcanzar un ritmo sostenible. Para implantar esta metodología, deberemos tener claro los siguientes aspectos:

Definir el flujo de trabajo de los proyectos

Para ello, simplemente deberemos crear nuestro propio tablero, que deberá ser visible y accesible por parte de todos los miembros del equipo. Cada una de las columnas corresponderá a un estado concreto del flujo de tareas, que nos servirá para saber en qué situación se encuentra cada proyecto. El tablero debe tener tantas columnas como estados por los que pasa una tarea, desde que se inicia hasta que finaliza (p.e: diagnóstico, definición, programación, ejecución, testing, etc.).

Tablero Kanban

Dicho tablero puede ser específico para un proyecto en concreto o bien genérico. No hay unas fases del ciclo de producción establecidas sino que se definirán según el caso en cuestión, o se establecerá un modelo aplicable genéricamente para cualquier proyecto de la organización.

Visualizar las fases del ciclo de producción

Al igual que Scrum, Kanban se basa en el principio de desarrollo incremental, dividiendo el trabajo en distintas partes. Esto significa que no hablamos de la tarea en sí, sino que lo dividimos en distintos pasos para agilizar el proceso de producción.

Normalmente cada una de esas partes se escribe en un post-it y se pega en el tablero, en la fase que corresponda. Dichos post-its contienen la información básica para que el equipo sepa rápidamente la carga total de trabajo que supone: normalmente descripción de la tarea con la estimación de horas. Además, se pueden emplear fotos para asignar responsables así como también usar tarjetas con distintas formas para poner observaciones o indicar bloqueos (cuando una tarea no puede hacerse porqué depende de otra).

Al final, el objetivo de la visualización es clarificar al máximo el trabajo a realizar, las tareas asignadas a cada equipo de trabajo (o departamento), así como también las prioridades y la meta asignada.

Stop Starting, start finishing

Este es el lema principal de la metodología Kanban. De esta manera, se prioriza el trabajo que está en curso en vez de empezar nuevas tareas. Precisamente, una de las principales aportaciones del Kanban es que el trabajo en curso debe estar limitado y, por tanto, existe un número máximo de tareas a realizar en cada fase.

En realidad, se trata de definir el máximo número de tareas que podemos tener en cada una de las fases (p.e: 3 tareas en la fase de planificación; 2, en la fase de desarrollo; una, en la fase de pruebas, etc.) y, por tanto, restringir el trabajo en curso. A esto, se le añade otra idea que, por muy obvia que pueda parecer, la práctica nos demuestra que no es así: no se puede abrir una nueva tarea sin finalizar otra.

De esta manera, se pretende dar respuesta al problema habitual de muchas empresas de tener muchas tareas abiertas pero con un ratio de finalización muy bajo. Aquí lo importante es que las tareas que se abran se cierren antes de empezar con la siguiente.

Control del Flujo

A diferencia de SCRUM, la metodología Kanban no se aplica a un único proyecto, sino que mezcla tareas y proyectos. Se trata de mantener a los trabajadores con un flujo de trabajo constante, las tareas más importantes en cola para ser desarrolladas y un seguimiento pasivo para no tener que interrumpir al trabajador en cada momento.

Asimismo, dicha metodología de trabajo nos permite hacer un seguimiento del trabajo realizado, almacenando la información que nos proporcionan las tarjetas.

Muchos insisten en destacar las ventajas de Kanban respecto a otras metodología ágiles, como puede ser SCRUM. La posibilidad de poder realizar entregas en cualquier momento, cambiar prioridades al vuelo y la visualización perfecta del flujo, son algunos de los puntos que remarcan como elementos diferenciales y de valor. Sin embargo, no podemos decir que exista una metodología mejor que otra sino que dependerá de la naturaleza de la empresa y la forma de organización de sus procesos internos.

Scrumban:

Conocemos Kanban y Scrum como metodologías de gestión Agile. Scrumban combina las mejores características de ambos métodos. Reúne la naturaleza preceptiva de Scrum y la capacidad de mejora del proceso de Kanban, permitiendo a los equipos moverse hacia el desarrollo Agile y a mejorar constantemente sus procesos. Scrumban se está haciendo especialmente popular en industrias en las que el desarrollo del proyecto y el mantenimiento van juntos.

Scrumban es un modelo de desarrollo especialmente adecuado para proyectos en mantenimiento, o con cargas de trabajo inesperadas, o en los que los requisitos del software se introduzcan o varíen durante todo el ciclo de desarrollo del producto.

Scrumban tiene como características a destacar:

Reduce el tiempo dedicado a planificación y estimación, promoviendo el flujo constante de trabajo.
Desova una cultura de mejora continua, haciendo hincapié en la entrega continua sin sobrecargar al equipo de desarrollo.
Alienta la filosofía de “pensar en grande, actuar en pequeño, fallar rápido, aprender rápidamente”.

Este mix nos permite tener reuniones diarias para dar soluciones a problemas que impactan sobre el desarrollo de un entregable, permite priorizar los entregables mediante reuniones con el lider usuario, permite presentar al usuario parte del producto cada tiempo sprint; así como también permite tener el control de cuantos entregables se encuentran en proceso, cuantos culminados y poder tener una vista gráfica de cómo estamos logrando nuestros objetivos.

Lean:

El término “Lean” o “Lean Manufacturing” (cuya traducción sería algo así como fabricación esbelta) es otro término que, al igual que el Kanban (te recomiendo este post sobre Kanban), tiene su origen en Toyota. De hecho, “Lean” es sinónimo de Toyota Production System, una estrategia de fabricación aplicada con mucho éxito en Japón y ahora muy famosa en el mundo del software, muchas veces bajo el término de Lean Software Development. En los 50 la industria japonesa estaba recuperándose de la segunda guerra mundial y logró con gran éxito aplicar a sus fábricas de coches los conceptos de calidad en la producción creados por los principales gurús estadounidenses, de entre los que destaca Deming. La paradoja fue que siendo métodos idealmente originados por estadounidenses… fueron aplicados por los japoneses, convirtiendo a Japón líder en la industria automovilística, pasando por encima de los EEUU.

La idea principal de la filosofía Lean es aplicar un método sistemático consistente en eliminar los desperdicios, o lo que es lo mismo, el trabajo que no aporta valor al resultado final (servicio o producto).
El artífice del Lean, quien introdujo esta nueva manera de fabricar en Toyota, fue Taiichi Ohno (1912 – 1990), cuya estrategia se fundamentó en tres bases:

– Construir sólo lo necesario.
– Eliminar todo aquello que no añade valor.
– Parar si algo no va bien (lo que está relacionado con el principio de cero defectos).

Además, conviene destacar que el Lean incluye siete importantes principios, los siguientes:

Eliminar desperdicios / restos

Por desperdicio o basura consideramos todo aquello que no aporta valor al cliente. En Lean y en su nombre original en japonés se conoce como Muda 無駄.

Dentro del desarrollo de software podríamos incluir los siguientes elementos:

Código generado que ofrece funcionalidades no deseadas o necesarias.
Retrasos en el proceso de desarrollo de software.
Mala toma de requisitos.
Problemas con la comunicación interna.
Documentación excesiva o mal procedimentada.

Amplificar el aprendizaje

Es de vital importancia que todos los miembros del equipo de desarrollo trabajen con una mentalidad de aprendizaje continuo. El hecho de que un desarrollador trabaje con una tecnología o lenguaje concreto (JavaScript, .NET, J2EE, Angular, NodeJS, etc.) no quiere decir que no pueda aprender de otros compañeros o proyectos.

Estamos en una era en la que la tecnología que hoy es noticia en unos días puede haber cambiado radicalmente. Por este motivo los principales implicados tienen que estar al día tanto por su bien como profesionales como por el bien de las empresas de desarrollo de software.

Tomar decisiones lo más tarde posible

Este principio que a priori puede parecer malo desde un punto de vista tradicional (ciclo de vida en cascada) en la filosofía Lean es primordial. Los requisitos de los clientes pueden cambiar de un día para otro, bien por cambios en las necesidades o bien por una mala definición de los mismos.

En un modo tradicional (sin aplicar Lean) el proyecto parte de unos requisitos iniciales que condicionan todo el ciclo de desarrollo de software y cualquier cambio plantea replanificación y adición de Muda al proyecto.

En una filosofía Lean, Agile generalmente, los requisitos suelen ser sustituidos por user stories que están más cerca de la necesidad real. Por este motivo podemos esperar a construir el software hasta que la user story esté definida claramente y sin ambigüedades.

Entregar lo antes posible

En un modelo Lean, las entregas de software son más frecuentes incluyendo features alineadas con las user stories. Por este motivo, cada entrega incluirá funcionalidades que necesitan los usuarios lo antes posible basadas en prioridades, impacto, valor o cualquier otro motivo.

Potenciar el equipo

Facilitar que los desarrolladores participen en la toma de decisiones de tiempos asociados a tareas, priorización de las mismas y demás hacen que los miembros del equipo se sientan parte importante en él.

Además, los propios desarrolladores saben de primera mano qué tareas cuestan más, cuales menos y qué implicaciones tienen el ciclo de vida del proyecto.

Técnicas como el Planning Poker en las que se asignan pesos, esfuerzos o complejidades a las tareas a realizar caen dentro de este principio.

Crear la integridad

Contar con un buen sistema de integración continua que incluya pruebas automatizadas, builds, pruebas de usabilidad son críticas para que un software sea fácil de mantener, de mejorar y de reutilizar. Con esto evitaremos añadir Muda a dicho software e intentar aprovechar lo aprendido de proyectos anteriores.

Visualizar todo el conjunto

La consigna “Pensar en grande, actuar en pequeño, equivocarse rápido y aprender con rapidez” podrían resumir los siete principios Lean para el desarrollo de software.

Analizar las interacciones de nuestro software con el resto de sistemas dentro de la compañía nos permitirán estudiar posibles mejoras y cambios que redunden en una mejor experiencia de usuario y aporten un mayor valor para el cliente y para el equipo del proyecto.

Situación no ideal vs Situación ideal

Además de la Muda, ya mencionada como todo aquello que no aporta valor al cliente, también contamos con otros dos términos, Muri y Mura relacionados con la filosofía Lean.

El primero hace referencia a la sobrecarga de trabajo a alguno de los miembros del equipo y el segundo a errores de balanceo de trabajo en función del proyecto.

FDD (Feature Driven Development)

Metodología FDD (Feature Driven Development). Es una metodología ágil para el desarrollo de sistemas, basado en la calidad del software, que incluye un monitoreo constante del proyecto.

FDD fue desarrollado por Jeff De Luca y Peter Coad a mediados de los años 90. Esta metodología se enfoca en iteraciones cortas que permite entregas tangibles del producto en corto periodo de tiempo que como máximo son de dos semanas.

Características

No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción.
Se preocupa por la calidad, por lo que incluye un monitoreo constante del proyecto.
Ayuda a contrarrestar situaciones como el exceso en el presupuesto, fallas en el programa o el hecho de entregar menos de lo deseado.
Propone tener etapas de cierre cada dos semanas.
Se obtienen resultados periódicos y tangibles.
Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitoriar.
Define claramente entregas tangibles y formas de evaluación del progreso del proyecto.

Procesos:

El FDD tiene cinco procesos. Los primeros tres se hacen al principio del proyecto.

Desarrollar un modelo global: Al inicio del desarrollo se construye un modelo teniendo en cuenta la visión, el contesto y los requisitos que debe tener el sistema a construir. Este modelo se divide en áreas que se analizan detalladamente. Se construye un diagrama de clases por cada área.
Construir una lista de los rasgos: Se elabora una lista que resuma las funcionalidades que debe tener el sistema, cuya lista es evaluada por el cliente. Cada funcionalidad de la lista se divide en funcionalidades más pequeñas para un mejor entendimiento del sistema.
Planear por rasgo: Se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes.
Diseñar por rasgo: Se selecciona un conjunto de funcionalidades de la lista. Se procede a diseñar y construir la funcionalidad mediante un proceso iterativo, decidiendo que funcionalidad se van a realizar en cada iteración. Este proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código.
Construir por Rasgo: se procede a la construcción total del proyecto.

Roles y responabilidades

El equipo de trabajo está estructurado en jerarquías, siempre debe haber un jefe de proyecto, y aunque es un proceso considerado ligero también incluye documentación (la mínima necesaria para que algún nuevo integrante pueda entender el desarrollo de inmediato).

Director del Proyecto: Líder administrativo y financiero del proyecto. Protege al equipo de situaciones externas.
Arquitecto jefe: Realiza el diseño global del sistema. Ejecución de todas las etapas.
Director de desarrollo: Lleva diariamente las actividades de desarrollo. Resuelve conflictos en el equipo. Resuelve problemas referentes a recursos.
Programador Jefe: Analiza los requerimientos. Diseña el proyecto. Selecciona las funcionalidades a desarrollar de la última fase del FDD.
Propietario de clases: Responsable del desarrollo de las clases que se le asignaron como propias. Participa en la decisión de que clase será incluida en la lista de funcionalidades de la próxima iteración.
Expertos de dominio: Puede ser un usuario, un cliente, analista o una mezcla de estos. Poseen el conocimiento de los requerimientos del sistema. Pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.

TDD (Test Driven Development)

TDD son las siglas en ingles de desarrollo dirigido por test. Es español se conoce esta metodología como Desarrollo Orientado a Pruebas. Se trata de una metodología de desarrollo ágil cuya mayor fortaleza es escribir la mínima cantidad de código posible para obtener el resultado deseado.

Para conseguirlo, se escriben líneas de código y se prueba su comportamiento en el conjunto del programa, incluso cuando sabemos que la prueba que vamos a realizar es incompleta o dará algún tipo de fallo. Los errores que arroje el propio programa nos darán las pautas de las siguientes líneas de código que debemos implementar, y así sucesivamente hasta obtener un resultado final. En basico, nos concentramos en desarrollar una parte del programa, probamos el codigo, si este es funcional pasamos a ver si se puede optimizar, si no pasamos a la corrección de errores.

Es una metodología de desarrollo ágil con una fortaleza fundamental, y es que unifica el proceso de testeo de una aplicación con el proceso de desarrollo, lo que hace que el producto final sea un programa robusto y a prueba de fallos, a la vez que ahorra costes.

El proceso TDD podemos reducirlo a los siguientes pasos:

Escribimos una prueba que recoja nuestros requisitos.
Ejecutamos la prueba. Esta debe fallar, en caso contrario es que no estamos desarrollándola bien, por lo tanto no es válida.
Se escribe la mínima cantidad de código necesaria para que el test pase.
Se vuelve a ejecutar la prueba, esta debe correr exitosamente.
Se recomienda refactorizar el código escrito, ya que cualquier cambio que hagamos vamos a estar seguros que nuestro código va funcionar si los tests son favorables.
Repetimos el punto uno para el siguiente requisito.

Este ciclo también se lo conoce como rojo (hacer que la prueba falle), verde (hacer que la prueba pase) y refactor. Aunque al principio pueda parecer muy parecido a un enfoque de probar primero, al combinarlo con prácticas de desarrollo ágil, TDD toma un enfoque mucho más amplio, y cambia su atención de las pruebas al diseño.

TDD está mucho más relacionado con el diseño emergente que con las pruebas, de hecho, que TDD genere una gran cantidad de pruebas es un efecto secundario positivo, pero no es su propósito final.

El proceso de diseño de software, combinando TDD con metodologías ágiles, sería el siguiente:

El cliente escribe su historia de usuario.
Se escriben junto con el cliente los criterios de aceptación de esta historia, desglosándolos mucho para simplificarlos todo lo posible.
Se escoge el criterio de aceptación más simple y se traduce en una prueba unitaria.
Se comprueba que esta prueba falla.
Se escribe el código que hace pasar la prueba.
Se ejecutan todas las pruebas automatizadas.
Se refactoriza y se limpia el código.
Se vuelven a pasar todas las pruebas automatizadas para comprobar que todo sigue funcionando.
Volvemos al punto 3 con los criterios de aceptación que falten y repetimos el ciclo una y otra vez hasta completar nuestra aplicación.

Vamos con un ejemplo práctico de este ciclo:

Supongamos que el cliente nos pide que desarrollemos una calculadora que sume números. Acordamos con el cliente que el criterio de aceptación sería que si introduces en la calculadora dos números y le das a la operación de .suma, la calculadora te muestra el resultado de la suma en la pantalla.

Partiendo de este criterio, comenzamos a definir el funcionamiento del algoritmo de suma y convertimos el criterio de aceptación en una prueba concreta, por ejemplo, un algoritmo que si introduces un 3 y un 5 te devuelve un 8:

public void testSuma() {

 assertEquals(8, Calculadora.suma(3,5));

}

Esto supone un cambio de mentalidad, primero escribo cómo debe funcionar mi programa y después, una vez lo tengo claro, paso a codificarlo.

Al escribir el test estoy diseñando cómo va a funcionar el software, pienso que para cubrir la prueba voy a necesitar una clase Calculadora con una función que se llame Suma y que tenga dos parámetros.

Esta clase todavía no existe pero cuando la cree, ya sé cómo va a funcionar. Este caso es muy trivial, pero muchas veces no sabemos exactamente qué clases hacer o qué métodos ponerle exactamente.

Es más, a menudo perdemos el tiempo haciendo métodos y clases que pensamos que luego serán útiles, cuando la cruda realidad es que muchas veces no se van a usar nunca. Con TDD sólo hacemos lo que realmente necesitamos en ese momento.

Realmente es la forma natural de pensar, primero pensamos en “qué” queremos hacer y después pasamos al “cómo”, la diferencia es que con TDD el test ya queda escrito y se ejecutará cada vez que compilamos nuestro programa.

Por supuesto, si intentamos pasar este test nos dará un error, porque la clase Calculadora aún no existe.

Ahora pasamos a escribir el código de la clase, es fácil porque ya sabemos exactamente cómo se va a comportar:

public class Calculadora {

 public static int suma (int a, int b) {

 int c = a + b;

 return c;

 }

}

Ahora ejecutamos la prueba y ya tenemos el código funcionado con la prueba pasada.

Una vez todo esté funcionando, pasamos a refactorizar y a eliminar código duplicado, este ejemplo es extremadamente sencillo, y en un caso real no haríamos tantos pasos para algo tan evidente, pero el código mejorado podría ser por ejemplo:

public class Calculadora {

 public static int suma (int a, int b) {

 return a+b;

 }

}

En ejemplos más complejos, según vayamos escribiendo más test, deberíamos buscar código duplicado y agruparlo en funciones o utilizar la herencia o el polimorfismo.

Es importante pasar todos los test después de refactorizar por si nos hemos cargado algo.

Ahora deberíamos volver al punto 3 con tests más complicados y repetir el proceso, por ejemplo, podíamos pasar a que el algoritmo admita sumar números decimales, etc.

Esta forma de trabajar es también muy buena para entender el código. Sabemos que la calidad del diseño de un software está también relacionada con el conocimiento del equipo de desarrollo en relación al dominio en cuestión. En este sentido, las pruebas son una muy buena forma de entender el código y su funcionamiento, muchas veces incluso mejor que la documentación.

Es una metodología de desarrollo ágil ideal para proyectos de tamaño medio desarrollados con lenguajes compilados, como páginas web desarrolladas en Action Script o aplicaciones móviles.

Metodologías Clásicas:

Las metodologías clásicas son aquellas que siguen una secuencia lógica y cada etapa es directamente dependiente de que se culmine la etapa anterior. Estas metodologías pueden ser clasificadas en:

Cascada:

El modelo en cascada es un proceso de desarrollo secuencial, en el que el desarrollo de software se concibe como un conjunto de etapas que se ejecutan una tras otra. Se le denomina así por las posiciones que ocupan las diferentes fases que componen el proyecto, colocadas una encima de otra, y siguiendo un flujo de ejecución de arriba hacia abajo, como una cascada.

Fases del modelo
El modelo de desarrollo en cascada sigue una serie de etapas de forma sucesiva, la etapa siguiente empieza cuando termina la etapa anterior.
Las fases que componen el modelo son las siguientes:
Requisitos del software
En esta fase se hace un análisis de las necesidades del cliente para determinar las características del software a desarrollar, y se especifica todo lo que debe hacer el sistema sin entrar en detalles técnicos. Hay que ser especialmente cuidadoso en esta primera fase, ya que en este modelo no se pueden añadir nuevos requisitos en mitad del proceso de desarrollo.

Esta es la etapa en la que se lleva a cabo una descripción de los requisitos del software, y se acuerda entre el cliente y la empresa desarrolladora lo que el producto deberá hacer. Disponer de una especificación de los requisitos permite estimar de forma rigurosa las necesidades del software antes de su diseño. Además, permite tener una base a partir de la cual estimar el coste del producto, los riesgos y los plazos.

En el documento en el que se especifican los requisitos, se establece una lista de los requerimientos acordados. Los desarrolladores deben comprender de forma clara el producto que van a desarrollar. Esto se consigue teniendo una lista detallada de los requisitos, y con una comunicación fluida con el cliente hasta que termine el el tiempo de desarrollo.

Diseño
En esta etapa se describe la estructura interna del software, y las relaciones entre las entidades que lo componen.

Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.

Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado. El primero de ellos tiene como objetivo definir la estructura de la solución (una vez que la fase de análisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo define los algoritmos empleados y la organización del código para comenzar la implementación.

Implementación
En esta fase se programan los requisitos especificados haciendo uso de las estructuras de datos diseñadas en la fase anterior. La programación es el proceso que lleva de la formulación de un problema de computación, a un programa que se ejecute produciendo los pasos necesarios para resolver dicho problema.

Al programar, tenemos que realizar actividades como el análisis de las condiciones, la creación de algoritmos, y la implementación de éstos en un lenguaje de programación específico.

Un algoritmo es un conjunto de instrucciones o reglas bien definidas y ordenadas que permiten llevar a cabo una actividad mediante pasos sucesivos.

Verificación
Como su propio nombre indica, una vez se termina la fase de implementación se verifica que todos los componentes del sistema funcionen correctamente y cumplen con los requisitos.

El objetivo de las pruebas es el de obtener información de la calidad del software, y sirven para: encontrar defectos o bugs, aumentar la calidad del software, refinar el código previamente escrito sin miedo a romperlo o introducir nuevos bugs, etc.

Instalación y mantenimiento
Una vez se han desarrollado todas las funcionalidades del software y se ha comprobado que funcionan correctamente, se inicia la fase de instalación y mantenimiento. Se instala la aplicación en el sistema y se comprueba que funcione correctamente en el entorno en que se va a utilizar.

A partir de ahora hay que asegurarse de que el software funcione y hay que destinar recursos a mantenerlo. El mantenimiento del software consiste en la modificación del producto después de haber sido entregado al cliente, ya sea para corregir errores o para mejorar el rendimiento o las características.

Ventajas

El tiempo que se pasa en diseñar el producto en las primeras fases del proceso puede evitar problemas que serían más costosos cuando el proyecto ya estuviese en fase de desarrollo.
La documentación es muy exhaustiva y si se une al equipo un nuevo desarrollador, podrá comprender el proyecto leyendo la documentación.
Al ser un proyecto muy estructurado, con fases bien definidas, es fácil entender el proyecto.
Ideal para proyectos estables, donde los requisitos son claros y no van a cambiar a lo largo del proceso de desarrollo.

Inconvenientes

En muchas ocasiones, los clientes no saben bien los requisitos que necesitarán antes de ver una primera versión del software en funcionamiento. Entonces, cambiarán muchos requisitos y añadirán otros nuevos, lo que supondrá volver a realizar fases ya superadas y provocará un incremento del coste.
No se va mostrando al cliente el producto a medida que se va desarrollando, si no que se ve el resultado una vez ha terminado todo el proceso. Esto cual provoca inseguridad por parte del cliente que quiere ir viendo los avances en el producto
Los diseñadores pueden no tener en cuenta todas las dificultades que se encontrarán cuando estén diseñando un software, lo que conllevará rediseñar el proyecto para solventar el problema.
Para proyectos a largo plazo, este modelo puede suponer un problema al cambiar las necesidades del usuario a lo largo del tiempo. Si por ejemplo, tenemos un proyecto que va a durar 5 años, es muy probable que los requisitos necesiten adaptarse a los gustos y novedades del mercado.

Metodo Evolutivo:

Propuesto por Mills en 1980. Sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema. Surge porque en los primeros desarrollos se podía esperar largo tiempo hasta que el software estuviese listo. Las reglas del negocio de hoy no lo permiten.

Este enfoque entrelaza las actividades de especificación, desarrollo y validación. Un sistema inicial se desarrolla rápidamente a partir de especificaciones abstractas. Éste se refina basándose en las peticiones del cliente para producir un sistema que satisfaga sus necesidades.

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar más allá, durante la fase de operación. Los modelos “Iterativo Incremental” y “Espiral” (entre otros) son dos de los más conocidos y utilizados del tipo evolutivo.

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el sistema adecuado.Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

El desarrollo evolutivo consta del desarrollo de una versión inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Las fases de especificación, desarrollo y validación se entrelazan en vez de separarse.

Características

Surge porque en los primeros desarrollos se podía esperar largo tiempo hasta que el software estuviese listo.
Permiten desarrollar versiones cada vez más completas y complejas, hasta llegar al objetivo final deseado.
Se asume que NO todos los requerimientos son conocidos desde el primer momento.
Es muy similar al modelo de desarrollo incremental.
En una primera fase, se desarrolla la primera versión, que recoge los requisitos conocidos.
Posteriormente, los usuarios utilizan el software desarrollado, generándose una nueva lista de requerimientos, con la que se desarrolla una nueva versión en la siguiente fase y así sucesivamente.
El usuario ve la materialización del proyecto más rápido que si hubiera que hacer un estudio largo para concretar las especificaciones. Además, puede modificar/añadir requerimientos sin afectar al proyecto y conseguir algo que se ajuste mejor a sus necesidades
Es un modelo compatible con el modelo de cascada y puede ser combinado con el modelo incremental.

Este tipo de modelo necesita de un proceso de ignición para poderse utilizar que consta de:

1) Iteración

Se desarrolla la primera versión, que recoge los requisitos conocidos.

2) Iteración

Los usuarios utilizan el software desarrollado, generándose una nueva lista de requerimientos, con la que se desarrolla una nueva versión en la siguiente fase y así sucesivamente.

El usuario ve la materialización del proyecto más rápido que si hubiera que hacer un estudio largo para concretar las especificaciones. Además, puede modificar/añadir requerimientos sin afectar al proyecto y conseguir algo que se ajuste mejor a sus necesidades.

Existen dos tipos de desarrollo evolutivo:

1. Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.

2. Prototipos desechables, donde el objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos para el sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Ventajas

• La especificación puede desarrollarse de forma creciente.

• Los usuarios y desarrolladores logran un mejor entendimiento del sistema. Esto se refleja en una mejora de la calidad del software.

• Es más efectivo que el modelo de cascada, ya que cumple con las necesidades inmediatas del cliente.

• Hay que implicar a los usuarios.

Desventajas

• Es difícil predecir el coste y duración de un proyecto, por lo que es conveniente limitar el número de fases, recursos y plazos si es un proyecto con principio y fin.

• Puede resultar costoso si hay que reiniciar el desarrollo.

• Hay que mantener muy bien la documentación del proyecto para facilitar el control de versiones y su mantenimiento

• Para el rápido desarrollo se necesitan herramientas que pueden ser incompatibles con otras o que poca gente sabe utilizar.

Prototipos:

La creación de prototipos consiste en construir rápida y económicamente un sistema experimental para que lo evalúen los usuarios finales. Interactuando con el prototipo, los usuarios pueden darse una mejor idea de sus requerimientos de información. El prototipo avalado por los usuarios puede servir de plantilla para crear el sistema definitivo.

El prototipo es una versión funcional de un sistema de información o de parte de éste, pero su propósito es el de servir de modelo preliminar. Una vez en operación, el prototipo se refinará más aún hasta que cumpla con precisión los requerimientos de los usuarios. Una vez finalizado el diseño, el prototipo se puede convertir en un sistema en producción refinado.

De esta manera el prototipo servirá para modelar y poder mostrar al cliente cómo va a realizarse la E/S de datos en la aplicación, de forma que éste pueda hacerse una idea de como va a ser el sistema final, pudiendo entonces detectar deficiencias o errores en la especificación aunque el modelo no sea más que una cáscara vacía.

Según esto un prototipo puede tener alguna de las tres formas siguientes:

• Un prototipo, en papel o ejecutable en ordenador, que describa la interacción hombre-máquina y los listados del sistema.

• Un prototipo que implemente algún(os) subconjunto(s) de la función requerida, y que sirva para evaluar el rendimiento de un algoritmo o las necesidades de capacidad de almacenamiento y velocidad de cálculo del sistema final.

• Un programa que realice en todo o en parte la función deseada pero que tenga características(rendimiento, consideración.

Etapas:

Recolección y refinamiento de requisitos
Modelado, diseño rápido
Construcción del Prototipo
Desarrollo, evaluación del prototipo por el cliente
Refinamiento del prototipo
Producto de Ingeniería

Ventajas

No modifica el flujo del ciclo de vida
Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios
Reduce costo y aumenta la probabilidad de éxito
Exige disponer de las herramientas adecuadas
Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.
También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina.

Para que sea efectivo

Debe ser un sistema con el que se pueda experimentar
Debe ser comparaticamente barato(menor que el 10%)
Debe desarrollarse rapidamente
Enfasis en la interfaz de usuario
Equipo de desarrollo reducido
Herramientas y lenguajes adecuadas

Desventajas

Debido a que el usuario ve que el prototipo funciona piensa que este es el producto terminado y no entienden que recién se va a desarrollar el software.
El desarrolador puede caer en la tentación de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y mantenimiento que tiene con el cliente

Tipos de Modelo de Prototipos

Modelo de Prototipos rápido: Metodología de diseño que desarrolla rápidamente nuevos diseños, los evalúa y prescinde del prototipo cuando el próximo diseño es desarrollado mediante un nuevo prototipo.
Modelo de Prototipos reutilizable: También conocido como "Evolutionary Prototyping"; no se pierde el esfuerzo efectuado en la construcción del prototipo pues sus partes o el conjunto pueden ser utilizados para construir el producto real. Mayormente es utilizado en el desarrollo de software, si bien determinados productos de hardware pueden hacer uso del prototipo como la base del diseño de moldes en la fabricación con plásticos o en el diseño de carrocerías de automóviles.
Modelo de Prototipos Modular: También conocido como Prototipado Incremental (Incremental prototyping); se añaden nuevos elementos sobre el prototipo a medida que el ciclo de diseño progresa.
Modelo de Prototipos Horizontal: El prototipo cubre un amplio número de aspectos y funciones pero la mayoría no son operativas. Resulta muy útil para evaluar el alcance del producto, pero no su uso real.
Modelo de Prototipos Vertical: El prototipo cubre sólo un pequeño número de funciones operativas. Resulta muy útil para evaluar el uso real sobre una pequeña parte del producto.
Modelo de Prototipos de Baja-fidelidad: El prototipo se implementa con papel y lápiz, emulando la función del producto real sin mostrar el aspecto real del mismo. Resulta muy útil para realizar tests baratos.
Modelo de Prototipos de Alta-fidelidad: El prototipo se implementa de la forma más cercana posible al diseño real en términos de aspecto, impresiones, interacción y tiempo.

Tipos de prototipos
Hay dos clases de prototipos el desechable y el evolucionario.

El desechable: nos sirve para eliminar dudas sobre lo que realmente quiere el cliente además para desarrollar la interfaz que más le convenga al cliente.
El evolucionario: es un modelo parcialmente construido que puede pasar de ser prototipo a ser software pero no tiene una buena documentación y calidad.

Desarrollo Basado en Componentes:

La metodología de software basada en Componentes surgió a finales de los 90's como una aproximación basada en la reutilización al desarrollo de sistemas de software. El desarrollo de software basado en componentes permite reutilizar piezas de código preelaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión. Es básicamente como cuando (si es que llevas tiempo programando) tienes ya una clase o un código guardado en algún lugar y te acuerdas de el, de manera que copeas y pegas el código en tu proyecto para usarlo, o lo conviertes en una clase y mandas llamar sus métodos, de esta manera podemos decir que es la metodología que recicla códigos.

Un Componente debe ser:

Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios que permita su clasificación.
Auto contenido: Un componente no debe requerir de la utilización de otros para finiquitar la función para la cual fue diseñado.
Puede ser remplazado por otro componente: Se puede remplazar por nuevas versiones u otro componente que lo remplace y mejore.
Con acceso solamente a través de su interfaz: Debe asegurar que estas no cambiaran a lo largo de su implementación.
Sus servicios no varían: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí.
Bien Documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
Es genérico: Sus servicios deben servir para varias aplicaciones.
Reutilizado dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
Independiente de la plataforma: Hardware, Software, S.O.

El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes. El uso de este paradigma posee algunas ventajas:

Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software.
Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema.
Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.
Ciclos de desarrollo más cortos. La adición de una pieza dada de funcionalidad tomará días en lugar de meses ó años.
Mejor ROI. Usando correctamente esta estrategia, el retorno sobre la inversión puede ser más favorable que desarrollando los componentes uno mismo.
Funcionalidad mejorada. Para usar un componente que contenga una pieza de funcionalidad, solo se necesita entender su naturaleza, más no sus detalles internos. Así, una funcionalidad que sería impráctica de implementar en la empresa, se vuelve ahora completamente asequible.

Desventajas:

Genera mucho tiempo.
Genera mucho trabajo adicional
Confiabilidad de los componentes.
Los componentes son cajas negras de unidades de programas, y el código de los componentes puede no estar disponible para los usuarios de dichos componentes.

Espiral:

El MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcción de prototipos con los aspectos controlados y sistemáticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rápido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema.

En el modelo espiral, el software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones la versión incremental podría ser un modelo en papel o un prototipo, durante las últimas iteraciones se producen versiones cada vez más completas del sistema diseñado.

Este puede ser considerado como una respuesta a los inconvenientes del desarrollo en cascada. El modelo en espiral describe el ciclo de vida de un software por medio de espirales, que se repiten hasta que se puede entregar el producto terminado. El desarrollo en espiral también se conoce como desarrollo o modelo incremental. El producto se trabaja continuamente y las mejoras a menudo tienen lugar en pasos muy pequeños.

Una característica clave del desarrollo en espiral es la minimización de los riesgos en el desarrollo de software, lo que podría resultar en un aumento de los costes totales, más esfuerzo y un lanzamiento retardado. Estos riesgos son contrarrestados por el enfoque incremental, haciendo primero prototipos, que luego pasan al menos una vez, por las fases de desarrollo de software. El desarrollo en espiral es genérico y puede combinarse con otros métodos de desarrollo clásicos y ágiles, por lo que también se denomina modelo o desarrollo de segundo orden.

EL modelo en espiral se divide en un número de actividades de marco de trabajo, también llamadas REGIONES DE TAREAS , Cada una de las regiones están compuestas por un conjunto de tareas del trabajo llamado CONJUNTO DE TAREAS que se adaptan a las características del proyecto que va a emprenderse en todos los casos se aplican actividades de protección.

Como funciona:

El modelo de desarrollo en espiral se caracteriza por los siguientes ciclos (también cuadrantes):

Objetivo y determinación alternativa: Los objetivos se determinan conjuntamente con el cliente. Al mismo tiempo, se discuten posibles alternativas y se especifican las condiciones marco (por ejemplo, sistemas operativos, entornos y lenguajes de programación).
Análisis y evaluación de riesgos: Se identifican y evalúan los riesgos potenciales. También se evalúan las alternativas existentes. Los riesgos son registrados, evaluados y luego reducidos utilizando prototipos, simulaciones y softwares de análisis. En este ciclo, existen varios prototipos como plantillas de diseño o componentes funcionales
Desarrollo y prueba: Los prototipos se amplían y se añaden funcionalidades. El código real es escrito, probado y migrado a un entorno de prueba varias veces hasta que el software pueda ser implementado en un entorno productivo.
Planificación del siguiente ciclo: El siguiente ciclo se planifica al final de cada etapa. Si se producen errores, se buscan soluciones, y si una alternativa es una mejor solución, se prefiere en el siguiente ciclo.

La fuerza impulsora más importante del desarrollo en espiral es el análisis y la evaluación de riesgos. Cualquier riesgo que amenace el proyecto debe ser identificado desde el principio. El progreso del proyecto depende decisivamente de cómo se puedan eliminar los riesgos. El proyecto se considera exitoso sólo cuando no hay riesgos. El objetivo del ciclo es producir un producto en continua mejora. El software o la aplicación se perfecciona constantemente. El modelo en espiral es incremental, pero no necesariamente repetitivo. Las repeticiones ocurren sólo cuando los riesgos, errores o conflictos amenazan el proyecto. Entonces el producto tiene que pasar por un ciclo de nuevo, llamado una iteración o repetición.

Beneficios / Desventajas

El modelo de desarrollo en espiral se utiliza a menudo para proyectos más grandes que están sujetos a riesgos. Dado que estos riesgos tienen un impacto monetario directo, el control de los presupuestos de los clientes y de las empresas promotoras es fundamental. El modelo en espiral se utiliza especialmente en los nuevos entornos técnicos, ya que éstos suponen un riesgo.
Los conflictos entre los requisitos de un software y su diseño se evitan eficazmente mediante el enfoque cíclico, ya que los requisitos pueden comprobarse constantemente y, si es necesario, modificarse.
Se puede obtener feedback de los usuarios, desarrolladores y clientes en las primeras fases del proyecto. Sin embargo, esta estructura también requiere una gestión que tenga en cuenta los ciclos del producto y pueda responder rápidamente a los riesgos. El control de tales proyectos es, por lo tanto, relativamente complejo y también requiere una buena documentación para que se registren todos los cambios.
Aunque el software se prueba bajo varios aspectos durante el ciclo de desarrollo y prueba (unidad, prueba de aceptación e integración), a menudo sucede que los prototipos se transfieren al sistema de producción. Por lo tanto, existe el riesgo de que se introduzcan otros errores e incoherencias conceptuales en el producto final posterior.
En los lugares donde se toman decisiones sobre los ciclos siguientes, existe el riesgo de que se formen bucles y el proyecto tarde más tiempo si se toman decisiones equivocadas. Por esta razón, las alternativas y su evaluación son importantes.

Incremental:

El modelo incremental combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos. Se basa en la filosofía de construir incrementando las funcionalidades del programa. Este modelo aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento del software. En cada incfemento, el producto debe mostrar una evolución con respecto a la fecha anterior; nunca puede ser igual.

Cuando se utiliza un modelo incremental, el primer incremento es a menudo un producto esencial, sólo con los requisitos básicos. Este modelo se centra en la entrega de un producto operativo con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que precisa y también una plataforma para la evaluación.

La principal diferencia del modelo incremental con los modelos tradicionales es que las tareas están divididas en iteraciones, es decir, pequeños lapsos en los cuales se trabaja para conseguir objetivos específicos. Con los modelos tradicionales no pasaba esto; era necesario esperar hasta el final del proceso.

Sin embargo, no se trata de iteraciones independientes. Por el contrario, están vinculadas de forma que cada una suponga un avance con respecto a la anterior. Otras características esenciales de este modelo son:

Los incrementos son pequeños.
Permite una fácil administración de las tareas en cada iteración.
La inversión se materializa a corto plazo.
Es un modelo propicio a cambios o modificaciones.
Se adapta a las necesidades que surjan.

Para que esto sea posible, se debe tener en cuenta que las iteraciones no pueden ser demasiado rígidas y que no existan tareas simultáneas. El modelo incremental exige un encadenamiento progresivo de cada tarea. Scrum y Kanban son las herramientas más conocidas que emplean este modelo de gestión.

Fases:

El modelo de gestión incremental no es un modelo necesariamente rígido, es decir, que puede adaptarse a las características de cualquier tipo de proyecto, existen al menos 7 fases que debemos tener en cuenta a la hora de implementarlo:

Requerimientos: son los objetivos centrales y específicos que persigue el proyecto.
Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el siguiente paso es hacer una lista de tareas y agruparlas en las iteraciones que tendrá el proyecto. Esta agrupación no puede ser aleatoria. Cada una debe perseguir objetivos específicos que la definan como tal.
Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será la evolución del producto en cada una de ellas. Cada iteración debe superar a la que le ha precedido. Esto es lo que se denomina incremento.
Desarrollo del incremento: posteriormente se realizan las tareas previstas y se desarrollan los incrementos establecidos en la etapa anterior.
Validación de incrementos: al término de cada iteración, los responsables de la gestión del proyecto deben dar por buenos los incrementos que cada una de ellas ha arrojado. Si no son los esperados o si ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de ello.
Integración de incrementos: una vez son validados, los incrementos dan forma a lo que se denomina línea incremental o evolución del proyecto en su conjunto. Cada incremento ha contribuido al resultado final.
Entrega del producto: cuando el producto en su conjunto ha sido validado y se confirma su correspondencia con los objetivos iniciales, se procede a su entrega final.

Ventajas
Entre las ventajas que puede proporcionar un modelo de este tipo encontramos las siguientes:

Mediante este modelo se genera software operativo de forma rápida y en etapas tempranas del ciclo de vida del software.
Es un modelo más flexible, por lo que se reduce el coste en el cambio de alcance y requisitos.
Es más fácil probar y depurar en una iteración más pequeña.
Es más fácil gestionar riesgos.
Cada iteración es un hito gestionado fácilmente

Inconvenientes

Para el uso de este modelo se requiere una experiencia importante para definir los incrementos y distribuir en ellos las tareas de forma proporcionada. Entre los inconvenientes que aparecen en el uso de este modelo podemos destacar los siguientes:

Cada fase de una iteración es rígida y no se superponen con otras.
Pueden surgir problemas referidos a la arquitectura del sistema porque no todos los requisitos se han reunido, ya que se supone que todos ellos se han definido al inicio

Características

Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.
El usuario se involucre más.
Difícil de evaluar el costo total.
Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.
Requiere gestores experimentados.
Los errores en los requisitos se detectan tarde.
El resultado puede ser muy positivo.