cycle de vie par prototypage

1. ModuleGestion de ProjetInformatique
AAMMOUSouhaib
2015/2016
Université Abdelmalek Essaâdi
École Normale Supérieure-Tétouan
Département d’Informatique et Gestion
Filière LP Logiciels et Développement Web

2.  Faiblesses du modèle chute d'eau
 Prototypage pour besoins
 Prototypage pour conception
 Prototypage évolutionnaire
2

3. 3
L’identification
des besoins du
système
L’identification
des besoins du
logiciel
L’analyse
La conception
Le testage
Le codage
La
maintenance

4.  supposition inhérente: il est possible de trouver tous les
besoins et de créer une bonne conception dès le premier
essai
4
 vrai pour quelques projets
 pour la plupart des projets, il est très difficile de comprendre
tous les besoins avant de faire la conception ou la réalisation
 les premières conceptions sont presque toujours non optimales
 lorsqu’il faut revisiter des phases déjà complétées, il faut
lutter contre beaucoup d’inertie administrative
 ça réduit le «génie récursif»
 il ’est très difficile de faire des ajustements de parcourt si les
décisions prise tôt dans le processus sont inopportunes

5.  In most projects, the first system built is barely usable. It
may be to slow, too big, awkward in use or all three.There
is no alternative but to start again, smarting but smarter,
and build a redesigned version in which these problems
are solved… When a new system concept or new
technology is used, one has to build a system to throw
away, for even the best planning is not so omniscient as to
get it right the first time.The management question,
therefore, is not whether to build a pilot system and throw
it away.You will do that.The only question is whether to
plan in advance to build a throwaway, or to promise to
deliver the throwaway to customers…
— Fred Brooks,The MythicalMan-month
5

6.  le problème
 le client précise les objectifs généraux mais n’est pas capable
d’identifier les besoins détaillés des entrées, du traitement, ou des
sorties
 unesolution:
collection des
besoins du
client
réalisation
du prototype
évaluation du
prototype par
le client
amélioration
du prototype
conception
rapide
6

7. L’identification
des besoins du
système
L’identification
des besoins du
logiciel
L’analyse
La conception
But: le prototypage des
besoins lors de l’analyse
aide à réduire le risque de
faire une conception basée
sur des besoins incorrects
ou incomplets.
Gather
requireme
nts from
customer
Build
prototype
Customer
evaluates
prototype
Refine
prototype
Quick
design
7

8.  le client voit un ‘’système qui fonctionne, et ne
réalise pas que le système
8
 est probablement difficile à maintenir
 est presque certainement de mauvaisequalité
 et le client exige qu’on ‘’répare le prototype’’
et qu’on le livre
 quelques solutions
 assurez vous que le client comprend pourquoi on crée
une prototype et le processus deprototypage
 utilise des technologies (matériel, système
d’exploitation, langage de programmation, etc.) qui
ne conviennent clairement pas au produit final

9.  le problème
 quelques aspects de la conception ne sont pas très bien compris ce qui
les rends très risqués
 unesolution:
identification
des critères
essentiels de
la conception
réalisation
du prototype
évaluation par
rapport aux
critères
amélioration
du prototype
conception
rapide
9

10. L’identification
des besoins du
système
L’identification
des besoins du
logiciel
L’analyse
La conception
Le codage
Identify
critical
design
criteria
Build
prototype
Review
critical
design
criteria
Refine
prototype
Quick
design
But: on crée et raffine les
prototypes de conception
jusqu’à ce qu’ils répondent
aux critères essentiels. Ceci
réduit le risque que la
conception est insuffisante
ou qu’elle est inadéquate.
10

11.  pour réaliser un prototype rapidement, les
programmeurs utilise des raccourcis
11
 les langages de programmation, les algorithmes, les bases
de données, les trousses à outils d’interface utilisateurs,
etc. qui sont inopportunes pour le systèmefinal
 et ils oublie que ces choix entait des compromiset
les réutilisent dans le systèmefinal
 quelquessolutions
 documentez les compromises de conception quandceux-
ci sontchoisis
 insistez sur une validation totale du conception finale,
portant attention particulière aux restants des prototypes
dans la conceptionfinale

12.  Pour quelques logiciels, une prototype peut être suffisant
pour les besoins du client. Ces logiciels sont caractériséspar:
12
 un risque technique assez bas
 le fait qu’on en a besoin immédiatement
 qu’on peut impliquer l’utilisateur très intimement
 qu’on a un système de développement
▪ dans lequel les programmeurs peuvent travailler assez vite pour soutenir le
prototypagerapide
▪ mais qui est en même temps assez petit, efficace, et robuste pour être
déployer
 Souvent on peut utiliser les langages de quatrième
génération (4GL), les composants de disponibilité immédiat,
ou les cadres d’applications (e.g., SAP, Peoplesoft)

13. 13
Collection des
besoins du
client
réalisation
du prototype
Évaluation du
prototype par
le client
amélioration
du prototype
Conception
rapide
Exploitation et
maintenance
Extraction de la
conception
Ajustement au
système

14.  le processus ne possède pas de phase de conception
exhaustif, le système peut donc manquer d’intégrité
conceptuelle
14
 il faut que les développeurs soient conscients de la
nécessité pour intégrité conceptuelle
 clarifiez ou re-factorisez la conception pendant la phase
d’extraction de la conception
 il peut être impossible d’ajuster la performance du
système une fois que celui-ci estcomplété
 l’administration sera tenté de sauter les phases
d’extraction de la conception et d’ajustement
 sans un fort contrôle de gestion, il est possible d’avoir
des itérations interminable

15. Barry Boehm a dit:
15
 Il faut faire toutes ces étapes de toute façon
 probablement vrai pour tous systèmes sauf les
plus petits
 Les mêmes étapes en ordredifférent
coûteraient plus chères
 vrai ou faux?
 pourquoi?

16. Besoin Conception Codage Tests
d’unité
Test
de réception
En
service
200
100
50
20
10
5
2
1
aux points différents dans le cycle de vie
16
projets plus grands
projets plus petits
Supposition
inhérent:
Le processus
utilisé était le
Chute-d’eau!

17.  La caractéristique clé des démarches
prototypage est le développement rapidede
modèles simples du système pour
17
 obtenir les réactions immédiates des clientset
clarifier les besoins,ou
 augmenter le niveau de confiance au sujet des aspects
de conception qui ne sont pas bien compris
 La question clé pour le prototypage efficace est:
 Avec quoi est-ce qu’on commence-t-on?