Está en la página 1de 4

Alumno

Vsquez Tapia Israel

Profesora
Mara Teresa Hernndez E.

Materia
Mtodos y Modelos de Desarrollo de Software

Actividad 1. Modelos de desarrollo de sistemas

Propsito: Analizar un problema y encontrar la solucin apropiada para el diseo del modelo de
desarrollo del sistema, con esta actividad reafirmars tus conocimientos en los modelos de desarrollo
de software.
Instrucciones:
La siguiente actividad se realizar por medio de dos herramientas: un foro y la seccin de tareas, por
lo tanto atiende a las siguientes indicaciones.
1. Ingresa al foro Actividad 1. Modelos de desarrollo de sistemas.
2. Analiza la problemtica con el equipo que te asign tu facilitador(a) y responde a lo que se te
indica. *El/ la facilitador(a) habilitar lneas de discusin para grupos de 3 a 4 personas.
3. Atiende a las instrucciones y comentarios de retroalimentacin por parte de tu facilitador(a).
4. Para comenzar este ejercicio, crea un archivo de texto y copia la descripcin del problema que
analizars, las respuestas las colocars en la descripcin del inciso correspondiente.
5. Recuerda que el ejercicio lo discutirs con tus compaeros y de forma colaborativa buscarn las
respuestas correctas, no obstante, al final los trabajos se enviarn de manera individual. Cabe
sealar que en los trabajos individuales se presentarn las respuestas que consideraron correctas y
en el foro debers de argumentar el porqu de tu respuesta.
Problema:
La administracin de una ruta de camiones de una ciudad, desea iniciar con un proceso para tener,
al final del mismo, un software, donde se desea supervisar los tiempos que toma a cada camin
realizar un recorrido, adems se desea conocer la cantidad de vueltas d cada conductor por da; se
entreg el siguiente reporte en uso:
En el reporte se observa una columna que pertenece a la firma de un supervisor, se explica que en
los recorridos suele existir supervisores que por azar se suben en los camiones en circulacin para
comprobar que todos los pasajeros hayan hecho su pago y tengan su boleto, ellos firman de acuerdo
al nmero de viaje en proceso; otras de sus actividades es proponer mejoras en el servicio.
Los supervisores tambin tienen su propio reporte, que es el siguiente:
Por otro lado, el administrador desea supervisar los mantenimientos que se les aplican a los
camiones, dependiendo de cierta cantidad de kilmetros incrementados. Pues, existe personal de
mantenimiento, pero no hay un reporte estandarizado donde se registre el lugar, fecha y gastos del
mantenimiento, as tambin la persona que lo realiz, pues el mantenimiento se hace segn la
recomendacin del chofer del camin.
Ahora realiza lo que se te pide en cada inciso:
A) Iniciando un proceso de anlisis, iniciaremos con el modelo de requisitos, pensando sobre los
casos de uso responde a las siguientes preguntas.
1.- Enlista los actores que identificas en el problema.
Administrador, Supervisor, Chofer, Pasajero y Mecnico
2.- La accin de llenado del reporte de entradas y salidas del camin, quin lo realiza?
El chofer el supervisor revisa que los pasajeros tengan su boleto pagado
3.- Quin firma la seccin del reporte de entradas y salidas de camiones en la seccin revis?
Administrador
4.- Quin revisa que los viajeros pagaron su pasaje?
Supervisor
5.- Quin realiza el llenado del documento de supervisin de servicio de transporte?:
Supervisor
6.- En cuanto al diseo del modelo de clases, podras decir que puedes aplicar la herencia en la
creacin de las clases chofer, mecnicos, administrador y supervisor Si/No?
Si
7. Por qu?:
Por qu el modelo de clases proporciona una manera sencilla de identificacin, adems existe
informa relacin entre las clases descritas.
B. Del siguiente listado de clases del sistema, responde a las preguntas:

1. Persona
2. Chofer
3. Administrador
4. Supervisor
5. Mecnico
6. Camin
7. Recorridos
8. Supervisiones
9. Registro de mantenimientos
De qu clases llevan sus claves primarias como llaves forneas a las siguientes clases:
1. Clase Recorridos, de:
Chofer, administrador, supervisor, camin
2. Clase Supervisiones de:
Supervisor, camin, chofer, administrador, persona
3. Clase registro de mantenimiento:
Mecnico, administrador, registro de mantenimiento
C. En la creacin de un diccionario de datos de tipo pasivo, se enlistan los datos, su descripcin, tipo
de dato y restricciones del mismo; suponiendo que describirs los datos de la entidad chofer, escribe
5 datos del mismo, que puede ser til para el administrador conocer del chofer y que puede ser til
para cuando se vaya a crear la base de datos del sistema, describe cada uno de ellos
En esta actividad agregue una tabla
Chofer
Nombre
Clave licencia
Edad
Direccin
Telfono

Israel Vsquez
0088
31
calle amapolas mz d lt 17
26-35-80-50

D. En Cuanto al modelo de interfaces. Responde a las preguntas:


1. Una de las opciones no es cierta para justificar el manejo de poca informacin en las interfaces
Cul es?
a. Memoria limitada de las personas a corto plazo.
b. El manejar muchas informaciones crea estrs en el usuario
c. Suponer que todos los tipos de usuario se pueden adaptar a la interfaz
d. Porque las pantallas permiten mostrar poca informacin
En los principios de diseo de interfaz se establece que deben tomarse las capacidades fsicas
mentales de las personas que utilizan el software
1. memoria limitada
2. todos cometemos errores
3. errores del sistema provocan estrs
4. rango de capacidad fsica
5. preferencias de interaccin
Por lo que considero que la d no aplica
2. Es el principio de diseo que indica usar trminos y conceptos obtenidos de la experiencia de las
personas que ms utilizan el sistema:
a. Familiaridad del usuario la interfaz debe utilizar trminos y conceptos obtenidos de la experiencia
de las personas que ms lo utilizan
b. Uniformidad
c. Mnima sorpresa

d. Recuperabilidad
3. Es el principio de diseo que sugiere que siempre que sea posible, la interfaz debe ser ecunime
en el sentido de que las operaciones comparables se activen de la misma forma:
a. Familiaridad del usuario
b. Uniformidad la interfaz debe ser uniforme en el sentido de que las operaciones se activen de la
misma forma
c. Mnima sorpresa
d. Recuperabilidad
4. Es el principio de diseo que indica que el comportamiento del sistema no debe de provocar
sobre saltos de emocin a los usuarios:
a. Familiaridad del usuario
b. Uniformidad
c. Mnima sorpresa el comportamientos del sistema no debe provocar sorpresa a los usuarios
d. Recuperabilidad