| Navegador que pincha sitios Web |
| Paso 2: Proceso de deasarrollo cartón-piedra |
La gran mayoría de los desarrolladores intentaría escribir todo el código de un tirón corresponiente a la Capa de Presentación y a la Capa de lógica de negocio para seguidamente probar el navegador.
- este enfoque sólo nos puede acarrear problemas y muchas horas de trabajo estériles ya que al intentar realizar la primera conexión a un Sitio Web seguramente veríamos que simple y llanamente no lo conseguimos
- y entonces en vez de dedicarnos a desarrollar, a lo que nos dedicaríamos sería a ir poniendo parches aquí y allí para que finalmente nos funcionara.
En vez de seguir este enfoque, lo que vamos a hacer será crear la aplicación en su conjunto y hacerla funcionar con el proceso de desarrollo cartón-piedra. Es decir, nos creamos los métodos del esqueleto de la aplicación que devuelven valores a piñón fijo. así de esta forma no nos perderemos en los detalles y trabajaremos con una visión de conjunto tal y como hacen los analistas y los diseñadores UML.
Asi pues, en vez de escribir hasta el último detalle todo el código de bajo nivel de verificación de datos, lo que haremos será simplemente devolver unos valores por defecto que nos permitirán en un tiempo relativamente corto probar toda la aplicación. Imaginando que esta aplicación fuera más extensa y la tuviéramos que realizar en 6 meses con iteraciones de 2 meses. Es decir visitar al cliente que nos solicita dicha aplicación cada dos meses.
- en la primera iteración le habríamos mostrado la Capa de Cliente y es en ese momento cuando el cliente tiene que decir si está deacuerdo en como los componentes gráficos están situados y nos dirá o nos tendría que decir si hay algún detalle que le desagrada para así de esta forma nosotros retocarlo y a los pocos días volverle a enseñar la interfaz gráfica para finalmente recibir el visto bueno.
- en en la segunda iteración sería conveniente que la aplicación mostrada al cliente ya fuera operativa a nivel cartón-piedra, es decir sólo nos pudiéramos conectar a un sitio web predefinido. De esta forma el cliente ya ve como la aplicación funciona en su conjunto pero todavía nos queda escribir el código de bajo nivel de verificación de datos.
- aquí sucede lo mismo que en la iteración anterior, si el cliente ve alguna cosa que le desagrada nos lo comunica y entonces llegamos a un acuerdo sobre si los cambios que él propone tienen que realizarse.
- en esta iteración hemos atacado la parte de código de la aplicación más costosa que es la Capa de lógica de negocio, en vez de haberla dejado para el final, es decir para la tercera y última iteración.
- en la tercera iteración en la cual ya entregaríamos el producto, sólo nos queda hacer parte de la Capa de presentación que contiene código de bajo nivel. Estamos en la recta final del proyecto, y sabemos que las partes de más riesgo de éste ya están cubiertas, es decir el cliente está satisfecho con la interfaz gráfica y hemos conseguido bajarnos un mensaje HTTP de un sitio Web, que a su vez es la razón de ser de esta aplicación. Por tanto ya estamos afrontando esta última parte del proyecto sin nervios y sin sobresaltos porque las partes de más riesgo de la aplicación ya están cubiertas.
- en esta iteración vamos a ir sustituyendo el cartón-piedra paulatinamente por ladrillos- y- cemento y así de esta forma vamos a ir probando uno por uno cada uno de los filtros correspondientes a los datos entrados por el usuario.
- por ejemplo en una aplicacón se puede utilizar cartón-piedra creándonos una matriz con un juego de datos ficticios y más adelante retirar el cartón-piedra y realizar conexiones a una Base de Datos con datos reales.
- en el caso de que a pesar de todo faltaran por ejemplo dos días para la entrega y nos diéramos cuenta de que no tenemos suficiente tiempo para finalizar esta tercera y última iteración está claro que de la manera que hemos planteado el proyecto podremos pedir ayuda a compañeros de nuestro equipo para que realicen tal o cual método de verificación de datos por separado y cuando lo hubieran terminado ensamblarlo al conjunto de la aplicación.
- por el contrario si le hubiéramos dedicado todo el tiempo del mundo primeramente a la verificación de los datos intentando bordar hasta la saciedad un código de bajo nivel, entonces irremediablemente se nos hecharía el tiempo encima y nos daríamos cuenta que no tenemos sufieciente tiempo para realizar el código de la Capa de Negocio y éste código a diferencia del código de presentación no es ni de lejos tan fácil de delegar en otros desarrolladores y en definitiva no podríamos entregar en los plazos previstos.
