Cómo Comprar Software de Calidad. Pablo Straub Consultor

Transcripción

1 Cómo Comprar Software de Calidad Pablo Straub Consultor

2 El Problema Testimonio de un comprador de software a medida Nos entregaron el sistema informático mucho después de la fecha original y nos costó un mundo echarlo andar. La marcha blanca parecía que no iba a terminar nunca. Ahora funciona, pero no responde a lo que esperábamos. Y eso que elegimos la mejor oferta técnica. 2

3 El Problema (Reverso) Testimonio de un proveedor de software a medida Nos costó un mundo que se pusiéran de acuerdo y los clientes hicieron cambios hasta en la marcha blanca. Después de un gran esfuerzo no los dejamos contentos. Ahora el sistema anda, pero perdimos bastante plata. Y eso que pusimos a nuestra mejor diseñadora. 3

4 Advertencia Todos los personajes de esta presentación son ficticios. Cualquier semejanza con personas o situaciones reales es mera coincidencia y no debe interpretarse como intencional. Los diálogos son sólo fruto de la imaginación del presentador y no necesariamente coinciden con la opinión del canal. 4

5 Objetivo Identificar elementos de la relación entre proveedores y compradores de software hecho a medida que inciden en el perfil de calidad, riesgos y costos de los proyectos 5

6 Resultados esperados Definir los conceptos básicos de calidad de software Entender la calidad de software como consecuencia de la calidad de los procesos, personas y tecnologías del desarrollo Entender los principales atributos de calidad del producto de software Entender los principales atributos de calidad del proyecto de desarrollo Aplicar todos los conceptos anteriores en la elaboración de bases de propuestas para desarrollo de software a media 6

7 Contenido Introducción El problema Qué es la calidad? Por qué me importa? Calidad: Personas, procesos y tecnologías Enfoque de gestión de calidad de procesos Evidencia de capacidad organizacional: ISO 9000, CMMI, política, metodología, procesos críticos Uso de la Presentación de Inicio de Proyecto en propuestas Qué pedir en Términos de Referencia La Calidad en el producto ISO/IEC 9126 Qué pedir en Términos de Referencia Calidad del proyecto Hacia la creación de Métricas de Software Generalmente Aceptadas Relación entre riesgo y términos contractuales sobre el ciclo de vida Qué pedir en Términos de Referencia Invitación: Incorporar el tema de calidad en las propuestas 7

8 El Problema (Global) Éxito Cumple plazo, costo y alcance; está operacional Dificultad No cumple plazo, costo y alcance; está operacional Fracaso No se completa Resultado Proyectos Nota: Los números son un poco mejores para las compañías pequeñas y medianas Éxito Dificultad Fracaso Fuente: The Standish Group Report, 1995 The Standish Group, Inc. 8

9 Principales factores de éxito/fracaso Las principales tres causas de éxito (43%) Involucramiento del usuario Apoyo de la gerencia ejecutiva Declaración clara de los requisitos Las principales tres causas de problemas (37%) Falta de input de los usuarios Requisitos y especificaciones incompletas Requisitos y especificaciones cambiantes Las principales tres causas de fracaso (36%) Requisitos incompletos Falta de involucramiento de los usuarios Falta de recursos Fuente: The Standish Group Report, 1995 The Standish Group, Inc. A base de encuestas hechas a muchos ejecutivos de TI. 9

10 Tamaño, complejidad y fracaso El tamaño y la complejidad ayudan al fracaso Investigaciones en The Standish Group sugieren también que los tiempos más cortos, con entrega de componentes de software temprano y seguido, aumentan la tasa de éxito. Los tiempos más cortos resultan en un proceso iterativo de diseño, prototipado, desarrollo, prueba e implantación de elementos pequeños. El simplificar los proyectos es una actividad valiosa porque la complejidad sólo causa confusión y costos mayores. Fuente: The Standish Group Report, 1995 The Standish Group, Inc. 10

11 Qué es la calidad? La totalidad de características y atributos de un producto o servicio relacionados con satisfacer necesidades expresas o implícitas Calidad = Satisfacción La Calidad depende de las expectativas 11

12 Cada cliente define la calidad Bien construido. Va a durar mucho! Excelente rendimiento Funciona en Unix y en PC Se adapta mis necesidades Muy fácil de usar Sin errores 12

13 Por qué me importa la calidad? Funciones crecientemente más críticas en empresas y el Estado se automatizan mediante software El impacto de la mala calidad es múltiple Errores funcionales Problemas en el negocio Dificultad de uso Ineficiencia operacional Dificultad de uso Errores del operador Lentitud del sistema Ineficiencia operacional Funcionalidad crítica ausente Incapacidad de la organización Poca modificabilidad Costos y tiempo de cambios futuros No necesito peleas con el proveedor, sino software para hacer mi negocio 13

14 De qué depende la calidad? Personas Cliente Procesos Tecnologías Para lograr calidad se necesita: Cliente que define la calidad para este sistema Método: Personas, procesos y tecnologías 14

15 Acercamientos a la calidad: Métodos Rigurosos / Métodos Ágiles El foco de los Métodos Rigurosos Personas Cliente El foco de los Métodos Ágiles Procesos Tecnologías 15

16 Enfoques para lograr calidad consistentemente Métodos rigurosos Procesos, herramientas Planes Documentación completa Control, auditoría, certificación Negociación de contratos Entregas grandes Pocos cambios de requisitos Equipos grandes y distribuidos Cliente/usuario lejano Negocio estable Representado por norma ISO 9000 y modelo CMM Métodos ágiles Personas e interacciones Reacción a los cambios Código que funciona Disciplina, código, pruebas Colaboración con el cliente Entregas frecuentes Necesidades cambiantes Equipos pequeños Cliente/usuario disponible Negocio cambiante Representado por Programación Extrema, Scrum, FDD, Crystal 16

17 Qué es ISO 9000? Una familia de normas internacionales que definen requisitos para los llamados sistemas de gestión de calidad Los sistemas de gestión de calidad son los mecanismos mediante los cuales las organizaciones siguen procesos bien definidos para asegurar que sus productos o servicios cumplen los requisitos de los clientes ISO 9000 goza de reconocimiento internacional y se aplica a todas las industrias, incluso al desarrollo de tecnologías de la información Los requisitos de la norma están en el documento conocido como ISO 9001:

18 Qué es CMM? Qué es CMMI? Modelo de Madurez de Capacidades (Capability Maturity Model) Es un modelo y norma de la industria de cómo se desarrollan las capacidades organizacionales que propenden a la calidad Define cinco niveles de capacidad organizacional Originalmente orientado sólo al desarrollo de software (SW- CMM) Ahora también orientado a actividades de ingeniería de sistemas, incluyendo hardware y software (CMMI) 18

19 Procesos Críticos Integridad de los Compromisos Gestión de compromisos con el cliente Gestión de compromisos internos (equipo inmediato, intergrupal) Control e informe de avance Verificación de prácticas y disciplina Integridad del Producto Gestión de requisitos Gestión de configuración Control de calidad: pruebas, demostraciones, revisiones Aprendizaje 19

20 Qué poner en los términos de referencia Solicitar información al proveedor sobre su postura y estado en relación a procesos de software Si está certificado en ISO 9000 o evaluado CMM Si tiene un proyecto de mejora de procesos Si conoce/aplica métodos ágiles Solicitar información sobre cómo se realizan los procesos más críticos Cuál es su estadística de entregas a tiempo Cómo hace gestión de configuración y de cambios de requisitos Cómo asegura la calidad del producto Cómo determina y reporta el estado de avance 20

21 La Calidad en el producto de software Queremos un software Fácil de aprender y usar De rápida ejecución Que tiene la funcionalidad apropiada Que no contiene ningún error A prueba de intrusos Que funciona en todos los computadores Que es fácil de modificar frente a nuevas necesidades De todas las anteriores, qué es lo que más importa para este proyecto en particular? 21

22 Clases de atributos de calidad de software según norma ISO/IEC 9126 Cuán fácil es transferir a otro ambiente? Portabilidad Funcionalidad Están disponibles y bien hechas las funciones requeridas? Cuán fácil es modificarlo? ISO/IEC 9126 Mantenibilidad Confiabilidad Funciona sin errores? Son frecuentes los errores? Cuánto tiempo y recursos usa? Eficiencia Usabilidad Es fácil de aprender, entender y usar? 22

23 Qué poner en los términos de referencia Describir cuáles atributos de calidad se necesitan en este proyecto en particular Poner sólo los atributos de calidad más importantes Asegurarse que los atributos de calidad son específicos a las necesidades del negocio y que son medibles Solicitar que la especificación de requisitos incluya requisitos de calidad Propios de este sistema Escritos en términos relativos al negocio Solicitar que las condiciones de aceptación incluyan pruebas para demostrar cada uno de los requisitos (incluyendo los de calidad) 23

24 La calidad en el proyecto Queremos un proyecto que Es barato Es rápido Cumple todos los plazos Controla adecuadamente el riesgo Entrega información creíble del estado de avance Entrega toda la funcionalidad Entrega el más alto nivel de calidad Reconoce y acepta los cambios De todas las anteriores, qué es lo que más importa para este proyecto en particular? 24

25 Aprobación de proyectos Hipótesis La forma en que las organizaciones aprueban proyectos dificulta el desarrollo evolutivo, causando Costos mayores Flexibilidad menor Calidad menor 25

26 Riesgo en los términos contractuales típicos Las licitaciones a suma alzada con requisitos fijos Obligan al comprador a anticipar todos los requisitos Poner todo lo que se piensa que es útil Muchos requisitos, algunos con dudable valor de negocio Inevitablemente olvidamos requisitos Inevitablemente surgen nuevos requisitos Obligan al proveedor a hacer planes y estimar costos con información temprana y poco análisis Planes poco realistas Precio incluye premio por riesgo Terminamos pagando más, implementando funciones muy poco usadas (sin valor), con proyectos usualmente atrasados y poco rentables para los proveedores 26

27 Pérdidas La mala calidad son pérdidas La funcionalidad que se usa muy poco son pérdidas La mayor pérdida en el desarrollo de software son las capacidades y funciones que se desarrollan, pruebas y soportan, pero que son raramente o nunca usadas. Hemos notado que tal vez los dos tercios del software de un sistema puede caer en esta categoría. Nuestros métodos usuales para levantar requisitos tienen muchos incentivos para agregar más requisitos Dejar que los clientes descubran qué necesitan implementando en forma incremental sólo aquello que tiene valor de negocio En vez de fijar el alcance, determinamos los objetivos Esto implica medir el rendimiento del equipo de desarrollo Fuente: Lean Development and the Predictability Paradox, 2003 Poppendieck LCC. 27

28 Los contratos Los contratos están más preocupados de delimitar culpas si hay problemas que de colaborar para tener éxito Multas, alcance, protocolos de cambio No mencionan la creación de valor en el desarrollo Es posible definir contratos de otro modo: con objetivos La idea es que se propone un objetivo de costo y plazo Además se determina el objetivo del sistema a desarrollar, pero no su alcance o funcionalidad exacta Si el objetivo no se puede alcanzar, se negocia de buena fe Si esto parece riesgoso, considere la alternativa de tener éxito en uno de cada seis proyectos 28

29 Qué poner en los términos de referencia Dejar un cierto grado de flexibilidad en los requisitos, que permita al comprador sacar funcionalidad (y también agregar) Exigir entrega por etapas, con evaluación del cliente del grado de adecuación de las funcionalidades Negociación de requisitos entre etapa y etapa Planes revisados entre etapa y etapa Flexibilidad en los requisitos y el alcance Inflexibilidad en las fechas Experto del usuario trabajando codo a codo con los desarrolladores Balanced scorecard del proyecto 29

30 Conclusiones La calidad del software a medida depende de la capacidad de los desarrolladores (método, personas, proceso) El tamaño, la complejidad y los requisitos cambiantes ayudan al fracaso: los métodos ágiles pueden ayudar La idea de que podemos planificar algo desconocido fijando costo, plazo y alcance es un mito La forma usual en que se relacionan clientes y proveedores es en gran medida culpable de la pérdida de efectividad y eficiencia en los desarrollos 30

31 Invitación Los invito a incorporar la calidad en las propuestas de software La calidad debe considerarse en tres facetas Calidad del proyecto de software y disminución de riesgo Requisitos específicos de calidad del producto a entregar Capacidad del desarrollador (método, personas, proceso) 31

32 Preguntas?