Usando el aseguramiento de la calidad como una herramienta que nos permita innovar.

Presentación del tema: "Usando el aseguramiento de la calidad como una herramienta que nos permita innovar."— Transcripción de la presentación:

1 Usando el aseguramiento de la calidad como una herramienta que nos permita innovar

2

3 Sobre nosotros La compañía
Vector es una compañía dedicada a la consultoría y al desarrollo e implantación de soluciones avanzadas, en el entorno de nuevas tecnologías IT. El desarrollo de nuestras soluciones soporta diferentes modelos de producción con foco en la industrialización de los procesos de implantación. Nuestro modelo de operación permite cubrir todos las fases de la construcción de soluciones desde su conceptualización hasta el desarrollo de aplicaciones a medida o la implantación/integración de soluciones de terceros.

4 VSF en cifras El equipo Vector
"Trabajar en Vector me da la oportunidad de que mi carrera profesional se desarrolle en un entorno de aprendizaje continuo". Progresión Un 60% más que hoy. Más de 770 personas en 2012 Previsión "Nuestro equipo humano, nuestro gran valor empresarial." año empleados

5 Estamos España Inglaterra Alemania Suiza Coruña Andorra Vigo Méjico
Madrid Albacete Brasil Valencia Sevilla Córdoba

6 Retail, Gran Consumo y Servicios
Quienes somos Sobre nosotros Áreas de Negocio Consultoría Soluciones y tecnologías Servicios de desarrollo Especialización Sectorial Retail, Gran Consumo y Servicios Telco y Media Finanzas y Seguros Admon. Públicas Industria y Utilities

7

8 El desarrollo de software
¿Qué percibimos? Clientes ¿Calidad? Ahora no puedo Explosión del Mercado ¿Presu-puestos? Inventar la rueda Falta de estándares… La Calidad en crisis Desarrollo Heterogéneo Oferta y demanda en desequilibrio Los recortes presupuestarios I+D+i

9 Desarrollo de software
La Calidad en crisis Producción La crisis resulta en problemas de planificación e ineficiencias de producción (poco valor añadido en los procesos de producción). Es frecuente que los planes de producción se centren en respuesta tácticas de forma habitual, resultando en situaciones ineficientes de baja calidad en los trabajos realizados. Personas Cuando hay “muchos fuegos que apagar” con “pocos bomberos” es difícil trabajar sin avivar otros o nuevos fuegos. Pérdida de sensación de logro por el trabajo bien hecho y la consecuente desmotivación. Política de calidad Reducción de costes se ha traducido en reducción de calidad en el servicio. Se sacrifican las estrategias de calidad con el consecuente deterioro de la imagen y del alineamiento estratégico de la organización. Clientes ¿Calidad? Ahora no puedo

10 Desarrollo de software
Oferta y demanda en desequilibrio Muchos competidores en un mercado en recesión. Muchos “nuevos actores”. La competencia entre proveedores se basa en la reducción de precios, lo cual se ha traducido en un incremento de los riesgos operativos y funcionales. Paradójicamente existe una reducción del margen de elección dada la necesidad de mitigar los riesgos de continuidad del servicio. Clientes Explosión del mercado

11 Desarrollo de software
Recortes presupuestarios Reducción de las partidas presupuestarias TIC que oscilan entre el 25% y el 90%. Se cae en la tentación de buscar el más por menos, sin realizar el análisis detallado mas allá de la solución táctica y olvidando las soluciones estratégicas. Existen una situaciones de alto riesgo, donde se combinan aspectos como la falta de presupuesto, la quiebra de proveedores y la continuidad del servicio administrativo … Se incrementa la carga de gestión debido a la proliferación de conflictos de producción, operación y humanos. Clientes ¿Y la partida?

12 Desarrollo de software
Desarrollo heterogéneo Cada organización tiene una normativa o una interpretación propia de la misma La mayoría de las veces la aplicación de la normativa adolece de mecanismos automatizados, resultando en la ejecución de labores manuales por equipos especializados(infrautilizados). Dada la sobre carga de los recursos, los procesos normativos no son revisados o mejorados. ¿Cómo afecta mi norma al desarrollo? ¿Y a la explotación? ¿Qué resultados obtenemos? Clientes Falta de estándares…

13 Desarrollo de software
I+D+i Dificultades y/o debilidades (AAPP/Proveedores) en la aplicación de conceptos como reutilización, eficiencia y optimización. Se han realizado grandes inversiones en I+D+i, pero la innovación sigue escribiéndose con letra minúscula… Es necesario utilizar nuevos paradigmas En la toma de decisiones, es necesario introducir criterios de análisis de las iniciativas sobre la base de conceptos como Lean o Sostenibilidad La estandarización debe soportarse sobre una visión holística de las mejores prácticas existentes y ajustadas a la realidad de AAPP. Es necesario cambiar el modelo de la competición, a la colaboración en todos los ámbitos Ante la crisis, es necesario es encontrar el equilibrio entre el mantenimiento de los procesos que aportan valor en el PRESENTE y la investigación, desarrollo e innovación para generar nuevos paradigmas que mejoren el FUTURO. Clientes Inventar la rueda

14 Desarrollo de software
Conclusión Existen Varios problemas … existen entonces oportunidades …

15

16 Aseguramiento de la calidad
Una respuesta Está demostrado que la inversión en Calidad desde las fases iniciales del desarrollo software influye directamente en la reducción de los costes de mantenimiento Costes durante el desarrollo Costes durante el mantenimiento

17 Aseguramiento de la calidad
Ciclo de vida de un proyecto Analisis Definición de Requisitos Diseño Codificación Construcción Pruebas Despliegue Mantenimiento Ciclo de vida de proyecto Actividades de Aseguramiento de la Calidad del Software (SQA) a lo largo de TODO el ciclo de vida del proyecto Oficina Calidad KB Automatización de las pruebas

18 Aseguramiento de la calidad
CMMI CMMI (Capability Maturity Model Integration) es un modelo de mejora (Model) y evaluación de los procesos de desarrollo de sistemas y software, donde la madurez (Maturity) se refiere a la capacidad (Capability) de los procesos de la organización para producir productos de buena calidad, en el coste y plazos estimados de una forma predecible. CMMI establece una escala de 5 niveles de madurez, los cuales están compuesto por uno conjunto predefinido de procesos, resultado de mejores prácticas observadas.

19

20 Metodología En la mente del cliente

21 Pruebas y Automatización
Metodología Dos actividades   Análisis funcional y diseño Pruebas y Automatización Requerimientos Plan de pruebas Escenarios de neogcio Procesos de pruebas/ Documentación Diagrama de contexto Análisis funcional Herramientas QA Diseño/ Arquitectura/ Documentación

22 Metodología Análisis funcional y diseño
La metodología se focaliza en identificar las necesidades del negocio y a partir de allí, profundizar en los escenarios funcionales del negocio, componentes de negocio y casos de usos. Durante este proceso es necesario dibujar la trazabilidad (matriz de trazabilidad) desde las necesidades del negocio hasta los casos de prueba. Posteriormente será necesario continuar este proceso hasta que los componentes de software. Y ya en la último estadio, la granularidad de los componentes de software, se define caso por caso. Requerimientos Escenarios de negocios Componentes de negocios Casos de usos Casos de prueba Pruebas de regresión Automatización

23 Documentación de la arquitectura de software
Metodología Entregables Objetivos del sistema Descripción de los objetivos del sistema Escenarios de negocio Descripción de los procesos ejecutados por actores Definición del escenario críticos para el negocio Diagrama de contexto Descripción de los principales componentes del sistema Relaciones entre los actores y componentes del sistema Actores Clasificación de actores y tipología (sistema externo y los usuarios) Componentes Para cada componente del sistema (o módulo) Modelado de casos de uso Casos de uso Analizar casos de uso sobre la base de las acciones de los Actores y la respuesta del sistema. Modelado de entidad para casos de usos Descrpción de IU Descrpción de pallas Flujo de pantallas Documentación de la arquitectura de software Proporciona una visión general de arquitectura del sistema, Diferentes puntos de vista arquitectónicos para representar diferentes aspectos del sistema

24 Metodología ¿Qué entendemos por pruebas de regresión? Resumen
"Para garantizar que una aplicación es todavía funcional y estable después de un cambio cualquiera." Principales objetivos Gestionar los riesgos provenientes de: Corrección de errores en el código no siempre resuelve problemas funcionales (entender que una intervención en el software no siempre resuelve el problema del usuario) Antiguos bugs reaparecen (ayudar a descubrir los errores que fueron parcialmente o selectivamente resueltos) Los cambios tienen efectos secundarios (entender la forma en que un cambio en el software impacta otras áreas de la aplicación) Fortalezas Efectivamente reduce el tiempo dedicado a realizar una prueba integral de la aplicación Debilidades Sólo se ejecutan pruebas funcionales – para los casos de uso, previamente automatizado Sólo es efectiva si los flujos de trabajo de las aplicaciones o el comportamiento funcional no se cambia con respecto a la versión anterior. Esta situación induce la necesidad de llevar un estrecho control y mantenimiento, para los casos de prueba automatizados.

25 Metodología Framework Definición de pruebas Análisis funcional
Componentes Entidades Relaciones Data Usuarios Entorno Flow de información Flujos crítcos de negocio Diagrama funcional Definición de pruebas Gestión de pruebas Mejorar documentación de casos de prueba Gestión de incidencias Gestión de cambios Análisis funcional Optimización de pruebas Relacción entre los requerimientos y los casos de pruebas Matriz de trazabilidad

26 Metodología Matriz de trazabilidad Matriz de trazabilidad
Jerarquización de cada flujo de negocio Matriz de trazabilidad Matriz de relación Checklist Pruebas críticas GUI & Non GUI Las áreas directamente afectadas Cubre la funcionalidad general y característica básica Conjunto de pruebas para clientes sensibles a la funcionalidad 1er Grupo Herramienta de regresión 2do Grupo Conjunto de pruebas que incluyen problemas que se han presentado en ocasiones anteriores 3ro Grupo Herramienta de gestión de pruebas Hot-Spot suite Las pruebas adicionales debido a la adición de código a finales Clean-Run/sanity Testing Data Set

27 Metodología ¿Cuánto automatizar?
En general tenemos que responder por cada CP, preguntas como: La automatización de cada CP y la ejecución de estos, va a costar más que ejecutar de forma manual cada CP? ¿Cuánto más? La prueba automatizada tiene una vida útil, con el tiempo algunos ajustes se requieren en los scripts. ¿Cuál es el horizonte de vida útil de un CP? ¿Qué eventos son susceptibles acortar este horizonte? Durante la vida de CP: ¿Qué tan probable es que el CP descubra errores adicionales (más allá de lo que sea que los problemas se encuentran por primera vez)?

28 Metodología Control versus aseguramiento de la calidad La calidad se debe asumir de forma proactiva a lo largo de todo el ciclo de vida del proyecto de implantación, de forma que se persigue un incremento de la eficiencia y productividad de los equipos, al detectar cualquier no conformidad en una fase temprana del proyecto, limitando el impacto de posibles errores o deficiencias. Análisis y Diseño Preparación y lanzamiento Construcción / Prototipo Pruebas Soporte Ciclo de vida y arranque Verificación de requisitos 1 Verificación del diseño funcional 2 Verificación modelo de procesos 3 Verificación pruebas unitarias 4 Análisis estáticos 5 Verificación de documentación 6 Pruebas de prestaciones 9 Verificación plan despliegue 10 Pruebas de regresión 11 Gestión y verificación de cambios 12 Gestión de pruebas 7 Gestión de Incidencias 8

29 Metodología Pruebas Agile

30 Metodología Herramientas
Asegurar la calidad de un desarrollo requiere considerar mucho aspectos de la codificación e implementación realizada: Garantizar el cumplimiento de los estándares de codificación Revisión de sintaxis y tipos Analizar acoplamiento y cohesión Identificar excepciones Detectar problema de seguridad o vulnerabilidad de la implementación Identificar potenciales patrones de código asociables a defectos Revisar funciones y relaciones para el caso de dominios vacíos Analizar el flujo de información Verificar condiciones previas, invariantes y posteriores para los procesos ejecutados Realiza reingeniería inversa del código La aplicación de una normativa de codificación por parte de los desarrolladores de software es compleja si no se dispone de herramientas que automaticen esta tarea. La normativa es un elemento vivo, ya que se basa en parte en las buenas prácticas, y por lo tanto requiere actualizaciones. La normativa en formato papel o en un fichero no es de gran ayuda y en algunos casos está sujeta a una interpretación subjetiva por parte del desarrollador. La revisión posterior del código para comprobar si se ajusta a la normativa es un proceso tedioso y que no aporta valor. Existen un conjunto importante herramientas disponibles para atender la rutina asociado a las actividades mencionadas.

31 Índice

32 COVER ¿Qué es? COVER es una herramienta desarrollada por Vector SF que permite comprobar que el software desarrollado cumple los estándares establecidos de calidad. Para ello, la herramienta valida la sintaxis del código generado contra un conjunto de reglas. Estas reglas se agrupan en categorías ISO9126 (Fiabilidad, Eficiencia, Mantenibilidad, Portabilidad, Funcionalidad y Usabilidad). Es un servicio que está disponible on-line. Entre los diferentes paquetes de software que son admitidos por esta herramienta están: las aplicaciones J2EE, las maquetas de HTML y los desarrollos de portales de Internet (Fatwire).

33 COVER Características de la herramienta Validación de código
Diferentes validadores (JAVA, XML, SQL, PL-SQL y Properties) Validación mixta (código embebido de otro lenguaje) Validación global (más de un fichero o estructura del proyecto) Categorización de reglas por ISO9126 Base de datos de reglas Reglas por tipología del desarrollo, y reglas por proyecto Documentación de reglas y ejemplos integrados en la aplicación Generación de informes de la validación (formato HTML) Tramos de corrección (4 grados: correcto, parcialmente correcto, con errores, con muchos errores) Activación / desactivación de reglas por proyecto Ponderación de mensajes / Umbrales de validación Administración Según las diferentes entidades que forman parte del servicio: Usuarios, Empresas, Grupos, Proyectos, Escenarios.

34 COVER Visión General Menú usuario Ubicación Buscador Menú navegación
Listado Operaciones

35 Cover Servicios asociados Consultoría de análisis de la normativa.
En este servicio se realiza el análisis de la normativa del destinatario y de la normativa basada en buenas prácticas de la herramienta (+600 reglas) y se establece un plan de implantación y adaptación del servicio. Implantación de la herramienta. Desarrollo de las adaptaciones e inclusión de la nueva normativa establecida en el plan realizado previamente. Así mismo como conclusión de esta implantación se realizará la parametrización de la herramienta (definición de escenarios, ponderaciones, proyectos y roles, usuarios…). Ejecución del Servicio. Mantenimiento perfectivo y adaptativo de la herramienta. Administración de usuarios, resolución de incidencias , ajustes de parametrización, etcétera. Alojamiento. Servicio de alojamiento de la herramienta.

36

37 Tendecias Control de tipos
Problema: Necesitamos reducir los errores asociados a la gestión de variables con significado específico dentro del sistemas de medidas SI, velocidad y aceleración. Respuesta: En C++ estándar de C+11, es posible asignar las normas de las unidades SI en un sistema de tipo general: template<int M, int K, int S> struct Unit { // a unit in the MKS system enum { m=M, kg=K, s=S }; }; template<typename Unit> // magnitude with unit struct Value { double val; // the magnitude explicit Value(double d) : val(d) {} // construct a Value from a double using Speed = Value<Unit<1,0,-1>>; // m /s using Acceleration = Value<Unit<1,0,-2>>; //m/s/s constexpr Value<Second> operator”” s(long double d) // a f-p literal suffixed by 's' { return Value<Second> (d); } // a very explicit notation (quite verbose): Speed sp1 = Value<1,0,0> (100)/ Value<0,0,1> (9.8); // use a shorthand notation: Speed sp1 = Value<M> (100)/ Value<S> (9.8); // abbreviate further still: Speed sp1 = Meters(100)/Seconds(9.8); Speed sp1 = M(100)/S(9.8); // this is getting cryptic } (*) Fuente IEEE Computer Enero 2012

38 Tendecias Software o Hardware
Como hemos visto, cada vez es mas importante trabajar en nuestros desarrollos de software con variables que utilicen “tipos ricos”. Sin embargo, cada vez es mas importante entender las piezas que se utilizan para implementar una solución y el impacto de estas sobre el rendimiento del sistema HR y SW. e.g. En la gráfica se muestra un ejemplo de lo que significa en tiempo de procesamiento, el organizar una lista que tiene dos posibles representaciones para el arreglo, un arreglo tipo Vector o una Lista. Codesign es un proceso iterativo, en el que el objetivo es optimizar las aplicaciones y el hardware a través de una combinación de rendimiento, consumo y el costo x (*) Fuente IEEE Computer Enero 2012

39