Es una de las últimas «discusiones» que he disfrutado desde la web, se corresponde a la que Ian Marteens, que ya muchos conoceis a través de la serie de libros «La cara Oculta de…» que extendió desde Delphi hasta C#, mantenía hace unos día acerca de UML y de los Gestores de Proyectos.
Marteens, además de escribir en las páginas de Insight, donde se comercializan algunos de sus proyectos profesionales, deja su opinión -por ejemplo- en el blog que mantiene en:
http://www.commanet.net/. Os adelanto que no tiene desperdicio y os animo en general a leerlo, como una buena parte de las cosas que escribe. Para muchos compañeros es un maestro. De hecho, cualquiera de los programadores que se inician en bases de datos pueden encontrar en sus libros un magnifico referente para dar esos primeros pasos, lejos de los discursos teóricos tan propios de la Universidad.
La discusión se iniciaba en la entrada [Gestores de Proyectos] del día 17 de Mayo. La seguí de cerca porque tengo amistad y relaciones de trabajo con el programador que inicia la discusión, y andaba Juan, que así se llama mi compañero de trabajo, valorando la necesidad de hacer uso de un gestor que le permitiera el trabajo en equipo y versionar los proyectos, de forma similar a como pueden hacerlo otros desarrollos. Borland ofreció a sus desarrolladores un producto como TeamSource que permitía el trabajo en equipo pero por diversas razones, como sucede con bastantes productos, no llegó a cuajar.
Posterior a esta entrada, y relacionada con ella, se aborda el tema de UML y aunque no tenga una relación directa con el versionado, afecta de lleno a la metodologia de trabajo. Y Nicolas Aragón (conocido programador entre los delphinomanos que rondaron algunos foros de trabajo) da una replica a Marteens desde su blog en este último tema y queda en el aire un cierto no se que de desconcierto… 😦 A partir de ahí, los lectores del blog de Marteens se posicionan en una ristra de comentarios inacabable, donde el mismo Marteens tiene que mediar para que no acabe aquello como el Rosario de la Aurora.
En mi opinión la pregunta es compleja. Todos conocen UML y han pasado algunos minutos insertando dibujitos cabezones y pinchando globitos que llamamos casos de uso. Hemos, incluso en algun momento, diseñado las clases y estampado las firmas de los métodos pero no sabemos hasta donde llegar y queda al criterio del programador valorar si tiene suficiente con un diagrama o se queda corto, porque nadie le obliga en definitiva a hacerlo de una forma o de otra. Para haceros una idea, pienso que UML podría simbolizar los planos de la misma forma que entendemos este concepto en la arquitectura. No me imagino a mi cuñado, que curiosamente es Arquitecto, planteandose en cada nuevo proyecto la forma en la que diseña sus planos y preguntandose si en ese proyecto concreto se puede ahorrar tal o cual plano o capa. La legislación establece que planos debe presentar y en que condiciones, para que un proyecto pueda validarse y recibir las certificaciones. ¿Es este el caso del software…?
Yo creo sinceramente que no. Para estar nuestros desarrollos a la altura de los proyectos que pueda ejecutar un arquitecto, nuestro cliente debería tener una especificación y un detalle completo de lo que hace nuestro software, con la misma presición que puedan tener los planos del arquitecto respecto a la ejecución de su proyecto. Si una habitación tiene una area de 20 mtros. cuadrados y en la realidad los tiene, es porque aquellos que han ejecutado la obra han leido los mismos planos que en su día diseño y dibujo el arquitecto. Por supuesto que se encarecerían los desarrollos, pero existiría una garantia legal de que nuestros programas hacen lo que tienen que hacer. Y ahora me dirán que eso ya existe… y que en los «grandes» desarrollos ya existen contratos donde se determina de antemano esta «memoria de calidades» de nuestro software. Esa es la diferencia. Al arquitecto, la ley le obliga tanto si edifica un mostruoso rascacielos como si se tratara de un chalet en la sierra (y se supone que los requisitos en el primer caso serán mayores)… Si mi primo, el del kiosko me pide un programa para llevar el recuento de sobres del pokemon, que vende a crios como a mi hijo, no creo que le haga el diseño en UML, no creo que utilice tampoco herencia para diseñar la clase TSobre, ni que exista el metodo Vender… sobretodo porque mi primo es de los que tardan en pagar… tarde mal y nunca.
Delphi Básico 
Comentarios recientes