9 3 0 0 0 9

SEP SEIT 1

' 1 - - c 4 ' '$

-1 CENTRO NACIONAL DE INVESTIGACION Y - -

,_ --- 1 DESARROLLO TECNOLOGICO p: i~ 1 - --

METODOLOGIA PARA EL DIAGNOSTICO DE SISTEMAS DE SOFTWARE,

COMO UNA APORTACION EN AREAS

CENTRO DE INWRMACION C E N I D E T T E S I s -

P A R A O B T E N E R E L G R A O O D E

' M A E S T R O E N C I E N C I A S D E L A C O M P U T A C I O N P R E S E N T A :

EULALiO CARDONA AJURIA

Cuernavaca, Mor. Marzo de 1993

81Bp,rsmm N A c l o r w De m s ~ ~ m o s mcNou>mm Centro Nacional de Investigación y Desarrollo Tecnológico

ACADEMIA DE LA MAESTRIA EN CIENCIAS DE LA COMPUTÁCION

Cuernavaca, Mor., a 1s de enero de 1993.

D r . Juan Manuel Ricafío Cas t i l l o Director del CENIDET P r e e e n t e .

At'n.: M.C. Luis Garcia Gutiérrez Jefe del Depto. de Computation.

Por e s t e conducto, hacemos de eu conocimiento que después de - haber sometido a revisidn e l t rabajo de tesis t i tu lado:

"I4ElODOUXIA PARA EL DIAGNOSTICO DE SIsTIeIAS DE COmARE. COK) UNA AWRTACION EN AREAS ABIERTAS DE INVESTIGACION"

Desarrollado por e l ING. =IO CARDONA AJURIA y habiendo cumplido con todas las correcciones que s e l e indicaron, estamos de acuerdo en que 00 le conceda l a autorizaci6n de impresi6n de la t e s i e , y la fecha de examen de grado.

Sin o t ro par t icu la r , quedamos de usted.

A t e n t a m e n t e

Comiaión Revisora

/lrr . Interior Internado P a l m i SN C.P. 62490

Apartado Postal 5-164, C.P. 62050 Cuemavaca. Mor. México Tels.: (73) 18 77 41 y (73) 12 76 13 cenidet /

Centro Nacional de Investigación y Desarrollo Tecnológico

DI RECC I ON COORDINACION ACADEMlCA OFICIO No. SDC-051/93

Cuernavaca, Mor., a 4 de marzo de 1993.

ING. EULALIO CARDONA AJURIA CANDIDATO AL GRADO DE MAESTRO EN CIENCIAS DE LA COMPUTACION P R E S E N T E .

Después de haber sometido a revisión su trabajo de tesis titulado:

" METODOLOGIA PARA EL DIAGNOSTICO DE SISTEMAS DE SOFTWARE COMO UNA APORTACION EN AREAS ABIERTAS DE INVESTIGACION "

Y habiendo cumplido con todas las indicaciones que el Jurado Revisor de Tesis l e hizo, se le comunica que se le concede autorización para que pro- ceda a la impresidn de la misma, como requisito para la obtención del gra- do.

n

CIENC S COMPUTACIONALES ~~ P

Interior Internado Palmira SIN C.P. 62490 Apartado Postal 5-164, C.P. 62050 Cuernavaca. Mor. México

Tels.: (73) I8 77 41 y (73) I2 76 13 cenidet /

DEDICO EL PRESENTE TRABAJO:

A mi esposa Virginia Salas de la F. y a mis hijos

Oscar S. y Erika N., por su comprensi611 y sacrificio.

Con profundo cariño a mis padres Antonino Cardona S.

y Amelia Ajuria R., por su confMza y apoyo.

A mis compañeros y amigos del Instituto de Investigaciones

Eléctricas y Cenidet, que de una manera u otra, me brindaron

su apoyo y valiosos consejos.

MIS AGRADECIMIENTOS:

Al M. C. Moist% Gonzáiez Garcia, por su gran labor

en la supervisión de este trabajo.

A los miembros del jurado revisor del CENIDET, por su

paciencia y valiosos comentarios realizados.

En especial, ai Ing. Jesús Nena Cano, que de manera

desinteresada deposit6 toda su confianza en mi para

lograr un nuevo objetivo.

Al Instituto de Investigaciones El&rkas @E),

ai Banco de México, ai Consejo Nacional de Ciencia

y Tecnologfa (CONACYT) y al Centro Nacional de

Investigación y Desarrollo Tecnológico (CENIDET)

por su apoyo que hizo posible la realización del

presente trabajo.

CONTENIDO

I

1

4 4 5 5 1.2.1 Necesidad de una metodología para realizar el diagnóstico de un

1.2.2 Procedimientos y tknicas necesarias para el diagn6stico 6

1.2.3 Herramientas necesarias 6 1.2.4 El modelo y relaciones entre sus componentes 6

INTRODUCCION

CAPITULO 1. POSTULADO DEL PROBLEMA 1 . 1 DESCRlPCION DEL PROBLEMA 1.2 EL ENTORNO GLOBAL DEL PROBLEMA

sistema de sofiware

y su validación

CAPITULO 2. DEFINICION DEL MODELO PARA EL DIAGNOSTICO 7 7 2.1 IDENTIFICACION DEL UNIVERSO DE METRICAS EXISTENTES

2.1.1 Metricas de calidad del producto 2.1.2 Métricas de calidad del proceso de desarrollo del software

2.2 CLASIFICACION DE LAS METRICAS EXISTENTES 2.2.1 Métricas de tamaño 2.2.2 M&icas de estructuras de datos y flujo de datos 2.2.3 Métricas de estructuras de control de programa 2.2.4 Metricas hlbridas de complejidad

2.3 SELECCION DE LAS METRICAS A UTILIZAR EN EL MODELO 2.3.1 Criterios de selección

2.4 ORGANIZACION Y RELACIONES ENTRE LAS METRlCAS SELECCIONADAS

I 8 10 10 10 10 10 12 12 17

CAPITULO 3. DESARROLLO DE LA METODOLOGIA PARA EL DIAGNOSTICO 19

19

19 20

22 3.1.3.2 El modelo de costos constructivo (COCOMO) 25

3.1.4 Descripción del procedimiento de diagn6stico 26 3.1.4.1 ETAPA 1: Análisis del código fuente 26 3.1.4.2 ETAPA 2: Análisis de requerimientos adicionales a los satisfechos 27

3.1.4.3 ETAPA 3: Análisis de requerimientos del nuevo sistema 27 3.1.4.4 ETAPA 4: Estimaci6n de costos de reparación del sistema existente 27

3.1.4.5 ETAPA 5: Estimación de costos para el desarrollo del nuevo sistema 28

3.1.4.6 ETAPA 6: Evaluación de las alternativas 28 3.1.4.7 ETAPA 7: Selección de la alternativa 28

DEL SISTEMA DE SOFTWARE

EL DIAGNOSTICO 3.1 ESTRUCTURA DE LA METODOLOGIA PARA REALIZAR

3. t. 1 Identificación de las etapas del proceso 3.1.2 Desarrollo del modelo de la metodología para el diagnóstico 3.1.3 Herramientas utilizadas 22

3.1.3.1 El programa analizador del código fuente

con el sistema existente

(ALTERNATIVA 1)

(ALTERNATIVA 2)

CAPITULO 4. APLICACION DE LA METODOLOGIA 4.1 MARCO D E S X F " 0 DEL SISTEMA EXISTENTE

4.1.1 Estructura general 4.1.2 Alcances y limitaciones

4.2 DIAGNOSTICO DEL SISTEMA 4.2.1 Determinación de la magnitud de reparación del sistema existente

4.2.1.1 Análisis del d i g o fuente (ETAPA 1) 4.2.1.2 Análisis de requerimientos adicionales a los satisfechos

4.2.1.3 Criterios utilizados para estimar la magnitud de reparación

4.2.2.1 Análisis de requerimientos del nuevo sistema (ETAPA 3) 4.2.2.2 Criterio utilizado para estimar el tamaño del nuevo sistema

con el sistema existente (ETAPA 2)

del sistema existente 4.2.2 Detenninación del tamaño del nuevo sistema

4.3 ANALISIS DE COSTOlBENEFICIO

29 29 29 31 34 35 35 38

38 ?

41 43 44 44 1

!

4.3.1 Determinación de costos para la reparación del sistema existente (ETAPA 4) 44 1 4.3.2 Determinación de costos para el desarrollo del nuevo sistema ETAPA 9 55 4.3.3 Análisis de costos de mantenimiento

4.4.1 Evaluación de alternativas (ETAPA 6) 4.4.2 Selección de la alternativa apropiada(ETAPA 7)

4.4 ANALISIS DE ALTERNATIVAS

CAPITULO 5. VALIDACION DE LAS METRICAS UTILIZADAS 5.1 EL EXPERIMENTO DE VALlDAClON

5.1.1 Definición del experimento 5.1.2 Planeación del, experimento 5.1.3 Operación del experimento

5.2.1 Criterio de definición de niveles de calidad 5.2.2 El analizador del d i g o fuente

5.2 LOS NIVELES DE CALIDAD DEL CODIGO FUENTE

60 69 69 70

71 72 72 72 73 74 74 75

77 78

78 79

CAPITULO 6. CONCLUSIONES 6.1 APORTACION DEL TRABAJO EN LAS AREAS ABIERTAS

DE INVESTIGACION 6.1.1 Identificación de las áreas de investigación 6.1.2 Descripción de las aportaciones del trabajo

ANEXOS ANEXO A: REPORTES

REPORTE 1: Llamado de subrutinas del universo de Módulos REPORTE 2: Análisis del código fuente del universo de Módulos REPORTE 3: Parámetros de desarrollo del universo de módulos REPORTE 4: Parámetros de desarrollo (módulos de mala calidad,

con nivel = 1) ANEXO B: BIBLIOGRAFIA ANEXO C: BREVE DESCRIF'CION DEL MODELO DE COSTOS

CONSTRUCTIVO (COCOMO), HERRAMIENTA PARA ESTIMACION DE COSTOS DE DESARROLLO DE SOFTWARE

80 81 83 85 87

88 105

i

Una de las funciones principales del Instituto de Investigaciones Electricas @E), es la realización y promoción de la investigación aplicada relacionada con la innovación tecnológica en la industria eléctrica, por ello, potencialmente requiere del desarrollo de software como herramienta indispensable en el apoyo de los proyectos que realiza su cuerpo de investigación. En sus 15 &os de existencia, el iiE ha experimentado un crecimiento general, así como en la complejidad de los proyectos que realiza, lo cual ha exigido ampliar y10 mejorar su infrmtructura computacional. La necesidad de contar con herramientas de software de manera inmediata, en algunos casos ha conducido al desarrollo desordenado y deficiente de sistemas de software que m& tarde requieren de mucho esfuerzo para su mantenimiento. Mejoras que se realizan sobre la marcha, son la causa de que los sistemas se degraden enormemente incrementando su complejidad y reduciendo su ciclo de vida útil.

La realización de este trabajo, surgió precisamente con el objeto de proporcionar un mecanismo que permita diagnosticar un producto de software. Se consideran técnicas basadas en mediciones de la complejidad del código, como una manera de medir la calidad del producto. Aquí es válida la aplicación de la frase siguiente: “no puede controlarse algo que no puede medirse”; para poder medir la calidad del producto, principalmente el código, se ha recurrido a la utilización de las m&icas, las cuales son simplemente mediciones cuantitativas de ciertas características (en este caso del código como producto). Por lo tanto, las metricas, cuando son usadas apropiadamente, conforman UM herramienta idónea para controlar la calidad del código fuente de programas, para ello, debe entenderse perfectamente lo que se desea medir y cómo hacerlo.

Por lo anterior, ha surgido la necesidad de controlar la calidad del software durante su etapa de desarrollo, definiendo a la calidad como “adecuado para usarse”. Por lo tanto, los productos o sistemas adecuados para usarse contienen los siguientes atributos:

a) Cuestan lo que el cliente puede pagar. b) Tienen las características más deseadas por el cliente. c) Son fáciles de instalar y operar. d) Su desempeño es de acuerdo a lo que espera el cliente. e) Son confiabl&. fj Están bien documentados. g) Son fáciles de corregir y mantener.

2 - Lo anterior, proporciona la pauta para definir las áreas a considerar para poder evaluar la calidad

de un produdo, desde el punto de vista adecuado para usarse, dichas consideraciones son las siguientes:

1. Mantenibilidad 2. Rasgos distintivos (funciones) 3. costo

. Compra . Operación Q 5. Desempeilo 4. Interfaz con el hombre

. Capacidad

. Tiempo de respuesta 6. Confiabilidad . Tiempo medio entre fallas . Tiempo medio para recobrarse

. Tiempo medio para regararlo 7. Tam& 8. instalabilidad 9. Documentación

En el caso presente en particular, se considera software de calidad, aquel que satisfaga las tres primeras consideraciones indicadas arriba (mantenibilidad, rasgos distintivos y costo). Esto es, que el software sea fácii de comprender y modificar, lo cual implica que sea mantenible; que contenga las características deseadas por el cliente y cuyo desempeilo sea de acuerdo a sus expectativas o rasgos distintivos, y que cueste lo que el cliente puede pagar (tanto para la compra, como para su operación).

Existen varios procedimientos propuestos para medir la complejidad del software; sin embargo, algunos de ellos s610 son teorías; otros, están enfocados a medir el diseño, su estructura, etc. En el presente estudio, la complejidad del software es medida desde su tamaño físico, en número de líneas de código fuente ejecutable (NLCFE) y desde el número de nitas de flujo de control del programa o complejidad ciclomática (v(G)).

La secuencia que mantiene la organización de este documento es la siguiente: inicialmente, en el capítulo 1, se proporciona el marco general del problema, en él, se plasman someramente las características y componentes del sistema problema, especificando las funciones de cada una de ellas. Como parte de su solución, también se plantea la necesidad de contar con ciertos elementos de inter6 como: metodologías, procedimientos, herramientas y modelos.

En el capítulo 2, como parte de la definición de un modelo para realizar el diagnóstico de un sistema de software, se lleva a cabo la identificación de las características cuantitativas medible de un sistema, denominadas “métriricas de calidad del software”. Se presenta una descripción de estas métricas, desglosadas en metricas de calidad del producto y métricas de calidad del proceso de desarrollo. También se presentan las clasificaciones existentes en la bibliografía, de estos dos tipos de métricas. Finalmente, se describen los criterios establecidos para llevar a cabo la seleccidn de las métricas para medir la calidad del software.

El contenido del capítulo 3 se refiere al desaqollo de la metodología para el diagnóstico de un sistema de software; en él, se propone una estructura de dicha metodología, segmentada en tres grandes fases, que a la vez, cada UM de ellas consta de diversas etapas. Se incluye también, una descripción de las herramientas utilizadas en el modelo de diagnóstico, consistente en un analizador

3

de cddigo fuente y un modelo para estimación de costos de desarrollo de proyeaos de software. Como parte final del capítulo, se plantea un procedimiento de diagnóstico que describe, someramente, cada UM de su8 etapas.

El capítulo 4 comprende la parte medular del trabajo, donde se presenta la aplicación de la metodología desarrollada en el capítulo anterior; aquí se presenta la estructura general del Sistema de información para el apoyo a la Evaluación de la Gestión Operativa (SiAGO), se incluyen SUS alcances y limitaciones. Como parte del diagnóstico, se presenta la aplicación de la metodología para determinar la magnitud de reparación necesaria al sistema existente y la determinación del tamailo del nuevo sistema. Se incluye, a d d , el análisis costoheneficio llevado a cabo a las siguientes dos alternativas: reparar el sistema existente 6 desarrollar un nuevo sistema; en función de este análisis, se evaliian las alternativas y se selecciona la más apropiada.

El captítulo 5, incluye la descripción de la definición, planeación y operación de un proceso experimental llevado a cabo para validar.las metricas utilizadas en la medición de calidad del software. Concretamente, se enuncian aquellos aspectos estadísticos cuya interpretación de resultados permiten determinar el comportamiento de las características del software analizado, que gracias a ellas es posible ubicar los módulos del sistema en determinados niveles de calidad.

Finalmente en el capítulo 6, como conclusiones derivadas del presente trabajo, se resumen las implicaciones generadas por el desarrollo del software sin una disciplina y se establecen las técnicas de desarrollo del software que pueden utilizarse para obtener productos de s o h a r e de buena calidad. Adicionalmente, el capítulo incluye la identificación de áreas abiertas de investigación y asimismo, una descripción de las aportaciones del presente trabajo en dichas áreas de investigación.

Adicionalmente, se incluyen tres anexos; el primero consiste de 5 reportes, 4 de ellos fueron generados por el programa analizador del d i g o fuente, aplicado al Sistema de Información para el Apoyo a la evaluación y Gestión Operativa; en el segundo anexo se presenta la bibliografía comentada de aquellos artículos y libros consultados; el tercer anexo es una descripción breve del modelo de costos constructivo, herramienta utilizada para la estimación de costos de desarrollo de software.

4

CAPITULO 1

POSTULADO DEL PROBLEMA

En el presente capítulo, se brinda una descripci6n del problema que originó la necesidad de desarrollar una metodología para diagnosticar un sistema de software. Asimismo, se vislumbra la necesidad de tomar en cuenta otros elementos que participan en el proceso de su solución, tales como procedimientos, técnicas, herramientas y modelos. De una manera integrada, la metodología y los elementos, defmen las bases para llevar el problema a su solución.

Antes de entrar en detalle de lo descrito anteriormente, se presentan de manera breve, las características principales del sistema de software que ha dado origen al problema.

Actualmente se cuenta con una herramienta computacionai consistente en un conjunto de programas en lenguaje de programacidn FORTRAN-77, desarrollados en una minicomputadora VAX 1 li78O que corren bajo el sistema operativo VMS ( V i a l Memory System), en un ambiente multiusuario. La herramienta se le denomina "Sistema de Información para el Apoyo a la Evaluación y Gestión Operativa" (SIAGO). Se utiliza en la integración de la información básica consistente en contratos, proyectos y facturación (en la sección 4.1, del capítulo 4, se presentan en mayor detalle las características del SIAGO).

Los resultados obtenidos con la herramienta indicada arriba son reportes y gráficas utilizados en el análisis de evaluación institucional (evolucib, crecimiento, trayectoria, mercado, Hc.) a través de sus proyectos de investigación.

1.1 DESCRIPCION DEL PROBLEMA

Con el sistema mencionado anteriormente, se almacena y procesa la informacicín recopilada durante 16 &os (1977 a 1992). Debido a este volumen de información y al incremento de objetivos funcionales agregados sin previa planeación, sin un diseño adecuado y el desarrollo desordenado de la programación, bay limitaciones en las funciones y eficiencia del sistema computacional. Para reducir tales limitaciones se ha planteado reparar dicho sistema, pero antes de tomar esta decisión. se tiene contemplado evaluar la factibilidad para efectuar su reparación 6 el desarrollo de un nuevo sistema que sustituya al existente.

El criterio para tomar una decisión de esta índole debe estar fundamentado por elementos visibles y las características relacionadas con la calidad del sistema.

5

1.2 EL ENTORNO GLOBAL DEL PROBLEMA

Para abordar un problema, con frecuencia es necesario considerar por partes las cuestiones asociadas a él, de aquellos elementos que jerarquicen los conocimientos y formas de hacer las cosas que sean útiles en la práctica. Actualmente, debido a que la ingeniería de software (como ciencia) aún es muy joven, s610 se cuenta con métodos ad-hoc que ayudan a resolver problemas [51], lo cual obliga a buscar nuevas soluciona basadas en metodologías, procedimientos. técnicas, métodos, herramientas y modelos.

Los problemas más significativos que se presentan para tomar la decisión de reparar el SIAGO o desarrollar un nuevo sistema, son los siguientes:

a) La necesidad de una metodología para realizar el diagn6stico de un sistema de software. a. 1) El modelo para el diagnóstico y las relaciones entre sus componentes. a.2) Procedimientos y técnicas necesarias para el diagnóstico y su validaci6n. a.3) Herramientas necesarias.

Estos problemas son descritos en las siguientes 4 secciones:

1.2.1 NECESIDAD DE UNA METODOLDGIA PARA REALIZAR EL DIAGNOSTICO DE UN SISTEMA DE SOFTWARE

Toda actividad implica la utilización de recursos y procedimientos que establecen una secuencia para alcanzar su objetivo.

Tomar una decisib como la indicada en la sección 1.1, no es trivial, se requiere de una serie de procedimientos, herramientas y recursos o materia prima que en conjunto, forman la metodología necesaria.

Se prevee que dicha metodología debe contemplar 3 fases:

1. FASE DE DIAGNOSTICO, que permita identificar aspectos críticos que brinden un panorama sobre la calidad del código fuente y la documentación del sistema. y con ello, determinar la magnitud de su reparación.

FASE DE GENERACION DE ALTERNATIVAS, que proporcione un mecanismo para determinar el costo que implica la reparación del SIAGO y el costo para desarrollar un nuevo sistema.

3. FASE DE EVALUACION DE ALTERNATIVAS Y SELECCION DE LA MAS APROPIADA, que brinde un procedimiento y los elementos necesarios para evaluar las alternativas, y de ahí, seleccionar la más indicada.

2.

Para lograr el objetivo, la metodología debe aplicarse siguiendo cada una de las fases antes mencionadas y en el orden indicado. La utilización de la metodología adecuada es una garantía para que todo individuo interesado en un objetivo pueda obtener los resultados correctos.

6

1.2.2 PROCEDIMIENTOS Y TECNiCAS NECESARIAS PARA EL DIAGNOSTICO Y SU VALIDACION

Conocer la secuencia o procedimientos que deben emplearse para realizar alguna tarea es, sin duda, un problema que debe analizarse para obtener el resultado esperado. Es común encontrar técnicas ya establecidas incluyendo herramientas, recursos y un conjunto de procedimientos apropiados. Por lo general tales técnicas consideran, además, maneras de utilizar dichos procedimientos, hasta lograr una habilidad en el uso de ellos.

Es importante identificar las posibles técnicas que puedan servir de base en la aplicación de la metodología a utilizar, dentro de cada UM de sus fases. Estas técnicas, no obstante, deben ser validadas para garantizar que durante su aplicaci6n se obtengan los resultados esperados, aún si la técnica es aplicada una y otra vez.

El proceso de validación es un problema que también debe analizarse con mucho detenimiento, ya que de su empleo correcto depende la confiabiiidad de sus resultados e interpretación. Del resultado de la validaci6n de las tecnicas, pueden surgir herramientas que pueden ser útiles en la solución de problemas, con menor costo y esfuerzo.

1.2.3 HERRAMIENTAS NECESARIAS

Dentro del ambiente cornputacional, es indispensable el uso de un conjunto de instrumentos que permitan r e a i i i varias funciones en un t¡mpo corto, con buena exactitud y disminuyendo el esfuerzo. Con el equipo de dmputo necesario y el lenguaje de programación o paquetes de c6mputo apropiados, puede generarse una herramienta @or ejemplo, un analizador de código fuente) que de manera automática ayude a usar los pmedim¡entos adecuados para obtener resultados a partir de la materia prima necesaria.

El problema de contar con tales herramientas implica, en ocasiones, un cierto costo para su adquisición, el tiempo necesario para su asimilaci6n 6 el tiempo y equipo necesario para su desarrollo.

1.2.4 EL MODELO Y RELACIONES ENTRE SUS COMPONENTES

Determinar el comportamiento de los componentes que intervienen en un procedimiento no es tan simple, en muchas ocasiones se pierde la dimensión de ellos. AI enmarcarlos dentro de un modelo se facilita su comprensi611 y el eshidio de su comportamiento, permite visualizarlos como un sistema o una realidad, aunque ésta sea compleja.

El diseiio de un modelo tampoco es sencillo, se requiere de conocimientos algunas veces profundos. Sin embargo, su uso permite manejar diversas dimensiones de un sistema, y además, permite enfocar la atención en aquellos puntos críticos de interés.

En el caso del diagnóstico de un producto de software, un modelo puede contribuir, al mostrar c6mo al variar los factores que intervienen en el desarrollo del software, aumentan o disminuyen su complejidad.

CAPITULO 2

DEFINiCION DEL MODELO PARA EL DIAGNOSTICO

Para concebir el proceso de diagnóstico de un sistema, es clara la necesidad de defmir un modelo que represente a un sistema computacional, el cual está constituído por una serie de características cuantitativas interrelacionadas por una serie de reglas. Estas reglas, al aplicarse a un conjunto de valores (medidos o estimados) de las características elegidas, representarán la apariencia o el comportamiento del sistema. Llamaremos aquí las características cuantitativas con el término de métricas.

Dado el problema que nos interesa resolver, es clara la necesidad de encontrar un conjunto de métricas que permitan detectar las diversas anomalías o deficiencias en el &ligo fuente del sistema problema, en este caso del SIAGO. Al respeao, no hay una métrica que pueda proporcionar una medición universal de la calidad del software, ya que las metricas &lo identifican anomalías individuales. Por lo tanto, es necesario considerar varias métricas o una combinación de ellas.

Como las métricas miden cuantitativamente el grado en que un programa tiene asociada alguna característica, algunas de ellas llegan a estar en conflicto, es decir, al mejorar una característica, se deteriora otra. Esta será la raz6n de ser del modelo, que permita identificar las relaciones entre ellas y visualizar anticipadamente los conflictos existentes.

2.1 IDENTIFICACION DEL UNIVERSO DE METRICAS EXISTENTES

En general la calidad se puede enfocar hacia dos aspectos diferentes: el producto y el proceso. Esto conduce a la necesidad de identificar aquellas métricas para medir la calidad del producto y aquellas que permitan medii la calidad del proceso de desarrollo.

2.1.1 METRICAS DE CALIDAD DEL PRODUCTO

Son aquellas métricas más dir- que pueden ser aplicadas a un producto de software, puesto que se cuenta con el código o documentación en forma física para su evaluación.

El universo de métricas que pueden aplicarse a un producto se enuncian en la lista siguiente:

a) METRiCAS DE LINEAS DE CODIGO, determinan el n h e r o de líneas de código fuente ejecutable que contiene un programa, el conteo no considera las líneas de la sección de declaración de datos ni las líneas de comentarios [is].

8 b) METRICAS DE LA CIENCIA DEL SOFTWARE, tambih se les denomina "Metricas de

Halstead" [41. Con base en el conteo de operadores y operandos puede determinarse el tamaño de un programa, el espacio necesario para almacenarlo y el esfuerzo y tiempo requerido para desarrollarlo 151, 1251.

c) MEIñICAS DE CONFIGURACION Y USO DE DATOS DENTRO DE UN PROGRAMA, miden la complejidad de la manera en que los datos en un programa son usados u organuados [ 151.

d) METRICAS DE LA COMPLEJIDAD CICLOMATICA DE McCABE, se utilizan para medir y controlar el número de rutas dentro de un programa. Permiten limitar el tamaño de un programa con un número igual a 10, que representa el número de instrucciones de decisión y ciclos. Esto facilita que los programas puedan ser probados y mantenidos [3],

e) METRICAS DE LA COMPLEJIDAD LOGICA DE GILB, permiten medir el número de 1151.

decisiones lógicas que se hacen dentro de un programa [is]. f ) CONTEO DE NUDOS DE WOODWARD, HENNELL Y HEDLEY, son métricas utilizadas para examinar las relaciones entre las localizaciones ffsicas de las transferencias de control [15].

complejidad topológica de las estructuras de control anidadas. Esta métrica está basada en las metricas de McCabe [15].

g) MEDICION DE CHEN DE LA COMPLEJIDAD DE PROGRAMAS, determina la

h) MEDICIONES DE COMPLEJIDAD DE HANSEN, combina la complejidad ciclomática de McCabe y el conteo de operadores, similar al número de operadores de Halstead [15].

i) MEDICION DE COMPLEJIDAD DE PROGRAMAS CON EL MODELO DE OVIEDO, se emplea para obtener la complejidad del flujo de datos y la complejidad del flujo de control a través de grafos [15].

j) MEDICIONES DE LA CIENCIA DEL SOFTWARE COMBINADO CON EL NUMERO CICLOMATlCO Y EL NIVEL DE ANIDAMIENTO, permiten obtener mediciones de la complejidad del software combinando las mediciones de la ciencia del software, la complejidad ciclomática de McCabe y el nivel de anidamiento [36].

2.1.2 METRICAS DE CALIDAD DEL PROCESO DE DESARROLLO DE SOFTWARE

Las métricas pueden aplicarse para determinar la calidad del software a través de cada paso del proceso de su desarrollo (definición de requerimientos, diseño, implementación, operación y mantenimiento).

Para obtener un producto de calidad debe mejorarse el proceso de su desarrollo; esto puede lograrse, por un lado, al establecer objetivos explícitos de la calidad del software, por el otro lado, a través del uso de tecnicas y herramientas que incrementen la calidad.

El grado de calidad'que una persona pone dentro de un programa, es el grado en que pueden alcanzarse los objetivos de calidad deseados. Por eso es importante decirle al desarrollador qué g r a o de calidad se desea para el producto final.

9 Durante el proceso de desarrollo, no siempre pueden utilizarse métricas para incrementar la calidad

del producto; por ejemplo, no pueden obtenerse mediciones numéricas de la calidad presente en la fase de detinición de requerimientos y diseño, sólo pueden identificarse problemas crfticos. Como ejemplo puede mencionarse la defectuosa expresión o ambigüedad de los requerimientos o un diseño incompleto. En la fase de implementación, sí puede mejorarse la calidad al utilizar métricas en la evaluación e incremento de la calidad del código, desde el punto de vista de su estructura y el contenido de información sobre el código (comentarios).

Las m&ricas que pueden aplicarse durante el proceso de desarrollo son:

a) METRlCAS DE LA CIENCIA DEL SOFIWARE, ya indicadas en la sección 2.1.1.

b) NUMERO DE DEFECTOS, son aquellas métricas que en función del número de líneas del código fuente, puede estimarse la cantidad de defectos que contendrá el software después de su implementación [14], [29].

c) INTENSIDAD DE FALLAS, permite determinar el número de fallas a través del tiempo de ejecución de un programa [241.

d) MEDICION DE LA PRODUCTIVIDAD DE DESARROLLO, consiste en definir y medir un producto y el costo. El costo del producto es medido con base en el número de entradas, preguntas, salidas y el número de archivos maestros entregados [59].

e) METRlCA DE WOODFIELD, mide la cantidad de tiempo que un programador debe invertir en cada procedimiento para entender el programa completo. La medición se hace por medio de la estructura de llamado de procedimientos [IO].

fj METRlCAS DE COMPLEJDAD DE MODULOS Y PROCEDIMIENTOS, se emplean para medir la fuena entre los módulos, considerando el flujo de información entre los componentes del sistema. Los elementos que se toman en cuenta son: módulos del sistema, estructuras de datos y conexiones entre m6dulos, estas mediciones son aplicadas al diseño 1131.

g) MEDICIONES DEL DISENO, son obtenidas a travk de mediciones de la complejidad estructural, complejidad del flujo de información y de la complejidad de estructuras de datos [43].

h) MEDICION DE LA COMPLEJIDAD ESTRUCTURAL DE PROGRAMAS, considera la complejidad de los componentes de un programa como los procedimientos, estructuras de datos, conexiones entre esios componentes y llamados a procedimientos 1441.

i) METRiCAS DEL DiSEfiO DE PROGRAMAS, son utilizadas para obtener la complejidad de los programas a partir de documentos de especificación de diseño o pseudocódigo. La complejidad es medida considerando el conteo de líneas y tokens del pseudocódigo 1471.

j) METRICAS DE CALIDAD DEL SOFTWARE DESDE EL DISEñO GRAFICO, pueden obtenerse mediciones del &digo (número de líneas, algunas métricas de Halstead y complejidad ciclomática); metricas de estructura (del flujo de información e invocación de un módulo), y métricas hfbridas (métricas del flujo de información y metricas de Woodfield). Para obtener estas mediciones, se toma wmo entrada un d i s h gráfico o código fuente 1521.

10

2.2 CLASIFICACION DE LAS METRICAS EXISTENTES

Con el fin de agrupar las metricas desde el punto de vista en que serán aplicadas en el presente problema. se presenta la clasificación propuesta por Warren Harrison, Kenneth Magel, Raymond Kluczny y Arlan DeKock [15]. Estas métricas de complejidad del software son utilizadas en el mantenimiento de programas, por tanto son aplicables a un producto de software. No obstante, algunas también pueden ser aplicables al proceso de desarrollo.

La clasificación de las métricas propuesta es la siguiente:

a) Metricas de tamao. b) Métricas de estructuras de datos y flujo de datos. c) Métricas de estructuras de control del programa. d) Métricas hlbridas de complejidad.

2.2.1 METRICAS DE TAMAÑO

Son aquellas que obtienen conteos del número de líneas de código, conteos de tokens, y conteos de operadores y operandos.

2.2.2 METRICAS DE ESTRUCTURAS DE DATOS Y FLUJO DE DATOS

Son aquellas mediante las cuales puede determinarse la complejidad del software con base en las estructuras de datos y al flujo de información entre los componentes de un sistema.

2.2.3 METRICAS DE ESTRUCTURAS DE CONTROL DEL PROGRAMA

Son las métricas util¡zadas para determinar la complejidad debido al flujo de control del programa como: ciclos, decisiones lógicas y llamados de procedimientos.

2.2.4 METRICAS HIBRIDAS DE COMPLUIDAD

Son aquellas que consideran una combinación de metricas de tam&, de estrumras de datos y flujo

La clasificación anterior agrupa las metricas en función de las características que miden. En la tabla 2.1 se presenta la clasificación de las metricas de calidad del producto, mientras que las de calidad del proceso, son mostradas en la tabla 2.2.

de datos y de estructuras de control del programa.

TABLA 2.1 CLASIFICACION DE LAS METRiCAS DE CALIDAD DEL PRODUCTO

CLASIFIC ACION

1.DE TAMAÑO

2.DE ESTRUCTURAS DE DATOS Y FLUJO DE DATOS

3.DE ESTRUCTURAS DE CONTROL DE PROGRAMA

4.HIBRiDAS

METRICAS

. Métricas de líneas de código

. Métricas de la ciencia del software

. Métricas de configuración y uso de datos dentro de un programa

. Méiricas de la complejidad ciclomática de

. Métricas de la complejidad lógica de Gilb

. Conteo de nudos de Woodward,Hennell y

. Medición de Chen de complejidad de

McCabe

Hedley

programas

. Mediciones de complejidad de Hansen

. Medición de complejidad de programas con

. Mediciones de la ciencia del software el modelo de Oviedo

combinado con el número ciclomático y el nivel de anidamiento

TABLA 2.2 CLASIFICACION DE LAS METRICAS DE CALIDAD DEL PROCESO

CLASIFIC ACION

1. DE TAMAÑO

2. DE ESTRUCTURAS DE DATOS Y FLUJO DE DATOS

3. DE ESTRUCTURAS DE CONTROL DEL PROGRAMA

4. HiBRiDAS

METRiCAS

Métricas de la ciencia del software Número de defectos Intensidad de fallas Medición de la productividad de desarrollo Métricas del diseño de programas

Ya consideradas dentro de las m&r¡cas hlbridas (clasificación 4)

Métricas de Woodfield

Métricas de complejidad de módulos y procedimientos Mediciones del diseño Medición de la complejidad estruaurai de Programas Métricas de calidad del software desde el diseño gráfico

12

2.3 SELECCION DE LAS METRICAS A UTILIZAR

2.3.1 CRITERIOS DE SELECCION

Pueden surgir varios criterios para realizar la selección de las métricas a utilizar, las m&ricas m a objetivas son:

a) Métricas que permiten medir las características del software. b) MBtricas que son simples de usar. c) Metricas con factibilidad de automatizar. d) Metricas con evidencia de utilidad práctica.

Las métricas que miden las características del software consisten en lo siguiente: primero, se identifica un conjunto de caracte.rísticas que son importantes en la calidad del software; luego, se clasifican de manera jerárquica de tal forma que las características ubicadas en el nivel m& bajo, asociadas al siguiente nivel alto o atributos, son condiciones necesarias para que contenga tal atributo. Por ejemplo, si se desea que el código sea comprensible, debe poseer las características de ser consistente, autodescriptivo, estructurado, conciso y legible. Dicho de otra manera, si el atributo principal que se desea del código es su comprensibilidad, primero debe contener las 5 características indicadas, y para saberlo, se buscan las métricas candidatas para evaluar el grado en que el software contiene asociadas tales características.

Para determinar los atributos del software: B. W. Boehm, J . R. Brown y M. Lipow [ll], proponen medir las características del software como se indica en la tabla 2.3.

Se dice que las métricas son simples de usar cuando no se requieren de medios sofisticados o costosos para obtener las mediciones, como por ejemplo, el contea de instrucciones fuente.

Las métricas con factibilidad de automatizar son aquellas que permiten medir las características del software de una manera automática, por ejemplo, con un analizador de d i g o puede obtenerse el nSmero de líneas de código, el conteo de tokens y el conteo de instrucciones de flujo de control.

Las metricas con evidencia de utilidad práctica son las que han probado ser útiles para medir las características del software y con ello incrementar la calidad del software.

13

TABLA 2.3

DESCRIF'CION DE LAS CARACTERiSTICAS DE CALIDAD DEL PRODUCTO PARA DETERMINAR LOS ATRIBUTOS QU

ATRIBUTOS DEL SOFTWARE I CARACTERISTICAS

COMPRENSIBLE CONSISTENTE (CN)

AUTO-DESCRrmnO (AD)

ESTRUCTURADO (ES)

CONCISO (CS)

LEGIBLE (LG)

MODIFICABLE

ESTRUCTURADO (ES)

EXTENDIBLE (EX)

PROBABLE

CUANTIFICABLE (CU)

ACCESIBLE (AC)

AUTO-DESCRIPTIVO (AD)

~

DEFINEN LA MANTENlBlLlDAD DEL SOFIWAR

DESCRIF'CION DE LAS CARACTERISTICAS DEL SOFTWARE

El código debe ser seguible basta sus requerimientos.

El código debe contener informaci6n o comentarios para el lector sobre los objetivos, suposiciones, res- tricciones, entradas, salidas, componentes y estatus de revisi6n.

El código debe contener un patr6n definido de la ~ganizacibn de sus partes interdependientes, además debe contener estructuras estándares de control.

El código no debe estar excesivamente fragmentado en módulos (supermodularizado), no deber haber código repetido en varios sitios.

Las funciones que realiza el código deben ser fácil- mente descifrables al ser leído (usar nombres mnem6- nicos de variables y usar paréntesis de ser necesarios).

Ya descrito arriba.

Los requerimientos de nuevas funciones o almacena- miento de datos deben ser fáciles de incorporar en sus componentes.

En el código debe poderse instrumentar pNebas para medir el tiempo de ejecuci6n de los programas.

El d i g o debe tener facilidades para el uso selectivo de sus partes (estructuras de datos).

El c6digo debe facilitar la especificación de entradas y proporcionar salidas cuya forma y contenido sean fáciles de asUnilar y usar.

Ya descrito arriba.

Ya descrito arriba.

o, O O O M Q

6

s: it-

z - - 2 t(= O W c w U

14 Como se observa en la tabla anterior, la caraterística de estructurable es indispensable para los tres

atributos (para ser comprensible, modificable y probable).

Como resultado, si el d i g o cumple con las características especificadas en la tabla 2.3, los atributos implicarían lo siguiente:

a) Para ser comprensible, el uso de los nombres de variables o símbolos deben ser consistentes, el código de los m6dulos son autodescriptivos y las estructuras de control utilizadas son simples de acuerdo con los estándares.

b) Para ser modificable, los cambios deben incorporarse fácilmente, una vez que &tos han sido determinados.

c) Para el caso del software probable, implica que el código posee facilidades para establecer criterios de verificación y evaluación de su calidad. Ello implica que los requerimientos son alcanzados en módulos específicos, o que puede agregarse capacidad de diagnóstico.

Finalmente estos atributos, en su conjunto, permitirán determinar la mantenibilidad de un sistema, lo cual implicaría, de ser así, gran facilidad para amalizarlo y satisfacer nuevos requerimientos o corregir deficiencias.

En resumen, la mantenibilidad de un sistema de software, implica que su código sea comprensible, modificable y probable; esto es, contiene comentarios para localizar llamados de subrutinas y entradas, visualmente pueden localizarse instrucciones de ramificación, el programa debe estar disefiado para ajustarse dentro de recursos disponibles, con cierto margen para evitar mayores rediseños.

Hasta el momento se ha definido qué es lo que se va a medir; ha llegado el momento de elegir las posibles métricas a utilizar para determinar las características contenidas eo el software. Esto puede hacerse en 2 pasos, relacionados con los criterios de selección especificados al inicio de la sección 2.3.

PASO 1 Identificar las características que pueden ser medidas con alguna métrica existente. Para hacerlo, se hace una confrontación entre las características del software, con las métricas existentes aplicables a un producto; en la tabla 2.4, la relación métricaaracterística se obtiene marcando con "XX" (las características del software están indicadas en clave para reducir espacio, estas claves estan definidas en la tabla 2.3 indicadas entre paréntesis, despu& del nombre de la característica del software).

PASO 2 Seleccionar las métricas que cumplan con los 3 últimos criterios de selección (simples de usar, factibles de automatizar y con evidencia de utilidad práctica). La tabla 2.5 muestra lo dicho anteriormente.

15

TABLA 2.4

CONFRONTACION DE LAS MEWCAS DE CALIDAD DEL PRODUCTO CON LAS CARACTENSTICAS DESEABLES PARA EL MANTENIMIENTO DEL SOFTWARE

AD

xx

METRICAS DE CALIDAD DEL PRODUCTO

. Métricas de lfneas de &ligo

. Métricas de la ciencia del software

. Métricas de configuración y uso de datos dentro de un programa

. Métricas de complejidad ciclomática de McCabe

. Métricas de complejidad lógica de Gilb

. Conteo de nudos de Woodward, Hennell y Hedley

. Medición de Chen de complejidad de programas

. Mediciones de complejidad de I

CARACl

ES

xx xx xx xx xx xx

xx

*

CN - EX

xx xx

xx xx xx xx xx xx

xx

. Medición de complejidad de programas con el modelo de oviedo

. Mediciones de la ciencia del software combinado con el número ciclomático y el nivel de anidamiento

CU AC

:AS

LG - - xx

xx xx xx xx xx xx

- -

CO

EL SOFTWARE _I_

En la tabla anterior se observa que las características a medir por medio de las métricas son: lo esmcturado, lo conciso, lo legible y lo extendible de un sistema de software.

Lo conciso (CS), puede determinarse midiendo el grado de modularización, a través del conteo del número de líneas de código fuente por m6dulo.

Lo legible (LG), puede determinarse verificando si el código es descifrable, si se utilizan nombres mnemónicos de las variables, uso de paréntesis e indentaciones.

Lo extendible (EX), los m6dulos no deben ser muy complejos por tamaño o por sus esúucturas de control, con el fm de poder incorporar nuevas funciones de requerimientos adicionales.

Una variante del número de líneas de código fuente es la medición del porcentaje de comentarios, el cual puede indicar el grado de autodescripción, cuyo número aceptable de líneas de comentarios es del orden de 30-90%. En el caso presente apenas se alcanza un 13% de comentarios, lo cual indica que el SiAGO no es autodescriptivo.

16 TABLA 2.5

RELACION DE LAS METRICAS DEL PRODUCTO Y LOS CRiTERiOS DE SELECCION

METRICAS DEL PRODUCTO

Métricas de lfneas de Cddigo

Métricas de la ciencia del software

Métricas de la complejidad ciclomiitica de McCabe

Métricas de la complejidad lógica de Gilb

Conteo de nudos de Woodward, Hennell y Hedley

Medición de Cben de complejidad de programas

Mediciones de complejidad de Hansen

Medición de complejidad de programas con el modelo de Oviedo

Mediciones de la ciencia del software combinado con el número ciclomático y el nivel de anidamiento

CRlTERIOS DE SELECCION

SIMPLE AUTOMATIZ. CON EVIDENCIA

xx xx xx xx xx xx xx xx xx

xx xx xx

xx xx

xx xx xx

xx xx xx

En la tabla 2.5 puede observarse que las métricas que reunen los 3 criterios de selección son:

a) Las métricas de líneas de código fuente b) Las métricas de la ciencia del s o h a r e c) Las métricas de la complejidad ciclomática de McCabe d) Las mediciones de la ciencia del software combinadas con el número ciclomático y el nivel

de anidamiento

Sin embargo, las mediciones indicadas en el inciso d), de la lista anterior, es una combinación de las métricas del inciso b) y c) (también de la misma lista). Esto conduce a seleccionar las siguientes métricas:

1. Las métricas de líneas de código fuente 2. Las mediciones de la ciencia del software combinadas con el número ciclomático y el nivel

de anidamiento

17 Esta métricas seleccionadas serán de utilidad para determinar el tamail0 ffsico de los módulos, el

conteo de operadores y operandos, las estructuras de control y el nivel de anidamiento. Con ellas se podrá determinar si el SIAGO no está muy complejo y puedan agregarse funciones adicionales para considerar nuevos requerimientos.

2.4 ORGANIZACION Y RELACIONES ENTRE LAS METRlCAS SELECCIONADAS

En secciones anteriores (2.3.1), se ha establecido la necesidad de determinar el grado de mantenibilidad para estimar los costos de reparación del SiAGO. También se establecieron tres atributos del software para SU deteminación. A su vez, estos atributos utilizan características que deben ser medidas para conocer el grado en que están contenidas en el software. Finalmente, se seleccionaron las métricas apropiadas para obtener mediciones de las características indicadas.

A continuación se define un esquema (figura 2.1) que refleja la manera en que los atributos, características del software y las métricas, son organizados para determinar la mantenibilidad del software.

En la misma figura puede observarse la relación que existe entre los atributos, las características del sohvare y las métricas seleccionadas.

En primer lugar, se observa una relación jerkquica donde los atributos representan un alto nivel y las métricas, el nivel más bajo. El resultado de los niveles más bajos determinan los resultados del siguiente nivel más alto.

En segundo lugar, se observa que las métricas correspondientes a líneas de código, de la complejidad ciclomática de McCabe y las métricas de la ciencia del software, hacen una aportación muy importante a las características del software consideradas.

En tercer lugar puede observarse que la estrucairabilidad del software presenta, también, una aportación importante a cada uno de los tres atributos.

Independientemente de la participación de las métricas de la ciencia del software sobre las características del software consideradas, aquellas serán de gran utilidad en la estimación del esfuerzo y tiempo de reparación del SiAGO.

18

U N T E N I B L E

ATRIBUTOS

MODIFICABLE PROBABLE COMPRENSIBLE

C ARACTERISTIC AS

CONCISO ESTRUCTURADO EXTENDIBLE I I

METRICAS ,II

CICLOMATICA DEL SOFTWARE

FIGURA 2.1

MODELO PARA EL DIAGNOSTICO DEL SOFTWARE QUE MUESTRA

LA ORGANNIZACION Y RELACION ENTRE LO6 ATRIBUTOS. CARACTERiSTICAS

DEL SOPIWARE Y LAS YETRICAE SELECCIONADAS

19

CAPITULO 3

DESARROL O DE LA METODOLOGIA PARA EL DIAGNOSTICO DEL SISTEMA DE SOFTWARE

En la sección 1.2.1 se estableció la necesidad de contar con una metodología para llevar a cabo d diagnóstico de un sistema de software. Asimismo, también se estableció la necesidad de segmentar la metodología en tres grandes fases: fase de diagnóstico, fase de generación de alternativas y la fase de evaluación y selección de alternativas.

Sin embargo, estas fases engloban actividades que pueden ser realizadas de manera aún m& especifica.

En la siguiente sección, se propone una estructura de la metodología a desarrollar para llevar a cabo el diagnóstico de un sistema de software.

3.1 ESTRUCTURA DE LA METODOLOGIA PARA REALIZAR EL DIAGNOSTICO

La estructura de la metodología a definir puede segmentarse en las fases arriba indicadas, dentro de cada una de éstas, pueden identificarse algunas etapas como se describe en la siguiente sección.

3.1.1 IDENTIFICACION DE LAS ETAPAS DEL PROCESO

En la fase de diagnóstico, se desea deteminar la calidad del código fuente, con el motivo de obtener la magnitud de reparación del SIAGO. En esta fase se aplicarán las métricas seleccionadas para dicho motivo.

En la fase de generación de alternativas, se desea determinar el costo que implica la reparación del SIAGO, y el costo para desarrollar un nuevo sistema. Para determinar estos costos, es necesario determinar la magnitud de reparación del SIAGO para corregir deficiencias (se denominará mantenimiento perfectivo). Pero a la vez, es indispensable definir un mecanismo que permita estimar la magnitud del código necesario para satisfacer nuevas necesidades del usuario (se le denominará mantenimiento adaptivo, y consiste en agregar d i g o para realizar nuevas funciones).

Para determinar la magnitud del código a agregar, será necesario revisar visualmente la documentación del SIAGO para identificar los requerimientos adicionales del usuario. Aprovechando tal revisión, pueden derivarse los requerimientos globales que son alcanzados con el SIAGO. Si se suman estos requerimientos con los requerimientos adicionales del usuario, pueden obtenerse los requerimientos cubiertos con el sistema ya reparado.

20

El costo de reparación puede ser estimado a panu del mantenimiento perfectivo y adaptive. Mientras que el costo para desarrollar un nuevo sistema, puede obtenerse conociendo los requerimientos cubiertos con el sistema ya reparado, pero previendo el uso de herramientas que incrementen la productividad y la calidad del proceso.

En la fase de evaluaci6n y selección de alternativas, se hace uso de los costos obtenidos en la fase anterior. En la evaluación, se emplean criterios de análisis costoheneficio con respecto a la reparación de un sistema o altemativa 1, y el desarrollo de uno nuevo o alternativa 2. Así, la alternativa que proporciona mejores beneficios, es la alternativa a seleccionar.

En conclusión, en la fase de diagnóstico se distingue la actividad de determinar la calidad del código fuente. En la fase de generación de alternativas, se observan 4 actividades: la determinaci6n de la magnitud de reparación de un sistema, los requerimientos que se satisfacen con el sistema ya reparado, la estimaci6n de los costos para reparar el sistema y los costos que implican el desarrollo de un nuevo sistema. La fase de evaluación y selección de alternativas, se visualiza la actividad de evaluar las 2 alternativas (reparar el sistema existente y desarrollar un nuevo sistema) y la selección de la más idónea.

AI ser condensadas estas actividades en etapas del proceso de diagnóstico, se establecen las siguientes, ubicadas dentro de cada fase correspondiente:

FASE DE DIAGNOSTICO

ETAPA 1: Análisis del código fuente.

FASE DE GENERACION DE ALTERNATIVAS

ETAPA 2: An4lisis de requerimientos adicionales a los satisfechos con el sistema existente.

ETAPA 3: An4lisis de requerimientos del nuevo sistema.

ETAPA 4: Estimación de costos de reparación del sistema existente (ALTERNATIVA 1).

ETAPA 5: Estimación de costos para el desarrollo del nuevo sistema (ALTERNATIVA 2).

FASE DE EVALUACION Y SELECCION DE ALTERNATIVAS

ETAPA 6: Evaluación de las alternativas.

ETAPA 7: Selección de la altemativa.

3.1.2 DESARROLLO DEL MODELO DE LA METODOLOGIA PARA EL DIAGNOSTICO

El modelo de la metodología incluye las fases y etapas correspondientes y refleja la secuencia en que las etapas deben ser realizadas. Esto se muestra en la figura 3.1

21

FASE DE GENERACION ETAPA 2

ETAPA 1

CODlCO FUENTE

FASE DE DIAGNOSTICO

DE ALTERNATIVAS ETAPA 3

I ANALISIS DE REQUERIYIENTOS

ADICIONALES A LO8 SATiSFECHOS CON EL SISTEYA EXISTENTE

ETAPA 4 I

ESTIYACION DE COSTOS DE

ANALIS16 DE REQUERIYIENTOS

DEL NUEVO SISTEMA

I I ETAPA 5 I ESTIYACION DE COSTOS I

DE DESARROLLO DEL NUEVO SISTEMA (ALTERNATIVA 2)

REPARACION DEL GISTEYA EXISTENTE (ALTERNATIVA 1 )

ETAPA 6

EVALUACION DE

ALTERNATIVAS

ETAPA 7

SELECCION DE U ALTERNATIVA

ASE DE EVALUACION Y SELECCION DE ALTERNATIVAS

FIGURA 9.1

MODELO DE LA MKTODOLOGIA PARA EL DIAGNOSTICO DE UN

SISTEMA DE SOFTWARE

22

3.1.3 HERRAMIENTAS UTILIZADAS

Principalmente son dos las técnicas que se utilizan dentro del modelo de diagnóstico, en los incisos 3.1.3.1 y 3.1.3.2, se describen someramente las dos herramientas, las cuales son aplicadas en las etapas: 1,4 y 5.

3.1.3.1 EL PROGRAMA ANALIZADOR DEL CODIGO

Este programa, denominado "DIAGNOSTICO", fue desarrollado en el lenguaje de programación turbopascal (Versión 5.0) y corre bajo el sistema operativo MS-DOS, en microcomputadoras compatibles XT o AT. Este programa considera las métricas seleccionadas, indicadas al final de la sección 2.3 (métricas de líneas de código fuente y las mediciones de la ciencia del software combinadas con el número ciclomático y el nivel de anidamiento).

La aplicación del conteo de las líneas de código fuente es muy simple; sin embargo, las mediciones de la ciencia del software, combinadas con la complejidad ciclomática de McCabe y el nivel de anidamiento, están fundamentadas con la técnica establecida por Bina Ramamurthy y Austin Melton [36]. En ella, consideran que la complejidad del código no solo se debe al contenido de informacidn o proceso secuencial, sino también al efecto de los ciclos e intrucciones de decisión.

En esta técnica, la frecuencia con que ocurren los operadores y operandos es afectada por el nivel de anidamiento en que se localizan las estructuras de control. Inicialmente, Halstead sólo contemplaba el incremento de la frecuencia en 1. Por tal motivo, este efecto está reflejado en el tamaño de un programa (N), en el volumen 0, en el tiempo de desarrollo 0, e&.

Asf, dentro de un m6dulo se define a A, como una colección de todos los operadores que aparecen en el módulo, cada operador necesitará estar en A con tanta frecuencia como esté en el módulo. Asimismo, se define a B como la colección de todos los operandos que aparecen en el módulo. Con cada elemento en A U B (A unión B), asociamos el valor de 1 6 O. Si un operador u operando, es parte de una estructura de control en el código fuente, entonces su valor asociado es 1, de lo contrario, su valor asociado es O.

Denotamos el valor asociado con cada elemento x en A U B, por 6(x). También asociamos con cada elemento en A U B, su nivel de anidamiento; para cada elemento x en A U B, entonces l(x) denota su nivel de anidamiento. En las mediciones con peso, los valores de 6(x) y l(x) interactúan entre sí, así que aunque cada operador y operando tenga un nivel de anidamiento asociado, este nivel de anidamiento solo afecta las mediciones si el operador u operando es parte de una estructura de control.

Así, 6 es realmente una función de A U B (cuyos valores pertenecen al conjunto de {0,1}) y I, es una función de A U B (cuyos valores pertenecen al conjunto de enteros no negativos).

Usando w, para denotar una medición con peso, se tienen las siguientes Mrmulas para obtener las mediciones de la ciencia del software con peso.

Total operadores: Nw, = ExmA (1 + 6(x) * i(x))

Total Operandos: Nw, = ExrnB (1 + 6(x) * l(x))

23 TallMBO:

Nw = Nw, + Nw, Tiempo de desarrollo:

(3.3)

T = (n, NW, NW * iog2n)nn , (3.4) Donde:

n ,, es el número de operadores distintos que aparecen dentro de un módulo; n2, es el n k o de operandos distintos dentro del módulo, y n , es el número de operadores y operandos (n , + n,) distintos contenidos dentro de un módulo.

De: (1 + 6(x) * l(x)], 1 corresponde al incremento debido a la ocurrencia de un operador. A 6(x), le corresponde un valor de 1, si el operador forma parte de una instrucción de flujo de control; 6 un valor de O, si la instrucción que lo contiene, no es una estructura de flujo de conirol. A i(x). l e corresponde un valor igual al nivel de anidamiento, en caso de que el operador u operando, forme parte de una instrucción de flujo de control. fl , n ,, n2, no sufren alteración, pues sólo es el conteo de los operadores u operandos diferentes existentes dentro de un módulo.

Vale la pena destacar que 6(x)*I(x), es la asignación de un valor adicional a los operadores u operandos que forman parte de una instrucción de decisión o ciclo; se han hecho experimentos sobre este criterio (361, se ha demostrado que los valores obtenidos muestran mayor complejidad de un programa, donde existen instrucciones de flujo de control, en comparación a un programa totalmente secuencial. A pesar de lo anterior, estas mediciones tienen algunas limitaciones, como a continuación se indican:

1. Las estructuras de flujo de control usadas son: . SEQUENCE . DO-WHILE . DO-UNTIL . IF-THEN-ELSE

2. No existen predicados con múltiples pniebas como: CASE, y operadores y operandos en predicados compuestos.

Para la validez de estas mediciones, se ha establecido el siguiente teorema:

TEOREMA (Primera Parte)

El número ciclomático v(G), de una estnictura de flujo de control que tiene un IF-THEN-ELSE, un DO-WHILE o un DO-UNTIL a un nivel L, es L+ 1, si:

1. La estructura de flujo de control a un nivel L, es la estructura más anidada en el programa. 2. En cada nivel de anidamiento, existe al menos una estructura de flujo de control no-secuencial. 3. El programa contiene s610 estructuras de fujo de control:

- SEQUENCE - IF-THEN-ELSE - DO-WHILE - DO-UNTIL

24

TEOREMA (Segunda Parte)

1. hede no haber ambas construcciones W W H I L E e IF-THEN-ELSE, en el mismo nivel de anidamiento.

2. Para cada construcción IF-THEN-ELSE, solo la parte THEN o la parte ELSE (no ambas), pueden

En la realidad, esta restricción es muy difícil de imponerla, ya que los programas pueden contener las estructuras de control no secuencial en cualquier segmento (en la parte THEN o en la parte ELSE); sin embargo, una forma de tratar estos casos es considerar la parte más anidada (puede ser la parte THEN o a parte ELSE) que determinaría la porción más compleja de la estructura.

contener estructuras de flujo de control no secuencial.

Con estas limitaciones, se supone que los predicados compuestos de las instrucciones de flujo de control se consideran como predicados simples, se utiliza este criterio para diagnosticar el sistema de software en estudio.

Utilizando la técnica descrita anteriormente, el programa de diagnóstico lo utiliza con el siguiente proceso algorítmico:

1. Carga en una estructura de datos de árbol binario, las palabras reservadas del lenguaje de programación (en este caso de fortran-77) para identificarlas como operadores.

2. Mientras se desee otro diagnóstico, hacer lo siguiente:

a) Leer el código fuente del módulo actual (puede ser programa principal, subrutina o función). Este proceso incluye la siguiente secuencia: . Lee cada línea de instnicción, descompniéndola en tokens, para obtener el número de

operadores y operandos diferentes y la frecuencia con que son usados dentro de cada módulo. . Realiza el conteo de las líneas de código fuente ejecutable para cada m6dulo (no considera las líneas ubicadas en la sección de declaración de variables, líneas de comentarios ni las líneas en blanco).

línea. . Identifica las continuaciones de líneas de instrucción para no ser contadas como una nueva . Registra el conteo de las líneas de comentarios para cada módulo. . Identifica y cuenta el número de líneas en blanco existentes en cada módulo. . Identifica las instrucciones de estructuras de control (ciclos y decisiones). . Mantiene el control del nivel de anidamiento de las instrucciones, al momento de encontrar una . La ocurrencia con que son usados los operadores y operandos, es afectada por el nivel de

estructura de control.

anidamiento, si el operador u operando forma parte de la instrucción de control.

b) Generaci6n del reporte de llamados de subrutinas, que comprende la siguiente información: - Número consecutivo del módulo - Nombre del módulo - Tipo del módulo @=programa principal, S=Subrutina, F=Función) - Número consecutivo de la(s) subrutina(s) o función(es) que son llamadas desde un programa

principal o subrutina

25 c) Cálculo del nivel de calidad del d i g o de cada módulo y generación del reQorte que resume los

datos de diagn6stico. - Cálculo del nivel de calidad del código de cada módulo. - El reporte resume los siguientes resultados: . N ú m m consecutivo del módulo . Nombre del módulo . Tipo del módulo @=programa principal, S=Subnitina, F=Función) . Número de líneas de código fuente ejecutables . Número de líneas de comentarios del módulo . Número de líneas en blanco . Número de operadores únicos . Frecuencia total u ocurrencia de los operadores únicos . Número de operandos únicos . Frecuencia total u ocurrencia de los operandos únicos . Complejidad ciclomática . Nivel de calidad del código fuente del módulo

d) Cálculo de las métricas de calidad del software y la generación del reporte correspondiente - Cálculo del tamaño del programa, sumando la ocurrencia de los operadores y operandos únicos - Cálculo del tiempo de desarrollo del módulo -en horas- (con la Mrmula 3.4). - Cálculo del volumen del programa o m6dulo. - Cálculo del valor total (del sistema) y promedio por módulo de los siguientes parhetros:

del módulo.

. Número de líneas del código fuente

. Ocurrencia de los operadores y operandos únicos

. Tamaño del programa

. Complejidad ciclomática

. Tiempo de desarrollo (en horas)

. Volumen - Generación del reporte de los parámetros indicados anteriormente.

3. Análisis de frecuencias sobre el nivel de modularización del código fuente del SIAGO, en función del número de líneas fuente ejecutables y la complejidad ciclomática.

3.1.3.2 EL MODELO DE COSTOS CONSTRUCTIVO (COCOMO)

EL modelo COCOMO, es la herramienta que se empleará en la estimación del esfuerzo, costos y tiempo para desarrollar y mantener un producto de software.

En el anexo C, se presentan algunos conceptos baicos del COCOMO y que serán de utilidad en la aplicación del presente trabajo; en esta sección, sin embargo, s610 se especifica la versión y el modo del COCOMO utilizado, así como sus ecuaciones correspondientes.

Dado que el COCOMO además de considerar las Instrucciones Fuente Ejecutables, toma en cuenta las instrucciones de la sección de declaración de datos, se empleará el término IFE (Instrucciones Fuente Entregadas, o MIFE, si se expresa en MILES), al utilizar las LCFE (Líneas de C6digo Fuente Ejecutables) adema de las instrucciones de la sección de declaración de datos; esto es: IFE = LCFE + instrucciones (líneas) de la sección de declaración de datos.

26 Existen 2 versiones del COCOMO: el COCOMO BASIC0 y el COCOMO INTERMEDIO. El

COCOMO intermedio, es la versión más adecuada para la estimación de costos para el desarrollo de proyectos de software, ya que toma en cuenta los 15 factores ( v k e anexo C) correspondientes a los 4 tipos de atributos:

1 . ATRIBUTOS DEL PRODUCTO DE SOFWARE 2. ATRIBUTOS DE LA COMPUTADORA 3. ATRIBUTOS DEL PERSONAL QUE DESARROLLA EL SOFTWARE 4. ATRIBUTOS DEL PROYECTO

A la vez, el COCOMO intermedio, presenta 3 modos de desarrollo del software:

a) Modo orgánico b) Modo semi-sqarado c) Modo embebido

Por las características presentes en la aplicación que nos interesa, se empleará el COCOMO INTERMEDIO, en modo ORGANICO, cuya ecuaci6n para estimar el esfuerzo de desarrollo es:

Hom-Mes = 3.2 (MIFE)'," (3.5)

3.1.4 DESCRPCION DEL PROCEDIMIENTO DE DIAGNOSTICO

En secciones anteriores, se han definido los elementos que forman parte de la metodología para el diagnóstico del software. En el capfhilo 2, se seleccionaron las métricas a utilizar para medir la calidad del software. En la sección 3.1.2, se desarrolló el modelo de la metodología a utilizar; en la sección 3.1.3, se describieron brevemente las herramientas necesarias en el diagnóstico, incluyendo la técnica mediante la cual, se aplican.

En la sección siguiente, se describe el procedimiento del diagnóstico, y considera las etapas indicadas en la figura 3.1.

3.1.4.1 ETAPA 1: ANALISIS DEL CODIGO FUENTE

Se determinará el tamaño físico del sistema, a traves del conte0 las líneas código fuente ejecutable de cada programa o subrutina (no se consideran las líneas de comentarios ni las líneas en blanco). El volumen de un programa (bits necesarios para almacenar un programa) y el tiempo de su desarrollo [5] , es obtenido por medio del conteo de operadores y operandos (f6rmula 3.4).

La complejidad ciclomática de McCabe, será determinada a través de la identificación y conteo de instrucciones de flujo de control del programa, como se describe en [31.

Todas estas mediciones serán obtenidas con la herramienta computacional denominada "DIAGNOSTIICO", desarrollada para tal fin, cuyos reportes se muestran en el anexo A.

21 Como resultado del uso de la herramienta, se identificarh aquellos m6dulos que requieran ser

reparados. Para tal efecto, se establece una clasificación de los módulos del sistema, por niveles de calidad. Esta clasificación es obtenida a traves del grado de modularizaci6n del sistema. Los niveles de calidad definidos, están basados en el tamaño de los módulos (en niimero de líneas fuente ejecutabies) y la complejidad ciclomática. Los niveles de calidad son los siguientes: m6dulos de mala calidad, m6dulos de calidad aceptable y m6dulos de alta calidad ( v h e definiciones de los niveles de calidad, en la sección 5.2).

3.1.4.2 ETAPA 2: ANALISIS DE REQUERIMIENTOS ADICIONALES A LOS SATISFECHOS CON EL SISTEMA EXISTENTE

Se debe realizar una revisión minuciosa de la documentación del sistema a diagnosticar. Para obtener los requerimientos adicionales a los satisfechos con el sistema existente, se analizan los objetivos propuestos (donde se identifican y describen las necesidades del usuario). Asf también, se analizan los objetivos y los métodos de solución propuestos; éstos, especifican lo que el sistema actualmente realiza u objetivos que son alcanzados. Los objetivos no alcanzados surgen de la diferencia de las necesidades del usuario y lo que el sistema actualmente realiza. Adicionalmente, deben considerarse las necesidades para perfeccionar el sistema.

Estos requerimientos deben ser traducidos en términos de instrucciones fuente necesarias para modificar el sistema (véase sección 4.2.1.3).

3.1.4.3 ETAPA 3: ANALISIS DE REQUERIMIENTOS DEL NUEVO SISTEMA

Consiste en identificar y considerar todas las necesidades del usuario. Aquellos objetivos no factibles identificados en la sección anterior, deben ser resueltos proponiendo otras alternativas (nuevo diseño, otras herramientas de desarrollo, nuevo ambiente, etc.).

De igual manera que en el punto anterior, los requerimientos para el nuevo sistema deben ser traducidos a instrucciones fuente, considerando las nuevas alternativas de desarrollo.

3.1.4.4 ETAPA 4: ESTIMACION DE COSTOS DE REPARACION DEL SISTEMA EXISTENTE (ALTERNATIVA 1)

En el punto 3.1.4.2, se definieron aquellos requerimientos para realizar el mantenimiento perfectivo y adaptivo del sistema existente; al ser traducidos estos requerimientos en instrucciones fuente, pueden ser utilizados eo la herramienta de estimación de costos para la reparación, los cuales incluyen los siguientes costos:

COSTOS DE INVERSION a) Identificación y eliminación de deficiencias existentes (reporte 4, anexo A). b) Consideración de requerimientos adicionales del usuario.

COSTOS DE OPERACION a) Costos para el mantenimiento del sistema. b) Costos de operación del sistema (tiempo de operador y CPU).

28

3.1.4.5 ETAPA 5: ESTIMACION DE COSTOS PARA EL DESARROLLO DEL NUEVO SISTEMA (ALTERNATIVA 2)

La estimación de estos costos son los que implica el desarrollo de un sistema totalmente nuevo, se supone la aplicación de técnicas modernas de programación, de paquetería de software (manejadores de bases de datos, generadores de reportes, paquetes estadísticos, paquetes gráficos, etc.). Estos costos incluyen los siguientes:

COSTOS DE INVERSION a) Adquisición de paquetes de software. b) Desarrollo del nuevo sistema. c) instalación del sistema.

COSTOS DE OPERACION a) Operación del nuevo sistema (tiempo de operador y CPU). b) Mantenimiento del sistema.

3.1.4.6 ETAPA 6: EVALUACION DE LAS ALTERNATIVAS

En función de los costos obtenidos en las etapas 4 y 5, puede procederse a evaluar la alternativa 1 y 2. La evaluación consiste en analizar y evaluar los costos y beneficios obtenidos, en cada una de las dos altemativas, esto puede realizarse, utilizando la técnica de análisis costo/beneficio, para la toma de decisiones.

El análisis costo/beneficio es utilizado para estimar y comparar los costos y beneficios, y en función de éstos, realizar la elección entre 2 alternativas. Los costos se refieren a los recursos requeridos para la reparación o desarrollo del software. Los beneficios, son vistos en forma de ahorros y ventajas que proporciona el hecho de contar con una nueva herramienta, con otras características a las originales.

3.1.4.7 EPATA 7: SELECCION DE LA ALTERNATIVA

Esta etapa, es el resultado de la evaluación de las alternativas, realizada en la etapa 6; la decisión puede apoyarse en una tabla que muestre los resultados de los costos para la reparación del sistema y para el desarrollo del nuevo sistema.

29

CAPITULO 4

APLICACION DE LA METODOLOGIA

La aplicación de la metodología en sí, implica un costo que se refiere al estudio a realizar para determinar los costos de la alternativa 1 (reparación de un sistema existente) y los costos de la alternativa 2 (desarrollo de un nuevo sistema). AI respecto, existe la necesidad de un criterio que determine cuándo la aplicación de la presente metodología es rentable; esto es, que el costo del estudio sea menor al costo de reparar el sistema o el desarrollo de uno nuevo.

4.1 MARCO DESCRIPTIVO DEL SISTEMA EXISTENTE

Esencialmente, el SIAGO consta de tres grandes módulos y cada uno de ellos está formado por los siguientes conjuntos de programas:

1. MODULO DE TRANSFERENCIA, consta de 7 programas cuyo objetivo es la transferencia de la información financiera de los costos presupuestados y ejercidos, así como los ingresos obtenidos por la venta de servicios y proyectos de investigación.

2. MODULO DE ACTUALIZACION, consta de 27 programas utilizados para actualizar la información, en general, de los proyectos.

3. MODULO DE CONSOLIDACION Y REPORTES, consta de 30 programas cuyo prop6sito consiste en integrar y resumir la infomación tinanciera y descriptiva, para con ello, generar los reportes y gráficas necesarias para el análisis de la evaluación institucional. Dicha evaluación, consiste en analizar los resultados que la institución ha obtenido a traves de sus proyectos de investigación; por ejemplo, la evolución se determina en función de la diversidad de las áreas en que se ha incursionado en las investigaciones. El crecimiento institucional, se detemina con base en los recursos e infraestructura que se requiere para realizar investigación. El mercado, se determina por el número de usuarios que son atendidos por la institución, a quienes se les vende servicios y/o proyectos de investigación (como principal fuente de ingresos).

El usuario tiene acceso a cada uno de estos módulos, cuya información que se procesa es extrafda y/o almacenada en una base de datos, consistente en una serie de archivos tradicionales del tipo INDEX-SEQUENTIAL.

4.1.1 ESTRUCTURA GENERAL

En la figura 4.1, se muestra el diagrama general del SIAGO (sistema utilizado en el departamento de estudios corporativos del instituto de Investigaciones Eléctricas), puede observarse que la información financiera de proyectos es obtenida de los Departamentos de Presupuestos (costos presupuestados y ejercidos) y Tesorería (ingresos de proyectos). Del Departamento Jurídico se obtienen los datos descriptivos de los proyectos, a traves de los contratos.

u)

4

W O u) W

e a

Y m

x

so

I

31

4.1.2 ALCANCES Y LIMITACIONES

Para reparar el SIAGO, se requiere de los dos siguientes tipos de mantenimiento:

1. Mantenimiento Adaptive, que consiste en corregir el código fuente! hacerlo más

2. Mantenimiento Perfectivo, consiste en incorporar nuevo código para satisfacer

estnicturado, documentado y aplicar las tkniw de modularización, con el fin de que el producto sea más entendible.

requerimientos adicionales que inicialmente fueron incompletos o confusos. Asimismo, para mejorar la interfaz hombremáquina del sistema.

El mantenimiento adaptivo que requerirá el SIAGO será determinado I con la herramienta computacional denominado DIAGNOSTICO (SU descripción se presenta en la sección 3.1.3.1), que analiza el código fuente. Mientras que a partir de los alcances y limitaciones que presenta el sistema existente, se pueden definir los requerimientos adicionales a los satisfechos con dicho sistema, con lo cual, se define el mantenimiento perfectivo.

I

Para determinar los alcances y limitaciones del SIAGO, a continuación se presenta una lista de los objetivos totales propuestos:

1. Contar con un sistema de información que permita generar reportes, estadí&as y gráficas sobre indicadores que se apoyen en el análisis de la evaluación institucional (a través de sus proyectos de investigación), para determinar su evolución, crecimiento, trayectoria, mercado, etc.

1

2. El sistema debe obtener información de proyectos en forma automática, de dos tipos: a) Información descriptiva, que pueda ser extraída a partir de los c o n t r j s formalizados por

b) Información financiera, que pueda extraerse de las bases de datos dellos depariamentos de presupuestos y tesorería, sobre gastos presupuestados y ejercidos e ingresos obtenidos por la venta de servicios y proyectos de investigación realizados.

el departamento jurídico. 1

3. La información financiera debe extraerse mensualmente.

4. El sistema debe contener funciones para actualizar la información de proyectos, con los siguientes I

fines: a) Clasificarla dentro de esquemas particulares al departamento. b) Complementarla con la información obtenida de otras fuentes.

5. Debe contener capacidad para conservar información históricade 16 años (1977-1992), información en forma resumida que aporta elementos para los análisis requeridos. I

I . 6. Debe contener funciones que permitan integrar información descriptiva, con la mformación

financiera.

7. Debe contener funciones que permitan visualizar la información en pantalla o en reportes impresos.

8. La información financiera debe manipularse en forma numérica, con una precisión de basta 10 cifras enteras. I

9. El sistema debe incluir algoritmos eficientes de búsqueda y ordenamiento de información.

-_ - --- -- -_

I

I 32

10. Se deben contemplar procesos de validación de datos al momento de ser introducidos, desde dos puntos de vista:

a). Validación de datos para verificar su tipo y rango de valores permitidos. b). Validación de información para verificar su conmencia, este proceso implica el relacionar información de proyectos, contratos y facturación.

11. El sistema debe ser operado por personal sin experiencia en el desarrollo de sistemas.

12. El sistema debe ser ejecutado eo un procesador VAX/isO, la interfase con el usuario debe ser a través de terminales de video.

i 4.1.2.1 ALCANCES Algunos objetivos enunciados en la lista anterior, son alcanzados con el sistema actual (objetivos 1, 3, 4, 5, 6, 7 y 12); otros, d o son alcanzados parcialmente (objetivo 2). I

4.1.2.2 LIMiTACIONES

Con base en la lista presentada en la sección 4.1.2, los objetivos: 2, 8, 9, 10 y 11 que no son cubiertos con el sistema existente, forman parte de las limitaciones que presentalel SIAGO. Debido a que el mantenimiento perfectivo será determinado en función de las limitaciones que presenta, éstas están divididas en 4 tipos: limitaciones por estructuras de datos, limitaciones de la programación, limitaciones de la explotación y limitaciones del mantenimiento.

4.1.2.2.1 LIMITACIONES POR ESTRUCTURAS DE DATOS

1. Uso de estructuras de datos simples, como arreglos unidimensionales, arreglos bidimensionales, I

registros y archivos. Dado su iamaño fijo, con frecuencia, se requiere modificar su tamaño (reducirlo o incrementarlo). !

2. Existencia de varios campos que ya no se utilizan, su eliminación no se realiza dada la organización utilizada de los archivos, esto obligaría a realizar cambios a todos los programa que los accesan. Lo anterior ha conducido a la deficiente administración del espacio de los archivos de datos.

3. Considerable tiempo de respuesta del sistema al manipular grandes volilmeneslde información por la estructura de datos utilizada (acceso a archivos).

4. Duplicidad de campos en algunos archivos de datos.

5. Tipo de los campos de costos definidos en forma alfanumérica, se requieren operaciones de conversión ( d i g o de programación adicional) para su manipulación. La longitud máxima de los c a m p de costos es de 7 dlgitos, esto impide registrar valores grandes.

- -_ . . .~

33 4.1.2.2.2 LMITACIONES DE LA PROGRAMACION

1. Los programas realizan funciones muy particulares, existen programas indepdientes aue realizan los mismos procesos, pero a diferentes archivos, por ejemplo:validación de informaci6n, ordenamiento, etc. 1

I

2. Los programas del sistema SIAGO están dearrollados en un lenguaje de al& nivel (FORTRAN), orientado a aplicaciones científicas e ingeniería, por lo tanto, para manipular la información se requiere de gran cantidad de código fuente.

3. Existe redundancia de información, debido a que las relaciones que deben existir entre los datos, se hace solamente en los programas. Esto ocasiona un enorme tamaño de los archivos de datos y la necesidad de los datos en varios de los archivos. 1

4. Los programas del sistema que son afectados, no se actualizan al ritmo de los nuevos requerimientos. Esto implica que, en caso de modificar el tamaño de un registro de un archivo de datos, todos los programas que accesan dicho archivo deben modificarse también.

5. Poco o nulo uso de técnicas de modularizaci6n al crear nuevas rutinas con código repetido en varios programas, con el tin de satisfacer necesidades de los usuarios, esto dcasiona la existencia de código redundante. Es recomendable desarrollar rutinas que realicen funciones específicas como búsquedas, ordenamiento, etc., pero que sean de uso general a través de llamados desde otros programas.

6. La validación de la información de los archivos de datos se realiza por triangulaciones (proyeaosiontratos-fachiras). Esto es razón también de la existencia de d i g o iMeCeSari0.

I 7. Nula aplicación de criterios de seguridad de la infonnaci6n, no existen conq.oles de acceso a los archivos de datos. Esta situación es un riesgo, pues la información puede ser alterada o borrada por cualquier usuario no autorizado.

8. No se contempla la validación automática de claves operativas (clave y descripción de la clave), esto incrementa el tiempo de captura. Actualmente se utilizan procesos de validación de información a través de la revisión manual por medio de los reportes. i 1

4.1.2.2.3 LIMITACIONES DE LA EXPLOTACION

1. La operación del sistema no es amigable con el usuario, por lo cual el usuario requiere de conocimientos del sistema y de programación.

2. La explotación de la información del sistema se realiza a través de programas particulares para generar reportes en video o en papel. Esto trae como consecuencia una fuerte limitación para consultar la informaci6n con otras características (otros formatos de despliegue, la presentación de otros datos, etc.).

3. Los reporta en papel, se realizan a través de programas específicos para el formateo de la información y rotulaci6n del reporte. Implica mucha codificación para el formateo, control de tamaño de páginas, etc. I

.

34 4. Para generar reportes, es necesario utilizar previamente los programas que combinan y consolidan

la información. Se generan muchos archivos temporales y la necesidad de ejecutar los programas de consolidación con mucha frecuencia, cada vez que los datos son actualizados.

5. Se requiere de programas específicos para generar reportes estadísticos para análisis I . . y promoción y programas específicos para generar reportes grafcos. Se utilizan varios programas para adecuar la información en formatos espedficos.

6. No se cuenta con programas que generen reportes para análisis y consolidados desglosados por depanamento, división, subprograma, etc. El desarrollo de estos programas, requiere de código adicional para seleccionar, ordenar y formatear los datos. i 7. No se cuenta con programas que obtengan reportes de proyectos con sus respectivos contratos asociados, índices de autofinanciamiento y el perfil de ingresos y costos. Tahbién requiere de tiempo adicional para desarrollar estos programas.

8. Los reportes gráficos se obtienen a través de programas que realizan llamados a subrutinas de un paquete grfico de primitivas. independientemente de requerir un formato específico de los datos, el trazado de los diagramas, requiere de mucho código, incluyendo cálculos para dimensionar los UaZOS. I

4.1.2.2.4 LIMITACIONES DEL MANTENIMIENTO

1. No se cuenta con la documentaci6n de apoyo (especificación de requerimiends, diseño, planes de prueba, manual de usuario, etc.). I

2. Los programas del sistema, sufren cambios frecuentes, aumentando con ello su complejidad y deteriorando su confiabilidad y eficiencia.

3. Dentro de la parte del código de los programas, existen eswas líneas de comentarios, para aquellos que presentan varias líneas, en realidad se trata de líneas de código i c e l a d a s (como pudo observarse en los reportes del diagnóstico, existe un promedio de 19 líneas de comentarios por módulo, cuyo promedio es de 120 líneas de instrucciones ejecutables; esto cbrresponde aproximadamente a 6 lfneas de instrucciones, por cada línea de comentario). Esto causa que los programas sean difíciles de entender y modificar.

4. El tiempo para analizar y realizar modificaciones a los programas del sistema es alto, esto se. debe

5. Los cambios realizados a los programas, proporcionan beneficios a corto p l h , debido al diseño

a la carencia de la documentación de los programas.

deficiente de los programas y a la adición de nuevos requerimientos.

4.2 DIAGNOSTICO DEL SISTEMA

Esta sección involucra la "fase de diagnóstico" y una parte de la "fask de generación de alternativas" (etapas 2 y 3). Esto puede observarse en la figura 3.1, del capftulb anterior.

!

35

4.2.1 DETEMNACION DE LA MAGNITUD DE REPARACION DEL SISTEMA EXISTENTE

A través de la aplicación de las primeras dos etapas, el volumen de la r&araci6n del sistema existente puede determinarse con el mantenimiento adaptivo y el mantenimienh perfectivo como se describe en las dos secciones siguientes.

I . MALA CALIDAD

4.2.1.1 ANALISIS DEL CODIGO FUENTE (ETAPA 1)

En esta etapa se determina el mantenimiento adaptivo que requiere el SIAGO, i indicado en nilmero de líneas de código fuente que deben ser modificados para corregir las deficiencias encontradas. Para ello, se recurre al uso del analizador del código fuente ("DIAGNOSTICO"), que analiza todos los programas que integran el SIAGO. AI ser clasificados en niveles de calidad del d i g o fuente, los 87 módulos que integran el SIAGO, fueron ubicados en los siguientes niveles:

a) 43 módulos (49%), son considerados de mala calidad o nivel 1 (reporte 4, anexo A). b) 34 módulos (39%), son considerados de calidad aceptable o nivel 2 (reporte13, anexo A). c) 10 módulos (12%), son considerados de buena calidad o nivel 3 (reporte 3, hex0 A).

(((I a NLCFE b 30) 6 (NLCFE > so)) 1 : 3 0 6 > 10 > 5 0 y (v(0) > 10))

Los niveles de calidad utilizados para clasificar los módulos analizados fueron definidos con base a las condiciones indicadas en la tabla 4.1 y figura 4.2.

1 :M6 > M

I : 30 11 2. CALIDAD ACEPTABLE

TABLA 4.1

010 (((I S N E P E 30) 6 &CFE > 50))

- 6 ' 510

Y (O a v(0) a Io))

((I NLCFE S 30) Y (5 a v(G) S IO))

I

3150

II 11 NIVELESDECALIDAD I NLCFE I v(G) I EXPRESION LOGICA

6 - ((31 S NLCFE 5 SO) Y (v(0) > IO))

> 10

3. ALTA CALIDAD

II

31:50 o: 10

1 : 3 0 o

I 36

I FIGURA 4.2 !

NUMERO DE LINEAS DE CODIGO FUENTE EJECUTABLE (NLCFE)

I

En (151, se especifica que para modificar un módulo se requiere de un gran esfueno para leerlo y entenderlo, principalmente en aquellos programas muy grandes por el volumen de ¡nformación que debe ser absorbido para comprenderlo. Así pues, si de los resultados obtenidos en el análisis del código fuente se decide modificar únicamente aquellos módulos clasificados en el nivel de mala calidad (nivel= 1), por considerarse muy complejos, es obvio que requerirá un gran esfueno para leerlos y comprenderlos. La razón es que, 43 módulos (de un total de 87 módulos del SIAGO), requieren de mantenimiento adaptivo.

Mostrados en forma resumida, la magnitud del mantenimiento adaptivo (obtenida con el analizador de código "DIAGNOSTICO"), en número de m6dulos o programas y en número de líneas de código fuente, pueden observarse en la tabla 4.2. Esto muestra la proporción del númm de módulos y/o número de líneas de código fuente que deben ser modificados.

!

MODULO LOGIC0 (COMPONENTE)

TRANSFERENCIA

A