Facultad 5
“Extensión al Redmine para Identificar Riesgos en Proyectos Productivos de Software”
Trabajo de Diploma para optar por el título de Ingeniero en Ciencias Informáticas.
Autora: Daylen Elena Fonseca Enamorado.
Tutora: Ing. Yanet Nieto Doce.
Ciudad de La Habana.
Junio 2011.
“Solo es útil el conocimiento que nos hace mejores.”
Sócrates
DECLARACIÓN DE AUTORÍA
Declaro ser autora de la presente tesis y autorizo a la Universidad de las Ciencias Informáticas los derechos patrimoniales de la misma, con carácter exclusivo.
Para que así conste firmo la presente a los ____ días del mes de ________ del año ________.
Daylen Elena Fonseca Enamorado Ing. Yanet Nieto Doce
___________________ ___________________
Firma de la Autora Firma de la Tutora
Tutora:
Nombres y Apellidos: Yanet Nieto Doce.
Institución: Universidad de las Ciencias Informáticas (UCI).
E-mail: [email protected]
Ingeniera en Ciencias Informáticas, graduada en la UCI en el año 2009. Con 2 años de experiencia en su desempeño laboral, se ha desarrollado como profesora en adiestramiento en el Centro de Informática Industrial (CEDIN) perteneciente a la Facultad 5. Líder del proyecto SCADA Meteorología.
Agradecimientos
Ser agradecido es una de las cualidades más hermosas del ser humano; sin embargo, este momento es de gran dificultad, pues no deseo dejar a nadie fuera. Es por ello que al finalizar este trabajo dirijo todo mi agradecimiento a aquellas personas que de un modo u otro hicieron suyo mi empeño por concluir los estudios, especialmente a:
A mis padres queridos: que han sido las personas que han estado a mi lado desde que nací, compartiendo mis alegrías y mis tristezas. Muchas gracias por su amor, su paciencia, su apoyo incondicional, su preocupación, por depositar su confianza en mí y por aportar tanto a mi carácter y a mi educación.
A Adrián: por todo el trabajo que realizó para ayudarme a terminar este trabajo.
A mi tutora Yanet Nieto: por sus consejos y su asesoría.
A mi tía Esther Rivera: por su cariño infinito hacia mí.
A mi amiga Annia: por brindarme su amistad durante estos años.
A la Universidad de las Ciencias Informáticas: por ser mi hogar durante estos 5 largos años.
Elenita.
Dedicatoria
Dedico este trabajo a mis padres y a la memoria de mi abuelita Elena, que aunque no está presente físicamente, su recuerdo siempre está conmigo.
Elenita.
Resumen
Un riesgo es un evento que puede incidir de forma negativa en el futuro de un proyecto, está presente en todo cambio y en cada decisión, implica elección e incertidumbre. Gestionar los riesgos implica identificarlos, analizarlos, y realizar un plan al que se le debe dar seguimiento para controlar estas amenazas y eliminar las fuentes de riesgo antes de que empiecen a afectar el cumplimiento de los objetivos del proyecto.
En los proyectos productivos de la Universidad de las Ciencias Informáticas la Gestión de Riesgos habitualmente no se realiza con todo el rigor que requiere, lo que implica que algunos proyectos presenten problemas durante su desarrollo, por no tenerse en cuenta la mayor cantidad de riesgos, de acuerdo con las características del sistema que se va a desarrollar. Por tal razón se hace necesaria la implementación de una herramienta que ofrezca solucionar estas inconveniencias.
Esta investigación tiene como principal objetivo, desarrollar una aplicación, que adjunta al gestor de proyectos Redmine, automatice el proceso de Identificación de Riesgos.
Siguiendo esta meta se obtuvo como resultado una extensión a la aplicación web Redmine, que integra el proceso anteriormente mencionado y que cumple con los objetivos trazados al inicio de su confección.
Palabras clave: Identificación, Redmine, extensión, riesgo.
Índice
DECLARACIÓN DE AUTORÍA ... I DATOS DE CONTACTO ... II Agradecimientos ... III Dedicatoria ... IV Resumen ... V Índice ... VI
Introducción ... 1
Capítulo 1: Fundamentación Teórica. ... 4
1.1 Introducción. ... 4
1.2 Concepto de Riesgo. ... 4
1.3 Gestión de Riesgos. ... 4
1.3.1 Técnicas de Identificación de Riesgos. ... 7
1.4 Herramientas existentes a nivel mundial para la identificación de riesgos. ... 10
1.4.1 Herramientas existentes en la UCI para la identificación de riesgos. ... 11
1.5 Herramientas y tecnologías a utilizar para el desarrollo. ... 12
1.5.1 Lenguaje de desarrollo: Ruby. ... 12
1.5.2 Framework: Rail. ... 13
1.5.3 Lenguaje de modelado Unificado... 14
1.5.4 Herramienta para el diseño del software: Visual Paradigm for UML. ... 14
1.5.5 Sistema Operativo: GNU/Linux. ... 14
1.5.6 Herramienta de Gestión de Proyectos: Redmine. ... 15
1.5.7 Sistema Gestor de Base de Datos (SGBD): PostgreSQL. ... 16
1.5.8 Servidor Web: Apache. ... 16
1.5.9 Metodología de desarrollo de Software: Open UP. ... 16
1.5.10 Entorno de Desarrollo Integrado (IDE): NetBeans 6.8 ... 17
1.6 Conclusiones Parciales. ... 17
Capítulo 2: Características y Diseño de la Propuesta. ... 18
2.1 Introducción. ... 18
2.2 Visión del Sistema. ... 18
2.3 Selección de la propuesta. ... 18
2.3.1 Propuesta aplicada a la extensión del Redmine. ... 20
2.4 Requisitos de la herramienta. ... 20
2.4.1 Requisitos Funcionales. ... 21
2.4.2 Requisitos no funcionales. ... 22
2.5 Descripción del sistema. ... 23
2.5.1 Actores del sistema. ... 23
2.5.2 Modelo de Casos de Uso (CU). ... 24
2.7 Arquitectura de la extensión al Redmine. ... 26
2.8 Modelo de Diseño. ... 27
2.8.1 Diagrama de clases del diseño del CU Gestionar Respuesta. ... 27
2.8.1 Diagrama de clases del diseño del CU Gestionar Riesgos. ... 28
2.8.2 Modelo de datos. ... 29
2.9 Patrones Utilizados. ... 30
2.9.1 Patrones Generales de Software para la Asignación de Responsabilidades (GRASP)... 30
2.9.2 Patrones de Caso de Uso: CRUD completo. ... 30
2.9.3 Patrón de Arquitectura: Modelo-Vista-Controlador. ... 30
2.9.4 Patrones de Diseño. ... 31
2.10 Conclusiones parciales. ... 31
Capítulo 3: Implementación y Pruebas de la Propuesta. ... 32
3.1 Introducción ... 32
3.2 Implementación del sistema... 32
3.2.1 Diagrama de Despliegue. ... 32
3.2.2 Diagramas de Componentes. ... 33
3.3 Pruebas del Sistema. ... 34
3.3.1 Plan de Pruebas. ... 35
3.3.2 Diseño de Casos de Pruebas. ... 36
3.3.3 Resumen del proceso de pruebas. ... 40
3.4 ¿Cómo adjuntar al gestor de proyectos Redmine la herramienta implementada? ... 40
3.5 Conclusiones Parciales. ... 40
Conclusiones Generales ... 41
Recomendaciones ... 42
Referencias Bibliográficas ... 43
Bibliografía... 44
Acrónimos... 48
Anexos ... 49
Anexo 1. Entrevistas. ... 49
Anexo 1.1 Entrevistas a Jefes de Proyectos. ... 49
Anexo 1.2 Entrevista concedida por el Ingeniero Manuel Vázquez Acosta (Jefe de la Dirección Técnica e Infraestructura Productiva). ... 49
Anexo 2. Cuestionario de Riesgos. ... 51
Anexo 3. Descripción del CU Gestionar Respuesta. ... 58
Anexo 4. Descripción del CU Gestionar Riesgos. ... 60
Anexo 5. Descripción del CU Gestionar Pregunta. ... 62
Anexo 6. Descripción del CU Gestionar Categoría de preguntas. ... 66
Anexo 8. Diagrama de Componentes del CU Gestionar Categorías de pregunta. ... 69 Anexo 9. Diagrama de Componentes del CU Realizar Cuestionario y Acceder a listados de riesgos. ... 69
Introducción
Desde sus inicios la Universidad de las Ciencias Informáticas (UCI) se ha caracterizado por ser un centro de altos estudios en el cual los estudiantes vinculan la docencia y la producción de software.
En este último aspecto la universidad ha logrado un gran desarrollo, creando muy buena opinión entre sus clientes por la calidad y la eficiencia de los productos desarrollados.
Actualmente la UCI se encuentra representada por varios centros productivos, cada uno con características distintas pero con una meta en común: Hacer todo lo posible porque nuestro país y la universidad continúen avanzando en la Industria de Desarrollo de Software.
Para tener un mayor control de los proyectos que se están desarrollando se decidió utilizar el Redmine, una herramienta con la cual se interactúa a través de la web.
El Redmine es una herramienta fácil de utilizar, con grandes perspectivas en el mundo de la gestión de proyectos, la misma, aún está en una fase temprana de su desarrollo y carece de funcionalidades importantes, no es capaz de realizar la automatización del proceso de identificación de los riesgos.
Por tanto, la situación problémica es la siguiente: como los jefes de proyectos son los encargados de introducir en el Redmine los riesgos que ellos consideren pueden afectar el desarrollo del software; puede que queden algunos sin tener en cuenta por diversas causas, entre ellas que no utilizan eficientemente las técnicas de identificación de riesgos. Por tal razón la mayoría de las veces los proyectos presentan problemas con la calidad o demora en el tiempo de entrega del mismo, al no tenerse en cuenta la mayor cantidad de riesgos predecibles.
Los riesgos deben ser analizados y no siempre se hace con todo el rigor que requieren, por tal razón la UCI presenta la necesidad de disponer de una herramienta que adjunta a la herramienta de gestión de proyectos Redmine, permita una correcta identificación de riesgos, para la detección de las incertidumbres que pudiesen afrontar cada uno de los proyectos.
Teniendo en cuenta lo anteriormente descrito, se puede llegar al siguiente problema científico:
“¿Cómo la identificación de riesgos durante el ciclo de vida del software incide en su calidad final?”
El problema científico se ubica en el siguiente objeto de estudio: “Identificación de riesgos en el desarrollo de un software”.
Para solucionar el problema científico se plantea el siguiente objetivo general: Desarrollar una extensión al Redmine capaz de identificar riesgos durante el ciclo de vida de los proyectos productivos.
Por lo que el campo de acción es: “Técnicas para identificar riesgos en los proyectos de desarrollo de software.”
Para darle cumplimiento al objetivo planteado se hace necesario realizar las siguientes tareas investigativas:
1- Elaboración del marco teórico de la investigación, a partir del estado del arte que actualmente existe sobre el tema.
2- Selección de la técnica de identificación de riesgos que se aplicará en la herramienta.
3-Descripción de los requisitos del sistema para caracterizar las funcionalidades de la aplicación.
4-Descripción de los casos de uso para guiar el desarrollo del sistema.
5-Elaboración de una propuesta de diseño como base para la implementación de la aplicación.
6-Implementación de la extensión al Redmine.
7-Realización de pruebas para identificar y corregir los errores de la extensión desarrollada.
La idea a defender que guiará la investigación es:
“El desarrollo de la herramienta que se elaborará será capaz de identificar riesgos y contribuirá a la toma de decisiones en la Gestión de Riesgos.”
Para el desarrollo de la presente investigación se combinan los siguientes Métodos y Técnicas en la búsqueda y procesamiento de la información, los principales son:
Dentro de los Métodos Empíricos:
Consulta en las fuentes de información: que permita la elaboración del marco teórico de la investigación.
La entrevista: para obtener información de los principales riesgos que están presentes en el desarrollo de un software y así completar la fundamentación teórica. Además se realizarán algunas conversaciones con los jefes de los proyecto.
Dentro de los Métodos Teóricos:
Método de Modelación: con el objetivo de representar las funcionalidades que tendrá la extensión, cumpliendo con un determinado nivel de similitud estructural y funcional con la realidad de dicha herramienta. Es decir, a través de un prototipo no funcional representar lo que en realidad se quiere desarrollar.
Método Analítico-sintético: para analizar las teorías, referente a la Gestión de Riesgos, con el objetivo de extraer los elementos más significativos que se relacionan con este proceso, posibilitando una mayor capacidad de comprensión y de síntesis sobre los aspectos más importantes.
Método histórico-lógico: para conocer los antecedentes y las tendencias actuales referidas a la Gestión de Riesgos, se constatará teóricamente cómo ha evolucionado la toma de decisiones, ante una inminente probabilidad de materialización de determinados riesgos en un período de tiempo, en toda su trayectoria o en un fragmento temporal de la lógica de su desarrollo.
El presente trabajo de diploma está estructurado de la siguiente manera: resumen, introducción, tres capítulos de contenido, conclusiones, recomendaciones, referencias bibliográficas, bibliografía, glosario de términos y anexos.
En el Capítulo 1 Fundamentación Teórica. Se realiza un estudio sobre los principales conceptos desarrollados en la investigación (riesgo, Gestión de Riesgos, técnicas de identificación de riesgos).
Además se muestra algunas herramientas para la identificación de riesgos y se hace referencia a las herramientas y tecnologías utilizadas para el desarrollo de la aplicación.
En el Capítulo 2 Características y Diseño de la Propuesta. Se expone una visión del sistema, se explica el alcance de la herramienta que se va a desarrollar y se da a conocer la técnica de identificación de riesgos que se usará en el sistema. Además se describen los diferentes diagramas que mostrarán el funcionamiento de la aplicación.
Por último en el Capítulo 3 Implementación y Pruebas de la Propuesta. Se modela el diagrama de despliegue del sistema y se presenta el diseño de casos de pruebas que evaluarán el comportamiento de la extensión para el Redmine.
Capítulo 1: Fundamentación Teórica.
1.1 Introducción.
En el presente capítulo se abordan los conceptos riesgo y gestión de riesgos; en este último caso se explican las fases porque está conformado este proceso, enfocándonos fundamentalmente en la identificación. Además se mencionan las herramientas para la identificación de riesgos utilizadas en el mundo y en la UCI, mientras se hace un análisis de las técnicas para identificación de riesgos existentes en la actualidad y se explican las herramientas y tecnologías que se utilizarán para el desarrollo de la aplicación.
1.2 Concepto de Riesgo.
Para definir el término riesgo se ha hecho referencia a diferentes denominaciones realizadas por distintos autores:
Posibilidad de que un evento adverso, desgracia o contratiempo pueda manifestarse produciendo una pérdida. (1)
Evento o condición incierta que, en caso de ocurrir, tiene un efecto positivo o negativo sobre los objetivos de un proyecto. (2)
Posibilidad de sufrir una pérdida. (3)
Denota incertidumbre asociada a un evento futuro o a un evento supuesto. (4) Contingencia o proximidad de un daño o peligro. (5)
La palabra riesgo se utiliza para definir la posibilidad de una situación que puede causar algún daño y que involucra incertidumbre. La buena prevención de un riesgo puede determinar su ocurrencia o no.
Es muy importante aclarar que riesgo no significa daño, sino la probabilidad de que este ocurra. La idea central del enfoque de riesgo es centrarse en su prevención una vez que este haya sido detectado.
1.3 Gestión de Riesgos.
Plantea que la Gestión de Riesgos (GR) del software es identificar, estudiar y eliminar las fuentes de riesgos antes de que comiencen a amenazar la finalización satisfactoria de un proyecto de software.
(2)
La GR es la práctica compuesta de procesos, métodos y herramientas que posibilita la gestión de los riesgos en un proyecto y que provee un entorno disciplinado para la toma de decisiones proactiva en base a determinar constantemente qué puede ir mal, identificar cuáles son los riesgos más importantes en los cuales enfocarse e implementar estrategias para gestionarlos. (3)
Existen varios modelos para gestionar los riesgos. El más general consta de cinco fases:
identificación, análisis, planificación, seguimiento y control de los riesgos (Ver Figura 1).
Fig. 1 Gestión de Riesgos
Identificación de riesgos.
La identificación de riesgos se basa en encontrar los riesgos que pueden surgir a lo largo del ciclo de vida de un proyecto. Inicialmente se identifican los riesgos provocados por fuentes externas, es decir que no esté bajo la responsabilidad del equipo de desarrollo (riesgos de comunicaciones, tecnología, riesgos de presupuesto, riesgos de personal).
Después se identifican los riesgos de fuente interna, es decir, los que pueden afectar el entorno de desarrollo y que pueden presentarse en el proyecto. Cada uno de estos riesgos es almacenado en el Registro de Riesgos (RR) para su posterior análisis, planificación, seguimiento y control. El RR se utiliza además para comunicar estos riesgos al equipo de desarrollo.
Análisis de los riesgos.
Para analizar un riesgo es necesario tener en cuenta la probabilidad de que éste ocurra y el impacto que traerá en el proyecto. Por tanto surge la necesidad de ordenar estos riesgos, en correspondencia
con la probabilidad de afectaciones y el impacto. La probabilidad puede ser alta, media o baja y el impacto catastrófico, muy importante o leve.
Se considera cada riesgo por separado y se valora su probabilidad e impacto. Luego se refleja el resultado en el RR, en los campos de impacto, probabilidad y prioridad. Serán ordenados teniendo en cuenta su prioridad, la cual dependerá de su efecto, es decir, aquellos de consecuencias catastróficas tienen mayor prioridad y así sucesivamente para las demás clasificaciones.
Además se utiliza una matriz de prioridad para las probabilidades con el nivel de impacto de cada uno de los riesgos identificados, asignándole la prioridad según corresponda (Ver Figura 2).
Fig.2 Matriz de Probabilidad e Impacto.
Planificación de las respuestas a los riesgos.
En esta etapa del proceso se crean los planes de contingencia y mitigación para enfrentar los riesgos que han sido identificados y analizados anteriormente. Se le da prioridad a los riesgos más significativos, pero sin dejar a un lado los que no ofrezcan grandes peligros, pues a pesar de ser menos significativos siempre existe la posibilidad de que inicialmente sea leve y en fases posteriores sea crítico.
Es muy importante llevar a cabo acciones para eliminar la probabilidad de que el riesgo se materialice y reducir el impacto de los riesgos identificados.
Seguimiento y control de riesgos.
Estos dos procesos permiten que no se quede pendiente ningún riesgo (sin tener en cuenta su prioridad). En estas etapas se le realiza un monitoreo al comportamiento de cada uno de los riesgos, buscando indicadores que impliquen cambios en su probabilidad o impacto. Además controlan las acciones planificadas y el cumplimiento de los planes de mitigación y contingencia.
De las cinco etapas estudiadas anteriormente, la herramienta que se desea construir se centrará específicamente en el proceso de Identificación de Riesgos, para de esta forma darle cumplimiento al objetivo general planteado al inicio de la investigación
1.3.1 Técnicas de Identificación de Riesgos.
Existen varias técnicas conocidas para identificar riesgos en proyectos, a continuación se mencionan y describen las más conocidas.
Tormenta de Ideas.
Técnica de Delphi.
Cuestionario basado en taxonomía.
Listas de Comprobación.
Experiencia del Personal.
Tormenta de Ideas.
Esta técnica consiste en reunir a un grupo de expertos, proveedores, miembros del equipo u otros involucrados del proyecto y pedirle que identifiquen los riesgos que pueden surgir en el desarrollo del proyecto. Todos estos riesgos son anotados en un lugar visible. Luego se filtran todas estas ideas con el consenso de los participantes.
Esta es una de las técnicas que más se utiliza, generalmente se usa cuando en el equipo de trabajo no hay un experto en el tema, o al menos alguien que lo domine lo suficiente para ser capaz de exponerlo delante de los demás.
Técnica Delphi.
Es muy parecida a la Tormenta de Ideas, solo que no se realiza de forma presencial. Con esta técnica se mantiene el anonimato de la gente que participa en ella para evitar que los más expertos inhiban las contribuciones de los que tienen menos experiencia en el tema, en general, para que no influyan unos sobre otros. Cada participante contribuye con ideas a un moderador (persona que se encarga de coordinar las ideas), estas ideas generalmente son anónimas, por ejemplo cargándolas
en un sitio web, fórum, etc. El moderador sintetiza, asocia y edita las ideas obtenidas, y devuelve a los participantes un resumen de estas. Generalmente se hacen varias iteraciones.
Cuestionario basado en taxonomía.
Taxonomía es “un esquema que produce particiones en un cuerpo de conocimiento y define las relaciones entre sus partes. Se utiliza para clasificar y entender el cuerpo de conocimiento”. (6) En otras palabras es la ciencia que se encarga de la clasificación, en este caso a partir de las características de desarrollo de software.
El cuestionario basado en taxonomía consiste en aplicarle una encuesta a un grupo de desarrollo de software. La encuesta contiene preguntas respecto a distintas áreas de desarrollo y permite la identificación de riesgos de una forma muy abarcadora, además identifica la causa que le dio origen al riesgo.
La identificación de riesgos utilizando taxonomía se divide en tres fases, cada una de ellas con diferentes pasos a seguir (7):
Fase #1 Parametrización:
1- Seleccionar una taxonomía base: Es decir elegir algunas de las taxonomías de riesgos existentes en la industria para diferentes áreas de conocimientos.
2- Seleccionar una clasificación de tipos de proyectos: Se refiere a seleccionar un tipo de proyecto de los existentes en la industria para el área de conocimiento en que se trabaje.
3- Generación de una taxonomía ajustada de riesgos: Este paso toma como elementos la taxonomía base y la clasificación de tipos de proyectos, seleccionadas anteriormente y produce como resultado una modificación en la taxonomía base, para cada tipo de proyecto y cada riesgo se obtendrá información sobre el grado de exposición a que se espera estén dichos proyectos.
4- Generación de reglas de identificación de riesgos: En este paso se identifican y generan un conjunto de reglas que reflejan relaciones causales, de forma tal, que la presencia de un riesgo incluye la probabilidad de que ocurra otro u otros.
Fase #2 Ejecución:
1- Especificación de las características del proyecto: Implica determinar varias evaluaciones en distintos aspectos que definirán al proyecto que se desea evaluar (tipo, existencia de organización,
cliente y entorno organizacional, por ejemplo), de manera que se determine un primer grupo de riesgos en base a los criterios de aplicabilidad definidos previamente.
2- Ejecución de las reglas de identificación de riesgos: Se ejecutan las reglas para identificar riesgos, definidas en la fase anterior.
3- Respuestas del gestor de proyectos a consultas sobre riesgos: Respuestas que da el gestor de proyectos para todos aquellos riesgos para los cuales no es factible aún fijar un valor de exposición.
4- Presentación de los riesgos identificados: Listar todos los riesgos que sean aplicables al proyecto con el valor de exposición determinado a lo largo de la fase de Ejecución.
Fase #3 Seguimiento:
1- Monitoreo de los riesgos identificados: Implica validar si los riesgos seleccionados para el proyecto son los correctos.
2- Detección de oportunidades de mejora: para realizar ajustes, agregados y correcciones que mejorarán el uso de este plan.
Listas de Comprobación.
Las listas de comprobación se utilizan para identificar riesgos y se enfocan en un subconjunto de riesgos conocidos y predecibles en las siguientes categorías genéricas. (1)
Tamaño del producto: riesgos asociados con el tamaño general del software a construir o a modificar.
Impacto en el negocio: riesgos asociados con las limitaciones impuestas por la gestión o por el mercado.
Características del cliente: riesgos asociados con la sofisticación del cliente y la habilidad del desarrollador para comunicarse con el cliente en los momentos oportunos.
Definición del proceso: riesgos asociados con el grado de definición del proceso del software y su seguimiento por la organización de desarrollo.
Entorno de desarrollo: riesgos asociados con la disponibilidad y calidad de las herramientas que se van a emplear en la construcción del producto.
Tecnología a construir: riesgos asociados con la complejidad del sistema a construir y la tecnología que contiene el mismo.
Tamaño y experiencia de la plantilla: riesgos asociados con la experiencia técnica y de proyectos de los ingenieros del software que van a realizar el trabajo.
Las listas de comprobación pueden organizarse de diferentes maneras. Se pueden obtener respuestas relevantes de cada uno de los temas apuntados anteriormente para cada proyecto de software, las que pueden ayudar al planificador del proyecto a estimar el impacto del riesgo.
Experiencia del Personal.
Esta técnica consiste en definir los posibles riesgos que pueden afectar el desarrollo del software, basándose específicamente en las experiencias adquiridas por el equipo de trabajo, tomando como referencia proyectos en los que hayan trabajado anteriormente. Esta información se obtiene tanto de manera formal, como informal.
1.4 Herramientas existentes a nivel mundial para la identificación de riesgos.
Active Risk Manager (ARM): Su proveedor es Strategic Thought. Es una herramienta integrada de Administración de Riesgos, que ofrece una solución para la Identificación de Riesgos mediante la utilización de la información contenida en la Estructura desglosada de trabajo o WBS de proyecto.
Con ARM todas las categorías de riesgo son enfrentadas. Incluye una función de simulación para calcular los riesgos, una de las principales razones por la que muchas empresas la utilizan. ARM permite la identificación, registro, comunicación, análisis y gestión de riesgos y oportunidades.
ARM tiene las siguientes funcionalidades:
Identificación de Riesgos: identificación de todos los posibles riesgos en el Registro de Riesgos ARM.
Evaluación de Riesgos: evaluación de la severidad de cada riesgo usando tanto un enfoque cualitativo como cuantitativo.
Mitigación de Riesgos: implanta planes de mitigación y respuestas para evitar riesgos o reducir sus posibles impactos.
Análisis de Riesgos: luego de tomar el riesgo en consideración realiza el cálculo del costo pronosticado del proyecto.
SCRAM99: Es un software propietario que permite evaluar el nivel del calendario y los riesgos de costo de un proyecto, identificando las áreas del proyecto que se beneficiarían con una mayor atención de gestión. Identifica además las tendencias de riesgos con el propósito de prevenir los
problemas antes de que se produzcan. También establece y mantiene el plan de contingencia y analiza sus posibles repercusiones. (8)
WelcomRisk: Su proveedor es Welcom. Es una herramienta integrada de Administración de Riesgos que brinda una solución para la Identificación de Riesgos, utilizando bibliotecas configurables de categorías de riesgos. Posee estrictas medidas de seguridad y una interfaz de fácil manejo con un gran nivel de flexibilidad. Permite identificar, clasificar y realizar un seguimiento de los riesgos en todo el ciclo de vida del proyecto.
WelcomRisk permite crear un marco de planificación de riesgos, mitiga los riesgos, elabora un registro de riesgos, y además realiza un informe sobre la organización y los riesgos del proyecto.
1.4.1 Herramientas existentes en la UCI para la identificación de riesgos.
En la UCI ya se han dado los primeros pasos para lograr la identificación de riesgos en proyectos de desarrollo de software. A continuación se mencionan algunos de los trabajos realizados:
Herramienta para la identificación de riesgos de proyectos productivos: Trabajo de diploma desarrollado por la Facultad 5 en el curso 2008-2009. Dentro de las 5 fases de la GR se centra específicamente en la primera etapa (Identificación). Actualmente esta herramienta no se usa pues fue implementada para usarse adjunta al TRAC, gestor de proyectos que actualmente no se utiliza en la UCI.
Estrategia para la Gestión de Riesgos: Software desarrollado por la Facultad 8, el cual utiliza la herramienta TRAC para la publicación de la documentación generada. Este sistema promovió la idea de crear un área para la gestión de riesgos dentro del TRAC, y las tareas a realizar en ella se describirían en el sistema de tickets que contiene el propio gestor de proyectos.
Análisis y Gestión de Riesgos: Desarrollado en la Facultad 2, apoya el proceso de gestión de la seguridad informática y posibilita la correcta gestión de los riesgos sobre los activos y bienes informáticos de una organización en cada una de sus áreas de desarrollo o dominios, aplicaciones en desarrollo, etc. Ofrece además indicaciones necesarias u orientaciones objetivas acerca de qué hacer ante los riesgos y cómo enfrentarlos.
Fig 3. Sistema de Análisis y Gestión de Riesgos.
Las herramientas mencionadas y descritas anteriormente ofrecen gran ayuda a la hora de gestionar los riesgos de un proyecto, pero son muy pocas las que se especializan en la identificación de estos riesgos. Por otra parte todas son propietarias u ofrecen servicios para una empresa determinada.
Además la mayoría proponen técnicas que no son muy satisfactorias para realizar la identificación de riesgos.
En la UCI se ha tratado de abordar el tema de la GR a través de distintos trabajos de diploma, los cuales fueron descritos anteriormente pero se puede concluir que todas ofrecen gran ayuda para la identificación de riesgos en la universidad, pero ninguna se puede adjuntar al Redmine, actual gestor de proyectos de la universidad. Es necesaria una aplicación capaz de identificar las incertidumbres que pueden surgir a lo largo del ciclo de vida de un proyecto de desarrollo de software.
1.5 Herramientas y tecnologías a utilizar para el desarrollo.
Para el desarrollo de la presente aplicación se escogieron una serie de herramientas y tecnologías, las cuales son la base para obtener una buena calidad, además se tuvieron en cuenta pues la mayoría de ellas fueron utilizadas para desarrollar la herramienta Redmine.
1.5.1 Lenguaje de desarrollo: Ruby.
Fue creado por Yukihiro Matsumoto. Fue presentado al público en el año 1995. Es una mezcla de los lenguajes de programación Perl, Smalltalk, Eiffel, Ada, y Lisp.
Características generales del lenguaje (9):
Orientado a objetos.
Cuatro niveles de ámbito de variable: global, clase, instancia y local.
Manejo de excepciones.
Expresiones regulares nativas similares a las de Perl a nivel del lenguaje.
Posibilidad de redefinir los operadores (sobrecarga de operadores).
Altamente portable.
Hilos de ejecución simultáneos en todas las plataformas.
Carga dinámica de DLL/bibliotecas compartidas en la mayoría de las plataformas.
Amplia librería estándar.
Soporta inyección de dependencias.
Soporta alteración de objetos en tiempo de ejecución.
Continuaciones y generadores.
Fue escogido este lenguaje para desarrollar la extensión porque además de las ventajas que se comentaron anteriormente, el Redmine fue implementado en Ruby y todo nuevo componente que se le desee agregar deberá estar desarrollado en el mismo lenguaje.
1.5.2 Framework: Rail.
Es un framework para el desarrollo de aplicaciones web. Se basa en la arquitectura Modelo-Vista- Controlador (MVC).
Sigue dos principios básicos:
Convención sobre la configuración: Con Rails, en lugar de archivos de configuración se utilizan una serie de convenciones. Es decir que no es necesario configurar la aplicación en un archivo XML (por ejemplo), basta con utilizar una convención que sustituya la configuración.
Ejemplo: Se tienen varias clases pero solo una parte de ellas son persistentes. Se debería configurar en un archivo XML las clases que persisten. En Rails para usar convención se define un prefijo (“CP” por ejemplo), de forma tal que la clase persistente de productos se nombra “CPProductos”. De esta forma Rails asume que las clases que contienen ese prefijo son clases persistentes.
Menos software: Se refiere a que se escribe menos líneas de código, lo que trae consigo más rapidez y menos errores en la implementación.
1.5.3 Lenguaje de modelado Unificado.
El lenguaje de modelado unificado (UML) sirve para especificar, visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino que ayuda a visualizar el diseño y a hacerlo más accesible para otros.
UML está controlado por el grupo de administración de objetos (OMG) y es el estándar de descripción de esquemas de software. (10)
Fue escogido para desarrollar el modelado de la aplicación porque brinda facilidades para describir los métodos del sistema que se va a desarrollar.
1.5.4 Herramienta para el diseño del software: Visual Paradigm for UML.
Visual Paradigm es una herramienta UML profesional que soporta el ciclo de vida completo del desarrollo de software: análisis y diseño orientados a objetos, construcción, pruebas y despliegue.
Permite dibujar todos los tipos de diagramas de clases, código inverso, generar código desde diagramas y generar documentación. Proporciona además abundantes tutoriales de UML, demostraciones interactivas de UML y proyectos UML. (11)
Visual Paradigm para UML permite además realizar ingeniería inversa, es decir, de código a modelo y de código a diagrama.
Permite la especificación de los detalles de los casos de uso, incluyendo la especificación del modelo general y de las descripciones de los casos de uso.
También ofrece la posibilidad de generar bases de datos pues transforma diagramas de Entidad- Relación en tablas de base de datos.
1.5.5 Sistema Operativo: GNU/Linux.
GNU/Linux es un sistema operativo compatible con Unix. Es muy accesible gracias a que es libre, esto significa que no debemos abonar ningún tipo de licencia a alguna empresa que desarrolle el software por su uso. Está acompañado por el código fuente, es decir, que puede ser modificado por cualquier individuo.
Este sistema operativo es multitarea, multiusuario y además ofrece independencia de dispositivos y comunicaciones.
Fue seleccionado porque el servidor de la UCI donde actualmente se encuentra instalado el Redmine (herramienta a la que se le va a desarrollar la extensión), se encuentra administrado en este Sistema Operativo.
1.5.5.1 Distribución: Ubuntu 10.04.
Ubuntu es una distribución de GNU/Linux, basada en Debian GNU/Linux, ofrece un sistema operativo enfocado a ordenadores de escritorio y proporciona soporte para servidores. Al igual que otras distribuciones, está compuesta por paquetes de software distribuidos bajo una licencia libre.
El sistema posee funciones avanzadas de seguridad, además incluye entre sus políticas: no activar de forma predeterminada, procesos latentes al momento de instalarse. Por tal razón, no hay un firewall predeterminado pues no existen servicios que puedan atentar a la seguridad del sistema.
Fue seleccionada esta distribución pues es compatible con la distribución sobre la cual se encuentra instalado el gestor de proyectos Redmine.
1.5.6 Herramienta de Gestión de Proyectos: Redmine.
El Redmine es una herramienta que soporta múltiples proyectos simultáneamente, posee una interfaz fácil de utilizar y permite la creación de una wiki por proyecto. Tiene campos ajustados a cada proyecto, cada usuario, ventana de tiempo, etc. Permite el auto-registro de usuarios y la creación de tareas vía correo electrónico, además de que soporta múltiples bases de datos.
El Redmine fue diseñado con una arquitectura que permite adjuntar extensiones con facilidad, además permite tener un mayor control sobre el equipo de trabajo de cada uno de los proyectos que gestiona y facilita el seguimiento de las tareas (tiempo empleado para realizarla, evaluación, por ciento realizado hasta el momento, etc.) pues posee elementos que agilizan este trabajo, estos son:
Vistazo: Ofrece una visión general del proyecto.
Wiki: Permite crear documentación.
Repositorio: Accede a conectarse a un repositorio de código.
Mi página: Permite ver todo lo relacionado con nuestras tareas pendientes, las que hemos asignado, calendario, etc.
Configuración del proyecto: Permite personalizar los proyectos con campos específicos y otros temas.
Roadmap: Permite ver el avance del proyecto y el porciento que falta para finalizar un hito o versión.
Peticiones: Son las partes de trabajo, ejemplo: tareas, errores, mejoras, etc. Estas partes son asignadas a personas y se puede seguir su evolución, tiempo dedicado, comentarios, evaluación, porciento realizado, etc.
Noticias del proyecto: Permite gestionar noticias relacionadas con el proyecto.
Documentos: Permite gestionar la documentación del proyecto.
1.5.7 Sistema Gestor de Base de Datos (SGBD): PostgreSQL.
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional (ORDBMS) basado en el proyecto POSTGRES, de la universidad de Berkeley. El director de este proyecto es el profesor Michael Stonebraker. Es una derivación libre (OpenSource) de este proyecto, y utiliza el lenguaje SQL92/SQL99. (12)
PostgreSQL se incluye entre los gestores objeto-relacionales pues permite la herencia entre tablas (aunque no entre objetos). Además soporta distintos tipos de datos (datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP...), cadenas de bits, etc.).
1.5.8 Servidor Web: Apache.
Un servidor web es un programa que se ejecuta constantemente en un computador y se mantiene a la espera de peticiones de ejecución que le hará un cliente o un usuario. El servidor web se encarga de contestar a estas peticiones de forma adecuada, entregando como resultado una página web o información de todo tipo de acuerdo a los comandos solicitados.
Apache es un Servidor web flexible, rápido y eficiente, estable y continuamente actualizado. Es uno de los servidores web más potentes del mercado a pesar de su sencillez.
Por todas las características mencionadas anteriormente y por ser el servidor con el que trabaja el Gestor de Proyectos Redmine, fue seleccionado para conectar el sistema que se va a desarrollar.
1.5.9 Metodología de desarrollo de Software: Open UP.
La metodología Open UP (Proceso Unificado Abierto), es un proceso unificado que utiliza propuestas de gestión ágiles, que tratan de ser manejables en relación con el Rational Unified Process (RUP), pues mantiene sus características esenciales: centrado en la arquitectura, dirigido por casos de uso y desarrollo iterativo e incremental dentro del ciclo de vida.
Open-Up se centra en una arquitectura temprana para reducir al mínimo los riesgos y organizar el desarrollo. (13)
Se propone para desarrollar la ingeniería porque es un proceso de desarrollo de software completo (plantea los pasos esenciales para la construcción de software), es extensible, es decir, se puede agregar o adaptar según lo vayan a necesitar los sistemas, es ágil, ligera y proporciona una comprensión detallada del proyecto; esta última característica beneficia a los clientes y desarrolladores sobre productos a entregar y su formalidad.
1.5.10 Entorno de Desarrollo Integrado (IDE): NetBeans 6.8
NetBeans es un entorno de desarrollo de código abierto. Favorece el desarrollo de aplicaciones multiplataforma. Además este IDE realiza la programación a través de componentes de software modulares, también llamados módulos.
Se escoge como IDE para desarrollar esta herramienta pues es un software libre y ha sido utilizado por una gran cantidad de desarrolladores. También brinda facilidades para el desarrollo de aplicaciones en Ruby on Rails 2.3.5, y posibilita desarrollar aplicaciones con el SGBD PostgreSQL 8.4.
1.6 Conclusiones Parciales.
En este capítulo se realizó un análisis del proceso de gestión de riesgos, enfocándonos principalmente en sus conceptos y características. También se abordaron las tendencias actuales referentes al tema, es decir, las herramientas usadas mundialmente, y las técnicas para identificar riesgos más utilizadas. Lo que permitió seleccionar las herramientas y tecnologías que se utilizarán para desarrollar el sistema que se desea implementar.
Capítulo 2: Características y Diseño de la Propuesta.
2.1 Introducción.
En este capítulo se presenta la visión del sistema, se realiza una comparación entre las técnicas de identificación abordadas en el capítulo anterior y se selecciona la que se aplicará en la extensión.
Además se describen las características y funcionalidades del sistema. Por último se presentará el diseño y la arquitectura del sistema a desarrollar.
2.2 Visión del Sistema.
En los proyectos productivos que se desarrollan en la UCI el líder de proyecto es el responsable de realizar el proceso de identificación de riesgos de acuerdo con las características generales del producto a desarrollar, es quién define los riesgos de su proyecto teniendo en cuenta la experiencia de otros líderes de proyectos o con las suyas propias, y casi nunca tienen en cuenta las características específicas del proyecto.
Debido a que no existe en la UCI una herramienta que posibilite el proceso de identificación de riesgos, surge la idea de implementar una herramienta que adjunta al gestor de proyectos Redmine, proponga un cuestionario que responda a características generales del proyecto y que esté dirigido al miembro del proyecto encargado de la GR.
A través de las respuestas suministradas se elaborará un listado con los principales riesgos que pueden afectar el proyecto en una o varias etapas de su desarrollo, permitiendo su visualización, y posteriormente su almacenamiento en la base de datos del Redmine.
2.3 Selección de la propuesta .
Luego de realizarse la investigación referente a las distintas técnicas para identificar riesgos, es necesario realizar una comparación entre ellas para saber cuál es más factible para aplicarla en la extensión que se desarrollará para el Redmine. Para ello se escogieron los siguientes criterios de comparación:
Grado de especificación: Que permita un alto grado de especificación de los riesgos.
Capacidad de aceptación: Que haya tenido relevantes resultados en la identificación de riesgos.
Adaptación con la aplicación: Que sus características se adapten a las necesidades de la aplicación.
De las técnicas estudiadas la experiencia del personal es la más utilizada actualmente en la universidad por los jefes de proyecto para identificar riesgos, sin embargo los riesgos no son bien
una técnica muy abarcadora. Por otra parte queda la posibilidad de no haber identificado todas las categorías de riesgos posibles.
La tormenta de ideas se utiliza en la universidad menos que la identificación de riesgos basado en experiencia del personal. A pesar de tener las mismas limitaciones es un poco más ventajosa pues están presentes más personas, y estas se encuentran reunidas en el mismo lugar lo que posibilita que sean aclaradas cada una de las ideas expuestas por los participantes.
La técnica Delphi es muy parecida a la tormenta de ideas por lo que presenta las mismas limitantes, con la ventaja de que se mantienen en el anonimato las opiniones de los presentes, lo que posibilita que los más expertos en el tema no inhiban a los menos conocedores y de esa forma puedan surgir más ideas.
Por otra parte las listas de comprobación han sido utilizadas por muchos proyectos pues estas promueven la GR al proveerles resultados reconocidos. Esta práctica se utiliza teniendo en cuenta un subconjunto de riesgos conocidos y predecibles en distintas categorías genéricas lo que constituye una limitante pues no se tiene en cuenta todas las categorías de riesgos existentes.
Por último el cuestionario basado en taxonomía identifica los riesgos de una forma abarcadora y permite además definir las causas que dieron origen al riesgo. Se centra en las características de cada uno de los proyectos a los que se está analizando. Esta última ha tenido gran repercusión a nivel mundial y ha demostrado ser eficiente para el Software Engineering Institute (SEI) pues puede personalizarse a las necesidades específicas de una empresa para utilizarse como una herramienta útil en la identificación de riesgos.
Luego de una valoración de cada una de las características de las técnicas se decidió utilizar para el desarrollo de la aplicación la técnica del cuestionario basado en taxonomía pues posee las siguientes ventajas:
Está formado por una serie de preguntas relacionadas con cada uno de los atributos de la taxonomía de los proyectos.
Permite enfocarse específicamente en aquellas áreas que necesiten mayor atención por parte del equipo de desarrollo.
Permite la identificación y descripción de los riesgos de una manera más entendible.
Establece categorías de riesgos más detalladas que las demás técnicas analizadas, lo que permite organizar los riesgos y realizar una búsqueda apropiada sobre aquellos riesgos que puedan tener peores consecuencias sobre el proyecto.
2.3.1 Propuesta aplicada a la extensión del Redmine.
La extensión al Redmine estará formada por dos módulos:
Módulo de administración: En este módulo se registrarán las preguntas, categorías de preguntas, respuestas y riesgos con los que se trabajará en el cuestionario.
Módulo de cuestionario: Este módulo contendrá todas las funcionalidades para efectuar el diagnóstico de riesgos y para visualizar riesgos identificados con anterioridad.
La técnica para identificar riesgos basada en taxonomía será gestionada en el módulo de administración y brindará la posibilidad de suministrar a la base de datos del sistema las preguntas y respuestas necesarias para englobar la mayor cantidad de riesgos. Las preguntas insertadas en el sistema estarán clasificadas por categorías que se corresponden con las clasificaciones que se establecen en la taxonomía de riesgos.
Cuando se desee realizar un cuestionario se enumerarán previamente las categorías de las preguntas en las que se puede encuestar el usuario. Seguidamente se realizará el cuestionario y luego se mostrará un listado con los riesgos identificados de acuerdo con las clasificaciones determinadas.
Se propone el rol “gestor de riesgos” para realizar diferentes cuestionarios, esta no es la única persona responsable del manejo de los riesgos, pudiendo ser además el líder de proyecto.
2.4 Requisitos de la herramienta.
Los requisitos representan las condiciones o capacidades que debe tener un sistema o componente de un sistema, para satisfacer un contrato, estándar o documento impuesto formalmente. Tiene como propósito, establecer un entendimiento común entre el usuario y el grupo de desarrollo del software sobre los requisitos que solicita el usuario.
Se dividen en dos grandes categorías:
Requisitos funcionales.
Requisitos no funcionales.
A continuación se exponen los requisitos funcionales y no funcionales, definidos para la realización y desarrollo del sistema que se propone. Los mismos se han especificado a partir de las características y funcionalidades que debe tener el sistema que se va a desarrollar.
2.4.1 Requisitos Funcionales.
A continuación se listan las condiciones o capacidades que el sistema debe cumplir.
El sistema debe:
RF1. Permitirle al administrador gestionar categorías de preguntas.
RF1.1 Adicionar una categoría.
RF1.2 Modificar una categoría.
RF1.3 Eliminar una categoría.
RF1.4 Mostrar un listado con las categorías almacenadas.
RF2. Permitirle al administrador gestionar las preguntas.
RF2.1 Adicionar una pregunta.
RF2.2 Realizar modificaciones a una pregunta.
RF2.3 Eliminar la(s) pregunta(s) de un cuestionario.
RF2.4 Asignar respuestas a una pregunta determinada.
RF2.5 Asignarle riesgos a las respuestas asociadas a una pregunta.
RF2.6 Asociar una nueva pregunta a la unión de una pregunta con su respuesta (dependencia).
RF2.7 Mostrar un listado con las preguntas almacenadas.
RF3. Permitirle al administrador gestionar una respuesta.
RF3.1 Insertar una respuesta.
RF3.2 Modificar una respuesta.
RF3.3 Eliminar una respuesta.
RF3.4 Mostrar un listado con las respuestas almacenadas.
RF4. Permitirle al administrador gestionar riesgos.
RF4.1 Insertar un riesgo.
RF4.2 Modificar un riesgo.
RF4.4 Mostrar un listado con los riesgos almacenados.
RF5. Permitirle al gestor de riesgos realizar un cuestionario y guardar el resultado.
RF6. Permitirle al gestor de riesgos acceder a los riesgos identificados en cuestionarios de riesgos realizados anteriormente.
2.4.2 Requisitos no funcionales.
Usabilidad:
La aplicación deberá visualizarse con calidad en los navegadores: Microsoft Internet Explorer, Mozilla Firefox, Opera y Google Chrome.
Fiabilidad:
El sistema debe mantener la integridad de los datos durante su aplicación, procesamiento y almacenamiento en la Base de Datos (BD).
Cuando se detecte un cambio en la BD se debe informar que se ha efectuado el mismo de manera automática.
Rendimiento:
El tiempo de respuesta del sistema será de pocos segundos.
Soportabilidad:
El sistema debe ser de fácil instalación, configuración y puesta en marcha.
El sistema debe funcionar sobre un servidor web Apache 2.0.
El sistema debe utilizar como SGBD PostgreSQL 8.4.
Hardware:
En las PCs Cliente: Procesador Pentium 233 MHz (recomendado 500 MHz o mayor), 512 MB de Memoria de Acceso Aleatorio (RAM), dispositivo de red de al menos 10 Mbits de velocidad de trasmisión.
En la PC Servidora: Procesador Pentium 500 MHz, 1 GB de RAM, 5 GB de capacidad del disco duro, dispositivo de red de al menos 10 Mbits de velocidad de trasmisión.
Apariencia o interfaz externa:
El sistema debe tener un diseño sencillo, formal, serio, de fácil manejo y que contenga las mismas características de las interfaces del Redmine.
El sistema proporcionará claridad y una correcta organización de la información, para evitar equivocaciones con esta.
Implementación:
El sistema debe ser multiplataforma.
EL sistema será implementado utilizando el lenguaje de programación Ruby 1.8.6 con el framework Ruby on Rails 2.3.5. Como SGBD se utilizará PostgreSQL 8.4. Como herramienta para la programación NetBeans 6.8.
Para la modelación de los diagramas UML se utilizará el Visual Paradigm 6.4 y como metodología de desarrollo de software Open UP 1.0.
El sistema debe cumplir con los lineamientos necesarios para la producción de software libre.
Seguridad:
El sistema debe garantizar que la información sea gestionada únicamente por la persona que posea los privilegios para ello.
El sistema debe validar rigurosamente todos los datos de entrada y de salida en el intercambio de información con el usuario.
Licencia:
Uso de licencias de código abierto en los componentes que conforman el desarrollo del sistema cumpliendo con los principios básicos de software libre.
2.5 Descripción del sistema.
2.5.1 Actores del sistema.
Administrador del sistema: Es el responsable de gestionar las preguntas, las categorías de preguntas y las respuestas del cuestionario de riesgos. Además administrará los riesgos que se mostrarán una vez realizado el cuestionario.
Gestor de riesgos: Es el encargado de interactuar con el sistema, después de autenticarse podrá acceder al cuestionario de riesgos y luego ver el listado de riesgos generado, además podrá realizar un nuevo cuestionario.
2.5.2 Modelo de Casos de Uso (CU).
Fig 4. Diagrama de CU del Sistema.
2.6 Descripción de los casos de uso.
A continuación se muestra la descripción de los CU: Realizar Cuestionario y Consultar Cuestionario.
La descripción del resto de los CU se encuentra en los anexos.
Caso de Uso: Realizar Cuestionario.
Objetivo El objetivo del gestor de riesgos es encuestarse con el fin de obtener los riesgos que pueden afectar a un proyecto en específico.
Actores Gestor de riesgos (Inicia).
Resumen Este CU le permite al gestor de riesgos realizar el cuestionario de riesgos que provee el sistema.
Complejidad Alta.
Prioridad Crítico.
Precondiciones El gestor de riesgos está autenticado previamente en el Redmine.
Postcondiciones Se visualiza el listado de riesgos generado de acuerdo con el cuestionario resuelto.
Flujo de eventos
Flujo básico Realizar Cuestionario.
1. Elige el vínculo “Identificación de riesgos”. 1.1 Muestra una interfaz con los datos de los cuestionarios realizados anteriormente.
2. Elige el vínculo “Nuevo Cuestionario” para responder el cuestionario de riesgos.
2.1 Muestra una interfaz con la clasificación de las preguntas, para que se seleccione las categorías de las preguntas que se desean responder.
3. Selecciona las categorías de preguntas en las que se desea encuestar.
3.1 Comprueba la selección de las categorías (Alterno 1.1.1) y muestra una interfaz que contiene el cuestionario de riesgos.
4. Selecciona la respuesta para cada pregunta y para finalizar presiona la opción “Salvar”.
4.1 Guarda el resultado del cuestionario realizado y muestra el listado de riesgos identificados y la categoría a que pertenecen.
4.3 Termina el CU.
Flujos alternos
Nº 1: Comprobar la selección de campos.
Actor Sistema
1. 1.1 Muestra un mensaje de
advertencia al gestor de riesgos si faltan campos por seleccionar.
1.2 Retorna al paso 3.1 del flujo básico.
Caso de Uso: Acceder a listados de riesgos.
Objetivo El objetivo del gestor de riesgos es observar los riesgos identificados en cuestionarios realizados anteriormente.
Actores Gestor de riesgos (Inicia).
Este caso de uso le permite al gestor de riesgos solicitar la visualización de los riesgos identificados en cuestionarios de riesgos realizados anteriormente.
Complejidad Alta.
Prioridad Crítico.
Precondiciones El gestor de riesgos está autenticado previamente en el Redmine.
Postcondiciones Se visualizan los riesgos identificados en cuestionarios realizados con anterioridad.
Flujo de eventos
Flujo básico Consultar Cuestionario.
Actor Sistema
1. Elige el vínculo “Identificación de riesgos” para ver los riesgos identificados anteriormente.
1.1 Muestra una interfaz con los datos de los cuestionarios realizados anteriormente.
2. Selecciona el cuestionario del cual quiere visualizar los riesgos y envía su solicitud.
2.1 Muestra una interfaz con los riesgos correspondientes al cuestionario seleccionado.
2.3 Termina el CU.
2.7 Arquitectura de la extensión al Redmine.
Para diseñar la arquitectura de la aplicación se decidió utilizar el patrón MVC que es uno de los más utilizados en la actualidad para el desarrollo de aplicaciones web. Además es el utilizado en la arquitectura del Redmine. Este patrón separa los datos de la aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.
La Vista es la página HTML y el código que contiene la página, es decir la interfaz gráfica; el Modelo es la representación de los datos con los cuales el sistema opera, en este paquete se agrupan las clases de acceso a datos, y el Controlador representa la lógica del Negocio, en este se agruparán las clases que van a monitorear las demandas de la Vista y a su vez enviarán peticiones al paquete Modelo, para posteriormente con la respuesta que envíe este paquete satisfacer las peticiones recibidas en la Vista.
2.8 Modelo de Diseño.
En esta sección se visualizan los diagramas de clases del diseño de los CU Gestionar Respuesta y Gestionar Riesgos, en ellos se muestran las relaciones existentes entre las clases. El resto de los diagramas se encuentran en la sección Anexos.
2.8.1 Diagrama de clases del diseño del CU Gestionar Respuesta.
Fig 5. Diagrama de clases del diseño del CU Gestionar Respuesta.
2.8.1 Diagrama de clases del diseño del CU Gestionar Riesgos.
Fig 6. Diagrama de clases del diseño del CU Gestionar Riesgos.
2.8.1.1 Descripción de las clases.
Clases entidad: Son las clases que contienen información persistente. Por tal razón son definidas como las clases persistentes del modelo de diseño. Además contienen la información que administran las clases de acceso a datos.
Clases controladoras: Son las encargadas de manejar los distintos eventos recibidos de la interfaz del sistema. Ella maneja todos los eventos realizados hacia el modelo por lo que funciona como un punto de control de acceso para la seguridad.
Clases interfaces: Estas clases siguen el diseño de aplicaciones Web. Luego de una petición del sistema las páginas servidoras crean su página cliente correspondiente y un formulario en caso de que se desee recopilar información. Las páginas clientes contienen código javascript para validar y confirmar peticiones.
2.8.2 Modelo de datos.
Fig 7. Modelo Físico de Datos.
Descripción del modelo.
En el anterior modelo de datos se representa la relación entre las clases persistentes. Entre la tabla Categoría y la tabla Pregunta existe una relación de “uno a muchos” mostrando que una categoría tiene cero o muchas preguntas, por tal razón su llave primaria pasa a ser llave foránea de la tabla Pregunta; esta a su vez se relaciona con la clase Respuesta a través de una relación de “muchos a muchos” originando de esta manera una nueva tabla llamada Pregunta_Respuesta; esta última se relaciona a su vez de una manera asociativa con la tabla Riesgo con una relación de “muchos a muchos”, esto quiere decir que una pregunta con su respuesta determinan un riesgo, esta relación genera una nueva tabla llamada Pregunta_Respuesta_Riesgo.
La tabla Pregunta_Respuesta se relaciona con la tabla Pregunta pues la relación entre una pregunta y una respuesta determinada pueden implicar otra pregunta, esta relación es de “muchos a muchos”
y se crea una nueva tabla Pregunta_Respuesta_Pregunta.
Finalmente las tablas Pregunta y Respuestas de una forma independiente se relacionan de ‟uno a muchos” con la tabla Cuestionario. En la tabla Cuestionario se almacena la relación entre las preguntas y respuestas que fueron dadas por el usuario que realizó el cuestionario.
2.9 Patrones Utilizados.
2.9.1 Patrones Generales de Software para la Asignación de Responsabilidades (GRASP).
Patrón controlador: Este patrón se evidencia en las clases controladoras, pues estas tienen la responsabilidad de recibir o manejar un evento del sistema.
En la aplicación se dividen los eventos del sistema en varias clases controladoras para lograr disminuir el acoplamiento y aumentar la cohesión.
Patrón alta cohesión: Se tuvo en cuenta este patrón porque cada clase cuenta con las funcionalidades imprescindibles para su buen funcionamiento. Este patrón permite fomentar la reutilización y genera bajo acoplamiento.
Patrón bajo acoplamiento: El bajo acoplamiento se muestra al existir la menor dependencia posible entre clases. Esto permite que en caso de producirse una modificación en una de ellas, se tenga el mínimo desenlace posible en el resto de clases.
2.9.2 Patrones de Caso de Uso: CRUD completo.
Este patrón consiste en un caso de uso, llamado Gestionar Información, que contiene todas las operaciones que pueden realizarse sobre la información ejemplo: creación, lectura, actualización y eliminación.
2.9.3 Patrón de Arquitectura: Modelo-Vista-Controlador.
Para diseñar la arquitectura de la aplicación se escogió el patrón MVC que en la actualidad es uno de los más utilizados para el desarrollo de aplicaciones web, además es utilizado en la arquitectura del Redmine. En este patrón; los datos de la aplicación, la interfaz de usuario, y la lógica de control, son separados en tres componentes diferentes. La Vista es la página HTML y el código que provee de datos dinámicos a la página, el Modelo es el SGBD, y el Controlador representa la lógica del Negocio. Este patrón se desarrolla de forma modular por lo que permite realizar cambios en una parte de la aplicación sin que otras partes se vean afectadas. (Ver figura 8)
Fig 8. Modelo Vista Controlador.
2.9.4 Patrones de Diseño.
Instancia única: Este patrón restringe la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto. Es decir provee una única instancia global lo que posibilitará tener solamente un objeto de la clase que se encargue de establecer la conexión a la BD en todo momento.
Active record: Es un patrón principal en el diseño del Redmine. Entre sus características está que el objeto contenga los datos presentes en una fila de la tabla que represente.
Además el objeto debe encapsular la lógica necesaria para interactuar con la BD. De esta forma el acceso a datos se realiza de una forma más sencilla y uniforme.
2.10 Conclusiones parciales.
En el transcurso del capítulo fue realizado un análisis del alcance y la visión de la aplicación. Fueron definidos los requisitos que debe poseer el sistema, los actores que van a interactuar con él, y los casos de uso necesarios para satisfacer los requisitos de la propuesta. Además se definió el diseño que debe tener la herramienta y se identificaron los patrones de diseño que serán utilizados.
Capítulo 3: Implementación y Pruebas de la Propuesta.
3.1 Introducción
En el presente capítulo se hará énfasis en dos aspectos fundamentales durante el desarrollo de un software: implementación y pruebas al sistema. Se explicará cómo está concebido el sistema a través del diagrama de despliegue y se describirán los casos de prueba para garantizar la calidad del módulo que ha sido desarrollado. Por último se explica cómo adjuntar la herramienta realizada al gestor de proyectos Redmine.
3.2 Implementación del sistema.
En un diagrama de despliegue se modela la disposición física de los diferentes nodos que componen un sistema y el reparto de los componentes sobre estos nodos. Los nodos son elementos físicos que existen en tiempo de ejecución y simbolizan un recurso computacional (usualmente tienen algo de memoria y capacidad de procesamiento). El diagrama de despliegue servirá para mostrar la topología de hardware sobre la cual se ejecutará el sistema.
3.2.1 Diagrama de Despliegue.
Fig 9. Diagrama de Despliegue.
La herramienta de gestión de proyectos Redmine 0.9.2 usada en la UCI, está instalada en un Servidor web Apache, utiliza PostgreSQL como SGBD, encargado de almacenar los datos con que trabajará la aplicación. Las PCs cliente podrán acceder a dicho servidor utilizando el protocolo de comunicación HTTP, de esta forma se garantiza que en cada estación de trabajo los usuarios tengan acceso a la herramienta.
3.2.2 Diagramas de Componentes.
El Diagrama de Componentes modela cómo un software es dividido en componentes y muestra las dependencias entre estos componentes. Cada diagrama representa una parte del software. Son usados para documentar la arquitectura del sistema.
A continuación se muestran los diagramas de componentes para los CU Gestionar Respuesta y Gestionar Riesgos. El resto de los diagramas se encuentran en la sección Anexos.
3.2.2.1 Diagrama de Componentes del CU Gestionar Respuesta.
Fig 10. Diagrama de Componentes CU Gestionar Respuesta.
3.2.2.2 Diagrama de Componentes del CU Gestionar Pregunta.
Fig 11. Diagrama de Componentes del CU Gestionar Pregunta.
3.3 Pruebas del Sistema.
El proceso de pruebas está centrado específicamente en la lógica interna del software y sus funciones externas. Se realiza con la intención de descubrir un error. Un buen caso de prueba posee alta probabilidad de mostrar un error no descubierto hasta ese momento.
La prueba es el proceso de ejercitar un programa bajo condiciones específicas, los resultados deben ser registrados y para luego ser analizados. Existen diferentes niveles de prueba: unidad, integración, sistema y aceptación.
Cualquier producto de ingeniería puede ser probado mediante una de estas técnicas:
Pruebas de caja negra: Se realizan conociendo la funcionalidad específica para la cual fue diseñado el producto.
Pruebas de caja blanca: Se realizan conociendo el funcionamiento del producto. Se pueden desarrollar pruebas para asegurar que todas las piezas encajen, es decir, que internamente el sistema se ajusta a las especificaciones.
