SCRUM

Introducción

Existen varias metodologías ágiles creadas para reducir y optimizar el tiempo de desarrollo de un proyecto, siendo SCRUM una de las más conocidas y utilizadas.

¿Qué es SCRUM?

Scrum es un proceso en el que se aplican de manera regular un conjunto de mejores prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto.

En Scrum se realizan entregas parciales y regulares del producto final, priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum está especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovación, la competitividad, la flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está entregando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capacidad de reacción ante la competencia, cuando la moral de los equipos es baja y la rotación alta, cuando es necesario identificar y solucionar ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un proceso especializado en el desarrollo de producto.

SCRUM vs XP

	SCRUM	XP
Características	Solo abarca prácticas de gestión, sin tomar en cuenta las prácticas de desarrollo. El equipo tiene la responsabilidad de decidir la mejor manera de trabajar con el fin de ser lo más productivo posible y se le da gran protagonismo a las reuniones que realicen a lo largo del proyecto. Sus raíces teóricas están en las teorías de la auto-organización.	Se basa en las pruebas realizadas a los principales procesos, de tal manera que sea posible hacer pruebas de las fallas que pudieran ocurrir. Tiene como pilar la reutilización de código, para lo cual se crean patrones o modelos estándares, siendo más flexible al cambio. Propone la programación en pares, la cual consiste en que dos desarrolladores participen en un proyecto en una misma estación de trabajo. Cada miembro lleva a cabo la acción que el otro no está haciendo en ese momento.
Roles	Product Owner Representa a todos los interesados en el producto final. Marca las prioridades del producto. Lleva el control de las estimaciones. Retorno de Inversión (ROI.) Scrum master Responsables del proceso de Scrum. Incorporación de Scrum en la cultura de la organización. Asegura el cumplimiento de los roles y responsabilidades. Formación y entrenamiento en el proceso. Scrum team Debe trasformar las tareas del Sprint Backlog en un incremento de funcionalidad en el software. Desarrollar el producto con calidad. Auto-gestionado. Auto-organizado. Multi-funcional. No mayor a ocho elementos.	Programador (Programmer) Responsable de decisiones técnicas. Responsable de construir el sistema. Sin distinción entre analistas, diseñadores o codificadores. En Xp, los programadores diseñan, programan y realizan las pruebas. Cliente (Customer) Es parte del equipo. Determina qué construir y cuándo hacerlo. Escribe tests funcionales para determinar cuándo está completo un determinado aspecto. Entrenador (Coach) El líder del equipo – toma las decisiones importantes. Principal responsable del proceso. Tiende a estar en un segundo plano a medida que el equipo madura. Rastreador (Tracker) Observa sin molestar. Conserva datos históricos. Probador (Tester) Ayuda al cliente con las pruebas funcionales. Se asegura de que los tests funcionales se ejecutan.

Conclusión

A pesar de que tanto SCRUM como XP forman parte de las metodologías ágiles, no es prudente realizar una comparación entre ambas pues tienen un campo de acción distinto.

Bibliografia

• Tataje, M. (22 de 11 de 2010). Recuperado el 24 de 05 de 2015, de https://www.ibm.com/developerworks/community/wikis/home/wiki/Rational+Team+Concert+for+Scrum+Projects/page/SCRUM+como+metodolog%C3%ADa
• Desconocido. (Desconocido). Recuperado el 24 de 05 de 2015, de https://aps2programacionxtrema.wordpress.com/xp-vs-scrum/

Practica 4 - Programación extrema

Mapa conceptual

El cuestionario fue entregado en clase

Practica 3 - Ventajas y desventajas Metodologías ágiles

Mapa conceptual

Presentación: Ver en Drive

Modelos del proceso del software

Mapa conceptual

Cuestionario

Presentación

Metodos ágiles de programación

Introducción

Cuando se ésta por desarrollar un software conviene conocer adecuadamente las características del proyecto y los distintos tipos de metodologías existentes para el desarrollo. Es importante elegir la metodología más apropiada en base a las características, para garantizar un mejor resultado final.

Métodos Ágiles de Programación

El método tradicional de desarrollo es el más adecuado para proyectos grandes, en los cuales se hace un análisis profundo de requerimientos antes de comenzar a desarrollar el software. Pero cuando se trata de proyectos más pequeños, se pierde tiempo en un análisis exhaustivo, por lo cual se desarrollaron los métodos ágiles, los cuales, entre otras cosas, siguen los siguientes puntos:

• Se permite el cambio en los requerimientos en cualquier momento del desarrollo.
• El equipo de desarrollo y el cliente deben trabajar en conjunto.
• Entrega continua de resultados.

Programación extrema

Propuesta por Kent Beck en 1999,  es el más destacado de los procesos ágiles de desarrollo de software. Se rige por los siguientes valores:

Simplicidad

Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece.

También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado.

Comunicación

El código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. 

Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de como utilizar su funcionalidad.

Realimentación

Al estar el cliente integrado en el proyecto, su opinión sobre el estado del proyecto se conoce en tiempo real.

Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante.

Coraje o valentía

Muchas de las prácticas implican valentía. Una de ellas es siempre diseñar y programar para hoy y no para mañana. La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. 

Respeto

El respeto se manifiesta de varias formas. Entre compañeros de trabajo, hacia el cliente y hacia el trabajo a realizar.

SCRUM

• Está especialmente indicada para proyectos con un rápido cambio de requisitos
• El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días
• Reuniones a lo largo proyecto

Crystal Clear

Mas que una metodología, son una familia de estas, fueron descritas por Alistair Cockburn, e ideal para equipos de 6 a 8 personas, se centra en las personas, no en los procesos, y la seguridad es una de sus mayores preocupaciones

Cuestionario

Mapa conceptual

Conclusión

Si bien los métodos ágiles nos permiten desarrollar de una manera más rápida y son ajustables al cambio, es importante recordar que solo son adecuados en proyectos pequeños. Si en algún momento deseamos comenzar un proyecto grande, es importante el análisis a profundidad de los requerimientos.

Pruebas de integración y de sistema

Pruebas de Sistema

Objetivo de la Prueba:  

Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento y recuperación.

Descripción de la Prueba:            

Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en técnicas de caja negra, ésto es, verificar el sistema (y sus procesos internos), la interacción con las aplicaciones que lo usan vía GUI y analizar las salidas o resultados.En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:

• Prueba funcionalidad
• Prueba de Usabilidad
• Prueba de Performance
• Prueba de Documentación y Procedimientos
• Prueba de Seguridad y Controles
• Prueba de Volumen
• Prueba de Esfuerzo
• Prueba de recuperación
• Prueba de múltiples sitios

La prueba de sistema es compleja porque intenta validar un número de características al mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema al mismo tiempo.

Técnica:   

Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para verificar que:

• Los resultados esperados ocurren cuando se utiliza un dato válido.
• Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando se utiliza un dato inválido.
• Cada regla de negocios es aplicada adecuadamente.

Criterio de Completitud:     

• Todas las pruebas planeadas han sido ejecutadas.
• Todos los defectos que se identificaron han sido tenidos en cuenta.

Prueba de Integración

Objetivo de la Prueba:

• Identificar errores introducidos por la combinación de programas probados unitariamente.
• Determina cómo la base de datos de prueba será cargada.
• Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente.
• Verificar que las especificaciones de diseño sean alcanzadas.
• Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.

Descripción de la Prueba:            

• Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente.
• Determina cómo la base de datos de prueba será cargada.
• Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.
• Decide qué acciones tomar cuando se descubren problemas.

Por cada Caso de Prueba ejecutado:

• Comparar el resultado esperado con el resultado obtenido.

Técnica:

• Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos.
• Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se verifica que los módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.

Criterio de Completitud:  

• Todas las pruebas planeadas han sido ejecutadas.
•  Todos los defectos que se identificaron han sido tenidos en cuenta.

Tarea - Tipos de prueba

Introducción 

Conocer los tipos de prueba es algo de suma importancia para cualquier programador, ya que de esta manera podemos optimizar nuestro programa, prever malos funcionamientos y prevenir errores. Realizar las pruebas de manera adecuada representa una tarea fundamental en el momento del desarrollo de cualquier software.

Pruebas de Caja Blanca

La prueba de la caja blanca es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar los casos de prueba.

Las pruebas de caja blanca intentan garantizar que:

• Se ejecutan al menos una vez todos los caminos independientes de cada módulo
• Se utilizan las decisiones en su parte verdadera y en su parte falsa
• Se ejecuten todos los bucles en sus límites
• Se utilizan todas las estructuras de datos internas

Pruebas de Caja Negra

Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el comportamiento interno y la estructura del programa.

Los casos de prueba de la caja negra pretenden demostrar que:

• Las funciones del software son operativas
• La entrada se acepta de forma correcta
• Se produce una salida correcta
• La integridad de la información externa se mantiene

Las pruebas de caja negra pretenden encontrar estos tipos de errores:

• Funciones incorrectas o ausentes
• Errores en la interfaz
• Errores en estructuras de datos o en accesos a bases de datos externas
• Errores de rendimiento
• Errores de inicialización y de terminación
• Los tipos de prueba de cana negra que vamos a estudiar son:
• Prueba de partición equivalente
• Prueba de análisis de valores límites

Prueba del camino básico

El método del camino básico (propuesto por McCabe) permite obtener una medida de la complejidad de un diseño procedimental, y utilizar esta medida como guía para la definición de una serie de caminos básicos de ejecución, diseñando casos de prueba que garanticen que cada camino se ejecuta al menos una vez.

Prueba de bucles

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en software, por lo que tenemos que prestarles una atención especial a la hora de realizar la prueba del software.

La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles.

      Se pueden definir cuatro tipos de bucles diferentes:

• Bucles simples
• Bucles concatenados
• Bucles anidados
• Bucles no estructurados

Conclusión

A pesar de no ser todos los tipos de prueba, los presentados en este trabajo nos ayudarán a realizar pruebas eficientes a nuestro software, para así garantizar su optimo rendimiento.