Conversor y graficador de monedas según el tipo de cambio multilateral desarrollado con VBA en MS Excel.
Este proyecto tiene por objetivo mejorar habilidades de desarrollo de aplicaciones en código VBA, uso del paradigma de POO, habilidades de escritura y presentación de proyectos. También se ensayará la selección de las especificaciones necesarias para un proyecto satisfactorio, el análisis de riesgos de la aplicación y la planificación de pruebas que permitan verificar que la aplicación desarrollada es suficientemente robusta como para ser Publicada.
La confección de un "Conversor de monedas" se suele utilizar en la práctica de distintos lenguajes de programación. En este caso, se trata de un proyecto propuesto en el curso "Excel/VBA for creative problem solving, Part 3." Realizado en la plataforma Coursera TM
Se agruparán muy brevemente los conceptos de:
- URS (Requerimientos elaborados por el usuario para la búsqueda de proveedores, servicios y /o proyectos (prediseñados o no).
- Especificaciones
- Análisis de Riesgos
- Testeo QA de la apliación
Se desea desarrollar una aplicación en código VBA para utilizar en Excel que realice la conversión de múltiples monedas entre si en forma automática y que permita graficar la evolución del tipo de cambio bilateral durante los 30 días anteriores a una fecha seleccionada por el usuario. Los datos de "ratio de conversión" de monedas deben ser actualizados diariamente.
- Debe incluir al menos la conversión entre: peso argentino, dólar estadounidense, euro, libra esterlina, reales, pesos mexicanos, sol, boliviano, guaraní, renminbi, yen y won.
- El usuario debe poder seleccionar cualquier moneda de partida y deseada. Es decir, no se deben necesitar pasos intermedios.
- Se debe poder graficar un período cualquiera de 30 días del tipo de cambio bilateral entre dos monedas cualesquiera que seleccione el usuario.
- En caso de que no hubiera datos del día en curso, la aplicación debe informar al usuario. No debe mostrarse la ventana de depuración del código al usuario.
- La aplicación debe controlar el ingreso equivocado de caracteres no numéricos por el usuario. No debe mostrarse la ventana de depuración del código al usuario.
- Se debe admitir la creación de varios gráficos de monedas diferentes en diferentes "hojas".
Se determinará la criticidad de las funcionalidades.
Cada una de los atributos de riesgo tendrá un valor según la criticidad:
- Severidad: de 1 a 3 se evaluará el nivel de severidad del fallo de la función.
- Siendo 1 una función cuya falla no impide el funcionamiento de la aplicación. No es una función esencial.
- Siendo 2 una función cuya falla impide el funcionamiento de alguna o algunas funcionalidades de la aplicación, pero no de la aplicación central. Es una función importante pero no es esencial.
- Siendo 3 una función cuya falla impide el funcionamiento de la aplicación. Es una función esencial.
- Probabilidad de Ocurrencia: de 1 a 3 se evaluará el nivel de Probabilidad de ocurrencia del fallo de la función.
- Siendo 1 una función cuya ocurrencia depende del código. Si el código se ha testeado y documentado correctamente en la etapa de validación, la funcionalidad tiene bajas o nulas probabilidades de ocurrencia.
- Siendo 2 una función cuya ocurrencia depende de la interacción del usuario con la aplicación, no depende enteramente del código, es "parametrizable". El error de uso aumenta la probabilidad de Ocurrencia, deja de ser una función "automática".
- Siendo 3 una función cuya ocurrencia depende de los parámetros ingresados por el usuario. El resultado de la funcionalidad depende enteramente del usuario.
- Detectabilidad: de 1 a 3 se evaluará el nivel de Probabilidad de detección del fallo de la función por parte del usuario final.
- Siendo Alta para una función prácticamente manual, el sistema se limita a guardar los datos ingresados por el usuario. El usuario puede contrastar el resultado con lo ingresado / esperado.
- Siendo Media para una función cuyo resultado se basa en funciones estándar, pero el usuario debe introducir parámetros para lograr el resultado deseado.
- Siendo Baja una función cuyo resultado se basa en una funcionalidad estándar y no se introducen parámetros por el usuario. El cálculo es automático.
Los valores de "Severidad" y "Ocurrencia" se sumarán y Se determinará una "Clase de riesgo" Baja, Media o Alta de la siguiente manera:
Según el resultado de la sumatoria:
- S + O = 2 **Clase 1**
- S + O = 3 ó 4 **Clase 2**
- S + O = 5 ó 6 **Clase 3**
Luego, de acuerdo a la Detectabilidad, se considerará el nivel de riesgo de la siguiente manera:
- Clase 1: Detectabilidad Alta, Nivel de Riesgo **BAJO"**, Detectabilidad Media, Nivel de Riesgo **MEDIO**, Detectabilidad Baja, Nivel de Riesgo **MEDIO**
- Clase 2: Detectabilidad Alta, Nivel de Riesgo **MEDIO"**, Detectabilidad Media, Nivel de Riesgo **MEDIO**, Detectabilidad Baja, Nivel de Riesgo **ALTO**
- Clase 3: Detectabilidad Alta, Nivel de Riesgo **MEDIO"**, Detectabilidad Media, Nivel de Riesgo **ALTO**, Detectabilidad Baja, Nivel de Riesgo **ALTO**
Todas las funcionalidades cuyo Nivel final de Riesgo resulte Medio o Alto, deberá ser testeada con resultado satisfactorio antes de poder salir al ambiente productivo.
El análisis de Riesgos y la Clasificación de Riesgos tendrán un sesgo que evalúe la peor situación que se pueda presentar de manera de lograr la mayor certeza de que las funcionalidades necesarias y deseables son testeadas a tiempo.
Este análisis busca priorizar las funcionalidades, pero el testeo de las mismas puede ser tan extenso y abarcador como se considere necesario según criterios que maximicen la seguridad para los fines del usuario. Pudiéndose optar por testear funcionalidades de Nivel de Riesgo Bajo también.
| ID | Descripción | Severidad | S | Ocurrencia | O | Detectabilidad | D | NR | P1 | P2 | P3 | P4 | Funcionalidad Crítica |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Conversión entre divisas. | Si no se puede realizar la conversión correcta, la aplicación no sirve. | 3 | Si el código funciona correctamente, la probabilidad de ocurrencia se elimina. | 1 | Detectabilidad baja. La conversión es automática, el usuario no tiene acceso ni control sobre los ratios de conversión, depende del código de la aplicación. | BAJA | ||||||
| 2 | Realizar gráfico de 30 días de la paridad entre monedas desde una fecha elegida por el usuario. | la funcionalidad de graficación no es la función principal. | Si el código funciona correctamente, la probabilidad de ocurrencia se elimina. | Detectabilidad baja. El cálculo se realiza en forma automática. | |||||||||
| 3 | Selección de fechas pasadas. | Si no se puede realizar la conversión en fechas pasadas la aplicación no sirve para el fin deseado. | Si el código funciona correctamente, la probabilidad de ocurrencia se elimina. | Detectabilidad alta. El resultado es comprobable. | |||||||||
| 4 | Detección de fecha sin datos. | Si no se maneja la posibilidad de falta de datos, la aplicación no serviría para el día en curso. | Si el código funciona correctamente, la probabilidad de ocurrencia se elimina. Se debe contemplar en el manejo de errores. | Detectabilidad alta. Sin datos, la aplicación no puede continuar dando mensaje de error. | |||||||||
| 5 | Verificación de ingreso de datos por el usuario. | Si los datos ingresados por el usuario no son correctos, la conversión falla o no tiene sentido. | Si el código funciona correctamente, la probabilidad de ocurrencia se elimina. | Detectabilidad alta. El resultado es comprobable. | |||||||||
| 6 | Creación de múltiples gráficos para comparación de resultados. | La falta de gráficos por separado no impide la tarea de los operadores pero puede dificultarla. | Si el código funciona correctamente, la probabilidad de ocurrencia se elimina. | Detectabilidad alta. El resultado es comprobable. |
| ID | Test | Descripción | Resultado esperado | Resultado obtenido. |
|---|---|---|---|---|
| 1 | Realizar 3 conversiones con la aplicación. | 1) 15 dólaresestadounidenses a pesos argentinos y 1500 pesos argentinos a dólares estadounidenses, 2) 13 euros a libras esterlinas y 13 libras esterlinas a euros, 3) 25 coronas danesas a pesos colombianos, 25 pesos colombianos a coronas danesas. | ||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 | ||||
| 6 |