© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus Hiver 2002 Petko Valtchev.

Présentation au sujet: "© Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus Hiver 2002 Petko Valtchev."— Transcription de la présentation:

1 © Petko ValtchevUniversité de Montréal Janvier 2002 1 IFT 2251 Génie Logiciel Le Processus Hiver 2002 Petko Valtchev

2 © Petko ValtchevUniversité de Montréal Janvier 2002 2 Bases Sommaire l Logiciel, tentative de définition l Génie logiciel, aspects historiques l La qualité des logiciels l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus

3 © Petko ValtchevUniversité de Montréal Janvier 2002 3 Bases Les Questions Questions fondamentales: l Quel est le problème à résoudre? l Quelles sont les fonctionnalités désirées du logiciel? l Comment sera conçu et construit le logiciel? l Quelle technique sera utilisée dans la détection des erreurs (bogues) dans le logiciel l Comment le logiciel sera-t-il maintenu (corrigé et/ou amélioré)?

4 © Petko ValtchevUniversité de Montréal Janvier 2002 4 Bases Les Activités Les Activités constituant le Processus: 1. Acquisition des besoins 2. Analyse 3. Conception 4. Implémentation 5. Vérification et validation 6. Maintenance 7. Retrait l + Gestion des ressources humaines et matérielles

5 © Petko ValtchevUniversité de Montréal Janvier 2002 5 Bases Définitions « Processus: fournit un cadre pour le développement en apportant des réponses aux principales questions d’ordre organisationnel. » Pressman, 2001 Comment gérer les activités du projet? Comment utiliser les ressources techniques? Comment produire les différents documents (pour décrire modèles, données, avancement du projet, etc.)? Comment fixer les objectifs du projet à long, moyen et court terme? Comment gérer les éventuels changements? Ex. Rational Unified Process, Extreme Programming, etc.

6 © Petko ValtchevUniversité de Montréal Janvier 2002 6 Bases Définitions ( suite ) « Méthode : Décrit une manière d’aborder les différentes activités (souvent un sous-ensemble) du développement du logiciel en proposant des principes, des théories, des formalismes, des techniques de modélisation et de spécification pour réaliser ces activités. » Pressman, 2001 Ex. OMT, OOA/OOD, Objectory, etc.

7 © Petko ValtchevUniversité de Montréal Janvier 2002 7 Bases Définitions ( fin ) « Outil : Support automatisé ou semi-automatisé pour l’application d’une méthode ou d’un processus. » Pressman, 2001 Atelier de Génie Logiciel: Ensemble cohérent d'outils informatiques formant un environnement d'aide à la conception, au développement et à la mise au point de logiciels d'application spécialisés. Computer-Aided Software Engineering (CASE) Tool

8 © Petko ValtchevUniversité de Montréal Janvier 2002 8 Bases Sommaire l Logiciel, tentative de définition l Génie logiciel, aspects historiques l La qualité des logiciels l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus

9 © Petko ValtchevUniversité de Montréal Janvier 2002 9 Bases status quo définition du problème technique développement solution intégration de la Résolution itérative de problèmes Le Processus Logiciel Ré-évaluation de la situation: Phase 2 Phase 1 Phase 3

10 © Petko ValtchevUniversité de Montréal Janvier 2002 10 Bases Les Phases, 1 l Objectifs l Besoins : Comprendre le problème l Spécification : Identifier les caractéristiques requis du système l Pourquoi : répondre à l'évolution des matériels, des systèmes, des langages de programmation, et surtout la complexité toujours croissantes des logiciels. 1. Définition Quel public (usagers)? Quelles fonctionnalités? Quelles propriétés? Quelles performances? Quelles comportements? Quel type d’interfaces? QUOI

11 © Petko ValtchevUniversité de Montréal Janvier 2002 11 Bases Les Phases, 2 2. Developpement l Comment structurer l’information? l Comment implémenter la conception logicielle? l Comment tester le logiciel? COMMENT l Objectif l Traduction progressive des spécifications (Le Problème) vers une description du système (La Solution) sans pour autant produire ce système. l Pourquoi : réduire la complexité du passage entre la description du problème et sa solution.

12 © Petko ValtchevUniversité de Montréal Janvier 2002 12 Bases Les Phases, 3 3. Maintenance l Corrections l Adaptations l Améliorations l Modifications préventives CHANGEMENT Pourquoi : l Erreurs l Évolution de l’environnement l Nouveaux besoins l Anticipation sur les conditions de fonctionnement et de maintenance Réingénierie

13 © Petko ValtchevUniversité de Montréal Janvier 2002 13 Bases Activités de support I C D 1. Suivi du projet 2. Révision formelle 3. Contrôle de la qualité 4. Documentation 5. Gestion de la réutilisation 6. Évaluation 7. Gestion du risque etc. 1. Suivi du projet 2. Révision formelle 3. Contrôle de la qualité 4. Documentation 5. Gestion de la réutilisation 6. Évaluation 7. Gestion du risque etc.

14 © Petko ValtchevUniversité de Montréal Janvier 2002 14 Bases Maturité du Processus Primitif (Initial) Reproductible (Repeatable) Défini Bien géré (Managed) Optimisant                      Le modèle proposé par SEI (Software Engineering Institute)

15 © Petko ValtchevUniversité de Montréal Janvier 2002 15 Bases Sommaire l Logiciel, tentative de définition l Génie logiciel, aspects historiques l La qualité des logiciels l Le processus de production l Concepts de base l Nature du processus et phases l Modèles de processus

16 © Petko ValtchevUniversité de Montréal Janvier 2002 16 Bases Le Modèle en Cascade analyse conceptioncodetest Ingénierie du système Le modèle classique de développement

17 © Petko ValtchevUniversité de Montréal Janvier 2002 17 Bases La Cascade Ingénierie du système - phase préliminaire Système (au sens large) = configuration de composantes l matérielles, l logicielles (BD, réseaux, passerelles Web, etc.), l humaines (usagers du système). dans laquelle devra s’intégrer le logiciel à développer. Besoins - clarification des besoins relatifs à tous les éléments du système Vue d’ensemble sur les besoins.

18 © Petko ValtchevUniversité de Montréal Janvier 2002 18 Bases Les Activités Analyse des besoins l Objectif : éviter de produire un logiciel inadéquat. l Démarche : l Étudier les besoins et les spécifier de la manière la plus claire possible. l Les éléments pertinents incluent: l le domaine d’application, l l'environnement du futur système, l le rôle escompté du système, l les ressources disponibles et requises, l les contraintes d'utilisation, l les performances attendues.

19 © Petko ValtchevUniversité de Montréal Janvier 2002 19 Bases Les Activités Conception l Objectif : transformer la description du problème obtenu par l’analyse en une description (de plus en plus détaillée) de la solution, sans pour autant produire la solution elle-même. l Démarche : l La conception architecturale: l décomposition du système logiciel en sous-systèmes (composants) de taille et complexité inférieures; chaque sous- système est décrit par ces fonctions et les interfaces avec le reste du système. l La conception détaillée: l définition des détails concernant la réalisation de chaque composant: algorithmes, structures de données, etc.

20 © Petko ValtchevUniversité de Montréal Janvier 2002 20 Bases Les Activités Implémentation l Objectif : Production du code des composants à partir de leurs conceptions détaillées. l Démarche : l Si la conception est de bonne qualité, la génération se fait de manière directe et peut être automatisée pour une grande partie.

21 © Petko ValtchevUniversité de Montréal Janvier 2002 21 Bases Les Activités Vérification (tests) l Objectif : S’assurer que le logiciel produit respecte les spécifications initiales. l Démarche : l Vérification de l’ensemble des descriptions produites tout au long du développement. l Examens des artefacts du développement: l preuves de correction l tests dynamiques = choix d’une sous-ensemble représentatif des données possibles et exécution du logiciel avec ces données.

22 © Petko ValtchevUniversité de Montréal Janvier 2002 22 Bases Les Activités Maintenance l Objectif : S’assurer que le logiciel livré continue de répondre aux besoins du client qui peuvent évoluer dans la période post-livraison. l Démarche : l Correction d’erreurs, l Adaptations l Ex. nouvelle plate-forme, l Améliorations l Ex. service accessible via le Web. l Changements au logiciel = nécessité de traverser une ou plusieurs (voire toutes) les phases du développement en cascade.

23 © Petko ValtchevUniversité de Montréal Janvier 2002 23 Bases Le Modèle en Cascade Bilan Les projets réels suivent rarement un déroulement purement séquentiel, souvent il y a des retours en arrière. Le client est rarement capable d’exprimer la totalité de ses besoin en une seule fois, d’habitude il prend conscience de certains besoins au cours du projet. Le client doit être patient car il ne verra une version exécutable de son système que vers la fin du processus de développement.  Problème de validation important!!!  