Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOpsDays Cuba 2016: Calidad de software en la empresa de aplicaciones informaticas Desoft

DevOpsDays Cuba 2016: Calidad de software en la empresa de aplicaciones informaticas Desoft

Author: Lian Lisette Hurtado Linares
Summary:
Este trabajo parte del quehacer cotidiano de un grupo de especialistas encargado de la Calidad de software en la Empresa de Aplicaciones Informáticas Desoft, a raíz de deficiencias encontradas en esta labor dentro de la mencionada entidad. El objetivo principal es mostrar la estrategia seguida por la empresa, que contribuyó a unificar y estandarizar la labor diaria, apoyó sobremanera la gestión del conocimiento entre los implicados y favoreció la comunicación de trabajo entre los especialistas de calidad y los desarrolladores. Se exponen los excelentes resultados logrados en la revisión y liberación de productos de software, el aporte de esta actividad a la gestión de proyectos y al rompimiento de las complejas barreras que existen entre diferentes roles de un mismo equipo de trabajo.

DevOpsDays Cuba

October 21, 2016
Tweet

More Decks by DevOpsDays Cuba

Other Decks in Technology

Transcript

  1. Autor: Nombre: Lian Lisette Hurtado Linares. Especialista B en Ciencias

    Informáticas, (EP). Consultor y Especialista de Calidad. Centro de Trabajo: Empresa de Aplicaciones Informáticas Desoft. División Sancti Spíritus e-mail: [email protected]
  2.  Metodologías y Procedimientos de Trabajo.  Políticas de Precios.

     Estrategias de Mercado.  Líneas de productos. Políticas de informatización. Uso estandarizado de tecnologías. Estándares de Codificación. Herramientas de trabajo. Sistema Integrado de Gestión de la Calidad.
  3. Existía diversidad en Plataformas de Desarrollo. Estilos y Estándares de

    codificación. Herramientas de Colaboración. Diseño de interfaces. Estrategias de pruebas de Software.
  4. Como resultado…  Productos de software de baja calidad. 

    Incongruencia entre plataformas y poca interoperabilidad.  Estrategias de pruebas de software deficientes (carencia de pruebas de software).  Productos finales carentes de una imagen que los identificara entre sí o identificara la empresa.  Gran número de insatisfacciones e inconformidades por parte de los clientes.
  5. ARAGÓN, Neida. “Proceso para alcanzar el mejoramiento continuo en biofábricas”.

    Tesis de doctorado. Universidad Central de Las Villas, Santa Clara, Cuba, dic. 1999 GARCIA PEREZ, Ana. “EL PROCESO DE GESTION DEL CONOCIMIENTO EN EL SISTEMA DE INNOVACION DE PRODUCTOS INFORMATICOS”. Santa Clara, Cuba. 2016
  6. En contra…  Pertenecemos al ámbito de las PyMes. 

    Equipos pequeños de trabajo, (una misma persona cubre varios roles).  Generalmente se realizan desarrollos a la medida. A favor…  Procesos definidos y organizados.  Personal altamente calificado y comprometido.  Metodologías de desarrollo definidas.  Reutilización de código y arquitecturas.  Amplia gama de desarrollos.
  7. ¿Qué hacer?  Estandarizar el proceso de Desarrollo.  Incorporar

    al probador como un miembro más del equipo de desarrollo.  Establecer pruebas de Liberación a los productos de software que se desarrollan y se comercializan.  Definir estrategias de pruebas.  Definir tipos de pruebas para otros servicios.
  8. Estandarizar el proceso de desarrollo.  Estándares y estilos de

    codificación (lenguajes más usados).  Repositorio de íconos y plantillas para la aplicaciones.  Plantillas para la documentación de proyectos.
  9. Incorporar al probador como un miembro más del equipo de

    desarrollo. ¿Cómo involucrar ambos roles en las pruebas?  Herramientas colaborativas.  Pruebas Automatizadas.  Estilos y estándares de codificación.  Diseño de interfaces.  Repositorio de íconos y plantillas.  Superación en temas de Pruebas.
  10. Liberación de productos de software que se desarrollan.  Pruebas

    internas (productos que se desarrollan).  Expediente de Proyecto con los documentos a entregar y sus plantillas.  Expediente de Pruebas con los documentos a elaborar por los probadores.  Roles que intervienen en cada revisión e iteración.  Herramientas informáticas a utilizar.  Flujo de las revisiones y/o pruebas.
  11. Liberación de productos de software que se comercializan.  Pruebas

    a productos externos  Expediente de Proyecto.  Expediente de Pruebas.  Roles que intervienen en la revisión  Herramientas informáticas a utilizar.  Flujo de las revisiones y/o pruebas.  Tipos de Pruebas.  Scripts de la BD (arreglos, restauración y carga inicial).
  12. Estrategia de Pruebas. ¿Pruebas Funcionales? ¿Pruebas de Sistema? Diseño y

    ejecución de Casos de Pruebas a requerimientos funcionales.  Requerimientos Funcionales.  Carga.  Rendimiento.  Usuario.  Volúmen. tipos de pruebas.
  13. Niveles de pruebas. Modelo V Código Pruebas unitarias Líneas de

    Código Diseño (Bajo nivel) Pruebas de integración de componentes Diseño detallado Diseño Funcional (Alto nivel) Pruebas de Sistemas. Requisitos del Software Definición de requisitos Pruebas de Aceptación. Requisitos del Cliente
  14. Modelo V Código Pruebas unitarias Líneas de Código Diseño (Bajo

    nivel) Pruebas de integración de componentes Diseño detallado Diseño Funcional (Alto nivel) Pruebas de Sistemas. Requisitos del Software Definición de requisitos Pruebas de Aceptación. Requisitos del Cliente Niveles de pruebas.
  15. Definir herramientas de apoyo a las pruebas. Herramientas de apoyo.

     Listas de chequeo al código.  Listas de chequeo al sistema.  Lista de chequeo a la documentación y otros entregables.  Casos de pruebas prediseñados para ser reutilizados.
  16. Definir tipos de pruebas para otros servicios. Otros Servicios 

    Despliegue de productos.  Soporte.  Operación Asistida.  Procesamiento de datos.  Servicios especializados. • Pruebas piloto. • Comprobación del servicio. • Encuestas de satisfacción. • Centro de Contacto (Soporte).
  17. Definir tipos de pruebas para otros servicios. Pruebas Piloto •

    Instalación. • Cambio entre versiones. • Errores corregidos. • Funcionalidades agregadas. • Cambios solicitados.
  18. Centro de Contacto • Solicitudes de Cambios. • Evolución de

    productos. • Gestión de la Configuración. • Servicio de Post-Venta.
  19. A favor En contra Aumento de la Calidad del Producto

    Final. Detección de errores + temprano  menos costosa. Disminución del re-trabajo. Mejora en la Documentación de Proyectos. Incremento de la satisfacción del usuario final. Alargamiento de la cadena de Producción. Aumento de interlocutores en cada fase de revisiones. Posible resistencia al cambio entre los implicados.
  20. ¿Qué se logró? Días 0 5 10 15 20 25

    30 35 40 1 2 3 4 5 Iteraciones Tiempo de Iteraciones antes después
  21. ¿Qué se logró? 0 5 10 15 20 25 30

    35 40 45 50 Aplicaciones de escritorio Aplicaciones Web Documentación Diseño 24 50 25 5 11 28 6 1 Cantidad de no-conformidades de una aplicación para una iteración de pruebas Antes Después
  22. ¿Qué se logró? 54,17 44 76 80 Aplicaciones de escritorio

    Aplicaciones Web Documentación Diseño PORCIENTO DE DISMINUCIÓN DE NO- CONFORMIDADES
  23. ¿Qué se logró? 0 3 6 9 12 15 18

    21 24 27 30 Errores de Código Errores de Interfaz Errores de sistema. Documentación Diseño Cantidad de no-conformidades reportadas según roles Desarrollador Probador Resto del equipo Totales
  24. Principales Resultados  Estrategia de Pruebas y Liberación de software

    definido e implementado.  Grupo de liberación de software con alcance nacional.  Se contribuyó de manera sustancial con el conocimiento tácito y explícito del personal.  Aumento de nivel de satisfacción de los clientes (internos y externos).  Surgimiento de Proyectos I+D+i.
  25.  Proyecto “Metodología Diseño Interfaces Productos DESOFT”  Identidad Visual

    a los productos.  Repositorio de íconos.  Repositorio de Plantillas.  Proyecto “Caliges”  Gestión de la Calidad por procesos.  Planificación de pruebas a servicios.  Emisión de Boletín (Trimestral).  Cursos de Capacitación.  Encuentros nacionales entre homólogos. Surgimiento de Proyectos I+D+i