Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Metodologa de Proyectos
Informticos
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.................................................................................... 10
2.5
TIPOLOGA DE PROYECTOS..................................................................................... 13
2.6
ALCANCE DE LA M ETODOLOGA EN CADA CASO ................................................... 15
2.7
HORIZONTE DE EVALUACIN................................................................................. 16
4.3.2
5
6
7
8
1 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 a Mideplan, 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 informtica 1 .
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.
Tambin es usual que no hayan respaldos de la informacin que es estratgica para la
organizacin.
Otro problema muy importante es que se le da ms importancia a la tecnologa que a la
gestin del proyecto.
A nivel operacional: el principal problema es la inexistencia de documentacin de los
sistemas. Esta situacin es comparable a construir un edificio sin haber hecho previamente
los planos y, como ya se mencion, esto influye en no tener independencia del proveedor
del sistema.
Otra falencia a nivel operacional es la inexistencia de programas fuentes, es decir,
inexistencia del cdigo humanamente entendible. En este caso slo existe el programa en
idioma mquina, lo cual se traduce en un conjunto de ceros y unos.
2 Aspectos Generales
2.1
2.1.1
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, video-conferencia, 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,
6
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 costo-beneficio.
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
Estructura de la Metodologa
Definicin de atributos
Adems consta de varios anexos, para ayudar a una mejor evaluacin del proyecto, como
tambin un mejor control del mismo cuando se este ejecutando.
Los anexos son:
Beneficios y costos
Modelamiento de Datos
2.3
Calidad funcional
Definciones legales
Glosario
Ciclo de proyectos informticos
2.4
Preinversin
Inversin
Operacin
Grafico N 1 Ciclo de vida de un proyecto
10
Los resultados esperados de cada etapa de preinversin, pasando desde idea a factibilidad,
se especifican a continuacin:
Etapas de la Evaluacin ExAnte de Proyectos (etapas del estado de preinversin)
Como se ha dicho, la seleccin de los mejores proyectos de inversin, es decir, los de
mayor conveniencia relativa (evaluacin) y hacia los cuales deben destinarse
preferentemente los recursos disponibles, constituye un proceso que sigue las siguientes
etapas secuenciales:
11
Del anlisis surgir la especificacin precisa del bien que se desea construir o el servicio
que se pretende dar. Y servir para adoptar la decisin de abandonar, postergar o
profundizar la idea de proyecto.
Etapa de Estudio en el Nivel de Perfil
Se estudian los antecedentes que permitan formar un juicio respecto de la conveniencia y
factibilidad tcnico-econmica de llevar a cabo la idea de proyecto.
El nfasis est en identificar los beneficios y costos pertinentes respecto de la situacin base
(situacin actual optimizada), sin incurrir en mayores costos en recursos financieros y
humanos para medirlos y valorarlos, debe incluir un anlisis preliminar de los aspectos
tcnicos, estudios de mercado y los de evaluacin. Se utilizan estimaciones gruesas de los
beneficios y costos. Generalmente basadas en informacin existente, es decir, sin incurrir
en costos significativos por concepto de levantamiento de informacin.
Como conclusin de esta etapa, estn las decisiones alternativas de abandonar, postergar o
profundizar el proyecto pasando a la etapa de prefactibilidad.
Etapa de Estudio de Prefactibilidad
Se examinan con mayor detalle las alternativas viables desde el punto de vista tcnico y
econmico que fueron determinadas en la etapa anterior, y se descartan las menos
atractivas.
El nfasis de esta etapa es medir los beneficios y costos identificados en la etapa de perfil.
Existe un esfuerzo de inversin en informacin para disminuir la incertidumbre.
Es necesario estudiar con especial atencin los aspectos de mercado, la tecnologa, el
tamao y la localizacin del proyecto, las condiciones institucionales y legales relevantes
para el proyecto.
El estudio de mercado es la base para estimar los ingresos, incluir un estudio de la oferta y
demanda, as como de los precios de comercializacin. El anlisis tecnolgico incluye
equipos, materias primas y procesos, que permiten determinar los costos del proyecto.
Sobre el tamao y localizacin del proyecto se debe considerar la identificacin y
localizacin de los centros de consumo, de abastecimiento de insumos, canales de
distribucin, competencia, proyecciones de crecimiento, as como el impacto en el medio
ambiente.
El anlisis de los aspectos administrativos permite determinar algunas componentes de
costo fijo y la organizacin de los recursos humanos, fsicos y financieros. El anlisis de los
aspectos legales permite conocer las restricciones de ese tipo que limitan al proyecto.
Ejemplo: tributacin (pago de impuestos), permisos requeridos, contaminacin ambiental,
eliminacin de desechos.
12
Todo lo anterior permite tener una estimacin de los montos de inversin, costos de
operacin y de los ingresos que generara el proyecto durante su vida til. Lo que se utiliza
para la evaluacin econmica y para determinar las alternativas ms rentables. Conviene
sensibilizar los resultados de la evaluacin a cambios en las variables ms importantes.
Como resultado de la etapa se debe decidir realizar el proyecto o postergar, abandonar o
profundizar pasando a la etapa de factibilidad.
Etapa de Estudio de Factibilidad
La factibilidad se enfoca a un anlisis detallado y preciso de la alternativa que se ha
considerado ms viable en la etapa anterior. El nfasis est en medir y valorar en la forma
ms precisa posible sus beneficios y costos.
Dada la cantidad de recursos destinados a esta etapa, slo llegarn a ella los proyectos para
los que no hay duda de su rentabilidad positiva, es decir, que se van a llevar a cabo. Por
ello, toma ms importancia los flujos financieros y la programacin de obras.
Una vez definido y caracterizado el proyecto, debe ser optimizado en tamao, localizacin,
momento ptimo de la inversin, etc.
Se debe coordinar la organizacin, puesta en marcha y operacin del proyecto. Determinar
el calendario de desembolsos para la inversin, disponibilidad de equipos y sus plazos,
anteproyecto de ingeniera, seleccin y entrenamiento del personal de administracin,
operacin y mantenimiento. Tambin las fuentes, condiciones y plazos de financiamiento.
Esta etapa es la conclusin del proceso de aproximaciones sucesivas en la formulacin y
preparacin de un proyecto y constituye la base de la decisin respecto a su ejecucin.
2.5
Tipologa de proyectos
13
Criterio de evaluacin
Costo eficiencia a nivel cualitativo
Costo eficiencia a nivel cuantitativo (segn
metodologa)
Mde U$ 50.000 y hay cambios de procesos Costo Beneficio
que involucran ahorro de costos para
usuarios.
Tabla N1: Criterios de Evaluacin segn tipo de proyecto
En los criterios de evaluacin, "costo eficiencia a nivel cualitativo" corresponde al nivel de
evaluacin que se establece en el Instructivo SEBI para los proyectos de Informtica,
mientras que "costo eficiencia a nivel cuantitativo" corresponde a la presente metodologa 4 .
En lo sucesivo, todas las cifras en dlares son al valor del dlar observado a la fecha de la evaluacin del
proyecto.
4 En particular el captulo 4.
14
2.6
En esta metodologa se usa una tcnica de evaluacin de alternativas aplicable a cada una
de las tipologas. La tcnica de evaluacin est basada en tablas con ponderadores. Cada
tipologa tiene sus tablas pertinentes.
Adems, segn cada tipologa y la etapa en curso se determinan distintos requisitos de
informacin que se debe presentar, esto queda reflejado en el Grfico N 3:
IDEA
Metodologa
(b) y (c)
PERFIL
Metodologa
(b) y (c)
PREFACTIBILIDAD
FACTIBILIDAD
DISEO
Metodologa
(a),(b) y (c)
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).
15
Horizonte de Evaluacin
El horizonte de evaluacin, debe considerar como mximo cuatro aos, debido a los
cambios tecnolgicos que en el rea informtica ocurren con gran velocidad.
16
3 Preparacin de Proyectos
La informacin necesaria para postular a cada etapa de acuerdo a cada tipologa de
proyectos se enumera a continuacin en la Tabla N 2. La marca en cada celda indica los
requisitos mnimos necesarios para esa tipologa, la celda en blanco indica que ese
requisito no es imprescindible para esa tipologa, no obstante, en proyectos especficos se
pueden exigir ms requisitos que los que aqu se sealan. Los nmeros entre parntesis en
la primera columna de requisitos de informacin, hacen referencia al punto dentro de este
captulo en que se describe dicho requisito
Proyectos de
desarrollo
Equipamiento, adquisicin,
mejoramiento, ampliacin o
reposicin
Perfil
Diseo
Diseo
Ejecucin
Perfil
Ejecucin
Ver Nota al pi 6
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
Procesos claves dentro de la institucin, ya que las mejoras a estos procesos es lo que
se debe desprender del plan informtico
Estrategia de capacitacin
3.4
Si se desea emplear esta metodologa, se pueden consultar mayores detalle en la Gua metodolgica
general para la preparacin y evaluacin de proyectos de inversin social, Sann, Hctor, ILPES, 1995
19
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.
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 hijos ms
relevantes).
20
3.5
La idea es describir los requerimientos principales a los cuales debe responder la solucin.
Estos requerimientos deben ligar el rendimiento de la solucin a implementar con procesos
estratgicos de la solucin. Por ejemplo, para un servicio determinado para el cual es muy
importante el nmero de reportes para beneficiarios y se ha determinado como decisin
estratgica disminuir las colas, el requerimiento debiera fijarse en el nmero de
cotizaciones por unidad de tiempo que se necesitan para cumplir ese objetivo.
3.6
En este punto es deseable un cronograma o carta gantt mostrando las actividades necesarias
para realizar el levantamiento y cuanto tiempo requerir. A diferencia de la programacin
de la planificacin del desarrollo del software propiamente tal, el tiempo planificado para
esta actividad debiera ser bastante exacto.
3.7
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.
ITEM
UNIDADES*
PRECIO
UNITARIO
CANTIDAD
VALOR TOTAL
(M$)
Profesionales1
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.
21
Adems, se debe informar de los requerimientos totales de personal del estudio de acuerdo al
siguiente esquema:
PERSONAL
PROPIO
EXTERNO
(Nmero de horas)
(Nmero de horas)
Profesionales1
Tcnicos
Secretarias, Asistentes y otros
Otros
TOTAL
1\. - Los profesionales deben ser desagregados por tipo y nivel.
Estimacin de beneficios
22
realizar otras. Esta descripcin se hace simbolizando cada tarea por una barra, cuyo largo
depender del tiempo que toma realizar cada tarea.
A continuacin se muestra un ejemplo, elaborado en Microsoft project 98 8 :
: Microsoft Corporation
23
24
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 refleje 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.
4.2
Atributos Relevantes
28
- La alternativa de solucin est de acuerdo con la poltica informtica (si es que existe) de la
institucin.
- La institucin dispone de las capacidades tcnicas y administrativas para soportar la
solucin. ( por ejemplo para administrar la red)
Atributos evaluables (deseables y muy deseables)
Los atributos evaluables son aquellos medibles y por tanto que permiten una evaluacin y
discriminacin de cada alternativa, lo que es importante pues las alternativas de la solucin
pueden ser variadas y complejas, para la decisin de implementar una solucin.
La clasificacin de atributos en muy deseables o deseables debe formularse en base al plan
informtico de la institucin.
Como sugerencia, creemos importante que la evaluacin de alternativas considere atributos
que hagan hincapi en la informacin, la cual es soportada por la tecnologa. Muchas veces,
por ejemplo, se eligen soluciones eficientes, pero en reas que la institucin no necesita tal
eficiencia. Por otra parte, alguna institucin puede que tenga informacin disponible, sin
embargo, la seguridad de la informacin es mala. En este caso, aparentemente la solucin es
eficiente, pero est descuidando un punto importante que es el riesgo de prdida de la
informacin.
Es as que ms adelante, en la exposicin de tcnicas de evaluacin de alternativas, se
toman en cuenta atributos de la informacin, junto con otros de carcter tcnico.
En cuanto a los atributos es importante para la evaluacin de soluciones, construir tablas en
las cuales se diga cules fueron los conceptos considerados y los pesos realtivos que para ellos
se asignaron. La tcnica se expone a continuacin.
4.3
La tcnica descrita a continuacin busca obtener un puntaje para cada una de las soluciones a
evaluar, considerando los criterios sealados anteriormente y los antecedentes recogidos en las
etapas anteriores.
Si existiera slo una alternativa, el puntaje deber ser calculado de todas maneras para ella, ya
que permite apreciar cmo se tom la decisin de optar por la solucin.
Adems, se sugiere que las matrices expuestas a continuacin sean completadas tambin en
el proceso de licitacin para la evaluacin de las propuestas en concurso.
29
4.3.1
ii.
iii.
iv.
30
Funcionalidades
Altern.
Altern.
del Sistema
1
2
MUY DESEABLES
100%
50%
(%Cumplimiento)
Informacin en Lnea
1
1
Interfaces Grficas
1
0
DESEABLES
33%
100%
(%Cumplimiento)
Emisin de cartas
0
1
Control de cambios
1
1
Otros atributos menores
0
1
Total
79.9
65
(EF1)
(EF2)
Tabla 5: Matriz de Efectividad
...
Altern.
N
100%
1
1
33%
0
1
0
79.9
(EFN)
Para otros ejemplo 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 deseables y de un
0.3 para las funciones deseables. En el ejemplo, utilizando dichos ponderadores, los puntajes
(multiplicados por 100) son 79.9 (0.7*100+0.3*33), 65 (0.7*50+0.3*100) y 79.9
respectivamente.
Los valores sugeridos para ponderar las funciones muy deseables y las deseables pueden
ser modificados, incluyendo la justificacin por hacerlo.
B) Plataforma Tecnolgica
En este factor se busca capturar que la solucin est basada en un conjunto de herramientas
que permitan, con una alta probabilidad de xito, la construccin de un sistema que satisfaga
los siguientes criterios:
Confidencialidad: debe evaluarse el nivel de proteccin que cada alternativa ofrece
contra la divulgacin no autorizada de la informacin. En sta, debern considerarse
aspectos como:
1. Sistema operativo
2. Base de datos
3. Conexin con otros sistemas de informacin (a travs de Internet o
localmente)
4. Acceso a medios de respaldo
Integridad: est relacionado con la precisin y suficiencia de la informacin. Tambin con
la validez de la informacin.
31
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.
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
Integridad
Disponibilidad
Confiabilidad
Informacin Externa
TOTAL
Pondera
dor
Altern.
1
Altern.
2
x%
X%
Y%
Z%
W%
100%
100
100
100
80
80
PT1
100
20
100
100
80
PT2
...
Altern.
N
40
100
30
100
100
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.
32
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 siguiente 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
Portabilidad: Compatibilidad con otras plataformas, en cuanto a hardware y software
Accesibilidad: Se refiere a la disposicin de la plataforma, para ser accesada desde otra.
Escalabilidad: Factibilidad de hacer crecer el sistema por etapas
En cada celda se debe colocar un 1 si la alternativa cumple con el aspecto tcnico y un 0 si
no. Luego se debe obtener el porcentaje de cumplimiento de cada uno de los cuatro grupos
de aspectos tcnicos. En base a estos porcentajes se calcula un promedio ponderado para
cada alternativa. Los ponderadores deben calcularse de acuerdo a lo indicado en el anexo 1.
A continuacin se presenta un ejemplo. Para un listado ms completo de aspectos tcnicos,
se puede ver el punto 3 del Anexo 2: Elementos a considerar en la Evaluacin Tcnica de
Proyectos Informticos.
ASPECTOS TCNICOS Ponderador Altern.
Altern.
...
Altern.
SISTEMA
1
2
N
SEGURIDAD
X%
%100
%75
%50
(% cumplimiento)
Sistemas de Respaldos
1
1
1
Sistema de recuperacin
1
1
1
Control de acceso
1
1
0
Encriptacin de datos
1
0
0
PORTABILIDAD
Y%
%100
%100
%100
(%Cumplimiento)
Herramientas para importacin
y exportacin de datos .
%0
%100
%100
%100
%100
%100
%0
%100
%0
Canales de comunicacin en
lnea con otras aplicaciones
TOTAL
CT1
CT2
CTN
DISPONIBILIDAD
Z%
Up time garantizado de ms
de 98%
ESCALABILIDAD
ACCESIBILIDAD
(%Cumplimiento)
W%
U%
33
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
:
:
:
100
:
:
:
ACO1
ACO2
:
:
:
Altern.
N
40
ACON
34
Ejemplo:
Ahorro de papel
Ahorro
en
promocin(marketing)
Ahorro en distribucin
de la informacin
Ahorro en reparaciones
SUMA
Promedio
Altern.
1
20
Altern.
2
30
Altern.
3
10
30
80
50
100
40
80
10
160
40
70
220
55
90
230
57,5
Ponderador
x%
y%
z%
w%
100%
Altern.
1
EF1
PT1
Altern.
2
EF2
PT2
CT1
ACO1
P1
CT2
ACO2
P2
...
Altern.
n
EFN
PTN
CTN
ACON
PN
PAji * Ponderadorj
100
35
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%)
Cumple totalmente:
Cumple adecuadamente:
Cumple con restricciones:
Cumple con muchas restricciones:
No cumple:
100 puntos
80-99 puntos
60-79 puntos
40-59 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.
4.3.2
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 1
n
) / (1+r)t
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 y una tasa social
de descuento del 10 %, con lo cual se obtiene: Factor de Recuperacin = 0,3154. 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 costoeficiencia 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
Ponderad
or
30%
25%
35%
10%
100%
Altern.
1
100
60
40
50
64
Altern.
2
80
100
80
40
81
Altern.
3
60
100
60
60
70
37
38
Mantenimiento preventivo.
Ingeniera de Sistemas con Soporte Tcnico, Desarrollo de Aplicaciones y Consejera
Informtica.
Respaldo y prestigio
Se debe considerar si el proveedor es capaz de ofrecer garantas como cumplimiento de
plazo de entrega, soporte ante fallas, ampliaciones, compatibilidades con otros equipos, lo
que constituye el respaldo del proveedor.
Los indicadores ms significativos del prestigio son: presencia en el mercado, nmina de
equipos instalados y montos que estos representan, rentabilidad, liquidez, razn deuda
patrimonio, etc.
Como es sabido, las bases de una licitacin se conforman a grandes rasgos por las bases
tcnicas y las bases administrativas.
39
7 Bibliografa
- Eduardo Contreras y otros. Metodologa de informtica de MIDEPLAN 1992.
- Information Systems Audit and Control Foundation (ISACF). http://www.isaca.org
Resumen Ejecutivo de COBIT (Objetivos de control para la informacin y tecnologas)
2da Edicin Abril de 1998. Copyright 1996, 1998
- Information Systems Audit and Control Foundation (ISACF).
Marco Referencial de COBIT(Objetivos de control para la informacin y tecnologas) 2da
Edicin Abril de 1998. Copyright 1996, 1998
- Information Systems Audit and Control Foundation (ISACF).
Objetivos de control de COBIT(Objetivos de control para la informacin y tecnologas)
2da Edicin Abril de 1998. Copyright 1996, 1998
- Tecnologas de la Informacin y su uso en Gestin de Oscar Barros V. Primera edicin
Copyright 1998 McGraw-Hill.
- Pgina http://www.ji.si.ehu.es/users/tap/ADSI/19992000/Tema1/
40
41
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
Total
fila
Orden
Item 6 Item 7
10. Ordenar la lista de tems de acuerdo al resultado obtenido, asignando los ponderadores
en forma tal que lo satisfagan y que su suma sea 100%. Como referencia, puede
utilizarse el porcentaje que representa el puntaje obtenido por un tem con respecto a la
suma de la columna "Total fila". En el ejemplo, el tem 4 obtendra un ponderador de
28,6% (6 dividido por 21). En todo caso, debe tenerse presente que la importancia
relativa de un tem respecto a otro incorpora elementos subjetivos, por lo cual los
ponderadores definitivos deben ser corregidos considerando dichos elementos, pero
siempre respetando el orden obtenido.
Inf. externa
(Gestin)
Confidencialidad
Integridad
Disponibilidad
Confiabilidad
(Gestin)
Inf. externa
0
1
10
40
20
10
20
42
Pondera
dor
Alternati
va 1
Alterna
tiva 2
Alternativ
a3
10%
40%
20%
10%
20%
100%
60
70
60
100
100
76
100
100
100
80
100
98
80
90
70
80
60
78
43
Nmero de tablas
b) Nmero de clientes
c) Nmero de transacciones (total o por cliente) por tipo (actualizaciones, consultas)
d) Crecimiento esperado de clientes
e) Crecimiento esperado de transacciones (total o por cliente)
f) Nmero de procesos masivos
Arquitectura Lgica de la Solucin
Se debe indicar si la solucin se basar en una arquitectura cliente - servidor, tecnologa
Internet, aplicaciones stand-alone, etc. Deber justificarse la arquitectura seleccionada en
trminos funcionales y otras consideraciones que se estimen relevantes. Particular
relevancia tienen consideraciones de carcter estratgico de la institucin.
44
45
Perifricos
f) Impresoras
Tipo de impresoras (lser, inyeccin de tinta, etc.)
Breve descripcin caractersticas tcnicas (calidad de impresin, velocidad, etc.)
g) Otros dispositivos (scaners, capturadores pticos, dispositivos de video, etc.)
Herramientas a utilizar para la construccin de la solucin
Detallar el software a utilizar para la construccin de la solucin:
a) Base de datos
b) Herramientas de productividad
c) Aplicaciones clientes
d) Otros
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
46
47
Por no tener que contratar personal adicional con respecto a la situacin optimizada.
Se considera como situacin base optimizada (sin proyecto) la contratacin de personal
adicional que permitira alcanzar los mismos objetivos que la configuracin computacional;
es decir, la alternativa de sustitucin de recursos de capital por trabajo. Este beneficio lo es
en la medida que exista dicha alternativa.
Del personal que actualmente labora en el sistema.
Este beneficio lo es bajo el supuesto de que las H-H liberadas tengan un uso alternativo
productivo. Si la alternativa es el ocio, en el caso de que con el proyecto disminuyan los
requerimientos diarios de H-H, tendramos slo un beneficio individual difcil de valorar.
Este ahorro de H-H corresponde a un aumento de la productividad.
Tipos de aumento de productividad
Con el nuevo sistema, se pretende reducir o eliminar el tiempo que las personas gastan en
desplazarse para intercambiar informacin o para realizar alguna accin que pudiera ser
llevada a cabo desde su escritorio.
Como ejemplos tpicos se tiene:
Entrega de informacin va diskette.
Ir a colocar papel a una impresora compartida.
Levantarse a buscar informacin escrita.
48
En el caso en que se est arrendando una oficina que ya no se va a necesitar una vez
adquirido el equipo computacional, se cuenta como ahorro el monto de dicho arriendo.
Tambin ocurre cuando se traspasa a medios magnticos la informacin antes contenida en
archivos y carpetas.
En el caso en que la oficina sea de propiedad de la institucin que adquiere el
equipo, el
ahorro proviene del uso alternativo que se le puede dar a esta oficina.
49
50
Para el caso social, la estimacin de beneficios y costos es similar al caso privado. Slo
deben hacerse ciertos ajustes a los costos y beneficios privados de modo que representen en
forma adecuada los beneficios y costos sociales.
Ahorro de tiempo de usuarios que realizan trmites en la Institucin.
En este caso es necesaria la realizacin de una encuesta o un estudio durante un tiempo
determinado, para medir la frecuencia media de pblico que llega. Para poder cuantificar
este beneficio se debe hacer una estimacin de la calificacin de las personas que realizan
los trmites, para luego calcular un sueldo promedio por unidad de tiempo.
Los supuestos de mantencin de frecuencias y composicin de la clientela deben quedar
explcitamente indicados.
Beneficios y costos intangibles (no valorables)
Se debe entregar un listado que incluya aquellos costos y beneficios que no se pudieron
valorar. Tpicamente, se tratan de los siguientes:
Costos
Como ejemplo: resistencia al cambio, problemas organizacionales por la introduccin de
computadores, cambios en las polticas de la organizacin, retrasos en la entrega por parte
de los proveedores.
Beneficios
Los beneficios intangibles, corresponden a aquellos, cuya valoracin econmica es difcil
de obtener. Estos pueden corresponder a mayor comodidad de los usuarios, mejor imagen
de la institucin, mejoramiento de las condiciones de trabajo para los funcionarios, etc.
Arriendo y leasing
En el caso que se adopte por un arriendo o un leasing, es necesario que se justifique esta
opcin, versus la inversin. La justificacin tiene que ser econmica o cualitativa.
51
DEFINICIN
Conjunto de entidades y relaciones que representan los datos de una organizacin o sistema
bajo anlisis.
Es construido en forma "bottom-up" a partir de los requerimientos establecidos para el
producto o servicio en desarrollo. Esto implica que se hace siempre necesario un estudio
previo de la organizacin o sistema que permita identificar y definir los requerimientos, y a
partir de ellos generar un MODELO que describa qu datos participan en el sistema y cmo
estos interactan entre s.
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
52
2.2
IDENTIFICACIN DE REQUERIMIENTOS
Consiste en buscar las fuentes de informacin, es decir, elementos que entreguen antecedentes
sobre el sistema o "problema" en estudio, con el fin de obtener informacin para la definicin
de entidades relacionadas.
Se consideran los siguientes puntos:
i)
ii)
iii)
iv)
v)
vi)
53
2.3.2 RELACIONES
Una relacin es una asociacin entre, exactamente, dos entidades. Por ejemplo, una
PERSONA (entidad) trabaja para un DEPARTAMENTO (entidad).
2.3.3
54
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.
55
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:
56
almacenado en
PRODUCTO
BODEGA
almacn de
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:
57
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.
58
- M:N (muchos a muchos): una ocurrencia de la primera entidad est relacionada con
muchas ocurrencias de la otra entidad, y viceversa.
59
Puede existir ms de un tipo de relacin entre dos entidades, las que deben dis tinguirse
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.
Error!Marcador no definido.Entidad
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.
60
Valores Atributos
Jos Prez
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.
61
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.
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.
El origen de un atributo puede traer ciertas complicaciones a la hora de determinar su
inclusin en una entidad. En este sentido, ser una regla el que todos los atributos de
entrada, es decir aquellos que no pueden ser derivados o calculados de otros atributos,
no sern incluidos en las entidades. Los atributos derivables, es decir aquellos que
resultan de combinar otros atributos, no sern incluidos ni en el modelo conceptual
ni en el modelo cannico. Ser una decisin de diseo el incluir atributos de este tipo
para propsitos como mejorar respuestas, agilizar navegaciones, etc. En todo caso, si
llegase a existir alguna duda respecto de las caractersticas de algn atributo, en cuanto
a si es de entrada o derivable, ser mejor incluirlo.
Similar a lo anterior, cada atributo incluido en el modelo deber corresponder a un
hecho particular que se desea registrar acerca de la entidad. Los cdigos compuestos o
"inteligentes", en donde cada dgito que compone tal cdigo en las distintas
ocurrencias describe informacin distinta, no deben ser incluidos, y se descompondr
en los datos atmicos que aporta cada componente, convirtindose cada uno de ellos
en un atributo por s mismo. Ser una decisin posterior el agruparlos para componer
una clave o cdigo especial.
e. Descripcin de Entidades
Es una tarea que se realiza continuamente. No es prudente describir una entidad apenas
sta es descubierta. El modelo de datos debe estar estable antes de hacerlo. Sin
embargo, la definicin de una entidad debe delinearse apenas se descubre la entidad.
Las propiedades que describirn a una entidad, y que son exigidas en los documentos
de especificacin, son las siguientes:
- Nombre: segn las caractersticas ya discutidas antes.
- Definicin: establece el significado de la entidad, describiendo su rol y
propsito para la organizacin. Debe dejar absolutamente claro el alcance de
la entidad, en trminos de acotar el tipo de ocurrencias que incorpora.
- Atributos: lista de los atributos de la entidad.
- Identificadores: atributos atmicos o combinacin de atributos y relaciones
que permiten la identificacin de las distintas ocurrencias (ver ms adelante).
f. Descripcin de Relaciones
De manera similar a las entidades, la descripcin final debe ser hecha cuando el
modelo se vea estabilizado, por lo tanto se sigue una descripcin evolutiva de las
mismas.
63
La descripcin de relaciones especfica las reglas que gobiernan cundo las instancias
individuales de cada entidad en la relacin estn de hecho asociadas con una instancia.
Se requieren las siguientes propiedades para describir una relacin:
Nombre:
Definicin:
Reglas de Existencia: establece las condiciones bajo las cuales la relacin es creada y
borrada.
g . Identificador de Entidades
- Debe haber al menos un atributo (o combinacin de stos y/o relaciones) cuyos
valores identifiquen en forma nica cada entidad. Este ser el identificador de la
entidad.
- No es necesario denotar al identificador inmediatamente descubierta la entidad, pero
si es indispensable que la entidad tenga, al final, un identificador que distinga a las
ocurrencias de la entidad.
- Una entidad podr tener ms de un identificador, pero no es importante distinguir
uno de ellos como "primario" en el modelamiento conceptual. Incluso puede ser
postergado hasta la fase de Diseo.
- 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.
2.4
64
Ejemplo:
65
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.
66
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.
67
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
68
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.
EMPLEADO (nmero empleado, nombre empleado, nmero departamento,
nombre departamento, cargo empleado, sexo empleado).
CARGA EMPLEADO (nmero empleado, cdigo carga).
CARGA (cdigo carga, nombre carga, edad carga).
Las entidades que se agregan para romper la relacin M:N, como en el caso de
CARGA EMPLEADO, reciben el nombre de "entidades asociativas" o "NUB".
69
- 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.
70
71
Entidad
Proceso
Almacn
72
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
No muestra los almacenes de datos
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.
73
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.
Ejemplo: Diagrama de Contexto de Anlisis de proyectos en el SNI
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
74
Ficha EBI
Anlisis Tcnico-Econmico
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
75
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
76
Sin prototipos
En cascada (Waterfall)
Con prototipos
Desechable
Parte del sistema definitivo
Incremental
Evolutivo
Ciclo de vida en espiral
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
77
OK
Modificacin
Diseo
...
78
Modificacin
Diseo
...
79
Abs
trac
Validacin
Espe
cifica
Verificacin
Veri
fica
Experi
menta
Validacin
80
PLANIFICACIN
Y ANLISIS DE
REQUISITOS
ANLISIS DE RIESGO
7
7
6
7
6
2
3
0
5
4
8
5
EVALUACIN
DEL
CLIENTE
INGENIERA
81
f
u
n
c
i
o
n
a
l
i
d
a
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
f
u
n
c
i
o
n
a
l
i
d
a
d
t0
t1
t2
t3
t4
t5
tiempo
83
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
evolutivo
incremental
anlisis de requisitos
en cada fase
Incremental con
1 anlisis de requisitos
t0
t1
t2
t3
t4
t5
tiempo
84
85
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 :
Diferencias en el significado de las fases
Mtodos de desarrollo distintos
Productos distintos, en algunos casos se necesita ms anlisis que en otros
Habilidad de los programadores, lo cual impacta en el tiempo de desarrollo
Diferencia en los plazos requeridos
86
Ejemplos de cuadros:
Distribucin de Recursos por Fase (%)
Fase
Tamao
Pequeo
Intermedio
Diseo
16
16
Diseo
26
25
programacin
Programacin y 42
40
Testing
Integracin
16
19
Mediano
16
24
Grande
16
23
38
36
22
25
Mediano
19
55
26
Grande
19
54
27
87
88
89
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 diferente
puntos de la red. Un 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.
90
92