¿Existen estándares para clasificar los NFR?, ¿Se pueden construir modelos formales para estimar los NFR?
Las anteriores son interrogantes que están presentes siempre en cualquier proyecto de desarrollo de software ya que necesariamente un proyecto de desarrollo tiene requisitos funcionales de usuario (FUR) y requisitos no funcionales (NFR); la proporción varía dependiendo del tipo de proyecto; sin embargo, lo que es claro al inicio del proyecto, es que necesitamos estimar un proyecto de desarrollo de software de manera integral, considerando ambos tipos de requisitos.
Primero expondremos como se definen formalmente los FUR y los NFR:
Los requisitos funcionales del usuario (FUR) pueden definirse como “lo que debe hacer el software” y afectan claramente al tamaño del software, lo que a su vez afecta el esfuerzo y/o costo del proyecto. Estos se pueden medir con estándares de medición de tamaño funcional como COSMIC.
Los requisitos no funcionales (NFR) que a veces se definen como “¿cómo debe hacerlo el software?”, no está claro de inmediato si el NFR afecta o no al tamaño del software; lo que es cierto inminentemente es que afectan el esfuerzo y/o costo del proyecto.
Normalmente para la parte de los FUR tenemos más claro como estimarlos a partir de su dimensionamiento del tamaño funcional usando COSMIC y posteriormente ingresando este tamaño a un modelo de estimación que nos permita estimar esfuerzo y/o costo (consultar la entrada de blog titulada “Modelos de estimación de esfuerzo usando el tamaño funcional COSMIC”).
Sin embargo, para el tema de los NFR, sabemos que no se pueden medir con COSMIC porque son requisitos que no tienen funcionalidad; sin embargo, sabemos que impactan el esfuerzo y/o costo de cualquier proyecto de desarrollo de software. Ejemplos de este tipo de NFR son: el uso de un lenguaje de programación en particular por políticas del cliente, la necesidad de un tiempo de respuesta específico por parte del sistema, cierta calidad del software desarrollado, requisitos técnicos como la arquitectura, etc.
Es importante entender sobre un requisito que se establece inicialmente como un requisito No funcional (NFR) que “puede” evolucionar “total” o “parcialmente” a medida que un proyecto avanza hacia ser un FUR para software, el tamaño de esta funcionalidad “adicional” puede potencialmente medirse utilizando el método COSMIC en de la misma manera que cualquier otro requisito que siempre fue un requisito funcional para el software desde que se estableció por primera vez. Un ejemplo de este requisito que inicialmente podría ser NFR, sería el cumplir con cifrado en algunos datos antes de guardar en la base de datos, a medida que evoluciona el proyecto puede derivar en la necesidad de un algoritmo de encriptación específico lo cual lo transforma en un FUR.
Pero qué pasa con aquellos requisitos que si se mantienen como NFR; ante la necesidad de estimar estos NFR, normalmente las fábricas de software o los clientes que solicitan desarrollos se ven forzados a recurrir al juicio de experto ya sea para estimar o para validad una estimación de esfuerzo y/o costo referente a los NFR; sin embargo, esta forma de hacerlo trae todas las desventajas de imprecisión e inexactitud inherentes a dicha técnica.
En consecuencia, surge la pregunta si es posible estimar el esfuerzo y/o costo de los NFR de manera formal usando modelos matemáticos consistentes; la respuesta es afirmativa ya que por un lado se dispone de estándares que hacen una adecuada clasificación de los NFR como por ejemplo el “ISO/IEC 25010:2011 System/Software Product Quality model” [1], que agrupa en 9 categorías la forma en que se compone la calidad del producto de software. Para temas relacionados con requisitos del entorno del sistema, requisitos técnicos se pueden considerar los cuestionarios de ISBSG [2].
Existen otros estándares y manuales como: IEEE Std 830-1998: Software Requirements Specifications; IFPUG Software Non-functional Assessment Process (SNAP) Asse Release 2.2ssment Practices Manual; COSMIC Guideline on Non-Functional & Project Requirements. Version 1.0; European standard ECSS-E-ST-40C – Software general requirements, etc.
Los estándares y manuales citados anteriormente nos permiten disponer de un listado y una clasificación bastante bien definido de NFR que son comunes en los desarrollos de software; sin embargo, no son ni métodos ni modelos para estimar NFR. En particular SNAP está en proceso de ser aceptado como estándar ISO, sin embargo, está completamente mal, y presenta serios problemas en su fundamentación.
Sin embargo, existe un modelo denominado EPCU [3], que nos permite usando el formalismo de la lógica difusa, construir modelos de estimación a partir de la definición de un contexto que defina las variables consideradas para la estimación (entradas) y la variable de salida (variable estimada); de forma tal que se pueden construir modelos para evaluar y estimar de manera formal los NFR utilizando los estándares existentes como referencia.
Hoy en día los NFR NO se pueden medir (no existe una unidad de medida para ellos), pero se pueden evaluar, una manera de evaluarlos con un modelo que sea matemáticamente válido es aplicando EPCU, lo que permite generar una misma regla para evaluar y comparar resultados bajo circunstancias iguales.
La plataforma tecnológica MENSURA® desarrollada por SPINGERE; permite la habilitación de cualquier modelo EPCU (contexto) para poder estimar cualquier tipo de NFR; para más información consultar https://mensura.com.mx/.
[1] ISO/IEC 25010:2011, Systems and software engineering – Systems and software Quality Requirements and Evaluation (SquaRE) – System and software quality models.
[2] International Software Benchmarking Standards Group, ‘Data Collection Questionnaire’ 3.08, 2012.
[3] Design of A Fuzzy Logic Estimation Process for Software Projects: Estimation of Projects in a Context of Uncertainty EPCU Model by Francisco Valdés Souto (Aug 23, 2012), ISBN: 978-3-659-19774-1, Lap Lambert Pub.
Jorge Valeriano Assem y Francisco Valdés Souto.