Auditoría Ágil

El Pueblo lo Pide!!

Etna Estrella@anthenogeetnaestrella@gmail.com098700428

Ingeniera en sistemas, madre, hija, bailarina de salsa por default, amante de los viajes ya l a aventura, trabajando alrededor de 10 años en el mundo de la tecnología y el desarrollo de software, auditoría interna y de calidad, egresada de la maestría en auditoria de sistemas tecnológicos. Entre otros certificados y/o cursos:PMP, Iitsm-itil, Certified Scrum Master (CSM), TOGAF Arquitecta de Aplicaciones, ISO 27000, Auditoria Forense, Ethical Hacking, Data Mining y Control de Fraudes, Sistemas de Tiempo Real, Análisis de Riesgos.Algunos de mis retos: Constantemente facilitar el conocimiento técnico, simplificarlo, de tal manera que cualquier persona pueda entendernos a través de palabras simples, salir como desarrollador o técnico de un mundo de ceros y unos muchas veces de compañero de trabajo introvertidos con audífonos a ver la vida con la interacción sin tecnología

Agenda1. ¡¡Adopción Ágil Hoy!!2. Situación real del Desarrollo de Software3. Paradigmas Auditoría y Scrum4. ¡¡Evaluar Proyectos Hoy!!5. Evaluación Ágil! ¿Auditar Proyectos Basados en Scrum?

6. Evaluación a artefactos, indicadores, métricas y gestión

1. ¡¡Adopción Ágil Hoy!!

• ¿Cuántos usan Ágil?• ¿Desde cuándo se está usando Ágil?• ¿Quién conoce Ágil?• ¿Qué marcos de trabajo están siendo mas

usados?

1. ¡¡Adopción Ágil Hoy!!

73%

 Experiencia Organizacional

% de Organizaciones que están usando Desarrollo Ágil, 2011 un 80%, 2012 84%, 2013 88%

¿Cuántas? ¿Cuánto tiempo?

¿Quiénes Conocen Ágil?

(Version One 2013) (Version One 2014) “El estado del ágil”

Uso de Metodologías Agiles

1. ¡¡Adopción Ágil Hoy!!• Del trabajo de titulación “Análisis de los Factores que Intervienen

en el Ámbito de la Dirección que Afectan al Desempeño de los Proyectos de Desarrollo de Software a la Medida" (Molina, 2014), de 28 empresas encuestadas relacionadas al Sector Bancario en el 2012.

Metodologías de Desarrollo de Software que se Utilizan

RIESGOS

Ciclo de Vida del SoftwarePLANEACIÓN ESTRATÉGICA

Análisis

Diseño

Codificación

Pruebas y Control de Cambios

Paso a Producción

Mantenimiento y Evolución

Definición de Necesidades

No se disponen de recursos exclusivos para pruebas de funcionalidad y calidad

No se aplica metodologías de QA

Aprobación, Socialización y Uso de Nuevos Procesos y Metodologías

Proyección de Arquitectura de Hardware y Software según Planificación Estratégica

Codificación

Con 8 desarrolladores se atiende el 22% de las Necesidades registradasAtención del 100%

de las Necesidades registradas

Incremento de área de QA

Ejecución de Pruebas Según Metodologías de Control de Calidad

Cambios de información directos en Base de Datos de Producción

Reportes Recurrentes Dentro de una Plataforma

Cambios a la base desde sistema con seguimiento y auditoria

2. Situación real del Ciclo Desarrollo de Software vs IdealCICLOS DESARROLLO DE SOFTWARE

Pasos a producción sin aprobaciones o documentación necesaria para roll back

RIESGOS

Ciclo de Vida del Software

En mejoraPLANEACIÓN ESTRATÉGICA

Análisis

Diseño

Codificación

Pruebas y Control de Cambios

Paso a Producción

Mantenimiento y Evolución

Definición de Necesidades

2. Situación real del Ciclo Desarrollo de Software vs IdealMetodologías utilizadas en el Desarrollo de Software

3. Paradigmas Auditoria y Scrum• ¿Qué hace la auditoría en los proyectos de desarrollo

de Software, según…?

3. Paradigmas Auditoria y Scrum• ¿Qué busca realmente la auditoría en los proyectos

de desarrollo de Software?

Evaluar fortalezas y debilidades. Detectar oportunidades para la mejora continua. Realizar seguimiento de la eficacia de las acciones preventivas y

correctivas. Evaluar nivel de desempeño. Genera confianza a los directivos, usuarios, y clientes. Optimiza las relaciones internas, externas y del clima de trabajo. Disminuye los costos de la mala calidad (reprocesos, rechazos, reclamos,

entre otros). Genera un balance de los riesgos, identificarlos. Detectar vulnerabilidades. Apoya la toma de decisiones. Prevenir Errores

3. Paradigmas Auditoria y Scrum• Scrum prohíbe documentar!! , ¿Es auditable?

No puedes someter, ni obligar, ni imponer al equipoLa documentación !!...... ??

Agile Uthopy

No es auditable es imposible

3. Paradigmas Auditoria y Scrum• Scrum prohíbe documentar!! , ¿Es auditable?

No puedes someter, ni obligar, ni imponer al equipoLa documentación !!...... ??

Agile Uthopy

No es auditable es imposible

3. Paradigmas Auditoría y Scrum

WIN!! WIN!!

• Scrum vs Auditoría

Valores, Pilares Fundamentales:

TransparenciaInspección

ADAPTACIÓN

Genera confianza a los directivos, usuarios, y clientes. Optimiza las relaciones internas, externas y del clima

de trabajo.

Objetivos de ControlPruebas de Cumplimiento

y/o SustantivasANÁLISIS DE RIESGOS

EVALUACIÓN ÁGIL

4. !!Evaluar Proyectos Hoy!!

3. Paradigmas Auditoría y Scrum• Principios ScrumCOD. PRINCIPIOS MANIFIESTO ÁGIL SCRUM OBJETIVO DE EVALUACION

PMA1

Nuestra mayor prioridad es satisfacer al cliente mediante

la entrega temprana y continua de software con valor.

PMA1.1 Satisfacer al cliente.

PMA1.2 Entregar temprana y continuamente de software con valor agregado y que cubra la necesidad real de cliente.

PMA2

Aceptamos que los requisitos cambien, incluso en etapas

tardías del desarrollo. Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.

PMA2.1 Facilitar la oportunidad de cambio de alcance.

PMA3

Entregamos software funcional frecuentemente, entre dossemanas y dos meses, con preferencia al periodo de tiempo más corto posible.

PMA3.1 Entregar funcionalidad completa dentro de periodos cortos.

PMA4

Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.

PMA4.1 Mantener comunicación efectiva, trabajar en equipo, establecer la sinergia entre el área de negocio, el área de desarrollo y todos los interesados.

PMA5

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.

PMA5.1 Mantener al equipo motivado.

PMA5.2 Establecer un entorno adecuado para la ejecución del trabajo.

PMA6

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.

PMA6.1 Preservar la comunicación directa del equipo y con el equipo.

3. Paradigmas Auditoría y Scrum• Principios ScrumCOD. PRINCIPIOS MANIFIESTO ÁGIL SCRUM OBJETIVO DE EVALUACION

PMA1

Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor. PMA1.1 Satisfacer al cliente.

PMA7 El software funcionando es la medida principal de progreso. PMA7.1 Entregar un producto con funcionalidad completa en cada

entrega y dentro de los criterios de aceptación del cliente..

PMA8

Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.

PMA8.1 Validar la velocidad de desarrollo constante.

PMA9

La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.

PMA9.1 Mantener equipos capacitados en las competencias necesarias para la implementación.

PMA9.2 Realizar diseños adecuados. (Enfoque arquitectura)

PMA10

La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.

PMA10.1 Organizar el trabajo según las necesidades del negocio.

PMA10.2

Ejecutar esfuerzo en función de lo necesario para el negocio, cubriendo alcances claros y entregando productos terminados.

PMA11

Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.

PMA11.1

Validar que las arquitecturas, requisitos y diseños sean realizados por el equipo auto – organizado.

PMA12

A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

PMA12.1

Preservar la retroalimentación entre los que conforman el equipo,

en intervalos regulares (tanto técnico como de negocio).

PMA12.2 Ejecutar acciones de mejora.

ÁREA DE DESARROLLO DE SOFTWARE

Eficacia de las medidas de control establecidas

objetivos de control

prácticas e

stándares

de contro

l en TI

Evaluar los p

rincip

ales

riesgos te

cnológicos

Evaluar y verificar la gestión

del área de Desarrollo

Validar si existen controles

para las fases de desarrollo

PC01 Gestionar Requisitos Funcionales y

Técnicos

PC02 Gestionar Análisis, Diseño, Construcción,

Pruebas e Implantación de Soluciones

PC03 Gestionar el Catálogo de Servicios de

TI

4. !!Evaluar Proyectos Hoy!!

Procesos de Control

DOMINIOSBAI02 Gestionar la Definición de RequisitosBAI03 Gestionar la Identificación y la Construcción de Soluciones

4. !!Evaluar Proyectos Hoy!!

Procesos Vs. Objetivos de ControlProcesosde Control Dominio Practica de Gestión /

Practica Clave

PC01 Gestionar Requisitos Funcionales y Técnicos

BAI02 Gestionar la Definición de Requisitos

BAI02.01Definir y mantener los Requerimientos técnicos y funcionales de negocio.

PC02 Gestionar Análisis, Diseño, Construcción, Pruebas e Implantación de Soluciones

BAI03 Gestionar la Identificación y la Construcción de Soluciones

BAI03.01Diseñar soluciones de alto nivel.BAI03.03Desarrollar los componentes de la soluciónBAI03.05Construir soluciones.

PC03Gestionar el Catálogo de Servicios de TI

BAI03 Gestionar la Identificación y la Construcción de Soluciones

BAI03.11 Definir los servicios TI y mantener el catálogo de servicios

 

4. !!Evaluar Proyectos Hoy!!

Procedimientos de PruebaBAI02.01 Definir y mantener los Requerimientos1. ¿Cuenta la institución con un repositorio de requerimientos actualizados? 2. Cuando existen cambios de alcance el equipo de desarrollo de Software implementa estos cambios una vez hayan sido registrados de manera formal?, cual es el documento o habilitante de aprobación?

4. !!Evaluar Proyectos Hoy!!Procesos Vs. Objetivos de ControlBAI02.01 Definir y mantener los Requerimientos1. Definir repositorio de requerimientos y el procedimiento de mantenimiento.2. Confirmar los criterios de aceptación de los requerimientos registrados.3. Registro de requerimientos y peticiones de cambios

Hallazgos

BAI02.01 Definir y mantener los Requerimientos1. Se confirma que los requerimientos no están siendo definidos dentro un repositorio, no existe ningún tipo de registro, registro no obligatorio en el sistema.2. El personal de desarrollo no está confirmando todos los criterios de aceptación necesarios en la entrega de la solución.

Evaluar los Riesgos

5. Evaluación Ágil, Auditar Proyectos Basados en Scrum

6. Evaluación a artefactos, indicadores, métricas y gestión

6. Evaluación a artefactos, indicadores, métricas y gestión

Evaluación Ágil, Auditar Proyectos Basados en Scrum

1.Evaluar Riesgos2.Definir Controles3.Recomendar4.Facilitar Implementación

Pasos para llevar una Auditoría Ágil• Una guía de auditoría permitirá al auditor:

– Identificar los entregables de proceso de un desarrollo de software basados en SCRUM para una evaluación de cumplimiento.

– Validar todas las etapas de un proyecto ejecutado con SCRUM para el relevamiento de las evidencias idóneas en una auditoría.

– Definir un proceso de auditoría de referencia que permita la evaluación de proyectos de desarrollo de software basados en SCRUM.

– Proponer métricas que permitan identificar el cumplimiento del proceso SCRUM y la salud de la gestión del proyecto SCRUM.

– Plantear elementos idóneos para la Gestión de Riesgos en proyectos de desarrollo de software basados en SCRUM.

– Correlacionar los indicadores de COBIT para la evaluación de proyectos de software con los artefactos e indicadores de un proyecto basado en SCRUM.

– Correlacionar las fases/ grupos de proceso de PMBOK con los de un proyecto SCRUM

– Brindar un objetivo claro y herramientas para la comprensión del contexto de un proyecto ágil y la evaluación eficiente del mismo.

Conclusiones• Las evaluaciones de proyecto de desarrollo de software basados en

marcos de trabajos agiles como SCRUM, pueden ser guiados y mapeados a marcos de trabajo COBIT 5 o CMMI.

• Con métodos de comparación y asociación es posible validar como las metodologías se interrelacionando y de esta manera es posible realizar evaluaciones sustentadas y consistentes al objetivo planteado.

• A futuro, de igual manera que se encuentran estandarizados los objetivos de control, y las metodologías de desarrollo de software con su gestión, es necesario normar y estandarizar los métodos de evaluación y auditoría para que estos no sean sujetos a un criterio por percepción, mucho menos de una percepción sin conocimiento.

"No es el más fuerte ni el más inteligente el que sobrevive, sino el más capaz de adaptarse a los cambios".Charles Darwin

“Tu peor enemigo no te puede dañar tanto como tus propios pensamientos. Ni tu padre, ni tu madre, ni tu amigo más querido, te pueden ayudar tanto como tu propia mente disciplinada”.Buda