REPORTE FINAL DEL PROYECTO DE INVESTIGACION148.206.53.84/tesiuami/UAMI12872.pdf · 2 OBJETIVOS La creación de un sistema automatizado para control escolar bajo la metodología de

REPORTE FINAL DEL PROYECTO DE INVESTIGACION

ALUMNO:

Juan Manuel Vázquez Orozco.

MATRICULA:

96323616

NOMBRE DEL PROYECTO:

”Desarrollo de sistemas utilizando los procesos PSP y TSP” NOMBRE DEL ASESOR:

Luis Fernando Castro Careaga

1

INDICE

OBJETIVOS ......................................................................................................2

PSP (Personal Software Process) ....................................................................3

Introducción ...................................................................................................3

Reporte R5 y conclusiones de desarrollo de PSP ..................................................4

TSP (Team Software Process)..........................................................................7

Introducción ...................................................................................................7

Flujo Detallado del TSP.....................................................................................7

Estrategias de Desarrollo. .................................................................................8

Roles de los miembros del equipo:.....................................................................8

Proceso de las juntas de lanzamiento .................................................................8

DESCRIPCION DEL PROBLEMA .......................................................................11

LANZAMIENTO DEL PROYECTO........................................................................ 13

MODULO DESARROLLADO. .............................................................................17

DESCRIPCIÓN ............................................................................................... 17

MODELO DE REQUERIMIENTOS ....................................................................... 18 MÓDULO MATERIAS.................................................................................... 18 MÓDULO PROFESORES ............................................................................... 27 MÓDULO HORARIOS................................................................................... 36 MÓDULO SUCURSALES ............................................................................... 44 MÓDULO SUCURSALES ............................................................................... 45 MÓDULO CURSOS ...................................................................................... 54

MODELO DE DISEÑO......................................................................................63

CONCLUSIONES .............................................................................................69

PROPUESTAS PARA LA MEJORA DEL PROCESO...............................................70

ANEXOS .........................................................................................................78

Modelo general de Casos de Uso...................................................................... 78

Modelo de Datos General ................................................................................ 79

BIBLIOGRAFIA...............................................................................................80

2

OBJETIVOS

La creación de un sistema automatizado para control escolar bajo la metodología de procesos PSP y TSP es una excelente oportunidad para mantener estándares de calidad a niveles altos. Ambos procesos exigen un desarrollo disciplinado, pero sobre todo predecible. Considerando estos preceptos se fijaron objetivos deseables pero realistas a tres niveles: Personales, equipo y sistema.

Los objetivos de equipo referentes al desempeño se fijaron tomando en cuenta el desempeño personal de cada miembro del equipo.

Objetivos personales • Mejora en la forma de desarrollar software • Emplear tecnologías de conexión remota proveídas por J2EE • Aplicar los conocimientos adquiridos en un proyecto que sea utilizado por usuarios.

Objetivos a nivel de equipo

• Terminación del Sistema de Administración Escolar en 4 meses a partir del 9 de marzo del 2005.

• Obtener una tasa de defectos de a lo más de 2 defectos/KLOC. • Obtener conocimientos homogéneos en las tecnologías, procesos y herramientas que se

utilicen durante la realización de SAECH (Sistema de Administración Escolar Coronet Hall). • Puntualidad en la realización de las juntas a lo largo del proyecto. • Utilización del Proceso de Software en Equipo (TSP) y de la Programación Extrema (XP). • Obtener una productividad de 80 LOC/hora, esto con el desarrollo en parejas. • Obtener un nivel de yield de 80%.

Objetivos a nivel de sistema

• El sistema deberá ser automatizado. • El sistema desarrollado deberá ser fácil de utilizar y de administrar. • Reducción del tiempo de proceso (administración) en un 90%. • El sistema deberá ser expandible a utilizarse vía Internet.

3

PSP (Personal Software Process)

Introducción El PSP (Personal Software Process ó Proceso Personal de Software) es una línea de trabajo de medición y análisis para ayudarle a caracterizar su proceso, también es un procedimiento definido que le ayuda a mejorar su desempeño en el desarrollo de software. El PSP muestra a los ingenieros como:

� Administrar la calidad de sus proyectos. Nos permite llegar a tener nivel 5 de CMM (Capability Maturity Model) que proporciona la línea de trabajo para la administración efectiva de procesos y asume que los profesionales de software seguirán métodos personales de manera disciplinada.

� Mejorar la estimación y planeación. Con la ayuda del PSP se logra obtener una mayor certeza del tiempo y tamaño de los proyectos de software que se realizarán.

� Reducir los defectos en sus productos. El PSP integra distintas fases, entre ellas las de revisiones de diseño y codificación, las cuales nos permiten obtener una disminución en la tasa de defectos de compilación y pruebas que son las que generan un mayor costo en el tiempo.

� Generar datos históricos. Nos provee de datos históricos, que pueden ser utilizados para planeación y establecimiento de metas.

� Utilizar Retroalimentación. El PSP permite al ingeniero de software utilizar la retroalimentación de su ejecución anterior utilizando las experiencias propias o de otros para obtener una mejoría personal.

El PSP puede ser aplicado a muchas partes del proceso de desarrollo de software, incluyendo:

� Desarrollo de programas pequeños. � Definición de requerimientos. � Escritura de documentación. � Pruebas de sistema. � Mantenimiento de sistema.

El PSP se divide en dos partes PSP I : Planeación y PSP II : Calidad.

PSP Parte 1: Planeación

PSP Parte II: Calidad

Introducción al proceso personal Medición del tamaño Estimación del tamaño Estimación basada en Proxy Estimación de recursos Proceso de Medición

Administración de defectos El proceso de diseño Verificación del diseño Crecimiento del PSP Proceso de desarrollo El uso del PSP

El uso del Proceso de Software Personal nos provee de algunas ventajas:

� Mayor Calidad en el producto. � Uso de bitácoras y plantillas. � Reducción en el error de estimación. � Reducción en los tiempos de pruebas. � Reducción mayor observada en los defectos. � Aumento en la productividad. � Desarrolladores motivados. � El uso del PSP como una herramienta de administración personal. � Los practicantes de PSP conducen a la creación de mejores equipos.

4

Reporte R5 y conclusiones de desarrollo de PSP De entre los objetivos mas importantes del PSP se tienen el control de calidad y el desarrollo de un mecanismo de estimación de tamaño de clases. Paralelamente se muestra la importancia de la planeación y se desarrollan hábitos de análisis y diseño que trasladan gran parte del esfuerzo del desarrollo al papel mas que a la codificación.

El proceso en su parte final cuenta con un último reporte, conocido como R5, en el cual se plasman los resultados finales y la proyección hacia el futuro. Todo lo anterior respaldado con números y ponderaciones, producto del proceso de aprendizaje de PSP sentando de esta manera las bases para una mejor comprensión del proceso actual y las mejoras en concreto que pueden llevarse a cabo en el futuro.

ÁREAS PRIORITARIAS DE MEJORA PERSONAL Cómo puedo hacer mi proceso más efectivo y eficiente?

Porcentaje de inserción de errores

0

87

0

83 86 85

60

87

4653

0.0

13.0 16.7 13.8 12.5 14.7

40.0 42.9 42.9

0.00

10

20

30

40

50

60

70

80

90

100

1 2 3 4 5 6 7 8 9 10

Código

Diseño

Las tareas donde se tuvo peor estimación fueron en las que hubo errores de comprensión de requerimientos y por ende errores de diseño, lo cual se traduce en costosas correcciones en fases posteriores. Así que para tener un proceso mas efectivo (menos errores) y eficiente (mayor productividad) La cantidad de errores de diseño va en aumento con las tareas, y hay cierta tendencia a bajar los errores de codificación. Mantener los errores de diseño bajos implica menor tiempo de corrección. Lograr la meta del 15% en errores de diseño se muestra como real.

Basados en mis datos históricos, cuales son algunas metas realistas para mí?

Total Defects

42.5535.81

14.29

28.09

14.564.40

21.93

7.81

22.5612.99

01020304050

1 2 3 4 5 6 7 8 9 10

Program Number

Def

ects

/KLO

C

5

La tendencia de defectos por KLOC se muestra a la baja, con el límite inferior de 4, pero en general están por el orden de 20 defectos/KLOC, considerando esta tendencia tener 15 defectos por KLOC sería una meta razonable. Si bien se han alcanzado menos defectos, no parece posible mantener una tasa tan baja, dado que requeriría un cambio radical en el proceso que de momento no es posible especificar por la dependencia de otras áreas (estimación de LOCS).

Defects Removed By Type

25

12 11

30 0 0 0 0 0

0

5

10

15

20

25

30

20 80 50 70 10 30 40 60 90 100

Los errores mas numerosos son los de tipo 20, se utiliza la siguiente clasificación:

21 Errores de escritura: minúsculas y mayúsculas. 22 Omisión: omitir partes de pseudocódigo 23 Uso incorrecto de objetos. 24 Comparación (casting) de objetos predefinidos 25 Errores de abarcamiento de código, breaks, llaves. 26 Métodos que no regresan el valor calculado, o se pasa un parámetro incorrecto por

error de captura

Errores de tipo 20

11

5

32 2 2

0

2

4

6

8

10

12

Escritura Omisión Uso de Objetos Comparación deobjetod

predefinidos

Abarcamientoobjetos

Métodos yresultados

La mayor cantidad de errores son los heredados de las tareas donde no existía revisión de código, esto ya se considera dentro de los checklists de revisión de código. Sin embargo para el abarcamiento de objetos y secciones de código se modifican los checklists existentes.

• Verificar el casting de variables y objetos especiales (Strings) • Observar que el objeto usado es del tipo correcto • Utilizar la inicialización correcta, no necesariamente el constructor • Los bloques de código de tamaño definido

Las subcategorías de los errores 80 son:

81 inicialización incorrecta de variables 82 asignación incorrecta a variables 83 Valores en la frontera 84 comportamiento no acorde con la conceptualización. 85 Referencia a objeto equivocado

6

Errores tipo 80

3 3 3

4

1

00.51

1.52

2.53

3.54

4.5

inicialización

de variables

asignación de

variables

valores de

frontera

comportamient

o errado

referencia a

objeto

equivocada

De lo anterior no se encuentra una tendencia especial sobre la fuente de errores, el estándar de diseño no requiere grandes modificaciones, solamente se identifican dos:

• Verificar el funcionamiento de clases: pruebas de escritorio • Verificar que el resultado generado es correctamente regresado.

PROPUESTA DE MEJORA FINAL Del análisis anterior se encontraron diversas áreas de mejora que una vez logradas darán como resultado un proceso confiable y de naturaleza predictiva.

• Buen entendimiento de los requerimientos • Mejora de la planeación • Diseño de clases modificables

El cambio en el proceso más importante se muestra en el Script de revisión rápida de planeación que no requiere de una fase extra.

Apegándose a los scripts y estándares se espera obtener los siguientes resultados en el proceso:

Estimación con margen de 6% de error Productividad de 70 LOC/h Yield del 60% Calidad de 12 defectos/KLOC

7

lanzamiento

Relanza-miento

Requerimientos

Diseño de alto nivel

Diseño detallado

Inspección

Inspección

Revisión

Pruebas unitarias

Pruebas de sistema

Inspección

Postmortem

Postmortem

Código Revisión Compilación

Inspección Postmortem

Postmortem Integración de pruebas

Relanza-miento

Relanza-miento

Requerimientos

Diseño de alto nivel

Implementación

Integración y pruebas de sistema

TSP (Team Software Process)

Introducción El TSP (Team Software Process o Proceso de Software en Equipo) es un marco de trabajo y un proceso estructurado para construir y guiar a los equipos de ingenieros en el desarrollo de software. El TSP contiene:

� Un proceso de construcción del equipo (team-building process) que guía a las metas del equipo, comité, metas de cohesión, y en la estructura del producto.

� Un proceso de trabajo de equipo (team-working process) que se enfoca en los procesos de ingeniería y prácticas utilizadas por el equipo.

Un prerrequisito para que un equipo utilice el TSP es un entendimiento de la ingeniería de software y los niveles de procesos aprendidos en el PSP. El TSP tiene cuatro fases de desarrollo principales:

� Requerimientos. � Diseño de Alto Nivel. � Implementación. � Pruebas.

Los proyectos de TSP pueden iniciar o finalizar en cualquier fase. � Desde los requerimientos a través de las pruebas de sistema. � Sólo requerimientos. � Sólo diseño de Alto Nivel. � Cualquier combinación.

Flujo Detallado del TSP. Los equipos de TSP necesitan de 3 a 15 personas, más el líder del equipo. Los equipos de TSP pueden ser:

� Solamente de software. � De Software y Hardware. � Múltiples Equipos.

8

Estrategias de Desarrollo. Las estrategias de desarrollo del TSP abarca :

� Desarrollo incremental. � Desarrollo iterativo. � Construcción múltiple o cíclico. � Trabajo en conjunto.

Roles de los miembros del equipo: El equipo de TSP comparte las responsabilidades del administrador del equipo a través de 8 roles definidos mas un líder de equipo, este último no tomará ninguno de los 8 roles restantes.

� Líder del equipo. Algunas de sus actividades son: dirigir al equipo, administración de los miembros del equipo, asesoría al equipo, manejo de calidad, manejo del proyecto.

� Administrador de Interfaz con el Cliente. Algunas de sus actividades son: enfoque con el cliente, manejo de los cambios en los requerimientos, establecimiento y mantenimiento de los estándares de requerimientos.

� Administrador de Diseño. Algunas de sus actividades son: dirigir el diseño, administrar los cambios en el diseño, establecer y mantener los estándares de diseño.

� Administrador de Proceso. Algunas de sus actividades son: soporte en el proceso, registro del proceso, análisis del proceso, problemas en el proceso, administración de las PIP.

� Administrador de Calidad. Algunas de sus actividades son: soporte en la calidad, registro de la calidad, análisis de la calidad.

� Administrador de Proyecto. Algunas de sus actividades son: dirigir las planeaciones del equipo, registrar el progreso del equipo.

� Administrador de Soporte. Algunas de sus actividades son: establecer las herramientas de soporte, manejo de la configuración, control de cambios.

� Administrador de Pruebas. Algunas de sus actividades son: planeación de las pruebas, soporte de pruebas, análisis de pruebas.

� Administrador de Implementación. Algunas de sus actividades son: dirigir la implementación, administrar los cambios en la implementación, establecer y mantener los estándares de implementación.

Proceso de las juntas de lanzamiento El propósito del lanzamiento (Launch) es producir un plan de equipo y estar de acuerdo a la administración para este plan, el objetivo principal del lanzamiento es construir un equipo que este listo para integrarse. La primera etapa del lanzamiento es para el equipo, este entenderá que preguntas de tienen que hacer.

9

El lanzamiento esta compuesto de 9 juntas o reuniones que se hará con todo el equipo:

1. En esta reunión se hará un estudio (marketing) o una presentación con el usuario y una administración con el equipo. En el marketing se describirá el producto que se necesita, la administración describe la importancia del proyecto, recursos/restricciones que el equipo tiene que hacer.

2. El equipo da las metas principales y su organización. El equipo revisa que se

presente la administración en la primera reunión e identifique las metas principales del equipo para el proyecto a realizar, el equipo de igual forma divide los roles de TSP a cada miembro en el que se hará responsable durante el proyecto.

3. En esta reunión se determina el trabajo para hacer, las estrategias para realizar el

trabajo y el proceso que se usara para hacer el proyecto.

4. El equipo construye un plan para identificar las tareas necesarias para el proyecto, la estimación del esfuerzo de cada tarea, la calendarización de las tareas basadas en las horas disponibles del equipo. Si el plan no satisface las metas, el equipo puede generar alguna propuesta alternativa.

5. El equipo construye un plan de calidad para el proyecto (por fase) cuantos defectos

serán introducidos y removidos. El equipo revisa de nuevo el plan de calidad y las metas para asegurarse de que hay consistencia y para hacer ajustes necesarios.

6. Las tareas para la próxima fase serán asignadas por los ingenieros, los ingenieros

construyen sus planes de trabajo, el equipo equilibra los trabajos completados, las tareas de la próxima fase con algún tiempo aproximado, el equipo une los planes de trabajo individual para formar un plan de equipo consolidado. Estos planes son usados por el equipo para guiar y dar un seguimiento del trabajo durante las próximas fases del proyecto.

7. El equipo identifica y evalúa riesgos que podría prevenir el equipo. Los riesgos son

documentados por un plan de equipo, y cada riesgo es asignado a un miembro del equipo para seguirle la pista durante el proyecto.

8. El equipo prepara una presentación de este plan al administrador. Si el equipo no

reúne la calendarización de las metas, el equipo incluye planes alternativos que llegaran a cerrarlo o reunirán metas administradas por agregar más recursos, se entregara una versión inicial, y seguirá una versión final.

El proceso de las Juntas de Lanzamiento

Día 1

1. Establecer metas de producto y de

negocio.

2. Asignar roles y definir metas de

equipo.

3. Producir estrategias de desarrollo.

Día 2

4. Construcción de planes top-down

5. Desarrollo de los planes de calidad.

6. Construcción de planes consolidados.

Día 3

7. Evaluación de riesgos.

8. Preparar la administración de la reunión informativa y

el reporte de lanzamiento.

Día 4

9. Revisión de la administración.

Postmortem del lanzamiento.

Nuevos Equipos: Revisión del proceso

de TSP

10

9. En la reunión 1 el administrador describe que es lo solicitado y pregunta al equipo para crear un plan de trabajo, en la reunión 9 el equipo da esta respuesta a la solicitud del administrador. El administrador prueba el plan de equipo para convencerse de que el equipo ha hecho bien el trabajo, aprovecha el plan de equipo o se realizan preguntas al equipo para examinar otras alternativas.

11

DESCRIPCION DEL PROBLEMA

La escuela de inglés Coronet Hall cuenta con un sistema de control escolar rudimentario, el registro de datos de alumnos, profesores y cursos de hace de forma manual llenando boletas de papel y archivándolas. Esta forma de administrar la información es muy lenta, lo cual genera aglomeraciones en fechas donde se requiere atender a muchas personas, un ejemplo es en fecha de inscripción a cursos, la cantidad de alumnos excede la capacidad de atención en mostrador.

La implementación de un control escolar automatizado que se base en la administración actual mejoraría la calidad de servicio y aumentaría la capacidad de atención. Además, puede obtenerse información a distancia con respecto a las sucursales, actualmente la única forma de acceder a esa información es presentarse personalmente en el sitio.

Además del desarrollo del sistema de control escolar se generarán manuales de utilización y se capacitará al personal administrativo.

El desarrollo del sistema será guiado por medio del Team Software Process, para adquirir conocimiento en este proceso de desarrollo, estimar tiempos con precisión y para brindar calidad en el producto terminado. El producto final será desarrollar el sistema llamado SAECH (Sistema de Administración Escolar Coronet Hall) que tiene como característica principal llevar el control escolar del colegio. El sistema esta divido en 8 módulos más un módulo de acceso al sistema, los cuales a su vez pueden constar de submódulos para facilitar el entendimiento e implementación, tales módulos son: Prerregistro, Inscripción, Reinscripción, Mantenimiento, Pagos, Cierres, Profesor y Consultas. El funcionamiento de estos módulos es explicado a continuación:

Prerregistro: Este módulo consiste en prerregistrar a los alumnos, esto es que puedan crear una nueva cuenta y que ingresen sus datos personales, así como del llenado de una encuesta de uso particular del colegio. A su vez permite que el usuario que ya haya creado una cuenta, pueda hacer modificaciones en sus datos. Este módulo es importante porque con los datos generados se realizará el proceso de inscripción. Inscripción: Una vez que ya tenemos los datos de los alumnos, y que el interesado quiera ingresar al colegio a realizar sus estudios, se procede a generar una matrícula, la cual será el indicador de que es alumno del colegio. Reinscripción: Este módulo es el que realiza las inscripciones de los alumnos, es decir, ya que se tiene una matrícula, podemos asignar un curso en específico y generar un estado de cuenta para el alumno. Pagos: Este módulo representa todos los movimientos efectuados en el colegio. Mediante el uso de este módulo se registran las ventas realizadas en el colegio por alumno, ya sea por curso, descuentos, libros, audiocasettes, credenciales, etc. y se genera un estado de cuenta para determinar el saldo por persona. Cierres: En este módulo se van a generar los reportes correspondientes a los movimientos generados en el colegio, los cierres se pueden efectuar en cualquier momento y estos indicarán las ventas totales realizadas hasta ese momento.

12

Mantenimiento: Este módulo consiste en generar diversos catálogos necesarios para la asignación de cursos, serán de gran utilidad para cuando se necesite anexar un nuevo profesor, horarios, etc. Se encuentra dividido en 5 submódulos:

� Altas, bajas y cambios de Materias. Se creará un catálogo de las materias impartidas por el colegio.

� Altas, bajas y cambios de Profesores. Se creará un catálogo de los profesores que imparten las clases en las distintas sucursales del colegio.

� Altas, bajas y cambios de Horarios. Se creará un catálogo de los distintos horarios manejados por el colegio, esto nos facilitará la asignación de cursos.

� Altas, bajas y cambios de Sucursales. Se creará un catálogo de las sucursales existentes, con la finalidad de saber en que sucursal se encuentra tomando clases un alumno.

� Altas, bajas y cambios de Cursos. Una vez que tenemos los catálogos anteriores, podemos crear un curso con los datos de la materia, el profesor que la imparte, el horario en que se da el curso y en que sucursal, además en este módulo se asignará el aula correspondiente.

Profesor: Este módulo será de gran utilidad para los profesores, pues en él se generarán las listas de los alumnos que existen en los cursos dados de alta, y se podrá registrar la asistencia de los alumnos así como de sus calificaciones. Consultas: Este módulo presentará todas las consultas de mayor interés tanto para el personal administrativo como para los mismos alumnos, pues en el podrán consultar las calificaciones obtenidas, etc. Módulo de acceso: Este módulo es el que permitirá el acceso al sistema. Dependiendo de los privilegios que tenga cada usuario es cómo podrá realizar las distintas actividades. También nos permitirá registrar un nuevo usuario.

13

LANZAMIENTO DEL PROYECTO Dentro del desarrollo del proyecto, se realizaron las diversas juntas de lanzamiento para establecer el trabajo a realizar, preparar los planes de equipo y administrarlos a lo largo del proyecto. Junta 1. En esta junta el coach de lanzamiento especificó los requerimientos del sistema generando un diagrama general de casos de uso (Anexo A). Se obtuvo información acerca del colegio y de los movimientos realizados de manera general. Junta 2. En esta junta se asignaron los roles del equipo y posteriormente se generaron las metas y objetivos tanto del equipo como del sistema. La siguiente tabla muestra a detalle las actividades realizadas en esta junta.

Hora : 15:31 Fecha : 28 de Febrero del 2005 Moderador :

Tania, Manuel Cano

Minuta : Gustavo

Hora : 15:38 Rol Titular Suplente

Líder del equipo Manuel Cano Tania Administrador de Diseño Jesús Urbina Roberto Administrador de Proceso Carlos Guadalupe Administrador de Calidad Uzziel Daniel Administrador de Proyecto Tania Gerardo Administrador de Soporte Javier Jesús Administrador de Interfaz con el Usuario

Juan Manuel Ricardo

Administrador de Pruebas Gustavo Manuel Cano Administrador de Implementación Arturo Gerardo

No. Objetivo Prioridad 1 Terminación del Sistema de Administración Escolar en

4 meses a partir del 9 de marzo del 2005 Alta

2 Obtener una tasa de defectos de a lo más de 2 defectos/KLOC.

Alta

3 Obtener conocimientos homogéneos en las tecnologías, procesos y herramientas que se utilicen durante la realización de SAECH (Sistema de Administración Escolar Coronet Hall).

Media

4 Puntualidad en la realización de las juntas a lo largo del proyecto.

Alta

5 Utilización del Proceso de Software en Equipo (TSP) y de la Programación Extrema (XP).

Alta

6 Obtener una productividad de 80 LOC/hora, esto con el desarrollo en parejas.

Alta

7 Obtener un nivel de yield de 80%. Alta 8 El sistema deberá ser automatizado. Alta 9 El sistema desarrollado deberá ser fácil de utilizar y de

administrar. Alta

10 Reducción del tiempo de proceso (administración) en un 90%.

Alta

11 El sistema deberá ser expandible a utilizarse vía Internet.

Media

14

Junta 3. En esta junta se generó una estrategia de desarrollo, básicamente se asigna un tamaño al sistema SAECH y se definen los ciclos de trabajo, la duración y los entregables para cada uno de ellos. Forma STRAT

• La duración estimada para desarrollar SAECH es de 4 meses. • Se manejaron ciclos con duración de 4 semanas, teniendo 4 ciclos en total.

Estimados Entregables y tamaño por ciclo(LOC)

Horas por ciclo

Módulo LOC Horas I II III IV I II III IV Prerregistro 1500 12.5 Inscripción 1500 12.5 Reinscripción 3500 25 Mantenimiento 8000 81.25 Pagos 2500 25 25 37.5 106.25 150 Cierres 3000 37.5 Profesor 1500 12.5 Consultas 4000 112.5 TOTAL 25500 318.75 3000 5000 10500 7000 Forma SUMS

15

Junta 4,5 y 6. En estas juntas se construyeron los planes necesarios para el desarrollo del proyecto, la estimación del esfuerzo y la calendarización, así como los planes de calidad que nos indicará la tasa de defectos y el plan de trabajo individual por módulo para formar el plan consolidado. Planes de Tareas. Forma Task

Planes de Calidad. Forma SUMQ

Forma Schedule.

16

Junta 7. Esta junta es muy importante, pues en ella se realiza una lista de los todos los posibles riesgos que el proyecto puede enfrentar, así como de la generación de planes de mitigación de los mismos. A continuación se presenta una lista de los riesgos y sus planes generados:

Riesgo Estrategia de Mitigación Prioridad Mal entendimiento de los requerimientos

1. Entrevistas con el cliente.

2. Preparar una reunión por semana donde se expongan las dudas correspondientes.

Alta

Incumplimiento de las actividades asignadas a los miembros del equipo

1. Reasignación de las tareas.

Media

Información de las juntas no adquirida por todos los miembros.

1. Cada junta generar un reporte de lo que se realizó, y agregarlo al pizarrón de información además de enviarlo por correo electrónico a todos los integrantes del equipo.

Media

Bajos conocimientos de la tecnología empleada

1. Generar equipos exploratorios de las tecnologías a utilizar, estudiando el tema 2 semanas y después exponerlo al equipo.

2. Autocapacitación en J2EE y EJB por 2 semanas y evaluar los conocimientos adquiridos.

3. Asignar a dos encargados del estudio de los servidores aplicativos y de evaluar el que mejor cubra nuestras necesidades.

Muy Alta

Este último riesgo es el que más prioridad presentaba y por lo tanto el que más se administró, por lo que nos produjo un atraso de 2 meses debido a la falta de conocimiento de la tecnología, dado que la capacitación nos llevó mucho tiempo así como la evaluación del servidor.

17

Mantenimiento de Cursos

Alta Curso Cambios Curso Eliminación Curso

Eliminación MateriasCambios MateriasAlta Materias

Mantenimiento Materias

Alta Horarios Cambios Horarios Eliminación Horarios

Mantenimiento Horarios

Mantenimiento Profesores

Alta Profesores Cambios Profesores Eliminación Profesores Alta Sucursales Cambios Sucursales Eliminación Sucursales

Mantenimiento Sucursales

MODULO DESARROLLADO.

DESCRIPCIÓN Al dividir el desarrollo de los módulos entre los integrantes del equipo fue elegido el módulo de mantenimiento, que consta de Altas, Bajas y Cambios de: Materias, Profesores, Horarios, Sucursales y Cursos. En el siguiente diagrama de Casos de Uso se muestra el módulo de Mantenimiento desglosado. Para cada uno de estos submódulos se realizó el análisis de requerimientos, el cual se muestra como sigue:

18

MODELO DE REQUERIMIENTOS

MÓDULO MATERIAS

CLAVE DEL CASO RPMCM01 - ALTA DE MATERIAS

PROYECTO: SAECH FECHA: 21/03/2005

AUTOR: JuVaz, RicBar CLAVE: RPMCM02

NIVEL ALCANCE Resumen muy general * Organización (caja negra) Resumen Organización (caja blanca)

* Actividad de Usuario Módulo Detalle Método

DESCRIPCIÓN BREVE Escenario ideal para dar de alta una nueva asignatura.

ACTORES

Actor Principal Personal Administrativo (P. A.)

Actores Secundarios

EVENTOS QUE LO INICIAN

1 Seleccionar la opción de Alta de Materias del Menú de Mantenimiento de Cursos.

FLUJO DE EVENTOS PRIMARIO

1 El Sistema despliega la pantalla de Alta de Materias.

2 El P.A. ingresa: a) Nombre. b) Clave c) Descripción. d) Duración. e) Predecesor.

3 El P.A. da clic en el botón de Aceptar.

4 El Sistema genera un Id. de Materia.

5 El Sistema registra la materia con los datos ingresados.

6 El Sistema muestra un mensaje de confirmación con Id de Materia generado.

7 El Sistema se prepara para capturar un nueva materia.

8 Fin de Caso.

FLUJO DE EVENTOS ALTERNATIVOS

1 Ninguno

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar de Alta una asignatura.

2 Este usuario debe de haber iniciado sesión al sistema.

POSCONDICIONES

1 Una nueva asignatura ha sido agregada a la Base de Datos.

DOCUMENTACIÓN ADJUNTA

Diagrama de Navegación de Pantallas

Modelo de Datos. Porcentaje de transacciones totales que cubre el caso: 16.66% Porcentaje de efectividad del proceso actual 0%

19

DIAGRAMA DE INTERFACES Pantalla de Alta de materias Mensaje de Generación de materia con éxito

20

Alta de Materias

Seleccion opcion Alta de Materias del Menu de


Ingreso de Datos

Mensaje de Error de Campos Faltantes

Aceptar

Mensaje de Error Materia Existente

Aceptar

Mensaje de Confirmación

Aceptar[ Campos Faltantes ]

Aceptar[ Materia Existente ]

Aceptar[ Campos Llenos y Materia No Existente ] / Generacion de Id y Guardado en BD

Cerrar

Aceptar / Limpia campos

Materia

IdMateria : IntegerNombre : StringClave : IntegerDescripcion : StringDuracion : StringPredecesor : String

DIAGRAMA DE NAVEGACION DE PANTALLAS CASO DE USO RPMCM01 – ALTA DE MATERIAS MODELO DE DATOS CASO DE USO RPMCM01 – ALTA DE MATERIAS

21

CLAVE DEL CASO RPMCM02 - MODIFICACION DE MATERIAS





DESCRIPCIÓN BREVE Escenario ideal para modificar la información de las asignaturas.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Modificación de Materias del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la pantalla de Modificación de Materias.

2 El P.A. selecciona la materia que desea modificar.

3 El Sistema despliega la información respectiva a la materia.

4 El P.A. modifica los datos correspondientes.

5 El P.A. da clic en Modificar.

6 El Sistema muestra un mensaje de confirmación de Modificación.

7 El Sistema actualiza la Base de Datos con la nueva información.

8 Fin de Caso.


1 Del Paso 6 si el usuario cancela la modificación, el sistema no genera ningún cambio

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para modificar una asignatura.


3 Debe de existir al menos una asignatura dada de Alta.

POSCONDICIONES

1 La actualización de la información de la materia en la Base de Datos.



Modelo de Datos.

Porcentaje de transacciones totales que cubre el caso: 16.66% Porcentaje de efectividad del proceso actual 0%

22

DIAGRAMA DE INTERFACES Pantalla de Modificación de Materias Pantalla Datos a Modificar Mensaje de Confirmación Mensaje de cambios generados

23

Pantalla Grid de Materias

Seleccion Modificacion de Materias del Menu de


Seleccionar Materia

Mensaje de Error

Ver[ Registro No Seleccionado ]Aceptar

Pantalla Modificación de Materias

Ver[ Registro Seleccionado ] / Inicializa Campos

Modifica Datos

Cancelar


Modificar[ Validacion Datos OK ]Cancelar

Mensaje de Éxito

Aceptar / Datos ModificadosAceptar / Actualiza Grid

Cerrar

Materia


DIAGRAMA DE NAVEGACION DE PANTALLAS CASO DE USO RPMCM02 – MODIFICACION DE MATERIAS MODELO DE DATOS CASO DE USO RPMCM02 – MODIFICACION DE MATERIAS

24

CLAVE DEL CASO RPMCM03 - ELIMINACION DE MATERIAS





DESCRIPCIÓN BREVE Escenario ideal para eliminar las materias existentes en la Base de Datos.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Eliminación de Materias del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la pantalla de Eliminación de Materias.

2 El P.A. selecciona la materia que desea eliminar.

3 El P.A. da clic en eliminar.

4 El Sistema muestra un mensaje de confirmación de Eliminación.

5 El Sistema elimina la materia seleccionada por el P.A. de la Base de Datos.

6 Fin de Caso.


1 Del Paso 4 si el usuario cancela la eliminación, el sistema no realiza ninguna acción.

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para eliminar una asignatura.


3 Debe de existir al menos una asignatura dada de Alta.

POSCONDICIONES

1 La eliminación del registro seleccionado en la Base de Datos.



Modelo de Datos.


25

DIAGRAMA DE INTERFACES Pantalla de eliminación de materias Mensaje de Confirmación de eliminación Pantalla de Eliminación de Materias Actualizada

26

Pantalla Grid Eliminación de Materias

Seleccion Eliminación de Materias del Menu de Mantenimiento de

Cursos

Selecciona Materia

Mensaje de Error

Aceptar

Confirmación de Eliminación

Aceptar / Registro Eliminado de BD y Actualiza Grid

Cancelar

Eliminar[ Registro No Seleccionado ]

Eliminar[ Registro Seleccionado ]

Cerrar

Materia


DIAGRAMA DE NAVEGACION DE PANTALLAS CASO DE USO RPMCM03 – ELIMINACION DE MATERIAS MODELO DE DATOS CASO DE USO RPMCM03 – ELIMINACION DE MATERIAS

27

MÓDULO PROFESORES CLAVE DEL CASO RPMCP01 - ALTA DE PROFESORES


AUTOR: JuVaz, RicBar CLAVE: RPMCP01 NIVEL ALCANCE Resumen muy general * Organización (caja negra) Resumen Organización (caja blanca)


DESCRIPCIÓN BREVE Escenario ideal de captura de datos de profesores.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Alta de Profesores del Menú de Mantenimiento de Cursos.

2


1 El Sistema despliega la pantalla de Alta de Profesores.

2 El P. A. captura : a) Nombre. b) Apellido Paterno y Materno. c) Dirección. d) RFC. e) CURP f) Correo electrónico. g) Teléfono 1 (Casa). h) Teléfono 2 (Oficina). i) Teléfono 3 (Celular).

3 El Sistema valida la entrada de cada campo.

4 El Sistema genera el Id de Profesor.

5 El Sistema muestra un mensaje de información con el Id generado.

6 El Sistema se prepara para agregar un nuevo profesor.

7 Fin de Caso


Ninguno

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar de Alta a un Profesor.


POSCONDICIONES

1 Un nuevo Profesor ha sido agregado y dado de Alta.




28

DIAGRAMA DE INTERFACES Pantalla Alta de Profesores Mensaje de generación de un nuevo registro con éxito

29

Alta de ProfesoresSelección Alta de

Profesores del Menú de Mantenimiento de

Cursos

Introduce Datos

Mensaje de Error

Aceptar

Mensaje de Éxito

Aceptar / Limpia Campos

Aceptar[ ValidaciónKO ]

Aceptar[ ValidaciónOK ] / Genera Id Profesor

Cancelar

Profesor

IdProfesor : IntegerNombre : StringApPaterno : StringApMaterno : StringRFC : StringCURP : StringCalle : StringColonia : StringNumero : IntegerDelegacion : StringCodPostal : LongEmail : StringTelefono1 : StringTelefono2 : StringTelefono3 : String

DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCP01 – ALTA DE PROFESORES MODELO DE DATOS CASO DE USO RPMCP01 – ALTA DE PROFESORES

30

CLAVE DEL CASO RPMCP02 - MODIFICACION DE PROFESORES




DESCRIPCIÓN BREVE Escenario ideal de modificación a la información de los profesores.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Modificación de Profesores del Menú de Mantenimiento de Cursos.

2


1 El Sistema despliega la pantalla de Modificación de Profesores.

2 El P.A. selecciona el Profesor a cambiar la información.

3 El Sistema muestra los datos que corresponden al profesor seleccionado.

4 El P.A. cambia la información deseada.

5 El P.A. da clic en el botón de Modificar.

6 El Sistema actualiza la Base de Datos con la nueva información.

7 Fin de Caso


Ninguno

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para poder modificar a un Profesor.


3 Debe de existir al menos un profesor dado de Alta.

POSCONDICIONES

1 Información actualizada del profesor seleccionado.



Modelo de Datos.


31

DIAGRAMA DE INTERFACES Pantalla de Modificación de Profesores Pantalla de Datos a Modificar Mensaje de Confirmación

32

Pantalla Grid de Profesores

Selección opción Modificación de

Profesores del Menú de Mantenimiento de

Cursos

Seleccionar Profesor

Mensaje de Error

Pantalla Modificación de Profesores

Modifica Datos


Cancelar

Aceptar / Datos Modificados y Actualiza Grid

Ver[ Registro No Seleccionado ]


Cerrar

Aceptar[ Validación Datos OK ]

Cancelar

Profesor


DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCP02– MODIFICACION DE PROFESORES

MODELO DE DATOS CASO DE USO RPMCP02– MODIFICACION DE PROFESORES

33

CLAVE DEL CASO RPMCP03 - ELIMINACION DE PROFESORES




DESCRIPCIÓN BREVE Escenario ideal para la eliminación de la información de los profesores.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Eliminación de Profesores del Menú de Mantenimiento de Cursos.

2


1 El Sistema despliega la pantalla de Eliminación de Profesores.

2 El P.A. selecciona del Grid el Profesor a eliminar la información

3 El P.A. da clic en el botón de Eliminar.

4 El Sistema muestra pantalla de Confirmación de Eliminación.

5 El P.A. confirma la eliminación del Registro.

6 El Sistema elimina de la Base de Datos el registro seleccionado.

7 Fin de Caso


1 Del paso 4 si el Usuario cancela la eliminación, el registro permanece en la Base de Datos.

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para poder eliminar a un Profesor.


3 Debe de existir al menos un profesor dado de Alta.

POSCONDICIONES

1 Información eliminada del profesor seleccionado.



Modelo de Datos.


34

DIAGRAMA DE INTERFACES Pantalla de eliminación de Profesores Pantalla de eliminación con confirmación

35

Pantalla Grid Eliminación de Profesores

Seleccion Eliminación de Profesores del Menú de Mantenimiento de Cursos

Seleccionar Profesor

Mensaje de Error

Aceptar



Cancelar



Cerrar

Profesor


DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCP03– ELIMINACION DE PROFESORES

MODELO DE DATOS CASO DE USO RPMCP03– ELIMINACION DE PROFESORES

36

MÓDULO HORARIOS CLAVE DEL CASO RPMCH01 - ALTA DE HORARIO


AUTOR: JuVaz, RicBar CLAVE: RPMCH01



DESCRIPCIÓN BREVE Escenario ideal de alta de Horarios

ACTORES


Actores Secundarios


1 Seleccionar la opción de Alta de Horarios del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la pantalla de Alta de Horarios.

2 El P. A. define : a) Clave de horario b) Días de la semana. c) Hora de inicio y final de cada día. d) Descripción del horario

3 El sistema valida los campos calculados

4 El Sistema valida que no exista un horario generado con la clave definida.

5 El Sistema genera un Id de Horario.

6 El Sistema registra el Horario con los datos seleccionados.

7 El Sistema muestra un mensaje de confirmación con Id de Horario generado.

8 El Sistema se prepara para capturar un nuevo horario.

9 Fin de Caso.


3 Si el sistema identifica un error en los campos muestra un mensaje de error y regresa al paso 2

4 Si ya existe un Horario con la clave horario muestra un mensaje de error y regresa al paso 2

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar de Alta a un Horario


POSCONDICIONES

1 Un nuevo horario ha sido agregado y dado de Alta.




37

DIAGRAMA DE INTERFACES Pantalla alta de horarios

Mensaje de confirmación éxito

Mensaje de error de horario Mensaje Error campos faltantes o erróneos

38

altaHorarios

mensajeOk

Alta de horarios

Aceptar

mensajeKOCampos

mensajeKOClave

validaciónClavevalidaciónCamposOK

AceptarValidaciónCamposKO

ValidaciónClaveOK

ValidaciónClaveKO

Aceptar

HorariosDetalle

Dia : IntegerHoraInicio : DateHoraFinal : DateIDHorario : Integer

Horarios

IDHorario : IntegerClaveHorario : StringDescripción : String

1..1 1..n

DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCH01– ALTA DE HORARIOS

MODELO DE DATOS CASO DE USO RPMCH01– ALTA DE HORARIOS

39

CLAVE DEL CASO RPMCH02 - MODIFICACION DE HORARIO





DESCRIPCIÓN BREVE Escenario ideal de Cambio de Horarios

ACTORES


Actores Secundarios


1 Seleccionar la opción de Cambio de Horarios del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la lista de Horarios dados de alta

2 El P. A. elige un horario y oprime modificar

3 El Sistema despliega la pantalla de detalle de Horarios.

4 El P. A. redefine : a) Días de la semana. b) Hora de inicio y final de cada día. c) Descripción del horario

5 El Sistema valida que no exista un horario generado con los datos definidos.

6 El Sistema registra el Horario con los datos seleccionados y el Id de Horario.

7 El Sistema muestra un mensaje de confirmación con Id de Horario modificado.

8 El Sistema muestra la lista de Horarios dados de Alta.

9 Fin de Caso.


2a Si el P. A. oprime cancelar va a 9

4a Si el P.A. oprime cancelar va a 1

6a Si hay errores se muestra un mensaje de error y va a 3

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para modificar un Horario


POSCONDICIONES

1 Un Horario ha sido modificado.




40

DIAGRAMA DE INTERFACES Pantalla de Modificación de Horarios Pantalla Modificación de Datos


Mensaje de cambios generados con éxito Mensaje de Error en los campos

41

validaciónKO

listaModificaciónmodificaciónHorarios pantallaModificaciónHorariosModificar

mensajeConfirmación

mensajeError

mensajeOK

Aceptar

Aceptar

Cancelar

Aceptar

validaciónOK

HorariosDetalle


Horarios


1..1 1..n

DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCH02– MODIFICACION DE HORARIOS

MODELO DE DATOS CASO DE USO RPMCH02 – MODIFICACION DE HORARIOS

42

CLAVE DEL CASO RPMCH03 - ELIMINACION DE HORARIO





DESCRIPCIÓN BREVE Escenario ideal de baja de Horarios

ACTORES


Actores Secundarios


1 Seleccionar la opción de Baja de Horarios del Menú de Mantenimiento de Cursos.


1 El sistema despliega una lista con todos los Horarios dados de alta

2 El usuario elige un horario y oprime el botón eliminar

3 El sistema despliega un mensaje de confirmación

4 El usuario oprime aceptar

5 El sistema elimina de la base de datos la sucursal

6 Fin de caso


4a Si el usuario oprime cancelar, se regresa al paso 1

5a Si el sistema encuentra referencias a ese horario muestra un mensaje de error y regresa a 1

2a Si el PA oprime cancelar va a 6

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar de Baja un Horario


POSCONDICIONES

1 Una horario ha sido eliminada del sistema



Modelo de Datos.


43

DIAGRAMA DE INTERFACES

Pantalla de lista de Horarios a Eliminar


Mensaje de Eliminación con éxito

44

listaHorarios mensajeConfirmación

Cancelar

mensajeOK

Aceptar

Aceptar

Eliminar

Cancelar

bajaHorarios

HorariosDetalle


Horarios


1..1 1..n

DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCH03– ELIMINACION DE HORARIOS

MODELO DE DATOS CASO DE USO RPMCH03 – ELIMINACION DE HORARIOS

45

MÓDULO SUCURSALES CLAVE DEL CASO RPMCS01 - ALTA DE SUCURSAL


AUTOR: JuVaz, RicBar CLAVE: RPMCS02



DESCRIPCIÓN BREVE Escenario ideal de alta de Sucursales

ACTORES


Actores Secundarios


1 Seleccionar la opción de Altas de Sucursales del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la pantalla de Generación de Sucursales.

2 El P. A. captura la información de la Sucursal a) Clave de Sucursal b) Nombre c) Descripción d) Teléfono

3 El Sistema valida que los campos estén correctamente capturados los campos

4 El Sistema valida que no exista una Sucursal generada con los datos capturados.

5 El Sistema genera un Id de Sucursal.

6 El Sistema registra la Sucursal con los datos capturados.

7 El Sistema muestra un mensaje de confirmación con Id de Sucursal generado.

8 El Sistema se prepara para capturar una nueva Sucursal

9 Fin de Caso.


3a Si el sistema encuentra algún error de captura muestra un mensaje y va a 2

4a Si existe una Sucursal con la clave de sucursal capturada muestra un mensaje y va a 2

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar de Alta una Sucursal


POSCONDICIONES

1 Una nueva sucursal ha sido agregada y dada de Alta.



Modelo de Datos.


46


Pantalla de captura de datos

Mensaje sucursal creada

Mensaje Error captura de datos

Mensaje Error sucursal existente

47

capturaDatos mensajeCreada

mensajeErrorCaptura

mensajeErrorSucursal

CapturaKO

validacionKO

generacionOK

Sucursal

IDSucursalClaveSucursalNombreDescripcionTelefono

DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCS01– ALTA DE SUCURSALES

MODELO DE DATOS CASO DE USO RPMCS01– ALTA DE SUCURSALES

48

CLAVE DEL CASO RPMCS02 - MODIFICACION DE SUCURSALES





DESCRIPCIÓN BREVE Escenario ideal de cambios a Sucursales

ACTORES


Actores Secundarios


1 Seleccionar la opción de Cambio de Sucursales del Menú de Mantenimiento de Cursos.


1 El sistema despliega una lista con todas las sucursales dadas de alta

2 El usuario elige una sucursal y oprime el botón modificar

3 El sistema despliega los detalles de la sucursal

4 El usuario captura los cambios y oprime modificar

5 El sistema pide al usuario confirmación

6 El usuario confirma la modificación

7 El Sistema valida que los campos estén correctamente capturados los campos

8 El sistema actualiza la información en la base de datos

9 El sistema muestra un mensaje de confirmación

10 Fin de caso



7a Si el sistema encuentra errores muestra un mensaje y regresa a 3

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar Cambios a una Sucursal


POSCONDICIONES

1 Una sucursal ha sido modificada en el sistema



Modelo de Datos.


49


Pantalla lista de sucursales

Pantalla modificación de datos

Mensaje de confirmación de cambios

Mensaje cambios generados exitósamente

50

listaSucursales modif icacionSucursalesmodif icar

cancelar

conf irmacionCambiosmodif icar

cancelar

mensajeOK

OK

Sucursal


DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCS02– MODIFICACION DE SUCURSALES

MODELO DE DATOS CASO DE USO RPMCS02– MODIFICACION DE SUCURSALES

51

CLAVE DEL CASO RPMCS03 - ELIMINACION DE SUCURSAL





DESCRIPCIÓN BREVE Escenario ideal de baja de Sucursales

ACTORES


Actores Secundarios


1 Seleccionar la opción de Baja de Sucursales del Menú de Mantenimiento de Cursos.


1 El sistema despliega una lista con todas las sucursales dadas de alta

2 El usuario elige una sucursal y oprime el botón eliminar

3 El sistema despliega un mensaje de confirmación

4 El usuario oprime aceptar

5 El sistema elimina de la base de datos la sucursal

6 Fin de caso



5a Si el sistema encuentra referencias a esa sucursal muestra un mensaje de error y regresa a 1

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar de Baja una Sucursal


POSCONDICIONES

1 Una sucursal ha sido eliminada del sistema



Modelo de Datos.


52


Pantalla lista de Sucursales

Mensaje de Confirmación de Eliminación

Mensaje eliminación exitósa

53

listaDeSucursales mensajeConfirmacionEliminacion

mensajeEliminacionOK

eliminar

KO

OK

KO

Sucursal


DIAGRAMA DE ESTADOS DE PANTALLAS CASO DE USO RPMCS03– ELIMINACION DE SUCURSALES

MODELO DE DATOS CASO DE USO RPMCS03– ELIMINACION DE SUCURSALES

54

MÓDULO CURSOS CLAVE DEL CASO RPMCC01 - ALTA DE CURSOS


AUTOR: JuVaz, RicBar CLAVE: RPMCC01



DESCRIPCIÓN BREVE Escenario ideal de alta de Cursos.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Alta de Cursos del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la pantalla de Alta de Cursos.

2 El P. A. selecciona : a) Materia. b) Horario. c) Profesor. d) Sucursal. e) Aula.

3 El Sistema valida que no exista un curso generado con los datos en el trimestre seleccionado.

4 El Sistema genera un Id de Curso.

5 El Sistema registra el curso con los datos seleccionados.

6 El Sistema muestra un mensaje de confirmación con Id de curso generado.

7 El Sistema se prepara para capturar un nuevo curso.

8 Fin de Caso.


Ninguno

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para dar de Alta a un Curso


3 Deben existir al menos una sucursal, una materia, un horario y un profesor dados de alta.

POSCONDICIONES

1 Un nuevo curso ha sido agregado y dado de Alta.




55

DIAGRAMA DE INTERFACES Interfaz Alta de Cursos Pantalla de generación de curso con éxito Pantalla de Mensaje de Error

56

Alta de Cursos

Seleccion Alta de Grupos del Menu de Mantenimiento de

Cursos

Seleccion Datos Correspondientes al Curso

Mensaje de Error

Aceptar


Cancelar

Mensaje de Curso Generado

Aceptar / Genera Id de Curso y Guardado en BDAceptarAceptar[ Curso Existente ]

Aceptar[ Curso No Existente ]

Cerrar

Materia

IdMateriaNombreDescripcionClaveDuracionPredecesor

Profesor

IdProfesorNombreApellidoPaternoApellidoMaternoCalleColoniaNumeroDelegacionCodPostalRFCCURPCorreoElectronicoTelefonoCasaTelefonoOficinaTelefonoCelular

Sucursal

IdSucursalClaveSucursalNombreDescripcionTelefono

*

1

*2

*

1

Curso

IdCursoIdMateria(FK)IdHorario(FK)IdProfesorG(FK)IdProfesorC(FK)IdSucursal(Fk)Aula

*

1

Horario

IdHorariodescripcion

1 *

DetalleHorario

IdHorarioDiaHoraInicioHoraFin

DIAGRAMA DE NAVEGACION DE PANTALLAS CASO DE USO RPMCC01 – ALTA DE CURSO MODELO DE DATOS CASO DE USO RPMCC01 – ALTA DE CURSO

57

CLAVE DEL CASO RPMCC02 - MODIFICACION DE CURSOS





DESCRIPCIÓN BREVE Escenario ideal para la modificación de la información de los cursos.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Modificación de Cursos del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la pantalla de Modificación de Cursos.

2 El P.A. selecciona el curso al cual desea modificar la información.

3 El Sistema despliega la información que corresponde al curso seleccionado.

4 El P.A. modifica la información del curso.

5 El P.A. da clic en el botón de Modificar.

6 El Sistema muestra un mensaje de confirmación de modificación.

7 El P.A. confirma modificación del Curso

8 El Sistema actualiza la información del curso en la Base de Datos


1 Del paso 6 si el usuario cancela la modificación, la información no se modifica de la Base de Datos.

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para poder modificar un Curso


3 Deben existir al menos un Curso dado de Alta.

POSCONDICIONES

1 Información actualizada del curso que modificó el P.A.



Modelo de Datos.


58

DIAGRAMA DE INTERFACES Pantalla de tabla de cursos Pantalla modificación de datos Mensaje confirmación

59

Pantalla Grid de Cursos

Seleccion Modificación de Cursos del Menu de Mantenimiento de Cursos

Seleccionar Curso

Mensaje de Error

Ver[ Registro No Seleccionado ]Aceptar

Pantalla Modificación de Cursos


Modifica Datos


Cancelar

Aceptar / Datos Modificados y Actualiza Grid

Cerrar

Aceptar[ Validación Datos OK ]

Cancelar

Materia


Profesor


Sucursal


*

1

*2

*

1

Curso


*

1

Horario


1 *

DetalleHorario


DIAGRAMA DE NAVEGACION DE PANTALLAS CASO DE USO RPMCC02 – MODIFICACION DE CURSO MODELO DE DATOS CASO DE USO RPMCC02 – MODIFICACION DE CURSO

60

CLAVE DEL CASO RPMCC03 - ELIMINACION DE CURSOS





DESCRIPCIÓN BREVE Escenario ideal para la eliminación de los cursos.

ACTORES


Actores Secundarios


1 Seleccionar la opción de Eliminación de Cursos del Menú de Mantenimiento de Cursos.


1 El Sistema despliega la pantalla de Eliminación de Cursos.

2 El P.A. selecciona del Grid el curso a eliminar.

3 El P.A. da clic en el botón de Eliminar.

4 El Sistema muestra pantalla de confirmación de eliminación de curso.

5 El P.A. confirma eliminación.

6 El Sistema elimina de la Base de Datos el curso seleccionado.

7 Fin de Caso.


1 Del paso 4 si el usuario cancela la eliminación, la información no se elimina de la Base de Datos.

PRECONDICIONES

1 Debe existir un usuario con los privilegios necesarios para poder eliminar un Curso


3 Deben existir al menos un Curso dado de Alta.

POSCONDICIONES

1 Curso eliminado de la Base de Datos.



Modelo de Datos.


61

DIAGRAMA DE INTERFACES Pantalla de tabla de cursos Mensaje Confirmación de eliminación Pantalla tabla actualizada

62

Pantalla Grid Eliminación de Cursos

Seleccion Eliminación de Cursos del Menú de Mantenimiento de Cursos

Selecciona Curso

Mensaje de Error

Aceptar


Cancelar




Cerrar

Materia


Profesor


Sucursal


*

1

*2

*

1

Curso


*

1

Horario


1 *

DetalleHorario


DIAGRAMA DE NAVEGACION DE PANTALLAS CASO DE USO RPMCC03 – ELIMINACION DE CURSO MODELO DE DATOS CASO DE USO RPMCC03 – ELIMINACION DE CURSO

63

CiMenu

Personal

Adm

inistrativo

CiAltaSucursal

CnAltaSucursal

SucursalBean

Opc. Alta Sucursal

Show( )

Ingresa Datos

Aceptar

validaCam

pos( )

getDataSucursal(voSucursal)

getDataSucursal(voSucursal)

1.-El usuario selecciona la opción de Altas de Sucursales

del M

enú de Mantenimiento de Cursos.

2.-El Sistema despliega la pantalla de Generación de

Sucursales.

3.-El P. A. captura la información de la Sucursal

a)Clave de Sucursal

b)Nom

bre

c)Descripción

d)Teléfono

4.- El P.A. oprim

e el botón de Aceptar.

5.-El Sistema valida que los campos estén correctamente

capturados los campos.

6.-El Sistema valida que no exista una Sucursal generada

con los datos capturados.

7.-El Sistema genera un Id de Sucursal.

8.-El Sistema registra la Sucursal con los datos

capturados.

9.-El Sistema muestra un mensaje de confirm

ación con Id

de Sucursal generado.

10.-El Sistema se prepara para capturar una nueva Sucursal

11.-Fin de Caso.

agregaSucursal(voSucursal)

agregaSucursal(voSucursal)

mensajeExito( )

limpiaCam

pos( )

MODELO DE DISEÑO DIAGRAMA DE SECUENCIA CASO DE USO RPMCS01 – ALTA SUCURSAL

64

CnAltaSucursal

voSucursal : VOSucursal

validaCam

pos()

getDataSucursal()

agregaSucursal()

CiMenu

<<event>> Alta de Sucursal()

CiAltaSucursal


show()

<<event>> aceptar()

mensajeExito()

limpiaCam

pos()

VOSucursal

IdSucursal : Integer

ClaveSucursal : String

Nom

bre : String

Descripcion : String

Telefono : String

VOSucursal()

void setIdSucursal()

void setClaveSucursal()

void setNom

bre()

void setDescripcion()

void setTelefono()

Integer getIdSucursal()

String getClaveSucursal()

String getNom

bre()

String getDescripcion()

String getTelefono()

Sucursal


getDataSucursal()

agregaSucursal()

SucursalBean


sessionContext : SessionContext

ejbCreate()

ejbRem

ove()

ejbActivate()

ejbPassivate()

setSessionContext()

getDataSucursal()

agregaSucursal()

SucursalHom

e

Sucursal create()

DIAGRAMA DE CLASES CASO DE USO RPMCS01 – ALTA SUCURSAL

65

CiMenu

Personal

Administrativo

CiTablaModificacionSu

cursal

CiModificacion

Sucursal

CnModificacion

Sucursal

SucursalBean

1.-Seleccionar la opción de Cambio de

Sucursales del Menú de Mantenimiento de

Cursos.

2.-El sistema despliega una lista con todas las

sucursales dadas de alta

3.-El usuario elige una sucursal y oprime el

botón modificar

4.-El sistema despliega los detalles de la

sucursal

5.- El usuario captura los cambios y oprime

modificar

6.-El sistema pide al usuario confirmación

7.-El usuario confirma la modificación

8.-El Sistema valida que los campos estén

correctamente capturados

9.-El sistema actualiza la información en la

base de datos

10.-El sistema muestra un mensaje de

confirmación

11.-Fin de caso

Opc. Cambio de Sucursales

Show( )

getDataSucursal()

getDataSucursal()

initTable()

Selecciona Sucursal

Modificar

show(voSucursal)

initFields()

Ingreso de Nuevos Datos

Modificar

mensajeConfirmacion()

Aceptar

validaCampos()

modificaSucursal(voSucursal)

modificaSucursal(voSucursal)

mensajeExito()

close()

close()

DIAGRAMA DE SECUENCIA CASO DE USO RPMCS01 – MODIFICACION DE SUCURSAL

66

CiMenu

<<event>> Cambio de Sucursal()


(from AltaSucursal)

CiTablaModificacionSucursal

show()

<<event>> Seleccion Sucursal()

<<event>> Modificar()

initTable()

close()

CiModificacionSucursal


show()

initFields()

<<event>> IngresoDatos()

<<event>> Modificar()


<<event>> Aceptar()

mensajeExito()

close() VOSucursal



Nombre : String


Telefono : String

VOSucursal()



void setNombre()


void setTelefono()



String getNombre()



(from AltaSucursal)

CnModificacionSucursal


getDataSucursal()

validaCampos()

modificaSucursal()

Sucursal


getDataSucursal()

agregaSucursal()

modificaSucursal()

(from AltaSucursal)

SucursalHome

Sucursal create()

(from AltaSucursal)

SucursalBean



ejbCreate()

ejbRemove()

ejbActivate()

ejbPassivate()

setSessionContext()

getDataSucursal()

agregaSucursal()

modificaSucursal()

(from AltaSucursal)

DIAGRAMA DE CLASES CASO DE USO RPMCS02 – MODIFICACION DE SUCURSAL

67

Personal

Adm

inistrativo

CiMenu

CiEliminacionSucursal

CnEliminacion

Sucursal

SucursalBean

1.-Seleccionar la opción de Baja de

Sucursales del M

enú de Mantenimiento de

Cursos.

2.-El sistema despliega una lista con todas

las sucursales dadas de alta

3.-El usuario elige una sucursal y oprime el

botón eliminar

4.-El sistema despliega un mensaje de

confirm

ación

5.-El usuario oprime aceptar

6.-El sistema elimina de la base de datos la

sucursal

7.-Fin de caso

Opc. Baja de Sucursales

show()

getListaSucursal()

getListaSucursal()

initListSucursal()

Selecciona Sucursal

Eliminar


Aceptar

eliminaSucursal(voSucursal)

eliminaSucursal(voSucursal)

mensajeExito()

close()

DIAGRAMA DE SECUENCIA CASO DE USO RPMCS03 – ELIMINACION DE SUCURSAL

68

CiMenu

<<event>> Cam

bio de Sucursal()


<<event>> Baja de Sucursal()

(from AltaSucursal)

CiEliminacionSucursal

show()

initListSucursal()


mensajeExito()

close()

<<event>> SeleccionaSucursal()

<<event>> Eliminar()

<<event>> Aceptar()

VOSucursal



Nom

bre : String


Telefono : String

VOSucursal()



void setNom

bre()


void setTelefono()



String getNom

bre()



(from AltaSucursal)

CnEliminacionSucursal


getListaSucursal()

eliminaSucursal()

SucursalHom

e

Sucursal create()

(from AltaSucursal)

Sucursal


getDataSucursal()

agregaSucursal()

modificaSucursal()

getListaSucursal()

eliminaSucursal()

(from AltaSucursal)

SucursalBean



ejbCreate()

ejbRem

ove()

ejbActivate()

ejbPassivate()

setSessionContext()

getDataSucursal()

agregaSucursal()

modificaSucursal()

getListaSucursal()

eliminaSucursal()

(from AltaSucursal)

DIAGRAMA DE CLASES CASO DE USO RPMCS03 – ELIMINACION DE SUCURSAL

69

CONCLUSIONES

Trabajar con PSP mejora los fundamentos para el desarrollo de software, son conocidas las múltiples deficiencias que se tienen al concebir y construir programas y sistemas, dentro de ellas la más importante es mezclar el proceso de diseño, codificación y pruebas.

Separar estas etapas, agregar otras (diseño de alto nivel y análisis posterior) y organizarlas mediante un proceso formal mejora notablemente la calidad del producto final; considerando como calidad un conjunto de características deseables en un producto de esta índole: pocos errores, tiempo de desarrollo predecible, ajuste a requerimientos y capacidad de repetir otros desarrollos en las mismas condiciones. Una cualidad extra sumamente importante es la generación de documentación durante el proceso, lo cual agrega mantenibilidad, aspecto muy importante dentro de una industria que requiere de ajustes, cambios y mejoras en el producto final.

TSP prometía obtener estos mismos resultados a nivel de equipo, pero el factor tecnológico fue adverso. La escasa experiencia en tecnología de servidores aplicativos tuvo amplias repercusiones, desde la instalación del servidor de aplicaciones hasta el desarrollo de los módulos. La capacitación y búsqueda de información tomaron mucho más tiempo del esperado, al asumir el riesgo de emplear una tecnología desconocida para los miembros del equipo erramos en el cálculo de la asimilación de la curva de aprendizaje. Como resultado hubo un retraso de 2 meses en las entregas iniciales.

Debe decirse que una vez que se logró asimilar el conocimiento de la nueva tecnología se estabilizaron los tiempos de desarrollo, logrando un avance que se ajustó mejor a lo planeado en tiempo y calidad.

Cabe decir que para muchos miembros del equipo esta demora por cuestiones tecnológicas fue desalentadora, así que se alejaron del compromiso con el equipo y dejaron de asistir a las juntas.

El TSP es un proceso rígido, y no fue fácilmente aceptado por los miembros del equipo que no habían sido capacitados en PSP, principalmente por no estar convencidos de los beneficios de la documentación. Es un proceso que debería adoptarse gradualmente, no es recomendable el adoptarlo de manera brusca y hacerlo así con TSP puede hacer parecer engorroso el uso de tantos formatos de documentación.

Al emplear el TSP en un desarrollo en conjunto se muestra una clara división de trabajo que aporta beneficios, se obliga a ser organizado en aspectos que afectan a todo el equipo, como el mantenimiento y evolución de la base de datos: Un solo responsable hace las modificaciones pertinentes, o la interfaz del usuario: Solamente un par de representantes asisten a las reuniones con el usuario final. Los resultados son claros: Control sobre la versión de base de datos en el primer caso y confianza por parte del usuario final en el segundo.

Las juntas iniciales del TSP son cruciales para consolidar el equipo, desde esa prematura forma de trabajo se logra compromiso con cada compañero y con el proyecto. Considerar la experiencia de los miembros y planear en conjunto estrecha los lazos existentes.

Finalmente, el usado de PSP y TSP hizo posible que muchos de los objetivos se alcanzaran, parece difícil lograr los buenos resultados con un desarrollo menos disciplinado, en especial si se considera que el equipo tiene poca experiencia en desarrollo de software que efectivamente se usa. Sin la ayuda de estos dos procesos se hubiera requerido un jefe de equipo muy experimentado que estuviera guiando el equipo en todo momento, y aún así la calidad del producto no podría asegurarse.

70

PROPUESTAS PARA LA MEJORA DEL PROCESO TSP Propuesta de Mejora del Proceso (PIP)

Nombre Juan Manuel Vázquez Orozco Fecha

Correo [email protected] Organización LISXP

Proyecto SAECH Lanzamiento/Fase Junta 7

PIP número 1 Prioridad Media

Descripción de la Mejora

Brevemente describa la mejora que propone

Los miembros del equipo deben mostrarse más comprometidos con el proyecto asistiendo a

las juntas y revisando el material que se genera.

Elementos del Proceso Impactados

Si los conoce liste los elementos del proceso que deben ser agregados, modificados o borrados

Beneficios de la Mejora (verifique cada uno)

Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido

Describa los beneficios probables de los cambios sugeridos

Que el equipo en su totalidad esté informado del avance permite que la aportación de ideas

sea de mejor calidad, además se evitan las demoras al explicar el por qué se han tomado

ciertas decisiones en juntas anteriores.

Que haya asistencia en las juntas motiva al equipo en general y logra cohesión entre todos

los miembros.

La presencia de los miembros que deben exponer material al resto del equipo evita demoras

o carencia de información

Cuando haya completado y revisado su Propuesta de Mejora del Proceso, envíela al Process Manager y

guarde una copia.

No escriba debajo de la siguiente línea.

Control de PIP # Aceptada

Recibida Devuelta

Evaluada Pospuesta

Esfuerzo involucrado Fecha de entrega

Autor Notificado

Razones

71

TSP Propuesta de Mejora del Proceso (PIP)



Proyecto SAECH Lanzamiento/Fase Juntas de lanzamiento

PIP número 2 Prioridad Alta



Cada miembro del equipo deberá informarse sobre qué tareas debe realizar en su rol

asignado




Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido


Desconocer las actividades correspondientes a cada rol genera confusiones sobré qué debe

hacer cada persona o a quién se debe dirigir para aclarar dudas

También crea retrasos en el caso de que se omita información o entregables por ignorar la

responsabilidad de dichas tareas.


guarde una copia.



Recibida Devuelta

Evaluada Pospuesta


Autor Notificado

Razones

72




Proyecto SAECH Lanzamiento/Fase Lanzamiento




Los entregables deben darse estrictamente en tiempo y forma por parte de los roles

responsables




Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido


La falta de cumplimiento de algunos roles genera atrasos, la asistencia y la entrega de

material mantendrían a tiempo el desarrollo de las juntas


guarde una copia.



Recibida Devuelta

Evaluada Pospuesta


Autor Notificado

Razones

73




Proyecto SAECH Lanzamiento/Fase Juntas de lanzamiento




La presencia de un guía en el proceso de TSP agilizaría en la comprensión de las

actividades que deben realizarse en cada junta




Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido


Contar con alguien experimentado en el uso de las herramientas de TSP y en las actividades

propias de cada junta mejoraría el desempeño del equipo, evitando las confusiones que

actualmente se dan y que en ocasiones deriva en rehacer el trabajo por haberlo interpretado

incorrectamente


guarde una copia.



Recibida Devuelta

Evaluada Pospuesta


Autor Notificado

Razones

74




Proyecto SAECH Lanzamiento/Fase Junta 7




Se requiere de capacitación en las tecnologías empleadas.




Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido


Entender cabalmente la tecnología a emplearse mejoraría la percepción del sistema, así

como estimar tamaños y tiempos con mayor precisión.

También disminuiría el riesgo que se toma al emplear una tecnología desconocida para la

mayoría de los miembros


guarde una copia.



Recibida Devuelta

Evaluada Pospuesta


Autor Notificado

Razones

75




Proyecto SAECH Lanzamiento/Fase Capacitación de tecnología




Agregar capacitación en el uso de las herramientas para el desarrollo




Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido


No todos los miembros tienen experiencia en las herramientas de desarrollo que se van a

utilizar, se pueden tener retrasos en tiempos de codificación y compilación por no conocer

la interfaz gráfica.

También se mejoraría el compromiso con el proyecto al trabajar cómodamente.


guarde una copia.



Recibida Devuelta

Evaluada Pospuesta


Autor Notificado

Razones

76




Proyecto SAECH Lanzamiento/Fase Capacitación de tecnología




herramientas a utilizar y de realizar una junta para explicar lo aprendido, para que el equipo

tenga conocimientos homogéneos del tema.




Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido


El tener un manual y un documento describiendo los pasos a seguir para utilizar las

tecnologías estudiadas, hará que los miembros se involucren en el aprendizaje y en el

seguimiento del proyecto.


guarde una copia.



Recibida Devuelta

Evaluada Pospuesta


Autor Notificado

Razones

77




Proyecto SAECH Lanzamiento/Fase Análisis y Diseño

PIP número 8 Prioridad Media



El apego a la estructura de casos de uso, estándares de interfaz de usuario y documentos

que componen los entregables debe ser de conocimiento de todos los miembros del equipo




Calidad de la

mejora

Tiempo

reducido del

ciclo

Riesgo reducido


El desconocimiento de la documentación o funcionalidad genera entregas equivocadas que

consumen tiempo.

Al mantener la comunicación con los encargados de interfaz de usuario se evitan demoras

por casos de uso mal diseñados


guarde una copia.



Recibida Devuelta

Evaluada Pospuesta


Autor Notificado

Razones

78

Aspirante

Prerregistro

Inscripción

Reinscripción

Pagos

Coordinador

Mantenimiento

Profesores

Profesor

Alumno

Consultas

Administrativo Cierres

ANEXOS

Modelo general de Casos de Uso En la siguiente figura se muestra el modelo general de casos de uso generado durante las primeras juntas de lanzamiento.

79

Encuesta

IdEncuestaFolio(FK)IdCurso(FK)ComoSeEnteroActividadesSoyProfesionistaEstoyInscritoGiroEmpresaNombreEmpresaDireccionEmpresaDelegacionEmpresaColoniaEmpresaCodigoPostalEmpresaPuestoTelefonoTrabajoJefeInmediatoCargoJefeInmediatoColegiaturaCubierta

ConceptoPago

IdconceptoDescripcionClavePrecio

Candidato

FolioApellidoPaternoApellidoMaternoNombreCalleNumeroColoniaCodigoPostalDelegacionTelefonoRFCCURPCorreoElectronicoFechaNacimiento

11 11

Movimiento

IdMovimientoMatricula(Fk)IdConcepto(FK)SaldoCantidadFechaTipoPagoTipoMovimiento

*1 *1

DetalleHorario


MensajeSucursal

IdMensajeIdUsuario(FK)IdSucursal(FK)MensajeFechaPublicacionFechaCaducidad

InscripcionCurso

MatriculaIdInscripcionCurso(FK)IDCurso(FK)TrimestreCalificacionG1CalificacionG2CalificacionC1CalificacionC2FechaInscripcion

Horario

IdHorarioDescripcion

1 *1 *

Materia


Sucursal


*1

*1

MensajeClase

IdCurso(FK)IdMensajeMensajeFechaPublicacion

Curso


*1 *1*

1

*

1

*

1

*

1

*

1

*

1

*1 *1

Alumno

MatriculaFolio(FK)

1

1

1

1

*

1

*

1

*

1

*

1

Profesor


*2 *2

Usuario

IdUsuarioLoginContraseñaIdAdministrativo(FK)Matricula(FK)IdProfesor(FK)

1

1

1

1

1

1

1

1Administrativo

IdAdministrativoNombreApellidoPaternoApellidoMaterno111 1

Modelo de Datos General En la siguiente figura se presenta el modelo de base de datos generado durante las juntas de lanzamiento.

80

BIBLIOGRAFIA

• Watts S. Humphrey. “A Discipline for Software Engineering : The Complete PSP Book” ISBN : 0-201-5416-8, 1995. Hardcover 816 pp. Addison-Wesley.

• Watts S. Humphrey. “Introducción al proceso personal de software”.

ISBN : 84-7829-052-4 Pearson Education.

• Watts S. Humphrey. “Introduction to the Team Software Process”

ISBN : 0-201-54610-8, 1995 Addison-Wesley.

• Ed Roman, Rima Patel Sriganesh, Gerald Brose. “Mastering Enterprise Java Beans, 3rd

Edition” ISBN: 0-7645-7682-8 Wiley.

• Keogh Jim. “J2EE Manual de referencia” ISBN : 8448139801 2003 McGraw-Hill

• Schmuller Joseph. “Teach yourself UML in 24 hours”

1999 Sams.

• Fowler Martin. “UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3rd

Edition” 2003 Addison-Wesley.

• Carnegie Mellon University. Software Engineering Institute.

http://www.sei.cmu.edu/tsp/

Documents

REPORTE FINAL DEL PROYECTO DE INVESTIGACION148.206.53.84/tesiuami/UAMI12872.pdf · 2 OBJETIVOS La creación de un sistema automatizado para control escolar bajo la metodología de