b3t10 - Metodologías y Control Versiones Flashcards
Metríca3 es la metodología orientada a procesos creada en la Administración
Qué roles hay en Métrica3?
Directivo
Jefe de Proyecto
Consultor
Analista
Programador
Indica 3 metodologías orientadas a procesos
SSADM
Merise
Metrica3
Indica 3 metodologías orientadas a objetos
En qué metodología se unifica?
Booch Method
OMT
OOSE Jacobson
Se unifican en
RUP -> Rational Unified Process
De qué tipo es la metodología RUP?
Iterativa incremental.
Es un proceso de desarrollo dirigido por casos de uso y centrado en la arquitectura. Quiere decir que primero se prepara la arquitectura y luego se hacen iteraciones. En cada iteración se coge un conjunto de casos de uso y se hacen todas las fases (cada fase podrá tener distinto peso en la iteración, dependiendo de qué iteración sea).
Qué versión abierta de la Eclipse Foundation hay de RUP?
OpenUP
Otro ejemplo de UP, en versión agile sería AUP - Agile Unified Process
Qué tres procesos tiene Metrica3?
Planificación (PSI) del sistema de información
Desarrollo (DSI) del sistema de información
Mantenimiento (MSI) del sistema de información
En qué otros 5 procesos se divide el proceso de Desarrollo (DSI) de Metrica3?
EVS - Estudio de viabilidad
ASI - Analisis
DSI- Diseño
CSI - Construcción
IAS - Iplantación y aceptación
En qué se dividen los procesos en Métrica3? Y estas a su vez?
Se dividen en actividades
Las actividades se dividen en tareas
Cómo se llaman las partes de Métrica3 que son comunes a todos los procesos? Cuáles son?
Se llaman Interfaces
Calidad
Gestión de proyectos
Gestión de la configuración
Seguridad
4 Valores del Manifiesto Ágil
Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan
12 Principios del Manifiesto Ágil
- Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua de software con valor.
- Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
- Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al período de tiempo más corto posible.
- Los responsables del negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.
- Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
- El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara.
- El software funcionando es la medida principal de progreso.
- Los procesos ágiles promueven el desarrollo sostenido. Los promotores, desarrolladores y usuarios debemos mantener un ritmo constante de forma indefinida.
- La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
- La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
- Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
- A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para, a continuación, ajustar y perfeccionar su comportamiento en consecuencia.
Metodologías ágiles
XP
SCRUM
FDD
KANBAN
SCRUM
Tipo: iterativa incremental
Roles:
- Cerdos: Product owner, Scrum master (facilitador), Scrum team (5-9) personas con habilidades transversales
- Gallinas: Stakeholder
Prácticas y artefactos
- Product backlog
- Sprint backlog
- Burndown chart
- Sprint Planning
- Daily scrum (15 min)
- Sprint review (al final del sprint, 1h)
- Sprint retrospective (revisión y mejora, 1h)
Xtreme Programing
- Potencia relaciones interpersonales.
- Historias de usuario (se agrupan en epicas) (se desgranan en tareas)
- Roles: Programador, cliente, encargado de pruebas (tester), encargado de seguimiento (tracker), entrenador (coach), consultor, gestor (big boss)
- Prácticas: Programación en parejas, refactoring, estiman los técnicos, el cliente prioriza, integración contínua, cliente in situ, max 40h /semana, pruebas unitarias primero (TDD), entregas pequeñas
Productos de integración contínua
Pipelines
Construcción
Repositorios de codigo fuente
Repos binarios
Análisis código
Test unitarios
Runtime
- Pipelines -> Jenkins, Spinnaker (Netflix)
- Construcción -> Maven
- Repositorios de codigo fuente -> GIT, SVN, TFS (teams foundation)
- Repos binarios -> Artifactory(jfrog), Nexus(sonatype), Apache Archiva
- Análisis código -> SonarQube
- Test unitarios -> JUnit
- Runtime -> JBOSS
CI -> hasta test
CD -> hasta deploy
Qué son los siguientes conceptos GIT
history
commit
.gitignore
HEAD
history -> los commits apuntan al commit anterior, formando un historial de lo que ha ocurrido
commit: snapshot
.gitignore -> se añade lo que se quiere que quede fuera del control de versiones
HEAD -> Puntero que apunta al último commit
Qué hacen los siguientes comandos de git
git status
git init
git clone url
git remote -v
git remote add / rm / rename
git log
git add
git commit -m nombre
git commit –ammend
git branch nombreRama
git checkout
git diff
git merge
git tag
git push
git fetch
git pull
git reset
git rebase
git blame
git mv
git status -> comprobar el estado del repositorio local, enumera los archivos que se han preparado, los que están sin preparar y los archivos sin seguimiento.
git init -> crear repositorio git en local desde cero. La rama principal se llama master, aunque se puede cambiar. Se le suele nombrar también main, trunk, development … El repo está vacío pero se crea un directorio oculto llamado “.git” con los metadatos del repositorio local
git clone url -> crea un repositorio local a partir de un repositorio remoto. Te crea por defecto la rama origin/main (o master, o development, … según el producto)
git remote -v -> indica las conexiones remotas con otros repositorios que hay configuradas en /git/config
git remote add / rm / rename -> añade una conexión a un repo remoto en git/config // la borra // renombra una
git log -> te muestra el histórico de commits, con su hash
git add -> añade desde el working directory al staging area, haciendo que ya tenga “seguimiento”
git commit -m nombre -> hace un commit poniéndole
git commit –ammend -> para sustituir el último commit, por uno nuevo, cuando nos hemos dejado algo olvidado en ese
git branch nombreRama-> crea una rama
git checkout -> moverse de rama. Con -b te crea la rama y te mueve a ella. Las ramas están en el Local Repo y se actualiza en el Working directory, saltando el staging area
git diff -> mostrar diferencias entre commits
git merge -> mezclar dos ramas
git tag -> para crear etiquetas sobre commits
git push -> para mezclar tu rama master del repo local con la del repo remoto
git fetch -> te trae los metadatos del repo remoto, y sabes si estás actualizado o no
git pull -> se baja el repo remoto al repo local, a la rama master
git reset -> deshacer commits
git rebase -> para mezclar commits entre ramas
git blame -> visualizar los metadatos de autor adjuntos a líneas específicas confirmadas en un archivo
git mv -> renombrar un fichero
Qué tres tipos de git reset hay?
git reset –soft -> deshace el commit en repo local tal y lo deja en el staging area, como si no se hubiese hecho el git commit
git reset –mixed -> deshace el commit en repo local tal y lo deja en el working directory, como si no se hubiese hecho el git add
git reset –hard -> deshace el commit y elimina los ficheros
cuando se hace un reset de un commit, hay que tener en cuenta que se hace de ese commit y de todos los posteriores. No se puede “extraer” un commit de en medio
Qué tres espacios hay en el repositorio local de git? Para qué es cada uno?
Working directory
Staging area (o index) -> zona para tener lo que se querrá commitear
Local repo
