DEsaficio De La Red Social

6ta Jornada sobre la Biblioteca Digital Universitaria

JBDU 2008

“Los desafíos de la Web Social”

30 y 31 de octubre de 2008

Universidad Nacional de La Plata, ROBLE Red de Bibliotecas

La Plata, provincia de Buenos Aires, Argentina

Plan de Riesgos para la implementación, desarrollo y

mantenimiento de componentes de Web 2.0 en Bibliotecas,

caso de estudio en una Biblioteca Especializada

Mgter. Lic. Horacio Daniel Kuna ; Asc. Sergio Caballero ; Bibl. Susana Eunice

Jaroszczuk ; Prof. Mirta Miranda

Universidad Nacional de Misiones - Facultad de Humanidades y Ciencias Sociales

Departamento de Bibliotecología

RESUMEN

La era tecnológica y la globalización de la economía, ha traído como consecuencia el

aumento sustancial de los riesgos en general, y en particular en el proceso software. En estos

últimos tiempos la evolución de las aplicaciones tradicionales hacia aplicaciones Web enfocadas

al usuario final que se denomina Web 2.0 y la no administración de los mismos puede implicar

en cualquier Biblioteca la posibilidad del fracaso del mejor proyecto.

La metodología desarrollada en este trabajo es una herramienta que brinda la posibilidad

de efectuar tareas de identificación de riesgos, plan de aversión en base a taxonomías estándar

para la implementación de componentes Web 2.0 en bibliotecas especializadas.

PALABRAS CLAVES: PLAN DE RIESGO, WEB 2.0, GESTIÓN DE RIEGOS,

TAXONOMÍAS (TIPOLOGÍA), BIBLIOTECA, APLICACIÓN INFORMÁTICA.

1. INTRODUCCIÓN

1.1 Riesgo

Un riesgo es una variable del proyecto que pone en peligro o impide el éxito del mismo.

Es la “probabilidad de que un proyecto experimente sucesos no deseables, como retrasos en las

fechas, excesos de costes, o la cancelación directa”1

Se han producido amplios debates sobre la definición adecuada para riesgo de software,

y hay acuerdo común en que el riesgo siempre implica dos características:

 Incertidumbre: el acontecimiento que caracteriza al riesgo puede o no puede ocurrir; por

ejemplo, no hay riesgos de un 100 por ciento de probabilidad.

 Pérdida: Si el riesgo se convierte en una realidad, ocurrirán consecuencias no deseadas o

pérdidas.

Suele ser común el confundir preocupaciones, riesgos y problemas: mientras que una

preocupación es cualquier situación sobre la cual existen dudas en algún determinado contexto

y que, por lo tanto, será evaluada como un posible riesgo, un problema es un riesgo que,

efectivamente, se ha producido (véase Figura 1 - Preocupaciones, Riesgos y Problemas).

Figura 1 Preocupaciones, Riesgos y Problemas

1. 2 Gestión de Riesgos

Un efectivo proceso de gestión de riesgos es un importante componente en todo

proyecto de software exitoso y en el cual la Web 2.0 y sus componentes forman parte del ello;

el principal objetivo de dicho proceso constituye posibilitar tanto al proyecto como a las

organizaciones el cumplimiento de su misión y de sus propósitos.

1 CAPERS, Jones. Assessment and Control of Software Risk, Upper Saddle River, NJ: Prentice-Hall,

1993.

La gestión de riesgos permite definir en forma estructurada, operacional y

organizacional, una serie de actividades para gestionar los riesgos de los proyectos a lo largo de

todas las fases de su ciclo de vida de desarrollo de software. En la mayor parte de los casos, esto

se traduce en la creación de planes tendientes a impedir que los riesgos se transformen en

problemas o a minimizar su probabilidad de ocurrencia o impacto.

1. 3 Propósito del plan de gestión de riesgos

El propósito del plan es identificar los riesgos que se puedan presentar en el desarrollo

del proyecto, analizarlos, calcular la exposición y en base a ello poder priorizarlos, para

establecer estrategias de control y resolución, que permitan ejercer una correcta supervisión de

los mismos.

Es por esta razón que, para que un proyecto de desarrollo pueda llevarse a cabo dentro

de los tiempos establecidos y los costos previstos, los riesgos deben ser identificados y

controlados, es decir se debe realizar un adecuado “Análisis y Gestión de Riesgos”.

Este trabajo pretende ser una herramienta que permita seleccionar e implantar las

medidas o „salvaguardas‟ para conocer, prevenir, impedir, reducir o controlar los riesgos

identificados, y así reducir al mínimo su potencialidad o posibles perjuicios para la

implementación de componentes de Web 2.0 en bibliotecas Especializadas.2

2. METODOLOGIA

2.1 Inventario de activos:

Se deberá analizar los activos que podrían ser amenazados por algún tipo de riesgo,

como ser. Hardware y telecomunicaciones, software y personal.

2.2 Propósitos y Objetivos del análisis de riesgos

En este punto se debe establecer los objetivos generales del análisis de riesgos y

establecer claramente los limites que tendrá el proyecto.

2 MAGERIT. Metodología de Análisis y Gestión de Riesgos de los Sistemas de Información. Madrid :

Consejo Superior de Informática, Ministerio de Administraciones Públicas, 2006.

2.3 Equipo de Trabajo

Establecidos los limites y objetivos del análisis de riesgo se debe formalizar el equipo

de trabajo que realizará la tarea.

2.4 Taxonomía de Riesgos

La clasificación de los riesgos -también denominadas taxonomías de riesgos- puede

servir de ayuda para elaborar un enfoque coherente, reproducible y medible. Las listas de

clasificación permiten al equipo pensar con mayor amplitud sobre los riesgos que pueden

afectar al proyecto dado que se dispone de una lista de áreas del proyecto susceptibles de

esconder riesgos.

Existen muchas taxonomías o clasificaciones para los riesgos de proyectos generales

de desarrollo de software. Para el presente trabajo se ha escogido la clasificación propuesta por

el Software Risk Management (SRM) desarrollado por el Software Engineering Institute. 3

A continuación se presenta la Clasificación de los elementos de la taxonomía del

software4, en el marco del presente proyecto se definen las clase y elementos más importantes y

sus atributos.

3 HIGUERA, Ronald P. y HAIMES, Yacov Y., “Software Risk Management”, Technical Report.

Pittsburgh, Pennsylvania : SEI (Software Engineering Institute) ; Carnegie Mellon University, 1996.

Disponible

...