epica's_blog.sh

Nota introductoria: A continuación os comentare un poco acerca de una de mis tantas experiencias en la empresa donde trabajo y después de un pequeño resumen con respecto a una de las sorpresas que más me ha trasnochado últimamente intentaré dejar un poco de "huella" sobre cómo evitar este tipo de situaciones.

La Sorpresa

Hace aproximadamente 21 días he vendido estoy trabajando en un "mini proyecto" que consta de la instalación de dos software (POS y Contabilidad) para una empresa X, esta empresa tiene una particularidad y es que tiene sus correspondientes seccionales en varias partes de Bucaramanga, por lo cual el POS debe ser instalado en cada una de las correspondientes seccionales, además se solicito también la creación de una red y los correspondientes servidores para las necesidades de esta empresa.

El detalle más importante a partir del cual se genera mi desvelo en este momento se basa en el POS (el resto supongo me desvelará después) del cual una persona Y (para no repetir la X) tomo la lista de requerimientos, la pasó al grupo de diseñadores y desarrolladores; el requerimiento era más o menos así:

Pero el día sábado (un día antes de la entrega) descubrimos que el verdadero requerimiento para la factura era:

Además:

Pero:

Supongo en este momento no es necesario describir la gran frustración y el mal genio que nos invadió a mi Jefe y a mí que somos los que "ponemos la cara" al descrubrir este requerimiento a tan pocas horas de la primera entrega.

Después de descubrir las sorpresas podría decirse no he dormido mucho y además tengo más trabajo del que debería tener, cabe resaltar que incumplimos con la primera entrega completa, por ende también tendremos que aplazar la capacitación a los empleados (8 días) por la necesidad de la realización de pruebas, lo único bueno es que de todas formas nos sobra tiempo de acuerdo a lo establecido en el contrato... pero obviamente quedamos mal en "palabra".

Dejando Huella (La solución para evitar sorpresas)

Ing. de Software y Requerimientos

Bueno superando la sorpresa... empecemos a tocar temas importantes a nivel de diseño de Software a la medida para empresas (para todo!).

Ingeniería de Software: En términos generales consta de métodos y técnicas para el desarrollo de software (antes, durante y después de este).

Algunas definiciones de este concepto dicen lo siguiente:

* Ingeniería de Software es el estudio de los principios y metodologías para el desarrollo y mantenimiento de sistemas software (Zelkovitz, 1978)
* Ingeniería de software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación asociada requerida para desarrollar, operar y mantenerlos. Se conoce también como Desarrollo de Software o Producción de Software ( Bohem, 1976).
* Ingeniería de Software trata del establecimiento de los principios y métodos de la ingeniería a fin de obtener software de modo rentable, que sea fiable y trabaje en máquinas reales (Bauer, 1972).
* Es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del software; es decir, la aplicación de la ingeniería al software (IEEE, 1993).

Personalmente gracias a mi profesor de Ingeniería de Software (quien nos torturo con manuales, requerimientos, pruebas, etc.) creo que le doy la suficiente importancia a este tema y bueno esta es la primera vez que soy "victima" de un fallo por saltarse la toma "minuciosa" de requerimientos y pensar únicamente en programar.

Requerimientos: Cuando se ve la necesidad de la implementación de software en cualquier sitio lo más importante es saber, el por qué?, el cómo?, cuando? y demás del software a implementar, esto se consigue a través de la correcta toma de requerimientos puesto que estos contienen todas las necesidades a las cuales se les debe dar solución.

Los requerimientos como tal deben estar muy bien documentados (en mi caso me gusta adjuntar ejemplos) y además consultados una y otra vez, realizando continúo un acompañamiento a quien está entregando dichos requerimientos (por si al caso olvida algo).

En general los requerimientos (a mi modo de ver) deberían estar compuestos de:

* El requerimiento que expresa el cliente
* La funcionalidad en el producto o servicio
* Los datos de entrada
* Los datos de salida esperados
* La información sobre la actual solución a estos (si la hay)
* Ejemplos

Debemos recordar que dentro de estos requerimientos se pretende establecer "que debe hacer el sistema" de acuerdo a las necesidades, pero no "como hacerlo" (esto será después por diseñadores y desarrolladores).

Tipos de requerimientos:

Algo a destacar es que:

* Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo de requerimiento especifica algo que el sistema entregado debe ser capaz de realizar.
* Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitables son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
* Otros tipos de limitaciones externas, que afectan en una forma indirecta al producto. Estas pueden ir desde la compatibilidad con cierto sistema operativo hasta la adecuación a leyes o regulaciones aplicables al producto

Características de los requerimientos:

Otro detalle importante en el momento de recolección o toma de requerimientos, las características y tipo de estos, es que: una es la forma en la cual ve el requerimiento (necesidad) el cliente, otra forma es como la ve quien está recolectando los requerimientos y finalmente una muy bien organizada y estructurada la que se entrega al equipo de diseñadores y desarrolladores. en ningún caso la "necesidad" entregada por el cliente puede diferir del requerimiento interpretado por los diseñadores de soluciones.

Los requerimientos bien formulados deben satisfacer varias características. Si no lo hacen, deben ser reformulados hasta hacerlo.

* Necesario: Lo que pida un requerimiento debe ser necesario para el producto.
* No ambiguo: El texto debe ser claro, preciso y tener una única interpretación posible.
* Conciso: Debe redactarse en un lenguaje comprensible por los inversores en lugar de uno de tipo técnico y especializado, aunque aún así debe referenciar los aspectos importantes
* Consistente: Ningún requerimiento debe entrar en conflicto con otro requerimiento diferente, ni con parte de otro. Asimismo, el lenguaje empleado entre los distintos requerimientos debe ser consistente también.
* Completo: Los requerimientos deben contener en sí mismos toda la información necesaria, y no remitir a otras fuentes externas que los expliquen con más detalle.
* Alcanzable: Un requerimiento debe ser un objetivo realista, posible de ser alcanzado con el dinero, el tiempo y los recursos disponibles.
* Verificable: Se debe poder verificar con absoluta certeza, si el requerimiento fue satisfecho o no. Esta verificación puede lograrse mediante inspección, análisis, demostración o testeo.

Por último (que hasta ahora no se ha hecho del todo en la empresa X) es la realización de las correspondientes pruebas y algo curioso es que una prueba es exitosa si se encuentran errores ;)

Opinión Final:

Los errores a nivel de diseño de software no son necesariamente culpa del cliente, puesto que este siempre dice: "necesito un programa que haga..." el verdadero error está en la toma de requerimientos, es a destacar que estos requerimientos no deben dejarse únicamente para el inicio, como he mencionado anteriormente lo importante es que tanto la ingeniería de software como la de requerimientos debe estar en todo momento, es decir antes de empezar la fase de desarrollo (obvio es la más importante), durante el desarrollo del Software y finalmente después de una entrega que contenga una prueba exitosa (esto va ligado al tipo de garantía y soporte que se le haya entregado al cliente).

Finalmente no queda más que decir que después de un error lo único que queda es corregirlo y "dejar huella" con respecto a lo que no se debe hacer a modo de "aprender la lección" y bueno esta semana el trabajo será duro... pero por lo menos los errores fueron encontrados a tiempo (o nos encontraron a tiempo).

Saludos y felices desarrollos!

.