Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Notes de Cours Ingénierie logicielle Cours 1 Introduction aux processus de déve

Notes de Cours Ingénierie logicielle Cours 1 Introduction aux processus de développement de logiciel Présenté par Mr KHIAT S. M1 informatique PLAN 1. Définition génie logiciel 2. Qualité du logiciel 3. Type de processus de développement 4. Les modèles de développement de logiciel 5. Norme IEEE std830 cahier des charges 6. Définition génie logiciel Processus unifié RUP Génie logiciel software engineering • Définition Ingénierie : Application d’une approche systématique, disciplinée et quantifiable aux structure, machine, produit, système ou processus. • Définition logiciel (software, [John tukey,1958]) Définition 1: programmes, procédures et avec possibilité de documentation associée et des données en rapport à l’exploitation du système informatique Définition 2: tous ou une parties des programmes, procédures, règles et des documents associé à un système de traitement d’information Génie logiciel (Définition) • Définition software engineering [Conférence l’ OTAN,1968] Définition 1: Application d’une approche systématique, discipliné et quantifiable au développement, exploitation et maintenance du logiciel, c’est-à-dire l’application l’ ingénierie au logiciel Définition 2: Application systématique des connaissances scientifique et technologique, des méthodes et des expériences dans la conception, l’implémentation, le teste et la documentation du logiciel • Objectif: La fabrication du logiciel sans faute, livré dans le délai et le budget prévus à l’avance, et qui satisfait aux besoins du client (gagner) délais (échéance), coûts et qualité Qualité du logiciel Définition 1: Capacité d’un produit logiciel de satisfaire des besoins prévus et implicites sous des conditions spécifiées (même les détailles ex sans cnx= avoir une vue globale) Définition 2: Degré de satisfaction des besoins prévus et implicites sous des conditions spécifique • L’assurance qualité logicielle (AQL) est un ensemble d'activités planifiées et systématiques de toutes les actions nécessaires pour fournir une assurance suffisante qu'un logiciel produit ou modifié est conforme aux exigences et aux attentes établies. ( les fonctionnalités = les exigence ) Qualité du logiciel Critères de qualité ISO\IEC 25010_ Qualité du produit logiciel Fonction souhaitabl e Fiabilit é Efficacité et performanc e Utilisabilité Sécurité Compatibilit é maintenabilit é portabilit é Complétud e fonctionnell e Exactitude fonctionnell e. Pertinence fonctionnell e Comportem ent du temps. Utilisation des ressources. Capacité. Caractère reconnaissable. Facilité d'apprentissage . Opérabilité. Protection contre les erreurs utilisateur. Esthétique de l'interface utilisateur. Accessibilité Confidentialité . Intégrité. Non- répudiation. Responsabilité. Authenticité Co- existence Interopera bility Modularité. Réutilisabilité Analysabilité . Modifiabilité . Testabilité. Adaptabilité . Facilité d'installation. Remplaçabilit é Maturité. Disponibilité. Tolérance aux pannes. Récupérabilit é Qualité du logiciel Critères de qualité Fonction souhaité  Cette caractéristique représente la mesure dans laquelle un produit ou un système fournit des fonctions répondant aux besoins déclarés et implicites lorsqu'il est utilisé dans des conditions spécifiées. Fiabilité  Mesure dans laquelle un système, un produit ou un composant remplit des fonctions spécifiées dans des conditions spécifiées pendant une période spécifiée. (moins de pannes) • Efficacité de la performance  Cette caractéristique représente la performance par rapport à la quantité de ressources utilisée dans les conditions indiquées. • Utilisabilité  Mesure dans laquelle un produit ou un système peut être utilisé par des utilisateurs spécifiés pour atteindre des objectifs spécifiés avec efficacité, efficience et satisfaction dans un contexte d'utilisation spécifié. Qualité du logiciel Critères de qualité Sécurité  degré de protection des informations et des données par un produit ou un système afin que les personnes ou les autres produits ou systèmes disposent du degré d'accès aux données approprié à leur type et à leur niveau d'autorisation • Compatibilité  Mesure dans laquelle un produit, système ou composant peut échanger des informations avec d'autres produits, systèmes ou composants et / ou remplir ses fonctions requises tout en partageant le même environnement matériel ou logiciel. • Maintenabilité  Cette caractéristique représente le degré d’efficacité avec lequel un produit ou un système peut être modifié pour l’améliorer, le corriger ou l’adapter aux changements de l’environnement et des exigences • Portabilité  Degré d'efficacité avec lequel un système, un produit ou un composant peut être transféré d'un matériel, d'un logiciel ou d'un autre environnement opérationnel ou d'utilisation à un autre.. Modèle et méthodes • Processus de développement du logiciel un ensemble d’activités inter liées et interconnectées dans le quel les besoins de l’utilisateur sont transformés en logiciel  Un processus décrit 2 choses importantes : Les activités (étapes) (QUOI ?) L’enchainement des activités (QUAND?) • Modèles cycle de vie du logiciel. Les modèles décrivent les liens, les relations entre les différentes étapes du cycle de vie du logiciel. • Méthodes cycle de vie du logiciel. Les méthodes permettent de mettre en œuvre un développement logiciel selon un modèle en organisant les différentes étapes du cycle de vie du logiciel. Méthode = Démarche + Langage Type de processus de développement Processus prédictifs (Ex: V, Cascade, Spirale) Processus adaptatifs (Ex: RUP, 2TUP, XP) • Planification très précise et très détaillée. • L’équipe de développement accomplit dans un ordre strict les phases de développement. • La planification rigoureuse ne permet pas d’évolutions dans les besoins des utilisateurs et fait travailler au ralenti les membres de l’équipe de développement. ex: jeux • Ils correspondent à un cycle de vie itératif qui considère les changements des besoins des utilisateurs, et de l’architecture technique. • Ils privilégient la livraison par tranche en commençant par les fonctionnalités utiles au client. Les modèles de développement de logiciel Le modèle en cascade Modèle en V Le modèle en spirale  Développement incrémental (prototypage)  Modèle orienté réutilisation .……………….. Le modèle en cascade Étude préalable 1. Phase exploratoire Dossier d’entretiens Décisions (faire, ne pas faire, faire faire, acheter) Budget approximatif 2. Phase conceptuelle Cahier des charges Plan général du projet Budget précis Définition des contraintes Spécification 1. Document de spécification (fonctions et performances) 2. Première version du manuel utilisateur 3. Plan détaillé du reste du projet 4. Plan de validation  Conception générale Définition des principales structures de données Décomposition du système en modules (architecture) Description du rôle de chaque module  Conception détaillée Description détaillée des structures de données et des modules  Codage Texte des programmes Chaque module est vérifié séparément  Validation globale, recette Compte rendu de recette Rapports d’inspection et de validation  Diffusion Versions des programmes et de leur documentation adaptées  Exploitation Programme en fonctionnement Rapports d’incidents et de correction Modèle en V Codage des modules Spécifications du système Conception préliminaire (sous-systèmes) Conception détaillée (modules) Validation via les tests d’acceptation Intégration des sous- systèmes et modules, tests correspondants Tests unitaires des modules Scenarii de tests du système Scenarii de tests des sous-systèmes Scenarii de tests des modules Modèle en V • Il précise la conception des tests :  Les tests système sont préparés à partir de la spécification.  Les tests d’intégration sont préparés à partir de la conception architecturale.  Les tests unitaires sont préparés à partir de la conception détaillée des composants. • Avantages  Montre comment les activités de «test» sont liées à celles d'«analyse et de conception». • Inconvénients  Manque de (ou difficile) «feedback». Pas de résultats intermédiaires dont on peut discuter avec le client Le modèle en spirale Le modèle en spirale Spécification : communiquer avec le client Analyse de risque : évaluation des risques techniques et des risques de gestion Implémentation et vérification : construire, tester, installer et fournir un support utilisateur Validation: obtenir des retours Planification : définir les ressources, la répartition dans le temps Le modèle en spirale Utilisation de la nature itérative du prototypage avec les aspects systématiques et contrôlés du modèle en cascade Les premières itérations peuvent être des modèles sur papier ou des prototypes Développement incrémental (prototypage) La norme IEEE 830 la norme IEEE 830 « Pratiques recommandées pour la spécification des exigences logicielles (SEL) » But de la norme:  Aider les clients à décrire le plus clairement possible ce qu’ils veulent  Aider les fournisseurs à comprendre ce que le client veut  Aider à définir une table des matières normalisée pour la SEL  Aider à définir le contenu de chaque chapitre  Aider à préparer des listes de vérification Norme IEEE std830 cahier des charges I-Introduction 1. Objectifs (décrire des objectifs et spécifie le public prévu) 2. La portée (nom du logiciel, ce que doit faire le logiciel...) 3. définition, acronyme et abréviation 4. Références 5.Vue générale ( décrit le contenu du SRS et comment il est organisé) II-Description générale 1. Environnement du projet 2. Fonctions générales du système 3. Caractéristiques des utilisateurs 4. Contraintes 5. Hypothèses et dépendances III. Les exigences spécifiques Cette troisième partie peut être organisée de différentes manières. (nous nous contenterons, d’une seule organisation) 3.1 Exigences des interfaces externes 3.1.1 Interfaces avec les utilisateurs 3.1.2 Interfaces avec le matériel 3.1.3 Interfaces avec les logiciels 3.1.4 Interfaces de communication 3.2 Exigences fonctionnelles 3.2.1 Mode 1 3.2.2.1 Exigence fonctionnelle 1.1 . . . 3.2.1.n Exigence fonctionnelle 1.n 3.2.2 Mode 2 . . . 3.2.m Mode m 3.2.m.1 Exigence fonctionnelle m.1 . . . 3.2.m.n Exigence fonctionnelle m.n 3.3 Exigences de performance 3.4 Contraintes de conception 3.5 Attributs du système logiciel 3.6 Autres exigences Norme IEEE std830 cahier des charges 4.1 La table de matière et uploads/Industriel/ cour-khyat-zrbda.pdf