ANÁLISIS

Anlisis
Conjunto de hechos, principios y reglas clasificadas

y dispuestas de manera ordenada mostrando un
plan lgico en la unin de las partes (anlisis
diseo), formando as una sola unidad con un
objetivo predefinido en el procesamiento de la
informacin.
Funcin del Proceso de
Anlisis
Dar soporte a las actividades de un negocio, o

desarrollar un producto que pueda venderse para
generar beneficios. Para conseguir este objetivo, un
Sistema basado en Computadores hace uso de (6)
elementos fundamentales:
Software
Hardware
Personal
Base de Datos
Documentacin
Procedimientos
Objetivos del Anlisis
Identificar necesidades del cliente.
Evaluar que conceptos tiene el cliente del
sistema.
Realizar un anlisis Tcnico y Econmico.
Asignar funciones a los elementos
fundamentales.
Crear una definicin del sistema que fundamente
el trabajo de Ingeniera.
Proceso de Anlisis
Planeacin del proyecto de software.
Anlisis del sistema actual.
Anlisis de requerimientos o requisitos para el

nuevo sistema.
Anlisis econmico y tcnico.

Viabilidad del Proyecto
Software
Cuando comenzamos a planificar un proyecto de
software, los recursos y el tiempo no son
correctamente calculados para su realizacin.
Razn por la cual es importante hacer el Estudio
de Viabilidad antes de la concrecin de un
contrato.
Viabilidad del Proyecto de
Software
Estudio de Viabilidad
Viabilidad Tcnica Viabilidad Econmica Viabilidad Legal

Proyectos:
Un proyecto es cualquier empresa humana con un
claro principio y un claro final (Gallagher)
Poseen algunas caractersticas comunes:
Combinacin de actividades
Relacin secuencial entre actividades
Preocupacin por el tiempo
Preocupacin por los recursos
Planeacin, programacin y
control
La Planeacin requiere desglosar el proyecto en
actividades, estimar recursos, tiempo e interrelaciones
entre actividades.
La Programacin requiere detallar fechas de inicio y
terminacin.
El Control requiere informacin sobre el estado actual
y analiza posibles trueques cuando surgen dificultades.
Herramientas de planeacin,
programacin
Grficas de Gantt
y control
Modelos de redes:
Redes deterministas (CPM = Mtodo de
la ruta crtica)
Redes probabilistas (PERT = Tcnica de
evaluacin y revisin de programas)
Tambin existen otras tcnicas
Ejemplo: Construccin de una
casa
Durac.
Activ Descripcin Predecesor (sem)
A Cimientos, paredes - 4
B Plomera, A 2
electricidad
C Techos A 3
D Pintura exterior A 1
E Pintura interior B, C 5
Grfica de Gantt
A
E
0 1 2 3 4 5 6 7 8 9 10 11 12
Red de actividades
B
Inicio A C E Fin
D
Ruta crtica
La Ruta Crtica es la ruta ms larga a
travs de la red
Determina la longitud del proyecto
Toda red tiene al menos una ruta crtica
Es posible que haya proyectos con ms de
una ruta crtica
Cul es la ruta crtica de la red anterior?
Este proyecto tiene tres rutas posibles:
Inicio A B E Fin
Inicio A C E Fin
Inicio A D Fin
Cul es la duracin de cada una?
Cmo se encuentra la ruta
crtica?
Es necesario agregar a la red los tiempos
de cada actividad
Los tiempos se agregarn en cada nodo
Las flechas slo representan la secuencia
de las actividades
crtica? 2
B
0 4 3 5 0
Inicio A C E Fin
1
D
crtica?
Para cada actividad se calcularn 4
tiempos
Se denotarn:
ES EF
LS LF
crtica?
1. Tiempo de inicio temprano: Es el
tiempo ms temprano posible para
iniciar una actividad
ES = EF ms alto de la(s) actividad(es)
anterior(es)
crtica?
2. Tiempo de terminacin temprano: Es el
tiempo de inicio temprano ms el
tiempo para completar la actividad
EF = ES de la actividad ms duracin
de la actividad
El ES y el EF se calculan recorriendo la
red de izquierda a derecha
4 6
crtica?0+4= 2
B
0 0 0 4 7 12 12 12
0 4 7
4 3 5 0
Inicio A C E Fin
1
D
4 5
crtica?
3. Tiempo de terminacin ms lejana: Es
el tiempo ms tardo en que se puede
completar la actividad sin afectar la
duracin total del proyecto
LF = LS ms bajo de la(s) actividad(es)
prxima(s)
crtica?
4. Tiempo de inicio ms lejano: Es el
tiempo de terminacin ms lejano de la
actividad anterior menos la duracin de
la actividad
LS = LF de la actividad duracin de la
actividad
Para calcular LF y LS la red se recorre
de derecha a izquierda
crtica? 4 6
5 7
2
B
0 0 0 4 7 12 12 12
0 0 0 4 7 12
0 4 7 12 12
4 3 5 0
4 7
Inicio A C E Fin
1
D
4 5
11 12
crtica?
Despus de calculados los cuatro tiempos
de cada actividad, se calculan las holguras
La holgura es el tiempo que se puede
atrasar una actividad sin afectar la
duracin total del proyecto
H = LF EF
crtica? 4 6
5 7
H=1
2
B H=0
0 0 0 4 7 12
H=0 H=0 12 12
0 0 0 4 H=0
4 7 7 12 12 12
0 4 3 5 0
4 7
Inicio A C E Fin
H=0
1
D
4 5
H=7
11 12
crtica?
La ruta crtica se encuentra como aquella
ruta para la cual todas sus actividades
tienen holgura igual a cero
Generalmente se marca en la red la ruta
crtica
En este caso es la ruta:
Inicio A C E Fin
4 6
crtica? 2 5 7
H=1
B H=0
0 0 0 4 7 12
H=0 H=0 12 12
0 0 0 4 H=0
4 7 7 12 12 12
0 4 3 5 0
4 7
Inicio A C E Fin
H=0
1
D
4 5
H=7
11 12
Hay varias razones para medir un producto
1. Para indicar la calidad del producto.
2. Para evaluar la productividad de la gente que
desarrolla el producto.
3. Par evaluar los beneficios en trminos de
productividad y de calidad, derivados del uso
de nuevos mtodos y herramientas de la ingeniera de
software.
4. Para establecer una lnea de base para la estimacin
5. Para ayudar a justificar el uso de nuevas herramientas
o de formacin adicional.
Por qu es tan importante medir el proceso de
ingeniera del software y el producto (software) que
produce?
La respuesta es relativamente obvia. Si no se mide,

no hay una forma real de determinar si se est
mejorando. Y si no se est mejorando, se est
perdido.
Conceptos Bsicos
Medida: Indicacin cuantitativa de la extensin,
cantidad, dimensiones, capacidad o tamao de
algunos atributos de un proceso o producto.
Medicin: Acto de determinar una medida
Mtrica: Medida cuantitativa del grado en que un
sistema, componente o proceso posee un atributo
dado.
Indicador: Mtrica o combinacin de mtricas que
proporcionan una visin profunda de un proceso,
producto o proyecto.
Indicadores
Indicadores de Proceso: Permiten a una
organizacin tener una visin profunda de la eficacia
de un proceso ya existente. Permiten evaluar lo que
funciona y lo que no. Se recopilan medidas durante un
largo periodo de tiempo. Proporcionan indicadores
que lleven a mejoras de los procesos de software.
Indicadores de Proyecto: Permiten evaluar el estado
del proyecto en curso, seguir la pista de los riesgos,
detectar las reas problemticas, ajustar las tareas y
evaluar la habilidad del equipo de trabajo.
Mediciones del Software
Pueden englobarse en dos categoras: medidas directas y
medidas indirectas.
Medidas Directas. En el proceso de ingeniera se
encuentran el costo, y el esfuerzo aplicado, las lneas de
cdigo producidas, velocidad de ejecucin, el tamao de
memoria y los defectos observados en un determinado
periodo de tiempo.
Medidas Indirectas. Entre las medidas indirectas se
incluyen la funcionalidad, calidad, complejidad,
eficiencia, fiabilidad, facilidad de mantenimiento y
muchas otras capacidades.
Mtricas del software
Son las que estn relacionadas con el desarrollo del software como funcionalidad, complejidad,
eficiencia.
MTRICAS TCNICAS: Se centran en las caractersticas de software por ejemplo: la
complejidad lgica, el grado de modularidad. Mide la estructura del sistema, el cmo esta hecho.
MTRICAS DE CALIDAD : proporcionan una indicacin de cmo se ajusta el software a los
requisitos implcitos y explcitos del cliente. Es decir cmo voy a medir para que mi sistema se
adapte a los requisitos que me pide el cliente.
MTRICAS DE PRODUCTIVIDAD . Se centran en el rendimiento del proceso de la ingeniera del
software. Es decir que tan productivo va a ser el software que voy a disear.
MTRICAS ORIENTADAS A LA PERSONA . Proporcionan medidas e informacin sobre la
forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista
humano de la efectividad de las herramientas y mtodos. Son las medidas que voy a hacer de mi
personal que va har el sistema.
MTRICAS ORIENTADAS AL TAMAO. Es para saber en que tiempo voy a terminar el
software y cuantas personas voy a necesitar. Son medidas directas al software y el proceso por el cual se
desarrolla, si una organizacin de software mantiene registros sencillos.
Orientadas al tamao
Las mtricas del software orientadas al tamao provienen de la
normalizacin de las medidas de calidad y/o productividad considerando el
tamao del software que se haya producido.
Mtricas
Productividad = KLDC/persona-mes
Calidad = errores/KLDC
Documentacin = pags. Doc/ KLDC
Costo = $/KLDC
Orientadas a la funcin
Las mtricas del software orientadas a la funcin
utilizan una medida de la funcionalidad entregada
por la aplicacin como un valor de normalizacin.
Ya que la funcionalidad no se puede medir
directamente, se debe derivar mediante otras
medidas directas.
Punto de funcin: Se calcula determinando 5
caractersticas de dominio de informacin.
1. Nmeros de entrada de usuario: se cuenta cada entrada del usuario
que proporcione al software diferentes datos orientados a la aplicacin.
Las entradas deben ser distinguidas de las peticiones que se contabilizan
por separado.
2. Numero de salida del usuario: se encuentra cada salida que
proporciona la usuario
informacin orientada ala aplicacin. En este contexto las salidas se
refieren a informes, pantalla, mensajes de error. Los elementos de datos
individuales dentro de un informe se encuentran por separado.
3. Nmeros de peticiones al usuario: una peticin esta definida como una
entrada
interactiva que resulta de la generacin de algn tipo de respuesta en
forma de salida interactiva. Se cuenta cada peticin por separado.
4. Numero de archivos: se cuenta cada archivo maestro lgico, o sea una
agrupacin lgica de datos que puede ser una parte en una gran base de
datos o un archivo independiente.
5. Numero de interfaces externas: se cuentan todas las interfaces legibles
por la maquina por ejemplo: archivos de datos, en cinta o discos que son
utilizados para transmitir informacin a otro sistema.
Mtricas para la calidad del
software
El objetivo primordial de la ingeniera del software es producir un sistema,
aplicacin o producto de alta calidad.
Para lograr este objetivo, los ingenieros del software deben aplicar mtodos
efectivos junto con herramientas modernas dentro del contexto de un proceso
maduro de desarrollo de software. Adems, un buen ingeniero del software (y
buenos gestores de la ingeniera del software) deben medir si la alta calidad se
va a llevar a cabo.
La calidad de un sistema, aplicacin o producto es tan bueno como los
requisitos que describen el problema, el diseo que modela la solucin, el
cdigo que conduce a un programa ejecutable, y las pruebas que ejercitan el
software para detectar errores. Un buen ingeniero del software utiliza
mediciones que evalan la calidad del anlisis y los modelos de diseo, el
cdigo fuente, y los casos de prueba que se han creado al aplicar la ingeniera
del software.
Medidas de la calidad
Aunque hay muchas medidas de la calidad de software, la
correccin, facilidad de mantenimiento, integridad y
facilidad de uso proporcionan indicadores tiles para el
equipo del proyecto.
Correccin. Un programa debe operar correctamente o

proporcionar poco valor a sus usuarios. La correccin es el
grado en el que el software lleva a cabo su funcin requerida.
La medida ms comn de correccin es defectos por KLDC,
en donde un defecto se define como una falta verificada de
conformidad con los requisitos.
Facilidad de mantenimiento
El mantenimiento del software cuenta con ms esfuerzo que
cualquier otra actividad de ingeniera del software. La
facilidad de mantenimiento es la facilidad con la que se
puede corregir un programa si se encuentra un error, se
puede adaptar si su entorno cambia, o mejorar si el cliente
desea un cambio de requisitos. No hay forma de medir
directamente la facilidad de mantenimiento; por
consiguiente, se deben utilizar medidas indirectas. Una
simple mtrica orientada al tiempo es el tiempo medio de
cambio (TMC), es decir el tiempo que se tarda en analizar la
peticin de cambio, en disear una modificacin adecuada,
en implementar el cambio, en probarlo y en distribuir el
cambio a todos los usuarios
Integridad
En esta poca de hackers y firewalls la integridad del software ha llegado a
tener mucha importancia. Este atributo mide la capacidad de un sistema
para resistir ataques contra sus seguridad.
Para medir la integridad, se tienen que definir dos atributos adicionales:
amenaza y seguridad.
Amenaza es la probabilidad (que se puede estimar o deducir de la
evidencia emprica) de que un ataque de un tipo determinado ocurra en
un tiempo determinado.
La seguridad es la probabilidad (que se puede estimar o deducir de la evidencia
emprica) de que se pueda repeler el ataque de un tipo determinado.
La integridad del sistema se puede definir como:
integridad = [( 1 - amenaza) x (1 - seguridad)]
donde se suman la amenaza y la seguridad para cada tipo de ataque.
Facilidad de uso
El calificativo amigable con el usuario se ha convertido en omnipresente
en las discusiones sobre productos de software. Si un programa no es
amigable con el usuario, frecuentemente est abocado al fracaso,
incluso aunque las funciones que realice sean valiosas. La facilidad de uso
es un intento de cuantificar lo amigable que puede ser con el usuario y
se puede medir en funcin de cuatro caractersticas:
1.- Habilidad intelectual y/o fsica requerida
para aprender el sistema;
2.- Tiempo requerido para llegar a ser moderadamente eficiente en el uso
del sistema;
3.- Aumento neto en productividad (sobre el enfoque que el sistema
reemplaza) medida cuando alguien utiliza el sistema moderadamente y
eficientemente; y
4.- Valoracin subjetiva (a veces obtenida mediante un cuestionario) de la
disposicin de los usuarios hacia el sistema
Eficacia de la Eliminacin de Defectos
Una mtrica de la calidad que proporciona beneficios tanto a
nivel del proyecto como del proceso, es la eficacia de la
eliminacin de defectos (EED). EED es una medida de la
habilidad de filtrar las actividades de la garanta de calidad y
de control al aplicarse a todas las actividades del marco de
trabajo del proceso.
Cuando un proyecto se toma en consideracin globalmente,
EED se define de la forma siguiente:
EED = E / (E + D)
donde E es el nmero de errores encontrados antes de
la entrega del software al usuario final y D es el nmero
de defectos encontrados despus de la entrega.
El valor ideal de EED es 1. Esto es, no se han encontrado defectos en ei software. De forma
realista, D ser mayor que cero.
Lnea Base
Estableciendo una lnea base de mtricas se
pueden obtener beneficios a nivel de proceso, proyecto y
producto (tcnico). Sin embargo la informacin reunida
no necesita ser fundamentalmente diferente. Las
mismas mtricas pueden servir varias veces. Las lneas
base de mtricas constan de datos recogidos de
proyectos de software desarrollados anteriormente y
pueden ser tan simples como una tabla de datos o tan
complejas como una gran base de datos que contenga
docenas de medidas de proyectos y las mtricas
derivadas de ellos.
COCOMO II
3 modelos con distinto nivel de complejidad
composicin de aplicaciones (tamao en Object Points)
diseo temprano (tamao en PF)
post-arquitectura (tamao en LOCs)
E= b Sc(y) m(X)
y: Elementos de escala para ajustar el exponente
x: Multiplicadores de esfuerzo
Herramientas que soportan los 2 ltimos modelos

Calibrada con base de datos de proyectos
Estima esfuerzo, duracin (y cantidad promedio de gente)
de desarrollo, SIN contar Requerimientos
Esfuerzo en Meses-Persona (152 horas-Persona)
COCOMO II - Ajustes de Escala
PREC -> Precedentes
FLEX -> Flexibilidad del Desarrollo
Requerimientos pre-establecidos
Interfaces externas
RESL -> Arquitectura/Resolucin de Riesgos

TEAM -> Cohesin del equipo
PMAT -> Madurez del Proceso de SW
COCOMO II
Multiplicadores de Esfuerzo (Post-Arq.)
4 categoras:
Atributos del producto
Relativos a las caractersticas del sw a desarrollar
RELY -> Confiabilidad requerida
DATA -> Tamao BD
CPLX -> Complejidad
RUSE -> Reuso de productos en proyecto y otros
DOCU -> Documentacin requerida
Atributos de la plataforma
Relativos a los req. de HW y SW del sistema
TIME -> Carga de Procesadores
STOR -> Restricciones de Memoria
PVOL -> Volatilidad de la Plataforma
COCOMO II
Multiplicadores de Esfuerzo (Post-Arq.)
Atributos del personal

Relativos a la experiencia y capacidades del equipo de desarrollo
ACAP -> Capacidad de Analistas
AEXP -> Experiencia de Analistas en dominio del proy.
PCAP -> Capacidad de Programadores
PEXP -> Experiencia de Programadores en el dominio del proy.
LTEX -> Experiencia en Lenguaje y Herramientas
PCON -> Continuidad del personal
Atributos del proyecto

Relativos a las caractersticas intrnsecas de cada proyecto especfico
TOOL -> Herramientas
SITE -> Dispersin/Comunicaciones
SCED -> Compresin/Estiramiento de Plazo
Estudio de viabilidad:
Analizar el sistema propuesto
Escribir una descripcin.
Definir y documentar posibles sistemas.
Analizar el coste de sistemas similares.
Estimar el tamao del sistema, la planificacin y los
costes. (tener en cuenta los entregables mas
importantes).
Definir cualitativa y cuantitativamente los beneficios
del sistema propuesto.
Realizar una planificacin inicial del plazo de
recuperacin de la inversin.
Realizacin de una estimacin detallada de costes,
planificacin, recursos, etc., de la siguiente fase
(Anlisis).
57
Asignar director del proyecto.
Composicin del documento de estudio de viabilidad.
Presentacin del documento de viabilidad a la
direccin para su aprobacin.
58
DEFINICION DE VIABILIDAD
Segn el diccionario de la Real Academia Espaola
Viabilidad: cualidad de viable, Viable: Que, por sus
circunstancias, tiene probabilidades de poderse llevar
a cabo.
ESTUDIO DE VIABILIDAD
Es el anlisis que intenta predecir el eventual xito o
fracaso de un proyecto de tal manera que cumpla con
su objetivo. Para lograr esto parte de datos empricos a
los que accede a travs de diversos tipos de
investigaciones.
Est relacionada con principios de calidad, eficiencia y
pertinencia de un proyecto en trminos de los
elementos conceptuales que lo componen, la
informacin utilizada, la coherencia de los
planteamientos y el mayor acercamiento a la realidad a
la que se refiere el proyecto.
Los anlisis de viabilidad se desarrollan en el mbito
gubernamental o corporativo. Se trata de un recurso
til antes del inicio de una obra o del lanzamiento de
un nuevo producto. De este modo, se minimiza el
margen de error.
DETERMINACIN DE LA VIABILIDAD EN UN PROYECTO
Las mejoras pueden ser de muchos tipos:
Aceleracin de un proceso.
Eliminar pasos innecesarios o duplicados.
Reduccin en la captura de informacin mediante la
modificacin de formularios y pantallas de despliegue, etc
CUADRICULA DE IMPACTO DE VIABILIDAD (CIV)

Se utiliza para evaluar el impacto de las mejoras al sistema
existente.
Puede aumentar la ganancia de los impactos sobre los
objetivos corporativos
VIABILIDAD DE UN PROYECTO
El estudio de la viabilidad evala tres criterios:
operacional, tcnico y econmico, del proyecto
propuesto.
Hay tres tipos de viabilidad:
o Viabilidad tcnica.
Evala si los recursos tcnicos actuales son suficientes
para el nuevo sistema, si ellos no lo estn pueden ser
actualizados para proveer el nivel necesario de
tecnologa necesario para el nuevo sistema.
o Viabilidad econmica.
La viabilidad econmica determina si el tiempo y el
dinero estn disponibles para desarrollar el sistema.
Incluye la compra de : equipo nuevo, hardware y
software.
o Viabilidad operacional
Determina si los recursos humanos estn disponibles:
para operar el sistema una vez que este sea instalado.
Los usuarios que no desean un nuevo sistema, pueden
impedir que llegue a ser operacionalmente viable.
ANLISIS Y GESTIN DEL RIESGO
AGENDA
1. INTRODUCCIN
2. RIESGO DEL SOFTWARE
3. IDENTIFICACIN DEL RIESGO
4. ANLISIS DEL RIESGO
5. PLANIFICACIN DEL RIESGO
6. SUPERVISIN DEL RIESGO
7. EL PLAN RSGR
1. INTRODUCCIN
1. INTRODUCCIN
Definicin de riesgo:
Es un problema potencial puede o no ocurrir.
El riesgo afecta futuros acontecimientos -qu riesgos podran
hacer que nuestro proyecto fracasara?
El riesgo implica cambio. Cmo afectarn los cambios en los
requisitos del cliente, en las tecnologas de desarrollo, al
cumplimiento de la planificacin y al xito en general?
El riesgo nos enfrenta a elecciones. qu mtodos y
herramientas deberamos emplear, cunta gente debera estar
implicada, cunta importancia hay que darle a la calidad?
1. INTRODUCCIN
Anlisis y gestin del riesgo:
Qu es?
Una serie de pasos que ayudan al equipo del software a
comprender y gestionar la incertidumbre.
Quin lo hace?
Todos los que estn involucrados en el proceso del software
gestores , ingenieros y clientes.
Por qu es importante?
El SW es una empresa difcil. Muchas cosas pueden ir mal y a
menudo salen mal. Estos problemas pueden tener un
impacto significativo en la fecha de entrega o en el
presupuesto.
1. INTRODUCCIN
Cmo se hace?Proactivamente.
Reactivas Bomberos
Estrategias
de riesgo
Antes de los
Proactivas trabajos tcnicos
1. INTRODUCCIN
Cules son los pasos?
Identificacin Anlisis Planeacin Supervisin

de riesgos de riesgos de riesgos de riesgos
Listado de Listado de Planes de

Valoracin
riesgos priorizacin prevencin y
contingencia de riesgos
potenciales de riesgos
1. INTRODUCCIN
Cul es el producto obtenido?
Se realiza un Plan de Reduccin, Supervisin y Gestin del
Riesgo (RSGR) o un informe de riesgos.
Cmo podemos estar seguros de que lo hemos hecho
correctamente?
El RSGR debe ser revisado mientras el proyecto se realiza
para asegurar que los riesgos estn siendo controlados. Los
planes de contingencia deben ser realistas.
Caractersticas del riesgo de SW
1. Incertidumbre: Puede o no ocurrir, no hay riesgos del
100% de probabilidad.
2. Prdida: Si el riesgo ocurre, hay prdidas.
1. Riesgos del proyecto: Amenazan al plan del proyecto; la planificacin
temporal y los costos. Ej: Prdida de un diseador
experimentado.
Categoras 2. Riesgos del producto: Amenazan la calidad y la planificacin

temporal del SW; la implementacin puede llegar a ser
de riesgos
difcil o imposible. Ej: Rendimiento de un componente
de software menor al esperado.
3. Riesgos del negocio: Amenazan la viabilidad del software a

construir. Ej: Un competidor introduzca un nuevo
producto.
1. Riesgo del mercado: Construir un producto o sistema que
nadie quiere comprar.
2. Riesgo estratgico: El producto no encaja en la estrategia

comercial general de la compaa.
Riesgos
del 3. Riesgo de ventas: El departamento de ventas no sabe
negocio vender el producto.
4. Riesgo de direccin: Perder el apoyo de un gerente

experto adecuado.
5. Riesgo de presupuesto: Perder presupuesto o personal

asignado.
1. Riesgos conocidos: Los que se pueden descubrir despus de

una cuidadosa evaluacin del plan del
proyecto, del entorno tcnico y comercial.
Categorizacin
general de 2. Riesgos predecibles: Se extrapolan de la experiencia en
los riesgos proyectos anteriores.
de SW
3. Riesgos impredecibles:Son muy difciles de identificar por
adelantado.
3. IDENTIFICACIN
DEL RIESGO

Valoracin
de riesgos
potenciales de riesgos contingencia
Es un intento sistemtico para especificar las amenazas al plan
del proyecto.
Hay dos tipos de riesgo para cada categora de riesgo de SW
(proyecto, producto y negocio).
Riesgos genricos: Amenaza potencial para todos los
proyectos de SW.
Riesgos especficos: De la tecnologa, el personal y el
entorno especfico del proyecto en cuestin.
Nos basamos en una lista de comprobacin de elementos de riesgo.
Es un subconjunto de riesgos conocidos y predecibles de las
siguientes categoras:
Tamao del producto. Tamao del SW a construir.
Ejemplos:
Tamao estimado del producto en LDC o FP?
Grado de seguridad en la estimacin del tamao?
Tamao estimado del producto en nmero de programas,
archivos y transacciones?
Impacto en el negocio. Limitaciones impuestas por la
gestin o por el mercado.
Efecto de este producto en los ingresos de la compaa?
Sofisticacin del usuario final?
Limitaciones gubernamentales en la construccin del
producto?
Nos basamos en una lista de comprobacin de
elementos de riesgo.
Caractersticas del cliente. Sofisticacin del cliente.
Hemos trabajado con el cliente anteriormente?
Est dispuesto el cliente a participar en las revisiones?
Entiende el cliente el proceso del software?
Definicin del proceso. Grado de uso de metodologas de
la organizacin.
Ha desarrollado su organizacin una descripcin escrita del
proceso del software a emplear en este proyecto?
Se llevan a cabo regularmente revisiones tcnicas formales de
las especificaciones de requisitos, diseo y cdigo?
Nos basamos en una lista de comprobacin de elementos de riesgo.
Entorno de desarrollo. Disponibilidad y calidad de
herramientas de desarrollo de software.
Tenemos disponible una herramienta de gestin de proyectos de
software?
Existen herramientas de anlisis y diseo disponibles?
Proporcionan las herramientas de anlisis y diseo, mtodos
apropiados para el producto a construir?
Tecnologa a construir. Complejidad del sistema a
construir.
Es nueva para su organizacin la tecnologa a construir?
Demandan los requisitos del cliente la creacin de nuevos algoritmos
o tecnologa de entrada o salida?
El software interacta con hardware nuevo o no probado?
Nos basamos en una lista de comprobacin de
Tamao y experiencia de la plantilla. Experiencia tcnica
y documentacin anterior de los ingenieros de SW que van a
realizar el trabajo.
Disponemos de la mejor gente?
Tiene el personal todos los conocimientos adecuados?
Ha recibido el personal la formacin adecuada?
Luego, en un grupo, se utiliza un enfoque de tormenta de ideas
para responder a las cuestiones de las listas de comprobacin de
Tambien se usa la experiencia de proyectos anteriores.
Factores principales de dao o cancelacin de Proyectos de software
(Fuente: Standish Group, The Chaos Report, 2003)
Factores de Dao o cancelacin %
Requerimientos incompletos 13.1
Deficiencia en el involucramiento del usuario 12.4
Deficiencia de recursos 10.6
Expectativas no realistas 9.9
Deficiencia en soporte ejecutivo 9.3
Cambios en los requerimientos y especificaciones 8.7
Deficiencia en la planeacin 8.1
Ya no se necesita ms 7.5
Deficiencia en administracin de TI 6.2
Desconocimiento en tecnologa 4.3
Otros 9.9
4. ANLISIS DEL
RIESGO


Valoracin
de riesgos
Probabilidad
Estimacin
Exposicin al riesgo (ER)
del riesgo
Magnitud de
Anlisis del prdida
riesgo
Priorizacin del Riesgos ms

riesgo importantes
Estimacin del riesgo:
Ejemplo de tabla de estimacin de riesgos:
Riesgo Categora Probabilidad Magnitud de Exposicin RSGR

de prdida la prdida al riesgo
(semanas) (semanas)
Planificacin demasiado optimista TP 50% 5 2,5 A.1.1
Aadir un requisito para la actualizacin PR 5% 20 1,0 A.2.1
automtica desde el mainframe
Aadir nuevas caractersticas desde NE 35% 8 2,8 A.3.2
marketing (sin conocer las caractersticas
especficas)
La interfaz del subsistema de grficos es PR 25% 4 1,0 B.2.1
inestable
Diseo inadecuado (hay que volver a disear) PR 15% 15 2,25 B.3.1
Los recursos no estn disponibles en su TP 10% 2 0,2 B.4.2
momento
Los informes de estado a nivel de directiva TP 10% 1 0,1 B.2.1
necesitan ms tiempo del previsto
1. Establecer una escala que refleje la probabilidad percibida del riesgo;
cualitativa y/o cuantitativa. Por ejemplo:
<10% muy bajo
10-25% bajo
25-50% moderado
50-75% alto
>75% muy alto
2. Estimar la probabilidad.
Consejos:
Tcnica Delphi: Cada quien hace una estimacin individual. Luego se discute
el origen de cada estimacin, hasta hacer converger las estimaciones.
Utilizar <<calibracin mediante adjetivos>>. Definir un valor cualitativo y
luego establecer un valor cuantitativo.
3. Estimar la magnitud de la prdida.
Cuantitativamente, la prdida puede ser medida en unidades de tiempo
o de costo.
Para determinar la magnitud en tiempo se recurre a la experiencia o se toma
la medida de algo pequeo y se combina para hallar la magnitud total (por
ejemplo, para LCDs).
Para determinar la magnitud en costo: Si es cdigo, se estima cuntas LDC o
FP se requieren, se averigua el valor promedio de cada una y se multiplica.
4. Estimar la exposicin al riesgo (ER). La ER es el valor esperado de
prdida. Es la probabilidad de prdida (P) multiplicada por la magnitud
de la prdida (C).
ER = P.C
El valor de la exposicin al riesgo se utiliza posteriormente para priorizar
los riesgos.
5. Retraso total del proyecto: Se suman todas las exposiciones al riesgo

para determinar el riesgo total del proyecto.
La planificacin total del proyecto se puede cambiar para reflejar el
retraso total esperado calculado en plan de gestin de riesgos.
Priorizacin de riesgos:
Se ordenan los riesgos de mayor a menor exposicin al riesgo.
Se establece una lnea de corte, se descartan los riesgos por debajo de esa
lnea.
En proyectos grandes se utiliza el principio de Pareto: El 20% de los
riesgos principales consumiran el 80% de su tiempo o de su dinero.
Muy
alta
Magnitud de
prdida
Alto
baja Relevancia para la

0 gestin
Probabilidad
1,0
5. PLANIFICACIN DEL
RIESGO


Valoracin
de riesgos
Se establece un plan de gestin del riesgo para cada uno de los
riesgos clave identificados.
Depende del conocimiento y la experiencia del gestor del proyecto.
Estrategias para atacar los riesgos:
1. Prevencin. Reducir la probabilidad.
2. Minimizacin. Reducir el impacto.
3. Planes de contingencia. Estar preparado para lo peor y
planificar como solucionar la prdida.
Resolucin de riesgos:
Evite el riesgo.
Traslade el riesgo de una parte del sistema a otra.
Consiga informacin acerca del riesgo.
Elimine el origen del riesgo.
Asuma el riesgo.
Comunique el riesgo.
Controle el riesgo (plan de contingencia).
Recuerde el riesgo.
6. SUPERVISIN
DEL RIESGO


Valoracin
de riesgos
6. SUPERVISIN DEL RIESGO
Valor cada riesgo: decidir si han cambiado sus efectos.
Se hace una valoracin despus de alcanzar cada hito principal.
Encargado de riesgos:
Alertar sobre los riesgos del proyecto y evitar que los admin. y
desarrolladores los ignoren en la planificacin.
Buscar todas las razones por las cuales el proyecto puede fallar.
Supervisar la efectividad de los planes de reduccin de riesgos.
Realizar el clsico anlisis costo-beneficio para la prevencin o el
plan de contingencia del riesgo.
7. EL PLAN DE
REDUCCIN,
SUPERVISIN Y
GESTIN DEL RIESGO
(RSGR)
7. EL PLAN DE REDUCCIN, SUPERVISIN Y GESTIN
DEL RIESGO (RSGR).
I. Introduccin
1. Alcance y propsito del documento
2. Visin general de los riesgos principales
3. Responsabilidades
a. Gestin
b. Personal tcnico
II. Tabla de riesgo del proyecto.
1. Descripcin de todos los riesgos por encima de la lnea de corte
2. Factores que influyen en la probabilidad e impacto
III. Reduccin, supervisin y gestin del riesgo
n. Riesgo # n
a. Reduccin
i.Estrategia general.
ii. Pasos especficos.
b. Supervisin
i. Factores a supervisar
ii. Enfoque de supervisin
c. Gestin
i. Plan de contingencia
ii. Consideraciones especiales.
IV. Planificacin temporal de revisin del Plan RSGR
V. Resumen
7. EL PLAN DE REDUCCIN, SUPERVISIN Y GESTIN
DEL RIESGO (RSGR).
HOJA DE INFORMACIN DEL RIESGO
ID Riesgo Fecha Probabilidad Magnitud de prdida Exposicin al riesgo
Descripcin
Refinamiento/contexto.
1
2
Reduccin/Supervisin
1
2
Gestin/Plan de Contingencia:
Estado Actual:
Autor: Asignado a:
8. Ejemplo de fracaso y posterior

recuperacin de implantacin de un
sistema ERP - Compaa: Nestl
8. Ejemplo de fracaso y posterior recuperacin de
implantacin de un sistema ERP - Compaa:
Nestl
Nestl firm un contrato con SAP para la
implantacin de un sistema ERP.
Pretenda integrar y centralizar sus ms de 200
compaas y subsidiarias en 80 pases.
Hasta 1991: Muchas marcas dispersas. Se
unificaron, pero seguan funcionando
independientemente.
En 1997: se descubri redundancia masiva.
Nestl USA estaba comprando vainilla al mismo
vendedor a 29 precios distintos.
implantacin de un sistema ERP - Compaa: Nestl
El proyecto presentado por Dunn se llamaba One Nestl,
under SAP.
En 1997, 50 top ejecutivos y 10 profesionales seniors de la
tecnologa de la informacin, encargados de implantar
el proyecto de SAP.
Meta: alcanzar una metodologa de procesos optima
para aplicar a todos los departamentos.
La crisis: comenz antes de que instalaran los mdulos
de SAP a finales de 1999.
Ninguno de los grupos que serian afectados directamente por el

sistema fueron representados en el comit del proyecto.
La crisis:
Los trabajadores no saban manejar los nuevos

sistemas y tampoco entendan los nuevos procesos.
Nadie quera utilizar el nuevo sistema.
Algunos mdulos quedaron desconectados por la prisa por
contrarestar el efecto 2000.
Ejemplo: El depto de ventas introduca un descuento y no
quedaba reflejado en el de contabilidad.
La mitigacin:
Implantar dos mdulos mas de SAP e integrarlos entre si.

Cost 5% ms del costo total del proyecto
Tom James: director de cambios de proceso Crear la
comunicacin entre los departamentos y el equipo del proceso.
Encuestas a los empleados Cmo va el nuevo sistema?
El resultado final:
Proyeccin de demanda muy exacta para sus productos.
Homogenidad de datos en todos los departamentos.
Reduccin de inventarios y costos de distribucin.
Cantidad ahorrada por Nestl tras la implantacin del sistema de
SAP asciende a 325 millones de dlares.

ANÁLISIS

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ANÁLISIS

Transféré par

Droits d'auteur :

Formats disponibles

Anlisis

Conjunto de hechos, principios y reglas clasificadas

Dar soporte a las actividades de un negocio, o

Anlisis del sistema actual.

Anlisis de requerimientos o requisitos para el

Anlisis econmico y tcnico.

Viabilidad Tcnica Viabilidad Econmica Viabilidad Legal

La respuesta es relativamente obvia. Si no se mide,

Correccin. Un programa debe operar correctamente o

Herramientas que soportan los 2 ltimos modelos

RESL -> Arquitectura/Resolucin de Riesgos

Atributos del personal

Atributos del proyecto

CUADRICULA DE IMPACTO DE VIABILIDAD (CIV)

Identificacin Anlisis Planeacin Supervisin

Listado de Listado de Planes de

Categoras 2. Riesgos del producto: Amenazan la calidad y la planificacin

3. Riesgos del negocio: Amenazan la viabilidad del software a

2. Riesgo estratgico: El producto no encaja en la estrategia

4. Riesgo de direccin: Perder el apoyo de un gerente

5. Riesgo de presupuesto: Perder presupuesto o personal

1. Riesgos conocidos: Los que se pueden descubrir despus de

Listado de Listado de Planes de

Identificacin Anlisis Planeacin Supervisin

Listado de Listado de Planes de

Priorizacin del Riesgos ms

Riesgo Categora Probabilidad Magnitud de Exposicin RSGR

5. Retraso total del proyecto: Se suman todas las exposiciones al riesgo

baja Relevancia para la

Identificacin Anlisis Planeacin Supervisin

Listado de Listado de Planes de

Identificacin Anlisis Planeacin Supervisin

Listado de Listado de Planes de

8. Ejemplo de fracaso y posterior

Ninguno de los grupos que serian afectados directamente por el

Los trabajadores no saban manejar los nuevos

Implantar dos mdulos mas de SAP e integrarlos entre si.

Vous aimerez peut-être aussi