Post on 03-Oct-2018
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%
20
Alta de Materias
Seleccion opcion Alta de Materias del Menu de
Mantenimiento de Cursos
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
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 modificar la información de las asignaturas.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Modificación de Materias del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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.
FLUJO DE EVENTOS ALTERNATIVOS
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.
2 Este usuario debe de haber iniciado sesión al sistema.
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.
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%
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
Mantenimiento de Cursos
Seleccionar Materia
Mensaje de Error
Ver[ Registro No Seleccionado ]Aceptar
Pantalla Modificación de Materias
Ver[ Registro Seleccionado ] / Inicializa Campos
Modifica Datos
Cancelar
Mensaje de Confirmación
Modificar[ Validacion Datos OK ]Cancelar
Mensaje de Éxito
Aceptar / Datos ModificadosAceptar / Actualiza Grid
Cerrar
Materia
IdMateria : IntegerNombre : StringClave : IntegerDescripcion : StringDuracion : StringPredecesor : String
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
PROYECTO: SAECH FECHA: 21/03/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCM03
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 eliminar las materias existentes en la Base de Datos.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Eliminación de Materias del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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.
FLUJO DE EVENTOS ALTERNATIVOS
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.
2 Este usuario debe de haber iniciado sesión al sistema.
3 Debe de existir al menos una asignatura dada de Alta.
POSCONDICIONES
1 La eliminación del registro seleccionado en 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%
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
IdMateria : IntegerNombre : StringClave : IntegerDescripcion : StringDuracion : StringPredecesor : String
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
PROYECTO: SAECH FECHA: 21/03/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCP01 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 de captura de datos de profesores.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Alta de Profesores del Menú de Mantenimiento de Cursos.
2
FLUJO DE EVENTOS PRIMARIO
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
FLUJO DE EVENTOS ALTERNATIVOS
Ninguno
PRECONDICIONES
1 Debe existir un usuario con los privilegios necesarios para dar de Alta a un Profesor.
2 Este usuario debe de haber iniciado sesión al sistema.
POSCONDICIONES
1 Un nuevo Profesor ha sido agregado y dado de Alta.
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%
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
PROYECTO: SAECH FECHA: 21/03/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCP01 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 de modificación a la información de los profesores.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Modificación de Profesores del Menú de Mantenimiento de Cursos.
2
FLUJO DE EVENTOS PRIMARIO
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
FLUJO DE EVENTOS ALTERNATIVOS
Ninguno
PRECONDICIONES
1 Debe existir un usuario con los privilegios necesarios para poder modificar a un Profesor.
2 Este usuario debe de haber iniciado sesión al sistema.
3 Debe de existir al menos un profesor dado de Alta.
POSCONDICIONES
1 Información actualizada del profesor seleccionado.
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%
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
Mensaje de Confirmación
Cancelar
Aceptar / Datos Modificados y Actualiza Grid
Ver[ Registro No Seleccionado ]
Ver[ Registro Seleccionado ] / Inicializa Campos
Cerrar
Aceptar[ Validación Datos OK ]
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 RPMCP02– MODIFICACION DE PROFESORES
MODELO DE DATOS CASO DE USO RPMCP02– MODIFICACION DE PROFESORES
33
CLAVE DEL CASO RPMCP03 - ELIMINACION DE PROFESORES
PROYECTO: SAECH FECHA: 21/03/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCP01 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 la eliminación de la información de los profesores.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Eliminación de Profesores del Menú de Mantenimiento de Cursos.
2
FLUJO DE EVENTOS PRIMARIO
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
FLUJO DE EVENTOS ALTERNATIVOS
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.
2 Este usuario debe de haber iniciado sesión al sistema.
3 Debe de existir al menos un profesor dado de Alta.
POSCONDICIONES
1 Información eliminada del profesor seleccionado.
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%
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
Confirmación de Eliminación
Aceptar / Registro Eliminado de BD y Actualiza Grid
Cancelar
Eliminar[ Registro No Seleccionado ]
Eliminar[ Registro Seleccionado ]
Cerrar
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 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
PROYECTO: SAECH FECHA: 27/06/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCH01
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 de alta de Horarios
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Alta de Horarios del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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.
FLUJO DE EVENTOS ALTERNATIVOS
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
2 Este usuario debe de haber iniciado sesión al sistema.
POSCONDICIONES
1 Un nuevo horario ha sido agregado y dado de Alta.
DOCUMENTACIÓN ADJUNTA
Diagrama de Navegación de Pantallas
Modelo de Datos. Porcentaje de transacciones totales que cubre el caso: 14.23% Porcentaje de efectividad del proceso actual 0%
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
PROYECTO: SAECH FECHA: 27/06/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCH01
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 de Cambio de Horarios
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Cambio de Horarios del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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.
FLUJO DE EVENTOS ALTERNATIVOS
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
2 Este usuario debe de haber iniciado sesión al sistema.
POSCONDICIONES
1 Un Horario ha sido modificado.
DOCUMENTACIÓN ADJUNTA
Diagrama de Navegación de Pantallas
Modelo de Datos. Porcentaje de transacciones totales que cubre el caso: 14.23% Porcentaje de efectividad del proceso actual 0%
40
DIAGRAMA DE INTERFACES Pantalla de Modificación de Horarios Pantalla Modificación de Datos
Mensaje de Confirmación
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
Dia : IntegerHoraInicio : DateHoraFinal : DateIDHorario : Integer
Horarios
IDHorario : IntegerClaveHorario : StringDescripción : String
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
PROYECTO: SAECH FECHA: 27/6/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCH03
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 de baja de Horarios
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Baja de Horarios del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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
FLUJO DE EVENTOS ALTERNATIVOS
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
2 Este usuario debe de haber iniciado sesión al sistema.
POSCONDICIONES
1 Una horario ha sido eliminada del sistema
DOCUMENTACIÓN ADJUNTA
Diagrama de Navegación de Pantallas
Modelo de Datos.
Porcentaje de transacciones totales que cubre el caso: 14.23% Porcentaje de efectividad del proceso actual 0%
43
DIAGRAMA DE INTERFACES
Pantalla de lista de Horarios a Eliminar
Mensaje de Confirmación
Mensaje de Eliminación con éxito
44
listaHorarios mensajeConfirmación
Cancelar
mensajeOK
Aceptar
Aceptar
Eliminar
Cancelar
bajaHorarios
HorariosDetalle
Dia : IntegerHoraInicio : DateHoraFinal : DateIDHorario : Integer
Horarios
IDHorario : IntegerClaveHorario : StringDescripción : String
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
PROYECTO: SAECH FECHA: 18/6/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCS02
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 de alta de Sucursales
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Altas de Sucursales del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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.
FLUJO DE EVENTOS ALTERNATIVOS
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
2 Este usuario debe de haber iniciado sesión al sistema.
POSCONDICIONES
1 Una nueva sucursal ha sido agregada y dada de Alta.
DOCUMENTACIÓN ADJUNTA
Diagrama de Navegación de Pantallas
Modelo de Datos.
Porcentaje de transacciones totales que cubre el caso: 14.23% Porcentaje de efectividad del proceso actual 0%
46
DIAGRAMA DE INTERFACES
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
PROYECTO: SAECH FECHA: 18/6/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCS02
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 de cambios a Sucursales
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Cambio de Sucursales del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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
FLUJO DE EVENTOS ALTERNATIVOS
6a Si el usuario oprime cancelar, se regresa al paso 1
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
2 Este usuario debe de haber iniciado sesión al sistema.
POSCONDICIONES
1 Una sucursal ha sido modificada en el sistema
DOCUMENTACIÓN ADJUNTA
Diagrama de Navegación de Pantallas
Modelo de Datos.
Porcentaje de transacciones totales que cubre el caso: 14.23% Porcentaje de efectividad del proceso actual 0%
49
DIAGRAMA DE INTERFACES
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
IDSucursalClaveSucursalNombreDescripcionTelefono
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
PROYECTO: SAECH FECHA: 18/6/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCS03
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 de baja de Sucursales
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Baja de Sucursales del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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
FLUJO DE EVENTOS ALTERNATIVOS
4a Si el usuario oprime cancelar, se regresa al paso 1
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
2 Este usuario debe de haber iniciado sesión al sistema.
POSCONDICIONES
1 Una sucursal ha sido eliminada del sistema
DOCUMENTACIÓN ADJUNTA
Diagrama de Navegación de Pantallas
Modelo de Datos.
Porcentaje de transacciones totales que cubre el caso: 14.23% Porcentaje de efectividad del proceso actual 0%
52
DIAGRAMA DE INTERFACES
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
IDSucursalClaveSucursalNombreDescripcionTelefono
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
PROYECTO: SAECH FECHA: 21/03/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCC01
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 de alta de Cursos.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Alta de Cursos del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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.
FLUJO DE EVENTOS ALTERNATIVOS
Ninguno
PRECONDICIONES
1 Debe existir un usuario con los privilegios necesarios para dar de Alta a un Curso
2 Este usuario debe de haber iniciado sesión al sistema.
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.
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%
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
Mensaje de Confirmación
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
PROYECTO: SAECH FECHA: 21/03/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCC02
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 la modificación de la información de los cursos.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Modificación de Cursos del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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
FLUJO DE EVENTOS ALTERNATIVOS
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
2 Este usuario debe de haber iniciado sesión al sistema.
3 Deben existir al menos un Curso dado de Alta.
POSCONDICIONES
1 Información actualizada del curso que modificó el P.A.
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%
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
Ver[ Registro Seleccionado ] / Inicializa Campos
Modifica Datos
Mensaje de Confirmación
Cancelar
Aceptar / Datos Modificados y Actualiza Grid
Cerrar
Aceptar[ Validación Datos OK ]
Cancelar
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 RPMCC02 – MODIFICACION DE CURSO MODELO DE DATOS CASO DE USO RPMCC02 – MODIFICACION DE CURSO
60
CLAVE DEL CASO RPMCC03 - ELIMINACION DE CURSOS
PROYECTO: SAECH FECHA: 21/03/2005
AUTOR: JuVaz, RicBar CLAVE: RPMCC03
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 la eliminación de los cursos.
ACTORES
Actor Principal Personal Administrativo (P. A.)
Actores Secundarios
EVENTOS QUE LO INICIAN
1 Seleccionar la opción de Eliminación de Cursos del Menú de Mantenimiento de Cursos.
FLUJO DE EVENTOS PRIMARIO
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.
FLUJO DE EVENTOS ALTERNATIVOS
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
2 Este usuario debe de haber iniciado sesión al sistema.
3 Deben existir al menos un Curso dado de Alta.
POSCONDICIONES
1 Curso eliminado de 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%
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
Confirmación de Eliminación
Cancelar
Aceptar / Registro Eliminado de BD y Actualiza Grid
Eliminar[ Registro No Seleccionado ]
Eliminar[ Registro Seleccionado ]
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 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
voSucursal : VOSucursal
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
voSucursal : VOSucursal
getDataSucursal()
agregaSucursal()
SucursalBean
voSucursal : VOSucursal
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()
<<event>> Alta de Sucursal()
(from AltaSucursal)
CiTablaModificacionSucursal
show()
<<event>> Seleccion Sucursal()
<<event>> Modificar()
initTable()
close()
CiModificacionSucursal
voSucursal : VOSucursal
show()
initFields()
<<event>> IngresoDatos()
<<event>> Modificar()
mensajeConfirmacion()
<<event>> Aceptar()
mensajeExito()
close() VOSucursal
IdSucursal : Integer
ClaveSucursal : String
Nombre : String
Descripcion : String
Telefono : String
VOSucursal()
void setIdSucursal()
void setClaveSucursal()
void setNombre()
void setDescripcion()
void setTelefono()
Integer getIdSucursal()
String getClaveSucursal()
String getNombre()
String getDescripcion()
String getTelefono()
(from AltaSucursal)
CnModificacionSucursal
voSucursal : VOSucursal
getDataSucursal()
validaCampos()
modificaSucursal()
Sucursal
voSucursal : VOSucursal
getDataSucursal()
agregaSucursal()
modificaSucursal()
(from AltaSucursal)
SucursalHome
Sucursal create()
(from AltaSucursal)
SucursalBean
voSucursal : VOSucursal
sessionContext : SessionContext
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
mensajeConfirmacion()
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>> Alta de Sucursal()
<<event>> Baja de Sucursal()
(from AltaSucursal)
CiEliminacionSucursal
show()
initListSucursal()
mensajeConfirmacion()
mensajeExito()
close()
<<event>> SeleccionaSucursal()
<<event>> Eliminar()
<<event>> Aceptar()
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()
(from AltaSucursal)
CnEliminacionSucursal
voSucursal : VOSucursal
getListaSucursal()
eliminaSucursal()
SucursalHom
e
Sucursal create()
(from AltaSucursal)
Sucursal
voSucursal : VOSucursal
getDataSucursal()
agregaSucursal()
modificaSucursal()
getListaSucursal()
eliminaSucursal()
(from AltaSucursal)
SucursalBean
voSucursal : VOSucursal
sessionContext : SessionContext
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 juanmvorozco@gmail.com 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)
Nombre Juan Manuel Vázquez Orozco Fecha
Correo juanmvorozco@gmail.com Organización LISXP
Proyecto SAECH Lanzamiento/Fase Juntas de lanzamiento
PIP número 2 Prioridad Alta
Descripción de la Mejora
Brevemente describa la mejora que propone
Cada miembro del equipo deberá informarse sobre qué tareas debe realizar en su rol
asignado
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
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.
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
72
TSP Propuesta de Mejora del Proceso (PIP)
Nombre Juan Manuel Vázquez Orozco Fecha
Correo juanmvorozco@gmail.com Organización LISXP
Proyecto SAECH Lanzamiento/Fase Lanzamiento
PIP número 3 Prioridad Alta
Descripción de la Mejora
Brevemente describa la mejora que propone
Los entregables deben darse estrictamente en tiempo y forma por parte de los roles
responsables
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
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
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
73
TSP Propuesta de Mejora del Proceso (PIP)
Nombre Juan Manuel Vázquez Orozco Fecha
Correo juanmvorozco@gmail.com Organización LISXP
Proyecto SAECH Lanzamiento/Fase Juntas de lanzamiento
PIP número 4 Prioridad Alta
Descripción de la Mejora
Brevemente describa la mejora que propone
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
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
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
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
74
TSP Propuesta de Mejora del Proceso (PIP)
Nombre Juan Manuel Vázquez Orozco Fecha
Correo juanmvorozco@gmail.com Organización LISXP
Proyecto SAECH Lanzamiento/Fase Junta 7
PIP número 5 Prioridad Alta
Descripción de la Mejora
Brevemente describa la mejora que propone
Se requiere de capacitación en las tecnologías empleadas.
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
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
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
75
TSP Propuesta de Mejora del Proceso (PIP)
Nombre Juan Manuel Vázquez Orozco Fecha
Correo juanmvorozco@gmail.com Organización LISXP
Proyecto SAECH Lanzamiento/Fase Capacitación de tecnología
PIP número 6 Prioridad Alta
Descripción de la Mejora
Brevemente describa la mejora que propone
Agregar capacitación en el uso de las herramientas para el desarrollo
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
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.
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
76
TSP Propuesta de Mejora del Proceso (PIP)
Nombre Juan Manuel Vázquez Orozco Fecha
Correo juanmvorozco@gmail.com Organización LISXP
Proyecto SAECH Lanzamiento/Fase Capacitación de tecnología
PIP número 7 Prioridad Alta
Descripción de la Mejora
Brevemente describa la mejora que propone
herramientas a utilizar y de realizar una junta para explicar lo aprendido, para que el equipo
tenga conocimientos homogéneos del tema.
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
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.
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
77
TSP Propuesta de Mejora del Proceso (PIP)
Nombre Juan Manuel Vázquez Orozco Fecha
Correo juanmvorozco@gmail.com Organización LISXP
Proyecto SAECH Lanzamiento/Fase Análisis y Diseño
PIP número 8 Prioridad Media
Descripción de la Mejora
Brevemente describa la mejora que propone
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
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
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
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
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
IdHorarioDiaHoraInicioHoraFin
MensajeSucursal
IdMensajeIdUsuario(FK)IdSucursal(FK)MensajeFechaPublicacionFechaCaducidad
InscripcionCurso
MatriculaIdInscripcionCurso(FK)IDCurso(FK)TrimestreCalificacionG1CalificacionG2CalificacionC1CalificacionC2FechaInscripcion
Horario
IdHorarioDescripcion
1 *1 *
Materia
IdMateriaNombreDescripcionClaveDuracionPredecesor
Sucursal
IdSucursalClaveSucursalNombreDescripcionTelefono
*1
*1
MensajeClase
IdCurso(FK)IdMensajeMensajeFechaPublicacion
Curso
IdCursoIdMateria(FK)IdHorario(FK)IdProfesorG(FK)IdProfesorC(FK)IdSucursal(Fk)Aula
*1 *1*
1
*
1
*
1
*
1
*
1
*
1
*1 *1
Alumno
MatriculaFolio(FK)
1
1
1
1
*
1
*
1
*
1
*
1
Profesor
IdProfesorNombreApellidoPaternoApellidoMaternoCalleColoniaNumeroDelegacionCodPostalRFCCURPCorreoElectronicoTelefonoCasaTelefonoOficinaTelefonoCelular
*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/