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

© Petko ValtchevUniversité de Montréal Janvier 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

© Petko ValtchevUniversité de Montréal Janvier 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é)?

© Petko ValtchevUniversité de Montréal Janvier 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

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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

© Petko ValtchevUniversité de Montréal Janvier 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

© Petko ValtchevUniversité de Montréal Janvier 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

© Petko ValtchevUniversité de Montréal Janvier 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

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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

© Petko ValtchevUniversité de Montréal Janvier 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.

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

© Petko ValtchevUniversité de Montréal Janvier 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

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

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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.

© Petko ValtchevUniversité de Montréal Janvier 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!!!  