Contexto: diferentes comunidades dependen en gran medida del software, pero utilizan prácticas de desarrollo de software bastante diferentes. Objetivo: Queríamos medir el estado de la práctica en el área de software estadístico para psicología para comprender cómo se compara con las mejores prácticas. Método: Comparamos y clasificamos 30 herramientas de software con respecto a la adherencia a las mejores prácticas de ingeniería de software en elementos que los usuarios finales podrían medir. Resultados Encontramos que los paquetes R usan prácticas bastante buenas, que mientras que los paquetes comerciales eran bastante utilizables, muchos aspectos de su desarrollo son demasiado opacos para ser medidos, y que los proyectos de investigación varían mucho en sus prácticas. Conclusión Recomendamos que más organizaciones adopten prácticas similares a las utilizadas por CRAN para facilitar el éxito, incluso para equipos pequeños. También recomendamos un acoplamiento cercano del código fuente y la documentación para mejorar la verificabilidad. Las mejores prácticas pueden tardar en propagarse entre disciplinas. Este artículo intenta abordar este problema entre los campos de la psicología y la ingeniería de software.

Analizamos qué tan bien se aplica este consejo en el dominio científico específico de SSP.

En particular, observamos el estado de la práctica para el desarrollo de software estadístico destinado a ser utilizado en psicología. su propio software porque el conocimiento específico del dominio es fundamental para el éxito de sus aplicaciones (Wilson et al, 2013). Sin embargo, estos científicos a menudo son programadores autodidactas y, por lo tanto, potencialmente desconocen las mejores prácticas de desarrollo de software. Para ayudar a remediar esta situación, Wilson et al (2013) brindan consejos generales para el desarrollo de software científico. Analizamos qué tan bien se aplica este consejo en el dominio científico específico de SSP. Nuestro objetivo es comprender primero cuál es el estado de la práctica en SSP y luego brindar asesoramiento sobre qué prácticas de ingeniería de software probablemente proporcionarían las mayores ganancias en la calidad percibida del software, según lo medido por la percepción del usuario final.

Cuando hablamos de cualidades del software, nos referimos a la unión de estas propiedades.

(Gewaltig y Cannon, 2012), para el dominio de la neurociencia computacional, proporciona un primer vistazo al estado de la práctica del software en una comunidad científica específica. Hay disponible una versión más reciente de su artículo (Gewaltig y Cannon, 2014), pero hacemos referencia a la versión original, ya que su sistema de clasificación de software más simple se adapta mejor a nuestras necesidades). Gewaltig y Cannon (2012) proporcionan una comparación de alto nivel del software de neurociencia existente, pero se dan pocos datos sobre las métricas específicas para su comparación. Nos basamos en la idea de estudiar el software creado y utilizado por una comunidad científica específica, al mismo tiempo que incorporamos medidas detalladas de las cualidades del software. En este artículo usamos el término cualidades del software tal como lo usan los ingenieros de software para referirnos a propiedades del software tales como – www.blogdepsicologia.com – instalabilidad, confiabilidad, mantenibilidad, portabilidad, etc. Cuando hablamos de cualidades del software, nos referimos a la unión de estas propiedades. Aquí apuntamos a 30 paquetes SSP, desarrollados por diferentes comunidades que utilizan diferentes modelos. Combinando nuestras propias ideas con sugerencias de Wilson et al (2013) y Gewaltig y Cannon (2012), creamos una hoja de calificación para medir sistemáticamente las cualidades de cada paquete.

Usamos el Proceso de Jerarquía Analítica (AHP) (Saaty, 1994) para cuantificar la clasificación entre paquetes a través de comparaciones por pares. Nuestra calificación asume que el software está diseñado para estar listo para el usuario, según lo definido por Gewaltig y Cannon (2012). Es decir, la calificación asume que la intención es que los nuevos usuarios puedan realizar su trabajo sin necesidad de comunicarse con los desarrolladores originales. En muchos casos, una "calificación" baja no debe atribuirse a una deficiencia en el software, sino al hecho de que el objetivo general no era la preparación del usuario, sino la preparación para la investigación (Gewaltig y Cannon, 2012). El objetivo de calidad general debe tenerse en cuenta al interpretar las clasificaciones finales. A diferencia de Gewaltig y Cannon (2012), los autores de este estudio no son expertos en el dominio. Nuestro objetivo es analizar SSP con respecto a los aspectos de ingeniería de software únicamente. Debido a nuestra falta de conocimiento del dominio, no se discutirán los algoritmos ni la teoría de fondo, y los paquetes no se juzgarán de acuerdo con las diferentes funcionalidades que brindan.

Llegamos a nuestras conclusiones a través de un proceso de calificación sistemático y objetivo, que incorpora algo de experimentación con cada paquete. Otros han analizado cuestiones relacionadas con la ingeniería de software científico. De particular relevancia es Heaton y Carver (2015), que analiza 12121212 prácticas diferentes de ingeniería de software en 43434343 artículos que examinan el desarrollo de software realizado por científicos. Las prácticas de ingeniería de software se agrupan como flujo de trabajo de desarrollo, que consta de problemas de diseño, modelo de ciclo de vida, documentación, refactorización, requisitos, pruebas y verificación y validación; e infraestructura, que consta de seguimiento de problemas, reutilización, problemas de terceros y control de versiones. Estos, naturalmente, tienen una superposición significativa con las cualidades del software, ya que se supone que estas prácticas mejoran estas cualidades. Aunque esta es una encuesta de prácticas, y uno esperaría que estuviera sesgada hacia historias de éxito y, por lo tanto, prácticas bastante buenas, lo que surge es diferente. En otras palabras, incluso entre las historias de éxito, el estado de la práctica es bastante mixto.