Documentos de Académico
Documentos de Profesional
Documentos de Cultura
1637 PDF
1637 PDF
Metodologa de Proyectos
Informticos
1 Introduccin ....................................................................................... 4
2 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
3 Preparacin de Proyectos ................................................................. 17
3.1 RESUMEN EJECUTIVO ............................................................................................. 18
3.2 PLAN O POLTICA INFORMTICA DE LA INSTITUCIN............................................. 18
3.3 IDENTIFICACIN Y DEFINICIN DEL PROBLEMA .................................................... 19
3.4 DIAGNSTICO DE LA SITUACIN ACTUAL (SIN P ROYECTO)................................... 19
3.4.1 Descripcin de la Organizacin y/o entorno Afectado por el Proyecto...... 19
3.4.2 Descripcin de la Unidad o Departamento ................................................. 20
3.4.3 Presentacin de la solucin informtica actual........................................... 20
3.4.4 Descripcin de los procesos ......................................................................... 20
3.4.5 Diagrama de Flujo de Datos (DFD) presentando la situacin actual......... 20
3.5 DESCRIPCIN GENERAL DE REQUERIMIENTOS ........................................................ 21
3.6 PROGRAMACIN DE ACTIVIDADES PARA LA ETAPA DE DISEO .............................. 21
3.7 REQUERIMIENTOS DE PERSONAL PARA POSTULAR A LA ETAPA DE DISEO............. 21
3.8 ESTIMACIN DE BENEFICIOS .................................................................................. 22
3.9 ESTIMACIN DE COSTOS DE INVERSIN, OPERACIN Y MANTENCIN PARA LA
ETAPA DE EJECUCIN ......................................................................................................... 22
3.10 CRONOGRAMA Y CARTA GANTT ........................................................................... 22
3.11 TRMINOS DE REFERENCIA PARA CONTRATAR ETAPA DE DISEO .......................... 23
3.12 OPTIMIZACIN DE LA SITUACIN ACTUAL............................................................. 24
3.12.1 Medidas administrativas o de rediseo organizacional ................................. 24
3.12.2 Inversin marginal a la solucin existente................................................... 24
3.13 ANLISIS DE REQUERIMIENTOS (DISEO LGICO) ................................................. 25
3.13.1 Diagrama de flujo de datos (lgico)............................................................. 25
3.13.2 Modelo de datos............................................................................................ 25
3.13.3 Otra documentacin ..................................................................................... 25
3.14 ALTERNATIVAS DE SOLUCIN ............................................................................... 26
3.14.1 Restricciones asociadas a cada alternativa................................................. 26
3.14.2 Producto o servicio esperado en cada alternativa....................................... 26
4 Evaluacin Costo - Eficiencia .......................................................... 27
4.1 EVALUACIN Y SELECCIN DE ALTERNATIVAS..................................................... 27
4.2 ATRIBUTOS RELEVANTES ...................................................................................... 28
4.3 TCNICA DE EVALUACIN DE ALTERNATIVAS ...................................................... 29
4.3.1 Evaluacin de los atributos .......................................................................... 30
2
4.3.2 Detalle de la Inversin y clculo del indicador costo eficiencia.................. 36
5 Trminos de referencia para la etapa de ejecucin........................... 38
6 Sugerencias para el proceso de licitacin.......................................... 38
7 Bibliografa ....................................................................................... 40
8 Anexos ...................................................... Error!Marcador no definido.
ANEXO 1: TCNICA PARA PRIORIZACIN Y ASIGNACIN DE PONDERADORES .................... 41
ANEXO 2: ELEMENTOS A CONSIDERAR EN LA EVALUACIN TCNICA DE PROYECTOS
INFORMTICOS .................................................................................................................. 44
ANEXO 3: BENEFICIOS Y COSTOS ....................................................................................... 48
ANEXO 4: MODELAMIENTO DE DATOS............................................................................... 52
ANEXO 5: DIAGRAMA DE FLUJO DE DATOS (DFD)............................................................ 71
ANEXO 6 CALIDAD FUNCIONAL ........................................................................................ 76
ANEXO 7: ETAPAS DE UN PROYECTO DE DESARROLLO EN INFORMTICA .......................... 77
ANEXO 8: EJEMPLOS DE MEDIDAS DE EFECTIVIDAD. ......................................................... 85
ANEXO 9 ESFUERZO REQUERIDO PARA CADA FASE ........................................................... 86
ANEXO 10 DEFINICIONES LEGALES .................................................................................... 88
ANEXO 11 GLOSARIO ........................................................................................................ 90
3
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.
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.
1
Estas deficiencias se vieron confirmadas con el problema informtico del ao 2000.
4
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.
5
2 Aspectos Generales
2.1 Teora en la que se basa la metodologa
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.
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.
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.
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.
Estos dos elementos evaluados en forma conjunta configuran el anlisis costo - eficiencia;
ste, en definitiva, establece el costo por unidad de cumplimiento del objetivo.
7
2.1.3 Criterios de aprobacin o rechazo de proyectos informticos
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.
Beneficios y costos
Modelamiento de Datos
8
Calidad funcional
Definciones legales
Glosario
Diseo Lgico. Los resultados tpicos esperados son las respuestas a las preguntas: qu
sistemas administrativos se van a apoyar, qu sistemas computacionales se desarrollarn,
qu flujos de informacin son relevantes, qu procesamiento se requiere, qu tipo de datos
se manejarn.
9
2.4 Los proyectos en el SNI
Preinversin
Inversin
Operacin
10
Los resultados esperados de cada etapa de preinversin, pasando desde idea a factibilidad,
se especifican a continuacin:
Estudio de prefactibilidad
Estudio de factibilidad
Grfico N 2: Etapas de Preinversin
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.
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.
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.
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.
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.
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.
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.
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.
2
Sistemas operativos, procesadores de texto, planillas de clculo, navegadores y antivirus.
13
Proyectos de Mejoramiento, ampliacin o reposicin: aumento de capacidad y
calidad de servicios de hardware y/o mejoramiento de software.
3
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 Alcance de la Metodologa en cada caso
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.
IDEA
Metodologa
(b) y (c) Metodologa
PERFIL (b) y (c)
PREFACTIBILIDAD
FACTIBILIDAD
Metodologa
DISEO (a),(b) y (c)
EJECUCIN
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
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.
a) Diseo Lgico.
b) Evaluacin de alternativas de solucin.
c) Elaboracin de Trminos de Referencia para la licitacin de la etapa siguiente.
El diseo lgico (a) , se requiere como resultado slo para proyectos de desarrollo de
aplicaciones, por lo tanto para las otras tipologas slo se requiere (b) y (c). Estas
diferencias estn representadas en el Grfico N 3, en el cual para cada tipologa se indica
con un valo la etapa en la cual se aplica la metodologa y en cada caso se seala el alcance
de la aplicacin de la metodologa, es decir, si se aplica (a), (b) y (c) o slo (b) y (c).
El horizonte de evaluacin, debe considerar como mximo cuatro aos, debido a los
cambios tecnolgicos que en el rea informtica ocurren con gran velocidad.
5
No utilitarios, es decir, distintos a los mencionados en el pi de pgina anterior.
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
6
En el caso de proyectos de mejoramiento, ampliacin o reposicin, si involucran aumento de capacidad o
calidad de software (no bsico ni utilitario), se sugiere exigir el diagrama de flujo de datos
17
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
Para mayores detalles sobre el Diagrama de Flujo de datos consultar el Anexo 5, para el
modelo conceptual de datos ver el Anexo 4.
La poltica informtica debe contener estrategias encaminadas a una buena gestin, tanto de la
informacin como de la tecnologa que la soporta.
18
- Clasificacin de la informacin contenida en las bases de datos que posee la institucin
en cuanto a su relevancia. La relevancia se define en funcin de lo que significa la
prdida de informacin, para la misin de la institucin, de manera que se debe
considerar estratgica aquella informacin cuya prdida afecta a la misin de la
institucin y no estratgica a aquella cuya prdida no afecta a la misin.
- 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
7
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 Descripcin de la Unidad o Departamento
- Objetivos actuales: se debe exponer cules son los objetivos tanto de corto como de
largo plazo que se ha planteado la unidad o departamento. Para esto, se debe realizar
una enumeracin y una breve descripcin.
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:
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 Descripcin general de requerimientos
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.
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.
Se debe presentar un presupuesto detallado por fases o total del estudio. La informacin
pertinente debe desagregarse en, al menos, los tems que se muestran en el siguiente cuadro,
identificando la cantidad y el precio unitario de cada uno. Se deben valorar slo los tems que
signifiquen desembolso adicional para el servicio; en consecuencia, no debe incluir personal
propio. Se entiende por personal propio los funcionarios de la institucin que financia o que
est postulando el estudio y que se estima se dedicarn en jornada parcial o completa a ser
contraparte del mismo o a participar en su ejecucin. Por otra parte, el personal externo son las
personas que asignar la empresa o institucin que desarrolle el estudio (empresa consultora u
otra institucin). Tambin debe incluirse en esta categora el personal que se contrate
especficamente para la ejecucin de ste o para hacer de contraparte, y cuyo contrato finalice
junto con su trmino.
21
Adems, se debe informar de los requerimientos totales de personal del estudio de acuerdo al
siguiente esquema:
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.
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 :
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)
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).
8
: Microsoft Corporation
23
En este sentido, se debe especificar claramente el producto final, el cual se traduce
en:
- Anlisis de procesos o flujo de datos, en relacin a la problemtica detectada, lo
cual se puede traducir en una optimizacin de procesos.
- Documentacin asociada al Diseo lgico
- Propuesta y evaluacin de las alternativas de solucin
A modo de ejemplo, se puede optimizar la situacin actual por medio de alguna de las
siguientes medidas:
-Redisear y/o normalizar las bases de datos, eliminando duplicidades. Aparte de proporcionar
una mayor eficiencia, esta medida permitir una mayor seguridad, menor duplicidad y por lo
tanto, una mejor eficiencia de la informacin mantenida en bases de datos.
- Redistribuir de forma ms racional los recursos computacionales entre los distintos usuarios.
En este caso, se recomienda considerar aspectos tales como: nivel de uso y capacidades de los
recursos.
24
- Balances de carga en dispositivos como discos, cpu, memoria.
- Otras inversiones
Para aquellos proyectos de desarrollo que incluyen la etapa de ejecucin ( y por ende el
diseo lgico) un hito importante del anlisis de requerimientos es la formulacin del
modelo de datos. Para efectos de presentacin de antecedentes a MIDEPLAN est descrito
cmo hacer un modelamiento en el Anexo 4 Modelamiento de Datos.
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.
25
Aquellos proyectos, que involucren la compra de software de clase mundial, o paquetes
desarrollados, se debe presentar un informe que especifique que requerimientos de la
organizacin son satisfechos por la organizacin y cuales no, para poder determinar la
factibilidad de ser implementada con xito.
Una adecuada presentacin de alternativas ser el paso inicial en una correcta presentacin y
preparacin del proyecto de informtica o alternativa final de solucin. Adems, ser la base
para el documento de especificaciones tcnicas en el proceso de formalizacin de compra o
licitacin.
26
4 Evaluacin Costo - Eficiencia
Los fundamentos para la adopcin de este criterio fueron presentados en la seccin 2.12.
Antes de iniciar la presentacin de la metodologa de evaluacin y seleccin de alternativas
bajo este criterio, cabe definir la diferencia entre efectividad y eficiencia.
9
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.
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.
Atributos imprescindibles
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)
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 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 Evaluacin de los atributos
Cada uno de estos factores ser calificado con un puntaje de 1 a 100, de acuerdo a los
siguientes procedimientos:
A) Efectividad
30
Funcionalidades Altern. Altern. ... Altern.
del Sistema 1 2 N
MUY DESEABLES
100% 50% 100%
(%Cumplimiento)
Informacin en Lnea 1 1 1
Interfaces Grficas 1 0 1
DESEABLES
33% 100% 33%
(%Cumplimiento)
Emisin de cartas 0 1 0
Control de cambios 1 1 1
Otros atributos menores 0 1 0
Total 79.9 65 79.9
(EF1) (EF2) (EFN)
Tabla 5: Matriz de Efectividad
Para otros ejemplo de atributos que miden efectividad en distintas dimensiones, ver Anexo 8
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:
31
Disponibilidad: las alternativas de solucin deben proveer:
1. Acceso a la informacin por parte de todos los usuarios autorizados, en el
momento en que lo requieran
2. Tiempos de respuesta acordes con las necesidades de los procesos
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:
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.
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
33
D) Ahorro de costos operacionales
AC j
CO j
Donde:
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.
34
Ejemplo:
En este caso los atributos son 4, por lo que se divide la suma de cada columna por ese
nmero, para obtener el total.
Evaluacin de alternativas
Una vez evaluados todos estos factores, se deber generar la siguiente matriz:
PAji * Ponderadorj
Pi =
j 100
35
Donde:
Pi : Puntaje Alternativa i
PAji : Puntaje del atributo j de la alternativa i
Ponderadorj : Ponderador del atributo j (corresponde a los x%, y%, z% y
w%)
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.
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:
Cj
RC j =
P
j
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;
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
r (1 + r )
n
FR =
(1 + r)n 1
n
VACj = Ij + (COtj + CMtj ) / (1+r)t
t=1
Con:
r: tasa de descuento
n: vida til del sistema
COtj: costo de operacin de la alternativa j en el perodo t
CMt: costo de mantencin de la alternativa j en el perodo t
Ij: costo de inversin de la alternativa j
De forma que
Cj = CAEj = VACj * FR
Para los sistemas se considera generalmente una vida til de cuatro aos 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 costo-
eficiencia y cuyo precio est dentro de los rangos presupuestados.
En el caso de que las alternativas tuvieran la misma razn costo-eficiencia, hay que escoger
la que cumpla al menos con restricciones.
Ejemplo:
37
En este caso, el resultado del anlisis de alternativas es el siguiente:
Capacitacin
Mantenimiento
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.
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.
- Pgina http://www.ji.si.ehu.es/users/tap/ADSI/19992000/Tema1/
40
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:
41
... que el tem que est en la columna? Total Orden
fila
Item 2
0 1 0 1 0 0 2 6
Item 3
1 0 0 0 1 1 3 3
Item 4
1 1 1 1 1 1 6 1
Item 5
0 0 1 0 0 0 1 7
Item 6
0 1 0 0 1 0 2 5
Item 7
0 1 0 0 1 1 3 4
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.
42
Matriz de Evaluacin de la plataforma tecnolgica
43
Anexo 2: Elementos a considerar en la Evaluacin Tcnica de Proyectos
Informticos
Los siguientes son los antecedentes a entregar para la evaluacin tcnica de un proyecto
informtico:
44
Arquitectura de Hardware y Software Bsico
b) Sistemas operativos
Fabricante
Versin (nmero y fecha liberacin)
Tipo de licenciamiento
e) Estaciones de trabajo
CPU
Unidades de almacenamiento (tipo, capacidad)
Memoria RAM
Unidades de respaldo
45
Perifricos
f) Impresoras
Tipo de impresoras (lser, inyeccin de tinta, etc.)
Breve descripcin caractersticas tcnicas (calidad de impresin, velocidad, etc.)
Costos de Operacin
Capacitacin Tcnica
a) Personal involucrado
b) Costo de capacitacin (inicial y mantencin)
46
Indicar eventual necesidad de contratacin de personal para la operacin y mantencin de
la solucin, describiendo perfil y costos.
47
Anexo 3: Beneficios y costos
Los costos de los proyectos de informtica son relativamente simples de cuantificar, no as
los beneficios, que se presentan como ahorro de costos con respecto a la situacin base,
siendo particularmente compleja la estimacin de las horas - hombre liberadas.
Por otra parte, este tipos de proyectos tienen costos y beneficios intangibles, los cules se
debern describir en forma cualitativa.
Beneficios privados
Por no tener que contratar personal adicional con respecto a la situacin optimizada.
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.
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.
48
Mejora del actual sistema
Con el nuevo sistema, se pretende mejorar las caractersticas bsicas del sistema actual.
Por ejemplo:
Automatizacin
Ordenamiento de archivos.
Generacin automtica de cheques.
Bsqueda de informacin.
El segundo tipo se produce con mayor frecuencia en proyectos que involucran un aumento
de la capacidad de procesamiento y un mejoramiento del diseo del sistema.
El tercer tipo de aumento de la productividad est relacionado con proyectos que formulan
el equipamiento de un sistema computacional por primera vez en alguna rea determinada.
Venta de informacin
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
Ahorro en costos de operacin
Costos privados
Costos de operacin
50
Beneficios y costos sociales
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.
Se debe entregar un listado que incluya aquellos costos y beneficios que no se pudieron
valorar. Tpicamente, se tratan de los siguientes:
Costos
Beneficios
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
Anexo 4: Modelamiento de datos
I DEFINICIN
Conjunto de entidades y relaciones que representan los datos de una organizacin o sistema
bajo anlisis.
2.1 ESQUEMA
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.
Est formado por entidades y las relaciones entre ellas. A continuacin se describen
cada uno de estos elementos.
2.3.1 ENTIDADES
53
Corresponde al objeto que se quiere representar. Son elementos, reales o abstractos,
acerca de las cuales se requiere registrar informacin.
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.
2.3.2 RELACIONES
Una relacin es una asociacin entre, exactamente, dos entidades. Por ejemplo, una
PERSONA (entidad) trabaja para un DEPARTAMENTO (entidad).
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.
Los nombres de las entidades debern ser escritos en modo singular y con letras
maysculas, por ejemplo "CLIENTE", y no usar "CLIENTES" o "cliente".
Muchas veces ser necesario utilizar un calificador u otra palabra agregada al
sustantivo para aclarar el alcance que tiene el nombre de la clase de datos identificada.
Por ejemplo, usar "CONTRATO DE LEASING" en vez de slo "CONTRATO". Por
supuesto, esto depender del contexto global y de las caractersticas particulares del
sistema bajo estudio.
55
Describiendo entidades y relaciones ya existentes.
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.
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.
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.
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
Las relaciones tienen una naturaleza que describe el tipo de asociacin, tales como:
- Pertenencia
- Jerarqua
- Temporal
- Complementariedad
- Parentesco
- Autoridad
Un "I" representa que una ocurrencia de una entidad debe estar asociada con cada
ocurrencia de la otra entidad, mientras que un "0" representa que una ocurrencia de
una entidad puede no estar asociada con cada ocurrencia de la otra entidad.
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
Figura 5: Relacin Opcional
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
Figura 8: Relacin de Uno a Muchos
- M:N (muchos a muchos): una ocurrencia de la primera entidad est relacionada con
muchas ocurrencias de la otra entidad, y viceversa.
59
Figura 10: Relacin Recursiva
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
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
Error!Marcador no definido.Ocurrencia Entidad Valores Atributos
El rango de valores posibles que puede tomar un atributo se denomina dominio del 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.
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.
- <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.
- <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.
62
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.
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:
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.
Reglas de Existencia: establece las condiciones bajo las cuales la relacin es creada y
borrada.
g . Identificador de Entidades
64
Ejemplo:
Lo que se puede hacer es dejar una sola entidad, la que servir para ambos propsitos.
Se podr reconocer su naturaleza por:
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:
65
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.
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:
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.
66
Enfoque:
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
EMPLEADO (nmero empleado, nombre empleado, nmero departamento,
nombre departamento, cargo empleado, sexo empleado, cdigo carga empleado,
nombre carga empleado, edad carga empleado).
Poner el modelo en 1FN significa sacar de las entidades los atributos repetitivos (o
grupos repetitivos) como entidades separadas. Por cada atributo que no es
identificador, pregunte: Hay ms de un valor para este atributo en cualquier
ocurrencia de la entidad ? Identifique todos los atributos en la lista para los cuales
la respuesta es "si". Busque el conjunto de tales atributos que siempre tienen el
mismo nmero de valores dentro de cualquier ocurrencia individual de la 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:
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:
68
crea forma la base de una nueva entidad, en la que debe copiarse el identificador
parcial relevante de la entidad original.
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".
Para tener el modelo en 3FN deben resolverse las transitividades en los atributos
(datos) repetidos, sacndolos como entidades independientes.
Los valores de este atributo dependen del valor de otro atributo cualquiera
distinto del identificador primario?
Si la respuesta es "si", el atributo dependiente debe ser trasladado a otra entidad, con
el atributo determinante como identificador primario. Separe los atributos afectados
y llvelos a una nueva entidad, la que deber tener otro nombre, una por cada grupo
de atributos con el mismo nuevo identificador primario. Las entidades resultantes
estarn en tercera forma normal. En el ejemplo, quedara:
69
- Esto debera hacerse slo si los requerimientos lo solicitan. Por ejemplo, si se
quiere saber todos los empleados que pertenecen a un determinado departamento.
- 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
Anexo 5: Diagrama de Flujo de Datos (DFD)
Para desarrollar un diagrama de flujo de datos hay que seguir los siguientes pasos:
- 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
71
Representacin grfica de los procesos que componen el sistema y las interfaces
entre ellos
Componentes
4) Almacn(rectngulo abierto)
- El medio fsico no es especificado; incluye medios
Almacn
manuales de almacenamiento
- No incluye almacenamientos temporales
72
Ejemplo general de diagrama DFD de contexto
Entidad Entrada A
externa 1
Nombre del
Salida F
sistema
Entidad
externa 3
Entidad
externa 2 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 Entrada A
externa 1
Proceso Flujo de datos C Proceso
general general
A C Salida F
Registro A Registro E
Proceso Proceso
general Flujo de datos D general
B 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.
Instituciones
pblicas Proyectos
Empresas
reguladas
Analizar
Resultado tcnico-econmico
proyectos
Hacienda
Ficha EBI Resultado tcnico-econmico
Solicitud de regularizacin de Proyectos
Proyectos
Instituciones
pblicas
Empresas Proyectos con
reguladas Ingreso Timbre Proyectos con fecha SNI
Ingreso al
oficina de
SNI
partes
Nmero de
Ficha EBI Fecha SNI
oficio o Memo Ministerio
de
Memos
oficios BIP Proyectos Hacienda
Proyectos para
Solicitud de Ficha EBI
anlisis
regularizacin
de proyectos
mal ingresados
Resultado
anlisis tcnico Anlisis
econmico Tcnico-econmico
Resultado
anlisis tcnico
econmico
74
Ejemplo: Diagrama Hijo del proceso de Anlisis Tcnico - econmico en el
SNI
Ficha EBI
BIP Anlisis Tcnico-Econmico
RATE
Instiucin que
presenta el
proyecto
Proyectos BIP
Resultado
Instituciones anlisis tcnico
pblicas econmico
Empresas (MEMO firmado)
reguladas
Ministerio
de
Hacienda
75
Anexo 6 Calidad Funcional
En este tem se pretende evaluar las prestaciones que ofrecen las distintas alternativas de
Diseo Fsico, para implementar de la solucin. Deber considerarse la existencia de
controles automatizados, redundancia de datos mnima y justificada, cobertura sobre los
procesos, reglas para eliminacin y modificacin de datos y, en general, todas aquellas
caractersticas que hagan que la solucin sea eficiente y robusta.
76
Anexo 7: Etapas de un Proyecto de Desarrollo en Informtica.
Sin prototipos
En cascada (Waterfall)
Con prototipos
Desechable
Parte del sistema definitivo
Incremental
Evolutivo
Ciclo de vida en espiral
Definir Requisitos
Sistema Desarrollo de SI
Definir Requisitos
software
Diseo Codificar
preliminar mdulos e
integrarlos
Diseo
detallado
Integrar el
Codificar & debug software en
el sistema
Test y
Pre-operacin
Operacin y
Mantenimiento
77
Problemas del Ciclo de Vida en Cascada
El prototipo es un modelo del sistema propuesto, que se construye para ilustrar la viabilidad
del nuevo sistema, esto porque los prototipos constituyen un mejor medio de comunicacin
que los modelos en papel.
Investigacin
preliminar
Definir requisitos
Breve anlisis
y especificacin
Diseo
y realizacin
Evaluacin
OK
OK
Modificacin
Diseo
...
78
Caractersticas del Ciclo de Vida con prototipos
Alto grado de participacin del usuario el cual evala los prototipos, propone mejoras y detalla
requisitos.
Alto grado de participacin del analista de sistemas, ya que en muchos casos los usuarios no
pueden indicar los requisitos sin tener experiencia con el sistema. El prototipo da mayor
conocimiento al usuario y analistas ayudando a que el usuario aprenda a utilizar el sistema. El
prototipo se modifica hasta que los requisitos del usuario queden claros.
Investigacin
preliminar
Definir requisitos
Breve anlisis
y especificacin
Diseo
y realizacin
Evalua-
cin
OK
OK Modificacin
Diseo
...
79
Ciclo de vida con prototipos desechables
El prototipo no se utilizar para construir el sistema final. Se programan sin fijarse en usar
buenas practicas de programacin y se hacen muy rpido, usualmente se hacen en Perl,
awk, csh, etc.). Lo importante es entender que en este caso no se debe tomar el prototipo
como un producto final, y menos programar encima de este.
Experi
menta
Validacin
80
PLANIFICACIN ANLISIS DE RIESGO
Y ANLISIS DE
REQUISITOS 7
7
6
7
6
1 2
6
3 3 3 3
0
5 4
8 9 Hacia el sistema final
5 8
5
EVALUACIN
DEL INGENIERA
CLIENTE
81
Evolucin de los Sistemas de Informacin
t0 se toma la decisin
t1 se acaba el anlisis de
requerimientos
t2 primer elemento ejecutable del
sistema
t2-t4 desarrollo del sistema
t4 versin definitiva en uso
t5 ampliacin de funcionalidad del
sistema
f
u
n
c
i Impropiedad
o
n
a
l
i
d D
a f
ici
t
Adaptabilidad
Retraso (la pendiente de la recta)
Longevidad
t t t t t t
0 1 2 3 4 5
tiempo
La lnea ms clara, representa el desarrollo ideal de un sistema de informacin, en el cual al
tomarse la decisin de elaborar un SI, ya se sabra claramente parte de las funcionalidades
necesarias del mismo, es as que al terminar el anlisis de requerimientos en t1, se habra
avanzado en la comprensin de las funcionalidades requeridas. En un proyecto real, lo cual
82
se aprecia en la lnea negrita, se aprecia un retraso debido a que cuando se obtiene el
primer elemento ejecutable del sistema, todava no se comprende en su totalidad las
funcionalidades requeridas o simplemente no se han podido desarrollar en el tiempo
deseado. Es as como existe un dficit entre lo que se lograra en condiciones ideales y lo
que realmente se logra en cuanto a funcionalidad. La adaptabilidad, se refiere a la
capacidad de agregar funcionalidades en el tiempo. La impropiedad se refiere a que al
agregar funcionalidades a un sistema ya terminado, estas son ms difciles de obtener que
en un sistema recin comenzado. No se logran todas las propiedades deseadas.
A continuacin se muestra la evolucin de los SI, segn los distintos ciclos de vida ya
mencionados. Es importante notar, que dependiendo del ciclo de vida elegido el proyecto se
acercar o alejar del ideal anteriormente expuesto.
Evolucin de SI en cascada
f
u
n
c
i
o
n
a
l
i
d
a
d
t0 t1 t2 t3 t4 t5
tiempo
83
Evolucin SI con prototipos desechables
f
u
n
c
i
o
n
a
l
i
d
a
d
t0 t1 t2 t3 t4 t5
tiempo
Evolucin SI con prototipos no desechables
f
u
n
c
i evolutivo incremental
o anlisis de requisitos
en cada fase
n
a
Incremental con
1 anlisis de requisitos
t0 t1 t2 t3 t4 t5
tiempo
84
Anexo 8: Ejemplos de medidas de efectividad.
Adems de las sealadas en la Tabla 5 del punto 4.3 (Informacin en lnea, Interfaces
grficas, Emisin de cartas, control de cambios), se pueden considerar las medidas, que a
continuacin se exponen para comparar alternativas, la idea en esta etapa es considerar la
solucin como un todo considerando hardware, software , comunicaciones:
85
Anexo 9 Esfuerzo requerido para cada fase
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%
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:
87
Anexo 10 Definiciones legales
Normas legales que protegen el programa: Ley N 17.336 de 2 de Octubre de 1970, sus
modificaciones y su reglamento (Decreto de Eduacin N 1.122 del 17 de Mayo de 1971).
88
Adaptacin de un programa: Es licito cuando es efectuada por el tenedor del programa o
autorizada por el legtimo dueo del mismo. Esta adaptacin debe ser esencial para el uso
del programa y no es destinado a un uso diverso. Estas adaptaciones no pueden ser
transferidas bajo ningn ttulo, sin que medie autorizacin previa del derecho de autor
respectivo.
Copia de un programa: La copia es licita cuando es efectuada por el tenedor del programa
o autorizada por el legtimo dueo del mismo y es esencial para su uso en un computador
determinado o para fines de archivo de respaldo. Estas copias no pueden ser transferidas
bajo ningn ttulo, salvo que lo sea con el programa computacional que le sirvi de matriz.
89
Anexo 11 Glosario
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.
90
Datawarehouse: Es un repositorio central para toda la informacin importante que las
diversas reas de negocio de una organizacin acumula. El datawarehouse obtiene
informacin de diversas fuentes, para anlisis y accesos tiles a la informacin, pero
generalmente no se obtiene esta informacin del usuario final el cual necesita una base de
datos local especfica sobre algn tema.
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.
91
Programa: En computacin un programa es un conjunto de isntrucciones ordenadas,
expresadas en algn lenguaje de programacin.
Web Server: Un servidor Web es un software, que sirve peticiones de pginas HTML o
archivos.
92