IFT 2251 Génie Logiciel Le Processus Hiver 2002 Petko Valtchev

Sommaire Le processus de production Concepts de base Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés

Développement de Prototypes CLIENT Connaissances du domaine Jargon technique Document des besoins Indécis, opinion variable Besoins ambigus, incomplets Connaissances en logiciel Langages, notations INGENIEUR DU LOGICIEL Incomplet Imprécis Spécifications ésotériques

Modèle par Prototypage Démarche : Pour corriger les spécifications du logiciel au fur et à mesure, construction d’un prototype (maquette). Écouter le client Consulter/ réviser la maquette Faire tester la maquette par le client Une ou plusieurs itérations…

Les Prototypes Deux manières de construire des prototypes: Approche classique «prototypage jetable » : Réalisation rapide d’un prototype dès le début du cycle de vie. Le prototype sert alors de référence pour la définition et la validation des spécifications, puis il est « jeté ». Le système logiciel final ne contient pas d’éléments du prototype. Approche évolutive «prototypage incrémental» : Réalisation dès le début du cycle de vie d’un premier prototype (p1). Ajouts progressif de fonctionnalités supplémentaires (raffinements: p2,p3,…) jusqu’à l’obtention du prototype final pn(pn = système visé).

Le Modèle par Prototypage Bilan  Le client a tendance à vouloir faire du simple prototype son produit final. Il ignore que souvent la façade cache une conception très approximative, voire inexistante. Les choix des développeurs pris lors du prototypage, et donc sous fortes contraintes temporelles, ont des fortes chances de devenir de choix définitifs. On oublie que ces choix n’étaient peut-être pas les meilleurs du point de vue de la qualité. 

Sommaire Le processus de production Concepts de base Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés

Rapid Application Development Cycle de développement très court = 60 à 90 jours. Adaptation « haute vitesse » du modèle en cascade. Conception à base de composants. Pré-conditions essentielles: besoins logiciels bien saisis, portée du projet bien définie, projet facilement « modularisable ».

Le Modèle RAD Cinq grandes phases : Modélisation des fonctions d’affaires (business functions): Définition des fonctions du système (en termes d’entrées - sorties) et du flot des informations à être manipulées et transformées. Modélisation des données: Définition des structures de données qui vont accueillir les informations manipulées. Modélisation des processus: Définition des processus qui traitent les informations. Génération de l’application: Construction de l’application à partir des modèles produits auparavant. Utilisation d’outils de 4e génération (ex. CASE) pour la généation. Test et livraison de l’application.

Schéma RAD 60 - 90 jours équipe #1 équipe #3 équipe #2 modéliser b u s i n e m o d l g a t p r c & v business modeling data process application generation test & turnover modéliser les fonctions d’affaires modéliser les données modéliser les processus générer l’application Rapid Application Development tester et livrer 60 - 90 jours

Le Modèle RAD Bilan     Nécessite des ressources humaines importantes: Afin de pouvoir composer le nombre suffisant d’équipes. Exige l’engagement constant du client sous péril de faire échouer le projet. Supporte mal des niveaux de risque élevés: Le modèle RAD n’est pas approprié lorsque des facteurs de risque importants sont présents car ceux-ci peuvent provoquer de retards non-négligeables dans le travail d’une des équipes. Ex. utilisation de nouvelles technologies Portée limitée: Le modèle RAD ne se prête pas au développement de certains types de logiciel   

Sommaire Le processus de production Concepts de base Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèle incrémental Modèle en spirale Modèles avancés

Les Modèles Évolutifs CONSTAT Au sein des modèles vus précédemment: Le système est divisé en composants séparés qui sont développés pour être intégrés à la fin (juste avant les tests et la livraison). CONSTAT Afin de permettre un retour de la part du client (usager) plus tôt dans le processus global: De versions successives du système sont livrées, avec chaque prochaine version possédant des fonctionnalités de plus en plus complètes vis à vis des besoins du client. Un processus global itératif est utilisé permettant de passer plusieurs fois par les différentes phases du développement. Ex. Modèle par «prototypage incrémental» - une approche évolutive Modèle incrémental Modèle en spirale

… Le Modèle Incrémental Modèles par incrément: le système est séparé en incréments qui sont constitués d’un ensemble de composants, chaque incrément développé selon un modèle de processus complet: souvent un modèle en cascade, à la fin de leur cycle de vie (indépendante) des incréments viennent s'intégrer, dans l’ordre, à un noyau développé au préalable (le plus souvent, l’incrément 1) version 1 (noyau) version 2 version finale Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents. Les noyau, les incréments ainsi que leurs interactions doivent donc être faites globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement. i2 i1 i3 i1 i2 i1 … i4

Schéma Incrémental livraison du 1er incrément livraison du incrément 1 (noyau) analyse concept. livraison du 1er incrément code test a n l y s i d e g c o t livraison du 2nd incrément incrément 2 a n l y s i d e g c o t livraison du 3eme incrément incrément 3 a n l y s i d e g c o t incrément 4 livraison du 4eme incrément temps

Le Modèle Incrémental, Bilan Avantages chaque développement est en soi moins complexe, l’intégration des incréments se fait de manière progressive, possibilité (et non obligation!) d’une livraison et de mise en service après le développement de chaque incrément, permet une meilleure gestion de l’ensemble des ressources allouées au projet: du temps réduit par rapport au modèle en cascade du coût en effort humain réduit par rapport au RAD: recouvrement entre processus pour les incréments, mis pas de recouvrement entre phases. Risques devoir remettre en cause le noyau ou les incréments précédents, une tâche ardue, ne pas pouvoir intégrer de nouveaux incréments. Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents. Les noyau, les incréments ainsi que leurs interactions doivent donc être faites globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.

Sommaire Le processus de production Concepts de base Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèle incrémental Modèle en spirale Modèles avancés

Le Modèle en Spirale CONSTAT De facteurs comme l’évolution des besoins ou leur remise en cause après la livraison, lesquels entraînent un passage supplémentaire par toutes les phases du cycle de vie, ne sont pas reflétés par les modèles vus précédemment. CONSTAT L’inévitable remise en cause des résultats d’un processus partiel est explicitée sous forme d’une spirale dans le modèle du même nom. Projet global, divisé en un ensemble de sous-projets réalisés en séquence. Sous-projet = un circuit de la spirale de développement (1 ou + tours). Chaque tour de la spirale traverse six régions d’activités. Région d’activité = ensemble de tâches spécifiques à réaliser. Chaque tour de la spirale doit produire ses propres résultats: un document de spécification, un prototype initial, une version améliorée du prototype, etc.

Le Modèle en Spirale, Schéma Planification Analyse des risques Discussion avec le Client Évaluation par le Client Ingénierie Construction & Livraison Les itérations sont rendues explicites!

Le Modèle Incrémental, Bilan Avantages Combine les avantages des modèle en cascade, par prototypage et incrémental. De façon générale, le modèle est réaliste et bien adapté pour le développement de systèmes de taille large. Risques L’analyse des risques étant, elle aussi, « évolutive », cela risque d’inquiéter le client. Modèle moins connu que les modèles en cascade et par prototypage. Moins de recul, donc difficile d’en évaluer l’efficacité. Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus. Dans les modèles par incrément un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents. Les noyau, les incréments ainsi que leurs interactions doivent donc être faites globalement, au début du projet. Les incréments doivent être aussi indépendants que possibles, fonctionnellement mais aussi sur le plan du calendrier du développement.

Sommaire Le processus de production Concepts de base Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés Modèle de développement par composants Modèles centrés sur des méthodes formelles

Le Modèle par Composants Processus de développement similaire à celui en spirale mais dans lequel l’activité d’ingénierie a une forme particulière. Ingénierie = conception de l’application à partir de composants logiciels prêts à l’emploi (disponibles sous forme de librairies commerciales) Identification des composants candidats. Chercher composants dans les librairies. Si disponible, extraire les composants. Sinon, les construire soi-même et les ajouter à la librairie. Intégrer les composants à la nième version du système. Certains Ateliers de génie logiciel offrent l’environnement nécessaire pour ce type de processus.

Sommaire Le processus de production Concepts de base Nature du processus et phases Modèles de processus Modèle en cascade Modèle par prototypage « Rapid Application Development » Modèles évolutifs Modèles avancés Modèle de développement par composants Modèles centrés sur des méthodes formelles

Le Modèle « Méthodes Formelles » Notations mathématiques et techniques d’analyse rigoureuses pour la spécification, la conception et la vérification de systèmes informatiques. Plusieurs outils CASE disponibles pour les principales méthodes. Ex. VDM, B, Z, CTL, Lotos, etc. Avantages = Détection précise d’ambiguïtés et d’erreurs, de problèmes de complétude et de cohérence. Inconvénients: Coûteux en temps, expertise requise, moyen inadéquat pour communiquer avec le client.