Cahier des charges
télécharger 24.36 Kb.
|
| Développement d’une application java de bureau pour la gestion des rapports de visite GSB CAHIER DES CHARGES
Les rapports de visite sont actuellement gérés à l’aide d’une application Access que les visiteurs utilisent dans les locaux de l’entreprise sur différents postes dédiés à cet effet. Un projet d’application Web est en cours pour rendre accessible cette gestion à partir de n’importe quel ordinateur. Cependant, l’accès à cette gestion doit être maintenu à l’aide d’une application de bureau, mais l’application Access doit évoluer. Il a été décidé de développer une application de bureau en java (swing) et de porter la base de données sur SGBD Oracle. L’application doit remplir les mêmes fonctionnalités que l’application existante. In fine, le déploiement de la BDD sera effectué sur un SGBD Oracle tournant sur une machine virtuelle VMWare de la ferme de serveurs. Le déploiement de l’application pourra se faire par WebStart.
L’application doit être accessible facilement (raccourci sur le bureau) à partir de l’ensemble des ordinateurs de l’entreprise.
L'environnement doit être accessible aux seuls acteurs de l'entreprise. Une authentification préalable sera nécessaire pour l'accès au contenu.
L’application respectera le modèle MVC et donc son organisation.
L’application doit s’inspirer fortement de l’application Access existante et est donc constituée d’un certain nombre d’écrans auxquels on accède à travers un écran de menu principal. Il n’y a pas de barre de menu. On essaiera de soigner l’ergonomie comme par exemple :
Des améliorations ou variations peuvent être proposées par rapport à l’application Access existante.
Les noms de fichiers, de classes, d’objets, de méthodes doivent respecter les normes de codage habituelles. Vous utiliserez des composants graphiques Swing. Vous utiliserez l’environnement de développement NetBeans. Vous commenterez votre code avec les tag javadoc.
Vous utiliserez Netbeans sous Linux associé à un SGBD Oracle Express. Vous utiliserez un serveur de versioning (Google doc, github, …). Un outil de transfert de BBD Access vers Oracle vous est fourni. Vous aurez peut-être à retravailler le script généré.
L'application présente deux modules :
  
La documentation de l’application devra présenter l'arborescence des fichiers, la javadoc produite sur les classes créées, ainsi que la liste des bibliothèques supplémentaires utilisées.
Le commanditaire fournira à la demande toute information sur le contexte nécessaire à la production de l'application. Le commanditaire fournira une documentation et des sources exploitables pour la phase de test : base de données exemple, modélisation,... Le prestataire est à l'initiative de toute proposition technique complémentaire. Le prestataire fournira un système opérationnel, une documentation technique permettant un transfert de compétence et un mode opératoire propre à chaque module.
Travail en équipe Le développement s’effectuera par équipe de 2. Les tests unitaires Les tests unitaires des classes métier et modèle seront réalisés à l’aide du FrameWork JUnit et se feront de manière croisée (ce n’est pas celui qui a développé la classe qui la teste). Les tests fonctionnels Les tests fonctionnels seront réalisés en utilisant les scénarii définis au préalable. Tous les test donneront lieu à un rapport de tests.
Un dossier de spécifications fonctionnelles et techniques (cf. par exemple http://www.ird.fr/informatique-scientifique/documents/iliade/DSL_V1R1.pdf) Il devra au moins contenir les
Un dossier technique de réalisation
Un dossier de recette
Un dossier de déploiement
La veille technologique
Des heures supplémentaires pourront être éventuellement allouées si nécessaire. En particulier le déploiement pourra être réalisé par la suite.
|
similaire:
 | «Bâtiments» à l’instar du cct qualiroutes existant pour les ouvrages de voirie. Ce cahier des charges «bâtiments» sera baptisé ultérieurement... |  | |
| | ||
| | ||
| | ||
| |