Plan de Prácticas

UNIVERSIDAD NACIONAL DE TRUJILLO
FACULTAD DE INGENIERÍA
ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE SISTEMAS
INFORME INICIAL DE PLAN DE PRÁCTICAS

PRE-PROFESIONALES
PRUEBAS DE INTEGRACIÓN DEL SUBSISTEMA ‘Aula Virtual’ DEL

SISTEMA UNIVERSITARIO VIRTUAL DE LA UNT
AUTORES:
- RUIZ VIDAURRE, CAROLINE ESTEFANIA
ASESOR:
Mg. SANTOS FERNÁNDEZ JUAN PEDRO

Mg. SANCHEZ TICONA, ROBERT JERRY
TRUJILLO, ENERO DEL 2019
TRUJILLO, NOVIEMBRE DEL 2016

Universidad Nacional de Trujillo Facultad de Ingeniería
Escuela de Ingeniería de Sistemas
CONTENIDO
I. GENERALIDADES ..................................................................................................... 3
1. Título: ..................................................................................................................... 3
2. Autores: ................................................................................................................. 3
3. Asesores: ............................................................................................................... 3
4. Tipo de Investigación: .......................................................................................... 3
4.1. De acuerdo a la orientación: ................................................................................ 3
5. Régimen de Investigación: ................................................................................... 3
6. Localidad e Institución donde se desarrollará el proyecto: ............................... 4
5.1 Localidad: ....................................................................................................... 4
5.2 Institución: ...................................................................................................... 4
7. Realidad Problemática .......................................................................................... 4
II. FORMULACIÓN DEL PROBLEMA............................................................................ 4
III. HIPÓTESIS ............................................................................................................. 4
IV. OBJETIVOS ........................................................................................................... 4
V. METODOLOGIA......................................................................................................... 5
VI. REFERENCIAS BIBLIOGRAFICAS ..................................................................... 16
1. Páginas Web .................................................................................................... 16
VII. RECURSOS .......................................................................................................... 17
1. Recursos Disponibles......................................................................................... 17
1.1 Personal ........................................................................................................ 17
1.2 Locales: ........................................................................................................ 17
VIII. PRESUPUESTO ................................................................................................... 17
IX. CRONOGRAMA DE EJECUCIÓN ........................................................................ 18
2|Informe de Practicas
I. GENERALIDADES:
1. Título:
Pruebas de Integración del Subsistema ‘Aula virtual’ Sistema Virtual

Universitario de la UNT
2. Autor:
- Ruiz Vidaurre, Caroline Estefania
3. Asesores:
- Mg. Santos Fernández, Juan Pedro

- Mg. Sanchez Ticona, Robert Jerry
4. Tipo de Investigación:
4.1. De acuerdo a la orientación:
 Aplicada:
Porque se está dando solución a un problema particular aplicando

técnicas y herramientas propias de ingeniería, así también,
metodologías existentes que permitirán el desarrollo de la
investigación.
5. Régimen de Investigación:
 Libre:
Porque el Proyecto de investigación científica, tecnológica e innovadora

fondos del Canon Minero PIC12-2013, cuyo responsable es Ing. Mg.
Juan Pedro Santos Fernández, nos ha facilitado la información del
sistema académico para el Estudio de nuestra Investigación.
6. Localidad e Institución donde se desarrollará el proyecto:
5.1 Localidad:
Trujillo - Perú
5.2 Institución:
- Ruc: N° 20172557628
- Razón Social: Universidad Nacional de Trujillo
- Dirección: Av. Juan Pablo II s/n (Ciudad Universitaria)
- Provincia: Trujillo
- Teléfono: (044) 205448 - 232528
- Página Web: www.unitru.edu.pe
7. Realidad Problemática:
Actualmente se ha culminado el Sistema Universitario Virtual faltando las pruebas
unitarias y las pruebas modulares de integración para validar su performance y su
desempeño.
II. FORMULACIÓN DEL PROBLEMA:

¿De qué manera incide las pruebas de integración en el subsistema ‘Aula virtual’ en
la unificación del Sistema Universitario Virtual de la Universidad Nacional de Trujillo?
III. HIPÓTESIS:
Las pruebas de integración del subsistema ‘Aula virtual’ garantizan la performance
y continuidad del Sistema Universitario Virtual de la Universidad Nacional de Trujillo.
IV. OBJETIVOS:
 Objetivo general:
Garantizar la performance y continuidad del Sistema Universitario Virtual de la

Universidad Nacional de Trujillo con las pruebas de integración.
 Objetivos específicos:
 Identificar errores introducidos por la combinación de programas probados

unitariamente.
 Determinar cómo la base de datos de prueba será cargada.
 Verificar que las interfaces entre las entidades externas (usuarios) y las
aplicaciones funcionan correctamente.
 Verificar que las especificaciones de diseño sean alcanzadas.
 Determina el enfoque para avanzar desde un nivel de integración de las

componentes al siguiente.
V. METODOLOGÍA:
RUP es un marco de proyecto que nos permite llevar a cabo la gestión del
proceso de desarrollo de un software basado en casos de uso. Utiliza el enfoque
de la orientación a objetos en su diseño y está diseñado y documentado bajo el
uso de la notación UML (Unified Modeling Language) como una metodología
estándar. RUP es el proceso de desarrollo más general de los existentes
actualmente.
Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de
iteraciones concerniente a sus estimaciones originales.
1. CARACTERÍSTICAS DE RUP:
El RUP es un proceso basado en modelos en cascada y por componentes.

Incluye artefactos (que son los productos tangibles del proceso como, por
ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que
desempeña una persona en un determinado momento, una persona puede
desempeñar distintos roles a lo largo del proceso).
 Dirigido por Casos de Uso. Son los usuarios de lo que requiere el

sistema, en el están las interacciones de cómo se relacionara los
usuarios con el software.
 Centrado en la arquitectura. Se relaciona a como se debe ver el

proyecto cuando se está en desarrollo. En él se instauran los modelos
del sistema, determinando que el software es un todo y tiene sus
partes.
 Iterativo Incremental. Divide el software en pequeños proyectos para
que sea más como trabajar con ellos con esto se logra la iteración que
va en aumento con la funcionalidad.
 Conceptualmente amplio y diverso.
 Enfoque orientado a objetos.
 En evolución continua.
 Adaptable, Repetible.
2. DIMENSIONES DEL RUP:
RUP tiene dos dimensiones:
- El eje horizontal representa tiempo y demuestra los aspectos del ciclo de

vida del proceso.
- El eje vertical representa las disciplinas, que agrupan actividades
definidas Lógicamente por la naturaleza.
La primera dimensión representa el aspecto dinámico del proceso y se

expresa en términos de fases, de iteraciones, y la finalización de las fases.
La segunda dimensión representa el aspecto estático del proceso: cómo se

describe en términos de componentes de proceso, las disciplinas, las
actividades, los flujos de trabajo, los artefactos, y los roles. En la siguiente
figura se puede observar como varía el énfasis de cada disciplina en un cierto
plazo en el tiempo, y durante cada una de las fases.
Por ejemplo, en iteraciones tempranas, pasamos más tiempo en
requerimientos, y en las últimas iteraciones pasamos más tiempo en poner
en práctica la realización del proyecto en sí.
2.1. Características esenciales:
Los autores de RUP destacan que el proceso de software propuesto por

RUP tiene tres características esenciales: está dirigido por los Casos de
Uso, está centrado en la arquitectura, y es iterativo e incremental.
2.1.1.- Proceso dirigido por Casos de Uso:
Los Casos de Uso son una técnica de captura de requisitos que fuerza a
pensar en términos de importancia para el usuario y no sólo en términos
de funciones que sería bueno contemplar. Se define un Caso de Uso
como un fragmento de funcionalidad del sistema que proporciona al
usuario un valor añadido.
Los Casos de Uso representan los requisitos funcionales del sistema. En

RUP los Casos de Uso no son sólo una herramienta para especificar los
requisitos del sistema. También guían su diseño, implementación y
prueba. Los Casos de Uso constituyen un elemento integrador y una guía
del trabajo como se muestra en la siguiente figura:
Los Casos de Uso no sólo inician el proceso de desarrollo, sino que

proporcionan un hilo conductor, permitiendo establecer trazabilidad entre
los artefactos que son generados en las diferentes actividades del
proceso de desarrollo.
Como se muestra en la siguiente figura, basándose en los Casos de Uso

se crean los modelos de análisis y diseño, luego la implementación que
los lleva a cabo, y se verifica que efectivamente el producto implemente
adecuadamente cada Caso de Uso. Todos los modelos deben estar
sincronizados con el modelo de Casos de Uso
2.1.2- Proceso centrado en la arquitectura:
La arquitectura de un sistema es la organización o estructura de sus

partes más relevantes, lo que permite tener una visión común entre
todos los involucrados (desarrolladores y usuarios) y una perspectiva
clara del sistema completo, necesaria para controlar el desarrollo.
En el caso de RUP además de utilizar los Casos de Uso para guiar el

proceso se presta especial atención al establecimiento temprano de una
buena arquitectura que no se vea fuertemente impactada ante cambios
posteriores durante la construcción y el mantenimiento. Cada producto
tiene tanto una función como una forma. La función corresponde a la
funcionalidad reflejada en los Casos de Uso y la forma la proporciona la
arquitectura.
Existe una interacción entre los Casos de Uso y la arquitectura, los

Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo
y la arquitectura debe permitir el desarrollo de todos los Casos de Uso
requeridos, actualmente y en el futuro. Esto provoca que tanto
arquitectura como Casos de Uso deban evolucionar en paralelo durante
todo el proceso de desarrollo de software.
En la siguiente figura se ilustra la evolución de la arquitectura durante

las fases de RUP. Se tiene una arquitectura más robusta en las fases
finales del proyecto. En las fases iniciales lo que se hace es ir
consolidando la arquitectura por medio de baselines y se va modificando
dependiendo de las necesidades del proyecto.
Es conveniente ver el sistema desde diferentes perspectivas para
comprender mejor el diseño por lo que la arquitectura se representa
mediante varias vistas que se centran en aspectos concretos del sistema,
abstrayéndose de los demás.
2.1.3.- Proceso iterativo e incremental:
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy

parecido al equilibrio de la forma y la función en el desarrollo del
producto, lo cual se consigue con el tiempo. Para esto, la estrategia que
se propone en RUP es tener un proceso iterativo e incremental en donde
el trabajo se divide en partes más pequeñas o mini proyectos.
Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya

logrando durante cada mini proyecto, así durante todo el proceso de
desarrollo.
Cada mini proyecto se puede ver como una iteración (un recorrido más
o menos completo a lo largo de todos los flujos de trabajo fundamentales)
del cual se obtiene un incremento que produce un crecimiento en el
producto. Una iteración puede realizarse por medio de una cascada
como se muestra en la siguiente figura.
Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,

Implementación y Pruebas), también existe una planificación de la
iteración, un análisis de la iteración y algunas actividades específicas de
la iteración. Al finalizar se realiza una integración de los resultados con
lo obtenido de las iteraciones anteriores.
El proceso iterativo e incremental consta de una secuencia de

iteraciones. Cada iteración aborda una parte de la funcionalidad total,
pasando por todos los flujos de trabajo relevantes y refinando la
arquitectura.
Cada iteración se analiza cuando termina. Se puede determinar si han

aparecido nuevos requisitos o han cambiado los existentes, afectando a
las iteraciones siguientes. Durante la planificación de los detalles de la
siguiente iteración, el equipo también examina cómo afectarán los
riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de
la iteración pasada permite reajustar los objetivos para las siguientes
iteraciones.
3. FASES DE RUP:
En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 fases

secuenciales, cada cual concluye con un producto intermedio. Al terminar
cada fase se realiza una evaluación para determinar si se ha cumplido o no
con los objetivos de la misma.
Las fases son:
- Inicio (Inception):
El objetivo general de esta fase es establecer un acuerdo entre todos los

interesados acerca de los objetivos del proyecto.
Es significativamente importante para el desarrollo de nuevo software, ya

que se asegura de identificar los riesgos relacionados con el negocio y
requerimientos.
Para proyectos de mejora de software existente, esta fase es más breve

y se centra en asegurar la viabilidad de desarrollar el proyecto.
- Elaboración
El objetivo en esta fase es establecer la arquitectura base del sistema

para proveer bases estables para el esfuerzo de diseño e
implementación en la siguiente fase.
La arquitectura debe abarcar todas las consideraciones de mayor

importancia de los requerimientos y una evaluación del riesgo.
10 | I n f o r m e d e P r a c t i c a s
- Construcción:
El objetivo de la fase de construcción es clarificar los requerimientos

faltantes y completar el desarrollo del sistema basados en la arquitectura
base.
Vista de cierta forma esta fase es un proceso de manufactura, en el cual

el énfasis se torna hacia la administración de recursos y control de la
operación para optimizar costos, tiempo y calidad.
- Transición:
Esta fase se enfoca en asegurar que el software esté disponible para sus
usuarios.
Se puede subdividir en varias iteraciones, además incluye pruebas del

producto para poder hacer el entregable del mismo, así como realizar
ajuste menor de acuerdo a ajuste menores propuestos por el usuario.
En este punto, la retroalimentación de los usuarios se centra en depurar

el producto, configuraciones, instalación y aspectos sobre utilización.
4. PRUEBAS DE CALIDAD DE DESARROLLO DE SOFTWARE:
Las pruebas de software son importantes porque aseguran el correcto

cumplimiento de la funcionalidad del producto, ayudan a ganar confianza,
confirman la fiabilidad del uso y previenen defectos en producción, lo cual
tiene un impacto económico positivo en la empresa en cuestión.
RUP nos permite valorar la calidad del software por medio de los siguientes
objetivos:
 Encontrar y documentar los defectos en la calidad del software

 Aconsejando acerca de la calidad percibida en el software
 Proveyendo la validación de los supuestos hechos en las
especificaciones de diseño y los requerimientos a través de
demostraciones concretas.
 Validando las funciones del producto de software según fueron
diseñadas
 Validando que los requerimientos hayan sido implementados
apropiadamente
 Validación del diseño.
Las pruebas de software son una actividad primordial en el proceso de

“aseguramiento de la calidad”.
El conjunto de actividades de pruebas dentro del proceso de desarrollo de

software, son conocidas como proceso básico de pruebas, el cual incluye:
 Planeación. Donde se hace un esquema de ¿qué se va a probar?,

¿cómo se va a probar?, ¿quién lo va a probar? y ¿cuándo? A la
salida de esta fase podemos mencionar que se obtiene un plan de
pruebas maestro que incluye estrategia y enfoque de pruebas.
 Análisis y diseño de pruebas. En esta fase se analizan los

requerimientos y se diseñan los casos de prueba, incluyendo en esta
actividad casos de prueba positivos y casos de prueba negativos,
podemos encontrar más detalle de lo que debe contener un caso de
prueba dentro del estándar IEEE 829. A la salida de esta fase se
tendrán los casos de prueba.
 Ejecución de pruebas. Esta fase es la más importante ya que, es

donde los casos de prueba son ejecutados en un ambiente de
prueba o calidad para validar que los requerimientos especificados
se hayan implementado de la manera correcta, es en este punto
donde se aplica la estrategia de pruebas. A la salida de esta fase
tendremos el avance de ejecución y los reportes a directivos
(generar información para las partes interesadas).
 Evaluación de resultados. En esta fase es donde determinamos si

se han alcanzado los objetivos de las pruebas, es decir, si la
implementación de los requerimientos fue la óptima, lo ideal es que
el usuario realice también otras pruebas para dar el visto bueno a la
aplicación y ésta pueda ser puesta en producción.
 Cierre de pruebas. Es la última fase del proceso de pruebas, aquí

archivamos toda la documentación generada y se realiza una carta
de aceptación de cierre que debe ser firmada por los directivos
involucrados, también es bueno incluir los riesgos activos de la
aplicación, si es que aplica.
Estas actividades podrán ser implementadas en cualquier momento

de dicho proceso de desarrollo. De manera general, se puede decir
que las pruebas de software permiten determinar si el producto
generado satisface las especificaciones establecidas. Así mismo,
una prueba de software permite detectar la presencia de errores que
pudieran generar salidas o comportamientos inapropiados durante
su ejecución.
4.1. Etapas o niveles de pruebas:
4.1.1. Verificación o validación:
En la actualidad existen muchos modelos de desarrollo de software,

es un reto para el ingeniero de pruebas amoldarse a cada modelo con
el fin de cubrir todas las tareas y actividades de manera óptima.
El modelo tradicional de desarrollo y pruebas es conocido como el

modelo V, donde se describen las actividades de desarrollo y las
correspondientes actividades en pruebas.
El modelo V como se muestra en la siguiente figura plantea que en

todo este proceso se debe llevar a cabo la verificación y validación y
se realiza como se menciona a continuación.
Cada nivel de desarrollo se verifica con el nivel anterior, es decir, se

comprueba si los requisitos y definiciones de niveles previos han sido
implementados de forma correcta.
La validación se refiere a la corrección de cada nivel de desarrollo, de

esta manera se comprueba lo adecuado de los resultados de un nivel
de desarrollo.
De esta manera podemos observar que el proceso de pruebas

comienza antes que la ejecución de las mismas, tan pronto comienza
el desarrollo se puede comenzar la preparación de las pruebas
correspondientes, como es el caso de la revisión de documentos.
4.1.2. Pruebas Unitarias:
Como se observa en el modelo V se describen los niveles de prueba

existentes, comenzaremos explicando el primer nivel “pruebas
unitarias”.
Un componente es la unidad más pequeña especificada de un

sistema, las pruebas se llevan a cabo tras la construcción o
realización de cada componente para verificar que la implementación
se esté llevando conforme a los estándares acordados.
De acuerdo a cada lenguaje de programación se puede hacer

referencia a un componente como:
 Prueba de módulo (en C)

 Prueba de clase (en Java o C++)
 Prueba de unidad (en Pascal)
Se hace referencia a los componentes como módulos, clases o

unidades, debido a que los desarrolladores pueden estar
involucrados en la ejecución de pruebas, pueden llamarse también
pruebas de desarrollador.
Es importante mencionar que estas pruebas las ejecuta el

desarrollador verificando que su código cumple con lo solicitado y no
ha violado ningún estándar que ponga en riesgo la estabilidad del
sistema.
Las pruebas de componente podrán comprobar características

funcionales y no funcionales de un sistema.
4.1.3. Pruebas de Integración:
Las pruebas integrales también son conocidas como pruebas de

interfaz, ya que comprueban la interacción entre los componentes del
software.
Las pruebas de integración asumen que los módulos ya han sido

probados de manera individual (pruebas unitarias).
Implican una progresión ordenada de pruebas que van desde los

componentes o módulos y que culminan en el sistema completo.
El orden de integración elegido afecta a diversos factores como los

siguientes:
 La forma de preparar casos

 Las herramientas necesarias
 El orden de codificar y probar los módulos
 El costo de la depuración
 El costo de preparación de casos
Las pruebas de componente podrán comprobar características

funcionales y no funcionales de un sistema.
Existen tres enfoques para realizar pruebas de integración, todos

obedecen a modelos de desarrollos incrementales o iterativos, como
scrum, xtreme programing y cascada, estos enfoques pueden ser:
 Ascendente. Cuando el desarrollo del sistema comienza con

piezas unitarias y crece hasta formar módulos.
 Descendente. Cuando se muestra el front de la aplicación,
pero está hueca por dentro y se comienza a trabajar desde los
módulos más grandes hasta llegar al detalle o a las partes
unitarias.
 Big Bang. Que va de la mano con xtreme programing porque
el desarrollo no tiene un orden específico y puede ser al azar.
Cualquier enfoque distinto a estos es llamado ad-hoc que encaja

con el modelo de desarrollo tradicional V.
4.1.3. Pruebas de Sistema:
Las pruebas de sistema se llevan a cabo cuando todo el desarrollo

ha sido culminado y tenemos una versión preliminar del sistema que
saldrá a producción. Esta etapa de pruebas consiste en probar un
sistema integrado con el objeto de comprobar el cumplimiento de
requisitos especificados.
Las pruebas se hacen con un enfoque desde el punto de vista del

usuario.
Las pruebas de sistema se desarrollan utilizando casos de prueba

funcionales y no funcionales. Las pruebas funcionales confirman que
los requisitos para un uso específico previsto han sido cumplidos
(validación).
Las pruebas de sistema no funcionales verifican los atributos de

calidad no funcionales.
4.1.3. Pruebas de Aceptación:
El objetivo en este nivel de prueba es obtener el visto bueno del

cliente, no se deberían encontrar defectos funcionales graves en el
sistema. Es por ello que las pruebas de aceptación son realizadas por
el usuario.
Se puede decir que las pruebas de aceptación son las pruebas de

sistema por parte del cliente.
Existen dos tipos de pruebas de aceptación:
 Pruebas Alfa. El cliente utiliza el software para hacer el

tratamiento de sus procesos de negocio en las dependencias
del proveedor.
 Pruebas Beta. Estas se ejecutan en las dependencias del

cliente.
Las pruebas de aceptación son consideradas como la fase final del

proceso para crear una confianza en que el producto es apropiado
para su uso, de esta manera se verificará que el software satisface
los requisitos del cliente.
VI. REFERENCIAS BIBLIOGRÁFICAS:
1. Páginas Web
 Reglamento de Prácticas Pre-Profesionales. Recuperado de

https://sites.google.com/site/ingesistemasunt/reglamentos-de-practpre-
profesionales
 Metodología RUP (RATIONAL UNIFIED PROCESS). Recuperado de

https://es.slideshare.net/bernardolimachi/metodologiarup14288208?ne
xt_slideshow=1
 Metodología Extrema RUP. Recuperado de https://metodoss.com/méto

dologia-rup/
 Campo, Cindy. (2015). Las pruebas en el desarrollo del software (Tesis

de pregrado). Universidad Nacional Autónoma de México, México.
Recuperado de http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/ha
ndle/132.248.52.100/7627/Las%20pruebas%20en%20el%20desarrollo
%20de%20software.pdf?sequence=1.
VII. RECURSOS
1. Recursos Disponibles:
1.1 Personal:
Investigador:
 Ruiz Vidaurre, Caroline Estefania.
1.2 Locales:
 Centro de cómputo de Ingeniería de Sistemas de la UNT.
VIII. PRESUPUESTO
Tabla Nª 1.3: PRESUPUESTO
COSTO PRECIO
DESCRIPCIÓN CANTIDAD
UNITARIO TOTAL
Equipos:
Computadoras de S/. S/.
1
Escritorio 3,000.00 3,000.00
S/. S/.
Total de Equipos: 1
3,000.00 3,000.00
Software
Lenguaje de S/. S/.
1
Programación: PHP 0,00 0,00
Base de Datos: S/. S/.
1
PostgreSQL 9.5 0,00 0,00
S/. S/.
ID: Sublime Text 3 1
0,00 0,00
S/. S/.
WAMPSERVER v3.06 1
0,00 0,00
S/. S/.
DataGrip v2017.3.4 1
0,00 0,00
Total Software: S/. -
S/.
TOTAL
3,000.00
Fuente: (Elaboración Propia, 2019)
IX. CRONOGRAMA DE EJECUCIÓN:
 Fecha de inicio: 16/01/2019

 Fecha de término: 10/04/2019
NOTA: Dado que el alumno realizara 25 horas a la semana, para cubrir las
horas de prácticas, se calcula 12 semanas. Se da esa prórroga a los
practicantes para terminar el plan que están presentando y además previendo
la semana o días que no haya atención o sean feriados. Si los alumnos
terminan sus 300 horas y se ha cumplido con los objetivos trazados, los
practicantes pueden tomar la decisión de dar por culminado sus prácticas
dentro de su facultad.

Plan de Prácticas

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Plan de Prácticas

Transféré par

Droits d'auteur :

Formats disponibles

UNIVERSIDAD NACIONAL DE TRUJILLO

INFORME INICIAL DE PLAN DE PRÁCTICAS

PRUEBAS DE INTEGRACIÓN DEL SUBSISTEMA ‘Aula Virtual’ DEL

- RUIZ VIDAURRE, CAROLINE ESTEFANIA

Mg. SANTOS FERNÁNDEZ JUAN PEDRO

TRUJILLO, ENERO DEL 2019

TRUJILLO, NOVIEMBRE DEL 2016

Pruebas de Integración del Subsistema ‘Aula virtual’ Sistema Virtual

- Ruiz Vidaurre, Caroline Estefania

- Mg. Santos Fernández, Juan Pedro

4.1. De acuerdo a la orientación:

Porque se está dando solución a un problema particular aplicando

Porque el Proyecto de investigación científica, tecnológica e innovadora

II. FORMULACIÓN DEL PROBLEMA:

Garantizar la performance y continuidad del Sistema Universitario Virtual de la

 Identificar errores introducidos por la combinación de programas probados

 Determinar cómo la base de datos de prueba será cargada.

 Verificar que las especificaciones de diseño sean alcanzadas.

 Determina el enfoque para avanzar desde un nivel de integración de las

El RUP es un proceso basado en modelos en cascada y por componentes.

 Dirigido por Casos de Uso. Son los usuarios de lo que requiere el

 Centrado en la arquitectura. Se relaciona a como se debe ver el

 Conceptualmente amplio y diverso.

 Enfoque orientado a objetos.

2. DIMENSIONES DEL RUP:

RUP tiene dos dimensiones:

- El eje horizontal representa tiempo y demuestra los aspectos del ciclo de

La primera dimensión representa el aspecto dinámico del proceso y se

La segunda dimensión representa el aspecto estático del proceso: cómo se

2.1. Características esenciales:

Los autores de RUP destacan que el proceso de software propuesto por

2.1.1.- Proceso dirigido por Casos de Uso:

Los Casos de Uso representan los requisitos funcionales del sistema. En

Los Casos de Uso no sólo inician el proceso de desarrollo, sino que

Como se muestra en la siguiente figura, basándose en los Casos de Uso

2.1.2- Proceso centrado en la arquitectura:

La arquitectura de un sistema es la organización o estructura de sus

En el caso de RUP además de utilizar los Casos de Uso para guiar el

Existe una interacción entre los Casos de Uso y la arquitectura, los

En la siguiente figura se ilustra la evolución de la arquitectura durante

2.1.3.- Proceso iterativo e incremental:

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy

Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya

Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño,

El proceso iterativo e incremental consta de una secuencia de

Cada iteración se analiza cuando termina. Se puede determinar si han

En cuanto a tiempo el ciclo de vida de RUP se descompone en 4 fases

Las fases son:

El objetivo general de esta fase es establecer un acuerdo entre todos los

Es significativamente importante para el desarrollo de nuevo software, ya

Para proyectos de mejora de software existente, esta fase es más breve

El objetivo en esta fase es establecer la arquitectura base del sistema

La arquitectura debe abarcar todas las consideraciones de mayor

El objetivo de la fase de construcción es clarificar los requerimientos

Vista de cierta forma esta fase es un proceso de manufactura, en el cual

Se puede subdividir en varias iteraciones, además incluye pruebas del

En este punto, la retroalimentación de los usuarios se centra en depurar

4. PRUEBAS DE CALIDAD DE DESARROLLO DE SOFTWARE:

Las pruebas de software son importantes porque aseguran el correcto

 Encontrar y documentar los defectos en la calidad del software

Las pruebas de software son una actividad primordial en el proceso de

El conjunto de actividades de pruebas dentro del proceso de desarrollo de

 Planeación. Donde se hace un esquema de ¿qué se va a probar?,