Informe NTI A 7

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.
Figura # 1. Fases de un Proyecto.
Inicio
Pl
an
ea
Eje
cu
ci
ci
Control
A continuacin se presenta de forma detallada las acciones que se deben realizar en cada una de las etapas.
Cierre
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 Lder de proyecto Lder Tcnico

Unidad Ejecutora
Coordinador de proyectos
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. 7.3. Insumos de la etapa: Informe de diagnstico. Descriptivo de la Organizacin del Proyecto. Estrategia de solucin para el proyecto.
7.4. Productos de la Etapa: Plan de trabajo para el proyecto (Cronograma). Formulario de planeacin de recursos. 7.5. Puntos de Control: 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. 8.4. Insumos de la etapa: Plan de trabajo para el proyecto (Cronograma). Formulario de planeacin de recursos. 8.5. Productos de la Etapa: Minutas de reuniones. Informes de avance. Productos intermedios propios del proyecto de TIC.
8.6. Puntos de Control:
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: 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 una
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. 9.5. Insumos de la etapa: Informes de avance. Plan de trabajo para el proyecto (Cronograma). Formulario de planeacin de recursos. 9.6. Productos de la Etapa: 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.
9.7. Puntos de Control: 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. 10.4. Insumos de la etapa: Cronograma actualizado con ejecucin de tareas. Documentos desarrollados durante el proyecto.
10.5. Productos de la Etapa: Informe de conclusin del proyecto Formulario de aceptacin a satisfaccin de los productos. Expediente actualizado del proyecto 10.6. Puntos de Control: 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, 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 hacer las
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
Entre sus responsabilidades est: 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
Entre sus responsabilidades est: 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: Real: definido a nivel abstracto, independiente de la describe concretamente el proceso en
tecnologa y la implementacin 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 Alternativos completa satisfactoriamente. Condiciones resultantes despus del proceso Se describe la excepcin al caso normal y se seala el punto 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

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
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 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

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
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 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
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
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 programacin para el Desarrollo de un Sistema de Informacin se identifican los siguientes entregables: 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 tipo tcnico para garantizar su calidad. a una revisin de su
funcionalidad por parte del Lder de Proyecto o quien l designe y a una revisin de
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
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
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 documentacin para el Desarrollo de un Sistema de Informacin se identifican los siguientes entregables: 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
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
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
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 implementacin para el Desarrollo de un Sistema de Informacin se identifican los siguientes entregables: 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. Las actividades a realizar son las siguientes: 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 Las actividades a realizar son las siguientes: 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: ASISTENCIA:

Invitado
Elaborado por: Fecha: Hora inicio: Hora finalizacin:
Dependencia
Pre
Aus
X ASUNTOS PENDIENTES Y SEGUIMIENTO DE ACUERDOS:

Asunto Responsable
Grado de avance / Finalizacin prevista
ASUNTOS TRATADOS:
Asuntos tratados 1) 2)
ACUERDOS:
Comentarios Generales
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.
DESCRIPTIVO DE LA ORGANIZACIN DEL PROYECTO PROYECTO: Nombre del proyecto Cdigo de Proyecto: _____________ Siglas: _____________ Objetivo
_________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ _________________________________________________________ Integrantes del equipo de trabajo
Lder de Proyecto: Lder Tcnico:
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.
Nombre del Proyecto:

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: _________
Humanos: ____________ ________________________________________________________________________ __________________________________________________________________ Tecnolgicos: _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ Materiales: ________________________________________________________________________ ________________________________________________________________________ __________________________________________________________________ Financieros: ________________________________________________________________________ ________________________________________________________________________ __________________________________________________________________ Elaborado por: ____________________________________ Fecha: ____________
Explicacin detallada.
Recursos Requeridos _________________________________________________________
Nombre del Proyecto:

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: ___________________ Explicacin detallada.
Nombre del proyecto:

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 Nombre del Proyecto: ________________________________________________________ Cdigo de Proyecto: _______ Siglas: _______ Cambio requerido: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Justificacin: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Impacto del cambio: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Requiri de ajustes en el plan de trabajo. ____________________ Elaborado por: ___________________________________ Fecha: ___________________ Explicacin detallada.

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 Nombre del Proyecto: ________________________________________________________ Cdigo de Proyecto: _______ Siglas: ________ Productos entregados: _____________________________________________________ _____________________________________________________ _____________________________________________________ _____________________________________________________
Observaciones: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Acepta a satisfaccin: _______________________________ Firma: ___________________ Fecha: ___________________ Explicacin detallada.

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 operacin 4. Presenta las opciones de operaciones disponibles. de 6. Pide la cantidad a retirar. 8. Procesa la peticin y da el dinero solicitado. Devuelve la tarjeta y genera un recibo.
Reintegro. 7. Introduce la cantidad requerida.
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.
9. Recoge la tarjeta.
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 y 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 Respuesta del Sistema 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. numrico. 5. etc. Presenta las opciones de
operaciones 6. etc.
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 Respuesta del Sistema 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.
Cursos Alternativos: Lneas 3 y 5: Selecciona Cancelar. Se cancela la operacin.
Seccin: Pago al Contado Accin del Actor 1. Mete los billetes correspondientes Respuesta del Sistema 2. Coge los billetes y sigue pidiendo dinero hasta que la cantidad est satisfecha 3. Devuelve el cambio.
Cursos Alternativos: 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.

Informe NTI A 7

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Informe NTI A 7

Uploaded by

Copyright:

Available Formats

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

220 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

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

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 223

224 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Figura # 1. Fases de un Proyecto.

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 225

226 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 227

228 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 229

Organigrama del proyecto

Patrocinador del proyecto Grupo de apoyo Lder de proyecto Lder Tcnico

Equipo de apoyo tcnico

230 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 231

232 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 233

234 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 235

236 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 237

238 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 239

240 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 241

242 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 243

244 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 245

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

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 249

250 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 251

252 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

10. Etapa 5: Conclusin

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 253

254 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 255

256 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 257

Actualizacin de la Gua Metodolgica para el Desarrollo de Proyectos de Tecnologa de Informacin y Comunicaciones.

258 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Responsabilidades de los miembros del proyecto Patrocinador del Proyecto

Coordinador de Proyectos de la USTI.

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 259

260 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Lder del Proyecto

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 261

262 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 263

264 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Lder Tcnico del proyecto

Normas Tcnicas en Tecnologas de Informacin y Comunicaciones / 265

266 / Normas Tcnicas en Tecnologas de Informacin y Comunicaciones

Elaborado por: _______________ Fecha:_ Explicacin Detallada Nombre del proyecto:

Nombre __

Unidad _______________ _ _ _ _______________