Este documento trata sobre la especificación de sistemas críticos. Explica conceptos como la especificación dirigida por riesgos, la especificación de seguridad, protección y fiabilidad del software. También cubre la gestión de riesgos, incluyendo la identificación, análisis, evaluación y reducción de riesgos. Finalmente, detalla el proceso de identificación de riesgos en ingeniería de software, categorizando los riesgos por proyecto, organización, cliente, proceso, tecnología, entorno y equipo
2. ESPECIFICACIÓN DE SISTEMAS CRÍTICOS
Especificación dirigida por riesgos
Especificación de la seguridad
Especificación de la protección
Especificación de la fiabilidad del software
Gestión de Riesgos
3. ESPECIFICACIÓN DIRIGIDA POR RIESGOS
Comprender los riesgos con los que se enfrenta el
sistema o el proyecto de software y generar requerimientos
de confiabilidad para tratar dichos riesgos.
Contempla:
Identificación de riesgos
Análisis y clasificación de riesgos
Descomposición o clasificación de riesgos
Valoración y reducción de riesgos
4. ESPECIFICACIÓN DE LA SEGURIDAD
El proceso de especificación y garantia de seguridad es
parte de un ciclo de vida completo de seguridad
definido en un estandar internacional para la gestión de
la seguridad IEC 61508. Este estandar se desarrolló
especificamente para la protección de sistemas tales
como un sistema de parada de un tren si éste se salta
una señal en rojo.
Existen dos tipos:
Requerimientos de seguridad funcionales que
definen las funciones de seguridad del sistema
Requerimientos de integridad seguros que definen la
fiabilidad y la disponibilidad de la protección del
sistema.
5. ESPECIFICACIÓN DE LA PROTECCIÓN
La especificación de los requerimientos de
protección para los sistemas tiene algo en común
con los requerimientos de seguridad. No es
práctico especificarlos cuantitativamente, y los
requerimientos de protección son a menudo
requerimientos «no deberia» que definen
comportamientos inaceptables del sistema en lugar
de funcionalidades requeridas del mismo.
Algunos tipos de requerimientos:
Requerimientos de autenticación
Requerimientos de autorización
Requerimientos de inmunidad (antivirus)
Requerimientos de detección de intrusiones
Requerimientos de auditoria de seguridad
6. ESPECIFICACIÓN DE LA FIABILIDAD DEL SOFTWARE
La fiabilidad es un concepto complejo que siempre se debería
considerar a nivel de sistema en lugar de a nivel de
componente individual. Debido a que los componentes de un
sistema son interdependientes, un fallo en un componente puede
propagarse al resto del sistema y afectar el funcionamiento de
otros componentes
Tres dimensiones:
Fiabilidad del hardware (cuanto se tarda en reparar dicho
componente)
Fiabilidad del software (bugs ocultos, corrección inmediata?)
Fiabilidad del operador (probabilidad de cometer errores)
8. GESTIÓN DE RIESGOS
Identificar
Análisis: clasificar
Análisis:
Plan: asignar
Riesgos
y evaluar riesgos
Prioridades
y Aprobar
Prioridad
Asignaciones
listado de
Y planes
riesgo
aprobados
Clase, prob.,
Declaración
y contexto
del riesgo
impacto y
ocurrencia
del riesgo
Plan: define
Monitoreo de Riesgos
Control de riesgo
Reporte de
Decisiones
acciones
Plan para
contra
restar
el riesgo
situación
9. CONCEPTO DE RIESGO
El riesgo se halla de forma implícita asociado a toda
actividad:
Todo suceso se ve marcado por las acciones del pasado, ¿Se
puede, por tanto, actuar ahora para crear oportunidades en el
futuro?
El riesgo acompaña a todo cambio
El riesgo implica elección e incertidumbre.
10. EL FUTURO ES LO QUE NOS PREOCUPA, ¿QUÉ RIESGOS PODRÍAN
HACER QUE NUESTRO PROYECTO FRACASARA?
¿ Qué puede salir mal?
¿cuál es la probabilidad?
¿Cuál sería el daño?
¿Qué hacer al respecto?
11. ESTRATEGIAS FRENTE AL RIESGO
Estrategias reactivas
Método:
Evaluar las consecuencias del riesgo cuando este ya se ha
producido (ya no es un riesgo)
Actuar en consecuencia
Consecuencias de una estrategia reactiva
Apagado de incendios
Se pone el proyecto en peligro
12. ESTRATEGIAS FRENTE AL RIESGO
Estrategias proactivas
Método
Evaluación previa y sistemática de riesgos
Evaluación de consecuencias
Plan de evitación y minimalización de consecuencias
Plan de contingencias
Consecuencias
Evasión del riesgo
Menor tiempo de reacción
Justificación frente a los superiores
13. RIESGOS EN INGENIERÍA DE SOFTWARE
Características
Incertidumbre (Probabilidad de que ocurra)
Pérdidas
Producto
Rendimiento
Mantenimibilidad
Proceso de producción
Tiempo de desarrollo
Coste
14. RIESGOS EN INGENIERÍA DE SOFTWARE
Riesgos del proyecto
Incremento en costes
Desbordamiento organizativo
Riesgos técnicos
Riesgos del negocio
De mercado
De estrategia
De ventas
De gestión
De presupuesto
15. IDENTIFICACIÓN DE RIESGOS
Grupos de riegos
Genéricos: Son comunes a
todos los proyectos
Específicos: Implican un
conocimiento profundo del
proyecto
Categorías
Relacionados con el tamaño del
producto
Con el impacto en la
organización
Con el tipo de cliente
Con la definición del proceso de
producción
Con el entorno de desarrollo
Con la tecnología
Con la experiencia y tamaño del
equipo
16. IDENTIFICACIÓN DE RIESGOS
Asociados
Tamaño
con el tamaño del producto
estimado del proyecto (LOC/PF)
Confianza en la estimación
Numero de programas, archivos y
transacciones
Tamaño relativo al resto de proyectos
Tamaño de la base de datos
Número de usuarios
Número de cambios de requerimientos
previstos antes y después de la entrega
Cantidad de software reutilizado
17. IDENTIFICACIÓN DE RIESGOS
Impacto
en la organización
Efecto del producto en la cifra de ventas
Visibilidad desde la dirección de la organización
Fecha límite de entrega razonable
Número de clientes que usarán el producto
Numero de productos con los que deberá interaccionar
Sofisticación del usuario final
Cantidad y calidad de la documentación a entregar al cliente
Límites legales y gubernamentales
Costes asociados al retraso en la entrega
Costes asociados a errores en el producto
18. IDENTIFICACIÓN DE RIESGOS
Relacionados
con el cliente
Hay experiencias anteriores con dicho cliente
Tiene una idea clara de lo que precisa
Está dispuesto a dedicar tiempo en la especificación
formal de requerimientos
Está dispuesto a relacionarse de forma ágil con el
equipo de desarrollo
Está dispuesto a participar en la revisiones
Es un usuario experto
Dejará trabajar al equipo de desarrollo sin dar consejos
de experto informático
Entiende el ciclo de vida de una aplicación
19. IDENTIFICACIÓN DE RIESGOS
Riesgos del proceso de producción
Hay una política clara de normalización y seguimiento de una
metodología
Existe una metodología escrita para el proyecto
Se ha utilizado en otros proyectos
Están los gestores y desarrolladores formados
Conoce todo el mundo los standards
Existen plantillas y modelos para todos los documentos resultado
del proceso
Se aplican revisiones técnicas de la especificación de
requerimientos diseño y codificación
Se aplican revisiones técnicas de los procedimientos de revisión y
prueba
20. IDENTIFICACIÓN DE RIESGOS
Riesgos
del proceso de producción
(cont.)
Se documentan los resultados de las revisiones
técnicas
Hay algún mecanismos para asegurar que un proceso
de desarrollo sigue los estándares
Se realiza gestión de la configuración
Hay mecanismos para controlar los cambios en los
requerimientos que tienen impacto en el software
Se documenta suficientemente cada subcontrato
Se ha habilitado y se siguen mecanismos de
seguimiento y evaluación técnica de cada subcontrato.
21. IDENTIFICACIÓN DE RIESGOS
Respecto
del proceso de
producción (cont.)
Se dispone de técnicas de especificación de
aplicaciones para facilitar la comunicación con el
cliente.
Se usan métodos específicos para análisis de software
Se utiliza un método específico para el diseño
arquitectónico y de datos
Está el 90% del código en lenguajes de alto nivel
Hay estándares de documentación de código
Se usan métodos específicos para el diseño de pruebas
Se utilizan herramientas para llevar a cabo la
planificación y control
22. IDENTIFICACIÓN DE RIESGOS
Riesgos
del proceso de producción
(cont.)
Se utiliza software de gestión de configuraciones para
controlar y seguir las actividades a lo largo del proceso
Se utilizan herramientas para soportar el análisis y el diseño
Se utilizan herramientas de prototipación
Se utilizan herramientas para soportar la fase de pruebas
Se utilizan herramientas para la generación y mantenimiento
de la documentación
Se disponen métricas de calidad para todos los proyectos de
software
Se disponen de métricas de productividad
23. IDENTIFICACIÓN DE RIESGOS
Riesgos
tecnológicos
Se trata de una tecnología nueva en la organización
Se requieren nuevos algoritmos o tecnología de I/O
Se debe interactuar con hardware nuevo
Se debe interactuar con software que no ha sido
probado
Se debe interactuar con un B.D. cuya funcionalidad y
rendimiento no ha sido probada
Es requerido un interface de usuario especializado
Se necesitan componentes de programa radicalmente
diferentes a los hasta ahora desarrollados
24. IDENTIFICACIÓN DE RIESGOS
Riesgos
Se
tecnológicos (cont.)
deben utilizar métodos nuevos de análisis, diseño o
pruebas
Se deben utilizar métodos de desarrollo no habituales,
tales como métodos formales, Inteligencia Artificial o
redes neuronales
Se aplican requisitos de rendimiento especialmente
estrictos
Existen dudas de que el proyecto sea realizable
25. IDENTIFICACIÓN DE RIESGOS
Respecto al entorno de desarrollo
Hay herramientas de gestión de proyectos
Hay herramientas de gestión del proceso de desarrollo
Hay herramientas de análisis y diseño
Hay generadores de código apropiados para la
aplicación
Hay herramientas de prueba apropiadas
Hay herramientas de gestión de configuración
apropiadas
26. IDENTIFICACIÓN DE RIESGOS
Respecto al entorno de desarrollo (cont.)
Se hace uso de una base de datos o repositorio
centralizado
Están todas las herramientas de desarrollo integradas
Se ha proporcionado formación a todos los miembros
del equipo de desarrollo
Hay expertos a los cuales solicitar ayuda acerca de las
herramientas
Hay ayuda en línea y documentación disponible
27. IDENTIFICACIÓN DE RIESGOS
Asociados
al equipo y la experiencia
Es el mejor personal disponible
Tienen los miembros las técnicas apropiadas
Hay suficiente gente disponible
Está el personal comprometido en toda la duración del
proyecto
Habrá parte del personal dedicado solamente en parte
al proyecto
Tiene el personal las expectativas correctas del trabajo
Tiene el personal la necesaria formación
Puede la rotación del personal perjudicar el proceso de
desarrollo
28. COMPONENTES DEL RIESGO
Se identifican cuatro
componentes del riesgo en
un proyecto software
Rendimiento
Costo
Mantenibilidad
Planificación
Tras identificar los factores
de riesgo, es necesario
averiguar a qué
componentes del riesgo
afectan y en qué medida
Despreciable
Marginal
Crítica
Catastrófica
29. ESTIMACIÓN DE RIESGOS
Creación de una tabla de riesgos
Riesgo
Categoría
Tamaño estimado demasiado pequeño
Proyecto
Probabilidad
40 %
Mas número de usuarios de lo planificado
Proyecto
30 %
Cliente cambie los requerimientos
Proyecto
80 %
Falta de experiencia en herramientas
Entorno
Desarrollo
Equipo
80 %
Rotación demasiado alta
60 %
Impacto
Planificación
Crítico
Rendimiento
Marginal
Costos
Crítico
Planificación
Marginal
Planificación
Crítica
RM
MM
30. ESTIMACIÓN DE RIESGOS
Ordenación y filtrado
Ordenación por probabilidad y prioridad
Despreciar riesgos poco probables y los medianamentes
probables con poco impacto
Riesgo
Categoría
Cliente cambie los requerimientos
Falta de experiencia en herramientas
Projecto
Entorno
Desarrollo
Equipo
Proyecto
Proyecto
Rotación demasiado alta
Tamaño estimado demasiado pequeño
Mas número de usuarios de lo planificado
Probabilidad
80 %
80 %
Impacto
60 %
40 %
30 %
Crítica
Crítico
Marginal
Crítico
Marginal
RMMM
31. ESTIMACIÓN DE RIESGOS
Factores que definen el impacto de la ocurrencia
de un riesgo
Alcance del mismo: cuán serio y cuánto del proyecto se
ve afectado
Temporalización de los efectos, cuándo y por cuánto
tiempo
32. ESTIMACIÓN DE RIESGOS
Cuándo desistir y finalizar el proyecto
Se debe definir un punto de referencia
Se debe marcar la relación entre cada factor de riesgo
enumerado y el punto de referencia
Definir el área de incertidumbre, donde será tan válido
continuar como interrumpir el trabajo
Predecir cómo la combinación de riesgos afectará a los
niveles de referencia
33. GESTIÓN, MONITORIZACIÓN Y MITIGACIÓN DE
RIESGOS (RMMM)
Objetivo: Marcar las estrategias y formas de actuar del
equipo de trabajo frente a los riesgos:
Como evitarlos
Como monitorizarlos
Como gestionarlos y plan de contingencia
34. GESTIÓN, MONITORIZACIÓN Y MITIGACIÓN DE
RIESGOS (RMMM)
Como evitar el riesgo
Definir las estrategias necesarias para evitar que el riesgo no se
produzca
Tomar las medidas encaminadas para que, aún cuando se
produzca, se minimecen sus efectos
35. GESTIÓN, MONITORIZACIÓN Y MITIGACIÓN DE
RIESGOS (RMMM)
Monitorización del riesgo
Definir los indicadores que influyen en la probabilidad de que el
riesgo se produzca
Monitorizar periódicamente dichos factores
Monitorizar la efectividad real de las acciones encaminadas a
evitar el riesgo
36. GESTIÓN, MONITORIZACIÓN Y MITIGACIÓN DE
RIESGOS (RMMM)
Gestión del riesgo y plan de contingencia
Se asume que no se puedo evitar el riesgo y la monitorización ha
fallado y el riesgo se ha producido
Se definen las estrategias y acciones a tomar para evitar que los
efectos se minimicen
Nunca se podrá reducir a cero el costo del plan de contingencia.
Dicho plan puede implicar unos costos en sí mismo, por lo cual se
ha de valorar el beneficio que se espera obtener de éste
37. CONCLUSIONES
Debemos estar consientes de ello
Se requiere una correcta identificación y categorización
Es necesario un plan para evitarlos o minimizarlos
Es imprescindible un correcto seguimiento (Monitorear los
riesgos)
Reservar un presupuesto para administrar o gestionar los riesgos
No somos perfectos… debemos encarar los riesgos con mucha
altura