Академический Документы
Профессиональный Документы
Культура Документы
Departamento de Inversiones
METODOLOGA DE PROYECTOS
INFORMTICOS
Autores:
1
2
Introduccin....................................................................................................4
Aspectos Generales.........................................................................................6
2.1
TEORA EN LA QUE SE BASA LA METODOLOGA..................................................................6
a) Evolucin de los proyectos de Informtica.........................................................................6
b) Fundamentos para la adopcin de un criterio de Costo/ Eficiencia...................................6
c) Criterios de aprobacin o rechazo de proyectos informticos............................................7
2.2
ESTRUCTURA DE LA METODOLOGA..................................................................................8
2.3
CICLO DE PROYECTOS INFORMTICOS ...............................................................................8
2.4
LOS PROYECTOS EN EL SNI ...............................................................................................9
a) Ciclo de vida de los proyectos .............................................................................................9
b) Etapas de la Evaluacin ExAnte de Proyectos (etapas del estado de preinversin).......10
c) Etapa de Generacin y anlisis de la idea de proyecto.....................................................11
d) Etapa de Estudio en el Nivel de Perfil ...............................................................................11
e) Etapa de Estudio de Prefactibilidad ..................................................................................11
f) Etapa de Estudio de Factibilidad .......................................................................................12
2.5
TIPOLOGA DE PROYECTOS ..............................................................................................13
2.6
ALCANCE DE LA METODOLOGA EN CADA CASO .............................................................14
2.7
HORIZONTE DE EVALUACIN ..........................................................................................15
Preparacin de Proyectos.............................................................................16
3.1
RESUMEN EJECUTIVO ......................................................................................................17
3.2
PLAN O POLTICA INFORMTICA DE LA INSTITUCIN ......................................................17
3.3
IDENTIFICACIN Y DEFINICIN DEL PROBLEMA ..............................................................18
3.4
DIAGNSTICO DE LA SITUACIN ACTUAL (SIN PROYECTO) ............................................18
a) Descripcin de la Organizacin y/o entorno Afectado por el Proyecto............................18
b) Descripcin de la Unidad o Departamento .......................................................................19
c) Presentacin de la solucin informtica actual.................................................................19
d) Descripcin de los procesos ..............................................................................................19
e) Diagrama de Flujo de Datos (DFD) presentando la situacin actual ..............................19
3.5
DESCRIPCIN GENERAL DE REQUERIMIENTOS .................................................................20
3.6
PROGRAMACIN DE ACTIVIDADES PARA LA ETAPA DE DISEO ........................................20
3.7
REQUERIMIENTOS DE PERSONAL PARA POSTULAR A LA ETAPA DE DISEO. .....................20
3.8
ESTIMACIN DE BENEFICIOS ............................................................................................21
3.9
ESTIMACIN DE COSTOS DE INVERSIN, OPERACIN Y MANTENCIN PARA LA ETAPA DE
EJECUCIN ...................................................................................................................................21
3.10 CRONOGRAMA Y CARTA GANTT .....................................................................................21
3.11 TRMINOS DE REFERENCIA PARA CONTRATAR ETAPA DE DISEO ...................................22
3.12 OPTIMIZACIN DE LA SITUACIN ACTUAL .......................................................................23
a) Medidas administrativas o de rediseo organizacional.......................................................23
b) Inversin marginal a la solucin existente ........................................................................23
3.13 ANLISIS DE REQUERIMIENTOS (DISEO LGICO)...........................................................24
a) Diagrama de flujo de datos (lgico)..................................................................................24
b) Modelo de datos.................................................................................................................24
c) Otra documentacin...........................................................................................................24
3.14 ALTERNATIVAS DE SOLUCIN .........................................................................................25
a) Restricciones asociadas a cada alternativa.......................................................................25
b) Producto o servicio esperado en cada alternativa ............................................................25
5
6
7
8
CAPACITACIN ................................................................................................................37
MANTENIMIENTO ............................................................................................................37
RESPALDO Y PRESTIGIO ...................................................................................................38
Bibliografa ...................................................................................................39
Anexos ...........................................................................................................40
ANEXO 1: TCNICA PARA PRIORIZACIN Y ASIGNACIN DE PONDERADORES ..............................40
ANEXO 3: BENEFICIOS Y COSTOS.................................................................................................47
ANEXO 4: MODELAMIENTO DE DATOS .........................................................................................51
ANEXO 5: DIAGRAMA DE FLUJO DE DATOS (DFD) .....................................................................68
ANEXO 6 CALIDAD FUNCIONAL ..................................................................................................73
ANEXO 7: ETAPAS DE UN PROYECTO DE DESARROLLO EN INFORMTICA. ..................................74
ANEXO 8: EJEMPLOS DE MEDIDAS DE EFECTIVIDAD. ...................................................................82
ANEXO 9 ESFUERZO REQUERIDO PARA CADA FASE .....................................................................83
ANEXO 10 DEFINICIONES LEGALES .............................................................................................85
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 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, se debe destacar 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.
2 Aspectos Generales
2.1
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.
b) Fundamentos para la adopcin de un criterio de Costo/ Eficiencia.
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
6
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:
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.
c) Criterios de aprobacin o rechazo de proyectos informticos
Como ya se expuso, un importante elemento para aprobar o rechazar un proyecto, es la
evaluacin costo-eficiencia. Sin embargo, esto no basta, para que un proyecto sea aprobado, tiene
que estar bien justificado, ya sea con beneficios cualitativos o cuantitativos. En este sentido, ser
muy importante la coherencia del proyecto con un plan informtico o con lneas estratgicas que
se haya planteado la institucin, es decir se revisar que los sistemas a implementar cumplan con
los objetivos que se ha planteado la institucin. Tambin se verificar que el clculo de
ponderadores responda a la estrategia, es as que si un departamento de la organizacin ha
planteado que privilegiar la seguridad, no podra presentar el ponderador correspondiente un
porcentaje bajo.
En general, se apreciar la coherencia que presenta el proyecto en s.
2.2
Estructura de la Metodologa
Definicin de atributos
Calificacin de los atributos de cada alternativa
Asignacin de un puntaje a cada alternativa, en base a sus atributos
Clculo del ndice de eficiencia
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:
2.3
2.4
Inversin
Operacin
Grafico N 1: Ciclo de vida de un proyecto
Los resultados esperados de cada etapa de preinversin, pasando desde idea a factibilidad, se
especifican a continuacin:
b) 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:
Generacin y Anlisis de la idea de Proyecto
Estudio de prefactibilidad
Estudio de Factibilidad
10
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:
c) Etapa de Generacin y anlisis de la idea de proyecto
Es crucial contar con un buen diagnstico, de modo que la generacin de una idea de proyecto de
inversin surja como consecuencia clara de necesidades insatisfechas, de objetivos y/o polticas
generales de la organizacin, de un plan de desarrollo, etc.
Se debe establecer su magnitud, a quienes afecta y la confiabilidad de la informacin utilizada.
As como tambin las alternativas disponibles.
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.
d) 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.
e) 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.
11
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.
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.
f) 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.
12
2.5
Tipologa de proyectos
El mtodo de evaluacin de cada tipologa, variar segn el monto involucrado. Es as que para
montos inferiores a US$ 50.0003 el anlisis ser cualitativo, para el caso de montos mayores se
aplicar costo-eficiencia o si se pueden medir y valorar los beneficios costo-beneficio. En
sntesis:
Costo del Proyecto
Menos de US$ 50.000
Ms de US$ 50.000
Criterio de evaluacin
Costo eficiencia a nivel cualitativo
Costo eficiencia a nivel cuantitativo (segn
metodologa)
Ms de US$ 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 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.
13
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:
DESARROLLO DE
APLICACIONES
EQUIPAMIENTO O
ADQUISICIONES
MEJORAMIENTO O
AMPLIACIN O
REPOSICIN
IDEA
Metodologa
(b) y (c)
Metodologa
(b) y (c)
PERFIL
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).
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.
14
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.
15
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.
Perfil
Diseo
Diseo
Ejecucin
Equipamiento, adquisicin,
mejoramiento, ampliacin o
reposicin
Perfil
Ejecucin
Proyectos de
desarrollo
16
En el caso de proyectos de desarrollo, con esa informacin a nivel de perfil, se podr analizar la
idea y trabajar en la propuesta de diseo, obtenindose la informacin relevante para la prxima
etapa de inversin
La informacin entregada para llevar a cabo la etapa de diseo en el caso de proyectos de
desarrollo es un elemento preliminar de desarrollo. sta sirve de base para el anlisis que se
efectuar en el levantamiento, por ello algunos requerimientos de informacin para pasar de
perfil a diseo se repiten cuando se pasa de diseo a ejecucin en este caso cada requisito debe
ser tratado en mayor profundidad.
Para mayores detalles sobre el Diagrama de Flujo de datos consultar el Anexo 5, para el modelo
conceptual de datos ver el Anexo 4.
A continuacin se detallan cada uno de los requisitos de informacin mencionados en la Tabla N
2.
3.1
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:
-
17
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
18
19
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.
TEM
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.
20
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)
Profesionales
Tcnicos
Secretarias, Asistentes y otros
Otros
TOTAL
1\. - Los profesionales deben ser desagregados por tipo y nivel.
Este cuadro debe completarse en base a la informacin de estudios similares ya efectuados (si
existen), en base a informacin de los posibles proveedores (cotizaciones) y en base a las actividades
del estudio que se presenta.
3.8
Estimacin de beneficios
Se deben describir los beneficios en forma cualitativa. De ser posible identificar, medir y
valorar los beneficios, se sugiere considerar los tems incluidos en el Anexo 3.
3.9
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 988:
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)
3.11 Trminos de Referencia para contratar etapa de diseo
Los trminos de referencia deben incluir toda la informacin necesaria, para poder licitar el
diseo, as como la evaluacin de las distintas alternativas de solucin (en el caso que el
formulador estime que no hay capacidad tcnica al interior de la institucin para evaluar el
proyecto).
: Microsoft Corporation
22
En este sentido, se debe especificar claramente el producto final, el cual se traduce en:
-
23
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 se debe considerar la
alternativa de adquirirlas o acceder a ellas va convenio, versus la alternativa de desarrollarlas
nuevamente para la institucin.
Para proyectos de desarrollo de pginas web y otros desarrollos de Internet, intranet o Extranet,
debe solicitarse un mapa de navegacin que de cuenta de la informacin que se requiere en el
sitio Web. Adems es deseable un anlisis de los procesos involucrados mediante DFDs u otra
herramienta, que permitan un uso cooperativo real de las herramientas de Internet. Por otra parte,
es importante presentar procedimientos administrativos as como adquirir software y hardware en
lo que se refiere a seguridad.
24
25
Costos
Efectividad
Grfico N 5: Relacin costo - efectividad
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.
26
Atributos Relevantes
27
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.
28
Efectividad
Plataforma tecnolgica
Calidad tcnica de la solucin
Ahorro de costos operacionales
Adems es importante considerar la Calidad Funcional de la Solucin, pero que no puede ser
evaluada con el avance que tiene el proyecto a esta altura (postulando a etapas que nunca van ms
all del diseo), porque la informacin necesaria para evaluar los atributos se obtiene del Diseo
Fsico de la solucin, por este motivo solamente se deja como referencia la informacin
correspondiente a los atributos de Calidad Funcional en el anexo 6, sin exigir su evaluacin.
Cada uno de estos factores ser calificado con un puntaje de 1 a 100, de acuerdo a los siguientes
procedimientos:
A) Efectividad
El objetivo de esta evaluacin es calificar el nivel de satisfaccin de las necesidades a ser cubiertas
por el sistema en cuestin. Para ello, se debern considerar todas aquellas funciones que debieran
satisfacerse, tanto las de carcter operativo como las estratgicas y tcticas. Esta evaluacin debe
seguir los siguientes pasos:
i.
ii.
iii.
Verificar que las alternativas satisfagan todas las funciones imprescindibles, descartando
las que no lo hagan
iv.
Si existe ms de una alternativa que cumpla el criterio anterior, generar la siguiente matriz
(las funciones indicadas lo son a modo de ejemplo):
29
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
0
79.9
(EF1)
1
1
1
65
(EF2)
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 cada alternativa, como la suma de 1 (unos)
divididos por el total de atributos dentro de cada 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:
Sistema operativo
Base de datos
Conexin con otros sistemas de informacin (a travs de Internet o localmente)
Acceso a medios de respaldo.
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.
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 Anexo 2 que sea relevante para la tipologa del proyecto. Una vez
hecho esto, se deber elaborar la siguiente matriz.
ASPECTOS PLATAFORMA
Ponderador
Altern 1
TECNOLGICA
Confidencialidad
x%
100
Integridad
X%
100
Disponibilidad
Y%
100
Confiabilidad
Z%
80
Informacin Externa
W%
80
TOTAL
100%
PT1
Tabla 6: Matriz de Evaluacin Plataforma Tecnolgica
Altern. 2
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.
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
31
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
SISTEMA
SEGURIDAD
X%
(% cumplimiento)
Sistemas de Respaldos
Sistema de recuperacin
Control de acceso
Encriptacin de datos
PORTABILIDAD
Y%
(%Cumplimiento)
Herramientas para importacin
y exportacin de datos.
DISPONIBILIDAD
Z%
Up time garantizado de ms
de 98%
ESCALABILIDAD
W%
ACCESIBILIDAD
U%
(%Cumplimiento)
Canales de comunicacin en
lnea con otras aplicaciones
TOTAL
Tabla 7: Matriz de Evaluacin Calidad Tcnica
Altern.
1
%100
Altern.
2
%75
...
Altern.
N
%50
1
1
1
1
%100
1
1
1
0
%100
1
1
0
0
%100
%0
%100
%100
%100
%100
%100
%0
%100
%0
CT1
CT2
CTN
32
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.
Altern.
1
100
Altern.
2
100
Ahorro de papel
Ahorro
en
100
100
promocin(marketing)
Ahorro en distribucin de la
100
100
informacin
Ahorro en reparaciones
100
100
:
:
:
:
:
:
etc
:
:
SUMA
Promedio
ACO 1
ACO 2
Tabla 8: Matriz de Ahorro en Costos Operacionales
...
Altern.
N
40
100
100
:
:
:
100
:
:
:
ACO N
33
Ejemplo:
Altern.
1
20
Ahorro de papel
Ahorro
en
30
promocin(marketing)
Ahorro en distribucin de la
100
informacin
Ahorro en reparaciones
10
SUMA
160
Promedio
40
Tabla N 9: Ejemplo de ahorro de costos
Altern.
2
30
Altern.
3
10
80
50
40
80
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.
b) Evaluacin de alternativas
Una vez evaluados todos estos factores, se deber generar la siguiente matriz:
Ponderador
Altern.
ATRIBUTOS
1
EVALUABLES
Efectividad
x%
EF1
Plataforma Tecnolgica
y%
PT1
Calidad Tcnica
z%
CT1
Ahorro de Costos Op.
w%
ACO 1
TOTAL
100%
P1
Tabla N 10: Matriz de Evaluacin de alternativas
Altern.
2
EF2
PT2
CT2
ACO 2
P2
...
Altern.
n
EFN
PTN
CTN
ACO N
PN
PA ji * Ponderadorj
100
Donde:
Pi
:
PAji
:
Ponderador j :
Puntaje Alternativa i
Puntaje del atributo j de la alternativa i
Ponderador del atributo j (corresponde a los x%, y%, z% y w%)
100 puntos
80-99 puntos
60-79 puntos
34
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.
c) Detalle de la Inversin y clculo del indicador costo eficiencia
Los tems de costos de inversin y operacin, estn identificados en el Anexo 3 de Beneficios y
costos10.
Si todas las alternativas tuvieran costos similares, podra bastar con los puntajes para decidir una
seleccin. En caso contrario, se deber hacer un anlisis en base al indicador costo eficiencia,
el que est definido como:
RC j =
Cj
Pj
RCj : Razn de costo - eficiencia de la alternativa j, (costo por unidad de cumplimiento de los
objetivos)
Cj
: Costo Anual Equivalente de la Alternativa j
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;
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
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.
35
Altern.
1
100
60
40
50
64
Altern.
2
80
100
80
40
81
Altern.
3
60
100
60
60
70
36
6.1
Capacitacin
6.2
Mantenimiento
37
6.3
Respaldo y prestigio
38
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) 2
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) 2 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) 2
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/
39
8 Anexos
Anexo 1: Tcnica para priorizacin y asignacin de ponderadores
Dada una lista de tems a los cuales hay que clasificar para poder determinar el nivel de
importancia entre ellos, se debe proceder del siguiente modo:
1. Determinar los tems relevantes a clasificar y asignarles una identificacin.
2. Colocar la identificacin asignada en las filas y columnas de la matriz de la pgina siguiente
(la matriz tiene la misma cantidad de filas y columnas).
3. Colocar alguna marca en la diagonal de la matriz (sobre la diagonal no habr ninguna clase de
informacin).
4. Completar cada una de las celdas por sobre de la diagonal respondiendo a la siguiente
pregunta: El tem de la fila, es ms importante que el tem de la columna? Si la respuesta es
afirmativa, se debe colocar un 1 en la celda, en caso contrario, un 0. En el ejemplo, el tem 1
(en la fila) es ms importante que el tem 2 (en la columna) y por este motivo se coloca un 1
en la celda.
5. Cuando todas las celdas de una fila (por encima de la diagonal) estn completas, las celdas de
la columna correspondiente al mismo tem se deben llenar con el inverso del nmero (donde
hay un 1 se coloca 0 y viceversa).
6. Cuando todas las celdas estn llenas, se las suma obtenindose el total de la fila.
7. Luego de calcular los totales por fila, se asigna un nmero de orden a aquella fila cuyo total
es el mayor (un 1) y as sucesivamente siguiendo en forma decreciente de importancia.
8. Si dos de los totales son iguales, se asigna mayor prioridad al tem que la tiene con respecto al
otro. En el ejemplo, puesto que a los tems 3 y 7 les corresponde el mismo total (en este caso
3), debido a que el tem 3 es ms importante que el tem 7, se le asigna al primero el nmero
de orden 3 y al tem 7, el nmero de orden 4.
9. En la columna Orden se obtiene la secuencia de tems con su prioridad, uno respecto del
otro.
40
Total
fila
Orden
Item 1
Item 2
Item 3
Item 4
Item 5
Item 6
Item 7
0
1
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.
Un ejemplo de esta metodologa se presenta a continuacin, para el caso del clculo de la matriz
de plataforma tecnolgica.
Clculo de ponderadores para evaluar la plataforma tecnolgica:
Confidencialidad Integridad Disponibilidad Confiabilidad
Inf. externa
(Gestin)
Confidencialidad
Integridad
Disponibilidad
Confiabilidad
(Gestin)
Inf. externa
0
1
10
40
20
10
20
41
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
42
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.
43
f) Impresoras
Tipo de impresoras (lser, inyeccin de tinta, etc.)
Breve descripcin caractersticas tcnicas (calidad de impresin, velocidad, etc.)
g) Otros dispositivos (scanner, 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)
45
46
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.
47
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.
Ahorro en costos de operacin
Se refiere a ahorros en costos de operacin, con respecto a situacin base. A modo de ejemplo,
una disminucin de los costos de mantencin; o bien, dejar de pagar por servicios a empresas,
48
pues con la realizacin del proyecto estos servicios podrn desarrollarse internamente. Se debe
mencionar el detalle de cada uno de los costos de operacin que van a disminuir o bien
desaparecer, acompaado por el monto anual del ahorro que se produce al adquirir el equipo.
Mejoras en la gestin y en la toma de decisiones
Este tipo de beneficios son frecuentes, pero generalmente de muy difcil cuantificacin, lo
que puede en ocasiones llevar a que se consideren slo como intangibles, o bien, como el primer
tipo de ahorro de H-H antes expuesto, es decir, del personal adicional que se requerira para
obtener el mismo efecto de mejora en la gestin y la toma de decisiones.
Es importante tener presente no cometer el error de contabilizar ms de una vez algn beneficio.
Para ello debe ponerse atencin al clasificarlo. Por ejemplo, si se usa el mtodo de estimar el
ahorro de H-H adicionales equivalentes para alcanzar la misma mejora en la gestin que logra el
equipamiento computacional, no debe considerarse como un beneficio adicional del proyecto
dicha mejora de la gestin.
Costos privados
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.
49
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.
50
I. 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.
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
51
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)
Est formado por entidades y las relaciones entre ellas. A continuacin se describen cada uno de
estos elementos.
52
2.3.1 ENTIDADES
Corresponde al objeto que se quiere representar. Son elementos, reales o abstractos, acerca de las
cuales se requiere registrar informacin.
Ejemplo: CLIENTE, EMPLEADO,
SEGMENTO, PRODUCTO, etc.
CUENTA,
PROVEEDOR,
SERVICIO,
CANAL,
Una entidad es una clase de "cosas" con un nombre, que tiene el mismo conjunto de atributos: por
ejemplo EMPLEADO es una entidad. Una instancia de entidad es una ocurrencia especfica de la
entidad: por ejemplo, PEDRO PREZ Z. es una instancia de la entidad.
La representacin de una entidad ser, en principio, un rectngulo. A futuro, el cono particular
que sea definido como estndar depender de la eleccin y capacidades de representacin de una
herramienta CLASE especfica.
2.3.2
RELACIONES
Una relacin es una asociacin entre, exactamente, dos entidades. Por ejemplo, una PERSONA
(entidad) trabaja para un DEPARTAMENTO (entidad).
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:
53
fecha_ingreso_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.
54
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
Figura 2: Diagrama de una entidad
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
55
Las relaciones tienen una naturaleza que describe el tipo de asociacin, tales como:
-
Pertenencia
Jerarqua
Temporal
Complementariedad
Parentesco
Autoridad
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:
56
1:1 (uno a uno): una ocurrencia de una entidad est relacionada con slo una ocurrencia de
la otra entidad, y viceversa.
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.
M:N (muchos a muchos): una ocurrencia de la primera entidad est relacionada con
muchas ocurrencias de la otra entidad, y viceversa.
57
Existe un tipo especial de relaciones, las relaciones recursivas, que indican asociaciones entre las
ocurrencias de la misma entidad. La figura 10 muestra un ejemplo.
Atributos
Empleado
Cliente
58
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.
Error! Marcador no definido.Ocurrencia Entidad
Valores Atributos
Jos Prez
Marambio, Consultores
Considere cada entidad y establezca los hechos requeridos para sus ocurrencias; cada
uno de estos hechos puede ser un atributo.
Considere los sistemas existentes, automatizados o no. Examine los datos registrados
para ellos, pues cada uno puede ser un potencial atributo.
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.
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
59
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.
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
60
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.
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.
61
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
Entidades redundantes: se producen cuando los atributos son los mismos en diferentes entidades.
Se puede evitar esta redundancia si es posible dejar clara la diferencia por la va de las relaciones en
que participan. Ejemplo:
62
Atributos redundantes, se produce cuando un atributo puede ser obtenido a partir de otros.
Ejemplo: Total costo horas/ hombre en la entidad EMPLEADO.
Relaciones redundantes: No slo los atributos pueden ser redundantes, tambin las relaciones.
Este tipo de relaciones es preferible omitirlas del diagrama Entidad - Relacin. Ocurren cuando hay
trayectorias cerradas, pues entre cualquier par de entidades hay dos caminos alternativos de
navegacin. Pero, ellas dicen lo mismo? Entregan la misma informacin? La figura 15 muestra un
ejemplo de este tipo de relaciones:
63
Una relacin es redundante si es posible derivarla bajo cualquier condicin todo el tiempo, es
decir, si todas las asociaciones entre las concurrencias de las entidades fueran idnticas con o sin
la posibilidad de la relacin redundante.
No hay relaciones redundantes si en el ciclo cerrado sucede que:
- Las relaciones son de distinta naturaleza, por lo tanto, no hay transitividad.
- Hay dos o ms relaciones M:N (normalizadas o no)
Si hay una sola relacin M:N y todas las relaciones directas, ser redundante pues dice lo mismo
que la relacin indirecta que une las dos entidades. Es decir:
Relacin Directa: A-D
Relacin Indirecta: A-B-C-D
Se podra eliminar la relacin A-D ya que es redundante, sin embargo se debe considerar el largo
de la trayectoria que significa recorrer las entidades versus el nmero de requerimientos
asociados a esta trayectoria. La ventaja de la redundancia es que da ms claridad al usuario, ya
que representa con mayor exactitud la situacin que se quiere modelar. Las desventajas de la
redundancia son un mayor uso de procesador para actualizar varias ocurrencias y mayor espacio
de almacenamiento.
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.
64
- Cada entrada en la lista tiene un nombre nico. Si aparece el mismo nombre dos veces, por
ejemplo "fecha", agregue, un calificativo que los distinga, como "inicio" y "fin".
- El significado oculto de cdigos estructurados debe abrirse en atributos separados, y los
atributos originales deben ser excluidos. Por ejemplo, el ISBN, Internacional Standard Book
Number, identifica al editor, el sujeto de la materia, la secuencia de publicacin y un dgito
verificador. Todos estos deben separarse en atributos distintos, excepto el ltimo.
Un ejemplo de una lista correcta es el siguiente:
EMPLEADO (nmero empleado, nombre empleado, nmero departamento, nombre
departamento, cargo empleado, sexo empleado , cdigo carga empleado, nombre carga empleado,
edad carga empleado).
Con este ejemplo se ilustrarn los pasos de normalizacin.
b) Seleccionar el identificador Primario:
Si no hay identificador definido, defina uno en este momento. Si existe ms de un identificador,
seleccione uno que sea el identificador primario, usando alguno de estos criterios.
-
Seleccione aquel cuya tasa de uso se perciba mayor que los otros.
entidad. En el ejemplo: cdigo carga empleado, nombre carga empleado, edad carga empleado
siempre ocurrirn una vez por cada carga que tenga EMPLEADO.
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).
66
Para desarrollar un diagrama de flujo de datos hay que seguir los siguientes pasos:
1) Hacer lista de actividades para determinar:
- Entidades externas
- 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
68
Entidad
los datos
flujos de entrada son diferentes a los de salida
Proceso
Almacn
DFD fsico
Apunta al cmo hacerlo
Implementacin del sistema. incluye hardware,
software, archivos y personas involucradas
Depende de la tecnologa disponible
69
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
70
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.
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
71
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
72
Ponderador
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
73
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
74
OK KKK
Modificacin
Diseo
...
75
Modificacin
Diseo
...
76
Abstraccin
Validacin
Especificacin
Verificacin
Verificaci
n
Experimentacin
Validacin
77
ANLISIS DE RIESGO
PLANIFICACIN
Y ANLISIS DE
REQUISITOS
7
7
6
3
0
5
4
8
5
EVALUACIN
DEL
CLIENTE
INGENIERA
78
funcionalidad
Impropiedad
Dficit
Adaptabilidad
(la pendiente de la recta)
Retraso
Longevida
d
t0
t1
t2
t3
t4
t5
tiempo
funcionalidad
t0
t1
t2
t3
t4
t5
tiempo
80
funcionalidad
t0
t1
t2
t3
t4
t5
tiempo
funcionalidad
evolutivo
incremental
anlisis de requisitos
en cada fase
Incremental con
1 anlisis de requisitos
t0
t1
t2
t3
t4
t5
tiempo
81
Este listado no pretende ser exhaustivo, y lo que es ms importante, las medidas a considerar para
medir la efectividad, dependern de los objetivos del proyecto. Por ejemplo, si proyecto no
genera grandes demandas de almacenamiento, no tiene sentido considerar esta variable como
deseable o muy deseable.
82
83
Ejemplos de cuadros:
Distribucin de Recursos por Fase (%)
Fase
Tamao
Pequeo Intermedio Mediano
Diseo
16
16
16
Diseo programacin
26
25
24
Programacin y Testing
42
40
38
Integracin
16
19
22
Grande
16
23
36
25
Grande
19
54
27
84
85
86
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.
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
87
esta informacin del usuario final el cual necesita una base de datos local especfica sobre algn
tema.
Este concepto ha ganado aceptacin, en parte, por la posibilidad de realizar Datamining. El
datawarehouse es usado tambin por otra aplicacin , este es el Sistema de Soporte a la Decisin
(DSS).
Decision Support System (DSS): Es una aplicacin que analiza datos de negocio y lo presenta
de tal manera, que los usuarios pueden tomar decisiones en forma ms fcil. Esta aplicacin
puede presentar informacin grfica y puede incluir un sistema experto o inteligencia artificial.
Evolucin de los lenguajes de programacin: La evolucin de los programas de computacin
que descrita por generaciones:
Primera generacin (1GL): Es un lenguaje de mquina, es decir los datos e instrucciones son
entregados en el lenguaje que el procesador entiende, esto es una cadena de 0s o 1s.
Segunda generacin (2GL): Es assembler, el cual consiste en declaraciones muy bsicas que son
convertidas a 0s o 1s. Una tpica declaracin se ve: ADD 3,8
Tercera generacin (3GL): Es un lenguaje de alto nivel, tal como PL/I, Pascal, C, Java. Un
programa Java se ve as:
class Hola {
public static void main(String[] args) {
System.out.println("Hola");
}
}
Un compilador convierte las declaraciones, de un lenguaje especfico de programacin de alto
nivel a lenguaje de mquina ( en el caso de Java, la salida del compilador se llama bytecode el
cual es transformado a idioma mquina por una mquina virtual.
Cuarta generacin (4GL): Lenguaje diseado para ser cercano al lenguaje natural. Los lenguajes
para acceder a bases de datos, son a menudos clasificados as. Un lenguaje 4GL, se vera as:
OBTIENE TODOS LAS PERSONAS DONDE SUELDO ES MAYOR QUE 100.
Claro que lo ms probable es que esto est expresado en Ingls.
Quinta generacin (5GL): Estos lenguajes, usan una interfase grfica o visual para crear cdigo
fuente (declaraciones) que es compilado, con un compilador 3GL o 4 GL.
Mainframe : Trmino de la industria para un computador de gran capacidad, tpicamente
construido por una compaa grande. Histricamente asociado con computacin centralizada,
ms que computacin distribuida.
Plataforma: Se entiende que la plataforma es el sistema computacional base , dnde se ejecutan
las aplicaciones. La plataforma est compuesta por el Sistema Operativo y el hardware sobre el
cual este se ejecuta. Tambin se entiende por plataforma cualquier base tecnolgica, que sirve
para que otras tecnologas o procesos sean construidos.
88
89