Metodologia de Proyectos

Anexo - NTP7
Guia Metodologica para

administracion Proyectos TI
218 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones
Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 219
1. Introduccin.
Con el fin de establecer un lenguaje comn a nivel institucional; as como un estndar
en la ejecucin y documentacin de proyectos de tecnologas de informacin y
comunicacin, se define en este documento la Gua Metodolgica que se debe aplicar
en la Contralora General de la Repblica (CGR).
La presente Gua Metodolgica, se elabora no slo para efectos de estandarizacin,
sino tambin en cumplimiento con lo establecido en el Manual de Normas Tcnicas
para la Gestin y el Control de las Tecnologas de Informacin, emitidos por la CGR.
Esta metodologa para la administracin de proyectos de TIC tiene como objetivo,
esbozar una serie de pasos comunes a seguir, con el fin de mejorar las probabilidades
de xito de los proyectos, teniendo siempre presente que en ltima instancia el
xito de los mismos est en funcin del nivel de motivacin y mstica de que estn
impregnados en los integrantes del equipo de trabajo, de la disponibilidad de recursos
y del nivel de apoyo que brinde oportunamente la alta Gerencia.
Un proyecto en Tecnologas de Informacin y Comunicaciones (TIC) es todo aquel
que introduzca en la organizacin elementos tecnolgicos que soporten y hagan ms
eficiente la ejecucin o el desarrollo de un proceso. Se consideran como proyectos de
este tipo, el desarrollo de un sistema automatizado, o la implantacin de una solucin
tecnolgica de hardware o de software, lo cual hace que el mismo proyecto sea muy
distinto y variado en cuanto a sus actividades se refiere. Todo proyecto en TIC deber
estar siempre orientado al logro de los objetivos institucionales y obtiene su sentido
en la medida que aporta un valor agregado a la organizacin, respondiendo a sus
necesidades de manejo de la informacin y del conocimiento.
Para los efectos de esta metodologa, se define un proyecto como:

Una secuencia de tareas con un principio y un final, limitadas en el tiempo por
los recursos y los resultados deseados.
Esto significa que un proyecto tiene un resultado deseado especfico, una fecha lmite
o fecha objetivo en la que el proyecto debe estar realizado y un presupuesto que limita
la cantidad de personal, suministros y dinero que pueden utilizarse para realizar el
proyecto.
Si el equipo a cargo del proyecto esta consciente de que su trabajo es importante y
necesario para la organizacin, estar en una mejor posicin para enfrentar y vencer,
la serie de obstculos que todo proyecto sin excepcin enfrenta.
En el desarrollo de todo proyecto existen diferentes actores cuyos roles sern
debidamente establecidos dentro de la presente gua metodolgica. En el anexo
1 se presentan cada uno de los diferentes roles involucrados, que sern partcipes
de las actividades planteadas en cada una de las etapas del proyecto. Como todo
instrumento metodolgico est sujeto a mejoras en el tiempo, aspecto que se explica
en el anexo 2.
Sin importar los objetivos que los proyectos busquen, se puede ver que todos presentan
etapas bsicas, con algunas pequeas variantes. Cada una de stas ser detallada en
la presente gua.
2. Objetivo
Definir la gua metodolgica para el desarrollo de proyectos en Tecnologas de
Informacin y Comunicaciones, que ser aplicada en la Contralora General de la
Repblica.
3. Objetivos especficos
a. Definir un marco de referencia comn para todos los proyectos de TIC,
uniformando tcnicas y mtodos de trabajo.
b. Establecer las etapas y actividades a realizar, as como los entregables en
cada una de ellas.
c. Definir para los proyectos que contemplen el desarrollo de un sistema
de informacin automatizado, las fases a cumplir con sus diferentes
entregables.
d. Sealar la organizacin, las funciones y las responsabilidades de los
involucrados en el proceso de desarrollo de un proyecto de TIC.
4. Etapas de los Proyectos de TIC

A continuacin se presentan las etapas de un proyecto, con un breve detalle de los
objetivos para cada una de ellas, en funcin de lograr los resultados deseados a tiempo
y dentro del presupuesto esperado. (Ver figura # 1)
4.1. Etapa 0. Anteproyecto.
La organizacin identifica una serie de necesidades que pueden ser atendidas
mediante el desarrollo de un proyecto.
Se determinan las expectativas generales de los interesados, as como el
efecto y resultados esperados.
Identificar los actores involucrados en el proyecto a desarrollar.
Confeccionar la ficha de anteproyecto.
Someter el anteproyecto a la evaluacin del Comit Gerencial de Tecnologas
de Informacin y Comunicacin (CGTIC), el cual valorar su viabilidad y
prioridad dentro de la organizacin.
4.2. Etapa 1. Iniciacin.

Corroborar las expectativas generales de los usuarios, gerentes y de
cualquier otro interesado, para establecer los resultados esperados y el
alcance del proyecto.
Definir la organizacin del proyecto y seleccionar el equipo de trabajo.
Realizar un informe de diagnstico que permita establecer las diferentes
opciones de solucin a ser evaluadas.
Elegir la alternativa de solucin a ser desarrollada.
4.3. Etapa 2. Planeacin.
Revisar los objetivos y alcances del proyecto en funcin de un adecuado
balance entre resultado, tiempo y recursos.
Listar las tareas y actividades que se deben ejecutar para lograr los alcances
definidos del proyecto.
Secuenciar u ordenar las actividades en funcin de las dependencias
tcnicas entre ellas y de los recursos disponibles.
Elaborar el calendario de requerimientos de recursos en el tiempo, para
lograr los alcances deseados.
Obtener la aprobacin para el plan de trabajo.
Mantener los planes de trabajo balanceados durante todo el desarrollo del
proyecto, en funcin de las variaciones que se produzcan en los alcances,
tiempos y recursos.
4.4. Etapa 3. Ejecucin.
Asignar, controlar, supervisar y liderar el desarrollo de las actividades
planeadas.
Efectuar reuniones de trabajo entre los integrantes del equipo de trabajo y
el lder del proyecto.
Comunicacin constante entre los diferentes participantes en el proyecto

y hacia la Unidad Ejecutora; comunicacin que debe ser promovida por el
lder del proyecto.
Gestionar la solucin de los problemas que puedan surgir durante la
ejecucin y asegurar la consecucin de recursos (dinero, gente, equipo),
para llevar a cabo el proyecto.
Si el proyecto tiene como objetivo el desarrollo de un sistema automatizado,
deber desarrollar las fases indicadas en el anexo 4.
4.5. Etapa 4. Control.
Monitorear las desviaciones del plan y determinar sus posibles causas.
Efectuar las acciones correctivas para lograr la ejecucin del plan.
Evaluar los requerimientos de cambios solicitados por los patrocinadores
y los miembros del grupo; determinando el impacto en los alcances, en el
tiempo o en los recursos.
Detectar variaciones en los alcances, en la asignacin de recursos o en el
tiempo en que se deseen lograr los resultados.
Retornar a la Etapa de planeacin para hacer ajustes a las metas del
proyecto y obtener aprobacin de los patrocinadores, si fuese necesario.
4.6. Etapa 5. Conclusin.
Documentar las lecciones aprendidas durante su ejecucin.
Informar sobre la terminacin y los alcances logrados.
Consolidar toda la documentacin generada.
Elaborar el informe final de proyecto.
Liberar los recursos asignados.
Entregar el informe final al Patrocinador.
Inicio
Figura # 1. Fases de un Proyecto.
Pl
an
ea
ci
Eje
cu
ci
Cierre
Control
A continuacin se presenta de forma detallada las acciones que se deben realizar en

cada una de las etapas.
6. Anteproyecto (Etapa 0)
Todo proyecto tecnolgico a desarrollar debe estar contemplado en el Plan Tctico de
TIC (PTAC), el cual responde a las orientaciones que plantea el Plan Estratgico de
Tecnologas de la Informacin y Comunicaciones (PETIC) de la Contralora General de
la Repblica (CGR).
El proceso de actualizacin del PTAC, que se realiza peridicamente; establece segn
las prioridades de la organizacin, cuales son los proyectos que se deben desarrollar con
el fin de aportar el soporte tecnolgico que la organizacin necesita para mantenerse
actualizada y apoyada para el cumplimiento de sus metas y objetivos.
Todo proyecto a desarrollar debe tener su ficha de anteproyecto, misma que ser
evaluada y priorizada por el Comit Gerencial de Tecnologas de Informacin y
Comunicaciones (CGTIC), a solicitud de la Unidad de Sistemas y Tecnologas de
Informacin (USTI). Este comit elige de los anteproyectos planteados, aquellos que
sern tomados en cuenta en la cartera de proyectos del PTAC.
Los anteproyectos que no sean incluidos en el PTAC debern ser re-evaluados en
sus alcances y objetivos, cada vez con un mayor nivel de detalle, hasta que llegue el
momento de incluirlo en una reformulacin del PTAC. Dados los procesos de planeacin
estratgica, el anteproyecto sobrevivir y llegar a ser un proyecto operativo, mientras
el mismo tenga como alcances una funcin estratgica dentro de la organizacin. Si
el mismo perdiera vigencia o dejara de ser importante para la organizacin, el mismo
proceso de planeacin se encargara de eliminarlo.
La organizacin como un todo y la USTI, realizarn cada ao el ejercicio de planeacin
operativa (PAO), con un horizonte de planeacin de dos aos. Tomando como insumo
la cartera de proyectos del PTAC, la USTI define los alcances, se detallan los recursos
y se plantea un horizonte de tiempo esperado, para cada uno de los proyectos.
Para la estimacin del tiempo, se puede recurrir a diferentes tcnicas, como lo es el

juicio experto o la comparacin con proyectos ya concluidos.
Se debe tener claro que en esta etapa, an no se ha creado un equipo de trabajo
ni se ha realizado una evaluacin profunda, sobre las tres variables bsicas de todo
proyecto a saber: tiempo, recursos y alcances. Por lo tanto es de esperar, que al
crearse el equipo de trabajo y se entre a los niveles de detalle como en la etapa de
planeacin, los contenidos de dichas variables cambien.
5.1. Planteamiento de los anteproyectos
Todo anteproyecto de TIC intenta resolver una serie de necesidades que manifiesta la
organizacin en el desarrollo o actualizacin de alguno de sus procesos.
En el proceso de planeacin estratgica de la CGR se determinarn dichas necesidades
y de un primer anlisis de stas se deber plantear ante la jefatura de la USTI, una
ficha de anteproyecto. Dicha jefatura realizar un anlisis inicial de la propuesta
antes de someterla a evaluacin del CGTIC; el cual asignar una prioridad con la
cual determinar si debe permanecer en espera de ser atendido o si es contemplado
dentro de la siguiente revisin y reformulacin del PTAC; todo conforme al proceso de
planeacin explicado anteriormente.
El formato para la ficha de anteproyecto se encuentra detallado en el anexo 7.
5.2. Ajustes a los anteproyectos
Cuando un anteproyecto requiera ajustes o replanteamientos, deber reformularse la
ficha de proyecto y volver a someterlo ante la jefatura de la USTI, quien le realizar un
anlisis y lo someter a consideracin del CGTIC.
Cualquier cambio en cuanto a los resultados esperados, alcance planeado, efecto,

objetivos o productos, requiere de ser aprobado por el CGTIC antes de proceder con
la etapa de iniciacin del proyecto.
5.3. Productos de la etapa:
Ficha de anteproyecto
5.4. Punto de Control:
Evaluacin y priorizacin del anteproyecto por parte del CGTIC.
6. Iniciacin (Etapa 1)
En esta etapa se corroboran los alcances globales del proyecto y las expectativas
generales de los diferentes interesados. Adems se define la organizacin del proyecto
estableciendo las funciones y responsabilidades de cada uno de los involucrados, as
como el perfil deseable de los integrantes del equipo de trabajo. Ver anexo 1.
Una vez establecido formalmente quienes asumen las funciones de Patrocinador(es)
de Proyecto, Lder de Proyecto y Lder Tcnico de Proyecto; estos inicialmente
proceden a realizar un diagnstico de la situacin con el fin de establecer estrategias
de solucin, para que el patrocinador del proyecto determine la forma en que se
desarrollar.
6.1. Organizacin para el proyecto
Es necesario que las personas a cargo del proyecto tengan una estructura organizativa
que garantice un formalismo operacional, que permita lograr los fines propuestos.
Esta estructura podra variar en funcin de la magnitud y complejidad de los proyectos
y puede ser matricial.
La organizacin del proyecto requiere la interaccin de personas de las diferentes
reas, segn la siguiente definicin de estructuras:
Unidad Ejecutora
Grupo de Apoyo
Equipo de Trabajo
Equipo de apoyo tcnico
Cada uno de los participantes tiene asignadas tareas y responsabilidades especficas,
para un adecuado desempeo de su funcin.
Los participantes en el proyecto que conforman la organizacin descrita, son

identificados como sigue:
Participantes por parte de la unidad(es) patrocinadora(s):
Patrocinador(es) del Proyecto
Lder del Proyecto
Equipo de Trabajo
Participantes por parte de la USTI:

Coordinador de Proyectos (Jefatura o funcionario asignado)

Lder Tcnico
Equipo de apoyo tecnolgico
Para la conformacin de la organizacin del proyecto de TIC se deber considerar el
siguiente organigrama:
Organigrama del proyecto
Patrocinador
del proyecto
Grupo de
apoyo
Coordinador de
proyectos
Lder de
proyecto
Lder
Tcnico
Unidad Ejecutora
Equipo de trabajo
Equipo de apoyo
tcnico
Para un mayor detalle de los perfiles y de las responsabilidades de los miembros

permanentes ejecutores de un proyecto de TIC, refirase al anexo 3 de la presente
metodologa. A continuacin se presenta una explicacin de cada uno de estos
ejecutores del proyecto:
6.1.1. Unidad Ejecutora
La Unidad Ejecutora es el ente coordinador de los aspectos relacionados con el
desarrollo del proyecto de TIC.
Sus responsabilidades principales son:
Aprobar la organizacin, los recursos, y el cronograma del proyecto.
Velar por la calidad de los productos de cada una de las etapas y hacer las
recomendaciones necesarias.
Resolver las situaciones que puedan afectar el buen funcionamiento del
proyecto.
Aprobar los productos generados y ejercer los puntos de control establecidos
en cada etapa.
Est constituida por:
Patrocinador(es) del Proyecto (Coordinador)
Coordinador de Proyectos (Jefe de la USTI o a quien designe)
Lder del Proyecto.
Lder Tcnico.
6.1.2. Patrocinador del Proyecto

Es el jefe de la Unidad Organizacional para la cual se va a desarrollar un proyecto de

TIC. Segn sea el proyecto pueden verse involucrados ms de un patrocinador.
6.1.3. Grupo de Apoyo

Lo conforman funcionarios cuya experiencia y conocimientos son de gran ayuda a
nivel de asesora para el equipo de proyecto. Tambin lo pueden integrar grupos de
usuarios con inters en los resultados del proyecto.
6.1.4 Coordinador de proyectos
Esta funcin la lleva a cabo el Jefe de la USTI con fines de armonizar y asegurar
el aprovechamiento de componentes tecnolgicos, puede ser ejecutada por el
coordinador de proyectos de la USTI.
6.1.5. Lder del Proyecto
El Lder del Proyecto es un funcionario con gran conocimiento de su rea funcional,
aspecto por el cual se le ha conferido la capacidad de tomar decisiones y la
responsabilidad de participar activamente en la direccin del proyecto. Vela tanto por
los mejores intereses de su rea como por los de la Contralora General de la Repblica,
en lo que respecta al proyecto de TIC. Es el responsable directo del proyecto y de los
productos entregados.
En aquellos casos en donde el proyecto tenga un mayor componente tcnico en
materia de introduccin de nueva tecnologa, estar justificado que la direccin sea
asumida por un representante de la USTI, por su mayor experiencia en la materia
tecnolgica.
6.1.6. Lder Tcnico del Proyecto
Este es un funcionario al cual, por su formacin en el rea de informtica, experiencia
y capacidad, se le ha conferido la responsabilidad de administrar los aspectos
tecnolgicos de un proyecto de desarrollo informtico. Es el responsable directo del
desarrollo del proyecto en lo que corresponde a la parte tcnica, para ello aplica las
polticas, normas y procedimientos de trabajo aprobados.
6.1.7. Equipo de apoyo tecnolgico
Son los funcionarios especialistas en el rea de tecnologas de informacin que apoyan
la labor del Lder Tcnico, en materias tales como programacin, base de datos,
configuracin y operacin de equipos principales, y conectividad.
6.1.8. Equipo de trabajo
Son usuarios de los procesos funcionales involucrados en el proyecto de TIC a desarrollar,
conocedores de las necesidades a resolver e involucrados en la implementacin de la
solucin. Un aspecto de primer orden para garantizar el xito de un proyecto, estar
en la escogencia de un excelente equipo de trabajo.
6.1.9. Equipo de proyecto
Lo conforman el Lder de Proyecto, el Lder Tcnico, el equipo de trabajo y el equipo
de apoyo tecnolgico.
6.2. Organizacin del Proyecto
La informacin relacionada con la organizacin del proyecto debe quedar debidamente
formalizada y documentada, para lo cual en el anexo 8 encontrar el formato de
documento a utilizar.
6.3. Informe de diagnstico:

El informe de diagnstico especifica los resultados de la valoracin efectuada sobre la
solicitud de desarrollo de un proyecto de TIC. Este documento es confeccionado en
conjunto por el Lder Tcnico y el Lder de Proyecto; debiendo contener las siguientes
secciones:
6.3.1. Situacin actual
El Lder Tcnico con la colaboracin del Lder de Proyecto debe realizar un anlisis
de la situacin actual donde se describa la forma como el proceso se est realizando;
ya sea con alguna herramienta tecnolgica existente o de forma totalmente manual.
En este anlisis se debe hacer nfasis en la bsqueda de oportunidades de mejorar los
procesos actuales, en procura de que la insercin de tecnologa permita la realizacin
de actividades de forma ms eficiente y efectiva.
6.3.2. Alcances del proyecto
Los alcances establecen de manera clara, hasta dnde llegar el proyecto de TIC y
debern permitir el manejo de expectativas comunes entre todos los interesados y
participantes del proyecto.
Uno de los aspectos ms crticos de todo proyecto, es detallar y comunicar lo que cada
uno de los interesados (muchos de ellos patrocinadores) esperan. Por ello resulta
imprescindible que para cada interesado se establezca lo que espera obtener cuando
ste concluya.
Las expectativas de cada interesado debern ser conocidas por los dems y por
todos los integrantes del equipo de trabajo y debern quedar documentadas en este
apartado del diagnstico. Estas expectativas sern de referencia obligada para el

equipo de trabajo, con el fin de mantener enfocado el proyecto. Si en algn momento
se determinase que alguna de las expectativas enumeradas no podr ser alcanzada, el
grupo de proyecto est en la obligacin de comunicar esta situacin al interesado con
las justificaciones del caso, no sin antes haber evaluado la posibilidad de modificar el
proyecto para su cumplimiento.
Si en algn momento, se determina que no es factible lograr alguna de las expectativas
enumeradas, se deben realizar las modificaciones sustanciales del proyecto, sin
descartar la posibilidad de cancelarlo, en caso de que fuese imposible lograr los
alcances esperados.
Si el proyecto lo que busca es el desarrollo de un sistema de informacin, en este
apartado deber incluir al menos una descripcin de lo que se pretende obtener y
hasta dnde se desea llegar con la automatizacin.
6.3.3. Objetivos del proyecto
Definicin de los objetivos generales y especficos esperados con el sistema o solucin
tecnolgica, con base en lo planteado en la ficha de anteproyecto. Se refieren al nivel
de desempeo que se debe lograr para satisfacer una necesidad determinada.
En caso de requerir un cambio en los objetivos del proyecto, esto se ver como un
cambio a lo establecido en la ficha de anteproyecto y deber atenderse como se
estableci en el punto 5.2 de esta gua metodolgica.
6.3.4. Anlisis de riesgo

El Lder de Proyecto y el Lder Tcnico debern hacer un anlisis de riesgos del
proyecto de acuerdo con la metodologa establecida institucionalmente, basndose
en los siguientes riesgos y otros que considere de relevancia:
a. El proyecto no est alineado con la Estrategia Institucional.
b. El proyecto no est incluido dentro de la cartera de proyectos del PTAC.
c. El proyecto no cuenta con un patrocinador comprometido.
d. No se tiene el recurso humano necesario y calificado para el desarrollo del
proyecto
e. El recurso humano asignado al proyecto no dispone del tiempo requerido
para el mismo.
f. No se tiene el presupuesto necesario para la ejecucin del proyecto.
g. No se tiene la infraestructura tecnolgica (interna y externa) apropiada para
la puesta en operacin de la solucin tecnolgica.
h. El personal no tiene la suficiente capacitacin para utilizar las herramientas
tecnolgicas requeridas por el proyecto.
i. No se cuenta con el personal calificado en las materias relacionadas con
el proyecto.
j. Incumplimiento del plan de trabajo
k. Los objetivos y alcances del proyecto pueden ser modificados.
l. No se tiene la estructura administrativa (interna y externa) para soportar la
operacin de la solucin tecnolgica.
6.3.5. Identificacin de estrategias de solucin y su factibilidad
Establecer y explicar las diferentes estrategias de solucin para la construccin de la
solucin tecnolgica de acuerdo a los alcances definidos, considerando el anlisis de
factibilidad econmica, operativa y tcnica.
Cuando se planteen dos o ms estrategias de solucin se deber realizar un

anlisis comparativo entre ellas de ventajas y desventajas. Dentro de este anlisis
y en la medida de lo posible, se deber realizar un anlisis de costo/beneficio de
las estrategias propuestas para hacer una evaluacin de su factibilidad econmica
definida en trminos de costos y ahorros. No slo tomando en cuenta los costos de
implementacin de la solucin sino tambin los costos asociados a su sostenibilidad
durante su operacin. Este anlisis econmico es fundamental para los proyectos
donde se tenga adquisicin de nueva tecnologa.
Para ello se sugiere tener en cuenta los costos administrativos, operativos, laborales,
tecnolgicos, y otros. Se deben considerar los beneficios tangibles e intangibles que
se obtienen con el sistema, por ejemplo: tiempo requerido para la actualizacin o
conclusin del proceso, desplazamiento de personas, aprovechamiento de equipo y
las herramientas existentes, aprovechamiento de mejores prcticas en el mercado,
reduccin de gastos y simplificacin de trmites.
El nivel de detalle de esta evaluacin depender directamente de la complejidad del
proyecto y de los recursos disponibles para la elaboracin del estudio. En cualquier
caso deber contemplar las variables bsicas que determinen la viabilidad del proyecto
y su permanencia en el tiempo.
Si bien es cierto se cuenta con unas fechas de inicio y de fin sugeridas, esta definicin
de tiempo para el desarrollo del proyecto se debe ir afinando conforme el equipo de
trabajo conozca ms detalles del mismo. Con base en los alcances identificados del
proyecto, estudio de la situacin actual y el anlisis de riesgos se deber presentar
la estimacin inicial del tiempo que se requiere para cada una de las opciones de
las soluciones sealadas; acompaadas de los supuestos y restricciones que apoyan
dichas estimaciones.
Para cada una de las estrategias de solucin se deber identificar:

Ventajas y desventajas (Costo/Beneficio)
Factibilidad operativa, tcnica, econmica y legal
Riesgos asociados
Complejidad tcnica en el desarrollo y en la implementacin
6.3.6. Recomendacin de una estrategia de solucin
Cuando se tengan dos o ms estrategias de solucin y basado en las consideraciones
anteriores; el equipo de proyecto recomendar una de las estrategias de solucin; o
segn sea el caso podra recomendar no continuar con el desarrollo del proyecto, al
no considerarlo factible desde el punto de vista econmico, operativo, legal o tcnico.
6.4. Seleccin de la estrategia de solucin:
La Unidad Ejecutora del proyecto deber indicar su criterio sobre la forma en que
debe desarrollarse, basado en los resultados obtenidos en el diagnstico realizado.
En la seleccin de la opcin la Unidad Ejecutora puede recomendar al CGTIC alguna
de las siguientes decisiones:
Seleccionar alguna de las opciones recomendadas.
Posponer el proyecto para un momento ms oportuno, esto de acuerdo con
los intereses y prioridades de la Institucin.
Cancelar el proyecto ya que el mismo no es viable desde el punto de vista
operativo, legal, econmico o tcnico; o porque las prioridades institucionales
as lo requieren.
Cuando la Unidad Ejecutora haya seleccionado el curso de accin para el proyecto

que considere ms adecuado, deber documentarlo utilizando el formulario que se
detalla en el anexo 9.
6.5. Insumos de la etapa:
Ficha de anteproyecto.
6.6. Productos de la Etapa:
Informe de diagnstico.
Descriptivo de la Organizacin del Proyecto.
Estrategia de solucin para el proyecto.
6.7. Puntos de Control:
El patrocinador (o patrocinadores) del proyecto oficializa(n) los nombramientos del
lder de proyecto, as como la conformacin de los equipos de trabajo, y la USTI la del
lder tcnico y la del equipo de apoyo tcnico.
La Unidad Ejecutora del proyecto define la estrategia de solucin para el proyecto,
eligiendo el curso de accin a partir del anlisis de las diferentes opciones planteadas
en el informe de diagnstico.
7. Planeacin (Etapa 2)
El principal objetivo de esta etapa es especificar a un nivel detallado, las diferentes
actividades a realizar, reflejadas en un plan de trabajo. Para ello el equipo de trabajo
deber empezar por analizar los objetivos y alcances del proyecto, deber identificar
los recursos requeridos y establecer un cronograma de proyecto. Se debe utilizar el
software institucional para administracin de proyectos.
Como requisito para iniciar con esta etapa, el equipo de trabajo debe ya estar
formalmente constituido y se debe tener una estrategia de solucin, establecida a
partir del anlisis de los resultados del diagnstico elaborado en la etapa anterior, la
cual determina el curso de accin para las tareas que deber realizar el equipo de
proyecto, con miras a lograr el objetivo propuesto.
Siendo la labor de planeacin cclica, como se muestra en la figura # 1, la misma
se debe realizar tanto para el inicio, como durante la realizacin del proyecto. Si el
proyecto mostrase atrasos considerables en alguna de sus etapas, que no pudiesen
ser absorbidos por las holguras de los proyectos, o bien por un esfuerzo adicional
que ubique de nuevo el proyecto en su planeacin inicial, se debe realizar un nuevo
plan de proyecto, para el resto de las actividades a cumplir. Esta nueva versin del
plan puede variar los alcances del proyecto, o bien la calidad y cantidad de recursos
asignados.
El elaborar el plan es una labor muy delicada y se debe realizar con la participacin
de todos los miembros del equipo. Como en toda actividad grupal surgirn una serie
de opciones sobre como realizar las cosas, por lo que ser habilidad del Lder de
Proyecto conciliar criterios, de modo tal que se llegue a un consenso sobre cuales son
las actividades a desarrollar, para llegar a cumplir las finalidades del proyecto.
7.1. Elaboracin del Plan de Trabajo:

Teniendo siempre presente cual es el objetivo que se pretende, se recomienda cumplir
con los siguientes pasos, en un trabajo grupal.
a. Se debe elaborar una lista o enumeracin de todas las actividades que se
deben realizar para cumplir la meta.
b. Por cada actividad se debe tener claro cual es su propsito y el producto a
lograr a su conclusin.
c. El producto a lograr por cada actividad debe ser claro y conciso, si no es as
se debe desglosar o partir la actividad, en tantas como sea necesario para
que cada actividad tenga un producto definido y claro.
d. Cuando se tengan las actividades debidamente enmarcadas en cuanto
al producto a lograr, se debe proceder a definir que recursos humanos o
tcnicos requiere cada una de ellas.
e. Ntese que hasta el momento no nos hemos preocupado por la duracin
de las actividades ni en que momento se han de ejecutar, nos hemos
preocupado por crear consenso sobre lo que se quiere lograr y como
lograrlo. El siguiente paso ser determinar cuanto tiempo tomaremos
en cumplir cada una de las actividades, en funcin de los recursos que
tendremos disponibles.
f. El siguiente paso consistir en agrupar aquellas actividades cuyo producto
intermedio o final, sea un componente de un mismo resultado. Todas
estas actividades las podemos agrupar en una etapa o subproyecto, al
final del cual siempre debe haber un producto claramente definido, al que
llamaremos entregable intermedio o final, segn sea el caso. La definicin
de las etapas o subproyectos, depende del tamao del proyecto, del nivel
de control que es necesario tener y del nivel de conocimiento que el grupo
tenga sobre la materia.
g. Una vez agrupadas las actividades en etapas o subproyectos, se debe

proceder a determinar cual es el tipo de relacin que existe entre cada
actividad, pudiendo sta ser, predecesora inmediata o sucesora inmediata
o sin relacin. Predecesora inmediata ser aquella actividad que debe
haber sido concluida para que otra sucesora inmediata inicie.
h. Entre una actividad predecesora inmediata y otra sucesora inmediata,
puede haber un lapso de tiempo que llamaremos holgura, la cual puede
ser negativa, cero o positiva. Ser cero cuando una actividad de acuerdo al
plan debe iniciar de inmediato, tan pronto concluye su predecesora. Ser
positiva cuando entre el tiempo de conclusin de la predecesora y el inici
de la sucesora, pueden transcurrir n cantidad de das. Ser negativa
cuando la actividad sucesora, puede iniciar segn el plan, n cantidad de
das antes de que concluya la actividad antecesora.
i. Con toda la informacin anterior, se debe proceder a balancear las
actividades de manera tal que el entregable de la etapa o subproyecto se
logre en el menor tiempo posible. Entendemos como balanceo el agrupar
las actividades, de manera tal que muchas de ellas se puedan ejecutar
en paralelo, cuando los recursos y las dependencias entre actividades lo
permitan. Se debe evitar que un recurso quede sobrecargado ms all de lo
razonablemente aceptable. En el caso de los recursos humanos, se deben
considerar las ausencias planificables, programando por cada recurso el
tiempo formalmente comprometido al proyecto.
j. Todas aquellas actividades que al final del proceso de planeacin presenten
una holgura de cero, formarn lo que conoceremos como la ruta crtica.
Estas son las actividades que no se deben retrasar, ya que su retrazo implica
un atraso de la etapa o subproyecto. Se debe tener presente que aquellas
actividades que presenten holguras positivas, una vez consumidas stas
entran a la ruta crtica y podra tambin retrazar el proyecto.
7.1.1. Fases para el desarrollo de un sistema de informacin automatizado

En el caso de que el proyecto tenga como objetivo el desarrollo de un sistema de
informacin automatizado, el plan de trabajo deber contemplar las actividades propias
de las fases explicadas ampliamente en el anexo 4. Para este caso el cronograma
deber detallar actividades agrupndolas por cada fase.
Cuando un sistema requiera de ajustes por la atencin de nuevos requerimientos, sin
que esto pueda ser calificado como un cambio de versin en dicho sistema, su atencin
deber cumplir con las fases propias del control de cambios para el mantenimiento de
sistemas, mismas que estn explicadas en el anexo 5.
Si los cambios que un sistema requiere son de tal impacto que realmente se estara
generando una nueva versin, el tratamiento de tales requerimientos deber atenderse
con la rigurosidad de un proyecto de desarrollo de sistemas normal.
7.2. Formulario de planeacin de recursos:
Para documentar los diferentes recursos que se necesitan en el proyecto y el momento
en que se requieren, deber utilizarse el formulario que se detalla en el anexo 10.
De ser necesario, durante el transcurso del proyecto se documentar en el mismo
formulario, cualquier variacin de los mismos.
Informe de diagnstico.
Estrategia de solucin para el proyecto.

Plan de trabajo para el proyecto (Cronograma).
Formulario de planeacin de recursos.
La Unidad Ejecutora del Proyecto revisa y da su visto bueno al plan de trabajo del
proyecto y a la planeacin de recursos, como requisito para poder continuar con la
etapa de ejecucin. Si el plan no satisface las expectativas de los integrantes de la
Unidad Ejecutora, sta puede solicitar al equipo de trabajo una reformulacin.
8. Ejecucin (Etapa 3)
El objetivo de esta etapa es propiamente desarrollar y cumplir el plan elaborado
en la etapa anterior.
En reuniones peridicas el equipo de proyecto programa la
ejecucin de las acciones a realizar y las metas a alcanzar, acorde con las actividades
enumeradas en el plan general.
Durante esta etapa el Lder de Proyecto deber mantener informada a la Unidad
Ejecutora respecto del avance en el desarrollo de las actividades, situaciones no
planeadas que se presenten, actividades no programadas y resolucin de problemas.
Dependiendo del mismo plan de trabajo y del tipo de proyecto, durante la etapa de
ejecucin se crearn productos intermedios que debern ser revisados y aprobados
por la Unidad Ejecutora.
8.1. Minutas de reuniones:
No se debe menospreciar la importancia de las reuniones, por lo que es de suma
importancia el dejar documentados todos los asuntos y acuerdos tratados en las
reuniones, sean estas calendarizadas o no.
El Lder de Proyecto deber mantener como parte de la documentacin del proyecto,
las minutas de las reuniones que se realicen. Para la creacin de las minutas deber
utilizarse el formulario que se presenta en el anexo 6.
8.2. Informes de avance:
Los informes de avance debern emitirse con una periodicidad no mayor al mes,
estableciendo valoraciones sobre el desempeo general del proyecto, resaltando
aquellos aspectos que afectan el cumplimiento de los tiempos y de las metas planeadas.
El informe de avance deber ser corto y contener las siguientes secciones:

Tareas planeadas y completadas.
Tareas planeadas no completadas.
Tareas completadas no planeadas.
Grfico de avance mensual y de avance acumulado.
Administracin del riesgo.
Acciones correctivas o preventivas ejecutadas.
Observaciones.
El informe de avance va dirigido a la Unidad Ejecutora del Proyecto y es responsabilidad
del Lder del Proyecto no solo entregarlo, sino asegurarse de que es comprendido.
8.3. Productos intermedios propios del proyecto de TIC.
Dependiendo del tipo de proyecto, durante su ejecucin se presentarn productos
intermedios (documentales o no) que debern ser evaluados y en algunos casos
aprobados por la Unidad Ejecutora.
En el caso de un proyecto de desarrollo de
sistemas de informacin los productos intermedios estn debidamente identificados

en el anexo 4 para cada una de las fases.
Minutas de reuniones.
Informes de avance.
Productos intermedios propios del proyecto de TIC.
La Unidad Ejecutora del Proyecto revisa los informes de avance que emite el equipo de
proyecto, as como los ajustes y actualizaciones realizadas al cronograma de trabajo.
La Unidad Ejecutora del Proyecto revisa los productos intermedios propios del tipo de
proyecto de TIC que se desarrolla. En algunos casos el equipo de trabajo requerir
que se apruebe determinado producto intermedio, antes de continuar con el desarrollo
de tareas subsiguientes.
9. Control (Etapa 4)
Antes de ver el control como una etapa separada, se debe tener claro que ste es una
accin que siempre est presente durante el desarrollo del proyecto. Su fin primordial
es detectar desviaciones del plan de ejecucin en forma oportuna, de manera que
permita tomar acciones correctivas y preventivas. De ser necesario se deber retomar
el proceso de planeacin, para ejecutar las acciones necesarias, reflejndolas en una
nueva versin del plan.
La meta del control es lograr que los objetivos definidos en el plan de trabajo se
cumplan, a partir del seguimiento, ajuste y realimentacin de las acciones planeadas
y ejecutadas.
El proceso de control del proyecto valora como insumo los cambios en el entorno, los
cambios en los recursos, los cambios en las necesidades a solventar, las acciones
realizadas y el plan de trabajo; para emitir acciones correctivas y acciones preventivas.
9.1. Cronograma de proyecto actualizado:
El cronograma debe actualizarse peridicamente con el detalle de las actividades que
se han completado, el porcentaje de avance de las actividades que estn en proceso y
los ajustes propios de un proyecto en ejecucin donde se presentan nuevas tareas no
planeadas o la necesidad de ajustar fechas, producto de desfases que deben quedar
debidamente documentados.
Se debe hacer todo el esfuerzo porque el plan se cumpla, sin embargo todo plan
no es ms que una aproximacin del futuro y por ms cuidado y experiencia que
se haya puesto en la elaboracin del mismo, siempre existirn una serie de factores
que se pueden haber escapado durante la elaboracin del mismo. Otro aspecto muy
importante es que el plan esta enmarcado en una realidad de la organizacin, siendo

la misma un ente vivo y cambiante, y as lo ser el plan.
9.2. Control de avance por unidades de logro
El Lder de Proyecto y el Lder Tcnico deben llevar un control del avance del proyecto,
que no sea por estimacin o por algn criterio experto, sino que sea totalmente objetivo,
enfocando el logro real de cada tarea.
Para ello deben hacer uso de la asignacin de Unidades de Logro (UL) a las tareas
del plan de trabajo y crear un seguimiento de las unidades alcanzadas por el proyecto
de forma acumulada y mensual. A cada tarea planeada se le asigna una cantidad de
unidades de logro y para la contabilizacin de unidades deber tenerse en cuenta que
slo las tareas completas ofrecen logro y que el aporte al logro varia dependiendo de
si la tarea pertenece a la ruta crtica o no.
Para la aplicacin de unidades de logro debern seguirse los siguientes pasos:
Debe pasarse a una hoja electrnica la lista de tareas planeadas en el
proyecto
A partir del cronograma de trabajo deben identificarse cuales son las tareas
que pertenecen a la ruta crtica del proyecto.
A las tareas que son de ruta crtica se les asignar un aporte al logro de 1
UL por cada 2 das que se planea que dure la tarea. Por ejemplo:
una
tarea de ruta crtica que dure 11 das aportar 5.5 UL.

A las tareas que no son de ruta crtica se les asignar un aporte al logro de
1 UL por cada 5 das que se planea que dure la tarea. Por ejemplo: una
tarea que no sea de ruta crtica que dura 11 das aportar 2.2 UL.
La tarea aportar sus UL al mes que corresponda con la fecha de finalizacin
planeada.
Por ejemplo: Si la tarea inicia el 15/06/200X y finaliza el
08/08/200X, las unidades de logro de esa tarea se acumularn para el mes

de agosto (por esto es importante dividir grandes tareas en tareas menores
que mejor contabilicen el logro por mes).
Se suman por mes las UL para tener el total general de UL del proyecto.
Se sumarizan los totales por mes en la tabla de Logro Planeado y Logro
Real, segn hoja electrnica presentada ms adelante. Ntese que de esta
forma se hace diferencia entre el logro alcanzado y el avance en el tiempo,
haciendo del manejo del porcentaje de avance una valoracin real y no una
estimacin por criterio personal.
Con dicha informacin se puede crear una hoja electrnica que calcule
de forma real el porcentaje de avance con relacin a lo planeado y a
lo ejecutado; que lo muestre por mes y por acumulado general para el
proyecto. A continuacin se presenta una hoja electrnica ejemplo que
puede ser ajustada para cualquier proyecto.
9.3. Formularios de acciones correctivas y preventivas:

Cuando en el proceso de control se detecten o prevean desviaciones con respecto a
lo que establece el plan de trabajo, de manera oportuna debern ejecutarse acciones
correctivas y preventivas que vengan a mitigar el impacto de dichas desviaciones
sobre el logro de los objetivos y metas del proyecto.
Las acciones correctivas o preventivas deben estar claramente explicadas e indicar
el o los responsables de ejecutarlas. De ser necesario estas acciones deben quedar
incorporadas en el plan de trabajo para su futuro seguimiento y
documentadas en formularios cuyo formato se detalla en el anexo 11.
debidamente
9.4. Control de cambios.

Durante la ejecucin de cualquier proyecto se pueden presentar cambios que afecten
directa o indirectamente el logro de los objetivos y de las metas. El proceso de control
del proyecto deber analizar; entre otros, los cambios en las condiciones del entorno,
los cambios en los recursos, los cambios en las necesidades a solventar, los cambios
en la tecnologa, cambios en los objetivos, y cambios en la estrategia de solucin.
Todo cambio que afecte el curso de accin, los alcances o la estrategia de solucin;
debe quedar documentado, sobre todo si dichos cambios impactan el cronograma de
proyecto. Adems el Lder del Proyecto deber hacer del conocimiento de la Unidad
Ejecutora todo cambio importante, la cual tiene que aprobar si se atiende o no dicho
cambio.
Para llevar el control de cambios del proyecto se debe usar el formulario que se detalla
en el anexo 12.
Informes de avance.
Cronograma de proyecto actualizado.
Control de avance por unidades de logro.
Grficos de avance acumulado y avance mensual.
Formularios de acciones correctivas.
Control de cambios.

La Unidad Ejecutora del Proyecto revisa los informes que emite el equipo de proyecto
y el control de avance; cuando identifique tareas desfasadas aprobar acciones
correctivas o preventivas tendientes a mitigar el desfase. La Unidad Ejecutora puede
decidir retomar el proceso de planeacin y generar una nueva versin del plan.
10. Etapa 5: Conclusin

En esta etapa se debe revisar el cumplimiento de las metas iniciales a efectos de
realizar el cierre del proyecto.
Toda etapa de conclusin de un proyecto debe cumplir con las siguientes actividades
bsicas.
Enterar a los patrocinadores sobre los resultados del proyecto.
Entrega de productos con su respectiva aprobacin.
Liberar los recursos que an estn asignados al proyecto.
Documentar los procesos finales, entendiendo que el proceso de
documentacin fue un proceso rutinario durante toda la vida del proyecto;
por lo que en esta etapa deber dejarse actualizado el respectivo expediente
de proyecto.
10.1. Informe de conclusin del proyecto:
Todo Lder de Proyecto, con el apoyo del resto de los integrantes del equipo, tiene
que elaborar el informe final de cierre del proyecto, el cual debe cubrir los siguientes
puntos:
Resumen ejecutivo con los principales logros, comparados con las metas
originales del proyecto.
Puntos o tareas que quedaron pendientes, ya sea porque requieren de una
mayor investigacin o elaboracin; o porque se debern retomar para una
segunda versin del proyecto.
Resumen de los asuntos conflictivos y soluciones.
Recomendaciones para mejorar la administracin y ejecucin de proyectos
futuros.
Costo total del proyecto.

Explicacin de las variaciones en el presupuesto.
10.2. Aceptacin a satisfaccin de los productos finales del proyecto:
La Unidad Ejecutora debe revisar y dar por aceptados a satisfaccin los productos
finales del proyecto. Si algn producto no se considera como terminado el proyecto
no est en fase de conclusin.
Luego de la respectiva revisin, el coordinador de la Unidad Ejecutora debe dejar
constancia de la aceptacin de los productos mediante el formulario detallado en el
anexo 13.
10.3. Expediente actualizado del proyecto:
Es necesario recordar que toda la informacin relativa al proyecto que recin termina,
es de vital importancia para otros proyectos o trabajos futuros. Es por ello que el Lder
del Proyecto deber dejar debidamente actualizado el expediente. Este expediente
debe contener todos los entregables de cada fase del proyecto, y debe mantenerse en
formato digital de acuerdo al expediente electrnico definido en la CGR.
La Unidad de Sistemas y Tecnologas de Informacin ser la encargada de mantener
toda la documentacin almacenada en un solo expediente o carpeta y de facilitar los
medios para que todo funcionario interesado tenga acceso a dicha informacin.
Cronograma actualizado con ejecucin de tareas.
Documentos desarrollados durante el proyecto.

Informe de conclusin del proyecto
Formulario de aceptacin a satisfaccin de los productos.
Expediente actualizado del proyecto

La Unidad Ejecutora del Proyecto revisa el informe final del proyecto y lo hace del
conocimiento de todos los interesados.
La Unidad Ejecutora da por aceptados los productos finales del proyecto.
Anexo 1
Definicin de roles
En el desarrollo de un proyecto de TIC se presentan diferentes actores con funciones
y responsabilidades que se describen a continuacin:
Comit Gerencial de Tecnologas de Informacin y Comunicaciones (CGTIC):

por delegacin del mximo jerarca (Contralor o Contralora General),
es el mximo ente en lo referente a recomendar sobre las directrices y
lineamientos a seguir en la planificacin y direccin de los procesos de
desarrollo tecnolgico. Est conformado por representantes de alto nivel
gerencial, por el Jefe de Auditoria Interna como asesor del Comit y por
el Jefe la Unidad de Sistema y Tecnologas de Informacin (USTI). Este
Comit reporta al mximo jerarca, quien lo preside.
Patrocinador del proyecto: es el mximo jerarca o en quien ste delegue, de
la Unidad Organizacional para la cual se va a desarrollar el proyecto de TIC.
Coordinador de proyectos: este rol es asumido por la jefatura de la USTI o
delegado en un funcionario de la misma Unidad, para velar por la adecuada
ejecucin de los proyectos de TIC observando aspectos como integracin,
calidad, logro de objetivos y eficiencia en los diseos y desarrollo de las
soluciones.
Lder del proyecto: es un funcionario con gran conocimiento de su rea
funcional, aspecto por el cual se le ha conferido la capacidad de tomar
decisiones y la responsabilidad de liderar activamente el proyecto; vela tanto
por los mejores intereses de la Contralora General de la Repblica, como
por los de su rea en lo que al proyecto concierne. En casos justificados
y por recomendacin del CGTIC, la direccin puede ser asumida por un
representante de la USTI.
Lder Tcnico del proyecto: ste es un funcionario al cual, por su formacin

en el rea de informtica, experiencia y capacidad, se la ha conferido la
responsabilidad de administrar los aspectos tecnolgicos de un proyecto
de TIC.
Analista de sistemas: es el recurso profesional en informtica (funcionario o
no de la Contralora General de la Repblica) que trabaja bajo la coordinacin
y direccin del Lder Tcnico del proyecto para la realizacin de tareas
propias del proyecto de TIC, cuyas actividades entre otras son: anlisis,
diseo, desarrollo de los programas, pruebas, capacitacin de usuarios,
documentacin y apoyo tcnico a los usuarios en la puesta en operacin
de una solucin tecnolgica.
Programador de sistemas: es el recurso profesional en informtica
(funcionario o no de la Contralora General de la Repblica) que trabaja
bajo la coordinacin y direccin del Lder Tcnico del proyecto para la
realizacin del sistema y cuyas actividades entre otras son: el desarrollo de
los programas, pruebas y documentacin de los programas.
Usuario de TIC: se considera a todo aquel individuo (funcionario o no de
la Contralora General de la Repblica) que tenga acceso autorizado a
sistemas de Informacin, o que se beneficie de alguna solucin tecnolgica.
Para efectos de la metodologa vamos a considerar usuarios registradores
y generadores de informacin, usuarios de consulta y usuarios expertos
de los sistemas o de la tecnologa, quienes adems de tener acceso o
interaccin con el sistema o solucin tecnolgica, son usuarios de amplio
dominio sobre el negocio que dicha tecnologa o sistema soporta.
Es posible que la misma persona desempee ms de un rol en el desarrollo del
proyecto, especialmente si pertenece a la USTI; pero en todo proyecto siempre se debe
contar con el apoyo de la contraparte usuaria que tiene las necesidades especficas de
manejo de la informacin y del conocimiento.
Anexo 2
Actualizacin de la Gua Metodolgica para el Desarrollo de Proyectos

de Tecnologa de Informacin y Comunicaciones.
Dado el ritmo acelerado que impone el entorno tecnolgico y los cambios que
toda organizacin debe realizar para mantenerse actualizada,
se establece la
necesidad de realizar peridicamente las revisiones y los ajustes que corresponda

a la Gua Metodolgica para el desarrollo de Proyectos de TIC. El responsable de
esta actualizacin ser la Unidad de Sistemas y Tecnologas de Informacin, quien
podr pedir el apoyo y la asesora de otros funcionarios de la Contralora General de la
Repblica, que estime conveniente.
Esta Unidad adicionalmente deber considerar las solicitudes de modificacin
expresas y aportes hechos por Lderes de Proyectos, producto de experiencias previas
de aplicacin de la misma gua y sus respectivas lecciones aprendidas.
Una vez hechos los ajustes correspondientes, los puntos modificados o agregados debe
ser sometidos a consideracin del Comit Gerencial de Tecnologas de Informacin y
Comunicaciones quien debe recomendar su aplicacin para proceder a su publicacin
y a la divulgacin respectiva.
Anexo 3
Responsabilidades de los miembros del proyecto

Patrocinador del Proyecto
Entre sus responsabilidades se destacan las siguientes:
Aprobar formalmente la organizacin del proyecto.
Designar al Lder del Proyecto.
Aportar el personal de apoyo adecuado para llevar a cabo un anlisis integral
sobre la factibilidad tcnica, legal, funcional y econmica, del proyecto a
realizar.
Apoyar en la solucin de problemas y en la consecucin de los recursos.
Aprobar los productos de cada etapa en el proceso de desarrollo del
proyecto.
Evaluar, peridicamente, el progreso del proyecto, con base en los planes
y los informes de avance, y hacer las recomendaciones que correspondan.
Aprobar ajustes al cronograma, en caso de ser necesario.
Aprobar cualquier cambio en procedimientos de trabajo que requiera la
solucin tecnolgica para ser implementada.
En el caso de un nuevo sistema automatizado, debe aprobar el plan para
levantamiento de informacin, conversin y carga de datos.
Aprobar el plan para capacitacin de usuarios.
Aprobar la solucin tecnolgica y fecha para su entrada en operacin.
Coordinador de Proyectos de la USTI.

Entre sus responsabilidades se destacan las siguientes:
Actuar como un integrador de los alcances de los diferentes proyectos.
Balancear la utilizacin de los diferentes recursos de la USTI, sobre todo
aquellos que estn siendo utilizados en varios proyectos, tanto humanos
como tecnolgicos.
Velar porque en cada proyecto se tenga un expediente con la informacin

relevante.
Generar informacin histrica sobre el desarrollo de cada proyecto y ponerla
a disposicin de los grupos de trabajo de los nuevos proyectos, para ser
utilizada como referencia.
Detectar desviaciones en los diferentes planes de trabajo y velar porque se
tomen las medidas correctivas del caso.
Velar porque los diferentes proyectos en ejecucin mantengan las
orientaciones planteadas tanto en el Plan Estratgico de Tecnologas de
Informacin y Comunicaciones (PETIC), como en el correspondiente Plan
Tctico (PTAC).
Generar informacin operativa de los proyectos para el apoyo a la toma de
decisiones por parte de la Jefatura de la USTI.
Apoyar en todos los pasos necesarios para dar inicio a los nuevos proyectos,
desde las etapas preparatorias de conceptualizacin, hasta dejar constituidos
y funcionando los equipos de trabajo.
Preparar y motivar a los integrantes de los equipos de trabajo, para que
conozcan y cumplan el rol que se espera de ellos.
Mantener el equilibrio en el uso de los recursos asignados a los diferentes
proyectos.
Mantener una secuencia lgica entre los alcances de los diferentes
proyectos.
Brindar capacitacin al equipo de trabajo en el uso de la Gua metodolgica
para desarrollo de proyectos en TIC.
Jefe de la USTI.
El jefe de la USTI puede delegar algunas responsabilidades de coordinacin en un
funcionario que rena los requisitos necesarios. Entre sus responsabilidades respecto
a los proyectos de TIC se destacan las siguientes:
Coordinar la ejecucin de los proyectos aprobados por el CGTIC.
Velar porque el desarrollo de los proyectos de TIC estn de acuerdo con las
estrategias y orientaciones definidas en los planes.
Apoyar en la solucin de problemas y en la consecucin de los recursos.
Recibir, analizar y tramitar las solicitudes por nuevos proyectos de TIC.
Asignar al lder tcnico que trabajar en el proyecto.
Participar en las reuniones de la Unidad Ejecutora cuando sea requerido.
Aprobar las diferentes etapas de aquellos proyectos que as lo requieran.
Apoyar al Lder Tcnico en los asuntos del desarrollo del proyecto que lo
requieran.
Coordinar el cumplimiento del cronograma de trabajo, en conjunto con el
Lder del Proyecto y el Lder Tcnico.
Identificar situaciones que puedan afectar el cumplimiento de los objetivos,
y coordinar las acciones preventivas o correctivas necesarias.
Lder del Proyecto

Perfil:
El Lder del Proyecto debe ser un representante, del rea funcional que
propone e impulsa el desarrollo de proyecto de TIC.
Debe coordinar estrechamente con el patrocinador del proyecto, por
cuanto sus responsabilidades incluyen la toma de decisiones, la resolucin
de problemas y el logro de la colaboracin necesaria de otras unidades
organizacionales, cuando sea requerida.
Debe tener las siguientes caractersticas:

Amplio conocimiento y dominio de las actividades y procesos involucrados
en el proyecto, as como de la problemtica y perspectivas futuras que
giren en torno a dichas actividades o procesos.
Disponer del tiempo suficiente que le demande el proyecto para participar
muy activamente junto con el Lder Tcnico y su equipo de trabajo, en las
fases del proyecto donde su participacin es crtica.
Mostrar alto nivel de compromiso e identificacin con el proyecto en
desarrollo.
Estar familiarizado con los conceptos bsicos del desarrollo de proyectos de
TIC y preferiblemente tener alguna experiencia al respecto.
Habilidad para administracin de personal.
Facilidades para administrar proyectos.
Responsabilidades Principales
Administrar (planificar, dirigir, controlar, ejecutar y evaluar) las fases de un proyecto de
TIC con eficiencia y eficacia.
Funciones
a. Comprobar la aplicacin de las actividades establecidas en la Gua
Metodolgica para el Desarrollo de Proyectos de TIC.
b. Elaborar, revisar y aprobar los planes del proyecto correspondientes a cada
una de las fases del desarrollo y velar por su cumplimiento.
c. Evaluar peridicamente el avance del proyecto, con base en lo planeado y
ajustarlo en caso de que sea necesario. Elaborar informes peridicos sobre
el desarrollo y cumplimiento del plan de trabajo.
d. Facilitar y promover el trabajo en equipo.
e. Atender los problemas administrativos (disponibilidad de recursos,

conflictos, modificacin de procedimientos o procesos) que requieran su
atencin.
f. Mantener las vas de comunicacin adecuadas, para informar a todos los
interesados en el proyecto, sobre los detalles del mismo.
g. Lograr la colaboracin apropiada de otras unidades organizacionales, que se
vean afectadas o involucradas por el desarrollo del proyecto, con el objetivo
de implementar una solucin integral, eficaz y eficiente al problema.
h. Definir los procedimientos administrativos en torno a la solucin tecnolgica
que se desarrolle o implante.
i. Definir las nuevas funciones y responsabilidades por puesto o la actualizacin
de stas, las cuales se deriven por el proyecto en desarrollo.
j. Participar activamente en la definicin de requerimientos y alcances del
proyecto, considerando las necesidades propias de su rea funcional, de
otras reas que por su funcin estn relacionadas con el proyecto, as
como de los niveles de decisin.
k. Participar en el estudio de paquetes de software, cuando sea requerido
para el proyecto y emitir las observaciones pertinentes.
l. Cuando el proyecto involucre un nuevo sistema de informacin deber:
revisar y aprobar, junto con el Lder Tcnico, el diseo funcional del
sistema.
Evaluar el prototipo del sistema de informacin,
hacer las
recomendaciones pertinentes y aprobarlo formalmente.

Participar activamente en la definicin de volmenes de informacin,
aspectos operacionales del sistema, criticidad, usuarios del sistema,
procesos de entrada y salida, diseo de reportes, aspectos de
seguridad y controles, interfaces, y requerimientos de hardware.
Evaluar el diseo final del sistema en sus apartados de seguridad y
controles, procesos de entrada y salida, e interfaces y funcionalidad
del sistema, emitir las recomendaciones pertinentes y aprobarlo

formalmente.
Participar y aprobar el plan de pruebas y del paralelo, y emitir, para
tal efecto, las recomendaciones pertinentes.
Coordinar el levantamiento de datos para las pruebas y para la
ejecucin del paralelo del sistema.
Asignar personal de su rea funcional para la digitacin de datos no
disponibles automticamente.
Coordinar y participar activamente en las pruebas integradas del
sistema, formular las recomendaciones pertinentes velando porque
ste se ajuste al prototipo y diseo final aprobados, con exactitud y
completitud conforme a los resultados deseados.
Identificar a los funcionarios que debern recibir entrenamiento
para el paralelo.
Participar activamente en la ejecucin del paralelo, llevando registro
de las modificaciones requeridas.
Identificar al personal de su rea funcional, que requerir
entrenamiento en la operacin del sistema.
Coordinar el planeamiento y ejecucin del plan de capacitacin.
Revisar y aprobar los manuales del usuario, capacitacin, y operacin
del sistema.
Participar activamente en la planificacin e implantacin del sistema.
Hacer un seguimiento del sistema post-implantacin y emitir las
recomendaciones que procedan.
Participar en la evaluacin posterior a la implantacin de la solucin
desarrollada, llevando a cabo un anlisis de los beneficios reales
contra los planeados.
Lder Tcnico del proyecto

Perfil:
Ser un individuo con una preparacin acadmica adecuada que lo
faculte para llevar a cabo con xito, el seguimiento, y el desarrollo de un
proyecto de sistemas de informacin.
A la vez, debe ser una persona
experimentada, segn lo que requiera el proyecto, en aspectos como el

desarrollo de sistemas de informacin o el manejo tcnico de herramientas
tecnolgicas especficas (bases de datos, redes, elementos de seguridad,
comunicaciones, paquetes, entre otros), o sobre la solucin tecnolgica a
desarrollar o implementar.
Tener capacidad de asimilar los procesos de las reas funcionales
relacionadas con su proyecto en desarrollo y aportar ideas creativas
que mejoren los procesos, al operar ste como agente de cambio en la
Organizacin.
Mantener una constante preocupacin por mantenerse actualizado acerca
de los ltimos avances en la tecnologa informtica en el entorno, con el
objetivo de analizarlos y determinar su aplicabilidad o adaptabilidad, si esto
fuese requerido para el logro de los objetivos del proyecto.
Responsabilidad principal
Colaborar con la Administracin en llevar a cabo las fases de un proyecto
de desarrollo tecnolgico, sea en forma interna o servicio contratado, con
eficiencia y eficacia.
Funciones
a. Apoyar en la elaboracin de los planes del proyecto requeridos y
correspondientes a cada una de las etapas, de acuerdo con la metodologa
y estndares vigentes.
b. Revisar los planes propuestos por el contratista e identificar y sugerir las
modificaciones necesarias, para salvaguardar los intereses del usuario y
de la Contralora General de la Repblica, en caso de contratacin externa.
c. Llevar un control de toda la informacin (documentacin) que se genera en
torno al proyecto tanto formal como informal, con el objetivo de respaldar
cualquier incidente, debido a problemas de comunicacin.
d. Supervisar y controlar la ejecucin real del proyecto, de acuerdo con los
estndares vigentes, para verificar la observacin de los planes y etapas
especficas, con la finalidad de identificar oportunamente cualquier desfase
o incumplimiento, interno o externo, y tomar las medidas correctivas.
e. Detectar y analizar cualquier problema actual o potencial que ocasione
variacin sobre lo planeado, coordinando las medidas correctivas con el
usuario responsable.
f.
g. Identificar y gestionar cualquier intervencin o ayuda requerida, para el
desarrollo del proyecto.
h. El Lder Tcnico debe velar por la aplicacin de los cambios tecnolgicos
que llegue a conocer y que afecten el proyecto.
i. Resolver los problemas y conflictos internos del proyecto que estn a su
alcance y elevar a los mandos superiores los que no pueda solucionar.
j. Presentar y justificar tcnicamente el proyecto tanto frente a los usuarios,
como ante otros coordinadores tcnicos y jefaturas.
k. Revisar y evaluar la calidad de los productos generados en las diferentes
etapas del proyecto, desarrollados en forma interna o por el contratista, de
acuerdo con los estndares vigentes y los planes. Por otra parte, identificar
las modificaciones necesarias y presentar las recomendaciones pertinentes

para su consideracin, por parte del usuario responsable, la jefatura de la
USTI y el contratista si lo hubiera.
l. Revisar y evaluar cualquier recomendacin hecha por un miembro del
proyecto antes de presentarla a otras personas o ante una eventual empresa
contratada.
m. Mantener una estrecha relacin con los otros Lderes Tcnicos de proyecto,
el Equipo de Apoyo Tecnolgico, y el coordinador de proyectos; con la
finalidad de determinar y facilitar los enlaces requeridos entre sistemas;
analizar la viabilidad tcnica de las propuestas y compartir las experiencias
del desarrollo de proyectos. Con esto se pretende identificar, entre otros
aspectos, los requerimientos en reas tales como: software, hardware,
interfaces, comunicacin y topologa.
n. Administrar con responsabilidad y discrecin toda aquella informacin que,
por su ndole, lo amerite.
o. Ofrecer continuos aportes y sugerencias de acuerdo con su conocimiento y
experiencia en el uso de metodologa, y estndares, que coadyuven en su
depuracin y mejoramiento, con la finalidad de eficientizar los mtodos
de trabajo.
p. Mantener informado al Lder del Proyecto, al coordinador de proyectos y a
la jefatura de la USTI, acerca de la ejecucin del proyecto.
En particular, si el proyecto se desarrolla bajo el esquema de contratacin, en lugar de
coordinar al equipo de apoyo tecnolgico, tendra las siguientes funciones:
a. Efectuar el control de calidad de los productos que entregue el proveedor
contratado.
b. Garantizar una transferencia tecnolgica adecuada, de tal forma que
inmediatamente que el proveedor entregue la herramienta pueda ser
administrada tcnicamente por la USTI.
c. Fungir como facilitador tcnico para el proveedor contratado, de tal forma

que suministre oportunamente la informacin tcnica que se requiera, para
que el proyecto se desarrolle sin contratiempos.
d. Velar por el cumplimiento de los tiempos de entrega de los productos,
segn lo acordado con el proveedor. Proponer acciones correctivas en
caso de desfases.
e. Fungir como contraparte tcnica por parte de la Contralora General en
defensa de los intereses institucionales, velando por el debido cumplimiento
de los compromisos suscritos por el proveedor contratado.
Equipo de apoyo tecnolgico

Entre sus responsabilidades est:
Asistir la labor del Lder Tcnico en materias como programacin, diseo y
optimizacin de bases de datos, operacin de equipos principales, paso a
produccin de un sistema, sistemas operativos, seguridad, comunicaciones
y definicin de perfiles de acceso.
Equipo de trabajo
Brindar toda la informacin y colaboracin necesaria al Lder de Proyecto y
al Lder Tcnico, en todas las etapas, actividades y tareas que lo requieran.
Atender las tareas que el Lder del Proyecto les asigne.
Grupo de Apoyo
Colaborar con el Lder de Proyecto en todas las etapas, actividades y tareas
que lo requiera.
Atender las tareas que el Lder del Proyecto les solicite.
Matriz de Responsabilidades
(Footnotes)
1
Esta revisin corresponde a la integracin del nuevo sistema propuesto y sus requerimientos con soluciones existentes y en
funcionamiento en la Contralora General, la aprobacin de los requerimientos en cuanto al alcance del proyecto es responsabilidad
del Patrocinador y Lder del Proyecto.
2
El producto debe ser informado al usuario por medio de una presentacin formal la cual debe quedar documentada por una minuta.
Anexo 4
Fases para el desarrollo de sistemas

1. Anlisis integral de requerimientos
1.1.
Consideraciones
Con el anlisis integral de requerimientos del sistema a automatizar se espera:

Identificar, analizar y documentar los requerimientos funcionales y nofuncionales que debe soportar el sistema o solucin propuesta. Los
requerimientos funcionales se refieren a las cosas que el sistema debe
realizar, por ejemplo que informacin se debe registrar y de que manera
se debe procesar; los requerimientos no funcionales se refieren a los
aspectos operativos del sistema como tiempos de respuesta, respaldos de
informacin y presencia en la Internet o en la Intranet de la Contralora.
Priorizar los requerimientos que ha de cubrir el nuevo sistema o solucin,
convirtindose en punto de referencia bsico para validar el sistema final,
comprobando que se ajusta a las necesidades del usuario.
El proceso de anlisis de requerimientos se puede representar en la siguiente figura:
El usuario o usuarios del futuro sistema deben realizar la especificacin de los

requerimientos funcionales y no funcionales del nuevo sistema, los cuales debern
ser priorizados de acuerdo a su grado de aporte a la consecucin de los objetivos
del proyecto. Para ello tendr la colaboracin del personal informtico asignado al
proyecto.
Estos requerimientos sern analizados por los Analistas de Sistemas asignados al
proyecto con el apoyo del Lder Tcnico y si fuera necesario se podr solicitar a los
usuarios profundizar en la especificacin de uno o varios de los requerimientos con la
finalidad de que stos sean lo ms claros y especficos posibles.
Paralelamente en este proceso de anlisis se deben identificar posibles ajustes a la
planeacin de los recursos requeridos por el proyecto; as como los requerimientos
crticos para el xito del mismo. Con esta informacin se confeccionar el Documento
de Anlisis y se ajustar el cronograma para la conclusin del proyecto.
1.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y

que formarn parte del expediente o archivo del proyecto.
En lo referente a la fase de anlisis integral de requerimientos para el Desarrollo de un
Sistema de Informacin se identifican los siguientes entregables:
Especificacin de requerimientos: se entiende por especificacin de
requerimientos un documento con la descripcin precisa y detallada que
hace el usuario de las necesidades a ser resueltas con el sistema solicitado
y sus restricciones.
Documento de anlisis: en este documento se presentan los resultados
obtenidos en la fase de Anlisis y debe hacer referencia a la valoracin de
complejidad y prioridad preliminar de los requerimientos. Puede establecer
ajustes al formulario de recursos requeridos para la realizacin del proyecto

y presentar ajustes al cronograma para la completitud del proyecto.
1.2.1. Especificacin de requerimientos
La especificacin de requerimientos es la descripcin precisa y detallada que hace el
usuario de las necesidades a ser resueltas con el sistema solicitado y sus restricciones.
Para ello, el Lder Tcnico y el analista asignado deben trabajar en conjunto con el
grupo de usuarios, de manera que generen experiencia en traducir en requerimientos
(descripcin precisa y detallada de la funcionalidad del sistema), las necesidades que
poseen y que sean muy comprensibles. Para lograr este propsito el usuario experto
puede aportar la documentacin que considere pertinente, como boletas, formularios,
legislacin, normativa, documentos y tipos de reportes.
Los requerimientos se pueden agrupar en funcionales y no funcionales:
a. Requerimientos funcionales
Son las indicaciones de servicio que el sistema debe proveer en cuanto a actualizacin
de datos, opciones de consulta, reportes a generar, interaccin con otros sistemas,
bitcoras de seguimiento y pistas de Auditoria (en coordinacin con la Auditoria
Interna).
Entre las caractersticas que se espera que posean los requerimientos funcionales
estn las siguientes:
Correcto: Cada requerimiento debe describir con exactitud la funcionalidad
que se obtendr del sistema, de manera que no exista conflicto entre ellos.
Debe tener una referencia a la fuente del requerimiento, sea este el cliente
o bien un requerimiento propio de la implementacin del sistema.
Factible: Se refiere a la posibilidad tcnica, operativa, legal, econmica y

presupuestaria de implementar cada uno de los requerimientos dentro de
la capacidad y limitaciones del sistema y su ambiente de desarrollo. El
desarrollador debe chequear cada uno de los requerimientos y determinar
qu se puede desarrollar y qu no, y qu puede desarrollarse pero tiene un
costo excesivo.
Necesario: Cada uno de los requerimientos debe documentar una necesidad
del usuario o bien un requisito del sistema, interfase o estndar. Debe poder
indicarse el rastro del requerimiento desde su origen, de tal forma que sea
vlido y por ende necesario.
Claro: El lector del documento de requerimientos debe ser capaz de
interpretarlo de una nica forma. Para esto cada requerimiento debe
describirse en forma sucinta, simple, en un lenguaje comprensible por el
usuario. Para verificar la claridad de los requerimientos se pueden crear
escenarios que ilustren la funcionalidad de porciones especficas del
sistema.
Verificable: Un requerimiento es verificable si se puede utilizar algn tipo
de pruebas tales como inspeccin o demostracin para determinar si el
requerimiento satisface las necesidades de los usuarios. Si el requerimiento
no es verificable, determinar si se implement correctamente.
Para la especificacin de los requerimientos funcionales del sistema se utilizarn
los casos de uso del UML (Unified Modeling Language), lenguaje cuyo estndar es
promovido por el OMG (Object Management Group) y que permite modelar, construir
y documentar los elementos que forman un sistema de informacin, especialmente,
orientado a objetos.
Los casos de uso representan la funcionalidad que ofrece el sistema en lo que se
refiere a su interaccin externa, desde el punto de vista del usuario y especificando
qu respuestas debe ofrecer el sistema a las diversas acciones de los usuarios o, en

general, los agentes externos al sistema.
En esta tarea se elabora el modelo de casos de uso identificando:
Actores y casos de uso.
Descripcin del escenario de cada caso de uso.
Para completar la descripcin del escenario, es preciso especificar el siguiente detalle:
Casos de uso de alto nivel:

Caso de Uso
Actores
Nombre del caso de uso

Lista de actores (agentes externos), indicando quin inicia el caso de
uso. Usualmente son roles, pero puede ser cualquier tipo de sistema
Tipo
Primario:
proceso principal
Secundario: casos de uso menores

Opcionales: proceso que puede no ser tomado en cuenta en el sistema
________________________________________________________
Esencial: definido a nivel abstracto, independiente de la tecnologa y
la implementacin
Descripcin
Real: describe concretamente el proceso en trminos del diseo real.

Muy breve descripcin del caso de uso
Casos de uso expandidos:

Caso de Uso
Actores
Nombre del caso de uso

Lista de actores (agentes externos), indicando quin inicia
el caso de uso. Usualmente son roles, pero puede ser
Propsito
cualquier tipo de sistema

Intencin del caso de uso
Tipo
Primario:
proceso principal
Secundario: casos de uso menores

Opcionales: proceso que puede no ser tomado en cuenta
en el sistema
Esencial:
definido a nivel abstracto, independiente de la
tecnologa y la implementacin
Real:
describe concretamente el proceso en
trminos del diseo real.

Referencias
Casos de uso relacionados
Precondicin
Condiciones dadas antes del proceso
Curso Tpico de Descripcin de la interaccin entre los actores y el sistema
eventos
mediante las acciones numeradas de cada uno (se disponen

en forma columnar) Describe la secuencia ms comn de
eventos, bajo condiciones de normalidad y el proceso se
Poscondicin
Cursos
completa satisfactoriamente.
Condiciones resultantes despus del proceso
Se describe la excepcin al caso normal y se seala el punto
Alternativos
en que se dara.
Los casos de uso se describen en forma detallada en el anexo 14.

a. Requerimientos no funcionales
Son las propiedades y restricciones del sistema, pueden ser de ndole organizacional,
como consecuencia de alguna poltica organizacional o de procedimiento, o pueden
ser de operabilidad como los son: confiabilidad, tiempo de respuesta, almacenamiento,
capacidades de dispositivos de E/S, migracin de herramienta, y conversin de
archivos.
1.2.2. Documento de anlisis

Este documento rene los resultados del proceso de anlisis y ser la base, en conjunto
con la especificacin de requerimientos, para la planificacin de las fases posteriores
en lo referente a la construccin del sistema.
Debe contener, al menos, la siguiente informacin:
a. Identificacin de recursos para desarrollo
Teniendo ahora mayor claridad respecto a lo que el sistema debe resolver y el
trabajo a realizar, se debe ajustar el formulario de recursos del proyecto Identificando
requerimientos de recurso humano, hardware, software, comunicaciones,
ambiente fsico, volumen de datos, materiales, capacitacin y otros recursos que
sern requeridos para el desarrollo del proyecto. Si al ejecutar esta tarea se tiene un
estimado de los recursos requeridos para las etapas de Implantacin y operacin, esto
puede ser descrito en esta tarea, revisado y ajustado ms adelante.
b. Anlisis de requerimientos
Los requerimientos estudiados se analizan para identificar los siguientes elementos de
cada solicitud:
Identificacin del requerimiento: Debe ser una secuencia conformada por
las siglas o cdigo del sistema y un consecutivo que identifique de manera
nica al requerimiento (en el proyecto o sistema actual)
Breve descripcin: Breve descripcin y propsito del requerimiento.
Prioridad: asignada por el Patrocinador o Lder del Proyecto. Se recomienda
utilizar tres valores posibles en concordancia con la priorizacin de
requerimientos, es decir, Alto, Medio y Bajo.
Complejidad: nivel de dificultad para la solucin de lo solicitado. Se
recomienda utilizar tres valores posibles: Alta, Media y Baja.
Tipo de requerimiento: Identificar si se trata de requerimiento funcional o de

un requerimiento no funcional.
Dependencia con otros requerimientos: Hacer referencia a los requerimientos
que estn relacionados y que de alguna manera representan una
dependencia; es decir, que para su atencin se requiera resolver previamente
otros requerimientos o que su atencin es obligatoria para el cumplimiento
de otros aspectos.
Tiempo estimado de construccin: estimacin preliminar del tiempo
requerido para la atencin del requerimiento. Se debe utilizar una unidad
de medida uniforme para cuantificar todos los requerimientos (horas, das,
semanas)
Seguidamente se presenta un ejemplo de la matriz de requerimientos:
ID
Descripcin del req.
Prioridad
Complejidad
Tipo Req.
Dependencia
Das const.
Con esta matriz se puede realizar un anlisis cuantitativo de los requerimientos que
permita identificar aquellos que son crticos para el xito y completitud del proyecto;
adems ofrece un elemento importante para la toma de decisiones por parte del Lder
de Proyecto y Lder Tcnico.
c. Definicin de infraestructura tecnolgica
Se debe detallar la infraestructura computacional que soportar el sistema cuando
est en operacin, a nivel de equipo principal y de usuarios, lenguaje de programacin
y especificacin de la base de datos; y cualquier otro aspecto requerido para el
funcionamiento del sistema. En trminos generales, el tipo de tecnologa a utilizar
dependiendo del tipo de sistema; incluyendo aquella que no est disponible en la CGR
y que se constituye en un riesgo tecnolgico.
d. Cronograma ajustado de las fases posteriores del proyecto

Con mayor claridad de lo que deber desarrollarse se puede ahora ajustar el cronograma
del proyecto para las siguientes etapas, indicando las fechas de inicio y finalizacin
para cada una de ellas as como los responsables de las actividades.
e. Aprobacin de los requerimientos
Se debe realizar una presentacin a la Unidad Ejecutora de los requerimientos
identificados, a efectos de efectuar los ajustes necesarios hasta obtener la aprobacin
por parte de la UE y continuar con la siguiente etapa.
2.
Diseo conceptual de la solucin

2.1.
Consideraciones
Esta fase tiene el propsito de identificar los primeros elementos de diseo del nuevo
sistema. Los insumos principales de esta fase son: el documento de especificacin de
requerimientos y el documento de anlisis.
En la siguiente figura se diagraman las principales actividades de esta fase:
2.2.
Entregables

En lo referente a la fase de diseo conceptual de la solucin para el Desarrollo de un

Sistema de Informacin se identifican los siguientes entregables:
Documento de diseo conceptual: a travs de este documento se presentan
los resultados de la primera actividad de diseo como la descripcin general
de procesos, identificacin de relaciones de integracin de sistemas, la
identificacin de usuarios y roles. Tiene el propsito de mostrar, de manera
general, cmo estar constituido el nuevo sistema y ser la base, en
conjunto con la especificacin de requerimientos, para el diseo detallado
del sistema.
2.2.1. Documento de diseo conceptual
Este documento deber contener, al menos, la siguiente informacin:
a. Identificacin de mdulos
Un mdulo es una parte o divisin del sistema. Consiste en agrupar funcionalidad que
est relacionada y que soporta un eje o situacin especfica del negocio sobre la cual
se est desarrollando el proyecto.
b. Descripcin de mdulos y sub-mdulos y su interaccin
Con base en el diseo conceptual de la solucin, se detalla la estructura modular
del sistema en cuanto a la jerarqua de los mdulos y la forma en la que interactan.
Adems de la descripcin de los mdulos se debe confeccionar el diagrama de contexto
y el diagrama de flujo de datos. El diagrama de contexto establece las relaciones que
el mdulo tiene con otros sistemas, otros mdulos o entidades externas. El diagrama
de flujo de datos es la representacin grfica de las entradas, procesos y salidas de un
mdulo mostrando la interrelacin de los procesos.
c. Identificacin de interrelaciones con otros sistemas o mdulos

Se refiere a la identificacin de sistemas o mdulos que estarn relacionados con el
sistema en construccin y la descripcin de estas relaciones en lo referente al tipo y
mtodo de comunicacin. Adems, se debe indicar si es requerida la modificacin de
algn sistema existente para ajustarlo a la solucin que se est diseando.
En esta actividad es importante que se analice la estructura de datos existente en los
sistemas que estarn relacionados para la creacin de un modelo lgico de datos en
la siguiente fase.
d. Identificar tipos de usuarios
Identificar los tipos de usuarios y el rol a cumplir por ellos dentro del sistema,
especificndose quines pueden ingresar, modificar, borrar o consultar informacin
y cul informacin. Qu tipos de usuarios utilizan cada uno de los mdulos y qu
funciones lleva a cabo.
3.
Diseo detallado de la aplicacin

3.1.
Consideraciones
El diseo detallado de la solucin establece, con mayor detalle, las caractersticas

que tendr el nuevo sistema. Adems, ser la base para la fase de construccin o
programacin de los mdulos.
La base de informacin para las actividades del diseo detallado son los documentos
de especificacin de requerimientos, documento de anlisis y diseo conceptual.
El documento de diseo detallado debe especificar los mdulos que tendr el
sistema, caractersticas de validacin y restricciones sobre los elementos de datos,
especificacin de procesos, detalle de controles y seguridad, caractersticas de la
interfaz de usuario y principales reportes que ofrecer el sistema. Todos estos aspectos
sern identificados con base en los requerimientos funcionales del proyecto y, de ser
necesario, de las consultas efectuadas a los usuarios, Lder de Proyecto o contraparte
y Patrocinador del proyecto.
En la siguiente figura se muestra el esquema funcional de esta etapa en la construccin
de sistemas:
El diseo detallado de la aplicacin ser revisado y aprobado por la Jefatura de la USTI

o por quien ste designe para comprobar que el desarrollo propuesto est dentro de
los estndares de la Unidad y que es consistente con la planificacin de crecimiento
tecnolgico de la Institucin. Dicha revisin debe ser consignada como visto bueno
del documento.
3.2.
Entregables

En lo referente a la fase de diseo detallado para el Desarrollo de un Sistema de
Informacin se identifican los siguientes entregables:
Documento de diseo detallado: se refiere al documento donde se describen,
con ms detalle los elementos del nuevo sistema como descripcin de
mdulos, modelado de datos, procesos, controles de acceso y seguridad,
interfaz de usuario y reportes.
Diseo de pruebas: se refiere a un documento donde se estipulan los
aspectos a considerar en el proceso de pruebas, con el propsito de contar
con el suficiente tiempo para su planificacin.
3.2.1. Documento de diseo detallado
Este documento deber contener, al menos, la siguiente informacin:
a. Descripcin de procesos
Consiste en desagregar los mdulos identificados en el diseo conceptual y describir
las entradas, los procesos y las salidas que considera el sistema de acuerdo con el
estndar fijado. Para la realizacin de esta actividad se utilizar la herramienta de
software aprobada por la USTI.
b. Diagrama lgico del modelo de datos
Especificacin del modelo entidad-relacin del sistema, de la composicin fsica que
tendrn las tablas relacionales y su normalizacin. Este modelo debe ser validado por
el DBA.
c. Definiciones de dominios para los datos

Se refiere a la especificacin de aspectos como:
Formato
Valor que asume por defecto
Rango de valores permisibles
Listas de valores
Mensajes informativos sobre los elementos
Adems se deben especificar las restricciones a nivel de bases de datos.
d. Estimacin del volumen de datos
Estimacin de la cantidad de registros que se ingresaran para cada tabla definida en el
modelo de datos lo cual se debe realizar con el apoyo del Administrador de las Bases
de Datos de acuerdo con el estndar respectivo.
e. Definicin de controles y seguridad a utilizar
Definir los puntos de control que garanticen la seguridad, integridad y confidencialidad
de la informacin a nivel de roles en la base de datos y control de acceso a las
transacciones en la aplicacin. Se deben identificar los tipos de eventos que debern
dejar registros de auditoria, bitcoras y otros controles que se establezcan en la
definicin de estndares para el desarrollo de sistemas.
f. Disear la interfaz de usuario
Establecer la apariencia de las pantallas con base en los estndares establecidos.
Definir la estructuracin del men y los roles de usuario que tendrn acceso a cada
opcin del sistema.
g. Organizacin para la operacin del sistema

Identificar y definir los requerimientos operativos a nivel del ambiente administrativo
donde se implantara el nuevo sistema.
Podran plantearse cambios en los
procedimientos actuales, necesidades de reubicar o de obtener nuevo personal,

cambios en los flujos de la informacin en los puntos de control de la misma.
3.2.2. Diseo de pruebas:
Con la finalidad de guiar el proceso de pruebas y realizar las tareas correspondientes
para esta actividad con la debida anticipacin, se debe efectuar un diseo de pruebas
basado en casos de uso y orientadas a:
Asegurar que el producto cumple con lo solicitado por los usuarios
Certificar que el aplicativo funciona correcta y eficientemente
El documento de diseo de pruebas debe contener los siguientes aspectos:
a. Especificacin de tipos de pruebas
Identificar los tipos de pruebas a realizar: pruebas unitarias, pruebas de mdulos,
pruebas de integracin, pruebas de esfuerzo, tiempos de respuesta y trfico en la
infraestructura de comunicaciones.
Pruebas unitarias: son las pruebas que se realizan a cada programa del
sistema
Pruebas de mdulos: pruebas que se aplicarn a los mdulos o partes
funcionales del sistema, incluye a todos los programas del mdulo.
Pruebas de integracin: pruebas totales del sistema y de su integracin con
otros sistemas, incluye todos los programas.
Pruebas de esfuerzo: comprobacin de recursos computacionales para
soportar la aplicacin (servidor de bases de datos, servidor Web, recursos
de las mquinas de usuario, red)
Tiempo de respuesta: verificacin de que el tiempo de respuesta es aceptable

de acuerdo con los estndares de la industria
Trfico en la infraestructura de comunicaciones: comprobacin de capacidad
de transmisin de datos (ancho de banda) para la operacin del sistema
b. Requerimientos para las pruebas
La plataforma de Hardware, Software, conectividad y base de datos requerida. Si
el sistema tendr integracin con otros sistemas o mdulos deber disponerse de un
ambiente de pruebas de dichos sistemas.
c. Casos y datos de prueba
Identificar todos los escenarios posibles con diversidad de datos de entrada y acciones
realizadas por el usuario, con el propsito de identificar posibles puntos de error en el
sistema.
Si se requiere la existencia de datos para la pruebas, se deber sealar el mtodo de
captura de stos en las estructuras de la base de datos.
d. Usuarios para las pruebas
Determinar las caractersticas y cantidad de los usuarios que sern requeridos en el
proceso de pruebas y el tiempo a invertir en dicho proceso. Esto es importante para
que las Unidades puedan efectuar la coordinacin correspondiente con la debida
anticipacin.
4.
Programacin y pruebas
4.1.
Consideraciones
En esta fase se confeccionan los programas y se realizan las pruebas a partir de los
documentos de requerimientos, casos de uso, especificacin de programas, anlisis y
diseo. Como producto se tendrn los componentes de programacin, una constancia
de pruebas y de aceptacin del producto.
En la siguiente figura se muestra el flujo de procesos esperado en esta fase donde
es posible que se deban realizar ajustes en la programacin para cumplir con las
especificaciones del usuario:
Diseo detallado
Construccin
Construccin
Ajustes
Ajustes
Pruebas
Pruebas
Aceptacin
Aceptacin
Implementacin
Figura No. 5: Construccin y pruebas
4.2.
Entregables

En lo referente a la fase de programacin para el Desarrollo de un Sistema de
Scripts de creacin de objetos en la BD: para la creacin de tablas, llaves
primarias y forneas, ndices, constraints, roles, usuarios y cualquier otro
componente de la base de datos.
Componentes de programacin: elementos de programacin como menes,
formas, reportes, procedimientos y funciones almacenados en la base de
datos, triggers de bases de datos y cualquier otro componente del nuevo
sistema.
Constancia de pruebas: documentacin de las pruebas donde se indiquen
los resultados obtenidos y los ajustes a realizar.
Aceptacin del sistema: nota del Lder del Proyecto donde se exprese que el
nuevo sistema cumple satisfactoriamente con lo solicitado y que se pueda
continuar con las actividades de capacitacin e implementacin.
4.2.1. Desarrollo o Construccin
a. Implementacin del modelo fsico de datos
Escribir las rutinas (scripts) para la creacin de objetos en la base de datos de acuerdo
con el modelo entidad relacin, especificando llaves primarias y llaves forneas.
Cuando el DBA reciba los scripts los completar con los parmetros de almacenamiento
adecuados de acuerdo con el tamao de los registros y de las tablas.
Estos scripts debern ser revisados por el Administrador de Bases de Datos y aplicados
en conjunto.
b. Creacin de roles y de usuarios

Se crean los roles y se asocian a los usuarios que se definan, segn las acciones que
les correspondan. Se debe implementar la seguridad en la base de datos.
c. Programacin
Durante el desarrollo de esta etapa se generan los programas que componen el
Sistema de Informacin.
Conforme se avanza en la programacin se debe documentar cada uno de los
componentes desarrollados de acuerdo con el estndar definido.
Adicionalmente, el desarrollador debe adoptar los estndares establecidos en la
nomenclatura, el manejo de versiones, y la documentacin de los programas que
establece el manual de estndares.
d. Conversin y levantamiento de datos
En caso de requerirse una migracin de datos desde una aplicacin anterior o bien
desde un ingreso masivo de informacin, se debe tomar en cuenta la depuracin
que requiera esta informacin. El Lder de Proyecto deber considerar este traspaso
como un subproyecto adicional, donde incluir los requerimientos de recurso
humano y tecnolgico para su ejecucin, asimismo deber negociar estos recursos.
Esta conversin o ingreso masivo de informacin se ejecutar durante la etapa de
implantacin.
Cada uno de los mdulos generados deber estar sujeto
a una revisin de su
funcionalidad por parte del Lder de Proyecto o quien l designe y a una revisin de
tipo tcnico para garantizar su calidad.
4.2.2. Pruebas
a. Preparacin y levantamiento de informacin para las pruebas
Se debe retomar el documento de diseo de pruebas para comprobar que est acorde
con las caractersticas del sistema y que est vigente en cuanto a los casos de prueba
a realizar y a la definicin de usuarios que van a participar en este proceso. De ser
necesario se realizar la generacin de datos para las pruebas de los mdulos.
b. Ejecucin de pruebas especficas
Se debe probar el funcionamiento (cumplimiento de los requerimientos), facilidad de
uso por el usuario (interfaz con el usuario), dilogos con el usuario y su control, para
cada pantalla con la que debe interactuar el usuario.
c. Ejecucin de pruebas por el usuario final
Esta actividad requiere que se pruebe la operacin integral de todos los componentes
del sistema y su interaccin con otros sistemas, de manera que se asegure el
cumplimiento de los requerimientos de integracin especificados. Estas pruebas
deben ser realizadas por el usuario final con al apoyo y colaboracin del equipo de
desarrollo.
d. Documentacin de los resultados de las pruebas
Generar la documentacin que corresponda para dejar constancia de los resultados
del proceso de pruebas, incluyendo los casos en donde stos no fueron satisfactorios,
lo cual implica ajustes a los programas y la aplicacin de las pruebas correspondientes.
Es importante que quede documentado quines y cundo realizaron las pruebas, as
como sus observaciones.
4.2.3. Ajustes de programacin

Si en la realizacin de pruebas se identifica la necesidad de efectuar ajustes en la
programacin, despus de llevarlos a cabo se deben realizar las pruebas especficas y
de integracin de manera interactiva con los usuarios; de tal forma que al finalizar las
modificaciones se realicen las pruebas correspondientes para que el sistema concluya
satisfactoriamente. Se debe actualizar la documentacin de los programas con base a
las modificaciones realizadas.
4.2.4. Aceptacin del sistema

Una vez concluido el proceso de pruebas y los ajustes a la programacin, el Patrocinador
del proyecto debe emitir una nota dirigida a la Jefatura de la USTI, mediante la cual
manifiesta que est satisfecho con el sistema dndolo por aceptado y autorizando a
que se proceda con su implementacin.
5.
Documentacin
5.1.
Consideraciones
La documentacin del sistema se genera durante el desarrollo de todas las fases del
proyecto; sin embargo, hay un conjunto de documentos especficos a generar: manual
de usuario, manual de operacin y manual tcnico.
La documentacin del proyecto se debe mantener actualizada en todo momento y
formar parte de un expediente o archivo por proyecto donde todos los documentos
producidos estn reunidos.
5.2.
Entregables

En lo referente a la fase de documentacin para el Desarrollo de un Sistema de
Manual de usuario: gua para la utilizacin del sistema por los usuarios.
Manual tcnico: descripcin, a nivel tcnico, de todos los componentes del
sistema.
Manual de operacin: descripcin de procesos operativos del sistema.
5.2.1. Documentacin del proyecto
Son todos los documentos generados e identificados como entregables, en cada una
de las fases, y que deben formar parte del archivo del proyecto:
Documentos de organizacin del proyecto
Cronograma original
Cronograma ajustado
Correspondencia generada
Solicitud para el desarrollo de un sistema de informacin
Memorando de solicitud
Informe de diagnstico
Memorando de resultado del estudio
Seleccin de la solucin
Solicitud formal del proyecto
Anlisis integral de requerimientos
Especificacin de requerimientos
Priorizacin de requerimientos
Documento de anlisis
Diseo conceptual de la solucin
Documento conceptual de la solucin
Diseo detallado de la aplicacin
Documento de diseo detallado
Diseo de pruebas
Programacin y pruebas
Scripts de creacin de objetos
Inventario de componentes de programacin
Constancia de pruebas
Aceptacin del sistema
Capacitacin
Constancia de la capacitacin
Implementacin
Plan de implementacin
Aprobacin del inicio de operacin
Entrega del sistema
Manual de usuario
Manual tcnico
Manual de operacin
5.2.2. Manual de usuario
El manual del usuario debe ser conciso y prctico, sin dejar de ser exhaustivo,
de manera que los usuarios encuentren en l toda la informacin necesaria para
interactuar con el sistema. Se debe combinar la descripcin textual, con la grfica, de
manera que al usuario se le facilite su uso.
El manual debe contener lo siguiente:
Introduccin
Estndares del Sistema
Requerimientos tecnolgicos
Cmo se ingresa al Sistema
Descripcin del Men Principal del Sistema
Descripcin textual y grfica de cada pantalla (sea de registro o consulta)
Descripcin del uso e impresin de reportes
Cmo y a quin reportar errores del sistema
5.2.3. Manual tcnico

En este manual se deben describir, de manera detallada, todos los componentes del
sistema desde el punto de vista tcnico. En dicha documentacin deben explicarse
todos los aspectos necesarios para el posterior mantenimiento de la aplicacin.
5.2.4. Manual de operacin
Manual donde se describan todas las actividades operativas del sistema como
creacin de usuarios, procedimientos de respaldo y recuperacin, procesos diarios o
peridicos, generacin de datos para otros sistemas o entidades y la descripcin de
cualquier otro proceso.
6.
Capacitacin
6.1.
Consideraciones
De acuerdo con la complejidad en el uso del sistema desarrollado y de la cantidad

de usuarios del sistema, se debe coordinar con el Centrro de Capacitacin y con
la Unidad de Recursos Humanos el lugar, hora y la cantidad de sesiones que va
a comprender la capacitacin. En caso de ser necesario se coordinar el uso del
laboratorio de microcomputadoras de manera que la capacitacin se lleve por medio
de una interaccin total sistema-usuario.
7.
Implementacin
7.1.
Consideraciones
El Lder de Proyecto, siguiendo criterios de impacto, materialidad, riesgo asociado,

sensibilidad y criticidad de la informacin involucrada, deber considerar el tipo de
pruebas adicionales que requiera el proyecto, logrando un adecuado balance costo/
beneficio. Entre otras podr considerar pruebas en paralelo cuyo objetivo ser verificar
que el sistema nuevo genera resultados similares al sistema que estuviera en ese
momento en funcionamiento manual o automatizado-, pruebas de esfuerzo cuyo
objetivo es poner a prueba el sistema y la plataforma frente a una fuerte demanda
de los servicios. Estas pruebas pueden ser reales o simuladas, dependiendo de la
disponibilidad de recursos humanos y tecnolgicos.
El proceso se muestra en la siguiente figura:
7.2.
Entregables

En lo referente a la fase de implementacin para el Desarrollo de un Sistema de

Plan de implementacin: breve documento donde se describen las
actividades a realizar para la implementacin del sistema, desde el punto
de vista tcnico y organizacional.
Aprobacin del inicio de operacin: nota o acta del Patrocinador donde
autoriza el inicio de operacin en produccin del sistema en vista de que
fueron cumplidos todos los requerimientos funcionales y no funcionales.
Entrega del sistema: notificacin a los usuarios y a la , administracin en
general (si fuese necesario), de la culminacin del proyecto y sobre la fecha
del inicio de operacin del sistema.
7.2.1. Plan de implementacin
De acuerdo con la complejidad del sistema se debe generar un plan de implementacin
que incluya la calendarizacin de actividades, la ejecucin de pruebas en paralelo,
pruebas de esfuerzo y el traslado al ambiente de produccin.
a. Estrategia de implementacin
Definicin del mtodo de implementacin ms adecuado para el proyecto donde se
considera si se realiza un paralelo o no, mtodo de carga de datos a utilizar y cualquier
otra decisin estratgica para la finalizacin exitosa del proyecto. Esta estrategia debe
ser acordada con el Patrocinador del proyecto, el Lder del proyecto, el Lder Tcnico
y la Jefatura de la USTI.
b. Calendarizacin de actividades
Se refiere a un cronograma especfico para esta etapa. Se deben revisar las actividades,
recursos y tiempos programados en la planificacin inicial del proyecto para hacer las
modificaciones que se requieran. Estas modificaciones deben ser del conocimiento
del Patrocinador del proyecto, de la Jefatura de la USTI, de los usuarios y de los

analistas.
7.2.2. Instalacin del sistema
Las actividades a realizar son las siguientes:
Preparar los aspectos relacionados con el ambiente fsico y computacional
para dar inicio con la operacin del sistema
Para lo anterior y de acuerdo a las caractersticas del sistema, se recomienda lo
siguiente:
Activar los componentes de seguridad de acceso al sistema: identificacin
de usuarios, palabras de paso y atributos de usuario (roles), con la finalidad
de garantizar que el ingreso al sistema en operacin se realizar de forma
segura.
Verificar que los requerimientos de hardware, de software y de
comunicaciones se encuentran disponibles.
Verificar que se tenga el mobiliario, la instalacin elctrica (toma corrientes,
conexin a tierra, protectores de picos) y el espacio fsico necesario y
acondicionado para su operacin.
Verificar que los materiales que use el sistema se encuentren disponibles.
Por ejemplo formularios especiales, papelera, cintas para impresora,
medios de almacenamiento de datos y vdeos, cobertores para el equipo,
as como todos los otros materiales requeridos.
Realizar la instalacin del sistema en el ambiente de produccin en
coordinacin con el DBA.
7.2.3. Conversin y carga inicial automatizada de datos

En caso de requerirse una migracin de datos desde una aplicacin anterior o bien
mediante el ingreso masivo de informacin, el Lder de Proyecto deber considerar
este traspaso como un subproyecto, donde incluir los requerimientos de recurso
humano y tecnolgico para su ejecucin y sus respectivos controles de calidad y
completitud.
Confirmar que el ambiente computacional (software, hardware) y
personal, requerido para la carga o digitacin de los datos al sistema, se
encuentre disponible, segn lo indicado en el plan. De lo contrario, realizar
los ajustes necesarios para asegurar que la carga de los datos iniciales se
haga en una forma satisfactoria.
Ejecutar las aplicaciones desarrolladas para la conversin y carga inicial de
los datos al sistema.
Es recomendable realizar una depuracin de los datos por convertir, para
asegurar que no se incluyan datos errneos al sistema.
Verificar que los datos introducidos se encuentren correctos y completos.
Comprobacin por parte del Lder del Proyecto y del analista responsable,
que la conversin y carga de datos se realiz en una forma satisfactoria.
7.2.4. Ejecucin del paralelo
Justificar la necesidad de ejecucin de un procesamiento en paralelo. Esta decisin
la toma el Lder de Proyecto, considerando las caractersticas e impacto del sistema.
Determinar la duracin y forma en que se realizar el paralelo, de acuerdo
con la naturaleza y complejidad del sistema.
Determinar las funciones y responsabilidades del personal tcnico y del

usuario que participa en el paralelo.
Establecer los criterios de aceptacin esperados para evaluar los resultados
que se tengan al final de la ejecucin del paralelo.
Iniciar el paralelo brindando asistencia al usuario en forma continua, para
asegurar que los procedimientos se realizan en la forma correcta. Asimismo,
identificar y corregir los problemas que se presenten.
Documentar los resultados de la ejecucin del paralelo, considerando
los criterios de evaluacin establecidos. Indicar el criterio de aceptacin
considerado y el nombre de la persona que aprueba.
Dar un visto bueno, por parte del Lder del Proyecto, haciendo constar que
el paralelo se concluy en forma satisfactoria.
7.2.5. Aprobacin formal del sistema para el inicio de su operacin.
Esta aprobacin la hace el Patrocinador, mediante un acta de aceptacin y puesta en
operacin del sistema.
Aqu se confirma que el sistema terminado cumple con los requisitos acordados y que
puede ser puesto en produccin.
7.2.6. Hacer la entrega del sistema al usuario.
El Patrocinador y el Jefe de la USTI notificarn formalmente acerca de la puesta en
operacin del sistema desarrollado
7.2.7. Hacer la entrega de programas fuente
Cuando el sistema cuenta con la aceptacin del Patrocinador o el Lder de Proyecto
y ya est instalado en los equipo de produccin, se debe entregar para su custodia,
todos los programas, fuente en su versin final, generados en el desarrollo del sistema.
Estos programas deben ir acompaados de la documentacin especificada en el
procedimiento. Adems se debe depurar el inventario de programas de manera tal que

solo se haga entrega de los que realmente se requieren para la operacin del sistema
(borrar los programas temporales o transitorios, versiones de prueba y cualquier otro
programa que no es definitivo).
8.
Evaluacin post-implantacin
Es necesario establecer el tiempo necesario (de una semana a 3 meses segn el

tamao del sistema), para que se realice una evaluacin durante su operacin, y para
que se hagan los ajustes necesarios, de manera que se satisfagan los requerimientos
previamente establecidos.
Esta etapa supone la realizacin de una sesin con el equipo de proyecto para discutir
las lecciones aprendidas en el proceso de desarrollo e implantacin, de donde incluso
pueden derivarse mejoras a ser incorporadas a esta Gua Metodolgica de acuerdo al
proceso establecido para su actualizacin. Adicionalmente se generar una rendicin
de cuentas final y la relacin costo/beneficio efectiva del proyecto.
Anexo 5.
Mantenimiento de sistemas.
1. Mantenimiento de sistemas
Para el mantenimiento de un sistema se tiene que elaborar la solicitud de modificacin
por escrito por parte del usuario administrador del sistema. Para ello la USTI tiene
definido un estndar de formulario para control de cambios que el interesado deber
llenar y enviar para su respectivo trmite.
Una vez aprobado el ajuste con base a lo establecido por el procedimiento de control
de cambios, se conforma el equipo de trabajo para el desarrollo correspondiente,
dndole tratamiento como un proyecto normal, ajustando todo al tamao y condiciones
del trabajo a realizar.
Durante la ejecucin del trabajo de mantenimiento se debern cumplir las siguientes
fases:
1.1.
Planificacin del trabajo de mantenimiento
Es necesario que se asignen los recursos necesarios (humanos, tcnicos, y materiales),

as como establecer un calendario de seguimiento: fechas de reunin con los usuarios
y fechas de validacin con el Patrocinador.
Para llevar a cabo el mantenimiento se debe hacer una lista con las actividades por
medio de las cuales ste se realizar. Con esta lista de actividades, se determinar
si es necesario formular un cronograma para esta etapa, o simplemente efectuar un
acuerdo entre el Lder de Proyecto y el Lder Tcnico sobre cmo se realizar, y cul
ser el alcance que tendr.
1.2.
Especificacin de los nuevos requerimientos
En la misma forma en que fueron especificados en la fase de anlisis de requerimientos,

deben ser especificadas las nuevas necesidades. Podra ser que obedezcan a
solicitudes que anteriormente tuvieran muy baja prioridad, por lo que no se les tom
en cuenta en esa oportunidad. De ser as debe quedar claro en el nuevo listado.
Para especificarlos debe existir una sesin de trabajo, en la cual el Lder Tcnico deje
claro qu se puede atender y qu no, de manera que todos los requerimientos que
sean viables se implementen en el mantenimiento, con el visto bueno del Lder de
proyecto.
1.3.
Ajustes en programacin y pruebas
Realizar los ajustes correspondientes a la programacin y a la base de datos si fuera

necesario, para dar cumplimiento a lo solicitado. Adems, se debe valorar el tipo de
pruebas a realizar (pruebas funcionales y pruebas de integracin) segn el impacto de
los nuevos requerimientos en el sistema. Es importante que se asegure que las pruebas
aplicadas cubren todos los aspectos afectados por las recientes modificaciones en el
sistema para asegurar la estabilidad de la aplicacin.
1.4.
Actualizacin de la documentacin y de los programas fuente
Realizar los ajustes que correspondan en la documentacin del sistema, en el manual

de usuario, en el manual de operacin y en el manual tcnico, con la finalidad de que
dichos documentos se mantengan vigentes en todo momento. Los cambios realizados
en la programacin y la base de datos deben manejarse como versiones de acuerdo
con lo establecido en el estndar respectivo.
1.5.
Capacitacin
Dependiendo del tipo de ajuste realizado, se ver la conveniencia de comunicarlos

por medio de un correo o una pequea charla. De lo contrario se deber efectuar una
capacitacin de acuerdo a lo estipulado en la presente metodologa referente a este
tema.
1.6.
Implementacin de los cambios
Con todos los ajustes aprobados y efectuada la capacitacin, se realizarn los ajustes
necesarios en el equipo de produccin (tanto en el equipo principal como en el equipo
perifrico, segn corresponda), implementando el sistema actualizado, de acuerdo
con los estndares definidos.
1.7.
Evaluacin post-implantacin
Dependiendo del tipo de ajuste realizado, se deber realizar una etapa de postimplantacin, segn lo establecido en esta Gua.
Anexo 6.
Formulario para documentacin de las reuniones del proyecto.

Proyecto: <<Nombre del proyecto>>
Memoria de Reunin No. XX-AO
Divisin/rea:
Lugar:
Elaborado por:
Fecha:
Hora inicio:
Hora finalizacin:
ASISTENCIA:
Invitado
Dependencia
Pre
Aus
ASUNTOS PENDIENTES Y SEGUIMIENTO DE ACUERDOS:

Asunto
Responsable
Grado de avance / Finalizacin

prevista
ASUNTOS TRATADOS:
Asuntos tratados
1)
2)
Comentarios Generales
ACUERDOS:
Acuerdos
1)
2)
3)
Responsable (s)
F e c h a
prevista
Anexo 7.
Ficha de Anteproyecto.
FICHA DE ANTEPROYECTO
Nombre del Proyecto ________________________________________________________
Resultado esperado
_________________________________________________________
_________________________________________________________
Efecto
_________________________________________________________
_________________________________________________________
Objetivo
_________________________________________________________
_________________________________________________________
Productos
_________________________________________________________
_________________________________________________________
Enfoque
_________________________________________________________
_________________________________________________________
Alcance
_________________________________________________________
_________________________________________________________
Relaciones de
Coordinacin
_________________________________________________________
Responsable
_________________________________________________________
Prioridad
_________________________________________________________
Requerimientos
Iniciales
_________________________________________________________
_________________________________________________________
Fecha de inicio:
______________
Fecha de finalizacin: _______________________
Elaborado por: ___________________________________ Fecha:_____________________

Explicacin Detallada
Nombre del proyecto:
Es el ttulo o enunciado que identifica al proyecto. Las principales caractersticas deseables al definir el nombre del proyecto son:
Identificar la naturaleza del proyecto.

Ubicar el contexto en el que se desarrollar.
Debe ser conciso.
Resultado esperado:
Deben establecerse los resultados esperados en los campos de accin de la Contralora
que aparecen en la estrategia institucional, con los cuales se considere que el proyecto
contribuye.
En este apartado debe anotarse tanto la numeracin como el resultado esperado tal y
como se consignan en el documento de la Estrategia Institucional. Lo anterior con el
objeto de interrelacionar ordenadamente la planificacin con la estrategia institucional.
En el caso de existir contribucin directa con ms de un resultado esperado, stos
deben incluirse respetando un criterio de mayor a menor contribucin.
Efecto:
Para que un proyecto sea viable dentro de la CGR, el mismo debe aportar un valor
agregado a la misma, o sea que el mismo coadyuve a que la organizacin cumpla sus
fines y objetivos. En estos trminos se deben aportar los razonamientos que muestren
como el proyecto ayudar a que la CGR sea ms eficiente y productiva. Un proyecto
que no se pueda justificar en los trminos anteriores, simplemente no se debe realizar.
Objetivo:
Es el nivel de desempeo que se debe lograr para satisfacer una necesidad determinada.
Los objetivos deben tener una relacin directa con dicha necesidad, y es conveniente
que se estructuren segn los siguientes componentes:
Escala de medicin: La variable que indica la magnitud o avance del
objetivo, como pueden ser el porcentaje o el volumen.
Horizonte de tiempo: El periodo definido para lograr la consecucin del
objetivo, por ejemplo en seis meses.
El para qu: cuando sea necesario se puede indicar para qu se quiere

alcanzar el objetivo, lo cual est en funcin de la necesidad que se desea
satisfacer, de manera que el lector perciba expresamente esa necesidad
an cuando no tenga conocimiento en la materia.
Segn sea el caso puede definir un objetivo general y varios objetivos especficos.
Productos:
Los resultados inmediatos del proyecto que propiciarn el alcance del objetivo.
Enfoque:
Determina la(s) caracterstica(s) u orientacin particular con que se quiere desarrollar
el proyecto. Por ejemplo: participativo, consensuado, externalizacin, fiscalizacin
horizontal o unilateral.
Alcance:
mbito de accin propio del proyecto.
Relaciones de coordinacin:
Definen la interaccin del proyecto, definiendo en principio lo que se requiere
para su desarrollo (identifica proveedores), y lo que debe aportar a otras unidades
organizacionales o a otros proyectos (identifica clientes). En primer lugar se establecen
los clientes del proyecto, que llevan al producto deseado, lo cual conduce a los
proveedores que suministran los recursos para obtener los productos. En este aparte
se debe definir el rol que asume cada uno de los involucrados en el proyecto.
Responsable:
Unidad patrocinadora a la que se le asignar la responsabilidad de administrar el
proyecto, y en consecuencia la que debe rendir cuentas por el logro de los objetivos
planteados.
Prioridad:
El grado de urgencia del asunto. Debe estar relacionado con el impacto de los productos
y con la disponibilidad de tiempo para la ejecucin. Se define en funcin del tiempo
con que se cuenta para tener los productos y de su impacto.
Requerimientos iniciales:
Indican en forma general los aspectos o acciones necesarias que deben desarrollarse
en el proyecto, con el propsito de que ste brinde los efectos y resultados esperados.
Dichos requerimientos deben analizarse segn los componentes del modelo gerencial
de esta Contralora General: Procesos Internos, Recursos Humanos y Sistemas de
Informacin.
Fecha de inicio y de finalizacin del proyecto:

Se establecen fechas de inicio y fin propuestas que enmarquen el proyecto dentro de
un tiempo especfico; estas fechas deben ser de comn acuerdo con todas las reas
involucradas.
Podran estar determinadas por un periodo previamente asignado,
negociado, establecido por ley o se puede partir del hecho de que la administracin
requiere que el proyecto est para determinada fecha, en cumplimiento de objetivos
estratgicos.
Es muy importante para efectos de planeacin, realizar un estimado de la duracin
del proyecto; ya que las diferentes reas involucradas debern aportar los recursos
que sean necesarios para que la duracin del proyecto se cumpla. Los supuestos
en que se basa la estimacin de tiempos resultan fundamentales a efecto de crear
expectativas realistas y acordes con los recursos y alcances esperados.
Elaborado por:
En este campo se debe consignar el nombre del funcionario que est promoviendo en
su etapa inicial el proyecto.
Fecha:
Este campo almacenar la fecha en que se elabor el documento.
Anexo 8.
DESCRIPTIVO DE LA ORGANIZACIN DEL PROYECTO

PROYECTO:
Nombre del proyecto
Cdigo de Proyecto: _____________

Siglas:
_____________
Objetivo
_________________________________________________________
_________________________________________________________
_________________________________________________________
Lder de Proyecto:
_________________________________________________________
Lder Tcnico:
_________________________________________________________
Integrantes del equipo de trabajo
Nombre
______________________________________
______________________________________
______________________________________
______________________________________
______________________________________
Unidad
_____________________________
_____________________________
_____________________________
_____________________________
_____________________________
Integrantes del equipo de apoyo tcnico

Nombre
______________________________________
______________________________________
______________________________________
Unidad
_____________________________
_____________________________
_____________________________
Patrocinador(es) del Proyecto

Nombre
Puesto
________________________________________________ ____________________
________________________________________________ ____________________
________________________________________________ ____________________
Elaborado por: ___________________________________ Fecha : ____________________
Explicacin Detallada.
Nombre del Proyecto:
Es el ttulo o enunciado que identifica al proyecto. Las principales caractersticas
deseables al definir el nombre del proyecto son:
Identificar la naturaleza del proyecto.
Ubica el contexto en el que se desarrollar.
Debe ser conciso.
Cdigo de Proyecto:
Para efectos prcticos y con el fin de mejorar aspectos de documentacin y archivo,
todo sistema ser conocido por un cdigo asignado tomando como referencia el
nmero de gestin y proceso que tendr el proyecto en el Sistema de Gestin y
Documentos (SIGYD). Con dicho nmero se podr entonces revisar en el SIGYD toda
la correspondencia asociada, el detalle del equipo de trabajo, fechas importantes y las
horas dedicadas.
Por ejemplo: 2008000123-5.
Siglas:
Se deben consignar las siglas que la USTI le asigne al proyecto.
Lder de Proyecto y Lder Tcnico:

Nombres del lder de proyecto y del lder tcnico designados.
Integrantes del equipo de trabajo y del equipo de apoyo tcnico:

Se indicar en cada lnea el nombre y la unidad de la persona que integrar cada uno
de estos equipos. Para definir cada equipo deber coordinarse con las respectivas
reas involucradas para que asignen a cada recurso con el tiempo suficiente para
atender las tareas propias de su participacin en el proyecto.
Patrocinadores del proyecto:

Todo proyecto debe tener uno o varios patrocinadores. Estos sern funcionarios que
no solo apoyan el proyecto sino que se involucran directamente en l. Por lo general
sern funcionarios ubicados en las ms altas posiciones de mando de la organizacin,

que no solo pedirn cuenta sobre el avance del mismo, sino que se encargaran de
nivelar cualquier obstculo que amenace al proyecto, y que promovern el mismo
ante las altas esferas de la CGR.
Elaborado por:
En este campo se debe consignar el nombre del funcionario que est promoviendo en
su etapa inicial el proyecto.
Fecha:
Este campo almacenar la fecha en que se elabor el documento.
Anexo 9.
Ficha de Estrategia de Solucin del proyecto.

ESTRATEGIA DE SOLUCION
PROYECTO:
Nombre del proyecto
Cdigo de Proyecto: _____________

Siglas:
_____________
Estrategia de solucin para el proyecto:

_________________________________________________________
_________________________________________________________
_________________________________________________________
Aprobado por: ___________________________________ Fecha: ____________________
Explicacin Detallada.

Es el ttulo o enunciado que identifica al proyecto.
Cdigo de Proyecto:
Cdigo asignado tomando como referencia el nmero de gestin y proceso que tendr
el proyecto en el Sistema de Gestin y Documentos (SIGYD).
Siglas:
Estrategia de solucin para el proyecto:

Se detalla la estrategia de solucin que la Unidad Ejecutora eligi para el proyecto.
Aprobado por:
Es el nombre del coordinador de la Unidad Ejecutora.
Fecha:
Fecha en que se emite el documento.
Anexo 10.
Formulario para la Planeacin de Recursos.
PLANEACION DE RECURSOS
Nombre del proyecto: ___________________________________________________
Cdigo de proyecto: ________
Siglas:
_________
Recursos Requeridos
_________________________________________________________
Humanos:
____________
________________________________________________________________________
__________________________________________________________________
Tecnolgicos:
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
Materiales:
________________________________________________________________________
________________________________________________________________________
__________________________________________________________________
Financieros:
________________________________________________________________________
________________________________________________________________________
__________________________________________________________________
Elaborado por: ____________________________________ Fecha: ____________
Explicacin detallada.

En este campo se debe consignar el nombre con que ha venido siendo conocido el
proyecto.
Cdigo de Proyecto:
En este campo se consignar el cdigo que se le asign al proyecto.
Siglas: Se deben consignar las siglas que la USTI le asigne al proyecto.
Recursos Humanos:
En este campo se debe anotar cada una de las personas que se requerirn durante el
ciclo de vida del proyecto, con el fin de que las mismas sean ubicadas a tiempo, segn
sea el caso.
Adems deber indicarse para cada persona el grado de dedicacin al
proyecto, dentro de un periodo debidamente especificado en esta seccin.

Para que un proyecto sea exitoso cada integrante del equipo de trabajo debe
comprometer un nmero determinado de horas de su horario normal. De no ser as,
ese funcionario no debe estar integrando el equipo de trabajo y debe ser sustituido.
No existe una formula fija, sin embargo reglas basadas en la experiencia indican que
el lder de un proyecto de mediano a gran tamao, debe dedicarse a tiempo completo
al proyecto; los otros integrantes del equipo podran no estar a tiempo completo pero
su grado de dedicacin debe quedar claramente establecido para todos los miembros,
ya que esto incide directamente en el tiempo requerido para el logro de las metas y
objetivos del proyecto.
Segn sea el caso se debe anotar el perfil requerido para el recurso; por ejemplo: se
requiere un programador en JAVA con basta experiencia, durante un lapso de cinco
meses, para laborar a medio tiempo. Se requiere los servicios de un experto en
instalacin de redes de fibra ptica, para trabajar por tres meses a tiempo completo,
para laborar en las oficinas centrales de la CGR.
Recursos Tecnolgicos:
En este campo se deben anotar aquellos recursos tecnolgicos con que se debe contar
en un momento determinado, para la buena marcha del proyecto. Es necesario indicar
cantidades, tiempo y especificaciones tcnicas.
Por ejemplo:
se requiere contar con un servidor instalado en la red central de la CGR, a
partir del mes de octubre, con las siguientes caractersticas tcnicas.......
Se debe contar, a partir de julio, con un Sistema Administrador de Bases
de Datos, Oracle 11g, con 12 licencias de prueba, instalado en el servidor
de pruebas de la CGR.....
Recursos Materiales:
En este campo se deben anotar aquellos recursos materiales, necesarios para la buena
marcha del proyecto. Es necesario indicar cantidades, tiempo y caractersticas.
Ejemplos.
Se necesita una oficina de 60 m2, equipada con cuatro escritorios, .....
Se requiere contar con los servicios de un vehculo a disposicin del grupo
de trabajo, las 24 horas del da, a partir del mes de febrero y por 3 meses.
Recursos Financieros:
En este campo se debe hacer referencia a un presupuesto de gastos, lo mismo que
a un flujo de efectivo, dependiendo de la complejidad del proyecto, los presupuestos
sern ms o menos detallados. En algunos proyectos de la CGR, podran no tener
presupuesto o flujos de efectivo, sobre todo aquellos que lo nico que requieren es
el aporte del esfuerzo personal de su grupo de trabajo, para obtener un determinado
producto como lo es por ejemplo un desarrollo interno de sistemas, un ante-proyecto,
la redaccin de una poltica o lineamiento.
Elaborado por:
En este campo se debe consignar el nombre de la persona que elabor el documento.
Fecha:
En este campo se debe consignar la fecha en que se elabor el documento.
Anexo 11.
Formulario para documentar Acciones Correctivas o Preventivas.
DOCUMENTACIN DE ACCIONES CORRECTIVAS O PREVENTIVAS
Nombre del Proyecto: ________________________________________________________
Cdigo de Proyecto: _______
Siglas:
_______
Actividad desfasada(o que se podra desfasar) segn el Plan.
__________________________________________________________________________
Motivos:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Acciones correctivas (o preventivas).
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Elaborado por: ___________________________________ Fecha: ___________________

En este campo se debe indicar el nombre del proyecto, tal y como el mismo es conocido
en toda la documentacin.
Cdigo del proyecto:

Nmero de cdigo asignado desde el inicio del proyecto.
Siglas:
Actividad desfasada segn el plan:

Se dice que una actividad esta desfasada cuando a travs del proceso de revisin se
determina que una actividad no esta logrando los alcances esperados, o bien los est
logrando en un tiempo mayor al planeado. En este campo se debe indicar el nombre
de todas aquellas actividades que el equipo de trabajo detectase como desfasadas.
Lo ideal es que el desfase sea detectado lo antes posible, para facilitar la toma de
acciones.
Motivos:
En este campo se deben documentar los motivos por los que, a criterio del equipo de
trabajo, la actividad tiende a estar o est desfasada.
Posibles acciones correctivas o preventivas para contrarrestar el desfase:

Dependiendo del tipo de desfase, el equipo de trabajo tomara diversas acciones para
contrarrestarlo. Por ejemplo si el desfase fuese en el tiempo, el equipo puede asignar
ms recursos a la actividad para acelerar su ejecucin. Si el desfase fuese en alcances,
el equipo buscar diversas alternativas para lograr los alcances iniciales. Si fuese
imposible lograrlos se debe hacer la comunicacin a la Unidad Ejecutora, para buscar
el consenso sobre unos nuevos alcances modificados o reducidos.
Si las acciones
correctivas no lograsen, mantener vigente el plan del proyecto, se deber elaborar un

ajuste al plan, comunicndolo a todos los diferentes interesados o afectados por el
proyecto.
Elaborado por:
Fecha:
Anexo 12.
Formulario para llevar el Control de Cambios del Proyecto

CONTROL DE CAMBIOS EN EL PROYECTO
Siglas:
_______
Cambio requerido:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Justificacin:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Impacto del cambio:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Requiri de ajustes en el plan de trabajo. ____________________
Elaborado por: ___________________________________ Fecha: ___________________

Cdigo del proyecto:

Siglas:
Cambio requerido:
Debe detallar en que consisti el cambio dentro del proyecto.
Justificacin:
Asociado al cambio anterior debe indicar la justificacin o el por qu se present el
cambio.
Impacto del cambio:

Debe valorar el impacto como bajo, mediano y alto dependiendo de cuanto afecte el
plan de trabajo.
Requiri ajustes en el plan de trabajo:

Se indica con un si o con un no si la atencin de dicho cambio requiri que se
realizaran ajustes al plan de trabajo.
Elaborado por:
Fecha:
Anexo 13.
Formulario para la Aceptacin de Productos Finales del Proyecto

ACEPTACIN DE PRODUCTOS FINALES DEL PROYECTO
Siglas:
________
Productos entregados:
_____________________________________________________
_____________________________________________________
_____________________________________________________
_____________________________________________________
Observaciones:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Acepta a satisfaccin: _______________________________ Firma: ___________________
Fecha: ___________________

Cdigo del proyecto:

Siglas:
Productos entregados:
Se listan todos los productos finales que deja el proyecto que concluye. Pueden ser;
entre otros, sistemas operando, documentacin, o tecnologa operando.
Observaciones:
El coordinador de la Unidad Ejecutora puede dejar constancia de puntos que considera
importantes en relacin a alguno de los productos, sobre todo si los requiere ser
retomado en futuras versiones del proyecto.
Acepta a satisfaccin:
En este campo se debe consignar el nombre del coordinador de la Unidad Ejecutora,
dando por aceptados los productos finales.
Firma:
Firma del coordinador de la Unidad Ejecutora.
Fecha:
Anexo 14.
Diagramas de Casos de Uso

Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos de uso
del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere
a su interaccin externa. En el diagrama de casos de uso se representa tambin el
sistema como una caja rectangular con el nombre en su interior. Los casos de uso
estn en el interior de la caja del sistema, y los actores fuera, y cada actor est unido
a los casos de uso en los que participa mediante una lnea. En la siguiente figura se
muestra un ejemplo de Diagrama de Casos de Uso para un cajero automtico.
1. Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores,
casos de uso y relaciones entre casos de uso.
1.1 Actores
Un actor es algo con comportamiento, como una persona (identificada por un rol), un
sistema informatizado u organizacin, y que realiza algn tipo de interaccin con el
sistema. Se representa mediante una figura humana. Esta representacin sirve tanto
para actores que son personas como para otro tipo de actores.
1.2 Casos de Uso
Un caso de uso es una descripcin de la secuencia de interacciones que se producen
entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea
especfica. Expresa una unidad coherente de funcionalidad, y se representa en el
Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su
interior. El nombre del caso de uso debe reflejar la tarea especfica que el actor desea
llevar a cabo usando el sistema.
1.3 Relaciones entre Casos de Uso
Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo
para el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin
con un alcance menor como caso de uso con fines de mejorar la comunicacin en
el equipo de desarrollo y en el manejo de la documentacin de casos de uso. Si
queremos utilizar casos de uso ms pequeos, las relaciones entre estos y los casos
de uso ordinarios pueden ser de los siguientes tres tipos:
Incluye (<>): Un caso de uso base incorpora explcitamente a otro caso de
uso en un lugar especificado dentro del caso base. Se suele utilizar para
encapsular un comportamiento parcial comn a varios casos de uso. En
la siguiente figura se muestra cmo el caso de uso Realizar Reintegro
puede incluir el comportamiento del caso de uso Identificacin.
Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos
de extensin) en los cuales, dependiendo de ciertos criterios, se va a
realizar una interaccin adicional. El caso de uso que extiende describe un
comportamiento opcional del sistema (a diferencia de la relacin Incluye que
se da siempre que se realiza la interaccin descrita) En la siguiente figura
se muestra como el caso de uso Comprar Producto permite explcitamente
extensiones en el siguiente punto de extensin: info regalo. La interaccin
correspondiente a establecer los detalles sobre un producto que se enva
como regalo estn descritos en el caso de uso Detalles Regalo.
Ambos tipos de relacin se representan como una dependencia etiquetada con el

estereotipo correspondiente (<<>> o <>), de tal forma que la flecha indique el sentido
en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede detallar el/los puntos
de extensin del caso de uso base en los que se aplica la extensin.
Generalizacin ( ): Cuando un caso de uso definido de forma abstracta se
particulariza por medio de otro caso de uso ms especfico. Se representa
por una lnea continua entre los dos casos de uso, con el tringulo que
simboliza generalizacin en UML (usado tambin para denotar la herencia
entre clases) pegado al extremo del caso de uso ms general. Al igual que
en la herencia entre clases, el caso de uso hijo hereda las asociaciones y
caractersticas del caso de uso padre. El caso de uso padre se trata de un
caso de uso abstracto, que no est definido completamente. Este tipo de
relacin se utiliza mucho menos que las dos anteriores. El caso de uso hijo
hereda el comportamiento y significado del caso de uso padre.
La generalizacin aplica tambin para los actores o agentes. Las funciones de un

actor pueden especializarse. Un actor puede heredar las funciones del actor padre y
a la vez tener funciones ms especficas que lo especialicen.
Trabajando con Casos de Uso

Un Caso de Uso es un documento narrativo que describe a los actores utilizando un
sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un
sistema. Los casos de uso son requisitos, en particular requisitos funcionales.
UML no define un formato para describir un caso de uso. Tan slo define la manera
de representar la relacin entre actores y casos de uso en un diagrama: el Diagrama
de Casos de Uso. Sin embargo, un caso de uso individual no es un diagrama, es
un documento de texto. En la siguiente seccin se define el formato textual para la
descripcin de un caso de uso que se va a utilizar en este documento.
Un escenario es un camino concreto a travs del caso de uso, una secuencia especfica
de acciones e interacciones entre los actores y el sistema. En un primer momento
interesa abordar un caso de uso desde un nivel de abstraccin alto, utilizando el

formato de alto nivel. Cuando se quiere describir un caso de uso con ms detalle, se
usa el formato expandido.
1. Casos de Uso de Alto Nivel

El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se
est usando un cajero automtico:
Caso de Uso: Realizar Reintegro
Actores: Cliente
Tipo: primario
Descripcin: Un Cliente llega al cajero automtico, introduce la tarjeta, se
identifica y solicita realizar una operacin de reintegro por una cantidad
especfica. El cajero le da el dinero solicitado tras comprobar que la
operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va.
En un caso de uso descrito a alto nivel la descripcin es muy general, normalmente
se condensa en dos o tres frases. Es til para comprender el mbito y el grado de
complejidad del sistema.
2. Casos de Uso Expandidos

Los casos de uso que se consideren los ms importantes y que se considere que son
los que ms influencian al resto, se describen a un nivel ms detallado en el formato
expandido.
La principal diferencia con un caso de uso de alto nivel est en que incluye un apartado
de Curso Tpico de Eventos, pero tambin incluye otros apartados como se ve en el
siguiente ejemplo:
Caso de Uso: Realizar Reintegro

Actores: Cliente (iniciador)
Propsito: Realizar una operacin de reintegro de una cuenta del banco
Visin General: Un Cliente llega al cajero automtico, introduce la tarjeta,
se identifica y solicita realizar una operacin de reintegro por una cantidad
especfica. El cajero le da el dinero solicitado tras comprobar que la
operacin puede realizarse. El Cliente coge el dinero y la tarjeta y se va.
Tipo: primario y esencial
Referencias: Funciones: R1.3, R1.7
Curso Tpico de Eventos:
Accin del Actor
Respuesta del Sistema
1. Este caso de uso empieza cuando 2. Pide la clave de identificacin.
un Cliente introduce una tarjeta en
el cajero.
3. Introduce la clave.
5.
Selecciona
la
4. Presenta las opciones de operaciones

operacin
disponibles.
de 6. Pide la cantidad a retirar.
Reintegro.
7. Introduce la cantidad requerida.
9. Recoge la tarjeta.
8. Procesa la peticin y da el dinero solicitado.

Devuelve la tarjeta y genera un recibo.
10. Recoge el recibo.

11. Recoge el dinero y se va.
Cursos Alternativos:
Lnea 4: La clave es incorrecta. Se indica el error y se cancela la operacin.
Lnea 8: La cantidad solicitada supera el saldo. Se indica el error y se
cancela la operacin.
El significado de cada apartado de este formato es como sigue:

Caso de Uso: Nombre del Caso de Uso
Actores: Lista de actores (agentes externos), indicando quin inicia el caso
de uso. Los actores son normalmente roles que un ser humano desempea,
pero puede ser cualquier tipo de sistema.
Propsito: Intencin del caso de uso.
Visin General: Repeticin del caso de uso de alto nivel, o un resumen
similar.
Tipo:
primario, secundario u opcional (descritos ms adelante).
Esencial o real (descritos ms adelante).

Referencias: Casos de uso relacionados y funciones del sistema que
aparecen en los requisitos (si se levantaron previamente)
Curso Tpico de Eventos: Descripcin de la interaccin entre los actores
y el sistema mediante las acciones numeradas de cada uno. Describe
la secuencia ms comn de eventos, cuando todo va bien y el proceso
se completa satisfactoriamente. En caso de haber alternativas con grado
similar de probabilidad se pueden aadir secciones adicionales a la seccin
principal, como se ver ms adelante.
Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto
con la descripcin de la excepcin.
3. Identificacin de Casos de Uso

La identificacin de casos de uso requiere un conocimiento medio acerca de los
requisitos del sistema, y se basa en la revisin de los documentos de requerimientos
(si los hay), y en el uso de la tcnica de lluvia de ideas entre los miembros del equipo
de trabajo y el lder tcnico.
Como gua para la identificacin inicial de casos de uso hay dos mtodos:
a. Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la organizacin.
2. Para cada actor, identificar los procesos que inicia o en los que participa.
b. Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a tener que responder.
2.
Relacionar
los
eventos
con
actores
casos
de
uso.
Ejemplos de casos de uso:

Pedir un producto.
Matricularse en un curso de la facultad.
Comprobar la ortografa de un documento en un procesador de textos.
Comprar un libro en una tienda de libros en Internet
4. Identificacin de los Lmites del Sistema

En la descripcin de un caso de uso se hace referencia en todo momento al sistema.
Para que los casos de uso tengan un significado completo es necesario que el sistema
est definido con precisin.
Al definir los lmites del sistema se establece una diferenciacin entre lo que es interno
y lo que es externo al sistema. El entorno exterior se representa mediante los actores.
Ejemplos de sistemas son:
El hardware y software de un sistema informtico.
Un departamento de una organizacin.
Una organizacin entera.
Si no se est haciendo reingeniera del proceso de negocio lo ms normal es escoger
como sistema el primero de los ejemplos: el hardware y el software del sistema que
se quiere construir.
5. Tipos de Casos de Uso

a. Segn Importancia
Para establecer una primera aproximacin a la priorizacin de casos de uso que
identifiquemos, los vamos a distinguir entre:
Primarios: Representan los procesos principales, los ms comunes, como
Realizar Reintegro en el caso del cajero automtico.
Secundarios: Representan casos de uso menores, que van a necesitarse
espordicamente.
Opcionales: Representan procesos que pueden no ser abordados en el
presente proyecto.
b. Segn el Grado de Compromiso con el Diseo
En las descripciones que se han visto se han descrito los casos de uso a un nivel
abstracto, independientemente de la tecnologa y de la implementacin. Un caso de
uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto
nivel son siempre esenciales por naturaleza, debido a su brevedad y abstraccin.
Por el contrario, un caso de uso real describe concretamente el proceso en trminos
del diseo real, de la solucin especfica que se va a llevar a cabo. Se ajusta a un tipo
de interfaz especfica, y se baja a detalles como pantallas y objetos en las mismas.
Para el ejemplo de un Caso de Uso Real en el caso del reintegro en un cajero
automtico tenemos la siguiente descripcin del Curso Tpico de Eventos:
Accin del Actor

1. Este caso de uso empieza cuando un 2. Pide el PIN (Personal Identification
Cliente introduce una tarjeta en la ranura Number).
para tarjetas.
3. Introduce el PIN a travs del teclado 4.
Presenta
numrico.
operaciones
5. etc.
6. etc.
las
opciones
de
disponibles.
En principio, los casos de uso reales deberan ser creados en la fase de Diseo de
Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definicin de
interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del
contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a
pesar de que suponen tomar decisiones de diseo muy pronto en el ciclo de vida.
No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de
compromiso con el diseo es un continuo, y una descripcin especfica de un caso de
uso estar situada en algn punto de la lnea entre Casos de Uso Esenciales y Reales,
normalmente ms cercano a un extremo que al otro, pero es raro encontrar Casos de
Uso Esenciales o Reales puros.
6. Consejos Relativos a Casos de Uso

a. Nombre
El nombre de un Caso de Uso debera ser un verbo, para enfatizar que se trata de un
proceso, por ejemplo: Comprar Artculos o Realizar Pedido.
b. Alternativas
Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se
indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas opciones,
todas ellas consideradas normales se puede completar el Curso Tpico de Eventos con
secciones adicionales.
As, si en un determinado nmero de lnea hay una bifurcacin se pueden poner
opciones que dirigen el caso de uso a una seccin que se detalla al final del Curso
Tpico de Eventos, en la siguiente forma:
- Curso Tpico de Eventos:
Seccin: Principal
Accin del Actor
1. Este caso de uso empieza cuando Actor 2. Pide la operacin a realizar.
llega al sistema.
3. Escoge la operacin A.
5. Selecciona el tipo de pago:
4. Presenta las opciones de pago.

6. Genera recibo.
Si se paga al contado ver seccin Pago

al Contado.
Si se paga con tarjeta ver seccin Pago
con Tarjeta.
7. Recoge el recibo y se va.

Lneas 3 y 5: Selecciona Cancelar. Se cancela la operacin.
Seccin: Pago al Contado

Accin del Actor
1. Mete los billetes correspondientes

2. Coge los billetes y sigue pidiendo dinero
hasta que la cantidad est satisfecha
3. Devuelve el cambio.
Lnea 3: No hay cambio suficiente. Se cancela la operacin.
Seccin: Pago con Tarjeta
7. Construccin del Modelo de Casos de Uso

Para construir el Modelo de Casos de Uso se siguen los siguientes pasos:
f. Despus de listar las funciones del sistema, se definen los lmites del
sistema y se identifican los actores y los casos de uso.
g. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan
como primarios, secundarios u opcionales.
h. Se dibuja el Diagrama de Casos de Uso.
i. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se
ilustran tales relaciones en el Diagrama de Casos de Uso.
j. Los casos de uso ms crticos, importantes y que conllevan un mayor
riesgo, se describen en el formato expandido esencial. Se deja la definicin
en formato expandido esencial del resto de casos de uso para cuando
sean tratados en posteriores ciclos de desarrollo, para no tratar toda la
complejidad del problema de una sola vez.
k. Se crean casos de uso reales slo cuando:
- Descripciones ms detalladas ayudan significativamente a incrementar
la comprensin del problema.
- El cliente pide que los procesos se describan de esta forma.
l. Ordenar segn prioridad los casos de uso.

Metodologia de Proyectos

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Metodologia de Proyectos

Caricato da

Copyright:

Formati disponibili

Anexo - NTP7

Guia Metodologica para

218 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 219

220 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Para los efectos de esta metodologa, se define un proyecto como:

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 221

4. Etapas de los Proyectos de TIC

222 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

4.2. Etapa 1. Iniciacin.

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 223

Comunicacin constante entre los diferentes participantes en el proyecto

224 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Figura # 1. Fases de un Proyecto.

A continuacin se presenta de forma detallada las acciones que se deben realizar en

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 225

226 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Para la estimacin del tiempo, se puede recurrir a diferentes tcnicas, como lo es el

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 227

Cualquier cambio en cuanto a los resultados esperados, alcance planeado, efecto,

228 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 229

Los participantes en el proyecto que conforman la organizacin descrita, son

Coordinador de Proyectos (Jefatura o funcionario asignado)

Organigrama del proyecto

230 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Para un mayor detalle de los perfiles y de las responsabilidades de los miembros

Es el jefe de la Unidad Organizacional para la cual se va a desarrollar un proyecto de

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 231

6.1.3. Grupo de Apoyo

232 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 233

6.3. Informe de diagnstico:

234 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

apartado del diagnstico. Estas expectativas sern de referencia obligada para el

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 235

6.3.4. Anlisis de riesgo

236 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Cuando se planteen dos o ms estrategias de solucin se deber realizar un

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 237

Para cada una de las estrategias de solucin se deber identificar:

238 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Cuando la Unidad Ejecutora haya seleccionado el curso de accin para el proyecto

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 239

240 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

7.1. Elaboracin del Plan de Trabajo:

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 241

g. Una vez agrupadas las actividades en etapas o subproyectos, se debe

242 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

7.1.1. Fases para el desarrollo de un sistema de informacin automatizado

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 243

7.4. Productos de la Etapa:

244 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

En reuniones peridicas el equipo de proyecto programa la

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 245

El informe de avance deber ser corto y contener las siguientes secciones:

En el caso de un proyecto de desarrollo de

sistemas de informacin los productos intermedios estn debidamente identificados

246 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

8.6. Puntos de Control:

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 247

248 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

importante es que el plan esta enmarcado en una realidad de la organizacin, siendo

tarea de ruta crtica que dure 11 das aportar 5.5 UL.