proyecto suriqui origen

UNIVERSIDAD SALESIANA DE BOLIVIA INGENIERIA DE SISTEMAS

TRABAJO DIRIGIDO

PARA OBTENER EL GRADO ACADMICO DE LICENCIATURA EN INGENIERIA DE SISTEMAS

SISTEMA DE INFORMACIN ACADMICA CASO: UNIDAD EDUCATIVA CENTRAL ISLA SURIQUI

Postulante: Juan Carlos Quispe Zabaleta Docente Gua: Ing. Simn Onofre Lpez

LA PAZ - BOLIVIA 2014

DEDICATORIA A Dios por darme la vida.

Todo esfuerzo en un xito A mis papas Prof. Gervacio Quispe y Sra. Margarita Zabaleta por

que los amo y admiro su ejemplo de paciencia, bondad y sabidura.

Por constante apoyo y paciencia, A mis hermanos: Ing. Vctor Hugo, Juan ngel, Shilma, por

apoyarme y estar a mi lado en todo momento.

Mi gran familia!

AGRADECIMIENTOS El xito depende de la cantidad de esfuerzo que se pone en ello

A Dios por guiar mis pasos y acompaarme en mis fracasos. A la U.S.B. por haberme acogido para formarme profesionalmente.

Al Ing. Simn Onofre Lpez una gran persona, un profundo agradecimiento por su paciencia,

colaboracin y acertados consejos. Al Ing(a). Erlinda Gutirrez Poma por su ayuda y apoyo.

1

NDICE CAPTULO I: GENERALIDADES

1.1 INTRODUCCIN _________________________________________________ 1 1.2 ANTECEDENTES _________________________________________________ 3

1.2.1 ANTECEDENTE INSTITUCIONAL ________________________________ 3 1.2.2 TRABAJOS AFINES ___________________________________________ 5

1.3 PLANTEAMIENTO DE PROBLEMA __________________________________ 7 1.3.1 DESCRIPCIN DEL PROBLEMA _________________________________ 7 1.3.2 PROBLEMA PRNCIPAL ________________________________________ 9 1.3.3 PROBLEMAS ESPECFICOS ____________________________________ 9

1.4 PLANTEAMIENTO DE OBJETIVOS _________________________________ 10 1.4.1 OBJETIVO PRNCIPAL ________________________________________ 10 1.4.2 OBJETIVOS ESPECFICOS ____________________________________ 10

1.5 JUSTIFICACIN _________________________________________________ 10 1.5.1 JUSTIFICACIN TCNICA _____________________________________ 10 1.5.2 JUSTIFICACIN ECONMICA __________________________________ 11 1.5.3 JUSTIFICACIN SOCIAL ______________________________________ 11

1.6 ALCANCES Y LIMITES ___________________________________________ 12 1.6.1 ALCANCES _________________________________________________ 12 1.6.2 LMITES ____________________________________________________ 12

1.7 APORTES ______________________________________________________ 13 1.8 METODOLOGAS Y TCNICAS ____________________________________ 13

1.8.1 METODOLOGAS ____________________________________________ 13 1.8.1.1 MTODO XP (PROGRAMACIN EXTREMA) ___________________ 13 1.8.1.2 CAJA BLANCA ___________________________________________ 13

1.8.2 MODELOS __________________________________________________ 14 1.8.2.1 COCOMO _______________________________________________ 14 1.8.2.2 UML (Unified Modeling Languaje) _____________________________ 14

1.8.3 TCNICAS __________________________________________________ 14 1.8.3.1 ENTREVISTAS ___________________________________________ 15 1.8.3.2 CUESTIONARIO __________________________________________ 15 1.8.3.3 OBSERVACIN DIRECTA __________________________________ 15

1.8.4TCNICAS DE SEGURIDAD ____________________________________ 15 1.8.4.1 MD5 ____________________________________________________ 15

1.8.5 NORMAS ___________________________________________________ 16 1.8.5.1 ISO 9126 ________________________________________________ 16

2

CAPTULO II: MARCO TERICO 2.1 INTRODUCCIN ________________________________________________ 17 2.2. SISTEMAS DE INFORMACIN ____________________________________ 17 2.3 MTODO RUP (Rational Unified Process) ___________________________ 17 2.4 UML (Unified Modeling Languaje) __________________________________ 20

2.4.1 DIAGRAMA DE CASOS DE USO ________________________________ 21 2.4.2 DIAGRAMA DE CLASES _______________________________________ 22 2.4.3 DIAGRAMA DE DESPLIEGUE __________________________________ 23 2.4.4 DIAGRAMA DE COMPONENTES ________________________________ 24 2.4.5 DIAGRAMA DE PAQUETES ____________________________________ 25 2.4.6 DIAGRAMA DE SECUENCIA ___________________________________ 26 2.4.7 DIAGRAMA DE FLUJO Y ACTIVIDADES __________________________ 27

2.5 MTODO DE PRUEBA DEL SISTEMA _______________________________ 28 2.5.1 PRUEBA DE CAJA BLANCA ____________________________________ 28

2.6 NORMA ISO/IEC 9126 ___________________________________________ 29 2.6.1 COCOMO ___________________________________________________ 32

2.6.1.1 MODELO ANTICIPADO ____________________________________ 32 2.7. ARQUITECTURA CLIENTE SERVIDOR _____________________________ 36

2.7.1 CLIENTE ___________________________________________________ 37 2.7.2 SERVIDOR _________________________________________________ 37 2.7.3 CARACTERSTICAS DE LA ARQUITECTURA CLIENTE/SERVIDOR ___ 38

CAPTULO III: ESTUDIO FACTIBILIDAD 3.1 INTRODUCCIN ________________________________________________ 40 3.2 ESTUDIO DE FACTIBILIDAD ______________________________________ 40 3.3 FACTIBILIDAD TCNICA _________________________________________ 40 3.4 FACTIBILIDAD OPERACIONAL ___________________________________ 41 3.5 FACTIBILIDAD ECONMICA ______________________________________ 41 3.6 ANALISIS DE COSTOS ___________________________________________ 41 3.7 COSTOS DEL DESARROLLO DEL SISTEMA UTILIZANDO PUNTOS DE ___ 45

3.7.1 DESCRIPCIN DE PROCESOS _________________________________ 45 3.7.2 CLASIFICACIN DE FUNCIONES _______________________________ 49 3.7.3 CLASIFICACIN DE FUNCIONES POR SU COMPLEJIDAD __________ 50

3.7.3.1 CLASIFICACIN DE FUNCIONES DE SALIDAS POR SU COMPLEJIDAD _________________________________________________ 51 3.7.3.2 CLASIFICACIN DE FUNCIONES DE ARCHIVOS POR SU COMPLEJIDAD _________________________________________________ 51

3

3.7.3.3 CLASIFICACIN DE FUNCIONES DE CONSULTA POR SU COMPLEJIDAD _________________________________________________ 52

3.7.4 CLCULO DE PUNTOS DE FUNCIN SIN AJUSTAR _______________ 52 3.7.5 CLCULO DEL FACTOR DE AJUSTE ____________________________ 53 3.7.6 CLCULO DEL TOTAL DE PUNTOS DE FUNCIN _________________ 54

3.8 APLICACIN DEL COCOMO ______________________________________ 54 3.8.1 ESTIMACIN DE COSTO TOTAL DEL PROYECTO MEDIANTE _______ 54

3.9 BENEFICIOS ___________________________________________________ 56 3.9.1 BENEFICIOS INTANGIBLES ___________________________________ 57

CAPTULO IV: INGENIERA DEL PROYECTO 4.1 INTRODUCCIN ________________________________________________ 58 4.2 FASE INICIO ___________________________________________________ 58 4.3 FASE ELABORACIN ____________________________________________ 58

4.3.1 INGENIERIA DE REQUERIMIENTOS ____________________________ 58 4.3.1.1 REQUERIMIENTOS FUNCIONALES _________________________ 58 4.3.1.2 REQUERIMIENTOS NO FUNCIONALES: ______________________ 59

4.4 ANLISIS DEL SISTEMA _________________________________________ 61 4.4.1 DIAGRAMA CASOS DE USO ___________________________________ 61

4.4.1.1 DOCUMENTO DE ESPECIFICACIN CASO DE USO GENERAL __ 61 4.4.2 DIAGRAMA DE CASO DE USO NIVEL EXPANDIDO_________________ 63

4.4.2.1 CASO DE USO NIVEL EXPANDIDO: INGRESAR AL SISTEMA _____ 63 4.4.2.2 CASO DE USO NIVEL EXPANDIDO: REALIZAR INSCRIPCIN ____ 64 4.4.2.3 CASO DE USO NIVEL EXPANDIDO: REGISTRAR DOCENTE _____ 66 4.4.2.4 CASO DE USO NIVEL EXPANDIDO: SEGUIMIENTO ACADMICO _ 67 4.4.2.5 CASO DE USO NIVEL EXPANDIDO: REGISTRO DE NOTAS ______ 68 4.4.2.6 CASO DE USO NIVEL EXPANDIDO: ASIGNACIN DE MATERIAS _ 70

4.5 DIAGRAMA DE SECUENCIA DEL SISTEMA __________________________ 71 4.5.1 DIAGRAMA DE SECUENCIA: MDULO DE INGRESAR AL SISTEMA __ 71 4.5.2 DIAGRAMA DE SECUENCIA: MDULO DE INSCRIPCIN ___________ 72 4.5.3 DIAGRAMA DE SECUENCIA: MDULO REGISTRO DE DOCENTE ____ 72 4.5.4 DIAGRAMA DE SECUENCIA: MDULO SEGUIMIENTO ACADMICO __ 73 4.5.5 DIAGRAMA DE SECUENCIA: MDULO REGISTRO DE NOTAS ______ 73 4.5.6 DIAGRAMA DE SECUENCIA: MDULO ASIGNACIN DE MATERIA ___ 74

4.6 DIAGRAMA DE ESTADO _________________________________________ 74 4.6.1 DIAGRAMA DE ESTADO: MDULO INGRESAR AL SISTEMA ________ 74 4.6.2 DIAGRAMA DE ESTADO: MDULO DE INSCRIPCIN ______________ 75 4.6.3 DIAGRAMA DE ESTADO: MDULO REGISTRO DE DOCENTE ______ 75 4.6.4 DIAGRAMA DE ESTADO: MDULO SEGUIMIENTO ACADMICO ____ 76 4.6.5 DIAGRAMA DE ESTADO: MDULO REGISTRO DE NOTAS _________ 76

4

4.6.6 DIAGRAMA DE ESTADO: MDULO ASIGNACIN DE MATERIAS ____ 77 4.7 DIAGRAMA DE CLASES: _________________________________________ 78

4.7.1 DISEO FISICO DE BASE DE DATOS ___________________________ 79 4.7.2 ARQUITECTURA DEL SISTEMA ________________________________ 79

4.8 FASE DE CONSTRUCCIN _______________________________________ 81 4.8.1 DISEO DE INTERFACES _____________________________________ 81 4.8.2 PGINA PRINCIPAL __________________________________________ 81 4.8.3 PANTALLA DE REGISTRO DE ESTUDIANTE ______________________ 82 4.8.4 PANTALLA DE REGISTRO DE ADMINISTRACIN __________________ 83 4.8.5 PANTALLA DE REGISTRO DE CALIFICACIONES __________________ 84

CAPTULO V: PRUEBAS Y CALIDAD DE SOFTWARE 5.1 INTRODUCCIN ________________________________________________ 85 5.2 PRUEBAS ______________________________________________________ 85

5.2.1 PRUEBA DE CAJA NEGRA_____________________________________ 85 5.2.2 PRUEBAS DE CAJA BLANCA___________________________________ 93

5.2.2.1 APLICACIN EN EL PROCESO DE REGISTRO DE ESTUDIANTE __ 94 5.2.2.2 APLICACIN EN EL PROCESO DE MOSTRAR ESTUDIANTE _____ 99 5.2.2.3 APLICACIN EN EL PROCESO DE ELIMINAR ESTUDIANTE ____ 102

5.2.3 FASE DE TRANSICIN ______________________________________ 106 5.2.3.1 ACTIVIDADES PARA LA IMPLEMENTACION DEL SISTEMA _____ 106

5.3 CALIDAD DEL SOFTWARE ______________________________________ 106 5.3.1 FACTORES DE CALIDAD ISO 9126 _____________________________ 106

5.4 FUNCIONALIDAD ______________________________________________ 107 5.5 CONFIABILIDAD _______________________________________________ 111 5.6 PORTABILIDAD ________________________________________________ 112 5.7 MANTENIBILIDAD ______________________________________________ 113

5.7.1 MANTENIMIENTO ADAPTIVO _________________________________ 113 5.7.2 MANTENIMIENTO PERFECTIVO _______________________________ 113

5.8 FACILIDAD DE USO ____________________________________________ 113 CAPTULO VI: CONCLUSIONES Y RECOMENDACIONES 6.1 CONCLUSIONES _______________________________________________ 115 6.2 RECOMENDACIONES ___________________________________________ 116

BIBLIOGRAFA ANEXOS: ANEXO A: CUESTIONARIO CALIDAD DE SOFTWARE ANEXO B: CUESTIONARIO CALIDAD DE HARDWARE

INDICE DE TABLAS

Tabla 1.1 Hardware Existente..11 Tabla 1.2 Software Existente...11 Tabla 2.1 Conductores de Costo.....34 Tabla 2.2 Factores de Escala...35 Tabla 3.1 Recursos de Desarrollo...40 Tabla 3.2 Recursos de Servidor...41 Tabla 3.3 Requerimientos de Equipos Hardware.....42 Tabla 3.4 Requerimientos de Equipos Software......42 Tabla 3.5 Costo de Accesorio HW......43 Tabla 3.6 Costo de Accesorio SW...43 Tabla 3.7 Descripcin Total de HW.....44 Tabla 3.8 Costo de Licencia.44 Tabla 3.9 Clasificacin de Funciones ...49 Tabla 3.10 Clasificacin de Funciones de Entradas por su Complejidad50 Tabla 3.11 Clasificacin de Funciones de Salidas por su Complejidad.......51 Tabla 3.12 Clasificacin de Funciones de Archivos por su Complejidad.51 Tabla 3.13 Clasificacin de Funciones de Consulta por su Complejidad52 Tabla 3.14 Puntos de Funcin..53 Tabla 3.15 Factor de Ajuste...53 Tabla 3.16 Modelo Intermedio...54 Tabla 3.17 Conductores de Coste....55 Tabla 5.1: Pruebas de caja negra-Portada Principal.86 Tabla 5.2: Pruebas de caja negra-Registro de Estudiante...88 Tabla 5.3 Pruebas de caja negra-Registro de Apoderado....89 Tabla 5.4 Pruebas de caja negra-Registro de Nivel..90 Tabla 5.5 Pruebas de caja negra-Registro de Docente....91 Tabla 5.6 Pruebas de caja negra-Registro de Notas.....92 Tabla 5.7 Entradas para el Clculo de Funcionalidad.108 Tabla 5.8 Calculo de Puntos de Funcin sin Ajustar..109

Tabla 5.9 Ajuste de Complejidad del Punto de Funcin.....110 Tabla 5.10 Valores de ajuste de Complejidad ..112 Tabla 5.11 Calculo de la Confiabilidad..106 Tabla 5.12 Resultados para el Clculo de Facilidad de Uso..114

INDICE DE FIGURAS

Figura 1.1 organigrama de la unidad Educativa Central Suriqui..5 Figura 1.2: Trabajo Afn 16 Figura 1.3: Trabajo Afn 26 Figura 1.4: Trabajo Afn 36 Figura 2.1 Mtodo RUP..18 Figura 2.2 Diagrama de Casos de Uso21 Figura 2.3 Diagrama de Clases.22 Figura 2.4 Diagrama de Despliegue.23 Figura 2.5 Diagrama de Componentes24 Figura 2.6 Diagrama de Paquetes25 Figura 2.7 Diagrama de Secuencia..26 Figura 2.8 Diagrama de Flujo de Actividades.27 Figura 2.9 Grafica de Arquitectura Cliente-Servidor.39 Figura 4.1: Diagrama de Caso Uso General...61 Figura 4.2: Diagrama de Caso Uso Nivel Expandido Ingresar al Sistema....63 Figura 4.3: Diagrama de Caso Uso Nivel Expandido Realizar Inscripcin...64 Figura 4.4: Diagrama de Caso Uso Nivel Expandido Registrar Docente..66 Figura 4.5: Diagrama de Caso Uso Nivel Expandido Seguimiento Acad..67 Figura 4.6: Diagrama de Caso Uso Nivel Expandido Registro de Notas...68 Figura 4.7: Diagrama de Caso Uso Nivel Expandido Asignacin de Mat..70 Figura 4.8: Diagrama de Secuencia Mdulo de Ingresar al Sistema...71 Figura 4.9: Diagrama de Secuencia Mdulo de Inscripcin..72 Figura 4.10: Diagrama de Secuencia Mdulo Registro de Docente72 Figura 4.11: Diagrama de Secuencia Mdulo Seguimiento Acadmico73 Figura 4.12: Diagrama de Secuencia Mdulo Registro de Notas73 Figura 4.13: Diagrama de Secuencia Mdulo Asignacin de Materias...74 Figura 4.14: Diagrama de Estado Mdulo Ingresar al Sistema.74 Figura 4.15: Diagrama de Estado Mdulo de Inscripcin..75 Figura 4.16: Diagrama de Estado Mdulo Registro de Docente...75

Figura 4.17: Diagrama de Estado Mdulo Seguimiento Acadmico.76 Figura 4.18: Diagrama de Estado Mdulo Registro de Notas76 Figura 4.19: Diagrama de Estado Mdulo Asignacin de Materias77 Figura 4.20: Diagrama de Clases Mdulo General78 Figura 4.21: Diseo Fsico de Base de Datos79 Figura 4.22: Diseo de arquitectura.80 Figura 4.23: Portada Principal...81 Figura 4.24: Registro de Estudiante.82 Figura 4.25: Registro de Apoderado.82 Figura 4.26: Registro de Nivel83 Figura 4.27: Registro de Administracin..83 Figura 4.28: Registro de Administracin (tablas)84 Figura 4.29: Registro de Calificaciones84 Figura 5.1: Portada Principal..86

CAPTULO I

GENERALIDADES

1

1.1 INTRODUCCIN La tecnologa de la informacin se ha convertido en una herramienta indispensable en el mbito de todo que hacer laboral, las organizaciones no son ajenas a este cambio y necesidad de informacin. Estamos viviendo en lo que muchos han llamado la ERA DE LA INFORMACIN, la rapidez de este cambio tecnolgico ha trado grandes cambios en los diferentes actividades, lo que ms se aprecia en el mundo de hoy son mquinas y la informacin que fluye a travs de las computadoras. Todo ste conocimiento tecnolgico permite a las organizaciones, brindar respuestas rpidas a los niveles de servicio y superior, mediante el empleo de herramientas que permitan el manejo de una informacin concreta, precisa y oportuna.

En la actualidad muchas instituciones pblicas y privadas estn dependiendo de los sistemas informticos para optimizar las actividades o procesos que manejan.

Todava algunas instituciones como la Unidad Educativa Central Isla Suriqui no cuenta con una herramienta para el rea acadmica para mejorar el rendimiento escolar.

Con los nuevos modelos de la educacin con la Ley de Avelino Siani y Elizardo Prez (070) es de Planificar los niveles de currculos. Los niveles del currculo van de arriba a abajo, o sea desde lo general hasta lo particular, como el Currculo Base del Sistema Educativo Plurinacional, planificacin Anual del Desarrollo Curricular, plan de Desarrollo Curricular de Aula.

Los dos ltimos niveles, la planificacin curricular Anual como el de Aula, obedecen a la elaboracin, ejecucin, y los objetivos del Proyecto Socio productivo (PSP), que da los lineamientos para la planificacin.

2

La planificacin curricular Anual y de Aula desarrollan y fortalecen las cualidades, capacidades y potencialidades del ser humano (estudiante).1 Estas dimensiones son:

Ser: La parte espiritual y de los valores humanos. Saber: Los saberes y conocimientos. Hacer: Las prcticas y/o actividades. Decidir: El poder de planificar, organizar y ejecutar.

Plan de Unidad Educativa (Proyecto Socio-productivo) La accin educativa en el modelo de educacin socio-comunitario productivo, se constituye en un proceso dinmico participativo y de consenso, orientado a desarrollar la formacin integral y holstica de las y los estudiantes.

Plan Anual de Desarrollo Curricular

En la planificacin anual de desarrollo curricular se organizan, disponen recursos y elementos curriculares, con el objetivo de desarrollar la formacin (integral holstico) de las y los estudiantes vinculado a las realidades de cada contexto sociocultural con la participacin de maestras, maestros y representantes de estudiantes.

Planificacin Bimestral

Es el nivel de planificacin curricular, entendida como la organizacin de los saberes y conocimientos para ser desarrollados en los cuatro bimestres, una vez realizada la planificacin anual en reunin de maestras y maestros de los cuatro campos y reas de acuerdo a los siguientes pasos:2

1.- Se consulto en la pgina de Ley 070 para mayor informacin consultar http://www.minedu.com 2.- Ley 070 de Avelino Siani consultado el 20 de enero de 2014. http://es.ley070.net.com

3

1. Se formula el objetivo de bimestre, derivado del objetivo de la planificacin anual asumiendo la temtica orientadora correspondiente.

2. Una vez formulado el objetivo de bimestre se organizan los contenidos programados en la Planificacin Anual integrando los campos de saberes y conocimientos en Educacin Primaria Comunitaria Vocacional y las reas de saberes y conocimientos en la Educacin Secundaria Comunitaria Productiva.

Con el presente Trabajo Dirigido se propone realizar un SISTEMA DE INFORMACIN ACADMICA PARA LA UNIDAD EDUCATIVA CENTRAL ISLA SURIQUI, que facilite el manejo de los procesos de inscripcin, registro de notas o calificaciones, elaboracin de listados de cada grado o curso, registro de docentes, seguimiento acadmico y asignacin de materias al docente.

1.2 ANTECEDENTES

1.2.1 ANTECEDENTE INSTITUCIONAL En el ao 1967 en la comunidad Isla Suriqui Provincia Los Andes de la Ciudad de La Paz, despus de realizar muchos trmites se consigui el tem, para la Escuela Seccional Suriqui que comenz con 4 en el Nivel Primario: inicial. Primero, segundo y tercero de primaria con un total de 21 estudiantes, dependiendo del Ncleo Escolar Corpa Chilaya (Soncachi), en ese entonces el primer docente de aula fue el Prof. Natalio Bautista de la Localidad de Tiquina.

El 29 de enero de 1973, Visit a esta Isla Suriqui el Presidente de Bolivia el Gral. Hugo Banzer Suarez, con el fin de asistir a la inauguracin de la rplica de balsa RA II y presenciar el II festival autctono y folklrico preparado por los comunarios de Isla Suriqui.

4

De ah en su discurso central ante la multitud de toda la gente de las diferentes comunidades, autoridades de Estado cre un nuevo ncleo denominando NUCLEO ESCOLAR PILOTO ISLA SURIQUI al mismo tiempo designando a un profesor presente en el acto, como flamante DIRECTOR del Ncleo, Profesor: Juan Huaapaco, as tambin declarando a las Escuelas Seccionales que han de funcionar el ncleo como a : Cuyampaya, Supicachi, Paco chachacoma, Taquiri, Kehuaya, Tirasca y Pariti, que con estos Escuelas Seccionales funcion durante varios aos.3

En la actualidad llamada Unidad Educativa Central Isla Suriqui dependiente de Cuarta Seccin Puerto Prez Provincia Los Andes, cuenta con los grados de nivel inicial y nivel primaria de primero hasta sexto grado, y tiene 94 estudiantes y 10 profesores/as, y un conserje, adems funciona con 3 Escuelas Seccionales: Cuyampaya, Supicachi y Paco Chachacoma.4

Objetivo Institucional La Unidad Educativa Central Isla Suriqui se constituye en una institucin acadmica de formacin educativa, capaz de desempear de manera eficiente en la construccin de la educacin hacia la niez y adolescencia.

MISIN Formacin de nias y nios exitosos, con valores ticos y morales que promuevan la solucin de problemas inherentes a su comunidad y propicie el desarrollo integral, la participacin protagnica, transformando su realidad social en consonancia con el principio de equidad, igualdad y justicia social que lo consoliden como ciudadanos aptos para la vida y comprometidos con su entorno social y nacin.

3.- Libro de: Quispe Salas, Gervacio: Suriqui Isla del Lago Titicaca. Imprenta Publiart La Paz Bolivia (2013) 4.- Fuente: Unidad Educativa Central Isla Suriqui (2013)

5

VISIN Mantenernos como una institucin educativa con mayor prestigio en la Cuarta Seccin Puerto Prez, ofreciendo un servicio y educacin de calidad a travs de la innovacin en el rea educativa, formando estudiantes de alto nivel competitivo para lograr la transformacin social.

A continuacin se muestra la figura 1.1 el organigrama de la Unidad Educativa Central Isla Suriqui.

Figura 1.1 organigrama de la unidad Educativa Central Suriqui

[Fuente: Unidad Educativa Central Isla Suriqui]

1.2.2 TRABAJOS AFINES Los trabajos afines acerca del tema de sistema de informacin acadmico son las siguientes:

DIRECTOR DE LA UNIDAD EDUCATIVA

DOCENTES DE LA UNIDAD EDUCATIVA

ESTUDIANTES DE LA UNIDAD EDUCATIVA

CONSEJO EDUCATIVO SOCIAL COMUNITARIO

CONSERJE DE LA UNIDAD EDUCATIVA

6

Figura 1.2: Trabajo Afn 1

Titulo: Sistema de Informacin Acadmica Bellas Artes Autor: Yolanda Nancy Nina Nina Ao: 2008 Universidad: Universidad Mayor de San Andrs Carrera: Informtica Descripcin: Tener un buen control y seguimiento del rea acadmica y que esta funcione de forma eficaz, confiable y oportuna para la institucin, automatizando los procesos seguimientos en la bsqueda de informacin.

[Fuente: Universidad Mayor de San Andrs]


Ttulo: Sistema de Informacin de Seguimiento de U.T.O. Autor: Jess Fernando Villarroel Mazuelo Ao: 2000 Universidad: Universidad Tcnica de Oruro Carrera: Ingeniera de Sistemas Descripcin: Un proceso ptimo de acuerdo a la realidad actual de U.T.O., para el seguimiento acadmico y el requerimiento bsico de la institucin.

[Fuente: Universidad Tcnica de Oruro]


Ttulo:Sistema de Informacin de Seguimiento Acadmico y Administrativo Colegio Nacional Mixto Antofagasta. Autor: Rosmery Cristina Barrios Gonzales Ao: 2003 Universidad: Universidad Mayor de San Andrs Carrera: Informtica Descripcin: Analizar, disear e implementar un Sistema de Informacin que brinde soporte a la Gestin Acadmica.

[Fuente: Universidad Mayor de San Andrs]

7

A diferencia de los anteriores proyectos el presente trabajo pretende realizar los controles en los servicios que brinda la institucin del sistema de informacin acadmica para la unidad educativa central isla suriqui.

El Trabajo Dirigido de Sistema de Informacin Acadmica para Unidad Educativa Central Isla Suriqui tendr un Sistema de un buen control en el rea acadmica y que sta funcione de forma eficiente, confiable y oportuna para la institucin y como tambin automatizando los procesos seguimientos en la bsqueda de la informacin.

1.3 PLANTEAMIENTO DE PROBLEMA

1.3.1 DESCRIPCIN DEL PROBLEMA En la actualidad la Unidad Educativa Central Isla Suriqui no cuenta con un sistema de informacin para los procesos en el rea acadmica, el trabajo para la Direccin de la Unidad Educativa se acumula y hasta resulta catico lo que conlleva a que las tareas no se realicen de manera ordenada y eficiente.

A continuacin se presenta los siguientes procesos realizados manualmente referentes al seguimiento acadmico:

Registro de inscripcin. Inscripcin de estudiantes nuevos, este proceso se realiza mediante la Direccin de la Unidad Educativa. La inscripcin de los estudiantes antiguos es directa, no es necesario reinscribir en la Direccin de la Unidad Educativa.

El registro de familiares o apoderados de los estudiantes tambin se registra con todos sus datos personales.

Registro estadstico de los estudiantes.

8

Registro de notas o calificaciones. La entrega de notas a la Direccin por los docentes de la Unidad Educativa es de forma escrita en boletn de notas. Registro de notas es de cada grado, con su nmero respectivo de estudiantes y docentes asignados a los mismos.

Lista de los estudiantes aprobados, reprobados, retirados, de cada grado.

Elaboracin de listados de cada nivel. La elaboracin de listado de nivel es dependiendo de los estudiantes para cada grado y si es mayor a 30 estudiantes se les designa el paralelo y su docente.

Registro de docentes. Contiene la informacin relacionado a los datos personales.

Seguimiento acadmico. Existe deficiencia en el seguimiento acadmico a los estudiantes por qu no se puede saber de qu forma oportuna cada curso en qu nivel esta y tampoco se sabe con exactitud cules son los estudiantes excelentes, regulares y psimos.

Asignacin de materias al docente. La asignacin de nivel depende de la especialidad del docente. Segn la especialidad de los docentes se les asigna el nivel, como tambin las materias educacin fsica, msica, tecnologa y conocimiento prctico y tica moral.

9

1.3.2 PROBLEMA PRNCIPAL El manejo de los procesos de inscripcin, registro de calificaciones, elaboracin de listados de cada grado, registro de docentes, seguimiento acadmico y asignacin de materias al docente de la Unidad Educativa Central Isla Suriqui se maneja de forma manual, lo que dificulta el acceso a la informacin de los procesos mencionados, para una toma de decisiones. Adems impide la elaboracin de reportes de manera oportuna.

1.3.3 PROBLEMAS ESPECFICOS El registro de inscripcin de los estudiantes nuevos, es deficiente

debido a que al momento de la misma existen largas filas lo que provoca malestar en padres de familia para poder inscribir a su hijo. El registro de notas o calificaciones de parte de los profesores, es deficiente al momento entregar calificaciones de los estudiantes e inoportuno para la tardanza de cuando se entrega el acta de notas.

Prdida de tiempo de los padres de familia al momento de consultar las calificaciones, ms aun cuando hay problemas con la prdida de nota de sus hijos.

Volmenes considerables de documentacin, al momento de la entrega de la documentacin de los estudiantes.

Deficiente y desorganizacin, en el seguimiento acadmico de los estudiantes.

10

1.4 PLANTEAMIENTO DE OBJETIVOS

1.4.1 OBJETIVO PRNCIPAL Desarrollar e implementar un sistema de informacin Acadmica para la Unidad Educativa Central Isla Suriqui que ayude a mejorar los procesos de inscripcin, registro de notas o calificaciones, elaboracin de informes de cada grado o curso, registro de docentes, seguimiento acadmico, elaboracin de horarios, designacin y asignacin de materias al docente, facilitando el acceso a la informacin de los procesos mencionados, para una toma de decisiones. Adems ayuda la elaboracin de reportes de manera oportuna.

1.4.2 OBJETIVOS ESPECFICOS Sistematizar el proceso agilizando la inscripcin de los estudiantes. Mejorar el registro de notas o calificaciones para que sea eficiente al momento de la entrega de las calificaciones. Facilitar al profesor al registro de notas de forma eficiente y as evitar entrega de notas a destiempo. Evitar la prdida de tiempo de los padres de familia al momento de consultar sus calificaciones de sus hijos. Optimizar el seguimiento acadmico de los estudiantes.

1.5 JUSTIFICACIN 1.5.1 JUSTIFICACIN TCNICA El presente Trabajo Dirigido se justifica tcnicamente, ya que la institucin Educativa cuenta con los medios necesarios de Hardware y Software necesario para el desarrollo e implementacin del sistema.

11

La institucin educativa cuenta con el siguiente equipo de software y hardware.

Tabla 1.1 Hardware existente COMPONENTES

Procesador Core 2 Duo de 2.8 GHz Memoria 2 GB RAM, DDR3 Disco Duro 500 GB IDE/SATA Placa Base Intel DP43TF Monitor LG 17 Combo Case Teclado, Mouse y Parlante Numero de PCs 2

[Fuente: Unidad Educativa Central Isla Suriqui]

Tabla 1.2 Software existente COMPONENTES

Sistema Operativo: Windows7 [Fuente: Unidad Educativa Central Isla Suriqui]

1.5.2 JUSTIFICACIN ECONMICA La Institucin Educativa cuenta con los equipos de Hardware y Software para el manejo del sistema. Econmicamente el sistema minimizara el costo asociado al tiempo de obtencin de informacin, alcanzando as los resultados eficientes con el menor esfuerzo del personal administrativo.

1.5.3 JUSTIFICACIN SOCIAL El desarrollo del presente trabajo dirigido beneficiara a la comunidad educativa, estudiantes docentes y padres de familia, haciendo ms fcil los procesos de informacin acadmica.

12

1.6 ALCANCES Y LIMITES

1.6.1 ALCANCES Con el presente Trabajo Dirigido se pretende implementar un Sistema de Informacin Acadmico para la Unidad Educativa Central Isla Suriqui, que ayude a administrar informacin acadmica relevante para la institucin, automatizando los siguientes mdulos: Mdulo de historial de estudiantes y docentes, que contiene la

informacin referente al seguimiento acadmico, para los docentes se tendr informacin necesaria para la Unidad Educativa. Realizar un mdulo de inscripcin de estudiantes a materias y grados, en el cual el estudiante podr escoger el paralelo que desea cursar en la presente gestin con su respectivo docente. Realizar mdulo de reportes, que ayuden a brindar informacin oportuna confiable y fidedigna relacionada al seguimiento acadmico. Mdulo de Control y Seguimiento de los estudiantes.

1.6.2 LMITES La limitancia del proyecto son las siguientes: El Sistema de Informacin Acadmica es solo para la Unidad Educativa.

Los padres de familia solo podrn obtener las calificaciones de sus hijos en la direccin.

Se limita a trabajar solo con el Sistema Operativo Windows.

13

1.7 APORTES APORTE DEL PROYECTO El aporte del presente proyecto es el Sistema de Informacin Acadmica para la Unidad Educativa Central Isla Suriqui como una herramienta para el uso de la institucin educativa, logrando sistematizar de forma eficiente la informacin de cada uno de los estudiantes y como tambin de los docentes.

APORTE ACADMICO Para el desarrollo del sistema se aplicar los conocimientos, destreza y habilidades adquiridas durante la carrera y a la vez se utilizar una serie de mtodos y tcnicas en el marco de diferentes parmetros y normas.

1.8 METODOLOGAS Y TCNICAS En el presente proyecto se emplearan para el desarrollo de las diferentes actividades las siguientes metodologas y tcnicas.

1.8.1 METODOLOGAS 1.8.1.1 MTODO XP (PROGRAMACIN EXTREMA)

El mtodo XP define un conjunto de prcticas ptimas para el desarrollo de aplicaciones en excelentes condiciones al colocar al cliente en el centro del proceso de desarrollo, manteniendo una cercana relacin con dicho cliente.

1.8.1.2 CAJA BLANCA De acuerdo con, la prueba de caja blanca denominada a veces prueba de caja de cristal es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba. Con este mtodo determina cuales son los casos de prueba a partir del cdigo fuente del software y se utilizan las especificaciones para determinar el resultado esperado del caso.5

14

1.8.2 MODELOS

1.8.2.1 COCOMO Calcula el esfuerzo del desarrollo de software en funcin de tamao del programa y de un conjunto de Conductores de Coste, que incluye la evaluacin subjetiva del producto de hardware, del personal y de los atributos del proyecto.

1.8.2.2 UML (Unified Modeling Languaje) UML proporciona un proceso de diseo de tal forma que los analistas, clientes y otras personas involucradas en el desarrollo del sistema lo comprendan y entiendan de manera fcil y sencilla.

En el UML se puede usar para modelar distintos tipos de sistema: sistemas de software, sistemas de hardware y organizaciones del mundo real. UML est formado por diversos elementos grficos los cuales se combinan para conformar diagramas con las debidas reglas para combinar estos elementos.

1.8.3 TCNICAS El anlisis puede ser un proceso largo y arduo para el que se requiere de habilidades psicolgicas. Los nuevos sistemas cambian el entorno y las relaciones entre las personas, as que es importante identificar a todas las personas implicadas y considerar sus necesidades, asegurando que entienden las implicaciones del nuevo sistema. Existen tcnicas para obtener los requisitos del estudiante como por ejemplos los que se utilizaran para el presente proyecto.6

5.- Libro de: [HERNANDEZ, 2001] HERNNDEZ, E., (2001): El Lenguaje Unificado de Modelado (UML) 6.- Libro de: [Fillottrani], Pablo Ramrez (2010), modelos de calidad de software

15

1.8.3.1 ENTREVISTAS La entrevista es el mtodo ms usual. Por lo general no se entrevista a todas las personas que se relacionan con el sistema, sino a una seleccin de personas que represente a todos los sectores crticos de la Unidad Educativa, con nfasis en los sectores ms afectados o que harn uso frecuente del nuevo sistema. Formulario, en el lugar de una entrevista, se debe llenar formularios

indicando los requerimientos. Prototipo, un prototipo es una pequea muestra, de funcionalidad

limitada, de cmo sera el producto final una vez terminado. Ayudan a conocer la opinin de los usuarios y rectificar algunos aspectos antes de llegar al producto terminado.

1.8.3.2 CUESTIONARIO Los cuestionarios son formularios que rellenan los encuestados solos. Los cuestionarios pueden entregarse en mano o enviarse por correo y recogerse posteriormente o devolverse en un sobre pre franqueado. Este mtodo puede adoptarse para toda la poblacin o por sectores escogidos.

1.8.3.3 OBSERVACIN DIRECTA Se la realizara en la institucin estando presente en todas las fases del proceso de seguimiento y control.7

1.8.4TCNICAS DE SEGURIDAD 1.8.4.1 MD5

Es un algoritmo de hash seguro, que se toma una cadena de entrada y produce un numero de 128 bits, el hash.8

7.- Libro de: [Fillottrani], Pablo Ramrez (2010), modelos de calidad de software 8.- Libro de: [PRESSMAN, 2001] PRESSMAN, R. S., (2001): Tcnicas de Seguridad MD5

16

La misma cadena siempre produce el mismo hash, pero teniendo en cuenta un hash, generalmente no es posible determinar la cadena original, tambin son tiles para proteger la contrasea y garanta de integridad.9

1.8.5 NORMAS

1.8.5.1 ISO 9126 ISO 9126 es un estndar internacional para la evaluacin del software. Esta supervisado por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los mismos conceptos. El estndar est dividido en cuatro partes los cuales dirigen, respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas internas y calidad en las mtricas de uso.

El modelo de calidad establecido en la primera parte del estndar. ISO 9126-1 clasifica la calidad de software en un conjunto estructurado de caractersticas y sub caractersticas de la siguiente forma: funcionalidad, usabilidad, eficiencia, mantenibilidad y probabilidad.10

9.- Libro de: [PRESSMAN, 2001] PRESSMAN, R. S., (2001): Tcnicas de Seguridad MD5 10.- Libro de: [NUEZ, 2005] NUEZ, P., (2005): Normas ISO 9126 http://www.iso.uned.es

CAPTULO II

MARCO TERICO

17

2.1 INTRODUCCIN En este captulo se realiza la descripcin del uso de metodologas, tcnicas y herramientas que se emplearan para el desarrollo del sistema propuesto.

2.2. SISTEMAS DE INFORMACIN Un sistema de informacin es un conjunto de elementos organizados para poder, almacenar, manipular, administrar, procesar, transmitir o recibir datos, para satisfacer la necesidad de informacin.

2.3 MTODO RUP (Rational Unified Process) RUP es uno de los procesos ms generales de los existentes actualmente, ya que en realidad est pensado para adaptarse a cualquier tipo de proyecto. El ciclo de vida de RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades.

1. Interaccin (puesta en marcha) Objetivo del proyecto. Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Se define el alcance del proyecto.

2. Elaboracin (definicin anlisis y diseo) Arquitectura de la aplicacin, Se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos. Construccin de una versin ejecutable de la arquitectura de la aplicacin.

3. Construccin (implementacin) Versin operativa inicial de la aplicacin, se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario. Complementar el esqueleto de la aplicacin con la funcionalidad.

18

4. Transicin (fin del proyecto y puesta en produccin) Liberacin de la versin de la aplicacin, se implementa el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requerimientos a ser analizados. Disponibilidad en la aplicacin para los usuarios finales. Se construye la versin final.

Figura 2.1 Mtodo RUP

Fuente: Universidad Tecnolgica de la Mixteca

En cada fase se ejecutaran una o varias iteraciones (da tamao variable segn el proyecto), y dentro de cada una de ellas se seguir el modelo cascada para flujos de trabajo que requieren las nuevas actividades anteriormente citadas.

Como tres caractersticas esenciales estn dirigidas por los Casos de Uso que orientan el proyecto a la importancia para el usuario y lo que este requiere, est centrado en la arquitectura que relaciona la toma de decisiones que cumplen sus objetivos de manera ms depurada.11

11.- Libro de: [JACOBSON, BOOCH, RUMBAUGH, 2000] JACOBSON, I., BOOCH, G., RUMBAUGH, J., (2000): El proceso unificado de desarrollo de software

19

Como filosofa RUP maneja seis principios clave:

Adaptacin del proceso El proceso deber adaptarse a las caractersticas propias de la institucin. El tamao del mismo, as como las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto.

Balancear prioridades Los requerimientos de los diversos usuarios pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse en balance que satisfaga los deseos de todos.

Colaboracin entre equipos El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.

Demostrar valor iterativamente Los proyectos se entregan, aunque sea de un modo interno, en etapas iterativas. En cada iteracin se analiza la opinin de los usuarios, la estabilidad y calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados.

Elevar el nivel de abstraccin Este principio dominante motiva el uso de los conceptos reutilizables tal como patrn del software, por ejemplo. Que se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con UML.

20

Enfocarse en la calidad El control de la calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin.

RUP Es un proceso muy general y muy grande, por lo que antes de usarlo habr que adaptarlo a las caractersticas de la institucin.12

2.4 UML (Unified Modeling Languaje) UML proporciona un proceso de diseo de tal forma que los analistas, clientes y otras personas involucradas en el desarrollo del sistema lo comprendan y entiendan de manera fcil y sencilla.

En el UML se puede usar para modelar distintos tipos de sistema: sistemas de software, sistemas de hardware y organizaciones del mundo real. UML est formado por diversos elementos grficos los cuales se combinan para conformar diagramas con las debidas reglas para combinar estos elementos. Los diagramas ms comunes y que se utilizan en el desarrollo del sistema del UML son: 13

2.3.1 Diagrama de Casos de Uso 2.3.2 Diagrama de Clases 2.3.3 Diagrama de Despliegue 2.3.4 Diagrama de Componentes 2.3.5 Diagrama de Paquetes 2.3.6 Diagrama de Secuencia 2.3.7 Diagrama de Comunicacin 2.3.8 Diagrama de Flujo y Actividades

12.- Libro de: [JACOBSON, BOOCH, RUMBAUGH, 2000] JACOBSON, I., BOOCH, G., RUMBAUGH, J., (2000): El proceso unificado de desarrollo de software 13.- Libro de: [HERNANDEZ, 2001] HERNNDEZ, E., (2001): El Lenguaje Unificado de Modelado (UML).

21

2.4.1 DIAGRAMA DE CASOS DE USO El Lenguaje de Modelado Unificado (UML), define una notacin grfica para representar casos de uso llamada modelo de casos de uso. UML no define estndares para que el formato escrito describa los casos de uso, y as mucha gente no entiende que esta notacin grfica define la naturaleza de un caso de uso; sin embargo una notacin grfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms detallados que los diagramas de casos de uso. La descripcin escrita del comportamiento del sistema al afrontar una

tarea de negocio o un requisito de negocio. La posicin o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organizacin, un conjunto de casos de usos coherentes y consistentes promueven una imagen fcil de comprender del comportamiento del sistema, un entendimiento comn entre el cliente/propietario/usuario y el equipo de desarrollo.14

Figura 2.2 Diagrama de Casos de Uso

[Fuente: (OEM Software)]

14.- Libro de: [HERNANDEZ, 2001] HERNNDEZ, E., (2001): El Lenguaje Unificado de Modelado (UML)

22

2.4.2 DIAGRAMA DE CLASES Es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atrorientados a objetos. Propiedad de objetos que tienen propiedades y/u operaciones que

contienen un contexto y un dominio, los primeros dos ejemplos son clases de datos y el tercero clase de lgica de negocio, dependiendo de quin disee el sistema se pueden unir los datos con las operaciones.

El diagrama de clases incluye mucha ms informacin como la relacin entre un objeto y otro, la herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz grfica. Presenta las clases del sistema con sus relaciones estructurales y de

herencia. Sera igual a BIG TIME RUSH (rushers)15

Figura 2.3 Diagrama de Clases



23

2.4.3 DIAGRAMA DE DESPLIEGUE

Es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

En el UML los componentes ya no estn dentro de nodos. En cambio, puede haber artefactos u otros nodos dentro de un nodo.

Este tipo de diagrama debemos tambin aadir que no van a existir actores para relacionarse con los nodos (no es un diagrama de casos de uso).16

Figura 2.4 Diagrama de Despliegue


16.- Libro de: [HERNANDEZ, 2001] HERNNDEZ, E., (2001): El Lenguaje Unificado de Modelado (UML).

24

2.4.4 DIAGRAMA DE COMPONENTES Un diagrama de componentes representa cmo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, bibliotecas compartidas, mdulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema. Debido a que los diagramas de componentes son ms parecidos a los diagramas de casos de usos, stos son utilizados para modelar la vista esttica y dinmica de un sistema. Muestra la organizacin y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema. En l se situarn libreras, tablas, archivos, ejecutables y documentos que formen parte del sistema. Uno de los usos principales es que puede servir para ver qu componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.17

Figura 2.5 Diagrama de Componentes



25

2.4.5 DIAGRAMA DE PAQUETES Un diagrama de paquetes muestra cmo un sistema est dividido en agrupaciones lgicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete est pensado como un directorio, los diagramas de paquetes suministran una descomposicin de la jerarqua lgica de un sistema.

Los Paquetes estn normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas lneas maestras sobre la mesa, los paquetes son buenos elementos de gestin. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.18

Figura 2.6 Diagrama de Paquetes



26

2.4.6 DIAGRAMA DE SECUENCIA Muestra la interaccin de un conjunto de objetos en una aplicacin a travs del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.

Tpicamente se examina la descripcin de un caso de uso para determinar qu objetos son necesarios para la implementacin del escenario. Si se dispone de la descripcin de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos.

Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.19

Figura 2.7 Diagrama de Secuencia



27

2.4.7 DIAGRAMA DE FLUJO Y ACTIVIDADES Es la representacin grfica del algoritmo o proceso. Se utiliza en disciplinas como programacin, economa, procesos industriales y psicologa cognitiva. Estos diagramas utilizan smbolos con significados definidos que representan los pasos del algoritmo, y representan el flujo de ejecucin mediante flechas que conectan los puntos de inicio y de fin de proceso. Las siguientes son acciones previas a la realizacin del diagrama de flujo: Identificar las ideas principales al ser incluidas en el diagrama de flujo. Deben estar presentes el autor o responsable del proceso, los autores o responsables del proceso anterior y posterior y de otros procesos interrelacionados, as como las terceras partes interesadas. Definir qu se espera obtener del diagrama de flujo. Los pasos a seguir para construir el diagrama de flujo son: Establecer el alcance del proceso a describir. De esta manera quedar fijado el comienzo y el final del diagrama. Frecuentemente el comienzo es la salida del proceso previo y el final la entrada al proceso siguiente. Identificar y listar las principales actividades/subprocesos que estn incluidos en el proceso a describir y su orden cronolgico.20

Figura 2.8 Diagrama de Flujo y Actividades



28

2.5 MTODO DE PRUEBA DEL SISTEMA Dentro del campo del estudio de la ingeniera del software, se sugieren diversas metodologas de prueba que pueden incorporarse al ciclo de vida de un proyecto de desarrollo computacional. De acuerdo con Pressman las pruebas funcionales pueden realizarse en base a dos enfoques principales.

2.5.1 PRUEBA DE CAJA BLANCA La prueba de caja blanca denominada a veces prueba de caja cristal es un mtodo de diseo de caos de prueba que usa la estructura de control del diseo procedimental para obtener los casos de prueba. Mediante este mtodo el ingeniero de software puede obtener casos de prueba que: Garanticen que se ejercita por lo menos una vez todos los caminos

independientes de cada mdulo. Ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa. Ejecuten todos los bucles en sus lmites y con sus lmites operacionales. Ejerciten las estructuras internas de datos para asegurar su validez.

Con este mtodo se determina cules son los casos de prueba a partir del cdigo fuente del software y se utilizan las especificaciones para determinar el resultado esperado del caso. Los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto, as como que la integridad de la informacin externa.

La prueba de caja blanca del software se basa en el minucioso examen de los detalles procedimentales.21

21.- Se consulto la pagina Caja Blanca, de Jacobsson., Editorial Pearson Education USA (2000) para mayor informacin consultar http://es.wikipedia.org/wiki/caja negra sistemas

29

Se comprueban los caminos lgicos del software proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o ciclos. Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado o mencionado.

2.6 NORMA ISO/IEC 9126 ISO 9126 es un estndar internacional para la evaluacin del software. El estndar ISO 9126 est conformado en cuatro partes los cuales dirigen, respectivamente, lo siguiente: modelo de calidad, mtricas externas, mtricas internas y calidad en las mtricas de uso.

El modelo de calidad establecido en la primera parte de estndar, ISO 91261, clasifica la calidad del software en un conjunto estructurado de caractersticas y sub-caractersticas de la siguiente manera:

a) FUNCIONABILIDAD, un conjunto de atributos que se relacionan con la existencia de un conjunto de funciones y sus propiedades especficas.

Las funciones son aquellas que satisfacen lo indicado o implica necesidades. Idoneidad Exactitud Interoperabilidad Seguridad Cumplimiento de normas

b) FIABILIDAD, Un conjunto de atributos relacionados con la capacidad del software de mantener su nivel de presentacin bajo condiciones establecidas durante un periodo de tiempo establecido.22 Madurez

22.- Se consulto la pagina ISO 9126, de Jacobsson., Editorial Pearson Education USA (2000) para mayor informacin consultar http://es.wikipedia.org/wiki/iso 9126

30

Recuperabilidad Tolerancia a fallos

c) USABILIDAD, Conjunto de atributos relacionados con el esfuerzo necesitado para el uso, y en la valoracin individual de tal uso, por un establecido o implicado conjunto de usuarios. Aprendizaje Comprensin Operatividad

d) EFICIENCIA, conjunto de atributos relacionados con la relacin entre el nivel de desempeo del software y la cantidad de recursos necesitados bajo condiciones establecidas. Comportamiento en el tiempo Comportamiento de recursos

e) MANTENIMIENTO, conjunto de atributos relacionados con el esfuerzo necesitado para modificar las especificaciones. Estabilidad Facilidad de anlisis Facilidad de cambios Facilidad de pruebas

f) MOVILIDAD, conjunto de atributos relacionados con la habilidad del software para ser transferido desde entorno a otro.23 Capacidad de instalacin Capacidad de re emplazamiento Adaptabilidad


31

Un producto software est definido en un sentido amplio como: los ejecutables, cdigo fuente, descripciones de arquitectura, y as como resultado, la nocin de usuario se ampla tanto a operadores como a programadores, los cuales son usuarios de componentes como son bibliotecas software.

El estndar provee un entorno para que las organizaciones definan un modelo de calidad para el producto software. Haciendo esto as, sin embargo, se lleva a cada organizacin la tarea de especificar precisamente su propio modelo. Esto podra ser hecho, por ejemplo, especificando los objetivos para las mtricas de calidad las cuales evalan el grado de presencia de los atributos de calidad.

Mtricas internas son aquellas que no dependen de la ejecucin del software (medidas estticas). Mtricas externas son aquellas aplicables al software en ejecucin. La calidad en las mtricas de uso est solo disponible cuando el producto final es usado en condiciones reales. Idealmente, la calidad interna no necesariamente implica calidad externa y esta a su vez la calidad en el uso.

Este estndar proviene desde el modelo establecido en 1977 por McCall y sus colegas, los cuales propusieron un modelo para especificar la calidad del software. El modelo de calidad McCall est organizado sobre tres tipos de caractersticas de calidad.24 Factores (especificar): Describen la visin externa del software, como es

visto por los usuarios.


32

Criterios (construir): Describen la visin interna del software, como es visto por el desarrollador. Mtricas (controlar): Se definen y sus usan para proveer una escala y mtodo para la medida.

ISO 9126 distingue entre fallo y no conformidad. Un fallo es el incumplimiento de los requisitos previos, mientras que la conformidad es el incumplimiento de los requisitos especificados.

Una distincin similar es la que se establece entre validacin y verificacin.

2.6.1 COCOMO COCOMO es un modelo que permite estimar el costo, esfuerzo y tiempo cuando se tiene una nueva actividad de desarrollo de software, es asociado a los ciclos de vida modernos, las ventajas que tiene COCOMO es de desarrollar una base de datos de costo y capacidad de soporte de herramientas y tcnicas para evaluar los efectos de la tecnologa de software sobre el costo y el tiempo en el ciclo de vida.25

2.6.1.1 MODELO ANTICIPADO Este modelo se usa en las etapas tempranas de un proyecto de software, cuando se conoce muy poco del tamao del producto que se va a desarrollar.

Este modelo podra emplearse tanto en productos desarrollados en sectores de Generadores de Aplicacin, Sistemas Integrados o Infraestructura.

25.- Libro de CALIDAD DE SOFTWARE, Juan Manuel Cueva Lovelle (2000), Grupo Gidis, de la Universidad Nacional de la Pampa.

33

El modelo anticipado se utiliza en las primeras etapas del desarrollo en las cuales se evalan las alternativas de hardware y software de un proyecto. En estas etapas se tiene poca informacin, lo que concuerda con el uso de Puntos Funcin, para estimar tamao y el uso de un nmero reducido de factores de costo. [Ana Moreno 2000]26

El modelo de Diseo anticipado ajusta el esfuerzo nominal usando siete factores de costo. La frmula para el clculo del esfuerzo es la siguiente:

PM estimado = PM nominal X EM Donde:

PM nominal = A X (KSLOC) B

B = 1.01 + 0.01 X PM Estimado: es el Esfuerzo Nominal ajustado por 7 factores, que reflejan otros aspectos propios del proyecto que afectan al esfuerzo necesario para la ejecucin del mismo.

1) Fiabilidad y complejidad (RCPX). 2) Reutilizacin requera (RUSE). 3) Dificultad de la plataforma (PDIF). 4) Capacidad del personal (PERS) 5) Experiencia del personal (PREX). 6) Facilidades (FCIL). 7) Calendario (SCED).

La tabla 2.1 muestra los valores estimados para cada uno de los factores de escala.

26.- Libro de COCOMO, de Ana Moreno (2000), Editorial Prentice

34

Tabla 2.1 Conductores de costo para diseo inicial estimados por Boehm Factores

de Escala

Extra

Bajo Muy

Bajo

Bajo

Nominal

Alto Muy

Alto

Extra

Alto RCPX 0.73 0.81 0.98 1.00 1.30 1.74 2.38 RUSE ----- ----- 0.95 1.00 1.07 1.15 1.24 PDIF ----- ----- 0.87 1.00 1.29 1.81 2.61 PERS 2.12 1.62 1.26 1.00 0.82 0.63 0.50 PREX 1.59 1.33 1.12 1.00 0.87 0.71 0.62 FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62 SCDE ----- 1.43 1.14 1.00 1.00 1.00 -----

[Fuente: Ana Moreno-Capuchin: Estimacin de proyectos Software]

KSLOC: Es el tamao del software a desarrollar expresado en miles de lneas de cdigo fuente.

A: es una constante que captura los efectos lineales sobre el esfuerzo de acuerdo a la variacin del tamao, (A=2.94).

B: Es el factor exponencial de escala, toma en cuenta las caractersticas relacionadas con las economas y des economas de escala producidas cuando un proyecto de software incrementa su tamao.

B = 0.91 + 0.01 * ( Factores de Escala) Emi: Corresponde a los factores de los costos que tiene un efecto multiplicativo sobre el esfuerzo, llamados Multiplicadores de Esfuerzo (Effort Multipliers). Cada factor se puede clasificar en seis niveles diferentes que expresan el impacto del multiplicador sobre el esfuerzo de desarrollo.

35

Esta escala vara desde el nivel Extra Bajo hasta el nivel Extra Alto. Cada nivel tiene el peso asociado.

El peso promedio o nominal es de 1.0. Si el factor provoca un efecto nocivo en el esfuerzo de un proyecto, el valor del multiplicador correspondiente ser mayor que 1.0 caso contrario el multiplicador ser inferior a 1.0. Los factores de escala son los siguientes: Precedentes (PREC). Flexibilidad en el desarrollo (FLEX) Arquitectura / Solucin de riesgos (RESL). Cohesin del Equipo (TEAM). Madurez de procesos (PMAT).

La tabla 2.2 muestra los valores estimados para cada uno de los factores de escala.

Tabla 2.2: Factores de Escala Estimados por Boehm Factores

de Escala

Muy

Bajo

Bajo

Nominal

Alto Muy

Alto

Extra

Alto PREC 6.20 4.96 3.72 2.48 1.24 0.00 FLEX 5.07 4.05 3.04 2.03 1.01 0.00 RESL 7.07 5.65 4.24 2.83 1.41 0.00 TEAM 5.48 4.38 3.29 2.19 1.10 0.00 PMAT 7.80 6.24 4.68 3.12 1.56 0.00

[Fuente: Ana Moreno-Capuchin; Estimacin del Proyecto de Software]

36

2.7. ARQUITECTURA CLIENTE SERVIDOR En el modelo cliente servidor, el cliente enva un mensaje solicitando un determinado servicio a un servidor (hace una peticin), y este enva uno o varios mensajes con la respuesta (provee el servicio) (Ver Figura 5.1). En un sistema distribuido cada mquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.

La idea es tratar a una computadora como un instrumento, que por s sola pueda realizar muchas tareas, pero con la consideracin de que realice aquellas que son ms adecuadas a sus caractersticas. Si esto se aplica tanto a clientes como servidores se entiende que la forma ms estndar de aplicacin y uso de sistemas Cliente/Servidor es mediante la explotacin de las PCs a travs de interfaces grficas de usuario; mientras que la administracin de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe.

Usualmente la mayora del trabajo pesado se hace en el proceso llamado servidor y el o los procesos cliente slo se ocupan de la interaccin con el usuario (aunque esto puede variar).27

La arquitectura cliente servidor tiene las siguientes ventajas: Centralizacin de los aspectos de seguridad y transaccionalidad, que serian responsabilidad del modelo. No replican de lgica del negocio en los clientes: esto permite que las modificaciones y mejoras sean automticamente aprovechadas por el conjunto de los usuarios, reduciendo los costes de mantenimiento.

27.- Se consulto la pagina CLIENTE-SERVIDOR, de Pressman Roger, Editorial Pearson Education USA (2000) para mayor informacin consultar http://es.wikipedia.org/wiki/cliente-servidor

37

Mayor sencillez de los clientes. 2.7.1 CLIENTE El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor, se le conoce con el trmino front-end.

El Cliente normalmente maneja todas las funciones relacionadas con la manipulacin y despliegue de datos, por lo que estn desarrollados sobre plataformas que permiten construir interfaces grficas de usuario (GUI), adems de acceder a los servicios distribuidos en cualquier parte de una red. Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos: Administrar la interfaz de usuario. Interactuar con el usuario. Procesar la lgica de la aplicacin y hacer validaciones locales. Generar requerimientos de bases de datos. Recibir resultados del servidor. Formatear resultados.

2.7.2 SERVIDOR Es el proceso encargado de atender a mltiples clientes que hacen peticiones de algn recurso administrado por l. Al proceso servidor se le conoce con el trmino back-end.

El servidor normalmente maneja todas las funciones relacionadas con la mayora de las reglas del negocio y los recursos de datos. Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos: 28


38

Aceptar los requerimientos de bases de datos que hacen los clientes. Procesar requerimientos de bases de datos. Formatear datos para trasmitirlos a los clientes. Procesar la lgica de la aplicacin y realizar validaciones a nivel de bases de datos.

2.7.3 CARACTERSTICAS DE LA ARQUITECTURA CLIENTE/SERVIDOR Las caractersticas bsicas de una arquitectura Cliente/Servidor son: Combinacin de un cliente que interacta con el usuario, y un servidor

que Interacta con los recursos compartidos. El proceso del cliente proporciona la interfaz entre el usuario y el resto del sistema. El proceso del servidor acta como un motor de software que maneja recursos compartidos tales como bases de datos, impresoras, mdems, etc. Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos de cmputo como velocidad del procesador, memoria, velocidad y capacidades del disco y input-output divises. Se establece una relacin entre procesos distintos, los cuales pueden ser ejecutados en la misma mquina o en mquinas diferentes distribuidas a lo largo de la red. Existe una clara distincin de funciones basada en el concepto de "servicio", que se establece entre clientes y servidores. La relacin establecida puede ser de muchos a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a recursos compartidos.29


39

Los clientes corresponden a procesos activos en cuanto a que son stos los que hacen peticiones de servicios a los servidores. Estos ltimos tienen un carcter pasivo ya que esperan las peticiones de los clientes. No existe otra relacin entre clientes y servidores que no sea la que se establece a travs del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la peticin y entrega de solicitudes de servicio. El ambiente es heterogneo. La plataforma de hardware y el sistema operativo del cliente y del servidor no son siempre la misma. Precisamente una de las principales ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas. El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier sistema Cliente/Servidor.30

Figura 2.9 Grfica de Arquitectura Cliente-Servidor

[Fuente: Arquitectura cliente-Servidor]


CAPTULO III

ESTUDIO FACTIBILIDAD

40

3.1 INTRODUCCIN En este captulo se describen todos los costos que conlleva realizar el proyecto mediante la estimacin de costos que se efectuar durante el tiempo de desarrollo del software del sistema haciendo uso del modelo de Cocomo para clculo del esfuerzo tiempo estimado y desarrollo de software utilizando punto de funcin.

3.2 ESTUDIO DE FACTIBILIDAD La informacin obtenida y recolectada para la realizacin de este captulo fue obtenida a travs de entrevistas realizadas al personal de la institucin Educativa.

3.3 FACTIBILIDAD TCNICA El Director de la Unidad Educativa, es el responsable de gestin y manejo de las tecnologas de la informacin, Equipos PC`s, servidores, software, licencias, etc.

En la tabla 3.1 se da a detallar los recursos de hardware y software, con los que debe contar la Unidad Educativa para poner en ejecucin el sistema.

Tabla 3.1: Recursos de Desarrollo Recursos de Desarrollo

Hardware Software Costo $us 3 Computadoras Sistema operativo 2100

1 Servidor (opcional) 25 Equipos de red Servidor Server 15

HP D1500 Manejador de Base de Datos (MySql) Herramientas de

Plataforma para la gestin de contenidos.

150

TOTAL 2290 $us [Fuente: Elaboracin Propia]

Para las maquinas cliente es necesario el equipo.

41

Tabla 3.2: Recursos de Servidor Hardware Observacin

Dual Core Duo Memoria RAM de 2Gb Disco Duro de 250Gb

(recomendable) (recomendable) (recomendable)

[Fuente: Elaboracin Propia]

3.4 FACTIBILIDAD OPERACIONAL El Sistema en la Unidad Educativa que se implementar, cumple con todos los requisitos para su usabilidad o funcionamiento, ya que es un software difundido y utilizado por que posee un interfaz accesible y amigable para cualquier usuario que tenga conocimientos bsicos de computacin.

As mismo la Unidad Educativa ya cuenta con personal capacitado para que pueda controlar y la vez usar el sistema a desarrollar. Por todo esto se encuentra al proyecto factible operativamente.

3.5 FACTIBILIDAD ECONMICA En esta parte se detalla el costo y la implementacin en la que se incurrir con el desarrollo del sistema como ser:

3.6 ANALISIS DE COSTOS Los equipos de computadoras con que cuenta actualmente en la institucin son las siguientes:

42

Requerimientos mnimos de Hardware

Tabla 3.3: Requerimiento de Equipos Hardware DISPOSITIVO CARACTERSTICAS Equipo tipo PC Core 2 Duo

Resolucin de Video (512 recomendado) Mouse ptico

Memoria Ram (2 GB recomendado) Espacio en Disco 256 Gb


Requerimientos mnimos de software

Tabla 3.4: Requerimiento de Equipos Software SOFTWARE CARACTERSTICA

Windows de 32 bits(Windows 7) Se ejecutara el sistema Visual Basic.Net


A continuacin se observara los costos mnimos de hardware y software para el Sistema.

Costo del hardware Para elaborar el costo del hardware se realizara una estimacin de costos para llegar a un precio que este en funcin a diferentes empresas y galeras que se encargan de la venta de equipos de hardware.

43

Descripcin de hardware

Tabla 3.5: Costo de los Accesorios Hardware Nombre del accesorio

Garanta Nombre de la galera

Observaciones Precio $us

Procesador Core2Duo 2.8

1 mes [email protected] Armado por partes 124

Tarjeta madre Intel DP35


Memoria Ram 2 Gb


Disco duro 160 1 mes [email protected] Armado por partes 40 Lector copiador

DVD 1 mes [email protected] Armado por partes 26

Tarjeta de video 512


Monitor LCD 17 pul 1 mes [email protected] Armado por partes 157 Case combo 1 mes [email protected] Armado por partes 48

TOTAL

$us 582

[Fuente: [email protected]]

Descripcin de hardware

Tabla 3.6: Costo de los Accesorios Software Nombre del accesorio

Garan-ta Nombre de la galera

Observaciones Precio $us

Procesador Core2Duo 2.8

30 das PCHardwareHouse Armado por partes 124

Tarjeta madre Intel DP35

30 das PCHardwareHouse Armado por partes 113

Memoria Ram 2 Gb 30 das PCHardwareHouse Armado por partes 20 Disco duro 160 30 das PCHardwareHouse Armado por partes 40

Lector copiador DVD 30 das PCHardwareHouse Armado por partes 26 Tarjeta de video 512 30 das PCHardwareHouse Armado por partes 45 Monitor LCD 17 pul 30 das PCHardwareHouse Armado por partes 155

Case combo 30 das PCHardwareHouse Armado por partes 48

TOTAL

$us 571

[Fuente: PCHardwareHouse]

44

A continuacin se mostrara en tablas los resultados de los precios totales

Descripcin total de hardware

Tabla 3.7: Descripcin Total HW Precio total Observaciones

$us. 582 Garanta de 1 mes todos los componentes $us. 571 Garanta de 1 mes todos los componentes


A continuacin se realiza operaciones para estimar un costo promedio 582 + 571 = $us. 1153

Este resultado se divide entre la cantidad de empresas 1153 / 2 = 576.5 = $us. 577

El costo promedio total de hardware es $us. 577.

Costo del software El costo de la licencia del sistema operativo se la observa en el siguiente cuadro.

Tabla 3.8: Costo de Licencia Descripcin Costo Licencia ($us)

Sistema Operativo Windows 7 200

visual basic.net 200

MySQL 250

Microsoft office 2003 406

TOTAL $us. 1056 [Fuente: Elaboracin Propia]

Costos de Software

45

3.7 COSTOS DEL DESARROLLO DEL SISTEMA UTILIZANDO PUNTOS DE FUNCIN. Los puntos de funcin miden la aplicacin desde una perspectiva del usuario, dejando de lado los detalles de codificacin. Para el clculo del tamao del sistema usamos Puntos de Funcin y a continuacin se muestran los detalles.

3.7.1 DESCRIPCIN DE PROCESOS

1) Pantalla de ingreso Ingresar Usuario Ingresar contrasea

2) Pantalla principal Inscripcin (Estudiantes, Docentes) Seguimiento Acadmico Control de Asistencia Asignacin de Materias Registro de notas

3) Inscripcin Usuario Contrasea (Consultas)

3.1) Inscripcin Registro de Estudiantes Registro Docentes Registro de Director Consultas Reportes

46

3.1.1 Registro de Estudiantes Ingresar RUDE Ingresar Grado Ingresar Materia Ingresar C.I. Ingresar Nombres Ingresar Apellidos Ingresar Fecha de Nacimiento Ingresar Tipo de Sangre Ingresar Direccin Ingresar Telfono de referencia.

3.1.2 Registro Docente Ingresar RDA Ingresar C.I. Ingresar Nombres Ingresar Apellidos Ingresar Fecha de Nacimiento Ingresar Tipo de Sangre Ingresar Direccin Ingresar Telfono de referencia.

4. Control y Seguimiento Acadmico Usuario Contrasea Consultas

4.1 Seguimiento Acadmico Registro de Estudiante Registro de Notas

47

Control de Asistencia Reportes

4.1.2 Registro de Estudiante Ingresar RUDE Ingresar Grado Ingresar Materia Ingresar C.I. Ingresar Nombres Ingresar Apellidos Ingresar Fecha de Nacimiento Ingresar Tipo de Sangre Ingresar Direccin Ingresar Telfono de referencia.

4.1.3 Registro de Notas Ingresar RUDE Ingresar Grado Ingresar Materia Ingresar Nombres Ingresar Apellidos

5.1.2 Registro de Estudiante Ingresar RUDE Ingresar Grado Ingresar Materia Ingresar C.I. Ingresar Nombres Ingresar Apellidos Ingresar Fecha de Nacimiento

48

Ingresar Tipo de Sangre Ingresar Direccin Ingresar Telfono de referencia.

6. Asignacin de Materias, Grados y Paralelos Usuario Contrasea Consultas

6.1 Materias, Grados y Paralelos Registro de Docente Consulta Reportes

6.1.1 Registro Docente Ingresar RDA Ingresar C.I. Ingresar Nombres Ingresar Apellidos Especialidad Ingresar Fecha de Nacimiento Ingresar Tipo de Sangre Ingresar Direccin Ingresar Telfono de referencia.

49

3.7.2 CLASIFICACIN DE FUNCIONES

Tabla 3.9: Clasificacin de Funciones


Caracterstica Funcin

Entrada Salida Archivos Consul- tas

Interfaces externas

Pantalla de ingreso X Pantalla Principal X

Realizar Inscripcin X Registro de Estudiante

X

Datos del Estudiante

X

Registro de Apoderados

Registrar Docente X Datos del Docente X

Asignacin de Nivel, Paralelo

X

Seguimiento Acadmico

X

Registro de Estudiante

X

Registro de Notas X Control de Asistencia

X

Registro de Notas X Registro de Estudiante

X

Asignar Materias X Registro de

Docente X

Asignar Nivel X Asignar Paralelo X

Control de Asistencia

X

Registro de Estudiante

X

Registro de Horario X Pantalla de ingreso X Pantalla Principal X

50

3.7.3 CLASIFICACIN DE FUNCIONES POR SU COMPLEJIDAD

Tabla 3.10: Clasificacin de Funciones de Entradas por su Complejidad


Caracterstica Complejidad

Funcin

Simple

Media

Compleja

Entradas

Pantalla de ingreso X Pantalla Principal X Realizar Inscripcin X Registro de Estudiante X Datos del Estudiante Registrar Docente X Datos del Docente X Asignacin de Nivel, Paralelo

X

Seguimiento Acadmico X Registro de Estudiante X Registro de Notas X Control de Asistencia X Registro de Notas X Registro de Estudiante X Asignar Materias X Registro de Docente X Asignar Nivel X Asignar Paralelo X Asignar rea X Registro de Estudiante X Registro de Apoderado X

TOTAL POR COMPLEJIDAD

1

21

O

51

3.7.3.1 CLASIFICACIN DE FUNCIONES DE SALIDAS POR SU COMPLEJIDAD

Tabla 3.11: Clasificacin de Funciones de Salidas por su Complejidad


Funcin

Simple

Media

Compleja

Salidas

Realizar Inscripcin X Registro de Estudiante X Datos del Estudiante X

Registro de Apoderados X Registro de Docente X

Registro de Datos X Datos secundarios X

TOTAL POR COMPLEJIDAD 7 0 0


3.7.3.2 CLASIFICACIN DE FUNCIONES DE ARCHIVOS POR SU COMPLEJIDAD

Tabla 3.12: Clasificacin de Funciones de Archivos por su Complejidad


Funcin

Simple

Media

Compleja

Archivos

Registro de Notas X Registro de Estudiante X

Lista de Aprobados X Lista de Reprobados X

Lista de Retirados X Asignar Materias X

Registro de Docente X Asignar Paralelo X

TOTAL POR COMPLEJIDAD 0 8 0


52

3.7.3.3 CLASIFICACIN DE FUNCIONES DE CONSULTA POR SU COMPLEJIDAD

Tabla 3.13: Clasificacin de Funciones de Consulta por su Complejidad


Funcin

Simple

Media

Compleja

Consulta

Seguimiento Acadmico X Registro de Estudiante X

Registro de Notas X Registro de Docente X

Registro de reas X Control de Estudiante X

Registro de Apoderado X

TOTAL POR COMPLEJIDAD

7

0

0 [Fuente: Elaboracin Propia]

3.7.4 CLCULO DE PUNTOS DE FUNCIN SIN AJUSTAR

Para realizar puntos de funcin sin ajustar, primeramente se realiza un conteo de las entradas, salidas, consultas y archivos, luego observamos su factor de complejidad.

Para posteriormente pasar a multiplicar por los valores fijos. En este caso representadas por la letra V. Luego procedemos a la suma total. De esa manera obtenemos el clculo de puntos sin ajustar.

53

Tabla 3.14 Puntos de Funcin Caractersticas

Del Sistema

Conteo

V Complejidad

Simple

V Complejidad

Media

V Complejidad

Alta Sub total

Entradas 22 3 1 4 21 6 0 87

Salidas 7 4 7 5 0 7 0 28

Consultas 3 3 7 4 0 6 0 21

Archivos 2 7 0 10

8 15

0 80

TOTAL PUNTOS DE FUNCIN SIN AJUSTAR 216 [Fuente: Puntos de Funcin]

3.7.5 CLCULO DEL FACTOR DE AJUSTE Para los clculos de factor ajuste existen diferentes preguntas que se relacionan con el sistema dichas preguntas tienen un valor de ajuste de complejidad evaluados de 0 a 5, las cuales nos permiten obtener un valor total para realizar el clculo de puntos de funcin.

Tabla 3.15: Factores de Ajuste FACTORES

N PREGUNTAS VALOR 1. Comunicacin de datos 2 2. Datos o procesamiento distribuidos 3 3. Objetivos de rendimiento 2 4. Configuracin utilizada masivamente 4 5. Tasa de transaccin 2 7. Eficiencia para el usuario 3 9. Procesamiento complejo 2

10. Reutilizacin 2 11. Factibilidad de instalacin y conversin 4 12. Factibilidad de operacin 1 13. Puestos mltiples 2 14. Factibilidad de cambio 2

TOTAL 30 [Fuente: Puntos de Factor de Ajuste]

Clculo de Puntos de Funcin segn su Complejidad

Factores de Ajuste

54

3.7.6 CLCULO DEL TOTAL DE PUNTOS DE FUNCIN Clculo del Factor de Ajuste

FA = 0.65 + (0.01 *30(factor ajuste)) = 0.95 Total de Puntos de Funcin Ajustados La formula general es TPF = PFSA (puntos sin ajustar) x FA (factor ajuste)

TPF = 216* 0.95 = 216.95 Para convertir a lneas de cdigo realizamos la siguiente operacin

SLDC = TPF* el valor del lenguaje a utilizar SLDC = 216.95*32(VB) = 6942.4

3.8 APLICACIN DEL COCOMO

3.8.1 ESTIMACIN DE COSTO TOTAL DEL PROYECTO MEDIANTE COCOMO I

Modelo Intermedio En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisin de la estimacin. Convertimos SLDC a KLDC: KLDC = (SLDC * 32)/1000 = (216.95*32)/1000 = 6.942 KDLC As pues, en nuestro caso el tipo orgnico ser el ms apropiado ya que el nmero de lneas de cdigo no supera los 50 KLDC, los coeficientes que usaremos sern las siguientes:

Tabla 3.16: Modelo Intermedio

[Fuente: Aplicacin del Modelo]

Proyecto Software a e c d

Orgnico 3,2 1,05 2,5 0,38

Semi-acoplado 3,0 1,12 2,5 0,35

Empotrado 2,8 1,20 2,5 0,32

55

Y por otro lado tambin hemos de hallar la variable FAE, la cual se obtiene mediante la multiplicacin de los valores evaluados en los diferentes 15 conductores de coste que se observan en la siguiente tabla:

Tabla 3.17: Conductores de Coste

Conductores de Coste VALORACIN

Muy bajo

Bajo

Nomi - nal

Alto

Muy alto

Extr. alto

Fiabilidad requerida del software 0,75 0,88

1.00 1,15

1,40 -

Tamao de la base de datos - 0,94

1.00 1,08

1,16 -

Complejidad del producto 0,70 0,85

1.00 1,15

1,30 1,65

Restricciones del tiempo de ejecucin

- - 1.00 1,11

1,30 1,66

Restricciones del almacenamiento principal

- - 1.00 1,06

1,21 1,56

Volatilidad de la mquina virtual 0,87

1.00 1,15

1,30 -

Tiempo de respuesta del ordenador

- 0,87

1.00 1,07

1,15 -

Capacidad del analista 1,46 1,19

1.00 0,86

0,71 -

Experiencia en la aplicacin 1,29 1,13

1.00 0,91

0,82 -

Capacidad de los programadores

1,42 1,17

1.00 0,86

0,70 -

Experiencia en S.O. utilizado 1,21 1,10

1.00 0,90

- -

Experiencia en el lenguaje de programacin

1,14 1,07

1.00 0,95

- -

Prcticas de programacin modernas

1,24 1,10

1.00 0,91

0,82 -

Utilizacin de herramientas software

1,24 1,10

1.00 0,91

0,83 -

Limitaciones de planificacin del proyecto

1,23 1,08

1.00 1,04

1,10 -

[Fuente: Aplicacin del Modelo]

56

FAE = 1,15*1,00*0,85*1,11*1,00*1,00*1,07*0,86*0,82*0,70*1,00*0,95 *1,00*0,91*1,08 = 0,53508480

Clculo del esfuerzo del desarrollo: E = a KLDC e * FAE = 3,2 * (6.9424)^1,05 * 0,53508480 = 13.88 personas /mes

Clculo tiempo de desarrollo: T = c Esfuerzo d = 2,5 * (13.88)^0,38 = 3.85 meses

Productividad: PR = LDC/Esfuerzo = 6942/13.88 = 500.14 LDC/personas mes

Personal promedio: P = E/T = 13.88/3.85 = 3.61 personas Segn estas cifras ser necesario un equipo de 4 personas trabajando alrededor de 4 meses. Para determinar el costo por lnea de cdigo realizamos lo siguiente: CLDC = P * sueldo del programador CLDC = 3.61 * $us 200 = $us 722

Para determinar costo total del software realizamos lo siguiente SW= CLDC*T SW= $us 722 * 3.85 = $us 2779.7 El costo total del software es de $us 2779.7

3.9 BENEFICIOS El sistema proveer acceso y transferencia de informacin en tiempo real, entre los diferentes usuarios, de tal forma que la informacin es oportuna al momento necesario para los mismos.

57

3.9.1 BENEFICIOS INTANGIBLES

Los beneficios tangibles que se pueden mencionar son: Todos los datos estarn centralizados en una sola base de datos. La informacin se transfiere electrnicamente a diferentes usuarios segn los privilegios que tenga. Se pueden hacer informes con la informacin en tiempo real. Se evita el gasto innecesario de papel reduciendo gastos operacionales. Con el software se reduce el tiempo en la productividad del personal, redundando en mejores servicios para la clientela. La integracin de los diferentes administrativos que brindan servicios similares en el rea acadmica, facilitando la integracin del sistema.

CAPTULO IV

INGENIERA DEL

PROYECTO

58

4.1 INTRODUCCIN En el presente proyecto, se desarrollar el proceso de desarrollo RUP siguiendo las fases correspondientes al anlisis, diseo, implementacin y pruebas, que se describir de forma detallada el comportamiento del Sistema de Informacin Acadmica de la Unidad Educativa Central Isla Suriqui, analizando las necesidades de la institucin, confirmando su viabilidad, planteando una solucin satisfactoria y razonable, as se pretender minimizar los problemas relacionados con su desarrollo.

4.2 FASE INICIO En esta fase se establece el contexto del sistema mediante el modelo de la institucin a travs de los casos de uso del Archivo de la Unidad Educativa, logrando definir el alcance del proyecto. Para lograr tal efecto se debe identificar las entidades externas con la que el sistema interactuar, es decir los actores, y definimos la interaccin a un nivel alto; esto involucra realizar un anlisis de requerimientos del usuario.

4.3 FASE ELABORACIN 4.3.1 INGENIERIA DE REQUERIMIENTOS El paso desde la determinacin de las necesidades del cliente hasta la implementacin. En primer lugar, las necesidades del cliente no son fciles de discernir, esto obliga a que se debe tener algn modo de capturar las necesidades del usuario de forma que puedan comunicarse fcilmente los requerimientos del sistema en toda su magnitud.

4.3.1.1 REQUERIMIENTOS FUNCIONALES Inscripcin. Registro de Docentes. Seguimiento Acadmico. Registro de calificaciones. Asignacin de Materias.

59

REGISTRO DE INSCRIPCIN Registrar RUDE Registro de Datos personales. REGISTRO DE DOCENTE Registrar RDA. Registrar los Datos Personales.

SEGUIMIENTO ACADMICO Seguimiento al Estudiante.

REGISTRO DE CALIFICACIONES Registrar las notas del estudiante. Entrega de notas a la direccin. Registro de notas de cada grado. Consulta de Estudiantes aprobados y reprobados

ASIGNACIN DE MATERIAS Asignacin de Grado al Docente. Asignar Materia segn la especialidad del Docente. 4.3.1.2 REQUERIMIENTOS NO FUNCIONALES: Los requerimientos no funcionales son propiedades o cualidades que el producto debe tener. Debe pensarse en estas propiedades como las caractersticas que hacen al producto atractivo, usable o confiable, por ejemplo, pudiera desearse que el sistema responda dentro de un intervalo de tiempo especificado o que obtenga los resultados de los clculos dados. En muchos casos los requerimientos no funcionales son fundamentales

en el xito del producto.

60

Normalmente estn vinculados a requerimientos funcionales, es decir una vez se conozca lo que el sistema debe hacer podemos determinar cmo ha de comportarse, que cualidades debe tener.

Apariencia o interfaz externa. El diseo de la interfaz del sistema es bastante simple de usar, adems de ser legible. Esto ayuda a que el usuario final se sienta cmodo en la interaccin con el sistema de informacin. Facilidad de uso. El sistema tiene parametrizado perfiles de usuarios de manera que el uso

del sistema ser de acuerdo al trabajo que realizan, esto con un control de autoridad de acuerdo al perfil asignado; adems el sistema proporciona mensajes de alerta o error claros para el uso adecuado del mismo rendimiento. Este sistema proporciona datos precisos. El tiempo de respuesta est limitado al tiempo de respuesta del DBMS ms que al servidor de aplicaciones donde reside el sistema soporte. El mantenimiento del sistema se efectuar desde la implementacin y migracin de datos en el caso de ser requerido; adems de continuar en el trabajo de mejora y dependiendo de los resultados obtenidos, se le agregaran nuevos servicios y herramientas para facilitar an ms el trabajo. Los usuarios de sistemas necesariamente debern conocer computacin bsica. El requerimiento mnimo del sistema operativo ser Windows XP.

61

4.4 ANLISIS DEL SISTEMA 4.4.1 DIAGRAMA CASOS DE USO

Figura 4.1: Diagrama de Caso Uso General

Realiza Inscripcin

SECRETARIO

DIRECTOR

ESTUDIANTE

DOCENTE

Asignacin deParalelo

Registrar Notas

SeguimientoAcademico

Ingresar al Sistema

Registrar Docentes

CASO DE USO G

proyecto suriqui origen

Documents