• Author / Uploaded
• AndrésTeston

Citation preview

´ lica de Chile Pontificia Universidad Cato ´ Escuela de Ingenierıa ´n Departamento de Ciencia de la Computacio

IIC2143 – Ingenier´ıa de Software (I/2013)

Interrogaci´ on 1 03 de abril de 2013

La interrogaci´on 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 secci´on respondida de forma incorrecta descuenta 0.5 ptos. 1. La ingenier´ıa de software conlleva la aparici´ on de diversas problem´aticas 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 definici´on de un producto personalizado. Un ejemplo posible para este es: (a) Un sistema operativo, puesto que tiene un gran grado de personalizaci´on por parte del usuario. (b) Un sistema de productividad de oficina (planilla de calculo, procesador de texto), puesto que es posible generar documentos variados. (c) Un sistema para la administraci´on de flujos de informaci´on, que incluye m´odulos 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 elaboraci´on de un producto de software. Seg´ un lo que ha aprendido y su criterio, cu´ al ser´ ual el conjunto m´ınimo de actividades que debiesen estar en todo proceso de desarrollo: (a) Especificaci´ on, Validaci´ on, Evoluci´on (b) Especificaci´ on, Desarrollo, Evoluci´on (c) Desarrollo, Validaci´ on, Evoluci´on (d) Ninguna de las anteriores 4. Un ejemplo de precondici´on que es v´ alida por si sola en su construcci´on (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 ser´an enviados en la fase siguiente. (c) El usuario est´ a autenticado en el sistema. Si vas a botar este enunciado, rec´ıclalo en los contenedores azules. M´ as informaci´ on 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 justificar esta afirmaci´ 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 dif´ıcil 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 podr´ıa justificar en la construcci´on del siguiente software: (a) Que requiera un nivel de calidad “vital”, con requerimientos estables (e.g. sistemas en tiempo real de veh´ıculos a´ereos, espaciales, sistemas de emergencia). (b) Sitios web que sirvan de apoyo a la gesti´on de una empresa y se adapte a las necesidades ad-hoc de un cliente en particular. (c) Aplicaciones para dispositivos m´oviles 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 definici´on de un cierto nivel de especificaciones. (d) Ninguna de las anteriores. 8. Indique qu´e 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 tambi´en 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 definidos en una fase inicial de un proyecto de desarrollo de software es: (a) Los de usuario se escriben de forma concreta, incluyendo aspectos t´ecnicos, en tanto los de sistema se escriben desde una perspectiva de alto nivel, centrada en la globalidad de las especificaciones. (b) Los de usuario se escriben de forma abstracta, al igual que los de sistema, pero considerando detalles de la interfaz de usuario final. (c) Los de usuarios se escriben de forma abstracta, sin incluir aspectos t´ecnicos, 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, rec´ıclalo en los contenedores azules. M´ as informaci´ on en www.reciclauc.cl

2

(a) S´ı, puesto que son requerimientos incompletos y divisibles (i.e. no at´ omicos), por lo que deben complementarse con los funcionales. (b) No, tratan aspectos distintos del sistema, por lo cual son disjuntos. No obstante, entre ambos es pposible especificar completamente un sistema. (c) S´ı, puesto que describen ciertos niveles de calidad con los cuales deben ser implementados los requerimientos funcionales. (d) No, porque los primeros permiten definir la arquitectura, en tanto los segundos el dise˜ no detallado, las cuales son fases independientes entre s´ı. 11. En la definici´on de un caso de uso existe una clasificaci´ on de actores. Al asignar a los actores en las distintas categor´ıas de clasificaci´ on, es posible: (a) Definir la cantidad de usuarios que trabajan en el sistema (b) Definir los roles de los usuarios presentes en el sistema (c) Definir los procesos involucrados en el sistema (d) Definir las interacciones entre actores. 12. Si Ud. tuviera que relacionar la cardinalidad de actores con casos de uso, la expresi´ on m´as general ser´ıa: (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: An´ alisis ENS: English numbers sorting para el reforzamiento de la pronunciaci´ on y entendimiento1 Este escenario se basa en una experiencia previa en el ´ambito del aprendizaje del idioma ingl´es 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 m´as 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, permitiendo el trabajo colaborativo m´as all´a 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 ingl´es. Para lograr ´esto, los estudiantes se organizan en grupos de tres, donde cada uno tiene un dispositivo m´ovil. 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 ingl´es 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 m´as 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 tecnol´ogicos y ciertos issues o restricciones relacionados con la naturaleza m´ovil 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´ onMaureira JF & Gil de la Iglesia D, 2013)

Si vas a botar este enunciado, rec´ıclalo en los contenedores azules. M´ as informaci´ on en www.reciclauc.cl

3

• Se necesita un sistema de speech recognition para la validaci´ on de la pronunciaci´ on en ingl´es, 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 m´as 3 segundos. • Se debe proveer capacidad de grabaci´ on y reproducci´on 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 m´oviles de los estudiantes y/o sus recursos tecnol´ogicos no est´ an disponibles necesariamente todo el tiempo. Esto puede deberse a eventos o problemas provocados por una falla t´ecnica en el dispositivo o recurso, o bien inaccesibilidad del mismo. Un ejemplo de falla t´ecnica los micr´ ofonos y/o aud´ıfonos/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 est´en 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 tecnol´ogicos (no s´ olo speech recognition), un mayor n´ umero de proveedores de recursos (computadores, m´oviles, 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 situaci´on descrita, redacte 6 requerimientos funcionales y 4 requerimientos 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 situaci´on descrita, adem´ as de que su redacci´ on sea consistente con lo visto en clases respecto a la definici´on de requerimientos.

2 B Casos de uso (9 pts.) 1. 4 pts., 1 pto. c/u → A continuaci´on se presenta una lista de t´ıtulos de casos de uso referentes a la situaci´on presentada. Indique si esos t´ıtulos 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 justificar 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 situaci´on presentada, construya un caso de uso detallado. Debe considerar solamente los siguientes campos: • T´ıtulo (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 b´asico de eventos • Flujos alternativos (si aplican)

Si vas a botar este enunciado, rec´ıclalo en los contenedores azules. M´ as informaci´ on en www.reciclauc.cl

4