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

1. INGENIERIA DE REQUERIMIENTOS
MODULO VI
CAPITULO
4:
ESPECIFICACIÓN DE SISTEMAS CRÍTICOS
Ing. Edson A. Terceros Torrico
edsonariel@gmail.com

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)

7. GESTIÓN DE RIESGOS

Introducción
Concepto
 Estrategias
 Riesgos en Ingeniería de Software

Identificación de riesgos
 Estimación riesgos
 Plan de riesgos


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