Je vais citer ce site Web simplement parce que je l'ai recherché : P
www.ece.cmu.edu les idées de ce site Web ne sont pas les miennes et tous les droits vont à (Philip Koopman, Carnegie Mellon University)
Résumé
Parce que les bases de données de recherche en ligne ne contiennent généralement que des résumés, il est essentiel d'écrire une description complète mais concise de votre travail pour inciter les lecteurs potentiels à obtenir une copie de l'article complet. Cet article décrit comment rédiger un bon résumé d'architecture informatique pour les articles de conférence et de revue. Les rédacteurs doivent suivre une liste de contrôle comprenant : la motivation, l'énoncé du problème, l'approche, les résultats et les conclusions. Suivre cette liste de contrôle devrait augmenter les chances que les gens prennent le temps d'obtenir et de lire votre article complet.
Introduction
Maintenant que l'utilisation de bases de données de publication en ligne est répandue, la rédaction d'un très bon résumé est devenue encore plus importante qu'il y a dix ans. Les résumés ont toujours servi à « vendre » votre travail. Mais maintenant, au lieu de simplement convaincre le lecteur de continuer à lire le reste de l'article ci-joint, un résumé doit convaincre le lecteur de quitter le confort d'un bureau et d'aller chercher une copie de l'article dans une bibliothèque (ou pire, d'en obtenir une après une longue attente grâce au prêt entre bibliothèques). Dans un contexte commercial, un « résumé exécutif » est souvent le seul élément d'un rapport lu par les personnes qui comptent ; et son contenu doit être similaire à celui d'un résumé d'article de journal.
Liste de contrôle : parties d'un résumé
Malgré le fait qu'un résumé soit assez bref, il doit faire presque autant de travail que l'article de plusieurs pages qui le suit. Dans un document d'architecture informatique, cela signifie qu'il devrait dans la plupart des cas inclure les sections suivantes. Chaque section est généralement une seule phrase, bien qu'il y ait de la place pour la créativité. En particulier, les parties peuvent être fusionnées ou réparties dans un ensemble de phrases. Utilisez les éléments suivants comme liste de contrôle pour votre prochain résumé :
Motivation :
Pourquoi nous soucions-nous du problème et des résultats ? Si le problème n'est pas manifestement « intéressant », il vaut peut-être mieux faire passer la motivation en premier ; mais si votre travail est un progrès incrémentiel sur un problème largement reconnu comme important, il est probablement préférable de mettre l'énoncé du problème en premier pour indiquer sur quel élément du problème plus vaste vous vous interrompez pour travailler. Cette section devrait inclure l'importance de votre travail, la difficulté de la zone et l'impact qu'il pourrait avoir en cas de succès.
Énoncé du problème :
Quel problème essayez-vous de résoudre ? Quelle est la portée de votre travail (une approche généralisée, ou pour une situation spécifique) ? Attention à ne pas utiliser trop de jargon. Dans certains cas, il est approprié de mettre l'énoncé du problème avant la motivation, mais cela ne fonctionne généralement que si la plupart des lecteurs comprennent déjà pourquoi le problème est important.
Approche :
Comment avez-vous résolu ou progressé sur le problème ? Avez-vous utilisé la simulation, des modèles analytiques, la construction de prototypes ou l'analyse de données de terrain pour un produit réel ? Quelle était l'étendue de votre travail (avez-vous examiné un programme d'application ou une centaine de programmes dans vingt langages de programmation différents ?) Quelles variables importantes avez-vous contrôlées, ignorées ou mesurées ?
Résultats:
Quelle est la réponse? Plus précisément, la plupart des bons articles sur l'architecture informatique concluent que quelque chose est tellement plus rapide, moins cher, plus petit ou meilleur qu'autre chose. Mettez le résultat là, en chiffres. Évitez les résultats vagues, tels que « très », « petit » ou « important ». Si vous devez être vague, vous n'êtes autorisé à le faire que lorsque vous pouvez parler d'améliorations par ordre de grandeur. Il y a une tension ici en ce sens que vous ne devez pas fournir de chiffres qui peuvent être facilement mal interprétés, mais d'un autre côté, vous n'avez pas de place pour toutes les mises en garde.
Conclusion :
Quelles sont les implications de votre réponse ? Est-ce que cela va changer le monde (peu probable), être une "victoire" significative, être un bon hack, ou simplement servir de panneau de signalisation indiquant que ce chemin est une perte de temps (tous les résultats précédents sont utiles). Vos résultats sont-ils généraux, potentiellement généralisables ou spécifiques à un cas particulier