1
II
Agradecimientos
Agradezco:
A mi Madre, ¿Por qué eres tan especial para mí?, quizás no exista una repuesta científica, pero yo si tengo mi teoría, mi vida eres Tú. Por ello, cada logro personal o profesional, será un modesto tributo a la veneración de tu ser. ¡Gracias por tu Amor!
A mi Padre, por ser esa luz en el horizonte, que ha guiado cada uno de mis pasos. Una luz tan nítida que ni en los momentos más oscuros disminuyó en intensidad. Tu ejemplo representa una Meta y un Desafío, conquistar esa línea en el horizonte será mi objetivo.
¡Gracias por Tu Ejemplo!
A mi Hermana, por permitirme el placer de compartir tu vida. ¡Gracias por Existir!
A mis abuelos por ser inmensamente grandes de espíritu y sencillez. ¡Son únicos!
A Argelio por tu dedicación y entrega para conmigo. ¡Gracias por considerarme tu hijo!
A Grency, agradezco cada instante que he compartido contigo, pero aún más agradezco la posibilidad que me dio la vida de conocerte. ¡Mil Gracias!
A mi Primo Dianly, que me ayudó en todo instante y me enseñó mucho de lo que se hoy.
A mi Tutora, por su ayuda inestimable, su entrega alegre y entusiasta en todo momento, su ejemplo profesional y por su calidad como persona.
A mi profesora Regla Albelo por inculcarme el ansia de saber. A todos mis profesores de la Lenin
por ofrecerme con mucha calidad sus conocimientos, representan una parte importante de mi preparación
profesional, muy especialmente a Víctor, por su paciencia y dedicación para conmigo.
III
A los profesores de la Universidad que me entregaron valiosos conocimientos durante la carrera, muy especialmente a mi profesora Eugenia (mi tutora), por su magnífica pedagogía al entregar sus conocimientos.
A mis amigos de la Lenin, son los mejores del Mundo, nunca los olvido. Por ser una “familia” tan grande no quiero olvidar a ninguno, cada uno sabe lo importante que es para mí.
A mis amigos de la Universidad con los que he compartido muchísimas alegrías pero también otras tantas no tan felices, muy especial a los “hermanos” a Julio y a Isabel, ojalá siempre los tenga cerca.
A todas las personas que me brindaron desinteresadamente su apoyo en el momento justo.
Finalmente, agradezco la oportunidad de luchar por el “Sueño de mis Padres”.
IV
A mi Madre,
por ser simplemente Única.
V
“El que sabe más, vale más. Saber es tener. La moneda se funde y el saber no. Un rico necesita de sus monedas para vivir, y pueden perdérsele y ya no tiene modos de vida. Un hombre instruido vive de su ciencia, y como la lleva en sí, no se le pierde, y su existencia es fácil y segura”.
José Martí
VI
Resumen
RESUMEN
En la Universidad de las Ciencias Informáticas existe una ineficiente Gestión de Riesgos en los proyectos productivos. Para contrarrestar esta situación fue desarrollado un modelo para la Gestión de Riesgos en proyectos de software; pero en la actualidad el mismo se desconoce en la mayoría de los proyectos productivos y su utilización se hace engorrosa debido a la carencia de una herramienta que de soporte al mismo. La disponibilidad de una herramienta que automatice los procesos descritos en dicho Modelo, contribuirá a mejorar el proceso de Gestión de Riesgos en la Universidad; por lo que los esfuerzos de este trabajo se centran en realizar la Ingeniería de Requisitos para una herramienta que satisfaga los procesos de Gestión de Riesgos planteados por el Modelo mencionado. Se utilizan técnicas de validación para asegurar la calidad de la propuesta de solución.
VII
Tabla de Contenidos
TABLA DE CONTENIDOS
INTRODUCCIÓN ... 1
CAPÍTULO1:FUNDAMENTACIÓNTEÓRICA. ... 6
1.1. GESTIÓN DE RIESGOS. ... 6
1.2. ACTUALIDAD DE LA GESTIÓN DE RIESGOS EN PROYECTOS DE SOFTWARE. ... 8
1.2.1. Estado de la Gestión de Riesgos a nivel Internacional. ... 8
1.2.2. Herramientas de Gestión de Riesgos. ... 8
1.2.3. Estado de la Gestión de Riesgos a nivel Nacional. ... 10
1.3. MODELO GRUCI. ... 14
1.3.1. Valoración del Modelo GRUCI. ... 18
1.4. REQUISITOS DE SOFTWARE. ... 19
1.4.1. Clasificación de los Requisitos. ... 19
1.4.2. Características de los Requisitos. ... 21
1.5. INGENIERÍA DE REQUISITOS. ... 22
1.5.1. Pasos de la Ingeniería de Requisitos. ... 23
1.5.2. Fuentes para la Identificación de Requisitos. ... 25
1.5.3. Problemas en la Identificación de los Requisitos. ... 26
1.5.4. Técnicas utilizadas para la Identificación de Requisitos. ... 26
1.5.5. Técnicas utilizadas para la Especificación de requisitos. ... 27
1.5.6. Técnicas utilizadas para la validación de requisitos. ... 28
1.6. CASOS DE USO. ... 30
1.6.1. Patrones de casos de uso utilizados. ... 30
1.7. MÉTRICAS DE CALIDAD. ... 31
1.8. TECNOLOGÍAS UTILIZADAS EN LA PROPUESTA DE SOLUCIÓN. ... 35
1.8.1. Lenguaje Unificado de Modelación (UML). ... 35
1.8.2. Proceso Unificado de Rational (RUP, según sus siglas en inglés). ... 36
1.8.3. Visual Paradigm. ... 39
1.8.4. Determinaciones de las Tecnologías a utilizar. ... 40
CONCLUSIONES DEL CAPÍTULO. ... 41
CAPÍTULO2:ESTUDIODELMODELOGRUCI. ... 43
2.1. MODELO DE NEGOCIO. ... 43
VIII
Tabla de Contenidos
2.2. DESCRIPCIÓN DE LOS PROCESOS DEL NEGOCIO. ... 44
2.2.1. Resumen de las técnicas propuestas en el Modelo GRUCI. ... 55
2.2.2. Flujo de información. ... 57
2.3. ACTOR Y TRABAJADORES DEL NEGOCIO. ... 58
2.4. DIAGRAMA DE CASOS DE USO DEL NEGOCIO. ... 65
2.5. DESCRIPCIÓN DE LOS CASOS DE USO DEL NEGOCIO. ... 66
2.6. REGLAS DEL NEGOCIO. ... 74
CONCLUSIONES DEL CAPÍTULO. ... 75
CAPÍTULO3:PROPUESTADESISTEMA. ... 76
3.1. ESPECIFICACIÓN DE LOS REQUISITOS DE SOFTWARE. ... 76
3.1.1. Requisitos Funcionales. ... 76
3.1.2. Requisitos No Funcionales. ... 93
3.2. DESCRIPCIÓN DEL SISTEMA. ... 95
3.3. DEFINICIÓN DE LOS ACTORES DEL SISTEMA. ... 96
3.3.1. Descripción de los actores del Sistema. ... 99
3.4. DIAGRAMA DE CASOS DE USO. ... 100
3.4.1. Casos de Uso Significativos para la Arquitectura. ... 107
3.5. DESCRIPCIÓN TEXTUAL DE LOS CASOS DE USO. ... 108
3.6. VALIDACIÓN DE LA PROPUESTA DE SOLUCIÓN. ... 124
3.6.1. Revisión Técnica por Lista de Chequeo... 124
3.6.2. Método de Consulta a Expertos. ... 125
3.6.2.1. Preparación para la Consulta a Expertos. ... 125
3.6.2.2. Selección de Expertos. ... 130
3.6.2.3. Resultados de la aplicación de la encuesta a expertos. ... 134
3.6.2.4. Conclusiones de la Validación por la Consulta a Expertos. ... 135
CONCLUSIONES DEL CAPÍTULO. ... 137
CONCLUSIONES ... 138
RECOMENDACIONES ... 139
BIBLIOGRAFÍA ... 140
ANEXOS ... 143
ANEXO1:ENCUESTA APLICADA PARA EVALUAR LA GESTIÓN DE RIESGOS EN EMPRESAS DE SOFTWARE. ... 143
ANEXO2:ENCUESTA APLICADA PARA EVALUAR EL ESTADO DE LA GESTIÓN DE RIESGOS EN LA UCI... 145
IX
Tabla de Contenidos
ANEXO3:RESULTADOS DE LA ENCUESTA APLICADA EN LA UCI. ... 149
ANEXO4:PLAN DE GESTIÓN DE RIESGOS. ... 156
ANEXO5:MODELO DE RIESGO. ... 157
ANEXO6:TÉCNICA.TABLA FIJA DE PROBABILIDADES. ... 158
ANEXO7:TÉCNICA.MÉTRICA DE FRECUENCIA. ... 159
ANEXO8:TÉCNICA.TABLA FIJA DE IMPACTOS. ... 160
ANEXO9:TÉCNICA.TABLA DE GRADOS DE CERTIDUMBRE. ... 161
ANEXO10:TÉCNICA.SUMA PONDERADA. ... 162
ANEXO11:TÉCNICA.PRIORIZACIÓN POR INCERTIDUMBRE DE LA INFORMACIÓN DE RIESGO. ... 163
ANEXO12:PLAN DE RESPUESTA DE RIESGO. ... 164
ANEXO13:PROCESO PARA LA DETERMINACIÓN DE LA ESTRATEGIA A ADOPTAR PARA EL RIESGO. ... 165
ANEXO14:LECCIONES APRENDIDAS. ... 166
ANEXO15:TÉCNICA.ECUACIÓN PARA EL CÁLCULO DE PRIORIDAD DEL PLAN DE RESPUESTA. ... 167
ANEXO16:TÉCNICA.ECUACIÓN DE EFECTIVIDAD DEL PLAN DE RESPUESTA (CRITERIO CUANTITATIVO). ... 168
ANEXO17:DIAGRAMAS DE OBJETOS POR ARTEFACTO. ... 169
ANEXO18:DIAGRAMA DE ACTIVIDADES DEL CUNREALIZAR PLANEACIÓN. ... 173
ANEXO19:DIAGRAMA DE ACTIVIDADES DEL CUNREALIZAR IDENTIFICACIÓN... 174
ANEXO20:DIAGRAMA DE ACTIVIDADES DEL CUNREALIZAR ANÁLISIS CUALITATIVO. ... 175
ANEXO21:DIAGRAMA DE ACTIVIDADES DEL CUNREALIZAR ANÁLISIS CUANTITATIVO. ... 176
ANEXO22:DIAGRAMA DE ACTIVIDADES DEL CUNPLANEACIÓN DE LA RESPUESTA. ... 177
ANEXO23:DIAGRAMA DE ACTIVIDADES DEL CUNREALIZAR MONITOREO Y CONTROL. ... 178
ANEXO24:DIAGRAMA DE ACTIVIDADES DEL CUNREALIZAR EVALUACIÓN Y APRENDIZAJE. ... 179
ANEXO25:DIAGRAMAS DE OBJETOS POR CASOS DE USO DEL NEGOCIO. ... 180
ANEXO 26:DESCRIPCIÓN DE LOS CASOS DE USO. ... 183
X
Tabla de Contenidos
Tabla 9. CU Realizar Solicitud. ... 183
Tabla 10. CU Autenticar. ... 184
Tabla 11. CU Cambiar Contraseña. ... 185
Tabla 12. CU Consultar Artefacto. ... 187
Tabla 13. CU Ver Artefacto. ... 192
Tabla 14. CU Imprimir Artefacto. ... 198
Tabla 15. CU Administrar Sistema. ... 198
Tabla 16. CU Validar Proceso de Evaluación y Aprendizaje. ... 201
Tabla 17. CU Administrar Proyecto. ... 204
Tabla 18. CU Gestionar Personal del Proyecto. ... 207
Tabla 19. CU Gestionar Plan de Gestión de Riesgos. ... 211
Tabla 20. CU Gestionar Definiciones de Riesgos. ... 212
Tabla 21. CU Evaluar Riesgo Cualitativamente. ... 216
Tabla 22. CU Evaluar Probabilidad. ... 219
Tabla 23. CU Evaluar Frecuencia. ... 220
Tabla 24. CU Evaluar Impacto. ... 222
Tabla 25. CU Evaluar Incertidumbre de la Información. ... 225
Tabla 26. CU Priorizar Riesgos. ... 227
Tabla 27. CU Evaluar Riesgo Cuantitativamente. ... 229
Tabla 28. CU Definir Estrategia. ... 233
Tabla 29. CU Gestionar Plan de Respuesta a riesgos. ... 236
Tabla 30. CU Calcular Prioridad del Plan de Respuesta a riesgos. ... 242
Tabla 31. CU Evaluar Efectividad del Plan de Respuesta a riesgos. ... 243
Tabla 32. CU Analizar la Reserva. ... 247
Tabla 33. CU Gestionar Resumen de Monitoreo y Control. ... 249
Tabla 34. CU Calcular Métricas de la Gestión de Riesgos. ... 253
Tabla 35. CU Realizar Evaluación y Aprendizaje. ... 255
Tabla 36. CU Actualizar Riesgos Comunes. ... 257
Tabla 37. CU Actualizar Respuestas Comunes a riesgos. ... 258
Tabla 38. CU Gestionar Lecciones Aprendidas. ... 259
ANEXO27:LISTA DE CHEQUEO PARA LA ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE. ... 261
XI
Tabla de Contenidos
ANEXO28:SALIDAS ESTADÍSTICAS DE LA EVALUACIÓN DE LOS INDICADORES DE LA LISTA DE CHEQUEO. ... 264
ANEXO29:MÉTODO DE EVALUACIÓN PARA LA LISTA DE CHEQUEO. ... 266
ANEXO30:LEYENDA DE ATRIBUTOS DE CALIDAD... 267
ANEXO31:GRADO DE IMPORTANCIA DE LOS ATRIBUTOS. ... 269
ANEXO32:ENCUESTA PARA DETERMINAR EL COEFICIENTE DE COMPETENCIA DE LOS EXPERTOS. ... 272
ANEXO33:ENCUESTA APLICADA A LOS EXPERTOS PARA OBTENER SUS CRITERIOS DEL SISTEMA. ... 273
ANEXO34:RESULTADOS ESTADÍSTICOS DE LA EVALUACIÓN DE LOS ATRIBUTOS DE LA ENCUESTA A EXPERTOS. ... 276
ANEXO35:ANÁLISIS DE CONCORDANCIA PARA LOS ATRIBUTOS DE LA ENCUESTA A EXPERTOS. ... 279
ANEXO36:RESULTADOS DE LA MEDICIÓN DE LOS ATRIBUTOS DE CALIDAD. ... 280
ANEXO37:RESULTADOS DE LA MEDICIÓN DE LOS INDICADORES DE CALIDAD. ... 283
1
Introducción
INTRODUCCIÓN
Son innumerables los factores que pueden afectar la vida diaria de cada persona y a la vez estas situaciones son muy difíciles de predecir. Estos factores pueden ser externos al ambiente que rodea a la persona y por ello no pueden ser controlados por los afectados. Pero cada persona va creando sus mecanismos de defensa basados en su experiencia y sentido común para enfrentar estas situaciones y lograr una salida exitosa de ellas.
De manera análoga, en el mundo empresarial también se crean contextos que pueden entorpecer el buen funcionamiento de una empresa u otro tipo de grupo de trabajo donde interactúen personas, ciencia y tecnología, para alcanzar un objetivo determinado. Estos tipos de situaciones se nombran riesgos y el mecanismo utilizado para realizar el control de estos es la Gestión de Riesgos.
Se comienza a formalizar la Gestión de Riesgos como un mecanismo de protección y control para los proyectos, para minimizar los eventos negativos así como sus efectos, conocer el grado de certidumbre o la probabilidad de que fracase el proyecto, o tener la seguridad que se está preparado para solucionar situaciones emergentes. También se emplea dada la necesidad de una medición constante de los indicadores claves para el éxito del proyecto, para poder realizar un análisis de los resultados y control periódico, para tener un panorama en tiempo real (o lo más real posible) del estado del mismo y así tomar las decisiones correctas en el momento adecuado. [Söderholm, 2008]
Este tipo de gestión trata de prever y proponer posibles medidas para atenuar las consecuencias de hechos negativos que puedan dar al traste con el cumplimiento de las metas trazadas.
Un ejemplo particular donde se hace indispensable una eficiente y eficaz Gestión de Riesgos es en la creación de software. En la creación de software intervienen personas que aplican conocimientos científicos con la ayuda de las tecnologías para el desarrollo de un producto, lo que acarrea asumir y enfrentar los riesgos que pueden afectar cada parte involucrada en el proceso.
Las estadísticas indican que una parte significativa de los proyectos de software que fracasan, no tuvieron, o tuvieron una pobre Gestión de Riesgos. Los problemas que enfrentaron hubieran sido eliminados, o su impacto reducido, si hubieran tenido una Gestión de Riesgos formal [Boehm, 1991]. Estos aspectos
2
Introducción
hacen que la Gestión de Riesgos revista también una importancia vital en el mundo del software actual.
[McConnell, 2008]
Se han creado diferentes modelos que proponen un proceso de Gestión de Riesgos que permita el seguimiento y control de los riesgos específicos de cada proyecto de software. Entre los modelos más utilizados se encuentra la Guía básica del PMBOK [Project Management Institute, 2000], las metodologías como CRAMM [Central Computer and Telecommunications Agency, 2005] o Microsoft Solutions Framework [Microsoft, 2002] y además AORDD Framework [Houmb, 2005] entre otros.
Producto de la naturaleza impredecible de los riesgos, unido a la mezcla indisoluble que tiene la Gestión de Riesgos al medio en que se desarrolla un proyecto, estos modelos establecidos a nivel internacional no se adaptan completamente al ambiente de desarrollo de los proyectos de software de la Universidad de las Ciencias Informáticas (UCI), debido a las características especiales que presentan los proyectos productivos en esta Institución. Este problema fue detectado y resuelto de forma satisfactoria en el curso 2007-2008 con la Tesis Diploma: “Propuesta de modelo para la Gestión de Riesgos en los proyectos de producción de software”, del Ingeniero Eduardo García Hernández, donde se expuso un modelo de Gestión de Riesgos para aplicar en ambientes de desarrollo de software similares al de la UCI. En lo subsiguiente se le hará referencia a este Modelo con las siglas GRUCI.
Existen un grupo de herramientas que sirven de soporte al proceso de desarrollo de software, estas son conocidas como herramientas CASE (Computer Aided Software Engineering). Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software [Murillo, 1999].
La Gestión de Riesgos es uno de los procesos que se llevan a cabo durante el ciclo de desarrollo de software, si en este proceso o cualquier otro que sea automatizable dentro del proyecto se utiliza una herramientas CASE, se está contribuyendo en primer lugar a la mejora de la calidad de los desarrollos realizados y, en segundo término, el aumento de la productividad. Para conseguir estos dos objetivos es
3
Introducción
conveniente contar con una organización y una metodología de trabajo, además de la propia herramienta [Murillo, 1999].
Las herramientas de Gestión de Riesgos garantizan principalmente:
1. Que el proceso descrito en las mismas sea utilizado en la forma adecuada, evitando así que se violen requisitos indispensables del modelo de Gestión de Riesgos al que tributan.
2. Facilitar el seguimiento, control y actualización del estado de los riesgos a lo largo de todo el ciclo de desarrollo del proyecto.
3. Que el modelo no sea rechazado por los usuarios por no ser factible su seguimiento de forma documental o por no estar automatizado su uso.
El Modelo GRUCI propone un nuevo procedimiento para realizar la Gestión de Riesgos, debido a que cada herramienta de Gestión de Riesgos está diseñada para dar soporte a una metodología específica, las herramientas existentes no se adaptan al Modelo propuesto. Está representa la problemática a resolver con este trabajo. “La situación problemática siempre es producto de un desconocimiento y refleja una contradicción entre la teoría y la práctica” [Hernández, 2002].
Existe el Modelo GRUCI, pero no se ha desarrollado una herramienta de apoyo para automatizar el proceso descrito en el mismo, lo que acarrea que el proceso de Gestión de Riesgos no sea totalmente eficiente y el seguimiento a los riesgos sea complejo. Esto último es el centro de atención de este trabajo, pues se considera de vital importancia disponer de una herramienta que de soporte al proceso de Gestión de Riesgos en la Universidad, por ello se hace necesario identificar las características de una herramienta de Gestión de Riesgos que automatice los procesos descritos en el modelo GRUCI. De esta situación problemática en el ambiente de desarrollo de los proyectos de software en la UCI se presenta:
Problema científico:
¿Cómo transformar los lineamientos del modelo GRUCI en requisitos de software que contribuyan a un efectivo diseño del mismo?
4
Introducción
Objeto de estudio:
Ingeniería de Requisitos.
Campo de acción:
Identificación de Requisitos, Análisis de Requisitos y Negociación, Especificación de Requisitos, Modelación del Sistema y Validación de Requisitos, del modelo GRUCI.
Objetivo:
Realizar los pasos definidos por la Ingeniería de Requisitos para transformar los lineamientos del modelo GRUCI en requisitos de software, que contribuyan a un efectivo diseño del mismo.
Hipótesis:
Si se realiza una adecuada Ingeniería de Requisitos del Modelo para la Gestión de Riesgos en proyectos de software, desarrollado en la Universidad de las Ciencias Informáticas, entonces se contribuirá a obtener los requerimientos de software que satisfagan dicho modelo, favoreciendo así un correcto diseño del mismo.
Tareas:
Valorar el tratamiento que se ofrece en la literatura internacional y nacional acerca del proceso de Gestión de Riesgos.
Estudiar el Modelo GRUCI desarrollado en la UCI.
Estudiar y realizar los pasos definidos para realizar la Ingeniería de Requisitos.
Seleccionar una metodología de desarrollo de software para realizar la propuesta de solución.
Desarrollar de los distintos artefactos definidos por la metodología de desarrollo de software seleccionada.
Establecer un conjunto de métricas que permitan valorar la calidad de la propuesta de solución.
Validar los resultados obtenidos.
5
Introducción
Aporte práctico:
Obtención de los requerimientos de software para el diseño de una herramienta de apoyo al proceso de Gestión de Riesgos en la UCI que cumpla con los lineamientos del Modelo GRUCI, lo que permitirá:
Contribuir a la generalización del uso del modelo GRUCI.
Automatizar todo el proceso de Gestión de Riesgos durante todo el ciclo de vida del proyecto.
Facilitar el seguimiento, control y documentación de los riesgos.
Garantizar que la experiencia en la Gestión de Riesgos de los proyectos que utilicen la herramienta sea reutilizable.
Actualidad de este trabajo:
Radica en la deficiente Gestión de Riesgos que se lleva a cabo en la UCI. Problemas como el desconocimiento en temas de riesgos, falta de capacitación de personal, la no utilización del modelo GRUCI para hacer la gestión y falta de herramientas que den soporte a la Gestión de Riesgos, están contribuyendo a este problema.
Descripción de los capítulos
El trabajo estará compuesto por 3 Capítulos. En el primer Capítulo se realiza un estudio de la Gestión de Riesgos a nivel Nacional e Internacional, lo que servirá como base para el análisis posterior de la Gestión de Riesgos en la Universidad. Además en dicho capítulo se presentarán los fundamentos teóricos necesarios para poder elaborar la propuesta de solución y se determinan las tecnologías utilizadas para ello. En el Capítulo 2 se realizará el estudio del modelo GRUCI, con el objetivo de lograr un nivel de entendimiento claro de los principales procesos que lo componen, modelándose el Negocio descrito en el mismo. Con el entendimiento del Negocio, en el Capítulo 3, se pudo modelar la propuesta de sistema, que constituye el aporte de esta tesis, además en dicho Capítulo se valida esta propuesta de solución.
6
Fundamentación Teórica
CAPÍTULO 1: FUNDAMENTACIÓN TEÓRICA.
En el desarrollo de este Capítulo se presentarán algunos aspectos de la Gestión de Riesgos. Se hará énfasis en la importancia actual de la Gestión de Riesgos a nivel internacional mediante la valoración de la información de una encuesta realizada por la empresa Construx Software Builders en el 2008 a 500 personas vinculadas al desarrollo de software.
A nivel nacional se presentarán los datos de encuestas realizadas por el autor de este trabajo a empresas de software cubanas (ver Anexo 1) y se verificó el estado actual de la Gestión de Riesgos en la Universidad a través de encuestas a personal involucrado en la producción de software (ver Anexo 2).
Se estudiaron los resultados de la tesis realizada en el curso 2007 -2008 por el Ing. Eduardo García Hernández [García, 2008], donde propone un Modelo de Gestión de Riesgos para ambientes de desarrollo similares al de la UCI (GRUCI). Se analizaron las principales características del modelo GRUCI, que sirvan de antecedente para definir los requerimientos de una herramienta que le de soporte. Para ello se determinaron las técnicas de Ingeniería de Requisitos a aplicar para obtener la propuesta de solución y las tecnologías a utilizar para ello.
Con el desarrollo de estos aspectos se pudo hacer una descripción del estado de la Gestión de Riesgos a nivel nacional e internacional, así como se estará en condiciones de poder identificar los requisitos más importantes de una herramienta que cumpla con los procesos descritos en el modelo GRUCI.
1.1. GESTIÓN DE RIESGOS.
En el proceso de desarrollo de software se debe prestar una especial atención a la identificación, clasificación y el seguimiento de los riesgos, durante todo el ciclo de desarrollo del Proyecto. Estos procesos permitirán manejar las situaciones riesgosas antes de que estas obstruyan el cumplimiento de los objetivos del proyecto y tener previamente estudiadas soluciones para manejarlas en el caso de que no sea posible evitarlas.
Una definición de riesgo la ofrece Robert Charette: “En primer lugar, el riesgo afecta a los futuros acontecimientos. El hoy y el ayer están más allá de lo que nos pueda preocupar, pues ya estamos cosechando lo que sembramos previamente con nuestras acciones del pasado. La pregunta es, podemos,
7
Fundamentación Teórica
por tanto, cambiando nuestras acciones actuales, crear una oportunidad para una situación diferente y, con suerte, mejor para nosotros en el futuro. Esto significa, en segundo lugar, que el riesgo implica cambio, que puede venir dado por cambios de opinión, de acciones, de lugares... (En tercer lugar,) el riesgo implica elección, y la incertidumbre que entraña la elección. Por tanto, el riesgo, como la muerte y los impuestos, es una de las pocas cosas inevitables en la vida.” [Charette, 1989, citado por Pressman]
Se debe aplicar una técnica proactiva para hacer la gestión de las situaciones riesgosas que pueden comprometer un proyecto. Con un pensamiento proactivo desde el momento que se concibe el proyecto se están tomando en cuenta las posibles situaciones indeseadas que se pueden presentar durante el desarrollo del producto, “se identifican los riesgos potenciales, se evalúa su probabilidad y su impacto y se establece una prioridad según su importancia. Después, el equipo de Software establece un plan para controlar el riesgo.” [Pressman, 2001]
Para llevar a cabo el proceso de detección, seguimiento y mitigación de los riesgos de un proyecto de software se lleva a cabo la Gestión de Riesgos. “El análisis y la gestión del riesgo son una serie de pasos que ayudan al equipo del software a comprender y a gestionar la incertidumbre. Un proyecto de software puede estar lleno de problemas. Un riesgo es un problema potencial –puede ocurrir o no-. Pero sin tener en cuenta el resultado, realmente es una buena idea identificarlo, evaluar su probabilidad de aparición, estimar su impacto, y establecer un plan de contingencia por si ocurre el problema”. [Pressman, 2001]. El objetivo fundamental de la Gestión de Riesgos es estar informado sobre los riesgos posibles del proyecto y establecer un Plan de contingencia para poder enfrentarlos en el caso de que ocurran.
Con el conocimiento de las debilidades de cada proyecto, el estudio de las capacidades y debilidades reales del grupo de desarrollo, el análisis de las posibilidades tecnológicas y los riesgos que acarrean su uso, se posibilitará en gran medida el éxito del producto final. Una adecuada Gestión de Riesgos evita la aparición de los riegos, pero si estos llegan a materializarse se puede garantizar una respuesta eficaz mediante las medidas plasmadas en el plan de mitigación de riesgos.
8
Fundamentación Teórica
1.2. ACTUALIDAD DE LA GESTIÓN DE RIESGOS EN PROYECTOS DE SOFTWARE.
Se realizó un estudio del estado de la Gestión de Riesgos a nivel Nacional e Internacional, con el objetivo de conocer su estado actual y las principales causas de las deficiencias que se presentan en los proyectos de software para gestionar los riesgos.
1.2.1. Estado de la Gestión de Riesgos a nivel Internacional.
Para la valoración a nivel internacional de la Gestión de Riesgos se analizaron los datos de una encuesta realizada por Construx Software Builders de los Estados Unidos. Esta empresa en julio de 2008 efectuó el estudio:”Software Development’s Classic Mistakes 2008” [McConnell, 2008], donde fueron encuestados 500 empleados del sector de la producción de software quienes según su experiencia, cuantificaron la frecuencia e impacto de los errores más comunes en el desarrollo de software.
Uno de los errores clásicos que recoge dicha encuesta es una ineficiente gestión de riesgos en el desarrollo de productos de software. Con el análisis de los resultados de esta investigación se llegó a la siguiente conclusión que según el criterio de los encuestados:
Este error se comete casi siempre o frecuentemente, según el 68% de los encuestados.
Tiene lugar en el 55 % - 65% de los proyectos de software.
Puede provocar graves o catastróficas respuestas en el producto final en un 60% de las ocasiones.
Se le asocia una importancia elevada.
Puede provocar problemas serios o moderados en el ciclo desarrollo del proyecto.
Estos resultados demuestran la vital importancia que tiene la Gestión de Riesgos en el desarrollo de software. El autor de este trabajo, basándose en las conclusiones antes expuestas, consideró pertinente explorar el estado de la Gestión de Riesgos a nivel nacional, profundizando el estudio en la Universidad de las Ciencias Informáticas, estos aspectos serán tratados en el epígrafe 1.3.3.
1.2.2. Herramientas de Gestión de Riesgos.
Se realizó un estudio de las herramientas de Gestión de Riesgos utilizadas a nivel internacional con el objetivo de conocer las principales características y funcionalidades de las mismas.
9
Fundamentación Teórica
En la actualidad se utilizan diferentes herramientas para gestionar los riesgos ambientales, económicos, de software y otros. Según el análisis realizado para este trabajo, en el mundo del software se utilizan herramientas de Gestión de Riesgos como Risk Matrix 2.2, TRAC, Entorno de análisis de riesgos (EAR) y RIS2K. En su mayoría, las herramientas existentes no están definidas explícitamente para gestionar los riesgos en proyectos de software, estas sirven como soporte para realizar la Gestión de Riesgos a cualquier tipo de proyecto, a excepción de TRAC, que si integra varios componentes con capacidades suficientes para la gestión en proyectos de software.
Risk Matrix 2.2 es una de las herramientas más utilizadas en la Gestión de Riesgos. Fue desarrollada por MITRE Corporation en 1999, está basada en Microsoft Excel y utiliza código Visual Basic para las principales funcionalidades. El proceso de cálculo de riesgos está basado en la propuesta de Electronic Systems Center, permitiendo la identificación, priorización y gestión de los principales riesgos que pueden atentar contra los objetivos del proyecto.
La mayoría de estas herramientas poseen una funcionalidad de documentación deficiente, lo que obliga a los usuarios a generar sus propios informes empleando otras aplicaciones. Esto provoca que el flujo de información de la gestión se realice de forma ineficiente. RIS2K es ejemplo de las herramientas que posibilita una forma de documentación incompleta.
Estas herramientas están definidas para dar soporte a metodologías de Gestión de Riesgos particulares, como por ejemplo RIS2K que ofrece soporte a la metodología de Gestión de Riesgos MAGERIT y Risk Matrix 2.2 que está basada en la idea de Gestión de Riesgos de Electronic Systems Center. Las herramientas de Gestión de Riesgos definen un proceso previamente descrito en una metodología, esta característica hace que cada herramienta de Gestión de Riesgos presente características diferentes, pues su comportamiento está ajustado a la metodología de Gestión de Riesgos a la que da soporte.
Según el análisis de lo planteado por diferentes autores [Pamela y Zachary, 1999 y Trac, 2008] se puede asumir que las tendencias fundamentales de las herramientas de Gestión de Riesgos son:
10
Fundamentación Teórica
Utilizar estructuras de módulos. Se pueden añadir plugins que proporcionan distintas funcionalidades.
La mayor cantidad de los componentes estándar son módulos que pueden ser activados, desactivados, reemplazados o modificados por otros.
Implementar las herramientas en sistemas web, que sean multiplataforma, ligero y extensible. Que permita la actualización, descarga, foros, wikis, blogs y con la utilización de repositorios para almacenar la información.
Utilizar bibliotecas con conocimiento de Gestión de Riesgos como por ejemplo: clases de activos, amenazas típicas, medidas de mitigación normalizadas, Ítems estándar para una política de seguridad, procedimientos estándar de seguridad, análisis cualitativo de una medida de mitigación con respecto a una amenaza, entre otros.
Implementar herramientas configurables al entorno de desarrollo.
Implementar funcionalidades de simulación para ayudar a comprender el impacto que los riesgos tienen en un sistema.
1.2.3. Estado de la Gestión de Riesgos a nivel Nacional.
Estudios realizados en la Universidad en el año 2008 concluyen que “en la generalidad de los proyectos productivos no se definen los riesgos con claridad, la Gestión de Riesgos es inadecuada y carece de utilización de herramientas para su aplicación, generalmente en los proyectos productivos de software los riesgos se gestionan deficientemente y en muchos de ellos no se gestionan y tienen un marco informal”
[García, 2008].
Encuestas realizadas en Enero de 2009 para los efectos de esta tesis (ver Anexo 1), a personal vinculado a la producción de software en dos de las principales empresas de software del país, DeSoft y SofTel, demuestran que se están realizando esfuerzos para lograr una Gestión de Riesgos más eficiente, tratando de evitar la situación descrita anteriormente, pero aún no se cuenta con una herramienta que de soporte todos los procesos de Gestión de Riesgos para un producto de software.
11
Fundamentación Teórica
Gestión de Riesgos en la Universidad de las Ciencias Informáticas (UCI).
Con el objetivo de conocer el estado de la Gestión de Riesgos en la Universidad se realizaron encuestas (ver Anexo 2) en diferentes aéreas de la UCI, para comprobar si el estado de la Gestión de Riesgos en el año 2009, tenía similares características a las descritas en la investigación antes mencionada.
La encuesta fue realizada a 15 personas vinculadas con el desarrollo de software en la Universidad. Entre los encuestados se encuentran líderes de proyectos productivos (50%), vicedecanos de producción e investigaciones (33%) y otros (17%). El 60% de los encuestados son Ingenieros en Informática. Se abarcan gran parte de las aéreas productivas de la Universidad, pues se encuestaron personas de 8 de las 10 facultades existente y personal de la infraestructura productiva. El mayor volumen de producción de software se centra en las facultades, por ello se encuestaron al 50% de los vicedecanos de producción e investigaciones, de las facultades 1, 10, 7, 9 y 4, pues estos dirigen la producción de dichas facultades.
Además se encuestaron los líderes de los proyectos: Sistema Gestión Fiscal, Arquitectura y Tecnología, Planificación Empresarial y Presupuestada, MINPPAL y Consultoría SOA-PDVSA, quienes están ligados de forma directa a la producción de software.
Los resultados de las encuetas permitieron valorar la situación actual de la Universidad en términos de Gestión de Riesgos. Un 40% de los encuestados considera que se mantiene totalmente la situación del año 2008 y el 60% restante está parcialmente de acuerdo con esta afirmación. Estos resultados confirman que existen aun problemas en términos de Gestión de Riesgos. Los encuestados argumentaron que esta situación está originada por:
Proyectos donde se exige la identificación de los principales riesgos pero no se realiza un seguimiento de los mismos durante el ciclo de desarrollo del software.
No se registran nuevos riesgos que puedan ser identificados durante el desarrollo.
No existe una cultura para realizar un proceso Gestión de Riesgos en los proyectos productivos.
Falta de capacitación en temas de Gestión de Riesgos del equipo de proyecto.
No se emplea ninguna herramienta para el proceso de Gestión de Riesgos, lo que provoca que sea engorroso la identificación, seguimiento, documentación y control de los riesgos.
12
Fundamentación Teórica
Líderes de proyectos sin experiencia ni conocimiento de cómo llevar y realizar una gestión de proyecto adecuada y la importancia de la misma, se enfocan mucho en el desarrollo e implementación del proyecto y no en el trabajo del mismo para que se gestione con calidad.
Desconocimiento de un procedimiento de Gestión de Riesgos acorde con las características de los proyectos productivos de la UCI. En algunos proyectos se gestionan los riesgos pero sin utilizar ninguna de las metodologías conocidas.
El 100% de los encuestados afirman que en la Universidad no se utiliza ninguna herramienta para realizar la Gestión de Riesgos. Mencionan herramientas como RIS2K y Trac, pero afirman que no son utilizadas.
El total de los encuestados argumentan que al no poseer una herramienta de Gestión de Riesgos adecuada, deben utilizar Hojas de Cálculo Excel que permiten listar los riesgos y realizar cálculos asociados a los mismos. Es una alternativa de fácil manejo, pero no están integradas al Plan de Proyecto ni orientadas a los riesgos. Proporciona una gestión muy limitada, pues no tienen un fuerte basamento teórico; las mismas son elaboradas al identificar los riesgos al inicio del proyecto y no son utilizadas durante el ciclo desarrollo para darle seguimiento a los riesgos identificados. Estas hojas de cálculo adaptadas para realizar la Gestión de Riesgos se basan en la herramienta Risk Matrix 2.2, sus características se describen en el siguiente epígrafe.
Se obtuvo como resultado que ninguno de los encuestados tiene conocimiento del modelo GRUCI; pero si reconocen las ventajas que proporcionaría una herramienta que se base en un Modelo que haya sido desarrollado específicamente para ambientes de desarrollo de software similares al de la UCI. El 67% de los sujetos afirman que sería totalmente necesaria una herramienta con estas características, y el 33%
restante cree que sería parcialmente necesaria. Estos últimos reconocen que una herramienta tendría un impacto positivo en la Gestión de Riesgos de la UCI, pero afirman que con ello debe ir aparejado la concientización de la necesidad de una adecuada Gestión de Riesgos en el equipo de Proyecto.
Según los resultados, se puede afirmar que no se dispone en la Universidad de una herramienta para la Gestión de Riesgos. Hasta el momento se utilizan documentos de textos para definir y gestionar los mismos, haciendo más engorroso el proceso. Según el criterio de los encuestados una herramienta que de soporte al modelo GRUCI contribuiría a:
13
Fundamentación Teórica
Automatizar el proceso de Gestión de Riesgos de forma eficiente.
Conocer paso a paso, como proceder en la identificación de los riesgos de manera estándar en todos los proyectos de la Universidad.
Obtener estadísticas, valores y datos que pueden ayudar a crear planes de Gestión de Riesgos más exactos a los proyectos de la Universidad.
Reforzar la meta de alcanzar la soberanía tecnológica.
Agilizar el trabajo productivo.
Los resultados de esta encuesta permitieron valorar la actualidad de la Gestión de Riesgos en la Universidad (ver Anexo 3).
Utilización de Hojas de Cálculo Excel para la Gestión de Riesgos en la Universidad.
El proceso de Gestión de Riesgos en la UCI se limita a elaborar una planilla de Gestión de Riesgos muy similar a la que propone Risk Matrix 2.2 en su modo básico (ver figura 1.1). En esta planilla se identifican, se numeran y se describen los riesgos, además se determinan la fechas entre las que se estima puede presentarse el riesgo, se define el impacto sobre los objetivos según las categorías definidas en el proyecto, se define la probabilidad de ocurrencia del riesgo y la estrategia de mitigación a seguir. Después de realizar estos procesos la planilla es almacenada y no se le realiza un seguimiento a los riesgos a lo largo del desarrollo del proyecto.
Figura 1.1. Planilla de Gestión de Riesgos.
14
Fundamentación Teórica
En opinión del autor este proceso resulta ineficiente para realizar la Gestión de Riesgos en la UCI, pues no toma en cuenta las técnicas de Gestión de Riesgos más modernas, ni se adapta a las condiciones de la Universidad, lo que hace que la Gestión de Riesgos sea muy primitiva. La utilización de hojas de cálculo Excel no permite más funcionalidades como Bibliotecas con conocimiento de Gestión de Riesgos, cálculos de variables estadísticas que identifiquen a los riesgos, un seguimiento cómodo de los riesgos y no propone un proceso que sirva de guía para la Gestión de Riesgos en los proyectos de software. Además el paquete Microsoft Office no es software libre, lo que crea una dependencia tecnológica por su utilización.
1.3. MODELO GRUCI.
En la Tesis de grado del Ing. Eduardo García Hernández, se constató la deficiencia de la Gestión de Riesgos en los proyectos productivos. Comprobándose que “las insuficiencias en los modelos existentes de Gestión de Riesgos para ser aplicados a proyectos de software desarrollados en entornos productivos similares al de la Universidad de las Ciencias Informáticas están afectando el desarrollo exitoso de los proyectos respecto al cumplimiento de los plazos, la recuperación ante contingencias y mitigación de los factores que pueden provocar el fracaso. [García, 2008]
Esta problemática fue resuelta satisfactoriamente, pues dicha investigación tuvo como resultado el diseño de un Modelo para la Gestión de Riesgos en los proyectos de desarrollo de software desarrollados en entornos productivos similares al de la Universidad de Ciencias Informáticas. A lo largo de este epígrafe se describen las principales características del modelo GRUCI.
Alcance del Modelo:
Este modelo es aplicable a proyectos de producción de software desarrollados en la Universidad de Ciencias Informáticas que deseen implementar una Gestión de Riesgos periódica con el objetivo de identificar y estudiar los riesgos, de disminuir las amenazas y aumentar las oportunidades. [García, 2008]
Representación del Modelo:
El Modelo se divide en dos grupos de procesos fundamentales, aquellos destinados al descubrimiento y evaluación de los riesgos, y aquellos destinados al control. El primer grupo se compone de los procesos
15
Fundamentación Teórica
de Identificación, Análisis Cualitativo y Análisis Cuantitativo y el segundo de los procesos Planeación de la Respuesta, Monitoreo y Control, Evaluación y Aprendizaje. Ver figura 1.2.
Figura 1.2. Representación del Modelo.
La figura 1.2 representa de forma gráfica los flujos de trabajo del modelo GRUCI y su interacción con el Plan de Gestión de Riesgos, que constituye el artefacto fundamental de la Gestión de Riesgos. Durante la Planeación se genera el Plan de Gestión de Riesgos que define los puntos de ejecución de la Identificación, el Monitoreo y Control, y la Evaluación y Aprendizaje. Siempre posterior a la Identificación se realiza el Análisis Cualitativo y posterior a este el Análisis Cuantitativo. Generalmente se realiza una Planeación de la Respuesta posterior al Análisis Cuantitativo.
El proceso de Planeación tiene actividad durante el inicio del proyecto. La Identificación de riesgos tiene gran actividad en los inicios, y posteriormente disminuye y se estabiliza, generalmente se realiza después de cada hito significativo del proyecto. El Análisis Cualitativo se comporta similar a la Identificación puesto que la sigue en orden lógico y el Análisis Cuantitativo sigue al Cualitativo pero en ocasiones se realiza para evaluar el estado de los riesgos. La Planeación de la Respuesta se ejecuta generalmente después del Análisis Cuantitativo. El proceso de Monitoreo y Control es una actividad constante durante las etapas del proyecto. Al concluir el proyecto se realiza el flujo de Evaluación y Aprendizaje. El grado de actividad de cada flujo de trabajo se puede observar en la figura 1.3.
16
Fundamentación Teórica
Figura 1.3. Actividad de la Gestión de Riesgos en cada fase del proyecto.
Representación de los riesgos:
La representación de los riesgos se hace de forma vectorial. Incluye propiedades claves para su uso adecuado por todos los procesos de la Gestión de Riesgos, logrando una fácil representación a nivel computacional y contribuyendo al análisis y las búsquedas. En la figura 1.4 se pueden observar algunas propiedades del vector del riesgo y los valores que puede asumir en los diferentes flujos de trabajo.
Figura 1.4. Representación del riesgo.
17
Fundamentación Teórica
Las propiedades del vector son descritas a continuación:
ID: identificador único del riesgo, debe ser único dentro de la Universidad, debe ser una cadena de caracteres donde los dos primeros identifiquen la entidad, los tres siguientes el proyecto, y luego enteros consecutivos, por ejemplo: 03COE15. Los riesgos siempre presentes, o riesgos comunes deben tener los primeros indicadores y cuando un riesgo se decida incluir como riesgo siempre presente, debe cambiarse el indicador del proyecto por GLB, para indicar que es un riesgo global.
Etapa: etapa del proyecto donde se manifiesta el riesgo. (Inicio, Elaboración, Construcción, Cierre, Soporte).
Estado: uno de estos valores: identificado, analizado, activo, cerrado, reabierto.
Prioridad: orden de prioridad para atender este riesgo. Es un valor numérico diferente para cada riesgo indicando su prioridad, 0 muy priorizado, > 0 menos priorizado.
Categoría: identificador de la categoría (una de las definidas por el modelo en “Taxonomía del Desarrollo de Software”. [García, 2008]
Entrevistado: persona que identificó el riesgo.
Evento: descripción textual del suceso incierto que causa preocupación. No debe ser ambiguo, debe ser corto pero no debe limitarse su descripción por acortarlo. El evento es descrito en futuro.
Consecuencia: descripción textual de las consecuencias que trae la ocurrencia del evento. Debe expresar claramente el impacto sobre los objetivos del proyecto, no tiene por qué ser sobre todos los objetivos, en otra propiedad del riesgo se cuantificará y valorará este impacto.
Causa: descripción textual de la causa que origina el riesgo. Es importante que sea precisa, descriptiva y objetiva. Es escrito en presente.
Probabilidad: valor numérico indicando la probabilidad de ocurrencia. Este valor es uno de los definidos en el Plan de Gestión de Riesgos.
Impacto: valor de impacto para cada objetivo de proyecto, de acuerdo a lo definido en Plan de Gestión de Riesgos.
18
Fundamentación Teórica
Frecuencia: el factor de aparición del riesgo en el tiempo de proyecto. Expresa un valor porcentual respecto al tiempo total del proyecto indicando con qué frecuencia aparece este riesgo.
Certidumbre de la Información: valor que indica cuán seguro se está de la información obtenida sobre el riesgo.
Marco de tiempo: tiempo mínimo en el que debe ejecutarse los planes de contingencia o explotación para este riesgo, debe expresarse en la unidad de medida acordada en el Plan de Gestión de Riesgos.
Estrategia de respuesta: estrategia utilizada para mitigar el riesgo.
Riesgos Relacionados: una lista de otros riesgos relacionados cuya causa o evento esté muy influenciada por este riesgo.
Observaciones: notas importantes sobre el riesgo, su historial.
1.3.1. Valoración del Modelo GRUCI.
Este modelo propone una Gestión de Riesgos que cubre el ciclo completo del proyecto. En el mismos se definen roles, estos son propietarios de artefactos o modifican artefactos a lo largo de los procesos. El modelo facilita el seguimiento, control y actualización del estado de los riesgos a lo largo de todo el proyecto, permitiendo conocer el estado de los mismos en todo momento.
Se proponen un proceso de aprendizaje que permiten aumentar la exactitud de las medidas de mitigación, a medida que es aplicado en diferentes proyectos. Las medidas de mitigación serán evaluadas según el por ciento de mitigación que se logró del riesgo con dicha medida, lo que servirá de referencia para tomar en cuenta en próximos proyectos, logrando así que el modelo sea más robusto. El modelo mantiene un enfoque en los objetivos de tiempo, costo y contempla la recuperación ante contingencias y mitigación de los factores que pueden provocar el fracaso.
En la tesis de grado de Eduardo García [García, 2008], donde se propone el modelo GRUCI, se recomienda elaborar un sistema informático que automatice los procesos definidos por el Modelo. Dicho
19
Fundamentación Teórica
sistema debe ayudar en la generación de los artefactos, asistir en la configuración de las técnicas seleccionadas y proponer riesgos durante la identificación.
Después del análisis de la problemática de la Gestión de Riesgos a nivel nacional e internacional y de haber realizado un estudio detallado del modelo GRUCI, se pudo concluir que una herramienta que permita realizar los procesos de Gestión de Riesgos descritos en el Modelo GRUCI contribuirá a mejorar la situación de la Gestión de Riesgos en la Universidad. Se asume que las herramientas de Gestión de Riesgos existentes no se adaptan al Modelo GRUCI, pues las mismas están definidas para métodos de Gestión de Riesgos específicos. Por ello el esfuerzo de este trabajo estuvo centrado en obtener los requisitos de software necesarios que permitieron posteriormente diseñar una herramienta de Gestión de Riesgos que brinde soporte al modelo GRUCI.
1.4. REQUISITOS DE SOFTWARE.
La IEEE (Institute of Electric and Electronics Engineers) define un requerimiento como: “(1) Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. (2) Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. (3) Una representación documentada de una condición o capacidad como en (1) o (2)”. [IEEE, 1993]
1.4.1. Clasificación de los Requisitos.
Los requisitos de software se pueden clasificar por sus características en Requisitos Funcionales y Requisitos No Funcionales. [Jacobson y otros, 2000]
Los Requisitos Funcionales especifican acciones que debe poder realizar un sistema, sin tener en cuenta las restricciones físicas. Estos especifican el comportamiento de salida y entrada de un sistema [Rational, 2003]. Representan las capacidades o condiciones que identifican a un sistema.
Los Requisitos No Funcionales “Especifican propiedades de un sistema, como restricciones del entorno o de la implementación, rendimiento, dependencias de la plataforma, facilidad de mantenimiento,
20
Fundamentación Teórica
extensibilidad y fiabilidad” [Jacobson, y otros, 2000: 110]. Son propiedades o cualidades que el producto final debe poseer.
Existen diferentes categorías para clasificar los Requisitos No Funcionales:
Requisitos de Usabilidad: Especifican el nivel de coherencia que debe tener la interfaz de usuario, la documentación ofrecida al usuario, la facilidad del sistema de proporcionar materiales de formación y ayuda en línea, entre otros. [Rational, 2003]
Requisitos de Rendimiento: Están relacionados con tiempos de respuesta estimados, requeridos y esperados para la ejecución en línea de procesos del sistema, teniendo como base la plataforma tecnológica y escenarios específicos a los que en teoría el sistema estará expuesto y frente a los que deberá responder [Informática, 2006]. Imponen condiciones a los requisitos funcionales. Por ejemplo, en una acción dada, puede especificar parámetros de rendimiento para la velocidad, eficiencia, disponibilidad, precisión, rendimiento, tiempo de respuesta, tiempo de recuperación, utilización de recursos entre otros [Rational, 2003].
Requisitos de Implementación: Un requisito de implementación especifica o restringe la codificación o la construcción de un sistema. Se tienen en cuenta los estándares necesarios, lenguajes de implementación, políticas de integridad de bases de datos, límites de recursos, entornos operativos, entre otros.
Requisitos de Capacidad: Están relacionados con la adaptabilidad del sistema, el mantenimiento, la compatibilidad, la capacidad de configuración, capacidad de servicio, capacidad de instalación, entre otros. [Rational, 2003]
Requisitos de Seguridad: Se relacionan con el manejo de la seguridad en el sistema. Son de vital importancia para resguardar la información manejada en los mismos. Su objetivo es garantizar la confidencialidad (que la información esté protegida de accesos no autorizados), la integridad (que la información esté segura de cambios corruptos manejados sin autorización) y la disponibilidad (que la información esté disponible y según el nivel de acceso que tenga cada usuario).
21
Fundamentación Teórica
1.4.2. Características de los Requisitos.
De acuerdo con el estándar IEEE 830, se considera que un requisito de software es de “calidad” cuando se puede decir que es "correcto, inequívoco, completo, consistente, ordenado por importancia y estabilidad, comprobable, modificable e identificable."[IEEE, 1998]
Correcto:
Un requisito es correcto si, y sólo si, el requisito declarado se encuentra en el software. No hay ninguna herramienta o procedimiento que aseguren la exactitud. Alternativamente el cliente o el usuario pueden determinar si el requisito refleja las necesidades reales correctamente. La Identificación de los requerimientos hace este procedimiento más fácil y hay menos probabilidad al error. [IEEE, 1998]
Inequívoco:
Un requisito es inequívoco si, y sólo si, el requisito declarado tiene sólo una interpretación. Como un mínimo, se requiere que cada característica de la última versión del producto se describa usando un único término [IEEE, 1998]. No debe existir ambigüedad en los requisitos de software.
Completo: [IEEE, 1998]
Un requisito es considerado completo si, y sólo si, incluye los elementos siguientes:
a) Está relacionados a la funcionalidad, el desarrollo, las restricciones del diseño, los atributos y las interfaces externas. En particular debe reconocerse cualquier requisito externo impuesto por una especificación del sistema y debe tratarse.
b) La definición de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones. Una nota que es importante especificar son las contestaciones a las entradas válidas e inválidas a ciertos valores.
c) Tener todas las etiquetas llenas y referencias a todas las figuras, tablas, diagramas en la especificación de requisito y definición de todas las condiciones y unidades de medida.
Consistente:
Se refiere a la consistencia interior. Un requisito es internamente consistente si, y sólo si, ningún subconjunto de requisitos individuales genera conflictos con él. [IEEE, 1998]
22
Fundamentación Teórica
Delinear la importancia y/o estabilidad:
Se puede considerar satisfecha esta medida de calidad en un requisito, si este tiene un identificador para indicar la importancia o estabilidad de ese requisito en particular. Típicamente, todos los requisitos que relacionan a un producto del software no son igualmente importantes. Algunos requisitos pueden ser esenciales, sobre todo para las aplicaciones de vida crítica, mientras otros pueden ser deseables. [IEEE, 1998]
Comprobable:
Un requisito es comprobable si, y sólo si, existe algún proceso rentable finito con que una persona o máquina puede verificar que el producto del software reúne el requisito. En general cualquier requisito ambiguo no es comprobable. [IEEE, 1998]
Modificable:
Un requisito es modificable si, y sólo si, su estructura y estilo son tales que puede hacerse cualquier cambio fácilmente, completamente y de forma consistente mientras conserva la estructura y estilo.
Identificable:
Un requisito es identificable si su origen está claro y si facilita las referencias de cada requisito en el desarrollo futuro o en la documentación del mismo.
1.5. INGENIERÍA DE REQUISITOS.
El objetivo de la Ingeniería de Requisitos, es generar una propuesta de requerimientos del sistema que esté en correspondencia con las necesidades de los usuarios finales del mismo. Para ello se debe lograr un claro entendimiento por parte del equipo de desarrollo de estas necesidades y qué debe hacer para que estas se satisfagan en el producto final. Estos constituirán los factores fundamentales para lograr el éxito de cualquier producto de software. Según Pressman, la captura de requisitos es “el proceso de averiguar, normalmente en circunstancias difíciles, lo que se debe construir. De hecho, es tan difícil que todavía no es poco común para los equipos de proyecto el comenzar a escribir código (lo cual es bastante fácil) antes de que se haya formado simplemente lo que se supone que debe hacer el código (lo cual es difícil de determinar)”. [Pressman, 2001]
23
Fundamentación Teórica
Entre las definiciones más acertadas de Ingeniería de Requisitos se encuentra:
Es el proceso sistemático de desarrollar requisitos mediante un proceso iterativo y cooperativo de analizar el problema, documentar las observaciones resultantes en varios formatos de representación y comprobar la precisión del conocimiento obtenido. [Christel, y otros, 1992]
Es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizará el sistema. [Boehm, 1976]
Pressman propone una concepción muy completa de la Ingeniería de Requisitos, conceptualizándola como “el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo que satisfaga las necesidades del usuario”. [Pressman, 2001]
Muchos proyectos de software han sido condenados al fracaso desde su propia concepción pues no se concedió la importancia requerida a la captura de las necesidades de los usuarios y a su buen entendimiento con el equipo del proyecto. “El empeño en construir elementos tecnológicos, antes de comprender el sistema, lleva a cometer errores que desagradan a los clientes”. [Pressman, 2001].
1.5.1. Pasos de la Ingeniería de Requisitos.
Según Pressman en la Ingeniería de Requisitos se desarrollan las actividades de Identificación de Requisitos, Análisis y Negociación de Requisitos, Especificación de Requisitos, Modelación del Sistema, Validación de Requisitos y Gestión de Requisitos [Pressman, 2001]. En el desarrollo de este trabajo se realizaron todos los pasos de la Ingeniería de Requisitos exceptuando la Gestión de Requisitos; debido a que esta propuesta de solución es una primera iteración del sistema, no es necesario gestionar cambios ni darle seguimiento de los requisitos, en próximas iteraciones del mismo si es de obligatorio cumplimiento este tipo de control.
