Vous êtes sur la page 1sur 21

Université Hassan I

Faculté des Sciences et Techniques – Settat MST :


Réseaux & Systèmes Informatiques

Rapport :

Application OBAAS

Réalisé par : Encadré par :


-
Karbaoui Kawtar - Saadi Youssef
-
Sadiki Houssam
-
Baihat Maryem
-
Aissata Diallo
-
Fannouch Anouar
-
Hari Fatimzahra
-
Yasbar Mariam

1
Table des matières

I. Introduction...................................................................................................................................... 3

II. Les étapes à suivre :........................................................................................................................ 4

III. La Division des rôles :................................................................................................................... 4

IV. Les technologies utilisées:.............................................................................................................5

V. Analyse de spécification :...............................................................................................................6

VI. Conception :.................................................................................................................................. 9

VII. Analyse d’intégration................................................................................................................. 12

VIII. Besoin fonctionnel.................................................................................................................... 13

IX. Les Test :..................................................................................................................................... 16

X. Conclusion :.................................................................................................................................. 21

2
I. Introduction
Dans ce projet on va implémenter la méthode en cascade.

a) Qu’est-ce que la méthodeen cascade ?


La méthode en Cascade est un modèle où les phases de développement suivent rigoureusement un
ordre spécifique. La phase suivante ne peut commencer que lorsque la phase précédente a été conclue.
D'une manière générale, l'approche en Cascade commence par une planification et un design étendu,
suivis d'un codage et d'un test, et se termine par la publication. L'idée principale derrière la méthode
en Cascade est que le processus de planification approfondi nie la nécessité d'apporter des ajustements
importants lors du développement. À cette fin, la technique en Cascade tente de se préparer à tous les
scénario afin d'éviter des retards qui coûtent du temps et des ressources.
b) Architecture et structure:

3
c) Les principes de méthode en cascade :
 La production des livrables définis au tout débutdu projet
 La livraison de ces livrables à une date précise et définie lors du cadrage duprojet
 La phase ne se termine que lorsque cette dernière a été vérifiée puis validée. Si un client n’est pas
satisfait d’un livrable, l’équipe devra le retravailler jusqu’à ce qu’il soit parfait.

d) Quels sont les avantages de cette méthodologie ?


La méthode en cascade présente des avantages certains. Les entreprises souhaitant tenir leurs délais ont
ainsi tout intérêt à choisir la méthodologie en cascade. Chaque phase se verrouille à la suite des autres,
ce qui permet d’obtenir une bonne visibilité de la suite du projet. Et si la moindre phase prend du retard,
les prochaines étapes en prennent également. Dans une telle situation, les membres de l’équipe projet
ont tout intérêt à respecter au maximum les délais de conception, de production et de livraison. Le
respect du planning établi permet également de mieux maîtriser les coûts et de ne pas étirer le budget du
client.
Les entreprises apprécient la méthode de gestion de projet en cascade pour sa grande simplicité. Les
membres de l’équipe projet savent tous ce qui est attendu de leur part et ne peuvent pas se perdre entre
les différentes tâches à accomplir.

II. Les étapes à suivre :


1. Analyse et Spécification des besoins + Préparation de l’environnement (Fait)
2. Conception
3. Développement
4. Test

III. La Division des rôles :


Chef de projet Karbaoui Kawtar
Analyse intégrateur Baihat Maryem ,Aissata Diallo
Conception Fannouch Anouar

Développement (Front-End) Hari Fatimzahra , Yasbar Mariam


Développement (Back-End) Karbaoui Kawtar,Houssam Sadiki
Test Karbaoui Kawtar, Fannouch Anouar
4
IV. Les technologies utilisées:
1. Technologies de développement :
Pour développer notre application on va utiliser concernant la partie back-end :
 Le langage JAVA avec l’architecture JAVAEE.
 À propos du partie front end : on va utiliser le Framework Javascript, Bootstrap pour le style.
 La connexion entre le back end et front end on va utiliser les web services Rest API.

2. GitHub :
GitHub est une plateforme open source de gestion de versions et de collaboration destinée aux
développeurs de logiciels. Elle repose sur Git, un système de gestion de code open source créé par
Linus Thorvald dans le but d'accélérer le développement logiciel.

3. Jenkins :
Jenkins est un outil logiciel open source d’intégration continue développer en Java. Après une
présentation du concept d’intégration continue, découvrez à quoi sert Jenkins, quels sont ses avantages
et ses différences avec les autres outils similaires, ainsi que son fonctionnement.

5
4. Maven :
Apache Maven est un outil de gestion et d'automatisation de production des projets logiciels Java en
général et Java EE en particulier. Il est utilisé pour automatiser l'intégration continue lors d'un
développement de logiciel. Maven est géré par l'organisation Apache Software Foundation.

V. Analyse de spécification :
Concernant OBAAS 1.1 on les fonctionnalités suivantes :
 Accès à la page d’accueil d’OBAAS
 Créer un compte
 Vérification du solde ducompte
 Payer des facteurs
 Demande un service
 Fermeture des comptes Voici les détails de chaque spécification
:
Spécification 1 :
- Nom : Accès à la page d’accueil d’OBAAS
- Rôle : test
- Description : taper dans un navigateur web l’url d’OBAAS Spécification 2 :
- Nom : la création un compte
- Rôle : test
- Description : le client crée son compte dansle système
- Critère d’acceptante : si le client n’a pas de compte en ligne, il contacte directement la
banque par email pour récupérer son login et mot de passe - Scénario de test :
 Etape1 :
- Saisir le nom d’utilisateur

6
- Saisir mot de passe
- Confirmer mot de passe.(Nom d’utilisateur et mot de passe récupérés
auprès de la banque)
 Etape2 :
- Saisir le numéro téléphone et adresse.
- Spécifier la catégorie
- Si les informations sont correctes : l’utilisateur est redirigé vers une page de
confirmation (alerte de confirmation et attribution d’un numéro de compte),
L’utilisateur valide la création du compte est sera rediriger vers la page d’accueil.
- Déposer un solde de 500 USD
- Sinon : une boite de dialogue affiche un message (pas de correspondance entre
les mots de passe ou l’obligation de saisir tous les champs).
Spécification 3 :
- Nom : vérifier le solde
- Rôle : test
- Description : le client pour vérifier son solde une page d’authentification doit
Apparaître pour saisir le numéro de compte, nom utilisateur et mot de passe
- Critère d’acceptante : si l’utilisateur a déjà un compte
- Scénario de test :
• si les informations sont correctes alors une page affiche le solde ,
Sinon une boite de dialogue indique une erreur concernant les
informations
Spécification 4 :
- Nom : fermetures des comptes
- Rôle : test
- Description : le client pour fermer son compte une page avec un formulaire doit
apparaître pour saisir le numéro de compte, nom utilisateur et mot de passe
- Critère d’acceptante : si l’utilisateur a déjà un compte
- Scénario de test :
• si les informations sont correctes alors une page affiche que le
compte est bien fermé. Sinon une boite de dialogue indique une
erreur concernant les informations.
Spécification 5 :
- Nom : Demander un chéquier
7
- Rôle :test /dev
- Description : Le client demande un chéquier à la banque enligne.
- Critère d’acceptation : le client a déjà un compte en ligne et il est connecté via ce
compte.
- Scénario de test :
 Etape1 :
- Cliquer sur le menu de demande de service
 Etape 2 :
- Remplir le formulaire avec le numéro de compte, le nom
d'utilisateur et le mot de passe et sélectionner dans liste déroulante
« Demander un chéquier »

 Etape 3 :
- Si les informations incorrectes dans les cases à cocher et le
bouton Soumettre est cliqué, Une boîte de dialogue devrait
apparaître avec le message « Le nom d'utilisateur / mot de passe
que vous avez entré est incorrect. Veuillez saisir les entrées
correctes »
- Si une zone de texte est laissée vide et l'utilisateur clique sur le
bouton Soumettre, une boîte de dialogue doit informer
l'utilisateur de remplir cette zone de texte vide.
- Si les informations correctes unmessage confirmant le problème
du chéquier doit s'afficher.
Spécification 6 :
- Nom : Payer une facture
- Rôle : test/dev
- Description : Le client paye une facture en ligne.
- Critère d’acceptation : le client a déjà un compte en ligne et il est connecté via cecompte.
- Scénario de test :
 Etape1 :
- Cliquer sur le menu paiement de facture
 Etape 2 :
- Remplir le formulaire affiché avec des zones de texte pour le
numéro de compte, le nom d'utilisateur, le mot de passe, le
montant et sélectionner le Facturier.
- Si les informations incorrectes dans les cases à cocher et le
8
bouton Soumettre est cliqué, une boîte de dialogue devrait
apparaître avec le message « Le nom d'utilisateur / mot de passe
que vous avez entré est incorrect. Veuillez saisir les entrées
correctes »
- Si une zone de texte est laissée vide et l'utilisateur clique sur le
bouton Soumettre, une boîte de dialogue doit informer
l'utilisateur de remplir cette zone de texte vide.
- Si le compte de l'utilisateur a un solde insuffisant pour payer la
facture , le message « Pas de fonds suffisants dans le compte.
Cette transaction ne peut pas être effectuée » doit être affiché à
l'utilisateur. La page de paiement de facture sera à nouveau
affichée et l'utilisateur peut payer une autre facture d'un montant
égal ou inférieur au solde de compte.
- Si l’utilisateur clique sur le bouton Effacer sur la page de
facturation tous les champs de texte seront réinitialisées.
- Si les informations sont correctes et le montant de facture égal
ou inférieur au solde de compte, un écran confirmant le
paiement de la facture doit être affiché à l'utilisateur.
VI. Conception :
1. Diagramme des cas d’utilisation :

9
Le diagramme des cas d’utilisation décrit les fonctionnalités qu’un client peut effectuer sur le système.
Alors le client peut Créer un nouveau compte, Consulter son solde, Effectuer des payements en ligne,
Demander un service et Fermer le compte.

2. Diagramme de séquence :
Le diagramme de séquence décrit l’interaction et le fonctionnement du système suite à chaque requête envoyée
par le Client.
3. Diagramme d’activité :
 Cas de création de compte :

Le processus est très simple, le client accède à la page Créer Compte dans plateforme OBAAS, il
remplit le formulaire et c’est fini le compte est bien créé.
 Cas de la consultation de solde :

Le client se dirige vers la page Consulter Compte, il remplit le formulaire contenant le numéro de
compte, le Username et le mot de passe.
Si les données sont valides, le solde du client sera affiché.
Sinon une alerte sera affichée comme quoi les données ne sont pas valides.

10
 Cas de payement

Le client se connecte à la page Effectuer Payement, il remplit le formulaire contenant le numéro de


compte, le Username, le mot de passe, le service à payer et le montant.
Si les données sont valides, le payement sera effectué et un message de confirmation sera affiché.
Sinon une alerte sera affichée comme quoi le payement n’a pas passé.
 Cas de demande de service

Le client accède à la page Demander Service, il remplit le formulaire contenant le numéro de compte,
le Username, le mot de passe et le service à demander (chèque, relevé…).
Si les données sont valides, la demande sera enregistrée avec succès et un message de confirmation
sera affiché.

11
Sinon une alerte sera affichée comme quoi les données saisies ne sont pas validées.
 Cas de fermeture de Compte :
Le client accède à la page Fermer Compte, il remplit le formulaire contenant le numéro de compte, le
Username et le mot de passe.
Si les données sont valides, le compte sera fermé et un message de confirmation sera affiché.
Sinon une alerte sera affichée comme quoi les données saisies ne sont pas validées.

4. Diagramme de classe :

VII. Analyse d’intégration


Dans ce projet nous allons utiliser la méthode de programmation MVC2, qui consister à diviser le travail
en 3 parties :
 Modéle : qui représente les données et les règles métiers. C’est dans ce composant que s’effectuent les

12
traitements liés au cœur du métier. Les données peuvent être liées à une base de données. En d’autres
termes, le modèle ne réalise aucune mise en forme. Ces données pourront être affichées par plusieurs
vues. Du coup le code du modèle est factorisé : il est écrit une seule et unique fois puis réutilisé par
chaque vue.
Dans notre cas nous aurrons la classe NEWAccount dans le la partie modéle.
 View : Elle présente les données et interagit avec l’utilisateur. Dans le cadre des applications Web, il
s’agit d’une interface HTML, mais n’importe quel composant graphique peut jouer ce rôle.
 Controller (Metier) : quant à lui, se charge d’intercepter les requêtes de l’utilisateur, d’appeler le
modèle puis de rediriger vers la vue adéquate. Il ne doit faire aucun traitement. Il ne fait que de
l’interception et de la redirection.
Les méthodes dans la classe NewAccount :
- /createaccount -> L’interface qui permet la création de compte en ligne qui fait appelle à la
méthode -> AddNewAccount(), cette méthode prend en paramètre un attribut de type
NewAccount, et ajoute un nouveau compte à la table ‘NEWACCOUNT’ de la BD ‘OBAAS’ .
- /deleteAccount -> L’interface qui permet de supprimer un compte en ligne et qui fait appelle à la
methode -> DeleteAccount() qui prend en paramètre un attribut de type NewAccount et qui vas
supprimer le compte indexer dans la table ‘NEWACCOUNT’ de la BD ‘OBAAS’ .
- /BillPay-> L’interface qui permet d’effectuer le paiment d’une facture et qui fait appelle à la
methode -> BillPay() qui prend en parametre les attribut ‘username’, ‘password’, ‘accountno’,
‘biller’, ‘amount’ et qui verifie l’existant de compte par l’appel de methode AccounExist() et
apres verifier le solde de client avant de effectuer le paiement .
- /AccountBalance -> L’interface qui permet de consulter le solde et qui fait appelle à la methode -
> AccountBalance() de la classe NewAccount qui va interroge la table NEWACCOUNT de la
base de données pour obtenir la valeur de solde ‘amount’ et affiche le solde .
- La méthode dans la classe ChequeBook:
- /ChequeBook-> L’interface qui permet de demander un chèque et qui fait appelle à la méthode ->
AddService() de la classe ChequeBook qui prend en paramètre un attribut de type
NEWACCOUNT et qui interroge la table NEWACCOUNT de la base de données pour vérifier
l’existence de client et après ajouter le chèque dans la table CHEQUEBOOK de la base de
données ‘OBAAS ’.

VIII. Besoin fonctionnel


1. Création compte
13
Tache : Créer Compte / Dev - Test
Intervenant Dev: Sadiki – Harri – Yasbar / Test: Fannouch - Karbaoui
Durée 25 min
Description Création d’interface id = 1
Création d’une page contenant un formulaire de création compte
Détail La page contient un formulaire contenant :
- Champ Username : fait référence au username de type text
- Champ Password : fait référence au password de type password
- Champ Retype password : de type password
- Champ Phone number : fait référence au numéro tél de type text
- Champ Adresse : fait référence à l’adresse de client de type text
- Champ Category : fait référence au category de type hidden
- Button Submit : Pour valider les données et passer l’action
- Button Clear : Pour effacer les données dans les champs

Scénario de Test Il faut :


- Vérifier si le compte est bien enregistré
- Test d’interface (les champs obligatoires à remplir)
- Test unitaire (test la méthode createAccount())

2. Payer facture

Tache /type Payer facture /dev et test


Intervenant Dév :Sadiki/Harri/Yasbar/test:Fannouch-Karbaoui
Date /durée 22 /01/2021 20 min
Description Création d’interface dont l’Id = 4
il s’agit d’une page de payer de facture
Détail La page contiendra quatre zones de texte et une liste service ainsi deux
buttons (clear/submit) placée au milieu qui fera référence a (nom
d’utilisateur /mot de passe /numéro de compte /émetteur de facture
/montant)
Scénario de test Requête http /validation réalisé à l’aide d’un script JS dont l’Id =2
Coté frontend : Validé les données saisies (champs non rempli) via un script
JS.
Coté backend on vérifie les données saisis avec les données dans la base de
données pour effectuer ou pas le payement
3. Demande de service
Tache Demande Service / dev et test
Intervenant Dev :Sadiki/Harri/Yasbar/test :Fannouch-karbaoui
Date /durée 22 /01/2021 15 min
Description Création d’interface dont l’Id =3
il s’agit d’une page de demande d’un service (chéquier).

14
Détail La page contiendra :
-un champ username :fait référence au username de type cacher( hidden ).
-un champ password :fait référence au password de type password.
-un champ Account number :fait référence au Account number de type
number.
-button clear : pour effacer les champs
- button Submit :pour valider les données et passer l’ action
Scénario de test -Si les informations sont bien saisies, la demande sera envoyée avec succès
et sera envoyée vers la page chéquier
-validation : test d’interface(les champs obligatoire à remplir)

4. Fermeture de compte
Tache /type Fermeture Compte / Dev - Test
Intervenant Dev : Sadiki – Harri – Yasbar / Test : Fannouch - Karbaoui
Durée 20 min
Description Création d’interface id = 5
Création d’une page contenant un formulaire de fermeture de compte
Détail La page contient un formulaire contenant :
- Champ Username : fait référence au username de type text
- Champ password : fait référence au password de type password
- Champ numero compte : fait référence au numero de compte de
type number
- Button Submit : Pour valider les données et passer l’action
- Button Clear : Pour effacer les champs
Scénario de Test Il faut :
- Vérifier si le compte est bien supprimé de la table
- Test d’interface (les champs obligatoires à remplir)
- Test unitaire (test la méthode deleteAccount())
5. Consulter Solde

Tache : Consulter Solde / Dev - Test


Intervenant Dev: Sadiki – Harri – Yasbar / Test: Fannouch - Karbaoui
Durée 25 min
Description Création d’interface id = 2
Création d’une page contenant un formulaire de consultation solde

15
Détail La page contient un formulaire contenant :
- Champ numero compte : fait référence au numero de compte de type
number
- Champ Username : fait référence au username de type text
- Champ password : fait référence au password de type password
- Button Submit : Pour valider les données et passer l’action
- Button Clear : Pour effacer les données dans les champs

Scénario de Test Il faut :


- Vérifier si le solde est bien affiché dans le cas de validation des
données
- Test d’interface (les champs obligatoires à remplir)
- Test unitaire (test la méthode accountBalance())
IX. Les Test :
Ils existent différents types de tests parmi ces types on peut citer :

Tests d’utilisabilité : Le test d’utilisabilité (ou test utilisateur), est la méthode la plus efficace pour
évaluer un logiciel. Le test consiste à observer directement l’utilisateur en train de se servir de
l’application ou du logiciel. Il permet d’identifier concrètement les problèmes. L’utilisabilité peut être
mesurée en calculant la performance de l’utilisateur.

Le test d’utilisabilité est l’occasion de voir l’utilisateur en situation et d’observer les problèmes qu’il
rencontre, les questions qu’il se pose et les fonctionnalités qu’il apprécie ou non. Les
équipes de développement recueillent ainsi des éléments précieux sur la façon de rendre le logiciel
plus agréable à utiliser.
Tests unitaires : Les tests unitaires consistent à tester individuellement les composants de
l’application. On pourra ainsi valider la qualité du code et les performances d'un module
Tests d’intégrations : Ces tests sont exécutés pour valider l'intégration des différents modules entre
eux et dans leur environnement exploitation définitif.

Ils permettront de mettre en évidence des problèmes d'interfaces entre différents programmes. Dans
notre cas nous avons utilisé outil jenny pour faire le test d’utilisabilité.

Définitions jenny : jenny est un outil pour générer des tests de régression. Chaque fois que des tests
exhaustifs semblent pénibles en raison de l'explosion combinatoire des interactions de fonctionnalités à
tester, pensez à utiliser jenny. Il couvrira la plupart des interactions avec beaucoup moins de cas de test.
Il peut garantir des tests par paires de toutes les fonctionnalités qui peuvent être utilisées ensemble, et il
peut éviter les combinaisons de fonctionnalités qui ne le peuvent pas.

16
 Test de création de compte :

A = valeur valide B = valeur invalide/null


Scénario des tests :

Username password Retype Phone Address Oracle


password number
A B B B B alert
B A A A A alert
A A A A A Compte
crée
A A A B A alert
B B B A A alert
B A A A B alert
A A B A A alert
 Test de consulter solde :

Account number Username password oracle


A A A Affichage de solde
A B B alert
B B B alert
B A A alert
A A B alert
 Test de paiement :

17
4a: LYDEC - 4b: ONE - 4c: IAM
Scenario test:

Username password Account number Biller amount Oracle


A B B 4c B alert
A A A 4a A Paiement
passe
B A B 4b A alert
A A B 4b A alert
B B B 4c A alert
B A A 4a B alert
A A B 4a A Alert

 Test de Fermeture :

Username Account number password Oracle


A A A Fermeture Compte
A B B alert
B B B alert
B A A alert
A A B Alert
Test demander Service :

18
Password Account number Service Oracle
A A A Enregistrement
demande
A B B alert
B B B alert
B A A alert
A A B Alert

Pour automatiser c’est test, on a utilisé Selenium. Voici le programme Selenium qui permet de tester la
création d’un compte bancaire.

19
On lance le test avec la commande node test_create_compte.js
Si le test passe bien le message success sera affiché sur la console

Après, le navigateur lance la page localhost :8080/obaas/ automatiquement avec le remplissage des
champs automatique aussi.

20
X. Conclusion :
La réalisation de ce projet nous a permet d’être capable de travailler en groupe d’un cote.et d’un autre
côté de connaitre comment utiliser la méthode en cascade pour livrer un produit finale comme dans
notre cas application qui permet de gérer les comptes bancaires on utilisant JEE.

21

Vous aimerez peut-être aussi