Comment gérer efficacement un projet d'analyse statistique?

Nous entendons souvent parler de gestion de projet et de modèles de conception en informatique, mais moins fréquemment en analyse statistique. Cependant, il semble qu'une étape décisive dans la conception d'un projet statistique efficace et durable consiste à garder les choses organisées.

Je préconise souvent l'utilisation de R et une organisation cohérente des fichiers dans des dossiers distincts (fichier de données brutes, fichier de données transformé, scripts R, illustrations, notes, etc.). La principale raison de cette approche est qu’il peut être plus facile d’exécuter votre analyse ultérieurement (lorsque vous avez oublié comment vous avez produit un tracé donné, par exemple).

Quelles sont les meilleures pratiques en matière de gestion statistique de projets ou les recommandations que vous aimeriez formuler à partir de votre propre expérience? Bien entendu, cela s’applique à n’importe quel logiciel statistique. ( une réponse par poste, s'il vous plaît )

Je suis en train de compiler une série de directives que j'ai trouvées sur SO (comme suggéré par @Shane), Biostar (ci-après, BS) et cette SE. J'ai fait de mon mieux pour reconnaître la propriété de chaque élément et pour sélectionner la première réponse ou le vote le plus élevé. J'ai également ajouté des éléments personnels et marqué des éléments spécifiques à l'environnement [R].

Gestion de données

• Créer une structure de projet pour garder tout au bon endroit (données, code, chiffres, etc., giovanni / BS)
• Ne modifiez jamais les fichiers de données bruts (idéalement, ils doivent être en lecture seule), copiez / renommez-en de nouveaux lorsque vous effectuez des transformations, un nettoyage, etc.
• Vérifier la cohérence des données ( whuber / SE)
• Gérez les dépendances de script et le flux de données avec un outil d'automatisation de la construction, tel que GNU make ( Karl Broman / Zachary Jones ).

Codage

• organiser le code source en unités logiques ou blocs de construction ( Josh Reich / hadley / ars / SO; giovanni / Khader Shameer / BS)
• séparez le code source des éléments d'édition, en particulier pour les grands projets - chevauchant en partie les éléments précédents et les rapports
• Tout documenter avec, par exemple, l'oxygène [R] ( Shane / SO) ou une annotation automatique cohérente dans le fichier source - bonne discussion sur Medstats, documentation des analyses et modification des données. Options
• [R] Les fonctions personnalisées peuvent être placées dans un fichier dédié (pouvant être recherché si nécessaire), dans un nouvel environnement (afin d’éviter de remplir l’ espace de noms de niveau supérieur, Brendan OConnor / SO), ou dans un package ( Dirk Eddelbuettel / Shane / SO)

Une analyse

• N'oubliez pas de définir / enregistrer le germe que vous avez utilisé lors de l'appel d'algorithmes RNG ou stochastiques (par exemple, k-means)
• Pour les études de Monte Carlo, il peut être intéressant de stocker les spécifications / paramètres dans un fichier séparé ( sumatra peut être un bon candidat, giovanni / BS)
• Ne vous limitez pas à un graphique par variable, utilisez des affichages multivariés (Trellis) et des outils de visualisation interactifs (par exemple, GGobi).

Gestion des versions

• Utilisez une sorte de contrôle de révision pour faciliter le suivi / l'exportation, par exemple Git ( Sharpie / VonC / JD Long / SO) - cela découle de questions sympas posées par @Jeromy et @Tal
• Sauvegardez tout, régulièrement ( Sharpie / JD Long / SO)
• Conservez un journal de vos idées ou utilisez un outil de suivi des problèmes, tel que ditz ( giovanni / BS) - en partie redondant avec l'élément précédent puisqu'il est disponible dans Git.

Edition / Reporting

• [R] Sweave ( Matt Parker / SO) ou le knitr le plus récent
• [R] Brew ( Shane / SO)
• [R] R2HTML ou ascii

Hadley Wickham offre en outre un aperçu complet de la gestion de projet R , y compris une illustration reproductible et une philosophie unifiée des données .

Enfin, dans son flux d'analyse d'analyse de données statistiques orienté R, Oliver Kirchkamp donne un aperçu très détaillé des raisons pour lesquelles l'adoption et le respect d'un flux de travail spécifique aideront les statisticiens à collaborer les uns avec les autres, tout en garantissant l'intégrité et la reproductibilité des résultats. Il inclut en outre des discussions sur l’utilisation d’un système de contrôle de version et de tissage. Les utilisateurs de Stata trouveront peut-être que le flux de travail de l'analyse de données à l'aide de Stott est aussi utile.

Cela ne fournit pas de réponse spécifique, mais vous voudrez peut-être examiner ces questions connexes:

• "Flux de travail pour l'analyse statistique et la rédaction de rapports"
• "Organisation du code source R"
• "Comment organiser de grands programmes R?"
• "R et contrôle de version pour l'analyste de données solo"
• "Comment le développement logiciel se compare-t-il à la programmation / analyse statistique?"
• "Comment combinez-vous“ Contrôle de révision ”avec“ WorkFlow ”pour R?"

Vous pouvez également être intéressé par le projet récent de John Myles White visant à créer un modèle de projet statistique.

Cela se recoupe avec la réponse de Shane, mais à mon avis, il y a deux piliers principaux:

• Reproductibilité ; non seulement parce que vous ne finirez pas avec des résultats obtenus "d'une manière ou d'une autre", mais vous pourrez également relancer l'analyse plus rapidement (sur d'autres données ou avec des paramètres légèrement modifiés) et disposer de plus de temps pour réfléchir aux résultats. Pour des données volumineuses, vous pouvez d’abord tester vos idées sur quelques "ensembles de jeu", puis les étendre facilement à l’ensemble des données.
• Bonne documentation ; des scripts commentés sous contrôle de version, un journal de recherche, voire un système de ticket pour des projets plus complexes. Améliore la reproductibilité, facilite le suivi des erreurs et rédige des rapports finaux sans importance.

van Belle est la source des règles des projets statistiques réussis.

Juste mes 2 cents. J'ai trouvé Notepad ++ utile pour cela. Je peux gérer des scripts distincts (contrôle du programme, formatage des données, etc.) et un fichier .pad pour chaque projet. Le fichier .pad appelle tous les scripts associés à ce projet.

Bien que les autres réponses soient bonnes, j’ajouterais un autre sentiment: éviter d’utiliser SPSS. J'ai utilisé SPSS pour mon mémoire de maîtrise et maintenant pour mon travail habituel d'étude de marché.

Pendant le travail avec SPSS, il était incroyablement difficile de développer un code statistique organisé, car SPSS ne gère pas plusieurs fichiers (vous pouvez certes gérer plusieurs fichiers, mais ce n'est pas aussi simple que R), car vous ne pouvez pas stocker de jeux de données. à une variable - vous devez utiliser "dataset activate x" - code, qui peut être une douleur totale. En outre, la syntaxe est maladroite et encourage les raccourcis, ce qui rend le code encore plus illisible.

Les ordinateurs portables Jupyter, qui fonctionnent avec R / Python / Matlab / etc, vous évitent de vous rappeler le script qui génère un certain chiffre. Cet article décrit une manière ordonnée de garder le code et la figure l'un à côté de l'autre. Le fait de conserver toutes les figures d’un chapitre de papier ou de thèse dans un seul cahier facilite la recherche du code associé.

Mieux encore, vous pouvez faire défiler une douzaine de chiffres pour trouver celui que vous voulez. Le code est gardé caché jusqu'à ce qu'il soit nécessaire.