UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

FACULTAD DE TECNOLOGIA

ING. INFORMATICA

Sistema de Informacin para Gestionar seleccin de profesores y creacin de grupos y horarios en el rea acadmica del Departamento de Programa de Admisin Bsica (P.A.B.) de la Universidad Autnoma Gabriel Ren Moreno MATERIA: SISTEMAS DE INFORMACION I GRUPO: 16

DOCENTE: Ing. Anglica Garzn Cuellar ALUMNOS:

SANDRA AEZ VACA

200754335

RODNEY CESPEDES ESPINOZA 200707256

MARIELA GONZALES SEGOVIA 200753533

FECHA: 04/ 12 / 09

SANTA CRUZ - BOLIVIA

ndice

1. Perfil4 1.1. Introduccin 41.2. Objetivos6 1.2.1. Objetivo general6 1.2.2. Objetivos especficos6 1.3. Antecedentes 8 1.4. Estructura Organizacional11 1.5. Problemtica12 1.5.1. Descripcin del problema12 1.5.2. Formulacin del problema141.6. Alcance15 1.6.1. Requerimientos Funcionales15

1.6.2. Requerimientos No Funcionales16 1.7. Entrevistas171.8. Elementos del Sistema261.9. Metodologa Ishikawa31 1.9.1. Identificar el Problema31 1.9.2. Identificar Principales Categoras32

1.9.3. Identificar Causas33

1.9.4. Anlisis y Conclusin35

2. Marco Terico36 2.1. Lenguaje Unificado de Modelado-UML36 2.1.1. Vocabulario de UML41 2.1.2. Aspecto Esttico y Dinmicos47 2.1.3. Diagrama de Clases48 2.1.4. Diagrama de Casos de Uso51 2.1.5. Diagrama de Objetos55 2.1.6. Diagrama de Componentes57 2.1.7. Diagrama de Distribucin59 2.1.8. Diagrama de Actividades59 2.1.9. Diagrama de Estados61 2.1.10. Diagrama de Colaboracin61 2.1.11. Diagrama de Secuencia62 2.2. Proceso Unificado de Desarrollo de Software-P.U.D.S. 64 2.2.1. Fases65 2.2.2. Flujo de Trabajo66 2.2.3. Caractersticas del Modelo69 2.2.4. Las Cuatro Ps71 2.2.5. Flujo de Trabajo (Requisitos y Anlisis) 713. Modelo de Diseo78 3.1. Identificar Clases78 3.2. Identificar Conexin de Instancia82 3.3 Diagrama de Dominio84 3.4. Construccin de la Base de Datos85 3.4.1. Diseo Lgico85 3.4.1.1. Diagrama de Clases86 3.4.1.2 Mapeo87 3.4.2. Diseo Fsico92 3.4.2.1. Tabla de volumen92 3.4.2.2. Script98 3.4.2.3. Diagrama Relacional104 3.5. Manipulacin de Tuplas106 3.6. Consultas118 3.7. Procedimientos Almacenados1204. Anlisis y Diseo de Sistema124 4.1. Modelo de Negocio124 4.1.1. Diagrama de Actividad124 4.1.1.1. Seleccin de Profesor124 4.1.1.2. Verificacin de Aulas Disponibles125 4.1.1.3. Programacin de Horarios126 4.1.2. Diagramas de Caso de Uso127 4.1.2.1. Identificar Casos de Uso y Actores127 4.1.2.2. Priorizacin de Casos de Uso129 4.1.2.3. Detallar Casos de Uso130 4.1.2.3.1. Disear Caso de Uso130 4.1.2.3.2. Prototipar Caso de Uso137 4.1.2.3.3. Detalle Caso de Uso139 4.1.2.4. Diagrama General de Caso de Uso1505. Anlisis de la Arquitectura151 5.1. Identificar Paquetes151

5.2. Vista de Paquetes152 5.3. Vista de Escenario154 5.4. Implementacin155 5.5. Diagrama de Componentes157 5.6. Implementacin de Arquitectura de Paquetes1586. Plataforma de Desarrollo160 6.1. Sistema Operativo160 6.2. Base de Datos160 6.3. Lenguaje de Programacin1617. Conclusin1628. Recomendacin1639. Bibliografa16410. Anexos1651. Perfil

1.1. Introduccin La U.A.G.R.M. como una poltica de ingreso de postulantes bachilleres, de acuerdo a Resolucin I.C.U. 09/90, la 21(B)/91, la 084/93 y la 041/03 implant la creacin y funcionamiento del Programa de Admisin Bsica (P.A.B.) como un eficaz mecanismo pedaggico de evaluacin y actualizacin de conocimientos, para un adecuado inicio del proceso de profesionalizacin.

Es de conocimiento pblico que el P.A.B. curso organizado por la UAGRM, es una actividad acadmica seria y planificada que busca alcanzar niveles adecuados de preparacin para el postulante a la UAGRM y que a travs de los aos se ha mejorado, alcanzando un nivel de madurez y seriedad. Con apoyo del equipo de COORDINADORES designados por la UAGRM quienes planifican y apoyan toda la actividad acadmica, en dicho PAB se apoya a los postulantes con:

Clases de repaso y actualizacin.

Textos elaborados y publicados por la UAGRM.

Banco de preguntas.

Prcticos y clases de apoyo.

El P.A.B. se constituye en un instrumento que permite preparar al estudiante convenientemente con la finalidad de encarar con xito su formacin profesional.

Para el logro de todos sus objetivos el departamento del P.A.B. se encarga de la seleccin de profesores calificados que estn dirigidos por un coordinador en cada rea, adems existe un encargado acadmico el cual programa los grupos y horarios; que se ofertan a los postulantes del P.A.B. Toda la informacin que el departamento necesita es registrada en libros y en planillas hechas en Excel, lo que ha llevado, en varias ocasiones, a prdidas y errores en los datos que se manejan. Tambin ocasiona perdidas de tiempo y mucho papeleo al momento de querer sacar informes. Debido a esto el departamento del P.A.B, ha optado por automatizar el control de la informacin que necesita para cumplir con sus objetivos.1.2. Objetivos

1.2.1. Objetivo GeneralDesarrollar un Sistema de Informacin para Gestionar seleccin de profesores y creacin de grupos y horarios en el rea acadmica del Departamento de Programa de Admisin Bsica (P.A.B.) de la Universidad Autnoma Gabriel Ren Moreno. 1.2.2. Objetivos Especficos Recolectar informacin del funcionamiento del Departamento mediante diferentes entrevistas y cuestionarios realizados a los funcionarios del departamento del P.A.B. Realizar la asignacin de profesores a los grupos ya programados de acuerdo a su especialidad o formacin acadmica tomando en cuenta los horarios de los grupos. Crear distintas vistas y acceso de informacin para los diferentes usuarios. Almacenar informacin actualizada de los profesores que estn trabajando en esa gestin.

Realizar la programacin de aulas para el da de la prueba. Controlar la creacin de grupos y horarios de acuerdo a los cupos y aulas que se disponen. Desarrollar la programacin de los grupos por turno, intercalando materias fuertes con materias dbiles, es ms las materias fuertes irn despus de una dbil. Utilizaremos herramientas de programacin VISUAL BASIC.1.3. AntecedentesLas polticas de Admisin de nuevos estudiantes en la Universidad Boliviana fueron aprobadas en el VII Congreso Nacional de Universidades, realizado en la ciudad de Potos, y homologadas en la Universidad Autnoma Gabriel Ren Moreno mediante Resolucin del Ilustre Consejo Universitario N084/93, del 09 de diciembre de 1993, donde se contempla claramente dos modalidades de ingreso para los bachilleres que deseen continuar sus estudios para adquirir una profesin.

Primera Modalidad.- Consiste en el ingreso en el primer semestre de cada gestin acadmica, a travs del examen de la Prueba de Suficiencia Acadmica (P.S.A.) que se realizan todos los aos equivalentes al 50% y el otro 50% corresponde a las notas adquiridas por el estudiante durante los ltimos tres aos de nivel secundario.

Segunda Modalidad.- Es el Programa de Admisin Bsica (P.A.B.), que consiste en el ingreso de los estudiantes a travs de un curso de capacitacin, preparacin y actualizacin de conocimientos orientado a la carrera a la cual postulo. Los estudiantes que aprueban este curso, pueden realizar su inscripcin en la carrera elegida en el segundo periodo de la gestin acadmica, estos estudiantes ocuparan las plazas de los alumnos que pasaron al segundo semestre.

A las dos modalidades de ingreso ya nombradas, se ha sumado una tercera: que consiste en el ingreso directo a la U.A.G.R.M. de el mejor bachiller de todos los colegios del departamento de Santa Cruz, luego el ICU fue incrementando esta cantidad a 2 despus a 5 y actualmente es de 10 estudiantes por colegio del Departamento de Santa Cruz, entendiendo por mejores bachilleres a los estudiantes que hayan obtenido el mayor promedio acumulado en los ltimos 3 aos del ciclo secundario con una nota mayor o igual 55/70 puntos como indica en la Resolucin I. C. U. 005/97, del 20 de febrero de 1997.

Hace 14 aos que la U.A.G.R.M. aplica las modalidades de P.S.A. al inicio de cada ao acadmico y P.A.B. para el segundo semestre de cada ao acadmico.

A partir del ao 2006, basados el la Resolucin I.C.U. 05/2006 artculo # 40, y su respectiva reglamentacin, faculta a la Unidad del PAB/PSA. Como la nica autorizada a organizar cursos de Nivelacin o Preparacin para los bachilleres que postularn a la P.S.A. dentro de la UAGRM. Actividad que antes de la resolucin (cursos de nivelacin) era desarrollada por INSTITUTOS privados y algunos Centros Internos con fines de lucro.

Sin embargo esta actividad acadmica nunca fue organizada con la seriedad, planificacin, transparencia y calidad que el caso requiere, convirtindose, en algunos casos, en un atractivo negocio de extorsin y estafa a los postulantes a la UAGRM.

El Programa de Admisin Bsica (P.A.B.), es una de las modalidades de ingreso a la Universidad Autnoma Gabriel Rene Moreno, que consiste en un curso pre-universitario y tiene por objetivo actualizar, reforzar y nivelar a los postulantes sobre los conocimientos recibidos en la enseanza del nivel secundario. Los alumnos que aprueben este curso, pueden realizar su inscripcin a la carrera elegida en la siguiente gestin acadmica que se inicia. El departamento del P.A.B. se encuentra localizado en el campus universitario de la Universidad Autnoma Gabriel Rene Moreno, entre las calles Mxico y Centenario, de la ciudad de Santa Cruz de la Sierra, mas especifico en el pabelln 145; Telfono 3365544 int. 2606, Telfono Fax 3340106, Casilla de correo N 702, E-mail pab@uagrm.edu.bo, Web http://pab.uagrm.info/.

Presta atencin en horarios de oficina de lunes a viernes.

1.4. Estructura OrganizacionalESTRUCTURA ORGNICA DEL DEPARTAMENTO PAB/PSA - UAGRM

1.5. Problemtica1.5.1. Descripcin del Problema Registran la documentacin manualmente y en un libro. Cuando necesitan algn dato de un docente deben revisar los archivos. Utilizan Microsoft Excel para gestionar todo tipo de informacin que manejan, primeramente registrado en distintos cuadernos. Al momento de la creacin de grupos y horarios hay cruces de aulas, porque no cuentan con una base de datos que les de informes de aquellas aulas que estn habilitadas para pasar clases. La seleccin de profesores no es adecuada, ya que muchas veces hay profesores que dictan materias que no corresponden a su rea. Necesitan un sistema que pondere a cada profesor que presenta su hoja de vida de acuerdo a su conocimiento para ser seleccionado. No cuentan con un registro de profesores pre-seleccionados en el caso de que algn profesor que por fuerza mayor no pueda dictar sus clases, habiendo sido ya contratado. El departamento contrata a cierto personal, que se encarga del control de asistencia de los profesores, esto lo hacen de manera manual. En el caso de las provincias, existe un encargado que necesariamente tiene que venir al departamento central para la seleccin de los profesores. En el momento de que ingresa algn documento en el departamento no hay una constante que apoye esto. Los contratos para los profesores tienen un mismo formato y se necesita un sistema que pueda generarlo cuando el profesor ya fue seleccionado, y no como en la actualidad lo hacen uno por uno manualmente. El departamento no tiene conocimiento de la cantidad de alumnos que ingresaron al P.A.B., este debe pedir informes al C.P.D. Para la toma de exmenes el P.A.B. requiere a dos docentes de planta registrados y en vigencia que tomaran la prueba, algunos hacen caso omiso a la invitacin y es por ello que hay grupos que no tienen docentes ese da; el departamento no cuenta con una cifra exacta de dichos docentes. No todos los profesores y los docentes que se encargan de la toma de pruebas cuentan con credenciales que los identifiquen como tales, siendo este un requisito para el ingreso a la universidad. Deficiencia en la recoleccin y manejo de archivos. Cuentan con un sistema de archivos que no cumple con sus requerimientos. Falta comunicacin con los profesores. A veces las boletas de los alumnos inscritos salen sin grupos o materias incompletas. No cuentan con un sistema contable ni de inventario. En el momento de la inscripcin no entregan los textos y a veces no hay suficientes para todos, tanto as que hay alumnos que dan examen sin tener el material, a aquellos que entregan los listan con nombre y cedula de identidad en hojas y manualmente. Han sufrido en varias ocasiones perdida de informacin y de archivos por falta de orden. A veces se necesita ubicar a los profesores con urgencia, pero no se lo puede realizar debido a que no se cuenta con datos actualizados de ellos. La manipulacin de la informacin que tiene cada docente registrada en las tablas de Excel, cuenta con fcil acceso, esto ocasiona que cualquier funcionario pueda modificar dicha informacin.1.5.2. Formulacin del ProblemaEl problema se refleja en el manejo manual de la seleccin de profesores y la creacin de grupos y horarios, entonces viendo estas deficiencias el factor ms importante es poder contar con un sistema que gestionara informacin de los profesores que dictan materias y de aquellos que pueden llegar a sustituir a algn profesor, si se lo requiriera adems de contar con datos precisos que ayudaran en la creacin de horarios; as de esta forma abra mejor organizacin en la informacin.1.6. Alcance

1.6.1. Requerimientos FuncionalesRf1.-Gestionar datos o documentos que presentan los profesores: Nombre, carnet de identidad, solicitud de docencia, hoja de vida, fotocopia del ttulo legalizado, fotocopia de su NIT.

Rf2.-Controlar las aulas disponibles tanto para las clases regulares como tambin para el da de los exmenes, mediante reportes.

Rf3.-Realizar Reportes Sencillos para brindar informacin que facilite la gestin de archivos y as se organicen ms fcilmente

Rf4.-Control De Variedad de Materias en la programacin de grupos, garantizando que no se crucen materias de la misma rea en un mismo turno del horario que se le d a los grupos que se programen ej. Lunes Historia, Orientacin Vocacional y Matemticas Rf5.-Tener una Actualizacin Constante De Datos De Docentes en cada gestin, para as ampliar la Cantidad de la Base De Datos De Docentes y as tener una referencia rpida en caso de que algn docente no pueda cumplir por algn motivo y se tenga que Buscar Reemplazos y estos datos sean actuales.

Rf6.- Controlar la asistencia de los docentes en horarios de Clases.Rf7.-Asignarle a los docentes Una Materia De acuerdo a la especialidad que tengan, segn el rea en la que se encuentre Su profesin.

Rf8.-Controlar Las Vistas y Usuarios de manera que no todos tengan acceso a la modificacin de informacin sin contrasea, pero si a la visualizacin de la informacin que se requiera

Rf9.-Gestionar la seleccin de docentes de acuerdo a sus conocimientos con una ponderacin basada en su hoja de vida.

1.6.2. Requisitos No Funcionales

Todo el sistema lo realizaremos en el lenguaje VISUAL BASIC .NET Utilizaremos Como Herramienta el Sistema Gestor de Base de Datos SQL Server. Para Elaborar Los Diagramas De Clases usaremos la Herramienta Start UML.

1.7. Entrevistas Entrevista al los trabajadores del departamento del P.A.B.Fecha: 28/08/091.- Cmo, porque y de quienes nace la iniciativa de crear el departamento del pab?Entrevistado: RODOLFO BUSTILLOS

Cargo: ENCARGADO ADMINISTRATIVO Y FINANCIEROHace 13 aos en1992 cada facultad generaba su ingreso de alumnos y no lo hacan en forma discrecional a veces tenan alrededor de 500 a 600 alumnos por semestre de ah nace el pab q es la prueba de admisin bsica que se encarga de normalizar todo eso.

Entrevistado: VIVIANA ROSARIO SANTOSCargo: ENCARGADO ACADEMICODesde Un inicio y Mediante la resolucin que deca que de acuerdo a la masificacin y remuneracin de tantos estudiantes hace que aparezca como departamento se cre en 1991

Entrevistado: DARWIN VELEZ SORIACargo: ASISTENTE FINANCIERONace porque la universidad necesita tener un mecanismo que introduzca a todos los postulantes preuniversitarios de colegio que egresan cada ao2.- Qu objetivos a largo, mediano o corto plazo tiene?Entrevistado: RODOLFO BUSTILLOS Cargo: ENCARGADO ADMINISTRATIVO Y FINANCIEROTodo es a largo plazo porque esto es para que se quede se genero esta unidad mas con la de orientacin para que quede a largo plazo porque son los que directamente hacen la generacin de entrada de lo que son los preuniversitarios la gente que sale de formacin estudiantilEntrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOSu objetivo es hacer pruebas para el ingreso simplemente En objetivos acadmicos hoy en da ya mucho mas estructurado y especificando bien la metodologa de que tenga un plan acadmico u enfocar eso en un sistemaEntrevistado: DARWIN VELEZ SORIACargo: ASISTENTE FINANCIEROEl objetivo a corto plazo seria Una Base de datos para tener un registro sistematizado, automatizado digital Que tengamos para que sea de uso presente y futuro3.- de qu formas invitan o hacen conocer a los docentes la postulacin para dictar las clases, que medios utilizan para hacerlo Entrevistado: RODOLFO BUSTILLOS Cargo: ENCARGADO ADMINISTRATIVO Y FINANCIERO Se le manda a cada facultad actas licitacin para que se genere todo esto ellos son los que nos mandan sus catedrticos pero dependiendo de cuanto ganen, que no pase de la ley financial casi la mayora pasa de la ley financial por eso es q no tenemos catedrticos dentro del pab son pocos los que nos sobresalen, porque son ms los que ganan ms de 7000 Bs.Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOEn realidad cuando inicie aqu trabajando se lanzaba la convocatoria aqu afuera del pab aqu en la salida se pona un letrero porque los docentes frecuentemente venan d visita no se lo haca pblica por que los medios que se utilizan simplemente se lanzan en una convocatoria cerrada.

Actualmente ya no hay convocatoria trabajamos digamos solo con ese grupo de docentes de los que ya tenemos formados ya que se quedan como docentes de planta

Entrevistado: DARWIN VELEZ SORIACargo: ASISTENTE FINANCIEROSe invita por medio de una convocatoria, se lo hace pblico mediante el vicerrectorado ya que este se encarga del departamento del PAB y se comunica a los docentes de sistema universitario que estn interesados a q manden una carta de solicitud de docencia, luego el director de la unidad lo evala y luego se lo llama para comunicarle que est habilitado.4.- Cules son los requisitos que presenta un profesor postulante?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOEntrevistado: RODOLFO BUSTILLOSCargo: ENCARGADO ADMINISTRATIVO Y FINANCIEROEntrevistado: DARWIN VELEZ SORIACargo: ASISTENTE FINANCIEROLos Requisitos Son:

-Solicitud de docencia

-Fotocopia carnet de identidad

-Hoja de Vida

-Fotocopia Legalizada Del Ttulo En Provisin Nacional De Su Profesin

-Informe De Actividades

-NIT (si tiene) para hacer su descargo posterior

5.- Cmo organiza los documentos que recolectan de los docentes?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOLos documentos Se recepcionan aqu y se los ponen en orden y luego se los pasa a recursos humanos luego pasa al DAF y luego a contabilidad y luego pasa a cheques ya para cancelarEntrevistado: DARWIN VELEZ SORIACargo: ASISTENTE FINANCIEROSe tarda mucho debido a dos motivos ya q es una gran cantidad ya q son alrededor de 300 docentes y el tiempo que toman en venir a dejar documentos es muy retardado ya que esto atrasa el pago por ejemplo.

6.- Cmo realiza la seleccin de los docentes para dictar las clases de nivelacin?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOCuando iniciamos fuimos a tener una capacitacin en escalafn para poder evaluarlos porque cuando lanzaron la convocatoria presentaban todos su curriculum y fuimos a sacar los tems para poder avaluarlos para saber qu es lo que necesitan para poder ser docentes en el PAB, En realidad es una sola vez y el tiempo que nos dan es de unos solo un mes Entrevistado: DARWIN VELEZ SORIACargo: ASISTENTE FINANCIEROPrcticamente una seleccin real o cientfica no se hace en el pab ya que en la seleccin que se hace se basa en que sea un docente titulado del sistema universitario Titulado y que sea ms o menos con la materia que va a dar7.- Cmo realizan el control de la documentacin de los docentes?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOTenemos harta deficiencia en el manejo de archivos y recoleccin de datos, lo hacemos manualmente

Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROLos Organizamos mediante los Cndor pero eso es muy fcil que se entre papelee en casos que se han dado as que es muy fcil que se pierda la documentacin.8.- Cmo controla el ingreso de documentacin?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOPor Recepcin en la SecretariaManualmente y Luego los pasamos a Excel

Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROEl ingreso de la documentacin se lo controla mediante una fotocopia q se lleva el docente.9.- Qu operaciones desea que realice su sistema?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOMe gustara tener docentes afiliados ya que si me falla el titular estn ellos ah para poder ubicarlos

10.- De qu manera manejan toda la informacin sobre los docentes (libro, tablas, archivo)?Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROLa informacin digital que se maneja es en planillas y tablas de Excel, Los Contratos en Word y los certificados en Power Point.Entrevista al los trabajadores del departamento del P.A.B.Fecha: 31/08/09

1.- Le gustara guardar el registro de sus profesores que son contratados?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOObvio que me registre todo en General nos hace falta y que me guarde los datos de profesores para consultar cualquier momento

2.- Le gustara guardar los datos de los profesores que no han sido contratados, si por algn motivo tendran que cambiar o reemplazar un profesor?Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROObvio, por supuesto que s, Esa es la idea que tenemos en mente tener una base de datos que nos sirva para siempre por medio de informacin para tenerlo como medio de informacin

3.- De qu se encargan los coordinadores?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICO Los Coordinadores se encargan de las materias, cada materia tiene un coordinador, cada uno de ellos se encarga de hacer los textos de crear el sistema acadmico, cada materia tiene un coordinador tanto los textosEntrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROLos Coordinadores de rea se encargan de elaborar todo lo que es en marco la materia que van a dictar, ellos elaboran los libros que van a dictar todos los docentes de la misma rea o materia4.- Cmo se realiza o como se comunica a los profesores que han sido aceptados para dictar las clases?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOLa mayora de los docentes ya son antiguos y ellos vienen a ver si ya estn programados y si se les ha asignado una materia

Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROMayormente por medio del telfono o mandando por mensajes5.- Prefiere tener diferentes accesos al sistema, en el que solo usted tenga acceso a toda la informacin y limitar la informacin que manejen los dems usuarios del sistema?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOCosa que cada uno debera haber uno que controla pero todos deberamos tener acceso a esa informacin

6.- Qu informacin le resulta adecuada aparezca en pantalla al registrar un docente?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOLo bsico que aparezca un nombre un grupo y el nmero de telfono y la profesin para poner un reaEntrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROLa Bsica y aun ms todava si o si tienen q estar nombre i Ci telfono actualizado y un correo electrnico tiene q tener de que carrera es y tambin el monto que va a recibir, los descuentos que se le van a realizar7.- Qu operaciones realiza manualmente (puede ser una lista de doc. seleccionados, las planillas el control de hora de trabajos, etc.)?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOEl Control de horas de trabajo el listado se maneja en Excel pero tambin es manual aunque hay ah un poco de tecnologa

Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIERO

Manualmente se realiza todo desde la planilla 8.- Cules son inconvenientes que tiene al realizar todo el proceso de seleccin de de profes?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOLa el embotellamiento que hay a fin de ao no se mira de que rea es porque ingresan muchos alumnos x q ah no podemos darnos el lujo de elegir por ejemplo Ud. no es de esta rea no la puede dar.Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROVienen de la parte legal ya que por ejemplo este ao con la ley financial y la ley 0181 que dice que no se puede contratar administrativos 9.- En cuntas provincias trabaja el pab?Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROTrabaja donde la UAGRM tiene alguna sucursal10.- Existe alguna diferencia para los profesores de provincia, cules?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOSi, es q algunas veces como ellos son de planta porque la mayora que acepta ser docente en provincia es porque ya trabajan all y es regularizado, se le pide solamente su fotocopia de carnet y sus solicitudesEntrevista al los trabajadores del departamento del P.A.B.Fecha: 01/09/09

1.- Cmo programan los grupos y horarios que se ofertan en los cursos del P.A.B.?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOLo programa el encargado de la programacin lo programa aqu el pab como lo programa de acuerdo a los grupos de acuerdo al curso que se est dando y de acuerdo al curso q se est dando y de acuerdo de cmo me bien la convocatoria los cursos son diferentes en los cursos de verano y de invierno Los cursos son diferentes en materias en tiempo y en la modalidad que se puede dar

2.- Cmo saben que tienen que crear algn nuevo grupo?

Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOAl meter Grupos al Sistema se le asigna una cantidad determinada de cupos, los transcriptores son los primeros en darse cuenta de ello y mandan a la oficina a un encargado para que nos llame y nos avisan que ya no hay cupos en un turno entonces aadimos nuevos grupos desde mi cuenta, que tiene ese privilegio 3.- Cmo los clasifican los grupos, por rea, por turno o por carrera?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOPor rea.4.- Tienen algn sistema que utilizan para crear los grupos?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOOcupamos tanto manual tano como sistema, pero en realidad lo q vale es el sistema porque todos los datos q se meten tienen q aparece para poder pagar porque de acuerdo a eso se paga, de acuerdo a eso se programa, por ejemplo en un pab de invierno no se puede programar aqu adentro 5.- El sistema que utilizan para la inscripcin al pab es del departamento?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOEs Del Centro de Procesamiento de Datos pero el CPD nos facilita un sistema que solo nos permite ponerle grupo y horarios los cuales ya preparamos con anticipacin para solo habilitarlos con una cantidad determinada de cupos

Entrevistado: DARWIN VELEZ SORIA

Cargo: ASISTENTE FINANCIEROSe lo hace pensando pero sin usar ningn sistema informtico6.- Cmo podran tener un reporte de los estudiantes inscritos al pab, si lo desearan?Entrevistado: ROSARIO SANTOSCargo: ENCARGADO ACADEMICOEl mismo CPD nos facilita imprimirnos reportes, estadsticas, incluso reportes de notas de cualquier tipo cuando nosotros queramos pero tenemos que pedrselos un da antes.1.8. Elementos Del Sistema

Seleccin De docentes PABEntrada: Documentos Del Docente: Nombre Completo, CI, Solicitud De Docencia, Informe de Actividades (Avance), Fotocopia De Titulo Profesional en provisin Nacional, Horarios Disponibles, Materias que pretende dictar y Hoja De Vida Objeto: Oficinas del Programa de Admisin Bsica, DocumentacinSujeto: Secretaria y Docente PostulanteConcepto: Seleccin de Docentes para dictar el Curso del PAB de Verano y/o InviernoAmbiente interno: Oficinas Del PABAmbiente externo: Formas de Ingreso a otras UniversidadesSalida: Nota De Recibidos los documentos para la postulacin a Docencia. PROCESO

ENTRADA SALIDA-Nombre

Nota De Recibido los

-CI documentos para la

-Solicitud de docencia postulacin a docencia

-Informe de Actividades (Avance)

-Fotocopia del Ttulo en Provisin

Nacional.

-Hoja De VidaAsignacin de Aulas Para Las Clases del Programa de Admisin Bsica Entrada: Lista de las Aulas Libres o Colegios Disponibles para que se lleve a cabo los cursos del Programa de admisin Bsica, Permiso Correspondiente para Ocupar las Aulas durante cierto periodoObjeto: Oficinas Del Programa de admisin Bsica, Listas De Las Aulas Sujeto: Aulas, Encargado De organizacin y asignacin de Aulas

Concepto: Asignacin de Aulas para Pasar Clases De las diferentes reas en grupo Ambiente Interno: Oficinas del PAB.

Ambiente Externo: Formas De Ingreso a Otras UniversidadesSalida: Programacin de aulas para las diferentes materias que se dictaran. PROCESO

ENTRADA SALIDA-Lista De Aulas De Lista De Aulas Designadas

La universidad para las diferentes materias

Disponibles que se dictaran en el

-Lista De Colegios. Programa de Admisin

Con Aulas Disponibles. Bsica

Programacin de Grupos y HorariosEntrada: Horarios Disponibles de los docentes en su documentacin para dictar los cursos del Programa de Orientacin Vocacional

Objeto: Oficinas Del PAB, Ordenador, Software para elaborar tablas (Excel)Sujeto: Encargado De Organizacin De Grupos, DocentesConcepto: Programacin de grupos y horarios para los diferentes docentes en todas las reas Para que dicten los Cursos Del Programa de admisin BsicaAmbiente interno: Oficinas Del PABAmbiente externo: Formas De Ingreso a Otras Universidades

Salida: Grupos Y Horarios Imprimidos y Bien Organizados en Boletas, Pancartas, para hacer Conocer a Cada Alumno y a cada Docente Donde Se Dictaran Las Clases, en que horario y que materia Se Cursara en Dicho Horario. PROCESO

ENTRADA SALIDA-Horarios Disponibles Lista De Grupos y Horarios

De Los Docentes en suque se Imprime y se da a

Documentacin para Conocer a todo alumno y

Dictar Los Cursos deldocente que participe del

Programa De Admisin BsicaPrograma De Admisin

Bsica

Programacin De Aulas Para ExmenesEntrada: Lista De Todas Las Aulas disponibles en el Campus y los Mdulos, autorizacin para el uso de las aulas en fin de semana, Lista De Docentes De Planta Disponibles para Tomar El Examen.

Objeto: Aulas De la universidad, Sujeto: Docentes, Coordinadores y Jefe Del PAB Concepto: Programacin y Organizacin De Las Aulas Para La Toma Del 1er y 2do Examen Ambiente interno: Aulas De la universidad.

Ambiente externo: Otras Formas De Ingreso a otras UniversidadesSalida: Lista De Los Cursos para el da del examen que se hace conocer en los diferentes Grupos Con anticipacin y se hace pblica para el Conocimiento de los postulantes.

PROCESO

ENTRADA SALIDA

-Lista De Aulas De Lista De las Aulas

Disponibles en laDesignadas en La

Universidad En elUniversidad para

Campus y MdulosConocimiento Pblico De

Docentes y estudiantes

. Que Participen en el Programa De Admisin Bsica

1.9. Metodologa Ishikawa1.9.1. Identificar el problema

P1. Desorden en la oficina por el exceso de archivosP2. Infraestructura Inadecuada con oficinas demasiado pequeasP3. Escasez de Muebles de Escritorio P4. Insuficiente equipo de ComputacinP5. Retraso en la entrega de documentos de los docentes que dictan el cursoP6. No hay un mtodo fijo de seleccin de docentesP7. Poca Coordinacin en el avance del Curso PABP8. Inadecuada asignacin de materias a profesoresP9. Dificultad en la asignacin de las aulas LibresP10. Problemas en la Disponibilidad de Horarios Con respecto a las materiasP11. Poca experiencia por parte de los nuevos docentesP12. Los profesores tienen una Insuficiente informacin acerca de las actividades acadmicas a desarrollar P13. Inadecuada seleccin de los profesores ya muchas veces se lo selecciona solo por seer de la misma lnea poltica, por el cumplimiento de los requisitos sin tomar en cuenta los meritos y experiencia indicados en su hoja de vida

P14. El personal que trabaja en el departamento del pab es desorganizado

P15. Poco de inters de parte del personal al realizar su trabajo

P16. Muchos de los que trabajan dentro del departamento son incompetentes ya que no conocen su rea de trabajo

P17. Los trabajadores no cumplen con el manual de funciones haciendo deficiente todo el manejo de la informacin sobre los profesores ya que todos hacen de todoy eso es completamente Ineficaz para el departamento.1.9.2. Identificar las principales categoras

a) El ambiente

b) Economa c) Recursos humanos (personal)

d) Profesores

e) Mtodos

1.9.3. Identificar las causas

Las causas para una inadecuada seleccin de profesores son las siguientes: a) El ambiente, este es una de las causas ya la infraestructura es inadecuada por el espacio pequeo adems no cuentan con los muebles de escritorio propicios para desarrollar su trabajo, adems existe un desorden de los archivos, papeles y documentacin q presentan los profesores.

b) Economa, este departamento no cuenta con los recursos suficientes ya que las computadoras que tienen estn en mal estado y fuera de mantenimiento, tanto como sus accesorios. c) Recursos humanos (Personal), En este grupo se incluyen los factores que pueden generar el problema desde el punto de vista del factor humano. Por ejemplo, falta de experiencia del personal, salario, falta de capacitacin, desinters, incompetencia, falta de organizacin, incumplimiento del manual de funciones.

d) Profesores, esta es una de las mayores causas del problema por su irresponsabilidad, retraso en la presentacin de sus documentos, falta de coordinacin con los administrativos del departamento, falta de informacin ya sea porque no hay los medios y son una gran cantidad, por no presentar todos sus requisitos, falta de experiencia de parte de los que por primera vez estn trabajando, poca disponibilidad de horarios. e) Mtodos, los que utilizan para la seleccin de profesores muy mecnicos adems no cuentan con un modelo fijo de seleccin ya que lo hacen por poltica, por disponibilidad de horarios, por el cumplimiento de requisitos y por tanto una inadecuada asignacin materia-profesor, dejando en segundo plano los meritos ganados o que cuentan en su hoja de vida siento este el mejor mtodo de seleccin.

1.9.4. Anlisis y ConclusinExiste una gran cantidad de problemas en este departamento, sin embargo nosotros no nos encargaremos de los problemas P1, P2, P3, P4, P5, P7, P11, P12, P14, P15 y P16 nos abocaremos a los ms mecnicos y adems que necesitan automatizacin en ese trabajo, los cuales son el P6, P8, P9, P10, P13 y P17 por lo tanto nuestro sistema de informacin administrara el problema Determinacin de los factores de la seleccin inadecuada de Docentes en el cual los problemas y sern solucionados Desarrollando Un Sistema de Informacin.2. Marco Terico2.1. Lenguaje Unificado de Modelado-UMLUML [UML] es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de software orientado a objetos (OO). Un artefacto es una informacin que es utilizada o producida mediante un proceso de desarrollo de software.

UML se quiere convertir en un lenguaje estndar con el que sea posible modelar todos los componentes del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante del modelo: no pretende definir un modelo estndar de desarrollo, sino nicamente un lenguaje de modelado. Otros mtodos de modelaje como OMT (Object Modeling Technique) o Booch s definen procesos concretos. En UML los procesos de desarrollo son diferentes segn los distintos dominios de trabajo; no puede ser el mismo el proceso para crear una aplicacin en tiempo real, que el proceso de desarrollo de una aplicacin orientada a gestin, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las fases del proceso. El mtodo del UML recomienda utilizar los procesos que otras metodologas tienen definidos.

Historia de UMLA partir del ao 1994, Grady Booch [Booch96](precursor de Booch '93) y Jim Rumbaugh (creador de OMT) se unen en una empresa comn, Rational Software Corporation, y comienzan a unificar sus dos mtodos. Un ao ms tarde, en octubre de 1995, aparece UML (Unified Modeling Language) 0.8, la que se considera como la primera versin del UML. A finales de ese mismo ao, Ivan Jacobson, creador de OOSE (Object Oriented Software Engineer) se aade al grupo.

Como objetivos principales de la consecucin de un nuevo mtodo que aunara los mejores aspectos de sus predecesores, sus protagonistas se propusieron lo siguiente: El mtodo deba ser capaz de modelar no slo sistemas de software sino otro tipo de sistemas reales de la empresa, siempre utilizando los conceptos de la orientacin a objetos (OO). Crear un lenguaje para modelado utilizable a la vez por mquinas y por personas. Establecer un acoplamiento explcito de los conceptos y los artefactos ejecutables. Manejar los problemas tpicos de los sistemas complejos de misin crtica.Lo que se intenta es lograr con esto que los lenguajes que se aplican siguiendo los mtodos ms utilizados sigan evolucionando en conjunto y no por separado. Y adems, unificar las perspectivas entre diferentes tipos de sistemas (no slo software, sino tambin en el mbito de los negocios), al aclarar las fases de desarrollo, los requerimientos de anlisis, el diseo, la implementacin y los conceptos internos de la OO.La notacin UML se deriva y unifica las tres metodologas de anlisis y diseo OO ms extendidas:1. Metodologa de Grady Booch para la descripcin de conjuntos de objetos y sus relaciones.

2. Tcnica de modelado orientada a objetos de James Rumbaugh (OMT: Object-Modeling Technique).

3. Aproximacin de Ivan Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodologa de casos de uso (use case).

El desarrollo de UML comenz a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus mtodos. A finales de 1995, Ivan Jacobson y su compaa Objectory se incorporaron a Rational en su unificacin, aportando el mtodo OOSE.

De las tres metodologas de partida, las de Booch y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relacin y colaboracin. Por otro lado, la metodologa de Jacobson es ms centrada a usuario, ya que todo en su mtodo se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estndar desde la formacin de OMG, que es tambin el origen de CORBA, el estndar lder en la industria para la programacin de objetos distribuidos. En 1997 UML 1.1 fue aprobada por la OMG convirtindose en la notacin estndar de facto para el anlisis y el diseo orientado a objetos.

UML es el primer mtodo en publicar un meta-modelo en su propia notacin, incluyendo la notacin para la mayora de la informacin de requisitos, anlisis y diseo. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propsito general debera ser capaz de modelarse a s mismo). En la actualidad

Existe actualmente una Revision Task Force (RTF) responsable de la generacin de revisiones menores de la especificacin UML 1.1. La primera RTF de UML termin su revisin en Junio de 1999 con el draft final UML 1.3, actualmente ya se public la revisin 1.5. Adems de estas revisiones menores tambin se est trabajando en una revisin mayor en lo que sera el UML 2.0.

ObjetivosDurante el desarrollo del UML sus autores tuvieron en cuenta:

1. Proporcionar una notacin y semnticas suficientes para poder alcanzar una gran cantidad de aspectos del modelado contemporneo de una forma directa y econmica.

2. Proporcionar las semnticas suficientes para alcanzar aspectos del modelado que son de esperar en un futuro, como por ejemplo aspectos relacionados con la tecnologa de componentes, el cmputo distribuido, etc.Proporcionar mecanismos de extensin de forma que proyectos concretos puedan extender el meta-modelo a un coste bajo.

3. Proporcionar mecanismos de extensin de forma que aproximaciones de modelado futuras podran desarrollarse encima del UML.

4. Permitir el intercambio de modelos entre una gran variedad de herramientas.

5. Proporcionar semnticas suficientes para especificar las interfaces a bibliotecas para la comparticin y el almacenamiento de componentes del modelo.

Mediante el fomento del uso de UML OMG pretende alcanzar los siguientes objetivos:

1. Proporcionar a los usuarios un lenguaje de modelado visual expresivo y utilizable para el desarrollo e intercambio de modelos significativos.

2. Proporcionar mecanismos de extensin y especializacin.

3. Ser independiente del proceso de desarrollo y de los lenguajes de programacin.

4. Proporcionar una base formal para entender el lenguaje de modelado.

5. Fomentar el crecimiento del mercado de las herramientas OO.

6. Soportar conceptos de desarrollo de alto nivel como pueden ser colaboraciones, frameworks, patterns, y componentes.

7. Integrar las mejores prcticas utilizadas hasta el momento.

El UML debe entenderse como un estndar para modelado y no como un estndar de proceso software. Aunque UML debe ser aplicado en el contexto de un proceso, la experiencia ha mostrado que organizaciones diferentes y dominios del problema diferentes requieren diferentes procesos. Por ello se han centrado los esfuerzos en un meta-modelo comn (que unifica las semnticas) y una notacin comn que proporcione una representacin de esas semnticas. De todas formas, los autores de UML fomentan un proceso guiado por casos de uso, centrado en la arquitectura, iterativo e incremental.

Bajo estas lneas genricas proponen el proceso software definido en una de las extensiones del UML (Objectory Extension for Software Engineering), pero en general el proceso software es fuertemente dependiente de la organizacin y del dominio de aplicacin.Por ltimo mencionar que aunque UML abarca todas las tcnicas existentes, es de esperar que aparezcan nuevas tcnicas. El UML se puede adaptar a estas nuevas tcnicas ya que dispone de mecanismos de extensin que no necesitan redefinir el ncleo UML.OMGEl OMG (Object Management Group) se form en 1989 con el propsito de crear una arquitectura estndar para objetos distribuidos en redes (componentes). En Octubre de 1989 empez a funcionar como una corporacin independiente y sin nimo de lucro. El compromiso asumido por el OMG busca el desarrollo de especificaciones para la industria del software que sean tcnicamente ``excelentes'', comercialmente viables e independientes del vendedor.

Hoy en da el consorcio incluye unos 800 miembros (compaas en la industria del software). La primera arquitectura resultante de esta colaboracin fue CORBA (Common Objet Request Broker Arquitecture). El elemento central de esta arquitectura es el ORB (Object Request Broker). Un ORB permite que un objeto cliente haga una peticin a un servidor sin conocer la interfaz ni la localizacin del objeto servidor. OMG define "object management" como el desarrollo software que modela el mundo real mediante su representacin como objetos. Estos objetos no son ms que la encapsulacin de atributos, relaciones y mtodos de componentes software identificable. 2.1.1. Vocabulario de UML Los bloques bsicos de construccin de UML son tres, los elementos, las relaciones y los diagramas.

Los elementos son abstracciones que actan como unidades bsicas de construccin. Hay cuatro tipos, los estructurales, los de comportamiento, los de agrupacin y los de notacin. En cuanto a los elementos estructurales son las partes estticas de los modelos y representan aspectos conceptuales o materiales. Los elementos de comportamiento son las partes dinmicas de los modelos y representan comportamientos en el tiempo y en el espacio. Los elementos de agrupacin son las partes organizativas de UML, establecen las divisiones en que se puede fraccionar un modelo. Slo hay un elemento de agrupacin, el paquete, que se emplea para organizar otros elementos en grupos. Los elementos de notacin son las partes explicativas de UML, comentarios que pueden describir textualmente cualquier aspecto de un modelo. Slo hay un elemento de notacin principal, la nota.

Las relaciones son abstracciones que actan como unin entre los distintos elementos. Hay cuatro tipos, la dependencia, la asociacin, la generalizacin y la realizacin.

Los diagramas son la disposicin de un conjunto de elementos, que representan el sistema modelado desde diferentes perspectivas. UML tiene nueve diagramas fundamentales, agrupados en dos grandes grupos, uno para modelar la estructura esttica del sistema y otro para modelar el comportamiento dinmico. Los diagramas estticos son: el de clases, de objetos, de componentes y de despliegue. Los diagramas de comportamiento son: el de Casos de Uso, de secuencia, de colaboracin, de estados y de actividades.

ElementosE

L

E

M

E

N

T

O

S

E

S

T

R

U

C

T

U

R

A

L

E

S

ClaseDescribe un conjunto de objetos que comparten los mismos atributos, mtodos, relaciones y semntica. Las clases implementan una o ms interfaces.

Clase activaSe trata de una clase, en la que existe procesos o hilos de ejecucin concurrentes con otros elementos. Las lneas del contorno son ms gruesas que en la clase normal

InterfazAgrupacin de mtodos u operaciones que especifican un servicio de una clase o componente, describiendo su comportamiento, completo o parcial, externamente visible. UML permite emplear un crculo para representar las interfaces, aunque lo ms normal es emplear la clase con el nombre en cursiva.

ColaboracinDefine una interaccin entre elementos que cooperan para proporcionar un comportamiento mayor que la suma de los comportamientos de sus elementos.

Caso de usoDescribe un conjunto de secuencias de acciones que un sistema ejecuta, para producir un resultado observable de inters. Se emplea para estructurar los aspectos de comportamiento de un modelo.

ComponenteParte fsica y por tanto reemplazable de un modelo, que agrupa un conjunto de interfaces, archivos de cdigo fuente, clases, colaboraciones y proporciona la implementacin de dichos elementos.

NodoElemento fsico que existe en tiempo de ejecucin y representa un recurso computacional con capacidad de procesar.

Elementos

de

comportamientoInteraccinComprende un conjunto de mensajes que se intercambian entre un conjunto de objetos, para cumplir un objetivo especifico.

Mquinas

de

estadosEspecifica la secuencia de estados por los que pasa un objeto o una interaccin, en respuesta a eventos.

Elementos

de

agrupacinPaqueteSe emplea para organizar otros elementos en grupos.

Elementos

de

notacin

NotaPartes explicativa de UML, que puede describir textualmente cualquier aspecto del modelo

RelacionesDependenciaEs una relacin entre dos elementos, tal que un cambio en uno puede afectar al otro.

AsociacinEs una relacin estructural que resume un conjunto de enlaces que son conexiones entre objetos.

GeneralizacinEs una relacin en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.

RealizacinEs una relacin que implica que la parte realizante cumple con una serie de especificaciones propuestas por la clase realizada (interfaces).

DiagramasM

O

D

E

L

A

N

E

S

T

R

U

C

T

U

R

A

ClasesMuestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones, cubriendo la vista de diseo esttica del sistema.

ObjetosAnlogo al diagrama de clases, muestra un conjunto de objetos y sus relaciones, pero a modo de vista instantnea de instancias de una clase en el tiempo.

ComponentesMuestra la organizacin y dependencias de un conjunto de componentes. Cubren la vista de implementacin esttica de un sistema. Un componente es un mdulo de cdigo, de modo que los diagramas de componentes son los anlogos fsicos a los diagramas de clases.

DespliegueMuestra la configuracin del hardware del sistema, los nodos de proceso y los componentes empleados por stos. Cubren la vista de despliegue esttica de una arquitectura.

M

O

D

E

L

A

N

C

O

M

P

O

R

T

A

M

I

E

N

T

O

Casos de UsoMuestra un conjunto de casos de uso, los actores implicados y sus relaciones. Son diagramas fundamentales en el modelado y organizacin del sistema.

SecuenciaSon diagramas de interaccin, muestran un conjunto de objetos y sus relaciones, as como los mensajes que se intercambian entre ellos. Cubren la vista dinmica del sistema. El diagrama de secuencia resalta la ordenacin temporal de los mensajes, mientras que el de colaboracin resalta la organizacin estructural de los objetos, ambos siendo equivalentes o isomorfos. En el diagrama de colaboracin de la figura de la izquierda, se puede ver que los elementos grficos no son cajas rectangulares, como cabra esperar, y en su lugar encontramos sus versiones adornadas. Estas versiones tienen como finalidad evidenciar un rol especfico del objeto siendo modelado. En la figura encontramos de izquierda a derecha y de arriba abajo un Actor, una Interfaz, un Control (modela un comportamiento) y una Instancia (modela un objeto de dato).

Colaboracin

EstadosMuestra una mquina de estados, con sus estados, transiciones, eventos y actividades. Cubren la vista dinmica de un sistema. Modelan comportamientos reactivos en base a eventos.

ActividadesTipo especial de diagrama de estados que muestra el flujo de actividades dentro de un sistema.

2.1.2. Aspecto Esttico y DinmicosSe Dispone de dos tipos diferentes de diagramas los que dan una vista esttica del sistema y los que dan una visin dinmica. Los diagramas estticos son: Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los ms comunes y dan una vista esttica del proyecto. Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visin de casos reales. Diagrama de componentes: Muestran la organizacin de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones. Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e ndice. Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.Lo diagramas dinmicos son: Diagrama de secuencia, Diagrama de colaboracin: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envan entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin prdida de informacin, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interaccin. Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son tiles en sistemas que reaccionen a eventos. Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.Como podemos ver el nmero de diagramas es muy alto, en la mayora de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el documento se dar una breve explicacin de todos, amplindose para los ms necesarios.

2.1.3. Diagrama de ClasesLos diagramas de clases representan un conjunto de elementos del modelo que son estticos, como las clases y los tipos, sus contenidos y las relaciones que se establecen entre ellos.Algunos de los elementos que se pueden clasificar como estticos son los siguientes:

Paquete: Es el mecanismo de que dispone UML para organizar sus elementos en grupos, se representa un grupo de elementos del modelo. Un sistema es un nico paquete que contiene el resto del sistema, por lo tanto, un paquete debe poder anidarse, permitindose que un paquete contenga otro paquete.

Clases: Una clase representa un conjunto de objetos que tienen una estructura, un comportamiento y unas relaciones con propiedades parecidas. Describe un conjunto de objetos que comparte los mismos atributos, operaciones, mtodos, relaciones y significado. En UML una clase es una implementacin de un tipo. Los componentes de una clase son:Atributo: Se corresponde con las propiedades de una clase o un tipo. Se identifica mediante un nombre. Existen atributos simples y complejos.Operacin. Tambin conocido como mtodo, es un servicio proporcionado por la clase que puede ser solicitado por otras clases y que produce un comportamiento en ellas cuando se realiza.Las clases pueden tener varios parmetros formales, son las clases denominadas plantillas. Sus atributos y operaciones vendrn definidos segn sus parmetros formales. Las plantillas pueden tener especificados los valores reales para los parmetros formales, entonces reciben el nombre de clase parametrizada instanciada. Se puede usar en cualquier lugar en el que se podra aparecer su plantilla.Relacionando con las clases nos encontramos con el trmino utilidad, que se corresponde con una agrupacin de variables y procedimientos globales en forma de declaracin de clase, tambin puede definirse como un estereotipo (o nueva clase generada a partir de otra ya existente) de un tipo que agrupa variables globales y procedimientos en una declaracin de clase. Los atributos y operaciones que se agrupan en una utilidad se convierten en variables y operaciones globales. Una utilidad no es fundamental para el modelado, pero puede ser conveniente durante la programacin.

Meta-clase: Es una clase cuyas instancias son clases. Sirven como depsito para mantener las variables de clase y proporcionan operaciones (mtodo de clase) para inicializar estas variables. Se utilizan para construir meta-modelos (modelos que se utilizan para definir otros modelos).

Tipos: Es un descriptor de objetos que tiene un estado abstracto y especificaciones de operaciones pero no su implementacin. Un tipo establece una especificacin de comportamiento para las clases.

Interfaz: Representa el uso de un tipo para describir el comportamiento visible externamente de cualquier elemento del modelo.

Relacin entre clases: Las clases se relacionan entre s de distintas formas, que marcan los tipos de relaciones existentes:

Asociacin:Es una relacin que describe un conjunto de vnculos entre clases. Pueden ser binarias o n-arias, segn se implican a dos clases o ms. Las relaciones de asociacin vienen identificadas por los roles, que son los nombres que indican el comportamiento que tienen los tipos o las clases, en el caso del rol de asociacin (existen otros tipos de roles segn la relacin a la que identifiquen). Indican la informacin ms importante de las asociaciones. Es posible indicar el nmero de instancias de una clase que participan en una relacin mediante la llamada multiplicidad. Cuando la multiplicidad de un rol es mayor que 1, el conjunto de elementos que se relacionan puede estar ordenado. Las relaciones de asociacin permiten especificar qu objetos van a estar asociados con otro objeto mediante un calificador. El calificador es un atributo o conjunto de atributos de una asociacin que determina los valores que indican cuales son los valores que se asociarn.Una asociacin se dirige desde una clase a otra (o un objeto a otro), el concepto de navegabilidad se refiere al sentido en el que se recorre la asociacin.Existe una forma especial de asociacin, la agregacin, que especifica una relacin entre las clases donde el llamado "agregado" indica l todo y el "componente" es una parte del mismo.Composicin:Es un tipo de agregacin donde la relacin de posesin es tan fuerte como para marcar otro tipo de relacin. Las clases en UML tienen un tiempo de vida determinado, en las relaciones de composicin, el tiempo de vida de la clase que es parte del todo (o agregado) viene determinado por el tiempo de vida de la clase que representa el todo, por tanto es equivalente a un atributo, aunque no lo es porque es una clase y puede funcionar como tal en otros casos.Generalizacin:Cuando se establece una relacin de este tipo entre dos clases, una es una Superclase y la otra es una Subclase. La subclase comparte la estructura y el comportamiento de la superclase. Puede haber ms de una clase que se comporte como subclase.

Dependencia:Una relacin de dependencia se establece entre clases (u objetos) cuando un cambio en el elemento independiente del modelo puede requerir un cambio en el elemento dependiente.

2.1.4. Diagrama de Casos de UsoUnos casos de uso es una secuencia de transacciones que son desarrolladas por un sistema en respuesta a un evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso sirven para especificar la funcionalidad y el comportamiento de un sistema mediante su interaccin con los usuarios y/o otros sistemas. O lo que es igual, un diagrama que muestra la relacin entre los actores y los casos de uso en un sistema. Una relacin es una conexin entre los elementos del modelo, por ejemplo la relacin y la generalizacin son relaciones.

Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al mostrar cmo reacciona una respuesta a eventos que se producen en el mismo. En este tipo de diagrama intervienen algunos conceptos nuevos: un actor es una entidad externa al sistema que se modela y que puede interactuar con l; un ejemplo de actor podra ser un usuario o cualquier otro sistema. Las relaciones entre casos de uso y actores pueden ser las siguientes: Un actor se comunica con un caso de uso. Un caso de uso extiende otro caso de uso. Un caso de uso usa otro caso de usoEste modelo, se emplea para visualizar el comportamiento del sistema, una parte de l o de una sola clase. De forma que se pueda conocer cmo responde esa parte del sistema. El diagrama de uso es muy til para definir como debera ser el comportamiento de una parte del sistema, ya que solo especifica cmo deben comportarse y no como estn implementadas las partes que define. Por ello es un buen sistema de documentar partes del cdigo que deban ser reutilizables por otros desarrolladores. El diagrama tambin puede ser utilizado para que los expertos de dominio se comuniquen con los informticos sin llegar a niveles de complejidad. Un caso de uso especifica un requerimiento funcional, es decir indica esta parte debe hacer esto cuando pase esto.En el diagrama nos encontramos con diferentes figuras que pueden mantener diversas relaciones entre ellas:Casos de uso: representado por una elipse, cada caso de uso contiene un nombre, que indique su funcionalidad. Los casos de uso pueden tener relaciones con otros casos de uso. Sus relaciones son: Include: Representado por una flecha, en el diagrama de ejemplo podemos ver como un caso de uso, el de totalizar el coste incluye a dos casos de uso.

Extends: Una relacin de una caso de Uso A hacia un caso de uso B indica que el caso de uso B implementa la funcionalidad del caso de uso A.Generalization: Es la tpica relacin de herencia.Actores: se representan por un mueco. Sus relaciones son:Communicates: Comunica un actor con un caso de uso, o con otro actor.

Parte del sistema (System boundary): Representado por un cuadro, identifica las diferentes partes del sistema y contiene los casos de uso que la forman.

En este grafico encontramos tres casos de usos Crear producto utiliza Validar producto, y Crear pack productos es una especializacin de Crear productos.

Podemos emplear el diagrama de dos formas diferentes, para modelar el contexto de un sistema, y para modelar los requisitos del sistema. Modelado del contexto.

Se debe modelar la relacin del sistema con los elementos externos, ya que son estos elementos los que forman el contexto del sistema.

Los pasos a seguir son:

Identificar los actores que interactan con el sistema.

Organizar a los actores.

Especificar sus vas de comunicacin con el sistema.Modelado de requisitos.

La funcin principal, o la ms conocida del diagrama de casos de uso es documentar los requisitos del sistema, o de una parte de l.

Los requisitos establecen un contrato entre el sistema y su exterior, definen lo que se espera que realice el sistema, sin definir su funcionamiento interno. Es el paso siguiente al modelado del contexto, no indica relaciones entre autores, tan solo indica cuales deben ser las funcionalidades (requisitos) del sistema. Se incorporan los casos de uso necesarios que no son visibles desde los usuarios del sistema.

Para modelar los requisitos es recomendable:

Establecer su contexto, para lo que tambin podemos usar un diagrama de casos de uso.

Identificar las necesidades de los elementos del contexto (Actores).

Nombrar esas necesidades, y darles forma de caso de uso.

Identificar que casos de uso pueden ser especializaciones de otros, o buscar especializaciones comunes para los casos de uso ya encontrados.

Como podemos ver se incluyen nuevos casos de uso que no son visibles por ninguno de los actores del sistema, pero que son necesarios para el correcto funcionamiento.

2.1.5. Diagrama de ObjetosLos diagramas de objetos modelan las instancias de elementos contenidos en los diagramas de clases. Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un momento concreto. En UML, los diagramas de clase se utilizan para visualizar los aspectos estticos del sistema y los diagramas de interaccin se utilizan para ver los aspectos dinmicos de los sistemas, y constan de instancias de los elementos del diagrama de clases y mensajes enviados entre ellos. En un punto intermedio podemos situar los diagramas de objetos, que contiene un conjunto de instancias de los elementos encontrados en el diagrama de clases, representando slo la parte esttica de un interaccin, consistiendo en los objetos que colaborar pero sin ninguno de los mensajes intercambiados entre ellos. Los diagramas de objetos se emplean para modelar la vista de diseo esttica o la vista de procesos esttica de un sistema al igual que se hace con los diagramas de clases, pero desde la perspectiva de instancias reales o prototpicas. Esta vista sustenta principalmente los requisitos funcionales de un sistema. Los diagramas de objetos permiten modelar estructuras de datos estticas, En general los diagramas de objetos se utilizan para modelar estructuras de objetos, lo que implica tomar una instantnea de los objetos de un sistema en un cierto momento. Un diagrama de objetos representa una escena esttica dentro de la historia representad a por un diagrama de interaccin. Los diagramas de objetos se utilizan para visualizar, especificar, construir y documentar la existencia de ciertas instancias en el sistema, junto a las relaciones entre ellas.

Tendramos un diagrama de objetos con dos instancias de Mensaje, mas concretamente con una instancia de Mensaje DIR y otra de Mensaje ADM, con todos sus atributos valorados. Tambin tendramos una instancia de cada una de las otras clases que deban tener instancia. Como CanalEnt, INS, Distr, y el Buzn correspondiente a la instancia de mensaje que se est instanciando. En la instancia de la clase INS se deber mostrar en su miembro Estado, que est ocupado realizando una insercin.En un diseo no podemos encontrar con multitud de diagramas de objetos, cada uno de ellos representando diferentes estados del sistema.2.1.6. Diagrama de ComponentesSe utilizan para modelar la vista esttica 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 el situaremos libreras, tablas archivos, ejecutables y documentos que formen parte del sistema.Uno de los usos principales es que puede servir para ver que componentes pueden compartirse entre sistemas o entre diferentes partes de un sistema.

Aqu tenemos un componente del sistema de Windows. En el diagrama de componentes de Windows debe salir este componente, ya que sin el sistema no funcionara.

En esta otra figura tenemos el mismo componente, pero indicamos que dispone de un interface. Al ser una Dll el interface nos da acceso a su contenido. Esto nos hace pensar que la representacin anterior es incorrecta, pero no es as solo corresponde a un nivel diferente de detalle.Como ya hemos indicado antes todo objeto UML puede ser modificado mediante estereotipos, el standard que define UML son: Executable Library Table File Document.Aunque por suerte no estamos limitados a estas especificaciones. Qu pasa si queremos modelar un proyecto de Internet donde nuestros componentes son ASP, HTML, y Scripts, y queremos marcarlo en el modelo. Pues utilizamos un estereotipo. Existen ya unos definidos WAE (Web Applications Extensin).Podemos modelar diferentes partes de nuestro sistema, y modelar diferentes entidades que no tiene nada que ver entre ellas. Ejecutables y bibliotecas. Tablas. API Cdigo fuente. Hojas HTML.

2.1.7. Diagrama de DistribucinEL diagrama de distribucin muestra la arquitectura fsica de un sistema de informacin. Se representan los equipos y dispositivos, adems la conexin entre ellos.

2.1.8. Diagrama de ActividadesSon similares a los diagramas de flujo de otras metodologas OO. En realidad se corresponden con un caso especial de los diagramas de estado donde los estados son estados de accin (estados con una accin interna y una o ms transiciones que suceden al finalizar esta accin, o lo que es lo mismo, un paso en la ejecucin de lo que ser un procedimiento) y las transiciones vienen provocadas por la finalizacin de las acciones que tienen lugar en los estados de origen. Siempre van unidos a una clase o a la implementacin de un caso de uso o de un mtodo (que tiene el mismo significado que en cualquier otra metodologa OO). Los diagramas de actividad se utilizan para mostrar el flujo de operaciones que se desencadenan en un procedimiento interno del sistema.

2.1.9. Diagrama de EstadosRepresentan la secuencia de estados por los que un objeto o una interaccin entre objetos pasa durante su tiempo de vida en respuesta a estmulos (eventos) recibidos. Representa lo que podemos denominar en conjunto una mquina de estados. Un estado en UML es cuando un objeto o una interaccin satisface una condicin, desarrolla alguna accin o se encuentra esperando un evento.Cuando un objeto o una interaccin pasa de un estado a otro por la ocurrencia de un evento se dice que ha sufrido una transicin, existen varios tipos de transiciones entre objetos: simples (normales y reflexivas) y complejas. Adems una transicin puede ser interna si el estado del que parte el objeto o interaccin es el mismo que al que llega, no se provoca un cambio de estado y se representan dentro del estado, no de la transicin. Como en todas las metodologas OO se envan mensajes, en este caso es la accin de la que puede enviar mensajes a uno o varios objetos destino

2.1.10. Diagrama de ColaboracinMuestra la interaccin entre varios objetos y los enlaces que existen entre ellos. Representa las interacciones entre objetos organizadas alrededor de los objetos y sus vinculaciones. A diferencia de un diagrama de secuencias, un diagrama de colaboraciones muestra las relaciones entre los objetos, no la secuencia en el tiempo en que se producen los mensajes. Los diagramas de secuencias y los diagramas de colaboraciones expresan informacin similar, pero en una forma diferente.Formando parte de los diagramas de colaboracin nos encontramos con objetos, enlaces y mensajes. Un objeto es una instancia de una clase que participa como una interaccin, existen objetos simples y complejos. Un objeto es activo si posee un thread o hilo de control y es capaz de iniciar la actividad de control, mientras que un objeto es pasivo si mantiene datos pero no inicia la actividad.

Un enlace es una instancia de una asociacin que conecta dos objetos de un diagrama de colaboracin. El enlace puede ser reflexivo si conecta a un elemento consigo mismo. La existencia de un enlace entre dos objetos indica que puede existir un intercambio de mensajes entre los objetos conectados.

Los diagramas de interaccin indican el flujo de mensajes entre elementos del modelo, el flujo de mensajes representa el envo de un mensaje desde un objeto a otro si entre ellos existe un enlace. Los mensajes que se envan entre objetos pueden ser de distintos tipos, tambin segn como se producen en el tiempo; existen mensajes simples, sincrnicos, balking, timeout y asncronos. Durante la ejecucin de un diagrama de colaboracin se crean y destruyen objetos y enlaces.

2.1.11. Diagrama de SecuenciaMuestran las interacciones entre un conjunto de objetos, ordenadas segn el tiempo en que tienen lugar. En los diagramas de este tipo intervienen objetos, que tienen un significado parecido al de los objetos representados en los diagramas de colaboracin, es decir son instancias concretas de una clase que participa en la interaccin. El objeto puede existir slo durante la ejecucin de la interaccin, se puede crear o puede ser destruido durante la ejecucin de la interaccin. Un diagrama de secuencia representa una forma de indicar el perodo durante el que un objeto est desarrollando una accin directamente o a travs de un procedimiento.

En este tipo de diagramas tambin intervienen los mensajes, que son la forma en que se comunican los objetos: el objeto origen solicita (llama a) una operacin del objeto destino. Existen distintos tipos de mensajes segn cmo se producen en el tiempo: simples, sncronos, y asncronos.

Los diagramas de secuencia permiten indicar cul es el momento en el que se enva o se completa un mensaje mediante el tiempo de transicin, que se especifica en el diagrama.El diagrama de secuencia forma parte del modelado dinmico del sistema. Se modelan las llamadas entre clases desde un punto concreto del sistema. Es til para observar la vida de los objetos en sistema, identificar llamadas a realizar o posibles errores del modelado esttico, que imposibiliten el flujo de informacin o de llamadas entre los componentes del sistema. En el diagrama de secuencia se muestra el orden de las llamadas en el sistema. Se utiliza un diagrama para cada llamada a representar. Es imposible representar en un solo diagrama de secuencia todas las secuencias posibles del sistema, por ello se escoge un punto de partida. El diagrama se forma con los objetos que forman parte de la secuencia, estos se sitan en la parte superior de la pantalla, normalmente en la izquierda se sita al que inicia la accin. De estos objetos sale una lnea que indica su vida en el sistema. Esta lnea simple se convierte en una lnea gruesa cuando representa que el objeto tiene el foco del sistema, es decir cuando l est activo.

2.2. Proceso Unificado de Desarrollo de Software-P.U.D.S.El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto.

El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.Proceso de desarrollo de software basado en el Lenguaje Unificado de Modelado y que es iterativo, centrado en la arquitectura y dirigido por los casos de uso y los riesgos. Proceso que se organiza en cuatro fases: inicio, elaboracin, construccin y transicin, y que se estructura en torno a cinco flujos de trabajo fundamentales: recopilacin de requisitos, anlisis, diseo, implementacin y pruebas. Proceso que se describe en trminos de un modelo de negocio, el cual est a su vez estructurado en funcin de tres bloques de construccin primordiales trabajadores, actividades y artefactos. 2.2.1. FasesEl Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.Fase de Inicio: Primera fase del ciclo de vida del software, en la que la idea inicial para el desarrollo es refinada hasta el punto de quedar lo suficientemente bien establecida como para garantizar la entrada en la base de elaboracin.

Fase de Elaboracin: Segunda fase del ciclo de vida, en la que se define la arquitectura.

Fase de Construccin: Tercera fase del ciclo de vida del software, en la que el software es desarrollado a partir de una lnea base de la arquitectura ejecutable, hasta el punto en el que se est listo para ser transmitido a las comunidades de usuarios.

Fase de Transicin: Cuarta fase del ciclo de vida del software es puesto en manos de la comunidad de usuarios.

2.2.2. Flujo de TrabajoCada fase se subdivide en iteraciones. En cada iteracin se desarrolla en secuencia

Un conjunto de disciplinas o flujos de trabajos.

Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo)

Vinculadas a un rea especfica dentro del proyecto total. Las ms importantes son:

Requerimientos, Anlisis, Diseo, Codificacin, y Prueba.

El agrupamiento de actividades en disciplinas es principalmente una ayuda para

Comprender el proyecto desde la visin tradicional en cascada.

Cada disciplina est asociada con un conjunto de modelos que se desarrollan. Estos

Modelos estn compuestos por artefactos. Los artefactos ms importantes son los

Modelos que cada disciplina realiza: modelo de casos de uso, modelo de diseo,

Modelo de implementacin, y modelo de prueba.

El Proceso Unificado consiste en una serie de disciplinas o flujos de trabajo que van

Desde los requisitos hasta las pruebas. Los flujos de trabajo desarrollan modelos

Desde el modelo de casos de uso hasta el modelo de pruebas.

Disciplina Modelos

Requisitos Modelo de Casos de Uso

Anlisis Modelo de Anlisis

Diseo Modelo de Diseo - Modelo de Despliegue

Implementacin Modelo de Implementacin Prueba Modelo de Prueba

2.2.3. Caractersticas del Modelo El Proceso Unificado es un proceso de desarrollo de software: conjunto de

Actividades necesarias para transformar los requisitos del usuario en un

Sistema software.

RUP es un marco genrico que puede especializarse para una variedad de

Tipos de sistemas, diferentes reas de aplicacin, tipos de organizaciones,

Niveles de aptitud y diferentes tamaos de proyectos.

RUP est basado en componentes. El sw est formado por componentes

Software interconectado a travs de interfaces.

RUP est dirigido por casos de uso, centrado en la arquitectura, y es

Iterativo e incremental.

Dirigido por Casos de Uso

Un caso de uso es un fragmento de funcionalidad del sistema que proporciona

Un resultado de valor a un usuario. Los casos de uso modelan los

Requerimientos funcionales del sistema.

Todos los casos de uso juntos constituyen el modelo de casos de uso.

Los casos de uso tambin guan el proceso de desarrollo (diseo,

Implementacin, y prueba). Basndose en los casos de uso los desarrolladores

Crean una serie de modelos de diseo e implementacin que llevan a cabo los

Casos de uso. De este modo los casos de uso no solo inician el proceso de

Desarrollo sino que le proporcionan un hilo conductor, avanza a travs de una

Serie de flujos de trabajo que parten de los casos de uso.

Centrado en la Arquitectura

La arquitectura de un sistema software se describe mediante diferentes vistas del

Sistema en construccin.

El concepto de arquitectura software incluye los aspectos estticos y dinmicos ms

Significativos del sistema.

La arquitectura es una vista del diseo completo con las caractersticas ms

Importantes resaltadas, dejando los detalles de lado.

Arquitectura: Conjunto de decisiones significativas acerca de la organizacin de un

Sistema software, la seleccin de los elementos estructurales a partir de los cuales se

Compone el sistema, las interfaces entre ellos, su comportamiento, sus

Colaboraciones, y su composicin.

Los casos de uso y la arquitectura estn profundamente relacionados. Los casos de

Uso deben encajar en la arquitectura, y a su vez la arquitectura debe permitir el

Desarrollo de todos los casos de uso requeridos, actualmente y a futuro.

El arquitecto desarrolla la forma o arquitectura a partir de la comprensin de un

Conjunto reducido de casos de uso fundamentales o crticos (usualmente no ms del

10 % del total). En forma resumida, podemos decir que el arquitecto:

- Crea un esquema en borrador de la arquitectura comenzando por la

Parte no especfica de los casos de uso (por ejemplo la plataforma) pero

Con una comprensin general de los casos de uso fundamentales.

- A continuacin, trabaja con un conjunto de casos de uso claves o

Fundamentales. Cada caso de uso es especificado en detalle y realizado

En trminos de subsistemas, clases, y componentes.

- A medida que los casos de uso se especifican y maduran, se descubre

Ms de la arquitectura, y esto a su vez lleva a la maduracin de ms

Casos de uso.

Este proceso contina hasta que se considere que la arquitectura es estable.

Iterativo e Incremental

Es prctico dividir el esfuerzo de desarrollo de un proyecto de software en partes mas

Pequeas o mini proyectos.

Cada mini proyecto es una iteracin que resulta en un incremento.

Las iteraciones hace referencia a pasos en el flujo de trabajo, y los incrementos a

Crecimientos en el producto.

Las iteraciones deben estar controladas. Esto significa que deben seleccionarse y

Ejecutarse de una forma planificada.

Los desarrolladores basan la seleccin de lo que implementarn en cada iteracin en

Dos cosas: el conjunto de casos de uso que amplan la funcionalidad, y en los riesgos

Mas importantes que deben mitigarse.

En cada iteracin los desarrolladores identifican y especifican los casos de uso

Relevantes, crean un diseo utilizando la arquitectura seleccionada como gua, para

Implementar dichos casos de uso. Si la iteracin cumple sus objetivos, se contina con

La prxima. Si no deben revisarse las decisiones previas y probar un nuevo enfoque.

Beneficios del enfoque iterativo

- La iteracin controlada reduce el riesgo a los costes de un solo incremento.

- Reduce el riesgo de retrasos en el calendario atacando los riesgos ms importantes

Primero.

- Acelera el desarrollo. Los trabajadores trabajan de manera ms eficiente al obtener

Resultados a corto plazo.

- Tiene un enfoque ms realista al reconocer que los requisitos no pueden definirse

Completamente al principio.2.2.4. Las Cuatro Ps Personas: Los principales autores de un proyecto de software son los arquitectos, desarrolladores, ingenieros de prueba, y el personal de gestin que les da soporte, adems de los usuarios, clientes, y otros interesados. Las personas son realmente seres humanos, a diferencia del trmino abstracto trabajadores. Proyecto: Elemento organizativo a travs del cual se gestiona el desarrollo de software. El resultado de un proyecto es una versin de un producto.

Producto: Artefactos que se crean durante la vida del proyecto, como los modelos, cdigo fuente, ejecutables, y documentacin.

Proceso: Un proceso de ingeniera de software es una definicin del conjunto de actividades necesarias para transformar los requisitos de usuario en un producto. Un proceso es una plantilla para crear proyectos.2.2.5. Flujo de Trabajo (Requisitos y Anlisis)

Fase de captura de requisitosLa captura de requisitos es el acto de descubrir y averiguar, normalmente en situaciones difciles, lo que se debe construir.Artefactos de requisitos Los artefactos fundamentales en la captura de requisitos son: el modelo de casos de uso, que incluye los casos de uso y los actores, la descripcin de la arquitectura, el glosario y el prototipo de la interfaz de usuario.

Artefactos:

Modelo de casos de uso: permite a los desarrolladores de software y a los clientes que lleguen a un acuerdo sobre los requisitos que debe cumplir el sistema. Un modelo de casos de uso contiene actores, casos de uso y las relaciones que existen entre s.

Actor: el modelo de casos de uso describe lo que hace el sistema para cada tipo de usuario. Cada uno de estos usuarios se representa por medio de un actor. Un sistema externo es considerado tambin un actor que interacta con el sistema. Los actores representan a terceros que interactan con el sistema. Un actor juega un papel por cada caso de uso con el que colabora.

Casos de uso: un caso de uso describe cmo utilizar el sistema por parte de los actores. Los casos de uso especifican una secuencia de acciones que el sistema puede llevar a cabo incluyendo las alternativas dentro de la secuencia. Un caso de uso puede especificarse con diagramas de estados, diagramas de actividad,... Una instancia de un caso de uso es la realizacin de un caso de uso. Cuando se lleva a cabo una instancia de un caso de uso se ejecuta una serie de acciones, algunas de las cuales pueden tener caminos alternativos.

Descripcin de la arquitectura: contiene una vista de la arquitectura del modelo de casos de uso, que representa los casos de uso significativos para la arquitectura. La vista de la arquitectura debera incluir aquellos casos de uso que describan alguna funcionalidad importante o crtica, o que impliquen algn requisito importante.

Glosario: es importante utilizar un glosario de trminos comunes para describir el sistema y as alcanzar un consenso entre los desarrolladores.

Prototipo de interfaz de usuario: los prototipos de interfaz de usuario nos ayudan a comprender y especificar las interaccione entre actores humanos y el sistema.

Flujos de trabajo de la captura de requisitos

A continuacin se presenta el flujo de trabajo de la captura de requisitos mediante un diagrama de actividad.

El analista de sistemas se encarga de encontrar actores y casos de uso en funcin de tres artefactos de entrada: el modelo de negocio, los requisitos adicionales y la lista de caractersticas. A partir de stos genera un esbozo del modelo de casos de uso y el glosario de trminos.

El arquitecto se encarga de priorizar los casos de uso en funcin de tres artefactos de entrada: el modelo de negocio, los requisitos adicionales y el glosario de trminos. A partir de stos genera la descripcin de la arquitectura.

El especificador de casos de uso se encarga de detallar los casos de uso en funcin de tres artefactos de entrada: el modelo de casos de uso, los requisitos adicionales y el glosario de trminos. A partir de stos genera los casos de uso detallados.

El diseador de la interfaz se encarga de prototipar la interfaz de usuario en funcin de cuatro artefactos de entrada: el modelo de casos de uso, los requisitos adicionales, los casos de uso detallados y el glosario de trmino. A partir de stos genera el prototipo de la interfaz de usuario.

Finalmente, el analista de sistemas se encarga de estructurar el modelo de casos de uso en funcin de cuatro artefactos de entrada: el modelo de casos de uso, los requisitos adicionales, los casos de uso detallados y el glosario de trminos. A partir de stos genera el modelo de casos de uso estructurado. Fase de anlisisDurante la fase de anlisis, analizamos los requisitos que se describieron en la captura de requ