Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

u des informateurs clés par téléphone Le problème que vous allez aborder est li

u des informateurs clés par téléphone Le problème que vous allez aborder est lié à l'activité INTERNE de l'organisation sur laquelle vous travaillez. Peut-être que les gens de cette entreprise ont besoin d'une nouvelle technologie, ou qu'ils ont investi dans quelque chose qui n'est pas utilisé/sous-utilisé, ou simplement qu'ils ont fusionné/grandi et ont besoin de nouvelles solutions pour organiser le travail. Tout ce que vous lirez dans les chapitres 1, 2 et 3 du manuel peut être pertinent ici. Vous allez formuler vos propres recommandations pour cette entreprise. Attention, vous devez montrer la rigueur et la pertinence de vos propres solutions, ne vous contentez pas d'expliquer ce que l'entreprise a décidé de faire pour résoudre le problème avant que vous ne frappiez à leur porte ! Il s'agit de gérer les technologies numériques, donc si vos recommandations s'arrêtent à " l'entreprise X devrait mettre en place un système ERP ", vos prospects ne seront pas du tout impressionnés... Ils ont besoin de savoir pour le mettre en place et ce que cela va changer dans leurs processus, comment les gérer, etc. Votre essai ne dépassera pas 2 300 mots (interligne 1,5 ; Times New Roman taille 12, A4 portrait), sans compter la page de couverture, la liste de références et les annexes. Vous écrirez le nombre de mots avant la liste de référence. · Sur la page de garde, vous indiquerez (1) le titre de la dissertation individuelle, (2) votre nom et votre numéro d'étudiant, (3) l'année académique et (4) le nom de votre professeur · Votre liste de références doit comprendre au moins 5 éléments, outre le cours du manuel Systèmes d'information pour managers. Copier le manuel est un problème de plagiat et sera sévèrement sanctionné. Vos références proviendront de médias spécialisés (par exemple HBR, MIT Tech Review) et de sources académiques Cornford, T., & Smithson, S. (2005). Project research in information systems : a student's guide. Macmillan International Higher Education. Vous téléchargerez votre fichier au format PDF dans la boîte de soumission correspondante sur Moodle. Toute essai soumis par un autre canal ne sera pas noté. · Vous enregistrerez votre fichier sous le nom de STUDENTNAME_PROFNAME_2022_CASE Présentation du cas Problématique Analyse situation actuelle Recommandation L’entreprise Eugen Systems est un studio de développement de jeu vidéo fondé en. SI adapté à la nature complexe et itérative de la production du produit vidéoludique. Objet technique central : la build. SI parvient à connecter designer, lignes de codes avec sauvegardes régulières, code couleur chacun laisse. Bien intégré pour hautement qualifié et lors production interne, manque testeurs une fois le jeu sortie Problématique : comment mieux intégrer le rôle itératif central des testeurs interne et externalisé une fois le jeu sorti ? Recommandation : intégrer davantage les testeurs + externaliser via twitch, en utilisant API et détection langage chat type bug ou quoi pour tout de suite pouvoir intervenir. Tirer partie du jv global game et mises à jours. Externalisation et automatisation par greffe à twitch. « dispositifs alogithimiques complexes et interactifs » « variété de spécialisations hautement qualifiées,, précaires cet assemblages de techniques myriades de défaillance » « build version intermédiaires du produit » « alertes pannes et défaut « global game, jeux comme services Kerr, 2017 » Meades : public expertise repère les bugs, lourdes conséquences commerciales Travail créatif incertitude Menger des testeurs en interne, prenant à contre-courant la généralisation du recours à l’externalisation pour ces travaux peu qualifiés (Kerr, 2017, p. 194- 195) Dans le numérique en particulier, les conditions d’inscription et d’effacement des participations productives se transforment avec l’introduction de nouvelles médiations technologiques. Les « petites mains » pourtant indispensables à la production de données et à la stabilité des infrastructures digitales se multiplient (Denis et Pontille, 2012 ; Cohn, 2019). Que se joue-t-il dans la production de ces données informationnelles, du point de vue de leur extraction, de leur codification, de leur circulation et de leur usage ? Le développement de jeux vidéo, par nature interdisciplinaire, fait intervenir quatre catégories d’acteurs (Kerr, 2006) : les ingénieurs (programmeurs), les designers, les artistes et le management. Au sein de chacune d’elles se logent de multiples corps professionnels fortement spécialisés qui ne partagent pas toujours de langage et de savoir-faire communs (Whitson, 2017), ni même d’outils (le nombre de supports de travail est conséquent : interfaces variées du moteur de jeu, logiciels de création de données – algorithmes, éléments graphiques, animations ou encore sons –, documents textuels, tableurs, etc.). Enjeu de centralisation de l’information Dans cet environnement, un objet numérique joue un rôle fondamental, en ce qu’il est le point d’observation central de la rencontre de ces actes productifs : la build. Elle est une simulation intermédiaire du produit, contenant la dernière version des données créées et intégrées, ainsi que le code d’exécution nécessaire à la lecture et à l’interprétation de celles-ci. Afin qu’une version actualisée du travail effectué soit toujours disponible, elle est générée automatiquement trois fois par jour. À ce titre, la build peut être considérée comme un « objet intermédiaire » (Jeantet, 1998 ; Vinck, 1999), en ce qu’elle participe à la structuration et la coordination des activités. Comme Dominique Vinck et Alain Jeantet le développent, l’objet intermédiaire, ici la build, est à la fois le siège de processus de représentation (elle matérialise les intentions des concepteurs, leurs habitudes de travail ou de pensée, leurs rapports et leurs interactions, leurs perspectives et les compromis qu’ils ont établis) et le véhicule d’une vision en cours de cristallisation à partir duquel les acteurs projettent leurs actions. Cette matérialisation engendre trois dynamiques : la première repose sur la mise en commun des contributions des différents développeurs. La build, en tant que carrefour du travail parallèle effectué par une myriade d’acteurs, matérialise les incompatibilités qui n’ont pas pu être anticipées de manière abstraite, mais également les désaccords et les négociations inachevées (Whitson, 2017) ; la deuxième dynamique est liée à la multiplicité des environnements technologiques : qu’elle provienne initialement d’une interface du moteur du jeu ou d’un logiciel de création graphique ou sonore, la contribution de chacun va passer d’un espace local à un objet technique collectif. Ces transferts engendrent de multiples résistances (O’Donnell, 2014, p. 128), puisqu’ils placent chaque participation dans un nouveau réseau de contraintes et d’interdépendances ; la dernière découle de l’interactivité propre aux jeux vidéo. Puisque les possibilités de mouvement et d’action du joueur sont innombrables, leurs anticipations par les développeurs ne sont souvent que partielles. La build, dès lors, est l’espace où se cristallisent ces anticipations incomplètes ou ratées et où se matérialisent les cas d’action n’ayant pas été pris en compte (puisqu’elle est le premier environnement « jouable » en « conditions réelles »). eux horizons temporels se croisent : celui du présent du développement, puisque la build doit rester suffisamment stable et fonctionnelle pour que chacun puisse analyser son travail « en contexte », et celui du futur de la commercialisation, puisqu’aucune défaillance majeure ne doit subsister lors de la prise en main par le consommateur final. La réactualisation permanente de la connaissance de son état est, dès lors, un enjeu fort du développement. Ils jouent le rôle d’un utilisateur fictif qui alerte l’équipe de développement sur les éléments venant empêcher l’expérience ou en amoindrir la qualité : déclenchement d’action incomplet ou inadapté, absence d’éléments de contenu (graphiques, sonores, animations, etc.), freins à la progression, manque de stabilité du code, etc. Cette recherche de bugs est principalement effectuée par le biais de la méthode du « test destructif », dans lequel le testeur explore un niveau jusqu’à rencontrer une défaillance, qui doit être notifiée au reste de l’équipe. Pour ce faire, un logiciel spécialisé de gestion de base de données de bugs (tel que Jira ou Mantis Bug Tracker), est mis à leur disposition, dans lequel chacune des anomalies est numérotée et décrite. Une fois créé, ce « ticket » est assigné à une équipe, qui devra se charger de résoudre la défaillance (ou de le réassigner à son tour si elle estime que sa résolution sort de son champ de compétence). Pourtant, cette particularité met aussi au jour la porosité de la frontière entre actes de création et de maintenance, l Les testeurs constituent une interface sensible entre le monde ludique en construction et les autres développeurs. Par leur travail d’exploration et d’alerte, ils sont le premier chaînon de la stabilisation et de la consolidation du produit. Ils amorcent le processus de structuration de la perception collective des défaillances. En créant des artefacts numériques qui impliquent les acteurs au gré de leur circulation et de leur catégorisation, ils autorisent, non sans négociations et frottements, la coexistence de mondes sociaux épistémiquement distincts. Ces actes d’inscriptions successifs « aplatissent » (Latour, 1985) progressivement un réel trop imbriqué pour être intelligible, tout en faisant émerger le relief de la représentation. En outre, une fois stabilisés (stabilité, nous l’avons vu, toujours relative), ces objets se fondent dans l’écologie ordinaire de l’action productive et outillent de multiples pratiques grâce à leurs propriétés représentationnelles et référentielles. Ce travail d’articulation uploads/Management/ tony-si-dissert-individuellee.pdf