Différences

Ci-dessous, les différences entre deux révisions de la page.

--- departement_info:personnels:pb:r3.10 [2024/10/13 21:15] – [Modèle de coût agile] Brutus Philippe
+++ departement_info:personnels:pb:r3.10 [2024/11/25 18:36] (Version actuelle) – [Ethique du numérique] Brutus Philippe
@@ Ligne 68: / Ligne 68: @@
 Dans les années 1970, de nombreux experts du développement ont constaté une corrélation entre la taille du logiciel et l'effort et la durée du développement. Pour cette raison, Barry Boehm a conçu son modèle sur la base de cette unité d'œuvre. Mais estimer la taille suppose de l'expérience... et tout peut être remis en question si on change de langage !
-Dans le cas de réécriture d'une application (passage d'application de bureau à application web par exemple, à condition que les langages utilisés aient des pouvoirs d'expression comparables - java et PHP par objets, C et PHP sans objets) ou lorsqu'il faut réécrire une partie du code d'une application (changement d'algorithme pour de meilleurs temps de réponse), on peut faire l'hypothèse que la taille est à peu près égale à celle de départ. Mais reste à estimer la taille quand il s'agit d'un développement nouveau (à partir de rien, //ex nihilo//, //from scratch//) !
+Dans le cas de réécriture d'une application (passage d'application de bureau à application web par exemple, à condition que les langages utilisés aient des pouvoirs d'expression comparables - java et PHP par objets, C et PHP sans objets) ou lorsqu'il faut réécrire une partie du code d'une application (changement d'algorithme pour de meilleurs temps de réponse), on peut faire l'hypothèse que la taille est à peu la même que celle de départ.
-La méthode des {{:departement_info:personnels:pb:R3.10:points_de_fonction.pdf|points de fonction}} répond à cette question.
-{{:departement_info:personnels:pb:R3.10:exercice_points_de_fonction.pdf|Exercice sur les points de fonction}} pour lequel les calculs pourront être faits avec cette {{:departement_info:personnels:pb:R3.10:application_racines.xlsx|application au tableur}}
 Ces modèles sont-ils encore applicables en l'état de nos jours, compte tenu de l'évolution des méthodes (modélisation en UML plutôt qu'en MERISE), des langages de programmation et des outils (Environnement de développement intégré - //Integrated Development Environnement//; //framework// et intelligence artificielle générative) ? Quelles unités d'œuvre retenir ?
@@ Ligne 115: / Ligne 112: @@
 {{:departement_info:personnels:pb:R3.10:exercice_revision_agile.pdf|Exercice de révision du plan de livraison}}
+----
+La valorisation par le client des attentes du carnet de commande et l'estimation par l'équipe de leur difficulté en points de récit permettent d'établir le plan de livraison. Cependant la mesure de la difficulté en points de récit est {{:departement_info:personnels:pb:R3.10:remise en question.pdf|remise en question}}.\\
+Qu'importe pour les nombreuses équipes agiles à ne pas faire de poker d'estimation. A la place, elles préfèrent une réunion pour bien comprendre les récits utilisateur, les reformuler si nécessaire, les décomposer en plusieurs récits... On appelle cette réunion //backlog refinement//. Elle conduit alors à un carnet de commande dans lequel toutes les attentes ont une difficulté à peu près équivalente et il devient inutile de les estimer. Le nombre d'attentes prises en charge à chaque itération est alors à peu près le même.
+Cependant, que l'on fasse une réunion d'estimation ou une réunion d'affinage du carnet de commande, comment fixer le nombre de personnes de l'équipe agile, ainsi que le nombre et la durée des itérations. C'est la question de la charge de travail qui reste posée. Certains proposent d'utiliser les {{:departement_info:personnels:pb:R3.10:points de fonction COSMIC.pdf|points de fonction COSMIC}} pour estimer l'effort requis pour mener à bien le projet (voir [[https://assemi.fr/cosmic-la-methode-de-mesure-logicielle/|COSMIC]]).
+----
 ==== Triplet coût-délai-qualité ====
@@ Ligne 202: / Ligne 206: @@
 La décision de développer une application ou un service ne se prend pas que sur la base du coût du projet ou de la connaissance du processus à automatiser.\\
-L'informatique utilise des données, parfois personnelles et nominatives, qui peuvent être utilisées à d'autres fins que ce que nécessitent les traitements automatisés. L'utilisation d'une application peut être détournée de sa vocation initiale. On peut aussi tromper l'utilisateur pour le faire agir contre son intérêt ([[https://www.atipik.ch/fr/blog/definition-dark-patterns-design-ux
+Il s'agit de rendre le Système d'information plus performant en offrant aux utilisateurs des applications utiles, pour le bien de l'organisation, des utilisateurs et des clients. Il ne faudrait pas que l'utilisation d'une application puisse être détournée de sa vocation initiale ou que l'on trompe l'utilisateur pour le faire agir contre son intérêt ([[https://www.atipik.ch/fr/blog/definition-dark-patterns-design-ux
-|interactions trompeuses]]).
+|interactions trompeuses]]).\\
+Par ailleurs, l'informatique utilise des données, parfois personnelles et nominatives, voire des {{:departement_info:personnels:pb:R3.10:donnees_sensibles.pdf|données sensibles}} qui pourraient être obtenues par des personnes non autorisées, voire altérées ou utilisées à d'autres fins que ce que nécessitent les traitements automatisés. Il faut veiller à sécuriser les applications pour se prémunir de ces agissements et respecter les obligations réglementaires en vigueur.
 L'{{:departement_info:personnels:pb:R3.10:ethique.pdf|éthique}} doit intervenir dans la décision du management (gouvernance des S.I.). En effet, l'éthique questionne trop souvent //a posteriori// alors qu'avec l'informatique, un problème éthique sera très difficile à régler dans la réactivité. Il faut être proactif et prendre en compte les considérations éthiques...\\
@@ Ligne 210: / Ligne 215: @@
 la transformation numérique de l'organisation.
-Des {{:departement_info:personnels:pb:R3.10:regles.pdf|lois, codes et chartes}} encadrent en partie les choses. Il faut y ajouter les multiples chartes propres à certaines organisations et que doivent signer les employés et éventuellement les usagers. Ils et elles rappellent des règles de bon sens, des principes éthiques ou de loi mais couvrent (partiellement) le sujet de l'éthique en ne traitant pas toutes ses {{:departement_info:personnels:pb:R3.10:dimensions.pdf|dimensions}}.
+« La technologie n’est ni bonne, ni mauvaise. Elle n’est pas neutre non plus. » ([[https://en.wikipedia.org/wiki/Melvin_Kranzberg|Melvin Kranzberg]]) car elle peut aussi avoir un impact positif ou négatif sur nous, sur nos sociétés, indépendamment de nos usages. Le numérique devient une norme, qui se heurte parfois à d'autres normes ou référentiels. Pour rééquilibrer les aspects normatifs négatifs du numérique, il faut inventer d'autres normes ({{:departement_info:personnels:pb:R3.10:normatif et ethique.pdf|normatif et éthique}}).
-« La technologie n’est ni bonne, ni mauvaise. Elle n’est pas neutre non plus. » ([[https://en.wikipedia.org/wiki/Melvin_Kranzberg|Melvin Kranzberg]]) car elle peut aussi avoir un impact positif ou négatif sur nous, sur nos sociétés, indépendamment de nos usages.
+Des {{:departement_info:personnels:pb:R3.10:regles.pdf|lois, codes et chartes}} encadrent en partie les choses. Il faut y ajouter les multiples chartes propres à certaines organisations et que doivent signer les employés et éventuellement les usagers. Ils et elles rappellent des règles de bon sens, des principes éthiques ou de loi mais couvrent (partiellement) le sujet de l'éthique en ne traitant pas toutes ses {{:departement_info:personnels:pb:R3.10:dimensions.pdf|dimensions}}.
 Il faut donc parvenir à [[https://www.cairn.info/revue-sciences-du-design-2019-2-page-61.htm(...)|une éthique par dessein]] (//by design//), qui considère les questions éthiques le plus tôt possible et dans le suivi des innovations techniques.
@@ Ligne 228: / Ligne 233: @@
-==== l'examen (23 novembre 2023 à 17h) ====
+==== l'examen (semaine du 4 novembre 2024) ====
 C'est une épreuve écrite surveillée d'une durée d'au plus 1 heure avec document manuscrit A4 recto-verso autorisé.\\
 Elle porte sur les modèles de coût (classique et/ou agile).
-Voici le {{:departement_info:personnels:pb:r3.10:sujet.pdf|sujet}} et le {{:departement_info:personnels:pb:r3.10:corrigé.pdf|corrigé}} de l'année 2021-2022.\\
+Voici le {{:departement_info:personnels:pb:r3.10:sujet.pdf|sujet}} et le {{:departement_info:personnels:pb:r3.10:corrigé.pdf|corrigé}} de l'année 2021-2022.
-**/!\** Un exercice de suivi agile comptera pour l'apprentissage critique AC4 "Mettre en œuvre un suivi de projet" de la compétence 5 "Appliquer une démarche de suivi de projet en fonction des besoins métiers des clients et des utilisateurs" de la S.A.É. S3.A.01 "Développement d’une application".
-==== le projet (13 décembre 2023) ====
+==== le projet (18 décembre 2024) ====
-C'est un travail de modélisation à réaliser en groupe de 2 et à rendre pour le 13 décembre 2023 sur [[https://ecampus.unicaen.fr/mod/assign/view.php?id=892411|le dépôt prévu à cet effet sur eCampus]].
+C'est un travail de modélisation à réaliser en groupe de 2 et à rendre pour le 19 décembre 2024 sur [[https://ecampus.unicaen.fr/mod/assign/view.php?id=892411|le dépôt prévu à cet effet sur eCampus]].
 {{:departement_info:personnels:pb:r3.10:sujet exercice de modélisation en BPMN.pdf|sujet}}