3.2.3.Especificaciones de desarrollo y pruebas

3.2.3.Especificaciones de desarrollo y pruebas

Llegados a este punto, estaremos en condiciones de establecer las condiciones y características del entorno de desarrollo en los siguientes términos:

• Entorno tecnológico: hardware, software y comunicaciones. • Herramientas de desarrollo: IDE, generadores de código, compiladores, etc. • Herramientas de documentación. • Restricciones técnicas. • Requisitos de seguridad del entorno.

También deberemos ser capaces de definir las pruebas necesarias que se deberán realizar para asegurar el funcionamiento del sistema una vez implantado. Éstas deberían definirse como pruebas unitarias, es decir, pruebas con el mínimo nivel posible de dependencia entre ellas para permitir un desarrollo o una integración software por componentes, donde cada equipo pueda trabajar y probar independientemente, dejando para la fase final las pruebas de integración.

La especificación de las pruebas unitarias se divide en pruebas de caja blanca y pruebas de caja negra:

• Caja negra: se considera el componente desde el punto de vista funcional, analizando sus entradas y salidas, y comparando todas sus posibilidades con los resultados esperados.

• Caja blanca: se considera el componente como una estructura con una secuencia lógica de eventos y se comprueba la validez de ésta, el código no usado, comprobaciones contempladas, etc.

Normalmente, se usará una combinación de los dos tipos de pruebas, según el componente o su funcionalidad. Tradicionalmente, se tiende a realizar las pruebas de los componentes una vez desarrollados. Las metodologías más recientes recomiendan invertir este proceso, y justifican la realización de las pruebas previamente a las de los propios componentes software por las siguientes razones:

• Al disponer de la funcionalidad requerida de los componentes, estamos en disposición de diseñarlas.

• Desde el primer momento podremos probar que nuestros componentes cumplen o van cumpliendo las funcionalidades.

• Es mejor crear un componente con el objetivo de pasar las pruebas diseñadas, que crear uno que tenga la funcionalidad requerida. De este modo se evita que los programadores introduzcan efectos colaterales o crean que determinada funcionalidad también será necesaria y la introduzcan.

• Se ha demostrado que si las pruebas están bien diseñadas y son completas, los programadores tardarán igual o menos en crear un componente que cumpla las funcionalidades que uno que simplemente pase los tests diseñados.

• Aunque tradicionalmente se dejan las pruebas para el final del desarrollo, éstas son las que más frecuentemente provocan retrasos en el proyecto. Este enfoque de pruebas unitarias mitiga estos retrasos y optimiza el desarrollo que ahora se enfoca directamente a obtener resultados, entendidos como tests pasados satisfactoriamente.

Para cada una de las pruebas, deberemos definir sus posibles parámetros o información de entrada, y sus posibles resultados o información de salida. Esto nos permitirá más adelante programar cada uno de los tests bajo el marco de trabajo de tests unitarios elegido.

Caso práctico

Definición de las especificaciones de desarrollo y pruebas del subsistema

El subsistema gestor de contenidos debe permitir administrar el contenido del sitio web, así como ofrecer la posibilidad de contratar paquetes de horas de servicio. Algunos de los subsistemas que lo integran, como el que permitirá la edición de contenidos o el de comercio electrónico, serán implementados a través de los productos elegidos de entre los existentes en el mercado. Por el contrario, la utilización del terminal punto de venta virtual de la entidad bancaria escogida, o la integración con la aplicación de gestión de la empresa, exigirán un desarrollo a medida que permita su correcta integración.

Así pues, se deberá desarrollar una interfaz que permita la comunicación con la aplicación de gestión de la empresa, de tal forma que cuando se realice un pedido éste pase a constar de forma automática en dicha aplicación.

Al determinar el lenguaje elegido para el desarrollo, se consideran las siguientes alternativas:

• Perl (http://www.perl.org/): lenguaje de script muy flexible y versátil, dispone de multitud de librerías de apoyo y una comunidad de usuarios extensa. Permite orientación a objetos.

• PHP (http://www.php.net/): lenguaje de script especialmente diseñado para la realización de aplicaciones web. Dispone de multitud de librerías de apoyo y una comunidad de usuarios extensa.

• Java (http://java.sun.com/): lenguaje interpretado y orientado a objetos, con tecnologías complementarias indicadas para llevar a cabo ciertas tareas (p. ej. servlets, JSP). Dispone de multitud de librerías de apoyo y una comunidad de usuarios extensa.

Por su amplia aceptación y disponibilidad de librerías de apoyo, así como su fácil integración con posibles herramientas de gestión de contenidos, Soluciones Abiertas, S. A. decide utilizar el lenguaje PHP.

Al determinar el entorno de desarrollo, se consideran las siguientes alternativas:

• Jedit (http://www.jedit.org/): se trata de un entorno muy potente desarrollado en Java y por tanto multiplataforma, con un conjunto de plug-ins que proporcionan funcionalidades adicionales como detección de sintaxis y navegación avanzada por el código, integración con sistemas de control de versiones, etc.

• Vim (http://www.vim.org/): se trata de una extensión del editor 'vi' incluido en casi todos los sistemas

Unix. Ha sido mejorado para facilitar su uso, y dispone de interfaz gráfica e interfaz de texto.