Objet = ensemble cohérent de propriétés
C’est souvent mieux de faire l’analyse et la spécification des besoins en un seul et
unique document plutôt que de manière séparée.
L’expression «analyse et conception » des besoins n’existe pas.
L’analyse fonctionnelle est non negligeable et doit etre precise.
Analyse des besoins → Qu’est ce que doit faire le futur systeme ?
→ On demande l’avis de l’expert metier
Analyse des besoins: []
Vacation (module fondamental) → Paiement au volume du travail
On appelle alumni tou tetudiant possedant un diplôme de l’etablissement et qui
part de l’ecole.
Apres l’analyse, tout doit etre clair ; On ne doit plus se poser des questions sur ce
qui doit etre fait, ce qu’on doit entrer comme information par exemple.
Bugdet:
- Recettes (Subventions, ecolage)
- Depenses
Creer un tableau ou chaque colonne est un module, et pour chaque module
identifier les acteurs, et bien sur preciser ce qu’ils vont faire.
Conception → Comment doit-etre fait la solution/le systeme ?
Conception architecturale → Permet d’avoir l’architecture generale de la solution.
Definir les differentes differents blocs de la solution et les relations qui existeront
entre eux.
Conception détaillée →
Difference outil – technologie : Un outil est concret (il aide a l’execution d’une
tache) ; La technologie est souvent conceptuelle (on retrouve un certain nombre
de techniques)
En termes de tests, le choix des cas representatifs est important. C’est pour cela
que le testeur a un rôle important. Il pour rôle de fabriquer des jeux de test pour
les test unitaires.
Les tests unitaires permettent de verifier le comportement « stable » d’une
fonction.
Les tests d’integration sont aussi consideres comme des tests de « non-
regression ». On s’assure que la qualite du systeme ne change pas apres
l’integration d’un nouveau module.
Analyse et solution ne vont pas de paire.
Le type/modele de processus depend du type de logiciel qu’on doit construire. La
nature/disponibilite du client font egalement partie des elements qui peuvent
influer. La nature de l’equipe de developpement influe.
En gros la nature du processus du dev depend d’un ensemble de facteurs.
Modeles de processus en cascade (Waterfall), Cycle en V, Agilité (promotion du
pragmatise), notions d’[iterations, increments].
L’adoption d’un processus strict ne reflete pas souvent la realite. Il s’agit de voir le
modele qui nous convient, sinon on en construit une, et cela peut etre la
combinaison d’un ensemble de pratiques venant d’autres methodes.
Identifier les use-case, les prioriser, entrer dans une cycle d’analyse-conception-
codage. Puis presenter un rapport avvec une liste des acteurs, liste des besoins du
use case. Presenter ce qui a ete fait en terme d’analyse-conception-codage. On ne
vas pas s’amuser a faire de la documentation sur tous les 20 cas d’utilisations, mais
sur peut-etre sur quelques.
Utilisation de Symfony 6.
Groupe 1 → Module Tableau de bord
Groupe 2 → Module Gestion des notes
Groupe 3 → Module Planning
Groupe 4 → Module Stages
Groupe 5 → Module Soutenances
Groupe 6 → Module Absences
