Regla 6:

El proceso de gestin de riesgos debe definirse y seguirse de forma consistente en toda la

organizacin. Todas las actividades deben ser tendientes a complementar los requisitos de
una poltica organizacional de gestin de riesgos.

Tcnicas de identificacin de riesgos.
Lluvia de ideas: en este mtodo, los miembros identifican riesgos sin emplear ninguna
estructura como base y de forma oral para permitir a los dems participantes el construir
nuevas ideas en base a los pensamientos de otros. Para lograr los resultados esperados, es
importante elegir como miembros del grupo a personas que estn familiarizadas con los
temas a discutir y, en michos casos, suele ser comn el entregar la documentacin
pertinente antes de las sesiones de identificacin de riesgos con el fin de lograr una mayor
efectividad. El uso de esta tcnica suele trasladarse adems a otras etapas (por ejemplo, al
momento de generar estrategias de mitigacin).
Encuestas: contienen una serie de preguntas tendientes a realizar la identificacin de
riesgos en un rea particular de inters. Un inconveniente intrnseco de este mtodo es
que la gente suele no sentirse atrada por las mismas, motivo por el cual pueden brindar
informacin inapropiada; adems, puede ser dificultoso evaluar las respuestas por la
evidente subjetividad asociada a las mismas. Su ventaja principal lo constituye la
posibilidad de obtener una amplia variedad de opiniones sin necesidad de organizar una
reunin para contar con todos los participantes (algunos de los cuales pueden ser de difcil
acceso).
Conocimiento por experiencia o documentado: es una coleccin de informacin que ha
sido obtenido mediante su experiencia. El conocimiento documentados es una coleccin
de informacin que ha sido documentada respecto a un determinado temas (en este caso
particular, riesgos en una determinada rea de inters). Es importante considerar que
debe validarse la relevancia y aplicabilidad de los conocimientos del experto y de la
documentacin pertinente al hacer uso de estas tcnicas.
Grupos de trabajo: son un mecanismo muy importante para el anlisis de un rea o tema
particular al realizar un proceso de discusin que posibilita el descubrimiento de riesgos
que podran no ser obvios por el grupo encargado especficamente de la identificacin.
Generalmente, estos grupos de trabajo estn compuestos por personas especializadas en
alguna determinada temtica relacionada con el proyecto.
Modelo de capacidad de madurez
El problema fundamental de las organizaciones de software es una inhabilidad para administrar
sus procesos. El CMM para software se convierte en una gua que nos ayudara a ganar el control
sobre estos procesos y as desarrollar y mantener un mejor software. La meta a alcanzar ser la
evolucin hacia una cultura de excelencia tanto en la ingeniera como en la administracin de
software.
El CMM prcticas de planeacin, ingeniera y administracin de desarrollo y mantenimiento de
software.
Si se siguen estas prcticas aumentara la habilidad con que una organizacin podr alcanzar metas
como costos, programa, funcionalidad y calidad de producto.
El propsito del CMM es el guiar a las organizaciones en la seleccin de estrategias de mejoras
determinado la madurez del proceso actual e identificando los puntos importantes para as
mejorar tanto el proceso como la calidad de software.
Ahora Por qu confiar en CMM? El modelo de capacidad y madurez est basado en prcticas
reales, refleja las mejores prcticas en el rea, tambin refleja la necesidad de los individuos, de
llevar a cabo una mejora en el proceso de software, al igual que la valoracin del proceso de
software, y para finalizar el CMM est documentado y es pblico (Paulk 1994).
Nivel 1
Es el punto base sin valor. Una empresa estar ubicada en el nivel inicial si su proceso es ad-hoc o
catico. Esto quiere decir que realmente no existe un ambiente estable en el cual no se pueda
desarrollar o mantener un software. En este nivel tendremos un nmero de entradas, seguidas por
cierto proceso que realmente no estaba documentado, ni se documenta.
En este nivel lo normal es no alcanzar las metas definidas ni tiempo ni costo ni recursos planeados.
Y si esto llegara a ocurrir seria gracias a personas excepcionales dentro del equipo de trabajo.
Suponiendo que gracias a esfuerzos heroicos se logra tener xito en el proyecto.
La capacidad es una cualidad de las personas mas no de la organizacin, se alcanza el propsito del
proceso de manera inconsistente. No es planeado ni lleva seguimiento.
Nivel 2
La organizacin debe empezar a documentar su proceso, empezamos a guardar informacin. As
pues una empresa cuenta con polticas que le permitan administrar un proyecto de software y a su
vez cuenta con procedimiento para verificar que estas polticas son implementadas.

Nivel 3: Definido
Contamos con un proceso de software estndar de la organizacin para desarrollar o mantener el
software. Este est documentado y es implementado a lo largo de toda la organizacin en
distintos proyectos. Este proyecto es la unin de prcticas de ingeniera de software y de
administracin de procesos.
Algunos puntos del nivel 3:
Los procesos se implementan y actualizan para ayudar a los administradores de proyectos
y staff tcnico de desempear ms efectivamente.
Para estandarizar se ocupan prcticas de ingeniera de software.
Un grupo dentro de la organizacin est encargado de las actividades del proceso del
software.
La organizacin cuenta con un programa de capacitacin para que todos los miembros de
la organizacin cuenten con el conocimiento y las habilidades requeridas para
desempear completamente sus roles.
El proceso de software estndar de la organizacin se amolda a cada proyecto para as
determinar el proceso del software definido del proyecto (su propio proceso de software).
Este contendr informacin acerca de cmo saber que ya est listo el producto, entradas
estndares y procedimientos para desarrollar el trabajo, mecnicos de verificacin, salidas
y un criterio de terminacin.

Conclusin nivel 3: definido
El nivel 3 es estndar y consistente ya que gracias a las prcticas de ingeniera de software y a las
de administracin de proyectos el proceso es estable y repetible. La capacidad se logra basndose
en el entendimiento de las actividades roles y responsabilidades en un proceso de software bien
definido. La administracin ahora puede prepararse con anterioridad para afrontar riesgos
posibles. En este nivel se cuenta con planes y programas de mejora aunque no necesariamente se
les da un seguimiento. La medicin no es solo de productos sino tambin de servicios.
Nivel 4: Administrado
Hacemos uso de todos los datos recolectados. Convertimos datos en informacin relevante para la
organizacin para as identificar qu era lo que estaba mal.
En este nivel podra llamarse cuantitativo, ya que en l cualquier decisin es respaldada por una
base cuantitativa, medimos el progreso y los problemas. Y mientras aumentamos la probabilidad
de ser ms precisos en nuestros estimados, reducimos la variabilidad (incertidumbre) de nuestro
proceso. El cliente tendr un entendimiento medible tanto de la capacidad del proceso como del
riesgo que este implica, incluso antes que el proyecto inicie.
En este nivel la organizacin fija metas de calidad tanto del proceso como del producto. Existe un
programa de medicin dentro de la organizacin que es aplicado a lo largo de todos los proyectos,
midiendo as la productividad y la calidad.
Al mismo tiempo, la organizacin cuenta con un repositorio de informacin donde almacena
informacin relevante de proyectos anteriores que podra utilizarse en proyectos futuros.
Todos los procesos de software son medidos. En este nivel formamos la parte cuantitativa de la
organizacin para poder evaluar los proyectos, los procesos y los productos. Esto no quiere decir
que en niveles anteriores no se obtuvo informacin cuantitativa. Puede ser que si guardo este tipo
de informacin pero no es sino hasta el nivel 4 que le damos un significado a esta informacin
valiosa.
Todas estas mediciones nos marcan distintos limites (inferiores y superiores) de como debera llev