Final 2010/02/20
CDGR_NDRMD
Primero que nada queria agradecer a la gente que armo este grupo y
todos los que colaboraron en subir tanto archivos como finales.
El final de hoy, era mas que nada para resolverlo con sentido comun
mas que con la teoria de la materia.
Les paso un pequeño resumen de lo que tomaron hasta q alguien copado
ponga el final completo
Parte Practica
===========
Era casi en su totalidad referido a Casos de Uso. (explico lo q
recuerdo) Se dió un enunciado que hablaba de una boleteria de trenes
de TCBA, el personal de la boleteria se encargaba de vender a los
pasajeros 2 tipos de billetes (boletos de viaje) cada uno de estos 2
tipos de billetes tenia algunas caracteristicas particulares como
- aplicar descuentos si era de un tipo y no aplicar si era del otro
tipo de billetes.
- ofrecer cena y almuerzo gratis si era de un tipo y no si era del
otro tipo de billetes
Ademas el billete se podia comprar para hacer viajes desde Capital Fed-
> Mar del Plata o a culquiera de las 2 ramas : Capital Fed-> Buenos
Aires o Buenos Aires-> Mar del Plata.
El sistema ademas debia permitir al supervisor poder ver un reporte
(creo q de los boletos comprados)
a)Dada una lista de posibles actores de los casos de uso (pasajero,
auditor, presidente de TCBA, supervisor) se debia identificar que
actores eran validos segun el enunciado anterior(unicamente con
Verdadero/Falso sin justificacion)
RTA a) sobre este punto habia q leer el enunciado e identificar los
actores yo puse q el presidente de TCBA y el pasajero no tenian nada q
ver y que el supervisor si
b)Pregunta Teorica: es posible no usar Casos de uso <extend> o
<include> para armar los casos de uso del sistema asociado al
enunciado??
RTA b) yo puse que se deben usar estos tipos de casos de uso ya que
van a permitir factorizar funcionalidad mediante el <include> y
mediante <extend> separar la funcionalidad que se ejecuta unicamente
bajo ciertas condiciones (puntos de extension)
c) Dado la especificacion de uno de los casos de uso (un escenarios de
dicho caso de uso) armado en base al enunciado, se planteaban lista de
precondiciones de los cuales se debia identificar cuales eran validos
segun el enunciado (unicamente con Verdadero/Falso sin justificacion)
RTA c) acá era mas q nada usar sentido comun con las precondiciones,
por ejemplo:
"El usuario debe tener ganas de viajar" -> obviamente es falso, no
tiene nada que las ganas
"Para pagar con Tarjeta de credito, esta debe tener credito" ->
Obviamente es verdadera ya que sino no se le puede cobrar
...etc
Parte Teorica
===========
Todos los puntos de la parte teorica son muy subjetivos ya que no
querian responder preguntas de ningun tipo, referidas al final ..para
mi fue mas q nada experiencia propia y mucha suerte :-S
a) que cosas se pueden hacer en una pagina web (V/F) :
"Se pueden agregar items al carrito" -> v (es lo mas habitual en
paginas web reales)
"Se pueden modificar los productos" -> f (no es habitual en webs
reales)
"Se pueden agregar items al Listado" -> v (si Listado es un reporte y
ni una lista de articulos a comprar, no es habitual agregar items al
Listado)
...etc
b) Relacion entre documentacion y UML
Esto es casi una redundancia ...pero buenh, UML -> Lenguaje para
modelizar todas la etapas del proceso y de esta forma generar la
documentacion de cada actividad.
c) Por que es importante la frase "hay que crear la documentacion del
sistema" (o algo asi)
DTA: es necesario crear la documentacion porque de esta forma queda
asentado cual es el funcionamiento del programa, asi como los
requerimientos que cubre el mismo. Ademas mas adelante en una etapa de
mantenimiento la documentacion del sistema es sumamente util.
d) Relacion entre manual de sistema, manual de usuario y manual
operativo
RTA: todos conforman las guias de usuario que deben ser entregadas
junto al sistema producido
Me saque un 7, asi que imagino que la mayoria de las respuestas estan
ok.
Bueno, espero que les sirva mi aporte y mucha suerte a los que van a
rendir en las fechas proximas!.
Salutes!