- Puntos de Función.
- COCOMO II
Puntos de Función.
La técnica de punto función, definida por Allan Albrecht, de IBM, en 1979 , es un método para medir el tamaño del software. Pretende medir la funcionalidad entregada al usuario independientemente de la tecnología utilizada para la construcción y explotación del software, y también ser útil en cualquiera de las fases de vida del software, desde el diseño inicial hasta la explotación y mantenimiento.
Existen diferentes metodologías de medición, la más popular de las cuales es la mantenida por el International Function Point Users Group (IFPUG).
Método de recuento
La técnica de medición del tamaño en punto-función consiste en asignar una cantidad de "puntos" a una aplicación informática según la complejidad de los datos que maneja y de los procesos que realiza sobre ellos. Siempre tratando de considerarlo desde el punto de vista del usuario.
Por ejemplo, el método IFPUG-FPA (Function Point Analisys) establece los siguientes pasos:
- Determinar el tipo de recuento
Puede tratase de un proyecto, una mejora a una aplicación o recontar una aplicación ya instalada. Según el tipo se incluirán funciones de conversión, modificación y baja de funcionalidad.
- Identificar el alcance del recuento y los límites de la aplicación
Se delimita el alcance de lo que se va a medir.
- Contar las funciones de datos
Se realiza un inventario de los ficheros lógicos utilizados (vistos como un usuario) tanto internos de la aplicación como mantenidos por otra aplicación. Para cada uno de ellos se recuenta el número de datos y de registros lógicos. En función de este número se calcula para cada fichero un índice de complejidad y posteriormente una contribución en puntos función.
- Contar las funciones transaccionales
De modo similar se inventarían los procesos elementales del sistema, distinguiendo los procesos de entrada, salida y consulta. Según el número de ficheros lógicos y datos que maneja cada proceso y de su naturaleza, se calcula su índice de complejidad y su contribución en puntos función.
- Calcular el recuento bruto de puntos función
A partir de los recuentos anteriores se calcula un recuento total bruto (unadjusted).
- Determinar el factor de ajuste
En función de 14 "características generales del sistema" que se valoran de 0 a 5 en función de su grado de influencia, se calcula un factor de ajuste al recuento.
Estas características tienen que ver con la arquitectura de la aplicación, sus requisitos de carga y rendimiento, complejidad de cálculos, etc..
- Calcular el recuento ajustado
Aplicando el factor de ajuste al recuento bruto se obtiene el recuento final.
Crítica
La principal crítica que recibe esta métrica es la de requerir una dedicación adicional en los proyectos de desarrollo de software, que suelen desenvolverse con presupuestos ajustados.
Su implantación en una organización no acostumbrada a su uso suele resultar penosa y requerir un fuerte compromiso de la dirección. Suele ser vista por los desarrolladores como un mecanismo de control de su trabajo.
Otros aspectos negativos serían:
- Resulta arduo formar al personal en su utilización y más todavía mantener unos criterios homogéneos de recuento.
- Carece de precisión cuando se trata de proyectos pequeños. Por debajo de unos 100 pf resulta demasiado poco fiable.
- Para resultar realmente útil, una organización de desarrollo y mantenimiento de software debe tener recontada la mayor parte de su base instalada, pero hacerlo resulta muy costoso especialmente si mantiene software adquirido a terceros.
- El factor de ajuste calculado a partir de las características generales del sistema resulta de dudosa utilidad.
COCOMO II
Propuesto y desarrollado por Barry Boehm, es uno de los modelos de estimación de costos mejor documentados y utilizados.
El método de estimación COCOMO II está basado dos modelos: uno aplicable al comienzo de los proyectos (Diseño preliminar, en inglés Early Design) y otro aplicable luego del establecimiento de la arquitectura del sistema (Post arquitectura, en inglés Post Architecture).
El modelo de Diseño preliminar (Early Design) contempla la exploración de las arquitecturas alternativas del sistema y los conceptos de operación. En esta etapa no se sabe lo suficiente del proyecto como para hacer una estimación fina. Ante ésta situación, el modelo propone la utilización de Puntos de Función como medida de tamaño y un conjunto de 7 factores (cost drivers) que afectan al esfuerzo del proyecto. Estos 7 factores son agrupaciones de los factores que se utilizan en la otra variante del modelo (Post Arquitectura).
El modelo Post arquitectura (Post Architecture) contempla el desarrollo y el mantenimiento de un producto software. Esta estrategia es más precisa si se ha desarrollado una arquitectura del sistema, la cual haya sido validada y establecida como base para la evolución del producto. Ante ésta situación, el modelo propone la utilización de Líneas de código fuente y/o Puntos de Función como medidores del tamaño, modificadores para indicar el grado de reutilización y descarte del software, un conjunto de 17 estimadores de costo, y un conjunto de 5 factores que afectan de manera exponencial en el esfuerzo del proyecto.
donde:
PM nominal: es el esfuerzo nominal requerido en meses-hombre
Size : es el tamaño estimado del software, en miles de líneas de código (KSLOC) o en Puntos de Función sin ajustar (convertibles a KSLOC mediante un factor de conversión que depende del lenguaje y la tecnología).
A : es una constante que se utiliza para capturar los efectos multiplicativos en el esfuerzo requerido de acuerdo al crecimiento del tamaño del software. El modelo la calibra inicialmente con un valor de 2.94.
B : es una constante denominada Factor escalar, la cual tiene un impacto exponencial en el esfuerzo y su valor está dado por la resultante de los aspectos positivos sobre los negativos que presenta el proyecto.
Inconvenientes
Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizar las tareas.
- Se puede desviar de la realidad debido a la existencia de comentarios en las líneas de código.
- No es objetivo puesto que se realizan estimaciones sobre estimaciones del número de líneas de código que tendrá nuestro proyecto.
- Se mide el producto, o su tamaño, cosa totalmente diferente a medir la productividad.
- La medición por líneas de código no tienen sentido en la orientación a objetos.
No hay comentarios:
Publicar un comentario