Uso de métricas y modelos de estimación en CMS

Uso de métricas y modelos de estimación en CMS

Introducción

Este artículo ha sido presentado en el VII Congreso Internacional sobre Aplicación de Tecnologías de la Información y Comunicaciones Avanzadas (ATICA2016), en el se da a conocer la situación actual sobre los métodos de estimación y medición de proyectos software, en el ámbito de los CMS. Según vayamos profundizando, se irán presentando técnicas, herramientas y metodologías que nos permitirán completar el estudio teórico de los temas que nos ocupan.

Medir debe ser considerado una necesidad ya que “todo aquello que no se puede medir no se puede controlar” (Salazar, Salazar). Sin embargo este proceso no es sencillo, ya que el software es el resultado de una actividad intelectual. Debido a la intangibilidad del software es lógico pensar que una unidad capaz de cuantificar el software debe ser por ende intangible. Pensemos un momento en la unidad de medida de longitud (metro) comúnmente aceptada, que define el SI de la siguiente forma: “distancia recorrida por la luz en el vacío en 1/299 792 458 partes de un segundo”. Siguiendo esta definición en caso de querer realizar una medición exacta, esta resultaría prácticamente imposible, por lo tanto, la medición obtenida se puede considerar una aproximación o estimación, por ello las unidades utilizadas en la medición de software son estimativas, con su respectivo margen de error.

Debemos considerar que una medida aislada no ofrece la exactitud requerida, por ello es necesario recopilar un histórico de datos de proyectos previos. El proceso establecido por las diferentes metodologías de explotación, llamado DM, consiste en extraer información del DW mediante el uso de análisis estadístico o sistemas inteligentes. En ocasiones estos DW contienen miles de proyectos heterogéneos, sin embargo aplicando técnicas de clustering, podremos transformar este DW en grupos de proyectos homogéneos.

Finalmente necesitaremos conocer que es un CMS, cuáles son sus características principales y como están clasificados, detallando algunos ejemplos concretos.

Métricas

En este apartado estudiaremos la normativa y estándares generales establecidos por la ISO y la IEC. Estos nos servirán para establecer las bases utilizadas por las métricas actuales, las cuales se estudiarán en el siguiente apartado. Estas métricas se encuentran también estandarizadas por la ISO / IEC. Todas ellas recogen el concepto de adaptación local, el cual permite realizar una adaptación de las mismas.

Existen dos normas relacionadas con el ámbito de la FSM. La primera es la ISO/IEC 14143-1:1998 que define los conceptos fundamentales. Estos conceptos promueven la interpretación consistente de los principios del FSM. (ISO, IEC 1998) En la norma se define la terminología a utilizar; se detallan las características principales que deben cumplir los métodos FSM; los requisitos que deben satisfacer; y las fases del proceso de aplicación.

La segunda parte de la norma ISO/IEC 14143-2:2002, establece: un marco de trabajo de la conformidad de un método FSM candidato; describe el proceso de conformidad; describe los requisitos para realizar la evaluación de la conformidad; provee directrices informativas; y provee ejemplos y plantillas. (ISO, IEC 2002)

Métricas más utilizadas

En primer lugar hablaremos de IFPUG, definida en el estándar ISO/IEC 20296:2009, el cual específica las definiciones, reglas y pasos para su aplicación. Su ámbito de aplicabilidad incluye el desarrollo de nuevos proyectos. (IFPUG 2009) Mencionaremos los elementos que describe, ya que son igualmente aplicables para el resto de métricas: tipos de datos elementales; tipos de datos registro; entrada externa; salida externa; consulta externa; archivos de interfaz externa; archivo lógico referenciado; y archivo lógico interno.

La siguiente métrica es NESMA, que surge con intención de cubrir aquellos ámbitos en los que IFPUG no puede ser aplicado, como es el caso de los proyectos evolutivos. Tan importante fue su impacto que la ISO creo el estándar ISO/IEC 24570:2005, en el cual se especifican las reglas y pasos para su aplicación. En lo que a la medición de proyectos de nuevo desarrollo se refiere, IFPUG y NESMA son prácticamente iguales. (NESMA 2009)

Para finalizar hablaremos de COSMIC, la cual también se encuentra estandarizada en la norma ISO/IEC 19731:2003. COSMIC realiza la medición basándose en los siguientes movimientos de datos: entradas; salidas; escrituras y lecturas. Para medir estos movimientos define el concepto de capa lógica. (ISO, IEC 2003)

International Software Benchmarking Standars Group

La ISBSG es una organización, cuya misión es mejorar los recursos de TI, mediante la provisión y explotación de repositorios públicos. (Fernández-Diego, Sanz-Berzosa et al. ) Este repositorio se organiza por versiones, encontrándose actualmente la Release 2016 R1, que incluye más de 7500 proyectos, incrementando este número a medida que surgen nuevas versiones.

Cada proyecto recibe dos tipos de valoraciones realizadas por ISBSG, sobre la calidad de su información: la calidad general de los datos, categorizada en cuatro niveles decrecientes de calidad (A, B, C y D); y la calidad de la medición funcional del proyecto, que utiliza el mismo criterio de categorización.

Sin embargo el uso de este repositorio tiene dos inconvenientes. El primero es que los resultados obtenidos en una versión no son reproducibles en una posterior. El segundo aparece en caso de que los criterios de selección de proyectos no estén correctamente explicados. De una forma u otra ISBSG nos proporciona una fuente de datos válida para realizar un proyecto de explotación.

Metodologías de explotación

De las múltiples metodologías de explotación se ha seleccionado CRISP-DM para su estudio, dado su grado de aceptación por la comunidad científica. Esta metodología costa de cuatro niveles de abstracción, organizados de forma jerárquica en tareas que van desde el nivel más general hasta los casos más específicos. (Rodríguez, Pollo Cattaneo et al. 2010) Cada fase está estructurada en tareas de segundo nivel, estas a su vez se proyectan en tareas, donde finalmente se describen las acciones a ser desarrolladas para situaciones específicas. (Arancibia 2010)

CRISP-DM está compuesta por seis fases. La primera de las fases es la de comprensión del negocio, en la cual se realiza la comprensión de los objetivos y requisitos del proyecto desde una perspectiva empresarial, para convertirlos en objetivos técnicos. La siguiente fase corresponde con la comprensión de los datos, esta fase tiene por objetivo establecer un primer contacto con el problema y establecer las relaciones más evidentes que permitan definir las primeras hipótesis. Una vez superada esta fase, llega el turno de la fase de preparación de los datos, en ella se preparan y adaptan los datos para las técnicas de DM. En concreto se seleccionan los datos a los que aplicar una determinada técnica de modelado. Seguidamente y con una estrecha relación con la fase anterior llega el turno de la fase de modelado, es esta se selecciona la técnica de modelado más apropiada y el método de evaluación. Una vez aplicado el modelo se pasa a la fase de evaluación, comprobando si el modelo cumple con los criterios de éxito del problema. En caso de que el modelo sea válido, se procede a la explotación del modelo, lo cual nos lleva a la última de las fases. En la fase de implantación se transforma el conocimiento obtenido en acciones dentro del proceso de negocio y se presentan los resultados de manera comprensible al usuario.

Clustering

Los modelos de estimación, que obtienen una relación matemática entre el esfuerzo y el tamaño de un proyecto software, proporcionan buenos resultados si el DW está formado por proyectos homogéneos. El clustering permite la división de datos en grupos de objetos similares. (Garre, Cuadrado et al. 2007)

Los algoritmos de clustering se pueden distinguir en métodos paramétricos y no paramétricos. Los métodos paramétricos se dividen en tres grupos fundamentales, jerárquicos, particionales y basados en densidad. En la categoría de métodos paramétricos encontramos los algoritmos de mezclas finitas. (Pascual, Pla et al. 2007) Los algoritmos jerárquicos son aquellos en los que se va particionando el conjunto de datos por niveles, de modo que a cada nivel se unen o se dividen dos grupos del nivel anterior. En otra clasificación se encuentran los algoritmos particionales, estos realizan una división de los datos en grupos y luego mueven los objetos de un grupo a otro según se optimice alguna función objetivo. Estos algoritmos asumen el número de cluster en que debe ser dividido el conjunto de datos. La última clasificación de algoritmos paramétricos son los algoritmos basados en densidad, los cuales enfocan el problema teniendo en cuenta la distribución de puntos en su interior. Estos algoritmos usan diversas técnicas para determinar dichos grupos como grafos, histogramas, etc.

En la otra categoría se encuentran los algoritmos basados en mezclas finitas, estos sirven para modelar densidades de probabilidad de conjuntos de datos univariados y multivariados, y modelan observaciones las cuales se asumen han sido producidas por un conjunto de fuentes e infieren los parámetros de estas fuentes, para identificar que fuente produjo cada observación.

Modelos de estimación

Un modelo es una representación abstracta de sistemas o procesos a fin de analizar, describir, explicar o simular esos sistemas o procesos. Además permite determinar un resultado final a partir de unos datos de entrada. Existen cuatro grupos: modelos con base histórica; modelos con base estadística; modelos teóricos; y modelos compuestos.

COCOMO II es un modelo de tipo compuesto, que está fundamentado en tres premisas (Boehm, Abts et al. 1997): los proyectos software cuentan con procesos de control y gestión, que incluyen la disponibilidad del software reutilizable, el nivel de conocimiento de la arquitectura y los requisitos, las limitaciones de horario, el tamaño y la fiabilidad; el nivel de detalle de los modelos de estimación debe ser coherente con el nivel de detalle de la información disponible; dadas las dos anteriores premisas cubre las estimaciones según el grado de definición de las entradas.

COCOMO II ofrece tres submodelos, la selección del más apropiado dependerá del grado de conocimiento del producto que va a ser desarrollado. El primer modelo es el de composición de aplicaciones, utilizada en etapas y tareas de prototipado. El siguiente modelo es el de diseño inicial, proporcionado para fases en las que se realizan tareas de exploración de alternativas arquitectónicas o de definición de estrategias de desarrollo. Por último el modelo post-arquitectura, utilizado cuando el proyecto está listo para comenzar, debiendo existir una arquitectura de ciclo de vida.

El esfuerzo es expresado en Personas Mes, entendiéndose como el tiempo total que una personas invierte trabajando en el desarrollo del proyecto durante un mes. El primer paso para los modelos de diseño inicial y post arquitectura es calcular el esfuerzo nominal, según la fórmula:

PM nominal = A x (tamaño)^B

Donde el tamaño se mide en miles de líneas de código o PF no ajustados, “A” representa los efectos multiplicativos del esfuerzo con otros proyectos. Y donde “B” representa el factor de escala calculado mediante la siguiente fórmula:

B = 0.91+0.01 x ∑ Wi

Donde W es el peso de cada uno de los cinco factores de escala. El último paso corresponde con el ajuste del esfuerzo nominal. En función del modelo elegido se utilizarán un número de multiplicadores de esfuerzo, siendo siete para el caso del diseño inicial y diecisiete para el modelo post arquitectura. Mediante la siguiente fórmula se puede realizar el ajuste, siendo “n” el número de multiplicadores de esfuerzo:

PM ajustado = PM nominal x ∏ EMi

Sistemas de gestión de contenidos

Los CMS no existían al inicio de la década de los noventa, a pesar de la complejidad inherente al desarrollo de portales. Fue la empresa Vignette la primera en desarrollar el primer CMS para el portal de noticias tecnológico CNET. (Morante Arreaga 2015)

Existen dos causas a las cuales se atribuye la aparición de los CMS, la primera sostiene que deben su aparición a la necesidad de suplir las insuficiencias de los sistemas de información basados en páginas estáticas, puesto que requerían personal especializado para su desarrollo. (Sarduy Domínguez, Urra González 2006) La otra causa es que los CMS surgen como una herramienta a partir de la evolución y aplicación de los lenguajes de programación y las ventajas que representa el trabajo con páginas dinámicas.

Los CMS dividen conceptualmente las páginas en públicas y privadas. Las páginas públicas se conocen como FrontEnd, y a las páginas privadas como BackEnd. Además están formados por una estructura de tres capas: capa de datos; capa de programación; y capa de diseño. (Menéndez Monroy 2015) Se pueden clasificar según el propósito que cumplan en las siguientes categorías: sistemas de gestión de contenidos; sistemas de gestión documental; sistemas de gestión de contenidos empresariales; y sistemas de gestión de contenidos web. En este artículo dedicaremos un apartado a estos últimos.

Sistemas de gestión de contenidos Web

Se trata de gestores de contenidos orientados a la publicación web. Reducen el coste de mantenimiento y administración de un portal ya que no es necesario que el usuario introduzca código HTML. Sino que a través de un editor integrado en el BackEnd se puede añadir contenido a la base datos, mientras el FrontEnd se encarga de mostrarlo con el estilo predefinido. Un CMS permite sin tener conocimientos de programación, crear sitios web con contenidos dinámicos y gestionar las responsabilidades de los usuarios. Sin embargo no todo son ventajas, ya que requiere una curva de aprendizaje elevada.

De los CMS existentes, en este artículo trataremos algunos de los más utilizados. En primer lugar hablaremos de Joomla, el cual está desarrollado en PHP. Joomla facilita una serie de extensiones para ampliar su funcionalidad: idiomas mediante ficheros de traducción; plantillas que permiten dar un aspecto general y homogéneo; componentes para presentar el contenido principal gestionando la información; y módulos, que son extensiones más ligeras y flexibles que un componente.

El siguiente CMS del que vamos hablar es Drupal. Tiene la diferencia de estar orientado a desarrolladores expertos, por lo que no incorpora demasiada funcionalidad inicialmente. Esta desarrollado en PHP y al igual que ocurría anteriormente, permite hacer uso directo de sus funciones a través de un API. Para ello ofrece las siguientes herramientas: los nodos son el contenido básico; las páginas utilizan contenidos estáticos; los bloques son contenidos dinámicos que se pueden habilitar en distintas zonas del tema; los módulos sirven para ampliar las funcionalidades del core; y los temas que son los encargados de la configuración estética del portal.

Otro CMS desarrollado en PHP es WordPress. Del mismo modo que ocurría anteriormente ofrece un API que permite ampliar su funcionalidad: los temas son los encargados de gestionar la presentación del contenido, pudiendo incluir código fuente; los plugins pueden realizar cualquier tipo de funcionalidad y amplían la funcionalidad del core; y los widget son fragmentos de código que permiten mostrar información o funcionalidades específicas.

El último de los CMS a tratar es Liferay. Liferay está desarrollado en Java. Cuenta con dos versiones, una comercial llamada Liferay Digital Experience Platform y una libre llamada Liferay Portal CE. Corre en la mayoría de servidores y contenedores de servlets, bases de datos y sistemas operativos y es compatible con los principales estándares de Java. Como viene siendo habitual, Liferay proporciona herramientas llamadas plugins para extender y personalizar sus funcionalidades. Estos plugins se describen brevemente a continuación: los portlets esta separados del core, pudiendo ser desplegados en cualquier contenedor de servlets, pueden realizar funcionalidades muy variadas; los service builder cuyo fichero de configuración debe estar incluido en un plugin portlet, crean tablas y relaciones propias en la base de datos, además de generar la capa encargada de manejar todas sus transacciones; los themes gestionan el aspecto visual de todo el contenido; las plantillas definen las estructuras de las páginas, creando posiciones en las que colocar los portlets; y los hooks que sobre escriben las funcionalidades del core, como pueden ser los ficheros de traducción, las propiedades del portal, ficheros del lado cliente y servicios del lado servidor. (Sezov 2012)

Conclusiones

A medida que se han ido presentando las métricas de estimación de software, se ha observado como paulatinamente han ido adquiriendo mayor nivel de abstracción. Si inicialmente utilizaban como unidades las líneas de código fuente, progresarón hacía los puntos de función. Es posible que este nivel de abstracción sea suficiente, pero existe la posibilidad de que sea necesario un nivel extra de abstracción en el caso de la medición de desarrollos basados en CMS. Esta afirmación está apoyada en la evolución de los sistemas de información actuales, en los cuales se cubren un gran número de funcionalidades sin apenas esfuerzo por parte de los desarrolladores.

Como se ha visto las métricas ofrecen adaptaciones locales de las mismas. Otro camino de investigación nos llevaría a desarrollar una metodología que defina los pasos necesarios para realizar conversiones entre las diferentes arquitecturas de los diferentes CMS, y las capas lógicas, tales como las que define COSMIC. Para validar si nuestra adaptación local es un método FSM válido, necesitaremos seguir las normas ISO 14143-1 y 14143-2.

Un aspecto preocupante, ha sido observar el nivel de detalle requerido por las diferentes métricas para la realización de las estimaciones. En algunos casos, como por ejemplo, en el caso de proyectos de mejora, en los cuales no disponemos de toda la información necesaria sobre el tamaño o la funcionalidad del sistema. Podemos afirmar sin temor a equivocarnos, que no podemos realizar la estimación del proyecto. Por lo tanto merece la pena investigar, como reducir la rigidez de los requisitos de entrada, sin que la calidad de la medición se vea afectada.

Dejando de lado las métricas, el siguiente punto principal del trabajo eran los modelos de estimación. Se ha estudiado COCOMO II, un modelo matemático de estimación que ofrece buenos resultados. Sin embargo existen otros métodos que pueden ofrecer mejores resultados, como es el caso de los sistemas de aprendizaje, en concreto las redes neuronales.

El último punto principal que se ha tratado durante el artículo, han sido los CMS. Como se ha podido apreciar permiten utilizar un amplio abanico de tecnologías, frameworks, etc. Sin embargo parece que existen una serie de conceptos comunes a todos ellos, como por ejemplo los plugins y la forma de extender las funcionalidades del propio CMS. Esto resulta un punto a favor, dado que nos puede facilitar el trabajo para la realización del método de conversión anteriormente mencionado.

Para finalizar hablemos del coste. Se ha tratado durante el artículo del término esfuerzo como personas / mes. Sin embargo lo realmente importante en términos de costes es el valor monetario. Hallar la relación del tamaño con el valor monetario es importante debido a que nos permite contabilizar el software como parte de los activos de la organización o para comprar o vender software. Debemos tener siempre en cuenta que este valor debe ser un rango con unos máximos y mínimos.

Referencias

Arancibia, J., 2010. Metodología para el Desarrollo de Proyectos en Minería de Datos CRISP-DM.

Boehm, B., Abts, C., Clark, B. and Devnani-Chulani, S., 1997. COCOMO II model definition manual. The University of Southern California.

Fernández-Diego, M., Sanz-Berzosa, M. and Torralba-Martínez, J., Evolución reciente del banco de datos ISBSG.

Garre, M., Cuadrado, J., Sicilia, M.A., Rodriuez, D. and Rejas, R., 2007. Comparación de diferentes algoritmos de clustering en la estimación de coste en el desarrollo de software. Revista Española de Innovación, Calidad e Ingeniería del Software, 3(1), pp. 6-22.

IFPUG, 2009. Function Point Counting Practices Manual.

ISO and IEC, 2003. ISO/IEC 19731-2:2003 COSMIC-FFP Un método de medición del tamaño funcional.

ISO and IEC, 2002. ISO/IEC 14143-2:2002 Medida del tamaño funcional Parte 2: Evaluación de la conformidad de los métodos de medida del tamaño del software según la norma ISO/IEC 14143-1:1998.

ISO and IEC, 1998. ISO/IEC 14143-1:1998 Medida del tamaño funcional Parte 1: Definición de conceptos.

Menendez Monroy, A., 2015. Comparativa de los métodos de desarrollo de ampliaciones en gestores de contenidos web.

Morante Arreaga, A.N., 2015. Análisis de la arquitectura de los CMS Open Source más utilizados para el diseño funcional, seguridad y auditoría del sistema de gestión de lípidos. Propuesta aplicada al laboratorio de biotecnología de la Facultad de Ciencias Naturales.

NESMA, 2009. Function Point Analysis for Software Enhancement.

Pascual, D., Pla, F. and Sánchez, S., 2007. Algoritmos de agrupamiento. Método Informáticos Avanzados.

Rodríguez, D., Pollo Cattaneo, M.F., Britos, P.V. and García Martínez, R., 2010. Estimación Empírica de Carga de Trabajo en Proyectos de Explotación de Información, XVI Congreso Argentino de Ciencias de la Computación 2010.

Salazar, E.E. and Salazar, M.F., Métricas de Proceso y Proyecto.

Sarduy Domínguez, Y. and Urra González, P., 2006. Sistemas de gestión de contenidos: en busca de una plataforma ideal. Acimed, 14(4), pp. 0-0.

Sezov, R., 2012. Liferay in action: the official guide to Liferay portal development. Manning Shelter Island, NY.

Tienes que estar conectado para dejar un comentario.