GUIMARÃES, Valéria Aparecida [1]
LARA, Alexander Prado [2]
PUTTINI, Ricardo Staciarini [3]
GUIMARÃES, Valéria Aparecida; LARA, Alexander Prado; PUTTINI, Ricardo Staciarini. Aplicación de Análisis de Punto de Servicio en proyectos SOA. Revista Multidisciplinar Científica Centro del Conocimiento. Número 08. Año 02, Vol. 01. pp 88-102, noviembre de 2.017 mil. ISSN:2448-0959
Resumen
Estimar el tamaño de un software para el desarrollo es esencial para obtener una estimación fiable de coste y tiempo. Una de las técnicas de medición más utilizados y documentado para obtener el tamaño de un software es la función de Análisis de Puntos (FPA), que, sin embargo, tiene su uso en proyectos que utilizan el enfoque de la arquitectura orientada a servicios (SOA) menudo cuestionada. Este artículo presenta el resultado de aplicar la APF en un sistema desarrollado por completo utilizando el enfoque SOA, lo que permitió una comparación adicional de las estimaciones producidas por APF con esfuerzo, tiempo y costos reales del proyecto.
Palabras clave: software de estimación, de disponibilidad de software, APF, SOA.
1. Introducción
Estimar el tamaño de un software a ser desarrollado es esencial para obtener una estimación fiable de los costes y el tiempo (Wilkie, 2011), pero adecuadamente realizar este tipo de estimación es designado por la literatura como uno de los mayores desafíos que enfrentan los gerentes de esta zona (Pressman 2011; Wilkie, 2011; Kaur, 2016). Esto se muestra, por ejemplo, Roetzheim (2000), que dirigió durante 18 años, una extensa investigación, que concluyó que las principales causas de los fracasos de proyectos de software están relacionados con las estimaciones de costos pobres y calendario de ejecución, y no a problemas técnicos, equipo de política o de desarrollo.
Aunque no es una ciencia exacta, debido a la influencia de variables humanos, técnicos, ambientales y políticos (Soares, 2013), las técnicas de medición (métrica) y el software puede contribuir significativamente a la generación de estimaciones más asertivas, que disminuye la discrepancia entre lo que fue estimado y lo que se ha logrado y para detectar tendencias y anticipar problemas proporcionando un control de costos más eficiente, reducir el riesgo, mejorar la calidad y la garantía de que los objetivos de negocio son alcanzados (1997 FLORAC ; Pressman, 2008; Tichenor, 2013; Soares, 2013).
Una de las técnicas de medición más utilizados y documentado para obtener el tamaño funcional de un software es APF (por sus siglas en Inglés Análisis de función FPA Point) (IFPUG, 2010; Wilkie, 2011; Soares, 2013). Este método fue publicado por primera vez a mediados de los años 70 por Allan Albrecht (Albrecht, 1984) y mejorada por el usuario Función Internacional Point Group (IFPUG), y ya está bien establecido y ampliamente utilizado en todo el mundo (IFPUG, 2010; Calazans, 2011; SISP, 2015). El método utiliza puntos de función (PF) como una unidad de medida (IFPUG, 2010).
A pesar de la consolidación de la APF como una técnica para dimensionar el tamaño funcional de software (Lindskoog, 2009; IFPUG, 2010) y el esfuerzo continuo de mejora y evolución del método, hay situaciones en las que su adopción no es directa. proyectos de software que siguen Enfoque orientado a la arquitectura (SOA) – arquitectura para el desarrollo de software, cuyo principio fundamental es la construcción de servicios reutilizables e interoperables (ERL 2005), forma parte de la lista de entornos en los que se cuestiona la aplicación de la APF .
Las discusiones acerca de la aplicabilidad del método para proyectos SOA han sido constante y aún quedan muchos retos que hay que superar para su aprobación. (Gencel, 2008; Lindskoog, 2009; Gomes, 2012). Esta dificultad se debe a varios factores, en los que podemos destacar el hecho de que, en los proyectos de SOA, muchas características están diseñadas para su reutilización, lo que hace que sea común para el alcance de un proyecto romper el alcance de las funciones de la aplicación en desarrollo ( ERL, 2005). Además, SOA, sistemas complejos necesitan ser desglosado en servicios y gran parte del esfuerzo de análisis y diseño está ligado precisamente para el proceso de descomposición y la posterior restauración de los servicios. Este proceso requiere la aplicación explícita de los métodos y principios para lograr la articulación flexible, capacidad de composición, la normalización y la mediación de transacciones, entre otros, que no están presentes en el desarrollo de software convencional (ERL 2008). Por lo tanto, las métricas y parámetros de estimación de esfuerzo utilizados para el desarrollo tradicionales no podían aplicarse directamente en los proyectos de SOA (Lindskoog, 2009; Farrag, 2015).
En este contexto, este artículo presenta los resultados de un estudio de casos que involucran la medición, a través de la APF, un software totalmente desarrollado utilizando el enfoque SOA para su posterior comparación con el esfuerzo, el tiempo y los costes reales dispensados en la implementación del software. El trabajo se desarrolló a partir de los datos recogidos de un proyecto real, que los autores tuvieron acceso completo.
En este artículo se organiza de la siguiente manera: la sección 2 se resumen los conceptos básicos relacionados con el análisis PF y SOA, así como los principales trabajos científicos que guiaron la propuesta. La sección 3 presenta la metodología de trabajo adoptada, mientras que la sección 4 se presentan los resultados obtenidos. Por último, la sección 5 trae las principales conclusiones y comentarios finales.
2. conceptos
2.1 Análisis de función Point (FPA)
Como ya se ha mencionado, la APF es una técnica para medir el software software o proyecto de desarrollo / mantenimiento mantenida por el usuario Función Internacional Point Group (IFPUG) y que tiene por objeto la obtención del tamaño funcional "Puntos de Función "(PF), teniendo en cuenta el punto de vista del usuario (IFPUG, 2010). El IFPUG publicar y mantener actualizado Manual de Prácticas de recuento (CPM – Prácticas conteo manual), que contiene las reglas y el proceso a seguir para asegurar resultados más consistentes en la aplicación de la APF (IFPUG, 2010).
Las organizaciones pueden aplicar esta norma internacional para medir el tamaño de un software con el fin de: (i) para estimar el esfuerzo, costo y el tiempo requerido para el desarrollo, mantenimiento y mejora del software; (Ii) proporcionan apoyo a la análisis de la calidad y la productividad; (Iii) proporcionar un factor de normalización para la comparación de software (IFPUG, 2010). Su uso tiene muchos beneficios que incluyen: reglas de conteo objetivo, la independencia de la solución y lenguaje de programación tecnológica y la posibilidad de estimar la generación ya en las primeras etapas del ciclo de vida del software (SISP, 2015).
La aplicación del método implica realizar los siguientes pasos, detallada en el CPM (2010): (i) obtener la documentación disponible; (Ii) identificar el propósito y el tipo de marcador, determinar el alcance de la cuenta y la frontera de la solicitud; (Iii) la medición de funciones de datos, que son los requisitos de los usuarios funcionales en cuanto a la recuperación de almacenamiento y / o de datos y se clasifican en archivo lógico interno (ALI) – grupos de datos lógicos retenidas dentro del límite de la aplicación, y archivo de interfaz externa (AIE) – se sólo se hace referencia por la aplicación que se está midiendo; (IV) la medición de las funciones transaccionales, que son funciones proporcionadas al usuario para el procesamiento de datos por una aplicación y se clasifican en (a) las entradas externas (EE) – responsable de procesamiento de datos o información de control que tienen su origen fuera de la aplicación de la frontera; (B) Los pacientes ambulatorios (CE) – responsable de enviar los datos o información de control que salen de la aplicación de la frontera; (C) salidas externas (SE) – responsables de enviar datos o información de control que salen de la aplicación de la frontera, incluyendo la lógica de procesamiento adicional, además de la identificada en un paciente ambulatorio; (V) calcular el tamaño funcional; (Vi) de documentos y la presentación de informes del conteo. Es decir, a partir de la documentación de diseño o software y en el punto de vista (requisitos funcionales) del usuario se derivan PF en términos de características que ofrece y los datos involucrados. Tener la cantidad de PF y en base a modelos como las estimaciones simplificado Modelo (Vázquez, 2012) o el modelo COCOMO II (Boehm, 2009), se derivan del esfuerzo, tiempo y coste de un proyecto.
2.2 Arquitectura orientada a servicios (SOA)
SOA es un enfoque arquitectónico para el desarrollo de software, cuyo principio fundamental es la construcción de servicios reutilizables e interoperables (ERL 2005). Según ERL (2005), el servicio es la unidad fundamental de la lógica orientada a servicios (lógica de la solución), es decir, las características de la aplicación están disponibles en forma de servicio.
Una lógica se considera cuando algunos principios orientada a servicios, conocidos como principios de SOA se aplican en una extensión significativa de la solución (ERL 2005). De acuerdo ERL (2008) son ocho de estos principios: (i) estandarización de los contratos; (II) los servicios débilmente acoplados; (III) abstracción servicio; (IV) la capacidad de servicio de reutilización; (V) autonomía de servicios; (VI) estado de servicio de la independencia; (VII) la visibilidad de servicio (descubrimiento de capacidad); y (VIII) la capacidad de servicio de la composición.
SOA busca, a través de la aplicación de los principios: el aumento de la alineación entre negocio y TI; federalización (acceso a los servicios ha sido estandarizada con el fin de unificar la visión de sus clientes); la diversidad de proveedores; el retorno de la inversión (ROI); y la agilidad de la organización; y reducir la carga de TI en la organización (ERL 2008). Por lo tanto, SOA le permite construir aplicaciones que responden más rápidamente a las demandas del negocio, ya que los servicios se construyen de una manera estandarizada, pudiendo interoperar (comunicación) entre sí de una manera estándar y transparente, independientemente de la plataforma, proveedores o tecnologías que fueron construidos en o correr.
A pesar de que ha existido durante algún tiempo, SOA ha ganado importancia sólo desde mediados de los años 2000 (ERL 2005). Según una reciente encuesta (gaulteria, 2014), el mercado SOA está creciendo rápidamente. El informe de investigación indica que el mercado SOA alcanzó los US $ 5.7 mil millones en 2013 y podría llegar a los US $ 16.4 mil millones para el año 2020. Según la encuesta, este importante crecimiento se debe al hecho de que SOA ofrece procesos automatizados más eficientes y de TI ofrecer la oportunidad de invertir más del presupuesto en hacer crecer el negocio. Por otra parte, con las soluciones de software disociadas (independientes), los servicios SOA se pueden reutilizar de manera eficiente.
3. Presentación de la metodología de trabajo aprobados
La medición mediante el uso de PF para obtener el tamaño funcional de diseño de referencia, realizada mediante la aplicación de las reglas de recuento establecidas en CPM (IFPUG, 2010), con el objetivo de identificar, a través de un análisis comparativo, lo que sería el costo , tiempo y esfuerzo real dispensado en la realización del proyecto y los resultados obtenidos de la aplicación de la APF. Así, era posible evaluar si el uso de la APF sería adecuado para la medición de proyecto (desarrollado bajo el enfoque SOA).
Selección 3.1 Proyecto
La elección del diseño que se utiliza produjo de forma natural, ya que la empresa donde los autores trabajo fue contratado para estructurar la adopción de SOA por una organización por motivos de confidencialidad de la información, será nombrado contratista en el curso de este artículo .El proyecto dirigido, en general, la estructura de la adopción de SOA por el contratista. Se desarrollaron actividades para la estructuración, desarrollo, implementación y monitoreo del programa de adopción de SOA a través de la ejecución de actividades que incluye, entres otros, la creación de un sistema desarrollado por completo utilizando el enfoque SOA y que se llamará el diseño de referencia sobre este artículo.
3.2 Diseño de referencia de medición
la medición de diseño de referencia a través del uso de PF se llevó a cabo después de la implementación y el despliegue completo del software. Por lo tanto, se decidió realizar un recuento detallado, que también considera la cantidad de funciones transaccionales, la complejidad funcional (bajo, medio, alto) de cada función individual. Fueron utilizados como entradas de medida, además de artefactos producidos durante el desarrollo del proyecto, el acceso al software que se ejecuta. También contamos con la opinión de los expertos de los miembros del equipo del proyecto.
Esfuerzo 3.3 Proyecto de Software Estimación
Varios modelos para estimar el esfuerzo de proyectos de software, basados en PF, están actualmente disponibles, y las estimaciones Modelo simplificado (Vázquez (2012)) y el modelo COCOMO II (Boehm, 2009) el más utilizado (SISP, 2015). En este estudio, hemos utilizado las estimaciones de los modelos simplificados, el mismo utilizado por el SISP (2015).
4. Los resultados experimentales
4.1 Diseño de referencia
En esta sección se presentan los resultados reales obtenidos de la aplicación de diseño de referencia, que incluye información sobre los costos del equipo del proyecto, esfuerzo, tiempo y del proyecto.
Equipo 4.1.1 Proyecto
La Tabla 1 muestra el personal asignado al desarrollo de la solución. Presentan la información sobre el número de personas que participaron en el proyecto por tipo de recurso / papel, el papel del recurso asignado al equipo con sus respectivas porcentam de particação y la dedicación relativa, en porcentaje, de un papel de recursos / específica sobre todo el proyecto.
4.1.2 El tiempo y el esfuerzo de la Conseguido
DISEÑO DE REFERENCIA duró seis meses y el esfuerzo real se midió registrando horas en JIRA, una herramienta que permite el seguimiento de los proyectos a través de las actividades de registro y presentación de informes. La Tabla 2 muestra el esfuerzo dispensado en la fabricación de cada etapa de desarrollo del proyecto.
Tabla 2: Diseño de referencia esfuerzo realizado
| Proyecto de fase | horas |
| Modelización y Análisis de Negocios | 1076 |
| implementación | 826 |
| Tesis y Ejecución | 268 |
| Horas totales | 2170 |
4.1.3 Costo Held
El coste se calcula horas a Unidad UST conversión (Servicios Técnicos), que es la unidad médico utilizado para cuantificar el trabajo. Es decir, la cantidad de horas-hombre se convierte en UST como definición contractual para derivar los costos. El cálculo de UST tiene en cuenta la complejidad de la actividad realizada (baja, media y alta). La Tabla 3 muestra el resultado de la conversión de hora / UST para cada fase del proyecto.
Tabla 3: diseño de referencia Dirigida Costo
| Proyecto de fase | horas | UST |
| Modelización y Análisis | 1076 | 1765 |
| implementación | 826 | 894 |
| Tesis y Ejecución | 268 | 304 |
| Horas totales | 2170 | 2963 |
Teniendo en cuenta la cantidad contratada UST de R $ 247,50, el proyecto tuvo un costo total de R $ 733,342.50
4.1.4 Resultados generales
La Tabla 4 muestra el resumen de esfuerzo, tiempo y coste dispensado en la fabricación del diseño de referencia, que sirven como base para el análisis comparativo para el resultado de la medición de la magnitud funcional del software a través del uso mp.
Tabla 4: Resultado global
| DISEÑO DE REFERENCIA | |
| Esfuerzo (horas): | 2170 |
| Plazo (meses): | 6 |
| Costo (R $): | R $ 733,342.50 |
4.2 Medir el tamaño de la Funcional – IFPUG
La medición del tamaño funcional del software mediante FP considera la aplicación en su conjunto, con la visión funcional del punto de vista del usuario, según lo recomendado por la norma APF IFPUG (IFPUG, 2010). La Tabla 5 muestra el objetivo (objetivo o propósito de medir) y el alcance de medición (conjunto o subconjunto de aplicaciones que se mide). La Tabla 6 muestra brevemente el resultado del recuento correspondiente al valor del tamaño funcional de diseño de referencia. El personal Esfuerzo periodo de derivación y el costo se determinó sobre la base de estimaciones de los modelos simplificados, que se presentan en la Tabla 7.
Tabla 5: Escenario Funcional DISEÑO medición de referencia
| escenario funcional | |||
| Propósito de Medición | diseño de referencia de medición de tamaño funcional (APF IFPUG) desarrolló como contratista del programa de adopción de SOA. | ||
| Medición alcance | Aplicaciones de diseño de referencia | ||
Conde Técnica: determina si el recuento se estima o se rompe indicativa. El recuento indicativo se basa únicamente en la información acerca de las funciones de datos, es decir, en el número de archivos lógicos (Alis y EIS). El recuento estimado considera, a la cantidad de funciones de datos, información sobre las funciones de transacción de manera que para que las necesidades de los usuarios tienen que ser más detallada. En cuanto a los recuentos detallados, además de la cantidad de funciones transaccionales, es necesario determinar la complejidad funcional (bajo, medio, alto) de cada función individual (NESMA, 2015).
Tipo Conde: son tres posibles tipos de conteo: (i) Desarrollo: A medida que la funcionalidad que proporciona a los usuarios que consideran la primera instalación del software. (Ii) la mejora / mantenimiento: relacionados con cambios, es, añadido, cambiado o eliminado, a una funcionalidad de software existente. (Iii) Aplicación: medición de la funcionalidad que una aplicación ofrece al usuario. Una aplicación es conjunto coherente de procedimientos y datos automatizados, que tiene como objetivo apoyar un objetivo de negocio y consta de uno o más componentes, módulos o subsistemas (IFPUG, 2010).
Tamaño del proyecto funcional: Se refiere al valor del tamaño funcional de diseño de referencia.
Productividad Noche (h): Se refiere al número de horas productivas en una persona. Este trabajo fue considerado como 6 horas / día, según lo recomendado por el (SISP, 2015).
Índice de productividad (horas / FP): Se refiere a la cantidad de tiempo dedicado a la producción de 1 PF. La determinación del valor del índice de productividad depende de varios factores, que pueden incluir, entre otros, el tamaño de la plataforma de tecnología, seguridad, rendimiento, facilidad de uso y el proyecto. Cada organización debe tener su propia tabla de la productividad, teniendo en cuenta los datos históricos de proyectos anteriores.
Esfuerzo (persona / hora): Esto se refiere al número de horas a dispensar en la entrega de proyectos, o la entrega de cierto tamaño funcional. Se calcula basado en el diseño funcional y el tamaño del índice de productividad (tamaño (PF) x Índice de Productividad (HH / FP)).
Medio Ambiente: Se refiere al exponente para ser usado en la fórmula para determinar el término recomendado. La Tabla 1 muestra las opciones disponibles. Esto fue seleccionado el "Sistema OO – Sistema Orientado a Objetos", lo que más se acerque a las características de un proyecto SOA.
Otro período: se calcula según la fórmula Capers Jones[Jones,2007].
Mensual Carga de trabajo (horas): Se refiere al número de horas de trabajo trabajadas por persona en el mes.
Equipo: Se refiere a la cantidad de recursos necesarios para el desarrollo del proyecto y debe ser considerado como el porcentaje de asignación del recurso para el proyecto. En el resultado anterior, el equipo de diseño 6.2 características podría corresponder, por ejemplo, un equipo de 12 personas con la asignación de un 50% y un jefe de proyecto con un 20% asignado al proyecto.
El personal informado: Esto se refiere al equipo que trabajó con eficacia en el desarrollo del proyecto. Su objetivo es apoyar otras simulaciones de esfuerzo y tiempo y la distribución de los recursos en el equipo de acuerdo a la dedicación de cada uno para el proyecto.
Otras estimaciones simulaciones: estimaciones otras simulaciones se generaron en base al equipo informado y teniendo en cuenta la reducción de plazo. El valor del punto de función que se utiliza se definió sobre la base de referencias históricas de la empresa contratista. los costos del proyecto se calcularon sin considerar el período de reducción y teniendo en cuenta el período de reducción.
5. conclusiones
5.1 Análisis crítico de la propuesta
A partir del análisis de los resultados obtenidos por la aplicación de APF y referencia ejecución diseño se concluyó que el coste real del diseño SOA y obtenido a partir de la medición por FP dio como resultado valores significativamente diferentes (costo real: R $ 733.342 mil 50 y su costo estimado de R $ 349,600.00). También hubo una diferencia significativa entre el esfuerzo requerido para el desarrollo del proyecto y el esfuerzo real (verdadero esfuerzo: 2170 horas y el esfuerzo estimado: 6992 horas). El coste real y estimada (costo real: R $ 733,342.50 en comparación con su costo estimado de R $ 593,620.00) sólo mostró valores relativamente cercanos al estimar método de costo de derivación considera que la reducción del tiempo de desarrollo del proyecto en relación con el tipo recomendado idealmente ( en tiempo real: 6 meses frente a tiempo recomendado: 7,71 meses).
Por lo tanto, se concluyó que la APF tenía resultados muy diferentes en relación con los resultados reales, y por lo tanto no es adecuado para la medición de los proyectos de SOA. Soma es también el hecho de que la APF no cuenta en su puntuación de los requisitos no funcionales, que son comunes en muchas aplicaciones SOA, tales como los servicios de reutilización y de composición. Además de no permitir que la solución de medición fragmentado, es decir, la medición de forma individual para el servicio. Esta es una característica muy deseada cuando se trata de medir los proyectos de SOA, que pueden implicar la construcción de una solución completa o sólo un subconjunto de estos servicios, y también puede implicar la construcción de un único servicio específico.
5.2 Limitaciones y trabajo futuro
El trabajo se limita a medir solamente un proyecto. Además, se utiliza un solo método para derivar estimaciones de esfuerzo, costo y tiempo. En trabajos futuros, la aplicación de la APF en una mayor diversidad de proyectos y el uso de otros métodos de estimación puede beneficiar en que va a proporcionar una mayor fiabilidad en las conclusiones extraídas. También será de gran importancia para proponer un método específico para medir el tamaño del software de SOA, que trata de seguir los conceptos más puros de IFPUG con respecto a la medición funcional, sino también en cuenta la necesidad de una solución de medición por partes, así como la medición de requisitos no funcionales.
referencias
Albrecht, IBM J. Allan El CIS y la Directriz 313. AD / M Productividad 1984.
Boehm, B. W. Estimación de costes de software con COCOMO II. Prentice Hall, Nueva Jersey, 2009.
Calazans Angelica; LISBOA Irina; OLIVEIRA Marcelo. Evaluación de los sistemas Características Generales de Análisis de Puntos de Función – APF mediante la aplicación de los GQM – Meta, preguntas métricas. VII Simposio Internacional de Software Mejora de Procesos. San Pablo. Noviembre de 2011.
ERL, Thomas. Arquitectura orientada a servicios: Conceptos, Tecnología y Diseño. Crawfordsville: Prentice Hall PTR, agosto de 2005.
ERL, Thomas. Principios de Diseño SOA servicio. Prentice Hall, 2008.
Farrag, Esraa A.; Moawad Ramadán; IMAM, Ibrahim F. Un enfoque para la estimación del esfuerzo de la arquitectura orientada a servicios (SOA) Proyectos. JSW, v. 11, no. 1, p. 44-63, 2016.
FLORAC, William A.; PARK, Robert E.; Carleton, Anita D. software de medición práctica: Medición para la gestión y mejora de procesos. Carnegie Mellon Univ Pittsburgh PA-1997 INGENIERÍA DE SOFTWARE INST.
Gencel, Cigdem; DEMIRORS, Onur. medición de tamaño funcional revisited. ACM Transactions on Software Engineering y Metodología (TOSEM) v. 17, no. 3, p. 15, 2008.
GOMES, Yuri Marx Pereira. tamaño funcional, esfuerzo y costo de los proyectos SOA con puntos de función. no. LXVIII, Noviembre de 2012.
IFPUG – GRUPO INTERNACIONAL DE FUNCIÓN PUNTO DE USUARIO. Practica Manual Puntos Función Count. Versión 4.3.1, enero de 2010.
IFPUG – GRUPO INTERNACIONAL DE FUNCIÓN PUNTO DE USUARIO. Manual de prácticas de evaluación. Versión 2.3, mayo de 2015.
JONES, Costos C. Estimación de software. Segunda edición, McGraw Hill, 2007.
Kaur, Prabhjot. Una revisión de Software y Medición métrica. Revista Internacional de Aplicaciones Informáticas y Tecnología de la Información, Vol. 9, no. 2, p. 187, 2016.
Jeff Lindskoog. La aplicación de Puntos de Función ambiente dentro de la SOA. EDS, an HP company. St. E. Hoffer 1401 Kokomo, IN 46902. EE.UU.. Septiembre de 2009.
NESMA – Función Holanda dirige a los usuarios. Análisis de Puntos de Función Home. Julio de 2015.
Pressman, Roger S. Ingeniería de Software: un enfoque profesional. 7ª edición. Ed: McGraw Hill, 2011.
Roetzheim, William H. estimación de los costos de software. DESARROLLO DE SOFTWARE-SAN FRANCISCO, v. 8, no. 10, p. 66-68, 2000.
SISP. Métricas de software Script SISP: versión 2.1, Ministerio de Planificación, Presupuesto y Gestión. Secretario de Logística y Tecnología de la Información. Brasilia: MP, 2015.
Soares dos Reis, Julio César; BARBOSA, Marcelo Werneck. PROPUESTA PARA UN PRESUPUESTO PARA REQUISITOS TÉCNICOS. Diario de Sistemas e Informática-RSC, v. 3, no. 1, 2013.
Charley Tichenor, SNAP-Estudio de caso 2 (1 VSN. 0): Cómo utilizar los puntos de función y SNAP para Mejorar el Contrato de adquisiciones de software. IFPUG. De junio de de 2014.
VAZQUEZ, Carlos E.; SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Análisis de Puntos de Función: Medición, estimaciones y gestión de proyectos de software. 12ª Edición, Editor Erica Ltda, Sao Paulo, 2012.
Wilkie George F. et al. El valor del software de dimensionamiento. Tecnología de Información y Software, vol. 53, no. 11, p. 1236-1249, 2011.
[1] Maestría en Ingeniería Eléctrica – UNB
[2] Doctor en Ingeniería y Gestión del Conocimiento
[3] (2004), donde enseña en el Departamento de Ingeniería Eléctrica desde 1998. Realizó una etapa doctoral en la L’Ecole Supérieure d’Électricité (Supelec), Rennes / Francia (2001/2002) y etapa de post- doctorado en el Swedish Institute for Computer Science (SICS), en Estocolmo / Suecia (2011). Fue coordinador del Núcleo de Tecnología de la Información (NTI) de la UnB (2006-2008) y Director del Centro de Informática (CPD) de la UnB (2007-2008). En los últimos años, se ha convertido en una de las más importantes de la industria de la información y de la comunicación. Sus áreas de interés actuales incluyen: computación en nube, arquitectura orientada al servicio, gestión de procesos de negocio, sistemas distribuidos y aplicaciones de tecnologías de la información en entornos gubernamentales
