Modèles de cycle de vie d’un logiciel

Modèles de cycle de vie d’un logiciel

Modèle de cycle de vie en V
Le modèle de cycle de vie en V part du principe que les procédures de vérification de la conformité du logiciel aux spécifications doivent être élaborées dès les phases de conception.
La représentation en V tient d’avantage compte de la réalité, le processus de développement n’est pas réduit à un enchaînement de tâches séquentielles. Elle montre que:
 C’est en phase de spécification que l’on se préoccupe des procédures de qualification,  C’est en phase de conception globale que l’on se préoccupe des procédures d’intégration,  C’est en phase de conception détaillée que l’on prépare les tests unitaires.
Cependant, ce modèle souffre toujours du problème de la vérification trop tardive du bon fonctionnement du système.
2. Modèle de cycle de vie en cascade
Dans ce modèle le principe est très simple: chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase suivante que s’ils sont jugés satisfaisants.
3. Modèle de cycle de vie en Spirale
Il met l’accent sur l’activité d’analyse des risques : chaque cycle de la spirale se déroule en quatre phases :
 Détermination, à partir des résultats des cycles précédents, ou de l’analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre et des contraintes;  Analyse des risques, évaluation des alternatives et, éventuellement maquettage;  Développement et vérification de la solution retenue, un modèle « classique » (cascade ou en V) peut être utilisé ici;
 Revue des résultats et vérification du cycle suivant.

Modèle par incrément

Dans les modèles par incrément un seul ensemble de composants est développé à la fois: des incréments viennent s’intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l’un des modèles précédents.
Les avantages de ce type de modèle sont les suivants :
 chaque développement est moins complexe ;  les intégrations sont progressives ;  il est ainsi possible de livrer et de mettre en service chaque incrément ;  il permet un meilleur lissage du temps et de l’effort de développement grâce à la possibilité de recouvrement des différentes phases.  Les risques de ce type de modèle sont les suivants :  remettre en cause les incréments précédents ou pire le noyau ;  ne pas pouvoir intégrer de nouveaux incréments.  Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés globalement, au début du projet.  Les incréments doivent être aussi indépendants que possible, fonctionnellement, mais aussi sur le plan du calendrier du développement.

Choix
On a choisi le modèle de cycle de vie en V qui permet d’anticiper sur les phases ultérieures de développement du produit. En particulier le modèle en V permet de commencer plus tôt:
 Plan de tests de qualification,  Plan d’évaluation des performances.

Méthodologie de conception

Étude comparative entre MERISE et UML
MERISE (Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise) est une méthode d’analyse et de réalisation des systèmes d’information qui est élaborée en plusieurs étapes: schéma directeur, étude préalable, étude détaillée et la réalisation.
Alors que UML (Unified Modeling Langage), est un langage de modélisation des systèmes standard, qui utilise des diagrammes pour représenter chaque aspect d’un système: statique, dynamique,….en s’appuyant sur la notion d’orienté objet qui est un véritable atout pour ce langage.

La démarche adoptée
Dans notre projet on va utiliser UML qui est idéal pour :
 Concevoir et déployer une architecture logicielle développée dans un langage objet. Certes UML, dans sa volonté « unificatrice » a proposé des formalismes,  Pour modéliser les données (le modèle de classe réduit sans méthodes et stéréotypé en entités), mais avec des lacunes que ne présentait pas l’entité relation de Merise,  Pour modéliser le fonctionnement métier (le diagramme d’activité et de cas d’utilisation) qui sont des formalismes très anciens.
Pour le choix des diagrammes UML, on a utilisé quatre diagrammes: diagramme de cas d’utilisation, diagramme d’activités, diagramme de séquence et diagramme de classes.

Guide du mémoire de fin d’études avec la catégorie Analyse du cas d’utilisation (Gérer Compte)

Étudiant en université, dans une école supérieur ou d’ingénieur, et que vous cherchez des ressources pédagogiques entièrement gratuites, il est jamais trop tard pour commencer à apprendre et consulter une liste des projets proposées cette année, vous trouverez ici des centaines de rapports pfe spécialement conçu pour vous aider à rédiger votre rapport de stage, vous prouvez les télécharger librement en divers formats (DOC, RAR, PDF).. Tout ce que vous devez faire est de télécharger le pfe et ouvrir le fichier PDF ou DOC. Ce rapport complet, pour aider les autres étudiants dans leurs propres travaux, est classé dans la catégorie Modèle de cycle de vie en cascade où vous pouvez trouver aussi quelques autres mémoires de fin d’études similaires.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport gratuit propose le téléchargement des modèles gratuits de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1: CADRE GENERAL
Introduction
I. Présentation du cadre du projet
1. Présentation de l’institut Supérieur des affaires de Tunis
2. Présentation du sujet
II. Modèles de cycle de vie d’un logiciel
1. Modèle de cycle de vie en V
2. Modèle de cycle de vie en cascade
3. Modèle de cycle de vie en Spirale
4. Modèle par incrément
5. Choix
III. Méthodologie de conception
1. Étude comparative entre MERISE et UML
2. La démarche adoptée
CHAPITRE 2: ÉTUDE PREALABLE
I. Analyse de l’existant
II. Critiques de l’existant
III. Solution proposée
CHAPITRE 3 : IDENTIFICATION DES BESOINS
I. Les besoins fonctionnels
II. Les besoins non fonctionnels
III. Diagramme des cas d’utilisation
CHAPITRE 4 : ANALYSE DES CAS D’UTILISATION
I. Analyse du cas d’utilisation (s’identifier)
1. Description
2. Diagramme du cas d’utilisation s’identifier
II. Analyse du cas d’utilisation (Gérer Compte)
1. Description
2. Diagramme de cas d’utilisation gérer compte
III. Analyse du cas d’utilisation «Consulter les notes »
1. Description
2. Diagramme de cas d’utilisation consulter les notes
IV. Analyse du cas d’utilisation «Ajouter inscription »
1. Description
2. Diagramme de cas d’utilisation Ajouter inscription
IV. Analyse du cas d’utilisation «Consulter Transcript »
1. Description
2. Diagramme des cas d’utilisation consulter transcript
V. Analyse du cas d’utilisation «Mettre à jour informations »
1. Description
2. Diagramme de cas d’utilisation mise à jour informations
VI. Analyse du cas d’utilisation « Contacter un Enseignant »
1. Description
2. Diagramme de cas d’utilisation contacter enseignant
CHAPITRE 5: CONCEPTION
I. Diagramme d’activité
1. Diagramme d’activité de cas d’utilisation « S’identifier »
2. Diagramme d’activité de cas d’utilisation «Gérer compte»
3. Diagramme d’activité de cas d’utilisation «Mise à jour informations»
II. Diagramme de séquence
1. Diagramme de séquence de cas d’utilisation « S’identifier »
III. Diagramme de classes
CHAPITRE 6: REALISATION PRATIQUE
I. Environnement matériel
1. Architecture matérielle
2. Matériel utilisé
II. Environnement logiciel
1. WordPress
a. Justification du choix
b. Classement du CMS WordPress
c. Extensions utilisées
III. Base de Données
IV. Les composantes applicatives réalisées
CONCLUSION ET PERSPECTIVES
Webographie