MPS.BR - Mejora de Proceso del Software Brasileño. Guía de Implementación Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS

(1)

MPS.BR - Mejora de Proceso del Software Brasileño

Guía de Implementación – Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS

Esta guía contiene orientaciones para la implementación del nivel C del Modelo de Referencia MR-MPS.

VIGENCIA Y TRANSICIÓN: La Guía General:2011 entra en vigor el 30 de junio de 2011. Así, a partir de esta fecha pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Sin embargo, queda definido un período de transición, de 30 de junio a 31 de diciembre de 2011, durante el cual pueden ser realizadas evaluaciones MPS usando el modelo de referencia MR-MPS:2011 o la versión anterior MR-MPS:2009. A partir del 1º de enero de 2012 solo serán válidas evaluaciones MPS usando el modelo de referencia MR-MPS:2011. Las implementaciones a ser realizadas utilizando esta Guía de Implementación deberán llevar en cuenta estas vigencias.

Julio de 2011

Derechos de esta edición reservados por la Sociedad SOFTEX La distribución ilimitada de este documento está sujeta a copyright ISBN 978-85-99334-71-3

(2)

Índice

1 Prefacio ... 3

2 Introducción ... 5

3 Objetivo ... 6

4 Evolucionando del nivel D al nivel C ... 6

5 Desarrollo para Reutilización (DRU) ... 6

5.1 Propósito ... 6

5.2 Fundamentación teórica ... 9

5.3 Resultados esperados ... 11

6 Gestión de Decisiones (GDE) ... 16

7 Gestión de Riesgos (GRI) ... 22

8 Los atributos de proceso del nivel C ... 30

Referencias bibliográficas... 31

Lista de colaboradores de la Guía de Implementación – Parte 5:2011 ... 34

Lista de colaboradores de la Guía de Implementación – Parte 5:2009 ... 35

Lista de colaboradores de la Guía de Implementación – Parte 5 versión 1.1 - Julio/2007 ... 36

Lista de colaboradores de la Guía de Implementación – Parte 5 versión 1.0 - Diciembre/2006 ... 37

(3)

1 Prefacio

El MPS.BR¹ es un programa movilizador, de largo plazo, creado en diciembre de 2003, es coordinado por la Asociación para Promoción de la Excelencia del Software Brasileño (SOFTEX), y cuenta con el apoyo del Ministerio de Ciencia y Tecnología (MCT), de la Financiera de Estudios y Proyectos (FINEP), del Servicio Brasileño de Apoyo a las Micro y Pequeñas Empresas (SEBRAE) y del Banco Interamericano de Desarrollo (BID).

El objetivo del programa MPS.BR (acrónimo) es la Mejora de Proceso del Software, para lograr dos metas a mediano y largo plazo:

a) meta técnica, teniendo como objetivo la creación y perfeccionamiento del modelo MPS, con resultados esperados tales como: (i) guías del modelo MPS; (ii) Instituciones Implementadoras (II) acreditadas para prestar servicios de consultoría de implementación del modelo de referencia MR-MPS; (iii) Instituciones Evaluadoras (IA) acreditadas para prestar servicios de evaluación siguiendo el método de evaluación MA-MPS; (iv) Consultores de Adquisición (CA) certificados para prestar servicios de consultoría de adquisición de software y servicios asociados;

b) meta de mercado, teniendo como objetivo la propagación y adopción del modelo MPS, en todas las regiones del país, en un intervalo de tiempo justo, a un costo razonable, tanto en PYMEs (foco principal) así como en grandes organizaciones públicas y privadas, con resultados esperados tales como: (i) creación y perfeccionamiento del modelo de negocio MN-MPS; (ii) cursos, pruebas y workshops; (iii) organizaciones que implementaron el modelo MPS; (iv) organizaciones con evaluación MPS publicada (vigencia de tres años).

El programa MPS.BR cuenta con dos estructuras de apoyo al desarrollo de sus actividades, el Foro de Acreditación y Control (FCC) y el Equipo Técnico del Modelo (ETM). Por medio de estas estructuras, el MPS.BR obtiene la participación de representantes de universidades, instituciones gubernamentales, centros de investigación y de organizaciones privadas, las cuales contribuyen con sus visiones complementarias que agregan calidad al emprendimiento.

Cabe al FCC: (i) emitir parecer para auxiliar las decisiones de la SOFTEX sobre la acreditación de Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA);

(ii) supervisar los resultados de las Instituciones Implementadoras (II) e Instituciones Evaluadoras (IA), emitiendo parecer proponiendo a la SOFTEX su desacreditación en caso de comprometimiento de la credibilidad del modelo MPS.

Cabe al ETM apoyar a la SOFTEX sobre los aspectos técnicos relacionados al Modelo de Referencia (MR-MPS) y Método de Evaluación (MA-MPS), para: (i) creación y perfeccionamiento continuo del MR-MPS, MA-MPS y sus guías específicas; (ii) capacitación de personas por medio de cursos, pruebas y workshops.

1 MPS.BR, MR-MPS, MA-MPS y MN-MPS son marcas de la SOFTEX. La sigla MPS.BR está asociada al programa MPS.BR – Mejora del Proceso de Software Brasileño y la sigla MPS está asociada al modelo MPS – Mejora del Proceso de Software.

(4)

La creación y el perfeccionamiento de esta Guía de Implementación son también atribuciones del ETM, siendo que esta guía forma parte del siguiente conjunto de documentos del modelo MPS:

• Guía General [SOFTEX, 2011a];

• Guía de Implementación (partes 1 a 11);

• Guía de Evaluación [SOFTEX, 2011b]; y

• Guía de Adquisición [SOFTEX, 2011c].

Esta Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos.

La Guía de implementación está subdividida en once partes, contemplando respectivamente, los siguientes niveles de madurez:

• Parte 1: Fundamentos para Implementación del Nivel G del MR-MPS;

• Parte 2: Fundamentos para Implementación del Nivel F del MR-MPS;

• Parte 3: Fundamentos para Implementación del Nivel E del MR-MPS;

• Parte 4: Fundamentos para Implementación del Nivel D del MR-MPS;

• Parte 5: Fundamentos para Implementación del Nivel C del MR-MPS;

• Parte 6: Fundamentos para Implementación del Nivel B del MR-MPS;

• Parte 7: Fundamentos para Implementación del Nivel A del MR-MPS;

• Parte 8: Implementación del MR-MPS (Niveles G a A) en organizaciones que adquieren software;

• Parte 9: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo Fábrica de Software;

• Parte 10: Implementación del MR-MPS (Niveles G a A) en organizaciones del tipo Fábrica de Pruebas; y

• Parte 11: Implementación y Evaluación del MR-MPS (Niveles G a A) en conjunto con el CMMI-DEV.

Los cambios de esta Guía de Implementación en relación a la versión 2009 se deben a:

• cambios realizados en la versión 2009 de la Guía General;

• corrección ortográfica y gramatical;

• adecuación de las referencias bibliográficas;

• inclusión de notas explicativas contenidas en las partes 8, 9 y 10 de la Guía de Implementación;

• inclusión de comentario sobre dominios de aplicación y aclaración sobre el resultado esperado DRU7.

(5)

2 Introducción

Los cambios que están sucediendo en los ambientes de negocios han motivado a las empresas a modificar sus estructuras organizacionales y procesos productivos, saliendo de la visión tradicional basada en áreas funcionales hacia redes de procesos centrados en el cliente. La competitividad depende, cada vez más, del establecimiento de conexiones en estas redes, creando vínculos esenciales en las cadenas productivas. Lograr competitividad por la calidad, para las empresas de software, implica tanto la mejora de la calidad de los productos de software y servicios asociados, así como la de los procesos de producción y distribución de software.

De esta forma, así como para otros sectores, la calidad es un factor crítico de éxito para la industria de software. Para que se tenga un sector de software competitivo nacional e internacionalmente, es esencial que los emprendedores del sector se concentren en la eficiencia y la eficacia de sus procesos, buscando ofrecer productos de software y servicios asociados conforme estándares internacionales de calidad.

Se busca que el modelo MPS sea adecuado al perfil de empresas con diferentes tamaños y características, públicas y privadas, aunque con especial atención a las micro, pequeñas y medianas empresas. También se espera que el modelo MPS sea compatible con los estándares de calidad aceptados internacionalmente y que tenga como presupuesto el aprovechamiento de toda la competencia existente en los estándares y modelos de mejora de proceso ya disponibles. De esta forma, tiene como base los requisitos de procesos definidos en los modelos de mejora de proceso y atiende a la necesidad de implantar los principios de Ingeniería de Software de manera adecuada al contexto de las empresas, estando en consonancia con los principales abordajes internacionales para la definición, evaluación y mejora de procesos de software.

El Modelo MPS se basa en los conceptos de madurez y capacidad de proceso para la evaluación y mejora de la calidad y productividad de productos de software y servicios asociados. Dentro de ese contexto, el MPS.BR posee tres componentes:

Modelo de Referencia (MR-MPS), Método de Evaluación (MA-MPS) y Modelo de Negocio (MN-MPS).

El Modelo MPS está descrito por medio de documentos en forma de guías:

• Guía General: contiene la descripción general del modelo MPS y detalla el Modelo de Referencia (MR-MPS), sus componentes y las definiciones comunes necesarias para su entendimiento y aplicación.

• Guía de Adquisición: describe un proceso de adquisición de software y servicios asociados. Está descrito de modo que apoye a las instituciones que quieran adquirir productos de software y servicios asociados.

• Guía de Evaluación: describe el proceso y el método de evaluación MA-MPS, los requisitos para evaluadores líderes, evaluadores adjuntos e Instituciones Evaluadoras (IA); y

• Guía de Implementación: serie de once documentos que proporcionan orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR-MPS.

(6)

3 Objetivo

La Guía de Implementación proporciona orientaciones para implementar en las organizaciones los niveles de madurez descritos en el Modelo de Referencia MR- MPS, detallando los procesos contemplados en los respectivos niveles de madurez y los resultados esperados con la implementación de los procesos. Este documento corresponde a la parte 5 de la Guía de Implementación y aborda la implementación del nivel de madurez C.

Este documento está dirigido, pero no se limita, a organizaciones interesadas en utilizar el MR-MPS para mejora de sus procesos de software e Instituciones Implementadoras (II). El contenido de este documento es informativo, o sea, no se espera que una organización implementando el MR-MPS cumpla todos los elementos citados en la explicación referente a los resultados esperados. Las observaciones presentes en este documento buscan apenas explicitar elementos importantes en la interpretación de los resultados esperados. Durante una evaluación MPS, solo es requerido el cumplimiento de los resultados esperados definidos en la Guía General. Los evaluadores MPS deben analizar si la implementación de los procesos de la organización cumple cada resultado, con abertura a múltiples formas válidas de implementación.

4 Evolucionando del nivel D al nivel C

La evolución del nivel D al nivel C no presenta novedades en términos de los procesos y atributos de proceso ya implantados en el nivel D.

La evolución hacia el nivel C del MR-MPS implica, por lo tanto, apenas en la definición e implementación de tres nuevos procesos con la misma capacidad de los procesos ya implantados: Gestión de Decisiones (GDE), Desarrollo para Reutilización (DRU) y Gestión de Riesgos (GRI).

En este nivel, se permiten exclusiones de resultados esperados apenas del proceso Desarrollo para Reutilización (DRU) conforme definido en la sección 5.1.

5 Desarrollo para Reutilización (DRU) 5.1 Propósito

El propósito del proceso Desarrollo para Reutilización es identificar oportunidades de reutilización sistemática de activos en la organización y, si es posible, establecer un programa de reutilización para desarrollar activos a partir de ingeniería de dominios de aplicación.

La Reutilización de Software es la disciplina responsable por la creación de sistemas de software a partir de software pre-existente [KRUEGER, 1992]. Diferentemente de la reutilización ad hoc, que usualmente se concretiza con copia de trechos de artefactos preexistentes, la disciplina de Reutilización de Software busca sistematizar y difundir prácticas de reutilización en la organización. El proceso Desarrollo para Reutilización es uno de los mecanismos utilizados por la disciplina de Reutilización de Software para ese fin.

El Desarrollo para Reutilización busca aplicar técnicas de ingeniería de dominio para definir el alcance, especificar la estructura y construir activos reutilizables para una clase de sistemas, subsistemas o aplicaciones [IEEE, 2004]. Esos activos

(7)

reutilizables, por ser producidos a partir de la ingeniería de dominio, son denominados activos de dominio. De esta forma, el principal resultado de la aplicación del proceso Desarrollo para Reutilización es la especificación, diseño e implementación de activos de dominio que atiendan a familias de aplicaciones o a dominios de conocimiento específicos.

El Desarrollo para Reutilización se inicia en la identificación del potencial de reutilización y de la capacidad de reutilización de la organización. En esa etapa se busca minimizar el riesgo de implantación de un programa de reutilización. En situaciones donde el Desarrollo para Reutilización se aplica, la etapa siguiente consiste en el análisis, diseño e implementación de activos de dominio previamente definidos. A partir de ese momento, los activos de dominio pueden ser objeto de propuestas de reutilización, de acuerdo con procesos de ingeniería de aplicación [JACOBSON et al., 1997].

Como puede ser constatado, el Desarrollo para Reutilización no se propone a definir cuándo y cómo los activos de dominio deben ser reutilizados, rol este reservado al propio proceso de desarrollo de software. Su actuación ocurre en la creación y evolución de esos activos de dominio, llevando en consideración la demanda existente en los diversos proyectos de la organización. De esta forma, es posible percibir que el proceso Desarrollo para Reutilización actúa tanto a nivel organizacional, en lo que se refiere a la creación de los activos de dominio, así como en proyectos específicos, en lo que se refiere a solicitaciones de reutilización de los activos de dominio.

El proceso Desarrollo para Reutilización está íntimamente relacionado a otros procesos del MR-MPS. Por ejemplo, el proceso Gestión de Proyectos apoya en la planificación del proceso Desarrollo para Reutilización y del programa de reutilización; el proceso Gestión de Decisiones apoya en la decisión sobre la implantación o no de un programa de reutilización en la organización; el proceso Gestión de Riesgos apoya en la evaluación de la capacidad de reutilización de la organización; el proceso Verificación apoya la revisión del programa de reutilización y de los activos de dominio; el proceso Adquisición apoya en la adquisición de activos de dominio en el mercado; el proceso Gestión de Configuración apoya en la evolución de los activos de dominio producidos durante la ejecución del proceso Desarrollo para Reutilización.

Por otro lado, el proceso Desarrollo para Reutilización puede apoyar al proceso Gestión de Reutilización, suministrando activos para colocarlos a disponibilidad para reutilización en la organización, y el proceso Diseño y Construcción del Producto, cuando se decide por reutilizar componentes del producto.

(8)

Exclusiones de resultados esperados de este proceso son permitidas de acuerdo con lo definido en la Tabla 5.1. La aprobación de las exclusiones es responsabilidad del evaluador líder. Todas las exclusiones de procesos o de resultados esperados deben estar identificadas en el Plan de Evaluación, en el Documento de Evaluación y en el Resultado da Evaluación.

Tabla 5.1 – Exclusiones de los Resultados de DRU.

Oportunidades

(DRU1) Capacidad

(DRU2) Solución

Si Si − Los demás resultados del DRU son obligatorios

Si No − Debe ejecutar acciones correctivas para generar capacidad

− Debe comprobar que esas acciones correctivas están en curso

− Los demás resultados pueden ser excluidos de esa evaluación

− Para la próxima evaluación, con un plazo de 3 años, debe obligatoriamente haber construido la capacidad No Excluido − Debe demostrar, vía proceso formal de toma de

decisión, que no existen oportunidades de reutilización

− Los demás resultados pueden ser excluidos mientras haya ausencia de oportunidades de reutilización (en esa y en las próximas evaluaciones)

Comentarios adicionales para implementación en diferentes tipos de organización Adquirientes

de Software (Parte 8)

Las exclusiones de resultados de este proceso permitidas están definidas en la tabla arriba y no difieren de las permitidas para otro tipo de organización.

Como no existen especificidades para organizaciones adquirentes, no fueron incluidos comentarios en los resultados esperados.

Fábrica de Software (Parte 9)

Para el caso de una organización del tipo Fábrica de Software, por restricciones contractuales, muchas veces no es permitido reutilizar componentes entre proyectos y/o clientes diferentes.

Como no existen especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios en los resultados esperados.

(9)

Fábrica de Pruebas (Parte 10)

La aprobación de las exclusiones es responsabilidad del evaluador líder, dependiendo del tipo de Prueba a ser efectuada.

Productos típicamente reutilizables para el caso de una Fábrica de Pruebas son los scripts de Prueba o las Pruebas automatizadas. Sin embargo, para el caso de una organización del tipo Fábrica de Pruebas, por restricciones contractuales, muchas veces no es permitido reutilizar componentes entre proyectos y/o clientes diferentes.

Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios en los resultados esperados.

5.2 Fundamentación teórica

La Reutilización de Software surgió en 1968, a partir de la constatación de que sistemas de software podrían ser construidos a partir de componentes preexistentes [MCILROY, 1968]. En aquel momento, componentes eran considerados apenas rutinas de código, y los dominios de aplicación sugeridos para la creación de componentes eran de infraestructura (por ejemplo, rutinas de aproximación numérica, conversión de entrada/salida, geometría 2D y 3D, procesamiento de texto y persistencia).

Desde entonces, fue posible notar una gran evolución en la disciplina de Reutilización de Software: los componentes reutilizables, que eran considerados como rutinas de código, hoy en día son tratados en diferentes niveles de abstracción; los dominios de aplicación, que se concentraban básicamente en infraestructura, hoy están migrando cada vez más para dominios de negocio, donde se pueden observar ganancias mayores con la aplicación de reutilización; y los procesos de apoyo se tornaron cada vez más maduros.

Bajo la dimensión de procesos, el proceso de Reutilización de Software puede ser descompuesto en dos procesos principales [MOORE e BAILIN, 1991]: Desarrollo para Reutilización y Desarrollo con Reutilización. El proceso Desarrollo para Reutilización utiliza técnicas de ingeniería de dominio para la creación de activos reutilizables para un dominio específico. El proceso Desarrollo con Reutilización utiliza técnicas de ingeniería de aplicación para la incorporación de activos reutilizables preexistentes en nuevas aplicaciones.

De forma análoga al desarrollo convencional de software, la ingeniería de dominio puede ser subdividida en tres sub-actividades principales: análisis, diseño e implementación. El principal producto del análisis es el modelo de dominio. A su vez, el principal producto del diseño es la arquitectura de dominio. Finalmente, el principal producto de la implementación son los activos de dominio.

No obstante, para que el proceso Desarrollo para Reutilización tenga éxito, aspectos técnicos y organizacionales deben ser considerados. En lo referente a los aspectos técnicos, diversos métodos fueron propuestos para apoyar en la creación de los activos de dominio. Por otro lado, en lo referente a aspectos organizacionales,

(10)

diferentes cuestiones también son importantes, tales como: composición de los equipos, certificación de los componentes, responsabilidad de mantenimiento, aspectos legales, aspectos económicos, etc.

Como el objetivo del proceso Desarrollo para Reutilización no es la construcción de una única aplicación, sino más bien de activos de dominio que atiendan a familias de aplicaciones, es necesario que esos activos de dominio tengan un grado adecuado de generalidad. Para eso, la ingeniería de dominio hace uso de recursos usualmente utilizados en el análisis de sistemas convencional, acrecidos de funcionalidades especiales para especificar elementos obligatorios u opcionales, comunes o variantes, dependencias y restricciones.

Una característica obligatoria de un dominio representa algo que debe estar presente en todas las aplicaciones para aquel dominio. Por otro lado, una característica opcional de un dominio representa algo que puede o no estar presente en aplicaciones del dominio. De forma perpendicular, una característica común del dominio tiene el mismo comportamiento en todas las aplicaciones del dominio. Ya una característica variante del dominio puede tener comportamientos diferenciados para diferentes aplicaciones del dominio.

Además de eso, pueden existir relaciones específicas entre las diversas características de un dominio [KANG et al., 1990]. Esas relaciones son usualmente divididas en dos categorías: dependencia y exclusión mutua. La relación de dependencia indica que una característica solo puede ser reutilizada de forma correcta en caso de que otras características también sean reutilizadas en conjunto (por ejemplo: la característica A requiere la característica B). Por otro lado, la relación de exclusión mutua indica que una característica solo puede ser reutilizada de forma correcta en caso de que otras características no sean reutilizadas en conjunto (por ejemplo: la característica A excluye la característica B). Usualmente son utilizados otros operadores lógicos en conjunto con esas relaciones para aumentar el poder de expresión del modelo de dominio.

De esta forma, un modelo de dominio describe en un alto nivel de abstracción las diversas familias de aplicaciones de un dado dominio. A partir del detalle de ese modelo de dominio, es obtenida la arquitectura de dominio, que sirve como base para la priorización de los activos de dominio que serán posteriormente adquiridos o desarrollados.

Vale resaltar que, un elemento clave en ese escenario es la rastreabilidad entre las representaciones de los activos de dominio en diferentes niveles de abstracción.

Con base en esa rastreabilidad, es posible seleccionar determinadas características en el modelo de dominio (recorte del modelo de dominio) e identificar cuáles son los activos de dominio que deben ser reutilizados para proveer las características seleccionadas.

(11)

5.3 Resultados esperados

5.3.1 DRU1 - Dominios de aplicación en que serán investigadas oportunidades de reutilización de activos o en los cuales se pretende practicar reutilización son identificados, detectando los respectivos potenciales de reutilización

Con la intención de viabilizar la decisión de implantación de un programa de reutilización, es necesario verificar si las ganancias proporcionadas por esa implantación son mayores que sus costos. Para eso, los dominios de actuación de la organización deben ser identificados. Esa identificación, que usualmente se basa en proyectos pasados, debe estar alineada con los objetivos organizacionales y las metas de medio y largo plazo de la organización. Con eso, además de percibir en cuales dominios la organización actuó hasta entonces, es posible inferir dominios en que la organización pretende actuar en un futuro próximo.

Los dominios de aplicación de una organización son aquellos relacionados al área de negocio de ella, por ejemplo, banquera, automatización comercial, médica etc. En otro ejemplo, si la empresa es desarrolladora de sistemas de administración de banco de datos (SGBD), tiene sentido que el dominio de aplicación de ella sea almacenamiento, caso contrario, no. Para cada dominio identificado, se debe analizar el potencial de reutilización, llevando en consideración los activos de dominio preexistentes en la organización y la posibilidad de adquirir activos de dominio en el mercado. El potencial de reutilización debe llevar en consideración la importancia del dominio para la organización en términos de proyectos futuros que la organización pretende ejecutar en el dominio en cuestión y el nivel de madurez y estabilidad del dominio. O sea, un dominio en que existe una gran oferta de activos de dominio, pero que la organización no pretende actuar más, es considerado de bajo potencial de reutilización bajo el punto de vista de la organización. De la misma forma, el potencial de reutilización de un dominio inmaduro, con alto grado de inestabilidad, es usualmente considerado bajo, debido a la dificultad de mantener un conjunto razonable de activos de dominio disponible y consistente.

La no existencia de dominios con potencial de reutilización en la organización puede justificar la no adopción de un programa de reutilización. No obstante, para justificar esa falta en la adopción, es fundamental la utilización de mecanismos formales de toma de decisión, de acuerdo con el proceso Gestión de Decisiones.

5.3.2 DRU2 - La capacidad de reutilización sistemática de la organización es evaluada y acciones correctivas son tomadas, caso necesario

Otro factor de gran importancia para el éxito de implantaciones de programas de reutilización es la capacidad de la organización para ejecutar ese programa.

Ejemplos de criterios relevantes para evaluación en ese contexto incluyen recursos humanos, financieros, de infraestructura y culturales. Bajo el punto de vista de recursos humanos, personas capacitadas para la ejecución sistemática del programa de reutilización pueden asegurar una mayor efectividad del programa. En relación a recursos financieros, es importante de que la organización esté consciente que el retorno de las inversiones en un programa de reutilización se obtiene a largo plazo. En lo que se refiere a la infraestructura, un programa de reutilización demanda, como cualquier otro proyecto de desarrollo de software, recursos apropiados para su ejecución. Finalmente, aspectos culturales también deben ser

(12)

considerados, pues, con la adopción de un programa de reutilización, los equipos pasarán a utilizar activos de dominio construidos y mantenidos por otros equipos dentro de la organización.

La evaluación de la capacidad de reutilización sistemática de la organización puede ser apoyada por un proceso de Gestión de Riesgos, donde el objetivo es minimizar los riesgos de fracaso del programa de reutilización a ser implantado.

En el caso de que la evaluación de la capacidad de la organización no tenga resultados positivos, la organización debe tomar acciones correctivas buscando crear las condiciones necesarias para la adopción del programa de reutilización. De esta forma, una evaluación negativa de capacidad de reutilización sistemática no justifica la no adopción de un programa de reutilización, pero si la postergación de esa adopción hasta que un nivel adecuado de capacidad sea logrado con la ejecución de las acciones correctivas.

5.3.3 DRU3 - Un programa de reutilización, incluyendo propósitos, alcance, metas y objetivos, es planificado con la finalidad de atender las necesidades de reutilización de dominios

Escenarios donde la organización tiene capacidad de reutilización sistemática y existen dominios con potencial de reutilización son propicios para el éxito de un programa de reutilización. Después de la aplicación de mecanismos formales para la toma de decisión (por ejemplo, por medio del proceso Gestión de Decisiones), en caso de que sea comprobado este escenario, la organización está apta para iniciar un programa de reutilización. Caso contrario, la adopción de un programa de reutilización se debe suspender temporariamente. No obstante, se debe repetir periódicamente la evaluación formal para verificar si se está logrando crear el escenario propicio para la adopción de un programa de reutilización.

El programa de reutilización debe establecer el propósito y las metas a ser logradas con la adopción de Reutilización de Software en la organización. Además de eso, para que esas metas puedan ser logradas, una información relevante son los recursos necesarios y disponibles. De esta forma, los elementos comunes en la planificación de un programa de reutilización son: los estados intermediarios a ser logrados durante la implantación; las actividades a ser ejecutadas, juntamente con los procedimientos, el cronograma y los responsables por la ejecución; los recursos disponibles; los indicadores a ser utilizados para la supervisión del programa; y el alcance en que el programa será conducido. Ese alcance puede ser definido en diferentes dimensiones: toda la organización o unidades organizacionales específicas; todos los dominios en que la organización actúa o dominios específicos;

para todos los tipos de activos de dominio o para tipos de activos de dominio específicos, etc.

Note que tanto las metas como os objetivos orientan y reflejan las condiciones deseadas para mejora del desempeño global de la organización. Mientras que los objetivos son más amplios, las metas son más específicas, siendo más apropiadas para orientar las tomas de decisión y actividades cotidianas de la organización [VILLELA, 2004].

(13)

5.3.4 DRU4 - El programa de reutilización es implantado, supervisado y evaluado

El programa de reutilización se debe implantar de acuerdo con lo planificado, como descrito en el DRU3. Además de eso, el programa de reutilización es supervisado llevando en consideración los indicadores previamente planificados. Esa supervisión debe comparar lo planificado con lo realizado. Las no-conformidades detectadas deben ser reportadas, analizadas, evaluadas y tratadas.

Finalmente, el programa de reutilización es evaluado periódicamente, con el objetivo de verificar su efectividad y motivar mejoras en su planificación, ejecución e infraestructura disponible.

5.3.5 DRU5 - Propuestas de reutilización son evaluadas de modo que se asegure que el resultado de la reutilización sea apropiado para la aplicación a la que se destina

Siempre que proyectos específicos demanden activos de dominio, esas demandas deben ser encaminadas en la forma de propuestas de reutilización. Las propuestas de reutilización pueden ocurrir tanto en la forma de solicitaciones de reutilización de activos de dominio existentes, como en la forma de solicitaciones para la construcción o adquisición de nuevos activos de dominio.

Esas propuestas de reutilización deben ser analizadas, buscando medir el esfuerzo de adaptación de los activos de dominio existentes. En caso de no existir en la biblioteca de activos reutilizables ningún activo de dominio que atienda a la necesidad relatada, el análisis tiene como objetivo medir el esfuerzo para construir el activo de dominio o el costo para adquirir el activo de dominio en el mercado.

A partir de los laudos de los análisis, las propuestas de reutilización deben ser evaluadas, buscando asegurar que la reutilización esté alineada con las necesidades y expectativas de la organización. Esa evaluación debe, además de aprobar o no la propuesta de reutilización, indicar cómo la reutilización será viabilizada. O sea, vía adaptación de activos de dominio preexistentes, construcción de nuevos activos de dominio o adquisición de activos de dominio en el mercado. En caso de adaptaciones sobre activos de dominio preexistentes, es de gran importancia mantener la rastreabilidad entre el activo de dominio base de la adaptación y el activo de dominio adaptado.

5.3.6 DRU6 - Formas de representación para modelos de dominio y arquitecturas de dominio son seleccionadas

Para que el conocimiento relacionado con un dominio específico pueda ser difundido por la organización, es importante que notaciones adecuadas de representación de los modelos de dominio y de las arquitecturas de dominio sean adoptadas. Esas notaciones deben ser capaces de representar dominios y familias de aplicaciones en diferentes niveles de abstracción.

Para los modelos de dominio, se espera que la notación adoptada sea capaz de representar la frontera entre dominios y capturar características que forman parte de todas las aplicaciones desarrolladas para un dado dominio, características que pueden o no ser de determinadas aplicaciones y características que pueden asumir diferentes formas en diferentes aplicaciones. Además de eso, la notación debe ser

(14)

capaz de representar dependencia entre características y exclusión mutua de características.

Para las arquitecturas de dominio, se espera que la notación adoptada sea capaz de representar, con respecto al diseño, las restricciones definidas en los modelos de dominio. El objetivo de las arquitecturas de dominio es proporcionar detalles de diseño para familias de aplicaciones que tuvieron sus características analizadas por medio de modelos de dominio. La notación adoptada debe permitir la concretización de las características definidas en los modelos de dominio en una arquitectura que describa la relación entre posibles activos de dominio, incluyendo aspectos tecnológicos y de infraestructura, siempre que sea pertinente.

5.3.7 DRU7 - Un modelo de dominio es desarrollado y sus límites y relaciones con otros dominios son establecidos y mantenidos. Este modelo debe ser capaz de capturar características, capacidades, conceptos y funciones comunes, variantes, opcionales y obligatorios Para cada dominio en el cual existe un potencial de reutilización, se debe establecer sus fronteras con dominios asociados, de acuerdo con la notación previamente establecida. Esa frontera define claramente el contexto del programa de reutilización y permite identificar dominios asociados, que pueden venir a ser parte del programa de reutilización en el futuro. El modelo de dominio desarrollado debe ser capaz de captar características, capacidades, conceptos y funciones, conforme pertinente. Se debe, también, identificar cuales elementos son comunes, variantes, opcionales u obligatorios.

Modelos de dominio deben ser definidos para todos los dominios que están en el alcance del programa de reutilización, de acuerdo con la notación previamente establecida. Esos modelos de dominio producidos, a pesar de situarse en un alto nivel de abstracción, ya deben ser considerados activos reutilizables y colocados en una biblioteca de activos reutilizables. Además de eso, esos modelos de dominio son objeto de un proceso formal de Gestión de Configuración, visto que los activos de dominio construidos a partir de ellos serán utilizados por diferentes proyectos de la organización. Cambios no controlados sobre los modelos de dominio pueden traer graves consecuencias en esos proyectos.

5.3.8 DRU8 - Una arquitectura de dominio describiendo una familia de aplicaciones para el dominio es desarrollada y mantenida durante todo su ciclo de vida

El detalle de los modelos de dominio permite identificar familias de aplicaciones para un dado dominio. Esas familias de aplicaciones deben ser representadas vía arquitectura de dominio utilizando la notación previamente establecida. Esa arquitectura de dominio posibilita identificar cuáles son los activos de dominio y cómo ellos se relacionan.

Con el objetivo de percibir su importancia para la organización, se debe analizar cada activo de dominio perteneciente a la arquitectura de dominio. A partir de ese análisis, se debe establecer una priorización para la especificación de los activos de dominio.

De forma análoga a los modelos de dominio, la arquitectura de dominio también se debe considerar como un activo reutilizable y se debe colocar en una biblioteca de

(15)

activos reutilizables. Para viabilizar la Gestión de Configuración sobre la arquitectura de dominio, es de suma importancia el mantenimiento de la rastreabilidad entre las características existentes en los modelos de dominio y los activos de dominio descritos en la arquitectura de dominio que proporcionan esas características. Así, cambios en los modelos de dominio pueden ser fácilmente propagados para los demás niveles de abstracción.

5.3.9 DRU9 - Activos del dominio son especificados, adquiridos o desarrollados, y mantenidos durante todo su ciclo de vida

Los activos de dominio identificados en la arquitectura de dominio son especificados conforme estrategia definida por la organización, por ejemplo, siguiendo la priorización previamente definida. Esa especificación busca detallar las funcionalidades del activo de dominio, lo que viabilizaría tanto su desarrollo como su adquisición.

Con esa especificación detallada, aún siguiendo la priorización definida en la arquitectura de dominio, puede hacerse un análisis de costo x beneficio en relación al desarrollo o adquisición del activo de dominio. Ese análisis, juntamente con La especificación del activo de dominio, servirá de base para la toma de decisión de desarrollo o adquisición.

Vale resaltar que, el desarrollo del activo de dominio puede ser acelerado en caso de que proyectos anteriores tengan funcionalidades semejantes a las funcionalidades especificadas para el activo de dominio. En esos casos, procesos de refactoración pueden ser aplicados con la intención de generalizar esas funcionalidades y encapsularlas en el activo de dominio. De modo general, los procesos de ingeniería de la organización son aplicables caso el activo de dominio venga a ser desarrollado. Por otro lado, en caso de que el activo de dominio sea adquirido en el mercado, se debe aplicar el proceso Adquisición.

Después de desarrollados o adquiridos en el mercado, los activos de dominio son colocados a disponibilidad en una biblioteca de activos reutilizables. Mecanismos establecidos en la organización son indicados para asegurar que los activos cumplen los requisitos mínimos de calidad deseados y si funcionarán como se pretende que sea en el ambiente de uso. Además de eso, los activos están bajo proceso formal de Gestión de Configuración, que permite la identificación de todos sus casos de utilización para notificación siempre que una nueva versión del activo de dominio sea colocada a disponibilidad en la biblioteca.

(16)

6 Gestión de Decisiones (GDE) 6.1 Propósito

El propósito del proceso Gestión de Decisiones es analizar posibles decisiones críticas usando un proceso formal, con criterios establecidos, para evaluación de las alternativas identificadas

Este proceso se debe aplicar en la toma de decisión relacionada a una cuestión crítica que se juzgue como objeto de un proceso de evaluación formal, pudiendo ocurrir tanto en el ámbito de los proyectos como organizacional. De esa forma, ese proceso es iniciado a cualquier momento a partir de la identificación de una cuestión de este tipo en la ejecución de cualquiera de los procesos del MR-MPS.

Un proceso de evaluación formal es un abordaje estructurado para evaluar soluciones alternativas en relación a criterios establecidos para determinar la solución a ser utilizada para resolver un problema. El principal motivo para utilizar este proceso es que él reduce la subjetividad de la decisión y, de esta forma, se tiene una mayor probabilidad de seleccionar una solución que atienda las múltiples demandas de los involucrados.

La Ingeniería de Software, como diversas áreas de conocimiento, también requiere el uso de técnicas de gestión, pues decisiones necesitan ser tomadas a lo largo de todo el proceso de desarrollo y evolución de los sistemas. Cuestiones como tipos de tecnologías, procesos, recursos y herramientas son fundamentales para el aseguramiento de la calidad de productos y servicios. RUHE [2003a] comenta que la toma de decisiones afecta significativamente a todas las fases del ciclo de vida de un proyecto y que procesos y sistemas de apoyo a la decisión son fundamentales para aumentar la eficiencia, la calidad y la relación costo/beneficio de sistemas.

RUHE [2003b] también destaca el hecho de que el apoyo a la toma de decisiones es un nuevo paradigma para organizaciones que buscan un aprendizaje continuo en desarrollo de software, pues:

• Facilita la estructuración de problemas bajo investigación;

• Auxilia la comprensión de informaciones necesarias a la toma de decisiones eficientes;

• Posibilita el acceso a datos que, de otra forma, no estarían disponibles o serian difíciles de ser obtenidos;

• Genera y evalúa alternativas de soluciones;

• Prioriza alternativas por medio de modelos explícitos.

Según KLEIN [1999] existen dos perspectivas en las cuales los seres humanos toman decisiones: la natural y la racional. En la primera, los decisores están, normalmente, involucrados con problemas u objetivos mal definidos y las decisiones se basan en la experiencia, por la intuición, simulaciones mentales, etc. Ya en la decisión Racional, existe un proceso formal de toma de decisión, o línea de

(17)

raciocinio a ser seguida donde paso a paso, el decisor es llevado a lograr el objetivo propuesto por el proceso.

Problemas bien definidos son aquellos donde los objetivos, caminos y obstáculos están claros y basados en informaciones confiables. A la vez que, problemas mal definidos son caracterizados por la ausencia de un camino claro que lleve a la solución. Los objetivos bien definidos son aquellos que proporcionan al solucionador una línea clara de acción en su dirección como, por ejemplo, el objetivo de adquirir el producto de menor precio. Ya en los objetivos mal definidos, las metas a ser logradas no son claras.

Diversos estudios discuten las ventajas y las desventajas tanto del abordaje natural, como del racional, tales como [SCHANK e OWENS, 1987; KLEIN e WEITZENFELD, 1978; LIPSHITZ e BAR-ILAN, 1996; GIGERENZER e SELTEN, 2002]. A pesar de las controversias existentes entre las perspectivas natural y racional, no hay como negar que informaciones cuantitativas estén en todos los lugares en el mundo de los negocios y la tendencia parece ser: medir y cuantificar todo lo que se pueda. Sin embargo, el problema pasa a ser: qué hacer con esa cantidad masiva de informaciones. ¿Cómo debemos usarlas para auxiliar a los tomadores de decisión a ayudar a las organizaciones a tratar los problemas y las presiones que enfrentan [WISNIEWSKI, 2002]? Aliado a eso, otros factores tienden a llevar el proceso de toma de decisión en el contexto de la Ingeniería de Software hacia la perspectiva racional:

• La Ingeniería de Software es parte de un contexto financiero y es una actividad económica como cualquier otra, donde, además de los beneficios introducidos por los sistemas, organizaciones buscan ampliar sus lucros, aumentar la expectativa de ganancia futura o minimizar perjuicios en un mercado dinámico, cada vez más competitivo y repleto de incertidumbre. En este sentido, tanto gerentes como técnicos necesitan, en muchos casos, basar y justificar sus decisiones de manera formal [COSTA et al., 2004];

• Durante un proceso de desarrollo de software, generalmente hay tiempo suficiente para tomar decisiones basadas en un análisis más detallado, como la sugerida por la perspectiva racional, diferentemente de decisiones que implican riesgo de vida o urgencia absoluta como en el caso de médicos, militares, bomberos y otros profesionales altamente presionados por el tiempo;

• Permite que el registro de los procesos sea reutilizado en futuras decisiones, facilitando la generación de conocimiento, el aprendizaje organizacional, el perfeccionamiento del proceso y la mejora de los parámetros de decisión; y

• Modelos de Referencias de Procesos y normas internacionales, tales como el CMMI [SEI, 2010], la ISO/IEC 12207 [ISO/IEC, 2008] y la ISO/IEC 15504 [ISO/IEC, 2003] - exigen procesos formales de toma de decisión, sea para obtener una certificación o para lograr determinados niveles de madurez y capacitación en procesos de software.

(18)

No son permitidas exclusiones de resultados de este proceso.

Como no existen especificidades para organizaciones adquirientes, no fueron incluidos comentarios a los resultados esperados.

Como no existen especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios a los resultados esperados.

Como no existen especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios a los resultados esperados.

6.3 Resultados esperados

6.3.1 GDE1 - Guías organizacionales para la gestión de decisiones son establecidas y mantenidas

El proceso Gestión de Decisiones (GDE) puede ser utilizado para tratar problemas con riesgo medio o alto o que afectan la posibilidad de lograr los objetivos del proyecto, así como cuando el impacto de la decisión envuelve una cantidad determinada del presupuesto, alteración significativa del cronograma o calidad, decisiones técnicas no triviales, etc. Así, él podrá ser usado tanto para problemas técnicos (como la decisión del tipo de arquitectura a ser utilizada) así como para problemas no técnicos (como cuál es el mejor proveedor de un producto). Sin embargo, se debe observar atentamente el hecho de que el costo de ejecutar un proceso de evaluación formal debe ser razonable cuando comparado al impacto de la decisión. Guías organizacionales deben, entonces, ser establecidos y mantenidos conteniendo descripciones de los criterios para inicio obligatorio del proceso Gestión de Decisiones (GDE) en la organización. Sin embargo, diversas otras situaciones no previstas pueden evocar la ejecución del proceso formal de decisión.

No existe una lista completa sobre cuando usar un proceso formal de decisión, pues su utilización es extremamente dependiente del tipo de organización, del proyecto o inclusive del producto. Sin embargo, algunos ejemplos de situaciones donde su utilización seria posible incluyen:

• Definición de componentes;

• Decisión sobre construir o adquirir un producto;

• Definición de herramientas;

• Definición de estrategias de contingencias de riesgos;

• Priorización de recursos;

(19)

• Contratación de personal;

• Plataformas de sistemas.

Sin embargo, el proceso formal de decisión puede estar asociado a la ejecución de cualquier otro proceso, sin haber una relación directa entre ellos. Así, si durante el proceso Gestión de Configuración, por ejemplo, hay la necesidad de determinar cuál herramienta CASE será utilizada y, si es necesario formalizar esta decisión, el proceso GDE podrá ser iniciado.

6.3.2 GDE2 - El problema o cuestión a ser objeto de un proceso formal de toma de decisión es definido

El primer paso en el proceso de toma de decisión es definir exactamente cuál es el problema que se desea resolver, pues esta definición es decisiva sobre las posibles soluciones adoptadas. En este sentido, definir un problema erróneamente puede conducir a un camino que no llevará a la solución del problema real. Esta actividad busca asegurar que se pretende resolver el problema correcto. Algunos de los principales puntos a ser observados en la definición de problema son [GOMES et al., 2003]:

• No confundir un problema con su solución;

• Formular el problema como pregunta;

• Describir el problema de forma clara y precisa;

• Verificar si el problema no tiene base exclusivamente subjetiva;

• Verificar si el problema es susceptible de solución;

• Definir el alcance del problema;

• No concentrar la atención en los síntomas sino más bien en el problema raíz;

• Listar los objetivos a ser logrados para solucionar el problema;

• Listar las restricciones y premisas existentes para posibles soluciones.

6.3.3 GDE3 - Criterios para evaluación de las alternativas de solución son establecidos y mantenidos en orden de importancia, de modo que los criterios más importantes tengan más influencia en la evaluación

En muchos casos, más de una variable puede influenciar en la elección de la mejor solución. Esas variables se llaman criterios. De esa forma, los criterios de evaluación deben ser priorizados y/o ponderados para que puedan ser aplicados y la mejor solución pueda ser escogida, así como los parámetros de aceptación de cada criterio. La priorización o la ponderación de los criterios podrá ser hecha por una o más personas. Es interesante que se registre el resultado del trabajo con los motivos que llevaron a la elección de los criterios y su priorización y/o ponderación. Se puede, también, registrar los motivos que llevaron al rechazo de algunos criterios.

Para asegurar la objetividad, los criterios escogidos no deben ser tendenciosos, y deben ser escogidos apenas aquellos que colaboran para que el objetivo sea logrado. En la priorización o ponderación de criterios, estos deben ser ordenados de tal forma que el criterio con mayor grado de prioridad sea el que realmente tiene mayor influencia en el proceso de decisión.

(20)

Un ejemplo de definición y priorización de criterios sería el caso donde alguien está intentando definir cuál es la mejor impresora a ser adquirida, siendo que los criterios para la selección son la velocidad, la calidad y el costo de impresión, que en este caso, pueden estar priorizados de la siguiente forma: velocidad (20%), calidad (30%) y costo (50%), siendo estos porcentajes los pesos utilizados en la priorización de los criterios.

6.3.4 GDE4 - Alternativas de solución aceptables para el problema o cuestión son identificadas

La identificación de alternativas de solución debe ser realizada de modo que sea posible hacer una buena evaluación y una implementación correcta. Siempre que sea posible, los principales involucrados en el problema deben estar presentes en la ejecución de esta actividad, así como especialistas y personas que serán afectados por el problema o por la(s) solución(es).

Una buena práctica para la identificación de las posibles soluciones es realizar un trabajo de grupo o reuniones de brainstorming, así como la búsqueda de datos históricos, donde, además de las alternativas de solución, son levantados los riesgos, problemas, ventajas y desventajas de las referidas alternativas, así como posibles premisas y restricciones para la implementación de una solución.

Es importante, en este momento, la evaluación (cuantitativa) de los riesgos de implementación de cada solución, pues caso alguna solución sea considerada inviable, debido a su riesgo, probablemente ésta no deberá ser llevada para la próxima fase del proceso. Esta evaluación considera la probabilidad de ocurrencia, el impacto y si la implementación de esta solución afectará el proceso de desarrollo, el producto final o cualquier otra actividad en alguna fase futura.

Se debe levantar el mayor número posible de alternativas de solución y, si, a cualquier momento del proceso formal de decisión, otra alternativa de solución fuese identificada, esta también se deberá registrar.

6.3.5 GDE5 - Los métodos de evaluación de las alternativas de solución son seleccionados de acuerdo con su viabilidad de aplicación

No existe un consenso sobre cuál es el mejor método a ser utilizado en un proceso formal de decisión, pues ellos dependen directamente de varios factores, tales como el nivel de precisión requerido en la respuesta, el tiempo disponible para la toma de decisión, los recursos a ser empleados, el grado de conocimiento del equipo en la aplicación de un método específico, la complejidad del problema, las informaciones disponibles para la toma de decisión, etc. Mientras algunos problemas pueden necesitar del uso de apenas un método de evaluación, otros problemas pueden requerir diversos métodos para determinar cuál es la alternativa de solución que se aplica mejor al problema definido. Se debe dar una atención especial a la capacidad del método en enfocar el problema en cuestión y no ser influenciable por problemas secundarios.

Así, los métodos a ser usados para evaluación pueden variar desde una simple reunión a simulaciones, al uso de modelos probabilísticos complejos, llegando al desarrollo de sistemas especialistas para situaciones más específicas. El nivel de detalle, sofisticación o complejidad de un método puede variar de acuerdo con la

(21)

necesidad, el costo, el plazo, el desempeño y el impacto con que un problema puede afectar a un proyecto.

Ejemplos de métodos de evaluación tales como: creación de prototipo, simulación, árboles de decisión y análisis de costo/beneficio, pueden ser encontrados en [CLEMEN e REILLY, 2004]. Una lista de métodos más simples tales como reuniones de Brainstorming, técnica Delphi, Multivotación Ponderada, Análisis de Pareto y Comparación por Pares pueden ser encontrados en [WILDMAN e WARNER, 2003].

Otros métodos más complejos tales como Redes Bayesianas [JENSEN, 1996], Análisis Multicriterio [BANA e COSTA e VANSNICK, 1995] y Dinámica de Sistemas [BARROS, 2001] también pueden ser utilizados.

6.3.6 GDE6 - Soluciones alternativas son evaluadas usando los criterios y métodos establecidos

Evaluar las alternativas significa realizar el trabajo necesario para aplicar los métodos seleccionados a las posibles soluciones listadas. Se debe comparar los resultados obtenidos en cada alternativa con relación a los criterios establecidos. Al realizar el análisis de una alternativa, se hace necesario verificar si ella está adecuada a las restricciones y premisas impuestas tanto por el problema como por la propia alternativa en cuestión. La elaboración de un breve parecer del resultado obtenido después de la aplicación de los criterios de selección a cada alternativa analizada auxilia la evaluación de la adecuación de la selección y sirve como justificación para futuros cuestionamientos.

En el ejemplo de la selección de la impresora, citado anteriormente (GDE4), sería posible, por ejemplo, utilizar una Multivotación Ponderada para la elección de la impresora, según los criterios establecidos. Así, para cada impresora levantada como alternativa serian efectuados votos atribuyendo puntos a cada impresora, considerando cada criterio especificado. Después de esta votación, se ponderan los puntos, con base en la priorización de los criterios y se calcula la suma de puntos para cada impresora. De esta forma, la impresora con la mayor cantidad de puntos, a principio, sería la más adecuada para la adquisición.

6.3.7 GDE7 - Decisiones se toman con base en la evaluación de las alternativas utilizando los criterios de evaluación establecidos

Tomar la decisión adecuada implica escoger, entre las alternativas evaluadas, aquella que mejor se encuadre en los criterios determinados y hace que el problema sea resuelto.

Se debe documentar todo el proceso de selección de la solución para que se puedan aclarar cuestionamientos futuros. Así, se considera una buena práctica, registrar los motivos que justificaron la elección de una solución, así como los motivos que llevaron a la exclusión de las demás alternativas.

Después de la selección de la alternativa de solución, es aconsejable trazar algunas recomendaciones para su implementación. Esto significa trazar las líneas generales de la forma como la solución escogida será implementada, pudiendo contener informaciones adicionales, recomendaciones, responsables, etc. Además de eso, se aconseja la comunicación de las decisiones a todos los interesados.

Dependiendo del tipo de decisión a ser tomada, es importante que se verifiquen los riesgos asociados a esta implementación, los cuales ya pueden haber sido

(22)

identificados y evaluados al identificar las alternativas de solución. Posibles respuestas a los riesgos (contenciones o contingencias), necesarias para su eliminación o mitigación, deben ser definidas. Algunos abordajes para gestión de riesgos pueden ser encontradas en [BOEHM, 1991; HALL, 1998; CARR et al., 1993].

En caso de que sean necesarios cambios en el Plan del Proyecto o en líneas base previamente establecidas, estos deben ser registrados para que los responsables tengan conciencia de esos hechos.

Durante toda la ejecución del proceso, se considera una buena práctica registrar las lecciones aprendidas, así como los parámetros utilizados para que, en decisiones futuras, estas lecciones y parámetros puedan ser reutilizados.

7 Gestión de Riesgos (GRI) 7.1 Propósito

El propósito del proceso Gestión de Riesgos es identificar, analizar, tratar, supervisar y reducir continuamente los riesgos a nivel organizacional y de proyecto.

El proceso Gestión de Riesgos se debe aplicar tanto a riesgos de proyecto así como a riesgos organizacionales. Este proceso engloba las actividades de identificación y control de los riesgos, asociadas a acciones de mitigación y contingencia, con la intención de asegurar la reducción continua de estos riesgos y de su impacto en los proyectos o en la organización.

A pesar de que la planificación (incluyendo la identificación y priorización) y supervisión de los riesgos se inicia en el nivel G con los resultados GPR6 y GPR15 del proceso Gestión de Proyectos (GPR), la gestión de riesgos en el nivel C adiciona aspectos diferentes como, por ejemplo, la necesidad de planes de mitigación y la supervisión proactiva para evaluar las situaciones de los riesgos y del progreso de las actividades de tratamiento, y determina que sean establecidas estrategias a ser seguidas en los proyectos para identificación y tratamiento de los riesgos.

Para las organizaciones del tipo Fábrica de Software es importante analizar los riesgos relacionados al hecho de que las especificaciones estén incompletas o incorrectas, una vez que son proporcionadas a la organización por la contratante.

Como no existen otras especificidades para organizaciones del tipo Fábrica de Software, no fueron incluidos comentarios en los resultados esperados.

(23)

Además de los riesgos oriundos del propio proyecto de la Fábrica de Pruebas, deben ser llevados en consideración los riesgos provenientes de la contratante como, por ejemplo, la no entrega de los códigos en la fecha planificada.

Como no existen otras especificidades para organizaciones del tipo Fábrica de Pruebas, no fueron incluidos comentarios adicionales a los resultados esperados.

El IEEE define riesgo como la probabilidad de que un evento, peligro, amenaza o situación ocurra asociado a consecuencias indeseables, o sea, un problema en potencial [IEEE, 2001].

Todo proyecto de software envuelve un conjunto de incertidumbres que pueden llevar a resultados negativos. En la gran mayoría de los casos, estos resultados pueden ser evitados o reducidos si es que hay la preocupación en anticipar posibles problemas con el uso de prácticas de gestión proactiva, identificando y resolviendo los principales riesgos.

Todo tipo de actividad envuelve riesgos, por lo tanto, además de las actividades de las organizaciones de software orientadas a proyectos, existen actividades externas al proyecto, normalmente llamadas organizacionales, que también poseen riesgos asociados. Es importante no ser negligente con la gestión de estos riesgos. La gestión de riesgos se debe conducir durante todo el período vigente de las actividades o proyectos a los cuales esté asociada, desde su planificación hasta su conclusión.

Asociados a todo riesgo existen, según PFLEEGER [2004], tres factores:

probabilidad de que el riesgo ocurra; pérdida o impacto generado como consecuencia; y grado en que se puede cambiar el resultado del riesgo. A fin de calcular la exposición al riesgo para cuantificar sus efectos se debe multiplicar la probabilidad por el impacto. Para tal, se debe establecer alguna forma de cuantificación de los factores: probabilidad e impacto.

PFLEEGER [2004] presenta tres abordajes para tratar los riesgos: evitar el riesgo (mitigando su probabilidad de ocurrir); asumir el riesgo (mitigando sus efectos); o transferir el riesgo. Para los riesgos a ser tratados deben ser desarrollados planes de mitigación, que buscan reducir la probabilidad y/o el impacto, y planes de contingencia, que especifican qué hacer cuando el riesgo se vuelve un hecho.

Existen diversas referencias de procesos para gestión de riesgos. BOEHM [1991]

fue uno de los primeros autores a tratar riesgos en proyectos de software y propuso un abordaje para la gestión de riesgos, inspirada en el modelo espiral, también propuesto por él. Él elaboró, con base en una encuesta, una lista de verificación con las diez principales fuentes de riesgos y un proceso compuesto de dos etapas [BOEHM, 1991]: la evaluación y el control de los riesgos. La etapa de evaluación envuelve la identificación (producción de una lista de riesgos), análisis (evaluación de la probabilidad e impacto) y priorización (ordenación) de los riesgos. El control

(24)

engloba la planificación (preparación para tratamiento de los riesgos), resolución (ejecución de acciones de mitigación y contingencia) y supervisión (acompañamiento del proyecto para verificar la resolución de riesgos tomando acciones correctivas cuando necesario).

La norma ISO/IEC 12207 [ISO/IEC, 2008], establece como propósito para el subproceso Gestión de Riesgos “identificar, analizar, tratar y supervisar los riesgos continuamente”. Entre los resultados esperados, establecidos por esta norma están:

la determinación del alcance de la gestión de riesgos; definición e implementación de estrategias apropiadas; identificación, análisis y priorización de los riesgos;

aplicación de medidas para evaluación de los riesgos y de las actividades de tratamiento de los riesgos; y tratamiento para evitar el impacto de los riesgos prioritarios.

El IEEE Std 1540 [IEEE, 2001] también presenta un proceso para gestión de riesgos compuesto de las siguientes actividades: Planificar e Implementar la Gestión de Riesgos, Gestionar Informaciones sobre la Evolución de los Riesgos, Realizar Análisis de los Riesgos, Realizar Supervisión de los Riesgos, Realizar Tratamiento de los Riesgos y Evaluar el Proceso Gestión de Riesgos.

En el PMBOK [PMI, 2008], una de las áreas de conocimiento es la gestión de riesgos, donde son presentados seis procesos asociados: Planificación de la Gestión de Riesgos; Identificación de Riesgos; Análisis Cualitativa de Riesgos; Análisis Cuantitativa de Riesgos; Planificación de Respuesta a Riesgos; y Control y Supervisión de Riesgos.

CARR et al. [1993] presenta seis actividades para gestión de riesgos: identificar;

analizar; planificar; acompañar; controlar; y comunicar. Las actividades son presentadas de forma cíclica para enfatizar que la gestión de riesgos es un proceso continuo, siguiendo un flujo lógico de identificación, análisis, planificación, acompañamiento y control, teniendo la comunicación como un canal para el flujo de informaciones. Presentan, todavia, una forma para realizar la identificación, auxiliada por el uso de un cuestionario basado en una taxonomía. La taxonomía presentada está organizada en tres niveles: clases, elementos y atributos. Las clases sugeridas son: Ingeniería del Producto, Entorno de Desarrollo y Restricciones. Estas clases son compuestas de elementos y estos elementos son compuestos de atributos. En el cuestionario, para cada atributo existe un conjunto de preguntas. Por ejemplo, el atributo “Experiencia de la Gerencia” se refiere al elemento “Proceso de Gerencia”

que integra la clase de “Entorno de Desarrollo”, y en el cuestionario existe una pregunta para evaluar si los gerentes poseen experiencia en desarrollo de software, en gestión de software, en el dominio de la aplicación, en el proceso de desarrollo y en productos de software grandes y complejos, que se refiere al atributo

“Experiencia de la Gerencia”.

El Software Technology Support Center (STSC) [STSC, 2005] propone un proceso compuesto de las actividades de planificación, evaluación (identificación y análisis), tratamiento, supervisión y documentación de riesgos, presentando también una lista de verificación para apoyar la gestión de riesgos.

En [FARIAS, 2002], basado en la literatura y en el resultado de un estudio experimental, es presentada una lista de verificación compuesta por un conjunto de hechos encontrados durante la planificación del proyecto y los riesgos derivados de estos hechos. Es, también, presentado un proceso de gestión de riesgos compuesto de las actividades: identificar riesgos; analizar riesgos; priorizar riesgos; planificar la