Guía Metodológica para el Desarrollo de Sistemas de Información

CONTRALORÍA GENERAL DE LA REPÚBLICA
UNIDAD DE SISTEMAS Y TECNOLOGÍA DE INFORMACIÓN
Guía Metodológica para el Desarrollo de
Sistemas de Información
Versión
Fecha de creación:
Ultima modificación
Aprobación Despacho
Del Contralor General
1.1
30 de junio de 2002
12 de junio de 2003
8 de agosto de 2003
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Guía Metodológica para el Desarrollo de
Sistemas de Información
Comité de elaboración
Fecha
Cecilia Flores Mora
Maryleana Méndez Jiménez
USTI
USTI
Año 2001
Año 2001
Comité de revisión
Fecha
Juan Carlos Solís Ledezma
Yirlane Orozco Sancho
Patricia Delgado Leandro
Javier Brenes Arrieta
Oscar Moya Alpízar
Gino Ramírez Solís
Alex Monge Lemaitre
José Alpízar Fallas
USTI
USTI
USTI
USTI
Auditoria Interna
Grupo de Auditoria de Sistemas
Grupo de Auditoria de Sistemas
Grupo de Auditoria de Sistemas
Año 2001
Año 2001
Año 2001
Año 2001
Año 2001
Año 2001
Año 2001
Año 2001
Bitácora de Cambios
Modificado por:
Descripción de la modificación
Róger Araya Fonseca
Miguel Aguilar Zamora
Róger Araya Fonseca
Cambios en la estructura del documento
Revisión integral de la Metodología
Modificación solicitadas por el CGI
Fecha
01-abril-2003
01-abril-2003
12-junio-2003
i
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Tabla de contenido
Introducción ......................................................................................................................................... 1
Descripción de la metodología ............................................................................................................ 1
Objetivo ............................................................................................................................................... 2
Objetivos específicos .......................................................................................................................... 2
Alcances .............................................................................................................................................. 2
Definición de roles ............................................................................................................................... 3
Actualización de la Guía Metodológica ............................................................................................... 4
1.
Organización del proyecto ...................................................................................................... 5
1.1.
Estructura organizacional del proyecto .............................................................................. 5
1.1.1.
Unidad Ejecutora ........................................................................................................... 6
1.1.2.
Patrocinador del Proyecto ............................................................................................. 7
1.1.3.
Jefe de la USTI. ............................................................................................................. 7
1.1.4.
Líder del Proyecto.......................................................................................................... 8
1.1.5.
Líder Técnico del proyecto .......................................................................................... 10
1.1.6.
Equipo de apoyo tecnológico ...................................................................................... 13
1.1.7.
Equipo de trabajo......................................................................................................... 13
1.2.
Propiedad del Sistema de Información y sus datos......................................................... 13
1.3.
Definición del ambiente administrativo ............................................................................ 15
1.4.
Proceso de contratación externa ("outsourcing") ............................................................ 15
2.
Fases para el desarrollo de sistemas .................................................................................. 16
2.1.
Solicitud para el desarrollo de un Sistema de Información ............................................. 16
2.1.1.
Consideraciones .......................................................................................................... 16
2.1.2.
Entregables .................................................................................................................. 17
2.1.3.
Responsabilidades ...................................................................................................... 18
2.1.4.
Solicitud del sistema .................................................................................................... 18
2.1.5.
Informe de Diagnóstico ................................................................................................ 18
2.1.6.
Solicitud formal del proyecto: ...................................................................................... 20
2.2.
Análisis integral de requerimientos .................................................................................. 22
2.2.1.
Consideraciones .......................................................................................................... 22
2.2.2.
Entregables .................................................................................................................. 23
2.2.3.
Responsabilidades ...................................................................................................... 23
2.2.4.
Especificación de requerimientos ................................................................................ 23
2.2.5.
Priorización de requerimientos .................................................................................... 24
2.2.6.
Documento de análisis ................................................................................................ 25
2.3.
Diseño conceptual de la solución .................................................................................... 27
2.3.1.
Consideraciones .......................................................................................................... 27
2.3.2.
Entregables .................................................................................................................. 27
2.3.3.
Responsabilidades ...................................................................................................... 28
2.3.4.
Documento de diseño conceptual ............................................................................... 28
2.4.
Diseño detallado de la aplicación .................................................................................... 29
2.4.1.
Consideraciones .......................................................................................................... 29
2.4.2.
Entregables .................................................................................................................. 30
2.4.3.
Responsabilidades ...................................................................................................... 30
2.4.4.
Documento de diseño detallado .................................................................................. 30
2.4.5.
Diseño de pruebas:...................................................................................................... 31
2.5.
Programación y pruebas .................................................................................................. 33
2.5.1.
Consideraciones .......................................................................................................... 33
2.5.2.
Entregables .................................................................................................................. 33
2.5.3.
Responsabilidades ...................................................................................................... 34
2.5.4.
Construcción ................................................................................................................ 34
2.5.5.
Pruebas ....................................................................................................................... 35
ii
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.5.6.
Ajustes de programación ............................................................................................. 35
2.5.7.
Aceptación del sistema ................................................................................................ 36
2.6.
Documentación ................................................................................................................ 37
2.6.1.
Consideraciones .......................................................................................................... 37
2.6.2.
Entregables .................................................................................................................. 37
2.6.3.
Responsabilidades ...................................................................................................... 37
2.6.4.
Documentación del proyecto ....................................................................................... 37
2.6.5.
Manual de usuario ....................................................................................................... 38
2.6.6.
Manual técnico ............................................................................................................. 39
2.6.7.
Manual de operación ................................................................................................... 39
2.7.
Capacitación .................................................................................................................... 40
2.7.1.
Consideraciones .......................................................................................................... 40
2.7.2.
Responsabilidades ...................................................................................................... 40
2.8.
Implementación ................................................................................................................ 41
2.8.1.
Consideraciones .......................................................................................................... 41
2.8.2.
Entregables .................................................................................................................. 41
2.8.3.
Responsabilidades ...................................................................................................... 42
2.8.4.
Plan de implantación ................................................................................................... 42
2.8.5.
Instalación del sistema ................................................................................................ 43
2.8.6.
Conversión y carga inicial automatizada de datos ...................................................... 43
2.8.7.
Ejecución del paralelo.................................................................................................. 44
2.8.8.
Aprobación formal del sistema para el inicio de su operación. ................................... 44
2.8.9.
Hacer la entrega del sistema al usuario. ..................................................................... 44
2.9.
Evaluación post-implementación ..................................................................................... 45
3.
Mantenimiento de sistemas.................................................................................................. 46
3.1.
Planificación de la fase de mantenimiento ...................................................................... 46
3.2.
Especificación de los nuevos requerimientos .................................................................. 46
3.3.
Ajustes en programación y pruebas ................................................................................ 46
3.4.
Actualización de la documentación y los programas fuente ............................................ 46
3.5.
Capacitación .................................................................................................................... 47
3.6.
Implementación de los cambios ....................................................................................... 47
3.7.
Evaluación post-implantación .......................................................................................... 47
iii
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Introducción
La búsqueda de soluciones con tecnología de información, entendida como la adquisición de una
solución para la automatización de procesos, posee una interrelación compleja de componentes
trabajando conjuntamente como lo son: personas, procesos, procedimientos, presupuesto,
políticas, dispositivos mecánicos o eléctricos, y equipo computacional.
Es por ello que es necesaria la definición de una guía metodológica para desarrollo de sistemas
que le permita a la Contraloría General de la República construir soluciones flexibles y responder a
un ambiente tecnológico establecido. Esta guía metodológica provee un conjunto estructurado de
actividades para implementar y dar mantenimiento a un sistema automatizado de manera que la
especificación, el diseño, la validación y la evolución del sistema converjan en una solución en un
tiempo prudencial, con un desarrollo acorde con las necesidades de la Institución y con la
documentación suficiente para facilitar su actualización.
Esta guía supone que anualmente el Comité Gerencial de Informática aprueba un Plan de la
Unidad de Sistemas y Tecnologías de Información, donde se definen y priorizan los sistemas de
información a ser implementados durante el año, así como su Unidad Patrocinadora, los cuales
serían desarrollados bajo la guía metodológica descrita en este documento. El Comité Gerencial
para algunos de estos proyectos podrá requerir para su dictamen definitivo la presentación de los
resultados de los estudios de factibilidad o diagnósticos, en consideración de elementos de
impacto económico, operativo, técnico, de materialidad, riesgo asociado, sensibilidad y criticidad.
Para el resto de los proyectos quedará a criterio de los participantes directos del proyecto, la
evaluación de su factibilidad y relación costo/beneficio. Este Comité tendrá la potestad de solicitar
al Líder de Proyecto, los reportes por excepción que considere pertinente.
Descripción de la metodología
La presente metodología está estructurada en tres secciones principales:
a) La organización del proyecto
b) Las fases para el desarrollo de sistemas de información
c) La evolución de los sistemas de información
En la primera de estas secciones se hace referencia a las funciones y responsabilidades de cada
uno de los involucrados en el desarrollo del proyecto. Además se presentan las cualidades que
deben presentar quienes asuman las funciones de Patrocinadores de Proyecto, Líderes de
Proyecto y Líderes Técnicos de Proyecto.
En la segunda sección de la presente metodología se presenta la guía a seguir por los Líderes
Técnicos de Proyectos, Analistas y Usuarios en la realización de las distintas fases que conlleva el
desarrollo de un sistema de información automatizado.
En la tercera sección se especifican los aspectos principales para la evolución de las aplicaciones
en producción considerando para esto el manejo de los nuevos requerimientos de la misma
manera en que fue construido el sistema; es decir, fases semejantes.
1
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Objetivo
Definir la guía metodológica para desarrollo de sistemas de información, que será aplicada en
todos los proyectos a elaborar en esta Unidad de Sistemas y Tecnología de Información.
Objetivos específicos
Los objetivos específicos de la presente Guía Metodológica son los siguientes:
1. Establecer claramente las fases y actividades a realizar en los proyectos de desarrollo de
sistemas de información en la Contraloría General de la República.
2. Señalar las funciones de los roles involucrados en el proceso de construcción e
implementación de sistemas de información en la Contraloría General de la República.
3. Definir un marco de referencia común entre todos los proyectos de desarrollo de sistemas
para uniformar técnicas y métodos de trabajo.
Alcances
El desarrollo del presente documento está orientado a citar y describir brevemente las actividades
a realizar para el desarrollo de sistemas de información sin entrar en detalles específicos de forma
en cuanto a la confección de documentos y entregables de cada una de las etapas ya que estos
aspectos deben formar parte del “Manual de Estándares para el Desarrollo de Sistemas de
Información”
Esta guía metodológica es para uso obligatorio de todos los funcionarios que participen en el
desarrollo de sistemas de información de esta Contraloría General de la república; por esto, no se
profundiza en aspectos técnicos específicos de la construcción de “software” como reglas para el
diseño de bases de datos, técnicas de afinamiento de sistemas y mecanismos para el desarrollo y
reutilización de componentes, entre otros, para permitir que lo establecido en esta Guía
Metodológica pueda ser consultado por cualquier funcionario de esta Contraloría General.
Se omite hacer referencia a herramientas para el desarrollo de “software”, modelado de bases de
datos, confección y actualización de cronogramas así como motores de bases de datos,
plataformas operativas, protocolos de comunicación, arquitectura de sistemas y especificaciones
de equipos, entre otros, para que lo establecido en esta Guía Metodológica no pierda vigencia
como consecuencia del constante avance que presenta el mercado en estos aspectos. El
documento está orientado, básicamente, a describir lo que se debe hacer sin establecer cómo ni
con cuál o cuáles herramientas.
Adicionalmente, no se establecen los procedimientos internos de la USTI para aspectos como
administración de ambientes, procedimiento para el manejo de versiones y programas fuente, y
procedimientos operativos de los sistemas ya que estos aspectos corresponden a otras áreas de la
organización de esta Unidad y a su distribución de funciones.
2
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Definición de roles
En el desarrollo del presente documento se hace referencia a varias funciones y responsabilidades
que se describen a continuación:

Comité Gerencial de Informática: por delegación del Sr. Contralor es el máximo ente en
lo referente a las directrices y lineamientos a seguir en la planificación y dirección de los
procesos de desarrollo tecnológico. Está conformado por un representante del Despacho
del Contralor, los Gerentes de División, Gerente del Área Administrativa, Jefe de Auditoria
Interna como asesor del Comité y el Jefe la USTI. Este Comité reporta al Sr. Contralor.

Patrocinador del proyecto: es el máximo jerarca o en quien éste delegue, de la Unidad
Organizacional para la cual se va a desarrollar el sistema de información.

Líder 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; vela tanto por los mejores intereses de su área como por los de la
Contraloría General de la República en un proyecto de desarrollo de sistemas. En casos
justificados la dirección puede ser asumida por un representante de la USTI.

Líder Técnico del proyecto: éste es un funcionario al cual, por su formación en el área de
informática, experiencia y capacidad, se la ha conferido la responsabilidad de administrar
los aspectos tecnológicos de un proyecto de desarrollo de sistemas. Puede asumir la
dirección del proyecto en casos justificados.

Coordinador de proyectos: es el funcionario designado por la USTI para velar por la
adecuada ejecución de todos los proyectos de desarrollo de sistemas observando
aspectos como integración, calidad, logro de objetivos y eficiencia en los diseños y
desarrollo de las soluciones.

Analista de sistemas: es el recurso profesional en informática (funcionario o no de la
Contraloría General de la República) que trabaja bajo la coordinación y dirección del Líder
Técnico del proyecto para la realización del sistema cuyas actividades principales son la
construcción de los programas, capacitación de usuarios, documentación y apoyo de los
usuarios en la puesta en operación del sistema.

Programador de sistemas: es el recurso profesional en informática (funcionario o no de la
Contraloría General de la República) que trabaja bajo la coordinación y dirección del Líder
Técnico del proyecto para la realización del sistema cuyas actividades principales son la
construcción de los programas, pruebas y documentación de los programas.

Usuario de sistemas: se considera a todo aquel individuo (funcionario o no de la
Contraloría General de la República) que tenga acceso autorizado al Sistema de
Información, o que se beneficie del mismo. Existen dos tipos de usuarios: usuario
generador de información y usuario de consulta.
En la aplicación de la presente metodología es posible que el mismo funcionario desempeñe más
de un rol en el desarrollo del proyecto, especialmente si el funcionario pertenece a la Unidad de
Sistemas y Tecnología de Información pero siempre se debe contar con el apoyo de la contraparte
correspondiente a los usuarios del sistema.
3
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
La aplicación de las actividades señaladas en la presente Guía Metodológica es de cumplimiento
obligatorio para todos los funcionarios de esta Contraloría General que participen en el desarrollo
de sistemas de información de acuerdo a los roles que estén desempeñando.
Actualización de la Guía Metodológica
Dado el ritmo acelerado que impone el entorno tecnológico se establece la necesidad de realizar
periódicamente las revisiones y los ajustes que corresponda a esta Guía Metodológica. El
responsable de esta actualización será la Unidad de Sistemas y Tecnologías de Información, quien
podrá pedir el apoyo y la asesoría de otros funcionarios de La Contraloría General de la República.
Esta Unidad adicionalmente deberá considerar las solicitudes de modificación expresas hechas por
Líderes de Proyectos, cuyas experiencias previas de aplicación de la guía metodológica y sus
respectivas “lecciones aprendidas” realizan aportes importantes para el fortalecimiento de este
instrumento de trabajo.
Una vez hechos los ajustes correspondientes, los puntos modificados o agregados deberán ser
sometidos a consideración del Comité Gerencial de Informática para, luego de su recomendación,
proceder a la publicación y divulgación respectiva.
4
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
1. Organización del proyecto
En este punto se define la estructura organizacional del proyecto en materia de soluciones y
sistemas basados en Tecnologías de Información así como el perfil deseable para cada uno de
sus miembros.
Esta metodología debe ser soportada por una organización de personal, que sea capaz de
llevar a cabo el proyecto de manera exitosa. Esta organización debe ofrecer agilidad,
flexibilidad y efectividad, de modo que sea un instrumento para seguir las tareas
organizadamente, chequear su calidad y responder a lo planeado en el cronograma.
1.1.
Estructura organizacional del proyecto
Se considerará la siguiente gráfica y definiciones para la conformación de la organización del
proyecto:
Organigrama del proyecto
Patrocinador
del proyecto
Grupo de
apoyo
Coordinador de
proyectos
Líder de
proyecto
Líder
Técnico
Unidad Ejecutora
Equipo de trabajo
Equipo de apoyo
técnico
5
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Para la organización del proyecto se forma un comité, para la ejecución de actividades que por
su naturaleza, requiere la interacción de personas de las diferentes áreas, según la siguiente
definición de estructuras:
-
Unidad Ejecutora
Grupo de Apoyo
Cada uno de los participantes tiene asignadas tareas y responsabilidades específicas, para un
adecuado desempeño de su función.
Los participantes en el proyecto que conforman la organización descrita, son identificados
como sigue:

Participantes por parte de la unidad organizacional del usuario:
-

Patrocinador del Proyecto
Líder del Proyecto
Equipo de Trabajo
Participantes por parte de la Unidad de Sistemas y Tecnología:
-
1.1.1.
Jefe USTI
Coordinador de Proyectos
Líder Técnico
Equipo Apoyo Tecnológico
Unidad Ejecutora
La Unidad Ejecutora es el ente coordinador de los aspectos relacionados con el desarrollo
de sistemas, bajo la responsabilidad de la Unidad de Sistemas y Tecnología de
Información.
Sus responsabilidades principales son:
-
Aprobar la organización, recursos, y el cronograma del proyecto.
Velar por la calidad de los productos de cada una de las etapas y de ofrecer
las recomendaciones al respecto.
Resolver las situaciones que puedan afectar el buen funcionamiento del
proyecto.
Aprobar los productos generados.
Está constituido por:
-
Jefe de la USTI
Coordinador de Proyectos
Patrocinador del Proyecto
Líder del Proyecto
Líder Técnico
Es coordinado por:
-
Jefe de la USTI
6
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Responsabilidades de los miembros permanentes:
1.1.2.
Patrocinador del Proyecto
Es el jefe de la Unidad Organizacional para la cual se va a desarrollar un sistema de
información.
Entre sus responsabilidades se destacan las siguientes:
1. Solicitar formalmente el desarrollo de un sistema de información.
2. Designar al Líder del Proyecto, si está dentro de sus posibilidades el asignarlo.
3. Aportar el personal de apoyo adecuado para llevar a cabo un análisis integral sobre
la factibilidad técnica, funcional y económica, de automatizar los sistemas,
procesos y procedimientos administrativos existentes o planeados a corto plazo,
bajo su cargo.
4. Apoyar en la solución de problemas y en la consecución de los recursos, en el nivel
superior.
5. Aprobar los productos de cada etapa en el proceso de desarrollo del sistema.
6. Evaluar, periódicamente, el progreso del proyecto, con base en los planes y los
informes de avance.
7. Aprobar ajustes al cronograma, en caso de ser necesario.
8. Aprobar el diseño de los formularios que utilizará el nuevo sistema y autorizar su
adquisición o emisión.
9. Aprobar el plan para levantamiento de información, conversión y carga de datos.
10. Aprobar el plan para capacitación de usuarios.
11. Aprobar el sistema de información desarrollado para su entrada en operación.
1.1.3.
Jefe de la USTI
Entre sus responsabilidades; algunas de las cuales pueden ser delegadas a un
coordinador de proyectos, se destacan las siguientes:
1. Velar porque el desarrollo de los sistemas esté de acuerdo con las políticas y
estrategias definidas en los planes.
2. Apoyar en la solución de problemas y en la consecución de los recursos en el nivel
superior.
3. Recibir, analizar y tramitar las solicitudes por nuevos desarrollos de sistemas de
información o sus ampliaciones.
4. Asignar al líder técnico que trabajará en el proyecto.
7
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
5. Convocar para las reuniones de la Unidad Ejecutora cuando sea requerido.
6. Participar y aprobar las diferentes etapas del proceso de desarrollo, en cada uno
de los proyectos que están bajo su responsabilidad.
7. Apoyar al Líder Técnico, en los asuntos técnicos del desarrollo del proyecto, que lo
requieran.
8. Coordinar el cumplimiento del cronograma de trabajo, en conjunto con el Líder del
Proyecto y el Líder Técnico.
1.1.4.
Líder del Proyecto
El Líder 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; vela tanto por los mejores intereses de su área,
como por los de la Contraloría General de la República, en un proyecto de desarrollo
informático. En casos justificados la dirección puede ser asumida por un representante de
la USTI.
Es el responsable directo del proyecto y de los productos entregados, bajo una
metodología de participación del usuario como "dueño" del sistema por desarrollar.
Características Funcionales
-
El Líder del Proyecto debe ser un representante, del área funcional a la cual se
le está desarrollando un sistema de información.
-
El nivel jerárquico es preferible que sea alto dentro de la unidad organizacional
que representa, por cuanto sus responsabilidades incluyen la toma de
decisiones, la resolución de problemas y el logro de la colaboración necesaria
de otras unidades organizacionales, cuando sea requerida.
-
El Líder del Proyecto debe tener las siguientes características:
-
Tener amplio conocimiento y dominio (o apoyarse en asesores operativos)
de las actividades y procesos por ser automatizados, así como de la
problemática 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 Líder Técnico y su equipo de trabajo, en las
fases del proyecto de desarrollo de un sistema de información, donde su
participación es crítica.
-
Mostrar alto nivel de compromiso e identificación con el proyecto en
desarrollo.
Características Técnicas
-
Estar familiarizado con los conceptos básicos del desarrollo de sistemas y
tener alguna experiencia al respecto.
8
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Responsabilidades Principales
Administrar (planificar, dirigir, controlar, ejecutar y evaluar) las fase de un proyecto de
desarrollo informático con eficiencia y eficacia.
Funciones
1. Vigilar por la aplicación de las actividades establecidas en esta Guía
Metodológica.
2. Elaborar, revisar y aprobar los planes del proyecto correspondientes a cada
una de las fases del desarrollo de un sistema de información.
3. Evaluar periódicamente el avance del proyecto de desarrollo, con base en lo
planeado y ajustarlo de ser necesario.
4. Atender los problemas administrativos (disponibilidad de recursos, conflictos,
modificación de procedimientos o procesos) que requieran su atención.
5. Lograr la colaboración apropiada de otras unidades organizacionales, que se
vean afectadas por el desarrollo del proyecto, con el objetivo de implantar una
solución integral, eficaz y eficiente al problema.
6. Definir los procedimientos administrativos en torno al sistema de información
en desarrollo.
7. Definir las nuevas funciones y responsabilidades por puesto o la actualización
de éstas, las cuales se deriven por el proyecto en desarrollo.
8. Participar activamente en la definición de requerimientos y alcances del
sistema de información, considerando las necesidades propias de su área
funcional, de otras áreas que por su función estén relacionadas con el
proyecto, así como de los niveles de decisión.
9. Revisar y aprobar, junto con el Líder Técnico, el diseño funcional del sistema
de información.
10. Participar en el estudio de paquetes de "software", cuando sea requerido para
el proyecto en desarrollo y emitir las observaciones pertinentes.
11. Evaluar el prototipo del sistema de información, hacer las recomendaciones
pertinentes y aprobarlo formalmente.
12. Participar activamente en la definición de volúmenes de información, aspectos
operacionales del sistema, criticidad, usuarios del sistema, procesos de
entrada y salida, diseño de reportes, aspectos de seguridad y controles,
interfaces, y requerimientos de "hardware".
13. Evaluar el diseño final del sistema en sus apartados de seguridad y controles,
procesos de entrada y salida, e interfaces y funcionalidad del sistema, emitir
las recomendaciones pertinentes y aprobarlo formalmente.
9
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
14. Participar y aprobar el plan de pruebas y paralelo, y emitir, para tal efecto, las
recomendaciones pertinentes.
15. Colaborar activamente con el Líder Técnico en el levantamiento de datos para
las pruebas y paralelo del sistema.
16. Asignar personal de su área funcional para la digitación de datos no
disponibles automáticamente.
17. Participar activamente en las pruebas integradas del sistema, formular las
recomendaciones pertinentes velando porque éste se ajuste al prototipo y
diseño final aprobados, con exactitud y completitud conforme a los resultados
deseados.
18. Identificar a los funcionarios que deberán recibir entrenamiento para el
paralelo.
19. Participar activamente en la ejecución del paralelo, llevando registro de las
modificaciones requeridas.
20. Identificar al personal de su área funcional, que requerirá entrenamiento en la
operación del sistema.
21. Participar en el planeamiento y ejecución del plan de capacitación.
22. Revisar y aprobar los manuales del usuario, capacitación, y operación del
sistema.
23. Participar activamente en la planificación e implantación del sistema.
24. Hacer un seguimiento del sistema
recomendaciones que procedan.
post-implantación
y
emitir
las
25. Participar en la evaluación posterior a la implantación del sistema, llevando a
cabo un análisis de los beneficios reales contra los planeados.
1.1.5.
Líder Técnico del proyecto
Este es un funcionario al cual, por su formación en el área de informática, experiencia y
capacidad, se le ha conferido la responsabilidad de administrar los aspectos tecnológicos
de un proyecto de desarrollo informático. Puede asumir la Dirección del Proyecto en casos
justificados.
Es el responsable directo del desarrollo del proyecto en lo que corresponde a la parte
técnica, para ello aplica la metodología de trabajo aprobada por la Unidad de Sistemas y
Tecnología.
Características Técnicas
10
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
El Líder Técnico debe tener las siguientes características:
-
Ser un individuo con una preparación académica adecuada que lo faculte para
llevar a cabo con éxito, el seguimiento, y el desarrollo de un proyecto de
sistemas de información. A la vez, debe ser una persona experimentada,
tanto en el desarrollo de sistemas de información, como también en su
administración.
-
Tener capacidad de asimilar, con acierto, 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 Organización.
-
Mantener una constante preocupación por mantenerse actualizado acerca de
los últimos avances en la tecnología informática, con el objetivo de analizarlos
y determinar su aplicabilidad o adaptabilidad, si esto fuese requerido.
Responsabilidad principal
-
Colaborar con la Administración en llevar con éxito las fase de un proyecto de
desarrollo informático, sea en forma interna o servicio contratado, con
eficiencia y eficacia.
Funciones
1. Elaborar los planes del proyecto de desarrollo requeridos y correspondientes a
cada una de las fases de desarrollo de un sistema de información, de acuerdo
con la metodología y estándares vigentes, en el caso de desarrollo interno.
2. Revisar los planes propuestos por el contratista e identificar y sugerir las
modificaciones necesarias, para salvaguardar los intereses del usuario y de la
Contraloría General de la República, en caso de contratación externa.
3. Llevar un control de toda la información (documentación) que se genera en
torno al proyecto tanto formal como informal, con el objetivo de respaldar
cualquier incidente, debido a problemas de comunicación; para cada reunión éste debe ser el responsable de preparar la minuta respectiva.
4. Supervisar y controlar la ejecución real del proyecto, de acuerdo con los
estándares vigentes, para verificar la observación de los planes y etapas
específicas, con la finalidad de identificar oportunamente cualquier desfase o
incumplimiento, interno o externo, y tomar las medidas correctivas.
5. Detectar y analizar cualquier problema actual o potencial que ocasione
variación sobre lo planeado, coordinando las medidas correctivas con el
usuario responsable.
6. Identificar y gestionar cualquier intervención o ayuda requerida, para el
desarrollo del proyecto.
11
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
7. El Líder Técnico debe preocuparse por estar al corriente de cualquier cambio
en las políticas y procedimientos administrativos o en su entorno, con la
finalidad de evaluar y, de ser necesario, considerar estos cambios en el
proyecto bajo su responsabilidad.
8. Resolver los problemas y conflictos internos del proyecto que estén a su
alcance y elevar a los mandos superiores los que no pueda solucionar.
9. Presentar y justificar técnicamente el proyecto tanto frente a los usuarios, como
a otros coordinadores técnicos y jefaturas de Informática.
10. 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 estándares vigentes y los planes. Por otra parte, identificar
las modificaciones necesarias y presentar las recomendaciones pertinentes
para su consideración, por parte del usuario responsable, las jefaturas de
Informática y el contratista si lo hubiera.
11. Revisar y evaluar cualquier recomendación hecha por un miembro del proyecto
antes de presentarla a otras personas o ante una eventual empresa
contratada.
12. Evaluar, a través del desarrollo del proyecto, el desempeño de los funcionarios
de la Contraloría General de la República, con la finalidad de que se
implementen las medidas correctivas en forma oportuna, de ser necesario.
13. Mantener una estrecha relación con los otros Líderes Técnicos de proyecto, el
Equipo de Apoyo Tecnológico, el coordinador de proyecto y el Jefe de la USTI
con la finalidad de determinar los enlaces requeridos entre sistemas; analizar
la viabilidad técnica 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,
comunicación, y topología.
14. Administrar con responsabilidad y discreción toda aquella información que, por
su índole, lo amerite.
15. Ofrecer continuos aportes y sugerencias de acuerdo con su conocimiento y
experiencia en el uso de metodología, y estándares, que coadyuven en su
depuración y mejoramiento, con la finalidad de "eficientizar" los métodos de
trabajo.
16. Mantener informado al Líder del Proyecto y jefaturas de Informática, acerca de
la ejecución del proyecto
En particular, si el proyecto se desarrolla bajo el esquema de subcontratación, en lugar de
coordinar al equipo de apoyo tecnológico, tendría las siguientes funciones:
1. Efectuar el control de calidad de los productos que entregue el proveedor o
desarrollador contratado.
12
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2. Garantizar una transferencia tecnológica adecuada, de tal forma que
inmediatamente que el proveedor entregue la herramienta pueda ser
administrada técnicamente por la Unidad de Sistemas y Tecnología de
Información.
3. Fungir como facilitador técnico para el desarrollador contratado, de tal forma
que sea un proveedor oportuno de la información técnica que requiera, para
que el proyecto se desarrolle sin contratiempos.
4. Velar por el cumplimiento de los tiempos de entrega de los productos, según lo
acordado con el proveedor o desarrollador contratado. Proponer acciones
correctivas en caso de desfases.
5. Fungir como contraparte técnica por parte de la Contraloría General en
defensa de los intereses institucionales, velando por el debido cumplimiento de
los compromisos suscritos por el proveedor o desarrollador contratado
1.1.6.
Equipo de apoyo tecnológico
Son los funcionarios especialistas en el área de tecnologías de información que en caso de
ser necesario apoyan la labor del Líder Técnico, en materias tales como programación,
base de datos, operación de equipos principales, y comunicaciones.
Reporta al Jefe de la USTI.
1.1.7.
Equipo de trabajo
Son usuarios de los procesos funcionales del sistema por desarrollar, son conocedores de
la función o funciones particulares por automatizar.
Entre sus responsabilidades se destacan las siguientes:
1.2.
-
Ofrecer toda la información y colaboración necesaria al Líder Técnico, en todas
las etapas, actividades y tareas que lo requiera.
-
Atender las tareas que el Líder del Proyecto en coordinación con el Líder
Técnico, les asignen en el desarrollo del proyecto.
-
Reportan al usuario responsable.
Propiedad del Sistema de Información y sus datos
Para todo sistema que se implemente en la Contraloría General de la República se respetarán
los siguientes acuerdos de propiedad del Sistema de Información y sus datos:
Dueño del Sistema: Es la Unidad Patrocinadora, por lo tanto será la responsable de velar
por la calidad de los datos que se incluyan en el sistema de información. Dentro de este
concepto de calidad se toman en cuenta aspectos como: actualización, oportunidad,
completitud y veracidad.
Así mismo será el responsable de autorizar:
13
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
-
Los cambios en los usuarios asignados a los roles definidos para el sistema de
información (inclusión y exclusión de usuarios).
-
El acceso a la información por medio de herramientas ajenas al Sistema de
Información (Herramientas de Extracción y Análisis de Datos o similar)
-
Velar por un uso adecuado y confidencial de las palabras de paso para el
acceso al Sistema de Información.
-
Tramitar la inscripción del sistema como un producto de software cuya
propiedad intelectual y derechos de autor le pertenecen a la Contraloría
General de la República, con base a los procedimientos establecidos.
Custodio del Sistema: Es la Unidad de Sistemas y Tecnologías de Información, por lo
cual deberá:
-
Garantizar la disponibilidad de la información lo que implica un sistema
adecuado de respaldo, continuidad y contingencia.
-
Garantizar razonablemente la seguridad de la información, evitando el acceso
no autorizado a los datos y la protección de las palabras de paso de los
usuarios.
-
Disponer de un adecuado sistema de respaldo de los programas fuentes.
Usuario del Sistema: Se considera todo aquel individuo (funcionario o no de la Contraloría
General) que tenga un acceso autorizado al Sistema de Información. Se definen dos tipos
de usuario, de acuerdo a sus roles:
-
Usuario Generador de Información: Con autorización para insertar, modificar
y borrar información, quienes serán los responsables directos de asegurar la
calidad de la información (actualización, completitud y veracidad de los datos).
Este tipo de usuario deberá exigir al Líder de Proyecto un adecuado
entrenamiento en el uso del sistema y deberá hacer un uso exhaustivo del
Manual de Usuario que se genere.
Asimismo será el responsable de mantener bajo una estricta confidencialidad
la palabra de paso de acceso al sistema y de cambiarla al menos una vez al
mes.
En el caso de que por alguna razón este tipo de usuario deje las funciones que
le requerían su interacción con el sistema deberá solicitar al dueño del
sistema, que le sea retirado su acceso al mismo. En cualquier caso la Unidad
de Sistemas y Tecnologías de Información, con base en un listado enviado por
la Unidad de Recursos Humanos u otros medios, procederá en forma periódica
a deshabilitar los usuarios de aquellas personas que hayan dejado de laborar
para la institución.
-
Usuario de Consulta: Es su responsabilidad el uso adecuado de la
información obtenida a través del sistema de información y evitar la divulgación
no autorizada de la misma.
14
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
1.3.
Definición del ambiente administrativo
Esta actividad se realizará si se estima pertinente para lo cual se buscará el personal
administrativo para su elaboración.
Identificar y definir los requerimientos del ambiente administrativo para el nuevo sistema, a
saber:
-
Modificaciones a las políticas y estrategias de la unidad organizacional.
-
Modificaciones a la estructura de funciones y responsabilidades de la unidad
organizacional.
-
Creación o modificación de procesos o procedimientos administrativos.
Realizar un análisis administrativo de la Unidad, de las funciones y del entorno, con el
propósito de determinar los procesos mal ubicados o innecesarios que no requieran ser
automatizados, así como la necesidad de definición y documentación de los procedimientos
existentes.
1.4.
Proceso de contratación externa ("outsourcing")
En caso de que se seleccione un proceso de contratación externa para el desarrollo de la
solución, se deberá iniciar con los trámites de acuerdo al procedimiento establecido para el
caso.
15
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2. Fases para el desarrollo de sistemas
2.1.
Solicitud para el desarrollo de un Sistema de Información
Esta es la primera fase para la formulación de un proyecto que conlleve al desarrollo de un
nuevo Sistema de Información o a la construcción de un nuevo módulo en un sistema ya
existente.
2.1.1.
Consideraciones
La solicitud para el desarrollo de un sistema de información debe ser elaborada por un
funcionario con jerarquía, quién en adelante será referido como patrocinador.
Como parte de la solicitud del proyecto se deben establecer los requerimientos de
operación y su factibilidad para asegurar que el sistema desarrollado contará con el
entorno adecuado de funcionamiento.
La comunicación al patrocinador del resultado del estudio de su solicitud debe ser realizada
por la Jefatura de la USTI a través de un memorando de respuesta.
La Jefatura de la USTI analizará la solicitud. Por medio de un estudio debidamente
justificado puede determinar que ésta procede y se asigna un analista de sistema para que,
junto con el Líder de Proyecto, complete el “Informe de Diagnóstico” que le permita detallar
y justificar la solución de desarrollo de un sistema de información. Si el estudio realizado
por la Jefatura de USTI determina que la solicitud no procede, se le remite un memorando
al patrocinador en el cual se indican los factores por los cuales la solicitud no es aceptada.
Basado en las alternativas señaladas en el “Informe de Diagnóstico” el Patrocinador del
proyecto efectuará la solicitud formal del mismo para que sea considerado dentro de la
planificación de la USTI y se determine la forma en que dicho proyecto será realizado.
La USTI mantendrá una cartera de proyectos formulados y el Comité Gerencial de
Informática tendrá conocimiento sobre esto y será el ente que determine las prioridades
con que los proyectos serán atendidos de acuerdo con el Plan Estratégico de la Función
Informática.
En la siguiente figura se resume el proceso de solicitud para el desarrollo de un Sistema de
Información:
16
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Factores de
no aceptación
Memorando
Memorando
de
deSolicitud
Solicitud
Recepción de la
Solicitud
Análisis
Análisis
Jefatura
Jefatura
de
delalaUSTI
USTI
Detalle y
Justificación del
proyecto
Informe
Informede
de
Diagnóstico
Diagnóstico
Archivo
Notificación de
resultados
Selección
Selecciónde
delala
Solución
Solución
Desarrollo del Sistema
Figura No. 1: Proceso de trámite de una solicitud
2.1.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y que
formarán parte del expediente o archivo del proyecto.
En lo referente a la fase de Solicitud para el Desarrollo de un Sistema de Información se
identifican los siguientes entregables:
-
-
Solicitud del sistema: donde se expresa la necesidad, los beneficios, y la
justificación de desarrollar un nuevo sistema de información incluyendo la
información que sea solicitada por la USTI.
Informe de diagnóstico: donde se especifican los resultados de la valoración
efectuada sobre la solicitud señalando las posibilidades de solución para la
realización del sistema.
-
Notificación del resultado del estudio: a través de este documento el Jefe
de la USTI, o quien éste designe, hará del conocimiento del Patrocinador los
resultados del estudio.
-
Selección de la solución: en este documento el Patrocinador del proyecto
indica su criterio sobre la forma de proceder en el trámite de la solicitud basado
en los resultados obtenidos en el Diagnóstico realizado por la USTI. En la
selección de la alternativa el Patrocinador puede tomar alguna de las
siguientes decisiones:
17
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
-
2.1.3.

Seleccionar alguna de las alternativas recomendadas

Posponer el proyecto para un momento más oportuno, esto de
acuerdo con los intereses y prioridades de la Institución

Cancelar el proyecto ya que el mismo no es viable desde el punto de
vista operativo, económico o técnico o porque las prioridades
Institucionales así lo requieren.
Solicitud formal del proyecto: Cuando el patrocinador haya seleccionado la
solución que considere más adecuada deberá realizar la presentación formal
del proyecto incluyendo la información que sea solicitada por la Unidad de
Sistemas y Tecnología de Información.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Patrocinador
Solicitud del
sistema
Informe de
Diagnóstico
Notificación del
resultado del
estudio
Selección de
solución
Solicitud formal
del proyecto
Hacer
2.1.4.
Hacer
Jefe USTI
Líder de
Proyecto
Líder Técnico
Apoyar y
aprobar
Hacer
Hacer
Apoyar
Apoyar
Apoyar
Hacer
Solicitud del sistema
El Patrocinador elabora la solicitud de desarrollo de un nuevo sistema de información
especificando claramente el objetivo, alcances, beneficios, personal de contraparte y
solución esperada de dicho proyecto.
La Jefatura de la USTI analizará la solicitud. Por medio de un estudio debidamente
justificado puede determinar que ésta procede y se asigna un analista de sistema para que,
junto con el Líder de Proyecto, complete el “Informe de Diagnóstico” que le permita detallar
y justificar la solución de desarrollo de un sistema de información. Si el estudio realizado
por la Jefatura de USTI determina que la solicitud no procede se le remite un memorando
al patrocinador en el cual se indican los factores por los cuales la solicitud no es aceptada.
2.1.5.
Informe de Diagnóstico
Este documento es confeccionado en conjunto por el Líder Técnico y el Líder de Proyecto
o contraparte asignada y deberá contener las siguientes secciones:
18
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
1. Alcances
Los alcances establecen, de manera clara, hasta dónde llegará el proyecto del
sistema de información y deberán permitir el manejo de expectativas comunes
entre todos los interesados y participantes del proyecto.
Deberá incluir al menos una descripción del sistema de información que se
pretende obtener y hasta dónde se desea llegar, de manera que se conozca el
punto de finalización del proyecto.
2. Objetivos
Definición de los objetivos generales y específicos esperados con el sistema o
solución
3. Análisis de la situación actual
El Líder Técnico con la colaboración del Líder de Proyecto o contraparte debe
realizar un análisis de la situación actual donde se describa la forma como el
proceso se está realizando ya sea por un sistema anterior o de forma manual.
En este análisis se debe hacer énfasis en la búsqueda de oportunidades de
mejorar los procesos actuales en procura de que el nuevo sistema permita la
realización de actividades de forma más eficiente y efectiva.
4. Análisis de riesgo
El Líder Técnico conjuntamente con el Líder de Proyecto o contraparte
asignada deberá hacer un análisis de riesgos del proyecto basándose en
cuatro aspectos fundamentales:
a. Tamaño y complejidad: Lo cual tiene una estrecha relación entre el tiempo y
costo asociado al proyecto.
b. Tipo de tecnología: Experiencia anterior con el tipo de tecnología a utilizar y
el tipo de sistema.
c. Grado de estructuración: Definición y variabilidad de los procesos y del
equipo de trabajo.
d. Grado de impacto: A mayor impacto y cobertura (departamental, institucional
u organizacional) mayor riesgo debido a que implica un alto grado de
coordinación y comunicación
Este análisis tendrá como objetivo dar insumos para la selección de la
estrategia de desarrollo más adecuada.
5. Identificación de soluciones y su prefactibilidad
Establecer las diferentes alternativas (al menos dos) para la construcción del
nuevo sistema de acuerdo a los alcances definidos.
19
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Realizar un análisis de costo/beneficio de las soluciones propuestas para hacer
una evaluación de su prefactibilidad económica definida en términos de costos
y ahorros. No sólo tomando en cuenta los costos de implementación del
sistema o solución sino también los costos asociados a la actualización
permanente de la información.
Para ellos se debe calcular el costo en cantidad de funcionarios y el tiempo
laboral requerido, el equipo y las herramientas a utilizar. En el caso del ahorro
se deben considerar los beneficios tangibles e intangibles que se obtienen con
el sistema, por ejemplo: tiempo requerido para la actualización o conclusión del
proceso, desplazamiento de personas, aprovechamiento de equipo y las
herramientas existentes.
El nivel de detalle de esta evaluación dependerá directamente de la
complejidad del sistema y del tamaño de los recursos disponibles para la
elaboración del estudio. En cualquier caso deberá contemplar las variables
básicas que determinen la viabilidad del sistema y su permanencia en el
tiempo.
Para cada una de las alternativas se deberá identificar:

Ventajas y desventajas operativas y técnicas

Riesgos asociados

Factibilidad operativa y técnica

Complejidad técnica en el desarrollo y en la implementación

Y en forma deseable la factibilidad económica
6. Recomendación de una solución
Basado en las consideraciones anteriores, el equipo de trabajo emitirá una
recomendación que provea al patrocinador del proyecto la suficiente
información para determinar si el proyecto deberá continuar a las siguientes
fases o no.
En dicha recomendación se considerará:
2.1.6.

Funcionalidad

Impacto en la unidad o unidades

Costos implícitos estimados
Solicitud formal del proyecto:
Cuando el patrocinador haya seleccionado la solución que considere más adecuada
deberá realizar la presentación formal del proyecto incluyendo la información que sea
solicitada por la Unidad de Sistemas y Tecnología de Información.
20
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Esta solicitud se analizará por la Jefatura de la USTI y se efectuará una comunicación al
patrocinador sobre la forma en que su proyecto será atendido, el cual podrá señalar alguna
de las siguientes decisiones:
a. Se acepta la solicitud y su atención se realizará mediante desarrollo interno para lo
cual se nombrará el Líder Técnico y un Líder de Proyecto.
b. Se acepta la solicitud pero su atención se recomienda bajo desarrollo externo, para
lo cual se nombrará un Líder Técnico para la coordinación del proyecto de
desarrollo.
c.
Se acepta la solicitud pero su atención no será inmediata; se establece una fecha
probable de inicio.
21
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.2.
Análisis integral de requerimientos
2.2.1.
Consideraciones
Con el análisis integral de requerimientos del sistema a automatizar se espera:
-
-
Identificar, analizar y documentar los requerimientos funcionales y nofuncionales que debe soportar el sistema o solución propuesta, obteniendo un
diagnóstico de situación actual.
Priorizar los requerimientos que ha de cubrir el nuevo sistema o solución,
convirtiéndose en punto de referencia básico para validar el sistema final,
comprobando que se ajusta a las necesidades del usuario.
El proceso de análisis de requerimientos se puede representar en la siguiente figura:
Solicitud
Cumplimiento
de objetivos
Especificación
Especificación
de
derequerim.
requerim.
Priorización
Priorización
de
derequerim.
requerim.
Estudio y
retroalimentación
Detalle de los
requerimiento
Análisis
Análisisde
de
Requerim.
Requerim.
Resultados
de la fase
Confecc.
Confecc.Doc.
Doc.
de
deAnálisis
Análisis
Diseño conceptual
Figura No. 2: Proceso de Análisis de requerimientos
El usuario o usuarios del futuro sistema deben realizar la especificación de los
requerimientos funcionales y no funcionales del nuevo sistema los cuales deberá ser
priorizados de acuerdo a su grado de aporte a la consecución de los objetivos del proyecto.
Estos requerimientos serán analizados por los Analistas de Sistemas asignados al proyecto
con el apoyo del Líder Técnico y si fuera necesario se podrá solicitar a los usuarios
profundizar en la especificación de uno o varios de los requerimientos con la finalidad de
que éstos sean lo más claros y específicos posibles.
22
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
En el proceso de análisis se debe identificar los recursos requeridos por el proyecto; así
como los requerimientos críticos para el éxito del mismo. Con esta información se
confeccionará el “Documento de Análisis” el cual contendrá el cronograma respectivo para
la conclusión del proyecto.
2.2.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y que
formarán parte del expediente o archivo del proyecto.
En lo referente a la fase de análisis integral de requerimientos para el Desarrollo de un
Sistema de Información se identifican los siguientes entregables:
-
Especificación de requerimientos: se entiende por especificación de
requerimientos como la descripción precisa y detallada que hace el usuario de
las necesidades a ser resueltas con el sistema solicitado y sus restricciones.
-
Priorización de requerimientos: se refiere a la consideración del
Patrocinador o Líder del Proyecto en cuanto al nivel de urgencia en la
resolución de los aspectos solicitados en función de los objetivos del proyecto.
El propósito de esta valoración es ofrecer un criterio en la toma de decisiones
que afecten el proyecto.
-
Documento de análisis: en este documento se presentan los resultados
obtenidos en la fase de Análisis y debe hacer referencia a los recursos
requeridos para la realización del proyecto, valoración preliminar de
requerimientos y la propuesta del cronograma para la completitud del proyecto.
2.2.3.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Patrocinador
Especificación de Apoyar
requerimientos
Priorización de
requerimientos
Documento de
análisis
2.2.4.
Líder de Proyecto Líder Técnico
o Usuario experto
Hacer
Apoyar
Hacer
Analista de
Sistemas
Apoyar
Apoyar
Apoyar
Hacer
Especificación de requerimientos
La especificación de requerimientos es la descripción precisa y detallada que hace el
usuario de las necesidades a ser resueltas con el sistema solicitado y sus restricciones.
Para ello, el Líder Técnico debe trabajar en conjunto con el Comité de Usuarios, de manera
que generen experiencia en traducir en requerimientos (descripción precisa y detallada de
la funcionalidad del sistema), las necesidades que poseen y le sean muy comprensibles.
Para lograr este propósito el Líder Técnico puede aportar la documentación que considere
pertinente, como boletas, formularios y tipos de reportes.
23
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.2.4.1.
Requerimientos funcionales
Son las indicaciones de servicio que el sistema debe proveer en cuanto a actualización
de datos, opciones de consulta, reportes a generar, interacción con otros sistemas,
bitácoras de seguimiento y pistas de Auditoria (en coordinación con la Auditoria
Interna).
Entre las características que se espera que posean los requerimientos son:
-
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 implementación del sistema.
-
Factible: Se refiere a la posibilidad técnica, operativa 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 estándar. Debe poder
indicarse el rastro del requerimiento desde su origen, de tal forma que sea
válido 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 específicas del sistema.
-
Verificable: Un requerimiento es verificable si se puede utilizar algún tipo de
pruebas tales como inspección o demostración para determinar si el
requerimiento soporta las necesidades de los usuarios a través del producto.
Si el requerimiento no es verificable determinar si se implementó
correctamente o no es un asunto de opinión.
2.2.4.2.
Requerimientos no funcionales
Son las propiedades y restricciones del sistema, pueden ser de índole organizacional,
como consecuencia de alguna política organizacional o de procedimiento, o pueden
ser de operabilidad como los son: confiabilidad, tiempo de respuesta, almacenamiento,
capacidades de dispositivos de E/S, migración de herramienta, y conversión de
archivos.
2.2.5.
Priorización de requerimientos
Implica asignar una prioridad a cada requerimiento o característica para indicar que tan
esencial es incluirlo en el lanzamiento de la próxima versión del sistema. Los usuarios
tienen una gran cuota de responsabilidad en definir las prioridades. Si todos los
requerimientos tienen igual prioridad, se limita la capacidad de reacción del Líder de
Proyecto ante nuevos requerimientos determinados durante el desarrollo, recortes en
24
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
el presupuesto, la salida de un miembro del equipo u otras situaciones inesperadas.
La prioridad se debe calcular como una función del valor que agrega el requerimiento a
la función del cliente, el costo relativo de implementación y el riesgo técnico asociado a
esta implementación.
Se recomiendan tres niveles de prioridad:
-
Alto: El requerimiento debe incluirse en la próxima entrega del producto.
-
Medio: El requerimiento es necesario pero puede ser incluido en otra versión.
-
Bajo: Sería bueno contar con el requerimiento sin embargo no es
imprescindible.
2.2.6.
Documento de análisis
Este documento reúne los resultados del proceso de análisis y será la base, en
conjunto con la especificación de requerimientos, para la planificación de las fases
posteriores en lo referente a la construcción del sistema.
Debe contener, al menos, la siguiente información:
2.2.6.1.
Identificación de recursos
Identificación de los requerimientos de recurso humano, "hardware", "software",
comunicaciones, ambiente físico, volumen de datos, materiales, capacitación y otros.
Si al ejecutar esta tarea se tiene un estimado de los recursos requeridos para las
etapas de Construcción e Implantación, esto puede ser descrito en esta tarea, revisado
y ajustado más adelante.
2.2.6.2.
Matriz de requerimientos
Los requerimientos presentados por el Patrocinador, Líder de Proyecto o Usuarios se
analizan para identificar los siguientes elementos de cada solicitud:
-
Identificación del requerimiento: Puede ser una secuencia o código que
identifique de manera única al requerimiento (en el proyecto o sistema actual)
-
Breve descripción: Breve descripción y propósito del requerimiento
-
Prioridad: asignada por el Patrocinador o Líder del Proyecto. Se recomienda
utilizar tres valores posibles en concordancia con la priorización de
requerimientos, es decir, Alto, Medio y Bajo
-
Complejidad: nivel de dificultad para la solución de lo solicitado. Se
recomienda utilizar tres valores posibles: Alto, Medio y Bajo
-
Tipo de requerimiento: Identificar si se trata de requerimiento funcional o
requerimiento no funcional
-
Dependencia con otros requerimientos: Hacer referencia a los
requerimientos que están relacionados y que de alguna manera representan
una dependencia; es decir, que para su atención se requiera resolver
25
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
previamente otros requerimientos o que su atención es obligatoria para el
cumplimiento de otros aspectos.
-
Tiempo estimado de construcción: estimación preliminar del tiempo
requerido para la atención del requerimiento. Se debe utilizar una unidad de
medida uniforme para cuantificar todos los requerimientos (horas, días,
semanas)
Seguidamente se presenta un ejemplo de la matriz de requerimientos:
ID
Descripción del req.
Prioridad
Complejidad
Tipo Req.
Dependencia
Días const.
Con esta matriz se puede realizar un análisis cuantitativo de los requerimientos que
permita identificar aquellos que son críticos para el éxito y completitud del proyecto;
además ofrece un elemento importante para la toma de decisiones por parte del Líder
de Proyecto y Líder Técnico.
2.2.6.3.
Definición de infraestructura tecnológica
Se debe detallar la infraestructura computacional que soportará el sistema, a nivel de
equipo principal y de usuarios, lenguaje de programación y especificación de la base
de datos; y cualquier otro aspecto requerido para efectos de desarrollo. En términos
generales, el tipo de tecnología a utilizar dependiendo del tipo de sistema.
2.2.6.4.
Selección de la estrategia de desarrollo
Luego de realizar todo el estudio de requerimientos y modo de operación del sistema,
se debe seleccionar la estrategia de desarrollo, esto es, si el mercado ofrece un
paquete similar que se ajuste a lo solicitado, si se contrata una empresa que lo realice
o si se construye internamente.
2.2.6.5.
Cronograma de las fases posteriores del proyecto
Confección del cronograma detallado del proyecto para las siguientes etapas indicando
las fechas de inicio y finalización para cada una de ellas así como los responsables de
las actividades. El cronograma será desarrollado utilizando software especializado y
aprobado por la USTI.
26
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.3.
Diseño conceptual de la solución
2.3.1.
Consideraciones
Esta fase tiene el propósito de identificar los primeros elementos de diseño del nuevo
sistema. Los insumos principales de esta fase son: el documento de especificación de
requerimientos y el documento de análisis.
En la siguiente figura se diagraman las principales actividades de esta fase:
Documento de
Análisis
Especificación de
Requerimientos
Identificación
Identificación
Módulos
Módulos
Diseño
conceptual
Identificación
Identificación
Roles/Usuarios
Roles/Usuarios
Integración
Integraciónde
de
Sistemas
Sistemas
Diseño detallado
Figura No. 3: Proceso de diseño conceptual
2.3.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y que
formarán parte del expediente o archivo del proyecto.
En lo referente a la fase de diseño conceptual de la solución para el Desarrollo de un
Sistema de Información se identifican los siguientes entregables:
-
Documento de diseño conceptual: a través de este documento se presentan
los resultados de la primera actividad de diseño como la descripción general
de procesos, identificación de relaciones de integración de sistemas, y la
identificación de usuarios y roles. Tiene el propósito de mostrar, de manera
general, cómo estará constituido el nuevo sistema y será la base, en conjunto
con la especificación de requerimientos, del diseño detallado del sistema.
27
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.3.3.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Jefe USTI
Líder Técnico
Documento de
diseño conceptual
Aprobar
Hacer
2.3.4.
Analista de
Sistemas
Hacer
BDA
Apoyar
Documento de diseño conceptual
Este documento deberá contener, al menos, la siguiente información:
2.3.4.1.
Descripción de entradas, procesos y salidas
Consiste en desagregar los módulos identificados en una
las entradas, los procesos y las salidas que considera
estándar fijado. Para la conformación de esta tabla
herramienta de software aprobada por la USTI para la
contexto y diagrama de flujos de datos.
2.3.4.2.
tabla en la cual se describen
el sistema y de acuerdo al
el desarrollador utilizará la
confección del diagrama de
Identificación de interrelaciones entre sistemas o módulos
Se refiere a la identificación de sistemas o módulos que estarán relacionados con el
sistema en construcción y la descripción de estas relaciones en lo referente al tipo y
método de comunicación. Además, se debe indicar si es requerida la modificación de
algún sistema existente para ajustarlo a la solución que se está diseñando.
En esta actividad es importante que se analice la estructura de datos existente en los
sistemas que estarán relacionados para la creación de un modelo lógico de datos en la
siguiente fase.
2.3.4.3.
Identificar tipos de usuarios
Identificar los tipos de usuarios y el rol a cumplir por ellos dentro del sistema,
especificándose quiénes pueden ingresar, modificar, borrar o consultar información y
cuál información. Qué tipos de usuarios utilizan cada uno de los módulos y qué
funciones lleva a cabo.
28
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.4.
Diseño detallado de la aplicación
2.4.1.
Consideraciones
El diseño detallado de la solución establece, con mayor detalle, las características que
tendrá el nuevo sistema. Además, será la base para la fase de construcción o
programación de los módulos.
La base de información para las actividades del diseño detallado son los documentos de
especificación de requerimientos, documento de análisis y diseño conceptual.
El documento de diseño conceptual debe especificar los módulos que tendrá el sistema,
características de validación y restricciones sobre los elementos de datos, especificación
de procesos, detalle de controles y seguridad, características de la interfaz de usuario y
principales reportes que ofrecerá el sistema. Todos estos aspectos serán identificados con
base en los requerimientos funcionales del proyecto y, de ser necesario, de las consultas
efectuadas a los usuarios, Líder de Proyecto o contraparte y Patrocinador del proyecto.
En la siguiente figura se muestra el esquema funcional de esta etapa en la construcción de
sistemas:
Insumos
Productos
Especificación
Especificación
Requerim.
Requerim.
Doc.
Doc.de
de
Análisis
Análisis
Diseño
Diseño
conceptual
conceptual
Diseño detallado
Doc.
Doc.Diseño
Diseño
Detallado
Detallado
•Definición de procesos
•Diagrama lógico de datos
•Identificación de módulos
•Definición de dominios
•Volúmenes de datos
•Controles y Seguridad
•Interfaz de usuario
•Reportes
Programación
Figura No. 4: Proceso de diseño detallado
El diseño detallado de la aplicación 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
estándares de la Unidad y que es consistente con la planificación de crecimiento
tecnológico de la Institución. Dicha revisión debe ser consignada como visto bueno del
documento.
29
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.4.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y que
formarán parte del expediente o archivo del proyecto.
En lo referente a la fase de diseño detallado para el Desarrollo de un Sistema de
Información se identifican los siguientes entregables:
-
Documento de diseño detallado: se refiere al documento donde se
describen, con más detalle los elementos del nuevo sistema como descripción
de módulos, modelado de datos, procesos, controles de acceso y seguridad,
interfaz de usuario y reportes.
-
Diseño de pruebas: se refiere a un documento donde se estipulan los
aspectos a considerar en el proceso de pruebas, con el propósito de contar
con el suficiente tiempo para su planificación.
2.4.3.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Líder de
Proyecto o
Usuario experto
Documento de
diseño detallado
Diseño de
pruebas
2.4.4.
Hacer
Líder Técnico
Analista de
Sistemas
DBA
Hacer
Hacer
Apoyar
Revisar
Hacer
Documento de diseño detallado
Este documento deberá contener, al menos, la siguiente información:
2.4.4.1.
Definición de procesos
Profundizar en el diseño de procesos realizado en la etapa anterior describiendo en
detalle lo que cada proceso debe realizar. Deben confeccionarse diagramas de flujo de
los datos y la descripción precisa de fórmulas y reglas de excepción.
2.4.4.2.
Diagrama lógico del modelo de datos
Especificación del modelo entidad-relación del sistema, de la composición física que
tendrán las tablas relacionales y su normalización. Este modelo debe ser validado por
el DBA.
2.4.4.3.
Descripción de módulos y sub-módulos y su interacción
Con base en el diseño conceptual de la solución, se detalla la estructura modular del
sistema en cuanto a la jerarquía de los módulos y la forma en la que interactúan, por
medio de un diagrama de bloques o similar.
30
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.4.4.4.
Definiciones de dominios para los datos
Se refiere a la especificación de aspectos como:
-
Formato
Valor que asume por defecto
Rango de valores permisibles
Listas de valores
Mensajes informativos sobre los elementos
Además se deben especificar las restricciones a nivel de bases de datos.
2.4.4.5.
Estimación del volumen de datos
Estimación 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
2.4.4.6.
Definición de controles y seguridad a utilizar
Definir los puntos de control que garanticen la seguridad, integridad y confidencialidad
de la información a nivel de roles en la base de datos y control de acceso a las
transacciones en la aplicación. Se deben identificar los tipos de eventos que deberán
dejar registros de auditoria, bitácoras y otros controles que se estimen pertinentes.
2.4.4.7.
Ajuste de la interfaz de usuario al estándar
Establecer la apariencia de las pantallas con base en los estándares establecidos.
Definir la estructuración del menú y los roles de usuario que tendrán acceso a cada
opción del sistema.
2.4.4.8.
Reportes del sistema
Se refiere a la definición y diseño de reportes que serán ofrecidos por el sistema así
como la consideración de herramientas para el usuario final con el propósito de que
éste pueda generar sus propios listados y gráficos.
2.4.5.
Diseño de pruebas:
Con la finalidad de guiar el proceso de pruebas y realizar las tareas correspondientes para
esta actividad con la debida anticipación se debe efectuar un diseño de pruebas orientadas
a:
-
Asegurar que el producto cumple con lo solicitado por los usuarios
-
Certificar que el aplicativo funciona correcta y eficientemente
El documento de diseño de pruebas debe contener los siguientes aspectos:
31
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.4.5.1.
Especificación de tipos de pruebas
Identificar los tipos de pruebas a realizar: pruebas unitarias, pruebas de módulos,
pruebas de integración, pruebas de esfuerzo, tiempos de respuesta y tráfico en la
infraestructura de comunicaciones.
2.4.5.2.
Requerimientos para las pruebas
La plataforma de “Hardware”, “Software”, conectividad y base de datos requerida. Si el
sistema tendrá integración con otros sistemas o módulos deberá disponerse de un
ambiente de pruebas de dichos sistemas.
2.4.5.3.
Casos y datos de prueba
Identificar todos los escenarios posibles con diversidad de datos de entrada y acciones
realizadas por el usuario, con el propósito de identificar posibles puntos de error en el
sistema.
Si se requiere la existencia de datos para la pruebas, se deberá señalar el método de
captura de éstos en las estructuras de la base de datos.
2.4.5.4.
Usuarios para las pruebas
Determinar las características y cantidad de los usuarios que serán requeridos en el
proceso de pruebas y el tiempo a invertir en dicho proceso. Esto es importante para
que las Unidades puedan efectuar la coordinación correspondiente con la debida
anticipación.
32
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.5.
Programación y pruebas
2.5.1.
Consideraciones
En esta fase se confeccionan los programas y se realizan las pruebas a partir de los
documentos de requerimientos, especificación de programas, análisis y diseño. Como
producto se tendrán los componentes de programación, constancia de pruebas y
aceptación 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 programación por la presencia de errores:
Diseño detallado
Construcción
Construcción
Ajustes
Ajustes
Pruebas
Pruebas
Aceptación
Aceptación
Implementación
Figura No. 5: Construcción y pruebas
2.5.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y que
formarán parte del expediente o archivo del proyecto.
En lo referente a la fase de programación para el Desarrollo de un Sistema de Información
se identifican los siguientes entregables:
-
Scripts de creación de objetos en la BD: para la creación de tablas, llaves
primarias y foráneas, índices, constraints, roles, usuarios y cualquier otro
componente de la base de datos.
33
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
-
Componentes de programación: elementos de programación como menús,
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: documentación de las pruebas donde se indiquen
los resultados obtenidos y los ajustes a realizar.
-
Aceptación del sistema: nota del Líder del Proyecto o contraparte donde se
exprese que el nuevo sistema cumple satisfactoriamente con lo solicitado y
que se pueda continuar con las actividades de capacitación e implementación.
2.5.3.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Líder de
Proyecto o
Contraparte
usuaria
Scripts de
creación de
objetos
Componentes de
programación
Constancia de
pruebas
Aceptación del
sistema
2.5.4.
Hacer y
Aprobar
Hacer
Líder Técnico
Analista de
Sistemas
DBA
Hacer
Apoyar
Apoyar
Hacer
Apoyar
Hacer
Construcción
2.5.4.1.
Implementación del modelo físico de datos
Escribir las rutinas (scripts) para la creación de objetos en la base de datos de acuerdo
con el modelo entidad relación, especificando llaves primarias y llaves foráneas, y
parámetros de almacenamiento de conformidad con el volumen de datos estimado.
Estos scripts deberán ser revisados por el Administrador de Bases de Datos y
aplicados en conjunto.
2.5.4.2.
Creación de roles y usuarios
Se crean los roles y se asocian a los usuarios según las acciones que les
correspondan. Se debe generar una rutina para la creación de los roles.
2.5.4.3.
Programación
Durante el desarrollo de esta etapa se generan los programas que componen el
Sistema de Información.
34
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
Adicionalmente el desarrollador deberá adoptar los estándares establecidos en
nomenclatura, manejo de versiones, y documentación de los programas que establece
el manual de estándares.
2.5.4.4.
Conversión y levantamiento de datos
En caso de requerirse una migración de datos desde una aplicación anterior o bien
desde un ingreso masivo de información, se deberá tomar en cuenta la depuración
que requiera esta información. El Líder de Proyecto deberá considerar este traspaso
como un subproyecto adicional, donde incluirá los requerimientos de recurso humano y
tecnológico para su ejecución, asimismo deberá negociar estos recursos. Esta
conversión o ingreso masivo de información se ejecutará durante la etapa de
implantación.
Cada uno de los módulos generados deberá estar sujeto a una revisión de su
funcionalidad por parte del Líder de Proyecto o quien él designe y a una revisión de
tipo técnico para garantizar su calidad.
2.5.5.
Pruebas
2.5.5.1.
Preparación y levantamiento de información para las pruebas
Se debe retomar el documento de diseño de pruebas para comprobar que está acorde
con las características del sistema y está vigente en cuanto a los casos de prueba a
realizar y a la definición de usuarios que van a participar en este proceso. De ser
necesario se realizará la generación de datos para las pruebas de los módulos.
2.5.5.2.
Ejecución de pruebas específicas
Se debe probar el funcionamiento (cumplimiento de los requerimientos), facilidad de
uso por el usuario (interfaz con el usuario), diálogos con el usuario y su control, de
cada pantalla con la que debe interactuar el usuario.
2.5.5.3.
Ejecución de pruebas integrales
Esta actividad requiere que se lleven a cabo tanto pruebas de todo el sistema como su
interacción con otros sistemas de manera que se cumpla con los requerimientos de
integración especificados.
2.5.5.4.
Documentación de los resultados de las pruebas
Generar la documentación que corresponda para dejar constancia del proceso de
pruebas y de los resultados obtenidos, incluso para los casos en donde éstos no son
los esperados lo cual implica ajustes a los programas y la aplicación de las pruebas
correspondientes. Es importante que quede documentado quiénes y cuándo realizaron
las pruebas y sus observaciones.
2.5.6.
Ajustes de programación
Si en la realización de pruebas se identifica la necesidad de efectuar ajustes en la
programación, después de llevarlos a cabo se deberán realizar las pruebas específicas
y de integración de manera interactiva con los usuarios; de este modo, al finalizar las
35
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
modificaciones también
satisfactoriamente.
2.5.7.
se
finalizan
las
pruebas
y
el
sistema
concluya
Aceptación del sistema
Una vez concluido el proceso de pruebas y se hayan realizado los ajustes a la
programación el Líder de Proyecto o la contraparte designada deberá manifestar si
está satisfecho con el sistema y lo da por aceptado autorizando que se proceda con su
implementación. Este criterio se debe emitir por medio de nota a la Jefatura de la
USTI.
36
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.6.
Documentación
2.6.1.
Consideraciones
La documentación del sistema se genera durante el desarrollo de todas las fases del
proyecto; sin embargo hay un conjunto de documentos específicos a generar como los
manuales de usuarios, manuales de operación y manuales técnicos.
La documentación del proyecto se debe mantener actualizada en todo momento y formará
parte de un expediente o archivo por proyecto donde todos los documentos producidos
estén reunidos.
2.6.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y que
formarán parte del expediente o archivo del proyecto.
En lo referente a la fase de documentación para el Desarrollo de un Sistema de
Información se identifican los siguientes entregables:
-
Manual de usuario: guía para la utilización del sistema por los usuarios.
-
Manual técnico: descripción, a nivel técnico, de todos los componentes del
sistema.
-
Manual de operación: descripción de procesos operativos del sistema.
2.6.3.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Manual de
usuario
Manual técnico
Manual de
operación
2.6.4.
Líder de Proyecto o
Usuario experto
Aprobar
Líder Técnico
Analista de Sistemas
Apoyar
Hacer
Apoyar y aprobar
Apoyar y aprobar
Hacer
Hacer
Documentación del proyecto
Son todos los documentos generados por su organización y ejecución. El archivo del
proyecto debe contener los documentos señalados como entregables en cada una de las
fases:
-
Documentos de organización del proyecto
 Cronograma original
 Cronograma ajustado
 Correspondencia generada
37
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
-
Solicitud para el desarrollo de un sistema de información
 Memorando de solicitud
 Informe de diagnóstico
 Memorando de resultado del estudio
 Selección de la solución
 Solicitud formal del proyecto
-
Análisis integral de requerimientos
 Especificación de requerimientos
 Priorización de requerimientos
 Documento de análisis
-
Diseño conceptual de la solución
 Documento conceptual de la solución
-
Diseño detallado de la aplicación
 Documento de diseño detallado
 Diseño de pruebas
-
Programación y pruebas
 Scripts de creación de objetos
 Inventario de componentes de programación
 Constancia de pruebas
 Aceptación del sistema
-
Capacitación
 Constancia de la capacitación
-
Implementación
 Plan de implementación
 Aprobación del inicio de operación
 Entrega del sistema
-
Manual de usuario
-
Manual técnico
-
Manual de operación
2.6.5.
Manual de usuario
El manual del usuario debe ser conciso y práctico, sin dejar de ser exhaustivo, de manera
que los usuarios encuentren en él toda la información necesaria para interactuar con el
sistema. Se debe combinar la descripción textual, con la gráfica, de manera que al usuario
se le facilite su uso.
El manual debe contener lo siguiente:
-
Introducción
Estándares del Sistema
Cómo se ingresa al Sistema
Descripción del Menú Principal del Sistema
Descripción textual y gráfica de cada pantalla (sea de registro o consulta)
38
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
-
2.6.6.
Descripción del uso e impresión de reportes
Manual técnico
En este manual se deben describir, de manera detallada, todos los componentes del
sistema desde el punto de vista técnico. En dicha documentación deben explicarse todos
los aspectos necesarios para el posterior mantenimiento de la aplicación.
2.6.7.
Manual de operación
Manual donde se describan todas las actividades operativas del sistema como creación de
usuarios, procedimientos de respaldo y recuperación, procesos diarios o periódicos,
generación de datos para otros sistemas o entidades y la descripción de cualquier otro
proceso.
39
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.7.
Capacitación
2.7.1.
Consideraciones
De acuerdo con la complejidad en el uso del sistema desarrollado y de la cantidad de
usuarios del sistema, se debe coordinar el lugar, hora y cantidad de sesiones que va a
comprender la capacitación de usuarios. En caso de ser necesario se coordinará con el
Centro de Capacitación para el uso del laboratorio de microcomputadoras de manera que
la capacitación se lleve por medio de una interacción total sistema-usuario.
Se debe tomar en cuenta la coordinación para la instalación de los programas necesarios
para efectuar la capacitación.
2.7.2.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Coordinación de la
capacitación
Instalación de
programas
Realizar la
capacitación
Líder de Proyecto o
Usuario experto
Hacer
Aprobar
Líder Técnico
Analista de
Sistemas
Apoyar
Apoyar
Hacer
Apoyar
Hacer
40
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.8.
Implementación
2.8.1.
Consideraciones
El Líder de Proyecto, siguiendo criterios de impacto, materialidad, riesgo asociado,
sensibilidad y criticidad de la información 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á el verificar que el sistema
nuevo arroja resultados similares al sistema que estuviera en ese momento en
funcionamiento – manual o automatizado), pruebas de tensión cuyo objetivo es poner a
prueba al 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 tecnológicos.
El proceso se muestra en la siguiente figura:
2.8.2.
Entregables
Se entiende como entregables aquellos documentos confeccionados en esta fase y que
formarán parte del expediente o archivo del proyecto.
En lo referente a la fase de implementación para el Desarrollo de un Sistema de
Información se identifican los siguientes entregables:
41
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
-
Plan de implantación: breve documento donde se describe las actividades a
realizar para la implementación del sistema, desde el punto de vista técnico y
organizacional.
-
Aprobación del inicio de operación: nota o acta del Patrocinador donde
autoriza el inicio de operación en producción del sistema en vista de que
fueron cumplidos todos los requerimientos funcionales y no funcionales.
-
Entrega del sistema: notificación a los usuarios, administración y
administración superior, si fuera necesario, de la culminación del proyecto y el
inicio de operación del sistema.
2.8.3.
Responsabilidades
Las responsabilidades de esta fase en el Desarrollo de Sistemas se establecen de la
siguiente manera:
Actividad
Plan de
implantación
Instalación del
sistema
Levantamiento
de datos
Ejecución del
paralelo
Aprobación del
inicio de
operación
Entrega del
sistema
2.8.4.
Líder de
Proyecto o
Contraparte
Usuaria
Hacer y aprobar
Líder Técnico
Analista de
Sistemas
DBA
Hacer y aprobar Apoyar
Apoyar
Hacer
Apoyar
Hacer
Apoyar
Hacer / Apoyar
Apoyar
Hacer
Hacer
Hacer
Hacer
Hacer
Hacer
Plan de implantación
De acuerdo con la complejidad del sistema se deberá generar un plan de implementación
del mismo que deberá incluir calendarización de actividades, ejecución de pruebas en
paralelo, pruebas de tensión y traslado al ambiente de producción.
2.8.4.1.
Estrategia de implantación
Definición del método de implementación más adecuado para el proyecto donde se
considera si se realiza un paralelo o no, método de carga de datos a utilizar y cualquier
otra decisión estratégica para la finalización exitosa del proyecto. Esta estrategia debe
ser acordada con el Patrocinador del proyecto, Líder del proyecto contraparte, Líder
Técnico y Jefatura de la USTI.
2.8.4.2.
Calendarización de actividades
Se refiere a un cronograma específico para esta etapa. Se deben revisar las
actividades, recursos y tiempos programados en la planificación inicial del proyecto
42
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
para hacer las modificaciones que se requieran. Estas modificaciones deberán ser del
conocimiento del Patrocinador del proyecto, de la Jefatura de la USTI, de usuarios y de
analistas.
2.8.5.
Instalación del sistema
Las actividades a realizar son las siguientes:
-
Preparar los aspectos restantes del ambiente físico y computacional para dar
inicio con la operación del sistema
Para lo anterior y de acuerdo a las características del sistema, se recomienda
lo siguiente:




-
2.8.6.
Iniciar las estructuras de seguridad de acceso al sistema:
identificación de usuarios, palabras de paso y atributos de usuario
(roles), con la finalidad de garantizar que el ingreso al sistema en
operación se realizará de forma segura.
Verificar que los requerimientos de “hardware”, “software” y
comunicaciones se encuentran disponibles.
Verificar que en los sitios de instalación del sistema, se encuentre
disponible el mobiliario, la instalación eléctrica (toma corrientes,
conexión a tierra, protectores de picos) y el espacio físico
acondicionado.
Verificar que los materiales que use el sistema se encuentren
disponibles. Por ejemplo formularios especiales, papelería, cintas
para impresora, disquetes, CDs, cajas de seguridad para
disquetes, cobertores para el equipo, así como todos los otros
materiales requeridos.
Realizar la instalación del sistema en el ambiente de producción en
coordinación con el DBA.
Conversión y carga inicial automatizada de datos
En caso de requerirse una migración de datos sea de una aplicación anterior o bien un
ingreso masivo de información, el Líder de Proyecto deberá considerar este traspaso como
un subproyecto, donde incluirá los requerimientos de recurso humano y tecnológico para
su ejecución 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 de los datos al sistema, se encuentre disponible, según
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 construidas para la conversión y carga inicial de los
datos al sistema.
-
Es recomendable realizar una depuración de los datos por convertir, para
asegurar que no se incluyan datos erróneos al sistema.
43
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
-
Verificar que los datos introducidos se encuentren correctos y completos,
considerando los resultados obtenidos
-
Comprobación por parte del Líder del Proyecto y del analista responsable, que
la conversión y carga de datos se realizó en una forma satisfactoria.
2.8.7.
Ejecución del paralelo
Las actividades a realizar son las siguientes:
-
Determinar la necesidad de ejecución de un procesamiento en paralelo,
realizando una justificación.
Esta decisión la tomará el Líder Técnico en conjunto con el usuario
responsable, considerando las características del sistema en cuanto a la
necesidad de un paralelo.
2.8.8.
-
Determinar la duración y forma del paralelo, de acuerdo con la naturaleza y
complejidad del sistema.
-
Determinar las funciones y responsabilidades del personal técnico y del
usuario que participa en el paralelo.
-
Establecer los criterios de aceptación esperados, para evaluar los resultados
que se tengan al final de la ejecución 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 ejecución del paralelo, considerando los
criterios de evaluación establecidos. Indicar el criterio de aceptación
considerado y el nombre de la persona que aprueba.
-
Dar un visto bueno, por parte del Líder del Proyecto y del analista responsable,
haciendo constar que el paralelo se concluyó en forma satisfactoria.
Aprobación formal del sistema para el inicio de su operación.
Esta aprobación la hace el Patrocinador, mediante un acta de aceptación y puesta en
operación del sistema.
Aquí se confirma que el sistema terminado cumple con los requisitos acordados al final de
la Etapa de Construcción.
2.8.9.
Hacer la entrega del sistema al usuario.
El Patrocinador y el Jefe de la USTI notificarán, formalmente, a los usuarios, a la
Administración y la Administración Superior, si es del caso, acerca de la puesta en
operación del sistema desarrollado
44
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
2.9.
Evaluación post-implementación
Es necesario que, realizada la implantación del sistema, se dé el tiempo necesario (de una
semana a 3 meses según el tamaño del sistema), para que se realice una evaluación de
éste y se hagan los ajustes necesarios, de manera que los usuarios finales satisfagan los
requerimientos previamente establecidos a implementarse en esta versión.
Esta etapa supone la realización de una sesión con el equipo de proyecto para discutir las
lecciones aprendidas en el proceso de desarrollo e implantación, de donde incluso pueden
derivarse mejoras a ser incorporadas a esta Guía Metodológica de acuerdo al proceso
establecido para su actualización. Adicionalmente se generará una rendición de cuentas
final y la relación costo/beneficio efectiva del proyecto.
45
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
3. Mantenimiento de sistemas
Para el mantenimiento del sistema se tiene que elaborar la solicitud de modificación por
escrito por parte del Patrocinador del Proyecto.
Una vez aprobado el ajuste,
correspondiente.
3.1.
se conforma el equipo de trabajo para el desarrollo
Planificación de la fase de mantenimiento
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 Líder de Proyecto y el Líder
Técnico sobre cómo se realizará, y cuál será el alcance que tendrá.
Es necesario que se asignen los recursos necesarios (humanos, técnicos, y materiales),
así como establecer un calendario de seguimiento: fechas de reunión con el Comité de
Usuarios y fechas de validación con el Usuario Patrocinador.
3.2.
Especificación de los nuevos requerimientos
En la misma forma en que fueron especificados en la fase de análisis de requerimientos,
deben ser especificadas las nuevas necesidades. Podría 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 sesión de trabajo, en la cual el Líder Técnico 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 Líder de proyecto.
3.3.
Ajustes en programación y pruebas
Realizar los ajustes correspondientes a la programación y la base de datos, si esto fuera
necesario, para dar cumplimiento a lo solicitado. Además, se debe valorar el tipo de
pruebas a realizar (pruebas funcionales y pruebas de integración) según 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 aplicación.
3.4.
Actualización de la documentación y los programas fuente
Realizar los ajustes que correspondan en la documentación del sistema, tanto a nivel de
manual de usuario, manual de operación y manual técnico, con la finalidad de que dichos
documentos se mantengan vigentes en todo momento. Los cambios realizados en la
programación y la base de datos deben manejarse como versiones de acuerdo con lo
establecido en el estándar respectivo.
46
Guía Metodológica para el Desarrollo de Sistemas de Información
Versión 1.1
3.5.
Capacitación
Dependiendo del tipo de ajuste realizado, se verá la conveniencia de comunicarlos por
medio de un correo o una pequeña charla. De lo contrario se deberá efectuar una
capacitación de acuerdo a lo estipulado en la presente metodología referente a este tema.
3.6.
Implementación de los cambios
Con todos los ajustes aprobados y efectuada la capacitación, se realizarán los ajustes en el
equipo de producción (tanto en equipo principal como en equipo periférico, según
corresponda), implementando el sistema actualizado.
3.7.
Evaluación post-implantación
Dependiendo del tipo de ajuste realizado, se deberá realizar una etapa de postimplantación.
47