Cette année, il y a 4 groupes de TP. Chaque groupe devra réaliser un projet différent. Comme dans une entreprise, vous devrez concevoir un produit (informatique), ensemble, en utilisant vos différentes capacités. Dans chaque groupe, il faudra se partager le travail (lors de la première séance), individuellement ou par binôme (mais les binômes seront évalués individuellement). Chaque groupe se réunit avec l'enseignant responsable (P. Trau cette année) pendant 5 séances de 4 heures, afin de valider ensemble les travaux effectués depuis la séance précédente, rendre compte des recherches effectuées, tenter de résoudre les différents problèmes rencontrés, redéfinir les tâches à effectuer pour la semaine suivante... Chaque séance débutera et se terminera par un petit « briefing » en présence de l'enseignant responsable.
En fin de projet, vous réaliserez un dossier, qui devra comporter une partie commune sur le projet, mais aussi une partie individuelle décrivant votre participation au projet, les difficultés rencontrées, votre avis sur le travail du groupe. L'évaluation prendra en compte :
le produit final, suivant ses fonctionnalités, sa documentation, puis (uniquement si les points précédents sont satisfaisants) son ergonomie.
votre participation individuelle au projet (ça peut être de l'informatique pure, mais aussi de la recherche d'informations, la création de la documentation technique, la gestion du projet, la gestion du groupe, la recherche d'informations,...). Etre dans un groupe ayant créé un produit extraordinaire mais sans votre participation vous apportera une note de 0, bien que vous soyez venu aux 5 séances.
votre analyse personnelle.
Restitution du travail |
Il faudra rendre (au plus tard le premier jour de la « semaine de révision »):
1) Le produit qui a été commandé à votre groupe, accompagné de son dossier technique. Le produit sera remis soit sur un support amovible (disquette / CD), soit sur un ordinateur accessible de l'IPST (en précisant la manière d'y accéder).
Le dossier technique décrit le produit, ses fonctionnalités, ses limites. Les différents composants du produit y sont décrits. Les différentes parties du dossier peuvent évidement être rédigées séparément, mais un document de synthèse sera bienvenu (au minimum une liste des sous-dossiers). En cas de partage du travail par petits groupes, chaque sous-dossier comportera le nom des étudiants l'ayant réalisé. L'un d'entre vous peut se proposer comme coordinateur.
Pour chaque partie, un nom (et éventuellement une adresse e-mail) désignera la personne "service après vente" à qui le client (par l'intermédiaire de Mr TRAU) pourra poser des questions techniques.
2) un rapport individuel qui précisera ce que vous avez fait, comment vous vous êtes organisés (tous ensemble et dans votre sous-groupe), ce que vous avez découvert et appris, comment et où vous avez cherché l'information, les difficultés que vous avez rencontrées et comment vous les avez résolues (ou pas). Si pour certains d'entre vous le travail consistait en une recherche d'informations pour le reste du groupe, vous expliquerez dans le rapport individuel votre démarche, et annexerez au dossier technique la synthèse de vos résultats.
Toujours dans votre rapport individuel, vous préciserez comment vous vous organiseriez si c'était à refaire (attention à ce que vous dites, on vérifiera peut-être dans vos projets d'IUP3). Vous pourrez également donner votre avis sur le module "application informatique", quelques conseils pour pour que les étudiants des prochaines années puissent mieux s'organiser, être plus efficaces, gérer leur temps et la progression du travail, se partager plus efficacement le travail (sur ce dernier point, comment ferez vous, une fois ingénieur maître, pour faire travailler les fainéants de votre service). Vous pourrez également dire quelles informations vous manquaient et comment vous avez essayé de les obtenir. Si le sujet ne vous a pas plu, vous pouvez en proposer d'autres, pour l'année prochaine.
Sujet 1 : gestion de données /
|
Aujourd'hui, le présentation de pages web statiques n'est plus suffisante pour une entreprise qui veut réellement utiliser internet pour toucher de nouveaux clients et fidéliser ses clients. En plus des pages de présentation, Il faut pouvoir présenter des données toujours à jour et surtout personnalisées. Il faut aussi pouvoir influer à distance et en temps réel sur les données présentées.
Pour cela, vous allez réaliser une architecture client-serveur :
Les informations de base sont sur un serveur relié à internet. Sur ce serveur vous allez faire tourner un programme (appelé aussi serveur) recevant des demandes (requêtes), effectuant des calculs en fonction des données dont il dispose (localement, sur le disque dur) et créant une page de réponse. Ce programme sera écrit en C. C'est évidement le gros de votre travail.
Le client est un navigateur web, les requêtes sont effectuées grâce à un formulaire HTML (form)
On prévoira également la possibilité de mise à jour des données du serveur via un client du même type, mais évidement en accès limité (par mot de passe par exemple).
J'ai écrit une page présentant simplement cette architecture client HTML et serveur en C : /internet/html/tst-form.htm.
Un très grand nombre d'applications peuvent utiliser ce schéma (établissement de devis personnalisé, disponibilité de produits et calcul de délais d'approvisionnement, liste des téléskis ouverts,...). Pour être très appliqué, vous allez traiter un sujet vous concernant : une gestion des salles de TP de l'IPST : gestion des salles, rotation des groupes... En accès public, vous donnerez des tableaux d'utilisation des salles, de rotation de TP, emplois du temps personnalisés (étudiants ou profs)... En accès protégé, vous permettrez l'introduction des données. Si possible, vous proposerez également des outils de vérification (prévenir en cas de chevauchement par exemple) et des outils d'aide à la décision (proposition automatique de plages libres par exemple).
Ce cahier des charges est volontairement peu précis : à vous de définir précisément le besoin. C'est aussi à vous de gérer l'intégralité du projet. Dès la première séance, vous devrez définir quelles données seront pertinentes et comment les organiser (tableaux, structures,...).L'application pourra être simplifiée par rapport à la réalité (par exemple seul l'IUP a plusieurs groupes, le Hall considéré comme une seule salle de TP mais pouvant accueillir plusieurs groupes simultanés...).
Sujet 2 : Salles de TP
|
Aujourd'hui, le présentation de pages web statiques n'est plus suffisante pour une entreprise qui veut réellement utiliser internet pour toucher de nouveaux clients et fidéliser ses clients. En plus des pages de présentation, Il faut pouvoir présenter des données toujours à jour et surtout personnalisées. Il faut aussi pouvoir influer à distance et en temps réel sur les données présentées.
Pour cela, vous allez réaliser une architecture client-serveur :
Les informations de base sont sur un serveur relié à internet. Sur ce serveur, vous utiliserez un gestionnaire de base de données utilisant le langage standard SQL (nommé MySQL) .
Le client est un navigateur web, les requêtes sont effectuées grâce à des pages HTML utilisant si nécessaire des formulaires (form), et le langage PHP au moins pour envoyer et traiter les requêtes.
On prévoira également la possibilité de mise à jour des données du serveur via un client du même type, mais évidement en accès limité (par mot de passe par exemple).
Un très grand nombre d'applications peuvent utiliser ce schéma (établissement de devis personnalisé, disponibilité de produits et calcul de délais d'approvisionnement, liste des téléskis ouverts,...). Pour être très appliqué, vous allez traiter un sujet vous concernant : une gestion des salles de TP de l'IPST : gestion des salles, rotation des groupes... En accès public, vous donnerez des tableaux d'utilisation des salles, de rotation de TP, emplois du temps personnalisés (étudiants ou profs)... En accès protégé, vous permettrez l'introduction des données. Si possible, vous proposerez également des outils de vérification (prévenir en cas de chevauchement par exemple) et des outils d'aide à la décision (proposition automatique de plages libres par exemple).
Ce cahier des charges est volontairement peu précis : à vous de définir précisément le besoin. C'est aussi à vous de gérer l'intégralité du projet. Dès la première séance, vous devrez définir quelles données seront pertinentes et comment les organiser (tableaux, structures,...).L'application pourra être simplifiée par rapport à la réalité (par exemple seul l'IUP a plusieurs groupes, le Hall considéré comme une seule salle de TP mais pouvant accueillir plusieurs groupes simultanés...). On trouve sur Internet de très bons manuels sur PHP, HTML et MySQL.
Sujet 3 : Base de données "stages"
|
Aujourd'hui, le présentation de pages web statiques n'est plus suffisante pour une entreprise qui veut réellement utiliser internet pour toucher de nouveaux clients et fidéliser ses clients. En plus des pages de présentation, Il faut pouvoir présenter des données toujours à jour et surtout personnalisées. Il faut aussi pouvoir influer à distance et en temps réel sur les données présentées.
Pour cela, vous allez réaliser une architecture client-serveur :
Les informations de base sont sur un serveur relié à internet. Sur ce serveur, vous utiliserez un gestionnaire de base de données utilisant le langage standard SQL (nommé MySQL) .
Le client est un navigateur web, les requêtes sont effectuées grâce à des pages HTML utilisant si nécessaire des formulaires (form), et le langage PHP (au moins pour envoyer et traiter les requêtes).
Vous prévoirez également la possibilité de mise à jour des données du serveur via un client du même type, mais évidement en accès limité (par mot de passe par exemple).
Un très grand nombre d'applications peuvent utiliser ce schéma (établissement de devis personnalisé, disponibilité de produits et calcul de délais d'approvisionnement, liste des téléskis ouverts,...). Pour être très appliqué, vous allez traiter un sujet vous concernant : Création d'une base de données sur les stages effectués par les étudiants de l'IPST. Cette base regroupera des détails sur les entreprises ayant acceuilli des stagiaires, ainsi que des détails sur chaque stage (sujet, domaine, durée,...). Elle fournira également des liens vers les sites internet de l'entreprise, mais aussi (dans les cas où c'est pertinent) des liens spécifiques à chaque stage. Elle sera destinée aux seuls étudiants de l'IPST. Votre but n'est pas de saisir toutes les données, mais de créer l'outil informatique : définition de la base de données (champs, liens,...), et des clients (pages de requêtes, introduction et modification des données,...). Le produit devra être assez facilement modifiable (entre autre grâce au dossier technique).
Ce cahier des charges est volontairement peu précis : à vous de définir précisément le besoin : il devra contenir toutes les informations que vous aimeriez trouver pour votre recherche de stage. C'est aussi à vous de gérer l'intégralité du projet. Dès la première séance, vous devrez définir quelles données seront pertinentes et comment les organiser (tables et relations entre elles). On trouve sur Internet de très bons manuels sur PHP, HTML et MySQL.
Sujet 4 : interface base de données
"réseau"
|
Aujourd'hui, le présentation de pages web statiques n'est plus suffisante pour une entreprise qui veut réellement utiliser internet pour toucher de nouveaux clients et fidéliser ses clients. En plus des pages de présentation, Il faut pouvoir présenter des données toujours à jour et surtout personnalisées. Il faut aussi pouvoir influer à distance et en temps réel sur les données présentées.
Pour cela, vous allez réaliser une interface web vers une base de données partagée :
Les informations de base sont sur un serveur relié à internet. Sur ce serveur, vous utiliserez un gestionnaire de base de données utilisant le langage standard SQL (nommé MySQL). Au départ du projet, la base existe, on peut y accéder en langage SQL, grâce à l'outil généraliste « phpmyadmin »
Le client est un navigateur web, les requêtes sont effectuées grâce à des pages HTML utilisant si nécessaire des formulaires (form), et le langage PHP (au moins pour envoyer et traiter les requêtes). Le client sera bien évidement totalement spécifique à l'application. Il permettra la consultation des données (avec divers critères de sélection, de tris...), mais aussi la modification des données, l'ajout et la suppression. Les accès seront sécurisés par mot de passe.
Un très grand nombre d'applications peuvent utiliser ce schéma (établissement de devis personnalisé, disponibilité de produits et calcul de délais d'approvisionnement, liste des téléskis ouverts,...). Pour être très appliqué, vous allez traiter une base de données réelle, mise en place par l'informaticien de l'IPST, Boris Lechner (bureau 205). Il vous a décrit la base actuelle : voir document joint. Votre produit devra être avant tout être efficace, utile, pratique, et assez facilement modifiable (entre autre grâce au dossier technique).
Ce cahier des charges est volontairement peu précis : à vous de définir plus précisément le besoin, et le proposer à votre « client ». L'enseignant responsable (P. Trau) pourra vous aider en répondant à vos question à vos questions purement techniques. Mais c'est à vous seuls qu'incombe la gestion du projet. On trouve sur Internet de très bons manuels sur PHP, HTML et MySQL.
Description de la base de données "Réseau" |
La base est située sur le serveur ipst-sv, accessible par phpmyadmin (http://ipst-sv/phpmyadmin). Vous avez un compte sur ce serveur (grp1).
Créer une interface permettant d'ajouter/supprimer/modifier des informations simplement.
Créer une interface permettant de signaler des problèmes (entièrement distincte de la première)
Voir les limitations de cette structure de données et proposer d'éventuelles améliorations. Exemple : Actuellement, un ordinateur ne peut avoir qu'un seul nom de domaine, une seule adresse ip et une seule adresse mac, alors que dans la pratique, ils peuvent en avoir plusieurs.
Table "batiment" - Liste des batiments |
||
* id_bat |
bigint(20) |
auto_increment |
Identifiant du batiment (clé primaire) |
||
* nom_bat |
varchar(255) |
|
Nom du batiment (IPST, Hall) |
Table "os" - Liste des systèmes d'exploitation |
||
* id_os |
UNSIGNED bigint(20) |
auto_increment |
Identifiant du système d'exploitation (clé primaire) |
||
* nom_os |
varchar(255) |
|
Nom du système d'exploitation |
||
* version_os |
varchar(50) |
|
Eventuel nom ou numéro de version du système d'exploitation |
Table "osParPoste" - Permet de savoir quel OS sont installés sur quels postes |
||
* id_pos |
UNSIGNED bigint(20) |
|
Identifiant du poste (tiré de la table 'postes') (clé primaire avec id_os) |
||
* id_os |
UNSIGNED bigint(20) |
|
Identifiant du système d'exploitation (tiré de la table 'os') (clé primaire avec id_pos) |
Table "postes" - Liste des ordinateurs |
||
* id_pos |
bigint(20) |
auto_increment |
Identifiant du poste (clé primaire |
||
* id_sal |
bigint(20) |
|
Identifiant de la salle ou se trouve le poste (tiré de la table 'salles') |
||
* dns_pos |
varchar(255) |
|
Nom de domaine de la machine |
||
* ip_pos |
varchar(15) |
|
Adresse IP de la machine |
||
* mac_pos |
varchar(17) |
|
Adresse MAC (ethernet, physique) de la machine |
||
* lastIntervention_pos |
date |
|
Date de dernière intervention sur l'ordinateur |
||
* lastUpdate_pos |
date |
|
Date de dernière mise à jour des systèmes d'exploitation |
||
* dhcp_pos |
UNSIGNED tinyint(3) |
|
0 ou NULL si le poste est configuré en adressage statique, 1 s'il est configuré en adressage dynamique (dhcp) |
Table "problemes" - Liste les problèmes des postes |
||
* id_pro |
UNSIGNED bigint(20) |
auto_increment |
Identifiant du problème (clé primaire) |
||
* id_pos |
UNSIGNED bigint(20 |
|
Identifiant du poste concerné par le problème (tiré de la table 'poste') |
||
* id_os |
UNSIGNED bigint(20) |
|
Identifiant du système d'exploitation concerné par le problème |
||
* intitule_pro |
varchar(255) |
|
Titre ou résumé du problème |
||
* desc_pro |
text |
|
Description détaillée du problème |
Patrick
TRAU, ULP - IPST
juillet 04