El
siguiente proyecto de “administración y control de postulantes a
docencia-auxiliatura” esta basado en la metodología de desarrollo RUP (Rational Unified Process ) utilizando la herramientas de UML 2.2
utilizando programas graficadores de UML los cuales son Rational Rose y
Enterprice Architect.
La
metodología RUP detalla :
3.1 Fase de Inicio
En
esta fase desarrollará los requisitos del producto desde la perspectiva del
usuario, los cuales serán establecidos en el artefacto Visión. Los principales
casos de uso serán identificados y se hará un refinamiento del Plan de
Desarrollo del Proyecto. La aceptación del cliente / usuario del artefacto
Visión y el Plan de Desarrollo marcan el final de esta fase.
Las
actividades principales de la fase de inicio son las siguientes:
·
Delimitar
el ámbito e identificar interfaces con sistemas remotos.
·
Describir
una propuesta de arquitectura del sistema, llegándose a una descripción de la
arquitectura (primeras versiones de los modelos). Demostrado que es viable, se
construirá en la fase de elaboración.
·
Identificar
riesgos críticos y determinar si se pueden mitigar en fases posteriores, sólo
se consideran los que afecten a la viabilidad, los no críticos simplemente se
apuntan.
·
Construcción
de un prototipo que muestre que se pueden solucionar los problemas del cliente
y de los usuarios finales pero que no tiene porqué dar lugar al producto final.
(Opcional)
Objetivos:
-
Justificar
la puesta en marcha del proyecto.
-
Delimitar
el ámbito y el alcance del sistema para discernir qué debemos cubrir con el
proyecto, comprender qué debe cubrir la arquitectura, definir los límites
dentro de los cuales debemos buscar los riesgos críticos y para delimitar las
estimaciones de coste, agenda y recuperación de la inversión (modelo de
negocio)
-
Identificar
una arquitectura candidata.
-
Identificar
y mitigar riesgos críticos.
-
Desarrollar
el análisis inicial del negocio.
-
Crear
un entrono de desarrollo.
Desarrollo
de la Fase de Inicio
PSI
2.1: Especificación del Ámbito y Alcance
PSI
2.3: Definición del Plan de Trabajo
PSI
4.3: Catalogación de Requisitos
ASI
2.2: Especificación de Casos de Uso
ASI
10.1: Definición del Alcance de las Pruebas
En
función de la solución adoptada en el desarrollo de un sistema de información,
es posible que determinados niveles de pruebas sean especialmente críticos y
otros no sean necesarios. Por ejemplo, puede haber grandes diferencias en
función de una solución de desarrollo completo o un producto de mercado cerrado
integrado con otros sistemas. En esta tarea se especifican y justifican de los
niveles de pruebas a realizar, así como el marco general de planificación de
cada nivel de prueba, según el siguiente esquema: Definición de los perfiles
implicados en los distintos niveles de prueba. Planificación temporal.
Criterios de verificación y aceptación de cada nivel de prueba. Definición,
generación y mantenimiento de verificaciones y casos de prueba. Análisis y
evaluación de los resultados de cada nivel de prueba. Productos a entregar como
resultado de la ejecución de las pruebas.
Se
aporta la prueba de caja negra del proyecto 8.06/47.2077 realizado entre la
Universidad de Málaga y la Empresa Malagueña Mixta de Limpieza con resultado
satisfactorio para la prueba de transmisión de datos entre PocketPC y un PC de
sobremesa. En el resto de los casos este proceso no es necesario porque la
comunicación por red local se considera trivial.
3.1.1 Modelado del
negocio 76
En
el proceso de elección de docentes y auxiliares de la carrera de informática consta de varios procesos
centralizados, lanzamiento de convocatoria, elección de tribunales, recepción
de documentos, evaluación escrita y oral, evaluación y publicación de notas.
El diagrama que representa los diferentes
subsistemas en los que se ha dividido para la carrera nivel de abstracción es
el siguiente:
3.1.2 DIAGRAMA DE
CASOS DE USO DE NEGOCIO
En el proceso interactúa con distintos
elementos externos, entre los que se identifican el postulante a auxiliar
(Estudiante), postulante a docente (Licenciado, Magister o Doctor), los
tribunales (Estudiante y Docentes) y por último el Kardex encargado de
gestionar el software.
3.1.3 MODELADO DEL
DOMINIO 78
No hay comentarios:
Publicar un comentario