Professional Documents
Culture Documents
Título: Automatización del Módulo del sistema de inscripción del curos Seminario
de Investigación de la Universidad de Oriente Núcleo Anzoátegui.
2.1.2 Antecedentes
Sistema Web para el Registro y Control Estudiantil de la Misión Sucre,
Aldea Centro Regional de Apoyo al Maestro (CRAM), Municipio Sucre del
Estado Mérida (mar.2014). La presente Práctica Profesional tiene como
objetivo fundamental desarrollar un sistema que permita lograr el registro y
control eficiente de la información de los estudiantes de la Misión Sucre. La
Práctica Profesional se titula “Sistema Web para el Registro y Control
Estudiantil de la Misión Sucre, Aldea Centro Regional de Apoyo al Maestro
(CRAM), Municipio Sucre del Estado Mérida”. El enfoque metodológico
aplicado en el desarrollo de la Práctica Profesional, está basado en la
metodología Pressman R., con notación UML. De la metodología de
Pressman R., se tomó la fase de formulación e identificación de requisitos,
como complemento en la recopilación de información requerida en el UML.
Como resultado de la aplicación de la metodología mencionada, se obtuvo
un sistema con una interfaz sencilla y de fácil manejo, que presenta las
ventajas del trabajo en ambiente web.
Modelo de dominio
Ejemplo:
Figura 1. Modelo de Dominio
Referencia: dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html.
Diagrama de casos de uso
Un diagrama de clases sirve para visualizar las relaciones entre las clases
que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso
y de consentimiento.
Ejemplo:
Diagrama de Despliegue
Diagrama de Paquetes
Diagrama de secuencia
Diagrama de Actividades
Diagrama de Estado
Fase de Inicio
La importancia en la fase de inicio, es desarrollar el análisis del negocio hasta el
punto necesario para justificar la puesta en marcha del proyecto. Para desarrollar
este análisis de negocio se debe de tomar en cuenta la delimitación del alcance
del Sistema propuesto. Para lograr esto debe identificar todas las entidades
externas con las cuales el Sistema interactúe (los actores) y definir la naturaleza
de esta interacción a un nivel alto. Esto implica identificar todos los casos de uso y
describir solo los más significativos. El caso de negocio incluye criterios de éxito,
la evaluación de riesgos, y la estimación de los recursos necesarios, y un plan de
la fase.
Para dar inicio a esta fase se debe de responder las siguientes preguntas:
• ¿Cuáles son las principales funciones del sistema para los usuarios más
importantes?
• ¿Cómo podría ser la mejor arquitectura del sistema?
• ¿Cuál es el plan del Proyecto y cuanto costar desarrollar el producto?
En esta fase se identifican y priorizan los riesgos más importantes.
El objetivo de esta fase es ayudar al equipo de Proyecto a decidir cuáles son los
verdaderos objetivos del Proyecto. Las iteraciones exploran diferentes soluciones
posibles, y diferentes arquitecturas posibles.
A esta fase usualmente no sobrevive mucho trabajo físico, solo queda el
conocimiento adquirido por el equipo, pero en los casos en que sobrevivió algo,
usualmente es:
• Un enunciado de los mayores requerimientos planteados generalmente
como casos de uso.
• Un boceto inicial de la arquitectura.
• Una descripción de los objetivos del Proyecto.
• Una versión muy preliminar del plan del Proyecto.
• Un modelo del negocio.
La fase de inicio finaliza con el Hito de objetivos de Ciclo de Vida. Este hito es
alcanzado cuando el equipo de proyectos y las partes interesadas llegan a un
acuerdo sobre:
• Cuál es el conjunto de necesidades del negocio y que conjunto de
funciones satisfacen estas necesitas.
• Una planificación preliminar de iteraciones.
• Una arquitectura preliminar.
Fase de Elaboración
Fase De Construcción
El propósito primordial de esta fase es dejar listo un producto de software en su
versión operativa, a veces llamada versión “beta”. El producto debería tener la
calidad adecuada para su aplicación y asegurarse de cumplir los requisitos. La
construcción debería tener lugar dentro de los límites del plan de negocio.
La importancia de esta fase reside en que se construyen todos los componentes y
funcionalidades de la aplicación restantes y son integrados al producto, para ser
probados. La línea base de la arquitectura crece hasta convertirse en el sistema
completo.
Al final de esta fase, el producto contiene todos los casos de uso implementados,
listo para poner en manos de los usuarios finales, sin embargo puede que no esté
libre de defecto. El resultado mínimo producido durante esta fase es
• El sistema de software
• Los casos prueba
• Los manuales de usuario
La fase de usuario finaliza con el hito de capacidad operativa inicial. En este punto
se decide si el software, los sitios y los usuarios están listos para estar operativos
sin exponer a un alto riesgo.
Este hito se alcanza cuando el equipo de desarrollo y las partes interesadas llegan
a un acuerdo
• El producto es estable para ser usado.
• El producto provee alguna funcionalidad del valor.
• Todas las partes están listas para comenzar la transición.
Análisis
El flujo de trabajo de análisis que se inicia en la fase de inicio y elaboración
culmina en la fase de construcción, utilizando todos los casos de uso
determinados a lo largo de la vida del producto.
• Análisis de la arquitectura: El análisis de la arquitectura en esta fase, el
arquitecto tendrá poco que hacer ya que todo se realizó en la fase anterior, solo
debe estar al tanto de las actualizaciones necesarias debidas a los cambios que
afecten a la arquitectura.
• Analizar un caso de uso: En cada iteración de la fase de construcción,
ampliaremos el modelo de análisis con los casos de uso que sean incluidos en la
iteración.
• Analizar una clase: Los ingenieros de componentes continúan el trabajo que
comenzaron en la fase de elaboración
• Analizar un paquete: El arquitecto identifica los paquetes durante la fase de
elaboración, y los reafirma en la fase de construcción.
Diseño
Normalmente, en esta fase se diseña e implementa el 90% restante de los casos
de uso aquellos que no fueron utilizados para desarrollar la línea base de la
arquitectura. AL considerar el flujo de trabajo de diseño, hacemos un énfasis de
nuevo en que este y los otros flujos de trabajo se repiten en cada nueva iteración
• Diseño de la arquitectura: Por lo general, en la fase de construcción el
arquitecto no añadirá subsistemas del diseño, ni subsistemas de servicio. Estos
elementos ya existen, en forma de esqueleto.
Implementación
Este flujo de trabajo implementa y lleva a cabo las pruebas de unidad de todos los
componentes, trabajando principalmente a partir del modelo de diseño. EL
resultado, después de varias iteraciones y de la integración y pruebas del sistema
es la versión operativa inicial, que representa el 100% de los casos de uso.
En este flujo de trabaja es donde se lleva a cabo la mayor parte del trabajo de la
fase de construcción, construyendo componentes.
• Implementación de la arquitectura: En este momento la arquitectura está
firmemente asentada. EL papel del arquitecto, en lugar de realizar una vigilancia
continua será de actualizarlas si es necesario.
• Implementar una clase e implementar un subsistema: Los ingenieros de
componentes implementaran las clases y subsistemas del modelo de
implementación. Implementaran clases de clases anteriores cuando sea necesario
para armar una construcción.
• Realizar pruebas de unidad: El ingeniero de componentes será el
responsable de realizar las pruebas de unidad del componente que fabrique. Si es
necesario, corregirá el diseño y la implementación del componente.
• Integrar el sistema: El responsable de la integración del sistema creara un
plan de integración de construcciones que perfile la secuencia de construcciones.
Este plan mostrara los casos de uso o escenarios de un caso de uso que va a
implementar la construcción.
Pruebas
Los esfuerzos de los ingenieros de prueba para descubrir lo que puede ser
comprobado de forma efectiva y para desarrollar casos de pruebas y
procedimientos de pruebas para hacerlo, tendrán su fruto en la fase de
construcción. Esta es una actividad fundamental de esta fase.
• Planificar las pruebas: Los ingenieros de pruebas seleccionaran los
objetivos que comprueben las sucesivas construcciones y, por último, el propio
sistema.
• Diseñas las pruebas: Los ingenieros de pruebas, determinaran como probar
los requisitos en los conjuntos de construcciones, con objeto de verificar los
requisitos que pueden ser comprobados. Prepararan casos y procedimientos de
prueba con este propósito.
• Realizar pruebas de integración: Los encargados de las pruebas de
integración ejecutaran los casos de prueba, siguiendo los procedimientos de
prueba. Si la construcción supera las pruebas, el responsable de la integración del
sistema añadirá construcciones adicionales, según vayan estando disponibles, y el
encargado de las pruebas de integración seguirá comprobándolas.
• Realizar pruebas del sistema: en el momento en que las sucesivas
construcciones alcancen el final de una iteración, habrán alcanzado el status de
versión parcial del sistema, y entraran en la jurisdicción del encargado de las
pruebas del sistema.
• Evaluar las pruebas: Ha medida que trascurren las pruebas de integración y
del sistema los ingenieros de pruebas revisaran los resultados de las pruebas al
final de cada construcción a luz de los objetivos originalmente fijados en el plan de
pruebas.
Fase de transición
Una vez que el proyecto entra en la fase de transición, el sistema ha alcanzado la
capacidad operativa inicial.
La fase de transición se centra en implantar el producto en su entorno de
operación. La forma en que el proyecto lleva a cabo este objetivo varia con la
naturaleza de la relación del producto con su mercado. Las iteraciones en esta
fase continúan agregando características al software. Sin embargo las
características se agregan a un sistema que el usuario se encuentra utilizando
activamente.
Los artefactos construidos en esta fase son los mismos que en la fase de
construcción. El equipo se encuentra ocupado fundamentalmente en corregir y
extender la funcionalidad del sistema en la fase anterior.
La fase de transición finaliza con el hito de lanzamiento del producto el cual se
alcanza cuando
• Se han alcanzado los objetivos fijados en la fase de inicio
• El usuario está satisfecho
Flujo de trabajo de una iteración de la fase de Transición.
En esta fase, la actividad es baja en los cincos flujos de trabajo. Como casi todo el
trabajo se realizó en la fase de construcción, el nivel de actividad en esta fase es
bajo, justo lo necesario para corregir los problemas encontrados durante las
pruebas en el entorno del usuario. Sin embargo, esto no quiere decir que no haya
una buena cantidad de trabajo en esta fase.
Login:
Se tiene un formulario para iniciar sesión donde se tiene el número de cedula y
contraseña; para poder ingresar tendrán que ingresar tus datos de usuario, donde
existen dos usuarios que son el de administrador y el de los estudiantes.
Cada persona ya sea administrador o estudiante tienen un único número de
cedula para poder saber quién se está logeando y la aplicación saber hacia dónde
redirigirte.
Estudiante:
En la interfaz de estudiante se tiene principalmente una visualización de la
persona que se encuentra logeada con su respectivo nombre, apellido y
especialidad, luego se tiene dos opciones:
Sistema
Administrador
El administrador es el encargado de la inscripción de los estudiantes de
acuerdo a los requisitos planteados por la universidad donde dicta que para
poder optar por la inscripción a seminario de investigación tiene que haber
cursado por lo menos el 80% de los créditos de su carrera donde en entre
parte se tendrán 2 interfaces diferentes:
• La interfaz de habilitación de estudiante donde el administrador puede
observar la carrera, cantidad de créditos cursados, promedio del estudiante
para luego tener la opción de habilitarlo o no de acuerdo a su criterio y
cumplimiento de los requisitos antes mencionados.