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)