Está en la página 1de 5

UNVIERSIDAD LIBRE

INGENIERIA DE SOFTWARE 2

Segundo Parcial

1. Cuá l es la funció n del documento de arquitectura

 La funcionalidad del documento de arquitectura es:

o Por mi experiencia en lo que llevo de mi


proyecto el documento de arquitectura es una
manera de plasmar alfo intangible en un
documento altamente organizado, donde cada
punto es clave para que el proyecto quede
claro para cualquier persona que lo lea, no solo
ingenieros.

o El documento de arquitectura su
funcionalidad es organizar cada aspecto que no
es visible en las primeras etapas de desarrollo
o investigació n del proyecto, es decir en los
primeros días cuando se decide el proyecto, lo
que conlleva a futuro como los usuarios
involucrados, los steakholders o cosas má s
técnicas como la visió n, el alcance o lo que se
espera del proyecto son irrelevantes en las
primeras etapas, pero con el documento de
arquitectura se comprime todo esto y se lleva a
un folder donde cada ítem y cada aspecto es
importante para su finalidad

o en mi opinió n el documento de arquitectura


me ayudo a darme cuenta de lo que conlleva
crear un proyecto y cambio mi punto de vista
sobre lo que yo pensaba que era eso, como solo
programar y dejar algo funcional sin que fuera
robusto en su metodología de hacerse.

2. Enumere los pasos que se deben tener presentes para una


adecuada definició n de la arquitectura del sistema en RUP

 Los pasos clave para presentar una adecuada


definició n de la arquitectura rup pueden ser

o Los requerimientos donde se evidencia y se


deja en claro las necesidades del cliente esto es
importante ya que es desde donde se parte
para tener una propuesta de proyecto

o El aná lisis y la implementació n es la etapa


donde el proyecto empieza a tener una forma
base sin ser muy llamativo, pero tiene los
aspectos bá sicos para que funcione, en esta
etapa es donde se hacen las pruebas
pertinentes para evidencias si los
requerimientos funcionales y no funcionales
son coherentes

o La prueba es una etapa donde se someterá al


aplicativo o producto a las distintas pruebas
que existen para medir su rendimiento algunas
de estas pruebas pueden ser:

 Someter al programa o producto a estrés


donde se le asignen demasiadas tareas,
demasiadas ó rdenes a ejecutar

 Las pruebas alfa y beta donde con ayuda


del usuario se testea su funcionalidad,
rendimiento, fiabilidad, y facilidad de
usar el producto o aplicativo

o La evaluació n es donde se hacen repetidas


iteraciones del producto, estas iteraciones
dará n resultados diferentes queda vez que se
ejecuta
Como una expansió n al tema, Las distintas prá cticas de estas
metodologías se basan en conjuntos de principios de desarrollo del
software y se pueden calificar en:

 Desarrollo de software iterativo

 La gestió n de requisitos

 El uso de una arquitectura basada en componentes

 Software de modelado visual

 La verificació n de la calidad del software

 Control de cambios en el software

3. Cuá les son los riesgos asociados de su proyecto en términos de


requerimientos no funcionales

 Orientando cada punto a mi proyecto los


requerimientos no funcionales que tengo son:

o Interfaz

o Estado del pedido

o Compatibilidad

Los riesgos asociados a estos requerimientos no funcionales son los


siguientes

 La interfaz se quiere que pueda ser cambiada por el usuario


es decir que pueda seleccionar un color de tema para su
interfaz, esto puede conllevar a unos errores como bien
pueden ser

 La fuente de la letra y el color de esta, se vean afectados


por el cambie de tema de la interfaz, es decir, que la
letra no se visible para el usuario ya que se camuflaría
con el fondo que seleccione
 Para el estado del pedido los errores que puede traer este
requerimiento no funcional podrían ser los siguientes

 Que al momento del usuario consultar el estado del


pedido, no esté en tiempo real es decir no se vea
segundo a segundo el recorrido de su pedido o la
ubicació n actual del mismo

 La hora de llegada puede cambiar dependiendo de si


hay trá fico o un factor externo que el domiciliario no
puede controlar, esto cambiaria la hora de entrega y no
se podría tener un control preciso sobre su llegada

 El requerimiento de compatibilidad con los distintos sistemas


operativos que hay en el mercado pueden ser

 Los modelos de vista que ven cada usuario dependiendo


del sistema operativo cambiaran o tendrá n errores de
dimensiones dependiendo el sistema operativo, y la
compatibilidad de este se verá influenciado por la
calidad de las líneas de có digo y la plataforma en la que
se desarrolle

4. Explique las siguientes 3 calidades de su proyecto: Rendimiento,


Escalabilidad, Disponibilidad

 Enfocando las calidades de mi proyecto para el


Rendimiento, Escalabilidad y disponibilidad son en
su respectivo orden:

o En el apartado de rendimiento se tiene


conciencia de que el aplicativo lo pueden usar
varias personas al mismo tiempo, y varias
personas pueden ordenar los artículos de su
preferencia en el mismo día, esto conlleva a
que el aplicativo necesite un servidor dedicado
a un alto movimiento de usuarios y
informació n

o En el apartado de escalabilidad el aplicativo


tiene oportunidades de crecer y mejorar
debido al constante cambio y innovació n de las
grandes corporaciones de videojuegos,
haciendo que cada semana o mes, salgan cosas
nuevas y esas cosas nuevas con el tiempo
estará n disponibles para alquilar desde el
aplicativo

o La disponibilidad del pedido dependerá de la


hora de uso tal es así que como en horas de la
madrugada los pedidos que se hagan en ese
horario será n tomados pero repartidos a
primera hora de la mañ ana por seguridad del
cliente y de los domiciliarios.

También podría gustarte