MENU

Fase De Inicio



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