Read without ads and support Scribd by becoming a Scribd Premium Reader.
See Premium Plans
 
1
 
 Abstract 
-- Aunque los diversos enfoques de gestión del riesgoaparecieron hace más de una década, sigue siendo evidente lapoca utilización de sus técnicas en los proyectos de desarrollo desoftware actuales. Uno de los métodos más conocido es el métododel SEI, conocido como Continuous Risk Management (SEI-CRM). En este artículo mostraremos la aplicación de este métodoen un proyecto universitario de desarrollo de software degrandes dimensiones. Además, nuestro trabajo muestra queconviene completar el SEI-CRM con un conjunto apropiado deriesgos organizacionales. Con nuestra investigación aplicada,esperamos contribuir al conocimiento de la gestión de los riesgosen proyectos de desarrollo del software, mediante la ampliacióndel método SEI-CRM con aquellos factores organizacionales deriesgo que han resultado relevantes en nuestro proyecto y ennuestra investigación previa.
 Index Terms
-- Métodos de gestión de riesgos, Continuous Risk Management (CRM), riesgos organizacionales, gestión deproyectos informáticos.
I. I
 NTRODUCCIÓN
 a investigación en la gestión de riesgos en el ámbito delsoftware procura formalizar conocimiento orientado a laminimización o evitación de riesgos en proyectos dedesarrollo de software, mediante la generación de principios y buenas prácticas de aplicación realista [10]. Hasta el momentose han propuesto y utilizado diferentes enfoques de gestión delriesgo desde que Boehm [2] atrajo a la comunidad deingeniería del software hacia la gestión del riesgo. Sinembargo, es evidente que pocas organizaciones utilizantodavía de una forma explícita y sistemática métodosespecíficos para gestionar los riesgos en sus proyectossoftware [13,16]. Así, por ejemplo, durante el año 2001, KLCIrealizó y publicó un estudio con 268 organizaciones de todo elmundo y el resultado fue que: el 3% no utilizaba ningúnmarco de gestión del riesgo, el 18% utilizaba algún marcocaótico para identificar sus riesgos, el 37% de los participanteshabían utilizado algún marco informal, el 28% utilizaban procedimientos repetitivos y sólo un 14% utilizaba unenfoque formal para identificar riesgos [13]. Según esteestudio, las razones más comunes para utilizar un marcoinformal son: falta de procedimientos, necesidades del proyecto no adecuadas, organización inmadura y compromisodel equipo. Según Hoffman [5], aunque algunasorganizaciones usen procesos formales de gestión del riesgo para otras partes de su negocio, demuestran una gestión deriesgos pobre en el ámbito general de los sistemas deinformación. Kontio y Basili [16] creen que hay tres razones principales para la baja tasa de divulgación de tecnologías degestión del riesgo: falta de conocimiento sobre posiblesmétodos y herramientas, limitaciones prácticas y teóricas delos marcos de gestión de riesgos que entorpecen la facilidadde uso de estos métodos, y tercero, todavía hay pocosinformes con evaluaciones sistemáticas o científicas que proporcionen feedback empírico sobre su viabilidad y beneficios.El riesgo en un proyecto de desarrollo de software incluyecomponentes técnicos y de conocimiento del riesgo [6].Diferentes estudios han mostrado que la mayoría de los proyectos fallan sobre todo en gestión, no tecnológicamente.Además, son los temas de naturaleza organizacional losfactores de riesgos del proyecto más dominantes a la vez queson los que se tratan satisfactoriamente en menos de la tercera parte de los proyectos de desarrollo [3]. Schmidt et al. [11]han observado que jefes de proyecto exitosos puntúan bajoaquellos factores sobre los que no tienen control o influenciacomo: conflictos entre departamentos usuarios, cambio del propietario o responsable ejecutivo del proyecto, volatilidaddel personal, número de unidades de la organizaciónimplicadas y proyectos que involucran a múltiples proveedores. Otro aspecto que influye en estos temas es lafalta de reconocimiento sobre la importancia de los aspectosorganizacionales que existe en gran parte de la comunidad profesional y académica vinculada a las tecnologías de lainformación y la comunicación, como muestran Doherty yKing [3].La finalidad de este artículo es, en primer lugar, describir lautilización del método conocido como SEI-CRM (SoftwareEngineering Institute - Continuous Risk Management) en un proyecto universitario de desarrollo de software de grandesdimensiones llevado a cabo en la Universitat Politècnica deCatalunya (UPC). En segundo lugar, queremos explicar laextensión realizada para dicho proyecto de la taxonomía deriesgos del SEI-CRM con riesgos organizacionales basados enun modelo anterior de factores críticos de éxito (FCE) paraimplementaciones de sistemas ERP (Enterprise ResourcePlanning) propuesto por Esteves y Pastor [15].De esta manera, se puede decir que la estrategia deidentificación y gestión de riesgos propuesta en este artículo
Implementación y Mejora del Método deGestión Riesgos del SEI en un proyectouniversitario de desarrollo de software
J. Esteves,
 Instituto de Empresa
, J.A. Pastor,
Universitat Internacional de Catalunya
, N. Rodríguez,
Universitat Politècnica de Catalunya
, & R. Roy,
Universitat Politècnica de Catalunya
 
L
 
2
resulta innovadora si la comparamos con otros trabajosrelacionados con anterioridad.De hecho, son dos los motivos principales por los que seadoptó el modelo unificado de FCE mencionado. Por una parte, la misma UPC había implantado un sistema ERP dosaños antes de empezar el proyecto de desarrollo en cuestión.En su momento se consideró que la información relacionadacon la predicción u ocurrencia de riesgos en proyectosanteriores de la UPC de nivel similar de complejidad (como por ejemplo sus causas, consecuencias, su tratamiento o eléxito de los planes de mitigación y contingencia) podía ayudar a los gestores a identificar y gestionar los riesgos del proyectoen curso. Además el aprendizaje de los resultadosrelacionados con la gestión del riesgo de proyectos anteriores puede contribuir al enriquecimiento del enfoque de planificación de los riesgos del nuevo proyecto. En segundolugar, el modelo unificado de FCE incluye un conjuntoconciso y bien definido de los factores críticos de éxito denaturaleza organizacional, que se pueden reinterpretar fácilmente como “factores críticos del riesgo”.Este artículo está estructurado de la siguiente manera.Primero se presenta una breve visión de los antecedentes delestudio. A continuación, se presentan las diferentes fases de lagestión del riesgo en el proyecto abordado y se comenta suimplementación. Después explicamos algunos de los riesgosorganizacionales utilizados en la extensión del SEI-CRM.Finalmente, presentamos las conclusiones y el trabajo futuro.II.
ANTECEDENTES DEL PROYECTO
PRISMA
 
La Universitat Politècnica de Catalunya (UPC) es unainstitución pública de enseñanza superior cuyos objetivos prioritarios son el estudio, la docencia, la investigación y latransferencia de tecnología de calidad. Fue fundada en losaños 70 y actualmente tiene más de 30.000 estudiantes,estando formada por 15 escuelas técnicas superiores yfacultades, 7 centros adscritos y 3 institutos universitarios deinvestigación. Uno de sus principales objetivos es transferir los resultados de sus investigaciones a las empresas. En estesentido, es la primera universidad española en volumen derecursos obtenidos por transferencia de tecnología.En el 2001 la UPC decidió unificar la gestión de losestudios de toda la universidad en un único sistema. Despuésde evaluar las diferentes alternativas existentes en el mercado,tomó la decisión de desarrollar su propio sistema deinformación informático para administrar los estudiosacadémicos, y seleccionó una unidad informática interna parallevarlo a cabo. El proyecto se llamó PRISMA y sus tres principales metas fueron: construir una única base de datos yun único sistema de información, tener acceso multicanal al SI(centro, Internet, móvil) y facilitar la adaptación a laconvergencia europea de los estudios universitarios impulsada por la Declaración de Bolonia.III. F
ASES DE LA
G
ESTIÓN DEL
R 
IESGO EN
PRISMA
 
Esta sección trata de proporcionar una visión general del proceso de gestión de riesgos diseñado y utilizado en el proyecto PRISMA, incluyendo la selección de un marco degestión de riesgos, su descripción, el equipo encargado dellevar a cabo el proceso y la descripción del plan de gestióndel riesgo que lo detallaba.
 A. Selección de un Método de Gestión de Riesgos
Esta fase consistió en la identificación, evaluación yselección de los diferentes métodos existentes para organizar la implementación de las funciones básicas que deben llevarsea cabo para una gestión efectiva de los riesgos “antes de queestos lleguen a ser amenazas para el éxito”. La Tabla 1muestra los métodos que fueron evaluados, ampliamenteconocidos y fácilmente accesibles por sus nombres o por lasorganizaciones que los avalan: Euromethod, Safe, SEI-CRM,RiskIt y los métodos para la gestión de riesgos del IEEE y delPMI (Project Management Institute). Es importante tener  presente que cada método establece categorías para lasfunciones del riesgo en diferentes fases. Para cada métodoanalizamos qué funciones de la Tabla 1 trata, y cómo proponeabordarlas.
TABLA
 
IL
ISTA DE LOS MÉTODOS DE GESTIÓN DEL RIESGO EVALUADOS EN EL PROYECTO
PRISMA.Euromethod Safe SEI IEEERiskit PMIPlan de Gestión
Identificación
  
Estimación
Evaluación
  
Planificación
  
Tratamiento
  
Seguimiento y control
  
Comunicación
El equipo de gestión del riesgo y el jefe del proyecto dePRISMA decidieron adoptar el método SEI-CRM por dosmotivos. Primero, el SEI-CRM es uno de los métodos degestión del riesgo más completo, con más documentacióndetallada y cuya aplicación está más extendida en la industria.Segundo, en paralelo, el proyecto PRISMA trabajaba paraconseguir el nivel 2 de madurez del SW-CMM nivel 2 delSEI, lo que apoyaba la opción de incorporar el SEI-CRMcomo parte de sus actividades.
 B. El método Continuous Risk Management del SEI 
El método Continuous Risk Management (SEI-CRM),desarrollado por el Software Engineering Institute (SEI), es unmétodo en el ámbito de la ingeniería del software cuyosconceptos, procesos y herramientas permiten gestionar demanera continua los riesgos de un proyecto, proporcionandoun entorno disciplinado para la toma preactiva de decisiones alo largo de todas las fases del proyecto: análisis de los problemas en potencia (riesgos), determinación de los riesgosimportantes para elaborar estrategias y planes paragestionarlos. Estos riesgos son controlados hasta que seresuelven o se convierten en problemas menores, y sontratados como tales. En la Tabla 1 podemos ver las funcionestípicas de gestión del riesgo que tiene el SEI-CRM peroademás este método también incluye el concepto de gestionar 
 
3
estas actividades como un ciclo básico, es decir, identificar,analizar, planificar, seguir, controlar y comunicar los riesgos alo largo de todo el ciclo de vida del proyecto.
C. Definición del Plan de Gestión de Riesgos de PRISMA
 Nuestra primera tarea fue crear el plan de gestión del riesgodel proyecto PRISMA. Aunque el SEI-CRM no incluyeespecíficamente una fase o actividad para el desarrollo de este plan, nosotros decidimos extender el SEI-CRM con la fase dedefinición del plan de gestión del riesgo del modelo del PMI,cuyo objetivo es el de garantizar que los riesgos del proyectosean identificados, analizados, documentados, mitigados ycontrolados correctamente durante todo el ciclo de vida del proyecto. Este documento incluye los procesos, métodos,responsabilidades y recursos utilizado para administrar losriesgos de PRISMA y sigue las recomendaciones del SEI SW-CMM y del PMI.
 D. Definición del equipo de Gestión de Riesgos
La Figura 1 muestra las responsabilidades para gestionar los riesgos de todo el personal del proyecto, incluyendo el jefedel proyecto, los responsables de las diferentes áreas, losmiembros del equipo PRISMA y el equipo completo degestión del riesgo.
Jefe delproyecto
 
Responsablesde áreaTodo elequipoPRISMA
Controlar 
 
•
 
Revisar 
 
•
 
Repriorizar 
 
•
 
Integración delos equipos
Analizar 
 
•
 
Revisar 
 
•
 
Priorizar 
 
•
 
Evaluar •
 
Clasificar 
 
Plan
 
•
 
aprobar planes
 
•
 
Recomendar planes
Identificar 
 
Seguimiento
 
 
RiesgosRiesgosimportantes Asignar responsabilidad 
 
Indicadores
 
Estado
 
Área de Calidad
 
Equipo deAyuda a laGestión delRiesgo
Transferir riesgo
Fig. 1. Diferentes roles en el proceso de gestión del riesgo.
A continuación se enumeran los roles principales y lasresponsabilidades para cada rol:-
 
Todo el equipo PRISMA: identificar nuevos riesgos,estimar su probabilidad e impacto, clasificar,recomendar acciones, seguimiento de los riesgos y desus planes de acción, y ayudar a priorizar los riesgos.-
 
Responsables de área: integrar información de todoslos riesgos de los miembros de su área, asegurar  precisión de las estimaciones de la probabilidad, delimpacto y la clasificación., reconsiderar la prioridadde todos los riesgos para determinar los riesgos másimportantes, revisar recomendaciones para lasacciones de mitigación, asignar y cambiar responsabilidades de los riesgos y sus planes demitigación, implementar decisiones de control sobrelos riesgos, construir planes de acción, recoger einformar sobre medidas del riesgo, e informar  periódicamente al jefe del proyecto de la situación delos riesgos.-
 
Jefe del proyecto: autorizar recursos para lamitigación, integrar información de todos losresponsables de área sobre los riesgos, revisar la prioridad de todos los riesgos para determinar cuálesson los riesgos importantes, tomar decisiones decontrol sobre estos riesgos, asignar y cambiar responsabilidades de los riesgos y sus planes demitigación dentro del proyecto, revisando las métricas periódicamente y conjuntamente con el área decalidad para evaluar la efectividad de la gestión delriesgo.-
 
Equipo interno de gestión del riesgo (Área deCalidad): coordinar actividades para identificar yanalizar riesgos, mantener la lista de los riesgos del proyecto, notificar nuevos riesgos e informar  periódicamente sobre el estado de los riesgos al jefedel proyecto. Estimar periódicamente las métricas delos riesgos para evaluar conjuntamente con el jefe del proyecto.-
 
Equipo de soporte a la gestión del riesgo (asesoresexternos): detectar elementos de riesgo y estimar suimpacto potencial negativo, revisar y evaluar procesoscríticos y áreas dentro del proyecto, revisar e importar resultados relevantes de proyectos internos similares oexternos, construir políticas y planes de contingencia,y evaluar y ayudar al jefe del proyecto en actividadesde criticidad elevada.IV. I
MPLEMENTACIÓN DEL
SEI-CRM
EN
PRISMA
 
 A. Fase de Identificación de Riesgos
La fase de identificación de riesgos consiste en descubrir factores de riesgo antes de que estos lleguen a ser problemas yderiven en daños o pérdidas. En la figura 2 se puede ver el proceso de identificación de riesgos que se siguió enPRISMA, que se dividió en dos fases: identificación de la listainicial de los riesgos del proyecto y proceso de identificacióny evaluación continua de los riesgos.
1) Identificación de la lista inicial de riesgos del proyecto
Para esta actividad, el equipo de gestión del riesgoconstruyó un cuestionario de identificación de riesgos basadoen la taxonomía de riesgos del SEI. Esta taxonomía proporciona un marco para identificar riesgos técnicos y del proceso utilizado para el desarrollo del software [12] yconsiste en 194 preguntas clasificadas en tres grandes clases:ingeniería del producto, entorno del desarrollo y restriccionesdel programa.
Search
Search History:
Searching...
Result 00 of 00
00 results for result for
  • p.
    • Notes
    Load more