logo

Analizamos nuestro producto software en 3 pasos

Trabajo del analista.

1. Finalidad con la que vamos a realizar el análisis.

Lo que en ingeniería del software se considera fase de análisis requiere una serie de tareas cuya finalidad puede ser:

Comprender un problema que necesita ser resuelto desde un sistema existente.

Crear un sistema nuevo que solucione un problema existente, o que resuelva una necesidad.

Ampliar un sistema con nuevas características, o refinar las existentes.

La pregunta fundamental es, ¿por qué debemos dedicar tanto tiempo, casi el 30% de la duración del proyecto, a este tipo de tareas?.

Existen gran variedad de respuestas, las cuales pueden ser muy técnicas o algo más sencillas. Para alguien que haya realizado algún tipo de desarrollo de software para algún cliente de un ámbito menos informático (casi siempre) es fácil que se haya encontrado en una situación donde dicho cliente cambie de idea respecto a la funcionalidad, el alcance, o el diseño de las interfaces.

En ese punto donde el proyecto deba afrontar un cambio significativo en cosas tan fundamentales como la funcionalidad, desde el punto de vista profesional, cómo afrontamos esos cambios.

Si se ha realizado un análisis correcto tendremos a nuestra disposición elementos como el documento de requisitos, modelo de dominio, de análisis, flujos de actividad, etc… Es mucho más sencillo tratar un problema si podemos trabajar sobre estos artefactos y ver su trazabilidad. Incluso es posible que el problema en cuestión se pueda resolver sin modificar ninguno de estos elementos, porque se hizo una estimación de riesgos y se contempló la posibilidad y sólo hay que seguir un plan de contingencia adecuado.

Por eso mismo un análisis claro no sólo facilita nuestra labor de desarrollo acotando el proyecto, y transformando elementos reales en elementos software, si no que nos ayuda a afrontar posibles problemas que surjan durante el desarrollo.

2. De la recopilación de información a la obtención de requisitos.

Una vez tenemos claro el objetivo de nuestro análisis llevamos a cabo la extracción de información, que podrá ser dada:

– Por el cliente: te proporcionará un listado incompleto de “cosas” que a él le gustaría que su sistema hiciese y que tendremos que completar de alguna manera.

– Por nosotros mismos.

– Por ambas partes: se puede (se debe) realizar una o varias entrevistas con el cliente, para aclarar ciertas cosas, y sobre todo transformar la realidad en conceptos que luego vayan a ser formalizados desde el punto de vista del desarrollo de software.

Para  obtener información que nos falte tenemos distintas posibilidades, en nuestro caso hemos utilizado las siguientes:

  • BrainStorming: la base de todo cambio debe basarse en una tormenta de ideas, ya sea a través de un grupo de enfoque, del equipo desarrollador o de usuarios del sistema. Nos va a proporcionar una base a partir de la cual trabajar si no hemos obtenido una gran cantidad de información por parte del cliente.

  • Encuesta: a través de una página o una plantilla de google docs (Drive) hemos puesto a disposición de unos usuarios información para que rellenaran siguiendo una Escala Likert o comentarán aspectos que creen esenciales o comentaran cómo mejorar algún aspecto del sistema. Esto nos permitirá pulir detalles a partir del primer análisis obtenido por la tormenta de ideas.

  • Observación de los usuarios: sería una opción a tener en cuenta si se espera realizar una mejora de un sistema ya existente ver, preguntar y comprobar los problemas que tienen los usuarios actuales con el sistema, así cómo su visión de cómo ellos abarcarían el problema. Es importante esta última frase, ya que los desarrolladores normalmente nos ponemos de nuestro lado y no entendemos porqué los usuarios pueden tener problemas que nosotros no detectamos.

En este punto es muy importante también diferenciar entre “cliente” y “usuario”. En muchos casos se tiende a no diferenciar conceptos y esto nos puede llevar a error. El usuario, es el usuario final, quién va a utilizar nuestro producto. Por tanto ese es el objetivo de la observación, ya que es quién va a decidir sobre el éxito o el fracaso de nuestro trabajo.

Una vez que ya hemos obtenido una cantidad de información suficiente para empezar a trabajar, y antes de detallar los requisitos es importante centrarse en entender qué principios deben tenerse en cuenta a la hora de realizar las especificaciones. Para ello nos vamos a basar en los 8 principios enumerados por Baltzer y Goldman para realizar las especificaciones:

  1. Separar funcionalidad de implementación: tenemos que dejar claro que lo primero que hay que hacer es identificar las necesidades, lo que hay que hacer, no cómo vamos a llevarlo a cabo.

  1. Se necesita un lenguaje de especificación de sistemas orientado al proceso: comprobar si va a haber cambios de denominación o modificaciones que lleguen a afectar a los elementos.

  1. Una especificación debe abarcar el sistema del cual el software es una componente: puede que los cambios se realicen una parte del software, pero es importante tener en cuenta “el todo”, ya que los comportamientos del conjunto pueden verse involucrados.

  1. Una especificación debe abarcar el entorno en el que el sistema opera: se debe tener en cuenta el entorno en el que el sistema va a funcionar, tanto en términos funcionales cómo de diseño. Habría que cuidar la cultura, el idioma, el sistema operativo…

  1. Una especificación de sistema debe ser un modelo cognitivo: el sistema debe entenderse como va a ser visto por los usuarios. El objetivo es modelar a las partes integrantes del sistema: individuos, organizaciones, acciones que se van a ejecutar, leyes que deben tenerse en cuenta, LOPD…

  1. Una especificación debe ser operacional: deben tenerse en cuenta tanto las entradas como las salidas que son esperadas en el sistema, con la intención de a partir de ellas realizar un diseño de las pruebas. Aunque no sea completa debe tener información de los comportamientos.

  1. La especificación del sistema debe ser tolerante con la incompletitud y aumentable: no se debe esperar tener una especificación completa, ya que según vaya avanzando el desarrollo irá apareciendo información que vaya completando el sistema. La especificación debe servir de modelo para, en el futuro, ir puliendo los distintos detalles que vayan apareciendo.

  1. Una especificación debe ser localizada y débilmente acoplada: la especificación debe estar dispuesta a sufrir modificaciones en cada una de las actividades principales, diseño, implementación y mantenimiento.

Teniendo en cuenta los principios anteriores describimos y enumeramos los requisitos, deberemos especificar a qué tipo de requisitos pertenece de los siguientes 4:

  • Requisitos Funcionales (RFN): especificaciones que involucran los cambios en el sistema, son aquellas cosas que va a percibir el usuario que hace o permite hacer nuestra aplicación.

  • Requisitos de Usabilidad(RUX): especificaciones relacionadas con la percepción de uso por parte de los usuarios. Ejemplo: facilidad de aprendizaje, adaptación a distintos dispositivos,…

  • Requisitos de Información(RIF): especificaciones que detallan la información de un “tipo” que debe contener. Ejemplo: un usuario de una página web deberá estar registrado por lo menos con nombre, login, password y dirección email.

  • Requisitos No Funcionales (RNF): requisitois que no son comprendidos en ninguno de los tipos anteriores.

3. Obtener soluciones técnicas (metodologías y herramientas).

– Modelado de datos con UML (StarUML):

Lenguaje Unificado de Modelado, más conocido por sus siglas en inglés: Unified Modeling Language es el lenguaje de modelado más utilizado. Como su propio nombre indica éste es un lenguaje para realizar distintos diagramas, en ningún momento su finalidad es la construcción software (implementación).

Se utiliza dentro de la disciplina de la ingeniería del software, para realizar modelos de los sistemas construidos. De esta manera su desarrollo es más sencillo, además previene errores, permite mantener una homogeneidad en el desarrollo. Una vez que el desarrollo ha finalizado las tareas de mantenimiento y futuras ampliaciones también son más sencillas si se tiene un conjunto de modelos y no hay que ir directamente al código a trabajar.

Uml está respaldado por el consorcio OMG, de forma que su utilización esté estandarizado dentro de una serie de normas para que cualquier modelo tenga la menor confusión posible.

Existen multitud de herramientas de modelado, incluso algunas están integradas en los IDE de desarrollo. En nuestro caso utilizamos StarUML ya que estamos más familiarizados con su uso, además es de acceso gratuito y es bastante completo.

Para más información de UML se puede consultar las referencias.

– Casos de uso  con REM.

En primer lugar habrá que decir que es un caso de uso, informalmente vamos a decir que un caso de uso es una tarea, donde el usuario interactúa con un sistema software, y el sistema interacciona con el usuario. Los principales autores de esta disciplina son: Ivar Jacobson y Alistair Cockburn.

Existen algunas herramientas, como REM, para describir los casos y uso, y dar un contexto a ciertas definiciones. En nuestros caso aunque utilicemos un editor de textos, se utilizan estructuras y un marco definido por estos autores.

En nuestro caso utilizamos la siguiente estructura:

Caso de uso

Nombre del caso de uso

# numero

Actor

*

Descripción

Descripción formal del caso de uso, objetivo

Precondición

Características que deben cumplirse antes de la realización del caso de uso

Secuencia normal

Paso

Acción

* Pasos de interacción

*

Post-condición

Características que se asegura que se cumplen una vez que el caso de uso ha finalizado.

Excepciones

Posibles interrupciones, o flujos alternativos en los pasos de interacción.

Trazabilidad

Otros elementos con los que se encuentra relacionado el caso de uso. Por ejemplo Requisitos.

 

Referencias