Hoy me preguntaron sobre cualidades del software y recordé lo que me habían enseñado en la facultad, como es un tema interesante, quiero escribir algo en el blog sobre ellas.
Las cualidades del software podrían definirse como las características propias e innatas del producto de software a construir. Idealmente, Las cualidades de un sistema deben estar por encima y por delante de la funcionalidad del sistema. Lamentablemente, la funcionalidad no sólo ocupa el primer lugar en las prioridades de los desarrolladores sino que muchas veces es el único.
Las cualidades podrían clasificarse como externas (visibles a los usuarios), internas (visibles solo a los desarrolladores), del producto, del proceso, observables y no observables en tiempo de ejecución.
Robustez: es un concepto difícil de definir, pero haremos nuestro intento: robustez = distancia al caos. Mientras menor es la distancia al caos, mayor solidez/robustez posee ese sistema. También puedo medir la robustez de un sistema en base a la tranquilidad al: 1) usar, 2) modificar una pieza de software.
Corrección: un sistema es correcto si hace lo que el cliente necesita. Dicho de otra forma, un sistema es correcto si su resuelve el problema real que causó su desarrollo. Adaptación total a una especificación no necesariamente implica corrección ya que dicha especificación puede no ser un fiel reflejo de la realidad del problema a resolver. Dicho de otra forma: pasa todo el tiempo que el cliente te pide y/o espera algo distinto de lo que necesita (de hecho lo que dice, lo que espera y lo que necesita pueden ser los tres súper distintos entre sí).
Eficiencia: tenemos dos dimensiones posibles para medir la eficiencia (tiempo/recursos) de un sistema: Recursos necesarios para la construcción (tiempo de desarrollador) o Recursos necesarios para la ejecución (tiempo de usuario + hardware). “Tiene mejor eficiencia el sistema que necesita menos recursos para realizar una tarea determinada”, por lo tanto deberíamos considerar ambas dimensiones a la hora de medir esta cualidad.
Claridad: Se refiere a la posibilidad de entender el funcionamiento de un sistema, subsistema o una porción de código cualquiera, su objetivo y la forma de solucionar el problema; en particular por gente que no es la que lo construyó. La claridad de un módulo afecta claramente a la posibilidades de modificarlo (flexibilidad).
Flexibilidad: es la capacidad que tiene un sistema para reflejar cambios percibidos en el dominio (sea por mejor comprensión del mismo o porque de verdad cambió) de una manera simple y sencilla. Conceptos relacionados son:
Extensibilidad: un sistema es extensible cuando pueden incorporarse nuevas características al mismo sin mayor impacto sobre las características actuales.
Mantenibilidad: un sistema o desarrollo es más mantenible cuanto menor esfuerzo requiere para que el sistema siga funcionando en condiciones distintas a las originales e incluso en las originales. Entre estas tareas podríamos enumerar:
Simplicidad: el sistema debe ser simple tanto en la interfaz como en la implementación. Es más importante la simplicidad en la interfaz que en la implementación.
Completitud: Un sistema es completo cuando contempla todas las posibles situaciones a darse en la práctica.
Encapsulamiento o Modularidad: poder agrupar unidades funcionales me permite que el sistema sea cohesivo, reduciendo la complejidad del sistema y aumentando en cierta forma su flexibilidad.
Escalabilidad: la facilidad con la que un sistema pensado originalmente para una carga determinada puede ser adaptado para soportar una carga mayor. Las aplicaciones Web nos dan una buena muestra de cuándo la escalabilidad puede ser importante para no afectar 1) la imagen del usuario que da vida a nuestro sistema, 2) la imagen corporativa del negocio que manejamos.
Abstracción: un sistema debería contener buenas abstracciones de la realidad. Recordemos que el sistema no es la realidad, sino un modelo. En base a nuestras abstracciones podemos definir:
Utilidad: no está de más recordar que el sistema debe ser útil al usuario.
Seguridad: Un sistema seguro debe impedir que agentes (personas u otros sistemas) no autorizados realicen acciones sobre el sistema.
Hagan click para ver la siguiente imagen mas grande con una subdivisión de estas y otras cualidades:
Fuentes:
Las cualidades del software podrían definirse como las características propias e innatas del producto de software a construir. Idealmente, Las cualidades de un sistema deben estar por encima y por delante de la funcionalidad del sistema. Lamentablemente, la funcionalidad no sólo ocupa el primer lugar en las prioridades de los desarrolladores sino que muchas veces es el único.
Las cualidades podrían clasificarse como externas (visibles a los usuarios), internas (visibles solo a los desarrolladores), del producto, del proceso, observables y no observables en tiempo de ejecución.
Robustez: es un concepto difícil de definir, pero haremos nuestro intento: robustez = distancia al caos. Mientras menor es la distancia al caos, mayor solidez/robustez posee ese sistema. También puedo medir la robustez de un sistema en base a la tranquilidad al: 1) usar, 2) modificar una pieza de software.
Corrección: un sistema es correcto si hace lo que el cliente necesita. Dicho de otra forma, un sistema es correcto si su resuelve el problema real que causó su desarrollo. Adaptación total a una especificación no necesariamente implica corrección ya que dicha especificación puede no ser un fiel reflejo de la realidad del problema a resolver. Dicho de otra forma: pasa todo el tiempo que el cliente te pide y/o espera algo distinto de lo que necesita (de hecho lo que dice, lo que espera y lo que necesita pueden ser los tres súper distintos entre sí).
Eficiencia: tenemos dos dimensiones posibles para medir la eficiencia (tiempo/recursos) de un sistema: Recursos necesarios para la construcción (tiempo de desarrollador) o Recursos necesarios para la ejecución (tiempo de usuario + hardware). “Tiene mejor eficiencia el sistema que necesita menos recursos para realizar una tarea determinada”, por lo tanto deberíamos considerar ambas dimensiones a la hora de medir esta cualidad.
Claridad: Se refiere a la posibilidad de entender el funcionamiento de un sistema, subsistema o una porción de código cualquiera, su objetivo y la forma de solucionar el problema; en particular por gente que no es la que lo construyó. La claridad de un módulo afecta claramente a la posibilidades de modificarlo (flexibilidad).
Flexibilidad: es la capacidad que tiene un sistema para reflejar cambios percibidos en el dominio (sea por mejor comprensión del mismo o porque de verdad cambió) de una manera simple y sencilla. Conceptos relacionados son:
Extensibilidad: un sistema es extensible cuando pueden incorporarse nuevas características al mismo sin mayor impacto sobre las características actuales.
Mantenibilidad: un sistema o desarrollo es más mantenible cuanto menor esfuerzo requiere para que el sistema siga funcionando en condiciones distintas a las originales e incluso en las originales. Entre estas tareas podríamos enumerar:
- Pequeños cambios de funcionalidad o parametrización (aquí se relaciona con la flexibilidad)
- Debugging
- Posibilidad de corregir las incongruencias producidas por los propios errores del software
- Posibilidad de hacer cualquier tipo de cambio sobre el sistema mientras este sigue funcionando.
Simplicidad: el sistema debe ser simple tanto en la interfaz como en la implementación. Es más importante la simplicidad en la interfaz que en la implementación.
Completitud: Un sistema es completo cuando contempla todas las posibles situaciones a darse en la práctica.
Encapsulamiento o Modularidad: poder agrupar unidades funcionales me permite que el sistema sea cohesivo, reduciendo la complejidad del sistema y aumentando en cierta forma su flexibilidad.
Escalabilidad: la facilidad con la que un sistema pensado originalmente para una carga determinada puede ser adaptado para soportar una carga mayor. Las aplicaciones Web nos dan una buena muestra de cuándo la escalabilidad puede ser importante para no afectar 1) la imagen del usuario que da vida a nuestro sistema, 2) la imagen corporativa del negocio que manejamos.
Abstracción: un sistema debería contener buenas abstracciones de la realidad. Recordemos que el sistema no es la realidad, sino un modelo. En base a nuestras abstracciones podemos definir:
- Reusabilidad: la posibilidad de utilizar un sistema construido anteriormente para resolver un problema nuevo.
- Genericidad: Un sistema o subsistema es genérico cuando se puede aplicar a un conjunto de situaciones similares.
Utilidad: no está de más recordar que el sistema debe ser útil al usuario.
Seguridad: Un sistema seguro debe impedir que agentes (personas u otros sistemas) no autorizados realicen acciones sobre el sistema.
Hagan click para ver la siguiente imagen mas grande con una subdivisión de estas y otras cualidades:
Fuentes:
No hay comentarios.:
Publicar un comentario