metodologÍa para la implementaciÓn de … · auxiliares de investigación: adriana lucia...

METODOLOGÍA PARA LA IMPLEMENTACIÓN DEPROYECTOS SE SISTEMAS DE INFORMACIÓN

MÉTRICA

Autores:

SANDRA LILIANA BARRIOS PRIETODANIEL ALEJANDRO MELO ESTRADA

Director Unidad Informática: Henry Martínez Sarmiento

Tutor Investigación: Carlos José Acuña Daza

Coordinadores: Maria Alejandra EnríquezLeydi Diana Rincón

Coordinador Servicios Web: Daniel Alejandro Ardila

Analista de Infraestructuray Comunicaciones: Adelaida Amaya

Analista de Sistemas deInformación: Álvaro Enrique Palacios Villamil

Líder de Gestión deRecurso Humano: Islena del Pilar Gonzalez

UNIVERSIDAD NACIONAL COLOMBIAFACULTAD DE CIENCIAS ECONÓMICAS

UNIDAD DE INFORMÁTICA Y COMUNICACIONESBOGOTÁ D.C.

DICIEMBRE 2005

METODOLOGÍA PARA LA IMPLEMENTACIÓN DEPROYECTOS SE SISTEMAS DE INFORMACIÓN

MÉTRICA

Director Unidad Informática: Henry Martínez Sarmiento

Tutor Investigación: Carlos José Acuña Daza

Auxiliares de Investigación:Adriana Lucia CastelblancoAlexis de Jesús MorosAndrés Ricardo RomeroBrayan Ricardo RojasCarlos Hernán PorrasCatherin Cruz PinzónCristian Gerardo GilDaniel Alejandro MeloDiana Patricia GarcíaDiego Fernando RubioEdwin MontañoGerman David RiverosGuillermo Alberto ArizaHéctor Javier CortésJuan Felipe RincónLeidy Viviana Avilés

Leydy Johana PovedaLiliana Paola RincónLuis Alfonso NietoLuz Karina RamosMaria Teresa MayorgaMartha Rubiela GuevaraMiller Giovanny FrancoNubia Yolima CucarianRafael Leonardo SaavedraSandra Liliana BarriosSandra Milena CardenasSandra Monica BautistaSonia Janeth RamírezYaneth Adriana Cañón

Este trabajo es resultado del esfuerzo de todo elequipo perteneciente a la Unidad de Informática.

Se prohíbe la reproducción parcial o total de estedocumento, por cualquier tipo de método fotomecánicoy/o electrónico, sin previa autorización de laUniversidad Nacional de Colombia.


UNIDAD DE INFORMÁTICA Y COMUNICACIONESBOGOTÁ D.C.

DICIEMBRE 2005

Implementación Métrica


UNIDAD DE INFORMÁTICA Y COMUNICACIONES3

TABLA DE CONTENIDO1. RESUMEN ................................................................................................................. 9

2. ABSTRACT................................................................................................................ 9

3. INTRODUCCIÓN...................................................................................................10

4. MANUAL ................................................................................................................11

4.1. PLANEACIÓN DE SISTEMAS DE INFORMACIÓN (PSI) ................................11

4.1.1. Descripción general de la PSI ..................................................................11

4.1.2. Definición y Organización de la PSI........................................................11

4.1.3. Estudio de la información relevante.......................................................12

4.1.4. Identificación de Requisitos......................................................................12

4.1.5. Estudio de los Sistemas de Información actuales................................12

4.1.6. Diseño del Modelo de Sistemas de Información .................................12

4.1.7. Definición de la Arquitectura Tecnológica...........................................13

4.1.8. Definición del Plan de Acción .................................................................13

4.1.9. Revisión y Aprobación ...............................................................................13

4.2. ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)................................................13

4.2.1. Establecimiento de alcances del sistema.............................................14

4.2.2. Estudio de la Situación Actual .................................................................14

4.2.3. Definición de Requisitos del Sistema ......................................................15

4.2.4. Estudio de alternativas de solución ........................................................15

4.2.5. Valoración de las Alternativas .................................................................15

4.2.6. Selección de la solución ...........................................................................16

4.3. ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI).........................................16

4.3.1. Definición del Sistema................................................................................16

4.3.2. Establecimiento de requisitos...................................................................16




4.3.3. Identificación de subsistemas de análisis ..............................................17

4.3.4. Análisis de los casos de uso (solamente para desarrollo orientado aobjetos).........................................................................................................................17

4.3.5. Análisis de clases (solamente para desarrollo orientado a objetos). 18

4.3.6. Elaboración del modelo de datos (solamente para desarrolloestructurado)...............................................................................................................18

4.3.7. Elaboración del modelo de procesos (solamente para desarrolloestructurado)...............................................................................................................18

4.3.8. Definición de interfaces de usuario........................................................19

4.3.9. Análisis de consistencia y especificación de requisitos .....................20

4.3.10. Especificación del plan de pruebas.......................................................20

4.3.11. Presentación y aprobación del Análisis del Sistema de Información 21

4.4. DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI)...........................................21

4.4.1. Definición de la arquitectura del sistema .............................................21

4.4.2. Diseño de la arquitectura de soporte....................................................22

4.4.3. Diseño de casos de uso reales.................................................................22

4.4.4. Diseño de clases..........................................................................................23

4.4.5. Diseño de la arquitectura de módulos del sistema ............................24

4.4.6. Diseño físico de datos ................................................................................24

4.4.7. Verificación y aceptación de la arquitectura del sistema ...............25

4.4.8. Generación de especificaciones de construcción............................25

4.4.9. Diseño de la migración y carga inicial de datos (Plan de migracióny carga inicial) ............................................................................................................26

4.4.10. Especificación técnica del plan de pruebas .......................................26

4.4.11. Establecimiento de requisitos de implantación...................................27

4.4.12. Aprobación del diseño del sistema de información ..........................27




4.5. CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI) .........................27

4.5.1. Preparación del entrono de generación y construcción .................27

4.5.2. Generación del código de los componentes y procedimientos....28

4.5.3. Ejecución de las pruebas unitarias .........................................................28

4.5.4. Ejecución de las pruebas de integración .............................................28

4.5.5. Ejecución de las pruebas del sistema....................................................28

4.5.6. Evaluación de los manuales de usuario ................................................29

4.5.7. Definición de la formación de usuarios finales ....................................29

4.5.8. Construcción de los componentes y procedimientos de migracióny carga inicial de datos............................................................................................29

4.5.9. Aprobación del sistema de información...............................................29

4.6. IMPLANTACION Y ACEPTACION DEL SISTEMA...........................................29

4.6.1. Establecimiento del plan de implantación...........................................30

4.6.2. Formación necesaria para la implantación.........................................30

4.6.3. Incorporación del sistema al entorno de operación .........................30

4.6.4. Carga de datos al entorno de operación............................................31

4.6.5. Pruebas de implantación del sistema....................................................31

4.6.6. Pruebas de aceptación del sistema ......................................................31

4.6.7. Preparación del mantenimiento del sistema .......................................31

4.6.8. Establecimiento del acuerdo de nivel de servicio..............................32

4.6.9. Presentación y aprobación del sistema................................................32

4.6.10. Paso a producción .....................................................................................32

4.7. MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN ...................................33

4.7.1. Registro de la petición...............................................................................33

4.7.2. Análisis de la petición.................................................................................33

4.7.3. Preparación de la implementación de la modificación...................34




4.7.4. Seguimiento y evaluación de los cambios hasta la aceptación....34

5. APLICACIÓN DEL MANUAL A UN PROYECTO DE LA UIFCE ........................35

5.1. PLANEACIÓN DE SISTEMAS DE INFORMACIÓN .........................................35

5.1.1. Descripción General de la PSI..................................................................35

5.1.2. Definición y descripción de la PSI ...........................................................35

5.1.3. Estudio de la información relevante.......................................................36

5.1.4. Identificación de requisitos.......................................................................36

5.1.5. Estudio de los Sistemas de Información Actuales................................37

5.1.6. Diseño del Modelo de Sistemas de Información .................................37

5.1.7. Definición de la Arquitectura Tecnológica...........................................38

5.1.8. Definición del plan de acción .................................................................38

5.2. ESTUDIO DE VIABILIDAD DEL SISTEMA ..........................................................38

5.2.1. Establecimiento de alcances del sistema.............................................38

5.2.2. Estudio de la situación actual ..................................................................39

5.2.3. Definición de Requisitos del Sistema ......................................................41

5.2.4. Estudio de alternativas de solución ........................................................42

5.2.5. Valoración de las alternativas .................................................................42

5.2.6. Selección de la solución ...........................................................................42

5.3. ANÁLISIS DEL SISTEMA DE INFORMACIÓN ..................................................42

5.3.1. Definición del sistema ................................................................................42

5.3.2. Casos de uso................................................................................................42

5.3.3. Identificación de subsistemas de análisis ..............................................43

5.3.4. Diagrama de interacción de los casos de uso....................................43

5.3.5. Diagrama de clases ...................................................................................44

5.3.6. Modelo de Datos ........................................................................................45

5.3.7. Definición de interfases de usuario.........................................................45




5.3.8. Análisis de consistencia y especificación de requisitos .....................45

5.3.9. Especificación del plan de pruebas.......................................................46

5.4. DISEÑO DEL SISTEMA DE INFORMACIÓN ....................................................46

5.4.1. Definición de la arquitectura del sistema .............................................46

5.4.2. Diseño de la arquitectura de soporte....................................................47

5.4.3. Diseño de casos de uso reales.................................................................47

CU01 Administración de salones.................................................................47

CU02 Registro de solicitud de programación ..........................................48

CU03 Registro de actividades......................................................................49

CU04 Programación de salones..................................................................50

CU05 Aprobación de solicitudes.................................................................50

CU06 Control de salones...............................................................................51

5.4.4. Diseño de clases..........................................................................................52

5.4.5. Diseño de la arquitectura de módulos del sistema ............................53

5.4.6. Diseño físico de datos. ...............................................................................53

5.4.7. Generación de especificaciones de construcción............................60

5.4.8. Diseño de la migración y carga inicial de datos.................................60

5.4.9. Especificación técnica del plan de pruebas .......................................60

5.4.10. Establecimiento de requisitos de implantación...................................60

5.5. CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN ...................................60

5.5.1. Preparación del entorno de generación y construcción. ................60

5.5.2. Generación del código de los componentes y procedimientos....60

5.5.3. Ejecución de las pruebas unitarias .........................................................65

5.5.4. Ejecución de las pruebas del sistema....................................................65

5.5.5. Evaluación de manuales de usuario. .....................................................65

5.5.6. Definición de la formación de los usuarios finales. .............................66




5.5.7. Construcción de los componentes y procedimientos de migracióny carga inicial de datos............................................................................................66

5.6. IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA...........................................66

5.6.1. Establecimiento del plan de implantación...........................................66

5.6.2. Formación necesaria para la implantación.........................................66

5.6.3. Incorporación del sistema al entorno. ...................................................67

5.6.4. Carga de datos al entorno de operación............................................67

5.6.5. Establecimiento del acuerdo de nivel de servicio..............................67

6. CONCLUSIONES...................................................................................................68

7. BIBLIOGRAFIA .......................................................................................................69




1. RESUMEN

Métrica es una metodología que ayuda a mantener y planificar los sistemas deinformación de una empresa, y de esta manera, ayudar a una organización aconseguir sus objetivos que se plantean, además dota a la organización desoftware que colabore en las necesidades de las personas.

Estas razones son por las cuales se decido analizar métrica y plasmarla en unproyecto de la Unidad de Informática de la Facultad de ciencias Económicas(UIFCE), ya que este será un ejemplo para el análisis y desarrollo de futurosproyectos que se realizaran para el aumento de la calidad de servicio que sepresta a los usuarios.

2. ABSTRACT

Metrica is a methodology that helps to maintain and to plan the informationsystems of a company, and in this way, to help an organization to obtain itsobjectives that are presented, besides endows software to the organization thatcollaborate in the needs of the people.

These reasons are for which has been analyze metrica and express it in a projectof the Computing Unit of the Economics Sciences Faculty (UIFCE), since this willbe an example for the analysis and development of future projects that werecarried out for the increase of the quality of service that lent to the users.




3. INTRODUCCIÓN

La tecnología de información busca obtener los métodos y herramientasnecesarias para recoger y administrar la información con el uso de nuevastecnologías asociadas con las computadoras, estas nuevas tecnologías hacenque las empresas y organizaciones puedan recibir toda la información en elmomento en que se produce y realizar el respectivo ajuste para la administraciónde esta.

Al utilizar de una manera eficiente los recursos que le proporciona las nuevastecnologías de información, la empresa puede incrementar su productividad, y deesta manera generaría un aumento en sus ventajas competitivas. Pero obteniendoesta enorme ganancia deben generar las herramientas adecuadas paramantenerla y seguir buscando nuevas tecnologías en otros procesos para hacerlosóptimos.

Para la Unidad de Informática y Comunicaciones de la Facultad de CienciasEconómicas UIFCE, que es una organización dedicada al servicio y atención ausuarios en el área de informática, es necesario que se esté actualizandopermanentemente para ofrecer los mejores productos en temas de tecnología dela información que se aplique a las ciencias económicas. Por consiguiente, sedeben desarrollar continuamente proyectos enfocados hacia el mejoramiento delos sistemas de información existentes, de tal forma que la mantengan actualizaday preparada a todas las demandas nuevas que surjan.

En el presente trabajo se pretende llevar a cabo una aplicación a la UIFCE de lametodología Métrica versión 3 desarrollada por el Ministerio de AdministracionesPúblicas de España, con el fin de generar un manual que sirva a la generación deSistemas de Información propios. Además, se llevará a cabo un pequeño ejemploque refleje las ventajas y características de dicho manual, basado en una nuevaaplicación del Sistema de Información ya existente (WEBSIUI), y de esta maneramejorar la calidad y servicio a sus usuarios, ganando por ende un aumento en sucompetitividad.




4. MANUAL

4.1. PLANEACIÓN DE SISTEMAS DE INFORMACIÓN (PSI)

Al iniciar cualquier proyecto en necesario tener un marco de referencia que indiquelo que se quiere lograr y cada uno de los pasos a seguir en la elaboración,desarrollo y control del mismo, con el fin de obtener los resultados esperadosacordes a los objetivos trazados inicialmente, así como la congruencia con los dela organización.Por lo tanto, la planeación es la labor que mayor tiempo, esfuerzo y dedicacióndeberá recibir por parte de la dirección y de quienes realizan el proyecto, ya quede su especificidad y aplicabilidad real dependerá el buen desarrollo del mismo.

Para esto, es necesario que el gestor de un proyecto aplicable a la UIFCE, lleve acabo los siguientes pasos:

4.1.1. Descripción general de la PSI

a) Establecer el objetivo del proyecto.b) Definir la relación del objetivo del proyecto con el cumplimiento de los

objetivos estratégicos de la UIFCE.c) Especificar las esferas o departamentos de la UIFCE que el proyecto

afectará.d) Asignar los responsables y participantes necesarios para el desarrollo de

cada fase del proyecto.

4.1.2. Definición y Organización de la PSI

a) Describir los objetivos específicos de las fases del proyecto, teniendo encuenta la participación de cada dependencia involucrada y susresponsables.

b) Definir las funciones de cada participante1 de acuerdo a su perfilconsignándolos en un Catálogo de Usuarios.

c) Definir el lugar, recursos necesarios, periodicidad y estándares dedocumentos para presentar informes parciales del proyecto.

1 Entendido como participante aquélla persona involucrada en el desarrollo del proyecto.




d) Establecer el plan de trabajo: Identificar las tareas de cada uno de losparticipantes del proyecto y establecer fechas de inicio y de entrega dedichas tareas, considerando los factores críticos de éxito.

e) Comunicar el plan de trabajo a todas las personas implicadas en elproyecto.

4.1.3. Estudio de la información relevante

a) Buscar, seleccionar y analizar la información referente a investigaciones ydesarrollo de trabajos ejecutados anteriormente y que puedan servir comoun antecedente útil para el proyecto a realizar.

b) Hacer un catálogo de las conclusiones de la actividad anterior (4.1.3.a) conel fin de establecer referencias de normativas y procedimientos que puedanservir para el proyecto. Este catálogo tendrá el nombre de Catálogo deRequisitos.

4.1.4. Identificación de Requisitos

a) Identificar y estudiar cada uno de los procesos de la UIFCE que se venafectados por el proyecto, determinando las personas implicadas, quéfunciones desempeñan, y cuál información fluye dentro de dichos procesos.

b) Identificar las necesidades de información de la UIFCE, proponiendo unmodelo ideal de flujo de éste en el que se especifique las actividades yfunciones en cada proceso analizado anteriormente (4.1.4.a.)

c) En el mismo catálogo realizado en la actividad 4.1.3.b) y basados en lastareas 4.1.4.a) y 4.1.4.b), definir los requisitos que el Sistema deInformación deberá cubrir asignándoles prioridades a cada uno de ellos.Esto se hará teniendo en cuenta la opinión de los usuarios.

4.1.5. Estudio de los Sistemas de Información actuales

a) Determinar el alcance y los objetivos de los Sistemas de Informaciónexistentes que se vean afectados por el plan del nuevo proyecto.

b) Analizar dichos Sistemas de Información, describiendo sus característicasgenerales referidas a datos, software y procesos de la UIFCE a los quebrinda soporte. Asimismo, se debe recoger los puntos de vista de losusuarios que interactúan en los mismos (estudiantes, docentes, monitores,analistas, coordinadores, etc).

c) Evaluar la eficiencia de los Sistemas de Información basados en opinionesde las personas, riesgos y problemas que presente, con el fin de determinarsi se debe sustituir o sólo realizar mejoras en el Sistema.

4.1.6. Diseño del Modelo de Sistemas de Información

a) Determinar la cobertura de requisitos (obtenidos de la actividad número4.1.4) por parte de los Sistemas de Información actuales y aquellos que no




son encerrados por dichos sistemas, junto con las necesidades deinformación que éstos cobijan.

b) Realizar un modelo de los Sistemas de Información actuales que se van amantener con sus mejoras respectivas, y los nuevos Sistemas que entraríana funcionar para cubrir las necesidades emergentes. Asimismo, sedetermina las relaciones entre los diferentes sistemas y los requisitos quecubre.

4.1.7. Definición de la Arquitectura Tecnológica

a) Identificar las necesidades de infraestructura tecnológica acordes con elmodelo propuesto del Sistema y plantear posibles alternativas, pensandosiempre a futuro.

b) Seleccionar entre las alternativas, aquélla que brinde el mejor soporte alsistema y que se encuentre acorde con el contexto de la UIFCE,determinando las posibilidades, recursos y tiempo necesarios para instalarla arquitectura tecnológica elegida.

4.1.8. Definición del Plan de Acción

a) Elaborar el plan de subproyectos, donde se especifique las acciones arealizar (asignando prioridades de acuerdo a la relación con los objetivos),disponibilidad de recursos, tiempo, limitaciones, riesgos y beneficios para laUIFCE. De esta manera, se propone un cronograma estimando fechas deinicio y de fin de cada subproyecto, teniendo en cuenta la disposición de losusuarios.

b) Construir el plan de mantenimiento de la PSI, donde se determinará losresultados que se deberán obtener, con qué periodicidad y a quién sedeberá informar, con el fin de mantener el cronograma actualizado enfunción de los avances logrados.

4.1.9. Revisión y Aprobación

a) Elaborar un resumen que simplifique todos los resultados de esta etapa.b) Presentar dicho plan a la Coordinación de la UIFCE y recoger alternativas

de mejoras, analizando su posible incorporación al plan.c) Presentar la propuesta final y esperar aprobación. Luego, se informa los

resultados a todas los equipos de trabajo de la UIFCE que se veanafectados por el proyecto (plan de comunicación).

4.2. ESTUDIO DE VIABILIDAD DEL SISTEMA (EVS)El objetivo del Estudio de Viabilidad del Sistema es el análisis de un conjuntoconcreto de necesidades para proponer una solución a corto plazo, que tenga encuenta restricciones económicas, técnicas, legales y operativas. La soluciónobtenida como resultado del estudio puede ser la definición de uno o varios




proyectos que afecten a uno o varios sistemas de información ya existentes onuevos.2

Por lo tanto, es importante que realice los siguientes pasos:

4.2.1. Establecimiento de alcances del sistema

a) Describir las necesidades que el Sistema planea satisfacer y lasrestricciones que tiene utilizando el Catálogo de Requisitos de la PSI, paralo cual se realizan los siguientes catálogos:Ø Catálogo de requisitos actualizado, en el que se especifique la relación

con otros proyectos que se estén realizando paralelamente, para lograruna sincronización y establecer posibles dependencias entre proyectos.

Ø Catálogo de objetivos que se planean alcanzar con el estudio deviabilidad del sistema.

b) Identificar las dependencias de la UIFCE que se encuentren afectados porel proyecto, sus responsables y estructura. Con esta información, realizarun catálogo de usuarios (internos y externos).

c) Establecer un plan de trabajo con objetivos, en el que se encuentren lasdependencias, usuarios involucrados y responsables para realizar el estudiode la situación actual de la UIFCE.

4.2.2. Estudio de la Situación Actual

a) Basado en la arquitectura de información propuesta en la actividad 4.1.7 dela PSI, identificar aquellos sistemas de información actuales que puedanafectar o ser afectados por el sistema objeto de estudio y el contexto quelos rodea.

b) En base al catálogo de usuarios, definir quiénes participaran en el estudiode viabilidad, se les informa y se espera aprobación.

c) Con los usuarios designados y la identificación de los sistemas deinformación actuales, elaborar la descripción de cada uno de ellos así:Ø Descripción del sistema a nivel lógico.Ø Descripción del modelo físico.Ø Determinar localización geográfica-física de módulos y datos del

sistema.Ø Establecer las dependencias organizacionales de la UIFCE que se

sirven de dicho sistema actual.d) Realizar un diagnóstico actual analizando la información anterior con el fin

de identificar problemas, deficiencias y mejoras para dichos sistemas.

2 http://www.csi.map.es/csi/metrica3/evs.pdf Pág.1“Ministerio de administracionesPublicas – España”

http://www.csi.map.es/csi/metrica3/evs.pdf




4.2.3. Definición de Requisitos del Sistema

a) Realizar de un catálogo de normas donde se encuentre las directrices queseguirá el software resultante del sistema de información a estudio. Endicho catálogo se debe encontrar:Ø Políticas de seguimiento, revisión, normativas, técnicas de

programación, metodologías.Ø Políticas de seguridad.Ø Directrices de planificación, gestión de cambios y gestión de calidad.

b) Definir las sesiones de trabajo y su frecuencia a razón del tiempo disponiblede los usuarios que van a participar.

Utilizando el catálogo de requisitos, definir y clasificar dichos requisitos queel sistema debe satisfacer en funcionales y no funcionales con susrespectivas prioridades.

4.2.4. Estudio de alternativas de solución

a) Proponer opciones que puedan ser soluciones para los requisitosplanteados anteriormente, además de determinar si será necesario adquirirnuevo software estándar, a la medida o mixto3.

b) Identificar para cada alternativa de solución los subsistemas, si los hay, ylos requisitos que cubre.

c) Definir cada alternativa y su estrategia de implantación en función de lacobertura global del sistema y geográfica que tenga. Si la alternativa desolución incluye:Ø Desarrollo, entonces se debe especificar el modelo abstracto de datos y

el modelo de procesos.Ø Orientación a Objetos, entonces se debe describir el modelo de

negocios y el de dominio (opcional).Ø Producto software, entonces se debe analizar su evolución,

adaptabilidad y costos adicionales por concepto de licencias.

4.2.5. Valoración de las Alternativas

a) Valorar el impacto de cada alternativa en la UIFCE y establecer suviabilidad económica por medio de un análisis coste/beneficio.

b) Identificar y analizar los riesgos y la complejidad de cada alternativa,proponiendo medidas para minimizar dichos factores de riesgo.

c) Plantear un plan de trabajo para cada alternativa, de tal forma quesincronice con los demás proyectos que se están realizando o que seejecutarán a futuro.

3 Para el estudio de las alternativas se podrá desagregar el sistema en subsistemas, con el fin deevaluar varias opciones y aplicar las más adecuadas. Esto puede ser opcional de acuerdo a lacomplejidad de dicho sistema.




4.2.6. Selección de la solución

a) Convocar a la Coordinación de la UIFCE para hacer una presentación detodas las alternativas de solución trabajadas anteriormente.

b) Evaluar, junto con la Coordinación, las ventajas e inconvenientes de cadauna de las alternativas y, así, elegir la solución final.

c) La Coordinación de la UIFCE aprueba formalmente la solución o determinasu no viabilidad.

4.3. ANÁLISIS DEL SISTEMA DE INFORMACIÓN (ASI)

Para el diseño del sistema de información, es necesario delimitarlo de tal formaque, efectivamente, satisfaga las necesidades de todos los usuarios. Así, esteanálisis buscará describir detalladamente dicho sistema, a través de los siguientespasos:

4.3.1. Definición del Sistema

a) Delimitar el sistema de información, describiendo los procesos que encierray el modelo abstracto de datos a partir de la solución encontrada en el EVS,además, identificar aquellos agentes externos involucrados que importan yexportan información al sistema. Si la solución es orientada a objetos esimportante determinar el contexto del sistema a través del modelo denegocios4 y de dominio.

b) Ampliar el catálogo de requisitos en el campo del ambiente tecnológiconecesario para desarrollar el sistema de información acorde con lasnecesidades de los usuarios y la solución planteada en el EVS.

c) Actualizar el catálogo de normas necesarias para la puesta en marcha y eldesarrollo del sistema en todos sus ciclos de vida.

d) Actualización del catálogo de usuarios, identificando los participantes deesta etapa y quienes darán la aceptación final del sistema, especificandosus funciones (plan de trabajo para el análisis). Se comunica dichasfunciones a los usuarios involucrados.

4.3.2. Establecimiento de requisitos

a) Obtener información detallada de los usuarios del ASI (4.3.1.d) acerca delos requisitos que el sistema o software debe cumplir referentes afuncionalidad, rendimiento, seguridad, implantación y disponibilidad del

4 El modelo de negocio especifica los procesos a los que se quiere dar respuesta en el sistema deinformación, en forma de casos de uso de alto nivel y el subconjunto de objetos del dominio que serequieren para ello.




sistema. Además, se debe especificar los requisitos no funcionales, talescomo las restricciones del entorno en hardware y software.

b) Si el proyecto es orientado a objetos se deben especificar los casos de usoasociados a los requisitos funcionales, es decir, identificar actores, casos deuso describiéndolos brevemente de acuerdo a las normas y estándares dela UIFCE.

c) Especificar, con la ayuda de los usuarios, los casos de uso identificadosanteriormente, recopilando información por medio de la descripción delescenario, precondiciones y poscondiciones, identificación de las interfacesdel usuario, condiciones de fallos y escenarios secundarios. Esta actividades obligatoria para el desarrollo orientado a objetos y opcional para el casode estructura.

d) Analizar la información recopilada detectando ambigüedades,inconsistencias, duplicidad o escasez de información, estableciendoprioridades que los usuarios colocan a los requisitos y comportamientoscomunes que permitan relacionar los requisitos con los casos de uso.

e) Confirmar con los usuarios la consistencia, validación y completitud de losrequisitos del Catálogo y los casos de uso.

4.3.3. Identificación de subsistemas de análisis

a) La descomposición en subsistemas debe estar enfocada hacia el desarrolloorientado a objetos y de acuerdo al modelo de negocios se determinan ydescriben la dependencia e interfaces entre los subsistemas. Para eldesarrollo estructurado los subsistemas tienden a coincidir con ladescomposición del diagrama de flujo.

b) Elaborar modelo de análisis de cada uno de los subsistemas de tal formaque se logre una coordinación y ausencia de duplicidad. Así, se permitealcanzar a tener una visión global y unificada de todos los modelos.

4.3.4. Análisis de los casos de uso (solamente para desarrollo orientado aobjetos).

a) Para cada caso de uso identificar los objetos necesarios que mejorrepresenten la información del sistema, determinando cuáles podrían serclases (entidad, interfaz del usuario y control) y generar un modelo de losmismos, así:Ø Que la clase identidad represente la información manipulada en el caso

de uso.Ø Que la clase de interfaz del usuario describa la interacción entre el

sistema y sus actores.Ø Que la clase de control represente la coordinación, secuencia de

transacciones y control de los objetos relacionados con caso de uso.b) Realizar un diagrama de interacción donde se encuentre los usuarios, los

objetos y las secuencias de mensajes intercambiados, además de incluir eltipo de objetos y de información que se intercambia.




4.3.5. Análisis de clases (solamente para desarrollo orientado a objetos).

a) Determinar las funciones de cada clase de acuerdo a los papeles que van adesempeñar los objetos dentro de los casos de uso. Igualmente,especificar los atributos de cada clase (propiedades implicadas en eldesarrollo de las funciones).

b) Analizar los mensajes entre los objetos establecidos en el diagrama deinteracción con el fin de encontrar asociaciones entre clases y, de estamanera, definir agregaciones o herencias entre objetos.

c) Organizar las clases de tal forma que se implemente de manera sencilla lasagregaciones y herencias entre dichas clases de acuerdo a la definición delsistema (ASI 4.3.1).

4.3.6. Elaboración del modelo de datos (solamente para desarrollo estructurado).

a) Elaborar el modelo conceptual de datos: Identificar y definir las entidades dedatos con sus respectivos atributos y relaciones entre sí (múltiples,recursivas, de explosión, de implosión, generalizaciones y agregaciones).

b) Elaborar el modelo lógico de datos a partir del modelo conceptual, es decir,resolver, eliminar y determinar dependencias entre las relaciones de lasentidades, así como prescindir de redundancias y ambigüedades. De igualforma, se debe determinar cuestiones, tales como:Ø Número máximo de ocurrencias.Ø Estimaciones de crecimiento por periodo.Ø Tipo y frecuencia de acceso.Ø Características de seguridad, confidencialidad, disponibilidad y demás

que sean consideradas como relevantesc) Normalizar el modelo lógico de datos, por medio de la prohibición de

redundancias, inconsistencias y grupos repetidos y, luego, el conocimientode los datos y sus relaciones.

d) Se realiza un plan de migración de datos desde otros sistemas si esnecesaria para la carga inicial de información. Para tal fin se debe tener encuenta prioridades, requisitos, necesidades de software y hardware,modificaciones, etc.

4.3.7. Elaboración del modelo de procesos (solamente para desarrolloestructurado).

a) Elaborar un modelo de los procesos de los subsistemas, a través de undiagrama de flujo de datos especificando todas sus características ydeterminando frecuencias de ejecución, restricciones para la ejecución ytiempos máximos de respuesta, franja horaria crítica, número máximo deusuarios. Además, para cada proceso se debe especificar aquéllos queestén bajo el control de los usuarios y cuáles bajo el control de sistema,junto con su ubicación geográfica y disponibilidad.

b) Identificar y describir las interfaces con otros sistemas, especificando decada uno:




Ø Procesos asociadosØ Especificaciones funcionalesØ Formato de datos intercambiadosØ Aspectos operativosØ Frecuencia o periodicidad del intercambioØ ValidacionesØ Requisitos de seguridadØ Evento que desencadena la interfazØ Modificaciones o adaptaciones

4.3.8. Definición de interfaces de usuario

a) Determinar los principios de las interfaces, donde se encuentren losestándares de su entorno (gráfico, carácter, etc), composición de laspantallas y la ubicación de las formas dentro de ellas, normas para lapresentación de avisos en general (error, ayuda y demás). Asimismo, sedeben especificar las directrices por las cuales se presentarán informes yformularios impresos.

b) Realizar un catálogo de perfiles de usuario de acuerdo al nivel deresponsabilidad y funciones a desempeñar, asignando a cada uno losrespectivos procesos de comunicación interactivos, los cuales debenincluirse al Modelo de Procesos con el fin de implementarlo en la interfaz.Dichos procesos interactivos deben ser presentados en forma de diálogosde acuerdo a las necesidades de cada usuario (esta actividad no se realizapara el desarrollo orientado por objetos).

c) Definir los formatos individuales de cada interfaz de pantalla teniendo encuenta tamaños, ubicación, modalidades, dispositivos de entrada, datos quese usan y que se generan por su ejecución y los controles y elementosactivos e inactivos de la interfaz. Además, es importante tener en cuenta:Ø Si el análisis es orientado a objetos, entonces los formatos individuales

de las interfaces completarán las especificaciones de los casos de uso.Ø Si el análisis es estructurado, entonces se debe tener en cuenta el

modelo de datos y el modelo de procesos.d) Elaborar un modelo de navegación de interfaz de pantalla, donde estén

establecidos lógicamente la entrada de datos y reglas de validación paracada formato, las secuencias de acciones para completar cada diálogo, eidentificar formatos o diálogos críticos para el buen funcionamiento delsistema, teniendo como base factores como número de usuarios, frecuenciade uso, seguridad, etc.

e) Determinar un prototipo de interfaz de impresión y los formatos individualesde informes y formularios (formatos de impresión), definiendocaracterísticas como la confidencialidad, periodicidad y procedimientos deentrega.




4.3.9. Análisis de consistencia y especificación de requisitos

a) Verificar la calidad formal de los modelos generados conforme a la técnicaseguida hasta este punto y al catálogo de normas actualizado en laactividad ASI 4.3.1.c)

b) Comprobar que existe coherencia entre los modelos y eliminarinconsistencias, ambigüedades y duplicación de información, elaborandolas siguientes matrices:Ø Para desarrollo estructurado:

P Matriz de modelo lógico de datos normalizados / Modelo deprocesos.

P Matriz de modelo lógico de datos normalizados / Interfaz deusuario.

P Modelo de procesos / Interfaz de usuario.Ø Para desarrollo orientado a objetos:

P Modelo de clases / Diagramas dinámicos5

P Modelo de clases / Interfaz de usuarioP Análisis de la realización de los casos de uso / Interfaz de

usuario.c) Evaluar los modelos de acuerdo al catálogo de requisitos del sistema de

información y a la validación directa del usuario, especialmente en lainterfaz de usuario.

d) Elaborar la Especificación de Requisitos de Software (ERS), el cual constade la información necesaria para la aprobación final de lo realizado en elASI. Por lo tanto, deberá estar guardar el siguiente orden:Ø IntroducciónØ Ámbito y alcanceØ ParticipantesØ Requisitos del sistema de informaciónØ Visión general del sistema de informaciónØ Referencia de los productos a entregarØ Plan de acción

4.3.10. Especificación del plan de pruebas

a) Para garantizar la calidad y satisfacción de necesidades del sistema deinformación hacia los usuarios, se debe especificar los niveles de prueba yplanificar su realización en cada nivel, de acuerdo al esquema: definir losperfiles implicados, hacer una planificación temporal, establecer criterios deverificación y aceptación, precisar las verificaciones, analizar los resultados,y determinar productos a entregar como consecuencia de la ejecución depruebas.

5 La interfaz de usuario incluirá diagramas dinámicos y hará parte del modelo de clases.




b) Recopilar requisitos referentes a hardware, software, configuración,herramientas, procedimientos para su realización y migración; todosrelativos al entorno de pruebas6.

c) Definir las pruebas de aceptación del Sistema por parte de los usuarios parasu posterior puesta en marcha con la seguridad de que satisface todos losrequisitos. Para tal fin se debe colocar especial atención a los criterios deaceptación, los cuales deben incluir, entre otros a juicio de losinvestigadores, los siguientes:Ø Procesos críticos del sistemaØ Rendimiento del sistemaØ SeguridadØ Disponibilidad

4.3.11. Presentación y aprobación del Análisis del Sistema de Información

a) Presentar todos los productos, resultados y conclusiones de esta fasecontenidos en la ERS y el plan de pruebas a la Coordinación de la UIFCEpara su aprobación final.

4.4. DISEÑO DEL SISTEMA DE INFORMACIÓN (DSI)

En esta etapa se trata de definir toda la arquitectura del sistema de información ysus componentes, con el fin de llegar a especificaciones que permitan visualizar suconstrucción.

Tanto el desarrollo estructurado, como el orientado a objetos se manejaran demanera integrada.

4.4.1. Definición de la arquitectura del sistema

a) Definir las particiones físicas del sistema, teniendo como criterios losusuarios, datos y procesos. Además, se debe especificar elementos talescomo gestores de datos, tipos de puesto cliente, tipo de dispositivos deimpresión, monitores de teleproceso, servidores y comunicaciones entre lasdiferentes particiones con sus respetivos protocolos (tipo de mensajes).

b) Actualizar el catálogo de requisitos con aquéllos que están relacionados oque condicionen el diseño y construcción del sistema. Estos requisitos sereferirán, de manera general, a los lenguajes, rendimientos, ubicación demódulos y datos de cada partición.

6 Es recomendable tener una independencia entre el entorno de pruebas y el de operación,asegurando la estabilidad de los datos y manteniendo un punto de comparación.




c) Definir comportamientos no habituales o anómalas en el sistema cuandosea ejecutado y consignarlos en un catálogo especificando, además,condiciones previas, elementos afectados (por ejemplo casos de uso) y larespuesta del sistema.

d) Concretar todos los estándares y normas relacionados con la infraestructuratecnológica y que condicionará el diseño y construcción del sistema, loscuales se deben recoger en el catálogo de normas para actualizarlo y servircomo punto de referencia para las siguientes actividades.

e) Determinar, de manera lógica, subsistemas que faciliten el mantenimiento ysencillez del sistema de información, clasificándolos en específicos(funciones propias del sistema) o de soporte (cobertura de servicioscomunes). Para ello, es posible tomar como referencia los subsistemasobtenidos del ASI o generar nuevos de acuerdo a la necesidad.

f) Precisar los elementos de la infraestructura técnica, tales como hardware,software y comunicaciones (topología de red y protocolos). Asimismo, sedebe realizar una estimación de la planificación de capacidades enaspectos referentes a almacenamiento (espacio en disco), procesamiento(tipos de procesadores y memoria) y comunicaciones (líneas y capacidad dered).

g) Definir requisitos de seguridad y control de acceso diseñandoprocedimientos para el acceso al sistema, mantenimiento y confidencialidadde datos, control y registro de accesos al sistema, copias de seguridad yrecuperación de datos. Igualmente, diseñar procedimientos de operación yadministración donde se relacione la franja horaria de mayor afluencia,número máximo de usuarios, periodicidad y secuencia de ejecución,distribución de información, control y seguimiento del correctofuncionamiento del backup y recuperación utilizados habitualmente.

4.4.2. Diseño de la arquitectura de soporte

a) Diseñar y especificar cada uno de los módulos/clases de los subsistemasde soporte del sistema contemplados en el paso 4.4.1.e), teniendo encuenta su descomposición en servicios, descripción de la interfaz ycomportamiento de cada servicio.

b) Realizar patrones o guías de diseño y construcción genéricos que sirva parala definición de la arquitectura del sistema y el diseño detallado desubsistemas específicos y de soporte.

4.4.3. Diseño de casos de uso reales7

a) Identificar las clases que intervienen en cada caso de uso a partir del paso4.4.1.a), si es necesario adicionar más clases de diseño, podrán serincorporadas al modelo.

7 Se realiza solo en el caso de desarrollo y diseño orientado a objetos




b) Establecer, desde el punto de vista técnico, cómo interactúa entre sí todoslos objetos para realizar un caso de uso del sistema, teniendo en cuenta losescenarios especificados en el ASI, detallando su entorno tecnológico ymecanismos genéricos de diseño. En el caso en el que existan elementoscomunes se podría crear un subsistema de soporte que ofrezca dichocomportamiento como un servicio.

c) Diseñar detalladamente (pantalla gráfica) el comportamiento de la interfazde usuario, revisando la navegación entre ventanas, elementos formadoresde cada interfaz, características, disposición y cómo se gestionan loseventos relacionados con lo objetos.

d) Describir cada caso de uso en términos de los subsistemas participantes,las interfaces requeridas y los mensajes que intercambian los objetos entresí.

4.4.4. Diseño de clases8

a) Plantear el diseño de clases identificando clases adicionales si esnecesario, y teniendo en cuenta que:Ø Clases de control se refieren a la coordinación y secuencia entre

objetos, distribución, rendimiento, transacción y serialización.Ø Diseño de clases de entidad depende del sistema de gestión de datos

utilizado.Ø Diseño de clases de interfaz de usuario depende de la tecnología

empleada.b) Definir asociaciones entre clases tomando como referencia la secuencia de

mensajes entre objetos definidos en el ASI (4.3.4.b), además, se debetener en cuenta las características de cada una, las relaciones (de tal formaque simplifiquen el sistema), la modelización de rutas de acceso óptimasentre asociaciones y contemplar la posibilidad de diseñar algunasasociaciones como clases.

c) Identificar atributos de cada una de las clases obtenidas en el proceso ASI(4.3.9.c), especificando su tipo, formatos y restricciones.

d) Determinar las operaciones que efectúa cada clase, especificando elnombre, parámetros y visibilidad (pública, privada, protegida), y teniendo encuenta el entorno de desarrollo utilizado. Si existen objetos en diferentesestados, entonces se realiza un diagrama de transición de estados paradescribir las operaciones.

e) Revisar jerarquía de las clases comprobando su viabilidad. Para esto, sedebe identificar clases abstractas (superclases) que agrupen atributos yoperaciones comunes y heredables.

f) Describir el método por el cual cada clase realiza sus operaciones. Puedeutilizarse algoritmos escritos en pseudocódigo o lenguaje natural.

8 Se realiza solo en el caso de desarrollo y diseño orientado a objetos




g) Realizar una pequeña aproximación a las necesidades de migración ocarga inicial de datos.

4.4.5. Diseño de la arquitectura de módulos del sistema9

a) Identificar los procesos que se van a implementar en cada subsistema,especificando el tipo de implementación (lotes o en línea) y el tipo deiniciación (bajo petición o por el sistema). Además, es necesario analizar elalcance y características propias de cada proceso y, con esto, diseñar laestructura en módulos de los procesos y detallar el prototipo de lenguajeutilizado (natural o pseudocódigo).

b) Describir las comunicaciones existentes entre los módulos, considerandolos requisitos del sistema. Realizar el diseño de las interfaces teniendo encuenta:Ø Datos involucrados y su formato en el intercambio.Ø Valores o rangos de datos intercambiados.Ø Origen y destino de los datos.Ø Información de control y valores posibles.

c) Diseñar la interfaz del usuario, revisando la descomposición funcional endiálogos de acuerdo a la arquitectura modular del sistema, la navegaciónentre ventanas y la información para la ejecución de cada diálogo,identificando dependencia entre datos. Además, examinar ventanasalternativas y sus elementos, comprobar que la información de cada interfaz(de pantalla y de impresión) sea tratada por el módulo correspondiente a laarquitectura del sistema, y realizar el diseño de mensajes de error, de avisoo advertencia y de ayuda.

4.4.6. Diseño físico de datos

a) Para obtener una mejor implementación del modelo lógico de datosnormalizado (diseño estructurado) o modelo de clases (diseño orientado aobjetos) y alcanzar una aproximación al espacio de almacenamiento, sedebe analizar las técnicas del gestor de bases de datos o sistemas deficheros a utilizar, estimando el uso y volumen de ocurrencias de cadaentidad/clase del modelo, además, definir elementos que se debenimplementar como bloqueo de datos, compresión, clústeres, punteros, etc.Asimismo, es importante tener en cuenta los volúmenes de estructuras dedatos implicados en caso de ser necesaria la migración inicial de datos.Con esto, determinar la forma de convertir las entidades/clases en tablas,identificando claves u otro medio de acceso.

b) A los principales módulos/clases que reúnan las características de ser detratamiento crítico, tengan concurrencia y accesos complejos a datos se lesdebe identificar tablas o ficheros para cada uno y el orden para la obtención

9 Se realiza solo en el caso de desarrollo y diseño estructurado.




de datos. Además, estimar el número de accesos, prioridad y frecuencia,con el fin de determinar diferentes caminos de acceso y, así, optimizar elrendimiento de los gestores de datos o sistemas de ficheros lo máseficientemente posible.

c) Optimizar el diseño físico de datos para mejorar el tiempo de respuesta enel acceso a datos, por medio de la detección de mejoras en el modelo físicode acuerdo a la secuencia de accesos de módulos/clases críticos (4.4.6.b),y teniendo en cuenta la estimación de volúmenes, frecuencias y tipos deacceso, crecimiento por periodo y requisitos de seguridad y disponibilidad.

d) Determinar el modelo de distribución de datos, estableciendo la ubicaciónde todos los elementos10 físicos por nodos de acuerdo a la partición físicadel sistema (4.4.1.)

4.4.7. Verificación y aceptación de la arquitectura del sistema

a) Asegurar la calidad formal de cada uno de los modelos elaborados en estaetapa desde el entorno tecnológico (4.4.1.f).

b) Utilizando técnicas matriciales y de revisión, establecer que existecoherencia entre sí de todos los subproductos obtenidos y que configuran eldiseño, asegurando también la consistencia (no duplicación de informaciónni ambigüedades).

c) Obtener la aceptación de la arquitectura del sistema de información, losrequisitos de operación y los de seguridad por parte de una autoridadasignada, o en su defecto, la coordinación de la UIFCE.

4.4.8. Generación de especificaciones de construcción

a) Especificación del entorno para la construcción de acuerdo a:Ø Entorno tecnológico: hardware, software y comunicaciones.Ø Herramientas, generadores de código y compiladores.Ø Restricciones técnicas.Ø Planificación de capacidades previstas.Ø Requisitos de operación y seguridad.

b) A partir de los subsistemas de diseño, definir los de construcción junto consus componentes (módulo o clase y formatos de interfaz), los cuales podránser distribuidos de acuerdo a criterios pertinentes. Además, se debeestablecer las dependencias entre subsistemas y sus componentes con elfin de establecer aspectos acerca de la plataforma de construcción yejecución, tales como agrupación de elementos en librerías.Adicionalmente, es preciso asignar los subsistemas a nodos que ayuden adeterminar la distribución de sus componentes.

10 Entre estos, la ubicación de los gestores de bases de datos o los sistemas de ficheros.




c) Especificar cada uno de los componentes de los subsistemas enpseudocódigo o lenguaje natural, sus elementos y sus parámetros enfunción del entorno tecnológico.

d) Realizar las especificaciones de cada uno de los elementos que hacenparte del modelo físico de datos a través del lenguaje correspondiente algestor de base de datos o sistemas de ficheros, en concordancia con suscaracterísticas, el entorno tecnológico y las normas de la UIFCE.

4.4.9. Diseño de la migración y carga inicial de datos11 (Plan de migración y cargainicial)

a) Establecer la infraestructura (almacenamiento y comunicaciones) y entornotecnológico (herramientas de software para estos procesos) que serequieren para la migración y carga inicia.

b) Definir los procedimientos de migración y carga inicial, referidos a laseguridad, preparación, carga de datos, verificación y comprobación de laintegridad de la información al finalizar el proceso.

c) Diseñar los módulos (mayor nivel de detalle) que sean necesarios para lamigración y carga inicial, identificando el orden de ejecución. De igualforma, definir los tipos y técnicas de pruebas a realizar.

d) Revisar y completar el plan y concretar el método de trabajo a seguir parala migración y carga inicial de datos.

4.4.10. Especificación técnica del plan de pruebas

a) Considerar el entorno que se requiere para la realización de pruebas delsistema, teniendo en cuenta el entorno tecnológico, sus restricciones,requisitos de operación y seguridad, herramientas de prueba, planificaciónde capacidades y procedimientos relativos a la promoción entre entornos,emergencia y recuperación.

b) Acorde con las características del diseño del sistema, establecer lasverificaciones de acuerdo a los niveles de prueba establecidos, de tal formaque sean aplicables a grupos de componentes y cubran aspectosfuncionales y no funcionales que aseguren el buen funcionamiento. Dichasverificaciones deben puntualizar:Ø Ámbito de aplicación (pruebas unitarias por componente, pruebas de

integración por subsistema de construcción, pruebas del sistema deinformación para comprobar su unificación, pruebas de implantación queaseguren el cumplimiento de la necesidades que justifiquen la creación

11 Solo se realizará esta actividad en caso de ser necesaria una carga inicial o migración deinformación.




del sistema, o pruebas de aceptación que verifiquen la buena respuestadel sistema frente a los requerimientos de los usuarios).

Ø Casos de prueba y sus procesos de ejecución.Ø Procedimientos de prueba que aseguren la buena ejecución de los

casos.Ø El entorno de prueba.Ø Criterios de aceptación.Ø Análisis y aceptación de resultados.

c) Revisar el plan de pruebas, estableciendo los perfiles implicados, susfunciones y el tiempo estimado para la ejecución de cada nivel de prueba.

4.4.11. Establecimiento de requisitos de implantación12

a) Determinar los requisitos para la documentación que se entregará a losdiferentes usuarios en forma de manuales. Por lo tanto, se debe especificarestándares, formato, estructura, soporte, distribución y mantenimiento dedicha documentación, junto con la fijación de copias y control de lasversiones.

b) Establecer los requisitos de implantación del sistema de información,especificando aquellos referidos a la formación necesaria de los usuariospara operarlo, a la infraestructura (software, hardware y comunicaciones) yal proceso de instalación.

4.4.12. Aprobación del diseño del sistema de información

a) Presentar el diseño del sistema de información a la Coordinación de laUIFCE para su posterior aprobación.

4.5. CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN (CSI)

Para el buen funcionamiento del sistema de información es necesario realizaraquellas actividades donde se generan los códigos de cada uno de loscomponentes, se desarrollan los procedimientos de seguridad y operación, juntocon los manuales de usuarios. En esta etapa se realizan dichas actividades.

4.5.1. Preparación del entrono de generación y construcción

a) Crear los elementos del gestor de base de datos o sistema de ficheros,definir y reservar el espacio de almacenamiento y demás dispositivos físicose iniciar dicha base de datos o sistema de ficheros cargando la informaciónnecesaria.

12 Actualización del catálogo de requisitos




b) Preparar el entorno en cuanto a librerías que se van a utilizar, herramientas talescomo compiladores, generadores de código, etc, puestos de trabajo yprocedimientos de operación y seguridad (DSI 4.4.8.a).

4.5.2. Generación del código de los componentes y procedimientos

a) Generar el código fuente de los componentes del sistema de información(DSI 4.4.8.b), teniendo en cuenta los estándares de la UIFCE recogidos enel catálogo de normas y, de igual forma, verificando y corrigiendo erroresacorde con el enlace con el código objeto.

b) Crear los procedimientos de operación y administración del sistema deinformación y los de seguridad y control de acceso al mismo que serequieren una vez sea implantado.

4.5.3. Ejecución de las pruebas unitarias

a) Asegurar la disponibilidad de todos los recursos necesarios para larealización de las pruebas unitarias a cada uno de los componentes(entorno, datos, librerías y procedimientos).

b) Realizar las pruebas unitarias con los casos asociados, evaluando yanalizando los resultados con el fin de determinar si dichos resultados sonlos esperados o si hay que llevar a cabo correcciones. Asimismo se debegenerar un registro de todo lo realizado

4.5.4. Ejecución de las pruebas de integración

a) Asegurar la disponibilidad de todos los recursos necesarios para larealización de las pruebas de integración (entorno, datos, librerías yprocedimientos), que permitan observar si los componentes estáninteractuando correctamente a través de sus interfaces.

b) Para cada verificación, realizar las pruebas con los respectivos casos,analizar los resultados obtenidos y crear el respectivo registro de lo hecho,así como el informe de cada una de las verificaciones.

c) Evaluar los resultados obtenidos de las pruebas de integración de tal formaque pueda determinarse la existencia de problemas, en caso de quehubiere, sus causas y el conjunto de acciones a ejecutar para solucionarlo.Asimismo, precisar nuevos casos de prueba de ser necesario.

4.5.5. Ejecución de las pruebas del sistema

a) Asegurar la disponibilidad de todos los recursos necesarios para larealización de las pruebas del sistema (entorno, datos, librerías yprocedimientos), con el fin de comprobar la integración globalmente delsistema tanto internamente, como con los demás sistemas de informacióncon los que interactúa.

b) Para cada verificación, realizar las pruebas con los respectivos casos,analizar los resultados obtenidos y crear el respectivo registro de lo hecho,así como el informe de cada una de las verificaciones.




c) Evaluar los resultados obtenidos de las pruebas de integración de tal formaque pueda determinarse la existencia de problemas, en caso de quehubiere, sus causas y el conjunto de acciones a ejecutar para solucionarlo.Asimismo, precisar nuevos casos de prueba de ser necesario.

4.5.6. Evaluación de los manuales de usuario

a) Elaborar la documentación (manuales) pertinentes para los usuarios finalesy los de explotación acorde con los requisitos contemplados en el DSI(4.4.11.a)

4.5.7. Definición de la formación de usuarios finales

a) Definir el esquema, tiempo y contenido para realizar el proceso deformación a los diferentes perfiles de usuario contemplados en el ASI, conel fin de que ellos aprendan a utilizar el sistema de información máseficazmente.

b) Especificar todos los recursos necesarios para llevar a cabo la formación,tales como equipos físicos y lógicos, aulas, entre otros. Igualmente, esimportante determinar el entorno en el que se desarrollará dicha formaciónrelativos a procedimientos de migración, seguridad, acceso, etc.

4.5.8. Construcción de los componentes y procedimientos de migración y cargainicial de datos

a) Considerar librerías, herramientas, compiladores y todos aquellos recursosnecesarios para realizar la migración y carga inicial de datos que fuerontenidos en cuenta en el DSI (4.4.9.a). Así, se configurará el entorno,determinando procedimientos y datos que se requieran en este proceso.

b) Generar el código fuente de los procedimientos y componentes que seannecesarios para realizar la migración y carga inicial teniendo en cuenta elDSI (4.4.9.b y 4.4.9.c). este código debe cumplir con los estándares de laUIFCE que ha sido recogidos en el catálogo de normas.

c) Efectuar las pruebas pertinentes de cada uno de los procedimientos ycomponentes de migración, de tal forma que los resultados permitandeterminar la posible existencia de problemas, la vía para solucionarlos y,de ser necesario, los casos de pruebas adicionales que deben generarse.

4.5.9. Aprobación del sistema de información

a) Recopilar todos los productos del sistema de información y presentarlosante la Coordinación de la UIFCE para su posterior aprobación.

4.6. IMPLANTACION Y ACEPTACION DEL SISTEMA




En esta fase el equipo de trabajo presenta ante la coordinación de la UIFCE todoel sistema de información para su posterior aprobación. Así, se procederá arealizar las actividades necesarias para su puesta en marcha.

4.6.1. Establecimiento del plan de implantación

a) Elaborar el plan de implantación del sistema teniendo como referencia elEVS (tarea 4.2.6.b), y los requisitos y procedimientos implicados que fueroncontemplados en el DSI (tareas 4.4.11.b y 4.4.1.g respectivamente). Aldefinir el plan se debe establecer los recursos necesarios para laimplantación, y contemplar factores tales como: la formación que cada perfilde usuario debe tener junto con el quipo que realiza las respectivaspruebas, la infraestructura requerida para la operación del sistema, lainstalación de componentes y procedimientos asociados, la carga inicial ymigración de datos, la realización de pruebas y la formalización del plan demantenimiento.

b) Constituir el equipo de trabajo (usuarios, personal técnico y demantenimiento) que participará en el proceso de implantación,especificando responsabilidades, perfiles y fechas.

4.6.2. Formación necesaria para la implantación

a) Preparar los esquemas de formación para cada perfil del equipo deimplantación y aceptación del sistema, puntualizando en la duración de loscursos y los recursos necesarios para su desarrollo.

b) Llevar a cabo el proceso de formación de todo el equipo de implantación yaceptación del sistema, realizando un registro de asistencia.

c) Planear la formación a usuarios finales basado en la CSI (actividad 4.5.7),estableciendo el esquema de los cursos, contenidos, los recursos ymateriales necesarios, lugar, fecha y prioridad para realizarlos.

d) Realizar seguimientos de la formación a usuarios finales ajustando el plancada vez que sea necesario.

4.6.3. Incorporación del sistema al entorno de operación

a) Verificar que la infraestructura necesaria para configurar el entrono seencuentre disponible. Además, es caso de ser necesaria una migración dedatos, confirmar los procedimientos empleados para estos procesoscontemplados en el DSI (actividad 4.4.9). Luego de esta comprobación,efectuar la instalación del software base del sistema.

b) Instalar todos los componentes del nuevo sistema (producto software) deacuerdo al plan de implantación, al DSI y a las normas y estándares de laUIFCE. De igual forma, preparar el entorno de datos teniendo en cuenta:Ø Crear las bases de datos pertinentes.Ø Establecer las normas relacionadas con el uso, actualización y consulta

de las bases de datos.




Ø Revisar los procedimientos para hacer copias de seguridad, indicando lafrecuencia las formas de consolidación y sincronización de lainformación.

Ø Preparar autorizaciones de acceso a los datos para cada perfil deusuario.

Por último, comprobar la correcta instalación del nuevo sistema y activastodos sus procedimientos, así como aquellos relativos a la migración dedatos (en caso de ser necesario).

4.6.4. Carga de datos al entorno de operación

a) Realizar la carga inicial de datos y, a continuación, la migración de acuerdoa los procedimientos trabajados en actividades anteriores.

4.6.5. Pruebas de implantación del sistema

a) Basados en el plan de pruebas de implantación, preparar las condicionesideales (en lo posible situaciones extremas) para realizar las pruebas,asegurando los recursos necesarios, así como la comunicación de dichoplan al equipo que las realizará.

b) Realizar las pruebas de implantación acorde con el DSI (actividad 4.4.10),con el fin de comprobar el correcto funcionamiento del entorno deoperación, evaluando factores tales como recuperación, seguridad,rendimiento, etc.

c) Evaluar los resultados obtenidos de las pruebas identificando la existenciade problemas y proponiendo sus respectivas medidas correctivas, de talforma que cumpla con todos lo requisitos de implantación.

4.6.6. Pruebas de aceptación del sistema

a) Preparar el escenario necesario para realizar las pruebas de aceptación, lascuales son efectuadas de acuerdo a los criterios de los usuarios finales quefueron contemplados en la tarea 4.6.1.b de la IAS.

b) Llevar a cabo las pruebas de aceptación del sistema con el objetivo decomprobar si éste cumple con todos los requisitos de los usuarios. Por lotanto, es importante registrar todos los resultados obtenidos.

c) Evaluar los resultados, identificar posibles problemas y determinar susrespectivas medidas correctivas. Así, se documenta el resultado global dela evaluación, el cual reflejará la aprobación del sistema por parte delusuario final.

4.6.7. Preparación del mantenimiento del sistema

a) Para establecer el plan de mantenimiento, se debe recopilar todos losproductos del sistema de información que van a ser susceptibles demantenimiento y se entregan al responsable para que éste a su vez, losanalice y revise de tal forma que determine la completa configuración del




software garantizando el control de futuras modificaciones. Asimismo, espertinente preparar el entorno, la infraestructura y las herramientas con lasque será realizado el mantenimiento (software y hardware)13, así como fijarmecanismos de registro y control de estos procesos.

b) Formalizar el plan de mantenimiento basado en lo realizado anteriormente ydefiniendo el tipo de mantenimiento para cada sistema de información y susrespectivos criterios de regulación. Igualmente, estimar el personal, susfunciones, perfiles y responsabilidades de cada uno de los encargados delservicio y coordinación del mantenimiento.

4.6.8. Establecimiento del acuerdo de nivel de servicio

a) Identificar los tipos de servicios que requiere el sistema a implantar,clasificándolos en los ofrecidos al cliente y los de gestión de operaciones(servicios en línea, por lotes, comunicaciones, seguridad y gestión decapacidad).

b) Detallar las propiedades funcionales, características y calidad de cada tipode servicio examinado anteriormente; si es posible que algunas de estaspropiedades sean cuantificables, entonces será necesario proponer lasrespectivas unidades de medición. De esta forma, será posible determinarla eficiencia, fiabilidad y facilidad de uso del sistema.

c) Establecer formalmente los tipos de servicios a los que el sistema debe darrespuesta por medio del acuerdo de servicios (compromisos adquiridos porcada tipo de servicio para cumplir con los objetivos); así como especificarlos mecanismos de regulación de los servicios, personal, infraestructura ynivel de calidad necesarios.

4.6.9. Presentación y aprobación del sistema

a) Recopilar la información del sistema, preparar la presentación y convocar ala Dirección de la UIFCE.

b) Presentar a la Dirección de la UIFCE esperando la aprobación formal delsistema de información.

4.6.10. Paso a producción

a) Comprobar que la instalación del sistema es correcto, realizando unainicialización, una nueva carga inicial e instalación de componentesfaltantes. Luego de esto, determinar la fecha para activar el nuevo sistema,eliminar el antiguo y especificar el proceso de transición del uno al otro.

13 En caso de que dichas herramientas disponibles en la UIFCE no sean suficientes para losrequerimientos del nuevo sistema de información, será necesario evaluar las alternativas quebrinda el mercado y elegir la más accesible y la que mejor se ajusten a las necesidades demantenimiento.




b) Arrancar el nuevo sistema de información, activando los procedimientos demantenimiento y los servicios que se van a prestar.

4.7. MANTENIMIENTO DE SISTEMAS DE INFORMACIÓN

Para que el sistema de información funcione lo más eficientemente posible esnecesario llevar a cabo labores de mantenimiento a petición de los usuarios de talforma que sean corregidos los problemas e inconvenientes que puedan surgir opara realizar acciones de mejora continua.

4.7.1. Registro de la petición

a) Crear un catálogo donde se registren las peticiones de los usuarios, demanera clara y completa, las peticiones de los usuarios que se refieran aproblemas o mejoras del sistema de información. Este catálogo debe estarde acuerdo con las normas y estándares de la UIFCE.

b) Determinar el tipo de mantenimiento que requiere la petición y si seencuentra dentro del plan de mantenimiento para ser aceptado orechazado. En caso de aceptarse la petición, se debe asignar a unresponsable para que continúe con el estudio del caso.

4.7.2. Análisis de la petición

a) Verificar la petición identificando si se trata de un mantenimiento correctivoo evolutivo (mejoras). En caso de ser correctivo es necesario determinar sies crítico para ser solucionado a corto, mediano o largo plazo y, así, actuarrápidamente o tomarse el tiempo para encontrar la solución más adecuada.En caso de ser evolutiva la petición, se debe establecer si éste es factible ysi se trata de una modificación de los sistemas de información existentes ouna adición de funcionalidades.

b) Analizar la relación entre peticiones para conformar grupos que se puedanabordar de manera conjunta y determinar la secuencia de los cambios.Además, considerar los sistemas de información que se ven afectados,otras peticiones en curso y el impacto en el entorno tecnológico.En el caso de peticiones evolutivas, se deben estudiar detalladamente deacuerdo a las versiones vigentes y empleando algunas fases de Métrica(ASI y EVS) para establecer requisitos, alcances, modificaciones yexistencia de opciones viables en el mercado.Si la petición es correctiva, es preciso comprobar que toda soluciónadoptada no afectará el sistema, conservando su integridad y operatividad.Finalmente, es necesario proponer varias alternativas de solución fijandofecha límite de implantación y coste aproximado. La elección de la soluciónmás adecuada se hará junto con los usuarios y, de esta manera, seaprobará o rechazará la petición.




4.7.3. Preparación de la implementación de la modificación

a) Analizar el impacto generado por los cambios e identificar los elementos(infraestructura y productos software) implicados en dichos cambios.

b) Establecer un plan de acción para la modificación, identificando las tareasde los procesos EVS, ASI, DSI, CSI, IAS que son precisos realizar enfunción de la petición estudiada y el plan de mantenimiento. Además,determinar un plan de trabajo que especifique costes, plazos paraimplantación, fechas y personal que va a integrar el equipo de trabajo, juntocon los puntos de control que servirán para hacer un seguimiento del plandurante la implementación de la modificación.

c) Generar el plan de pruebas de regresión14, especificando los casos deprueba basados en las relaciones entre los componentes contemplados enel MSI (tarea 4.7.3.a).

4.7.4. Seguimiento y evaluación de los cambios hasta la aceptación

a) Realizar seguimiento del plan de acción (puntos de control), es decir,evaluar todos los cambios introducidos y lo obtenido en las fases EVS, ASI,DSI, CSI, IAS. Este control implica verificar la realización de pruebasunitarias, de integración y del sistema, actualizar los productoscorrespondientes y coordinar las modificaciones en cada componente,asegurando su correcta implantación.

b) Luego del proceso de construcción, realizar las pruebas de regresiónasegurando el funcionamiento normal del sistema de información.Asimismo, es importante documentar todos los resultados obtenidos paradetectar posibles problemas y adoptar las medidas correctivas necesariaso, en caso de mostrar comportamientos correctos, ser aprobado por partedel responsable de mantenimiento.

c) Aprobar formalmente la petición de mantenimiento y cerrarla actualizandosu respectivo catálogo. Igualmente, registrar los datos cuantitativosrelativos al tiempo empleado en todo el proceso de mantenimiento con el finde establecer métodos más eficaces para la mejora y solución deproblemas del sistema de información

14 Estas pruebas tratan de eliminar el denominado efecto onda , el cual consiste en comprobarque los cambios introducidos no generen efectos indeseados o errores en componentes que nofueron modificados.




5. APLICACIÓN DEL MANUAL A UN PROYECTO DELA UIFCE

Responsable: Analista de Sistemas de Información de la UIFCE.

Nombre del Proyecto: Control y administración de salones15

5.1. PLANEACIÓN DE SISTEMAS DE INFORMACIÓN5.1.1. Descripción General de la PSI

Objetivo del Proyecto: Establecer un medio por el cual los profesores,estudiantes y demás usuarios de la Facultad de Ciencias Económicaspuedan programar y tener acceso a información actualizada sobre el estadode los salones y salas de informática.Relación del objetivo con los de la UIFCE: Este proyecto ayudará a cumpliruno de los objetivos de la UIFCE: Implementar mejoras en procedimientosy tecnologías que agilicen el manejo de la información al interior de laFacultad, convergiendo en la optimización de los recursos disponibles 16.Así se podrá tener un mayor control sobre la asignación de salones de talforma que sea más coordinado y eficiente por medio del aplicativo.

Primero que todo la UIFCE y el área de sistemas de información donde sedesarrollará el aplicativo y estará a cargo de su mantenimiento y buenfuncionamiento, las Escuelas de Administración y Contaduría y la deEconomía de la Facultad, quienes asignan bajo el sistema actual lossalones, así como los integrantes del grupo de Sistemas de Información dela UIFCE, quienes diseñan las ayudas respectivas para el uso del aplicativo.

Las fases del proyecto estarán desarrolladas por la persona vinculadadirectamente con el aplicativo (Analista de Sistemas de Información).

5.1.2. Definición y descripción de la PSI

Plantación de Sistemas de Información: Encontrar una manera de hacermas eficiente y preciso el control y asignación de salas de computo a losusuarios que las necesiten.

15 El desarrollo de este ejemplo para observar la aplicabilidad del manual fue realizado con la totalcolaboración del analista de Sistemas de Información de la UIFCE.16 http://www.fce.unal.edu.co/uifce/newuifce/objetivos.php

http://www.fce.unal.edu.co/uifce/newuifce/objetivos.php




Estudio de Viabilidad del Sistema: En el proyecto que se quiere adelantar yase tiene un elemento importante que es el aplicativo WEBSIUI donde sepodría añadir este complemento.

Análisis del Sistema de Información: Identificar la estructura jerárquica y porconsiguiente el proceso que esta ligado a la asignación de los salones

Diseño del Sistema de Información: En este caso el diseño del sistemaestaría basado en las opciones que se presentaría al usuario, pues yatenemos el aplicativo donde se colocara.

Construcción del Sistema de Información: Construir un diagrama de flujo delos principales actores del sistema

5.1.3. Estudio de la información relevante

El aplicativo Websiui (Sistema de Información de la Unidad de Informática yComunicaciones de la Facultad de Ciencias Económicas) ya ha sidodesarrollado bajo las esferas del control de salas de cómputo, asignaciónde turnos para usuarios (estudiantes); control y asignación de turnos paralos monitores de la UIFCE; inscripción, evaluación y administración decursos libres en software ofrecidos por la Unidad. Estos servicios prestadospor el sistema han funcionado efectivamente proporcionando mejoras en elmanejo de la información al interior de la UIFCE. Además, se hanrealizado investigaciones como por ejemplo, Sistemas de Información,Aplicativo Web, Diseño de Bases de Datos, Web Services, entre otros, quede alguna manera han contribuido al desarrollo de los sistemas deinformación con los cuales hoy contamos.

5.1.4. Identificación de requisitos

Los procesos internos de la Unidad que se ven implicados por el proyectoson: la forma en el que profesores o monitores de diferentes asignaturassolicitan salas de cómputo para llevar a cabo las clases llenando un formatoestándar suministrado por la UIFCE, junto con los pasos para contemplar lapetición y programar la asignación de salas por parte de la Coordinación.Asimismo, el proceso de solicitud, evaluación y asignación de salones en laEscuela de Economía17. Además, el control que actualmente se lleva pararegistrar el efectivo uso de las salas de informática por parte de losmonitores, donde se consigna información tal como el nombre del profesor,la asignatura, numero de asistentes y software utilizado en un formato Excel

17 Lugar donde generalmente se solicitan los salones para las clases.




y, luego, es revisado por la Coordinación de la UIFCE para la asignación desalas.

Basados en dichos procesos actuales para llevar a cabo la solicitud,asignación y administración de salones, la información que permitacoordinar estos procesos son cruciales para obtener mayor organización,por lo tanto, los datos necesarios será el nombre del profesor, la materia,las fechas y el aula requerida de tal forma que se eliminen los formatosllenados a mano por la opción de realizar dicho registro en Internet y,asimismo, el sistema informe sobre la disponibilidad de salones con el fin deevitar la pérdida de tiempo por parte de Coordinadores en la verificaciónmanual de éstos.

5.1.5. Estudio de los Sistemas de Información Actuales

El Websiui brinda soporte para procesos de la UIFCE, tales como:

• Para los estudiantes, la posibilidad de apartar turnos para los equiposen usuarios (máximo 2 horas diarias y 6 horas a la semana), así comoconsultar su programación de turnos, cancelar los mismos y consultarlas sanciones que se le hayan aplicado (en caso de existir) y el estadode cumplimiento en el que se encuentran. Igualmente, los estudiantestiene la posibilidad de inscribir cursos libres ofrecidos por la UIFCE yrevisar sus notas finales de los mismos.

• Para los monitores, además de las anteriores, pueden administrar losturnos (ingresar los turnos efectivamente cumplidos por los usuarios yubicarlos en los equipos correspondientes), pueden consultar suprogramación de la semana correspondiente, ingresar a turno comomonitor, registrar la salidas junto con las actividades realizadas,realizar reprogramaciones de horas de investigación y trabajo degrupo, registrar reemplazos de horas en salas, cuando sea pertinentellenar la bitácora de equipos

• Para los monitores que tengan permisos en la opción de cursos libres(grupo de capacitación, por ejemplo) tendrán la posibilidad deadministrar dichos cursos, obtener la lista de admitidos para los cursose ingresar las notas finales.

El Websiui funciona por medio de interfaces a los que se pueden teneracceso vía Internet y las bases de datos donde se encuentran las tablasrespectivas trabajan bajo en programa SQL Server.

5.1.6. Diseño del Modelo de Sistemas de Información

Al confirmar que el WEBSUI cumple con los requisitos necesarios para laimplementación de la nueva aplicación puesto que es de fácil acceso para




todos los usuarios del sistema en curso (profesores, alumnos yresponsables del aplicativo). Además de cobijar a todos los usuarios evita almáximo el posible error humano a la hora de asignar tanto horario comosalones y salas de computo, y le da la opción a los usuarios de enterarse delas actividades planeadas desde cualquier lugar y en cualquier momento.

5.1.7. Definición de la Arquitectura Tecnológica

Debido a que el aplicativo Websiui ya se encuentra funcionando y con unainfraestructura determinada y óptima, no se hace necesario contemplararquitectura adicional, ya que la administración de salones representaríauna mejora para dicho aplicativo, el cual puede funcionar con la yaexistente.

5.1.8. Definición del plan de acción

Como los objetivos principales del proyecto son los de darle a los usuariosla opción de programar el préstamo de salones y salas de computo desdecualquier lugar vía Internet y de evitar totalmente el error humano que sepuede presentar en el momento de adjudicar el préstamo y que este tuvieseun cruce de horario con otro, los logros alcanzados con este programa sedeben ver al poco tiempo y se verán reflejados en la dinámica existente enel momento de pedir y asistir a la sala o salón asignado.

5.2. ESTUDIO DE VIABILIDAD DEL SISTEMA

5.2.1. Establecimiento de alcances del sistema

La nueva aplicación que se planea adicionar deberá cubrir necesidadestales como la asignación y coordinación de salones y salas en la Facultadde Ciencias Económicas de manera eficiente y rápida, además de proveercontrol sobre aquellos espacios que se encuentren disponibles y los que nopara actividades académicas. Es importante tener en cuenta que esteproyecto pretende cubrir requerimientos tanto para el personal de la UIFCEen la asignación de las salas de cómputo, como para la Escuela deEconomía la cual se encarga de la administración de los salones de claseen la Facultad.

Catálogo de Usuarios:

P Usuarios Externos de la UIFCE:§ Personal administrativo que asigna, coordina y controla los salones

de clase en la Facultad (Escuela de Economía).§ Personal administrativo que pueda brindar información relevante al

proyecto.




ü Usuarios Internos de la UIFCE:§ Coordinadores§ Analista de Sistemas de Información§ Monitores

5.2.2. Estudio de la situación actual

Como se anotó anteriormente, se busca realizar mejoras al aplicativoWebsiui, por lo tanto, se describirá la manera como éste funciona.

Ilustración 1 Websiui

Inicialmente, las personas que tienen acceso a este sistema son aquellasque están vinculadas con la Facultad de Ciencias Económicas, así, debenidentificarse para poder ingresar (Ilustración 2 Inicio de sesión).

Ilustración 2 Inicio de sesión

Cada persona, de acuerdo con su perfil, tendrá ciertos permisos que lepermiten realizar actividades especificas y, otras, generalizadas como en elcaso de los estudiantes (Ilustración 3 Inicio Websiui).




Ilustración 3 Inicio Websiui

Turnos de usuarios: Los estudiantes tienen permisossolamente para las dos primeras opciones. En laprimera es posible consultar la programación de cadauna de las salas de informática en la fecha que dichousuario elija. En la segunda opción, se puede acceder avarias alternativas: reservar turnos (acceder a un

computador para realizar actividades académicas, máximo por 2 horasdiarias y 6 a la semana), consultar los turnos de acuerdo al estado de losmismos (todos, cancelados, reservados, en uso o usados), cancelar turnosy consultar las sanciones por incumplimiento de turnos. Para los monitoresde la UIFCE, además de las anteriores opciones, pueden contar con elmanejo de turnos global para la administración de los mismos, los turnosocupados e informes de turnos de usuarios.

Cursos Libres: En este ítem, los estudiantes puedenacceder a las tres primeras opciones, las cuales lespermiten inscribir, consultar y evaluar los cursos libresofrecidos por la UIFCE. Las siguientes opciones dan laposibilidad de administrar y coordinar los cursos porparte de los integrantes del grupo de Capacitación, loscoordinadores y el analista de programación de la

UIFCE.

Turnos de monitores: Esta opción del menú seencuentra activada solamente para los monitores de laUIFCE. Aquí, es posible consultar los turnos de lasemana, entrar y salir de turno (control delcumplimiento y puntualidad de los turnos de monitores);el historial de turnos con fechas, hora de entrada ysalida, junto con las actividades realizadas; registrar




reemplazos, liberaciones de horas, reprogramar horas de investigación otrabajo de grupo; y, bitácora de equipos para registrar aquelloscomputadores que presenten alguna deficiencia en su desempeño en arasde ser arreglado.

UIC FCE: A esta opción tienen acceso solamentequines tienen el cargo de Coordinadores de la UIFCE.Éste provee información tal como las horas liberables ypermisos que tiene cada uno de las personas quehacen parte de la Unidad, los integrantes de los gruposde investigación y los temas, y, por último, los gruposde trabajo interno.

Otras opciones: El Analista de Sistemas deInformación (Álvaro Palacios), es quien tiene todos losaccesos permitidos para controlar y administrar elsistema, por medio de las bases de datos que seencuentran en el servidor de la Facultad (sfeconoweb).

Los profesores y personal administrativo no poseen actualmente permisospara ingresar al Websiui. Sin embargo, debido al proyecto de adicionar laopción de administración de salones, los docentes podrían tener permisossolamente en esta área, al igual que el personal administrativo encargadoespecíficamente de la asignación de salones (Escuela de Economía).

5.2.3. Definición de Requisitos del Sistema

ü Servidor de la base de datos debe funcionar con SQL Server 2000.ü El servidor Web funciona con Windows 2000ü Los equipos clientes deben tener Internet Explorer versión 5.0 o superior,

y Netscape versión 6.0ü Javascript versión 4.0 en adelante

Necesidades que debe suplir:ü Brindar información eficiente y real de las actividades, lugar y hora que

se llevaran a cabo en la Facultad.ü Permitir que los docentes puedan realizar las solicitudes de salones y

salas por medios electrónicos que le permitan ingresar y consultar lainformación desde cualquier lugar y en cualquier momento.

ü Dejar que los estudiantes estén informados sobre el lugar y hora de susclases




ü Permitir que los administradores de los salones puedan acceder yactualizar la programación de los salones y salas de la Facultad.

5.2.4. Estudio de alternativas de solución

Debido a que el Websiui es un Sistema de Información hecho a la medidapara la Facultad de Ciencias Económicas, no existe otra alternativa desoftware que supla las necesidades para el que éste es diseñado o paraagregar el nuevo módulo de administración de salones. Sin embargo, paradiseñarlo existen varias opciones en cuanto a software de programación,tales como SQL, Microsoft Visual FoxPro, Visual C++, entre otros, quesirvan para construir un modelo orientado a objetos.

5.2.5. Valoración de las alternativas

El Sistema de Información ya se encuentra programado con SQL einstalado de acuerdo a los requisitos anteriormente numerados, así que elnuevo módulo se construirá bajo esos mismos estándares y, por lo tanto, nose demandará la compra de nuevo software.

5.2.6. Selección de la solución

Se lleva a cabo la solución prevista.

5.3. ANÁLISIS DEL SISTEMA DE INFORMACIÓN5.3.1. Definición del sistema

Cada uno de los usuarios debe identificarse en el Sistema para poder teneracceso a la información de acuerdo a su perfil. Todos lo permisos ydescripción del aplicativo se realizó anteriormente.

5.3.2. Casos de uso

Para este proyecto se plantean seis casos de uso:• Caso de Uso 01: Administración de Salones. Este caso de uso permite a

los coordinadores crear, modificar, eliminar y consultar registros de lossalones y salas con sus características particulares.

• Caso de Uso 02: Registro de solicitud de programación. Se refiere a laposibilidad que tiene los estudiantes de solicitar una sala o salón de laFacultad a una hora y día determinado, así de eliminar solicitudes norespondidas por parte del Administrador de Salones. Asimismo, dichoadministrador también podrá aceptar o rechazar las solicitudes realizadaspor los responsable, es decir, docentes o encargados.

• Caso de Uso 03: Registro de actividades. Permite al Administrador crear,




consultar y eliminar actividades programadas para realizarlas en lossalones o salas solicitadas.

• Caso de Uso 04: Programación de salones. El Administrador de salonespuede crear, consultar o eliminar la programación de las salas deinformática y los salones.

• Caso de Uso 05: Aprobación de solicitudes. Cuando el Administrador desalones realiza una nueva programación aprobará o rechazará lassolicitudes realizadas por los responsables (docentes o encargados).

• Caso de Uso 06: Control de salones. Este caso de uso aplica para losmonitores de las salas de informática, quienes deben registrar el efectivouso de las salas y el número de usuarios o estudiantes que asistieron a laclase.

5.3.3. Identificación de subsistemas de análisis

Debido a la mediana envergadura del proyecto (adición de un nuevo móduloal Sistema de Información Websiui), no es necesario descomponerlo ensubsistemas.

5.3.4. Diagrama de interacción de los casos de uso

El diagrama de interacción de casos de uso se visualiza en la Ilustración 4Interacción de casos de uso.

Administrador de Salones: Personal administrativo de la Escuela deEconomía encargado de hacer las reservas de salones, y los Coordinadoresde la UIFCE, quienes asignan las salas de informática.

BD MsSQL: Base de datos que interactúa con el sistema y desde donde seleen los datos.

Otros: Estudiantes, docentes y administrativos que consultan laprogramación de los salones.

Responsable: Aquella persona que realiza la solicitud de salón o sala,puede ser el Docente o encargado.

Monitores: quienes están a cargo y deben entregar las salas de informáticaen buenas condiciones a los profesores.




Ilustración 4 Interacción de casos de usoFUENTE: PALACIOS VILLAMIL, Álvaro Enrique. Casos de Uso Detallados para elmodulo de administración de salones. Sistema de Información, Unidad deInformática y Comunicaciones, 2005

5.3.5. Diagrama de clases

Las clases son cinco: programación, personas, actividades, salones ysolicitudes. Las programaciones las realizan los administradores desalones y salas según corresponda con sus actividades, fecha y hora; laspersonas involucradas en el sistema, de quienes se encuentra los datospersonales; los diferentes tipos de actividades a efectuar por parte delresponsable; las solicitudes que realizan los responsables con fecha, hora yactividad, junto con las opciones para aceptarlas o rechazarlas; y salones adisposición, capacidad y ubicación.




5.3.6. Modelo de Datos

Este modelo corresponde a la base de datos y las relaciones entre lastablas que van a dar soporte al módulo de salones del Sistema deInformación (Ilustración 5 Modelo de datos).

Ilustración 5 Modelo de datosFUENTE: PALACIOS VILLAMIL, Álvaro Enrique. Definición de datos para elsistema de control de salones. Sistema de Información, Unidad de Informática yComunicaciones, 2005

5.3.7. Definición de interfases de usuario

El esquema de las interfaces se encuentra en el anexo. Es importanterecordar que este proyecto es una mejora al sistema de informaciónexistente en la Facultad de Ciencias Económicas, por lo tanto, las interfasesestarán acorde con el entorno de éste.

5.3.8. Análisis de consistencia y especificación de requisitos

De acuerdo con el análisis propuesto se analizara como responde elaplicativo a las cinco clases presentes: programación, personas, actividades,salones y solicitudes.




La programación de salas y salones las puede realizar el administradorconociendo los horarios establecidos para cada semana y según sudisponibilidad.

Las personas (usuarios) pueden acceder de una manera fácil y rápida a todala información referente a los horarios de salones o salas.

Las actividades realizadas en cada uno de los salones o salas se actualizaninmediatamente después de asignar la solicitud y por esta razón esta alalcance de todos.

Las solicitudes se realizan de acuerdo con la disponibilidad de horario yabriendo la sesión, la cual le permite esos privilegios.

5.3.9. Especificación del plan de pruebas

El mismo Analista de Sistemas de Información Álvaro Palacios realiza laspruebas para comprobar la integridad del sistema antes de colocarlo enfuncionamiento para todos los usuarios. Así, dependiendo de losrequerimientos funcionales del sistema, ingresa los datos de prueba y luegoverifica que los resultados sean los esperados.

5.4. DISEÑO DEL SISTEMA DE INFORMACIÓN

5.4.1. Definición de la arquitectura del sistema

El Sistema de Información tendrá como base el ya existente, por lo tanto,utilizará dicha arquitectura adicionando el módulo específico del control yadministración de salones. Asimismo, el acceso a la información estarácondicionado al perfil que cumple cada uno de los usuarios, teniendo encuenta que cada uno deberá proporcionar su nombre y clave de accesopara poder ingresar:Estudiantes: tendrán los mismos permisos correspondientes al sistema yaexistente y, adicionalmente, podrán consultar la programación de lossalones.Monitores de la UIFCE: Además de los permisos como monitores yestudiantes, tendrán la posibilidad de controlar si las salas asignadas hansido efectivamente utilizadas.Docentes: Podrán solicitar y consultar la programación de salones y salas.Administrativos: El personal administrativo no tiene permisos para ingresaral Sistema, solamente lo tendrá la persona encargada de asignar lossalones en la Facultad.Coordinadores de la UIFCE: Junto con los permisos que ya tienen paraingresar a las bases de datos, podrán asignar y programar las salas deinformática.

La infraestructura técnica, es decir, el hardware y software existente en la




Facultad es apto y suficiente para la ejecución del Sistema de Información,sin embargo, puede ser susceptible de mejoras. Dicha arquitectura seresume de la siguiente manera:ü Los equipos de la Facultad se encuentran en el dominio de la

Universidad Nacional de Colombiaü Lenguaje: PHP 3.4ü Nombre del servidor: sfeconowebü Servidor web: ISS (Internet Information Server) Vr. 5.0ü Estación de prueba: econos2001admü Personal para el plan de pruebas: Analista de Sistemas de Información

y la Coordinación de la UIFCE

5.4.2. Diseño de la arquitectura de soporte

La adición del nuevo módulo al sistema no se encuentra divido ensubsistemas, además, para el Sistema de Información no existenprocedimientos para realizar automáticamente funciones de mantenimiento,sino que ésta se realiza de manera aleatoria y manual mente por el Analistade Sistemas de Información.

5.4.3. Diseño de casos de uso reales

Caso de uso: CU01 Administración de salones

Actores Primarios: Administrador

Participantes e intereses: Administrador: Llevar estricto control de los salonesdisponibles para la programación de actividades, así comorealizar modificaciones a las características asociadas acada uno.

Precondiciones: El usuario debe haberse identificado, autenticado yverificado sus permisos.

Descripción El Administrador de ingresa a la opción de archivo desalones, en este punto tiene varias posibilidades: 1. Modificarun registro de salón existente; 2. Eliminar un registro de salón,siempre que no tenga asociadas programaciones deactividades; 3. Consultar los salones característicasparticulares. Para los dos primeros casos la información quese captura es la siguiente: el identificador del salón, elnombre del mismo (si lo tiene), descripción de lascaracterísticas particulares (si las tiene), capacidad, ladependencia a la que pertenece, edificio y si pertenece a laUnidad de informática.

Curso típico de eventos Después de ingresar a la opción de archivo de salones seprocede a crear o modificar el registro de salón deseado.

Se llenan los datos correspondientes al nuevo registro de




salón, los anteriormente mencionados.Cuando el usuario cree que la información está correcta,

selecciona la opción de guardar.El sistema verifica la integridad de los datos suministrados y si

son correctos procede a hacer permanentes los cambiosal registro trabajado.

Curso alternativo Si el salón ya existe y se quiere modificar se debe localizarprimero mediante la consulta de “Salones” y luegoseleccionar la opción de modificar definición.

Excepciones No se puede eliminar un salón que tenga asociadoprogramaciones de actividades.

Poscondiciones: La información del salón se debe guardar en el servidor debase de datos en las tablas correspondientes.

Ilustración 6 Caso de uso 01

Caso de uso: CU02 Registro de solicitud de programación

Actores Primarios: Administrador, responsable de la actividad

Participantes e intereses: Administrador: Llevar estricto control de las solicitudes dereserva hechas por los responsables de las actividades conrespecto a los salones disponibles.Responsable: Realizar solicitud de programación deactividades.

Precondiciones: El usuario debe haberse identificado, autenticado yverificado sus permisos. Pensar

Deben estar creados en el sistema todos los salones sobre loscuales se quiera hacer solicitud de programación.

Descripción El usuario selecciona la opción de “solicitudes deprogramación”, en este punto tiene varias posibilidades: 1.Consultar las solicitudes realizadas anteriormente y verificar elestado de las mismas, si el usuario es administradoradicionalmente podrá agregar comentarios a las solicitudes,aceptarlas o rechazarlas; 2. Realizar una solicitud deprogramación de salones; 3. Retirar una solicitud realizadapreviamente en la cual no se haya recibido respuesta. Paralos dos primeros casos la información que se captura es lasiguiente: el identificador del salón, el nombre de la personaque lo solicita, la fecha de la programación o el intervalo defechas (en dado caso se deben indicar los días de lasemana), la descripción de la actividad a realizarcapacidad, la hora de inicio y finalización.

Curso típico de eventos Después de ingresar a la opción de “Solicitud deprogramación” se procede a crear o modificar losregistros del usuario correspondiente (si es administrador,todos, si no, los propios).




Se llenan los datos correspondientes al nuevo registro desolicitud, los anteriormente mencionados.

Cuando el usuario cree que la información está correcta,selecciona la opción de guardar.

El sistema verifica la integridad de los datos suministrados y sison correctos procede a hacer permanentes los cambiosal registro trabajado. El sistema verifica que no existanactividades programadas en las fechas y horassolicitadas para ahorrar tiempo en el proceso deseguimiento de las solicitudes.

Curso alternativo

Excepciones No se puede eliminar una solicitud que tenga asociado unarespuesta o una programación.

Poscondiciones: La información de la solicitud se debe guardar en el servidorde base de datos en las tablas correspondientes.


Caso de uso: CU03 Registro de actividades


Participantes e intereses: Administrador: Te control de las actividades que seprograman en los salones y de los responsables de cada unade esas actividades


Deben estar creados todos los usuarios responsables a loscuales se quieren asociar las actividades.

Descripción El usuario selecciona la opción de “Archivo de actividades”,en este punto tiene varias posibilidades: 1. Consultar lasactividades guardadas anteriormente y verificar los datos delas mismas; 2. Crear una nueva actividad; 3. Eliminar unaactividad. Para los dos primeros casos la información que secaptura es la siguiente: El código de la actividad, el nombrede la actividad, la clase de actividad, el responsable.

Curso típico de eventos Después de ingresar a la opción de “Archivo de actividades”se procede a crear o modificar los registros de laactividad correspondiente.

Se llenan los datos correspondientes al nuevo registro deactividad, los anteriormente mencionados.


El sistema verifica la integridad de los datos suministrados y sison correctos procede a hacer permanentes los cambiosal registro trabajado.

Curso alternativo




Excepciones No se puede eliminar una actividad que tenga asociado unaprogramación.

Poscondiciones: La información de la actividad se debe guardar en elservidor de base de datos en las tablas correspondientes.


Caso de uso: CU04 Programación de salones


Participantes e intereses: Administrador: Llevar estricto control de las actividades y lossalones en el proceso de programación.


Deben estar creados todas las actividades y los salones sobrelos cuales se quiere realizar programación.

Descripción El usuario selecciona la opción de “Programación”, en estepunto tiene varias posibilidades: 1.Eliminar programaciónprevia; 2. Consultar programación; 3. Crear una nuevaprogramación. Para los dos primeros casos la informaciónque se captura es la siguiente: El código de la actividad, elsalón en el cual se quiere realizar la actividad, la fecha, lahora de inicio y finalización de la actividad.

Curso típico de eventos Después de ingresar a la opción de “Programación” seprocede a crear los registros de la programacióncorrespondiente.

Se llenan los datos correspondientes al nuevo registro deprogramación, los anteriormente mencionados.



Curso alternativo

Excepciones



Caso de uso: CU05 Aprobación de solicitudes





Participantes e intereses: Administrador: Realizar control sobre las solicitudes realizadaspor los encargados de las actividades con respecto de lasreservas de salones.Que cuando se realice una aprobación se programe la salade forma automática.Que se controle el cruce de



Descripción El usuario selecciona la opción de “Programación”, en estepunto tiene varias posibilidades: 1.Eliminar programaciónprevia; 2. Consultar programación; 3. Crear una nuevaprogramación. Para los dos primeros casos la informaciónque se captura es la siguiente: El código de la actividad, elsalón en el cual se quiere realizar la actividad, la fecha, lahora de inicio y finalización de la actividad.

Curso típico de eventos Después de ingresar a la opción de “Programación” seprocede a crear los registros de la programacióncorrespondiente.

Se llenan los datos correspondientes al nuevo registro deprogramación, los anteriormente mencionados.



Curso alternativo

Excepciones



Caso de uso: CU06 Control de salones


Participantes e intereses: Administrador: Llevar estricto control de las actividades y lossalones en el proceso de programación.



Descripción El usuario selecciona la opción de “Control”, luegoselecciona la sala o salón a a registrar, el sistema muestra lasactividades programadas para el día actual, en este punto




el usuario puede seleccionar la actividad a registrar yseleccionar alguna de las siguientes posibilidades: 1.Nousado; 2. Usado tarde; 3. Usado normalmente; 4. Registrar elnúmero de usuarios y; 5. Registrar observaciones.

Curso típico de eventos Después de ingresar a la opción de “Control” se procede aseleccionar la sala o salón correspondiente.

Se muestra la programación para la sala seleccionada.El usuario selecciona la actividad a controlar.Se realizan las modificaciones pertinentes y observaciones

sobre el uso de la sala o salón.Se selecciona el botón guardar.

Curso alternativo

Excepciones


Ilustración 11 Caso de uso 06FUENTE: PALACIOS VILLAMIL, Álvaro Enrique. Casos de Uso Detallados para elmodulo de administración de salones. Sistema de Información, Unidad deInformática y Comunicaciones, 2005

5.4.4. Diseño de clases

El diseño de clases se puede observar en la Ilustración 12 Diagrama declases




Adicionar_salon()Modificar_datos_salon()Eliminar_salon()Consultar_salon()

Identificador c(20)Nombre c(100)CaracterísticasCapacidad n(3)DependenciaEdificio

Salones

Adicionar_actividad()Modificar_datos_actividad()Eliminar_actividad()Consultar_actividad()

Identificador c(20)Nombre c(100)TipoResponsable

Actividades

Adicionar_programacion()Modificar_datos_programacion()Eliminar_programacion()Consultar_programacion()

ActividadSalónFechaHora

Programación

Adicionar_solicitud()Modificar_datos_solicitud()Eliminar_solicitud()Consultar_solicitud()Adicionar_observaciones()Aceptar_solicitud()Rechazar_solicitud()

SalónSolicitanteFecha solicitadaActividadHora de inicioHora de finalización

Solicitudes

Adicionar_persona()Modificar_datos_persona()Eliminar_persona()Sancionar_persona()Consultar cursos()

CedulaNombresApellidosDirecciónTeléfonoEmail

Persona

Ilustración 12 Diagrama de clases

FUENTE: PALACIOS VILLAMIL, Álvaro Enrique. Diagrama de clases para elsistema de control de salones. Sistema de Información, Unidad de Informática yComunicaciones, 2004

5.4.5. Diseño de la arquitectura de módulos del sistema

A pesar de que se conocen los procesos del Sistema de Información, éstosno se encuentran documentados ni existen flujogramas de los mismos. Lainterfaz que funcionará para este nuevo módulo se encuentra en el anexo.

5.4.6. Diseño físico de datos.

Las pruebas de concurrencia no se realizan, pero el Sistema funcionasatisfactoriamente y no se demora en procesar las peticiones debido a quelos registros no han alcanzado grandes cantidades. El diccionario de datosse presenta en la Ilustración 13 Diccionario de datos.




DICCIONARIO DE DATOS

TABLE Personas

La tabla almacena los datos de todas las personas que puedan tener alguna relación con el sistema sin importar si son usuarios o no.

No. Campo Tipo Longitud Valor pordefecto

Permitenulo

Descripción

1 idpersona varchar 20 NULL No Es el identificador del registro dentro de la tabla (llave primaria), corresponde aldocumento de identificación de la persona, generalmente la cédula

2 nombres varchar 100 NULL YES Nombres completos de la persona

3 apellidos varchar 100 NULL YES Apellidos completos de la persona

4 fecha_nacimiento smalldatetime NULL NULL YES Fecha de nacimiento de la persona

5 direccion varchar 100 NULL YES Dirección de residencia

6 telefono varchar 60 NULL YES Telefono o telefonos de contacto

7 email varchar 60 NULL YES Correo electrónico personal

8 edificio varchar 3 NULL YES Peter final fantacy

9 piso varchar 1 NULL YES Peter final fantacy

10 oficina varchar 60 NULL YES Peter final fantacy

11 extension varchar 5 NULL YES Peter final fantacy

12 t_estudiante bit NULL NULL YES Es de tipo estudiante de pregrado

13 t_docente bit NULL NULL YES Es de tipo docente

14 t_administrativo bit NULL NULL YES Es de tipo administrativo




15 t_unidad bit NULL NULL YES

TABLE tipos_actividades

Almacena la información relacionada con los tipos de actividades que se pueden programar.


Permitenulo

Descripción

1 idtipo char 20 NULL No Es la clave primaria de la tabla.

2 ntipo char 240 NULL YES Es la descripción del tipo de actividad.

3 color nvarchar 50 NULL YES Es el código del color asociado al tipo de actividad.

TABLE actividades

Corresponden a las actividades que pueden ser programadas en los salones, auditorios, salas.


Permitenulo

Descripción

1 idactividad int NULL NULL No Corresponde al identificador de la actividad a programar

2 nactividad varchar 100 NULL YES Es la descripción (nombre) de la actividad.

3 idtipo char 20 NULL YES Es el tipo de actividad, es llave foranea proveniente de la tabla"Tipos_actividades"

4 idsemestre varchar 20 NULL YES Corresponde al semestre en el cual se programa la actividad (por ejemplo lasmaterias). Las actividades que se programan todos los semestres tendran enNULL este campo.

5 idpersona varchar 20 NULL YES Es la persona responsable de la actividad. Para las materias será el profesor, así




se tiene la programación semestral de las materias.

6 grupo varchar 50 ('01') No Es el grupo correspondiente a la actividad. Generalmente materias.

7 idmateria varchar 20 NULL YES Es la llave foranea proveniente de la tabla materias.

TABLE materias

Corresponde a las materias de los programas de las carreras, que son un tipo de actividad.


Permitenulo

Descripción

1 idmateria varchar 20 NULL No Es el código de la materia

2 nmateria varchar 100 NULL YES Nombre de la materia

TABLE semestres

Almacena información relacionada con los periodos semestrales.


Permitenulo

Descripción

1 idsemestre varchar 20 NULL No Identificador de la tabla semestres

2 nsemestre varchar 120 NULL YES Descripción del semestre

3 activo bit NULL 0 YES Indica si el registro del semestre corresponde a un semestre sobre el cual sepueden realizar procesos.

4 actual bit NULL 0 YES Indica si el registro del semestre es el que está en curso.

5 fechaini smalldatetime NULL NULL YES Corresponde a la fecha de comienzo del semestre.




6 fechafin smalldatetime NULL NULL YES Corresponde a la fecha de finalización del semestre.

TABLE actividades

Corresponden a las actividades que pueden ser programadas en los salones, auditorios, salas.


Permitenulo

Descripción

1 idactividad int NULL NULL No Corresponde al identificador de la actividad a programar

2 nactividad varchar 100 NULL YES Es la descripción (nombre) de la actividad.

3 idtipo char 20 NULL YES Es el tipo de actividad, es llave foranea proveniente de la tabla"Tipos_actividades"

4 idsemestre varchar 20 NULL YES Corresponde al semestre en el cual se programa la actividad (por ejemplo lasmaterias). Las actividades que se programan todos los semestres tendran enNULL este campo.

5 idpersona varchar 20 NULL YES Es la persona responsable de la actividad. Para las materias será el profesor, asíse tiene la programación semestral de las materias.

6 grupo varchar 50 ('01') No Es el grupo correspondiente a la actividad. Generalmente materias.

7 idmateria varchar 20 NULL YES Es la llave foranea proveniente de la tabla materias.

TABLE salones

Almacena información asociada a los salones, auditorios, salas y oficinas de la Facultad.


Permitenulo

Descripción




1 idsalon varchar 20 NULL No Es la llave primaria de la tabla salones y corresponde a la abreviación del salòncorrespondiente.

2 nsalon varchar 80 NULL YES Es la descripciòn detallada del salòn correspondiente al registro.

3 caracteristicas text 2,15E+09 NULL YES Descripciòn general de las caracteristicas del salòn.

4 capacidad float NULL NULL YES Es la capacidad en nùmero de personas.

5 iddependencia varchar 20 NULL YES Es la llave foranea que viene de la tabla dependencias e indica a quedependencia pertenece la administración del salón.

6 edificio varchar 20 NULL YES Es el edificio al cual pertenece el salón.

7 piso varchar 1 NULL YES Piso de ubicación dentro del edificio.

8 tipo varchar 20 NULL YES Indica si es [Salon],[Sala],[Auditorio],[Oficina].

9 tmod smalldatetime NULL (getdate()) YES

10 orden_llenado int NULL NULL YES Se aplica unicamente a las salas e indica el orden en el cual se deben buscarcupos para turnos de usuarios.

TABLE programaciones

almacena la programación total de los salones, indicando las actividades y los horarios.


Permitenulo

Descripción

1 idprogramacion int NULL NULL No Es la columna que identifica el registro, es un autonumérico

2 idprogsemestre varchar 50 NULL YES ???

3 fecha smalldatetime NULL NULL YES Indica la fecha de la programación.




4 idsalon varchar 20 NULL YES Indica el salon, auditorio o sala que se está programando.

5 hi int NULL NULL YES Es la hora de inicio de la programación.

6 hf int NULL NULL YES Es la hora de finalización de la programación.

7 idactividad int NULL NULL YES Es la actividad que se programa y es una llave foranea que viene de la tablaactividades.

Ilustración 13 Diccionario de datosFUENTE: PALACIOS VILLAMIL, Álvaro Enrique. Definición de datos para el sistema de control de salones. Sistema deInformación, Unidad de Informática y Comunicaciones, 2005




5.4.7. Generación de especificaciones de construcción

Las especificaciones de construcción del Sistema de Información lassuministra la Coordinación de la UIFCE, sin embargo, éstas carecen dedocumentación y no existen normas o políticas para el desarrollo deSistemas de Información que hubiesen sido aplicados desde el desarrolloinicial del Websiui.

5.4.8. Diseño de la migración y carga inicial de datos

El nuevo módulo podrá funcionar con los datos de cada uno de losestudiantes que ya se encuentran en las bases de datos, no obstante, serealizará una carga de datos semestralmente correspondiente a losestudiantes nuevos que ingresen a la Facultad. Igualmente, se realizarácon los docentes contemplando la carga inicial de sus datos debido a queanteriormente el Websiui no contaba con esta información.

5.4.9. Especificación técnica del plan de pruebas

Las pruebas las realiza el Analista de Sistemas de Informaciónparalelamente a la realización del módulo, así como en el momento definalizado el desarrollo desde la estación de prueba. Además, al serentregado en nuevo modulo la Coordinación de la UIFCE también realizalas pruebas pertinentes de consistencia y funcionamiento. Las pruebas nose documentan y carecen del seguimiento de unos procedimientos.

5.4.10. Establecimiento de requisitos de implantación.

Los requisitos en cuanto a hardware y software se encuentran enumeradosanteriormente cuando éstos se especificaron, sin embargo, es de tener encuenta que el Sistema de Información ya se encuentra en funcionamiento,es decir, ya se encuentra instalado y este proyecto corresponde a la adiciónde un nuevo módulo para mejorar la cobertura de éste.

5.5. CONSTRUCCIÓN DEL SISTEMA DE INFORMACIÓN

5.5.1. Preparación del entorno de generación y construcción.

Este entorno ya se encuentra determinado por el Sistema de InformaciónWebsiui que se encuentra actualmente en funcionamiento. Por lo tanto, elnuevo módulo obedecerá a los lineamientos y estándares de dicho sistema.

5.5.2. Generación del código de los componentes y procedimientos

La programación para crear la base de datos para el nuevo módulo de




Administración de salones se muestra a continuación:

DATA DEFINITION LANGUAGE

CREACIÓN DE TABLASCREATE TABLE [dbo].[Personas] ( [idpersona] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL , [nombres] [varchar] (100) COLLATE Modern_Spanish_CI_AS NULL , [apellidos] [varchar] (100) COLLATE Modern_Spanish_CI_AS NULL , [fecha_nacimiento] [smalldatetime] NULL , [direccion] [varchar] (100) COLLATE Modern_Spanish_CI_AS NULL , [telefono] [varchar] (60) COLLATE Modern_Spanish_CI_AS NULL , [email] [varchar] (60) COLLATE Modern_Spanish_CI_AS NULL , [edificio] [varchar] (3) COLLATE Modern_Spanish_CI_AS NULL , [piso] [varchar] (1) COLLATE Modern_Spanish_CI_AS NULL , [oficina] [varchar] (60) COLLATE Modern_Spanish_CI_AS NULL , [extension] [varchar] (5) COLLATE Modern_Spanish_CI_AS NULL , [t_estudiante] [bit] NULL , [t_docente] [bit] NULL , [t_administrativo] [bit] NULL , [t_unidad] [bit] NULL) ON [PRIMARY]GO

CREATE TABLE [dbo].[actividades] ( [idactividad] [int] IDENTITY (1, 1) NOT NULL , [nactividad] [varchar] (100) COLLATE Modern_Spanish_CI_AS NULL , [idtipo] [char] (20) COLLATE Modern_Spanish_CI_AS NULL , [idsemestre] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL , [idpersona] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL , [grupo] [varchar] (50) COLLATE Modern_Spanish_CI_AS NOT NULL , [idmateria] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL) ON [PRIMARY]GO

CREATE TABLE [dbo].[materias] ( [idmateria] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL , [nmateria] [varchar] (100) COLLATE Modern_Spanish_CI_AS NULL) ON [PRIMARY]GO

CREATE TABLE [dbo].[programaciones] ( [idprogramacion] [int] IDENTITY (1, 1) NOT NULL , [idprogsemestre] [varchar] (50) COLLATE Modern_Spanish_CI_AS NULL , [fecha] [smalldatetime] NULL , [idsalon] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL ,




[hi] [int] NULL , [hf] [int] NULL , [idactividad] [int] NULL) ON [PRIMARY]GO

CREATE TABLE [dbo].[salones] ( [idsalon] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL , [nsalon] [varchar] (80) COLLATE Modern_Spanish_CI_AS NULL , [caracteristicas] [text] COLLATE Modern_Spanish_CI_AS NULL , [capacidad] [float] NULL , [iddependencia] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL , [edificio] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL , [piso] [varchar] (1) COLLATE Modern_Spanish_CI_AS NULL , [tipo] [varchar] (20) COLLATE Modern_Spanish_CI_AS NULL , [tmod] [smalldatetime] NULL , [orden_llenado] [int] NULL) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]GO

CREATE TABLE [dbo].[semestres] ( [idsemestre] [varchar] (20) COLLATE Modern_Spanish_CI_AS NOT NULL , [nsemestre] [varchar] (120) COLLATE Modern_Spanish_CI_AS NULL , [activo] [bit] NULL , [actual] [bit] NULL , [fechaini] [smalldatetime] NULL , [fechafin] [smalldatetime] NULL) ON [PRIMARY]GO

CREATE TABLE [dbo].[tipos_actividades] ( [idtipo] [char] (20) COLLATE Modern_Spanish_CI_AS NOT NULL , [ntipo] [char] (240) COLLATE Modern_Spanish_CI_AS NULL , [color] [nvarchar] (50) COLLATE Modern_Spanish_CI_AS NULL) ON [PRIMARY]GO

ALTER TABLE [dbo].[Personas] WITH NOCHECK ADD CONSTRAINT [PK_directorio] PRIMARY KEY CLUSTERED ( [idpersona] ) ON [PRIMARY]GO

ALTER TABLE [dbo].[actividades] WITH NOCHECK ADD CONSTRAINT [PK_actividades] PRIMARY KEY CLUSTERED




( [idactividad] ) ON [PRIMARY]GO

ALTER TABLE [dbo].[materias] WITH NOCHECK ADD CONSTRAINT [PK_materias] PRIMARY KEY CLUSTERED ( [idmateria] ) ON [PRIMARY]GO

ALTER TABLE [dbo].[programaciones] WITH NOCHECK ADD CONSTRAINT [PK_programaciones] PRIMARY KEY CLUSTERED ( [idprogramacion] ) ON [PRIMARY]GO

ALTER TABLE [dbo].[salones] WITH NOCHECK ADD CONSTRAINT [PK_salones] PRIMARY KEY CLUSTERED ( [idsalon] ) ON [PRIMARY]GO

ALTER TABLE [dbo].[semestres] WITH NOCHECK ADD CONSTRAINT [PK_semestres] PRIMARY KEY CLUSTERED ( [idsemestre] ) ON [PRIMARY]GO

ALTER TABLE [dbo].[tipos_actividades] WITH NOCHECK ADD CONSTRAINT [PK_tipos_actividades] PRIMARY KEY CLUSTERED ( [idtipo] ) ON [PRIMARY]GO

ALTER TABLE [dbo].[actividades] ADD CONSTRAINT [DF_actividades_grupo] DEFAULT ('01') FOR [grupo]GO

ALTER TABLE [dbo].[salones] ADD CONSTRAINT [DF_salones_tmod] DEFAULT (getdate()) FOR [tmod]




GO

ALTER TABLE [dbo].[semestres] ADD CONSTRAINT [DF_semestres_activo] DEFAULT (0) FOR [activo], CONSTRAINT [DF_semestres_actual] DEFAULT (0) FOR [actual]GO

ALTER TABLE [dbo].[Personas] ADD CONSTRAINT [FK_Personas_telefonos] FOREIGN KEY ( [extension] ) REFERENCES [dbo].[telefonos] ( [extension] )GO

ALTER TABLE [dbo].[actividades] ADD CONSTRAINT [FK_actividades_materias] FOREIGN KEY ( [idmateria] ) REFERENCES [dbo].[materias] ( [idmateria] ) ON UPDATE CASCADE , CONSTRAINT [FK_actividades_Personas] FOREIGN KEY ( [idpersona] ) REFERENCES [dbo].[Personas] ( [idpersona] ) ON UPDATE CASCADE , CONSTRAINT [FK_actividades_semestres] FOREIGN KEY ( [idsemestre] ) REFERENCES [dbo].[semestres] ( [idsemestre] ) ON UPDATE CASCADE , CONSTRAINT [FK_actividades_tipos_actividades] FOREIGN KEY ( [idtipo] ) REFERENCES [dbo].[tipos_actividades] ( [idtipo] ) ON UPDATE CASCADEGO

ALTER TABLE [dbo].[programaciones] ADD CONSTRAINT [FK_programaciones_actividades] FOREIGN KEY (




[idactividad] ) REFERENCES [dbo].[actividades] ( [idactividad] ) ON UPDATE CASCADE , CONSTRAINT [FK_programaciones_salones] FOREIGN KEY ( [idsalon] ) REFERENCES [dbo].[salones] ( [idsalon] ) ON UPDATE CASCADEGO

ALTER TABLE [dbo].[salones] ADD CONSTRAINT [FK_salones_dependencias] FOREIGN KEY ( [iddependencia] ) REFERENCES [dbo].[dependencias] ( [iddependencia] ) ON UPDATE CASCADE , CONSTRAINT [FK_salones_edificios] FOREIGN KEY ( [edificio] ) REFERENCES [dbo].[edificios] ( [idedificio] ) ON UPDATE CASCADEGO

5.5.3. Ejecución de las pruebas unitarias

Durante el desarrollo del módulo para el Websiui se realizaron pruebas enla estación que sirve para dichos propósitos. Sin embargo, cuando éste seadiciona al sistema para colocarlo en funcionamiento, la mayoría de laspruebas que se llevan a cabo, se realizan en el servidor por el Analista deSistemas de Información de la UIFCE.

5.5.4. Ejecución de las pruebas del sistema.

Este tipo de pruebas las realiza la Coordinación de la UIFCE pero éstas nose documentan no existen procedimientos para llevarlas a cabo. Asimismo,luego de evaluar los resultados y encontrar fallas o errores, se le avisa alAnalista de Sistemas de Información, quien, a su vez, hace las respectivascorrecciones de manera simultánea, pero igualmente sin documentarlas.

5.5.5. Evaluación de manuales de usuario.

El Analista de Sistemas de Información es el encargado de realizar losmanuales técnicos y de usuarios del Websiui, sin embargo, éstos carecen




de revisión y evaluación.

5.5.6. Definición de la formación de los usuarios finales.

La capacitación para los integrantes de la UIFCE, tanto Coordinación comomonitores, se realiza de manera directa por parte del Analista de Sistemasde Información, quien desarrolló el módulo. Esta formación se lleva a caboen las instalaciones de la UIFCE dentro de los horarios y fechasestablecidas.Los estudiantes en general, quienes pueden consultar la programación desus clases en sus respectivos salones, recibirán formación a partir deavisos gráficos en las carteleras de la UIFCE, de tal forma que sean de sumayor entendimiento. Además, tendrán la oportunidad de preguntarcualquier inquietud a los monitores.La capacitación de los docentes de la Facultad se llevará a cabo por mediode folletos ilustrativos, donde se muestre las ventajas y modo de uso tantodel Sistema de Información como del módulo de Administración de Salones.

5.5.7. Construcción de los componentes y procedimientos de migración y cargainicial de datos.

Como ya se anotó la carga inicial de datos se realizará semestralmente, lacual corresponde a la información de estudiantes y docentes nuevos. Estalista es facilitada por el DNIC.En caso de la existencia de algún problema en los datos de estas personas,se tratará de manera individual y con el Analista de Sistemas deInformación.

5.6. IMPLANTACIÓN Y ACEPTACIÓN DEL SISTEMA

5.6.1. Establecimiento del plan de implantación

Luego de la terminación de todo el módulo y la aceptación por parte de laCoordinación, el Analista de Sistemas de Información llevará a cabo suimplantación para que aparezca en el Websiui y pueda ser visualizado porlos usuarios finales.

5.6.2. Formación necesaria para la implantación

Debido a que solamente es el Analista de Sistemas de Información quienrealiza la implantación del módulo de Administración de Salones, se leconsidera una persona idónea y apta para realizarlo ya que cuenta con losconocimientos previos en el Websiui, acorde con su cargo.Las capacitaciones al personal de la UIFCE tendrán prioridad porque seránquienes sirvan de soporte para la formación de los estudiantes y docentes,




cuya formación se realizará paralelamente a la implantación del módulo.

5.6.3. Incorporación del sistema al entorno.

El Sistema de Información Websiui ya se encuentra instalado y enoperación satisfactoriamente, por lo tanto, se procederá a la instalación delmódulo sobre toda la infraestructura que soporta al sistema.

5.6.4. Carga de datos al entorno de operación

Los datos correspondientes a estudiantes antiguos ya se encuentran en elSistema de Información, se procederá, cuando corresponda, a la carga dedatos de los estudiantes nuevos y de los docentes.

5.6.5. Establecimiento del acuerdo de nivel de servicio

No se establecen niveles de servicio, dado que el sistema de Informaciónha trabajado satisfactoriamente hasta la fecha.




6. CONCLUSIONES

1. Utilizamos la metodología Métrica versión 3 en la adecuación de unaplicativo para mejorar el servicio que la UIFCE presta a sus usuarios.

2. Se analizaron los sistemas de información existentes en la UIFCE y se llegoa la conclusión de que no existe un manual o guía de cómo se realizaron laslabores en los diferentes departamentos que la componen.

3. Se encontraron deficiencias en el manejo de la información de la UIFCEpues no se tiene la metodología para la recolección de la información.

4. Se logro la aplicación a la UIFCE de la metodología Métrica versión 3, paracrear un manual que sirva a la generación de Sistemas de Informaciónpropios, el cual se puede y debe tener en cuenta para la documentación decualquier proyecto en la Unidad.




7. BIBLIOGRAFIA

9.1. Ministerio de Administraciones Públicas de España(http://www.csi.map.es/csi/metrica3/). Métrica versión 3.0

9.2. PALACIOS VILLAMIL, Álvaro Enrique. Casos de Uso Detallados para elmodulo de administración de salones. Sistema de Información, Unidad deInformática y Comunicaciones, 2005.

9.3. PALACIOS VILLAMIL, Álvaro Enrique. Definición de datos para el sistemade control de salones. Sistema de Información, Unidad de Informática yComunicaciones, 2005

9.4. PALACIOS VILLAMIL, Álvaro Enrique. Diagrama de clases para el sistemade control de salones. Sistema de Información, Unidad de Informática yComunicaciones, 2004

http://www.csi.map.es/csi/metrica3/

metodologÍa para la implementaciÓn de … · auxiliares de investigación: adriana lucia...

Documents