Génie Logiciel Définitions et grandes problématiques

Présentation au sujet: "Génie Logiciel Définitions et grandes problématiques"— Transcription de la présentation:

1 Génie Logiciel Définitions et grandes problématiques
Hakim Lounis et Hafedh Mili Copyright

2 Sommaire Définitions Origines GL et autres disciplines
Nature et Qualités Principes

3 Définitions Application de l’ingénierie aux logiciels ;
Champ de l’informatique relatif au système logiciel : large & complexe construit par une équipe existe en plusieurs versions date de quelques années évolue …

4 Définitions Application d’une approche systématique, disciplinée et quantifiable pour le développement, l’opération et la maintenance du logiciel (IEEE 1990). “Multi-person construction of multi-version software” (Parnas 1978) GL partie d’un projet plus large en conception de système : systèmes embarqués

5 Sommaire Définitions Origines GL et autres disciplines
Nature et Qualités Principes

6 Histoire GL né en 1968 en réponse à des échecs répétés de grands projets logiciels en terme de rencontre de contraintes de temps et de budget. Le terme devient populaire après la Conférence de l’OTAN à Garmisch Partenkirchen (Germany), 1968.

7 Rôle du software engineer
Programmation non suffisante ! GL : comprendre les besoins et produire des spécs dériver des modèles et raisonner dessus être membre d’une équipe communication gestion construire un logiciel opérer à différents niveaux d’ abstraction

8 Sommaire Définitions Origines GL et autres disciplines
Nature et Qualités Principes

9 Relation entre GL et d’autres disciplines de l’informatique
Langages de programmation Systèmes d’exploitation Bases de données Intelligence artificielle Théorie

10 Relation entre GL et d’autres disciplines
Science de la gestion Ingénierie des systèmes Autres …

11 Sommaire Définitions Origines GL et autres disciplines
Nature et Qualités Principes

12 Nature du GL et qualité Le GL est uen activité intellectuelle “human-intensive” Un produit logiciel est construit pour rencontrer des objectifs fonctionnels et satisfaire des qualités Le processus doit aussi satisfaire des considérations de qualité

13 Classification des attributs de qualité
Internes vs. externes Externes  visibles aux usagers Internes  concernent les développeurs Produit vs. processus Le but est de développer des produits Le processus nous indique comment faire Les qualités internes affectent les qualités externes La qualité du processus affecte la qualité du produit

14 Correction Un logiciel est correct s’il satisfait les spécifications des besoins fonctionnels ; Si le programme est spécifié de façon formelle, on peut en prouver la correction comme un théorème ou alors prouver sa non correction par l’établissement de contre-exemples (test)

15 Limites de la correction
Qualité absolue (oui/non) “degré de correction” ? “séverité de la déviation” ? Problème si les spécs sont fausses … Vérification versus validation

16 Fiabilité Fiabilité Intuitivement, cela veut dire que les usagers peuvent s’y fier Peut-être définie mathématiquement comme la probabilité de l’absence d’erreurs pendant une durée de temps donnée

17 Robustesse Robustesse
Le logiciel se comporte de façon “raisonnable” même dans des circonstances exceptionnelles (entrées erronées, défaillances matériel, etc.)

18 Performance Utilisation efficiente des ressources Peut-être vérifiée
mémoire, temps d’exécution, temps de communication Peut-être vérifiée Analyse de complexité Par évaluation de performance (par simulation, par des tests, etc.) La performance affecte la possibilité de mise à l’échelle (scalability) Un serveur qui peut se comporter convenablement avec 10 usagers peut se planter royalement avec 100 (dégradation non-linéaire)

19 Utilisabilité Les usagers trouvent le logiciel facile à utiliser
Autre terme: “user-friendly” Certains aspects sont mesurables E.g. keystroke model D’autre sont subjectifs I.e., on ne sait pas encore les mesurer  Principalement reliée aux interfaces usagers Usager final, administrateur, etc.

20 Vérifiabilité La mesure dans laquelle il est possible de vérifier certaines propriétés Peut-être un facteur déterminant dans le choix d’une architecture pour un système critique

21 Maintenabilité Maintenance: modifications après livraison ou déploiement. Trois types de maintenance corrective: corriger des erreurs d’implantation (20%) adaptive: adjuster le logiciel à des changements dans son environnement (20%) perfective: améliorer la qualité du logiciel (performance, maintenabilité, etc.) (>50%) Maintenabilité : facilité de maintenir le logiciel La maintenance représente plus de 60% du coût du logiciel durant sa vie

22 Reutilisabilité Construire un produit à partir d’un produit ou des composants existants, moyennant des modifications “mineures” Effort Dégradation de qualité On peut réutiliser des produits ou des processus Le degré de réutilisation dans un domaine est un indicateur de sa maturité

23 Portabilité Capacité du logiciel de fonctionner sur différentes plateformes logicielles et matérielles Java n’a pas reglé le problème définitivement PDA vs. téléphone vs. PC vs. mainframe

24 Compréhensibilité Facilité de comprendre le logiciel
Essentiel pour la maintenance (et la maintenabilité)

25 Interopérabilité Capacité du système à co-exister et inter-agir avec d’autres systèmes: Standardization des protocoles de communication Standardization des protocoles d’invocation Standardization des formats de données Etc.

26 Qualité du processus Productivité “Ponctualité” (timeliness)
La mesure du rapport extrants/intrants (efforts, personnel, etc.) “Ponctualité” (timeliness) Capacité de livrer les produits à temps Visibilité Toutes les étapes sont clairement documentées

27 Mesurer la qualité Plusieurs attributs de qualité sont subjectifs
Pas de définition de métriques standards pour la plupart des attributs de qualité

28 Application de principes
Principes s’appliquant au processus et au produit Principes appliqués à travers des méthodes et des techniques souvent, méthodes et techniques constituent des méthodologies méthodologies sont supportées par des outils

29 Représentation

30 Sommaire Définitions Origines GL et autres disciplines
Nature et Qualités Principes

31 Principes clés Rigueur et formalisme “separation of concerns”
Modularité Abstraction Anticipation des changements Généralité Incrémentalité

32 Rigueur et formalisme Génie logiciel implique la créativité (résolution de problèmes inédits) On voudrait que ce soit systématique Rigueur et créativité se complètent Formalisme = rigueur totale

33 Separation of concerns
Pour maîtriser la complexité d’un problème, on sépare les problématiques pour les traiter une à la fois "Diviser pour règner" : temps, qualité, vues, taille, Supporte la parallélization des efforts et la séparation des responsabilités

34 Modularité Un système complexe peut être divisé en modules
Un système qui est composé de modules de qualité est appelé modulaire La modularité permet la “separation of concerns” Les concerns qui tombent dans les frontières des modules …

35 Cohésion et couplage Chaque module doit être cohésif
Ses parties sont reliées au même objectif Les modules doivent être faiblement couplés Peu d’intéractions Compréhensibles séparément

36 Une illustration Couplage élevé Couplage bas

37 Abstraction Identifier les aspects importants d’un phénomène et en ignorer les détails “separation of concerns” est une façon de faire de l’abstraction Le type d’abstraction dépend de l’objectif poursuivi. Abstraction = projection!

38 L’abstraction ignore les détails
Example: equations describing complex circuit (e.g., amplifier) allows designer to reason about signal amplification Equations may approximate description, ignoring details that yield negligible effects (e.g., connectors assumed to be ideal)

39 L’abstraction produit des modèles
For example, when requirements are analyzed we produce a model of the proposed application The model can be a formal or semiformal description It is then possible to reason about the system by reasoning about the model

40 Anticipation des changements
Pour que le logiciel puisse “évoluer” à moindre coût, il faut prévoir– et accommoder– les changements futurs potentiels L’anticipation des changements résulte en la capacité d’évolution du logiciel (evolvability)

41 Généralité En résolvant un problème donné, voir si ce problème n’est pas un cas particulier d’un problème plus général qu’on pourra résoudre à la place Trouver un équilibre entre généralité et: Performance Coût

42 Incrementalité Processus de développement livre en “incréments”
Exemples (processus) Livrer un premier sous-ensemble de fonctionnalités critiques pour ajouter les autres par la suite Se pré-occuper d’abord d’architecture, et après de fonctionnalités d’affaires Livrer un premier prototype qu’on transforme après en produit