Si, veamos… ¿De qué tipo? ¿Un Chalet? ¿Un bloque de pisos? ¿Un palacio de congresos?
Pues no lo sabemos. Usted empiece por el chalet y luego si eso ya lo cambia si necesitamos otra cosa…
Pero… oiga… ¿No tiene ustedes documentos sobre el proyecto? Es que sin eso, va a ser difícil hacer los planos…
Uy no, si tenemos que enseñar la construcción a unos posibles compradores en 5 semanas, no podemos perder el tiempo en esas cosas… Usted pregunte, pregunte…
¿Qué uso le van a dar?
Pues…. De todo.
¿Qué capacidad de personas necesitan?
La máxima
Oiga, así no vamos a ningún sitio, si no me dice lo que necesita, no podemos hacer nada… Tienen ustedes que detallar sus necesidades o no sabré ni qué materiales comprar, ni qué cimientos poner…
Mire, no vamos a perder un mes en decirle lo que quiere y que usted se entretenga en hacer los planos, con las técnicas modernas que hay ahora, lo hace usted así como flexible y modular y que se pueda cambiar todo en un pispás si es necesario… Parece mentira que yo, que no tengo ni idea de arquitectura, le tenga que decir cómo tiene que hacer las cosas … Y por cierto, si nos dice también qué posibles cosas podríamos necesitar para el edificio, cosas que crea que son importantes para nosotros, pues …
¿O sea, que quiere que adivine qué van a necesitar?
Bueno, sí usando las modernas tecnologías supongo que no le será complicado… En fin… ¿Cuánto tardaría?
No tengo ni idea.
Algo aproximado…
Vale 1 ó 2 años.
Vaya, pues no me imaginaba yo este proyecto de 1 ó 2 años…
Mire, sin que me diga lo que quiere, sin planos, sin que me diga qué quiere enseñar en ese piloto a sus cliente, … Pues esa es mi estimación.
¡Está bien, está bien! ¡Aquí tiene! ¡No ponéis nada de vuestra parte!
Oiga, esto es un folio en el que pone: “ALGO PARECIDO A MARINA D’OR”
Ale, ¡Ya tiene lo que necesitaba! Lo necesitamos todo para dentro de seis meses.
Problema: a partir de una lista de objetos de tipo “Coche”, quiero sumar el precio de cada uno de ellos agrupado por marca.
La clase coche tiene la siguiente forma
public class Coche
{
public int IdCoche { get; set; }
public string Matricula { get; set; }
public int IdMarca { get; set; }
public int NumeroPuertas { get; set; }
public int Precio { get; set; }
public Coche(int idCoche, string matricula, int idMarca, int numeroPuertas, int precio)
{
this.IdCoche = idCoche;
this.Matricula = matricula;
this.IdMarca = idMarca;
this.NumeroPuertas = numeroPuertas;
this.Precio = precio;
}
}
Inicializamos una lista con objetos de la clase Coche
Desde hace unos años atrás los entornos virtualizados se abren camino y cada día se encuentran presentes con mayor frecuencia en el mundo del desarrollo de aplicaciones.
La virtualización presenta una mejora principal que es el ahorro de costes asociado a la compra de servidores. Ya no va a ser necesario comprar n máquinas encargadas de soportar servidores web, servidores de base de datos, servidores de ficheros, correo electrónico. Cada máquina viene a representar un coste en Hardware más que significativo. Con la virtualización es posible disponer de un único soporte hardware que albergue n servidores virtualizados a nivel de software y que puedan dar soporte a las necesidades de la organización. Es mucho más económico adquirir uno o dos servidores para la virtualización, donde albergar n máquinas virtuales, que n servidores físicos.
Otra de las mejoras presentes con la virtualización es la escabilidad, la portabilidad y el control. Desde nuestros servidores de entornos virtualizados se puede gestionar de forma centralizada qué máquinas virtuales están activas en un momento dado así como el consumo de memoria ram y de disco de cada una de ellas. Esto nos permite tomar decisiones, y poder en un momento dado apagar una de las máquinas virtuales que no esté en uso para liberar recursos del servidor de virtualización. El despliegue de nuevos entornos virtualizados se torna también más sencillo, una vez disponemos de una máquina virtual modelo, podemos realizar réplicas para los diferentes entornos y/o proyectos, que queden expuestas a los desarrolladores una vez se han publicado en el servidor de virtualización pertinente. Respecto a la escalabilidad, las máquinas virtuales puede ser configuradas de forma dinámica con un tamaño de disco y memoria determinados, que puede variar en el tiempo, por lo que a mayores recursos necesarios para la máquina virtual, vamos a poder escalarlos mediante configuración (siempre que la máquina física disponga de los medios necesarios, claro).
Es común el uso de entornos virtualizados para dar soporte al desarrollo de aplicaciones, como por ejemplo para crear un entorno de desarrollo donde participen diferentes entidades como servidores de aplicaciones y de base de datos. También es fácil encontrar que incluso se utilice esta práctica para entornos pre-productivos.
Respecto a las pegas de estos sistemas, la principal problemática asociada es la del rendimiento, de ahí que se descarte el uso de la virtualización en muchos casos en entornos de producción, donde la velocidad de respuesta en muchos casos puede resultar crítica.
En el mercado podemos encontrar dos productos principales que ofrecen soporte respecto a la virtualización: VMWare y Virtual PC de Microsoft.
A continuación un simple ejemplo de lo que podría ser un entorno de desarrollo para N desarrolladores trabajando conjuntamente en el desarrollo de un aplicativo sobre AgilePoint BPM, y con la gestión de código fuente de la aplicación mediante Team Foundation Server.
El entorno del desarrollador que podría distribuirse facilmente mediante máquinas virtuales, cuenta con todo lo necesario para la construcción. Visual Studio 2008 SP1 + Framework 3.5 SP1 para trabajar con las últimas versiones estables y consolidadas en el mercado de tecnología .NET. En el caso de estar trabajando en el desarrollo de aplicaciones web, un IIS local donde desplegar las aplicaciones web y hacer las pertinentes pruebas de desarrollo y debugs. A Visual Studio se le incorpora el plugin AgilePoint Developer para el desarrollo a medida de nuevos AgileWorks, AgileParts y AgileConnectors. Finalmente se cuenta con la disponibilidad de Microsoft Visio 2007 más el plugin AgilePoint Envision, para el desarrollo en local de las plantillas (flujos de trabajo) de AgilePoint.
En el repositorio central se almacena todo el código fuente generado por los desarrolladores mediante el uso de Team Foundation Server, que garantiza la trazabilidad del código, gestión de versiones, etc; además de poder convertirse en una herramienta de gestión y control centralizado del trabajo asociado al desarrollador. Asignación de trabajo mediante el uso de Work Items, y el control de los bugs existentes en la aplicación son algunas de sus capacidades. Al mismo tiempo, mientras el uso de Sharepoint, permite crear fácilmente portales asociados a cada uno de los proyectos en desarrollo, donde el equipo de construcción puede compartir documentación de forma centralizada y todo tipo de información de gestión o técnica asociada a cada uno de los proyectos. Debemos tener en cuenta que este entorno deberá mantener también el control de versiones asociado a las plantillas de Visio que se vayan generando mediante NVision.
El entorno de desarrollo de Agilepoint, que centraliza tanto el AgilePoint Server, la gestión web del mismo a través del Enterprise Manager, y el interfaz de servicios web que permite gestionar de forma remota y transparente el acceso a las facilidades que provee el motor de Agilepoint.
Finalmente se expone un último entorno, representativo de cada tipo de aplicación, que no hace más que definir la posible existencia de un tercer entorno de integración, necesario para el desarrollo de la aplicación, como otros servicios de comunicación u otros aplicativos existentes en el sistema sobre los que nuestra aplicación en desarrollo deba integrarse.
Hasta el momento solo habíamos hablado de malas y buenas prácticas que estaban asociadas a labores de construcción de bajo nivel, pero, éstas, aunque siendo sin duda malas prácticas, quedan bajo la sombra que provocan otras prácticas de dudosa viabilidad que se llevan a cabo en niveles más altos, y sobre las que el impacto en un proyecto de desarrollo de software es aún mucho más pesado.
Un ejemplo muy claro es el incluir en un documento de descripción de la funcionalidad (Documento funcional o de Requerimientos o como estéis más acostumbrado a llamarlo), descripciones que tienen que ver con la parte técnica. Si además de describir cómo ha de comportarse algo funcionalmente, incluimos la pantalla asociada a la funcionalidad en el mismo documento, y además describimos lo que tiene que hacer la pantalla (si pulso aquí se desplegará un menú, si hago botón derecho me saldrán las opciones “juan” y “pedro”, si paso el ratón por encima de la zona central se mostrará un aviso indicando el nombre del formulario…) estamos haciendo el documento funcional totalmente dependiente de la tecnología a emplear, cuando este último debería limitarse únicamente a describir el negocio de la aplicación.
De ahí que, bajo mi punto de vista, así como el uso de diferentes capas a la hora de definir una arquitectura de software es una buena herramienta de diseño, aplicar el mismo concepto a la documentación funcional también lo es.
Sería interesante entonces trabajar a dos niveles. Inicialmente crear el documento estrictamente funcional, desarrollado por un analista o experto en el negocio incluyendo en el mismo casos de uso, requerimientos y reglas del negocio. A partir de ahí, y tras análisis del documento funcional, un perfil algo más técnico, con conocimientos de usabilidad y de arquitectura de software, debería evaluar la documentación y proponer (además de una arquitectura de software adecuada para el tipo de funcionalidad requerida), cómo orientar la funcionalidad a la pantalla que va a ver el usuario, creando los prototipos pertinentes, bajo la perspectiva de la tecnología seleccionada para la solución.
Y es que en más ocasiones de las que nos gustaría, en el mundo del software nos encontramos con situaciones que responden comunmente al siguiente símil.
Juan tiene un clavo y Pedro un destornillador. Juntos, quieren conseguir clavar el clavo en una tabla. Alberto, un amigo de ambos, tiene un martillo y también sabe usar el destornillador.
Antes de comenzar el trabajo Juan y Pedro se reunen; y tras descartar el pedirle el martillo a Alberto, por motivos que desconocemos, deciden clavar el clavo en la tabla con el destornillador.
Alberto, que participa como observador en la reunión, analiza la situación y transmite a Juan y Pedro sus conclusiones:
Si intentan clavar el clavo con el destornillador, puede que al final lo claven, ahora bien, al no ser la herramienta más adecuada, van a necesitar invertir muchos recursos para conseguirlo, ya que van a enfrentarse a innumerables problemas.
Si lo clavan, seguramente o quede el clavo torcido, o acaben rompiendo el destornillador.
Si saben que yo tengo un martillo, y que sé clavar clavos con él, ¿por qué no me lo piden?
A partir de aquí aparecen las tres vertientes de la historia:
Juan y Pedro le piden el martillo a Alberto. El clavo se clava y todos son felices. (Esta no suele ocurrir).
Juan y Pedro proceden con su idea inicial. Un año más tarde de lo previsto la mitad del clavo y torcido está casi clavado en la tabla. El destornillador ya no sirve. (Esta os sonará más).
Juan, Pedro y Alberto siguen la reunión hablando de más alternativas, de las expectativas y necesidades de cada uno. Finalmente, caen en la cuenta que a Juan no le importa quitar algo de la superficie de su clavo (donde debería golpear el martillo), ya que la final lo que quiere es clavar el clavo y eso no le afecta a su objetivo. Curiosamente el hueco que dejan en la superficie del clavo es el suficiente para que encaje el destornillador y conseguir así, sin apenas esfuerzos extra respecto al martillo, clavar el nuevo tornillo, salido tras manipular el clavo, con el destornillador. (Esta tampoco suele ocurrir).
Para los menos imaginativos o exhaustos tras una dura jornada de trabajo, una pista: la historia la ha escrito Alberto.
A pesar de lo poco que me deja últimamente el trabajo el ir añadiendo artítulos, parece que el número de visitas se está manteniendo e incluso subiendo ligeramente la media.
Eso ha hecho que la página haya adquirido en los últimos días el Page Rank 5 de Google.
La última subida, que fue a 4, se dio el 14/01/2009 y parece que menos de un año después las cosas siguen mejorando.
Simplemente seguir insistiendo en los agradecimientos, ya que con vuestras visitas y vuestros comentarios a los artítulos, sois los que estáis haciendo que cada día este blog se encuentre cada vez mejor posicionado.
