Embed Size (px)
Citation preview
Especificación de un Modelo de Medición y Estimación de Proyectos
de Software para la Banca Central
Juan Manuel Cubillos Avellaneda
Universidad Nacional de Colombia
Facultad de Ingeniería, Departamento de Sistemas e Industrial
Bogotá, Colombia
2017
Especificación de un Modelo de Medición y Estimación de Proyectos
de Software para la Banca Central
Juan Manuel Cubillos Avellaneda
Tesis presentada como requisito parcial para optar al título de:
Magister en Ingeniería de Sistemas y Computación
Director (a):
Jairo Hernán Aponte Melo, Ph.D.
Línea de Investigación:
Ingeniería de Software
Grupo de Investigación:
ColSWE
Universidad Nacional de Colombia
Facultad de Ingeniería, Departamento de Sistemas e Industrial
Bogotá, Colombia
2017
Para ser grande, sé entero:
Nada tuyo exageres o excluyas.
Sé todo en cada cosa.
Pon cuanto eres en lo mínimo que hagas,
Así en cada lago la luna entera brilla,
Porque alta vive.
Fernando Pessoa (1888-1935)
Agradecimientos
Agradezco en primer lugar al profesor Jairo Hernán Aponte por haber tenido el interés, la
disposición y la paciencia para la consecución de este trabajo. Además, agradezco el haber
despertado en mí la motivación por hacer investigación.
Al equipo del Banco de la República que de una u otra forma apoyó el desarrollo de este
proyecto.
A mi familia quien tuvo que soportar durante más de dos años mis ausencias tanto físicas
como de pensamiento para cumplir este objetivo.
Resumen y Abstract IX
Resumen
Este proyecto de investigación está enfocado en aspectos de medición y estimación de
software. A través de una organización empresarial del sector financiero que desarrolla
este tipo de actividades sobre su portafolio de proyectos de software, el cual está
compuesto por nuevos desarrollos, adquisición de productos existentes en el mercado y
mantenimiento de software. Se planteó como objetivo principal especificar un modelo de
medición y estimación de proyectos de software que contribuyera a mejorar la planeación
de proyectos en términos de esfuerzo, costo y duración. Para lograr este objetivo, se
realizó un diagnóstico mediante la aplicación de una entrevista dirigida a personas de la
organización que lideran este frente a través de personal interno y firmas de outsourcing
en desarrollo de software y una encuesta dirigida a los involucrados directamente con
temas de medición y estimación de software. El resultado del diagnóstico sirvió para
identificar aspectos claves en términos de debilidades, oportunidades de mejora,
fortalezas y amenazas además de direccionar de mejor manera las etapas subsecuentes
de la investigación. Posteriormente, se realizó un estudio del estado del arte a nivel
académico y de industria en temas relacionados con medición y estimación de software y
específicamente en aquellos temas obtenidos del análisis de resultados de la etapa de
diagnóstico. Finalmente, con base en el análisis realizado y el marco teórico desarrollado,
se planteó la estructura de un modelo integral de medición y estimación de software a
través de un conjunto de requisitos de alto nivel que servirán de insumo para una posterior
implementación del modelo propuesto.
Palabras clave: Medición de software, Estimación de software, Gestión de Proyectos,
Ingeniería de Software, Puntos Funcionales, SNAP Points.
X Resumen y Abstract
Abstract
This research is about software measurement and estimation. Through a financial
company which performs this type of activities on its software project portfolio compound
by projects of new development, acquisition of commercial software and software
maintenance, it is proposed as main objective of this research, to specify a software project
measurement and estimation model to improve project planning in terms of effort, costs
and duration. To achieve this goal, a diagnosis was made applying an interview and a
survey. The first instrument was applied to people who lead this topic through internal staff
and software development outsourcing staff. The second instrument was applied to a large
number of people which is directly involved with topics of software measurement and
estimation. The diagnosis result was used to identify key aspects such as weaknesses,
opportunities for improvement, strengths and threats, as well as to better target the
subsequent stages of this research. Subsequently, it was carried out a state of the art study
in topics related to software measurement and estimation and specifically in those subjects
obtained from the diagnosis results analysis. Finally, based on the diagnosis results and
the conceptual framework compiled, it was proposed the structure of an integral model of
software measurement and estimation by using a set of high level requirements
specification that will serve as input for a future implementation of the proposed model.
Keywords: Software measurement, Software estimation, Project management, Software
engineering, Function Points, SNAP Points.
Contenido XI
Contenido
Agradecimientos .......................................................................................................... VII
Resumen ........................................................................................................................ IX
Abstract........................................................................................................................... X
Lista de figuras ............................................................................................................ XIV
Lista de tablas .............................................................................................................. XV
Introducción .................................................................................................................... 1 1. Organización objeto de estudio .............................................................................. 5
1.1 Banco de la República ..................................................................................... 5 1.1.1 ¿Qué es un banco central? .................................................................. 5 1.1.2 Funciones del Banco de la República .................................................. 5
1.2 Dirección General de Tecnología ..................................................................... 7 1.2.1 Antecedentes y evolución .................................................................... 7 1.2.2 Estructura organizacional ..................................................................... 8
1.3 Departamento de Gestión Informática ........................................................... 11 1.3.1 Principales funciones ......................................................................... 11 1.3.2 Recurso humano ................................................................................ 12 1.3.3 Gestión por procesos ......................................................................... 13 1.3.4 Gestión de proyectos ......................................................................... 14 1.3.5 Estándares y metodologías ................................................................ 15 1.3.6 Modelo de outsourcing ....................................................................... 16
2. Gestión de proyectos de software ........................................................................ 17 2.1 Introducción ................................................................................................... 17 2.2 Portafolio de proyectos de software ............................................................... 18 2.3 Planeación de proyectos ................................................................................ 22 2.4 Desarrollo de software ................................................................................... 23 2.5 Medición y estimación de software ................................................................ 23
2.5.1 Antecedentes ..................................................................................... 24 2.5.2 Conocimiento ..................................................................................... 24 2.5.3 Habilidades y capacidades ................................................................. 25 2.5.4 Técnicas............................................................................................. 26 2.5.5 Herramientas ..................................................................................... 28
3. Diagnóstico .......................................................................................................... 29 3.1 Entrevista....................................................................................................... 29
3.1.1 Resultados y análisis de la entrevista ................................................. 30 3.2 Encuesta........................................................................................................ 31
3.2.1 Resultados y análisis de la encuesta .................................................. 32
XII Modelo de Medición y Estimación de Proyectos de Software
3.2.1.1 Información demográfica .................................................................... 32 3.2.1.2 Medición funcional del software .......................................................... 34 3.2.1.3 Medición no-funcional del software ..................................................... 36 3.2.1.4 Estimación de software ....................................................................... 37 3.2.1.5 Otros aspectos.................................................................................... 38
3.3 Análisis DOFA ............................................................................................... 39 3.4 Conclusiones del diagnóstico ........................................................................ 41
4. Marco conceptual ................................................................................................. 45 4.1 Medición de software..................................................................................... 45
4.1.1 Introducción a la medición .................................................................. 45 4.1.2 Historia y evolución de la medición de software .................................. 46 4.1.3 Medición del tamaño del software ....................................................... 47 4.1.4 Medición funcional .............................................................................. 48 4.1.4.1 Puntos funcionales ............................................................................. 49 4.1.4.2 Medición no-funcional ......................................................................... 55 4.1.4.3 SNAP Points ....................................................................................... 56
4.2 Estimación de software ................................................................................. 59 4.2.1 Enfoques de estimación ...................................................................... 62 4.2.2 Productividad ...................................................................................... 65 4.2.2.1 Factores que influencian la productividad ........................................... 68 4.2.2.2 Conductores de esfuerzo .................................................................... 69
4.3 Otros tipos de medición y estimación ............................................................ 71 4.3.1 Medición y estimación de requisitos .................................................... 71 4.3.2 Medición y estimación de pruebas de software ................................... 72 4.3.3 Medición y estimación en metodologías ágiles ................................... 74
4.4 Estándares .................................................................................................... 76 4.4.1 IFPUG: ISO/IEC 20926:2009 .............................................................. 76 4.4.2 COSMIC: ISO/IEC 19761:2011 ........................................................... 76 4.4.3 FiSMA: ISO/IEC 29881:2010 .............................................................. 78 4.4.4 MK II: ISO/IEC 20968:2002................................................................. 79 4.4.5 NESMA: ISO/IEC 24570:2005 ............................................................ 80 4.4.6 ISO/IEC 14143 Functional Size Measurement .................................... 81
4.5 Repositorios de información de proyectos ..................................................... 81 4.5.1 ISBSG ................................................................................................ 81 4.5.2 QSM ................................................................................................... 82
5. Modelo de medición y estimación de software ...................................................... 83 5.1 Definición del modelo .................................................................................... 83 5.2 Representación y especificación del modelo ................................................. 84
5.2.1 Consideraciones frente a las metodologías ágiles .............................. 85 5.2.2 Estructura de la especificación ........................................................... 85 5.2.3 Medición funcional y no-funcional ....................................................... 87 5.2.4 Estimación de software ....................................................................... 88 5.2.5 Especificación de requisitos ................................................................ 89 5.2.6 Construcción de software ................................................................... 90 5.2.7 Pruebas de software ........................................................................... 91 5.2.8 Mantenimiento de software ................................................................. 92 5.2.9 Esquema de contratación de software ................................................ 94 5.2.10 Oficina de medición y estimación de software .................................... 95
6. Conclusiones y recomendaciones ........................................................................ 97 6.1 Conclusiones ................................................................................................. 97 6.2 Recomendaciones ......................................................................................... 98
Contenido XIII
Bibliografía .................................................................................................................. 106
Glosario........................................................................................................................ 112
Contenido XIV
Lista de figuras
Pág.
Figura 1-1: Estructura de la DG-T en 2016 ............................................................. 9
Figura 2-1: Portafolio de proyectos de software .................................................... 19
Figura 2-2: Productos de software por tecnología principal ................................... 20
Figura 2-3: Productos de software por tipo de usuario .......................................... 20
Figura 2-4: Infraestructuras del mercado financiero .............................................. 21
Figura 2-5: Proceso de medición y estimación para mantenimiento de software .. 26
Figura 2-6: Proceso de medición y estimación para desarrollo de software .......... 27
Figura 3-1: Nivel educativo de los entrevistados ................................................... 33
Figura 3-2: Edades de los entrevistados ............................................................... 33
Figura 3-3: Estándares de medición reconocidos ................................................. 34
Figura 3-4: Experiencia de los entrevistados en medición funcional ..................... 35
Figura 3-5: Conocimiento en estándares de medición no-funcional ...................... 37
Figura 3-6: Enfoque utilizado para realizar medición no-funcional ........................ 37
Figura 3-7: Técnicas reconocidas de estimación de software ............................... 38
Figura 3-8: Opinión sobre suficiencia en la documentación existente ................... 38
Figura 4-1: Proceso general de conteo de puntos funcionales .............................. 50
Figura 4-2: Definición de la frontera de la aplicación ............................................. 51
Figura 4-3: Proceso de Valoración SNAP ............................................................. 57
Figura 4-4: Procesos de medición de SNAP points y puntos funcionales. ............. 59
Figura 4-5: Fases de la estimación en el ciclo de vida del software ...................... 61
Figura 4-6: Cono de incertidumbre ........................................................................ 62
Figura 4-7: Clasificación de métodos de estimación de software .......................... 64
Figura 4-8: Proceso del método COSMIC ............................................................. 77
Figura 5-1: Modelo de medición y estimación de software .................................... 84
Contenido XV
Lista de tablas
Pág.
Tabla 1-1: Número de empleados de TI en los últimos 30 años. .................................. 8
Tabla 1-2: Distribución de planta de personal al interior de la DG-T ........................... 11
Tabla 1-3: Cargos y personal del DGI ........................................................................ 12
Tabla 1-4: Procesos de la metodología de gestión de proyectos ................................ 14
Tabla 3-1: Síntesis de la aplicación de la entrevista ................................................... 30
Tabla 3-2: Distribución de encuestados por tipo de organización ............................... 32
Tabla 3-3: Experiencia en medición y estimación de software ................................... 33
Tabla 3-4: Dificultades en la aplicación de reglas de medición funcional .................... 35
Tabla 3-5: Análisis DOFA – Debilidades .................................................................... 40
Tabla 3-6: Análisis DOFA - Oportunidades ................................................................ 40
Tabla 3-7: Análisis DOFA - Fortalezas ....................................................................... 41
Tabla 3-8: Análisis DOFA - Amenazas ....................................................................... 41
Tabla 4-1: Tipos de funciones del método IFPUG ...................................................... 52
Tabla 4-2: Puntos Funcionales para EI’s .................................................................... 52
Tabla 4-3: Puntos Funcionales para EO’s .................................................................. 52
Tabla 4-4: Puntos Funcionales para EQ’s .................................................................. 53
Tabla 4-5: Puntos Funcionales para ILF’s .................................................................. 53
Tabla 4-6: Puntos Funcionales para EIF’s .................................................................. 53
Tabla 4-7: Características Generales del Sistema...................................................... 54
Tabla 4-8: Categorías y subcategorías del proceso SNAP ......................................... 58
Tabla 4-9: Enfoques y Técnicas de Estimación .......................................................... 63
Tabla 4-10: Actividades asociadas al desarrollo de software ....................................... 66
Tabla 4-11: Factores que influencian el esfuerzo en proyectos de software ................ 68
Tabla 4-12: Conductores de esfuerzo más comunes ................................................... 69
Tabla 4-13: Métodos y niveles de pruebas ................................................................... 73
Tabla 5-1: Estructura de la especificación de requisito ............................................... 86
Tabla 5-2: Requisito de medición funcional ................................................................ 87
Tabla 5-3: Requisito de medición no-funcional ........................................................... 87
Tabla 5-4: Requisito de estimación de software ......................................................... 88
Tabla 5-5: Requisito de estimación en especificación de requisitos ........................... 89
Tabla 5-6: Requisito de productividad ........................................................................ 90
Tabla 5-7: Actividades asociadas a las pruebas de software ..................................... 91
Tabla 5-8: Requisito de estimación de pruebas .......................................................... 91
XVI Modelo de Medición y Estimación de Proyectos de Software
Tabla 5-9: Requisito de mantenimiento de software ................................................... 93
Tabla 5-10: Requisito de contratación .......................................................................... 94
Tabla 5-11: Requisito oficina de medición y estimación ................................................ 95
Tabla 5-12: Requisito funciones de la oficina de medición y estimación ....................... 96
Introducción
La estimación de proyectos es el acto de crear una valoración cuantitativa de un monto
probable o resultado. Este concepto es usualmente aplicado a proyectos en lo referente a
costos, recursos, esfuerzo y duración [1]. En el dominio de la ingeniería de software, la
estimación de esfuerzo, predicción y planeación, frecuentemente son términos
relacionados. En el caso del desarrollo del software, el objetivo es realizar estimaciones lo
más precisas posibles para completar el proyecto de forma exitosa.
La medición es el principal conductor de la estimación del esfuerzo de proyectos de
software [2]. Este concepto está relacionado con el cálculo del tamaño del producto a ser
construido. La medición de software es una disciplina dentro de la ingeniería de software
que se ha venido estudiando desde la época en la cual se utilizaban lenguajes de
programación como Fortran y Assembler. Los métodos tradicionales evalúan el tamaño del
software a través de líneas de código (SLOC - Source Lines Of Code), mientras los
enfoques contemporáneos para evaluar el tamaño del software se basan en la medición
del tamaño funcional [3]. Recientemente los enfoques de medición involucran el tamaño
funcional y el tamaño no-funcional del software [4].
La mayoría de estudios e investigaciones relacionadas con este tema se han enfocado en
definir nuevas técnicas y en perfeccionar las existentes. De acuerdo con algunos autores
como Jones y Chemuturi [5] y [4] y la experiencia del autor, hay vacíos en los cuerpos de
conocimiento existentes que están relacionados con dos aspectos que pretende abordar
esta investigación: (1) La definición más precisa de técnicas de medición y estimación para
fases de la ingeniería de software distintas al desarrollo de software (v.g. especificación de
requisitos y pruebas del sistema) y (2) la integración de distintas técnicas de medición y
estimación en un modelo que cubra el ciclo de ingeniería de un proyecto de software, esto
es, desde la especificación de requisitos hasta la obtención de software en condiciones de
operación en un ambiente productivo.
2 Introducción
Las principales razones por las cuales se realizó esta investigación están relacionadas en
primer lugar con un marcado interés por parte del autor en temas de medición y estimación
de software tanto a nivel académico como de industria. La segunda razón tiene que ver
con el desarrollo reciente que ha tenido esta temática a nivel de ingeniería de software y
de gerencia de proyectos y que, a juicio del autor, no es uno de los temas más estudiados
ni aplicados a nivel académico y de industria cuando se emprenden proyectos de desarrollo
de software. La tercera razón es el aporte que puede generar el resultado del estudio para
la comunidad de la ingeniería de software, a nivel local e internacional, como referente
para otro tipo de organizaciones interesadas en implementar modelos integrales de
medición y estimación de proyectos de software.
La organización utilizada para el desarrollo de este proyecto es la Banca Central de
Colombia representada por el Banco de la República y en particular la Dirección General
de Tecnología (DG-T), área responsable de la definición de políticas y estándares de
tecnología y seguridad informática y de definir y controlar su desarrollo, dentro de un
objetivo de modernización permanente, de acuerdo con las necesidades del Banco y los
desarrollos tecnológicos relacionados.
Dentro del portafolio de proyectos de software que administra la DG-T se requieren
actividades de medición y estimación de software y en la mayoría de los casos estos
esfuerzos presentan oportunidades de mejora en aspectos específicos como a nivel
general. El volumen de trabajo, las inversiones realizadas en este sentido y la cantidad de
personas involucradas ponen en evidencia la necesidad de contar con un modelo
transversal para la medición y estimación de proyectos de software que mejore los
procesos de planeación de proyectos, la asignación de recursos, el monitoreo y control de
los mismos, que redunde en el mejoramiento de los actuales índices de proyectos exitosos
y en la disminución de la tasa de proyectos que enfrentan situaciones de fallas en términos
de alcance, tiempo, costo y calidad. Actualmente se utilizan técnicas aisladas sobre
elementos puntuales del ciclo de vida del software que no son suficientes para dar soporte
a las necesidades de planeación y ejecución requerida para los proyectos.
La investigación desarrollada buscó definir elementos fundamentales de un modelo
integral de medición y estimación de proyectos de software, para ser utilizado en una
organización específica. Gran parte del proyecto se centró en estudiar cuáles son los
Introducción 3
elementos susceptibles de incluir en el modelo de acuerdo a una revisión del estado del
arte. Posteriormente se desarrollaron y articularon cada uno de los elementos definidos,
revisados y estudiados. Sobre estos elementos, existen estudios en mayor o menor
medida, pero hasta ahora no se ha encontrado en el estado del arte una articulación
transversal de todos ellos que involucren técnicas, herramientas y métodos de aplicación
al ciclo completo de la ingeniería de software. Para el desarrollo de este proyecto se
investigó sobre los estudios realizados en materia de medición y estimación de software,
desde los métodos tradicionales hasta los más recientes, incluyendo aproximaciones
académicas y de industria, estándares internacionales y tendencias actuales.
Uno de los objetivos centrales de esta investigación es especificar un modelo de medición
y estimación de proyectos de software para ser utilizado sobre el portafolio de proyectos
de software de una organización determinada. Este modelo articula una serie de técnicas,
métodos y herramientas de medición y estimación de software que se han propuesto a lo
largo de los últimos años y que se han desarrollado con diferentes niveles de profundidad.
Para lograr lo anterior, se realizó en primera instancia un estudio al interior del Banco de
la República sobre la situación actual en materia de planeación de proyectos de software
en el contexto de medición y estimación de software para identificar debilidades, fortalezas,
riesgos asociados y oportunidades de mejora. Posteriormente, se produjo un marco teórico
en materia de medición y estimación de proyectos de software basado en una revisión del
estado del arte a nivel académico y de industria. Finalmente, se propuso una especificación
de alto nivel de los requisitos necesarios para la implementación de un modelo integral de
medición y estimación de proyectos de software ajustado a las necesidades de la
organización.
1. Organización objeto de estudio
1.1 Banco de la República
La información que se presenta a continuación sobre la organización utilizada para realizar
esta investigación ha sido recopilada de varias fuentes que incluyen la historia del Banco
de la República [6]; La Introducción al análisis económico [7]; El Banco de la República –
Antecedentes, Evolución y Estructura [8]; Programa de Gestores [9]; Website de Banco
[10] y Tesis de grado de maestría sobre el Banco de la República [11].
1.1.1 ¿Qué es un banco central?
Es una institución que ejerce la soberanía monetaria, en nombre y representación del
estado para formular e implementar la política monetaria dirigida a mantener la estabilidad
del nivel general de precios, a fin de preservar el poder adquisitivo de los ingresos de la
población.
1.1.2 Funciones del Banco de la República
Emisor de la moneda legal. El Banco de la República, por mandato constitucional, es
la única institución autorizada para emitir moneda legal de circulación forzosa y poder
liberatorio (sirve para librarse de obligaciones) en todo el país. Esto significa que el
Banco tiene el monopolio de la emisión de monedas y billetes, además planea y
coordina las emisiones de moneda y distribuye el dinero en todo el país.
Administrador de las Reservas Internacionales. Administrar las reservas
internacionales del país con el propósito de garantizar que los agentes de la economía
puedan hacer sus pagos al resto del mundo. En la administración de las reservas, si
bien el Banco busca que la inversión tenga una buena rentabilidad, los criterios
principales para su manejo son la seguridad de las inversiones y su liquidez.
6 Modelo de Medición y Estimación de Proyectos de Software
Prestamista de última instancia. El Banco de la República puede prestar dinero a
uno o varios intermediarios financieros, cuando se vean enfrentados a determinadas
circunstancias transitorias de iliquidez. Los préstamos de última instancia tiene el
propósito de preservar la confianza del público en el sistema financiero, evitar la crisis
de éste y proteger a los usuarios del sistema.
Banquero de Bancos y coordinador del sistema de pagos. El Banco maneja las
cuentas de depósito de los intermediarios financieros, de manera que estos siempre
tengan recursos disponibles para entregar a sus ahorradores en el momento en que
los requieran. El sistema de pagos es el sistema a través del cual los agentes de la
economía se pagan o cancelan sus obligaciones entre sí, utilizando los medios de pago
aceptados universalmente por todas las personas. El sistema de pagos en Colombia
se basa en gran parte, en la utilización de cheques y otros documentos físicos, pero en
los últimos años se han evolucionado a la utilización de tarjetas débito y crédito.
Banquero, agente fiscal y fideicomisario del gobierno. El Banco de la República
cumple con estas funciones por cuanto, de un lado, puede recibir en depósitos fondos
de la Nación y de las entidades públicas, bajo las condiciones que establezca la Junta
Directiva del Banco. De otro lado, a solicitud del gobierno, puede actuar como agente
fiscal en la contratación de créditos externos e internos y en operaciones que sean
compatibles con la finalidad del Banco. En cuanto al crédito al gobierno, solamente en
situaciones excepcionales señaladas expresamente en la constitución (artículo 373),
el Banco de la República puede conceder crédito directo al gobierno, requiriéndose la
aprobación unánime de los siete miembros de la Junta.
Apoyo al desarrollo científico, cultural y social. El nivel profesional y la estructura
operativa del Banco le permiten apoyar, simultáneamente, el desarrollo científico,
cultural y social del país, a través de la creación de fundaciones destinadas a
seleccionar, estimular y financiar investigaciones en las áreas de las ciencias, la
tecnología, las humanidades, la antropología, la arqueología, la educación y la salud y
las artes. Además, el Banco ha participado en el rescate y la preservación del
patrimonio cultural y en la creación de estímulos a su desarrollo mediante la
administración y creación de bibliotecas y museos especializados.
Capítulo 1 7
1.2 Dirección General de Tecnología
1.2.1 Antecedentes y evolución
La Tecnología de Información (TI) ha sufrido grandes transformaciones en el Banco de la
República. Las necesidades de automatización de la organización aumentaron
permanentemente desde 1965, cuando se adquirió la primera computadora. Los
imperativos de competitividad, calidad y buen servicio para los clientes internos y externos
del Banco exigieron que la TI fuera de mayor calidad, confiabilidad y oportunidad. Cuando
se habla de TI en la Banca Central de Colombia, se hace referencia a la evolución y
transformación de la actual Dirección General de Tecnología (DG-T) y todos sus
componentes, además de sus interrelaciones con otras áreas. A continuación se listan los
momentos más significativos que sintetizan los cambios que ha sufrido la DG-T desde su
aparición hasta el día de hoy:
La aparición de la Subgerencia de Informática (SGINF) como un área estratégica
dentro del Banco, responsable de la definición de políticas y estándares de TI y
seguridad informática.
El proceso de modernización iniciado en el año 1994 que cambió radicalmente la
función, la estructura y el pensamiento de la SGINF y del Banco con relación a las
posibilidades de la TI en las organizaciones y en particular en aquellas con actividades
tan específicas como lo es el negocio de Banca Central .
La aparición de la actual Dirección General de Tecnología por efectos de la
reestructuración de varias áreas de negocio del Banco a partir de 2010 y la rede-
nominación de varias de ellas, como es el caso de la eliminación de la SGINF y la
creación de la DG-T.
El momento actual de la DG-T en cuanto a su misión y visión de largo plazo frente al
rol que debe desempeñar como protagonista del desarrollo tecnológico del Banco y del
sector financiero, además de seguir ejerciendo labores de soporte y creación de valor
en las esferas culturales de la nación.
Desde la creación del Departamento de Sistemas en el año 1975, los ingenieros de
sistemas del Banco se concentraban fundamentalmente en la administración de los
computadores y en desarrollar y operar algunas aplicaciones. El acceso a la informática
8 Modelo de Medición y Estimación de Proyectos de Software
estaba restringido a unos cuantos especialistas. A medida que fue creciendo el portafolio
de servicios se demandó por parte de las áreas del Banco mayor cantidad de ingenieros
para atender diversos negocios a través de sistemas de información computarizados. La
Tabla 1-1 presenta la evolución en cuanto al número de personas pertenecientes al área
de TI del Banco para diferentes momentos en los últimos 30 años.
Tabla 1-1: Número de empleados de TI en los últimos 30 años.
Año Número de empleados
1985 50
1990 123
2000 126
2016 166
La DG-T está conformada por profesionales especializados en cada una de las áreas que
la componen. La gran mayoría de estos profesionales son ingenieros de sistemas. Existen
también ingenieros electrónicos, técnicos en sistemas y/o electrónica además de
funcionarios con formación en áreas administrativas.
1.2.2 Estructura organizacional
A partir del año 2010, se realiza la última transformación organizacional para el área de TI
del Banco. Aparece la DG-T, a la cual adhieren otras áreas funcionales además de hacer
evidente el aumento de su tamaño en términos de personal, infraestructura tecnológica y
portafolio de productos y servicios. En la Figura 1-1 se muestra la actual estructura del
área de tecnología del Banco de la República.
Capítulo 1 9
Figura 1-1: Estructura de la DG-T en 2016
Fuente: Creación del autor.
A continuación se describe a un alto nivel cada una de las áreas de la estructura
organizacional que componen la actual DG-T:
Dirección General de Tecnología (DG-T): Es la responsable de la definición de
políticas y estándares de tecnología y seguridad informática y de definir y controlar su
desarrollo, dentro de un objetivo de modernización permanente, de acuerdo con las
necesidades del Banco y el desarrollo tecnológico asociado. La misión está relacionada
con su contribución al cumplimiento de los objetivos del Banco y a la generación de
valor a sus áreas, brindando servicios y productos basados en tecnología. Así mismo,
la visión es ser reconocidos por sus clientes como socios estratégicos, resultado de
una gestión de mejora continua que integra personas, procesos y tecnología [12].
Coordinación Administrativa (CA): Es un grupo de apoyo encargado de facilitar la
asignación y control de los recursos económicos necesarios para el cumplimiento de
la misión de la DG-T y garantizar el pago debido y oportuno de las obligaciones
contraídas a través de cualquiera de sus dependencias.
Organización de la Calidad (OC): Compuesta por un grupo de ingenieros consultores
responsable de “determinar e implementar la política, los objetivos, los procedimientos
Gerencia General
Subgerencia General de Servicios
Corporativos
Dirección General de Tecnología
Departamento de Tecnología Informática
Subdirección de Computación Corporativa
Subdirección de Tele-
Comunicaciones
Departamento de Gestión
Informática
Departamento de Seguridad Informática
Unidad de Seguridad Electrónica
Unidad de Soporte y Continuidad Informática
Centro de Soporte
Organización de la Calidad
Coordinación Administrativa
Arquitecto
10 Modelo de Medición y Estimación de Proyectos de Software
y las responsabilidades de la calidad utilizando medios tales como la planeación, el
control, el aseguramiento y el mejoramiento” [13].
Departamento de Tecnología Informática (DTIN): De esta área hacen parte el
director de Tecnología Informática, las subdirecciones de Computación Corporativa
(DTIN-SCC) y de Telecomunicaciones (DTIN-ST), ingenieros de telecomunicaciones
y administradores de bases de datos además de personal administrativo. Este
departamento es responsable de mantener operativa y tecnológicamente actualizada
y adecuada a las necesidades de la institución, la plataforma de cómputo y
telecomunicaciones del Banco.
Departamento de Gestión Informática (DGI): De este departamento hacen parte el
director de Gestión Informática, asesores de soluciones informáticas, ingenieros
consultores, expertos y especializados además de las personas que cumplen funciones
administrativas. Tiene como objetivo primordial asesorar a las demás áreas de negocio
en la identificación de necesidades para traducirlas en proyectos de adquisición,
desarrollo y mejoramiento continuo de sistemas de información [14].
Departamento de Seguridad Informática (DSI): Compuesto por el director de
Seguridad Informática y las secciones de Seguridad en Redes y Aplicaciones y de
Protección de la Información, además de ingenieros consultores, expertos,
especializados y personal administrativo. Este departamento vela por la seguridad de
la información en cada una de las plataformas existentes en el Banco.
Unidad de Seguridad Electrónica (USE): Es el área responsable de realizar estudios
y diseños de sistemas de seguridad para cada una de las áreas o sucursales del Banco.
Así mismo, es la responsable de instalar y mantener los sistemas de seguridad,
electrónicos, mecánicos y de radiocomunicaciones del Banco a nivel nacional [15].
Unidad de Soporte y Continuidad Informática (USCI): Compuesta por el director de
la unidad, ingenieros de soporte, de continuidad informática además de personal
administrativo. Es el área que administra la Mesa de Ayuda o Centro de Soporte para
usuarios internos y externos y gestiona la continuidad del negocio mediante la
implementación de planes de contingencia.
La Tabla 1-2 muestra la distribución de la planta de personal para el año 2016.
Capítulo 1 11
Tabla 1-2: Distribución de planta de personal al interior de la DG-T
Ingenieros Profesionales/
Administrativos
Técnicos/
Analistas Auxiliares Directivos Otros Total
DG-T 1 1 1 3
OC 2 2
CA 5 2 2 9
DTIN 21 9 2 3 35
DGI 47 1 1 7 56
DSI 15 1 1 17
USE 7 8 2 1 1 19
USCI 13 6 3 1 2 25
TOTAL 106 12 19 12 14 3 166
1.3 Departamento de Gestión Informática
El Departamento de Gestión Informática (DGI) es el área de TI eje central de este trabajo
de investigación por ser la organización desde la cual se gestionan los proyectos de
software del Banco de la República razón por la cual, a continuación se presentan en
mayor detalle algunas de sus características.
1.3.1 Principales funciones
Las principales funciones del DGI se enmarcan dentro de dos grandes categorías
tecnológicas: La gestión de proyectos y la ingeniería de software. A continuación se
describen las más relevantes:
Asesorar a las demás áreas de negocio en la identificación de necesidades de
tecnología que puedan ser satisfechas a través de la implementación e implantación
de sistemas de información.
Ser responsable del mantenimiento de sistemas de información que se encuentran en
operación. Este mantenimiento puede ser:
o Adaptativo: Modificar el sistema para hacer frente a cambios en el ambiente
donde reside el sistema (v.g. Base de Datos, Sistema Operativo, Servidor de
Aplicaciones, etc.).
12 Modelo de Medición y Estimación de Proyectos de Software
o Perfectivo: Implementar requisitos funcionales los cuales extienden la
funcionalidad del sistema.
o Preventivo: Incrementar la mantenibilidad y confiabilidad del sistema para
prevenir problemas en el futuro (v.g. integraciones con otros sistemas).
o Correctivo: Corregir defectos (bugs) en el software.
Apoyar a las áreas de negocio en el levantamiento de requisitos funcionales y no-
funcionales para ser implementados en sistemas de información nuevos y aquellos que
se encuentran en fase de mantenimiento.
Apoyar a las áreas de negocio en la planeación y realización de pruebas de aceptación
de usuario (UAT-User Acceptance Testing).
1.3.2 Recurso humano
El DGI cuenta en la actualidad con 56 personas de planta, distribuidas en distintos roles
tal como lo muestra la Tabla 1-3.
Tabla 1-3: Cargos y personal del DGI
Cargo Funciones y Responsabilidades Número
personas
Director
Proponer, planear, coordinar, dirigir y controlar los proyectos de sistematización del Banco dentro de un marco de eficiencia, seguridad y productividad y definir las pautas de aseguramiento de calidad y niveles de servicio, para obtener productos y acciones que garanticen el resultado esperado.
1
Asesor
Gestionar el portafolio de proyectos del departamento dentro de un marco metodológico de gestión de procesos y riesgos, y soportado en contratos marco de mejoramiento y pruebas de sistemas de información
1
Asesor de Soluciones
Informáticas
Asesorar a las áreas usuarias que le sean asignadas, en la definición de su estrategia y la identificación, búsqueda e implantación de soluciones informáticas que soporten su operación, apoyadas en tecnologías de información.
5
Ingeniero Consultor
Liderar técnicamente uno o más proyectos de desarrollo y/o mejoramiento de sistemas de información de complejidad alta y coordinar las actividades inherentes a los mismos.
7
Ingeniero Experto
Liderar técnicamente uno o más proyectos de desarrollo y/o mejoramiento de sistemas de información de complejidad media y coordinar las actividades inherentes a los mismos.
16
Ingeniero Especializado
Liderar técnicamente uno o más proyectos de desarrollo y/o mejoramiento de sistemas de información de complejidad baja y coordinar las actividades inherentes a los mismos.
24
Capítulo 1 13
Cargo Funciones y Responsabilidades Número
personas
Profesional
Realizar las actividades relacionadas con el control de contratos, la revisión de las facturas y la custodia de los expedientes de contratación así como actualizar la información de los inventarios, activos y personal contratista.
1
Auxiliar Asistir al personal del departamento en la atención telefónica, procesos de archivo y correspondencia y demás labores administrativas.
1
1.3.3 Gestión por procesos
El DGI basa su gestión en un modelo de procesos. A continuación se realiza una
descripción de los procesos de negocio que ejecuta. La información presentada a
continuación ha sido extraída del modelo de procesos de la DG-T del Banco del República
[16].
Gestionar la Demanda: Registrar, clasificar y priorizar la demanda de servicios
tecnológicos administrados por la DG-T. Comprende las necesidades detectadas por
los usuarios y las que surgen como parte de la prestación de los servicios tecnológicos.
Realizar Análisis y Diseño Integral: Obtener el diseño de la solución tecnológica que
responda de manera integral a la necesidad identificada. El diseño comprende además
de la funcionalidad requerida los aspectos técnicos, de seguridad y de continuidad
necesarios para la solución tecnológica.
Construir e Implantar: Construir y poner en producción la solución tecnológica.
Comprende la planeación de la construcción, configuración, pruebas y puesta en
producción de los componentes, módulos o configuraciones que satisfacen las
necesidades del área de negocio.
Operar y Prestar Soporte: Dar solución a los diferentes requisitos operativos,
técnicos, administrativos y eventos que surgen de las actividades propias del Banco.
Comprende la atención de solicitudes operativas, la realización de tareas técnicas y
administrativas programadas, y la gestión de incidentes.
Realizar Seguimiento y Mejora: Realizar seguimiento y analizar las oportunidades de
mejora del Sistema de Gestión. Comprende las actividades relacionadas con el
seguimiento al sistema de gestión y las posibles mejoras que puedan surgir de la
operación de la DG-T.
14 Modelo de Medición y Estimación de Proyectos de Software
1.3.4 Gestión de proyectos
El DGI basa parte de su gestión de proyectos en los estándares del Project Management
Institute (PMI) para gestionar proyectos de Software. La metodología de Gerencia de
Proyectos usada actualmente fue desarrollada en el año 2003 y gradualmente ha sido
actualizada de acuerdo con los procesos y principios de la DG-T y del Banco, además de
las mejores prácticas del Project Management Body of Knowledge (PMBOK). Actualmente
la metodología está alineada con el estándar PMBOK Cuarta Edición [17].
La metodología de gestión de proyectos es de obligatorio cumplimiento en cuanto a la
definición de los grupos de trabajo, roles y responsabilidades, grupos de procesos y
documentación asociada a cada proceso. La Tabla 1-4 presenta los procesos utilizados
para gestionar proyectos de software.
Tabla 1-4: Procesos de la metodología de gestión de proyectos
Grupo de procesos Proceso
Iniciación
Analizar la necesidad de negocio
Desarrollar estudio de factibilidad
Construir Charter (Carta/Acta de Constitución) del proyecto
Planeación
Realizar la programación del proyecto
Elaborar el presupuesto del proyecto
Desarrollar la planeación organizacional
Planear la gerencia de riesgos
Formalizar la planeación de adquisiciones
Desarrollar la planeación de la calidad
Realizar la planeación de las comunicaciones
Realizar planeación de la configuración
Ejecución
Ejecutar el plan del proyecto
Invitar a proveedores
Seleccionar y contratar a proveedor
Adquirir el personal del proyecto
Distribuir información
Capítulo 1 15
Grupo de procesos Proceso
Monitoreo y Control
Controlar el desempeño
Controlar la configuración
Monitorear y controlar el plan de gerencia de riesgos
Controlar la calidad
Controlar el cronograma
Controlar los costos
Administrar el contrato
Cierre Realizar cierre del contrato
Realizar cierre administrativo
1.3.5 Estándares y metodologías
A continuación se relacionan los principales estándares y metodologías utilizadas en el
DGI para realizar su labor de gestión de proyectos de software.
Estándares: son guías para orientar el trabajo que se desarrolla en el área. Establecen
las bases de políticas y procedimientos. Los estándares que utiliza el DGI están
relacionados en su mayoría con desarrollo de software, los cuales cubren aspectos
desde lineamientos arquitectónicos, pasando por frameworks o marcos de
implementación hasta la gestión de pruebas de software. Todos los estándares
adoptados están gobernados por el “Grupo de Arquitectura” que tiene una estructura
informal y depende directamente del Director General de Tecnología de la DG-T. Al
año 2016 hay definidos 174 estándares de tecnología de información.
Metodologías: son métodos sistemáticos utilizados para lograr un objetivo específico.
Las más representativas usadas en el DGI son:
o Gerencia de proyectos
o Desarrollo y gestión de requisitos
o Desarrollo de aplicaciones de usuario final
o Análisis de valor ganado
o Aplicación del juicio de expertos
o Gestión de riesgos
o Medición de software por puntos funcionales
o Gestión de pruebas
16 Modelo de Medición y Estimación de Proyectos de Software
1.3.6 Modelo de outsourcing
Con el fin de atender las necesidades de las 66 áreas de negocio del Banco [18] desde
hace aproximadamente 20 años se ha hecho necesario el contar con aliados estratégicos
externos que apoyen la función del DGI en materia de construcción y mantenimiento de
software. El modelo de outsourcing ha sido modificado durante los últimos años, pasando
de compañías que se dedicaban esencialmente a construir software a un esquema de
tercerización. Este último modelo ha ofrecido opciones adicionales además del desarrollo
de software como por ejemplo, apoyo en el levantamiento de procesos de negocio,
especificación de requisitos y pruebas de software. Las compañías que brindan este tipo
de servicios al DGI son tanto nacionales como extranjeras y tienen modelos de presencia
en sitio y fábricas de software a nivel local y regional.
En este sentido, se han establecido acuerdos contractuales con firmas reconocidas en la
industria local y en la mayoría de situaciones son contratos por un número de horas fijas
que son consumibles en esquemas de tiempos y materiales y horas asociadas a la
productividad de construcción de software cuando se utilizan enfoques de medición
funcional.
2. Gestión de proyectos de software
Este capítulo describe las principales características relacionadas con la forma como se
gestionan los proyectos de software al interior del DGI.
2.1 Introducción
Los proyectos de software que se desarrollan al interior del DGI están orientados a la
implementación de sistemas de información organizacionales que apoyan procesos de
negocio del Banco. Existen dos grandes familias de sistemas de información:
Los específicos a la función de Banca Central. En estos casos no es posible
encontrar productos comerciales a nivel local y el DGI debe recurrir a proveedores
extranjeros. Debido a la complejidad en términos de regulación de Banca Central para
cada país, los productos comerciales requieren una gran personalización lo que ha
llevado en algunas ocasiones a optar por el desarrollo de productos a la medida en
lugar de adquirir productos comerciales que deben ser personalizados en grandes
proporciones (en más de un 50%).
Los que soportan a las áreas funcionales tradicionales o de apoyo. Los que se
pueden encontrar en cualquier organización empresarial tales como sistemas de
nómina, contabilidad, cartera, cuentas por pagar, cuentas por cobrar, indexadores
documentales, inventarios, activos fijos, etc. En esta familia se encuentran sistemas
comerciales que cubren gran parte de la funcionalidad requerida. En los otros casos,
donde la casuística es específica del Banco ha sido necesario hacer desarrollos a la
medida o personalización sobre productos existentes en el mercado.
Existen tres tipos de proyectos de software en el DGI:
18 Modelo de Medición y Estimación de Proyectos de Software
Proyectos de construcción de nuevos sistemas de información: para el desarrollo
de estos sistemas se utilizan las metodologías y estándares descritos en el numeral
“1.3.5 - Estándares y metodologías” de este documento.
Proyectos de implantación de sistemas existentes en el mercado: también
conocidos como COTS (Commercial-Off-The-Shelf). Se adquieren productos
comerciales que son personalizados de acuerdo con las necesidades del Banco. El
DGI propende por una baja personalización (únicamente las integraciones con otros
sistemas corporativos) y una adherencia a los estándares ofrecidos por fabricantes,
comercializadores e implantadores de este tipo de soluciones.
Proyectos de mantenimiento: proyectos para gestionar la evolución de productos de
software en términos de mejoras funcionales y corrección de defectos.
Para emprender un proyecto de software en el DGI, existen restricciones y supuestos
fundamentales que a continuación se describen:
Debe existir un proyecto formalmente establecido. Esta formalización se logra a través
de un charter de proyecto, que en el contexto del Banco se conoce como “Carta de
Constitución”.
Debe existir un presupuesto asignado.
Debe estar definido un plan de proyecto que defina actividades, recursos y horizontes
de tiempo.
Debe estar conformado un grupo de ingeniería con los siguientes roles:
o Ingeniero Líder (ingeniero del DGI que ejerce el rol de gerente técnico)
o Ingeniero de Seguridad (ingeniero del DSI)
o Ingeniero de Telecomunicaciones (ingeniero del DTIN)
o Ingeniero de Administrador de Servidores (ingeniero del DTIN)
o Ingeniero de Continuidad (ingeniero de la USCI)
o Arquitecto de Tecnología (ingeniero de la DG-T)
2.2 Portafolio de proyectos de software
El portafolio de proyectos de software, entendido como una colección de proyectos o
programas y otro trabajo que es agrupado para facilitar la gestión y así cumplir los objetivos
estratégicos de negocio [19], es configurado periódicamente en el DGI. Las actividades de
Capítulo 2 19
identificación, categorización, evaluación, selección, priorización y balanceo de
componentes (proyectos y programas) son desarrollados tanto en el proceso de
elaboración de presupuesto como en el ejercicio de planeación estratégica de tecnología.
En el primero de ellos se identifican frentes de trabajo y necesidades sobre los proyectos
de software que serán abordados en la siguiente vigencia presupuestal que generalmente
tiene una duración de un año contado a partir del primer día del año posterior a la
elaboración del presupuesto correspondiente. En cuanto a la planeación estratégica, se
identifican proyectos y programas que contribuirán al cumplimiento de los objetivos
estratégicos.
Existe un portafolio a nivel de la DG-T. El interés de esta investigación está enfocado
únicamente en el portafolio de proyectos de software entendido como un subgrupo del
portafolio de la DG-T (existen otros tipos de proyectos de tecnología no relacionados con
software). La Figura 2-1 presenta los componentes del portafolio de proyectos del DGI en
términos de proyectos de construcción de software a la medida o adquisición de productos
comerciales con algún grado de personalización además de los proyectos de
mantenimiento de soluciones de software en operación. Cada una de las ramificaciones
presenta el número de proyectos de cada categoría.
Figura 2-1: Portafolio de proyectos de software
Fuente: Creación del autor.
Portafolio de
Proyectos de
Software
Nuevo Desarrollo a
la medida (6)
Adquisición de
Productos de
Software (20)
Mantenimiento de
Software (93)
Banca Central (5)
Areas de Apoyo (1)
Otros (0)
Banca Central (11)
Areas de Apoyo (7)
Otros (2)
Banca Central (39)
Areas de Apoyo (45)
Otros (9)
20 Modelo de Medición y Estimación de Proyectos de Software
La Figura 2-2 presenta la distribución de los componentes del portafolio por tipo de
tecnología. Se observa que las tecnologías principales son Java, .NET, Oracle y Scripting
(i.e. Perl, PHP, JavaScript, Python). Aproximadamente un 15% de los componentes son
productos comerciales de los cuales se desconoce su tecnología de implementación y
sobre los cuales no se realiza intervención en su código fuente. En la Figura 2-3 se observa
que la mayoría de los componentes del portafolio está dirigida a usuarios internos a la
organización aunque el 14% de ellos está dirigido a usuarios externos del sistema
financiero.
Figura 2-2: Productos de software por tecnología principal
Fuente: Creación del autor
Figura 2-3: Productos de software por tipo de usuario
Fuente: Creación del autor
0 5 10 15 20 25
Java
Oracle
BI
Visual Basic
Sharepoint
Cloud
Número Aplicaciones
Tecn
olo
gía
0 10 20 30 40 50 60 70 80
Internos al Banco
Externos - Sistema Financiero
Externo - Cultural
Externos - Ciudadanía
Externo - Otros
Número Aplicaciones
Tip
o d
e U
suar
io
Capítulo 2 21
Es importante resaltar que el Banco de la República juega un papel fundamental en el
sistema de pagos del país. De los sistemas relacionados en la Figura 2-3 bajo el tipo de
usuario “Externos – Sistema Financiero” se encuentran los sistemas de información que
son motor para la función de apoyo a los sistemas de pago y prestación de servicios al
sistema financiero. La Figura 2-4 presenta el papel que juegan algunos de los sistemas
de información que han sido relacionados anteriormente en el portafolio de proyectos de
software:
SEN: Sistema Electrónico de Negociación y registro de operaciones con títulos de
deuda pública
DCV: Sistema Depósito Central de Valores. Custodia y administración de títulos de
deuda pública
CUD: Sistema de Cuentas de Depósito. Sistema de pagos de alto valor
CEDEC: Sistema de compensación electrónica de cheques
CENIT: Sistema de compensación electrónica nacional interbancaria
Figura 2-4: Infraestructuras del mercado financiero
Fuente: Reporte de sistemas de pago [20]. Pág. 15.
22 Modelo de Medición y Estimación de Proyectos de Software
2.3 Planeación de proyectos
El portafolio de proyectos de software es reconfigurado anualmente o cada vez que los
objetivos estratégicos del Banco son modificados. Una vez los proyectos o programas de
proyectos son identificados, se procede a realizar la planeación de alto nivel de los mismos.
Dependiendo de la magnitud y criticidad del proyecto se deben surtir ciertos procesos de
aprobación de los componentes en términos presupuestales, de recurso humano e
infraestructura (física y tecnológica). En ciertos proyectos donde los niveles de
incertidumbre son altos en términos del producto a generar o de los requisitos a especificar,
se procede a realizar una fase inicial de estructuración o conceptualización que puede
estar acompañada de una investigación de mercado suficientemente profunda para
determinar además de la viabilidad del proyecto, el alcance adecuado para las
necesidades de la organización.
A continuación se presenta una lista de las herramientas de planeación de proyectos de
software utilizadas desde la identificación del proyecto:
Guía de pre-inversión: documento utilizado en etapa de presupuesto. Es un análisis
de factibilidad para proyectos de determinado monto. Incluye información de
antecedentes, problemática y justificación, objetivo del proyecto, estudio de mercado,
alternativas de solución, evaluación costo/beneficio, conclusiones y recomendaciones.
Solicitud de solución informática: documento utilizado en la etapa de presupuesto
para oficializar una necesidad de tecnología de información por parte de las áreas de
negocio del Banco. Incluye información general, problemática, situación actual,
justificación de la necesidad, descripción preliminar de la solución requerida.
Solicitud de Mantenimiento de software: documento utilizado en la etapa de
presupuesto. Se utiliza para solicitar formalmente el inicio de un proyecto de
mantenimiento de software para la siguiente vigencia. Aplica para sistemas de
información que se encuentren en producción. Incluye información general, objetivos y
metas del proyecto, planeación y alcance, programación de fechas y planeación
financiera.
Formulario de identificación de proyecto: documento exigido para aquellos
proyectos más importantes para el Banco de acuerdo con los ejercicios de priorización
realizados entre la Oficina de Gestión de Proyectos (PMO – Project Management
Capítulo 2 23
Office) del Banco y la DG-T. Incluye información de alto nivel, a nivel de descripción,
objetivos, y alineación estratégica. Este documento tiene sentido en fase de
estructuración/conceptualización del proyecto.
Carta de Constitución: es el documento mediante el cual se autoriza al gerente de
proyectos a utilizar recursos de la organización para llevar a cabo el proyecto. Es una
práctica estándar de la gestión de proyectos. Incluye información general, problemática
y justificación del proyecto, objetivos, metas, alcance, restricciones, supuestos,
presupuesto, estructura organizacional, seguimiento e hitos. Este documento es la
autorización de desarrollo del proyecto.
Plan de proyecto: es el documento que describe como el proyecto será ejecutado,
monitoreado y controlado. Se compone de varios planes subsidiarios tales como (1)
Plan del alcance, (2) Plan de calidad, (3) Plan de gerencia de comunicaciones, (4) Plan
de gerencia de riesgo, (5) Planeación de recursos, (6) Plan de gerencia de
adquisiciones, (7) Plan de control de cambios y (8) Plan de gerencia de configuración.
2.4 Desarrollo de software
Para el desarrollo de software, se utiliza principalmente el modelo de desarrollo en cascada
(Especificación de Requisitos, Diseño, Implementación, Pruebas y Mantenimiento). En
algunas ocasiones se han utilizado metodologías ágiles siguiendo los lineamientos de
SCRUM. En varios proyectos que usan el modelo cascada se han incorporado técnicas y
herramientas usadas en metodologías de ágiles tales como historias de usuario o tableros
Kanban. Igualmente existe una metodología para que los usuarios de las áreas de negocio
desarrollen aplicaciones de baja criticidad sin necesidad de la intervención de la DG-T
cumpliendo ciertas reglas de juego (aplicaciones departamentales) como por ejemplo, el
lenguaje de programación a ser utilizado, los ambientes de desarrollo, pruebas y
producción a ser utilizados y los esquemas válidos para consultar los datos del ambiente
productivo de sistemas corporativos.
2.5 Medición y estimación de software
A continuación se presentan las principales características y aspectos fundamentales de
la forma como se miden y estiman los proyectos de software al interior de la organización.
24 Modelo de Medición y Estimación de Proyectos de Software
2.5.1 Antecedentes
A partir del año 2003 se tomó la decisión de complementar el modelo tradicional de
estimación de software a través de juicio de expertos por un modelo que utilizaba puntos
funcionales siguiendo los lineamientos del IFPUG – International Function Points Users
Group1.
En octubre de 2003 se publicó la metodología de puntos funcionales para realizar la
estimación del tamaño del código de un producto de software [21]. Este documento
metodológico estuvo basado en el estándar del IFPUG publicado para entonces [22] y fue
construido por ingenieros de sistemas del DGI en colaboración con empresas contratistas
desarrolladoras de software. A partir de este momento inició la utilización de los puntos
funcionales para los proyectos de software desarrollados en el DGI. Este documento
metodológico no ha sufrido actualizaciones más allá de algunas que solamente contienen
modificaciones de forma.
2.5.2 Conocimiento
A partir de 2003 inició una estrategia de divulgación y capacitación relacionada con la
medición funcional del software. A continuación se presentan los principales elementos
relacionados con este frente que además han venido promoviendo la construcción del
acervo de conocimiento en temas de medición y estimación de software.
Afiliación empresarial al International Function Points User Group (IFPUG) para
tener acceso a recursos relacionados con medición funcional. El IFPUG es una
organización sin ánimo de lucro que tiene como propósito promover la gestión efectiva
de actividades de desarrollo y mantenimiento de software, a través de estándares de
tamaño de software y otras técnicas de medición de software. El IFPUG respalda dos
estándares de tamaño de software. Uno de ellos es el Function Point Counting
Practices Manual (CPM) [23] el cual es un estándar reconocido en la industria para
realizar Análisis de Puntos Funcionales (FPA por su sigla en inglés) el cual es avalado
por la ISO bajo el estándar ISO/EIC 20926:2009. El segundo es el Software Non-
1 http://www.ifpug.org/
Capítulo 2 25
Functional Assessment Process – SNAP Assessment Practices Manual (APM),
utilizado para hacer medición del componente no-funcional del software. En el portal
de esta comunidad se encuentra información de eventos, posibilidades de certificación
y recursos para descargar (v.g. El manual de conteo por puntos funcionales) y un
magazín periódico relacionado con medición de software (Metric Views).
Afiliación empresarial al International Software Benchmarking Standards Group2
(ISBSG). El ISBSG es una organización sin ánimo de lucro fundada en 1997 por un
grupo de asociaciones de Estados Unidos relacionadas con métricas de software. Su
misión es ayudar a las organizaciones a mejorar la planeación y la gestión de proyectos
de software a través de repositorios de datos de proyectos de desarrollo y
mantenimiento además de reportes y libros relacionados con temas de medición y
estimación de software.
Conformación de un grupo de trabajo para el desarrollo y promoción de la
medición de software al interior del DGI. En el año 2012 se conformó un grupo de 8
ingenieros de sistemas para desarrollar conocimiento alrededor de puntos funcionales
y diseminarlo a los contratistas y áreas de negocio. En esa oportunidad los entregables
fueron documentos relacionados con el perfeccionamiento de las técnicas de medición,
estadísticas, métricas y presentaciones gerenciales para promover la medición
funcional a distintos niveles.
2.5.3 Habilidades y capacidades
Además de las facilidades mencionadas en el apartado anterior, la exposición permanente
a situaciones de medición y estimación de software junto con algunas capacitaciones y
socialización de conocimiento en estos temas han hecho que el personal del DGI
mantenga cierto nivel de competencia en lo relacionado con medición funcional de
software. Existen varios ingenieros que han liderado el tema de medición y estimación.
Estas personas tienen mayor experiencia y se convierten en algunos casos en asesores
que dan soporte a ingenieros que requieren aclarar situaciones específicas con
proveedores o requieren un mayor entendimiento en aspectos puntuales de medición y
estimación de software.
2 http://www.isbsg.org/
26 Modelo de Medición y Estimación de Proyectos de Software
2.5.4 Técnicas
A continuación, se presenta el proceso que sigue el DGI y que está relacionado con la
medición y estimación de software que se realiza para los proyectos de software. La Figura
2-5 muestra el proceso de medición y estimación de proyectos de mantenimiento de
software.
Figura 2-5: Proceso de medición y estimación para mantenimiento de software
Fuente: Creación del autor
El área usuaria crea una solicitud de software que puede ser una corrección a un defecto,
un ajuste al software o una nueva funcionalidad. Esta solicitud generalmente es creada por
el área de negocio y puede tener adjunta información relacionada que en la mayoría de los
casos es un caso de uso o un requisito funcional. En el siguiente paso, el DGI a través del
ingeniero asignado al proyecto, realiza la validación técnica de la solicitud y si es viable y
cumple con los criterios de un requisito de software, la solicitud pasa a un estado “definida”.
Posteriormente el desarrollador, ya sea interno o una firma de outsourcing, analiza la
solicitud, realiza la medición y estimación respectiva y la solicitud queda en el estado
“evaluada”. Eventualmente el DGI puede no estar de acuerdo con la evaluación y puede
iniciar una etapa de conciliación, de lo contrario la solicitud es aprobada por el DGI y puede
iniciar el desarrollo de software (construcción y/o modificación).
La Figura 2-6 presenta el proceso para proyectos nuevos en un escenario en el cual se
han planificado los requisitos detallados (si los requisitos no se tienen especificados desde
InicioCreación de solicitud
de softw are
Validación técnica de
solicitud
Análisis, diseño de
alto nivel, medición y
estimación
Aprobación de la
estimación (duración
y esfuerzo)
Inicio desarrollo
Por conciliarFin
Capítulo 2 27
el inicio del proyecto, el proceso a utilizar es el de mantenimiento anteriormente descrito
por cuanto los requisitos son elaborados gradualmente y se atienden con un enfoque de
solicitudes de software como las presentadas en la Figura 2-5).
Figura 2-6: Proceso de medición y estimación para desarrollo de software
Fuente: Creación del autor
El DGI realiza un conteo de referencia para conocer una estimación del tamaño del
producto de software que desea construir a través de un proceso de contratación con una
firma especializada. Después de liberar una solicitud de propuesta (RFP - Request For
Proposal) al mercado, los potenciales proveedores realizan la medición y posterior
estimación del software solicitado y realizan su mejor propuesta para ser seleccionados.
El Banco a través del DGI y el Departamento de Adquisiciones, realiza la evaluación
técnica y económica y selecciona la propuesta con el mejor índice calidad-precio. Una vez
seleccionado el proveedor, se da inicio al proyecto con una estimación en tiempo, costo y
alcance pactada contractualmente.
Inicio
Especif icación Funcional y
Técnica
Medición interna para
referencia
Liberación del RFP
Proponentes miden y
estiman requerimientos
Proponentes presentan
propuesta
Banco realiza evaluación
técnica y económica
Selección de proveedor
Inicio del proyecto de
desarrollo
Fin
28 Modelo de Medición y Estimación de Proyectos de Software
2.5.5 Herramientas
El DGI cuenta con varias herramientas para dar soporte al proceso de medición y
estimación de proyectos de software tanto para mantenimiento como para nuevos
desarrollos. A continuación se describe cada una de ellas:
Manual de medición de puntos funcionales. Es un manual o guía que proporciona
una descripción detallada de la medición de puntos funcionales que intenta asegurar
que las mediciones son consistentes con las prácticas de medición de los miembros
del IFPUG. Al momento de la elaboración de este documento, la versión más reciente
del manual es la 4.3.1.
Guía rápida de conteo de puntos funcionales. El IFPUG cuenta con una herramienta
de libre distribución que orienta de manera acelerada a un analista o desarrollador en
los elementos significativos del conteo bajo el estándar del IFPUG 4.3.1. Contiene
definiciones, el proceso de medición y las tablas de parámetros necesarias para
realizar el conteo funcional.
Plantilla de Conteo de Puntos Funcionales. Plantilla implementada en MS Excel
para el registro y conteo de puntos funcionales. Está basada en el manual de medición
de puntos funcionales del IFPUG 4.3.1. En esta plantilla se registran los procesos
elementales, los tipos de funciones (de datos y transaccionales) y sus atributos y el
libro MS Excel arroja como resultado el número total de puntos funcionales.
Clear Quest. Herramienta de automatización de flujos de trabajo de IBM. Se configura
en el Banco principalmente como una herramienta de registro y seguimiento a
solicitudes de software (defectos, ajustes, requisitos, etc.). En cada solicitud ya sea de
un proyecto de software nuevo o de mantenimiento es posible registrar el número de
puntos funcionales asociados y adjuntar archivos relacionados con la solicitud.
Metodología de puntos funcionales del Banco de la República. Descrita en el
apartado “2.5.2- Conocimiento” - de este documento.
3. Diagnóstico
Se utilizaron dos herramientas para la recopilación de información relacionada con
medición y estimación de proyectos de software en la organización objeto de estudio.
Posteriormente, se realizó el análisis de resultados y se clasificaron y articularon las
conclusiones.
3.1 Entrevista
Se realizó una entrevista a funcionarios internos y a personal de las empresas contratistas
que brindan servicios de desarrollo de software. Las personas entrevistadas fueron las
siguientes:
Asesor DGI. Responsable de los temas de contratación de desarrollo de software.
Subdirector DTIN. Precursor e impulsor de temas de medición y estimación de
software al interior de la DG-T.
Director de Auditoria Informática. Encargado de los procesos de auditoría de
proyectos y procesos de TI al interior del Banco.
Gerentes de proyectos de empresas contratistas (Dos personas). Gerentes de
empresas de outsourcing quienes prestan servicios al Banco en materia de desarrollo
y mantenimiento de software.
La entrevista fue realizada de forma presencial. Para mayor detalle de la entrevista, se
encuentra disponible en “Anexo: Entrevista sobre medición y estimación de software” de
este documento. La entrevista constaba de once (11) preguntas que abordaban nueve (9)
temas relacionados con medición y estimación de proyectos de software y en su totalidad
fueron preguntas abiertas que pretendían conocer la opinión de expertos en el tema que
desempeñan los siguientes roles:
30 Modelo de Medición y Estimación de Proyectos de Software
Impulsores de la adopción de técnicas de medición y estimación de software.
Gestores del proceso de medición y estimación de software.
Líderes ejecutores de la normatividad existente en materia de medición y estimación.
Líderes que validan el proceso que se lleva a cabo en materia de medición y estimación
y hacen recomendaciones dentro de un proceso de mejoramiento continuo.
3.1.1 Resultados y análisis de la entrevista
A continuación se presentan los principales hallazgos producto de la aplicación de este
primer instrumento de diagnóstico que documenta a un alto nivel las opiniones y
experiencia de las personas directamente relacionadas con temas de medición y
estimación. En la Tabla 3-1 se relacionan las principales conclusiones del análisis de la
entrevista realizada.
Tabla 3-1: Síntesis de la aplicación de la entrevista
No. Tópico Hallazgos
1
Proceso de Medición y estimación a nivel funcional y no-funcional llevado a cabo en la organización
Es un buen deseo pero no ha sido consolidado. No todos los interesados lo practican adecuadamente.
Es una práctica ad-hoc que se aplica en algunos casos y en otros no. No hay uniformidad de criterio al respecto.
No es una práctica institucionalizada. El proceso nunca se consolidó y está dormitando. Hay responsables del proceso pero se desconocen elementos
claves de esa responsabilidad. En muchas oportunidades el componente no-funcional no se
estima. No se registra la historia adecuadamente. No hay acoplamiento de los componentes funcional y no-
funcional. La medición y estimación del componente no-funcional es algo
que falta y que se debe hacer. El esquema actual es endeble. En general, falta conocimiento en temas de medición y
estimación de software.
2
Adopción de técnicas paramétricas para la medición y estimación de la fase de especificación de requisitos
Es interesante pero es complejo en la medida en que es un tema de descubrimiento y de plasmar de forma explícita deseos y necesidades de clientes y usuarios finales.
Puede llegar a ser muy subjetivo. No es fácil estimar el esfuerzo sobre la especificación de un requisito que no es claro incluso para el cliente o usuario final.
Es una buena posibilidad para explorar. Falta conocimiento en todos los involucrados con medición y
estimación para esta fase del software.
Capítulo 3 31
No. Tópico Hallazgos
3
Adopción de técnicas paramétricas para la medición y estimación de la fase de pruebas de software
Es válida y definitivamente se requiere. No se podría medir ni estimar más allá del primer ciclo de
pruebas.
4
Implementación de un repositorio para registrar la gestión de la medición y estimación de proyectos nuevos y de mantenimiento de software
Se requiere documentar la historia de las mediciones y estimaciones de software.
Es importante para tener métodos alternativos de estimación basados en analogía.
Es indispensable para establecer líneas base de medición y estimación de productos de software (v.g. sistemas de información en operación).
5 Medición y estimación en proyectos de mantenimiento de software
Para los proyectos de mantenimiento correctivo de software, puede ser complejo el uso de puntos funcionales del IFPUG.
Se encuentran elementos que dificultan este proceso: Ausencia de documentación (v.g. documentos de diseño de los sistemas), restricciones de tiempo para realizar los ajustes y tecnologías sobre las cuales está construido el software.
6 Contratación de desarrollo de software bajo modelos de puntos funcionales
Se requiere de conocimiento adicional en temas de medición y estimación funcional y no-funcional.
Se debería profundizar en aspectos de productividad y de análisis económico del software.
Según los entrevistados, la industria local no lo utiliza como una práctica reconocida pero debería ser verificado en vista que no existe ningún estudio relacionado.
Se debe contar con una terminología común. Se deben establecer pautas claras de servicio. Se deben establecer pautas claras sobre los entregables.
7
Implantación de herramientas reconocidas en la industria para realizar estimación de proyectos de software
No se conocen estas herramientas por parte de los proveedores de software.
Es necesaria mejorar las mediciones, estimaciones, la productividad y la historia de los proyectos.
Los algoritmos de dominio público pueden ser implementados en hojas electrónicas (v.g. MS Excel).
8 Documentación disponible en la organización
Debe ser actualizada. Es limitada.
9
Nivel de conocimiento tanto del cliente como del proveedor en temas de Medición y estimación de Software
A nivel interno, pocas personas tienen conocimientos sólidos. Cerca de la mitad de los involucrados tiene nociones básicas y
la otra mitad no conoce del tema. A nivel externo (firmas contratistas), el nivel de conocimiento
no es muy alto. Contados casos con un conocimiento aceptable.
3.2 Encuesta
Se realizó una encuesta dirigida a diferentes poblaciones de la organización objeto de
estudio:
32 Modelo de Medición y Estimación de Proyectos de Software
Ingenieros líderes de proyectos que tienen o han tenido contacto con temas de
medición y estimación para proyectos nuevos o de mantenimiento. El número potencial
de encuestados fue de 36 personas.
Analistas de firmas de outsourcing en desarrollo de software: Analistas de negocio y
desarrolladores de software que realizan mediciones y estimaciones de software. El
número potencial de encuestados de este grupo fue de 20 personas.
La encuesta fue diseñada en Qualtrics [24]. Para mayor ilustración, el diseño de la
encuesta se encuentra disponible en “Anexo: Entrevista sobre medición y estimación de
software” de este documento.
3.2.1 Resultados y análisis de la encuesta
En total, la solicitud de diligenciamiento de la encuesta se dirigió a 56 personas que tienen
relación directa con la medición y estimación de software. El número final de personas que
diligenció la encuesta fue 33, que corresponden al 58.9% de la población. A continuación
los principales hallazgos como resultado de la encuesta practicada:
3.2.1.1 Información demográfica
Para los 33 encuestados, la distribución del tipo de organización en la que trabajan es la
presentada en la Tabla 3-2.
Tabla 3-2: Distribución de encuestados por tipo de organización
Tipo
Organización
Porcentaje encuestados
Número
Encuestados
Cliente 57.58% 19
Proveedor de Software
42.42% 14
El 100% de los involucrados en medición y estimación, son ingenieros de sistemas. El
30% de ellos cuenta con estudios de maestría, el 42% con especialización y el 24%
solamente con pregrado. Hay una persona con estudios de doctorado (ver Figura 3-1)
Capítulo 3 33
Figura 3-1: Nivel educativo de los entrevistados
Fuente: Encuesta Qualtrics.
Los dos rangos de edades más representativos se encuentran entre los 30 y 35 años
(49% de los encuestados) y más de 45 años (21% de los encuestados). Ver la Figura
3-2 para conocer otros rangos de edades de los entrevistados.
Figura 3-2: Edades de los entrevistados
Fuente: Encuesta Qualtrics.
El 72% de los encuestados son hombres y el 28% mujeres.
Cerca del 60% de los encuestados tiene más de 5 años de experiencia en análisis,
diseño y desarrollo de software. En cuanto a medición y estimación de software, la
experiencia se presenta en la Tabla 3-3.
Tabla 3-3: Experiencia en medición y estimación de software
Experiencia Porcentaje encuestados
Número
Encuestados
Sin experiencia 3% 1
0-1 años 9% 3
34 Modelo de Medición y Estimación de Proyectos de Software
Experiencia Porcentaje encuestados
Número
Encuestados
1-2 años 21% 7
2-3 años 24% 8
3-4 años 21% 7
Más de 5 años 21% 7
3.2.1.2 Medición funcional del software
Las técnicas de medición más reconocidas son la medición funcional utilizando el
método del IFPUG (24 de los encuestados) y Líneas de Código (20 de los
encuestados). En contados casos y posiblemente por desconocimiento o confusión,
algunos encuestados respondieron que conocen métodos de medición tales como
COCOMO o Casos de Uso, los cuales no son técnicas de este tipo (ver Figura 3-3).
Figura 3-3: Estándares de medición reconocidos
Fuente: Encuesta Qualtrics.
Aproximadamente el 50% de los encuestados tiene menos de dos años de experiencia
en este tipo de actividades. El otro 50% tiene 3 años o más. Cerca del 75% de los
encuestados ha realizado medición y estimación de software en máximo 3 proyectos
(ver Figura 3-4).
Capítulo 3 35
Figura 3-4: Experiencia de los entrevistados en medición funcional
Fuente: Encuesta Qualtrics.
Las mayores dificultades que se encuentran en la aplicación de reglas de medición
funcional son las presentadas en la Tabla 3-4 (en orden de importancia):
Tabla 3-4: Dificultades en la aplicación de reglas de medición funcional
Dificultad Porcentaje
No funcionan para todos los tipos de software existentes 51,61%
Las reglas son ambiguas y dependen de la opinión del contador 41,94%
Los requisitos no tienen la calidad apropiada 38,71%
El vocabulario de las reglas no es apropiado y/o confuso 29,03%
La curva de aprendizaje es muy larga y toma mucho tiempo su aplicación 29,03%
Se requiere conocimiento del negocio 25,81%
Los ejemplos documentados no son prácticos 25,81%
El manual oficial es diferente a la documentación on-line existente 6,45%
Es difícil tener acceso a documentación de Puntos Funcionales 3,23%
El 75% de los encuestados ha recibido entrenamiento en medición funcional. En
promedio este entrenamiento ha sido de 6.3 horas (promedio ponderado basado en las
respuestas).
Solamente 4 de los 33 encuestados (12%) ha contado más de 2000 puntos funcionales.
Esta cifra resulta particularmente importante debido a que en la industria de la medición
36 Modelo de Medición y Estimación de Proyectos de Software
de software se requiere, por ejemplo, haber contado mínimo 2500 puntos funcionales
como requisito obligatorio para presentar el examen de una de las certificaciones más
reconocidas en la actualidad en materia de medición, como lo es la ofrecida por el
IFPUG, denominada Especialista Certificado en Puntos Funcionales (CFPS-Certified
Function Point Specialist). Este hecho es consecuente con las expectativas de los
encuestados en materia de certificaciones. Solamente el 9% de los encuestados tiene
un interés en conseguir certificaciones de este tipo.
No se conocen enfoques más efectivos de medición de software. El 9% de los
encuestados menciona que el juicio de expertos es más efectivo que la medición de
software basada en funcionalidad.
Un 71% de los encuestados afirman que la medición funcional es más apropiada para
nuevos proyectos mientras que el 29% restante cree que es útil tanto en proyectos de
nuevos desarrollos como en proyectos de mantenimiento.
Solamente el 25% de los encuestados conoce o ha aplicado el estándar del IFPUG.
Cerca del 75% de los restantes no reconoce la sigla ni el estándar que soporta esta
organización.
3.2.1.3 Medición no-funcional del software
El 94% de los encuestados aplica juicio de expertos para la medición no-funcional del
software. Solamente uno de los encuestados aplica un modelo propietario y otro de
ellos no utiliza métodos de medición para este componente del software. A excepción
de uno de los encuestados, no existen planes de alcanzar alguna certificación en este
sentido (ver Figura 3-5 y Figura 3-6).
Capítulo 3 37
Figura 3-5: Conocimiento en estándares de medición no-funcional
Fuente: Encuesta Qualtrics.
Figura 3-6: Enfoque utilizado para realizar medición no-funcional
Fuente: Encuesta Qualtrics.
3.2.1.4 Estimación de software
El modelo más reconocido para estimación de software es COCOMO II (42%) También
son conocidos modelos de Regresión (13%) y Planning Poker (16%). El 31% de los
encuestados no conoce ningún método de estimación de software (ver Figura 3-7).
El 90% de los encuestados utiliza juicio de expertos para estimar tiempo, duración y
esfuerzo para la construcción del software. Curiosamente, el 10% restante afirma que
utiliza el método de puntos funcionales, el cual no es un método de estimación sino de
medición de software.
38 Modelo de Medición y Estimación de Proyectos de Software
Figura 3-7: Técnicas reconocidas de estimación de software
Fuente: Encuesta Qualtrics.
3.2.1.5 Otros aspectos
El 65% de los encuestados considera que la documentación disponible en la
organización en materia de medición y estimación no es suficiente. Un 7% de los
encuestados no conoce la documentación asociada (ver Figura 3-8).
Figura 3-8: Opinión sobre suficiencia en la documentación existente
Fuente: Encuesta Qualtrics.
Un 61% de los encuestados considera que la documentación existente sobre medición
y estimación es útil y tiene aplicación mientras que el 39% restante opina lo contrario,
es decir, la documentación disponible no es útil.
Capítulo 3 39
El 90% de los encuestados considera que se deberían implementar técnicas de
medición y estimación para la fase de especificación de requisitos. Algunas de las
razones son:
o Serviría como elemento de referencia.
o Todas las fases de la ingeniería de software deberían medirse y estimarse.
o Es una forma de mejorar la calidad de los requisitos.
o Se optimizarían los recursos.
o Ayudaría a contar con un modelo integral de medición y estimación.
o Eliminaría posiciones subjetivas en términos de esfuerzo en la especificación
de requisitos.
o Permitiría el establecimiento de métricas para mejoramiento continuo.
o Ayudaría a controlar tiempos y costos asociados.
o Mejoraría la planeación y control del presupuesto de los proyectos.
El 97% de los encuestados considera que se deberían implementar técnicas de
medición y estimación para la fase de pruebas de software. Algunas de las razones
son:
o Por estandarización.
o Para medir el ciclo de vida de forma integral.
o Parta planear y controlar las pruebas realizadas por una firma independiente
o Para tener mecanismos alternativos a los ofrecidos por empresas que prueban
software.
o Para definir métricas.
o Para planear y controlar de mejor forma los presupuestos de los proyectos.
o Para tener valores de referencia.
3.3 Análisis DOFA
A continuación se presenta un análisis de Debilidades-Oportunidades-Fortalezas-
Amenazas basado en (1) los resultados de la observación directa del autor, (2) la
documentación recopilada, (3) la entrevista realizada y (4) la encuesta aplicada.
40 Modelo de Medición y Estimación de Proyectos de Software
Tabla 3-5: Análisis DOFA – Debilidades
Debilidades
Se desconocen aspectos fundamentales de medición y estimación de proyectos de
software tanto a nivel interno como a nivel externo (compañías que brindan servicios
de desarrollo de software en un modelo de outsourcing).
El cuerpo de conocimiento de la medición basada en puntos funcionales no está
interiorizado en muchos de los involucrados en temas de medición y estimación.
No existen métodos diferentes al juicio de expertos para la medición y estimación del
componente no-funcional del software.
No existe un repositorio para registrar la historia de las mediciones y estimaciones de
software.
No se realiza medición y estimación para la fase de especificación de requisitos.
No existe un método formal de medición y estimación para la fase de pruebas de
software.
La documentación sobre medición y estimación de software no es utilizada y requiere
actualizaciones.
Hay subjetividad marcada en la medición y estimación realizada.
El mantenimiento correctivo de software no utiliza métodos paramétricos de medición
y estimación.
Tabla 3-6: Análisis DOFA - Oportunidades
Oportunidades
Crear un programa de entrenamiento/capacitación relacionado con medición y
estimación de software.
Reforzar a nivel de proceso y de documentación el cuerpo de conocimiento de puntos
funcionales del IFPUG utilizado en la organización.
Contar con un esquema de medición y estimación del componente no-funcional del
software que esté acoplado a la medición del componente funcional.
Explorar la posibilidad de implementar un esquema de medición y estimación de la
fase de especificación de requisitos.
Implementar un esquema de medición y estimación para la fase de pruebas de
software.
Contar con un léxico común en materia de medición y estimación de software.
Complementar la documentación existente en materia de medición y estimación de
software.
Explorar la posibilidad de contar con un esquema de medición y estimación
paramétrico para proyectos de mantenimiento correctivo, adaptativo y preventivo.
Capítulo 3 41
Tabla 3-7: Análisis DOFA - Fortalezas
Fortalezas
Interés de la organización en la implementación de un modelo integral de medición y
estimación de software.
Uso de medición funcional por más de 10 años utilizando el método del IFPUG.
Afiliación a los dos grupos de interés de mayor reconocimiento a nivel internacional:
ISBSG e IFPUG.
Se establecen contratos de desarrollo y mantenimiento de software que manejan
acuerdos de servicio en términos de medición funcional y productividad basada en
puntos funcionales del IFPUG.
Tabla 3-8: Análisis DOFA - Amenazas
Amenazas
Juicio de expertos como único método de estimación no-funcional del software. En la
mayoría de casos el estimador es el mismo experto y en situaciones específicas
carece de la experiencia necesaria para realizar estimaciones con márgenes de error
aceptables.
La documentación desactualizada y en algunos casos incompleta, induce a la
aplicación errónea de principios de medición y estimación.
La falta de un modelo integral de medición y estimación además de la ausencia de un
repositorio para almacenar la historia de medición y estimación no permite tener
certeza absoluta de indicadores de calidad, tiempos y costos asociados al desarrollo
de software.
Cada vez se impone en mayor medida el uso del juicio de expertos para realizar la
estimación del esfuerzo, con el riesgo que esto conlleva.
3.4 Conclusiones del diagnóstico
A continuación se presentan las principales conclusiones del diagnóstico llevado a cabo
en materia de medición y estimación de software..
Si bien existieron en el pasado esfuerzos relacionados con la implementación de un
modelo de medición y estimación de software, la rotación de las personas y los
instrumentos fragmentados que comenzaron a operar, contribuyeron a que las actividades
relacionadas con medición y estimación de software se realizaran de forma parcial sin un
evidente beneficio para la organización.
42 Modelo de Medición y Estimación de Proyectos de Software
Al no existir un común denominador en cuanto al conocimiento de estándares, técnicas y
herramientas asociadas a la medición y estimación de software, para algunos, este
conjunto de actividades no se percibe como una herramienta de planeación y optimización
de proyectos sino como una tarea adicional que no agrega valor al proceso de ingeniería
de software.
La falta de conocimiento, de entrenamiento permanente y de investigación alrededor de
temas de medición y estimación (tanto a nivel interno como externo a través de las
empresas de outsourcing en desarrollo de software) permite que los conteos de software
y las posteriores estimaciones sean subjetivos y que dependan en muchos casos de las
personas que realizan la actividad. Ejemplo de ello, es la situación en la cual para un mismo
escenario de medición que es realizado por dos grupos de personas diferentes, los
resultados pueden diferir hasta en un 100%. Esto trae como consecuencia una pérdida de
credibilidad en la técnica por una mala aplicación de la misma.
Al ser fragmentado el ejercicio de medición y estimación de software, teniendo solamente
cierta fortaleza en la medición de puntos funcionales, las mediciones y estimaciones de
otras fases del ciclo de desarrollo como por ejemplo la medición no-funcional y las pruebas
de software, se manejan con técnica de juicio de expertos que se realiza de forma
imperfecta, en la medida en que muchos de los involucrados en la aplicación de esta
técnica no son expertos ni en la tecnología ni el negocio relacionado con el software.
Se hace necesario hacer una revisión de herramientas que apoyen las labores de medición
y estimación de software en lo referente a (1) repositorios de medición y estimación de
proyectos de software y (2) herramientas de estimación de software que implementan
modelos públicos y propietarios.
En materia de contratación de desarrollo de software, se podrían revisar referentes
internacionales para complementar el ejercicio que se está desarrollando en la
organización.
Es importante contar con un modelo integral de medición y estimación de software que
articule las principales fases de la ingeniería de software, esto es, la especificación de
Capítulo 3 43
requisitos, la construcción y las pruebas del software. Este modelo debe aplicar tanto para
proyectos de nuevos desarrollos como para mantenimiento de software.
4. Marco conceptual
Esta segunda parte de la investigación comprende el estado del arte en temas de medición
y estimación de software a nivel académico y de industria. Está enfocado en los aspectos
relacionados con los hallazgos descritos en el capítulo “3 - Diagnóstico”. Se abordan los
temas relacionados con medición y estimación funcional y no-funcional del software
además de medición y estimación de otros componentes del ciclo del desarrollo de
software tales como especificación de requisitos y pruebas de software.
4.1 Medición de software
4.1.1 Introducción a la medición
La medición de software es un componente esencial de la ingeniería de software. Algunos
autores como Fenton y Bieman afirman que sin medición la tecnología no puede funcionar,
pues se requiere en muchas esferas que gobiernan nuestras vidas [25]. La medición nos
ayuda a entender nuestro entorno, como interactuar con el medio y mejorar la forma en
que vivimos. Los mencionados autores, definen la medición como el proceso por medio
del cual números o símbolos son asignados a atributos (características) de entidades
(objetos) del mundo real con el fin de describirlos de acuerdo con reglas claramente
definidas [25]. Ejemplos de aplicación de esta definición pueden ser la estatura, inteligencia
o el grado de alcohol de una bebida. La exactitud de la medida depende tanto del
instrumento de medición como también de la misma definición de medición. Existen
definiciones alternativas como por ejemplo la de Hubbard [26] que define la medición como
una reducción cuantitativa de la incertidumbre basada en una o más observaciones.
La medición en la ingeniería de software se ha convertido en un elemento comúnmente
aceptado: en la medida en que los proyectos son fallidos o no cumplen sus objetivos de
alcance, tiempo y costo, se han buscado nuevas técnicas y herramientas para mejorar
46 Modelo de Medición y Estimación de Proyectos de Software
tanto el proceso como los productos generados. El alcance de las métricas de software es
amplio, pero en lo que se refiere a esta investigación, el aspecto más relevante tiene que
ver con la medición como elemento esencial para la estimación de costo, duración y
esfuerzo en proyectos de software.
4.1.2 Historia y evolución de la medición de software
La industria del software tiene aproximadamente 70 años de vida, lo cual indica que es una
industria de cierta forma madura. A continuación, se relaciona la evolución en medición de
software según los aportes de Jones [27].
Entre 1947 y 1957 la mayoría de las aplicaciones eran pequeñas: La gran mayoría de ellas
tenían un tamaño menor a 1.000 líneas de código fuente (SLOC – Source Lines Of Code).
Los primeros intentos de medir productividad y calidad usaron líneas de código que de una
u otra forma fueron efectivos y cumplieron su objetivo. La codificación tomaba cerca del
50% del esfuerzo en la construcción de la aplicación, la depuración y las pruebas cerca de
un 40% y todas las demás actividades el 10% restante.
Entre 1957 y 1967 los lenguajes de programación de bajo nivel como ASSEMBLER
comenzaron a ser reemplazados por lenguajes procedimentales tales como COBOL y
FORTRAN. Los computadores comenzaron a ser aplicados a funciones de negocio entre
las que se destacan la banca y la manufactura. El tamaño de las aplicaciones creció de
1.000 SLOC hasta 100.000 SLOC. Debido al cambio de los lenguajes de programación,
comenzaron a presentarse inconvenientes con la métrica basada en SLOC. Al final de este
periodo, el esfuerzo en el desarrollo de aplicaciones cayó al 30% mientras que la
especificación de requisitos, planeación y documentación se acercó al 40%. Las pruebas
y depuración conformaban el 30% restante.
A mediados de los años 70, fueron más evidentes los problemas relacionados con métricas
basadas en SLOC. Los lenguajes de programación de alto nivel incrementaban la
productividad y calidad del desarrollo. En este momento apareció la paradoja de SLOC:
Las líneas de código penalizan los lenguajes de alto nivel y favorecen los lenguajes de
bajo nivel. A continuación un ejemplo donde se evidencia la paradoja en mención:
Capítulo 4 47
Paradoja de la productividad
Asuma que tiene dos aplicaciones idénticas, una desarrollada en ASSEMBLER y
la otra en COBOL. La versión de ASSEMBLER tiene 10.000 SLOC y la versión de
COBOL 3.000 SLOC. Por un lado, parecería que la aplicación de 10.000 SLOC
tiene un mayor tamaño que la de 3.000 SLOC, sin embargo la funcionalidad es
idéntica.
Así mismo, si en la primera aplicación el desarrollador #1 invirtió 10 meses en su
construcción tendría una productividad de 1.000 SLOC x Mes. Para la segunda
aplicación, el desarrollador #2 que invirtió 6 meses en su construcción (debido a
las ventajas que puede tener la utilización de un lenguaje de alto nivel) tendría una
productividad de 500 SLOC x Mes. Lo anterior indica que el desarrollador #1 es
más productivo que el desarrollador #2 así el tiempo de desarrollo haya sido inferior
en el caso de la segunda aplicación (desarrollador #2).
Los problemas antes mencionados que tenían un impacto económico, es decir, en el costo
del software, condujeron a que IBM asignara a Allan Albrecht y otras personas para que
intentaran desarrollar una métrica de software que fuera independiente de los volúmenes
de código y pudiera medir productividad y calidad sin distorsión. Después de varios años
de esfuerzo, más exactamente en 1979, Albrecht y sus colegas propusieron una nueva
métrica que llamaron “Puntos de Función” o “Puntos Funcionales” (Function Points en
inglés) [28].
4.1.3 Medición del tamaño del software
Con la llegada de la industria del desarrollo de software a gran escala en la mitad de los
años sesenta, la comunidad de la ingeniería de software reconoció la necesidad de contar
con un mejor control sobre los aspectos económicos de la producción y mantenimiento de
software. Un aspecto clave era entender la forma como se podía cuantificar el software
como resultado de un proceso complejo y de esta forma tener un mejor entendimiento y
gestión sobre las múltiples facetas de su producción [29]. Según Trendowicz y Jeffery [2],
el tamaño del software es el principal conductor para la estimación del esfuerzo en su
construcción, esto es, la mayoría de los modelos de estimación para el cálculo del esfuerzo
en términos de tiempo y recursos están dados por el tamaño del software. Existen dos
48 Modelo de Medición y Estimación de Proyectos de Software
tipos de tamaño del software reconocidos en la industria: El funcional y el no-funcional.
Algunos autores como Abran [29] llaman a este último el tamaño técnico.
El tamaño funcional del software es usado para medir el producto de software desde una
perspectiva de usuario. Es independiente de decisiones técnicas de desarrollo e
implementación y puede ser usado para comparar la productividad de diferentes técnicas
y tecnologías [29]. Otros autores como Bundschuh y Dekkers [3] definen el tamaño
funcional como “un tamaño del software derivado por la cuantificación de los requisitos
funcionales de usuario”. En este contexto, los requisitos funcionales de usuario (FUR-
Functional User Requirements) son a su vez definidos como un subconjunto de los
requisitos de usuario, que describen lo que el software debe hacer en términos de tareas
y servicios (el “Qué” debe hacer el software).
El tamaño no-funcional es usado para medir el producto de software desde una perspectiva
de desarrollador. Generalmente aborda aspectos relacionados con atributos de calidad
tales como seguridad, desempeño, confiabilidad, mantenibilidad y portabilidad entre otros
(el “Cómo” lo debe hacer el software).
4.1.4 Medición funcional
El aporte de Allan Albrecht a partir de 1979 estuvo basado en la medición funcional [30].
Su contribución más importante fue cambiar el paradigma de medición de líneas de código
por un método para calcular el tamaño de software que fuera independiente del lenguaje
de programación utilizado.
En 1984 se conformó el International Function Point Users Group (IFPUG) cuyo objetivo
era promover la evolución del método de los puntos funcionales. Una de las principales
contribuciones del IFPUG ha sido la documentación de las reglas de medición para el
mejoramiento del nivel de uniformidad en la aplicación del método de los puntos
funcionales. El cuerpo de conocimiento que recoge los fundamentos, la estructuración del
método, las reglas de conteo y ejemplos de aplicación se encuentran en el Function Point
Counting Practices Manual (CPM) que fue actualizado por última vez en el año 2010 [31].
En los últimos años se han desarrollado estándares de industria basados en puntos
funcionales. La variedad de estándares depende de la región de aplicación, de la
Capítulo 4 49
organización que lo promueve o del tipo de sistema más apropiado de medir con cada
estándar (v.g. sistemas embebidos, sistemas de información de negocio, bodegas de
datos, etc.). A continuación se listan los principales estándares a la fecha que están
relacionados con medición funcional:
ISO/IEC 14143-1:2012. Functional size measurement [32].
ISO/IEC 20926:2009. IFPUG functional size measurement method [33].
ISO/IEC 24570:2005. NESMA functional size measurement method, versión 2.1 [34].
ISO/IEC 29881:2010. FiSMA 1.1 functional size measurement method [35].
ISO/IEC 20968:2002. MK II Function Point Analysis – Counting Practices Manual [36]
ISO/IEC 19761:2011. COSMIC: A functional size measurement method [37].
La medición del tamaño funcional es independiente de los requisitos no-funcionales,
incluyendo la tecnología usada para su implementación. Los aspectos tecnológicos (el
“Cómo”) del desarrollo de software no son parte del tamaño funcional.
4.1.4.1 Puntos funcionales
El método más reconocido a nivel mundial en términos de medición funcional es el de
puntos funcionales del IFPUG. Las reglas de medición se encuentran documentadas en el
Manual de Prácticas de Conteo (CPM-Counting Practices Manual). La aplicación principal
del CPM es la medición de nuevos desarrollos y mejoras de software [3]. Se debe tener
disponible la siguiente información para realizar un proceso de conteo de puntos
funcionales:
Las salidas producidas por la aplicación
Las entradas que atraviesan la frontera de la aplicación
Los archivos internos de datos que son mantenidos por la aplicación
Entidades y relaciones entre los datos
Consultas de datos que pueden ser solicitados por la aplicación
Interfaces entre la aplicación y otras aplicaciones
Interfaces entre la aplicación y sus usuarios
Procesos claves que ejecuta la aplicación
50 Modelo de Medición y Estimación de Proyectos de Software
Figura 4-1: Proceso general de conteo de puntos funcionales
Fuente: IFPUG - Function Point Counting Practices Manual [31]. Pág. 39.
El proceso de conteo de puntos funcionales se presenta en la Figura 4-1. A continuación
se describen a nivel general los pasos del proceso.
Recopilar documentación disponible. Toda la documentación relacionada con el
software a construir o mejorar.
Definir el alcance del conteo, la frontera e identificar los requisitos funcionales
de usuario. Existen tres tipos de conteo: (1) nuevos desarrollos, (2) Mejoras al software
y (3) Conteo sobre la aplicación. Se debe establecer la diferencia entre el tamaño del
proyecto de software y el tamaño de la aplicación. Esta diferenciación ayuda a
establecer cual funcionalidad requiere ser contada dentro del proyecto y cuál debe ser
contada por aplicaciones externas. La frontera de la aplicación se establece desde el
punto de vista del usuario. En la Figura 4-2 se presenta un ejemplo de lo que significa
la frontera de la aplicación además de otros de los principales elementos del marco de
referencia.
Medir las funciones de datos. Medir la funcionalidad proporcionada al usuario para
satisfacer los requisitos de almacenamiento de datos internos y externos. Son archivos
lógicos (ILF-Internal Logical FIle) o archivos de interfaz (EIF-External Interface File). La
Tabla 4-1 describe en mayor detalle este tipo de funciones.
Medir las funciones transaccionales. Medir la funcionalidad proporcionada al usuario
para procesar datos. Son entradas de datos (EI-External Input), salidas externas (EO-
External Output) o consultas externas (EQ-External Inquiry). La Tabla 4-1 describe en
mayor detalle este tipo de funciones.
Capítulo 4 51
Calcular el tamaño funcional. Representa el tamaño del software resultante de la
cuantificación de los requisitos funcionales de usuario. El tamaño funcional se calcula
mediante la medida de funciones de datos y funciones transaccionales.
Documentar y reportar. El conteo de puntos funcionales debe ser documentado en
todos los aspectos anteriormente descritos. El reporte consiste en generar los
resultados del conteo de puntos funcionales para permitir a los lectores conocer el
tamaño y el estándar que fue utilizado. Por ejemplo:
)2009:20926/(250 EICISOIFPUGFPTamaño
Que indica que el tamaño del producto de software medido es de 250 puntos
funcionales utilizando el estándar IFPUG-ISO/EIC20926 de 2009.
Figura 4-2: Definición de la frontera de la aplicación
Fuente: The IT Measurement Compendium [3]. Pág. 71.
En la Figura 4-2 se observa la frontera de la aplicación tanto para el usuario como para
otras aplicaciones. Es entendida como una interfaz conceptual entre el software bajo
estudio y el usuario (el cual puede ser un usuario final u otra aplicación).
52 Modelo de Medición y Estimación de Proyectos de Software
Tabla 4-1: Tipos de funciones del método IFPUG
Funciones
de Datos
ILF
Internal Logical Files. Archivos internos de datos con sus
registros y elementos de datos; los datos son mantenidos dentro
de la frontera de la aplicación por el software bajo consideración.
EIF
External Logical Files. Interfaces externas con sus registros y
elementos de datos; los datos son mantenidos fuera de la frontera
de la aplicación (son mantenidos por otras aplicaciones). Estas
interfaces son referenciadas por el software bajo consideración.
Funciones
Transaccionales
EI External Inputs. Funciones de entradas externas con sus grupos
de datos y elementos de datos. Son procesos elementales.
EO External Outputs. Funciones de salidas externas con sus grupos
de datos y elementos de datos. Son procesos elementales.
EQ External Outputs. Funciones de consultas externas con sus
grupos de datos y elementos de datos. Son procesos elementales.
Cada una de las funciones descritas en la Tabla 4-1 (datos y transaccionales) debe ser
clasificada de acuerdo con su complejidad. El IFPUG define tres (3) tipos de complejidad:
Alta, Promedio y Baja (High, Average, Low). La Tabla 4-2, Tabla 4-3, Tabla 4-4, Tabla 4-
5 y Tabla 4-6 muestran los diferentes niveles de complejidad dependiendo del número de
registros/grupos de datos y del número de elementos de datos para cada función de datos
y transaccional. Los conceptos de FTR (File Type Referenced), RET (Record Element
Type) y DET (Data Element Type) son definidos en el glosario del documento.
Tabla 4-2: Puntos Funcionales para EI’s
Tipos de Archivos Referenciados (FTR)
Elementos de Datos
1-4 5-15 Más de 15
Menos de 2 Low (3) Low (3) Average (4)
2 o 3 Low (3) Average (4) High (6)
Más de 3 Average (4) High (6) High (6)
Tabla 4-3: Puntos Funcionales para EO’s
Tipos de Archivos Referenciados (FTR)
Elementos de Datos
1-5 6-19 Más de 19
Menos de 2 Low (4) Low (4) Average (5)
2 o 3 Low (4) Average (5) High (7)
Más de 3 Average (5) High (7) High (7)
Capítulo 4 53
Tabla 4-4: Puntos Funcionales para EQ’s
Tipos de Archivos Referenciados (FTR)
Elementos de Datos
1-5 6-19 Más de 19
Menos de 2 Low (3) Low (3) Average (4)
2 o 3 Low (3) Average (4) High (6)
Más de 3 Average (4) High (6) High (6)
Tabla 4-5: Puntos Funcionales para ILF’s
Tipos de Registros de Elementos (RET)
Elementos de Datos
1-19 20-50 Más de 50
Menos de 2 Low (7) Low (7) Average (10)
2 o 3 Low (7) Average (10) High (15)
Más de 3 Average (10) High (15) High (15)
Tabla 4-6: Puntos Funcionales para EIF’s
Tipos de Registros de Elementos (RET)
Elementos de Datos
1-19 20-50 Más de 50
Menos de 2 Low (5) Low (5) Average (7)
2 o 3 Low (5) Average (7) High (10)
Más de 3 Average (7) High (10) High (10)
En versiones anteriores de este método, se realizaba un paso adicional denominado
“cálculo de los puntos funcionales ajustados” por cuanto los análisis mostraban que no
había una correlación fuerte entre los puntos funcionales sin ajustar (UFP-Unajusted
Function Points) y el esfuerzo requerido para entregar el producto. En un intento por
resolver esta discrepancia, el método IFPUG usó una serie de características generales
del sistema (GSC-General Systems Characteristics) para modificar el UFP en un factor de
ajuste denominado VAF (Value Adjustment Factor) derivado de las respuestas a un
conjunto de preguntas enfocadas en requisitos no-funcionales del proyecto [38].
A partir de 2010 está práctica de ajustar los puntos funcionales en un factor calculado,
comenzó a reemplazarse por un nuevo enfoque basado en la medición del componente
no-funcional del software. A continuación y únicamente a manera de ilustración, la
Tabla 4-7 presenta las catorce (14) características generales del sistema que se utilizaban
para ajustar los puntos funcionales. El método consistía en puntuar cada uno de los catorce
aspectos en una escala de 0 a 5. Posteriormente, se sumaban los puntajes que constituían
54 Modelo de Medición y Estimación de Proyectos de Software
el VAF. La sumatoria de los grados de influencia de cada una de las características se
denomina Total Degree of Influence (TDI). El valor del TDI puede oscilar entre 0 y 70.
Tabla 4-7: Características Generales del Sistema
No. Factor de Ajuste
1 Comunicaciones de datos
2 Procesamiento de datos distribuido
3 Desempeño
4 Ambiente operacional
5 Tasa de transacciones
6 Entrada de datos en línea
7 Eficiencia para el usuario final
8 Actualización en línea
9 Complejidad en el procesamiento
10 Reusabilidad
11 Facilidad de instalación
12 Facilidad de operación
13 Operación en múltiples sitios
14 Facilidad de cambio
La fórmula tradicional3 para calcular los puntos funcionales ajustados se muestra a
continuación:
Cálculo del VAF:
65,0)01,0( TDIVAF
Dónde:
VAF: Valor del Factor de Ajuste.
TDI: Total Degree of Influence. Sumatoria de todas las características generales del
sistema.
3 Existen fórmulas adicionales que dependen del tipo de proyecto. Para efectos de ilustración únicamente se muestra la fórmula para un proyecto de nuevo desarrollo de software en vista que es esta práctica de hallar un VAF no es muy utilizada actualmente entre otras por la subjetividad en su cálculo.
Capítulo 4 55
Cálculo de los Puntos Funcionales Ajustados:
VAFUFPDFP
Dónde:
DFP: Puntos Funcionales Ajustados
UFP: Puntos Funcionales sin Ajustar
VAF: Valor del Factor de Ajuste.
La descripción completa de las reglas de conteo de puntos funcionales (FSM – Functional
Size Measurement) además de ejemplos y léxico relacionado se puede encontrar en el
Function Point Counting Practices Manual Release 4.3.1 [31].
4.1.4.2 Medición no-funcional
La medición no-funcional del software se refiere a la medición del componente técnico.
Generalmente hace referencia a todos los elementos que tienen que ver con atributos de
calidad y restricciones técnicas del software.
Los atributos de calidad son requisitos del sistema expresados en términos de
escalabilidad, disponibilidad, facilidad de cambio, portabilidad, usabilidad y desempeño
entre otros. Abordan aspectos relacionados con requisitos de la mayoría de los
stakeholders del sistema: usuarios finales, equipo de ingeniería, equipo del proyecto y
sponsors.
Las restricciones técnicas limitan las opciones técnicas especificando determinadas
tecnologías que el software debe usar. Generalmente no son negociables. Algunos
ejemplos incluyen:
"El sistema debe ser desarrollado en Java"
"La base de datos Oracle debe ser 12c o superior y se debe ejecutar en Solaris 11”
"Debe existir una integración con el sistema CRM"
"A partir del 2018 el middleware será Open Source debido a los altos costos del
proveedor actual"
56 Modelo de Medición y Estimación de Proyectos de Software
"Todos los reportes de tipo financiero que sean generados por el nuevo sistema deben
integrarse en la solución ECM de acuerdo con las políticas de gestión de información
establecidas a partir del año 2017"
El siguiente apartado presenta el tipo de medición no-funcional más reconocido en la
actualidad en la industria: El método de SNAP Points.
4.1.4.3 SNAP Points
En la conferencia ISMA4 de 2008 se lanzó una primera versión del framework para la
medición de los requisitos no-funcionales del software. Este fue el nacimiento de SNAP
Points, sigla en inglés para “Software Non-Functional Assessment Process”. En marzo de
2010 fue lanzado el Manual de Prácticas de Valoración (APM-Assessment Practices
Manual) [39].
SNAP define un marco de referencia y un método para determinar el tamaño no-funcional
y establecer un enlace entre este tamaño y el esfuerzo sin la utilización de las GSCs. El
framework utiliza definiciones y terminología de organizaciones tales como IEEE, ISO e
IFPUG y reutiliza definiciones y terminología del framework del tamaño funcional.
SNAP es utilizado independiente de la medición funcional, con lo cual los datos
tradicionales de puntos funcionales no son impactados. El tamaño funcional incluye
aspectos técnicos y de calidad que pueden ser desarrollados en varios niveles
dependiendo de la exactitud de los resultados requeridos. El proceso SNAP tiene las
siguientes características [38]:
Los requisitos no-funcionales dentro de una aplicación son valorados usando varias
subcategorías agrupadas dentro de categorías lógicas.
La distinción entre requisitos no-funcionales y las categorías lógicas que son usadas
para medir el tamaño deben ser comprensibles para los usuarios SNAP.
Las categorías no describen los requisitos no-funcionales; por lo tanto, ellas no
reemplazan ni explican los estándares que describen y clasifican los requisitos no-
funcionales (tales como ISO 9126) [40].
4 Conferencia anual del IFPUG
Capítulo 4 57
Las categorías y subcategorías describen como los proyectos serán valorados o como
los productos cumplirán esos requisitos no-funcionales.
Los resultados SNAP (llamados SNAP Points) tienen las siguientes características [38]:
Pueden ser usados en conjunto con el tamaño funcional y ayudan a explicar el esfuerzo
adicional requerido para cumplir los requisitos no-funcionales.
Junto con el tamaño funcional, ellos pueden ser usados como entrada a los modelos
de estimación de software.
Son determinados desde una perspectiva de usuario no-funcional pero entendidos y
aceptados por los usuarios funcionales.
La Figura 4-3 presenta el proceso de valoración SNAP que obtiene como resultado final
las Unidades de Conteo SNAP (SCU- SNAP Counting Units).
Figura 4-3: Proceso de Valoración SNAP
Fuente: Software Non-Functional Assessment Process [38]. Pág. 500.
A continuación y únicamente a manera ilustrativa, se presenta en la Tabla 4-8 un resumen
de las categorías y subcategorías utilizadas en el modelo de valoración SNAP. Cada
categoría tiene subcategorías que facilitan la medición detallada de los requisitos no-
funcionales de una aplicación de software.
58 Modelo de Medición y Estimación de Proyectos de Software
Tabla 4-8: Categorías y subcategorías del proceso SNAP
Categoría Subcategoría
1. Operaciones de datos
Validaciones de entrada de datos
Operaciones lógicas y matemáticas
Formateo de datos
Movimiento internos de datos
Entrega de valor agregado a los usuarios a
través de parametrización
2. Diseño de interfaces
Interfaces de usuario
Métodos de ayuda
Múltiples métodos de entrada
Múltiples métodos de salida
3. Ambiente tecnológico
Múltiples plataformas
Tecnología de base de datos
Procesamiento en batch
4. Arquitectura Software basado en componentes
Múltiples interfaces de entrada/salida
La descripción completa de las reglas de conteo de SNAP Points, además de ejemplos y
léxico relacionado, se puede encontrar en el Software Non-functional Assessment Process
– SNAP Assessment Practices Manual (APM) Release 2.3 [41].
En mayo de 2016, el IFPUG publicó el primero de dos documentos [42] donde propone por
primera vez la integración de los procesos de medición funcional (FPA) y no-funcional
(SNAP). En diciembre de 2016, se publicó un segundo documento que aborda aspectos
de estimación, métricas y benchmarking sobre la integración en la medición funcional y no-
funcional de software [43]. La Figura 4-4 presenta el esquema general de la articulación
entre los procesos FPA y SNAP.
La propuesta consiste en la identificación de procesos elementales tanto para SNAP como
para puntos funcionales. Pueden existir procesos elementales funcionales, no-funcionales
o aquellos que involucran aspectos de ambos tipos. Por ejemplo, mientras se analizan los
requisitos funcionales se pueden identificar procesos elementales que tienen un
componente no-funcional y hacer el respectivo análisis en paralelo.
Capítulo 4 59
Figura 4-4: Procesos de medición de SNAP points y puntos funcionales.
Fuente: Integrating Procedures for FP and SNAP [42]. Pág 8.
Es importante resaltar que las unidades de medida de SNAP points y puntos funcionales
son independientes y no pueden ser intercambiables. La medición del tamaño de una
aplicación de software utilizando los marcos de referencia del IFPUG es igual al número
de puntos funcionales más el número de SNAP points. En ningún caso se pueden sumar
en una única unidad de medida.
4.2 Estimación de software
El Project Management Institute (PMI-Project Management Institute) define como objetivo
de la estimación el proporcionar una aproximación de la cantidad de recursos necesarios
para completar las actividades de un proyecto y entregar resultados de características
funcionales y no-funcionales previamente especificadas [44].
Así mismo, el PMI en su estándar para estimación de proyectos, define la estimación como
una valoración cuantitativa de una cantidad o resultado probable, usualmente aplicada a
los costos, recursos, esfuerzo y duración de un proyecto. Generalmente precedida por un
modificador (v.g. preliminar, factible, orden de magnitud, definitiva) [1].
60 Modelo de Medición y Estimación de Proyectos de Software
Otros autores definen la estimación de manera más elaborada como es el caso de
Trendowicz y Jeffery [2] valiéndose de la definición de Tom de Marco: “Una estimación es
la predicción más optimista que tiene una probabilidad distinta a cero de convertirse en
realidad”.
Los elementos de mayor interés en la estimación son los recursos de personal, la duración,
el esfuerzo y el presupuesto. El personal se refiere al número de personas requeridas para
completar el trabajo del proyecto. La unidad de personal es el número de personas. La
duración se refiere al tiempo total necesario para completar un trabajo particular,
incluyendo el tiempo no-productivo; las unidades típicas de duración son horas, días,
meses o años. El esfuerzo es la combinación de personas y tiempo. Se refiere a la cantidad
de tiempo de trabajo productivo que una persona debería necesitar para completar cierto
trabajo. Si múltiples personas trabajan en la misma tarea, el esfuerzo total es calculado
sumando el tiempo de trabajo de todas las personas relacionadas. Las unidades típicas de
esfuerzo son persona-hora, persona-día, persona-mes y persona-año. El presupuesto se
refiere a la cantidad de dinero disponible para la realización del proyecto. Además del
significado monetario, el término presupuesto también es usado para referirse al objetivo
del proyecto, es decir, a la cantidad total de esfuerzo necesario para completar las
actividades del proyecto.
En cuanto a proyectos de software, la estimación de mayor interés es la del esfuerzo.
Teniendo cifras de esfuerzo, el costo y el tiempo del proyecto pueden ser derivados de
forma relativamente sencilla por cuanto el esfuerzo se mide en términos de personas (las
cuales tienen un costo) y tiempo. Tradicionalmente la estimación del esfuerzo en el
software ha sido asociada a la planeación de la cantidad de recursos requerida para
completar las actividades del proyecto. En la actualidad, se requiere esta información para
apoyar los procesos de toma de decisiones asociados con el proyecto además de
perseguir los siguientes objetivos [2] y [3]:
Gestionar y reducir el riesgo del proyecto
Implementar procesos de mejoramiento continuo y aprendizaje organizacional
Definición de una línea base de productividad
Negociar recursos y alcance del proyecto
Gestionar los cambios sobre el proyecto
Capítulo 4 61
Reducir los costos de gestión
Incrementar la confiabilidad, precisión y exactitud de las estimaciones de los proyectos
Tener una fundamentación para ejercicios de referenciación interna o externa
(benchmarking)
La Figura 4-5 presenta el proceso de estimación de software y su relación con el ciclo de
vida del proyecto.
Figura 4-5: Fases de la estimación en el ciclo de vida del software
Fuente: Software Project Effort Estimation: Foundations and Best Practice Guidelines for
Success [2]. Pág 32.
En la medida en que existe mayor información sobre el proyecto, las estimaciones son más
precisas. Boehm [45] introdujo el concepto del cono de incertidumbre y McConnell [46] lo
perfeccionó para ilustrar la exactitud de la estimación a lo largo de las fases de un proyecto
de desarrollo de software. La Figura 4-6 presenta una gráfica de este concepto. En ella se
observa por ejemplo, en la fase de concepción del proyecto, la estimación de esfuerzo,
62 Modelo de Medición y Estimación de Proyectos de Software
duración o costos puede estar en el rango de -75% y +400% de precisión; una vez existe
una especificación de diseño del software, la estimación realizada mejora su precisión y
se puede encontrar en el rango -20% y + 25%.
Figura 4-6: Cono de incertidumbre
Fuente: Software Engineering Economics [45]. Pág 12.
Uno de los principales conductores de la estimación de proyectos de software, ya sean
nuevos o de mantenimiento, es el tamaño del software. Este tamaño puede ser medido en
líneas de código o en cantidad de funcionalidad utilizando técnicas de medición tales como
COSMIC, FiSMA, IFPUG o NESMA. Cada uno de estos métodos tiene su propia unidad
de medida y su propio enfoque para determinar el tamaño funcional.
4.2.1 Enfoques de estimación
Existen dos principales enfoques de estimación: Macro-estimación y micro-estimación. Los
enfoques adicionales surgen como combinación de estos e incluyen elementos adicionales
en su técnica. Cualquiera de las técnicas puede ser utilizada en diferentes etapas del ciclo
de vida del software. La Tabla 4-9 muestra un resumen de los principales enfoques de
estimación basado en los aportes de Hill [47].
Capítulo 4 63
Tabla 4-9: Enfoques y Técnicas de Estimación
Enfoque Técnica de Estimación ¿Cuándo es aplicable?
Macro-Estimación
Ecuaciones. En este método el tamaño del
proyecto es aplicado a una ecuación
específica que ha sido derivada de datos de
proyectos anteriores que se encuentran
registrados en algún repositorio particular. El
resultado es indicativo para esfuerzo y
duración.
Útil cuando hay poca información
conocida o cuando los requisitos están
incompletos. Es una estimación de alto
nivel.
Comparación. Involucra encontrar un grupo
de proyectos finalizados con atributos
similares (rango del tamaño, lenguaje de
programación, tecnología utilizada, tamaño
del equipo del equipo del proyecto, etc.) a los
del nuevo proyecto y usar los datos de esos
proyectos identificados para proporcionar una
guía para estimar el esfuerzo y la duración del
nuevo proyecto.
Útil cuando hay suficientes atributos del
proyecto y el rango de tamaño
funcional es conocido. Permite al
estimador tener un espectro de
comparación de proyectos finalizados
que son similares en los atributos
identificados.
Analogía. Este método está basado en poder
encontrar un proyecto finalizado que es muy
parecido al nuevo proyecto basado en sus
principales atributos. La tasa de entrega del
proyecto (PDR – Project Delivery Rate) y la
velocidad de entrega del proyecto análogo,
son utilizadas para guiar la estimación del
esfuerzo y duración del nuevo proyecto.
Útil cuando un poco más de
información es conocida sobre el
proyecto que está siendo estimado. Es
mucho más conveniente después que
los requisitos han sido completados.
Micro-Estimación
Work Breakdown. El esfuerzo y la duración
asociados con cada componente o actividad
del proyecto de software es estimado por
separado y los resultados son agregados para
producir una estimación del trabajo como un
todo. Es una técnica tipo Bottom-up.
Útil cuando el alcance del proyecto está
bien definido y una estructura de
descomposición de trabajo (WBS –
Work Breakdown Structure) puede ser
definida. Típicamente se estiman las
tareas de acuerdo con aquellas
finalizadas de datos históricos de otros
proyectos. La estimación general es la
suma agregada de todas las
estimaciones de las tareas de la WBS.
Igualmente, existe una clasificación sugerida por Trendowicz y Jeffery en términos de
métodos de estimación del esfuerzo del software (ver Figura 4-7). Esta clasificación se
basa en (1) los tipos de datos usados como entrada del método y (2) el principio de
estimación que el método usa [2].
64 Modelo de Medición y Estimación de Proyectos de Software
Figura 4-7: Clasificación de métodos de estimación de software
Fuente: Software Project Effort Estimation [2]. Pág. 156.
Capítulo 4 65
4.2.2 Productividad
La productividad representa la eficiencia en el desarrollo del software. Trendowicz y Jeffery
[2] encontraron en 2006 que cerca del 80% de las organizaciones adoptaron una
perspectiva industrial de productividad en el contexto del desarrollo del software, donde las
entradas se refieren al esfuerzo invertido en el proyecto para producir los entregables de
software como salida del proyecto. La fórmula de productividad es la siguiente:
Esfuerzo
Tamañoadroductivid
Es importante señalar que con esta fórmula se asume que el desarrollo de software se
comporta como cualquier otro proceso industrial de manufactura. Es claro para muchos
practicantes de la ingeniería de software, que la producción de software es típicamente
mucho más compleja y difícil de un proceso de producción de otras industrias
principalmente por tres razones: (1) La industria de software desarrolla nuevos productos
cada vez, contrario a lo que sucede en un proceso de manufactura donde se fabrica el
mismo producto permanentemente, (2) El desarrollo de software es basado en personas y
(3) el desarrollo de software se realiza en un ambiente de permanentes cambios
tecnológicos. Por lo anterior, la productividad varía significativamente de un proyecto a
otro, dependiendo de un número importante de factores, algunos de los cuales se
describen en los siguientes apartados.
El IFPUG y otros autores como Hill [47] se refieren a la productividad en un contexto de
puntos funcionales como la tasa de entrega del proyecto (PDR – Project Delivery Rate).
Es una expresión que define el número de horas invertidas en la implementación de un
punto funcional. El PDR depende de muchos factores pero según estudios del ISBSG, las
características del proyecto que más impactan este factor son el tamaño software, el
tamaño del equipo (entendido como el grupo de personas que participan en el desarrollo
del software, principalmente desarrolladores y probadores) y el lenguaje de programación
utilizado para el desarrollo de software. A partir del PDR se puede obtener la fórmula del
esfuerzo:
PDRionalesPuntosFuncEsfuerzo
66 Modelo de Medición y Estimación de Proyectos de Software
Existen estudios documentados del ISBSG basados en su repositorio de proyectos para
definir PDRs por diferentes categorías, por ejemplo, por industria, tipo de organización,
área de negocio, tipo de aplicación, plataforma de desarrollo, tipo de desarrollo, tipo de
lenguaje de programación, tipo de arquitectura, metodología de desarrollo, tipo de usuario,
tamaño del proyecto, relación con el mercado y tamaño del equipo entre otros.
Autores como Jones [48] y [28] han realizado estudios para determinar las actividades
involucradas en la creación de un punto funcional y de esta forma definir un marco de
referencia para establecer esquemas de productividad en el desarrollo de software. La
Tabla 4-10 presenta un listado de las actividades identificadas por ese autor para la
construcción de un punto funcional. Además y para efectos ilustrativos, se incluye un
escenario para una aplicación desarrollada en Java, de 10.000 puntos funcionales,
utilizando un método iterativo de implementación y un equipo de desarrollo de 6 personas.
El resultado final arroja que para esta aplicación se tiene un PDR de 20,44 (Se requieren
20,44 horas para la construcción de un punto funcional de un sistema de 10.000 puntos
funcionales desarrollado en Java).
Tabla 4-10: Actividades asociadas al desarrollo de software
# Actividades de Desarrollo de Software Horas de Trabajo por
Punto Funcional (Horas)
1 Análisis de Negocio 0,02
2 Análisis de Riesgos 0,00
3 Plan de Respuesta a Riesgos 0,01
4 Especificación de Requisitos 0,38
5 Inspección de Requisitos 0,22
6 Prototipos 0,33
7 Arquitectura 0,05
8 Inspección de Arquitectura 0,04
9 Planeación y Estimación del Proyecto 0,03
10 Diseño Inicial 0,75
11 Diseño Detallado 0,75
12 Inspección de Diseño 0,53
13 Codificación 4,00
14 Inspección de Código 3,30
15 Reusabilidad 0,01
16 Análisis Estático 0,02
17 Adquisición software COTS 0,01
18 Adquisición de software open source 0,01
19 Auditoría de Código 0,04
20 Verificación y Validación 0,07
Capítulo 4 67
# Actividades de Desarrollo de Software Horas de Trabajo por
Punto Funcional (Horas)
21 Control de la Configuración 0,04
22 Integración de Código 0,04
23 Documentación de Usuario 0,29
24 Pruebas Unitarias 0,88
25 Pruebas Funcionales 0,75
26 Pruebas de Regresión 0,53
27 Pruebas de Integración 0,44
28 Pruebas de Desempeño 0,33
29 Pruebas de Seguridad 0,26
30 Pruebas de Usabilidad 0,22
31 Pruebas de Sistema 0,88
32 Pruebas Cloud 0,13
33 Pruebas de Campo (Beta) 0,18
34 Pruebas de Aceptación (UAT) 0,05
35 Pruebas Independientes 0,07
36 Aseguramiento de la Calidad 0,18
37 Instalación y Entrenamiento 0,04
38 Medición del Proyecto 0,01
39 Oficina de Proyectos 0,18
40 Gerencia del Proyecto 4,40 Resultado Acumulado 20,44 Horas
A raíz de la aparición de métodos para la medición del tamaño no-funcional del software,
en 2012 Buglione [49] propone un enfoque de productividad para el componente no-
funcional del software. Este autor propone una evolución a la fórmula de productividad de
la siguiente forma:
oyecto
oyecto
funcionalNo
funcionalNo
Funcional
Funcional
Esfuerzo
XYZ
Esfuerzo
SP
Esfuerzo
FPdoductivida
Pr
Pr)(Pr
Dónde:
FPFuncional: Tamaño funcional del producto de software medido en puntos funcionales
EsfuerzoFuncional: Esfuerzo para construir el tamaño funcional del producto medido en
horas
SPNo-funcional: Tamaño no-funcional del producto de software medido en SNAP points
EsfuerzoNo-funcional: Esfuerzo para construir el tamaño no-funcional del producto medido
en horas
XYZProyecto: Medida del tamaño de las actividades a nivel de proyecto
EsfuerzoProyecto: Esfuerzo para desarrollar las actividades a nivel de proyecto medido
en horas
68 Modelo de Medición y Estimación de Proyectos de Software
Buglione pone de manifiesto dos aspectos importantes para lograr tener una productividad
del componente no-funcional y del proyecto:
Se debe comenzar a medir el componente no-funcional en paralelo con el funcional. Si
bien el componente funcional se viene midiendo en la industria desde hace varias
décadas, es necesario realizar la medición no-funcional con los métodos existentes y
abandonar los esquemas de aplicación de factores de ajuste o proporciones de
tamaño.
Registrar la historia de proyectos en materia de medición y productividad tanto a nivel
funcional como a nivel no-funcional y de proyecto. Lo anterior significa registrar el
consumo de recursos de las actividades relacionadas con la construcción del
componente funcional y no-funcional del producto además de aquellas relacionadas
con el desarrollo del proyecto (v.g. esfuerzo invertido en labores de gerencia de
proyectos). Con este registro de datos, se tendrán valores para la organización que
pueden ser comparados con los repositorios de proyectos y valores de referencia de la
industria en materia de productividad.
4.2.2.1 Factores que influencian la productividad
De acuerdo con los aportes de Trendowicz y Jeffery [2], algunos de los principales factores
que influencian la productividad de un proyecto de software se encuentran resumidos en
la Tabla 4-11.
Tabla 4-11: Factores que influencian el esfuerzo en proyectos de software
Tipo Factor Descripción
Factores de contexto
Lenguaje de programación
Lenguaje de programación utilizado para implementar el código. Ejemplos: C, C++, Java.
Dominio de aplicación
Dominio de aplicación donde se utiliza el software. Ejemplos: Sistemas de Software Embebido, Sistemas de Información Empresariales.
Tipo de desarrollo Ejemplos: Nuevo desarrollo, mejora, corrección de defectos.
Metodología de desarrollo Ciclo de vida del desarrollo que será utilizado. Ejemplos: Cascada, Incremental, Iterativa.
Factores de Escala
Tamaño del equipo y estructura del equipo
El número de canales de comunicación y el número de conflictos interpersonales entre los miembros del equipo.
Capítulo 4 69
Tipo Factor Descripción
Complejidad de las actividades de gestión del proyecto
Número y complejidad de las actividades de la gestión de proyectos. Una deficiente gerencia incrementa los costos del proyecto.
Madurez de los procesos Procesos inestables y sin documentación reducen la productividad en el desarrollo de software.
Novedad del proyecto
La falta de familiaridad con el dominio de aplicación del proyecto reduce la productividad y afecta el mantenimiento del producto.
Complejidad de las interfaces e integración
La complejidad de las interfaces y la integración incrementa
4.2.2.2 Conductores de esfuerzo
Los conductores de esfuerzo son factores que son explícitamente incluidos en el proceso
de estimación para explicar la varianza en la productividad dentro de un contexto particular.
Estos factores se refieren al personal, al producto, al proceso o a las características del
proyecto. La Tabla 4-12 hace un resumen de los conductores de esfuerzo más comunes
y que se encuentran detalladamente explicados en [2].
Tabla 4-12: Conductores de esfuerzo más comunes
Conductor de esfuerzo Descripción
Capacidades y experiencia
del equipo
Conocimiento y experiencia en el dominio de aplicación
del proyecto, procesos, estándares, mejores prácticas y
plataforma de desarrollo.
Experiencia en el lenguaje de
programación
Experiencia en la utilización del lenguaje de programación
empleado en el proyecto (al inicio del proyecto).
Experiencia y familiaridad en
la aplicación
Conocimiento del equipo de las necesidades de negocio
del cliente además de las características principales del
sistema (al inicio del proyecto).
Experiencia y habilidades en
gerencia de proyectos
Iniciación, planeación, ejecución, monitoreo y control y
cierre del proyecto. Esta experiencia se adquiere de
proyectos anteriores.
Involucramiento del
usuario/cliente
El grado en el cual el usuario/cliente está involucrado en
el proyecto y pueda proveer experiencia e información
necesaria y útil al proyecto.
70 Modelo de Medición y Estimación de Proyectos de Software
Conductor de esfuerzo Descripción
Complejidad del software
El grado en el cual algunos aspectos tales como
interfaces, arquitectura, base de datos, algoritmos o
relación con otros sistemas definen la complejidad del
producto o magnitud del proyecto.
Tamaño de la base de datos
y complejidad
El tamaño y la complejidad de las estructuras de datos y
la gestión de los mismos.
Complejidad de la
arquitectura La complejidad de la arquitectura del software
Complejidad de las interfaces
con otros sistemas
Complejidad de las interfaces hardware-software y/o
interfaces usuario-software.
Calidad de los requisitos
Características de los requisitos del software tanto
funcionales como no-funcionales que determinan su
utilidad para desarrollar software de calidad a tiempo y
dentro del presupuesto.
Novedad en los requisitos El grado en el cual los requisitos son novedosos para el
equipo de desarrollo.
Estabilidad de los requisitos
El grado en el cual los requisitos cambian después que
han sido especificados, típicamente después de la fase de
especificación de requisitos.
Calidad del software
requerida
El grado en el cual un producto particular de software debe
cumplir ciertos requisitos no-funcionales. Este factor
refleja que tan riguroso es un requisito relacionado con el
producto de software.
Confiabilidad del software
requerida
La cantidad de atención que debe ser prestada para
minimizar fallas y asegurar que ninguna de ellas resultará
en un daño económico, de seguridad y/o del ambiente. La
confiabilidad requerida puede ser alcanzada a través de
acciones tales como validaciones, pruebas diseño de un
sistema tolerante a fallas y especificaciones formales.
Mantenibilidad requerida
El grado en el cual se espera que el software sea fácil de
entender y modificar. Puede ser alcanzado a través de
acciones tales como ocultación de información de diseño
(v.g. encapsulación), modularidad en el diseño,
documentación y registro de la racionalidad del diseño.
Restricciones del proyecto Restricciones adicionales sobre el desempeño de
proyecto de desarrollo de software.
Presiones de
tiempo/cronograma
El grado en el cual el plan de trabajo es razonable para
cumplir los requisitos especificados.
Distribución del proyecto El grado en el cual el equipo del proyecto está geográfica
y organizacionalmente distribuido.
Capítulo 4 71
Conductor de esfuerzo Descripción
Uso, calidad y efectividad de
herramientas
El grado en el cual las herramientas son de alta calidad y
tienen un uso efectivo a través del proyecto. Ejemplos
incluyen herramientas de análisis y diseño, Application
Lifecycle Management (ALMs), herramientas de
depuración y herramientas CASE,
Herramientas CASE
El grado en el cual herramientas de alta calidad son
apropiadas para las actividades de diseño y desarrollo de
software.
Herramientas de pruebas El grado en el cual herramientas de alta calidad soportan
adecuadamente las actividades de pruebas del software.
4.3 Otros tipos de medición y estimación
En este apartado se encuentra una descripción de los otros dos (2) tipos de medición que
son de interés para esta investigación: Los relacionados con la medición de las fases de
especificación de requisitos y desarrollo de pruebas de software.
4.3.1 Medición y estimación de requisitos
Los requisitos de software son el punto de partida de cada nuevo proyecto. Generalmente
la especificación de requisitos funcionales, no-funcionales y del proyecto define el éxito o
el fracaso del proyecto. Jones define los requisitos en un contexto de costos del software
como un elemento clave para el desarrollo de los proyectos y encuentra que en muchas
ocasiones son ambiguos, especificados con supuestos erróneos, contienen errores
severos y es difícil precisar en una forma clara y comprensiva cuales son las necesidades
de los usuarios finales tanto técnicos como de negocio [28].
Otro aspecto relevante para entender el bajo desarrollo en temas de medición y estimación
de requisitos tiene que ver con la falta de herramientas tecnológicas para recopilación y
análisis de requisitos de software; según Jones, las existentes son difíciles de utilizar o
están incompletas. La mayoría de los libros relacionados con ingeniería de requisitos
omiten aspectos de cuantificación del tamaño de los requisitos, esfuerzo requerido y costos
asociados.
La medición de requisitos no es una de las disciplinas más desarrolladas y tampoco existen
muchos estudios al respecto. Una de las principales causas de esta situación se debe al
72 Modelo de Medición y Estimación de Proyectos de Software
hecho relacionado con la inestabilidad de los requisitos y al crecimiento continuo de los
mismos durante el ciclo de desarrollo de software incluso en las fases de codificación y
pruebas [28].
Otros autores sugieren algunas formas para establecer el esfuerzo que debe ser invertido
en las actividades asociadas a requisitos. Proyectos “pequeños” típicamente gastan entre
el 15% y el 18% del esfuerzo total en requisitos [50]. El porcentaje apropiado depende del
tamaño y complejidad del proyecto. K. Wiegers y J. Beatty han encontrado evidencias que
muestran que al invertir más tiempo en el entendimiento de los requisitos, el desarrollo de
software se acelera. A continuación algunos ejemplos que ilustran este hecho [50]:
Un estudio de 15 proyectos en las industrias de banca y telecomunicaciones reveló que
sus proyectos más exitosos invirtieron el 28% de sus recursos en levantamiento,
modelamiento, validación y verificación de requisitos. Dedicaron a la ingeniería de
requisitos en promedio 15.7% del esfuerzo y el 38.6% del cronograma [51].
Proyectos de la NASA que invirtieron más del 10% del total de sus recursos en
requisitos tuvieron menor sobre-costo y menores desfases en cronograma con
respecto a aquellos que invirtieron menor esfuerzo en el mismo tipo de actividades [52].
4.3.2 Medición y estimación de pruebas de software
Estimar esfuerzo, costos y duración asociadas a las pruebas es uno de los temas más
complejos que existe por cuanto hay muchas formas de probar software (tipos de pruebas)
además de la amplia variedad de niveles de pruebas (hasta 18 niveles distintos) que
pueden ser ejecutadas desde un modo superficial hasta uno muy detallado. La estimación
de pruebas también resulta compleja por el hecho de la cantidad de defectos presentes en
el software antes de iniciar las pruebas [28]. Por ejemplo, proyectos que usan inspecciones
de diseño e inspecciones de código pueden tener hasta un 80% menos de defectos que
aquellos proyectos que no utilizan inspecciones. La Tabla 4-13 presenta los principales
niveles de pruebas según Jones [28]. Según ese autor, a medida que el tamaño de la
aplicación es mayor, se requieren mayores niveles de pruebas. Sin embargo, él observó
en sus estudios de 2007 que no hay un único patrón de pruebas universalmente apropiado
para todos los tamaños de software (1, 10, 100, 1.000, 10.000 puntos funcionales) y todas
las clases de software (MIS, Web, Militares, de sistema, etc.).
Capítulo 4 73
Tabla 4-13: Métodos y niveles de pruebas
Forma Nivel de pruebas
Pruebas generales Pruebas unitarias
Pruebas de integración
Pruebas de sistema
Pruebas de regresión
Pruebas nueva funcionalidad
Pruebas de subrutinas
Pruebas
especializadas
Pruebas de protección viral
Pruebas de estrés
Pruebas de desempeño
Pruebas de seguridad
Pruebas de plataforma
Pruebas independientes
Pruebas “Supply-Chain”
Pruebas de usuario
Pruebas aceptación usuario
Pruebas de campo (beta)
Pruebas de usabilidad
Pruebas de laboratorio
Pruebas “clean-room”
En [28] Jones propone un modelo que usa los puntos funcionales del IFPUG para estimar
el volumen de los casos de prueba. Su ventaja principal radica en que los puntos
funcionales de un sistema son conocidos desde la fase especificación de requisitos o
desde las etapas tempranas del diseño del software. Esto hace posible que se puedan
predecir de alguna manera el número de casos de prueba oportunamente. El ISBSG tiene
ejemplos de este tipo de estimación que utiliza la métrica llamada “casos de prueba por
punto funcional”. Igualmente el uso de puntos funcionales permite estimar el número de
personas que realizarán pruebas (Test Personnel / Testers) además del esfuerzo y los
costos asociados que incluyen las fases:
Preparación de pruebas: Involucra la creación de casos de pruebas, validación de los
mismos y organización en un repositorio de pruebas.
Ejecución de pruebas: Involucra la ejecución de los casos de prueba sobre el software
y el posterior registro de resultados. Las pruebas son un proceso iterativo y los mismos
casos de prueba pueden ser ejecutados varias veces si es necesario.
Reparación de defectos: Relacionado con la corrección de bugs en el software que
son identificados vía pruebas. Se valida la corrección ejecutando nuevamente los
74 Modelo de Medición y Estimación de Proyectos de Software
casos de prueba que identificaron los bugs para asegurar que estos bugs fueron
reparados y que nuevos bugs no han sido inyectados inadvertidamente.
Estudios recientes relacionados con el costo del software muestran que las pruebas de
software constituyen entre un 30% y 50% del costo del software. Una técnica que sobresale
en materia de estimación de pruebas es el Análisis de Puntos de Prueba (TPA-Test Point
Analysis) que ha mostrado un buen nivel de exactitud, proporcionando un rango amplio de
cobertura de pruebas y el esfuerzo necesario para planear y ejecutar las pruebas de
software. Sin embargo, se han encontrado problemas al momento de evaluar la
complejidad de la funcionalidad por cuanto se hace necesario revisar manualmente el
código, lo cual es una actividad susceptible a errores y además en la fase de diseño o
incluso en especificación de requisitos que es un momento apropiado para estimar las
pruebas, el código aún no es definitivo [53].
Técnicas alternativas como Análisis de Puntos de Prueba Adaptados (ATPA - Adapted
Test Point Analysis) [54] sugieren que la estimación de la complejidad funcional debe ser
realizada a través del conteo de puntos funcionales. Esto trae como ventaja que en ese
momento las mediciones funcionales ya deberían estar disponibles (una vez los requisitos
funcionales fueron definidos). En algunos proyectos desarrollados en Brasil, la técnica ha
mostrado resultados satisfactorios. La técnica en mención está basada en tres elementos
fundamentales: (1) el tamaño del sistema a probar en puntos funcionales; (2) la estrategia
de pruebas y (3) la productividad, expresada en el número de horas necesarias para
ejecutar una tarea. Para mayor información relacionada con esta técnica ver [53].
4.3.3 Medición y estimación en metodologías ágiles
Los métodos ágiles han desarrollado sus propias métricas de medición, estimación y
monitoreo del progreso del proyecto las cuales trabajan adecuadamente. De acuerdo con
los practicantes de estas metodologías, las métricas se consideran muy útiles para las
actividades que desempeñan los equipos ágiles.
En metodologías ágiles, las historias de usuario (HU) son usadas para capturar los
requerimientos funcionales y la suma de todas ellas define el producto a ser desarrollado.
Capítulo 4 75
El tamaño de las HU está basado en su complejidad relativa la cual es expresada en una
medida llamada puntos de historia (PH).
Las HU son priorizadas basadas en varios factores; los más importantes son su valor de
negocio y complejidad relativa. Las HU son descompuestas en Work Items (WI) y el
esfuerzo de cada uno de estos es estimado con base en métodos Delphi como por ejemplo
Planning Poker y de esta forma planear el esfuerzo de la iteración. La estimación del
tamaño (en puntos de historia) y la estimación del esfuerzo (Planning Poker) son hechos
por separado. Después que la primera iteración es finalizada, el equipo tiene que estimar
su velocidad: el número de PH que pueden ser alcanzados en una iteración. Esta
velocidad es reevaluada periódicamente dentro del proyecto. Asociando la velocidad y el
número de PH a ser desarrollados, el equipo puede estimar el número de iteraciones
requeridas para completar el proyecto. De esta forma se puede tener una idea de la fecha
final del proyecto.
No existen a la fecha métodos de medición y estimación de software en proyectos ágiles
que estén basados en procedimientos estandarizados. Esta condición hace difícil sino
imposible medir y comparar la productividad del desarrollo entre proyectos de la
organización y proyectos de una organización con el sector de industria.
Algunos autores proponen los PH como una medida del tamaño del software. Es claro que
los PH no proveen una medida exacta del tamaño del software lo las siguientes razones:
Los PH no están basados en un método estándar
No hay relación entre los PH y los puntos funcionales
Los PH son distintos para cada equipo o proyecto y tienen significado solamente para
los miembros del equipo que los estimó
A la fecha, existen interrogantes relacionadas con la utilidad de estas métricas desde una
perspectiva de necesidades de la organización en materia de medición y estimación de
portafolios de proyectos de software.
76 Modelo de Medición y Estimación de Proyectos de Software
4.4 Estándares
Existen cinco (5) métodos reconocidos por ISO/EIC además de un estándar de
características generales sobre el tamaño funcional del software. A continuación una breve
reseña de cada uno de ellos:
4.4.1 IFPUG: ISO/IEC 20926:2009
Este método es el que se ha descrito en “4.1.4.1-Puntos funcionales”. Puede ser usado
para determinar el tamaño funcional tanto de aplicaciones como de proyectos de software
[33]. Los principales pasos de proceso son los siguientes:
a. Recopilar documentación disponible
b. Determinar el alcance del conteo y la frontera de la aplicación además de los
requisitos funcionales
c. Medir el tamaño de las funciones de datos. Las funciones de datos son Internal
Logical Files (ILFs) o External Interfaces Files (EIFs)
d. Medir el tamaño de las funciones transaccionales. Las funciones transaccionales
son External Inputs (EIs), External Outputs (EOs) o Externa Inquiries (EQs)
e. Calcular el tamaño funcional
Información detallada sobre este estándar se encuentra en [31], [33] y [55].
4.4.2 COSMIC: ISO/IEC 19761:2011
Common Software Measurement International Consortium (COSMIC) [37]. El método
COSMIC fue aceptado como un estándar internacional por primera vez en el año 2003. La
versión actual del estándar es de 2011. La versión 4.01 y el estándar ISO actual pueden
ser descargados de [56]. Es usado en empresas del sector público y privado tanto para
medición de proyectos de software como para aplicaciones de software. Define los
principios, reglas y procesos de medición del tamaño funcional del software, entendida
como la cantidad de funcionalidad entregada por el software, independiente de cualquier
consideración técnica o de calidad. El método puede ser aplicado para medir requisitos
funcionales a cualquier nivel de descomposición, en cualquier capa arquitectónica y en
cualquier punto del ciclo de vida del software.
Capítulo 4 77
COSMIC puede ser usado para medir aplicaciones de negocio, software de tiempo real,
software de infraestructura (v.g. sistemas operativos). La característica fundamental de
estos tipos de software es que estos son dominados por funciones de entrada de datos,
almacenamiento y recuperación de datos y datos de salida. Este método no está diseñado
para software que está dominado por funciones que manipulan datos tales como software
científico o de ingeniería.
En este estándar, el método de medición implica que los procesos del software funcional
y sus eventos disparadores sean identificados. La unidad de medición es el “movimiento
de datos” de los cuales hay cuatro (4) tipos: Entradas, Salidas, Lecturas y Escrituras. El
tamaño de una pieza de software es definido como el número total de movimientos de
datos (Entradas, Salidas, Lecturas y Escrituras) sumadas sobre todos los procesos
funcionales de la pieza de software. Cada movimiento es contado como un COSMIC
Function Point (CFP). El tamaño de una pieza de software puede ser de mínimo 2 CFP,
sin límite superior.
La Figura 4-8 muestra el proceso de medición COSMIC. La primera fase denominada
“Estrategia de Medición” define el alcance y propósito de la medición. En la “Fase de
Mapeo” el modelo de software genérico es aplicado a los requisitos funcionales del
software a ser medido para producir el “Modelo COSMIC del Software”. La tercera fase,
“Fase de Medición” se encarga de realizar la medición del tamaño del software.
Figura 4-8: Proceso del método COSMIC
Fuente: COSMIC. http://cosmic-sizing.org [57]
78 Modelo de Medición y Estimación de Proyectos de Software
A partir de 2007 se han realizado investigaciones para construir frameworks de medición
del tamaño no-funcional del software basados en COSMIC. Kassab, Ormandjieva y otros
autores propusieron un framework para tal efecto [58] que denominaron Non-Functional
Requirements Size Measurement Method (NFSM) with COSMIC-FFP (NFSM-COSMIC).
Información detallada sobre este estándar se encuentra en [29], [57], [47] y [59].
4.4.3 FiSMA: ISO/IEC 29881:2010
Finnish Software Measurement Association [35]. Basado en requisitos funcionales es
aplicable a la medición de todo tipo de software en cualquier dominio funcional. Puede ser
usado para determinar el tamaño funcional tanto de aplicaciones como de proyectos de
software. Identifica 28 tipos distintos de componentes funcionales (BFC – Base Funcional
Componentes) además de siete (7) clases BFC. Cada clase tiene una regla específica de
conteo para determinar el tamaño funcional de cualquier componente dentro de la clase.
Los parámetros utilizados en las reglas de conteo son (1) número de elementos de datos;
(2) número de lecturas de referencia; (3) número de escrituras de referencia y (4) número
de operaciones. Todas las reglas de conteo siguen la misma fórmula:
C
eracionesNúmeroDeOp
D
atosementosDeDNúmeroDeElATamaño
Donde A, D y C son constantes específicas de clase. Por ejemplo, la fórmula para la clase
“navegación y servicios de consulta” es:
272,0
RNTamaño
Por ejemplo, el tamaño de una consulta con 21 elementos de datos (N) en la pantalla que
es leída de 4 entidades (R), debería ser:
2,52
4
7
212,0 Tamaño
El cual se mide en FFP (FiSMA Function Points)
Los principales pasos del proceso son los siguientes:
a. Recopilar documentación y artefactos de desarrollo de software para describir los
requisitos funcionales del software desarrollado o a ser desarrollado.
b. Determinar el alcance de la medición del tamaño funcional.
Capítulo 4 79
c. Determinar cuáles son los requisitos funcionales a ser medidos
d. Identificar los componentes funcionales base dentro de los requisitos funcionales
en dos grupos principales (1) medición de servicios de interface de usuario final y
(2) medición de servicios indirectos.
e. Asignar los valores numéricos apropiados a cada componente funcional base.
f. Calcular el tamaño funcional.
g. Documentar los detalles del conteo.
La versión actual del método es 1.1. Información detallada sobre este estándar se
encuentra en [47] y [60].
4.4.4 MK II: ISO/IEC 20968:2002
Mark II (este concepto se refiere a la segunda versión de un producto. El significado de
Mark es “modelo” y es abreviado como “Mk”). Principalmente usado en el Reino Unido por
organizaciones del gobierno. Originalmente desarrollado por Charles R. Symons en 1988.
El método es estable y sus reglas no han cambiado desde 1988 [36]. Incluye el conteo de
entidades y relaciones en el modelo de datos. La versión actual del método es la 1.3.1. La
principal característica del método es su simplicidad para la medición que involucra
únicamente 3 componentes:
Entradas: datos que vienen desde afuera del software a través de un usuario en un
ambiente externo.
Salidas: datos abandonando el software hacia un usuario en un ambiente externo.
Referencias a entidades: el almacenamiento, recuperación y eliminación de datos del
almacenamiento permanente.
El método se utiliza tanto para la medición funcional como para calcular el esfuerzo,
productividad y otros parámetros de desempeño. Involucra para el componente no-
funcional un ajuste de complejidad técnica dado por los elementos denominados “grados
de influencia”. Los principales pasos de proceso son los siguientes:
a. Determinar la perspectiva, propósito y tipo de conteo.
b. Definir la frontera del conteo.
c. Identificar las transacciones lógicas.
d. Identificar y categorizar los tipos de entidades de datos.
80 Modelo de Medición y Estimación de Proyectos de Software
e. Contar Input Data Element Types, Data Entity Types Referenced y Output Data
Element Types.
f. Calcular el tamaño funcional.
Información detallada sobre este estándar se encuentra en [3], [36] y [61].
4.4.5 NESMA: ISO/IEC 24570:2005
Netherlands Software Metrics Association (NESMA) [34]. En 1989 fue publicado el primer
estándar de medición funcional basado en los principios del método de Albretch. Puede
ser descargado desde [62]. Las primeras versiones tuvieron variaciones significativas con
respecto a las mediciones realizadas con el método IFPUG debido a la variación e
interpretación de las reglas de cada método. Las actuales versiones de los estándares son
altamente comparables y de acuerdo con los comités de ambos métodos, son en un 95%-
99% el mismo [3]. NESMA e IFPUG han trabajado de la mano desde 1990 para evitar
divergencias entre sus respectivas mediciones del tamaño funcional. Este método es
específico para proyectos de mejoramiento de software.
NESMA e IFPUF usan la misma terminología aunque en un lenguaje diferente (inglés y
dutch). Se diferencian en los mismos 5 tipos de funciones de usuario: ILGV (ILF), KGV
(EIF), IF (EI), UF (EO), OF (EQ). Las reglas para determinar el tipo y la complejidad de una
función son las mismas con algunas excepciones. Los principales pasos de proceso son
los siguientes:
a. Identificar las funciones de datos y transaccionales dentro del alcance del proyecto
de mejora y determinar su tamaño funcional
b. Determinar cuáles funciones de datos y transaccionales serán adicionadas
c. Determinar cuáles funciones de datos y transaccionales serán eliminadas
d. Determinar cuáles funciones de datos serán cambiadas y determinar el factor de
impacto
e. Determinar cuáles funciones transaccionales serán cambiadas y determinar el
factor de impacto
f. Calcular el número de puntos funcionales de la mejora
Información detallada sobre este estándar se encuentra en [3], [34] y [62].
Capítulo 4 81
4.4.6 ISO/IEC 14143 Functional Size Measurement
La familia de estándares ISO/EIC 14143 tiene 6 partes relacionadas con el tema de
medición funcional del software. A continuación se describen a nivel general cada uno de
sus componentes:
ISO/IEC 14143-1. Medición del tamaño funcional: Definición de conceptos [32].
ISO/IEC 14143-2. Evaluación de la conformidad de los métodos de medición del
tamaño del software.
ISO/IEC 14143-3. Verificación de los métodos de medición del tamaño funcional del
software.
ISO/IEC 14143-4. Modelo de referencia.
ISO/IEC 14143-5.Determinación de dominios funcionales parea el uso de medición
funcional del software.
ISO/IEC 14143-6. Guía para el uso de los estándares de la serie ISO/IEC 14143 y
estándares relacionados. Provee guías para seleccionar el método de medición de
tamaño del software más apropiado para una situación particular.
4.5 Repositorios de información de proyectos
En cuanto a productividad del software, existen repositorios de información de proyectos
de software que son alimentados por empresas a nivel mundial una vez sus proyectos han
sido finalizados. Estos repositorios son administrados por otro tipo de organizaciones que
impulsan a compañías que llevan a cabo proyectos de software para que registren datos
de sus proyectos de software y de esta forma ir consolidando bases de datos que sirven
como referente para procesos de toma de decisiones. A continuación se presentan dos de
los repositorios más reconocidos a nivel mundial.
4.5.1 ISBSG
Administra un repositorio de proyectos que día a día se alimenta por organizaciones
interesadas en hacer procesos de referenciación entre sus nuevos proyectos y los
realizados por otras organizaciones a nivel mundial. Este repositorio de métricas de
software apoya los procesos de estimación, benchmarking, gestión de proyectos,
planeación de infraestructura, gestión de outsourcing, cumplimiento de estándares y
82 Modelo de Medición y Estimación de Proyectos de Software
gestión de presupuesto. Las métricas principales que contiene el repositorio se enfocan en
tamaño, tiempo y esfuerzo para las diferentes fases de desarrollo de software con
aproximadamente 100 atributos de información.
En 2016 el repositorio de esta organización contiene datos de más de 7.500 proyectos de
nuevos desarrollos (65%) y mantenimiento de software (35%). La mayoría de los proyectos
registrados fueron medidos con el método IFPUG y también se encuentran mediciones con
métodos COSMIC, NESFA y Mark II. La tasa de crecimiento del repositorio es de
aproximadamente 500 proyectos por año. Los proyectos pertenecen a 32 países (32%
Estados Unidos, 13% Australia, 12% Japón, 9% Finlandia y 7% Francia entre otros) y
abordan las 7 industrias principales donde se desarrollan proyectos de software. El costo
de una licencia de este repositorio es de aproximadamente USD 1.938. Para mayor
información al respecto, consultar [63].
4.5.2 QSM
Quantitative Software Management (QSM) es una organización privada que administra un
repositorio denominado “QSM Software Project Database” que contiene información de
más de 10.000 proyectos de software finalizados y que sirve principalmente para soportar
procesos de benchmarking. El repositorio comenzó a poblarse desde 1978. Desde 1994
se adicionan en promedio 200 proyectos por año. Las métricas principales que contiene el
repositorio se enfocan en tamaño, tiempo, esfuerzo y defectos para las diferentes fases de
desarrollo de software. Existen otros 300 atributos complementarios. El 98% del repositorio
tiene datos de tiempo y esfuerzo de cada proyecto para las fases de construcción y
pruebas. El repositorio contiene proyectos de 9 dominios de aplicación, 6 metodologías de
desarrollo, 3 estándares de tecnología, más de 700 lenguajes donde los principales son
Java, Cobol, C, C++, C# Visual Basic y .NET. El 50% de los proyectos registrados son de
Estados Unidos, otro 40% de Europa y Asia y el 10% restante de África y Oceanía. Para
mayor información al respecto ver [64].
5. Modelo de medición y estimación de software
5.1 Definición del modelo
El modelo de medición y estimación propuesto para la organización objeto de estudio es
el resultado del diagnóstico realizado además de la revisión del estado del arte en materia
de medición y estimación de software tanto a nivel académico como de industria. Existen
variadas definiciones de lo que puede ser considerado un modelo, entendido como una
representación de aspectos seleccionados de un dominio de interés para el modelador:
Una representación lógica, física o matemática de un sistema, entidad, fenómeno o
proceso [65].
Una representación de uno o más conceptos que pueden ser percibidos en el mundo
físico [66].
Una representación simplificada de un sistema en algún punto en particular del tiempo
o espacio, con el propósito de promover entendimiento de un sistema real [67].
Una abstracción de un sistema, encaminada a comprender, comunicar, explicar o
diseñar aspectos de interés de ese sistema [68].
Una representación selectiva de algún sistema cuya forma y contenido son
seleccionados con base en un conjunto específico de requisitos, circunstancias o
necesidades [69].
Basado en las anteriores definiciones, para el caso de esta investigación, se define el
modelo de medición y estimación de software como una abstracción del proceso llevado a
cabo por la organización objeto de estudio, encaminada a diseñar aspectos de interés
relacionados con medición y estimación de proyectos de software. Los elementos del
modelo y sus interrelaciones han sido seleccionados de acuerdo con los requisitos sobre
84 Modelo de Medición y Estimación de Proyectos de Software
la realidad observada por parte del modelador y que están relacionados principalmente
con las oportunidades de mejora identificadas a lo largo de este trabajo de investigación.
5.2 Representación y especificación del modelo
A continuación se presenta un diagrama del modelo de medición y estimación de software
propuesto para la organización objeto de estudio (ver Figura 5-1). En las secciones
posteriores se realiza la especificación de requisitos para cada uno de los elementos que
componen el modelo propuesto. Esta especificación es el resultado principal de esta
investigación y está planteada a un nivel tal que la organización defina alternativas de
implementación de acuerdo con sus prioridades y recursos disponibles.
Es importante resaltar en este punto, que el objetivo central de este trabajo está
relacionado con la especificación misma del modelo y no con su implementación. Esta
última es más un proyecto organizacional derivado de los resultados de esta investigación.
Figura 5-1: Modelo de medición y estimación de software
Fuente: Creación del autor
El modelo consta de 8 componentes, de los cuales cuatro son de apoyo o estructura: (1)
Medición funcional y no-funcional; (2) Estimación de software; (3) Esquema de contratación
de software y (4) Oficina de medición y estimación de software que actúan de forma
Especificación de Requerimientos
Construcción de Software
Pruebas de Software
Mantenimiento de Software
Esquema de Contratación de Software
Oficina de Medición y Estimación de Software
Estimación de Software
Medición Funcional y No-Funcional
Capítulo 5 85
transversal sobre los cuatro pilares del desarrollo de software en la organización objeto de
estudio: (1) Especificación de requisitos; (2) construcción de software; (3) pruebas de
software y (4) mantenimiento de software.
Estas propuestas de requisitos pueden hacer parte de un proyecto que los contenga como
un todo o pueden implementarse gradualmente, dependiendo de las prioridades de
negocio y recursos que la organización pueda asignar para su consecución. Al implementar
todos los requisitos propuestos se logrará un modelo integral de medición y estimación de
proyectos de software para la organización objeto de estudio: La Banca Central de
Colombia.
5.2.1 Consideraciones frente a las metodologías ágiles
El modelo de medición y estimación de software presentado a continuación es el resultado
del análisis realizado sobre la organización objeto de estudio. De acuerdo con el análisis
presentado en el diagnóstico, solamente dos (2) de los proyectos que pertenecen al
portafolio han sido desarrollados con metodologías ágiles. Por lo anterior, los
requerimientos del modelo relacionados con el ciclo de vida del software (i.e.
requerimientos, construcción y pruebas) están orientados a la utilización de metodologías
tradicionales.
En la medida en que las metodologías ágiles comiencen a jugar un papel crucial dentro
del portafolio de proyectos de software de la organización objeto de estudio, se deberían
complementar algunos de los requerimientos y/o redefinir la implementación de los mismos
dentro del modelo. Se deberían analizar consideraciones como las descritas en el capítulo
4 de este documento y propender por la utilización de métodos de medición y estimación
de software que sean independientes de la metodología de desarrollo utilizada.
5.2.2 Estructura de la especificación
En este apartado se explica la forma como se estructura la especificación de los requisitos
del modelo de medición y estimación para la organización objeto de estudio. Para cada
uno de los componentes se propone uno o más requisitos necesarios para su
implementación. El formato utilizado para especificar cada uno de los requisitos se muestra
en la Tabla 5-1.
86 Modelo de Medición y Estimación de Proyectos de Software
Tabla 5-1: Estructura de la especificación de requisito
No.
Nombre:
Componente:
Prioridad:
Justificación:
Descripción:
Criterios de Aceptación:
Supuestos y restricciones:
Los atributos de información para cada uno de los requisitos especificados se explican a
continuación:
Número (No.): Número consecutivo de la especificación. Este atributo se utiliza para
efectos de identificación del requisito.
Nombre: Nombre del requisito. Junto con el número consecutivo de identificación
ayuda a identificar de manera única el requisito.
Componente: Categoría a la cual pertenece el requisito. Existen ocho (8) diferentes
categorías que pueden ser examinadas en la Figura 5-1 o en el apartado “5.2 -
Representación y especificación del modelo” de este documento.
Prioridad: Prioridad en términos de criticidad de implementación del requisito para
consolidar el modelo. Los posibles valores son ALTA | MEDIA | BAJA.
Justificación: Responde a la pregunta: ¿Por qué se debe implementar este requisito?
Puede contener los objetivos del requisito o las necesidades que soluciona.
Descripción: Contiene la información detallada de las características que deben ser
implementadas.
Criterios de aceptación: Son las condiciones esenciales que deben ser cumplidas
para aceptar la implementación asociada al requisito.
Supuestos y restricciones: Limitaciones y suposiciones que pueden afectar positiva
o negativamente la función esperada.
Con la anterior explicación, se procede a realizar la especificación de cada uno de los
requisitos del modelo de medición y estimación de proyectos software.
Capítulo 5 87
5.2.3 Medición funcional y no-funcional
Este primer componente del modelo está relacionado con el reforzamiento de la medición
funcional de software y la incorporación técnicas de medición no-funcional tanto para
estimaciones indicativas como detalladas a lo largo del ciclo de vida del software. Para
este componente se han especificado dos (2) requisitos que se muestran en la Tabla 5-2
y Tabla 5-3.
Tabla 5-2: Requisito de medición funcional
No. 1
Nombre: Esquema de medición funcional
Componente: Medición funcional y no-funcional
Prioridad: Alta
Justificación: El esquema actual de medición funcional basado en el estándar del IFPUG se aplica de forma heterogénea en los diferentes proyectos de software que adelanta el área de TI de la organización.
Descripción: Implementar una estrategia de aplicación de la técnica Análisis de Puntos Funcionales (FPA- Function Point Analysis) del IFPUG versión 4.3.1 la cual debe estar soportada en documentación y entrenamiento para las personas involucradas con temas de medición funcional de software tanto a nivel interno (personal de la organización) como externo (personal de las firmas de outsourcing en desarrollo y mantenimiento de software).
Criterios de Aceptación: El esquema de medición funcional es utilizado de manera homogénea para todos los
proyectos de software y está apoyado en documentación y un esquema de entrenamiento.
Supuestos y restricciones: Es requerido un programa de entrenamiento sobre medición funcional basada en puntos
funcionales. Es requerido un cuerpo de conocimiento documentado sobre medición funcional basada en
puntos funcionales del IFPUG. En este sentido, se debería gestionar una metodología de medición y estimación de software.
Tabla 5-3: Requisito de medición no-funcional
No. 2
Nombre: Esquema de medición no-funcional
Componente: Medición funcional y no-funcional
Prioridad: Alta
Justificación: El esquema actual de medición no-funcional está basado en la técnica de juicio de expertos que no permite crear reglas uniformes de aplicación ni permite trazabilidad en materia de medición de software.
Descripción: Implementar un enfoque de medición no-funcional utilizando la técnica más reconocida actualmente en la industria denominada Software Non-Functional Assesment Process (SNAP). Esta técnica es promovida y respaldada por el IFPUG y se asemeja en su aplicación al proceso de medición de puntos funcionales. Se debe documentar el proceso de acuerdo con las reglas del método y se debe divulgar su aplicación a través de entrenamiento al personal interno y externo de la organización involucrado en temas de medición de software.
88 Modelo de Medición y Estimación de Proyectos de Software
Criterios de Aceptación: Los requisitos no-funcionales de los proyectos son medidos utilizando la técnica de SNAP
Points, la cual está soportada por documentación propia de la organización y un esquema de entrenamiento.
Supuestos y restricciones: Es requerido un programa de entrenamiento sobre medición no-funcional basada en SNAP
Points Es requerido un cuerpo de conocimiento propio de la organización sobre medición no-
funcional basado en SNAP Points. En este sentido se debería gestionar una metodología de medición y estimación de software.
5.2.4 Estimación de software
Este componente del modelo está relacionado con la estimación de esfuerzo, duración y
costo de las actividades asociadas al desarrollo de proyectos de software. La Tabla 5-4
presenta la especificación del requisito.
Tabla 5-4: Requisito de estimación de software
No. 3
Nombre: Modelo de estimación de software
Componente: Estimación de software
Prioridad: Alta
Justificación: El esquema actual de estimación de software está basado en (1) un enfoque fragmentado de productividad en construcción de software y (2) la técnica de juicio de expertos.
Descripción: Implementar un enfoque integral de estimación de esfuerzo y duración para la construcción de software. A nivel indicativo (conjunto de alternativas propuestas):
o Contar con un set de ecuaciones derivadas de proyectos de repositorios de industria (i.e. ISBSG) para estimar a un alto nivel el esfuerzo y duración de la construcción del software.
o Utilizar la técnica de comparación que identifica un conjunto de proyectos finalizados con atributos similares a los del nuevo proyecto. Estos proyectos finalizados pueden ser seleccionados desde un repositorio de industria (i.e. ISBSG) o uno que debe comenzar a documentar la organización.
o Utilizar la técnica de analogía que consiste en identificar un proyecto finalizado de similares atributos y utilizar sus valores para realizar la estimación del nuevo proyecto. Este proyecto finalizado puede ser seleccionado de un repositorio de industria (i.e. ISBSG) o uno que debe comenzar a documentar la organización.
A nivel detallado (conjunto de alternativas propuestas): o Utilizar un modelo de Estructura de Descomposición de Trabajo (WBS-Work Breakdown
Structure) basado en actividades estándares de industria para el desarrollo de software que apliquen para la organización. Ejemplo de estas actividades son las que se encuentran en estándar ISO/EIC 12207 [70] el cual establece las actividades del proceso de ciclo de vida del software.
o Implementar un modelo de estimación conducido por los datos de la organización donde a partir de datos de proyectos anteriores se puedan utilizar técnicas de comparación y analogía para la respectiva estimación.
o Implementar un modelo de estimación conducido por los datos de la organización donde a partir de datos de proyectos anteriores se puedan utilizar técnicas paramétricas tales como regresión o Constructive Cost Model II (COCOMO II).
Capítulo 5 89
Criterios de Aceptación: La estimación del esfuerzo, duración y costo de los proyectos se hace a través de alguna de
las alternativas planteadas tanto a nivel indicativo como a nivel detallado. La técnica del juicio de expertos únicamente es válida en los casos en los cuales la(s)
actividad(es) a desarrollar es (son) nueva(s) para la organización.
Supuestos y restricciones: Se requiere el registro permanente del esfuerzo y duración de las actividades asociadas a
los proyectos de software en un repositorio organizacional. Datos históricos incorrectos o incompletos pueden conducir a estimaciones erróneas.
5.2.5 Especificación de requisitos
Una de las actividades más complejas de medir y estimar está relacionada con la
especificación de requisitos de software. Una de las razones principales tiene que ver con
que a pesar de que puede llegar a ser un proceso sistemático en cierta medida, lograr la
especificación de un requisito adecuado puede ser una labor que involucra un esfuerzo y
duración considerables, más allá de los inicialmente planeados, en la medida en que en
muchas situaciones la labor de extraer de los usuarios finales la información necesaria y
adecuada para especificar el requisito resulta ser una labor demasiado compleja. La Tabla
5-5 presenta la especificación del requisito.
Tabla 5-5: Requisito de estimación en especificación de requisitos
No. 4
Nombre: Especificación de requisitos
Componente: Especificación de requisitos
Prioridad: Baja
Justificación: Las actividades relacionadas con especificación de requisitos involucran duraciones que no son planeadas y se extienden indefinidamente sin mayores controles asociados al esfuerzo realizado.
Descripción: Implementar un mecanismo de registro de esfuerzo en la consecución de requisitos funcionales y no-funcionales. Sobre este repositorio se pueden utilizar técnicas de analogía, comparaciones y regresiones para estimar esfuerzos en la especificación de requisitos de proyectos futuros. Los esfuerzos asociados a la especificación, se deben articular con la medición funcional y no-funcional obtenida de los requisitos. De esta forma se obtienen valores de referencia de puntos funcionales y SNAP Points por números de páginas de requisitos, casos de uso y otras métricas similares relacionadas con especificación de requisitos.
Criterios de Aceptación: Cada uno de los requisitos especificados se encuentra relacionado en el repositorio de
esfuerzo, detallando atributos tales como: complejidad de la especificación, tipo de usuario final, tipo de requisito, duración de la actividad, analistas de negocio involucrados y tipo de proyecto.
Supuestos y restricciones: Se requiere el registro permanente del esfuerzo y duración de las actividades asociadas a la
especificación de requisitos funcionales y no-funcionales. Datos históricos incorrectos o incompletos pueden conducir a estimaciones erróneas.
90 Modelo de Medición y Estimación de Proyectos de Software
5.2.6 Construcción de software
La construcción de software comprende las etapas de análisis, diseño e implementación
del software.
Tabla 5-6: Requisito de productividad
No. 5
Nombre: Productividad en la construcción de software
Componente: Construcción de software
Prioridad: Alta
Justificación: La estimación en la construcción del software está basada en tasas de productividad uniformes sin diferenciar plataforma (v.g. mainframe, cliente/servidor, etc.), lenguaje de programación (v.g. 3GL, 4GL), tipo de desarrollo (v.g. nuevo desarrollo, mejora, etc.).
Descripción: Se deben definir tasas de productividad (expresadas en horas por punto funcional y horas por SNAP Point) para los siguientes conductores de desarrollo de software:
Plataforma: Mainframe, Cliente/Servidor y N-capas Lenguaje de programación: Java, .NET, Oracle, Scripting. Tipo de desarrollo: Nuevo desarrollo, Mejora.
Igualmente, se debe crear una tasa de productividad genérica para todas aquellas combinaciones de plataforma, lenguaje de programación y tipo de desarrollo no contemplado en el listado anterior. Cada tasa de productividad debe construirse con base en el modelo de actividades sugerido por Jones [48] para construcción de software. La siguiente tabla presenta las actividades sugeridas para la construcción de software que deben ser consideradas para determinar las tasas de productividad tanto de construcción del componente funcional como del no-funcional.
No. Actividad Esfuerzo Funcional
(Horas)
Esfuerzo No-Funcional
(Horas)
1 Análisis de requisitos
2 Prototipos
3 Arquitectura
4 Inspección de arquitectura
5 Planeación y estimación del proyecto
6 Diseño inicial
7 Diseño detallado
8 Inspección de diseño
9 Codificación
10 Inspección de código
11 Análisis estático
12 Control de la configuración
13 Integración de código
Criterios de Aceptación: Existen tasas de productividad para distintas plataformas, lenguajes de programación y tipos
de desarrollo. Las tasas de productividad aplican tanto para desarrollo del componente funcional como del
no-funcional del software.
Capítulo 5 91
Supuestos y restricciones:
Las productividades iniciales pueden ser determinadas a partir de los valores de referencia de industria que sugieren autores como Jones en [48] y [71].
Las revisiones de productividad subsiguientes deben ser obtenidas a partir de los datos históricos de proyectos anteriores. En este sentido, datos históricos incorrectos o incompletos pueden conducir a estimaciones erróneas.
5.2.7 Pruebas de software
Las pruebas de software comprenden diferentes tipos y niveles. La Tabla 5-7 contiene las
actividades más representativas que se realizan en la etapa de pruebas de software según
el modelo de Jones [71]. La Tabla 5-8 detalla el requisito para lograr este componente del
modelo propuesto.
Tabla 5-7: Actividades asociadas a las pruebas de software
No. Actividad No. Actividad
1 Pruebas unitarias 8 Pruebas de sistema
2 Pruebas funcionales 9 Pruebas de campo (Beta)
3 Pruebas de regresión 10 Pruebas de aceptación (UAT)
4 Pruebas de integración 11 Pruebas independientes
5 Pruebas de desempeño 12 Aseguramiento de la calidad
6 Pruebas de seguridad 13 Pruebas de sistema
7 Pruebas de usabilidad 14 Pruebas de campo (Beta)
Tabla 5-8: Requisito de estimación de pruebas
No. 6
Nombre: Estimación de las pruebas de software
Componente: Pruebas de software
Prioridad: Alta
Justificación: No existen mecanismos de medición y estimación para realizar pruebas de software más allá de la técnica de juicio de expertos.
Descripción: Se debe implementar un modelo de estimación para la etapa de pruebas de software. Se proponen tres alternativas en este sentido. Estimaciones basadas en el esfuerzo de desarrollo de software. Los métodos que usan este
criterio se basan en el hecho de que las pruebas de software dependen del esfuerzo de desarrollo [72]. El proceso de estimar el esfuerzo de pruebas consiste, primero, en estimar el esfuerzo de desarrollo mediante cualquiera de las técnicas que existen, por ejemplo COCOMO o SLIM. Posteriormente a través de una heurística específica, se relacionan los valores de esfuerzo del desarrollo para obtener valores de referencia del esfuerzo en pruebas de software [73]. Se presentan a continuación ejemplos para la heurística planteada utilizando valores de estudios realizados por Jones [74]:
o Para un sistema tipo de 1.000 puntos funcionales desarrollado en Java como lenguaje de programación principal se tienen los siguientes valores para pruebas de software:
92 Modelo de Medición y Estimación de Proyectos de Software
- Se realizan pruebas unitarias, funcionales, de integración de sistema y de
aceptación de usuario final. - Tiene un potencial de 4.087 defectos que tienen como principales fuentes de
error los requisitos (11%), el diseño (24%), el código (53%) y la documentación (4%).
- La cantidad de defectos por punto funcional es 4,09 - La eficiencia en la remoción de defectos es del 96% - Los casos de prueba asociados son 5.016 para los diferentes niveles de
pruebas y tipos de pruebas tales como pruebas de regresión, de componentes y de desempeño.
- La cantidad de casos de prueba por punto funcional es 5,02 - El cubrimiento de pruebas es aproximadamente del 92% - El pico de complejidad ciclomático probable es 15
Estimaciones basadas en el tamaño del software. El criterio principal para los métodos de
esta categoría es el tamaño del software. Los métodos de este enfoque parten igualmente de la premisa que el esfuerzo de las pruebas es directamente proporcional al tamaño del software. Existen varios enfoques:
o Jones [27] relaciona casos de prueba con el número de puntos funcionales del sistema.
o Veenendaal y Dekkers [75] desarrollaron un método conocido como Análisis de Puntos de Prueba (TPA-Test Point Analysis), en el cual el número de puntos de prueba se deriva de los puntos funcionales. Posteriormente, operando el número de puntos de pruebas junto con un factor ambiental y un factor de productividad se obtiene el esfuerzo de pruebas. Este método también ha sido revisado recientemente por otros autores como Santos [53] y Souza y Barbosa [54] quienes crearon una técnica alternativa conocida como Análisis de Puntos de Prueba Adaptados (ATPA - Adapted Test Point Analysis) la cual también está basada en el tamaño del software utilizando puntos funcionales.
Estimaciones basadas en los casos de prueba. Este enfoque se basa en el número de casos de prueba y los diferentes escenarios que conforman las pruebas para calcular el esfuerzo de pruebas de software. Arahna y Borba [76] y Xiaochum et al. [77] definen métodos de estimación similares utilizando conductores de número de casos de prueba y complejidad de la ejecución de las pruebas.
Criterios de Aceptación: La fase de pruebas de los proyectos de software utiliza un enfoque de estimación de acuerdo
con alguno de los escenarios propuestos.
Supuestos y restricciones:
En el caso eventual de utilizar un enfoque de estimación de pruebas basado en puntos funcionales, la medición del software es requisito indispensable ya sea desde la etapa de especificación de requisitos o antes de la finalización de la construcción del software.
5.2.8 Mantenimiento de software
Para efectos del modelo, se asume el mantenimiento de software como una etapa más
dentro del ciclo de vida de los proyectos de software. En la realidad, la mayoría de las
actividades de mantenimiento de software se enmarcan dentro de un proyecto que tiene
inicio y fin, un objetivo que persigue un resultado específico y un conjunto de recursos
asignados para cumplirlo. La estimación aplica para (1) mantenimiento adaptativo o de
mejoramiento, el cual incluye modificaciones a raíz de nuevos requisitos funcionales o
Capítulo 5 93
técnicos; (2) mantenimiento preventivo que abarca cambios de hardware o software
efectuados para prevenir defectos o fallas futuras y (3) mantenimiento perfectivo que
incluye modificaciones de plataforma, optimización del rendimiento y otras actividades
relacionadas con preservar los acuerdos de niveles de servicio. Referente al
mantenimiento correctivo, orientado a la corrección de defectos, no hay enfoques definidos
para estimar el esfuerzo de esta actividad debido principalmente a la incertidumbre que se
genera alrededor la forma de corregir un defecto que aparece en un sistema de software
en operación. La Tabla 5-9 describe el requisito de mantenimiento de software.
Tabla 5-9: Requisito de mantenimiento de software
No. 7
Nombre: Estimación del mantenimiento
Componente: Mantenimiento de software
Prioridad: Alta
Justificación: El mantenimiento adaptativo, preventivo y perfectivo de software se estima parcialmente desde el diseño hasta la entrega para pruebas de usuario final (UAT-User Acceptance Testing).
Descripción: Se debe implementar un enfoque integral de estimación de mantenimiento de software. Se sugiere un modelo basado en la historia de la organización con valores iniciales extraídos de repositorios de industria además de algunos estudios específicos sobre la materia. La tabla que se muestra a continuación presenta un modelo de esfuerzo para diferentes escenarios de mantenimiento de software. Para algunos escenarios, la estructura y formulación está basada en [78] y los factores y de esfuerzo y fórmulas de estimación son ejemplos propuestos por el autor de esta investigación.
Escenario de mantenimiento
Factor de esfuerzo
Modelo de estimación de esfuerzo (horas)
Mantenimiento adaptativo
1.00
Factor de Esfuerzo x [(Tamaño funcional nueva Funcionalidad x Tasa de productividad funcional) + (Tamaño no-funcional nueva funcionalidad x Tasa
de productividad No-funcional)]
Mantenimiento preventivo
1.00
Factor de Esfuerzo x [(Tamaño funcional nueva Funcionalidad x Tasa de productividad funcional) + (Tamaño no-funcional nueva funcionalidad x Tasa
de Productividad No-funcional)]
Mantenimiento perfectivo
1.00 Factor de Esfuerzo x [Tamaño no-funcional nueva
funcionalidad x Tasa de Productividad No-funcional]
Adición a funcionalidad existente con incremento de funcionalidad.
1.00 Factor de Esfuerzo x [Tamaño nueva funcionalidad
x Tasa de productividad funcional]
Modificación a funcionalidad existente sin incremento de funcionalidad.
0.20 Factor de Esfuerzo x [Tamaño nueva funcionalidad
x Tasa de productividad funcional]
Eliminación de funcionalidad existente
0.15 Factor de Esfuerzo x [Tamaño nueva funcionalidad
x Tasa de productividad funcional]
Requisitos no-funcionales 1.00 Factor de Esfuerzo x [Tamaño no-funcional nueva
funcionalidad x Tasa de productividad No-funcional]
Criterios de Aceptación:
94 Modelo de Medición y Estimación de Proyectos de Software
Las labores de mantenimiento de software son conducidas por el modelo de estimación de
esfuerzo propuesto.
Supuestos y restricciones: Para aplicar este modelo de estimación de mantenimiento, el software a intervenir debe estar
medido en puntos funcionales.
5.2.9 Esquema de contratación de software
Este componente resulta fundamental dentro del modelo propuesto por cuanto la gran
mayoría de los proyectos de software de la organización objeto de estudio son
desarrollados por firmas de outsourcing en desarrollo de software. En este sentido, es
necesario contar con acuerdos contractuales ajustados a un enfoque de desarrollo de
proyectos de software basados en medición funcional y no-funcional como principales
conductores de la estimación del proyecto. La Tabla 5-10 describe las características más
importantes que debe tener la contratación de desarrollo y mantenimiento de software.
Tabla 5-10: Requisito de contratación
No. 8
Nombre: Aspectos de contratación de software
Componente: Esquema de contratación de software
Prioridad: Alta
Justificación: En un modelo de construcción de software que hace uso de firmas de outsourcing en desarrollo de software, es necesario implementar acuerdos contractuales que contengan aspectos propios de una estrategia basada en medición funcional y no-funcional.
Descripción: En los contratos de desarrollo de software para nuevos proyectos o proyectos de mantenimiento se deben tener en cuenta los siguientes aspectos: Pruebas de concepto para selección de proveedores. Es necesario validar que las firmas que
participan en los procesos de contratación de desarrollo de software tengan un nivel adecuado de conocimiento y habilidades en la aplicación de las reglas de medición y estimación de software.
Tasas de productividad diferenciadas para nuevos desarrollos y mantenimiento de software. Se deben establecer a nivel contractual acuerdos de servicio en términos de las tasas de productividad para diferentes plataformas, lenguajes de programación y tipos de desarrollo.
Implementación de métricas de calidad basadas en puntos funcionales. El desarrollo de software debe estar sujeto al cumplimiento de métricas de calidad como por ejemplo niveles acordados de densidad de defectos por punto funcional (número máximo de defectos inyectados por punto funcional entregado).
Pagos de acuerdo con la cantidad de funcionalidad entregada al cliente. Solamente se realizan pagos por artefactos de software recibidos en términos de cantidad de funcionalidad (puntos funcionales y SNAP Points).
Esfuerzo del soporte técnico y funcional del sistema en ambiente de producción como factor del tamaño del producto. El esfuerzo que realiza el proveedor de servicios de soporte técnico y funcional sobre el software debe ser directamente proporcional al tamaño del sistema en términos de puntos funcionales y SNAP Points.
Criterios de Aceptación: Los contratos con firmas de outsourcing en desarrollo siguen los acuerdos propuestos.
Capítulo 5 95
Supuestos y restricciones: Los acuerdos contractuales que se logren con este enfoque deben realizarse sobre proyectos
que utilicen la medición funcional y no-funcional basada en puntos funcionales y SNAP Points.
Las firmas que realicen acuerdos contractuales siguiendo estas pautas deben tener experiencia en medición y estimación de software más allá de los métodos tradicionales y/o apertura para modificar sus procesos de ingeniería de software y gerencia de proyectos.
5.2.10 Oficina de medición y estimación de software
Uno de los componentes esenciales del modelo es lo que el autor de esta investigación ha
denominado una Oficina de Medición y Estimación de Software. Esta área organizacional
está conformada por un grupo de expertos en temas de medición y estimación de software
que provee dirección, liderazgo, mejores prácticas y entrenamiento entre otras actividades
fundamentales, en el ecosistema de la organización para proveer estimaciones confiables
y efectivas a lo largo del ciclo de vida de los proyectos de software. Su implementación
requiere el reconocimiento de esta disciplina dentro de la ingeniería de software y la
gerencia de proyectos como algo que demanda habilidades, actitudes y comportamientos
específicos. En la documentación que se encuentra al respecto algunas de estas oficinas
son una extensión de la Oficina de Gerencia de Proyectos (PMO-Project Management
Office) del área de TI de la organización [79]. En el campo de la estimación de software,
esta área también se conoce como Centro de Excelencia en Estimación (ECoE –
Estimation Center of Excellence). La Tabla 5-11 muestra la especificación de la
conformación de esta área organizacional mientras que la Tabla 5-12 contiene las
funciones mínimas que debe desempeñar.
Tabla 5-11: Requisito oficina de medición y estimación
No. 9
Nombre: Conformación de la oficina de medición y estimación
Componente: Oficina de medición y estimación
Prioridad: Media
Justificación: Debe existir un rol dentro de la organización que tenga la responsabilidad de liderar las labores relacionadas con medición y estimación de software.
Descripción: Se debe implementar una estructura dentro del área de Tecnología de Información responsable de liderar las actividades relacionadas con medición y estimación de software. Se sugiere que esta área de negocio tenga un grado de formalidad suficiente para que pueda desempeñar adecuadamente sus funciones.
Criterios de Aceptación: Existe una estructura organizacional que lidera temas relacionados con medición y
estimación de software.
96 Modelo de Medición y Estimación de Proyectos de Software
Supuestos y restricciones: El planteamiento de la creación de la oficina de medición y estimación es de alto nivel, por
ello no se propone personal a ser asignado, niveles de autoridad ni asignación parcial o total de los recursos.
Tabla 5-12: Requisito funciones de la oficina de medición y estimación
No. 10
Nombre: Funciones de la oficina de medición y estimación
Componente: Oficina de medición y estimación
Prioridad: Media
Justificación: Una vez establecida la oficina de medición y estimación de software, se deben definir las funciones que llevará a cabo.
Descripción: Las principales funciones que desempeña la oficina de medición y estimación de software son las siguientes: Gestionar herramientas de medición y estimación de software Gestionar los repositorios de datos de proyectos de la organización Gestionar la(s) metodología(s) de medición y estimación de proyectos de software Gestionar la capacitación y entrenamiento en medición y estimación de proyectos de software Brindar apoyo a proyectos en materia de medición y estimación Gestionar estándares y métricas de medición y estimación Apoyar la planeación de proyectos de software Realizar supervisión y control de proyectos en materia de medición y estimación de software
Criterios de Aceptación: La oficina de medición y estimación de software implementa las ocho (8) funciones definidas.
Supuestos y restricciones: Para implementar todas las funciones propuestas, la oficina de medición y estimación debe
tener asignados recursos adecuados y suficientes.
6. Conclusiones y recomendaciones
6.1 Conclusiones
No es suficiente la utilización de la técnica de puntos funcionales durante un periodo
específico para asegurar que la medición de software y actividades asociadas a ésta
agregan valor al proceso de desarrollo de software y contribuyen al éxito de los proyectos.
Al ser fragmentado el ejercicio de medición y estimación de software teniendo solamente
cierta fortaleza en la medición de puntos funcionales, las mediciones y estimaciones de
otras fases del ciclo de desarrollo como por ejemplo la medición no-funcional y las pruebas
de software, presentan oportunidades de mejora en la medida en que la técnica utilizada
es juicio de expertos y los involucrados en su aplicación en muchas ocasiones no son
expertos en la tecnología, el negocio que soporta el software ni en la misma utilización de
la técnica.
La falta de conocimiento, entrenamiento permanente e investigación alrededor de temas
de medición y estimación (tanto a nivel interno como externo a través de las empresas de
outsourcing que desarrollan software para la organización objeto de estudio) permiten que
los conteos de software y las posteriores estimaciones sean subjetivos y que dependan en
muchos casos de las personas que realizan la actividad.
En general, existen oportunidades de mejora en todos los aspectos que requieren medición
y estimación asociadas a las actividades necesarias para desarrollar software, esto es,
desde la especificación de los requisitos, pasando por la construcción de los componentes
funcionales y no-funcionales así como de las pruebas de software. De igual forma, es
importante contar con herramientas que faciliten el registro de información histórica y otras
que apoyen el proceso de estimación de esfuerzo. Se deben complementar las prácticas
actuales en materia de contratación de software en la modalidad de outsourcing para incluir
98 Modelo de Medición y Estimación de Proyectos de Software
aspectos relevantes sobre medición y estimación. Finalmente, se debe realizar una
revisión y modificación del esquema actual de entrenamiento y documentación disponible.
Fue acertado definir el alcance de este trabajo de investigación sin incluir la
implementación del modelo propuesto por cuanto este frente depende en su mayoría de
las prioridades y recursos de la organización objeto de estudio. Esta implementación
implica iniciar un proyecto de tecnología que demanda recursos importantes para su
consecución. Si este alcance hubiera sido incluido como parte de los objetivos de este
trabajo, existiría un riesgo muy alto de cumplirlo.
6.2 Recomendaciones
Existen oportunidades para investigar en mayor profundidad la mayoría de los temas
planteados en este trabajo de investigación. Como resultado, es de especial interés para
el autor hacer investigación en tres temas de medición y estimación: (1) Del componente
no-funcional del software, (2) En pruebas de software y (3) En mantenimiento de software.
En cuanto a medición y estimación del componente no-funcional del software, sería
interesante abordar aspectos relacionados con métodos tradicionales y emergentes y
presentar resultados de su aplicación en distintos contextos que involucren desarrollo de
software.
En cuanto a la medición y estimación de pruebas de software, hay mucho camino por
recorrer. Es un tema en general novedoso que merece la pena ser estudiado en
profundidad y explorar posibilidades de aplicarlo en un contexto local, donde por ejemplo,
se han venido consolidando firmas dedicadas exclusivamente a la realización de pruebas
de software en un modelo de tercerización.
En cuanto a medición y estimación del mantenimiento de software y en particular aquel
que no tiene que ver con adición de funcionalidad, existen varias oportunidades de
investigación en lo referente a proponer modelos en los cuales se puedan planear de mejor
forma los mantenimientos preventivos, perfectivos y correctivos de software.
A. Anexo: Entrevista sobre medición y estimación de software
Entrevista sobre Medición y Estimación de Software El objetivo de esta entrevista es identificar fortalezas y oportunidades de mejora en términos de la medición y estimación de software que se realiza en el Banco de la República para los proyectos de TI que involucran desarrollo de software. * Requerido
1. ¿Cuál es su opinión acerca de la medición y posterior estimación basada en Puntos
Funcionales que se realiza en el Banco? *
2. ¿Cuál es su opinión acerca de la forma de estimar el componente No-Funcional en los
proyectos nuevos y de desarrollo de software? *
3. ¿Considera necesaria la adopción de técnicas paramétricas para la medición y
estimación en la fase de especificación de requisitos? *
4. ¿Considera necesaria la adopción de técnicas paramétricas para la medición y
estimación en la fase de pruebas del software? *
5. ¿Cuál es su opinión sobre la implementación de un esquema para almacenar y gestionar
el resultado de las mediciones funcionales y no-funcionales tanto para proyectos nuevos
como de mantenimiento? *
6. ¿Cuáles dificultades encuentra en la medición y estimación de proyectos de
mantenimiento? *
7. ¿Cuáles dificultades encuentra para establecer contratos de desarrollo de software
basados en medición de puntos funcionales? *
8. ¿Considera importante contar con herramientas reconocidas en la industria para realizar
estimación de proyectos de software? *
9. ¿Cuál es su opinión acerca de la documentación disponible en el Banco sobre medición
y estimación de software? *
10. ¿Cuál es su opinión acerca del nivel de conocimiento del personal del Banco en temas
de medición y estimación de software? *
11. ¿Cuál es su opinión acerca del nivel de conocimiento del personal de los contratistas en
temas de medición y estimación de software? *
100 Modelo de Medición y Estimación de Proyectos de Software
B. Anexo: Entrevista sobre medición y estimación de software
Encuesta sobre Medición y Estimación
I. PERFIL DEL ENCUESTADO Las preguntas que siguen a continuación permiten definir el perfil demográfico del encuestado 1. Profesión Ingeniería de Sistemas
Ingeniería Industrial
Ingeniería Electrónica
Otra- ¿Cuál?: ____________________
2. Nivel educativo más alto completado: Técnico/Tecnológico
Pregrado
Especialización
Maestría
Doctorado
3. Edad: Entre 20 y 25
Entre 25 y 30
Entre 30 y 35
Entre 35 y 40
Entre 40 – 45
Más de 45
4. Género: Masculino
Femenino
Anexo B 101
5. Experiencia
No tengo
experiencia Entre 0 y 1
años Entre 1 y 2
años Entre 2 y 3
años Entre 3 y 4
años Más de 5
años
Análisis de Software
Diseño de Software
Desarrollo de Software
Medición y/o
Estimación de Software
6. Tipo de organización en la que trabaja: Proveedor de servicios de desarrollo de software
Cliente que recibe servicios de desarrollo de software
II. MEDICIÓN FUNCIONAL La medición funcional de software se refiere al cálculo del tamaño del producto de software a ser construido en términos de la funcionalidad que ofrecerá. Es el principal conductor de la estimación del esfuerzo de proyectos de software. Existen varios métodos para realizar medición funcional entre los que se destacan: Story Points, Use Case Points, Feature Points, 3-D Function Points, Full Function Points, Function Points, COSMIC Function Points, FISMA Function Points, NESMA Function Points y Mark II Function Points entre otros. Algunas de las preguntas que se formulan a continuación hacen referencia al estándar de Puntos Funcionales (PF's) del IFPUG. 7. De los siguientes, seleccione cuáles estándares de medición funcional de software conoce: IFPUG
COSMIC
FISMA
NESMA
Líneas de Código
Otro(s)- ¿Cuáles?: ____________________
Ninguno
102 Modelo de Medición y Estimación de Proyectos de Software
8. ¿Qué tan larga ha sido su experiencia realizando medición funcional de software? 0 – 1 años
1 – 2 años
2 – 3 años
3 – 4 años
4 – 5 años
Más de 5 años
No he realizado este tipo de medición
9. ¿En cuántos proyectos ha realizado medición funcional? 0
1
2
3
4
5
Más de 5
10. ¿Cuáles dificultades encuentra en la aplicación de las reglas de medición en puntos funcionales? Se requiere conocimiento del negocio
Los requisitos no tienen la calidad apropiada
Las reglas son ambiguas y dependen de la opinión del contador
Los ejemplos documentados no son prácticos
El vocabulario de las reglas no es apropiado y/o confuso
La curva de aprendizaje es muy larga y toma mucho tiempo su aplicación
No funcionan para todos los tipos de software existentes
Es difícil tener acceso a documentación de Puntos Funcionales
El manual oficial es diferente a la documentación on-line existente
Otra(s) - ¿Cuáles? ____________________
Ninguna dificultad
11. ¿Ha recibido entrenamiento para el conteo de puntos funcionales? Sí
No
12. ¿Cuántas horas de entrenamiento en conteo de puntos funcionales ha recibido? Entre 1 y 5 horas
Entre 5 y 10 horas
Entre 10 y 20 horas
Más de 20 horas
No he recibido entrenamiento
13. ¿Cuántos puntos funcionales ha medido en diferentes periodos? Realice su mejor aproximación.
Anexo B 103
No he
realizado conteos
0-500 PF's 500-1000 PF's 1000-2000
PF's Más de 2000
PF's
Últimos 6 meses
Último año
Últimos 2 años
Últimos 3 años
14. ¿Conoce técnicas/enfoques más efectivos para medir el tamaño funcional del software? Sí - ¿Cuáles? ____________________
No
15. ¿Ha planeado conseguir alguna certificación en términos de medición funcional? Sí - ¿Cuáles? ____________________
No
16. De acuerdo con su experiencia, la medición funcional es más apropiada para: Nuevos proyectos
Proyectos de Mantenimiento
Nuevos proyectos y Proyectos de Mantenimiento
Ninguno
III. MEDICIÓN NO-FUNCIONAL La Medición No-Funcional se refiere al componente técnico del software y los atributos de calidad (Seguridad, Disponibilidad, Mantenibilidad, Usabilidad, etc.). 17. De los siguientes estándares de medición No-funcional, , cuáles conoce y/o ha aplicado: SNAP - IFPUG
NFSM - COSMIC
Otro - ¿Cuáles? ____________________
Ninguno
18. ¿Cuál es el enfoque que aplica para realizar la medición del componente No-Funcional del software (sobre productos o requisitos)? Juicio de Expertos
Modelo propietario
Otro - ¿Cuál? ____________________
Ninguno
19. ¿Conoce técnicas/enfoques más efectivos para medir el tamaño No-funcional del software? Sí - ¿Cuáles? ____________________
No
104 Modelo de Medición y Estimación de Proyectos de Software
20.¿Ha planeado conseguir alguna certificación en términos de medición No-Funcional? Sí - ¿Cuáles? ____________________
No
IV. ESTIMACIÓN DE PROYECTOS DE SOFTWARE La estimación de software tiene que ver con la creación de una valoración cuantitativa en lo referente a costos, recursos, esfuerzo y duración. El objetivo primordial de la estimación de software es realizar una provisión de una aproximación de la cantidad de recursos requeridos para completar las actividades del proyecto y entregar el producto/servicio requerido. 21. ¿Conoce algunas de las siguientes técnicas para estimar el esfuerzo de desarrollo de software? Modelos de Regresión
COCOMO II (Constructive Cost Model)
Planning Poker
CoBRA (Cost Estimation, Benchmarking and Risk Assessment)
PRICE-S (Parametric Review of Information for Costing and Evaluation)
Software Estimating Model (SEER-SEM)
Modelo de Putnam (SLIM)
Ninguno
22. ¿Cuál es la técnica que regularmente usa para estimar proyectos de software (nuevos o de mantenimiento)? Juicio de Expertos
Modelo propietario
Otro - ¿Cuál? ____________________
V. OTROS ASPECTOS Las preguntas a continuación hacen referencia a elementos transversales de Medición y Estimación en el contexto del ciclo de desarrollo de software. 23 ¿Considera que la documentación existente en su organización en términos de Medición y Estimación es suficiente? Sí
No
No la conozco
24. ¿Considera que la documentación existente en su organización en términos de Medición y Estimación es útil? Sí
No
No la conozco
Anexo B 105
25. ¿Considera útil la incorporación de técnicas de medición para la Especificación de Requisitos? Sí. ¿Por qué? ____________________
No - ¿Por qué? ____________________
26. ¿Considera útil la incorporación de técnicas de medición para las Pruebas de software? Sí. ¿Por qué? ____________________
No - ¿Por qué? ____________________
Bibliografía
[1] Project Management Institute, Practice Standard for Project Estimating, Primera ed.,
Newtown Square, Pennsylvania: PMI, 2011.
[2] A. Trendowicz y R. Jeffery, Software Project Effort Estimation, Berlin: Springer-Verlag, 2014.
[3] M. Bundschuh y C. Dekkers, The IT Measurement Compendium, Berlin: Springer-Verlag ,
2008.
[4] M. Chemuturi, «Effort Estimation for Software Projects,» de The IFPUG Guide to IT and
Software Measurement, IFPUG, Ed., Boca Raton, Florida, CRC Press, 2012, pp. 97-120.
[5] C. Jones, «A Proposed Suite of Thirteen Functional Metrics for Economic Analysis,» de The
IFPUG Guide to IT and Software Measurement, IFPUG, Ed., Boca Raton, FL, CRC Press, 2012,
pp. 3-28.
[6] F. Gómez, Historia del Banco de la República 60 años, Bogotá: Talleres Gráficos, Banco de la
República, 1983.
[7] Banco de la República, Introducción al análisis económico. El caso colombiano, Segunda ed.,
Bogotá: Siglo del Hombre Editores, 1998.
[8] M. Roca, El Banco de la República: antecedentes, evolución y estructura., Bogotá: Banco de
la República - Departamento Editorial , 1990.
[9] Banco de la República, Primer programa de gestores, Bogotá: Banco de la República -
Departamento Editorial, 2001.
[10] Banco de la República, «Sitio Web del Banco de la República,» 07 2016. [En línea]. Available:
http://www.banrep.gov.co. [Último acceso: 05 07 2016].
[11] F. Celis, Creación de valor en la banca central a través de Tecnología de Información - Caso
colombiano, Bogotá: Banco de la República, 2003.
[12] Banco de la República - Dirección General de Tecnología, «Intranet - Sede SharePoint de la
DG-T,» 09 07 2016. [En línea]. Available: http://dgt. [Último acceso: 09 07 2016].
Bibliografía 107
[13] Banco de la República - Subgerencia de Informática, «Visión Tecnológica – Tendencias de
Infraestructura para los próximos 3 años,» Subgerencia de Informática, Bogotá, 2003.
[14] Banco de la República - Dirección General de Tecnología, «Intranet - Sede SharePoint de la
DG-T - DGI,» Dirección General de Tecnología, 08 07 2016. [En línea]. Available:
http://dgt/dgi. [Último acceso: 08 07 2016].
[15] Banco de la República, «Intranet - Infobanco,» 10 07 2016. [En línea]. Available:
http://infobanco. [Último acceso: 10 07 2016].
[16] Banco de la República, «Repositorio de Procesos y Procedimientos,» 12 07 2016. [En línea].
Available: http://aris. [Último acceso: 12 07 2016].
[17] Project Management Institute, PMBOK-Project Management Body Of Knowledge, Cuarta
ed., Newton Square, Pennsylvania: PMI, 2008.
[18] Banco de la República, «Organigrama,» 09 06 2016. [En línea]. Available:
http://www.banrep.gov.co/sites/default/files/paginas/organigrama.pdf. [Último acceso: 13
07 2016].
[19] Project Management Institute, The Standard For Portfolio Management, Newton Square:
PMI, 2013.
[20] Banco de la República, Reporte de Sistemas de Pago, Bogotá: Banco de la República, 2013.
[21] Banco de la República - Departamento de Gestión Informática, «Puntos Funcionales,»
Documento Interno, Bogotá, 2003.
[22] IFPUG- The International Function Points Users Group, Function Point Counting Practices
Manual Release 4.1.1, 4.1.1 ed., Princenton Juntion, New Jersey : IFPUG, 2000.
[23] IFPUG- The International Function Points Users Group, Function Point Counting Practices
Manual Release 4.3.1, 4.3.1 ed., Princenton Juntion, New Jersey : IFPUG, 2010.
[24] Qualtrics, 4 2016. [En línea]. Available: http://www.qualtrics.com.
[25] N. Fenton y J. Bieman, Software Metrics. A Rigorous and Practical Approach, Tercera ed.,
Boca Raton, Florida: CRC Press, 2015.
[26] D. Hubbard, How to Measure Anything: Finding the Value of Intangibles in Business,
Segunda ed., Hoboken, New Jersey: John Wiley and Sons, 2010.
[27] C. Jones, Applied Software Measurement Global Analysis of Productivity and Quality 3rd
Edition, Third Edition ed., New York: Mc Graw Hill, 2008.
10
8
Modelo de Medición y Estimación de Proyectos de Software
[28] C. Jones, Estimating Software Costs: Bringing Realism to Estimating 2nd Edition, Segunda
ed., New York, NY: McGraw-Hill, 2007.
[29] A. Abran, Software Metrics and Software Metrology, Hoboken, New Jersey : IEEE Computer
Society, 2010.
[30] A. Albrecht, «Measuring Application Development Productivity,» IBM Applications
Development Symposium, Monterey, California, 1979.
[31] IFPUG - International Function Points Users Group, Function Point Counting Practices
Manual Release 4.3.1, Princenton Juntion, NJ USA: IFPUG, 2010.
[32] ISO - International Organization for Standardization, «ISO/IEC 14143:2012. Functional Size
Measurement,» Geneva,Switzerland, 2012.
[33] ISO - International Organization for Standardization, «ISO/IEC 20926:2009. IFPUG functional
size measurement method.,» Geneva, Switzerland, 2009.
[34] ISO - International Organization for Standardization, «ISO/IEC 24570:2005. NESMA
functional size measurement method versión 2.1.,» Geneva, Switzerland, 2005.
[35] ISO - International Organization for Standardization, «ISO/IEC 29881:2010. FiSMA 1.1
functional size measurement method.,» Geneva, Switzerland, 2010.
[36] ISO - International Organization for Standardization, «ISO/IEC 20968:2002. MK II Function
Point Analysis – Counting Practices Manual,» Geneva, Switzerland, 2002.
[37] ISO - International Organization for Standardization, «ISO/IEC 19761:2011. COSMIC: A
functional size measurement method.,» Geneva, Switzerland, 2011.
[38] C. Green, D. Bradley, T. Ben-Cnaan , W. Bloomfield, D. Garmus, J. Venkat, S. Chizar y L.
Santillo, «Software Non-Functional Assessment Process,» de The IFPUG GUide to IT and
Software Measurement, Boca Raton, Florida , CRC Press, 2012, pp. 495-523.
[39] IFPUG - International Function Points Users Group, Software Non-functional Assessment
Process (SNAP) 2.2, 2.2 ed., Princenton Junction, New Jersey: IFPUG, 2011.
[40] ISO - International Organization for Standardization, «ISO 9126-1:2001, Software
Engineering – Product Quality – Part 1: Quality,» Geneva, Switzerland, 2001.
[41] IFPUG - International Function Points Users Group, Software Non-functional Assessment
Process (SNAP) Release 2.3, 2.3 ed., Princenton Junction, New Jersey: IFPUG, 2015.
Bibliografía 109
[42] IFPUG- The International Function Points Users Group, «Integrating Procedures for Function
Point Analysis and the Software Non-functional Assessment Process (SNAP) - Part 1,»
Princenton Juntion, New Jersey, 2016.
[43] IFPUG - International Function Points Users Group, «Integrating Procedures for Function
Point Analysis and the Software Non-functional Assessment Process (SNAP) - Part 2,»
Princenton Juntion, New Jersey, 2016.
[44] Project Management Institute, PMBOK-Project Management Body Of Knowledge, Quinta
ed., Newton Square, Pennsylvania: PMI, 2013.
[45] B. Boehm, Software engineering economics, Englewood Cliffs, New Jersey: Prentice-Hall,
1981.
[46] S. McConnell, Software estimation: demystifying the black art, Redmond, MA : Microsoft
Press, 2006.
[47] P. Hill, Practical Software Project Estimation. A toolkit for Estimating Software Development
Effort & Duration, New York, New York: ISBSG, 2011.
[48] C. Jones, The Mess of Software Metrics, Sexta ed., N. A. LLC, Ed., Rhode Island: Namcook
Analytics LLC, 2015.
[49] L. Buglione, The Next Frontier: Measuring and Evaluating the NonFunctional Produtivity,
Primera ed., Roma: ISBSG, 2012.
[50] K. Wiegers, More About Software Requirements: Thorny Issues and Practical Advice.,
Redmond, WA : Microsoft Press, 2006.
[51] H. Hofmann y F. Lehner, «Requirements Engineering as a Success Factor in Software
Projects,» IEEE Software, vol. 18, nº 4, p. 58–66, Julio 2001.
[52] I. Hooks y K. Farry, Customer-Centered Products: Creating Successful, New York, New York:
AMACOM, 2001.
[53] L. Santos, «An experience in estimating Software Testing Effort,» de The IFPUG Guide to IT
and Software Measurement, IFPUG, Ed., Boca Raton, Florida, CRC Press, 2012, pp. 151-160.
[54] P. Souza y M. Barbosa, «Tailoring the test point analysis estimation technique in a software
testing process,» de IV Encontro Brasileiro de Testes (EBTS), Recife, 2010.
[55] IFPUG - International Function Points Users Group, «IFPUG International Function Points
Group Website,» IFPUG, 7 2017. [En línea]. Available: http://www.ifpug.org. [Último acceso:
14 10 2016].
11
0
Modelo de Medición y Estimación de Proyectos de Software
[56] COSMIC, «COSMIC,» COSMIC, 8 2016. [En línea]. Available:
www.cosmicon.com/portal/dl.asp. [Último acceso: 14 10 2016].
[57] COSMIC, «The COSMIC Functional SIze Measurement Method Version 4.0.1. Measurement
Manual,» Canada, 2015.
[58] M. Kassab, O. Ormandjieva, M. Daneva y A. Abran, «Non-Functional Requirements Size
Measurement Method (NFSM) with COSMIC-FFP,» International Conference, IWSM-
Mensura 2007, pp. 168-182, Noviembre 2008.
[59] COSMIC, «COSMIC SIZING,» 8 2016. [En línea]. Available: http://cosmic-sizing.org/. [Último
acceso: 14 10 2016].
[60] FiSMA, «FiSMA,» FiSMA, 8 2016. [En línea]. Available: http://www.fisma.fi/in-english/.
[Último acceso: 14 10 2016].
[61] United Kinkdom Software Metrics Association, «United Kinkdom Software Metrics
Association,» 11 2016. [En línea]. Available: http://www.uksma.co.uk/. [Último acceso: 12
10 2016].
[62] NESMA - Netherlands Software Metrics Association, «NESMA,» 10 2016. [En línea].
Available: http://nesma.org/. [Último acceso: 12 10 2016].
[63] ISBSG - International Software Benchmarking Standards Group), «ISBSG Repository Data,»
ISBSG, 9 2016. [En línea]. Available: http://isbsg.org/software-project-data/. [Último acceso:
17 10 2016].
[64] QSM - Quantitative Software Management, «QSM Software Project Database,» 11 2016. [En
línea]. Available: http://www.qsm.com/resources/qsm-database. [Último acceso: 17 10
2016].
[65] US Department of Defense, «DoD Modeling and Simulation (M&S) Glossary - DoD Manual
5000.59-M,» US Department of Defense, Arlington, VA, , 1998.
[66] S. Friedenthal, A. Moore y R. Steiner, A Practical Guide to SysML: The Systems Modeling
Language, Needham, MA: OMG Press, 2012.
[67] G. Bellinger, «Systems Thinking - Modeling & Simulation An Introduction,» 3 2017. [En
línea]. Available: http://www.systems-thinking.org/modsim/modsim.htm. [Último acceso:
14 04 2017].
[68] D. Dori, Object-Process Methodology: A Holistic System Paradigm, New York, New York:
Springer, 2002.
Bibliografía 111
[69] Object Management Group, «MDA Foundation Model,» Object Management Group,
Needham, MA, USA, 2010.
[70] ISO - International Organization for Standardization, «ISO/IEC 12207 Systems and software
engineering – Software life cycle processes,» ISO-International Organization for
Standardization, Geneva,Switzerland, 2008.
[71] C. Jones, «Function Points as a Universal Software Metric,» ACM SIGSOFT Software
Engineering, vol. 38, nº 4, pp. 1-27, Julio 2013.
[72] S. Nageswaran, «Test effort estimation using use case points,» Quality Week, pp. 1-6, Junio
2001.
[73] D. Torres, «Un método para medir la productividad del equipo de pruebas en la estimación
del esfuerzo de pruebas de software,» Universidad Nacional de Colombia, Medellín,
Colombia, 2013.
[74] C. Jones, «Variations In Software Development By Function Point Size,» IFPUG MetricViews,
pp. 11-13, Agosto 2016.
[75] E. Veenendaal y T. Dekkers, «Test point analysis: a method for test estimation,» Project
control for software quality, pp. 45-49, Abril 1999.
[76] E. Aranha y P. Borba, «An Estimation Model for Test Execution,» de First International
Symposium on Empirical Software Engineering and Measurement, Madrid, Spain, 2007.
[77] Z. Xiaochun, Z. Bo, H. Li, Q. Yi y C. Lu, «Estimate Test Execution Effort at an Early Stage: An
Empirical Study,» de International Conference on Cyberwolds, Hangzhou, China, 2008.
[78] J. Mayes, «Saving the World One Project at a Time: Planning by the Numbers,» Cutter IT
Metrics Strategies, vol. 6, nº 12, pp. 5-16, Diciembre 2000.
[79] D. Horvath, «Getting your Projects off to a Good Start Using a Project Initiation Center of
Excellence,» Metrics Views, vol. 11, nº 1, pp. 12-14, Febrero 2017.
[80] Project Management Institute, The Standard For Program Management, Newton Square,
New Jersey: PMI, 2013.
Glosario
ACH: Automated Clearing House. Cámara de Compensación Automatizada. Es una red
electrónica para realizar transacciones financieras. Procesa grandes volúmenes de
transacciones de crédito y débito en lotes.
BVC: Bolsa de Valores de Colombia.
CCDC: Cámara de Compensación de Divisas de Colombia S. A.
Componente del portafolio: proyecto o programa de proyectos dentro de un portafolio
de proyectos.
Charter: un documento emitido por el patrocinador del proyecto que autoriza
formalmente la existencia de un proyecto y confiere al gerente de proyecto la autoridad
para usar los recursos de la organización en las actividades del proyecto.
CRCC: Cámara de Riesgo Central de Contraparte de Colombia S. A
Deceval: entidad privada en Colombia encargada de la custodia y administración de
títulos de deuda privada.
DET: Data Element Type. Atributo único, no repetido, identificable por el usuario.
DOFA: análisis DOFA. Metodología de estudio de la situación de una empresa o un
proyecto, analizando sus características internas (Debilidades y Fortalezas) y
su situación externa (Amenazas y Oportunidades). Proviene de las siglas en inglés
SWOT (Strengths, Weaknesses, Opportunities y Threats).
Glosario 113
Framework: marco de referencia.
FTR: File Type Referenced. Función de datos leída y/o mantenida por una función
transaccional.
ISBSG: organización sin ánimo de lucro fundada en 1997 por un grupo de asociaciones
de Estados Unidos relacionadas con métricas de software. Su misión es ayudar a las
organizaciones a mejorar la planeación y la gestión de proyectos de software a través
de repositorios de datos de proyectos de desarrollo y mantenimiento además de reportes
y libros relacionados con tópicos de medición y estimación de software.
IFPUG: organización sin ánimo de lucro que tiene como propósito promover la gestión
efectiva de actividades de desarrollo y mantenimiento de software, a través de
estándares de tamaño de software y otras técnicas de medición de software.
Juicio de Expertos: técnica en la cual un juicio o afirmación es hecha basada en un
conjunto específico de criterios y/o experiencia que ha sido adquirida un área específica
de conocimiento, producto, disciplina o industria.
Punto Funcional: Function Point en inglés. Creados en 1979 por Allan Albretch. Es una
unidad de medida para expresar la cantidad de funcionalidad de negocio en un sistema
de información que es entregada a un usuario final. Los Puntos Funcionales son usados
para calcular el tamaño funcional del software. Existen varios estándares reconocidos
parea medición del tamaño del software basado en puntos funcionales:
COSMIC: ISO/IEC 19761:2011
FiSMA: ISO/IEC 29881:2010
IFPUG: ISO/IEC 20926:2009
Mark-II: ISO/IEC 20968:2002
NESMA: ISO/IEC 24570:2005
11
4
Modelo de Medición y Estimación de Proyectos de Software
Qualtrics: compañía de investigación en software basada en Provo, Utah, Estados
Unidos. Provee una plataforma de encuestas en línea. Enlace:
https://www.qualtrics.com/
MEC: Mercado Electrónico Colombiano. Propiedad de la Bolsa de Valores de Colombia
S. A.
Programa de Proyectos: grupo de proyectos relacionados que son gestionados de una
forma coordinada para obtener beneficios que NO podrían ser alcanzados cuando estos
proyectos son gestionados individualmente [80].
Proyecto: esfuerzo temporal llevado a cabo para crear un producto, servicio o resultado
único [44].
RFP: Request For Proposal. Es una solicitud de propuesta realizada a menudo a través
de un proceso de licitación, por parte de una compañía interesada en
el aprovisionamiento de un producto o un servicio a proveedores potenciales.
RET: Record Element Type. Es un subgrupo de elementos de datos reconocible por el
usuario, dentro de una función de datos.
SET-FX: sistema electrónico de transacción en moneda extranjera, administrado por
Servicios Integrados en Mercado Cambiario S. A., con el respaldo de la Bolsa de Valores
de Colombia S. A. y SIF-ICAP de México.
SNAP Point: Software Non-functional Assessment Process. Es una medida del tamaño
no-funcional del software. Es un complemento a la medición de puntos funcionales, la
cual mide el tamaño funcional del software. Es un producto del IFPUG y es medido
usando el Non-functional Assessment Practices Manual.
Glosario 115
Sponsor: persona o grupo que tiene autoridad para proveer financiamiento, aprobar
cambios al alcance del proyecto y proveer direccionamiento de alto nivel sobre el
proyecto.
Stakeholder: persona u organización como clientes, patrocinadores, organización
ejecutante o el público, involucrados activamente con el proyecto o cuyos intereses
pueden verse afectados de manera positiva o negativa por la ejecución o conclusión del
proyecto.
Test Point: medida para analizar la funcionalidad que necesita ser probada en un
Proyecto de software. Sirve para estimar los casos de prueba requeridos y el esfuerzo
en las pruebas de software.
