Articles

Métodos Agiles en el Desarrollo de Software

In Uncategorized on febrero 9, 2012 by j0sephandres Etiquetado: , , , , , , , , ,

eXtreme Programming (XP) 

La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck.

Es un nuevo enfoque para desarrollo basado en el desarrollo y entrega de incrementos de funcionalidad muy pequeños. Depende de mejoramiento de código constante, involucramiento del usuario en el equipo desarrollador y programación interactiva.

SCRUM

El Scrum es un proceso de desarrollo iterativo e incremental enfocado a la gestión de procesos de desarrollo de software, aunque también puede ser utilizado en equipos de mantenimiento de software, que sirve para administrar y controlar el desarrollo de sistemas.
Esta metodología, inicialmente documentada por dos japoneses (Takeuchi y Nonaka) en 1986 y con aportes de especialistas (Sutherland y Schwaber) a lo largo de la última década, tiende a hacer que los procesos que influyen en el desarrollo de tecnología se incrementen en rapidez y flexibilidad, siempre tomando en cuenta los tiempos y reglas de negocio que dan motivo al desarrollo del proyecto.

RUP (Rational Unified Process) 

es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental.

El RUP está basado en 6 principios clave que son los siguientes:

Adaptar el proceso
El proceso deberá adaptarse a las necesidades del cliente ya que es muy importante interactuar con él. Las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto en un área subformal.

Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.

Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados

Colaboración entre equipos
El desarrollo de software no lo hace una única persona sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.

Elevar el nivel de abstracción
Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilización del código.

Enfocarse en la calidad
El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

Crystal 

Crystal es una metodología de desarrollo de Software ágil, más que una metolodogía se la considera una familia de metodologías, debido a que se subdivide en varios tipos de metodologías en función a la cantidad de persona que vayan a estar en el proyecto. Es una metodología que ha sido creada por una persona en particular (Alistair Cockburn ) el cuál llego la creó en base al análisis de distintos proyectos de desarrollo de SW y su propia experiencia, lo cuál fusionando ambos aspectos dio lugar a esta metodología.

LEAN

El movimiento de Lean Development o Desarrollo minimalista (traducción libre y propia) nació de los equipos de desarrollo de la industria automotriz. La idea que refuerza es básicamente la optimización del proceso para desarrollar más rápido y barato, obteniendo el mejor resultado para el cliente. Afortunadamente, su éxito ha dado paso a prácticas que son seguidas por la mayoría de los fabricantes para mantenerse competitivos. En el mundo del desarrollo de software, este movimiento está estrechamente relacionado con las metodologías ágiles y cómo no, con el movimiento de Software Craftsmanship. La idea es sencilla, aplicar los mismo principios al proceso de desarrollo de software, para obtener el mismo resultado.

La correcta aplicación de los principios Lean, conducen a un software más barato pero también de mayor calidad.

Los siete principios Lean son:

Eliminar el desperdicio: cualquier cosa que no añada valor al producto final ha de ser eliminada.

Incrementar la retroalimentación: para ello el desarrollo basado en iteraciones como hacen Scrum o XP son fundamentales a la hora de obtener retroalimentación lo antes posible.

Postergar el compromiso: posterga las decisiones irreversibles hasta último momento, de esta manera podrás tomarlas con más conocimiento. Rompe con las dependencias y desacopla tus componentes.

Entregar rápido y temprano: así podrás permitirte retardar el compromiso
Dar el poder al equipo: son los que más cerca están de la información, por lo tanto los mejores para tomar decisiones.

Construir con integridad: refuerza el equipo centrado en el producto, refactoriza el código para mantenerlo limpio y a ser posible, utiliza TDD para asegurar la mayor cobertura y mejor diseño.

Tener visión global: las métricas han de ser de alto nivel y no de bajo nivel. Tener métricas de bajo nivel promueve la micro optimización, que tiende a la sub optimización. En cambio tener métricas de alto nivel garantiza la optimización global.

El resultado de utilizar estos principios es un proceso de desarrollo mejor, más barato, centrado en la calidad y los requerimientos y mucho más rápido y ágil. Adoptar estos como parte de ALM ágil, ya sea utilizando Scrum, XP o tu propia metodología, no sólo es perfectamente compatible, sino recomendable.

DRA

El Desarrollo Rápido de Aplicaciones (DRA) (rapid application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a “Alta velocidad” en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un “sistema completamente funcional” dentro de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información, el enfoque DRA comprende las siguientes fases:

Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que responda a las siguientes preguntas: ¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde va la información? ¿Quién la proceso?

Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características (llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan transformados para lograr el flujo de información necesario para implementar una función de gestión. Las descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la comunicación entre los objetos.

Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables (cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los componentes nuevos y se deben ejercitar todas las interfases a fondo.

KANBAN

kanban es un término que proviene del japonés y que puede traducirse al español como “etiqueta de instrucción” o tarjeta. Dentro del marco de desarrollo de software es una metodología que viene de la filosofía Lean Software Development (que a su vez provienen del Lean Manufacturing).

Kanban comparte con otras metodologías como Feature Driven Development o SCRUM la idea de crear un Backlog del producto que tenga una serie de items (user stories, features…) priorizados. Pero la principal diferencia con otras aproximaciones ágiles, es que en Kanban no existen las iteraciones.

En su lugar, Kanban se centra en controlar el WIP (Work In Progress). Esto es, cuando hay poco WIP, se añade el item más prioritario del Product Backlog, y se controla que nunca se supere una cierta cantidad de WIP.

Dadas sus características, no se adapta a un desarrollo basado en entregas, y actualmente se utiliza especialmente en entornos de mantenimiento (corrección de bugs, etc.).

MSF (Microsoft® Solutions Framework)

Microsoft® Solutions Framework es un marco de trabajo de referencia para construir e implantar sistemas empresariales distribuidos basados en herramientas y tecnologías de Microsoft. MSF comprende un conjunto de modelos, conceptos y guías que contribuyen a alinear los objetivos de negocio y tecnológicos, reducir los costos de la utilización de nuevas tecnologías, y asegurar el éxito en la implantación de las tecnologías Microsoft. MSF es el resultado de las experiencias de diferentes áreas de Microsoft con proyectos exitosos.

MSF representa una base de conocimientos y recursos que proveen información sobre:

  • Planeación de la arquitectura empresarial, enfocada a realizar planes a largo plazo al tiempo que permite lograr resultados a corto y mediano plazo.
  • Una disciplina de desarrollo de soluciones basada en modelos que permiten organizar equipos de trabajo efectivos y administrar exitosamente el ciclo de vida de los proyectos.
  • Un proceso de diseño de soluciones que apoya el diseño de sistemas distribuidos complejos.
  • Un enfoque de implantación de infraestructura que emplea los modelos de equipos y procesos como apoyo fundamental en la implantación y operación de las soluciones tecnológicas.

OpenUP

OpenUP es un método y un proceso de desarrollo de software propuesto por un conjunto de empresas de tecnología,1 quienes lo donaron en el año 2007 a la Fundación Eclipse. La fundación lo ha publicado bajo una licencia libre2 y lo mantiene como método de ejemplo dentro del proyecto Eclipse Process Framework.

Principios del OpenUP

  • Colaborar para sincronizar intereses y compartir conocimiento. Este principio promueve prácticas que impulsan un ambiente de equipo saludable, facilitan la colaboración y desarrollan un conocimiento compartido del proyecto.
  • Equilibrar las prioridades para maximizar el beneficio obtenido por los interesados en el proyecto. Este principio promueve prácticas que permiten a los participantes de los proyectos
  • desarrollar una solución que maximice los beneficios obtenidos por los participantes y que cumple con los requisitos y restricciones del proyecto.
  • Centrarse en la arquitectura de forma temprana para minimizar el riesgo y organizar el desarrollo.
  • Desarrollo evolutivo para obtener retroalimentación y mejoramiento continuo. Este principio promueve prácticas que permiten a los equipos de desarrollo obtener retroalimentación temprana y continua de los participantes del proyecto, permitiendo demostrarles incrementos progresivos en la funcionalidad.


Empresarial Up

es una variante extendida del Rational Unified Process y fue desarrollado por Scott W. Ambler y Larry Constantino en el año 2000, con el tiempo reelaborado en 2005 por Ambler, Nalbone John y Michael Vizdos .

EUP fue introducido para superar la escasez de algunos de RUP, es decir, la falta de apoyo al sistema y eventual retiro de un sistema de software. Por lo tanto dos fases y varias nuevas disciplinas se han añadido a las RUP.

EUP ve el desarrollo de software, no como una actividad independiente, sino integrada en el ciclo de vida del sistema (que se construirá o mejorado o sustituido), el ciclo de vida de la empresa y el ciclo de vida de la organización / negocio de la empresa en sí misma. Las  ofertas con el desarrollo de software como se ve desde el punto de vista del cliente.

About these ads

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

%d personas les gusta esto: