De la conception en informatique

Voir le sujet précédent Voir le sujet suivant Aller en bas

De la conception en informatique

Message par quid le Jeu 25 Aoû 2016 - 14:09

Kercoz a écrit:- Plus tard vint le pékin informaticien..qui va être le seul a pouvoir "parler" au système. Mais ce gus n' a aucune heure de philo dans son cursus ! et c'est lui qui va imprimer la façon de bosser et vider ceux que ses statistiques lui indiqueront comme n' ayant pas atteint le quota.
- Actuellement le langage doit être parvenu à l ' économique, au commercial ....je passes.

C'est cette notion de pouvoir dans la langue que je veux mettre en avant. Mes rapports de controles ont été bouleversés par ce pékin "qualifié" non pas dans l' intéret du type qui grimpe sur la grue, mais pour faciliter l' agencement et le boulot du prog.
Un simple exemple : Pour les visites périodiques d' un poste HT/BT, je me servais du rapport précédent, je pouvais modifier les dates de visite, le titre du rapport, du lieu ...etc , mais pas le nom de l'ingénieur qui fait le controle ( si un collègue avait fait la visite l' année précédente). Il n' y a aucune raison rationnelle à cette impossibilité et ça a été la croix de la bannière pour le lui faire avouer...simplement ça lui impliquait 1 à 2 heures de boulot de plus pour modifier sa programmation.
La réponse du type était systématique :...j' ai mes raisons qui ne vous sont pas accessibles ( ce en quoi il se trompait).

Je réagis sur ce qu'a dit Kercoz ici, http://digression.forum-actif.net/t1257-que-pensez-vous-du-mepris-de-la-philosophie#30942, et je vais essayer d’éclaircir la problématique.

D’abord sur cela :

Kercoz a écrit:Un simple exemple : Pour les visites périodiques d' un poste HT/BT, je me servais du rapport précédent, je pouvais modifier les dates de visite, le titre du rapport, du lieu ...etc , mais pas le nom de l'ingénieur qui fait le contrôle ( si un collègue avait fait la visite l' année précédente). Il n' y a aucune raison rationnelle à cette impossibilité et ça a été la croix de la bannière pour le lui faire avouer...

D’abord je suppose que HT/BT, çà veut dire Haute-Tension / Basse-Tension. Rien d’évident pour moi, mais je le déduis et le suppose d’après ce que tu dis là :
« J' ai contrôlé les installations électriques et de levage de tout ordre durant près de 30 ans. », c’est donc certainement un « jargon » de la profession.

Il faut voir qu’en informatique les données prennent généralement leur place dans un modèle de données. Cela est le cas en particulier, lorsque ces données sont prévues pour être exploitées par une application.
Cependant, le modèle de données ne sera pas le même pour une application de maintenance que pour une application de gestion commerciale par exemple.
On est obligé de passer par cette organisation des données pour structurer  l’application. Et le modèle de données et l’application se font un peu miroir. Car le modèle de données est conçu au moment du développement en fonction de l’objectif général de l’application, ainsi que de ses cas d’utilisation qui déterminent ses fonctionnalités.

Le modèle de données le plus couramment utilisé est un modèle de données relationnel. On raisonne par entités de données et de relations entre ces entités. C’est à dire que l’on va identifier des entités unitaires, des catégories en quelque sorte.

Par exemple, suivant l’application, on va sans doute dédier une de ces entités aux « Personnes », et l’on ne va pas sans doute pas créer à chaque fois une nouvelle instance d’une entité « Personne » lorsque l’âge de la personne change ; l’âge sera alors un attribut de cette entité et donc de chaque instance particulière. De la même manière, on va aussi distinguer une entité « Visite », qui aura attrait à une visite particulière.
Les entités peuvent être des plus abstraites. Ici on est encore dans le tangible en quelque sorte.

Il n’y a pas qu’une seule manière de modéliser. C’est pour cela qu’on essaie d’étudier les cas d’utilisation le plus exhaustivement possible pour définir le modèle de données le plus approprié. Mais d’une part, on atteint rarement l’exhaustivité attendue, et d’autre part, pour une même spécification de cas d’utilisation, il n’y aura pas forcément les mêmes choix de modèles qui seront fait d’une équipe de développement (équipe pouvant parfois se résumer à une seule personne) à l’autre.

- Par exemple le modèle de données pour la visite d’équipements par des intervenants pourrait être celui-ci :

En plus des entités, il faudra donc mettre en relation ces entités. Ici le diagramme indique qu’une entité « Intervenant » peut très bien exister sans visite (0..) (ne pas encore en avoir fait) et peut et pourra faire plusieurs visites (..*).
Une visite, elle, a un et un seul (1) intervenant mais peut concerner plusieurs équipement (..*), mais au moins un (1..).

On voit donc que l’application prévoie d’abord l’existence et la création des intervenants et des équipements, avant de pouvoir créer des visites, et que les visites ne doivent pas pouvoir être créées sans référencer un intervenant et un équipement.

Cela ne veut pas forcément dire que que les fonctionnalités "colleront" complètement à cette contrainte, et que l'on devra systématiquement passer par des fonctionnalités isolée de création d'intervenants, ou d'équipements, ... On peut très bien avoir une fonctionnalité, un écran, qui permet de créer les équipements ou les intervenants en même temps que les visites, pour apporter une certaine souplesse lorsque l'on s'aperçoit qu'ils n'ont pas encore été référencés. Mais c'est un cas d'utilisation distinct, et cela n'empêchera pas que d'un point de vue technique, cela ne sera pas une seule et même opération ; il y aura bien toujours la création d'un intervenant et des équipements, avant la visite.

En terme de diagramme d’instances, cela peut être schématisé comme cela :


- On pourrait aussi imaginer ce modèle là :

Mais ici on voit qu’il y a alourdissement et redondance de l’information, ainsi qu’un manque de centralisation. Car le nom de l’intervenant qui ne changera pas pour une personne va se répéter dans chaque visite, et si l’on veut avoir d’autres informations sur l’intervenant, il faudra rajouter à nouveau ces informations dans l’entité « Visite ».
La fonction de l’intervenant peut changer et ne sera plus forcément correcte dans les instances antérieures et pourra alors être différente d’une « Visite » à l’autre, avec en plus un risque de mauvais renseignement de celle-ci (à moins que ce qui nous intéresse soit de connaître la fonction de l’intervenant au moment de la visite)

Bref, il faut bien organiser les données de manière à ce qu'elles soient plus distinguables et exploitables.

- On pourrait également avoir ce modèle là, peut-être un peu mieux :


Ici une visite peut être faite potentiellement par plusieurs intervenant, mais l’on entend par visite, la visite d’un seul équipement. Ainsi, une visite pourra détailler plus précisément le rapport concernant chaque équipement, et l’on créera une visite par équipement. Cela permettra aussi, lorsque l’on interrogera un équipement de ne voir que les remarques le concernant.

Entre le premier modèle et le troisième, le format des tables stockant les données ne sera pas le même, bien qu’il ne semble y avoir qu’un petit changement au niveau des cardinalités des associations. La spécification des cardinalités est relativement engageante de ce point de vue.

De plus, si l’on est parti dans un premier temps vers le premier modèle pour faire correspondre à une visite plusieurs équipements, la signification de la visite dans le troisième modèle n’est plus la même. Donc dans une application déjà en service avec déjà des données produites, il faudra prévoir une conversion assez lourde pour se diriger vers le second modèle. Je passe sur toutes les difficultés induites, lorsque l’application et les données doivent être mises à jour chez plusieurs utilisateurs ou plusieurs clients. Il faut alors une vrai stratégie de mise à jour.

Le modèle de données est engageant, mais n’est pas toujours forcément visible dans les interfaces utilisateurs.
Ainsi, dans l’interface utilisateur, on aura sans doute un écran ou l’on pourra indiquer un intervenant au même titre qu’une date ou qu’un commentaire, sans que l’on voit forcément qu'au niveau du modèle, l’intervenant relève d’une association avec la visite, et non d'un attribut de la visite.

C’est pour cela que penser pouvoir utiliser une visite précédente en pensant la modifier pour spécifier la nouvelle peut être contraire au modèle qui envisage des visites distinctes même en cas de visites régulières.
C’est à dire qu’il est vrai que l’utilisateur serait tenté de rappeler dans ce cas la visite de l’année dernière pour ne pas avoir à ressaisir certaines informations, mais le cas d’utilisation ici n’est pas la modification d’une visite, mais la création d’une visite sur la base d’une autre.
L’utilisateur, voit alors son opération comme la fiabilisation des informations et un complément des visites, alors qu’il s’agit en fait pour l’interface de prévoir un cas d’utilisation qui permette la création d’une visite sur la base de la précédente. Or, effectivement, si la fonctionnalité en question n’est pas prévue, le problème n’est pas juste de permettre de « modifier le nom de l’utilisateur ».

Mais ce n’est pas forcément de là que peut provenir la difficulté, cela peut aussi venir du fait que par exemple, on a voulu faire évoluer l’application pour permettre de traiter des visites périodiques, alors que le modèle de départ n’avait pas été prévu pour cela. Ainsi, on n’aurait pas prévu que dans le cadre de visites périodiques modélisées par une seule et même entité visite, il puisse y avoir plusieurs intervenants successifs.

- En gros, pour traiter des visites périodiques, toutes rapportées à un même processus de visite, il aurait peut-être fallut avoir adopté un autre modèle de données et introduire une entité relative à la périodicité  :



Tout cela pour montrer que lorsque l’on voit une information non modifiable dans un écran, ce n’est pas si évident que cela, puisque ce n’est pas forcément seulement un texte dans un champ de saisie mais cela peut-être une association effective (cas d’une modification), qui peut être un cas d’utilisation non prévu plus qu’une simple modification.

Ou encore un dilemme conceptuel, car si l'on permettait de modifier cette information, cela introduirait une incohérence. (Par exemple, on n'aurait plus que l'intervenant ayant fait la dernière visite)

Je pense que ce genre de problématique est plus large, c’est le rapport de l’utilisateur, quelque soit l’outil, avec le concepteur.

Il y a d’autres problématiques de ce genre. L’une par exemple, est de vouloir introduire des fonctionnalités qui peuvent paraître évidentes ou simples quand on elles sont dites verbalement, mais qui posent un problème avec le modèle existant. En gros souvent l’utilisateur est concentré sur sa problématique du moment, mais ne voit pas forcément la contradiction avec d’autres fonctionnement du logiciel. Le concepteur, lui doit s’efforcer d’évaluer les implications sur l’ensemble, que ce soit en terme de cohérence, de faisabilité, de difficulté, de temps, de coût, de gain, d’évolutivité, …
Cela peut amener des discussions sans fin jusqu’à ce qu’il soit mis devant les yeux en quoi cela pose problème. Ce n’est pas de la mauvaise volonté, c’est juste que d’un point de vue c’est problématique alors que de l’autre çà paraît si simple quand on le dit dans une seule phrase.

Kercoz a écrit:simplement ça lui impliquait 1 à 2 heures de boulot de plus pour modifier sa programmation

Le fait est que le développeur est de plus en plus assimilé à un artisan, qui fait un travail a un moment donné, alors qu’en même temps on attend d’un logiciel qu’il soit évolutif aux besoins.

Ce sont deux approches, qui s’excluent l’une l’autre. Soit l’on fait des développements à façon et dédiés, mais on se prive de l’évolutivité, et l’on arrive à un certain mécontentement, car on n'a alors plus cette aspect évolutif du programme informatique, qui est quelque part attendu.

Soit l’on cesse de voir le développement informatique comme de l’artisanerie, et on pense en terme d’amélioration et d’évolutivité.

Dans le second cas, cela demande plus de précaution et d’organisation. En général, on considère au minimum que 50% du temps de développement d’une application est censée être investi dans la documentation technique et fonctionnelle, et ceci pour les besoins d’évolutivité et de maintenabilité.

La première approche, celle de l’artisanerie, c’est souvent le rapport qui s’instaure lorsque les équipes de développement sont directement en contact avec les donneurs d’ordre ou même des utilisateurs. Ces équipes doivent alors en plus s’improviser maître d’oeuvre, ce qui n’est pas facile lorsque l’on a des utilisateurs qui ne voit que leur pré carré.

Car c’est normalement le rôle d’un maître d’oeuvre, en concertation avec le maître d’ouvrage, de définir correctement les contours du projet. Il y aura cependant toujours quelqu’un qui connaît son métier, mais sans pouvoir décider à la place de celui qui a besoin de ses services et qui ne le connaît pas.

Le problème étant, dans la maîtrise d’oeuvre concernant une application informatique, d’intégrer ou non l’évolutivité du produit, ce qui n’est pas du tout évident, car il faudra essayer ne pas se laisser enfermer par les choix de départ.


Dernière édition par quid le Jeu 25 Aoû 2016 - 14:58, édité 1 fois

quid
Digressi(f/ve)
Digressi(f/ve)

Nombre de messages : 721
Date d'inscription : 04/08/2012

Voir le profil de l'utilisateur

Revenir en haut Aller en bas

Re: De la conception en informatique

Message par kercoz le Jeu 25 Aoû 2016 - 14:54

D'abord chapeau pour ce boulot! impressionnant.
Il se trouve que j' ai aussi un DUT informatique ( gagné de haute lutte sous Jospin et la grande Alice qui géraient l' iut).
Je ne parle donc pas d'abus de pouvoir à la légère. Je te rappelle que c'est le "Pouvoir du langage " que je voulais mettre en évidence sinon dénoncer.
Ces structures de controles règlementaires ne couvrent qu' une vingtaine de personnes. Celui qui distribue les visites ( en réalité la secrétaire) est le patron ou le responsable technique du domaine controlé. S' il y a plusieurs domaines, il y a plusieurs type de rapports. La problématique qui peut se poser se situe dans la corrélation entre la visite et les agréments ( aptitudes) du controleur. Par exemple mes agréments étaient dans le domaine électrique de TBT à THT réseau et machines ( Tres basse tension à Tres haute tension). BE2 et BE3 ( installations à risque incendie et risque explosion ( comme poudreries et silos agricoles).. ERP 1 à 5 ( etablissements recevant du public 1ere à 5eme cat.) ...qui dépendent d' une règementation supplémentaire , à l' époque l' A. M. 80 obligeant à un rapport différent. IGH ( immeubles de grandes hauteur).
Cette corrélation devrait etre controlée par le responsable qui confie la mission.
En réalité.
9 fois sur 10 la mission est confiée à un habitué de cette mission surtout du fait qu' il connait les lieux , les installations, les gens, ce qui réduit les causes de conflits.
Le responsable technique délègue la distribution à une secrétaire et s'il y a problème d' incohérence , d' incompatibilité géographique ( distance de la plage) ou autre , le conflit se règle entre la secrétaire et surtout l' intervenant qui va refuser une intervention qui sort de sa compétence.
C'est vrai que dans une méga structure, l' impossibilité de changer le nom pourrait être un verrou de controle des compétences de la visite , mais je t'assure que ce n' était jamais le cas...il faut juste se renvoyer la page de titre à la main avec des séries de nombres à 20 chiffres ...sources d'erreur.

_________________
TIMSHEL

kercoz
Digressi(f/ve)
Digressi(f/ve)

Nombre de messages : 1844
Date d'inscription : 01/07/2014

Voir le profil de l'utilisateur

Revenir en haut Aller en bas

Voir le sujet précédent Voir le sujet suivant Revenir en haut

- Sujets similaires

 
Permission de ce forum:
Vous ne pouvez pas répondre aux sujets dans ce forum