ENTORNOS DE DESARROLLO – 1º DAW

PRUEBA DE LA 1ª EVALUACIÓN curso 2020/2021

Nombre y Apellidos: Puntuación:

SOLUCIÓN A LA PRUEBA 10

1. (Máx: 3ptos.) Indica si son Verdaderas (‘V’) o Falsas (‘F’) las siguientes afirmaciones (0,1pto.
por cada acierto; -0,1ptos. por cada 2 errores):

RESPUESTA PREGUNTA

En un repositorio de Github sólo el dueño (owner) o quienes éste haya definido como
1 V colaboradores (collaboratos) podrán actualizar un proyecto directamente. El resto de
usuarios deberán solicitar una pull request

El archivo ejecutable es el archivo que tiene todas las instrucciones en código

2 V
máquina que le indican a la CPU la forma en que debe ejecutarse el programa.

Generalmente la labor de describir detalladamente los casos de uso recae en el

3 V
equipo de analistas.

La necesidad básica que todo IDE debe cubrir es la edición y creación de programas
4 V
informáticos, convirtiendo código fuente en código ejecutable.

En un diagrama de clases no hay diferencia entre una relación de composición y otra

de agregación. LA COMPOSICIÓN INDICA UNA RELACIÓN FUERTE ENTRE LAS
5 F
ENTIDADES MIENTRAS QUE LA AGREGACIÓN INDICA UNA RELACIÓN DÉBIL
(AMBAS ENTIDADES EXISTEN SIN LA NECESIDAD DE LA OTRA)

6 F Todas las fases del ciclo de desarrollo de software duran el mismo tiempo.

La operación en Github para descargar la última revisión de un proyecto se denomina

7 F commit. LA OPERACIÓN COMMIT SIRVE PARA REGISTRAR UN CAMBIO DE UNO
O VARIOS FICHEROS DE UN PROYECTO EN UN REPOSITORIO.

La única fase del ciclo de desarrollo del software que no requiere de documentación
8 F es la fase de codificación. TODAS LAS FASES DEL CICLO DE DESARROLLO DEL
SW SE DEBEN DOCUMENTAR ADECUADAMENTE.

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 1 de 8

 Con lenguajes de programación compilados el código ejecutable obtenido es más
9 V
eficiente y rápido y los archivos ejecutables tienden a ser más pesados.

10 F El lenguaje de programación Java es de bajo nivel. ES DE ALTO NIVEL.

11 V En la fase de compilación, el tipo de código que se obtiene es código objeto.

El sistema operativo es el software base que ha de estar instalado y configurado en

el ordenador para que las aplicaciones puedan ejecutarse y funcionar. También facilita
12 V
la interacción entre los componentes físicos y el resto de las aplicaciones, y
proporciona una interfaz con el usuario.

13 F El lenguaje java ni es compilado ni es interpretado. ES AMBOS.

Si 2 casos de uso se relacionan a través de una relación <<includes>> entonces

14 V significa que todos los pasos de uno de ellos se llevarán a cabo siempre en algún
momento de la secuencia de acciones del otro.

De los distintos tipos de mantenimiento de software es más prioritario el

15 V
mantenimiento correctivo.

Un diagrama de casos de uso no puede tener más de 2 actores. EN UN DIAGRAMA

16 F DE CASOS DE USO HABRÁ TANTOS ACTORES COMO ROLES DE USUARIO MÁS
ENTIDADES EXTERNAS QUE INTERACCIONEN CON EL SISTEMA.

La fase del ciclo de desarrollo del software en que se divide el sistema en partes y se
17 V
determina la función de cada una es la fase de diseño.

Es posible crear aplicaciones informáticas sin necesidad de un entorno de desarrollo,

18 V
tan sólo con un editor de texto junto a un compilador.

Siempre debe haber un canal de comunicación directo entre los usuarios finales y el
equipo de analistas. NI SIEMPRE NI DIRECTO. EL EQUIPO DE ANALISTAS HABLA
19 F
CON EL CLIENTE O CON EL SERVICIO DE ATENCIÓN AL CLIENTE, AL CUAL
CONTACTAN LOS USUARIOS.

Con el uso de máquinas virtuales podemos desarrollar y ejecutar una aplicación sobre
cualquier equipo, independientemente de las características concretas de los
20 V
componentes físicos instalados ya que éstos son emulados, garantizando así la
portabilidad de las aplicaciones.

Los lenguajes compilados tienen la característica de garantizar siempre la

independencia de la plataforma sobre la que se ejecutan sus programas. ES JUSTO
21 F
LO OPUESTO: SE REQUIERE DE COMPILADOR PROPIO DE CADA
PLATAFORMA.

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 2 de 8

 Los programadores de Java solo tienen que escribir su aplicación una vez y ese
programa podrá ejecutarse en cualquier plataforma (computadoras de escritorio,
22 V celulares (sin importar si usan Android, iOS o cualquier otro), autos… cafeteras…)
mientras tengan una Máquina Virtual de Java y los recursos del sistema sean
suficientes.

Una de las principales características del lenguaje ensamblador es que está orientado
23 V
a la máquina y, por tanto, tiene mayor adaptación al equipo.

Las relaciones de composición en un diagrama de casos de uso indican que, bajo

24 F ciertas condiciones, un caso de uso se compone de otros. NO HAY RELACIONES DE
COMPOSICIÓN EN LOS DIAGRAMAS DE CASOS DE USO.

El modelo de desarrollo en cascada es el modelo de vida clásico del software, en el

25 V
que se requiere finalizar una etapa para realizar la siguiente.

En el diagrama de casos de uso de un sistema informático siempre debe aparecer el

26 F
propio sistema como el actor principal del diagrama.

27 F Una superclase no puede tener más de una subclase. Sí PUEDE.

A lo largo de la breve historia del mundo de los lenguajes de programación ha habido

28 V diferentes generaciones de lenguajes, desde la 1ª en lenguaje máquina (basado en
binario) hasta la 5ª generación de lenguajes orientados a la Inteligencia Artificial.

La descripción de un caso de uso debe incluir todos los escenarios posibles, es decir,
29 V debe detallar todas las diferentes alternativas que pueden darse, así como las
excepciones que pudieran producirse y su adecuado manejo.

El sistema GIT es una tecnología para el control de versiones de archivos, a través

30 V del cual se almacenan metadatos sobre las distintas actualizaciones (modificaciones,
borrados, autorías, etc.) de los ficheros y carpetas que se monitorizan.

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 3 de 8

 2. (Máx: 3ptos.) Realice el Diagrama de Casos de Uso para la descripción, identificando
adecuadamente cada componente del diagrama y las relaciones que se establezcan entre
los mismos. Acompañe el diagrama con una explicación breve y concisa, pero suficiente,
sobre cada componente.

Descripción de los actores:

USUARIO: se corresponde con los usuarios finales de los equipos y programas cuyo
mantenimiento se está llevando a cabo. Registran las nuevas incidencias sobre los programas y
equipos que manejan, pueden ver el progreso de resolución de las mismas y mantienen contacto
sólo con el personal de nivel 0 (del centro de atención al usuario). Son quienes aceptan o
rechazan la resolución de sus incidencias en última instancia.

NIVEL 0: se corresponde con las personas del centro de atención al usuario. Cuando un usuario
registra una incidencia sobre algún equipo o programa, un nivel0 recoge la incidencia, la examina
y clasifica, (pudiendo contactar con el usuario que la registró para mayor detalle) y si lo estima
necesario ‘eleva’ la incidencia a los técnicos para que se proceda a su resolución.

TÉCNICO: se corresponde con los técnicos informáticos del equipo, quienes proceden con la
resolución de las incidencias que se reciben desde el centro de atención al usuario, es decir,
revisan las incidencias. En ocasiones estos técnicos necesitan contactar con el nivel0 para
conocer más detalles sobre las incidencias que revisan, quienes, a su vez, han de contactar con
los usuarios que registraron tales incidencias. Se dividen en 2 grupos:

TÉCNICO SW: se encargan de las incidencias clasificadas como “de software”, es decir,
las relativas sólo a programas o componentes de software.

TÉCNICO HW: se encargan de las incidencias clasificadas como “de hardware”, es decir,
las relativas sólo a equipos y periféricos o componentes de hardware.

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 4 de 8

 Descripción breve de los casos de uso:

CU1: NUEVA INCIDENCIA: Un usuario registra una nueva incidencia en el sistema, describiendo
su problema. Se genera una nueva instancia de Incidencia, con un identificador único y
acompañada de la descripción aportada por el usuario. La incidencia queda en estado
Introducida, con los campos revisada y aceptada a valor FALSE y con fecha de creación la fecha
actual. La prioridad se establece al valor por defecto 5.

CU2: CLASIFICAR INCIDENCIA: Una persona de nivel0 recoge los datos de una nueva
incidencia, la revisa y clasifica (estableciendo el estado de la incidencia a Clasificada), pudiendo
incluso llegar a contactar con el usuario que la registró para conocer más detalles. En definitiva,
gestiona las nuevas incidencias y decide si se ‘elevan’ al nivel 1 (de técnicos) para que sean
revisadas o si se procede con su cierre (aceptación/rechazo de resolución). También establece
la prioridad final para la incidencia en función de la urgencia de ésta.

CU3: CONTACTAR: Tiene que ver con el mecanismo de comunicación entre los actores del
sistema, en el que tanto los usuarios, como los técnicos, como el personal de nivel0 intercambian
información referente a las incidencias y sobre su proceso de resolución y de cierre. Destacar
que los técnicos nunca contactan con los usuarios directamente, sino que es obligatorio que la
persona de nivel0 que gestiona la incidencia sea el interlocutor intermediario entre ellos. Los
Contactos se registran en el sistema con un identificador único, una descripción y el modo en
que se estableció el contacto (‘T’ para teléfono, ‘E’ para email y ‘R’ para reunión) y una fecha y
hora. La mayoría de las veces se incluye en el informe propio de la incidencia cada contacto
establecido entre los involucrados, pero no siempre.

CU4: VER INCIDENCIAS: Cada usuario final puede realizar un seguimiento de las incidencias
que ha registrado en el sistema, pudiendo ver todos los detalles de estas. También el resto de
personas involucradas podrán visualizar los datos de las incidencias que gestionan (para el caso
de nivel0) o que revisan (para el caso de los técnicos).

CU5: REVISAR INCIDENCIA: Cuando se eleva una incidencia al nivel 1, un técnico del tipo
adecuado (software o hardware, en función de la clasificación de la incidencia) toma la resolución
de ésta y se cambia de estado a Desarrollo. Podrá haber necesidad de algún contacto durante
el tiempo que tome la resolución y se priorizan algunas incidencias más urgentes. En todo
momento los técnicos pueden ver todos los detalles de sus incidencias. Cuando el técnico
termina, se modifica el valor de la incidencia poniendo el campo revisada igual TRUE y pasa al
estado Revisada. Esto es notificado a la persona de nivel0 que gestiona la incidencia para
proceder con el cierre.

CU6: ACEPTAR/RECHAZAR RESOLUCIÓN: Cuando una incidencia ha sido revisada se

comienza con el proceso de cierre. La persona de nivel0 pone el estado de la incidencia a la
espera por la Aceptación del usuario. El usuario que registró la incidencia es notificado entonces
y procede a verificar si se resolvió favorablemente su problema. En caso afirmativo establece el
campo aceptada de la incidencia a TRUE y la incidencia queda en el estado Resuelta. Pero si el
usuario determina que no se resolvió su incidencia, contactará de nuevo con el centro de atención
al usuario para que se revise de nuevo. En el proceso de cierre se registran todos los contactos
que se establezcan, dado que es fundamental que se incluyan en el informe propio de la
incidencia.

CU7: GESTIÓN de EQUIPOS y PROGRAMAS: Corresponde con la gestión propia de los datos
acerca de los equipos y de los programas que entran en el lote del que se está realizando el
mantenimiento. Los técnicos llevan la cuenta de qué aplicaciones y elementos software

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 5 de 8

 (Programas) y de qué equipos y otros elementos hardware (Equipos) se mantienen, insertando
nuevos datos, modificando los existentes, etc.

CU8: ACTUALIZAR INFORME: Cada incidencia tiene asociado un Informe propio. En él se

recoge no sólo un resumen del proceso de resolución y de cierre de la misma, sino que también
está compuesto por la mayoría de las comunicaciones (Contactos) que se han establecido entre
las personas implicadas en la incidencia, tanto el usuario que la registró, como la persona del
centro de atención al cliente que la gestionó y el técnico asignado a su resolución.

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 6 de 8

 3. (Máx: 4ptos.) Realizar el diagrama de clases UML para la descripción, donde se utilizan para nombre de clases las palabras que aparecen
en negrita. Las palabras que aparecen en cursiva proporcionan pistas para la definición de los otros elementos del modelo. Identificar
los atributos y sus tipos de dato. Identificar también el tipo y nombrar con un nombre representativo a cada relación entre las clases del
diagrama, junto con sus cardinalidades mínima y máxima, y la multiplicidad resultante.

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 7 de 8

 Descripción del sistema a modelar: “Gestión de incidencias”
El sistema informático permitirá la gestión de incidencias de los elementos incluidos en el mantenimiento, es
decir, sirve para gestionar el mantenimiento correctivo de programas y de equipos.

Todo comienza cuando un usuario (del cual se guarda un identificador, su nombre, email, dni y teléfono) tiene
un problema y registra una nueva incidencia describiendo lo ocurrido. El sistema asigna un identificador único
a la incidencia, registra la fecha y hora de creación y el usuario que la registró. También se establecen los
valores por defecto para la prioridad (valor 5) y para el estado (Introducida).

Desde el centro de atención al usuario, en adelante nivel 0, se recogen y se gestionan todas las incidencias.
Cada persona de este nivel tiene su propio identificador, y se almacena su nombre y dni, y su forma de contacto
mediante email y teléfono. Cada nivel 0 gestiona varias incidencias pero cada incidencia sólo es gestionada
por una persona de nivel 0 y, si fuera necesaria una revisión de la incidencia, será manejada por el mismo
técnico todo el tiempo. En el nivel0 se clasifica de qué tipo es una incidencia: si el problema viene de un equipo
o elemento hardware, es una incidenciaHW. Si viene desde un programa o elemento software, es una
incidenciaSW. Además del identificador propio de cada incidencia, se quiere registrar un identificador propio
de cada una de las incidencias de uno y otro tipo. Independientemente del tipo, a todas las incidencias se les
establece un valor definitivo para la prioridad en función de la urgencia y pasan al estado Clasificada.

El sistema informático dispone de un mecanismo de notificaciones y de comunicaciones entre las distintas

personas involucradas entorno a las incidencias. Se registran los contactos establecidos entre los actores,
registrando su identificador de contacto, una descripción de lo que se dijo, la fecha y hora en que se produjo,
y el modo de contacto que es ‘T’ para una conversación telefónica, ‘E’ para contacto por email o ‘R’ si fue una
reunión. Cada incidencia del sistema puede ser seguida por cualquier actor involucrado en ella, así que todos
los perfiles pueden ver todos los datos de sus incidencias en todo momento. Eso incluye también el informe
que va asociado a cada incidencia, del que se guarda su identificador y un campo resumen. Este informe,
además, incluye la mayoría de las comunicaciones (es decir, de los contactos) referidas a la incidencia, pero
no todos. Al menos se compondrá de uno, el referido al cierre de la incidencia. Es importante destacar que los
usuarios que registran las incidencias nunca pueden comunicarse directamente con los técnicos que las
revisan, sino que debe ser alguien de nivel 0 quien gestione la intercomunicación entre ellos, actuando como
interlocutor intermediario.

Una incidencia, de acuerdo al criterio de la persona de nivel 0 que la gestione, puede ser ‘elevada al nivel 1’.
Esto significa que se asigna un técnico para su revisión. Se tienen los técnicosHW, quienes revisan
únicamente incidenciasHW, y los técnicosSW, quienes revisan sólo incidenciasSW. Cada persona de ambos
grupos tiene su propio identificador, se guarda su nombre, su dni, su email, su teléfono y otro campo para
marcar en qué es experto cada técnico. Recordemos que las incidenciasHW se asocian a equipos (de los que
se guarda un identificador, su sistema operativo y las capacidades de RAM y de disco duro) y que las
incidenciasSW se asocian a programas (de los que se tiene su identificador, nombre del programa, versión
(con 1 decimal) y tamaño). Los técnicosHW gestionan (es decir, actualizan, registran, eliminan…) los datos
sobre los equipos y los técnicosSW los de los programas.

Cuando un técnico termina de revisar la incidencia (o cuando no se elevó a nivel 1), se procede al cierre de
ésta, y se establece el campo revisada a TRUE. El usuario que la registró debe aceptar la correcta resolución
o rechazarla. En el primer caso la incidencia queda cerrada, mientras que en el segundo caso será necesaria
una nueva revisión. Toda incidencia debe tener, al menos, una comunicación favorable por parte del usuario
en forma de “contacto” para que se pase al estado final (resuelta), marcando un campo aceptada a TRUE. En
ese momento termina el ciclo de vida de la incidencia.

Prueba de la 1ª Evaluación Entornos de Desarrollo (1º DAMDAW) curso 2020/2021 Página 8 de 8