Preguntas de examen - Ingeniería del Software

TEMA 1 - Introducción a la Ingeniería del Software
1. ¿Cuáles son las principales diferencias entre el hardware y el software?***
El hardware es la parte más física y externa de un dispositivo mientras que el software es todo lo
que ese dispositivo lleva en su interior (programas, código, aplicaciones…)
El software es desarrollado, mientras que el hardware es fabricado. El hw comienza a fallar después
de cierto tiempo, debido a los efectos acumulativos del entorno, pero el software no se ve afectado
por este factor. El software es personalizado y se desarrolla la mayoría de las veces desde cero,
mientras que en el caso del hw se pueden utilizar piezas construidas con anterioridad Por último, los
sistemas softwares están constantemente cambiando, y los productos hw son directamente
reemplazados.
El hardware es el conjunto de componentes físicos de los que está hecho un equipo, mientras que el
software es el conjunto de programas o aplicaciones, instrucciones y reglas informáticas que hacen
posible el funcionamiento de este equipo.
2. ¿Qué es la Ingeniería del Software?
La ingeniería de software es una disciplina formada por un conjunto de métodos, herramientas y
técnicas que se utilizan en el desarrollo de programas informáticos, más conocidos como softwares
La ingeniería del software es una disciplina que estudia la creación de un software confiable y de
calidad, basándose en métodos y técnicas de ingeniería y brindando soporte operacional y de
mantenimiento.
3. ¿Qué ventajas aporta la Ingeniería del Software a la Ingeniería de Salud?
La ingeniería de software ha sido la cuna de disciplinas como la biotecnología y la bioinformática,
permitiendo a las ciencias clásicas como las matemáticas y la medicina avanzar a grandes pasos.
4. ¿Cuáles son los principales motivos de los errores en el desarrollo del software?
El software está constantemente sujeto a cambios, los cuales pueden introducir errores. Cuando
intentamos solucionar un problema en nuestro sistema, modificar o añadir funcionalidades,
podemos introducir más errores.
5. ¿Dónde y por qué se acuñó el término "crisis del software"?
En el año 1965, se produjo una entrega del sistema operativo S/360 en el que estaban implicados
1000 programadores, pero a la hora de probarlo se dieron cuenta de que la calidad y el rendimiento
estaban por debajo de los estándares establecidos, de que se estaban saltando algunas pruebas más
rigurosas se estaban entregando las nuevas máquinas sin el software crucial, además los clientes se
veían obligados a utilizar programas temporales más rudimentarios que los prometidos. A partir de
ahí el coste en hardware fue decreciendo y poco a poco fue aumentando el precio del software.
Grupo D→ Tras todos los problemas que tenía el desarrollo de software en los años 60,
precisamente en 1968 un grupo de ingenieros de computadores, managers de corporaciones e
incluso algunos oficiales militares se reunieron en Garmisch, Alemania para la primera conferencia
NATO de ingenieria de Software, en que trataron diferentes soluciones para el problema llamado
desde aquel entonces “crisis del software”.
Página 1
6.
¿Qué propone la Ingeniería del Software para resolver los problemas del desarrollo del
software?
A la hora de desarrollar un sistema software, se propone planificar los pasos para intentar minimizar
el número de cambios, de forma que si se tiene que hacer algún cambio o arreglo, este sea lo más
temprano posible para no entorpecer el posterior desarrollo y la aparición de múltiples errores tras
cada modificación.
Conforme se desarrolla el software, enmendar un error se vuelve más caro a nivel de programación,
ya que un cambio compromete cada vez un sistema más grande.
Lo que propone la ingeniería del Software es un enfoque organizado, sistemático y cuantificable de
forma que se resuelvan los problemas de los clientes. Por lo tanto, la ingeniería del Software
comienza en la primera reunión con el cliente para determinar lo que necesita y continúa aun
después de la entrega del resultado final, puesto que el software desarrollado necesitará
mantenimiento para adecuarse a los nuevos requerimientos.
7. ¿Qué problemas ha resuelto la Ingeniería del Software?
Los presupuestos y calendarios ya no se sobrepasan tras la Ingeniería del Software ya que el
desarrollo del Software se fue encareciendo y las entregas llevaban retraso.
Las características del software no se ajustaban a los deseos de los usuarios. Faltaba alguna
funcionalidad o los resultados no eran los esperados.
El software era muy difícil de mantener o modificar. El software entregado era tan complejo y mal
estructurado que los cambios eran difíciles de aplicar y suponían un alto riesgo de introducir nuevos
errores o hacer que otras funcionalidades dejarán de funcionar correctamente.
La ingeniería de software propone diseñar los programas más organizados, creando subrutinas en
vez de saltar de una parte a otra del código. Por lo tanto, no tenemos los tan conocidos códigos
espagueti.
También la ingeniería del software propone definir el problema inicial determinando la viabilidad
del proyecto, determinando los posibles riesgos a lo largo del proyecto y proponiendo planes de
acción para cada riesgo.
Por último, la ingeniería del Software tiene la vista a largo plazo, es decir, en los proyectos tenemos
en cuenta el mantenimiento del programa después de su entrega al cliente.
8.
¿Cuáles son las principales actividades incluidas en la Ingeniería del Software?
Página 2
Las principales actividades son :
•
La definición de las condiciones iniciales del proyecto tales como la viabilidad, los
requisitos técnicos y como se va a planificar todo
•
La construcción del software, que consta de un análisis previo de todas las características
requeridas por el cliente, el diseño, cómo va a ser implementado y finalmente comprobar la
calidad del producto mediantes pruebas y las valoraciones del cliente al respecto
•
El mantenimiento de un producto tras la finalización de su desarrollo ya que puede que esté
todavía en una fase alfa-beta y necesita un seguimiento hasta la formalización
•
Las principales actividades incluidas en la ingeniería del software son:
•
La definición: se establecen los objetivos esperados para el sistema, debemos saber qué
quiere el cliente y qué funciones debe tener el sistema para satisfacer sus necesidades. En
esta fase se incluye un estudio de viabilidad, requisitos y planificación.
•
La construcción: una vez que tenemos claro qué requisitos deben estar incluidos, pensamos
en cómo implementar una solución. Este proceso se divide en varias capas, en cada una se
hace una descripción más precisa que en la anterior, hasta llegar a la implementación final,
añadiendo detalles e incorporando tecnologías. Esta fase suele incluir el análisis, diseño,
implementación y calidad.
•
El mantenimiento: una vez desarrollado el software, testeado y validado, debemos
desplegarlo. Es decir, se pone en funcionamiento en su entorno final, donde es usado por los
usuarios reales. Debemos asegurarnos de que funcione bien, realizando un mantenimiento y
actualización.
9.
¿Ha resuelto la Ingeniería del Software todos los problemas del desarrollo del
software?¿Por qué?***
No, los sistemas están aún sujetos a muchos errores y casos no contemplados, para prevenirlos y
enmendarlos se han empleado técnicas de planificación y métodos de refactorización distintos.
10. ¿Qué es un atributo de calidad del software?Describe tres ejemplos.
Los atributos de calidad son una serie de propiedades que el proyecto software debe requerir para
verificar que se trata de un software de buena calidad. Tres ejemplos de estos atributos pueden ser la
eficiencia, la portabilidad del producto y cómo de fiable es.
Los atributos de calidad del software son propiedades medibles de un sistema que indican cómo de
bien se satisfacen las necesidades de los clientes. Algunos ejemplos de estos atributos serían la
disponibilidad, rendimiento y modificabilidad.
11. ¿Qué atributos de calidad del software son más importantes para los desarrolladores y
cuáles para los clientes y por qué?
•
Para los desarrolladores los atributos de calidad más importantes son:
La eficiencia, para emplear solo los recursos necesarios.
◦
El mantenimiento, ya que si estas personas son las que van a tener que responder
◦
ante un problema, qué menos que sea fácil y rápido de solventar
La reutilización, es importante que sea capaz de reutilizarse el producto sin
◦
deteriorarse
•
Para los usuarios los atributos de calidad clave son:
Página 3
◦
◦
◦
•
La usabilidad porque para ellos que sea fácil de usar es lo primordial la mayoría de
veces
La fiabilidad, que sea un producto el cual no comprometa la privacidad o
información de los usuarios
La eficacia porque el usuario prima que funcione tal y como espera que funcione
Para los desarrolladores son la portabilidad y que sea un producto fácil de mantener y
modificar (si el cliente quiere cambiar algo en un momento dado, que realizar este cambio
resulte fácil y que no entorpezca al resto del proyecto). Para los usuarios son la usabilidad
(que sea fácil de usar y de entender) y que no falle.
12. ¿Qué es un "stakeholder"? ¿Por qué son importantes?
Toda persona que se ve afectada por el producto software que vamos a desarrollar, desde la empresa
o cliente que nos contrata hasta los usuarios finales.
Los stakeholders son las personas y organizaciones que presentan algún tipo de relación con la
empresa o proyecto, de manera que influyen en él y cualquier decisión les afecta (directa o
indirectamente). A parte de los accionistas e inversores, serían también los trabajadores, socios,
competidores, proveedores y clientes. Son importantes porque son quienes garantizan estar
satisfechos con lo que se está desarrollando y si se están cumpliendo las necesidades. Involucrarlos
es muy importante para así evitar perjuicios a la empresa (económicos o de comunicación).
13. ¿Cuáles son los principales "stakeholders"?
•
Usuarios. Los usuarios son las personas que trabajarán directamente con el sistema en
funcionamiento cuando sea desplegado. Quieren que la funcionalidad del sistema se adapte
a sus necesidades, que el sistema sea fácil de usar y que aporte valor a su trabajo.
•
Clientes. Los clientes son las personas u organizaciones que han pedido que se desarrolle el
sistema. Se centran en los objetivos empresariales que debe cubrir el sistema. También son
conscientes de que el proyecto debe ajustarse al calendario y al presupuesto.
Página 4
•
Desarrolladores de software. El personal técnico que construye el sistema. Están interesados
en obtener los requisitos correctos para el sistema y construir un sistema que los cumpla.
Ellos son los expertos en los detalles técnicos del desarrollo.
•
Directores de desarrollo. Son las personas que dirigen la organización que está desarrollando
el software. Sus principales objetivos son satisfacer a los clientes y reducir los costes de la
organización.
14. ¿Un desarrollador en un proyecto, se considera un stakeholder del mismo?¿Por qué?
Sí, se puede considerar un stakeholder ya que se trata de un integrante del conjunto con cierto
interés en el proyecto y tiene asociada una función dentro del mismo.
Página 5
TEMA 2 - Procesos software
Este documento contiene 56 preguntas sobre el tema de procesos software
1. Describe un ejemplo de proyecto en el que consideras que el modelo en espiral sería
recomendable usarlo
Un ejemplo podría ser un software que se encargue de monitorizar a una empresa de taxis, donde
nos piden que se recoja información de los conductores, rutas que hacen, clientes que recojan…
Como es un proyecto a largo plazo que conlleva un gran tiempo y coste, nos conviene usar un
modelo en espiral, ya que es un modelo evolutivo que para cada iteración se irá asumiendo más
complejidad, por lo que lo iremos desarrollando progresivamente y reduciendo y corrigiendo los
errores en cada iteración.
2.
¿Cuál es la principal aportación del modelo en cascada frente a un proceso sin
modelo?¿Puedes dar un ejemplo de proyecto en el que se pudiera usar?***
Que aporta control y planificación a la hora de desarrollar el proyecto. El modelo en cascada se
suele usar para software con una baja complejidad, por lo que un ejemplo sería para un
software que se encargue de ver si un alumno ha suspendido o aprobado.
La principal aportación del modelo en cascada es que al tener una estructura muy clara y
precisa, permite establecer de manera eficaz y desde el principio el papel de cada integrante
en cada fase del proyecto.
3.
¿Cuáles son las actividades fundamentales del proceso en cascada?
Las actividades fundamentales son las actividades fundamentales del desarrollo, que son integración
y prueba del sistema.
Las actividades fundamentales son:
•
Determinar los requisitos del sistema
•
Definir los requisitos del software
•
Análisis del problema
•
Diseño del programa
•
Desarrollo de código
•
Comprobar el código mediante pruebas
•
Implantación del código
4.
¿Cuáles son las ventajas de documentar el diseño según el método en cascada?
Esto facilitará a personas que no han trabajado directamente en el desarrollo su comprensión,
mejorando así la comunicación entre el equipo de desarrollo y el cliente. También ayudará a una
futura reimplementación o arreglo de errores.
Página 6
5. ¿Cuál es el sentido en el método en cascada de hacer el proceso dos veces?
Es recomendable hacer el proceso una primera vez de forma rápida para testear y una segunda vez
que tome más tiempo. En caso de que encontremos fallos en la primera vez que lo hacemos,
podemos solucionarlos en la segunda.
6.
¿Qué actividades se proponen en el modelo en cascada para involucrar mejor al
cliente?
Documentando el proceso involucramos al cliente desde el principio y lo mantenemos siempre al
tanto. El cliente debe revisar y aprobar los resultados del software resultante del diseño previo y
revisar el software final para su aceptación.
7. ¿Para qué tipos de sistema es apropiado el modelo en cascada?
Para problemas con poca complejidad y baja tasa de innovación.
Para aquellos en los que el objetivo está muy bien definido o cuando los proyectos son de poca
envergadura.
8. ¿En qué proyectos se desaconseja el modelo en cascada? ¿Por qué?
En proyectos complejos o inventivos, ya que el ciclo de vida del modelo cascada empuja muchos
elementos difíciles y de alto riesgo hacia el final del proyecto.
9. ¿Por qué es difícil integrar los cambios en el modelo en cascada?
En este modelo los requisitos iniciales no deben cambiarse a lo largo del proyecto. Sin embargo, es
muy común, especialmente para el nuevo software, que los requisitos sufran muchas modificaciones
durante el desarrollo. Es por eso que, si cambian los requisitos en el medio del desarrollo, no
podremos integrar los cambios fácilmente.
10. ¿Por qué en el modelo en cascada se atacan los mayores riesgos al final?
En el modelo en cascada, la fase de prueba (testeo) no tiene lugar hasta casi el final y tras la fase de
implementación. Es por ello, que los riesgos (sobre todo los más grandes) no se ven hasta ese
momento. Un error de código o en los requisitos iniciales implicaría volver a las fases iniciales de
requisitos o de diseño del programa del proyecto (lo cual retrasa y vuelve más costoso el proyecto).
11. ¿Qué es una iteración en los modelos iterativos?
En los modelos iterativos se divide el proyecto en bloques temporales, llamados iteraciones, en las
que se llevan a cabo diferentes tareas. Cada iteración se repite hasta obtener un producto que
satisfaga las necesidades del cliente.
Bloques temporales que dividen el proyecto en distintas partes con diferentes actividades a realizar
para la atención temprana de posibles fallos. Estos bloques se repiten hasta la finalización del
proyecto.
12. ¿Qué es una entrega de iteración (iteration release)?
Un iteration release es una versión estable, integrada y probada parcial o completamente del
sistema. Al final de cada iteración, se entrega al cliente una versión mejorada o con mayores
funcionalidades del producto. Será el cliente quien evalúe este producto y o bien lo corrija o bien
proponga nuevas mejoras.
Página 7
13. ¿Por qué el desarrollo en iteraciones reduce los riesgos presentes en el modelo en
cascada?
En el modelo en cascada, es necesario tener los requisitos claros y bien definidos desde un principio
para poder lograr una ejecución exitosa, rápida y rentable y para pasar a la siguiente fase es
necesario completar la anterior. Sin embargo, en la práctica esto se complica, ya que los requisitos
no suelen estar tan bien definidos desde un inicio y un proyecto no siempre sigue el flujo secuencial
del modelo.
Dividir en iteraciones este proceso mejora los aspectos comentados anteriormente, ya que no es
necesario tener las ideas tan claras desde un principio (pueden ir puliéndose conforme se desarrolla
el proyecto), se hace posible la detección de errores pronto (reduciendo costes y tiempo) y se
facilita la identificación de funcionalidades (que falten, no funcionen correctamente o sean difíciles
de implementar).
Otro aspecto muy importante es que el uso de iteraciones promueve la mitigación temprana de los
riesgos, debido a que en las primeras etapas se enfrentan las tareas más difíciles y que conforman
mayor riesgo (arquitectura e integración).
Finalmente, comentar que al permitir una evolución simultánea del modelo y el software también se
evita que ambos puedan quedar obsoletos en el momento de su aplicación (un riesgo bastante
importante dado el creciente desarrollo de la tecnología actual).
14. ¿Por qué los modelos iterativos también se denominan incrementales?
Porque al final de cada iteración se entrega un producto mejorado y es el cliente quien propone
nuevas mejoras o correcciones, es decir, tras cada iteración el producto incrementa en
funcionalidades, características, etc. y cada vez se va obteniendo uno que se adecua más a aquel que
satisface las necesidades del cliente.
15. ¿Cuáles son las similitudes entre una iteración y el modelo en cascada?
Hablan con el cliente. Ambas hacen testing. En las iteraciones los pasos no son lineales.
Los pasos que se realizan en ambas son similares, pero la carga de trabajo en cada una se distribuye
de manera diferente. Además, en las iteraciones los pasos no se realizan de manera lineal como en
el modelo en cascada.
16. ¿Qué significa que un desarrollo sea dirigido por riesgos?
Al principio de cada iteración es necesario elegir el conjunto de requerimientos que se van a
implementar. Un desarrollo dirigido por riesgos es una estrategia que tiene en cuenta los riesgos y
aquellos requerimientos que mitigan los más importantes. De esta forma, los problemas más graves
surgen en la etapa de desarrollo (cuando todavía no se ha avanzado mucho en el proyecto y queda
tiempo y presupuesto para corregir los problemas).
17. ¿Cuáles son las ventajas y los inconvenientes de dirigir un proyecto por riesgos o que lo
dirija el cliente?
En una estrategia dirigida por el cliente es él quien decide qué requerimientos van a ser
implementados en la siguiente iteración.
•
Ventajas: No tiene ventajas que un cliente dirija un proyecto.
•
Desventajas: El equipo de desarrollo es el responsable de estimar cuánto tiempo van a
necesitar para implementar estos requisitos (posible error de cálculo) y además, pueden no
saber muy bien qué requisitos dan más valor al cliente (pudiendo dejar estos requisitos para
Página 8
el final con el riesgo de que no se acaben implementando). El cliente puede no entender los
riesgos asociados a cada requisito, dejando riesgos importantes para el final del proyecto.
En una estrategia dirigida por riesgos:
•
Ventajas:
Con este enfoque los riesgos más importantes y graves surgen en la fase de
◦
desarrollo, esto permite que se solucionen (normalmente) pronto y a menor coste, lo
que reduce el coste tanto de trabajo como económico a largo plazo.
•
Desventajas:
Al priorizar aquellos riesgos que son más significativos, pueden dejarse de lado
◦
requerimientos importantes para el cliente y al dejarlos para el final, puede darse la
situación de que no lleguen a implementarse (no satisfaciendo así las necesidades del
cliente).
18. ¿Qué ventajas aporta los plazos fijos (timeboxing) en las iteraciones?
Establecer unos plazos fijos para cada iteración permite la reducción de retrasos en el desarrollo. Si
durante una iteración se ve que no se pueden implementar todos los requisitos, se dejan algunos
para la siguiente, es decir, la iteración sigue con la misma duración. Esta estrategia permite
identificar si el número de requisitos en cada iteración es correcto o si por el contrario es necesario
reducirlo (para evitar una sobrecarga de los trabajadores).
19. ¿Por qué se recomienda que los plazos de las iteraciones sean cortos (generalmente de
pocas semanas)?
Dicha recomendación beneficia en la disminución de problemas que puedan ir surgiendo, ya sea,
problemas con el tiempo de entrega, con el cumplimiento de requisitos, presupuesto, integrantes del
grupos…etc. De esta forma al ser plazos de iteraciones cortos podremos solucionarlo de una forma
más sencilla y menos costosa.
Los plazos son cortos porque de esta manera, cada unas pocas semanas se tiene un producto final
(parcial) que puede ser presentado al cliente, quien nos dará feedback para volver a modificarlo.
20. ¿Qué se recomienda hacer si se ve que no se va a cumplir el plazo de una iteración?
El plazo de una iteración no puede alargarse, por lo que si se observa que no va a ser posible
completar los requerimientos propuestos en ese tiempo, deben descartarse algunos y dejarlos para la
siguiente iteración.
21. ¿Por qué no se permiten cambios durante las iteraciones si los modelos iterativos
presumen de adaptarse bien a los cambios?
En este tipo de modelos, se permiten cambios pero entre iteraciones, cuando el proyecto es
reevaluado tras la entrega de una nueva versión. Esto es así ya que los requisitos de cada iteración
están marcados y se realiza una planificación concreta para ellos. Cambiar o añadir tareas implica
tener que reorganizar toda la iteración, lo cual no se acepta en este tipo de modelos.
22. ¿Qué quiere decir que un desarrollo es evolutivo?
El desarrollo evolutivo implica que los requisitos, planes y estimaciones se actualizan y refinan a lo
largo del desarrollo. Las versiones iniciales de esos elementos no se consideran fijas, sino que
evolucionan en función de cómo se desarrolle el proyecto.
Página 9
23. ¿Cómo se lleva a cabo el análisis de requisitos evolutivos en los métodos iterativos?
La mayoría de los requisitos se identifican durante las primeras iteraciones y se presta especial
atención a los requisitos que más influyen en la arquitectura o que agregan más valor al cliente.
No obstante, se realiza un taller de uno o dos días en el que se vuelve a analizar los requisitos, como
respuesta a la nueva información obtenida y al feedback recibido de versiones anteriores. Aunque
es cierto que los requisitos se analizan de manera frecuente a lo largo del proyecto.
24. ¿Cuál es la relación entre las entregas incrementales y la involucración de los clientes?
Al realizar entregas incrementales el cliente está más involucrado en el proyecto, es decir, al
finalizar cada iteración se presenta una nueva versión al cliente, y es este quien determina si el
resultado es bueno o no y cuáles son las mejoras o nuevas funcionalidades que este debiera tener.
25. ¿Qué es un caso de uso en el Proceso Unificado? 2.4.1¿Cuál es su principal función?
2.4.2
El Proceso Unificado es un marco de desarrollo software dirigido por casos de uso. La idea es que
en cada iteración se cojan un conjunto de casos de uso para su desarrollo, por lo que son la “base”
del proceso unificado. Su finalidad es:
•
Que sean lo suficientemente precisos como para que sirvan de base desde el desarrollo hasta
la implementación.
•
Que sean entendibles para las personas sin entrenamiento técnico.
•
Mostrar con más detalle la interacción entre el sistema (caja negra) y el usuario (actores) en
cada uno de los modos que el usuario puede utilizar el sistema, pero sin mostrar los detalles
internos.
Los casos de uso son los actores más importantes y qué realiza el sistema por ellos. Su principal
función es ayudarnos a tener una primera solución e idea del costo del proyecto. Los requisitos
recogidos en los casos de uso deben ser claros y alineados con el proyecto, ya que se necesita la
credibilidad del coste, prioridades, riesgos, etc.
26. ¿Por qué no se deben incluir aspectos no funcionales en los casos de uso?
Los casos de uso son un refinamiento de los requisitos funcionales y en ellos únicamente pueden
describirse detalles funcionales y otros aspectos técnicos, es decir, en los casos de uso se va a hablar
de qué hace el sistema, no de cómo lo hace (aspectos no funcionales).
Los casos de uso son un refinamiento de los requisitos funcionales y surgen de la interacción del
sistema con el usuario. Deben expresar la funcionalidad de manera comprensible para las personas
sin formación técnica. Es por ello que únicamente pueden describirse detalles funcionales y otros
aspectos técnicos, dejando de lado los detalles de la interfaz gráfica de usuario.
27. ¿Por qué los casos de uso deben estar escritos en un lenguaje que entienda el cliente?
Los casos de uso deben estar escritos en un lenguaje entendible por el cliente, ya que es necesario
que capturen las necesidades de los usuarios y permitan que los stakeholders las entiendan
fácilmente, de forma que los clientes puedan verificar que la descripción hecha por el equipo de
desarrollo es correcta y cubre sus necesidades y expectativas.
28. ¿Cuáles son las principales fases del PU?***
Las principales fases son: inicio, elaboración, construcción y transición.
Página 10
29. ¿Cuál es el objetivo de las fases del PU? 2.4.5
Los objetivos de cada fase del PU son:
•
Fase de inicio, consiste en determinar los requerimientos iniciales del proyecto y lo que
prevemos conseguir (riesgos, restricciones, primeros modelos..etc).
•
Fase de elaboración, consiste en llevar a cabo el trabajo que hemos hecho en la fase inicial
y desarrollar la arquitectura del proyecto.
•
Fase de construcción, fase en la que el diseño se termina de desarrollar y se implementa
completamente consiguiendo su total funcionalidad.
•
Fase de transición, esta es la última fase en la que el cliente ha de ser capaz de usar el
producto sin ningún problema, además se plantean mejoras futuras.
30. ¿Cuáles son los flujos de trabajo definidos en el PU?
Los flujos de trabajo definidos en el PU son requisitos, análisis, diseño, implementación y prueba.
31. ¿Cuál es la relación entre los modelos de los distintos flujos de trabajo?
La relación entre los modelos de distintos flujos de trabajo es que cada uno es la entrada para la
construcción del siguiente. En cada flujo se van refinando los modelos, incluyendo cada vez más
detalles hasta llegar al modelo de implementación, que se puede compilar para ejecutar el software.
A esta relación entre modelos se le denomina “trace”.
32. ¿Cuál es la relación entre los casos de uso y los casos de prueba?
Los casos de prueba derivan de los casos de uso. Ambos abarcan la definición de los requisitos
funcionales del sistema, pero se diferencian en el nivel de profundidad al que llega.
Los casos de uso abarcan todas las posibles rutas que se pueden seguir para lograr el proyecto y los
casos de prueba son un refinamiento que comprueba el cumplimiento o no de los requisitos de uso y
la relación con el usuario (cubren más a fondo el software).
33. ¿Qué características fundamentales distinguen a los métodos ágiles de otros métodos
iterativos?
En los métodos ágiles:
•
Se favorece y potencia la comunicación y el feedback (entre equipo de desarrollo y
clientes).
•
Se da importancia a los programadores (el trabajo se realiza mejor si la gente está
contenta)
•
Se utilizan prácticas y herramientas sencillas: en las metodologías ágiles se busca hacer
siempre lo más simple, no solo a nivel de código y diseño, sino también con las prácticas y
herramientas que se utilizan.
•
Se utilizan procesos empíricos: se basan en medir constantemente los eventos variables y
responder de manera dinámica ante ellos (muy útil sobre todo en ambientes inestables y
sujetos a muchos cambios).
•
Se basa en seguir una serie de principios en vez de reglas estrictas.
•
Presentan un toque humano (disciplina sostenible), ya que las actividades deben ser
asequibles para el equipo y este tiene que estar dispuesto a realizarlas de nuevo, es decir, la
actividad tiene que proporcionar disfrute, una ganancia al equipo, motivación, etc.
Página 11
•
El equipo se ve como un sistema adaptativo complejo: son los equipos de desarrollo
quienes asumen las responsabilidades de gestión (autoorganización, gestión de los roles,
asignación de tareas, etc.) en lugar de que una única persona lo planifique todo.
34. ¿Qué tipo de comunicación se promueve en los métodos ágiles?
En los métodos ágiles se promueve la comunicación cara a cara, tanto con el equipo como con el
cliente.
35.
•
•
•
•
•
¿Cuáles son los principios del pensamiento Lean?***
1. Identificar el valor.
2. Mapear el flujo de valor.
3. Optimizar el flujo.
4. Establecer el sistema pull, esto significa que solo se empieza una tarea cuando haya una
demanda o pedido.
5. Buscar la perfección.
36. ¿Cuáles son los valores de Scrum?
•
Compromiso: el equipo Scrum se compromete a lograr sus objetivos y apoyarse
•
Enfoque: su enfoque principal es en el trabajo del sprint para hacer el mejor progreso hacia
esos objetivos.
•
Apertura: el equipo Scrum y los stakeholders son abiertos sobre el trabajo y los desafios.
•
Respeto: los miembros del equipo Scrum se respetan entre sí para ser personas capaces e
independientes.
•
Coraje: los miembro del equipo Scrum tienen el valor/coraje de hacer lo correcto y de
trabajar en problemas difíciles.
37. ¿Qué toma Scrum del empirismo?
El empirismo afirma que el conocimiento procede de la experiencia y en tomar las decisiones
basándonos en lo que observamos. En Scrum cada sprint es una oportunidad de observar
(inspeccionar) y adaptar el proyecto.
38. ¿Qué es un Sprint en Scrum?
Un sprint en scrum, también llamado iteración, es un determinado tiempo en el que desarrollamos el
proyecto o producto para obtener una primera versión del producto final que luego será presentado
al cliente para validar los user stories esenciales.
Es un periodo breve de tiempo en el que un equipo de Scrum trabaja para completar una cantidad de
trabajo establecida (el Sprint Backlog). El objetivo es conseguir un incremento de valor en el
producto o proyecto que se está construyendo.
39. ¿Cuánto puede durar un Sprint en Scrum?¿Puede cambiar su duración durante un
proyecto?
Puede durar un mes o menos, el Sprint es continuo por lo que no debe cambiar su duración durante
el proyecto.
Página 12
40. ¿Cómo y cuándo se decide qué historias de usuario se van a implementar en un sprint?
Es en el Sprint Planning cuando se decide qué historias de usuario se van a implementar en cada
sprint y es el equipo de desarrollo quien las selecciona (mediante un push de los ítems del Product
Backlog) según su capacidad de trabajo.
41. ¿Cómo puede finalizar un Sprint?***
Un sprint puede finalizar con un prototipo funcional del proyecto o un prototipo que aún necesita
algunos cambios.
Porque acaba el tiempo, llega al final del proyecto.
Puede finalizar porque se ha terminado el tiempo del sprint o porque no se puede lograr el Sprint
goal.
42. ¿Quienes integran un equipo Scrum?
Un equipo de Scrum está compuesto por un Scrum Master, un Product Owner y uno o más
desarrolladores.
43.
•
•
•
¿Cuál es la función del Product Owner?
Es el responsable de maximizar el valor del producto que resulta en cada sprint.
Se ocupa de tratar con los stakeholders, clientes y sponsors para determinar qué quieren.
Organiza y define el Product Backlog.
44. ¿En qué debe emplear su tiempo el Scrum Master?
El Scrum Master es el encargado de establecer correctamente la metodología Scrum y de mantener
al equipo enfocado y ayudarle en caso de que se atasquen en alguna tarea.
45. ¿Por qué se dice que en Scrum los equipos se auto dirigen y autoorganizan?
El Scrum Team es un equipo auto organizado porque cada uno de los constituyentes decide sobre
que hacer, cuando se hace y cómo. Puede ocurrir que existan pequeños grupos dentro del equipo
global. En ese caso, estos grupos se auto organizan y cada uno se enfoca en el mismo objetivo.
La adaptación a cambios en el proceso de desarrollo es una de las características que debe
prevalecer en técnicas Scrum, y esto se hace cada vez más difícil cuando la gente que forma el
Scrum Team no está auto organizada.
46. ¿Para qué sirve la reunión diaria?
La reunión diaria sirve para revisar el progreso que se ha hecho y planear las siguientes 24 horas.
47. ¿Qué información contiene el Product Backlog?
Una vez determinados los user stories, la información que contiene el product backlog es una lista
en orden de prioridades de las user stories que necesitamos desarrollar. Además, tendrá el sizing de
los user stories.
48. ¿Qué información contiene el Sprint Backlog?
El sprint backlog tiene la información primordial del sprint, es decir, la lista de objetivos del sprint,
los elementos del product backlog que se han escogido para este sprint y las características del
definition of done para este sprint.
Página 13
49. ¿Cuál es el propósito de usar un burn-down chart?
Su propósito es servir de referencia para saber si la cantidad de trabajo es mucha o poca según
avanza el sprint y, en consecuencia, añadir o quitar elementos del product backlog.
50. ¿Quién puede cancelar un Sprint?¿Y bajo qué circunstancias?
Sólo el Product Owner puede cancelar un Sprint en caso de que el objetivo del Sprint quedara
obsoleto, por ejemplo, si cambian las condiciones del mercado, la tecnología, la dirección de la
empresa.
51. ¿En qué consiste la programación por parejas?
La programación por parejas es un método de programación en el que dos personas trabajan juntas
en un mismo programa. La primera persona es el “conductor”, que escribe el código, y la otra es el
“navegante”, que revisa cada línea de código a medida que se escribe, comprobando si hay errores.
Suelen intercambiar sus papeles con regularidad.
52. ¿Dónde se pueden incluir restricciones impuestas de eficiencia en el producto en Scrum
para su validación?
Se pueden incluir en los criterios de aceptación (comprueban las user stories) y en el Definition of
Done (se comprueban al final de cada iteración).
53. ¿Quién se encarga de aportar valor al producto en Scrum?
El Product Owner
54. ¿Cuáles son los artefactos de Scrum?
Un artefacto representa un “trabajo” o un “valor” y contiene un “compromiso” (un objetivo a
cumplir). Existen 3 artefactos:
•
Para el Product Backlog es el Product Goal (el producto final que cubre las necesidades del
paciente)
•
Para el Sprint Backlog es el Sprint Goal (objetivo a obtener al final de cada sprint)
•
Para el Incremento es el Definition of Done (la mejora o nueva funcionalidad, el
“incremento”, se crea cuando se cumple el DoD)
55. ¿Cuáles son los eventos de Scrum?
Eventos: Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.
El evento principal de Scrum es el Sprint y contiene al resto de eventos. El primero es el Sprint
Planning, donde el equipo de Scrum decide cuál es el Sprint goal, los ítems del Product Backlog
que se van a realizar en ese Sprint. Posteriormente, cada día se realizan Daily Scrum meetings, para
inspeccionar el progreso y planear el día siguiente.
El Sprint Review se realiza al final de cada Sprint para ver el incremento y recibir el feedback de
los stakeholders. El último evento es el Sprint Retrospective, donde el equipo de Scrum inspecciona
el proceso de desarrollo e identifica posibles problemas (mala comunicación, uso ineficiente de
herramientas, Definition of Done incompleto, etc.)
56. ¿Qué es el Definition of Done?
Es una descripción de las medidas de calidad requeridas para el producto. Puede incluir requisitos
como la seguridad, funcionalidad, etc., pruebas, organización, etc. En el momento en el que un item
Página 14
del Product Backlog cumple la definición descrita en en DoD, se crea un incremento (una nueva
funcionalidad añadida).
57. ¿Qué es una historia de usuario?
Las user stories o historias de usuario son explicaciones cortas, generales e informales de una
función de software desde la perspectiva de un usuario final o el cliente. Estas historias describen el
resultado que se espera, cómo va a proporcionar esta función valor al cliente y permiten dar a los
desarrolladores un contexto para que sepan qué compilan y con qué valor. Suelen responder a las
preguntas quién quiere la funcionalidad, cuál es la funcionalidad y por qué se necesita (el valor).
Página 15
Tema 3 - Gestión de proyectos
Este documento contiene 24 preguntas sobre el tema de gestión de proyectos.
1. What is a project?
Un proyecto es un conjunto de actividades interrelacionadas, realizadas por un grupo de personas
con el fin de producir un producto o servicio para un cliente en concreto.
2. What is the difference between a project and operations in an organization?
Los proyectos son trabajos temporales y únicos que buscan un resultado concreto (dar un producto
o un servicio al cliente) y son “tareas cerradas”, es decir, tienen un inicio y un fin (tienen un límite
temporal). Mientras que las operaciones son acciones continuas, repetitivas y estáticas, que no
tienen como objetivo producir nada, sino mantener y hacer sostenible el sistema. Un ejemplo de
operaciones podrían ser las tareas administrativas, el cobro a clientes, el pago a proveedores, etc. 3. What are the possible causes for a project to end?***
Un proyecto puede finalizar por 3 razones:
•
Se han cumplido los objetivos establecidos
•
Se concluye que no se pueden alcanzar los objetivos
•
Deja de existir la necesidad de ese proyecto
4. What are the main reasons that add complexity to the management of a project?
Tiempo, recursos, presupuesto, tamaño del proyecto y del equipo, número de dependencias con
otros proyectos y/o empresas, etc.
5. What is project management?
La gestión del proyecto hace referencia al conjunto de metodologías que se utilizan para planificar,
hacer un seguimiento y dirigir las tareas y recursos de un proyecto. Incluye aspectos como la
coordinación de procesos, las herramientas, los miembros del equipo y la habilidad para entregar
proyectos que cumplen y satisfacen los objetivos y necesidades del cliente.
6. What are the main process groups of Project Management according to the PMI?
Inicio, Planificación, Ejecución, Mantenimiento y control y Cierre.
7. What is the goal of the Project Initiation process group?*
El IPG está compuesto por esos procesos realizados para definir un nuevo proyecto habiendo
obtenido autorización para empezar el proyecto. El objetivo de este grupo es establecer lo que se va
a hacer en el proyecto, involucrando a los stakeholders para influir en esto. Si aun no se ha
realizado, se asignará al manager del proyecto.
8. What are the expected results from the Project Initiation process group?
Producir el Acta de Constitución del Proyecto, el documento que lidera el resto del desarrollo.
9. What is the Project Charter document?
Es un documento que autoriza formalmente la existencia de un proyecto y que proporciona a su
director la autoridad para aplicar recursos de la organización a las actividades del proyecto. En el
momento en que se aprueba un Project Charter, el proyecto se autoriza oficialmente.
Página 16
10. What is the information required to write the Project Charter?
1. Declaración del proyecto de trabajo: descripción del producto o servicio y cuál es el
resultado que se espera obtener.
2. Caso de negocio: describe si el proyecto es rentable o no
3. Acuerdos necesarios
4. Factores del entorno empresarial: condiciones y restricciones impuestas al proyecto sobre
las cuales no se tiene un control total (políticas, leyes, etc.)
5. Activos del proceso organizativo: información del día a día de la organización que pueden
afectar positiva o negativamente un proyecto (planes, procedimientos,, registros históricos,
lecciones aprendidas, etc de la empresa).
11. What is the Scope and Vision document?
Es un documento complementario al Project Chapter que incluye información extra útil para la
puesta en marcha del proyecto. El “scope” incluye una lista de características que deben
desarrollarse y el trabajo a realizar para ello. El “vision” es una descripción de alto nivel de
abstracción sobre los objetivos software del proyecto.
12. What is the information contained in the Scope and Vision document?
1. Objetivos del proyecto y del producto.
2. Características y requisitos del producto o servicio.
3. Criterios de aceptación del producto.
4. Límites del proyecto.
5. Requisitos y entregables del proyecto.
6. Restricciones del proyecto.
7. Supuestos preliminares del proyecto.
8. Riesgos iniciales definidos.
9. Principales hitos y su calendario.
10. Distribución del trabajo inicial.
11. Estimaciones de costos de alto nivel.
13. What is the product’s "Vision"?
Una descripción de alto nivel sobre los objetivos software principales del proyecto de manera
minimalista. Son unas pocas líneas en las que deben incluirse el propósito principal del nuevo
producto, su lugar en el mercado o en su entorno y las necesidades de los stakeholders.
14. What is the purpose of project planning?***
El objetivo del Project Planning es desarrollar un plan que permita ejecutar y controlar el proyecto.
15. What are the main activities to build a Project Plan?
1. Verificar el documento de definición: para asegurarnos de que toda la información es
correcta y válida.
2. Determinar qué hay que hacer: detalles sobre el enfoque del proyecto, los resultados que
se esperan y el trabajo necesario para completar el proyecto.
3. Determinar los criterios de aceptación: para tener criterios comunes que permitan evaluar
si los resultados de un proyecto son exitosos o no.
4. Determinar los recursos necesarios: incluye personas, tiempo, presupuesto, equipos e
instalaciones.
Página 17
5.
Adquisición de dichos recursos: gestionar la obtención de estos recursos para cuando sean
necesarios.
6. Estimación del trabajo: estimar los costes (tiempo, personal, etc.) que requiere la
realización de cada tarea o actividad.
7. Generar un horario: asignación de fechas límite y duración de cada actividad, fase y
proyecto final.
8. Actualizar roles y responsabilidades: si hay un nuevo rol en el proyecto se le debe asignar
una serie de responsabilidades, relacionarlo con un stakeholder y asignarlo a una persona en
concreto. Para cada actividad deben definirse las responsabilidades que tiene cada rol.
9. Actualizar la organización del proyecto: si hay cambios de personal, roles, departamentos,
organizaciones involucradas en el proyecto, etc.
10. Determinar los costes del proyecto y el presupuesto: incluye los recursos necesarios y el
“horario” (punto 7).
11. Determinar el sistema de control del proyecto: establece qué se va a controlar, cómo, con
qué frecuencia, cómo se informará, etc.
16. What is estimation?
Una estimación es una evaluación preliminar tentativa o aproximada del coste de un proyecto, es
decir, es un cálculo preliminar del coste, el tiempo o los recursos que requerirá una tarea futura de
un proyecto.
17. What is the difference between targets and estimations?
Un objetivo es una meta que se quiere alcanzar en el proyecto, en cambio una estimación es un
cálculo que se hace al principio del proyecto para establecer el coste, el tiempo o los recursos
necesarios.
18. What factors influence estimations?***
•
Los riesgos son un factor importante que influye en las estimaciones y deben tenerse en
cuenta al hacerlas. Del mismo modo, se harán suposiciones al calcular las estimaciones.
•
La experiencia de los trabajadores encargados de realizar la tarea es un factor importante, los
estimadores, ya que cuanto más experiencia tenga mayor será su implicación para llegar a
estas.
•
Las estimaciones deben estar basadas en datos medibles y procesos formales cuando sea
posible.
19. What is the PERT estimation used to compute an expected value?
Es una técnica de estimación que se aplica a tareas cortas (que tengan una duración menor a 2 días).
En ella se utiliza el mejor valor, el peor y el más probable.
20. How are estimations considered in Agile Methodologies?
Las técnicas de estimación ágil siguen la visión de simplicidad de las metodologías ágiles y no
utilizan grandes series históricas de registros de proyectos anteriores o técnicas estadísticas
complejas para estimar el tamaño de las historias de usuario.
Su estimación se basa en el criterio de miembros expertos del grupo, primandose así la
comunicación entre los miembros del equipo y la búsqueda de un consenso para determinar la
mejor estimación de cada historia de usuario.
21. When are large user stories acceptable in Agile-managed projects?
Página 18
Las historias de usuario grandes son aceptadas más hacia el final, ya que conviene comenzar con
tareas más pequeñas que tomen menos tiempo de realizar para así poder comenzar el proyecto. Si
inicialmente tengo una user story que me va a costar mucho trabajo y tiempo el proyecto queda
“parado” durante todo ese desarrollo.
22. How is Planning Poker used to develop estimations?
El product owner selecciona una user story y la lee en voz alta. Los desarrolladores le pueden hacer
cualquier pregunta sobre esta. Cuando no haya más preguntas, cada desarrollador elige una carta de
su mazo con su estimación, y todos muestran sus estimaciones. Si todas las estimaciones son
iguales, se le asigna a la historia de usuario. Si las estimaciones difieren, el desarrollador que haya
propuesto el valor más bajo y el del valor más alto justifica sus elecciones. Cuando hayan terminado
de exponer sus puntos de vista, todos los desarrolladores mantendrán una breve discusión y luego
comenzará una nueva ronda.
23. How is Team Estimation used to develop estimations?
Esta técnica se basa en el análisis de todas las decisiones tomadas por parte del equipo sobre la
complejidad (relativa) de las distintas historias de usuario. Se divide en dos partes:
1. Se ordenan las historias de usuario según su complejidad relativa
2. Se asigna una complejidad cuantificable (mediante el Scrum Poker) a cada historia de
usuario
Página 19
Tema 4 - Ingeniería de requisitos
Este documento contiene 25 preguntas sobre el tema de
1. ¿Qué es un requisito?***
Un requisito es una descripción de los servicios y restricciones de un sistema que se descubren
durante el proceso de la ingeniería de requisitos. También describen lo que los stakeholders
necesitan del sistema.
2. ¿Qué diferencia hay entre requisitos de sistema y de usuarios?***
Los requisitos de usuarios son declaraciones en lenguaje natural y en diagramas de los servicios que
debe brindar el sistema y las restricciones bajo las que debe funcionar. Se escriben en forma de user
stories y sin tecnicismos. Mientras que los requisitos del sistema son una especificación completa y
consistente del sistema, escrita en texto estructurado, detallando los servicios, lo que se
implementará y lo que no y sus restricciones.
3. ¿Cómo se documentan los requisitos en SCRUM?
Los requisitos en SCRUM se documentan a través del Product Backlog (lista de requisitos
funcionales (user stories) y no funcionales (definidos en DoD y criterios de aceptación) priorizados
por el Product Owner por su valor para el cliente).
4. ¿Qué es un requisito no funcional?
Un requisito no funcional son todas las restricciones y/o condiciones bajo las que tiene que trabajar
correctamente un sistema, es decir, son las características del software pero no determinan la
funcionalidad del sistema a desarrollar.
5. ¿Dónde se pueden incluir los requisitos no funcionales en SCRUM?
En el definition of done.
6.
¿Que es un requisito funcional?
Un requisito funcional describe lo que hace el producto, su funcionalidad y los servicios que
debe suministrar.
7.
•
¿Describe un ejemplo de requisito de eficiencia?***
El sistema debe de ser capaz de hacer N transferencias de datos en menos de X tiempo.
8. ¿Describe un ejemplo de requisito de fiabilidad?
Un sistema deberá tardar un máximo de x minutos para la recuperación de un fallo de caída total, en
la mayoría de los casos.
9.
•
•
¿Describe un ejemplo de requisito de seguridad?
Cada 24 horas se realizará una copia de seguridad de todos los datos del sistema en un
servidor ubicado en un edificio que no sea el sistema principal.
Las comunicaciones entre cliente y servidor se encriptaran.
Página 20
10. ¿A qué nivel de abstracción se puede definir un requisito?
Se puede definir a nivel de usuario (especificación a alto nivel) o del sistema (especificación
funcional).
11. ¿Qué diferencia hay entre un actor y un stakeholder?
Los actores son aquellos que interactúan directamente con el sistema (usuarios finales y gente que
interactúa con el sistema para conseguir los objetivos de los usuarios). Mientras que los
stakeholders incluyen a todas las personas y sistemas que no usan directamente el sistema, pero
afectan o se ven afectados por él y tienen cierta influencia sobre los requisitos.
12. ¿Qué papel juegan los actores (usuarios finales) y los stakeholders en los requisitos?*
De los actores se obtendrán los requisitos no funcionales para satisfacerlos, los stakeholders
definirán los requisitos funcionales.
13. ¿Qué es la Ingeniería de Requisitos?
Es el proceso para deducir, especificar y validar los requisitos de un sistema, se reúne a los
stakeholders y se obtienen y validan los requisitos.
14. ¿Cómo se relacionan los requisitos con otros aspectos de la ingeniería del software?
Existen algunos puntos en común entre los modelos de procesos de software:
1. La obtención y especificación de requisitos, en la que se definen las características globales del
sistema y las funciones que desean los usuarios.
2. Análisis de requisitos, en el que se construye un primer modelo del interior del sistema, un nivel
de abstracción muy alto y conceptos estrechamente ligados al dominio del negocio, comprensibles
para el usuario.
3. Diseño, en el que se construye un modelo del sistema mucho más cercano a las restricciones
técnicas y lógicas a las que debe enfrentarse el sistema, y más cercano a los conceptos informáticos
que al dominio del negocio.
4. Desarrollo, en el que se construye finalmente el sistema informático que lleva a cabo las
acciones esperadas por el sistema.
5. Pruebas, utilizadas para verificar si el sistema implementado responde a su especificación.
6. Despliegue, donde se pone en producción el sistema creado. Puede incluir la migración desde
sistemas anteriores y la formación de los usuarios.
15. ¿Qué técnicas se pueden aplicar para obtener requisitos?
Se pueden obtener requisitos a través de entrevistas, reuniones de equipo, la etnografía, los
escenarios (por ejemplo, casos de uso), prototipos.
16. ¿Cuándo se recomienda el uso de la técnica de Etnografía?
Es recomendable cuando el dominio es muy específico y no entendemos del tema, vamos al entorno
para saber donde va a estar implementado el software y cómo trabaja la gente.
17. ¿Qué formas hay de documentar requisitos?
Se pueden documentar desde la perspectiva de dominio del problema, especificando el
comportamiento externo del sistema y no los detalles sobre su arquitectura y diseño (documento de
definición del sistema). Se usa lenguaje natural.
Otra forma es especificar los requisitos de sistema y los requisitos de software que derivan de estos
(documento de requisitos del sistema).
Página 21
Estableciendo las bases para un acuerdo entre clientes y contratistas sobre lo que debe hacer el
producto y lo que no. Debe tener descripciones formales y estimación de costes, riesgo y tiempo
(SRS).
18. ¿Qué retos encontramos en la obtención de requisitos?
Uno de los retos es que los requisitos no sean ambiguos.
En el caso de los requisitos del dominio es muy probable que no entendamos la terminología que se
usa y que los especialistas no aclaren explícitamente los requisitos del dominio, ya que para ellos
está claro.
Sean validables. El cliente no sabe lo que quiere ni la dificultad que esto implica.
19. ¿Qué es un Storyboard?
Un storyboard, es un conjunto de ilustraciones presentadas de forma secuencial con el objetivo de
servir de guía para entender de una forma más gráfica una historia. En este caso un storyboard nos
permitirá comprender, planificar, previsualizar las historias de usuario de los casos de uso,
referencia a elementos del software…etc, de una forma más gráfica.
20. ¿Para qué sirve la validación de requisitos?
La validación de requisitos sirve para determinar si estos requisitos cumplen las especificaciones
del cliente cuando el producto ha sido terminado.
21. ¿Cómo se realiza la validación de requisitos en SCRUM?
Se comprueban los criterios de aceptación cumplidos y el DoD
22. ¿Qué se persigue con la priorización de los requisitos?
Se intenta decidir si un requisito es más importante que otro para hacerlo antes.
23. Describe una user story con dos criterios de validación.
User story: Como usuario quiero acceder a la agenda de especialidades médicas de forma segura
para usar sus funcionalidades.
Criterios de aceptación:
· El nombre de usuario debe existir en la base de datos, en caso contrario se mostrará un error de
inicio de sesión.
· La contraseña debe coincidir con la que el nombre de usuario tiene asociada en la base de datos,
en otro caso se mostrará un error de inicio de sesión.
24. Describe un par de criterios que se pueden usar en el DoD.
En el DoD van los requisitos no funcionales, como por ejemplo, que el tiempo de análisis de un
dispositivo médico no exceda los 3 minutos. Otro ejemplo es que una aplicación sea compatible con
Windows.
25. ¿Dónde se puede realizar la validación en SCRUM? Describe todos los posibles sitios.*
En el Sprint Review, donde los stakeholders hablan sobre la mejora de calidad del producto (El
incremento) y el Product Owner define el valor de este.
Página 22
Tema 5 - Modelado de sistemas
Este documento contiene 18 preguntas sobre el tema de modelado
1. ¿Qué es un modelo?***
Un modelo es una abstracción de la realidad que nos permite quedarnos con los aspectos más
relevantes de la misma.
2. ¿Qué vistas propone el modelo unificado?
Vista lógica: describe la estructura del software.
Vista de despliegue: muestra cómo los ejecutables y otros componentes de tiempo de ejecución se
asignan a las plataformas subyacentes o nodos informáticos.
Vista de proceso: aborda el aspecto concurrente del sistema en tiempo de ejecución.
Vista de implementación: proporciona la organización estática del software en términos de
empaquetado, estratificación y gestión de la configuración.
3. ¿Qué son los atributos en un diagrama de clases?
Los atributos son los elementos de la clase que almacenan los datos que son propios de dicha clase.
4. ¿Qué son las operaciones o métodos en un diagrama de clases?
Las operaciones son descripciones del comportamiento de los objetos.
5. ¿Qué significa que un atributo en un diagrama de clases sea protegido?
Quiere decir que solo se puede acceder al atributo desde una instancia de la misma clase o desde
una clase que especializa a esa clase.
6. ¿Qué significa que un atributo en un diagrama de clases sea público?***
Significa que se accede al atributo desde cualquier otra clase del modelo.
7. ¿Qué significa que un atributo en un diagrama de clases sea derivado?
Los atributos derivados son atributos cuyos valores se pueden calcular a partir de valores de
atributos relacionados.
8.
¿Qué diferencia hay entre una relación de composición y una de agregación en un
diagrama de clases?
En el caso de las composiciones, una parte no puede existir sin ser parte de un todo, si eliminamos
una clase, las que la componen también se eliminan. Mientras que en la agregación una parte puede
existir sin ser parte del todo.
9.
¿Qué diferencia hay entre una relación de agregación y una de especialización en un
diagrama de clases?
En la agregación hay una clase que representa el todo y se compone por instancias de otras clases
(las partes). En cambio, en la generalización se consideran objetos independientes aun cuando haya
enlaces frecuentes entre ellos. La agregación es una relación más fuerte.
10. ¿Qué diferencia hay entre una relación agregación y una de asociación en un diagrama
de clases?
Página 23
La relación de agregación indica que un objeto de una clase es parte de un objeto de otra clase que
es un todo. Mientras que la relación de asociación indica que un objeto de una clase tiene un objeto
de otra clase, si A tiene a la clase B, la clase B puede ser tratada como otro atributo de la clase A.
11. ¿Qué relación existe entre los mensajes y las líneas de vida (lifeline) en un diagrama de
secuencia?
Las líneas de vida aparecen siempre que el objeto esté vivo en la interacción, si este envía mensajes,
la línea de vida presenta activaciones (tiempo en el que el objeto está activo en la interacción).
12. ¿Qué tipos de mensajes existen en un diagrama de secuencia?
Los mensajes pueden ser:
•
Síncronos: el emisor del mensaje queda bloqueado hasta que el receptor le responda.
•
Asíncrono: no esperan respuesta, por lo que pueden o no tenerla.
•
Creación: designa la creación de otro objeto de línea de vida.
•
Borrar: designa la terminación de otra línea de vida.
•
Respuesta: mensaje de respuesta a una llamada de operación.
13. ¿Para qué se usa un actor en un diagrama de secuencia?
Los actores representan a los objetos o usuarios que van a interactuar entre sí durante la secuencia.
14. ¿Describe un ejemplo de automensaje en un diagrama de secuencia?
En el diagrama de secuencia de la pulsera de pulsos vemos que la central se envía un automensaje
para actualizar la alarma. Este mensaje es síncrono, pero la respuesta está implícita porque responde
eél mismo participante que recibe el mensaje. Grupo Q
15. ¿Qué diferencia existe entre una activación (trigger) y una guarda (guard) en una
transición en el diagrama de máquina de estados?***
La activación es la transición de un estado a otro, mientras que la guarda es la condición que debe
cumplirse para que se dé el trigger.
La guarda no define la activación, si no que define a dónde se va en el siguiente paso. El trigger lo
hace es producir la transición de un estado a otro.
16. ¿Es posible modelar transiciones de salida en un estado final de un diagrama de
máquina de estados?
No.
17. ¿Qué significa la expresión run-to-completion semantics en los diagramas de máquina
de estados?
Significa que una máquina de estado finaliza todas las acciones relacionadas con la recepción de la
ocurrencia de un evento antes de comenzar con la reacción a la ocurrencia de otro evento.
18. Describe un ejemplo en el que se modelen dos transiciones salientes de un estado en un
diagrama de máquina de estados*
Página 24
Tema 6 - Diseño software
Este documento contiene 20 preguntas sobre el tema de diseño
1. ¿Qué es una responsabilidad en el tema de diseño software?
Son las obligaciones de un objeto en términos de su comportamiento, y hay dos tipos: de conocer y
de hacer. Son asignadas a las clases durante el diseño y puede incluir la ejecución de varios
métodos.
2. ¿Qué aporta tener una alta cohesión?
La cohesión mide la relación entre las responsabilidades de un elemento. Tener una alta cohesión
quiere decir que un elemento tiene responsabilidades altamente relacionadas y no hace una excesiva
cantidad de trabajo.
3. ¿Qué conlleva una baja cohesión?
Una clase con baja cohesión conlleva a que sean difíciles de comprender, de reutilizar y mantener.
Son también delicadas, y, están sometidas constantemente a cambios. Estas clases hacen muchas
cosas que no están relacionadas y hacen una excesiva cantidad de trabajo.
4. ¿Qué aporta un bajo acoplamiento?
El acoplamiento es una medida que comprueba cómo de fuerte está conectado un elemento y si
depende de otros elementos. Si este acoplamiento es bajo, quiere decir que dicho elemento no
depende de muchos otros.
5. ¿Qué ocurre cuando el acoplamiento es alto?
Si una clase tiene un acoplamiento alto, quiere decir que depende de muchas otras clases. Estas
clases deben evitarse.
6. ¿Qué relación hay entre el acoplamiento y la cohesión?***
Si tenemos una clase con alta cohesión, las responsabilidades están centradas en esa misma clase,
que dependerá de pocas clases, con lo cual, tendremos bajo acoplamiento. Las clases con alta
cohesión normalmente tienen bajo acoplamiento porque cada una hace sus responsabilidades, sin
necesitar de las demás. Igualmente depende mucho del sistema en concreto, porque podemos tener
clases con muy alta cohesión y otras con baja cohesión que necesiten de otras clases.
7. ¿Qué mejora aporta usar el principio de information expert?***
El principio de information expert indica que la responsabilidad de la creación de un objeto o
implementación de un método recae sobre la clase que conoce toda la información necesaria para
crearlo, obteniendo así un diseño con mayor cohesión y la información se mantiene encapsulada,
disminuyendo así el acoplamiento.
8.
¿Qué relación hay entre el principio creator y las relaciones en el diagrama de clases de
composición?
En el caso del principio creator hay una clase B que tiene la responsabilidad de crear a la clase A.
Esta responsabilidad es asignada a B si cumple con una o más afirmaciones, entre las que se
encuentran que B agregue objetos de A, contenga objetos de A, guarde instancias de los objetos de
A, etc.
Página 25
Por otro lado, en el caso de la composicion, si B está compuesto por A, cuando se crea un objeto de
la clase B puede o no crearse uno de A (depende de la multiplicidad en la relación). Es decir, debe
crearse un objeto de B para que pueda crearse un objeto de la clase A.
En ambos casos, primero debe crearse el objeto de la clase B para que se pueda crear el de la clase
A. Si el creator cumple con varias de las afirmaciones puede ser conveniente elegir una relación de
asociación.
9. ¿Qué ventajas aporta usar el principio controller?
Un controlador es un componente de software que permite al sistema operativo y un dispositivo
comunicarse entre sí. Se encarga de la interacción con el usuario (por ejemplo: clicks de ratón,
teclas pulsadas) y de pasar esas interacciones a la Vista o el Modelo.
Este principio permite especificar las respuestas a sucesos o solicitudes de datos concretas,
permitiendo que entidades o arquitecturas externas lleven a cabo las acciones de control necesarias.
Las ventajas son:
•
Al automatizar las tareas se reduce el costo de mano de obra.
•
Es más fácil monitorear los procesos (más sencilla la detección de errores).
•
Ahorro en gastos de operación, mantenimiento, etc.
10. ¿Qué principio de SOLID aumenta la cohesión?¿Por qué?
El principio de responsabilidad única (SRP). Una clase o función debe centrarse en una única
responsabilidad y debe existir una única razón para cambiar. Por ello, todos los métodos deberían
tener una alta cohesión.
11. Describe el principio abierto-cerrado de SOLID. Pon un ejemplo en pseudo-código.
Expresa la necesidad de que ante un cambio de los requisitos, el diseño de las entidades existentes
permanezca inalterado, es decir, debe adaptarse a nuevas situaciones, sin modificar el código
existente y añadiendo nuevo código. Se puede conseguir por polimorfismo, dinámico (sin
especificar datos), o estático (datos explícitos).
12. ¿Qué consecuencias puede tener una violación del principio de sustitución de Liskov?
Las consecuencias que puede tener la violación de dicho principio son ocultar el comportamiento
heredado, redefiniendo métodos con implementaciones vacías o lanzando excepciones, modificar el
comportamiento heredado, redefiniendo métodos con semánticas incompatibles o lanzando
excepciones nuevas, modificar la clase base, para adaptarlas a las necesidades de la heredada, y para
redefiniar mas de lo que se extiende, se debe usar delegación, agregación o composición.
Si se viola el principio de sustitución de Liskov, quiere decir que la clase hijo no puede sustituir a la
clase padre. En consecuencia, se intenta arreglar modificando el código que funciona bien, ya que
buscamos ocultar o modificar el comportamiento heredado, o modificar la clase base. Así es como
el no cumplimiento del principio de sustitución conlleva al no cumplimiento del principio abiertocerrado.
13. ¿Qué ventajas aporta el principio de segregación de interfaces de SOLID?
Este principio permite agrupar a los clientes según sus necesidades y segregar la interfaz del sistema
en función de los clientes. Así un cliente no tiene que aprender de los métodos que no use y puede
usar solo el subconjunto de la interfaz que necesite.
Página 26
14. ¿Qué representa la arquitectura de un sistema?
Representa una vista general de cómo es el sistema, su organización, elementos estructurales e
interfaces.
15. ¿Cómo se organiza el patrón arquitectónico de tuberías y filtros? Pon un ejemplo de
uso.
Está dirigido por el flujo de datos. Estos datos se procesan incrementalmente conforme llegan.
Los filtros leen flujos de entrada, transforman localmente los datos, escriben flujos de salida y son
independientes, lo que quiere decir que no tienen estados compartido y que entre sí no se conocen.
Los filtros son equivalentes a los componentes.
Las tuberías, son los flujos de datos, y equivalen a los conectores.
Un ejemplo puede ser en la composición en lenguajes funcionales, por ejemplo Haskell.
Este patrón tiene componentes, que son los filtros, es decir, programas que leen flujos de entrada,
transforman localmente los datos y escriben flujos de salida. Los conectores son las tuberías, es
decir, los flujos de datos. Los componentes y conectores se organizan de manera que un filtro coge
la entrada (tubería), aplica un algoritmo y lanza la salida. Esta salida puede ser tomada como flujo
de entrada para otro filtro.
Un ejemplo de uso es el procesamiento de imágenes, donde el flujo de entrada es la imagen y el
filtro es una función de ajuste de contraste que devuelve la imagen ajustada. Este resultado puede
ser tomado por otro filtro que aplique la detección de objetos y devuelva la imagen resultante.
16. ¿Cómo se organiza el patrón arquitectónico de llamada y retorno funcional? Pon un
ejemplo de uso.
Está basado en la descomposición funcional del sistema.
En este caso, las subrutinas implementan tareas o subtareas, ofrecen una interfaz al exterior, y están
combinadas a través del flujo de control. Se corresponden a los componentes.
Las llamadas están de acuerdo con la interfaz, y se corresponden con los conectores.
La organización de este patrón consta de unos componentes que son subrutinas, resultantes de la
descomposición funcional del sistema, es decir, dividimos un programa según las tareas a realizar.
Los conectores son las llamadas a esas subrutinas, es decir, los argumentos.
Un ejemplo es la descomposición de la gestión de un pedido en subrutinas que hacen tareas
específicas, como el cálculo del precio, gestión de cobro y gestión de envío.
17. ¿Cómo se organiza el patrón arquitectónico de capas? Pon un ejemplo de uso.
Este patrón se organiza en niveles de abstracción, que son las capas. Cada capa se comunica
únicamente con las capas adyacentes y entre las capas hay interfaces definidas que definen su
interacción. Generalmente las capas más bajas proporcionan servicios de bajo nivel. Las capas son
los componentes y las interfaces son los conectores.
Un ejemplo es su uso en los protocolos de comunicación, donde tenemos las capas (desde abajo
hacia arriba) física, de enlace, de red, transporte, sesión, presentación y aplicación. Cada capa presta
servicios a su capa inmediatamente superior y demanda a la capa inmediatamente inferior, por
ejemplo, la capa de red presta servicios a la capa de transporte y demanda a la capa de enlace.
18. ¿Cómo se organiza el patrón arquitectónico de repositorio? Pon un ejemplo de uso.
Página 27
Los componentes de este patrón son los clientes y el repositorio, mientras que los conectores son los
flujos de datos. Se organiza de manera que tenemos un repositorio donde se manejan todos los datos
del sistema y al que acceden clientes que no se comunican entre sí (sólo a través del repositorio).
Un ejemplo de uso es almacenar todos los datos de los pacientes de un hospital en un repositorio
para que los distintos clientes (médicos especialistas, enfermeros, cirujanos, administrativos, etc.)
puedan acceder a ellos.
19. ¿Cómo se organiza el patrón arquitectónico de cliente-servidor? Pon un ejemplo de
uso.
La organización de este patrón consiste en uno o más clientes (componente) que se conectan a un
servidor (componente) para demandar servicios que los servidores ofrecen. Los conectores son los
flujos de datos, que pueden ser remotos o locales.
Un ejemplo de uso es cuando el navegador es el cliente y pide servicios a un servidor web (como
por ejemplo, google.com) a través de internet.
20. ¿Cómo se organiza el patrón arquitectónico de modelo-vista-controlador? Pon un
ejemplo de uso.
Este patrón cuenta con tres componentes, el modelo (gestiona los datos y operaciones del sistema),
la vista (representación visual del modelo) y el controlador (responsable de traducir las
interacciones del usuario a datos y pasarlas a la vista o al modelo). Estos tres componentes se
organizan de tal forma que el usuario interacciona con la vista y los datos llegan al controlador, este
procesa los datos y los transmite al modelo. Por ultimo, el modelo cambia, notifica al controlador y
se hacen los cambios en la vista.
Un ejemplo de uso es una aplicación de tienda on-line, donde el controlador recibe la acción
solicitada por el usuario y se lo transfiere al modelo, que se actualiza y lo comunica para que la
vista muestre lo correcto. Por ejemplo, si el usuario hace click en un producto, deben hacerse los
cambios necesarios en el modelo para que la vista se actualice y muestre el producto correcto.
Página 28
Tema 7 - Verificación y pruebas
Este documento contiene 17 preguntas sobre el tema de verificación y pruebas.
1. ¿Qué son las pruebas unitarias?
Son aquellas en las que se prueban unidades de programa individuales o clases de objetos. Se
centran únicamente en probar la funcionalidad de los objetos y/o métodos.
2. ¿Qué son las pruebas de componentes?
Son aquellas en las que se integran varias unidades individuales para crear componentes
compuestos. Se centran en probar las interfaces de los componentes.
3. ¿Qué son las pruebas de sistema?
Son aquellas donde algunos o todos los componentes de un sistema están integrados y el sistema se
prueba como un todo. Se centran en probar las interacciones de los componentes.
4. ¿Qué son las pruebas de release?***
Son pruebas en las que un equipo de prueba externo prueba una versión completa del sistema antes
de que se lance a los usuarios.
5. ¿Qué son las pruebas de usuario?
Son pruebas en las que los usuarios o usuarios potenciales de un sistema prueban el sistema en su
propio entorno.
6. ¿Qué técnicas para realizar pruebas unitarias conoces?
JUnit y Unittest. Son framework de automatización de pruebas que proporcionan clases de prueba
genéricas para crear casos de prueba específicos (permiten ejecutar todas las pruebas que se han
implementado e informar, a menudo de forma gráfica, sobre el éxito o fracaso de las pruebas).
7. ¿Qué diferencia hay entre pruebas de caja negra y pruebas de caja blanca?***
La caja blanca sabes el código, en la caja negra usas una interfaz.
8. ¿Qué son los caminos base en las pruebas unitarias?
Son los caminos independientes del código. El número de caminos base se calcula con la
complejidad ciclomática del grafo de flujo.
9. ¿Qué son las particiones de equivalencia en las pruebas?
Las particiones de equivalencia son las clases en las que se dividen los datos de entrada. Todos los
datos de una clase están relacionados y muestran un comportamiento común. El programa se
comporta de manera equivalente para cada miembro de la clase de equivalencia.
10. ¿Qué aportan las pruebas de interfaz?
Aportan garantizar una comunicación fluida y segura entre los componentes del software
11. ¿Qué son las pruebas alpha?***
Son pruebas de usuario que incluyen a los desarrolladores. Los usuarios trabajan con el equipo de
desarrolladores y prueban el software en el sitio del equipo de desarrollo. Se centra en ver que el
Página 29
sistema cumpla con las funcionalidades esperadas y que el usuario sea capaz de hacer lo que le
piden los desarrolladores.
12. ¿Qué son las pruebas beta?
Son pruebas de usuario que se hacen cuando el software se pone a disposición del usuario, puede
ser que el software se saque al mercado controlado o que sea una muestra gratuita. Se hace para que
el usuario experimente y detecte problemas.
13. ¿Qué son las pruebas de aceptación?
Son pruebas en las que el cliente prueba el sistema para decidir si está listo para ser aceptado y
desplegado en el entorno del cliente. Suelen ser pruebas para sistemas personalizados porque el
desarrollador va al entorno del cliente a instalar el software.
14. ¿Qué diferencia existe entre las pruebas de sistema y las de release?
Las pruebas de sistema las realiza el equipo de desarrollo y el objetivo es hacer un defect testing, es
decir, encontrar errores. En cambio, las pruebas de release son hechas por un equipo externo que
hace un validation testing, es decir, buscan verificar que el sistema cumpla con los requisitos y
funcione como se espera, no buscan errores.
15. ¿Qué diferencia existe entre las pruebas alpha y beta de usuario?
Durante las pruebas alpha, solo se prueban la funcionalidad y la usabilidad, mientras que durante las
pruebas beta, la usabilidad, la funcionalidad, la seguridad y la confiabilidad se prueban con la
misma profundidad.
En las pruebas Alpha se incluye a los desarrolladores, que trabajan con los usuarios en el sitio del
equipo de desarrollo. En cambio, las pruebas beta son hechas en el entorno del usuario, sin que el
desarrollador le pida que haga cosas específicas.
16. ¿Qué diferencia existe entre la generación de pruebas con las particiones de
equivalencia y los caminos base?
Las particiones de equivalencia es una caja negra y los caminos bases caja blanca.
17. ¿Pueden las pruebas garantizar la ausencia de errores?¿Por qué?
"Las pruebas pueden ser una forma muy efectiva de mostrar la presencia de errores, pero son
irremediablemente inadecuadas para mostrar su ausencia". - Dijkstra
Página 30