Vous êtes sur la page 1sur 50

M1 informatique

Notes de Cours
Ingénierie logicielle

Cours 1
Introduction aux processus de développement
de logiciel

Présenté par
Mr KHIAT S.
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 Fiabilit Efficacité et


Compatibilit maintenabilit portabilit
souhaitabl performanc Utilisabilité Sécurité
e é e
é é é

Complétud Caractère Modularité.


e reconnaissable. Confidentialité
fonctionnell Maturité.
Comportem Facilité
. Réutilisabilité
e ent du d'apprentissage Co- Adaptabilité
Disponibilité. Intégrité. .
temps. .
Opérabilité. existence Analysabilité Facilité
Exactitude Tolérance Non- . d'installation.
fonctionnell Utilisation des
aux pannes. Protection répudiation.
Interopera
e. ressources. contre les Remplaçabilit
Modifiabilité
Récupérabilit
erreurs Responsabilité. bility é
Capacité. utilisateur. .
Pertinence é
Esthétique de Authenticité
fonctionnell Testabilité.
l'interface
e utilisateur.

Accessibilité
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)


• 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

Processus adaptatifs (Ex: RUP, 2TUP, XP)

• 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

Spécifications Scenarii de tests du système Validation via les


du système tests d’acceptation

Conception préliminaire Scenarii de tests des sous-systèmes


Intégration des sous-
(sous-systèmes) systèmes et modules,
tests correspondants

Scenarii de
Conception détaillée tests des Tests unitaires des
(modules) modules modules

Codage 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 l’index


 4.3 Annexes
Partie 2 Introduction aux
méthodes de développement

 Processus adaptatif

_ Processus unifié
1) RUP
Processus adaptatifs
• Ils correspondent à un cycle de vie itératif et incrémentale

• Ils privilégient la livraison par tranche en commençant par les


fonctionnalités utiles au client.

 Il existe 3 grandes familles de processus de développement :


Processus unifier (RUP, 2TUP…….)
Méthode Agile (XP, Scrum, RAD.……)
Méthode autre ( AUP, XUP, EssUP,……..)
Méthode
• Méthode (contexte développement)
 Une démarche reproductible pour obtenir un résultat
fiable. (composée de +ieurs processus)

 Méthode de développement des système d’information

 Les règles de modélisation et construction de système


logiciel de manière fiable et reproductible (langage)

 les règle de mise en œuvres qui décrivent


l’enchainement des actions, ordonnancements des
taches et la répartition des taches (démarche)
Processus unifier
Piloté par les cas d’utilisation
Centré sur l’architecture
 Architecture:

 Définition
Un ensemble de règles qui définie la structure d’un système
et les relations entre ces parties
Un pattern

 Définition 1
Un pattern est une solution à un problème dans un contexte.

 Définition 2
Un patron décrit à la fois un problème qui se produit très fréquemment
dans l’environnement et l’architecture de la solution à ce problème de
telle façon que l’on puisse utiliser cette solution des milliers de fois
sans jamais l’adapter deux fois de la même manière.
Rational Unified Process (RUP)
 Le Rational Unified Process (RUP) est l’une des plus célèbres
implémentations de la méthode PU

• Caractéristiques du RUP :

 Itératif
 Utilisation de modèle (UML)
 Centré sur l’architecture
 Piloté par les cas d’utilisation
 Supporte les techniques orientées objets
 Processus configurable
 Contrôle de qualité et gestion des risques
Cycle de vie RUP
Définition
 Phase: laps de temps écouler entre de jalons majeur (important) du
processus de développement et au cours du quel un ensemble
d’objectifs est atteint

 Un jalon : un ensemble d’artefacts qui ont atteint une réalisation


fixée au préalable (point de repère)
 Il existe deux types:
 Un jalon majeur: chaque phase se termine avec un jalon
majeur, c’est un jalon ou sont prises d’important décisions sur
le plan commerciale,
 Un jalon mineur: jalon intermédiaire entre deux jalon majeur
exemple: les jalons de fin d’itération

 Itération : représente un cycle de développement complet


Artefacts
• N'importe quel produit du travail
• C'est la spécification d'une information physique utilisée ou
produite par un procédé de développement logiciel

• Un artefact peut être :


 Un modèle
 Un élément de modèle
 Un document
 Du code source
 Des exécutables
 ………………...
Inception (Pré-étude)
• Délimiter la portée du système,
• Définir les frontières et identifier les interfaces
• Développer les cas d’utilisation
• Décrire et esquisser l’architecture candidate
• Identifier les risques les plus sérieux
• Démontrer que le système proposé est en mesure de
résoudre les problèmes ou de prendre en charge les objectifs
fixés

 Vision : Glossaire, Détermination des parties prenantes et


des utilisateurs, Détermination de leurs besoins, Besoins
fonctionnels et non fonctionnels, Contraintes de conception
Elaboration
• Spécification des fondements de l’architecture, créer une
architecture de référence
• Identifier les risques, ceux qui sont de nature à bouleverser le
plan, le coût et le calendrier,
• Définir les niveaux de qualité à atteindre,
• Formuler les cas d’utilisation pour couvrir environ 80% des
besoins fonctionnels et de
planifier la phase de construction,
• Planification du projet, élaborer une offre abordant les
questions de calendrier, de personnel et de budget

 Architecture : Document d’architecture Logicielle, Différentes


vues selon la partie prenante,
Comportement et conception des composants du système
Construction
• Extension de l’identification, de la description et de la
réalisation des cas d’utilisation
• Finalisation de l’analyse, de la conception, de
l’implémentation et des tests
• Préservation de l’intégrité de l’architecture
• Surveillance des risques critiques et significatifs identifiés dans
les deux
premières phases et réduction des risques

 Produit
Transition
• Préparation des activités
• Recommandations au client sur la mise à jour de
l’environnement logiciel
• Elaboration des manuels et de la documentation concernant
la version du produit
• Adaptation du logiciel
• Correction des anomalies liées aux tests
• Dernières corrections
 Livraison du produit aux utilisateurs
flux de travaux (les
enchainement)
• Modélisation métier :
– Compréhension de la structure et la dynamique de
l'organisation
– Comprendre les problèmes posés dans le contexte de
l'organisation
– Conception d’un glossaire
• Recueil et expression des besoins :
– Auprès des clients et parties prenantes du projet
– Ce que le système doit faire
– Expression des besoins dans les cas d'utilisation
– Spécifications des cas d'utilisation en scénarios
– Limites fonctionnelles du projet
– Spécifications non fonctionnelles
– Planification et prévision de coût
– Production de Maquettes de l’IHM
flux de travaux (les
enchainement)
• Analyse et conception :
– Transformation des besoins utilisateurs en modèles UML
– Modèle d'analyse et modèle de conception
• Implémentation :
– Développement itératif
– Découpage en couches
– Composants d'architecture
– Retouche des modèles et des besoins
– Unités indépendantes, équipes différentes
• Test, Déploiement, Configuration et gestion des
changements, Gestion de projet, Environnement,
Déploiement
flux de travaux (les enchainement
principaux de soutient)

 Le but de la gestion de la configuration et des changements est de


garder la trace de tous les éléments tangibles qui participent au
développement et de suivre leurs évolutions
 La gestion de projet a les buts suivants :
• procurer un cadre pour gérer les projets logiciels ;
• procurer des lignes de conduites pratiques pour planifier, répartir le
personnel, exécuter et contrôler les projets ;
• procurer un dispositif de gestion du risque.
 L’environnement. Le but de l’environnement est de supporter
l’organisation du développement avec les processus et les outils.
Modèle
Utilisation des diagrammes
Utilisation des diagrammes
Utilisation des diagrammes
Utilisation des diagrammes
Utilisation des diagrammes
Utilisation des diagrammes
Merci pour votre attention

Vous aimerez peut-être aussi