UNIVERSIDAD DE ORIENTE NCLEO DE ANZOTEGUI ESCUELA DE INGENIERA Y CIENCIAS APLICADAS DEPARTAMENTO DE COMPUTACIN Y SISTEMAS

DESARROLLO DE UN SISTEMA AUTOMATIZADO BAJO ENTORNO WEB PARA EL CONTROL DE LA PROGRAMACIN ACADMICA EN LA UNIVERSIDAD DE ORIENTE NCLEO DE ANZOTEGUI

REAZLIZADO POR:

Afonso R., Mariela A.

Segnini R., Jesus E.

Trabajo de grado presentado como requisito parcial para optar al Ttulo de INGENIERO EN COMPUTACIN

Barcelona, Junio de 2009

UNIVERSIDAD DE ORIENTE NCLEO DE ANZOTEGUI ESCUELA DE INGENIERA Y CIENCIAS APLICADAS DEPARTAMENTO DE COMPUTACIN Y SISTEMAS

DESARROLLO DE UN SISTEMA AUTOMATIZADO BAJO ENTORNO WEB PARA EL CONTROL DE LA PROGRAMACIN ACADMICA EN LA UNIVERSIDAD DE ORIENTE NCLEO DE ANZOTEGUI

JURADO CALIFICADOR:

M.Sc. Lenys Ordaz Asesor Acadmico

Ing. Rhonald Rodrguez Jurado Principal

Ing. Claudio Cortnez Jurado Principal

Barcelona, Junio de 2009

RESOLUCINDe acuerdo al Artculo N 44 Del Reglamento de Trabajo de Grado Los trabajos de grado son de exclusiva propiedad de la Universidad y slo podrn ser utilizados para otros fines con el conocimiento del Consejo de Ncleo respectivo, quin lo participar al Consejo Universitario.

IV

DEDICATORIASA Diosito que siempre est presente en todo lo que hago, a l debo la dicha de tener una familia tan maravillosa, mis logros y todo lo que soy.

A mi mamita hermosa por ser mi mejor amiga y darme apoyo incondicional solo el que una verdadera madre sabe dar, tan preocupada y dedicada, gracias a ella soy una persona de bien, es la madre ms maravillosa del mundo.

A mi papito por consentirme y amarme tanto, sus consejos juntos con los de mi mami son los que me hicieron la gran persona que soy, siempre hizo hasta lo imposible por velar por mi bienestar y el de toda la familia.

A mi hermanita la ms linda Maribel que a pesar de ser menor que yo me abri los ojos ante el mundo, siempre apoyndome y desendome lo mejor.

A mi novio Jess Eduardo por su amor, su compaa, por apoyarme siempre y ayudarme a lograr mis metas.

Mariela A. Afonso R.

V

Este trabajo de grado est dedicado principalmente a mi mama Yolmar de la Coromoto Rodrguez, que desde el cielo te sientas orgullosa.

A Dios, por esta maravillosa vida, por lo bueno, y por lo malo, pues de todo he aprendido algo.

A mi padre Carlos Eduardo Segnini por su gran dedicacin a sus hijos, gracias a su enorme esfuerzo tuvimos lo justo para que nunca nos faltara nada, tus ojos cansados siempre fueron motivo de empeo para seguir luchando por alcanzar mis metas.

A mi linda hermana Gabriela Segnini, quien desde su nacimiento ha llenado de alegras mi vida.

A mi hermano Carlos Segnini, por ser una gua durante mi carrera.

A mi bella novia Mariela, por apoyarme en todo cuanto he necesitado.

Jess E. Segnini R.

VI

AGRADECIMIENTOSA Diosito le doy gracias por todos mis logros y todo lo que soy, realmente soy feliz.

A la Universidad de Oriente por darme la oportunidad de estudiar a nivel superior y tratarme de la mejor manera posible haciendo realidad este logro.

A mis padres y hermanas por su apoyo y comprensin en todo momento. A mi novio por ser incondicional por estar siempre a mi lado y ayudarme en todo lo que he necesitado.

A mi asesora Lenys Ordaz por apoyarme desde el comienzo con este proyecto, por ofrecerme toda la informacin relacionada con el sistema actual, adems de estar pendiente del desarrollo del proyecto en todo momento.

A Carlos y Lanz por ofrecerme informacin sobre la base de Datos que administran en el Centro de Computacin Acadmica.

A mis amigos: Freya, Luisana, Wilfredo, Juan Luis, Rima, Manuel, Feres, Vanessa, Carmen, Luis Miguel, Luis Eduardo, Luis Carlos y Rosnuel por todos los maravillosos momentos que vivimos juntos.

A los profesores del Departamento de Computacin y Sistemas por sus enseanzas.

VII

A todos los profesores jefes de departamento y directores de escuela de la Universidad de Oriente, Ncleo de Anzotegui por su atencin y ayuda durante las entrevistas.

A todos mis familiares: abuelos, tos, primos que de alguna manera me han apoyado.

A mis compaeros de clases por su apoyo y compartir esta meta.

Gracias a todos.

Mariela A. Afonso R.VIII

Agradezco a Dios por ser mi principal gua, en especial en los momentos ms difciles cuando solo en sus palabras pude encontrar consuelo. A m querida madre Yolmar de la Coromoto Rodrguez por nunca rendirse, por haberme dado la vida, y sobre todo por su amor incondicional.

Gracias a mi bella hermana Gabriela Segnini, por ser mi mayor alegra y fuente inagotable de admiracin.

A mi hermano Carlos Segnini por cada valioso consejo y por haber marcado el camino para mi xito dejando suficientes seales a mi nombre para no perderme en los trayectos obscuros.

Agradezco a mi querida novia Mariela Afonso, que lleg justo a tiempo para detener mi cada y ensearme a caminar de nuevo cuando haba olvidado cmo hacerlo, por darle nuevo sentido a la palabra amor y ser tan comprensiva.

Gracias a la Sra. Luisa, el Sr. Manuel y Maribel, mi otra familia, quienes me abrieron las puertas de su casa y de sus corazones.

A mi asesora Lennys Ordaz, siempre atenta y dispuesta a ayudarnos.

Agradezco a mis profesores, por haber compartido sus conocimientos.

IX

A mis compaeros de clases, mis amigos, sin los cuales no hubiese podido llegar hasta este punto.

Gracias a todos!.

Jess E. Segnini R.

X

RESUMENEl siguiente proyecto de investigacin se basa en el desarrollo de un sistema automatizado para el control de la Programacin Acadmica (SACPA) para la Universidad de Oriente, Ncleo de Anzotegui. El software se encarga de proporcionar una interfaz agradable y de fcil manejo en entorno web a los diferentes departamentos acadmicos de la Institucin y a los directores de escuela para ingresar y administrar la Programacin Acadmica que elaboran durante cada periodo acadmico. Ademas de permitir consultas por parte de los estudiantes y los profesores. Esta informacin relacionada con la programacin acadmica es guardada directamente en la base de datos ubicada en el Centro de Computacin Acadmica que es el administrador del sistema, lo que mejora la comunicacin entre este centro y los departamentos. Este sistema garantiza informacin confiable ya que uno de sus principales objetivos es validar los datos ingresados, adems permite a los usuarios consultar un mapa de aulas con el fin de mejorar la planificacin de su programacin. El software se elabor utilizando el lenguaje de programacin PHP versin 5.2.0, la tcnica de programacin AJAX, el servidor Apache versin 5.0 y el motor de base de datos MySQL versin 5.0. Este proyecto se construy siguiendo el Proceso Unificado de Desarrollo de Software, la herramienta WebML y el Lenguaje de Modelado UML.

XI

CONTENIDO

RESOLUCIN ................................................................................................. IV DEDICATORIAS ............................................................................................. V AGRADECIMIENTOS .................................................................................. VII RESUMEN ....................................................................................................... XI CONTENIDO .................................................................................................. XII CAPITULO I. PLANTEAMIENTO DEL PROBLEMA ................................ 16 1.1 Introduccin ............................................................................................ 16 1.1.1 Problema ......................................................................................... 17 1.1.2 Propsito ......................................................................................... 22 1.1.3 Importancia ..................................................................................... 24 1.1.4 Alcance ........................................................................................... 24 1.1.5 Justificacin .................................................................................... 25 1.1.6 Originalidad .................................................................................... 26 1.2 Objetivos ................................................................................................. 26 1.2.1 Objetivo General ............................................................................. 26 1.2.2 Objetivos Especficos...................................................................... 26 .......................................................................... Error! Marcador no definido. CAPITULO II. MARCO TEORICO ............................................................... 28 2.1 Antecedentes de la investigacin ............................................................ 28 2.2 Universidad de Oriente ........................................................................... 29 2.3 Sistemas de Informacion......................................................................... 33 2.3.1 Definicin [5] .................................................................................. 33 2.3.2 Actividades bsicas de los sistemas de informacin [5] ................. 33 2.3.3 Anlisis y diseo del sistema [5] .................................................... 34 2.3.4 Desarrollo del diseo del sistema [5] .............................................. 35

2.4 INGENIERA DE SOFTWARE ............................................................ 38 2.4.1 Definicin [6].............................................................................. 38

2.4.2 Objetivos de la Ingeniera de Software [6] ...................................... 40 2.4.3 Objetivos de la Ingeniera de Software en los Proyectos de

Sistemas [6] .......................................................................................................... 40 2.4.4 Proceso de Ingeniera de Software [6] ............................................. 43 2.4.5 Fases de la Ingeniera de Software [6] ............................................. 44 2.5 Programacin orientada a objetos ........................................................... 45 2.5.1 Definicin [7] ................................................................................... 45 2.6 Proceso unificado de desarrollo de software .......................................... 49 2.6.1 Definicin [8] ................................................................................... 49 2.6.2 Principios Bsicos del Proceso Unificado de Desarrollo de

Software [8] ......................................................................................................... 50 2.6.3 Vida del Proceso Unificado [8] ........................................................ 53 2.6.4 Descripcin de las fases del proceso unificado de desarrollo del software [8] .......................................................................................................... 54 2.6.5 Flujos del Proceso Unificado de Desarrollo de Software [8] ........... 56 2.6.6 Flujos de Trabajos para una Iteracin [8]......................................... 62 2.6.7 Ventajas del Proceso Unificado de Desarrollo de Software [8] ....... 62 2.6.8 Desventaja del Proceso Unificado de Desarrollo de Software [8] .. 63 2.8 Tecnologas web ................................................................................... 75

2.8.1 Intranet [10] .................................................................................... 75 2.8.2 Internet [11] .................................................................................... 75 2.8.3 Aplicacin Cliente - Servidor [12] ................................................. 76 2.8.4 Servidor Web [13] .......................................................................... 76 2.8.5 Lenguaje de Etiquetas por Hipertexto [14] ..................................... 78 2.8.6 Tcnica de desarrollo web AJAX [15] ........................................... 78 2.8.7 Aplicaciones Web [16] ................................................................... 80 2.8.8 Concepto general de WebML [17] ................................................. 83

2.9 LENGUAJE DE PROGRAMACIN PHP .......................................... 100 2.9.1 Definicin [18] .............................................................................. 100 2.10 Base de datos ....................................................................................... 101 2.10.1 Definicin [19] ............................................................................ 101 2.10.2 Sistema De Gestin De Base De Datos (SGBD) [19] ................. 102 2.10.3 Arquitectura de un SGBD [19].................................................... 102 2.10.4 Modelo de datos [19]................................................................... 103 2.10.5 Arquitectura Cliente Servidor [19] ........................................... 104 2.10.6 Lenguaje Estructurado de Consultas SQL [19] ........................... 104 2.10.7 Sistema Manejador de Base de Datos MySQL [19] .................. 104 2.11 Software libre ...................................................................................... 105 2.11.1 Definicin [20] ............................................................................ 105 CAPITULO III. FASE DE INICIO ................................................................ 108 3.1 Introduccin .......................................................................................... 108 3.2 Contexto del sistema ............................................................................. 108 3.2.1 Comprensin de los Requisitos ..................................................... 109 3.2.2 Modelo de dominio del sistema .................................................... 109 3.3 Riesgos del sistema ............................................................................... 112 3.4 Requisitos del sistema ........................................................................... 113 3.4.1 Requisitos Funcionales .................................................................. 114 3.4.2 Requisitos No Funcionales ............................................................ 115 3.4.3 Requisitos de Software .................................................................. 115 3.4.4 Requisitos de Hardware ................................................................ 115 3.4.5 Modelo de Casos de Uso ............................................................... 116 3.5 Anlisis.................................................................................................. 131 3.5.1 Diagramas de Clases de Anlisis ................................................. 131 3.5.2 Diagramas de Clases de Anlisis para los casos de uso del sistema. ............................................................................................................................ 137 3.6 Diseo del sistema ................................................................................ 144

3.6.1 Arquitectura de una aplicacin web ............................................... 144 3.7 Evaluacin de la fase de inicio ............................................................. 145 CAPITULO IV. FASE DE ELABORACIN ................................................ 147 4.1 Introduccin .......................................................................................... 147 4.2 Requisitos del sistema .......................................................................... 147 4.2.4 Validaciones ................................................................................... 151 4.2.5 Prototipo de Interfaz de Usuario .................................................... 151 4.2.6 Modelo de Hipertextos ................................................................... 153 4.3 Anlisis ................................................................................................. 157 4.3.1 Identificacin de Clases de Anlisis .............................................. 157 4.3.2 Diagramas de Colaboracin ........................................................... 158 4.4 Diseo ................................................................................................... 164 4.4.1 Base de Datos del Sistema ............................................................. 165 4.4.3 Modelos de Gestin de Contenidos ............................................... 171 4.4.4 Diseo de la Arquitectura .............................................................. 189 4.5 Implementacin .................................................................................... 191 4.5.1 Implementacin de la Arquitectura ................................................ 191 4.5.2 Identificacin de los Componentes de la Arquitectura .................. 191 CAPITULO V. FASE DE CONSTRUCCIN ............................................... 194 5.1 Introduccin .......................................................................................... 194 5.2 Implementacin .................................................................................... 194 5.2.1 Implementacin del Modelo de Hipertexto ................................... 194 5.2.2 Implementacin de los Modelos de Gestin de Contenido ........... 196 5.3 Pruebas ................................................................................................. 274 5.3.1 Pruebas de Unidad ......................................................................... 274 5.3.2. Pruebas de Integracin .................................................................. 280 5.4 Evaluacin de la fase de construccin .............................................. 288 CAPITULO VI. FASE DE TRANSICIN ..................................................... 290 6.1 Introduccin .......................................................................................... 290

6.2 Lanzamiento de la versin beta ............................................................ 290 6.3 Evaluacin de la fase de transicin....................................................... 291 CONCLUSIONES........................................................................................... 293 RECOMENDACIONES ................................................................................. 296 BIBLIOGRAFA ............................................................................................. 298 ANEXO A. MANUAL DE USUARIO ............ Error! Marcador no definido. ANEXO B. REPORTES IMPRESOS ............... Error! Marcador no definido. METADATOS PARA TRABAJOS DE GRADO, TESIS Y ASCENSO:....302

CAPITULO I. PLANTEAMIENTO DEL PROBLEMA1.1 Introduccin La tecnologa a nivel mundial, siempre ha sido parte importante dentro de la sociedad y la educacin, donde las universidades forman parte integral de este proceso, en el mbito de la informacin y la comunicacin, las instituciones utilizan sistemas y recursos para el desarrollo y difusin digitalizada de la informacin. El desarrollo de aplicaciones Web como complemento al proceso de aprendizaje se convierte en un recurso imprescindible en nuestros das. En la actualidad, se incorporan estas nuevas tecnologas al proceso educativo en sus distintos niveles con la finalidad de variar y flexibilizar las oportunidades de aprender sin restricciones de lugar, tiempo y atendiendo a las diferencias individuales y de grupo. La Universidad de Oriente, especficamente el Ncleo de Anzotegui se perfila en concordancia con estos nuevos avances en el rea de la ciencia y la tecnologa, por medio de la incorporacin de nuevos proyectos enmarcados al desarrollo de aplicaciones usando plataforma Web, que permitirn dar a conocer y satisfacer las necesidades de informacin a toda la comunidad universitaria.

En el ao de 1995 por Resolucin CU-08/95 del Consejo Universitario, la Universidad de Oriente en el Ncleo de Anzotegui funda la Direccin de Servicios de Computacin con dos dependencias, el Centro de Computacin Acadmica y el Centro de Computacin Administrativa. El Centro de Servicios de Computacin Acadmica de la Universidad de Oriente del Ncleo de Anzotegui, permite apoyar a todas las dependencias acadmicas que lo conforman tales como: Decanato, Coordinaciones, Escuelas, Departamentos, Direccin de Bienestar Estudiantil y por supuesto la principal dependencia que es el Departamento de Admisin y Control de

17

Estudios (D.A.C.E), a travs de sistemas de informacin acadmicos automatizados y prestacin diaria de soporte tcnico. A su vez, ste centro se encarga de planificar, organizar, coordinar y supervisar diferentes servicios que ofrece a estas dependencias. Tambin el resguardo de los datos estudiantiles, la programacin acadmica, emisin de diferentes informes impresos, presentacin anual de las actividades del departamento a entidades superiores y cumplir con los deberes y atribuciones que sealan los reglamentos y resoluciones de la institucin.

El personal administrativo que labora en este centro de computacin puede tomar decisiones a la hora de planificar, coordinar y desarrollar nuevos proyectos en beneficio de la comunidad universitaria. Actualmente el personal de este centro est compuesto por un jefe del centro de computacin acadmica y tres analistas de sistemas. El jefe del centro, se encarga de planificar, organizar, coordinar y supervisar todas las actividades que se desenvuelven en l, as como tambin delegar funciones al resto de sus empleados como son los analistas de sistemas, que se encargan de analizar, desarrollar e instalar nuevos sistemas de informacin y mantener los ya existentes, todo enmarcado dentro de las necesidades de la institucin.

En la presente investigacin se desarrolla un sistema que permitir automatizar el control de la programacin acadmica de la Universidad de Oriente Ncleo de Anzotegui.

1.1.1 Problema El Centro de Servicios de Computacin Acadmica, es el que lleva a cabo el proceso de inscripcin de los estudiantes regulares de la universidad por cada periodo acadmico, en el cual participan ciertos elementos que son considerados claves dentro del sistema. Evidentemente, estos elementos que forman parte del sistema del proceso

18

de inscripcin estn enmarcados por la informacin suministrada por las distintas direcciones de escuelas, coordinacin acadmica y D.A.C.E, como se muestra en la figura 1.1.

Figura 1.1. Elementos relacionados con el Proceso de Inscripcin. (Fuente: Centro de Computacin Acadmica)

Previamente al desarrollo de las inscripciones regulares, en lo referente a datos e informacin se procesan las preactas con las notas de cada materia para poder actualizar la data en los servidores, se prepara la generacin de las citas de inscripcin (hora y da) por estudiante, cabe destacar la carga de la programacin acadmica de materias y secciones es suministrada por las diferentes Direcciones de Escuelas de la Institucin, que a su vez la recibe de los departamentos.

El Centro de Servicios de Computacin Acadmica es un ente de desarrollo, implantacin y mantenimiento de los sistemas de informacin acadmicos automatizados que existen actualmente en este ncleo, la eficiencia operativa de esta dependencia estara siendo afectada por la ausencia de aplicaciones Web para todo el

19

entorno del proceso de inscripcin de los estudiantes regulares de la Universidad de Oriente del Ncleo de Anzotegui, a pesar de que ya se han realizado varias aplicaciones Web, entre las cuales se encuentran: el sistema de carga de notas o preactas, el sistema de asociacin de preactas al profesor, el sistema de preinscripcin de estudiantes regulares, el sistema de preinscripcin de nuevos ingresos, faltando el sistema para el control de la programacin acadmica, para apoyar de manera efectiva el proceso de inscripcin de estudiantes regulares. Esta carencia se estima como una debilidad que se agudiza durante la jornada de inscripcin debido a que el mecanismo existente no aporta la respuesta adecuada para los usuarios y el personal al frente del sistema, esto afecta al proceso de inscripcin de forma directa. Se presenta una situacin problemtica caracterizada por:

El aumento de la poblacin estudiantil a lo largo de varios aos, como se muestra en la tabla 1.1 lo que ha ocasionado un colapso durante las inscripciones debido a la insuficiencia de espacio fsico (planta fsica), que no cubre la demanda de estudiantes que asisten al proceso.

Tabla 1.1 Matrcula Estudiantil (Centro de Servicios de Computacin Acadmica, 2007) 1/2

20

Tabla 1.1 Matrcula Estudiantil (Centro de Servicios de Computacin Acadmica, 2007) 2/2

Existen fallas muy frecuentes en la programacin acadmica, suministrada por las distintas direcciones (Ingeniera, Ciencias de la Salud, Ciencias Administrativas y la Direccin de Apoyo a la Docencia reas Interdisciplinarias) de la institucin, en cuanto a la cantidad de secciones por asignaturas planificadas que no satisfacen la demanda de cupos ya que frecuentemente deben ser modificados. Entre estas fallas podemos mencionar:

La escuela de Ciencias de la Salud realiza una programacin acadmica usando un editor de texto y el Centro de computacin Acadmica es el que se encarga de revi sar y cargar la programacin en el formato requerido por el sistema para su posterior uso en las inscripciones, esto puede generar errores, ya que una sola persona se enc arga de adaptar esta programacin acadmica. Las otras tres direcciones: Ingeniera, Ciencias Administrativas y la Direccin de Apoyo a la Docencia reas Interdisciplinarias (Bsico), procesan la programacin acadmica de sus departamentos usando un programa con una base de datos local que no se encuentra interconectada en cada direccin, este sistema est desarrollado en

21

Visual Basic con una base de datos en Access, donde la programacin acadmica es cargada por una sola persona que la mayora de las veces comete errores, bien sea de trascripcin o simplemente cargando la programacin que ya viene con errores desde los departamentos, por lo general quien carga la programacin en el sistema son las secretarias de estas direcciones.

Al no estar interconectadas las bases de datos de las direcciones pueden existir choques de aulas, ya que las tres direcciones manejan todas las aulas independientemente una de otras.

Tambin se puede dar el caso de que choquen materias pertenecientes a un mismo semestre, esto porque al momento de verificar la programacin lo pasan por alto.

La presente investigacin se basa fundamentalmente en solventar las dificultades que se presentan con la programacin acadmica en el proceso de inscripcin de los estudiantes regulares, con una propuesta que se inicia con un sistema que permita cargar la programacin acadmica, e mpleando tecnologa Web, esto con el fin de proporcionar un excelente servicio a la comunidad universitaria y mejorar los procesos de inscripcin de estudiantes regulares y de planificacin en los diferentes departamentos.

Con la data que genera este sistema se proporciona informacin veraz a todos los entes involucrados, debido a que podrn acceder al mismo y obtener informacin acerca de la cantidad de estudiantes planificados por materias, para as poder tomar decisiones de aperturas de nuevas secciones a corto plazo.

22

El sistema permitir a los departamentos realizar la carga de la programacin acadmica independientemente uno de otros sin tener que hacerlo en las direcciones, simplemente desde cada departamento usando la Intranet existente o mediante el uso de Internet solo en caso de ser necesario, se acceder al sistema a travs de la pagina del Centro de Computacin Acadmica con previa identificacin.

Adems de esto se podr consultar un mapa de aulas por parte de cada uno de los departamentos acadmicos, c on la finalidad de que entre departamentos se puedan facilitar aulas en los horarios que les quedan disponibles.

En funcin de las anteriores consideraciones se puede formular la siguiente interrogante: Cules sern los criterios y procedimientos a seguir para desarrollar un sistema basado en tecnologa Web a objeto de minim izar las deficiencias detectadas en los actuales procesos de carga de la programacin acadmica de la Universidad de Oriente - Ncleo de Anzotegui y la influencia sobre las entidades acadmicas?

1.1.2 Propsito El fin de este trabajo es el desarrollo del Sistema para el control de la Programacin Acadmica para estudiantes regulares en un entorno Web utilizando tecnolo gas de Base de Datos, lenguajes de cuarta generacin y una arquitectura Cliente/Servidor que funcione sobre la plataforma de red existente en el Ncleo.

Este trabajo se realizar aplicando la disciplina de Ingeniera de Software, la cual se puede obtener mediante la combinacin de mtodos completos para todas las fases de desarrollo de software.

23

En el sistema a desarrollar se utilizar el Lenguaje Unificado para Modelado UML, ya que este lenguaje define una notacin y un proceso para construir Sistemas de Software complejos y ofrece un rico conjunto de mtodos lgicos y fsicos con los cuales se puede razonar sobre diferentes aspectos del sistema.

En vista de lo anterior, se plantea el desarrollo de un sistema automatizado, el cual ser concebido con mecanismos que permitan la creacin, mantenimiento, respaldo y seguridad de la informacin que se maneja en el rea de Pregrado, que incluye los datos personales y acadmicos de los profesores, los pensum de estudios, las aulas disponibles, y horarios para las diferentes las materias que se dictan, con sus respectivas secciones , adems de la generacin de los reportes necesarios.

Esta implementacin se esquematiza a los fines de proveer beneficios que establezcan un control y organizacin del sistema actual, permitiendo la estandarizacin de los diferentes procesos que se realizan en cada una de las direcciones de escuela, y as mejorar la comunicacin de stas con el Centro de Computacin Acadmica. Las Bases de Datos, son como depsitos para los datos, que son almacenados unificadamente y que se pueden compartir por varios usuarios. Esto permite reducir la inconsistencia, reforzar los estndares, crear restricciones de seguridad y de integridad de la informacin.

La programacin aplicada en este proyecto emplear la herramienta PHP 5, lenguaje de cuarta generacin que trabaja en el contexto de una arquitectura Cliente/Servidor, donde las aplicaciones sugieren una forma de procesamiento cooperativo entre bancos de computadores personales y un servidor de base de datos central.

24

1.1.3 Importancia La importancia de esta investigacin usando tecnologa Web radica en proporcionar soluciones a corto o mediano plazo ante la imperiosa necesidad de mejorar tanto las actividades relacionadas con el proceso de inscripcin de los estudiantes regulares como la toma de decisiones de todos los departamentos con relacin a la programacin acadmica en la Universidad de Oriente - Ncleo de Anzotegui.

La implan tacin y utilizacin de este sistema traer consigo una notable mejora en la relacin Tiempo-Trabajo en cuanto a la programacin acadmica, que permitir un mejor desempeo en la funcionalidad del Sistema de Admisin y Control de Estudios de de la Universidad de Oriente Ncleo de Anzotegui.

1.1.4 Alcance El Sistema automatizar todos los procesos referentes a la programacin acadmica de la Universidad de Oriente, Ncleo de Anzotegui, produciendo un mayor rendimiento tiempo/trabajo.

Con la realizacin de este proyecto se pretende elaborar una herramienta de gestin para solventar la problemtica asociada a la programacin acadmica de los estudiantes regulares de la Universidad de Oriente, Ncleo de Anzotegui, este sistema utiliza plataforma Web y se desarroll mediante la herramienta WebML, el lenguaje de programacin PHP 5, el lenguaje de consultas SQL y el motor de base de datos MySQL 5.

25

La herramienta WebML se utiliza como herramienta de anlisis y diseo del sistema. Para modelar los escenarios que conforman el sistema a travs de los esquemas estticos y dinmicos que permiten adaptar la investigacin sin problemas, se usa el Lenguaje Unificado para Modelado (UML) como metodologa.

En trminos prcticos, la presente investigacin propone que el sistema bajo plataforma Web tome una perspectiva integral, global, permitiendo que directivos de la academia y estudiantes (ya que estos tendrn acceso para consultar la informacin relacionada con la programacin acadmica) se involucren dentro de nuevas tecnologas y satisfagan sus necesidades.

1.1.5 Justificacin Desde el punto de vista prctico el desarrollo del sistema se orienta a la mejora del servicio prestado por el Centro de Servicios de Computacin Acadmica para el proceso de inscripcin de alumnos regulares y sirve de soporte informtico a las actividades realizadas dentro de la institucin relacionadas con este proceso, logrando de esta manera la eficiencia en el manejo de la informacin.

Con la innovacin del sistema en plataforma Web, los departamentos pueden realizar la carga de la informacin relacionada con la programacin acadmica a travs del portal desde la pgina principal del Centro de Servicios de Computacin Acadmica de la Universidad de Oriente del Ncleo de Anzotegui, facilitando el acceso a los usuarios. Cada departamento es responsable de su programacin debido a que tendr control total sobre el sistema, ingresando data, re alizando consultas entre ellas la del mapa de aulas que les ser de mucha ayuda al momento de planificar o modificar la programacin. Los departamentos tienen acceso

26

al sistema en lnea desde cualquier sala de computacin de esta institucin (Intranet) y desde Internet.

Para el Centro de Servicios de Computacin Acadmica el proyecto de investigacin se presenta como una alternativa a objeto de elevar su calidad de gestin en beneficio de la comunidad universitaria.

1.1.6 Originalidad

Este es uno de los primeros proyectos que se desarrollar en la Universidad Ori de ente Ncleo de Anzotegui mediante Software Libre.

Adems este proyecto es uno de los pocos que ser implementado en la univers idad, gracias al Centro de Computacin Acadmica.

1.2 Objetivos

1.2.1 Objetivo General Desarrollar un sistema basado en tecnologa Web, para el control de la programacin acadmica de los estudiantes regulares de la Universidad de Oriente, Ncleo de Anzotegui.

1.2.2 Objetivos Especficos

Diagnosticar la situacin actual del proceso de la programacin acadmica de estudiantes regulares del ncleo de Anzotegui en la Universidad de Oriente.

27

k Identificar los requerimientos del sistema a desarrollar partiendo del anlisis de la informacin recopilada del sistema actual. k Definir la estructura del sistema, identificando los modelos de datos, comportamientos y relaciones. k Estudiar la base de datos existente. k Desarrollar mdulos de programacin del sistema de informacin propuesto utilizando herramientas de desarrollo computarizado. k Elaborar la documentacin del usuario y de mantenimiento del Software. k Instalar el software.

CAPITULO II. MARCO TEORICO2.1 Antecedentes de la investigacin A continuacin se establecen los antecedentes ms prximos al problema. Entre los trabajos realizados estn:

(Martha Elena Garca Len y Vctor Julio Mujica Vargas, Junio 2005). Desarrollo de un Software para la Automatizacin de las actividades Administrativas del Departamento de Computacin y Sistemas de la Universidad de Oriente Ncleo de Anzotegui. El Proyecto se elabor siguiendo los lineamientos del proceso unificado de desarrollo de software el objetivo primordial fue agilizar la gestin administrativa del departamento de computacin y sistemas a travs de la automatizacin de de las tareas administrativas llevadas a cabo. [1] (Dr. Snchez David, 2007) Aplicacin Web. Sistema Web del Estudiante Universidad del Zulia. Este sistema se centra en la idea de prestar un mejor servicio e interaccin entre los procesos acadmicos de la direccin docente y el alumnado de la Universidad. Los estudiantes tendrn una inscripcin interna por facultades que comienza con una pre-inscripcin por carrera. Existen otros proyectos basados en tecnologa Web tales como: Sitio Web La Web del Estudiante, Aplicacin Web Sistema de Admisin Web a LUZ y Material Multimedia Interactivo e Informativo para la Web. [2] (Colmenares Giancarlo , 2.004). Sistema de Inscripcin va Web. El sistema de Inscripcin va Web fue realizado por el ingeniero Giancarlo Colmenares en la Universidad Experimental del Tchira (UNET). El primer

29

sistema fue desarrollado por el profesora Marisol Mantilla en el II perodo del 2004, pero fue rediseado totalmente por Giancarlo perodo 3 del 2004. Al finalizar cada semestre y una vez entregadas las notas definitivas a los estudiantes, se les genera la oferta acadmica y esta es publicada automticamente en la pgina Web. All el estudiante puede visualizar las materias ofertadas y el horario que posee cada una de las secciones para que cuadren el horario. El orden de inscripcin es calculado de acuerdo al ndice acadmico del ndice ms alto al ms bajo y la activacin de la inscripcin se realiza cada 13 segundos. En la pgina de la inscripcin como tal el estudiante puede cuadrar el horario y slo ver las secciones en las cuales queden cupos disponibles. Los choques de horario son marcados con rojo. [3]

2.2 Universidad de Oriente La Universidad de Oriente fue creada el 21 de noviembre de 1958, mediante el Decreto Ley Nro. 459 dictado por la Junta de Gobierno presidida por el Dr. Edgard Sanabria, siendo Ministro de Educacin el Dr. Rafael Pizani.

La conformacin de la Universidad de Oriente en cinco Ncleos, obedece a su filosofa de regionalizacin de la Educacin Superior, estructurndose cada uno de ellos de acuerdo a la vocacin de los estados en que se asientan y a las facilidades ofrecidas por los mismos. De este modo fue considerada la vocacin hacia las principales actividades econmicas y de produccin de cada entidad federal y sus implicaciones:

La agricultura, la ganadera, los hidrocarburos y el turismo, en Anzotegui. La agricultura, la ganadera, la minera y el turismo, en Bolvar. La agricultura, la ganadera, los hidrocarburos y el turismo, en Monagas.

30 El comercio, la pesca y el turismo, en Nueva Esparta. La agricultura, la pesca y el turismo, en Sucre.

Todo ello sin excluir otras posibilidades locales de desarrollo, tanto econmico como social. Ver figura 2.1.

Figura 2.1. Ubicacin de los Ncleos de la universidad de Oriente El 20 de febrero de 1960, por Resolucin del Consejo Universitario se crea en Barcelona, el Ncleo de Anzotegui de la Universidad de Oriente, respondiendo a las exigencias regionales de profesionales y tcnicos. Este ncleo inicia sus actividades docentes el 12 de febrero de 1963, con la apertura de las carreras de Ingeniera Elctrica, Ingeniera Mecnica, Ingeniera Industrial e Ingeniera Qumica.

En el segundo semestre de 1974 se reestructura el Ncleo de Anzotegui, crendose las Escuelas de Ingeniera y Ciencias Aplicadas, la Escuela de Ciencias Administrativas, la Escuela de Medicina y la Unidad de Estudios Bsicos. Actualmente se dictan 14 carreras en su sede de Barcelona. La extensin de Anaco se cre para ofrecer las carreras de Contadura Pblica, Administracin,

31

Ingeniera Industrial e Ingeniera de Sistemas. A continuacin podemos en la figura 2.2 ver el mapa del Ncleo de Anzotegui de la Universidad de Oriente.

Figura 2.2. Mapa de la universidad de Oriente Ncleo de Anzotegui Dentro de la universidad de Oriente se encuentra en Centro de computacin acadmica el cual tiene como misin, Planificar, Coordinar y Supervisar todas aquellas actividades relacionadas con el anlisis, diseo, administracin,

mantenimiento y actualizacin de sistemas de informacin y la red acadmica (Intranet) de la comunidad universitaria. Adems de autorizar y supervisar el desarrollo de proyectos que involucren el uso de la red o plataforma Teleinformtica en el rea acadmica.

Tiene como objetivo apoyar a las dependencias acadmicas del ncleo como: departamento de Admisin, Control de Estudios, Direccin de Bienestar Estudiantil y Oficina de Planificacin, entre otros; mediante el mantenimiento del Sistema Automatizado Acadmico-Administrativo de Control de Estudios, as como la impresin de diferentes listados y el resguardo de los datos estudiantiles (ver figura 2.3).

32

Las funciones del centro de computacin acadmica son las siguientes:k Organizar, promover, coordinar y supervisar los diferentes servicios que

presta este departamento.k Presentar el Informe Anual de Actividades. k Realizar reuniones peridicas con el fin de promover y evaluar los

diferentes servicios que presta el Departamento.k Realizar reuniones con el Director de Servicios de Computacin a fin

de coordinar, evaluar y proyectar los diferentes servicios que se prestan.k Cumplir con los deberes y atribuciones que sealan los Reglamentos y

Resoluciones de la Institucin. [4]

Figura 2.3. Organigrama Centro de Computacin Acadmica

33

2.3 Sistemas de Informacion

2.3.1 Definicin [5] Un sistema, es un conjunto de componentes que interactan entre s para lograr un objetivo comn. Una organizacin es un sistema, donde sus componentes: mercadotecnia, manufactura, ventas, investigacin, embarques, contabilidad y personal; trabajan juntos para crear utilidades que beneficien tanto a los empleados como a los accionistas de la compaa. Cada uno de estos componentes es a su vez un sistema. Todo sistema depende en mayor menor medida, de una entidad abstracta denominada sistema de informacin. Este sistema es el medio por el cual los datos fluyen de una persona o departamento hacia otros y puede ser cualquier cosa, desde la comunicacin interna entre los diferentes componentes da la organizacin y lneas te lefnicas hasta sistemas de cmputo que generan reportes peridicos para varios usuarios. Los sistemas de informacin proporcionan servicio a todos los dems sistemas de una organizacin y enlazan todos sus componentes en forma tal que estos trabajen con eficiencia para alcanzar el mismo objetivo.

2.3.2 Actividades bsicas de los sistemas de informacin [5] Segn (Peralta, 1997) el sistema de informacin realiza cuatro actividades bsicas : entrada, almacenamiento, procesamiento y salida de informacin:

Entrada de Informacin: es el proceso mediante el cual el Sistema de Informacin toma los datos que requiere para procesar la informacin. Las entradas pueden ser manuales o automticas. Almacenamiento de informacin: el almacenamiento es una de las actividades o capacidades ms importantes que tiene una computadora , ya que

34

a travs de esta propiedad el sistema puede recordar la informacin guardada en la seccin o proceso anterior. Procesamiento de Informacin: es la capacidad del Sistema de Informacin para efectuar clculos de acuerdo con una secuencia de operaciones preestablecida. Estos clculos pueden efectuarse con datos introducidos recientemente en el sistema o bien con datos que estn almacenados. Salida de Informacin: la salida es la capacidad de un Sistema de

Informacin para sacar la informacin procesada o bien datos de entrada al exterior. Las unidades tpicas de salida son las impresoras, terminales, diskettes.

2.3.3 Anlisis y diseo del sistema [5] El anlisis y diseo del sistema se refiere al proceso de explorar la situacin de la organizacin con el propsito de mejorarla con mtodos y procedimientos ms adecuados, en el caso de este proyecto es utilizando el Lenguaje de Modelado Unificado (UML) de manera novedosa.

El anlisis de sistemas, es el proceso de clasificacin e interpretacin de hechos, diagnsticos de problemas y empleo de la informacin para recomendar mejoras al sistema. El anlisis especifica que es lo que el sistema debe hacer.

El diseo del sistema, es el proceso de planificar, reemplazar complementar un sistema organizacional existente. Es como los planos de un edificio: especifica

objetivo.

todas las caractersticas del producto terminado, es decir, establece como alcanzar el

35

2.3.4 Desarrollo del diseo del sistema [5] Es un proceso que consta de las siguientes actividades:

2.3.4.1 Investigacin pre liminar La solicitud para recibir ayuda de un sistema de informacin puede originarse por varias razones; sin importar cuales sean stas, el proceso se inicia siempre con la peticin de una persona (administrador, empleado, especialista en sistemas). Cuando se formula la solicitud, comienza la primera actividad: la investigacin preliminar. Esta tiene tres partes: Aclaratoria de la solicitud, estudio de factibilidad y aprobacin de la solicitud. Aclaracin de la solicitud: Muchas solicitudes que provienen de empleados y usuarios no estn formulados de manera clara. Por consiguiente antes de considerar cualquier investigacin de sistemas, la solicitud de proyecto debe examinarse para determinar con precisin lo que el solicitante desea. Si el solicitante pide ayuda sin saber qu es lo que est mal donde se encuentra el problema, la aclaracin del mismo se vuelve ms difcil. En cualquier caso, antes de seguir adelante, la solicitud del proyecto debe estar claramente planteada.

Estudio de factibilidad: El sistema solicitado debe ser factible en tres aspectos:

9 Factibilidad tcnica: El trabajo para el proyecto, puede realizarse con el equipo actual, la tecno loga existente de software y el personal disponible?, si se necesita una nueva tecnologa cul es la posibilidad de desarrollarla? 9 Factibilidad econmica: Al crear el sistema, los beneficios que se obtienen sern suficientes para aceptar los costos?, los costos

36

asociados con la decisin de no crear el sistema son tan grandes que se debe aceptar el proyecto?

9 Factibilidad operacional: Si se desarrolla e implanta, ser utilizado elsistema?, existir cierta resistencia al cambio por parte de los usuarios?

Aprobacin de la solicitud: No todos los proyectos solicitados sondeseables o factibles. Los que son deben incorporarse a los planes. Muchas organizaciones desarrollan sus planes para sistemas de informacin con el mismo cuidado con el que planifican nuevos productos y programas de fabricacin o la expansin de las instalaciones. Despus de aprobar la solicitud del proyecto se estima su costo, el tiempo necesario para terminarlo y las necesidades de personal; con esta informacin se determina donde ubicarlo dentro de la lista existente de proyectos.

2.3.4.2 Determinacin de los requerimientos del sistema El aspecto fundamental del anlisis del sistema es comprender todas las facetas importantes de la parte de la organizacin que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de la organizacin para dar respuesta a las siguientes preguntas claves: 1. Qu es lo que se hace? 2. Cmo se hace? 3. Con que frecuencia se presenta? 4. Qu tan grande es el volumen de transacciones o de decisiones? 5. Cul es el grado de eficiencia con el que se efectan las tareas? 6. Existe algn problema? 7. Si existe un problema, qu tan serio es?

37

8. Si existe un problema, cul es la causa que lo origina? Para contestar estas preguntas, el analista conversa con varias personas para reunir detalles relacionados con los procesos de la organizacin, sus opiniones sobre por qu ocurren las cosas, las soluciones que proponen y sus ideas para cambiar el proceso . Se emplean cuestionarios para obtener esta informacin cuando no es posible entrevistar, en forma personal, a los miembros de grupos grandes dentro de la organizacin. Asimismo, las investigaciones detalladas requieren el estudio de manuales y reportes, la observacin en condiciones reales de las actividades del trabajo y, en algunas ocasiones, muestras de formas y documentos con el fin de comprender el proceso en su totalidad. Conforme se renen los detalles, los analistas estudian los datos sobre requerimientos con la finalidad de identificar las caractersticas que debe tener el nuevo sistema, incluyendo la informacin que deben producir los sistemas junto con caractersticas operacionales tales como controles de procesamiento, tiempo de respuesta y mtodos de entradas y salidas.

2.3.4.3 Diseo del sistema El diseo de un sistema de informacin produce los detalles que establecen la forma en la que el sistema cumplir con los requerimientos identificados durante la fase de anlisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseo lgico en contraste con la de desarrollo de software a la que denominan diseo fsico. Los analistas de sistemas comienzan el proceso de diseo identificando los reportes y dems salidas que debe producir el sistema. Hecho lo anterior se determinan con toda precisin los datos especficos para cada reporte y salida.

38

El diseo de un sistema tambin indica los datos de entrada, aquellos que sern calculados y los que deben ser almacenados. Los documentos que contienen las especificaciones de diseo representan a ste de muc has maneras (diagramas, tablas, y smbolos especiales). La informacin detallada del diseo se proporciona al equipo de programacin para comenzar la fase de desarrollo de software.

En este trabajo de investigacin el diseo del sistema de informacin se efectuar utilizando para ello el Lenguaje de Modelado Unificado (UML), herramienta novedosa para el desarrollo de sistemas.

2.4 INGENIERA DE SOFTWARE

2.4.1 Definicin [6] La Ingeniera de Software es el establecimiento y uso de principios de la ingeniera para obtener econmicamente un software confiable y que funcione de modo eficiente en mquinas reales.

Es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software. Es decir, se considera que es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software, es decir, permite elaborar consistentemente productos correctos, utilizables y costo-efectivos.

La Ingeniera de Software es una tecnologa estratificada en cuatro partes:

39

Un enfoque de calidad: cualquier enfoque de la ingeniera (incluido el de la ingeniera de software) debe estar sustentado en un compromiso de calidad. Como por ejemplo: La Gestin de Calidad Total, Sigma Seis y otros enfoques similares que fomentan una cultura de mejora continua del proceso, y esta cultura es la que al final conduce al desarrollo de enfoques muy efectivos para la ingeniera de software. El proceso: el proceso del software forma la base para el control de la gestin de los proyectos de software y establece el contexto en el cual se aplican los mtodos tcnicos, se generan los productos del trabajo (modelos, documentos, datos, reportes, formatos, etctera), se establecen los fundamentos, se asegura la calidad, y el cambio se maneja de manera apropiada. Los mtodos: los mtodos abarcan un amplio espectro de tareas que incluyen la comunicacin, el anlisis de requisitos, el modelado del diseo, la construccin del programa, la realizacin de pruebas y el soporte. Los mtodos de la ingeniera del software se basan en un conjunto de principios bsicos que gobiernan cada rea de la tecnologa e incluye actividades de modelado y otras tcnicas descriptivas. Las herramientas: las herramientas de la ingeniera de software proporcionan el soporte automatizado o semi-automatizado para el proceso y los mtodos. Cuando las herramientas se integran de forma que la informacin que cree una de ellas pueda usarla otra, se dice que se ha establecido un sistema para el soporte del desarrollo del software.

40

2.4.2 Objetivos de la Ingeniera de Software [6]k Poseer la capacidad para procesar transacciones con rapidez y

eficiencia.k Mejorar la calidad de los productos de software. k Llevar a cabo el seguimiento de los costos de mano de obra, bienes y

gastos generales.k Aumentar la productividad y trabajo de los ingenieros del software. k Facilitar el control del proceso de desarrollo de software. k Ampliar la comunicacin y facilitar la integracin de funciones

individuales.k Suministrar a los desarrolladores las bases para construir software de alta

calidad en una forma eficiente.k Definir una disciplina que garantice la produccin y el mantenimiento de

los productos software desarrollados en el plazo fijado y dentro del costo estimado.

2.4.3 Objetivos de la Ingeniera de Software en los Proyectos de Sistemas [6] Para que los objetivos se cumplan las empresas emprenden proyectos por las siguientes razones:k Capacidad: las actividades de la organizacin estn influenciadas por la

capacidad de sta para procesar transacciones con rapidez y eficiencia. Los sistemas de informacin mejoran esta capacidad en tres formas:1 Aumentan la velocidad de procesamiento: Los sistemas basados en

computadoras pueden ser de ayuda para eliminar la necesidad de clculos

41

tediosos y comparaciones repetitivas. Un sistema automatizado puede ser de gran utilidad si lo que se necesita es un procesamiento acelerado.

9 Aumento en el volumen: La incapacidad para mantener el ritmo deprocesamiento no significa el abandono de los procedimientos existentes. Quiz stos resulten inadecuados para satisfacer las demandas actuales. En estas situaciones el analista de sistemas considera el impacto que tiene la introduccin de procesamiento computarizado, si el sistema existente es manual. Es poco probable que nicamente el aumento de la velocidad sea la respuesta. El tiempo de procesamiento por transaccin aumenta si se considera la c antidad de actividades comerciales de la empresa junto con su patrn de crecimiento.

9 Recuperacin ms rpida de la informacin: las organizacionesalmacenan grandes cantidades de datos, por eso, debe tenerse en cuenta donde almacenarlos y como recuperarlos cuando se los necesita. Cuando un sistema se desarrolla en forma apropiada, se puede recuperar en forma rpida la informacin.

Costo: esta capacidad mejora de la siguiente forma: 9 Vigilancia de los costos: para determinar si la compaa evoluciona en laforma esperada, de acuerdo con lo presupuestado, se debe llevar a cabo el seguimiento de los costos de mano de obra, bienes y gastos generales. La creciente competitividad del mercado crea la necesidad de mejores mtodos para seguir los costos y relacionarlos con la productividad individual y organizacional.

9 Reduccin de costos: los diseos de sistemas ayudan a disminuir los costos, yaque toman ventaja de las capacidades de clculo automtico y de recuperac in de datos que estn incluidos en procedimientos de programas en 4 2 dichas computadora. vas abarcan Muchas todo tareas el pas son y les realizadas permitenpor acelerar programas el flujo de decmputo, informacin lo

cual deja un nmero muy reducido de stas para su ejecucin manual, disminuyendo al personal. Control: esta capacidad posee las siguientes funciones para mejorar el

sistema:9 Mayor seguridad de informacin: algunas veces el hecho de que los datos

puedan ser guardados en una forma adecuada para su lectura por medio de una mquina, es una seguridad difcil de alcanzar en un medio ambiente donde no existen computadoras. Para aumentar la seguridad, generalmente se desarrollan sistemas de informacin automatizados. El acceso a la informacin puede estar controlado por un complejo sistema de contraseas, limitado a ciertas reas o personal, si est bien protegido, es difcil de acceder.9 Menor margen de error (mejora de la exactitud y la consistencia) : esto se

puede lograr por medio del uso de procedimientos de control por lotes, tratando de que siempre se siga el mismo procedimiento. Cada paso se lleva a cabo de la misma manera, consistencia y exactitud: por otra parte se efectan todos los pasos para cada lote de transacciones. A diferencia del ser humano, el sistema no se distrae con llamadas telefnicas, ni olvidos e interrupciones que sufre el ser humano. Si no se omiten etapas, es probable que no se produzcan errores. Comunicacin: la falta de comunicacin es una fuente comn de dificultades

que afectan tanto a cliente como a empleados. Sin embargo, los sistemas de informacin bien desarrollados amplan la comunicacin y facilitan la integracin de funciones individuales.9 Interconexin (aumento en la comunicacin): muchas empresas aumentan

sus vas de comunicacin por medio del de sarrollo de redes para este fin,

43

dentro de sus oficinas y otras instalaciones que no se encuentran en la misma localidad. Una de las caractersticas ms importantes de los sistemas de informacin para oficinas es la transmisin electrnica de informacin, como por ejemplo, los mensajes y los documentos.

9 Integracin de reas en las empresas: con frecuencia las actividades de lasempresas abarcan varias reas de la organizacin, la informacin que surge en un rea se ne cesita en otra rea, por ejemplo. Los sistemas de informacin ayudan a comunicar los detalles del diseo a los diferentes grupos, mantienen las especificaciones esenciales en un sitio de fcil acceso y calculan factores tales como el estrs y el nivel de costos a partir de detalles proporcionados por otros grupos.

2.4.4 Proceso de Ingeniera de Software [6] El proceso de Ingeniera del Software sigue etapas segn las que las necesidades del usuario que luego son traducidas en requerimientos del software, estos requerimientos son transformados en dis eo y el diseo es implementado en cdigo, el cdigo seguidamente es probado, documentado y certificado para uso operativo. Concretamente define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: k Concepcin: define el alcance del proyecto y desarrolla un caso de negocio. k Elaboracin: define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. k Construccin: crea el producto. k Transicin: transfiere el producto a los usuarios.

44

2.4.5 Fases de la Ingeniera de Software [6]

La ingeniera de software est dividida en las siguientes fases:

Anlisis y Especificacin de los Requerimientos: esta fase consiste enanalizar, entender y registrar el problema que el patrocinante est tratando de resolver. Los requerimientos son una descripcin de las necesidades o deseos de un producto. Un conjunto de requerimientos en estado de madurez, debe presentar una serie de caractersticas tanto individualmente como en grupo, as se tiene que un requerimiento debe ser:

9 Necesario: si su omisin provoca una deficiencia en el sistema a construir,y adems su capacidad, caractersticas fsicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o proceso.

9 Conciso: si es fcil de leer y entender. Su redaccin debe ser simple y clarapara aquellos que vayan a consultarlo en un futuro.

9 Completo: si no necesita ampliar detalles en su redaccin, es decir, si seproporciona la informacin suficiente para su comprensin.

9 Consistente: si no es contradictorio con otro requerimiento. 9 No ambiguo: cuando tiene una sola interpretacin. Diseo: consiste en crear una solucin que satisfaga las especificacionesdefinidas en la fase de anlisis. En esta fase se crea la interfaz de usuario y la estructura del software.

Codificacin: en esta fase se lleva a cabo la implementacin fsica delas bases de datos, de los programas (codificacin), prueba de unidad o procedimientos separado s y prueba de subsistemas o integracin.

45

Prueba del Sistema: los grupos de procedimientos de unidades prob comoadas elementos separados en la fase previa son comprobados como sistema durante la integracin.

Instalacin: corresponde a la fase de puesta en marcha de la aplicacin. Mantenimiento del Sistema y Mejoras: esta fase se corresponde al mantenimiento y mejoras futuras que deben contemplarse a la hora de implantar una aplicacin informtica, una vez que el sistema est en funcionamiento .

2.5 Programacin orientada a objetos

2.5.1 Definicin [7] La programacin orientada a objeto (POO) tiene la ventaja de ser un paradigma natural donde se pueden programar sistemas. Los seres humanos perciben el mundo como si estuviera formado por objetos: mesas, sillas, computadoras, coches, cuentas bancarias, partidos de ftbol, etc. Tambin es un instinto humano intentar organizar estos objetos disponindolos de una forma concreta, optando por destacar determinadas caractersticas de algunos objetos que los destacan de otros.

Los niveles de dichas categoras y los mtodos de clasificacin de objetos en el mundo son infinitos. La forma en que las personas clasifican las cosas depende, en gran medida, de lo que deseen hacer con ellas y las caractersticas que ms les llamen la atencin. A la vez que se agrupan los objetos atendiendo a esquemas de clasificacin, tambin se tiende a resaltar determinados atributos de objetos mostrando su preferencia sobre otros.

46

Esta idea de crear jerarquas de objetos relacionados se utiliza en la programacin orientada a objetos. En 1960, los investigadores ya observaron que muchas de las entidades del modelo de programas de computadoras se podan nombrar y que se podan describir sus propiedades y comportamiento. Se dieron cuenta de que los programas estaban relacionados con cuentas bancarias, matrices, archivos y usuarios; en definitiva, algo parecido a los objetos en el mundo real.

La programacin orientada a objetos se puede describir rpidamente como la identificacin de objetos importantes, su organizacin en jerarquas, la adicin de atributo s a los objetos que describen las caractersticas relevantes en el contexto del problema y de la adicin de las funciones (mtodos) a los objetos para realizar las tareas necesarias en el objeto. Los detalles son algo ms complejo, pero lo fundamental es que se trata de un proceso simple y natural. No obstante, que sea un proceso simple y natural no significa que sea sencillo, ya que un conjunto de objetos se podra clasificar de muchas formas distintas. La clave es la posibilidad de identificar los atributos importantes de objetos y formar abstracciones y jerarquas idneas. Incluso en el contexto de un dominio problemtico, a veces resulta bastante difcil determinar los niveles correctos de abstraccin y jerarquas de clasificacin correctas. Simplemente, la decisin de la clase o grupo al que un objeto pertenece puede ser una tarea bastante difcil.

2.5.2 Caractersticas de los Lenguajes Programacin Orientada a Objetos [7]

Los lenguajes de programac in orientada a objetos (como C++, C# y Java) se caracterizan por tres conceptos clave: encapsulacin, herencia y polimorfismo, que son compatibles con este aspecto natural de identificacin y clasificacin de objetos.

47

2.5.2.1 Encapsulacin La encapsulacin facilita la compresin de los grandes programas; la ocultacin de datos les hace ms eficaces. Los objetos pueden interactuar con otros objetos slo a travs de los atributos y mtodos del objeto que se muestran pblicamente. Cuantos ms atributos y mtodos se muestren pblicamente, ms difcil ser modificar la clase sin que ello afecte al cdigo que utiliza la clase. Una variable oculta se podra cambiar de un long a un double, sin que ello afecte al cdigo que utilicen los objetos creados (instanciados) de esa clase. El programador solo se debera preocupar por los mtodos en la clase que han tenido acceso a esa clase, en lugar de por todos los sitios en el programa que un objeto ha instanciado desde los que se puede llamar a la clase.

2.5.2.2 Herencia Proporciona dos ventajas evidentes a los programadores. La primera, y ms importante, es que permite crear jerarquas que expresen las relaciones entre los diferentes tipos. Imagine que tiene dos clases, CuentaAhorro y CuentaCorriente, que proceden de la clase principal Cuenta. Si tiene una funcin que necesite una clase Cuenta como argumento, podr pasarle una CuentaAhorro o una CuentaCorriente, ya que ambas clases son de tipos de Cuenta. Cuenta es una clasificacin general, mientras que CuentaCorriente y CuentaAhorro son tipos ms especficos.

La segunda ventaja es que las clases pueden heredar caractersticas ms generales de las clases superiores dentro de la jerarqua. En lugar de desarrollar nuevas clases a partir de cero, las clases nuevas podrn heredar las funciones de las clases existentes y, a continuacin, modificar o ampliar esta funcin. La clase princip al desde la que la nueva clase hereda las propiedades se conoce como la clase bsica y la nueva clase se denomina la clase derivada.

48

2.5.2.3 Polimorfismo Polimorfismo significa, fundamentalmente, que las clases pueden tenerel mismo comportamiento, pero implementarse de distintas maneras. Esto resulta muy til en trminos de programacin, ya que permite trabajar con tipos de objetos genricos cuando lo que interesa no es cmo implementa cada clase las funciones.

2.5.3 Clases y Objetos [7] Como su propio nombre lo indica, la programacin orientada a objetos est re lacionada con objetos. Un objeto se compone de datos que describen al objeto y las operaciones que se pueden realizar en el objeto. No obstante, cuando se crea un programa, en realidad se declaran y definen clases, no objetos.

Una clase es un tipo definido por el usuario, encapsula tanto los datos como los mtodos que funcionen en esos datos. Una clase es algo muy parecido a una plantilla, que se utiliza para crear (instanciar) objetos.

2.5.4 Ventajas de la Programacin Orientada a Objetos en el Ciclo de Vida de Desarrollo del Software [7]

Son tres las ventajas clave de la programacin orientada a objetos: compresin, reutilizacin del cdigo y posibilidad de ampliacin. La divisin del cdigo en clases contribuye a imponer una estructura a medida que crecen los programas. La idea es unir los programas orientados a objetos de clases escritas previamente, as como realizar las modificaciones necesarias para admitir los nuevos requisitos mediante la herencia para derivar nuevas clases a partir de las ya existentes. La creacin de sistemas a partir de componentes que se pueden volver a utilizar

49

conduc e, naturalmente, a una mayor productividad, que suele ser la ventaja ms citada de todos los mtodos orientados a objetos.

Las caractersticas de la programacin orientada a objetos tambin proporcionan varias ventajas. La encapsulacin facilita la escala de pequeos sistemas a grandes sistemas. En buena medida, independientemente del tamao del sistema, el programador simplemente est creando objetos.

Por ltimo, la posibilidad de ocultar datos tambin genera sistemas ms seguros. El estado de objetos slo se puede modificar mediante mtodos expuestos pblicamente; esto aumenta la posibilidad de predecir el comportamiento del objeto.

2.6 Proceso unificado de desarrollo de software

2.6.1 Definicin [8] El proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema de software. Sin embargo, el proceso Unificado es ms que un simple proceso; es un marco de trabajo genrico que puede especializarse para una gran variedad de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaos de proyecto.

El proceso Unificado est basado en componentes, lo cual quiere decir que el sistema software en construccin est formado por componentes de software interconectados a travs de interfaces bien definidas.

50

El proceso Unificado utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema software; de hecho UML es una parte esencial del proceso Unificado.

El proceso unificado de desarrollo nace en vista de la necesidad de crear un estndar para el desarrollo de software con la finalidad de satisfacer la creciente demanda de sistemas ms grandes, modernos y poderosos y que a su vez permita disminuir el tiempo de desarrollo de los mismos. Adems este proceso permite minimizar los riesgos de tener que codificar componentes que no sern utilizados correctamente o simplemente no son terminados. A travs de la historia se han desarrollado varios modelos de proceso de software (paradigmas de desarrollo) cada uno con sus ventajas, desventajas y utilidad en algunos tipos de proyectos y problemas. Al igual que cualquier notacin, el proceso unificado acta como un modelo que puede adaptarse a cualquier tipo de proyecto (grande y pequeo).

2.6.2 Principios Bsicos del Proceso Unificado de Desarrollo de Software [8] Los verdaderos aspectos definitorios del Proceso Unificado se resumen en tres frases claves: dirigidos por casos de uso, centrados en la arquitectura, iterativo e incremental. Esto es lo que hace nico al proceso Unificado. A continuacin se explican los principios bsicos del Proceso Unificado de Desarrollo de Software:

2.6.2.1 Proceso Unificado Dirigido por Casos de Uso Cuando un usuario utiliza el sistema, se lleva a cabo una interaccin que consiste en una secuencia de acciones (tanto por parte del usuario como del sistema) que proporcionan al usuario un resultado de valor importante para l. Un caso de uso 51

es precisamente una interaccin de ese tipo, que deriva en que el sistema debe incluir un fragmento de funcionalidad para proporcionar al usuario el resultado de valor esperado.

Por tanto, los casos de uso representan los requisitos funcionales del sistema, es decir, las necesidades de los usuarios y de la organizacin en donde se desplegar el sistema. Dicho con otras palabras, el modelo de casos de u so responde a la pregunta qu debe hacer el sistema para satisfacer a sus usuarios?

De nada sirve desarrollar un sistema muy avanzado tecnolgicamente pero que no cumple con las expectativas de los usuarios; un producto software se crea para dar servicio a sus usuarios. Durante todo el desarrollo hay que tener en cuenta los casos de uso, esto es, los casos de uso guan todo el proceso de desarrollo. La forma en que esto se lleva a cabo es desarrollando el sistema incrementalmente, aadiendo poco a poco fragmentos de funcionalidad para realizar un conjunto de casos de uso, y demostrando la validez del sistema, comprobando que la funcionalidad desarrollada realmente realiza esos casos de uso. En definitiva, los cas os de uso proporcionan el hilo conductor para avanzar en el desarrollo del software.

La captura de requisitos tiene dos objetivos: Encontrar los verdaderos requisitos y representarlos de un modo adecuado para los usuarios, clientes y desarrolladores. Los verdaderos requisitos son aquellos que cuando se implementen aadirn el valor esperado para los usuarios. Normalmente un sistema tiene muchos usuarios. Cada tipo de usuarios se representa por un actor. Los actores utilizan el sistema interactuando con los casos de usos. El modelo de casos de usos est compuesto por todos los actores y casos de uso de un sistema. 52

2.6.2.2 Un Proceso Centrado en la Arquitectura La arquitectura del software sirve para poder contemplar el futuro sistema desde varios puntos de vista antes de que se construya y durante la construccin El

concepto de arquitectura software incluye los aspectos estticos y dinmicos ms significativos del sistema, es decir, especifica la forma, estructura y comportamiento del sistema desde diversos puntos de vista, todos ellos a un nivel de detalle que permita tener una idea global clara sin perderse en detalles insignificantes (que, precisamente, no influyen en la arquitectura del sistema).

De esta forma quedan cubiertos los dos aspectos fundamentales del sistema: Qu hace el sistema para cada usuario? (casos de uso); Cmo es el sistema y cmo funciona para realizar esos casos de uso? (arquitectura de software). Ambas especificaciones se complementan y evolucionan en paralelo. Por un lado, los casos de uso deben encajar en la arquitectura del sistema cuando se lleven a cabo (adaptar los casos de uso a lo que la arquitectura permite); por otro lado, la arquitectura debe permitir la realizacin de todos los casos de uso (adaptar la arquitectura a lo requerido por los casos de uso).

En la prctica, la arquitectura se disea para permitir realizar los casos de uso, pero pueden existir limitaciones externas que obliguen a redefinir el modelo de casos de uso, dando lugar a un ciclo de realimentacin. Pero existen otros parmetros que influyen en la arquitectura: la plataforma y tecnologa de destino, componentes reutilizables disponibles, sistemas heredados y requisitos no funcionales (ver figura 2.4).

53

Figura 2.4. Proceso Centrado en la Arquitectura

2.6.3 Vida del Proceso Unificado [8] El proceso unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo consta de cuatro fases: inicio, elaboracin, construccin y transicin. En la figura 2.5 se puede visualizar las diferentes actividades: Requisitos, Anlisis, Diseo, Implementacin y Prueba que tienen lugar sobre las 4 fases: Inicio, Elaboracin, Construccin y Transicin.

Figura 2.5. Las actividades: Requisitos, Anlisis, Diseo, Implementacin y Prueba tienen lugar sobre las 4 fases: Inicio, Elaboracin, Construccin y Transicin.

54

Cada ciclo produce una nueva versin del sistema, y cada versin es un producto preparado para su entrega; consta de un cuerpo de cdigo fuente incluido en componentes que puede compilarse y ejecutarse, adems de manuales y otros producto s asociados. Sin embargo, el producto terminado no slo debe ajustarse a las necesidades de los usuarios, sino tambin a las de todos los interesados, es decir, toda la gente que trabajar con el producto. El producto terminado incluye los requisitos, casos de uso, especificaciones no funcionales y casos de prueba. Incluye el modelo de la arquitectura y el modelo visual (artefactos modelados con el UML).

2.6.4 Descripcin de las fases del proceso unificado de desarrollo del software

2.6.4.1 Fase de Inicio En esta fase se desarrolla una descripcin del producto final a partir de una buena idea y se presenta el anlisis de negocio para el producto. Esencialmente esta fase responde a las siguientes preguntas: 1. Cules son las principales funciones del sistema para sus usuarios ms importantes? 2. Cmo podra ser la arquitectura del sistema? 3. Cul es el plan de proyecto y cunto costar desarrollar el producto? La respuesta a la primera pregunta se encuentra en un modelo de casos de uso simplificado que contenga los casos de uso ms crticos. Una vez obtenidos, la arquitectura es provisional, y consiste tpicamente en un simple esbozo que muestra los subsistemas ms importantes. En esta fase, se identifican y priorizan los riesgos ms importantes, se planifica en detalle la fase de elaboracin, y se estima el proyecto de manera aproximada.

55

2.6.4.2 Fase de Elaboracin Durante esta fase se especifican en detalle la mayora de los casos de uso del producto y se disea la arquitectura del sistema. La relacin entre la arquitectura del sistema y el propio sistema es primordial. Por tanto la arquitectura se expresa en forma de vistas de todos los modelos del sistema, los cuales juntos representan al sistema entero. Esto implica que hay vistas arquitectnicas del modelo de casos de uso, del modelo de anlisis, del modelo de diseo, del modelo de implementacin y modelo de despliegue. La vista del modelo de implementacin incluye componentes para probar que la arquitectura es ejecutable. Durante esta fase del desarrollo, se realizan los casos de uso ms crticos que se identificaron en la fase de inicio. El resultado de esta base es la lnea base de la arquitectura.

2.6.4.3 Fase de Construccin En esta fase se crea el producto, la lnea base de la arquitectura crece hasta convertirse en el sistema comp leto. La descripcin evoluciona hasta convertirse en un producto preparado para ser entregado a la comunidad de usuarios. El grueso de los recursos requeridos se emplea durante esta fase del desarrollo. Sin embargo la arquitectura del sistema es estable, aunque se pueden describir formas mejores de estructurar el sistema. Al final de esta fase, el producto contiene todos los casos de uso que la direccin y el cliente han acordado para el desarrollo de esta versin. Sin embargo, puede que no est completamente libre de defectos. Muchos de estos defectos se descubrirn y solucionarn durante la fase de transicin.

2.6.4.4 Fase de Transicin Durante esta fase se cubre el perodo durante el cual el producto se convierte en versin beta. En la versin beta un nmero reducido de usuarios con experiencia

56

prueba el producto e informa de defectos y deficiencias. Esta fase conlleva actividades como la fabricacin, formacin del cliente, el proporcionar una lnea de ayuda y asistencia, y la correccin de los defectos que se encuentren tras la entre ga.

2.6.5 Flujos del Proceso Unificado de Desarrollo de Software [8] Los flujos fundamentales: Requisitos, Anlisis, Diseo, Implementacin y Pruebas, se distinguen entre los flujos de trabajos fundamentales e iterativos. Dichos flujos no ocurren una sola vez, en el Proceso Unificado de Modelado, como sucede tericamente en el modelo en cascada; sino que se repiten ms bien en cada iteracin, una y otra vez, como flujos de trabajos iterativos. Cada repeticin, sin embargo, se diferencia en los detalles que se enfrentan o asuntos centrales de cada iteracin.

2.6.5.1 Requisitos El esfuerzo principal en la fase de requisitos es desarrollar un modelo del sistema que se va a construir, y la utilizacin de los casos de uso en una forma adecuada de crear este modelo. Esto es debido a que los requisitos funcionales se estructuran de forma natural mediante casos de uso, y a que la mayora de los otros requisitos no funcionales son especficos de un solo caso de uso, y pueden tratarse en el contexto de ese caso de uso. As, los requisitos de un sistema se capturan en forma de: Un modelo del negocio o un modelo del domini o para establecer el contexto del sistema. Un modelo de casos de uso que capture los requisitos funcionales, y los no funcionales que son especficos de casos de uso concretos. El modelo de casos de uso se realiza mediante una descripcin general, un conjunto de diagramas, y una descripcin detallada de cada caso de uso.

57

Un conjunto de esbozos de interfaces de usuario y de prototipos de cadaactor, que

representan el diseo de las interfaces de usuario. Una especificacin de requisitos adicionales para los requisitos que songenricos y no especficos de un caso de uso en particular.

Estos resultados son un buen punto de partida para los siguientes flujos de trabajos: anlisis, diseo, implementacin y prueba. Los casos de uso dirigirn el trabajo a lo largo de estos flujos de trabajo iteracin por iteracin. Para cada caso de uso del modelo de casos de uso identificaremos una realizacin de caso de uso correspondiente en las fases de anlisis y diseo y un conjunto de casos de prueba en la fase de pruebas. Por tanto, los casos de uso enlazaran directamente los diferentes flujos de trabajo.

2.6.5.2 Anlisis Durante el anlisis, estudiamos los requisitos que se describen en la captura de requisitos, refinndolos y estructurndolos. El resultado del flujo de trabajo del anlisis es el modelo de anlisis, que es un modelo del objeto conceptual que analiza los requisitos mediante su refinamiento y estructuracin. El modelo de anlisis inc luye los siguientes elementos:

Paquetes del anlisis y paquetes de servicio, y sus dependencias ycontenidos. Los paquetes de anlisis pueden aislar los cambios en un proceso del negocio, el comportamiento de un actor, o en conjunto de casos de uso estrechamente relacionados. Los paquetes de servicios aislarn los cambios en determinados servicios ofrecidos por el sistema, y construyen un elemento esencial para construir pensando en la reutilizacin durante el anlisis.

58

Clases de anlisis, sus responsabilidades, atributos, relaciones y requisitos especiales. Cada una de las clases de control, entidad e interfaz aislaran los cambios al comportamiento y la informacin que representan. Un cambio en la interfaz de usuario o en una interfaz de comunicacin normalmente se ubica en una o ms clases de entidad; un cambio en el control, coordinacin, secuencia, transacciones y a veces en la lgica del negocio compleja, que implica a varios objetos (de interfaz y/o de entidad) normalmente se ubica en una o ms clases de control. Realizaciones de casos de uso-anlisis que describen como se refinan los casos de uso en trminos de colaboraciones dentro del modelo de anlisis y de sus requisitos especiales. La realizacin de casos de uso aislaran os cambios en los casos de uso, debido a que si cambia un caso de uso, debe cambiarse tambin su realizacin. La vista arquitectura del modelo de anlisis, incluyendo sus elementos significativos para la arquitectura. La vista de la arquitectura aislara lo s cambios de la arquitectura. El modelo de anlisis se considera la entrada fundamental para las actividades de diseo subsiguientes. Cuando utilizamos el modelo de anlisis con esa intencin, conservamos en todo lo posib le la estructura que define durante el diseo del sistema, mediante el tratamiento de la mayor parte de los requisitos no funcionales y otras restricciones relativas al entorno de la implementacin. Ms en concreto, el modelo de anlisis influir en el modelo de diseo de las siguientes maneras:

59

y' Los paquetes del anlisis y los paquetes de servicios tendrn una influencia fundamental en los subsistemas de diseo y en los subsistemas de servicios, respectivamente, en las capas especficas y generales de la aplicacin. En muchos casos tendremos una traza uno a uno entre paquetes y los correspondientes subsistemas. y' Las clases del anlisis servirn como especificaciones al disear las clases. Se requieren diferentes tecnologas y habilidades al disear clases del anlisis con diferentes estereotipos: por ejemplo, el diseo de las clases de entidad normalmente requiere el uso de tecnologas de bases de datos, mientras que el diseo de clases de interfaz normalmente requiere el uso de tecnologas de interfaz de usuario. Sin embargo, las clases del anlisis y sus responsabilidades atributos y relaciones sirven como una entrada lgica par la creacin de las correspondientes operaciones, atributos y relaciones de las clases de diseo. Adems, la mayora de los requisitos especiales recogidos sobre una clase del anlisis sern tratados por las clases de diseo correspondientes cuando se tienen en cuenta tecnologas como las de bases de datos y de interfaces de usuarios. y' Las realizaciones de casos de uso anlisis tienen dos objetivos principales. Uno es ayudar a crear especificaciones ms precisas para el caso de uso. En lugar de detallar cada caso en el modelo de casos de uso con diagramas de estado o diagramas de actividad. La descripcin de un caso de uso mediante una colaboracin entre clases del anlisis da como resultado una especificacin formal completa de los requisitos del sistema. Las realizaciones de casos de uso-anlisis tambin sirven como entrada al diseo de los casos de uso.

60

La vista de la arquitectura del modelo de anlisis se utiliza como entrada en la creacin de la vista de la arquitectura del modelo de diseo. Es muy probable que los elementos de las diferentes vistas (de los diferentes modelos) tengas trazas entre ellos. Esto es debido a que la relacin de relevancia para la arquitectura tiende a fluir suavemente a lo largo de los diferentes modelos mediante diferencias de traza.

2.6.5.3 Diseo En el diseo se modela el sistema y se encuentra la forma para que soporte los requisitos que se suponen. El principal resultado del diseo es el modelo de diseo. Se esfuerza en conservar la estructura del sistema impuesta por el modelo de anlisis, y que s irve como esquema para la implementacin. El modelo de diseo incluye los siguientes elementos: Subsistemas del diseo y subsistemas de servicio y sus dependencias, interfaces y contenidos. Los subsistemas del diseo de las dos capas superiores (las capas especficas de la aplicacin) se obtienen a partir de los paquetes del anlisis algunas de las dependencias entre subsistemas del diseo se obtienen a partir de las correspondientes dependencias entre paquetes del anlisis. Algunas de las interfaces se obtienen a partir de las clases del anlisis. Clases del diseo, incluyendo las clases activas, y sus operaciones, atributos y requisitos de implementacin. Algunas clases del diseo relevantes para la arquitectura se obtienen a p artir de las clases del anlisis relevante para la arquitectura. Algunas clases activas se obtienen a partir de clases del anlisis se utilizan como especificaciones al obtener las clas es de diseo. Realizaciones de casos de uso-diseo, que describen como se disean lo s casos de uso en trminos de colaboraciones dentro del modelo de diseo. En general, al obtener las realizaciones de caso de uso-diseo utilizamos las realizaciones de caso de uso-anlisis como especificaciones.

61

La vista arquitectnica del modelo de diseo, incluyendo esos elementossignificativos de cara a la arquitectura.

2.6.5.4 Implementacin El resultado principal de la implementacin es el modelo de la implementacin, el cual incluye los siguientes elementos:

Subsistemas de implementacin y sus dependencias, interfaces y contenidos. Componentes, incluyendo componentes ficheros y ejecutables, y las dependencia entre ellos. Los componentes son sometidos a pruebas de unidad.

Las vista de la arquitectura del modo de implementacin, incluyendo suselementos arquitectnicamente significativos. La implementacin tambin produce como resultado un refinamiento de la vista de la arquitectura de modelo de despliegue, donde los componentes ejecutables son asignados a nodos. El modelo de implementacin es la entrada principal de las etapas de pruebas que siguen a la implementacin, ms concretamente, durante la a de etapprueba cada construccin generada durante la implementacin es sometida a pruebas de implementacin, y posiblemente tambin a pruebas del sistema.

2.6.5.5 Pruebas El resultado principal de la prueba es el modelo de prueba, el cual describe como ha sido probado el sistema. El modelo reprueba incluye:

Casos de prueba, que especifican que probar en sistema. Procedimientos de prueba, que especifican como realizar los casos de pruebas. Componentes de pruebas, que automatizan los procedimientos de pruebas.

62

La prueba da tambin como resultado un plan de prueba, evaluaciones de las pruebas realizadas y los defectos que pueden ser pasados como entrada a flujos de trabajos anteriores, como el diseo y la implementacin.

2.6.6 Flujos de Trabajos para una Iteracin [8] Cada iteracin e st formada por cinco grupos de flujos de trabajos fundamentales, estos flujos se adaptan segn sea la fase para la cual se est desarrollando. En la figura 2.6, se observa cmo, para una iteracin de cualquier fase, coexisten los cinco flujos de trabajos.

Figura 2.6. Los cinco (5) flujos de trabajo Requisitos, Anlisis, Diseo, Pruebas e Implantacin.

2.6.7 Ventajas del Proceso Unificado de Desarrollo de Software [8] La Iteracin controlada acelera el ritmo de esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan de manera ms eficiente para obtener resultados claros a corto plazo. La iteracin controlada reconoce una realidad que a menudo ignora que las necesidades del usuario y sus correspondientes requisitos no pueden definirse completamente al principio. Mediante proceso unificado racional los requisitos se adquieren y refinan en sucesivas iteraciones.

63

En cada fase del proceso unificado se genera un producto; as mismo eldesarrollo de cada fase puede contener algunos de los siguientes modelos: requisitos, anlisis, diseo, implementacin, despliegue y pruebas.

Los modelos son ideales porque mediante stos se representa el trabajoevolutivo que desarrollan los ingenieros de software; y no incluye un producto final, como lo es la versin Beta del sistema; es decir no se requiere esperar la culminacin del trabajo para observar un producto.

Los modelos juntos representan al sistema como un todo. El proceso unificado est basado en componentes; y utiliza el estndar delle nguaje unificado de modelado para llevar a cabo sus modelos.

2.6.8 Desventaja del Proceso Unificado de Desarrollo de Software [8] A pesar de sus caractersticas de adaptabilidad y flexibilidad, el Proceso Unificado no permite representar en su totalidad los elementos representativos de los agentes, los cuales son: habilidad social, autonoma, reactividad, pro-actividad, nociones mentales, adaptabilidad o aprendizaje, veracidad, racionalidad.

2.7 LENGUAJE UNIFICADO DE MODELADO (UML)

2.7.1 Definicin [9] El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual de propsito general que es usado para especificar, visualizar, construir y documentar los artefactos de un sistema software (Jacobson I., Booch G. y Rumbaugh J, 2000). El UML captura informacin acerca de la estructura esttica y el comportamiento dinmico de un sistema. Un sistema es