UNIVERSIDAD VERACRUZANA

FACULTAD DE ESTADÍSTICA E INFORMÁTICA

Maestría en Ingeniería de
Software

Metodología de estimación de costos

para microempresas desarrolladoras de
software en México

TESIS

QUE COMO REQUISITO PARCIAL PARA OBTENER EL

GRADO DE MAESTRÍA

ELABORÓ:

Edith nicet Melgoza Toral

DIRIGIÓ:
Dra. María de los Ángeles Sumario López

Xalapa, Ver. Junio 2009.

 UNIVERSIDAD VERACRUZANA

FACULTAD DE ESTADÍSTICA E INFORMÁTICA

Maestría en
Ingeniería de
Software

C. ISC. Edith llicet Melgoza Tora!

Candidata a la Maestría en
Ingeniería de Software
PRESENTE

Por este medio comunico a usted el dictamen aprobatorio de la comisión

revisora integrada por:

Dra. María de los Ángeles Sumano López Directora

Dr. Juan Manuel Fernández Peña Jurado interno
Mtra. Angélica Cerdán Jurado interno
Mtra Edith Hernández Lagunes Jurado externo

Para el trabajo titulado “Metodología de estimación de costos para

microempresas desarrolladoras de software en México ”.

En consecuencia, se autoriza la impresión del trabajo, para continuar con los

trámites correspondientes.

ATENTAMENTE
“LIS DE VERACRUZ: ARTE, CIENCIA, LUZ”
Xalapa-Enríquez, Veracruz, a 10 de junio de 2009

Dr. Juan Manuel Fernández Peña

Coordinador de la MIS

Av. Xalapa esquina Ávila Camacho s/n, CP 91020, Xalapa, Ver.

Tel +52(228)842-1700 ext 14154. Fax 814-9990 e-mail [email protected]
Agradecimientos

Quiero agradecer a todos los que de una u otra manera me acompañaron mientras
cursaba mi maestría y llevaba a cabo mi tesis.

A Dios, mi guía y camino que siempre esta dentro de mi.

A los tres hombres más importantes en mi vida: José, Pablo y Armando. Mi papi, mi
ejemplo; mi abuelito, mi ángel guardián y mi corazón.

A mi mamá Edith, por su cariño y sus consejos.

A mis hermanos: Ipsae y José, por su ayuda en los momentos difíciles.

A mis primos Emely, Ricardo, Jaime y Vale.

A mi tutora y amiga la Dra. María de los Ángeles Sumano López.

A mi amigo Adán Aguilar.

A toda mi familia y amigos que estuvieron conmigo a lo largo de toda esta parte de mi
vida.

A mis maestros del Tecnológico y de la Universidad que me apoyaron con ideas y

resolviendo encuestas.

Hoy he terminado una etapa de mi vida, mi Maestría, de la que puedo expresar que
me siento satisfecha del conocimiento adquirido a lo largo de dos años de estudios y
casi uno más en el trabajo de mi tesis, me alegra haber concluido llevando conmigo
muy buenos recuerdos, buenos amigos y buenos maestros.
Resumen

En los últimos años, en la República Mexicana han aparecido empresas cuyocampo de

trabajo es el desarrollo de software. Algunas de éstas han llegado a posicionarse en el
mercado nacional e inclusive internacional, contando con procesos definidos e historial
de desarrollo que les permite estimar un costo adecuado para su producto.

En contraparte, existen empresas cuyo tamaño, falta de antigüedad u otras

características más intrínsecas a si mismas, no les permite establecer un costo
adecuado a su producto. Lo único con lo que pueden contar es con métricas de
software ya establecidas, lo que lleva a la siguiente pregunta:

¿Cómo interpretar las métricas utilizadas en las empresas para estimar costos en las
PYMES de México?

Se piensa además que existen condiciones particulares de operación interna de las

PYMES y externas de! mercado particular en México, que deben ser consideradas para
determinar el costo del producto a desarrollar.

En el presente trabajo se describen fundamentos teóricos y se detalla el estudio

práctico que sirvieron como base para sustentar una propuesta de estimación de
costos para PYMES, así como un método de estimación de costos de software.
Contenido

Resumen............................................................................................. <............ iii

Capítulo 1. Introducción.............................................................................. 1

1.1. Antecedentes............................................................................................ 1

1.2. Necesidad del uso de métricas.................................................................... 2

1.3. Exposición general del problema...... .■......................................................... 2

1.4. Situación actual del uso de métricas de software en empresas de México........ 3

1.5. Pregunta de investigación..........................................................................4

1.6. Objetivos..... ............................ 4

1.6.1. Objetivo general.............................................................. 4

1.6.2. Objetivos específicos........................................................................... 4

1.7. Alcance del proyecto................................................................................. 4

1.8. Estructura del trabajo................................................................................ 5

Capítulo 2. Marco Teórico..................................................................................... 6

2.1. Métricas de software................................................................................. 6

2.1.1. Métricas de los flujos fundamentales del desarrollo de software............... 6

2.2. Métricas en el flujo de análisis....................................................................7

2.2.1. Puntos de Función............................................................................... 8

2.2.1.1. Cálculo de puntos de función sin ajustar..........................................8

2.2.1.2. Cálculo de puntos de función ajustados......................................... 10

2.2.2. Puntos de Casos de Uso..................................................................... 13

2.2.2.1. Cálculo de Puntos de Casos de Uso sin ajustar............................... 14

2.2.2.2. Cálculo de Puntos de Casos de Uso ajustados................................ 15

2.2.3. COCOMO II............................................................. 18

2.2.3.1. Nivel de construcción de prototipos........ .......................................18

 2.3. Ejemplos de aplicación de Métricas............................................................ 19

2.3.1. Caso de Estudio................................................................................ 20

2.3.2. Medición de tamaño por medio de Puntos de Función;............................ 20

2.3.3. Medición de tamaño por medio de Puntos de Casos de Uso.................... 22

2.4. Estimación del esfuerzo........................................................................... 25

2.4.1. Estimación del esfuerzo por medio de Puntos de Función....................... 26

2.4.2. Estimación del esfuerzo por medio de puntos de Casos deUso................ 28

2.4.3. Ejemplo de estimación del esfuerzo por COCOMO II.............................. 29

2.5. Contabilidad de Costos............................................................................ 30

2.5.1. Tipos de costos................................................................................. 30

2.5.1.1. Según su función........................................................................ 30

2.5.1.2. Según su grado de variabilidad..................................................... 31

2.5.1.3. Según su asignación................................................................... 31

Capítulo 3. Estudio de Campo sobre el uso de métricas y estimaciones.................... 33

3.1. Planteamiento del estudio de campo.......................................................... 33

3.1.1. Objetivo del estudio.......................................................................... 33

3.1.2. Proceso a seguir................................................... 33

3.2. Etapa 1: Empresas certificadas................................................................. 35

,3.2.1. Planteamiento de la entrevista............................................................ 35

3.2.2. Resultados Etapa 1. Entrevista a Empresas Certificadas......................... 36

3.2.3. Conclusiones de la Etapa 1................................................................. 39

3.3. Etapa 2: PYMES....................................................... :............................. 40

3.3.1. Planteamiento del cuestionario...........................................................40

3.3.2. Resultados Etapa 2. Cuestionario a PYMES...........................................40

3.3.2.1. Descripción de los resultados.......................................................44

3.3.3. Conclusiones de la Etapa 2............................................................ 50

 3.4.1. Planteamiento de la entrevista............................................................ 50

3.4.2. Resultados Etapa 3.................................................................. 51

3.4.3. Conclusiones de la Etapa 3................................................................. 52

Capítulo 4. Propuesta de Metodología de Estimación.............................................. 53

4.1. Características........................................................................................ 53

4.2. Procedimiento a seguir para aplicar la metodología propuesta...................... 53

4.2.1. Descripción de las variables principales................................................ 54

4.2.1.1. Modificadores relacionados al Esfuerzo...................................... 55

4.2‘.1.2. Modificadores relacionados con el Calendario................................. 56

4.2.1.3. Modificadores relacionados con el Costo........................................57

4.2.2. Descripción de la metodología......................................... 58

4.3. Ejemplo de aplicación de la metodología propuesta............. 58

4.3.1. Obtención del esfuerzo...................................................................... 59

4.3.2. Obtención del calendario....................................... 59

4.3.3. Obtención del Costo.......................................................................... 60

4.3.4. Costo total del Proyecto........... 61

Capítulo 5. Modelado del Sistema de Software EcPymes........................................ 62

5.1. Modelo de Casos de Uso de EcPymes......................................................... 62

5.1.1. Caso de Uso Estima Esfuerzo.............................................................. 63

5.1.2. Caso de Uso Estima Calendario........................................................... 63

5.1.3. Caso de Uso Estima Costo.................................................................. 64

5.1.4. Caso de Uso Guarda Estimación.......................................................... 64

5.1.5. Caso de Uso Abre Estimación Previa.................................................... 65

5.1.6. Caso de Uso Almacena Históricos........................................................ 65

. 5.2. Realización de Casos de Uso de Diseño................................................'..... 66

 5.2.1. Realización del Caso de Usode diseño: Estima Esfuerzo........................ 56

5.2.2. Realización del Caso de Usode diseño: Estima Calendario...................... 69

5.2.3. Realización del Caso de Uso de diseño: Estima Costos............... :.......... 70

5.2.4. Realización del Caso de Usode diseño: Guarda Estimación..................... 73

5.2.5. Realización del Caso de Usode diseño: Abre Estimación Previa............... 74

5.2.6. Realización del Caso de Usode diseño: Almacena Históricos................... 75

Capítulo 6. Comprobación de la metodología........................................................ 79

6.1. Descripción de los sistemas...................................................................... 79

6.2. Comparación con la opinión del experto...................... 80

6.3. Comparación con estimaciones hechas por PYMES...................................... 81

6.4. Conclusiones de la comprobación de la metodología.................................... 82

Conclusiones.................................................................................................... 83

Bibliografía................................................... 86

Apéndices........................................................................................................ 88

Anexos........................................................................................................... 133
Lista de Ecuaciones

Ecuación 2.1. Cálculo del Multiplicador de Complejidad............................... 12

Ecuación 2.2. Cálculo de Puntos de Función.......................................................... 13

Ecuación 2.3. Cálculo del Peso de los Casos de Uso sin ajustar............................... 14

Ecuación 2.4. Cálculo del Peso de los Actores sin ajustar....................................... 15

Ecuación 2.5. Cálculo de Puntos de Casos de Uso sin ajustar................................. 15

Ecuación 2.6. Cálculo de! Factor de Complejidad Técnica....................................... 16

Ecuación 2.7. Calculo del Factor de Complejidad del Ambiente............................... 17

Ecuación 2.8. Cálculo del Ajuste de Puntos de Casos de Uso.................................. 17

Ecuación 2.9. Cálculo del Esfuerzo Nivel de Prototipos COCOMO II.......................... 19

Ecuación 2.10. Obtención del Multiplicador de Complejidad.................................... 22

Ecuación 2.11. Cálculo de Puntos de Función......................................................... 22

Ecuación 2.12. Cálculo de Puntos de Casos de Uso sin ajustar................................. 24

Ecuación 2.13. Cálculo del Factor de Complejidad Técnica....................................... 24

Ecuación 2.14. Cálculo del Factor de Complejidad del Ambiente............................... 25

Ecuación 2.15. Cálculo de Puntos de Casos de Uso................................................. 25

Ecuación 2.16. Fórmula para el cálculo del esfuerzo.......... 28

Ecuación 2.17. Esfuerzo en Personas/Mes obtenido por COCOMO II, Construcción de

Prototipos......................................................................................................... 29
Lista de Figuras

Figura 2.1. Gráficos de un Caso de Uso................................................................. 13

Figura 2.2. Incremento del costo por Punto de Función.......................................... 27

Figura 3.1. Diagrama de actividades del estudio de campo..................................... 34

Figura 3.2. Estimación del esfuerzo...................................................................... 45

Figura 3.3. Métricas de estimación....................................................................... 46

Figura 3.4. Comparación entre el registro de estimaciones de proyectos y registro de

proyectos terminados......................................................................................... 47

Figura 3.5. Factores a considerar para estimar el costo......................................... 48

Figura 3.6. Factores que se toman en cuenta por complejidaddel proyecto...............49

Figura 3.7. Factores para determinar el precio de venta................................. 49

Figura 4.1. Diagrama de Flujo de la Metodología de Estimación de Costos................ 54

Figura 5.1. Modelo de Casos de Uso.................................................................... 63

Figura 5.2. (a) Diagrama de Secuencia: Estima Esfuerzo....................................... 67

Figura 5.2. (b) Diagramas de clases correspondientes a la estimación del esfuerzo. ..68

Figura 5.3. (a) Diagrama de Secuencia: Estima Calendario.................................... 69

Figura 5.3. (b) Diagrama de clases correspondiente a la estimación delcalendario.... 70

Figura 5.4. (a) Diagrama de Secuencia: Estima Costo. ......................................... 71

Figura 5.4. (b) Diagrama de clases correspondiente a la estimación delcalendario....71

Figura 5.4. (c) Clases correspondientes a las pestañas de la estimación de costo..... 72

Figura 5.5. (a) Diagrama de Secuencia: Guarda Estimación.................................... 73

Figura 5.5. (b) Diagrama de clases correspondiente al guardado deestimación.......... 74

Figura 5.6. (a) Diagrama de Secuencia: Abre Estimación previa...............................74

Figura 5.6. (b) Diagrama de clases correspondiente a la apertura de un proyecto

previamente guardado....................................................................................... 75

Figura 5.7. (a) Diagrama de Secuencia: Almacena históricos.................................. 76

Figura 5.7. (b) Diagramas de clases correspondientes al almacenado de datos
históricos.......................................................................................................... 77

Figura 5.8. Diagrama de subsistemas de EcPymes. 78

Lista de Tablas

Tabla 2.1. Tipo de archivos y su descripción.......................................................... 9

Tabla 2.2. (a) Asignación de complejidad para Funciones de Datos........................... 9

Tabla 2.2. (b) Asignación de complejidad para Salidas y Consultas Externas............. 10

Tabla 2.2. (c) Asignación de complejidad paraEntradas Externas............................. 10

Tabla 2.3. Valor de los Identificadores................................................................. 10

Tabla 2.4. (a) Escala de valores para los modificadores de Puntosde Función........... 12

Tabla 2.4. (b) Ejemplo de asignación del grado de influencias para el modificador
actualización en línea......................................................................................... 12

Tabla 2.5. Criterios de Complejidad de los Casos de Uso...................................... 14

Tabla 2.6. Criterios de Complejidad de los Actores............................................... 15

Tabla 2.7. Factores de Complejidad Técnica........................................................ 16

Tabla 2.8. Factores de Complejidad del Ambiente................................................ 17

Tabla 2.9. Productividad medida en Puntos de Objeto............................................ 19

Tabla 2.10. (a) Archivos lógicos internos y de interfaz externa................................ 20

Tabla 2.10. (b) Entradas, Salidas y Consultas Externas......................................... 21

Tabla 2.11. Cálculo de Puntos de Función sin ajustar............................................. 21

Tabla 2.12. Modificadores de Complejidad............................................................ 22

Tabla 2.13. Complejidad de los Casos de Uso....................................................... 23

Tabla 2.14. Peso los Casos de Uso sin ajustar....................................................... 23

Tabla 2.15. Complejidad de los Actores............................................................... 23

Tabla 2.16. Peso de los Actores sin ajustar........................................................... 23

Tabla 2.17. Influencia y Peso de los Factores de ComplejidadTécnica....................... 24

Tabla 2.18. Influencia y peso de los Factores del Ambiente..................................... 25

Tabla 2.19. Incremento del costo por Punto de Función.......................................... 28

Tabla 3.1. (b) Herramientas a utilizar para el desarrollo......................................... 37

Tabla 3.1. (c) Características utilizadas para medición del Software............. .'.......... 37

Tabla 3.1. (d) Métricas de estimación de características delSoftware........................ 38

Tabla 3.1. (e) Razones para utilizar las métricas especificadas................................ 38

Tabla 3.1. (f) Descripción de cálculo de métricas................................................... 38

Tabla 3.1. (g) Descripción de estimaciones........................................................... 39

Tabla 3.1. (h) Relación entre métricas y estimaciones............................................ 39

Tabla 3.1. (i) Otros conceptos para realizar estimaciones........................................39

Tabla 3.2. (a) Datos Generales del Entrevistado.................................................... 41

Tabla 3.2. (b) Estimación del esfuerzo en general.................................................. 41

Tabla 3.2. (c) Información sobre Métricas de Software.......................................... 41

Tabla 3.2. (d) Información sobre Métricas de Software.......................................... 42

Tabla 3.2. (e) Información sobre consejos de expertos................... 42

Tabla 3.2. (f) Información sobre comparaciones con proyectos previos................. ...42

Tabla 3.2. (g) Información sobre estimación de costos.......................................... 43

Tabla 3.2. (h) Opinión con respecto al método de estimación................................. 44

Tabla 3.3. Métricas y su uso en las empresas........................................................ 45

Tabla 3.4. (a) Elementos relacionados con el Modificador Esfuerzo y suinfluencia...... 51

Tabla 3.4. (b) Elementos relacionados con el Modificador Calendarioy suinfluencia.. 52

Tabla 4.1 Distribución de Trabajo estimada de los desarrolladores.......................... 59

Tabla 4.2 Salarios estimados del personal desarrollador de software........................ 60

Tabla 4.3 Costos indirectos................................................................................ 61

Tabla 5.1 Descripción del Caso de Uso Estima Esfuerzo.......................................... 63

Tabla 5.2 Descripción del Caso de Uso Estima Calendario....................................... 64

Tabla 5.3 Descripción del Caso de Uso Estima Costo.............................................. 64

Tabla 5.5 Descripción del Caso de Uso Abre Estimación Previa............................... 65

Tabla 5.6 Descripción del Caso de Uso Almacena Históricos................................... 66

Tabla 5.7 Descripción de Casos de Uso................................................................ 78

Tabla 6.1. Descripción de casos de estudio........................................................... 80

Tabla 6.2. Comparación de costos estimados con base en la opinión de expertos..... 81

Capítulo 1. Introducción

En todo proyecto de software, en sus comienzos, se hace necesario estimar el esfuerzo

que será necesario aplicar para, sobre esa base, calcular tiempos, número de
participantes, gastos y finalmente el precio para el cliente. A pesar de los años que
lleva la industria de software, estos problemas persisten y son especialmente
importantes para empresas nuevas y pequeñas, como un gran número de las que
existen en México. El presente trabajo busca contribuirá la solución del problema.

1.1. Antecedentes

Las métricas y los procesos de estimación de software tienen su origen en la década de

1960, con su forma más simple: contar líneas de código; la cual es utilizada como base
para medir sólo el tamaño, con ésta era posible ilevar a cabo una estimación del
tamaño de! código; el problema comenzó cuando el número de lenguajes de
programación se incrementó y diversificó, ya que este tipo de métrica resultaba
imprecisa y hasta injusta [Fenton, N. (2000)].

Posteriormente, a mediados de la década de 1970, surgió el interés por medir la

complejidad del Software independientemente del lenguaje de programación, de ahí
surgió la necesidad de crear nuevas métricas, tales como puntos de función y puntos
de casos de uso, entre otras.

Al igual que la mayoría de los elementos relacionados con las Tecnologías de la

Información, la evolución de las métricas también se relaciona con la evolución de los
equipos de cómputo. Bill Gates, dijo en una entrevista "... en un principio, no había
nadie con esta ¡dea loca de tener computadoras realmente baratas. Había muy pocas
computadoras, había computadoras muy grandes que eran propiedad del gobierno y
de las grandes empresas. La gente les temía. Tenían lo que se llamaban tarjetas
perforadas y las computadoras cometían errores. Se logró un gran cambio y ahora
vemos a las computadoras como algo que nos permite publicar información, aprender
y que capacita a las personas" [Gates, B. (2007)].

Con el aumento del uso de los equipos de cómputo personales y de la necesidad de

software, también fueron aumentando el número de empresas desarrolladoras. Que al
ir creciendo, van ganando experiencia y un historial de desarrollo por medio del cual
les es posible comparar un proyecto nuevo, con uno previo y realizar una estimación
de sus características.

Resulta común que muchas pequeñas y medianas empresas (PYMES), al no contar con
la práctica mencionada anteriormente, carezcan de un modo confiable de estimar las
características de un proyecto de Software. Así pues, lo que las PYMES hacen, es
implementar sus propias heurísticas (métodos), basadas en su experiencia, para con
ellas cobrar a sus clientes el sistema de software que les desarrollarán 1. En su
mayoría, consideran al estimar un costo la complejidad del proyecto comparando éste
con sistemas desarrollados previamente. Ésta situación, además de resultar
impráctica, empobrece la imagen del informático en el mercado.

1.2. Necesidad del uso de métricas

Al llevar a cabo la medición de un objeto, se compara éste con un patrón relacionado

con la característica que quiere conocerse (longitud, peso, área, por mencionar
algunos). La finalidad de realizar esta comparación es contar con una mayor
información del objeto en cuestión. Por su parte, al comparar proyecto de software con
un patrón definido, es posible describir de manera aproximada diversas características
de éste, como son tamaño, tiempo de desarrollo, costo del proyecto, entre otros.

El propósito de toda métrica de Software es brindar al desarrollador un valor

cuantitativo de una característica del programa. Existen diversos tipos de métricas que
se utilizan a lo largo de todo el proceso de desarrollo de sistemas de Software, como
son; puntos de función, en el análisis de requerimientos; grafos, para el caso del
diseño con la finalidad de medir la complejidad; medición de líneas de código, durante
la codificación, y; modelos de confiabilidad para las pruebas. Siendo, para la
estimación de costos de software, las métricas de análisis de requerimientos las más
importantes.

1.3. Exposición general del problema

En nuestro país, se han ¡do creando PYMES desarrolladoras de Software que en su

mayoría cuentan con un reducido número de empleados. En su mayoría, son empresas

1 Estudio realizado por la Facultad de Informática de la Universidad Veracruzana en el año 2002.

de nueva creación que, como ya se mencionó, no cuentan con un marco de referencia
debido a que la mayoría de los proyectos que llevan a cabo son nuevos para éstas.
Además, generalmente elaboran proyectos de desarrollo de Software por pedido, lo
cual representa que tienen un tiempo limitado para llevar éste a cabo.

Al contar con una reducida cantidad de personal, un tiempo restringido y no tener

referencia histórica previa, las PYMES no siempre pueden llevar a cabo una medición
formal de las características del software que van a desarrollar y por lo tanto, no
pueden realizar una estimación de costos adecuada del mismo.

Es por esto que surge la necesidad de elaborar una metodología de estimación de

costos de un proyecto de Software que se adapte a las necesidades de las PYMES.

1.4. Situación actual del uso de métricas de software en

empresas de México

Nuestro país, México, tiene un nivel de gasto en Tecnologías de la Información y

Comunicaciones (TIC) de 3.2 del Producto Interno Bruto (PIB), ubicándose en el lugar
50 a nivel mundial. Este rezago es aún mayor en términos de gasto en software, que
es seis veces inferior al promedio mundial y nueve veces menos que el de EEUU.
[Durán Rubio, S. E., (2003)].

Dado el gran potencial con que cuenta México para desarrollar esta industria, la
Secretaría de Economía, en coordinación con organismos empresariales y empresas del
sector, diseñó el Programa para el Desarrollo de la Industria del Software (PROSOFT).

Este programa contempla entre sus estrategias, el alcanzar niveles internacionales en

Capacidad de Procesos de Desarrollo de Software y ésto incluye el uso de métricas.

Actualmente, la Asociación Normalización y Certificación Electrónica A. C. (NYCE), lleva

a cabo verificaciones de acuerdo a las normas NMX-I-059/02-NYCE-2005 (nivel de
madurez de las empresas que hacen uso del Modelo de Procesos de Software,
MoProSoft) y NMX-I-006/02-NYCE-2006 (nivel de madurez de capacidad de los
procesos de las empresas que hacen uso de la norma internacional ISO/IEC-12207).
La mayoría de las empresas tienen como referencia la primera norma y generalmente
alcanzan el primer nivel de madurez en los procesos que llevan a cabo2.

1.5. Pregunta de investigación

¿Cómo interpretar las métricas utilizadas en las empresas para estimar costos en las
PYMES de México?

1.6. Objetivos

A continuación se presentan el objetivo general y los objetivos específicos a los que se

espera llegar a lo largo del presente proyecto.

1.6.1. Objetivo general

Brindar ayuda a las PYMES dedicadas al desarrollo de Software para estimar costos
para el desarrollo de Software.

1.6.2. Objetivos específicos

1. Mostrar las métricas de software y el cálculo de estimaciones más utilizado.

2. Realizar un estudio empírico que recopile información acerca de la manera en

que las empresas desarrolladoras de Software llevan a cabo las estimaciones.

3. Desarrollar un método de estimación de costos, basado en la información

teórica y práctica obtenida, que se adapte a las necesidades de las pequeñas y
medianas empresas mexicanas.

4. Elaborar un componente de Software que estime costos a partir de la métrica

utilizada y sus datos históricos y heurísticos.

1.7. Alcance del proyecto

Este proyecto se elabora con la intención de concentrar datos suficientes sobre

conceptos teóricos y prácticos de métricas y estimaciones, con base en los cuales se

2 Para más información, revisar: http://www.nyce.org.mx/ donde aparece un listado de las empresas
certificadas y el nivel de certificación que tienen.
realizará una propuesta para el cálculo de estimación de costos que se adapte a
pequeñas y medianas empresas en México.

Estos datos a analizar se refieren a la investigación bibliográfica y al estudio de campo

el cual se separará en cuatro etapas: en la primera, se elaborará una entrevista a
empresas desarrolladoras de software cuyos procesos estén bien documentados
(preferentemente con una certificación como CMMI - 3 ó MoProSoft). La segunda
etapa, consistirá en un cuestionario para PYMES donde se preguntará su forma de
estimar costo o esfuerzo a la fecha. Una tercera etapa, donde se aplicará una
entrevista también a PYMES acerca de la influencia de elementos de esfuerzo,
calendario y costo en las aplicaciones que elaboran y por ende en sus estimaciones.

1.8. Estructura del trabajo

El presente trabajo se organiza como sigue: en el capítulo 2 se presenta el Marco

Teórico, discutiendo una serie de aspectos referentes a métricas y estimaciones, que
serán útiles para este trabajo, brindando un panorama teórico del proyecto.

En el capítulo 3, el Estudio de Campo, se detalla un estudio realizado con la finalidad

de conocer la manera en que las empresas desarrolladoras de software elaboran
estimaciones de costos.

Es ya en el capítulo 4 dónde se describe la metodología de estimación de costos que se

propone, desarrollada con base en las métricas abordadas en el segundo capítulo y el
estudio empírico llevado a cabo en el tercer capítulo. Es decir, la transformación de
métricas de software a una metodología de estimación adaptable para las PYMES.

En las Conclusiones se presentan los logros alcanzados con este proyecto, los faltantes
y trabajos futuros.

Además se adicionan Apéndices y Anexos que incluyen ejemplos, formatos utilizados

en el estudio de campo y diagramas, manual de operación y pruebas de usabilidad del
componente indicado en los objetivos específicos.
Capítulo 2. Marco Teórico

En este capítulo se expondrá una recopilación bibliográfica referente a métricas de

software, su definición y sus características. Así como la descripción de algunos
métodos de medición utilizados actualmente.

2.1. Métricas de software

En la sección 1.2, se habló del origen de las métricas de software y de la necesidad de

cuantificar diferentes aspectos de un proyecto de desarrollo de software. Ahora, es
importante definir qué son las métricas de Software.

“Métricas de Software es un término colectivo utilizado para describir el producto de

las actividades referentes a la medición en Ingeniería de Software. Dicho producto
consiste en números que representan las características del Software a través de
modelos que ayudan a predecir la calidad del mismo a partir de sus requerimientos"
[Fenton, N., (2000)].

Las actividades mencionadas en la definición pueden incluir desde la cuantificación de

algún aspecto del sistema, hasta una ponderación de las cualidades del mismo, todo
ésto basado en reglas previamente definidas y, preferentemente, estandarizadas.

El resultado obtenido por medio de una medición de software, se relaciona

directamente con la fase en que ésta se realiza y la intención de la misma. En las
etapas iniciales de un proyecto, tamaño, tiempo y esfuerzo, son de las más comunes.

2.1.1. Métricas de los flujos fundamentales del desarrollo de software

Cada uno de los flujos fundamentales del desarrollo de software cuenta con al menos
una métrica, empleada para conocer algún aspecto del proyecto en el flujo específico
donde éste se encuentra.

El propósito básico de las métricas en cualquier punto durante el desarrollo de un

proyecto es "brindar información cuantitativa de la gestión del proceso, dicha
información puede utilizarse durante el proceso de desarrollo" [Jalóte, P., (2005)].

La estimación llevada a cabo durante el flujo de especificación y análisis de

requerimientos, utiliza métricas que permiten una evaluación inicial de diversos
aspectos del proyecto, tales como: tamaño, tiempo, esfuerzo y costo preeliminar. Así
como evaluar la calidad de los procesos durante la obtención de requerimientos del
mismo.

En el flujo de diseño, se hace énfasis en métricas que permitan asegurar la estabilidad

del sistema durante esta fase, se aplican también métricas de estructura, cohesión y
de acoplamiento.

Durante la fase de codificación, las métricas se abocan al tamaño y complejidad del

código. Éstas pueden compararse con las métricas llevadas a cabo durante la
especificación de requerimientos con el fin de confirmar o refutar las características
previamente estimadas del proyecto.

Por último, en el flujo de pruebas, las métricas se enfocan en la confiabilidad de las

mismas, así como en la detección de errores, se utilizan sobre todo modelos de
estimación de fallas.

Otras métricas asociadas al producto son: madurez, usabilidad, especificación, entre

otras. Dado que el presente trabajo se aboca a la estimación del costo de un software
a contratar, las secciones que siguen se concentran en las métricas de especificación y
análisis.

2.2. Métricas en el flujo de análisis

La estimación de costos de software, debería poderse llevar a cabo en una fase

temprana, como la de análisis de requerimientos o incluso antes de ésta, ya que con
ésta se plantea un presupuesto de desarrollo: una estimación rápida basada en la
experiencia previa por parte de la empresa en desarrollo de sistemas de software. Por
su importancia, es necesario profundizar más en esta etapa.

A continuación se revisarán algunas métricas utilizadas durante el flujo de análisis

como son el método de Puntos de Función, el método de Puntos de Casos de Uso y el
método COCOMO II. Se consideraron éstas por su uso generalizado en las empresas y
su relativa simplicidad de aplicación.
2.2.1. Puntos de Función

Puntos de Función es un modelo de medición de sistemas de software ampliamente

utilizado, y de hecho, existe una organización mundial que regula su uso; a saber:
International Function Point Group3.

La medición por medio de Puntos de Función tiene la ventaja de ser un método

mediante el cual se obtiene un valor cuya interpretación está estandarizada? Su unidad
es el punto de función. "Un punto de función es una métrica sintética que se
comprende de los pesos totales, de las entradas, salidas, indagaciones, archivos
lógicos o datos de usuario ... Creados a mediados de la década 1970 por A. J. Albrecht,
es un método que consiste en realizar un conteo de cinco modificadores. Los cuales se
dividen en funciones de datos y funciones transaccionales" [Jones, C. (1996)].

Los Puntos de Función registran todas las entradas, salidas, consultas, archivos lógicos
o agrupaciones de datos de usuario e interfaces pertenecientes a una aplicación. Son
definidos por Albrecht para ser "beneficios del usuario final" y se utilizan en contratos y
negociaciones entre productores de software y sus clientes. A partir de los Puntos de
Función, puede obtenerse un estimado del esfuerzo en Horas/Persona [Jones, C.
(1996)].

En los siguientes subtemas se detalla la obtención de puntos de función, los pasos,

funciones y características que se emplearán en su cálculo [tomado de Jones, C.
(1996)].

2.2.1.1. Cálculo de puntos de función sin ajustar

El primer paso consiste en realizar un conteo de cinco parámetros del sistema de

software, los cuales se dividen en: dos de datos o archivos y tres transaccionales o de
funcionalidades, mismos que se definen en la Tabla 2.1.

3 Para mayor referencia, página de Internet: www.ifpug.org

 Tabla 2.1. Tipo de archivos y su descripción.

Tipo Parámetro Descripción

Agrupaciones de datos relacionados cuyo propósito principal es

Archivos Lógicos
almacenar datos mantenidos a través de alguna transacción que se
Internos (ALI)
está considerando en el conteo.
Funciones de
Datos
Archivos de
Agrupaciones de datos relacionados y referenciados pero que no son
Interfaz Externa
mantenidos por alguna transacción dentro del conteo.
(AIE)

Entradas Externas Procesos cuyo propósito principal es mantener uno más archivos
(EE) lógicos internos.

Procesos cuyo propósito principal es presentar información al usuario

Salidas Externas
Funciones de mediante un proceso matemático diferente al de sólo recuperar los
(SE)
Transacciones datos.

Procesos cuyo propósito principal es presentar información al usuario

Consultas Externas
leída de uno o más grupos de datos, generalmente mediante
(CE)
consultas lógicas.

A cada parámetro se fe asigna un nivel de complejidad que depende del número de de

datos (Tipos de Dato Elemental, TDE) y el número de registros (Tipo de Registro
Elemental, TRE) que manejen las Funciones de Datos. Para las Funciones de
Transacciones también se lleva a cabo un conteo con base en TDE y referencias a
archivos (RA). En las Tablas 2.2 (a), (b) y' (c) se indica la manera de determinar la
complejidad.

Tabla 2.2. (a) Asignación de complejidad para Funciones de Datos.

TDE
TRE
1 - 19 20 - 50 51 ó +

0-1 Bajo Bajo Medio

2-5 Bajo Medio Alto

6ó + Medio Alto Alto

 Tabla 2.2. (b) Asignación de complejidad para Salidas y Consultas Externas.

TDE
RA
1 - 5 6-19 20 ó +

0-1 Bajo Bajo Medio

2-3 Bajo Medio. Alto

4ó + Medio Alto Alto

Tabla 2.2. (c) Asignación de complejidad para Entradas Externas.

TDE
RA
1 -4 5-15 16 ó +

0-1 Bajo Bajo Medio

2 Bajo Medio Alto

3 ó + Medio Alto Alto

Después de asignados los tipos de archivo, a cada indicador y sus rangos

correspondientes, se procede a realizar el cálculo de los Puntos de Función si ajustar
(PFA) utilizando la Tabla 2.3.

Tabla 2.3. Valor de los Identificadores.

Bajo Medio Alto Total

ALI 7 * n 10 * n 15 * n Suma ALI

AIE 5 * n 7 * n 10 * n Suma AIE

EE 3 * n 4 * n 6 * n Suma EE

SE 4 * n 5 * n 7 * n Suma SE

CE 3 * n 4 * n 6 * n Suma CE

PFA Suma Total

2.2.1.2. Cálculo de puntos de función ajustados

Para ajustar los puntos de función, se consideran catorce modificadores, que

representan los requerimientos no funcionales y son los siguientes [tomado de
Sumano López, M. A., (2006)]:
I. Comunicación de datos. Describe el grado con el cual la aplicación se
comunica directamente con el procesador.

,2. Procesamiento distribuido de datos. Mide el grado con el que la aplicación

transfiere entre componentes la misma aplicación.

3. Rendimiento. El rendimiento será crítico y tendrá influencia sobre cómo

diseñar, desarrollar o implementar.

4. Configuración altamente usada. El software será implementado en un entorno

existente y fuertemente utilizado.

5. Promedio de transacciones. Un alto promedio de transacciones influirá en el

diseño, desarrollo, implantación y soporte.

6. Entrada de datos en iínea. El software requerirá de entradas interactivas.

7. Eficiencia para el usuario final. Las funciones en línea provistas tendrán que
enfatizar un diseño para la eficiencia del usuario final.

8. Actualización en linea. Se necesitará la actualización de archivos maestros en

forma interactiva.

9. Procesamiento complejo. Describe el grado en el cual el procesamiento lógico

influye en el desarrollo de la aplicación.

10. ReusabHidad. Describe el grado en el cual la aplicación y el código en la

aplicación ha sido específicamente diseñado, desarrollado y soportado para
que se pueda utilizar en otras aplicaciones.

II. Facilidad de instalación. Describe el modo en que la conversión desde medios

ambientes previos influirán en el desarrollo de la aplicación.

12. Facilidad de operación. Describe el grado en el cual las aplicaciones atienden

los aspectos operacionales, tales como: salvar y recuperar datos y
recuperación de procesos.

13. Varios sitios. Describe el grado en el cual la aplicación será diseñada,

desarrollada e implantada en múltiples localizaciones y organizaciones de
usuarios.
14. Facilidad de cambios. Describe el grado en el cual la aplicación ha sido
desarrollada para la fácil modificación del procesamiento lógico o en las
estructuras de datos.

El valonde los modificadores va de 0 a 5, dependiendo de su grado de influencia en el

sistema (ver Tabla 2.4 (a)), posteriormente se realiza la suma de estos valores. El
método de Puntos de Función brinda una serie de pautas para la asignación del grado
de influencias, un ejemplo se ve en la Tabla 2.4 (b).

Tabla 2.4. (a) Escala de valores para los modificadores de Puntos de Función.

Valor Descripción

0 El factor no se haya presente o no tiene influencia.

1 La influencia del factor es insignificante.

2 La influencia es moderada.

3 La el grado de influencia es medio.

4 La influencia es significativa.

5 El grado de influencia es fuerte.

Tabla 2.4. (b) Ejemplo de asignación del grado de influencias para el modificador
actualización en línea.

Valor Descripción

0 No se lleva a cabo actualización en línea.

Se incluye la actualización en línea de uno a tres archivos de control. El volumen de actualización es

1 '
bajo y la recuperación es fácil.

Se incluye la actualización en línea de cuatro o más archivos de control. El volumen de actualización

2
es fácil.

3 Se incluye la actualización en línea de la mayoría de los archivos lógicos internos.

Además, la protección contra pérdida de datos es esencial que ser especialmente diseñada y
4
programada en el sistema.

Así mismo, se consideran dentro de los procesos de recuperación altamente automatizados con
5
intervención mínima def operador.

Luego de que los 14 modificadores se han sumado, deben convertirse al Multiplicador

de Complejidad (MC) utilizando la fórmula que aparece en la Ecuación 2.1.

MC = (Sum*0.01) + 0.65
Ecuación 2.1. Cálculo del Multiplicador de Complejidad.
Donde el valor 0.01 se utiliza para convertir la sumatoria a un valor decimal y 0.65 es
una constante que permite crear el multiplicador de complejidad. Esto significa que el
valor del Modificador de Complejidad tiene un rango de 0.65 a 1.35.

Una vez que se cuenta con los Puntos de Función sin ajustar y el Multiplicador de
Complejidad se aplica la fórmula de la Ecuación 2.2 para calcular los Puntos de Función
ajustados (PF) .

pf = pfa*mc
Ecuación 2.2. Cálculo de Puntos de Función.

En la Sección 2.3 se documenta un ejemplo donde se lleva a cabo la estimación del

tamaño de un proyecto real por medio de Puntos de Función.

2.2.2. Puntos de Casos de Uso

Antes de comenzar a definir esta métrica, es necesario explicar qué son los casos de
uso y dar una aproximación acerca de la forma en que se hace uso de éstos. "Un caso
de uso es, en esencia, una interacción típica entre un usuario y un sistema de
cómputo" [Fowler, M. (1999)].

Los casos de uso se componen de un actor, que es la persona o sistema que lleva a
cabo el proceso; y una generalización, que relaciona el actor con la actividad: el caso
de uso en sí. En la Figura 2.1 se puede apreciar un ejemplo de un diagrama de casos
de uso.

Figura 2.1. Gráficos de un Caso de Uso.

Puntos de Casos de Uso es un método que analiza los casos de uso, los escenarios y
varios factores técnicos y ambientales para posteriormente abstraerlos en una
ecuación. Se compone de tres variables [Clemmons, R. (2006)]:

1. Puntos de Casos de Uso sin ajustar.

5. Factor de Complejidad Técnica.

A continuación se detalla paso a paso el proceso de obtención de puntos de caso de
uso [tomado de Clemmons, R. (2006)].

2.2.2.1. Cálculo de Puntos de Casos de Uso sin ajustar

El primer paso para la estimación consiste en el cálculo de los Puntos de Casos de Uso
sin ajustar (Unadjusted Use Case Points, UUCP). Para lo cual debe determinarse el
peso de los Casos de Uso sin ajustar (Unadjusted Use Case Weight, UUCW) y el Peso
de los Actores sin Ajustar (Unadjusted Actor Weight, UAW).

Para calcular UUCW, se analizan los Casos de Uso presentes en el sistema y se separan
en tres categorías: simple, medio y complejo (Ver Tabla 2.5).

Tabla 2.5. Criterios de Complejidad de los Casos de Uso.

Tipo de Caso de Uso Descripción Peso

Simple El Caso de Uso contiene de 1 a 3 transacciones4 5

Medio El Caso de Uso contiene de 4 a 7 transacciones 10

Complejo . El Caso de Uso contiene más de 8 transacciones 15

Una vez obtenida la cantidad de casos de uso simples, medios y complejos, se procede
a aplicar la fórmula presente en la Ecuación 2.3 para obtener el Peso de los Casos de
Uso sin ajustar.

UUCW = Z Caso de Uso¡ * Peso

¡=i

Ecuación 2.3. Cálculo del Peso de los Casos de Uso sin ajustar.

Para calcular UAW, se lleva a cabo un análisis de la cantidad de Actores presentes en el

sistema y su complejidad (Ver Tabla 2.6). La complejidad de los actores se establece
considerando si se trata de una persona u otro sistema y la forma en que interactúa
con el sistema, también pueden ser simples, medios o complejos.

4 Interacciones en una estructura de datos compleja, compuestas por procesos que se aplicarán uno después
del otro. La transacción debe ser equivalente a una interacción atómica. Es decir, que se realice de una sola
vez y que la estructura a medio manipular no sea jamás alcanzable por el resto del sistema hasta que haya
finalizado todos sus procesos.
 Tipo de Factor de
Descripción
Actor Peso

Otro sistema que interactúa con el sistema a desarrollar mediante una interfaz
Simple 1
de programación (API, Application Programming Interface).

Otro sistema que interactúa con el sistema a desarrollar mediante un protocolo o

Medio 2
una interfaz basada en texto.

Complejo Una persona que interactúa con el sistema mediante una interfaz gráfica 3

Una vez que se obtienen los actores simples, medios y complejos, se procede a aplicar
la fórmula de la Ecuación 2.4, para obtener el Peso de los Actores sin ajustar.

uaw = z Actoi-j * Peso

¡=1

Ecuación 2.4. Cálculo del Peso de los Actores sin ajustar.

Una vez obtenidos ambos pesos, se suman como se indica en la Ecuación 2.5 y se
obtienen los UUCP.

uucp = uaw + uucw

Ecuación 2.5. Cálculo de Puntos de Casos de Uso sin ajustar.

2.2.2.2. Cálculo de Puntos de Casos de Uso ajustados

Para obtener los Puntos de Casos de Uso ajustados, es necesario calcular los Factores
de Complejidad Técnica (Technical Complexity Factor, TCF) y el Factor de Complejidad
del Ambiente (Environment Complexity Factor, ECF).

TCF se calcula mediante trece factores técnicos que permiten estimar el impacto en la
productividad (Ver Tabla 2.7). A cada uno de los factores se le asigna un valor en un
rango de 0 a 5, donde 0 significa un aporte irrelevante y 5 un aporte muy importante.
 Factor Descripción Peso

TI Sistema distribuido 2

T2 Rendimiento o tiempo de respuesta 1

T3 Eficiencia del usuario final 1

T4 Procesamiento interno complejo 1

T5 El código debe ser reutilizable 1

T6 Facilidad de instalación 0.5

T7 Facilidad de uso 0.5

T8 Portabilidad 2

T9 Facilidad de cambio 1

TIO Concurrencia 1

Til Objetivos especiales de seguridad 1

T12 Provee acceso directo a terceras partes 1

T13 Se requiere entrenamiento especial a usuarios 1

Luego de asignar un valor a los trece factores, se aplica la fórmula en la Ecuación 2.6
para obtener el Factor de Complejidad Técnica.

TI 3
TCF = 0.6 + (0.01 * E Valor asignado, * Peso)
i=Tl

Ecuación 2.6. Cálculo del Factor de Complejidad Técnica.

ECF se refiere a las habilidades y el entrenamiento del grupo involucrado en el

desarrollo, las cuales tienen un gran impacto en las estimaciones de tiempo ya que
equipos más experimentados tendrán un mayor impacto en el cálculo de los Puntos de
Casos de Uso. El cálculo del mismo es similar al cálculo del Factor de Complejidad
Técnica, es decir, se trata de un conjunto de factores que se cuantifican con valores
entre 0 y 5. En la Tabla 2.8, se muestra el significado y el peso de cada uno de éstos
factores.
 Factor Descripción Peso

El Familiaridad con el modelo de proyecto utilizado 1.5

E2 Experiencia en la aplicación 0.5

E3 Experiencia en el paradigma de desarrollo 1

E4 Capacidad del analista líder 0.5

E5 Motivación 1

E6 Estabilidad de los requerimientos 2

E7 Personal de medio tiempo -1

E8 Dificultad del lenguaje de programación -1

Para los factores El a E4, un valor asignado de 0 significa sin experiencia, 3

experiencia media y 5 amplia experiencia (experto). En el caso del factor E5, 0
significa sin motivación para el proyecto, 3 motivación media y 5 alta motivación. En el
factor E6, cero significa requerimientos extremadamente inestables, 3 estabilidad
media y 5 requerimientos estables sin posibilidad de cambios. Para el factor E7, 0
significa que no hay personal de medio tiempo (es decir todos son tiempo completo), 3
significa mitad y mitad, y 5 significa que todo el personal es medio tiempo. Y por
último en el factor E8, 0 significa que el lenguaje de programación es fácil de usar, 3
medio y 5 que el lenguaje es extremadamente difícil.

Una vez cuantificados los conceptos, el Factor de Complejidad del Ambiente se calcula
mediante la fórmula de la Ecuación 2.5.

es
EF = 1.4 - (0.3 * I Valor asignado¡ * Peso)
i=El

Ecuación 2.7. Calculo del Factor de Complejidad del Ambiente.

Al contar con ambos Factores, así como con los UUCP, se procede a obtener los UCP
empleando la fórmula de la Ecuación 2.8.

UCP = UUCP * TCF * EF

Ecuación 2.8. Cálculo del Ajuste de Puntos de Casos de Uso.

En la Sección 2.3 se documenta un ejemplo donde se lleva a cabo la estimación dei

tamaño de ún proyecto real por medio de Puntos de Casos de Uso.
2.2.3. COCOMO II

El Modelo Constructivo de Costos (Constructive Cost Model, COCOMO) fue desarrollado

inicialmente por Barry W. Bohem en 1978 cuya primera versión se basaba en tres
niveles (Básico, Intermedio y Detallado) que reflejaban la estimación de costos
[Boehm, B. (1981)]. Su versión más reciente, COCOMO II, que se publicó en el año
2000, cuenta con cuatro niveles a saber [Sommerville, I. (2005)]:

Nivel de construcción de prototipos. Presupone que el sistema será creado

mediante componentes reutilizables, scripts y programación en bases de datos.
Fue diseñado para hacer estimaciones de desarrollo de prototipos. Las
estimaciones de tamaño del software están basadas en puntos de aplicación y
se utiliza una fórmula simple (tamaño/productividad) para estimar el esfuerzo
requerido.

Nivel de diseño inicia!. Se utiliza en etapas tempranas del diseño del sistema,
después que los requerimientos han sido establecidos. Las estimaciones están
basadas en número de líneas de código.

Nivel de reutilización. Este nivel se utiliza para calcular el esfuerzo requerido

para integrar componentes reutilizables o código que es automáticamente
generado por herramientas de diseño o programas de traducción. Normalmente
es utilizado con el diseño de postarquitectura.

Nivel de Postarquitectura. Una vez diseñado el sistema, se puede hacer una

estimación más precisa del tamaño del software. Incluye un conjunto de
diecisiete multiplicadores que reflejan habilidades del personal y las
características del producto y del proyecto.

El nivel inicial, el Nivel de construcción de prototipos, se estudiará más a fondo ya que

su intención es dar soporte a la estimación del esfuerzo en una fase temprana del
desarrollo de aplicaciones [tomado de Sommerville, I. (2005)].

2.2.3.1. Nivel de construcción de prototipos

Se basa en una estimación de puntos de aplicación con pesos o puntos objeto, la cual
se divide entre una cifra estándar de la productividad estimada (Ver Tabla 2.9) que
luego se ajusta de acuerdo con la dificultad de desarrollo de cada punto objeto. La
productividad del programador depende de la experiencia y de la capacidad del
desarrollador y de las características de las herramientas utilizadas.

Tabla 2.9. Productividad medida en Puntos de Objeto.

Experiencia y capacidad de los desarrolladores Muy baja Baja Media Alta Muy Alta

Madurez y capacidad de las herramientas Muy baja Baja Medía Alta Muy Alta

PROD (NOP/mes5) 4 7 13 25 50

Puede existir la reutilización de componentes y con ésto, algunos puntos de aplicación

se pueden implementar reutilizando componentes. En consecuencia, se deberá ajustar
la estimación obtenida mediante el total de puntos de aplicación, análogos a los Puntos
de Función, teniendo en cuenta el porcentaje de reutilización esperado. Con estos
datos se calcula el esfuerzo por medio de la fórmula que aparece en la Ecuación 2.9.

PM = (NAP * (1 - %reutiüzación/100) / PROD

Ecuación 2.9. Cálculo del Esfuerzo Nivel de Prototipos COCOMO II.

PM es el esfuerzo estimado en personas/mes, un mes de trabajo implica 152 horas

[Kemerer, C. F. (1987)], NAP es el total de puntos de aplicación en el sistema a
desarrollar (el cual es análogo a los Puntos de Función sin ajustar), °/oreutilización es
una estimación de la cantidad de código reutilizado en el desarrollo y PROD es la
productividad medida en puntos objeto.

En la Sección 2.4 se documenta un ejemplo donde se lleva a cabo la estimación del

esfuerzo de un proyecto real por medio del Nivel de Prototipos de COCOMO II.

2.3. Ejemplos de aplicación de Métricas

Una vez revisados los fundamentos teóricos de las métricas Puntos de Función y
Puntos de Casos de Uso, se presenta su aplicación, con la finalidad de ejemplificar la
aplicación de las métricas, en un proyecto real elaborado en la materia Taller de
Desarrollo II en el 2o Semestre de la Maestría en Ingeniería de Software, fue
desarrollado en conjunción con el L. I. Ulises Marinero Aguilar , el I. S. C. Fernando
Rivera Pelayo, la L. S. C. A. Liliana Velázquez Bello y la que escribe. En el proyecto se

5 Número de Puntos Objeto por mes

utilizó la metodología Áncora para la Especificación y Análisis de Requerimientos de
Software y Proceso Unificado de Desarrollo de Software para los Casos de Uso,

2.3.1. Caso de Estudio

La empresa ALRO se dedica a la importación de juguetes al territorio nacional a través

de la aduana de la ciudad de Veracruz. Dicha empresa actualmente no cuenta con
ningún sistema de información que apoye el proceso de recepción de mercancía (Ver
Apéndice A para conocer el proceso completo actual de registro de mercancías así
y

como la propuesta computacional y diagramas).

Todo el proceso del llenado de la ficha e impresión de los informes, es mantenido en

una hoja de cálculo en Microsoft Office Excel ®. Este proceso posibilita cometer una
gran cantidad de errores, además de ser laborioso, tardado y repetitivo.

2.3.2. Medición de tamaño por medio de Puntos de Función

Con la documentación detallada en el Apéndice A, se obtuvieron los tipos de funciones

y sus pesos. En la Tabla 2.10 (a) y (b), se enumeran los tipos de archivos y la
asignación de complejidad.

Tabla 2.10. (a) Archivos lógicos internos y de interfaz externa.

Archivos lógicos Internos
TRE TDE Complejidad
Producto 1 21 Medio
Mecanismos 1 3 Bajo
Material 1 2 Bajo
Presentación 1 ■ 3 Bajo
Pilas 1 4 Bajo
Comercialización 1 2 Bajo
Fracción Arancelaria 1 5 Bajo
Aviso Sanitario 1 5 Bajo
Proveedor 1 4 Bajo
Cliente 1 4 Bajo
Ficha Corta 1 24 Medio
Ficha Larga 1 24 Medio

Archivos de Interfaz Externa

RA TDE Complejidad
Usuarios 1 2 Bajo
 Entradas Externas
RA TDE Complejidad
Código de Barras 2 2 Bajo •
Número de Cajas 2 2 Bajo
Número de Productos 2 2 Bajo

Salidas Externas
RA TDE Complejidad
Ficha Corta 3 15 . Medio
Anexo XVIII 1 1 Bajo
Etiquetado 1 14 Bajo
Factura 6 25 Alto

Consultas Externas
RA TDE Complejidad
Catálogos 11 53 Alto
Una vez que se cuenta con las funciones y su complejidad se procede a calcular los
PFA (Ver Tabla 2.11).

Tabla 2.11. Cálculo de Puntos de Función sin ajustar.

Identificador Bajo Medio Alto Suma
Archivos Lógicos Internos 63 30 93
Archivos de Interfaz Externa 5 5
Entradas Externas 9 9
Salidas Externas 8 5 7 . 20
Consultas Externas 6 6
PFA = 133
Puede apreciarse que el resultado es 133 PFA de tamaño del proyecto. Para obtener el
MC y así poder ajustar los PF, se revisaron los modificadores y su grado de influencia
en la aplicación (Ver Tabla 2.12).
 Modificador Grado de influencia
1. Comunicación de datos 1
2. Procesamiento distribuido de datos 2
3. Rendimiento 1
4. Configuración altamente usada 2
5. Promedio de transacciones 4
6. Entrada de datos en línea 3
7. Eficiencia para el usuario final 5
8. Actualización en línea 1
9. Procesamiento complejo 3
10. Reusabilidad 3
11. Facilidad de instalación 3
12. Facilidad de operación 2
13. Varios sitios 0
14. Facilidad de cambios 4
| Sum = 34

Una vez que se cuenta con la suma del grado de influencia de los modificadores se
calcula MC utilizando la Ecuación 2.1, como se ilustra en la Ecuación 2.10 ya con el
total de la suma.

MC = (34*0.01) + 0.65

MC = 0.99
Ecuación 2.10. Obtención del Multiplicador de Complejidad.

Finalmente, se aplica la Ecuación 2.2 y se obtienen el ajuste de los PF como aparece

en la Ecuación 2.11.

PF = 133 * 0.99
PF = 131.67
Ecuación 2.11. Cálculo de Puntos de Función.

2.3.3. Medición de tamaño por medio de Puntos de Casos de Uso

La obtención de Puntos de Casos de Uso sin ajustar, se realiza con. base en los
Diagramas de Casos de Uso del proyecto (Ver Apéndice A), de dichos diagramas se
identifican los Casos de Uso y su complejidad (Ver Tabla 2.13).
 Caso de Uso Complejidad
Acceso al sistema Simple
Creación de Ficha Complejo
Generación de etiquetas Medio
Generación de Ficha Corta Complejo
Generación de Anexo XVIII Medio
Facturación Medio
Actualización de Catálogos Complejo
Sincronizar información Medio
Registrar Datos Simple
Posteriormente, con base en la Tabla 2.14, se procede a calcular el Peso de los Casos
de Uso sin ajustar (Ver Tabla 2.14).

Tabla 2.14. Peso los Casos de Uso sin ajustar.

Complejidad de! Caso de Uso Cantidad Peso Peso Tota i
Simple 2 5 10
Medio 4 10 40
Complejo ¡ 3 15 45
UUCW = 95
Luego de obtener el Peso de los Casos de Uso sin ajustar, se procede a identificar y
asignar nivel de complejidad a los actores (Ver Tabla 2.15).

Tabla 2.15. Complejidad de los Actores.

Actor Complejidad
Usuario Complejo
Administrador Complejo
ALRO Simple
Ya identificados los actores y su grado de complejidad, se obtiene el Peso de los
actores (Ver Tabla 2.16).

Tabla 2.16. Peso de los Actores sin ajustar.

Complejidad de! Actor Cantidad Peso Peso Tota!
Simple 1 1 x 1,
Medio 2 0
Complejo 2 3 6
UAW = 7
Ya que se cuenta con el peso tanto de los casos de uso como de los actores, se aplica
la Ecuación 2.5, y se obtienen los Puntos de Casos de Uso sin ajustar (Ver Ecuación 2.
12).

UUCP = 95 + 7

UUCP = 102
Ecuación 2.12. Cálculo de Puntos de Casos de Uso sin ajustar.

Luego de tener los Puntos de Casos de Uso sin ajustar, se lleva a cabo la
determinación del peso de los Factores de Complejidad Técnica (Ver Tabla 2.17) con el
fin de ajustar posteriormente los Puntos de casos de uso.

Tabla 2.17. Influencia y Peso de los Factores de Complejidad Técnica.

Factor Influencia Peso Valor
Sistema distribuido 2 2 4
Rendimiento o tiempo de respuesta 3 1 3
Eficiencia del usuario final 3 1 3
Procesamiento interno complejo 3 1 3
El código debe ser reutilizable 2 1 2
Facilidad de instalación 4 0.5 2
Facilidad de uso 5 0.5 2.5
Portabilidad 4 2 8
Facilidad de cambio 3 1 3
Concurrencia 4 1 4
Objetivos especiales de seguridad 1 ' 1 1
Provee acceso directo a terceras partes 4 . 1 4
Entrenamiento especial a usuarios 2 1 2
Suma Total - 41.5
Con el total de pesos de los factores y aplicando la Ecuación 2.6, se obtiene el Factor
de Complejidad técnica (Ver Ecuación 2.13).

TCF = 0.6 + (0.01 * 41.5)

TCF = 1.015
Ecuación 2.13. Cálculo del Factor de Complejidad Técnica.

Posterior ai cálculo del Factor de Complejidad Técnica, se procede a identificar el grado

de influencia y el peso de los Factores del Ambiente (Ver Tabla 2.18).
 Factor Influencia Peso Valor
Familiaridad con el modelo de proyecto 4 1.5 6
Experiencia en la aplicación 3 0.5 1.5
Experiencia en el paradigma de desarrollo 3 1 3
Capacidad del analista líder 4 0.5 2
Motivación 5 1 5
Estabilidad de los requerimientos 5 2 10
Personal de medio tiempo 5 -1 -5
Dificultad del lenguaje de programación 3 -1 -3
Suma Total = 19.5
Ya contando con el total de pesos de los Factores del Ambiente, se utiliza esta
sumatoria en la Ecuación 2.7 para obtener el Factor de Complejidad del Ambiente (Ver
Ecuación 2.14).

ECF = 1.4 - (0.3 * 19.5)

ECF = 0.815
Ecuación 2.14. Cálculo del Factor de Complejidad del Ambiente.

Con todos los valores obtenidos, Puntos de Casos de Uso sin ajustar, Factores de
Complejidad Técnica y del Ambiente, se aplica la Ecuación 2.8 y se obtiene el valor de
los Puntos de Casos de Uso ajustados (Ver Ecuación 2.15).

UCP = 102 * 1.015 * 0.815

UCP = 84.38
Ecuación 2.15. Cálculo de Puntos de Casos de Uso.

2.4. Estimación del esfuerzo

Estimar quiere decir predecir el futuro, lo cual es una espada de dos filos, en la
antigüedad, los oráculos y adivinos eran ampliamente recompensados o sentenciados a
muerte si se equivocaban [Armour, P. (2002)]. Actualmente, aunque no se condena a
muerte por una mala estimación, si puede representar pérdidas para empresa. Lo que
se espera al estimar las características de un sistema de software, como por ejemplo el
tamaño del mismo, es un aproximado, con base en la información con la que se cuenta
en ese momento, según Humprey, un buen método de estimación debe [Humphrey,
W. S (2003)]:

Utilizar métodos estructurados, que faciliten el entrenamiento del personal, que

permitan la mejora de procesos y del método en sí.
 Poder utilizarse durante todas las fases de desarrollo y mantenimiento, con la
finalidad de elaborar planes y compromisos o ajustes en fases posteriores.

Poder utilizarse en cualquier elemento del sistema de softwaré: código,

archivos, reportes, pantallas y documentación.

Ser adecuado para un análisis estadístico.

Ser adaptable con el trabajo a futuro que se elaborará, con la finalidad de

construir un histórico de datos.

Proveer los medios para juzgar la exactitud de un estimado.

En la opinión de Philip Armour [Armour, P. (2002)], una estimación no debe ser

exacta, sino suficientemente acertada y brindar información de calidad que permita a
la empresa asignar un presupuesto, hacer compromisos en los proyectos y tomar una
mejor decisión.

El esfuerzo y la programación de un proyecto tienen tres niveles de conocimiento: lo

que sabemos (orden 0), lo que sabemos que necesitamos (orden 1) y lo que no
sabemos que necesitamos (orden 2), éste último es el factor más importante, ya que
es aquel que no podemos estimar [Armour, P. (2004)]. Debido a esto, podemos decir
que la estimación de software es un proceso de aprendizaje, que se apoya en lo que
sabemos y necesitamos, para poder deducir aquello que no sabemos que requerimos.

Una métrica que se encuentra bastante documentada en su transformación a esfuerzo

son los Puntos de Función, debido a que se han realizado extensos estudios sobre ésta.
Los Puntos de Casos de Uso por su parte, también cuentan con estudios acerca de su
transformación a esfuerzo, ambos en Horas/Persona por punto. En las siguientes
secciones, se detalla la estimación del esfuerzo por medio de Puntos de Función y
Puntos de Casos de Uso.

2.4.1. Estimación del esfuerzo por medio de Puntos de Función

Para conocer el esfuerzo necesario para realizar una aplicación una vez que se tiene el
tamaño de un proyecto por puntos de función, es necesario contar con una medida de
referencia. Lamentablemente no es posible establecer una sola medida ya que la
relación que existe entre tamaño y esfuerzo no se da de manera lineal, "... mientras
que ei tamaño de desarrollo de un proyecto se incrementa, el costo por punto de
función también aumenta" [Longstreet, D. (2008)]. En la Figura 2.9, se puede
.observar la curva de crecimiento, posteriormente se explica cómo se llegó a ésta y se
detalla mejor en la Tabla 2.19 [Tomado de Longstreet, D. (2008)].

c
o
o.
c.
o
O
c
□
U-
<D
0-
Ibv
3
O

Size in Function Points

Figura 2.2. Incremento del costo por Punto de Función.

Esta curva se obtuvo, luego de un estudio de siete años aplicado a más de 100
compañías distintas y cerca de 1,000 proyectos diferentes. En la Tabla 2.19, se puede
apreciar mejor el incremento. Vale la pena aclarar que en el estudio también se
manifestó que cerca del 75% de los proyeétos superiores a 8,000 Puntos de Función,
fallan o son cancelados, por lo que solo se incluyeron los datos hasta esta cantidad
límite.
 Tabla 2.19. Incremento del costo por Punto de Fundón.

Tamaño Horas/PF

50 1.3

100 1.4

500 1.6

1,000 2.0

2,000 2.7

3,000 3.6

4,000 4.9

5,000 6.6

6,000 9.0

7,000 12.1

8,000 16.3

Esta tabla puede servir como una referencia inicial para estimar el esfuerzo requerido
para un proyecto medido en Puntos de Función. En el cuarto capítulo se presenta un
ejemplo haciendo uso de la Tabla 2.19 para la estimación del esfuerzo en
Horas/Persona.

2.4.2. Estimación del esfuerzo por medio de puntos de Casos de Uso

Para determinar el total estimado de horas por proyecto utilizando Puntos de Casos de
Uso (UCP), se obtiene multiplicando éstos por un Factor de Productividad (Productivity
Factor, PF). PF es el rango Horas/Persona de desarrollo necesarias por UCP y se puede
establecer por medio de datos históricos [Clemmons, R. (2006)]. Para obtener la
estimación del esfuerzo, se emplea la Ecuación 2.16.

Total Estimado = UCP x CF

Ecuación 2.16. Fórmula para el cálculo del esfuerzo.

Si no se cuenta con datos históricos, puede elaborarse una línea base utilizando los
datos de proyectos reales de otras empresas. También se, puede llevar a cabo la
estimación del esfuerzo evaluando la influencia de los Factores de Complejidad del
Ambiente (Ver Tabla 2.8) en el proyecto [Ribu, K. (2001)].
1. Se contabilizan cuántos factores de los que afectan al Factor de Complejidad
del Ambiente están por debajo del valor medio (3), para los factores El a E6.

2. Se contabilizan cuántos factores de los que afectan al Factor de Complejidad

del Ambiente están por encima del valor medio (3), para los factores E7 y E8.

Luego de sumar estos datos se considera el total para convertir los Puntos de Función
en esfuerzo

Si el total es 2 ó menos, se utiliza el factor de conversión 20 Horas -

Persona/Punto de Casos de Uso, es decir, un Punto de Caso de Uso toma 20
Horas/Persona.

Si el total es 3 ó 4, se utiliza el factor de conversión 28 Horas - Persona /Punto

de Casos de Uso, es decir, un Punto de Caso de Uso toma 28 Horas/Persona.

Si el total es mayor o igual que 5, se recomienda efectuar cambios en el

proyecto, como mejorar las habilidades del equipo de desarrollo, ya que se
considera que el riesgo de fracaso del mismo es demasiado alto.

2.4.3. Ejemplo de estimación del esfuerzo por COCOMO II

Cabe destacar que el modelo COCOMO II hace uso de puntos de objeto para llevar a
cabo la medición de tamaño similar a Puntos de Función y Puntos de Casos de Uso, y
con base en esto lleva a cabo una estimación del esfuerzo. Con base en el proyecto
descrito en el Apéndice A, se realizó la estimación del esfuerzo por medio del Nivel de
Construcción de Prototipos (Ver Apéndice A).

Inicialmente se determinan los puntos objetos y el peso de éstos, lo cual puede

llevarse a cabo revisando la Tabla 2.12 de la sección 2.3.2. Posteriormente, con la
Tabla 2.9, se obtiene la productividad estimada, la cual es de nivel medio. El proyecto
realizado es relativamente nuevo por lo cual el porcentaje de reutilización fue solo del
10%. Con los datos obtenidos se resuelve la Ecuación 2.9 y se obtiene el esfuerzo en
Personas/Mes (Ver Ecuación 2.17).

PM = {128 *[1 - (10/100)]} /13

PM = 9.84
Ecuación 2.17. Esfuerzo en Personas/Mes obtenido por COCOMO II, Construcción de Prototipos.

Aproximando el resultado teórico, nos lleva a que el proyecto se puede realizar con
diez personas durante un mes.
2.5. Contabilidad de Costos

Un aspecto que las empresas desarrolladoras de Software, por muy pequeñas que
sean, deben tener en cuenta es: la contabilidad de costos.

La contabilidad de costos tiene como objetivo construir una base de datos de

información económica interna a la empresa, a la que todo responsable de la empresa
puede acceder para obtener la información necesaria con el fin de establecer una
adecuada toma de decisiones.

Con el fin de complementar el costo del desarrollo de un producto de software, es

recomendable considerar el gasto que éste representa para la empresa.

El costo es el sacrificio o esfuerzo económico que se debe realizar para lograr un

objetivo y se traduce en el valor monetario de los recursos empleados en la
producción, distribución o consumo de un bien o servicio.

2.5.1. Tipos de costos

Dependiendo de sus características, los costos empresariales se tipifican según su:

función, grado de variabilidad, asignación y comportamiento. Dichas categorías deben
considerarse con el fin de contabilizar el costo de un producto de software. A
continuación se explica cada tipo de costo [Tomado de García Pérez de Lema, D.
(2006)].

2.5.1.1. Según su función

Los costos según su función se dividen en costos de: producción, comercialización,

administración y financiación.

Costos de producción. Se refiere a aquellos que permiten obtener bienes a

partir de otros mediante el empleo de un proceso de transformación. Es decir,
todo aquello que la empresa debe invertir para llevar a cabo el producto o
servicio al que se dedica.

Costos de comercialización. Son los que permiten la venta de bienes o servicios

al cliente. Refiriéndose ésto a toda aquella acción que se realice para promover
el producto que la empresa desarrolla principalmente.
 Costos de administración. Son aquellos costos necesarios para la gestión del
negocio. A diferencia de los costos anteriores, en las PyMES, algunas veces los
costos administrativos son subestimados e incluso ignorados, debido a la
mínima cantidad de personal e incluso a la falta de una ubicación física de la
empresa. Sin embargo, esto no significa que no existan éstos costos.

Costos de financiación. Corresponden a la obtención de fondos aplicados al

negocio. Es decir, impuestos, hipotecas, intereses, entre otros.

2.5.1.2. Según su grado de variabilidad

El grado de variabilidad en un costo, quiere decir la constancia con que permanece el

importe en efectivo. Se dividen en: fijos y variables.

Costos fijos. En los costos fijos el importe permanece constante. Algunos

ejemplos son: alquileres, seguros, impuestos y servicios públicos. En pocas
palabras, costos de administración y financiamiento.

Costos variables. Son aquellos que se modifican de acuerdo con las actividades
de la empresa. Algunos ejemplos son: sueldos, materias primas y comisiones
sobre ventas. Los costos de producción y de comercialización, son costos
variables, debido a que su importe dependerá de la cantidad de productos que
desarrolle.

2.5.1.3. Según su asignación

Al hablar de costos por asignación, se refiere a la relación que el costo tiene con
respecto al producto. Se dividen en: costos directos e indirectos.

Costos directos. Son aquellos que se asignan directamente a una unidad de

producción. Por lo general se asimilan a los costos variables. Ejemplo de costos
directos en la elaboración de un proyecto de Software son: el costo por horario
del equipo de cómputo y el costo por hora por desarrollador.

Costos indirectos. Son aquellos que no se pueden asignar directamente a un

producto o servicio, sino que se distribuyen entre las diversas unidades
productivas mediante algún criterio de reparto. En la mayoría de los casos los
costos indirectos son costos fijos. Los costos indirectos representan todo el
soporte para producción, algunos ejemplos son: costo por asesorías,
capacitaciones y outsourcing.
Representan una parte importante del costo final de una aplicación de software ya que
si se comete un error en los costos indirectos del análisis de costos, su valor afecta a
todos los renglones del presupuesto [Salas Rico, R. (1981)].

El análisis de los costos tiene por objeto evaluar todos los elementos que intervienen
en la realización de los trabajos: personal, equipo y materiales utilizados. Para ello se
hace uso de los costos directos e indirectos. Con ello es posible comparar los
resultados obtenidos y decidir, entre otras cosas un presupuesto adecuado al
desarrollo del proyecto [Salas Rico, R. (1981)]. En el Capítulo 4 se abordan los costos
directos e indirectos más importantes en el desarrollo de un proyecto de software.
Capítulo 3. Estudio de Campo sobre el uso de métricas
y estimaciones

Ahora que ya se conocen algunas métricas de Software, es necesario relacionar éstas

con estimaciones de esfuerzo, tiempo y costo. Con este fin, se realizará un estudio de
campo que dé una visión del uso de métricas en las empresas para el cálculo de sus
estimaciones. Sobre esta base empírica que apoyará el método de estimación de
costos para las PYMES.

3.1. Planteamiento del estudio de campo

Para validar cualquier propuesta de modelo de estimación debe contrastarse con datos
reales de empresas con características similares a aquellas a las que va dirigida. En el
caso correspondiente a este trabajo, debe validarse con empresas de la región centro
dé Veracruz y que correspondan a tamaño pequeño, para esto se tomó una aleatoria
homogénea. Las características del estudio se describen en esta sección.

3.1.1. Objetivo del estudio

La finalidad de llevar a cabo el presente estudio es: obtener una fuente de información
del mundo real, confiable, con base en la cual elaborar un modelo de apoyo, para que
las PYMES desarrolladoras de Software puedan llevar a cabo la estimación de costos de
sus proyectos.

Los datos obtenidos en el estudio permitirán decidir cuáles son las métricas que más
se adaptan a las necesidades de las pequeñas y medianas empresas. Con base en el
resultado que brinde, se podrá obtener una estimación de costos más acertada,
confiable y fácil de emplear.

3.1.2. Proceso a seguir

En esta sección, se describe cómo se llevará a cabo de cada una de las etapas del
estudio (Ver Figura 3.1).
 Figura 3.1. Diagrama de actividades del estudio de campo
El estudio de campo se dividió en tres etapas:

1. Entrevista a empresas con algún tipo de certificación.

2. Cuestionario general a PYMES desarrolladoras de software.

3. Entrevista a PYMES desarrolladoras de software.

Con base en la bibliografía recopilada en el Capítulo 2, se elaboró, para la primera

etapa, una entrevista, que fue enviada a empresas desarrolladoras de software que
tienen certificación CMMI al menos de nivel tres o con certificación de MoProSoft. La
intención es conocer cómo una empresa establecida, lleva a cabo la medición y
estimación de costo de los proyectos que desarrolla, y usarlo como base para la
siguiente etapa.

Ya que se cuente con un panorama acerca de la forma de medir y de estimar de

empresas certificadas, se procederá a elaborar un cuestionario, para empresas sin las
certificaciones previamente mencionadas o que entren en el rango de las PYMES. La
finalidad de esta segunda etapa es saber si estas empresas cuentan con algún proceso
de medición y la forma en que la aplican, además de la manera en que estiman el
costo final de sus productos.

Con la información obtenida en las etapas previas, se procederá a elaborar una nueva
entrevista, encaminada a conocer la postura de las PYMES ante los datos obtenidos en
las etapas anteriores y con ello poder sustentar la metodología.

Al inicio y final de cada etapa, se llevará a cabo un análisis, con la finalidad de:
elaborar las preguntas correspondientes para el cuestionario y la entrevista a PYMES, y
sustentar el modelo propuesto.

3.2. Etapa 1: Empresas certificadas

La primera etapa del estudio, se enfoca en identificar la manera en que las Empresas
Desarrolladoras de Software (EDSW) en México, llevan a cabo la transformación de
una métrica en una estimación.

Lo interesante de esta entrevista es que, al contar con procesos definidos, las EDSW
cuentan también con datos históricos de proyectos que ya han terminado, siendo éstos
la base para el cálculo de proyectos nuevos. Con base en ésto, se espera que sus
estimaciones puedan ser más precisas.

3.2.1. Planteamiento de la entrevista

Para saber de qué forma las empresas certificadas llevan a cabo la estimación de
costos de software, se elaboró una entrevista, que se aplicó a algunas de ellas
mediante correo electrónico, por teléfono o personalmente. La entrevista permitió
conocer los siguientes puntos:

Procesos de desarrollo utilizados.

Metodologías de desarrollo aplicadas.

Herramientas de apoyo en el desarrollo empleadas.

Métricas recolectadas y su utilización.

Estrategia utilizada para estimar costo a partir de las métricas.

Siendo estos conceptos de importancia para comprender aquellos aspectos de

Ingeniería de Software que se usan en la práctica profesional.
3.2.2. Resultados Etapa 1. Entrevista a Empresas Certificadas

Una vez aplicada la entrevista a las empresas se pudo observar que una característica
muy utilizada, es la medición del esfuerzo de desarrollo de software y el
mantenimiento del mismo. Destacan como herramientas para la estimación, los casos
de uso, el análisis de riesgo y los requisitos técnicos de un sistema. Con la finalidad de
estimar utilizan la obtención del tamaño por medio de puntos de casos de uso, de
puntos de función, y para el tiempo, historiales. También realizan una comparación del
software con proyectos previos.

En las Tablas 3.1. (a) a 3.1 (i), se muestran los resultados completos obtenidos de las
entrevistas enviadas a veinte empresas certificadas, de las cuales sólo se obtuvo
respuesta de cuatro. Cabe aclarar que por cada pregunta hubo respuestas múltiples,
es por ello que el total de respuestas supera el 100%. El formato de la entrevista se
incluye en el Apéndice E.

Tabla 3.1. (a) Modelo de desarrollo de Software.

Pregunta Respuestas Porcentaje

1. Select Perspective 25%

¿Qué modelo o 2. Serum 25%

ciclo de desarrollo
de Software 3. Iterativo 50%
utiliza su
empresa? 4. Cascada 25%

5. No contestaron o no correspondía 25%

Se puede apreciar que la mayoría la mitad de las empresas utilizan un modelo de

desarrollo iterativo, también cabe destacar que algunas empresas llevan a cabo dos o
más modelos de desarrollo en los distintos proyectos que elaboran.
 Tabla 3.1. (b) Herramientas a utilizar para el desarrollo.

Pregunta Respuestas Porcentaje

1. Select Software Tools 25%

2. Project Server 25%

¿Cuáles son las 3. Visual Studio 25%

herramientas que
su empresa utiliza
4. Developer suite 25%
para desarrollar
programas de
cómputo? 5. Websphere Studio 25%

6. Concurrent Versions System 25%

7. JDK 25%

El uso de herramientas de desarrollo es muy variado entre las empresas, aunque es

importante mencionar que así como en la pregunta anterior, la mayoría de las
empresas hacen uso de dos o más herramientas.

Tabla 3.1. (c) Características utilizadas para medición del Software.

Pregunta Respuestas Porcentaje

1. Casos de uso 25%

2. Valor ganado 25%

3. Rendimiento 25%

¿Qué características, 4. Reuso 25%

del Software que
desarrolla, utiliza 5. Mantenimiento 50%
para realizar la
medición del mismo? 6. Funcionalidad 25%

7. Fiabilidad 25%

8. Usabilidad 25%

9. Movilidad 25%

Al igual que las herramientas, las características de las que hacen uso las empresas
para medir el tamaño son variadas, destaca el mantenimiento. También en este caso
se emplea más de una.
 Tabla 3.1. (d) Métricas de estimación de características del Software.

Pregunta Respuestas Porcentaje

1. Tamaño de los casos de uso 50%

2. Calidad del caso de uso 50%

¿Qué métricas utiliza
su empresa para 50%
3. Esfuerzo por la elaboración de casos de uso
estimar los diversos
aspectos del
Software que 4. Requisitos técnicos del proyecto 50%
elabora?
5. Cronogramas del proyecto 50%

6. Análisis de riesgo 50%

En esta pregunta, destacan los casos de uso, como una métrica utilizada para estimar
aspectos del software, aunque las empresas también afirmaron que los otros
conceptos también eran de mucha importancia.

Tabla 3.1. (e) Razones para utilizar las métricas especificadas.

Pregunta Respuestas Porcentaje

1. La metodología utilizada se dirige a casos de

50%
uso

¿Por qué utilizan

2. Ofrecen valores de rendimiento en los
estas métricas? 25%
proyectos

3. Tiempos críticos de entrega 25%

Destaca en las respuestas, que la metodología que utilizan es la que determina la

razón de utilizar la métrica.

Tabla 3.1. (f) Descripción de cálculo de métricas.

Pregunta Respuestas Porcentaje

1. Complejidad del proyecto 25%

Describa brevemente, 2. Calculo automático de los datos 25%

¿cómo calcula dichas
métricas? 3. Experiencia previa 25%

4. Cálculo de productividad 25%

El cálculo de las métricas varía dependiendo de la métrica que utilizan, aunque es

importante analizar los conceptos en sí. Siendo empresas grandes, siguen confiando en
experiencias de desarrollo previas, además de evaluar la complejidad y la
productividad.
Pregunta Respuestas Porcentaje

¿Cómo estima el tiempo, 1. Con base en casos de uso 50%

costo y esfuerzo de
desarrollo de los 2. Puntos de función 25%
proyectos que lleva a
cabo? 3. Historial 25%

Al igual que para las métricas, los casos de uso destacan como un concepto más
utilizado para realizar estimaciones, se observan también Puntos de Función e
Historiales.

Tabla 3.1. (h) Relación entre métricas y estimaciones.

Pregunta Respuestas Porcentaje

¿Cómo relaciona las

1. Comparación con proyectos previos 50%
métricas que aplica en
los sistemas que
desarrolla con la
estimación mencionada 2. No contestaron o no correspondía 50%
previamente?

Al igual que como se vislumbraba en las métricas, la experiencia en proyectos previos

es un factor importante en la elaboración de estimaciones.

Tabla 3.1. (i) Otros conceptos para realizar estimaciones.

Pregunta Respuestas Porcentaje

1. Productividad de la empresa 25%

¿Qué otro concepto 2. Experiencia de expertos en temas técnicos y

25%
toma en cuenta al funcionales
momento de estimar
las características de 3. Tiempo de desarrollo del proyecto 25%
sus proyectos de
Software? 4. Recursos asignados al proyecto 25%

5. Actividades asignadas a desarrolladores 25%

Los conceptos adicionales considerados en las estimaciones son variados, cabe

destacar que varias empresas consideraban más de un elemento.

3.2.3. Conclusiones de la Etapa 1

Los conceptos que destacan más en las respuestas de las empresas certificadas son:
como modelo del ciclo de desarrollo de software, se utiliza un modelo iterativo. Para
estimar el tiempo, costo y esfuerzo, se utilizan casos de uso, puntos de función e
■historiales. Para establecer una relación entre las métricas aplicadas y un esfuerzo
estimado, se compara lo obtenido con los proyectos previamente elaborados. Destaca
sobre todo la importancia de la relación que consideran las empresas entre los
sistemas que llevarán a cabo y los que ya elaboraron, tomando para medir éstos los
casos de uso y los puntos de función.

3.3. Etapa 2: PYMES

En la segunda etapa, se elaboró un cuestionario basado en la recopilación bibliográfica

y en las respuestas recibidas de la primera etapa. Éste se aplicó a PYMES
desarrolladoras de software. Con este cuestionario se buscaba conocer la manera en
que estas empresas estiman el costo de un proyecto y los elementos que influyen al
momento de realizar dicha estimación.

3.3.1. Planteamiento del cuestionario

El cuestionario inicia con una pregunta que solicita al encuestado mencionar la manera
en que su empresa lleva a cabo la estimación del esfuerzo de un proyecto, las
respuestas de ésta se basan en la información obtenida en la primera etapa, luego de
llevar a cabo un análisis de los resultados. Con base en esto, se consideraron los
temas más importantes para incluir en el estudio, que son:

Uso de métricas de software.

Consejo de expertos.

Comparación con proyectos realizados previamente.

Estimación de costos de proyecto.

Opinión con respecto al método de estimación.

Lo anterior proporcionará una imagen de los conceptos de Ingeniería de Software que

consideran de mayor importancia que pueden emplearse en la propuesta del método.

3.3.2. Resultados Etapa 2. Cuestionario a PYMES

Se envió cuestionario a veintidós empresas de la región Centro y Sur del país, de las
cuales contestaron todas. El formato del cuestionario se incluye en el Apéndice E. Los
resultados obtenidos se despliegan en la Tabla 3.2 (a) a (i), Posteriormente los más
importantes se detallan y grafican en la sección 3.3.2.1.
 Tabla 3.2. (a) Datos Generales del Entrevistado.
Grado académico relacionado a la computación o informática:
a) Carrera técnica 0
b) Licenciatura 16
c) Especialización 0
d) Maestría 7
e) Doctorado 0
Lugar donde labora actualmente:
a) Empresa especializada en desarrollo de software 3
b) Empresa de otro giro en el departamento de desarrollo de sistemas 8

c) Institución educativa con proyectos de desarrollo de software 8

d) Consultor independiente en desarrollo de software 2
Años de experiencia en desarrollo de software:
a) Menos de 1 año 2
b) De 1 a 3 años 8
c) De 3 a 5 años 4
d) De 5 a 10 años 3
e) Más de 10 años 5

Tabla 3.2. (b) Estimación del esfuerzo en general.

Para estimar el esfuerzo requerido para un proyecto, su empresa utiliza principalmente:

a) Métricas de Software 10
b) Consejo de un experto 3
c) Comparación con proyecto realizados previamente 10
d) Otro 3
e) CMMI 1
f) Decisión de los desarrolladores 1
g) No se estima el esfuerzo requerido 1

Tabla 3.2. (c) Información sobre Métricas de Software.

Indique cuál o cuales métricas utiliza su empresa.
a) Puntos de Función 3
b) Puntos de Casos de Uso 9
c) COCOMO 2
d) Bang 0
e) Otro 2
f) Tamaño 1
g) Tiempo/Esfuerzo 1
¿Por cuánto tiempo han empleado esa métrica?
a) 1 a 6 meses 2
b) 6 meses a 1 año 2
c) 1 año a 3 anos 5
d) 3 a 5 años 3
e) Más de 5 años 2
¿Cuánto tiempo le toma llevar a cabo el proceso de medición de un proyecto?
a) Menos de 4 horas 2
b) 4 a 8 horas 1
c) 8 a 24 horas 5
d) 24 a 40 horas 5
e) Más de 40 horas 1
¿Lleva registro de las estimaciones de proyectos anteriores?
a) Sí 4
b) No 4
c) No en todos 7
d) No sé 0
¿Lleva un registro del esfuerzo real de proyectos terminados?
a) Sí 4
b) No 6
c) No en todos 5
d) No sé 0

Tabla 3.2. (e) Información sobre consejos de expertos.

Si hace uso de la experiencia previa en su estimación, ¿cuántas.personas intervienen?

a) Un solo experto 3
b) Dos o tres expertos 7
c) Más de tres expertos 1
¿Qué aspectos toman en cuenta?
a) Tipo de proyecto 5
b) Funcionalidad solicitada 6
c) Rendimiento esperado 2
d) Valor agregado a la empresa cliente 2
e) Urgencia para terminarlo 3
f) Otros 0

Tabla 3.2. (f) Información sobre comparaciones con proyectos previos.

Si utiliza comparación en sus estimaciones, ¿qué aspectos son los principales?
a) Tamaño del proyecto 8
b) Tipo del proyecto 7
c) Funcionalidad 9
d) Tipo de cliente 2
e) Otro 0
¿Qué factores considera más importantes para determinar el costo del proyecto?
a) Estimación del esfuerzo 5
b) Complejidad del proyecto 14
c) Descomposición en costos unitarios 3
d) Tiempo de duración 10
e) Capacitación especial para el personal 3
f) Reuso de Software anterior 0
g) Mantenimiento previsto 0
h) Análisis de Riesgo en el desarrollo de software 0
i) Otro 0
Si es complejidad del proyecto, ¿cuáles son los factores más importantes que toma en
cuenta al momento de realizar la estimación?
a) Por experiencia 4
b) Por comparación con otros proyectos 2
c) Por medio de una métrica 2
d) Por dificultad y magnitud del proyecto 11
e) Por tiempo estimado 6
f) Tipo de tecnologías usadas 7
g) Otro 1
h) Conceptos nuevos 1
Si es por costos unitarios, ¿qué aspectos incluye con mayor frecuencia?
a) Lenguaje de programación utilizado 3
b) Tiempo requerido 8
c) Personal requerido 5
d) Especialistas consultados 1
e) Equipo utilizado 2
f) Gastos de oficina 3
g) Insumos dedicados al desarrollo 2
h) Tamaño del proyecto en cantidad de archivos, módulos o pantallas 2
elaborados
i) Gastos de entrenamiento a usuarios 2
j) Gastos de viáticos 2
k) Otro 0
¿Qué factores considera más importantes para determinar el precio de venta del sistema?

a) Similitud con proyectos anteriores 7

b) Precios de otras empresas 9
c) Según beneficio para cliente 11
d) Otro 1
e) Ningunos, solo elaboran proyectos internos 1
Si es por precio de otra empresa ¿Cuál?
a) Otras de la localidad 4
b) Alguna de México 5
c) Alguna extranjera 3
d) Una en particular 1
e) Se remite al departamento de desarrollo, se hace una licitación y una 1
comisión dictamina los requerimientos mínimos
¿El proceso de estimación que utiliza su empresa le parece práctico?
a) Sí 6
b) Medianamente 11
C) NO 1
¿El proceso de estimación que utiliza su empresa le parece justo al momento de llevarlo a
cabo?
a) Sí 10
b) Medianamente 8
c) No 1
¿El proceso de estimación que utiliza su empresa le parece fácil de emplear?
a) Sí 11
b) Medianamente 7
c) No 1
¿El proceso de estimación que utiliza su empresa ie parece flexible con respecto a su
aplicación?
a) Sí 10
b) Medianamente 5
c) No 4
¿El proceso de estimación que utiliza su empresa le parece consistente con el costo final del
proyecto?
a) Sí 5
b) Medianamente 10
c) No 4

3.3.2.1. Descripción de los resultados

Como se observa en la Figura 3.2 el 34.5% de las empresas utilizan métricas o llevan
a cabo una comparación con proyectos realizados previamente, seguido por la
estimación con base en el consejo de un experto con un 10.3%.
Se observa que las PYMES, sobre todo, dicen utilizar métricas y realizan una
comparación con proyectos previamente realizados. Por lo cual se consideró
conveniente indicar las métricas utilizadas por las PYMES para estimar el tamaño del
proyecto. En seguida se indican los porcentajes de utilización (Ver Tabla 3.3).

Tabla 3.3. Métricas y su uso en las empresas.

Métrica Porcentaje de uso

Puntos de Casos de Uso 50.0%

Puntos de Función 16.7%

COCOMO II 11.1%

Tamaño 5.6%

Tiempo/Esfuerzo 5.6%

Posteriormente, en la Figura 3.3, se aprecia el gráfico que indica la relación de los

valores.
 Métricas de estimación

Figura 3.3. Métricas de estimación.

Otro aspecto importante es la comparación con proyectos previos. Donde, el 26.7%,
lleva a cabo un registro de todas las estimaciones hechas a los proyectos que realizan;
el 26,7%, no lleva a cabo un registro y el 46.7% restante, lleva a cabo un registro de
la estimación de software pero no en todos. Para el caso del registro de proyectos
terminados, el 26.7%, lleva un registro; el 40.0%, no lleva un registro y el 33.3%,
lleva registro pero no en todos los proyectos terminados. En la Figura 3.4 se observa
una comparación de ambos registros.
 Comparación del registro del esfuerzo estimado
con el registro del esfuerzo real

■ Estimación del Esfuerzo

□ Esfuerzo Real

Figura 3.4. Comparación entre el registro de estimaciones de proyectos y registro de

proyectos terminados.
Dado el uso que las PYMES dan a la comparación con proyectos previos, resultan
contradictorios estos resultados, aunque cabe aclarar que no necesariamente las
empresas que llevan un registro de la estimación son las mismas que registran el
esfuerzo real.

Los factores más importantes al momento de estimar el costo del proyecto, incluyen la
estimación del esfuerzo, con un 14.3%; la complejidad del proyecto, con un 40.0%; la
descomposición del precio en costos unitarios, con 8.6%; el tiempo de duración del
proyecto, con 28.6% y la capacitación especial para el personal con un 8.6%. En la
Figura 3.5 se observa un gráfico que indica dichos valores.
 Factores para estimar el costo de un proyecto

personal

Figura 3.5. Factores a considerar para estimar el costo.

Se puede ver que la mayoría toma más en cuenta la complejidad del proyecto al
momento de hacer una estimación del costo. Posteriormente, se preguntó a las
empresas qué factores consideraban más importantes acerca de la complejidad del
proyecto, de lo cual se obtuvo que el 11.8%, consideraba la experiencia como un
factor importante; el 5.9%,. consideraba llevar a cabo la comparación con otros
proyectos como importante; el 5.9%, cuantificaba la complejidad del proyecto por
medio de una métrica; el 32.4%, tomaba en cuenta la dificultad y magnitud del
proyecto; el 17.6%, medía la complejidad por medio de el tiempo estimado; el 20.6%,
contabiliza el tipo de tecnologías usadas y el 2.9%, considera conceptos nuevos. En la
Figura 3.6, se observa la distribución de dichos factores.
 Factores por complejidad del proyecto

12

a) Por b) Por c) Por medio d) Por e) Por tiempo f) Tipo de g) Otro h) Conceptos
experiencia comparación de una dificultad y estimado tecnologías nuevos
con otros métrica magnitud del usadas
proyectos proyecto

Figura 3.6. Factores que se toman en cuenta por complejidad del proyecto.
Por último, los factores que se toman en cuenta para determinar el precio de venta son
la similitud con proyectos anteriores, con un 24.1%; los precios de otras empresas,
con un 31.0%; el beneficio para cliente, con un 37.9% y una empresa que representa
el 3.4%, solo elabora proyectos internos, así que no estima el costo. En la Figura 3.7
se observan dichos datos.

Factores para determinar precio de venta

a) Similitud con b) Precios de c) Según d) Otro e) Ningunos,

proyectos otras empresas beneficio para solo elaboran
anteriores cliente proyectos
internos

Figura 3.7. Factores para determinar el precio de venta.

3.3.3. Conclusiones de la Etapa 2

Es importante destacar que las PYMES, al igual que para las empresas certificadas,
estiman el esfuerzo por medio de métricas y comparando los proyectos a elaborar con
los realizados previamente. Lo cual va demostrando la importancia de elaborar una
metodología que permita ambos aspectos, siendo además las métricas de Software
más empleadas los Puntos de Casos de Uso y los Puntos de Función, es importante
incluir un proceso de medición haciendo uso de ellos.

También destaca el tiempo para elaborar la estimación, que a pesar de ser algo
disperso (8 a 40 horas), implica el uso de un tiempo valioso para el cual una
metodología más rápida permitiría reducirlo.

Siendo el la dificultad y magnitud del proyecto, además del tiempo requerido para
elaborarlo un aspecto importante a la hora de estimar el proyecto, también es
necesario considerar éstos en la elaboración de una metodología.

3.4. Etapa 3: Entrevista a PYMES

Luego de realizar un análisis de los resultados obtenidos en las etapas anteriores, se

procedió elaborar una serie de preguntas que conformaron una entrevista (ver
Apéndice E) con la finalidad de sustentar la metodología de estimación de costos
propuesta.

3.4.1. Planteamiento de la entrevista

Aplicada a PYMES de manera personal, se interrogó sobre elementos, obtenidos del

marco teórico y de las primeras dos etapas del estudio, con el fin de conocer su grado
de influencia en el desarrollo de la aplicación. Dichos elementos se agrupan en tres
categorías:

1. Modificadores de esfuerzo.

2. Modificadores de calendario.

3. Modificadores de costo.

En lo que se refiere a los modificadores relacionados al esfuerzo, se agruparon todos

aquellos conceptos que resaltaron en las Etapas 1 y 2 relacionadas con el equipo de
desarrollo, así como los elementos de hardware y software que podrían necesitarse
para elaborar el programa que implican un ajuste en los cálculos que las PYMES
desarrolladoras de Software lleven a cabo.

Por su parte, en los modificadores al calendario se incluyeron todos los riesgos que en
genera! podrían afectar el desarrollo del software, incrementar su precio e inclusive
provocar el fracaso en la elaboración del mismo.

Finalmente los modificadores de costo no fueron incluidos para evitar una longitud
excesiva en la entrevista, además de que existe suficiente información práctica
documentada análisis de costos.

3.4.2. Resultados Etapa 3.

Se logró contactar a cinco PYMES, tres de las cuales ya tenían un conocimiento previo
del estudio de campo debido a que habían participado en la segunda etapa. Cuando se
interrogó acerca de la precisión de las estimaciones de tiempo que llevaban a cabo,
tres de ellas dijeron elaborar estimaciones exactas, una dijo estar en un rango del 70%
de exactitud y una dijo que generalmente el esfuerzo real resultaba el doble del
estimado. Cabe destacar que sólo dos empresas llevan a cabo el registro de datos
históricos.

Con fundamentos teóricos y empíricos, se consideró una serie de modificadores sobre

los cuales se llevó a cabo la entrevista. En la Tabla 3.4 (a) y (b), se detallan los
modificadores, sus elementos y grado de influencia (Ninguna, Poca, Media, Suficiente,
Alta), según el promedio de las cinco PYMES en los proyectos que desarrollan.

Tabla 3.4. (a) Elementos relacionados con el Modificador Esfuerzo y su influencia.

Elemento Influencia

Familiaridad con el modelo de desarrollo Suficiente

Habilidades del equipo de desarrollo Alta

Conocimiento de Hardware Especializado Media

Información de Proyectos Similares Alta

Capacidad de Liderazgo Media

Conocimiento de Técnicas y Herramientas de Ingeniería de Software Suficiente

Conocimiento de Lenguajes y Plataformas Suficiente

 Elemento Influencia

Restricciones de tiempo Alta

Riesgos Alta

Poca estabilidad de requerimientos Alta

Falta de comunicación con el cliente Media

Análisis incorrecto Suficiente

Pérdida de base de conocimiento Alta

Turnos Poca

Personal de medio tiempo Media

3.4.3. Conclusiones de la Etapa 3

En los elementos relacionados al esfuerzo, destacan la habilidad del equipo de

desarrollo y la información que cuentan de proyectos similares como características
más importantes y aquellas que se considerarán principalmente en la elaboración de la
metodología.

En el caso de los elementos relacionados con el calendario, las restricciones de tiempo,

los riesgos, la falta de estabilidad de los requerimientos y la pérdida de la base del
conocimiento son aquellos que mayor importancia tienen para las PYMES. Cabe
mencionar que los dos últimos también son riesgos, por lo que para elaborar la
propuesta de metodología se considerarán restricciones de tiempo y riesgos.
Capítulo 4. Propuesta de Metodología de Estimación

El presente capítulo, contiene la propuesta metodológica de estimación de costos para

PYMES. Incluye las características del método, la innovación que propone, los pasos
que lo forman y un diagrama de las actividades a realizar. Se describen tareas,
artefactos y resultados del mismo y se definen los elementos considerados para la
construcción de una línea base para la estimación.

4.1. Características

Para el caso de la presente metodología se podrán usar opcionalmente la métricas

Puntos de Función o Puntos de Casos de Uso. Sobre la estimación inicial de esfuerzo se
aplican una serie de modificadores relacionados con el costo y el calendario de
desarrollo, todos ellos basados en las características particulares de las PYMES,
seleccionados con base en los resultados obtenidos en el estudio presentado en el
Capítulo 3 y los elementos teóricos del Capítulo 2, en su Sección 2.4.

Por medio de la estimación por Puntos de Función o Puntos de Casos de Uso, será
posible realizar una estimación del tamaño del sistema que luego será ajustada con la
línea base, lo que permitirá a las empresas adaptar el estimado a su situación
particular. Conforme la empresa registre más datos de los proyectos que vaya
elaborando, tendrá un mayor acercamiento de su estimación a la realidad del proyecto.

4.2. Procedimiento a seguir para aplicar la metodología

propuesta

Los pasos a seguir para llevar a cabo la metodología de estimación ajustada para
PYMES, y así obtener un estimado del costo, se describen en los siguientes párrafos.
En la Figura 4.1, se despliega un diagrama de flujo que detalla el proceso para mayor
comprensión de los elementos que conforman la metodología de Estimación de costos
para PYMES (EcPymes).
 Figura 4.1. Diagrama de Flujo de la Metodología de Estimación de Costos.

4.2.1. Descripción de las variables principales

A partir del marco teórico, se determinó que existen tres variables sujetas a la
estimación en un proyecto:

1. Esfuerzo. Se refiere a la cantidad de Horas/Persona por unidad de medida

estimada necesaria para llevar a cabo el desarrollo de un proyecto de
software. Su importancia radica en que al relacionarlo con la productividad del
equipo de desarrollo, permite conocer el calendario. Al final del proyecto
 también puede compararse el esfuerzo estimado con el real y así obtener
información histórica que retroalimentará el modelo. Usualmente se calcula a
partir del tamaño del software propuesto.

2. Calendario. Se refiere al tiempo en días, semanas o meses en que se va a

elaborar la aplicación. Depende directamente del esfuerzo estimado. Es
importante ya que por medio de éste se asignan recursos humanos y
materiales al proyecto. Aún en proyectos sin restricción alguna de tiempo es
necesario establecer un calendario que permita visualizar el avance.

3. Costo. Una vez asignados los recursos necesarios a la aplicación, según el

calendario, es necesario saber cuánto gastará la empresa para elaborarlo,
además de costos genéricos (papelería, capacitación, nuevo software de apoyo
y otros). Es importante conocer el costo de un proyecto, aún en la elaboración
para sistemas internos de la empresa, para conocer cuánto valdrá el software
y poder destinar los recursos económicos necesarios.

Para cada una de las variables existe una o más fórmulas o tablas para calcularse. Este
cálculo es más bien teórico y debe ajustarse a la realidad de las empresas,
especialmente en PYMES. Éste ajuste puede hacerse implementando una serie de
modificadores que se describen a continuación.

4.2.1.1. Modificadores relacionados al Esfuerzo

Los elementos relacionados con el Esfuerzo se tomaron de los modificadores

propuestos para la métrica Puntos de Función o Puntos de Casos de Uso (Ver sección
2.3):

1. Familiaridad con el modelo de desarrollo. Es el grado de conocimiento

relacionado con el ciclo de vida del proyecto del que haga uso la empresa.
Afecta de manera inversa al Esfuerzo, ya que a mayor conocimiento,
presumiblemente menor esfuerzo. Es relevante que el equipo de desarrollo
conozca al menos los fundamentos del modelo de desarrollo para poder llevar
a cabo el proyecto. El grado de conocimiento se puede incrementar por medio
de la capacitación del equipo.

2. Habilidades del equipo de desarrollo. Se refiere a la facilidad con que el equipo

de desarrollo lleva a cabo las actividades de análisis, codificación y prueba.
Afecta inversamente al esfuerzo ya que, a mayor habilidad, menor esfuerzo;
 por lo mismo es muy importante. También puede incrementarse con
capacitación de los desarrolladores.

3. Información de proyectos sími/ares. Incluye todos los datos históricos

relacionados con proyectos previos. Permite al equipo de desarrollo estimar
con mayor aproximación el esfuerzo de un proyecto, además de brindar
información de cómo se puede llevar a cabo el mismo. Influye inversamente al
esfuerzo.

4.2.1.2. Modificadores relacionados con el Calendario

Los elementos relacionados con el Calendario son:

1. Restricciones de Tiempo. Es el marco de tiempo, medido en días, semanas o

meses, de duración de desarrollo del proyecto definido por el cliente. Implica
la asignación de recursos para ajustarse a cumplir los plazos determinados de
tiempo. Afecta de manera inversa al calendario, a menor cantidad de tiempo,
se requiere mayor cantidad de recursos humanos y materiales.

2. Riesgos. Implican todos los elementos que representan un grado de

incertidumbre en el desarrollo del proyecto. Afecta tanto al calendario como al
costo debido a que, a mayor riesgo, mayor tiempo y presumiblemente mayor
costo. Algunos de los riesgos más representativos son: sólo los riesgos
asociados a requerimientos deben influir, pues los demás corresponden más a
la organización ejecutora.

a) Poca estabilidad en los requerimientos. Se presenta cuando el cliente no

está seguro de todas las necesidades que debe cubrir el sistema, implica
desconocimiento y ambigüedad de la información sobre el proyecto. Hace
necesaria una mayor comunicación con el cliente y afecta inversamente al
calendario: a menor estabilidad, mayor tiempo.

b) Pérdida de base de conocimiento. Hace referencia a la falta de

documentación adecuada de los proyectos que se han desarrollado, dado que
la base del conocimiento radica en los recursos humanos de la empresa, lo
cual conlleva a un mayor riesgo en la pérdida del conocimiento para el
empresa. Afecta a todo un proyecto dado que implica un mayor tiempo de
calendario.
4.2.1.3. Modificadores relacionados con el Costo

Los elementos relacionados con el Costo para el caso particular de Empresas

Desarrolladoras de Software son:

1. Costos Directos. Son todos aquellos elementos que se relacionan directamente

con la producción del proyecto. En el caso de las desarroliadoras son los
costos por horario de equipo y salarios a personal. Se influye de manera
directa con el calendario y su importancia radica en que es el principal
elemento del presupuesto.

2. Costos indirectos. Representan elementos que son soporte para la producción

del proyecto. Su importancia radica en que influyen en muchos conceptos del
presupuesto. Algunos costos indirectos en el caso de empresas desarrolladoras
de software son:

a) Capacitación ai persona!. Todos los elementos de formación de personal en

una herramienta relacionada directamente con la Ingeniería de Software o el
desarrollo de sistemas. Para obtener el valor, el costo total de las
capacitaciones se divide entre el número de proyectos para los cuales
servirán. Influye directamente al presupuesto y es recomendable que la
empresa incluya una proporción del costo de la capacitación en el presupuesto
de un proyecto.

b) Asesorías. Si la empresa se ve en la necesidad de consultar alguna duda a

algún especialista ya sea una empresa o persona física ajenos a la
organización, es recomendable que se incluya el costo por consulta en el costo
del proyecto.

3. Gastos administrativos. Se refiere a todos aquellos elementos que implican un

costo para el funcionamiento de la empresa, no se relacionan directamente
con el proyecto pero implican un mejor funcionamiento del mismo. Para
agregarlos en el presupuesto, se recomienda incluir una parte proporcional de
los gastos como luz, agua, teléfono, renta de local, gastos de papelería, etc.,
en el costo del proyecto.
4.2.2. Descripción de la metodología

1. Estimar el tamaño, lo cual puede ser con Puntos de Casos de Uso o Puntos de
Función.

2. Posteriormente se presentan dos opciones, una con datos históricos y otra sin
datos históricos.

a) Con datos históricos-, se elabora una estimación del esfuerzo comparando el

tamaño aproximado obtenido previamente con los históricos y luego aplicando
ios modificadores históricos de la línea base. Si no se cuenta con datos
históricos suficientes, se recomienda considerar la opción b.

b) Sin datos históricos-, se lleva a cabo la estimación con las propuestas para
estimar el esfuerzo (Ver sección 2.4).

3. Si se cuenta con una línea base de modificadores de esfuerzo, se aplican al

esfuerzo estimado para ajustarlo. Si no se cuenta con una línea base de
modificadores no es necesario aplicar este paso.

4. Ya que se cuenta con el esfuerzo en Horas/Persona, la empresa procede a

elaborar el calendario de desarrollo de acuerdo con el personal con que cuenta
y restricciones particulares.

5. ' Con el calendario y la cantidad de recursos ya asignada al proceso, se estima

el valor monetario del proyecto considerando los tres tipos distintos de costos.
Para ello debe considerar el salario que proporcionará a los desarrolladores del
proyecto así como los gastos intrínsecos al proyecto.

6. Una vez obtenido el costo estimado se lleva a cabo el desarrollo del proyecto.

Al término del desarrollo se registran los datos reales del proyecto elaborado que
pasarán a formar parte de los datos históricos.

4.3. Ejemplo de aplicación de la metodología propuesta

Con la finalidad de llevar a cabo una estimación por medio de la metodología

propuesta, se considerará el ejemplo de la sección 2.3.1, del cual se tomará en cuenta
el valor obtenido en Puntos de Función como tamaño estimado para el proyecto.
4.3.1. Obtención del esfuerzo

El tamaño del sistema es de 131.67 Puntos de Función, dado que no se cuenta con
datos históricos, se aplicará directamente los valores de la Tabla 2.19 (Incremento del
*
costo por Punto de Función), de la sección 2.4.1. Como el tamaño del sistema de
software propuesto es mayor a 100 Puntos de función pero no excede los 500, el valor
de referencia a considerar será de 1.4 horas/pf, lo cual da un total de 184.34 horas de
trabajo totales (de acuerdo a la Tabla 2.19).

4.3.2. Obtención del calendario

Una vez estimadas las 184.34 horas de esfuerzo, se procede a distribuirlo en días de
trabajo y desarrolladores. En la Tabla 4.1, se indica la distribución diaria y total
considerando un solo desarrollador por cada fase.

Tabla 4.1 Distribución de Trabajo estimada de los desarrolladores

Fases de desarrollo Horas diarias Horas totales

Administración del Proyecto 8 184.34

Requerimientos 4 9.22

Análisis y Diseño 4 36.87

Construcción 4 119.82

Instrucción y capacitación al Usuario 4 18.43

La distribución sugerida se basa en el porcentaje indicado en el Proceso Unificado de

Desarrollo (PUDS) que puede encontrarse más a detalle en [Humphrey, W. S (2003)].
Cabe mencionar que tanto la distribución sugerida de tiempo así como el número de
desarrolladores puede modificarse según las características inherentes a la empresa.

Es importante aclarar que aunque sea una misma persona quien lleve a cabo dos fases
de desarrollo distintas, como puede ser el caso de algunas PYMES, para efectos de la
estimación deben separarse las actividades por tipo de trabajo. Cabe mencionar que si
los desarrolladores llevan a cabo tareas que no corresponden al proyecto, no se
reportan.

En este ejemplo, se consideraron dieciséis horas diarias acumuladas de trabajo, cinco

días a la semana, con base en lo cual tomaría un estimado de once días y medio llevar
a cabo el sistema de Software sin considerar ninguna restricción en este aspecto por
parte del cliente.

4.3.3. Obtención del Costo

Tomando como base cuatro desarrolladores y al líder de proyecto trabajando las horas
especificadas en la Tabla 4.1 durante cinco días a la semana, se alimenta la Tabla 4.2,
para indicar el salario para los mismos, los cuales representan costos directos.

Tabla 4.2 Salarios estimados del personal desárrollador de software.

Sueldo por Sueldo diario por Sueldo total por

Puesto
hora persona persona

Administración del Proyecto $156.25 $1,250.00 $28,803.12

Requerimientos $125.00 $500.00 $1,152.50

Análisis y Diseño $125.00 $500.00 $4,608.75

Construcción $125.00 $500.00 $14,977.50

Instrucción y capacitación al
$125.00 $500.00 $2,303.75
Usuario

Lo cual genera un costo total de $51,845.62 en salarios a los desarrolladores, al igual

que la asignación de tiempos, el sueldo por hora debe ser definido por la Empresa
Desarrolladora de Software.

Además de los salarios al personal, que implican costos directos, se añadirá al costo
total del proyecto algunos costos indirectos, entre los que se encuentra la adquisición
de un dispositivo óptico que permita registrar códigos de barras con un valor de
$1,500.00, también deben considerarse los costos de insumos relacionados con el
proyecto como papelería y consumibles; además de agua, luz, teléfono, entre otros,
cuyo costo se estimará de manera proporcional correspondiente a los días que tomará
desarrollar el proyecto los cuales se indican en la Tabla 4.3.
 Tabla 4.3 Costos indirectos

Concepto Valor

Papelería en general $500.00

Consumibles $500.00

Gasto de luz $57.00

Consumo de agua $38.00

Renta de Internet $190.00

Renta de Teléfono $190.00

Todo esto genera un valor total de $1,475.00, lo cual aunado al salario del equipo de
desarrollo, generará el costo total del proyecto. Dependiendo de las características de
la empresa, así como del proyecto, pueden añadirse o retirarse conceptos.

4.3.4. Costo total del Proyecto

Sumando los valores obtenidos, se obtiene un costo total de $54,820.62. Hay que
aclarar que dentro de este valor representa el costo del proyecto y no el precio para el
cliente, por lo cual no se incluyen conceptos como la ganancia de la empresa.
Capítulo 5. Modelado del Sistema de Software
EcPymes

Una vez planteado el método, para tener mayor comprensión y facilidad de aplicación
por parte de las empresas del mismo, se desarrolló un pequeño sistema de software
denominado EcPymes (Estimación de costos para PYMES).

Dicho sistema permite al usuario calcular a partir del esfuerzo estimado, basado en
Puntos de Función o Puntos de Casos de Uso; obtener un calendario, para
posteriormente estimar un costo. Siendo que son tres las variables principales que
incluye la metodología, de manera análoga se separó en tres partes más una que
permita revisar datos históricos.

El presente capítulo incluye los modelos del sistema, así como una descripción del
funcionamiento de mismo. El manejo detallado del sistema se incluye en el Manual de
Operación del Apéndice B.

Cabe resaltar que además del diseño del sistema, se realizó una prueba de usabilidad
al programa la cual se detalla en el Apéndice C.

5.1. Modelo de Casos de Uso de EcPymes

En el análisis que se llevó a cabo para el sistema EcPymes, se realizó un modelo que
incluye tres casos de uso correspondientes a las variables principales de la
metodología, uno más que permite revisar proyectos anteriores, uno que permite
guardarlos para su posterior apertura y uno correspondiente al manejo de datos
históricos. En la Figura 5.1, se ilustra el diagrama de Casos de Uso de EcPymes.
 Figura 5.1. Modelo de Casos de Uso.
A continuación se detalla lo que cada Caso de Uso realiza y las restricciones que tiene
asociadas utilizando la anotación sugerida en [Sommerville, I. (2005), p. 271] para
descripción de cada uno.

5.1.1. Caso de Uso Estima Esfuerzo

Consiste en la inserción de la cantidad de puntos de función o puntos de casos de uso

y su transformación, por medio de los parámetros de referencia en Horas por persona
totales por proyecto. En la Tabla 5.1 se presenta la descripción del mismo.

Tabla 5.1 Descripción del Caso de Uso Estima Esfuerzo

Caso de Uso Estima Esfuerzo

Actores Usuario

Datos Métrica y ajustes al esfuerzo

Estímulo Oprimir el botón Calcular o Utilizar Histórico y luego el botón Calcular ajuste

Respuesta Aparece la pestaña Estima Calendario

Es necesario al menos ingresar la métrica del sistema, para que sea posible llevar a cabo la
Comentarios
estimación del esfuerzo

5.1.2. Caso de Uso Estima Calendario

Recibe el esfuerzo previamente estimado y permite al usuario distribuirlo entre el

número de desarrolladores con los que cuente, el tiempo que trabajarían diariamente y
el tiempo de trabajo que cada desarrollador va a dedicar al proyecto. En la Tabla 5.2
se presenta la descripción del mismo.

Tabla 5.2 Descripción del Caso de Uso Estima Calendario

Caso de Uso Estima Calendario

Actores Usuario

Número de miembros del equipo de desarrollo en cada fase, horas diarias y totales que
Datos
laborarán, días de la semana a laborar

Estímulo Oprimir el botón calcular

Respuesta Aparece la pestaña Estimar Costos

Se incluye una sugerencia de tiempo de desarrollo en cada fase además de un apartado que
Comentarios permite calcular el tiempo necesario de desarrollo diario con base en restricciones hechas por
el cliente

5.1.3. Caso de Uso Estima Costo

Permite al usuario asignar un valor monetario al trabajo de los desarrolladores, así

como agregar otros gastos como pueden ser capacitaciones, elementos de Hardware,
Software, luz, agua, entre otras. En la Tabla 5.3 se presenta la descripción del mismo.

Tabla 5.3 Descripción del Caso de Uso Estima Costo

Caso de Uso Estima Costo

Actores Usuario

Salarios, capacitaciones (costos y desarrolladores a tomarlas), software y hardware para

Datos adquisición (tanto en estos como en las capacitaciones oprimir el botón añadir) y otros gastos
(luz, agua, renta de local, entre otros)

Estímulo Oprimir el botón actualizar y en el caso de la pestaña Otros gastos oprimir el botón total

Respuesta Se obtiene el costo estimado del sistema

Comentarios Debido a que implican varios aspectos, cada uno se separó en pestañas

5.1.4. Caso de Uso Guarda Estimación

Una vez que ya se completó la estimación o si el usuario desea guardar el avance para
retomarlo posteriormente, este caso de uso proporciona la posibilidad de almacenar un
archivo con extensión *.ecp. En la Tabla 5.4 se presenta la descripción del mismo.
 Tabla 5.4 Descripción del Caso de Uso Guarda Estimación

Caso de Uso Guarda Estimación

Actores Usuario

Datos Ruta de almacenamiento y nombre del proyecto

Estímulo Oprimir el botón Guardar o Guardar como

Respuesta Mensaje de guardado

Para el caso de la opción Guardar no se necesitan datos, el sistema almacenará el proyecto

Comentarios
en el directorio donde se encuentre el programa

5.1.5. Caso de Uso Abre Estimación Previa

Si se ha almacenado un archivo *.ecp, éste puede retomarse a partir del punto en que
se guardó con este caso de uso. En la Tabla 5.5 se presenta la descripción del mismo.

Tabla 5.5 Descripción del Caso de Uso Abre Estimación Previa

Caso de Uso Abre Estimación Previa

Actores Usuario

Datos Ruta y nombre del proyecto

Estímulo Clic en el botón Abrir Proyecto Previo

Respuesta Aparece en pantalla el proyecto

Comentarios El sistema abre únicamente archivos con extensión propia del mismo

5.1.6. Caso de Uso Almacena Históricos

Con este caso el usuario puede, una vez terminado el proyecto, ingresar los datos
reales de tiempo y costo del proyecto elaborado y con ello crear una línea base más
adaptable a la empresa. En la Tabla 5.6 se presenta la descripción del mismo.
 Tabla 5.6 Descripción del Caso de Uso Almacena Históricos

Caso de Uso Almacena Históricos

Actores Usuario

Datos Datos Históricos: métrica, tiempo real de desarrollo, costo estimado y costo real

Estímulo Oprimir botón Añade o Elimina

Respuesta Mensaje de Almacenado

Conforme se vayan creando datos históricos estos se irán promediando para ajustar el
Comentarios
esfuerzo a las características de la empresa.

5.2. Realización de Casos de Uso de Diseño

En esta sección se detallan dos de ¡os principales artefactos de diseño: diagramas de

secuencia y diagrama de clases participantes en cada caso de uso. Cabe aclarar que
solo se muestra el curso normal de cada caso de uso.

5.2.1. Realización del Caso de Uso de diseño: Estima Esfuerzo

En la Figura 5.2. (a) se muestra el diagrama de secuencia correspondiente al flujo de

eventos del Caso de Uso Estima Esfuerzo (Sección 5.1.1) mismo que se detalla con el
flujo de sucesos a continuación:

1. El usuario da clic en el Menú Nuevo Proyecto y selecciona Puntos de Función o

Puntos de Casos de Uso.

2. El sistema llama al Panel Esfuerzo y lo abre en pantalla.

3. El usuario introduce los datos.

4. El usuario estima el esfuerzo.

5. El usuario introduce los ajustes.

6. El usuario estima el esfuerzo ajustado.

7. El sistema envía el esfuerzo ajustado a la clase proyecto y llama al panel de

calendario.
 sd Estima Esfuerzo^

%
usuario
- gui::Menu guí:: Panel Esfuerzo systerrE: Proyecto

T
i i
i i
i clic en nuevo proyectoQ i
A------------------------------------ te i
i
i

u
i
i

PanelEtfuerzoftnt, Proyecto, JTabbedPane, ArchivoHistorico)

i i
introduce datos() |
i
i
i I
dic Calcular!)
i
i
i
i e^uerzo ajustado() :doub(e
i
i
i
i i i
i i i
i i
i i i
i i i
i i i
i

Figura 5.2. (a) Diagrama de Secuencia: Estima Esfuerzo.

Las clases utilizadas se detallan en la Figura 5.2. (b) Es importante señalar que la clase
proyecto se utiliza en todas las pestañas del sistema ya que es la que se encarga de
almacenar temporalmente los datos, dado esto solo se mostrará en esta ocasión. Así
como el resto.de las clases que se repitan.
 JPanel
PanelEsfuerzo

- bandera boolean = false

- calcular JButton
JMenuBar - calcularAjuste: JButton
ActionListener - decremento JTextField
Menú ~ durMin JTextField
~ es_ajustado JTextField
~ abrir: JMenultem * esfuerzoEstimado: JTextField
* archivo: JMenu ~ et_aj: JLabel
~ ayuda: JMenultem * et_dec JLabel
- dp: JDesktopPane - et_dm. JLabel
- et_EE: JLabel
~ esfuerzoCU: JMenultem
~ et_fp. JLabel
* esfuerzoPF: JMenultem
- et_hpfp JLabel
- nuevo: JMenu - et_hpls: JLabel
~ proyecto: Proyecto - et_inc. JLabel
- ventana: JFrame ~ et_pcu: JLabel
~ et_pf: JLabel
+ actionPerformed(ActionEvent): void - et_ps JLabel
inicializacionO : void ~ et_vtls JLabel
+ Menu(JMenultem. JDesktopPane, JFrame) - factorProduc: JTextField
- gbc: GridBagConstraints
-mp A - horasPersonaFP JTextField
- horasPeraonaLS: JTextField
- incremento: JTextField
- proy_sm JTextField
JFrame ~ proyecto: Proyecto
PantailaPrincipal + PUNTOS_CASOS_USO: int = 1 {readQnly}
+ PUNTQS_FUNCION: int = 0 {readQnly}
ayuda: JMenultem ~ puntosCasosU» JTextField
dp: JDesktopPane - puntosFuncion: JTextField
mp: Menú + tb: JTabbedPane
- valorTablaLS: JTextField
+ PantallaPrincipalO
+ añadeListenerQ : void
- ponLaAyudaQ : void + midalizaCompAjusteO : void
+ ¡nidal izaCompCUQ : void
♦ iniaalizaCompPFO : void
+ PanelEsfuerzofint. Proyecto. JTabbedPane)
- ;;or¡C.~ --ra ¡-¿¡Component .m. ¡nt ¡nt.nitj.void

Figura 5.2. (b) Diagramas de clases correspondientes a la estimación del esfuerzo.

5.2.2. Realización del Caso de Uso de diseño: Estima Calendario

En la Figura 5.3. (a) se muestra el diagrama de secuencia correspondiente al flujo de

eventos del Caso de Uso Estima Calendario (Sección 5.1.2) mismo que se detalla con
el flujo de sucesos a continuación:

1. El usuario ingresa los datos correspondientes a la cantidad de personas que

van a integrar al equipo de desarrollo en sus diferentes fases, así como el
tiempo en el que intervendrán en el mismo.

2. Oprime el botón Calcular.

3. El sistema guarda los datos correspondientes y llama el panel de costos.

sd estimaCalendario

$
guiiPanelCalendario system: Proyecto

usuario
i i
i i
i i
i i
----------------- ------------- ^*1 1
1
1
diasTotalaLaborar() :double 1
1
*LI
1
duracionMinutos() :double
1
1

1
desarrolladoresTotales() :double 1

1
diasTotalaLaborarO :double 1
1
*u
calculoTiempoSugeridoO 1
1
1
1
[ F 1
1
1

Figura 5.3. (a) Diagrama de Secuencia: Estima Calendario.

Como se mencionó anteriormente en este caso de uso también se utiliza la clase
Proyecto y la clase PanelCalendario que se detalla a continuación en la Figura 5.3 (b).
 class gul /

JPanel
PanelCafendario

~ a_c: JTextField
~ a_hd: JTextField
- a.ht: JTextField
- c_c: JTextField
- c_hd. JTextField
- c_ht: JTextField
~ calcularTodo: JButton
- d_c: JTextField
- d_hd: JTextField
- d_ht: JTextField
- desarrolladoresTotale& JTextField
- diasjaborales JTextField
- diasTotales JTextField
- gbc. GridBagConstraints
- horasAcDiarias JTextField
~ horasNecesariasPlazo: JTextField
- horasPersona: JTextField
- I_c: JTextField
- l_hd: JTextField
* l_ht. JTextField
- o_c: JTextField
~ o_hd: JTextField
- o_ht: JTextField
~ proyecto: Proyecto
- t_c: JTextField
- t_hd: JTextField
- t_ht: JTextField
- tb: JTabbedPane
~ tiempoCliente: JTextField

añadeListenert): void
inidalizaComponentesO : void
PanelCalendario(Proyecto, JTabbedPane)
ponConstrains(Component. int, int int, int): void
valorCelda(JTextField): double

Figura 5.3. (b) Diagrama de clases correspondiente a la estimación del calendario.

5.2.3. Realización del Caso de Uso de diseño: Estima Costos

En la Figura 5.4. (a) se muestra el diagrama de secuencia correspondiente al flujo de

eventos del Caso de Uso Estima Esfuerzo (Sección 5.1.3) mismo que se detalla con el
flujo de sucesos a continuación:

1. El usuario ingresa en cada uno de los subpaneles de Costo: salarios,

capacitaciones, adquisición de Hardware y Software y otros gastos.

2. Ya sea cuando termina de ingresar los datos o luego de que ingresó los datos
en cada pestaña el usuario oprime el botón Actualizar para obtener el valor
total o parcial estimado del costo.

a) En el subpanel otros gastos luego de ingresar dichos datos, el usuario

oprime el botón Total con la finalidad de obtener el compilado de otros gastos.

3. Mientras se actualiza, el sistema guarda los valores recientemente ingresados.

 Figura 5.4. (a) Diagrama de Secuencia: Estima Costo.
Además de la clase PanelCosto y la clase proyecto, que puede observarse en la Figura
5.4. (b), internamente se hace uso de las clases correspondientes a cada una de las
pestañas que utiliza, las cuales se observan en la Figura 5.4. (c). Su tamaño es algo
reducido debido a que sirve de conexión al resto de clases que manejan los datos de la
estimación de costos.

class gui

JPanel
PanelCosto

- actualizar JButton
- et1: JLabel
- gbc: GridBagConstraints
~ pestañasCostos JTabbedPane
~ proyecto: Proyecto
- total' JTextField

miaalizaCompO: void
+ PanelCosto(Proyecto)
- ponConstrainsíComponent, mt m! int. mt) void

Figura 5.4. (b) Diagrama de clases correspondiente a la estimación del calendario.

 JPanel JPanel
PanelSa lados PaneIRecursos

~ gbc: GridBagConstraints = new GridBagCons.. - addH: JButton

- ms ModeloSalarios - addS: JButton
- tabla: JTable gbc. GridBagConstraints
~ total: JTextFíeld hard. JTable
- mh: ModeloHardware
+ PanelSalariosfProyecto) - ms modeioSoftware
- ponConstrains(Component. int. int, ínt, int): void - proyecto: Proyecto
- removeH JButton
JPanel
- removeS JButton
- scrollH: JScrollPane
PanelCapa citación scrollS: JScrollPane
- soft. JTable
- add JButton
- totalH: JTextFíeld
* gbc GridBagConstraints
totalS: JTextFíeld
- me: modeloCapacitacion
- proy: Proyecto
- remove JButton accionesO: void
iniciaCompt): void
- tabla: JTable
+ Panel Recursos(Proyecto)
~ total: JTextFíeld
ponConstrainsíComponent, int, int, int, int) void
- accionesO: void
+ iniciaCompü void
+ PanelCapacitadon(Proyecto)
- ponConstrains(Component. int, int. int, int): void

class modelos Tabla

7
TableModei
JPanel
ModeloSalarios
PanelOtrosGasto
Id: LinkedList<Desarrollador> = new LinkedList<...
~ agua_costo: JTextFíeld
listeners LinkedList<TableModelListener> = new LinkedLisK...
- agua_cXp: JTextFíeld
proyecto: Proyecto
- agua_meses_trabajo: JTextFíeld
total JTextFíeld
~ agua_proy_mes JTextFíeld
-> asesona: JTextFíeld
+ addDesarrolladoqDesarrollador): void
* consumibles JTextFíeld
+ addTableModelListenerfTableModelListener). void
- gbc: GridBagConstraints
avisaSuscnptorestTableModelEvent) void
- intemet_costo JTextFíeld
+ getColumnClass(int): Class<?>
~ intemet_cXp: JTextFíeld
+ getColumnCountO : int
- intemet_meses_trabajo: JTextFíeld
+ getColumnName(int): String
- intemet_proy_mes JTextFíeld
+ getRowCountO: int
- iocal_costo JTextFíeld
+ getValueAt(int, int): Object
- local_cXp: JTextFíeld
+ isCellEditablefint, int) boolean
- Iocal_meses_trabajo: JTextFíeld
+ ModeloSalarios(Proyecto, JTextFíeld)
- Iocal_proy_mes JTextFíeld
+ removeTableModelListener(TableModelListener): void
- !uz_bimestre_trabajado. JTextFíeld
+ setValueAt(Qbject, int, int): void
- luz_costo: JTextFíeld
- iuz_cXp' JTextFíeld
TableModei
- Iuz_proyecto_bimestre: JTextFíeld
MocteloHardware - outsourcing: JTextFíeld
~ papelería: JTextFíeld
- adhad AdquiácionHardware
~ proyecto: Proyecto
Ih: LinkedList<Hardware>
- r_hardware_cXp: JTextFíeld
- listeners LinkedList<TableModelListener> = new LinkedList<...
- r_hardware_meses_trabajo: JTextFíeld
- total JTextFíeld
- r_hardware_proy_mes JTextFíeld
■> renta_hardware_costo. JTextFíeld
+ addHardware(Hardware): void
* telefono_costo: JTextFíeld
+ addTableModelListener(TableModelListener): void
- telefono_cXp JTextFíeld
avisaSuscriptore$(TableModelEvent) : void
- telefono_meses_trabajo: JTextFíeld
+ borra Hardware(int): void
- telefono_pray_mes JTextFíeld
+ getColumnClassfint): Class<?>
- total: JTextFíeld
+ getColumnCountO: int
- total_boton: JButton
+• getColumnName(int) : String
+ getRowCountO : int
acciones(): void
+ getValueAKint. int). Object
- coiocaObjetosf). void
+ isCellEditable(int. int) boolean
creaobjetos(). void
+ ModeloHardware(AdquisidonHardware, JTextFíeld)
+ ModeloHandwareO + PanelOtrosGasto(Proyecto)
ponConstrains(Component, int. int, int, int): void
+ removeTableModelListeneríTableModelListener) void
restriccionesp: void
+ setValueAt(Qbject int, int): void

Figura 5.4. (c) Clases correspondientes a las pestañas de la estimación de costo.

5.2.4. Realización del Caso de Uso de diseño: Guarda Estimación

En la Figura 5.5. (a) se muestra el diagrama de secuencia correspondiente al flujo de

eventos del Caso de Uso Estima Esfuerzo (Sección 5.1.4) mismo que se detalla con el
flujo de sucesos a continuación:

1. El usuario da clic en la opción Guardar o Guardar como.

2. El sistema almacena los datos ingresados al proyecto con una extensión *.ecp

a) En el caso de la opción Guardar el sistema almacenará el proyecto en la

carpeta origen donde se encuentra el programa.

b) Para la opción Guardar como, el sistema almacenará el proyecto en la

carpeta que el usuario elija.

Figura 5.5. (a) Diagrama de Secuencia: Guarda Estimación.

El caso de uso utiliza la clase MenuProyecto, que puede observarse en la Figura 5.5
(b), y una utilidad de Java llamada OperacionesArchivo que permite el almacenamiento
del mismo ya sea en la ubicación origen o en la que el usuario especifique.

Una situación semejante ocurre cuando el usuario desea exportar un archivo a *.pdf
para su manejo posterior, luego de invocar la clase MenuProyecto, Figura 5.5 (b), y la
utilidad que permite la creación del documento.
 class gui /

ActionListener
MenuP royecto: :Gua rda rListener

+ actionPerformed(ActionEvent): void

ActionListener
M e nuP royecto: :G ua rda rComoLi ste ne r

+ actionPerfofmed(ActíonEvent): void

Figura 5.5. (b) Diagrama de clases correspondiente al guardado de estimación.

5.2.5. Realización del Caso de Uso de diseño: Abre Estimación Previa

En la Figura 5.6. (a) se muestra el diagrama de secuencia correspondiente al flujo de

eventos del Caso de Uso Estima Esfuerzo (Sección 5.1.5) mismo que se detalla con el
flujo de sucesos a continuación:

1. El usuario selecciona desde el menú principal la opción abrir.

2. A partir de la utilidad OperacionesArchivo el usuario selecciona la ruta de

acceso y abre el archivo.

3. El sistema muestra el archivo en pantalla.

sd AbrirEstimacion

Figura 5.6. (a) Diagrama de Secuencia: Abre Estimación previa.

Esta función se llama directamente del menú principal la cual hace uso de clase
OperacionesArchivo donde recibe la ruta del proyecto. En la Figura 5.6 (b) se observa
la clase correspondiente.
 class gui

Figura 5.6. (b) Diagrama de clases correspondiente a la apertura de un proyecto

previamente guardado.
5.2.6. Realización del Caso de Uso de diseño: Almacena Históricos

En la Figura 5.7. (a) se muestra el diagrama de secuencia correspondiente al flujo de

eventos del Caso de Uso Estima Esfuerzo (Sección 5.1.6) mismo que se detalla con el
flujo de sucesos a continuación:

1. El usuario desde el menú principal, ingresa en el panel Históricos.

2. El usuario ingresa los Datos Históricos.

3. El usuario oprime la opción Añadir para ingresar el valor histórico.

a) Si desea borrar un dato puede oprimir el botón eliminar.

 sd almacena Historíeos

Figura 5.7. (a) Diagrama de Secuencia: Almacena históricos.

DatoHistorico es la clase base que almacena los datos, la clase DatosHistoricosPFyPCU
es la que contiene la colección de los datos, una para los Puntos de Función y otra para
los Puntos de Casos de Uso.

Y la clase ArchivoHistorico es la encargada de guardar y recuperar los datos históricos

desde el archivo. Cuando se crea la instancia se recupera el archivo o se crea si no
existe. El método serializaDatosHistoricos guarda en el archivo los datos que se
encuentran. Las clases que integran el almacenamiento de datos históricos, pueden
apreciarse en la Figura 5.7 (b) a continuación.
 class system

Serializable
DatosHistoricosPFyPCU

- d_PCU: LinkedList<DatoHistorico>
- d_Pf: LinkedList<DatoHistorico>
serialVersionUID: long =-71846328903293 {readQnly}

+ addHistoricoPCU(DatoHistorico): void
+ addHistoricoPF(DatoH¡storico): void
+ DatosH¡storicosPFyPCU(LinkedList<DatoHistonco> LinkedList<DatoHistorico>)
+ DatosHistoricosPFyPCUO
+ getD_PCU(): LinkedList<DatoHistorico>
+ getD_Pf(): LintedList<DatoHistorico>
+ setD_PCU(LinkedList<DatoHistorico>): void
+ setD Pf(Linl<edL¡st<DatoHistoríco>) : void

class system
class utils
Serializable
DatoHistorico

- costoReal: double ArchivoHis torteo

~ métrica String
- serialVersionUID: long = -11076980378008... {readQnly} - dh: DatosHistoricosPFyPCU
- tiempoTotal double
- valor, double
- f: File
+ VALOR_PCU: int = 2
+ DatoHistorico(String, double. double, double) + VALOR_PF: int = 1
+ DatoHistoricoO
+ getCostoRealQ: double
+ getMetricaO : String + ArchivoHistorico()
+ getTiempoTotalO: double + getDhO : DatosHistoricosPFyPCU
+ getValor() double
+ setCostoReal(double): void
+ serializaDatosHistoricosO : void
+ setMemca(String) : void + setDh(DatosHistoricosPFyPCU) : void
+ setTiempoTotal(double). void + valorHistorico(int): double
setValor(double) • void

Figura 5.7. (b) Diagramas de clases correspondientes al almacenado de datos

históricos.
A continuación, en la Tabla 5.8, se pueden apreciar las entradas, salidas visibles y
resultados de los casos de uso.
 Caso de Uso Entradas Salidas Resultado

Estima Puntos de función o puntos de casos de uso y Aparece la pestaña

Esfuerzo
Esfuerzo factor de productividad, ajustes al esfuerzo calendario

Estima Desarrolladores, tiempo por día, tiempo total, días Aparece la pestaña
Calendario
Calendario de trabajo, restricciones del cliente de costos

Sueldos de los desarrolladores, capacitaciones, Costo total

Estima Costo adquisiciones de Hardware y Software, otros Costo estimado del
gastos proyecto

Guarda Mensaje de Estimación

Ruta, nombre del proyecto
Estimación confirmación guardada

Abre Aparece el
Estimación Ruta, nombre del proyecto proyecto en Estimación abierta
previa pantalla

Almacena Puntos de función o puntos de casos de uso, Mensaje de

Datos guardados
Históricos tiempo real de desarrollo, costo real confirmación

Finalmente, en la Figura 5.8, aparece el diagrama de subsistemas agrupados por nivel

que incluye todos los paquetes del sistema.

class Logical Model

modelosTabla

a ++ modeloCapacitacion
gui H ModeloHardware

a + Menú a + ModeloSalarios

a + MenuProyecto a + modeloSoftware

a + PanelCalendario
panelesCostos
a + PanelCosto
+ PanelCapacitacion
a + PanetEsfuerzo
+ PanelOtrosGasto
a + PantailaPrincipal
+ PaneIRecursos
S + PruebaAbrirArchivo
+ VentanaProyecto
+ PaneiSalarios

s + modelosTabla

principal
□ + panelesCostos utils
Qj + uti,s a + Double
g + Principal
H + FormatoDec
+ LimitadorNumeros
B
+ MiFileFilter
B
+ OperacionesArchivo
system a
+ AdquisicionHardware
+ AdquiácionSoftware
+ Capacitación
+ CapacitacionyActualizacion
+ Desarrollador
+ Hardware
+ OtrosGastos
+ Proyecto
+ Software
+ TablaLongstreet

Figura 5.8. Diagrama de subsistemas de EcPymes.

Capítulo 6. Comprobación de la metodología

Con el fin de validar los resultados de cálculo de costos obtenidos con la metodología
EcPymes sobre varios sistemas de software, se planearon dos comparaciones distintas:

1. Comparación de la estimación de costos obtenidos de la metodología con el

precio estimado por parte de expertos en desarrollo de Software.

2. Comparación del resultado proporcionado por la metodología con el costo

estimado por PYMES.

En el presente capítulo se plantean los sistemas de software que sirvieron como casos
de estudio, se estima su costo con base en la metodología propuesta y se presentan
los resultados obtenidos en la primera comparación y se comenta la segunda.

6.1. Descripción de los sistemas

Se consideraron cinco sistemas de software, elaborados para empresas Veracruzanas

por estudiantes de la Especialidad en Ingeniería de Software como trabajo final de la
misma y el proyecto detallado en el Apéndice A cuyo costo se estimó en la sección 4.3.

A continuación, en la Tabla 6.1, se detallan brevemente los sistemas que se tomaron

como base para realizar la comprobación de la metodología, la descripción a detalle de
los cinco proyectos se puede apreciar en la sección de apéndices y anexos.
 Nombre del Empresa para la que Ubicación en
Siglas Descripción
proyecto se desarrolla el documento

Empresa ALRO de Sistema de manejo de mercancías

Sistema ALRO de
importaciones, por medio de instrumentos ópticos
Control de ALRO Apéndice A
aduana de la ciudad y manejo de documentos legales
Inventarios
de Ve raer uz propios de la aduana del país

Sistema de
Sistema de control del presupuesto
Control y Municipio de Xalapa,
SICAP que permita su seguimiento y la Anexo A
Administración de Veracruz
obtención de reportes
Presupuesto

Sistema de
Sistema de manejo de reportes y
Control del SEDESOL, programa
SIAOP formatos así como de bases de Anexo B
Archivo de OPORTUNIDADES
datos
Oportunidades

Sistema de Sistema de manejo de personal y

H. Legislatura del
Recursos SIRH expedición de anteojos, así como Anexo C
Estado de Veracruz
Humanos de reportes de personal

Farmacia del Sistema de control de inventario

Sistema de
SIF Magisterio por medio de terminales portátiles Anexo D
Inventario Físico
Veracruzano en todo el territorio veracruzano

6.2. Comparación con la opinión del experto

Para comprobar la efectividad de la metodología, se solicitó el apoyo de dos personas

con experiencia en ¡a estimación de costos de manera tal que, con base en las
características del sistema, indicaran el valor monetario que consideran es adecuado
para elaborar el proyecto.

En la Tabla 6.2, se presentan los cinco proyectos, su costo en bruto estimado por
medio de la metodología y su precio así como los precios estimados por los expertos.
Un reporte detallado de la estimación, proporcionado por el Sistema EcPymes, se
incluye en el Apéndice D.
Nombre del Puntos de Esfuerzo Costo en bruto Precio Precio Precio
Proyecto Función en Horas (CB) EcPymes CB*2+IVA experto 1 experto 2

ALRO 131.67 184.34 $54,820.62 $126,087.42 $245,487.91 $360,332.55

SICAP 155.70 217.98 $62,872.12 $144,605.87 $260,916.14 $391,770.00

SIAOP 265.78 372.09 $109,129.03 $250,996.76 $331,445.18 $625,050.00

SIRH 186.30 260.82 $75,029.38 $172,567.57 $280,752.43 $457,380.00

SIF 154.00 215.60 $49,948.50 $114,881.55 $259,446.79 $386,910.00

Para estimar el precio a partir del costo en bruto, inicialmente se duplicó el valor del
proyecto, con ésto se incluye el pago de impuestos y una ganancia sugerida, además
de que ya incluye el Impuesto al Valor Agregado (IVA, 15%) a la cantidad previamente
obtenida ya que los precios de los expertos sí incluyen IVA.

Los precios que los expertos proporcionaron fueron estimados de acuerdo a Puntos de
Función y otros factores derivados de la experiencia propia (experto 1) y con base en
las estimaciones de costos que se llevan a cabo en proyectos de consultoría de
ingeniería civil y ajustados al software (experto 2).

Como puede observarse en la Tabla 6.2, los precios obtenidos haciendo uso de la
metodología se encuentran por debajo de los precios estimados por los expertos.

6.3. Comparación con estimaciones hechas por PYMES

Así como se solicitó la opinión de personas con experiencia en la estimación de Costos,

también se envió a algunas PYMES, mismas que ya habían colaborado previamente en
el proyecto durante el estudio del Capítulo 3, algunos datos de los sistemas antes
descritos y se solicitó que estimaran un costo con base en sus propias heurísticas.

Lamentablemente no hubo respuesta por parte de ninguna de las PYMES, se les esperó
durante 6 meses y por falta de tiempo ya no fue posible seguir esperando.

Debido a ello esta fase de la comprobación queda abierta para ser un trabajo futuro
por parte de la autora así como de cualquier otra persona interesada en la estimación
de costos y la metodología descrita, sólo es necesario tomar como base de
comparación los costos estimados en la Tabla 6.2.
6.4. Conclusiones de la comprobación de la metodología

Se debe destacar que la metodología es una base teórica para las PYMES que no
cuentan con experiencia práctica, es importante que las empresas tomen como base el
costo y los datos proporcionados por la metodología y lo vayan adaptando para
obtener un costo más aproximado a su realidad y no terminen perdiendo.

El costo bruto que se obtiene a partir de la metodología permite a las empresas contar
con un punto de referencia inicial. A pesar de ser un valor mucho menor al estimado
por los expertos, puede representar un costo mínimo al cual las empresas se pueden
atener con la finalidad de no tener pérdidas.

Cabe destacar que la metodología no considera ni ganancias ni impuestos y la autora

establece un salario para los desarrolladores similar al que se percibe en la región
donde vive (Xalapa, Veracruz), así como los gastos adicionales que pueden llevarse a
cabo en la elaboración de un sistema de software. Por tal motivo, al ajustar la empresa
estos factores, añadir el pago de impuestos y establecer una ganancia a su propio
criterio, hace posible que la metodología aquí planteada se acerque más a las
estimaciones que podría plantear para ellos un experto.

Finalmente, además de la estimación, la otra finalidad de la metodología (el crear una

cultura de registro de estimaciones), se fomenta al proponer el adaptar las variables
de la metodología para propia PYME.

Lamentablemente las PYMES a las que se solicitó cotizaran los casos de estudio no
pudieron enviar los costos por lo que no fue posible elaborar la segunda comparación.

Cabe la pena hacer notar que se buscaron tanto otras PYMES como otros expertos pero
sólo dos contestaron.
Conclusiones

En la parte final de este trabajo se presentan tanto los logros obtenidos como los
pendientes del trabajo así como una revisión crítica del mismo.

La intención de elaborar una forma que permita a pequeñas y medianas empresas

(PYMES) desarrolladoras de Software estimar el costo de sus productos de software,
nace de la propia experiencia de la autora al notar el desconocimiento, tanto propio
como de otros desarrolladores, acerca del valor del trabajo de desarrollo así como del
costo final del producto terminado. Así, surge la preocupación de que, si no es posible
valorar un sistema de software terminado, resulta improbable estimar su costo previo
a su elaboración, dejando al pequeño desarrollador de software en desventaja frente a
grandes empresas en el momento de contender por una licitación.

El objetivo general en este trabajo es brindar ayuda a las PYMES dedicadas al

desarrollo de Software en la tarea de estimar costos para el desarrollo de Software.
Teniendo además los objetivos específicos que se enumeran a continuación.

1. Mostrar las métricas de software y el cálculo de estimaciones más utilizado.

2. Realizar un estudio empírico que recopile información acerca de la manera en

que las empresas desarrolladoras de Software llevan a cabo las estimaciones.

3. Desarrollar un método de estimación de costos, basado en la información

teórica y práctica obtenida, que se adapte a las necesidades de las pequeñas y
medianas empresas mexicanas.

4. Elaborar un componente de Software que estime costos a partir de la métrica

utilizada y sus datos históricos y heurísticos.

Para llevar a cabo la metodología, fue necesario considerar todas las características de
a
las PYMES, entre las cuales destaca la carencia de información. Es por ello, que
propone para la estimación del tamaño del software a elaborar, utilizar dos de las
métricas más comunes: Puntos de Función y Puntos de Casos de Uso; para luego
transformar el tamaño en tiempo de desarrollo con tablas de referencia.
Posteriormente, para obtener un tiempo de desarrollo en días, la empresa debe
repartir el trabajo en horas diarias y entre todos los desarrolladores que trabajarán en
el proyecto. Finalmente, al indicar los salarios y otros gastos del proyecto, se obtendrá
el costo total estimado.
Al unificar todos estos datos en una sola metodología de costos, una PYME podrá
conocer de antemano el costo aproximado de un proyecto a desarrollar, contando con
algunos datos de referencia, haciendo posible llevar a cabo un presupuesto.

La metodología de estimación de costos para el desarrollo de sistemas de software que

se propone considera las características de las pequeñas y medianas empresas al
presentar tablas de referencia con las que una empresa de nueva creación puede
comenzar a trabajar. Además, una vez que la empresa vaya ganando experiencia y
guardando información histórica, puede ir personalizando más el método de acuerdo
con sus necesidades.

El sistema elaborado permite realizar la estimación de costos, con lo cual es posible

reducir el tiempo y pequeños errores que dicho proceso tomaría si se llevara a cabo
manualmente. Siendo, además, un programa sencillo de manejar (como se mostró en
el Capítulo 4), resulta factible que los desarrolladores hagan uso de éste.

Con la metodología que se propone, una PYME o un desarrollador independiente de

Software cuenta con una base sólida con la que puede aproximar el valor del trabajo
que va a llevar a cabo para obtener un software.

Además, el programa elaborado, facilita el proceso de estimación de costos, ya que los

cálculos se llevan de manera automática siendo únicamente trabajo de la empresa
introducir los valores necesarios. Sin embargo, es importante indicar que la persona
que haga uso de dicho programa debe tener conocimiento del procedimiento que lleva
a cabo la metodología con la finalidad de poder llenar los datos de manera correcta.

Cabe resaltar la importancia de conservar datos históricos de cada proyecto elaborado,

tanto de las estimaciones como de los costos finales. Con ello, la empresa tendrá una
cultura de conservación de información la cual a futuro le permitirá contar con una
base de datos sólida que le permita llevar a cabo una estimación de manera más
eficiente.

Al contar con el sistema de software y las tablas de referencia, el uso de la

metodología resulta práctico para las PYMES desarrolladoras de Software ya sean de
nueva creación o que ya tengan algún tiempo en el mercado. Debido a que cuenta con
los elementos suficientes para cubrir con sus necesidades, resulta un procedimiento
útil al momento previo a elaborar un software.
Aunque al comparar la metodología con los precios estimados por los expertos quedó
por debajo, las empresas pueden realizar ajustes para que la metodología se vaya
adaptando a sus características como serían: área económica-geográfica, oferta y
demanda. Como un proyecto a futuro, podría compararse los precios estimados por el
método con precios proporcionados por PYMES o incluso con otros expertos con la
finalidad de contar con un mayor número de puntos de referencia para compararlo.

Además de casos de prueba a corto plazo, es necesario llevar a cabo estudios de casos
a lo largo de un tiempo, es decir, que ya no únicamente incluyan estimaciones
independientes como referencia, sino además los resultados concretos de tiempo y
costo de desarrollo al finalizar el proyecto con la finalidad de comprobar la certeza con
la que la metodología lleva a cabo el procedimiento de estimación de costos.

Una vez que se tengan los resultados de las pruebas de seguimiento, puede comenzar
a depurarse los modificadores planteados por la metodología, añadir nuevos conceptos
e incluso corregir las tablas de referencia con la finalidad de adecuar la misma a las
necesidades de las PYMES.

También podría considerarse el anexar el componente de software a una suite de

sistemas mayor y así trabajar en conjunto durante la fase de especificación y análisis
de requerimientos de un sistema.

Finalmente, es deseo de la autora expresar sus impresiones generales del trabajo

realizado. Puede decirse que la elaboración de una metodología de estimación de
costos para sistemas de software es un proceso complicado y que necesita de mucha
validación y experiencia; que por el lado positivo podrá permitir a desarrolladores de
software que apenas comienzan a trabajar en el área darse una idea del tiempo y
costo de los proyectos además de crearles una cultura de almacenamiento de datos
históricos la cual resulta muy importante para su crecimiento como empresa.
Bibliografía

Armour, P. (2002) Ten Unmyths of Project Estimation. Reconsidering some

commonly accepted project management practices;
Communications of the ACM; Pp. 15 - 18; Noviembre; Vol.
45; No. 11; EEUU.

Armour, P. (2004) Real Work, Necessary Friction, Optional Chaos. Challenges

in estimating software scope by effort.; Communications of
the ACM; Pp. 15 - 18; Junio; Vol. 47; No. 6; EEUU.

Boehm, B. (1981) Software Engineering Economics; Prentice-Hall, Advances

in Computing Science & Technology Series; EEUU.

Clemmons, R (2006) Project Estimation With Use Case Points; CrossTalk, The
Journal of Defense Software Engineering; Febrero; EEUU.

Duran Rubio, S. E. Puntos por Función. Una métrica estándar para establecer
(2003) el tamaño del software; Boletín de Política Informática
Núm. 6, México.

Fenton, N. (2000) Software Metrics: Roadmap; ACM Press; Future of

Software Engineering, Pp. 357 - 370; Irlanda.

Fowler, M. (1999) UML gota a gota; Pearson Educación; Traducido por

González J.; México.

García Pérez de Lema, D. La contabilidad de costos y la rentabilidad en la PYME;

(2006) Universidad Veracruzana, Facultad de Contaduría y
Administración; No. 218; enero - abril; México.

Gates, B. (2007) Entrevista a Bill Gates por Joaquín López-Dóriga; en

http://www.esmastv.com.mx/esmas_tv/smallPlayer.aspx7i
d=7587&idroot=76, Parte 1 de 2; Copyright Televisa, S. A.
de C. V.; 2007; México.
Humphrey, W. S (2003) A Discipline for Software Engineering; Software
Engineering Institute; Addison Wesley; 14° Impresión;
EEUU.

Jalóte, P. (2005) An integrated approach to software engineering; Springer;

3a edición; EEUU.

Jones, C. (1996) Applied Software measurement: assuring productivity and

quality; Me Graw - Hill; 2a Edición; EEUU.

Kemerer, C. F. (1987) An Empirical Validation of Software Cost Estimation

Models; Communications of the ACM; Vol. 30 No. 5, Pp.
416 - 429; EEUU.

Longstreet, D. (2008) Estimating Data; Longstreet Consulting Inc.; disponible en:

http://softwaremetncs.com/Articles/estimatingdata.htm;
EEEUU.

Ribu, K. (2001) Estimating Object-Oriented Software Projects with Use

Cases; Tesis de master. Universidad de Oslo. Disponible
en: http://heim.ifi.uio.no/~kribu/oppgave.pdf

Salas Rico, R. (1981) Análisis de Costos Indirectos; Secretaría de

Comunicaciones y Transportes; México.

Shneiderman, B. (2005) Diseño de interfaces de usuario: estrategias para una

interacción persona-computadora efectiva; Addison
Wesley; 4a edición; EEUU.

Sommerville, I. (2005) Software Engineering; Addison Wesley; 7a edición;

Traducido por Alfonso Galipienso, M. I.; España.

Sumano López, M. Á. Áncora: Análisis de requerimientos de software conducente

(2007) al reuso de artefactos; 1° ed.; colección Textos
Universitarios; Universidad Veracruzana; México.
 Apéndices
Apéndice A. Sistema ALRO de control de inventarios

Apéndice B. Manual de Operación

Apéndice C. Pruebas de usabilidad

Apéndice D. Reportes detallados de Estimación

Apéndice E. Formatos de Entrevistas y Encuestas

 Apéndice A. Sistema ALRO de control de inventarios
La empresa ALRO, la cual se dedica a la importación de juguetes al territorio nacional a
través de la aduana de la ciudad de Veracruz, actualmente no cuenta con ningún
sistema de información que les apoye en el proceso de recepción de mercancía, y el
proceso que sigue es el siguiente:

1. La mercancía es enviada por un proveedor y descargada en la aduana.

2. La persona responsable de la empresa debe que revisar que la mercancía

recibida coincida con lo especificado por su proveedor.

3. En un formato denominado ficha, se captura la información de recepción. El

formato contiene la información siguiente:

a) Núm. de orden. b) Piezas por caja.

c) Núm. de producto. d) Total de piezas.

e) Descripción. f) Total de peso por caja.

g) Descripción para aviso sanitario. h) Proveedor.

i) Descripción de factura. j) Valor unitario.

k) Material. I) Total de factura.

m) Mecanismo. n) Aviso sanitario.

o) Modelo. p) País de origen.

q) Marca. r) Fracción arancelaría.

s) Peso unitario. t) Edad.

u) Cajas. v) Pilas.

Además de su encabezado con los datos del cliente, fecha, folio y proveedores de la
mercancía.

4. Con la información recolectada se generan los siguiente informes:

 a) Informe de ficha corta. Empleado para control interno ya que sólo contiene
el mismo encabezado de la ficha pero sus campos son únicamente descripción,
Núm. de orden, fracción arancelaria, proveedor, país de origen, aviso
sanitario, norma, precio estimado, padrón sectorial, unidad de
comercialización, total de piezas, total de .peso y valor total.

b) La ficha corta se envía a un agente aduanal para que realice los trámites
pertinentes y la mercancía pueda ser retirada del recinto aduanal.

c) Informe de Anexo XVIII. Éste es un reporte dirigido a las autoridades

aduanales en el cual se reporta el tipo de mercancía, material, uso, modelo,
representación, características de construcción, características adicionales,
armado, presentación, funcionamiento, motor, escala y marca de cada uno de
los productos.

d) Informe de Etiquetado por display1. Aquí se explica que existen ciertas

mercancías que a su vez contienen cajas de productos y contiene el Núm. de
producto, descripción, el tipo de presentación y las piezas contenidas.

e) Etiquetas. La generación de las mismas se usa para identificar las cajas

previamente verificadas. Cada etiqueta contiene: Núm. de producto,
descripción, material, mecanismo, importador, advertencia, precaución,
cantidad, país de origen y pilas.

5. Generados los reportes anteriores se procede a elaborar la factura para cada

cliente. La factura contiene: datos del cliente, cantidad de producto, Núm. de
producto, descripción, costo unitario y costo total.

6. Una vez realizados estos procesos, la mercancía es enviada al cliente

correspondiente.

Actualmente todo el proceso del llenado de la ficha e impresión de ios informes, es

mantenido en una hoja de cálculo en Microsoft Office Excel ®. Este proceso posibilita
cometer una gran cantidad de errores, además de ser laborioso, tardado y repetitivo.

1 Quiere decir etiquetado por despliegue, pero se menciona en inglés debido a que así lo maneja la empresa.
Descripción de la situación actual

A continuación se presenta el guión en Áncora de la situación actual, referente al

proceso de recepción, llenado de documentos y entrega de mercancías; dividido en dos
pistas: la primera, en la Figura ApA.l, corresponde a la recepción de los productos,
registro de los mismos y la elaboración de los documentos para legalizar el ingreso al
país.

Guión Esceria 1. Verificar Mercancías

Sistema Arlo RES ecibe ME en la Aduana
RES \aerifica que ME coincida con la información
Pista del p roveedor
X
Recepción y revisión de X
Juguetes ** x X
¿Son incorrectos los datos?

Papeles RES corrige ME

RES: Responsable de la RES habla con proveedor
Empresa
AAD: Agente Aduanal Escerta 2. Creación de documentos
AUA: Autoridades RES zaptura toda la información en FI
aduanales RES ilabora FC con algunos de los datos de FI
RES invía FC a AAD
Utensilios AAD verifica FC
X
ME: Datos de mercancía X
FI: Ficha " ¿No está completo?
FC: Ficha Corta X
AX: Documento Anexo AAD corrige ME
XVIII
Escerta 3. Trámite de importación
Condiciones de entrada AAD envía AX a AUA
PRV envía ME a la aduana AUA verifican AX
de Veracruz AUA verifican FC
X
*** ¿AX y FC no están completas?
X
Condiciones de salida X
X
RES libera ME X.
AUA no completa tramite
RES almacena Mercancía

Escena 4. Liberación de mercancía

AUA aprueba ME
AAD notifica a RES que ME esta aprobado

Figura ApA.l. Guión de la Situación actual, primera pista.

En esta primera pista se presenta la recepción de mercancías enviadas por el
proveedor a la responsable de la empresa importadora, quien elabora los documentos
necesarios para su importación legal en el país y luego envía éstos a las autoridades
aduanales para ser aprobados. Con ello es posible ingresar las mercancías en la
bodega. La segunda pista, que aparece en la Figura ApA.2, se refiere a la liberación de
los productos y su entrega al transportista con el fin de que lo haga llegar a los
clientes.
 Guión Escena 1. Generación de etiquetas
Sistema Arlo RES envia FC a SEC
SEC recibe FC
Pista SEC extrae información de ME a partir de FC
Liberación de Juguetes SEC genera ET
SEC envía ET a RES
Papeles
RES; Responsable de la Escena 2. Creación de Reporte
empresa SEC crea ED basadas en FC
SEC; Secretaria de la SEC envía ED a RES
empresa
Escena 3. Salida de mercancía
Utensilios RES recibe ET y ED
ME: Mercancía RES imprime ET y ED
ED: Reporte de etiquetado RES pega ET a ME
por Display RES elabora FA para los Clientes
ET: Etiquetas
FC: Ficha corta
FA: Factura

Condiciones de entrada
AAD genera ED

Condiciones de salida
RES envía ME a los
Clientes

Figura ApA.2. Guión de la Situación actual, segunda pista.

Propuesta computacional

Debido a la situación actual, en la que el manejo de los productos se lleva casi manual,
se propuso elaborar un sistema de control de ingresos que incluya los siguientes
requisitos:

1. El sistema deberá permitir el ingreso de una clave, preferentemente un código

de barras, con la cual se identifique el producto.

a) Deberá incluir un espacio para ingresar el número de cajas y productos que

ingresan.

2. Deberá permitir la elaboración de reportes como:

a) Ficha.

b) Ficha Corta.

c) Etiquetado.

d) Factura.

e) Documentos legales para el ingreso de mercancías.

3. Será necesario que el sistema cuente con una serie de catálogos en los que se
incluyan datos referentes a:
 a) Producto.

b) Clientes.

c) Proveedores.

d) Características del producto en general.

Esto con el fin de facilitar la captura de las características de los productos que la
aduana de México solicita.

4. Como requerimiento adicional, se desea incluir la extensión del sistema base a

un dispositivo móvil para facilitar la captura de las cantidades de los
productos.

A continuación se presenta el guión en Áncora de la propuesta computacional, pistas

para el sistema móvil, que permitirá el registro de la mercancía recibida, en la Figura
ApA.3 que se presenta a continuación.

Guión Escena 1: Registro de Datos

Sistema Aduanal USR captura^CB

Pista " ¿No existe ME?

Sistema Móvil
USR da de alta información en SC
Papeles
USR: Usuario USR solicita información de ME
SC: Sistema Central USR coteja información de ME

Utensilios ** ¿No es correcta la información?

ME: Mercancías **
CB: Código de Barras USR verifica CB
NC: Número de cajas
NP: Número de Piezas USR introduce NC y NP

Condiciones de Entrada Escena 2: Sincronizar Información

USR recibe ME USR realiza sincronización con SC

Condiciones de Salida
USR termina de capturar
ME

Figura ApA.3. Guión del Sistema Móvil.

El sistema base, cuyo guión en Áncora aparece en la Figura ApA.4, permitirá llevar el
control automatizado de las mercancías, aún cuando no se cuente con el sistema
móvil. Llevará a cabo las impresiones de los documentos requeridos para la
importación de mercancías y mantendrá catálogos de los datos.
 Guión Escena 1: Acceso al Sistema
Sistema Aduanal USR introduce login y password
X
X
Pista ** X ¿No existe USR?
X
Sistema Central X
X
USR recibe mensaje de error
Papeles Volver a escena 1
USR: Usuario
AAD: Agente Aduanal Escena 2: Creación de Ficha
ADM: Administrador USR crea nueva FI
SIC: Sistema Central SIC genera FI
USR captura información de producto en FI
Utensilios
FI: Ficha Escena 3: Generación de Ficha corta
FC: Ficha Corta USR solicita FC
AX: Anexo XVIII SIC genera FC
ET: Etiqueta USR envia FC a AAD
ED: Etiqueta por Display
FA: Factura Escena 4: Generación de Etiquetas
CU: Catálogo Usuarios USR solicita ED y ET
CC: Catálogo Clientes USR imprime ED y ET
CP: Catálogo Proveedores
CD: Catálogo Productos Escena 5: Generación de Factura
CM: Catálogo Mecanismos USR solicita FA
CA: Catálogo Materiales SIC genera FA
CR: Catálogo Presentación USR imprime FA
CL: Catálogo Pilas
CF: Catáloqo Fracción Escena 6: Generación de Anexo XVIII
Arancelaria USR solicita AX
UM: Catáloqo Unidad de SIC genera AX
Comercialización
CS: Catáloqo Aviso Escena 7: Catálogos
Sanitario ADM actualiza CU
ADM actualiza CC
Condiciones de entrada ADM actualiza CP
USR tiene información de ADM actualiza CD
mercancía ADM actualiza CM
ADM actualiza CA
Condiciones de Salida ADM actualiza CR
CA actualizado ADM actualiza CL
ADM actualiza CF
ADM actualiz.a UM
ADM actualiza CS

Figura ApA.4. Guión del Sistema Central.

Se aprecia que la actualización de los catálogos es simple y sencillamente altas, bajas
y cambios de la base de datos.

Modelo de Datos

Con el fin de tener una mayor comprensión del problema, además de los guiones del
sistema, se desarrolló un modelo Entidad Relación. Donde los utensilios detectados en
la parte de las Redes Semánticas Naturales (RSN) se plasman como una entidad y sus
respectivas relaciones entre ellas.

Las entidades más importantes son las de Producto y Ficha. El primero, incluye todos
los datos requeridos por las autoridades aduanales para describir los juguetes que la
compañía desea ingresar al país; y el segundo, se refiere a los datos de clientes,
proveedores, del producto mismo, entre otros que complementan la información
requerida. El modelo de Datos expresado en el modelo Entidad Relación se presenta a
continuación en la Figura ApA.5.

j'ñcííá' ■' '

i robo
Pilas (FK)
í ^Presentación (FK).

; Fracción arancelarla (FK) Rroductb_____ ;_____ ,1Mil | y/M.CocMrcíábzácjon__ ¿7

i¡| Ü U/M Comerciaüación
i T Avisó sanitario (FK) 1 Item
4 Unidad
■ Material (FK¡ t Proveedor. (FK)
j 4 Proveedor (FK) Ij Material (FK) ;t/i]j
i íf Producto (FK) i Reí Olí
Aviso sanitario (FK)
í t Otente (FK) ? Fracción arancelaria (FK) id Fracción arancelaria
í Ü id U/M Cómerdafczacfon (FK)
J
Presentación (FK) [Rd'oa Mi 4 Norma
i mecanismo (FK) ¿ í Pilas (FK) JT 4 Predo estimado
i -i Caía numero W U/M Comercialización (FK) ít‘dJ'1 4 Anexos
i 4 No. factura ’í mecanismo (FK)________ O Padrón
! '■> Fecha O Descripción
4 No. control <J Descripción 2 A'(!?SLÍÍE!ÍL?.'2_ ¿j
& No. orden 4 Descripción 3 [Mí! [Rd'ÓTj id Aviso sanitario
O Pasa' 4 Modelo itriji O Proveedor
4 Observaciones <r Márca 14 Item
O Selección 4 Peso unitario 4 Pah de origen
4 Cajas' Q Valor unitario O Vigencia
4 Pzas por caja O País de origen iMn
4 Total de piezas O Precio estimado
—[íteíw
o Total de peso caja 4 Edad Ri^ 'il IProveedor
4 Total factura 4 Cuota
-------- —O Proveedor
.1 j[i, íjr 4 Cuota valor
4Domtoho
ReLIO 4 Tax ID number

] [Mñ
ipüeT ’v
R) Id P*á7
SCfente ' •*
ifldaeñte p> Pila
in Nombre ¡4 voltios
,4 DormcSo 4 T«o
O RFC

Figura ApA.5. Diagrama Entidad Relación.

La idea de crear una entidad llamada ficha, es para permitir que coincida con el llenado
original de datos, facilitando esta acción al usuario. Todas estas entidades, realmente
presentan catálogos, los cuales se planea llenar previo a la entrega del sistema y dejar
la opción al usuario para agregar más datos a los catálogos, modificar los datos
existentes y eliminarlos si ya no se necesitan.

Planeación del sistema

Una vez definido el Guión de la Propuesta Computacional, se procedió a calcular el

tiempo necesario para crear todas las funcionalidades que se incluirían en el sistema y
describir las mismas en la Bitácora de Desarrollo, la cual aparece en la Tablas ApA.l y
ApA.2.
 Tabla ApA.l Bitácora de Desarrollo, primera parte.

Tiempo
Requerimientos
Forma de Comprobación Estimado
(Quinteta)
(horas)

USR captura CB El usuario ingresa el código de barras por medio de lector 6

óptico

USR solicita información El sistema despliega información de Mercancía en pantalla 10

de ME

USR coteja información El usuario verifica que la información desplegada en pantalla 4

de ME sea la correcta

USR introduce NC y NP El usuario introduce la cantidad de cajas y piezas por medio de 10

teclado

USR realiza Una vez terminado el registro el usuario sincroniza la PDA con 8
sincronización con SC el sistema central en la PC

USR introduce login y El usuario introduce su cuenta por medio de teclado para 6
password ingresar al sistema en la PC

USR crea nueva FI El usuario solicita al sistema por medio del mouse crear una 10
Ficha nueva en base a la información recientemente obtenida

SIC genera FI El sistema despliega en pantalla la ventana correspondiente de 4

la Ficha

USR captura información El usuario agrega los campos faltantes del producto en la Ficha 4
de producto en FI creada por medio del teclado

USR solicita FC Una vez llenados los datos, el usuario selecciona por medio del 4
mouse la opción para crear la Ficha Corta

SIC genera FC Con todos los datos necesarios el sistema presenta en pantalla 4
la Ficha Corta para su guardado o impresión

USR envía FC a AAD Ya sea por correo o en formato impreso el usuario envía la
Ficha Corta al Agente Aduanal para validación

USR solicita ED y ET Dependiendo del tipo de presentación el usuario solicita al 8

sistema por medio del mouse la elaboración de Etiquetado por
Display o Etiquetado normal

USR imprime ED y ET El usuario envía la orden por medio de mouse a la impresora 4

de realizar la impresión de las etiquetas que aparecen en
pantalla

USR solicita FA El usuario selecciona por medio del mouse la opción para 10
elaborar la Factura referente a la Ficha Corta creada
anteriormente
 Tabla ApA.2 Bitácora de desarrollo, segunda parte.

Tiempo
Requerimientos
Forma de Comprobación . Estimado
(Quinteta)
(horas)

SIC genera FA El sistema presenta en pantalla la Factura correspondiente 4

Una vez elaborada el usuario envía la orden por medio de) mouse de
USR imprime FA 4
imprimir la Factura

El usuario selecciona la opción por medio del mouse para elaborar el

USR solicita AX 10
Anexo XVIII

SIC genera AX El sistema presenta en pantalla el documento de Anexo XVIII 4

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CU 6
modificaciones) al catálogo usuarios por medio de teclado al sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CC 6
modificaciones) al catálogo clientes por medio de teclado al sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CP modificaciones) al catálogo proveedores por medio de teclado al 6
sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CD modificaciones) al catálogo productos por medio de teclado al 6
sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CM modificaciones) al catálogo mecanismos por medio de teclado al 6
sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CA modificaciones) al catálogo materiales por medio de teclado al 6
sistema

El usuario administrador realiza modificaciones. (altas, bajas o

ADM actualiza CR modificaciones) al catálogo presentación por medio de teclado al 6
sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CL 6
modificaciones) al catálogo pilas por medio de teclado al sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CF modificaciones) al catálogo fracción arancelaria por medio de 6
teclado al sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza UM modificaciones) al catálogo unidad de comercialización por medio de 6
teclado al sistema

El usuario administrador realiza modificaciones (altas, bajas o

ADM actualiza CS modificaciones) al catálogo aviso sanitario por medio de teclado al 6
sistema
Modelo de casos de uso

El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un

caso de uso representa una unidad discreta de interacción entre un usuario (humano o
máquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo significativo.

Cada caso de uso tiene una descripción que narra la funcionalidad que se construirá en
el sistema propuesto. Un caso de uso puede "incluir" la funcionalidad de otro caso de
uso o "extender" a otro caso de uso con su propio comportamiento.

En la Figura ApA.6 se presenta el diagrama general de Casos de Uso que incluye los
requerimientos funcionales del sistema.

Figura ApA.6. Diagramas de Casos de Uso, Sistema Base.

Puede observarse que el usuario regular puede realizar todas las operaciones excepto
la actualización de catálogos que sólo puede llevar a cabo el administrador del sistema,
quien además también puede realizar el resto de las acciones.

En la Figura ApA.7, se presenta el diagrama de Casos de Uso del sistema móvil. El

actor ALRO representa al sistema base que se sincroniza con el sistema móvil cuando
el usuario lo solicita.

Figura ApA.7. Diagrama General de Casos de Uso, Sistema Móvil.

 Apéndice B. Manual de Operación

A continuación se detalla el procedimiento para utilizar el componente de Software

EcPymes, así como las características que debe tener un equipo de cómputo para que
pueda ejecutarse.

Estimación del Esfuerzo

En un primer paso, deberá ejecutarse el archivo EcPymes.jar, el cual se encargará de
abrir la pantalla principal que se muestra en la Figura ApB.l.

Figura ApB.l. Pantalla Principal del Componente.

Esta es la pantalla principal del programa desde la cual se puede acceder a una de las
dos opciones para estimar el esfuerzo: Puntos de Función o Puntos de Casos de Uso
como se aprecia en la Figura ApB.2, donde se observa también la opción Abrir
Proyecto, la cual permite cargar una estimación previamente guardada, además de la
opción Históricos donde puede elaborarse un resumen de los mismos.

1 r hífEiUSF'' ¿
■ Archivo i Ayuda

Puntos de Función
Abrir Proyecto Casos de Uso
Historíeos

Figura ApB.2. Selección de métrica a utilizar.

Si se elige la opción Puntos de Función el programa lo llevará a una pantalla como la
que aparece en la Figura ApB.3. Donde al introducir la cantidad de Puntos de Función
correspondientes al sistema que se va a estimar se obtiene un esfuerzo obtenido a
partir de la Tabla 2.19. Incremento del costo por Punto de Función.
 Figura ApB.3. Opción Puntos de Función.
Para el llenado de los datos en el caso de Puntos de Función, se introduce en la
primera celda el valor del proyecto en dicha medida, posteriormente se debe dar click
en el botón "Calcular", por medio del cual el sistema aplicará el valor correspondiente a
la Tabla de Longstreet.

Si se desea, también es posible ajustar el esfuerzo en las siguientes celdas aplicando

un incremento o decremento en horas o inclusive la duración de un proyecto terminado
semejante al que se está realizando.

Posteriormente se da click en el botón "Calcular Ajuste" y con ello aparecerá la pestaña

"Calendario" que permitirá llevar a cabo dicha estimación (Ver Figura ApB,4).

El programa enviará automáticamente el esfuerzo estimado a la pestaña "Calendario"

para su aplicación en el siguiente paso.
 Figura ApB.4. Estimación del Esfuerzo por medio de Puntos de Función
En caso de no ingresar datos al ajuste, éste se considerará como cero y de todas
maneras se abrirá la pantalla de "Calendario".

Resultando similar para el llenado de Puntos de Casos de Uso, como se puede apreciar
en la Figura ApB.5. En este caso en lugar de añadir el valor de tablas, el usuario debe
ingresar el Factor de Productividad (Horas por Punto de Caso de Uso) del que se hace
referencia en el Capítulo 2.4.2 y de la misma forma que con Puntos de Función,
estimar el esfuerzo. De manera análoga, el esfuerzo será enviado a la pestaña
"Calendario" para su uso posterior.
 Figura ApB.5. Estimación del Esfuerzo por Puntos de Casos de Uso.

Estimación del Calendario

Una vez que ha sido estimado el Esfuerzo y la pestaña "Calendario" aparezca junto a la
de esfuerzo, se puede proceder a llenar los datos como se observa en la Figura ApB.6.
 Figura ApB.6. Obtención de Calendario.
Los primeros cuatro datos son calculados de manera automática por el programa una
vez que el usuario introduzca la cantidad de desarrolladores y el tiempo, diario y total,
que trabajarán en el proyecto y de click en el botón "Calcular".

Cabe destacar que la suma de las horas totales de los desarrolladores, a excepción del
líder, así como el tiempo diario de trabajo son las que permiten saber el tiempo total
en días de desarrollo.

Es importante aclarar que aunque en la empresa exista un desarrollador que realice

dos actividades distintas, como por ejemplo análisis y diseño, para efectos de la
estimación, es necesario separar dichas actividades. Para el caso del líder, aunque se
incluye en el calendario, solo se le considera en efectos de costos, no de tiempos, por
lo tanto si el líder realiza alguna actividad, esta deberá registrarse de manera
separada.

Si el cliente para el cual se esta elaborando el proyecto, indica alguna restricción con
respecto al tiempo, ésta puede introducirse en el campo destinado para ello y de esta
manera el sistema dará también un valor de tiempo estimado diario en horas que
puede tomar en cuenta la empresa para trabajar.
Una vez que se ha estimado el Calendario y se da click en el botón "Calcular" aparece
la pestaña "Costos" por lo que se puede proceder a obtener los mismos.

Estimación de Costos
Ya que se ha establecido un Calendario, se debe proceder a estimar el costo del
proyecto, comenzando por el salario que se pagará a cada desarrollador, como se
puede ver en la Figura ApB.7.

Figura ApB.7. Estimación de salarios de los desarrolladores.

Para introducir los salarios de cada uno se debe posicionar en el espacio
correspondiente, oprimir la tecla F2 e indicar el valor monetario del salario,
posteriormente se da un Enter para continuar. La suma de los salarios aparecerá
automáticamente en la celda inferior.

El salario para cada desarrollador deberá establecerse a criterio de la empresa, así

como las horas extra a trabajar y el costo de las mismas.

Una vez que se tienen todos los salarios, al hacer click en el botón Actualizar, se unirá
al total del costo estimado de desarrollo.
De la misma manera, para ingresar el costo por capacitación, en la pestaña con el
mismo nombre, se da click en el botón Añade y se introducen los valores como se
observa en la Figura ApB.8.

Figura ApB.8. Costos por capacitación.

De la misma manera que en los salarios, se oprime la tecla F2 y se borran las letras o
números para introducir los nuevos datos. El valor de viáticos y capacitaciones es por
desarrollador; en el caso de tratarse de dos personas, se debe dar el costo unitario si
fuera el mismo o separar los costos si éstos resultaran diferentes.

Cabe señalar que en el cuadro Proy/Cap la empresa puede prorratear el costo de la

capacitación con los proyectos que considere.

Si se desea quitar o borrar una capacitación, el usuario debe colocarse en la

capacitación que desea suprimir y dar click en el botón Eliminar, con lo cual se quitará
de la estimación la capacitación seleccionada. Si ésta ya había sido incluida en el total,
bastará con volver a actualizar el costo para quitar dicho valor.

Posteriormente, para añadir esta cantidad al costo total estimado, se da click en el

botón Actualizar.
Para agregar el costo de los Recursos de Hardware y Software se lleva a cabo el mismo
procedimiento que en las capacitaciones: se da click en el botón añade Hardware o
Añade Software y se ingresan los datos colocando el cursor en la celda deseada,
oprimiendo la tecla F2 y borrando el contenido existente para ingresar el nuevo, como
se observa en la Figura ApB.9 a continuación.

Archivo Ayuda

Figura ApB.9. Costo por adquisición de Hardware y Software.

Al igual que en las capacitaciones si se desea eliminar un elemento de Hardware o de
Software adquiridos se da click en el botón eliminar y luego en el de actualizar.

Finalmente, para agregar otros gastos al costo total del proyecto, en la pestaña
correspondiente se ingresa los valores indicados como pueden ser costo por asesorías
para el proyecto; el costo de outsourcing, si es que se requirió para el mismo; el costo
de papelería y consumibles (tintas, tonners) que se estima se utilizarán por proyecto y
gastos varios correspondientes a la ubicación física de la empresa, como pueden ser
agua, renta de local, de teléfono, de Internet (los cuales se consideran mensuales) y
luz (bimestral). Señalando el número de proyectos, junto con el que se esta
evaluando, que durante el mes o el bimestre se llevarán a cabo; así como el número
de meses de trabajo que tomará elaborar el proyecto (este valor puede tomarse de la
pestaña Calendario) finalmente es necesario ingresar los gastos que se incluirán en el
proyecto y el programa irá calculando automáticamente los gastos totales como se
observa en la Figura ApB.10. Cabe señalar que si un valor se omite, se considerará
como cero. Por otra parte si se desea eliminar o cambiar algún gasto, éste se borra o
modifica y posteriormente se da click una vez más en actualizar.

> Archivo Ayuda

Figura ApB.10. Otros gastos.

Finalmente, para añadir dichos gastos al costo total estimado, se da click en el botón
Actualizar.

Requerimientos del Sistema

Procesador a 1.6 GHZ o superior.

Maquina virtual de java 1.4 o superior.

Mínimo 256 MB de memoria RAM.

Mínimo 1 MB de espacio libre en Disco Duro.

 Apéndice C. Pruebas de usabilidad
Como parte complementaria a las pruebas que se realizaron a la metodología, también
se llevaron a cabo pruebas a la facilidad con que una persona puede emplear el
sistema EcPymes.

La encuesta, elaborada por la Universidad de Maryland, EEUU, tomado de

[Shneiderman, B. (2005)], se aplicó a estudiantes de 4o, 5o y 6o semestres de la
materia de Administración de Proyectos de la Licenciatura en Informática de la
Universidad Veracruzana.

A continuación se describen los tópicos empleados en el cuestionario, cabe destacar

que ha sido reducido para adaptarlo a las características del sistema EcPymes. Se
tomaron en cuenta cinco niveles para que los usuarios expresaran su opinión sobre las
características de interfaz del sistema. El cuestionario completo se encuentra en el
compendio de entrevistas y encuestas del Apéndice E.

Descripción del cuestionario

Inicialmente se estudió el impacto que hace el sistema hacia el usuario englobado en el

apartado Reacciones globales de! usuario. Donde se pide al mismo, en una serie de
seis preguntas, que indique su impresión general sobre el sistema.

El siguiente conjunto de preguntas se refiere a las características de las Ventanas, que

incluye cuatro preguntas en la sección del mismo nombre donde se revisan los
elementos incluidos en la interfaz del sistema y la opinión que el usuario tiene de ellos.

Posteriormente se elabora una serie de seis preguntas sobre los términos utilizados en
el sistema en la sección Terminología, donde el usuario debe plasmar su opinión sobre
la facilidad o dificultad para comprender instrucciones, mensajes, entre otros.

En la sección Aprendizaje, los usuarios del sistema indican la facilidad o dificultad que
tienen al manejar el sistema conforme va pasando el tiempo. Para ello se realizan
cinco preguntas.

La velocidad, fiabilidad y manejo de errores se miden en la sección Capacidades del

sistema, donde el usuario selecciona la opción más representativa con respecto a
dichos términos en una serie de cinco preguntas.
En la sección Ayuda en línea, el usuario responde tres preguntas acerca de la utilidad
en general que percibió de la misma.

Por último en la sección sobre la Instalación de! software, se realizan tres preguntas
sobre la facilidad o dificultad que tiene el usuario para la misma.

Resultados de la encuesta

Una vez aplicada la encuesta a veintidós estudiantes, se procedió a reunir todos los
resultados e interpretarlos. En la Tabla ApC.l (desde la a hasta la g) se presenta el
valor numérico que tuvo la mayor frecuencia por cada pregunta y su interpretación.
Cabe aclarar que si en alguna respuesta el número de incidencias es el mismo o muy
cercano se indicarán ambas.

Tabla ApC.l (a). Resultados de la encuesta de Usabilidad (Reacciones globales del

usuario).

Pregunta Valor Significado

1.1 3,4 Quiere decir que el sistema destaca de medio a alto nivel de relevancia.

El manejo del sistema resulta suficientemente satisfactorio de acuerdo a los resultados

1.2 4
que proporciona.

1.3 4 El manejo del sistema resulta estimulante para el usuario.

1.4 5 Es sistema es muy fácil de utilizar.

1.5 3 El sistema cuenta con una potencia de nivel medio.

1.6 4 El sistema resulta lo suficientemente flexible.

Tabla ApC.l (b). Resultados de la encuesta de Usabilidad (Ventanas).

Pregunta Valor Significado

2.1 5 Los caracteres en la pantalla resultan fáciles de leer para el usuario.

Los elementos resaltados en las pestañas del sistema resultan de utilidad para el manejo
2.2 5
del mismo.

La composición de la pantalla resulta la adecuada, aunque cabe destacar que el siguiente

2.3 4, 3 valor que fue muy cercano fue un tres lo cual indica mas bien que es medianamente
adecuada.

La secuencia de las pantallas durante el manejo del sistema va de evidente a muy

2.4 5,4
evidente.
 Tabla ApC.l (c). ©Resultados de la encuesta de Usabilidad (Terminología).

Pregunta Valor Significado

3.1 5 El uso de términos a lo largo del desarrollo del sistema es el mismo.

Los términos empleados siempre o casi siempre se relacionan con los utilizados en el
3.2 5,4
trabajo que el sistema realiza.

Las instrucciones que aparecen en pantalla son medianamente consistentes con lo que el
3.3 3
usuario debe realizar.

Los errores y funciones en pantalla son medianamente evidentes, dado que el sistema no
3.4 4,3
permite que se introduzcan valores que no correspondan al tipo de variable.

El sistema mantiene al usuario informado casi todo lo que esta haciendo ya que cabe
3.5 4
destacar que las operaciones son sencillas y rápidas de efectuar.

3.6 4,3 Los mensajes de error son de mediana utilidad.

Tabla ApC.l (d). Resultados de la encuesta de Usabilidad (Aprendizaje).

Pregunta Valor Significado

4.1 4 El aprender a cómo utilizar la herramienta resultó sencillo.

4.2 4,3 El realizar actividades un poco más complejas resulto medianamente sencillo.

El descubrir nuevas características mediante la prueba y error resultó alentador para los
4.3 4
usuarios.

4.4 4, 3 El recordar los nombres y utilizarlos resultó medianamente fácil.

4.5 3 Las tareas pueden realizarse de una manera medianamente directa.

Tabla ApC.l (e). Resultados de la encuesta de Usabilidad (Capacidades del Sistema).

Pregunta Valor Significado

5.1 5 El sistema trabaja muy rápido.

5.2 4 El sistema es fiable en la mayoría de las ocasiones.

5.3 3 La falta de sonidos de alerta por parte del sistema tuvo una aceptación media.

5.4 3 La recuperación de errores por parte del sistema es de un nivel intermedio.

5.5 5 El uso del sistema resulta mucho más fácil conforme el usuario va ganando experiencia.
 Tabla ApC.l (f). Resultados de la encuesta de Usabilidad (Ayuda en línea).

Pregunta Valor Significado

6.1 1 La ayuda que proporciona el sistema resulta muy confusa.

6.2 3, 1 La información que brinda el manual de usuario pocas veces resulta comprensible.

6.3 3, 2,1 La cantidad de ayuda ofrecida va de inadecuada a medianamente adecuada.

Tabla ApC.l (g). Resultados de la encuesta de Usabilidad (Instalación del Software).

Pregunta Valor Significado

La instalación es muy rápida dado que solamente es necesario copiar un archivo al

7.1 5
momento de instalar el sistema.

Aunque no se informa del proceso de instalación debido a que solamente es copiar un

7.2 5 archivo, la velocidad del proceso de copiado si se informa por parte del sistema
operativo.

Como no se instala ningún archivo, si ocurren fallos en la copia del programa, el sistema
7.3 4
operativo informa al usuario acerca de los mismos.

Conclusiones

La realización de las pruebas de usabilidad resultaron muy útiles en la depuración de

errores del sistema, así como en el mejoramiento de algunas de sus características
como son las siguientes:

1. Se incluyó un número mayor de mensajes que brindaran información al

usuario acerca de las actividades que estaba realizando el sistema.

2. Se mejoró la calidad de las instrucciones para así hacer más evidente al

usuario lo que debía hacer.

3. Se incrementó la cantidad y mejoró la calidad de información del manual de

operación.

4. Se controló aún más el tipo de variables que pueden introducirse en el sistema

y los lugares donde deben ingresarse.
Apéndice D. Reportes detallados de
Estimación
■ma a ■ ■ Z
ALRO.ecp
1. Estimación del Esfuerzo en Puntos de Función
Total de puntos de función: 131.67
Valor de referencia de tabla: 1.40
Horas/persona según Longstreet: 184.34
Duración en minutos: 0.00

2. Ajustes al esfuerzo
Esfuerzo estimado: 184.34
Incremento al esfuerzo: 0.00
Decremento al esfuerzo: 0.00
Tiempo de duración de proyecto similar: 0.00
Esfuerzo ajustado: 184.34

3. Planteamiento del Calendario

Horas/Persona: 184.34
Desarrolladores Totales: 4.00
Horas acumuladas diarias: 16.00
Días totales a laborar: 11.52

4. Restricciones de Tiempo
Tiempo definido por el cliente:0.00
Días Laborales: 5.00

5. Costo total del proyecto

Suma de costos del proyecto: 54820.62

5.1 Salarios

Condiciones salariales del personal

Tipo Cantidad Sueldo Horas Horas Horas Costo Sueldo Sueldo Suma de
por hora Diarias Totales Extras hora diario total por sueldos
totales extra por persona
persona
Admon. 1.00 156.25 8.00 184.34 0.00 0.00 1250.00 28803.1 28803.1
del 2 2
Proyecto
Requerí 1.00 125.00 4.00 9.22 0.00 0.00 500.00 1152.50 1152.50
mientos
Análisis 1.00 125.00 4.00 36.87 0.00 0.00 500.00 4608.75 4608.75
y diseño
General
Construc 1.00 125.00 4.00 119.82 0.00 0.00 500.00 14977.5 14977.5
cion 0 0
Instrucci 1.00 125.00 4.00 18.43 0.00 0.00 500.00 2303.75 2303.75
on y
Capacita
cion al
Usuario

Sueldo total de personal: 51845.62

5.2 Capacitación

Capacitación y Actualización de pensonal

Nombre Desarrollad Costo Viáticos Proy/Cap Total
ores
Total costo de capacitación:
5.3 Recursos

Adquisición de Hardware nuevo para el proyecto

Nombre Costo Proyecto a utilizar Total
PDA 1500.00 1 1500.00
Total Hardware: 1500.00

Adquisición de Software nuevo para el proyecto

Nombre Costo Provecto a utilizar Total
Total Software: 0.00
5.4 Otros
Costo total de otros gastos: 475.00
Asesoría (costo): 0.00
Outsourcing (costo): 0.00
Papelería (costo): 500.00 ■
Costo total de otros gastos: 500.00
Proyecto por mes: 1.00
Meses de trabajo: 0.38
Luz
Costo bimestral: 300.00
Proyectos por bimestre: 1.00
Bimestres de trabajo: 0.19
Costo por proyecto: 57.00
Agua
Costo mensual: 100.00
Costo por proyecto: 38.00
Renta del local
Costo mensual: 0.00
Costo por proyecto: 0.00
Renta del telefono
Costo mensual: 500.00
Costo por proyecto: 190.00
Renta de Internet
Costo mensual: 500.00
Costo por proyecto: 190.00
Renta de hardware
Costo mensual: 0.00
Costo por proyecto: 0.00
SICAP.ecp
1. Estimación del Esfuerzo en Puntos de Función
Total de puntos de función: 155.70
Valor de referencia de tabla: 1.40
Horas/persona según Longstreet: 217.98
Duración en minutos: 0.00

2. Ajustes al esfuerzo
Esfuerzo estimado: 217.98
Incremento al esfuerzo: 0.00
Decremento al esfuerzo: 0.00
Tiempo de duración de proyecto similar: 0.00
Esfuerzo ajustado: 217.98

3. Planteamiento del Calendario

Horas/Persona: 217.98
Des a crol lado res Totales: 4.00
Horas acumuladas diarias: 16.00
Días totales a laborar: 13.62

4. Restricciones de Tiempo
Tiempo definido por el cliente:0.00
Días Laborales: 5.00

5. Costo total del proyecto

Suma de costos del proyecto: 62872.12

5.1 Salarios

Condiciones salariales del personal

Tipo Cantidad Sueldo Horas Horas Horas Costo Sueldo Sueldo Suma de
por hora Diarias Totales Extras hora diario total por sueldos
totales extra por persona
persona
Admon. 1.00 156.25 8.00 217.98 0.00 0.00 1250.00 34059.3 34059.3
del 8 8
Proyecto
Requerí 1.00 125.00 4.00 10.90 0.00 0.00 500.00 1362.50 1362.50
míenlos
Análisis 1.00 125.00 4.00 43.60 0.00 0.00 500.00 5450.00 5450.00
y diseño
General
Construc 1.00 125.00 4.00 141.69 0.00 0.00 500.00 17711.2 17711.2
cion 5 5
Instrucci 1.00 125.00 4.00 21.80 0.00 0.00 500.00 2725.00 2725.00
on y
Capacita
cion al
Usuario

Sueldo total de personal: 61308.12

5.2 Capacitación

Capacitación y Actualización de perisonal

Nombre Desarrollad Costo Viáticos Proy/Cap Total
ores
Total costo de capacitación:
5.3 Recursos

Adquisición de Hardware nuevo para el proyecto

Nombre ¡Costo Provecto a utilizar Total
Total Hardware: 0,00

Adquisición de Software nuevo para el proyecto

Nombre Costo Proyecto a utilizar ¡Total
Total Software: 0.00
5.4 Otros
Costo total de otros gastos: 564.00
Asesoría (costo): 0.00
Outsourcing (costo): 0.00
Papelería (costo): 500.00
Costo total de otros gastos: 500.00
Proyecto por mes: 1.00
Meses de trabajo: 0.45
Luz
Costo bimestral: 300.00
Proyectos por bimestre: 1.00
Bimestres de trabajo: 0.23
Costo por proyecto: 69.00
Agua
Costo mensual: 100.00
Costo por proyecto: 45.00
Renta del local
Costo mensual: 0.00
Costo por proyecto: 0.00
Renta del telefono
Costo mensual: 500.00
Costo por proyecto: 225.00
Renta de Internet
Costo mensual: 500.00
Costo por proyecto: 225.00
Renta de hardware
Costo mensual: 0.00
Costo por proyecto: 0.00
SIAOP.ecp
1. Estimación del Esfuerzo en Puntos de Función
Total de puntos de función: 265.78
Valor de referencia de tabla: 1.40
Horas/persona según Longstreet: 372.09
Duración en minutos: 0.00

2. Ajustes al esfuerzo
Esfuerzo estimado: 372.09
Incremento al esfuerzo: 0.00
Decremento al esfuerzo: 0.00
Tiempo de duración de proyecto similar: 0.00
Esfuerzo ajustado: 372.09

3. Planteamiento del Calendario

Horas/Persona: 372.09
Desarrolladores Totales: 4.00
Horas acumuladas diarias: 16.00
Días totales a laborar: 23.26

4. Restricciones de Tiempo
Tiempo definido por el cliente.0.00
Días Laborales: 5.00 I

5. Costo total del proyecto

Suma de costos del proyecto: 109129.03

5.1 Salarios

Condiciones salariales del personal

Tipo Cantidad Sueldo Horas Horas Horas Costo Sueldo Sueldo Suma de
por hora Dianas Totales Extras hora diario total por sueldos
totales extra por persona
persona
Admon. 1.00 156.26 8.00 372.09 0.00 0.00 1250.08 58142.7 58142.7
del 8 8
Proyecto
Requerí 1.00 125.00 4.00 18.60 0.00 0.00 500.00 2325.00 2325.00
mientas
Análisis 1.00 125.00 4.00 74.42 0.00 0.00 500.00 9302.50 9302.50
y diseño
General /
Construc 1.00 125.00 4.00 241.86 0.00 0.00 500.00 30232.5 30232.5
cion 0 0
5.2 Capacitación

Capacitación y Actualización de personal

Nombre Desarrollad Costo Viáticos Proy/Cap Total
ores
Total costo de capacitación:
5.3 Recursos

Adquisición de Hardware nuevo para el proyecto

Nombre Costo Proyecto a utilizar Total
Total Hardware: 0.00

Adquisición de Software nuevo para el proyecto

Nombre Costo Proyecto a utilizar Total
Manejador BD 2500.00 1 2500.00
Total Software: 2500.00
5.4 Otros
Costo total de otros gastos: 975.00
Asesoría (costo): 0.00
Outsourcing (costo): 0.00
Papelería (costo): 500.00
Costo total de otros gastos: 500.00
Proyecto por mes: 1.00
Meses de trabajo: 0.78
Luz
Costo bimestral: 300.00
Proyectos por bimestre: 1.00
Bimestres de trabajo: 0.39
Costo por proyecto: 117.00
Agua
Costo mensual: 100.00
Costo por proyecto: 78.00
Renta del local
Costo mensual: 0.00
Costo por proyecto: 0.00
Renta del telefono
Costo mensual: 500.00
Costo por proyecto: 390.00
Renta de Internet
Costo mensual: 500.00
Costo por proyecto: 390.00
Renta de hardware
Costo mensual: 0.00
Costo por proyecto: 0.00
SIRH.ecp
1. Estimación del Esfuerzo en Puntos de Función
Total de puntos de función: 186.30
Valor de referencia de tabla: 1.40
Horas/persona según Longstreet: 260.82
Duración en minutos: 0.00

2. Ajustes al esfuerzo
Esfuerzo estimado: 260.82
Incremento al esfuerzo: 0.00
Decremento al esfuerzo: 0.00
Tiempo de duración de proyecto similar: 0.00
Esfuerzo ajustado: 260.82

3. Planteamiento del Calendario

Horas/Persona: 260.82
Desarrolladores Totales: 4.00
Horas acumuladas diarias: 16.00
Días totales a laborar: 16.30

4. Restricciones de Tiempo
Tiempo definido por el cliente:0.00
Días Laborales: 5.00

5. Costo total del proyecto

Suma de costos del proyecto: 75029.38

5.1 Salarios

Condiciones salariales del personal

Tipo Cantidad Sueldo Horas Horas Horas Costo Sueldo Sueldo Suma de
por hora Diarias Totales Extras hora diario total por sueldos
totales extra por persona
persona
Admon. 1.00 156.25 8.00 260.82 0.00 0.00 1250.00 40753.1 40753.1
del 2 2
Proyecto
Requerí 1.00 125.00 4.00 13.04 0.00 0.00 500.00 1630.00 1630.00
mientos
Análisis 1.00 125.00 4.00 52.16 0.00 0.00 500.00 6520.00 6520.00
y diseño
General
Construc 1.00 125.00 4.00 169.53 0.00 0.00 500.00 21191.2 21191.2
cion 5 5
Instrucci 1.00 125.00 4.00 26.08 0.00 0.00 500.00 3260.00 3260.00
on y
Capacita
cion al
Usuario

Sueldo total de personal: 73354.38

5.2 Capacitación

Capacitación y Actualización de personal

Nombre Desarrollad Costo Viáticos Proy/Cap Total
ores
Total costo de capacitación:
5.3 Recursos

Adquisición de Hardware nuevo para el proyecto

Nombre Costo Proyecto a utilizar Total
Total Hardware: 0.00

Adquisición de Software nuevo para el proyecto

Nombre Costo Proyecto a utilizar Total
Total Software: 0.00
5.4 Otros
Costo total de otros gastos: 675.00
Asesoría (costo): 0.00
Outsourcing (costo): 0.00
Papelería (costo): 500.00
Costo total de otros gastos: 500.00
Proyecto por mes: 1.00
Meses de trabajo: 0.54
Luz
Costo bimestral: 300.00
Proyectos por bimestre: 1.00
Bimestres de trabajo: 0.27
Costo por proyecto: 81.00
Agua
Costo mensual: 100.00
Costo por proyecto: 54.00
Renta del local
Costo mensual: 0.00
Costo por proyecto: 0.00
Renta del telefono
Costo mensual: 500.00
Costo por proyecto: 270.00
Renta de Internet
Costo mensual: 500.00
Costo por proyecto: 270.00
Renta de hardware
Costo mensual: 0.00
Costo por proyecto: 0.00
SIF.ecp
1. Estimación del Esfuerzo en Puntos de Función
Total de puntos de función: 154.00
Valor de referencia de tabla: 1.40
Horas/persona según Longstreet: 215.60
Duración en minutos: 0.00

2. Ajustes al esfuerzo
Esfuerzo estimado: 215.60
Incremento al esfuerzo: 0.00
Decremento al esfuerzo: 0.00
Tiempo de duración de proyecto similar: 0.00
Esfuerzo ajustado: 215.60

3. Planteamiento del Calendario

Horas/Persona: 215.60
Desarrolladores Totales: 4.00
Horas acumuladas diarias: 16.00
Días totales a laborar: 13.48

4. Restricciones de Tiempo
Tiempo definido por el cliente:0.00
Días Laborales: 5.00

5. Costo total del proyecto

Suma de costos del proyecto: 49948.50

5.1 Salarios

Condiciones salariales del personal

Tipo Cantidad Sueldo Horas Horas Horas Costo Sueldo Sueldo Suma de
por hora Diarias Totales Extras hora diario total por sueldos
totales extra por persona
persona
Admon. 1.00 156.25 8.00 215.60 0.00 0.00 1250.00 33687.5 33687.5
del 0 0
Proyecto
Requerí 1.00 125.00 4.00 10.78 0.00 0.00 500.00 1347.50 1347.50
mientos
Análisis 1.00 125.00 4.00 43.12 0.00 0.00 500.00 5390.00 5390.00
y diseño
General
Construc 1.00 125.00 4.00 14.14 0.00 0.00 500.00 1767.50 1767.50
cion
Instrucci 1.00 125.00 4.00 21.56 0.00 0.00 500.00 2695.00 2695.00
on y
Capacita
cion al
Usuario

Sueldo total de personal: 44887.50

5.2 Capacitación

Capacitación y Actualización de personal

Nombre Desarrollad Costo Viáticos Proy/Cap Total
ores
Total costo de capacitación:
5.3 Recursos

Adquisición de Hardware nuevo para el proyecto

Nombre Costo Proyecto a utilizar Total
Terminal Portátil 3500.00 1 3500.00
Total Hardware: 3500.00

Adquisición de Software nuevo para el proyecto

Nombre Costo (Proyecto a utilizar Total

Total Software: 0.00

5.4 Otros
Costo total de otros gastos: 561.00
Asesoría (costo): 0.00
Outsourcing (costo): 0.00
Papelería (costo): 500.00
Costo total de otros gastos: 500.00
Proyecto por mes: 1.00
Meses de trabajo: 0.45
Luz
Costo bimestral: 300.00
Proyectos por bimestre: 1.00
Bimestres de trabajo: 0.22
Costo por proyecto: 66.00
Agua
Costo mensual: 100.00
Costo por proyecto: 45.00
Renta del local
Costo mensual: 0.00
Costo por proyecto: 0.00
Renta del telefono
Costo mensual: 500.00
Costo por proyecto: 225.00
Renta de Internet
Costo mensual: 500.00
Costo por proyecto: 225.00
Renta de hardware
Costo mensual: 0.00
Costo por proyecto: 0.00
 Anexos
Anexo A. Sistema de Control y Administración de Presupuesto (SICAP)

Anexo B. Sistema de Control del Archivo de Oportunidades (SIAOP)

Anexo C. Sistema de Recursos Humanos del Congreso del estado de

Veracruz (SIRH)

Anexo D. Sistema de Inventario (SIF)

 Anexo A. Sistema de Control y Administración de
Presupuesto (SICAP)
El Ayuntamiento Jalapeño es una forma de gobierno reconocida por nuestra
Constitución, el cual impulsa de manera permanente una participación plural y efectiva
en la vida de la ciudad. Este objetivo se alcanzará de forma gradual y se reflejará en
una administración eficaz, con vocación democrática, en la que el cabildo garantizará
el respeto absoluto a los derechos de los individuos y de la sociedad que representa.

La administración municipal promueve tareas de desarrollo político y acciones

alternativas que privilegien el fomento a la tolerancia, la pluralidad, la participación
ciudadana en acciones de beneficio social dentro del territorio.

La consolidación de la cultura participativa que impulsa el H. Ayuntamiento de Jalapa,

así como las propuestas y programas a promover y ejecutar, solo pueden concebirse
en virtud de la acción corresponsable y solidaria de los diferentes grupos y sectores de
nuestra comunidad, sin cuya colaboración, cualquier esfuerzo será insuficiente.

El objetivo es superar los rezagos en infraestructura urbana y social, y convertir a

Jalapa en un municipio moderno y eficiente; en una ciudad de primer nivel, donde
todos podamos vivir con dignidad, promoviendo la participación ciudadana en las
decisiones fundamentales del nuevo gobierno municipal.

Las principales metas del Ayuntamiento son :

’b Promover programas de fomento educativo, recreativo y cultural, que favorezcan la

participación ciudadana.

Realizar un buen control presupuestal que controle de manera adecuada todos los
recursos de los departamentos con que cuenta la institución.

Ofrecer mayores oportunidades de desarrollo y contribuir a elevar el nivel de vida

de la sociedad jalapeña.

Apoyar programas de pavimentación, guarniciones, alumbrados públicos, y

saneamiento ambiental.
Organigrama de la empresa

Es importante ubicar el sistema propuesto dentro del marco organizacional de la

institución; por lo tanto a continuación se describen los departamentos en que
interviene el sistema, siendo el principal el Departamento de la Tesorería, el
organigrama se muestra en la Figura AxA.l. Este organigrama indica la organización
general de los principales departamentos del Ayuntamiento.

Departamento de la Tesorería Es de las principales áreas del Ayuntamiento ya que

es la encargada de dirigir, coordinar y fungir como principal administrador de los
recursos financieros de las diferentes áreas administrativas.
Lista de los principales problemas

En esta sección, se resumen los principales problemas que se enfrenta el control de

presupuesto; para ello se han dividido 2 grupos, los que se pueden resolver y los que
no se pueden resolver con el uso de la computadora.

Los problemas que se pueden resolver empleando computadora:

Automatizar las tareas manuales de presupuesto.

Controlar el gasto presupuestal.

Dar un seguimiento de los gastos de las distintas áreas.

Obtener reportes en tiempo y forma.

Facilitar procesos de oficina.

En términos generales el control actual de presupuesto es llevado a través de registros

manuales en formatos elaborados en Excel.

Así mismo, se muestran los problemas que no se resuelven con una computadora :

Uso inadecuado del gasto presupuestal.

Mantenimiento de equipo.

Decisiones equivocadas.

Fallo de la red.

Fallo de energía eléctrica.

Justificación del nuevo software

Elaborar el Sistema de Control y Administración de Presupuesto Municipal supone un

reto por distintos motivos:

La rudimentaria tarea de muchos años en forma manual implica ajustes en el

funcionamiento de los proceses, a la vez que posibilita una planificación y control
de las actividades.
 La creación de SICAP tiene como objetivo, por tanto, orientar, asesorar y facilitar
las tareas que permitan a los usuarios y autoridades el control y la administración
de presupuesto.

De esta forma la herramienta SICAP, trata de dar respuesta a los problemáticas

planteadas en este capítulo, generar una novedosa forma de trabajar y responder a
las necesidades de control detectadas en la institución.

Conclusión sobre la situación actual

Los requerimientos de software son fundamentales para el buen funcionamiento del

sistema de control de presupuesto.

Para obtener una adecuada recopilación de los requerimientos son indispensables

realizar el análisis de requerimientos de software (ARS) siguiendo actividades que
permitan obtener una especificación de requerimientos de software (ERS), que resulte
útil para todos los involucrados en la elaboración de un nuevo software.

Propuesta Computacional

En esta sección, se muestra el guión SICAP, el cual se encuentra clasificado en dos

pistas, una pista "captura de presupuesto", en ella se genera la captura de
presupuesto de áreas, y los gastos que se realizan con el.

Una segunda pista "Actualización de presupuesto", en la que se realizan

transferencias, incrementos, reducciones y actualizaciones de presupuesto, así como la
solicitud de consultas y reportes.

Esquema General de la Propuesta Computacional

En la Figura AxA.2 se muestra la pista "captura de presupuesto", el cual describe las

escenas participantes en los procesos de captura del presupuesto de las áreas.
Pista : Actualización de presupuesto Escena 1: Iniciar sesión
A ingresa la clave
Papeles: \ La clave no es correcta?
A ingresa clave ó sale
US : Usuarios A inicia sesión
A = Autoridad
SI = Sistema de presupuesto Escena 2: Ampliaciones
A solicita AP
'' ¿Error en calendario?
Utensilios : SI envía mensaje de error
AP = Ampliación de presupuesto A actualiza AP
CM = Cierre mensual
RU = Registro de usuario Escena 3: Reducciones
PD = Presupuesto disponible A solicita RP
RP = Reducción e presupuesto '¿Error en calendario?
RC = Reportes de control SI envía mensaje de error
A actualiza RP

Escena 4: Transferencias
Condiciones de entrada : A selecciona parámetros
Deberá existir en PD ' ¿Hacer la transferencia?
Se visualiza la nueva información
Condiciones de salida :
AU podrá generar RC Escena 5:Registro de usuarios
A ingresa DU
¿Existen datos?
Enviar datos en pantalla
AU actualiza DU

Escena 6: Generar reportes

A solicita RC

Figura AxA.3. Pista "Actualización de presupuesto" del guión SICAP.

Modelo de Datos

El modelo de datos es una representación gráfica de los objetos que conforman el

sistema propuesto, aquí se identifican los objetos o clases, a demás de sus atributos.
En la Figura AxA.4 se modela el sistema de información mediante el modelo relacional
E-R, en el cual se indican las tablas resultantes, claves primarias y foráneas.

Figura AxA.4. Modelo de datos de SICAP.

El modelo anterior, ¡lustra un conjunto de tablas relacionadas, las cuales son:

Presupuesto.- Tabla del presupuestal original.

Áreas.- Catalogo de áreas.

Programas.- Catálogo de programas y sub programas.

Partidas.- Catálogo de partidas de presupuesto.

Pagos.- Tabla de pagos.

Compromisos.- Tabla de pagos extraordinarios.

’b Resumen.- Resumen de los movimientos que se generaron como transferencias,

reducciones, y la actualizaciones.
Bitácora de desarrollo

A través de una tabla se presenta una descripción más detallada de cada una de las
quintetas que conforman la propuesta computacional, asó como las operaciones que se
requerirán para llevarlas a cabo y una estimación del tiempo de desarrollo (Tablas
AxA.l hasta AxA.10).

Tabla AxA.l. Escena 1: Identificación del usuario

Función Comprobación Tiempo

US Ingresar clave US ingresa la clave y la contraseña de acceso, 2 Horas
al dar clic en OK, el sistema despliega el menú
de opciones, en otro caso, envía mensaje de
error.

Tabla AxA.2. Escena 2: Presupuesto original

Función Comprobación Tiempo

US ingresa PD US ingresa un nuevo registro con la clave del 5 Horas
programa, al dar clic sobre la opción Grabar,
US observa que el nuevo registro queda
grabado en la tabla, en otro caso recibe
mensaje de error.
US actualiza PD Al seleccionar la clave del programa, se 3 Horas
muestran los datos del programa.

Tabla AxA.3. Escena 3: Cuentas por pagar

Función Comprobación Tiempo

US ingresa CP US ingresa un nuevo registro con la clave de! 4 Horas
programa y la factura, al dar clic sobre la
opción Grabar, US observa que el nuevo
registro queda grabado en la tabla, en otro caso
recibe mensaje de error.
US actualiza CP Al seleccionar la clave del programa y la 2 Horas
factura, se muestran los datos del programa.
 Tabla AxA.4. Escena 4: Presupuesto comprometido

Función Comprobación Tiempo

US ingresa PC US ingresa un nuevo registro con la clave del 2 Horas
programa y el folio, al dar clic sobre la opción
Grabar, US observa que el nuevo registro queda
grabado en la tabla, en otro caso recibe
mensaje de error.
US actualiza PC Al seleccionar la clave del programa y el folio, 1 Hora
se muestran los datos del programa.

Tabla AxA.5. Escena 5: Cierre mensual

Función Comprobación Tiempo

US realiza CM US ingresa un nombre de archivo y dar clic en 8 Horas
cierre mensual, US observa el mensaje "El
cierre de mes se realizo satisfactoriamente", en
otro caso recibe mensaje de error.

Tabla AxA.6. Escena 6: Ampliaciones

Función Comprobación Tiempo

A ingresa AP A selecciona el programa e ingresa el importe a 4 Horas
incrementar y al dar clic en OK, A observa el
mensaje que el incremento queda grabado en la
tabla, en otro caso recibe mensaje de error.
A actualiza AP Al seleccionar el programa, se muestran los 2 Hora
datos del programa, en caso contrario, recibe
mensaje de error.

Tabla AxA.7. Escena 7: Reducciones

Función Comprobación Tiempo

A ingresa RP A selecciona el programa e ingresa la reducción 2 Horas
de presupuesto y al dar clic en OK, A observa
el mensaje que la reducción queda grabado en
la tabla, en otro caso recibe mensaje de error.
A actualiza RP Al seleccionar el programa, se muestran los 2 Horas
datos del programa, en caso contrario, recibe
mensaje de error.
 Tabla AxA.8. Escena 8: Transferencias

Función Comprobación Tiempo

A selecciona A selecciona los programas de transferencia ( 4 Horas
parámetros fuente y destino), e ingresa el importe a
transferir, al dar clic en OK, A observa la
transferencia, en otro caso, recibe mensaje de
error.

Tabla AxA.9. Escena 9: Registro de usuarios

Función Comprobación Tiempo

A ingresa DU A ingresa el registro de un usuario, al dar clic 2 Horas
sobre la opción Grabar, A observa que el nuevo
registro queda grabado en la tabla, en otro caso
recibe mensaje de error.
A actualiza DU Al ingresar la clave del usuario, al dar clic en 1 Hora
OK, se despliegan los datos en pantalla, en otro
caso, recibe mensaje de error.

Tabla AxA.10. Escena 10: Generar reportes

Función Comprobación Tiempo

A ó U solicita RC A selecciona los parámetros del reporte, a! dar 10 Horas
clic en OK, A observa el reporte en pantalla o en
impresora
 Anexo B. Sistema de Control del Archivo de
Oportunidades (SIAOP)
EL Programa de Desarrollo Humano Oportunidades es un programa que pertenece a la
Secretaria de Desarrollo Social, el cuál brinda apoyos a personas de extrema pobreza.
Estos apoyos ANXBarcan los siguientes aspectos: Educación, Salud y Alimentación.

En educación el Programa otorga becas escolares a los estudiantes que cursen a partir
de 3o. De primaria hasta el último grado de Bachillerato. El monto de la beca varía
según el grado que cursa el alumno y su sexo, siendo para el sexo femenino una beca
mayor al sexo masculino, debido a que estadísticamente la mujer ANXBandona
primero los estudios que el barón.

En cuanto a Salud el programa una consulta médica cada mes para todos los
integrantes de la familia. Estas consultas médicas se llevan a cANXBo en clínicas de
SSA y en el IMSS.

En alimentación otorga un apoyo bimestralmente a todas las titulares del programa,

además de un complemento alimenticio para los niños menores de 4 años y un
complemento alimenticio para mujeres embarazadas.

El Programa de Desarrollo Humano Oportunidades fue inaugurado el 1 de marzo de

2002 en el estado de Sinaloa. Este programa es el sucesor del programa de Progresa
inaugurado en el año de 1997.

Actualmente a nivel nacional existe un total de más de 4 millones de titulares en el

programa. En el estado de Veracruz uno de cada 8 beneficiarios es de este estado,
logrando la meta aproximadamente de 500,000 titulares.

Ubicación Geográfica

El archivo de la Coordinación Estatal de Oportunidades se localiza a orillas de esta

ciudad, en la carretera Xalapa-Veracruz km 3+700, en la colonia EL Olmo.

Metas

Las principales metas del programa Oportunidades son los siguientes:

Integración del Padrón de Familias.

Integración del Padrón de Becarios.

 Prestación de Servicios de Salud y Certificación de CorresponsANXBilidades,

Certificación de CorresponsANXBilidad a los Servicios Educativos.

Componente Patrimonial "Jóvenes con Oportunidades".

Entrega de Apoyos Monetarios.

Entrega de Suplemento Alimenticio.

Mecanismos de Atención a Familias Beneficiarías.

Coordinación Interinstitucional.

Formación de Estructuras Comunitarias.

Organigrama de la empresa

Es importante ubicar el sistema propuesto dentro del marco organizacional de la

Institución; por lo tanto a continuación se describen los departamentos en que
interviene el sistema, siendo el principal el departamento de Archivo, el organigrama
se muestra en la Figura AxB.l. En este organigrama solo se muestra a detalle el área
de Padrón y Sistemas que es donde se localizaría el sistema.

Figura AxB.l. Organigrama de la Coordinación Estatal de Veracruz.

Coordinador Estatal. El la persona que tiene a su cargo toda la Coordinación Estatal, se

encarga de dirigir y controlar a las áreas de: Atención Ciudadana, Padrón y Sistemas,
Área Operativa y al Área Administrativa.
En el sistema propuesto existen dos áreas muy importantes que intervienen en él: El
Área de Padrón y sistemas, los cuales emiten los formatos y el área Operativo, los
cuales entregan y recuperan los formatos a las instituciones que intervienen en el
programa (Sector Salud y Sector de Educación).

Subdirector de Padrón y Sistemas: Es el responsable de la administración del padrón

de beneficiarios del estado de Veracruz. Es el área más importante en el organigrama
de la coordinación Estatal, ya que es donde se emiten todos los formatos oficiales de
las titulares, así como la captura de todos los movimientos solicitados. En este
departamento existen tres jefaturas: Jefatura de Padrón, Jefatura de sistemas y la
Jefatura de Archivo. Básicamente todos los formatos que se encuentran almacenados
en el archivo de Oportunidades son creados en esta área.

Subdirector del Área Operativa: Es una persona importante en el esquema del

Programa, ya que es el responsable de que la titular obtenga sus apoyos, realice sus
movimientos y pueda enterarse de sus corresponsabilidades. Esta Área se encuentra
conformada por tres Jefes de Atención Operativa, distribuidos a lo largo del estado:
Norte, Centro, Sur. También son los encargados de recolectar todos los formatos
oficiales con sus respectivos sellos y firmas válidas, los cuales son entregados al área
de archivo para su correcto almacenamiento.

Lista de los principales problemas

En esta sección se muestran los principales problemas que enfrentan en la

administración y control del archivo del programa Oportunidades; para ello se han
separado en dos grupos: los que tienen solución utilizando computadora y los que no
se pueden resolver utilizando una computadora:

Problemas que se pueden resolver empleando computadora.

El departamento del Archivo de oportunidades les resulta complicado Generar

reportes finales o parciales de los formatos entregados por parte del área
Operativa.

El departamento de Padrón y sistemas no cuenta con la información ai día y

actualizada de los formatos que están almacenados en el archivo de la
Coordinación Estatal.
 Controlar la productividad de los empleados es una función que no se lleva a
cANXBo actualmente en el archivo de la Coordinación Estatal.

Debido a que el programa es financiado por el Banco Internacional, el programa

está expuesto a diversas auditorías y cuando ellos requieren de un documento o un
formato, resulta muy complicado encontrarlo.

En términos generales el control actual del archivo de la Coordinación Estatal es

guiado a través de registros manuales y de formatos creados en Excel y reportes
generados en Word.

Existe una gran incertidumbre en el total de los formatos.

Problemas que no se pueden resolver utilizando computadora

Revisión y validación de los formatos recibidos.

Asignación de cargas de trANXBajo.

Almacenamiento de los formatos ya validados.

Toma de decisiones por parte del Jefe de archivo.

Que se encuentre mal ordenado un paquete de formatos.

Que no se encuentre un formato.

Los problemas anteriores son cuestiones que tienen que ver con el funcionamiento del
archivo de la Coordinación Estatal pero no se pueden resolver utilizando una aplicación
de software.

Justificación del nuevo software

Como se puede observar en la sección anterior existe una problemática actual en el

control y la administración del archivo de la Coordinación Estatal, debido a su
magnitud y a las cargas de trANXBajo liberadas por la Coordinación Nacional.

Es importante contar con una herramienta que apoye en la administración y control del
archivo dando indicadores y reportes que ayuden en el funcionamiento del mismo. Así
como la ayuda en consultas de información y búsquedas físicas de los formatos
solicitados.
Cuando existe una auditoría se requieren los documentos lo más rápido posible y si se
cuenta con una herramienta que facilite las búsquedas de los formatos evitaría mucho
tiempo invertido en realizar estas búsquedas.

Conclusión sobre la situación actual

En los puntos anteriores se mencionó la forma en como opera actualmente el archivo

de la Coordinación Estatal del Programa de Desarrollo Humano Oportunidades, dando
énfasis a los puntos clave donde existen problemas. Aunque el Archivo de la
Coordinación Estatal de Veracruz ha sido reconocido a nivel Nacional por ser uno de los
mejores administrados y ordenados, no deja de ser un departamento exento de
errores. Por la cantidad de documentos que sé manejan bimestres a bimestres es
necesario contar con una herramienta que facilite el uso de la administración y control
del archivo de la Coordinación Estatal.

Propuesta Computacional

En la siguiente sección se presenta el Guión correspondiente a la propuesta

computacional, desarrollada para el sistema de administración y control del archivo de
la Coordinación Estatal del programa de Desarrollo Humano Oportunidades.

Esquema General de la Propuesta Computacional

El Guión computacional lo dividí en dos pistas, debido a que en una estoy considerando
todo lo referente a la administración y configuración del sistema y en otra pista
considero lo referente a captura de información.

El guión de la propuesta computacional de la Pista 1 Administración del sistema,

ANXBarca lo siguiente puntos:

Como condiciones de entrada: Acceso a la bases de datos del SIIOP

Condiciones de Salida: Generación de Bases de Datos y cifras de control, usuarios

válidos en el sistema con sus respectivos permisos.

Las funciones principales están representadas en escenas:

 Identificación del usuario, Generación de Bases, Consulta de Bases de Datos,
Respaldo de información, Carga de Bases de Datos, Crear usuario y asignación de
permisos.

En esta pista se consideran dos papeles para el sistema: Administrador y Usuario.

En la pista 2 Registro y consulta de formatos:

Condiciones de entrada: Bases de Datos Generadas.

Condiciones de salida: Reportes generados, Formatos Registrados.

Las funciones principales en este subsistema son:

Registro de caja, Registro de Formatos, Generación de reportes, y búsquedas.

En esta pista se consideran 2 papeles: capturista, administrador.

El guión de la propuesta computacional se muestra en la Figura AxB.2 la pista 1,

administración del SIAOP y en la Figura AxB.3 la pista 2 llamada registro y consulta de
formatos.
Guión: Sistema de control del archivo Escena 1 : Identificación de Usuario
de Oportunidades Op ingresa CV
SICAOP ¿Clave incorrecta?
" Op recibe mensaje de error
Pista 1: Administración del sistema Op selecciona M

Papeles: Escena 2.1 : Generación de bases

Op = Operador de Sistemas Op selecciona TF
UP = Usuario Válido Op selecciona Año
Op selecciona BI
Utensilios: ''' - ¿Base existente?
CV = Clave Válida Op recibe mensaje de advertencia
TF = Tipo de Formato OP imprime Formato de CG
BI = Bimestre
CG = Cifras Generadas Escena 2.2: Consulta de Bases de datos
P = Permisos Generadas
TR = Tipo de Reporte Op selecciona BG
RD = Respaldo de Datos Op imprime CG
BG = Base Generada
Escena 3.1: Respaldo de Información
OP Selecciona RD
OP Imprime CV
OP grANXBa en CD RD

Condiciones de Entrada: Escena 3.2: Carga de Base de Datos

Acceso a las bases del SIIOP Op selecciona BG
OP valida BG
Condiciones de Salida: OP carga BG

Generación de Bases de Datos y cifras Escena 4.1: Crea usuario

totales Op genera UP
Respaldos de Información OP registra datos UP
Usuarios Permitidos y Claves Válidas ¿Usuario Existente?
'OP recibe mensaje de advertencia

Escena 4.2 Asigna permisos

Op selecciona UP
Op ASIGNA P

Figura AxB.2. Guión de la propuesta computacional Pista 1.

Guión: Sistema de control del archivo Escena 1 : Identificación de usuarios
de Oportunidades SIAOP Ca, OP ingresa CV
¿Clave incorrecta?
Pista 2: Registro y consulta de UP,OP recibe mensaje de error
Formatos

Escena 2 : Registro de formatos

Papeles:
Ca selecciona TF
OP = Operador de sistemas
Ca selecciona aa
Ca = Capturista
Ca selecciona BI
Ca pistolea F
¿Formato inválido?
Utensilios:
"Ca recibe mensaje de error
CV =? Clave válida
Ca registra F
BI = Bimestre Recibido
Ca imprime RC
F = Formatos
TF = Tipo de Formato
Escena 3 : Registro en Cj
aa = Año
Ca selecciona Cj
Cj = Caja
Ca captura RC
RC - Cifras Registradas
R = Reporte
Escena 4: Reportes
OP selecciona TR (Avance,Productividad,
Totales,etc)
OP selecciona TF
Condiciones de Entrada: OP selecciona AA
Bases de datos generadas OP selecciona BI
OP genera R
Op imprime o exporta R
Condiciones de Salida:
Reporte de formatos capturados Escena 5: Búsquedas
Reporte de formatos faltantes OP selecciona TF
Formatos Registrados OP ingresa folio

Figura AxB.3. Guión de la propuesta computacional Pista 2.

Modelo de Datos

El Modelo de Datos es una representación gráfica de los objetos que conforman el

sistema propuesto.

Dentro del análisis de requerimientos se define cuál será el modelo de datos que se
empleará para el desarrollo del sistema. En este caso el sistema se desarrollaría en
Java el cual es un lenguaje de programación orientado a objetos. En las Figura AxB.4
se muestra el modelo de datos del Sistema.

$ id: INTEGER $ ideaja: INTEGER______ idformatos: INTEGER________

4 login: CHAR 4 usuarioJd: INTEGER (FK) 4 concentraJdbase: INTEGER (FK)
4 contra: CHAR ;Rel_O2j 4 anaquel: CHAR 4 cajajdcaja: INTEGER (FK)
ÍReljOl
4 nombre: CHAR O fila: CHAR 4 Bimestre: CHAR
4 puesto: CHAR 4 colummna: CHAR ■ 4 Formato: CHAR
4 sitúa: CHAR 4 bimestre: CHAR 4 Caja: INTEGER
4 fecha: CHAR usuarioid: INTEGER
4__________ 4 etiqueta: CHAR
4 permisos: INTEGER c3j3_FKIndexl 4 usuario: CHAR
usuatiojd 4 fecha: CHAR
concentra
4 ano: CHAR
t idbase: INTEGER
4 usuarioid: INTEGER
4 formatsjdformato: INTEGER (FK)
4 id base: INTEGER
4 notificaJdnotifica: INTEGER (FK) 3 foirnato^FKIndexl
4 ficha Jdficha: INTEGER (FK)
J idforma: INTEGER__________ 4 cajajdcaja
❖ fecha: CHAR
4 concentrajdbase: INTEGER (FK) £ form8to_fí<Jndex2
4 concentra: CHAR
4 mun: CHAR 4 concentrajdbase
0 formato: CHAR
4_______________
reg: INTEGER 4 loe: CHAR
concebí r3JWntíexi 4 ese: CHAR
4 concentra: INTEGER
4 fichaJdficha
concentra_fí(Index2 £ form3te_FKIndexl
4 notificaJdnotifica 4 concentrajdbase
concentr3__FKIndex3
4 formatsjdformato
í ¡formats'
(O- í 19 idformato: INTEGER
ficha ',í“í?’ 4. notifica"-' 14 mun: CHAR
i $ idnotifica: INTEGER 4 loe: CHAR
t idficha: INTEGER
4 mun: CHAR i 4 folio: CHAR 4 ageb: CHAR
4 loe: CHAR E 4 nombre: CHAR 4 capturado: CHAR
1 4 mun: CHAR 4 usuario: INTEGER
4 ageb: CHAR
4 foto: CHAR 4 loe: CHAR 4 fecha: CHAR
4 tipomov: INTEGER 4 ageb: CHAR 4 juris: CHAR
4 loteid: INTEGER 4 causa: CHAR 4 etiqueta: CHAR
4 baseid: INTEGER 4 fecha: CHAR 4 baseid: INTEGER
4 codigo: CHAR 4 baseid: INTEGER

Figura AxB.4. Modelo Entidad Relación

Bitácora de desarrollo

En la Tabla AxB.l muestra a detalle cada una de las quintetas que conforman la
propuesta computacional, así como las operaciones que se requerirán para llevarlas a
cabo y una estimación de tiempo de desarrollo. Esto último deberá ser comparado con
el tiempo real de desarrollo.
 Tabla AxB.l (a). Bitácora de Desarrollo

Tiempo
Función Forma de comprobación Tiempo real
propuesto

El OP recibirá un
mensaje de bienvenida y
Validar acceso OP 8 53
podrá acceder al menú
principal.

El OP recibirá un
mensaje de "proceso
OP Genera bases de
terminado", una vez que 50 70
datos
haya creado todas las
bases de datos.

El OP visualizará en
OP consulta Bases de pantalla el contenido de
30 30
Datos la base de datos
seleccionada

El OP visualizará en
pantalla la compresión
de los archivos de la
OP Genera respaldo de
base de datos, y al 30 20
la Base de Datos
terminar el proceso
recibirá el mensaje de
"respaldo concluido"
El OP visualizará en
pantalla los archivos de
la base de datos
OP Carga Base de Datos descomprimidos, al 20 16
término del proceso
recibirá el mensaje de
"base restaurada"
El OP visualizará en
Op crea clave capturista pantalla el mensaje de 4 9
"usuario creado"
El OP visualizará en
pantalla los datos
Op edita clave capturista 2 9
correctos de la clave
editada
El OP recibirá un
mensaje de advertencia
OP desactiva clave para seguir con el
2 6
capturista proceso. Si se continúa
recibirá un mensaje de
"clave suspendida"
 Tabla AxB.l (b). Bitácora de Desarrollo

Tiempo
Función Forma de comprobación Tiempo real
propuesto

El OP recibirá un
Op asigna permisos a mensaje de "permisos
2 6
cuentas de usuarios asignados", una vez
terminado el proceso

El CA recibirá un
OP, Ca, Crean caja mensaje de "caja 2 10
creada"

El CA visualizará en
Op, Ca, Registra
pantalla el folio 10 13
Formatos
agregado.

El OP visualizará en
OP Genera reportes pantalla los datos 30 30
generados

EL OP o el CA
OP, Ca, generan
visualizarán en pantalla 30 13
búsquedas
los datos generados

Total 210 horas 285 horas.

Anexo C. Sistema de Recursos Humanos del Congreso
del estado de Veracruz (SIRH)
El Poder Legislativo del Estado de Veracruz tiene su sede en Xalapa. El edificio en que
se alberga se inauguró el 12 de octubre de 1992 y el 3 de diciembre de ese año, la LVI
Legislatura, en ceremonia especial, lo declaró su recinto oficial, lugar desde el que
desempeña eficientemente la alta misión que el pueblo veracruzano le ha
encomendado.

Tiene como misión legislar para adecuar la norma jurídica a las necesidades sociales y
propiciar con ello, el logro de los fines del estado de Veracruz de Ignacio de la Llave.
Como visión ser un congreso que realice la acción legislativa de manera plural,
transparente y comprometida con la sociedad a través de una eficaz práctica
parlamentaria sustentada en la consulta popular que genere instrumentos orientados
al incremento sistemático y continuo del desarrollo económico, político, social y
cultural de la entidad. En la Figura AxC.l se muestra el organigrama del congreso.

F Secrtti&Gehéfil j
cHíCwvjtTW í

— J irtvwtígaciortrt |
iCcmunka aóft Social f
l —

Archivo. •
Í jr ftlbtíoteca

I Serrícic*

r - ,.CT"
i-1
Dífettíón de
| ¡Recursos Matnain y j
J | $g¡v<jen i f Hrtanoeraj | Seguimiento

.Depro defccgfstro f" ptwaO(¿:iJe',Í!

DocufMrtaí q AMfahdeb 4 DeutfaPüb.yPwg. I -iDcptaóü Amperes
| InsPtixídftal | ]

1 Oeoto, de I J Degto.rfd DtaHode j teotú. de SéfHclo* |j

a Comincott | | los Debates i
-j Programación y í
I Genera les H
1
Mr.x Síip-i
Municipios [ ! S<;rrólor« PmK | | tps)l j

CoúUtMiidad Métodos I JÍ
íí ^Ví<! p
Oficina dé
3¡t*<wlofa

Figura AxC.l. Organigrama del H. Congreso del Estado de Veracruz.

Lista de los principales problemas

Después de analizar la situación actual, se puede ver que los principales problemas
son:

’b No se cuenta con un sistema que maneja la plantilla de personal, esto hace que las
solicitudes de información sean lentas y erróneas.

Los permisos del personal son llevados de manera manual, por lo que no existe un
registro organizado de los mismos, se tienen capturados en diversas hojas de
cálculo en Microsoft Excel.

El control que se lleva de las prestaciones de anteojos otorgadas al personal se

lleva en una hoja de cálculo, por lo que ocasiona que se otorgue la prestación al
personal antes del tiempo establecido.

De los problemas anteriores, se propone resolver con la puesta en marcha de un

sistema de cómputo los siguientes:

Poder estar en condiciones de emitir reportes de personal de manera pronta y sin

errores, es decir, trabajar con una sola plantilla de personal.

Contar con un registro histórico de permisos del personal para consultas prontas.

Justificación del nuevo software

Se requiere un sistema acorde a las necesidades propias del Congreso del Estado como
unidad administrativa independiente, con sus propios requerimientos y criterios para
aplicar las disposiciones de ley.

Se necesita un sistema en donde la redundancia de información sea eliminada, y así

disminuir la inconsistencia.

Conclusión sobre la situación actual

El problema, radica en la falta de un sistema acorde con las necesidades propias del
Congreso del Estado. Si bien es cierto que se cuenta con el Sistema de Recursos
Humanos de la Secretaría de Finanzas y Planeación, este no cubre los esquemas que
necesitan en el Congreso, mismo que no es de acceso 100% al personal que maneja la
plantilla del personal, por estar restringido a manejo de personal de plaza, razón por la
cual solo se puede tener controlada una parte de la totalidad del personal.

Se propone un sistema integral que maneje la plantilla del personal, en -todos sus
aspectos, adecuado a las necesidades del Congreso.

Propuesta Computacional

En esta sección se muestran los siguientes aspectos:

Guión de la propuesta computacional. Se presenta una propuesta computacional

del SIRH la cual describe, a través de guiones, todas las actividades factibles de
automatizar en el Departamento de Control de Personal de la Dirección de Recursos
Humanos del Congreso del Estado de Veracruz. El guión agrupa actividades
respetando las funciones que desempeña cada persona en el departamento.

Modelo de.datos. Se muestra la representación gráfica de las relaciones que existen

entre los datos utilizados en SIRH.

Esquema General de la Propuesta Computacional

En la Figura AxC.2 se muestra el guión de la propuesta computacional para el sistema

a elaborar Sistema de Recursos Humanos.
Guión: Sistema de Recursos Humanos Escena 1: Identificación del usuario
JP ó AA ingresa clave
Pista: Control de Personal ¿Clave incorrecta?
JP ó AA recibe mensaje
Papeles "Clave Incorrecta"
JP: Jefe de Personal Sale del sistema
AA: Auxiliar Administrativo
Escena 2: Empleados
Utensilios AA actualiza PP
MP: Movimientos de personal AA actualiza MP
PP: Plantilla de personal AA actualiza CUR
CUR: Cursos impartidos al personal
PER: Permisos del personal Escena 3: Incidencias
INC: Incidencias del personal AA captura PER
ANT: Solicitud para otorgar la prestación AA procesa INC
de anteojos
CAT: Catálogo del sistema Escena 4: Prestaciones
CDEPTOS: Departamentos. AA actualiza ANT
- CPUESTO: Puestos. AA actualiza EST
CPROF: Profesiones.
CDIPS: Diputados. Escena 5: Catálogos
CTABS: Tabuladores. AA actualiza CDEPTOS
CCUR: Cursos. AA actualiza CPUESTO
CPERM: Permisos AA actualiza CPROF
REP: Reporte del personal AA actualiza CDIPS
IMP: Impresora AA actualiza CTABS
EST: Estímulo por antigüedad AA actualiza CCUR
AA actualiza CPERM
Condiciones de Entrada
DP necesita mantener PP actualizada Escena 6: Reportes
AA selecciona REP
Condiciones de Salida AA imprime REP en IMP
DP mantiene PP actualizada
Escena 7: Utilerías
AA selecciona BD
AA respalda BD

Figura AxC.2. Guión de la propuesta computacional.

Modelo de datos

En la Figura AxC.3 se presenta el modelo de datos correspondiente al SIRH.

i,
PK MjiMetaa ;W emoHtdo
• obaüWrteáánl
PK 1<L emofeedo M emoteedo
C5SES
PK PK id trftta
detcnpcfon
nombre ■
epáteme *
r > rfc ec_rteú
cánp_dom
< ■u
nunvoceta,
tcdt_recete
nombre ,
dirección

II ematemo
kLpuesto * r
■+
cred^etoc
curp
fcfjopttee rfc
CP
»
i
PK M ¿frutado
<d9pto
dirección
.
’f
curt vKae
dóc_oompr
*T‘ '

telefono •c^necJí
nontn
«acción ' nf»_ert ifií^^wüWi
tdjxnteslon
pttMJncand PK idj>roft»lon
tech^nac pmfjcond
prométatelo nomjwofeiton
td_<fiput»do
tugor_rae
l-J------------
etfojtec ^erMrUrneregtjM’
«Mtedón
nOTT\jJ»pá PK WdeMrfertwnto PK M oveeto
nofftjfflimí
1■ - COfoná nombro ncrrtx»
cMgo_pottef tfirooofán
PK M careo
KÜ Mcreterit
C*; nom_Our*o dajrrmion
impenido nun^avd
!>'• erado dvi
fechjnicio
fe M>_tNnkio
mame - A PKFKl l
PKFK1 M omhd
fcehejrigr
ídjlepertamento <■
td_tíL»*rtv*
kl_edocM
PK W enwteedo

W W_a»so
t condujo
hcondueo

Figura AxC.3. Modelo de datos del SIRH.

 Anexo D. Sistema de Inventario SIF
Las Farmacias del Magisterio pertenecen al Seguro Social de los Trabajadores de la
Educación del Estado de Veracruz (SSTEEV), como un servicio para los mismos. En la
Figura AxD.l se muestra el organigrama general del SSTEEV, detallando la parte
correspondiente a las farmacias del magisterio.

Figura AxD.l. Organigrama de la empresa.

Lista de los principales problemas

La forma en que se lleva actualmente el inventario físico origina varios problemas que
se pueden resolver utilizando las Terminales Portátiles:

Registro erróneo de productos con códigos de barra diferentes y con terminaciones

¡guales.

’b Errores en la captura de diferencias encontradas por el levantamiento de inventario

físico.
 I

1? j jjfj_■ «ifeBjtw
IdCfererxte£xfc
h: V
V *ir idGúágtórra IdCtdgofianá
«Ími Hhafo ,jg|
i WÍUttW '< I c |jH7ík¿OJ
Ftós ; ®SS
■K:?í JdCtt^a j>k7
•£ rt; atetó ^¿'•,: HtetóCPV .
1,.M. ■%: a.
&wtfe , Reducto - ct<
tótetó ¡ *# !¡gj. FHfcMfa|g£í' &QiEte«¿á Eátetóftte
ünti-táxn
DfStuerítffl) ‘* *fco
j: Km» 5&
s j** & .\V' '■ --
rtOTicta:
Oteen» « ( 1
Otearvadones i
7 DKMrtoGrpra GrttórUfet K¡ j Hora '□i
£ &.; Ftórtó jnu-J \i5tJ lerenda f kVktuefca
T DeswertoOrtcto . ftttóFtótó tíh‘ : EstadcCcja '£• <
Ftórtkáid p! >UTOX¿& ta.* ldtea< <
FttóMfco i(^^;
Mws Feteüntfc '
111. ¿JJxk
4' Sflñtío a
raxuqra
fttóCMÍO
Vnáfcrti |\wJ
Tátaarttó'v’ i
fafetaórtgái i
■ ¡
:
Se*/
SJF* pt* ■
, ^ÍJ
¿i
!(tí rJ
g ¿ fttóGtéo
ÜteRUfflto^

Rnrt&teteft ’;
$ fteítaK t-tk'
:I&nnd^¿ E ^h*4i
>)X k tedio
z~ r
J
fetaCqta
Iñafo r !'

taaarto
WrtQró
I Córtete,s5
»»
:suúrft'ú?

-; EttSjtó
Í. Jhro 7
Rtóó “
j Wttón <*£•* TiuflKSnto
tiptófal f ¡rafctswJT«¿; ■ 1ra r ■ A;ik1
irtütírtes ■. tóficfet 31

$
, ju.. í *V
Mhtafe. í^. StfturtAO. IvaHares j IctodgcBarraj
jggg. TopeOfeta ( jjK< í'-f’oo rtMfe ,■ .Jjgi ra^lQftód
$
Swgg" r cma
Fffmaoix l¡77 lítótófritó Strtutó ,L
l/¿
moOrata {^,o
77 'teí ‘itees^M 9 KñSSÍ<SI
JK catmií» IB bijpiffí.'^ís
r-
.^T.
afeitorouulH^u . SutwWt«$
: v títtót IdCcdgoBtór
yS hptaraSflrü ’
V" i £jodp6afra •■. íxitetó
tmWtoia ■*
fef ttóWotór Motes, L—,_.l Dftttrtó
45WW*’•■-’ V
* ♦ * k - V
4- **' Psaeo'"'’ í’
tes'

Retener jOnJjKSry
lílkfet.
35215
ággaíMga
WipcrtB"1 WJ'
Tiíft t
CrtóoCcrttesK
íhaan
)

& Víifel
5*1*
tí>
IcfnAjrftwT» ,2
•j

. «a
; ktataofcra

. Sefe
Feda
tíCodgcBana
atetó.

vstóí
1 RreóoGostc 1
4 Vitó3
ftedtfferte
Maqud
1
. Caitóad
14 Tetóal I i
I

Figura AxD.4. Modelo Entidad Relación