lunes, 17 de noviembre de 2014

METODOLOGÍAS ÁGILES


Fecha de clase: Lunes, 17 de noviembre del 2014
INTRODUCCIÓN

Esta clases se inició con el narrador de la clase y los expositores luego la docente empezó a explicar sobre las metodologías ágiles que es la forma más óptima de acoplarse a nuevos requerimientos en la creación de proyecto lo principal de esta clase es dar a conocer los principales sistemas agiles en la construcción de software.
.

MARCO TEÓRICO

METODOLOGÍA ÁGIL

La historia de la ingeniería de software está salpicada de decenas de descripciones y metodologías de proceso, métodos de modelado y notaciones, herramientas y tecnología, todos ellos obsoletos. Cada uno tuvo notoriedad y luego fue eclipsado por algo nuevo y (supuestamente) mejor. Con la introducción de una amplia variedad de modelos ágiles del proceso —cada uno en lucha por la aceptación de la comunidad de desarrollo de software— el movimiento ágil está siguiendo la misma ruta histórica.

PRINCIPIOS DE AGILIDAD

1. La prioridad más alta es satisfacer al cliente a través de la entrega pronta y continua de software valioso.

2. Son bienvenidos los requerimientos cambiantes, aun en una etapa avanzada del desarrollo. Los procesos ágiles dominan el cambio para provecho de la ventaja competitiva del cliente.

3. Entregar con frecuencia software que funcione, de dos semanas a un par de meses, de preferencia lo más pronto que se pueda.

4. Las personas de negocios y los desarrolladores deben trabajar juntos, a diario y durante todo el proyecto.

5. Hay que desarrollar los proyectos con individuos motivados. Debe darse a éstos el ambiente y el apoyo que necesiten, y confiar en que harán el trabajo.

6. El método más eficiente y eficaz para transmitir información a los integrantes de un equipo de desarrollo, y entre éstos, es la conversación cara a cara.

7. La medida principal de avance es el software que funciona.

8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores, desarrolladores y usuarios deben poder mantener un ritmo constante en forma indefinida.

9. La atención continua a la excelencia técnica y el buen diseño mejora la agilidad.

10. Es esencial la simplicidad: el arte de maximizar la cantidad de trabajo no realizado.

11. Las mejores arquitecturas, requerimientos y diseños surgen de los equipos con organización propia.

12. El equipo reflexiona a intervalos regulares sobre cómo ser más eficaz, para después afinar y ajustar su comportamiento en consecuencia.


Un modelo de desarrollo ágil es un proceso incremental con pequeñas entregas de software ya que el software va evolucionando y necesita de nuevas características o nuevos requerimientos.

El más usado de todos los modelos ágiles de proceso es la programación extrema (XP). (Pressman, R.)
Pero se han propuesto muchos otros y están en uso en toda la industria. Entre ellos se encuentran los siguientes:

• SCRUM. Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito durante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

• Crystal Methodologies. Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas. Estas políticas dependerán del tamaño del equipo, estableciéndose una clasificación por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a 50 miembros).

• Dynamic Systems Development Method (DSDM). Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo de crear una metodología RAD unificada. Sus principales características son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fases.

• Adaptive Software Development (ASD). Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida que propone tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la primera de ellas se inicia el proyecto y se planifican las características del software; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

• Feature -Driven Development (FDD) .Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de características que debe reunir elsoftware. Sus impulsores son Jeff De Luca y Peter Coad.

• Lean Development (LD) .Definida por Bob Charette’s a partir de su experiencia en proyectos con la industria japonesa del automóvil en los años 80 y utilizada en numerosos proyectos de telecomunicaciones en Europa. En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios. (Canós, J)


CONCLUSIÓN

Las metodologías agiles son requeridas mucho en el desarrollo del proceso de software ya q estas metodologías permiten realizar pequeños incremento al equipo de desarrollo sin generar problemas ya que pasaría por lo mismo que todo el proceso de desarrollo es decir todas las actividades de desarrollo de software.


BIBLIOGRAFÍA

Canós, J. 2005. Metodología Ágil. Formato (PDF). En línea. Disponible en: http://noqualityinside.com/nqi/nqifiles/XP_Agil.pdf

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición


lunes, 10 de noviembre de 2014

PROCESO UNIFICADO

Fecha de clase: Lunes, 10 de noviembre del 2014


INTRODUCCIÓN

Esta clases se inició con el narrador de la clase y los expositores  con un tema muy interesante como es el proceso unificado; el Proceso Unificado no es simplemente un proceso, sino un marco de trabajo que puede ser adaptado a organizaciones o proyectos específicos para así llegar a cumplir el objetivo planteado.
El proceso Unificado reconoce la importancia de la comunicación con el cliente y los métodos  directos para describir su punto de vista respecto de un sistema.

MARCO TEÓRICO

PROCESO UNIFICADO

El Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es un conjunto de actividades necesarias para transformar los requerimientos del usuario en un sistema de software. El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado 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 refinamiento más conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. (Stephen, R; Schach, D)

FASES DEL PROCESO UNIFICADO

La fase de concepción del PU agrupa actividades tanto de comunicación con el cliente como de planeación. Al colaborar con los participantes, se identifican los requerimientos del negocio, se propone una arquitectura aproximada para el sistema y se desarrolla un plan para la naturaleza iterativa e incremental del proyecto en cuestión.
La fase de elaboración incluye las actividades de comunicación y modelado del modelo general el proceso. La elaboración mejora y amplía los casos de uso preliminares desarrollados como parte de la fase de concepción y aumenta la representación de la arquitectura para incluir cinco puntos de vista distintos del software: los modelos del caso de uso, de requerimientos, del diseño, de la implementación y del despliegue.
La fase de construcción del PU es idéntica a la actividad de construcción definida para el proceso general del software. Con el uso del modelo de arquitectura como entrada, la fase de construcción desarrolla.
La fase de transición del PU incluye las últimas etapas de la actividad general de construcción y la primera parte de la actividad de despliegue general (entrega y retroalimentación). Se da el software a los usuarios finales para las pruebas beta, quienes reportan tanto los defectos como los cambios necesarios.
La fase de producción del PU coincide con la actividad de despliegue del proceso general. Durante esta fase, se vigila el uso que se da al software, se brinda apoyo para el ambiente de operación (infraestructura) y se reportan defectos y solicitudes de cambio para su evaluación. (Pressman, R.)

CARACTERÍSTICAS DEL PROCESO UNIFICADO:

- Soporta técnicas orientadas a objeto, por lo que se basa en los conceptos de clase y objeto y las relaciones entre ellos, usando UML como notación común.
- Es una metodología que sigue un proceso iterativo e incremental. Propone una descomposición incremental del problema a través de refinamientos sucesivos y una producción incremental de la solución, a través de la realización de varios ciclos. Esta filosofía es lógica cuando se aplica a sistemas grandes ya que “no se puede abarcar todo a la vez”.
- El PU está dirigido por el riesgo. Esta es una de las características fundamentales del este modelo, y propone identificar, afrontar y resolver los elementos de riesgo lo más pronto posible. En etapas iniciales se desarrollan las funcionalidades con mayor riesgo y las de mayor complejidad. De este modo se mejoran las posibilidades de éxito del proyecto.
- Se utilizan modelos gráficos de representación más que documentación, en particular se usan diagramas UML que son representaciones expresivas y pueden aplicarse durante todo el desarrollo.
- El PU está centrado en la arquitectura software. La arquitectura del software para el sistema en desarrollo se define al principio y guía su desarrollo. Propone la definición de una arquitectura robusta, lo que facilita el desarrollo del sistema en paralelo, aumentando las posibilidades de reutilización de componentes y el mantenimiento del sistema. El diseño arquitectónico aporta una base sólida sobre la que planificar y gestionar el desarrollo software basado en componentes. Al basarse en la definición de una arquitectura clara y sencilla, el PU sirve de marco común para toda una familia de procesos y que puede acomodarse a distintas situaciones. Para ello, el PU da las guías para configurar el proceso de modo que se adapte a cada situación.
- EL PU está dirigido por los casos de uso. Esto es así porque el PU pone gran énfasis en la construcción de sistemas basados en la comprensión de cómo se va a utilizar ese sistema. Así, los casos de uso y los escenarios se usan para guiar el flujo de procesos, desde la definición de los requisitos hasta las pruebas.
- El PU es un proceso adaptable a los distintos tipos de desarrollo y se puede configurar dependiendo de las necesidades de cada proyecto (desde los más sencillos a los más complejos).
- Control continuo de la calidad. El PU propone llevar un adecuado control de calidad y una adecuada gestión de riesgos. Ambos conceptos están incluidos en el propio proceso, formando parte de sus actividades. (Stephen, R; Schach, D)

CONCLUSIÓN

Un proceso es la parte que lleva al objetivo principal, es un conjunto de pasos ordenados  que al finalizarlos se alcanza un objetivo. 
En  ingeniería de software, el objetivo es construir un producto de software nuevo o  extender uno existente obteniendo las características deseadas



BIBLIOGRAFÍA

Stephen, R; Schach, D. 2005. Proceso unificado. Formato (PDF). En línea. Disponible en: http://es.slideshare.net/bebeyom/proceso-unificado

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición