M22- GENIE LOGICIEL ET CONCEPTION

ORIENTEE OBJETS (UML)

Lotfi NAJDI
Année Universitaire 2022 / 2023
Génie Informatique
FPT Taroudant
Introduction général au génie logiciel
Définition du génie logiciel

Le génie logiciel, l'ingénierie logicielle ou l'ingénierie du logiciel (en anglais : software

engineering) est une science qui étudie les méthodes de travail et les bonnes

pratiques des ingénieurs qui développent des logiciels. Le génie logiciel s'intéresse en

particulier aux procédures systématiques qui permettent d'arriver à ce que des logiciels

de grande taille correspondent aux attentes du client, soient fiables, aient un coût

d'entretien réduit et de bonnes performances tout en respectant les délais et les

coûts de construction.

Wikipedia
Définition du génie logiciel

L'application d'une approche systématique, rigoureuse et mesurable au

développement, à l'exploitation et à la maintenance des logiciels, c'est-à-dire

l'application de l'ingénierie aux logiciels.

IEEE
Définition du génie logiciel

Discipline technologique et managériale qui s'occupe de la production et de la

maintenance systématiques de produits logiciels qui sont développés et modifiés

en respectant les délais et les coûts prévus.

Richard Fairley
Historique

• Le terme « software engineering » a été mentionné publiquement pour la première fois

en 1968.

• Ce terme Il a été repris l'année suivante à une conférence concernant la crise du logiciel.

• La crise logiciel fait référence aux difficultés rencontrées dans le développement des

projets informatiques initialement focalisée sur les calculs scientifiques simples.

• Le développement logiciel s’ouvre sur la gestion des entreprises, commande de

procédés industriels , embarquées.

Crise logiciel

Les problèmes logiciels majeurs arrivent très souvent

• Dépassements de budget

• Livraison tardive

• Exigences erronées

• Produit livré non accepté par les clients

Solution à la crise logiciel

• L'ingénierie logicielle constitue un moyen permettant d'aider les entreprises de logiciels à

travailler de manière organisée , systématique et disciplinée.

• Faire la complexité du développement logiciel (taille des projets et des équipes )

• Prise en charge de toutes les étapes nécessaire à construction d'un logiciel.

• Amélioration de la qualité des produits logiciels.

 Crise du logiciel

Standish group

• SUCCESSFUL (RÉUSSI) : Projets réalisés dans les délais , respectent le budget impartis, avec
un résultat satisfaisant

• CHALNGED (MITIGÉ) : Projets achevés et approuvés mais livrés en retard, hors budget ou sans toutes
les fonctionnalités demandées

• Failed (ECHOUÉ) : Projets abandonnés c.-à-d. produits non livrés ou bien livrés
mains non utilisés à cause de non satisfaction
Crise du logiciel

Standish group
Programmation(écriture de code) et génie logiciel

• La programmation est en réalité une petite partie du génie logiciel !

• L'une des principales différences entre "l'écriture de code" et "l'ingénierie logicielle"

consiste à suivre un processus spécifique.

• Par processus, on entend une série d'étapes ou de phases suivies à chaque fois par une
équipe pour s'assurer de la construction d'un logiciel se fait correctement.

• Analogie : Construction de bâtiment

• Savoir poser des briques et construire un mur ne suffisent pas!

• Que faut-il de plus ?

Génie logiciel

Le génie logiciel s'intéresse à l’ensemble des activités du processus de développement

logiciel

• Analyse des besoins et Spécification (Requirements and Specification)

• Conception (Design)

• Programmation (Programming , Implementation )

• Test : Validation et vérification (Testing )

• Déploiement

• Maintenance (Maintenance )
Recueil des besoins(Requirements Elicitation)

Recueil / Identification /capture des exigences / des besoins.

La collecte des exigences est le processus qui consiste à identifier et comprendre les besoins du

client.

Etablir et documenter les véritables besoins d’une application :

• Etudier le contexte métier (processus, règles, standards, etc.),

• Etat actuel de l’environnement (l’existant)

• Rôle attendu de l’application, ressources disponibles et requises, performances espérées,

contraintes d’utilisation, etc.

Techniques de recueil des besoins

Le recueil des besoins vise à comprendre le problème, construire et formuler les besoins

bruts.

• Entretien : très courant, généralement structuré, mais il peut s'agir aussi de conversation

simple (groupes de travail et brainstormings)

• Questionnaires

• Observation in situ des utilisateurs : observer le travail quotidien des gens et détecter les

problèmes.

• Lecture de documents et procédures

Techniques de recueil des besoins

Principales questions à se poser :

• À qui l’application est-elle destinée ?

• Pourquoi est-elle attendue ?

• Quels problèmes doit-elle résoudre ? Quel est son périmètre ?

• Quelles seront ses conditions d’utilisation ?

• Quand est-elle attendue ?

• Comment fonctionnera-t-elle ?
Techniques de recueil des besoins

Le document d’expression des besoins peut inclure des maquettes pour

les IHM et un glossaire pour fixer le vocabulaire du projet.

L’introduction du prototypage rapide dans le processus de

développement permet :

• Identifier ce que l’utilisateur souhaite en termes d’organisation des

écrans, principaux contenus, interactions..etc.

• Faciliter recueil des besoins

• Soutenir de communication avec les clients et utilisateurs

Les Maquette peuvent être produites à la main, avec des logiciels de

dessin ou des outils spécialisés de prototypage.
Difficultés liées au recueil de besoin

• Les utilisateurs ont une compréhension insuffisante de leurs besoins.

• Les développeurs connaissent mal le domaine de l’application.

• les développeurs et le client ne parlent pas le même langage.

• Les informations "évidentes" sont omises.

• Différentes parties prenantes ont des points de vue contradictoires.

• Les exigences sont volatiles et peuvent évoluer dans le temps.

Spécification (Requirements Specification)

La spécification des exigences est une reformulation des exigences dans un format technique compréhensible et

exploitable par les développeurs.

• Spécification = Quoi

• Formalisation et description claire de ce que doit faire le logiciel

• Détail des fonctionnalités offertes , comportement observable de l’application pour ses utilisateurs, exigences

fonctionnelles et non fonctionnelles

• Clarification du cahier des charges (ambiguïtés, contradictions)

• Modéliser les exigences ( problème) pour approfondir la compréhension

• Alignement entre les gens du métier et du technique

Objectif de la spécification

• Parvenir à un consensus au sein de l'équipe sur les fonctionnalités du logiciel avant de

commencer le codage proprement dit.

• Permettre une compréhension claire et commune des exigences :

• ce qui doit être construit exactement par les développeurs

• Ce qui doit être tester et approuvé par les personnes qui font la vérification et la

validation

• Communiquer aux parties prenantes les résultats qu'elles sont censées obtenir une fois les

travaux de développement terminés.

Formes de spécifications

Les spécification peuvent prendre plusieurs formes selon la méthodologie utilisée :

• Document de spécification des besoins (Software Requirements Specification SRS,

BRD,FRD ) sous forme de statements “The system shall…”
Spécifications en langage naturel (textuelle)

• Use Cases : Acteurs principaux , Scénario principal, Alternatives et extensions ..etc.

• User Stories : En tant que <rôle> Je veux <fonctionnalité> Afin de <résultat>

Caractéristique <priorité, complexité technique, valeur métier, état>
Critères d’acceptation
Quelle que soit la technique employé , l’essentiel est d’établir une compréhension profonde
des besoins et des exigences exactes et exploitables
Recueil vs Spécification

• Le recueil des exigences (besoins) est centré sur le client (les utilisateurs) , alors que

la spécification est centrée sur le développeur.

• Les exigences brutes sont rédigées de manière simple afin d’ être compréhensibles

par des gens du métier (qui n'ont pas férocement background technique).

• Après recueil des besoins brutes , on procède à l’analyse , la revue et vérification afin

de détecter les éventuelles erreurs . L’objectif est d’avoir un accord et une

compréhension partagée du besoin de la part des parties prenantes.

• La spécification doit être non ambiguë pour les développeurs afin de permettre une

compréhension parfaite du système à réaliser.

Exigences non fonctionnelles

• Exigences fonctionnelles : Exigences qui spécifient les fonctions qui doivent être réalisées

par le système (services qu’elle doit rendre).

• Exigences non fonctionnelles :

• Exigences qui ne sont pas nécessairement associées à une fonctionnalité unique,

mais qui décrivent un état/condition du système(les exigences qualitatives ).

• Contraintes : Exigences qui restreignent la mise en œuvre

Exigences non fonctionnelles

Les exigences non fonctionnelles sont généralement transversales et concernent l'ensemble

du système (ne se limitent pas à une fonction, une classe ou un module).

• Sécurité : Accès , données .

• Performance : temps de réponse , ressources exigées, temps de réponse, taux de

transaction.. etc.

• Facilité d'utilisation et ergonomie (usability ).

• Fiabilité (reliability) : fréquence des pannes, récupération. (reliability)

Exigences non fonctionnelles
Contraintes

Les contraintes diffèrent sont relatives à l’implémentation c.-à-d. sous lesquelles le système

doit être développée, et non pas aux fonctionnalités ou les conditions sous lesquelles il doit

fonctionner :

• Langages de programmation, OS, outils, matériel, etc.

• Interfaçage avec d’autres systèmes

• Aspects juridiques, licences, etc.

Conception

COMMENT construire le système (Solution).

Conception générale ou préliminaire :

 Décrit les concepts de haut niveau du produit logiciel final (structure de la solution

proposée) .

 Dégager les composants appropriés, les responsabilités et les relations entre ces

composants.
Conception

Conception détaillé

• Décrit le détail technique à un niveau de granularité plus fin

• Préciser comment fonctionne chaque sous-partie de l'application

• Détails en termes d’attributs, structuration des données , opérations (algorithmes en

pseudo-code)

• Décrire comment les responsabilités de chaque composant sont assumées.

les diagrammes techniques et modèles sont largement utilisés à ce stade afin de décrire la

solution à mettre en œuvre.

Implantation (Programming , Implementation)

Codage de la solution conçue par les équipes de développement :

• Environnement de développement

• Langages de programmation

• logiciel de gestion de versions (version control system)

• Revue de code (code review )

• Documentation du code
Validation et vérification

Vérification : Did we build the thing right?

• S'assurer que le produit est construit de manière correcte.

• Se fait tout au long du projet et peut prendre plusieurs formes différentes.

• Il est toujours moins coûteux de détecter les problèmes à un stade précoce du processus

de développement.
Validation et vérification

Validation: Did we build the right thing?

• S’assurer que le produit (logiciel) répond aux besoins des utilisateurs ?

• Pour s’assurer qu’on a construit la solution adéquate :

• Parties prenantes à convaincre dans le projet : Client ,Utilisateurs principaux,

utilisateurs qui vont demander le support

• Comment :

• Démonstration directe

• Version livrable de votre système qui sera évaluée

• Version finale(Recette finale)

Types de tests

Tests unitaires :

• Chaque composant de l’application est testé isolément

• Pour un objet , vérifier que chaque opération fonctionne correctement ?

Tests d’intégration

• Test de l’assemblage et interactions entre les différents composants de l’application

• Vérifier que les différentes parties du logiciel fonctionnent correctement ensemble ?

Types de tests

Tests système (test de validation) :

• Le système dans son ensemble est évalué.

• Validation par les développeurs que le système fonctionne est conforme aux spécifications
(fonctionnelles et non fonctionnelles).

Test d’acceptation (recette) :

• La conformité du système aux au cahier des charges est évalué

• Validation par le client du système complet par rapport aux exigences.

Déploiement

Livraison sur les sites concernés d’ un sous-ensemble du système ou du système complet

selon le processus de développement en question :

• Installation (manuelle ou automatisée)

• Mise en en production

• Formation des utilisateurs.

• Instauration d’une procédure et une organisation pour le support et la remontée des

questions, problèmes et suggestions.

• Manuels d’utilisation

• Guide d’installation et d’exploitation

Maintenance

La phase de maintenance commence après déploiement de l’application.

• Maintenance corrective: identification et corriction des erreurs détectées pendant le

fonctionnement de l’application après la livraison(bugs).

• Maintenance adaptative : adaptation du logiciel aux changements(change) dans son

environnement :

• règles métier

• formats des données

• Environnement d’exécution..etc.

• Maintenance perfective: Amélioration des performances ou de la maintenabilité et à

l’ajout de nouvelles fonctionnalités.
Qualité logiciel

Aspects de la qualité fonctionnelle

- Respect des exigences spécifiées pour le logiciel

- Création de logiciels présentant peu de problèmes

- Performances optimales

- Facilité de prise en main et d'utilisation

Qualité logiciel

Aspects de la qualité structurelle

- Maintenabilité du code

- Compréhensibilité du code

- Efficacité du code

- Sécurité du code
Qualité logiciel

Aspects de la qualité des processus

- Respect des dates de livraison

- Respect des budgets

- Un processus de développement reproductible qui produit des logiciels de qualité de

manière fiable