Le système d'information (S.I.) (ensemble des informations et règles de gestion de ces informations) est l'instrument de la coordination entre les acteurs d'une organisation. Il assure 3 fonctions : le traitement, la mémorisation et la circulation de l'information.

Il évolue au cours du temps par
- l'introduction de nouvelles applications qui couvrent des besoins nouveaux ou pas encore automatisés
- l'ajout de fonctionnalités aux applications existantes,
…

Le management dit quoi faire tandis que la gestion dit comment faire. (Management is to do the right things and administration is to do right the things.) En matière de S.I., le management décide des projets d'informatisation, d'évolution… sur la base de différents critères au nombre desquels on trouve le coût.

Pour déterminer le coût d'un projet (de développement), on peut utiliser des modèles de coût.

Il s'agit de déterminer le coût d'un projet avant de l'avoir réalisé.

Deux approches sont possibles :
- par décomposition du projet en tâches élémentaires dont on estime la durée et l'effectif requis pour les mener à bien, c'est l'approche analytique. Les charges des différentes tâches sont ajoutées les unes aux autres pour donner la charge du projet tout entier.
- par une approche globale qui consiste à estimer la charge d'un projet en se basant sur l'expérience, à partir d'éléments objectifs, tangibles, propres au projet.

L'analyse méthodique procède par décomposition en un plan détaillé et addition des charges du plan. Elle permet d'estimer le coût total d'un projet ainsi que l'évolution du coût au cours du temps (plus on avance dans le projet, plus le coût - cumul des dépenses - augmente).

Ce coût peut être compatible avec le budget disponible ou pas et détermine ainsi la décision de départ (Go / No Go).

En effectuant un suivi régulier au cours du projet, on peut apprécier si la réalisation est conforme aux prévisions en termes de délai et de coût et décider ainsi de l'arrêt du projet (retard et/ou surcoût trop important) ou de sa poursuite (Stop or Go). Le modèle de la valeur acquise fournit les informations utiles à cette décision (stop or go) et des indicateurs de performance du projet…

Exercice sur la valeur acquise

Cet exercice illustre le besoin de quantifier l'avancement des tâches, ce qui est relativement facile quand le produit du projet est concret, physique. Qu'en est-il pour le développement d'un logiciel ? Quelle pourrait être la mesure de l'avancement ?

Les indices de performance peuvent constituer les coordonnées des points d'un graphe qui illustre l'évolution du projet au cours du temps en termes de délai (efficacité en abscisse) et de coût (efficience en ordonnée), le graphe de tendance coût-délai.

Cette approche méthodique suppose :
- de n'oublier aucune tâche dans le découpage du projet;
- d'estimer correctement la charge de chaque tâche;

Plus l'ampleur du projet est grande, plus ces conditions sont difficiles à satisfaire. Cette approche conduit alors à sous-estimer la durée et l'effectif… et le projet semble être toujours en retard, toujours en dépassement du budget, ce qui conduit les équipes à faire vite et mal pour y arriver ! Il faut donc une autre approche qui découpe le projet en grandes phases de travail, sans entrer dans le détail de toutes les tâches à mener à bien (ce dont on n'est pas capable).

Exercice basé sur les grandes phases d'un projet
Pour plus d'informations sur le projet de cet exercice, on pourra lire les articles parus sur le-ticket.fr et sur igen.fr.

Les modèles de coût empiriques sont basés sur l'expérience et proposent de calculer la charge (et la durée) à partir d'unités d'œuvre propres au projet, sur quelques grandes phases du projet.

La méthode RACINES (RAtionalisation des Choix INformatiquES) a été conçue en 1976 par le ministère français de l'industrie et formalisée dans un guide publié en 1988. A partir d'unités d'oeuvre de MERISE, RACINES permet de calculer les charges de travail de 3 phases d'un projet d'informatisation :
- l'analyse fonctionnelle
- la réalisation
- l'intégration.

Exercice RACINES

CoCoMo a été conçue en 1981 par Barry Boehm. C'est une méthode statistique basée sur 63 projets de développement de logiciels de 2 000 à 1 000 000 lignes de code. Elle permet de calculer l'effort et la durée d'un projet de développement de logiciel à partir de sa taille et de sa complexité. Des tableaux fournissent les coefficients pour répartir l'effort et la durée sur les 4 phases du projet :
- spécification et planification
- conception générale
- programmation
- intégration et tests.

Exercice CoCoMo pour lequel les calculs pourront être faits avec cette application au tableur

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'oeuvre. Mais estimer la taille suppose de l'expérience.

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) ! La méthode des points de fonction répond à cette question.

Exercice sur les points de fonction pour lequel les calculs pourront être faits avec cette 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'oeuvre retenir ?

Toujours est-il que ces modèles de coût correspondent aux approches classiques de gestion de projet. Mais qu'en est-il des approches agiles ?

Les approches agiles diffèrent des approches classiques par leur cycle de vie qui répète des périodes de travail courtes avec livraison partielle au client plutôt qu'une seule longue période de projet avec livraison complète à la fin du travail.

C'est le cas de l'approche Scrum dont les itérations, appelées sprints, suivent toutes le même schéma :
- planification
- production
- revue d'itération
- rétrospective d'itération
ponctué de réunions quotidiennes, les mêlées (daily scrum).

Le cahier des charges agile prend la forme d'un carnet de commande (product backlog) constitué de différentes attentes formulées en petits scénarios d'utilisation, les histoires d'utilisateur (user stories).

La planification dans les approches agiles est basée sur un modèle de coût spécifique, qui s'appuie sur :
- l'effort estimé en points de difficulté,
- la valeur des attentes, fournie par le client ou le porteur du produit (product owner).

L'estimation de la difficulté se fait au cours d'une réunion de planification, le poker d'estimation ou planning poker.

La valorisation de la difficulté des attentes du carnet de commande permet la planification agile qui consiste à établir un plan de livraison. A celui-ci correspondent …
- une baisse au cours du temps de la charge de travail restante
- une augmentation de la valeur du produit livré au client
illustrées par des graphiques prévisionnels du TAF et de la valeur.

La valeur du produit livré (éventuellement ramenée au budget du projet) peut être comparée à la valeur acquise des approches classiques de gestion de projet. L'observation des courbes de la valeur du produit (approche agile) et de la valeur acquise (approche classique) montre un accroissement rapide de la valeur dans les approches agiles (qui diminue ensuite) quand les approches classiques se caractérisent par un accroissent lent la valeur acquise (qui augmente ensuite). La décision d'arrêt du projet en cas de retard est plus facile à prendre dans les approches agiles puisqu'un produit répondant partiellement au besoin est utilisable et que ce qui lui manque a peu de valeur pour le client qui peut donc y renoncer.

Exercice de planification agile

Au cours de chaque itération, un outil est utilisé pour coordonner et suivre le travail des membres de l'équipe : le tableau d'itération ou tableau des tâches.

A la fin de la revue d'itération les graphiques de suivi du TAF et de la valeur peuvent être mis à jour pour illustrer le retard, la conformité ou l'avance par rapport aux prévisions.

Exercice de suivi agile

En cas de retard, les tâches encore "à faire" ou "en cours" à la fin d'une itération sont reportées "à faire" ou "en cours" pour l'itération suivante et les attentes qu'on avait prévu de traiter au cours de la prochaine itération ne sont pas toutes portées "à faire" dans cette itération. Si au contraire l'équipe a pris de l'avance, on inclut dans le travail "à faire" des éléments initialement prévus ultérieurement. Le plan de livraison est donc revu à la fin de la rétrospective pour tenir compte de la vélocité réelle de l'équipe.

Exercice de révision du plan de livraison

La gestion de projet vise à respecter le budget tout en tenant les délais. Mais il ne faut pas oublier la qualité et la sacrifier au profit du délai et/ou du budget. Remettre à plus tard une réécriture revient à emprunter du temps qu'il faudra rembourser par de la maintenance corrective par exemple. Malheureusement, le temps que cela prend quand on ne le fait pas tout de suite est plus long, un peu comme si on devait rembourser des intérêts en plus du capital. C'est pourquoi on appelle les défauts du code de la dette technique. Le coût de cette dette est énorme.

On pourra lire à ce sujet deux articles de juin 2022 : article paru dans "Le monde informatique" et article publié sur LinkedIn.

Il faut donc toujours avoir en tête la qualité et ne rien livrer qui ne soit terminé. Par leur processus itératif avec validation à chaque revue d'itération, les approches agiles encouragent et permettent la qualité. Mais cela suppose une définition stricte de fini (DoD pour Definition of Done) et la connaissance des critères d'acceptation du client.

Décider de développer une nouvelle application, de faire évoluer une application existante, de remplacer une application par une autre, en bref de réaliser la transformation numérique de l’entreprise suppose d’en connaître les processus. Le coût intervient dans la décision, mais ce n'est pas le seul critère ! Une activité ne peut être automatisée que si elle est bien comprise.

A cet effet, un outil, la cartographie des processus, permet :
- d'analyser finement le fonctionnement de l'entreprise ;
- de localiser les processus clés ;
- d'aider à comprendre les interactions entre eux.

Pour cartographier les processus, on peut démarrer la représentation par les intrants (inputs) principaux (commande client, réclamation, …) et associer le(s) processus participant à l'atteinte des objectifs et la production des principaux extrants (outputs). Cela renvoie aux fonctions du S.I. (traitement, circulation et mémorisation de l'information) et à la représentation des flux d'information.

Un flux d'information est un ensemble de données qui circulent en même temps (une commande, une facture, un bulletin de paie…) entre deux acteurs : l'émetteur et le destinataire.

MERISE propose de représenter les flux d'information entre le S.I. et les acteurs externes au moyen d'un modèle de contexte ou diagramme brut des flux. En s'intéressant à l'activité, la représentation ou modèle conceptuel des flux, fait apparaître les processus au sein de l'organisation, processus que l'on peut détailler en activités entre lesquelles des informations sont échangées. On peut aussi s'intéresser aux acteurs internes entre lesquels des informations sont échangées. Le graphe des flux et des acteurs en rend compte.

La circulation de l'information et les traitements étant liés, il existe des modèles qui mixtent les fonctions circulation et traitement. C'est le cas du diagramme de flux de données de l'analyse structurée (SA) et du schéma de circulation des documents de MERISE.

Alors que la cartographie a pour objectif de représenter graphiquement les principaux processus et les interactions entre eux, la modélisation va plus loin, en explicitant le fonctionnement du système.

La modélisation des processus fournit un support pour se donner les moyens de
- formaliser la manière de fonctionner du système
- la comprendre
- l’analyser
- l’optimiser
- la faire évoluer.

MERISE propose trois modèles des traitements correspondant à ses trois niveaux de description du système d'information.

Le modèle conceptuel des traitements décompose le processus en opérations et le décrit indépendamment des choix d'organisation.

Exemple de modèle conceptuel des traitements

Les choix d'organisation (niveau d'automatisation, affectation à un poste de travail) sont pris en compte dans le modèle organisationnel des traitements qui décrit la procédure (et ses différentes phases constitutives) correspondant à une opération du modèle conceptuel.

Exemple de modèle organisationnel des traitements

Le modèle opérationnel des traitements décrit les phases automatisées du modèle organisationnel et précise les accès aux données et l'interface utilisateur au moyen de dessins d'écran.

UML propose différents points de vue sur le système d'information

Parmi les diagrammes de comportement, le diagramme de cas d'utilisation recense les opérations sans les décrire tandis que le diagramme états-transitions illustre les différents états que peut prendre un objet en fonction des traitements réalisés. Le diagramme de séquence explicite le déroulement des choses tout comme le diagramme d'activité, qui sert à expliciter un cas d'utilisation, une méthode ou un processus.

Exercices sur le diagramme d'activité

Les différents acteurs impliqués dans un processus peuvent être représentés par des couloirs verticaux (des colonnes) mentionnant leur nom en entête et permettant de distribuer les noeuds du diagramme d'activité pour préciser qui fait quoi. De plus, l'avancement du processus peut être explicité en reliant les opérations à des objets (instances de classes) avec mention de leur état noté comme une condition (entre crochets). diagramme d'activité avec couloirs et objets dans différents états

Même si UML permet de modéliser les processus, les concepts utilisés (classes, objets, cas d'utilisation, méthodes…) sont trop techniques pour des experts métier (non développeurs). La norme BPMN (Business Process Modeling Notation) a été conçue spécialement pour eux en répondant à leurs besoins.

UML et BPMN sont deux normes de l'Object Management Group. Le standard BPMN 2.0 de janvier 2011 spécifie les éléments graphiques des modèles, leur sémantique et leur exécution, ce qui permet de convertir les diagrammes en modèles de processus et de les exécuter avec un moteur BPMN.

Appelé aussi processus d’affaires ou processus d’entreprise ou processus opérationnel, un processus métier (business process) est un ensemble d’activités corrélées ou en interaction qui contribuent aux finalités des affaires d’une organisation. Il est représenté par un graphe dont les éléments sont répartis dans des groupes éventuellement compartimentés en phases.

Exercice 1 de BPMN

La notation précise la temporalité et la nature des événements et propose différents types de branchements ainsi que différents types de tâches et marqueurs d'activité.

exemple d'escalade et de sous-processus

Exercice 2 de BPMN

Tout BPMN 2 en un poster !

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 (interactions trompeuses).

L'é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…
- à la décision de
- pendant
la transformation numérique de l'organisation.

Des 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 dimensions.

« La technologie n’est ni bonne, ni mauvaise. Elle n’est pas neutre non plus. » (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.

Il faut donc parvenir à une éthique par dessein (by design), qui considère les questions éthiques le plus tôt possible et dans le suivi des innovations techniques.

Cette partie de "Management des systèmes d'information" est évaluée par :
- un examen écrit ;
- un mini-projet.
La partie de Monsieur Jean-Luc Lambert est évaluée séparément.

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 sujet et le corrigé de l'année 2021-2022.
/!\ Un exercice de suivi agile comptera pour l'apprentissage critique AC4 "Mettre en oeuvre 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".

C'est un travail de modélisation à réaliser en groupe de 2 et à rendre pour le 13 décembre 2023 sur le dépôt prévu à cet effet sur eCampus.

sujet

site de téléchargement du logiciel Camunda Modeler