archivo

Archivos diarios: marzo 26, 2011

Esta estrategia de desarrollo de software se basa en la construcción de un prototipo preliminar que se utilizará como apoyo para la toma de requisitos del sistema.

Para que el proyecto se mantenga dentro de los parámetros económicos y plazos establecidos, la construcción del prototipo tiene que ser rápida y en el caso de sistemas de información de gran tamaño, se debe de centrar en aquellos aspectos donde resulta más complicado obtener los requerimientos por parte del usuario y en aquellas funcionalidades que sean más críticas.

El prototipo puede ser modificado si con eso se ayuda a seguir perfilando los requisitos.

Una vez catalogados los requisitos y se tenga clara la operativa de funcionamiento de la aplicación, se iniciaría el desarrollo del sistema de información desde su fase de análisis, desechando el prototipo que quedará simplemente a modo de recordatorio, por si hay algunos aspectos que considera de interés recordar.

Este tipo de ciclo de vida tiene como principal ventaja que es más sencillo obtener las especificaciones de los usuarios si ven algo en funcionamiento (aunque no tenga todas las funcionalidades implementadas, se hayan descuidado algunos aspectos del diseño o tengan algunos errores).

También presenta varios inconvenientes:

– Se puede caer en la tentación de realizar la construcción del sistema utilizando el prototipo, realizando evoluciones sobre el mismo. Hay que tener en cuenta que si el prototipo se ha desarrollado de forma rápida, muy probablemente se hayan descuidado bastantes aspectos relacionados con la calidad del software, esto implica que el producto final heredará muy probablemente muchos de esos defectos.

– Puede crear falsas expectativas al cliente u usuario del sistema, ya que en un tiempo razonablemente corto, ven un sistema funcionando (aunque sea parcialmente y con errores) y una vez terminado el propósito de los prototipos, tardan bastante tiempo en ver una primera versión utilizable del producto.

– Si el prototipo es modificado varias veces, se incrementará el riesgo de caer en el primer inconveniente descrito o de salirse de la estimación de tiempo y esfuerzo prevista inicialmente.

El día a día es el principal obstáculo para conseguir nuestros objetivos. Estar apagando fuegos nos hace perder nuestra perspectiva.

Dado que es prácticamente inevitable dejar a un lado los tareas que surgen en nuestros proyectos todos los días es necesario dejar un hueco para evaluar el grado de cumplimiento de las metas que te permiten llegar a tus objetivos, así como para simplemente recordar a dónde quieres llegar.

Para conseguir los objetivos es necesario tenerlos presentes siempre, independientemente de las circunstancias laborales o personales que te ocupen en cada momento.

Hilary Hinton “Zig” Ziglar es un conocido autor y conferenciante americano. Es autor de numerosas citas, de las cuales voy a seleccionar una de ellas:

“Es tu actitud y no tu aptitud, la que determina tu altitud”.

El talento sin actitud no es nada, es como tener una importante suma de dinero en el banco y no utilizarlo. Con unos niveles de aptitud que superen el umbral a partir del cual se pueda realizar adecuadamente una actividad profesional, una buena actitud puede hacer que personas que lo mismo tienen menos talento consigan unos resultados excepcionalmente mejores que otros que tienen mejores aptitudes y además tendrán un crecimiento que les permitirá reducir las distancias con quienes ya tienen un determinado nivel de talento e incluso superarlos.

En muchas ocasiones cuando hemos señalado un punto en un mapa hemos optado por poner un punto gordo, para señalar la posición aproximada de un elemento en el mismo, es decir, hemos buscado una solución basada en la generalización que si bien puede resultar de utilidad en algunos casos, puede resultar inútil y contraproducente en otros, ya que por ejemplo, la utilidad del punto gordo se reduce en función del tamaño del mismo y de la escala en que se dibujo.

Muchos gestores utilizan esta misma estrategia para tratar a sus recursos humanos, aplican el punto gordo, generalizan y aplican una determinada política a un conjunto de personas que ni por asomo han tenido un comportamiento similar en términos de productividad y resultados.

¿Qué circunstancias les hace aplicar el teorema del punto gordo? Principalmente el desconocimiento real de lo que hace cada cada persona y porque para ellos es lo más fácil, ya que creen que es justo tratar a todo el mundo por igual y eso lo es en algunos aspectos, pero no lo es en muchos otros.

Si te esfuerzas en el trabajo, aplicas estrategias para intentar se lo más productivo posible, obtienes resultados y sin embargo te tratan igual (o peor) que otros que no tienen ni tu compromiso, ni tu dedicación, ni tus logros, terminas tarde o temprano por desmoronarte y tiene consecuencias en tu trabajo (te cansas de hacer el canelo y se reduce tu productividad o directamente buscas otros horizontes profesionales) y/o en en ti mismo (aguantas tu nivel en el trabajo, a cambio de tener al angelito malo recordándote todos los días, ¿por qué narices te implicas si tu organización no lo hace contigo?).

Políticas generalistas van en contra de lo productividad y sin embargo son las más extendidas. Así nos va.

Por regla general, las empresas de desarrollo de software hacen uso de un determinado framework y de generadores de código, con el objetivo de estandarizar en cierta forma la construcción del sistema de información y solo incluyen variaciones sobre los mismos en proyectos concretos donde el cliente exige algún tipo de especificación distinta.

Si se quiere mejorar en productividad, el camino es ese (si bien, son necesarias muchas más variables para que la mejora de la productividad realmente sea efectiva).

Los generadores de código hacen repetible determinadas funcionalidades, como por ejemplo, la gestión de tablas maestras, la autenticación, etc… Por otro lado, aunque no se utilicen ese tipo de productos resulta aconsejable que salvo que se indique lo contrario por parte del cliente, se implementen determinadas funcionalidades de forma repetible entre un sistema de información y otro, así como dentro de un mismo sistema (no resulta lógico, salvo situaciones excepcionales, que la estrategia de diseño y construcción del mantenimiento de una tabla maestra sea distinta a la de otra).

Por este motivo, no resulta de utilidad invertir esfuerzo en el diseño de casos de uso, en repetir tanto el diagrama de casos de uso, como la descripción de los mismos, en elementos que van a tener un comportamiento similar, como por ejemplo, la gestión de tablas maestras. Eso dentro de un mismo proyecto, pero para proyectos donde se utilicen estrategias similares, bastará con tener dentro del proyecto base de la herramienta CASE la especificación de los casos de uso que pueden ser repetibles (y después realizar los ajustes que sean necesarios).

La clave de todo esto es racionalizar los esfuerzos de manera que se inviertan donde realmente merezca la pena.

En muchos casos resultará suficiente con dibujar el diagrama de casos de uso y realizar la descripción de los mismos a través de sus caminos principales y alternativos. Dado que, por regla general, este entregable no es común en los proyectos de desarrollo de software (pese a lo que aporta una vez que se llega a entender su utilidad), podemos estar más que satisfechos con tener este producto con dicho alcance.

Una especificación adicional a los mismos, es la especificación para cada caso de uso de una precondición y una postcondición. Es importante señalar que las mismas están a nivel de caso de uso y no a nivel de sus escenarios (camino principal y caminos alternativos).

Tanto la precondición como postcondición se especifican en lenguaje natural.

¿Qué es una precondición? Es el estado en el que se tiene que encontrar el sistema para que se pueda ejecutar el caso de uso. En muchos casos una precondición coincidirá con parte o con toda la postcondición de otro caso de uso.

¿Qué es un postcondición? Mientras queda claro que todo caso de uso tiene un único estado inicial, un caso de uso puede tener diferentes estados finales, potencialmente, tantos como caminos se definan en el mismo. Por tanto la postcondición de un caso de uso es un listado de todos los posibles estados finales en los que se encuentra el sistema tras la ejecución del caso de uso. Como la definición es en lenguaje natural, en muchos casos se opta por utilizar sentencias condicionales para especificar las condiciones que hacen que el estado final sea uno u otro.

¿Considero imprescindible la definición de precondiciones y postcondiciones? Desde mi punto de vista no lo es, aunque puede ser interesante su uso como elemento de depuración de los casos de uso (te hace pensar qué condiciones son necesarias para que el caso de uso se pueda llevar a cabo y cómo queda el sistema una vez que se haya realizado) y también para facilitar su comprensión.

Tendemos a evitar los obstáculos buscando el camino más sencillo para tratar de conseguir nuestro propósito. Supongo que cada cual tendrá su experiencia en esto, pero mi recomendación es que no te saltes a tu interlocutor salvo que no tengas otra posibilidad y además sea absolutamente necesario (hay veces que queremos conseguir algo que es prescindible o que existe otra alternativa que pueda resultar válida o satisfactoria).

Saltarse al interlocutor directo crea desconfianza no solo con esa persona, con quien probablemente además tengas que seguir trabajando en un futuro, sino con el resto de personas que estén al tanto de la situación ya que ellos pueden pensar que pueden ser los siguientes.

La confianza es para mi uno de los pilares en las relaciones laborales y profesionales, cuando se pierde, todo se complica y pasas a ser, en el mejor de los casos, simplemente uno más para esa persona que ha perdido la confianza en ti.