archivo

Archivos diarios: diciembre 31, 2012

Que un proyecto sea complejo y/o tenga numerosas resistencias no debe ser excusa para tratar de obtener la mayor calidad posible del software y del producto dentro del contexto en el que nos toque trabajar.

Por ese motivo, los equipos de proyecto deben establecer mecanismos para garantizar esos umbrales de calidad y la coordinación general del mismo debe armonizarlos y exigirlos siempre teniendo en cuenta el contexto y nuestras posibilidades, y también las características del sistema que se desarrolla: un sistema crítico en el que se pone en juego la integridad de las personas, del medio ambiente o la cuenta de resultados de una organización requerirá unos mecanismos de control más estrictos que otros tipos de aplicaciones (en lógica, ese sistema debería tener un presupuesto de trabajo acorde a esas características).

Meses trabajando en el proyecto, con un desgaste importante y en el que cada día es una aventura nueva. Decenas de personas trabajando, de organizaciones y departamentos distintos. Riesgos que aparecen de forma continua. Y detrás de todo una agenda que cumplir, que podremos negociar con el área usuario (o no), pero que al fin y al cabo te establece unos hitos y unos límites.

Este puede ser el día a día de gran parte de los proyectos de desarrollo de software en los que estamos trabajando, en resumen, mucha dificultad y mucho trabajo para conseguir que salga adelante de la manera más satisfactoria posible para todas las partes. Si además, tratamos de que llegar lo más próximo al límite de la calidad que nos permite tener el contexto del proyecto el esfuerzo será muchísimo mayor.

El equipo de testing no debería ser ajeno a las intrahistorias del proyecto, a la complejidad que se está teniendo en el proceso de desarrollo, si me apuráis incluso a ese sufrimiento para sacar el trabajo adelante, por ese motivo recomiendo que los testers participen activamente en los trabajos porque de esta forma su empatía con el resto del equipo le permitirá entender por qué se ha actuado de una manera o de otra.

De esta manera no solo la labor del tester es más efectiva sino que los controles de calidad tienen en cuenta todo lo que ha pasado.

Resulta demoledor para los desarrolladores cuando haciendo una presentación del estado de desarrollo del proyecto al equipo de testing, estos empiezan a fijarse en detalles sin importancia teniendo en cuenta todo lo que se ha tenido que pasar para llegar a ese momento, es como si después de haberte perdido en el bosque un día de tormenta, lo primero que te dicen cuando llegas a casa es que hay que ver que cómo es posible que se te caído un botón de la camisa.

Como vengo haciendo al final de estos dos últimos años, os pongo la lista de los 25 artículos más visitados desde que empecé con el blog. Os pongo los enlaces de acceso, por si os interesa leer alguno.

1.- Desarrollo de software. Ciclo de vida RUP (Rational Unified Process).
2.- Desarrollo de software. El analista funcional y el analista orgánico.
3.- Mantenimiento adaptativo.
4.- Orientación al producto.
5.- La importancia de un buen análisis funcional.
6.- Ahora más que nunca hay que mirar al software libre.
7.- Mantenimiento correctivo y mantenimiento evolutivo.
8.- Las precondiciones y postcondiciones en los casos de uso.
9.- Ciclo de vida iterativo incremental.
10.- Ciclo de vida clásico o en cascada.
11.- LCOM4 y la falta de cohesión en las clases.
12.- Delimitar el alcance del proyecto.
13.- Desarrollo de software. Programación extrema (eXtreme Programming: XP).
14.- Empresas de desarrollo de software: ¿estructura vertical u horizontal?.
15.- La crisis del software.
16.- Complejidad ciclomática.
17.- Reducción de tiempos muertos.
18.- El papel de los usuarios en un proyecto de desarrollo de software.
19.- Testing de caja gris (Grey box testing).
20.- Proyectos de desarrollo de software: La importancia de las métricas y de la documentación.
21.- Pruebas de regresión.
22.- Desarrollo de software. Método de desarrollo de sistemas dinámicos (DSDM) III.
23.- El paso a producción.
24.- Ciclo de vida por prototipos.
25.- PMD: Security – Array is stored directly.

Si queréis consultar las listas de los dos últimos años:

Los 25 artículos más leídos de mi blog
Los 25 artículos más leídos de mi blog II