sábado, septiembre 23, 2006

Bases para el Desarrollo

Es muy frecuente que no se documenten correctamente los requerimientos y que estos sean acordados formalmente. Sucede porque no tenemos tiempo de documentar lo que el usuario quiere y brincamos directamente a diseñar o a programar con las consecuentes fallas. Al ser esta la primera etapa del proceso de desarrollo esta también es la primera oportunidad de incluir errores por lo que debemos de tomar las medidas necesarias para realizarla correctamente.

Para hacer bien esta tarea debemos de tener los elementos para ello, como las personas adecuadas para la obtención de los requerimientos, capacitadas en los métodos, el proceso y los artefactos a desarrollar. Debemos no solo de dejar documentados los requerimientos sino tratar de identificar todo aquello que esta entre líneas y que el usuario no nos transmite, que al considerarlos completos alguien los revise para ver si se pueden implementar, si están completos, claros y consistentes.

Con un conjunto de requerimientos documentados, completos y revisados, podemos establecer un compromiso con el cliente y con el equipo, lo que nos permite tener una base para el trabajo posterior. Aquí encontramos otro problema, no todos queremos asumir este compromiso. Si se nos olvida algo, ¿Cómo puedo cambiarlo?.

El obtener un compromiso sobre los requerimientos no significa que estos ya no se puedan cambiar, es imposible conocer con anticipación todo lo que pudiera hacer el nuevo producto o los cambios en el mercado. Lo que debemos hacer después de este compromiso es realizar los cambios de manera formal y controlada, es decir, cada requerimiento de cambio deberá ser analizado en su impacto en el proyecto y como estos pueden ser incorporados sin que el proyecto salga de control.

Con un buen proceso de obtención de requerimientos y una buena administración de los mismos podemos establecer las bases hacia una planificación, estimación y desarrollo del producto más estable y con mayores probabilidades de éxito.

sábado, septiembre 16, 2006

Sitios

Algunos buenos sitios sobre mejora de procesos y temas de ingeniería de software son www.davidfrico.com, www.processimpact.com, o el mismo sitio del SEI http://www.sei.cmu.edu

sábado, septiembre 09, 2006

¿Funciona la mejora?

Existen múltiples artículos, investigaciones y evidencia sobre el retorno de inversión resultado de un proceso de mejora, sin embargo no hay nada mejor que verlo en nuestra propia empresa para decirlo.

Tanto se habla de los resultados que es común que la dirección se apresure a verlos cuando todavía no existe información suficiente. Para poder ver resultados necesariamente tenemos que tener mediciones, así sean básicas, pero hay que tenerlas para poder ver el avance. ¿Qué tanto retrabajo hacemos?, ¿Qué errores cometemos?, ¿Cuánto se desvían nuestros proyectos?, ¿Qué tantos errores recibimos una vez entregado al cliente el producto?.

A través de la ejecución de algunos proyectos con las mejoras implementadas y con la obtención de mediciones, tendremos la información necesaria para analizar y ver que cómo nos están ayudando las nuevas prácticas. Algo importante, es que debemos de implementar las prácticas tal y como las diseñamos para ver los resultados esperados, no hay otra forma.

viernes, junio 23, 2006

¿CMMI, Moprosoft, ISO?

Esta es una pregunta que se hacen organizaciones sobre que modelo deben se seguir, pero lo primero que debemos de preguntarnos no es sobre los modelos, sino para que los queremos.

Si estamos buscando seguir un modelo para obtener alguna acreditación, diploma o reconocimiento las probabilidades de fracaso son muy altas, más que nada por que un proyecto de mejora implica un cambio en la forma de hacer las cosas. Si queremos obtener el diploma sin cambiar la forma de hacer las cosas, simplemente no hay forma.

Así que primero debemos de preguntarnos porque queremos cambiar, ¿Qué nos duele?, ¿Qué nos hace falta?, ¿Qué queremos mejorar?, ¿Qué esperamos ser en un futuro?. Si no podemos resolver esto, si no sabemos porqué queremos cambiar, ¿Cómo vamos a soportar el cambio?

sábado, mayo 20, 2006

CM - Administración de la configuración

Este tema es quizá uno de los más importantes que nadie le toma importancia hasta que empieza a relacionar algunos de los errores que suceden durante el desarrollo.

¿Alguna vez se ha topado con alguna de las siguientes situaciones?

• El producto no fue entregado completo.
• Probó un módulo equivocado.
• Estimó en una especificación que no era la última.
• Un cambio que había hecho ya no está.
• El proyecto ha tenido tantos cambios que ya no sabe cual fue el pedido original.

Estos son problemas que serían solucionados fácilmente con una buena administración de la configuración, algunos de ellos muy simples.

La administración de la configuración nos ayuda a mantener la integridad de los productos de software a través de todo el ciclo de desarrollo, esto significa que la administración de la configuración nos permite a mantener a todos nuestros productos (sistema, fuentes, documentación, manuales) consistentes con la información que contienen. Si existe un cambio este cambio se verá reflejado en todos y cada uno de los documentos afectados.

jueves, mayo 18, 2006

Revisión de los estimados

Un hecho es que no conocemos todo al inicio del proyecto. Se hace un estimado en la propuesta el cual tiene cierta probabilidad de cumplirse y dependerá de muchas condiciones, entre ellas, que tanto conocemos a nuestra organización y como hacemos uso de la historia.

Una realidad es que el estimado no debería de quedar allí, a medida que avanza el proyecto contamos con más información y por lo tanto nuestro estimado puede ser mejorado o en el peor de los casos verificar el anterior que teníamos.

Algunos puntos en donde podríamos verificar nuestro estimado serían al terminar los requerimientos y al terminar los requerimientos. Si hacemos antes un estudio de factibilidad podemos incluir un estimado en dicha actividad. Lo importante es identificar en forma anticipada los estimados que vamos a realizar en el proyecto y así como la metodología a utilizar.

Las métricas alrededor de los estimados son muy útiles para ir aprendiendo de ellos y saber cuál es nuestra desviación contra los valores reales comparando contra la propuesta, contra la estimación de requerimientos y contra la estimación de diseño, así como las desviaciones entre las diferentes técnicas utilizadas.

domingo, mayo 14, 2006

¿40 hrs = 1 Semana?

¿Porque no alcanza el tiempo para terminar el programa a tiempo?, es común ver equipos que se comprometen a entregas que difícilmente van a cumplir creyendo que si lo van a hacer y además bastante convencidos. Al final resulta que no se termina a tiempo o se hizo pero a raíz de trabajar el fin de semana o quedarse más tiempo. ¿Porque no alcanza el tiempo?, simplemente porque hacemos otras actividades durante el día.

Es prácticamente imposible entregar 8 horas efectivas al proyecto durante un día y si lo hiciéramos no lo pudiéramos repetir el resto de la semana y no digamos del mes. Esto es simplemente porque realizamos otras actividades durante el día entre las que están reuniones, tomamos café, recibimos una llamada, contestamos el correo, resolvemos una duda, tantas y tantas cosas que pueden surgir en un día que hace que no tengamos toda la atención en el proyecto.

Algo aceptable a considerar que pudiéramos dedicar al proyecto sin comprometer al mismo serían 120 horas de 160 horas de un mes considerando 4 semanas. Esto da que tenemos que dar al proyecto 30 horas a la semana, es decir 6 horas la día. Quiere decir que debemos de dedicarnos el 75% del tiempo al proyecto. ¿Poco?, ¿Cuánto dedicamos en nuestra organización hacia los proyectos?, hacia actividades que son productivas, es decir, que generan dinero.

Cuando hagamos un compromiso no tomemos 40 horas de esfuerzo igual a una semana de trabajo. Es importante distinguir primeramente entre el esfuerzo y el calendario, entre el esfuerzo que podemos generar y el que podemos entregar. Conociendo esto números seguramente estaremos cumpliendo mejor con nuestros compromisos.

miércoles, mayo 10, 2006

¿Cómo vender los estimados?

Siempre que nos llega una solicitud de un nuevo sistema o requerimiento generamos un estimado del esfuerzo, tiempo y costo que nos va a tomar solucionar dicha necesidad. Este estimado, el cual es nuestra mejor aproximación a la realidad, es parte de nuestra propuesta o control de cambios que presentado al cliente. ¿Cómo manejamos esto?

El problema inicial surge en como presentamos este estimado, y no tiene nada que ver con el estimado en sí mismo. Típicamente se presenta el estimado como tal, entendiendo que quedará claro al usuario con la explicación que podamos hacer al presentarlo. Se incluyen como valores estimados las horas, tiempo y costo, lo que generalmente se toma como el deber ser, no importa que tanto conversemos con el usuario al respecto.

Para trasmitir mejor el mensaje podemos poner indicar que lo mostrado es un estimado y tiene un porcentaje de desviación o certeza (p.ej. +/- 20%) de lo que se esta indicando. Sería mejor si se incluye el porcentaje de certeza y los rangos de los estimados en estos porcentajes de certeza. Siempre indicando que de surgir algún cambio en estos estimados serían comunicados al cliente para tomar acciones correctivas o un plan de acción.

Parte del trabajo es también vender estos estimados para que quede claro y acordado entre el equipo y el cliente que se esta trabajando sobre un estimado y que este puede bajar o subir dependiendo de cómo se va ejecutando el proyecto y los ajustes que se van presentando y que su presupuesto se base en estos estimados.

Es posible que no nos funcione a la primera pero hay que trabajar con los clientes en función de esto y nunca dar estimados al aire por que esto nos tira por los suelos todo nuestro trabajo ganado.

domingo, febrero 19, 2006

¿Qué hacemos con los tecnólogos?

El desarrollo de la tecnología en los últimos años ha tenido un crecimiento impresionante lo que ha hecho que prácticamente hagamos uso de ella en todas nuestras actividades diarias, desde lo más sencillo como puede ser para atender un semáforo, un cajero automático, una caja registradora en el supermercado hasta los sofisticados sistemas médicos, bancarios o de control aéreo.

El que la tecnología este presente en muchas actividades nos ha llevado en algunos casos a enfrentarnos a ella, o bien para utilizarla o para implementarla. Esto nos lleva a que nos demos cuenta de que no siempre la utilicemos u obtengamos el provecho necesario para realizar nuestras tareas o para facilitarlas. Es común ver, por ejemplo, filas de gente para pagar servicios pudiendo pagar estos por Internet, o bien siendo atendido por un empleado de mostrador el cual no nos puede encontrar en el Sistema.

El desconocer la tecnología de los sistemas de información nos lleva también a no saber como estos nos pueden ayudar, que podemos obtener de ellos y como nos pueden facilitar nuestras actividades. El problema se agrava al tener que nosotros solicitar o desarrollar un sistema de información que soluciones nuestros problemas en el que este desconocimiento nos lleva a no saber que pedir, como hacerlo o que esperar. Gran parte de esta incertidumbre se genera porque lo que manejamos es un intangible, no como hacer un mueble o una casa en los que podemos sentir y ver lo que se esta construyendo.

El propósito aquí es ver todo lo que involucra el desarrollar un sistema de información, cuál es su proceso, cómo podemos asegurarnos que nos va a ser de utilidad, como interactuar con las personas que nos van a ayudar a lograr la solución y ver que estamos en el camino correcto a lograrlo. Estaremos tocando diferentes temas para ir entendiendo los diferentes términos, métodos y herramientas que es utilizada por los tecnólogos para desarrollar los sistemas y de esta manera poder lograr un mejor entendimiento con ellos logrando mejores resultados.