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