Los aspectos más importantes que nadie te dijo antes de empezar a desarrollar una aplicación

Desde hace casi 50 años -desde que Fred Brooks publicó el clásico “El mítico Hombre-Mes”-, los equipos de desarrollo de software han luchado con el modo de desarrollar un proyecto de programación a tiempo y de acuerdo con las especificaciones requeridas.

No es una tarea fácil. Esto es lo que se les olvida decirte antes de que empiezas a desarrollar esa nueva aplicación para un cliente. Aquí van los aspectos más críticos que nadie te dijo antes de empezar a desarrollar una aplicación.

El producto final no se parecerá en nada a las especificaciones originales

Construir una aplicación debería ser bastante sencillo. Te sientas con unas cuantas personas en una sala, te pones de acuerdo en unas cuantas especificaciones y luego dejas que las personas más inteligentes de la sala vayan a trabajar programando lo que acabas de terminar de discutir. Bastante fácil, ¿verdad? Error.

Existe una alta probabilidad de que el producto final no se parezca en nada a las especificaciones originales. Hay un número de muy buenas razones para que esto suceda, y no tiene nada que ver con la competencia (o incompetencia) del equipo de desarrollo de software.

Los plazos cambian. Los planes cambian. En algunos casos, incluso el problema original que se estaba tratando de resolver con los cambios. De hecho, es un milagro que al final se llegue a desarrollar algo 🙂

Cuantas más partes interesadas tenga un proyecto, más complicado será la obtención de un resultado concreto

A primera vista, parecería tener mucho sentido limitar el número de “chefs” en la cocina, pero te sorprendería saber cuántas personas totalmente sensatas lo ignoran.

Al contrario, hay un afán de involucrar no sólo al equipo de desarrollo, sino también al equipo de ventas, al equipo de marketing y tal vez incluso al tipo que está al final del pasillo y que no sabe absolutamente nada de software pero es muy buena persona…

Y lo que sucede a continuación es como el clásico juego del teléfono, en el que cada persona que escucha una conversación la repite de forma ligeramente diferente a la siguiente persona de la cadena.

De acuerdo con lo que ahora se conoce como la Ley de Brooks (en honor a Fred Brooks),  que viene a decir algo así como que “añadir personal a un proyecto de software que va con retraso, solo hace que se retrase más”.

Siempre habrá una parte del producto final del software que nadie sabe exactamente lo que hace

En el mejor de los casos (es el escenario idílico, casi utópico), siempre habrá un trazado directo -uno a uno- entre todas las características diseñadas inicialmente por el equipo de desarrollo de software, y las características finales que aparecen en la aplicación o software. Es decir, una correspondencia total entre las funcionalidades diseñadas sobre el papel y las funcionalidades que efectivamente tiene la aplicación que se ha programado.

Pero el problema es que la mayoría de los equipos de desarrollo de software se sienten tan presionados para que el proyecto salga a flote que escatimarán en la documentación de lo que se supone que cada línea de código debe hacer en realidad.

Si se repite esto muchas veces, inevitablemente conduce a una “característica” que nadie sabe realmente lo que hace, o incluso cómo apareció en primer lugar. (Y hagas lo que hagas, nunca digas que es un “error” – ¡siempre di que es una “funciónalidad”)!

Siempre habrá un miembro de tu equipo encargado de mover “los postes de la portería”

Por mucho que a las personas les guste hablar de “estar alineadas” (o cualquier otra palabra que sea la última jerga del curso MBA), las personas rara vez están alineadas. Eso es lo que nos convierte en personas, y no en máquinas.

Una de esas personas (extraoficialmente, por supuesto) se auto-nombrará a sí misma como la persona encargada de “mover los postes de la portería”. Ya sabes, la persona que se presenta en la reunión del lunes por la mañana y anuncia de la nada que la fecha límite del proyecto se ha adelantado unas semanas, o que una de las funciones hace tiempo olvidadas es ahora “crítica para la misión” y debe ser añadida de inmediato.

Conclusión

Así que si tienes que liderar un proyecto de desarrollo de una aplicación, la próxima vez que te sientes con tu equipo y empieces a negociar los plazos y especificaciones, ten en cuenta estos puntos. Podría ahorrarte mucha sangre, sudor y lágrimas.

Artículos relacionados con proyectos de software

Artículos relacionados: 15 buenas prácticas para proyectos de desarrollo de software, 5 formas de agilizar tus proyectos de desarrollo de software, Podcast: Los secretos de buen análisis en los proyectos de software, ¿Cómo afrontar un nuevo proyecto de software?, ¿Necesitas nuevos proyectos de software? 

Nota: este artículo es una traducción para hacerlo accesible a desarrolladores y programadores hispano-hablantes.

 

Este artículo Los aspectos más importantes que nadie te dijo antes de empezar a desarrollar una aplicación es original de Velneo.

Los secretos de buen análisis en los proyectos de software

¿Quieres aprender las claves para hacer un buen análisis en tus proyectos de software? Te presentamos aquí el podcast de un valor incalculable de nuestros expertos compañeros Jesús Arboleya y Mario Conde, en el que te destripan los secretos de un buen análisis que asegure el éxito de un proyecto de software.

En todo proyecto es necesaria la figura del analista. El trabajo de un analista consta de varias facetas:

1. Escuchar

Tenemos 2 orejas y 1 boca para escuchar el doble de lo que hablamos.
Cuidado con hablar más de la cuenta.
Levantar acta de todas las reuniones.

2. Pensar

El 80% del éxito de un proyecto software depende de un buen análisis.
Documenta tu análisis para que lo puedan entender todos.

3. Abstraer

El papel lo soporta todo, pero las bases de datos no.

4. Concretar

Define la estructura de la base de datos.
La complejidad no es una buena compañera.
Lo complejo suele ser un síntoma de falta de conocimiento.

5. Programar

Analiza, analiza y analiza antes de escribir tu primera línea de código.
En un proyecto de software un mal análisis garantiza un 100% de fracasos.
Evidentemente, tras un buen análisis debe seguir un buen desarrollo.

6. Comunicación

Un buen analista debe ser también un buen comunicador.
Todos los stakeholders deben participar en el proyecto para que tenga éxito.
Al cliente siempre hay que informarlo con antelación de todo, de lo bueno y lo malo.
Por muy buen analista que seas, cometerás errores.

7. Funcionalidad

No caer en el error del efecto “barra libre”.
Menos es más.
No añadir nada que no nos hayan pedido.
Lo que sobra es tan malo como lo que falta”.
Una aplicación nunca está terminada.

Este artículo Los secretos de buen análisis en los proyectos de software es original de Velneo.

Desarrolla aplicaciones a medida con éxito

Ejemplo de Kanbanpad

El desarrollo de software a medida tiene características específicas que lo diferencian del desarrollo de aplicaciones estándar, sin embargo la metodología a seguir en ambos casos es muy similar. En este artículo quiero comentarte 7 aspectos que considero fundamental cuidar desde el principio, para tener éxito en un proyecto de desarrollo de una aplicación a medida.

1. Gestiona tus expectativas y las del cliente

No pienses que te vas a hacer rico con un proyecto a medida. Los clientes no son PaPá Noel, no regalan nada, y tampoco tienen por qué hacerlo, de la misma forma que tú debes hacer valorar tu trabajo. Si consigues un proyecto importante vete pensando que si vas a ganar mucho dinero es porque vas a tener que trabajar mucho. Esfuerzo y facturación suelen ser proporcionales.

El éxito profesional y económico en este tipo de proyectos se consigue a través de una larga relación con tu cliente, basada en la confianza que deberás obtener en base a hacer un buen trabajo cumpliendo plazos y calidad.

2. Sin jefe de proyecto no hay organización

En cualquier proyecto siempre hay como mínimo 2 personas, tu cliente y tú. A medida que el tamaño del proyecto crece también lo hacen las personas que están implicadas en el proyecto. Gestionar un equipo de personas no es fácil, por ese motivo la figura del jefe de proyecto es fundamental.

Sin un jefe de proyecto que haga bien su trabajo el equipo estará inmerso en el caos y la desorganización, te encontrarás con graves problemas de comunicación que derivarán en serios problemas con el cliente, entre los programadores. El trabajo se vuelve complicado, se pierde mucho tiempo en tomar decisiones, los programadores se sentirán perdidos y se buscarán la vida por su cuenta, nadie sabe lo que están haciendo los demás, nadie sabe cuanto llevamos hecho y cuando falta, etc.

No lo dudes si no hay un jefe de proyecto haciendo bien su trabajo, solicita la parada del proyecto hasta que se nombré a uno, y si es preciso coge tú el toro por los cuernos.

3. El responsable de producto debe ser el cliente

Nadie deberia saber más de su negocio que el propio cliente. Nosotros estamos para ayudar al cliente a poner en marcha una herramienta de software que le suponga mejoras en su empresa o negocio y que deberán tener una repercusión económica positiva.

Por este motivo es fundamental que la figura de responsable de producto corra a cargo de un empleado de nuestro cliente. Esta persona debe tener una importante dedicación en horas al proyecto, si no es así el jefe de proyecto debería pararlo inmediatamente hasta que se encuentre la persona que lo pueda llevar a cabo.

Esta persona debe estar en permanente contacto tanto con el jefe de proyecto como con los usuarios finales de la aplicación. Un grave error que debemos evitar es tratar directamente con los usuarios finales sin que esté presente el responsable de producto, lo más probable es que saques conclusiones incorrectas, tu análisis no sirva y haya que deshechar mucho código, tiempo y dinero.

Un buen responsable de producto también debe saber medir los tiempos, las necesidades de la empresa y saber decir no tanto a los usuarios finales como a los programadores cuando tratan de llegar más lejos de lo previsto inicialmente. Si tienes un buen jefe de proyecto y un buen responsable de producto, que aplican bien el criterio de menos es más hay más de un 75% de posibilidades de tener éxito.

4. Utiliza una herramienta online para la gestión de las tareas

Cada vez es más fácil encontrar proyectos donde el equipo está disperso geográficamente, además hay que tener en cuenta a los miembros del equipo que no son de tu empresa. Necesitamos trabajar como un único equipo y para eso es fundamental disponer de una herramienta que nos facilite la gestión de las tareas y la comunicación.

Están de moda las metodologías ágiles, y de esta moda una de las herramientas que mejor me ha funcionado y aportado grandes beneficios son los tableros kanban. Hay cientos de herramientas en el mercado para el uso de tableros kanban, yo te puedo comentar que tengo una magnífica experiencia de uso con dos de ellas:

  • kanbanpad que funciona perfectamente tanto en navegadores de escritorio como en móviles.
  • Trello, una aplicación web que cuenta también con versión para navegador y aplicaciones nativas para iOS y Android.

En otro artículos escribiré más en profundidad las experiencias con cada una de ellas y sus pros y contras.

Gracias a estas herramientas los equipos conocen las tareas pendientes, planificadas, en curso, en fase de pruebas o finalizadas. Todos, incluido el cliente, saben lo que están haciendo los demás, es fácil gestionar los errores encontrados durante las pruebas.

Mi recomendación es que dividas las tareas hasta que puedan ser realizadas en un día como mucho, el objetivo es doble, conseguir que pasen a pruebas tareas todos los días y que el programador se sienta más productivo. Por otro lado el equipo de desarrollo debe tener una comunicación constante, nosotros usamos un chat grupal, como el que nos ofrece por ejemplo Skype.

4. Iteraciones cortas

Si el proyecto lo permite es bueno tener contacto físico con el cliente. Nosotros intentamos tener una reunión presencial en el inicio de cada iteración, en esa reunión se definen y planifican las tareas a desarrollar en las siguientes 2 ó 3 semanas.

2 ó 3 semanas es tiempo suficiente para obtener avances visibles y a la vez es lo suficientemente corto como para reducir el coste de corregir errores en la gestión de las tareas del proyecto. Un mes es mucho tiempo, mejor si las iteraciones pueden ser de 2 semanas.

Las ventajas de realizar iteraciones cortas son múltiples, por un lado simplifica el control de la evolución del proyecto, algo crítico desde el punto de vista económico y del cumplimiento de plazos, por otro lado para los miembros del equipo es más positivo tener 3 tareas pendientes de hacer que ver una lista desde el inicio del proyecto con 100 tareas. Además, los proyectos evolucionan por lo que las tareas deben definirse a corto plazo para que sean efectivas.

Un aspecto fundamental es la prioridad de las tareas, nosotros aplicamos el criterio de priorizar siempre la resolución de incidencias encontradas durante las pruebas a seguir avanzando con otras tareas nuevas. La experiencia nos demuestra que muchas veces la resolución de una incidencia encontrada durante las pruebas de una tarea implica cambios de estructura y de programación que cuanto antes se aplique menos costo en tiempo y dinero supondrá para el proyecto.

En realidad cuando el equipo funciona bien trabaja en lo que podriamos denominar una iteración continua a la que añaden nuevas tareas cada 2 ó 3 semanas.

5. Programa en cloud

Cada día crece el número de personas que hacen teletrabajo y gracias a herramientas de desarrollo de aplicaciones PaaS como Velneo, también crecen el número de desarrolladores que programan en cloud tanto individualmente como en equipo. Programar en la nube aporta numerosas ventajas:

  • Tu código está siempre disponible estés donde estés.
  • No dependes de un equipo, puedes programar desde cualquier ordenador
  • Puedes programar en equipo sin tener que abrir tu red a accesos externos
  • Pruebas tu aplicación en un entorno más real que programar en local
  • Si tu aplicación está optimizada y funciona bien en cloud será un cohete en una red local

Evidentemente, programar en cloud también tiene contras:

  • Grabar tus desarrollos es más lento
  • Las pruebas de importación de datos requieren más tiempo o más programación

Pese a los inconvenientes, te recomiendo que siempre programes en cloud, y que excepcionalmente lo hagas en local para hacer tareas muy puntuales, depurar procesos complejos o pesados o para evitar bloqueos de proyectos con otros desarrolladores del equipo.

En otro artículo, daré más información sobre nuestra experiencia a la hora de abordar el desarrollo en equipo de una aplicación usando el cloud y combinándolo con servidores para uso individual de cada desarrollador y el uso de la importación de componentes.

Desarrollar en cloud tiene además 2 ventajas fundamentales para abordar estos proyectos:

  • El cliente y el responsable de producto pueden ver en todo momento como se avanza en el desarrollo de la aplicación. Es cierto que ven si avanzamos o no, pero la transparencia es nuestra aliada si somos buenos profesionales.
  • El cliente, el responsable de producto y los usuarios finales, puedes hacer las pruebas en tiempo real, con los mismos datos y condiciones que el equipo de desarrollo. Esto ayuda a que sea más sencillo comprender las incidencias reportadas.

Todo esto no implica que en una fase avanzada del proyecto sea conveniente poner en marcha un servidor de desarrollo en el cliente para que puedan tener libertad a la hora de hacer pruebas sin bloquear al equipo de desarrollo que constantemente necesita reiniciar las instancias para probar sus desarrollos.

6. Informa periódicamente a tu cliente de la evolución del proyecto

Salvo que tu cliente sea un autónomo o una empresa pequeña, no es habitual que la dirección participe de forma activa en el proyecto, y aunque el responsable de producto podrá informar de primera mano, es lógico que los directivos deseen conocer el estado del proyecto desde el punto de vista de la empresa que los está programando.

Por ese motivo es importante informar periódicamente, cada iteración o una vez al mes, enviando un informe donde se detallen las acciones realizadas, los módulos o funcionalidad que ya están programadas y probadas, las que se están probando, las que se están programando y las pendientes. No hace falta entrar en profundidad con detalles muy técnicos, hay que tener en cuenta el perfil de quién leerá nuestro informe.

Es importante ser realista y sincero, indicar en todo momento si el proyecto evoluciona favorablemente o si se están produciendo retrasos. Cuanto antes informes, más posibilidades hay que de se puedan tomar medidas correctoras y de que los propios directivos puedan ayudar en la resolución del problema.

Las personas que dieron viabilidad económica al proyecto, están implicadas personalmente en el mismo, y por regla general tienen el mismo deseo que todos los miembros del equipo del proyecto en que sea un éxito, por ese motivo debemos siempre verlos como nuestros aliados, no como nuestros enemigos o evaluadores.

7. Probar, probar, probar y aprobar

Todos los arranques son complicados. Si quieres evitar que la implantación de la aplicación sea un infierno debes asegurarte de que todos los usuarios tienen conocimiento de como funciona la aplicación, la han probado y han dado su visto bueno. Aún así, los datos de pruebas no te van a proteger de que surjan complicaciones durante el arranque, pero al menos evitarás que los usuarios vean a la aplicación como su enemigo, pues ellos mismo han tenido la oportunidad de probarla y aprobarla antes de su puesto en producción.

Para conseguir que los usuarios prueben la aplicación es indispensable el trabajo del responsable de producto que se encargará de probarla personalmente y de validarla con cada uno de los usuarios de la aplicación, bien personalmente o a través los responsables de departamento o área que deberán encargarse de trasladar las tareas de pruebas y validación a toda la organización.

El éxito siempre será el fruto del esfuerzo y del trabajo en equipo

Aún gestionando bien un proyecto y realizando un gran esfuerzo para que todo salga bien, siempre aparecerán muchas dificultades e imprevistos, que deberán superarse en equipo, con respeto, evitando buscar culpables y centrándonos siempre en resolver las incidencias que surjan y las necesidades de nuestro cliente.

Cuando la implantación se estabiliza y el proyecto se convierte en un caso de éxito, no te olvides nunca de disfrutarlo personalmente, con todo el equipo, con el cliente y añadirlo en tu lista de casos de éxito, ya que siempre puede ser la puerta a nuevos clientes y proyectos.

 

Si te ha gustado este artículo, por favor compártelo con los tuyos en las redes sociales

The post Desarrolla aplicaciones a medida con éxito appeared first on Lógica mente Velneo V7.

Velneo V7 7.10: Idiomas de proyecto y de Velneo V7

En la nueva versión de Velneo V7 7.10 hemos incorporado una gran cantidad de mejoras relacionadas con la gestión de idiomas de tus proyectos. La principal mejora que encontrarás es la posibilidad de seleccionar el idioma de entre los definidos en el proyecto. También encontrarás gran número de funciones que te permitirán configurar la visualización de los textos en el idioma que te interese.

Vamos a ver un resumen de las novedades incorporadas y de todas las funcionalidades relacionadas con la gestión de idioma que puedes usar. Descarga Velneo vTranslator V7 y aprovecha todas las posibilidades que te brinda.

Idiomas del proyecto en Velneo V7

Los textos que aparecen en una aplicación realizada con Velneo V7 pueden ser internos (menús en stock, textos del sistema, etc.) o del proyecto Velneo V7.

En la ventana de propiedades del proyecto puedes definir los idiomas que usarás en tu aplicación. Las propiedades de los objetos que admiten idiomas (por ejemplo el nombre del objeto) tienen un editor que permite definir la propiedad en los diferentes idiomas del proyecto.

Idiomas internos de los componentes de Velneo V7

Los ejecutables de los componentes de Velneo V7 (Velneo vClient V7, Velneo vDevelop V7, etc.) se suministran en inglés y español. A esto se añade la opción de incluir en el directorio de aplicación los ficheros de traducción de otro idioma, con lo que los textos de Velneo V7 se podrán visualizar en dicho idioma.

Estos ficheros tienen el formato vClient_IDIOMA_PAIS.qm, donde IDIOMA es el identificador del idioma en formato ISO ISO 639 y PAIS es el identificador del país en formato 3166 (por ejemplo vClient_CA_ES.qm es el fichero de traducción en catalán). Iremos publicando en el Centro de soporte de Velneo los ficheros de traducción realizados por otros suscriptores según los vayan aportando.

Continue reading "Velneo V7 7.10: Idiomas de proyecto y de Velneo V7"

Cmo funcionan las instancias?

El 13 de Noviembre de 2009 se celebr en el saln de actos del Parque Tecnolgico de Gijn el Seminario con Juan Muoz-Cobos.

El vdeo que puedes ver a continuacin corresponde a un fragmento de la ponencia de Juan Muoz-Cobos en el que explica el funcionamiento de las instancias, las diferencias entre proyectos de datos y de aplicacin y cmo personalizar aplicaciones.

¿Cómo organizar los proyectos y soluciones en el server?

Este fin de semana he estado de limpieza. Sí, limpiando mi server de la nube que estaba hecho un pequeño “cajón desastre” y lo necesitaba, por agilidad mía al trabajar con los proyectos y del server también al cargar.

Mi problema era que tenía en el server una solución solamente, “shared” donde tenía muchos proyectos, algunos creados por mí, otros que eran de las open apps que me bajo de Velneo para probar, etc. Necesitaba limpiarlo porque ver la vista de los proyectos en la solución era una maraña bastante difícil de seguir, además al abrir la solución tardaba lo suyo.

Ahora ya está limpio, claro, ágil, además esta tarea me ha ayudado a descubrir unas cuantas cosas, buenas y otras no tan buenas.

Aquí van las buenas:

- Se pueden borrar proyectos!

Simplemente desde el vdevelop, proyectos cargados y botón derecho del ratón, eliminas. No permite eliminar si el proyecto está editado, pero se puede “Des-editar” con la opción “Deshacer desprotección proyecto”

- Se pueden mover objetos entre proyectos! Se mueven también los objetos que el objeto movido esté utilizando, con lo que no hay que ir uno por uno.

Tenía mi proyecto en la solución shared, quería moverlo a la solución “Biblioteca” y pude hacerlo gracias a esta opción, siguiendo estos pasos:

  1. Creé una nueva solución
  2. Dentro de la nueva solución, creé nuevo proyecto de datos y nuevo proyecto de aplicación
  3. En los proyectos originales que estaban en shared, modifiqué sus propiedades, heredando los nuevos, creados en la solución nueva
  4. En los proyectos originales de datos y de aplicación, fui moviendo cada objeto a los nuevos proyectos. Al mover, pasa todo a la carpeta que le indiques, no obstante, hay que ordenar después porque se mueven los objetos que use el primero.

También utilicé esta opción para limpiar iconos que estaba usando de otros proyectos. Moviendo objetos y re-nombrando después en el proyecto nuevo.

- Renombrar objetos y  que los otros usen el nuevo objeto (renombrado) es tan fácil como en 6x.

Estaba heredando y usando unos iconos de proyecto que me había ido bajando de open apps desde el principio, y no estaba muy ordenado. Así que fui moviendo los iconos de los proyectos “anticuados” al proyecto “iconos” que viene por defecto con vBase.

Después en el proyecto iconos, localicé un icono que se adecuase a mi propósito, lo corté y después renombré los que venían del otro proyecto con el nombre del original del proyecto de iconos. Así con todos hasta tener todo limpio. Y después volví a instalarme vBase de modo que ya dejé el proyecto de iconos original.

Todos los objetos de mi proyecto Biblioteca que usaban cualquier icono, renombrado o no, lo capturaron de nuevo sin problema, a pesar de que no eran objetos de su propio proyecto, sino de uno heredado.

En definitiva, que fue un trabajo de “encaje de bolillos” que funcionó a la perfección como siempre, Velneo V7 conserva toda la esencia de esto que ya disfrutábamos en 6x.

Y las no tan buenas

- No se pueden mover proyectos entre soluciones

- Importar componentes te copia las soluciones de un server a otro. Creo que sería interesante si se pudiesen mover las soluciones o algo así como importar dentro del mismo server.

Aunque esto creo que me ha pasado por el desconocimiento inicial, ahora ya no me pilla en un desorden tal ;-)

Organización servidores

Ahora tengo dos servidores en la nube (como son gratis :-) organizados del siguiente modo:

Server 1:

Con las soluciones:

- shared

Open apps que necesite para otros proyectos (que estarán en las otras soluciones).

En esta no tocaré nada para desarrollar. Sólo serán las cosas originales de Velneo.

Por ejemplo cuando Velneo saque una nueva versión de vBase, la reinstalaré, se re-escribirá y todos los proyectos que la hereden ya tendrán todo lo nuevo.

- Mis soluciones

- Biblioteca

- …

Los proyectos aquí siempre podrán heredar los proyectos que estén en shared.

Una solución por aplicación es lo más sensato y organizado.

Server 2:

Con la solución shared solamente. Este servidor lo creé nuevo, registrándome con otra cuenta de e-mail en la página de Velneo, será para bajarme pruebas de las open apps. Se puede decir que será usado de forma temporal para probar, aprender de otras apps, etc.


Reiniciando…

Después del periodo estival, “reiniciamos”

Comparto a continuación una curiosidad y/o detalle a tener en cuenta para no meter la pata:

Estaba modificando la vbase, la tabla de entidades para personalizarle, añadirle unos booleanos que necesitaba, y … una confusión tuve …

Tengo dos versiones de vbase instaladas en mi server, ¿porqué? … eso me preguntaba yo…

Resulta que tenía la aplicación de Agenda que proporciona velneo y ésta tenía heredada la vbase versión 0.1

Así que ojo al modificar las cajas de datos, teniendo en cuenta esto :-) Lo he reportado como sugerencia, que se vean las versiones de las cajas al heredar.

Del proyecto de biblioteca, sigo con él. He decidido darle una vuelta, lo que me ha reportado bastantes errores (no importa! tenemos un magnífico inspector de errores que nos dice el objeto y el control donde está el error), pero en un par de horas estaban solucionados todos los inconvenientes.

He cambiado algo la estructura de tablas, ahora aprovecho el núcleo que proporciona vBase para las entidades (socios, editoriales, …) y también tengo lo de países y direcciones resuelto ahí (me ahorra muchísimo trabajo el heredar esta caja)

Al cambiar tanto la estructura, herencias nuevas y cambios variados, en el vadmin tenía varias instancias con errores… Lo he resuelto borrando las instancias antiguas y instanciando el proyecto de nuevo, al mismo directorio de datos. Así queda ahora (me refiero sólo a las instancias de Biblioteca)

vadmin

También voy a empezar a aplicar los estilos gráficos. Me decanto por “Velneo Mountain Style“, ya os contaré mi experiencia.


Esquemas Velneo 7.1

La versión 7.1 de Velneo liberada a principios de Junio incluía numerosas novedades, entre ellas los esquemas de tablas.

A continuación hacemos un repaso de sus propiedades:

  • “Añadir nodo tabla”. Permite incluir una tabla nueva de las que tengamos heredadas en la caja. En el nodo de la tabla se puede añadir un icono para dicha tabla. El inconveniente es que no se puede modificar el tamaño del icono sino que lo pone a tamaño completo original del mismo.
  • “Añadir texto”. Se pueden tener comentarios sueltos entre las tablas, comentando relaciones entre tablas, etc.
  • “Añadir dibujo”. Podemos insertar iconos en el esquema para hacerlo visualmente más atractivo y utilizarlo como documentación de proyecto por ejemplo. Un pequeño inconveniente es que el tamaño del icono no se puede manipular, lo pone del tamaño original que tenga.
  • “Añadir proceso”. Permite seleccionar un proceso de lista (no permite seleccionar procesos de ficha) de alguna de las tablas e insertarlo en el esquema, generando una flecha verde entre las tablas de origen y destino del proceso. La flecha es verde por defecto, pero se puede personalizar su color y grosor.
  • “Levantar al frente” y “Llevar al fondo”. Si superponemos varias tablas, podemos indicar aquí cuál queremos que vaya en primer plano o no.
  • Tipografías: Cada nodo y cada texto puede tener su tipo de letra y estilo (negrita, cursiva…). Se me ocurre que podemos resaltar las tablas principales del esquema para una mejor lectura del mismo.
  • “Color fuente”. Cada nodo puede tener su color de fuente.
  • “Color fondo”. Podemos escoger el color de fondo del esquema.
  • Zoom: podemos aplicarlo en el esquema de modo que lo podamos ver más grande o pequeño. Por ejemplo cuando hay un esquema con muchas tablas y necesitamos verlo en una pantalla todo.
  • “Aplicar efectos al imprimir”. No tengo claro lo que hace… He probado activando y desactivándola y, aparentemente, no hace nada.
  • “Imprimir”. Como su nombre indica, nos saca por impresora el esquema. Si el esquema es muy grande y no cabe en una página, hemos de aplicar zoom para que quepa en una hoja. Esto lo encuentro totalmente lógico porque un esquema en varias hojas, desde mi punto de vista, puede perder su sentido y claridad al leer.
  • “Imprimir a fichero”. Genera un fichero con el esquema, se me ocurre por ejemplo para añadirlo a un documento de la aplicación, memoria del proyecto (muy necesaria cuando se va a pedir una subvención por el mismo), etc. El fichero que genera es en formato pdf.

Lo que no encuentro es la propiedad de arrastrando entre tablas poder relacionarlas.
Me explico: en 6x cuando estamos en un esquema y pasamos el ratón por encima de una tabla, se activa el puntero en forma de mano y podemos arrastrar de una tabla a otra, generando un enlace maestro-histórico entre ambas tablas (siempre y cuando sea posible relacionarlas, puesto que no permite enlaces redundantes)

Actualización: El objeto esquema está disponible tanto en el proyecto de datos como en el proyecto de aplicación. Desde el proyecto de datos podremos crear nuevos enlaces entre tablas arrastrando el puntero correspondiente entre las tablas que necesitemos enlazar.

En la imagen se ve la barra de herramientas del esquema en el proyecto de datos:

  1. Asistente de creación de nueva tabla
  2. Puntero normal
  3. Puntero arrastrar esquema
  4. Puntero creación de enlace plural (histórico)
  5. Puntero creación de enlace singular (maestro)

toolbar_esquema_datos

En general, creo que es un objeto que nos trae muchas novedades, muchos detalles nuevos y nos facilita las cosas en el sentido de que podemos aplicar más propiedades visuales, lo que nos ayuda a que se lea mejor y más rápidamente, como es el propósito de todo esquema ;-)

esquema tablas velneo 7.1


La implantación y puesta en marcha de un nuevo proyecto

Implantacion

Revisando antiguos post, pero no obsoletos :) , nuevamente he recaído en el post de Nicolás Osuna, Pesadillas del desarrollador, la verdad es que es una buena fuente de inspiración…

De estas “pesadillas” del desarrollador, hoy me voy a centrar en “La implantación y puesta en marcha: si todo funciona realmente bien, la importancia de los datos antiguos, que todos los procesos complicados funcionen, que no haya bugs, gazapos…

Por experiencia y debido a compartir estas pesadillas, una forma de minimizar los problemas que puedan surgir (por no estar correctos todos los datos importados, por no funcionar procesos complicados pero a la vez críticos en la actividad del cliente, que no haya grandes bugs, etc… )  es poniendo en un nuevo directorio diferente al de los datos reales una copia de los datos reales en pruebas. Vamos a hacer un arranque beta, previo al real.

El objetivo es conseguir un compromiso por parte del cliente de que durante x días, trabaje de forma dual, por un lado con su actual software y haciendo exactamente lo mismo con el nuevo software. Ésto supone un esfuerzo por parte del cliente, pero es la mejor prueba de fuego de todo el desarrollo y datos. Aunque nosotros probemos los datos, incluyendo los procesos complicados, nunca conseguiremos llegar a donde los usuarios llegan una vez que se ponen a trabajar con la aplicación.  Y si no, quién no se ha encontrado alguna vez con la pregunta de ¿cómo lo habrá hecho?

Por tanto, si conseguimos este compromiso del cliente y si,  además, finalizado el periodo de pruebas,  comprobamos que los datos y el funcionamiento de todos los procesos es el correcto, sin duda alguna será un seguro que evitará problemas en el arranque real.

Para ello, debemos incluir en el procedimiento de implantación y puesta en marcha un documento de validación previo al arranque, que el cliente debe responsabilizarse a cumplir, algo que no tendremos difícil si nuestro cliente se encuentra implicado en el proyecto y apoya el cambio.

Con todo ésto conseguiremos:
- corregir errores de importación de datos
- detectar errores en procesos críticos
- localizar bugs y gazapos

Esto nos permitirá antes del arranque en real:
- solucionar los problemas anteriores
- minimizar el impacto de cambio de software

Aunque este modo de proceder no va a solucionar todos nuestros problemas, los que permanezcan serán menores y se podrán solucionar sin suponer un mayor impacto al cliente y por supuesto dejará de ser una pesadilla… aunque, posiblemente, ¡tendremos otras!

Saludos a todos!!