-
Notifications
You must be signed in to change notification settings - Fork 1
guia analisis
volver a Guía
El análisis es el primer paso de cualquier proceso de resolución de un problema. Al plantearse un problema a un miembro del equipo de trabajo, éste se convierte en el especialista del grupo en ese problema. Es su trabajo analizar todas las posibles alternativas de solución y estudiar todas las herramientas que faciliten su resolución. El ciclo de vida del análisis se compone de las siguientes etapas:
- Planteamiento del problema.
- Diagramas iniciales.
- Investigación bibliográfica en amplitud.
- Investigación bibliográfica en profundidad.
El problema lo plantea un experto u otro miembro del equipo de desarrollo. Los problemas normalmente se plantean con un grano de definición muy grueso, suministrándose además toda la información de la que se disponga: trabajos previos, posibles alternativas de solución, bibliografía relacionada... Será tarea del especialista ir refinando este grano hasta aislar los problemas más simples.
El análisis cuidadoso del problema es el siguiente paso a realizar. Se recomienda ceñirse a la metodología UML por ser orientada a objetos. Siendo realistas, esto nunca se hace… pero debería hacerse un esfuerzo en plantear al menos algunos casos de uso. Una buena guía rápida para tener a mano cuando se trata de crear casos de uso se encuentra aquí. Este paso puede hacerse en paralelo con el siguiente.
Debe encontrarse toda la documentación posible acerca del problema en Internet o la biblioteca. Si se está en la red de la universidad se puede configurar el acceso a Internet a través de su Proxy. Al hacer esto, se tiene acceso a artículos y publicaciones on-line que, de otra forma, debe pagarse para consultar.
Algunas de las fuentes más útiles de información se referencian aquí
En esta primera aproximación se requiere una búsqueda en amplitud pero no en profundidad; sólo sondear las ideas más interesantes acerca del tema y las posibles propuestas ya implementadas. Especial hincapié debe hacerse en este segundo punto: como ingeniero, es fundamental no “reinventar la rueda”. Si existen una o varias alternativas ya implementadas de lo que se busca, deberán evaluarse para ver si satisfacen los requerimientos, y compararse entre sí para determinar cuál es la mejor herramienta.
Un requerimiento inicial que puede llegar a ser excluyente es la licencia del software. En principio siempre interesará que el software no sea propietario para no tener que pagar por su uso, pero dependiendo del caso puede merecer la pena invertir en este software. Sin embargo, incluso aunque se trate de software libre, existen una gran variedad de licencias que pueden llegar a ser incompatibles entre sí, así que hay que estudiar detenidamente el tipo de licencia del software a evaluar.
Con todas las herramientas disponibles, salvando el obstáculo de la licencia, deben seguirse los siguientes pasos para realizar una evaluación inicial.
- Obtener el programa y toda la información relacionada que se encuentre.
- Instalar el programa y tratar de ejecutar o crear un ejemplo (normalmente el incluido en el tutorial de la herramienta).
- Comenzar un pequeño informe del resultado de la evaluación.
- Características técnicas: Licencia, requisitos (SO, BBDD, librerías...), tipo de aplicación (web, escritorio, consola...)...
- Cantidad de documentación (la calidad se evalúa en los otros apartados).
- Instalación de la herramienta: problemas encontrados y solución (si la hay). Decir si la documentación fue suficiente o hubo que recurrir a faqs, foros...
- Evaluación del ejemplo. Indicar problemas, si el ejemplo funciona correctamente, documentación suficiente...
Una vez se tengan un grupo de herramientas potencialmente válidas, se comparan a través de un ejemplo perteneciente al dominio del problema que se está tratando de solucionar. El ejemplo no debe ser excesivamente costoso de implementar pero debería incluir el mayor número posible de características del problema. Por cada herramienta debe añadirse al informe cómo se implementó el ejemplo: simplificaciones o cambios de concepto, y si pudo o no implementarse finalmente. En caso de no poder implementarse debe decirse el porqué. Tras intentar implementar el ejemplo con todas las herramientas debe crearse una tabla en la que se presenten comparativamente los siguientes aspectos:
- Sencillez de obtención de la herramienta (descarga directa de internet, formulario, solicitándola, software de evaluación...)
- Tiempo dedicado a la instalación. Dependiendo de la herramienta se debería incluir o no aquí el tiempo de instalación de otro software que requiera la herramienta. En todo caso, los detalles van en la primera parte del informe.
- Facilidad de instalación
- Tiempo dedicado a implementar el ejemplo
- Dificultad de la implementación del ejemplo
- Valoración subjetiva de la adecuación de la herramienta.
O depuración de la búsqueda. Tras los pasos anteriores debe estar más clara la información que debe encontrarse. En este punto es necesario realizar una búsqueda en profundidad de las opciones más claras. Esta opción es especialmente relevante en temas con un fuerte componente de investigación.
volver a Guía