CHAPITRE 2: Processus Logiciels

18

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

9

CHAPITRE 2: Processus Logiciels

Activités du cycle de vie

Avant-projet

Initiation du projet

n o i t s e G

t e j o r p e d

Développement

Planification, Pilotage & Suivi Gestion de qualité

Exploitation & Maintenance

Retrait

Évaluation

s e u q i n h c e t

s é t i v i t c A

Analyse

Conception

Étude préalable

Implémentation

Tests

Mise hors service

Maintenance & Assistance

Installation

Documentation

Vérification et Validation (V&V)

Gestion de la configuration

19

CHAPITRE 2: Processus Logiciels

A c t i v i t é s d e d é v e l o p p e m e n t

Maintenance et assistance

 La maintenance du logiciel : Modifications apportées à un

logiciel après sa mise en œuvre

 But:

 Corriger les fautes  Améliorer l'efficacité ou autres caractéristiques  Adapter à un environnement modifié

 Tâches:

 Effectuer des corrections mineures /majeures  Réappliquer le cycle de développement pour des modifications

plus importantes

 Assistance :

 Fournir l’assistance technique  Maintenir un journal des demandes d’assistance et de support.

20

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

10

CHAPITRE 2: Processus Logiciels

A c t i v i t é s d e d é v e l o p p e m e n t

Types de maintenance

 Maintenance corrective : modification d'un logiciel

afin de corriger les défauts rencontrés.

 Maintenance adaptative : modification d'un logiciel

pour qu'il reste utilisable dans un environnement qui change ou a changé.

 Maintenance évolutive : mise à jour du logiciel à la suite

de modification des spécifications d’un point de vue fonctionnel ou performance.

 Maintenance préventive : modification d'un logiciel pour en déceler et corriger les défauts latents avant qu'ils ne se manifestent.

CHAPITRE 2: Processus Logiciels

A c t i v i t é s d e d é v e l o p p e m e n t

Quelques chiffres ?

21

22

14/09/2017

11

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

CHAPITRE 2: Processus Logiciels

Activités du cycle de vie

Avant-projet

Initiation du projet

n o i t s e G

t e j o r p e d

Développement

Planification, Pilotage & Suivi Gestion de qualité

Exploitation & Maintenance

Retrait

Évaluation

s e u q i n h c e t

s é t i v i t c A

Analyse

Conception

Étude préalable

Implémentation

Tests

Mise hors service

Maintenance & Assistance

Installation

Documentation

Vérification et Validation (V&V)

Gestion de la configuration

23

CHAPITRE 2: Processus Logiciels

A c t i v i t é s d e g e s t i o n d e p r o j e t

Avant le développement

 Initiation du projet: préparation de la gestion de projet:

 Représenter les activités à entreprendre dans un modèle

 Identifier les tâches et procédures du projet et les mesures à

mettre en place pour contrôler leur application

 Prévoir les ressources nécessaires au projet

 Planifier la gestion de projet

24

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

12

14/09/2017

CHAPITRE 2: Processus Logiciels

A c t i v i t é s d e g e s t i o n d e p r o j e t

Lors du développement

1. Affinement de la planification du projet

 La planification du projet définit les tâches, le

calendrier, les ressources, l’allocation de ces ressources aux tâches et les procédures du projet.

2. Pilotage et suivi du projet

 Enregistrer les faits sur l’avancement du projet et le

comparer à la planification;

 Entreprendre, si nécessaire, des mesures correctives.

25

CHAPITRE 2: Processus Logiciels

A c t i v i t é s d e g e s t i o n d e p r o j e t

Lors du développement

3. Gestion de la qualité:

 Définir et planifier un programme pour mesurer la

qualité;

 Piloter et contrôler l’application du programme de

qualité;

 Recommander des améliorations pour les programmes.

 La gestion de la qualité du logiciel et les activités de vérification et de validation sont parfois regroupées sous le nom « assurance de qualité du logiciel ».

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

26

13

14/09/2017

CHAPITRE 2: Processus Logiciels

A c t i v i t é s d e g e s t i o n d e p r o j e t

Après le développement

 Evaluation du projet:

 Respect des objectifs  Respect des coûts  Respect des délais -> Suggestions d’améliorations pour les projets futures!

 Gestion de la maintenance et de l’assistance  Identification des tâches et planification  Estimation des coûts et des délais

A la prochaine séance!

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

27

28

14

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Aperçu

 Modèles classiques  Modèles linéaires

 Modèle en cascade  Modèle en V  Modèles itératifs

 Modèle par prototypage  Modèle de développement incrémental

 Modèle orienté réutilisation  Modèles de la transformation formelle  Modèles agiles : SCRUM,…  Modèles orientés objet

 PU  2TUP, …

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle en cascade

 Présente le développement logiciel comme une suite de phases qui s’enchaînent dans un déroulement linéaire.

Analyse

V&V

Conception globale et détaillée

V&V

Implémentation

V&V

Tests unitaires

[Royce70]

V&V

Intégration et Tests

V&V

Installation

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

29

30

14/09/2017

15

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle en cascade

 Chaque étape doit être achevée avant que ne débute la

suivante.

 Chaque fin d’étape est matérialisée par un événement, où s’exerce une activité de contrôle (V&V) afin d’éliminer au plus tôt les anomalies des produits réalisés.

 Le passage à l’étape suivante est conditionné par le résultat

de contrôle (acceptation, rejet, ajournement)

 Les retours en arrière sur les étapes précédentes se limitent

à un retour sur l’étape immédiatement antérieure.

C o u r s « G L - A C O O » E N S I

Adapté aux projets dont les besoins sont clairs dès le début du projet.

31

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle en cascade: Bilan

 Avantage

 Facile à comprendre

 Inconvénients

 Pas toujours adapté à une production logicielle, en

particulier si les besoins du client sont changeants ou difficiles à spécifier

 Le client ne reçoit pas de résultats concrets pendant le

développement du logiciel (Problème de l’effet tunnel )

 Coût de modification d'une erreur important, donc choix en amont cruciaux (typique d'une production industrielle)

32

C o u r s « G L - A C O O » E N S I

14/09/2017

16

CHAPITRE 2: Processus Logiciels

Modèle en V

Analyse des besoins

Ecriture

Validation

M o d è l e s d e p r o c e s s u s

Tests système

Spécification

Tests d’acceptation

Conception Globale

Tests d’intégration

Conception Détaillée

Tests unitaires

Codage

33

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle en V

 Processus linéaire dérivé du modèle de la cascade;  La première branche correspond à un modèle en

cascade classique.

 Les premières étapes du cycle doivent préparer les dernières étapes, essentiellement les activités de vérification et de validation.

 Toute description d’un composant est accompagnée de

définitions de tests.

 Avec les jeux de tests préparés dans la première

branche, les étapes de la deuxième branche peuvent être mieux préparées et planifiées.

 La seconde branche correspond à des tests effectifs

effectués sur des composants réalisés.

34

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

17

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle en V

 Deux sortes de dépendances entre étapes :

 Traits continus : correspondent à l’enchaînement du modèle

en cascade, les étapes se déroulent séquentiellement en suivant le V de gauche à droite

 Traits non continus : Une partie des résultats de l’étape de

départ est utilisée directement par l’étape d’arrivée.  Par exemple : à l’issue de la conception globale, le

protocole d’intégration et les jeux de tests d’intégration doivent être décrits.

35

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle en V: Bilan

Avantages

 Un e m eilleure spécifica t ion

 évite d’énoncer une propriété qu’il est impossible de vérifier objectivement une

fois le logiciel réalisé.

 Préven ir les erreurs

 l’obligation de concevoir les jeux de tests et leurs résultats oblige à une

réflexion et à des retours sur la description en cours.

 Un e m eilleure pla n ifica t ion du projet :

 Les étapes de la branche droite du V peuvent être mieux préparés et planifiés.

Inconvénients

 Le clien t n e reçoit pa s de résult a t s con cret s pen da n t le développem en t du

logiciel

 Les va lida t ion s in t erm édia ires n ’em pêch en t pa s la t ra n sm ission des

in suffisa n ces des ét a pes précéden t es

 Ada pt é a ux projet s de t a ille et de com plex it é m oyen n e.

36

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

18

14/09/2017

CHAPITRE 2: Processus Logiciels

Modèle du prototypage

M o d è l e s d e p r o c e s s u s

 Prototype = une version de tout ou d’une partie d’un logiciel, facile à mettre en œuvre et à modifier qui va permettre de vérifier rapidement certaines fonctionnalités

 Il n’est pas construit avec les mêmes contraintes de

qualité que le logiciel final.

 Technique souvent utilisée pour la validation des

spécifications

CHAPITRE 2: Processus Logiciels

Modèle du prototypage

M o d è l e s d e p r o c e s s u s

Analyse préliminaire des besoins

Analyse et sélection des nouvelles fonctions

État non satisfaisant

Construction du prototype

Évaluation expérimentation

État satisfaisant

Expression claire des besoins réels

37

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

• Initialement, les spécifications données par le client sont

d’ordre général ;

• Raffinement des spécifications, des fonctionnalités et des

Spécifications définitives

performances par des prototypes successifs.

• Quand le client donne son accord, le développement suit

souvent un cycle de vie linéaire.

38

19

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle du prototypage: Bilan

Avantages  Pour le client: Une approche où domine l’écoute total du client.

 Le client reçoit des résultats tangibles rapidement ;  Le client peut exprimer ses besoins plus facilement;  Le client peut changer d’avis sans conséquences dramatiques.

 Pour l’utilisateur:

 Expérimentation rapide par les utilisateurs et feedback immédiat.  Former les utilisateurs avant la livraison du système final.

 Pour l’équipe de développement:

 Meilleure clarification des spécifications  Amélioration de la COMMUNICATION entre d’une part le client et

l’analyste, d’autre part l’analyste et le concepteur

Inconvénients  Impatience du client qui croît avoir un logiciel final.  Problème relatif à la gestion de projet (planification, estimation des

coûts, etc.)

39

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Prototype évolutif

 Vise à pallier à la linéarité dans le modèle en cascade et au

caractère « jetable » dans le prototypage;

 Le prototype est complété et amélioré jusqu’à la livraison

finale du logiciel

 Principe (démarche méthodologique)

 Développer une première spécification  Conception et réalisation du prototype  Utiliser le prototype  Evaluation,  Corrections et amélioration  Itérations 2, 3,…  Livrer le logiciel

40

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

20

14/09/2017

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Prototype évolutif: Bilan

Avantages

 Modèle adapté aux systèmes non spécifiables (certains

systèmes d’IA)  Caractère itératif

Inconvénients

 Difficultés liées à la gestion du projet (le temps et le

coût ne sont pas maîtrisés)

 Mal adapté aux systèmes complexes.

41

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle incrémental

 A été proposé dans les années 80  Incrément= version  Propose un développement du logiciel par morceaux,

lesquels sont livrés successivement au client, en venant se greffer à un noyau logiciel.

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

42

21

14/09/2017

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle incrémental

Analyse et spécification des besoins

Conception détaillée d’un incrément

Conception architecturale

Codage d’un incrément

Validation de l’incrément

Intégration

Validation du système

Système final

43

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle incrémental

 Un seul sous-ensemble des composants est développé à la fois

 Un logiciel noyau est tout d’abord développé puis,  Des incréments sont successivement développés et intégrés

 Permet d’éviter de tout concevoir, de tout coder et de tout

tester

 Les spécifications du logiciel sont figées et connues, l’étape de

conception globale est terminée.

 Certains modèles proposent de développer les différents incréments en parallèle:

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

44

22

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle incrémental: Bilan

Avantages  Des livraisons et des mises en service possible après chaque

intégration d’incrément ;  Faire accepter progressivement un logiciel par les utilisateurs

 Intégration allégée: les intégrations et leurs tests sont

progressifs ;

 Maintenance allégée (par incrément)

Inconvénients  Remise en cause du noyau ou les incréments précédents

(définition globale des incréments et de leurs interactions dès le début du projet).

 Pour chaque version à développer après la 1ère version livrée,

il faut arbitrer entre les demandes de correction et les nouvelles fonctionnalités à développer.

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle orienté réutilisation

 Basée sur une réutilisation systématique de composants

existants pour concevoir un nouveau système

 Les étapes du processus

 Analyse des composants  Spécification des modifications  Conception avec réutilisation  Développement et intégration

 De plus en plus utilisé de nos jours

45

46

14/09/2017

23

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Types de composants réutilisables

 Les Web services

 Développés selon des standards  Disponibles par appel sur un serveur

 Collections d’objets intégrés dans un framework (tel

que .NET ou J2EE)

 Logiciels autonomes (COTS: Commercial Off The

Shelf ) configurés pour une utilisation dans un environnement particulier

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle orienté réutilisation: Bilan

Avantages  Réduire le coût  Livraison et déploiement du logiciel souvent rapide Inconvénient  Il est souvent nécessaire de faire des compromis vis à vis des spécifications d’où le risque de produire un logiciel qui ne répond pas aux vrais besoins des utilisateurs.

14/09/2017

24

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

47

48

14/09/2017

A la prochaine séance!

49

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle de la transformation formelle

 Une spécification d’un logiciel est formelle si elle est

exprimée avec un langage qui possède:

 un vocabulaire et une syntaxe formellement définis;  une sémantique basée sur les mathématiques.

 Ce modèle se base sur des notations mathématiques (il permet au spécifieur de décrire rigoureusement, sans ambiguïté ce que le logiciel doit faire)

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

50

25

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle de la transformation formelle

T:Transformations

T1

T2

T3

Tn-1

Tn

Spécification formelle

R1

R2

….

Rn

Programme Exécutable

P

P

P

P

P

P: Preuves de la correction (démonstration formelle) des transformations R: raffinement

Si la spécification satisfait les propriétés et l’implémentation traduit la spécification alors l’implémentation satisfait aussi les propriétés

51

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle de la transformation formelle

Avantages

 Améliorer la qualité du logiciel;  Rigueur et précision des spécifications;  Faciliter la validation;  Automatiser la vérification;  Favoriser le développement de programmes corrects et

documentés formellement.

Inconvénients

 Nécessite une certaine qualification du client, utilisateurs et

développeurs;

 Ne facilite pas la communication avec les utilisateurs;  Le produit est obtenu à la fin du processus.

52

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

26

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle agiles

 Agilité = la capacité d’une organisation à créer de la valeur et à ravir son client, tout en favorisant et en s’adaptant -à temps- aux changements de son environnement.

 Les méthodes agiles:

 sont plus pragmatiques que les méthodes

classiques (en adéquation avec les capacités et les limites humaines).

 impliquent au maximum le client et permettent une

grande réactivité à ses demandes.

 Visent en priorité la satisfaction réelle du client

(contrat de développement).

53

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle agiles

• Une méthode agile est une approche itérative et

incrémentale, qui est menée dans un esprit collaboratif

• Elle génère un produit de haute qualité tout en prenant

en compte l’évolution des besoins des clients

• Concepts formalisés en 2001 par le Manifeste Agile»

(4valeurs fondamentales)

http://agilemanifesto.org/iso/fr/

54

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

27

14/09/2017

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Valeurs de l’agilité

Privilégier

Personnes et interactions

Un produit opérationnel

Collaboration avec le client

Adaptation au changement

Plutôt que

Processus et outils

Plutôt que

Plutôt que

Documentation pléthorique

Négociation d'un contrat

Plutôt que

Suivi d'un plan

C o u r s « G L - A C O O » E N S I

55

CHAPITRE 2: Processus Logiciels

Valeurs de l’agilité

M o d è l e s d e p r o c e s s u s

1.Priorité aux personnes et aux interactions par rapport aux procédures et aux outils …

 Ce sont les individus, leur expertise, l’esprit d’équipe

(plutôt que les processus et les outils) qui font la valeur du travail accompli:  Les processus qui définissent ce que doit faire chaque personne brident le potentiel caché derrière chacun.

C o u r s « G L - A C O O » E N S I

 Faire interagir les gens au maximum permet d'améliorer

grandement l'efficacité et la qualité du travail fourni.

56

28

CHAPITRE 2: Processus Logiciels

Valeurs de l’agilité

M o d è l e s d e p r o c e s s u s

3. Priorité à la collaboration avec le client par rapport à la négociation de contrats

 Sortir de la guerre client/fournisseur et penser en

équipe qui veut atteindre un but commun pour réussir le projet.

 Le client devient un partenaire qui participe au projet

pour donner régulièrement son feedback.

57

CHAPITRE 2: Processus Logiciels

Valeurs de l’agilité

M o d è l e s d e p r o c e s s u s

4. Priorité à l’acceptation et la réactivité au changement par rapport au suivi d’un plan.

 Planning flexible :

 Le planning est flexible pour accepter les modifications

nécessaires.

 Lorsqu’un plan est défini, l’équipe essaie de s’y tenir et ne fait pas attention à des évènements extérieurs qui peuvent arriver à tout moment (Risque de conflit).

 Pour le client, pouvoir adapter les besoins en cours de

projet est un atout concurrentiel.

58

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

29

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Modèle agiles

 Parmi ces modèles, on trouve :

 SCRUM  XP (eXtreme Programming)  ASD (Adaptative Software Development)  FDD (Feature Driven Development)  DSDM (Dynamic Systems Development Method)  AM (Agile Modeling)  … Ces méthodes sont regroupées par l’Agile Alliance

www.AgileAlliance.org

CHAPITRE 2: Processus Logiciels

Un modèle agile: SCRUM

M o d è l e s d e p r o c e s s u s

 Le coeur de Scrum est un sprint : un bloc de temps d’un mois ou moins durant lequel un incrément du produit est réalisé.

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

59

60

14/09/2017

30

14/09/2017

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Un modèle agile: SCRUM

Daily scrum meeting: Mêlée quotidienne

24 heures

2 – 4 semaines

Backlog du sprint

Backlog du produit

Produit

61

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

SCRUM

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

62

31

14/09/2017

CHAPITRE 2: PROCESSUS LOGICIELS

M O D È L E S D E P R O C E S S U S

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

63

64

32

As a « type of user » I want « some objectives » so that « benefits value »

Sprint backlog

Unité de mesure exprimant l’effort demandé pour effectuer une tâche

Evolution de la quantité de travail restante par rapport au temps sur une période donnée.

CHAPITRE 2: Processus Logiciels

C H A P I T R E 2 : P r o c e s s u s L o g i c i e l s

SCRUM

Planification du sprint (PO+SM+E+I)

 Analyser et évaluer le backlog de produit (analyse)

 Définir le but du sprint

 Décider comment s'y prendre (conception)

 Créer la liste des tâches à partir des éléments du

backlog de produit

 Estimer les tâches en heures

65

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

SCRUM

Mêlée quotidienne (E)  Destinée à permettre à l’équipe de développement de

synchroniser ses activités et planifier les prochaines 24 heures.

 Tous les jours, 15 minutes, même heure, même endroit.

 Trois questions pour chacun:

• Qu’avez-vous fait hier ?

• Qu’allez-vous faire aujourd’hui?

• Quels sont vos problèmes?

66

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

33

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

SCRUM

Revue de sprint (PO+SM+E+I)

 Tous les acteurs échangent sur ce qui a été fait durant

le sprint.

 Inspecter l’incrément du produit et adapter le carnet de

produit si nécessaire.

Pour un sprint d’un mois, cette rencontre est limitée à un bloc de temps de quatre heures.

C o u r s « G L - A C O O » E N S I

67

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

SCRUM

Rétrospective du sprint (PO+SM+E+I)

 Inspecter la manière dont le dernier sprint s'est déroulé en

ce qui concerne les personnes, les relations, les processus et les outils ;

 Identifier et ordonner les éléments majeurs qui se sont bien

déroulés et les améliorations potentielles ;

 Créer un plan pour améliorer les processus de travail de

C o u r s « G L - A C O O » E N S I

l'équipe Scrum

Pour un sprint d’un mois, cette rencontre est limitée à un bloc de de trois heures.

14/09/2017

34

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

SCRUM

Remarque: Taille de l’équipe de développement  Une équipe de développement de taille optimale est

assez petite pour demeurer agile et assez grande pour effectuer du travail significatif.  Moins de 3 membres :

 diminue les interactions et entraîne des pertes

productivité

 Contrainte de compétences

 Plus de 9 membres :

 Trop de coordination  Complexité non gérée par un processus empirique

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

SCRUM: Bilan

Avantages  Règles définies clairement  Souplesse : répondre au changement, modifier le projet

et les livrables à tout moment

 Contrôle quotidien : coût; planning; fonctionnalités; et

qualité.

 Partage de connaissances : améliorer la productivité  Résultat conforme aux attentes

Inconvénients  Grande disponibilité de tous les acteurs  Non adaptée aux grands projets

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

35

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

Les modèles orientés objet

71

CHAPITRE 2: Processus Logiciels

Modèles orientées objet

M o d è l e s d e p r o c e s s u s

 Le développement orienté objet conduit à des architectures logicielles fondées sur les objets (plutôt que sur les fonctions)

 Dans le cadre de développement orienté objet, UML

(Unified Modeling Language) est le standard

 le PU (Processus Unifié) a été proposé afin de

compléter UML avec une méthode

 Méthode générique de développement de logiciels  Générique = pouvant être adaptée à une large

classe de systèmes logiciels.

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

14/09/2017

36

CHAPITRE 2: Processus Logiciels

PU: caractéristiques

M o d è l e s d e p r o c e s s u s

1. PU utilise le langage UML;

2. PU est piloté par les cas d’utilisation;

3. PU est centré sur l’architecture;

4. PU est itératif et incrémental.

5. PU gère les risques

CHAPITRE 2: Processus Logiciels

PU: caractéristiques

M o d è l e s d e p r o c e s s u s

PU est piloté par les cas d’utilisation

 Cas d’utilisation: donne une vision global du

comportement fonctionnel du système

 Le processus de développement est centré sur

l’utilisateur.

 Toutes les activités, de l’analyse des besoins

jusqu’aux tests sont guidés par les cas d’utilisation.

 A partir des cas d’utilisation, les développeurs

créent une série de modèles UML.

14/09/2017

37

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

CHAPITRE 2: Processus Logiciels

PU: caractéristiques P

 Exemple de cas d’utilisation:

M o d è l e s d e p r o c e s s u s

CHAPITRE 2: Processus Logiciels

M o d è l e s d e p r o c e s s u s

PU: caractéristiques

PU est piloté par les cas d’utilisation

14/09/2017

38

C o u r s « G L - A C O O » E N S I

C o u r s « G L - A C O O » E N S I

75

76

CHAPITRE 2: Processus Logiciels

PU: caracté