Identificación de Riesgos - SEI v1.5

Identificacin de Riesgos (SEI)
Basado en taxonoma de desarrollo de Software
2011
ndice
Introduccin
Contexto
Mtodo
Observaciones finales
ndice
Introduccin
Contexto
Mtodo
Introduccin
El riesgo en si no es malo, es esencial para el progreso, y el

fracaso es a menudo una parte esencial del aprendizaje, pero
tenemos que aprender a equilibrar las posibles consecuencias
negativas de los riesgos contra los beneficios potenciales
asociados a su oportunidad.
VanScoy,RogerL. Software Development
Risk: Opportunity, Not Problem.
Software Engineering Institute (SEI)
Los riesgos de un proyecto se ubican siempre en el futuro. Un

riesgo es un evento o condicin incierta que, si sucede, tiene
un efecto en por lo menos uno de los objetivos del proyecto.
PMBOK 4.0
Introduccin
Identificar riesgos es labor de participacin

fundamental de cada participante de un proyecto.
Este documento presenta la tcnica de Identificacin de

riesgos basado en la taxonoma de desarrollo de
Software.
La taxonoma proporciona un marco para clasificar, organizar

y estudiar los diversos aspectos e instancias del desarrollo de
software, facilitando as la identificacin de los riesgos
asociados.
El mtodo a estudiar consiste de un instrumento

cuestionario basado en la taxonoma (TBQ) y un
proceso para su aplicacin.
activa
ndice
Introduccin
Contexto
Mtodo
Contexto - Modelo
El modelo que apoya la gestin integral de riesgos considera

los siguientes elementos fundamentales:
Identificarlos (a estudiar en este documento)

Analizar su informacin
Planificar las acciones de respuesta
Seguir su evolucin
Controlar y corregir desvos del plan
Comunicar la informacin que generan
Identificar
controlar
Analizar
Comunicar
La clave para la planificacin de

respuestas a los riesgos es:
considerar las consecuencias
futuras de una decisin tomada
hoy.
Seguir
Planificar
Modelo de administracin de
Riesgos
Contexto Identificacin de riesgos
Es prioritario identificar los riesgos antes de que se conviertan

en problemas e impacten en los objetivos del proyecto.
Este documento concentra nuestra atencin en la

taxonoma de desarrollo de SW y el
cuestionario basados en Taxonoma.
El cuestionario y proceso de aplicacin

controlar
son la herramienta que estudiaremos para
poder lograr una identificacin de riesgos
eficaz y eficiente.
Identificar
Analizar
Comunicar
Seguir
Planificar
Riesgos
Contexto Anlisis de riesgos levantados
El anlisis es la conversin de datos de riesgo en informacin

para decidir que accin tomar con el riesgo.
El anlisis proporciona la base para el gerente de

proyecto y as trabajar en el riesgo correcto.
Identificar
Cubre principalmente probabilidad e

Impacto de cada uno facilitando con
controlar
ello la priorizacin en la atencin y respuesta
a aplicar.
Analizar
Comunicar
Seguir
Planificar
Riesgos
Contexto Planificacin de respuestas
Convierte la informacin del riesgo en decisiones y acciones

(presentes y futuro).
Permite desarrollar acciones para hacer frente a

los riesgos individuales, priorizar las acciones del
riesgo, y crear un plan integral de gestin
de riesgos.
Identificar
controlar
Es importante para proporcionar los recursos

y el tiempo suficientes para las actividades
de gestin de riesgos y establecer los
acuerdos para evaluar los riesgos.
Analizar
Comunicar
Seguir
Planificar
Riesgos
Contexto Seguimiento de evolucin de los riesgos
Es la supervisin del estado del riesgo y las medidas

adoptadas para atender y manejar su probabilidad e impacto.
Se identifican parmetros adecuados y son

controlados para permitir la evaluacin de la
situacin del riesgo y de los planes de
respuesta al mismo.
Identificar
controlar
Analizar
Comunicar
Seguir
Planificar
Riesgos
Contexto Control de la evolucin
Permite tomar medidas de correccin a las desviaciones en las

acciones planificadas.
El control de riesgos se funde con la gestin de

proyectos y se basa en los procesos de gestin de
proyectos para el control de los planes
de accin de riesgos.
Identificar
controlar
Analizar
Comunicar
Seguir
Planificar
Riesgos
Contexto Comunicar la informacin generada
La comunicacin de riesgos se encuentra en el centro del

modelo destacando la trascendencia de su alcance, debido a
que:
Facilita la interaccin entre los elementos del

modelo, y hacia los Stakeholders (Sponsor, cliente,
Identificar
Usuarios, etc.)
Es la componente que condiciona la

efectividad del mtodo y que registra y
difunde la informacin generada por los
controlar
Analizar
Comunicar
Riesgos.
Seguir
Planificar
Riesgos
ndice
Introduccin
Contexto
Mtodo
Mtodo - Bases
Los riesgos en un proyecto pueden ser :
Conocidos: Una o ms personas del proyecto son conscientes de

l, Pero no ha sido registrado en la gestin de riesgos.
Desconocidos: Aquel que nadie del proyecto poda prever, por
ende no ha sido informado ni registrado.
SEI trabaja sobre estos tipos y para ello dispone un mtodo

para su identificacin efectiva, apoyada en:
Clasificacin de instancias del desarrollo de software (Taxonoma)

Cuestionario que se basa en cada clase, elemento y atributo
estructurados en la taxonoma(Taxonomy-Based Questionnaire
TBQ)
Comunicacin efectiva de los resultados de identificacin hacia
cada instancia de la gestin de riesgos como a todos los
interesados del proyecto.
Mtodo - Bases
El enfoque principal es sobre los riesgos que se sabe an no

han sido comunicados a la gestin de proyectos.
Est diseado para asegurarse de que las preguntas

formuladas sean respondidas por las personas adecuadas y
de la forma correcta , as con ello producir resultados
ptimos.
Este mtodo permite que los riesgos sean identificados sin

justificacin y sin una propuesta de solucin, de ello se
encarga otra instancia del modelo de gestin de riesgos.
Mtodo - Bases
Las preguntas y su secuencia se utilizan como una definicin,

pero no como un instrumento de limitacin, es decir, permite
que los temas sensibles al contexto y a la cultura afloren de
una manera natural. . . La pragmtica es primordial.
En efecto, el mtodo TBQ se puede describir como una

forma de lluvia de ideas estructurada.
Ayuda a aclarar las incertidumbres y preocupaciones del

personal tcnico y de gestin de un proyecto, por el
conocimiento y experiencia que poseen de sus temas,
proporcionando empoderamiento y seguridad al equipo.
Mtodo - Supuestos
Los riesgos son conocidos generalmente por el personal

tcnico del proyecto, pero no estn bien comunicados.
Es indispensable contar con un mtodo estructurado y

repetible para la identificacin de riesgos.
Una Identificacin de riesgos eficaz debe cubrir todas las

claves del desarrollo y reas de apoyo del proyecto.
El proceso de identificacin de riesgos debe crear y mantener

un entorno de riesgo sin prejuicios, de modo de permitir que
todas las opiniones, an siendo controversiales, sean
escuchadas.
Mtodo - Taxonoma de desarrollo de software
Obtiene, clasifica y organiza toda la amplitud de los riesgos en

desarrollo de software tanto tcnicos como no tcnicos,
basndose en la clasificacin de las instancias de desarrollo
de SW.
Las instancias clasificadas inicialmente se organizan en tres

clases principales:
A. Ingeniera del Producto

B. Ambiente de desarrollo
C. Limitaciones del programa
Estas tres clases se dividen en Elementos y cada elemento es

caracterizado por sus atributos. (Ver el siguiente mapa)
Mapa Taxonmico de riesgos en desarrollo de

SW
Clase
Elemento
Atributo
Este mapa muestra a modo resumido las agrupaciones propuestas

por la taxonoma y distingue las caractersticas del desarrollo de
SW , por lo tanto los riesgos de cada una de ellas.
A continuacin se detalla el concepto de cada uno de los

componentes de este mapa para cada clase, elemento y atributo.
Clase A. Ingeniera del producto

1.2.- Diseo 3.- Cdigo y 4.5.Requisitos
pruebas
Integraci Especialidad
unitarias
ny
es de la
Eleme
pruebas ingeniera
ntos
a.
a.
a. Factibilidad a.
a. Capacidad
Estabilidad Funcionalida
Ambiente de
d
mantenimient
o
b.
b. Dificultad b. Pruebas
b. Producto b.
Completitud
Confiabilidad
c. Claridad c. Interfaces c.
c. Sistema c. Seguro
Codificacin /
Implementaci
n
d. Validez d.
d. Con
Rendimiento
seguridad
e.
e.
e. Factores
Factibilidad Testeabilida
Humanos
d
At
ri
bu
to
s
Se refiere a la ingeniera de sistemas y actividades de

ingeniera de software necesarios para crear un sistema que
satisfaga los requisitos especificados y las expectativas del
cliente, Incluyendo los siguientes elementos:
1. Requisitos:
abarcan tanto la calidad de la especificacin de

requisitos como tambin la dificultad de implementar un sistema
que satisfaga dichos requisitos. Este elemento tiene los siguientes
atributos:
a)
Estabilidad: Grado en que las necesidades estn cambiando y como

impactan en la calidad, funcionalidad, programacin, diseo,
integracin y pruebas del producto en construccin.

b)
c)
d)
e)
f)
g)
Completitud: Especificacin de requerimientos con falencias en que

no son indicados adecuadamente para desarrollar los criterios de
aceptacin.
Claridad: Se refiere a la imprecisin y ambigedad del registro de
requerimientos que no se resuelven hasta el final de la fase de
desarrollo.
Validez: Se refiere a si las necesidades globales reflejan las
intenciones de los clientes para con el producto.
Viabilidad: Se refiere a la dificultad de la implementacin de un
nico requisito tcnico u operacional, o de cumplir con requisitos en
conflicto de forma simultnea.
Precedente: Se refiere a las capacidades que no se han aplicado con
xito en los sistemas existentes o estn ms all de la experiencia del
personal o de la empresa.
Escalabilidad: Hace referencia tanto a problemas tcnicos y de
gestin presentado por el desarrollo de grandes sistemas complejos.

2) Diseo:
Habla de las dificultades posibles de encontrar ante la

viabilidad de los algoritmos, funciones o requisitos de
desempeo, y las interfaces de los productos internos y externos,
y cuenta con los siguientes atributos:
a)
b)
c)
Funcionalidad: Cubre los requisitos funcionales que no pueden

someterse a un diseo factible, o el uso de algoritmos especificados
sin un alto grado de certeza.
Dificultad: Se refiere a los requisitos funcionales y de diseo que
puede ser extremadamente complejos de realizar.
Interfaces: cubre todas las interfaces de hardware y software que
estn dentro del alcance del programa de desarrollo, incluyendo las
interfaces entre los elementos de configuracin, y las tcnicas para la
definicin y gestin de las interfaces.

d)
e)
f)
g)
Desempeo: Se refiere al rendimiento de tiempo crtico, requisitos

de rendimiento, anlisis de rendimiento y modelos de actuacin en
todo el ciclo de desarrollo.
Testeabilidad: cubre la disponibilidad del diseo de pruebas, diseo
de funciones para facilitar las pruebas, y la inclusin en el proceso de
diseo de la gente que disea y realiza pruebas de productos.
Limitaciones de Hardware: Se refiere a la dependencia del
hardware para cumplir con los requisitos del sistema y responder a
las capacidades de respuesta, acceso a BD o limitaciones de
capacidad.
No desarrollo de SW: Hace referencia a cualquier software que no
es un software legado para el programa, o no se desarrolla como
parte del esfuerzo que est realizado por el equipo de desarrollo.

3. Cdigo
y pruebas unitarias: Se asocia con la calidad y

estabilidad del software o la especificaciones de la interfaz y
limitaciones que puedan presentar dificultades de aplicacin o de
prueba. Este elemento tiene los siguientes atributos:
a)
b)
Viabilidad: La viabilidad del cdigo y el elemento de prueba busca

posibles dificultades que pueden surgir de un mal diseo o
especificaciones de diseo. La naturaleza del propio sistema puede
agravar la dificultad y complejidad de la tarea de codificacin.
Unidad de pruebas: Incluyen la planificacin, la preparacin y el
desarrollo de los recursos y el tiempo asignado para las pruebas.

c)
Codificacin/Implementacin:
Este
atributo
examina
las
consecuencias de las limitaciones de la aplicacin. Algunos de estos
son:
objetivo de hardware que es marginal o inadecuada en cuanto a velocidad

Arquitectura
Tamao de la memoria o la capacidad de almacenamiento externo
Idiomas necesarios o mtodos de aplicacin
Diferencias entre el desarrollo y el hardware de destino

4. Integracin
y pruebas: Este elemento abarca la integracin y

la planeacin de pruebas, ejecucin, y las instalaciones, tanto
para el producto del contrato como para la integracin del
producto en el sistema o el ambiente del sitio.
a)
b)
Ambiente: Este atributo se refiere a la adecuacin de este entorno

para permitir la integracin en un entorno realista o para probar
plenamente todos los requisitos funcionales y de rendimiento.
Producto: Se refiere a la integracin de las componentes de SW con
el HW de destino, resaltando dentro de los factores
que afectan:
La capacidad de prueba de los requisitos

La negociacin del contrato con el cliente sobre los criterios de prueba
La adecuacin de las especificaciones de prueba
La consideracin de tiempo suficiente para las actividades de integracin y
pruebas

c)
Sistema: Los factores asociados y analizados con este atributo son :
Las especificaciones de interfaz externa

La capacidad para producir fielmente las condiciones del sistema de interfaz
antes de la integracin del sitio o del sistema
El acceso al sistema o la interconexin del sitio
La adecuacin de tiempo para las pruebas
Las relaciones socio contratista.

5. Especialidades
de la Ingeniera: Este elemento es un

dispositivo para asegurarse de contar con los especialistas que
son llamados para analizar los riesgos asociados con sus reas de
especializacin.
a)
b)
c)
Capacidad de Mantenimiento: Este atributo puede verse afectada

por una pobre arquitectura de software, diseo, cdigo.
Confiabilidad: Puede verse afectada por el hardware que no cumpla
con sus especificaciones de fiabilidad o la complejidad del sistema
que agrava las dificultades en el cumplimiento de los plazos de
recuperacin.
La seguridad: Se refiere a la dificultad de implementar los requisitos
de seguridad asignados, as como la posible dificultad de demostrar la
satisfaccin de las necesidades por simulacin fiel de las condiciones
de inseguridad y las acciones correctivas.

d)
e)
f)
Con seguridad: Destaca la posibilidad de falta de experiencia en la

aplicacin del nivel requerido de seguridad del sistema que puede
resultar en una subestimacin de los esfuerzos necesarios para los
mtodos de verificacin rigurosa.
Factor Humano: Trata la comprensin del entorno operativo del
sistema instalado y las expectativas incorporadas en los requisitos de
factores humanos.
Especificaciones: Hace referencia a todas las especificaciones para
el sistema:
Hardware,
Software
Interfaz
requisitos de prueba o diseo.
Calidad de la estabilidad, integridad, claridad, y verificabilidad.
Clase B. Ambiente de desarrollo

1. Proceso
Elemen de
desarrollo
tos
a.
Formalidad
b.
Idoneidad
At
ri
bu
to
s
2. Desarrollo
de Sistemas
3. Gestin
4. Mtodos de 5.
de procesos gestin
Ambientes
de Trabajo
a. Capacidad
a. Planificaci a. monitoreo
a. Actitud de
n
Calidad
b. Idoneidad
b.
b.
b.
Organizacin Administracin Cooperacin
del proyecto de personal
c. Control c. Usabilidad
c. Experiencia c.
c.
de
de Gestin
Aseguramiento Comunicacin
Procesos
de la Calidad
d.
d. Familiaridad d. Interfaces d.
d. Moral
Familiaridad
del programa Administracin
de la
configuracin
e. Control e. Confiabilidad
de los
Productos
f. Sistema de
Apoyo
g. Capacidad de
entrega
Aborda el entorno del proyecto y el proceso utilizado para

disear un producto de software. Este entorno incluye el
proceso de desarrollo y del sistema, los mtodos de gestin, y
el medio ambiente de trabajo, Incluye los siguientes
elementos:
1. Proceso
de desarrollo: El proceso es la secuencia de pasos, las

entradas, salidas, actividades, criterios de validacin y
seguimiento de las actividades, que van desde la especificacin
inicial de requisitos hasta el producto final entregado.
a)
Formalidad: Es una funcin del grado en que se define un proceso

coherente, documentado y comunicado para todos los aspectos y
fases del desarrollo.

b)
c)
d)
Seguridad: Este atributo se refiere a la dificultad de implementar los

requisitos de seguridad asignados, as como la posible dificultad de
Idoneidad: Es la habilidad con que es elegido el modelo de
desarrollo, de procesos, mtodos y herramientas de apoyo al alcance
y tipo de actividades necesarias para el programa especfico.
Control de procesos: Se refiere no slo a garantizar la aplicacin del
proceso definido por el personal del programa, sino tambin a la
medicin y mejora de los procesos basados en la observacin con
respecto a la calidad y productividad.

d)
e)
Familiaridad: Se refiere a la familiaridad para con el proceso de

desarrollo, abarcando conocimientos, experiencia y confort con el
proceso descrito.
Control de los productos: Dice relacin con el control del producto
que depende de la trazabilidad de los requisitos, as como tambin los
de los impactos del control de cambios que refleja todas las
modificaciones.

2. Desarrollo
de sistemas: Este elemento analiza las

herramientas de hardware, software y equipo de apoyo utilizados
en el desarrollo de productos. Esto incluye asistencia por
ordenador, herramientas de ingeniera de software, simuladores,
compiladores, equipos de prueba, y los sistemas host.
a)
b)
Capacidad: Los riesgos asociados con la capacidad del sistema de

desarrollo puede resultar de: muy pocos puestos de trabajo,
insuficiente poder de procesamiento o almacenamiento de bases de
datos, u otras insuficiencias en equipo para apoyar las actividades
paralelas a las actividades de desarrollo, prueba y soporte.
Idoneidad: Se asocia con el grado en que se apoyan los modelos de
desarrollo especficos, procesos, mtodos, procedimientos y
actividades que se requieren y son seleccionados para el programa.

c)
d)
e)
f)
g)
Usabilidad: Se refiere a la documentacin de desarrollo del sistema,

la accesibilidad y espacio de trabajo, as como la facilidad de uso de
ello.
Conocimiento: Hace referencia al conocimiento previo del sistema
de la empresa y por el personal del proyecto, as como la formacin
adecuada para los nuevos usuarios.
Confiabilidad: Es una medida de si los componentes necesarios del
sistema de desarrollo estn disponibles y funcionando correctamente
cuando as sea requerido.
Sistema de Apoyo: Incluye la capacitacin en el uso del sistema, el
acceso a usuarios expertos o consultores, y la reparacin o la
resolucin de problemas por los proveedores.
Capacidad de entrega: Los riesgos pueden resultar de descuidar la
oferta y asignar los recursos para asegurar que el sistema de
desarrollo cumple con todos los requisitos de entrega.

3. Gestin
de procesos: Hace referencia a los riesgos asociados

con la planificacin, seguimiento y control de presupuesto y el
calendario, con el control de los factores involucrados en la
definicin, implementacin y pruebas del producto, con el
personal de gestin de proyectos, y con el manejo de
organizaciones externas, incluyendo el cliente, la alta direccin,
matriz de gestin, y otros contratistas.
a.
b.
Planificacin:
Hace referencia a los riesgos asociados con el
desarrollo de un plan bien definido y que responda a las
contingencias.
Organizacin del Proyecto: se refiere a la eficacia de la
organizacin del programa, la definicin eficaz de las funciones y
responsabilidades, y la garanta de que estas funciones y lneas de
autoridad son entendidos por el personal.

c.
d.
Gestin de Experiencia: Se refiere a la experiencia de todos los

niveles de los directivos con respecto al desarrollo y gestin del
desarrollo de software.
Interfaces del Programa: Se refiere a las interacciones de los
gerentes en todos los niveles con personal del programa en todos los
niveles, y con personal externo, como el de los clientes, altos
directivos, gerentes y compaeros.

4. Mtodos
de Gestin: Abarca temas de desarrollo del personal

de productos y el programa. Estos incluyen la garanta de calidad,
gestin de configuracin, el desarrollo del personal con respecto a
las necesidades del programa, y mantener la comunicacin sobre
el estado del programa y sus necesidades.
a.
b.
Monitoreo: incluye las actividades para obtencin y actuar sobre los

informes de estado, la asignacin de informacin de estado a las
organizaciones el mantenimiento y el uso de mtricas de progreso.
Administracin del Personal: Se refiere a la seleccin y
capacitacin de los miembros del programa y asegurar que: participan
en la planificacin y la interaccin con los clientes para sus reas de
responsabilidad.

c.
d.
Garanta de Calidad: El atributo de control de calidad se refiere a los

procedimientos establecidos para asegurar que tanto los procesos
contractuales y las normas se aplican correctamente para todas las
actividades del programa.
Gestin de la Configuracin: Atribuye las direcciones tanto de
personal y herramientas para la funcin de CM, as como la
complejidad del proceso de manejo requerido con respecto a factores
tales como el desarrollo y sitios de instalacin y la coordinacin con
los productos existentes.

5. Ambiente
de Trabajo: Los aspectos subjetivos del medio

ambiente, tales como la cantidad de atencin prestada a
asegurar que las personas se mantengan informados de los
objetivos del programa y la informacin, la gente de la manera
trabajar en conjunto, la capacidad de respuesta a las entradas de
personal, la actitud y la moral del personal.
a.
b.
Actitud de Calidad: Este atributo se refiere a la tendencia del

personal del programa para hacer un trabajo de calidad en general y
de conformidad con los estndares de calidad especficos para el
programa y el producto.
Cooperacin: Aborda la falta de espritu de equipo entre el personal
de desarrollo tanto dentro de los grupos de trabajo y el fracaso de
todos los niveles de gestin para demostrar que mejor se estn
haciendo esfuerzos para eliminar los obstculos para la realizacin
eficiente del trabajo

c.
d.
e.
Actitud de Calidad: Este atributo se refiere a la tendencia del

personal del programa para hacer un trabajo de calidad en general y
de conformidad con los estndares de calidad especficos para el
programa y el producto.
Comunicacin: Riesgos que se derivan de la falta de comunicacin
se deben a la falta de conocimiento de la misin del sistema, los
requisitos y objetivos de diseo y los mtodos, o la falta de
informacin sobre la importancia de los objetivos del programa a la
empresa o el proyecto.
Moral: Riesgos que se derivan de la baja moral o bajos niveles de
entusiasmo y por lo tanto el rendimiento baja, la productividad y la
creatividad, la ira que puede resultar en un dao intencional al
proyecto o del producto; xodo masivo de personal del proyecto, y la
reputacin de la empresa que hace que sea difcil contratar.
Clase C. Limitaciones del Programa

Element 1.
recursos
os
2. contrato
3. Interfaces del programa
a. Horario a. Tipo de Contrato a. Cliente

b. Personal b. Restricciones
b. Asociado contratista
c.
c. Dependencias
A t r i Presupuesto
d.
b u t Instalacione
os s
c. Subcontratistas
d. Contratista Principal
e. Gestin empresarial
f. Proveedores
g. Polticas
Las limitaciones del programa se refieren a las

"externalidades" del proyecto. Estos son factores que pueden
estar fuera del control del proyecto, pero todava puede tener
efectos importantes en el xito o constituyen una fuente de
riesgo importante. Cuenta con los siguientes elementos:
1. Recursos:
Aborda los recursos que proponen depende externas.

Esto incluye horarios, personal, presupuesto e instalaciones.
a)
Horario: Este atributo se refiere a la estabilidad de la programacin

con respecto a los acontecimientos internos y externos o de las
dependencias y la viabilidad de las estimaciones y la planificacin de
todas las fases y aspectos del programa.

b)
c)
d)
Personal: Se refiere a la estabilidad y la adecuacin del personal en

cuanto al nmero y niveles de habilidad, su experiencia y habilidades
en las reas requeridas tcnica y dominio de aplicacin, y su
disponibilidad cuando sea necesario.
Presupuesto: Este atributo se refiere a la estabilidad del presupuesto
con respecto a los acontecimientos internos y externos o de las
dependencias y la viabilidad de las estimaciones y la planificacin de
todas las fases y aspectos del programa
Instalaciones: Este atributo se refiere a la adecuacin de las
instalaciones del programa para el desarrollo, integracin y prueba del
producto.

2. Contrato:
Los riesgos asociados con el contrato se clasifican

segn el tipo de contrato, restricciones y dependencias.
a)
b)
c)
Tipo de Contrato: Este atributo cubre las condiciones de pago (el

costo ms cuota de adjudicacin, el costo ms honorarios fijos, etc.) y
los requisitos contractuales.
Restricciones: Se refieren a las directivas de contratos, por ejemplo,
el uso de mtodos especficos de desarrollo o de los equipos y las
complicaciones resultantes, como la adquisicin de los derechos de
los datos para el uso del software.
Dependencias: Este atributo se refiere a las posibles dependencias
contractuales sobre los contratistas externos o proveedores,
proporcionados por el cliente, u otros productos y/o servicios del
exterior.

3. Interfaces
del Programa: Este elemento se compone de las

diversas interfaces con entidades y organizaciones externas
a)
b)
c)
Cliente: Este atributo cubre las condiciones de pago (el costo ms

cuota de adjudicacin, el costo ms honorarios fijos, etc.) y los
requisitos contractuales.
Contratistas asociados: Se refieren a las directivas de contratos,
por ejemplo, el uso de mtodos especficos de desarrollo o de los
equipos y las complicaciones resultantes, como la adquisicin de los
derechos de los datos para el uso del software.
Subcontratistas: Este atributo se refiere a las posibles dependencias
contractuales sobre los contratistas externos o proveedores,
proporcionados por el cliente, u otros productos y/o servicios del
exterior.

d)
e)
f)
g)
Contratista principal: Cuando el programa es un subcontrato, los

riesgos pueden surgir a partir de definiciones de tareas mal definidas,
arreglos complejos de informacin.
Gestin corporativa: Riesgos en el rea de gestin empresarial
incluyen la falta de comunicacin y la direccin de la administracin
superior, as como lo poco ptimos niveles de apoyo.
Proveedores: Los riesgos de proveedores se pueden presentar en las
formas de las dependencias en las entregas y el apoyo a los
componentes crticos del sistema.
Poltica: Los riesgos polticos se obtengan de las relaciones con la
empresa, clientes, contratistas asociado o subcontratistas, y puede
afectar a las decisiones tcnicas.
Mtodo - Cuestionario basado en Taxonoma (TBQ)
Sustenta la exploracin de reas que contienen los temas,

preocupaciones o riesgos de cada clase, elemento y atributo
del desarrollo de software.
Se estructura en base a una pregunta genrica inicial a nivel

de atributo, donde se interpretan sus respuestas con seales
especficas lo que gatilla las siguientes preguntas de sondeo.
Se adapta a cada proyecto en que se aplica, por ello contiene

preguntas que pueden no ser relevantes para todas las etapas
del ciclo de vida de desarrollo de software o definitivamente
no aplican.
Se apoya en una estructura de entrevistas.
Ejemplo
Realizando la identificacin de riesgos para la Ingeniera del
producto, nos encontramos revisando el diseo y puntualmente
el rendimiento del proyecto
Aplicacin para:
Clase: A. Ingeniera de producto

Elemento: 2. Diseo
Atributo: d. Rendimiento
A.2.d
.
La indexacin A.2.d. nos facilita el direccionamiento en el

cuestionario a la pregunta especfica de la clase, elemento y
atributo en cuestin, y es el que mostramos a continuacin. . .
Ejemplo (Extracto del TBQ)

A. Ingeniera de Producto
2. Diseo
d. Rendimiento
[ Hay tiempos de respuesta rigurosos o requisitos de rendimiento?]

[22] Hay algn problema con el rendimiento?
rendimiento
Programacin asncrona eventos en tiempo real
Respuesta en tiempo real
los plazos de recuperacin
Tiempo de respuesta
Base de datos de respuesta, contencin, o acceso
[23] Ha realizado un anlisis de desempeo?
(S) (23.a) Cul es su nivel de confianza en el anlisis de rendimiento?

(S) (23.b) Tiene usted un modelo para seguir el rendimiento a travs
de diseo e implementacin?
Ejemplo
La declaracin ofrece entre corchetes la pregunta inicial en

un contexto generalizado.
Cada pregunta inicial puede tener otras preguntas sobre la

base de la respuesta inicial.
Estas preguntas de sondeo estn precedidas por un "S" o

"No entre parntesis, que indica el tipo de respuesta inicial
que activa la siguiente pregunta de sondeo.
Ejemplo
Clase: A. Ing.de Producto

Elemento: 2. Diseo,
Atributo: d. Rendimiento
Si la respuesta a la pregunta inicial
Ha hecho un anlisis de rendimiento? Es " S
entonces las preguntas de sondeo son:

Cul es su nivel de confianza en el anlisis de rendimiento? y"
Tiene usted un modelo de para realizar un seguimiento al rendimiento a
travs del diseo y la ejecucin?"
Sino
Entonces el entrevistador sondea los problemas, preocupaciones o los

riesgos para el proyecto debido a la falta de un anlisis de rendimiento.
El protocolo de la entrevista requiere que el entrevistador siga

siempre las respuestas que parecen indicar un problema
potencial.
Mtodo Condiciones iniciales para aplicar el TBQ
Antes de aplicar el TBQ, tres actividades indispensables

deben tener lugar:
1. Compromiso ejecutivo:
Se presenta un informe a los ejecutivos

para obtener su compromiso y aceptacin del esfuerzo dedicado
a la identificacin de riesgos. Este informe da una visin general
del proceso con detalles en cuanto a personal involucrado junto a
los beneficios y el costo para el proyecto.
El no contar con esta aceptacin produce:
Retrasos significativos en la identificacin de riesgos o

La cancelacin del proceso de identificacin de riesgos.

deben tener lugar:
2. Seleccin
de proyectos: Dos son los criterios bsicos para la

seleccione de un proyecto:
Los esfuerzos y beneficios de la identificacin de riesgos debe contar

con la aceptacin y compromiso por parte de los directivos.
El(los) proyecto(s) a seleccionar debe(n) tener componerse en forma

importante de software.

deben tener lugar:
3. Entrevistas y seleccin de participantes:
Se recomienda que no existan relaciones jerrquicas entre los

participantes de las entrevistas.
Los participantes de cada sesin no deben ser superior a 5, con ello se

optimiza el dilogo y concrecin de ideas.
Para lograr una cobertura total, se definen 4 grupos para hacer

optimas las entrevistas:
Lderes tcnicos
Desarrolladores
Funciones de apoyo (QA, integracin, etc.)
Gestin del proyecto
Entrevistas
Las sesiones de identificacin de riesgos comienzan con una

reunin inicial informativa a todos los participantes. (Kick off)
En la reunin informativa inicial se describe el mtodo TBQ y

un resumen de la programacin y el proceso a llevar a cabo.
Entrevistas
La presencia de una relacin de subordinacin en un grupo

propone un efecto inhibidor sobre los subordinados,
condicionando su participacin activa y exposicin de temas.
Es fundamental no evaluar posturas ni juzgar o pre-juzgar

opiniones.
En virtud del tiempo se recomienda no quedarse bloqueado

en la dinmica de preguntas-respuestas para entrar en la
resolucin de problemas.
Las entrevistas deben ser de una hora como lmite superior,

de superarlo, se debe programar una sesin extra.
Entrevistas
Cada sesin de entrevista tiene dos partes:
1. Preguntas
y Respuestas. Este segmento incluye el uso de la

TBQ
y
preguntas de sondeo sensibles al contexto para provocar
problemas, preocupaciones o relevar los riesgos que podran
poner en peligro la conclusin exitosa del proyecto
2. Aclaracin
de temas. Este segmento consiste en la aclaracin

de la redaccin y el significado de las preguntas identificadas en el
segmento de preguntas y respuestas a travs de la clasificacin
de consenso de los riesgos en los grupos de la taxonoma.
Una vez que los participantes clasificar los problemas, evaluar

consenso para determinar cules son esencialmente equivalentes.
Temas equivalentes se funden en un solo tema.
Mtodo - Conclusin de la identificacin
Al concluir la identificacin de riesgos, es necesario e

indispensable
proporcionar informacin a todos los
participantes.
La informacin a entregar se compone de todos los problemas

sealados, y algunas sugerencias sobre los prximos pasos.
La intencin de la informacin es proporcionar a los

participantes :
informacin sobre los resultados de sus esfuerzos.
Generar registro de estos resultados hacia el jefe de proyecto quien se
encargar de priorizarlos previo a su liberacin y posteriormente

gestionarlos.
La liberacin prematura de esta informacin sin necesidad podra obligar o
impedir las acciones del gerente y exponer el proyecto a la atencin
negativa injustificada.
ndice
Introduccin
Contexto
Mtodo
Habilidades de facilitacin puede ser la

transicin
Los individuos pueden ser efectivamente capacitados para

llevar a cabo una identificacin de riesgos utilizando la
taxonoma.
No es necesario ser experto en las reas ni necesita tener

conocimientos detallados sobre los proyectos especficos.
Se recomienda la observacin y apoyo de un miembro del

equipo de expertos durante una sesin de entrevista como
parte de la formacin del equipo.
Habilidades de facilitacin puede ser la

transicin
El proceso de identificacin de riesgos representa slo el

comienzo de la estrategia de gestin de riesgos del proyecto.
Todo proyecto debe repetir la identificacin de riesgos y los

procesos de seguimiento peridicamente durante el ciclo de
vida del proyecto.
En los procesos de adquisiciones, se recomienda que la

identificacin formal de los riesgos se lleve a cabo durante la
fase de definicin del concepto de una adquisicin para
determinar los riesgos potenciales para el proyecto.
www.practiaconsulting.com
Contctenos:
ARGENTINA
San Martn 550 | (C1004AAL)| Buenos Aires | Tel (+54-11) 5276-1999 | contacto@pragmaconsultores.com
Crdoba 524 1er Piso | (Q8300BLL) Neuqun | Tel (+54-0299) 4424044
BOLIVIA
Calle uflo de Chavez No. 470 | Santa Cruz de la Sierra | Tel (+59 1) 3-3329300
CHILE
Luis T. Ojeda 0191 Piso 7 | Providencia, Santiago | Tel (+56-2) 334-3361 | practia@practia.cl
ESPAA
Santa Hortensia 15, Of. A3 | 28002 | Madrid | Tel (+ 34) 91-515-0558 | practia@practia.es
MEXICO
Homero 203 Piso 10 | Col. Chapultepec Morales | Miguel Hidalgo | Mxico DF, C.P. 11570 | Tel (+ 52 55) 3300 5361
Prol. Corregidora No. 338 Oficina 3 y 4 | Fracc. Alamos 3ra. Seccin | Quertaro, Qro. C.P. 76160 | Tel (+ 52 442) 245 2151/52
Batalln de San Patricio 109 | Piso 10 | Col. Valle Oriente | San Pedro Garza Garca | Monterrey N.L. 66260 practia@practia.com.mx
PER
Av. Vctor Andrs Belaunde 147 | Va Principal 140 | Edificio Real Seis, Piso 7 | San Isidro - Lima 27 | Tel (+51 1) 712-4308
URUGUAY
Cerrito 566 | Montevideo | Tel (+ 59 8) 2-9166405 | Fax (+ 59 8) 2- 9166405 int. 700

Identificación de Riesgos - SEI v1.5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Identificación de Riesgos - SEI v1.5

Uploaded by

Copyright:

Available Formats

Identificacin de Riesgos (SEI)

Basado en taxonoma de desarrollo de Software

El riesgo en si no es malo, es esencial para el progreso, y el

Los riesgos de un proyecto se ubican siempre en el futuro. Un

Identificar riesgos es labor de participacin

Este documento presenta la tcnica de Identificacin de

La taxonoma proporciona un marco para clasificar, organizar

El mtodo a estudiar consiste de un instrumento

El modelo que apoya la gestin integral de riesgos considera

Identificarlos (a estudiar en este documento)

La clave para la planificacin de

Contexto Identificacin de riesgos

Es prioritario identificar los riesgos antes de que se conviertan

Este documento concentra nuestra atencin en la

El cuestionario y proceso de aplicacin

Contexto Anlisis de riesgos levantados

El anlisis es la conversin de datos de riesgo en informacin

El anlisis proporciona la base para el gerente de

Cubre principalmente probabilidad e

Contexto Planificacin de respuestas

Convierte la informacin del riesgo en decisiones y acciones

Permite desarrollar acciones para hacer frente a

Es importante para proporcionar los recursos

Contexto Seguimiento de evolucin de los riesgos

Es la supervisin del estado del riesgo y las medidas

Se identifican parmetros adecuados y son

Contexto Control de la evolucin

Permite tomar medidas de correccin a las desviaciones en las

El control de riesgos se funde con la gestin de

Contexto Comunicar la informacin generada

La comunicacin de riesgos se encuentra en el centro del

Facilita la interaccin entre los elementos del

Es la componente que condiciona la

Los riesgos en un proyecto pueden ser :

Conocidos: Una o ms personas del proyecto son conscientes de

SEI trabaja sobre estos tipos y para ello dispone un mtodo

Clasificacin de instancias del desarrollo de software (Taxonoma)

El enfoque principal es sobre los riesgos que se sabe an no

Est diseado para asegurarse de que las preguntas

Este mtodo permite que los riesgos sean identificados sin

Las preguntas y su secuencia se utilizan como una definicin,

En efecto, el mtodo TBQ se puede describir como una

Ayuda a aclarar las incertidumbres y preocupaciones del

Los riesgos son conocidos generalmente por el personal

Es indispensable contar con un mtodo estructurado y

Una Identificacin de riesgos eficaz debe cubrir todas las

El proceso de identificacin de riesgos debe crear y mantener

Mtodo - Taxonoma de desarrollo de software

Obtiene, clasifica y organiza toda la amplitud de los riesgos en

Las instancias clasificadas inicialmente se organizan en tres

A. Ingeniera del Producto

Estas tres clases se dividen en Elementos y cada elemento es

Mtodo - Taxonoma de desarrollo de software

Mapa Taxonmico de riesgos en desarrollo de

Este mapa muestra a modo resumido las agrupaciones propuestas

A continuacin se detalla el concepto de cada uno de los

Mtodo - Taxonoma de desarrollo de software

Clase A. Ingeniera del producto

Mtodo - Taxonoma de desarrollo de software

Clase A. Ingeniera del producto

Se refiere a la ingeniera de sistemas y actividades de

abarcan tanto la calidad de la especificacin de

Estabilidad: Grado en que las necesidades estn cambiando y como

Mtodo - Taxonoma de desarrollo de software