La planification en génie logiciel GEF492A Automne 2014 [HvV ch. 2]

Présentation au sujet: "La planification en génie logiciel GEF492A Automne 2014 [HvV ch. 2]"— Transcription de la présentation:

1 La planification en génie logiciel GEF492A Automne 2014 [HvV ch. 2]
GEF La planification en génie logiciel Automne 2013 La planification en génie logiciel GEF492A Automne 2014 [HvV ch. 2] Capt Vincent Roberge Collège Militaire Royal du Canada Génie électrique et génie informatique roberge.segfaults.net PPL01-planification.pdf Sylvain P. Leblanc

2 GEF492 - 01 La planification en génie logiciel
Automne 2013 Aperçu Qu’est-ce que le génie Maturité du génie logiciel Planification de projet Contrôle de projet Les aperçus sont là pour aider votre étude Automne 2014 GEF492 Sylvain P. Leblanc

3 Qu’est-ce que le génie? Le génie est l’application d’art, science, connaissances, mathématiques, technologie et d’expérience pratique à la conception d’objet, d’outils ou de processus utiles Wikipedia Plusieurs parle d’une progression Bricoleur Artisan Scientiste Ingénieur Automne 2014 GEF492

4 La profession du génie Le génie au Canada est une profession qui, dans l'intérêt du public, est réglementée par des organismes autonomes qui délivrent les permis d'ingénieur. Ces organismes ont été créés par les 13 gouvernements provinciaux et territoriaux du Canada, par l'entremise de lois contrôlant la pratique du génie. Seuls les ingénieurs titulaires de la désignation ing./PEng. sont autorisés à exercer le génie au Canada. Dispense pour ingénieurs fédéraux Automne 2014 GEF492

5 Les ingénieurs font parfois des erreurs
The original Tacoma Narrows Bridge opened on July 1, 1940, and dramatically collapsed into Puget Sound on November 7 of the same year. The bridge's collapse had a lasting effect on science and engineering. In many physics textbooks the event is presented as an example of elementary forced resonance with the wind providing an external periodic frequency that matched the natural structural frequency, even though its real cause of failure was aeroelastic flutter. Le pont des Tacoma Narrows Automne 2014 GEF492

6 Le génie logiciel Le génie logiciel est l’application d’une approche disciplinée, systématique, et quantifiable au développement, à l’utilisation et à l’entretien de logiciel IEEE Il s’agit donc de l’application des principes d’ingénierie au logiciel Automne 2014 GEF492

7 Maturité du génie logiciel
Conférence de l’OTAN introduit le terme « Software Engineering » en 1968/1969 Motivation: Le développement de logiciel est plus qu’un art, ou qu’un « sac de trucs » On bâtit le logiciel comme on bâtis un pont!! Ce qui signifie qu’on suit un processus de génie; il existe toutefois des grandes différences entre le génie logiciel et les génies matériaux Automne 2014 GEF492

8 Distribution relative des coûts matériel/logiciel
100 Coûts matériel sont une fraction des coûts logiciel Matériel Développement 60 Pourcentage du coût total Logiciel 20 Maintenance 1955 1970 1985 Année Automne 2014 GEF492

9 La planification On doit commencer avec un plan, mais celui-ci n’est rien de plus qu’un point de départ duquel on peut/doit s’adapter Aucun plan d’opérations ne demeure adéquat avec exactitude après avoir rencontré la force principale de l’ennemi. - Helmut von Moltke the Elder Aucun plan ne survit le contact avec l’ennemi. — Dicton commun Automne 2014 GEF492

10 Pourquoi est-ce qu’on fait des plans?
C’est vrai que les projets logiciels échouent parfois de par des facteurs techniques, mais la plupart des échecs sont causés pare des facteurs de gestion Causes typiques pour l’échec d’un projet: estimation de temps trop optimiste on ne prévoit pas assez de temps pour concevoir le projet productivité des programmeurs moins haute que prévue une manque de réalisation du progrès actuel, peut-être a cause de mesures inexactes une manque de connaissance des besoins réels La conception et l’entretien d’un plan est indispensable – le succès n’est pas un hazard Automne 2014 GEF492

11 Un plan de projet définit (1)
ce qu’on va construire un contexte et sommaire du système, et le but principale (de point de vue de l’entreprise) le processus qu’on suivra il faut qu’on choisisse un modèle du cycle de vie cohérent aux objectifs du projet des méthodes ou techniques spéciales et les outils nécessaires la structure organisationnelle les rôles et responsabilités des membres de l’équipe, ainsi que les relations entre l’équipe et les entités externes (y compris le client) Automne 2014 GEF492

12 Un plan de projet définit (2)
les normes, directives et procédures très important pout les projets exécutés par un entrepreneur externe il faut identifier les questions de documentation de façon assez précise les activités de gestion les rôles et responsabilités de l’équipe de gestion y compris les reports de progrès et la gestion des risques les risques l’identification et classification des risques au projet et les stratégies d’atténuation de ceux ci la qualité comment s’assurer de rencontrer les besoins de qualité Automne 2014 GEF492

13 Un plan de projet définit : (3)
les ressources le matériel, les outils, et l’appareillage d'essai le nombre de personnel requis, ainsi que leurs qualifications les lots de travaux la division du travail en morceaux maniable le budget et le programme une allocation des fonds et du temps aux lots de travail les techniques d’estimation et de pistage le gestion des changements les procédures claires pour adresser les changements Automne 2014 GEF492

14 Principes de base Le logiciel est crée de façon itérative* et doit être entretenu on commence par trouver un « sentier » des besoins vagues aux besoins précis on crée un plan conceptuel du produit chaque fois que les besoins devient plus précis, on raffine les estimations et le programme quand les besoins deviennent clairs, on élabore un design détaillé et une stratégie d’exécution et on les incorporent dans le plan le plan fournit l’échafaud duquel on peut négocier pour les ressources et le temps nécessaires Automne 2014 GEF492

15 Il faut se souvenir que les premières estimations de ressource et du programme sont presque toujours fautives On doit réduire l’ampleur du projet ou augmenter le temps disponible ou les ressources allouées on a toujours besoin d’entités avant que celles-ci ne soient disponibles Donc: le plan devient le début d’un processus de négociation entre les désires du clients et les ressources du développeur il faut conclure cette négociation aussitôt que possible Automne 2014 GEF492

16 Les besoins sont maîtres
le plan découle toujours des besoins du client, y compris attributs critiques ce que le système doit faire configuration du système Plateforme, normes, compatibilité l’identification par le client pour qui est-ce qu’on élabore ce système, comment est-ce qu’on les implique mesures du succès coût, programme, performance, qualité, grandeur validation et réception les tests de réception, critère d’acceptation, garanties soutien les besoins de soutient après achèvement Automne 2014 GEF492

17 Les variables de contrôle du projet
l’ampleur ressources ? temps la qualité* * La qualité n’est pas une bonne variable de contrôle. Pourquoi pas? Automne 2014 GEF492

18 Les paradoxes du contrôle
si on ajoute des programmeurs au projet, la productivité va presque certainement diminuer “… More fire requires more gasoline, and thus begins a regenerative cycle which ends in disaster” Fred Brooks habituellement, l’insistance sur la haute qualité aide à réduire le temps requis pour compléter si on a plus de temps pour le projet, on crée parfois un système moins utile parce qu’on a besoin des réactions du client Automne 2014 GEF492

19 Resources supplémentaires
Kent Beck. eXtreme Programming eXlained - Embrace Change, Chapter 4. Addison Wesley, ISBN Frederick P. Brooks. The Mythical Man-Month: Essays on Software Engineering. 20th Anniversary Edition. Addison Wesley, ISBN Automne 2014 GEF492

20 Les modèles du processus et le modèle «Waterfall»
GEF La planification en génie logiciel Automne 2013 Prochaine séance: Les modèles du processus et le modèle «Waterfall» Automne 2014 GEF492 Sylvain P. Leblanc