reduciendo el riesgo operativo de liberaciones a producción con cmmi e itil

Reduciendo el Riesgo

Operativo de Liberaciones a

Producción con CMMI e ITIL

2

This document may contain brand names, text, graphics or images which are registered trade marks, trade marks, service marks, or trade names of third parties which are owned by their respective owners.© Copyright 2011 Global Lynx, Inc. All rights reserved.This material is property of Global Lynx, Inc (www.globallynx.com). Reproduction in whole or in part is prohibited.

Agenda

Introducción

Calidad y mejora basada en modelos de referencia

Servicios de TI, ciclo de vida y aportación al negocio

Gestión del servicio de TI a través de CMMI e ITIL

Problemática del Desarrollo de software

Minimizar el riesgo operativo para liberaciones a producción.

Integración de una solución

Preguntas

3


Introducción

A lo largo de los años los equipos de trabajo de desarrollo y operación han convividode una manera informal, con pocas reglas de convivencia por lo que hay muchashistorias sin final feliz sobre migraciones a producción o cambios de versiones.

En esta conferencia se mostrarán los beneficios de integrar CMMI con ITIL para que lasliberaciones a producción dejen de ser un riesgo operativo significativo para el negocioal fortalecer las pruebas, la validación, la aceptación y la planeación del despliegue delas liberaciones sin descuidar el cumplimiento de las regulaciones y las prácticas deauditoría para evitar interrumpir los servicios del negocio.

4


Calidad y Mejora Basada En Modelos de

referencia

5


Implementación de Mejores prácticas

Beneficios de Implementación de un modelo

Lenguaje común

Visión integral .

Basada en procesos y practicas probadas yseleccionadas.

Marco de referencia para dar Priorizar acciones yrealizar evaluaciones

Facilita el Benchmarking

El enfoque de la calidad a lo largo de todo el proceso de generación de un servicio,desde la planeación estratégica hasta la operación de la iniciativa.

Durante el proceso de definición de la estrategia.Durante el proceso de DiseñoDurante el proceso de transición.Durante la administración del día a día.Durante el cierre.

6


Servicios de TI, ciclo de vida y aportación al

negocio

7


Concepto de Servicio

Utilidad

Garantía

Servicio:Forma de entregar valor a clientes mediante la creación de resultados que el cliente desea lograr sin la responsabilidad de costos y riesgosespecíficos.

¿Sirve para el propósito?(Soporta el desempeño) (Resuelve restricciones)

¿Se puede usar?(Está disponible)(Tiene la capacidad)(Tiene continuidad)(Es seguro)

+

ValorValor creado =

8


Aplicabilidad de los servicios de TI

Servicio de Negocio Servicio de TI

Habilita

Utilidad

Garantía

Valor

Utilidad

Garantía

Valor

Cadenas de valor

Las Aplicaciones se encapsulan en servicios de TI que habilitan a los servicios de Negocio

SeguridadContinuidad

CapacidadDisponibilidad

Administración

Gente

Conocimiento

Información

Aplicaciones

Infraestructura

Proceso de Negocio

utilidad

garantía

workflow

ValorServicio deNegocio

9


Servicios de TI Punta-a-Punta

CÓMPUTOPERSONAL

SERVIDORES REDES APLICATIVOS& BASE DE

DATOS

Servicio de TI

Los Sistemas de Información

(Aplicativos) son parte de los

servicios de TI

10


Ciclo de vida de un servicio

Estrategia:

Definir la estrategia para identificar las oportunidadesde proveer nuevos servicios que agreguen valor alcliente (Nuevos Mercados, Nuevos Clientes).

Desarrollar la oferta

Desarrollar los activos estratégicos que diferenciarána la Organización

Prepararse para la ejecución

Evaluar el riesgo de construir nuevos servicios yestimar de manera confiable de los recursos queserán necesarios para hacer una realidad laestrategia.

1. El Diseño consiste en :Estructuración de un Servicio de TI,incluye su arquitectura, procesos,políticas, documentación y lonecesario para cubrir con losrequerimientos presentes y futurosdel negocio.Identificación y definición de losestándares y regulaciones aplicables.

El foco estará dirigido a:Satisfacer necesidades del negocioQue puedan ser desarrollados entiempo y costo.Definir procesos efectivos yeficientes para construir,transicionar, operar, soportar ymejorar los servicios.Definir la infraestructura de TI queasegure la utilidad y garantía de losservicios.Definir las métricas y los métodosde análisis para evaluar laefectividad y eficiencia de losprocesos y los servicios.

Dentro de la Transición se contempla:

Estructuración de un Servicio de TI,incluye su arquitectura, procesos,políticas, documentación y lo necesariopara cubrir con los requerimientospresentes y futuros del negocio.

Identificación y definición de losestándares y regulaciones aplicables.

Planear y administrar los recursos paraliberar exitosamente un nuevo servicio ocambio al servicio en el ambiente deproducción, de acuerdo a los costos,calidad y tiempos estimados.

Asegurar que los impactos nopronosticados sean mínimos durante laproducción de servicios, en la operación yen la organización que brinda el soporte.

Tiene como objetivos

Coordinar y llevar a cabo lasactividades y procesos requeridos quepermitan entregar y administrar elservicio a los usuarios y clientes delnegocio de acuerdo a los niveles deservicio.

Administrar el día a día de latecnología que es usada para la entregay soporte de los servicios.

Monitorear el rendimiento de lasactividades cotidianas que entregan ysoportan los servicios.

Consiste en :

Entender los objetivos de negocio dealto nivel.

Obtener una foto, exacta e imparcialde dónde se encuentra la organizaciónen este momento.

Entender y acordar las prioridades demejora.

Detallar el plan de la CSI para lograruna provisión de servicios de mayorcalidad.

Verificar que las mediciones y lasmétricas existan.

Mantener el dinamismo en la mejorade la calidad.

11


Gestión del servicio de TI a través de

CMMI e ITIL

12


Gestión de Servicios de TI-Enfoque en servicios (ITIL)-

Servicio de TI

Solicitud deCambio

Diseño del servicio de TI

Transición del servicio de TI

Servicio de TIcambiado

Servicio de TILiberado

Operación delServicio


Diseño delServicio

Transición delServicio

Catálogo de ServiciosNivel de ServicioCapacidadDisponibilidadContinuidad del Servicio de TISeguridad de la InformaciónAprovisionamiento

Planificación y soporte de la transiciónCambiosActivos del servicio y configuracionesLiberaciones y desplieguesValidación y pruebas del servicioConocimientoEvaluación

13


Gestión de Servicios de TI -Desarrollo de Software (CMMI)-

Servicio de TI

Solicitud deCambio

Diseño del servicio de TI

Transición del servicio de TI

Servicio de TIcambiado

Servicio de TILiberado



Diseño delServicio

Transición delServicio

Planeación y monitoreo de proyectosDesarrollo y administración de Reqs.Administración de Proveedores

Planeación y monitoreo de proyectos (PP, PMC)Administración de RiesgosSolución técnicaIntegración de productoVerificación ValidaciónAdministración de proveedores

Medición y AnálisisAseguramiento de calidadAdministración de la configuración

Liberaciones y despliegues

14


Liberaciones y Despliegues

Describe la porción de servicio o infraestructura de TI que es liberada junta, de acuerdo a la política de liberación de la organización.

● El nivel apropiado de unidad de liberación para cada activo de servicio o componente de servicio debería ser definido considerando:

– La cantidad y facilidad de cambio necesarios para liberar y desplegar una unidad de liberación.

– La cantidad de recursos y tiempo necesario para construir, probar, distribuir e implementar una unidad de liberación.

– La complejidad de interfaces entre la unidad propuesta y el resto de los servicios e infraestructura de TI.

– El almacenamiento disponible en los ambientes de construcción, pruebas, distribución y producción.

● Las liberaciones deberían tener una identificación única de acuerdo al esquema definido en la política de liberación.

15


-CMMI-Áreas de Proceso por Nivel de Madurez

Nivel Enfoque Áreas de proceso

5. Optimizado Mejora continua de procesos

Organizational Performance Management (OPM)Causal Analysis and Resolution (CAR)

4. AdministrativoCuantitativamente

Administración cuantitativa basada en resultados

Organizational Process Performance (OPP)Quantitative Project Management (QPM)

3. Definido Estandarización de Procesos

Requirements Development (RD)Technical Solution (TS)Product Integration (PI)Verification (VER)Validation (VAL) Organizational Process Focus (OPF) Organizational Process Definition (OPD)Organizational Training (OT)Integrated Project Management (IPM) Risk Management (RSKM)Decision Analysis and Resolution (DAR)

2. Administrado Administración básicade Proyectos

Requirements Management (REQM)Project Planning (PP)Project Monitoring and Control (PMC)Supplier Agreement Management (SAM)Measurement and Analysis (MA)Process and Product Quality Assurance (PPQA)Configuration Management (CM)

1. Desempeñado

5. Optimizado

4. Administrado Cuantitativamente

3. Definido

2. Administrativo

1. Repetible

16


Problemática del Desarrollo de software

17


Principales causas de problemas en proyectos actuales

1. No se analiza a fondo cual es el problema real, solo se crea una solución.

2. El cliente no se involucra lo suficiente para el entendimiento del problema y creación de una solución.

3. Se suponen muchas cosas que para la operación del negocio no son la mejor solución.

4. Se va directamente a los requerimientos del producto sin buscar y seleccionar la mejor solución de acuerdo

al problema.

5. Falta de comunicación entre las diferentes áreas.

6. Se hace un análisis muy simple que no permite visualizar cosas importantes para el proyecto en la

conceptualización para presentar la propuesta.

7. No se lleva control sobre la dependencia y la rastreabilidad de los requerimientos, casos de uso, desarrollos y

casos de prueba, lo que hace más difícil identificar todo lo que está relacionado con un requerimiento.

8. La documentación actual no está bien dividida para poder reutilizarse en mantenimientos posteriores.

9. Las validaciones del cliente solamente se realizan al finalizar con la etapa de pruebas.

10. No se hace una verificación de los requerimientos y casos de uso.

11. Falta de herramientas, guías, estándares, técnicas, criterios de clasificación y calidad para la administración y

el desarrollo de requerimientos.

18


Problemática de Desarrollo de Software-Inversión-

20

200

Co

sto

rela

tivo

de r

ep

ara

ció

n

UATTestPruebasCodificaciónDiseñoAnálisis

0

Mantenimiento

1-2

10

5

50El tiempo que no se

invierte en requerimientos se

gasta en retrabajos (costo x200)

Etapa en la que los errores en requerimientos son descubiertos

19


Problemática-Causas y Efectos-

• Los sistemas surgen por solicitudes de gente que no alinea sus necesidades con las del negocio.

• Se pierde el rastro desde la primera definición de requerimientos hasta la implementación.

• En caso de tercerizar, se desarrollan RFPs (privado) o bases de licitación (público) en donde no se

establece un alcance claro, Objetivos de negocio a satisfacer, Entregables, Criterios de aceptación,

Caso de desarrollo .

• La falta de una metodología y personal capacitado en calidad de software hace que la cantidad de

errores que llegan al negocio reste confianza a los usuarios en los sistemas.

• No se sabe si erogar o no el dinero comprometido para la fase debido a que no se tiene una

percepción real del valor ganado con la entrega.

• La falta de documentación, no permite darle mantenimiento a los sistemas cuando se requiere.

• Monitoreo y control insuficiente

20


Minimizar el riesgo operativo para liberaciones a producción

-Integración de una solución-

21


Caso de Negocio de Alto Nivel

• Reducción de costos de desarrollo y mantenimiento

– Mejora en la productividad

– Menos re-trabajo

• Genera ahorros

• Contribuye a la generación

de ingresos

• Mejora en la satisfacción del cliente

– Reducción de defectos en productos

– Mejoras mesurables en confiabilidad y calidad • Repetición de negocios

• Incremento en las ventas

• Reducción del ciclo de desarrollo

– Mejora en el desempeño del proceso • Mejora en el tiempo de entrega al mercado

• Beneficios/bonos de

entrega temprana

• Mejora en el equipo de trabajo

– Moral del equipo mejorada

– Equipos integrados

• Reducción en la rotación del

personal y costos de entrenamiento

• Mejora en ventajas competitivas

22


Las organización de Nivel 3 de CMMI Gastan 20% menos en esfuerzo de desarrollo y tiempo, así como 50% menos en pruebas del código

20%

Retrabajo

Retrabajo

Requerimientos

4.5 Meses

Diseño

6.6 Meses

Código

8.8 Meses

Pruebas

9.4 Meses

CMMI Level 1

Requerimientos

4.0 Meses

Diseño

6.0 Meses

Código

6.8 Meses

Pruebas

3.75 Meses

CMMI Level 3

Las organizaciones de nivel 3 entregan 80% menos defectos a producción resultando en ahorros significativos y menos re-trabajo que generan hasta 45% mas productividad

45%

Mejora en productividad

23


• Software de mejor calidad

– 39%1 a 80%2 disminución de defectos post liberación

• Aumento de la productividad

– 35%1 a 65%2 ganancia en Productividad

• Retorno de la Inversión (ROI)

– Promedio de ROI de 5:11

1: CMU/SEI-94-TR-013 Benefits of CMM-Based Software Process Improvement: Initial Results, Software Engineering Institute

2: Measuring Software Process Improvement, Capers Jones, Software Productivity Research, 2010

Hacer las cosas correctamente tiene sus ventajas

24


Dimensiones de Calidad

Funcionalidad

Usabilidad

Confiabilidad

Rendimiento

Soportabilidad

Probar el funcionamiento adecuado para cada escenario de uso

Probar el aplicativo desde la perspectiva de comodidad para el usuario

Probar que el aplicativo trabaje de manera consistente

Probar tiempos de respuesta del aplicativo y respuestas a carga

Probar la habilidad de mantener y soportar el aplicativo en producción

25


Extensión de las Dimensiones de Calidad

Ejemplos de Pruebas que soportan las dimensiones de calidad:

•Accesibilidad

•Compatibilidad

•Concurrencia

•Benchmarking

•Eficiencia

•Pruebas de Instalación

•Pruebas de Carga

•Performance Profile

•Portabilidad

•Escalabilidad

•Seguridad

•Pruebas de Configuración

•Look & Feel

26


¿Cómo definir Técnicas a implementar?

Al momento de diseñar la Estrategia de Verificación se debe pensar en 5 dimensiones:

•Ejecutores de Pruebas: ¿Quién realizará la verificación?

•Cobertura: ¿Cuáles son los productos de trabajo a verificar?

•Problemas Potenciales: ¿Porqué se está verificando?

•Actividades: ¿Cómo se realizan las verificaciones?

•Evaluación: ¿Cómo determinar los resultados de verificación?

Evaluar:

• Al momento de seleccionar las más adecuadas se debe tomar en cuenta la completitud de la

verificación.

• No existe “el método correcto”, ya que la selección depende completamente de los productos a

verificar.

• Si se define mezclar las técnicas, la cobertura de la verificación será mayor y mas “completa”.

27


Tipos de Pruebas ..1

Técnica Descripción Problemaspotenciales

Fortalezas PuntosCiegos

Caja negra Probar cada función de manera independiente

No siempre las funciones trabajan de manera aislada sino que dependen de otras funciones, existe interacción entre ellas.

Fácil de implementar a medida que se van creando las funciones; Análisis adecuado de cada elemento programado.

La interacción entre funciones

Análisisequivalente

Cuando se tienen demasiados casos de prueba a ejecutar, se utiliza una selección estratégica de casos de prueba que ejemplifiquen a la mayoría de los casos

La selección de los datos a probar no es la adecuada; los valores a ser verificados no son los mas representativos ni los de mayor valor.

Detecta los defectos de mayor peso con un set de datos relativamente corto; El aprovechamiento es mejor dada la cantidad baja de pruebas a ejecutar.

Los datos no son los mas adecuados ó no se encuentran dentro de los límites para datos de entrada.

Pruebas basadas en Especificación

Verificar la conformidad con cada especificación, cada requerimiento documentado, características, etc

Inconsistencia entre las especificaciones y lo implementado

Defensa crítica en contra de reclamos, pérdida de credibilidad con el cliente; Efectiva para la administración del alcance; Reduce los costos de soporte

Todos aquellos asuntos que hayan sido mal especificados ó documentados

28


Tipos de Pruebas .. 2


Fortalezas Puntos Ciegos

Basadas en riesgos

Definir, priorizar y refinar las pruebas en base a los elementos que pueden presentar el mayor riesgo

Riesgos no identificados

Priorización óptima; Pruebas muy fuertes en base al riesgo identificado

Difícil medir la cobertura alcanzada; Algunos ejecutores de pruebas realizan las pruebas de manera subjetiva.

Pruebas de stress

Detectar fallas que ocurren al momento de sobrecargar el producto e identificar los cambios que deben ser efectuados

Manejo de errores de manera inadecuada.

Expone debilidades que el software podría presentar en producción; Expone riesgos de seguridad.

Debilidades que no puedan ser visibles al momento de utilizar solamente stress

Pruebas de Regresión

: Efectos negativos después de realizar un cambio ó defectos no solucionados correctamente

Costos bajos de ejecución; Pruebas adecuadas a las configuraciones

Costos bajos de ejecución; Pruebas adecuadas a las configuraciones

Costo de mantener las pruebas de regresión

29


Tipos de Pruebas ..3


Fortalezas Puntos Ciegos

Exploratorias Simultáneamente aprender acerca del producto y de las estrategias de pruebas para exponer los defectos del mismo

Todo aquello no previsto por las técnicas de pruebas planeadas

Basado en la perspectiva del cliente; Encontrar problemas ó defectos no identificados por otras técnicas.

Mientras menos conocimiento del aplicativo se tenga, menos riesgo se prueba; Limitado a la falta de conocimiento de cada ejecutor de pruebas

Pruebas de escenarios

Crear casos de prueba que reflejen el uso real del producto

Interacciones complejas que ocurren en producción ejecutadas por usuarios expertos.

Puede manejar situaciones que son difíciles de modelar; Expone fallas que ocurren a través del tiempo.

Debe ser bien definida para alcanzar un buen porcentaje de cobertura.

Estocásticas o aleatorias

Pruebas de alto volumen con nuevos casos cada ejecución

Mal funcionamiento y excepciones en las computadoras.

Probar diversas características del producto variando los datos a manera de evaluar el manejo de grandes volúmenes de información

Todo aquello que no haya sido programado ya que es ejecutado por máquinas

30


Formato para Reporte de Problemas

Los formatos ó formas típicas de reporte de problemas incluyen la mayoría de los campos que seenlistan a continuación:

•Número de reporte

•Reportado Por

•Fecha de reporte

•Nombre de Producto

•Número de Release

•Identificador de Build

•Se pudo reproducir:

•Severidad:

•Prioridad:

•Corrección Propuesta

•Solución probada por

•Comentarios

31


Validación

32


Importancia

• Se cerciora de “construir lo correcto”.

• Se demuestra que el producto satisface a los clientes y trabajará de manera eficiente en el ambiente previsto.

• Aplica para todos los aspectos del producto (requerimientos y/oentrenamiento) en cualquiera de los ambientes previstos (por ej.Operación, Soporte, Manufactura)

• Típicamente los clientes identifican las definiciones del producto,descripciones y/o requerimientos de una manera muy débil ódesordenada por lo que la validación ayuda a entender lasnecesidades.

• La validación minimiza “sorpresas” en el despliegue operativo.

33


• Las pruebas de usabilidad involucran al usuario pidiéndole trabajar con el producto y observarlas respuestas de dicho producto.

• Se recomienda realizar este tipo de pruebas para involucrar al usuario tan rápido como seaposible en el ciclo de desarrollo del producto.

• Estas pruebas son un proceso para identificar las posibles discrepancias entre las interfacesprevistas del producto y las especificaciones de los usuarios.

• Se centra primordialmente en evaluar la presentación del producto y no tanto en sufuncionalidad, como:

Accesibilidad

Respuesta

Eficiencia

Comprensible

Técnicas de Validación-Pruebas de Usabilidad-

34


• Las pruebas de sistema son complejas; ya que no existen metodologías para diseñarlos casos de prueba.

• Su objetivo es demostrar que el producto NO cumple con los requerimientos yobjetivos originales para los que fue creado.

• El diseño de los casos de prueba a realizar requiere de mucha creatividad y siempremanteniendo la perspectiva del usuario.

• En estas pruebas se mezclan varios tipos de técnicas ya consideradas en verificación

tales como: Pruebas de volumen, de carga y stress, de seguridad y rendimiento.

Técnicas de Validación-Pruebas de sistema-

35


• Estas pruebas se refieren al proceso de comparar el producto final con lasnecesidades de los usuarios finales.

• Son siempre realizadas por el parte del usuario ó un representante del mismo;tomando en cuenta los criterios de aceptación definidos desde el inicio del proyecto.

• Para éstas pruebas se requiere de generar la versión ALFA para una primerevaluación del producto en el cual se involucran diversos tipos de verificación y unavez resueltas los defectos encontrados se genera la versión BETA que podrá serentregada al usuario para su evaluación.

• En estas pruebas el usuario define el periodo de pruebas del producto terminado.

Técnicas de Validación-Pruebas de Aceptación-

36


Análisis y seguimiento de resultados

37


• Un mecanismo efectivo de seguimiento y mejora para las actividades de verificacióny validación se lleva a cabo a través del análisis de los resultados, y para obtener elmejor resultado se recomienda establecer una serie de indicadores que permitan

establecer los lineamientos.

Análisis y mejora de resultados

38


Preguntas?

39


Datos de Contacto

Claudia Lizbeth Patiño Bahena

Process Consultant

Authorized PSP Instructor

[email protected]

reduciendo el riesgo operativo de liberaciones a producción con cmmi e itil

Technology