| | | | | | --- | --- | --- | --- | | **Institut Supérieur des Etudes Technologiques de Bizerte** **Département Technologies de l’informatique** | | | | | **Parcours :** | Développement des Système d’Informations | | | | **Unité d’Enseignement :** | Environnement de Développement | | | | **Matière** | | | | | **Méthodologie de Conception** | | | | | **Enseignant Responsable :** Khaoula Jridi | | **Année Universitaire :** 2015-2016 | **Semestre :** 5 |
**Chapitre 1 : Le Processus Unifié**
1. **Introduction**
Qu’est-ce qu’un système ?
* Un système est un ensemble d’éléments interagissant entre eux suivant un
certains nombres de principes et de règles dans le but de réaliser un objectif.
* La frontière d’un système est le critère d’appartenance au système. * L’environnement est la partie du monde extérieure au système. * Un système est souvent hiérarchisé à l’aide de sous-systèmes. * Un système complexe se caractérise par :
-sa dimension qui nécessite la collaboration de plusieurs personnes
- son évolutivité
Exemples : une fourmilière, l’économie mondiale, le système solaire, etc.
Qu’est-ce qu’un logiciel ?
* Un logiciel est un ensemble d’entités nécessaires au fonctionnement d’un
processus de traitement automatique de l’information.
Le Cycle de développement et cycle de vie du logiciel
* Analyse
**Cycle de vie**
**Cycle de développement**
* Conception * Réalisation * Tests * Exploitation * Maintenance
1. **Qu’est ce qu’une méthode de conception ?**
Une méthode de conception :
* Décrit une démarche (un ensemble de tâches, d’activités dans un ordre, en succession) * Une ligne de conduite * Un recueil d’enchainement recommandé, des directives à suivre * Possède un domaine d’étude (périmètre du système à modéliser, à informatiser) * Utilise des outils techniques, des langages et des modèles * Un ensemble de bonnes pratiques * C’est une recette pour accomplir avec succès un projet de développement logiciel
1. **Pourquoi a-t-on recours à une méthode ?**
**Est-il vraiment nécessaire d’adopter une méthode de conception lors du développement logiciel ?**
Une méthode de conception pour :
* Maitriser le coût, qualité et délais d’un projet de développement logiciel. * Diviser le projet en composants et par la suite planifier les équipes de développement en fonction de ces composants.
(Gérer le rapport effort/homme).
* Savoir les clés de développement logiciel : Qui fait Quoi Comment et à quelle moment 🡪synchronisation des équipes. * Optimiser le processus de prise de décision : la meilleure décision dans le bon moment (Gestion de projet)
1. **Présentation générale d’UP**
* La vie d’un logiciel est composée de cycles * Chaque cycle est une version
Voici le schéma d’un cycle avec ses 4 phases :
Etude Préliminaire
(INCEPTION)
Elaboration
Publicité
Construction
Transition
**Un Cycle**
* Chaque phase du cycle est composée d’itérations (incréments) * Chaque itération est une succession d’activités ; une mini-cascade qui comporte toutes les activités * Une itération conduit à une version montrable implémentant un certain nombre de CU
Capture des besoins
Analyse
Une itération
Conception
Réalisation
Test et intégration
* Chaque activité est réalisée avec une importance lors d’une itération * Efforts par itération dans une phase
1. **Etude des phases d’un cycle UP**
| | | | --- | --- | | **Phase1 : Etude Préliminaire** | * Phase très courte (souvent 1 itération) * Etude de faisabilité, de risques et périmètres de projet | | **Phase 2 : Elaboration** | * Quelques itérations courtes * Identification des besoins * Conception de l’architecture de base * Programmation et test des composants logiciels les plus importants * Estimation des délais et coûts | | **Phase3 : Construction** | * Phase la plus coûteuse (+50% du cycle) * Développement par incrément * Produit suffisamment correcte pour être installé | | **Phase4 : Transition** | * produit délivré en version béta * correction, amélioration, formation des utilisateurs, préparation des manuels |
1. **Description détaillée des activités d’une itération**
**Part des activités d’une itération / Phases**
****
**6.1. L’activité « Capture et analyse des besoins »**
*But :*
* Identifier (définir le périmètre) le système à construire * Définir les besoins fonctionnels et non fonctionnels
*Capture et analyse des besoins :*
* Formulation des souhaits du client en besoin * Passer d’un langage informel redondant (langage client) à un langage formel et non redondant (structuration par classes). * Elaboration d’un cahier de charge ; compromis entre le client et l’analyste
***Remarque***
\*\*Capture des besoins : Le modèle des CU représente le système vu de l’extérieur, son insertion dans l’organisation, ses frontières fonctionnelles.
\*\*Analyse : le modèle d’analyse représente le système vu de l’intérieur. Les objets sont des abstractions des concepts manipulées par les utilisateurs. Point de vue statique et dynamique sur les comportements.
*Artéfacts/livrables :*
* Modèles de domaine (business logic) du système à construire * Modèle de cas d’utilisation système+les divers descriptions (textuelle/diagramme de séquence) * Glossaire des mots clés * Cahier de charges
**6.2. L’activité « Conception »**
*But :*
* Appréhender la logique comportementale (interactions entre objets) * Identifier le design pattern adopté (décision de premier ordre) * Réfléchir sur la logique structurelle (architecture logique et physique)
*Conception de l’application:*
* Pendant cette phase, le système n’est plus une boite noire * Décortiquer le système en objets tout en précisant la relation entre eux et les responsabilités de chaque objet. * Qui crée les objets ? * Qui permet d’accéder à un objet ? * Quel objet reçoit un message provenant de l’IHM ? * Elaboration de modèles de conception (ajouter les visibilités, les méthodes, les interfaces, les contrôleurs, lier le modèle de séquence avec le modèle de classes, etc.) * Concevoir les modèles architecturaux (diagrammes de package en couche, diagramme de déploiement et de composants ou les deux couplés) voir les exemples ci-dessous.
Publicité
Exemple de diagramme de package pour une architecture en couche
Exemple de diagramme de déploiement
*Artéfacts/livrables :*
* Diagrammes de séquence * Diagrammes de classes participantes (de l’application) * Diagrammes de package * Diagramme d’interaction * Diagramme de déploiement/de composants
**6.3. L’activité « Réalisation »**
*But :*
* Implémenter les cas d’utilisations * Vérifier si le code et conforme aux besoins
*Capture et analyse des besoins :*
* Codage de classes avec génération automatique d’un squelette de code (Reverse Engineering) * Compléter le squelette généré * Elaboration des fiches de test des fonctionnalités développées * Retravailler le code selon le résultat du test
*Artéfacts/livrables :*
* Code source * Fiche de test
1. **Description détaillée de chaque phase**
**7.1. Phase 1 : Etude Préliminaire (Inception)**
****
**Objectif : lancer le projet**
* Délimiter le système * Déterminer que fait le système? * A quoi pourrait ressembler l’architecture? * Quels sont les risques? * Quel est le coût estimé du projet? Comment le planifier?
🡪Phase très courte (1 itération)
🡪A la fin de cette phase on décide de continuer ou non (la faisabilité)
**Activités principales de l’étude préliminaire**
***Capture et analyse des besoins***
* Comprendre le contexte du système (50-70% du contexte) * Identifier les cas d’utilisation (80%) * Identifier les besoins non fonctionnels (80%) * Détailler et analyser les cas les plus importants (10%)
***Analyse et Conception Orientées Objet***
* Entamer la conception architecturale * Architectures logique et de déploiement
**7.2. Phase 2 : Elaboration**
****
**Objectif : Cerner le projet**
* Identifier et stabiliser les besoins * Planifier les phases du projet et estimer les coûts * Choisir l’architecture adéquate
**Phase courte : quelques itérations de quelques semaines**
**Activités principales de l’élaboration**
***Capture et analyse des besoins***
* Compléter la liste des cas d’utilisation * Description abrégée des cas d’utilisation * Description détaillée / Diag. de séquences de 40 à 80% * Faire un prototype de l’interface utilisateur
***Analyse et Conception Orientées Objet***
Publicité
* Stabiliser la conception architecturale * Architectures logique et de déploiement * Effectuer la conception des cas sélectionnés
***Réalisation et test***
* Limités au squelette de l’architecture * Valider les choix
**7.3. Phase 3 : Construction**
****
**Objectif : Réaliser une version bêta**
🡪Phase la plus couteuse englobe conception, codage, tests, intégration.
**Activités principales de la construction**
***Capture et Analyse des besoins***
* Spécifier l’interface utilisateur * Terminer l’analyse de tous les cas d’utilisation
***Analyse et Conception Orientées Objet***
* L’architecture est fixée * Concevoir les packages et classes pour réaliser les cas * Selon l’ordre de priorité
***Réalisation et Tests***
* Réaliser et tester les cas, intégrer les incréments
**7.4. Phase 4 : Transition**
****
**Objectif : Mise en service chez l’utilisateur**
* Test de la bêta-version, correction des erreurs * Préparer la formation, la commercialisation
**Activités principales de la transition**
* Préparer la version bêta à tester * Installer la version sur le site client, convertir et faire migrer les données nécessaires (Livraison) * Gérer le retour des sites (retour client) et Corriger le reliquat d’erreurs * Adapter le produit corrigé aux contextes utilisateurs (installation) * Améliorer le produit * Terminer les livrables du projet (modèles, documents...) * Déterminer la fin du projet * former les utilisateurs * Planifier le prochain cycle de développement
**\*\*\*Récapitulation\*\*\***
****
1. **Caractéristiques d’UP** 1. **UP est guidé par les cas d’utilisation**
* Objectif du processus : la construction d’un système qui réponde à des besoins par construction complexe de modèles * CU utilisés tout au long du cycle * Validation des besoins / utilisateurs * Point de départ pour l’analyse (découverte des objets, de leurs
relations, de leur comportement) et la conception (sous
systèmes)
* Guide pour la construction des interfaces * Guide pour la mise au point des plans de tests * Les cas d’utilisation lient les modèles
* 1. **UP est centré sur l’architecture** * L’architecture sert de lien pour l’ensemble des membres du projet * Contrainte de l’architecture : plus le projet avance, plus l’architecture est difficile à modifier 🡪les risques liés à l’architecture sont très élevés, car très coûteux * Objectif pour le projet : établir dès la phase d’élaboration des fondations solides et évolutives pour le système à développer, en favorisant la réutilisation * Construire une architecture comme forme dans laquelle le système doit s’incarner * Les CU réalisés doivent y trouver leur place * La réalisation des CU suivant doit s’appuyer sur l’architecture * Qui permette de promouvoir la réutilisation * Qui ne change pas trop : converger vers une bonne architecture rapidement 1. **UP est itératif, incrémental**
| | | --- | | * Anti-cascade, spirale * Construction progressive du système * Chaque itération permet de maîtriser une partie des risques et apporte une preuve tangible de faisabilité. 🡪 Produit un système partiel opérationnel (exécutable, testé et intégré) avec une qualité égale à celle d’un produit fini (alpha) (qui peut être évalué: permet de savoir si on va dans la bonne direction ou non) * Série de prototypes qui vont en s’améliorant de plus en plus de fonctionnalités disponibles  |