SCRUM y XP

SCRUM

Scrum se basa en la teoría de control de procesos empírica o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.

El Equipo Scrum consiste en un Dueño de Producto (Product Owner), el Equipo de Desarrollo (Development Team) y un Scrum Master.

El Equipo Scrum (Scrum Team) 

El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, la creatividad y la productividad. Los Equipos Scrum entregan productos de forma iterativa e incremental, maximizando las oportunidades de obtener retroalimentación. Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto

El Dueño de Producto (Product Owner)

El rol del Product Owner, puede venir de parte del cliente o dentro de la empresa misma, depende. Generalmente no se aconseja que el Product Owner sea parte también del equipo de desarrollo, o el Scrum Master mismo, sus intereses se pueden ver enfrentados, pero esto puede variar según el caso. Por defecto, probablemente venga de parte del cliente. Como Product Owner representa al cliente, y es el encargado de negociar con el equipo, con el Scrum Master por medio como facilitador, la prioridad del trabajo a realizar. Esto desde una perspectiva del retorno de inversión para el negocio.

El Equipo de Desarrollo (Development Team)

El Equipo de Desarrollo consiste en los profesionales que desempeñan el trabajo de entregar un Incremento de producto “Terminado”, que potencialmente se pueda poner en producción, al final de cada Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento. Los Equipos de Desarrollo son estructurados y empoderados por la organización para organizar y gestionar su propio trabajo. La sinergia resultante optimiza la eficiencia y efectividad del Equipo de Desarrollo.

El Scrum Master

El Scrum Master es el responsable de asegurar que Scrum es entendido y adoptado. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.

XP

XP es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. XP se define como especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y donde existe un alto riesgo técnico.

Los roles de acuerdo con la propuesta original de Beck son: 

- Programador. El programador escribe las pruebas unitarias y produce el código del sistema.

- Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su implementación. Además, asigna la prioridad a las historias de usuario y decide cuáles se implementan en cada iteración centrándose en aportar mayor valor al negocio.

- Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales. Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es responsable de las herramientas de soporte para pruebas.

- Encargado de seguimiento (Tracker). Proporciona realimentación al equipo. Verifica el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para mejorar futuras estimaciones. Realiza elseguimiento del progreso de cada iteración.

- Entrenador (Coach). Es responsable del proceso global. Debe proveer guías al equipo de forma que se apliquen las prácticas XP y se siga el proceso correctamente.

- Consultor. Es un miembro externo del equipo con un conocimiento específico en algún tema necesario para el proyecto, en el que puedan surgir problemas.

- Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje efectivamente creando las condiciones adecuadas. Su labor esencial es de coordinación.

Sesión 3

¿Qué son las metodologías ágiles de desarrollo de software?

Metodologías que permiten desarrollar software rápidamente, respondiendo a los cambios que puedan surgir a lo largo del proyecto y siendo las alternativas a los procesos de desarrollo de software tradicionales

¿Cuáles son las características en las que se basan las metodologías ágiles?

1. Valorar 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.)
2. Desarrollar software que funciona más que conseguir una buena documentación.
3. La colaboración con el cliente más que la negociación de un contrato.
4. Responder a los cambios más que seguir estrictamente un plan. (La planificación no debe ser estricta sino flexible y abierta.)

¿Cuáles son las ventajas y desventajas del empleo de las metodologías ágiles respecto a las tradicionales?

Ventajas:

• Son especialmente preparadas para cambios durante el proyecto.
• Procesos menos rigurosos.
• Contrato bastante flexible.
• El cliente es parte del equipo de desarrollo.
• Grupos pequeños de menos de 10 integrantes y trabajan en el mismo sitio.

Desventajas:

• Proceso menos controlado.
• No hay un contrato prefijado.
• En algunos casos posible falta de personas en los grupos de desarrollo de software.

¿Cuándo es recomendable utilizar metodologías ágiles en el desarrollo de software?

Cuando existan proyectos donde el entorno del sistema es muy cambiante, y en donde se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad.

¿Cuáles son algunos tipos de metodologías ágiles?

• Programación Extrema (Extreme Programming, XP)
• SCRUM
• Crystal Methodologies
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Feature-Driven Development (FDD)
• Lean Development (LD)

https://docs.google.com/presentation/d/1zLovV1E4S09r_knExB8xGMHwk5KJsxwrUQl4Kya_0mE/edit?usp=sharing

Métodos Ágiles de Programación

Introducción

Ya hemos visto anteriormente algunos metodos de  desarrrollo tradicionales, tal como el modelo de cascada, en espiral, el modelo evolutivo, entre otros, éstos mencionado son tradicionales y tienen todo gestionado con calidad, pero habrá veces en que no requeriremos de mucha documentación simplemente porque requerimos desarrollar un proyecto de software no tan robusto o complejo, es aquí donde entran en juego las metodologías ágiles de desarrollo de software, a continuación estudiaremos un poco sobre estos métodos que nos ofrece muchas ventajas sobre los métodos tradicionales de desarrollo de software. .

Desarrollo

Metodologías Ágiles de Desarollo de Software

Las metodologías ágiles de desarrollo de software son imprescindibles en un mundo en el que las cosas cambian a velocidad de vértigo. El mundo del desarrollo, para bien o para mal, ha evolucionado desde un modelo en el que se planificaban y estructuraban minuciosamente todas las fases a un modelo en el que el desarrollo debe ser lo más rápido y eficiente posible

Conclusión

Como pudimos ver, llegarán ocasiones en que requiramos de métodos para desarrollar un proyecto de software que se adapte a nuestras necesidades y, si esas necedades implican poco tiempo y un proyecto no tan complejo, y tengamos equipo limitado de personal, podremos requerir a algunas de las metodologías que agilicen la forma de desarrollar en proyecto de software, y aunque estos métodos no son los únicos podemos adaptarnos a una metodología que se adapte a nuestras necesidades, pero eso es decisión del equipo.

Bibliografía

• Valverde, D. (06 de septiembre de 2007). Introducción a la Programación Extrema. Recuperado el 2012 de marzo de 26, de davidvalverde.com: http://www.davidvalverde.com/blog/introduccion-a-la-programacion-extremaxp

Métodos del proceso de software

Introducción

Con el pasar del tiempo los proyectos que buscan desarrollar software implementan diferentes procesos que les permiten tener un orden lógico en el proceso a seguir para la elaboración del producto de software, por lo que con el pasar del tiempo se requieren diferentes procesos para cada proyecto que surja, ya sea para software complejos o sencillos requieren un diferente ritmo de trabajo y organización de las actividades para el equipo de trabajo.

Desarrollo

Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto de software que pueda reunir los requisitos del cliente. Algo que debemos tener claro es que los procesos de software son complejos además de que dependen totalmente de las decisiones y el juicio del equipo de trabajo que busca satisfacer las necesidades del cliente. 

A pesar de la variedad de propuestas de proceso de software, existe un conjunto de actividades fundamentales que se encuentran presentes en todos ellos:

1. Especificación de software. Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.
2. Diseño e implantación. Se diseña y construye el software de acuerdo a la especificación.
3. Validación. El software debe validarse, para asegurar que cumpla con lo que quiere el cliente.
4. Evolución. El software debe evolucionar, para adaptarse a las necesidades del cliente.

Modelo de proceso de software

Un modelo de proceso de software se define como una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto un modelo de procesos del software es una abstracción de un proceso real.

Algunos de los modelos de proceso de software existentes son:

• Modelo en cascada
• Desarrollo evolutivo
• Basado en componentes

Modelo de cascada

Considera las actividades fundamentales del proceso de especificación, desarrollo, validación y evolución. Los representa como fases separadas del proceso, tales como especificación de requerimientos, el diseño de software, la implantación, las pruebas, etc.

Las principales etapas de este modelo se transforman en actividades de desarrollo:

1. Análisis y definición de requerimientos. Os servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se definen en detalle y sirven como una especificación del sistema.
2. Diseño del sistema de software. El proceso de diseño de sistema divide los requerimientos en sistemas en hardware y software. Establece la arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema de software y sus relaciones.
3. Implantación y prueba de unidades. En esta etapa el diseño del software se lleva a cabo como un conjunto o unidades de programa. La prueba de unidades implica verificar que cada una cumpla su especificación.
4. Integración y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como sistema completo para asegurar que se cumplan los requerimientos del software. Después de las pruebas, el sistema del software se entrega al cliente
5. Funcionamiento y mantenimiento. Por lo general, ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en funcionamiento. El mantenimiento implica corregir errores no cubiertos en las etapas anteriores del ciclo de vida, mejorar la implantación de las unidades del sistema y resaltar los servicios del sistema una vez que se descubren nuevos requerimientos.

Desarrollo evolutivo

La idea detrás de este modelo es el desarrollo de una implantación del sistema inicial, exponerla a los comentarios del usuario, refinarla en versiones hasta que se desarrolle el sistema final adecuado. Una ventaja de este modelo es que se obtiene una rápida realimentación del usuario, ya que las actividades de especificación, desarrollo y pruebas se ejecutan en cada iteración.

Existen dos tipos de desarrollo evolutivo:

• Desarrollo exploratorio, donde el objetivo del proceso es trabajar con el cliente para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando nuevos atributos propuestos por el cliente.
• Prototipos desechables., donde su objetivo del proceso de desarrollo evolutivo es comprender los requerimientos del cliente y entonces desarrollar una definición mejorada de los requerimientos del sistema. El prototipo se centra en experimentar con los requerimientos del cliente que no se comprenden del todo.

Basado en componentes

En la mayoría de proyectos de software se reutiliza software. Esto sucede cuando las personas que trabajan en el proyecto conocen diseños o códigos similares al requerido. En los últimos años ha surgido un enfoque de desarrollo de software denominado ingeniería de software basado en componentes que se basa en la reutilización. Algunas veces estos componentes son sistemas por si mismos que pueden proporcionar funcionalidad específica. Las etapas son las siguientes:

1. Especificación de requerimientos. Similar al modelo de cascada.
2. Análisis de componentes. A partir de la especificación de buscan los componentes para implementar esta especificación. Por lo general no existe una concordancia exacta y los componentes que se utilizan sólo proporcionan parte de la funcionalidad.
3. Modificación de requerimientos. Los requerimientos se analizan utilizando información acerca de los componentes que se han descubierto.. Entonces estos componentes se modifican para reflejar los componentes disponibles. Si las modificaciones no son posibles, la actividad de análisis de componentes se puede llevar a cabo nuevamente para buscar soluciones alternativas.
4. Diseño del sistema con reutilización. En esta fase se diseña o se reutiliza un marco de trabajo para el sistema. Los diseñadores tienen en cuenta los componentes que se reutilizan y organizan el marco de trabajo para que los satisfaga. Si los componentes reutilizables no están disponibles, se puede tener que diseñar nuevo software.
5. Desarrollo e integración. Para crear el sistema, el software que no se puede adquirir externamente se desarrolla, y los componentes y los sistemas adquiridos se integran.
6. Validación del sistema. Similar al modelo de cascada

Conclusion

Como hemos visto, los diferentes clientes que podemos encontrar tendrán diferentes necesidades que cubrir, por lo que el utilizar un único modelo de desarrollo de software para todos los proyectos resulta ser insuficiente para cubrir las necesidades del cliente, por lo que siempre debemos elegir el que se acople mejor a las necesidades tanto del cliente como del equipo de trabajo para la realización del software.

Bibliografía

• Pressman, R, Ingeniería del Software: Un enfoque práctico, McGraw Hill 1997.
• http://ele-mariamoliner.dyndns.org/~fperal/proy/ingenieriaSW.pdf
• http://yaqui.mxl.uabc.mx/~molguin/as/IngSoft%201-4.pdf

Pruebas de integración y de Sistema

Pruebas de Integración.

La prueba de integración es una técnica sistemática para construir la estructura del programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores asociados con la interacción. El objetivo es tomar los módulos probados en unidad y estructurar un programa que esté de acuerdo con el que dicta el diseño. La integración puede ser descendente si se integran los módulos desde el control o programa principal, o bien, ascendente, si la verificación del diseño empieza desde los módulos más bajos y de allí al principal. La selección de una estrategia de integración depende de las características depende de las características del software y, a veces, del plan del proyecto, en algunos de los casos se puede combinar ambas estrategias.

Diseñadas para probar la interacción entre los distintos componentes de un sistema.

Tipos de errores:

·         Errores de programación entre componentes.

·         Errores de interoperabilidad.

Estrategias de pruebas:

·         Pruebas no incrementales (“Big Band Approach”):

Se integran todos los componentes y entices se prueba el Sistema como un todo. No es una técnica recomendada pues dificulta el aislamiento de errores.

·         Pruebas incrementales:

El programa es construido y probado en pequeños incrementos. Facilita el aislamiento de errores y las pruebas sistemáticas.

o    Integración descendente (Top-down).

§  En profundidad (Depth-first).

§  En anchura (Breadth-first).

o    Integración ascendente (Bottom-up).

Integración descendente.

·         Permite verificar los puntos de control o decisión al principio del proceso de prueba.

·         La integración en profundidad permite probar funcionalidades completas lo cual aumenta la confianza.

·         Puede requerir el uso de muchos stubs.

La integración se realiza partiendo del programa principal y moviéndolos hacia abajo por la jerarquía de control.

Integración descendente en profundidad.

La integración se realiza por ramas. Cada rama suele implementar una funcionalidad específica.

Integración descendente en anchura.

La integración se realiza por niveles moviéndose en horizontal por la estructura de control.

Integración ascendente.

·         Se elimina la necesidad de usar stubs.

·         Es necesario el uso de controladores de prueba (“drivers”) a fin de coordinar la entrada y salida de casos de prueba.

La integración se realiza partiendo de módulos atómicos situados en los nodos finales de la jerarquía de control. No suele necesitar el uso de stubs.

Pruebas de Sistema.

Diseñadas para probar el sistema en su totalidad como si de una caja negra se tratase.

Un clásico problema de la prueba del sistema es la delegación de culpabilidad. Esto ocurre cuando se descubre un error t cada uno de los creadores de cada elemento del sistema echa la culpa del problema a otros, para evitar esto se debe prever y tomar medidas correctivas tomando en cuenta lo siguiente:

• Diseñar caminos de manejo de errores que prueben toda la información procedente de otros elementos del sistema.
• Lleva a cabo una serie de pruebas que simulan la presencia de datos en mal estado o de otros posibles errores en la interfaz del software.
• Registrar los resultados de las pruebas como “evidencias” en el caso de señalamientos informales.
• Participar en la planificación y diseño de las pruebas del sistema para asegurarse de que el software es probado en forma adecuada.

La prueba del sistema se basa en otras técnicas de pruebas, aunque la finalidad de cada prueba es distinta, sirven para verificar que se hayan integrado correctamente cada uno de los elementos del sistema:

1. Prueba de Recuperación: es una prueba que se hace al sistema forzando a que produzca fallas de software de muchas maneras y verificando que la recuperación se lleve a cabo, ya sea automáticamente o manual, tomando en cuenta los recursos que se requieran para efectuar la recuperación.
2. Prueba de Seguridad: intenta verificar la aplicación de los mecanismos de protección incorporados en el sistema. Durante la prueba el encargado desempeña el papel de intruso tratando de violar la seguridad del sistema, intentando obtener las claves de acceso por cualquier medio externo; debe bloquear el sistema negando así el servicio a otras personas además de producir errores a propósito en el sistema o debe curiosear los datos públicos intentando encontrar una clave de acceso al sistema.
3. Prueba de Resistencia: está diseñada para enfrentar a los problemas en situaciones anormales, es decir ejecutar el sistema en forma que demande recursos en cantidad, frecuencia o volúmenes anormales. El encargado de la prueba debe intentar tirar el sistema. Para lograr esto se puede tomar en consideración lo siguiente:

•  Diseñar pruebas especiales que generen 10 o más interrupciones por segundo.
• Incrementar la frecuencia de datos de entrada en un orden de magnitud con el fin de comprobar cómo responden las funciones de entrada.
• Ejecutar casos de prueba que requieran al máximo de memoria o de espacio en disco.
• Diseñar casos de prueba que produzcan excesivas búsquedas de datos almacenados en el disco.

https://www.lsi.us.es/docencia/get.php?id=6731

http://www.academica.mx/blogs/las-pruebas-integraci%C3%B3n-software

Diagrama de Nodos

Diagrama

Posibles Rutas

p1
p2-p7
p2-p7-p9
p3-p7
p3-p7-p9
p4-p5-p8-p9
p4-p5-p8...
p4-p6-p8-p9
p4-p6-p8...

Pruebas de Caja Negra & Blanca

Pruebas de Caja Negra: Realiza pruebas que comprueben que todas las funciones son operativas. (Externo). Demuestran que las funciones del software son operativas, que la entrada es aceptada y la salida es correcta, y la integridad de la información se mantiene. (Interfaz).

Intentan encontrar errores de Funciones incorrectas o ausentes, Errores en Interfaz, en Estructuras de Datos o Accesos a Bases de Datos, Rendimiento, Inicialización y Terminación.

Prueba de Partición Equivalente

Divide el dominio de entrada de un programa en clases de datos, y de estas se derivan los casos de prueba. Cada clase de equivalencia representa un conjunto de estados válidos o inválidos para las condiciones de entrada.

Prueba de Análisis de Valores Límites

Conduce a que para determinadas clases de equivalencia se genere más de un caso de prueba.

Pruebas de Caja Blanca: Realiza pruebas que comprueben que las operaciones internas son correctas y sean de acuerdo a las especificaciones. (Interno). En estas pruebas se comprueban que los detalles del programa sean correctos, es decir que los procedimientos sean los que corresponden.

·         Se ejecutan por lo menos una vez en cada camino de cada módulo.

·         Se utilizan todas las estructuras de datos internas.

Prueba del Camino Básico

Propuesto por McCabe, con este se obtiene una medida de la complejidad de un diseño procedimental, diseña casos de prueba que garanticen que todos los caminos se ejecuten por lo menos una vez.

Prueba de Bucles

Técnica de prueba de caja blanca que se enfoca en la validez de las construcciones de los bucles.

Hay cuatro tipos de bucles:

-Simples

-Concatenados

-Anidados

-No Estructurados

Referencias:

http://indalog.ual.es/mtorres/LP/Prueba.pdf

http://www.lsi.us.es/docencia/get.php?id=401