Pontificia Universidad Cat olica de Chile

Escuela de Ingeniera
Departamento de Ciencia de la Computaci on
IIC2143 Ingeniera de Software (I/2013)
Examen
08 de julio de 2013
Parte 1: Verdadero o falso
Indique si cada proposicion es verdadera (V) o falsa (F). Hagalo al lado del n umero de cada proposicion. No es necesario justicar
las falsas. Cada respuesta correcta vale 1 punto. Cada respuesta incorrecta descuenta 0.5 pts.
1. La adopcion de estilos arquitectonicos se vincula a los requerimientos funcionales centrados en el usuario.
2. La ingeniera de software se centra simplemente en aspectos de la gestion de proyectos de desarrollo. Aspectos relacionados
con la calidad del dise no e implementacion del producto corresponden a disciplinas autonomas.
3. Un producto generico podra transformarse en un producto personalizado (con las adecuaciones necesarias), pero no al
reves. Ello, porque en el caso del producto personalizado el equipo desarrollador controla la especicacion.
4. Es posible construir software funcional sin hacer testing alguno durante el desarrollo, asumiendo problemas en la etapa de
aceptacion por parte de clientes.
5. El cambio en las organizaciones clientes debe ser manejado, porque tiene relacion directa con la denicion de arquitecturas,
no as con el dise no detallado o los features implementados.
6. Los requerimientos deben ser gestionados de alguna forma, puesto que tanto clientes como desarrolladores convergen en la
decision de como se producira el software y sus restricciones.
7. Un software evoluciona porque los requerimientos son estaticos, pero los ambientes operacionales cambian.
8. Un artefacto corresponde al resultado de una actividad dentro del desarrollo de software, en una fase de especicaciones y
documentacion. En fases donde se desarrolla c odigo no se generan artefactos.
9. No existe el proceso de desarrollo ideal, debe adaptarse a cada proyecto en particular. Lo que existen son plantillas o
templates de como hacer las cosas, las cuales deben considerar diversas variables en el proyecto.
10. Es posible que existan m ultiples roles en un proceso de desarrollo, asociados a personas distintas; no obstante, una persona
no puede tomar distintos roles a la vez.
11. Un proceso de desarrollo es complejo por la gran cantidad de documentacion que se genera.
12. Un proceso agil se diferencia de uno plan-driven en que en el primero la planicacion es incremental y es posible adaptarse
al cambio.
13. En un modelo de cascada es posible denir la arquitectura del sistema y su codicacion en paralelo.
14. En un modelo incremental es posible que la estructura del sistema se pierda, redundando en altos costos de refactoring.
15. Los test unitarios son elemento fundamental dentro de un plan de pruebas, pues constituyen un elemento dentro de las
pruebas de aceptacion.
16. Los tests de integracion se centran en evaluar a los distintos modulos de forma coordinada.
17. La validacion de un sistema se centra en como se satisfacen los requerimientos no funcionales.
18. El proceso de mantencion de un sofware corresponde a una etapa que ocurre mientras este se encuentra en un ambiente
de desarrollo.
19. Altos costos en la produccion de un software redundaran en altos costos futuros de mantenimiento.
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informaci on en www.reciclauc.cl 1
Parte 2: Selecci on m ultiple
Seleccione la alternativa correcta (es solamente una). Encierre en un crculo la letra que corresponda. Cada respuesta correcta
vale 2 puntos. Cada respuesta incorrecta descuenta 1 punto.
1. Los requerimientos de alto nivel o mas abstractos en un sistema de software corresponde redactarlos:
(a) Colocando al usuario como agente principal de las acciones, ya que debe ser posible realizar la aceptacion del software
haciendo matching contra esta especicacion.
(b) Colocando a los detalles propios del sistema (implementacion, tecnicos, etc.) como agente principal, desde un inicio.
Ello porque permite desarrollar con mayor anticipacion.
(c) Da lo mismo el formato de la redaccion, ya que el usuario no es el aspecto mas relevante en una especicacion.
(d) Ninguna de las anteriores.
2. Un caso de uso permite construir especicaciones de software. El nivel de completitud alcanzado es:
(a) Simplemente a nivel de contexto general: actores, funcionalidades y servicios.
(b) Depende de cuan profundo sea el conocimiento de la modelacion del problema.
(c) Siempre es maximo, porque tiene elementos que permiten una especicacion muy detallada.
(d) Ninguna de las anteriores.
3. En el curso se vio primero la especicacion de software usando requerimientos, para luego pasar a casos de uso. Es posible
hacerlo al reves, partiendo con la denicion de casos de uso, para luego pasar a requerimientos?
(a) S, porque a partir de las especicaciones de los casos de uso es posible concretizar en requerimientos, de acuerdo a
sus propiedades.
(b) No, porque los casos de uso dene el modelo de interaccion entre actores y sistema. Los requerimientos denen
funcionalidades y caractersticas de calidad, las cuales se deben tener claras antes que las interacciones.
(c) S, porque cada caso de uso es una especicacion que en si misma sus elementos son requerimientos. Un ejemplo son
las etapas del ujo basico de eventos, donde aparecen los actores como agentes de interaccion.
(d) Ninguna de las anteriores.
4. Un requerimiento funcional puede transformarse en uno no funcional si:
(a) Dene parametros de calidad sobre la funcionalidad descrita.
(b) Si es atomico y completo respecto a su especicacion.
(c) Si corresponde a un requerimiento de sistema y no de usuario.
(d) Ninguna de las anteriores.
5. Existen metricas para denir requerimientos no funcionales. Estas pueden ser:
I: Facilidad de uso
II: Extension de la documentacion
III: Tipos de usuarios
IV: Fiabilidad esperada
V: Portabilidad
(a) I, III, IV
(b) I, II, IV
(c) I, IV, V
(d) II, III, V
6. Para obtener requerimientos es posible:
(a) Realizar entrevistas
(b) Hacer investigacion etnograca
(c) Construir casos de uso
(d) Todas las anteriores
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informaci on en www.reciclauc.cl 2
7. En un caso de uso, los actores de soporte:
(a) Son usuarios no tan relevantes, como lo son los actores principales.
(b) Proveen soporte a los actores principales, intermediando la interaccion con el sistema.
(c) Estan implementados dentro de la frontera del sistema.
(d) Ninguna de las anteriores.
8. En un caso de uso, los ujos alternativos corresponden a:
(a) Posibles problemas que deben resolverse debido a situaciones emergentes en los actores.
(b) Secuencias de acciones que se siguen ante una cierta desviacion o alternativa dentro del ujo principal.
(c) Todas las anteriores
(d) Ninguna de las anteriores.
9. Se quiere construir las especicaciones de un juego de video rico en interacciones. Una vez denida la historia y el scripting
Que conviene realizar?
(a) Levantar requerimientos de usuario, porque permiten ver primero la atomicidad de las acciones a realizar en el juego.
Las interacciones pueden ser muy complejas, y los casos de uso detallados pueden volverse un overhead, ya que
dependiente de la historia es posible contar con m ultiples ujos alternativos u opciones posibles en un determinado
escenario.
(b) Construir casos de uso detallados, puesto que los juegos de video son aplicaciones ricas en interacciones, cuyo ujo de
acciones es constante. El lenguaje y la estructura del caso de uso es bastante exible.
(c) Levantar requerimientos de sistema, porque los aspectos mas esenciales de un videojuego tienen que ver con las
caractersticas tecnicas mas que las interacciones, por mas que este sea rico en ellas. Lo esencial es proveer un buen
framework de desarrollo.
(d) Es posible que una combinacion que combine un par de las proposiciones anteriores ea verdadera.
10. Es posible construir casos de uso de forma incremental?
(a) S, puesto que la estructura de la especicacion se puede adaptar a la etapa en que se este dentro del proceso de
desarrollo. Algunos campos pueden dejarse por completar, o bien quitar en etapas iniciales. Tambien se pueden
construir modelos mas generales, a nivel de contexto.
(b) No, un caso de uso es completo en s mismo. Lo que se pueden ser construidos de forma incremental son los requer-
imientos, ya que estos son atomicos y posiblemente incompletos.
(c) S, puesto que en general la modelacion considera todo el conocimiento existente hasta cierta etapa dentro del proceso
de desarrollo. Es posible actualizar en particular el contenido de la especicaci n de casos de uso a medida vaya
actualizandose el conocimiento del dominio.
(d) Dos de las proposiciones anteriores pueden ser validas a la vez.
11. Un dise no guiado por dominio se caracteriza por:
(a) Focalizarse en el dominio y la logica que subyace.
(b) Implementar en codigo entidades de dominio antes que otras articiales.
(c) Clientes son los lideran el proyecto, pues son los que conocen el dominio.
(d) Todas las anteriores.
12. La modelacion utilizando UML esta centrada en:
(a) Construir diagramas a partir de especicaciones textuales, como lo son los casos de uso y requerimientos.
(b) Denir distintos tipos de especicaciones de software, de forma visual y formal.
(c) Denir aspectos estaticos de un sistema, como lo son los objetos y sus relaciones.
(d) Construir especicaciones de refactoring, para que un sistema pueda reconstituirse.
13. En UML es posible denir distintos modelos tanto estructurales como otros mas centrados en en el contexto de una lnea
temporal. Cual de los siguientes pares (situacion, modelo) es correcta:
(a) Modelar el comportamiento interno de una maquina expendedora de bebidas ante eventos diagrama de secuencia
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informaci on en www.reciclauc.cl 3
(b) Denir interacciones complejas entre las distintas clases de un sistema de software, basadas en el paso de mensajes
diagrama de maquina de estado.
(c) Claricar los procesos involucrados en el workow de ventas de una empresa, las tareas, el orden de las mismas, junto
con sus inputs y outputs diagrama de clases.
(d) Ninguna de las anteriores.
14. En la denicion de arquitectura para un sistema de software indique la proposicion verdadera:
(a) Una macroarquitectura se interesa por programas individuales, modulos y componentes.
(b) Con una buena arquitectura se logra impacto en el desempe no y mantenimiento de un sistema.
(c) El nivel de concretizacion en un modelo arquitectonico centrado en componentes debe llegar hasta el nivel de clases
de software y sus detalles de implementacion.
(d) Ninguna de las anteriores.
15. Un estilo arquitectonico permite:
(a) Descomponer el sistema en subsistemas mas peque nos.
(b) Denir quienes son los actores y servicios presentes en el sistema.
(c) Controlar el ujo del cambio en las especicaciones del sistema.
(d) Ninguna de las anteriores.
16. Un modelo arquitectonico 4+1 completo:
(a) No considera a los casos de uso, puesto que ellos ayudan a denir especicaciones en una etapa inicial del proyecto.
(b) Considera a los requerimientos funcionales para denir ciertas propiedades intrnsecas del sistema, como performance
y mantenibilidad.
(c) Se centra en elementos mas abstractos, sin detales de implementacion fsica (como hardware).
(d) Ninguna de las anteriores.
17. Al aplicar principios GRASP en el dise no de un sistema de software se debe tener en cuenta:
(a) Que la modelacion de clases sea incompleta, si no, no tiene sentido aplicarlos. Los principios GRASP siempre agregan
clases.
(b) Usar principios GRASP evaluativos como metrica de validacion en la aplicacion de los otros principios.
(c) Conocer previamente patrones GoF, pues ellos denes aspectos fundamentales en el dise no guiado por responsabili-
dades.
(d) Ninguna de las anteriores.
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informaci on en www.reciclauc.cl 4
Parte 3: Relaci on entre elementos
Indique para cada estilo arquitectonico que propiedad o propiedades no funcionales busca maximizar. Hagalo se nalando el
n umero correspondiente. Cada estilo con las propiedades correctamente asignadas tiene 2 puntos. Una propiedad incorrecta
borra una propiedad correcta.
Cliente - Servidor
Repositorio
Tubera - ltro.
Capas.
Indique para cada principio GRASP que propiedad o propiedades no funcionales se ve desfavorecida. Hagalo se nalando el
n umero correspondiente. Cada principio con las propiedades correctamente asignadas tiene 2 puntos. Una propiedad incorrecta
borra una propiedad correcta.
Indirection
Pure Fabrication
Information Expert
Indique para los siguientes patrones GoF con que principio o principios GRASP se relaciona, descartando los principios
evaluativos. Hagalo se nalando el n umero correspondiente. Cada patron con los principios correctamente asignados tiene 2
puntos. Un principio incorrecto borra un principio correcto.
Composite
Command
Chain of Responsability
Decorator
Builder
Abstract factory
Facade
Strategy
Bridge
Mediator
Lista de propiedades no funcionales
1. Performance
2. Availability
3. Security
4. Protection
5. Maintainability
6. Extensibility
7. Scalability
8. Fault tolerance
9. Reliability
10. Portability
Lista de principios GRASP
1. Creator
2. Information Expert
3. Protected variations
4. Pure fabrication
5. Indirection
6. Controller
7. Polymorphism
8. High cohesion
9. Low coupling
Si vas a botar este enunciado, recclalo en los contenedores azules. Mas informaci on en www.reciclauc.cl 5