La programación extrema “Engloba un conjunto de reglas y prácticas que ocurren en el contexto de cuatro actividades estructurales: planeación, diseño, codificación y pruebas.
La Figura 13 ilustra el proceso XP y resalta algunas de las ideas y tareas clave que se asocian con cada actividad estructural. En los párrafos que siguen se resumen las actividades de XP” (Pressman, 2010).
29 Figura 13 Modelo Aplicativo
Fuente: (Pressman, 2010) Ingeniería del software 7ma edición McGRAW-HILL Elaboración: Propia
Planeación: “La actividad de planeación (también llamada juego de planeación) comienza escuchando, actividad para recabar requerimientos que permite que los miembros del equipo XP comprendan el entorno del negocio del software y logren la sensibilidad de salida principales características y funcionabilidad requerida. En esta etapa los usuarios o clientes se reúnen con el equipo de desarrollo para crear "historias de usuario" o requisitos. El equipo de desarrollo convierte las historias de usuario en iteraciones que cubren una pequeña parte de la funcionalidad o características requeridas. Una combinación de iteraciones proporciona al cliente el producto final completamente funcional. En este contexto, el equipo de programación formula el plan, tiempo y los costos para llevar a cabo las iteraciones, en tanto que los desarrolladores individuales se registran para las iteraciones. Una orientación de planificación es el denominado método de la ruta crítica, que agrupa las iteraciones principales para el progreso del proyecto de manera lineal y organiza la culminación de las demás iteraciones paralelas a la ruta crítica. En este proceso, es importante tener en cuenta que en cualquier instante se pueden escribir historias nuevas” (Pressman, 2010).
“Cabe mencionar que también tanto desarrolladores como usuarios coordinan y deciden la agrupación de las “historias” para el próximo aumento en el software que va desarrollar el equipo. Convenido el acuerdo para la entrega de las “historias” la cual debe incluir fecha y otros aspectos relevantes del proyecto, el equipo se encarga del ordenamiento
30 de las “historias” que se desarrollarán de una de las siguientes maneras: 1) las historias en su totalidad se pueden implementar inmediatamente, 2) implementar primero todas las historias que tengan mayor valor o 3) las historias consideradas como de “mayor riesgo”
se implementan primero y se programan las actividades” (Pressman, 2010).
“Una vez realizado el primer aumento del software o después de realizada la primera entrega el equipo XP determina la velocidad del proyecto. Esto se refiere al número de historias implementadas de los clientes para la entrega primera. La velocidad del proyecto es necesaria para: 1) permite calcular fechas de entrega para programar actividades de futuras entregas, 2) Evaluar los compromisos contraídos para todas las historias durante la programación de todo el proyecto. Si se tiene un gran compromiso se puede modificar las fecha de entrega o el contenido de entregas.A medida que avanza el trabajo, el cliente puede agregar historias, cambiar el valor de una ya existente, descomponerlas o eliminarlas. Entonces, el equipo XP reconsidera todas las entregas faltantes y modifica sus planes en consecuencia” (Pressman, 2010).
Diseño: “Una iteración de la programación de XP comienza con el diseño y se basa estrictamente en el principio “mantenlo sencillo”. Sobre la representación compleja es más conveniente un diseño sencillo. Un diseño conduce al establecimiento de una historia tal como se escribe; el diseño se desalienta de una funcionalidad complementaria debido a que su desarrollador cree que se necesitará después. La programación de XP incentiva el use de Tarjetas de Responsabilidades y Colaboración de clase de software (CRC) que permiten un alejamiento de la mentalidad procesal tradicional y hacen posible la tecnología orientada a objetos. La tarjeta CRC constituyen el producto de la implementación del diseño del proceso XP” (Pressman, 2010).
“Cuando se encuentra algún problema de diseño difícil de una “Historia”, XP aconseja que inmediatamente se cree un prototipo operativo para el diseño, denominado solución en punta; que tiene como objetivo reducir el riesgo cuando se inicie la verdadera al implementación y de esta forma validar las estimaciones iniciales para la “historia” que comprende el problema de diseño. Cuando virtualmente el diseño XP no emplea notación y produce pocos, cuando alguno, resultados del trabajo no tarjetas CRC o solución en punta, se observa el diseño como un artefacto en cambio lo cual se debe de modificar conforme avanza su construcción. El propósito de rediseñar es el control de las modificaciones realizadas, proponiéndose cambios pequeños en el diseño, capaces de mejorarlo radicalmente. No obstante, hay que tener en cuenta que el esfuerzo para rediseñar aumenta considerablemente el tamaño de la aplicación” (Pressman, 2010).
31 Una idea en XP se refiere “a que el diseño puede ocurrir antes o después de iniciado la codificación. Rediseñar quiere decir que el diseño se realiza continuamente de acuerdo a la construcción del sistema. En verdad, la acción de construcción proporciona al equipo XP las pautas para la mejora del diseño” (Pressman, 2010).
Código: “Luego del desarrollo de las historias y de realizado el diseño preliminar el equipo XP aun antes de realizar la codificación desarrolla varias pruebas individuales a las historias que serán entregadas en curso. Después de realizada la prueba individual, el desarrollador tendrá mayor información para concentrarse en la implementación y pasar la prueba. Después de culminado con la codificación, debe aplicarse inmediatamente la prueba unitaria que dará lugar a una retroalimentación rápida a los desarrolladores”
(Pressman, 2010).
Durante el proceso de codificación “un aspecto importante es la denominada programación por pares, en donde en una estación de trabajo laboran dos personas juntas con el propósito de generar el código de la historia. Este mecanismo permite dar solución a problemas en tiempo real al igual que asegurar la calidad. Los desarrolladores se mantienen concentrados en la solución del problema. En realidad, cada una de las personas cumple con un papel diferente; así, uno puede dedicarse a los detalles de una porción en particular del código y la otra asegurarse de los estándares de codificación, con el propósito de confrontar el código para validarlo con la historia. Conforme los programadores que trabajaron en parejas culminen su labor, el código desarrollado se va integrar con el trabajo de los restantes de la integración” (Pressman, 2010).
Pruebas: “Como ya se mencionó anteriormente en el enfoque XP las pruebas unitarias se debe de crear antes del inicio de la codificación. Conforme se van creando las pruebas unitarias también se debe de implementar utilizando una estructura de modo que admita su automatización, esto con el propósito de que se puedan repetir con facilidad. Esto permite generar una táctica de pruebas de regresión, cuando se modifique el código, de acuerdo al enfoque XP de rediseño” (Pressman, 2010).
“Cuando se organizan y ejecutan las pruebas unitarias dentro de un conjunto de pruebas universales, las pruebas del sistema tanto de integración como de validación se pueden realizar a diario. Esto otorga al equipo de XP una continua indicación del avance y proporciona señales de aviso sobre la marcha del equipo. Wells dice: Corregir pequeños problemas cada cierto número de horas toma menos tiempo que resolver problemas enormes justo antes del plazo final. Las pruebas de aceptación también denominadas del cliente, son determinadas por el cliente y se basan en peculiaridades y funcionalidades
32 genéricas del sistema, siendo visibles y revisables por el cliente. Mientras que las pruebas de aceptación provienen de las historias de los usuarios” (Pressman, 2010).