En el proceso inicial de desarrollo de software, el profesional se encuentra con situaciones no siempre previsibles, a pesar de tener experiencia, en muchas ocasiones se debe enfrentar a la alta incertidumbre, en especial cuando el resultado final no es fácil de estimar y los cambios ocurren con alta frecuencia, en resumen, se debe enfrentar a situaciones nuevas o conocidas presentadas de forma diferente.

Esta incertidumbre lo ocasionan circunstancias como la recolección de forma errada e incompleta de requisitos, selección errada de la arquitectura del software ocasionando ineficiencia por ser insuficiente, los procesos de pruebas no se ejecutan de manera adecuada al existir requisitos incompletos o no claros, falta de soporte, bugs en el código fuente.

Es en esta parte donde se debe tener en cuenta el concepto "Desarrollo de Software Ágil", donde esa incertidumbre es gestionada de forma tal que resulte disminuida por medio de la retroalimentación de los usuarios al usar el software, de forma tal que sirvan como insumo para los ajustes necesarios.

El concepto nació en el 2001 por medio de la reflexión de varios críticos en búsqueda de la optimización del desarrollo de software mediante metodologías livianas, de allí salieron nuevos términos, a partir del llamado "Manifiesto Ágil", allí se describe el ciclo de desarrollo del software ágil, se difundieron rápidamente conceptos como "Programación Extrema - XP", "Cruz" y Kanban.

El ciclo de vida del Desarrollo de Software Ágil se da de forma cíclica, se denominan ciclos ágiles y cuentan con unos patrones secuenciales.

La Programación Extrema - XP es la metodología parte del ciclo de vida del Software Ágil, está enfocada a la ingeniería de software para el desarrollo en proyectos de tamaños medianos y pequeños, busca incluir la interacción usual con el cliente, con prácticas para el desarrollo descritas de forma detallada, esto es describir el lenguaje de la programación, hacer pruebas unitarias y usar poca documentación para iniciar el desarrollo.

XP adapta las mejores prácticas en el desarrollo y las mejores metodologías acorde con los objetivos del proyecto y se aplica en toda la vida del desarrollo del sistema.

Ventajas de la Programación Extrema - XP
1	Los resultados se obtienen en corto tiempo
2	Reciclaje de código de programación
3	El usuario final participa en el ciclo de vida de desarrollo del sistema
4	Alta comprensión del código de programación

Cruz es la parte de la gestión del proyecto con la interacción usual del cliente, hace énfasis en las buenas prácticas para trabajo en equipo y enfocado a los resultados.

Cruz pretende instar a las entregas parciales y constantes del producto final, se orienta a proyectos con contextos complejos y con la necesidad de resultados inmediatos, implica creatividad, competitividad, productividad, entre otros.

Ventajas de Scrum
1	Entregas periódicas que permiten al usuario final, hacer uso del sistema en desarrollo
2	Al hacer entregas periódicas, también permite saber si se debe corregir el camino que lleva el desarrollo o no
3	Adaptación del sistema en desarrollo a las necesidades del cliente en el ciclo de vida del desarrollo
4	Cuando el problema no se encuentra bien definido o incompleto, con Cruz es posible ir visualizando el problema
5	Se agila el proceso, porque se divide el problema en pequeñas tareas y las tareas tienen un tiempo que se ha determinado con anterioridad
6	El cliente puede comenzar a utilizar el producto rápidamente

KANBAN Palabra japonesa que significa tablero, cartel o panel en donde se muestra como un sistema de información trabajando de modo muy armónico delimitando fases en un proceso para que cada pieza del programa a crear funcione correctamente y sea de la mejor calidad posible, dando así un óptimo flujo de trabajo, asignando a su vez bien los recursos con una constante revisión al sistema.

Sus objetivos son simples: lograr un producto de excelente calidad y terminar con los cuellos de botella. Se debe tener en cuenta que juegan el liderazgo, la aceptación al cambio, el respeto por los roles, responsabilidades y el proceso en sí de cada integrante del sistema.

Ventajas de Kanban
1	Dispone de un mínimo de espacio en infraestructura
2	Adaptación del sistema en desarrollo a las necesidades del cliente en el ciclo de vida del desarrollo
3	Permite a los desarrolladores, pruebas y performance, observar y hacer seguimiento a las señales visuales del tablero, sin necesidad de desplazamiento
4	Promueve el trabajo en equipo (los desarrolladores se comunican entre sí y se ayudan cuando alguna actividad da problemas).
5	Reducción del tiempo perdido (todo el desarrollo se hace bajo demanda, por lo que no hay partes que sobren, además si alguien acaba su trabajo ayuda al resto del equipo).
6	Facilidad para añadir mejoras (el tablero permite que todo el equipo de desarrollo pueda ver cómo se está haciendo el producto desde una visión global, lo que permite que puedan reflejar a sus compañeros diversas mejoras sobre el mismo).

Problema en un Entorno Real

Empresa: Salud Total

Lugar: Área de desarrollo, performance y pruebas de software.

En cada área existen sub-áreas, según el tipo de aplicaciones que tiene la entidad, esta cuanta con aplicaciones jurídicas, de facturación, de atención en citas médicas y urgencias, de recobros y de talento humano.

Síntomas:

Los problemas que se identifican en estas áreas son los siguientes:

La entidad necesita aplicar constantemente campos en los registros de las aplicaciones, las cuales en su mayoría son aplicaciones de escritorio, cuando se necesitan aplicaciones en alguna sub área, esta se solicita de manera urgente, lo que hace que al hacer el desarrollo para estos cambios surja lo siguiente: al tener menor tiempo en el desarrollo, se pasan por alto la presentación de la interfaz que se presenta al usuario.

Causas:

En performance se pasa por alto la capacidad de los servidores en cuanto a espacio en disco, procesamiento, cantidad de usuarios conectados al tiempo.
En pruebas no siempre se tiene un usuario disponible de los que usualmente utilizan la aplicación, lo que hace que las pruebas la hagan personas que no saben manejar la aplicación para exigirla al extremo, por lo cual las pruebas no son confiables.
La articulación de las tres áreas no es la adecuada, ya que cada área al cumplir con su parte se desentiende, si llegara a quedar un vacío, el área que tiene en ese momento la aplicación, asume los cambios necesarios para su puesta en producción.

Pronóstico:

Las consecuencias son, una aplicación en producción con riesgo a ser rechazada de golpe por el usuario al no encontrar su contenido usual en la interfaz, lentitud y bloqueo de la aplicación, además de llamados erróneos en datos o entradas inequívocas que no llaman las bases de datos que deberían llamar.

Diagrama 1. Mapa de procesos Desarrollo - Pruebas y Performance

Diagrama 2. Diagrama de procesos Desarrollo - Pruebas y Performance

Control al pronóstico:

Solución propuesta al Problema en Entorno Real

Proceso general de desarrollo.

El proceso de desarrollo en la organización se presenta como un modelo estándar con las etapas mínimas para la generación de un producto de software.

Proceso general de desarrollo

Subproceso de pruebas

El proceso Pruebas y Control de Calidad de Software, se inicia una vez el área de desarrollo libera una nueva versión, ajuste o modificación del software para ser verificado en cuanto a su funcionalidad y calidad. Es necesario para tal fin, disponer de información y documentación de los requerimientos funcionales, no funcionales o las actas de las reuniones de levantamiento de información con los usuarios del sistema.

A continuación, se describen las actividades del proceso de pruebas y control de calidad del software:

SUBPROCESO: PRUEBAS Y CONTROL DE CALIDAD DE SW
ID	ACTIVIDAD		DESCRIPCIÓN
AC01	Recibir y asignar requerimiento		El líder de pruebas recibe la documentación del requerimiento a probar, la revisa y según su complejidad y disponibilidad de recursos lo asigna a un probador para su validación y ejecución de pruebas.
AC02		Verificar requerimiento	El probador revisa la documentación del requerimiento para conocer de qué se trata y proceder con las pruebas.
AC03		Solicitar información complementaria	Si hay dudas en cuanto a la claridad del requerimiento en la documentación, el probador solicita al responsable del requerimiento en el área de desarrollo la información necesaria, la cual será validada nuevamente hasta tener 100% clara la solicitud.
AC04		Definir criterios de aceptación	Si el requerimiento no tiene sus criterios de aceptación previamente definidos en la solicitud, el probador en conjunto con el desarrollador del requerimiento y/o un representante del área que lo solicitó define los criterios de aceptación.
AC05		Diseñar y documentar plan de pruebas	El probador diseña el plan de pruebas funcionales o no funcionales para certificar el requerimiento. Lo documenta en el formato de pruebas o en una herramienta documentación y ejecución de pruebas según sea el caso.
AC06		Agendar fecha pruebas	Se validan fechas de entrega para pruebas y se estima fecha de cierre de pruebas según prioridades.
AC07		Ejecutar plan de pruebas	Se ejecutan las pruebas del requerimiento y se documentan los resultados.
AC08		Registrar y reportar incidencias	Si en el proceso de pruebas se detectan incidencias se documentan en el formato de pruebas o en la herramienta de pruebas, según sea el caso. Si es en la herramienta de pruebas, se crea un issue en TFS, se asigna al responsable del requerimiento en el área de desarrollo y se notifica mediante email al desarrollador el resultado de las pruebas. Si es en el formato de pruebas, se envía un email al desarrollador indicando el incidente encontrado.
AC09		Actualizar manuales usuario	Se envía a la mesa de ayuda la documentación técnica y/o funcional del requerimiento para que se genere y actualice la documentación en el manual de usuario del sistema.
AC10		Enviar autorización para instalación en producción	Una vez se termina el ciclo de pruebas exitosamente, se informa al desarrollador con copia al Líder de Tecnología autorizando la instalación en producción de la nueva versión.

Subproceso de pruebas

Objetivo del plan de pruebas.

Establecer las actividades para la planeación, diseño, ejecución y evaluación de pruebas que permitan identificar y corregir los defectos encontrados en las diferentes modificaciones hechas al software y verificar que estas cumplan con los requerimientos definidos y con los lineamientos tecnológicos de la empresa.

Estructura del área de tecnología

Diagrama 3. Organigrama Área Tecnología

Alcance

Los casos de prueba se elaboran con base en las definiciones en los documentos de requerimientos (RFP / Casos de Uso) o en su defecto en las actas de las reuniones con usuarios del sistema, donde se especifican las modificaciones a realizar, las cuales son entregadas por el grupo de desarrollo.

Con el fin de identificar flujos de procesos críticos a ser probados, se hace necesario conocer acerca de los procesos de negocio y sus interrelaciones para el diseño de pruebas de integración y del sistema.

En cada una de estas entregas de software por parte del grupo de desarrollo se realizarán diferentes pruebas y verificaciones con el fin de validar:

• La visualización de los datos.

• La respuesta y realización de las transacciones.

• Que los estados de las actividades y documentos generados en el sistema se reflejen

de acuerdo a la secuencia lógica requerida por el usuario.

• La secuencia lógica de las funcionalidades y transacciones.

• Cumplimiento de estándares de desarrollo y presentación.

• Pruebas funcionales.

• Pruebas no funcionales.

• Verificación de documentación entregada.

• Validación de ejecución de pruebas por parte del grupo de desarrollo.

• Solución / corrección de incidentes reportados en el proceso de pruebas.

• Otros que sean pertinentes.

La aplicabilidad se hará como especie prototipo, se evalúa el requerimiento si es posible y se procede a crearlo, después de terminado estos archivos códigos se llevan de un ambiente local a un ambiente de pruebas en donde es la misma aplicación pero no afecta un usuario productivo (lo que llamamos despliegue) y lo evaluará la misma área que en la realidad está involucrada en este proceso , si aprueban estos cambios y ven que son correctos se procede a generar el despliegue del desarrollo al ambiente productivo para ya ponerlo en marcha.

Referencias

UNID. 2009. DESARROLLO ÁGIL DE SOFTWARE – CASO PROGRAMACIÓN EXTREMA – XP. México: Ingeniería de Software II, UNID. Recuperado el 25 de septiembre de: http://brd.unid.edu.mx/desarrollo-agil-de-software/

Ángel Arias. Curso de Programación de Apps. Android y iPhone: 2ª Edición. IT Campus Academia.

José R. Laínez F. 2015. Desarrollo de Software Ágil: Extreme Programming y Cruz. IT Campus Academy.

José López. Noviembre de 2013. Mejora tu trabajo en equipo con el método Kanban. Recuperado el 27 de septiembre de 2016 de: https://hipertextual.com/archivo/2013/11/que-es-kanban/

Rafael C. Cabrera. Lean Six Sigma TOC. Simplificado. PYME. Recuperado el 28 de septiembre de 2016 de: https://www.google.com.co/search?sourceid=chrome-psyapi2&ion=1&espv=2&ie=UTF-8&q=Lean%20Six%20Sigma%20TOC.%20Simplificado.PYMES&oq=Lean%20Six%20Sigma%20TOC.%20Simplificado.PYMES&aqs=chrome..69i57j0j69i61l3.675j0j7

Antonio Martel. 2016. Gestión Práctica de Proyectos con SCRUM, Desarrollo de software ágil para Cruz Master. Safe Creative. Recuperado el 28 de septiembre 2016 de: https://books.google.com.co/books?id=g3yKCwAAQBAJ&printsec=frontcover&hl=es&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false

Rafael L. Granados. 2015. Desarrollo de aplicaciones web en el entorno servidor. IFCD0210. Málaga, España: IC Editorial.

Desarrollo de Software Agil 201014_7

martes, 27 de septiembre de 2016

Desarrollo de Software Ágil – “XP (Programación Extrema), SCRUMB y Kanban”

Descripción de la Tecnología "Desarrollo de Software Ágil"

Problema en un Entorno Real

Síntomas:

Causas:

Pronóstico:

Control al pronóstico:

Proceso general de desarrollo

Subproceso de pruebas

Subproceso de pruebas

Objetivo del plan de pruebas.

Alcance

Referencias

Archivo del blog