Análisis y planificación

Conoce los pasos necesarios para realizar un buen análisis para tu proyecto de desarrollo software

Visitas: 59

La fase de análisis y planificación consta de dos partes bien diferenciadas. La primera se realiza antes de empezar el desarrollo, es donde se intenta hacer la primera traducción de la idea que se tiene a algo más estructurado. Esta fase a su vez consta de pasos que van consiguiendo aportar más detalle a los requerimientos y, de esta forma, conseguir unas estimaciones más aproximadas.

Una vez se comienza el desarrollo del producto, la fase de análisis y planificación se convierten en algo que hay que realizar de forma constante. Al empezar a escribir código pueden surgir nuevas dudas, problemas, etc., que requieren volver a ser analizados y planificados. El cliente puede requerir hacer cambios sobre lo que está viendo, y esto no debe suponer un problema. Nosotros estamos para eso, pero, obviamente, esto puede afectar al plan inicialmente establecido y hay que ser disciplinado, realizar los pasos y alertar de cualquier posible cambio en las fechas de finalización.

El proceso de planificación tiene como entrada las características del programa a desarrollar. Como salida tiene dos cifras: estimación de costes y estimación de tiempo. En este artículo no se incluye nada sobre presupuestos, cada cual puede realizar los presupuestos como considere oportuno, pero para poder establecer un coste, sí es necesario determinar el tiempo que va a llevar desarrollar una aplicación.

Y como puedes comprobar, ambas cifras se consideran estimaciones. Nadie puede exigir unas cifras 100% exactas y, su variabilidad, dependerá en gran medida de que no se introduzcan cambios por parte del cliente en los requerimientos.

¿Quién es quién?

Antes de empezar a trabajar, lo primero que hay que hacer es identificar quién es quien. Es decir, ¿quien es el cliente? ¿quien es el desarrollador? Dependiendo de producto en el que estamos trabajando y de lo que haya que hacer, estas preguntas pueden tener respuestas muy diferentes.

La configuración más básica, para una empresa pequeña, es cuando un cliente pide un presupuesto para realizar una aplicación. En este caso, dentro de la empresa del cliente, hay que identificar a la persona con la que vamos a tener que realizar esa comunicación. Esa persona tiene que tener el suficiente conocimiento sobre la aplicación que se pretende desarrollar, de forma que pueda responder nuestras dudas. También tiene que tener capacidad suficiente para tomar decisiones, en el caso que planteemos varias alternativas.

En empresas de desarrollo grandes y en productos más complejos, no es tan fácil identificar quien es el cliente. Normalmente, para cada característica a implementar en el producto, lo que hay que hacer es asignar el rol de cliente a un departamento de desarrollo. Ellos serán los "dueños" de la característica y los encargados de actuar como clientes para el resto de departamentos.

Una vez el cliente está identificado, ya podemos pasar a las siguientes fases. Usaremos el termino cliente para definir quién va a recibir el código de desarrollemos.

Análisis

Normalmente, el cliente llega con las ideas muy claras. A los diez minutos se da cuenta que no es así. Es normal, las ideas abstractas siempre tienden a funcionar en nuestros pensamientos, luego, cuando queremos materializarlos, surgen los problemas.

Lo primero que hay que hacer es una lista simple con las características a implementar. El lenguaje a utilizar debe ser llano. El cliente debe entender esta lista ya que debe validarla. Esta lista define el ámbito de lo que se va a desarrollar. Es la primera transformación de la idea abstracta.

Vamos a plantear un ejemplo, el cliente quiere un programa que le realice una operación aritmética simple. Quiere introducir dos números y que le realice la suma de ambos. Más simple imposible, ¿no?

La lista sería tal que así:

  1. El usuario podrá introducir dos números
  2. Cuando el usuario pulse un botón, se le presentará la suma de ambos

Una vez tengamos esta lista, se debe enviar al cliente para ser validada. El cliente debe entender qué es lo que se va a hacer y estar de acuerdo con ello.

Estimaciones de alto nivel

Una vez obtengamos la aceptación del cliente, debemos estimar la duración.

Aquí entra nuestra experiencia como desarrolladores para establecer cuanto tiempo nos llevará realizar este programa.

Nosotros debemos tener el control total sobre la implementación que se va a realizar, es decir, no podemos realizar unas estimaciones, basadas en una posible implementación, y que luego, llegue otro arquitecto y cambie esta implementación, modificando, por lo tanto, las estimaciones iniciales.

Tenemos que tener en cuenta varias cosas:

  • La estimación será aproximada, es imposible determinar de forma exacta la fecha de terminación de un programa. El cliente debe ser consciente de esto.
  • La fecha de finalización que obtengamos inicialmente, debe tener un desplazamiento. Es decir, en este paso en el que nos encontramos, la fecha de finalización obtenida, tiene que ser bastante antes de la fecha en la que tenemos que acabar el proyecto. Es imposible acertar el día exacto en el que vamos a acabar, y todavía no tenemos suficiente detalle como para poder aproximar más.

Una vez tengamos la fecha establecida, el cliente debe estar de acuerdo con esta fecha antes de empezar a trabajar.

¿Cuál es el alcance del desarrollo?

Si no se realiza este acuerdo, el cliente siempre puede reducir la cantidad de trabajo a realizar, o nosotros podemos ampliar el equipo de trabajo si es posible. En ningún caso hay que empezar a trabajar si hay discrepancias entre nosotros y el cliente.

Análisis detallado

Una vez están determinadas las tareas a desarrollar y una fecha estimada, hay que realizar una planificación más detallada de cada tarea. El objetivo de hacerlo ahora y no antes, es no perder tiempo analizando tareas que, una vez el cliente hubiera tenido una fecha sobre la mesa, hubiera rechazado. Por lo general, el tiempo de planificación no se tiene en cuenta en los costes de desarrollo, cuanto menos tiempo se desperdicie en esta fase, mejor.

Ahora lo que hay que hacer es repetir el proceso de análisis sobre cada elemento de la lista, añadiendo un nivel más de detalle.

Se tendrán reuniones con el cliente para hablar sobre estas características profundizando más sobre ellas.

De esas reuniones tiene que salir una idea más clara sobre cada punto. Hay que hacer preguntas para saber cómo tiene que funcionar cada característica.

Siguiendo con nuestro ejemplo, sobre el punto uno, tendríamos que preguntar:

  • ¿Los números pueden ser flotantes?
  • ¿El usuario podrá introducir cualquier carácter o solo aquellos que formen parte de un número?
  • ¿Soportará números negativos?

Sobre el punto dos, estas son algunas de las preguntas:

  • ¿Ambos campos son requeridos?
  • En el caso de no serlo, si no se introduce uno de los dos operadores, ¿tomamos cero como valor, o mostramos un error?
  • Teniendo en cuenta las validaciones del punto anterior, en el caso de tener que mostrar errores, ¿se mostrarán a medida que el usuario vaya escribiendo o de forma puntual al realizar la operación?
  • ¿El resultado de la operación debe estar visible en todo momento, o de forma puntual una vez el usuario pulse el botón?
  • En el caso de estar visible en todo momento, ¿se debe actualizar a medida que el usuario escribe o borrarse cuando el usuario cambie algún operador?

Como vemos, de un programa tan simple, pueden surgir bastantes dudas. Muchas las podríamos resolver con nuestra experiencia y siguiendo algunos patrones de diseño, pero esto es solo un ejemplo, en el mundo real, las aplicaciones suelen ser bastante más complejas.

Es posible que, en este punto, cuando actualicemos nuestro proyecto, obtengamos una nueva fecha de finalización y que el cliente no esté de acuerdo. Hay que volver a hacer lo mismo, si no se está de acuerdo, hay que solucionarlo, o bien eliminando tareas del proyecto, o bien añadiendo a más gente, o buscando una empresa que nos proporcione esas tareas de forma externa. Esto último debe ser siempre el último recurso, ya que es muy difícil controlar a una empresa externa.

Redacción de requerimientos

Una vez la reunión ha finalizado, es hora de estructurar esas ideas en requerimientos. Un requerimiento es una lista en forma de árbol, donde se agrupa y estructura la funcionalidad que se va a implementar. Este es el segundo paso para transformar la idea abstracta en algo más concreto. El lenguaje debe ser llano, y los requerimientos deben ser validados por el cliente. 

Si contestamos a esas preguntas, la lista de requerimientos quedaría así:

  1. El usuario podrá introducir dos números

    1. Los números podrán ser flotantes, o negativos
    2. La entrada de caracteres en los campos deberá estar restringida a los caracteres que forman parte de un número
  2. Cuando el usuario pulse un botón, se le presentará la suma de ambos

    1. Para realizar la operación, los campos no son requeridos, en caso de no tener un valor en alguno de ellos, se tomará valor cero
    2. El resultado de la operación se mostrará en una etiqueta cuando el usuario pulse un botón
    3. Cuando se modifique el valor de los campos, esta etiqueta se borrará

Los requerimientos son la piedra angular sobre la que se apoya todo el proceso de desarrollo. De ellos tienen que generarse varias cosas, no solo el software, sino también las suites de test y la documentación. Un requerimiento representa un contrato entre el cliente y el desarrollador.

Ahora es el momento de volver revisar las estimaciones del paso anterior y establecer una fecha más aproximada.

El requerimiento debe ser dinámico, a lo largo del proceso de desarrollo irán surgiendo dudas y problemas que hay que resolver. La solución a dichos problemas tendrá que modificar los requerimientos y volver a ser validados por el cliente.

Glosario

La herramienta que utilicemos para redactar los requerimientos, debe incorporar algún tipo de glosario, que permita añadir definiciones sobre los términos que se van a utilizar en los requerimientos. En el desarrollo de cada proyecto se acuñan palabras o términos que, en base al contexto en el que nos movemos, tienen un significado concreto. El buen entendimiento de estos términos hace que la información fluya entre todos los equipos de forma correcta. Facilitar a quien lee los requerimientos las definiciones de estos términos es clave para que se entienda el objetivo de una determinada característica.

En Confluence existe un plugin que lee la lista de términos de una página específica, y los subraya en las páginas de contenido. Cuando el usuario pasa por encima de estos términos, se muestra una ventana flotante con la definición.

Especificaciones técnicas

Una vez el requerimiento está completo en su fase inicial, es hora de empezar a pensar de forma técnica. Hay que evaluar las necesidades técnicas de los requerimientos para descubrir cabos sueltos que hayan podido quedar. 

Es normal que surjan más dudas en esta fase. Las dudas tendrán que ser resueltas con el cliente y los requerimientos modificados en consecuencia.

Una especificación técnica debe contener lo siguiente:

  • Introducción - Explicar brevemente qué se pretende con la característica
  • Equipo - Personas involucradas en el desarrollo, documentación, calidad, etc.
  • Especificación técnica - Traducción a lenguaje técnico, incluyendo si es necesario referencias a clases, código fuente, etc.
  • Internacionalización - Si es necesario que la característica cuente con traducción a otros idiomas
  • Plan de Test - Sugerencias para el equipo de calidad para que realicen la automatización de la verificación de esta tarea.

El líder del equipo es el encargado de desarrollar la estructura inicial de la especificación técnica. Por lo general, el líder del equipo no tiene porque saber todos los detalles de la implementación. Es decir, en programas pequeños o donde el líder del equipo esté muy familiarizado con el código, esto es posible, pero lo normal es que no sea así.

Por lo tanto, simplemente con una estructura inicial e indicando a los desarrolladores las claves del desarrollo, suele bastar.

El desarrollador tiene que utilizar la especificación técnica como un diario de programación. El primer día tiene que incluir los detalles de más alto nivel sobre la implementación.

Luego tiene que hacer prototipos y pruebas para resolver las posibles dudas que surjan. Tiene que investigar en el código como enfocar la implementación de la característica y documentar los resultados de esta investigación en la especificación técnica.

Hay que pensar que tanto calidad como documentación utilizarán la especificación técnica, y el resto de información (requerimientos, etc.) para poder realizar su trabajo. Por lo que tiene que ser escrita con un nivel de detalle suficiente para que sea entendible.

El otro objetivo de la especificación técnica es que sirva al propio desarrollador, o a otros que se unan al equipo, para poder averiguar más sobre los detalles de la implementación en un futuro.

Es muy común, con el paso de tiempo, tener que averiguar los motivos por los cuales se hicieron las cosas de una determinada manera.

La especificación técnica nos tiene que ayudar a entender esto. Lo que nos permite también la especificación técnica es revisar los estimados de alto nivel que se hicieron y poder afinar más. Es decir, estamos realizando una aproximación más exacta a la fecha de finalización del proyecto.

Y, finalmente, la especificación técnica nos ayuda a identificar las tareas que hay que realizar para completar la característica. Haciendo esta especificación, descubrimos cosas que no tuvimos en cuenta en un principio, y nos permite desgranar con un nivel mayor de detalle todo lo que hay que hacer.

Autor

Imagen de José León

Director Área Business Software Solutions