EEPICA's BLOG eepica@nirvana:~# ps aux blog | grep eepica

Ingeniería de Software? Requerimientos? Y éso con que se come?!!

in Security in Technology

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 por lo cual intento reducir al máximo en mis proyectos los fallos 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!

Creative Commons License
.

Comments (2)

  • perezgump:

    29 Nov 2009 23:15:50

    Bueno me parecio una explicacion conlcuyente sobre requerimientos, solo que donde mencionas como en tu opinion deberian ser los requerimientos, no podriamos generaliar, ya que los que plantea el cliente no llegarian a ser tan tecnicos como para definir sus datos de entrada, si te describen la pantalla, lo que esperan es un avanze que el ingeniero de requerimientos debe decifrar para complementar sus demas listas de requerimientos.SaludosPD. que tal va la materia.

  • epica:

    01 Dec 2009 00:16:15

    @perezgump Hola! debes tener en cuenta que los requerimientos como tal son especificados formalmente por las personas encargadas de desarrollar el proyecto, interpretando las necesidades del cliente. Es decir, ellos describen una pantalla que pide usuario y contraseña, el ingeniero o persona encargada de requerimientos dice, interpretará que se requiere atenticación para el sistema ;)Saludos y gracias por tu comentario!

Leave a comment