Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
EVALUACIN DE PROYECTOS DE
TECONOLOGAS DE INFORMACIN Y
COMUNICACIN
2013
1
2
Introduccin ............................................................................................................. 4
Aspectos Generales................................................................................................. 6
2.1
TEORA EN LA QUE SE BASA LA METODOLOGA ........................................................ 6
2.1.1
Evolucin de los proyectos de Informtica ................................................. 6
2.1.2
Fundamentos para la adopcin de un criterio de Costo/ Eficiencia. ............ 6
2.1.3
Criterios de aprobacin o rechazo de proyectos informticos ..................... 8
2.2
ESTRUCTURA DE LA METODOLOGA ....................................................................... 8
2.3
CICLO DE PROYECTOS INFORMTICOS ................................................................... 9
2.4
LOS PROYECTOS EN EL SNI .................................................................................. 9
2.5
TIPOLOGA DE PROYECTOS ................................................................................. 13
2.6
ALCANCE DE LA METODOLOGA EN CADA CASO .................................................... 14
2.7
HORIZONTE DE EVALUACIN ............................................................................... 16
3
Preparacin de Proyectos ..................................................................................... 17
3.1
RESUMEN EJECUTIVO ......................................................................................... 18
3.2
PLAN O POLTICA INFORMTICA DE LA INSTITUCIN .............................................. 18
3.3
IDENTIFICACIN Y DEFINICIN DEL PROBLEMA ..................................................... 19
3.4
DIAGNSTICO DE LA SITUACIN ACTUAL (SIN PROYECTO) .................................... 20
3.4.1
Descripcin de la Organizacin y/o entorno Afectado por el Proyecto ...... 20
3.4.2
Descripcin de la Unidad o Departamento ................................................ 20
3.4.3
Presentacin de la solucin informtica actual ......................................... 20
3.4.4
Descripcin de los procesos ..................................................................... 20
3.4.5
Diagrama de Flujo de Datos (DFD) presentando la situacin actual ......... 20
3.5
DESCRIPCIN GENERAL DE REQUERIMIENTOS ...................................................... 21
3.6
PROGRAMACIN DE ACTIVIDADES PARA LA ETAPA DE DISEO................................ 21
3.7
REQUERIMIENTOS DE PERSONAL PARA POSTULAR A LA ETAPA DE DISEO. ............. 21
3.8
ESTIMACIN DE BENEFICIOS ............................................................................... 22
3.9
ESTIMACIN DE COSTOS DE INVERSIN, OPERACIN Y MANTENCIN PARA LA ETAPA
DE EJECUCIN ............................................................................................................... 22
3.10 CRONOGRAMA Y CARTA GANTT .......................................................................... 23
3.11 TRMINOS DE REFERENCIA PARA CONTRATAR ETAPA DE DISEO .......................... 24
3.12 OPTIMIZACIN DE LA SITUACIN ACTUAL .............................................................. 24
3.12.1
Medidas administrativas o de rediseo organizacional ................................ 24
3.12.2
Inversin marginal a la solucin existente ................................................. 24
3.13 ANLISIS DE REQUERIMIENTOS (DISEO LGICO) ................................................. 25
3.13.1
Diagrama de flujo de datos (lgico) .......................................................... 25
3.13.2
Modelo de datos ....................................................................................... 25
3.13.3
Otra documentacin ................................................................................. 25
3.14 ALTERNATIVAS DE SOLUCIN .............................................................................. 26
3.14.1
Restricciones asociadas a cada alternativa .............................................. 26
3.14.2
Producto o servicio esperado en cada alternativa ..................................... 26
Evaluacin Costo - Eficiencia ...................................................................................... 27
3.15 EVALUACIN Y SELECCIN DE ALTERNATIVAS...................................................... 27
3.16 ATRIBUTOS RELEVANTES .................................................................................... 28
3.17 TCNICA DE EVALUACIN DE ALTERNATIVAS ....................................................... 29
3.17.1
Evaluacin de los atributos ....................................................................... 29
3.17.2
Detalle de la Inversin y clculo del indicador costo eficiencia.................. 36
4
Trminos de referencia para la etapa de ejecucin ............................................. 38
5
Sugerencias para el proceso de licitacin ........................................................... 38
6
Bibliografa ............................................................................................................. 40
Anexo 1: Tcnica para Priorizacin y Asignacin de Ponderadores ......................... 41
ANEXO 3 ....................................................................................................................... 46
BENEFICIOS Y COSTOS ................................................................................................... 46
ANEXO 4: MODELAMIENTO DE DATOS .............................................................................. 50
ANEXO 5: DIAGRAMA DE FLUJO DE DATOS (DFD) ............................................................ 68
ANEXO 6 CALIDAD FUNCIONAL ....................................................................................... 74
ANEXO 7: ETAPAS DE UN PROYECTO DE DESARROLLO EN INFORMTICA. .......................... 75
ANEXO 8: EJEMPLOS DE MEDIDAS DE EFECTIVIDAD. ......................................................... 83
ANEXO 9 ESFUERZO REQUERIDO PARA CADA FASE ......................................................... 84
ANEXO 10 DEFINICIONES LEGALES ................................................................................. 86
Introduccin
El presente documento tiene como propsito entregar una gua metodolgica para la
preparacin y evaluacin de proyectos de informtica y su presentacin al Sistema Nacional
de Inversiones.
Como herramienta metodolgica, guiar a las instituciones que desarrollan proyectos de
informtica en los siguientes aspectos:
Presentacin de un proyecto de informtica
Presentacin de alternativas de solucin (cuando exista ms de una)
Evaluacin de la o las alternativas de solucin mediante el criterio costo - eficiencia
El resultado de la aplicacin de esta metodologa ser un documento estndar, el que se
presentar al Ministerio de Desarrollo Social, con el propsito de que esta institucin revise la
factibilidad tcnica y econmica de desarrollar dicho proyecto.
La metodologa se orienta a mejorar la presentacin de proyectos, en respuesta a la
problemtica que se ha detectado en este tipo de inversiones.
A continuacin se presentan algunos problemas que se han presentado en las reas
estratgica, tctica y operacional, en relacin a los proyectos de informtica1.
A nivel estratgico: se aprecia falta de definiciones estratgicas con respecto a la
informacin dentro de la organizacin. Uno de los activos ms importantes de la
organizacin actual es la informacin y la tecnologa que la soporta, por lo tanto no hay
que perder de vista que la tecnologa implementada debe apoyar la definicin estratgica
de la organizacin con respecto a la informacin. La tecnologa ayuda a administrar la
informacin y sta debe existir en funcin de generar conocimiento, entendido como la
capacidad de realizar tareas o actividades en forma efectiva.
A nivel tctico: en el rea informtica hay un descuido del tema calidad, principalmente
porque al momento de licitar la principal variable de eleccin es el precio.
Adicionalmente, es destacable que el cliente chileno es poco exigente con el proveedor.
Es as que se ha descuidado, en los desarrollos de software, velar por la reusabilidad del
cdigo. La ventaja de que el cdigo sea reusable, es que permite fcilmente agregar o
modificar funciones del software, pero esto exige que el proveedor se preocupe de
programar de tal manera que esta condicin se cumpla. Esto requiere ms recursos por
parte del proveedor.
En este caso habra que invertir en un mayor grado, pero el costo de mantencin
disminuye.
Adems, cabe destacar que usualmente no se hacen los estudios que se debieran, para
determinar la capacidad del hardware a adquirir, o se define a priori la solucin informtica
a implementar sin haber hecho un levantamiento de requerimientos adecuado.
1
2.1
2.1.1
Aspectos Generales
Los proyectos de informtica han ido evolucionando junto con las organizaciones y a
medida que se han ido produciendo cambios tecnolgicos. Las organizaciones han
evolucionado desde estructuras mecanicistas a flexibles para poder hacer frente a un
medio ambiente externo muy cambiante y orientado al cliente. La informtica ha ido
cambiando tanto tecnolgicamente, como tambin para apoyar la transformacin, ya
mencionada, en las organizaciones. Es as que la informtica ha evolucionado desde
sistemas fuertemente centralizados basados en mainframe, cambiando posteriormente a
sistemas interactivos (terminales de usuarios), luego vino la computacin personal que
haca hincapi en las redes de PCs (surgen los sistemas gerenciales, estratgicos).
Finalmente se ha llegado al punto actual con Internet, aplicaciones multimedia, videoconferencia, realidad virtual, etc.
Con respecto a los criterios de inversin, stos han ido cambiando paralelamente a la
evolucin ya mencionada de la siguiente forma:
Primeramente, slo tena importancia la evaluacin costo beneficio.
Luego se evaluaba adems si se facilitaba la obtencin de los objetivos de la
organizacin y si es que las tecnologas de informacin (TI) mejoraban la calidad
de las inversiones.
Posteriormente cobr importancia cmo las TI podan mejorar las tomas
decisiones y aumentar la participacin de mercado.
Finalmente, ahora se da mayor importancia a cmo las TI pueden aumentar la
capacidad de la informacin (Datawarehouse, Internet, etc.) e innovacin.
Se aprecia que la gestin de la organizacin es muy relevante para considerar los
sistemas necesarios a implementar, y se aprecia cmo el nfasis en el criterio de
inversin ha ido variando.
2.1.2
Como se seal en el punto anterior, el criterio de inversin a lo largo de los aos ha ido
evolucionando haciendo hincapi en distintos aspectos. En la dcada de los 90, se
consideraba como criterio de inversin relevante la posibilidad de aumento de capacidad
de la informacin. Este aumento se entiende orientado a la generacin de conocimiento y
a una mayor satisfaccin del cliente. Es decir, la idea es conocer la tecnologa y explotarla
de tal manera que permita ofrecer mejores servicios con la informacin disponible.
La anterior metodologa para proyectos de informtica evaluaba segn el criterio de costo
beneficio. Sin embargo, existen beneficios que son muy difciles de cuantificar, medir y
valorar. Junto con ello, se presentan beneficios intangibles tales como mejoras en la
calidad de la informacin, efecto modernizador, redes sociales que se pueden establecer
por Internet, aprendizaje debido al contacto con la tecnologa, etc. Adems, como ya se
expuso, se espera que conociendo las TI se hagan innovaciones haciendo uso de ella, lo
que agrega mayor dificultad, ya que los beneficios se obtendran despus de tener
contacto con las TI.
Adems, el anlisis se centraba slo en los aspectos tecnolgicos, lo que produca que se
perdiera de vista la administracin de la informacin, con la consiguiente prdida de
conciencia de la administracin del riesgo de la misma. Es decir, no se apreciaba una
definicin de cul informacin era la relevante para la organizacin y qu medidas se
tomaban para asegurarla o respaldarla. Hay que considerar que esto es muy importante,
porque se ha constatado que empresas que han perdido sus bases de datos han
quebrado como promedio en cuatro meses. Las instituciones pblicas no quiebran, pero
puede afectarse seriamente su funcionamiento.
Considerando que la evaluacin encuentra su sentido en ser un apoyo veraz para la toma
de decisiones, esta metodologa propone el criterio de costo-eficiencia sin prejuicio de
que en algunos casos en que se puedan medir y valorar los beneficios, se aplicar costobeneficio. En particular este esfuerzo es ms justificable, en aquellos casos en que hay
cambios de procesos y ahorros de costos de transaccin para usuarios. Ejemplos:
Teletrmites, infocentros.
Adems, en el caso de outsourcing, es necesario hacer una evaluacin costo-beneficio
para determinar la mejor alternativa entre realizar outsourcing o realizar una inversin
tradicional.
La idea es conceptualizar factores estratgicos, que tengan que ver con la decisin de
cul informacin almacenar, la determinacin de la informacin crtica para la
organizacin o cmo sta se puede aprovechar mejor, lo que se expresa normalmente en
temas cualitativos.
El enfoque costo - eficiencia plantea que la conveniencia de la ejecucin de un proyecto
se determina por la observacin conjunta de dos factores:
El costo: involucra la implementacin de la solucin informtica, adquisicin y
puesta en marcha del sistema hardware / software y los costos de operacin
asociados.
La eficiencia: se entiende como la relacin entre bienes y servicios finales
(resultados) y los insumos requeridos para ello (esfuerzo). As se trata de medir en
qu grado el gasto de recursos se justifica por los resultados, minimizando costos
u optimizando insumos.
Estos dos elementos evaluados en forma conjunta configuran el anlisis costo - eficiencia;
ste, en definitiva, establece el costo por unidad de cumplimiento del objetivo.
Ahora, al considerar los criterios a utilizar en el mtodo costo-eficiencia es necesario que
stos sean un reflejo de la estrategia que est tomando la organizacin con respecto a la
informacin.
2.1.3
2.2
Estructura de la Metodologa
2.4
Preinversin
Inversin
Operacin
Grafico N 1 Ciclo de vida de un proyecto
10
preferentemente los recursos disponibles, constituye un proceso que sigue las siguientes
etapas secuenciales:
Cada una de ellas busca reproducir el ciclo de vida del proyecto, de manera que a medida
que se avanza en las etapas, los estudios van tomando mayor profundidad y se va
reduciendo la incertidumbre, respecto a los costos y beneficios netos esperados del
mismo.
La secuencia por etapas tiene por justificacin evitar los elevados costos de los estudios y
poder desechar en las primeras etapas los proyectos que no son adecuados.
Cada etapa se presenta en la forma de un informe, cuyo objetivo fundamental es
presentar los elementos que intervienen orientados claramente a la toma de decisiones de
abandonar o proseguir la idea. En mayor detalle:
11
12
2.5
Tipologa de proyectos
En lo sucesivo, todas las cifras en dlares son al valor del dlar observado a la fecha de la
evaluacin del proyecto.
13
Criterio de evaluacin
Menos de U$ 50.000
Ms de U$ 50.000
Ms de U$ 50.000 y hay
cambios de procesos que
Costo Beneficio
involucran ahorro de costos
para usuarios.
En los criterios de evaluacin, "costo eficiencia a nivel cualitativo" corresponde al nivel de
evaluacin que se establece en Ias Normas y Procedimientos (NIP) vigentes para los
proyectos de Informtica, mientras que "costo eficiencia a nivel cuantitativo" corresponde
a la presente metodologa4.
2.6
4 En particular el captulo 4.
14
IDEA
Metodologa
(b) y (c)
PERFIL
Metodologa
(b) y (c)
PREFACTIBILIDAD
FACTIBILIDAD
Metodologa
(a),(b) y (c)
DISEO
EJECUCIN
Grfico N 3: Ciclo de vida y Tipologa de Proyectos
La metodologa se aplica a distintas etapas del ciclo de vida del proyecto dependiendo de
la tipologa. En efecto, para proyectos de desarrollo se requiere tener el diseo lgico,
luego la metodologa se aplica para pasar de la etapa de diseo a la de ejecucin (para
pasar de perfil a ejecucin se requiere la documentacin obtenida en el diseo lgico, as
como la evaluacin de las distintas alternativas de solucin).
Para proyectos de equipamiento, adquisiciones, mejoramiento, ampliacin o reposicin, la
metodologa se aplica para pasar de la etapa de perfil a ejecucin, sin perjuicio de que en
algunos casos se puede pasar de perfil a prefactibilidad o factibilidad (y posteriormente a
ejecucin) dependiendo de la posibilidad de cuantificar los beneficios del proyecto, esta
posibilidad se indica con las flechas de lneas punteadas en el grfico anterior.
Adicionalmente, se debe considerar que la metodologa considera tres resultados
esperados de distinta naturaleza y que no aplican a todas las tipologas:
a) Diseo Lgico.
b) Evaluacin de alternativas de solucin.
c) Elaboracin de Trminos de Referencia para la licitacin de la etapa siguiente.
15
El diseo lgico (a), se requiere como resultado slo para proyectos de desarrollo de
aplicaciones, por lo tanto para las otras tipologas slo se requiere (b) y (c). Estas
diferencias estn representadas en el Grfico N 3, en el cual para cada tipologa se
indica con un valo la etapa en la cual se aplica la metodologa y en cada caso se seala
el alcance de la aplicacin de la metodologa, es decir, si se aplica (a), (b) y (c) o slo (b)
y (c).
Es importante notar que para el caso de informtica, el significado de la etapa de Diseo
varia, con respecto a un proyecto tradicional, ya que como producto de esta etapa se
obtendr el Diseo Lgico, as como la evaluacin de las distintas alternativas de
solucin, evaluacin que normalmente se presenta como resultado final de la etapa de
factibilidad.
Cabe mencionar que la tipologa para el caso de compra de paquetes de software5,
corresponde a la tipologa de Desarrollo para la etapa de Ejecucin. Sin embargo en este
caso slo se pedir el diagrama de procesos o el diagrama de flujo de datos (DFD),
porque es importante considerar, si es que la organizacin es capaz de adaptarse al
software comprado, situacin que se puede apreciar de mejor manera, si es que existe un
levantamiento de requerimientos.
Cada uno de estos requisitos quedan explicados en forma ms amplia en el resto de la
metodologa.
Adems, en el Anexo 9 se describe el esfuerzo necesario para cada fase de un proyecto
informtico.
2.7
Horizonte de Evaluacin
16
Preparacin de Proyectos
Perfil
Diseo
Diseo
Ejecucin
Equipamiento, adquisicin,
mejoramiento, ampliacin o
reposicin
Perfil
Ejecucin
Ver Nota al pi
17
Resumen ejecutivo
3.2
La poltica informtica debe contener estrategias encaminadas a una buena gestin, tanto de
la informacin como de la tecnologa que la soporta.
En particular, se debe definir, en los casos que corresponda:
-
18
3.3
Estrategia de capacitacin
de
almacenamiento,
19
3.4
3.4.1
Esta etapa tiene como objetivo dar una descripcin completa del rea o departamento
involucrado en el estudio sirviendo como base para el anlisis.
3.4.2
La idea es describir los sistemas, software y hardware del rea problema. para lo anterior
hay que basarse en el anexo 2 Elementos a considerar en la Evaluacin Tcnica de
Proyectos Informticos. Adems, es importante presentar en este caso un diagrama de la
arquitectura de la solucin actual.
Para las tipologas de desarrollo o mejoramiento (las que incluyen desarrollo de software),
se requiere:
3.4.4 Descripcin de los procesos
Se deber definir cules son los procesos que tienen relacin con el tema en estudio,
dando un nombre simple al proceso y una breve descripcin de cmo opera.
3.4.5 Diagrama de Flujo de Datos (DFD) presentando la situacin actual
Los DFD que se debern describir, son los indicados en el punto anterior. El objetivo es
visualizar en un esquema simple cmo fluye la informacin. Como ejemplo de Diagrama
de Flujo de Datos ver el Anexo Diagrama de Flujo de Datos.
20
Estos diagramas pueden situarse en varios niveles. Para esta etapa, slo se necesita una
presentacin a nivel intermedio (siguiente al nivel de contexto, con los subniveles ms
relevantes).
3.5
Se debe presentar un presupuesto detallado por fases o total del estudio. La informacin
pertinente debe desagregarse en, al menos, los tems que se muestran en el siguiente
cuadro, identificando la cantidad y el precio unitario de cada uno. Se deben valorar slo los
tems que signifiquen desembolso adicional para el servicio; en consecuencia, no debe
incluir personal propio. Se entiende por personal propio los funcionarios de la institucin que
financia o que est postulando el estudio y que se estima se dedicarn en jornada parcial o
completa a ser contraparte del mismo o a participar en su ejecucin. Por otra parte, el
personal externo son las personas que asignar la empresa o institucin que desarrolle el
estudio (empresa consultora u otra institucin). Tambin debe incluirse en esta categora el
personal que se contrate especficamente para la ejecucin de ste o para hacer de
contraparte, y cuyo contrato finalice junto con su trmino.
21
UNIDADES*
PRECIO
UNITARIO
CANTIDAD
VALOR TOTAL
(M$)
Profesionales
Tcnicos
Secretarias
Viticos y pasajes
Materiales y equipos
Total
Gastos Generales
La unidad de medida del recurso humano es el nmero de horas.
1\. - Los profesionales deben ser desagregados por tipo y nivel.
Adems, se debe informar de los requerimientos totales de personal del estudio de acuerdo
al siguiente esquema:
Tabla N 4: Costos Totales de personal
PERSONAL
PROPIO
EXTERNO
(Nmero de horas)
(Nmero de horas)
Profesionales
Tcnicos
Secretarias, Asistentes y otros
Otros
TOTAL
1\. - Los profesionales deben ser desagregados por tipo y nivel.
Estimacin de beneficios
Se deben describir los beneficios en forma cualitativa. De ser posible identificar, medir y
valorar los beneficios, se sugiere considerar los temes incluidos en el Anexo3.
3.9
22
: Microsoft Corporation
23
Como se observa en el ejemplo, las flechas indican la dependencia entre las distintas
tareas. Las indicaciones que aparecen al lado de cada barra (Emp, EFC, etc.) indican
quin es el responsable de la tarea. Los diamantes indican hitos de control (reuniones,
entrega de resultados)
24
-Otras inversiones
3.13 Anlisis de requerimientos (Diseo lgico)
3.13.1 Diagrama de flujo de datos (lgico)
El objetivo es visualizar en un esquema simple la informacin requerida y cmo fluye
dicha informacin entre las distintas entidades y procesos. Como ejemplo, ver el Anexo 5
correspondiente al Diagrama de flujo de datos (lgico). En lo que se refiere al flujo de
datos, estos Diagramas pueden ir aumentando en complejidad, en la medida que cada
flujo se vaya describiendo en mayor profundidad.
En el caso de sistemas de informacin geogrficos, debe pedirse como parte del anlisis
requerimientos, las capas y cruces mnimos necesarios. En el caso de que el diagnstico
determine la necesidad de contar con capas adicionales, se debe identificar que
instituciones (distintas a la que presenta el proyecto), pueden disponer de dichas capas, y
25
26
A modo de ejemplo, si el objetivo es acertar en el blanco de una diana, quien logre esa meta despus de
lanzar 100 dardos, ha sido efectivo, pero sumamente ineficiente, el que ni siquiera logra acertar despus de
100 intentos es ineficaz, y el que acierta a la primera ocasin es eficaz y eficiente.
27
El clculo de los indicadores (cmo VAN y TIR), puede mostrar una rentabilidad alta (que en
general es difcil de medir) y no guarda relacin con la calidad de la solucin tecnolgica
seleccionada, cabe centrarse por lo tanto en la optimizacin del proyecto.
Obviamente, la seleccin final se hace en el proceso de licitacin, sin embargo, el anlisis
previo de generacin y seleccin de alternativas debera ayudar a una mejor especificacin
de las bases tcnicas para la formalizacin de la compra o licitacin, evitando conflictos por
vacos en las bases y acotando el espacio de alternativas. Esto permitir un anlisis ms
minucioso de las propuestas.
Para la evaluacin de alternativas se medirn ciertos atributos de la solucin propuesta y se
definirn ponderadores para dichos atributos. Esto se explica en la siguiente seccin.
El uso de ponderadores de atributos permitir evaluar las distintas alternativas planteadas,
intentando seleccionar las alternativas que ofrezcan el mejor nivel tcnico y que resuelvan de
la mejor manera posible el problema planteado.
La dificultad del modelo radica justamente en la definicin de atributos y la estimacin de los
ponderadores. En efecto, el proceso de generacin de atributos, asignacin de puntajes y
ponderadores, presupone claridad respecto de los requerimientos, de los problemas del
actual sistema, de los objetivos del nuevo sistema y de las funciones y sistemas
administrativos a ser apoyados por la configuracin.
Si se dan las condiciones anteriores y se realiza un adecuado anlisis, debera esperarse
que los atributos y el valor asignado a los ponderadores reflejen las reales necesidades de la
institucin con respecto al sistema computacional.
Al no darse esas condiciones, queda abierta la posibilidad de que el evaluador "maneje" los
ponderadores para "seleccionar" alguna alternativa preconcebida, lo que hace que la
herramienta resulte inservible para los objetivos de acercarse a la seleccin de una buena
configuracin computacional.
3.16 Atributos Relevantes
Se pueden plantear dos tipos de atributos:
Atributos imprescindibles
Los atributos imprescindibles son aquellos que obligatoriamente deben cumplirse en su
totalidad, en la alternativa a evaluar. De lo contrario, dicha alternativa no deber ser
considerada.
A lo menos, se deben considerar los siguientes atributos como imprescindibles:
- La alternativa de solucin est de acuerdo con la poltica informtica (si es que existe) de la
institucin.
28
Efectividad
Plataforma Tecnolgica
Calidad Tcnica de la Solucin
Ahorro de costos operacionales
29
ii.
iii.
iv.
Funcionalidades
del Sistema
MUY DESEABLES
(%Cumplimiento)
Informacin en Lnea
Interfaces Grficas
DESEABLES
(%Cumplimiento)
Emisin de cartas
Control de cambios
Otros atributos
menores
Total
Altern. 1
Altern. 2
...
Altern. N
100%
50%
100%
1
1
1
0
1
1
33%
100%
33%
0
1
1
1
0
1
79.9
65
(EF1)
(EF2)
Tabla 5: Matriz de Efectividad
79.9
(EFN)
Para otros ejemplos de atributos que miden efectividad en distintas dimensiones, ver Anexo
8
En cada celda, colocar un 1 (uno) si la alternativa cubre la funcin y un 0 (cero) en caso
contrario. Posteriormente se calcula el % de cumplimiento para c/alternativa, como la suma
de 1 (unos) divididos por el total de atributos dentro de c/categora (deseable o muy
deseable). Luego, obtener el puntaje de cada alternativa por grupo de funcin y calcular el
promedio ponderado de ambas. Se utilizar un factor de 0.7 para las funciones muy
30
Confiabilidad de la informacin (Gestin): Esto tiene que ver con que la informacin
obtenida debe ser apropiada para la gestin con el fin de operar la institucin y para
ejercer las responsabilidades de cumplimiento de las tareas institucionales.
Informacin Externa: Esto tiene que ver con que la informacin obtenida debe ser
apropiada para satisfacer los requerimientos de otras instituciones con respecto a la
organizacin.
31
En lo posible, cada uno de estos criterios deber ser evaluado objetivamente. En todo
caso, la existencia de opiniones de expertos podr ser incorporada, as como estadsticas
que exhiban una validacin de la industria informtica respecto al cumplimiento de cada
uno de ellos. De todos modos, cada criterio ser calificado con una nota de 1 a 100, en
base al siguiente criterio:
Si cumple totalmente:
Si cumple adecuadamente:
Si cumple con restricciones:
Cumple con muchas restricciones:
Si no cumple:
100 puntos
80 puntos
60 puntos
40 puntos
0 puntos
Con el fin de obtener todos los antecedentes necesarios para la evaluacin, el formulador se
deber apoyar en la informacin del anexo2 que sea relevante para la tipologa del proyecto.
Una vez hecho esto, se deber elaborar la siguiente matriz.
ASPECTOS
PLATAFORMA
TECNOLGICA
Confidencialidad
Ponderador
Altern. 1
Altern. 2
...
Altern. N
M%
100
100
40
Integridad
X%
100
20
100
Disponibilidad
Y%
100
100
30
Confiabilidad
Z%
80
100
100
Informacin Externa
W%
80
80
100
TOTAL
100%
PT1
PT2
PTN
En base a estos resultados, se debe calcular un promedio ponderado. Para calcular los
ponderadores, se debe aplicar la tcnica descrita en el anexo 1.
C) Calidad Tcnica
Este punto tiene que ver con aspectos tcnicos de la solucin propiamente tal, ms all de la
plataforma en la cual se basa. El objetivo es asegurar que la implementacin de las
herramientas disponibles en la plataforma tecnolgica seleccionada cumpla con los criterios
deseados. Para estos efectos, se deber crear una matriz con todos los aspectos tcnicos
evaluables de las alternativas, clasificndolos en los siguientes grupos:
Seguridad: Da cuenta de la seguridad de la solucin tanto en los mbitos de hardware como
de software.
Disponibilidad: Se refiere a la capacidad de la plataforma de no sufrir cadas dentro de un
rango de tiempo determinado.
32
ASPECTOS TCNICOS
SISTEMA
SEGURIDAD
(% cumplimiento)
Sistemas de Respaldos
Sistema de recuperacin
Ponderador
Altern. 1
Altern. 2
X%
%100
%75
%50
1
1
1
1
1
1
1
1
1
0
0
0
%100
%100
%100
%0
%100
%100
%100
%100
%100
%0
%100
%0
CT1
CT2
CTN
Control de acceso
Encriptacin de datos
PORTABILIDAD
(%Cumplimiento)
Herramientas para
importacin y exportacin
de datos.
DISPONIBILIDAD
Up time garantizado de
ms de 98%
ESCALABILIDAD
ACCESIBILIDAD
(%Cumplimiento)
Canales de comunicacin
en lnea con otras
aplicaciones
TOTAL
Y%
Z%
W%
U%
...
Altern. N
33
AC j
CO j
Donde:
ACj: Ahorro de costos operacionales con proyecto en la alternativa j
Coj: costos operacionales para alternativa j
Se considera que el mximo ahorro en costos operacionales puede llegar a ser del 10%.
Para llevar esto a puntaje, se amplificar por 1000 el porcentaje obtenido. As si el ahorro
fuera del 10% el puntaje sera 100. Si el ahorro fuera del 4%, el puntaje sera de 40.
Ahorro de papel
Ahorro en promocin
(marketing)
Ahorro en distribucin de la
informacin
Ahorro en reparaciones
:
:
etc
SUMA
Promedio
Altern. 1
100
Altern. 2
100
...
100
100
100
100
100
100
100
:
:
:
100
:
:
:
ACO1
ACO2
:
:
:
Altern. N
40
100
:
:
:
ACON
34
Ejemplo:
Ahorro de papel
Ahorro en
promocin(marketing)
Ahorro en distribucin de la
informacin
Ahorro en reparaciones
SUMA
Promedio
Altern. 1
Altern. 2
Altern. 3
20
30
10
30
80
50
100
40
80
10
160
40
70
220
55
90
230
57,5
En este caso los atributos son 4, por lo que se divide la suma de cada columna por ese
nmero, para obtener el total.
Evaluacin de alternativas
Una vez evaluados todos estos factores, se deber generar la siguiente matriz:
ATRIBUTOS
EVALUABLES
Efectividad
Plataforma Tecnolgica
Calidad Tcnica
Ahorro de Costos Op.
TOTAL
Ponderador
Altern. 1
Altern. 2
x%
y%
z%
w%
100%
EF1
PT1
CT1
ACO1
P1
EF2
PT2
CT2
ACO2
P2
...
Altern. n
EFN
PTN
CTN
ACON
PN
PA ji * Ponderadorj
Pi
j
100
Donde:
Pi
:
PAji
:
Ponderadorj :
Puntaje Alternativa i
Puntaje del atributo j de la alternativa i
Ponderador del atributo j (corresponde a los x%, y%, z% y
w%)
35
Cumple totalmente:
100 puntos
Cumple adecuadamente:
80-99 puntos
60-79 puntos
0-39 puntos
Una vez obtenida una calificacin para cada una de las alternativas, es posible el clculo
de una razn costo / eficiencia que incorpora criterios estratgicos y de calidad.
RC j
Cj
Pj
RCj
: Razn de costo - eficiencia de la alternativa j, (costo por unidad de cumplimiento
de los objetivos)
Cj
Pj:
: Puntaje de la alternativa j
Para calcular Cj, se calcula el Costo anual equivalente (CAE) del proyecto dentro de su
vida til considerando los costos de inversin, mantencin y operacin. El CAE se calcula
como el producto del Factor de Recuperacin del Capital (FR) por el Valor Actual de
Costos de la alternativa j (VACj), donde:
10
No se debe olvidar en el caso de adquisicin de software, incluir los costos asociados al nmero
de licencias de uso que se desea habilitar.
36
FR
r 1 r
1 r
n
VACj = Ij + (COtj + CMtj ) / (1+r)t
t=1
Con:
r: tasa de descuento
n: vida til del sistema
COtj: costo de operacin de la alternativa j en el perodo t
CMt: costo de mantencin de la alternativa j en el perodo t
Ij: costo de inversin de la alternativa j
De forma que
Cj = CAEj = VACj * FR
Para los sistemas se considera generalmente una vida til de cuatro aos. En el caso que
se estime que la vida til de alguna alternativa tecnolgica difiere significativamente de 4
aos se deber recalcular su FR le acuerdo a la frmula anterior.
Para escoger la o las alternativas finales, se seleccionan aquellas con menor razn de
costo-eficiencia y cuyo precio est dentro de los rangos presupuestados. En el caso de
que las alternativas tuvieran la misma razn costo-eficiencia, hay que escoger la que
cumpla al menos con restricciones.
Ejemplo:
A continuacin, se presenta un ejemplo de la aplicacin de la tabla de atributos
evaluables.
ATRIBUTOS
EVALUABLES
Efectividad
Plataforma Tcnica
Calidad Tcnica
Costos operacionales
TOTAL
Ponderador
Altern. 1
Altern. 2
Altern. 3
30%
25%
35%
10%
100%
100
60
40
50
64
80
100
80
40
81
60
100
60
60
70
37
Los trminos de referencia deben incluir toda la informacin necesaria, para poder licitar
la etapa de ejecucin. Deben especificar que la solucin se debe adaptar al diseo lgico
ya desarrollado, as como a los distintos atributos desarrollados en esta metodologa. Por
otro lado deben establecerse claramente los productos entregables (cdigos fuentes,
documentacin del diseo fsico, otros), tambin debe especificarse el tiempo de entrega
de la solucin y que hacer en caso de atraso. Puntos importantes a considerar son la
marcha blanca, capacitacin y la operacin, mantencin del sistema.
5
Mantenimiento
Se debe considerar si la propuesta del proveedor contempla:
Responsabilidades como mantenimiento y reparacin de unidades del sistema.
Inspecciones, pruebas, limpieza de partes internas, lubricaciones, ajustes y reemplazo
de partes.
Perodo de garanta.
Mantenimiento preventivo.
38
39
Bibliografa
40
Total
fila
Orden
1
0
41
(Gestin)
Confidencialidad
Integridad
Disponibilidad
Confiabilidad
(Gestin)
Inf. externa
0
1
Fila
10
40
20
10
20
Pondera
dor
Alternativ
a1
Alternat
iva 2
Alternativa
3
10%
40%
20%
10%
20%
100%
60
70
60
100
100
76
100
100
100
80
100
98
80
90
70
80
60
78
42
Anexo 2
Elementos a considerar en la Evaluacin Tcnica de Proyectos Informticos
Los siguientes son los antecedentes a entregar para la evaluacin tcnica de un proyecto
informtico:
1.
2.
3.
4.
5.
6.
7.
8.
43
a) Servidores
CPU
Unidades de almacenamiento (tipo, capacidad)
Memoria RAM
Unidades de respaldo
Perifricos
Otros (hardware redundante, etc.)
b) Sistemas operativos
Fabricante
Versin (nmero y fecha liberacin)
Tipo de licenciamiento
c) Software de aplicacin de terceros
Fabricante
Versin (nmero y fecha liberacin)
Tipo de licenciamiento
d) Componentes de red y comunicaciones (hardware y software)
Servidores de comunicaciones
Routers, modems, DTU, etc.
Protocolos de comunicacin
e) Estaciones de trabajo
CPU
Unidades de almacenamiento (tipo, capacidad)
Memoria RAM
Unidades de respaldo
Perifricos
f)
Impresoras
Tipo de impresoras (lser, inyeccin de tinta, etc.)
Breve descripcin caractersticas tcnicas (calidad de impresin, velocidad, etc.)
44
Costos de Operacin
Debe estimarse el costo de operacin de la solucin y la curva de evolucin de ste, con
el fin de predecir la vida til de la solucin. Aqu deben considerarse:
a) Insumos y materiales fsicos
b) Recursos humanos
c) Otros
Costos de Mantencin de la Solucin
Esta informacin complementa la anterior, debiendo incluirse:
a) Upgrade o mantencin de licencias
b) Actualizaciones de hardware
c) Proyeccin de requerimientos de nuevos desarrollos
d) Otros
Capacitacin Tcnica
a) Personal involucrado
b) Costo de capacitacin (inicial y mantencin)
Personal nuevo necesario
Indicar eventual necesidad de contratacin de personal para la operacin y mantencin de
la solucin, describiendo perfil y costos.
45
Anexo 3
Beneficios y costos
Los costos de los proyectos de informtica son relativamente simples de cuantificar, no
as los beneficios, que se presentan como ahorro de costos con respecto a la situacin
base, siendo particularmente compleja la estimacin de las horas - hombre liberadas.
Por otra parte, este tipo de proyectos tienen costos y beneficios intangibles, los cules se
debern describir en forma cualitativa.
Beneficios privados
Dependiendo de la naturaleza del proyecto, se pueden presentar algunos de los
siguientes beneficios:
46
47
Costos privados
En general tendremos los siguientes tems:
Compra de hardware
Compra de software
Conversin/Adaptacin de software existente
Desarrollo de software
Estudios y capacitacin
Instalacin y puesta en marcha
Habilitacin de locales y muebles
Costos de operacin
Remuneraciones (cuando se requiera personal adicional)
Servicios externos
Comunicaciones (arriendo de lneas)
Arriendo de programas
Materiales de uso y consumo corriente (diskettes, hojas perforadas, cintas de impresoras,
etc.)
Mantencin y reparaciones
Consumo de energa
48
49
DEFINICIN
II.
2.1
ESQUEMA
En la figura 1 se representa una serie de secuencia de pasos a seguir, desde el
punto de vista metodolgico, para hacer modelamiento de datos:
Modelo de Datos
Fsicos
50
2.2
IDENTIFICACIN DE REQUERIMIENTOS
iii) Definir o recolectar formularios: todos los formularios que se utilizan en el Sistema
en estudio.
2.3
51
2.3.1
ENTIDADES
52
Es posible registrar hechos que describen las instancias de una entidad. Por
ejemplo, los siguientes hechos se aplican a las ocurrencias de la entidad
PROVEEDOR: Nombre_proveedor, direccin_proveedor,
fecha_ingreso_proveedor, calidad_proveedor, vigencia_proveedor.
Cada hecho puede tomar slo un valor para cada ocurrencia de la entidad.
Por ejemplo si un proveedor tiene ms de un vendedor para contactar la
empresa, luego el nombre del vendedor es un hecho multivaluado acerca del
proveedor. De esto se sigue que ms de una entidad es necesaria para
descubrir completamente al proveedor.
53
Una relacin debe ser tanto relevante como significativa para la organizacin. Por
relevante se entender el hecho de que es necesario registrar la asociacin, y por
significativa se entender el que aporte el entendimiento y uso del modelo. Estos dos
factores aparecern ms claros al observar el uso del modelo en los procesos del
sistema.
Nombres para las relaciones
Las relaciones deben tener nombre con frases que sean significativas para la
asociacin entre las dos entidades. Por ejemplo, PROVEEDOR provee
PRODUCTO. La frase de asociacin casi siempre tendr un verbo presente. La
forma activa del verbo denotar el primer sentido de asociacin (primero en trminos
de que es el primer sentido estudiado), y la forma pasiva del verbo denotar la
asociacin inversa, por ejemplo, PRODUCTO provisto por el PROVEEDOR.
Es muy importante evitar nombres generales tales como "es", "tiene", "con ", que
aportan poco a aclarar el significado de una relacin. Por ejemplo, ORDEN contiene
(no "con") ITEMS ORDEN, o CIUDAD ubicacin de (no "tiene) HOTEL.
c. Construir Diagrama Entidad - Relacin
Las entidades y relaciones se van dibujando a medida que se van descubriendo, por
lo que el diagrama va siendo modificado continuamente a medida que se van
encontrando nuevas entidades y relaciones.
Una entidad es dibujada como un rectngulo, que contiene el nombre de la entidad,
escrito en mayscula, tal como aparece en la figura 2:
PRODUCTO
Una relacin se dibuja como una lnea entre dos entidades, con el nombre de la relacin
escrito en minsculas sobre esta lnea, tal como en la figura 3:
PRODUCTO
almacenado en
BODEGA
almacn de
54
Las relaciones tienen una naturaleza que describe el tipo de asociacin, tales como:
-
Pertenencia
Jerarqua
Temporal
Complementariedad
Parentesco
Autoridad
relaciones:
Obligatorias: toda ocurrencia de una entidad debe participar en la relacin con una
ocurrencia de la otra entidad. La figura 4 muestra un ejemplo:
Opcionales: no es necesario que una ocurrencia de una entidad este asociada con una
ocurrencia de la otra entidad. La figura 5 muestra un ejemplo:
55
De Contingencia: una ocurrencia de una de las entidades puede existir slo si est
relacionada con una ocurrencia de la otra entidad, pero una ocurrencia de la otra
entidad puede existir independientemente y no necesita participar en la relacin. La
figura 6 muestra un ejemplo:
- 1:1 (uno a uno): una ocurrencia de una entidad est relacionada con slo una
ocurrencia de la otra entidad, y vice versa.
- 1:M (uno a muchos): una ocurrencia de la primera entidad est relacionada con
muchas ocurrencias de la otra entidad, mientras que una ocurrencia de la otra
entidad est relacionada con slo una ocurrencia de la primera entidad.
56
- M:N (muchos a muchos): una ocurrencia de la primera entidad est relacionada con
muchas ocurrencias de la otra entidad, y viceversa.
57
Puede existir ms de un tipo de relacin entre dos entidades, las que deben
distinguirse con nombres diferentes. La figura 11 muestra un ejemplo.
d. Identificacin de Atributos
Un atributo es un hecho o propiedad significativo y nico acerca de una entidad, y tiene
sentido slo dentro de sta. La figura 12 muestra esta situacin.
Atributos
Empleado
Cliente
Los atributos toman valor para cada ocurrencia de la entidad. Las ocurrencias de una
entidad son descritas por los valores de sus atributos, tal como lo muestra la figura 13.
58
Marambio, Consultores
Cada una de las fuentes anteriores indicar los hechos que la organizacin requiere
para ser registrados, siendo ellos potenciales atributos de entidades. Si no existe una
entidad que pueda abarcar al atributo descubierto, cree una nueva, segn las
especificaciones anteriores.
La descripcin de atributos ser en extremo relevante para la especificacin final de
los datos y su modelamiento fsico. Las siguientes propiedades sern exigidas en el
modelo de datos:
Nombre: nacen fundamentalmente de un acuerdo con usuarios y/o miembros del
equipo de trabajo. El nombre completo del atributo debe consistir del nombre del
atributo seguido del nombre de la entidad, por ejemplo: nombre.CLIENTE,
ubicacin.EMPLEADO.
59
Definicin:
Debe indicar el significado y propsito del atributo, dejando
absolutamente claro qu propiedad de la entidad describe cada atributo. Por ejemplo,
precio .PRODUCTO: "Precio inicial actual ofrecido a un cliente estndar". Algunos
casos pueden ser obvios, por lo que no siempre deber ir una definicin del atributo,
como por ejemplo nombre.CLIENTE.
Sinnimos: cuando aparezcan sinnimos para algn atributo, deben ser registrados.
Cardinalidad: todo atributo tendr una cardinalidad mnima y mxima, reflejando si
es dato simple, o repetitivo, obligatorio u opcional. Se describirn de acuerdo a las
convenciones siguientes:
- <0,1> dato simple, opcional. Indica cardinalidad mnima de cero (puede no tener
un valor en alguna ocurrencia), y un valor mximo de 1 (si tiene valor, el mximo ser
uno). Por ejemplo, fecha.RESERVA: Tendr valor slo cuando exista una reserva, y
en ese caso tendr slo un valor.
- <0,m> dato repetitivo, opcional. Indica cardinalidad mnima de cero (puede no
tener un valor en alguna ocurrencia ), y un valor mximo de m ( si tiene valor, podr
haber muchos valores dentro de la misma ocurrencia de la entidad). Por ejemplo,
crdito. CLIENTE: El cliente puede tener ms de un crdito asignado, pero podra no
tenerlo.
- <1,1> dato simple, obligatorio. Este caso corresponder a aquellos atributos que
son candidatos a llave. Corresponden a datos nicos. Por ejemplo, nmero.CUENTA
CORRIENTE: Una cuenta corriente tendr siempre un nmero que la identifique, y a
lo ms un nmero.
- <1,m> dato repetitivo, obligatorio. Similar al anterior, pero dentro de la misma
ocurrencia puede tener varios valores asociados. Habr al menos un valor para el
atributo. Por ejemplo, telfono.PROVEEDOR: El proveedor puede tener ms de un
telfono registrado, pero al menos se le exigir uno.
Los casos <x,m> corresponden a entidades que sern tratadas con la Primera
Forma Normal, que justamente elimina los atributos repetitivos de las entidades,
creando otras entidades como resultado.
Condiciones de Exigencia: Cuando los atributos sean declarados como opcionales,
deben establecerse las reglas y restricciones, referidas a otros atributos y/o
relaciones que determinan su existencia. Los atributos obligatorios, por su parte,
deben tener asociado un valor por defecto, que regir como valor del atributo hasta
que sea ingresado el valor final.
Valores Permitidos y su significado: Cuando un atributo tenga un dominio distinto
de un string de caracteres, una cantidad o una fecha, ser necesario determinar el
rango de valores permitidos y el significado de cada valor, si es necesario. Por
ejemplo, tipo CLIENTE, puede tener los valores permitidos "vigente", "potencial",
"convenio" y otros. Estos valores no pueden ser conocidos a menos que quien define
el atributo los declare. Todos los atributos que indican algn tipo de "cdigo" o "tipo"
deben ser establecidos.
60
61
Nombre:
Definicin:
g . Identificador de Entidades
2.4
Si una entidad usa una relacin como parte de un identificador, la entidad deber
tener participacin obligatoria en la relacin, y debe tener una cardinalidad mxima
de uno.
62
Ejemplo:
63
2.4.2
Su propsito es analizar los atributos de las entidades para confirmar que ellos
estn ubicados en la entidad correcta y que no son necesarias entidades
adicionales, proveyendo una base para el diseo de la base de datos lgica que
minimice los accesos a la base de datos.
Para que un modelo de datos no tenga redundancia, y para prevenir anomalas de
actualizacin, debe ser normalizado, esto es, que cada atributo de una entidad sea
completamente dependiente de su identificador primario.
Es el proceso de bsqueda de la forma en la cual los datos pueden ser trabajados
independientemente, pero manteniendo sus relaciones. Permite optimizar el
modelo conceptual. En otras palabras, es una representacin de los datos en una
forma ms clara, sencilla, visual, y fcil de implementar. Una representacin que
contiene nada ms que la informacin necesaria.
64
Enfoque:
a) Obtener la lista de atributos de cada entidad
Obtenga una lista para la entidad, que incluya todos los atributos individuales (no
compuestos) y las relaciones. Verifique que se dan las siguientes reglas.
Seleccione aquel cuya tasa de uso se perciba mayor que los otros.
65
Por cada conjunto de estos atributos, cree una nueva lista de atributos, y copie en
esta lista el identificador primario. Para cada lista de este tipo que surja de este
trabajo, seleccione su identificador primario. Este identificador primario incluir al
menos uno de los atributos de la lista, adems del identificador primario de la
entidad original (entidad "padre"). Repita este proceso hasta que no queden
grupos de atributos respectivos en la entidad padre. Las listas resultantes estarn
en Primera Forma Normal (1FN). En el ejemplo:
EMPLEADO (nmero empleado, nombre empleado, nmero departamento,
nombre departamento, cargo empleado, sexo empleado)
CARGA EMPLEADO (nmero empleado, cdigo carga empleado, nombre carga
empleado, edad carga empleado).
Es necesario normalizar en 2FN cuando se tiene una relacin de M:N, la cual debe
transformarse en dos relaciones de 1:N. Considere la lista de cada entidad que
contiene identificadores primarios compuestos, y para cada atributo que no es
identificador en la lista, pregunte:
El valor de este atributo depende completamente de los identificadores
parciales?
Si la respuesta es "no", saque el atributo de lista y determine los identificadores
parciales de los cuales ste depende. Haga una lista separada para todos los
atributos que dependen del (los) mismo (s) identificador (res) parcial (es). Cada
lista que se crea forma la base de una nueva entidad, en la que debe copiarse el
identificador parcial relevante de la entidad original.
De un nombre a cada nueva entidad creada, documntelas en el estndar
definido, y selecciones un identificador primario. Elimine los calificativos heredados
de la entidad original. Por ejemplo, "empleado" ya no forma parte del atributo
"cdigo carga" en el ejemplo que sigue. Las entidades resultantes estarn en
segunda forma normal.
66
- La diferencia con respecto a la IFN es que en este caso (3FN) los datos repetidos
salen como "padre", mientras que en la LFN los datos repetitivos salen como "hijos"
de la entidad original.
67
Para desarrollar un diagrama de flujo de datos hay que seguir los siguientes pasos:
1) Hacer lista de actividades para determinar:
-
Entidades externas
68
Flujos de datos
Procesos
Almacenes de datos
2) Diagrama de contexto
3) Diagrama de nivel 0
4) Crear diagrama hijo por cada proceso de nivel 0
5) Revisar el modelo
6) Desarrollar DFD fsico a partir del DFD lgico
Entidad
los datos
- Los flujos de entrada son diferentes a los de salida
Proceso
Almacn
69
DFD lgico
DFD fsico
Orientado al qu hacer
Apunta al cmo hacerlo
Enfocado a la actividad propia de la Implementacin
del sistema.
incluye
organizacin y como opera
hardware, software, archivos y personas
involucradas
Describe los eventos de la actividad propia Depende de la tecnologa disponible
de la organizacin
Funciones de la actividad propia son ms
estables que la tecnologa
Entidad
externa 1
Entrada A
Nombre del
sistema
Entidad
externa 2
Salida F
Entidad
externa 3
Entrada B
Este diagrama muestra todo el sistema como un proceso sencillo con entidades
externas y sus principales entradas y salidas.
70
Entidad
externa 1
Entrada A
Proceso
general
A
Registro A
Proceso
general
C
Flujo de datos C
Flujo de datos B
Salida F
Registro E
Entidad
externa 3
A1
A2
Registro A
Proceso
general
B
Registro E
Flujo de datos D
Proceso
general
D
Entrada B
Entidad
externa 2
Este diagrama describe slo los procesos ms generales e incluye los almacenes de
datos.
Posteriormente se crea diagrama hijo por cada proceso de nivel 0, usando la misma
metodologa, o simplemente se agrega al modelo procesos que no haban sido
considerados anteriormente.
Como ejemplo se presenta a continuacin, un esquema simple (no incluye todos los
procesos) del anlisis de proyectos en el SNI.
71
Instituciones
pblicas
Empresas
reguladas
Proyectos
Resultado tcnico-econmico
Analizar
proyectos
Hacienda
Ficha EBI
Resultado tcnico-econmico
Ficha EBI
Proyectos
Ingreso
oficina de
partes
Proyectos con
Timbre
Nmero de
oficio o Memo
Memos
oficios
Solicitud de
regularizacin
de proyectos
mal ingresados
Resultado
anlisis tcnico
econmico
Ingreso al
SNI
Fecha SNI
BIP
Proyectos
Ficha EBI
Ministerio
de
Hacienda
Proyectos para
anlisis
Anlisis
Tcnico-econmico
Resultado
anlisis tcnico
econmico
72
Ficha EBI
Anlisis Tcnico-Econmico
BIP
Anlisis
segn
metodologa
Proyectos para
anlisis
Resultado
anlisis tcnico
econmico
(MEMO firmado)
Instituciones
pblicas
Empresas
reguladas
RATE
Instiucin que
presenta el
proyecto
Proyectos
Discusin del
proyecto en la
coordinacin
del rea
BIP
Elaboracin
de Memo
Resultado
anlisis tcnico
econmico
(MEMO firmado)
Ministerio
de
Hacienda
73
Controles automatizados
Validaciones al ingreso y modificacin de datos
Cuadraturas de datos
Reportes de inconsistencias
Consistencia de Datos
Ingreso nico de datos en el origen
Registro de modificaciones histricas
Redundancia de datos mnima y justificada
Definicin de reglas especficas para la mantencin de datos histricos
Cobertura de procesos
Validacin de consistencia del Modelo de Datos con respecto a los procesos
diseados.
Cumplimiento de Reglas exgenas
Velar por el Cumplimiento de leyes, regulaciones, normas, acuerdos contractuales,
etc.
Aspectos de la calidad
funcional
Controles Automatizados
Consistencia de Datos
Cobertura de Procesos
Cumplimiento de reglas
exgenas
TOTAL
Pondera
dor
x%
x%
x%
Altern.
1
100
100
100
Altern.
2
100
100
100
...
Altern.
N
100
100
100
x%
100
100
100
100%
CF1
CF2
CFN
74
Definir Requisitos
Sistema
Desarrollo de SI
Definir Requisitos
software
Diseo
preliminar
Codificar
mdulos e
integrarlos
Diseo
detallado
Codificar & debug
Integrar el
software en el
sistema
Test y
Pre-operacin
Operacin y
Mantenimiento
75
Investigacin
preliminar
Definir requisitos
Breve anlisis
y especificacin
Diseo
y realizacin
Evaluacin
OK
KKK
Modificacin
OK
KKK
Diseo
...
76
Investigacin
preliminar
Definir requisitos
Breve anlisis
y especificacin
Diseo
y realizacin
Evaluacin
OK
OK
Modificacin
Diseo
...
77
Prototipo
Obs
erva
cin
Requisitos
Abs
trac
ci
Validacin
n
Espe
cifica
cin
Verificacin
Veri
fica
ci
n
Experi
menta
cin
Validacin
78
ANLISIS DE RIESGO
PLANIFICACIN
Y ANLISIS DE
REQUISITOS
7
7
6
7
6
2
0
5
4
8
5
EVALUACIN
DEL
CLIENTE
INGENIERA
79
f
u
n
c
i
o
n
a
l
i
d
a
d
Impropiedad
D
f
ici
t
Adaptabilidad
(la pendiente de la recta)
Retraso
Longevidad
t
0
t
1
t
2
t
3
t
4
t
5
tiempo
80
Evolucin de SI en cascada
f
u
n
c
i
o
n
a
l
i
d
a
d
t0
t1
t2
t3
t4
t5
tiempo
81
f
u
n
c
i
o
n
a
l
i
d
a
d
t0
t1
t2
t3
t4
t5
tiempo
f
u
n
c
i
o
n
a
l
i
d
a
d
evolutivo
incremental
anlisis de requisitos
en cada fase
Incremental con
1 anlisis de requisitos
t0
t1
t2
t3
t4
t5
tiempo
82
83
El clculo del esfuerzo requerido para cada fase es complicado, ya que depende de varias
variables. A pesar de esto hay modelos que tratan de dar respuesta a esta dificultad,
algunos de ellos son:
COCOMO: Constuctive Cost Model que tiene como objetivo estimar el esfuerzo, costo y
planificacin del desarrollo de software.
Puntos de Funcin.: En este mtodo la idea es obtener una medida cuantitativa del
tamao de las aplicaciones basndose en sus requisitos funcionales e ir midiendo la
productividad del proyecto en la medida que este avanza.
Nmero de lneas de cdigo: Otra manera bastante popular, es estimar la cantidad de
lneas de cdigo que generar el software a desarrollar. El problema con esto es que para
una misma funcionalidad el nmero de lneas de cdigo que se necesitarn depender del
lenguaje utilizado. Para solucionar esto existen tablas que convierten lneas de cdigo de
diversos lenguajes a Assembler o a nmero de puntos de funcin.
Cmo estos modelos o metodologas para medir el esfuerzo requerido requieren cierta
preparacin e informacin histrica, que a menudo no es dominio de la institucin es que
facilitamos la siguiente informacin obtenida en conversaciones con diversos jefes de
proyectos. Por lo mismo es solamente una referencia, ya que no responde a un estudio
riguroso del problema, pero que consideramos un dato valioso y orientador, dada la gran
variabilidad entre los tiempos y presupuestos estimados para un desarrollo y los que
finalmente resultan. En opinin de las personas entrevistadas, el esfuerzo requerido en
cada una de las fases del desarrollo de software es el siguiente:
Anlisis: 15%
Diseo y programacin: 75%
Testing: 10%
El Diseo aqu mencionado corresponde al Diseo lgico y fsico.
Por otra parte hay cuadros elaborados en Estados Unidos en base a miles de proyectos
de software que se pueden usar, pero que difieren entre s debido a :
-
84
Ejemplos de cuadros:
Mediano
16
24
Grande
16
23
38
36
22
25
Mediano
19
55
26
Grande
19
54
27
85
86
87
Anexo 11 Glosario
Arquitectura: En las tecnologas de la informacin (TI), especialmente en lo que refiere a
computadores y ms recientemente en lo que se refiere a redes, arquitectura es un
trmino que se aplica al proceso y resultado de pensar y especificar la estructura,
componentes lgicos, e interrelaciones lgicas de un computador, sistema operativo, red
u otro concepto.
Bases de datos: Es una coleccin de datos, organizada de tal forma que sus contenidos
pueden ser fcilmente obtenidos, gestionados y actualizados. El tipo de base de datos
dominante actualmente es el modelo relacional (aunque en Chile an hay un gran nmero
de bases de datos que usa archivos indexados). En este tipo de bases de datos, los
datos estn definidos de tal manera, que es posible reorganizarlos y obtenerlos de
diferentes maneras. Una base de datos distribuida es aquella que est dispersa o
replicada en diferentes puntos de la red. Una base de datos orientada al objeto es aquella
que es congruente con los datos definidos en clases de objetos y subclases.
Cdigo Fuente: Consiste en declaraciones de programacin que son creadas por un
programador, mediante un editor de texto o una herramienta visual de programacin y que
posteriormente es grabada en un archivo con un determinado nombre. Despus de este
proceso el cdigo fuente est listo para ser compilado. El resultado de est compilacin
es el cdigo objeto (esto no tiene que ver con orientacin al objeto).
Cdigo Objeto: Contiene una secuencia de instrucciones que el procesador puede
entender, pero que es difcil de ser ledo o modificado por seres humanos.
Cliente/Servidor: Describe la relacin entre dos programas computacionales en el cual
un programa, el cliente, pide un servicio a otro programa, el servidor, el cual satisface el
requerimiento. La idea de cliente/servidor puede ser usada por programas localizados en
un nico computador, pero este concepto es ms importante en redes. En una red, el
modelo cliente/servidor provee una manera conveniente para interconectar programas
que estn distribuidos en diferentes lugares. Estas transacciones son muy comunes en
las redes.
Datamart: Es un repositorio de datos obtenido desde datos operacionales y otras fuentes,
que est diseado para satisfacer requerimientos de una comunidad de trabajadores con
ciertos conocimientos especficos. Es ms pequeo que un Datawarehouse, de hecho el
conjunto de Datamarts, pueden construir un Datawarehouse. A diferencia de los
Datawarehouse, los Datamart se construyen a partir de los requerimientos del usuario
final.
Datamining: Es el anlisis de datos para encontrar relaciones que no haban sido
descubiertas anteriormente. Puede revelar asociaciones por ejemplo entre productos, en
este caso es conocida la relacin encontrada entre paales y cerveza. Esto porque
muchos padres de familia al comprar paales tambin compraban cervezas.
Datawarehouse: Es un repositorio central para toda la informacin importante que las
diversas reas de negocio de una organizacin acumula. El datawarehouse obtiene
informacin de diversas fuentes, para anlisis y accesos tiles a la informacin, pero
generalmente no se obtiene esta informacin del usuario final el cual necesita una base
de datos local especfica sobre algn tema.
88
89
90