SDLC OPERATION

MODEL
 ETAPAS

Entradas componente más pequeño de su software que puede probar se debe realizar un
seguimiento del número de pruebas unitarias que pasan o fallan durante un ciclo
 Modelo de versionamiento de código de desarrollo.
Salidas
 Pipelines de integración continua
Ejecutar compilaciones
 Todo proceso de compilación debe integrar continuamente (CI) el software
desarrollado por el equipo de proyecto, crear artefactos candidatos para
Integración
lanzamiento(release) y ejecutar pruebas automatizadas en esos artefactos para
detectar problemas. Continua
 Los artefactos generados en el proceso de compilación (CI) se deben versionar en
la herramienta de gestión de artefactos de Periferia IT Group (Nexus).
 Las librerías o dependencias de aplicación se deben descargar del repositorio de
dependencias de Nexus de Periferia IT Group. Procesos
 La selección de la tecnología de compilación está sujeta a la necesidad del
proyecto (Ant, Maven, Gradle, etc).
1. Ejecutar
Ejecutar pruebas unitarias
compilaciones
 El equipo de desarrollo debe implementar pruebas unitarias en el proyecto, el uso 2. Ejecutar pruebas
del framework para la construcción de las pruebas unitarias debe estar sujeta a
la tecnologia o lenguaje de programación del
unitarias
proyecto(NUnit para .Net, JUnit para Java)
 La cobertura de pruebas unitarias debe ser mínimo del 70% del código.
 Toda prueba unitaria debe ser automatizada en el pipeline de aplicación para su
ejecución dentro del flujo de integración continua y detección temprana de
errores en código.
 Métrica Pruebas unitarias aprobadas / reprobadas: Puesto que la unidad es el
 ETAPAS

Generar Reporte
 Si la prueba presenta error debe informar en el reporte el punto de falla de la
prueba.
 El informe de pruebas debe ser legible y de fácil entendimiento.
 Las pruebas deben generar como resultado un informe en formato .xml para la
interpretación del resultado con la herramienta de integración continua. Integración
Notificación de la nueva versión en calidad
 Las versiones de software liberadas por el equipo de desarrollo pasan por un
Continua
proceso de entrega continua que deberá notificar la entrega de una nueva
versión implementada y disponible en ambiente de QA, esta notificación llegará por
medio de correo electrónico notificando al equipo de calidad.

Procesos
3. Generar Reporte
4. Notificación de la
nueva versión en
calidad
 ETAPAS

Entradas entre el cliente y Periferia.

 Características del producto  Uso del porcentaje de memoria: El uso de demasiada memoria en un host puede
provocar un rendimiento deficiente de la aplicación, mientras que el uso de muy
Salidas poca memoria de manera constante puede significar que está infrautilizando
recursos costosos, especialmente en la nube. (evaluar herramienta para medir el
 Configuración de entorno de acuerdo a Características del producto porcentaje de memoria)
 Scripts de infraestructura como código
Instalar herramientas de terceros
 Según se requiera para aprovisionar el ambiente se deberá realizar instalación
de herramientas de terceros, al inicio del proyecto se deberá identificar quien
Configuración
estará a cargo de la licencia para dichos productos.
Configurar el entorno del producto
del entorno
 Los entornos DEV, TEST / QA y STAGE pueden definirse para compartir el mismo
equipo físico, pero deben aislarse lógicamente en instancias separadas, de modo
que el acceso al sistema para un entorno no permita el mismo acceso a otro
entorno en el mismo hardware. Procesos
 A nivel de plataforma, base de datos y red, los desarrolladores no tienen acceso
a entornos distintos al entorno DEV asignado. 1. Instalar
 Solo el personal del equipo de pruebas tiene acceso a su entorno TEST / QA herramientas de
asignado.
terceros
 Se debe garantizar que el entorno de DEV y QA cumpla con características
semejantes a las que se espera tener en entorno de PROD, incluyendo (Sistema 2. Configurar el
operativo, características mínimas de hardware, herramientas y versiones de
software)
entorno del
 El acceso al entorno PROD a nivel de la aplicación está limitado a aquellos producto
usuarios autorizados a utilizar el sistema de producción, el equipo de DEV o QA
solo podrá realizar pruebas en dichos entornos cuando exista un previo acuerdo
 ETAPAS

Entradas rechazo por parte de calidad para la entrega de una versión al cliente.
 Release generado desde CI
Salidas
Despliegue/
 Ejecución del despliegue y testing continuo automatizados
Ejecutar despliegues en desarrollo / calidad
Testing Continuo
 La ejecución de los despliegues se debe realiza por medio de pipelines, los
pipelines deben estar escritos en código de forma declarativa y versionados en
un repositorio.
 Un entorno TEST / QA está configurado para replicar (lo más fielmente posible) el Procesos
rendimiento del entorno PROD para el que se implementan o modifican
soluciones. 1. Obtener Historias de
 Métrica Tiempo de implementación y frecuencia de implementación: Cuánto usuarioEjecutar
tiempo se tarda en implementar el software y con qué frecuencia lo
implementa. (evaluar herramienta con la cual se hace el despliegue y hacia donde despliegues en
se realiza el despliegue)
desarrollo / calidad
Pruebas del sistema manuales y automáticas
2. Pruebas del sistema
 Se debe ejecutar el plan de pruebas manuales y automáticas diseñadas por el área
de QA acorde a las historias de usuario y características del producto manuales y
Aprobación o Rechazo de calidad para generar versión al cliente automáticas
 El equipo de calidad debe informar el resultado de las 3. Aprobación o
pruebas ejecutadas cuando se realiza un release, deberá notificar al equipo de
proyecto y scrum master por medio de un correo electrónico la certificación de Rechazo de calidad
calidad para la entrega de producto al cliente.
para generar versión
 El equipo de calidad debe informar constantemente al equipo de desarrollo con el
fin de corregir los errores encontrados antes de tomar una decisión final de al cliente
 ETAPAS

Entradas herramientas como Grafana y/o App Dynamics

 Métrica: Objetivos de nivel de servicio (SLO): Los SLO son objetivos que los equipos
establecen y los clientes sobre lo que pueden esperar de su sistema en términos de
disponibilidad, rendimiento, tasas de error y cualquier otra cosa que acuerde
medir. Monitoreo
Supervisar los entornos de desarrollo y calidad
Continuo
 Todos los cambios de construcción / configuración / integración de emergencia
deben probarse en todas las fases suficientes para garantizar un rendimiento de
calidad sin agregar perturbaciones adicionales a los sistemas actuales.
Métricas claves
 Métricas de defectos: Rastrear la cantidad de problemas o errores informados
Procesos
para el software en producción o los problemas que surgen durante la
implementación del software.
1. Supervisar los
 Métrica Uso de porcentaje de CPU: Medida crítica para rastrear la disponibilidad
entornos de
de su aplicación, por ello se mide el tiempo de proceso total que la CPU (o su
núcleo) que usan realmente para procesar datos. El valor máximo de uso de la
desarrollo y
CPU es, por lo tanto 100 %, para calcularlo se compara el tiempo general de
proceso con el tiempo real de ejecución, de esta manera a medida que aumenta
calidad
el uso de la CPU, puede ocurrir que la aplicación experimente cierta degradación, 2. Métricas claves
lo que podría generar problemas en la experiencia.
3. Detectar y
 Métrica Promedio de carga: Utilizar esta métrica para medir la cantidad
promedio de procesos, subprocesos o tareas del sistema que están esperando y solucionar
listos para la CPU. Monitorear el promedio de carga puede ayudar a comprender
si su sistema está sobrecargado o si tiene procesos que consumen demasiados problemas de
recursos.
entornos
Detectar y solucionar problemas de entornos
 De acuerdo a las practicas de monitoreo continuo sobre los entornos DEV Y TEST se
espera habilitar la detección y solución temprana de errores apoyándonos en
 ETAPAS

Entradas respuesta de las aplicaciones y servicios web. Específicamente, mide la relación

entre tiempos de respuesta satisfactorios y tiempos de respuesta insatisfactorios o
 Seguimiento directo a los entregables realizados en cliente peores
 Feedback formal e informal del cliente en relación a los entregables  Métrica Uso y tráfico de aplicaciones: Después de una implementación, se verifica
si la cantidad de transacciones o usuarios que acceden a su sistema parece
Salidas normal.
 Planes de acción de mejora continua
 Métricas claves Seguimiento
Formalizar entrega al cliente
 Se debe diligenciar el formato de acta de entrega con la aprobación de las
Continuo
diferentes áreas (DEV, QA, DEVOPS).
 Se debe entregar el formato de acta de entrega al cliente por el medio de
comunicación previamente establecido con el mismo (Presencial, Correo Electrónico,
otros) Procesos
Métricas claves
1. Formalizar
 Numero de actas de entrega firmadas y aceptadas por el cliente VS Numero de
actas devueltas por el cliente entrega al
Detectar y solucionar problemas de la entrega cliente
 Métrica Tiempo medio de detección (MTTD): Rastrea la cantidad de tiempo entre 2. Métricas claves
el inicio de un problema y la detección del problema, idealmente en qué momento
se toman algunas medidas, se debe mantener el MTTD lo más corto posible. 3. Detectar y
 Métrica Tiempo medio de recuperación (MTTR): MTTR realiza un seguimiento del solucionar
tiempo promedio que se tarda en reparar un componente defectuoso en el
sistema, desde el momento en que se detecta la falla hasta el punto en el que el problemas de la
sistema vuelve a funcionar normalmente.
entrega
 Métrica Apdex: Medida de satisfacción de nuestros clientes con el tiempo de