1.

Defina los elementos desde el producto

R//

Modelo de calidad:

Criterios de aceptación:

1. Debe de existir una primera verificación para el correo electrónico que valide que la persona
registrada realmente se haya registrado con un correo valido
2. Deberá existir una segunda verificación para las personas registradas tal que el administrador
pueda verificar que los que se registren en la plataforma realmente si formen parte de la red de
escuelas de música.
3. Las tareas asignadas a determinado trabajador deben ser poder vistas por él y nadie más, a
excepción del administrador que se las delegó.
4. Las estadísticas que se muestran en el panel de administración deben de ser informativas y
gráficas, es decir, es necesario que se muestren en gráficos de torta, diagramas de barras e
histogramas.
5. La única información a proveer para el inicio de sesión deberá ser el correo electrónico y la
contraseña.
6. Los campos para el registro deben de ser los suficientes con el fin de utilizarse posteriormente
en acciones tales como asignación de tareas o despliegue de estadísticas.

Metodología de desarrollo(paradigma)

 Determinar objetivos: El alcance de la necesidad es un aplicativo web que se gestione las

actividades de los empleados de las sedes de la escuela de música
1. Se realizan varias secciones para entender la necesidad del cliente y el cómo desea
resolverlo
2. Se orienta a el cliente sobre mejores posibles opciones, para obtener una mejor
experiencia para satisfacer su necesidad
3. Finalmente se llega a un acuerdo con el cliente y se elige la solución final
4. Se define las fechas de entregas de los avances y pruebas
5. Finalmente se determina el costo total del trabajo

En todo este proceso de van determinando una serie de posibles riegos, como lo es que, al
ser un aplicativo web, se puede sufrir fallas en la red la escuela de música, lo que puede
ocasionar que los usuarios tengan problemas al acceder al aplicativo. De igual forma que se
pueda filtrar información sensible como lo son datos personales de los empleados (Esto va
ligado a la topología que posea la escuela de música)

 Análisis del riesgo: Los riesgos anteriormente mencionados van todos ligados a la topología de
red que pueda poseer la escuela de música, una de las restricciones que no están dentro del
costo final, es las mejoras que se deban de realizar en la red, un ejemplo claro es que toda su
información se encuentre encriptada por toda la red y sea de fácil acceso para un tercero (Costo
del proceso se encuentra ligado al proceso y a definir con la mesa de directivos)
  Desarrollar y probar:
Fase 1 : Se realiza la primera entrega de unos de los prototipos del aplicativo, se le explica cada
uno de los objetivos logrados y se le enseña su funcionalidad, se identifican nuevas fallas y se
plantean una serie de soluciones, las cuales se determinará su solución junto con la mesa
directivos de la escuela de música, se tiene para este punto la terminación total del diseño de la
pagina web (Sujeto a mejoras)

Fase 2: Se tendrá un prototipo final, el cual cuenta con la mejoras y solución de problemas
identificados en la fase 1, en este punto se realizan varias pruebas y testing del aplicativo para
probar su perfecto funcionamiento, en este punto se reciben críticas constructivas y posibles
mejoras (Mejoras que no estén pactadas en los objetivos principales pueden tener un valor
adicional)

Fase 3: Entrega final del aplicativo el cual entra en un periodo de prueba

 Planificación:
Como se definió desde un inicio, el mantenimiento del aplicativo no va incluido en el costo que
se definió inicialmente, se determinó que dicho mantenimiento se debe de realizar cada 60 días,
con disponibilidad prioritaria en caso de fallas, todo el código se dejará documentado y se
tendrá un tipo manual con la solución de posibles fallas comunes.

Métricas

la verificación del campo de correo se realizará en 3 segundos en las siguientes condiciones: internet
mínimo de 10 megas, no tener abiertos programas en segundo plano que consuman el ancho de banda
y buscadores cuya última actualización se haya realizado del 2020 en adelante.

Se realizan 3 pruebas unitarias a la integridad de los datos del registro y tendrá que pasar 2 de las 3
pruebas realizadas.

Se efectúan 4 pruebas de integración entre la asignación de tareas y el visor de tareas, y el sistema

ganara mínimo 3 de las 4 pruebas

Herramientas de software:

ChecKing QA. Es una herramienta que controla tanto los elementos del proceso de desarrollo software
(actividades, requisitos, cambios) como los elementos analizables del software (código fuente,
proyectos, documentación, scripts de pruebas etc), esta herramienta permitirá la evaluación de los
requisitos y la automatización del proceso de software.
Google CodePro Analytix.: Esta herramienta permitirá la evaluación del tráfico transaccional de la
aplicación y la automatización de gráficas y estadísticas relacionadas a la solución.

JMeter: Permitá realizar pruebas funcionales y de rendimiento para la aplicación web.

2. Cree el diseño aplicando y definiendo patrones, principios, tàcticas, estilos y lo que considere
pertinente que soporte la necesidad.

R//

se opta por el diseño MVC dado que permite la evolución del aplicativo de una manera más eficiente al
tener la lógica de negocio separada de la interfaz del usuario y dado que la solución es un web facilita la
flexibilidad del aplicativo al poder acceder a este desde diferentes medios.

Factory method patrón destinado a indicar el proceso de creación de la clase principal y las subclases
necesarias para el funcionamiento del proyecto.

bridge patrón estructural con la funcionalidad de separar las clases de una manera relacional para saber
que clases corresponden a los diferentes procesos

Command convierte las solicitudes en objetos con el fin de que se procesen, retrasen o encolen los
objetos si no se puede realizar una acción ya sea que no se pueda procesar la solicitud o se están
realizando procesos que no puedan ser interrumpidos, entonces pone en espera la solicitud. Está
ubicado en la conexión de la base de datos y el contenedor del api.

Mediator implementado entre el contenedor de api y el contenedor de la vista del aplicativo. Este
controlador es el encargado de la hacer llegar los datos necesarios para el usuario que mando una
solicitud

Chain of responsibility: ubicado entre la solución y el usuario con el propósito de pasar todas las
solicitudes de los usuarios conectados a la solución e ir identificando si dichas solicitudes se procesan o
pasan al siguiente manejador.

Diagrama
Principios de los patrones de comportamiento:

 Command: Uno de los principios que más se resaltan es la encapsulación, ya que este patrón
tiene la función de contener una solicitud e identifica los argumentos que se requieren para
ejecutar dicha solicitud

 Mediator: El principio que tiene más relevancia sobre este es el de información escondida, el
cual es el que encapsula y lleva la información subministrada por la base de datos, según la
petición del usuario y lo muestra únicamente en la interfaz grafica
 Chain of responsability: Para este patrón de cadena de responsabilidad se adapta de una buena
manera a el principio de acoplamiento, ya que para este el emisor y el receptor no se
encuentran conectados directamente, por este pasa la cadena de elementos y cada uno de
estos es totalmente autónomo de tomar la decisión si consumir el dato o si desea pasárselo a el
siguiente elemento

Patrones de creación

Factory method: Este se asocia fácilmente con el principio de interfaz, ya que es el encargado de
delegar la creación de un conjunto de objetos, que posee unas características similares, sin
necesidad que se tenga un conocimiento previo de cómo se crean

Patrones estructurales
  Bridge: Sabemos que el patrón bridge se asocia bastante con la suficiencia, ya que este patrón
genera una alteración estructural en las clases principales y de implementador de interfaz sin
tener ningún efecto entre las mismas

Tácticas: