Está en la página 1de 10

Tabla de Contenidos

1 USANDO LA TABLA DE RIESGOS 2 FACTORES DE RIESGO GENERALES PARA SOFTWARE 2 3

Factores de Riesgos para Proyectos de Software

1 USANDO

LA TABLA DE RIESGOS

Un equipo de proyecto podra usar esta tabla para analizar los riesgos de su proyecto. El equipo puede decidir que factores son relevantes y en que ranking, luego proceder a definir los riegos que supuestamente podran afectar su proyecto. Cuando el proyecto se completa, el equipo debera revisar lo realizado contra los riesgos y ver si hay factores para agregar a esta tabla, o ajustar aquellos que debieran ser cambiados
El material en la tabla es organizado con los siguientes encabezados: Factor ID

Nmero secuencia asignado a cada factor en este dominio.


Categora de Riesgo

Encabezado que nombra la categora de los siguientes factores de riesgo.


Factores de Riesgo

Areas nombradas de potencial riesgo para proyectos en este dominio.


Seal de Bajo Riesgo

Caractersticas de este factor cuando puede ser considerado de bajo riesgo para el proyecto
Seal de Riesgo Medio

Caractersticas de este factor cuando provee un riesgo medio para el proyecto


Seal de Alto Riesgo

Caractersticas de este factor cuando debera ser considerado de alto riesgo para el proyecto
Rating

Nivel de riesgo que posee este proyecto Bajo Este proyecto exhibe la seal de bajo riesgo, o parece no tener riesgo en este rea. Medio Este proyecto exhibe la seal de riesgo medio, o algo similar
Alto

Este proyecto exhibe la seal de alto riesgo, o algo similar No Aplica Este factor no es aplicable a este proyecto.

Pagina 2 de 10

Factores de Riesgos para Proyectos de Software

2
Factor ID 2 3 4 5 6 7 8

FACTORES

DE

RIESGO GENERALES

PARA

SOFTWARE
Rating (elegir uno)

Factor de Riesgo

Bajo Riesgo

Riesgo Medio

Riesgo Alto

N/A Alto Medi Bajo

Mision y Objetivos El proyecto se ajusta a la 1 organizacin del Cliente El proyecto se ajusta a la organizacin del proveedor Percepcin del Cliente

Flujo de trabajo

No soporta o no se Soporta directamente Impacta indirectamente en relaciona a la misin u misin y/u objetivos de la uno o ms objetivos del objetivos de la organizacin del cliente cliente organizacin del cliente No soporta o no se Soporta directamente Impacta indirectamente en relaciona a la misin u misin y/u objetivos de la uno o ms objetivos del objetivos de la organizacin del proveedor organizacin del proveedor proveedor El proyecto no est en La organizacin est El Cliente espera que esta sintona con los trabajando en proyectos en organizacin provea este principales servicios o reas no esperadas por el producto productos de la cliente organizacin Cambiarn algunos Cambios significativos al Poco o ningn cambio al aspectos o tendrn flujo de trabajo o mtodo flujo de trabajo pequeos efectos sobre el de la organizacin flujo de trabajo Los objetivos de los proyectos dentro del programa estn sustentados o se complementan uno a otro Los proyectos comparten con el programa los recursos sin ningn conflicto Mltiples clientes del programa poseen necesidades comunes El programa posee un Gerente de Programa que coordina los proyectos Los objetivos de los proyectos no estn en conflicto, pero proveen poco soporte directo Los proyectos dentro del programa, programan los recursos cuidadosamente para evitar conflictos Mltiples clientes del programa poseen diferentes pero no conflictivas necesidades El programa posee una persona o equipo responsable del programa, pero no dispone del suficiente tiempo para liderar efectivamente

Gestin de Proyectos Conflicto en los objetivos Los objetivos del proyecto estn en conflicto, directa o indirectamente Los proyectos dentro del programa frecuentemente necesitan los mismos recursos al mismo tiempo (o compiten por el mismo presupuesto) Mltiples clientes del programa estn tratando de conducirlo en diferentes direcciones El programa no posee lider, o el concepto de gerente de programa no est en uso

Conflicto de recursos

Conflictos entre clientes

Liderazgo

Pagina 3 de 10

Factores de Riesgos para Proyectos de Software


Experiencia del Gerente de Programa El gerente de programa El gerente de programa tiene alguna experiencia, posee una gran pero son aconsejados por experiencia en el dominio expertos en el tema. El programa esta bien definido, con un alcance que es manejable por esta organizacin El programa est bien definido, pero probablemente no pueda ser manejado por esta organizacin El gerente de programa es nuevo en el dominio

10

La definicin del programa

El programa no est bien definido o posee objetivos conflictivos en el alcance

Gestores de Decisin Ninguna eleccin manejada polticamente ha sido tomada El proyecto tiene varias decisiones motivadas El proyecto tiene una polticamente, tales como la variedad de influencias eleccin de un vendedor polticas por razones polticas mas que por sus calificaciones. La fecha est parcialmente condicionada por necesidad de satisfacer la demo de marketing, muestra comercial, u otro mandato no relacionado a la estimacin tcnica La fecha est siendo totalmente condicionada por necesidad de satisfacer la demo de marketing, muestra comercial, u otro mandato; sin considerar las estimaciones del equipo de proyecto El proyecto est siendo realizado de manera de mostrar una nueva tecnologa o como una excusa para traer nueva tecnologa a la organizacin El equipo de proyecto ha estado explcitamente dirigido a ignorar la visin del largo plazo y enfoca en completar el entregable del corto plazo

11

Influencias polticas

12

Conveniencia de fechas

La fecha de entrega ha sido definida por un proceso razonable.

13

Tecnologa atractiva

La tecnologa seleccionada ha sido usada por algn tiempo

El proyecto est siendo realizado de manera poco ptima, influenciado por la compra o desarrollo de nueva tecnologa

14

Solucin de corto plazo

El proyecto satisface las necesidades del corto plazo sin comprometer seriamente la visin del largo plazo

El proyecto enfoca la solucin de corto plazo, con poca comprensin de las necesidades en el largo plazo

Organizacin / Gerencia Estabilidad de la 15 Organizacin Pocos o ningn cambio en la expectativa de la gerencia o estructura organizativa Algn cambio en la gerencia o expectativa de reorganizacin Los individuos comprenden sus propios roles y responsabilidades, pero no estn seguros sobre quin es responsable del trabajo fuera de su grupo inmediato Las polticas y estndares de Desarrollo estn definidas, pero no son tenidas en cuenta Pagina 4 de 10 La gerencia o estructura organizativa est continuamente cambiando Muchos en la organizacin no estn seguros de quin es responsable de muchas de las actividades de la organizacin No existen polticas ni estndares definidos, o estn pobremente definidos y no se usan

Los individuos a travs de la organizacin Roles y comprenden sus propios 16 Responsabilidaden roles y responsabilidades, de la Organizacin y los de los dems miembros Polticas y 17 estndares Las polticas y estndares de Desarrollo estn definidas y son seguidas cuidadosamente

Factores de Riesgos para Proyectos de Software


Fuertemente Algn compromiso, pero no 18 Soporte gerencial comprometida con el xito Poco o nada de soporte total del proyecto 19 Involucramiento ejecutivo Soporte visible y fuerte Objetivos del proyecto verificables, requerimientos razonables Usuarios altamente involucrados con el equipo de proyecto Usuarios altamente experimentados en proyectos similares, poseen ideas de cmo satisfacer las necesidades Soporte ocasional, provee ayuda en temas clave cuando se lo consulta Existen algunos objetivos del proyecto, pero las mediciones pueden ser cuestionadas Ningn soporte visible; ninguna ayuda sobre custiones no resueltas No se han establecido los objetivos del proyecto o no son medibles

Objetivos del 20 proyecto Cliente/Usuario 21 Involucramiento del usuario

Los usuarios juegan roles Falta o mnimo menores, impacto Involucramiento del moderado sobre el sistema usuario. Los usuarios tiene experiencia con proyectos similares y tienen necesidades en mente Los usuarios no poseen experiencia previa con proyectos similares; no estn seguros de cmo satisfacer las necesidades Los usuarios no participan de la aceptacin de definiciones globales y de detalle del sistema.

22

Experiencia del Usuario

Aceptacin del 23 usuario

Los usuarios aceptan la Los usuarios aceptan mayora de definiciones definiciones globales y de globales y de detalle del detalle del sistema. sistema. Necesidades de entrenamiento a usuario son consideradas, pero ningn plan de entrenamiento est en progreso.

Necesidades de entrenamiento a usuario Necesidades de son consideradas, el 24 entrenamiento del entrenamiento est en usuario progreso o al menos existe un plan Parmetros de Proyectos 25 Tamao del proyecto Restricciones de hardware

Los requerimientos no estn identificados.

Tamao medio, Pequeo, no-complejo, o complejidad moderada, fcil de descomponer descomponible Poca o ninguna limitacin Alguna limitacin de de hardware impuesta o hardware impuesta, varias plataforma simple plataformas

Tamao grande, altamente complejo, o no descomponible Limitaciones significativas de hardware; mltiples plataformas

26

Componentes 27 reusables

Componentes Componentes disponibles Componentes disponibles, idetificados, necesitan y compatibles con el pero necesitan alguna serias modificaciones enfoque revisin para el uso Los componentes Componetes disponibles y funcionan bajo la mayora usables directamente de las circunstancias Suficiente presupuesto asignado Fondos asignados sin restriccones presupuesto cuestionable Algunos problemas en la disponibilidad de fondos Pagina 5 de 10 Componentes que fallan en ciertos casos, probablemente sea tarde, o partes incompatibles con el enfoque Presupesto incierto Asignacin incierta o sujeta a cambios

28

Componentes provistos Tamao de Presupuesto Limitaciones de presupuesto

29 30

Factores de Riesgos para Proyectos de Software


31 Compromiso de entrega Fechas comprometidas estables. Compromisos algo inciertos Compromisos no estables o fluctuantes

32

Desarrollo de cronograma

El equipo est de acuerdo El equipo est de acuerdo El equipo descubre que en que 2 o ms fases del en que el cronograma es una fase del plan tiene una cronograma, aceptable y puede ser programacin muy agresiva probablemente no sern satisfecho satisfechas Los requerimientos cambian muy frecuentemente Algunos requerimientos se encuentran slo en la cabeza del cliente.

Contenido del Producto Pocos o ningn cambio a Algunos cambios se Estabilidad en los 33 la definicin aprobada producen sobre la requerimientos (lnea base) definicin aprobada 34 Todos completamente Requerimientos especificados y completos y claros claramente escritos Algunos requerimientos incompletos o poco claros

35 Testeabilidad

La mayora del producto Requerimientos fciles de Partes del producto difciles es difcil de probar, o no testear de testear se ha hecho el plan de pruebas Est poco claro cmo Las interfaces no estn Interfaces bien definidas; disear, o algunos aspectos bien definidas o diseo bien comprendido del diseo an no han sido controladas decididos Los algoritmos y/o diseo Los algoritmos y el diseo tienen algunos elementos son razonables para que difciles de implementar el equipo los implemente para el equipo Los algoritmos y/o diseo tienen componentes que este equipo encontrar muy difciles de implementar

Dificultades en el 36 Diseo

37

Dificultad de implementacin

Distribucin Recursos de 38 hardware para entregar 39 Factores de performance Maduro, capacidad de crecer en el sistema, flexible Encaja dentro de los lmites establecidos Disponible, alguna capacidad de crecimiento Opera ocasionalmente sobre los lmites Ninguna capacidad de crecimiento, inflexible Opera continuamente en los niveles lmites

40

Impacto en el servicio al cliente

Requiere pocos cambios en servicio al cliente

Requiere cambios Requiere cambios menores mayores al servicio al al servicio al cliente cliente Muchos datos para Muchos datos para migrar, migrar; varios tipos de pero buenas descripciones bases de datos o no hay disponibles de estructuras y buenas descripciones de usos lo que se tiene Alguna integracin o interfaces necesarias Interfaces requeridas

41

Migracin de datos Pocos o ningn dato a requerida migrar

Hardware externo Poca o ninguna 42 o interfaces de integracin o interfaces software necesarias Proceso de desarrollo

Pagina 6 de 10

Factores de Riesgos para Proyectos de Software


Anlisis de alternativas Anlisis de alternativas completo, algunas completo, todas suposiciones cuestionables consideradas, o alternativas no suposiciones verificables consideradas Procedimientos establecidos, pero no bien seguidos o poco efectivos El anlisis no es completo, no todas las alternativas son consideradas, o fallan las suposiciones Ningn proceso de QA establecido.

43

Anlisis de alternativas

Enfoque de Sistema de QA 44 aseguramiento de establecido, seguido, y calidad efectivo. 45 Desarrollo de documentacin Uso de proceso definido Correcta y disponible Proceso de desarrollo establecido, efectivo, y seguido por el equipo Son incorporadas revisiones por pares Seguimiento definido de fallas, consistente y efectivo

Algunas definciencias, pero No existe disponible Proceso establecido, pero Proceso informal usado no seguido, o poco efectivo Revisiones por pares son usadas espordicamente Proceso definido de seguimiento de defectos, pero inconsistentemente usado El equipo espera encontrar todos los defectos durante el testing Ningn proceso para seguir defectos No es usado ningn proceso de control de cambios Se necesitan modificaciones importantes; o no existe infraestructura

46

Identificacin 47 temprana de defectos Seguimiento de 48 fallas Control de 49 cambios para productos

Proceso de control de Proceso de control de cambios formal, seguido y cambios definido, no efectivo seguido o inefectivo

Ambiente de desarrollo Ninguna o poca Infraestructura / 50 necesidad de Facilidades fsicas modificacin 51 Plataforma de hardware Estable, no se esperan cambios, capacidad suficiente Algunas modificaciones resultan necesarias

Algn cambio en progreso, Plataforma bajo desarrollo pero controlado junto con el software No validada, propietaria o no dispone de alguna funcionalidad esencial Poco o nada de soporte, alto costo, y/o pobre tiempo de respuesta El contrato posee demasiados requerimientos de documentacin u ocasiona demasiado trabajo extra al equipo

52

Herramientas disponibles

Disponible, validada, pero no dispone de toda la Disponible en el lugar, funcionalidad necesaria (o documentada, y validada posee documentacin mnima) Soporte completo a precio Adecuado soporte en el razonable y en el tiempo precio contratado, tiempo necesario de respuesta razonable

53

Soporte del proveedor

54 Contrato

El contrato con el cliente El contrato posee temas posee buenos trminos, la abiertos que podran comunicacin con el ocasionar problemas equipo es buena

Pagina 7 de 10

Factores de Riesgos para Proyectos de Software


Todas las reas siguen guas de seguridad; Recuperacin ante resguardo de datos; 55 desastres sistema de recuperacin de desastres in-situ; se siguen los procedimientos Gerencia de Proyecto 56 Enfoque de PM Planificacin del proceso Necesidad de mejorar la Carencia de planificacin y producto, y monitoreo planificacin y el monitoreo y monitoreo in-situ Los objetivos y estados se Se comunica algo de comunican claramente informacin en algn entre el equipo y el resto momento de la organizacin El gerente del proyecto Gerente de proyecto muy tiene experiencia experimentado en moderada, o posee proyectos similares experiencia en otros tipos de proyectos Raramente se comunica en forma clara al equipo o a otros que necesitan ser informados del estado El gerente de proyectos no tiene experiencia con este tipo de proyectos o el gerente es nuevo. Le interesa muy poco el proyecto Tiene poca autoridad desde su ubicacin en la estructura organizativa, y poca potencia personal para influenciar sobre las decisiones de los dems Ningn soporte visible; slo el cargo de gerente Grandes cambios, falta de disponibilidad; el equipo ocupa mucho tiempo apagando incendios Algunas disciplinas no representadas Poca o ninguna experiencia en proyectos similares Se toman algunas medidas de seguridad; la recuperacin ante desastres es considerada, pero no se poseen procedimientos o stos no son seguidos Ninguna medida de seguridad; carecen de backup; no se tiene en cuenta la recuperacin ante desastres

Comunicacin de 57 PM

Experiencia del 58 gerente de proyecto

59

Fuertemente Actitud del gerente Bien dispuesto para hacer comprometido con el xito de proyectos lo que haga falta del proyecto Posee lnea gerencial o autoridad oficial que lo habilita como lder efectivo del proyecto Soporte completo del equipo y del gerente Puede influenciar a distintas personas de la organizacin, basado en las relaciones personales. Soporte de la mayora del equipo, con algunas reservas.

Autoridad del 60 gerente de proyectos Soporte del 61 gerente de proyecto Equipo de Projecto Disponibilidad de 62 miembros del equipo Mezcla de habilidades

In-situ; pocos cambios esperados

Disponible; algunos cambios esperados Algunas disciplinas inadecuadamente representadas

63

Buena mezcla de habilidades

64 Experiencia

Experiencia importante en Algo de experiencia con equipos con proyectos proyectos similares como ste.

Experiencia con el hardware y 65 Gran experiencia software del proyecto

Experiencia promedio

Baja experiencia

Pagina 8 de 10

Factores de Riesgos para Proyectos de Software


Experiencia en el proceso Algo de experiencia con Poca o ninguna Experiencia importante en este proceso o experiencia experiencia con un este proceso importante con otro proceso proceso definido No existe plan de entrenamiento Poco o ningn compromiso con el proyecto, no es un equipo cohesivo Productividad baja, hitos no satisfechos, demoras en los entregables Ninguna experiencia en el dominio, dentro del equipo; no hay expertos dispobibles

66

Entrenamiento no Plan de entrenamiento Entrenamiento del disponible para algunas 67 disponible, entrenamiento equipo reas, o entrenamiento permanente planificado para el futuro Espritu y actitud 68 del equipo Fuerte compromiso con el Alguna persona no xito del proyecto, comprometida con el xito cooperativo. del proyecto Todos los hitos satisfechos, entregables teminados en tiempo, alta productividad Hitos satisfechos, algunas demoras en los entregables, productividad aceptable Alguna experiencia en el dominio de aplicacin por parte del equipo, o pueden llamar a expertos cuando lo necesitan

Productividad del 69 equipo

Buena experiencia en el Experiencia en el dominio de la aplicacin 70 rea de aplicacin por parte del equipo de (dominio) desarrollo Tecnologa

La tecnologa La tecnologa se La tecnologa planificada Alguna de la tecnologa seleccionada se ajusta 71 corresponde con el se ajusta bastante bien a planificada no se ajusta pobremente al problema o proyecto los clientes y al problema bien al problema o al cliente cliente Experiencia en la Buen nivel de experiencia Alguna experiencia con la Ninguna experiencia con 72 tecnologa por en la tecnologa tecnologa la tecnologa parte del equipo Disponibilidad de 73 expertos en la tecnologa Madurez en 74 tecnologa Mantenimiento 75 Complejidad del diseo Personal de soporte Mantenible estructuralmente (baja complejidad) En el lugar, experimentada, y suficiente en nmero Ciertos aspectos difciles de Extremadamente difcil de mantener (complejidad mantener (alta media) complejidad) Falta experiencia en algunas reas Falta de experiencia Los expertos en la tecnologa, estn disponibles Hay expertos disponibles en algn lugar de la organizacin Se necesitar ayuda externa a la organizacin Uso de tecnologa nueva y desconocida, lo que implica ciertos riesgo a manejar

La tecnologa ha estado La tecnologa usada es en uso en la industria por bastante bien conocida en bastante tiempo la industria

76

77

Soporte del proveedor

Soporte completo a precio Soporte adecuado al precio Poco o nada de soporte, razonable en el tiempo contratado, teimpo de alto costo, y/o pobre necesario respuesta razonable tiempo de respuesta Parte del equipo de testing Desarrollo es responsable pertenece al equipo de del testing desarrollo o dentro del Pagina 9 de 10

Testing 78 Independencia del El equipo de Testing es Equipo de Testing independiente

Factores de Riesgos para Proyectos de Software


mismo equipo de desarrollo se cruza el testing El equipo es compartido Disponibilidad del Existe el equipo destinado con desarrollo pero existe 79 equipo para testing para testing politica de manejo del ambiente de testing Automatizacion de Existe herramienta de Existe herramienta pero no 80 testing automatizacin de testing se adapta bien al proyecto Conocimiento de La herramienta es No todos los miembros del 81 herramienta de conocida por el equipo de equipo tienen experiencia Testing testing en la herramienta Total Categorias 15 Total Factores 81

Equipo compartido y sin poltica de ambiente No existe herramienta de automatizacin de testing La herramienta es nueva para el equipo de testing

Pagina 10 de 10

También podría gustarte