1 ANÁLISIS Y GESTIÓN DEL RIESGO + C ONTROL DE LA CALIDAD Integrantes del Equipo: Judith Guadalupe Barrios Hernández Gonzalo Iván Jiménez Leyva José Rubén López Sosa

2 ANÁLISIS Y GESTIÓN DEL RIESGO “Más vale prevenir, que lamentar”

3 ¿Que es? ¿Quién lo hace? ¿Por qué es importante? ¿Cuáles son los pasos? ¿Cuál es el producto obtenido? ¿Cómo puedo estar seguro de que lo he hecho correctamente?

4 Riesgo: la combinación de la probabilidad y consecuencias de la ocurrencia de un evento peligroso determinado. Evaluación de riesgos: el proceso global de estimar la magnitud del riesgo y de decidir si un riesgo es tolerable o no. Peligro: fuente o situación con el potencial de causar daños en términos de lesiones o enfermedades ocupacionales, daños a la propiedad, daños al ambiente, o una combinación de éstos. Identificación de peligros: el proceso de reconocer que un peligro existe y de definir sus características.

5 RIESGOS DEL SOFTWARE Incertidumbre: El acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por ejemplo, no hay riesgos de un 100% de probabilidad (ya que un riesgo del 100% es una limitación del proyecto). Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o pérdidas.

6 ESTRATEGIAS DE RIESGO PROACTIVAS VS REACTIVAS Proactivas.- se consideran desde antes de que ocurran los riesgos. Reactivas.- se realizan cuando aparece el problema y vienen los errores.

7 RIESGOS DEL PROYECTO Problemas potenciales de presupuesto Planificación temporal Personas (Asignación y organización) Recursos Cliente, requerimientos y su impacto en el proyecto software La complejidad del proyecto Tamaño y grado de incertidumbre estructural

8 R IESGOS T ÉCNICOS Diseño Implementación De interfaz Verificación Mantenimiento Las ambigüedades de especificaciones Tecnologías

9 R IESGOS DEL N EGOCIO Construir un producto o sistema excelente que no quiere nadie en realidad (Riesgo de Mercado). Construir un producto que no encaja en la estrategia comercial general de la compañía (Riesgo Estratégico). Construir un producto que el departamento de ventas no sabe cómo vender.

10 Perder el apoyo de una gestión experta debida a cambios de enfoque o a cambios de personal (Riesgo de Dirección). Perder presupuesto o personal asignado (Riesgo de Presupuesto).

11 IDENTIFICACIÓN Y CLASIFICACIÓN DEL RIESGO Riesgos Genéricos: Son una amenaza potencial para todos los proyectos de software. Riesgos específicos: Los riesgos específicos de producto sólo los pueden identificar los que tienen una clara visión de la tecnología, el personal y el entorno específico del proyecto en cuestión.

12 R IESGOS ESPECÍFICOS Tamaño del producto. Impacto en el negocio. Características del cliente. Definición del proceso. Entorno de desarrollo. Tecnología a construir. Tamaño y experiencia de la plantilla.

13 PROYECCIÓN DEL RIESGO Establecer una escala que refleje la probabilidad percibida del riesgo. Definir las consecuencias del riesgo. Estimar el impacto del riesgo en el proyecto y en el producto. Apuntar la exactitud general de la proyección del riesgo de manera que no haya confusiones.

14 C OMPONENTES Y CONTROLADORES DEL RIESGO Riesgo de rendimiento: el grado de incertidumbre con el que el producto encontrará sus requerimientos y se adecue para su empleo pretendido. Riesgo de costo: El grado de incertidumbre que mantendrá el presupuesto del proyecto. Riesgo de soporte: El grado de incertidumbre de la facilidad del software. para corregirse, adaptarse y ser mejorado. Riesgo de la planificación temporal: El grado de incertidumbre con que se podrá mantener la planificación temporal y de que el producto se entregue a tiempo.

15 Componentes Categoría RendimientoSoporteCosto Planificación Temporal Catastrófico 1 Dejar de cumplir los requerimientos provocaría fracaso de la misión. Malos resultados en un aumento de costos y retrasos de la planificación temporal con cifras que superan los US$500.000. 2 Degradación significativa para no poder alcanzar el rendimiento técnico. El software no responde o no admite soporte. Recortes financieros significativos, presupuestos excedidos. Fecha de entrega inalcanzable. Crítico 1 Dejar de cumplir los requerimientos degradaría el rendimiento del sistema hasta un punto donde el éxito de la misión es cuestionable. Malos resultados en retrasos operativos y/o aumento de costo con valor esperado de US$100.000 a US$500.000. 2 Alguna disminución en el rendimiento técnico. Pequeños retrasos en modificaciones de software. Algunos recortes de los recursos financieros, posibles excesos del presupuesto. Posibles retrasos de la fecha de entrega. Marginal 1 Dejar de cumplir los requerimientos provocaría la degradación de la misión secundaria. Los costos, impactos y/o retrasos recuperables de la planificación temporal con un valor estimado de US$1000 a US$100.000. 2 De mínima a pequeña reducción en el rendimiento técnico. EL soporte del software no responde. Recursos financieros suficientes. Planificación temporal realista, alcanzable. Despreciable 1 Dejar de cumplir los requerimientos provocaría inconvenientes o impactos no operativos. Los errores provocan impactos mínimos en el costo y/o planificación temporal con un valor esperado de menos de US$1000. 2 No hay reducción en el rendimiento técnico. Software fácil de dar soporte.Posible superávit de presupuesto. Fecha de entrega fácilmente alcanzable.

16 C ONTROL DE C ALIDAD DEL S OFTWARE “La calidad nunca es un accidente; siempre es el resultado de un esfuerzo de la inteligencia.”

17 C ALIDAD : La CALIDAD es una característica o atributo de una entidad Que le otorga la capacidad de satisfacer necesidades explícitas E implícitas. Como atributo de una entidad, la calidad se refiere a las características mensurables. *Tipos de calidad de acuerdo a características mensurables: La calidad de diseño: Se refiere a las características que los Ingenieros de software especifican para un artículo. El grado De materiales, tolerancias, y especificaciones del rendimiento, Todos contribuyen a la calidad del diseño. La calidad de concordancia: es el grado del cumplimiento de las especificaciones de diseño durante su realización.

18 C ONTROL DE C ALIDAD G ARANTÍA DE C ALIDAD Engloba todo el proceso de desarrollo: supervisar y mejorar el proceso, asegurar que se siguen los procedimientos acordados, que se alcanza el nivel de calidad deseado y que se localicen y resuelven los problemas. Concordancia con los requisitos funcionales y de rendimiento explícitamente establecidos, y con las características implícitas que se esperan.

19 Puntos importantes de la Garantía de Calidad: *Los requisitos del software son la base de la medida de la calidad. *Los estándares especificados definen un conjunto de criterios de desarrollo que guían la forma en que aplica la ingeniería de software. *Existe un conjunto de requisitos implícitos que a menudo no se mencionan.

20 C OSTE DE C ALIDAD El coste de calidad incluye todos los costes acarreados en la Búsqueda de la calidad. Se dividen en: *Costos de Prevención: Planificación de la calidad, Revisiones Técnicas formales, Equipo de pruebas y formación *Coste de Evaluación: Inspección en el proceso y entre procesos, Calibración, y mantenimiento de equipo y pruebas. *Coste de Fallos (Internos): Revisión, Reparación y análisis de la Modalidades de fallos. *Coste de Fallos(Externo):Resolución de quejas, devolución y Sustitución de productos, soporte de línea de ayuda y trabajo De garantía.

21 Anécdota IBM: Se han dedicado 7.053 horas inspeccionando 200.000 líneas de código resultado de 3.112 errores potenciales descubiertos. Dado por sentado un coste de programador de 40 dólares por Hora, el coste de eliminar 3.112 defectos ha sido de 282.120 dólares, o aproximadamente unos 91 dólares por defecto.

22 Costo Relativo de corregir un error 1 40-1000 30-70 15-40 10 3-6 C OP SP MCDR Costo Relativo de Corregir un Error

23 R EVISIONES DEL S OFTWARE Son un filtro para el proceso de ingeniería del software. Una revisión, cualquier revisión es una forma de aprovechar la Diversidad de un grupo de personas por: *Señalar la necesidad de mejoras en el producto. *Confirmar las partes de un producto donde no se necesitan Las mejoras. * Conseguir un trabajo técnico de una calidad más uniforme.

24 I MPACTO DE LOS DEFECTOS DEL SOFTWARE SOBRE EL COSTO Un defecto se define como una anomalía del producto. Una serie de estudios indican que las actividades del diseño Introducen entre el 50 al 65 por ciento de todos los errores Durante el proceso de software. Con la detección y la eliminación de un gran porcentaje de Errores, el proceso de revisión reduce substancialmente el coste De los pasos siguientes.

25 R EVISIÓN F ORMAL T ÉCNICA (RTF) D EFINICIÓN Una revisión técnica formal (RTF) es una actividad de control de calidad del software, constituida por alguna de los siguientes tipos de evaluaciones ejecutados en reuniones RTF. Algunos ejemplos son: Recorridos (Walkthroughs). Inspecciones. Revisiones cíclicas. Revisiones por pares. Etc.

26 R EVISIÓN F ORMAL T ÉCNICA (RTF) O BJETIVOS 1) Descubrir errores en la función, lógica o implementación. 2) Verificación. 3) Garantizar que el software se ha representado de acuerdo con los estándares predefinidos. 4) Controlar un desarrollo uniforme. E) Compartir experiencia.

27 J UNTA DE R EVISIÓN F ORMAL P REPARACIÓN

28 J UNTA DE R EVISIÓN F ORMAL R EALIZACIÓN RTF

29 J UNTA DE R EVISIÓN F ORMAL C ONSIDERACIONES 1. Revisar el producto, no al productor. 2. Establecer una agenda y respetarla. 3. Limitar el debate y la impugnación. 4. Enunciar áreas de problemas, pero no se intente resolver todos los que se hayan señalado. 5. Tomar notas. 6. Limitar el número de participantes e insistir en la preparación anticipada. 7. Desarrollar una lista de verificación para cada producto que tenga probabilidad de ser revisado. 8. Asignar recursos y programar las RTF. 9. Realizar un entrenamiento significativo de todos los revisores. 10. Analizar las revisiones previas.

30 R EVISIONES BASADAS EN MUESTRAS O PCIÓN ALTERNATIVA A RTF Las revisiones por muestras consiste en seleccionar partes del producto total a revisar, evaluarlos y a partir de estos estimar la cantidad de errores totales. Efectivo cuando no se dispone del tiempo necesario para realizar las RTF.

31 S EGURIDAD DEL SOFTWARE D EFINICIÓN La seguridad del software es una actividad de aseguramiento de la calidad de software que se enfoca en la identificación y evaluación de los peligros potenciales que pueden afectar negativamente al software y provocar una falla de todo el sistema.

32 N ORMAS, ESTÁNDARES, ETC. Una norma de calidad es un documento, establecido por consenso y aprobado por un organismo reconocido, que proporciona para un uso común y repetido, una serie de reglas, directrices o características para las actividades de calidad o sus resultados, con el fin de conseguir un grado óptimo de orden en el contexto de la calidad. -Wikipedia

33 ¿Qué Hacemos? Producto/Servicio ¿Para quien? Cliente ¿Cómo lo hacemos? Procesos Nuestra Misión

34 P ROCESO D EFINICIÓN Conjunto de actuaciones, decisiones, actividades y tareas que se encadenan de forma secuencial y ordenada para conseguir un resultado que satisfaga plenamente los requerimientos del cliente al que va dirigido“. El conjunto de actividades secuenciales que realizan una transformación de una serie de inputs (material, mano de obra, capital, información, etc.) en los outputs deseados (bienes y/o servicios) añadiendo valor

35 G ESTIÓN POR PROCESOS O BJETIVOS Reducir la variabilidad innecesaria. Eliminar las ineficiencias asociadas a la repetitividad de las acciones o actividades. Evitar el consumo inapropiado de recursos. Permite dividir y evaluar las actividades.

36 G ESTIÓN POR PROCESOS T IPOS DE PROCESOS Procesos clave. Procesos de soporte. Procesos base. Procesos de operación.

37 G RACIAS POR SU ATENCIÓN