You are on page 1of 36

Bachiller: Ricardo J. Sanchez Ch.

Cedula de identidad: 20.636.247


Desarrollo de Software Avanzado.

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.

Planteamiento del problema


La universidad de oriente núcleo Anzoátegui en el periodo de inscripción del curso
seminario de investigación presenta un retraso, el cual puede tener un lapso de
tiempo prolongado, ya que el proceso de aprobación lleva diversos pasos y estos
mismos son cumplidos manualmente, tomando en cuenta que debe pasar por
departamentos para su respectiva verificación necesaria cumpliendo con los
requisitos necesarios; con el fin de que cada inscripción de seminario pueda ser
garantizada para el alumno.
La automatización es la aplicación de máquinas o de procedimientos automáticos
en la realización de un proceso, practicando dicha modalidad este brindaría una
rapidez en dicho planteamiento, a su vez presenta herramientas tales como el
desarrollo del software, programación junto a las herramientas de web, PHP y
HTML5 y CCS3 para lograr su finalidad; al plantear la automatización se lograría
una rapidez notoria e inmediata al presentar la inscripción del curso seminario de
investigación, este realizaría el método que actualmente siendo engorroso es
aplicado en la universidad de oriente núcleo Anzoátegui en uno simple el cual
daría un resultado satisfactorio y además cumpliría con los requisitos necesarios y
en un menor tiempo.
Comprendiendo que gracias a la realización del módulo de inscripción y
aprobación de la administración presente en la automatización de inscripción del
curso seminario de investigación, es sumamente importante comprender el por
qué se lleva a cabo y dichas razones son vitales, con ellas todo el proceso
actualmente de la universidad de oriente núcleo Anzoátegui se cambiaría a uno
que en simples pasos finalizaría todo el proceso, y con estos beneficiaran a la
misma y al alumnado obteniendo un resultado de inscripciones satisfactoriamente
y en un corto tiempo.
OBJETIVOS DE INVESTIGACION
Objetivo General
Desarrollo del Módulo del sistema de inscripción del curos Seminario de
Investigación de la Universidad de Oriente Núcleo Anzoátegui.
Objetivos Específicos
 Analizar el funcionamiento del sistema actual de la institución.
 Determinar los requisitos funcionales y no funcionales del sistema a
desarrollar.
 Diseñar la arquitectura del software, base de datos e interfaces del
programa en base a información recopilada.
 Codificar los distintos módulos del sistema en base al diseño realizado.
 Realizar las pruebas que garanticen el buen funcionamiento del sistema.
Marco Teórico
2.1 Bases teóricas
Las bases teóricas, son todas aquellas definiciones que sustentan a un
trabajo de investigación y que explican diferentes aspectos del tema en estudio,
igualmente, amplían la descripción del problema planteado. Es decir, que integra la
teoría con la investigación y sus relaciones mutuas. En tal sentido, Bisquerra (2008),
los define como “un conjunto de proposiciones teóricas interrelacionadas, que
fundamentan y explican aspectos significativos del tema o problema en estudio”. (p.
139). En conclusión las bases teóricas, son consultas del tipo bibliográficas, que
proporcionan las bases sobre las cuales se ha de fundamentar el trabajo,
considerando estudios previos y toda aquella información documental que de una u
otra forma está relacionada con la temática de estudio. Desde esta perspectiva, se
presenta el basamento teórico que sustenta y apoya la presente investigación.

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.

 Desarrollo del sistema de gestión académica CONEST para la


Coordinación de Postgrado de la Facultad de Ciencias. Módulos de
migración de datos, administración e inscripción (oct.2015). Este Trabajo
Especial de Grado tuvo como objetivo realizar la implementación de la
aplicación Web CONEST en los estudios de postgrado, con la finalidad de
adaptarla y obtener un producto que sirva para su gestión académica y el
beneficio de su comunidad.

 “Desarrollo de un sistema automatizado bajo entorno web para el control de


la Programación Académica en la Universidad de oriente Núcleo de
Anzoátegui”(jun.2009). El siguiente proyecto de investigación se basa en el
desarrollo de un sistema automatizado para el control de la Programación
Académica (SACPA) para la Universidad de Oriente, Núcleo de Anzoátegui.
El software se encarga de proporcionar una interfaz agradable y de fácil
manejo en entorno web a los diferentes departamentos académicos de la
Institución y a los directores de escuela para ingresar y administrar la
Programación Académica que elaboran durante cada periodo académico.

2.2.1 Aplicación web


Según Luján (2002), la aplicación web se define como “un tipo especial de
aplicación cliente/servidor, donde tanto el cliente como el servidor y el protocolo
mediante el que se comunican están estandarizados y no ha de ser creados por el
programador de aplicaciones.” (p.48).

López (2009), define a una aplicación web como:

Un sistema informático que los usuarios utilizan accediendo a un servidor


web a través de Internet o de una Intranet. Las aplicaciones Web son
populares debido a la practicidad del navegador Web como cliente ligero.
La facilidad para actualizar y mantener aplicaciones web sin distribuir e
instalar software en miles de potenciales clientes es otra razón de su
popularidad. Aplicaciones como los webmails, wikis, weblogs, tiendas en
línea y la wikipedia misma son ejemplos bien conocidos de aplicaciones
web. (p.25).

2.2.1.1 Usos Comunes de las Aplicaciones Web


Las aplicaciones Web pueden tener numerosos usos tanto para los visitantes
como para los ingenieros de desarrollo, entre otros:
 Permitir a los usuarios localizar información de forma rápida y sencilla en un
sitio Web en el que se almacena gran cantidad de contenido. Este tipo de
aplicación Web ofrece a los visitantes la posibilidad de buscar contenido,
organizarlo y navegar por él de la manera que estimen oportuna. Algunos
ejemplos son: las intranets de las empresas, Microsoft MSDN
(www.msdn.microsoft.com) y Amazon.com (www.amazon.com).

 Actualizar sitios Web cuyo contenido cambia constantemente. Una aplicación


Web evita al diseñador Web tener que actualizar continuamente el código
HTML del sitio. Los proveedores de contenido, como los editores de noticias,
proporcionan el contenido a la aplicación Web y ésta actualiza el sitio
automáticamente. Entre los ejemplos figuran Economist
(www.economist.com) y CNN (www.cnn.com).

2.2.2 Definición de Sistemas


Según Puleo, F. (1980), “Un sistema es un todo complejo y organizado; una
reunión de cosas y partes que forman un todo unitario y complejo. La idea de
sistema da una connotación de plan, método, orden, arreglo. Lo antagónico de
sistemas es el caos” (p. 3).

2.2.2.1 Características de los sistemas


 Estabilidad: Cualidad por lo que el sistema funciona eficazmente.
 Adaptabilidad: Cualidad que le permite evolucionar dinámicamente en su
entorno.
 Eficiencia: Cualidad que permite al sistema alcanzar su objetivo con
economía de medios.
 Sinergia: La capacidad de actuación del sistema es superior a la de sus
componentes individuales.

2.2.3 Ingeniería de software


El proceso de ingeniería de software se define como “un conjunto de etapas
parcialmente ordenadas con la intención de lograr un objetivo, en este caso, la
obtención de un producto de software de calidad”. El proceso de desarrollo de
software “es aquel en que las necesidades del usuario son traducidas en
requerimientos de software, estos requerimientos transformados en diseño y el
diseño implementado en código, el código es probado, documentado y certificado
para su uso operativo". Concretamente "define quién está haciendo qué, cuándo
hacerlo y cómo alcanzar un cierto objetivo”.

2.2.4 Definición de UML


UML es un lenguaje estándar que sirve para escribir los planos del software,
puede utilizarse para visualizar, especificar, construir y documentar todos los
artefactos que componen un sistema con gran cantidad de software. UML puede
usarse para modelar desde sistemas de información hasta aplicaciones distribuidas
basadas en Web, pasando por sistemas empotrados de tiempo real. UML es
solamente un lenguaje por lo que es sólo una parte de un método de desarrollo
software, es independiente del proceso aunque para que sea óptimo debe usarse
en un proceso dirigido por casos de uso, centrado en la arquitectura, iterativo e
incremental.

UML es un lenguaje porque proporciona un vocabulario y las reglas para


utilizarlo, además es un lenguaje de modelado lo que significa que el vocabulario y
las reglas se utilizan para la representación conceptual y física del sistema.

 Modelo de dominio

“Un Modelo de Dominio es una representación visual de clases conceptuales


o de objetos reales en un dominio de interés” [MO95].

Un Modelo de Dominio consiste en un conjunto de diagramas de clases, sin


definición de operaciones.

Ejemplo:
Figura 1. Modelo de Dominio

Referencia: dsic.upv.es/asignaturas/facultad/lsi/ejemplorup/Model_Negocio.html.
 Diagrama de casos de uso

El diagrama de casos de uso representa la forma en como un Cliente


(Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en
como los elementos interactúan (operaciones o casos de uso).
Ejemplo:

Figura 2. Diagrama de Casos de Uso.


Referencia: dcc.uchile.cl/~psalinas/uml/casosuso.html.
 Diagrama de Clases

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:

Figura 3. Diagrama de Clases.


Referencia: dcc.uchile.cl/~psalinas/uml/modelo.html.

 Diagrama de Despliegue

Es un diagrama que se utiliza para modelar el hardware utilizado en las


implementaciones de sistemas y las relaciones entre sus componentes.
Ejemplo:
Figura 4. Diagrama de Despliegue.
Referencia: www.ecured.cu/Archivo:Diagrmad.jpg

 Diagrama de Paquetes

El diagrama muestra como está estructurado el sistema. Cada paquete


puede contener otros paquetes o clases, que tienen interfaces y realizan cierta
funcionalidad.
Ejemplo:
Figura 5. Diagrama de Paquetes.
Referencia: Damian Gutierrez (Septiembre 2009) UML Diagramas de
Paquetes. Clase 5. Universidad de los Andes.

 Diagrama de secuencia

Un diagrama de secuencia destaca la ordenación temporal de los mensajes,


un diagrama de secuencia se forma colocando en primer lugar los objetos o roles
que participan en la interacción en la parte superior del diagrama, a lo largo del eje
horizontal. Normalmente, se coloca a la izquierda el objeto o rol que inicia la
interacción, y los objetos o roles subordinados a la derecha.
Figura 6. Diagrama de Secuencia.

 Diagrama de Actividades

Un diagrama de actividades muestra un proceso de negocio o un proceso


de software como un flujo de trabajo a través de una serie de acciones. Las
personas, los componentes de software o los equipos pueden realizar estas
acciones.
Ejemplo:
Figura 7. Diagrama de Actividades.
Referencia: Librería Microsoft Diagrama de Actividades UML Visual estudio
2015.

 Diagrama de Estado

En UML, un diagrama de estados es un diagrama utilizado para identificar


cada una de las rutas o caminos que puede tomar un flujo de información luego de
ejecutarse cada proceso.
Permite identificar bajo qué argumentos se ejecuta cada uno de los
procesos y en qué momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la
ejecución de cada uno de los procesos.
Ejemplo:
Figura 8. Diagrama de Estados.
Referencia: Librería Microsoft Diagrama de Estados UML Visual estudio
2015.
Modelo de Dominio

Modelo de dominio actual del sistema de inscripción de seminario de


investigación.
MARCO METODOLÓGICO
Metodología de la investigación
A continuación se describe la metodología de investigación utilizada para llevar a
cabo esta investigación (Tamayo y Tamayo, 2001).
Forma de investigación
La investigación realizada se considerada de tipo aplicada, porque comprende el
estudio y la puesta en práctica de la investigación a problemas reales y de
características concretas. En vista de que el objetivo principal de este proyecto es
el desarrollo de un modulo del sistema de inscripción de seminario de
investigación de la UDO Anzoategui, se le puede incluir dentro de esta forma de
investigación, por brindar solucióna un problema de manera rápida y directa.
Tipo de investigación
La investigación descriptiva trabaja sobre realidades de hechos y su característica
fundamental es la de presentar una interpretación correcta. La presente
investigación es de tipo descriptiva, porque alcanzara fines directos e inmediatos;
además puntualizara, registrara, analizara e interpretara los procesos y
actividades que se llevan a cabo la inscripción del curso en UDO Anzoategui.
Diseño de la investigación
El diseño de esta investigación es de campo, porque “los datos se recogen
directamente de la realidad”; es decir, se aplicaran técnicas para la recolección de
datos como la observación directa, que permitiera obtener la información
necesaria para el desarrollo del sistema.
Técnicas para la recolección de datos
Las técnicas que se emplearon en la recolección de la información necesaria para
el desarrollo de este proyecto de investigación fueron la observación directa;
consultas bibliográficas y consultas en Internet, lo que permitió establecer las
bases teóricas de esta investigación.

Metodología del área aplicada


En el desarrollo de este sistema se recurrió a una metodología UML/RUP
Metodología de Proceso Unificado Racional (RUP)
El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente
resumido como RUP) es un proceso de desarrollo de software y junto con el
Lenguaje Unificado de Modelado UML, constituye la metodología estándar más
utilizada para el análisis, implementación y documentación de sistemas orientados
a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologías adaptables al contexto y necesidades de cada organización la cual
nos permite:
¾ Desarrollar Software Iterativamente.
¾ Modelar el software visualmente.
¾ Gerenciar los Requerimientos.
¾ Usar arquitecturas basadas en componentes.
¾ Verificación continúa de la calidad.
¾ Gerenciar los cambios
Está basado en 5 principios clave que son:
¾ Adaptar el proceso: Deberá adaptarse a las características propias del proyecto
u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo
condicionen, influirán en su diseño específico.
También se deberá tener en cuenta el alcance del proyecto.
¾ Equilibrar prioridades: Los requerimientos de los diversos participantes pueden
ser diferentes, contradictorios o disputarse recursos limitados.
Debe encontrarse un equilibrio que satisfaga los deseos de todos.
Gracias a este equilibrio se podrán corregir desacuerdos que surjan en el futuro.
¾ Demostrar valor Iterativamente: Los proyectos se entregan, aunque sea de un
modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los
inversores, la estabilidad y calidad del producto, y se refina la dirección del
proyecto así como también los riesgos involucrados
¾ Colaboración entre equipos: El desarrollo de software no lo hace una única
persona sino múltiples equipos. Debe haber una comunicación fluida para
coordinar requerimientos, desarrollo, evaluaciones, planes, resultados, etc.
¾ Elevar el nivel de abstracción: Esto evita que los desarrolladores de software
vayan directamente de los requisitos a la codificación de software a la medida del
cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los
requerimientos y sin comenzar desde un principio pensando en la reutilización del
código. Un alto nivel de abstracción también permite discusiones sobre diversos
niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las
representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.
Lenguaje Unificado de Modelado (UML)
Es un lenguaje que sirve para escribir los planos del software, puede utilizarse
para visualizar, especificar, construir y documentar todos los artefactos que
componen un sistema con gran cantidad de software. UML puede usarse para
modelar desde sistemas de información hasta aplicaciones distribuidas basadas
en Web, pasando por sistema empotrado de tiempo real, la esencia del UML es
que utiliza varios tipos de notaciones y diagramas estándar para modelar ilustrar
sistemas orientados a objetos y describe la semántica esencial de lo que estos
diagramas y símbolos significan.
Es importante resaltar que UML es un "lenguaje de modelado" para especificar o
describir métodos o procesos. Se utiliza para definir un sistema, detallar los
artefactos en el sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo.
Se puede aplicar en el desarrollo de software entregando gran variedad de formas
para dar soporte a una metodología de desarrollo de software (tal como el Proceso
Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o
proceso usar.
UML no puede compararse con la programación estructurada, pues UML significa
Lenguaje Unificado de Modelado, no es programación, solo se diagrama la
realidad de una utilización en un requerimiento. Mientras que, programación
estructurada, es una forma de programar como lo es la orientación a objetos, sin
embargo, la programación orientada a objetos viene siendo un complemento
perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a
objetos.

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.

Flujo de trabajo de una iteración de la fase de inicio


La mayor parte de trabajo de la fase de inicio se lleva a cabo en el flujo requisito,
seguido del flujo de análisis y diseño. Hay poca actividad en los flujos de trabajo
de implementación y prueba.
Flujo de requisito
La recopilación de requisitos es el énfasis principal de esta fase de inicio ya que
en él, se identifica y detalla los casos de usos. Para eso se incluyen los siguientes
aspectos:
- Enumerar los requisitos candidatos
La lista de características surge a menudo de la experiencia de los clientes o
usuarios tienen con sistemas predecesores o similares. En el caso de productos
de gran distribución, las nuevas características surgen por la demanda del
mercado. Adicionalmente. Muchas de las ideas de las posibles características
surgen de los trabajadores de la propia organización de desarrollo. Estas listas de
características deseadas del Sistema constituyen los requisitos candidatos.
Esta lista se utiliza para estimar el tamaño del proyecto y decidir cómo
dividirlo en secuencia de iteraciones. La prioridad y nivel de riesgo asociados con
el proyecto.

- Comprender el contexto del Sistema


Si el cliente tiene un modelo de negocio o dominio, el equipo de persona de la fase
de inicio puede trabajar sobre él. Si el cliente no dispone de tal modelo deberá de
alertarle a los desarrolladores para que el grupo de trabajo estime el recurso y
tiempo.
Hay por lo menos dos aproximaciones para expresar el contexto de un
sistema:
• Un modelo del dominio: describe los conceptos importantes del contexto
como objetos del dominio relacionados entre sí.
• Un modelo del negocio: es más amplio. Describe los procesos con el
objetivo de comprenderlo. El modelado del negocio especifica que procesos
soportara el sistema.

- Captura los requisitos funcionales


Los requisitos funcionales son capturados por medio de casos de uso, que
conforman el modelo de casos de uso.
- Captura de requisitos no funcionales
Los requisitos no funcionales especifican propiedades del sistema, como
restricciones del entorno o de la implementación, rendimiento, entre otros.
Representación de los requisitos como caso de uso en término de las actividades
• Encontrar actores y casos de uso:
Identificamos actores y casos de uso para:
- Delimitar el Sistema de su entorno.
- Esbozar quien y que (actores), interactuaran con el Sistema, y que
funcionalidad (casos de uso) se espera del sistema.
- Capturar y definir un glosario de términos comunes esenciales para la
creación de descripciones detalladas de las funcionalidades del sistema.
• Determinar la prioridad de los casos de usos:
El propósito de esta actividad es priorizar cuales son los casos de uso más
importantes para abordar en las primeras iteraciones. Los resultados se recogen
en la vista de la arquitectura del modelo de casos de uso.

• Detallar un caso de uso:


El objetivo principal de detallar cada caso de uso es, describir su flujo de sucesos
en detalle, incluyendo como comienza, termina e interactúan con los actores.
Flujo de trabajo Análisis
El objetivo de este flujo de trabajo es analizar los requisitos, refinarlos y
estructurarlos en un modelo de objetivo que sirva como primera impresión del
modelo de diseño. En esta fase se utiliza el modelo de análisis para definir con
precisión los casos de uso, y se establece una arquitectura candidata básica. Para
este flujo de trabajo se debe de tomar en consideración las siguientes actividades:
- Análisis de la Arquitectura:
Esta actividad en esta fase consiste en clasificar los casos de usos o escenarios
necesarios para examinar, comprender y refinarlos. Dado este conjunto inicial de
casos de uso y escenario, el arquitecto construye una versión del modelo de
análisis para esta fase del sistema, pero de una forma básica ya que en la
siguiente fase realizara otro de una formas más profunda.
- Analizar un caso de uso:
Esta actividad se basa en realizar un análisis del modelo de casos de usos, el cual
muestra un caso de uso a la vez, permite verificar cuales son los casos de usos
que comparten recurso del sistema (base de datos, recursos computacionales),
para así resolver cualquier conflicto que se pueda presentar.
Flujo de trabajo Diseño
En esta fase el objetivo principal es esbozar un modelo de diseño de la
arquitectura candidata, con la finalidad de incluirlo en la descripción de la
arquitectura preliminar.
Este prototipo se muestra a los usuarios respectivos, para asegurar que
este satisfice sus necesidades y si hace falta, para hacer los cambios necesarios
para satisfacer las mismas.
- Diseño de la Arquitectura:
La intención del diseño de arquitectura, es desarrollar un esbozo inicial del modelo
de diseño, un primer paso para la vista de la arquitectura del modelo de diseño
que realice los casos de usos como colaboraciones del subsistema. Además las
interfaces son importantes porque forma el núcleo de la arquitectura, como
también se debe de elegir el software del sistema y los marcos de trabajo que se
utilizan en la fase intermedia.
Flujo de trabajo de implementación y prueba
Las actividades de este flujo de trabajo no interactúan en esta fase.
Modelado de casos de uso en la fase de inicio
El modelo de casos de uso permite a los desarrolladores de software y los clientes
llegar a un acuerdo sobre los requisitos, es decir, sobre las condiciones y
posibilidades que debe cumplir el sistema.
Modelado de análisis en la fase de inicio
El modelo de análisis describe un conjunto de Clases del Análisis, que se utilizan
para realizar una descripción abstracta de la realización de los casos de uso del
modelo de casos de uso.

Fase de Elaboración

Durante la fase de elaboración se especifican en detalle la mayoría de los casos


de uso del producto y se diseña la arquitectura. El resultado de esta fase es la
línea base de la arquitectura
La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de
Vida.
Iteraciones en la fase de elaboración:
- Establecen una firme comprensión del problema a solucionar.
- Establece la fundación arquitectural para el software.
- Establece un plan detallado para las siguientes iteraciones.
- Elimina los mayores riesgos
En esta fase se construyen típicamente los siguientes artefactos:
- El cuerpo básico del software en la forma de un prototipo arquitectural.
- Casos de prueba.
- La mayoría de los casos de uso (80%) que describen la funcionalidad del
sistema.
- Un plan detallado para las siguientes iteraciones.
El hito de la Arquitectura del Ciclo de Vida con el que finaliza esta fase, se alcanza
cuando el equipo de desarrollo y la parte interesada llegan a un acuerdo sobre:
- Los casos de uso describen la funcionalidad del sistema.
- La línea base de la arquitectura.
- Los mayores riesgos han sido mitigados.
- El plan del proyecto.
Al finalizar esta fase se debe ser capaz de responder las siguientes preguntas:
- ¿La línea base de la arquitectura que se ha creado es adaptable y robusta?
¿Puede evolucionar?
- ¿Se han identificado y eliminado los riesgos más graves?
- ¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para
respaldar una agenda, costes y calidad realistas?
- ¿Proporciona el proyecto, una adecuada recuperación de la inversión?
- ¿Se ha obtenido la aprobación de los inversores?

Flujo de trabajo de una iteración de la Fase de Elaboración:


Recopilar requisitos
En esta fase el flujo de trabajo establece la prioridad y estructura de los casos de
uso.

• Encontrar casos de uso y Actores


El analista del sistema identifica casos de uso y actores adicionales a aquellos,
identificados en la fase de inicio. (Se debe identificar por lo menos el 80% de los
casos de uso para alcanzar los objetivos de esta fase)
• Determinar la Prioridad de los casos de uso
Nuestra primera acción en este flujo de trabajo es de encontrar nuevos casos de
uso, sin embargo se debe llevar en paralelo la definición de la prioridad de los
mismos, basándonos en los niveles de riesgo que estos simbolizan para el
sistema.
• Detallar un caso de uso
En esta fase no se detallan completamente todos los casos de uso, sino aquellos
que producen los riesgos más importantes y los que necesitamos para esta fase
(crear la línea base de la arquitectura).
• Estructurar el modelo de los casos de uso
En esta sección se revisa (el analista de sistemas) lo que se ha hecho en los
diagramas de caso de uso, con la finalidad de encontrar redundancia en la
información y de esta forma simplificar los casos de uso.
Análisis
Este flujo trabaja con los casos de uso que son significativos desde un punto de
vista de la arquitectura.
• Análisis de la arquitectura
Este primer flujo de trabajo de análisis consiste en realizar paquetes de análisis
del sistema, basándose en modelo de casos de usos del flujo anterior.
• Analizar un caso de uso
Se analizan aquellos casos de usos que no son totalmente comprensibles de la
forma que están descritos. Se refinan los casos de usos mencionados por medio
de clases de análisis.
Se analizarán solo unos pocos casos de uso comprendidos entre los detallados en
el flujo anterior
• Analizar una clase
Las clases de análisis identificadas en el caso anterior son refinadas.
• Analizar un paquete
Luego de que las clases de análisis se agrupan en paquetes de servicios, los
ingenieros de componentes asumirán la responsabilidad de los paquetes, su
refinamiento y mantenimiento.
Diseño
En este flujo de trabajo se diseña e implementa al menos un 10% de los casos de
uso. En la fase de elaboración se diseña desde el punto de vista de la
arquitectura.
• Diseño de la arquitectura
La vista de la arquitectura del modelo de diseño incluye subsistemas, clase,
interfaces y realización de los casos de uso arquitectónicamente significativos.
• Diseño de un caso de uso
Los paquetes y clases del análisis proporcionan una forma directa de encontrar
subsistemas y clases del diseño. Una vez encontrados se describirá las
responsabilidades y el detalle de las interacciones entre ellos.
En el diseño se especifica las operaciones usadas para la comunicación.
• Diseñar una clase
Esta parte se encarga de diseñar las clases que participaron en las realizaciones
del caso de uso del paso anterior. Los ingenieros de componentes integran los
diferentes roles de cada clase en una clase consistente.
• Diseñar un Sub Sistema
Los ingenieros de componentes diseñan los subsistemas resultantes del diseño de
la arquitectura. El arquitecto podrá actualizar la vista del modelo de diseño si es
necesario.
Implementación
Este flujo de trabajo se encarga de implementar y realizar pruebas de
componentes a partir de los elementos de diseño. El resultado de este es la línea
base de la arquitectura.
• Implementación de la arquitectura
Se identifican los componentes necesarios para implementar los subsistemas de
servicio. Los componentes ejecutables se asignan a los nodos de la red de
computadores en la que van a ejecutarse.
• Implementación de una clase e implementación de un subsistema
Los ingenieros de componentes implementarán las clases en término de
componente que fueron diseñados en el flujo de diseño.
• Integrar el sistema
Sobre la base del pequeño porcentaje de casos de uso que se han de
implementar en esta iteración, el responsable de integrar el sistema establece la
secuencia de integración en un plan de integración, seguido de esto integra los
subsistemas y los componentes correspondientes en una línea base de la
arquitectura ejecutable.
Prueba
El objetivo de este flujo de trabajo es asegurar de que los subsistemas de todos
los niveles y de todas las capas funcionen.
Empezar por las capas más bajas de la arquitectura significa probar los
mecanismos de distribución, almacenamiento, recuperación y concurrencia de
objetos. Esto implica no solo comprobar su funcionalidad sino también su
rendimiento.
• Planificar pruebas
El ingeniero de pruebas seleccionará los objetivos que evaluarán la línea de base
de la arquitectura.
• Diseñar las pruebas
Tomando como base estos objetivos, el ingeniero de pruebas identificara los
casos de pruebas necesarios, y preparará procedimientos de prueba para
comprobar la sucesiva integración de subsistemas hasta acabar con la línea de
base completa.
• Realizar las pruebas de integración
Según se van comprobando los componentes, quedarán listos para las pruebas de
integración. Los encargados de realizar estas pruebas comprobarán cada
construcción.

• Realizar las pruebas del sistema


Una vez que el sistema, tal y como queda definido por los casos de prueba
significativos, ha sido integrado, el ingeniero de pruebas del sistema lo prueba, el
mismo revisará que los resultados de las pruebas del sistema para verificar que se
cumplen los objetivos originales o para decir cómo se deben modificar los casos
de prueba con objeto de alcanzar estos objetivos.

Modelado de Análisis en la Fase de Elaboración y su representación gráfica.

En esta fase el modelo de análisis es la que describe un conjunto de clases del


Análisis, que se utilizan para realizar una descripción abstracta de la realización de
los casos de uso del modelo de casos de uso anterior.
El modelo de análisis en la fase de elaboración se puede representar gráficamente
a través de diagrama de clase de análisis y diagrama de colaboración, de los
casos de uso más importantes del sistema.

En la fase de elaboración el modelo de diseño se crea tomando el modelo de


análisis como entrada principal y se adapta a un entorno de implementación
particular.
Este modelo es similar al modelo de análisis, ya que incluye calificadores,
relaciones y realizaciones de casos de uso, y existe una relación de traza entre los
artefactos del diseño y los de análisis.
Las clases de diseño normalmente tienen una traza a una clase de análisis. Esto
es habitual para las clases de diseño que son específicas de la aplicación,
diseñadas para dar soporte a una aplicación o a un conjunto de ellas.
Debemos identificar la interacción detallada entre los objetos de diseño que tienen
lugar en la realización del caso de uso en el modelo de diseño. Sin embargo
utilizaremos principalmente diagramas de secuencia para representar una
interacció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.

Flujo de trabajo de una iteración de la fase de construcción.


En las primeras iteraciones de la fase de construcción, los flujos de trabajo
iniciales reciben mayor énfasis; los últimos, un énfasis menor. Este énfasis se
desplaza a lo largo de las iteraciones de construcción.
Construcción del sistema
En este momento, los requisitos y la arquitectura son estables. El énfasis se pone
a completas las realizaciones de casos de uso para cada uno de ellos, diseñando
los subsistemas y clases necesarios, implementándolos como componentes y
probándolos tanto de forma individual como en construcciones.
Un desarrollo iterativo, guiado por los casos de uso y centrado en la arquitectura,
construye el software mediante pequeños incrementos, y añade cada incremento
a la acumulación previa de incrementos de tal forma que siempre se tenga una
construcción ejecutable. La secuencia de incrementos se ordena de forma
progresiva, de modo que los constructores nunca tienen que volver atrás varios
incrementos y rehacerlos.
Construir el software en incrementos relativamente pequeños hace que un
proyecto sea más manejable. Reduce el ámbito de los flujos de análisis, diseño
implementación y pruebas al número de aspectos y problemas comparativamente
menor encontrados dentro de un incremento individual. Aísla en gran parte riesgos
y defectos dentro del ámbito de una construcción individual, haciendo que sean
más fáciles de encontrar y tratar.
Las fases anteriores han investigado y mitigado los riesgos críticos y significativos,
pero habrá aún muchos riesgos en la lista de riesgos. Además, pueden aparecer
nuevos riegos a medida que los desarrolladores realicen construcciones e
iteraciones y que los usuarios prueben nuevos incrementos.
Requisitos
Los requerimientos en la fase de construcción se encontraran los casos de usos y
actores restantes, construir prototipos de las interfaces de usuario, detallar y
estructurar los casos de uso. En esta fase se recorre todo el camino hasta lograr el
sistema inicial con capacidad operativa, así como realizar la recopilación completa
de requisitos.
• Encontrar actores y casos de uso: Normalmente, solo se resta identificar
una pequeña fracción de los casos de uso y actores durante la fase de
construcción. Si es necesario, el analista de sistemas actualizara los casos de uso
y actores en el modelo de casos de uso.
• Desarrollar un prototipo de la interfaz de usuario: Ahora se debe diseñar las
interfaces de usuario. Lo que tenemos que hacer aquí depende del tipo de sistema
que estamos construyendo.
• De terminar la prioridad de los casos de uso: En esta fase, a medida que
identificamos casos de uso, los añadimos a la clasificación, con objeto de
establecer su prioridad.
• Detallar un caso de uso: Los encargados de especificar los casos de uso
detallaran completamente todos los casos de uso y escenarios de caso de uso
que queden.
• Estructurar el modelo de casos de uso: Debido a que en esta fase el
sistema ya tiene una arquitectura estable, cualquier cambio debe referirse
fundamentalmente a casos de uso que aún no hayan sido desarrollados.

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.

Modelo de componente y su representación grafica


El modelo de componente se describe como los elementos del modelo de diseño,
como las clases, se implementan en términos de términos de componentes, como
ficheros de código fuente, ejecutable, otro. Este modelo describe también como se
organizan los componentes de acuerdo con los mecanismos de estructuración y
modulación disponible en el entorno de implementación y en el lenguaje de
programación utilizado, y como dependen los componentes unos de otros.

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.

Modelado de las diferentes pruebas que se le aplicaran al software


El modelo de prueba describe principalmente como se prueban los componentes
ejecutables en el modelo de implementación con prueba de integración y de
sistemas. EL modelo de prueba puede describir como han de ser probado
aspectos específicos del sistema.
• Caso de prueba: Un caso de prueba específica una forma de probar el
sistema incluyendo la entrada o resultado con la que se ha de probar y las
condiciones bajo las que ha de probarse.
• Procedimiento de prueba: Un procedimiento de prueba específica como
realizar uno a varios casos de prueba o partes de estos.
• Componentes de prueba: Un componente de prueba autoriza uno o varios
procedimientos de prueba o partes de ellos. Los componentes de prueba pueden
ser desarrollados utilizando un lenguaje de guiones o un lenguaje de programa, o
puede ser grabado con una herramienta de automatización de prueba.
Módulos Diagramados
Este Proyecto está realizado en entorno web en la realización de un módulo del
sistema universitario siceudo donde se simulara la inscripción de seminario de
investigación para los estudiantes, donde se tendrá una base de datos relacional
mySQL para la manipulación de la misma y un sistema de gestión de bases de
datos conocido como xampp donde nos permite trabajar la parte del servidor
apache con la base de datos mySQL
Interfaz de Usuario:

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

La primera será cuando el estudiante este deshabilitado para la inscripción de


seminario de investigación debido a pueda que no cumpla con los requerimientos
necesarios para el mismo o aun no haya sido habilitado por el administrador,
donde al ser así le saldrá un escrito señalándole que no se encuentra habilitado
para dicha inscripción.
La segunda interfaz será luego de la habilitación por parte del administrado donde
le saldrá la opciones en secciones para la inscripción de la materia con un textfield
donde se tendrá que colocar el motivo del porque se quiere inscribir dicha materia.

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.

• La interfaz de inscripción se irán mostrando los estudiantes cuya


preinscripción haya sido cargadas donde este tendrá la opción de leer el
motivo del porque quiere inscribir la materia, sus créditos, y decidir en cual
sección descrita por el estudiante lo inscribirá.
• Método para mostrar estudiantes inscritos.(PDF)
BASE DE DATOS

You might also like