Les démarches de développement

Slides:



Advertisements
Présentations similaires
Les Systèmes d’Information Financière Atelier conjoint ACBF / Banque Mondiale / AFRITAC de l’Ouest Gérer l’application dans le temps, sur les plans fonctionnel,
Advertisements

Analyse et Programmation Orientées Objets
Le projet HEI 3 – Décembre 2005.
Eléments de Génie Logiciel
Processus d'expression du besoin
La Gestion de la Configuration
Copyright 2008 © Consortium ESUP-Portail ESUP-Days 7, Paris, 3 février 2009 La démarche projet Pascal Aubry.
LA QUALITE LOGICIELLE Plan du cours Le Plan Qualité 1 h ½
Le processus unifié UML est un langage de modélisation et n ’impose pas de démarche de développement Le processus unifié : méthodologie de développement.
Chapitre 7 : démarche de conception, conduite de projet SI
Les démarches de développement
Les démarches de développement
Tests et validation du logiciel
Tests et Validation du logiciel
Rational Unified Process (RUP)
Processus général de la gestion de projet
Cours gestion de projet partie 2
Filière Informatique et Réseaux
S.T.S. S.I.O. 1ère année La gestion de projets
MIAGE MASTER 1 Cours de gestion de projet
Cycle de vie dun logiciel Origine des erreurs La spécification 50% 40% 10% Le design Le codage.
Management de projet Michel Winter Année universitaire:
Réalisé par: COLIN Yann DECAP Clément HAJJI Emna NICOLETTI Anthony
METHODE AGIL Présenté par : GRIOUI Haykel MILADI Hedi CHARFI Habib
Réunion de démarrage Fahmi Hachicha Tél Cotonou, 24 février 2014 Ministère de lEconomie et des Finances République.
Michel Winter – 2008 / 2009 Lévaluation des charges.
Paul Bories Cyril Enrici Bouzidi Gharoual Kevin Royere
Équipe de projet Méthodologie
Les étapes du cycle de développement du génie logiciel
Portée, arrimages et intervenants Évolution des méthodes
Démarche de développement
Genèse du projet. Contexte : Université dAvignon Contexte : Université dAvignon Correspondant Informatique et Liberté (CIL) Correspondant Informatique.
ANALYSE METHODE & OUTILS
Supports de formation au SQ Unifié
Développement d'application rapide GEF492A Automne 2014 [HvV § 3.2.3]
Institut Supérieur des Sciences Appliquées et de Technologie Sousse
Cycle de vie d’un produit et Démarche de Projet
Définitions Gestion Exemple
GESTION DE PROJET
Vérification dans le cycle de vie GEF492A 2014 Référence: [HvV §14.2, 14.9] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et.
Cycles de Vie du Logiciel LFI2 Genie Logiciel/ Gestion de Projets Septembre 2008.
Marché Client Produit Service MOA MOE Expression du besoin Sp é
UML : un peu d’histoire H. Lounis.
© Petko ValtchevUniversité de Montréal Février IFT 2251 Génie Logiciel Conception Hiver 2002 Petko Valtchev.
Introduction au Génie Logiciel
ESTIMATION / CHIFFRAGE
Initiation à la conception des systèmes d'informations
Gestion de projet Cycles de production
Présentation AICHA REVEL INGENIEUR D’ÉTUDE STERIA DEPARTEMENT TRD
IFT 2251 Génie Logiciel Le Processus
ISNET-43 Atelier de génie logiciel Approche fonctionnelle ou objets Concurrence ou complémentarité ? Synthèse.
L’enseignement de spécialité SLAM
OPTIMISATION DE LA PLANIFICATION
G.L modèle en CASCADE Plan Réalisé par : Selmane mohamed lamine
Soutenance Phase 1 Bibliographie et Analyse des besoins
2 Tracks Unified Process
TIJARIATE Méthodes Orientées Objets Unified Process (UP) - Groupe A
Sensibilisation aux projets logiciels
Informatique et Sciences du Numérique
Les concepts d’UML - Le Processus Unifié -
Déroulement et organisation
AMDEC AMDEC : Analyse des modes de défaillances, de leurs effets et leurs criticités Origine: 1950 : USA (FMECA) 1970 : Europe.
Conférence 2TUP Stéphane Barthon 03/12/
Présentation de la méthode Merise
Modèles de cycle de vie et processus de génie
Réunion de cadrage 4 09/03/10.
19 avril Spécification d’un cadre d’ingénierie pour les réseaux d’organisations Laboratoire de recherche : OMSI à l’EMSE.
SIO Gestion de projets, applications SIO Hager Khechine, MBA, PhD. Séance 2 : Méthodes de découpage de projets.
Lancement du projet de refonte du portail eaufrance Groupe de coordination inter bassins 28/01/2014 – Anne Macaire.
Projet logiciel orienté objets M2 Pro OSAE – P.Didelon, J.F.Rabasse.
Transcription de la présentation:

Les démarches de développement

Les phases hors réalisation Projet interne Cadrage Réalisation Production Projet externalisé Les phases hors de la réalisation : Idée : une personne propose une idée de projet à sa hiérarchie. Contenu, délai et budget sont estimés très grossièrement. Cadrage : le cadrage doit permettre d’affiner contenu, délai et budget. Le cahier des charges est généralement rédigé à l’issue de cette phase. Le cahier des charges (et donc l’analyse faite durant le cadrage) doit permettre de fixer l’enveloppe budgétaire, et permettre l’émission d’un appel d’offre (suffisamment de précision pour qu’un prestataire propose une solution voire un forfait). Appel d’offre : le cahier des charges est émis à 1 ou plusieurs prestataires. Chacun retourne après analyse une proposition technique et financière. Le client analyse les offres et en retient une. Réalisation : l’application est développée (cycle de développement) Garantie : le prestataire s’engage à résoudre les problèmes gratuitement (suite à la réalisation, même contrat) suivant une procédure et des délais contractuels Maintenance : Même principe que la garantie, mais nouveau contrat et nouveau financement. Différence entre maintenance et TMA. Ne pas se cristalliser sur la terminologie, mais comprendre les activités à mener. Cadrage Appel d’offre Réalisation Production Garantie Maintenance

Compréhension du problème Découpages standards Code-and-fix Possible si détermination facile des besoins Mise au point avec l’aide de l’utilisateur Une vrai méthode ? Compréhension du problème Implémentation Mise au point Si non satisfaisant Fin

La transformation automatique Découpages standards La transformation automatique Transform model Transformation automatique des spécifications en programme Atelier logiciel (Rational,...) Spécifications Validation Eccueil mythe de la spec. parfaite, complète et non ambiguë. Transformation

Cycle en cascade Waterfall model Hérité du bâtiment Découpages standards Cycle en cascade Spécification Définition des besoins Conception Codage Recette Livraison / installation Validation Intégration Waterfall model Hérité du bâtiment Problème en informatique : effet tunnel Incapacité de l’utilisateur final de valider les étapes intermédiaires Hérité du bâtiment : les fondations, les murs, la toiture... Jalonnement très stricte, avec une validation marquée à chaque étape, sans retour arrière. Effet tunnel : le client utilisateur perd la visibilité sur le projet : étapes techniques, a la différence du bâtiment Une csq de la même problèmatique : le client est incapable de valider les étapes intermédiares.

Modèle en V 1/4 Un standard de fait Années 1980 Découpages standards Modèle en V 1/4 Spécification Définition des besoins Conception architecturale Codage Recette Tests de validation Tests d’intégration Conception détaillée Tests fonctionnels Tests unitaires Un standard de fait Années 1980 Adaptation du modèle en cascade au monde de l’informatique : Mise en évidence du cheminement top-down Standard de fait : Explicitement utilisé ou implicitement (au travers de la terminologie) Cheminement top-down : pas simplement évolution dans le temps : aussi évolution en terme de niveau de détails (a comparer aux étapes du bâtiment)

Modèle en V 4/4 Toujours l’effet tunnel Découpages standards Modèle en V 4/4 visibilité utilisateur Spécification Définition des besoins Conception architecturale Codage Recette Tests de validation Tests d’intégration Conception détaillée Tests fonctionnels Tests unitaires Principe : la validation de chaque étape est couverte par des tests Toujours l’effet tunnel Pas de remise en question des choix de l’étape précédente

Modèle en W 1er V : Orienter l’analyse, Découpages standards Modèle en W 1er V : Orienter l’analyse, dégager des directions pour les spécifications 2ème V : cycle standard Définition des besoins bruts Orientations pour les spécifications Conception de haut niveau Maquettes ou prototypes Vérification des flux logiques

Cycle en V : découpage en modules Découpages standards Cycle en V : découpage en modules Cahier des charges Spécifications générales Spécifications module i Conception générale Spécifications module j Spécifications module j Conception module i Conception module j Conception module j Codage module i Codage module j Codage module j Tests d’intégration Recette

Modèle en spiral Spiral model Chaque révolution = 1 cycle en V Découpages standards Modèle en spiral Spiral model Chaque révolution = 1 cycle en V Expression des besoins Validation Spécifications Test Le développement reprend les différentes étapes du cycle en V. Par l'implémentation de versions successives, le cycle recommence en proposant un produit de plus en plus complet. Chaque cycle peut être contractualisé comme un cycle classique en V Implémentation Conception

Cycle itératif Intérêts Découpages standards Cycle itératif Intérêts Prise en compte des changements du cahier des charges Intégrations successives Dilution des risques Changement de stratégie Meilleure conception Montée en expertise de l’équipe de développement, des utilisateurs Amélioration du processus lui-même Prise en compte des changements du cahier des charges Intégrations successives : effort énorme en cas d’une intégration finale, et découverte trop tardive des problèmes Dilution des risques : les risques majeurs en phase d’intégration Changement de stratégie : ex : sortir le projet plus tôt avec moins de fonctionnalités pour convaincre, pour prendre des places de marché. Meilleure conception : possibilité de découvrir des problèmes de conception et de la remettre en question Montée en expertise de l’équipe de développement Amélioration du processus lui-même

1990 1980 1970 Les grandes approches Méthodes unifiées Méthodes Agiles Découpages standards Les grandes approches 1990 Méthodes unifiées RUP, UP, EUP, 2TUP Méthodes Agiles XP, Crystal, ASD, Scrum, DSDM .. 1980 Rapid Application Development (RAD) 1970 Modèle en cascade Cycle en V, W

La démarche de développement Conclusions Retenons qu’il y .. 2 ... voire... 1,2 approches classiques : La séquence (cascade) La séquence sur plusieurs itérations…. Et des adaptations importantes : Approche itérative Approche incrémentale Et avec ça, on construit une démarche spécifique

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Construction d’un Gantt Elaboration du planning Construction d’un Gantt

Estimation de la charge

La méthode d’évaluation analytique 1/2 Découpage du développement en tâches élémentaires, Rattachement à un ‘type de développement’, Au sein de chaque type, caractérisation de la complexité de la tâche en : Très simple, simple, moyenne, ... , très complexe. Exemple : Tâche : formulaire web de saisie de recherche Type : interface web Complexité : très simple

La méthode d’évaluation analytique 2/2 Conversion directe en jour*homme Pondération des complexités par type de développement à partir d’abaque ou au cas par cas Ajout de charges pour les autres phases en pourcentage de la charge de réalisation, exemple : Spécification : 20% Test d’intégration : 20% Test de recette : 20% Gestion de projet : 20%, ... Simplification : pas de types de développement

Approche analytique : essayons... Mise en œuvre excel (SOGETI)