Ovejero Tesisdemagister

TESIS DE MAGISTER
EN INGENIERA DEL SOFTWARE
Estimacin de Proyectos Para

Sistemas Basados en Conocimiento
AUTOR : ING. JOS DANIEL OVEJERO
DIRECTORES
DR. DANTE CARRIZO (UPM)
M.ING. EDUARDO DIEZ (ITBA)
BUENOS AIRES, 2006
Estimacin de Proyectos Para Sistemas Basados en Conocimiento
A mi esposa
e hijos
por tanta
paciencia y espera
AGRADECIMIENTOS
A las autoridades del ITBA

A los docentes de la Capis
por el apoyo y la transferencia de conocimientos
A mi Director de Tesis M. Ing. Eduardo Diez
Especialmente a la M. Ing. Bibiana Rossi
por su apoyo en las primeras etapas de este proyecto
A mi familia
por la tolerancia y la espera
NDICE DE CONTENIDOS
Parte I - (Terica) - Aproximacin a la Solucin: Estimacin de

Proyectos Para Sistema Basados en Conocimiento.
CAPTULO I - INTRODUCCIN
1.1 Introduccin
1.2 Descripcin de la composicin del trabajo de tesis
3
4
CAPTULO II- DOMINIO DEL PROBLEMA

2.1 Introduccin
2.2 Conceptos generales de estimacin
2.3. Breve descripcin de las tcnicas a analizar
2.4 Sistemas basados en conocimientos (SSBBCC)
2.5 Justificacin del problema
2.6 Descripcin de la solucin a implementar
9
9
10
13
14
14
CAPTULO III- LA ESTIMACIN Y LA GESTIN DEL PROYECTO

3.1 Introduccin
3.2. Qu se entiende por estimacin
3.3 Establecimiento de mbito y objetivos del proyecto
3.4 Mtricas y medidas
3.5 Tipos de software
3.6 Estimacin basada en la funcionalidad
19
19
19
20
21
22
CAPTULO IV- ESTUDIO DE LAS TCNICAS DE ESTIMACIN

4.1 Introduccin
4.2 Estudio de las tcnicas de estimacin
4.2.1 Tcnica de estimacin de puntos de funcin (FP)
[Albrecht79]
4.2.1.1 Identificacin de grupos lgicos de datos y
funciones transaccionales en las aplicaciones a medir
4.2.1.2 Identificacin de grupos lgicos de datos (ILF Y
ELF)
4.2.1.2.1 Determinacin de la complejidad para
grupos de datos lgicos
4.2.1.3 Identificacin de funciones transaccionales (EI, EO,
EQ)
4.2.1.3.1 Determinacin de la complejidad para
funciones transaccionales
4.2.1.4 Aplicacin de formulas para conteo de los puntos de
27
27
27
28
28
29
30
32
33
i
funcin sin ajustar

4.2.1.5 Calibracin de los FP en base a las caractersticas
generales de la aplicacin
4.2.2 Tcnica de estimacin de puntos de caracterstica
(FEATURE POINTS) [Jones99]
4.2.3 Tcnica de estimacin Mark II (MK II) [Symons98]
4.2.3.1 Tamao de la aplicacin
4.2.3.2 Reglas para la identificacin de los componentes de
las transacciones lgicas
4.2.3.2.1 Identificacin y contabilizacin de
entidades
4.2.3.2.2 Identificacin y contabilizacin de
transacciones lgicas
4.2.3.2.3 Reglas para contar DETs en entradas y
salidas
4.2.3.3 Ajuste de la complejidad tcnica
4.2.3.4 Aplicacin de frmulas para el clculo de los puntos
de funcin totales para MK II
4.2.4 Mtodo de estimacin 3D FUNCTION POINTS
[Whitmire92]
4.2.5 Mtodo de estimacin de puntos completos de funcin FFP
[Abran A., et al97]
4.2.6 Mtodo de estimacin COSMIC-FFP [Abran A., et al99]
4.2.6.1 Identificacin y extraccin de los FURs
4.2.6.2 Fase de representacin en COSMIC-FFP
4.2.6.3 Reglas para la representacin
4.2.6.3.1 Identificacin de capas del software
4.2.6.3.2 Identificacin de la frontera del software
4.2.6.3.3 Identificacin de procesos funcionales
4.2.6.3.4 Identificacin de grupo de datos
4.2.6.3.5 Identificacin de atributos de datos
4.2.6.4 Fase de medicin de COSMIC-FFP
4.2.6.4.1 Identificacin de los subprocesos
4.2.6.4.2 Aplicacin de la funcin de medicin
4.2.6.4.3 Agregacin de los resultados de la funcin
de medicin
4.2.6.5 Matriz de representacin y medicin de valores
COSMIC-FFP
4.3 Resumen del estudio de las tcnicas de estimacin
4.4 Aplicabilidad de las tcnicas a distintos tipos de software
CAPTULO V CONOCIMIENTO
ESTUDIO
DE
LOS
SISTEMAS
BASADOS
5.1 Introduccin
5.2 Breve resea y evolucin de los sistemas basados en conocimiento
5.3 Relacin entre la inteligencia artificial (IA) y los SSBBCC
5.4 Principales actores de un SSBBCC
ii
34
40
42
42
43
43
45
45
46
48
49
50
50
52
52
54
55
56
56
57
58
58
59
61
61
62
63
63
EN
67
67
68
69
5.5 Arquitectura de un SBC

5.6 Modelo genrico para el desarrollo de SSBBCC
5.7 Diferencias y similitudes con otros tipos de sistemas
70
72
75
CAPTULO VI - TCNICA DE ESTIMACIN PARA SSBBCC

6.1 Introduccin
6.2 La estimacin y el estudio de viabilidad del sistema
6.3 Desarrollo de la tcnica propuesta para estimacin de costo, tiempo
y esfuerzo en SSBBCC
6.3.1 Reglas que se aplican al mtodo de medicin
6.3.2 Etapas del proceso de medicin
6.3.3 Desarrollo de cada una de las etapas del proceso
6.3.3.1 Determinacin de los objetivos de la medicin
6.3.3.2 Definicin de los lmites de la aplicacin a medir
6.3.3.3 Identificacin de interfaces
6.3.3.4 Identificacin de transacciones lgicas
6.3.3.4.1 Contabilizacin de mens e inicios de
transacciones
6.3.3.4.2 Contabilizacin de entradas y salidas en
6.3.3.5 Identificacin de conceptos u objetos
6.3.3.6 Ajuste de complejidad tcnica
6.3.3.7 Clculo de productividad, costo, tiempo y esfuerzo
79
79
80
80
82
84
85
85
87
88
89
90
91
92
97
Parte II - (Prctica) Construccin de la Herramienta de Software.
CAPTULO VII - DEFINICIN DEL PROYECTO DE DESARROLLO DE

SOFTWARE
7.1 Introduccin
101
7.2 Seleccin del ciclo de vida del desarrollo
101
7.3 Lista de procesos y actividades a desarrollar
101
7.4 Estimacin del esfuerzo de desarrollo (GPI 1)
103
7.4.1 Identificacin de elementos a desarrollar (GPI 1.1)
103
7.4.2 Clculo del esfuerzo (GPI 1.2)
103
7.5 Planificacin (GPI 2)
112
7.6 Seguimiento y control del proyecto (GPS)
113
7.7 Gestin de la configuracin
114
7.7.1 Identificacin de la configuracin
114
7.7.2 Control de la configuracin
119
7.7.3 Generacin de informes de estado
122
7.7.4 Auditora de la configuracin
123
7.8 Plan de sistemas de informacin (PSI)
125
7.8.1 Inicio del plan de sistemas de informacin (PSI 1)
125
7.8.2 Definicin y organizacin del plan de sistemas de
informacin (PSI 2)
125
7.8.3 Estudio de la informacin relevante (PSI 3)
126
iii
7.8.4 Identificacin de requisitos (PSI 4)

7.8.5 Estudio de los sistemas de informacin actuales (PSI 5)
7.8.6 Diseo del modelo de sistemas de informacin (PSI 6)
7.8.7 Definicin de la arquitectura tecnolgica (PSI 7)
7.8.8 Definicin del plan de accin (PSI 8)
7.8.9 Revisin y aprobacin del PSI (PSI 9)
7.9 Estudio de la viabilidad del sistema (EVS)
7.9.1 Establecimiento del alcance del sistema de informacin
(EVS 1)
7.9.2 Estudio de la situacin actual (EVS 2)
7.9.3 Definicin de requisitos del sistema (EVS 3)
7.9.4 Estudio de alternativas de solucin (EVS 4)
7.9.5 Valoracin de las alternativas (EVS 5)
7.9.6 Seleccin de la solucin (EVS 6)
7.10 Aseguramiento de la calidad del sistema (CAL)
7.10.1 Identificacin de las propiedades de calidad del sistema
(EVS-CAL)
7.10.2 Revisin del anlisis de consistencia (ASI-CAL)
7.10.2.1 Revisin del catlogo de requisitos (ASI-CAL 3.1)
7.10.2.2 Revisin de la consistencia entre productos (ASICAL 3.2)
7.10.3 Revisin de la arquitectura del sistema (DSI-CAL 1)
7.10.3.1 Revisin de la consistencia entre productos del
diseo (DSI-CAL 1.1)
7.10.4 Revisin de las pruebas unitarias, de integracin y del
sistema (CSI-CAL)
7.10.5 Revisin de las pruebas de aceptacin del sistema (IASCAL)
126
126
126
127
127
127
127
128
128
128
128
129
129
129
130
130
131
131
131
132
132
CAPTULO VIII - ANLISIS DEL SISTEMA DE INFORMACIN (ASI)

8.1 Introduccin
8.2 Definicin del sistema (ASI1)
8.2.1 Determinacin del alcance del sistema (ASI 1.1)
8.2.2 Identificacin del entorno tecnolgico (ASI 1.2)
8.2.3 Especificacin de estndares y normas (ASI 1.3)
8.2.4 Identificacin de usuarios participantes y finales (ASI 1.4)
8.3 Establecimiento de requisitos (ASI 2)
8.3.1 Obtencin de requisitos (ASI 2.1)
8.3.2 Especificacin de casos de uso (ASI 2.2)
8.3.3 Anlisis de requisitos (ASI 2.3)
8.3.4 Validacin de requisitos (ASI 2.4)
8.4 Identificacin de subsistemas de anlisis (ASI 3)
8.4.1 Determinacin de subsistemas de anlisis (ASI 3.1)
8.4.2 Integracin de subsistemas de anlisis (ASI 3.2)
8.5 Elaboracin del modelo de datos (ASI 6)
8.5.1 Elaboracin del modelo conceptual de datos (ASI 6.1)
8.5.2 Elaboracin del modelo lgico de datos (ASI 6.2)
iv
135
135
135
137
137
138
138
138
141
149
150
151
151
152
152
152
153
8.5.3 Normalizacin del modelo lgico de datos (ASI 6.3)

8.5.4 Especificacin de necesidades de migracin de datos y
carga inicial (ASI 6.4)
8.6 Elaboracin de un modelo de procesos (ASI 7)
8.6.1 Obtencin del modelo de procesos del sistema (ASI 7.1)
8.6.2 Especificacin de interfaces con otros sistemas (ASI 7.2)
8.7 Definicin de interfaces del usuario (ASI 8)
8.7.1 Especificacin de los principios generales de la interfaz (ASI
8.1)
8.7.2 Identificacin de perfiles y dilogos (ASI 8.2)
8.7.3 Especificacin de formatos individuales de interfaz de
pantalla (ASI 8.3)
8.7.4 Especificacin del comportamiento dinmico de la interfaz
(ASI 8.4)
8.7.5 Especificacin de formatos de impresin (ASI 8.5)
8.8 Anlisis de consistencia y especificacin de requisitos (ASI 9)
8.8.1 Verificacin de los modelos (ASI 9.1)
8.8.2 Anlisis de consistencia entre modelos (ASI 9.2)
8.8.3 Validacin de los modelos (ASI 9.3)
8.8.4 Elaboracin de la especificacin de requisitos del software
(ASI 9.4)
8.9 Especificacin del plan de pruebas (ASI 10)
8.9.1 Definicin del alcance de las pruebas (ASI 10.1)
8.9.2 Definicin de requisitos del entorno de pruebas (ASI 10.2)
8.9.3 Definicin de las pruebas de aceptacin del sistema (ASI
10.3)
8.10 Presentacin y aprobacin del anlisis del sistema de informacin
(ASI.11.1)
153
153
154
154
154
154
155
155
156
158
164
164
165
165
165
165
166
167
169
170
171
CAPTULO IX - DISEO DEL SISTEMA DE INFORMACIN (DSI)

9.1 Introduccin
9.2 Definicin de la arquitectura del sistema (DSI.1)
9.2.1 Definicin de niveles de arquitectura (DSI 1.1)
9.2.2 Identificacin de requisitos de diseo y construccin (DSI
1.2)
9.2.3 Especificacin de excepciones (DSI 1.3)
9.2.4 Especificacin de estndares y normas de diseo y
construccin (DSI 1.4)
9.2.5 Identificacin de subsistemas de diseo (DSI 1.5)
9.2.6 Especificacin del entorno tecnolgico (DSI 1.6)
9.2.7 Especificacin de requisitos de operacin y seguridad (DSI
1.7)
9.3 Diseo de la arquitectura de soporte (DSI 2)
9.4 Diseo de la arquitectura de mdulos del sistema (DSI 5)
9.4.1 Diseo de mdulos del sistema (DSI 5.1)
9.4.2 Diseo de comunicacin entre mdulos (DSI 5.2)
9.4.3 Revisin de la interfaz del usuario (DSI 5.3)
175
175
175
177
177
179
179
185
185
186
186
187
187
187
v
9.5 Diseo fsico de datos (DSI 6)

9.5.1 Diseo del modelo fsico de datos (DSI 6.1)
9.5.2 Especificacin de los caminos de acceso a los datos (DSI
6.2)
9.5.3 Optimizacin del modelo fsico de datos (DSI 6.3)
9.5.4 Especificacin de la distribucin de datos (DSI 6.4)
9.6 Verificacin y aceptacin de la arquitectura del sistema (DSI 7)
9.7 Generacin de especificaciones de construccin (DSI 8)
9.7.1 Especificacin del entorno de construccin (DSI 8.1)
9.7.2 Definicin de componentes y subsistemas de construccin
(DSI 8.2)
9.7.3 Elaboracin de especificaciones de construccin (DSI 8.3)
9.7.4 Elaboracin de especificaciones del modelo fsico de datos
(DSI 8.4)
9.8 Diseo de la migracin y carga inicial de datos (DSI 9)
9.9 Especificacin tcnica del plan de pruebas (DSI 10)
9.9.1 Especificacin del entorno de pruebas (DSI 10.1)
9.9.2 Especificacin tcnica de niveles de pruebas (DSI 10.2)
9.9.3 Revisin de la planificacin de las pruebas (DSI 10.3)
9.10 Establecimiento de los requisitos de implantacin (DSI 11)
9.11Presentacin y aprobacin del diseo del sistema de informacin
(DSI 12)
189
190
192
192
192
192
193
193
193
194
194
194
194
194
195
203
204
204
CAPTULO X - CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI)

10.1 Introduccin
10.2 Preparacin del entorno de generacin y construccin (CSI.1)
10.2.1 Implantacin de la base de datos fsica o archivos (CSI 1.1)
10.2.2 Preparacin del entorno de construccin (CSI 1.2)
10.3 Generacin del cdigo de los componentes y procedimientos (CSI
2)
10.3.1 Generacin del cdigo de componentes (CSI 2.1)
10.3.2 Generacin del cdigo de los procedimientos de operacin
y seguridad (CSI 2.2)
10.4 Ejecucin de las pruebas unitarias (CSI 3)
10.4.1 Preparacin del entorno de las pruebas unitarias (CSI 3.1)
10.4.2 Realizacin y evaluacin de las pruebas unitarias (CSI 3.1)
10.5 Ejecucin de las pruebas de integracin (CSI 4)
10.5.1 Preparacin del entorno de las pruebas de integracin (CSI
4.1)
10.5.2 Realizacin de las pruebas de integracin (CSI 4.2)
10.5.3 Evaluacin del resultado de las pruebas de integracin
(CSI 4.3)
10.6 Ejecucin de las pruebas de sistema (CSI 5)
10.6.1 Preparacin del entorno de las pruebas de sistema (CSI
5.1)
10.6.2 Realizacin de las pruebas de sistema (CSI 5.2)
vi
207
207
207
209
209
209
209
210
210
210
212
213
213
213
213
214
214
10.6.3 Evaluacin de los resultados de las pruebas de sistema

(CSI 5.3)
215
10.7 Elaboracin de los manuales del usuario (CSI 6)
215
10.8 Aprobacin del sistema de informacin (CSI 9)
215
CAPTULO XI - IMPLANTACIN Y ACEPTACIN DEL SISTEMA DE
INFORMACIN (IAS)
11.1 Introduccin
11.2 Establecimiento del plan de implantacin (IAS 1)
11.3 Formacin necesaria para la implantacin (IAS 2)
11.4 Incorporacin del sistema al entorno de operacin (IAS 3)
11.4.1 Preparacin de la instalacin (IAS 3.1)
11.4.2 Realizacin de la instalacin (IAS 3.2)
11.5 Carga de datos en el entorno de operacin (IAS 4)
11.6 Pruebas de implantacin del sistema (IAS 5)
11.7 Pruebas de aceptacin del sistema (IAS 6)
219
219
219
219
219
220
220
220
221
CAPTULO XII - EVALUACIN DEL SISTEMA DE INFORMACIN

12.1 Introduccin
231
12.2 Seleccin de proyectos para evaluacin de la herramienta de
software
231
CAPTULO XIII - CONCLUSIONES Y FUTURAS LNEAS DE INVESTIGACIN
13.1 Introduccin
13.1 Aspectos generales del trabajo de tesis
13.3 Consideraciones previas a las conclusiones
13.4 Futuras lneas de investigacin
239
239
239
240
BIBLIOGRAFA
Bibliografa
245
APNDICE A - ACRNIMOS
Acrnimos
249
APNDICE B GESTIN DEL PROYECTO

B1 Introduccin
B.2 Horas reales insumidas
B.3 Cronograma final de tareas
253
253
253
vii
ANEXO I DOCUMENTOS DE LAS ETAPAS DEL PROCESO DE MEDICIN

I.A. Documento de objetivos de medicin (DOM)
I.B. Documento de descripcin de lmites de la aplicacin (DDL)
I.C. Documento de transacciones lgicas identificadas (DTL)
I.D. Documento de entradas, salidas y conceptos
257
258
258
259
ANEXO II DESCRIPCIN DEL MODELO CONCEPTUAL DE DATOS

II.A. Tabla de entidades, atributos, descripcin y dominio
II.B Diagrama de entidades, relaciones e identificadores normalizado a
tercera forma normal 3FN
II.C. Correspondencia entre nombres de entidades y tablas de la base
de datos
II.D. Entidades que son accedidas por procesos primarios
263
266
266
267
ANEXO III MODELO DE PROCESOS DEL SISTEMA

III.A. Nivel 1 del modelo de procesos
271
III.B. Nivel 2 del modelo de procesos (modelo de procesos del sistema
ASI 7.1)
272
B.1 Subsistema de ingreso de datos de la aplicacin a medir
272
B.2 Clculos de valores de medicin
273
B.3 Mostrar resultados de la medicin
273
B.4 Actualizar parmetros de clculo
274
C. Descripcin de los procesos
274
ANEXO IV CODIGO DE LOS COMPONETES DEL SISTEMA DE
INFORMACIN
IV.A Cdigo de los componentes del sistema de informacin
279
ANEXO V GESTIN DE LA CONFIGURACIN

V.A Introduccin
V.B Informes
B.1 Informe de estado
B. 2 Informes de auditoria
305
305
305
306
ANEXO VI GESTIN DE LA CALIDAD

VI. Listas de verificacin
313
ANEXO VII MANUAL DEL USUARIO

VII.1 ndice del manual del usuario
VII.2 Introduccin
viii
317
318
VII.3 Requerimientos del sistema

VII.4 Ingreso al sistema
VII.5 Descripcin de las opciones principales
VII.6 Descripcin de cada una de las opciones principales
VII. 6.1 Ingreso de datos de la aplicacin a medir
VII. 6.2 Consulta de valores y resultados
VII. 6.3 Reportes y listados de proyectos
VII. 6.4 Actualizacin de parmetros de clculo
318
318
319
321
322
327
329
330
ix
PARTE I
(TERICA)
Aproximacin
a la Solucin:
Estimacin
de Proyectos
Para Sistemas
Basados
en
Conocimiento
CAPTULO I
INTRODUCCIN
CAPTULO I
INTRODUCCIN
1.1 INTRODUCCIN
La gestin es una tarea importante para poder controlar un proyecto y
asegurar su xito. Comienza con una serie de actividades que en su conjunto
se denominan planificacin del proyecto. Una de las primeras tareas de la
planificacin es la estimacin la cual proporciona valores aproximados de
costos, tiempos y esfuerzos que se necesitarn para su desarrollo; esa
aproximacin, implica un cierto grado de riesgo e incertidumbre; sin embargo,
contar con dicha informacin en etapas tempranas de desarrollo, permite tomar
decisiones importantes antes llevarlo a cabo.
Uno de los primeros pasos que debe realizar el encargado de proyecto (de
aqu en adelante EP) es determinar el tamao aproximado del producto
software que se est por construir o desarrollar. Para ello, y como paso previo
a la estimacin debe realizar mediciones con el objeto de obtener al menos dos
tipos de medidas [Pressman98]: directas (lneas de cdigo (LOC del ingls
lines of code)) e indirectas (puntos de funcin o funcionalidad (FP del ingls
function points)). Hay que hacer una diferenciacin entre estos dos tipos; ya
que entre las medidas directas del proceso de ingeniera, se incluyen el costo
y el esfuerzo; mientras que entre las medidas directas del producto, se
incluyen LOC, velocidad de ejecucin y defectos por unidad de tiempo. Por su
parte, las medidas indirectas, estn orientadas a la funcionalidad; pues este
parmetro no puede ser medido directamente [Pressman98]. La eleccin de la
tcnica a utilizar para la estimacin depende fundamentalmente de la
naturaleza del proyecto y del producto que se intenta medir. Las que se
estudian en el presente trabajo, devuelven como resultado FP, y la razn para
focalizar a este grupo, es que la estimacin tiene como objetivo contar en
etapas tempranas del desarrollo con valores estimados de tiempo, costo y
esfuerzo; precisamente en estas etapas todava no existe cdigo escrito.
En este trabajo, se analizan en total seis (6) tcnicas de estimacin (las ms
difundidas). Estas tcnicas cubren un amplio rango de tipos de desarrollos de
software; sin embargo, y mediante un estudio preliminar realizado en la etapa
de elaboracin del anteproyecto, no se ha observado explcitamente que las
mismas permitan hacer estimaciones en Sistemas Basados en Conocimientos
(de aqu en adelante SSBBCC). Esto amerita llevar a cabo una investigacin y
un anlisis de aquellas con el objeto de comprobar si es factible o si resulta
oportuno realizar adecuaciones, que permitan incluir a los tipos de desarrollo
antes mencionados.
Las tcnicas de estimacin que se analizan para determinar o comprobar si
se pueden aplicar a los SSBBCC son:
Function Point Analisys de Allan J. Albrecht.
Feature Points de Caper Jones.
MK II FPA de Charles R. Symons.
Captulo I Introduccin
Ing. Jos Daniel Ovejero
3-D Function Point de Scott Whitmire.

Full Function Points de Universidad de Qubec en Montreal
(Canad) de Symon y colaboradores.
COSMIC FFP de Common Software Measurement International
Consortium (COSMIC FFP) de Abran y colaboradores.
Con el fin de aplicar los conceptos que resulten del estudio de de la tcnica
de estimacin propuesta, y para cumplir con el objetivo del trabajo de tesis, se
construir una herramienta de software capaz de realizar los clculos
necesarios para obtener datos estimativos del tamao del producto software a
desarrollar, particularizado a aquellos desarrollos que incluyan a SSBBCC.
sta herramienta de software le permitir al EP ingresar las caractersticas
funcionales de la aplicacin a medir y de su entorno de desarrollo; y luego de
procesar los datos ingresados, devolver una cantidad de puntos de funcin
ajustados a partir de los cuales se podrn obtener estimaciones de costo,
tiempo y esfuerzo.
1.2 DESCRIPCIN DE LA COMPOSICIN DEL TRABAJO DE TESIS
El trabajo de tesis consta de dos partes: una terica (parte I) y otra prctica
(parte II).
La parte terica, donde se realiza una aproximacin a la solucin de la
estimacin en SSBBCC, est compuesta por los captulos (II, III, IV, V y VI). En
estos, se exponen los siguientes conceptos:
dominio del problema (captulo II),
estimacin y la gestin de proyecto (captulo III),
estudio de las tcnicas de estimacin (captulo IV),
estudio de los SSBBCC (captulo V),
presentacin de una tcnica para realizar estimaciones en SSBBCC
(captulo VI).
En el captulo II se explican los conceptos sobre los cuales gira el
desarrollo de la tesis: estimacin, sus tcnicas y los SSBBCC. Se define el
problema, su justificacin y los pasos necesarios para la obtencin de la
solucin a implementar.
En el captulo III, se estudian los conceptos bsicos de estimacin; su
proceso y los elementos que en ella intervienen.
En el captulo IV se estudian las tcnicas de estimacin, en qu desarrollos
es conveniente su aplicacin y cuales son sus fortalezas y debilidades. Al final
se realiza una clasificacin de los distintos tipos de software que son
susceptibles de ser medidos utilizando las diferentes tcnicas de estimacin.
En el captulo V, se estudian a los SSBBCC con el objeto de conocer como
funcionan, sus caractersticas y cuales son las etapas que se llevan a cabo en
este tipo de desarrollo. Adems se fundamenta y se exponen los motivos por
4
los cuales an no es posible realizar mediciones con estas tcnicas en

SSBBCC.
En el captulo VI, y una vez presentado por un lado a las tcnicas de
estimacin, y por otro a los SSBBCC, se analiza como las primeras pueden
adecuarse a aquellos. Se presenta; adems, una aproximacin que permite
efectuar mediciones en este tipo de software.
En la parte II y con el propsito de desarrollar una herramienta de software
capaz de representar la aproximacin a la solucin desarrollada en el captulo
VI, y demostrar que es factible obtener mtricas en estos tipos de sistemas, se
ejecutan los pasos de la metodologa mtrica V3. La parte II est conformada
por los captulos VII al XIII.
En el captulo VII, se realiza la definicin del proyecto del software. Se
selecciona el ciclo de vida, y la metodologa con la que se va a desarrollar la
herramienta de software. Luego, se hacen las estimaciones con el objeto de
determinar en forma aproximada el tiempo y esfuerzo necesario para acometer
dicho desarrollo; adems, se muestra una lista de las fases de la metodologa
seleccionada, con el orden de ejecucin de cada fase y el tiempo que se estima
que lleve cada una de estas. Por ltimo se gestiona la configuracin con el
propsito de identificar y mantener un ordenamiento de los productos que se
obtienen a lo largo del ciclo de vida.
En el captulo VIII, se realiza el anlisis del sistema de informacin
(ASI). Se define el trabajo a realizar en cuanto a requisitos y alcance del
sistema.
En el captulo IX, se realiza el diseo del sistema de informacin (DSI).
Se define la arquitectura de la herramienta a construir, diseo de un plan de
pruebas, y de las necesidades para la implantacin.
En el captulo X se procede a la construccin del sistema de
informacin (CSI). Se codifican los mdulos que han sido diseados en la
etapa DSI. Se realizan adems las pruebas unitarias, pruebas de integracin y
pruebas del sistema, con el objeto de detectar errores y; si corresponde, aplicar
las medidas correctivas. Se toman como casos de prueba a SSBBCC
desarrollados por tesistas del ITBA.
El captulo XI, corresponde a la implantacin y aceptacin del sistema
de informacin (IAS). En esta fase se traslada el sistema de su entorno de
desarrollo al entorno operativo; adems se realizan las pruebas de
implantacin y aceptacin del sistema de informacin.
En el captulo XII se realiza la evaluacin del sistema de informacin
con el objeto de determinar si resulta necesaria alguna correccin en los
parmetros bsicos de clculo. Para ello se utilizan datos de proyectos de

tesis; es decir, desarrollos de SSBBCC, elaborados por tesistas de la carrera
de Maestra en Ingeniera del Software de ITBA.
Por ltimo, en el captulo XIII, se exponen las conclusiones y futuras
lneas de investigacin para aspectos que no contemple el presente trabajo.
CAPTULO II
DOMINIO
DEL
PROBLEMA
CAPTULO II
DOMINIO DEL PROBLEMA
2.1 INTRODUCCIN
En este captulo se presenta el cuerpo de conocimientos sobre el cual gira
el desarrollo del proyecto de tesis. En primer lugar, se muestran conceptos
generales de estimacin y cual es el estado actual de la tecnologa que se
quiere implementar. Se describe adems, como son las tcnicas mayormente
difundidas pero sin profundizar, ya que en el captulo IV, se lleva a cabo un
estudio detallado de las mismas.
2.2 CONCEPTOS GENERALES DE ESTIMACIN
La gestin de proyectos es una de las reas clave dentro del proceso de
desarrollo de sistemas software. Tiene como finalidad la planificacin, el control
y el seguimiento de recursos humanos, tiempo y esfuerzo que se necesitan
antes y durante el desarrollo del software. Se puede encontrar en la literatura
existente muchas definiciones de lo que es la estimacin; en el desarrollo del
presente trabajo se ha escogido la siguiente: es la prediccin del personal, del
esfuerzo, de los costos y del tiempo que se requerirn para realizar todas las
actividades y construir todos los productos asociados con el proyecto [Moreno
Snchez-Capuchino98].
El desarrollo del software requiere de la estimacin como una herramienta
para controlar y administrar los recursos que se necesitan y que se utilizan
antes y durante el proyecto. No se puede considerar a la estimacin como una
ciencia exacta ya que existen numerosas variables humanas, tcnicas, del
entorno y polticas, que intervienen en su proceso y que pueden afectar los
resultados finales. Sin embargo, cuando es llevada a cabo en forma
sistemtica, se pueden lograr resultados con un grado aceptable de riesgo y
convertirla en un instrumento til para la toma de decisiones.
La estimacin es un proceso continuo que acompaa a todo el desarrollo
del proyecto y comienza usando pocas variables en un nivel alto de
abstraccin. A esta primera etapa se la denomina macro-estimacin y permite
obtener valores aproximados de costo, tiempo y esfuerzo como para estudiar la
viabilidad del proyecto. Una vez comenzado el proyecto y obtenidos estos
valores se pueden efectuar comparaciones, detectar desvos en el plan y
realizar los ajustes correspondientes. A medida que el proyecto progresa,
aumenta la informacin del mismo, la estimacin se torna de grano ms fino y
los parmetros descriptivos de las etapas iniciales se convierten en otros ms
detallados (como por ejemplo cantidad de mdulos o nmero de lneas de
cdigo). El aporte de un mayor caudal de informacin, proveniente del diseo,
programacin e implementacin disminuye el margen de error, hasta hacerse
mnimo en la fase de aceptacin del software.
Captulo II Dominio del

Problema
2.3. BREVE DESCRIPCIN DE LAS TCNICAS A ANALIZAR

Previo a realizar una descripcin de las tcnicas a analizar, resulta
conveniente exhibir cuales son las opciones que se presentan a la hora de
realizar estimaciones en el marco del desarrollo de proyectos de software. Aqu
se exponen las principales:
a) Basar la estimacin en proyectos similares: esta alternativa puede
funcionar muy bien cuando el proyecto tiene parecido con otros que ya
se hayan desarrollado. La desventaja de su implementacin es la de
requerir informacin de mediciones efectuadas en proyectos pasados
que no siempre estn disponibles y que adems no siempre representan
un buen indicador.
b) Utilizar tcnicas de descomposicin relativamente sencillas para generar
estimaciones: se basa en la descomposicin del problema redefinindolo
en conjuntos ms pequeos. Este enfoque tiene dos puntos de vista:
descomposicin del problema y descomposicin del proceso
[Pressman98]. La estimacin hace uso de ambas formas de
particionado. En este contexto es importante comprender primero el
mbito del software a construir y luego realizar una estimacin de su
tamao.
c) Desarrollar un modelo emprico: utiliza frmulas derivadas
empricamente para predecir costos, esfuerzos y tiempos [Pressman98].
Los datos empricos que soportan la mayora de los modelos de
estimacin se obtienen de una muestra limitada de proyectos; razn por
la cual este tipo de modelo no es adecuado para todas las clases de
software ni para todos los entornos de desarrollo.
El uso de estos modelos en forma combinada podra arrojar beneficios, ya
que permitira la comparacin de los resultados de unos contra otros.
Las tcnicas sobre las cuales se realiza el anlisis que tiene por objeto
determinar la aplicabilidad a SSBBCC, son las que se presentan a
continuacin:
Puntos de Funcin de Allan Albrecht: los primeros estudios en materia de

estimacin de proyectos software, fueron realizados a mediados de los
setenta por Allan J . Albrecht, quien en 1979 public por primera vez su
mtodo denominado puntos de funcin (FP). Los FP de Albrecht, se
obtienen utilizando una relacin emprica basada en medidas cuantitativas
del dominio de informacin del software y valoraciones subjetivas de su
complejidad. Sus objetivos son:
o Medir lo que el usuario pide y lo que el usuario recibe.
o Medir independientemente de la tecnologa utilizada
implantacin del sistema.
10
en
la

Problema
o Proporcionar una mtrica del tamao.

o Proporcionar un medio para la estimacin del software.
o Proporcionar un factor de normalizacin para la comparacin de
distintos software.
El anlisis de puntos de funcin se desarrolla considerando cinco
parmetros bsicos del sistema. Estos son:
o
o
o
o
o
Entradas externas,
salidas externas,
consultas externas,
grupos de datos lgicos internos,
grupos de datos lgicos externos.
Con estos parmetros se calculan los FP sin ajustar. A posteriori se aplica

un factor de ajuste que resulta de valoraciones subjetivas efectuadas a la
aplicacin que est siendo medida y a su entorno. La suma de los puntos
de funcin sin ajustar y el factor de ajuste representan los FP ajustados.
Una vez presentado el mtodo, su autor realiz mejoras sobre el modelo
inicial y ha publicado diferentes versiones del mismo. En 1986, Allan
Albrecht funda el Grupo Internacional de Usuarios de Puntos de Funcin
(IFPUG del ingls - International Function Point User Group) [IFPUG04].
Esta organizacin se encarga de la difusin del mtodo y de la publicacin
de manuales de uso y documentos de cmo sacar provecho del mismo. Los
FP fueron diseados originariamente para ser aplicados a sistemas de
informacin de gestin, es por ello que se puso nfasis en la dimensin de
datos, excluyendo las dimensiones funcionales y de control.
Feature Points (puntos de caractersticas): este mtodo fue propuesto por

Caper Jones [Jones87] como una alternativa que permitiera obtener puntos
de funcin en software cientfico y de ingeniera. Para evitar confusiones
con los FP, Jones lo denomin puntos de caracterstica (en ingls feature
points). Actualmente es usado con mucho xito en software del tipo CAD
(del ingls Computer Aided Design), sistemas embebidos y sistemas en
tiempo real.
MK II FPA:propuesto por Charles R. Symons [Symons98], este mtodo es

una derivacin de los FP de Albrecht, el que considera al sistema que se
est analizando, compuesto por cinco tipos de componentes (entradas
externas, salidas externas, consultas externas, grupos de datos lgicos
internos y externos), mientras que el MK II FPA mira al sistema como una
coleccin de transacciones lgicas discretas, compuestas cada una de ellas
por entrada, proceso y salida. Si se usan herramientas modernas de diseo
para el desarrollo del software, y esas herramientas permiten identificar
fcilmente las transacciones lgicas, resulta apropiado el uso de este
mtodo.

Problema
11
3-D Function Point: entre los aos 1989 y 1992, Scott Whitmire [Whitmire92]
desarroll un mtodo para la empresa internacional de aeronavegacin
Boing. El objetivo fue ampliar su espectro a sistemas con elevada
complejidad como los sistemas en tiempo real. El trmino 3D, se refiere a
que considera tres dimensiones en las que puede proyectarse un sistema
software; ellas son: datos, funciones y control. Visto de esta forma, resulta
atractivo el uso del mtodo, para aquel tipo de software, pero presenta el
inconveniente
de la necesidad de disponer de mayor cantidad de
informacin acerca del sistema, sobre todo de la complejidad de los
algoritmos a implementarse; esta informacin no siempre est disponible en
las primeras etapas del desarrollo.
Full Function Points (Puntos de Funcin Completos): esta tcnica ha sido

desarrollada por un equipo de la Universidad de Qubec en Montreal
(Canad) [Abran A., et al98], siendo muy eficiente en la medicin de puntos
de funcin en sistemas de control, tiempo real y embebidos.
Particularmente, los sistemas en tiempo real presentan dos factores crticos:
primero, el tiempo de respuesta y en segundo lugar, su interaccin con
entidades externas. Los FP de Albrecht eran limitados a la hora de medir
sistemas software en tiempo real. Estos ltimos trabajan con dos tipos de
estructura de datos de control: grupo lgico de ocurrencia mltiple, que
puede tener ms de una instancia por cada tipo de registro y el grupo lgico
de ocurrencia nica, que puede tener solamente una instancia por cada tipo
de registro. En lo que respecta a las transacciones, los sistemas en tiempo
real, presentan una variacin importante en la cantidad de subprocesos por
proceso; es decir, el mtodo debera contemplar que unos procesos
contaran con unos pocos subprocesos y otros en cambio, con un nmero
significativo de ellos. Los FP se basan ms en el nmero de procesos que
en el de subprocesos. Para paliar este inconveniente, FFP introduce en el
clculo no solamente a los procesos, sino que tambin incluye a los
subprocesos.
COSMIC FFP: a finales de 1998, un grupo de expertos en mtricas de

software, establecieron el Common Software Measurement International
Consortium (COSMIC FFP) [Abran A., et al99]. La iniciativa de COSMIC, ha
sido bsicamente la de dar respuesta a proveedores y a clientes de
servicios de desarrollo de software, principalmente en aquellos contratos de
terceros donde no haba reglas claras acerca del valor de este tipo de
servicio. En tal sentido COSMIC apunta a satisfacer tanto a proveedores de
software que deben traducir los requerimientos del cliente en un tamao del
software como un paso clave en la estimacin de los costos del proyecto,
como a los clientes que quieren conocer ese tamao recibido como un
componente importante para la medicin del rendimiento del proveedor. El
mtodo se puede aplicar a dominios de software de gestin, tiempo real e
hbridos.
12

Problema
2.4 SISTEMAS BASADOS EN CONOCIMIENTOS (SSBBCC)

Los ltimos cincuenta aos han estado regidos por cambios significativos
en las tecnologas de la informacin. Durante las dcadas del sesenta y setenta
algunos investigadores prefirieron estudiar un aspecto no menos importante de
las ciencias del conocimiento, denominado inteligencia artificial (IA). El objetivo
de los cientficos era el de desarrollar programas de computadora que
resuelvan problemas complejos y que para ello necesitaran de soluciones
inteligentes emulando el comportamiento de un ser humano. En este contexto,
se puede definir a la IA como una parte de las ciencias de la computacin
centrada en el desarrollo de programas de computadora inteligentes
[Waterman86]. Incluye a programas capaces de hallar soluciones en dominios
con alto nivel de complejidad, aprender con la experiencia, comprender un
lenguaje natural y en general, comportarse de alguna forma que sea
considerada inteligente.
Por su parte, los SSBBCC, conforman una de las reas bsicas de la IA,
relacionada con las capacidades humanas de actuar o interactuar en un
dominio determinado. La fortaleza de este tipo de programas, no se centra
precisamente en los formalismos ni en los esquemas de inferencia, mas bien
se encuentra en el conocimiento que posee. Este ltimo puede ser de carcter
pblico o privado: el primero se encuentra en soporte de libros, manuales,
documentacin formal e informal, registros y presentaciones; es decir, todo el
conjunto de informacin acerca del dominio del problema que est disponible y
en forma explcita. Por otro lado estn los conocimientos privados que los
expertos en el dominio del problema usan en forma implcita y que lo adquieren
con los aos de ejercicio de una profesin determinada. Un sistema experto (de
aqu en ms SE en singular y SSEE en plural) es un programa de
computadora que aplica conocimiento especfico o privado para lograr altas
prestaciones en un rea sustancial del problema [Waterman86]. Entre sus
cualidades estn las de representar conocimiento en forma simblica, justificar
su modo de razonamiento, exponer conclusiones, usar reglas heursticas e
interpretar datos ambiguos.
Un SBC, es un SE organizado de forma tal que separa su conocimiento
especfico (conocimiento del dominio del problema) del resto (conocimiento
general de cmo resolver el problema y conocimiento de cmo interactuar con
el usuario). Al conjunto de conocimientos especficos se lo denomina base de
conocimientos, y al resto motor de inferencias (conocimiento de cmo
resolver el problema) e interfaz del usuario (que permite la interaccin con el
usuario). En resumen, un SBC es un programa de computadora en el que el
conocimiento acerca del dominio del problema est explcito y separado del
resto del conocimiento [Waterman86]. Se puede decir que un SE es un
subconjunto de un SBC (figura 2.1).

Problema
13
Figura 2.1. Relacin entre IA, SBC y SE.

2.5 JUSTIFICACIN DEL PROBLEMA
Los sistemas basados en conocimiento (SSBBCC) son desarrollados y
aplicados en universidades y organizaciones dedicadas a la investigacin y en
las empresas de tecnologa de informacin. Estas ltimas han comenzado a
pensar en ellos con una visin comercial, provocando su expansin y su
inclusin en proyectos donde ambos coexisten, lo cual amerita, a que sean
tomados en cuenta al momento de realizar una estimacin global.
En base a un estudio preliminar efectuado en la etapa de elaboracin del
anteproyecto de tesis, se han analizado someramente las tcnicas enunciadas
en el punto 2.3, con el fin de verificar si son aplicables directamente a los
SSBBCC. Una vez finalizado estos estudios preliminares, es posible enunciar
que no se identifica expresamente la aplicabilidad de dichas tcnicas a
SSBBCC, lo cual lleva a la realizacin de estudios ms profundos cuyo objeto
es el de determinar si es posible aplicar los FP directamente a los tipos de
sistemas en cuestin, o si es necesaria alguna adecuacin para lograr
estimaciones ms precisas.
Una vez hechas las justificaciones del caso, es posible pensar en un
objetivo para el trabajo de tesis, el cual sera precisamente: determinar la
aplicabilidad de puntos de funcin a SSBBCC y construir una herramienta
o producto software que los incluya.
En este tratado solamente van a ser sometidos a estudio los mtodos que
se exhiben en el punto 2.3, dejando abierta la posibilidad del estudio de otros
mtodos o tcnicas para futuras investigaciones.
2.6 DESCRIPCIN DE LA SOLUCIN A IMPLEMENTAR
El desarrollo del trabajo de tesis, est compuesto por dos partes: una
terica y una prctica. Los temas que involucran a cada una de estas etapas
14

Problema
han sido descritos brevemente en el captulo I. El desarrollo de la parte terica

del proyecto de tesis incluye las siguientes fases:
a)
b)
c)
d)
Conceptos de gestin del proyecto y estimacin (captulo III).

Estudio detallado de los mtodos (o tcnicas) de estimacin (captulo
IV).
Estudio detallado de los SSBBCC (captulo V).
Adecuacin para su aplicacin en SSBBCC (captulo VI).
El estudio de los SSBBCC, permite conocer caractersticas que los

diferencian de otros tipos de sistemas denominados convencionales. Entre
estos ltimos, se pueden encontrar entre otros sistemas de gestin
administrativa, sistemas operativos, software de base, software de aplicacin y
software en tiempo real. Por su parte el estudio y anlisis de los mtodos de
estimacin permitir conocer como trabajan y como se pueden aplicar sus
principios a los SSBBCC.
La segunda parte del trabajo de tesis (o parte prctica o de
implementacin), incluye el desarrollo de una herramienta o producto
software capaz de calcular el tamao aproximado del producto software basado
en su funcionalidad para proyectos que involucren a SSBBCC. El uso de la
herramienta permitir al EP estimar costos, tiempos y esfuerzos que se
necesitan para llevar a cabo el desarrollo de un producto software.
Para orientar al lector, se describen someramente los pasos que el usuario
o el EP debera realizar para interactuar con la herramienta. Estos se detallan
en orden de ejecucin en los siguientes puntos:
a) Ingresar las caractersticas del software que se quiere medir.
b) Ingresar las caractersticas del entorno de desarrollo.
c) La herramienta devuelve como resultado, una cantidad estimada de
puntos de funcin sin ajustar.
d) Aplicar factor de ajuste
e) Calcular los FP completos (ajustados).
f) Aplicar ratios que determinan en forma aproximada recursos a utilizar
(costo, tiempo y esfuerzo).
El proceso de clculo y obtencin de puntos de funcin y el esfuerzo
necesario para acometer el desarrollo del software, se muestra en la figura 2.2.

Problema
15
Figura 2.2. Proceso de clculo de esfuerzo, costo y tiempo.
16

Problema
CAPTULO III
LA ESTIMACIN
Y LA GESTIN
DEL
PROYECYO
CAPTULO III
LA ESTIMACIN Y LA GESTIN DEL PROYECTO
3.1 INTRODUCCIN
En este captulo se exhiben los conceptos relativos a la estimacin, su
proceso y los elementos que en ella intervienen. Al final se realiza una
clasificacin de los distintos tipos de software que son susceptibles de ser
medidos utilizando tcnicas de estimacin.
3.2. QU SE ENTIENDE POR ESTIMACIN
Estimar, consiste en determinar el valor de una variable desconocida a
partir de otras conocidas o de una pequea cantidad de valores conocidos de
esa variable. La estimacin forma parte de la inferencia estadstica. El
razonamiento por inferencia va de lo particular a lo general y de lo conocido a
lo desconocido; mientras que el razonamiento por deduccin va de lo general
a lo particular y de lo desconocido a lo conocido.
Puede considerarse a la estimacin como una actividad en el marco de la
gestin de proyectos de software. El objetivo de esta actividad es conocer el
tamao aproximado del sistema a desarrollar, y establecer el costo, la duracin
y los recursos necesarios para conseguir desarrollarlo [Mtrica V.304].
En ocasiones se realizan estimaciones por analoga o similitud con otros
proyectos que ya hayan sido finalizados y de los que se cuentan con valores
de costo, tiempo y esfuerzo. En la prctica es difcil que existan tales
similitudes; razn por la cual existen tcnicas (o mtodos) de estimacin,
para determinar en forma aproximada y con un grado aceptable de exactitud el
tamao de un producto software que se est por desarrollar. Cada una de
estas tcnicas (que se vern en el captulo IV) se adapta mejor que otras a los
diferentes tipos de software. Ahora bien, si ms de una tcnica se puede
aplicar al mismo producto, y si los costos de estimacin lo permiten,
convendra realizar ms de una estimacin con el objeto de comparar los
resultados arrojados por una contra otra.
Para acometer un proceso de estimacin, se deben cumplir una serie de
requisitos, entre los cuales se mencionan:
establecer de antemano el mbito del proyecto,
se pueden usar mtricas de proyectos anteriores,
se puede dividir el proyecto en pequeas partes (o sub-proyectos) con el fin
de facilitar la estimacin.
Captulo III La Estimacin y

la Gestin del Proyecto
19
3.3 ESTABLECIMIENTO DE MBITO Y OBJETIVOS DEL PROYECTO

Tanto clientes como desarrolladores deben ponerse de acuerdo para definir
el mbito y el objetivo del proyecto. Una vez establecidos, se pueden
considerar soluciones alternativas. An haciendo un estudio no muy detallado
de esas alternativas, permitirn tanto a gestores como a desarrolladores
seleccionar el mejor enfoque dadas unas restricciones de fecha, recursos
humanos y presupuestos.
El mbito del software describe la funcin, el rendimiento, las
restricciones, las interfaces y la fiabilidad [Pressman98]. Primero se
evalan las funciones descritas en el enunciado del mbito, y en algunos
casos se refinan para dar ms detalles antes del comienzo de la estimacin.
Las consideraciones de rendimiento, abarcan los requisitos de tiempo de
respuesta y procesamiento. Las restricciones identifican los lmites del
software originados por el hardware externo, por la memoria disponible y por
otros sistemas existentes. Las interfaces, definen las comunicaciones con el
usuario ya sean entradas o salidas; por ltimo las consideraciones de
fiabilidad, incluyen a parmetros que determinan hasta qu punto se puede
confiar en el funcionamiento del software libre de errores. Entre esos
parmetros se encuentran: tolerancia a errores, consistencia, precisin y
simplicidad. Las medidas que determinan la fiabilidad son entre otras: cantidad
de errores por FP, cantidad de errores por FP despus de la implementacin y
cantidad de errores detectados por usuarios.
3.4 MTRICAS Y MEDIDAS
Las mtricas se refieren a un amplio elenco de medidas para el software de
computadora. En la mayora de los procesos de desarrollo, las mtricas o
medidas permiten un mejor entendimiento tanto de los procesos (que se
utilizan para el desarrollo) como de los productos. El proceso se mide con la
intencin de mejorarlo; mientras que el producto se mide para aumentar su
calidad. Se puede definir a las mtricas como: la aplicacin continua de
tcnicas basadas en las mediciones de los procesos de desarrollo del software
y sus productos, para producir una informacin de gestin significativa y a
tiempo [Moreno Snchez-Capuchino98].
Podra parecer que la necesidad de medir es algo evidente ya que la
medicin arroja resultados que permiten la gestin del proyecto. Sin embargo,
la realidad es diferente; y genera controversias acerca de: la tcnica utilizar, la
exactitud de los datos, las comparaciones entre gente y productos o procesos,
etc. [Pressman98].
En el dominio del software, las medidas pueden ser directas o indirectas.
Entre las primeras se pueden citar al costo y calidad y estn representadas por
lneas de cdigo producidas y entre las segundas que incluyen a la calidad,
complejidad, eficiencia, fiabilidad, facilidad de mantenimiento y otras tantas
capacidades estn representadas por los puntos de funcin.
20

3.5 TIPOS DE SOFTWARE

Con el fin de poder mostrar los distintos tipos de software existentes en el
mercado, se realiza una categorizacin [Pressman98], para las aplicaciones
ms significativas. Esta clasificacin no es excluyente y puede haber tipos de
software que no estn incluidos, lo cual no implica que no puedan ser objeto
de mediciones.
a) Software de sistemas: es un conjunto de programas que ha sido
construido con la finalidad de servir a otros programas. Algunos
ejemplos de esta categora son: editores, compiladores, utilidades de
gestin de archivos, componentes del sistema operativo, utilidades para
manejo de dispositivos de entrada y salida y procesadores de
comunicaciones. Se caracterizan por una fuerte interaccin con el
hardware de la computadora, utilizacin de mltiples usuarios,
operaciones concurrentes, compartimiento de recursos y mltiples
interfaces.
b) Software de tiempo real: mide, analiza y controla sucesos del mundo
real, de acuerdo a como van ocurriendo. Sus elementos son:
un componente de adquisicin de datos, que recolecta y da formato a
la informacin recibida del entorno externo,
un componente de anlisis, que se encarga de transformar la
informacin segn lo requiera la aplicacin,
un componente de control o salida que responde al entorno externo,
un componente de monitorizacin que coordina a todos los dems
componentes.
Es importante en este tipo de sistemas, que la respuesta sea
verdaderamente en tiempo real; es decir, la diferencia de tiempo entre la
recepcin de un estmulo ( o adquisicin de un dato) y la respuesta
debe responder dentro de las restricciones de tiempo planteadas en los
requisitos.
c) Software de gestin: representa el procesamiento de la informacin
comercial y constituye el mayor porcentaje de las aplicaciones de
software. Son algunos ejemplos de este tipo de software, sistemas de
nminas de empleados, sistemas bancarios y sistemas comerciales de
ventas. Se caracterizan por acceder a bases de datos donde se
encuentra alojada fsicamente la informacin.
d) Software de ingeniera y cientfico: se caracteriza por los algoritmos de
manejo de nmeros. Algunos ejemplos de este tipo de software son
aquellas aplicaciones que analizan valores recibidos desde algn
dispositivo. Otro aspecto de estos tipo de software son los programas
CAD (del ingls computer aided design) o diseo asistido por
computadora.

21
e) Software empotrado: los productos inteligentes se han convertido el

algo comn en casi todos los mercados de consumo e industriales
[Pressman98]. Este tipo de software reside en la memoria de solo
lectura (ROM del ingls read only memory) y se utiliza para controlar
productos industriales y de consumo. Como ejemplo de este tipo de
software se pueden citar a: funciones de control de hornos de
microondas, funciones digitales de automotores, etc.
f) Software de computadoras personales: como ejemplo de este tipo de
software, procesadores de texto, hojas electrnicas de clculo, grficos
por computadora, gestores de bases de datos, aplicaciones financieras,
etc.
g) Software de inteligencia artificial: este tipo de software hace uso de
algoritmos no numricos para resolver problemas complejos.
Actualmente el rea ms activa de este tipo de software corresponde a
los sistemas expertos (SE) y a los sistemas basados en
conocimientos (SSBBCC) [Watterman85]. Un anlisis en detalle de
este tipo de software se realiza en el captulo IV. Otras aplicaciones de
este estilo son las llamadas redes neuronales de computadoras las
cuales simulan el comportamiento de una neurona biolgica para
resolver problemas de reconocimiento de patrones y de aprendizaje.
3.6 ESTIMACIN BASADA EN LA FUNCIONALIDAD
Las primeras investigaciones acerca de las medidas del software fueron
realizadas en la dcada del setenta en la empresa IBM (del ingls international
business machine) por Allan J Albrecht [IBM75], quin not que las mediciones
que se efectuaban en ese entonces apuntaban a medir el tamao de los
programas en lneas de cdigo. Esta prctica variaba en funcin de la
tecnologa, lo cual impeda realizar las mediciones en etapas tempranas del
desarrollo, donde an no se tiene en claro que tecnologa se va a usar ni que
metodologa se va a emplear para llevar adelante dicho desarrollo.
Hacia fines del ao 1979, fue el mismo Allan Albrecht [Albrecht79] quin
descubri una tcnica que permita medir independiente de la tecnologa
usada, del lenguaje de programacin, de la metodologa de desarrollo y de la
capacidad del equipo de trabajo para desarrollar la aplicacin [IFPUG,CPM00].
Es as que la denomin FPA (del ingls function point analysis). Fue esta la
primera tcnica capaz de medir funcionalidad en el software y proporcionar
valores aproximados del tamao en etapas tempranas del desarrollo. Los
puntos de funcionalidad son una medida al igual que el metro, el kilmetro, el
kilogramo, la hora, etc.
En todo proyecto de ingeniera, es necesario y totalmente apropiado
realizar mediciones de los distintos productos que se fabrican o se construyen.
La ingeniera del software no est exenta de este proceso y la razn
fundamental que es comn a la mayora (por no decir a la totalidad de las
22

ramas de la ingeniera) es el control que se puede y se debe llevar a cabo y los

desvos que se pueden corregir con los resultados obtenidos de esas
mediciones.
Cada punto de funcionalidad (PF) representa a una cantidad de lneas de
cdigo, las que en definitiva determinan el tamao de la aplicacin a
desarrollar. En las etapas tempranas del desarrollo, esa medida es aproximada
y sirve, entre otras cosas, para decidir la realizacin o no del proyecto. Los PF
no solamente permiten obtener el tamao del producto software, sino que
adems se pueden hacer estimaciones del costo, esfuerzo y duracin
aproximados.
Los PF son una medida indirecta del tamao y los distintos fabricantes de
software, publican valores (cantidad de lneas de cdigo) por cada PF segn la
herramienta seleccionada para la programacin.

23
CAPTULO IV
ESTUDIO
DE LAS
TCNICAS
DE
ESTIMACIN
CAPTULO IV
ESTUDIO DE LAS TCNICAS DE ESTIMACIN
4.1 INTRODUCCIN
En este captulo se realiza un estudio detallado de las tcnicas de
estimacin enunciadas en el captulo II, con el objeto de que el lector conozca
en detalle como funcionan. Se muestran reglas para identificar los elementos
del sistema que debieran ser considerados para la contabilizacin o la
medicin. Al finalizar el captulo se hace un resumen de las tcnicas y se
expone un cuadro de la aplicabilidad de las tcnicas a distintos tipos de
software.
4.2 ESTUDIO DE LAS TCNICAS DE ESTIMACIN
En este apartado y en los subsiguientes, se muestra un estudio de las
tcnicas de estimacin ms difundidas. Entre esas tcnicas estn la de puntos
de funcin de Albrecht, puntos de caracterstica de Jones, el mtodo 3D de
Whitmire, el Mark II de Symons y el puntos de funcin completos de Abran y
colaboradores.
4.2.1 TCNICA DE ESTIMACIN DE PUNTOS DE FUNCIN (FP)
[Albrecht79]
Esta tcnica se basa en la descomposicin de un sistema en componentes
ms pequeos, de tal forma que estos puedan ser medidos y, o analizados
con mayor facilidad. El mtodo intenta enfocar al software desde el punto de
vista del usuario y; la medicin, se realiza cuantificando la funcionalidad
brindada a dicho usuario, partiendo fundamentalmente de diseos lgicos.
En el marco del clculo de los FP, las aplicaciones se dividen en inco
componentes:
Salidas Externas (del ingls External Output - EO).
Consultas Externas (del ingls External Queries - EQ).
Entradas Externas (del ingls External Inputs EI).
Archivos Lgicos Internos (del ingls Internal LogicaL File ILF).
Archivos Lgicos Externos (del ingls External LogicaL File ELF).
Los tres primeros de esta lista, corresponden a funciones
transaccionales que actan sobre archivos (grupos lgicos de datos)
actualizando la informacin contenida en estos. Los dos ltimos componentes
(ILF y ELF) son las entidades, almacenes o grupos lgicos de datos
(comnmente denominados archivos).
Captulo IV Estudio de las

Tcnicas de Estimacin
27
4.2.1.1 IDENTIFICACIN DE GRUPOS LGICOS DE DATOS Y FUNCIONES

TRANSACCIONALES EN LAS APLICACIONES A MEDIR
Con respecto a los datos, existen dos grupos que se identifican al principio
y son: grupos lgicos de datos (ILF y ELF). Las transacciones, estn
identificadas mediante las funciones transaccionales (EO, EI y EQ). Una vez
definidos y agrupados estos componentes, se puede mostrar la funcionalidad
vista desde una perspectiva del usuario (figura 4.1).
Figura 4.1. Funcionalidad desde una perspectiva del usuario.

En toda aplicacin, existe una cantidad determinada de ILF, ELF, EI, EO y
EQ. Para cada uno de estos, adems, se debe medir la complejidad cuyo valor
se obtiene de unas reglas detalladas (que se vern ms adelante). Esa
complejidad puede ser baja, media o alta; y tomar valores en funcin de esos
parmetros.
4.2.1.2 IDENTIFICACIN DE GRUPOS LGICOS DE DATOS (ILF Y ELF)
Los ILF o archivos lgicos internos representan a grupos de datos
relacionados lgicamente o informacin de control que se mantiene dentro de
los lmites de la aplicacin. Las reglas para identificar a ILFs se muestran en la
tabla 4.1.
Regla
R1
R2
R3
R4
Como Identificar ILFs

Grupo de datos lgicos identificables por el usuario que cubre de manera
completa requisitos especficos de este.
Grupo de datos lgicos mantenidos dentro de los lmites de la aplicacin.
Grupo de datos lgicos mantenido o modificado mediante un proceso
elemental de la aplicacin.
Grupo de datos lgicos que no se ha contabilizado como ELFs.
Tabla 4.1. Reglas para identificar a ILFs.

Los archivos lgicos externos (ELF), representan a grupos de datos
relacionados lgicamente o informacin de control reconocida por el usuario
que puede ser referenciada y mantenida fuera de los lmites de la aplicacin.
Este ltimo concepto representa la principal diferencia entre un ILF y un ELF.
Las reglas para identificar a ELFs, se muestran en la tabla 4.2
28

Regla
R1
R2
R3
R4
Como Identificar ELFs

Grupo de datos lgicos identificables por el usuario que cubre de
manera completa sus requisitos.
Grupo de datos lgicos referenciados pero externos a la aplicacin que
est siendo contada.
Grupo de datos lgicos mantenidos fuera de los lmites de la aplicacin.
Grupo de datos lgicos que no ha sido contado como un ILF.
Tabla 4.2. Reglas para identificar a ELFs.

Muchas veces se relacionan a ILFs y a ELFs con archivos fsicos. Esto es
un grave error, ya que cuando se hace referencia a entidades puede no haber
una relacin directa con aquellos. Por ejemplo, si existe una entidad persona,
los atributos y valores de esta entidad pueden estar diseminados en una o
varias tablas o archivos fsicos de datos (por ejemplo, personas, tipos de
personas, domicilios de personas, etc.). En estos casos se debe contar como
un solo ILF o ELF y no tres o ms.
4.2.1.2.1 DETERMINACIN DE LA COMPLEJIDAD PARA GRUPOS DE
DATOS LGICOS
La complejidad de los grupos de datos lgicos se sustenta sobre dos
parmetros: tipo de dato elemental (o primario) o DET (del ingls Data Element
Type) y tipo de registro elemental (o primario) o RET (del ingls Record
Element Type).
Un DET es un atributo (o campo lgico) reconocible por el usuario que
compone una entidad. Para el conteo de DETs, se aplican las siguientes
reglas:
Las claves forneas para referenciar otro ILF segn los requerimientos
tambin se cuenta como DET.
Un atributo (o campo lgico) nico pero almacenado en ms de un
archivo fsico o tabla, se cuenta una sola vez.
dem para los que se repiten.
Los atributos (o campos lgicos) que aparecen por la aplicacin de
tcnicas de implementacin pero que no son reconocibles por el usuario
no se cuentan como DETs.
Un RET representa a un subgrupo de datos elementales reconocibles por

el usuario. Se debe contar como un RET por cada uno de estos. Existen dos
tipos de subgrupos:
Opcional: son aquellos que el usuario tiene la opcin de usar solamente

uno o ningn subgrupo en un proceso elemental que agrega o crea una
instancia de datos.
Obligatorios: son subgrupos que el usuario debe usar al menos uno.

29
Las reglas que se aplican en el momento de contar RETs son las

siguientes:
Contar como un RET a cada subgrupo opcional u obligatorio de un ILF

y, o ELF.
Si no hay subgrupos se debe contar a un ILF o ELF como un RET.
Una vez que se han identificado los DETs y RETs, de cada archivo lgico,
se debe determinar su complejidad, de acuerdo a los valores de la tabla 4.3.
1 a 19 DETs
20 a 50 DETs
51 o ms DETs
1 RET
Baja
Baja
Media
2 a 5 RETs
Baja
Media
Alta
6 o ms RETs
Media
Alta
Alta
Tabla 4.3. Determinacin de la complejidad de ILFs y ELFs.

4.2.1.3 IDENTIFICACIN DE FUNCIONES TRANSACCIONALES (EI, EO,
EQ)
Una entrada externa (EI) es un proceso elemental o una accin que
procesa datos o informacin de control que provienen desde afuera de los
lmites de la aplicacin a medir. Su procedencia puede ser va un programa
externo (se ejecuta fuera de los lmites) o mediante la accin de ingreso de
datos de un usuario a travs de un dispositivo de entrada (por ejemplo teclado,
ratn, o cualquier dispositivo de entrada de datos). Las entradas externas para
que sean consideradas como tales deben mantener por lo menos un ILF y, o
alterar el comportamiento del sistema. Las reglas que se aplican para identificar
las EIs se muestran en la tabla 4.4.
Regla
R1
R2
R3
R4
Como Identificar EIs

Los datos se reciben desde afuera de los lmites de la aplicacin
Los datos mantienen un ILF a travs de un proceso elemental de la aplicacin
Un proceso es la unidad ms pequea de actividad significativa para el usuario
final.
El proceso identificado debe observar algunas de las siguientes reglas:
Su lgica de proceso es nica con respecto a otras EIs de la
aplicacin.
Los elementos de datos identificados son distintos a los de otras EIs de
la aplicacin.
Los ILF referenciados son diferentes..
Tabla 4.4. Reglas para identificar a EIs.

Una salida externa (EO) es un proceso elemental que enva datos o
informacin de control fuera de los lmites de la aplicacin. Su objetivo es
30

presentar informacin al usuario luego del procesamiento lgico de datos o de

la informacin de control obtenida. El procesamiento lgico debe contener al
menos una frmula o clculo matemtico o crear datos derivados de los
obtenidos; adems una EO podra mantener por lo menos un ILF o alterar el
comportamiento del sistema. Las reglas para identificar EOs, se muestran en la
tabla 4.5
Regla
R1
R2
R3
R4
R5
R6
R7
R8
Como Identificar EOs

Los datos se envan a travs de un proceso elemental fuera de los lmites de la
aplicacin
Los datos mantienen un ILF a travs de un proceso elemental de la aplicacin
Un proceso es la unidad ms pequea de actividad significativa para el usuario
final.
El proceso identificado debe observar algunas de las siguientes reglas:
Su lgica de proceso es nica con respecto a otras EOs de la
aplicacin.
Los elementos de datos identificados son distintos a los de otras EOs
de la aplicacin.
Los ILF referenciados son diferentes.
Deben cumplirse al menos una de las siguientes condiciones:
El proceso elemental contiene al menos una frmula matemtica.
El proceso crea datos derivados.
El proceso que genera la salida mantiene al menos un ILF.
El proceso que genera la salida altera el comportamiento del sistema.
La transferencia de datos a otras aplicaciones se cuenta como EO.
Los informes escritos y en lnea se cuentan como salidas independientes.
Los grficos se cuentan como salidas independientes.
Tabla 4.5. Reglas para identificar a EOs.

Las consultas externas (EQ) identifican a procesos elementales o
acciones que envan datos fuera de los lmites de la aplicacin que se quiere
medir. Ningn ILF es mantenido mientras se procesa una accin de una EQ ni
tampoco se altera el comportamiento del sistema. Su objetivo es presentar
informacin al usuario mediante una simple obtencin de datos o informacin
de control. La diferencia con EOs radica fundamentalmente en que su
procesamiento lgico no debe contener frmulas o clculos matemticos, ni
tampoco debe crear datos derivados de los obtenidos. Las reglas que se
aplican para identificar EQs, se muestran en la tabla 4.6.

31
Regla
R1
R2
R3
R4
R5
R6
R7
R8
R9
R10
Como Identificar EQs

Una peticin entra en los lmites de la aplicacin.
El resultado de esa peticin sale de los lmites de la aplicacin.
Existe recuperacin de datos.
Los datos recuperados no contienen datos derivados.
El proceso lgico no contiene clculo o frmulas matemticas.
El proceso que genera la EQs no mantiene ningn ILF y no altera el
comportamiento del sistema..
La peticin de entrada y el resultado de salida juntos, hacen del proceso la
unidad de actividad ms pequea que es significativa para el negocio del
usuario.
El proceso es autocontenido y deja a la aplicacin en estado consistente.
El proceso no actualiza ILFs.
El proceso debe verificar las siguientes reglas:
La lgica del proceso sobre la entrada y la salida es nica con respecto a
otras EQs.
Los elementos de datos que forman la entrada y la salida son distinto
respecto a los de otras consultas de la aplicacin.
Los ficheros lgicos referenciados son distintos.
Tabla 4.6. Reglas para identificar a EQs.

4.2.1.3.1 DETERMINACIN DE LA COMPLEJIDAD PARA FUNCIONES
TRANSACCIONALES
La determinacin de la complejidad de las EIs, se realiza considerando a
dos parmetros. Uno de ellos son los DETs o tipos de datos elementales (visto
en prrafos anteriores) y el otro corresponde a los tipos de archivos
referenciados o FTR (del ingls File Type Referenced). Las reglas que se
deben aplicar para el conteo de DETs, son las siguientes:
Es considerado como DET todo campo reconocible por el usuario y no
repetido que cruza las fronteras de la aplicacin.
Una definicin del comienzo de la ejecucin del proceso (si existen

varias formas contar solamente una).
Mensajes de error que se muestran durante la ejecucin del proceso ( si

hay varios mensajes de error contar solamente uno).
Con respecto a los FTRs se deben contar solo uno por cada archivo interno
ledo y, o mantenido por el proceso de entrada. La tabla 4.7 muestra el grado
de complejidad de las EIs en funcin de la cantidad de DETs y FTRs.
32

1 a 4 DETs
5 a 15 DETs
16 o ms DETs
1 FTR
Baja
Baja
Media
2 FTRs
Baja
Media
Alta
3 o ms FTRs
Media
Alta
Alta
Tabla 4.7. Determinacin de la complejidad de EIs en funcin de DETs y

FTRs.
Para EOs y EQs que cruzan los lmites de la aplicacin, se deben aplicar
las siguientes reglas:
Contar un DET por cada campo reconocible por el usuario no

repetido, que ingresa a la aplicacin y que se requiere para
especificar cuando, que o como deben ser recuperados los datos de
salida.
Contar un DET por cada campo reconocible por el usuario no
repetido que sale de los lmites de la aplicacin.
Un dato que entra y sale de la aplicacin debe ser contado
solamente una vez.
Contar un DET por todos los mensajes de error del proceso.
Contar un DET por la iniciacin del proceso, an habiendo varias
formas de hacerlo.
No se deben contar datos recuperados o derivados por el sistema
que no cruzan los lmites de la aplicacin.
Contar un FTR por cada archivo interno ledo por el proceso de
salida o consulta.
En la tabla 4.8 se muestra la cantidad de DETs y FTRs identificados y

relacionados con su nivel de complejidad:
1 a 5 DETs
6 a 19 DETs
20 o ms DETs
1 FTR
Baja
Baja
Media
2 o 3 FTRs
Baja
Media
Alta
4 o ms FTRs
Media
Alta
Alta
Tabla 4.8. Determinacin de la complejidad de EOs y EQs en funcin de

DETs y FTRs.
4.2.1.4 APLICACIN DE FORMULAS PARA CONTEO DE LOS PUNTOS DE
FUNCIN SIN AJUSTAR
Una vez identificados los componentes, su cantidad y su nivel de
complejidad (bajo, medio o alto), se realiza la cuenta de los FP sin ajustar. En

33
la tabla 4.9 se muestran los valores (o pesos) que puede adquirir cada uno de
los componentes en funcin de su complejidad.
Componente
Complejidad
Peso
Cantidad
Subtotal (peso *
cantidad)
Alta
15
ILF
Media
10
Baja
7
Alta
10
ELF
Media
7
Baja
5
Alta
6
EI
Media
4
Baja
3
Alta
7
EO
Media
5
Baja
4
Alta
6
EQ
Media
4
Baja
3
Total de FP sin ajustar es la sumatoria del producto Total de puntos de FP sin
de los pesos, por las cantidades segn sea el ajustar
componente.
Tabla 4.9. Valores de los pesos para FP sin ajustar.
4.2.1.5 CALIBRACIN DE LOS FP EN BASE A LAS CARACTERSTICAS
GENERALES DE LA APLICACIN
Los FP de Albrecht, sin ajustar deben ser calibrados (o ajustados) con otros
catorce (14) componentes, cuyos valores dependen del entorno de desarrollo.
Estas caractersticas en su conjunto se denominan tambin factores de ajuste
(FA del ingls factors adjust) y son enunciadas a continuacin:
1. Comunicaciones de datos.
2. Datos o procesamiento distribuidos.
3. Objetivos de rendimiento.
4. Configuracin utilizada masivamente.
5. Tasa de transaccin.
6. Entrada de datos en lnea.
7. Eficiencia para el usuario.
8. Actualizacin en lnea.
9. Procesamiento complejo.
10. Reutilizacin.
11. Facilidad de instalacin y conversin.
12. Facilidad de operacin.
13. Puestos mltiples.
34

14. Facilidad de cambio.

Estos factores de ajuste pueden tomar valores entre cero (0) y cinco (5).
Es decir, cero cuando la caracterstica del componente est ausente o es nula
y cinco cuando puede alcanzar una valoracin mxima; tambin se pueden
asociar porcentajes, como se muestra en la tabla 4.10.
Valor del
FA
0
1
2
3
4
5
Influencia en el
Sistema
Ninguna
Insignificante
Moderada
Media
Significativa
Fuerte
Porcentaje que Afecta o es

Requerido por la Aplicacin
0%
1- 20 %
21 - 40 %
41 - 60 %
61 - 80 %
81 - 100%
Tabla 4.10. Factores de influencia en el sistema para clculo de FA.

A continuacin se realiza una breve descripcin de cada una de las
caractersticas y los posibles valores que debera considerar el encargado de
un proyecto a la hora de realizar la estimacin del tamao del software.
1. Comunicacin de datos: son los datos o informacin de control que la
aplicacin utiliza, se enva o recibe a travs de las facilidades (sistema) de
comunicacin. A modo de ejemplo se puede citar a aquellas aplicaciones
que se desarrollan para entidades bancarias y que registran transacciones
en distintos puntos geogrficos, las cuales hacen uso en forma masiva de
las comunicaciones de datos (ya sea va satlite o va telefnica). Los
valores que puede tomar la caracterstica son:
Descripcin de la caracterstica
La aplicacin no usa comunicaciones remotas.
Impresin o entrada de datos remota.
Teleproceso (TP) interactivo.
TP interfaz a un proceso batch.
La aplicacin es interactiva y en forma remota
predominantemente.
Valor
0
1
2-3
4
5
2. Funcin distribuida. una aplicacin que se ejecuta sobre un solo

procesador, se puede considerar monoltica; pero si se ejecuta en distintos
procesadores y persigue un nico objetivo, significa que los componentes
(o los datos) de la aplicacin estn distribuidos. Un ejemplo de este tipo
de requerimiento es un motor de bsqueda Web donde el procesamiento
est repartido en ms de un procesador. Los valores que puede tomar la
caracterstica son:
35
La aplicacin no ayuda a la trasferencia de datos o a la
funcin de procesamiento entre los componentes del
sistema.
La aplicacin prepara datos para el usuario final de
otro procesador.
Los datos se preparan para trasferencia; se trasfieren,
y se procesan en otro componente del sistema.
Las funciones de procesamiento se realizan
dinmicamente en el componente ms apropiado del
sistema.
Valor
0
1
2-4
5
3. Rendimiento: est referido a la importancia del tiempo de respuesta

dentro de todo el sistema. El tiempo de respuesta se ver influenciado por
el diseo, desarrollo, instalacin y soporte de la aplicacin. Los valores que
puede tomar la caracterstica son:
Anlisis y diseo de las consideraciones del
rendimiento son estndar. No se precisan
requerimientos especiales por parte del usuario.
En la fase de diseo se incluyen tareas del anlisis del
rendimiento para cumplir los requerimientos del
usuario.
Adems de los dos tems anteriores, se utilizan
herramientas de anlisis del rendimiento en el diseo,
desarrollo e instalacin.
Valor
03
4. Configuracin utilizada masivamente: se refiere a la importancia del

entorno y del uso del sistema. Por ejemplo, un sistema de ventas de un
supermercado con lneas de caja conectadas a un servidor, demanda una
alta tasa de ocupacin de recursos (memoria, disco, procesador,
comunicaciones, etc.), lo cual provoca restricciones en el hardware. Los
La aplicacin corre en una mquina estndar sin
restricciones de operacin.
Restricciones de operacin requieren caractersticas
especficas de la aplicacin en el procesador central.
Adems hay restricciones especficas a la aplicacin
en los componentes distribuidos del sistema.
Valor
03
4
5
5. Tasas de transaccin: una alta llegada de transacciones provoca

problemas ms all de los de la caracterstica tres (3). Como ejemplo de
este tipo de caractersticas estn los sistemas bancarios donde a
36

determinadas horas (denominadas pico) las transacciones tienen un

volumen considerable. Los valores que puede tomar la caracterstica son:
Las tasas son tales que las consideraciones
anlisis de rendimiento son estndares.
En la fase de diseo se incluyen tareas de anlisis
rendimiento para verificar las altas tasas
transacciones.
Adems se utilizan herramientas de anlisis
rendimiento.
Puntuacin
de
de
de
de
03
4
5
6. Entrada en lnea de datos se refiere al tipo de entradas (interactivas).

Por ejemplo un programa de aceptacin de solicitudes de prstamos donde
el usuario introduce los datos del solicitante y debe obtener una respuesta
inmediata acerca de la aceptacin o no de los perfiles exigidos en el
trmite. Los valores que puede tomar la caracterstica son:
Hasta el 15% de las transacciones tienen entrada
interactiva
15% al 30% de las transacciones tienen entrada
interactiva
30% al 50% de las transacciones tienen entrada
interactiva.
Puntuacin
02
34
5
7. Diseo para la eficiencia de usuario final: determina si las entradas

interactivas de datos requieren que se lleven a cabo sobre mltiples
pantallas, u operaciones especiales. Ejemplo de este tipo de transacciones
son las que se llevan a cabo en pantallas sensibles al tacto. Existen
operaciones, especialmente aquellas relacionadas con la venta de pasajes
en lnea, pago con tarjeta de crdito, operaciones en cajeros automticos,
etc., donde el usuario debe interactuar con mltiples pantallas. Los valores
que puede tomar la caracterstica son:
No se especifican requerimientos especiales
Se incluyen tareas de diseo para la consideracin de
factores humanos
Adems se utilizan herramientas especiales o de
prototipado para promover la eficiencia
Valor
03
4
5
8. Actualizacin en lnea: se refiere a la necesidad de la aplicacin de

actualizar los datos en lnea. Se da muchos de estos casos en los sistemas
de reservas de pasajes, para evitar vender dos veces la misma plaza. Los
37
No existe actualizacin en lnea.
Actualizacin en lnea de los archivos de control. El
volumen de actualizacin es bajo y la recuperacin
fcil.
Actualizacin en lnea de la mayora de los archivos
internos lgicos.
Adems es esencial la proteccin contra la prdida de
datos.
Adems se considera el coste de recuperacin de
volmenes elevados de grupos de datos.
Valor
0
12
3
4
5
9. Complejidad del procesamiento: se refiere a una cantidad considerable

de decisiones lgicas que debe tomar la aplicacin, o realizar muchos
clculos matemticos o manejar un nmero grande de excepciones. Las
caractersticas identificables de la aplicacin son:
0
1
2
3
4
5
mucho procesamiento matemtico y, o lgico,

procesamiento complejo de las entradas,
procesamiento complejo de las salidas,
muchas excepciones de procesamiento, muchas transacciones
incompletas y mucho reprocesamiento de las transacciones,
procesamiento de seguridad y, o control sensitivo.
No se aplica ninguna caracterstica.
Se aplica alguna caracterstica.
Se aplican dos caractersticas.
Se aplican tres caractersticas.
Se aplican cuatro caractersticas.
Se aplican todas.
10. Utilizable en otras aplicaciones: el cdigo se disea para que sea

compartido o utilizable por otras aplicaciones. Por ejemplo una funcin de
altas, bajas y modificaciones (ABM) que la mayora de las aplicaciones de
nminas de personas la usa. Los valores que puede tomar la caracterstica
son:
Una aplicacin local que responde a las necesidades
de una organizacin usuaria.
La aplicacin utiliza o produce mdulos comunes que
consideran ms necesidades que las del usuario.
Adems, la aplicacin se "empaquet" y document
con el propsito de fcil reutilizacin.
38
Valor
01
23
45

11. Facilidad de Instalacin cuando se necesita de un desarrollo adicional

para la instalacin de la aplicacin, se le asignar mxima puntuacin. Los
No se requieren por parte del usuario facilidades
especiales de conversin e instalacin.
Los requerimientos de conversin e instalacin son
descritos por el usuario y se proporcionan guas de
conversin e instalacin.
Adems se proporcionan y prueban herramientas de
Valor
01
23
45
12. Facilidad de operacin: Los valores que puede tomar la caracterstica

son:
No se especifican por parte del usuario
consideraciones especficas de operacin
Se requieren, proporcionan y prueban procesos
especficos de arranque, backup y recuperacin
Adems la aplicacin minimiza la necesidad de
actividades manuales, tales como instalacin de cintas
y papel
La aplicacin se disea para operacin sin atencin
Valor
0
12
34
5
13. Puestos mltiples: cuando el sistema se construye para ser ejecutado

en diferentes regiones, con diferentes monedas o idiomas, aumenta su
puntuacin, ya que esta facilidad le aade un cierto grado de complejidad.
Los valores que puede tomar la caracterstica son:
El usuario no requiere la consideracin de ms de un
tipo de puesto.
Se incluyeron necesidades de varios tipos de puestos
en el diseo.
Se proporciona documentacin y plan de apoyo para
soportar la aplicacin en varios tipos de puestos.
Valor
0
13
45
14. Facilidad de cambio: cuando se debe desarrollar la aplicacin para que

se adapte a los cambios y le facilite la operacin al usuario, alcanza
mximos puntajes. Los valores que puede tomar la caracterstica son:

39
No hay requerimientos especiales del usuario para
minimizar o facilitar el cambio.
Se proporciona capacidad de consulta flexible.
Datos importantes de control se mantienen en tablas
que son actualizadas por el usuario a travs de
procesos en lnea interactivos.
Valor
0
13
45
Una vez obtenido los valores para las catorce (14) caractersticas, de
acuerdo al entorno de desarrollo del software, se calcula el FA para la
aplicacin que est siendo medida. Dicho clculo se realiza de la siguiente
forma:
FA = 0,65 + (0,01 * de los 14 factores de influencia o caractersticas)
FPA = FP (sin ajustar) * FA
donde
FA = factor de ajuste
FP = puntos de funcin sin ajustar
FPA = puntos de funcin ajustados o totales
Los valores 0,65 y 0,01 no son arbitrarios; son el resultado de cientos de
mediciones realizadas en diferentes proyectos [Albrecht79]. El FA de los FPA,
puede tener una influencia que va desde 0,65 hasta 1,35; es decir si todas las
caractersticas toman valor nulo (cero) los FP se multiplican por 0,65; es decir,
reciben desde la calibracin una influencia negativa. Sin embargo si toman el
mximo valor (cinco para cada una) se multiplican los FP por 1,35; es decir,
reciben desde la calibracin una influencia positiva.
El software que mejor se adapta a este tipo de mediciones es el software
de gestin, que procesa informacin comercial [Pressman98]. Si bien es
cierto, los puntos de funcin de Albrecht, no son aplicables a todos los tipos de
software [Desharnais98], la mayora de los mtodos que incorporan facilidades
para distintas aplicaciones se basan en la tcnica de Albrecht, modificando
ligeramente algunos aspectos o incorporando nuevos elementos a los
mencionados.
4.2.2 TCNICA DE ESTIMACIN DE PUNTOS DE CARACTERSTICA
(FEATURE POINTS) [Jones99]
Las investigaciones de los puntos de caractersticas, comenzaron
aproximadamente en el ao 1999 [Jones99]. Utilizaba la lgica de los FP, para
estimar el tamao de software y se aplic en un principio a sistemas operativos,
sistemas de control de telefona y aquellos sistemas denominados de tiempo
real. Para evitar confusiones con el mtodo de Albrecht, a este mtodo se lo
denomin puntos de caractersticas (FP del ingls feature points). Desde un
principio, el mtodo arroj resultados favorables en los experimentos realizados
40

en software embebido, software de tiempo real, sistemas CAD, y algunas

aplicaciones de software de gestin. Precisamente, con el crecimiento de la
industria del software y con su correspondiente masificacin, comenzaron a
surgir requerimientos que no eran necesariamente de gestin administrativa o
comercial (por nombrar los ms conocidos). Por consiguiente, hubo que
desarrollar software diferente; el cual deba ser medido y, o estimado.
Algunos ejemplos de aplicaciones en las que el mtodo de Albrecht no era
del todo exacto, y que permiti el nacimiento de esta nueva tcnica entre otras
son:
software de tiempo real para control de armamento en las fuerzas
armadas,
nuevos sistemas operativos,
software embebido,
software de comunicaciones (por ejemplo para control de telefona),
software de control de dispositivos.
Cuando se aplica FP de Albrecht a este tipo de desarrollos, no se obtiene
una estimacin del todo exacta. La razn fundamental es que aquellos fueron
desarrollados para sistemas software de gestin y; con otro tipo de software, la
cuenta de FP no es del todo confiable. La tcnica de Jones, puede sustituir a
los FP de Albrecht, agregando algunos parmetros de tal forma que permita
representar a aquellos algoritmos complejos o a procesos que requieren de
una lgica de un nivel elevado.
Para ello, los puntos de caractersticas, aaden un componente adicional a
los cinco (EI, EO, EQ, ILF y ELF) ya mencionados de los FP de Albrecht. Este
componente denominado algoritmos complejos (CA del ingls complex
algorithms) permite introducir en el conteo a procesos con algoritmos complejos
o lgica de nivel elevado. El componente CA por defecto tiene un peso de tres
(3). En general el mtodo de puntos de caractersticas presenta un peso fijo
con respecto a los FP de Albrecht. Para el caso de funciones transaccionales
(EI, EO y EQ) considera una complejidad media; por ende, los valores que
toman estos componentes son de cuatro (4), cinco (5) y cuatro (4)
respectivamente. Con los grupos de datos lgicos (ILF y ELF) sucede algo
similar, pero en vez de considerar los valores de la complejidad media de los
FP, considera los de complejidad baja, adjudicndose siete (7) y cinco (5)
respectivamente. En la tabla 4.11 se muestra la disposicin de los
componentes con sus respectivos pesos:

41
Componente
Peso
ILF
ELF
CA
EI
EO
EQ
7
7
3
4
5
4
Cantidad
Subtotal (peso *
cantidad)
-------------------------------------------------------------------
Tabla 4.11. Pesos para puntos de caractersticas

Las diferencias entre los FP de Albrecht y los puntos de caractersticas, son
bsicamente que cuando el nmero de algoritmos de una aplicacin es mucho
mayor que el de los archivos, los puntos de caractersticas generan
estimaciones ms precisas que los FP. A la inversa si existe un nmero de
archivos considerablemente mayor al de algoritmos (situacin muy comn en
los sistemas de gestin), la cuenta de puntos de caractersticas ser mucho
menos confiable que la de FP.
En proyectos pequeos, tanto FP de Albrecht como los puntos de
caractersticas generan los mismos resultados; pero si se realiza el conteo en
el marco de proyectos de mediana o gran envergadura, existe una diferencia
considerable entre los resultados arrojados por una y otra tcnica.
El ajuste de los puntos de caractersticas se realiza de igual forma que los
FP de Albrecht; es decir se identifican y evalan los catorce (14) parmetros o
caractersticas para representar el entorno de desarrollo.
4.2.3 TCNICA DE ESTIMACIN Mark II (MK II) [Symons98]
Esta tcnica fue introducida por Charles Symons [Symons98], y conserva
caractersticas del mtodo de Albrecht; por lo tanto puede considerarse una
variante de esta. Al igual que el mtodo de FP, la medicin se realiza en dos
etapas bien diferenciadas. La primera de ellas corresponde al tamao de la
aplicacin (puntos de funcin sin ajustar en el mtodo de Albrecht) y la
segunda al ajuste de complejidad tcnica (aplicacin del factor de ajuste en
el mtodo de Albrecht). El mtodo se puede usar preferentemente en software
de gestin; pues las reglas y los valores estn orientados a este tipo de
software. Sin embargo, si se plantea la necesidad de medir otros tipos de
software como cientfico y, o de ingeniera, los cuales incluyen algoritmos
complejos, se podran adecuar dichas reglas para llevar a cabo mediciones en
estos dominios.
4.2.3.1 TAMAO DE LA APLICACIN
Una de las primeras diferencias que se puede apreciar con el mtodo de
FP de Albrecht, es que mientras este considera cinco componentes bsicos
42

(EI, EO, EQ, ILF y ELF), MK II examina al sistema desde el punto de vista de
las transacciones lgicas, conformadas cada una por una combinacin de
entrada, proceso y salida, desencadenada por un evento de inters para el
usuario, o una necesidad de recuperar informacin. El clculo de La
funcionalidad sin aplicar el ajuste de complejidad tcnica, se realiza en base a
la frmula 4.1:
P. de Funcin (sin ajustar) = W I * NI + W E * NE + W O * NO (4.1)
Donde:
WI
WE
WO
NI
NE
NO
Son los pesos para un elemento de dato de entrada.

Son los pesos para una entidad referenciada.
Son los pesos para un elemento de dato de salida.
Es la cantidad de tipos de elementos de datos de entrada.
Es la cantidad de tipos de entidades referenciadas.
Es la cantidad de tipos de elementos de datos de salida.
Los pesos W i se obtienen mediante una calibracin; sin embargo, existe

una valoracin estndar (resultado de un nmero considerable de mediciones)
que se muestra a continuacin:
WI = 0.58
WE = 1.66
WO = 0.26
4.2.3.2 REGLAS PARA LA IDENTIFICACIN DE LOS COMPONENTES DE
LAS TRANSACCIONES LGICAS
Los componentes que conforman las transacciones lgicas son las
entradas, salidas y las entidades. Con respecto a los lmites de la aplicacin, su
concepto no vara a lo largo de la exposicin de las diferentes tcnicas.
4.2.3.2.1 IDENTIFICACIN Y CONTABILIZACIN DE ENTIDADES
Una entidad es cualquier cosa u objeto del mundo real, del que se quiere
obtener informacin y que es de inters para la aplicacin a medir. Por ejemplo
en un sistema de ventas, pueden ser entidades entre otras: clientes,
proveedores, depsito, empleado y, o comprobantes. Un cliente tiene un
cdigo, domicilio, telfono, etc. y estos datos se denominan atributos que
identifican individualmente a las entidades (por ejemplo cada cliente tiene un
nico cdigo que lo identifica del resto).
Se pueden reconocer diversos tipos de entidades, para las cuales existen
reglas que se muestran a continuacin:

43
Regla 1: una entidad para la cual se introducen y almacenan datos, se

debera contabilizar cada vez que es referenciada en el marco de una
transaccin lgica (entrada-proceso-salida). Sin embargo, si se crea una
entidad a los fines de darle un formato determinado a una salida de datos,
esa entidad se debera contabilizar solamente una vez en el componente
de datos de salida.
Regla 2: se denominan entidades primarias a aquellas para las cuales el
sistema ha sido construido con la intencin de almacenar y recolectar
datos. Sin embargo, en un sistema pueden aparecer algunas entidades que
se han creado con fines operativos. Estas pueden referenciar a conjuntos
de datos como pases, cdigos postales, parmetros del sistema, mensajes
de error, etc. Si bien estas entidades representan a cosas del mundo real,
se las denominan entidades no primarias, y se engloban bajo la
denominacin de entidad del sistema. Existen criterios para diferenciarlas,
y se muestran en la tabla 4.12.
Criterio
N de atributos
Frecuencia de
acceso
Propiedad
Perodo en el cual
se modifican los
valores de los
atributos
Autorizacin para
cambios en el valor
de los atributos
Entidad Primaria
Varios con alta tasa de
cambio
Accedida
constantemente
La aplicacin que est
siendo contabilizada es
propietaria de la entidad
Entidad no Primaria
Pocos con baja tasa de
cambio
Permanentemente fija o
rara vez es accedida
Podra tener ms de un
propietario y no ser
exclusiva de la aplicacin
que se est contando
Durante la normal
operacin del sistema
Fuera de la operacin
normal del sistema
No requiere autorizacin
Requiere de autorizacin
de administradores del
sistema
Tabla 4.12. Criterios para diferenciar entidades primarias y no primarias.

Regla 3: en ocasiones se deben identificar a entidades y a sub-entidades
y contarlas a estas ltimas en forma separada. Una sub-entidad es un tipo
especfico de entidad primaria con una lgica de procesamiento o atributos
diferentes a aquella. Por ejemplo si existe una entidad denominada
empleados, se pueden definir dos sub-entidades: una como empleados
permanentes y otra como empleados temporarios.
Regla 4: la contabilizacin se realiza tomando en cuenta la cantidad de
entidades referenciadas en una transaccin lgica y no por la cantidad de
veces que una entidad es referenciada. Por ejemplo, si una entidad es
referenciada dos veces una para leer y otra para modificar en una misma
transaccin, se cuenta solamente una referencia a esa entidad.
44

Regla 5: si una entidad se relaciona con ella misma, se cuenta doble.

4.2.3.2.2 IDENTIFICACIN Y CONTABILIZACIN DE TRANSACCIONES
LGICAS
Una transaccin lgica es definida como una combinacin de uno o ms
tipos de entradas, un procesamiento y uno o ms tipos de salidas,
correspondientes a un proceso lgicamente nico. Un evento del mundo real
y que es de inters para el usuario es el que desencadena una transaccin
lgica. A modo de ejemplo se pueden mencionar algunos tipos de
transacciones lgicas: agregar un empleado, consultar un estado de cuenta,
agregar un comprobante de venta, calcular el promedio de ventas por perodo,
etc. Las reglas para su identificacin son las siguientes:
Regla 1: se deberan definir las transacciones al nivel ms bajo posible de
los procesos de la organizacin o del sistema que se est por medir.
Regla 2: en el contexto de la contabilizacin de la funcionalidad MK II, se
considera un nico tipo de evento y sus ocurrencias (no importa su
cantidad) se contarn solamente una vez. Esto se evidencia en los
conceptos del prrafo anterior (proceso lgicamente nico). A su vez, se
define como a proceso nico, misma entrada, validacin y acceso a
entidades, igual formato e igual salida. Cualquier diferencia entre estos
conceptos, se considera como otro tipo de transaccin lgica.
Regla 3: los eventos de inters son los que tienen significado en la tarea
que desarrolla el usuario valindose del sistema para resolver un problema
en particular. Por ejemplo el usuario quiere saber la cantidad de
empleados, el estado de una cuenta corriente, imprimir un inventario, etc.
Cada evento deber ser nico e indivisible; es decir, no podra separarse
en dos partes. Si as sucediera se tendra que contar otra transaccin
lgica.
Regla 4: una transaccin lgica se debe completar con xito y dejar el
sistema operativo o emitir un mensaje de error.
4.2.3.2.3 REGLAS PARA CONTAR DETs EN ENTRADAS Y SALIDAS
Los DETs, tienen el mismo significado que el definido en los FP de
Albrecht. Las reglas para la contabilizacin de tipos de datos primarios o
elementales son las siguientes:
Regla 1: se debe contar por tipo de dato elemental y no por ocurrencias
individuales de este.
Regla 2: no se deben contar DETs en cabeceras ni pies de pgina,
etiquetas, cajas, etc.

45
Regla 3: se deben considerar todos los mensajes de error como

ocurrencias del tipo de dato mensaje de error
Regla 4: las fechas que generalmente estn compuestas por da, mes y
ao en el formato (dd/mm/aaaa), se deben contar como un solo elemento
de dato.
Existe un nmero considerable de reglas que se aplican a cada tipo de
software a medir. Estas se encuentran disponibles en el manual de Counting
Practices Manual (CPM) V 1.3.1 [UKSMA98].
4.2.3.3 AJUSTE DE LA COMPLEJIDAD TCNICA
Para obtener la funcionalidad completa del mtodo, se han propuesto los
catorce (14) puntos del mtodo de Albrecht, con el agregado de cinco (5)
caractersticas adicionales, las cuales pueden aumentar si existe un buen
justificativo.
Las tablas que reflejan este agregado, se detallan a continuacin:
1. Requerimiento de otras aplicaciones: si una aplicacin que se quiere
medir requiere de otras aplicaciones como interfase. Los valores que puede
tomar la caracterstica son:
El sistema es aislado.
Requerimientos
del
sistema
para
interfases
compartimiento de datos deben ser sincronizados con
otras aplicaciones
Se deben sincronizar los requerimientos del sistema
con cuatro o ms aplicaciones.
Valor
0
14
5
2. Seguridad, privacidad y auditoria: se deben agregar puntos por cada

caracterstica que deba estar presente en el sistema a medir. Los valores
46

El sistema debe cumplir requerimientos personales
(incluso legales) de privacidad.
El sistema debe cumplir requerimientos especiales de
auditoria.
El sistema debe cumplir requerimientos excepcionales
de seguridad para prevenir prdidas de naturaleza
financiera o militar.
El sistema requiere criptografa de los datos enviados
y recibidos en las comunicaciones.
Agregar
Puntos
1
1
2
1
3. Necesidad de adiestramiento al usuario: los valores que puede tomar la

caracterstica son:
No es necesario material ni cursos.
Se requiere de entrenamiento especial ose deben
proporcionar facilidades de ayudas en lnea. Incluye:
facilidades de ayudas estndares,
desarrollo de ayudas especiales,
entrega de material especial de adiestramiento.
Se requiere de un sistema separado de entrenamiento
o simulador.
Valor
0
14
4. Uso del software por parte de empresas externa (usuarios externos) a la

propietaria: los valores que puede tomar la caracterstica son:
No existe otra empresa conectada al sistema.
Los datos se reciben o se envas desde / hacia
empresas conocidas.
Empresas conocidas estn conectadas al sistema,
pero solo pueden consultar datos.
Empresas conocidas estn conectadas al sistema con
facilidad de actualizacin en lnea.
Empresas desconocidas (pblico en general o
demasiado extenso como para ser adiestrado) pueden
acceder al sistema.
Valor
0
1
2
3-4
5
5. Documentacin: se deben contar puntos por cada una de las

caractersticas de documentacin que se deben entregar al finalizar el
proyecto. Algunas de esas caractersticas son:
especificacin funcional del sistema (datos y proceso),

especificacin tcnica del sistema,

47
documentacin del programa (diagramas de flujo),

librera de elementos de datos,
elemento de datos / registro / referencia del programa,
manual del usuario,
folleto de informacin general del sistema,
librera de datos de prueba,
material del curso de adiestramiento,
documento de costo / beneficio del sistema,
informe de pedido de cambios y errores.
Se calcula el grado de influencia o la puntuacin de la siguiente manera:

Cantidad de
caractersticas
Entre 0 y 2
Entre 3 y 4
Entre 5 y 6
Entre 7 y 8
Entre 9 y 10
Entre 11 y 12
Puntuacin
0
1
2
3
4
5
4.2.3.4 APLICACIN DE FRMULAS PARA EL CLCULO DE LOS

PUNTOS DE FUNCIN TOTALES PARA MK II
Como se ha mencionado en prrafos anteriores, los puntos de funcin sin
ajustar con el mtodo MK II, se calculan como el producto de los pesos (W I)
por la cantidad de elementos de datos NI referenciados o identificados en cada
transaccin lgica, segn se indica en la frmula 4.2.
UFP = W I * NI + W E * NE + WO * NO (4.2)
Donde
UFP Son los puntos de funcin sin ajustar para MK II
Ahora bien; el ajuste de complejidad tcnica (TCA del ingls technical
complexity adjustment) se calcula en forma similar a como se lo hace en el
mtodo de Albrecht, sumando los valores de cada una de las caractersticas y
multiplicando ese resultado por un coeficiente obtenido tras haber efectuado
mediciones en cientos de proyectos [Symons98]. Ese valor, es de 0.005; por lo
tanto la operacin para determinar el TCA es la que se muestra en la frmula
4.3:
TCA = 0.65 + (0.005 * caractersticas)
(4.3)
El valor final de los puntos de funcin para MK II ser:
48

Cantidad de Puntos de Funcionalidad (MK II) = UFP * TCA (4.4)

Ntese que a diferencia del mtodo de Albrecht, MK II achica el rango del
ajuste de complejidad tcnica. Mientras en el primero estaba entre 0.65 y 1.35,
en el MK II ese rango disminuye a 0.65 y 1.125. Esto se explica debido a que el
coeficiente que utiliza MK II es 0.005 mientras que el usado por el mtodo de
Albrecht es 0.01.
4.2.4 MTODO DE ESTIMACION 3D FUNCTION POINTS [Whitmire92]
En aos recientes han surgido entre otros, desarrollos orientados a
objetos (OO del ingls object oriented). Como sucede con cualquier tecnologa
nueva, las prcticas OO han requerido de nuevos mtodos de estimacin del
tamao. La mayora de las tcnicas de estimacin, especialmente la de FP de
Albrecht, tuvieron sus inicios cuando el desarrollo del software estaba orientado
hacia los procedimientos y los datos. Mientras las tcnicas denominadas
tradicionales dividen el espacio de soluciones en datos y procedimientos, el
paradigma de diseo orientado a objetos hace una combinacin de ellos
[Whitmire92].
El problema de las tcnicas que no son OO, es que solamente miden
funcionalidad (una sola dimensin). Se puede decir, que los mtodos
orientados hacia la funcionalidad, ignoran aspectos importantes como son las
relaciones entre objetos y la reusabilidad de estos. La funcionalidad (es decir el
comportamiento de los objetos) puede resultar importante a la hora de
dimensionar el esfuerzo; sin embargo, considerar esto solo puede resultar
insuficiente para estimar el tamao del software.
Aparte de la funcionalidad, tambin existe un nivel de complejidad en el
software a desarrollar, que depende de las comunicaciones entre objetos. Esta
complejidad puede hacer aumentar sustancialmente el tamao del software,
debido a que un alto nivel de intercomunicacin entre objetos implica un
esfuerzo adicional.
Los puntos de funcin 3-D fueron introducidos en el ao 1992 por Scott
Whitmire, quien en ese entonces trabajaba para la compaa de
aeronavegacin Boeing. Esta tecnologa fue desarrollada para dar respuesta a
desarrollos denominados independientes de la tecnologa y poder as
obtener mtricas convenientes para un mayor rango de dominios.
El mtodo 3D se basa en que la aplicacin a desarrollar se puede expresar
en tres dimensiones:
datos,
funciones, y
control.
49
Cada dimensin representa una parte de toda la complejidad de la

aplicacin. Si bien es cierto, se puede identificar a una dimensin con un grado
de complejidad mayor que otra, el anlisis que se debe hacer, debe abarcar a
las tres dimensiones si se quieren obtener medidas ms confiables en estos
tipos de software.
El mtodo puede identificar directamente caractersticas en cada una de
esas dimensiones; caractersticas que pueden ser directamente medidas
[Methods & Tools99].
La dimensin de datos, puede asociarse directamente con el tipo de
software denominado de gestin. En estos casos las caractersticas del
software a desarrollar pueden obtenerse directamente de los manuales de
prcticas de los FP de la IFPUG [IFPUG04].
La dimensin de funciones est relacionada con el tipo de software
denominado cientfico donde se identifica una cantidad importante de clculos y
algoritmos complejos.
La dimensin de control est fuertemente asociada con tipos de desarrollo
para software denominado de tiempo real.
El autor del mtodo ha hecho aportes importantes al desarrollo de mtricas
para anlisis y programacin orientados a objetos. Debido a que la tcnica fue
concebida en el seno de una compaa internacional (Boeing Company), no ha
habido difusin
de literatura como en otros mtodos, quizs por la
personalizacin que all se hizo.
4.2.5 MTODO DE ESTIMACIN DE PUNTOS COMPLETOS DE FUNCIN
FFP [Abran A., et al97]
Este mtodo fue desarrollado por un equipo de la Universidad de Qubec
en Montreal (Canad) [Abran A., et al.,97], siendo muy eficiente en la medicin
de puntos de funcin en sistemas de control, tiempo real y embebidos.
Particularmente, los sistemas en tiempo real presentan dos factores crticos:
primero, el tiempo de respuesta y en segundo lugar, su interaccin con
entidades externas.
El mtodo de FFP, se ver ms en detalle en el punto 4.2.6, donde se
realiza un desarrollo completo de los puntos de funcin completos en el marco
del Consorcio Internacional Comn de Medidas del Software (COSMIC), con el
denominado COSMIC-FFP.
4.2.6 MTODO DE ESTIMACIN COSMIC-FFP [Abran A., et al99]
Este mtodo ha sido inspirado en los puntos de funcin completos (FFP
del ingls full function points) [Abran A., et al,99] y es el resultado de diversas
pruebas de campo y opiniones recibidas de distintas empresas que lo han
50

usado en procesos de desarrollo y, o mantenimiento de productos software. El

mtodo FFP, fue propuesto por primera vez en el ao 1997 [Abran A., et al,97]
con el objeto de obtener medidas para software de tiempo real. Diversas
pruebas han demostrado adems, que el mtodo es til para software tcnico,
de explotacin y de gestin. COSMIC FFP no es otra cosa que el Common
Software Measurement International Consortium [COSMIC-FFP01] o Consorcio
Internacional Comn de Medidas del Software, con la participacin de varios
pases entre ellos Canad, Reino Unido, Francia y Japn. Bsicamente apunta
a satisfacer las necesidades de:
los proveedores de software que deben traducir los requerimientos del

cliente en un tamao del software como un paso fundamental para la
estimacin de los costos del proyecto,
los clientes que deben conocer ese tamao funcional del software recibido
como un componente de la medicin del desempeo del proveedor.
Esta tcnica al igual que el resto de las estudiadas en el captulo, considera

a los requerimientos desde una perspectiva del usuario. Estos requerimientos y
en el marco de la tcnica COSMIC-FFP, reciben el nombre de requerimientos
funcionales del usuario (FUR - del ingls functional user requirement). El
modelo del proceso de medicin, se muestra en la figura 4.2.
Para aclarar algunos puntos que se han visto y se vern ms adelante, se
definen los siguientes conceptos relacionados con el mtodo:
Capa: el software que se quiere medir puede estar dividido en dos o ms
partes, cada una de ellas con diferentes niveles de abstraccin. Cada
una de estas partes recibe el nombre de capa y encapsula funcionalidades
tiles a s misma. Puede haber relacin jerrquica para el intercambio de
datos entre capas a nivel subordinado o entre pares (peer to peer).
Frontera (o lmites): es un conjunto de criterios percibidos mediante los
FURs del software, que permite establecer una distincin conceptual clara
entre aquellos tems que son parte del software (o que estn dentro de los
lmites) y los que forman parte del medio ambiente (estn fuera de los
lmites del sistema).
Usuario del software: el modelo COSMIC-FFP define al usuario como
aquella persona o dispositivo de ingeniera que se beneficia con el uso del
software.
Requerimientos funcionales del usuario: son las partes de los
requerimientos del software que describen la naturaleza de las funciones a
ser provistas. Aqu no se incluyen a aquellos requerimientos tcnicos o de
calidad que igualmente describen funcionalidad del software.

51
Figura 4.2. Modelo del proceso de medicin COSMIC-FFP.

Segn lo ilustra la figura 4.2, previo a la aplicacin de reglas y
procedimientos de medicin, se deben representar los FURs en un modelo
especfico que capture sus conceptos, definiciones y relaciones. Una vez
efectuada esta representacin, se realiza la medicin aplicando el conjunto de
reglas y principios del mtodo. A continuacin se detallan los pasos para la
identificacin de los diferentes elementos que intervienen en el proceso de
medicin COSMIC-FFP.
4.2.6.1 IDENTIFICACIN Y EXTRACCIN DE LOS FURs
La prctica indica que los FURs pueden tomar distintas formas.
Bsicamente puede ser o un documento especfico, o derivaciones de otros
objetos de ingeniera del software (producidos antes que existe el software a
desarrollar a partir de documentos de concepcin y arquitectura). Estos objetos
pueden ser software de definicin de requisitos o de modelizacin y, o anlisis
de datos.
4.2.6.2 FASE DE REPRESENTACIN EN COSMIC-FFP
Esta fase es considera como entrada a los FURs obtenidos. La fase
representacin genera un modelo COSMIC-FFP de los FURs. Este modelo
ser el apropiado para medir el tamao funcional del software y se compone de
dos partes:
a) Modelo de contexto: el contexto se refiere a todo lo que es considerado
como parte del software a ser medido y el resto (que corresponde al
entorno de operacin). De acuerdo a esta perspectiva se puede decir que:
el software est delimitado por el hardware. Como lo muestra la
figura 4.3 en la direccin front-end el software est delimitado por uno
o varios componentes de hardware (ratn, teclados u otros
52

dispositivos de entrada de datos). A su vez, en la direccin back-end

est delimitado por el hardware de almacenamiento,
el flujo funcional de los atributos de datos se puede caracterizar por
cuatro movimientos: entradas y salidas, que realizan el traslado de
datos desde / hacia fuera de los lmites de la aplicacin; y las
lecturas y escrituras que leen y graban respectivamente esos datos
en los dispositivos de almacenamiento (figura 4.3).
. Figura 4.3. Flujo genrico de datos desde una visin funcional COSMIC-FFP.
b) El modelo de software COSMIC-FFP: se basa en los siguientes principios:
Principio 1: el software a ser representado y medido es alimentado por
entradas de datos y genera salidas de datos tiles a los usuarios.
Principio 2: el software a ser representado y medido manipula parcelas
de informacin designadas como grupos de datos, las cuales contienen
atributos de datos.
El modelo COSMIC-FFP, parte de los requerimientos funcionales del
usuario que son implementados por un conjunto de procesos funcionales; cada
uno de estos, es un conjunto nico de subprocesos. Cada subproceso realiza
ya sea un movimiento o una manipulacin de datos. El modelo COSMIC-FFP
distingue cuatro tipos de subprocesos de movimientos de datos: entradas,
salidas, lecturas y escrituras. Las entradas transfieren datos desde los
usuarios hacia el interior de la frontera del software; las salidas lo hacen en
sentido inverso (desde el interior de la frontera del software hacia los usuarios);
las lecturas y escrituras transfieren datos desde y hacia las formas de
almacenaje. Estas relaciones se ilustran en la figura 4.4.
53
Figura 4.4. Tipos de subprocesos y sus relaciones.

4.2.6.3 REGLAS PARA LA REPRESENTACIN
El proceso de representacin implica la aplicacin de una serie de reglas y
principios. En la figura 4.5, se muestra el modelo genrico de representacin,
que ha sido construido en funcin de una gama bastante amplia de
aplicaciones, lo cual no quita que para alguna en particular, pueda sufrir
modificaciones o adecuaciones; siempre y cuando, refleje claramente y sin
ambigedades el software a ser medido.
Figura 4.5. Modelo general para el proceso de representacin COSMICFFP.

54

4.2.6.3.1 IDENTIFICACIN DE CAPAS DEL SOFTWARE

Ya sea que el analista del sistema lo infiera o los requerimientos de los
usuarios lo ameriten, se pueden distinguir diferentes capas de software, para
las cuales efectan mediciones en forma separada. Las capas se identifican de
acuerdo a los siguientes principios:
a) Definicin: una capa es el resultado de una particin del software en la
cual todos los procesos funcionales son ejecutados a un mismo nivel de
abstraccin. En un ambiente de varias capas, el software de una
intercambia datos con el software de otra a travs de los procesos
funcionales. Las interacciones que se dan son a nivel jerrquico. En tal
sentido una capa puede ser cliente de otra; y utiliza los servicios de
otra capa denominada subordinada.
b) Principios:
el software de todas las capas provee funcionalidades a los usuarios,
el software de una capa subordinada provee servicios funcionales al
software de una capa cliente,
el software de una capa subordinada puede ejecutarse sin la
asistencia del software de una capa cliente,
el software de una capa cliente puede no ejecutarse apropiadamente
si el software de la capa subordinada que depende no es ejecutado
apropiadamente,
el software de una capa cliente no usa necesariamente todas las
funcionalidades provistas por el software de una capa subordinada,
el software de una capa subordinada puede ser una capa cliente
desde la perspectiva de una tercera capa subordinada,
el software en las capas clientes y subordinadas puede fsicamente
compartir e intercambiar datos; sin embargo el software en cada capa
interpreta los datos en forma diferente,
el software que comparte datos con otro software no puede ser
considerado en una capa diferente si interpreta los datos de manera
idntica al otro software.
c) Reglas:
los servicios funcionales de los tipos de software tales como sistemas
de gestin de bases de datos, interfaz grfica, sistemas operativos o
sistemas de control (que manejan diferentes dispositivos
electrnicos) son considerados generalmente como capas distintas,
si un software es concebido utilizando un paradigma de arquitectura
conocido, ese paradigma puede ser usado para la identificacin de
capas,
un software de aplicacin es considerado como la capa de ms alto
nivel,

55
en caso de dudas, se puede utilizar el concepto de acoplamiento

para distinguir las capas.
4.2.6.3.2 IDENTIFICACIN DE LA FRONTERA DEL SOFTWARE

Una vez que la frontera del software ha sido identificada, cada FUR que
describe un proceso dentro de esa frontera es incluido en el mbito de la
medicin del tamao del software.
a) Definicin: el lmite o frontera de un software es el lmite conceptual
entre el software y el medio ambiente en el cual opera, tal cual es
percibido externamente desde la perspectiva del usuario. Permite
distinguir, y sin ambigedades, lo que es parte del software de lo que
forma parte de su medio ambiente operativo.
b) Principios: existe una frontera entre cada par de capas adyacentes y hay
un lmite entre distintos componentes de software en una misma capa,
siempre y cuando, los intercambios de datos entre ellas sean del mismo
nivel.
c)
Reglas:
identificar primero los eventos desencadenadores, luego los procesos
funcionales puestos en marcha por esos eventos. Los lmites se
encuentran entre esos eventos y los procesos,
identificar los dispositivos de entrada y salida que utiliza el software para
interactuar con el usuario. Relacionar esos dispositivos con las funciones
provistas por el software. Situar a la frontera entre esas funciones y los
dispositivos de entrada y salida,
para un software del tipo tiempo real, utilizar el concepto de capas para
identificar las fronteras.
4.2.6.3.3 IDENTIFICACIN DE PROCESOS FUNCIONALES

Los procesos funcionales son los que brindan la funcionalidad del software
a medir de acuerdo con los requerimientos del usuario.
a) Definicin: un proceso funcional es un conjunto nico de movimiento de
datos (entrada, salida, lectura y escritura) que implementan un conjunto
coherente y lgicamente indivisible de FURs. Es desencadenado directa
o indirectamente por medio de un evento y es completado cuando se
ejecuta todo lo que se quiere hacer, en respuesta a dicho evento.
b) Principios:
1. un proceso funcional es una forma derivada de al menos un FUR,
2. un proceso funcional es realizado cuando ocurre un evento
desencadenador identificable,
3. un proceso funcional contiene al menos dos movimientos de datos:
una entrada y una salida o una escritura,
56

4. un proceso funcional contiene no ms de un estado de espera

incluido (el cual puede ocurrir cuando es completado),
5. un proceso funcional pertenece a una y solo una capa.
c) Reglas:
los subconjuntos de eventos desencadenadores no son considerados
como eventos desencadenadores diferentes.
4.2.6.3.4 IDENTIFICACIN DE GRUPO DE DATOS
a) Definicin: un grupo de datos es un conjunto no nulo, no ordenado y no
redundante de atributos de datos en el cual cada dato incluido describe
un aspecto complementario del mismo objeto de inters. Adems un
grupo de datos es caracterizado por su persistencia, que puede ser:
Transitoria: el grupo de datos no sobrevive a la transaccin que los
utiliza.
Corta: el grupo de datos sobrevive a la transaccin, pero no

sobrevive a la operacin del software.
Indefinida: el grupo de datos sobrevive a la operacin del software.
b) Principios:
un grupo de datos debe ser implantado en el sistema informtico que
soporta el software,
cada grupo de datos identificado debe ser nico y distinguible a
travs de una coleccin de atributos de datos,
los grupos de datos son relacionados directamente con los objetos en
los FURs.
c) Reglas:
con respecto a la aplicacin de tipos de software denominados de
gestin, un grupo de datos es identificado para cada tipo de entidad
observado en el modelo de datos normalizado (segunda o tercera
forma normal) del software medido. Usualmente los grupos de datos
identificados tienen una persistencia indefinida y el software es
requerido para almacenar los datos de las entidades involucradas,
si el software es de tiempo real, los grupos de datos tienen alguna de
las siguientes formas:
o los movimientos de datos que son entradas de dispositivos
fsicos, tpicamente contienen datos sobre el estado de un objeto
simple o pueden ser el objeto mismo,
o estructura de datos comunes representando objetos que son
nombrados en los requerimientos funcionales del usuario, los que
son almacenados en la memoria voltil y accesible a la mayor
parte de los procesos funcionales del software medido,
57
o estructuras de datos referenciales, representados bajo la forma

de grficos o tablas en los requerimientos funcionales del usuario,
guardados en memoria permanente y accesible a la mayor parte
de los procesos funcionales del software a medir,
o almacenamientos simples, representando objetos que figuran en
los requerimientos funcionales del usuario que son conservados
en dispositivos de memoria permanente.
4.2.6.3.5 IDENTIFICACIN DE ATRIBUTOS DE DATOS
Esta etapa se identifica el conjunto de atributos referidos al software a
medir.
a) Definicin: un atributo es la parcela ms pequea de informacin, dentro
de un grupo de datos identificado, que tiene un significado desde la
perspectiva del FUR del software. Se pueden distinguir tres tipos de
atributos de datos, de los cuales dos de ellos son vlidos para la
medicin del tamao del software:
los datos que describen o representan el mundo del usuario, son
considerados vlidos. Por ejemplo el nombre de un empleado, el
departamento donde trabaja, su salario, etc.,
los datos contextuales que especifican qu, cundo y cmo otros
datos son procesados por el software a medir, son considerados
como vlidos,
los datos tcnicos (tablas de parmetros, cdigos especficos, etc.)
que son creados solamente para darle funcionalidad al software no
son considerados vlidos.
b) Principios:
un atributo de dato debe representar un tipo vlido de dato,
un atributo de dato debe representar el componente ms pequeo de
datos referido por el software medido, desde la perspectiva de los
FURs.
4.2.6.4 FASE DE MEDICIN DE COSMIC-FFP
Esta fase recibe como entrada una instancia del modelo de software
COSMIC-FFP, y haciendo uso de un conjunto de reglas y procedimientos,
produce un valor que es directamente proporcional al tamao del software a
medir. Esa medida es expresada en CFSU (del ingls Cosmic Functional Size
Units) y es la medida o tamao del software. Esta medida es directamente
proporcional a la cantidad de subprocesos de movimientos de datos. En la
figura 4.6 se muestra el procedimiento que se debe aplicar para esta fase.
58

Figura 4.6. Procedimiento general para la fase de medicin.

Las caractersticas del conjunto de reglas y procedimientos que rigen la
generacin del valor de CFSU son las siguientes:
a) Funcin de medicin: para cada instancia del subproceso, es asignada
una cantidad numrica, segn su tipo a travs de una funcin de
medida.
b) Unidad de medida: una unidad de CFSU es definidas por convencin
como equivalente a un movimiento de datos a nivel subproceso.
c) Aditividad: el tamao funcional de un proceso es la suma aritmtica de
los tamaos de los subprocesos que lo conforman.
Bajo estas consideraciones, se puede decir que el menor tamao que
puede tomar una medicin es de dos (2) CFSU, representado por una entrada
(1 CFSU) y una salida o una grabacin (1 CFSU).
4.2.6.4.1 IDENTIFICACIN DE LOS SUBPROCESOS

Este paso consiste en la identificacin de los subprocesos de un proceso
funcional.

59
a) Definicin: un subproceso COSMIC-FFP es un movimiento de datos

que ocurre durante la ejecucin de un proceso funcional. Existen cuatro
tipos de subproceso: entrada, salida, lectura y escritura;
una entrada (E) es un movimiento de datos que se encuentra en un
grupo de estos desde el lado del usuario de la frontera o lmite hacia
el interior de la frontera del software. No actualiza los datos que
desplaza,
una salida (X) corresponde al movimiento inverso de una entrada.
Existe un desplazamiento de datos desde adentro de los lmites del
software hacia fuera de estos,
una lectura (R) funcionalmente, trae datos de un archivo al proceso
funcional al cual pertenece,
una escritura (W) funcionalmente, enva datos desde el proceso
funcional al que pertenece hacia un archivo.
b) Principios: aqu se describen los principios que se aplican para los
subprocesos;
entradas (E):
o el subproceso recibe atributos desde fuera de los lmites del
software, desde el lado del usuario,
o el subproceso recibe datos de un solo grupo. Si el origen es de
ms de un grupo de datos, entonces se identifica una entrada por
cada uno de estos grupos,
o el subproceso no extrae, no lee y no escribe datos,
o dentro de un proceso funcional donde es identificado el
subproceso es nico, el procesamiento y los atributos de datos
identificados son diferentes a los de otras entradas incluidas en el
mismo proceso funcional;
salidas (X):
o el subproceso enva atributos de datos hacia fuera de la frontera
del software, del lado del usuario,
o el subproceso enva datos que pertenecen solo a un grupo de
datos. Si los datos pertenecen a ms de un grupo son enviados al
exterior de la frontera, identificar una salida (X) por cada grupo de
datos referenciado,
o el subproceso no recibe, no lee ni escribe datos,
o dentro del proceso funcional en el cual es identificado, el
subproceso es nico; el tratamiento y los datos identificados son
diferentes de los de otras salidas incluidas en el mismo proceso
funcional;
lecturas (R):
o el subproceso recupera los atributos de datos en el grupo de
almacenamiento de datos,
o el subproceso hace referencia a atributos que pertenecen a un
solo grupo de datos. Si ms de un grupo de datos es referenciado
se debe identificar una lectura por cada grupo de datos
referenciado,
o el subproceso no recibe, no extrae y no escribe datos,
60

o el proceso funcional dentro del cual es identificado, el subproceso

es nico; es decir, el tratamiento y los atributos de datos
identificados son diferentes de los de otras lecturas incluidas en el
mismo proceso funcional;
escrituras (W):
o el subproceso graba los atributos de datos de un grupo de datos
en el lado del almacenamiento del software,
o el subproceso modifica el valor de los atributos de datos que
pertenecen a un solo grupo de datos. Si ms de un grupo de
datos es referenciado, identificar una escritura por cada grupo de
datos,
o el subproceso no recibe, no extrae ni lee datos,
o en el proceso funcional dentro del cual es identificado, el
subproceso es nico; es decir, el tratamiento y los atributos de
datos identificados son diferentes de los de otras escrituras
incluidas en el mismo proceso funcional.
c) Reglas: aqu se describen las reglas que se aplican para los

subprocesos;
entradas (E):
o los eventos desencadenados por reloj son considerados como
externos. Por ejemplo un evento que ocurre cada tres segundos y
es asociado a una entrada que mueve un atributo de dato. Sin
embargo el proceso funcional que genera el evento es ignorado
ya que ocurre fuera de los lmites del sistema;
salidas (X):
o todos los mensajes generados que no contengan datos del
usuario (por ejemplo mensajes de error o confirmacin) son
identificados como una salida simple en el proceso funcional en el
cual la salida es identificada.
4.2.6.4.2 APLICACIN DE LA FUNCIN DE MEDICIN
Consiste en la aplicacin de la funcin de medicin COSMIC-FFP a los
subprocesos identificados en cada proceso funcional. La funcin de medicin
es una funcin matemtica que asigna un valor a una variable sobre la base
del estndar de medicin COSMIC-FFP. La variable de la funcin de medicin
es el subproceso.
4.2.6.4.3 AGREGACIN DE LOS RESULTADOS DE LA FUNCIN DE
MEDICIN
En este paso se integran los valores obtenidos de los subprocesos en un
solo valor que representa el tamao del software a desarrollar.
a) Principios:

61
para cada capa identificada, el tamao de los subprocesos

individuales son sumados aritmticamente para obtener un solo valor.
Tamao CFSU (capai) = tamao(entradasi) + tamao(salidasi) +

tamao(lecturasi) + tamao(escriturasi) (4.5)
para cada capa identificada el tamao funcional de los cambios en

los requerimientos funcionales del usuario es la suma de los tamaos
de los subprocesos correspondientes modificados
Tamao CFSU (cambio(capai)) = tamao(subprocesosi adicionados) +

tamao(subprocesosi modificados) +
tamao(subprocesosi elim inados) (4.6)
4.2.6.5 MATRIZ DE REPRESENTACIN Y MEDICIN DE VALORES
COSMIC-FFP
Una vez que se han obtenido los valores de los subprocesos incluidos en
las distintas capas, es posible representarlos en una matriz similar a la de la
figura 4.7.
Capa
Proc. Funcionales
Gr. Dato 1
CAPA
CAPA
CAPA
CAPA
CAPA
CAPA
1
1
1
1
1
1
Proc. Func.
Proc. Func.
Proc. Func.
Proc. Func.
Proc. Func.
Proc. Func.
Grupos de Datos
..
.
Gr. Dato n
Subprocesos
Entrada (E) Salida (X) Lectura R
Escritura (W)
Gr. Dato n
Subprocesos
Entrada (E) Salida (X) Lectura R
Escritura (W)
A
B
C
D
E
F
Totales Capa 1
Capa
Proc. Funcionales
Gr. Dato 1
Grupos de Datos
..
.
CAPA n Proc. Func. J

CAPA n Proc. Func. K
CAPA n Proc. Func. L
Totales Capa n
Figura 4.7. Matriz de representacin de valores COSMIC-FFP.

Para la fase de representacin, se debe completar de la siguiente forma:
cada capa puede ser nominada o representada por medio de un nombre
descriptivo y ubicada en la fila y columna correspondiente,
cada grupo de datos identificado es registrado en su columna
correspondiente,
cada proceso funcional es registrado en una fila especfica y agrupados
en cada capa identificada.
Para la fase de medicin, se debe completar de la siguiente forma:
62

para cada proceso funcional identificado, los subprocesos identificados

son anotados en la celda correspondiente utilizando la convencin: E
para cada entrada, X para cada salida, R para cada lectura y W para
cada escritura,
para cada proceso funcional identificado, los subprocesos son sumados
por tipo, y cada subtotal es registrado en la columna apropiada, en la
parte derecha de la matriz,
el resumen de la medicin puede ser calculado y registrado en las
celdas de cada capa, en la lnea de los totales.
4.3 CONCLUSIONES DEL ESTUDIO DE LAS TCNICAS DE ESTIMACIN

Est claro que todas las tcnicas estudiadas en este captulo, encuentran
su origen en los puntos de funcin de Albrecht, quin ide un mtodo que
capaz de calcular la funcionalidad del software y obtener su tamao
aproximado en etapas tempranas del desarrollo.
En sus inicios, y debido al entorno de trabajo de Albrecht, todas sus
investigaciones y estudios empricos se efectuaron en software de gestin. En
las dcadas siguientes a este hallazgo, y debido a la explosin de las
aplicaciones en computadoras, surgieron demandas de otro tipo de software, el
cual tambin deba ser medido y estimado. Software de tiempo real,
empotrado, orientado a objetos son solamente algunos de estos ejemplos.
Debido a esta necesidad, salieron a la luz varias tcnicas alternativas a la de
los puntos de funcin de Albrecht, que han sido adaptadas para aquellas
aplicaciones en las cuales los puntos de funcin no eran del todo confiables.
Las ms importantes o las ms difundidas, han sido estudiadas en este
captulo, con el propsito de identificar a aquellas que dejan abierta la
posibilidad de introducir adecuaciones para el clculo de funcionalidad en
SSBBCC.
De acuerdo a la literatura tomada como referencia, y al estudio y anlisis
de las tcnicas propuestas en el presente captulo, no se ha detectado
expresamente que las mismas puedan ser aplicadas directamente y efectuar
mediciones en SSBBCC. Sin embargo, algunas de estas tcnicas dejan abierta
la posibilidad de hacer adecuaciones a sus parmetros con el objeto de que
puedan ser usadas en otro tipo de software (como cientfico, de ingeniera o
basado en conocimiento). Para el caso de los SSBBCC, se puede adaptar
alguna de las mencionadas y hacer un aporte a la solucin del problema de
estimacin en proyectos que incluyan al tipo de software antes mencionado.
4.4 APLICABILIDAD DE LAS TCNICAS A DISTINTOS TIPOS DE
SOFTWARE
Como se ha mencionado en el punto anterior, las tcnicas de estimacin
han sido desarrolladas en su mayora con el objeto de obtener mtricas de
63
tipos de software de gestin, tiempo real, empotrados, sistemas operativos y

software cientfico. Este concepto, se ha puesto de manifiesto en el desarrollo
de los puntos 4.2.1 a 4.2.6 del presente captulo. Es decir; no existen
elementos como para asegurar que se pueden medir tipos de software de
lgica compleja, como es el caso de los SSEE o en trminos ms generales los
SSBBCC.
Todas las tcnicas mencionadas en este captulo basan sus respectivas
mediciones en la funcionalidad del producto software a desarrollar y; como ya
se ha expresado en este tratado, tuvieron su origen en los puntos de
funcionalidad de Albrecht. En la tabla 4.13, se muestran los tipos de software
que se pueden medir con las tcnicas desarrolladas en este captulo. Esta
clasificacin no es excluyente y puede ser objeto de diversos estudios, anlisis
y, o adecuaciones para dar solucin a dominios que no han sido contemplados
en la tabla 4.13.
Tcnica
Tipo de software que se puede medir
Puntos de funcin de
software de gestin
Albrecht
Puntos de caractersticas
software de tiempo real
(feature points)
sistemas operativos
software embebido
software de ingeniera (sistemas CAD)
software
de
gestin
(algunas
aplicaciones)
Mark II (MK II)
software de gestin,
software de ingeniera y cientfico (con
adaptacin de las reglas del mtodo)
3D function point
desarrollos con tecnologa orientada a
objetos
FFP puntos de funcin
completos
sistemas de control
software embebido
COSMIC - FFP
sistemas de control
software embebido
software de gestin
Tabla 4.13. Aplicabilidad de las tcnicas a distintos tipos de software.
64

CAPTULO V
ESTUDIO
DE LOS
SISTEMAS
BASADOS
BASADOS
EN
CONOCIMIENTO
CAPTULO V
ESTUDIO DE LOS SISTEMAS BASADOS EN CONOCIMIENTO
5.1 INTRODUCCION
En este captulo se realiza un estudio de los SSBBCC conjuntamente con
sus caractersticas, arquitectura, etc. La finalidad de este enfoque es que el
lector tenga los elementos necesarios como para conocer aspectos
sobresalientes de los SSBBCC, su principio de funcionamiento y las
diferencias y similitudes (al final del captulo se presenta un cuadro) con el
resto de los sistemas software.
5.2 BREVE RESEA Y EVOLUCIN DE LOS SISTEMAS BASADOS EN
CONOCIMIENTO
Al principio, los programas denominados inteligentes, tuvieron muy poca
repercusin en la comunidad informtica. No fueron muchos los profesionales
que se dedicaron a indagar acerca de cmo resolvan sus problemas los
expertos de un rea o de un dominio determinado. En las dcadas del sesenta
y setenta, los investigadores estuvieron concentrados principalmente en los
mtodos de bsqueda y en las formas de representar hechos y conocimientos.
A partir de los aos ochenta, se ocuparon de formalizar reglas y llevarlas a un
formato procesable o entendible por un programa de computadora. A fines de
los ochenta, se comenz a utilizar entornos de desarrollo lo cual permitira un
avance importante hacia sistematizacin de este tipo de sistemas. En los
noventa, las investigaciones se centraron en el uso de nuevas metodologas,
permitiendo una real madurez de los procesos. La tabla 5.1 [Hidalgo05] refleja
esa evolucin.
Captulo V Estudio de los

SSBBCC
67
SE o SBC
Ao
GPS (General
Problem Solver)
1963
DENDRAL
(Universidad de
Stanford)
1968
MYCIN (Universidad
de Stanford)
1976
PROSPECTOR (SRI)
1981
KADS (Universidad de
Amsterdam)
Common KADS
(Universidad de
Amsterdam)
1992
2000
Uso experto
bsqueda de operadores, que eliminan la diferencia
entre un estado inicial y el estado final
separacin entre conocimiento y su forma de uso
infiere la estructura molecular a partir de un anlisis
espectogrfico de masas mediante resonancia
magntica
utilizacin de conocimiento especfico del dominio
diagnstico y tratamiento de desrdenes en la
sangre
aproximadamente 400 reglas que relacionan
condiciones a posibles interpretaciones
combina los elementos de primera generacin
(separa base conocimiento del motor de
inferencias, y el conocimiento especfico del
heurstico)
ayuda a la exploracin geolgica
desarrollo sistemtico
influencia de la ingeniera del software
madurez de metodologas
reconocimiento del papel central del conocimiento
Tabla 5.1. Breve resea de la evolucin de los SSBBCC.

5.3 RELACIN ENTRE LA INTELIGENCIA ARTIFICIAL (IA) Y LOS SSBBCC
Los SSBBCC, representan una de las reas bsicas de la IA, relacionada
con las capacidades humanas de actuar o interactuar en un dominio
determinado. Esas capacidades humanas son inherentes solamente a un grupo
muy reducido de personas. Este grupo al que se hace referencias lo forman
solamente los expertos. Una persona con estas caractersticas puede resolver
la mayora de los problemas o situaciones que se le plantean y que obviamente
corresponden a su dominio de conocimientos. La figura 5.1 [Hidalgo05],
muestra donde se sitan los SSBBCC y cual es su relacin con la IA .
68

SSBBCC
Los SSBBCC y la IA
IA
Razonamient
o
conocimiento
Percepcin
movimiento
Resoluc. Gral.
De Problemas
SSBBCC
Planificacin
Aprendizaje
Automtico
Robtica
Visin
Artificial
Procesamiento del Lenguaje Natural
Figura 5.1. Los SSBBCC y su relacin con la IA.

5.4 PRINCIPALES ACTORES DE UN SSBBCC
Un proyecto de desarrollo de SSBBCC, involucra a distintos actores o
grupos de personas claramente diferenciados, sin los cuales sera
prcticamente imposible llevar adelante este tipo de emprendimientos. Un
grupo est formado por el o los Ingeniero/s de Conocimiento (de aqu en ms
IC). Debido a que todo SE es un SBC, se puede decir que si este ltimo incluye
a un SE, ser necesario en el proyecto la intervencin de uno o varios
experto/s (de aqu en ms EX). Un experto, posee el conocimiento y
experiencia (tambin llamada experticia) para resolver un problema o realizar
una tarea en un dominio especial. Por ltimo est el grupo de los usuarios
(US) quienes en definitiva interactan con el sistema. Dentro de este ltimo,
tambin se encuentran los usuarios directivos que son los que deciden la
ejecucin del proyecto. Cuando el desarrollo del SBC, incluye a un SE, el grupo
de los IC es el que se encarga de mantener las primeras entrevistas, con el
segundo grupo (el de los EX). En ellas se capta informacin general de una
tarea o un problema que resuelve el experto. En esta etapa an no se sabe si
se va a acometer el desarrollo, pues hay una serie de estudios y anlisis que
se deben llevar a cabo como para evaluar su conveniencia. Si se concluye que
es viable desarrollar el SE en el marco de un SBC, los IC comienzan a realizar
entrevistas con un grado mayor de profundidad y con el propsito de obtener
(educir) informacin del experto. El IC debe llegar a un entendimiento
importante de la tarea que resuelve el experto, de lo contrario ser difcil
atravesar con xito las etapas de conceptualizacin y formalizacin de los
conocimientos. Una vez que estn formalizados los conocimientos e
incorporados en un software, se harn las primeras pruebas. En estas etapas
solamente interviene como usuario el EX, ya que es ste quien deber estar
SSBBCC
69
conforme con el sistema y sentir que es una herramienta til a los propsitos
para los que fuera construida. Una vez chequeada la conformidad del EX, se
puede implementar e instalar el SBC. En esta etapa entran en juego los US
quienes sern en definitiva los que usarn el SBC diariamente. Cuando este
grupo sienta que el SBC es de ayuda y que la intervencin del EX es casi nula,
se habrn cumplido con los objetivos del proyecto. Cabe aclarar que el grupo
de US, est formado por personas con un cierto conocimiento en el dominio del
problema en el que le toca actuar al SBC; es decir, a diferencia de otro tipo de
sistemas software, aqu el usuario deber tener tambin algo de experiencia.
5.5 ARQUITECTURA DE UN SBC
Los SSBBCC pueden ser diferenciados claramente en el dominio de la IA
de la siguiente forma: en primer lugar, ejecutan tareas que de alguna forma
resultan complicadas o simplemente difciles para cualquier ser humano y que
estn reservadas solamente a unos pocos en un dominio en particular. Para
ejecutar estas tareas o resolver los problemas que resuelven los expertos, los
SSBBCC, utilizan estrategias de bsqueda que comnmente se denominan
heursticas. Adems, emplean conocimientos para razonar acerca de sus
propios mtodos de inferencia y por ltimo proporcionan explicaciones o
justificacin de la solucin obtenida.
Un SBC se puede describir en tres niveles [Pazos Sierra05]:
Funcional: para poder entender este nivel y en el siguiente, habra
que definir lo que es arquitectura del sistema: es la ciencia y el
mtodo de diseo que determina las estructuras del sistema. El nivel
funcional hace una descripcin de cmo debiera aparecer el
sistema frente al usuario o como este debera verlo.
Lgico: es la implementacin que debe soportar la arquitectura

descrita.
Fsico: es la realizacin concreta del sistema.
Los SSBBCC suelen tener una arquitectura comn, la cual se puede ver en
la figura 5.2.
70

SSBBCC
ING. EN
CONOCIMIENTO
USUARIO
INTERFAZ DE
USUARIO
GENERADOR DE
EXPLICACIONES
EXPERTO
ADQUISICIN
DE
CONOCIMIENTO
MOTOR DE
INFERENCIAS
BASE DE
CONOCIMIENTOS
MARCOS
CONTROL
REGLAS
HECHOS
MEMORIA DE
TRABAJO
Figura 5.2. Arquitectura de un SBC.

Como se ilustra en la figura 5.2 la base de conocimientos alberga los
conocimientos relativos a la tarea que resuelve el experto. El motor de
inferencia es el encargado de aplicar esos conocimientos. La memoria de
trabajo (tambin conocida como base de hechos) contiene la informacin de
datos de entrada (o hechos) y conclusiones intermedias que se generan en el
proceso de razonamiento. El generador de explicaciones es el mdulo que
proporciona una explicacin coherente con la solucin encontrada y el porque
de las decisiones o pasos seguidos en el encaminamiento de la solucin. El
subsistema de adquisicin de conocimientos es el medio que facilita tanto la
inclusin como la actualizacin del conocimiento. Por ltimo la interfaz del
usuario permite establecer una comunicacin entre el SBC y el usuario.
SSBBCC
71
5.6 MODELO GENRICO PARA EL DESARROLLO DE SSBBCC

El desarrollo de un SSBBCC puede representarse con cinco fases
interdependientes [Buchanan83]. El desarrollo de un marco terico de las cinco
fases es extenso; en el presente trabajo, solamente se abordan los aspectos
ms importantes a los fines de determinar las caractersticas de la aplicacin.
Las fases se ilustran en la figura 5.3:
Figura 5.3. Fases para el desarrollo de SSBBCC.

Durante fase de identificacin del problema, se determina si la tarea
puede ser resuelta mediante un SBC; se definen caractersticas y se
especifican los requisitos que enmarcan la solucin. Una de las primeras
actividades del IC, es identificar las necesidades del cliente, siendo necesario
para ello describir los objetivos del sistema. En esta fase se realiza tambin el
estudio de la viabilidad; el cual es determinante para seguir adelante con el
desarrollo del SBC. Esta fase debe entregar una completa especificacin de
requisitos, con las caractersticas relevantes asociadas al desarrollo de la
aplicacin.
En la fase de conceptualizacin, se extraen los conocimientos de sus
fuentes ya sean pblicas (libros, documentos, manuales de procedimientos,
memos, etc.) o privadas (conocimientos del experto); luego, se los analizan
con el propsito de conseguir una mejor comprensin de la tarea. Una vez que
el IC entiende como el EX resuelve la tarea, se comienza con la construccin
del modelo conceptual, el cual determina la validez del sistema; es decir, si
el modelo es correcto y se ajusta a las necesidades del usuario. La
conceptualizacin se desarrolla en una doble etapa: una de anlisis y otra de
sntesis. Lo que se busca con el anlisis y la sntesis es obtener los modelos
esttico y dinmico; juntos modelan el comportamiento del experto. Los
conocimientos que se modelan en la conceptualizacin son tres (3):
Estratgicos: qu hacer, donde, porqu, etc.
Tcticos: cmo hacer, cuando hacer, etc.
Fcticos: especifican lo que se cree que es verdad acerca del mundo real.
En resumen, esta fase entrega como resultado el modelo conceptual que
tiene un doble propsito: por un lado le permite al IC tener un mayor
entendimiento de la tarea; y por otro al EX constatar sus conocimientos con
72

SSBBCC
aquellos modelados en esta etapa (tcticos, fcticos y estratgicos). Algunos

ejemplos de elementos que se usan para representar los conceptos son:
glosario de trminos, tablas concepto-atributo-valor, mapa de conocimientos,
rbol de descomposicin funcional y definicin de frmulas.
La fase de formalizacin, tiene como objeto expresar los conocimientos
conceptualizados mediante unas estructuras de datos que reciben el nombre
de formalismos. Las tcnicas de propsito general que razonan con estas
estructuras para resolver un problema se denominan motor de inferencias.
Algunos ejemplos de formalismos son: ternas(concepto-atributo-valor), marcos,
redes semnticas, clculos de predicados, dependencia conceptual, sistemas
de produccin y guiones. Los formalismos que modelan la parte esttica del
sistema son: marcos, redes semnticas y ternas (concepto-atributo-valor).
Aquellos que modelan la parte dinmica del sistema son entre otros las reglas
o sistemas de produccin. Una vez que se tiene una representacin del modelo
formal, el paso siguiente es llevarlo al plano computacional o mejor dicho a un
modelo entendible por una computadora.
Un aspecto que conviene tener en cuenta es la representacin del
conocimiento del control, el cual acta sobre todos los niveles de un SBC. Su
funcin es decidir qu conocimiento debe usarse, en qu momento, como
razonar sobre estos y que datos deben emplearse como entradas. Las
decisiones del control a travs del motor de inferencias, afecta a la totalidad del
SBC. En las bases de conocimiento (BC), determina cual de ellas se va a usar
o que parte de una de ellas se precisa en una etapa determinada del
razonamiento. En la memoria de trabajo (MT) el control establece hacia donde
focalizar la atencin. Tambin, el control, elige cual es la estrategia ms
adecuada y el conjunto de reglas a disparar. El componente de control, se
puede encontrar implcito como parte de la estrategia de control, o explcito en
algn lugar de la base de conocimiento. Existen tcnicas para representar este
conocimiento. Entre ellas se pueden nombrar a: metarreglas, agendas y
pizarras.
Otro aspecto a tener en cuenta, es el razonamiento aproximado. Sucede
que la mente humana y por ende la del experto no siempre razona con
certidumbre. La incertidumbre o el conocimiento incierto que usa el experto,
tambin debe ser representado por el SBC. Los modelos que permiten
representar el conocimiento incierto son: MYCIN, PROSPECTOR, DempsterShafer, redes bayesianas y lgica difusa.
Una vez que se ha logrado conceptuar y formalizar los conocimientos,
comienza la fase de implementacin, donde se codifican los conocimientos.
Cuando los modelos conceptual y formal han sido construidos y el IC est de
acuerdo con los formalismos de representacin del conocimiento de control,
conocimiento incierto, y tiene un entendimiento de la problemtica y de la
terminologa usada por el experto, y los presupuestos de la organizacin donde

SSBBCC
73
se implementa el SBC y la interfase del usuario, entonces el IC est en

condiciones de seleccionar una herramienta para la implementacin.
Esta seleccin no es fija; es decir, si el problema por su naturaleza amerita
un enfoque basado en reglas, la eleccin de una herramienta que ms se
adapte a este formalismo ser lo adecuado; lo mismo ocurre con los marcos u
otros formalismos. Otro aspecto a tener en cuenta es la eleccin entre un
lenguaje de programacin y un una herramienta (o entorno de desarrollo).
Las alternativas que se pueden presentar son las siguientes:
implementacin ad-hoc del sistema usando lenguaje de programacin,
el uso de una herramienta que ya exista en la organizacin pero que no
haba sido adquirida para el problema que se quiere resolver,
la seleccin de una herramienta idnea existente en el mercado,
una herramienta especializada ad-hoc.
Una vez seleccionado el entorno de desarrollo (herramienta y arquitectura
del sistema) el modelo conceptual gua la implementacin y permite crear un
diseo de implementacin al aplicar el modelo conceptual sobre las
capacidades de la herramienta. Como ejemplo de lenguajes de programacin
se pueden citar a: C, C++, modula, etc. Y entre los entornos o herramientas se
cuentan: KEE, KAPPA, ART, etc.
La ltima fase del proceso de desarrollo es la evaluacin, donde se deber
comprobar que la aplicacin funciona correctamente y responde a los
requerimientos del usuario. El creciente desarrollo de los SSBBCC ha
producido una necesidad importante con respecto a su fiabilidad. Esto sugiere
que dejen de ser tratados como meros productos artesanales, para convertirse
en verdaderos productos industriales. Es por ello que la evaluacin de este
tipo de software es crucial, al tiempo que llevada a cabo en forma ordenada y
sistemtica permite lograr productos cada vez ms confiables. La relacin con
el EX es muy estrecha; y es l quin determina, en definitiva, si el software
brinda las respuestas esperadas. La evaluacin no es una fase que se lleva a
cabo una vez finalizado el proceso de desarrollo; ms bien, se encuentra
imbricada a lo largo de dicho proceso. La tarea de desarrollar un SBC, es ms
bien parecida a la de un escultor que la de un arquitecto. Los requisitos no
quedan estticos (o congelados) como en otros tipos de software en las etapas
tempranas; estos van tomando distintas formas hasta satisfacer las
necesidades del usuario y, o convertirse en el sistema final.
Son mltiples y variados los criterios sobre los cuales realizar evaluaciones
de los SSBBCC. Sin embargo, existen cuatro aspectos sobre los cuales se
evalan los SBC; ellos son:
Correccin: determina si el sistema es correcto y se realiza sobre el modelo
formal.
Validez: determina si el sistema es vlido y se realiza parte sobre el modelo
formal y parte sobre el modelo computable.
74

SSBBCC
Usabilidad: determina si el sistema es amigable para el usuario.

Operatividad: determina si el sistema es operativo y condice con los
objetivos de la organizacin.
5.7 DIFERENCIAS Y SIMILITUDES CON OTROS TIPOS DE SISTEMAS
Si bien es cierto se han mencionado algunas diferencias entre los SSBBCC
y el resto de los sistemas software, conviene hacer una comparacin en un
cuadro donde se las pueda visualizar correctamente.
Resto de Sistemas Software
SSBBCC
Usan como soporte a la ingeniera del

software para el proceso de construccin.
Usan como soporte a la ingeniera del

conocimiento,
para
el
proceso
de
construccin.
Los tipos de problemas que resuelve son de
caractersticas heurstica y declarativos.
Sus especificaciones no son del todo
completas.
Centran su atencin en los conocimientos
(hechos, creencias, teoras y, o heursticas).
Procesos son inferidos.
Un SBC est formado por el conocimiento y el
control. Existe un separacin entre la
codificacin del conocimiento y la codificacin
del control. Esto produce la ventaja de que
cualquier modificacin en uno u otro, no afecta
el funcionamiento general del SBC.
Una entrada puede tener varias soluciones y
el sistema puede explicar como llega a cada
una de esas soluciones.
Los tipos de problemas que resuelve son

procedimentales y sistemticos
Tienen especificaciones completas
Centran su atencin en los datos.
Sus procesos son repetitivos.
Los programas estn formados
estructuras de datos y algoritmos.
por:
Tienen una solucin nica. Cada entrada

produce una nica salida.
Tabla 5.2. Diferencias entre los SSBBCC y el resto de sistemas software.

En este captulo se ha querido exponer las principales caractersticas de
los SSBBCC, como funcionan, sus diferentes tipos de representaciones y en
que fase conviene usarlas. Si bien es cierto, se puede profundizar en lo que
respecta a este tipo de software, no es objeto de este trabajo hacerlo. Si resulta
necesaria alguna profundizacin especial para poner en relieve algn elemento
o alguna caracterstica, se lo har en el captulo VI, donde se realiza un
abordaje de la solucin del problema.

SSBBCC
75
CAPTULO VI
TCNICA
DE
ESTIMACIN
PARA
SSBBCC
CAPTULO VI
TCNICA DE ESTIMACIN PARA SSBBCC
6.1 INTRODUCCIN
En este captulo, se exhibe una tcnica para realizar estimaciones en
proyectos que incluyan el desarrollo de SSBBCC. Primero se presentan los
conceptos y las reglas en torno a las cuales gira la solucin propuesta. Luego
se propone un proceso con sus respectivas etapas. Por ltimo se aplica las
frmulas que permiten obtener la funcionalidad y estimaciones de costo, tiempo
y esfuerzo.
6.2 LA ESTIMACIN Y EL ESTUDIO DE VIABILIDAD DEL SISTEMA
Si el proyecto, que se va a acometer es llevado con una metodologa de
desarrollo, en alguna etapa se realiza el estudio de viabilidad del sistema. El
objetivo de dicho estudio es el anlisis de un conjunto concreto de necesidades
para proponer una solucin a corto plazo, que tenga en cuenta restricciones
econmicas, legales y operativas [Mtrica v304].
Si se ha seleccionado a IDEAL como metodologa de desarrollo, en una de
sus primeras etapas, se realiza el estudio de la viabilidad, cuyo objetivo es
determinar si el sistema que se va a desarrollar es viable. Para ello, se hacen
entrevistas abiertas al experto o al grupo de expertos (en el caso que sea ms
de uno), con el objeto de entender en lneas generales cual es la tarea que
realiza o el problema que resuelve. Con los datos obtenidos de la entrevista, se
le asigna un valor a unas caractersticas (plausibilidad, justificacin, adecuacin
y xito) como para determinar si el sistema es o no viable [Pazos Sierra05]. Si
se est usando Mtrica V3, existe una serie de actividades conducentes a
determinar la viabilidad del sistema [Mtrica v304]; esas actividades son:
establecimiento del alcance del sistema (EVS1),
estudio de la situacin actual (EVS2),
definicin de requisitos del sistema (EVS3),
estudio de alternativas de solucin (EVS4),
valoracin de las alternativas (EVS5),
seleccin de la solucin (EVS6).
Una vez completadas estas actividades, es posible determinar si el
desarrollo del sistema es o no viable. Por otro lado, y tal como se ha
mencionado en prrafos anteriores, para asignarle algn valor a las
caractersticas del estudio de viabilidad, se ha efectuado una entrevista abierta
al experto o al grupo de expertos que conocen la tarea, o que resuelven el
problema en particular. En el caso de los SSBBCC, y al finalizar el estudio de
viabilidad, se puede aplicar una tcnica tendiente a determinar en forma
aproximada el tamao del software a construir; y en base a este tamao,
Captulo VI Tcnica de
Estimacin Para SSBBCC
79
realizar estimaciones de costo, tiempo y esfuerzo necesarios para acometer el

desarrollo.
6.3 DESARROLLO DE LA TECNICA PROPUESTA PARA ESTIMACIN DE
COSTO, TIEMPO Y ESFUERZO EN SSBBCC
El propsito de la tcnica propuesta, es realizar mediciones en etapas
tempranas del desarrollo del SBC, y poder obtener en forma aproximada su
tamao funcional y con esos valores realizar estimaciones de costo, tiempo y
esfuerzo. Las reglas generales son:
el software a medir es un SBC,
las mediciones pueden ser efectuadas en etapas tempranas, y a lo largo del
desarrollo,
las mediciones se realizan independientemente de la tcnica aplicada para
el desarrollo del software a medir,
el tamao aproximado del software a medir, se basa en los requerimientos
funcionales del usuario (RFU),
la tcnica permite realizar mediciones en software del tipo SBC, el cual
deber poder ser descrito mediante transacciones lgicas, compuestas
cada una de estas por entradas, conceptos y salidas.
La tcnica que se propone permite realizar mediciones en un SBC; pero al
no haber difusin del uso de este tipo de tcnicas en este tipo de sistemas,
existe la posibilidad de que se produzcan algunos defasajes en los resultados.
No obstante, se prev en la herramienta software, la posibilidad de efectuar
calibraciones con el propsito de adecuar los parmetros, a los resultados que
se vayan obteniendo. La satisfaccin de dichos resultados estar en funcin del
grado o porcentaje de certeza que se adquiera al medir los valores estimados
contra los valores reales.
6.3.1 REGLAS QUE SE APLICAN AL MTODO DE MEDICIN
Existe un nmero de reglas que se deben aplicar al mtodo de medicin y
que ayudan a que su proceso sea exitoso. Dichas reglas se exhiben a
continuacin:
Regla 1 Lmites de la aplicacin:
1.1 El mtodo se utiliza para medir la funcionalidad requerida por el o los
usuarios de la aplicacin, dentro de unos lmites establecidos.
1.2 La aplicacin o la parte de ella encerrada por los lmites establecidos,
deber ser coherente en trminos de funcionalidad, y debe constar de una
o ms transacciones lgicas.
1.3 Se define al lmite de la aplicacin como la lnea imaginaria que separa
conceptualmente al entorno del software y al software propiamente dicho.
80
Regla 2 Tamao funcional y transacciones lgicas:

2.1 El tamao funcional de una aplicacin es la suma de los tamaos
funcionales de cada una de las transacciones lgicas que la componen.
2.2 Una transaccin lgica es el nivel ms bajo de proceso y que es de
inters para el usuario, conformada por una entrada que cruza los lmites
de la aplicacin desde la parte de afuera, un proceso de inferencia y una
salida que vuelve a cruzar los lmites de la aplicacin hacia fuera.
2.3 Una transaccin lgica es disparada por un nico evento que es de
inters para el usuario. Cuando se completa dicha transaccin, debe dejar
el SBC totalmente operativo y en estado consistente.
2.4 Si una transaccin es ejecutada por ms de un proceso, solamente se
cuenta una vez.
2.5 Cualquier transaccin lgica que se ejecute en el sistema y no
representa un requerimiento funcional del usuario (RFU), no se cuenta en
el tamao de la aplicacin.
Regla 3 Componente proceso de actualizacin e inferencia (PAI) de las
transacciones lgicas:
3.1 Cada proceso de actualizacin de una transaccin lgica puede ser
analizado en funcin de cmo aade, borra o modifica reglas (subsistema
de adquisicin de conocimientos).
Regla 4 Componente de entrada y salida de las transacciones lgicas:
4.1 Tanto las entradas como las salidas se cuentan en funcin de los tipos
de datos elementales (o primarios) (DETs) que cruzan los lmites de la
aplicacin.
4.2 Un DET es un tipo de dato elemental, nico e indivisible y que sirve a
los objetivos de la aplicacin y que cruza los lmites de esta ltima. Son
ejemplos de DETs los atributos de una tabla concepto, atributo valor (CAV).
Regla 5 Tamao de las transacciones lgicas:
5.1 El valor total del tamao de una aplicacin es la sumatoria del producto
entre el componente coeficiente de ajuste lgico (CAL) por la cantidad de
entradas, conceptos y salidas, de cada una de las transacciones lgicas
identificadas, se exhibe en la frmula 6.1:
81
PFSBC =CALE *por cantidad de entradas identificadas +

CALS* por cantidad de salidas identificadas +
CALC* por cantidad de conceptos identificados +
(6.1)
donde:
PFSBC: Se calcula para cada transaccin lgica; luego, se suman
todos los valores de PFSBC para obtener el total de
puntos de funcin de la aplicacin
CAL:
es el coeficiente de ajuste lgico
Los valores del CAL son los siguientes:
CALE = 0.80
CALS = 0.80
CALC = 1.20
Los valores del coeficiente de ajuste lgico inicialmente se los obtiene de
mediciones efectuadas en proyectos industriales [Industrial Technology03].
Como se puede apreciar, los conceptos (CALC) tienen mayor injerencia que las
entradas y salidas (CALE CALS). Por ejemplo una transaccin lgica con los
siguientes valores:
Entradas = 10
Salidas = 5
Conceptos = 7
Se calcula el valor de PFSBC de la siguiente forma:

PFSBC = (10*0.80) + (5 * 0.80) + (7*1.20) = 8 + 4 + 8.4 = 20.4
Regla 6 Requerimientos funcionales del usuario:
6.1 Los requerimientos funcionales del usuario (RFU), generalmente se
derivan de la documentacin correspondiente a las especificaciones de
requisitos.
6.2 Los RFU, expresan que se incluye y que se excluye desde el punto de
vista de las necesidades del usuario en la aplicacin que se est por medir.
6.3.2 ETAPAS DEL PROCESO DE MEDICIN
Cualquier proceso de medicin debe llevarse a cabo en un marco de
ordenamiento de las etapas y de las actividades involucradas en cada una de
ellas. Por lo expuesto, resulta oportuno definir una secuencia de pasos o
etapas que deben llevarse a cabo con el objeto de que el proceso de medicin
tenga ordenamiento y prolijidad. La figura 6.1, muestra una secuencia de las
etapas y los productos obtenidos en cada una de ellas.
82
INICIO
FIN
PROCESO DE MEDICIN
DEFINIR
OBJETIVOS DE
LA MEDICIN
DEFINIR
LMITES DE LA
APLICACIN A
MEDIR
IDENTIFICAR
TRANS.
LGICAS
CONTABILIZAR
ENTRADAS,
SALIDAS Y
CONCEPTOS
CALCULAR EL
TAMAO
FUNCIONAL
APLICAR
AJUSTE DE
COMPLEJIDAD
TCNICA
CALCULAR
PRODUCTIVIDAD,
TIEMPO, COSTO
Y ESFUERZO
DOCUMENTO
DE OBJETIVOS
DE LA
MEDICIN
DOCUMENTO
DE DEFINICIN
DE LMITES
DOCUMENTO
DE TRANSACC.
LGICAS
IDENTIFICADAS
DOCUMENTO DE
ENTRADAS,
SALIDAS Y
CONCEPTOS
CONTADOS
TAMAO
FUNCIONAL DE
LA APLICACIN
VALOR DEL
AJUSTE DE
COMPLEJIDAD
TCNICA (ACT)
PRODUCTIVIDAD,
TIEMPO, COSTO
Y ESFUERZO
(ESTIMADOS)
PRODUCTOS OBTENIDOS DEL PROCESO

DE MEDICIN
Figura 6.1. Proceso de medicin y productos obtenidos.

Etapa 1 - Definicin de los Objetivos de la Medicin.
En esta etapa, se identifica al cliente (o usuario) que demanda la aplicacin
a ser medida y se define el objetivo de la misma. Es muy importante tambin
identificar de manera clara sus requisitos y la funcionalidad solicitada contra la
funcionalidad a ser entregada por el sistema software. Algunas cuestiones que
debieran tenerse en cuenta son:
qu abarca el proyecto: desarrollo, modificacin, soporte o mantenimiento,
cul es su contexto,
cul es el grado de exactitud demandado por el usuario (medicin exacta o
aproximada).
Como resultado de esta etapa se obtiene un documento de definicin de
objetivos de la medicin (anexo I.A).
Etapa 2 - Definicin de los Lmites de la Aplicacin a Medir.
La ejecucin de esta etapa implica trazar los lmites de la aplicacin y
definir cuales son las transacciones lgicas que se incluyen y cuales no. Esta
eleccin se realiza en base a los RFU. Adems, se identifican las interfaces,
tanto de entrada como de salida. El soporte donde queda documentado cuales
son los lmites de la aplicacin es el documento de definicin de lmites (anexo
I.B).
Etapa 3 - Identificacin de Transacciones Lgicas.
En esta etapa se identifican a las transacciones lgicas que en conjunto
representan a los RFU. Las transacciones lgicas son el nivel ms bajo de
proceso soportado por la aplicacin y que se encuentra dentro de los lmites de
la misma. Como resultado de esta etapa, se obtiene el documento de
transacciones lgicas (anexo I.C).
83
Etapa 4 - Contabilizacin de Entradas, Salidas y Conceptos (este ltimo

tambin se lo denomina objetos).
En cada transaccin lgica, se debe contabilizar la cantidad de tipos de
dato de entrada, tipos de datos de salida y objetos (o conceptos) del (de los)
proceso(s) de inferencia. Cabe la aclaracin que para el mtodo presentado en
este trabajo de tesis, solamente se incluyen como representaciones
intermedias a las tablas o ternas concepto, atributo, valor (CAV), dejando otros
tipos de representaciones para futuros estudios de esta naturaleza. La
enumeracin de estos elementos (entradas, salidas y conceptos) queda
registrada en el documento respectivo (anexo I.D).
Etapa 5 Clculo del Tamao Funcional.
El tamao funcional de la aplicacin es la sumatoria de la cantidad de
entradas, salidas y conceptos por sus respectivos coeficientes de ajuste lgico
(CAL). La frmula (6.2) para calcular el tamao expresado en puntos de funcin
de un SBC (PFSBC) es:
PFSBC =CALE *por cantidad de entradas identificadas
CALS* por cantidad de salidas identificadas
CALC* por cantidad de conceptos identificados
(6.2)
Como resultado de la aplicacin o del desarrollo de esta etapa, se obtiene

el tamao aproximado de los puntos de funcin sin ajustar de la aplicacin.
Etapa 6 Clculo del Ajuste de Complejidad Tcnica (ACT).
El ACT, permite definir valores tcnicos que se aplican al resultado
obtenido de los puntos de funcin. Este valor puede variar entre 1 y 2.42 (12.42). Como resultado del desarrollo de esta etapa se obtienen los puntos de
funcin ajustados a las caractersticas del entorno de la aplicacin.
Etapa 7 Clculo de Productividad, Tiempo, Costo y Esfuerzo.
Esta es la ltima etapa del proceso. Una vez que se tienen los puntos de
funcin ajustados, es posible obtener valores aproximados de productividad,
costo, tiempo y esfuerzo requeridos para el desarrollo de la aplicacin.
6.3.3 DESARROLLO DE CADA UNA DE LAS ETAPAS DEL PROCESO
Una vez definidas a nivel general las etapas de del proceso de clculo del
tamao, se desarrollan una a una con el propsito de dar una visin ms
amplia y ms clara de sus conceptos y como se deben aplicar en un proyecto
concreto.
84
6.3.3.1 DETERMINACIN DE LOS OBJETIVOS DE LA MEDICIN

Como se ha mencionado en la regla 1 del punto 6.3.1, uno de los primeros
pasos que se debe dar en el marco del proceso de contabilizacin de
funcionalidad es determinar los lmites de la aplicacin a medir; es decir, qu
funcionalidad se incluye y qu funcionalidad se excluye de la cuenta. Otro
aspecto a tener en cuenta es el punto de vista desde el cual se va a comenzar
a desarrollar el proceso de medicin. Para ello se definen tres criterios a saber:
I. El punto de vista del producto: se especifica la funcionalidad entregada (o
liberada) para una aplicacin que se quiere medir; ya sea que se est
acometiendo un nuevo desarrollo, o se est por realizar alguna
modificacin (mantenimiento, correcciones o mejoras) en un producto
existente o como soporte del mismo.
II. El punto de vista de la gestin de proyecto: cuando se desea hacer un
seguimiento de las aplicaciones desarrolladas en relacin a las
estimaciones efectuadas de las mismas.
III. El punto de vista del negocio: cuando se quiere hacer una valuacin total
de las aplicaciones.
Para cumplir con los objetivos del trabajo de tesis, se toma en cuenta
solamente el punto I.
6.3.3.2 DEFINICIN DE LOS LMITES DE LA APLICACIN A MEDIR
Como se ha mencionado, los lmites de la aplicacin determinan qu
funcionalidad se incluye y qu funcionalidad queda excluida. Ese lmite o
frontera es una lnea imaginaria que separa conceptualmente al entorno de la
aplicacin propiamente dicha. Un dato de entrada, o simplemente una entrada
cruza esa lnea para ingresar en la aplicacin. A su vez un dato de salida, o
simplemente una salida, cruza los lmites de la aplicacin para ponerse a
disposicin del usuario. Dentro de los lmites de la aplicacin, estn los
conceptos que han sido obtenidos luego de entrevistas efectuadas a
experto(s) del dominio del conocimiento y que se incluyen en la contabilizacin
de la funcionalidad. Los atributos de los conceptos son alcanzados por las
reglas en cada proceso de inferencia para llegar a un objetivo. Ese objetivo,
representa una respuesta que brinda el SBC al usuario en funcin de sus
requerimientos funcionales.
El usuario, y tal como se ha definido en el captulo IV, puede ser una
persona o una aplicacin. Ambos son demandantes de conocimientos, de
acuerdo a como se hayan definido los objetivos del sistema software a medir.
Ya sea que se trate de una persona o una aplicacin, cualquiera sea el caso,
esta cruza los lmites de la aplicacin y produce los siguientes efectos:
nuevos hechos en la base de hechos,
alcance de objetivos intermedios,
85
encadenamiento de reglas (aquellas que cumplen con una cierta condicin),

razonamiento en funcin de un cierto nmero de reglas,
disponibilidad del resultado de ese razonamiento para el usuario.
En resumen una transaccin lgica debera estar formada por:
I. una entrada que cruza (ingresa) los lmites de la aplicacin; y que
corresponde a hechos iniciales que le permiten al SBC elaborar las
primeras conclusiones,
II. un proceso de inferencia que dispara una cierta cantidad de reglas; las
equipara con los hechos iniciales, interpreta esas reglas y comienza un
proceso de encadenamiento de las condiciones y acciones hasta
satisfacer una condicin de parada, que puede ser de xito o de
fracaso;
III. un proceso de actualizacin de conocimiento (incluido en el
subsistema de adquisicin de conocimiento), que permite actualizar la
base de conocimientos;
IV. una salida que produce un resultado de ese razonamiento, cruza los
lmites de la aplicacin y se pone a disposicin del usuario.
La figura 6.2 muestra (dentro de la lnea roja) los lmites de una aplicacin
de estas caractersticas.
86
ING. EN
CONOCIMIENTO
USUARIO
EXPERTO
LMITE DE LA APLICACIN
SUBSISTEMA DE
EXPLICACIN
SUBSISTEMA DE
USUARIO
SUBSISTEMA DE
ADQUISIC. DE CONOC
Procesad. De Texto
Entradas on-line
Herramientas de
Depuracin de la Base
de Conocimientos
MENUES
GRAFICOS
HECHOS Y
DATOS
ESPECFICOS
EXPLICACIONES
Y CONSEJOS
BASE DE
CONOCIMIENTOS
MARCOS
CONTROL
REGLAS
HECHOS
MOTOR DE
INFERENCIAS
Encadenamiento
(adelante-atrs)
Unificacin,
equiparacin
Agenda, pizarra
Razonamiento
aproximado
Etc.
LMITE DE LA APLICACIN
Figura 6.2. Lmites de una aplicacin de SSBBCC.

6.3.3.3 IDENTIFICACIN DE INTERFACES
Si el sistema que se est por construir est embebido en otro, y recibe o
enva desde, hacia este ltimo, datos o conocimientos, habr que tener
consideracin en las interfaces. Cuando se reciben datos desde otra aplicacin,
hay que tener en cuenta el esfuerzo que debe hacer el sistema en validarlos.
Cuando se enva informacin hacia otra aplicacin que embebe al sistema que
87
est siendo medido, hay que considerar el formato de los datos de salida (o
datos remitidos hacia otra aplicacin). Tanto las validaciones (de las entradas)
como las adecuaciones de los datos de salida deben ser contabilizadas.
6.3.3.4 IDENTIFICACIN DE TRANSACCIONES LGICAS
Una vez trazados los objetivos, mbito y lmites del la aplicacin, se
identifican todas las transacciones lgicas que intervienen en el proceso de
medicin. Al principio del proyecto, los requerimientos funcionales del usuario,
son un tanto imprecisos, de orden general y; en etapas posteriores, pueden
sumarse algunas transacciones lgicas que hayan sido pasadas por alto. Como
se trata de una estimacin, las mediciones que se efecten sern
aproximadas. No obstante, es importante este proceso ya que se pretende
que el grado de confianza de dicha medicin sea lo ms alto posible.
Una transaccin se inicia cuando se dispara un evento nico que es de
inters para el usuario, o por un requerimiento de informacin (o
conocimientos). Dicha transaccin debe completarse correctamente y dejar el
sistema totalmente operativo.
Algunos tipos de transacciones lgicas, pueden ser:
Crear, eliminar, consultar o modificar datos (reglas): este tipo de
i)
transaccin se presenta cuando se quiere actualizar la base de
conocimientos. Se pueden crear, eliminar, modificar o consultar
reglas. Un ejemplo de este tipo de transaccin se puede ver en la
tabla 6.1.
Ejemplo de una transaccin de actualizacin de reglas
Evento /
ID-Transaccin
Tipo de Transaccin
Consulta
IDT001
Agregar una regla
IDT002
Eliminar una regla
IDT003
Consultar o visualizar
reglas
Tabla 6.1. Desagregacin de una transaccin lgica de actualizacin de reglas.

Como se observa en la tabla 6.1, una transaccin que aparece en la
lista de requisitos como actualizacin de reglas, puede estar
compuesta a su vez por una o ms sub-transacciones (agregar,
eliminar y consultar).
ii)
88
Inferir conocimientos: este tipo de transaccin se presenta cuando

en base a un conjunto de hechos iniciales se dispara un proceso de
inferencia con la finalidad de obtener a cambio una conclusin o un
resultado de una parte de conocimiento experto. El sistema,
adicionalmente, podr requerir ms informacin o hechos iniciales,
para posteriormente disparar un proceso de inferencia; hasta que se

cumpla alguna condicin de parada. Esta condicin puede ser
alguna de las siguientes:
que haya fallado la bsqueda y la respuesta no se encuentre en
el espacio de soluciones,
que se haya alcanzado el objetivo, con lo cual el sistema brinda
la respuesta esperada.
La transaccin est compuesta por:
una entrada, con uno o ms DETs (atributos y valores),
una entrada que permite al usuario disparar un evento que hace
posible que comience el proceso de inferencia,
un proceso de inferencia,
una salida (o una respuesta del experto) y,
una salida capaz de explicar el modo de razonamiento y justificar
esa respuesta.
El tamao de las entradas es proporcional al nmero de DETs identificados
del lado de las entradas; otro tanto sucede con las salidas y; por ltimo, los
conceptos identificados se cuentan para asignarle valor a el(los) proceso(s) de
inferencia.
En el lado de las entradas, las operaciones tpicas son las de solicitud de
datos (hechos iniciales) y su correspondiente validacin. Por su parte, las
salidas realizan la tarea de preparar (formatear) y presentar las respuestas del
experto al usuario. Los conceptos, conjuntamente con los atributos y sus
valores asociados a cada uno de estos son los que reflejan el conocimiento
que maneja el experto. Cuando comienza un proceso de inferencia, los valores
de los atributos se equiparan y se encadenan hasta lograr un objetivo
determinado y enviar una respuesta hacia el lado de las salidas.
6.3.3.4.1 CONTABILIZACIN DE MENS E INICIOS DE TRANSACCIONES
En la mayora de las aplicaciones existe una pantalla de presentacin y un
men o una serie de mens que orientan al usuario en la navegacin por las
distintas pantallas, que en definitiva corresponden a las funciones del software
a medir. Cuando estos mens no llevan consigo valores o parmetros que se
trasladan o envan de una funcin a otra, no se deben contabilizar; sin
embargo, cuando estn cargados con algn valor que le es de utilidad a la
funcin disparada, se deben contabilizar en esta ltima como datos de entrada.
Otro caso ocurre con aquellos datos que inician la transaccin, los cuales
deben ser contados como DETs.
89
6.3.3.4.2 CONTABILIZACIN
TRANSACCIONES LGICAS
DE
ENTRADAS
SALIDAS
EN
Las entradas de los SSBBCC, son hechos iniciales necesarios para

equiparar reglas en un proceso de inferencia. Esos hechos, pueden ser
preguntas que el sistema le hace al usuario, para que este ltimo responda y;
con esas respuestas, el SBC realiza dicha equiparacin hasta llegar a una
condicin de parada. Con cada grupo de respuestas se crean nuevos hechos
para lograr los objetivos antes mencionados. Esas preguntas (que el sistema le
hace al usuario) esperan una respuesta de este ltimo, en cuyo caso, dicha
respuesta deber ser validada como para determinar si se encuentra dentro de
un rango permisible. Por ejemplo, si se trata de un SBC que detecta
infecciones respiratorias, y se pide el ingreso de un valor de temperatura
corporal, 60 C, no es un valor permisible, ya que una persona no puede tener
un valor mayor de los 41 C o 42 C. Entonces esas entradas deben ser
validadas por el sistema. El esfuerzo desde el punto de vista de la construccin
del software que se realiza en la validacin, tambin debe ser contabilizado.
Por otro lado cuando las salidas requieren un formato especial para lograr
un mejor entendimiento por parte del usuario, existe tambin una
contabilizacin.
Cada entrada que requiere un tratamiento diferente o cada salida que
necesite ser mostrada en forma diferente, deben ser contadas aparte del resto.
Existe una facilidad que se encuentran presente en la mayora de las
aplicaciones; facilidad que se denomina interfaz grfica del usuario (GUI del
ingls graphical user interfaces). Este tipo de interfaz hace agradable la visita y
la navegacin por los distintos sectores o pantallas del software o aplicacin a
medir. Los elementos que conforman las GUIs, y que deben o no ser incluidos
en la contabilizacin se muestran a continuacin:
Check box (casilla de verificacin): Permite el ingreso y, o la salida
i)
de datos que tienen la caracterstica de poder ser visualizados y
representados mediante dos valores (verdadero o falso). La
contabilizacin de estos elementos debe hacerse contando como un
tipo de dato elemental DET, ya sea para las entradas o salidas de
una transaccin lgica. Un ejemplo de este tipo de elemento se
muestra en la figura 6.3.
90
Figura 6.3. Elemento check box.

ii)
Edit box (casilla de edicin) / text box (casilla de texto): este tipo de
elemento es sencillo y se usa para ingresar datos y debe ser
contabilizado como una entrada. Un ejemplo se muestra en la figura
6.4.
Figura 6.4. Elemento edit box.

iii)
Drop down / pop up list box: las cajas de listas pueden actuar como
entradas o salidas en transacciones lgicas, cuando se quiere
seleccionar o mostrar un valor entre varios. La figura 6.5, muestra un
ejemplo de este tipo de elemento. Pueden darse tres casos del uso
del drop down / pop up list box:
a. una lista que no hace referencia a ningn objeto de la tabla CAV.
Este caso se presenta cuando se quiere seleccionar un valor de
entre varios y que funciona como un parmetro del sistema. En
este caso se debe contar como un DET,
b. una lista cuyos elementos hacen referencia a una transaccin
lgica claramente identificable. Tambin se debe contar como un
DET,
c. Cuando aparece un cuadro de texto, indicando que se debe
seleccionar un valor de la lista, se debe contabilizar tambin a
dicho cuadro.
Figura 6.5. Elemento drop down / pop up list box.

91
iv)
Radio button (botn radial): este recurso se emplea cuando se

necesita que el usuario seleccione una opcin entre varias; siempre y
cuando no sean ms de cinco o seis, ya que si ocurre esto ltimo ya
debera usar otro tipo de elemento. Se debe contar como un DET por
cada conjunto de radio buttons incluidos en la transaccin lgica. La
figura 6.6 muestra un ejemplo de este tipo de elemento.
Figura 6.6. Elemento radio button.

v)
Dialog box (cuadro de dilogo): este recurso puede incluir a

cualquiera de los cuatro elementos mencionados anteriormente.
Pueden estar presentes uno, dos, tres o cuatro en un mismo cuadro
de dilogo. El cuadro de dilogo no se cuenta como DET o como
elemento de una transaccin lgica.
6.3.3.5 IDENTIFICACIN DE CONCEPTOS U OBJETOS

Es importante que el encargado del proyecto pueda identificar las
transacciones lgicas. A partir de estas, debe ser posible identificar conceptos,
entradas y salidas. Dos herramientas (una ms que otra) importantes para esta
etapa son el diccionario de conceptos y la tabla conceptos-atributosvalores. Con estos elementos es posible ir rellenando las tablas que solicitan la
informacin de referencia. El mtodo de estimacin se basa justamente en los
conceptos identificados para poder realizar los clculos que le permiten estimar
el tamao aproximado del software a desarrollar.
6.3.3.6 AJUSTE DE COMPLEJIDAD TCNICA
El ajuste de complejidad tcnica (ACT) permite valorar algunos
requerimientos que no pueden ser manipulados por las transacciones lgicas.
Estos requerimientos deben tener algn soporte dentro del proceso de
medicin; y ese soporte, es precisamente el ACT. Cuando se aplica este
coeficiente, vara el resultado de la cuenta de puntos de funcionalidad. La
forma de darle valor a las caractersticas que estn incorporadas en el ACT, es
uno (1) cuando el nivel de esfuerzo adicional es muy bajo o no hay injerencia
alguna y cinco (5) cuando sucede lo contrario (alto grado de esfuerzo
adicional). La totalidad de los valores se muestra en la tabla 6.2.
92
Valor
1
2
3
4
5
Esfuerzo adicional
Muy poco
Moderado
Medio
Significativo
Total
Tabla 6.2. Valores de influencia en las caractersticas.

La frmula (6.3) para realizar el clculo del ACT es:
ACT = (SUM_CAR*COE_ACT)+VAR
(6.3)
donde
SUM_CAR
COE_ACT
VAR
es la sumatoria de las caractersticas

es el coeficiente de ajuste de complejidad tcnica (en
un principio ese coeficiente es de 0,035).
es la variacin, cuyo valor es de 0.65
Con respecto al valor del ACT, se pueden hacer algunas consideraciones.

En primer lugar, y a diferencia de algunos de los mtodos vistos en el captulo
IV, las caractersticas tcnicas de la aplicacin y del entorno de desarrollo que
se evalan son diez (10). Cada una puede tomar el valor de uno (1) cuando
esa caracterstica no implique esfuerzo alguno o no tenga injerencia y cinco (5)
cuando alcance su valor mximo, es decir, cuando requiera el mximo de
esfuerzo. Estas diez caractersticas han sido seleccionadas en base a una
aproximacin al mtodo de MK II [Symons98], del cual se han suprimido
algunas que no son propias de los desarrollos de proyectos que incluyen a
SSBBCC y se han agregado otras como por ejemplo la posibilidad de que el
sistema razone en forma aproximada, como un aporte personal del autor del
trabajo al mtodo. En segundo lugar el COE_ACT o coeficiente de ajuste de
complejidad tcnica, tiene un valor de 0.035. Este valor puede ser calibrado (o
modificado) luego de sucesivas mediciones en diferentes SSBBCC.
Como se trata de un trabajo acadmico, solamente se cuenta con
resultados histricos de estudios empricos realizados para aquellos mtodos
capaces de aceptar el ajuste de complejidad como variable que modifica el
valor original de los puntos de funcin; y, que adems, representan la
valoracin subjetiva de la aplicacin a medir. El valor de VAR o simplemente
variacin, asume en un principio el valor de 0.65. Ahora bien, si todas las
caractersticas toman el mnimo (1), la sumatoria de estas dar como resultado
diez (10), con lo cual el ACT no tendr influencia alguna en el resultado final de
los puntos de funcin, ya que el ACT tomar el valor de 1 (uno). En el supuesto
caso de que todas las caractersticas tomen el mayor valor posible (5), los
puntos de funcin tendrn que ajustarse multiplicndolos por un valor igual a
2.4.
93
Las caractersticas de ajuste de complejidad tcnica a tener en cuenta son:

i) Facilidad de comunicacin de datos: son los datos o informacin de
control que la aplicacin utiliza y se enva o recibe a travs de las
facilidades (sistema) de comunicacin. Por ejemplo un SBC que debe
recibir hechos iniciales desde una PC que se encuentra en una ubicacin
remota con respecto al procesador donde se realizan las inferencias,
requiere un esfuerzo distinto (mayor en este caso) a un sistema donde los
datos se capturan y se procesan todos en una PC o en un mismo lugar
fsico. Igual consideraciones debieran hacerse para las salidas de datos,
con respecto al procesador donde se realizan las inferencias. Los valores
La aplicacin no necesita de comunicaciones remotas, las
entradas, el proceso de inferencia y las salidas se realizan en
un solo procesador.
La aplicacin no necesita de comunicaciones remotas, pero las
entradas, y las salidas se realizan en un procesador distinto al
de los procesos de inferencia. Es tpicamente una red de rea
local.
Salidas y, o entradas son remotas y no hay exigencias de
tiempo de respuesta.
Salidas y, o entradas son remotas, y hay exigencias de tiempo
de respuesta.
Valor
1
3
4-5
ii) Conocimientos distribuidos: los conocimientos pueden estar

almacenados en uno o en varios procesadores distintos, ubicados estos en
distintos lugares fsicos. En este caso la comunicacin entre las distintas
partes del conocimiento del experto, aportan un cierto grado de
complejidad a la aplicacin. Los valores que puede tomar la caracterstica
son:
El conocimiento se encuentra centralizado en un solo
procesador.
El conocimiento se encuentra distribuido pero dentro de los
lmites de una red de rea local.
El conocimiento se encuentra distribuido y los procesadores
donde se encuentra almacenado estn ubicados en forma
remota y requieren de facilidades de comunicacin entre ellos.
Valor
1
2-3
4-5
iii) Rendimiento: referido a la importancia del tiempo de respuesta dentro de

todo el SBC. Este tipo de facilidad se puede ver influenciada por el diseo,
desarrollo, instalacin y soporte de la aplicacin. Los valores que puede
94
Anlisis y diseo de las consideraciones del rendimiento son
estndar. No se precisan requerimientos especiales por parte
del usuario.
En la fase de diseo se incluyen tareas del anlisis del
rendimiento para cumplir los requerimientos del usuario.
Adems se utilizan herramientas de anlisis del rendimiento en
el diseo, desarrollo e instalacin.
Valor
1
2-4
5
iv) Uso masivo del procesador: se refiere a la importancia del uso del
procesador del componente del hardware. De hecho, cuando se dispara un
proceso de inferencia, la equiparacin de reglas demanda una alta tasa de
ocupacin del procesador. Si el SBC, debe compartir el procesador con
otras aplicaciones, hay que tener en cuenta consideraciones en el diseo
de los procesos de inferencia. Los valores que puede tomar la
caracterstica son:
La aplicacin corre en una mquina estndar sin restricciones
de operacin.
Restricciones de operacin requieren caractersticas
especficas de la aplicacin en el procesador central.
Adems hay restricciones especficas a la aplicacin en los
componentes distribuidos del sistema.
Valor
1
2-3
4-5
v) Diseo para la eficiencia de usuario final: determina si el ingreso de

hechos iniciales requiere que se lleven a cabo sobre mltiples pantallas u
operaciones especiales. Los valores que puede tomar la caracterstica son:
No se especifican requerimientos especiales
Se incluyen tareas de diseo para la consideracin de
factores humanos.
Adems se utilizan herramientas especiales o de prototipado
para promover la eficiencia.
Valor
1
2-4
5
vi) Utilizable en otras aplicaciones: el cdigo se disea para que sea

compartido o utilizable por otras aplicaciones. Es deseable que el motor de
inferencia se mantenga lo ms independiente posible de las reglas y estas
puedan ser actualizadas en etapas de post-desarrollo. Los valores que
puede tomar la caracterstica son:
95
El motor de inferencias responde a las necesidades de una
organizacin usuaria.
El motor de inferencias responde a ms necesidades que las
de un usuario.
Valor
1-3
45
vii) Facilidad de Instalacin cuando se necesita de un desarrollo aparte

para la instalacin de la aplicacin, se le asignar mxima puntuacin. Los
No se requieren por parte del usuario facilidades especiales
de conversin e instalacin.
Los requerimientos de conversin e instalacin son descritos
por el usuario y se proporcionan guas de conversin e
instalacin.
Adems se proporcionan y prueban herramientas de
Valor
1
23
45
viii) Facilidad de operacin: los usuarios de los SSBBCC, son aquellos que
tienen un cierto conocimiento de cmo se resuelve la tarea o como el
experto emite un diagnstico. Si bien es cierto estos usuarios no tienen la
categora de expertos, tienen bastante conocimiento sobre el dominio del
problema; es por ello, que muchos SBC no requieren de facilidades de
operacin. Los valores que puede tomar la caracterstica son:
No se especifican por parte del usuario consideraciones
especficas de operacin
La aplicacin se disea para operacin sin atencin
Valor
1-3
4-5
ix) Puestos mltiples: cuando el sistema se construye para ser ejecutado

en diferentes regiones, y los conocimientos del experto se deben exportar a
otros pases con diferentes monedas o idiomas, aumenta su puntuacin, ya
que esto le aade un cierto grado de complejidad. Los valores que puede
El usuario no requiere la consideracin de ms de un tipo de
usuario.
Se incluyeron necesidades de varios tipos de usuarios en el
diseo.
Se proporciona documentacin y plan de apoyo para soportar
la aplicacin en varios lugares
Valor
1
23
45
x) Razonamiento aproximado: toma valores mayores a uno (1) cuando el

conocimiento del experto no es del todo preciso y el SBC debe razonar con
96
un cierto grado de incertidumbre. Los valores que puede tomar la

caracterstica son:
Valor
Los hechos son ciertos.
Los hechos son inciertos. El SBC demanda razonamiento
aproximado.
1-2
3-5
La frmula final (6.4) para calcular los puntos de funcin totales ser:
PFASBC = ((CALE * E )+ (CALS* S) + (CALC* C)) * ACT
(6.4)
donde:
E
S
C
PFASBC
son las entradas

son las salidas
son los objetos (o conceptos de la tabla CAV)
Es la cuenta total de puntos de funcin ajustados
6.3.3.7 CLCULO DE PRODUCTIVIDAD, COSTO, TIEMPO Y ESFUERZO

Una vez que se han obtenido los puntos de funcionalidad ajustados con las
caractersticas tcnicas, es posible lograr medidas de productividad; y de estas,
derivar estimadores de costo, tiempo y esfuerzo. Para dar cumplimiento con el
primer punto, se ha considerado la frmula desarrollada por Symons con
algunas adecuaciones y que ofrece como resultado la productividad P (frmula
6.5).
[ ]
P= A*
0.11 e
[ ]
S-250
575
1.1
+ 0.01*S
522
6.5
donde:
S
P
A
Son los puntos de funcionalidad ajustados o PFASBC

Es la productividad en puntos de funcionalidad desarrollados
por hora
Es un parmetro que se ajusta en base al entorno de
desarrollo, puede variar entre 1 y 1.6. Preferentemente se
debera usar 1.6.
La frmula 6.5 est adaptada los proyectos que incluyen desarrollos de

SSBBCC.
97
Por ejemplo para un proyecto con cuarenta (40) puntos de funcin totales o
ajustados, y A = 1.6, el valor de P ser de aproximadamente 0.201. El
significado del resultado de esta expresin es el siguiente: la productividad o la
cantidad de puntos de funcin que se pueden desarrollar en una hora, es de
0.201. Si se quiere saber el tiempo que demanda el desarrollo de cuarenta
(40) puntos de funcin, se lo puede obtener mediante una relacin directa:
0.201 PFASBC
1 hora / hombre
40 PFASBC
40 PFASBC X1 hora / hombre

0.201 PFASBC
=199 hs / hombre
6.6
Como se puede apreciar en la frmula 6.6 (relacin directa), el desarrollo

de cuarenta (40) puntos de funcionalidad demanda aproximadamente
doscientas (200) horas/hombre; este valor representa el esfuerzo medido en
horas de trabajo por persona.
Si se quiere saber el tiempo (frmula 6.7) que se necesita para desarrollar
esa cantidad de puntos de funcionalidad, se deber realizar el cociente entre el
tamao estimado del software y el valor resultante de la productividad. La
frmula (6.7) para obtener este resultado se muestra a continuacin.
E=
tamao (PFASBC)
productividad
6.7
El resultado de la frmula 6.7 debe ser expresado en personas u hombre

por unidad de tiempo. En este caso, y para seguir el ejemplo anterior, si
PFASBC es igual a 40, el valor de E ser aproximadamente igual a 200.
El tiempo de desarrollo necesario puede ser expresado en horas, semanas
o meses de acuerdo a las necesidades de informacin de gestin. En este caso
200 hs. pueden representar aproximadamente cinco (5) semanas con una
carga horaria de cuarenta (40) horas semanales.
El costo de desarrollo se debera calcular en funcin de proyectos que se
hayan desarrollado con anterioridad. Si se calcula el costo solamente de los
recursos humanos o el costo de programacin, ser necesario multiplicar el
valor de la hora por la cantidad de horas insumidas.
98
PARTE II
(PRCTICA)
Construccin
de la
Herramienta
de
Software
CAPTULO VII
DEFINICIN
DEL
PROYECTO
DE
DESARROLLO
DE
SOFTWARE
CAPTULO VII
DEFINICIN DEL PROYECTO DE DESARROLLO DE SOFTWARE
7.1 INTRODUCCIN
La segunda parte del trabajo comienza con el captulo VII. En esta parte se
desarrollan las actividades que tienen como objetivo la construccin de una
herramienta de software. Tambin se selecciona el ciclo de vida para acometer
el desarrollo, se realiza una lista de actividades a desarrollar y se presentan los
aspectos relativos a la planificacin del proyecto de desarrollo de software. En
la planificacin se realiza tambin la estimacin aproximada del esfuerzo,
aplicando algunas las tcnicas vistas en el captulo IV. El captulo culmina con
la gestin de la configuracin [Mtrica V304].
7.2 SELECCIN DEL CICLO DE VIDA DEL DESARROLLO
Una de las primeras actividades en todo proceso de desarrollo de un
producto software es la seleccin del ciclo de vida. Si bien es cierto, no existe
un nico modelo de ciclo de vida que defina los estados por los que pasa un
producto software, hay una variedad que permite seleccionar uno en base a
unas especificaciones iniciales y a informacin que se conoce antes del
desarrollo propiamente dicho. Al respecto se pueden hacer algunas
consideraciones:
i)
el problema es perfectamente conocido,
ii)
no se precisa de un grupo de desarrollo, ya que el tamao del
software no es grande; es mas bien pequeo,
iii)
el usuario puede describir sus requisitos,
iv)
los riesgos son mnimos.
Dadas estas caractersticas preliminares, se sugiere un ciclo de vida en
cascada o comnmente denominado clsico, el cual tiene la particularidad de
permitirle al producto evolucionar a travs de una secuencia ordenada de
transiciones de una fase a otra, segn un orden lineal. Se pueden realizar
iteraciones dentro de una misma fase o se puede volver a alguna de las
anteriores.
7.3 LISTA DE PROCESOS Y ACTIVIDADES A DESARROLLAR
La metodologa de desarrollo de software seleccionada para el presente
trabajo es (como se ha mencionado) mtrica V3. Ahora bien; mtrica V3
propone una serie de fases (o procesos), actividades y tareas, de las cuales no
todas se llevan a cabo en el presente trabajo (por tratarse de una tesis). La
tabla 7.1, tiene por objeto que el lector conozca que actividades se desarrollan
y cuales sern pasadas por alto.
Captulo VII Definicin del

Proyecto de Desarrollo de
Software
101
Cdigo
GP
GPI 1
GPI 2
GPS
GPF
GC
EVS-GC 1
EVS-GC 2
GC 1
GC 2
EVS-CAL
ASI-CAL
DSI-CAL
CSI-CAL
IAS-CAL
PSI
PSI 1
PSI 2
PSI 3
PSI 4
PSI 5
PSI 6
PSI 7
PSI 8
PSI 9
EVS
EVS 1
EVS 2
EVS 3
EVS 4
EVS 5
EVS 6
ASI
ASI 1
ASI 2
ASI 6
ASI 7
ASI 8
ASI 9
ASI 10
ASI 11
DSI
DSI 1
DSI 2
DSI 5
DSI 6
DSI 7
DSI 8
DSI 9
DSI 10
DSI 11
DSI 12
CSI
CSI 1
CSI 2
CSI 3
CSI 4
CSI 5
CSI 6
CSI 9
IAS
IAS 1
IAS 5
IAS 6
IAS 9
IAS 10
MSI
MSI1
MSI2
MSI3
MSI4
Procesos y Actividades
Gestin del Proyecto
Estimacin del esfuerzo
Planificacin
Actividades de seguimiento y control
Actividades de finalizacin del proyecto
Gestin de la Configuracin - GC
Definicin de los req. de gestin de la configuracin
Establec. del plan de gest. de la configuracin
Identificacin y registro de productos
Identificacin y registro del producto global
Identificacin de las propiedades de calidad del sistema
Revisin del anlisis de consistencia
Revisin de la arquitectura del sistema
Revisin de las pruebas unitarias, de integracin y sistema
Revisin de las pruebas de aceptacin del sistema
Plan de Sistemas de Informacin (PSI)
Inicio del plan de sistemas de informacin
Definicin y organizacin del PSI
Estado de informacin relevante
Identificacin de requisitos
Estudio de los sistemas de informacin actuales
Diseo del modelo de sistema de informacin
Definicin de la arquitectura tecnolgica
Definicin del plan de accin
Revisin y aprobacin
Estudio de Viabilidad del Sistema (EVS)
Establecimiento del alcance del sistema
Estudio de la situacin actual
Definicin de requisitos del sistema
Estudio de alternativas de solucin
Valoracin de las alternativas
Seleccin de la solucin
Anlisis del Sistema de Informacin (ASI)
Definicin del sistema
Establecimiento de requisitos
Elaboracin del modelo de datos
Elaboracin del modelo de procesos
Definicin de interfaces del usuario
Anlisis de consistencia
Especificacin del plan de pruebas
Presentacin y aprobacin del anal. de sist. de Inf
Diseo del sistema de Informacin (DSI)
Definicin de la arquitectura del sistema
Diseo de la arquitectura de soporte
Diseo de la arquitectura de mdulos del sistema
Diseo fsico de datos
Verificacin y aceptacin de la arq. del sistema
Generacin de especificaciones de construccin
Diseo de migracin y carga inicial de datos
Especificacin tcnica del plan de pruebas
Establecimiento de requisitos de implantacin
Aprobacin del diseo sistema de informacin
Construccin del Sist. de Informac (CSI)
Preparacin del entorno de gen. y const.
Generac. del cd. de los comp. y de los proc.
Ejecucin de las pruebas unitarias
Ejecucin de las pruebas de integracin
Ejecucin de las pruebas del sistema
Elaboracin de manuales del usuario
Aprobacin del sistema de informacin
Implantacin y aceptacin del sistema (IAS)
Establecimiento del plan de implantacin
Pruebas de implantacin del sistema
Pruebas de aceptacin del sistema
Presentacin y aprobacin del sistema
Paso a produccin
Mantenimiento del Sistema de Informacin (MSI)
Registro de la peticin
Anlisis de la peticin
Preparacin de la implementacin de la modificacin
Seguimiento y eval. de los cambios hasta la aceptacin
Aplica en Tesis
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
Si
No
No
No
No
Tabla 7.1. Procesos y actividades de elaboracin del software.

102

Software
7.4 ESTIMACIN DE ESFUERZO (GPI 1)

El objetivo de esta actividad es conocer en etapas tempranas del desarrollo
el tamao aproximado del sistema que se est por construir. Adems,
establecer el costo, la duracin y los recursos necesarios para lograr
desarrollarlo.
Es muy difcil calcular en forma exacta el esfuerzo requerido para el
desarrollo de cualquier proyecto informtico, debido a la gran cantidad de
factores que intervienen en su realizacin, algunos de ellos inciertos y otros
desconocidos. Sin embargo, las tcnicas de estimacin permiten obtener
valores aproximados suficientes para definir el desarrollo del proyecto.
7.4.1 IDENTIFICACIN DE LOS ELEMENTOS A DESARROLLAR (GPI 1.1)
Esta tarea tiene como finalidad determinar la cantidad y caracterstica de
los elementos a desarrollar a partir de un modelo abstracto cuyo grfico ha sido
exhibido en la figura 2.1 del captulo II. Este grfico muestra el proceso de
clculo de puntos de funcin y su correspondencia con el tamao aproximado
de la aplicacin que se va a desarrollar. La descripcin de la aplicacin, puede
presentarse como una rplica de la expuesta en el captulo II; es decir, el
usuario encargado del proyecto necesita realizar una estimacin del tamao del
producto software a desarrollar, ingresa los datos que le solicita el software de
dicha aplicacin y; la aplicacin le devuelve una valor estimado de tamao,
esfuerzo, costo y tiempo.
Basado en este modelo y en la solucin a implementar se pueden
identificar a priori los elementos que se exhiben en la tabla 7.2.
7.4.2 CLCULO DEL ESFUERZO (GPI 1.2)
Una vez identificados los elementos a desarrollar se utiliza la tcnica de
estimacin apropiada para calcular el esfuerzo necesario para el desarrollo.
La aplicacin a desarrollar, resulta relativamente sencilla, no modifica el
entorno y no presenta mayores complejidades en los clculos de las
operaciones aritmticas. Adems, es posible que sea descrita en trminos de
entradas, salidas, consultas, archivos lgicos internos y archivos lgicos
externos. Una de las tcnicas que ms se adapta a este tipo de aplicaciones es
la de puntos de funcin de Albrecht.
Segn la IFPUG [IFPUG04], y tal como se ha mencionado en el captulo IV
los puntos de funcin se calculan a partir de los cinco elementos que se
pueden identifican en las etapas previas al desarrollo y que son:
entradas externas (EI),

salidas externas (EO),

Software
103
consultas externas (EQ),

archivos lgicos internos (ILF),
archivos lgicos externos (ELF).
Una vez que han sido identificados los tipos de elementos, se les debe
asignar una complejidad que vara segn su cantidad de ocurrencias. En tal
caso, esa complejidad puede tomar tres valores: baja, media o alta. La tabla
7.2 refleja los elementos identificados y su correspondiente complejidad.
FUNCIONES TRANSACCIONALES IDENTIFICADAS
TIPO DE ELEMENTO
Entradas Externas (EI)
Salidas Externas (EO)
Consultas Externas(EQ)
DESCRIPCIN DE ELEMENTO
Ingresar valores para medicin
Ingresar caractersticas de ajuste de
complejidad tcnica
Actualizar parmetros de clculo
Actualizar valores de complejidad tcnica
Actualizar valores de caractersticas tcnicas
Mostrar resultados de la medicin
Mostrar resumen de resultados de mediciones
Mostrar detalle de resultados de mediciones
Mostrar detalles de de ajustes de complejidad
tcnica
Listar datos proyectos
Listar proyectos y resultados
Pantalla de presentacin del producto
Men principal
Men de ingreso de datos de mediciones
Men de consulta de resultados de
mediciones
Men de reportes y listados
Men de parmetros de mediciones
Mensajes de error
COMPLEJIDAD
Media
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
GRUPOS DE DATOS LGICOS

TIPO DE ELEMENTO
Archivo lgico interno (ILF)
DESCRIPCIN DE ELEMENTO
Tabla de mediciones
Tabla de entradas identificadas
Tabla de salidas identificadas
Tabla de conceptos identificados
Tabla de elementos de entrada
Tabla de elementos de salida
Tabla de descripcin de transacciones lgicas
Tabla de ajustes de complejidad tcnica
Tabla de valores de complejidad tcnica
Tabla de parmetros
COMPLEJIDAD
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Baja
Tabla 7.2. Elementos identificados.

En el captulo IV, se ha desarrollado la frmula para calcular los puntos de
funcin sin ajustar y los puntos de funcin ajustados. Para el primer caso, se
cuentan los elementos identificados y se suma dicha cantidad por el valor
asignado segn la valoracin de la complejidad. En la tabla 7.3 se muestra el
104

Software
clculo del total de los puntos de funcin sin ajustar para los elementos
identificados.
Componente
Complejidad
Peso
Alta
15
ILF
Media
10
Baja
7
Alta
10
ELF
Media
7
Baja
5
Alta
6
EI
Media
4
Baja
3
Alta
7
EO
Media
5
Baja
4
Alta
6
EQ
Media
4
Baja
3
Cuenta total de puntos de funcin sin ajustar
Cantidad
0
0
10
0
0
0
0
1
4
0
0
6
0
0
7
Subtotal
(peso *
cantidad)
0
0
70
0
0
0
0
4
12
0
0
24
0
0
21
131
Tabla 7.3. Tabla para clculo de puntos de funcin sin ajustar.

Una vez obtenidos los puntos de funcin sin ajustar, se analizan las
caractersticas de la aplicacin y del entorno de desarrollo con el objeto de
obtener el factor de ajuste, tomando en cuenta una serie de valoraciones
subjetivas que debe realizar el encargado del proyecto. Esas valoraciones (son
catorce en total) se analizan a continuacin:
1. Comunicacin de datos: la aplicacin se desarrolla para una
computadora personal, sin necesidad de la realizacin de comunicaciones
remotas. El valor de la complejidad es 0.
2. Funcin distribuida. la aplicacin es monoltica; es decir, se desarrolla
para un solo computador. El valor de la complejidad es 0.
3. Rendimiento: el anlisis y diseo de las consideraciones del rendimiento
son estndar. No se precisan requerimientos especiales por parte del
usuario. El valor de la complejidad es 2.
4. Configuracin utilizada masivamente: la aplicacin corre en una mquina
estndar sin restricciones de operacin. El valor de la complejidad es 2.
Software
105
5. Tasas de transaccin: las tasas son tales que las consideraciones de

anlisis de rendimiento son estndares. El valor de la complejidad es 2.
6. Entrada en lnea de datos: 30% al 50% de las transacciones tienen
entrada interactiva. El valor de la complejidad es 5.
7. Diseo para la eficiencia de usuario final: no se especifican
requerimientos especiales. El valor de la complejidad es 2.
8. Actualizacin en lnea: actualizacin en lnea de la mayora de los
archivos internos lgicos. Adems es esencial la proteccin contra la
prdida de datos. El valor de la complejidad es 4.
9. Complejidad del procesamiento: el procesamiento es ms bien simple. El
valor de la complejidad es 0.
10. Utilizable en otras aplicaciones: la aplicacin responde a las
necesidades de una sola organizacin usuaria. El valor de la complejidad
es 1.
11. Facilidad de Instalacin: no se requieren por parte del usuario
facilidades especiales de conversin e instalacin. El valor de la
complejidad es 1.
12. Facilidad de operacin: no se especifican por parte del usuario
consideraciones especficas de operacin. El valor de la complejidad es 0.
13. Puestos mltiples: el usuario no requiere la consideracin de ms de un
puesto. El valor de la complejidad es 0.
14. Facilidad de cambio: se proporciona capacidad de consulta flexible. El
valor de la complejidad es 0.
Una vez que se ha valorado la complejidad tcnica de la aplicacin y de su
entorno de desarrollo conviene mostrarlo en una tabla y tener una idea de
cmo influye cada uno de los parmetros en el resultado final (tabla 7.4).
106

Software
Caracterstica de Complejidad Tcnica

1. Comunicaciones de datos.
2. Datos o procesamiento distribuidos.
3. Objetivos de rendimiento.
4. Configuracin utilizada masivamente.
5. Tasa de transaccin.
6. Entrada de datos en lnea.
7. Eficiencia para el usuario.
8. Actualizacin en lnea.
9. Procesamiento complejo.
10. Reutilizacin.
11. Facilidad de instalacin y conversin.
12. Facilidad de operacin.
13. Puestos mltiples.
14. Facilidad de cambio.
Suma total de caractersticas tcnicas
Valor
0
0
2
2
2
5
2
4
0
1
1
0
0
0
19
Tabla 7.4. Suma de parmetros de ajuste de complejidad tcnica.

Una vez sumados los parmetros correspondientes a las caractersticas de
la aplicacin y de su entorno, se pueden calcular los puntos de funcin
ajustados (FPA). La frmula (7.1) para hacerlo es la siguiente:
FA = 0,65 + (0,01 * de los 14 factores de influencia o caractersticas)

FPA = FP (sin ajustar) * FA (7.1)
Reemplazando por los valores obtenidos, la frmula quedara de la
siguiente forma:
FA = 0,65 + (0,01 * 19) = 0.84
FPA = 131 * 0.84 = 110.04
El resultado final del clculo para el desarrollo de la aplicacin demanda
aproximadamente 110 puntos de funcin. Como se puede notar al no ser una
aplicacin con mayores dificultades (solamente pretende demostrar un estudio
terico) no son altos los valores de funcionalidad.
Para llevar a cabo la estimacin del esfuerzo necesario, tiempo, personas
por mes (PM del ingls persons month) y el costo se acudir al mtodo de
COCOMO II [Bohem98].
La frmula (7.2) para obtener el PM o personas mes, se describe a
continuacin:
PM = 2.94*tamaoE*PRODUCTORIA(i=1 n)EMi (7.2)
Software
107
donde:
tamao se expresa en miles de lneas de cdigo
EM son los factores de ajuste de costo (tabla 7.5)
E exponente no lineal calculado segn la frmula:
E=0.91 + (0.01 * SUMATORIA(i_1n)SFi ) (7.3)
Los SF o factores de escalamiento se calculan segn las tablas que se
exhiben a continuacin:
i)
PREC Desarrollo previos similares

Valor
0.00
1.24
2.48
3.72
4.96
6.20
ii)
FLEX Flexibilidad del desarrollo (por ejemplo grado de acuerdo

con requerimientos pre-establecidos o interfaces externos preexistentes)
Valor
0.00
1.01
2.03
3.04
4.05
5.07
108
Descripcin de factor
el nuevo desarrollo es idntico a los previos
el nuevo desarrollo es muy parecido a los previos
el nuevo desarrollo es bastante parecido a los previos
el nuevo desarrollo tiene aspectos novedosos
el nuevo desarrollo es muy diferente
el nuevo desarrollo es totalmente diferente
metas generales
cierto acuerdo
acuerdo general
cierta flexibilidad
flexibilidad ocasional
Riguroso

Software
iii)
RESL Manejo de riesgos y arquitectura

Valor
0.00
1.41
2.83
4.24
5.65
7.07
iv)
TEAM Cohesin del equipo de desarrollo

Valor
0.00
1.10
2.19
3.29
4.38
5.48
v)
el plan identifica todos los riesgos crticos y establece
hitos para resolverlos
el plan identifica la mayora de los riesgos crticos y
establece hitos para resolverlos
el plan identifica muchos de los riesgos crticos y
el plan identifica algunos de los riesgos crticos y
el plan identifica pocos riesgos crticos y establece hitos
para resolverlos
el plan no identifica riesgos crticos
descripcin de factor
interacciones fluidas
interacciones altamente cooperativas
interacciones principalmente cooperativas
interacciones bsicas cooperativas
algunas interacciones difciles
interacciones difciles
EMPL Nivel de madurez estimada en relacin al modelo CMM

Valor
0.00
1.56
312
4.68
6.24
7.80
descripcin de factor
nivel 5
nivel 4
nivel 3
nivel 2
nivel 1 superior
nivel 1 inferior
Una vez presentados los factores de escalamiento, se muestra un detalle

de los factores de costo, cuyo producto determina el valor del parmetro EM.
COCOMO II sugiere que muchos de esos factores no pueden estimarse en
etapas tempranas del desarrollo, razn por la cual se reducen a siete.

Software
109
Valores que pueden tomar los Ems

Mutiplicadores de
Esfuerzo (EM)
RCPX Confiabilidad y
complejidad del
producto
RUSE - Nivel de
reutilizacin
extremo
bajo
0.73
muy bajo
0.81
PDIF - Dificultad de
uso de plataforma
PERS - Capacidad
del personal de
desarrollo
PREX - Experiencia
del personal de
desarrollo
FCIL - Facilidad del
desarrollo
SCED - Exigencias
sobre el calendario
bajo
nominal
alto
muy alto
extremo
alto
0.98
1.00
1.30
1.74
2.38
0.95
1.00
1.07
1.15
1.24
0.87
1.00
1.29
1.81
2.61
2.12
1.62
1.26
1.00
0.83
0.63
0.50
1.59
1.33
1.12
1.00
0.87
0.71
0.62
1.43
1.30
1.10
1.00
0.87
0.73
0.62
1.43
1.14
1.00
1.00
1.00
Tabla 7.5. Valoracin del esfuerzo en la etapa del diseo pre-arquitectnico

(COCOMO II).
Una vez presentado los parmetros y sus distintas valoraciones, se
procede a personalizarlos o adaptarlos al escenario que se presenta para el
desarrollo de la herramienta software de estimacin para SSBBCC.
Para hacerlo ms claro al proceso de clculo del esfuerzo, se enumeran
los pasos a seguir:
1.- Como primera medida se parte de los puntos de funcin ajustados (110
FP en este caso), los cuales deben ser convertidos a lneas de cdigo
(LOC). Esta es una condicin para comenzar a realizar los clculos en el
marco del modelo COCOMO II. La conversin a
LOC se realiza
multiplicando los FP por el valor correspondiente segn los fabricantes de
las distintas herramientas de programacin existentes en el mercado. En
este caso corresponde asignar por cada punto de funcin, treinta y cinco
(35) lneas de cdigo [QSM05]. El valor de 35, extrado de la publicacin de
la empresa QSM, dedicada mostrar gratuitamente estos valores, que
corresponde a la cantidad promedio de lneas de cdigo que se asignan en
funcin de la herramienta seleccionada para la programacin del software.
Para este caso particular la cantidad de LOC ser de 3850 y las KLOC (o
miles de lneas de cdigo) sern en total 3,850.
2.- Luego y para continuar con la obtencin de los valores que componen la
frmula (1), se calcula el exponente E. La sumatoria de dicho exponente se
la obtiene a partir de la valoracin otorgada a los parmetros exhibidos en
110

Software
prrafos anteriores como factores de escalamiento (SF). Para esta

aplicacin en particular, esos parmetros toman valores que se muestran
en la tabla 7.6.
Factor de
Escalamiento (SF)
PREC - Desarrollo
similares
FLEX - Flexibilidad
del desarrollo
RESL - Manejo de
riesgos
TEAM - Cohesin del
Justificacin
Valoracin
El nuevo desarrollo es totalmente diferente
6.20
Los requisitos no son rigurosos pero deben respetarse
3.04
Se identifican pocos riesgos crticos
5.65
EL equipo es unipersonal, con lo cual no presenta

0.00
equipo de desarrollo dificultades

No hay exigencias por tratarse de un trabajo acadmico
EPML
Suma total de los factores de escalamiento (SF)
7.80
22.69
Tabla 7.6. Valoracin y suma de los SFs en base a las especificaciones de

la aplicacin.
Una vez que se tiene el valor total de la suma de los SFs, se procede a
calcular el valor del exponente E:
E=0.91 + (0.01 * 22.69) = 1.1369
(7.4)
3.- Una vez que se tiene el valor del exponente E, se calcula el producto de
los multiplicadores de esfuerzo (EM) (tabla 7.7).
Mutiplicadores de Esfuerzo
(EM)
RCPX - Confiabilidad y
complejidad del producto
Justificacin
La confibilidad no es extremadamente crtica. A pesar
de ello las formulas que involucren los recursos a ser
estimados deben ser rigurosamente controlados.
Valor
1.00
RUSE - Nivel de
Este desarrollo no se realiza para que sea reutilizado.
reutilizacin
PDIF - Dificultad de uso de
No existen limitaciones en el uso de la plataforma
plataforma
La capacidad del personal de desarrollo no es crtica,
PERS - Capacidad del
pues no existen exigencias por parte del usuario. S se
requiere de conocimiento especializado en tcnicas de
personal de desarrollo
estimacin.
PREX - Experiencia del
No se exige experiencia
personal de desarrollo
FCIL - Facilidad del
Se requiere conocimiento de la herramienta de
desarrollo pero no es crtico
desarrollo
0.83
SCED - Exigencias sobre el No hay exigencias de calendario, ms all de aquellas

relacionadas con fechas de entrega del trabajo final.
calendario
1.00
El producto total de los multiplicadores de esfuerzo es
0.79
0.95
1.00
1.00
1.00
Tabla 7.7. Resultados del producto de los multiplicadores de esfuerzo (EM).

Software
111
4.- Ahora se realiza el clculo de PM con los resultados obtenidos de las

tablas 7.6 y 7.7 en las frmulas 7.2 y 7.4:
PM = 2.94*3.8501.1369*0.79 = 10,75 meses/hombre
(7.5)
5.- A partir del resultado de PM, se puede calcular el tiempo que insume el
desarrollo con la frmula 7.6:
TDEV = 3.67*PM0.28+0.002*SUMA(SF)
(7.6)
Reemplazando por los valores correspondientes, la frmula arroja el

siguiente resultado:
TDEV = 3.67 * 10.75 0.28+(0.002*22.69) = 7.94 8 meses (7.7)
Una vez que se ha determinado la duracin aproximada, se asigna una
parte de ese tiempo total a cada una de las fases (tabla 7.8). A modo de
consideraciones, se asume que la carga horaria mensual es de cien (100)
horas aproximadamente. Como consecuencia de ello, para un tiempo total
estimado de ocho (8) meses, se estiman ochocientas (800) horas.
Fase
Descripcin de Fase
GP
Gestin del Proyecto
GC
Gestin de la Configuracin
CAL
Aseguramiento de la Calidad
ASI
Anlisis del Sistema de Informacin
DSI
Diseo del Sistema de Informacin
CSI
Construccin del Sistema de Informacin
IAS
Implantacin y Aceptacin del Sistema de Informacin
Total en horas estimadas
Tiempo Estimado
en Hs.
55
60
20
210
230
185
40
800
Tabla 7.8. Distribucin del tiempo por fases de la metodologa.

7.5 PLANIFICACIN (GPI 2)
El objeto de esta actividad es definir y preparar las condiciones de trabajo,
estableciendo recursos, fechas y costos para lograr los objetivos que se
persiguen con el proyecto. La planificacin de un proyecto establece fechas
previstas para la realizacin del conjunto de actividades que lo componen,
teniendo en cuenta el calendario y las fechas de inicio y finalizacin de cada
una de ellas.
A continuacin se presenta un cronograma tentativo para la ejecucin de
las fases de la metodologa mtrica V3 (figura 7.1), su ordenamiento y el
tiempo que se estima que lleve el cumplimiento de cada una. Para una mejor
visualizacin, y a diferencia de la escala empleada en la tabla 7.8, la variable
correspondiente a la duracin de cada una de las fases, se expresa en das.
112

Software
Figura 7.1. Cronograma tentativo de ejecucin de las fases de mtrica V3 y

tiempo insumido.
Como condicionantes, se puede concluir que debido a la poca o nula
interrelacin con externos al proyecto, no se identifican a aquellos que puedan
producir algn impacto negativo en el proyecto; por ende, no existe riesgo
potencial de que la fecha de finalizacin del proyecto sufra retrasos.
7.6 SEGUIMIENTO Y CONTROL DEL PROYECTO (GPS)
El seguimiento y control tiene como objetivo fundamental la vigilancia de
todas las actividades de desarrollo del sistema. Para poder ejercer un correcto
seguimiento y control de proyecto, es necesario que el Jefe de Proyecto
dedique todo el tiempo que sea necesario para vigilar cada una de las tareas
que se estn desarrollando, prestando especial inters a aquellas que estn
sufriendo algn retraso.
Las actividades de seguimiento y control del proyecto se llevan a cabo
desde la asignacin de tareas hasta la aceptacin interna por parte del equipo
de proyecto, previa la aceptacin del cliente prevista en mtrica V3. Las tareas
de seguimiento y control se realizan a medida que se ejecutan las de anlisis,
diseo, construccin, implantacin y mantenimiento del sistema.
Para el caso particular de la aplicacin a construir, hay actividades que se
dejan de lado debido a que se trata de un trabajo acadmico. Sin embargo, se
realiza un seguimiento y control del proyecto mediante el registro del tiempo
efectivamente insumido para cada una de las tareas, el cual es comparado con
el planificado. Los registros se muestran en el apndice B.
Software
113
7.7 GESTIN DE LA CONFIGURACIN

La gestin de la configuracin es una disciplina cuya misin es controlar la
evolucin del sistema software [Jimenez05]. Los objetivos de las actividades de
gestin de la configuracin son establecer y mantener la integridad de los
productos generados durante un proyecto de desarrollo de software y a lo largo
de todo el ciclo de vida del producto.
Las actividades que se llevan a cabo en el presente trabajo para la gestin
de la configuracin son:
identificacin de la configuracin,
control de la configuracin,
generacin de informes de estado, y
auditoria de la configuracin.
7.7.1 IDENTIFICACIN DE LA CONFIGURACIN

Como primera medida, se establecen lneas bases funcional, de diseo, de
producto y operativa (tabla 7.9) con el fin de identificar los resultados de las
tareas realizadas durante las fases y asegurar que esta ltima se ha
completado.
114

Software
Lnea
Base
Funcional
Arquitect
ura
Elementos de
Configuracin
Procesos y actividades
incluidas en la
construccin del software
Planificacin temporal
Listas de verificacin de
aseguramiento de la
calidad
ltimo estado de la
configuracin
Identificacin de la
configuracin (lnea
base)
Diagrama de contexto
Diagrama entidadrelacin
Diagrama de casos de
uso
Catlogo de requisitos
Especificacin de
pantallas y reglas de
validacin
Modelo de navegacin
de pantallas
Especificacin de
requisitos del software
Perfiles y objetivos de los
distintos tipos de
pruebas
Enfoques y criterios de
seleccin de tipos de
pruebas
Requisitos del entorno
de pruebas
Tipos o niveles de error
Criterios y niveles de
aceptacin de los tipos
de prueba
Nivel 1 Subsistemas de
anlisis
Nivel 2 Subsistema de
ingreso de datos de la
aplicacin a medir
Ubicacin
Identificacin
en el Trabajo
en el Captulo
de Tesis
Tipo de
Elemento
Tabla 7.1
Captulo VII
Tabla
Tabla 7.8
Figura 7.1
Captulo VII
Captulo VII
Tabla
Figura
Tablas VI.1 a
VI.5
Anexo VI
Tablas
Tabla V.1
Anexo V
Tabla
Tabla 7.9
Captulo VII
Tabla
Figura 8.1
Captulo VIII
Diagrama
Figura 8.2
Captulo VIII
Diagrama
Figura 8.3
Captulo VIII
Diagrama
Tabla 8.6
Captulo VIII
Tabla
Tabla 8.7
Captulo VIII
Tabla
Figura 8.24
Captulo VIII
Diagrama
Tabla 8.8
Captulo VIII
Tabla
Tabla 8.9
Captulo VIII
Tabla
Tabla 8.10
Captulo VIII
Tabla
Tabla 8.11
Captulo VIII
Tabla
Tabla 8.12
Captulo VIII
Tabla
Tabla 8.13
Captulo VIII
Tabla
Figura B.III.1
Anexo III
Diagrama
Figura B.III.2
Anexo III
Diagrama
Tabla 7.9. Lnea base y distintos elementos de configuracin.

Software
115
Lnea Base
Arquitectura
Diseo
Elementos de
Configuracin
Nivel 2
Subsistema de
clculo de valores
de la medicin
Nivel 2
Subsistema de
mostrar resultados
de la medicin
Nivel 2
Subsistema de
actualizacin de
parmetros de
clculo
Descripcin de los
procesos
Diagrama de
entidades,
relaciones e
identificadores
normalizada (3FN)
Correspondencia
entre nombres de
entidades y tablas
de la base de
datos
Diagrama de
despliegue
Catlogo de
excepcin de
rango de valores
Catlogo de
excepcin de
ruptura de
integridad
referencial
Identificacin
en el Captulo
Ubicacin en
el Trabajo de
Tesis
Tipo de
Elemento
Figura B.III.3
Anexo III
Diagrama
Figura B.III.4
Anexo III
Diagrama
Figura B.III.5
Anexo III
Diagrama
III.C
Anexo III
Documento
Figura A.II.1
Anexo II
Diagrama
Tabla C.II.2
Anexo II
Tabla
Figura 9.1
Captulo IX
Diagrama
Tabla 9.1
Captulo IX
Tabla
Tabla 9.2
Captulo IX
Tabla
Tabla 7.9. Lnea base y distintos elementos de configuracin (continuacin).
116

Software
Lnea
Base
Elementos de
Configuracin
Diseo
Catlogo de excepcin de
texto no existente en lista
de valores
Diagrama de estructuras
Proceso de ingresar datos
del proyecto
Proceso de ingresar
descripciones de
Proceso de ingresar
entradas de transacciones
lgicas
Proceso de ingresar
salidas de transacciones
lgicas
Proceso de ingresar
conceptos de
Ingreso de caractersticas
de la aplicacin a medir
Realizar medicin del
tamao de la aplicacin
Consultas (resumen)
resultado de mediciones
Actualizacin de
parmetros de clculo
Actualizacin de valores
de caractersticas tcnicas
Mostrar parmetros de
clculo
Procedimientos
relacionados con medidas
de seguridad
Especificacin del entorno
tecnolgico para la
construccin
Ubicacin
Identificacin
en el
en el Captulo Trabajo de
Tesis
Tipo de
Elemento
Tabla 9.3
Captulo IX
Tabla
Figura 9.2
Captulo IX
Diagrama
Tabla 9.4
Captulo IX
Tabla
Tabla 9.5
Captulo IX
Tabla
Tabla 9.6
Captulo IX
Tabla
Tabla 9.7
Captulo IX
Tabla
Tabla 9.8
Captulo IX
Tabla
Tabla 9.9
Captulo IX
Tabla
Tabla 9.10
Captulo IX
Tabla
Tabla 9.11
Captulo IX
Tabla
Tabla 9.12
Captulo IX
Tabla
Tabla 9.13
Captulo IX
Tabla
Tabla 9.14
Captulo IX
Tabla
Tabla 9.15
Captulo IX
Tabla
Tabla 9.17
Captulo IX
Tabla
Tabla 9.18
Captulo IX
Tabla
Tabla 7.9. Lnea base y distintos elementos de configuracin (continuacin).

Software
117
Lnea
Base
Diseo
Producto
Operativa
Elementos de
Configuracin
Especificacin del
entorno tecnolgico para
las pruebas
Detalle de pruebas
unitarias
Distribucin y
ordenamiento lgico de
los mdulos
Especificacin de los
casos de prueba del
sistema
Documentacin del
cdigo de los
componentes de los
mdulos
Cdigo de los
componentes del
sistema de informacin
Resultados de la
ejecucin de las pruebas
unitarias
Resultado de la
de integracin
Resultado de la
del sistema
Manual del usuario
Software ejecutable
Identificacin
en el Captulo
Ubicacin en
el Trabajo de
Tesis
Tipo de
Elemento
Tabla 9.19
Captulo IX
Tabla
Tabla 9.20
Captulo IX
Tabla
Figura 9.7
Captulo IX
Grfico
Tabla 9.23
Captulo IX
Tabla
IV.A
Anexo IV
Documento
Programa
Tabla 10.1
Captulo X
Tabla
Tabla 10.2
Captulo X
Tabla
Tabla 10.3
Captulo X
Tabla
Anexo VII
Documento
Cdigo
Estimsbc.mdb
Tabla 7.9. Lnea base y distintos elementos de configuracin

(continuacin).
Todos los elementos de configuracin se almacenan en un directorio o
carpeta denominado tesis. Los documentos en un subdirectorio dentro de tesis
denominado documentos y los mdulos de estimsbc (incluidos en la base de
datos) en una carpeta o subdirectorio denominada estimsbcexe. Por ejemplo,
si el disco lgico es C, la distribucin quedara de la siguiente forma:
C:\tesis\documentos\capituloI.doc
C:\tesis\documentos\capituloII.doc
C:\tesis\documentos\capituloIII.doc
C:\tesis\documentos\capituloXIII.doc
C:\tesis\estimsbcexe\estimsbc.mdb.
118

Software
Con respecto a la versin, se codifica con dos valores numricos

separados cada uno de estos por un punto. Un nmero vlido (y a modo de
ejemplo) de versin puede ser: 4.3, donde cuatro indica cambios importantes y
el nmero tres los cambios menos significativos. Estos valores se irn
incrementando segn los cambios sufridos por los productos identificados.
En el Anexo V, se muestra una tabla que contiene los diferentes cdigos de
los elementos de configuracin identificados. El formato de dicha tabla se
muestra a continuacin:
Proyecto
Versin del
Lnea Base
Sistema
Elemento de Configuracin
Descripcin
Tipo
Nombre
Versin
Fecha
Directorio
Funcional
Diseo
Producto
Operativa
Varios
Tabla 7.10. Formato de planilla de versiones.

7.7.2 CONTROL DE LA CONFIGURACIN
Tiene como objetivo proporcionar un mecanismo de control de cambios. A
su vez, el proceso de control de cambios estar compuesto por las siguientes
etapas:
Iniciacin del cambio.

Clasificacin y registro de la solicitud de cambio.
Aprobacin o rechazo de la solicitud de cambio.
Generacin de una orden de cambio.
Realizacin del cambio.
Validacin del cambio.
El primer paso para llevar a cabo este proceso de control de cambios es la

creacin del comit de cambios, que estar formado por el ingeniero de
software autor del proyecto. Ser su responsabilidad la de tomar decisiones
acerca de la viabilidad y prioridad de las solicitudes de cambio, evaluar el
impacto sobre el resto de los elementos de configuracin y sobre los requisitos
del producto.

Software
119
Los tipos de cambios a considerar son:

i)
Informales: que se producen por parte de aquel que ha desarrollado

el elemento de configuracin. Son cambios justificados y que luego
pasan a formar parte de la lnea base.
ii)
Formales: cuando ya forman parte de una lnea base y necesitan del

comit de cambios para su aprobacin y posterior inclusin en la
lnea base.
La necesidad de cambio puede derivar de una incidencia o una solicitud

de cambio. Ya sea que deriven de una u otra, se deben registrar con el objeto
de llevar un control en las versiones de los productos. Para ello existen dos
elementos: uno es el registro de incidencias (tabla 7.11) y el registro de
cambios (tabla 7.12).
tem
Completado por
Identificacin del informe de incidencia

Sistema
Confeccionado por
Firma solicitante
Fecha de incidencia
Descripcin de incidencia
Tipo de incidencia (leve/seria/importante/crtica)
Resultado de la evaluacin (Desestimada/No desestimada)
Fecha de evaluacin
Identificacin de la solicitud de cambio asociada
Receptor/evaluador
Solicitante
Solicitante
Solicitante
Solicitante
Solicitante
Solicitante
Receptor/evaluador
Receptor/evaluador
Receptor/evaluador
Tabla 7.11. Registro de incidencias.

tem
Completado por
Identificacin de la solicitud
Sistema
Nombre del solicitante
Firma solicitante
Fecha de confeccin de la solicitud de cambio
Descripcin del requerimiento
Motivo del requerimiento
Observaciones
Documentacin de apoyo entregada
Fecha de recepcin de la solicitud
Identificacin del informe de evaluacin de cambio asociado
Identificacin del informe de incidencia asociado (si existe)
Receptor/evaluador
Solicitante
Solicitante
Solicitante
Solicitante
Solicitante
Solicitante
Solicitante
Solicitante
Receptor/evaluador
Receptor/evaluador
Receptor/evaluador
Tabla 7.12. Registro de solicitudes de cambio.

Cada registro de solicitud de cambio puede tener o no asociado un registro
de incidencias. Luego, es importante presentar un registro de evaluacin del
cambio (tabla 7.13).
120

Software
tem
Completado por
Identificacin del informe de cambio

Confeccionado por
Fecha de evaluacin
Elementos de configuracin afectados
Descripcin de la solicitud propuesta
Estimacin del tiempo de desarrollo por perfil
Observaciones
Resultado del anlisis de viabilidad (aprobado/denegado)
Fecha de anlisis de viabilidad
Identificacin de orden de cambio asociada (si corresponde)
Identificacin de solicitud de cambio asociada
Evaluador
Evaluador
Evaluador
Evaluador
Evaluador
Evaluador
Evaluador
Comit de control de cambios
Evaluador
Tabla 7.13. Registro de informes de cambios

Para cada informe de cambio debe existir una orden de cambio, cuyo
formato de registro se muestra en la tabla 7.14.
tem
Completado por
Identificacin de orden de cambio

Confeccionado por
Fecha de confeccin
Fecha estimada de implementacin/instalacin
Identificacin del informe de implementacin/instalacin
asociado
Identificacin del informe de evaluacin de cambio asociado

y Desarrollador
Desarrollador
Tabla 7.14. Registro de rdenes de cambios.

Por cada orden de cambio existe un informe implementacin/instalacin
sobre el cual se registran los tems presentados en la tabla 7.15.
tem
Completado por
Identificacin del informe de implementacin/instalacin

Confeccionado por
Fecha de confeccin
Elementos de configuracin modificados/afectados
Descripcin de la solicitud real
Responsables de la modificacin y perfil
Horas insumidas por perfil
Fecha de implementacin/instalacin
Versin del sistema generada
Identificacin de la orden de cambio asociada
Desarrollador
Desarrollador
Desarrollador
Desarrollador
Desarrollador
Desarrollador
Desarrollador
Desarrollador
Desarrollador
Desarrollador
Tabla 7.15. Registro de informe implementacin/instalacin.

Software
121
7.7.3 GENERACIN DE INFORMES DE ESTADO

Tambin denominada contabilidad de estado; su objetivo, es mantener
informado a gestores y desarrolladores acerca de los cambios ms
importantes.
Uno de los informes que se generan en esta actividad es el informe de
incidencias (tabla 7.16).
Identificacin
Fecha de
incidencia
Incidencias ESTIMSBC
Desde xx/xx/xx hasta xx/xx/xx
Tipo de
Descripcin
Estado
incidencia
Solicitud de Cambio
Asociada
Tabla 7.16. Formato de informe de incidencias.

Otro informe relacionado con los cambios en los elementos de
configuracin son los de solicitudes de cambio (tabla 7.17).
Solicitud de Cambio ESTIMSBC
Identificacin
Fecha de
Solicitud
Descripcin
Estado
Fecha de
Descripcin de la
implementacin/i
Solucin
nstalacin
Tabla 7.17. Formato de solicitud de cambio.

Por
ltimo
se
muestra
el
formato
del
registro
de
implementaciones/instalaciones cuyo propsito es mantener informacin
acerca de los lugares y las versiones del software instaladas (tabla 7.18).
122

Software
Implementaciones / Instalaciones ESTIMSBC

Identificacin
Fecha
Elementos de
configuracin
afectados/modificados
Descripcin de la
Solucin
Versin
Generada
Tabla 7.18. Formato de informe de implementaciones / instalaciones.

Por ltimo se genera el informe de estado de la configuracin con el
formato presentado en la tabla 7.19.
Proyecto
Versin del
Lnea Base
Sistema
Estado de Configuracin - Sistema ESTIMSBC

Al xx/xx/xx
Elemento de Configuracin
Descripcin
Tipo
Nombre
Versin
Fecha
Directorio
Funcional
Diseo
Producto
Operativa
Varios
Tabla 7.19. Formato de informe de estado de la configuracin.

El estado se refiere al que posee el tem al momento de emitir el reporte o
informe del estado de la configuracin. Ese estado puede ser implementado /
instalado, pendiente, desestimado o denegado.
7.7.4 AUDITORIA DE LA CONFIGURACIN
El o los responsable(s) de la auditoria debern tener una visin ntegra del
proyecto y no estar directamente involucrados. Se pueden hacer tres tipos de
auditoria: funcional, fsica y revisin formal de certificacin.

Software
123
En el primer caso, el objetivo es comprobar que se han completado todos

los test necesarios para el elemento de configuracin auditado y; que luego de
haber efectuado todos los test necesarios, ese elemento cumple con los
requisitos que se haban impuesto sobre l. El formato del informe de auditoria
funcional se muestra en la tabla 7.20.
Auditora Funcional
Sistema ESTIMSBC
Fecha xx/xx/xx
Responsable XXXXXXXXXXXX
Elemento de configuracin auditado
Resultado
Versin X.Y
Firma
Observaciones
Tabla 7.20. Formato de informe de auditoria funcional.

La auditoria fsica tiene como objetivo verificar la adecuacin, completitud y
precisin de la documentacin que constituye una lnea base. La tabla 7.21
muestra el formato del informe para este tipo de auditoria.
Auditora Fsica
Sistema ESTIMSBC
Fecha xx/xx/xx
Lnea Base de Auditora
Resultado
Versin X.Y
Firma
Observaciones
Tabla 7.21. Formato de informe de auditora fsica.

El ltimo informe que se puede generar para auditora es el de revisin
formal de certificaciones, cuyo objetivo es el de certificar que el elemento de
software se comporta correctamente en su entorno operativo (tabla 7.22).
124

Software
Certificacin
Sistema ESTIMSBC
Fecha xx/xx/xx
Elemento de Configuracin Auditado
Resultado
Versin X.Y
Firma
Observaciones
Tabla 7.22. Formato de informe de certificacin.

7.8 PLAN DE SISTEMAS DE INFORMACIN (PSI)
El Plan de Sistemas de Informacin tiene por objeto la obtencin de un
marco de referencia para el desarrollo de sistemas de informacin que
responda a los objetivos estratgicos de una organizacin.
En el caso particular del trabajo de tesis, se desarrollan las actividades con
el objetivo de crear un marco de referencia para el desarrollo del sistema
software para estimacin de proyectos de SSBBCC.
7.8.1 INICIO DEL PLAN DE SISTEMAS DE INFORMACIN (PSI 1)
Generalmente para el desarrollo de esta actividad, se toma como
disparador, las necesidades de las distintas reas de una organizacin de
llevar a cabo un PSI. Para el caso particular del desarrollo de la herramienta de
software, surge la necesidad de cumplir con un requisito curricular de culminar
la carrera de Maestra en Ingeniera del Software. Por este motivo, el inicio del
PSI est implcito y se da por aprobado. No existen objetivos estratgicos que
tengan que ver con una organizacin en particular, ms bien, responden a la
necesidad del autor de la tesis de finalizar el desarrollo en tiempo y forma.
7.8.2 DEFINICIN Y ORGANIZACIN DEL PLAN DE SISTEMAS DE
INFORMACIN (PSI 2)
En esta actividad se detalla el alcance del plan, se organiza el equipo de
personas que lo va a llevar a cabo y se elabora un calendario de ejecucin.
Una descripcin concreta del mbito se ha realizado en el captulo II; con
respecto al equipo de personas, este trabajo es unipersonal y lo realiza el autor
de la tesis. El o los usuario(s) son generalmente encargados de proyectos de
desarrollo de software de SSBBCC.

Software
125
7.8.3 ESTUDIO DE LA INFORMACIN RELEVANTE (PSI 3)

El objetivo de esta actividad es recopilar y analizar todos los antecedentes
generales que puedan afectar a los procesos y a las unidades organizativas
implicadas en el PSI, as como los resultados del mismo.
Los antecedentes necesarios y que son de inters para el desarrollo, se
han puesto de manifiesto ya sea en forma parcial o total en los captulos que
van del I al VI. En el captulo III, se explica lo que significa la estimacin y su
importancia dentro de un proceso de gestin de proyecto; en el captulo IV, se
desarrollan, analizan y estudian las tcnicas de estimacin. En el captulo V, se
hace lo propio con los SSBBCC, que son los que sern sometidos a las
mediciones para determinar su tamao aproximado. Por ltimo en el captulo
VI, se propone una tcnica de estimacin para SSBBCC, la cual deber estar
reflejada en un producto final alcanzado tras la finalizacin del desarrollo del
software.
7.8.4 IDENTIFICACIN DE REQUISITOS (PSI 4)
El objetivo de esta actividad es la de identificacin de requisitos de la
organizacin y la de obtener un modelo de informacin que los complemente.
Normalmente y en el marco de un PSI de una organizacin se estudian los
procesos que sern incluidos en dicho plan. Debido a las particularidades del
presente proyecto, las necesidades de informacin son las mencionadas en el
captulo II (punto 2.5). Adems existe un catlogo de requisitos que se ir
construyendo en la fase de Diseo del Sistema de Informacin (DSI).
7.8.5 ESTUDIO DE LOS SISTEMAS DE INFORMACIN ACTUALES (PSI 5)
Debido a la particularidad del proyecto, no existe una organizacin que
demande la construccin de un sistema software; por ende, no existe sistema
de informacin actual. En este caso se arranca de cero.
7.8.6 DISEO DEL MODELO DE SISTEMAS DE INFORMACIN (PSI 6)
Al igual que el punto anterior, se expresa que no existe un sistema de
informacin del cual se parte para el desarrollo del presente. Esta actividad se
realiza tomando en consideracin los sistemas de informacin actuales y se
definen los nuevos, que cubrirn los requisitos que se expondrn e irn
completando en el catlogo de requisitos.
En el captulo VIII, se definen los modelos que describen la solucin a
adoptar.
126

Software
7.8.7 DEFINICIN DE LA ARQUITECTURA TECNOLGICA (PSI 7)

En esta actividad se propone una arquitectura tecnolgica que da soporte
al modelo de informacin. Si bien es cierto es necesario considerar el catlogo
completo de requisitos, solamente se tienen en cuenta los requisitos
tecnolgicos.
En un principio, se considera la necesidad de infraestructura tecnolgica.
Esto involucra servicios, conectividad, comunicaciones, criticidad, etc.
A priori y sin entrar a realizar un anlisis exhaustivo, se puede decir que la
herramienta funcionara en un entorno monousuario, sin mayores exigencias.
De hecho, el tiempo de respuesta deber ser importante, ya que se espera que
el usuario o encargado de proyecto interacte con la mayor fluidez posible.
Esto significa que debe ingresar los datos y obtener respuestas del sistema en
fraccin de segundo.
7.8.8 DEFINICIN DEL PLAN DE ACCIN (PSI 8)
En el Plan de Accin que se elabora, se definen los proyectos y las
acciones a llevar a cabo para la implantacin de los sistemas de informacin.
Debido a que el desarrollo del sistema software de este trabajo de tesis no se
encuentra enmarcado en ningn plan estratgico, esta actividad se reduce
solamente a definir la realizacin del desarrollo del sistema software para la
medicin del tamao en SSBBCC.
7.8.9 REVISIN Y APROBACIN DEL PSI (PSI 9)
Una vez identificados necesidades de informacin, requisitos, tecnologa y
solucin a implementar, resulta necesario aprobar el PSI.
7.9 ESTUDIO DE LA VIABILIDAD DEL SISTEMA (EVS)
El objetivo de esta fase es analizar un conjunto concreto de necesidades
para proponer una solucin a corto plazo, que tenga en cuenta las restricciones
econmicas, tcnicas, legales y operativas. La solucin obtenida como
resultado puede ser la definicin de uno o varios proyectos que afecten a uno o
varios sistemas de informacin ya existentes o nuevos. Para ello se identifican
los requisitos que se han de satisfacer y; si procede, se estudia la situacin
actual.
De acuerdo a los conceptos que se exhiben en la teora de mtrica V3, esta
fase se realiza a continuacin de PSI. La solucin que implique la realizacin
de uno o varios proyectos est relacionada tambin con la particularidad de
que este se trata de un trabajo acadmico; es por ello, que el desarrollo de esta
fase no realiza tarea por tarea sino ms bien involucrando a todas las que
perteneces a esta actividad
Software
127
7.9.1 ESTABLECIMIENTO
INFORMACIN (EVS 1)
DEL
ALCANCE
DEL
SISTEMA
DE
En esta actividad se estudia el alcance de la necesidad planteada por el

usuario, o como consecuencia de la realizacin de un PSI, realizando una
descripcin general de la misma.
En el captulo II, punto 2.5, se describen los estudios que se realizan
previos a la construccin de la herramienta de software. Adems, se ha
propuesto una representacin grfica (figura 2.1) de las entradas y las salidas
del sistema y de los procesos intermedios entre el requerimiento de informacin
del usuario y los resultados arrojados por el software.
7.9.2 ESTUDIO DE LA SITUACIN ACTUAL (EVS 2)
La situacin actual es el estado en que se encuentran los sistemas de
informacin existentes en el momento en que se inicia su estudio. Se realiza
una valoracin de la informacin existente acerca de los sistemas de
informacin afectados. En funcin de dicha valoracin se especifica el nivel de
detalle con que se debe llevar a cabo el estudio.
Teniendo en cuenta el estado de la tecnologa al momento de escribir el
trabajo de tesis, se puede asegurar la existencia de tcnicas que aplicadas a
las fases iniciales del proyecto, determinan (con un alto porcentaje de certeza)
el tamao aproximado del producto software a desarrollar. En el captulo IV se
ha hecho referencia a que ninguna tcnica puede ser aplicada directamente a
SSBBCC (puntos 4.3 y 4.4). Para el sistema que se construye, se aplican
conceptos de algunas de ellas. En el captulo VI, se han exhibido las
adecuaciones correspondientes para lograr estimaciones en este tipo de
desarrollos.
7.9.3 DEFINICIN DE REQUISITOS DEL SISTEMA (EVS 3)
En esta actividad se incluye la determinacin de los requisitos del sistema
mediante una serie de sesiones de trabajo con los usuarios participantes que
hay que planificar y realizar. Una vez finalizadas se analiza la informacin
obtenida definiendo los requisitos y sus prioridades, que se aaden al catlogo
de requisitos.
En el captulo VIII, se ir construyendo y completando un catlogo de
requisitos, luego, se mostrar un catlogo completo que resume todas las
instancias en las que se agregarn distintos aspectos del mismo.
7.9.4 ESTUDIO DE ALTERNATIVAS DE SOLUCIN (EVS 4)
Este estudio se centra en proponer alternativas que respondan
satisfactoriamente a los requisitos planteados considerando tambin los
128

Software
resultados obtenidos en el Estudio de la Situacin Actual (EVS 2), en el caso

de que se haya realizado.
Teniendo en cuanta el mbito y la funcionalidad que debe cubrir el sistema,
puede ser conveniente realizar previamente a la definicin de cada alternativa
una descomposicin del sistema en subsistemas.
Habiendo analizado las diferentes tcnicas de estimacin y luego de
comprobar que ninguna de ellas puede ser aplicada directamente a desarrollos
que incluyan a SSBBCC, se puede decir que la solucin que se propone es la
construccin de un sistema de informacin que permita realizar los clculos
correspondientes en desarrollos que incluyan a este tipo de sistemas.
7.9.5 VALORACIN DE LAS ALTERNATIVAS (EVS 5)
Una vez descritas las alternativas se realiza una valoracin en funcin del
impacto que producen en la organizacin. Como en este caso particular se
trata de un trabajo de tesis, no existe impacto alguno.
7.9.6 SELECCIN DE LA SOLUCIN (EVS 6)
Antes de finalizar el estudio de viabilidad se convoca al Comit de
Direccin para la presentacin de distintas alternativas de solucin resultantes
de la actividad anterior. En dicha presentacin se debaten las ventajas de cada
una de ellas, incorporando modificaciones que se consideren oportunas con el
fin de seleccionar la ms adecuada. Finalmente se aprueba la solucin o se
determina su inviabilidad.
7.10 ASEGURAMIENTO DE LA CALIDAD (CAL)
El objetivo de la interfaz de Aseguramiento de la Calidad en Mtrica
Versin 3 es proporcionar un marco comn de referencia para la definicin y
puesta en marcha de planes especficos de aseguramiento de la calidad
aplicables a proyectos concretos.
Las actividades propias de la interfaz de Calidad en MTRICA Versin 3
estn orientadas a verificar la calidad de los productos. Son actividades que
evalan la calidad y que son realizadas por un grupo de Aseguramiento de la
Calidad independiente de los responsables de la obtencin de los mismos.
Las actividades relativas a la Calidad Intrnseca del Producto son propias
de los Procesos principales de MTRICA Versin 3, y no del Proceso de
Interfaz de Calidad.
Para asegurar la calidad de los productos resultantes el equipo de calidad
deber realizar un conjunto de actividades que sirvan para reducir, eliminar y, o
prevenir la deficiencia en la calidad de los productos a construir. Adems,
Software
129
deber alcanzar una razonable confianza en que las prestaciones y servicios

esperados por el cliente o usuario queden satisfechas.
La calidad del software debe ser controlada desde el comienzo del
proyecto y verificarse a lo largo de las fases del mismo. En tal sentido se
propone como mtodo de control por un lado los siguientes:
revisiones, que consiste en el control de las distintas versiones que se
van obteniendo de los productos, y que tras cumplir con las condiciones
de calidad establecidas pasan a formar una lnea base;
pruebas de software, que se realizan con el objeto de detectar errores
para luego aplicar las medidas correctivas.
En los puntos siguientes, se identifican las propiedades de calidad y las
tareas a realizar en el proceso de aseguramiento de la calidad. En el anexo
VI, se exhiben una serie de formularios en los que se valida las
especificaciones presentadas en los puntos 7.10.1 a 7.10.5.
7.10.1 IDENTIFICACIN DE LAS PROPIEDADES DE CALIDAD DEL
SISTEMA (EVS-CAL 1)
Entre las propiedades de calidad del sistema ESTIMSBC, se encuentran
las siguientes:
correccin: el sistema debe cumplir con las especificaciones de los
requisitos y satisfacer los objetivos de los usuarios,
facilidad de uso: el sistema debe ser fcilmente operable por el
usuario,
fiabilidad: el sistema debe funcionar correctamente y estar libre de
errores,
integridad: el sistema debe impedir el acceso a usuarios que no tengan
un nombre de usuario y contrasea vlidos,
facilidad de mantenimiento: el costo de localizar y corregir errores debe
ser bajo.
7.10.2 REVISIN DEL ANLISIS DE CONSISTENCIA (ASI-CAL 3)
En el proceso de Anlisis del Sistema de Informacin (ASI), el grupo de
aseguramiento de la calidad se ocupa de la revisin de los siguientes
productos:
catlogo de requisitos,
modelos de anlisis y
plan de pruebas.
7.10.2.1 REVISIN DEL CATLOGO DE REQUISITOS (ASI-CAL 3.1)
Se verifica que los requisitos sean precisos y completos. La lista de
verificacin donde se exhiben los controles, se muestra en el anexo VI. Entre
otros aspectos, debe figurar en la lista los siguientes tems:
130

Software
Los requisitos son claros?

Los requisitos son contradictorios?
Los requisitos son imposibles de probar?
Los requisitos son relevantes?
Son importantes para la solucin del problema?
Son testeables por un grupo independiente?
Cumplen con los objetivos principales del sistema?
7.10.2.2 REVISIN DE LA CONSISTENCIA ENTRE PRODUCTOS (ASI-CAL

3.2)
Se revisa que se haya realizado la verificacin y validacin de los productos
resultantes del anlisis, as como la trazabilidad de los requisitos. La lista de
verificacin deber constar de los siguientes tems:
Todos los casos de uso tienen su correspondiente diagrama de
anlisis?
Cada clase de anlisis tiene su correspondiente descripcin?
Todos los requisitos funcionales tienen su correspondiente caso de
uso, diagrama de anlisis y descripcin?
7.10.3 REVISIN DE LA ARQUITECTURA DEL SISTEMA (DSI-CAL 1)
Las revisiones del diseo se centran en confirmar que los requisitos
especificados en el proceso de anlisis se han traducido en una arquitectura
conforme al entorno tecnolgico.
7.10.3.1 REVISIN DE LA CONSISTENCIA ENTRE PRODUCTOS DEL

DISEO (DSI-CAL 1.1)
Se comprueba que el diseo de la arquitectura del sistema responda a los
requisitos especificados en el sistema. Esta tarea se efecta mediante la lista
de comprobacin que aparece en el anexo VI y que contiene los siguientes
tems:
Todos los casos de uso tienen su correspondiente diagrama de clases
de anlisis y de diseo?
Cada clase de diseo tiene su correspondiente descripcin?
uso, diagrama de diseo y descripcin?
7.10.4 REVISIN DE LAS PRUEBAS UNITARIAS, DE INTEGRACIN Y DEL
SISTEMA (CSI-CAL 2)
Las verificaciones que se realizan en el marco de esta actividad, estn
orientadas a responder las siguientes cuestiones:
Se prueba cada requisito?
Software
131
Se prueba cada elemento de diseo?

Se realiza una prueba de interfaz entre mdulos?
Los casos de prueba testean todos los procesos?
7.10.5 REVISIN DE LAS PRUEBAS DE ACEPTACIN DEL SISTEMA (IASCAL 3)

La lista de verificacin para esta actividad debe responder a los siguientes
cuestionamientos:
Se confecciona una tabla de derivacin de los casos de prueba?
132

Software
CAPTULO VIII
ANLISIS
DEL
SISTEMA
DE
INFORMACIN
(ASI)
CAPTULO VIII
ANLISIS DEL SISTEMA DE INFORMACIN (ASI)
8.1 INTRODUCCIN
En este captulo se desarrollan las actividades de anlisis del sistema de
informacin (ASI). Su objetivo es obtener una especificacin detallada del
sistema de informacin que sirva tanto a usuarios como a posteriores etapas
(diseo, codificacin, etc.) del desarrollo de software.
8.2 DEFINICIN DEL SISTEMA (ASI1)
El objetivo de esta actividad es realizar una descripcin del sistema,
delimitando su alcance, estableciendo las interfaces con otros sistemas e
identificando a los usuarios representativos. Sus tareas se desarrollan a
continuacin.
8.2.1 DETERMINACIN DEL ALCANCE DEL SISTEMA (ASI 1.1)
Esta tarea tiene como objetivo delimitar al sistema de informacin utilizando
como punto de partida el modelo de procesos. En el captulo II (figura 2.1) se
ha realizado una representacin grfica del proceso que se sigue para el
clculo de puntos de funcin, aplicacin del factor de ajuste y su transformacin
a lneas de cdigo y valores de estimacin de tiempo, costo y esfuerzo para
Sistemas Basados en Conocimientos (SSBBCC).
Se indica tambin en esta actividad qu procesos pertenecen al mbito del
sistema de informacin, cuales quedan excluidos y se identifican entidades
externas que envan o reciben informacin hacia o desde el sistema. Se
obtiene un modelo conceptual de datos identificando las entidades y las
relaciones que forman parte del sistema de informacin que es objeto de
anlisis.
Uno de los productos que se obtiene en esta fase es el catlogo de
requisitos, que se ir enriqueciendo a medida que se agregue informacin en
el desarrollo de las actividades propias de la fase.
A continuacin se exhibe en la figura 8.1 el diagrama de contexto (nivel 0)
de la aplicacin a desarrollar.
Captulo VIII Anlisis del

Sistema de Informacin (ASI)
135
Usuario
Encargado de
Proyecto
Informacin
del Proyecto
a Desarrollar
Nivel 0
Resultados de
la Medicin
ESTIMSBC
Usuario
Encargado de
Proyecto
Figura 8.1. Diagrama de flujo de datos nivel 0 contexto.

En esta tarea, se construye adems, un modelo conceptual de datos
identificando las entidades y las relaciones que forman parte del modelo
sistema de informacin, objeto de anlisis. Para representar las entidades y
sus relaciones, se muestra a continuacin el modelo entidad-relacin (figura
8.2).
Mediciones
1
N
Transacciones
Lgicas
1
N
Entradas de
Transacciones
Lgicas
1
Tipos de
Elementos de
Entrada
1
N
Salidas de
Transacciones
Lgicas
N
Conceptos de
Transacciones
Lgicas
1
Tipos de
Elementos de
Salida
Figura 8.2. Modelo conceptual de datos: diagrama (o modelo) entidad-relacin.

La descripcin de las relaciones entre entidades, se puede definir de la
siguiente forma:
Una medicin puede tener una o varias transacciones lgicas.
Una transaccin lgica puede tener una o varias entradas.
Una transaccin lgica puede tener una o varias salidas.
Una transaccin lgica puede tener uno o varios conceptos.
Un tipo de elemento de entrada puede encontrarse en una o varias
entradas.
136

Un tipo de elemento de salida puede encontrarse en una o varias

salidas.
8.2.2 IDENTIFICACIN DEL ENTORNO TECNOLGICO (ASI 1.2)

En esta actividad se define el entorno tecnolgico que se requiere para dar
respuestas a las necesidades de informacin, especificando condiciones y
restricciones. Como resultado de esta tarea el catlogo de requisitos se ve
actualizando con nuevas caractersticas.
Como se trata de una aplicacin para ser tratada en un mbito acadmico,
no existe presupuesto asignado para adquirir herramientas de desarrollo ni
equipamiento hardware que debera tener una aplicacin para empresas u
otras organizaciones dedicadas a la comercializacin y, o venta de productos y,
o servicios. Las restricciones son inherentes al sistema informtico con que
cuenta el autor para acometer el desarrollo del producto software. Es por ello,
que los requerimientos de hardware y software sern enumerados en funcin
de la disponibilidad de dicho equipamiento.
La tabla 8.1 muestra un catlogo de requisitos de operacin definido para
el presente proyecto de desarrollo.
N de Req.
ROP01
ROP02
ROP03
ROP04
Descripcin del Requerimiento

Volatilidad
El sistema se desarrolla en una
plataforma con software adquirido como
Baja
parte del sistema informtico (propiedad
del autor)
El sistema operativo es Windows XP
Baja
Profesional
EL entorno de desarrollo es Access 2002
y el front end son herramientas de
Access para construccin de formularios,
reportes, tablas y consultas.
El hardware est compuesto por una PC
con 256 Mb. RAM, HD 40 Gb.,
lectograbadora de CD, pantalla, teclado y
mouse
Necesidad
Prioridad
Alta
Alta
Baja
Alta
Baja
Alta
Tabla 8.1. Catlogo de requisitos de operacin.

8.2.3 ESPECIFICACIN DE ESTNDARES Y NORMAS (ASI 1.3)
La realizacin de esta tarea permite considerar las referencias para el
sistema de informacin en estudio, desde el punto de vista de estndares,
leyes o recomendaciones que se deben tener en cuenta a lo largo del
desarrollo. Para el caso particular de este trabajo se utiliza como metodologa
de desarrollo mtrica V3.

137
8.2.4 IDENTIFICACIN DE USUARIOS PARTICIPANTES Y FINALES (ASI

1.4)
En esta tarea se identifican los usuarios participantes y finales. Para esta
aplicacin en particular, y al servir para los fines de demostrar un estudio
terico, todas las validaciones y aceptaciones estn orientadas a reflejar las
teoras propuestas en el captulo VI del presente trabajo. Este desarrollo est
orientado a un usuario con un perfil definido. Este perfil al que se hace
referencia es un encargado de proyecto de un desarrollo de un sistema
software que incluya a SSBBCC. Para las pruebas, verificaciones y
validaciones, se considerar como usuario final, al autor del proyecto quin
estar a cargo de llevar a cabo las pruebas correspondientes del sistema
software y de los modelos generados a travs de las distintas etapas del
desarrollo.
8.3 ESTABLECIMIENTO DE REQUISITOS (ASI 2)
El objetivo de esta actividad es obtener un catlogo detallado de requisitos
que completa al obtenido en la actividad anterior (ASI 1.2). Para ello se lleva a
cabo la definicin, anlisis y validacin de requisitos a partir de la informacin
proporcionada por el usuario.
Esta actividad se descompone en un conjunto de tareas que si bien es
cierto tienen un determinado orden, exigen solapamientos y realimentacin con
otras tareas realizadas en paralelo.
Una tcnica que si bien es cierto es para desarrollos orientados a objetos,
pero que se la puede aplicar en desarrollos estructurados en la de obtencin de
casos de usos (mediante el diagrama de casos de uso).
8.3.1 OBTENCIN DE REQUISITOS (ASI 2.1)
En esta tarea comienza la obtencin de informacin de los usuarios
identificados en la tarea ASI 1.4. Se recoge informacin de los requisitos que
debe cumplir el software. En la definicin de los requisitos, que sirven de base
para establecer los niveles del sistema, hay que tener en cuenta si existen las
posibles restricciones del entorno tanto en hardware como en software que
puedan afectar al sistema de informacin. Tambin se definen las prioridades
que hay que asignar a los requisitos, considerando los criterios de los usuarios
acerca de las funcionalidades a cubrir.
Los principales tipos de requisitos que se deben especificar son:
138
Funcionales
Rendimiento
Seguridad
Implantacin

Disponibilidad del sistema.
Mediante el diagrama de casos de usos de la figura 8.3, se pueden

capturar los requisitos funcionales del sistema y expresarlos desde el punto de
vista del usuario.
Consultar
Resultados de
Mediciones
Usuario Encargado
del Proyecto
Ingr Valores
de la Apl. A
Medir
Realizar
Mediciones
Usuario Encargado
del Proyecto
Listar Proy./
Result. De
Mediciones
Actualizar
Parmetros de
Clculo
Figura 8.3. Diagrama de casos de usos.

En el diagrama de la figura 8.3, se identifica como actor del caso de uso, al
encargado del proyecto quin demanda informacin para la gestin y
planificacin del proyecto de desarrollo de software a su cargo. Este tambin le
proporciona al sistema los datos necesarios para realizar dichas mediciones.
Los casos de uso que definen la funcionalidad que el sistema debe brindar
se muestran a continuacin:
i)
Ingresar Valores de la Aplicacin a Medir: el sistema deber permitir

ingresar los datos que identifican y diferencian a un proyecto de otro.
Adems debe permitir el ingreso de:
transacciones lgicas,
entradas, salidas y conceptos que componen cada
transaccin lgica,
valores de las caractersticas tcnicas de la aplicacin.
ii)
Realizar Mediciones: el sistema debe permitir realizar los clculos

previstos para obtener las estimaciones de tamao, costo, tiempo y
esfuerzo.
iii)
Consultar Resultados de las Mediciones: el sistema debe permitir

visualizar o mostrar tanto en resumen como en detalle los resultados
de las mediciones arrojadas en los diferentes proyectos cargados en
el sistema.
Listar Datos de Proyectos y Resultados de Mediciones: el sistema
debe permitir hacer un reporte de los datos de los proyectos que ya
hayan sido registrados. Adems se debe poder listar o imprimir un
reporte de cada proyecto con los resultados arrojados por las
mediciones.
iv)

139
v)
Actualizar Parmetros de Clculo: el sistema debe permitir actualizar

los parmetros que se aplican a los clculos. Por ejemplo valores de
coeficientes de ajustes de complejidad tcnica, coeficiente de ajuste
lgico (CAL), etc. Adems debe permitir actualizar y realizar
consultas de los valores de ajuste de complejidad tcnica y de las
caractersticas de la aplicacin.
A continuacin se definen los requisitos funcionales, de rendimiento, de

seguridad, de implantacin y disponibilidad del sistema que se irn agregando
a los exhibidos en la tabla 8.1. Primero se definen los requisitos funcionales
(tabla 8.2).
N de Req.
RF01
RF02
RF03
RF04
RF05
Volatilidad
Ingresar valores de la aplicacin a

medir
Realizar mediciones
Consultar resultados de las
mediciones
Listar
resultados
de
las
mediciones
Necesidad
Prioridad
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Tabla 8.2. Requisitos funcionales.

Adems de los requisitos funcionales se pueden definir los requisitos nofuncionales relacionados con la aplicacin. En la tabla 8.3, se muestran los
requisitos de cumplimientos de normas y estndares.
N de Req.
Volatilidad
Necesidad
Prioridad
El sistema debe ser desarrollado

RNF01
siguiendo
pasos
de
los
la
lineamientos
metodologa
y
de
Baja
Alta
desarrollo mtrica V3.
Tabla 8.3. Requisito no funcional de cumplimiento de normas y estndares.

Los requerimientos no funcionales de backup, contingencia y recuperacin
de errores se muestran en la tabla 8.4.
N de Req.
RNFB01
Los
datos
deben
estar
centralizados para facilitar el backup (o copias de seguridad) y la
restauracin del sistema
Volatilidad
Baja
Necesidad
Alta
Prioridad
Tabla 8.4. Requisito no funcional de back-up, contingencias y recuperacin

de errores.
140

Por ltimo, se muestran los requerimientos de rendimiento en la tabla 8.5.

N de Req.
RNFR01
En
todos
los
casos
la
recuperacin de la informacin
deber hacerse en menos de tres
segundos
Volatilidad
Baja
Necesidad
Alta
Prioridad
Tabla 8.5. Requisito no funcional de rendimiento.

8.3.2 ESPECIFICACIN DE CASOS DE USO (ASI 2.2)
El objetivo de esta tarea es especificar cada caso de uso identificado en la

tarea anterior. Para cada caso de uso se especifica los siguientes elementos:
descripcin, precondiciones, poscondiciones y excepciones.
A continuacin se detallan los diferentes casos de uso:
i) Caso de Uso 1: Ingreso de Valores de la Aplicacin a Medir (CU01):
Descripcin: debido a que la aplicacin a medir se encuentra incluida en un
proyecto de desarrollo, primero se deberan ingresar los datos del proyecto:
nmero de medicin, nombre de proyecto, fecha de medicin, nombre de
aplicacin a medir y autor. Una vez que se han ingresado estos datos, el
sistema debe permitir incorporar la cantidad de transacciones lgicas
identificadas. Una transaccin lgica est conformada por entradas y, o
salidas y, o conceptos. Una vez que se han identificado estos elementos,
se les deber dar el alta. Luego, el sistema los debe agrupar por separado
y contabilizar a fin de obtener la cantidad exacta de entradas, salidas y
conceptos. Adems; el sistema debe permitir el ingreso de los valores que
representan las caractersticas tcnicas de la aplicacin a medir.
Precondiciones: el usuario debe identificar las transacciones lgicas,
entradas, salidas y conceptos, e incorporarlas al sistema; ya que sin estar
satisfecha esta condicin, no es posible realizar el clculo y posterior
estimacin. De igual forma se debe contar con los valores de las
caractersticas tcnicas de la aplicacin a medir.
Poscondiciones: una vez ingresados los valores de la aplicacin, es posible
realizar el clculo y la estimacin de esfuerzo costo y tiempo.
Excepciones: pueden haber situaciones anmalas que interrumpan el
normal desenvolvimiento de la transaccin. Las situaciones anmalas o no
previstas en este caso de uso estn relacionadas con el ingreso de valores
que se encuentran fuera de los lmites previstos y que pueden arrojar
resultados inesperados. En cada caso en particular, el sistema muestra un
mensaje de error al usuario, describiendo la situacin no prevista.

141
Identificacin de Interfaces del Usuario: a continuacin se presentan seis

pantallas que conforman la interfaz del usuario para el ingreso de valores
de la aplicacin a medir.
Ingreso (ABM) de Datos del Proyecto: la figura 8.4 muestra un diseo de
pantalla para el ingreso y, o actualizacin de datos generales del proyecto.
Figura 8.4. Pantalla de ingreso de datos del proyecto.

ABM de Transacciones Lgicas: la figura 8.5 muestra un diseo de pantalla
para el ingreso y, o actualizacin de transacciones lgicas.
Figura 8.5. Pantalla de ABM de transacciones lgicas.
142

Registro de Entradas (ABM) de Transacciones Lgicas: las transacciones

lgicas pueden estar conformadas por entradas, salidas y, o conceptos. El
diseo de pantalla de la figura 8.6 muestra como el sistema debe permitir
que se ingresen y, o actualicen los elementos de entradas.
Figura 8.6. Pantalla de registro de entradas de transacciones lgicas.

Registro de Salidas (ABM) de Transacciones Lgicas: este diseo de
pantalla (figura 8.7) muestra como se ingresan y, o actualizan las salidas
de las transacciones lgicas.
Figura 8.7. Pantalla de registro de salidas de transacciones lgicas.

143
Registro de Conceptos (ABM) de Transacciones Lgicas: al igual que los

dos diseos anteriores, este (figura 8.8) muestra como se pueden ingresar
y, o actualizar los conceptos de las transacciones lgicas.
Figura 8.8. Pantalla de registro de conceptos de transacciones lgicas.

Ingreso de Caractersticas Tcnicas de la Aplicacin: en este diseo de
pantalla (figura 8.9) se exhibe como es el ingreso de caractersticas
tcnicas de la aplicacin a medir.
Figura 8.9. Pantalla de ingreso de caractersticas tcnicas de la aplicacin

a medir.
144

ii) Caso de Uso 2: Realizar Mediciones (CU02):

Descripcin: el sistema debe permitir el clculo del tamao aproximado de
la aplicacin a medir, su ajuste de complejidad tcnica y; basado en los
valores de los parmetros tcnicos, realizar las estimaciones de
productividad, costo, tiempo y esfuerzo.
Precondiciones: para poder realizar el clculo de los puntos de funcin, el
sistema debe contar con el valor de la cantidad de entradas, salidas y
conceptos. Estos valores se deben incorporar al sistema antes de realizar
este clculo (CU01). Para el caso del ajuste de complejidad tcnica (ACT),
si no se ingresa ningn valor, toma por defecto el valor nominal para cada
una de las caractersticas tcnicas (valor nominal igual a uno).
Poscondiciones: quedan almacenados en la base de datos los resultados
de los clculos y los valores de las estimaciones.
Excepciones: no se identifican excepciones para este caso de uso.
Identificacin de Interfaces del Usuario: los clculos de valores de puntos
de funcin, puntos de funcin ajustados y los estimadores, se debe realizar
como un evento; es decir, el usuario debe apretar un botn y el sistema
debe realizar todos los clculos. El botn que dispara este proceso se
encuentra en la pantalla de la figura 8.9. A continuacin se presenta un
diseo de pantalla (figura 8.10) para mostrar los resultados de ese clculo.
Figura 8.10. Pantalla de resultados de la medicin.

145
iii) Caso de Uso 3: Consultar Resultados de Mediciones (CU03):

Descripcin: para este caso de uso, el sistema debe permitir realizar
distintas consultas de los resultados arrojados por las mediciones. En un
principio, se debern poder emitir por pantalla una consulta en columnas de
los valores de dichos resultados. Adems deber haber otra consulta en
detalle de los valores de entrada y los resultados (o salidas) que estos
generan.
Precondiciones: los valores de los resultados deben estar almacenados en
la base de datos previamente para poder consultarlos.
Excepciones: si no hubieran datos almacenados, el sistema emite un
mensaje de error comunicando esta situacin al usuario.
Identificacin de las Interfaces del Usuario: a continuacin se muestran dos
diseos de pantalla que reflejan los requisitos del caso de uso CU03.
Resumen de Resultados de Mediciones: el diseo de pantalla de la figura
8.11, muestra un resumen de los resultados de mediciones efectuadas.
Figura 8.11. Pantalla de resumen de los resultados de las mediciones.
146

Detalle de los Resultados de las Mediciones: el diseo de pantalla de la

figura 8.12, muestra un detalle de los resultados de mediciones efectuadas.
Figura 8.12. Pantalla de detalle de resultados de las mediciones.

iv) Caso de Uso 4: Listar Proyectos / Resultados de las Mediciones (CU04):
Descripcin: el sistema debe permitir hacer listado de la cartera de
proyectos y de los resultados de las mediciones hechas.
Precondiciones: las precondiciones son idnticas a las de las consultas de
las mediciones.
Excepciones: si no hubieran datos almacenados, el sistema emite un
mensaje de error comunicando esta situacin al usuario.
v) Caso de Uso 5: Actualizar Parmetros de Clculo (CU05):
Descripcin: el sistema debe permitir actualizar o ajustar los parmetros de
clculo. Entre estos estn los valores de los coeficientes de actualizacin
lgica (CAL), el coeficiente de ajuste de complejidad tcnica y el coeficiente
de variacin de ajuste de complejidad tcnica. Con respecto a los valores
estimados, se especifican la cantidad de horas semanales de trabajo y el
costo de la hora de trabajo.
Precondiciones: el usuario debe contar con los datos que le sirven a la
aplicacin como parmetros de clculo.
Excepciones: no se identifican

147
Identificacin de las Interfaces del Usuario: a continuacin se muestran las

pantallas que reflejan los requisitos del caso de uso CU05.
Pantalla de Actualizacin de Parmetros: esta pantalla (figura 8.13) permite
el ingreso de los parmetros de clculo de indicadores y de puntos de
funcin de la aplicacin que se quiere medir.
Figura 8.13. Pantalla de actualizacin de parmetros de clculo.

Factores De Ajuste De Complejidad Tcnica: el diseo de la pantalla de la
figura 8.14 muestra una consulta para factores de ajuste de complejidad
tcnica.
Figura 8.14. Pantalla de consulta de factores de ajuste de complejidad

tcnica.
148

ABM de Caractersticas Tcnicas de la Aplicacin: este tipo de pantalla,

permite la actualizacin (alta, baja y, o modificacin) de las caractersticas
tcnicas de la aplicacin a medir.
Figura 8.15. Pantalla de ABM de caractersticas tcnicas de la aplicacin.

Consulta de Valores de Ajuste de Complejidad Tcnica: la pantalla de la figura
8.16, permite consultar los valores de ajuste de complejidad tcnica de cada
una de las caractersticas de la aplicacin.
Figura 8.16. Pantalla de consulta de ajustes de complejidad tcnica.

8.3.3 ANLISIS DE REQUISITOS (ASI 2.3)
En esta etapa se analiza la informacin recopilada previamente con el

objeto de detectar ambigedades, inconsistencias y, o falta de informacin. Se
analizan adems, las prioridades establecidas por el usuario y se asocian los
requisitos relacionados entre s. En un principio, no se han detectado
ambigedades o inconsistencias en la informacin.

149
8.3.4 VALIDACIN DE REQUISITOS (ASI 2.4)
En esta tarea los usuarios confirman los requisitos especificados en el

catlogo de requisitos, adems se verifica los casos de uso con el objeto de
detectar validez, completitud y consistencia. En la tabla 8.6 se muestra el
catlogo completo de requisitos.
N de Req.
ROP01
ROP02
ROP03
ROP04
RF01
RF02
RF03
RF04
RF05
RNF01
RNFB01
RNFR01

Volatilidad
El sistema se desarrolla en una
plataforma con software adquirido como
Baja
parte del sistema informtico (propiedad
del autor)
El sistema operativo es Windows XP
Baja
Profesional
EL entorno de desarrollo es Access 2002
y el front end son herramientas de Access
para construccin de formularios,
reportes, tablas y consultas.
El hardware est compuesto por una PC
con 256 Mb. RAM, HD 40 Gb.,
lectograbadora de CD, pantalla, teclado y
mouse
Ingresar valores de la aplicacin a

medir
Realizar mediciones
Consultar resultados de las
mediciones
Listar
resultados
de
las
mediciones
El sistema debe ser desarrollado
siguiendo
pasos
de
los
la
lineamientos
metodologa
y
de
desarrollo mtrica V3.

Los
datos
deben
estar
centralizados para facilitar el backup (o copias de seguridad) y la
restauracin del sistema
En
todos
los
casos
la
recuperacin de la informacin
deber hacerse en menos de tres
segundos
Necesidad
Prioridad
Alta
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Baja
Alta
Tabla 8.6. Catlogo completo de requisitos.
150

8.4 IDENTIFICACIN DE SUBSISTEMAS DE ANLISIS (ASI 3)
El objetivo de esta actividad es dividir al sistema en subsistemas con el

objeto de facilitar su anlisis. Se realiza en paralelo con actividades
correspondientes a la generacin de modelos de anlisis; por ello, se asume
una realimentacin y ajuste continuo con respecto a la definicin de los
subsistemas, sus dependencias y sus interfaces.
8.4.1 DETERMINACIN DE SUBSISTEMAS DE ANLISIS (ASI 3.1)
La descomposicin del sistema en subsistemas est normalmente

orientada al modelo de negocios, aunque es posible adoptar tambin otros
criterios. Entre esos criterios se encuentran los siguientes:
Homogeneidad de procesos.
Servicios comunes.
Prioridad.
Afinidad de requisitos.
Localizacin geogrfica.
Como el caso de este tipo de desarrollo se trata de un anlisis

estructurado, los subsistemas coinciden generalmente con el primer nivel de
descomposicin. Se toma como entrada de la tarea el modelo de contexto
exhibido en la figura 8.1 del presente captulo. En la figura 8.17 se muestra un
diagrama de nivel 1, para determinar los subsistemas de anlisis.

151
NIVEL 1 - SUBSISTEMAS
IDENTIFICADOS
A1
Transacciones
Lgicas
A3
Parmetros de
Clculo
Datos de Elementos
de la Aplicacin
(Trans. Lgicas)
Usuario
Encargado de
Proyecto
Datos de la
Aplicacin a
Medir
-1Ingresar
Datos de
Aplicacin a
Medir
Datos
Generales
del Proyecto
A2
Nuevos Valores de
Parmetros de
Clculo
Parmetros
de Clculo
-2Realizar
Clculos de
Medicin
Resultados
de
Mediciones
Resultados
de
Mediciones
-3Mostrar
Result. de
Medicin
Resultados
de
Mediciones
Usuario
Encargado de
Proyecto
Valores de
Elementos
Para
Medicin
Mediciones
-4Actualizar
Parmetros
de Clculo
A2
Mediciones
Valores Actuaiizados de
Parmetros de Clculo
Valores Actuaies
de Parmetros de
Clculo
A3
Parmetros de
Clculo
A3
Parmetros
de Clculo
Figura 8.17. Primer nivel de descomposicin de sistema en subsistemas de

anlisis.
8.4.2 INTEGRACIN DE SUBSISTEMAS DE ANLISIS (ASI 3.2)
El objetivo de esta tarea es la coordinacin en la elaboracin de los
distintos modelos de anlisis de cada subsistema, asegurando la ausencia de
duplicidad de elementos y la precisin en la elaboracin de los trminos del
glosario. Esta tarea se realiza en paralelo con el resto de las tareas de anlisis.
Como resultado de esta tarea, se exhibe el modelo de procesos (anexo
A.III y anexo B.III) y los niveles I y II. En el anexo C.III se realiza adems, una
descripcin de los procesos.
8.5 ELABORACIN DEL MODELO DE DATOS (ASI 6)
El objetivo de esta actividad es obtener un modelo de datos que contemple

todas las entidades, relaciones, atributos y reglas de negocio. El modelo de
datos requiere un anlisis de lo general a lo particular (comnmente llamado
top-down).
8.5.1 ELABORACIN DEL MODELO CONCEPTUAL DE DATOS (ASI 6.1)
Para la elaboracin del modelo conceptual de datos, generalmente se parte

del modelo de contexto de la figura 8.1, el cual permite tener una visin general
152

de la aplicacin e identificar las entidades externas que intervienen. Luego, se

construye el modelo entidad-relacin (figura 8.2) y; a partir de este, es posible
describir a los atributos, dominio del atributo y sus relaciones. En el anexo II.A
se muestra una tabla con la descripcin de los atributos correspondientes a las
entidades involucradas en el modelo de negocio.
En esta etapa, se identifican adems a aquellas entidades que no forman
parte del modelo pero que tienen alguna relacin con aquellas. Son ejemplo de
este tipo de entidades:
descripcin de las caractersticas tcnicas de la aplicacin,
ajustes de complejidad tcnica.
8.5.2 ELABORACIN DEL MODELO LGICO DE DATOS (ASI 6.2)
En esta etapa se obtiene el modelo lgico de datos a partir del modelo

conceptual. Se han resuelto las relaciones complejas, se han eliminado
ambigedades y se han identificado relaciones de dependencia entre
entidades. En el anexo II.B se muestra un diagrama con las relaciones de
entidades y los atributos relacionados; el anexo II.C muestra la
correspondencia entre los nombres de las entidades y las tablas de la base de
datos.
8.5.3 NORMALIZACIN DEL MODELO LGICO DE DATOS (ASI 6.3)
El objetivo de esta tarea es revisar el modelo para asegurar que cumple al

menos con la tercera forma normal. Si bien es cierto, no se quiere profundizar
acerca del estudio de las formas normales, se puede decir a modo de
referencia, que la primera forma normal tiene como objetivo transformar los
atributos con ms de una valor en ms de una t-upla (o tantas t-uplas como
valores de atributos existan). La segunda forma normal tiene como objetivo
garantizar una dependencia funcional total respecto de cada una de las claves.
Por ltimo, la tercera forma normal determina que un atributo que forma parte
de una clave y otro que no forma parte de la clave pero que tiene dependencia
funcional con aquel, no debe pertenecer al primero. En el anexo II.B, se
muestra un esquema normalizado de las relaciones entre las entidades y los
atributos incluidos. Los smbolos 1 e (infinito) significan que de una lado
existe una t-upla y del otro varias (n t-uplas).
8.5.4 ESPECIFICACIN DE NECESIDADES DE MIGRACIN DE DATOS Y
CARGA INICIAL (ASI 6.4)
Esta tarea implica la migracin de datos que provienen de un sistema en

funcionamiento o la carga inicial para comprobar el perfecto funcionamiento del
sistema. Como se trata de un trabajo que se inicia de cero, no hay necesidad
de migracin de datos. Con respecto a la carga inicial, se estipula el ingreso
de valores de SSBBCC desarrollados como trabajos de tesis por alumnos del
ITBA. Los trabajos de tesis que se han seleccionado, se especifican luego, en
las tareas correspondientes a planificacin y diseo de las pruebas.
153
8.6 ELABORACIN DE UN MODELO DE PROCESOS (ASI 7)
El objetivo de esta actividad es analizar las necesidades del usuario para

establecer el conjunto de procesos que conforman el sistema de informacin.
Se realiza una descomposicin top-down (es decir de arriba hacia abajo), que
se inici con el diagrama de contexto (o nivel 0) de la figura 8.1 y continu con
el diagrama de la figura 8.16 correspondiente al nivel 1.
Un nivel claro de entendimiento, se debera alcanzar con una
desagregacin en un nivel ms bajo de detalle (nivel 2) y que a su vez, se
corresponda con el de nivel 1.
Para el caso particular de este trabajo de tesis, se ha llegado hasta el nivel
2 de desagregacin, no siendo necesario avanzar hacia otros niveles de mayor
profundidad.
8.6.1 OBTENCIN DEL MODELO DE PROCESOS DEL SISTEMA (ASI 7.1)
En esta tarea se lleva a cabo la descripcin de los subsistemas definidos

en la actividad 3 (ASI 3), mediante la descomposicin en sucesivos niveles de
procesos. La tcnica habitual para llevar a cabo las tareas de esta actividad es
el diagrama de flujo de datos (DFD). Durante las tareas correspondientes a
esta actividad, se describe la estructura de los flujos de datos, almacenes y el
tipo de tratamiento.
Para una mejor comprensin, se muestra en el anexo III.A el modelo de
procesos de nivel 1 ya exhibido en la figura 8.16 y; en el anexo III.B, el nivel 2
correspondiente a las siguientes funciones:
Ingreso de datos de la aplicacin a medir.

Clculo de valores de la medicin.
Mostrar resultados de la medicin.
Actualizar parmetros de clculo.
En el anexo III.C, se realiza la descripcin de los procesos.

8.6.2 ESPECIFICACIN DE INTERFACES CON OTROS SISTEMAS (ASI 7.2)
En esta actividad se describe en detalle las interfaces que el sistema

mantiene con otros sistemas. Esta tarea se desarrolla con el objeto de delimitar
al sistema. Para el caso de la aplicacin que se est desarrollando, no existen
interfaces con otros sistemas.
8.7 DEFINICIN DE INTERFACES DEL USUARIO (ASI 8)
En esta actividad se especifican las interfaces entre el usuario y el sistema:

formatos de pantalla, dilogos e informes principalmente. Su objetivo es
154

realizar un anlisis de los procesos del sistema de informacin en los que se

requiere una interaccin con el usuario, con el fin de crear una interfaz que
satisfaga todos los requisitos establecidos, teniendo en cuenta los diferentes
perfiles a quienes va dirigido.
Al comienzo de este anlisis es necesario seleccionar el entorno en el que
es operativa la interfaz, considerando estndares internacionales y de la
instalacin, y establecer las directrices aplicables en los procesos de diseo y
construccin. El propsito es construir una interfaz de usuario acorde a sus
necesidades, flexible, coherente, eficiente, y sencilla de utilizar, teniendo en
cuenta la facilidad de cambio hacia otras plataformas si fuera necesario.
Se identifican distintos tipos de usuarios de acuerdo a las funciones que
realizan, conocimientos y habilidades que poseen y caractersticas del entorno
en el que trabajan. Esta identificacin permite conocer mejor las necesidades
particulares de cada uno de ellos.
Adems se identifica la naturaleza de los procesos que se llevan a cabo
(en lotes o en lnea). Para cada proceso en lnea se especifica qu tipo de
informacin requiere el usuario para completar su ejecucin realizando para
ello, una descomposicin en dilogos que refleje la secuencia de la interfaz de
pantalla tipo texto o de pantalla grfica.
Finalmente se define el formato y contenido de cada una de las interfaces
de pantalla especificando su comportamiento dinmico.
8.7.1 ESPECIFICACIN DE LOS PRINCIPIOS GENERALES DE LA
INTERFAZ (ASI 8.1)
El objetivo de esta tarea es especificar los estndares, elementos

generales y directrices a tener en cuenta en la interfaz del usuario. La interfaz
es del tipo grfica (GUI del ingls graphic user interface). Los mens se
presentan en dos formatos: por un lado descolgables y por otro mediante
transicin de pantallas.
8.7.2 IDENTIFICACIN DE PERFILES Y DILOGOS (ASI 8.2)
El objetivo de esta tarea es identificar los perfiles de usuario, de acuerdo a

su nivel de responsabilidad y al alcance o naturaleza de las funciones que
realizan, as como analizar las caractersticas ms relevantes de los usuarios
que van a asumir estos perfiles, valorando tanto su conocimiento tcnico; es
decir, la mecnica necesaria para usar la interfaz eficazmente como as
tambin su conocimiento del negocio, en cuanto a la comprensin de las
funciones que realizan, relacin entre funciones y condicionantes en su
ejecucin.
El usuario caracterstico de esta aplicacin es el encargado del proyecto de
desarrollo de Sistemas Basados en Conocimientos (SSBBCC). Su funcin es
155
determinar en forma aproximada el tiempo, costo y esfuerzo necesario para

acometer dicho desarrollo. Como primer dato esencial para llevar a cabo la
estimacin debe conocer el tamao aproximado de la aplicacin a medir. Para
ello debe poder identificar las caractersticas de la aplicacin que se mide.
Entre estas caractersticas estn:
Transacciones lgicas.
Entradas.
Salidas.
Conceptos (de la tabla concepto-atributo-valor).
Tipo de razonamiento (aproximado, no aproximado).
8.7.3 ESPECIFICACIN DE FORMATOS INDIVIDUALES DE INTERFAZ DE

PANTALLA (ASI 8.3)
El objetivo de esta tarea es especificar cada formato individual de interfaz

de pantalla desde el punto de vista esttico.
Como primera medida, se identifican cuatro tipos de pantalla:
i)
ii)
iii)
iv)
Pantalla de presentacin.
Pantalla de men.
Pantalla de ingreso de datos.
Pantalla de consulta de datos.
Estos cuatro tipos de pantalla se muestran en las figuras 8.18 a 8.21. El

tipo de pantalla de presentacin se muestra al inicio de la aplicacin (figura
8.18). Es una pantalla que solamente presenta a la aplicacin, el autor y los
datos generales. Aqu se solicita el usuario y la contrasea; a su vez, esta
pantalla conecta al usuario con el men principal (figura 8.19).
156

Figura 8.18. Tipo de pantalla presentacin de la aplicacin.

La figura 8.19 muestra un tipo de pantalla de mens. Estos tienen por
objetivo guiar al usuario por las distintas alternativas, funciones o subsistemas
de la aplicacin.
Otro tipo de pantalla es la de ingreso de datos, en la cual se pueden hacer
las operaciones de edicin, modificacin y borrado de datos. El modelo es
idntico a las pantallas exhibidas en las figuras 8.4 a 8.8.
Figura 8.19. Tipo de pantalla de mens.

157
Otro tipo de pantalla es la de consulta de datos cuyo objetivo es permitir la

visualizacin de los resultados de las mediciones. Un ejemplo de este tipo de
pantallas son las de las figuras 8.11 y 8.12.
8.7.4 ESPECIFICACIN DEL COMPORTAMIENTO DINMICO DE LA
INTERFAZ (ASI 8.4)
El objetivo de esta tarea es definir los flujos entre los distintos formatos de
interfaz de pantalla y flujos dentro del mismo formato. Este modelo se describe
mediante un modelo de navegacin de interfaz de pantalla.
En el punto 8.3.2 ESPECIFICACIN DE CASOS DE USO (ASI 2.2), se
han exhibido pantallas derivadas de los distintos casos de uso. Por su parte en
el punto 8.7.3 ESPECIFICACIN DE FORMATOS INDIVIDUALES DE
INTERFAZ DE PANTALLA (ASI 8.3), se muestran distintos tipos de pantallas.
Ya sea que cumplan con uno u otro requisito de la metodologa mtrica V3,
estas pantallas, junto con otras que se muestran a continuacin (figura 8.20 a
8.23), componen un conjunto de elementos de interfaz. Estos elementos se
referencian en la tabla 8.7.
Figura 8.20. Pantalla del men de ingreso de datos de la aplicacin.
158

Figura 8.21. Pantalla de men de consulta de valores y resultados de

mediciones.
Figura 8.22. Pantalla de men de reportes y listados.

159
Figura 8.23. Pantalla de men de parmetros de clculo.

A continuacin se muestra en la tabla 8.7, las pantallas y el cdigo de
figura que corresponde al captulo (VIII en este caso) y al orden de aparicin en
este. Para cada pantalla se especifica entrada lgica de datos y regla de
validacin.
160

Cdigo
PAN_01
PAN_02
PAN_03
PAN_04
PAN_05
PAN_06
Descripcin de Pantalla
Presentacin de la Aplicacin
y Entrada al Sistema
Men Principal (Panel de
Control Principal)
Men de Ingreso de Datos de
la Aplicacin
Men de Consulta de Valores
y Resultados
Men de Reportes y Listados
Men de Parmetros de
Clculo
PAN_07 ABM de Datos del Proyecto
PAN_08
PAN_09
PAN_10
ABM de Transacciones
Lgicas
ABM de Entradas de
Transacciones Lgicas
ABM de Salidas de
Ingreso de Caractersticas
Tcnicas de la Aplicacin
Resultados Estimativos de la
Medicin
Resumen de los Resultados
PAN_14
de la Medicin
Detalle de los Resultados de la
PAN_15
Medicin
PAN_13
Entrada de Datos
Regla de
Validacin
8.18
Registro como usuario e ingreso

de contrasea. Luego, click en
Usuario y
el botn que aparece a la
contrasea vlidos
derecha de la pantalla, para
pasar a la siguiente
8.19
Se selecciona una alternativa.
Ninguna
8.2
Ninguna
8.21
Ninguna
8.22
Ninguna
8.23
Ninguna
8.4
8.5
ABM de Conceptos de
PAN_11
PAN_12
Cod.
Figura
Nombre de
Se ingresan los datos de
proyecto, aplicacin
proyecto (nombre, fecha,
y cliente no nulos y
nombre de aplicacin y cliente) formato de fecha
vlidos
La identificacin es
Se ingresan las transacciones autonumrica y la
lgicas identificadas de la
descripcin de la
aplicacin a medir
transaccin lgica
debe ser no nula
8.6
El nombre de
Se selecciona una transaccin
atributo relacionado,
lgica de una lista, luego se
tipo de elemento y
ingresan las entradas de la
breve descripcin
transaccin lgica seleccionada
deben ser no nulos
8.7
El nombre de
atributo relacionado,
tipo de elemento y
ingresan las salidas de la
breve descripcin
deben ser no nulos
8.8

ingresan los conceptos de la
El nombre de
concepto y la
descripcin deben
ser no nulos
8.9
Se ingresan las caractersticas

tcnicas de la aplicacin a
medir y su valoracin
Las caractersticas
tcnicas estn
relacionadas con
una tabla y los
valores deben estar
comprendidos entre
1 y 5.
8.10
Ninguna
Ninguna
8.11
Ninguna
Ninguna
8.12
Ninguna
Ninguna
Tabla 8.7. Especificacin de pantallas, entrada lgica de datos y reglas de

validacin.
161
Cdigo
PAN_16
Cod.
Figura
Descripcin de Pantalla
Actualizacin de Parmetros de
Clculo
ABM de Caractersticas
PAN_17 Tcnicas de la Aplicacin a
Medir
Consulta de Factores de Ajuste
PAN_18
de Complejidad
PAN_19
Consulta de Valores de Ajuste

de Complejidad Tcnica
8.13
8.15
8.14
8.16
Entrada de Datos
Regla de
Validacin
Valores de coeficientes (CAL)

para entradas, salidas y
conceptos. Coeficientes de
Valores de
ajuste de complejidad tcnica y
coeficientes vlidos
varuacin del ajuste. Costo de la
hora de trabajo y cantidad de
horas de trabajo por semana
Actualiza los valores de las
caractersticas tcnicas de la
aplicacin
Consulta de los Factores de
Ajuste de Complejidad Tcnica
Ninguna
Descripcin no nula
Ninguna
Ninguna
Tabla 8.7. Especificacin de pantallas, entrada lgica de datos y reglas de

validacin (continuacin)
Una vez exhibida la tabla 8.7 de codificacin de pantallas, se muestra el
modelo de navegacin en la figura 8.24
162

PAN_01
PAN_02
PAN_03
PAN_07
PAN_08
PAN_09
PAN_10
PAN_11
PAN_12
PAN_13
PAN_04
PAN_14
PAN_15
PAN_18
PAN_19
PAN_05
PAN_06
PAN_16
PAN_17
Figura 8.24. Modelo de navegacin de pantallas.

163
8.7.5 ESPECIFICACIN DE FORMATOS DE IMPRESIN (ASI 8.5)
El objetivo de esta tarea es especificar los formatos y caractersticas de las

salidas de impresin. Los formatos que se desprenden de la pantalla PAN_06
de la figura 8.24 se muestran en las figuras 8.25 y 8.26.
Figura 8.25. Modelo de formato de impresin para listado de proyectos.
Figura 8.26. Modelo de formato de impresin de resultados de mediciones.

8.8 ANLISIS DE CONSISTENCIA Y ESPECIFICACIN DE REQUISITOS
(ASI 9)
El objetivo de esta actividad es garantizar la calidad de los distintos

modelos generados en la fase de Anlisis del Sistema de Informacin (ASI).
Adems, se elabora en esta actividad la Especificacin de Requisitos del
Software (ERS) como producto para la aprobacin formal por parte del usuario
de las especificaciones del sistema. La ERS se convierte en lnea base para los
procesos posteriores de desarrollo de software, de modo que cualquier peticin
de cambio en los requisitos que pueda surgir, debe ser evaluada y aprobada.
164

8.8.1 VERIFICACIN DE LOS MODELOS (ASI 9.1)
El objetivo de esta tarea es asegurar la calidad de los distintos modelos

conforme a las tcnicas especificadas. En esta tarea se debe asegurar que el
modelo exhibido en el anexo II.B sea vlido y verificable. Tambin se debe
tener en cuenta el mismo criterio para el modelo de procesos que se muestra
en el anexo III.A y anexo III.B. El primero es de nivel 1 y el del anexo III.B
corresponde a su desagregacin (nivel 2).
8.8.2 ANLISIS DE CONSISTENCIA ENTRE MODELOS (ASI 9.2)
El objetivo de esta tarea es asegurar que los modelos sean coherentes

entre s, comprobando falta de ambigedades o duplicacin de la informacin.
Las comprobaciones que se realizan generalmente, son del tipo matriz donde
se pueden visualizar los elementos comunes a los distintos tipos de
representaciones.
La correspondencia entre almacenes de datos y entidades, se muestra en
el anexo II.C y las entidades que son accedidas por procesos primitivos o
primarios, se muestran en el anexo II.D. Los modelos se han comprobado y
resultan consistentes.
8.8.3 VALIDACIN DE LOS MODELOS (ASI 9.3)
El objetivo de esta tarea es validar los distintos modelos con los requisitos
especificados para el sistema de informacin, tanto a travs del catlogo de
requisitos, traza de requisitos o mediante la validacin directa del usuario.
Para este tipo de tareas, resulta conveniente la validacin de los modelos
mediante tcnicas de prototipado. Debido a que este proyecto es ms bien
pequeo; es decir, no consume una cantidad importante de lneas de cdigo,
se omite esta tarea para dar lugar a las correspondientes a la elaboracin de la
ERS.
8.8.4 ELABORACIN DE LA ESPECIFICACIN DE REQUISITOS DEL
SOFTWARE (ASI 9.4)
En esta tarea se realiza la especificacin de requisitos del software que

tiene por objeto agrupar los distintos elementos de anlisis construidos en esta
fase. La tabla 8.8 se encarga de mostrar una especificacin de requisitos del
software.

165
Propsito
Alcance
Definicin de
trminos
Referencias
Perspectiva del
producto
Funciones del
producto
Caractersticas del
Usuario
Restricciones
Interfaces
externas
Funciones
Requisitos de
rendimiento
Restricciones
lgicas de la base
de datos y
atributos
El propsito de la ERS es agrupar los distintos

elementos generados en la fase de ASI, bajo una
denominacin.
El producto software que se construye tiene como
objetivo realizar mediciones aproximadas en sistemas
software basados en conocimientos.
En el apndice A se muestran los acrnimos utilizados a
lo largo del desarrollo del trabajo de tesis y de la
documentacin del desarrollo del software.
En el documento denominado bibliografa se muestran
todas las referencias bibliogrficas.
Mediante la figura 8.1 se identifica al producto y su
relacin con el usuario. No existe relacin con otros
productos
En el diagrama de casos de uso (figura 8.3) y tabla 8.2,
se pueden identificar las funciones principales del
producto.
Es un encargado de proyecto quin demanda
informacin de tamao aproximado de software a
desarrollar.
Con respecto al hardware requerido, se muestra en el
catlogo de la tabla 8.6.
El conjunto de las interfaces se muestran en la tabla 8.7,
donde se resumen las referencias a pantallas, la
mayora mostradas en este captulo.
Se muestra en la tabla 8.6 en el catlogo de requisitos
funcionales.
Se muestran en la tabla 8.6.
En el anexo II.A se hace una descripcin de las
entidades, atributos, descripcin y dominio. En el anexo
II.B, el diagrama de las entidades normalizadas (con sus
atributos, identificadores y relaciones). En anexo II.C, se
muestra la correlacin entre entidades y tablas de la
base de datos. Por ltimo en el anexo II.D, se muestra
las entidades que son accedidas por procesos
primarios.
Tabla 8.8. Especificacin de requisitos del software.

8.9 ESPECIFICACIN DEL PLAN DE PRUEBAS (ASI 10)
En esta actividad se inicia la especificacin del plan de pruebas el cual

sirve como gua para su realizacin. Permite verificar que el sistema de
informacin cumple las necesidades establecidas por el usuario con las
debidas garantas de calidad.
166

El plan de pruebas es un producto formal que define los objetivos de la

prueba de un sistema, establece y coordina una estrategia de trabajo, y provee
del marco adecuado para elaborar una planificacin paso a paso de las
actividades de prueba. El plan se inicia en el proceso de Anlisis del Sistema
de Informacin (ASI), definiendo el marco general, y estableciendo los
requisitos de aceptacin de las pruebas, relacionados directamente con la
especificacin de requisitos.
A continuacin se desarrollan las actividades tendientes a definir un plan
de pruebas, cuyo objetivo ser establecer un marco de referencia capaz de
guiar el proceso que involucra las pruebas unitarias, de integracin, del sistema
y de aceptacin. Este plan se va completando y ejecutando en las fases de
diseo, construccin e implantacin del sistema.
8.9.1 DEFINICIN DEL ALCANCE DE LAS PRUEBAS (ASI 10.1)
En funcin de la solucin adoptada en el desarrollo de un sistema de

informacin, es posible que determinados niveles de prueba sean
especialmente crticos y otros no sean necesarios. Las pruebas son prcticas
que se realizan en diversos momentos del desarrollo del sistema de
informacin. Las tcnicas predominantes en todo proceso de prueba son la de
verificacin y validacin. Algunos aspectos a tener en cuenta y que se
relacionan con ellas son:
i)
ii)
iii)
iv)
v)
Correcto funcionamiento de los componentes del sistema.

Correcto ensamblaje entre componentes.
Correcto funcionamiento del sistema con las interfaces internas y
externas.
Correcto funcionamiento del sistema integrado (hardware y software)
en el entorno de operacin.
Aceptacin por parte del usuario de funcionalidad y rendimiento del
sistema.
Los tipos de pruebas que se plantean para verificar y validar el sistema

son:
Unitarias.
Integracin.
Sistema.
Aceptacin.
Los perfiles implicados y los objetivos de las distintas pruebas varan. En el

cuadro 8.9, se hace una distribucin de los perfiles y los objetivos segn el tipo
de prueba a realizar:

167
Tipo de
Prueba
Perfil
Requerido
Unitaria
Integracin
Programador
Sistema
Aceptacin
Objetivo (s)
Observaciones
Asegurar que
cada uno de
los
mdulos
estn
correctamente
codificados.
Verificar
la
existencia de
errores
una
vez
ensamblados
los mdulos
Verificar que el
sistema integrado
(hardware
y
software) cumple
con los requisitos
especificados.
Comprobar que el
producto est listo
para
su
uso
operativo en el
entorno del cliente.
Este tipo de prueba, es llevado a

cabo por el programador que
codifica
cada
mdulo.
Sin
embargo, es recomendable que
las realice quin a pesar de tener
ese perfil no ha codificado los
mdulos. De esta forma se gana
en objetividad. Para el caso
particular del presente trabajo de
tesis, este tipo de prueba es
llevado a cabo por el autor de
dichos mdulos.
El criterio es similar al caso
anterior. Es el autor del proyecto
quien cumple las funciones de los
perfiles requeridos para probar el
sistema y asegurar que cumple
con los requisitos especificados.
El autor del proyecto, se convierte
en usuario del sistema. Las
pruebas sern aportadas por
datos
provenientes
de
los
proyectos seleccionados (tesis del
Magster
en
Ingeniera
del
Software ITBA de SSBBCC).
Programador
Ingeniero de
Software
Usuarios del
sistema
Usuarios del
sistema
Ingeniero de
software
Tabla 8.9. Perfiles y objetivos de los distintos tipos de pruebas.

Otro aspecto a tener en cuenta en las pruebas son los enfoques que se
usan para cada tipo de prueba y los criterios para seleccionar casos de prueba.
Estos se muestran en la tabla 8.10.
168

Tipo de
Prueba
Criterios Para Seleccionar los

Casos de Prueba
Enfoque
Unitaria
Funcional (caja negra)
Integracin
Integracin incremental
Sistema
Aceptacin
Funcional
Comunicaciones
Rendimiento
Facilidad de uso
Seguridad
Se seleccionan todos los mdulos de la

aplicacin.
Se planifican las entradas y salidas
esperadas.
Se integran primero los mdulos de nivel
ms bajo hacia arriba, hasta llegar a nivel de
programa en su conjunto.
Se seleccionan casos de prueba acordes a
cada tipo de enfoque.
Prueba del sistema con casos reales,
extrados de trabajos realizados en el ITBA
por tesistas, en los cuales se han
desarrollados
Sistemas
Basados
en
Conocimientos.
Validacin
Tabla 8.10. Enfoques, criterios de seleccin de tipos de pruebas.

8.9.2 DEFINICIN DE REQUISITOS DEL ENTORNO DE PRUEBAS (ASI
10.2)
El objetivo de esta tarea es la definicin o recopilacin de los requisitos

relativos al entorno de pruebas, completando en plan de pruebas.
Generalmente se aconseja tener un entorno separado para el plan de pruebas
con respecto al entorno de desarrollo. Como este caso particular se trata de un
desarrollo ms bien pequeo, solamente se toma la precaucin de crear una
versin de back-up para la realizacin de dichas pruebas; siendo el
equipamiento utilizado, el mismo en el que se desarrolla la aplicacin. La tabla
8.11, refleja los requisitos del entorno de pruebas.
Tipos de Requisito
Requisitos bsicos de hardware
Descripcin del Tipo de Requisito

Se define el equipamiento necesario
para llevar a cabo las pruebas
Requisitos bsicos de software
Se define el entorno necesario para
llevar a cabo las pruebas. Esto incluye
sistema operativo, gestores de bases
de datos y software de aplicacin
Herramientas auxiliares
Identificacin
y
extraccin
de
muestras para llevar a cabo las
pruebas
Procedimientos para realizacin de Migraciones entre entornos
las pruebas
Tabla 8.11. Requisitos del entorno de pruebas.

169
La informacin con la que se cuenta como dato de entrada para llevar a

cabo las pruebas, proviene de los trabajos de tesis de la carrera de postgrado
en Ingeniera del Software; especficamente aquellos temas que son de
desarrollo de SSBBCC.
Para el caso particular de este trabajo de tesis, se han seleccionado dos
proyectos. Uno de ellos es el presentado por el M. Ing. Eduardo Diez [Diez03],
titulado Generador de un Mapa de Actividades (GMAP). El otro es un
SSBBCC desarrollado por el M. Ing. Daro Piccirilli [Piccirilli03], de Sistema de
Ayuda Para la Seleccin de un Perito Informtico, Especialista en
Propiedad Intelectual del Software. Ambos trabajos han sido elegidos
despus de una exhaustiva bsqueda y anlisis de varios de ellos, y tomando
como referencia la informacin de gestin y documentacin que brindan. En el
captulo XI, se llevan a cabo las pruebas de aceptacin con los valores reales
extrados de los proyectos mencionados.
8.9.3 DEFINICIN DE LAS PRUEBAS DE ACEPTACIN DEL SISTEMA (ASI
10.3)
En el marco de esta tarea se realiza la prueba de aceptacin del sistema;

labor desempeada por el usuario quin valida el sistema como paso previo a
la aceptacin. Los criterios de aceptacin son importantes y sirven para
asegurar que satisface los requisitos exigidos. Los niveles de errores [Ares
Casal06] que se pueden encontrar en los desarrollos de software, se definen
en la tabla 8.12.
Nivel de Error
Ninguno
Leve
Moderado
Incmodo
Trastorno
Serio
Muy serio
Extremo
Intolerable
Descripcin
No existe error alguno.
Los sntomas del error suelen ser estticos. Por ejemplo
encolumnado incorrecto de los datos.
El efecto puede afectar el rendimiento del sistema. Por
ejemplo salidas redundantes.
Puede deshumanizar el comportamiento del sistema. Por
ejemplo nombres truncados.
No realiza en forma correcta el tratamiento de las
transacciones.
Se pierde la pista de la transaccin.
El sistema realiza una transaccin errnea.
El problema no se limita a unos pocos usuarios o
transacciones tipo, sino que la frecuencia y arbitrariedad es
la norma frente a lo espordico o casos inusuales.
Provoca tomar la decisin de parar el sistema.
Tabla 8.12. Tipos o niveles de error.

Una vez definidos los niveles de error, es posible exhibir los criterios y
niveles de aceptacin para los distintos tipos de pruebas.
170

Tipo de
Prueba
Unidad
Integracin
Sistema
Aceptacin
Criterio de Aceptacin
Los mdulos deben funcionar correctamente.
Los mdulos deben funcionar correctamente
en su conjunto
Los tiempos de respuesta deben estar
dentro de los lmites establecidos en la
ERS.
El sistema se debe adaptar a las
necesidades del usuario y permitir la
correcta introduccin de datos.
El criterio de aceptacin est definido por la
especificacin de requisitos del software y
aprobados por el usuario.
Nivel Necesario Para la

Aceptacin
Leve / Ninguno
Leve / Ninguno
Leve / Ninguno
Leve / Ninguno
Tabla 8.13. Criterios y niveles de aceptacin para los tipos de pruebas

8.10 PRESENTACIN Y APROBACIN DEL ANLISIS DEL SISTEMA DE
INFORMACIN (ASI.11.1)
En esta etapa se realiza la presentacin del anlisis del sistema de

informacin al Comit encargado de evaluarlo.

171
CAPTULO IX
DISEO
DEL
SISTEMA
DE
INFORMACIN
(DSI)
CAPTULO IX
DISEO DEL SISTEMA DE INFORMACIN (DSI)
9.1 INTRODUCCIN
En este captulo se desarrollan las actividades de diseo del sistema de

informacin (DSI). El objetivo de este proceso es definir la arquitectura del
sistema y su entorno tecnolgico que le va a dar soporte junto con la
especificacin detallada de los componentes del sistema de informacin.
9.2 DEFINICIN DE LA ARQUITECTURA DEL SISTEMA (DSI.1)
En esta actividad se define la arquitectura general del sistema de

informacin, especificando las distintas particiones fsicas del mismo, la
descomposicin lgica en subsistemas de diseo y la ubicacin de cada
subsistema en cada particin, as como la especificacin detallada de la
infraestructura tecnolgica necesaria para dar soporte al sistema de
informacin.
El particionamiento fsico del sistema de informacin se especifica
identificando los nodos y las comunicaciones entre los mismos, con cierta
independencia de la infraestructura tecnolgica que da soporte a cada nodo.
Con el fin de organizar y facilitar el diseo, se realiza una divisin del sistema
de informacin en subsistemas de diseo, como partes lgicas coherentes y
con interfaces claramente definidas.
9.2.1 DEFINICIN DE NIVELES DE ARQUITECTURA (DSI 1.1)
En esta tarea se describen los niveles de arquitectura del software,

mediante la definicin de las particiones fsicas del sistema de informacin,
representadas como nodos y comunicacin entre nodos.
Se entiende por nodo cada particin fsica o parte significativa del sistema
de informacin con caractersticas propias de ejecucin o funcin, e incluso de
diseo y construccin. Para mostrar las particiones fsicas se utiliza como
tcnica el diagrama de despliegue, el cual representa la disposicin de las
particiones fsicas del sistema de informacin y la asignacin de los
componentes software a estas particiones. La figura 9.1 muestra un diagrama
para la aplicacin que se construye.
Captulo IX Diseo del

Sistema de Informacin (DSI)
175
Cliente - Usuario
Encargado de
Proyecto
GUI
PC - Estimacin
de Tamao de
Software
(ESTIMSBC)
Impre
sora
Base de Datos
- ESTIMSBC
Figura 9.1. Definicin de niveles de arquitectura - diagrama de despliegue.

En el diagrama de la figura 9.1, se identifican los nodos conformados por:
Clientes: son usuarios del sistema de informacin. Para el caso particular
de la aplicacin que se construye, corresponde a un perfil del tipo
encargado de proyecto. Este se comunica con la aplicacin mediante una
interfaz GUI (del ingls Graphic User Interface) con el objeto de grabar o
recuperar informacin en/de la base de datos ESTIMSBC, construida a
tales fines.
PC Estimacin de Tamao de Software ESTIMSBC: la aplicacin se
construye para ser ejecutada en ambientes monolticos, generalmente
conformado por una PC con sistema operativo y software de aplicacin. La
misma permite comunicar al usuario con los datos almacenados en la base
de datos.
Base de Datos ESTIMSBC: contiene los datos de los proyectos y los
resultados de las mediciones. Estos datos estn a disposicin del usuario y
peden ser actualizados.
176

Impresora: permite canalizar todo tipo de salida impresa, llmese

resultados de mediciones, cartera de proyectos y, o cualquier informacin
que por resoluciones de diseo y requisitos del usuario deba ser impresa.
9.2.2 IDENTIFICACIN DE REQUISITOS DE DISEO Y CONSTRUCCIN
(DSI 1.2)
En esta tarea se realiza la especificacin de los requisitos que estn

directamente relacionados con la adopcin o diseo de una arquitectura o
infraestructura concreta, y que pueden condicionar el diseo o la construccin
del sistema de informacin. Entre estos elementos estn lenguajes,
rendimientos de los distintos elementos de la arquitectura, criterios de
ubicacin de los mdulos, etc. En la tabla 8.6 del captulo VIII, se ha definido un
catlogo completo de requisitos, en los cuales estn incluidos adems
requisitos funcionales y no funcionales. Siguiendo los lineamientos del
catlogo, se puede definir lo siguiente:
el rendimiento del sistema debe ser tal de que el usuario, luego de una
consulta pueda recuperar la informacin en un tiempo no mayor a los
dos (2) segundos,
la base de datos debe conservar la integridad referencial de sus datos y
de las relaciones existentes.
el entorno de desarrollo debe estar disponible para llevar a cabo la
codificacin de los mdulos.
9.2.3 ESPECIFICACIN DE EXCEPCIONES (DSI 1.3)
El objetivo de esta tarea es definir comportamientos no habituales en el

sistema, que reflejan situaciones anmalas o secundarias en el funcionamiento
y ejecucin del sistema de informacin. Para ello, se establece previamente el
nivel de especificacin de las mismas, as como los criterios de catalogacin y
clasificacin.
Se propone su catalogacin como ayuda para el diseo del sistema de
informacin y como gua para la especificacin tcnica de las pruebas al
permitir la generacin de algunos casos de prueba inmediatos. Este catlogo
se ir construyendo y completando conjuntamente con el diseo detallado del
sistema de informacin. A continuacin en las tablas 9.1 a 9.3 se muestran los
catlogos de excepciones identificados.

177
Tipo excepcin
Descripcin de la excepcin
Condiciones previas
Elementos afectados
Rango de valores
El rango de valor invlido para los ajustes
de complejidad tcnica son mayores a 5
(cinco) y menores a 1 (uno).
Debe existir un software que se quiere
medir y se deben haber ingresado los
valores de las transacciones lgicas
Tabla de mediciones
Respuestas del sistema de

informacin
Tabla 9.1. Catlogo de excepcin de rango de valores.

Tipo excepcin
Descripcin de la
excepcin
Condiciones previas
Elementos afectados
Ruptura de integridad referencial

Cuando se desea eliminar un registro, el sistema
debe prevenir que no se rompa la integridad
referencial.
El usuario debe querer eliminar un registro
determinado.
Tabla de mediciones, tabla de transacciones
lgicas, tabla de entradas, salidas y conceptos
Respuestas del sistema

de informacin
Tabla 9.2. Catlogo de excepcin de ruptura de integridad referencial
178

Tipo excepcin
Descripcin de la
excepcin
Condiciones
previas
Elementos
afectados
Texto ingresado no existente en una lista de valores

Cuando se quiere ingresar un valor que no existe en
una lista.
El usuario debe querer consultar un elemento
(inexistente) de una lista.
Tabla de mediciones, tabla de transacciones lgicas,
tabla de entradas, salidas y conceptos
Respuestas del
sistema de
informacin
Tabla 9.3. Catlogo de excepcin de texto no existente en una lista de valores.

9.2.4 ESPECIFICACIN DE ESTNDARES Y NORMAS DE DISEO Y
CONSTRUCCIN (DSI 1.4)
En esta tarea se definen los estndares tcnicos y de nomenclatura,

normas y recomendaciones, que generalmente estn relacionadas con la
adopcin o diseo de una arquitectura o infraestructura tecnolgica concreta y
que pueden condicionar el diseo o la construccin del sistema de informacin.
El estndar que se sigue como gua para el desarrollo y la documentacin del
sistema es la metodologa mtrica V3.
9.2.5 IDENTIFICACIN DE SUBSISTEMAS DE DISEO (DSI 1.5)
En esta tarea se divide en forma lgica al sistema de informacin en

subsistemas de diseo con el fin de reducir la complejidad y facilitar el
mantenimiento. Hay que tomar como referencia inicial los subsistemas de
anlisis especificados en la fase de ASI. Se exhibe en la figura 9.2 el diagrama
de estructura para el modelo de aplicacin a desarrollar.

179
Figura 9.2. Diagrama de estructuras.

En las tablas subsiguientes (tabla 9.4 a la 9.14), se realiza una descripcin
de los procesos identificados y exhibidos en la figura 9.2
Nombre de Proceso: Ingresar datos del proyecto
Objetivo: Permitir el ingreso de los datos identificatorios del proyecto que involucra al software
a medir
Argumentos de entrada
Nmero de medicin
Fecha de medicin
Nombre del proyecto
Aplicacin
Cliente
Descripcin del proceso: Se ingresan los datos del proyecto que incluye la aplicacin a medir.
Argumentos de salida
Operaciones permitidas con Agregar
registros
Borrar
Modificar
Tabla 9.4. Proceso de ingresar datos del proyecto.
180

Nombre de Proceso: Ingresar descripciones de transacciones lgicas

Objetivo: Permitir el ingreso de los datos o descripciones de transacciones lgicas
Nmero de medicin
Id. de transaccin lgica
Nmero de medicin
Descripcin de transaccin lgica
Descripcin: Se localiza al proyecto y se ingresan las transacciones lgicas identificadas. Se
pueden agregar y borrar a las existentes.
Operaciones
permitidas
con Agregar
registros
Borrar
Modificar
Tabla 9.5. Proceso de ingresar descripciones de transacciones lgicas.

Nombre de Proceso: Ingresar entradas de transacciones lgicas
Objetivo: Permitir el ingreso de entradas de transacciones lgicas
Nombre de atributo relacionado
Tipo de elemento de entrada
Breve descripcin de la entrada
Descripcin del proceso: Se localiza la transaccin lgica que a su vez est asociada a un
proyecto. Luego, se pueden agregar, borrar o modificar filas correspondientes a las entradas.
Cantidad de entradas
Operaciones
permitidas
con Agregar
registros
Borrar
Modificar
Tabla 9.6. Proceso de ingresar entradas de transacciones lgicas.

Nombre de Proceso: Ingresar salidas de transacciones lgicas
Objetivo: Permitir el ingreso de salidas de transacciones lgicas
Nombre de atributo relacionado
Tipo de elemento de salida
Breve descripcin de la salida
proyecto. Luego, se pueden agregar, borrar o modificar filas correspondientes a las salidas.
Cantidad de salidas
Operaciones
permitidas
con Agregar
registros
Borrar
Modificar
Tabla 9.7. Proceso de ingresar salidas de transacciones lgicas.

181
Nombre de Proceso: Ingresar conceptos de transacciones lgicas

Objetivo: Permitir el ingreso de conceptos de transacciones lgicas
Nombre de concepto
Breve descripcin del concepto
proyecto. Luego, se pueden agregar, borrar o modificar filas correspondientes a los conceptos.
Cantidad de conceptos
Operaciones
permitidas
con Agregar
registros
Borrar
Modificar
Tabla 9.8. Proceso de ingresar conceptos de transacciones lgicas.

Nombre de Proceso: Ingresar caractersticas de la aplicacin
Objetivo: Permitir el ingreso de caractersticas de la aplicacin a medir
Conocimientos distribuidos
Eficiencia del usuario final
Facilidad de instalacin
Facilidad de operacin
Facilidad de comunicacin
Puestos mltiples
Razonamiento aproximado
Rendimiento
Reutilizacin
Uso del procesador
Descripcin del proceso: Se localiza un proyecto asociado a una aplicacin de la cual se
desean modificar el o los valore(s) de las caractersticas. Estos valores varan entre 1 y 5. Por
defecto el valor para cada una de las caractersticas tcnicas es igual a uno (1).
Conocimientos distribuidos
Eficiencia del usuario final
Facilidad de instalacin
Facilidad de operacin
Facilidad de comunicacin
Puestos mltiples
Razonamiento aproximado
Rendimiento
Reutilizacin
Uso del procesador
Operaciones
permitidas
con Modificacin
registros
Tabla 9.9. Ingreso de caractersticas de la aplicacin a medir.
182

Nombre de Proceso: Realizar medicin del tamao de la aplicacin

Objetivo: Realizar el clculo de los valores de funcionalidad segn los datos ingresados de la
aplicacin.
Cantidad de salidas
Valores de CAL entradas
Valores de CAL salidas
Valores de CAL conceptos
Coeficiente ACT
Coeficiente de variacin
Costo de hs-hombre
Hs. Semanales de trabajo
Descripcin del proceso: Se dispara un evento que ejecuta una funcin de clculo de los
PFSBC y los PFASBC, adems de obtener los indicadores de productividad y esfuerzos
necesarios para el desarrollo de la aplicacin.
PFSBC
PFASBC
Ajuste de complejidad Tcnica (ACT)
Productividad
Esfuerzo
Costo Estimado
Tiempo de Desarrollo
Operaciones
permitidas
con Lectura
registros
Tabla 9.10. Realizar medicin del tamao de la aplicacin.

Nombre de Proceso: Mostrar resultados de mediciones (resumen)
Objetivo: Consultar los resultados de mediciones de aplicaciones.
Solicitud de visualizacin de resultados de medicin
Descripcin del proceso: Se exhibe una pantalla con los argumentos de salida encolumnados,
cada vez que se ingresa en este procesoArgumentos de salida
Nmero de medicin
Cantidad de salidas
PFSBC
PFASBC
Productividad
Esfuerzo
Costo Estimado
Tiempo de Desarrollo
Operaciones
permitidas
con Lectura
registros
Tabla 9.11. Consultar resultados (resumen) de mediciones.

183
Nombre de Proceso: Actualizacin de parmetros de clculo

Objetivo: Actualizar los valores de los parmetros de clculo.
Descripcin del proceso: Se actualizan o se cambian los viejos valores por nuevos. Estos
ltimos sern tomados en cuenta a la hora de realizar los clculos de las estimaciones.
Valor Cal (entradas)
Valor Cal (salidas)
Valor Cal (conceptos)
Coeficiente de variacin de ACT
Costo de honorarios profesionales por hora
Horas de trabajo por semana
Operaciones
permitidas
con Lectura
registros
Grabacin
Tabla 9.12. Actualizacin de parmetros de clculo.

Nombre de Proceso: Actualizacin de valores de caractersticas tcnicas
Objetivo: Actualizar los valores de caractersticas tcnicas.
Descripcin del proceso: Cada ACT tiene asociado parmetros que representan las
caractersticas tcnicas de la aplicacin a medir. Inicialmente estos tienen valores asignados,
los que se pueden modificar en funcin de las instalaciones encargadas del desarrollo de la
aplicacin.
Valor de caracterstica tcnica
Operaciones
permitidas
con Agregar
registros
Borrar
Modificar
Tabla 9.13. Actualizacin de valores de caractersticas tcnicas.

Nombre de Proceso: Mostrar parmetros de clculo
Objetivo: Consultar los parmetros para el clculo de valores de estimacin.
Solicitud de visualizacin de parmetros de clculo.
Descripcin del proceso: Se exhibe una pantalla con los valores correspondiente a los
parmetros de clculo Argumentos de salida
Valor CAL para datos de entrada
Valor CAL para datos de salida
Valor CAL para conceptos de tablas CAV
Coeficiente para ajuste de complejidad tcnica
Coeficiente de variacin de ajuste de complejidad
tcnica
Costo de honorarios profesionales por hora
Cantidad de horas de trabajo por semana
Operaciones
permitidas
con Lectura
registros
Tabla 9.14. Mostrar parmetros de clculo.
184

9.2.6 ESPECIFICACIN DEL ENTORNO TECNOLGICO (DSI 1.6)
En esta tarea se definen en detalle los distintos elementos de la

infraestructura tcnica que dan soporte al sistema de informacin,
determinando la implementacin concreta de los nodos y comunicaciones
especificados en la tarea DSI 1.1. La infraestructura del entorno tecnolgico
necesario, no sufre modificaciones con respecto a lo especificado en la tabla
8.1 del captulo VIII y a lo especificado en el punto 9.2.1.
En esta tarea se realiza una planificacin de capacidades o se especifican
los parmetros que se precisan para la etapa de explotacin del sistema.
Algunos aspectos a tomar en cuenta con respecto a esta tarea son:
Almacenamiento: el espacio en disco y espacio en memoria no
i)
supera a las especificaciones del hardware de la tabla 8.1 (captulo
VIII). Tampoco se esperan tasas de crecimiento de informacin que
superen las pautas de almacenamiento de dicho punto.
ii)
Procesamiento: con respecto al nmero de procesadores, esta

aplicacin demanda solamente un solo procesador.
iii)
Comunicaciones: no est previsto en los requerimientos demandas

de comunicaciones con otras aplicaciones o procesamiento remoto.
9.2.7 ESPECIFICACIN DE REQUISITOS DE OPERACIN Y SEGURIDAD

(DSI 1.7)
El objetivo de esta tarea es definir los procedimientos de seguridad y

operacin necesarios para no comprometer el correcto funcionamiento del
sistema y garantizar el cumplimiento de los niveles de servicios que exigir el
sistema en cuanto a la gestin de operaciones (procesos por lotes, seguridad,
comunicaciones, etc.). Los niveles de servicio se especifican formalmente en el
proceso de Implantacin y Aceptacin del Sistema de Informacin (IAS).
Tomando como referencia los requisitos establecidos para el sistema, y
teniendo en cuenta la arquitectura propuesta y las caractersticas del entorno
tecnolgico definido en esta actividad, se lleva a cabo la definicin de los
requisitos de seguridad y control de accesos necesarios para garantizar la
proteccin del sistema y minimizar el riesgo de prdida, alteracin o consulta
indebida de la informacin.
La tabla 9.15, muestra las medidas propuestas relacionadas con la
seguridad en el sistema que se construye:

185
Tpico
Medida de Seguridad
La PC en la que se encuentra alojado el software,
Acceso al sistema y a los
debe estar protegida por contrasea para ingresar
recursos
al sistema operativo.
Mantenimiento de la
El sistema software debe impedir el acceso a
integridad y
usuarios no autorizados y la rplica no autorizada
confidencialidad de datos de la base de datos.
Control y registro de
No se previene un control de este tipo
entradas
Copias de seguridad y
Se debe realizar una copia diaria de la base de
recuperacin de datos
datos.
Se aconseja a usuarios autorizados, el transporte y
Recuperacin ante
posterior resguardo de la base de datos en lugares
catstrofes
fsicos externos al lugar de procesamiento.
Tabla 9.15. Procedimientos relacionados con medidas de seguridad.

Las medidas o procedimientos relacionados con la operacin del sistema,
no son especiales o no requieren tratamiento especial.
9.3 DISEO DE LA ARQUITECTURA DE SOPORTE (DSI 2)
En esta actividad se lleva a cabo la especificacin de la arquitectura de

soporte, que comprende el diseo de los subsistemas de soporte identificados
en la actividad DSI 1, y la determinacin de los mecanismos genricos de
diseo. Estos ltimos sirven de gua en la utilizacin de diferentes estilos de
diseo, tanto en el mbito global del sistema de informacin, como en el diseo
de detalle. Debido a las caractersticas de la herramienta seleccionada para el
desarrollo de los mdulos del sistema de informacin, no resulta necesaria para
este caso en particular, llevar a cabo las tareas de esta actividad.
9.4 DISEO DE LA ARQUITECTURA DE MDULOS DEL SISTEMA (DSI 5)
El objetivo de esta actividad es definir los mdulos del sistema de

informacin, y la manera en que van a interactuar unos con otros, intentando
que cada mdulo trate total o parcialmente un proceso especfico y tenga una
interfaz sencilla.
Para cada uno de los subsistemas especficos, identificados en la tarea DSI
1.5, se disea la estructura modular de los procesos que lo integran tomando
como punto de partida los mdulos obtenidos en la tarea validacin de los
modelos ASI 9.3 y del catlogo de requisitos. Dicha estructura se ir
completando con los mdulos que vayan apareciendo como consecuencia de
los diseos de interfaz, as como de la optimizacin del diseo fsico de datos.
186

9.4.1 DISEO DE MDULOS DEL SISTEMA (DSI 5.1)
El objetivo de esta tarea es realizar una descomposicin modular de los

subsistemas especficos identificados en la tarea DSI 1.5. En esta tarea
tambin se disean mdulos de consulta, generalmente no especificados en el
modelo de procesos, aunque s en el catlogo de requisitos.
Como paso previo al diseo de la estructura modular del sistema, se
identifican los procesos que se van a implementar en cada subsistema
especfico. Para cada uno de ellos se establece el tipo de implementacin (por
lotes o en lnea) y el tipo de iniciacin (bajo peticin o por el sistema).
A su vez se analiza el alcance y las caractersticas propias de cada
proceso con el fin de determinar qu parte gestiona el acceso a la informacin
soportada en bases de datos, qu parte se encarga de integrar las
funcionalidades necesarias para cumplir las reglas de negocio y en caso de
tratamiento en lnea qu parte gestiona la presentacin de la informacin en los
dispositivos de interfaz con los que el usuario va a interactuar.
Con respecto a los mdulos, conviene hacer las siguientes consideraciones
acerca del diseo y su relacin con la herramienta de desarrollo. Debido a que
dicha herramienta (seleccionada para construir la aplicacin) no es un lenguaje
de programacin, sino ms bien un entorno de desarrollo, permite mediante
sus elementos constitutivos ir creando los distintos componentes.
9.4.2 DISEO DE COMUNICACIN ENTRE MDULOS (DSI 5.2)
El objetivo de esta tarea es definir las interfaces entre los mdulos de cada
subsistema, entre subsistemas y con el resto de los sistemas, incluyendo tanto
la comunicacin del control como los datos propios del sistema, de acuerdo a la
arquitectura propuesta y a las caractersticas del entorno tecnolgico. Hay que
definir interfaces sencillas, que permitan reducir la complejidad de
comunicacin entre los distintos mdulos, especialmente aquellas relacionadas
con las comunicaciones entre subsistemas.
En el punto 9.2.5 (DSI 1.5) se exhibe el diagrama de estructura, en el que
se puede observar la relacin y el intercambio de datos entre los distintos
mdulos. En las tablas 9.4 a 9.14, se detalla las especificaciones de cada uno
de estos mdulos.
9.4.3 REVISIN DE LA INTERFAZ DEL USUARIO (DSI 5.3)
El objetivo de esta tarea es realizar el diseo detallado de la interfaz del

usuario, tanto en pantalla como impresa, a partir de la especificacin obtenida
en el proceso de ASI, de acuerdo al entorno tecnolgico seleccionado y
considerando los estndares y directrices marcados por la instalacin.

187
Algunos elementos de salida de esta tarea, se han exhibido en el captulo

VIII; tal es el caso de los modelos de pantallas y reportes o salidas impresas.
En el punto 8.3.2 del captulo VIII, se muestran las pantallas que intervienen en
el proceso de clculo de puntos de funcin para SSBBCC.
Para dar cumplimiento a las pautas de la metodologa mtrica V3, en este
punto solamente se hace una descripcin de los distintos sectores (figura 9.3)
que componen esas pantallas para que el lector tenga conocimiento de las
especificaciones tomadas en cuentas al momento de realizar el diseo de las
mismas.
Nombre de
Aplicacin y
Proceso
Ttulo del Proceso
rea de
Datos
Operacio
nes con
Reg.
Figura 9.3. Formato de pantalla.

Con respecto a las salidas impresas, en el punto 8.7.5 del captulo VIII, se
han expuesto sendos reportes o salidas impresas, cuyo formato se especifica a
continuacin (figura 9.4).
188

Nombre de
Aplicacin y
Proceso
Ttulo del Proceso
Figura 9.4. Formato de salida impresa.

Cada uno de los productos que solicita mtrica v3 para este punto, se
exhibe en la tabla 9.16.
Producto
Formatos individuales de interfaz de
pantalla.
Catlogos de controles y elementos
de diseo de interfaz de pantalla.
Modelo de navegacin de interfaz de
pantallas.
Formatos de impresin.
Prototipo de interfaz de pantalla.
Prototipo de interfaz de impresin.
Ubicacin en el presente trabajo

Captulo VIII figuras de 8.4 a 8.16 y de
8.18 a 8.23; tabla 8.6
Captulo VIII tabla 8.6

Captulo VIII figura 8.24
Captulo VIII figuras 8.25 y 8.26
Captulo IX figura 9.2
Captulo IX figura 9.3
Tabla 9.16. Productos ya desarrollados y exigidos por mtrica v3

9.5 DISEO FSICO DE DATOS (DSI 6)
En esta actividad se define la estructura fsica de los datos que utilizar el

sistema a partir del modelo lgico de datos normalizado, de manera que
teniendo presentes las caractersticas especficas del sistema de gestin de
datos concreto a utilizar, los requisitos establecidos para el sistema de
informacin, las particularidades del entorno tecnolgico, se consiga una mayor
eficiencia en el tratamiento de los datos.

189
Tambin se analizan los caminos de accesos a los datos utilizados por

cada mdulo del sistema en consultas y actualizaciones, con el fin de mejorar
los tiempos de respuestas y optimizar los recursos de mquina.
9.5.1 DISEO DEL MODELO FSICO DE DATOS (DSI 6.1)
El objetivo de esta tarea es realizar el diseo del modelo fsico de datos a

partir de un modelo lgico normalizado. En el anexo II.B, se muestra un
esquema de la relacin entre tablas de la base de datos relacional. La
traduccin de entidades a tablas de la base de datos se exhibe en la tabla
C.II.2 del anexo II.C. Luego, se brinda un detalle de los atributos o campos de
las tablas, campos claves, forneos e indexacin (tabla 9.17). El esquema del
anexo II.B, del anexo II.C y la tabla 9.17, conforman el diseo fsico de la
aplicacin a construir.
190

Entidad
Nombre de Tabla de la
Base de Datos
Conceptos de
transacciones
lgicas
Tabla_con_identificados
Transacciones
lgicas
Tabla_dtl_identificadas
Tipo de
elemento de
entrada
Tabla_elementos_entrada
Tipo de
elemento de
salida
Entradas de
transacciones
lgicas
Tipo
Long.
Clave
Primaria
Clave
Fornea
Indexado
Entero largo
No
Si
Si (con
duplicados)
Texto
Memo
50
-
No
No
No
No
No
No
IDETRA
Entero largo
Si
No
Si (sin
duplicados)
NUMMED
DESTRA
Entero largo
Texto
4
50
No
No
Si
No
No
No
TIELEN
Texto
Si
No
Si (sin
duplicados)
DEELEN
Texto
50
No
No
No
Si (sin
duplicados)
Atributo
IDETRA
NOMCON
BREDES
Tabla_elementos_salida
Tabla_ent_identificadas
Mediciones
Tabla_mediciones
Salidas de
transacciones
lgicas
Tabla_sal_identificadas
TIELSA
Texto
Si
No
DEELSA
Texto
50
No
No
No
IDETRA
Entero largo
No
Si
Si (con
duplicados)
ATRREL
TIELEN
BREDES
Texto
Texto
Memo
30
50
-
No
No
No
No
No
No
No
No
No
NUMMED
Entero largo
Si
FECMED
NOMPRO
NOMAPL
NOMCLI
CDI
EUF
FAI
FAO
FCD
PMU
RAP
REN
REU
UPR
CATRLO
CANENT
CANSAL
CANCON
PFSBC
ACT
PFASBC
PRODUC
TIEMPO
COSTO
ESFUER
Fecha/Hora
Texto
Texto
Texto
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Doble
Doble
Doble
Doble
Doble
Moneda
Entero largo
IDETRA
Entero largo
No
Si
Texto
Texto
Memo
Doble
Doble
Doble
Doble
Doble
Moneda
Entero largo
Texto
Texto
Entero largo
50
50
8
8
8
8
8
8
4
3
200
4
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Si
No
No
ATRREL
TIELSA
BREDES
VACAEN
VACASA
Parmetros
VACACO
Tabla_valores_cal
para
VALCO1
VALCO2
mediciones
COSHOR
HORSEM
Descripcin de
CODFAC
Tabla_valores_factor_ajust
caractersticas
DESCRI
e
VAFAAJ
tcnicas de la
Ajustes de
CODFAC
Tabla-ajustes_complejidad
complejidad
DESCRI
tcnica
8
100
100
100
4
4
4
4
4
4
4
4
4
4
4
4
4
4
8
8
8
8
8
8
4
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Texto
Si
Texto
50
No
No
No
Si (sin
duplicados)
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
No
Si (con
duplicados)
No
No
No
No
No
No
No
No
No
No
No
No
No
Si (sin
duplicados)
No
Tabla 9.17. Descripcin de tablas del modelo fsico de datos.

191
9.5.2 ESPECIFICACIN DE LOS CAMINOS DE ACCESO A LOS DATOS

(DSI 6.2)
El objetivo de esta tarea es determinar el camino de acceso a los datos

persistentes del sistema, utilizados por los principales mdulos y de acuerdo al
modelo fsico, con el fin de optimizar el rendimiento de los gestores de datos o
sistemas de archivos y el consumo de recursos, as como disminuir el tiempo
de respuesta.
La informacin que se obtiene de los caminos de accesos a datos sirve
para identificar accesos costosos o redundantes. Si bien esta informacin es
importante en el marco de un desarrollo a gran escala o en una organizacin
donde los tiempos de respuesta son crticos, para la aplicacin que se
construye, no tiene mucha significacin debido a que se trata de un trabajo
acadmico y no tiene mayores exigencias por parte del usuario final.
9.5.3 OPTIMIZACIN DEL MODELO FSICO DE DATOS (DSI 6.3)
En esta tarea se optimiza el diseo fsico de datos con el objeto de mejorar

el tiempo de respuesta de acceso a los datos persistentes, hacer una adecuada
utilizacin de los recursos del sistema y en consecuencia garantizar que el
diseo satisface las necesidades del tratamiento establecidas para el sistema
de informacin en cuanto a que se ajusta a los requisitos de rendimiento
exigidos.
Para este punto cabe la misma justificacin del punto anterior (9.5.2)
acerca de los tiempos de respuesta.
9.5.4 ESPECIFICACIN DE LA DISTRIBUCIN DE DATOS (DSI 6.4)
En esta tarea se determina el modelo de distribucin de datos, teniendo en

cuenta los requisitos de diseo establecidos. Se establece la ubicacin de los
gestores de bases de datos o de los ficheros, as como los distintos elementos
de la estructura fsica de datos, en los nodos correspondientes de acuerdo al
particionamiento fsico especificado en la actividad DSI 1.
9.6 VERIFICACIN Y ACEPTACIN DE LA ARQUITECTURA DEL SISTEMA
(DSI 7)
El objetivo de esta actividad es garantizar la calidad de las especificaciones

del diseo del sistema de informacin y la viabilidad del mismo, como paso
previo a la generacin de especificaciones de construccin.
En la tabla 9.16, se muestran los productos desarrollados en el marco de la
metodologa mtrica V3. En la tabla 9.17, se exhibe el diseo fsico de los
datos, la estructura y campos claves. Debido a que se trata de un desarrollo
pequeo y personalizado, el desarrollo de este punto se obvia para el presente
trabajo.
192

9.7 GENERACIN DE ESPECIFICACIONES DE CONSTRUCCIN (DSI 8)
En esta actividad se generan las especificaciones de construccin a partir

del diseo detallado.
Estas especificaciones definen la construccin del sistema de informacin a
partir de las unidades bsicas de construccin (o componentes) entendiendo
como tales unidades independientes y coherentes de construccin y ejecucin,
que se corresponden con un empaquetamiento fsico de los elementos del
diseo de detalle.
9.7.1 ESPECIFICACIN DEL ENTORNO DE CONSTRUCCIN (DSI 8.1)
El objetivo de esta tarea es definir el entorno necesario para la construccin

de los componentes del sistema de informacin. Los conceptos que intervienen
en la especificacin del entorno se muestran en la tabla 9.18.
Concepto
Entorno tecnolgico
Herramienta de
construccin
Restricciones tcnicas
del entorno
Requisitos de seguridad
del entorno de desarrollo
Especificacin
El sistema informtico donde se desarrolla la
aplicacin ha sido descrito en la tabla 8.1 del
captulo VIII. Para este desarrollo en particular
coincide el entorno tecnolgico de desarrollo con el
de operacin del sistema.
Entorno de desarrollo para base de datos
relacional con facilidad de generacin de interfaces
grficas del tipo GUI (graphic user interface).
Posibilidad de construir tablas, relaciones entre
tablas, consultas especficas, formulario de ingreso
y consultas de
datos, reportes y elementos
especiales o frmulas mediante cdigo.
No presenta
Back-up diario de las versiones generadas, hasta

tener la versin definitiva.
Tabla 9.18. Especificacin del entorno tecnolgico para la construccin del

sistema de informacin.
9.7.2 DEFINICIN DE
CONSTRUCCIN (DSI 8.2)
COMPONENTES
SUBSISTEMAS
DE
La especificacin de los subsistemas de construccin se realiza a partir de

los subsistemas de diseo con una continuidad directa, permitindose a su vez
un mayor nivel de detalle agrupando componentes en subsistemas dentro de
un subsistema de construccin.
Una vez definidos los componentes o procesos primitivos en el diagrama
de estructura (punto 9.2.5, figura 9.2, tablas 9.4 a la 9.14 y anexo II.D), se
193
considera como elementos a partir de los cuales se puede construir cada uno
de los mdulos del sistema de informacin.
9.7.3 ELABORACIN DE ESPECIFICACIONES DE CONSTRUCCIN (DSI
8.3)
Se realiza una especificacin detallada de cada componente en

pseudocdigo o lenguaje natural completando la informacin que se considere
necesaria segn el entorno tecnolgico.
Este paso resulta innecesario dadas las caractersticas de la herramienta
de construccin, en el punto 9.7.2 (DSI 8.2), se han definido los elementos que
se encuentran disponibles para acometer la construccin del sistema de
informacin.
9.7.4 ELABORACIN DE ESPECIFICACIONES DEL MODELO FSICO DE
DATOS (DSI 8.4)
En esta tarea se generan especificaciones necesarias para la definicin y

creacin de elementos del modelo fsico de datos, mediante el lenguaje de
definicin de datos del gestor de bases de datos o sistema de archivos,
teniendo en cuenta el entorno tecnolgico, las normas estndares de la
organizacin y las caractersticas intrnsecas del gestor. El anexo II.B muestra
un diagrama propio de la herramienta de desarrollo de parte del diseo fsico
de datos, correspondiente a las relaciones que permiten que los datos puedan
interactuar entre s.
9.8 DISEO DE LA MIGRACIN Y CARGA INICIAL DE DATOS (DSI 9)
Esta actividad se lleva a cabo cuando es necesaria una carga inicial de

informacin o una migracin de datos de otros sistemas, cuyo alcance y
estrategias a seguir se habrn definido previamente. Debido a las
particularidades del desarrollo, esta actividad es pasada por alto. Solamente se
ingresan los datos de los proyectos seleccionados, tal como se lo ha
especificado en el plan de pruebas (punto 8.9.2 del captulo VIII).
9.9 ESPECIFICACIN TCNICA DEL PLAN DE PRUEBAS (DSI 10)
En esta actividad se realiza una especificacin en detalle del plan de

pruebas del sistema de informacin para cada uno de los niveles de prueba
establecidos en el ASI 10.
9.9.1 ESPECIFICACIN DEL ENTORNO DE PRUEBAS (DSI 10.1)
El objetivo de esta tarea es la especificacin detallada y completa del

entorno necesario para la realizacin de las pruebas: unitarias, de integracin,
de implantacin y de aceptacin. Se propone en la tabla 9.19 los conceptos del
entorno tecnolgico de las pruebas.
194

Concepto
Especificacin
del
entorno
tecnolgico para pruebas
El sistema informtico donde se
desarrolla la aplicacin ha sido
descrito en la tabla 8.1 del captulo
VIII. Para este desarrollo en particular
coincide el entorno tecnolgico de
desarrollo con el de pruebas del
sistema. Se realiza una rplica de la
Entorno tecnolgico
base de datos para someterla a los
diferentes tests especificados en las
pruebas. Con respecto a los datos, se
cuentan con dos trabajos de tesis de
desarrollo de SSBBCC M. Ing. del
ITBA, de la Carrera de Magster en
Ingeniera del Software.
No existen ya que al contar con una
rplica de la base de datos, esta
Restricciones tcnicas del entorno
incluye a todos los elementos
constitutivos y que sern sometidos a
las pruebas.
No existen ya que al contar con una
rplica de la base de datos, esta
Requisitos de operacin y seguridad
incluye a todos los elementos
en pruebas
constitutivos y que sern sometidos a
las pruebas.
Tabla 9.19. Especificacin del entorno tecnolgico de pruebas.

9.9.2 ESPECIFICACIN TCNICA DE NIVELES DE PRUEBAS (DSI 10.2)
El objetivo de esta tarea es el diseo detallado de los distintos niveles de

prueba, especificados en el plan de pruebas elaborado en el proceso de ASI.
De acuerdo a la arquitectura propuesta y a las caractersticas intrnsecas
del diseo del sistema de informacin, se definen en detalle las distintas
verificaciones a realizar sobre el sistema, conforme a los niveles de prueba
establecidos, teniendo en cuenta que una verificacin puede ser aplicable a un
componente o a un grupo de componentes.
Para el caso particular del desarrollo de la herramienta de software de
clculo de puntos de funcin en SSBBCC, se especifican tres criterios para
realizar las pruebas unitarias:
i)
Ingreso de Datos: El objetivo de este tipo de prueba es detectar

datos errneos al momento de ingresarlos al sistema o a la base de
datos. Un ejemplo de este tipo pueden ser fechas invlidas o
campos numricos que se encuentran fuera de los lmites

195
permitidos. En la figura 9.5, se muestra un ejemplo de validacin que

se realiza en el momento de crear las tablas, pero que se refleja en
la carga de datos. Esta validacin se traslada al formulario de
ingreso de datos, mediante el cual, se incorporan datos en dicha
tabla. En el caso especfico de las fechas una fecha no vlida puede
ser 30 de febrero o 31 de Noviembre o un mes con un valor mayor a
12. En estos casos se espera que el sistema emita un mensaje de
error.
Mensaje de Error
al Validar Fecha
Figura 9.5. Ejemplo de una validacin de un campo (o atributo) fecha.

ii)
196
Operaciones con Registros: Se verifican las operaciones

caractersticas que se realizan con registros. Esas operaciones son
altas, bajas o modificaciones (agregar, borrar o modificar). En el
caso de altas o modificaciones no existen mayores complicaciones;
sin embargo, al hacer una operacin de baja (o eliminacin) de
registro, el sistema debe tener en cuenta que no se pierda la
integridad referencial. En estos casos, el sistema tambin debe
emitir un mensaje de error o advertencia. Un ejemplo de este tipo de
validaciones se muestra en la figura 9.6.

Mensaje de ruptura
de integridad
referencial
Figura 9.6. Ejemplo de mensaje de advertencia de ruptura de integridad

referencial.
iii)
Funciones de los Botones: El objetivo de este tipo de control es

verificar si los botones responden a los eventos que representan en
el marco de un formulario determinado. Al hacer clic o al apuntar un
botn determinado con el puntero del ratn, el sistema se comporta
de una manera determinada. Si ese comportamiento no es el
esperado, entonces existe un error en la codificacin del evento (o
del botn).
En la fase de Construccin del Sistema de Informacin (CSI), se ejecutan

las pruebas cuyo detalle se muestra en la tabla 9.20.

197
Identificac.
del Caso de
Prueba
Criterios Para la Realizacin de

las Pruebas
Proceso
Ingreso Operacion Funciones

de Datos es C/Reg. de Botones
CP001
Consulta de Factores
No-Aplica
de Ajustes de
Complejidad Tcnica
No-Aplica
Aplica
CP002
No-Aplica
de Ajustes de
Complejidad Tcnica
No-Aplica
Aplica
CP003
No-Aplica
de Ajustes de
Complejidad Tcnica
No-Aplica
Aplica
CP004
Ingreso de Datos del

Proyecto
(ABM_Proyecto)
Aplica
No-Aplica
No-Aplica
CP005

Proyecto
(ABM_Proyecto)
No-Aplica
Aplica
No-Aplica
CP006

Proyecto
(ABM_Proyecto)
Aplica
No-Aplica
No-Aplica
CP007
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
Aplica
No-Aplica
No-Aplica
CP008
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
No-Aplica
Aplica
No-Aplica
Aplica
No-Aplica
No-Aplica
Aplica
No-Aplica
No-Aplica
No-Aplica
Aplica
No-Aplica
Aplica
No-Aplica
No-Aplica
CP009
CP010
CP011
CP012
CP013
CP014
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
Resumen de
Resultados de
Mediciones
(consulta)
Resumen de
Resultados de
Mediciones
(consulta)
Detalle de
Resultados de
Mediciones
(consulta)
Detalle de
Resultados de
Mediciones
(consulta)
No-Aplica
Consulta de Valores
No-Aplica
de Ajuste de
Complejidad Tcnica
Aplica
No-Aplica
No-Aplica
Aplica
Entradas Necesarias
Salidas Esperadas
Se pulsa el botn de avance El sistema debe mostrar un

de registro cuando se est
mensaje impidiendo el
posicionado en el ltimo
avance hacia otro registro
registro
inexistente
Se pulsa el botn de retroceso El sistema debe mostrar un
de registro cuando se est
mensaje impidiendo el
posicionado en el registro
retroceco hacia otro registro
nmero 1
inexistente
El sistema debe recorrer una
tabla y permitir el avance,
Se pulsan los botones de
retroceso, ir al principio e ir
avance, retroceso, ir al primero
al final, segn la secuencia
e ir al ltimo registro
de pulsacin de botones
ingresada.
Se ingresa una fecha invlida
(por ejemplo un mes con un El sistema debe mostrar un
valor mayor a 12) en el
mensaje de error (fecha
formulario de ABM de
erronea)
proyectos
El sistema debe mostrar un
Se tiene en pantalla un registro
mensaje de advertencia de
determinado correspondiente a
que se quiere eliminar un
una aplicacin que se ha
registro que est
medido, y se quiere eliminarla
relacionado.
EL sistema debe permitir el
Se ingresan los datos de un
ingreso de los datos del
proyecto, en el orden que lo
proyecto en forma normal y
solicita la pantalla de ingreso
sin ningn inconveniente.
Debido a que el valor no
debe ser mayor a cinco, el
Se ingresa un valor mayor a 5
sistema emite un mensaje de
error
mensaje de error, debido a
Se ingresa un registro con un
que el cdigo de factor de
cdigo de factor de ajuste de
ajuste de estar asociado a
una caracterstica invlido (por
uno de los factores de
ejemplo 'XXX')
ajustes definidos en la tabla
para tales fines
Se modifica el valor de alguna
de las caractersticas tcnicas
de la aplicacin
Valor de caracterstica
tcnica de la aplicacin
modificado.
El sistema no debe permitir

Se ingresa un valor (cualquiera
el cambio o la modificacin
sea) en algunos de los
en el valor mostrado en la
casilleros de la pantalla
pantalla
Se selecciona desde el menu
El sistema debe mostrar en
la opcin de mostrar el
forma de columnas los
resumen de los resultados de
resultados de las mediciones
las mediciones
El sistema no debe permitir
Se ingresa un valor (cualquiera
el cambio o la modificacin
sea) en algunos de los
en el valor mostrado en la
casilleros de la pantalla
pantalla
Se selecciona desde el menu El sistema debe mostrar en
la opcin de mostrar en detalle detalle los resultados de las
variables de estimacin
el resultado de las mediciones,
luego se elecciona un proyecto correspondientes al proyecto
de una lista
seleccionado
Se pulsa algn botn de
avance o retroceso de
registros para ver si el detalle
del formulario coincide con el
encabezamiento
El encabezamiento debe
coincidir con el detalle del
fornulario
Tabla 9.20. Detalle de pruebas unitarias a desarrollar en la fase de CSI.
198

Identificac.
del Caso de
Prueba
CP015
Criterios Para la Realizacin de

Proceso
Ingreso Operacion Funciones

de Datos es C/Reg. de Botones
Registro de Entradas
No-Aplica
de Transacciones
Lgicas
No-Aplica
Aplica
CP016
Registro de Salidas
de Transacciones
Lgicas
No-Aplica
No-Aplica
Aplica
CP017
Registro de
Conceptos de
Transacciones
Lgicas
No-Aplica
No-Aplica
Aplica
CP018
ABM de
Transacciones
Lgicas
No-Aplica
No-Aplica
Aplica
CP019
ABM de
Transacciones
Lgicas
Aplica
No-Aplica
No-Aplica
CP020
ABM de
Transacciones
Lgicas
Aplica
No-Aplica
No-Aplica
CP021
ABM de
Transacciones
Lgicas
Aplica
No-Aplica
No-Aplica
CP022
Actualizacin de
Parmetros de
Clculo
CP023
Actualizacin de
Parmetros de
Clculo
CP024
Actualizacin de
Parmetros de
Clculo
CP025
Actualizacin de
Parmetros de
Clculo
CP026
CP027
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
Aplica
Aplica
Aplica
No-Aplica
No-Aplica
No-Aplica
Entradas Necesarias
Salidas Esperadas
Se seleccionan los datos para

El formulario debe mostrar el
realizar la bsqueda de una
proyecto y la(s)
transaccin lgica
transaccin(es) lgic(s)
perteneciente a un proyecto en
asociada(s) al mismo
particular
proyecto y la(s)
transaccin lgica
particular
proyecto y la(s)
transaccin lgica
particular
El sistema debe informar que
Se ingresa un nmero de
ese nmero de proyecto
proyecto que an no ha sido
corresponde a uno
ocupado
inexistente
El sistema debe impedir la
Se intenta alterar los valores
modificacin de cualquier
de los atributos del proyecto atributo del proyecto en esta
pantalla.
Se intenta alterar el nmero
del proyecto en el
El sistema debe impedir la
subformulario de ingreso de
modificacin de este valor.
Se selecciona un proyecto y
El sistema debe permitir el
luego en el subformulario se
ingreso de la transaccin
ingresa la descripcin de una
lgica sin ningn
nueva transaccin lgica
inconveniente.
No-Aplica
Se ingresan valores invlidos para

los parmetros de clculo. Para
mensaje en el que indique
entradas se ingresan cinco
que se trata de un valor
valores invlidos (-3, 0, 0.00040,
invlido
1 y 5)
No-Aplica
Se ingresan valores invlidos para El sistema debe mostrar un

salidas se ingresan cinco valores
invlidos (-6, 0, 0.00555, 1 y 5)
invlido
No-Aplica
Se ingresan valores invlidos para

conceptos se ingresan cinco
valores invlidos (-2, 0, 0.00699,
invlido
3 y 16)
Aplica
No-Aplica
No-Aplica
Se ingresan valores vlidos para

conceptos se ingresan tres
valores vlidos (0.700, 1.555 y
1.870)
Aplica
No-Aplica
No-Aplica
Se ingresan en todos los casos

tres tipos de valores: (-2, 0 y 6)

invlido
Aplica
No-Aplica
No-Aplica
Se ingresan un valor entre 1 y 5 y

el sistema debe permitir su
incorporacin
El sistema debe aceptar el

valor ingresado.
El sistema debe permitir el

ingreso de estos valores sin
ningn inconveniente.
Tabla 9.20. Detalle de pruebas unitarias a desarrollar en la fase de CSI

(continuacin).
Para las pruebas de integracin, tal como se ha hecho referencia en la
tabla 8.10 del captulo VIII, se siguen los lineamientos de la tcnica incremental
ascendente. Si bien es cierto, la tcnica necesita de programas auxiliares
[Casal05], en este caso particular se prescinde de los mismos. En la tabla 9.21
199
y en la figura 9.7, se muestran las referencias a mdulos (mens o submens)

que conducen a los mdulos especficos.
Cdigo del Mdulo
M001
M002
M003
M004
M005
M006
M007
M008
M009
M010
M011
M012
M013
M014
M015
M016
M017
M018
M019
Descripcin del Mdulo

Pantalla de inicio de la aplicacin
Men de ingreso de datos de la aplicacin
Consulta de valores y resultados
Reportes y listados
Parmetros de las mediciones
Formulario de ABM de datos del proyecto
Formulario de ABM de valores de transacciones lgicas
Formulario de ABM de entradas de transacciones
lgicas
Formulario de ABM de salidas de transacciones lgicas
Formulario de ABM de conceptos de transacciones
lgicas
Formulario de ingreso de ajustes de complejidad tcnica
Formulario de resumen de valores (resultados de
mediciones)
Formulario de detalle de valores (resultado de
mediciones)
Reporte de lista de proyectos
Reporte de lista de proyectos resultados
Formulario de actualizar parmetros de clculo
Formulario de ABM de Valores de Caractersticas
Tcnicas
Formulario de consulta de factores de ajuste
Formulario de consulta de valores de ACT
Tabla 9.21. Codificacin de los mdulos y de los submens.

En la figura 9.7, se exhibe la distribucin de los mdulos en la aplicacin.
La distribucin grfica permitir en la etapa de construccin realizar una prueba
en la cual se determine un recorrido o camino lgico que debe seguir una
prueba en particular.
200

M006
M007
M008
M002
M009
M010
M011
M012
M013
M001
M003
M018
M019
M014
M004
M015
M016
M005
M017
Figura 9.7. Distribucin de los mdulos y ordenamiento lgico.

Con el fin de comprobar los diferentes caminos lgicos que sigue la
aplicacin, se definen los siguientes recorridos en la tabla 9.22.
201
Identificac. del
Caso de Prueba
CP028
CP029
CP030
Camino Lgico
Entradas Necesarias
Salidas Esperadas
El sistema debe conducir al mdulo

Desde el mdulo M001, se llama al
de ingreso de valores de
M001, M002,
M002, luego al M007. Luego al salir
transacciones lgicas. Luego debe
M007,M002,M001 del mdulo M007, este debe devolver
devolver el control al mdulo que lo
el control al M002, y este al M001.
convoc.
de ingreso de conceptos de
M001, M002, M010, M002, luego al M010. Luego al salir
transacciones lgicas. Luego debe
M002, M001
del mdulo M010, este debe devolver
convoc.
de ingreso de mostrar en detalle
resultados de mediciones. Luego
M003, M001
debe devolver el control al mdulo
que lo convoc.
CP031

M004, M001
CP032

de de actualizar valores de ajustes de
complejidad tcnica. Luego debe
M005, M001
convoc.

de reporte de lista de proyectos.
Luego debe devolver el control al
mdulo que lo convoc.
Tabla 9.22. Recorrido lgico de la aplicacin.

En las pruebas del sistema, se comprueban los puntos especificados en la
tabla 8.13 del captulo VIII. Para llevar a cabo las pruebas especificadas en la
tabla 8.13, se toman en cuenta todos los mdulos. La tabla 9.23, muestra una
especificacin de los casos de prueba del sistema.
202

Identificac.
del Caso de
Prueba
CP033
CP034
CP035
CP036
CP037
CP038
CP039
CP040
CP041
Proceso
Consulta de Factores de Ajustes de
Complejidad Tcnica
Ingreso de Datos del Proyecto
(ABM_Proyecto)
Ingreso de Caractersticas Tcnicas de la
Aplicacin
Resumen de Resultados de Mediciones
(consulta)
Detalle de Resultados de Mediciones
(consulta)
Consulta de Valores de Ajuste de
Complejidad Tcnica
Registro de Entradas de Transacciones
Lgicas
Registro de Salidas de Transacciones
Lgicas
Registro de Conceptos de Transacciones
Lgicas
Tiempo de respuesta
No debe superar los 2 (dos) segundos
CP042
ABM de Transacciones Lgicas
CP043
Actualizacin de Parmetros de Clculo
CP044

Aplicacin
Tabla 9.23. Especificacin de los casos de prueba del sistema.

Para el caso de las pruebas de aceptacin, se toma como casos de
prueba a dos trabajos de tesistas de la carrera de Magster en Ingeniera del
Software del ITBA. Las razones por las cuales se han seleccionado estos
trabajos han quedado manifestadas en el punto 8.9.2 del captulo VIII.
Se considerarn los datos de las estimaciones de sendos trabajos y se
compararn con los valores reales que se han empleado para el desarrollo de
los mismos.
9.9.3 REVISIN DE LA PLANIFICACIN DE LAS PRUEBAS (DSI 10.3)
En esta tarea se complementa y especifica la planificacin de las pruebas

determinando los distintos perfiles implicados en la preparacin y ejecucin de
las pruebas y en la evaluacin de los resultados, as como el tiempo estimado
para la realizacin de cada uno de los niveles de prueba de acuerdo a la
estrategia de integracin establecida.
La preparacin, ejecucin de las pruebas y evaluacin de los resultados
estarn a cargo del autor de la tesis. Los tiempos estimados para la realizacin
de las pruebas, han sido incluidos en la planificacin prevista para la fase de
diseo del sistema de informacin (DSI). El plan resumido se exhibe en la
figura 7.1 del captulo VII.

203
9.10 ESTABLECIMIENTO DE LOS REQUISITOS DE IMPLANTACIN (DSI

11)
En esta actividad se completa el catlogo de requisitos con aquellos

relacionados con la documentacin que el usuario requiere para operar con el
nuevo sistema, y los relativos a la propia implantacin del sistema y de su
entorno de operacin. La incorporacin de estos requisitos permite ir
preparando, en los procesos de CSI e IAS los medios y los recursos necesarios
para que los usuarios finales y de operacin sean capaces utilizar el sistema en
forma satisfactoria. En el caso de los requisitos de implantacin no existen
mayores exigencias debido a la envergadura de la aplicacin.
9.11PRESENTACIN Y APROBACIN DEL DISEO DEL SISTEMA DE
INFORMACIN (DSI 12)
En esta tarea se realiza la presentacin del diseo del sistema de

informacin al Comit encargado de evaluarlo.
204

CAPTULO X
CONSTRUCCIN
DEL
SISTEMA
DE
INFORMACIN
(CSI)
CAPTULO X
CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI)
10.1 INTRODUCCIN
En este captulo se desarrollan las actividades de construccin del sistema

de informacin (CSI). El objetivo de este proceso es generar el cdigo de los
componentes del sistema de informacin. Adems se realizan las pruebas
unitarias y las pruebas de integracin del sistema diseadas en la fase DSI.
10.2 PREPARACIN DEL ENTORNO DE GENERACIN Y CONSTRUCCIN
(CSI.1)
El objetivo de esta tarea es asegurar la disponibilidad de todos los medios

y facilidades para que se pueda llevar a cabo la construccin del sistema de
informacin. Entre otros medios cabe destacar la preparacin de los puestos de
trabajo, equipos fsicos y lgicos, gestores de bases de datos, bibliotecas de
programas, etc.
Con respecto a la herramienta seleccionada para llevar a cabo el desarrollo
o la codificacin de los componentes del sistema software, tiene las facilidades
de permitir la creacin automtica de elementos constitutivos de la base de
datos. Estos elementos son:
i) Tablas: son las tablas derivadas de entidades de los modelos lgico y
fsico de datos, cuya correspondencia ha sido presentada en el anexo II.C.
ii) Consultas: son las tablas relacionadas en diferentes vistas para facilitar
la recuperacin de informacin en diferentes formatos y de manera tal que
involucre a ms de una tabla.
iii) Formularios: son elementos que permiten el ingreso de datos al sistema
por un lado y realizar consultas de datos por otro.
iv) Reportes: son elementos que dan un formato imprimible a los datos de
salida.
v) Macros: permiten realizar operaciones especiales con los elementos
descritos.
10.2.1 IMPLANTACIN DE LA BASE DE DATOS FSICA O ARCHIVOS
(CSI.1.1)
El elemento fsico que contiene los datos de la aplicacin lo constituye cada

una de las tablas de la base de datos. El entorno de desarrollo permite la
creacin de dichas tablas de la base de datos con las especificaciones de
diseo fsico de datos. Se debe incorporar:
Captulo X Construccin del
Sistema de Informacin (CSI)
207
Nombre de campo (o atributo).

Tipo de dato (del campo).
Descripcin breve.
Tamao del campo.
Formato.
Lugares o posiciones decimales.
Mscara de entrada.
Ttulo del campo (nombre con el que se lo describe en la entrada de
datos predefinida).
Valor predeterminado.
Regla de validacin
Texto de validacin (texto que aparece en la ventada cuando no se
cumple la regla de validacin).
Requerido (si o no).
Indexado (si o no).
Cabe aclarar que no todos los tems son obligatorios. A continuacin en la

figura 10.1, se muestra un ejemplo de este tipo de interfaz que permite el
ingreso de las caractersticas de las tablas de la base de datos. Esta actividad
se repite para todas las tablas definidas en el anexo II.C.
Figura 10.1. Ejemplo de interfaz de ingreso de datos de construccin de tablas

de la base de datos.
Otro aspecto a tener en cuenta en la construccin de la base de datos
fsica es la relacin existente entre las tablas. En el anexo II.B, se muestra un
diseo de la disposicin de cada una de estas, los campos que son claves y
forman parte de las relaciones y el tipo de relacin propiamente dicho.
208

10.2.2 PREPARACIN DEL ENTORNO DE CONSTRUCCIN (CSI 1.2)
En esta actividad se prepara el entorno para la construccin o codificacin

de los componentes de la base de datos. Para la construccin de los mdulos
se cuenta con el entorno especificado en la tabla 8.1 del captulo VIII.
10.3 GENERACIN DEL
PROCEDIMIENTOS (CSI 2)
CDIGO
DE
LOS
COMPONENTES
El objetivo de esta actividad es la codificacin de los componentes del

sistema de informacin, a partir de las especificaciones de construccin
obtenidas en el proceso DSI, as como los procedimientos de operacin y
seguridad establecidos en el mismo.
En paralelo con esta actividad se desarrollan las actividades relacionadas
con las pruebas unitarias y de integracin del sistema de informacin.
10.3.1 GENERACIN DEL CDIGO DE COMPONENTES (CSI 2.1)
En esta tarea se genera el cdigo de los componentes del sistema de

informacin, identificados en las tareas de DSI.
Una vez que se han generado las tablas de la base de datos, se
construyen las relaciones que tienen por objeto precisamente relacionar la
informacin contenida en aquellas con el fin de presentar formatos que
cumplan con las especificaciones de diseo.
La generacin de los cdigos de componentes la realiza la herramienta de
software seleccionada para el desarrollo. Se marcan las pautas de los
elementos que se quieren desarrollar y la herramienta genera automticamente
el cdigo.
En el anexo IV, se muestra una lista del cdigo fuente generado para los
componentes desarrollados.
10.3.2 GENERACIN DEL CDIGO DE LOS PROCEDIMIENTOS DE
OPERACIN Y SEGURIDAD (CSI 2.2)
El objetivo de esta tarea es generar los procedimientos de operacin y

administracin del sistema de informacin, as como los procedimientos de
seguridad y control de acceso, necesarios para ejecutar el sistema una vez que
se haya implantado y est en produccin.
La operacin del sistema, esta es relativamente sencilla. Pro otro lado, es
preciso, contar con la informacin inicial del sistema que se quiere someter a
medicin e ingresar los datos que solicita el software. En primer lugar, como ya
se ha mencionado, se cargan datos del proyecto (nombre de proyecto, fecha
de medicin, nombre de aplicacin y nombre de cliente); por su parte, el
nmero de medicin, se genera automticamente.
209
10.4 EJECUCIN DE LAS PRUEBAS UNITARIAS (CSI 3)
En esta actividad se realizan las pruebas unitarias de cada uno de los

componentes del sistema de informacin, una vez codificados con el objeto de
comprobar que su estructura es correcta y que se ajusta a la funcionalidad
establecida.
10.4.1 PREPARACIN DEL ENTORNO DE LAS PRUEBAS UNITARIAS (CSI
3.1)
En esta tarea se preparan todos los recursos para realizar las pruebas
unitarias de cada uno de los componentes del sistema de informacin.
En la tabla 9.19 del captulo IX y tabla 8.1 del captulo VIII se han exhibido
los recursos necesarios y los que se cuenta para la realizacin de las pruebas.
En base a estas especificaciones, y otras definidas en la tabla 9.20 del
mencionado captulo, comienza la ejecucin de las pruebas unitarias.
10.4.2 REALIZACIN Y EVALUACIN DE LAS PRUEBAS UNITARIAS (CSI
3.2)
El objetivo de esta tarea es verificar el correcto funcionamiento de los

mdulos del sistema de informacin, codificados en la tarea CSI 2.2.
En el caso de las pruebas unitarias, muchas verificaciones se realizan
informalmente mientras se desarrollan o codifican los distintos mdulos que
componen el sistema de informacin. Los resultados de la ejecucin de las
pruebas unitarias, se muestran en la tabla 10.1.
Tanto para el caso de las pruebas unitarias como para las de integracin, el
responsable de la ejecucin de dichas pruebas es el tesista.
210

Identificacin
del Caso de
Prueba
Proceso
Fecha de
Ejecucin
Resultado de la
Ejecucin
CP001
Consulta de
Factores de Ajustes
de Complejidad
Tcnica
09 de Enero del
2006
Ok
CP002
Consulta de
Factores de Ajustes
de Complejidad
Tcnica
09 de Enero del
2006
Ok
CP003
Consulta de
Factores de Ajustes
de Complejidad
Tcnica
09 de Enero del
2006
Ok
CP004

09 de Enero del
Proyecto
2006
(ABM_Proyecto)
No Ok
CP005

09 de Enero del
Proyecto
2006
(ABM_Proyecto)
Ok
CP006

09 de Enero del
Proyecto
2006
(ABM_Proyecto)
Ok
CP007
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
09 de Enero del
2006
Ok
CP008
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
09 de Enero del
2006
Ok
09 de Enero del
2006
Ok
09 de Enero del
2006
Ok
09 de Enero del
2006
Ok
09 de Enero del
2006
Ok
09 de Enero del
2006
Ok
CP009
CP010
CP011
CP012
CP013
CP014
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
Resumen de
Resultados de
Mediciones
(consulta)
Resumen de
Resultados de
Mediciones
(consulta)
Detalle de
Resultados de
Mediciones
(consulta)
Detalle de
Resultados de
Mediciones
(consulta)
Consulta de Valores
de Ajuste de
09 de Enero del
Complejidad
2006
Tcnica
No Ok
CP015
Registro de
Entradas de
Transacciones
Lgicas
09 de Enero del
2006
No Ok
CP016
Registro de Salidas
de Transacciones
Lgicas
09 de Enero del
2006
No Ok
CP017
Registro de
Conceptos de
Transacciones
Lgicas
09 de Enero del
2006
No Ok
Errores
Encontrados
Nivel de
Severidad
Versin de
Correccin
Versin de
Re-testeo
La fecha no se
valida en forma
correcta
Moderado
2.0
2.1
No se actualizan
los registros del
encabezado con
respecto al detalle
del formulario
Moderado
2.0
2.1
Leve
2.0
2.1
Leve
2.0
2.1
Leve
2.0
2.1
Los ttulos no
estn
correctamente
encolumnados
Los ttulos no
estn
correctamente
encolumnados
Los ttulos no
estn
correctamente
encolumnados
Tabla 10.1. Resultados de ejecucin de las pruebas unitarias.

211
Identificacin
del Caso de
Prueba
Proceso
CP018
ABM de
Transacciones
Lgicas
CP019
Resultado de la
Ejecucin
Errores
Encontrados
Nivel de
Severidad
Versin de
Correccin
Versin de
Re-testeo
09 de Enero del
2006
No Ok
El sistema no
valida el ingreso
de un nmero de
proyecto que an
no ha sido
generado
Muy serio
2.0
2.1
ABM de
Transacciones
Lgicas
09 de Enero del
2006
Ok
CP020
ABM de
Transacciones
Lgicas
09 de Enero del
2006
Ok
CP021
ABM de
Transacciones
Lgicas
09 de Enero del
2006
Ok
CP022
Actualizacin de
Parmetros de
Clculo
09 de Enero del
2006
No Ok
Moderado
2.0
2.1
CP023
Actualizacin de
Parmetros de
Clculo
09 de Enero del
2006
No Ok
Moderado
2.0
2.1
CP024
Actualizacin de
Parmetros de
Clculo
09 de Enero del
2006
No Ok
Moderado
2.0
2.1
CP025
Actualizacin de
Parmetros de
Clculo
09 de Enero del
2006
Ok
09 de Enero del
2006
Ok
09 de Enero del
2006
Ok
CP026
CP027
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
Ingreso de
Caractersticas
Tcnicas de la
Aplicacin
Fecha de
Ejecucin
No se pueden
actualizar los
valores. El
formulario se abre
como " solo
lectura"
No se pueden
actualizar los
valores. El
formulario se abre
como " solo
lectura"
No se pueden
actualizar los
valores. El
formulario se abre
como " solo
lectura"
Tabla 10.1. Resultados de ejecucin de las pruebas unitarias (continuacin).

De todos los casos de pruebas unitarias que se han exhibido, el 67 % (18
casos) han aprobado el test. El resto, es decir los casos en los que se han
detectado errores, se han aplicado las medidas correctivas y se ha generado
una nueva versin del sistema software que cuenta ya con estas correcciones
implementadas.
10.5 EJECUCIN DE LAS PRUEBAS DE INTEGRACIN (CSI 4)
El objetivo de la ejecucin de las pruebas de integracin en verificar si los

componentes interactan correctamente, a travs de las interfaces internas y
externas y cubren las funcionalidades establecidas y se ajustan a los requisitos
especificados en las verificaciones correspondientes.
212

10.5.1 PREPARACIN
INTEGRACIN (CSI 4.1)
DEL
ENTORNO
DE
LAS
PRUEBAS
DE
El objetivo de esta tarea es asegurar la disponibilidad del entorno para la

realizacin de las pruebas de integracin del sistema. Se ha especificado en el
captulo IX el entorno para las pruebas del sistema (tabla 9.19).
10.5.2 REALIZACIN DE LAS PRUEBAS DE INTEGRACIN (CSI 4.2)
Con respecto a este tipo de pruebas, se verifica si los mens se

corresponden entre s y convocan a un proceso determinado y si devuelven el
control al que los convoc en forma correcta. Los resultados de la ejecucin de
las pruebas y tal como se ha especificado en el captulo IX, se muestran en la
tabla 10.2.
Identificac. del
Caso de Prueba
Camino Lgico
Fecha de
Ejecucin
Resultado
de la
Errores
Encontrados
Nivel de
Severidad
Versin de
Correccin
Versin de
Re-testeo
CP028
M001, M002,
M007,M002,M001
11 de Enero
del 2006
No Ok
El mdulo M002
no devuelve el
control al mdulo
M001
Moderado
2.1
2.2
CP029
M001, M002, M010,

M002, M001
11 de Enero
del 2006
No Ok
El mdulo M002
no devuelve el
control al mdulo
M001
Moderado
2.1
2.2
CP030
M001, M003, M013,

M003, M001
11 de Enero
del 2006
No Ok
El mdulo M002
no devuelve el
control al mdulo
M001
Moderado
2.1
2.2
CP031
M001, M004, M014,

M004, M001
11 de Enero
del 2006
No Ok
El mdulo M002
no devuelve el
control al mdulo
M001
Moderado
2.1
2.2
CP032
M001, M005, M017,

M005, M001
11 de Enero
del 2006
No Ok
El mdulo M002
no devuelve el
control al mdulo
M001
Moderado
2.1
2.2
Tabla 10.2. Resultados de la ejecucin de las pruebas de integracin.

10.5.3 EVALUACIN DEL
INTEGRACIN (CSI 4.3)
RESULTADO
DE
LAS
PRUEBAS
DE
En este caso, las verificaciones hechas al sistema, han dado como

resultado que una funcin del men, no responda como estaba previsto. Esto
amerit la correccin de ese mdulo para que el sistema se comportase de la
forma deseada.
10.6 EJECUCIN DE LAS PRUEBAS DE SISTEMA (CSI 5)
El objetivo de las pruebas del sistema es comprobar la integracin del

sistema de informacin globalmente, verificando el funcionamiento correcto de
213
las interfaces entre los distintos subsistemas que lo componen y con otros
sistemas con los que se comunica. Debido a que el sistema no se comunica
con otro; es decir, opera en forma autnoma, la nica prueba del sistema que
se ha ejecutado es la relacionada con el tiempo de respuesta. En todos los
casos el sistema ha respondido correctamente.
10.6.1 PREPARACIN DEL ENTORNO DE LAS PRUEBAS DE SISTEMA
(CSI 5.1)
En esta tarea se preparan todos los recursos necesarios para la realizacin

de las pruebas del sistema, de acuerdo a las caractersticas establecidas en el
plan de pruebas. En el captulo VIII, se han planificado entre otros elementos el
entorno necesario y en al captulo IX, se ha especificado la realizacin de este
tipo de pruebas.
10.6.2 REALIZACIN DE LAS PRUEBAS DE SISTEMA (CSI 5.2)
El objetivo de esta tarea es integrar todos los subsistemas y componentes

del sistema de informacin, as como la interaccin con otros sistemas de
informacin. A nivel de mdulo se ha comprobado si el tiempo de respuesta
responde a la ERS. Para graficar esta situacin se exhibe la tabla 10.3.
Identificac.
del Caso de
Prueba
CP033
CP034
CP035
CP036
CP037
CP038
CP039
CP040
CP041
Proceso
Consulta de Factores de Ajustes de
Complejidad Tcnica
Ingreso de Datos del Proyecto
(ABM_Proyecto)
Aplicacin
Resumen de Resultados de Mediciones
(consulta)
Detalle de Resultados de Mediciones
(consulta)
Consulta de Valores de Ajuste de
Complejidad Tcnica
Registro de Entradas de Transacciones
Lgicas
Registro de Salidas de Transacciones
Lgicas
Registro de Conceptos de Transacciones
Lgicas
CP042
ABM de Transacciones Lgicas
CP043
Actualizacin de Parmetros de Clculo
CP044

Aplicacin
Fecha de
Ejecucin
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
12 de Enero
del 2006
Resultado
de la
Ejecucin
Errores
Encontrado
s
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Ok
Ninguno
Tabla 10.3. Resultados de la ejecucin de las pruebas del sistema.

214

10.6.3 EVALUACIN DE LOS RESULTADOS DE LAS PRUEBAS DE

SISTEMA (CSI 5.3)
Segn se muestra en la tabla 10.3, los test que se han ejecutado para el
tiempo de respuesta han sido todos satisfactorios.
Otro aspecto para destacar es que no se esperan que se generen nuevos
casos de pruebas, debido al nivel de satisfaccin alcanzado.
10.7 ELABORACIN DE LOS MANUALES DEL USUARIO (CSI 6)
El objetivo de esta tarea es elaborar la documentacin tanto del usuario

final como la del usuario de explotacin, de acuerdo a los requisitos
establecidos, y recogidos del catlogo de requisitos.
En el anexo VI, se exhibe un manual del usuario, el cual le permite al
operador del sistema (generalmente encargado del proyecto), introducirse en
las cuestiones relativas al uso del producto resultante (ESTIMSBC). En el se
encuentran las pantallas y algunas explicaciones que permiten sacar el mayor
rendimiento posible de la herramienta de software.
10.8 APROBACIN DEL SISTEMA DE INFORMACIN (CSI 9)
En esta etapa se realiza una recopilacin de los productos del sistema de

informacin y se los presenta ante el Comit encargado de evaluarlo.

215
CAPTULO XI
IMPLANTACIN
Y
ACEPTACIN
DEL
SISTEMA
DE
INFORMACIN
(IAS)
CAPTULO XI
IMPLANTACIN Y ACEPTACIN DEL SISTEMA DE INFORMACIN (IAS)
11.1 INTRODUCCIN
En este captulo se desarrollan las actividades y tareas concernientes a la

implantacin y aceptacin del sistema de informacin. Debido a las
particularidades del presente desarrollo y al tratarse de un trabajo de tesis, no
se desarrollan todas las actividades de la fase.
11.2 ESTABLECIMIENTO DEL PLAN DE IMPLANTACIN (IAS 1)
En esta actividad se revisa la estrategia de implantacin para el sistema

establecida inicialmente en el proceso de EVS. Una vez estudiado el alcance y
los condicionantes de la implantacin, se decide si esta se puede llevar a cabo.
La estrategia de implantacin del sistema se habr determinado en la tarea
EVS 6. Debido a que se trata ms bien de un sistema pequeo; es decir de
poca envergadura, resulta innecesario delinear un plan de implantacin. Las
tareas correspondientes a esta actividad no se desarrollan al pie de la letra
debido, precisamente, a este motivo.
11.3 FORMACIN NECESARIA PARA LA IMPLANTACIN (IAS 2)
En esta actividad se prepara y se imparte la formacin al equipo que

participar en la implantacin y aceptacin del sistema de informacin. El
seguimiento de la formacin de usuarios finales no est contemplado en el
marco del desarrollo de la metodologa mtrica V3.
Debido a que se trata de un trabajo acadmico, no se especifica en detalle
un plan de formacin; tampoco se especifica un plan de formacin a usuarios
finales.
11.4 INCORPORACIN DEL SISTEMA AL ENTORNO DE OPERACIN (IAS
3)
En esta actividad, se realizan las tareas necesarias para la incorporacin

del sistema al entorno operativo. Mientras que las pruebas unitarias, de
integracin y del sistema se pueden realizar afuera del entorno de operacin,
las pruebas de aceptacin solamente son posibles en dicho entorno.
Como paso previo a la realizacin de dichas pruebas y de acuerdo a lo
planificado, se verifica que los recursos necesarios estn disponibles para que
se pueda instalar adecuadamente todos los componentes del sistema.
Captulo XI Implantacin y
Aceptacin del Sistema de
Informacin (IAS)
219
11.4.1 PREPARACIN DE LA INSTALACIN (IAS 3.1)
En esta tarea se verifica que est disponible la infraestructura necesaria

para configurar el entorno. Dicha infraestructura debe cumplir los requisitos de
implantacin y tener en cuenta los procedimientos de seguridad y control de
acceso, operacin y administracin del sistema.
Adems si alguno de los sistemas de informacin implicados en la
implantacin lleva consigo una migracin, habr que tenerlo en cuenta
igualmente. Con respecto a la carga inicial de datos, en el punto 8.9.2 y tabla
8.10 del captulo VIII, se ha referenciado a la fuente de datos para la realizacin
de las pruebas.
11.4.2 REALIZACIN DE LA INSTALACIN (IAS 3.2)
Se realiza la instalacin de todos los componentes del nuevo sistema,

incluidos procedimientos manuales y automticos de acuerdo al plan de
implantacin.
Los elementos constitutivos de la base de datos que se instalan en el
entorno operativo son:
i)
Base de datos:
a. tablas,
b. consultas,
c. formularios,
d. reportes,
e. macros,
Estos elementos han sido correctamente instalados y se encuentran en

condiciones de operar.
11.5 CARGA DE DATOS EN EL ENTORNO DE OPERACIN (IAS 4)
Teniendo en cuenta que los sistemas de informacin a implantar pueden

reemplazar a otros existentes, puede ser necesario una migracin y, o carga
inicial de datos cuyo alcance depender de las caractersticas y cobertura de
cada sistema de informacin implicado.
Para el sistema implantado no se ha previsto migracin de datos debido a
que no reemplaza a un sistema existente. La carga inicial de datos se realiza
de acuerdo a lo previsto en el punto 8.9.2 y tabla 8.10 del captulo VIII.
11.6 PRUEBAS DE IMPLANTACIN DEL SISTEMA (IAS 5)
La finalidad de las pruebas de implantacin es doble: por un lado

comprobar el correcto funcionamiento del sistema en su entorno de operacin;
220
Informacin (IAS)
y por otro, permitir que el usuario determine desde su punto de vista la

aceptacin o no del sistema implantado.
Se comprueba la disponibilidad de los recursos humanos y tcnicos
necesarios para realizar las pruebas de implantacin, los que han sido
especificados en el punto 9.10 del captulo IX. Con respecto al plan de
pruebas, se ha especificado adems, en el punto 9.9.3 del mismo captulo.
11.7 PRUEBAS DE ACEPTACIN DEL SISTEMA (IAS 6)
Las pruebas de aceptacin tienen como fin validar que el sistema se

comporta y cumple con los requisitos bsicos de funcionamiento. Estas
pruebas son llevadas a cabo por el usuario final, quin en definitiva es el
conoce en detalle la tarea que debe realizar con la ayuda del sistema.
Para validar el funcionamiento, se toma un caso en particular y se
determina una secuencia de pantallas para que el lector tome conocimiento de
cmo se comporta el sistema ante un caso particular.
La pantalla de la figura 11.1, tiene por objeto iniciar al usuario en la
aplicacin y mostrar el ttulo o nombre, autor y a quien va dirigido el software.
En la parte inferior derecha aparece un botn que gua al usuario hacia el men
principal.
Figura 11.1. Pantalla de presentacin de la aplicacin.

Seguida a la pantalla de presentacin, se muestra un men (figura 11.2)
con las opciones para ingresar valores, realizar el clculo o realizar consultas o
listados (reportes).
Informacin (IAS)
221
Figura 11.2. Pantalla de men de opciones.

Debido a que en el captulo VIII se han exhibido las distintas pantallas, en
esta seccin solamente se muestran aquellas que marcan el trayecto para
realizar el clculo del mtodo y posteriormente mostrar los resultados de la
estimacin.
En la figura 11.3 se muestra la interfaz que permite ingresar los datos del
proyecto.
i)
Datos de entrada:
a. Nmero de medicin (auto-incremental).
b. Fecha de medicin.
c. Nombre de proyecto.
d. Nombre de aplicacin.
e. Nombre de cliente.
Figura 11.3. Pantalla de ingreso de datos del proyecto.
222
Informacin (IAS)
Esta pantalla no solamente permite ingresar los datos del proyecto;

adems, permite modificar o eliminar un registro determinado siempre y cuando
no rompa las reglas de integridad referencial.
Una vez que se tienen los datos del proyecto, se ingresan aquellos que
correspondientes a las transacciones lgicas. Primero se localiza un proyecto
determinado y luego, se procede a incorporar las transacciones lgicas
pertenecientes a dicho proyecto (figura 11.4).
Figura 11.4. Pantalla de ingreso (ABM) de transacciones lgicas.

En el caso de que el usuario o el encargado del proyecto ha ingresado un
dato errneo, este se puede rectificar; es decir, esta pantalla permite eliminar o
modificar un registro de transacciones lgicas.
Luego de ingresar las transacciones lgicas se deben cargar sus
elementos que son entradas, salidas y conceptos. Estos tres tipos de ingreso
de datos tienen el mismo tratamiento y las figuras 11.5 a 11.7, muestran como
es la interfaz del usuario.
Informacin (IAS)
223
Figura 11.5. Ingreso (ABM) de conceptos de transacciones lgicas.
Figura 11.6. Ingreso (ABM) de entradas de transacciones lgicas.
224
Informacin (IAS)
Figura 11.7. Ingreso (ABM) de salidas de transacciones lgicas.

Estos elementos ingresados, permiten dar el valor de la cantidad de
entradas, conceptos y salidas. Una vez que se tienen estos valores, se pueden
ingresar los valores de las caractersticas tcnicas de la aplicacin. Para el
ejemplo escogido para demostrar la interfaz de usuario, todos los valores son
nominales; es decir igual a uno (1), con lo cual el valor de los puntos de funcin
ser el mismo de los puntos de funcin ajustados. La pantalla 11.8 muestra un
ejemplo de esta situacin.
Figura 11.8. Pantalla de ingreso de caractersticas tcnicas de la aplicacin.

Informacin (IAS)
225
En la parte inferior de esta pantalla est ubicado un botn mostrar

resultados de medicin, que al oprimirlo, se abre una pantalla con los
resultados de la estimacin (figura 11.9).
Figura 11.9. Pantalla de resultados de medicin.

Una vez que se tienen los resultados de las mediciones, estos pueden ser
exhibidos en forma de columnas (figura 11.10) o como un detalle de los
mismos (figura 11.11).
Figura 11.10. Pantalla de resumen de resultados de mediciones.

226
Informacin (IAS)
Figura 11.11. Pantalla de resultados de mediciones (detalle).

Con respecto a la evaluacin de los resultados, y para cumplir con las
pruebas de aceptacin, se ha dedicado un captulo aparte (captulo XII) para
que el lector comprenda como se ha llevado a cabo dicho proceso.
Informacin (IAS)
227
CAPTULO XII
EVALUACIN
DEL
SISTEMA
DE
INFORMACIN
CAPTULO XII
EVALUACIN DEL SISTEMA DE INFORMACIN
12.1 INTRODUCCIN
En este captulo se realiza una evaluacin de la herramienta o sistema

software desarrollado con el objeto de determinar si rene los requisitos
esperados y se comporta segn las especificaciones. Esta evaluacin forma
parte de las pruebas de aceptacin iniciadas en el captulo XI.
12.2 SELECCIN DE PROYECTOS
HERRAMIENTA DE SOFTWARE
PARA
EVALUACIN
DE
LA
Como se ha mencionado en el captulo VIII (punto 8.9.3 ya tabla 8.10), se

han seleccionado dos proyectos para realizar una evaluacin de la herramienta
de software y determinar si los resultados arrojados son coherentes y el desvo
o la diferencia con el tiempo real insumido para el desarrollo son aceptables.
El primer proyecto es el del M. Ing. Eduardo Diez, Generador de un Mapa
de Actividades (GMAP). La herramienta de software GMAP es un SBC que
asiste al responsable de un proyecto de desarrollo de software en la
elaboracin de un mapa de actividades del mismo. El sistema permite ingresar
las particularidades del proyecto, infiere el mapa de actividades sobre la base
de la metodologa estndar mtrica V3, y lo presenta en un formato electrnico
estndar [Diez03].
En la tabla 3.1 del trabajo de tesis del M. Ing. Eduardo Diez, se muestra
una estimacin para las fases de requisitos, modelado conceptual, diseo del
sistema, implementacin y evaluacin que asciende a 400 hs.
Una vez que se tiene el valor de las horas estimadas por el usuario o por
los datos del proyecto que va a ser sometido a pruebas, se analizan el
diccionario de datos y la tabla concepto, atributo, valor con el objeto de
identificar transacciones lgicas, entradas, salidas y conceptos. La tabla 12.1,
exhibe la cantidad de estos elementos identificados para las transacciones
lgicas.
Captulo XII Evaluacin del

Sistema de Informacin
231
Presentacin de la aplicacin
Mensajes de error
Botones de eventos
Caracterizar un proyecto
Especificar datos del proyecto
Especificar conjunto de actividades
seleccionadas para proyecto
Totales
Entradas
1
1
4
22
68
Salidas
1
1
1
12
21
3
Conceptos
-
96
40
1
1
1
Tabla 12.1. Elementos identificados para las transacciones lgicas.

Una vez obtenidos las cantidades correspondientes a los distintos
elementos, se procede a incorporarlos en el sistema con el objeto de que este
realice la estimacin. A continuacin se muestran dos pantallas donde se
exhiben los resultados en forma resumida (figura 12.1) y en forma detallada
(figura 12.2).
Figura 12.1. Resumen de resultados de medicin de proyecto M. Ing.

Eduardo Diez.
232

Figura 12.2. Pantalla de detalle de resultados de proyecto M. Ing. Eduardo

Diez.
Si se toman en cuenta los resultados que arroja la herramienta de software,
se nota que estima una cantidad aproximada de horas de seiscientas cincuenta
y cinco (655). En el apndice B correspondiente a la gestin del proyecto, se
muestra la tabla (B.1 horas insumidas) cuyas fases (requisitos, modelado
conceptual, diseo del sistema, implementacin y evaluacin) que fueron
estimadas en cuatrocientas horas (400 hs.), asciende a seiscientas noventa y
cinco horas (695 hs.). La herramienta de estimacin ha calculado un total de
seiscientas cincuenta y cinco horas (655 hs.) con un desvo o diferencia de
cuarenta horas (40 hs.), que representa el -6 % se error, lo cual es un valor
aceptable.
Otro proyecto que se considera para la evaluacin es el desarrollado por el
M. Ing. Daro Piccirilli [Piccirilli03], de Sistema de Ayuda Para la Seleccin de
un Perito Informtico, Especialista en Propiedad Intelectual del Software.
En la pgina 38 del mencionado trabajo se muestra una tabla donde se realiza
una estimacin de horas insumidas por cada fase. Se toma en cuenta las fases
de diseo e implementacin del sistema. Entre estas dos fases, suman 895 hs.
Con respecto a los elementos identificados, en la tabla 12.2 se muestran las
transacciones lgicas, conceptos, entradas y salidas identificadas.

233
Transaccin Lgica
Presentacin de la aplicacin
Mensajes de error
Determinar valores de puntuacin del perito
Determinar experiencia en docencia especializada
Valor generado por el sistema
Determinar experiencia en otros fueros
Analizar causas de actuacin en fuero civil
Determinar experiencia penal
Determinar formacin acadmica
Determinar otras participaciones perciales
Determinar profesional a evaluar / sugerir
Determinar perfil profesional
Totales
Entradas
0
1
2
4
1
2
10
10
16
13
23
12
94
Salidas
1
1
2
3
1
1
11
1
5
7
13
3
49
Conceptos
0
0
1
1
1
1
1
1
1
1
1
1
10
Tabla 12.2. Elementos identificados en proyecto de M. Ing. Daro Piccirilli

A continuacin se muestran las figuras 12.3 y 12.4 con los resultados de la
medicin efectuada al proyecto del M. Ing. Daro Piccirilli.
Figura 12.3. Resultados estimativos de la medicin del proyecto del M. Ing.

Daro Piccirilli.
234

Figura 12.4. Resultados estimativos (detalle) de la medicin del proyecto

del M. Ing. Daro Piccirilli.
Como se puede apreciar en las figuras 12.3 y 12.4, los clculos han
arrojado aproximadamente setecientas veinticinco horas (725 hs.-hombre) para
desarrollar las fases de diseo e implementacin del software. En la pgina 38
del trabajo de tesis desarrollado por el M. Ing. Daro Piccirilli [Piccirilli03], se
muestra una estimacin del tiempo insumido en horas, cuyo valor asciende a
ochocientas noventa y cinco horas (895 hs.). El desvo o la diferencia son de
ciento setenta horas (170 hs), que representa aproximadamente el -23 %. Esto
significa que se ha estimado un 23 % menos con respecto a la estimacin de
Piccirilli. Debido a que el trabajo no exhibe la cantidad de horas insumidas,
resulta imposible comparar con el tiempo real que se ha ocupado en el
desarrollo de las fases en cuestin.

235
CAPTULO XIII
CONCLUSIONES
Y
FUTURAS
LNEAS
DE
INVESTIGACIN
CAPTULO XIII
CONCLUSIONES Y FUTURAS LNEAS DE INVESTIGACIN
13.1 INTRODUCCIN
En este captulo se exponen las conclusiones del trabajo de tesis y las

futuras lneas de investigacin o aspectos que no han sido contemplados y que
tienen relacin con dominio de la estimacin en desarrollos de proyectos que
incluyen a SSBBCC.
13.2 ASPECTOS GENERALES DEL TRABAJO DE TESIS
Como se ha manifestado en el captulo V (dedicado ntegramente a los

SSEE) este tipo de software ha comenzado a ser visualizado como una opcin
para resolver problemas donde se requiere experticia que debe ser aplicada en
uno o varios lugares al mismo tiempo o cuando la presencia de uno o varios
expertos resulta un tanto crtica debido a la hostilidad de las instalaciones.
El uso de los SSBBCC, con fines comerciales, hace posible que en muchas
empresas se comiencen a gestionar, administrar y controlar los recursos
previstos frente a los recursos utilizados. Este trabajo constituye un aporte
precisamente para ayudar al encargado de proyecto a gestionar los recursos
que va a necesitar a la hora de iniciar un proyecto con las caractersticas de los
desarrollos de SSBBCC.
Los proyectos de desarrollo de de SSBBCC, al igual que cualquier otro tipo
de desarrollo, deben ser controlados y medidos, de lo contrario su gestin y
seguimiento no seran correctos.
13.3 CONSIDERACIONES PREVIAS A LAS CONCLUSIONES
Algunas consideraciones previas a las conclusiones propiamente dichas se

exponen a continuacin:
i)
De acuerdo al estudio y anlisis efectuado en el captulo IV, no

existe en el mercado o al menos no se ha identificado
explcitamente la presencia de una herramienta que sea aplicable a
los SSBBCC.
ii)
Esto ha llevado a tomar como base de experimentacin algunos de

los mtodos existentes y sacar provecho de ciertos aspectos.
iii)
El mtodo de estimacin que se presenta en este trabajo es

experimental; es decir, haran falta una serie de estudios empricos
como para dar un soporte ciento por ciento fiable. A pesar de ello,
en el captulo XII, se han sometido a medicin sendos trabajos
Captulo XIII Conclusiones

y Futuras Lneas de
Investigacin
239
acadmicos del Instituto Tecnolgico de Buenos Aires (ITBA) con

resultados altamente satisfactorios y con mrgenes de error
tolerables.
iv)
Los datos de los valores del coeficiente de ajuste lgico (CAL) que
en un principio son 0.800 para entradas y salidas y 1.200 para
conceptos, puede variar en funcin de los resultados que se vayan
obteniendo y a medida que se recopile informacin de proyectos
basados en esta tecnologa.
v)
Otro tanto pasa con los valores de las caractersticas tcnicas de la

aplicacin que se quiere medir. En un principio la cantidad de
parmetros de ajuste tcnico es de diez (10), pero se pueden
agregar o eliminar en funcin de los resultados y de las
caractersticas particulares de la instalacin donde se desarrolla el
software.
vi)
El mismo tratamiento del punto anterior se realiza para los

coeficientes de ajuste y variacin tcnica.
vii)
Si bien es cierto este tipo de mtodos se aplican en etapas

tempranas del desarrollo, conviene utilizarlo en el momento de
tener definida la tabla de concepto-atributo-valor (etapa de
conceptualizacin), de manera de poder agrupar en transacciones
lgicas los elementos de entradas, salidas y conceptos.
Teniendo en cuenta estas consideraciones, se puede concluir lo siguiente:

a)
El mtodo de estimacin para proyectos que incluyan a

SSBBCC, ha resultado til cuando se lo ha aplicado a sendos
trabajos del ITBA (captulo XII). Adems ha arrojado
resultados coherentes y con mrgenes de error aceptables.
b)
Representa un aporte para el encargado de proyectos que

incluyen a SSBBCC, especialmente a la hora de estimar los
recursos necesarios para continuar o no con dicho proyecto.
c)
El mtodo sirve como lnea base y permite detectar desvos

en cuanto a los tiempos de duracin total del proyecto.
13.4 FUTURAS LNEAS DE INVESTIGACIN
Luego de analizar las conclusiones, resulta conveniente enunciar las

siguientes lneas de investigacin y desarrollo:
i)
240
Al ser este un mtodo experimental, deja abierta la posibilidad de

que se recopile informacin de otros proyectos y se realicen estudios

y Futuras Lneas de
Investigacin
como para crear una base de datos y comparar resultados obtenidos

con los clculos estimados.
ii)
Si bien es cierto el mtodo que se presenta puede estimar el tamao

de un producto software, no lo hace particularizado para cada una
de las fases del desarrollo. Resulta oportuno que en futuras
versiones
la
herramienta
pueda
realizar
estimaciones
particularizadas segn lo expresado en este punto.
iii)
Otro aspecto a tomar en cuenta es la cantidad de caractersticas

tcnicas del entorno de desarrollo. Estas pueden resultar excesivas
o pueden ser inadecuadas segn las tendencias de los distintos
entornos de desarrollo. Un ejemplo de ello, son aquellos que se
acometen para ser utilizados en la red INTERNET.

y Futuras Lneas de
Investigacin
241
BIBLIOGRAFA
BIBLIOGRAFA
o [Abran A., et al99].Abran A.; Desharnais J. M.; Oligny S.; St-Pierre D.;
Symons Charles S. (1999); COSMIC FFP Measurement Manual, Versin
2.0
[en
lnea].
Universite
du
Qubec
a
Montreal,
Canada.<http://www.lrgl.uqam.ca/ffphtml> . [Consulta: 1 de Abril del 2004].
o [Abran A., et al.98]. Abran, A.; Desharnais J. M.; Maya M.; St-Pierre D.;
Bourque P. (1998). Design of a Functional size Measurement for Real-Time
Software. Research Report N 13. Software Engineeri ng Management
Research Laboratory, Universite du Qubec a Montreal, Canada.
o [Albrecht79]. Albrecht, Allan J. (1979). Measuring Aplication Development
Productivity. Proc Of IBM applications. Development Joint SHARE/GUIDE
Symposium, Monterrey, Pginas 83-92.
o [Ares Casal 06]. Ares Casal Juan M (2006). Pruebas del Software. Mster
en Ingeniera del Software e Ingeniera del Conocimiento, Parte A Mdulo II,
Unidad XV.
o [Bohem98]. Bohem Barry (1998). Cost Model For Future Software Life Cycle
Processes: COCOMO II.
o [Buchanan83]. Buchanan, B.,Bechtal, R., Bennet J., Clancey, W.,
Kulikowski, C., Mitchell T., and Waterman, D. A. Constructing an Expert
System. Addison-Wesley, (1983).
o [Costar V7.0.03]. Costar V 7.0 (2003). Sophisticates Software Company Softstar Systems. [en lnea]. < http://www.softstarsystems.com >. [Consulta
1 de Octubre del 2004].
o [Diez03]. Diez Eduardo (2003). Tesis de Magster en Ingeniera del
Software. Generador del Mapa de Actividades de un Proyecto de Desarrollo
de Software.
o [Hidalgo05]. Jose Maria Gomez Hidalgo (2005). Introduccin a los Sistemas
Basados
en
conocimientos.
<http://www.esi.uem.es/~jmgomez/isbc.
[Consulta: 30 de Junio del 2005].
o [IFPUG04]. IFPUG, (2004). International Function Point User Group. [en
lnea].Brief History. < http://www.ifpug.org >. [Consulta: 1 de Junio del 2004].
o [IFPUG00]. IFPUG, (2000). International Function Point User Group.
MANUAL DE PRACTICA CPM.
o [Industrial Technology03]. Journal of Industrial Technology. A Method For
Evaluating Expert System. Volume 19. January 2003.
o [Jimnez05]. Jimnez Anglica Antonio de (2005). Gestin de la
Configuracin. Mster en Ingeniera del Software e Ingeniera del
Conocimiento, Parte A Mdulo I, Unidad VI.
o [Jones99]. Jones, C. (1999). A Short History of Function Points and Feature
Points. Software Productivity Research Inc. USA.
o [Kantelien Pasi04]. Kantelinen Pasi (2004). Services for developing software
project management practices and software process.
< http://www.laatuk.com/tools/effort_estimation_tools.html >
[Consulta: 30 de Septiembre del 2004].
o [Mtrica V304]. Mtrica V3 (2004). Metodologa de Planificacin, Desarrollo
y Mantenimiento de Sistemas de Informacin [en lnea]. Ministerio de
Administraciones Pblicas Espaol.
<http://www.csi.map.es/csi/metrica3/index.html > [Consulta: 15 de Marzo del
Bibliografa
245
2004].
o [Methods & Tools99] Methods & Tools (1999). Global Knowledge source for
software development professionals. ISSN 1023-4918.Volume 7 Number
3.
o [Moreno Snchez-Capuchino98]. Moreno Snchez Capuchino Ana Mara,
(1998). Estimacin de Proyectos Software. Master en Ingeniera del
Software e Ingeniera del Conocimiento, Parte A Mdulo I, Unidad IV
o [Pazos Sierra05]. Juan Pazos Sierra (2005). Introduccin a la Ingeniera del
Conocimiento. Master en Ingeniera del Software e Ingeniera del
Conocimiento, Parte B Mdulo IV, Unidad XIX.
o [Piccirilli03]. Daro A. Piccirilli (2003). Tesis de Magster en Ingeniera del
Software. Sistema de Ayuda Para la Seleccin de un Perito Informtico,
Especialista en Propiedad Intelectual del Software.
o [Pressman98]. Pressman, Roger S (1998). Ingeniera del Software. Un
Enfoque Prctico. Cuarta Edicin. 581 pginas. Editorial Mc Graw-Hill. ISBN
84-481-1186-9.
o [QSM05]. Quantitative Software Management Inc (2005). Function Point
Table Languages. < http://www.qsm.com/FPGearning.html >
o [Symons98]. Symons, Charles R. (1998). Function Point Analisis:Difficulties
and Improvements. IEEE Transactions on Software Engineering. Paginas 211.
o [Waterman86]. Waterman, Donald A (1986). A Guide to Expert Systems.
418 pginas. Editorial Addison-Esley Publishing Company. ISBN 0-20108313-2.
o [Whitmire92]. Whitmire, Scott A. (1992). 3D Function Points: Scientific and
Real-Time Extensions to Function Points. Pacific Nothwest Software Quality
Conference.
246
Bibliografa
APNDICE A
ACRNIMOS
APNDICE A
ACRNIMOS
A. ACRNIMOS
A
ABM
Alta, baja o modificacin
B
BC
Base de conocimiento
C
CA
CAD
CAV
CFSU
D
DET
E
EI
ELF
EP
EO
EQ
EX
F
FA
FP
FTR
FUR
Algoritmo complejo (del ingls Complex Algorithm)

Diseo asistido por computadora (del ingls Computer Aided
Design)
Concepto, atributo, valor, en referencia al tipo de
representacin intermedia del modelo conceptual
Unidad de medida funcional COSMIC (del ingls Cosmic
Functional Size Units)
Tipo de dato elemental o primario (del ingls data elemental

type)
Entradas externas (del ingls External Input)

Archivos lgicos externos (del ingls External Logical File)
Encargado de proyecto
Salidas externas (del ingls External Output)
Consultas externas (del ingls External Queries)
Expertos
Factores de ajuste (del ingls Factors Adjust).

Puntos de funcin (del ingls Function Point).
Tipo de archivo referenciado (del ingls File Type Referenced).
Requerimientos funcionales del usuario ( del ingls Functional
User Requirement).
G
GUI
Graphical User Interfaces Interface grfica del usuario.
I
IC
ILF
Ingeniero en conocimiento.
Archivos lgicos internos (del ingls Internal Logical File)
Apndice A - Acrnimos
249
L
LOC
Lneas de cdigo (del ingls Lines of Code).
M
MT
Memoria de trabajo.
P
PAI
PM
Proceso de actualizacin e inferencias.

Persons Month personas mes
R
RET
RFU
ROM
Registro elemental o primario de datos (del ingls Record

Element Type).
Requerimiento funcional del usuario.
Memoria de solo lectura (del ingls Read Only Memory).
S
SSBBCC
Sistemas basados en conocimientos.
T
TCA
U
US
250
TCA Ajuste de complejidad tcnica (del ingls Technical

Complexity Adjustment).
Usuarios del sistema (pueden ser personas u otros sistemas).
Apndice A - Acrnimos
APNDICE B
GESTIN
DEL
PROYECTO
APNDICE B
GESTIN DEL PROYECTO
B.1 INTRODUCCIN
En este apndice se muestra el estado final del proyecto; es decir, la

cantidad total de horas insumidas para la ejecucin de las fases exhibidas en la
tabla 7.8 del captulo VII y las tareas que se muestran en la figura 7.1 del citado
captulo.
B.2 HORAS REALES INSUMIDAS
En la tabla B.1, se muestra el tiempo real insumido (expresado en horas)

para la ejecucin de las fases de la metodologa mtrica V3. Este valor, es
comparado con el tiempo estimado (tabla 7.8, captulo VII).
Tiempo
Estimado en
Hs.
Descripcin de Fase
Gestin del Proyecto
Gestin de la Configuracin
Aseguramiento de la Calidad
Anlisis del Sistema de Informacin
Diseo del Sistema de Informacin
Construccin del Sistema de Informacin
Implantacin y Aceptacin del Sistema de Informacin
Total en horas estimadas
Tiempo Real Diferencia de

Diferencia en
Empleado en
la Variable
Das
Hs.
Tiempo en Hs.
55
60
20
210
230
185
40
800
55
45
15
185
205
145
20
670
0
-15
-5
-25
-25
-40
-20
-130
0
-3
-1
-5
-5
-8
-4
-26
Tabla B.1. Tiempo real insumido para la ejecucin de las fases de mtrica
V3.
Como se puede apreciar en la tabla B.1, y si bien es cierto no ha habido un
control riguroso del proyecto, el tiempo real insumido para su desarrollo ha sido
menor al previsto. Seguramente, la causa fundamental fue la ausencia de
interacciones con terceros para educir informacin. Otro argumento importante,
ha sido la utilizacin de un entorno de desarrollo, el cual ha generado el cdigo
en forma automtica, evitando su escritura manual. An as, se recuerda que
algunas funciones han sido escritas o codificadas manualmente.
B.3 CRONOGRAMA FINAL DE TAREAS
En la figura B.1 se exhibe el cronograma final de fases ejecutadas del

proyecto, conjuntamente con las fechas de inicio, finalizacin y duracin de las
mismas. En dicha figura, se puede apreciar la diferencia con la fecha prevista
de finalizacin mostrada en la figura 7.1 del captulo VII.
Apndice B Gestin del

Proyecto
253
Figura B.1. Cronograma de fases con tiempo de inicio, finalizacin y duracin.
254
Apndice B Gestin del

Proyecto
ANEXO I
DOCUMENTOS
DE LAS
ETAPAS
DEL
PROCESO
DE
MEDICIN
ANEXO I
DOCUMENTOS DE LAS ETAPAS DEL PROCESO DE MEDICIN
I.A. DOCUMENTO DE OBJETIVOS DE LA MEDICIN (DOM)
ESTIMSBC
Fecha:_____/______/_____
DOCUMENTO DE OBJETIVOS DE LA MEDICIN

Proyecto
Cliente/Usuario
Nombre de Aplicacin
Tipo de Aplicacin
Desarrollo
Mantenimiento
Soporte
Tipo de Medicin
Exacta
Aproximada
Breve descripcin del contexto en el que opera el sistema
Anexo I - Documentos de las

Etapas del Proceso de
Medicin
257
I.B. DOCUMENTO DE DESCRIPCIN DE LMITES DE LA APLICACIN

(DDL)
Fecha:_____/______/_____
ESTIMSBC
DOCUMENTO DE DESCRIPCIN DE LMITES

Proyecto
Cliente/Usuario
Nombre de Aplicacin
Breve descripcin de la aplicacin
Breve descripcin de relacin con interfaces externas
I.C. DOCUMENTO DE TRANSACCIONES LGICAS IDENTIFICADAS (DTL)
258
Anexo I Documentos de las

Medicin
I.D. DOCUMENTO DE ENTRADAS, SALIDAS Y CONCEPTOS
Fecha:_____/______/_____
ESTIMSBC
DOCUMENTO DE TRANSACCIONES LGICAS IDENTIFICADAS

Proyecto
Cliente/Usuario
Nombre de Aplicacin
Cantidad de entradas identificadas
tem
Id. Tr. Lgica
Atributo
Relacionado
Tipo de
Elemento de
Entrada
Breve Descripcin
Tipo de
Elemento de
Salida
Breve Descripcin
Cantidad de salidas identificadas

tem
Id. Tr. Lgica
Atributo
Relacionado
Cantidad de conceptos identificados

tem
Id. Tr. Lgica
Anexo I - Documentos de las

Medicin
Nombre de Concepto
Breve Descripcin
259
ANEXO II
DESCRIPCIN
DEL
MODELO
CONCEPTUAL
DE
DATOS
ANEXO II
DESCRIPCIN DEL MODELO CONCEPTUAL DE DATOS
II.A TABLA DE ENTIDADES, ATRIBUTOS, DESCRIPCIN Y DOMINIO
Entidad
Atributo
IDETRA
Conceptos de
transacciones NOMCON
lgicas
BREDES
IDETRA
NUMMED
Transacciones DESTRA
lgicas
CANENT
CANSAL
CANCON
Tipo de
TIELEN
elemento de
entrada
DEELEN
Tipo de
TIELSA
elemento de
salida
DEELSA
IDETRA
Entradas de ATRREL
transacciones
TIELEN
lgicas
BREDES
Descripcin
Id. De Transaccin
lgica
Nombre del Concepto
Tipo
Longitud Dominio de Atributo
Entero largo
Autonumrico
Texto
50
Cadena de caracteres
Autonumrico
Breve Descripcin del

Memo
Concepto
Id. De Transaccin
Entero largo
lgica
Nmero de la
medicin
Entero largo
Descripcin de
transaccin lgica
Texto
Cantidad de entradas Entero largo
Cantidad de salidas Entero largo
Cantidad de
conceptos
Entero largo
Tipo de elemento de
entrada
Texto
Descripcin de
elemento de entrada
Texto
Tipo de elemento de
salida
Texto
Descripcin de
elemento de salida
Texto
Id. De Transaccin
lgica
Entero largo
Atributo relacionado
Texto
Tipo de elemento de
entrada
Texto
Breve descripcin de
la entrada
Memo
4
50
4
4
4
3
Autonumrico
Numrico
Numrico
Numrico
50
3
50
4
30
50
-
Autonumrico
Tabla A.II.1. Modelo conceptual de datos.
Anexo II Descripcin del

Modelo Conceptual de Datos
263
Entidad
Atributo
NUMMED
FECMED
NOMPRO
NOMAPL
NOMCLI
Descripcin
Tipo
Nmero de la
Autonumrico
medicin
Entero largo
4
Fecha de medicin
Fecha/Hora
8
Date
Nombre de proyecto
Texto
100
Nombre de aplicacin
Nombre de cliente
Conocimientos
distribuidos
Eficiencia del usuario
final
Facilidad en la
instalacin
Facilidad de
operacin
Facilidad de
comunicacin de
datos
Texto
Texto
100
100
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
Entero largo
RAP
Puestos mltiples
Razonamiento
aproximado
Entero largo
REN
Rendimiento
Entero largo
REU
Entero largo
UPR
Reutilizacin
Uso masivo del
procesador
Entero largo
CATRLO
Cantidad de
transacciones lgicas Entero largo
CDI
EUF
FAI
FAO
FCD
PMU
CANCON
PFSBC
ACT
PFASBC
PRODUC
TIEMPO
COSTO
ESFUER
Cantidad de salidas
Cantidad de
conceptos
Puntos de funcin sin
ajustar (PFSBC)
Ajuste de
complejidad tcnica
Puntos de funcin
ajustados (PFASBC)
Productividad
Tiempo estimado
para el desarrollo
Costo estimativo del
desarrollo
Esfuerzo en personas
- mes
Numrico mayor a cero
Mediciones
CANENT
CANSAL

Numrico
Entero largo
Entero largo
4
4
Entero largo
Doble
Doble
Doble
Doble
8
8
Doble
Moneda
Entero largo
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Numrico
Moneda
Numrico
Tabla A.II.1. Modelo conceptual de datos (continuacin).
264

Entidad
Atributo
IDETRA
ATRREL
Salidas de
transacciones
TIELSA
lgicas
BREDES
VACAEN
VACASA
VACACO
Parmetros
para
mediciones
VALCO1
VALCO2
COSHOR
HORSEM
Descripcin de CODFAC
caractersticas
tcnicas de la
aplicacin
DESCRI
VAFAAJ
Ajustes de
CODFAC
complejidad
tcnica
DESCRI
Descripcin
Tipo
Id. De Transaccin
Autonumrico
lgica
Entero largo
4
Atributo relacionado
Texto
50
Tipo de elemento de
salida
Texto
50
Breve descripcin del
elemento de salida
Memo
Valor de coeficiente
de ajuste para
entradas
Doble
de ajuste para
salidas
Doble
de ajuste para
conceptos
Doble
Valor del coeficiente
de ajuste de
complejidad tcnica
Doble
Valor del coeficiente
de variacin
estimada
Doble
Costo de la hora para
un profesional
informtico
Moneda
Horas semanales
estipuladas de
trabajo
Entero largo
Cdigo de factor de
ajuste de
caractersticas de la
aplicacin
Texto
de ajuste de
caractersticas de la
aplicacin
Texto
Valor del factor de
ajuste
Entero largo
Cdigo de factor de
ajuste de
complejidad tcnica
Texto
de ajuste de
complejidad tcnica
Texto
Numrico
8
Numrico
8
Numrico
8
Numrico
8
Numrico
8
Moneda
8
Numrico
4
3
200
4

3
50
Tabla A.II.1. Modelo conceptual de datos (continuacin).

265
II.B DIAGRAMA DE ENTIDADES, RELACIONES E IDENTIFICADORES

NORMALIZADO A TERCERA FORMA NORMAL 3FN
Figura A.II.1. Diagrama de entidades, relaciones e identificadores en 3FN.

II.C CORRESPONDENCIA ENTRE NOMBRES DE ENTIDADES Y TABLAS
DE LA BASE DE DATOS
Nombre de Entidad
Mediciones
Transacciones lgicas
Entradas de transacciones lgicas
Salidas de transacciones lgicas
Conceptos de transacciones lgicas
Elementos de entrada
Elementos de salida
Ajustes de complejidad tcnica
Valores factor de ajuste de
complejidad tcnica
Parmetros para mediciones
Correspondiente Nombre de Tabla

en la Base de Datos
Tabla_mediciones
Tabla_dtl_Identificadas
Tabla_ent_Identificadas
Tabla_sal_Identificadas
Tabla_con_Identificados
Tabla_elementos_entrada
Tabla_elementos_salida
Tabla_ajustes_complejidad
Tabla_valores_factor_ajuste
Tabla_valores_cal
Tabla A.II.2. Correspondencia entre nombre de las entidades y nombre de las

tablas de las bases de datos.
266

II.D ENTIDADES QUE SON ACCEDIDAS POR PROCESOS PRIMARIOS

Nombre de Entidad
Mediciones
Transacciones lgicas
Entradas de transacciones
lgicas
Salidas de transacciones
lgicas
Conceptos de transacciones
lgicas
Elementos de entrada
Elementos de salida
Ajustes de complejidad tcnica
Valores factor de ajuste de

complejidad tcnica
Parmetros para mediciones
Nombre del Proceso Primario

Ingresar datos del proyecto
ABM de transacciones lgicas
Ingreso de caractersticas de la
aplicacin a medir
Consulta de resultados de mediciones
(resumen y detalle).
Reporte de resultados de mediciones
(datos del proyecto y datos de las
mediciones)
ABM de transacciones lgicas
Ingreso de entradas de transacciones
lgicas
Ingreso de salidas de transacciones
lgicas
Ingresos de conceptos de transacciones
lgicas.
lgicas
lgicas
Ingresos de conceptos de transacciones
lgicas.
lgicas
lgicas
Ingreso de ajustes de complejidad
tcnica
Consulta de valores de ajuste de
complejidad tcnica
Actualizar valores de ajuste de
complejidad tcnica
Ingreso de ajustes de complejidad
tcnica
Consulta de valores de ajuste de
complejidad tcnica
Actualizar valores de ajuste de
complejidad tcnica
Tabla A.II.3. Entidades que son accedidas por los diferentes procesos
primarios.

267
ANEXO III
MODELO
DE
PROCESOS
DEL
SISTEMA
ANEXO III
MODELO DE PROCESOS DEL SISTEMA
III.A NIVEL 1 DEL MODELO DE PROCESOS
En la figura 9.16 del captulo IX, se exhibe el modelo de procesos (nivel 1)

en el que se identifican cuatro subsistemas. La tarea 7.1 de la actividad
correspondiente a la elaboracin del modelo de procesos, tiene como finalidad,
la descomposicin del modelo presentado en la figura 9.16 en procesos ms
primitivos con el objeto de alcanzar un mayor nivel de comprensin. En la
figura III.1 se muestra un modelo de procesos nivel 1, exactamente igual al de
la figura 9.16 con el objeto de que el lector pueda seguir el proceso de
descomposicin.
NIVEL 1 - SUBSISTEMAS
IDENTIFICADOS
A1
Transacciones
Lgicas
A3
Parmetros de
Clculo
Datos de Elementos
de la Aplicacin
(Trans. Lgicas)
Usuario
Encargado de
Proyecto
Datos de la
Aplicacin a
Medir
-1Ingresar
Datos de
Aplicacin a
Medir
Datos
Generales
del Proyecto
-2Realizar
Clculos de
Medicin
Resultados
de
Mediciones
Resultados
de
Mediciones
-3Mostrar
Result. de
Medicin
Resultados
de
Mediciones
Usuario
Encargado de
Proyecto
Valores de
Elementos
Para
Medicin
Mediciones
A2
Nuevos Valores de
Parmetros de
Clculo
Parmetros
de Clculo
-4Actualizar
Parmetros
de Clculo
A2
Mediciones
Valores Actuaiizados de
Parmetros de Clculo
Valores Actuaies
de Parmetros de
Clculo
A3
Parmetros de
Clculo
A3
Parmetros
de Clculo
Figura A.III.1. Nivel 1 de modelo de procesos.
Anexo III Modelo de

Procesos del Sistema
271
III.B NIVEL 2 DEL MODELO DE PROCESOS (MODELO DE PROCESOS DEL

SISTEMA ASI 7.1)
B.1 Subsistema de Ingreso de Datos de la Aplicacin a Medir:

NIVEL 2 - SUBSISTEMA DE INGRESO DE DATOS DE LA
APLICACIN A MEDIR
Usuario
Encargado de
Proyecto
Datos del
Proyecto
-1.1Ingresar
Datos del
Proyecto
Datos del
Proyecto
A2
Informac. de
Transacc. Lgicas
de Aplicacin a
Medir
Mediciones
Informac. de
Transacc. Lgicas
de
Aplicacin a
-1.2Medir
Ingresar
Transacciones
A1
Transacc.
Lgicas
Lgicas
Transacc.
Lgicas de
Aplicacin a
Medir
Entradas
-1.3Ingresar
Elementos
Salidas
de Trans.
Lgicas
Conceptos
Informac. de Elementos de
Transacc. Lgicas de Aplicacin a
Medir
Usuario
Encargado de
Proyecto
Informac.
Caract. Tc.
Apl.a Medir
A7
Elementos de
Entradas
-1.5Actualizar
Caract. Tc.
Aplic. a
Medir
Caract. Tc.
de Aplicacin
A5
Salidas de
Trans. Lg.
Entradas
A8
Salidas
Conceptos
Elemento Sal.
(Pant. Impr, etc.)
-1.6Contabilizar
Caract. Tc
Aplicac.
A9
Entradas de
Trans. Lg.
A6
Elemento Entr.
(Check-Box,
etc.)
Caract. Tc.
A9 de Aplicacin
A4
-1.4Contabilizar
entradas,
salidas y
conc.
Conceptos de
Trans. Lg.
Elementos de
Salidas
Entradas, salidas
y conceptos
contabilizados
A2
Mediciones
Informac. Caract. Tc. Apl.a

Medir Contabilizadas
Informac.
Caract. Tc.
Apl.a Medir
Figura B.III.2. Nivel 2 del modelo de procesos del sistema subsistema de

ingreso de datos de la aplicacin a medir.
272
Anexo III Modelo de

B.2 Clculos de Valores de Medicin:

NIVEL 2 - SUBSISTEMA DE CLCULO DE VALORES DE
MEDICIN
Valores de la
Aplicacin a Medir
A2
Mediciones
-2.1Realizar
Clculos de
Mediciones
Parmetros de
Clculo
A3
Parmetros de
Clculo
Resultados
de
Mediciones
A2
Mediciones

clculo de valores de medicin.
B.3 Mostrar Resultados de la Medicin:
NIVEL 2 - SUBSISTEMA DE MOSTRAR RESULTADOS DE
MEDICIN
Usuario
Encargado de
Proyecto
Informac. Sobre
Requesitoria
-3.1Resultados a
de Resultados
Recibir Req.
de Mediciones
Mostrar
de
Resultados
Medic.
-3.2Mostrar
Resultados
de Medic.
Resultados de
Mediciones
Usuario
Encargado de
Proyecto
A2 Mediciones

mostrar resultados de la medicin.
Anexo III Modelo de

273
B.4 Actualizar Parmetros de Clculo:

NIVEL 2 - SUBSISTEMA DE ACTUALIZAR PARMETROS DE
CLCULO
Usuario
Encargado de
Proyecto
Valores
Actualizados
-4.1de Parmetros
Ingresar
de clc.
Valores Act.
de Param.
Calc.
Valores
Actuales de
Parmetros de
clculo
A3
Valores
Actualizados
de Parmetros
de clculo
Parmetros
de Clculo
A3
Parmetros
de Clculo

actualizar parmetros de clculo.
III.C DESCRIPCIN DE LOS PROCESOS
Proceso 1.1 Ingresar Datos del Proyecto

Debe permitir el ingreso de los datos del proyecto. Entre estos datos estn:
fecha de proyecto, nombre, nombre de la aplicacin y cliente. Luego, se
guardan en el almacn de datos A.2 (Mediciones).
Proceso 1.2 Ingresar Transacciones Lgicas
Debe permitir el ingreso (en realizada una descripcin) de las transacciones
lgicas que componen o conforman la aplicacin a medir. Recibe como
entrada los datos del proyecto en el que se desarrolla la citada aplicacin y
produce la actualizacin del almacn de transacciones lgicas (A.1).
Proceso 1.3 Ingresar Elementos de Transacciones Lgicas
Como se ha mencionado en la parte terica, las transacciones lgicas estn
compuestas por entradas, salidas y conceptos. Este proceso debe permitir el
ingreso de esos elementos que se guardan en los almacenes A.4, A.5 y A.6
(figura III.2). Primero se identifica a la transaccin lgica que pertenece a una
aplicacin y luego se ingresan las entradas, salidas y conceptos.
Proceso 1.4 Contabilizar Entradas, Salidas y Conceptos
Este proceso debe permitir contabilizar las entradas, salidas y conceptos. Para
ello debe transformar la descripcin de esos elementos en nmeros o
cantidades de cada una de estas. Ese valor es almacenado en A.2
Proceso 1.5 Actualizar Caractersticas Tcnicas de la Aplicacin a Medir
Debe permitir al usuario ingresar o actualizar valores de caractersticas
tcnicas de la aplicacin. Todas esas actualizaciones se almacenan en A.9
274
Anexo III Modelo de

Proceso 1.6 Contabilizar Caractersticas Tcnicas de la Aplicacin

Debe permitir contabilizar las caractersticas tcnicas de la aplicacin para
obtener los puntos de funcin ajustados.
Proceso 2.1 Realizar Clculos de Mediciones
Debe permitir realizar clculo de las mediciones. Dicho clculo consiste en
determinar los puntos de funcin sin ajustar, en base a la cantidad de
entradas, salidas y conceptos. Adems, obtiene de parmetros de clculo
(A.3), los valores del coeficiente de ajuste lgico (CAL). Una vez obtenido los
puntos de funcin, realiza el clculo del ajuste de complejidad tcnica (ACT),
para obtener los puntos de funcin ajustados. Los resultados de las
mediciones se almacenan en A.2
Proceso 3.1 Recibir Requisitoria de Resultados de Mediciones
Debe permitir realizar consultas de los resultados de las mediciones por
proyecto o por aplicacin, de acuerdo a la requisitoria del usuario. Para ello
consulta el almacn A.2.
Proceso 3.2 Mostrar Resultados de Mediciones
Debe permitir mostrar los resultados de las mediciones por las salidas
especificadas por el usuario.
Proceso 4.1 Ingresar Valores Actualizados de los Parmetros de Clculo
Debe permitir el ingreso (cuando se quieren corregir) de los parmetros que
sirven al clculo de los puntos de funcin sin ajustar y ajustados.
Anexo III Modelo de

275
ANEXO IV
CDIGO
DE LOS
COMPONENTES
DEL
SISTEMA
DE
INFORMACIN
ANEXO IV
CODIGO DE LOS COMPONENTES DEL SISTEMA DE INFORMACIN
IV.A CDIGO DE LOS COMPONENTES DEL SISTEMA DE INFORMACIN
Proceso: ABM de Factores de Ajuste de Complejidad
Tipo de elemento: Formulario
Nombre de Formulario:ABM_AJUSTES_COMPLEJIDAD
Cdigo:
'Texto del Ttulo del Formulario'
Private Sub Etiqueta4_Click()
End Sub
'Ttulo de Columna - Codigo de Factor de Ajuste - '
Private Sub CODFAC_Etiqueta_Click()
End Sub
'Ttulo de Columna - Descripcin de Factor de Ajuste - '
Private Sub DESCRI_Etiqueta_Click()
End Sub
'Ingreso de Valores de Cdigo de Factor de Ajuste'
Private Sub CODFAC_BeforeUpdate(Cancel As Integer)
End Sub
'Boton de Agregar Nuevo Registro'
Private Sub Comando5_Click()
On Error GoTo Err_Comando5_Click
DoCmd.GoToRecord , , acNewRec
Exit_Comando5_Click:
Exit Sub
Err_Comando5_Click:
MsgBox Err.Description
Resume Exit_Comando5_Click
End Sub
'Botn de Eliminar un Registro'
DoCmd.DoMenuItem acFormBar, acEditMenu, 8, , acMenuVer70

Exit Sub
Err_Comando7_Click:
End Sub
'Botn Para ir al Primer Registro'
Anexo IV Cdigo de los

Componentes del Sistema de
Informacin
279
DoCmd.GoToRecord , , acFirst
Exit Sub
Err_Comando11_Click:
End Sub
'Botn Para ir al ltimo Registro'
DoCmd.GoToRecord , , acLast
Exit Sub
End Sub
'Botn Para ir al Siguiente Registro'
DoCmd.GoToRecord , , acNext
Exit Sub
End Sub
'Botn Para ir al Registro Anterior'
DoCmd.GoToRecord , , acPrevious
Exit Sub
End Sub
'Botn Para Salir del Formulario'
280

Informacin
DoCmd.Close
Exit Sub
End Sub
'Ventana de Confirmacin de Eliminacin de Registro'
Dim stDocName As String
stDocName = "CONFIRMACION DE ELIMINACION"
DoCmd.RunMacro stDocName
Exit Sub
End Sub
'Control de Cdigo y Descripcin de Factor de Ajuste'
Dim stDialStr As String
Dim PrevCtl As Control
Const ERR_OBJNOTEXIST = 2467
Const ERR_OBJNOTSET = 91
Const ERR_CANTMOVE = 2483
Set PrevCtl = Screen.PreviousControl
If TypeOf PrevCtl Is TextBox Then
stDialStr = IIf(VarType(PrevCtl) > V_NULL, PrevCtl, "")
ElseIf TypeOf PrevCtl Is ListBox Then
ElseIf TypeOf PrevCtl Is ComboBox Then
Else
stDialStr = ""
End If
Application.Run "utility.wlib_AutoDial", stDialStr
Exit Sub
Err_Comando9_Click:
If (Err = ERR_OBJNOTEXIST) Or (Err = ERR_OBJNOTSET) Or (Err = ERR_CANTMOVE)
Then
Resume Next
Informacin
281
End If
End Sub
Proceso: ABM de Proyectos

Nombre de Formulario:ABM_PROYECTOS
Cdigo:
End Sub
'Para Ubicar un Proyecto Determinado - Antes de Dar Alta se Realiza Esta Operacin'
Private Sub Cuadro_combinado164_AfterUpdate()
' Buscar el registro que coincida con el control.
Dim rs As Object
Set rs = Me.Recordset.Clone
rs.FindFirst "[NUMMED] = " & Str(Nz(Me![Cuadro combinado164], 0))
If Not rs.EOF Then Me.Bookmark = rs.Bookmark
End Sub
'Ttulo de Campo de Fecha de Medicin'
End Sub
'Ingreso de Datos en Campo Fecha de Medicin'
Private Sub Texto41_BeforeUpdate(Cancel As Integer)
End Sub
'Ingreso de Datos en Campo Nombre de Proyecto'
Private Sub NOMPRO_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Nombre de la Aplicacin'
End Sub
'Ingreso de Datos en Campo Nombre de de la Aplicacin'
Private Sub NOMAPL_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Nombre de Cliente'
End Sub
'Ingreso de Datos en Campo Nombre de Cliente'
Private Sub NOMCLI_BeforeUpdate(Cancel As Integer)
End Sub
'Botn de Agregar Nuevo Registro'
Exit Sub
282

Informacin
End Sub

Exit Sub
End Sub
'Botn de Grabar Datos'
DoCmd.DoMenuItem acFormBar, acRecordsMenu, acSaveRecord, , acMenuVer70

Exit Sub
End Sub
'Botn de Salir del Formulario'
DoCmd.Close
Exit Sub
End Sub

Informacin
283
Proceso: ABM de Caractersticas Tcnicas de la Aplicacin

Nombre de Formulario: CARACTERISTICAS TECNICAS
Cdigo:
End Sub
'Ttulo de Columna - Codigo de Factor de Ajuste - '
Private Sub CODFAC_Etiqueta_Click()
End Sub
'Ttulo de Columna - Descripcin de Caracterstica Tcnica de la Aplicacin'
Private Sub DESCRI_Etiqueta_Click()
End Sub
'Ttulo de Columna Valor de la Caracterstica Tcnica de la Aplicacin'
Private Sub VAFAAJ_Etiqueta_Click()
End Sub
'Ingreso de Datos en Campo Cdigo de Factor de Ajuste (Para Caractersticas Tcnicas)'
Private Sub CODFAC_BeforeUpdate(Cancel As Integer)
End Sub
'Ingreso de Datos en Campo Descripcin de Caracterstica'
Private Sub DESCRI_BeforeUpdate(Cancel As Integer)
End Sub
'Ingreso de Datos en Campo Valor de Factor de Ajuste'
Private Sub VAFAAJ_BeforeUpdate(Cancel As Integer)
End Sub
'Botn de Agregar Nuevo Registro'
Exit Sub
Err_Comando8_Click:
End Sub

Exit Sub
Err_Comando9_Click:
284

Informacin
End Sub
'Botn de Salir del Formulario'
DoCmd.Close
Exit Sub
Err_Comando7_Click:
End Sub
Proceso: Consulta (Resumen) de Resultados de Mediciones

Nombre de Formulario: CONS RESULTADO DE MEDICIONES
Cdigo:
End Sub
'Ttulo de Columna Nmero de la Medicin - '
Private Sub NUMMED_Etiqueta_Click()
End Sub
'Ttulo de Columna Cantidad de Entradas - '
End Sub
'Ttulo de Columna Cantidad de Salidas - '
End Sub
'Ttulo de Columna Cantidad de Conceptos - '
End Sub
'Ttulo de Columna Puntos de Funcin Sin Ajustar - '
Private Sub Expr1_Etiqueta_Click()
End Sub
'Ttulo de Columna Ajuste de Complejidad Tcnica - '
End Sub
'Ttulo de Columna Puntos de Funcin Ajustados - '
End Sub
'Ttulo de Columna Productividad - '
End Sub
'Ttulo de Columna Horas Hombre - '
End Sub
'Ttulo de Columna Tiempo en Semanas - '
End Sub
'Ttulo de Columna Costo en $ - '
Informacin
285

End Sub
'Campo Nmero de la Medicin - '
Private Sub NUMMED_BeforeUpdate(Cancel As Integer)
End Sub
'Campo Cantidad de Entradas - '
Private Sub CANENT_BeforeUpdate(Cancel As Integer)
End Sub
'Campo Cantidad de Salidas - '
Private Sub CANSAL_BeforeUpdate(Cancel As Integer)
End Sub
'Campo Cantidad de Conceptos - '
Private Sub CANCON_BeforeUpdate(Cancel As Integer)
End Sub
'Campo Calculado de Puntos de Funcin Sin Ajustar - '
Private Sub Expr1_BeforeUpdate(Cancel As Integer)
End Sub
'Campo Calculado de Ajuste de Complejidad Tcnica - '
End Sub
'Campo Calculado de Puntos de Funcin Ajustados - '
End Sub
'Campo Calculado de Productividad - '
End Sub
'Campo Calculado de Horas Hombre - '
End Sub
'Campo Calculado de Tiempo en Semanas - '
End Sub
'Campo Calculado de Costo en $ - '
End Sub
DoCmd.Close
Exit Sub
End Sub
286

Informacin
Proceso: Consulta (Detalle) de Resultados de Mediciones

Nombre de Formulario: CONS RESULTADO DE MEDICIONES I
Cdigo:
End Sub
'Para Ubicar un Proyecto Determinado'
Dim rs As Object
End Sub
End Sub
'Datos de Campo Fecha de Medicin'
End Sub
'Datos de Campo Nombre de Proyecto'
End Sub
'Datos de Campo de Nombre de la Aplicacin'
End Sub
'Datos de Campo Nombre de de la Aplicacin'
End Sub
End Sub
'Datos de Campo Nombre de Cliente'
End Sub
'Texto del Ttulo de Datos de Entrada'
End Sub
'Ttulo de Cant. De Transacciones Lgicas'
End Sub
'Datos de Campo de Cant. De Transacciones Lgicas'
Private Sub CATRLO_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Cant. De Entradas'
End Sub
'Datos de Campo de Cant. De Entradas'
Private Sub CANENT_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Cant. De Salidas'
End Sub
'Datos de Campo de Cant. De Salidas'
Informacin
287
Private Sub CANSAL_BeforeUpdate(Cancel As Integer)

End Sub
'Ttulo de Cant. De Conceptos'
End Sub
'Datos de Campo de Cant. De Conceptos'
Private Sub CANCON_BeforeUpdate(Cancel As Integer)
End Sub
'Texto del Ttulo de Datos de Salida'
End Sub
'Ttulo de Puntos de Funcin Sin Ajustar'
End Sub
'Datos de Campo de Puntos de Funcin Sin Ajustar'
End Sub
'Ttulo de Factor de Ajuste'
End Sub
'Datos de Campo de Factor de Ajuste'
End Sub
'Ttulo de Puntos de Funcin Ajustados'
End Sub
'Campo de Puntos de Funcin Ajustados'
End Sub
'Ttulo de ndice de Productividad'
End Sub
'Datos de Campo de ndice de Productividad '
End Sub
'Ttulo de Cantidad de Horas Hombre'
End Sub
'Datos de Campo Cantidad de Horas Hombre '
End Sub
'Ttulo de Duracin en Semanas'
End Sub
'Datos de Campo Duracin en Semanas '
End Sub
'Ttulo de Costo Aproximado'
End Sub
'Datos de Campo Costo Aproximado'
End Sub
288

Informacin
DoCmd.Close
Exit Sub
End Sub
Proceso: Consulta de Ajustes de Complejidad Tcnica

Nombre de Formulario: CONS_AJUSTES_COMPLEJIDAD
Cdigo:
End Sub
'Para Ubicar un Registro de Caractersticas Tcnicas de Aplicacin'
Dim rs As Object
rs.FindFirst "[CODFAC] = '" & Me![Cuadro combinado129] & "'"
End Sub
Campo Detalle de Transaccin Lgica de Subformulario
Private Sub Detalle_Click()
End Sub
Campo Valor de Factor de Ajuste de Subformulario
Private Sub VALORES_FACTOR_AJUSTE_Enter()
End Sub
'Botn Para ir al Primer Registro'
DoCmd.GoToRecord , , acFirst
Exit Sub
End Sub
'Botn Para ir al ltimo Registro'
DoCmd.GoToRecord , , acLast

Informacin
289
Exit Sub
End Sub
'Botn Para ir al Siguiente Registro'
DoCmd.GoToRecord , , acNext
Exit Sub
End Sub
'Botn Para ir al Registro Anterior'
DoCmd.GoToRecord , , acPrevious
Exit Sub
End Sub
DoCmd.Close
Exit Sub
End Sub
290

Informacin
Proceso: Ingreso de Conceptos de Transacciones Lgicas

Nombre de Formulario: DTL_CONCEPTOS
Cdigo:
End Sub
'Para Ubicar un Registro de Transacciones Lgicas'
Dim rs As Object
rs.FindFirst "[IDETRA] = " & Str(Nz(Me![Cuadro combinado54], 0))
End Sub
Campo Descripcin de Transaccin Lgica
Private Sub DESTRA_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Identificacin de Transaccin Lgica'
Private Sub IDETRA_Etiqueta_Click()
End Sub
'Datos de Campo Identificacin de Transaccin Lgica'
Private Sub IDETRA_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Nombre de Concepto'
Private Sub NOMCON_Etiqueta_Click()
End Sub
'Datos de Campo Nombre de Concepto'
Private Sub NOMCON_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Breve Descripcin del Concepto'
Private Sub BREDES_Etiqueta_Click()
End Sub
'Datos de Campo Breve Descripcin del Concepto'
Private Sub BREDES_BeforeUpdate(Cancel As Integer)
End Sub
Salir del Formulario Guardando los Cambios
stDocName = "Actualizar_Conceptos"
DoCmd.OpenQuery stDocName
DoCmd.Close
Exit Sub
End Sub
Informacin
291
Proceso: Ingreso de Entradas de Transacciones Lgicas

Nombre de Formulario: DTL_ENTRADAS
Cdigo:
End Sub
Dim rs As Object
End Sub
End Sub
End Sub
End Sub
'Ttulo de Campo de Atributo Relacionado'
Private Sub ATRREL_Etiqueta_Click()
End Sub
'Datos de Campo Atributo Relacionado'
Private Sub ATRREL_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Tipo de Elemento de Entrada'
Private Sub TIELEN_Etiqueta_Click()
End Sub
'Datos de Campo Tipo de Elemento de Entrada'
Private Sub TIELEN_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Breve Descripcin de Entrada'
End Sub
'Datos de Campo Breve Descripcin de Entrada'
End Sub
DoCmd.Close
292

Informacin
Exit Sub
End Sub
Proceso: Ingreso de Salidas de Transacciones Lgicas

Nombre de Formulario: DTL_SALIDAS
Cdigo:
End Sub
Dim rs As Object
End Sub
End Sub
End Sub
End Sub
'Ttulo de Campo de Atributo Relacionado'
Private Sub ATRREL_Etiqueta_Click()
End Sub
'Datos de Campo Atributo Relacionado'
Private Sub ATRREL_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Tipo de Elemento de Salida'
Private Sub TIELSA_Etiqueta_Click()
End Sub
'Datos de Campo Tipo de Elemento de Entrada'
Private Sub TIELSA_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Breve Descripcin de Salida'
End Sub
'Datos de Campo Breve Descripcin de Salida'
End Sub
Informacin
293

DoCmd.Close
Exit Sub
End Sub
Proceso: ABM de Transacciones Lgicas

Nombre de Formulario: DTL_FORMULARIO
Cdigo:
End Sub
Dim rs As Object
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
294

Informacin

End Sub
End Sub
'Ttulo de Campo de Nmero de Medicin'
Private Sub NUMMED_Etiqueta_Click()
End Sub
'Datos de Campo Nmero de Medicin '
Private Sub NUMMED_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Descripcin de Transaccin Lgica'
Private Sub DESTRA_Etiqueta_Click()
End Sub
'Datos de Campo Descripcin de Transaccin Lgica'
End Sub
DoCmd.Close
Exit Sub
End Sub
Proceso: Actualizacin de Parmetros de Clculo

Nombre de Formulario: PARAMETROS_DE_CALCULO
Cdigo:
End Sub
'Ttulo de Campo Coeficiente CAL Para Entradas'
Private Sub VACAEN_Etiqueta_Click()
End Sub
'Datos de Campo Coeficiente CAL Para Entradas'
Private Sub VACAEN_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo Coeficiente CAL Para Salidas'
Private Sub VACASA_Etiqueta_Click()
End Sub
'Datos de Campo Coeficiente CAL Para Salidas'
Private Sub VACASA_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo Coeficiente CAL Para Conceptos'
Informacin
295
Private Sub VACACO_Etiqueta_Click()

End Sub
'Datos de Campo Coeficiente CAL Para Conceptos'
Private Sub VACACO_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo Coeficiente de Ajuste de Complejidad Tcnica'
Private Sub VALCO1_Etiqueta_Click()
End Sub
'Datos de Campo Coeficiente de Ajuste de Complejidad Tcnica '
Private Sub VALCO1_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo Coeficiente de Variacin de Ajuste de Complejidad Tcnica'
Private Sub VALCO2_Etiqueta_Click()
End Sub
'Datos de Campo Coeficiente de Variacin de Ajuste de Complejidad Tcnica '
Private Sub VALCO2_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo Costo de Hora de Trabajo'
Private Sub COSHOR_Etiqueta_Click()
End Sub
'Datos de Campo Costo de Hora de Trabajo'
Private Sub COSHOR_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo Cantidad de Hs. de Trabajo Por Semana'
Private Sub HORSEM_Etiqueta_Click()
End Sub
'Datos de Campo Cantidad de Hs. de Trabajo Por Semana'
Private Sub HORSEM _BeforeUpdate(Cancel As Integer)
End Sub
DoCmd.Close
Exit Sub
End Sub
Proceso: Ingreso de Caractersticas de la Aplicacin a Medir

Nombre de Formulario: PF_MEDICION
Cdigo:
296

Informacin
End Sub
Dim rs As Object
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
Ttulos de los Campos de Ajuste de Complejidad Tcnica de la Aplicacin
Para Determinar el Factor de Ajuste
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
Informacin
297
End Sub
End Sub
End Sub
Cuadros Combinados Para Recibir Valor de Descripcin de la Caracterstica Tcnica
Private Sub Cuadro_combinado87_BeforeUpdate(Cancel As Integer)
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
End Sub
Campos Que Reciben Valores de la Caracterstica Tcnica
Private Sub CDI_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub EUF_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub FAI_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub FAO_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub FCD_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub PMU_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub RAP_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub REN_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub REU_BeforeUpdate(Cancel As Integer)
End Sub
Private Sub UPR_BeforeUpdate(Cancel As Integer)
End Sub
Botn de Mostrar Resultados de Medicin Abre el Formulario Correspondiente
Dim stLinkCriteria As String
stDocName = "RESULTADOS_MEDICION"
stLinkCriteria = "[NUMMED]=" & Me![NUMMED]
DoCmd.OpenForm stDocName, , , stLinkCriteria
298

Informacin
Exit Sub
End Sub
Salir del Formulario
DoCmd.Close
Exit Sub
End Sub
Proceso: Mostrar Resultados de Mediciones

Nombre de Formulario: RESULTADOS_MEDICION
Cdigo:
End Sub
'Ttulo de Campo de Puntos de Funcin Para SBC'
Private Sub PFSBC_Etiqueta_Click()
End Sub
'Datos de Puntos de Funcin Para SBC '
Private Sub PFSBC_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Ajuste de Complejidad Tcnica'
Private Sub ACT_Etiqueta_Click()
End Sub
'Datos de Ajuste de Complejidad Tcnica'
Private Sub ACT_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Puntos de Funcin Ajustados Para SBC'
Private Sub PFASBC_Etiqueta_Click()
End Sub
'Datos de Puntos de Funcin Ajustados Para SBC '
Private Sub PFASBC_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Productividad'
Private Sub PRODUC_Etiqueta_Click()
End Sub
'Datos de Productividad'
Private Sub PRODUC_BeforeUpdate(Cancel As Integer)
Informacin
299
End Sub
'Ttulo de Campo de Esfuerzo'
Private Sub ESFUER_Etiqueta_Click()
End Sub
'Datos de Esfuerzo'
Private Sub ESFUER_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Tiempo de Desarrollo'
Private Sub TIEMPO_Etiqueta_Click()
End Sub
'Datos de Tiempo de Desarrollo'
Private Sub TIEMPO_BeforeUpdate(Cancel As Integer)
End Sub
'Ttulo de Campo de Costo de Desarrollo'
Private Sub COSTO_Etiqueta_Click()
End Sub
'Datos de Costo de Desarrollo'
Private Sub COSTO_BeforeUpdate(Cancel As Integer)
End Sub
Salir del Formulario
DoCmd.Close
Exit Sub
End Sub
Proceso: Mostrar Resultados de Mediciones (Impresora)

Tipo de elemento: Reporte
Nombre de Formulario: RESULTADOS_MEDICIONES
Cdigo:
Private Sub Detalle_Format(Cancel As Integer, FormatCount As Integer)
End Sub
Private Sub EncabezadoDelInforme_Format(Cancel As Integer, FormatCount As Integer)
End Sub
Private Sub PieDelInforme_Format(Cancel As Integer, FormatCount As Integer)
End Sub
Private Sub Report_Open(Cancel As Integer)
End Sub
Private Sub SeccinEncabezadoDePgina_Format(Cancel As Integer, FormatCount As
Integer)
End Sub
300

Informacin
Private Sub SeccinPieDePgina_Format(Cancel As Integer, FormatCount As Integer)

End Sub
Private Sub SeccinPieDePgina_Print(Cancel As Integer, PrintCount As Integer)
End Sub
Proceso: Mostrar Resultados de Mediciones Datos de Proyecto y Valores

(Impresora)
Tipo de elemento: Reporte
Nombre de Formulario: RESULTADOS_MEDICIONES_I
Cdigo:
Private Sub Detalle_Format(Cancel As Integer, FormatCount As Integer)
End Sub
Private Sub EncabezadoDelInforme_Format(Cancel As Integer, FormatCount As Integer)
End Sub
Private Sub PieDelInforme_Format(Cancel As Integer, FormatCount As Integer)
End Sub
Private Sub Report_Open(Cancel As Integer)
End Sub
Private Sub SeccinEncabezadoDePgina_Format(Cancel As Integer, FormatCount As
Integer)
End Sub
Private Sub SeccinPieDePgina_Format(Cancel As Integer, FormatCount As Integer)
End Sub
Private Sub SeccinPieDePgina_Print(Cancel As Integer, PrintCount As Integer)
End Sub

Informacin
301
ANEXO V
GESTIN
DE LA
CONFIGURACIN
ANEXO V
GESTIN DE LA CONFIGURACIN
V.A INTRODUCCIN
En este anexo se muestran los informes correspondientes a la gestin de la

configuracin.
V.B INFORMES
B.1 Informe de Estado:

En la tabla V.1 se muestra el estado de la configuracin de la ltima
versin.
Anexo V Gestin de la
Configuracin
305

Al 15/07/2006
Ubicacin
Lnea
Id. en el
en el
Tipo de
Elementos de Configuracin
Base
Captulo
Trabajo de
Elem
Tesis
Procesos y actividades incluidas
Tabla 7.1
Captulo VII Tabla
en la construccin del software
Tabla 7.8
Captulo VII Tabla
Planificacin temporal
Figura 7.1 Captulo VII Figura
Funcio
Tablas VI.1
nal Aseguramiento de la calidad
Anexo VI
Tablas
a VI.5
ltimo estado de la configuracin Tabla V.1 Anexo V
Tabla
Identificacin de la configuracin
Tabla 7.9
Captulo VII Tabla
(lnea base)
Diagrama de contexto
Figura 8.1 Captulo VIII Diagrama
Diagrama entidad-relacin
Diagrama de casos de uso
Catlogo de requisitos
Tabla 8.6
Captulo VIII Tabla
Especificacin de pantallas y
Tabla 8.7
Captulo VIII Tabla
reglas de validacin
Ult.Fecha
Modif
Versin
01/07/2006
1.8
22/02/2006
22/02/2006
1.5
1.5
01/07/2006
1.1
01/07/2006
1.8
01/07/2006
1.8
20/02/2006
20/02/2006
20/02/2006
20/02/2006
1.5
1.5
1.5
1.5
20/02/2006
1.5
20/02/2006
1.5
Captulo VIII Tabla
20/02/2006
1.5
Captulo VIII Tabla
20/02/2006
1.5
Captulo VIII Tabla
20/02/2006
1.5
Requisitos del entorno de pruebas Tabla 8.11
Captulo VIII Tabla
20/02/2006
1.5
Tipos o niveles de error

Criterios y niveles de aceptacin
de los tipos de prueba
Tabla 8.12
Captulo VIII Tabla
20/02/2006
1.5
Tabla 8.13
Captulo VIII Tabla
20/02/2006
1.5
Anexo III
Diagrama
20/02/2006
1.5
Anexo III
Diagrama
20/02/2006
1.5
Anexo III
Diagrama
20/02/2006
1.5
Anexo III
Diagrama
20/02/2006
1.5
Anexo III
Diagrama
20/02/2006
1.5
Anexo III
Documento 20/02/2006
1.5
Diagrama
20/02/2006
1.5
Tabla
20/02/2006
1.5
Modelo de navegacin de pantallas Figura 8.24 Captulo VIII Diagrama

Especificacin de requisitos del
Tabla 8.8
software
Perfiles y objetivos de los distintos
Tabla 8.9
tipos de pruebas
Enfoques y criterios de seleccin
Tabla 8.10
de tipos de pruebas
Figura
B.III.1
Nivel 2 - Subsistema de ingreso de Figura
datos de la aplicacin a medir
B.III.2
Nivel 2 - Subsistema de clculo de Figura
valores de la medicin
B.III.3
Nivel 2 - Subsistema de mostrar
Figura
resultados de la medicin
B.III.4
Nivel 2 - Subsistema de
Figura
actualizacin de parmetros de
B.III.5
clculo
Nivel 1 - Subsistemas de anlisis
Descripcin de los procesos
III.C
Diagrama de entidades, relaciones

e identificadores normalizada
Figura A.II.1 Anexo II
(3FN)
Correspondencia entre nombres
de entidades y tablas de la base de Tabla C.II.2 Anexo II
datos
Tabla A.V.1. ltimo estado de la configuracin.
306
Configuracin

Al 15/07/2006
Ubicacin
Lnea
Id. en el
en el
Tipo de
Elementos de Configuracin
Base
Captulo
Trabajo de
Elem
Tesis
Diagrama de despliegue
Figura 9.1 Captulo IX Diagrama
Catlogo de excepcin de rango
Tabla 9.1 Captulo IX Tabla
de valores
Catlogo de excepcin de ruptura
de integridad referencial
Catlogo de Excepcin de Texto
no Existente en Lista de Valores
Diagrama de Estructuras
Figura 9.2 Captulo IX Diagrama
Proceso de Ingresar Datos del
Proyecto
Proceso de Ingresar Descripciones
de Transacciones Lgicas
Proceso de Ingresar Entradas de
Proceso de Ingresar Salidas de
Proceso de Ingresar Conceptos de
Ingreso de Caractersticas de la
Aplicacin a Medir
Diseo
Realizar Medicin del Tamao de
la Aplicacin
Consultas (resumen) resultado de
mediciones
Actualizacin de parmetros de
clculo
Actualizacin de valores de
caractersticas tcnicas
Mostrar parmetros de clculo
Procedimientos relacionados con
medidas de seguridad
tecnolgico para la construccin
tecnolgico para las pruebas
Detalle de pruebas unitarias
Distribucin y ordenamiento lgico
de los mdulos
Especificacin de los casos de
prueba del sistema
Documentacin del cdigo de los
componentes de los mdulos
Cdigo de los componentes del
sistema de informacin
Produc Resultados de la ejecucin de las
to
pruebas unitarias
Resultado de la ejecucin de las
pruebas de integracin
Resultado de la ejecucin de las
pruebas del sistema
Operati
va
Manual del usuario
Ult.Fecha
Modif
Versin
20/02/2006
1.3
20/02/2006
1.3
20/02/2006
1.3
20/02/2006
1.3
20/02/2006
1.3
20/02/2006
1.3
Tabla 9.5 Captulo IX
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Tabla
20/02/2006
1.3
Figura 9.7 Captulo IX
Grfico
20/02/2006
1.3
Tabla
20/02/2006
1.3
1.4
Programa
13/01/2006
1.4
Tabla 10.1 Captulo X
Tabla
13/01/2006
1.4
Tabla
13/01/2006
1.4
Tabla
13/01/2006
1.4
1.5
Base de
datos
1.5
IV.A
Anexo IV
Anexo VII
Software ejecutable
13/01/2006
Tabla A.V.1. ltimo estado de la configuracin (continuacin).

Configuracin
307
B. 2 Informes de Auditoria:
La auditoria se llevo a cabo una vez terminada la versin definitiva de los
productos incluidos en el proyecto. En las tablas V.2, V.3 y V4 se presentan los
resultados de las mismas.
Sistema ESTIMSBC
Fecha 22/02/2006 Versin 1.3
Firma
Elemento de configuracin auditado
Resultado
Observaciones
Dminio del problema
OK
Corregido
Correcciones sugeridas por el Director de
Definicin del proyecto de desarrollo del
software
Tesis el 14/02/2006
Planificacin general del proyecto de desarrollo
Corregido
del software
Tesis el 14/02/2006
Anlisis del sistema de informacin
Corregido
Tesis el 14/02/2006
Diseo del sistema de informacin
Corregido
Tesis el 14/02/2006
Construccin del sistema de informacin
Corregido
Tesis el 14/02/2006
Implementacin del sistema de informacin
Corregido
Tesis el 14/02/2006
Evaluacin del sistema de informacin
OK
Ok
Cdigo del producto
Tesis entre el 22/12/2005 y el 26/12/2005
Ok
Software ejecutable
Tesis entre el 22/12/2005 y el 26/12/2005
Documentacin complementaria
Corregido
Tesis el 14/02/2006
Responsable Ing. Jos Daniel Ovejero
Tabla A.V.2. Resultado de auditoria funcional.

Auditora Fsica
Sistema ESTIMSBC
Responsable Ing. Jos Daniel Ovejero Fecha 13/01/2006
Lnea Base de Auditora
Funcional
Diseo
Producto
Operativa
Varios
Resultado
Corregido
Corregido
Corregido
OK
Corregido
Versin 1.0
Firma
Observaciones
Tabla A.V.3. Resultado de auditoria fsica.
308
Configuracin
Certificacin
Sistema ESTIMSBC
Responsable Ing. Jos Daniel Ovejero Fecha 13/01/2006
Elemento de Configuracin Auditado
Software ejecutable
Resultado
Corregido
Versin 1.0
Firma
Observaciones
Han surgido algunas correcciones de
las pruebas unitarias, de integracin
y del sistema las cuales fueron
llevadas a cabo y corregido el
sistema con xito.
Tabla A.V.4. Resultado de auditoria de certificacin.
Configuracin
309
ANEXO VI
GESTIN
DE LA
CALIDAD
ANEXO VI
GESTIN DE LA CALIDAD
VI.1 LISTAS DE VERIFICACIN
En este anexo se muestran una serie de listas de verificacin incluidas en

el proceso de Aseguramiento de la Calidad, especificado en el Captulo VII
(puntos 7.10.1. a 7.10.5). Se muestran cinco (5) tablas (de la VI.1 a VI.5) con
los respectivos procesos de verificacin.
Sistema.
ESTIMSBC
Lista de Verificacin
Fecha:01/06/2006
Lugar
Versin: 001
Inicio: 17:00
Fin: 17:40
Revisin del Catlogo de Requisitos

Grado de Cumplimiento
Total
Parcial
Ninguno
Los requisitos son claros?
X
Los requisitos son contradictorios?
X
X
Los requisitos son imposibles de probar?
Los requisitos son relevantes?
X
Son importantes para la solucin del problema?
X
Son testeables por un grupo independiente?
X
Cumplen con los objetivos principales del sistema?
X
Observaciones: Debido a que no existe un grupo interdisciplinario para la evaluacin y testeo del
sistema, las pruebas y, o ensayon estrn a cargo del autor del proyecto.
Elementos
Tabla VI.1. Lista de verificacin de catlogo de requisitos.

Sistema.
ESTIMSBC
Fecha:01/06/2006
Lugar
Versin: 001
Inicio: 18:00
Fin: 18:40
Revisin de la Consistencia Entre Productos

Elementos
anlisis?
Cada clase de anlisis tiene su correspondiente descripcin?
uso, diagrama de anlisis y descripcin?
Observaciones:
Total
Parcial
Ninguno
X
X
X
Tabla VI.2. Lista de verificacin de revisin de la consistencia entre productos.
Anexo VI Gestin de la
Calidad
313
Sistema.
ESTIMSBC
Fecha:01/06/2006
Lugar
Versin: 001
Inicio: 19:00
Fin: 19:40
Revisin de la Consistencia Entre Productos del Diseo

Total
Parcial
Ninguno
Elementos
clases de anlisis y de diseo?
Cada clase de diseo tiene su correspondiente descripcin?
uso, diagrama de diseo y descripcin?
Observaciones:
X
X
X
Tabla VI.3. Lista de verificacin de revisin de la consistencia entre productos

del diseo.
Sistema.
ESTIMSBC
Fecha:01/06/2006
Lugar
Versin: 001
Inicio: 20:00
Fin: 20:40
Revisin de las Pruebas Unitarias, de Integracin y del Sistema

Elementos
Se prueba cada elemento de diseo?
Se realiza una prueba de interfaz entre mdulos?
Los casos de prueba testean todos los procesos?
Observaciones:
Total
Parcial
Ninguno
X
X
X
X
Tabla VI.4. Lista de verificacin de revisin de las pruebas unitarias, de

integracin y del sistema.
Sistema.
ESTIMSBC
Fecha:01/06/2006
Lugar
Versin: 001
Inicio: 21:00
Fin: 21:40
Revisin de las Pruebas de Aceptacin del Sistema

Elementos
Se confecciona una tabla de derivacin de los casos de prueba?
Observaciones:
Total
Parcial
Ninguno
X
X
Tabla VI.5. Lista de verificacin de revisin de las pruebas de aceptacin del

sistema.
314
Anexo VI Gestin de la
Calidad
ANEXO VII
VII
MANUAL
DEL
USUARIO
ANEXO VII
MANUAL DEL USUARIO
VII.1 INDICE DEL MANUAL DEL USUARIO
Tema
Pg.
VII.1 Introduccin ..
VII.2 Requerimientos del Sistema ..
VII.3 Ingreso al Sistema ..
VII.4 Descripcin de las Opciones Principales
VII.5 Descripcin de cada una de las Opciones Principales
VII. 5.1 Ingreso de Datos de la Aplicacin a Medir .
VII. 5.2 Consulta de Valores y Resultados ...
VII. 5.3 Reportes y Listados de Proyectos
VII. 5.4 Actualizacin de Parmetros de Clculos
318
318
318
319
321
322
327
329
330
Anexo VII Manual del

Usuario
317
VII.2 INTRODUCCIN
En este anexo se exhibe una serie de recomendaciones acerca de como

usar la herramienta de software ESTIMSBC, que mide el tamao aproximado
de un producto software a desarrollar y reporta indicadores de tiempo, costo y
esfuerzo necesarios para acometer dicho desarrollo.
VII.3 REQUERIMIENTOS DEL SISTEMA
En el captulo VIII (tabla 8.1) se han enunciado los requisitos de operacin.

El sistema se ha construido para ser usado con sistemas informticos con las
caractersticas que se exhiben en la tabla VI.1.
Sistema operativo
Base de datos
Velocidad del procesador
Memoria RAM
Windows XP, 2000 o superior

Access 2002 V 10.2627.2625 o superior
500 Mhz o superior
256 Mb. o superior
Tabla VII.1. Requerimientos del sistema informtico para correr la

aplicacin ESTIMSBC.
VII.4 INGRESO AL SISTEMA
La aplicacin tiene como forma de acceder un cono que se puede ubicar

en el escritorio de la PC. Cuando se pulsa (accin de hacer clic con el mouse
en un cono), automticamente se cargan los archivos de la base de datos
como para que empiece a funcionar. En primer lugar aparece una pantalla que
solicita el ingreso de un usuario y una contrasea, tal como lo ilustra la figura
VII.1.
Figura VII.1. Pantalla de ingreso al sistema.

318

Usuario
Una vez que el usuario se registra y es validado por el sistema,

automticamente se dirige hacia un men que le permite ir hacia una de las
cuatro opciones principales. Ellas son:
Ingreso de datos de la aplicacin: permite ingresar todos los valores y

datos relativos a la aplicacin que se est por someter a la medicin.
Consulta de valores y resultados: permite visualizar los resultados de

mediciones ya efectuadas a diferentes proyectos y consultar valores de
parmetros de clculo.
Reportes y listados de proyectos: permite emitir reportes de datos de los

proyectos que han sido sometidos a mediciones con sus
correspondientes resultados.
Actualizacin de parmetros: permite actualizar los parmetros con los

que se rige el software para llevar a cabo las mediciones.
VII.5 DESCRIPCIN DE LAS OPCIONES PRINCIPALES
El despliegue de estas cuatro opciones que se han mencionado en el punto

anterior, puede verse en la figura VII.2.
Figura VII.2. Pantalla de men principal de opciones.

A continuacin se exploran una a una las distintas opciones presentadas
por este men. La primera de ellas es la de Ingreso de Datos de la
Aplicacin. Esta alternativa est compuesta a su vez por un men que dirige
al usuario por todas aquellas funciones que permiten ingresar los datos de la
aplicacin a medir. Este men o submen puede verse en la figura VII.3.

Usuario
319
Figura VII.3. Submen de ingreso de datos de la aplicacin a medir.

La segunda de las opciones del men de la figura VII.2 es Consulta de
Valores y Resultados de Mediciones. Tambin esta alternativa presenta a su
vez un submen, tal como se muestra en la figura VII.4.
Figura VII.4. Submen de consulta de valores y resultados de mediciones.

La tercera alternativa del men de la figura VII.2 es la de Reportes y
Listados de Proyectos. Esto permite emitir reportes de los proyectos y los
resultados arrojados por las mediciones de cada uno de ellos. Esta opcin se
puede visualizar en la figura VII.5.
320

Usuario
Figura VII.5. Submen de reportes y listado de mediciones.

Por ltimo, la cuarta opcin disponible corresponde a la de Actualizacin
de Parmetros de Clculo. En este submen, estn todas las opciones de
modificacin de los parmetros que rigen los clculos de las mediciones (figura
VII.6).
Figura VII.6. Submen de actualizacin de parmetros de clculo.

VII.6 DESCRIPCIN DE CADA UNA DE LAS OPCIONES PRINCIPALES
A continuacin, se realiza una descripcin detallada de cada una de las

opciones principales presentadas en los prrafos anteriores. La lectura de
Usuario
321
dicha descripcin permitir al usuario conocer la forma en que opera la

herramienta de software.
VII. 6.1 INGRESO DE DATOS DE LA APLICACIN A MEDIR
Esta alternativa, permite ingresar los valores de la aplicacin a medir.

Como se ha mencionado, ESTIMSBC es una herramienta orientada al
encargado o jefe de un proyecto de desarrollo de sistemas; en este caso
particular para SSBBCC.
Como se puede exhibir en la figura VII.3, esta alternativa permite realizar
las siguientes funciones:
a.
b.
c.
d.
e.
f.
ABM de datos del proyecto.

ABM de transacciones lgicas.
ABM de entradas de transacciones lgicas
ABM de salidas de transacciones lgicas
ABM de conceptos de transacciones lgicas
Ingreso de caractersticas tcnicas de la aplicacin a medir
En la primera de estas opciones (ABM de datos del proyecto) se pueden

ingresar los datos del proyecto o del software que se est sometiendo a una
medicin. La figura VII.7, muestra una pantalla que realiza esta funcin.
Figura VII.7. Pantalla de ABM de datos del proyecto.

El ingreso de datos del proyecto se realiza siguiendo los siguientes pasos:
322
i)
Cuando se abre la pantalla de la figura VII.7, aparece en la parte

inferior un grupo de cuatro botones. El primero de la izquierda
es
el que habilita al operador para ingresar (dar de alta) los datos del
proyecto. El nmero de la medicin es el primer campo que
aparece en la pantalla, el cual es generado automticamente por el
sistema; es decir, el usuario no debe ingresar aqu un valor.
ii)
El primer valor que debe incorporar al sistema el usuario es la fecha

de medicin. Por defecto, la fecha que est colocada en el sistema

Usuario
es la actual. De todos modos si el usuario decidiera colocar una

fecha diferente, es decir anterior a la actual, el sistema permitir
hacerlo. En este punto existe un control por parte del sistema; esto
significa que los valores correspondientes al mes, al da y al ao
debern ser vlidos.
iii)
Los datos que se deben ingresar a continuacin en el sistema son:

nombre del proyecto, nombre de la aplicacin y nombre del
cliente. Estos datos representan al proyecto, el nombre de la
aplicacin y por ltimo el nombre del cliente. Los mismos son
obligatorios; es decir el casillero del campo (o caja de edicin) donde
debe ser cargado debe tener algn valor. Esta es el nico control
que se realiza para estos tres campos.
iv)
En la parte inferior de la pantalla hay un juego de cuatro botones: el

tercero comenzando de la izquierda (
) es el que debe ser
presionado para que queden grabados los datos en el sistema.
v)
Otras operaciones que se pueden realizar son la modificacin y la

eliminacin (o baja) de datos de proyectos. En el primer caso, lo
que se debe hacer cuando se convoca a la pantalla es abrir una lista
de valores que corresponde a los proyectos que ya estn cargados
en el sistema (figura VII.8). Luego se selecciona uno de ellos y se
procede a modificar los datos segn los requerimientos del usuario.
Figura VII. 8. Lista de seleccin de nmero y nombre del proyecto.

vi)
En el caso de eliminacin o baja, una vez que se encuentran en

pantalla los datos, se los puede eliminar con el botn situado en la
parte inferior de la pantalla
. Si el usuario quisiera borrar un
proyecto para el cual se han cargado o generado transacciones
lgicas, el sistema le devolver un mensaje de error debido a que
estara quebrantando una regla de integridad referencial.
vii)
Por ltimo, para salir de esta pantalla, se lo puede hacer con el

botn correspondiente

Usuario
323
La segunda de las opciones de este grupo es la de ABM de transacciones

lgicas. Esta funcin permite el ingreso de las transacciones lgicas que han
sido identificadas por el usuario. La pantalla que ejecuta esta funcin se exhibe
en la figura VII.9.
Figura VII.9. Pantalla de ABM de transacciones lgicas.

Como se puede apreciar en la figura VII.9, las transacciones lgicas
pertenecen a un proyecto en particular; es decir, cada proyecto o cada
aplicacin tiene su juego o conjunto de transacciones lgicas. Por ello, y tal
como se puede ver en la figura VII.9, lo primero que se hace en esta funcin es
seleccionar un proyecto de una lista. Una vez hecho esto, en el subformulario
correspondiente se carga los datos de la transaccin lgica (figura VII.10).
Figura VII.10. La zona marcada con rojo indica el sub-formulario de carga de

transacciones lgicas.324

Usuario
Como se puede apreciar en la figura VII.10, la zona marcada con rojo

indica el sub-formulario donde se pueden ingresar, eliminar o modificar los
datos correspondientes a las transacciones lgicas pertenecientes a un
proyecto.
La funcin que sigue a continuacin permite ingresar, borrar o modificar
(ABM) las entradas de las transacciones lgicas. Primero, se elige de una lista
una transaccin lgica perteneciente a un proyecto. Luego, en el sub-formulario
se pueden realizar cualquiera de estos tres movimientos (ABM). La figura
VII.11, grafica esta operacin.
Figura VII.11. ABM de entradas de transacciones lgicas.

De igual forma se procede con las salidas y los conceptos. Se selecciona
una transaccin lgica y luego de ingresan los elementos correspondientes a
dicha transaccin lgica.
Una vez que se han identificado e ingresado los datos del proyecto,
transacciones lgicas y elementos de cada una de estas, el sistema estar en
condiciones de contabilizar la cantidad de entradas, salidas y conceptos. Estos
datos son importantes a la hora de realizar los clculos para determinar el
tamao aproximado de la aplicacin a medir.
Por ltimo y para completar con todas las entradas relativas al proyecto, se
cargan en el sistema las caractersticas del entorno de desarrollo. Por defecto
se tienen diez (10) caractersticas y cada una de ellas toma un valor inicial de
uno (1). La pantalla de la figura VII.12 muestra esta situacin.

Usuario
325
Cada una de estas caractersticas, debe tener un valor comprendido entre

uno (1) y cinco (5). Si se ingresa un valor que no est comprendido en este
rango, el sistema devolver automticamente un mensaje de error.
Figura VII.12. Ingreso o carga de caractersticas del entorno de desarrollo.

Una vez ingresados los valores correspondientes a las diez caractersticas
de la aplicacin, se puede pulsar el botn de mostrar los resultados de la
y automticamente se dispara un evento que muestra la
medicin
pantalla de la figura VII.13.
326

Usuario
Figura VII.13. Pantalla de mostrar los resultados de la medicin.Como se puede apreciar en la pantalla de la figura VII.13, se muestran los
resultados correspondientes a los puntos de funcin sin ajustar, el factor de
ajuste y los puntos de funcin ajustados. Adems de estos valores, el sistema
muestra la productividad que es un indicador de la cantidad de puntos de
funcin producidos, el esfuerzo necesario expresado en horashombre, la
cantidad aproximada de semanas que lleva el desarrollo y el costo total
aproximado.
VII. 6.2 CONSULTA DE VALORES Y RESULTADOS
Una vez que se han ingresado los datos y se han efectuado las
mediciones, se puede hacer consultas de los resultados. La pantalla de la
figura VII.14 muestra un formato en columnas de los proyectos y sus resultados
estimativos.

Usuario
327
Figura VII.14. Resumen de resultado de mediciones.

En esta pantalla se puede observar un formato resumido, el cual
precisamente por tener estas caractersticas carece de caracteres descriptivos
como por ejemplo el nombre del proyecto o el nombre de la aplicacin. Las
columnas indican entre otros valores, el nmero de la medicin, la cantidad de
entradas, salidas y conceptos y los valores aproximados arrojados por las
estimaciones. Este tipo de pantalla sirve ms para comparar los valores de un
proyecto frente a otro.
Si el usuario desea ver en forma detallada los resultados de las
mediciones, puede acudir a la pantalla de la figura VII.15.
Figura VII.15. Detalle de resultado de mediciones.

328

Usuario
Una vez que se han mostrado las pantallas de resumen y detalle de los
resultados, se exhiben dos pantallas de consultas que son complementarias y
le permiten al usuario en la primera (figura VII.16) hacer una recorrida por los
factores de ajuste de complejidad tcnica (en realidad son diez (10)) y en la
segunda (figura VII.17), ver en detalle que valores puede tomar cada uno de los
tems de los ajustes de complejidad tcnica. A cada uno de estos valores, el
encargado del proyecto los debe relacionar con las caractersticas del entorno
de desarrollo.
Figura VII.16. Consulta de factores de ajuste de complejidad tcnica.
Figura VII.17. Consulta de tems de factores de ajuste de complejidad tcnica.

VII. 6.3 REPORTES Y LISTADOS DE PROYECTOS
La tercera de las cuatro opciones presentadas en el punto VII.3, es la de

reportes y listados de proyectos. Permite listar por el dispositivo de impresin,
los proyectos y los resultados de las mediciones. Debido a la particularidad de
este trabajo, no se han construido ms tipos de listados; pues simplemente
cumple con un requerimiento curricular. Las figuras VII.18 y VII.18, muestra una
pantalla previa de este estilo de reporte.

Usuario
329
Figura VII.18. Lista de proyectos medidos.
Figura VII.19. Lista de proyectos, datos de entrada y salida (o resultados).

VII. 6.4 ACTUALIZACIN DE PARMETROS DE CLCULO
Esta ltima opcin, es la que le permite al usuario actualizar los

parmetros que utiliza el software para realizar los clculos. Dichos parmetros
son:
330
Coeficiente de ajuste lgico (CAL) para entradas: en un principio este

valor es de 0.800. El usuario puede alterar este valor, pero debe tener la
precaucin de cargar al sistema con valores que realmente arrojen
resultados confiables.
Coeficiente de ajuste lgico (CAL) para salidas: al igual que el atributo

anterior, este en un principio toma el valor de 0.800 y tambin puede
ser modificado.
Coeficiente de ajuste lgico (CAL) para conceptos: este atributo toma

un valor igual a 1.200; es decir, a diferencia de los anteriores, por
encima de la unidad. Tambin puede ser alterado por el usuario.

Usuario
Coeficiente de Ajuste de Complejidad Tcnica (ACT): este valor es de

0.035 y tambin se lo puede modificar.
Coeficiente de Variacin de ACT: toma por defecto en valor de 0.650 y

tambin puede ser modificado.
Costo de Honorarios por Hora de Trabajo: es un costo que puede variar

segn la regin donde se realice el desarrollo del software. En un
principio es de cincuenta unidades monetarias. Para la regin donde se
ha desarrollado la herramienta de medicin corresponde a la moneda
pesos.
Horas de Trabajo Por Semana: son las horas estipuladas o convenidas

como jornada de trabajo para una semana. Por ejemplo si las horas de
trabajo por da son ocho (8), las horas de trabajo semanal sera de
cuarenta (40).
En la figura VII.20, se muestra una pantalla que permite la actualizacin de

estos valores.
Figura VII.20. Pantalla de actualizacin de parmetros de clculo.

Otra opcin de este submen es la actualizacin (ABM) de las
caractersticas tcnicas de la aplicacin a medir. La figura VII.21, muestra un
modelo de pantalla para esta funcin.

Usuario
331
Figura VII.21. Pantalla de actualizacin (ABM) de caractersticas tcnicas de la

aplicacin.
Cuando se quiere dar de alta una caracterstica, hay que tener en cuenta
que esta debe pertenecer a algunas de las diez (10) caractersticas de factores
de ajuste de complejidad tcnica de las figuras VII.12 y VII.16. Cuando se pulsa
), el sistema le brinda al usuario la posibilidad de
el botn de agregar (
ingresar los valores de una caracterstica tcnica de la aplicacin. El primer
dato que debe ingresar es el cdigo de factor de ajuste, luego la descripcin de
la caracterstica (debe ser representativo de esta) y por ltimo, el valor de la
caracterstica que debe estar comprendido entre uno (1) y cinco (5). La figura
VII.22, muestra una pantalla de este tipo.
Figura VII.22. Alta de caracterstica tcnica de la aplicacin a medir.

Las otras dos operaciones que se pueden realizar es la de modificar y
), siempre y cuando no se rompan las reglas de integridad
borrar (
referencial. Si el usuario estara ante esta situacin, el sistema emite un
mensaje de error.
332

Usuario

Ovejero Tesisdemagister

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ovejero Tesisdemagister

Enviado por

Direitos autorais:

Formatos disponíveis

TESIS DE MAGISTER

EN INGENIERA DEL SOFTWARE

Estimacin de Proyectos Para

AUTOR : ING. JOS DANIEL OVEJERO

BUENOS AIRES, 2006

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

A las autoridades del ITBA

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

Parte I - (Terica) - Aproximacin a la Solucin: Estimacin de

CAPTULO II- DOMINIO DEL PROBLEMA

CAPTULO III- LA ESTIMACIN Y LA GESTIN DEL PROYECTO

CAPTULO IV- ESTUDIO DE LAS TCNICAS DE ESTIMACIN

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

funcin sin ajustar

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

5.5 Arquitectura de un SBC

CAPTULO VI - TCNICA DE ESTIMACIN PARA SSBBCC

Parte II - (Prctica) Construccin de la Herramienta de Software.

CAPTULO VII - DEFINICIN DEL PROYECTO DE DESARROLLO DE

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

7.8.4 Identificacin de requisitos (PSI 4)

CAPTULO VIII - ANLISIS DEL SISTEMA DE INFORMACIN (ASI)

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

8.5.3 Normalizacin del modelo lgico de datos (ASI 6.3)

CAPTULO IX - DISEO DEL SISTEMA DE INFORMACIN (DSI)

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

9.5 Diseo fsico de datos (DSI 6)

CAPTULO X - CONSTRUCCIN DEL SISTEMA DE INFORMACIN (CSI)

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

10.6.3 Evaluacin de los resultados de las pruebas de sistema

CAPTULO XII - EVALUACIN DEL SISTEMA DE INFORMACIN

APNDICE B GESTIN DEL PROYECTO

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

ANEXO I DOCUMENTOS DE LAS ETAPAS DEL PROCESO DE MEDICIN

ANEXO II DESCRIPCIN DEL MODELO CONCEPTUAL DE DATOS

ANEXO III MODELO DE PROCESOS DEL SISTEMA

ANEXO V GESTIN DE LA CONFIGURACIN

ANEXO VI GESTIN DE LA CALIDAD

ANEXO VII MANUAL DEL USUARIO

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

VII.3 Requerimientos del sistema

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

Ing. Jos Daniel Ovejero

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

3-D Function Point de Scott Whitmire.

Ing. Jos Daniel Ovejero

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

los cuales an no es posible realizar mediciones con estas tcnicas en

Ing. Jos Daniel Ovejero

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

parmetros bsicos de clculo. Para ello se utilizan datos de proyectos de

Ing. Jos Daniel Ovejero

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

Captulo II Dominio del

Ing. Jos Daniel Ovejero

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

2.3. BREVE DESCRIPCIN DE LAS TCNICAS A ANALIZAR

Puntos de Funcin de Allan Albrecht: los primeros estudios en materia de

Ing. Jos Daniel Ovejero

Captulo II Dominio del

Estimacin de Proyectos Para Sistemas Basados en Conocimiento

o Proporcionar una mtrica del tamao.