View
113
Download
3
Category
Preview:
Citation preview
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
Recommended