Demande d'avis sur la conception d'un petit projet GPAO!

Répondre


Cette question est un moyen d’empêcher des soumissions automatisées de formulaires par des robots.
Smileys
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :!: :?: :idea: :arrow: :| :mrgreen: =D> #-o =P~ :^o :non: :priere: 8-|
Voir plus de smileys
  Revue du sujet
 

  Étendre la vue Revue du sujet : Demande d'avis sur la conception d'un petit projet GPAO!

par basvic » 13 oct. 2005, 12:06

ReBonjour,
Désolé pour la réponse (très) tardive...
L'avis de tous les employés (autres que moi ;-) est assez bonne car on se dit tous que cela ne peut pas être pire (enfin j'espère ;-))).
Je pense que si cet utilitaire nous permettra d'améliorer certaines lacunes il n'en restera pas moins un outil et que comme tu le dis si bien, si personne ne s'implique réellement dans le projet... c'est perdu d'avance !!!
Merci à tous en tout cas pour vos remarques et vos conseils.
Pour le moment j'en suis à la fin de la 1ère étape! La structure de la base de donnée est presque finie. Je vous la présente dès qu'elle vérifier (heu par moi donc pas vraiment sûr ;-)
A bientôt

par pjl » 10 oct. 2005, 18:44

Si tu le fais en dehors de tes heures de travail, pourquoi pas mais en plus de ma remarque précédente, quel est l'avis du propriétaire du Véléda bleu ?

A mon avis, vu la taille de la boite, il y a intéret à ce que tout le monde s'approprie le projet sinon c'est mort né et j'ai comme idée que ce n'est pas le patron qui pourra l'imposer.

par Cyrano » 10 oct. 2005, 18:35

Tu auras trois étapes de toutes façon :
  1. Modélisation et conception de la base de données;
  2. Conception des requêtes SQL;
  3. Codage de l'application et intégration d'une interface graphique;
Pour la fin, tu auras le débuggage et la mise en service effectif.

Un petit projet intéressant, mais pas évident en partant d'un niveau de connaissance très limité. Encore une fois, ce serait à titre privé, je te dirais "Fonce", tu n'as rien à y perdre et tout à gagner en l'apprenant. Mais dans un cadre d'entreprise, j'aurais d'autres arguments pour dire que ce n'est pas du tout une bonne idée parce que ça va coûter très cher à l'entreprise.

par basvic » 10 oct. 2005, 17:48

En fait, on en a déjà un pour le moment qui fonctionne plus ou moins bien... Ce sont de jolis tableaux blancs sur lesquels on inscrit les commandes avec un feutre Veleda bleu ;-)
Et puis quand je parlai de logiciel... je voulais plutot dire "petit utilitaire" car il serait impossible pour moi de pondre un logiciel tel qu'il en existe déjà actuellement en vente avec des quantités d'options très bien pensées mais pas forcément utile à de petites structures comme la notre, d'où l'idée de ce "tout petit projet" qui je le rappelle n'a aucun autre but que d'afficher des commandes triées par date avec ses différentes étapes de production. C'est tout. En fait le seul problème pour moi est d'afficher les étapes avec les commandes car sinon je sais le faire dans des fenêtres séparées mais forcément beaucoup moins intéressant!
Et je fais parti des personnes qui vont utilisé le logiciel étant moi-même un peu ouvrier et passionné d'informatique!

par Cyrano » 10 oct. 2005, 17:39

:shock: Il faut que l'entreprise aie quand même certains moyens pour ça : apprendre le PHP ne se fait pas en quelques jours, le SQL non plus et la conception d'un logiciel ne s'improvise pas. Enfin bon, c'est pas mes oignons, mais ça me semble un peu imprudent comme méthode de gestion.

par pjl » 10 oct. 2005, 17:37

Et ba tout simplement, je pense que c'est un bon projet pour moi d'apprendre PHP
Et qu'en pensent les ouvriers qui seront quand même les utilisateurs du produit ?

par basvic » 10 oct. 2005, 17:36

En effet, cette une société de 7 personnes! Et là j'imagine la grande question mais alors poourquoi s'embetter à faire un logiciel de gpao pour une si petite entreprise ??? Et ba tout simplement, je pense que c'est un bon projet pour moi d'apprendre PHP et si cela intéresse d'autres petite société de fabrication, je leur donnerai volontier le code source... Mais bon il faut que j'y arrive d'abord ;-)

par Cyrano » 10 oct. 2005, 17:16

Pas de quoi. En fait, je te dirais que la création d'une base correctement structurée, c'est aussi un métier, c'est pour ça que je faisais cette remarque. L'entreprise étant, si j'ai bien compris, de taille quand même modeste ne peut pas se permettre de trop grands écarts budgetaires. CQFD, c'est toi qui vois :)

par basvic » 10 oct. 2005, 17:14

Heuuuu..... J'ai réalisé ma base de donnée comme il me l'a semblé la plus logique...! Maintenant moi et ma logique, effectivement je doute... ;-) Mais effectivement je vais me pencher sur ce problème aussi qui semble à priori le 1er à prendre en compte.
Merci

par Cyrano » 10 oct. 2005, 17:08

Question subsidiaire: as-tu fait une modélisation de ta base de données ? Parce que là, j'ai l'impression que tu es particulièrment rapide en besogne: Le problème des requête viendra bien assez tôt, la structure de ta base de données est à finaliser avant. Il faudrait commencer par correctement gérer les différents éléments et les relations en identifiant soigneusement les cardinalités.

Soit-dit sans aucune acrimonie, il serait opportun de faire appel à un consultant spécialisé pour réaliser ta base (note: je ne suis pas candidat, trop loin): ça coûtera nettement moins cher à terme qu'un bricolage qui te coûtera une fortune dans six mois quand tu réaliseras que la structure est à refaire :-k

par basvic » 10 oct. 2005, 17:07

Merci je vais essayer avec la jointure et je tiendrai au courant du résultat

par zeus » 10 oct. 2005, 16:54

Avec une jointure, tu devrais arriver à tes fins

Code : Tout sélectionner

SELECT liste des champs FROM commandes as c JOIN etapes AS e ON c.ID=e.comID

par basvic » 10 oct. 2005, 16:51

Ok, jusqu'à là j'avais pas trop faux visiblement. J'ai effectivement les tables suivantes :
- ateliers (ID, atelier) = juste pour récupérez les noms dans les formulaires
- clients (ID, societe, contact, telephone, fax, mail)
- commandes (ID, ref_com, groupe, clientID, prodID, designation, qte, delais, prioriteID, statusID, prevision) = juste les infos relatives à une commande
- etapes (ID, comID, ordre, atelier, travail, temps, commentaire, statutID, machineID, personnelID)
- machines (ID, marque, modele)
- personnel (ID, nom, prenom, fonction)
- priorites (ID, etat)
- statuts (ID, statut)
- travaux (ID, travail)

Donc pour afficher les commandes et toutes les étapes de chaque commande, je suppose que je ne peux pas faire qu'une seule requête mais plutôt 2 requêtes ; 1 pour sélectionner toutes les commandes classées par ordre de délais et une seconde pour sélectionner toutes les étapes de chaque commande ? Donc il faut vraiment faire une boucle dans une boucle ?

par Cyrano » 10 oct. 2005, 16:29

À première vue, je vois six tables:

Code : Tout sélectionner

commande: - cde_id (numéro de commande) - cli_id (identifiant du client) - pro_id - cde_delai - cde_priorite client: - cli_id - infos clients... produit: - pro_id etapes - pro_id \ - tra_id | clé primaire triple - res_id / - traite (oui | non) traitement - tra_id - tra_libelle responsable - res_id - res_nom
C'est sommaire, mais c'est la seule manière que je vois dans l,immédiat pour gérer ça proprement. Regarde les noms de champs, (il en manque bien sur, à toi de compléter) mais les liens seront facile à repérer entre les tables. Ça te donnera toujours j'espère un guide de réflexion de départ.

Demande d'avis sur la conception d'un petit projet GPAO!

par basvic » 10 oct. 2005, 16:11

Bonjour,
Travaillant d'une toute petite entreprise de fabrication, je me suis lancé (pauvre fou que je suis!) dans la conception d'un petit programme sous php/mysql permettant de mieux gêrer les retards de fabrication dans notre société. Le souci c'est qu'au départ c'était tout simple puisque je devais juste affiché les commandes sur chaque ordinateur de chaque atelier (donc réseaux local), mais maintenant je dois en plus essayer d'afficher dans un même tableau toutes les étapes de fabrication de chaque commande! En gros, par exemple j'ai 3 commandes à traiter dans un atelier A. La commande 1 requiert 3 étapes de fabrication, la commande 2 en requiert 12 et la commande 3 en requiert 7. De plus pour chaque étape il doit être possible à l'employé de cliqué dessus pour informer si il la finie ou pas. bref, j'espère que j'ai expliqué le problème assez clairement sinon, n'hésitez pas à me demander plus de précision.
Donc ma question est toute simple, quelle est la méthode la plus adéquate pour cette réalisation ?
Moi je suis parti avec une base de donnée contenant en autre les tables commandes (id, num, delais, status, priorite, clientID,com) ; etapes (etapeID, comID, atelier, travail, temps, statut, com, statut).
La table "commande" liste les différentes commandes à traiter et la table "etapes" liste toutes les étapes de production de toutes les comandes
Ensuite j'essaye d'afficher tous ces résultats dans un même tableau et c'est là que rien ne vas plus!!! En effet j'arrive à afficher tous les commandes avec la 1re étape à chaque fois mais pas avec chaque élément (statut, priorite...) de toutes les étapes de chaque commande... J'ai essayé de faire une boucle dans une boucle mais sans succès.
Ex :
Boucle 1 = affiche résultat de la requête "commande"
Boucle 2 (qui se trouve dans la boucle1) = affiche résultat de la requête "etapes" où comID=celle de la boucle 1
Voilà, voilà, je sais c'est un peu décousu tout ça mais je patoge un peu dans tous les sens. Forcément à force de tourner en rond ;-)
Pour mieux visualiser, voici un petit exemple de ce à quoi le tableau devrait ressembler : http://www.cvo95.com/exemple.htm