Métodos de medición del tamaño funcional

Esta es la segunda parte del blog que se enfoca en varios métodos populares de medición del tamaño del software y su utilidad para la estimación de proyectos de software.. En esta segunda parte los métodos de medición de tamaño funcional IFPUG, NESMA y COSMIC están cubiertos. En blogs futuros, cubriré métodos de medición de tamaño no funcionales y métodos híbridos..

Se recomienda encarecidamente a los lectores interesados ​​en este tema que lean primero el primera parte de este blog, antes de leer esta segunda parte.

Para que un método de medición de tamaño de software en particular sea útil para la estimación de proyectos de software, las siguientes características deben aplicarse:

  • El método de medición del tamaño se puede llevar a cabo de forma objetiva. (independiente de la persona que lo hace), repetible, comprobable y por lo tanto defendible forma;
  • El tamaño en sí solo es útil cuando información histórica está disponible de proyectos medidos en ese método de medición de tamaño;
  • Los métodos de medición del tamaño deben estar respaldados por modelos y/o herramientas paramétricas para tener en cuenta con precisión las características específicas del proyecto que influyen en la estimación, como por ejemplo COCOMO II, DELGADO, SEER para software o Trueplanning.

Por supuesto, cualquier método de medición del tamaño del software que no cumpla con uno o más de estos criterios aún puede ser muy útil para una organización, siempre que elaboren un procedimiento para garantizar mediciones de tamaño repetibles, recopilar y analizar datos históricos y/o construir sus propios modelos de estimación basados ​​en los datos recopilados. Sin embargo, para este blog, la atención se centra en la utilidad teórica del método de medición específico para fines de estimación de proyectos de software en el contexto de organizaciones que aún no cuentan con un proceso de estimación paramétrica. Para estas organizaciones, que estén dispuestos a implementar un método de medición de tamaño para estimar proyectos de software, este blog puede servir como guía para seleccionar un método específico.

Aunque todo lo escrito en este blog se basa en la experiencia personal y en la documentación disponible públicamente, deseo recalcar que este blog solo refleja mis puntos de vista y creencias personales y por lo tanto no estoy afirmando que todo lo escrito en este blog sea una verdad absoluta. Mis creencias personales no son necesariamente las creencias de las organizaciones a las que estoy afiliado: Metros, Nesma y ISBSG.

Harold Heeringen

Animo a todos a enviar comentarios y/o comentarios sobre este blog..

Nesma FPA

Nesma FPA es muy similar a IFPUG ya que mide los mismos componentes funcionales básicos (BFC [24]) (ILF, FEI, NO, EO, EQ) y ahora hay muy pocas diferencias entre las pautas de conteo de los dos métodos. Muchos expertos usan el tamaño medido en puntos de función IFPUG como igual al tamaño en Nesma FP. Las principales ventajas de Nesma sobre IFPUG a efectos de estimación es la disponibilidad de una serie de métodos derivados que se consideran parte del estándar ISO/IEC.:

  • FPA indicativo: este método se puede usar muy temprano en el ciclo de vida del proyecto cuando solo se especifica el modelo de datos. La precisión no es muy alta. (-30% / +50%), pero generalmente suficiente para ser útil en una etapa temprana del ciclo de vida del proyecto cuando solo se necesita una estimación de ROM.
  • FPA de alto nivel (a.k.a. FPA estimado) – Este método se considera el método principal en la actualidad., ya que la mayoría de la documentación funcional carece del detalle para poder usar el Nesma estándar (o IFPUG) FPA. El FPA de alto nivel utiliza una evaluación de complejidad fija por componente funcional base: baja complejidad para archivos lógicos y complejidad media para funciones. Este método se puede utilizar cuando se conocen el modelo de datos y las funciones., pero los detalles de qué atributos se utilizan en qué funciones faltan o están incompletos (que es a menudo el caso). La precisión de este método es de alrededor -8% a +15% (ver este papel).

Adicionalmente, Nesma distingue entre tamaño del proyecto (el número de puntos de función agregados a un sistema existente, más el número de puntos de función modificados en el sistema, más el número de puntos de función eliminados, más puntos de función de software necesarios para realizar para completar el proyecto, por ejemplo software de conversión) y tamaño del producto (el tamaño funcional de la aplicación que se entrega a los usuarios).

Nesma es una comunidad muy activa de voluntarios que trabajan constantemente en nuevas formas de utilizar el método en nuevos tipos o tipos especiales de proyectos de software.. Aunque estos no son oficialmente parte del estándar ISO/IEC, estos métodos pueden ser muy útiles para fines de estimación de software. Las pautas ampliamente utilizadas son, por ejemplo,:

los Bases de Estimación (BoE) para servicios de software según lo publicado por Nesma y el AACE Internacional, la autoridad para la gestión de costes totales, es una forma muy útil de establecer la línea de base de cualquier estimación de proyecto de software, al mismo tiempo que prueba que el estimador ha tenido en cuenta todos los aspectos que son importantes en su estimación. el nesma (IFPUG) El método es compatible con la mayoría de los modelos y herramientas de estimación de software paramétrico comercial y no comercial..

Las características para evaluar la utilidad de este método para la estimación de proyectos de software se enumeran en la siguiente tabla:

Característica Y/N Observaciones
Objetivo, repetible, verificable y defendible si ISO / IEC 24570:2004
Datos históricos disponibles si ISBSG R13: 187 proyectos (5433 cuando se combina con IFPUG)
Compatible con modelos/herramientas si QSM, VIDENTE-SEM, Trueplanning, COCOMO II, ISBSG

 

IFPUG

El método IFPUG es el método más utilizado para la medición del tamaño funcional. De todos los requisitos, Mide solo los requisitos funcionales del usuario y lo hace de la misma manera que los archivos lógicos internos (ILF), archivos de interfaz externa (FEI), funciones de entrada externa (NO), funciones de salida externa (EO) y consulta externa (EQ) las funciones se identifican y clasifican en complejidad. La complejidad del software se clasifica de la siguiente manera: Bajo, Medio o Alto, dependiendo de elementos como la cantidad de atributos de datos involucrados, la cantidad de archivos a los que se hace referencia o la cantidad de tipos de registros que forman parte del archivo lógico. Para un archivo lógico interno (ILF) por ejemplo, el número de puntos de función conectados a un ILF de baja complejidad es 7 puntos de función (FP), se obtiene un ILF de mediana complejidad 10 FP y se obtiene un ILF de alta complejidad 15 FP. Hay un número mínimo de puntos por función y un número máximo de puntos por función. Aunque esto simplifica un poco el proceso de análisis, se percibe como un inconveniente que puede que no haya suficientes matices entre el tamaño de los diferentes archivos lógicos y funciones. Por ejemplo, el tamaño de una función de entrada externa compleja es 6 FP, pero el tamaño de una IE muy compleja es 6 puntos también y el tamaño de un EI extremadamente complejo también es 6 FP.

El método IFPUG es más útil como método de dimensionamiento para estimar proyectos que cumplan con las siguientes características (no limitado):

  • El software está orientado a datos., muchos CRUD (Crear, Leer, Actualizar, Borrar) se especifican las funciones
  • El software está orientado a la administración.
  • Está disponible un diseño funcional detallado en el que el modelo de datos es completo y claro y para todas las funciones está claro qué atributos de datos se utilizan

Cuando se mide el tamaño de los requisitos funcionales, hay numerosas formas de convertirlo en una estimación. El uso de datos históricos de la organización que va a realizar el software suele ser la mejor manera de hacerlo., preferiblemente apoyado por herramientas de estimación profesionales. Si los datos históricos no están disponibles, la base de datos abierta del International Software Benchmarking Standards Group puede resultar muy útil. Contiene más 6700 proyectos (Lanzamiento 13) y muchos de estos fueron medidos en IFPUG. El método IFPUG es compatible con la mayoría de los modelos y herramientas de estimación de software paramétrico comerciales y no comerciales..

Las características para evaluar la utilidad de este método para la estimación de proyectos de software se enumeran en la siguiente tabla:

Característica Y/N Observaciones
Objetivo, repetible, verificable y defendible si ISO / IEC 20926:2009
Datos históricos disponibles si ISBSG R13: 5244 proyectos
Compatible con modelos/herramientas si QSM, VIDENTE-SEM, Trueplanning, COCOMO II, ISBSG

 

CÓSMICO

El Consorcio Internacional de Medición de Software Común (CÓSMICO) es un voluntario, grupo mundial de expertos en métricas de software. Inició en 1998, COSMIC ha desarrollado un método para medir el tamaño funcional del software que fue diseñado para superar algunas de las fallas percibidas de Nesma e IFPUG FPA. Mientras que Nesma e IFPUG se utilizan principalmente para medir el tamaño del software administrativo, COSMIC también es aplicable para medir el tamaño del software de infraestructura y en tiempo real. El método es completamente 'abierto'; toda la documentación del método está disponible en el dominio público para su descarga gratuita.

Una de las principales ventajas del método COSMIC es el hecho de que permite al especialista en medición dividir el software en capas de software y componentes pares., que permite la posibilidad de medir el tamaño funcional del software que reside en capas de arquitectura separadas o en diferentes componentes que se comunican entre sí. Esto supera uno de los inconvenientes percibidos de los métodos Nesma e IFPUG., que no permiten dividir el software de tal manera.

Otra ventaja importante es el hecho de que el método sigue una escala de razón. Por lo tanto, el tamaño funcional por proceso funcional puede ser cualquier tamaño entre 2 Puntos de función COSMIC (el valor mínimo por proceso funcional) y (teóricamente) infinidad.

Usualmente el método COSMIC es muy bien aplicable para usar en proyectos desarrollados con una metodología ágil. El tipo de documentación que suelen entregar este tipo de proyectos (por ejemplo. historias de usuarios, casos de uso, diagramas de actividad, diagramas de secuencia, diagramas de clases) suelen ser fáciles de medir con COSMIC de forma muy precisa.

Aunque el uso de COSMIC está aumentando y también está aumentando el número de profesionales certificados, todavía no hay muchos datos abiertos de evaluación comparativa disponibles. El lanzamiento del repositorio de nuevos desarrollos y mejoras de ISBSG 13 (lanzado en febrero 2014) contiene sobre 500 proyectos medidos en COSMIC, mientras que el número de proyectos medidos en puntos de función IFPUG está muy por encima 5000 proyectos.

El método COSMIC suele ser especialmente aplicable cuando se utiliza el tamaño funcional para estimar los siguientes tipos de proyectos:

  • Proyectos de software en tiempo real;
  • Proyectos de software de aplicaciones móviles;
  • Proyectos de software de infraestructura;
  • Proyectos de software que entregan software en una arquitectura en capas;
  • Proyectos de software administrativo.

La documentación funcional debe mostrar al menos los procesos funcionales que implementa el software y los movimientos de datos entre los usuarios y el software..

Las características para evaluar la utilidad de este método para la estimación de proyectos de software se enumeran en la siguiente tabla:

Característica Y/N Observaciones
Objetivo, repetible, verificable y defendible si ISO / IEC 19761:2003
Datos históricos disponibles si ISBSG R13: 488
Compatible con modelos/herramientas si QSM, VIDENTE-SEM, Trueplanning, ISBSG

Hay dos estándares ISO/IEC más para la medición del tamaño funcional, FiSMA y Mark II, pero como estos métodos solo se usan en comunidades locales específicas, no se discuten en este documento.

Todos los métodos para la medición del tamaño funcional son muy adecuados para la estimación de proyectos de software.. Sin embargo, el tamaño del software es solo una parte de la estimación.. El tamaño debe convertirse en una estimación mediante el uso de datos históricos relevantes de productividad.. Cuando se conoce el tamaño funcional en puntos de función, debe multiplicarse por el número más probable de horas por punto de función que probablemente se necesiten en el proyecto. Aunque hay varias herramientas paramétricas profesionales disponibles, y también se pueden adquirir fácilmente bases de datos con datos históricos, muchas organizaciones sienten que es complicado y requiere mucho tiempo usar la medición del tamaño funcional y les resulta difícil determinar una tasa de productividad precisa para los proyectos que necesitan estimar. Prefieren métodos que consumen menos tiempo o métodos que son más fáciles de aplicar.. Desafortunadamente, esto también significa que estos métodos pueden no ser tan precisos.

Próximo blog

En el próximo blog sobre este tema., Daré mi opinión sobre la utilidad de los principales métodos de medición de tamaño no funcional para la estimación de proyectos de software..

 

Sobre el Autor

Harold van Heeringen es consultor sénior de evaluación comparativa en Metri. Aparte de su trabajo para Metri, él está involucrado en Nesma (miembro de la Junta), el Grupo de estándares internacionales de evaluación comparativa de software (ISBSG, presidente actual) y el Consorcio Internacional de Métricas de Software Común (CÓSMICO, Consejo Consultivo Internacional, en representación de los Países Bajos).

Una publicación de blog representa la opinión personal del autor.
y puede no coincidir necesariamente con las políticas oficiales de Nesma.
Comparte este artículo en:

Deja una respuesta