GESTION DEL RIESGO

Los objetivos de la gestión de riesgo son identificar, controlar y eliminar

ACTIVIDADES DE LA GESTION DEL RIESGO

 Identificación del riesgo
 Proyección del riesgo
 Evaluación del riesgo
 Refinanciamiento del riesgo
 Reducción, supervisión y gestión del riesgo (anulación de riesgos y planes de contingencia)

1. IDENTIFICACION DE RIESGOS.
Consiste en crear una lista de verificación de riesgo, con esta se pueden identificar riesgos y enfocarse en algún subconjunto de
riesgos conocidos y predecibles en las siguientes sub-categorías genéricas:

 Tamaño del Producto: Riesgos  Impacto en el Negocio:

asociados con el tamaño Asociados con las
global del SW. restricciones que impone
la gerencia o el mercado.
 Características del cliente:  Definición del proceso:
Asociados con la Riesgos con el grado en
satisfacción del cliente. que se ha definido el
proceso
 Entorno de desarrollo:  Tecnología que construir:
Asociado con disponibilidad Asociado con la
y calidad de las complejidad del sistema
herramientas. que se construirá.
 Tamaño y experiencia de la
plantilla de personal:
Relacionado con la
experiencia técnica del
personal

Componentes y Controladores del riesgo:

el gestor del proyecto identifica los controladores del riesgo que afectan los componentes de riesgo el software.
• Riesgo en el rendimiento: el grado de incertidumbre con el que el producto encontrará sus requisitos y se adecue para su
empleo pretendido.
• Riesgo en el costo: el grado de incertidumbre que mantendrá el presupuesto del proyecto.
• Riesgo en el soporte: el grado de incertidumbre de la facilidad del software para corregirse, adaptarse y ser mejorado.
• Riesgo en 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.

Consecuencias:
Consecuencias potenciales de errores (filas etiquetadas con 1) o
La imposibilidad de conseguir el producto deseado (filas etiquetadas con 2)
2. PROYECCION DEL RIESGO
Denominada “Estimación del Riesgo”. Evalúa cada riesgo de 2 formas: la probabilidad de que el riesgo sea real y
las consecuencias de los problemas asociados con el riesgo suponiendo que aparece.
Pasos en la Proyección:
Establecimiento de una escala que refleje la probabilidad
observada de un riesgo
Definición de las consecuencias del riesgo
Estimación del impacto del riesgo en el proyecto y el producto
Anotación de la exactitud general de la proyección del riesgo
para que no haya malas interpretaciones.

3. EVALUACION DEL RIESGO

En este punto está establecido ternas de: La naturaleza (el riesgo), ámbito y tiempo [ri, li, xi].
 Naturaleza: problemas que son probables si ocurre, ej: interfaz externa mal definida hacia el hardware del
cliente
 Ámbito: combina la severidad (que tan serio es) con su distribución global (cuanto del proyecto se afectara)
 Tiempo: cuando y durante que periodo se sentirá el impacto

Pasos para determinar las consecuencias globales de un riesgo:

Determinar el valor promedio de la probabilidad de que ocurra para cada componente del riesgo
Determinar el impacto para cada componente, con base en los criterios (tabla componente/categoría)
Completar la tabla de riesgos y analizar los resultados

Ejemplo, Identificación del riesgo:

Solo el 70% de los componentes de software calendarizados para reutilización se integra en la aplicación. La
funcionalidad restante tendrá que desarrollarse de manera personalizada

Probabilidad del riesgo: 80 %

Impacto del riesgo: se planificaron 60 componentes de software reutilizables. Solo se puede emplear el 70%, 18
componentes tendrán que desarrollarse.
 Un componente promedio: 100 LDC y costo para cada uno es de 1,4 dólares,
  El costo (impacto) del desarrollo de los componentes seria:
18 X 100 X 1,4= 2520 dólares
Exposición al riesgo: ER= 0.80 X 2520 = 2020 dólares.

4. REFINAMIENTO DEL RIESGO

Refinar el riesgo es un conjunto de riesgos más detallado, cada uno un poco más sencillo de refinar, supervisar y
gestionar.
Identificación del riesgo: Solo el 70% de los componentes de software calendarizados para reutilización se integra en
la aplicación
 Subcondición 1: ciertos componentes de reutilización fueron desarrollados por un tercer participante sin
conocimiento de los estándares de diseño interno.
 Subcondición 2: el estándar de diseño para componentes de interfase no ha sido solicitado y tal vez no
concuerde con ciertos componentes reutilizables existentes.
 Subcondición 3: ciertos componentes reutilizables se han implementado en un lenguaje que no soporta el
entorno destino
5. REDUCCION, SUPERVISION Y GESTION DEL RIESGO

Todas las actividades del análisis del riesgo tienen una sola meta: ayudar a desarrollar una estrategia para luchar
contra el riesgo.
Una estrategia eficaz debe considerar:
 Evitar el riesgo
 Supervisar el riesgo
 Gestionar el riesgo y los planes de contingencia

Plan para Reducir el riesgo:

Ej: elevada movilidad del personal.
Elevada  La probabilidad de 70%
Impacto: se proyecta crítico en costo y calendario.

Plan: estrategia para reducir la movilidad (pasos).

 Reunir con personal para determinar causas de movilidad
 Reducir aquellas causas que se controlen antes de que comience el proyecto
 Asumir que la movilidad ocurrirá
 Organizar equipos para dispersar la información con amplitud
 Definir estándares de documentación
 Revisiones por pares de todo el trabajo
 Asignar miembro de respaldo por cada tecnología critica.
 FUNDAMENTOS DE CONSTRUCCION DE SOFTWARE
• Minimizar la complejidad
• Anticipación a los cambios
• Construcción Según Modelos de Desarrollo
• Planificación de la construcción

Minimizar la complejidad: La necesidad de reducir la complejidad aplica esencialmente a cada aspecto de la

'construcción del software', y es particularmente crítica en el proceso de verificación y pruebas.

Anticipar cambios: La naturaleza de los proyectos de software hace que en su gran mayoría sean desarrollos un gran
número de cambios y nuevos requerimientos que van surgiendo durante la ejecución del mismo.
Este es uno de los motivos por los cuales es importante desarrollar sistemas que puedan ser mantenibles, ya que
facilita estos procesos de modificación y actualización.

Construcción según modelos de desarrollo: Mientras más linear sea el enfoque más se tiende a enfatizar en las
actividades que preceden al proceso de construcción.

MODELO DE CONSTRUCCIÓN DE SOFTWARE

Existen muchos modelos de desarrollo de software distintos pero, ¿cómo saber cuál conviene más al proyecto? Para
responder a esta pregunta hay que conocer la importancia de la calidad, la velocidad o la creatividad, entre otras, y
establecer prioridades.

ESPIRAL
DESARROLLO ÁGIL

CASCADA
Planificación de la Construcción
Métricas de Construcción de Software
Numerosas actividades de la construcción y ciertos artefactos deben ser medidos, incluyendo el código desarrollado, el código
modificado, el código rehusado, el código destruido, la complejidad del código, las estadísticas del código, búsqueda y eliminación
de errores, esfuerzo y calendario. Estas medidas pueden ser útiles para los propósitos de la gerencia de la construcción,
asegurando la calidad durante la construcción, mejorando también el proceso de construcción.

CONSTRUCCIÓN DE SOFTWARE
Se refiere a la creación de software productivo y significativo a través de los procesos de codificación, verificación, pruebas
unitarias, pruebas de integración y depuración de errores.

Diseño de la Construcción
Algunos proyectos suelen colocar más actividades de diseño en la construcción, otros tienden a tener una fase exclusivamente a
diseño.
Lenguaje de Construcción
▪ Los lenguajes de construcción incluyen todas las formas de comunicación por las cuales el ser humano puede implantar
una solución ejecutable al computador.
Se pueden dividir en:
1. 'lenguaje de configuración'
2. Herramientas de prueba
3. Lenguajes de programación.

Pruebas de Software
Hay dos tipos de pruebas de software
1. Demostrar al desarrollador y al cliente que el software alcanza sus requisitos. En el caso de software hecho a la medida
esto representa que debe existir al menos 1 prueba por cada requerimiento. Para software pre-empaquetado significa
que debe existir al menos 1 prueba por cada funcionalidad y sus combinaciones
2. Descubrir situaciones donde el comportamiento del software es incorrecto, indeseable o no está ajustado a las
especificaciones. Estas son las consecuencias de defectos del software.

Calidad de construcción
▪ En la construcción del software, la calidad de diseño acompaña a la calidad de los requisitos, especificaciones y diseño
del sistema.
▪ La calidad de concordancia es un aspecto centrado principalmente en la implementación; Si la implementación sigue al
diseño, y el sistema resultante cumple con los objetivos de requisitos y de rendimiento, la calidad de concordancia es
alta.
Reutilización
▪ Implementar el re-uso del software involucra mucho más que crear librerías. Requiere formalizar la práctica del re-uso al
integrar procesos de re-uso y actividades dentro del ciclo de vida del software.
▪ El re-uso es lo suficientemente importante en la construcción del software que es incluido como un tópico.
Integración
El término "integración" hace referencia a una actividad de desarrollo de software que combina componentes de software
diferentes en un conjunto. La integración se realiza en varios niveles y fases de la implementación
▪ La integración del trabajo de un equipo que trabaja en el mismo subsistema de implementación antes de liberar el
subsistema para los integradores del sistema.
▪ La integración de subsistemas en un sistema completo.

ESTIMACION
Es más, un arte que una ciencia. Es la base de todas las demás actividades planificación.

En un proyecto de software se debe realizar estimaciones a cerca de:

 los costos del proyecto,
 los recursos necesarios y
 del tiempo requerido.
ESTIMACIÓN DEL PROYECTO DE SOFTWARE
Opciones para realizar estimaciones de costos y esfuerzos:

 Dejar la estimación para más adelante.

  Basar las estimaciones en proyectos similares ya terminados.
 Utilizar “técnicas de descomposición “.
 Utilizar uno o más modelos empíricos
 Adquirir una o varias herramientas automáticas de estimación.

MODELOS EMPIRICOS DE ESTIMACION

Un modelo de estimación para software utiliza formulas obtenidas empíricamente para predecir el esfuerzo
como una función de LDC o PF.

Clases de modelos de recursos:

 Modelos univariables estáticos: recurso = cons1 x (característica estimada) cons2
 Modelos multivariables estáticos: recurso = c11e1 + c21e2+…
 Modelos multivariables dinámicos: requisitos de recursos como función del tiempo
 Modelos teóricos: examina el software de forma microscópica (características del código fuente –
número de operandos y operadores)

GESTION DE LA CONFIGURACION DEL SOFTWARE

El desarrollo del software implica que haya cambios que se tienen que llevar a cabo.
Una serie de cambios descontrolados pueden convertirse en un caos comprometiendo la calidad del SW

La administración de la configuración del software es una actividad sombrilla que se aplica a lo largo del proceso de
software.

En ella se Coordina el desarrollo de SW para minimizar la confusión entre miembros de un equipo de SW.
Situaciones que fomentan la confusión:
 Los cambios no se analizan antes de que se realicen
 No se registran los cambios antes de que estos se implanten
 No se informan a quienes tienen la necesidad de conocerlos
No se controlan para mejorar la calidad y reducir el error

La ACS gestiona las modificaciones que ocurren mientras el software se desarrolla y después de que se libera a un
cliente.
Los objetivos son:
 Identificar los productos de trabajo que pueden cambiar
 Definir mecanismos para administrar distintas versiones de los productos de trabajo y controlar los cambios
 Garantizar que el cambio se implementó de manera adecuada
 Auditar los cambios e informar a todo el personal de SW que pueda estar interesado en cada cambio

Orígenes o Fuentes de Cambios del SW:

 Nuevas reglas empresariales o de mercado que cambien los requisitos del producto,
modificación de los datos a producir, funcionalidad ofrecida o servicios ofrecidos
 La reorganización o crecimiento/reducción de la empresa produce cambios en las
prioridades proyectadas o en la estructura del equipo de ingeniería del software
 Restricciones presupuestales o de calendario causan una redefinición del sistema o del
producto
Todos los ICS se almacenan dentro de un Repositorio que implementa un conjunto de mecanismos y estructuras de
datos para:

 Asegurar la integridad de los datos

 Proporcionar apoyo de integración para

otras herramientas de software

 Implementar funciones de apoyo al

control de versiones y de cambios.

Una vez desarrollado y revisado el objeto de configuración, se convierte en línea de referencia

Línea de Referencia o Línea Base: “es una especificación o producto que se revisó formalmente….
Que sirve como base para un mayor desarrollo y que puede cambiar solo a través de
procedimientos de control” (IEEE)

Los cambios a un objeto convertido en línea de referencia dan como resultado la creación de una
nueva versión de dicho objeto.
La evolución de un programa puede rastrearse al examinar la historia de revisión de todos los
objetos de configuración.

El Proceso de Gestión de la Configuración se desglosa en 5 actividades:

Identificación, control de versiones, control de cambios, auditorias de configuración y
generación de informes.

1. Identificación: Cada objeto tiene un conjunto

de características distintas:
a. Identificador (número, letra, ambos.
No ambiguo)
b. Nombre (descriptivo)
c. Tipo (documento, código, producto de
terceros, etc.)
d. Localización
e. Fecha
f. Versión (mayor, menor, revisión)
g. Estado (Ej. Para un documento En elaboración, finalizado, revisado, aceptado)
h. Proyecto/producto
Los objetos se relacionan entre ellos.

2. El control de versiones es el conjunto de procedimientos y herramientas que sirven para

administrar el uso de dichos objetos.

También se puede hacer que cada versión sea un conjunto de ICS, o sea que tenga: para la versión
2  Los elementos 1,2,3,4,5 en la variante 4
En cambio en la versión 1, se tiene los componentes 1,2,3 en la variante 1, y
4, 5 en la variante 3.
O sea que se suman distintas versiones de distintos ICS para hacer una versión más grande de
todo el programa.

3. El control de cambios es una actividad procedimental que garantiza la calidad y la consistencia

conforme se realizan cambios a un objeto de configuración.

El proceso de control de
cambios comienza con una
petición de cambios,
conduce a una decisión para
hacer o rechazar la petición
del cambio y culmina con
una actualización controlada
del ICS que debe cambiarse.

4. La auditoría de la configuración es una actividad SQA que ayuda a garantizar que la calidad se
conserva conforme se realizan cambios.
5. Generación de Informe: El reporte de estado proporciona información acerca de cada cambio a
quienes necesitan conocerla.
Básicamente se encarga de producir los informes para todos los cambios y cosas que se le hagan al
software por cada uno de los desarrolladores, así todos están al tanto de lo que se va haciendo, de
esta forma se evita el síndrome de la mano izquierda que ignora lo que hizo la derecha, y un
desarrollador va a cambiar lo que otro ya hizo.

METRICAS TECNICAS
Métricas del Diseño Arquitectónico
Estas métricas de diseño centradas en la arquitectura del programa, prestan importancia a la estructura
arquitectónica y a la eficiencia de los módulos.
Son de caja negra en el sentido que no requieren ningún conocimiento del trabajo interno de un módulo en
particular del sistema
Métricas de diseño en los componentes
Las métricas de diseño a nivel de componentes se concentran en las características internas de los
componentes del software e incluyen medidas de la cohesión, acoplamiento y complejidad del módulo.
Métricas de cohesión: Para medir la cohesión se puede usar el trabajo de Bieman y Ott, el cual define
varios conceptos:
 Número de elementos (tokens), Rebanada de datos (data slice), Adhesivo (glue) Superadhesivo
(superglue).
Con ellas se calcula la cohesión funcional fuerte
 CFF = número de superadhesivos / número de elementos
Cohesión Funcional Débil, se calcula así:
 CFD=número de adhesivos/ número de elementos.
Mientras más cercano sean CFF ó CFD a 1, mayor será la cohesión del módulo.

METRICAS DE DISEÑO DE INTERFAZ DE USUARIO

El diseño de interfaz de usuario o ingeniería de la interfaz es el resultado de definir la forma, función,
usabilidad, ergonomía y otros aspectos que afectan a la apariencia externa de las interfaces de usuario en
sistemas de todo tipo.
La conveniencia de la representación es una valiosa métrica de diseño de interfaces hombre-máquina que
se emplea para valorar diferentes distribuciones propuestas de IGU (Interfaz Gráfica de Usuario).
Una IGU típica usa entidades de representación como iconos gráficos, texto, menús, ventanas y otras
para ayudar al usuario a completar tareas. Para realizar una tarea dada usando una IGU, el usuario debe
moverse de una entidad de representación a otra. Las posiciones absolutas y relativas de cada entidad de
representación, la frecuencia con que se utilizan y el «coste» de la transición de una entidad de
representación a la otra contribuirán a la conveniencia de la interfaz.
Métricas orientadas a clases
Chidamber y Kemerer propusieron uno de los conjuntos de métricas de software OO de mayor referencia.
En ocasiones llamada suite de métricas CK. Una clase encapsula datos y la función que los manipula. Con
frecuencia es el “padre” de las subclases (en ocasiones llamadas hijos) que heredan sus atributos y
operaciones.
 PROFUNDIDAD DEL ÁRBOL DE HERENCIA (PAH): Esta métrica es “la máxima longitud desde el nodo hasta la raíz
del árbol”. Conforme crece la PAH, es probable que las clases de nivel inferior hereden muchos métodos. Esto
conduce a potenciales dificultades cuando se intenta predecir el comportamiento de una clase.
 NUMERO DE HIJOS (NDH): Las subclases que son inmediatamente subordinadas a una clase en la jerarquía de
clase se denominan hijos. Conforme crece el número de hijos, el reusó aumenta, pero también, como el NDH
aumenta, la abstracción representada por la clase padre puede diluirse si algunos de los hijos no son miembros
adecuados de la clase padre. Conforme el NDH aumenta, la cantidad de pruebas (requeridas para ejercitar cada
hijo en su contexto operativo) también aumentará.

Métricas de código fuente

Estás métricas asignadas como cuantitativas por Halstead, se derivan después de que se ha generado el
código o se estima una vez que el diseño esté completo.
Composición del lenguaje: token, operadores, palabras reservadas, identificadores, constante y signos
especiales. De esta forma se obtiene una medida más realista de la cantidad de información contenida en el
código fuente.
Las medidas son:
● n1: el número de operadores diferentes que aparecen en el programa.
● n2: el número de operandos diferentes que aparecen en el programa.
● N1: el número total de ocurrencias de operadores
● N2: el número total de ocurrencias de operandos
Volumen (V): Da un peso extra al número de operadores y operandos únicos. Por ejemplo, si dos
programas tienen la misma longitud N pero uno tiene mayor número de operadores y operandos únicos, que
naturalmente lo hacen más difícil de entender y mantener, este tendrá un mayor volumen.
Se calcula como V = N x log2(n) donde n = n1 + n2
Por ejemplo, consideremos el siguiente trozo de programa:
if (N < 2)
{ A = B * N;
System.out.println("El resultado es : " + A);
}
A partir de aquí se deduce:
● Operadores Únicos n1 = 6 (if, {}, system.out.println, =, *,<)
● Ocurrencias de Operadores N1 = 6 (if, {}, system.out.println, =, *,<)
● Operandos Únicos n2 = 4 (N, A, B, 2)
● Ocurrencias de Operandos N2 = 6 (N, 2, A, B, N, A)
Volumen (V) = 27.509 * log2(6+4) = 91.382

Métricas de Diseño para WebApps

El diseño web abarca actividades técnicas y otras que no lo son. La visión y el sentido del contenido se
desarrollan como parte del diseño gráfico, la plantilla estética de la interfaz de usuario se crea como parte de
diseño de la interfaz y la estructura técnica de la webapp se modela como parte del diseño arquitectónico y
de navegación.
Entre las métricas que se utilizan para el diseño de webApp están las siguientes:
● Métricas de interfaz.
● Métricas estéticas (Diseño gráfico).
● Métricas de contenido.
● Métricas de navegación
Métricas de Contenido: Las métricas en estas categorías se enfocan en la complejidad del contenido y en
los grupos de objetos de contenidos que se organizan en páginas.
● Complejidad de página (Número promedio de tipos diferentes de medios usados en la página).
● Complejidad gráfica (Número de medios gráficos por página).
● Complejidad de audio (Número promedio de audio por página).
● Complejidad de animación (Número promedio de animaciones por página).

MÉTRICAS ORIENTADAS A OBJETOS

El conjunto de métricas a usar debe dejar claro qué aspectos de la calidad son los que propone medir y a
quién van dirigidos. Subdivisiones:
Métricas a nivel de sistema Métricas a nivel de clases
Métricas a nivel de herencia Métricas a nivel de métodos

Métricas a nivel de Herencia: La relación de herencia se ve como un compromiso, es decir, un acuerdo

entre el rehúso que proporciona y la dificultad en el entendimiento y mantenibilidad de los sistemas. La
herencia puede ser sustituida por delegación, además reduce el acoplamiento ya que el cliente no conoce al
proveedor y este puede ser reemplazado sobre la marcha. El mecanismo de delegación debe ser tenido en
cuenta cuando el objetivo es la reutilización de código.
Número de hijos. (Number of Children –NOC-): Es un indicador del nivel de rehúso, la posibilidad de
haber creado abstracciones erróneas y es un indicador del nivel de test requerido. Es el número de subclases
subordinadas a una clase en la jerarquía, es decir, el número de subclases que pertenecen a una clase.
Métricas Orientadas a Operaciones
Existen menor cantidad de métricas de este tipo por el hecho de que son las clases las que preponderan en el
software OO. Tres métricas simples, propuestas por Lorenz y Kidd son apropiadas:
• Tamaño promedio de operación (TOprom): La cantidad de líneas de código no son una buena
unidad de medida para determinar la calidad de una operación, por lo tanto, para determinar ésta se
persigue la contabilización de mensajes
• Complejidad de la operación (CO): En este caso puede utilizarse cualquier métrica existente para el
software tradicional debido a que esta medición no se ve relacionada con el paradigma de la POO.
• Número promedio de parámetros por operación (NPprom): Tan largo como sea el número de
parámetros de operación, mas compleja será la colaboración entre objetos

Métricas para pruebas

Durante la etapa de pruebas se utilizaran las métricas de medida de amplitud, madurez y profundidad de
las pruebas, densidad de defectos, perfil de fallos, entre otras.
• Profundidad de las pruebas: es el Porcentaje de los caminos básicos independientes probados en
relación al total de ellos sumando la complejidad ciclomática de todos los módulos del programa.
• La densidad de defectos: ofrece una medida sobre la proporción de defectos con respecto a la
cantidad de elementos de especificación