02/12/2020 | Consejos tecnológicos,Desarrollo de software

El método científico aplicado al desarrollo de software

Hace tiempo que surgió en nuestro equipo de desarrolladores la idea de escribir sobre la relación entre el metodo científico y la manera que tenemos de abordar el desarrollo de software, tanto al crear nuevos productos como al resolver incidencias (muchas veces escurridizas) que aparecen en productos ya desarrollados. Como CTO y experto en el desarrollo de software a medida, me gustaría compartir con vosotros mis sugerencias esperando que os resulten interesantes y útiles.

Recomendaciones para el Desarrollo de Software

Por lo general, los desarrolladores de Tribalyte nos guiamos por las buenas prácticas de desarrollo como por ejemplo:

Pero a la hora de escribir código fuente, hay algo anterior, algo que considero son los cimientos sobre los que se apoyan las guías anteriormente mencionadas, algo que podríamos llamar el razonamiento científico.

Para explicarlo mejor, vamos a diferenciar dos casos en lo que respecta al desarrollo de software: crear un nuevo producto de software y solucionar una incidencia en un producto existente. Comencemos por el segundo caso.

Cómo solucionar una incidencia en un producto existente

Si nos paramos a pensar en la manera en la que abordamos la tarea de solucionar una incidencia en un producto existente, nos daremos cuenta de que estamos aplicando (al menos en parte) el modelo científico.

La primera etapa a tener en cuenta en la resolución de una incidencia, defecto o bug en el software, es obtener un procedimiento de reproducción de la misma (siempre que sea posible), es decir, conocer la manera en la que hacer que se manifieste el problema (o los síntomas del problema). A partir de ese procedimiento, comienza el análisis del problema a fin de determinar lo que está ocurriendo y, una vez comprendido, poder diseñar una solución. Estas etapas se podrían sintetizar en:

  1. Reproducir la incidencia.
  2. Analizar y comprender la causa.
  3. Desarrollar la solución.

De manera general (aunque por supuesto, hay una gran tipología de defectos de software) la segunda etapa es la que mayor esfuerzo requiere, sobre todo cuando el producto software en cuestión no ha sido desarrollado por nosotros o no tenemos acceso al código fuente.

Durante esta segunda etapa de análisis empleamos el razonamiento lógico a fin de encontrar y comprender la causa, aunque, todo sea dicho, hay situaciones en las que no es posible aplicarlo y se requiere mayores dosis de creatividad (aplicando por ejemplo el pensamiento lateral). Supongamos que disponemos de un procedimiento para reproducir la incidencia y es posible aplicar el razonamiento.

En este caso resulta de gran utilidad seguir el método científico, que podríamos adaptar de la siguiente manera:

Observación

Consiste en, aplicando el procedimiento para reproducir la incidencia, realizar varias ejecuciones del mismo y obtener datos. Por ejemplo se puede ver qué datos de entrada provocan la aparición del defecto y cuáles no; también es posible alterar la secuencia de acciones (orden, duración en el tiempo) y ver si afecta a la aparición del defecto, etc. En paralelo y en caso de ser posible, también se analiza el código fuente para intentar deducir el comportamiento erróneo.

Inducción

Mediante razonamiento inductivo, pensamos en posibles causas del defecto. En este punto, como no puede ser de otra manera, influye la manera de pensar de cada uno, por lo que puede ser recomendable realizar el ejercicio de razonamiento en equipo.

Hipótesis

Elaboramos una explicación provisional de la causa del defecto, basada en el punto anterior. En este punto por ejemplo podríamos realizar una modificación temporal en el software acorde a la hipótesis.

Prueba

Aplicando de nuevo el procedimiento de reproducción de la incidencia, comprobamos si la hipótesis es válida o no. Por ejemplo, si hemos modificado el software temporalmente, probamos en profundidad si los cambios solucionan el defecto (con cuidado de no crear nuevos defectos, claro).

Análisis de resultados

En caso de que el resultado del paso anterior no fuese correcto (por ejemplo, el defecto continúa presente a pesar de los cambios), la hipótesis queda refutada, por lo que volveríamos al paso 3. En caso de que la hipótesis haya sido cierta (por ejemplo, ya no es posible reproducir el defecto con los cambios realizados), podemos continuar al último paso.

Informe

Al haberse demostrado válida la hipótesis, podemos concluir que conocemos la causa de la incidencia y por tanto desarrollar y aplicar una solución al software. Una vez aplicada, la incidencia se daría por cerrada.

Según nuestra experiencia, este modelo ayuda a solucionar la gran mayoría de problemas encontrados en cualquier producto de software, aunque, por supuesto, cada situación tiene sus restricciones particulares (por ejemplo: no es posible reproducir el defecto, no se tiene acceso al código fuente, no es posible utilizar los datos o el entorno que hacen que se reproduzca la incidencia, etc).

Adicionalmente, este método puede ser de utilidad también en procesos de aprendizaje o investigación, por ejemplo cuando un/a desarrollador/a comienza a trabajar con una nueva tecnología que al principio no comprende en su totalidad. En esta situación sirve como ayuda y motivación realizar el ciclo de observación, hipótesis y comprobación, a fin de ir ganando conocimiento sobre la tecnología que se está aprendiendo o investigando. De esta manera se puede llegar a tener un conocimiento más profundo incluso que lo a veces documentado.

Pasos para desarrollar un nuevo producto de software

Por otro lado, al realizar un nuevo desarrollo de software, cuya finalidad será la creación de lo que llamamos producto, los pasos que por lo general se llevan a cabo son:

  1. Analizar el problema a solucionar, es decir, extraer los requisitos que debe cubrir el producto.
  2. Hacer un plan de alto nivel en base al conocimiento inicial (analizado en 1) y dividirlo en iteraciones.
  3. Seleccionar las tecnologías generales (lenguajes, frameworks, librerías, etc) con las que realizaremos el desarrollo (en base a nuestros conocimientos y experiencia).
  4. Planificar la próxima iteración especificando los requisitos que se van a implementar, en base a unos criterios concretos (habitualmente maximizar el valor aportado).
  5. Comenzar a desarrollar el producto progresivamente, en iteraciones que aportarán incrementos de producto.
  6. Revisar el incremento aportado al terminar cada iteración, así como el propio proceso de desarrollo, a fin de ajustarlo con la intención de mejorarlo.
  7. Repetir el proceso desde el punto 4 en cada iteración, aplicando las mejoras resultantes de iteraciones anteriores.

Si está pensando desarrollar un proyecto software y no sabes por dónde empezar, seguro que nuestra guía práctica sobre el desarrollo de software para empresas te resultará útil.

El desarrollo ágil

Esta sería, grosso modo, la base de un proceso de desarrollo ágil (como por ejemplo el marco de trabajo Scrum). Este tipo de procesos están diseñados para maximizar la adaptación al cambio, minimizar la incertidumbre en el tiempo y mejorar el propio proceso de desarrollo de manera continua. En definitiva cada iteración se podría ver como un círculo de Deming, o círculo PDCA, el cual, a su vez, está basado en el método científico.

Aunque existen numerosas tipologías del método científico (por ejemplo MC-14) si echamos un vistazo a la formulación común (según Francis Bacon, 1620), vemos que sus etapas son: observación, inducción, hipótesis, experimentación, demostración o refutación y generación de la teoría científica. Podríamos sintetizar las etapas en tres: hipótesis, experimentación y evaluación (muy similar al plan-do-check del círculo PDCA).

Un principio fundamental tanto del método científico como del círculo PDCA es la naturaleza iterativa a fin de obtener mejores resultados. Es decir, una vez que una hipótesis es confirmada (o negada), realizar una nueva iteración del ciclo generará mayor conocimiento.

De esta manera podemos ver que los expertos en desarrollo de software que emplean estrategias ágiles tienen mucho en común con los científicos usando el método científico. Sin olvidar que el método nos sería útil también para evaluar qué tecnología elegir para el desarrollo de apps. Espero que mis sugerencias os hayan resultado interesante.

Compartir en:

Relacionados