Apuntes examen de prueba PS 2020

Gestión de riesgos:
- Los imprevistos no los tenemos identificados, por eso son imprevistos. Los riesgos
SI los tenemos identificados.

- El riesgo puede afectar a muchos más aspectos que solamente a la planificación

- Los riesgos siempre están identificados, pero no siempre cuentan con una estrategia
de mitigación. Solamente se diseñan estrategias de mitigación para aquellos riesgos
que pueden suponer un mayor impacto al proyecto (entendido impacto como la
conjunción de probabilidad de que se de el riesgo junto con el daño que produciría)

- Las estrategias de mitigación también pueden estar orientadas a reducir el daño que
el riesgo puede producir en el proyecto una vez que se ha presentado.

Documentación de las interfaces de módulos y

componentes en las vistas arquitecturales:
- No podemos tener componentes sin interfaces que hagan algo útil en nuestro
sistema. Puede que estén gastando ciclos de procesador y ocupando memoria, pero
si no pueden recibir órdenes, ni datos, ni devolver datos, ni enviar órdenes... no
están haciendo nada útil.

- La interfaz de una clase NO incluye sus métodos y atributos privados. Solo los
públicos son parte de su interfaz

- Al describir la interfaz de un elemento, hay que expresar lo que los otros elementos
del sistema pueden esperar del mismo. Esto es lo fundamental. En general no es
importante, o muy poco, cómo hace su trabajo, pero sí es importante lo que
podemos esperar que haga cuando le llamemos a través de sus interfaces.

- Cada componente puede ofrecer más de una interfaz. Es habitual que un

componente ofrezca distintas interfaces. Un ejemplo sencillo es un objeto de una
clase Java que implementa dos interfaces. Ese es un componente con dos interfaces
Vistas arquitecturales de módulos:
- Suelen incluir diagramas de clases y paquetes de UML. Las clases y paquetes son
módulos.

- NO incluyen diagramas de casos de uso de UML. Los casos de uso son análisis. Se
hacen antes de diseñar qué módulos tendrá el sistema.

- NO contienen procesos, objetos, clientes, servidores etc. Todos esos son

componentes (tiempo de ejecución) y no módulos (tiempo de diseño).

- NO describen el sistema en tiempo de ejecución. Lo describen en tiempo de diseño,

que es cuando estamos escribiendo el código, y no en tiempo de ejecución que es
cuando el sistema está en marcha.

Entrega continua:
- El proceso de lanzamiento es repetible, fiable y predecible. Esto son todo beneficios,
y se deben a tener el proceso basado en scripts y probado continuamente
- Facilita desplegar en entornos nuevos. Esto es un beneficio. Es más fácil adaptar el
despliegue a un nuevo entorno cuando haga falta cuando el despliegue está basado
en scripts.
- Disminuye el estrés que normalmente produce el verse cerca de la fecha de
lanzamiento. Esto es un beneficio y se consigue gracias a que el proceso de
despliegue se ha realizado muchas veces antes del despliegue final, por lo que ya
sabemos que no va a fallar.

En muchas ocasiones, con o sin entrega continua, no se permite a los usuarios decidir
cuándo quieren volver a una versión anterior del software. Y si se puede hacer, no es
porque la entrega continua lo permita (en todo caso podría hacerlo un poco más fácil).
Paquetes de trabajo:
- Son unidades de gestión dentro del proyecto. De hecho, las unidades con las que
vamos a llevar a cabo la gestión en todo lo relativo a la construcción de los
entregables al cliente.

- No son momentos importantes de proyecto. Los Momentos importantes de proyecto

son los Hitos

- No son las unidades de gestión de configuraciones del proyecto. En algunos casos

se pueden mapear unidades de gestión de configuraciones a paquetes de trabajo,
pero generalmente éstas se constituyen como agregados de paquetes de trabajo y
de sus resultados

- No son los elementos que vamos a entregar a los clientes. Los elementos que
vamos a entregar a los clientes son los entregables. Hay paquetes de trabajo cuyo
resultado se integra en estos entregables y otros no.

Métricas calculadas con el código fuente:

- Code churn (tasa de cambio del código). Líneas de código añadidas, borradas y
cambiadas.

- Las métricas CK (Chidamber y Kemerer). Son para lenguajes orientados a objetos y

se calculan a partir del código.

Sistema de Gestión de la Calidad

- Beneficia​ al ​cliente​ porque consigue productos de calidad. Es posible conseguir un
producto de calidad sin un sistema de calidad. Pero es menos probable que si se
tiene el sistema de calidad.

- Beneficia​ a la ​gerencia de la organización​ porque tiene garantía de que se

pueden cumplir los compromisos que se adquieren. El no cumplimiento de estos
compromisos genera afecciones económicas que la gerencia tiene que evitar o
minimizar. El sistema de calidad le da garantías ante estos problemas.

- No afecta al desarrollador. Lo que tiene que hacer cada desarrollador en cada

momento se establece en la planificación del mismo, no en el sistema de calidad.

- Tampoco afecta a las subcontrataciones. El sistema de calidad no tiene ninguna

implicación directa con la integración de resultados de las subcontratas. Según el
 grado de desarrollo del sistema de calidad, éste tendrá definidos procedimientos que
fijen la gestión de la relación, pero no la integración

Git, merges y conflictos:

- Los merge ​fast-forward​ son ​automáticos​, esencialmente consisten en mover un
puntero hacia delante en el grafo de commits.

- También son ​automáticos​ cualquier merge de dos ramas donde los cambios sean
compatibles​ (por ejemplo, son cambios en ficheros distintos).

- La mayoría de merges tienen ​más de un padre​. Un merge es combinar dos o más

ramas. Es probable que esas ramas apunten a commits distintos y que no están en
el mismo camino en el grafo de commits, luego el merge commit tendrá dos o más
padres.

- No todos los tipos de merge en Git añaden un commit especial a la historia del
repositorio denominado merge commit. Los fast-forwards no lo hacen.

Marco legal:
- Sienta las bases sobre las que construimos la relación jurídica con nuestros clientes.
Es posible que nuestros desarrollos afecten a terceros y nos veamos limitados por lo
que legalmente podemos y no podemos hacer en este relación con ellos.

- Fija límites a lo que podemos hacer con la tecnologías. NUNCA podemos saltarnos
la legalidad, aunque tecnológicamente sea factible.

- El actual marco legal que tenemos lo fija un Reglamento de la Unión Europea que es
de obligado cumplimiento en TODOS los países de la misma.

Trabajo con clientes:

- Hay que hacer lo que hemos acordado con el cliente en el documento de requisitos,
no lo que nos vaya diciendo sobre la marcha.

- No debemos buscar que oigan lo que quieren porque es posible (casi seguro) que
no seremos capaces de hacerlo. Debemos explicar nuestra propuesta y qué valor les
aporta a ellos.
 - Debemos mostrar solamente aquellos aspectos de la realidad que más nos
beneficien, pero siempre sin mentir.

- Seremos especialmente cuidadosos a la hora de planificar nuestras reuniones con

ellos para evitar que tengan la sensación de que les hacemos perder el tiempo. Nos
están cediendo su tiempo por lo que debemos conseguir que no tengan la sensación
de haberlo perdido

Un buen jefe de proyectos presenta las siguientes

cualidades:
- Liderazgo​. El jefe del equipo es líder, debe ejercer como tal, y ser reconocidos por
el resto de integrantes del equipo

- Buena​ ​comunicación​. Tiene que ser capaz de comunicar hacia el equipo, hacia la
gerencia y hacia el cliente.

- Buena​ ​organización​. Tiene que ser capaz de organizarse a si mismo y a todo el

equipo

- Dominar​ ​la​ ​tecnología​. Tiene que saber moverse en la tecnología con la que el
equipo está trabajando para comprender las limitaciones y capacidades de la misma,
así como para poder entenderse con el equipo.

Integración continua:
- Es una ​práctica​. Es algo que se hace. No es un software, aunque haya software
que la facilite.

- Requiere, entre otras cosas, que usemos un sistema de control de versiones. Sin un
VCS​ no tenemos la base para hacer integración continua.

- No consiste en poner inmediatamente en manos de los usuarios todos los cambios

que hagamos en el código, siempre que pasen todas las pruebas. Eso es el
despliegue continuo, que requiere que hagamos integración continua, pero luego va
bastante más lejos.

- Un flujo de Git con pull requests dificulta mucho (e incluso impide según cómo se
use) la integración continua. Pero nadie te obliga a usar pull requests en GitHub.