PROPUESTA DE DIRECTRICES PARA EL PROCESO GESTIÓN DE RIESGOS PARA UN MODELO
DE CALIDAD EN CUBA
PROPOSED GUIDELINES FOR THE MANAGEMENT RISK PROCESS FOR A QUALITY MODEL IN
CUBA
Luz María Gutiérrez Feria1*
1Universidad de las Ciencias Informáticas (UCI), Carretera San Antonio de
los Baños Km. 2 ½, Torrens, La Lisa, La Habana, Cuba. Teléfono (537)
8372427
*Autor para la correspondencia:
[email protected], 5-8053450
La Habana, febrero 2014
Resumen
Teniendo en cuenta que el desarrollo de software en Cuba está dado
principalmente por pequeñas y medianas empresas, resulta muy difícil para
ellas adoptar un modelo de calidad reconocido debido a que los requisitos
mínimos que exigen están muy por encima de sus posibilidades y
disposiciones. Independientemente de la conciencia que tienen las empresas
desarrolladoras cubanas de la necesidad de adoptar un modelo orientado a
alcanzar la calidad de sus productos, no han podido dedicar tiempo y
esfuerzo a adaptar un modelo a sus características. De ahí que exista la
necesidad de definir un modelo de calidad que se adecue a las necesidades y
particularidades de las empresas cubanas de desarrollo de software pequeñas
y medianas. Este modelo está compuesto por varios procesos base, entre
ellos el de Gestión de Riesgos, y propone directrices para cada uno. En el
presente artículo se identifican las actividades de los modelos de calidad
internacionalmente reconocidos que son compatibles con las directrices
propuestas para el Proceso Base Gestión de Riesgos y se congregan en una
tabla comparativa. A partir de este mapeo se ratifican o modifican las
directrices propuestas por el Modelo de Calidad para el Desarrollo de
Aplicaciones Informáticas, proponiendo en adición, su ubicación según los
niveles de madurez que propone.
Palabras Clave: directrices, gestión de riesgos, modelo de calidad
Abstract
GIVEN THAT SOFTWARE DEVELOPMENT IN CUBA IS MAINLY COMPOSED OF SMALL AND
MEDIUM ENTERPRISES, IT IS VERY DIFFICULT FOR THEM TO ADOPT A RECOGNIZED
QUALITY MODEL BECAUSE THE MINIMUM REQUIREMENTS THAT REQUIRE WELL ABOVE
THEIR MEANS AND PROVISIONS. REGARDLESS OF CONSCIOUSNESS WITH CUBAN
DEVELOPMENT COMPANIES NEED TO ADOPT A MODEL AIMED TO REACH THE QUALITY OF
THEIR PRODUCTS, THEY HAVE NOT BEEN ABLE TO DEVOTE TIME AND EFFORT TO ADAPT
A MODEL TO ITS CHARACTERISTICS. HENCE, DEFINING A QUALITY MODEL THAT FITS
THE NEEDS AND PARTICULARITIES OF CUBAN COMPANIES SOFTWARE DEVELOPMENT. THIS
MODEL IS COMPOSED OF SEVERAL BASE PROCESSES, INCLUDING RISK MANAGEMENT, AND
PROPOSES GUIDELINES FOR EACH BASE PROCESS TO BE DEFINED. IT IDENTIFIES THE
ACTIVITIES OF INTERNATIONALLY RECOGNIZED QUALITY MODELS THAT ARE COMPATIBLE
WITH THE PROPOSED GUIDELINES AND CONGREGATE IN A COMPARATIVE TABLE. FROM
THIS MAPPING WILL CONFIRM OR MODIFY THE GUIDELINES PROPOSED BY THE QUALITY
MODEL FOR APPLICATION DEVELOPMENT, PROPOSING IN ADDITION, ITS LOCATION AS
MATURITY LEVELS PROPOSED.
KeyWords: risk management, guidelines, quality model
1. INTRODUCCIÓN
Adoptar un modelo de calidad internacionalmente reconocido para el
desarrollo de software conlleva una serie de inversiones por parte de la
empresa interesada. Principalmente se invierte en las actividades para
alcanzar o lograr cumplir con los requisitos que exigen los modelos, y en
los costes de certificación que requieren las empresas certificadoras. Aún
así las organizaciones están conscientes que la calidad lejos de ser un
gasto es una inversión que apunta a la efectividad de los productos que
desarrollan. La calidad en el desarrollo evita la aparición de errores en
etapas avanzadas de la elaboración del producto de software o después de
entregado al cliente. Estas deficiencias son más costosas de componer en
esos momentos. Si de otra manera se logara establecer la calidad del
producto desde los procesos por los que se desarrolla, la aparición de
deficiencias o errores sería menor y controlable.
Las empresas desarrolladoras de software cubanas están conscientes de las
ventajas que conlleva la adopción de un modelo de calidad. Sin embargo al
ser en su mayoría pequeñas y medianas empresas (de menos de 200
trabajadores), la inversión que se necesita hacer constituye un esfuerzo
mayor, sobre todo por el trabajo que se debe dedicar a alcanzar los
requisitos que estos modelos y normas exigen, ya que están fuera del
alcance de una pequeña o mediana empresa por su complejidad y amplitud.
Esta situación no está presente solo en Cuba. Otros países de Latinoamérica
han definido modelos de calidad adecuados a las necesidades y
características de sus pequeñas y medianas empresas. Estos modelos están
basados en normas y modelos reconocidos internacionalmente de forma tal que
se cumplan con sus requisitos al mismo tiempo que se simplifican. Las
experiencias de estos modelos latinoamericanos sirven como impulso a Cuba
para desarrollar su propio modelo de calidad.
La gestión riesgos durante el proceso de desarrollo del software en las
empresas cubanas, también se ve afectada por la falta de un modelo que se
adapte a las condiciones de las pequeñas y medianas empresas en Cuba, a
pesar de que en algunas entidades se hayan tomado medidas para llevar a
cabo su gestión. Un modelo de calidad cubano, actualmente en proceso de
definición, incluye, entre otras disciplinas la gestión de riesgos.
2. CONTENIDO
1. Modelo de calidad para el desarrollo de aplicaciones informáticas
Teniendo como base los modelos internacionalmente reconocidos y las
experiencias latinoamericanas, se propone un modelo de calidad que se
ajuste a las características de las pequeñas y medianas empresas cubanas.
Este modelo lleva el nombre de Modelo de Calidad para el Desarrollo de
Aplicaciones Informáticas (MCDAI).
El MCDAI tiene como objetivo proporcionar a la industria cubana del
software un modelo basado en las mejores prácticas internacionales
pero teniendo en cuenta las regulaciones nacionales y que además sea
fácil de entender, fácil de aplicar y sirva de base para alcanzar
evaluaciones en otros modelos. El modelo está dirigido a las empresas
o áreas internas dedicadas al desarrollo y/o mantenimiento de
software. Las organizaciones que no cuenten con procesos
establecidos pueden usar el modelo ajustándolo de acuerdo a sus
necesidades, mientras que las que ya tienen procesos establecidos
pueden usarlo como punto de referencia para identificar los elementos
que les hace falta cubrir (Montalván and Tardío 2013).
Para la evaluación de la capacidad o nivel de implementación del
modelo, se definen tres niveles de madurez: Básico, Avanzado y
Eficiente. Para alcanzar cada nivel se deben cumplir una serie de
requisitos o desarrollar una serie de actividades que incluyen las
requeridas en el nivel anterior a él.
El modelo cuenta con una serie de procesos que están organizados en
las áreas de aplicación: Gestión de procesos de la organización,
Ingeniería, Soporte y Gestión de proyecto. Dentro del área Gestión
de proyecto se encuentra ubicado el Proceso Base Gestión de
Riesgos. Para este proceso se proponen las directrices:
Determinar las fuentes y las categorías de los riesgos.
Definir los parámetros de los riesgos.
Establecer una estrategia de gestión de riesgos.
Identificar riesgos.
Evaluar, categorizar y priorizar los riesgos.
Desarrollar e Implementar los planes de mitigación de riesgo.
2. Mapeo de las directrices propuestas con los modelos y normas
existentes
Con el objetivo de validar las directrices propuestas para el Proceso Base
de Gestión de Riesgos se realiza un estudio que refleje las actividades de
algunos modelos y normas que son interesantes para la definición del MCDAI.
Algunos de estos son reconocidos internacionalmente mientras que otros son
regulaciones y disposiciones cubanas para el funcionamiento empresarial. La
incorporación de las prácticas cubanas asegura que las directrices sean
compatibles con las necesidades y regulaciones políticas y económicas del
país.
1 Capability Maturity Model Integration
CMMI (por sus siglas en inglés Capability Maturity Model Integration) es un
modelo de mejora para el desarrollo de productos de software que valora la
madurez del proceso de desarrollo mismo. Cubre el ciclo de vida del
desarrollo del software incluyendo las mejores prácticas para las
actividades de desarrollo. CMMI persigue como objetivo ayudar a las
organizaciones a mejorar sus procesos de desarrollo y mantenimiento de
software. Incluye actividades que cubren la gestión de proyectos, la
ingeniería de sistemas, la gestión de procesos, la ingeniería de software,
la ingeniería de hardware y otras prestezas de soporte y mantenimiento
llevadas a cabo en el desarrollo de un producto de software(Team 2006).
CMMI tiene 22 áreas de proceso que en la representación escalonada están
agrupadas los en niveles de madurez. Cada área de proceso contiene las
prácticas que permiten que las organizaciones mejoren la misma. Un área de
proceso está compuesta, entre otras especificaciones, por objetivos
específicos y prácticas específicas, las que describen las actividades
propias del área.
El área de proceso Gestión de Riesgos pertenece al nivel de madurez
Definido del modelo y tiene como propósito identificar problemas
potenciales antes de que ocurran, para que las actividades de tratamiento
de riesgos puedan planificarse e invocarse según sea necesario a lo largo
de la vida del producto o del proyecto para mitigar los impactos adversos
sobre la consecución de objetivos (Team 2006).
El área Gestión de Riesgos del modelo CMMI contiene las siguientes metas
específicas (SG) y prácticas específicas (SP):
SG1. Preparar la gestión de riesgos.
SP1.1determinar las fuentes y las categorías de riesgos.
SP1.2definir los parámetros de riesgos.
SP1.3establecer una estrategia de gestión de riesgos.
SG2 Identificar y analizar los riesgos.
SP2.1 Identificar los riesgos.
SP2.2evaluar, clasificar y priorizar los riesgos.
SG3 Mitigar los riesgos.
SP3.1desarrollar los planes de mitigación de riesgos.
SP3.2 Implementar los planes de mitigación de riesgos.
2 ISO/IEC 15504
La norma ISO/IEC 15504 es un estándar internacional que provee un marco de
evaluación a procesos de software. Incluye prácticas para la planeación,
gestión, desarrollo, mantenimiento, soporte, evolución del software entre
otras. Incluye una arquitectura para evaluar las prácticas y los procesos
de software y para presentar los resultados de dicha evaluación. Tiene como
objetivo permitir a las organizaciones comprender: el estado de sus
procesos para la mejora de procesos, la idoneidad de sus procesos según un
criterio o una serie de estos, la idoneidad de los procesos de otra
organización a fin de conocer su estado(ISO/IEC 1995).
El marco de evaluación a procesos de la ISO/IEC 15504 evalúa instancias
específicas del proceso de desarrollo del software. Cada instancia de
proceso puede caracterizada por una serie de cinco (5) niveles de
capacidad, donde cada uno comprende las determinaciones de los niveles
anteriores a él. Estos niveles de capacidad son: (0) Incompleto, (1)
Realizado, (2) Gestionado, (3) Establecido, (4) Predecible, (5) En
Optimización.
La Idoneidad Demostrada es una calificación que indica que una instancia de
proceso cumple con los aspectos evaluativos que le fueron definidos. A
partir de las calificaciones de las instancias de procesos se pueden
derivar otras calificaciones que provean mejor entendimiento sobre la
capacidad de los procesos dentro de una organización. El marco de
evaluación de la norma está estructurado de forma que enuncia las
actividades que se necesitan cumplir en el desarrollo de software sin
especificar cómo ejecutarlas. Cada proceso esta descrito en prácticas base
que son específicas de cada proceso, capacidad, características comunes y
prácticas genéricas, donde estas últimas son aplicables a todos los
procesos. Esto ayuda a describir como los procesos son gestionados con
respecto a los propósitos definidos. La práctica genérica 6 Administrar los
riesgos relaciona todos los procesos con las actividades relacionadas a la
Gestión de riesgos, de esta manera este proceso se coloca transversalmente
al desarrollo del software.
Los procesos se agrupan en cinco (5) categorías: Cliente-Proveedor,
Ingeniería, Proyecto, Soporte y Organización. El proceso Gestión de Riesgos
se encuentra dentro de la categoría Proyecto y tiene como propósito
identificar y mitigar continuamente los riesgos en un proyecto a lo largo
de todo el ciclo de vida del proyecto. Para cumplir con dicho objetivo el
proceso Gestión de la Configuración en la ISO/IEC 15504 define las
siguientes prácticas base:
PRO.6 Administrar los riesgos
PRO.6.1 Establecer el alcance de los riesgos
PRO.6.2 Identificar los riesgos
PRO.6.3 Analizar y priorizar los riesgos
PRO.6.4 Desarrollar estrategias de mitigación
PRO.6.5 Definir las métricas de riesgo
PRO.6.6 Implementar estrategias de mitigación
PRO.6.7 Evaluar los resultados de las estrategias de mitigación
PRO.6.8 Tomar acción correctiva
3 MPS-BR
MPS-BR (Mejora de Procesos de Software - Brasil) es un programa para la
mejora de procesos de software en Brasil que presta especial atención a las
Pequeñas y Medias Empresas (PyMEs) aunque está pensado que sea adecuada
para empresas de cualquier tamaño. Este programa pretende ser compatible
con los estándares de calidad de software internacionalmente reconocidos de
forma que se aprovechen las mejores prácticas de los modelos que ya
existen. Uno de sus objetivos es definir y perfeccionar un modelo de mejora
y evaluación de proceso de software, dando preferencia a las micro,
pequeñas y medianas empresas, de modo que atiendan sus necesidades de
negocio y que sea reconocido nacional e internacionalmente como un modelo
aplicable a la industria de software (BR 2011).
Este modelo se basa en la capacidad y madurez para la evaluación de los
procesos de software, la mejora de la calidad y productividad de productos
y servicios de software. Para ello se establece un modelo de procesos de
software y un método de evaluación a procesos que garantice que el modelo
se implementa según fue definido. Este modelo está basado en las normas
ISO/IEC 12207:2008 e ISO/IEC 15504-2, adecuando sus características a las
peculiaridades de la comunidad de interés. Fue además definido en
correspondencia con el modelo CMMI-Dev. Estas normas y modelos son
utilizadas tanto para su modelo de referencia, su modelo de evaluación como
para el modelo de negocio de MPS-BR (Br 2011).
El MR-MPS define siete niveles de madurez: A (En Optimización), B
(Gestionado Cuantitativamente), C (Definido), D (Ampliamente Definido), E
(Parcialmente Definido), F (Gestionado) y G (Parcialmente Gestionado),
siendo el nivel G el más bajo y el A el más alto. La división en 7
escalones tiene el objetivo de posibilitar una implementación y evaluación
apropiada para las micro, pequeñas y medianas empresas. La posibilidad de
realizar evaluaciones considerando más niveles también permite una
visibilidad de los resultados de mejora de procesos en plazos más cortos
(Br 2011).
El proceso Gestión de Riesgos se desarrolla cuando se pretende alcanzar el
nivel de madurez Definido (C). Tiene como objetivo identificar, analizar,
tratar, supervisar y reducir continuamente los riesgos a nivel
organizacional y de proyecto.
Tiene como resultados esperados (BR 2011):
GRI1 - El alcance de la gestión de riesgos es determinado.
GRI2 - Los orígenes y las categorías de riesgos son determinados, y los
parámetros usados para analizar riesgos, categorizarlos y controlar el
esfuerzo de la gestión de riesgos son definidos.
GRI3 - Las estrategias apropiadas para la gestión de riesgos son
definidas e implementadas.
GRI4 - Los riesgos del proyecto son identificados y documentados incluyendo
su contexto, condiciones y posibles consecuencias para el proyecto y las
partes interesadas.
GRI5 - Los riesgos son priorizados, estimados y clasificados de acuerdo
con las categorías y los parámetros definidos.
GRI6 - Planes para la mitigación de riesgos son desarrollados
GRI7 - Los riesgos son analizados y la prioridad de aplicación de los
recursos para la supervisión de esos riesgos es determinada.
GRI8 - Los riesgos son evaluados y supervisados para determinar cambios en
su situación y en el progreso de las actividades para su tratamiento
GRI9 - Acciones apropiadas son llevadas a cabo para corregir o evitar el
impacto del riesgo, basadas en su prioridad, probabilidad, consecuencia u
otros parámetros definidos.
4 MoProSoft
El Modelo de Procesos para la Industria de Software de México intenta
fomentar la estandarización de la industria mediante la inclusión de buenas
prácticas en los procesos de ingeniería y gestión de software. La adopción
del modelo permitirá a las empresas desarrollar un nivel de capacidad que
les beneficie en la adquisición de calidad del producto que se brinde, y en
el alcance internacional de su competitividad.
MoProSoft está pensado para PyMEs, obteniendo las mejores prácticas de los
modelos internacionales ISO 9000:2000, CMMI, ISO 15504, PMBOK, SWEBOK, u
otros, y al igual que sus modelos base, está enfocado a procesos, aunque
permite su aplicación en empresas que no tiene procesos definidos o
documentados. La estructura del modelo está diseñada de forma que se alinee
con la estructura básica de las empresas: Alta Dirección, Gerencia y
Operación. La Alta Gerencia tiene participación protagónica en la
planificación estratégica, su revisión y su mejora como entidad
organizadora por excelencia. La Gerencia debe ser vista como proveedora de
recursos, procesos y proyectos. Es responsable además de velar por el
cumplimiento de los objetivos estratégicos. Las actividades que realiza se
basan en los lineamientos establecidos por la Alta Dirección. La Operación
por su parte, es encargada de ejecutar los proyectos de desarrollo y
mantenimiento de software basándose en los elementos dados por la Gerencia
(Team).
La Gestión de riesgos dentro del modelo se lleva de manera transversal a
todos procesos que llevan, y ese desarrollo de actividades tiene como
propósito fundamental establecer y llevar a cabo sistemáticamente las
actividades que permitan cumplir con los objetivos de un proyecto en tiempo
y costo esperados. Dichas actividades se relacionan a continuación:
Identificar y evaluar los riegos en cada proceso.
Definir un plan de contención de riesgos.
Definir un plan de contingencia.
Identificar las Lecciones Aprendidas e integrarlas a la Base de
Conocimiento.
Supervisión y control de los riesgos identificados
5 CompetiSoft
El proyecto de Mejora de Procesos para fomentar la competitividad de la
pequeña y mediana industria del software de Iberoamérica se basa en: la
norma mexicana (MoProSoft, EvalProSoft), el Sistema Integral para la Mejora
de los Procesos Software en Colombia-SIMEP-SW (Agile SPI), la metodología
española Métrica v3, La metodología Mantema y en los diferentes entregables
que los miembros de COMPETISOFT han elaborado durante el primer año del
proyecto. CompetiSoft está concebido para convertirse en un referente para
todas las PyMES dedicadas al sector informático de Iberoamérica. Tiene como
objetivo general incrementar el nivel de competitividad de las PyMES
Iberoamericanas productoras de software mediante la creación y difusión de
un marco metodológico común que, ajustado a sus necesidades específicas,
pueda llegar a ser la base sobre la que establecer un mecanismo de
evaluación y certificación de la industria del software reconocido en toda
Iberoamérica. Se propone además ser la base para la certificación en normas
mundialmente reconocidas como ISO 9000:2000 o CMMI. Este modelo está
dirigido a las empresas dedicadas al desarrollo y/o mantenimiento de
software (Oktaba, García et al. 2007).
El modelo está enfocado en procesos y considera los tres niveles básicos de
la estructura de una organización que son: la Alta Dirección, Gestión y
Operación. El modelo pretende apoyar a las organizaciones en la
estandarización de sus prácticas, en la evaluación de su efectividad y en
la integración de la mejora continua (Oktaba, García et al. 2007).
El modelo de procesos de CompetiSoft está basado en lo que se define en
MoProSoft, por lo que tiene tres categorías de procesos: Alta Dirección,
Gerencia y Operación que reflejan la estructura de una organización.
Como consecuencia de este basamento del modelo de procesos muchos de los
procesos descritos son similares a los de MoProSoft, aunque se evidencian
diferencias en algunos procesos. Ejemplo de esto es el proceso Desarrollo
de Software (similar al proceso Desarrollo y Mantenimiento de Software de
MoProSoft) en el que las actividades se integración y pruebas, unidas en
MoProSoft, se separan en CompetiSoft. Además se adicionan nuevas
actividades y se desglosan otras.
6 Resolución No. 60/11 Normas del Sistema de Control Interno
La Resolución 60/11 fue emitida por la Contraloría General de la República
de Cuba con el fin de seguir perfeccionando el sistema de control interno.
Esta norma está basada en las disposiciones de las actividades del control
interno y en los requerimientos del desarrollo económico-administrativo del
país.
Constituye un modelo estándar del Sistema de Control Interno y tiene por
objetivo establecer normas y principios básicos de obligado acatamiento
para la Contraloría General de la República y los sujetos a las acciones de
auditoría, supervisión y control. El control interno es el proceso
integrado a las operaciones con un enfoque de mejoramiento continuo,
extendido a todas las actividades inherentes a la gestión, efectuado por la
dirección y el resto del personal; se implementa mediante un sistema
integrado de normas y procedimientos, que contribuyen a prever y limitar
los riesgos internos y externos, proporciona una seguridad razonable al
logro de los objetivos institucionales y una adecuada rendición de cuentas
(2011).
La norma no está directamente relacionada con las empresas desarrolladoras
de software sino que plantea los requisitos que debe cumplir toda empresa
estatal cubana. De ahí que se tenga como referencia para que lo definido en
la propuesta de proceso base Gestión de Riesgos no sea incongruente con lo
establecido en la resolución. Como consecuencia de no ser una norma
definida para las empresas desarrolladoras de software no se contemplan
actividades típicas de los procesos de desarrollo, ni existen niveles de
madurez ni de implementación como en las normas anteriores. Se muestran a
continuación los artículos que son consonantes con las actividades para
establecer y mantener la documentación y legado de la empresa:
DE LOS COMPONENTES Y NORMAS DE CARACTER GENERAL
ARTÍCULO 9.-El Sistema de Control Interno está formado por cinco
componentes interrelacionados entre sí, en el marco de los principios
básicos y las características generales; estos son los siguientes: Ambiente
de Control, Gestión y Prevención de Riesgos, Actividades de Control,
Información y Comunicación y Supervisión y Monitoreo, los que se encuentran
estructurados en normas.
ARTÍCULO 11.-El componente Gestión y Prevención de Riesgos establece las
bases para la identificación y análisis de los riesgos que enfrentan los
órganos, organismos, organizaciones y demás entidades para alcanzar sus
objetivos. Una vez clasificados los riesgos en internos y externos, por
procesos, actividades y operaciones, y evaluadas las principales
vulnerabilidades, se determinan los objetivos de control y se conforma el
Plan de Prevención de Riesgos para definir el modo en que habrán de
gestionarse. Existen riesgos que están regulados por disposiciones legales
de los organismos rectores, los que se gestionan según los modelos de
administración pre-vistos. El componente se estructura en las siguientes
normas:
a) identificación de riesgos y detección del cambio
b) determinación de los objetivos de control
Los objetivos de control son el resultado o propósito que se desea
alcanzar con la aplicación de procedimientos de control, los que deben
verificar los riesgos identificados y estar en función de la política
y estrategia de la organización. Luego de identificar, evaluar y
cuantificar, siempre que sea posible, los riesgos por procesos,
actividades y operaciones, la máxima dirección y demás directivos de
las áreas, con la participación de los trabajadores, realizan un
diagnóstico y determinan los objetivos de control, dejando evidencia
documental del proceso.
El diagnóstico se realiza en reuniones por colectivos de áreas,
direcciones o departamentos según corresponda, las cuales son
presididas por la máxima autoridad del lugar, el dirigente sindical y
los representantes de las organizaciones políticas; debe estar
presente al menos uno de los integrantes del grupo que realizó la
identificación y análisis de riesgos a nivel dela organización, con la
información y antecedentes específicos del área. En estas reuniones se
realiza entre todos un diagnóstico con los objetivos de control a
considerar y se definen las medidas o procedimientos de control a
aplicar, las mismas serán antecedidas de un trabajo de información y
preparación de los trabajadores en asamblea de afiliados donde se les
explica el procedimiento a seguir para su desarrollo.
c) prevención de riesgos
7 Guía de los Fundamentos de la Dirección de Proyectos (PMBOK)
PMBOK es una guía cuya finalidad principal es identificar el subconjunto de
Fundamentos de la Dirección de Proyectos generalmente reconocido como
buenas prácticas. Cubre el ciclo de vida del desarrollo del software
centrándose en la dirección de proyectos basado en áreas del conocimiento.
Dentro de dichas áreas está la Gestión de Riesgos del Proyecto que incluye
los procesos relacionados con la planificación de la gestión de riesgos, la
identificación y el análisis de riesgos, las respuestas a los riesgos, y el
seguimiento y control de riesgos de un proyecto, por lo que tiene como
objetivo fundamental aumentar la probabilidad y el impacto de los eventos
positivos, y disminuir la probabilidad y el impacto de los eventos adversos
para el proyecto. Los procesos de Gestión de los Riesgos del Proyecto
incluyen lo siguiente:
11.1 Planificación de la Gestión de Riesgos: decidir cómo enfocar,
planificar y ejecutar las actividades de gestión de riesgos para un
proyecto.
11.2 Identificación de Riesgos: determinar qué riesgos pueden afectar al
proyecto y documentar sus características.
11.3 Análisis Cualitativo de Riesgos: priorizar los riesgos para realizar
otros análisis o acciones posteriores, evaluando y combinando su
probabilidad de ocurrencia y su impacto.
11.4 Análisis Cuantitativo de Riesgos: analizar numéricamente el efecto de
los riesgos identificados en los objetivos generales del proyecto.
11.5 Planificación de la Respuesta a los Riesgos: desarrollar opciones y
acciones para mejorar las oportunidades y reducir las amenazas a los
objetivos del proyecto.
11.6 Seguimiento y Control de Riesgos: realizar el seguimiento delos
riesgos identificados, supervisar los riesgos residuales, identificar
nuevos riesgos, ejecutar planes de respuesta a los riesgos y evaluar su
efectividad a lo largo del ciclo de vida del proyecto.
3. Tabla comparativa
A partir de los modelos y normas estudiadas, y las directrices propuestas
para el Proceso Base Gestión de la Configuración se realiza una comparación
que valide dichas directrices. Esto garantizaría la completitud del proceso
y su compatibilidad con las normas y modelos reconocidos en los que se
basa.
Tabla 1 Traceo de directrices propuestas por el MCDAI con los modelos,
normas y estándares estudiados.
Directrices / Modelos CMMI 1.3 ISO 15504 MPS - BS MoProSoft CompetiSoft Resolución No. 60/11 PMBOK Identificar los riesgos SP 1.1
SP 1.2
SP 2.1 PRO.6.2 GRI2
GRI4 RGP A1.6 RGP A1.6 Art.11 a) 11.2 Evaluar y priorizar los riesgos SP2.2 PRO.6.3 GRI5
GRI7
GRI8 11.3
11.4 Desarrollar e implementar planes de mitigación y/o contingencia SP 3.1
SP 3.2 PRO.6.4
PRO.6.6 GRI6 RGP A1.6 RGP A1.6 Art. 11 c) 11.5 Revisar y monitorear el proceso Proceso de Monitoreo y Control de Proyecto (PMC) PRO.6.7
PRO.6.8
GRI9 GES. 1 Gestión de Procesos GES. 1 Gestión de Procesos 11.6 Establecer una estrategia para la gestión de riesgos SP 1.3 PRO.6.1 GRI1
GRI3 Art. 11 b) 11.1 Gestionar indicadores y lecciones aprendidas PRO.6.5 RGP A3.16 RGP A3.16
Propuesta de directrices para el proceso base Gestión de Riesgos
Teniendo en cuenta los modelos presentados y la tabla comparativa que se muestra, se plantea una modificación en las directrices. Se proponen como subdirectrices de Identificar riesgos las directrices Determinar las fuentes y las categorías de los riesgos y Definir los parámetros de los riesgos, además de agregar otras que garantizarán la calidad del proceso. Estos cambios se fundamentan en que los modelos plantean que para una identificación eficiente de los riesgos, como esto constituye una tarea engorrosa para los inexpertos se realicen las actividades previamente relacionadas a las subdirectrices propuestas de manera que la identificación y la determinación de sus parámetros sea determinada con mayor exactitud. Por lo tanto las directrices que se proponen para el Proceso Base Gestión de la Configuración organizadas por niveles de madurez son:
Nivel: Básico
Identificar los riesgos.
1.1 Determinar fuentes y categorías de los riegos.
1.2 Definir los parámetros de los riesgos
Evaluar y priorizar los riesgos.
Desarrollar e implementar planes de mitigación y/o contingencia.
Revisar y monitorear el proceso.
Nivel: Intermedio
Establecer una estrategia para la gestión de riesgos.
Gestionar indicadores y lecciones aprendidas.
CONCLUSIONES
A partir de la investigación presentada se concluye que las directrices propuestas por (Montalván and Tardío 2013) son compatibles con las actividades que proponen los modelos y normas estudiados, así como con la Resolución 60/11. Teniendo en cuenta el mapeo realizado se propone la modificación de una de las directrices y la adición de otras de manera que se garantice la calidad del proceso y una mejor determinación de los riegos en un proyecto u organización. Se propone además como resultado del mapeo la ubicación de las directrices finales en los niveles de madurez del MCDAI.
REFERENCIAS BIBLIOGRÁFICAS
Anaya, R., Henao, M., Cechich, A., & Oktaba, H. (2007). Software process improvement: The COMPETISOFT project. 506PI0287- COMPETISOFT.
Br. M. (2011). "Associação para Promoção da Excelência do Software Brasileiro–SOFTEX" MPS.BR–Guia de Implementación–Parte 5. Brazil.
Br. M. (2011). "Melhoria de Processo do Software Brasileiro." Guía General 1. Brazil.
Contraloría General de la República Gaceta Oficial No. 013. (2011). Normas del Sitema de Control Interno Resolución No. 60/11. La Habana.
Equipo del Producto CMMI. (2010). CMMI-DEV, V1.3. CMU/SEI-2010-TR-033.
ISO/IEC. (1995). 15504 Software Process Assessment. Concepts and Introductory Guide.
Pérez Montalván, D., & Tardío, M. (s.f.). PROPUESTA DE ESTRUCTURA PARA UN MODELO CUBANO DE DESARROLLO DE APLI-CACIONES INFORMÁTICAS. VI Taller de Calidad en las Tecnologías de la Información y las Comunicaciones.
Software Industry Process Model. (Agosto de 2006). MoPRoSoft: Modelo de Proceso para la Industria del Software, v1.3.2. Obtenido de http://www. comunidadmoprosoft.org.mx
-----------------------
12
