Cahier des charges








télécharger 24.36 Kb.
titreCahier des charges
date de publication05.07.2017
taille24.36 Kb.
typeDocumentos
ar.21-bal.com > comptabilité > Documentos
Développement d’une application java de bureau

pour la gestion des rapports de visite GSB

CAHIER DES CHARGES

    1. Définition du besoin

      1. Définition de l'objet


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.

      1. Forme de l'objet


L’application doit être accessible facilement (raccourci sur le bureau) à partir de l’ensemble des ordinateurs de l’entreprise.

      1. Accessibilité/Sécurité


L'environnement doit être accessible aux seuls acteurs de l'entreprise.

Une authentification préalable sera nécessaire pour l'accès au contenu.
    1. Contraintes

      1. Architecture


L’application respectera le modèle MVC et donc son organisation.

      1. Ergonomie


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 :

  • Contrôle des saisies

  • Ne pas être obligé de cliquer sur un bouton après avoir fait un choix sur une liste déroulante,

  • Valider ou invalider des composants (boutons de commande en particulier) suivant les circonstances.

  • Afficher précisément les erreurs et replacer le curseur dans le champ de saisie.

Des améliorations ou variations peuvent être proposées par rapport à l’application Access existante.

      1. Codage


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.

      1. Environnement de développement


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é.

      1. Modules


L'application présente deux modules :

  • l’affichage des visiteurs médicaux

  • suivi des rapports de visite par les visiteurs







      1. Documentation


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.

      1. Responsabilités


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.

      1. Méthode de développement


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.

      1. Documents à remettre


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

  • Diagramme de cas d’utilisation

  • Scénarii

  • Le planning prévisionnelle


Un dossier technique de réalisation


  • Organisation du code

  • MLD et MCD (retro-ingénierie Windesign)

  • Diagramme de classe

  • Le code source

  • La documentation


Un dossier de recette

  • Rapports de tests


Un dossier de déploiement

  • Informations sur le déploiement de l’application


La veille technologique

  • Pour chaque question, liste des sites ou forum utilisés et une note expliquant la solution au problème



      1. Heures disponibles


lundi 3 déc

2 h

14h-16h

16h-18h : anglais-EDM

lundi 10 déc

4 h




lundi 17 déc

4 h




lundi 7 janvier

3 h

14-15h : cours veille technologique

Total

13 h





Des heures supplémentaires pourront être éventuellement allouées si nécessaire. En particulier le déploiement pourra être réalisé par la suite.

      1. Compétences


P1 : Production de services



A1.1.1 Analyse du cahier des charges d’un service à produire


  • C1.1.1.1 Recenser et caractériser les contextes d’utilisation, les processus et les acteurs sur lesquels le service à produire aura un impact

  • C1.1.1.2 Identifier les fonctionnalités attendues du service à produire

A1.2.2 Rédaction des spécifications techniques de la solution retenue (adaptation d’une solution existante ou réalisation d’une nouvelle solution)

  • C1.2.2.1 Recenser les composants nécessaires à la réalisation de la solution retenue

  • C1.2.2.2 Décrire l’implantation des différents composants de la solution et les échanges entre eux

  • C1.2.2.3 Rédiger les spécifications fonctionnelles et techniques de la solution retenue dans le formalisme exigé par l’organisation

A1.2.4 Détermination des tests nécessaires à la validation d’un service

  • C1.2.4.1 Recenser les tests d’acceptation nécessaires à la validation du service et les résultats attendus

  • C1.2.4.2 Préparer les jeux d’essai et les procédures pour la réalisation des tests

A1.3.1 Test d’intégration et d’acceptation d’un service

  • C1.3.1.1 Mettre en place l’environnement de test du service

  • C1.3.1.2 Tester le service

  • C1.3.1.3 Rédiger le rapport de test

A1.3.4 Déploiement d’un service

  • C1.3.4.1 Mettre au point une procédure d’installation de la solution

  • C1.3.4.2 Automatiser l’installation de la solution

  • C1.3.4.3 Mettre en exploitation le service

A1.4.1 Participation à un projet

  • C1.4.1.1 Établir son planning personnel en fonction des exigences et du déroulement du projet

  • C1.4.1.2 Rendre compte de son activité

P4 - Conception et maintenance de solutions applicatives



A4.1.6 Gestion d’environnements de développement et de test

  • C4.1.6.1 Mettre en place et exploiter un environnement de développement

  • C4.1.6.2 Mettre en place et exploiter un environnement de test

A4.1.8 Réalisation des tests nécessaires à la validation d’éléments adaptés ou développés

  • C4.1.8.1 Élaborer et réaliser des tests unitaires

  • C4.1.8.2 Mettre en évidence et corriger les écarts

A4.1.9 Rédaction d’une documentation technique

  • C4.1.9.1 Produire ou mettre à jour la documentation technique d’une solution applicative et de ses composants logiciels

similaire:

Cahier des charges icon0 T0 Entreprise / Chantier
«Bâtiments» à l’instar du cct qualiroutes existant pour les ouvrages de voirie. Ce cahier des charges «bâtiments» sera baptisé ultérieurement...

Cahier des charges iconCahier des charges

Cahier des charges iconCahier des Charges

Cahier des charges iconCahier des charges

Cahier des charges iconCahier des charges

Cahier des charges iconCahier des charges

Cahier des charges iconCahier des Charges

Cahier des charges iconExtrait du cahier des charges

Cahier des charges iconCahier des charges type

Cahier des charges iconCahier des charges type ascenseur








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com