lunes, 22 de junio de 2015

Cap 3 - QA&V Ciclo de vida del Desarrollo de Software Parte - 2

QA&V Ciclo de vida del desarrollo de Software Parte - 2

(QA&V Software Development Life Cycle)

3.2.2.5 Modelo Prototipo:
Este modelo de desarrollo de software se basa en la creación de prototipos con base en los requerimientos del cliente, este modelo está constituido en 4 fases principales:
  • Definición de los requerimientos básicos.
  • Creación del prototipo de trabajo.
  • Verificación del prototipo.
  • Cambio o elaboración de los requerimientos.

Todo esto para la creación de un método de trabajo rápido y aplicable al proyecto donde los requerimientos del sistema no son del todo claros al inicio o donde los desarrolladores no tienen bien establecidos los algoritmos o la estructura del software. (Softtek, 2013)

Existen dos tipos principales de prototipos:
  • Evolutivo: Donde el objetivo del prototipo es liberar y mostrar el trabajo a los usuarios finales, esto es usado por sistemas donde las especificaciones del proyecto no están del todo claras, y donde la verificación es imposible debido a que no hay especificaciones.
  • Desechables: El objetivo de los desechables es validar u obtener los requerimientos del sistema. Los desechables o prototipos rápidos, hacen referencia a la creación de un modelo que es eventualmente descartado conforme se llega a la parte final del software. Después de que los requerimientos preliminares fueron establecidos, un modelo simple del sistema es construido para poder mostrar al cliente cómo es que los usuarios verán la aplicación, y con ello ir definiendo poco a poco los requerimientos finales a implementar para que se genere un proyecto de calidad.  (Society, 1998)


El ciclo del prototipo es:
  • Identificar la base de los requerimientos.
  • Desarrollar el prototipo inicial.
  • Obtener una revisión de los usuarios finales y clientes.
  • Basado en esa revisión, revisar la utilidad del prototipo y valorar si es lo que el cliente necesita.



Ilustración 8 Modelo evolutivo.
Fuente: Elaboración Propia.
·         Ventajas:

·         El modelo puede ser usado cuando los requerimientos están o no están especificados.
·         El usuario puede experimentar con el sistema para mejorar los requerimientos.
·         Desventajas:

·         El uso de este método es exploratorio, lo que genera tener siempre un alto riesgo y por ello se necesita un manejo estricto de situaciones en las que se encuentre el proyecto.
·         Este método puede ser usado incluyendo o no la documentación del diseño, siempre que sean entendidos perfectamente.


3.2.2.6 Modelo V:
El modelo V es la evolución del modelo en cascada, es un modelo secuencial y en cada paso finalizado se inicia el comienzo de la próxima fase, y una vez que se llega al fondo del modelo (ver Ilustración 9) se vuelve a subir simulando una V.
Las pruebas son mucho más exhaustivas en este modelo a comparación del modelo en cascada, y las pruebas son más sencillas, así como también más eficaces, mejorando la calidad en el desarrollo de los productos. (Ángel, 2013)
                                              



Ilustración 9 Modelo V.
Fuente: Elaboración Propia.
·         Ventajas:

·         Simple y fácil de usar.
·         Para cada fase existe un entregable.
·         Tiene una gran probabilidad de que el proyecto sea terminado satisfactoriamente.
·         El flujo de trabajo funciona muy bien cuando los requerimientos están bien entendidos.


·         Desventajas:

·         Es poco flexible, como el modelo en cascada.

·         Ajustar los calendarios de trabajo es difícil y muy caro.

·         El modelo no está diseñado para un camino sencillo a la hora de encontrar problemas durante la fase de desarrollo.

 

3.2.3 Modelos Ágil

El manifiesto de los modelos ágil establece la diferencia con los modelos tradicionales, este manifiesto indica lo siguiente:

·         Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas. La gente es el principal factor de éxito de un proyecto de software. Es más importante construir un buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el entorno y esperar que el equipo se adapte automáticamente. Es mejor crear el equipo y que éste configure su propio entorno de desarrollo con base en sus necesidades.

·         Se debe desarrollar software que funciona más que conseguir una buena documentación. La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. Estos documentos deben ser cortos y centrarse en lo fundamental.

·         Buscar o preferir la colaboración con el cliente más que la negociación de un contrato. Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración entre ambos será la que marque la marcha del proyecto y asegure su éxito. (Amaro Calderón, 2007)

·         Responder a los cambios más que seguir estrictamente un plan. La habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
Este manifiesto tiene doce puntos:

  1. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor.

  1. Dar la bienvenida a los cambios. Se capturan los cambios para que el Cliente tenga una ventaja competitiva.

  1. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas.

  1. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.

  1. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

  1. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo.

  1. El software que funciona es la medida principal de progreso.

  1. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante.

  1. La atención continua a la calidad técnica y al buen diseño mejora la agilidad.

  1. La simplicidad es esencial.

  1. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos.

  1. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. (Amaro Calderón, 2007)



3.2.3.1 XP- extreme Programming:
XP es la primera metodología ágil y la que le dio conciencia al movimiento actual de metodologías ágiles, creada a mediados de los 90 por Kent Beck, poniendo las 12 ideas anteriormente citadas en el manifiesto como fundamentales en los principios de un desarrollo XP. (Amaro Calderón, 2007)



Ilustración 10 Modelo XP.
Fuente: (Amaro Calderón, 2007).
·         Ventajas:

·         Se construye el proyecto con base a la calidad.
·         Es simple.
·         Siempre se está programando.
·         El cliente siempre está al pendiente del desarrollo del proyecto.
·         Es una buena práctica de sinergia.


·         Desventajas:

·         Cuando el proyecto es muy largo, se vuelven más complejos los ambientes.

·         Se generan muchas situaciones críticas si no se lidera bien.

·         Demanda tener muy bien entendido los requerimientos del proyecto.

·         El cliente puede estar distante o no saber exactamente lo que desea.
3.2.3.2 Scrum:
Scrum es un marco de trabajo para desarrollar productos y sistemas complejos, que son desarrollados bajo una teoría empírica, el cual emplea un desarrollo de optimización iterativo incremental para optimizar la predicción y el control de riesgos.
Scrum es un método iterativo e incremental que enfatiza prácticas y valores de project management por sobre las demás disciplinas del desarrollo. Al principio del proyecto se define el Product Backlog, que contiene todos los requerimientos funcionales y no funcionales que deberá satisfacer el sistema a construir. Los mismos estarán especificados de acuerdo a las convenciones de la organización ya sea mediante: features, casos de uso, diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog será definido durante  reuniones de planeamiento con los stakeholders (son los individuos que se relacionan directamente con el proyecto). A partir de ahí se definirán las iteraciones, conocidas como Sprint en la jerga de Scrum, en las que se irá evolucionando la aplicación evolutivamente. Cada Sprint tendrá su propio Sprint Backlog que será un subconjunto del Product Backlog con los requerimientos a ser construidos en el Sprint correspondiente. La duración recomendada del Sprint es de un mes.  (Amaro Calderón, 2007)


Esta metodología es susceptible a incertidumbres y riesgos sin embargo provee técnicas específicas y prácticas para resolver estos riesgos, es muy similar al modelo iterativo e incremental. En esta metodología se maneja el Sprint, el cual es un periodo aproximado de 30 días donde se trabaja para sacar el producto entregable al cliente. En cada fase de desarrollo se requiere una serie de Sprints para determinarlos, donde primero se planean las prioridades y el tiempo de revisión de las actividades que se llevarán a cabo, tratando de localizar el tiempo que se tomará para cada una de las actividades, este tiempo es determinado en una junta con los administradores del proyecto. Se trata de no gastar tiempo en detalles ya que se tiene un conocimiento previo de lo deseado. El seguimiento se trata de monitorear a los involucrados en el desarrollo del producto, en el caso de QA se busca observar los problemas encontrados por el equipo de Testers manuales y la comunicación con Automatización.
Estas reuniones llevan el nombre de Scrum Meeting, y tienen la duración de 15 a 30 minutos con cada equipo, donde se habla de lo que se realizó en el anterior Scrum Meeting, cuáles fueron los problemas encontrados, si alguien no logró terminar el trabajo en el tiempo asignado, y lo que se trabajará para el siguiente Sprint.
Los roles involucrados en el Scrum Meeting son:
·         Cliente.
·         Scrum Master.
·         Equipo QA.


Como se puede observar en la Ilustración 11. La metodología resulta sencilla definiendo algunos roles y artefactos que contribuyen a tener un proceso que maximiza el feedback para mitigar cualquier riesgo que pueda presentarse.


Ilustración 11 Modelo Scrum.
Fuente: (Amaro Calderón, 2007).
La intención de Scrum es la de maximizar la realimentación sobre el desarrollo, pudiendo corregir problemas y mitigar riesgos de forma temprana. Su uso se está extendiendo cada vez más dentro de la comunidad de Metodologías Ágiles, siendo combinado con otras – como XP – para completar sus carencias. Cabe mencionar que Scrum no propone el uso de ninguna práctica de desarrollo en particular; sin embargo, es habitual emplearlo como un framework ágil de administración de proyectos que puede ser combinado con cualquiera de las metodologías mencionadas. (Amaro Calderón, 2007)


3.2.3.3 Ciclo de Vida de Scrum:
El ciclo de vida de Scrum es el siguiente:

1. Pre-Juego: Planeamiento. El propósito es establecer la visión, definir expectativas y asegurarse la financiación. Las actividades son la escritura de la visión, el presupuesto, el registro de acumulación o retraso (backlog) del producto inicial y los ítems estimados, así como la arquitectura de alto nivel, el diseño exploratorio y los prototipos. El registro de acumulación es de alto nivel de abstracción.
2. Pre-Juego: Montaje (Staging). El propósito es identificar más requerimientos y priorizar las tareas para la primera iteración. Las actividades son planificación, diseño exploratorio y prototipos.
3. Juego o Desarrollo. El propósito es implementar un sistema listo para entrega en una serie de iteraciones de treinta días llamadas “corridas” (sprints). Las actividades son los planeamientos de corridas en cada iteración, la definición del registro de acumulación de corridas y los estimados, y encuentros diarios de Scrum.
4. Pos-Juego: Liberación. El propósito es el despliegue operacional. Las actividades, documentación, entrenamiento, mercadeo y venta.

Usualmente los registros de acumulación se llevan en planillas de cálculo comunes, antes que en una herramienta sofisticada de gestión de proyectos. Los elementos del registro pueden ser prestaciones del software, funciones, corrección de bugs, mejoras requeridas y actualizaciones de tecnología. Hay un registro total del producto y otro específico para cada corrida de 30 días. En la jerga de Scrum se llaman “paquetes” a los objetos o componentes que necesitan cambiarse en la siguiente iteración. (Ángel, 2013)



Ilustración 12 Ciclo de vida de Modelo Scrum.
Fuente: (Amaro Calderón, 2007).


La lista de Acumulación del Producto contiene todos los rasgos, tecnología,  mejoras y lista de bugs que, a medida que se desenvuelven, constituyen las futuras entregas del producto. Los rasgos más urgentes merecerán mayor detalle, los que pueden esperar se tratarán de manera más sumaria. La lista se origina a partir de una variedad de fuentes. El grupo de mercadeo genera los rasgos y la función; la gente de ventas genera elementos que harán que el producto sea más competitivo; los de ingeniería aportarán paquetes que lo harán más robusto; el cliente ingresará debilidades o problemas que deberán resolverse. El propietario de la administración y el control del backlog en productos comerciales bien puede ser el product manager; para desarrollos in-house podría ser el project manager, o alguien designado por él. Se recomienda que una sola persona defina la prioridad de una tarea; si alguien tiene otra opinión, deberá convencer al responsable. Se estima que priorizar adecuadamente una lista de producto puede resultar dificultosa al principio del desarrollo, pero deviene más fácil con el correr del tiempo.  (Amaro Calderón, 2007)


Te invito a dejar tus comentarios para mejorar la información.
Gracias.

Autor: Luis Eduardo Fernandez Rocha (Contacto Linkedin)

No hay comentarios.:

Publicar un comentario