ETAPAS DEL PROCESO DE DESARROLLO DE SOFTWARE

ETAPAS DEL PROCESO DE DESARROLLO DE SISTEMAS (ANALISIS)

ETAPAS DEL PROCESO DE DESARROLLO DE SISTEMAS

METODO TRADICIONAL (CASCADA)

Análisis ¿qué?

Elicitación de requerimientos:

 Requerimientos funcionales

 Requerimientos no funcionales

Modelo

 Modelado de datos

 Modelado de procesos

“ANALISIS”

Lo primero que debemos hacer para construir un sistema de información es averiguar qué es exactamente lo que tiene que hacer el sistema. La etapa de análisis en el ciclo de vida del software corresponde al proceso mediante el cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las características que el sistema debe poseer)

Por qué resulta esencial la etapa de análisis?

Simplemente, porque si no sabemos con precisión qué es lo que se necesita, ningún proceso de desarrollo nos permitirá obtenerlo. El problema es que, de primeras, puede que ni nuestro cliente sepa de primeras qué es exactamente lo que necesita. Por tanto, deberemos ayudarle a averiguarlo con ayuda de distintas técnicas (algunas de las cuales aprenderemos a utilizar más adelante)

¿Por qué es tan importante averiguar exactamente cuáles son los requerimientos del sistema si el software es fácilmente maleable (aparentemente)?

Porque el coste de construir correctamente un sistema de información a la primera es mucho menor que el coste de construir un sistema que habrá que modificar más adelante. Cuanto antes se detecte un error, mejor. Distintos estudios han demostrado que eliminar un error en las fases iniciales de un proyecto (en la etapa de análisis) resulta de 10 a 100 veces más económico que subsanarlo al final del proyecto. Conforme avanza el proyecto, el software se va describiendo con un mayor nivel de detalle, se concreta cada vez más y se convierte en algo cada vez más rígido.

¿Es posible determinar de antemano todos los requerimientos de un sistema de información?

Desgraciadamente, no. De hecho, una de las dos causas más comunes de fracaso en proyectos de desarrollo de software es la inestabilidad de los requerimientos del sistema (la otra es una mala estimación del esfuerzo requerido por el proyecto). En el caso de una mala estimación, el problema se puede solucionar estableciendo objetivos más realistas. Sin embargo, en las etapas iniciales de un proyecto, no disponemos de la información necesaria para determinar exactamente el problema que pretendemos resolver. Por mucho tiempo que le dediquemos al análisis del problema (un fenómeno conocido como la parálisis del análisis).

La inestabilidad de los requerimientos de un sistema es inevitable. Se estima que un 25% de los requerimientos iniciales de un sistema cambian antes de que el sistema comience a utilizarse. Muchas prácticas resultan efectivas para gestionar adecuadamente los requerimientos de un sistema y, en cierto modo, controlar su evolución. Un buen analista debería tener una formación adecuada en:

- Técnicas de elicitación de requerimientos.

- Herramientas de modelado de sistemas.

- Metodologías de análisis de requerimientos.

Técnicas de elicitación de requerimientos

En la fase de análisis, los errores más difíciles de corregir son los causados por "requerimientos ausentes", generalmente en la forma de suposiciones que se dan por sabidas pero nunca se llegan a plasmar explícitamente. Por este motivo, elicitar los requerimientos de un sistema de información (esto es, obtener de algún modo cuáles son realmente esos requerimientos) resulta una actividad esencial en cualquier proceso de desarrollo de software.

La elicitación de requerimientos requiere previamente la identificación de las personas afectadas por el proyecto, sus stakeholders (literalmente, los que apuestan algo), lo que incluye desde el cliente que paga el proyecto hasta los usuarios finales de la aplicación, sin olvidarse de terceras personas y organizaciones relacionadas indirectamente con el sistema que se va a desarrollar (por ejemplo, empresas competidoras y organismos reguladores)

En la elicitación de requerimientos se recurre a distintas técnicas que favorezcan la comunicación entre el analista y el resto de personas involucradas, como puede ser la realización de entrevistas (en las que importa no sólo lo que se pregunta, sino cómo se pregunta), el diseño de cuestionarios (cuando no tenemos tiempo ni recursos para entrevistar personalmente a todo el mundo) o el desarrollo de prototipos (para recoger información que, de otra forma, no obtendríamos hasta las etapas finales del proyecto, cuando cualquier rectificación saldría mucho más cara). También se puede observar el funcionamiento normal del entorno en el que se instalará nuestro sistema o, incluso, participar activamente en él (por ejemplo, desempeñando temporalmente el trabajo de los usuarios de nuestro sistema). Por último, también podemos investigar por nuestra cuenta consultando documentos relacionados con el tema de nuestro proyecto o estudiando productos similares que ya existan en el mercado.

Herramientas de modelado de sistemas

Un modelo, básicamente, no es más que una simplificación de la realidad. El uso de modelos en la construcción de sistemas de información resulta esencial por los siguientes motivos:

- Los modelos ayudan a comunicar la estructura de un sistema complejo (y, por tanto, a comunicarnos con las demás personas involucradas en un proyecto).

- Los modelos sirven para especificar el comportamiento deseado del sistema (como guía para las etapas posteriores del proyecto).

- Los modelos nos ayudan a comprender mejor lo que estamos diseñando (por ejemplo, para detectar inconsistencias y corregirlas).

- Los modelos nos permiten descubrir oportunidades de simplificación (ahorrarnos trabajo en el proyecto actual) y de reutilización (ahorrarnos trabajo en futuros proyectos).

En resumidas cuentas, los modelos, entre otras cosas, facilitan el análisis de los requerimientos del sistema, así como su posterior diseño e implementación. Un modelo, en definitiva, proporciona "los planos" de un sistema. El modelo ha de capturar "lo esencial" desde determinado punto de vista. En función de para qué queramos el modelo, lo haremos más o menos detallado, siempre

...