AGL Intro

Atelier Génie Logiciel
Cycle de vie d’un logiciel
Abdelali Saidi
saidi.a@ucd.ac.ma
Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 1 / 43

Plan
1 Le génie logiciel
Définitions
Qualité du logiciel
2 Principes fondamentales du développement logiciel

Rigueur
Décomposition
3 Cycle de vie d’un logiciel

Le cahier des charges
Modèles de cycle de vie d’un logiciel

Le génie logiciel
Plan
Définitions
Rigueur
Décomposition

Le génie logiciel Définitions
Le génie logiciel
Définitions
Projet
Le projet est un ensemble d’actions à réaliser pour satisfaire un objectif défini,
dans le cadre d’une mission précise, et pour la réalisation desquelles on a identifié
non seulement un début, mais aussi une fin.a
a AFITEP, Dictionnaire de management de projet [1996]
Projet de développent logiciel

Le projet de développement d’un logiciel est un projet qui a pour objectif le
développement d’une application quelconque.

Le génie logiciel
Définitions
Le logiciel
Un logiciel est un ensemble d’entités nécessaires au fonctionnement d’une tâche
informatisée d’un système. Parmi ces entité on a :
Codes sources
Exécutables
Documentations
...
Génie logiciel
Le génie logiciel est une science de l’ingénieur qui englobe plusieurs phases (la
conception, le développement et la maintenance) qui mènent à l’accomplissement
d’un système informatique.

Le génie logiciel
Définitions
Types de logiciels
Logiciels sur mesure : Fait pour un client spécifique
Logiciel générique : Adaptable à un ensemble de clients

Le génie logiciel
Quelques chiffres
Répartitions des coûts de développement
Spécification : 6%
Conception : 5%
Codage : 7%
Tests et validations : 15%
Maintenance : 67%
Coûts de correction des erreurs
Exigences et spécifications : 56%
Conception : 24%
Codage : 10%
Autres : 10%

Le génie logiciel
Objectifs et risques
Objectifs
Le génie logiciel vise à garantir :
Une spécification correcte
Un logiciel qui respecte cette spécification
Un coût et un délai de réalisation respectables
Risques majeurs du développent de logiciels

Ne pas satisfaire les exigences du client
Produire un logiciel non fiable
Dépasser les délais, le coût ...

Le génie logiciel Qualité du logiciel
Critères de la qualité du logiciel

La qualité d’un logiciel dépend des 4 critères suivants :
Maintenabilité
Robustesse
Efficacité
Utilisabilité

Le génie logiciel Qualité du logiciel
Fabrication d’un logiciel de qualité

Pour un logiciel de qualité, il faut se donner un cadre rigoureux
Guider le développement du logiciel
Contrôler les coût
Évaluer les risques
Respecter les délais
Évaluer le logiciel par étapes

Principes fondamentales du développement logiciel
Plan
Définitions
Rigueur
Décomposition

Principes fondamentales du développement logiciel Rigueur
Principes fondamentales
Les grands principes du génie logiciel

La rigueur
La décomposition des problèmes en sous-problème
La modularité
L’abstraction
L’anticipation des évolutions
La généricité
La construction incrémentale

Principes fondamentales du développement logiciel Rigueur
L’anticipation des évolutions

Prévoir l’évolution que peut avoir un logiciel permet une meilleure
maintenance
Les modifications que peut avoir un logiciel doivent être le plus possible
locales
Sinon cela mettra en cause la validation faite précédemment
L’idéal est de concevoir un système suffisamment riche pour que l’on puisse le
modifier d’une manière incrémentale

Principes fondamentales du développement logiciel Décomposition
La rigueur
Les principales sources de défaillance d’un logiciel sont d’origines humaine
Toujours se poser des questions à propos de la validité de ses décisions
Utiliser les outils de vérification (Computer Aided Software Engineering)
pour réduire la marge d’erreur

La décomposition des problèmes en sous-problème

Diviser pour reigner
Décorréler les problèmes pour n’en traiter qu’un seul à la fois
Simplifier les problèmes pour traiter leur complexité progressivement
Exemple :
La communication réseau (modèle en couches)
L’architecture logiciel en MVC

La modularité
Elle fait partie du prncipe décomposition des problèmes
Il s’agit de partitionner le logiciel en plusieurs modules qui sont cohérents

L’abstraction
Également une partie du principe décomposition des problèmes
Créer des concepts généraux qui englobent plusieurs cas particuliers
Cela permet de raisonner efficacement
Exemple
générics du java
template du C++

La généricité
Un logiciel réutilisable est plus valeureux qu’un module dédié
Un logiciel est générique lorsqu’il est adaptable

La construction incrémentale
La meilleure façon pour réussir l’aboutissement d’un logiciel en
développement est de le construire d’une manière incrémentale
Question : Quelle est la meilleure méthode de procéder ?
Écrire le code entièrement et le compiler par la suite
Écrire le code d’une fonction, compiler et avancer encore et encore

Cycle de vie d’un logiciel
Plan
Définitions
Rigueur
Décomposition

Cycle de vie d’un logiciel Le cahier des charges
Développent d’un logiciel

Un projet réussi
L’aboutissement d’un projet dépends impérativement de la définition écrite,
détaillé, précise, exhaustive et évaluable :
des objectifs à atteindre
des ressources requises
de la planification de la mise en oeuvre
des outils d’évaluation
des méthodes de contrôle
la compréhension et la collaboration du propriétaire (Maitre d’ouvrage -
MOA) et le fournisseur (Maitre d’oeuvre - MOE)
D’où la nécessité d’un cahier de charges et de sa spécification


Définition
Un cahier des charges est un document contractuel décrivant ce qu’attend le
MOA de la part du MOE. Ce document doit décrire de la façon la plus simple et
précise possible les besoins du MOA auxquels le MOE doit répondre.
Caractéristiques
Il doit être fonctionnel (ne pas avoir de détails techniques)
Il doit contenir tous les éléments nécessaires qui permettront au MOE de :
Juger de la taille du projet
Juger de sa complexité
Offrir un devis (coût, délai, ressources humaines ...) adéquat
Idéalement statique


Éléments principaux dans un cahier des charges
Le contexte
Un cahier des charges commence généralement par une section qui décrit le
contexte :
Analyse du besoin : il faut acquérir le métier et bien comprendre le besoin et
les enjeux du MOA
Analyse de l’existant : il faut bien décrire l’environnement du MOA
(Matériels, logiciels, RH impacté)


L’objectif
Permettre de comprendre le but recherché
Ce que doit le produit final permettre de faire


Le vocabulaire
Permettre une communication correcte (MOA et MOE sont souvent de
différentes cultures)
Il se peut que le MOA pense avoir utilisé un terme générique et qu’il soit un
terme technique chez le MOE


Le calendrier
Des dates précise que le MOA va imposer
Éviter l’effet tunnel


Les clauses juridiques

Un cahier des charges est document contractuel entre MOA et MOE. Il doit
posséder un certain nombre de clauses juridiques :
Définir la propriété intellectuelle de l’ouvrage
Définir les pénalités en cas de non respect des délais
Définir des tribunaux compétents en cas de litige


L’expression fonctionnelles des besoins

Cela consiste à :
Décomposer le besoin en fonctionnalités
Pour chaque fonctionnalité, il faut expliquer sa mise en oeuvre à partir de
l’angle de vue de l’utilisateur
Comment une fonctionnalité doit satisfaire un besoin
Définir les règles de gestion


L’expression des besoins techniques

Ce sont des besoins non fonctionnelles tels que :
La sécurité
La fiabilité
Identifier des métriques de mesure pour chaque besoin


Les contraintes
Le coût : spécifier le budget alloué au projet
Les délais : spécifier la date des livrables
autres : Normes techniques, clauses juridiques ...


Plan d’un cahier des charges

I Positionnement et objectifs du projet
II Organisation du travail (membres des équipes,. . . )
III Spécifications applicatives (Fonctionnel)
IV Spécifications techniques (architecture cible, environnement matériel/logiciel,
...)
V Contraintes ( de coûts, de délais, . . . )
VI Spécification d’évaluation

Cycle de vie d’un logiciel Modèles de cycle de vie d’un logiciel
Définition
Un ensemble structuré d’activités qui conduisent à la production d’un logiciel
Objectif
Contrôler l’avancement du développement du logiciel
Vérifier et valider cet avancement
S’apercevoir des problèmes liés au logiciel le plutôt possible
Remarques
Il n’existe pas de cycle idéal
Le cycle dépends de l’entreprise qui l’adopte
ses besoins
son domaine
ses contraintes de qualité
les personnes impliqués

Rôles d’un cycle

En général, un cycle de vie d’un logiciel comprend les activités suivantes :
L’analyse des besoins
La spécification du logiciel
La conception
L’implémentation
L’intégration
La vérification et la validation


Rôle d’un cycle
L’analyse des besoins

Objectif :
Déterminer ce que doit faire et ne pas faire le logiciel
Déterminer les ressources et les contraintes
Caractéristiques :
Parler métier et non informatique
Entretiens et questionnaires
Observation de l’existant (comparaison avec des situations similaires)
Résultat :
Rôle du système
Futur utilisation
Aspects de l’environnement


Rôle d’un cycle
La spécification
Objectif :
Établir une première description du logiciel final
Analyse des besoins
+
Les faisabilités informatiques
Résultat :
Spécification technique des besoins
Description de ce que fera le logiciel (et non comment)


Rôle d’un cycle
La conception
Objectif :
Décrire la structure du logiciel
Décider les technologies qui répondront au mieux au besoin
Détailler la description technique du logiciel
Résultat :
Conception architecturale
Conception détaillée


Rôle d’un cycle
Répartition des activités

Un projet bien conduit consomme :
40% pour l’analyse, spécification et conception
20% pour l’implémentation
40% intégration, vérification et validation

Modèle de cycles de vie

Plusieurs modèles sont proposés :
Modèle en cascade
Modèle en V
Modèle spirale

Modèle en cascade

Modèle en cascade
On ne commence une nouvelle phase que si on a dèjà terminé celle d’avant
À la terminaison de chaque phase il faut produire un document pour
améliorer le suivi du projet
Ce modèle s’adapte aux systèmes complexes
La détection d’une anomalie ne doit concerner que la phase précédente
il faut donc reprendre à partir de cette phase précédente
il faut reproduire de nouveaux documents à la fin de cette phase
cela impose une réflexion sur ses choix vu le coût que peut faire une correction
Ce modèle est déconseillé pour les projets difficiles à spécifier (exprimer) leurs
besoins

Modèle en V

Modèle en V
C’est une amélioration du modèle précédent
Les phases montantes renvoient de l’information vers les phases en vis-à-vis
Cela permet l’amélioration du logiciel en cas de découverte d’anomalie

Modèle de développent évolutif

Modèle de développent évolutif

Les trois activités sont entrelacées
Un prototype est rapidement écrit et est confronté à l’utilisateur
La spécification dépend de chaque résultat
On reprend avec le prototype et sa confrontation jusqu’au résultat final
Ce modèle a plus de chances de bien répondre aux besoins de l’utilisateur
Il est incrémentale
Il est parfait pour les projets de taille moyenne

Modèle de développent à livraison incrémentale

Modèle de développent à livraison incrémentale

On affecte des priorités aux besoins de l’utilisateur
Chaque avancement du projet dépend de ces priorités
On livre d’une manière incrémentale en respectant les priorités
cela minimise le risque d’inadéquation avec le produit final
se focaliser sur les fonctionnalités coeur peut compromettre le développement
des fonctionnalités secondaires

AGL Intro

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AGL Intro

Transféré par

Droits d'auteur :

Formats disponibles

Atelier Génie Logiciel

Cycle de vie d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 1 / 43

2 Principes fondamentales du développement logiciel

3 Cycle de vie d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 2 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 3 / 43

Projet de développent logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 3 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 4 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 5 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 6 / 43

Risques majeurs du développent de logiciels

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 7 / 43

Critères de la qualité du logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 8 / 43

Fabrication d’un logiciel de qualité

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 9 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 10 / 43

Les grands principes du génie logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 10 / 43

L’anticipation des évolutions

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 11 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 12 / 43

La décomposition des problèmes en sous-problème

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 13 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 14 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 15 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 16 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 17 / 43

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 18 / 43

Développent d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 18 / 43

Développent d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 19 / 43

Développent d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 20 / 43

Développent d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 21 / 43

Développent d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 22 / 43

Développent d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 23 / 43

Développent d’un logiciel

Les clauses juridiques

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 24 / 43

Développent d’un logiciel

L’expression fonctionnelles des besoins

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 25 / 43

Développent d’un logiciel

L’expression des besoins techniques

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 26 / 43

Développent d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 27 / 43

Développent d’un logiciel

Plan d’un cahier des charges

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 28 / 43

Modèles de cycle de vie d’un logiciel

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 29 / 43

Modèles de cycle de vie d’un logiciel

Rôles d’un cycle

Abdelali Saidi Atelier Génie Logiciel saidi.a@ucd.ac.ma 30 / 43

Modèles de cycle de vie d’un logiciel