Pontificia Universidad Cat olica de Chile

Escuela de Ingeniera
Departamento de Ciencia de la Computaci on
IIC2143 Ingeniera de Software (I/2013)
Interrogacion 1
03 de abril de 2013
La interrogacion dura 100 minutos.
Parte 1: Conceptos (12 puntos)
Esta parte de la interrogaci on puede responderla en este mismo enunciado
Seleccione la alternativa correcta (1 pto. c/u). Cada pregunta de esta seccion respondida de forma incorrecta
descuenta 0.5 ptos.
1. La ingeniera de software conlleva la aparici on de diversas problematicas que busca resolver. Una causa posible
es:
(a) Que las piezas de software son abstractas e intangibles.
(b) El cambio en el contexto donde debe operar la pieza de software (dependiendo del tipo de producto).
(c) Que las piezas de software deben operar en medios homogeneos y conocidos, ya que el hardware es
bastante estable.
(d) Ninguna de las anteriores
2. En clases hemos visto la denicion de un producto personalizado. Un ejemplo posible para este es:
(a) Un sistema operativo, puesto que tiene un gran grado de personalizacion por parte del usuario.
(b) Un sistema de productividad de ocina (planilla de calculo, procesador de texto), puesto que es posible
generar documentos variados.
(c) Un sistema para la administracion de ujos de informacion, que incluye modulos que se adaptan a las
necesidades de los potenciales usuarios.
(d) Ninguna de los anteriores.
3. Los procesos de desarrollo de software consisten en una secuencia de actividades que conducen la elaboracion
de un producto de software. Seg un lo que ha aprendido y su criterio, cu al ser ual el conjunto mnimo de
actividades que debiesen estar en todo proceso de desarrollo:
(a) Especicacion, Validaci on, Evolucion
(b) Especicacion, Desarrollo, Evolucion
(c) Desarrollo, Validaci on, Evolucion
(d) Ninguna de las anteriores
4. Un ejemplo de precondicion que es v alida por si sola en su construccion (sin considerar un contexto que
permita indicar que es v alida) es:
(a) Revisar el estado de la aplicaci on antes de empezar.
(b) Los documentos seran enviados en la fase siguiente.
(c) El usuario est a autenticado en el sistema.
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informacion en www.reciclauc.cl 1
(d) Ninguna de las anteriores.
5. Un proceso de desarrollo de software es complejo. Indique cu al de los siguientes ejemplos es v alido para
justicar esta armaci on:
(a) Muchos involucrados en el proceso introducen ciertos grados de incerteza.
(b) Muchas etapas o tareas en el proceso introducen ciertos grados de incerteza.
(c) Mucha documentaci on que describe a los procesos es engorrosa y difcil de leer, lo que introduce ciertos
grados de incerteza.
(d) Ninguna de las anteriores.
6. El uso de un modelo en cascada por sobre uno interativo e incremental se podra justicar en la construccion
del siguiente software:
(a) Que requiera un nivel de calidad vital, con requerimientos estables (e.g. sistemas en tiempo real de
vehculos aereos, espaciales, sistemas de emergencia).
(b) Sitios web que sirvan de apoyo a la gestion de una empresa y se adapte a las necesidades ad-hoc de un
cliente en particular.
(c) Aplicaciones para dispositivos moviles con requerimientos no funcionales complejos.
(d) Ninguna de las anteriores.
7. El desarrollo iterativo e incremental, en contraste con el desarrollo en cascada, puede considerar:
(a) Actividades que son inexistentes en un proceso en cascada, como lo es el testing.
(b) La entrega de software ya operativo, antes de cubrir todos los requerimientos.
(c) La eliminaci on de aspectos innecesarios en el desarrollo del software, como lo es la denicion de un cierto
nivel de especicaciones.
(d) Ninguna de las anteriores.
8. Indique que conjunto de requerimientos funcionales, escrito desde la perspectiva del usuario, es v alido respecto
a su redacci on:
I: El usuario debe poder acceder al sistema con un grado de uptime del 99.9%
II: Muchas veces el usuario requiere visualizar el formulario.
III: El usuario debe poder seleccionar las opciones de una lista, adem as de visulizar el reporte y enviar un
mensaje, por lo que tambien debe ser capaz de enviar un mensaje de feedback.
(a) I y II
(b) II y III
(c) I y III
(d) Ninguno de los conjuntos es v alido.
9. Una diferencia posible entre los requerimientos funcionales de usuario v/s los de sistema denidos en una fase
inicial de un proyecto de desarrollo de software es:
(a) Los de usuario se escriben de forma concreta, incluyendo aspectos tecnicos, en tanto los de sistema se
escriben desde una perspectiva de alto nivel, centrada en la globalidad de las especicaciones.
(b) Los de usuario se escriben de forma abstracta, al igual que los de sistema, pero considerando detalles de
la interfaz de usuario nal.
(c) Los de usuarios se escriben de forma abstracta, sin incluir aspectos tecnicos, en tanto los de sistema se
hace de forma concreta.
(d) Ninguna de las anteriores.
10. Los requerimientos no funcionales pueden relacionarse con los funcionales?
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informacion en www.reciclauc.cl 2
(a) S, puesto que son requerimientos incompletos y divisibles (i.e. no at omicos), por lo que deben comple-
mentarse con los funcionales.
(b) No, tratan aspectos distintos del sistema, por lo cual son disjuntos. No obstante, entre ambos es pposible
especicar completamente un sistema.
(c) S, puesto que describen ciertos niveles de calidad con los cuales deben ser implementados los requerim-
ientos funcionales.
(d) No, porque los primeros permiten denir la arquitectura, en tanto los segundos el dise no detallado, las
cuales son fases independientes entre s.
11. En la denicion de un caso de uso existe una clasicaci on de actores. Al asignar a los actores en las distintas
categoras de clasicaci on, es posible:
(a) Denir la cantidad de usuarios que trabajan en el sistema
(b) Denir los roles de los usuarios presentes en el sistema
(c) Denir los procesos involucrados en el sistema
(d) Denir las interacciones entre actores.
12. Si Ud. tuviera que relacionar la cardinalidad de actores con casos de uso, la expresi on mas general sera:
(a) N actores, K casos de uso (N > 0)
(b) N actores, K casos de uso (K > 0)
(c) N actores, K casos de uso (N > 1, K > 0)
(d) N actores, K casos de uso (N > 1, K > 1)
Parte 2: Analisis
ENS: English numbers sorting para el reforzamiento de la pronunciacion y entendimiento
1
Este escenario se basa en una experiencia previa en el ambito del aprendizaje del idioma ingles como lengua
extranjera. Esta experiencia consisti o en el dise no e implementaci on de laboratorios de idioma que permitieran
el aprendizaje de pronunciaci on, listening, gram atica y vocabulario, de forma colaborativa. Para ello, grupos de
tres alumnos desarrollan las distintas actividades pedag ogicas compartiendo la misma pantalla, pero disponiendo
cada uno de un audifono y micr ofono individuales. Ello les permite saber que hacen sus compa neros, adem as de
escuchar mensajes del sistema, grabar y compartir la pronunciaci on grabada. Estos laboratorios colaborativos de
idioma demostraron ser mas efectivos en el aprendizaje de las habilidades de pronunciaci on y listening, respecto de
un laboratorio de idiomas individual que busca desarrollar las mismas habilidades.
Este nuevo escenario busca extender las capacidades del escenario inicial de los laboratorios de idioma, per-
mitiendo el trabajo colaborativo mas alla de una pantalla compartida. Ello posibilita que los estudiantes no
necesariamente deban estar cara a cara, pudiendo trabajar en distintos lugares. En este escenario el contenido a
trabajar corresponde a los n umeros en ingles. Para lograr esto, los estudiantes se organizan en grupos de tres,
donde cada uno tiene un dispositivo movil. Inicialmente el sistema asigna un n umero al azar (del 1 al 9) a cada
uno de ellos, el que es desplegado en la pantalla de sus respectivos dispositivos. Cada estudiante debe pronunciar
correctamente en ingles el n umero desplegado. En el caso de que la pronunciaci on sea correcta, se reproduce la
grabaci on al resto de los compa neros del grupo, en caso contrario se repite el proceso (i.e. debe volver a pronunciar
el n umero). En una segunda fase, el sistema despliega en el dispositivo de cada integrante una lista con todos
los n umeros que ha pronunciado el grupo. A partir de esta lista, cada estudiante debe construir una secuencia en
orden creciente, seleccion andolos en la lista desplegada en su dispositivo. Luego, en cada grupo votan por alguna
de las secuencias construidas, pasando la mas votada a la siguiente fase. Finalmente, si el orden en la secuencia es
correcto, los estudiantes deben pronunciar en el orden construido su n umero asignado. La pronunciaci on se valida
de igual forma que en la primera fase.
A partir de este learning scenario emergen requerimientos tecnologicos y ciertos issues o restricciones relacionados
con la naturaleza movil de los dispositivos con los que trabajan los estudiantes:
1
Extraido del draft Design and Implementation of Distributed Collaborative Mobile Learning Activities: Leassons learnt (Calder on-
Maureira JF & Gil de la Iglesia D, 2013)
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informacion en www.reciclauc.cl 3
Se necesita un sistema de speech recognition para la validaci on de la pronunciaci on en ingles, que sea de alta
disponibilidad. El tiempo total del procesamiento del resultado (desde que se recibe el audio grabado, hasta
que se entrega la palabra reconocida), debe ser de a lo mas 3 segundos.
Se debe proveer capacidad de grabaci on y reproduccion de audio para cada estudiante, la cual debe estar
disponible cada vez que se requiera.
Los dispositivos de los estudiantes no tienen necesariamente todos los recursos disponibles que son necesarios
para el desarrollo de la actividad. Por ejemplo: el script de la actividad, consistente en la secuencia de n umeros
que deben ser pronunciados y ordenados debe ser consumido remotamente desde un servidor externo, el motor
de speech-recognition, que no reside en todos los dispositivos y debe ser consumido de forma remota.
Los dispositivos moviles de los estudiantes y/o sus recursos tecnologicos no est an disponibles necesariamente
todo el tiempo. Esto puede deberse a eventos o problemas provocados por una falla tecnica en el dispositivo o
recurso, o bien inaccesibilidad del mismo. Un ejemplo de falla tecnica los micr ofonos y/o audfonos/altavoces
de los respectivos dispositivos no funcionen, con lo cual sea imposible grabar los n umeros pronunciados por
los estudiantes y/o reproducir tales grabaciones. Un ejemplo de inaccesibilidad de recurso tiene que ver con
problemas de conectividad de los respectivos dispositivos, ya sea entre ellos para consumir alg un recurso, bien
con servidores externos que provean ciertas capacidades o servicios. Otra causa es por restricciones propias
de cada recurso, provocando que estos no esten disponibles todo el tiempo. Un ejemplo de ello es el servicio
de speech-recognition, el que puede ser consumido solo por un requester al mismo tiempo.
Un aspecto importante, es que el sistema pueda admitir un mayor n umero de tipos de recursos tecnologicos (no
s olo speech recognition), un mayor n umero de proveedores de recursos (computadores, moviles, servidores, etc.) y
un mayor n umero de dispositivos.
Nota: conteste cada sub-parte en hojas separadas
2 A Requerimientos (10 pts.)
1. 10 pts., 1 pto. c/u A partir de la situacion descrita, redacte 6 requerimientos funcionales y 4 requer-
imientos no funcionales. En el caso de los requerimientos funcionales, es obligatorio redactarlos desde el
punto de vista del usuario (no as en el caso de los no funcionales). Se evaluar a que sean pertinentes a la
situacion descrita, adem as de que su redacci on sea consistente con lo visto en clases respecto a la denicion
de requerimientos.
2 B Casos de uso (9 pts.)
1. 4 pts., 1 pto. c/u A continuacion se presenta una lista de ttulos de casos de uso referentes a la situacion
presentada. Indique si esos ttulos de caso de uso son correctos, bas andose solamente lo que aparece en el
enunciado y l que Ud. ha aprendido en las clases. Para justicar su respuesta puede basarse en los test vistos
en el curso para casos de uso.
Formaci on de grupos.
Contestar pronunciando.
Armar secuencia de n umeros.
Entregar feedback del profesor.
2. 5 pts. Basado en la situacion presentada, construya un caso de uso detallado. Debe considerar solamente
los siguientes campos:
Ttulo (si usa alguno de la parte anterior, este debe ser correcto, o bien corregirlo para que sea correcto).
Actores principales
Actores de soporte o secundarios
Precondiciones
Postcondiciones
Flujo basico de eventos
Flujos alternativos (si aplican)
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informacion en www.reciclauc.cl 4