Este capitulo tiene como objetivo analizar la metodología de preparación
de proyectos informáticos, de tal manera que el estudiante se apropie de la
metodología y aplique en el desarrollo de su proyecto de curso.
Los proyectos en área de informática
pueden ser de gran variedad, si embargo, podemos clasificarlos en forma
general en:
Proyectos de Desarrollo de
aplicaciones: elaboración y puesta en marcha de programas o sistemas
computacionales.
Proyectos de Equipamiento:
adquisición por primera vez de equipos, incluyendo tanto hardware como software
básico utilitario .
Proyectos de Mejoramiento,
ampliación o reposición: aumento de capacidad y calidad de servicios de
hardware y/o mejoramiento de software.
Seguidamente se desarrolla la metodología para formular proyectos en área
de informática, sin embargo es posible aplicar la metodología a cualquier otro
tipo de proyecto.
En esta metodología se usa una técnica
de evaluación de alternativas aplicable a cada una de las tipologías. La técnica
de evaluación está basada en tablas con ponderadores. Cada tipología tiene
sus tablas pertinentes.
Además, según cada tipología y
la etapa en curso se determinan distintos requisitos de información que se debe
presentar, esto queda reflejado en el Gráfico Nº 1:
TIPOLOGÍA DE PROYECTOS DE INFORMÁTICA
Gráfico Nº 1: Ciclo de vida y Tipología de Proyectos
Para
proyectos de equipamiento, adquisiciones, mejoramiento, ampliación o reposición, la metodología se aplica para pasar de la etapa de perfil a ejecución,
sin perjuicio de que en algunos casos se puede pasar
de perfil a prefactibilidad o factibilidad (y
posteriormente a ejecución) dependiendo de
la posibilidad de cuantificar los beneficios del proyecto, esta
posibilidad se indica con las flechas de líneas punteadas en el gráfico
anterior.
Adicionalmente, se debe considerar que la metodología considera tres resultados esperados de distinta naturaleza y que no aplican a todas las tipologías:
a)
Diseño Lógico.
b)
Evaluación de alternativas de
solución.
c)
Elaboración de Términos de
Referencia para la licitación de la etapa siguiente.
El
diseño lógico (a), se requiere como resultado
sólo para proyectos de desarrollo de aplicaciones, por lo tanto para las otras
tipologías sólo se requiere (b) y (c). Estas diferencias están representadas
en el Gráfico Nº 1, en el cual para cada tipología se indica con un óvalo la
etapa en la cual se aplica la metodología y en cada caso se señala el alcance
de la aplicación de la metodología, es decir, si se aplica (a), (b) y (c) o sólo
(b) y (c).
Es importante notar que para el caso de informática,
el significado de la etapa de diseño varía, con respecto a un
proyecto tradicional, ya que como producto de esta etapa se obtendrá el
Diseño Lógico, así como la evaluación de las distintas alternativas de
solución, evaluación que normalmente se presenta como resultado final de la
etapa de factibilidad.
Cabe mencionar que la tipología
para el caso de compra de paquetes de software[1],
corresponde a la tipología de Desarrollo para la etapa de Ejecución. Sin
embargo en este caso sólo se pedirá el diagrama de procesos o el diagrama de
flujo de datos (DFD), porque es importante considerar, si es que la organización
es capaz de adaptarse al software comprado, situación que se puede apreciar de
mejor manera, si es que existe un levantamiento de requerimientos.
Cada uno de estos requisitos
quedan explicados en forma más amplia en el resto de la metodología.
2.
ESTRUCTURA DE
PROYECTO
La información necesaria para cada etapa de acuerdo a cada tipología de proyectos se enumera a continuación en la Tabla Nº 1. La marca en cada celda indica los requisitos mínimos necesarios para esa tipología, la celda en blanco indica que ese requisito no es imprescindible para esa tipología, no obstante, en proyectos específicos se pueden exigir más requisitos que los que aquí se señalan. Los números entre paréntesis en la primera columna de requisitos de información, hacen referencia al punto dentro de este capítulo en que se describe dicho requisito.
|
|
Proyectos de desarrollo |
Equipamiento, adquisición,
mejoramiento, ampliación o reposición |
|
|
Etapa desde la
que postula |
Perfil |
Diseño |
Perfil |
|
Etapa a la que
postula |
Diseño |
Ejecución |
Ejecución |
|
REQUISITOS
DE INFORMACIÓN |
|
|
|
|
Resumen Ejecutivo (2.1) |
|
ü |
ü |
|
Plan,
o Política Informática de la Institución (2.2) |
ü |
ü |
ü |
|
Identificación
y Definición del Problema (2.3) |
ü |
ü |
ü |
|
Diagnóstico
de la situación actual (2.4) |
ü |
ü |
ü |
|
Optimización
de la situación actual (2.12) |
ü |
ü |
ü |
|
Descripción
general de requerimientos (2.5) |
ü |
|
ü |
|
Análisis
de requerimientos (diseño lógico) (2.13):
|
|
ü |
Ver Nota al pié[2] |
|
Programación
de actividades para etapa de diseño (2.6) |
ü |
|
|
|
Requerimiento
de personal estimadas del Proyecto en su etapa de Diseño (2.7) |
ü |
|
|
|
Análisis
de alternativas de solución (2.15) |
|
ü |
ü |
|
Evaluación
de costo – eficiencia |
|
ü |
ü |
|
Estimación
de beneficios esperados (2.8) |
ü |
ü |
ü |
|
Estimación
de costos de inversión, operación y mantención para la etapa de ejecución
(2.9) |
ü |
ü |
ü |
|
Cronograma
o carta Gantt (2.10) |
ü |
ü |
ü |
|
TDR
para la etapa de Diseño (2.11) |
ü |
|
|
|
TDR
para la etapa de Ejecución |
|
ü |
ü |
Tabla Nº 1: Requisitos de información
según tipologías y etapa del ciclo de vida
En el caso de proyectos de desarrollo, con esa información
a nivel de perfil, se podrá analizar la idea y trabajar en la propuesta de diseño,
obteniéndose la información relevante para la próxima etapa de inversión.
La información entregada para llevar a cabo la etapa de
diseño en el caso de proyectos de desarrollo es un elemento preliminar de
desarrollo. Ésta sirve de base para el análisis que se
efectuará en el levantamiento, por ello algunos requerimientos de
información para pasar de perfil a diseño
se repiten cuando se pasa de diseño a ejecución en este caso cada
requisito debe ser tratado en mayor profundidad.
A continuación se detallan cada uno de los requisitos de información mencionados en la Tabla Nº 1.
El resumen ejecutivo debe
contener:
§
Identificación del problema a
resolver
§
Objetivo del proyecto
§
Requerimientos
§
Breve justificación de la solución
escogida
§
Costos de inversión y operación
de la solución
La política informática debe contener estrategias
encaminadas a una buena gestión, tanto de la información como de la tecnología
que la soporta.
En particular, se debe definir, en los casos que
corresponda
-
El papel de
la información dentro de las distintas áreas de la institución. Dependiendo
del área, la información debiera cumplir con los siguientes atributos en
distintos grados de importancia:
§
Confidencialidad:
nivel de protección de la información que se necesita.
§
Integridad:
precisión y suficiencia de la información
§
Disponibilidad:
para cuáles usuarios estará la información disponible
§
Confiabilidad:
la información obtenida debe ser apropiada para la gestión y operación de la
institución.
§
Información
Externa: se debe poder acceder a requerimientos de información formulados por
otras instituciones.
-
Clasificación
de la información contenida en las bases de datos que posee la institución en
cuanto a su relevancia. La relevancia se define en función de lo que significa
la pérdida de información, para la misión de la institución, de manera que
se debe considerar estratégica aquella información cuya pérdida afecta a la
misión de la institución y no estratégica a aquella cuya pérdida no afecta a
la misión.
-
Procesos
claves dentro de la institución, ya que las mejoras a estos procesos es lo que
se debe desprender del plan informático
-
Estrategia
de capacitación
-
Estrategia
de software básico: sistemas operativos, sistemas de bases de datos, para
servidores y estaciones de trabajo.
-
Estrategia
de hardware: procesadores, capacidades de almacenamiento, capacidades de
crecimientos, estándares, etc.
-
Estrategia
de arquitectura: centralizada, distribuida o mixta. Sistemas propietarios o
sistemas abiertos.
-
Estrategia
de comunicaciones y redes: protocolos, arquitectura de redes, enlaces de
comunicaciones, etc
-
Estrategia
de desarrollo de software de aplicaciones: desarrollo local, desarrollo externo,
desarrollo mixto.
-
Estrategia
de recursos humanos: Unidad de Informática y sus alcances.
Se debe
determinar qué problema se intenta solucionar o qué objetivo se pretende
alcanzar mediante el proyecto (en términos generales, ya que el análisis en
detalle se abordará en la etapa de diagnóstico). Es importante aclarar este
punto, por cuanto constituirá el motivo por el que se origina el proyecto. Se
sugiere utilizar la metodología del árbol causa – efecto[3].
Esta etapa tiene como objetivo dar una descripción completa del área o
departamento involucrado en el estudio sirviendo como base para el análisis.
Este hito consta en la generación de un documento en el cual se describe
la situación actual de la unidad o departamento en estudio. El documento debe
contener los siguientes puntos insertos:
-
Organigrama de la unidad o departamento: un organigrama simple de cómo está
hoy la unidad que se debe estudiar
- Funciones
y responsabilidades de la unidad o departamento: descripción de funcionalidades permiten acotar el proyecto a
realizar.
- Objetivos
actuales: se debe exponer cuáles son los objetivos tanto de corto como
de largo plazo que se ha planteado la unidad o departamento. Para esto, se debe
realizar una enumeración y una breve descripción.
-
Interacción con su entorno: definir con un esquema simple la interrelación del
Departamento con su entorno. Mencionar las relaciones que guardan nexo con el
tema que se desea estudiar y que puede ser importante acotarlas.
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 Evaluación Técnica de Proyectos Informáticos”.
Además, es importante presentar en este caso un diagrama de la arquitectura de
la solución actual.
Se
deberá definir cuáles son los procesos que tienen relación con el tema en
estudio, dando un nombre simple al proceso y una breve descripción de cómo
opera.
Los
DFD que se deberán describir, son los indicados en el punto anterior. El
objetivo es visualizar en un esquema simple cómo fluye la información. Como
ejemplo de Diagrama de Flujo de Datos ver el Anexo
Diagrama de Flujo de Datos.
Estos diagramas pueden situarse en varios niveles, Para esta etapa, sólo se necesita una presentación a nivel intermedio (Siguiente al nivel de contexto, con los hijos más relevantes)
La idea es describir los
requerimientos principales a los cuales debe responder la solución. Estos
requerimientos deben ligar el rendimiento de la solución a implementar con
procesos estratégicos de la solución. Por ejemplo, para un servicio
determinado para el cual es muy importante el número de reportes para
beneficiarios y se ha determinado como decisión estratégica disminuir las
colas, el requerimiento debiera fijarse en el número 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 programación de la
planificación 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 información 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 sólo 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
institución que financia o que está postulando el estudio y que se estima se
dedicarán en jornada parcial o completa a ser contraparte del mismo o a
participar en su ejecución. Por otra parte, el personal externo
son las personas que asignará la empresa o institución que desarrolle el
estudio (empresa consultora u otra institución). También debe incluirse en
esta categoría el personal que se contrate específicamente para la ejecución
de éste o para hacer de contraparte, y cuyo contrato finalice junto con su término.
|
ÍTEM |
UNIDADES* |
PRECIO UNITARIO |
CANTIDAD |
VALOR TOTAL (M$) |
|
Profesionales1 Técnicos Secretarias Viáticos y pasajes Materiales
y equipos |
|
|
|
|
|
Total |
|
|
|
|
|
Gastos Generales |
|
|
|
|
* La unidad de medida del recurso humano es el número
de horas.
1\. - Los profesionales deben ser desagregados por
tipo y nivel.
Tabla Nº 2: Costos Directos de Personal
Además, se debe informar de los requerimientos
totales de personal del estudio de acuerdo al siguiente esquema:
|
PERSONAL |
PROPIO (Número de horas) |
EXTERNO (Número de horas) |
|
Profesionales1 Técnicos Secretarias,
Asistentes y otros Otros |
|
|
|
TOTAL |
|
|
1\. - Los profesionales deben ser desagregados por
tipo y nivel.
Tabla Nº 3: Costos Totales de
personal
Este cuadro debe completarse en base a la información
de estudios similares ya efectuados (si existen), en base a información de los
posibles proveedores (cotizaciones) y en base a las actividades del estudio que
se presenta.
Se deben describir los beneficios
en forma cualitativa. De ser posible identificar, medir y valorar los
beneficios.
La estimación de los costos de
inversión, operación y mantención debe estar fundamentada en la experiencia
anterior de la institución, si esta existe. La idea es presentar claramente
como se obtuvieron los valores correspondientes, explicando las cifras usadas y
describiendo el software, hardware y servicios profesionales que se usarían,
después de realizar el levantamiento de requerimientos.
La estimación debe afinarse después
de realizar el levantamiento de requerimientos, ya que se tendrá más claro que
funcionalidades se implementarán y cuales no, lo que permite predecir con mayor
información cuánto será el costo de inversión, operación y mantención
futuro.
Es importante notar que en informática
se entiende por costos de mantención los destinados a las adecuaciones
que requieren los sistemas para mantener su vigencia y utilidad.
Un
cronograma o carta Gantt, establece el orden de las actividades a abordar,
detallando cuales tareas pueden ser elaboradas en forma paralela y cuales tareas
son necesarias para realizar otras. Esta descripción se hace simbolizando cada
tarea por una barra, cuyo largo dependerá del tiempo que toma realizar cada
tarea.
A
continuación se muestra un ejemplo, elaborado en Microsoft Project 98®[4]:
Gráfico Nº4:
Carta Gantt
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 quién es el responsable de la tarea. Los diamantes indican hitos de
control (reuniones, entrega de resultados)
Los
términos de referencia deben incluir toda la información necesaria, para poder
licitar el diseño, así como la evaluación de las distintas alternativas de
solución (en el caso que el formulador estime que no hay capacidad técnica al
interior de la institución para evaluar el proyecto).
En
este sentido, se debe especificar claramente el producto final, el cual se
traduce en:
-
Análisis de procesos o
flujo de datos, en relación a la problemática detectada, lo cual se puede traducir en
una optimización de procesos.
-
Documentación asociada al Diseño lógico
-
Propuesta y evaluación de
las alternativas de solución
Estos
puntos quedarán más claros en los restantes puntos de la metodología.
En base a la información recopilada, vale decir,
antecedentes preliminares, presentación del problema y el diagnóstico, se
determinará si es posible mejorar la situación actual, ya sea con medidas
administrativas, de rediseño organizacional, o con inversiones marginales.
La optimización de la situación actual puede convertirse en una
importante fuente de ahorro de recursos, por ello se recomienda explorar esta
alternativa.
A modo de ejemplo, se puede optimizar la situación
actual por medio de alguna de las siguientes medidas:
a)
Medidas administrativas o de rediseño organizacional
- Rediseño de procesos al interior de la
institución
- Eliminar trámites
innecesarios
- Redistribuir físicamente al personal
de manera de optimizar los procesos
- Elaborar manuales de procedimientos administrativos
b)
Inversión marginal a la solución existente
-Rediseñar 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 información mantenida en bases de datos.
- Capacitar, tanto a usuarios, como a
especialistas del área informática de la institución.
Muchas veces se dispone de las herramientas de hardware, software o
comunicaciones, pero no se hace un adecuado uso de ellas.
- Redistribuir de forma más 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
- Segmentación de
redes mediante el balance y reasignación de la carga en la red de informática.
- Balances de carga en dispositivos como discos,
cpu, memoria.
- Otras inversiones
El objetivo es visualizar en un esquema simple la información requerida
y cómo fluye dicha información entre las distintas entidades y procesos. Estos
Diagramas pueden ir aumentando en complejidad, en la medida que cada flujo se
vaya describiendo en mayor profundidad.
Para aquellos proyectos de
desarrollo que incluyen la etapa de ejecución ( y por ende el diseño lógico)
un hito importante del análisis de requerimientos es la formulación del modelo
de datos.
En el caso de que se desarrollen
aplicaciones específicas:
En
el caso de sistemas de información geográficos, debe
pedirse como parte del análisis requerimientos, las capas y cruces mínimos
necesarios. En el caso de que el diagnóstico 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 vía convenio, versus
la alternativa de desarrollarlas nuevamente para la institución.
Para proyectos de desarrollo de páginas web y otros desarrollos de
Internet, intranet o Extranet, debe solicitarse un mapa de navegación que
de cuenta de la información que se requiere en el sitio Web. Además es
deseable un análisis de los procesos involucrados mediante DFD’s 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.
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 organización son satisfechos por la organización y
cuales no, para poder determinar la factibilidad de ser implementada con éxito.
Para proyectos de las tipologías: equipamiento, mejoramiento, ampliación
reposición, los requerimientos de información, se especifican
en el siguiente capitulo en tópico “Elementos a considerar en la
Evaluación Técnica de Proyectos Informáticos”
La presentación de alternativas de solución está
relacionada en forma directa con las capacidades técnicas para generar
alternativas y el nivel de problemas que se desean solucionar.
Una adecuada presentación de alternativas será el
paso inicial en una correcta presentación y preparación del proyecto de informática
o alternativa final de solución. Además,
será la base para el documento de especificaciones técnicas en el proceso de
formalización de compra o licitación.
La idea es mencionar las
restricciones de precio, mantención, operación y tecnología
que presenta cada alternativa.
b) Producto o servicio esperado en cada alternativa
Debe establecerse si se espera el
mismo servicio o producto por cada alternativa de solución y en qué consiste
en términos generales. Por ejemplo, se podría mencionar que el producto de la
alternativa seleccionada cumplirá con un requerimiento específico y que en
cambio no solucionará otro requerimiento menos importante.
[1] No utilitarios, es decir, distintos a los mencionados en el pié de página anterior.
[2]
En el caso de proyectos de mejoramiento, ampliación o reposición, si
involucran aumento de capacidad o calidad de software (no básico ni
utilitario), se sugiere exigir el diagrama de flujo de datos
[3] Si
se desea emplear esta metodología, se pueden consultar mayores detalle en
la “Guía metodológica general para la preparación y evaluación de
proyectos de inversión social”,
Sanín, Héctor, ILPES, 1995
[4]
®: Microsoft Corporation