Mare Magnum de Palabros

Coad-Yurdon, marco, metodología, estándar, calidad, gestión de la calidad, calidad en la gestión, procesos, Magerit, metodología, Merise, Booch, eXtreme Programming, Scrum, agile, CMMI, ITIL, calidad de

producto ISO, ISO9000, ISO9001, garantía, predictibilidad, prestaciones, riesgos, reingeniería de procesos, lean, calidad total, RUP, TQM, EFQM, RSC, excelencia, revisión por pares, testing,

verificación, madurez, validación, aceptación, inspección, pruebas unitarias, regresión, usabilidad, RAD, muda, Métrica 3, deuda técnica, mock, confianza, cobertura(s), gestión del cambio, gestión de cambios,

gestión de configuración, TDD, integración continua, ISO20000, ISO9126, 6 Sigma, Cobit , Kaizen, mejora continua, chindogu, poka-

yoke, gemba, gembutsu, CMM, ISO 15504, SCAMPI, producto, servicios, sistema, documentación, documento, métricas, indicador,

propósito, objetivo, requisitos, necesidades, misión, alcance, dependencias, jerarquía, trazabilidad, RAMS, criticidad, prioridad, gravedad, bug, fallo, error, incidencia, problema, RCA, Ishikawa,

ISO25000, ISO 14598, calidad interna/externa/de uso, administración, gestión, operación, explotación, prototipo, paralelo, implantación,

despliegue, puesta en marcha, espejos, entornos, la W, las 5 S, KISS, YAGNI, merma, SPICE, procedimiento, técnica, guía, normativa, elicitar, aseguramiento, QA, cumplimiento, cumplimentación, …

lista no exhaustiva de conceptos relacionados y/o confusos, ya sea por adyacentes o por desconocimiento

¿Y pur dóunde?Mapa de contenidosIntro:

Mare Magnum

Mapa de

contenidos

Pruebas

Revisiones

• conceptos

• aspectos

Herramientas

Mejora

Costes

Praxis:

• Q(I+D)

• Q(servicios)

• Q(gestión)

• ges(Q)

Mapa => Implicados => necesidades

Servicios IT

Desarrollo IT

• proceso I+D+i

• retos gestión

• metodologías

Producto IT

Fin:

Referencias

IT

Q

Qué es Q:

• confusiones

• cuéntame

• sopa de letras

• para qué

Consultoría Q:

• ej.serv.cons.Q

• mapa Q-jobs

Q ¿vs. IT?

¿Qué es Q?

• Marco: establece límites y condicionantes dejando margen para

elegir soluciones alternativas (4-4-2).

• Metodología: describe cómo ejecutar un proceso.(Al toque con incursiones de los extremos por las bandas y pases hacia atrás)

• Estándar: fija una solución. Los hay de proceso y de resultado.

• Desarrollo (jugadores) vs Gestión (centrocampista) vs Dirección (entrenador)

• Desarrollar gestión ≠ gestionar desarrollo

• Gestión de calidad = calidad en/de gestión ≠ gestión de la calidad

Ejemplos de conceptos similares que se confunden

Reina la confusión…

¡Jo! „Pos‟ seguimos sin saber qué es…

Cuéntamet circunstancias Q Ref./ej.

preindustrial Manufactura

Objetos (pasivos)Durabilidad “las cosas ya no se

hacen como antes”

~ 1960‟s Fabricación

IndustrialVerificación de

especificaciones de

unidades fabricadas

“control de fallos”

~ 1970‟s Nuevas

máquinas

(activas)

Validación de diseño

de producto

“calidad de producto,

prevenir defectos”

~ 1980‟s Variedad Eficiencia de los

procesos

“re-ingeniería de

procesos”, “JIT”

~ 1990‟s Competencia

ferozSatisfacción del cliente “calidad de servicio,

atención al cliente”

~ 2000‟s Subcontratación

y OutsourcingSatisfacción de los

implicados

“excelencia”

~ 2010‟s Crisis

Internet

¿crowdsourcing?

¿redes sociales?

¿satisfacción colectiva? ”RSC, buenismo

ciudadánico”

Historia (muy simplificada) de la percepción del concepto calidad.

Sopa de letras

• “Empleamos metodología XYZ”

– ¿de qué es la metodología: análisis, desarrollo, codificación, gestión de

proyecto?

– ¿Qué me está vendiendo con su empleo de la metodología? ¿cuadra?

– Ej: ISO: Cuidau con lograr obtener mierdas perfectamente igualitas.

– Ej: “Certificado CMMI” ¿qué nivel? ¿qué ámbito? ¿”certificado”?

• Scrum, XP, CMMI, ITIL, ISO 20000, ISO9000,

ISO 9126, 6 Sigma, Magerit, ISO, URP, EFQM,

Cobit, Yurdon, Buch, Merise, … [página 12]

Conceptos: Metodologías, certificaciones, estándares, … de calidad en IT

¡Jo! P‟os seguimos sin saber qué es…

• Hist. || Madurez: Detectar → Prevenir → Mejora continua

¿Q pa‟ qué?

• Para reducir costes o riesgos o problemas -> ¿cuales?

– … de oportunidad <= retrasos, priorización

– … de desarrollo <= retrasos, inadecuación, errores,

– … de evolución <= trazabilidad, dificultad, lentitud, costes

– … de explotación <= infraestructura, consumos, incidencias (sustos), formación, …

– … de uso <= dificultades, procedimientos pesados/farragosos, ...

– … de venta <= demostraciones y convicción,

• Para aumentar beneficios

– Funcionalidad (lo que hace)

– Prestaciones (cuan bien lo hace)

– Venta (abrir mercados, convencer en primera impresión, …)

– Satisfacción (experiencia subjetiva)

• Para poder reaccionar (predictibilidad, control, …)

• Para confiar (garantías)

Motivaciones para gestionar la calidad.

=> Calidad = Cualidad || Propósito

Servicios de consultoría Q

• Creación y mejora de organizaciones (dptos, grupos de trabajo, empresas,

…)

• Ingeniería de procesos

• Oficinas de pruebas

• Sistemas de verificación

• Oficinas de validación

• Diagnósticos de situación: identificación de problemas

• Preparación para certificación

• Prescripción de tratamientos: gestión del cambio

• Administración de tratamientos: gestión del despliegue

• Mediciones, charitos y cuadros de mando

• Madurez

• Despliegue y operación de herramientas (de control, de desarrollo, …)

• Apertura de horizontes: “¿Qué más puedo hacer?” (Efecto Dunning-Kruger)

• … etc

Ejemplos de trabajos posibles de consultoría de calidad

Calidades y calidades

A. ¿Qué buscar?: Funcionalidad, Prestaciones, Predictibilidad,

Confianza

A. Madurez, Desempeño/Rendimiento, Dureza/fragilidad/robustez, …

B. ¿Cómo buscar?: Defensivo (- problemas) vs. expansivo (+

beneficios)

C. ¿Qué hacer? Mirar/Medir → Diagnosticar → Proponer → Prescribir

Administrar → Monitorizar

D. ¿Cuál tocar?: Organizativa, de proceso, de producto, de servicio

E. ¿Dónde tocar?: oportun., desarrollo, manto., explot., uso, venta,

{ Posibles trabajos } = A x B x C x D X E

Mapa para focalizar la gestión de la calidad

OK, ya veo. Pero…

¿qué tiene que ver con IT?

Q para IT:

vamos a entrar a verlo

a cierto detalle

Q ITIT para Q:

debiera servir de intro para

seguir aprendiendo en casa

IT

ITMapa de contenidosIntro:

Mare Magnum

Mapa de

contenidos

Mapa => Implicados => necesidades

Servicios IT

Desarrollo IT

• proceso I+D+i

• retos gestión

• metodologías

Producto IT

Pruebas

Revisiones

• conceptos

• aspectos

Herramientas

Mejora

Costes

Praxis:

• Q(I+D)

• Q(servicios)

• Q(gestión)

• ges(Q)

Fin:

Referencias

Q

Qué es Q:

• confusiones

• cuéntame

• sopa de letras

• para qué

Consultoría Q:

• ej.serv.cons.Q

• mapa Q-jobs

Q ¿vs. IT?

¿quién hace qué?

Cliente del desarrollo tiene un propósito (negocio)

Jefe persigue unos objetivos mediante un proyecto

Técnicos desarrollan un producto (sistema)

Usuario necesita un servicio

Gestión de empresa

Gestión de servicio

Gestión de proyecto

Mapa de contexto del negocio IT

Mear con viento

(u) Los problemas „causados por mal uso‟ en realidad raramente son atribuibles al mal uso: en general enmascaran problemas de diseño,

venta, formación, etc.

Oportun. Des. Evolución. Explot. Uso Compra

Oportun. retrasos (u)

Des. sobrecoste

retrasos

retrasos

inadecuación

errores

-

(u)

-

Evoluc. sobrecoste inadecuación

trazabilidad

trazabilidad documentación (u)

Explot. sobrecarga dificultad

lentitud

consumo

infraestructura

dificultad

lentitud

consumo

Infraestructura

errores

errores =>fallos (u) dificultad

lentitud

consumo

fallos

Uso ? dificultad

lentitud

Son necesarias

muchas evoluciones

para causar un daño

serio en el uso.

dificultad

lentitud

(u) errores

Venta convicción demostración

convicción

mala fama mala fama (u) -

Impactos cruzados habituales por mala calidad.

Gestión de servicio

• ITIL v2 (v3 ya) ≈ ISO 20000

– Apoyo al servicio: Atención > Incidentes > Problemas > Cambios > Despliegues > Configuración

– Provisión del servicio: Continuidad > Disponibilidad > Nivel de Servicio > Capacidad > Financiación

• Cobit

• Magerit (riesgos IT)

Calidad para administradores de sistemas, …

DESPLIEGUES:

– Niveles de servicio (SLA)

– Subcontrataciones

– Rendimiento y capacidad

– Continuidad

– Seguridad de sistemas

– Financiación (costes)

– Formación

– Atención e incidencias

– Configuración (integridad)

– Problemas (RCA)

– Datos

– Entorno físico (HW, geo, T…)

– Operaciones

IMPLEMENTACIÓN

– Identificar soluciones automatizadas

– Software de Aplicación

– Infraestructura tecnológica

– Operación y uso

– Compra de recursos IT

– Cambios

– Instalar soluciones y cambios

PLANIFICACIÓN

– Estrategia y directrices

– Arquitectura informacional (MD)

– Dirección tecnológica

– Procesos, relaciones y organización

– Inversión IT

– Comunicación desde la dirección

– RR.HH

– Calidad

– Riesgos IT

– Proyectos

MONITORIZACIÓN

– El proceso

– (su gestión:) El control

– Cumplimiento regulatorio

– El gobierno (BSC)

Proceso de desarrollo*Divide y vencerás: Metas vs soluciones

(*)

• no confundir con proceso de gestión de proyecto de desarrollo.

• se puede desarrollar un prod., un sist. un plan, o un serv., o un proy.Retos:

• especificar vs. ambigüedad o incompletitud

• decisión tecnocrática y soporte tecnocrático a decisiones de gestión

→Elicitar necesidades (tirar de la lengua) (I)

→Especificar requisitos funcionales

→Esbozar alternativas de solución y elegir (Análisis conceptual)

→Especificar requisitos técnicos (D)

→Diseñar: arquitectura, lógica

→Construcción de elementos físicos

¿para qué?

¿qué?

¿cómo se logra?

¿cómo debe ser?

¿cómo funciona?

Manos a la obra

Retos de gestión

Objetivo: Equilibrio (medios vs. resultados) eficaz > eficiente

Medios:

• Dirección: “No hay viento bueno para quien no sabe donde va”

• Interlocución/negociación: Gap negocio – tech

• Predictibilidad <= control pasivo (cuadros de mando)

• Control activo (gobierno) <= organización (mandos del cuadro)

• Soluciones Imaginativas (se tiende a administrar)

Selección de metodologías

• Profesionalidad, experiencia, motivación

• Volatilidad de requisitos

• Cultura de responsabilidad y delegación

• Criticidad

• Tamaño del equipo

• Cultura de orden y

control

ágil predictiva

• Elicitación: relatos de uso + prototipado, monitorización de uso, …

• Análisis: …de refactorización emergente vs. Yurdon, Merise, …

• Diseño: TDD, refinado (Merise, Yurdon, …),

• Gestión: Scrum, XP, …

Producto: ISO 9126 („91-‟01)

• 9126 (mod) || 14598 (proc y rel) => 25000 (dev)

Funcionalidad• Cumplidor

• Idóneo

• Preciso

• Interoperable

• Seguro

Usabilidad• Cumplidor

• Inteligible

• Aprendible

• Operable

• Atractivo

Mantenibilidad• Cumplidor

• Estable

• Analizable

• Se deja probar

• Cambiable

Portabilidad• Cumplidor

• Intercambiable por otros

• Instalable en otras bases

• Coexiste con otros

• Adaptable

Eficiencia• Cumplidor

• Velocidad/veloz

• Consumo/austero

Fiabilidad• Cumplidor

• Maduro

• Tolera fallos

• Capaz de recuperarse

InternaExternaDe uso

QMapa de contenidosIntro:

Mare Magnum

Mapa de

contenidos

Mapa => Implicados => necesidades

Servicios IT

Desarrollo IT

• proceso I+D+i

• retos gestión

• metodologías

Producto IT

Pruebas

Revisiones

• conceptos

• aspectos

Herramientas

Mejora

Costes

Praxis:

• Q(I+D)

• Q(servicios)

• Q(gestión)

• ges(Q)

Q

Fin:

Referencias

IT

Qué es Q:

• confusiones

• cuéntame

• sopa de letras

• para qué

Consultoría Q:

• ej.serv.cons.Q

• mapa Q-jobs

Q ¿vs. IT?

Pruebas

• Defecto ≠ Fallo ≠ Error ≠ Incidencia ≠ Problema

• Niveles de prueba: La W: unitarias, de integración, de sistema

• Tipos de prueba: funcionales, de prestaciones, específicas

• Técnicas de diseño de pruebas

– Caja Negra: Partición de clases equivalentes, análisis de valores límite, conjetura de

errores, cobertura de requisitos, cobertura de casos de uso

– Caja Blanca (transparente => cobertura(s)): de sentencias, de decisiones, de

condiciones, múltiple de condiciones.

• Mock

Lista de conceptos relacionados con Pruebas

• Verificación: hecho como se había establecido (“según planos”)

• Validación: lo hecho vale para lo que se quería

• Aceptación: el cliente traga (contractual)

• Inspección: para aprobar/rechazar

• Comprobación: asegurarse de algo

• Revisión: volver a mirar (puede ser para ir más allá)

• Por pares o por autoridad (técnica o jerárquica)

• ¿reunión?

• Defecto ≠ Fallo ≠ Error ≠ Incidencia ≠ Problema (ya lo vimos en pruebas)

Revisiones: Conceptos

Aspectos de revisión

Verificación contra

estándares y

normativa

+ Otros …Integración entre productos

o componentes

Validación

de uso

Verificación

contra

especificaciones

• Fuentes externas de estándares y normativa:

– Legislación (LOPD, …)

– Entidades reguladoras de mercado (DGT, BdE, CNT, …)

– Entidades de normalización técnica (ISO, IEEE, W3C, ESI, …)

– Estándares de facto: usos y costumbres (1)

• Fuentes internas de estándares y normativa:

– La jerarquía de la entidad (gerencias, direcciones, jefaturas, …)

– Los planes de calidad de proyecto/sistema/organización

Aspectos de revisión

Verificación contra estándares y normativa

(1) Conviene convertir en especificaciones

Aspectos de revisión

Intergración entre producto o componentes

• Código ejecutable vs estructuras de datos

• Interacción entre subsistemas

• Programas vs librerías

• Comunicaciones con el exterior

• Dependencias Orden de implantación y puesta en funcionamiento

1º

2º

3º

3º

4º

No basta con cumplir los requisitos funcionales

Aspectos de revisión

Validación de uso

Hay que comprobar que la solución es práctica en su propio contexto

(chindogu)

¿Pistola o espada?• Diseño

• Modeladores gráficos → facilitan la visualización de conceptos

• (Compiladores y) generadores de código → elevan el discurso de la tecnología hacia el propósito

• Editores sintácticos → facilitan la visualización de estructuras

• Desarrollo– IDE‟s -> automatizan tareas banales → agilizan y evitan errores „tontos‟

– Frameworks y librerías → reuso de componentes fiables + estructura el código

– Integración contínua: Ant, Maven, …etc. → son base para automatizar pruebas de regresión.

• Análisis de código:

– Estático• Dependencias -> facilitan la visualización de estructuras

• Reglas de codificación (sentencias): Compiladores, Jlint, … → uniformizan y evitan errores „tontos‟

• Reglas de diseño (algoritmos) -> uniformizan y provocan análisis

• Métricas -> facilitan la visualización de situaciones

– Dinámico• Pruebas unitarias xUnit

• Opensourcetesting.org => (178 herram. SW de pruebas + 65 de gestión de pruebas)

• Evaluación agregada y reporting:– Desarrollo SW: Squale y Sonar

– Sistemas IT: Nagios, Zenoss, Pandora FMS, Osmius, …

– Inteligencia de negocio: Pentaho

• Administración: financiera, inventarios, …

Técnicas/Herramientas (IT)

La tortuga y la liebre

• Kaizen, Lean, agile (XP, scrum, TDD, …)

• Innovación disruptiva

– pensamiento lateral (medio)

– 2 cordeles / agua y vino / movil blindado /

• ¿Cuándo Kaizen cuando ID?

• ¿Cómo?

Herramientas

Referencias

Objetivos

Optimización

Referencias de proceso

Referencias de producto

Cómo inv€rtir en Q

• Calidad es gratis. Lo que cuesta es la no-calidad

• Rdto_Q = ahorro acumulado (inv) / invLo normal es buscar la Q que da el máximo rendimiento

A veces se justifica comprar caro, p. ej. si ventas(Q)

Otras veces no hay para comprar el pico => realimentar

1 / inv

Ahorro acumulado de los fallos

evitados (inv)

Costes de la Q

• al principio: muchos fallos y graves

• al final: pocos fallos y leves

=>

• el nº fallos desciende

• el ahorro/fallo también

el ahorro desciende muy rápido

el ahorro acumulado crece cada

vez menos, estabilizándose.

PraxisMapa de contenidosIntro:

Mare Magnum

Mapa de

contenidos

Mapa => Implicados => necesidades

Servicios IT

Desarrollo IT

• proceso I+D+i

• retos gestión

• metodologías

Producto IT

Pruebas

Revisiones

• conceptos

• aspectos

Costes

Praxis:

• Q(I+D)

• Q(servicios)

• Q(gestión)

• ges(Q)

Fin:

Referencias

IT

Q

Qué es Q:

• confusiones

• cuéntame

• sopa de letras

• para qué

Consultoría Q:

• ej.serv.cons.Q

• mapa Q-jobs

Q ¿vs. IT?

1:52‟

¿Qué hay de lo mío? (dev)• Elicitar requisitos >> apuntar (ni escribir) lo que me dice el cliente (ni el usuario).

– Sacar a la luz las necesidades y especificarlas: “Los pacientes mienten” (Dr. House)

– Necesidades, NO requisitos => Chindogu

• Gestionar requisitos >> cargar de datos la herramienta de gestión.– Mantener un equilibrio entre las necesidades cambiantes y contrapuestas de las partes.

• Gestionar cambios >> emplear un CVS.– Control de versiones: id. única, repo/fuente única (CVS)

– Control de cambios (SW): ∆ (código, diseño, análisis, requisitos, …) (diffs + su lógica)

– Control de configuración: mantener integridad entre los elementos: normas y controles (pro-/react)

• Analizar >> rellenar la plantilla– Estable y/o muy grande => Primero la amplitud y luego la profundidad

– “Divide y vencerás” …pero cuidado ¡no restar al dividir!

– Documentar (o explicar a otros) obliga a explicitar => suscita cuestionamientos

• Diseñar >> que quede bonito– Re-uso & infraestructura, vs. refactorización

– Documentar no es coleccionar comentarios: ¿Qué? ¿para quién? ¿dónde? y ¿cómo?

– Internacionalizar >> traducir (pl., gén., fmt. fecha, coma decimal, alineación, ñîç€, tono, Ud. moneda, …)

• Gestión de pruebas no es probar, ni es contar casos de prueba superados– Humo, Funcionales, Regresión, Usabilidad

– Técnicas: • Prestaciones/rendimiento: Escalabilidad/Capacidad, Estabilidad, Sobrecarga, elasticidad, estrés, robustez/recuperación

• Seguridad

• Compatibilidad, configuración, empaquetamiento

• Alinear y mantener alineado el producto al propósito.

Claves de Aplicación (IT)

¿Qué hay de lo mío? (serv.)

• Atención AL (no “del”) cliente: Las herramientas y procesos no son su problema: el sastre.

• Orientación al cliente ≠ atenderle rápido

• Atención al cliente ≠ satisfacción del cliente. “pelota” = la sonrisa que cabecea.

• Ojo al cierre de las incidencias: un registro no es una evidencia.

• Un buen producto o sistema no garantiza un buen servicio. Sólo ayuda.

• Que funcione no significa que sea bueno.

• Gestión de problemas >> cerrar un tiquet: RCA

• Desplegar >> instalar

• Provisión de servicio >> poder hacer pedidos.

• Gestionar la capacidad >> tenerlo todo inventariado.

• Gestión financiera >> tenerlo todo contabilizado.

• Ojo: los conceptos son relativos. Dependen del punto de vista.– El pájaro, la vaca, …, el burro en el pozo,

Claves de Aplicación (IT)

¿Qué hay de lo mío? (ges.)

• Calidad de Gestión:

– Gestionar >> mirar charitos + presionar al personal.

– Gestionar >> administrar

– Controlar >> saber lo que está pasando. Es tener la sarten por el mango.

– Calentar la silla ≠ Trabajar mucho ≠ trabajar bien

– Un modelo aproxima una realidad, no la condiciona =>• Los procesos no mandan sobre la realidad. El sol saliendo a mediodía

• Los indicadores y las estadísticas mienten

– Cuadro de mandos o los mandos del cuadro (ro vs. rw)

– Alinear y mantener alineado el trabajo al propósito: producción vs prediccion

– Gestión debería ser un soporte: Kaizen, Gemba, Gembutsu, …

– Cuidado con acabar buscando las llaves bajo la farola

Claves de Aplicación (IT)

¿Qué hay de lo mío? (ges Q.)

• Gestión de la Calidad:

– Calidad en la fuente: La calidad la inyecta quien sabe y puede• => La gestión no inyecta, solo ayuda = La gestión es un medio, no un fin.

– Lo mejor es enemigo de lo bueno• Release early, release fast + minimalismos: KISS, YAGNI, …

– Si es simple y hace lo mismo, es mejor. La navaja de Occam.

– Las herramientas soportan el proceso, no mandan sobre él.

– Seguir un proceso definido no garantiza buenos resultados. Solo ayuda.• Aporta predictibilidad => aporta significación parcial a las métricas => facilita aprender

• Estabiliza la base sobre la que evolucionar

– Barrer debajo de la alfombra es incubar la catástrofe. Génesis de un tsunami.

– Evidencia ≠ registro “Te lo juro por …”

Claves de Aplicación (IT)

Materiales

• http://www.slideshare.net/kybeleconsulting/i-jornada-csi-moiss-rodrguez-alarcos-

quality-center-calidad-del-producto-software-de-la-teora-a-la-prctica

• http://opensourcetesting.org

• http://www.youtube.com/watch?v=vJG698U2Mvo

• http://humor.desvariandoando.com/2007/11/ingeniera-casera-chapuzas.html

• http://es.wikipedia.org/wiki/Historia_de_la_calidad

• ftp://ftp.gul.es/pub/gul/cursos/2010/marzo/calidad_sw/calidad_sw.mpg

• http://en.wikipedia.org/wiki/Theory_of_Constraints (POOGI)

• http://www.nofunciona.es/eisenhower-y-la-diferencia-entre-luchar-contra-alemania-y-

luchar-contra-japon/

1:20‟

Las siguientes imágenes no son mías y se incluyen a modo de cita; están reducidas y enlazadas a las páginas donde las encontré:

• Las de los chindogus

• La de la sopa de letras

La bola del mundo tampoco es mía pero no he logrado encontrar la fuente de origen.

El resto es mío y lo libero bajo licencia CC-By-SA.