top of page

Tendencias en la Ingeniería de Software


Hoy en día podemos echar mano de modelos que son tendencia en la actualidad por razones de velocidad, costo y manera de solucionar conflictos. Estos principalmente son:

  • XP (Programación Extrema).

  • Scrum.

  • Desarrollo manejado por rasgos.

  • DSDM (Método de desarrollo en Sistemas Dinámicos).

SCRUM.

Scrum es una metodología ágil y flexible para gestionar el desarrollo de software, cuyo principal objetivo es maximizar el retorno de la inversión para su empresa (ROI). Se basa en construir primero la funcionalidad de mayor valor para el cliente y en los principios de inspección continua, adaptación, auto-gestión e innovación.

Con la metodología Scrum el cliente se entusiasma y se compromete con el proyecto dado que lo ve crecer iteración a iteración. Asimismo le permite en cualquier momento realinear el software con los objetivos de negocio de su empresa, ya que puede introducir cambios funcionales o de prioridad en el inicio de cada nueva iteración sin ningún problema. Esta metódica de trabajo promueve la innovación, motivación y compromiso del equipo que forma parte del proyecto, por lo que los profesionales encuentran un ámbito propicio para desarrollar sus capacidades.

Los beneficios que logramos obtener son:

  • El cliente establece sus expectativas indicando el valor que le aporta cada requisito / historia del proyecto, el equipo los estima y con esta información el Product Owner establece su prioridad. De manera regular, en las demos comprueba que efectivamente los requisitos se han cumplido y transmite se feedback al equipo.Cumplimento de expectativas

  • Alta capacidad de reacción ante los cambios de requerimientos generados por necesidades del cliente o evoluciones del mercado. La metodología está diseñada para adaptarse a los cambios de requerimientos que conllevan los proyectos complejos.Flexibilidad a cambios

  • El cliente puede empezar a utilizar las funcionalidades más importantes del proyecto antes de que esté finalizado por completo.Reducción del Time to Market

  • La metódica de trabajo y la necesidad de obtener una versión funcional después de cada iteración, ayuda a la obtención de un software de calidad superior.Mayor calidad del software

  • Se consigue entre otras razones, gracias a la eliminación de la burocracia y a la motivación del equipo que proporciona el hecho de que sean autónomos para organizarse.Mayor productividad

  • Producción de software únicamente con las prestaciones que aportan mayor valor de negocio gracias a la priorización por retorno de inversión.Maximiza el retorno de la inversión (ROI)

  • Mediante esta metodología se conoce la velocidad media del equipo por sprint (los llamados puntos historia), con lo que consecuentemente, es posible estimar fácilmente para cuando se dispondrá de una determinada funcionalidad que todavía está en el Backlog.Predicciones de tiempos

  • El hecho de llevar a cabo las funcionalidades de más valor en primer lugar y de conocer la velocidad con que el equipo avanza en el proyecto, permite despejar riesgos eficazmente de manera anticipada. Reducción de riesgos

XP (PROGRAMACIÓN EXTREMA).

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.

Pero ¿Qué es la Programación Extrema en general?

  • Metodología liviana de desarrollo de software.

  • Conjunto de practicas y reglas empleadas para desarrollar software.

  • Basada en diferentes ideas acerca de cómo enfrentar ambientes muy cambiantes.

  • Originada en el proyecto C3 para Chrysler.

  • En vez de planificar, analizar y diseñar para el futuro distante, hacer todo esto un poco cada vez, a través de todo el proceso de desarrollo.

El principal objetivo de la Programación Extrema es establecer las mejores prácticas de Ingeniería de Software en el desarrollo de proyectos, mejorando su productividad, garantiza la calidad del mismo y logra superar las expectativas del cliente.

Podemos contextualizar que en la Metodología XP el cliente se encuentra bien definido debido a que lo requisitos pueden variar. Los grupos de trabajo se integran en un máximo de doce personas con un desarrollo profesional elevado pero con ´propuesta de aprendizaje.

El funcionamiento del modelo de Practicas Extremas se basa en doce practicas básicas:

  • Forman parte del equipo todas las personas que tienen algo que ver con el proyecto, incluido el cliente y el responsable del proyecto.Equipo completo

  • 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.Planificación

  • El cliente, con la ayuda de los desarrolladores, propone sus propias pruebas para validar las mini-versiones.Test del cliente

  • 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.Versiones pequeñas.

  • Hacer siempre lo mínimo imprescindible de la forma más sencilla posible. Mantener siempre sencillo el código.Diseño simple

  • Los programadores trabajan por parejas (dos delante del mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).Pareja de programadores

  • Se deben realizar programas de prueba automática y deben ejecutarse con mucha frecuencia. Cuantas más pruebas se hagan, mejor.Desarrollo guiado por las pruebas automáticas

  • 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.Integración continua

  • Cualquiera puede y debe tocar y conocer cualquier parte del código. Para eso se hacen las pruebas automáticas.El código es de todos

  • Debe haber un estilo común de codificación (no importa cual), de forma que parezca que ha sido realizado por una única persona.Normas de codificación

  • 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.Metáforas

  • 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.Ritmo sostenible

DESARROLLO MANEJADO POR RASGOS.

El Desarrollo Manejado por Rasgos (FDD por su sigla en inglés de Feature-Driven Development) fue desarrollado por Jeff De Luca y el viejo gurú de la Orientación a Objetos Peter Coad. Como las otras metodologías adaptables, se enfoca en iteraciones cortas que entregan funcionalidad tangible. En el caso del FDD las iteraciones duran dos semanas.

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

  • Desarrollar un Modelo Global

  • Construir una Lista de los Rasgos

  • Planear por Rasgo

  • Diseñar por Rasgo.

  • Construir por Rasgo

Los últimos dos se hacen en cada iteración. Cada proceso se divide en tareas y se da un criterio de comprobación. Los desarrolladores entran en dos tipos:

  • Dueños de clases, y

  • Programadores jefe.

Los programadores jefe son los desarrolladores más experimentados. A ellos se les asignan rasgos a construir. Sin embargo ellos no los construyen solos. Sólo identifican qué clases se involucran en la implantación de un rasgo y juntan a los dueños de dichas clases para que formen un equipo para desarrollar ese rasgo. El programador jefe actúa como el coordinador, diseñador líder y mentor, mientras los dueños de clases hacen gran parte de la codificación del rasgo.

MÉTODO DE DESARROLLO DE SISTEMAS DINAMICOS (DSDM).

El DSDM (Dynamic Systems Development Method) empezó en Gran Bretaña en 1994 como un consorcio de compañías del Reino Unido que querían construir sobre RAD (Rapid Applications Development) Desarrollo Rápido de Aplicaciones y desarrollo iterativo. Habiendo empezado con 17 fundadores ahora tiene más de mil miembros y ha crecido fuera de sus raíces británicas. Siendo desarrollado por un consorcio, tiene un sabor diferente a muchos de los otros métodos ágiles. Tiene una organización de tiempo completo que lo apoya con manuales, cursos de entrenamiento, programas de certificación y demás. Pero, también lleva una etiqueta de precio, lo cual ha limitado la investigación popular sobre su metodología. Sin embargo, Jennifer Stapleton ha escrito el libro “DSDM” que da una apreciación global de la metodología.

El método empieza con un estudio de viabilidad y negocio. El estudio de viabilidad considera si DSDM es apropiado para el proyecto. El estudio de negocio es una serie corta de talleres para entender el área de negocio donde tiene lugar el desarrollo. También propone esbozos de arquitecturas del sistema y un plan del proyecto. El resto del proceso forma tres ciclos entretejidos:

  • El ciclo del modelo funcional produce documentación de análisis y prototipos,

  • El ciclo de diseño del modelo diseña el sistema para uso operacional, y

  • El ciclo de implantación se ocupa del despliegue al uso operacional.

DSDM tiene principios subyacentes que incluyen una interacción activa del usuario, entregas frecuentes, equipos autorizados, pruebas a lo largo del ciclo. Igual que otros métodos ágiles, usan ciclos de plazos cortos de entre dos y seis semanas. Hay un énfasis en la alta calidad y adaptabilidad hacia requisitos cambiantes.

No hay mucha evidencia de su uso fuera del Reino Unido, pero DSDM es notable por tener mucha de la infraestructura de las metodologías tradicionales más maduras, al mismo tiempo que sigue los principios de los métodos ágiles.

Como ya es muy conocido. La Ingeniería de Software tiene como principal objetivo desarrollar sistemas confiables y seguros a menor costo y tiempo. Logrando solucionar problemas complejos de una manera más eficiente en todos los aspectos.

Entradas relacionadas

Ver todo
vShopping
bottom of page