Transferencia

Transferencia Diseño Desarrollo Estabilización Soporte

Gestión de
Requerimientos
 PROCEDIMIENTO DE INTEGRACIÓN UTILIZADO POR SOFTWARE FACTORY HUNDRED

Para las pruebas

Github
4 A partir de develop se crea una rama de revisión para
master 4 develop integrar los requerimientos que pasarán a pruebas
review/sprint# internas y sprint review (pruebas de analista(s) y/o
develop [ej: review/sprint9] Product Owners).
feature/Id Jira 5 A partir de la rama de revisión se clona el repositorio
[ej: feature/GR-#####] localmente y se compila (build) y despliega (deploy) en
Este esquema representa el review/sprint# ambiente de pruebas.
procedimiento de integración de [ej: review/sprint9]
• Si hay observaciones sobre el requerimiento se
requerimientos de SWF del proyecto 1) [feature/GR-#####] Merge a [review/sprint#] corrigen en la rama origen (ej: feature/GR-#####)
Mejora Continua (GR) alineado a • Si hay observaciones sobre la revisión integrada se
corrigen sobre su rama (ej: review/sprint9)
estándar Belcorp (Gitflow). • Si se cambia el alcance de la revisión y no se quieren
5 1) Clone perder los ajustes de la integración anterior se
2) Build puede crear una nueva revisión derivada (ej: review/
Para atender el flujo se usarán como 3) Deploy sprint9.1)
base las ramas principales master y Cuando se culmina la revisión y se formaliza la entrega a
6
develop existentes en Github. review/sprint#
pre producción el código de la rama de revisión pasa a
develop y de este último se origina un release (ej:
6 [ej: review/sprint9]
release/v1.0).
PROCEDIMIENTO DE INTEGRACIÓN UTILIZADO POR SOFTWARE FACTORY HUNDRED CON PROYECTOS
develop
Para el desarrollo • V[1].0: el primer dígito representa cambios
sustanciales en la aplicación.
develop • v1.[0]: el según dígito representa revisiones en la
1 develop release/v#.# aplicación (correlacionado al sprint review).
feature/Id Jira [ej: release/v1.0] • v1.0.[25]: el tercer dígito representa un correlativo
[ej: feature/GR-#####] para el ajuste en el release (solo se usa dentro de Desarrollo Pruebas Producción
bugfix).
QA temporal
1) Clone release/v#.# 7 Durante las pruebas de un release a pre producción si se 1 Proyecto.Master 4 Proyecto.QA
7 7 [ej: Proyecto.QA-aaaammdd]
[ej: release/v1.0] presenta un defectos a subsanar se genera una rama QA temporal QA temporal de SW Factory
bugfix/v#.#.X bugfix (ej: bugfix/v1.0.25). Github Id requerimiento [ej: Req1]
[ej: Proyecto.QA-aaaammdd] [ej: QA-aaaammdd]
[ej: bugfix/v1.0.25]
2 1) Pull ...
Donde: Master
2) Commit ... 1) Clone 1) [Req#####] Merge a QA temporal ... 1) Tag
3) Push ... • v1.0.[25]: el tercer dígito representa un correlativo
para el ajuste en el release. Proyecto.Master
QA temporal de SW Factory
Proyecto.QA 1) Pull ... 1) Clone 8 Master
[ej: QA-aaaammdd]
2 2) Commit ... 5 2) Build
Para producción 3) Push ... 3) Deploy Master + QA

1 A partir de develop se crea una rama para el

requerimiento Jira usando la nomenclatura feature/
Id.
De esta rama se clonará al repositorio local.
2 Acciones como Pull y Push (Commit) sobre la rama
creada serán realizadas durante todo el desarrollo las
veces necesarias.
Este esquema representa el 3 6 9 Master Master
release/v#.# 8 La rama release certificada es replicada en la rama
procedimiento de integración
master (merge) y etiquetada (tag) con la versión
8 [ej: release/v1.0]
correspondiente al pase a producción. de requerimientos de SW Id Jira [ej: GR-#####] + Proyecto.Master
master Factory con proyectos en
9 La rama master actualizada es replicada a la rama
paralelo. 1) Merge a branches activos ...
develop de donde se originarán los nuevos desarrollos
1) Tag master con versión v#.# de requerimientos.
Las ramas Proyecto.Master y
1 A partir de Proyecto.Master se crea una rama para 4 A partir de Proyecto.QA se crea una rama temporal 7 La rama QA temporal certificada del proyecto es
10 La rama develop es replicada también (merge) a todas Proyecto.QA serán
9 master el requerimiento usando su Id o nombre corto. De para integrar los requerimientos que pasarán a replicada en la rama QA temporal de SW Factory
las ramas de requerimientos activas (con desarrollo en aperturadas al inicio del esta rama se clonará al repositorio local. pruebas internas y/o pruebas de analista(s). (merge).
curso). proyecto con la última versión
develop
2 Acciones como Pull y Push (Commit) sobre la 5 A partir de la rama temporal se clona el repositorio 8 La rama QA temporal de SW Factory es replicada en la
Asimismo, las ramas de requerimientos cerrados (que
en Producción.
nueva rama son realizadas durante todo el localmente y se compila (build) y despliega (deploy) en rama principal Master (merge) esta es replicada a la
fueron entregados en el último release) son eliminadas desarrollo en reiteradas ocasiones. ambiente de pruebas. rama QA de donde se formarán futuras integraciones.
10 develop
en el repositorio remoto y local. Esta rama de pruebas es recreada cada vez que existan
feature/Id Jira 3 Cuando se culmina un desarrollo se inicia el actualizaciones por corrección de los requerimientos 9 La rama Master es replicada también a todas las ramas
[ej: feature/GR-#####] procedimiento de integración para pruebas involucrados. de requerimientos de SW Factory que se encuentren
internas y/o pruebas de analista(s). activas y a la rama Proyecto.Master.
1) Merge a requerimientos activos 6 Cuando se culminan las pruebas satisfactoriamente se
2) Delete requerimientos cerrados (release) da inicio al procedimiento de pase a Producción.
 PROCEDIMIENTO DE INTEGRACIÓN UTILIZADO POR SOFTWARE FACTORY HUNDRED

Para las pruebas

Github
3 A partir de develop se crea una rama de revisión (ej:
master 3 develop review/sprint9) para integrar los requerimientos que
review/sprint# pasarán a pruebas internas y sprint review (pruebas de
develop [ej: review/sprint9] analista(s) y/o product owners).
feature/Id Jira 4 A partir de la rama de revisión se clona el repositorio
[ej: feature/GR-#####] localmente y se compila (build) y despliega (deploy) en
Este esquema representa el review/sprint# el ambiente de pruebas.
procedimiento de integración de [ej: review/sprint9]
• Si hay observaciones sobre el requerimiento se
requerimientos de SWF del proyecto 1) [feature/GR-#####] Merge a [review/sprint9] corrigen en la rama origen (ej: feature/GR-#####)
Mejora Continua (GR) alineado a • Si hay observaciones sobre la revisión integrada se
estándar Belcorp (Gitflow). corrigen sobre su rama (ej: review/sprint9)
• Si se cambia el alcance de la revisión y no se quieren
4 1) Clone
perder los ajustes de la integración anterior se
2) Build
Para atender el flujo se usarán como puede crear una nueva revisión derivada (ej: review/
3) Deploy
sprint9.1)
base las ramas principales master y
5 Cuando se culmina la revisión y se formaliza la entrega a
develop existentes en Github. review/sprint# pre producción el código de la rama de revisión pasa a
5 [ej: review/sprint9] develop y de este último se origina un release (ej:
release/v1.0).
develop
Para el desarrollo
• V[1].0: el primer dígito representa cambios
sustanciales en la aplicación.
develop
• v1.[0]: el segundo dígito representa revisiones en la
1 develop release/v#.# aplicación (correlacionado al sprint review).
feature/Id Jira [ej: release/v1.0] • v1.0.[25]: el tercer dígito representa un correlativo
[ej: feature/GR-#####] para el ajuste en el release (solo se usa dentro de
bugfix o hotfix).
1) Clone release/v#.#
6 6 Durante las pruebas de un release a pre producción si se
[ej: release/v1.0]
bugfix/v#.#.X presenta un defecto a subsanar se genera una rama
[ej: bugfix/v1.0.25] bugfix (ej: bugfix/v1.0.25).
2 1) Pull ...
2) Commit ... Donde:
3) Push ... • v1.0.[25]: el tercer dígito representa un correlativo
para el ajuste en el release.

Para producción
1 A partir de develop se crea una rama para el
requerimiento Jira usando la nomenclatura feature/Id
Jira (ej: feature/GR-#####).
release/v#.# 7 La rama release certificada es replicada en la rama
De esta rama se clonará al repositorio local.
7 [ej: release/v1.0] master (merge) y etiquetada (tag) con la versión
2 Acciones como Pull y Push (Commit) sobre la rama correspondiente al pase a producción.
master
creada serán realizadas durante todo el desarrollo las 8 La rama master actualizada es replicada (merge) a la
veces necesarias. rama develop de donde se originarán los nuevos
1) Tag master con versión v#.# desarrollos de requerimientos o proyectos.
9 La rama develop es replicada también (merge) a todas
master las ramas de requerimientos o proyectos (features) con
8
desarrollo en curso (activas).
develop
Asimismo, las ramas de requerimientos (features) y
sprints (reviews) cerradas porque fueron entregadas en
9 develop el último release son eliminadas en el repositorio
remoto y local.
feature/Id Jira
[ej: feature/GR-#####]

1) Merge a requerimientos activos

2) Delete requerimientos cerrados (release)

Para incidentes hotfix Para producción

1 master hotfix/Id Jira 3 La rama hotfix certificada es replicada en la rama

3 [ej: hotfix/GR-#####] master (merge) y etiquetada (tag) con la versión
hotfix/Id Jira
master correspondiente al pase a producción agregando el
[ej: hotfix/GR-#####]
tercer dígito que representa un correlativo para el
hotfix (ej: v1.0.1).
1) Clone
1) Tag master con versión v#.#.# La rama master actualizada es replicada (merge) a la
4
rama develop de donde se originarán los nuevos
1) Pull ... master desarrollos de requerimientos o proyectos.
2 4
2) Commit ... 5 La rama develop es replicada también (merge) a todas
3) Push ... develop las ramas de requerimientos activos (con desarrollo en
curso) incluyendo proyectos relacionados.

5 develop Asimismo, las ramas de hotfixes cerradas son

A partir de master se crea una rama para el incidente feature/Id Jira eliminadas en el repositorio remoto y local.
1
Jira usando la nomenclatura hotfix/Id Jira (ej: hotfix/ [ej: feature/GR-#####]
GR-#####).
De esta rama se clonará al repositorio local. 1) Merge a requerimientos activos
2) Delete hotfix cerrado
2 Acciones como Pull y Push (Commit) sobre la rama
creada serán realizadas durante todo el desarrollo las
veces necesarias.
 PROCEDIMIENTO DE INTEGRACIÓN UTILIZADO POR SOFTWARE FACTORY HUNDRED CON PROYECTOS

Para las pruebas

Github
develop
feature/Id proyecto
Este esquema representa el procedimiento
de integración de requerimientos de SWF
del proyecto Mejora Continua (GR) con
proyectos ejecutándose en paralelo y
alineados a estándar Belcorp (Gitflow).
Para atender el flujo se usará como base la
rama principal develop existente en Github
y una rama del tipo feature para el proyecto
(usando su codename, ej: feature/planit2).
Para el desarrollo
3 feature/Id proyecto
review/Id proyecto-sprint#
[ej: review/planit2-sprint3]
feature/Id Jira proyecto
[ej: feature/PRY1-#####]
review/Id proyecto-sprint#
[ej: review/planit2-sprint3]
1) [feature/PRY1-#####] Merge a [review/planit2-sprint3]
4 1) Clone
2) Build
3) Deploy
review/Id proyecto-sprint#
5 [ej: review/planit2-sprint3]
feature/Id proyecto
3 A partir de feature/Id proyecto se crea una rama de
revisión (ej: review/planit2-sprint3) para integrar los
requerimientos del proyecto que pasarán a pruebas
internas y sprint review (pruebas de product owner y/o
key users).
4 A partir de la rama de revisión se clona el repositorio
localmente y se compila (build) y despliega (deploy) en
ambiente de pruebas.
• Si hay observaciones sobre el requerimiento de
proyecto se corrigen en la rama origen (ej: feature/
PRY1-#####)
• Si hay observaciones sobre la revisión integrada se
corrigen sobre su rama (ej: review/planit2-sprint3)
• Si se cambia el alcance de la revisión y no se quieren
perder los ajustes de la integración anterior se
puede crear una nueva revisión derivada (ej: review/
planit2-sprint3.1)
Cuando se culmina la revisión y se formaliza la entrega a
5
ambiente UAT el código de la rama de revisión pasa a
feature/Id proyecto y de este último se origina un
release de proyecto (ej: release/planit2-v2.0).

feature/Id proyecto • V[2].0: el primer dígito representa cambios

1 feature/Id proyecto release/Id proyecto-v#.# sustanciales en la aplicación para el proyecto.
[ej: release/planit2-v2.0] • v2.[0]: el según dígito representa revisiones en la
feature/Id Jira proyecto
aplicación (correlacionado al sprint review de
[ej: feature/PRY1-#####]
proyecto).
release/Id proyecto-v#.# • v2.0.[25]: el tercer dígito representa un correlativo
1) Clone para el ajuste en el release (solo se usa dentro de
6 [ej: release/planit2-v2.0]
bugfix/Id proyecto-v#.#.X bugfix o hotfix).
[ej: bugfix/planit2-v2.0.25] 6 Durante las pruebas de un release en ambiente UAT si
2 1) Pull ...
2) Commit ... se presenta un defecto a subsanar se genera una rama
3) Push ... bugfix de proyecto (ej: bugfix/planit2-v2.0.25).

Donde:
• v2.0.[25]: el tercer dígito representa un correlativo
para el ajuste en el release.
1 A partir de feature/Id proyecto se crea una rama para
el requerimiento Jira usando la nomenclatura feature/ Para producción
Id Jira proyecto (ej: feature/PRY1-#####).
De esta rama se clonará al repositorio local.
release/Id proyecto-v#.# 7 La rama release de proyecto certificada es replicada en
2 Acciones como Pull y Push (Commit) sobre la rama
7 [ej: release/planit2-v2.0] la rama activa de revisión de mejora continua (merge)
creada serán realizadas durante todo el desarrollo las
review/sprint# con la finalidad que pase a pruebas junto con
veces necesarias.
[ej: review/sprint9] requerimientos de SWF que se entregarán en conjunto
a producción. Desde este punto se sigue un
… procedimiento de mejora continua procedimiento normal de revisión de mejora continua
en SWF.
8 Durante las pruebas de un release a pre producción si
release/v#.# se presenta un defecto a subsanar asociado al proyecto
8 [ej: release/v2.0] se genera una rama bugfix (ej: bugfix/planit2-v2.0.25).
bugfix/Id proyecto-v#.#.X
[ej: bugfix/planit2-v2.0.25] Donde:
• v2.0.[25]: el tercer dígito representa un correlativo
para el ajuste en el release.
9 1) Delete requerimientos de proyecto cerrados 9 Cuando un release llega a producción las ramas de
(release) requerimientos de proyecto (features) y sprints
(reviews) cerrados porque fueron entregados en el
último release son eliminadas en el repositorio remoto
y local.

Para incidentes hotfix Para producción

1 master hotfix/Id Jira proyecto 3 La rama hotfix certificada es replicada en la rama

3 [ej: hotfix/PRY1-#####] master (merge) y etiquetada (tag) con la versión
hotfix/Id Jira proyecto
master correspondiente al pase a producción agregando el
[ej: hotfix/PRY1-#####]
tercer dígito que representa un correlativo para el
hotfix.
1) Clone
1) Tag master con versión v#.#.#
4 Desde este punto se sigue un procedimiento normal de
pase a producción de mejora continua responsabilidad
1) Pull ... … procedimiento de mejora continua de SWF.
2 4
2) Commit ...
3) Push ...

1 A partir de master se crea una rama para el incidente

Jira asociado al proyecto usando la nomenclatura
hotfix/Id Jira proyecto (ej: hotfix/PRY1-#####).

De esta rama se clonará al repositorio local.

2 Acciones como Pull y Push (Commit) sobre la rama

creada serán realizadas durante todo el desarrollo las
veces necesarias.
 Gestión de Requerimientos HUNDRED Management Framework

Generación Ejecución Estabilización Entrega Gestión Integral de Servicio

Mantenimiento Integral de Aplicaciones Gestión Administrativa y

Modelo de Gobierno
de Recursos
Requerimientos Aplicaciones
Ciclo de Vida de Aplicaciones Arquitectura de
Soporte Tecnológico y
Soluciones, Patrones y
Plataforma ALM
Prácticas

Gestión de Gestión de Gestión de

Demanda Configuración Cambios

HUNDRED Management Framework

Transferencia Operación

Planificación Transición Estabilización Operación Devolución

Duración total

Aceptación de Firma de Servicio

Inicio
propuesta contrato estable

Mantenimiento Integral de Aplicaciones

Personalización de FW
Gestión de Requerimientos
SETUP HUNDRED Management Framework
Medición de Servicio
SLAs
SLOs

Proveedor actual es responsable de HUNDRED es responsable de

servicio servicio
 Comité de Gestión

Planificación | Seguimiento | Mejora Continua

Gerente de Gerente de
Servicio Servicio

Dueños de Producto Coordinador(es) de

Demanda

Coordinador(es) de Coordinador(es) de
Desarrollo Desarrollo

HUNDRED Management Framework

 Transferencia Operación

Gestión de
Planificación Transición Estabilización Operación Devolución
Servicio
Gestión de
contrato

Formalización de Formalización de
Formalización de
cartera de demanda inicial
contrato de servicio
aplicaciones (horas/mes)

Identificación de Identificación de
Planificación de
dueños de procedimientos y
Diseño de servicio

transición de servicio
aplicaciones (POs) protocolos existentes

Gestión de
Aplicaciones
(Gestión) Planificación de
Planificación de
continuidad de
comunicaciones
servicio
conocimiento
Gestión de

Planificación de base
de datos de
conocimiento
configuración
Gestión de

Planificación de
repositorios de
configuración

Transferencia Operación

Gestión de
Planificación Transición Estabilización Operación Devolución
Servicio
Soporte de
transición

Formalización de Diagnóstico inicial de

equipos de aplicaciones en
transferencia cartera

Planificación de Planificación de Planificación de

Informe de diseño de
control de cambios integración de entrega y despliegue
Diseño de servicio

operación
de requerimientos requerimientos de requerimientos

Planificación de
continuidad de
Gestión de servicio
Aplicaciones
(Gestión)
conocimiento
Gestión de

Configuración de
base de datos de
conocimiento
configuración
Gestión de

Configuración de
repositorios de
configuración
Gestión de nivel
de servicio

Planificación de SLAs
(SLO)

Transferencia Operación Transferencia Operación

Gestión de Gestión de
Planificación Transición Estabilización Operación Devolución Planificación Transición Estabilización Operación Devolución
Servicio Servicio

Variación de demanda
Gestión de

Gestión de
demanda

demanda

Planificación de
Seguimiento a la Redimensión de Planificación de
Cambio aceptado demanda
demanda equipo demanda (liberación)
(asignación)

Cambio aceptado
requerimientos
Gestión de

Gestión de requerimientos

Seguimiento a la Resolución de Gestión de cambios

atención de cambios sobre sobre
requerimientos requerimientos requerimientos

Gestión de Cambio aceptado Cambio aceptado

Aseguramiento

Aplicaciones
de calidad

Seguimiento a (Gestión) Generación de Ejecución de Estabilización de Entrega de

Gestión de protocolos de calidad requerimiento requerimiento requerimiento requerimiento
Aplicaciones
(Gestión)
Aseguramiento
de calidad

Planificación de Planificación de Planificación de Revisión de

Informe de mejora Revisión de Revisión de entrega
control de cambios integración de entrega y despliegue estimación
Mejora continua

de operación cobertura de pruebas de requerimiento

de requerimientos requerimientos de requerimientos (observada/escalada)
configuración
Gestión de

Planificación de Revisión de Sincronización de

Planificación de
continuidad de repositorios de cambios en
comunicaciones
servicio configuración repositorio principal
Gestión de nivel
de servicio

Planificación de Planificación de Planificación de

Medición de SLAs Planificación de SLAs Informe de mejora
control de cambios integración de entrega y despliegue
Mejora continua

(SLO) (SLO) de operación

de requerimientos requerimientos de requerimientos

Planificación de
Planificación de
continuidad de
comunicaciones
servicio
Gestión de nivel
de servicio

Medición de SLAs Planificación de SLAs

(SLO) (SLO)

Transferencia Operación

Gestión de
Planificación Transición Estabilización Operación Devolución
Servicio
Gestión de
demanda

Planificación de
culminación de Liberación de equipo
demanda
requerimientos
Gestión de

Planificación de Seguimiento a la
100% Requerimientos Informe de cierre de
liquidación de liquidación de
liquidados operación
requerimientos requerimientos

Gestión de
Aseguramiento

Aplicaciones
de calidad

(Gestión) Seguimiento a
protocolos de calidad
conocimiento
Gestión de

Transferencia de
conocimiento a Transferencia completada
cliente
 Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos

Gestión de
demanda Registro de
Hot fix Planificación
requerimiento

Gestión de Diagnóstico de
Causa-Efecto
Aplicaciones completitud y
100% identificada
Estimación
(desarrollo) ambigüedad
Análisis

Por identificar

Análisis de
impacto

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Gestión de
demanda

Cambio aceptado Planificación

Gestión de
cambios

Gestión de cambio Cambio identificado

Cambio aceptado
Gestión de
Análisis

Transferencia de Resolución de
Aplicaciones know-how observaciones
(desarrollo)
Desarrollo

Diseño de
Desarrollo Pruebas internas
solución
configuración
Gestión de

Sincronización de
Configuración de
cambios en
espacio de desarrollo
repositorio

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Gestión de
demanda

Cambio aceptado Planificación

Gestión de
cambios

Gestión de cambio Cambio identificado

Cambio aceptado

Gestión de
Análisis

Transferencia de Resolución de
Aplicaciones know-how incidentes
(desarrollo)
Desarrollo

Diseño de Desarrollo de
Pruebas internas
solución correcciones
configuración
Gestión de

Sincronización de
Documentación de
cambios en
entrega a pruebas
repositorio

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Gestión de
cambios

Cambio identificado Gestión de cambio

Incidentes resueltos
Análisis

Resolución de
incidentes
Desarrollo

Gestión de
Desarrollo de
Aplicaciones correcciones
Pruebas internas
(desarrollo)
configuración
Gestión de

Sincronización de
Sincronización de
Informe de entrega a cambios en
cambios en
producción repositorio principal
repositorio
(main)
conocimiento
Gestión de

Retroalimentación de
base de datos de
conocimiento
Gestión de
demanda

Registro de cierre de
entrega
 Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos

Gestión de
demanda Registro de
Hot fix Planificación
requerimiento
Gestión de
Aplicaciones
(Pruebas de
Software) Análisis de
Análisis

Por identificar escenarios de Estimación

prueba

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Gestión de
demanda

Planificación
Cambio aceptado
Gestión de
cambios

Gestión de cambio Cambio identificado

Gestión de Cambio aceptado

Aplicaciones Resolución de
(Pruebas de observaciones
Software)
Análisis

Transferencia de Identificación de Diseño de casos de

know-how casos de prueba prueba
configuración
Gestión de

Sincronización de
Identificación de
cambios en
espacio de pruebas
repositorio

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Gestión de
demanda

Planificación
Cambio aceptado
Gestión de
cambios

Gestión de cambio Cambio identificado

Cambio aceptado
Gestión de
Análisis

Aplicaciones Transferencia de Resolución de

(Pruebas de know-how incidentes
Software)
Pruebas de
software

Identificación de Diseño de casos de Ejecución de casos

casos de prueba prueba de prueba
configuración
Gestión de

Sincronización de
Configuración de
cambios en
espacio de pruebas
repositorio

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Gestión de
demanda

Planificación

Incidentes resueltos
Gestión de
cambios

Cambio identificado Gestión de cambio

Gestión de
Análisis

Aplicaciones Resolución de
Hot fix
(Pruebas de incidentes
Software)
Pruebas de
software

Informe final de Identificación de Diseño de casos de Ejecución de casos

pruebas casos de prueba prueba de prueba
configuración
Gestión de

Sincronización de
cambios en
repositorio
 Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos

Desarrollo Revisión de
estimación de
Gestión de desarrollo
Aplicaciones
(Aseguramiento de
Pruebas de

Calidad)
software

Revisión de
estimación de
pruebas

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Desarrollo

Revisión de código
Revisión de
de cambios
cobertura de pruebas
sincronizados

Revisión de
Gestión de configuración

repositorio de
Gestión de desarrollo
Aplicaciones
(Aseguramiento de
Calidad) Revisión de
repositorio de
pruebas
Pruebas de
software

Revisión de
cobertura de casos
de pruebas

Gestión de
Generación Ejecución Estabilización Entrega
Requerimientos
Desarrollo

Revisión de código
Revisión de entrega a
de cambios
producción
sincronizados

Revisión de Revisión de
Gestión de configuración

repositorio de repositorio principal

Gestión de desarrollo (main)
Aplicaciones
(Aseguramiento de
Calidad) Revisión de
repositorio de
pruebas
Pruebas de
software

Revisión de informe
final de pruebas