GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

Transcription

1 GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 7ÈME PARTIE GESTION DE PROJETS (PROJECT MANAGEMENT) Faculté des Sciences et Techniques

2 Plan de cette partie de cours 2 Gestion des risques Gestion des ressources humaines Travail d équipe

3 Gestion de projets logiciels 3 Concerne les activités mises en oeuvre pour que le logiciel soit livré à temps et selon le planning, en accord avec les exigences des organisations développant le logiciel. Nécessaire car le développement d un logiciel est toujours sujet à des contraintes de budget et d organisation mises en place par l organisation développant le logiciel

4 Critères de succès 4 Livrer le logiciel au client à la date fixée. Respecter les coûts. Livrer un logiciel qui respecte les attentes du client. Maintenir une équipe de développement travaillant dans la bonne humeur et possédant une bonne productivité.

5 Spécificités de la gestion de projets logiciels 5 Le produit n est pas quelque chose de tangible. Un logiciel ne peut pas être observé ou touché. Les chefs de projets logiciels ne peuvent pas voir les progrès en observant simplement l artefact qui est en train d être construit. De nombreux projets logiciels sont des projets uniques Les grands projets logiciels sont en général différents les uns des autres. Même les managers très expérimentés peuvent avoir des difficultés à anticiper les problèmes. Les processus logiciels sont variables et spécifiques à chaque organisation Il n est toujours pas possible de prédire de façon fiable quand un processus logiciel particulier risque de conduire à des problèmes de développement.

6 Les activités de la gestion de projets 6 Planification du projet Les managers sont responsables de la planification, de l estimation et de l organisation du projet ainsi que de l affectation des tâches aux personnes. Compte Rendu Les managers sont en général responsables des comptes rendus aux clients et aux managers de la société développant le logiciel Gestion des risques Les managers doivent estimer les risques pouvant affecter le projet, mesurer ces risques et décider d actions lorque des problèmes surviennent

7 Les activités de la gestion de projets 7 Gestion des ressources humaines Les managers doivent choisir les personnes de leur équipe et déterminer les façons de travailler les plus efficaces Rédaction de la proposition La première étape d un projet logiciel peut impliquer la rédaction d une proposition pour remporter un contrat. La proposition décrit les objectifs du projet et comment il sera mené à bien.

8 Gestion des risques 8 La gestion des risques consiste à identifier les risques et mettre au point des plans pour minimiser leurs effets sur le projet. Un risque correspond à une probabilité qu une circonstance indésirable survienne Les risques projet affectent le planning ou les ressources Les risques produit affectent la qualité ou la performance du produit en cours de développement Les risques financiers affectent l organisation développant le logiciel

9 Exemples classiques de risques projet, produit et business 9 Risque Affecte Description Turnover de l équipe Projet Des membres expérimentés de l équipe vont quitter le projet avant sa fin. Changement dans le management Projet Il y aura des changements dans le management organisationel. Hardware indisponible Projet Du matériel essentiel au projet ne sera pas disponible dans les délais. Changement dans les exigences Délais dans les specifications Projet et produit Projet et produit Il y aura un nombre plus important que prévu de changements dans les exigences. Les spécifications des principales interfaces ne seront pas disponibles selon le calendrier. Taille sous estimée Projet et produit La taille du système a été sous estimée. Outil CASE non performant Changements technologiques Produit Business Les outils de développement logiciel supportant le projet n ont pas les performances attendues. La technologie sous jacente sur laquelle le système est construit est dépassée par une nouvelle technologie. Compétition produit Business Un produit concurrent est mis sur le marché Chapter 22 Project management avant que le système soit terminé.

10 Processus de gestion des risques 10 Identification des risques On identifie les risques projet, produit et business Analyse des risques On estime la probabilité et les conséquences de ces risques Planification des risques On construit des plans pour éviter/minimiser les effets des risques Contrôle des risques On contrôle les risques tout le long du projet

11 Processus de gestion des risques 11 Identification des risques Analyse des risques Planification des risques Contrôle des risques Liste de risques potentiels Liste de risques prioritisés Plans d évitement limitation des risques Evaluation des risques

12 Identification des risques 12 Peut être une activité d équipe ou basé sur l experience individuelle du manager de projet Une liste des risques usuels peut être utilisée pour identifier les risques dans un projet Risques technologiques Risques humains Risques organisationels Risques dans les exigences Risque dans les estimations

13 Exemples de différents types de risques 13 Type de risques Technologiques Humains Organisationels Risques possibles La base de données utilisée par le système ne peut pas traiter autant de transaction par seconde que ce qui était attendu (1) Les composants logiciels réutilisables contiennent des défauts et ne peuvent donc pas être réutilisés comme prévu (2) Il n est pas possible de recruter le personnel possédant les compétences requises (3) Le personnel clé est malade et indisponible à des moments critiques (4) La formation nécessaire n est pas disponible (5) L organisation est restructurée de telle façon que différents managers sont responsable du projet (6) Des problèmes financiers au sein de l organisation obligent à des réductions de budget pour le projet (7) Outils Le code généré par des outils de génération de code est inéfficace (8) Les outils logiciels ne peuvent pas travailler ensemble de manière intégrée (9) Exigences Des changements dans les exigences sont proposés et nécessitent un nouveau travail majeur de conception (10) Le client ne comprend pas l impact des changements dans les exigences (11) Estimation Le temps nécessaire au développement est sous estimé (12) Le taux de réparation des défauts est sous estimé (13) La taille du logiciel est sous estimé (14)

14 Analyse des risques 14 Evaluation de la probabilité et de l importance de chaque risque Probabilité très faible Faible Modérée Élevée Très élevée Importance des conséquences Catastrophique Sérieuse Tolérable Insignifiante

15 Types de risques et exemples 15 Risque Probabilité Conséquences Des problèmes financiers au sein de l organisation obligent à des réductions de budget pour le projet (7) Il n est pas possible de recruter le personnel possédant les compétences requises (3) Le personnel clé est malade et indisponible à des moments critiques (4) Les composants logiciels réutilisables contiennent des défauts et ne peuvent donc pas être réutilisés comme prévu (2) Des changements dans les exigences sont proposés et nécessitent un nouveau travail majeur de conception (10) L organisation est restructurée de telle façon que différents managers sont responsables du projet (6) La base de données utilisée par le système ne peut pas traiter autant de transaction par seconde que ce qui était attendu (1) Faible Elevée Modérée Modérée Modérée Elevée Modérée Catastrophiques Catastrophiques Sérieuses Sérieuses Sérieuses Sérieuses Sérieuses

16 Types de risques et exemples 16 Risque Probabilité Conséquences Le temps nécessaire au développement est sous estimé (12) Les outils logiciels ne peuvent pas travailler ensemble de manière intégrée (9) Le client ne comprend pas l impact des changements dans les exigences (11) Elevée Elevée Modérée Sérieuses Tolérables Tolérables La formation nécessaire n est pas disponible (5) Modérée Tolérables Le taux de réparation des défauts est sous estimé (13) Modérée Tolérables La taille du logiciel est sous estimé (14) Elevée Tolérables Le code généré par des outils de génération de code et inéfficace (8) Modérée Insignifiantes

17 Planification des risques 17 Considérer chaque risque et développer une stratégie pour gérer ce risque Stratégies d évitemment On cherche à réduire la probabilité que le risque se produise Stratégies de minimisation L impact du risque sur le projet ou le produit est réduite Plans de traitement Si le risque se produit les plans prévus doivent être capable de traiter ce risque

18 Strategies d aide à la gestion des risques 18 Risque Problèmes financiers dans l organisation Problèmes de recrutement Maladie Composants défectueux Changements dans les exigences Strategie Préparer un document à destination des managers séniors montrant comment le projet va avoir une contribution très importante aux objectifs du business et présentant les raisons pour lesquelles des coupes budgétaires dans le budget du projet n auraient pas les conséquence budgétaire positive attendue Alerter le client des difficultés potentielles et de la possibilité d un délai ; Etudier la possibilité d acheter des composants intégrables Réorganiser l équipe de telle façon qu il y ait plus de recoupement du travail et que les personnes comprennent le travail des autres Remplacer les composants défectueux potentiels par des composants achetés de meilleur fiabilité Utiliser les informations de traçabilité pour estimer l impact des changements ; maximiser le masquage de l information durant Chapter la conception 22 Project management

19 Strategies d aide à la gestion des risques 19 Risque Restructuration organisationelle Performance de la base de données Temps de développement sous estimé Strategie Préparer un document à destination des managers séniors montrant comment le projet va avoir une contribution très importante aux objectifs du business Etudier la possibilité d acquérir un SGBD plus performant Etudier la possibilité d acquérir des composants ; étudier la possibilité d utiliser un générateur de programme

20 Contrôle des risques 20 Estimer régulièrement chaque risque identifié pour décider s il devient plus ou moins probable Estimer si les effets du risque ont changé Chaque risque clé devrait être discuté lors de meetings d avancement

21 Indicateurs de risque 21 Type de risque Technologique Indicateurs potentiels Livraison tardive du matériel ou du support logiciel ; nombreuses remontées de problèmes techniques Humain Equipe démoralisée ; Faible lien social entre les membres de l équipe ; fort turnover au sein de l équipe Organisationnel Outils Exigences Estimation Nombreux ragots au sein de l organisation ; manque d action de la part du management senior Les membres de l équipe rechignent à utiliser des outils ; plaintes à propos d outils CASE ; demande pour des ordis plus puissants Nombreuses requêtes de changement dans les exigences ; plaintes de clients Echec à respecter l agenda prévu ; échec à produire des rapports clairs de défauts

22 Gestion des ressources humaines Les personnes constituent l atout le plus important d une organisation Les tâches d un manager sont essentiellement orientées sur les personnes. Sans compréhension des personnes, le management est un échec Mauvais management des personnes échec du projet

23 Facteurs du management des personnes Consistence Les membres de l équipe devraient tous être traités de façon comparable sans favoritisme ou discrimination Respect Les membres de l équipe ont différentes compétences et ces différences devraient être respectées Implication Impliquer tous les membres de l équipe et s assurer que tous les points de vue sont pris en compte Honnêteté Le manager devrait toujours être sincère sur ce qui va bien et ce qui va mal dans un projet

24 Motiver les personnes 24 Un des rôles importants du manager est de motiver les personnes à travailler sur le projet Motivation = organiser le travail et l environnement de travail pour encourager les personnes à travailler efficacement Si les personnes ne sont pas motivées, elles ne seront pas efficaces dans le travail qu elles doivent réaliser. Elles vont travailler plus lentement, vont faire plus d erreurs et ne vont pas contribuer aux objectifs de l équipe Motivation = problème complexe Différents types de motivations basées sur Les besoins de base (e.g. nourriture, sommeil, etc.) Besoins personnels (e.g. respect, estime de soi, etc) Besoins sociaux (e.g. être accepté d un groupe, etc)

25 25 Hiérarchie des besoins humains

26 Satisfaction des besoins 26 Dans les groupes de développement logiciel, le besoins physiologiques et de sécurité ne sont pas un problème Besoins d appartenance Procurer des lieux communs Permettre la communication informelle (par exemple via des réseaux sociaux) Besoins d estime Reconnaissance des réalisations Récompenses appropriées Besoins de réalisation Apprentissage les gens ont soif d apprendre plus Responsabilité

27 Types de personnalités 27 La hiérarchie des besoins est certainement trop simplificatrice de la motivation La motivation doit aussi prendre en compte différents types de personnalités Orientée tâche Centrée sur soi Ouverte à l interaction

28 Types de personnalités 28 Orientée tâche La motivation pour faire un travail est le travail lui même Centrée sur soi Le travail est un moyen d assouvir des objectifs individuels (être riche, voyager, etc) Ouverte à l interaction La principale motivation est la présence d autres collègues

29 Equilibre des motivations 29 Les motivations sont constituées d éléments de chaque classe L équilibre peut varier selon les circonstances personnelles et les événements extérieurs Toutefois, les personnes ne sont pas seulement motivées par des facteurs personnels mais aussi par le fait de participer à un groupe, une culture Les personnes vont au travail parce qu elles sont motivées par les personnes avec qui elles travaillent

30 Travail d équipe 30 Le développement logiciel est une activité de groupe Le planning de développement pour la plupart des projets non triviaux est tel qu il ne peut pas être réalisé par une seule personne travaillant seule Un bon groupe est un groupe cohérent où reigne un esprit d équipe. Les personnes sont motivées par le succès du groupe autant que par leurs objectifs personnels Les interactions dans un groupe sont un facteur déterminant de la performance de celui-ci La flexibilité dans la composition d un groupe a ses limites Les managers doivent faire de leur mieux avec le personnel disponible

31 Cohésion du groupe Dans un groupe cohérent les membres considèrent le groupe comme plus important que ses individus Avantages Des standards de qualité peuvent être développés par les membres du groupe Les membres de l équipe peuvent apprendre les uns des autres. Les inhibitions causées par l ignorance sont réduites La connaissance est partagée. Une continuité peut être assurée si un membre du groupe s en va L amélioration permanente est encouragée. Les membres du groupe travaillent collectivement pour fournir des résultats de grande qualité et résoudre les problèmes sans se préoccuper de qui a originellement créé le programme

32 Une équipe efficace 32 Les personnes dans le groupe Besoin d un mélange de personnes vu que le développement de logiciels met en jeu des qualités très variées L organisation du groupe Un groupe doit être organisé de telle façon que les individus puissent contribuer au mieux de leurs compétences et que les tâches soient réalisées comme prévu Communication entre technique et management Une bonne communication entre les membres du groupe et entre les ingénieurs logiciels et les parties prenantes est essentielle

33 Sélectionner les membres du groupe 33 Un des jobs du manager est de créer un groupe cohérent et d organiser celui-ci pour que ses membres puissent travailler ensemble de façon efficace créer un groupe équilibré entre compétences techniques et personnalités

34 Créer l équipe 34 Pas forcément possible de recruter les personnes idéales Le budget ne permet pas de recruter des personnes à haut salaire Le personnel avec les compétences nécessaires peut ne pas être disponible Une organisation peut vouloir développer des compétences de certains employés sur certains domaines Les managers doivent travailler avec de telles contraintes, notamment lorsqu il y a des carences en personnel qualifié

35 Composition du groupe 35 Un groupe composé de gens partageant les même motivations peut être problématique Orienté tâche chacun veut développer de son côté Centré sur soi chacun veut être le chef Ouvert aux échanges trop de bavardage, pas assez de travail Un groupe efficace doit être équilibré entre tous les types de personnalités Cela peut être difficile car les informaticiens sont souvent orientés tâches Les personnes ouvertes aux échanges sont importantes car elles sont bien placées pour détecter les tensions lorsqu elles apparaissent

36 Organisation du groupe 36 La façon dont le groupe est organisé affecte les décisions prisent par le groupe, la façon dont l information est échangée, les interaction entre l équipe de développement et les parties prenantes Questions clés Le projet doit-il être managé par le leader technique du groupe? Qui sera chargé de prendre les decisions techniques critiques et comment seront elles prises? Comment vont être gérées les interactions avec les parties prenantes, les managers? Comment le groupe peut-il intégrer des personnes travaillant à distance? Comment la connaissance peut-elle être partagée au sein du groupe?

37 Organisation du groupe 37 Petits groupes organisation informelle sans structure rigide Grands projets structure plus hiérarchique. Chaque groupe est responsable d un sous projet Développement agile groupe informel (les structures formelles inhibent les échanges)

38 Groupes informels 38 Le groupe agit ensemble et parvient à un consensus lorsque des décisions affectant le système doivent être prises Le chef de projet sert d interface externe mais n a pas de tâche spécifique Le travail est discuté par le groupe dans son ensemble et les tâches sont distribuées selon les capacités et l expérience de chacun Succès si membres expérimentés et compétents

39 Communication de groupe 39 Une bonne communication est essentielle à l efficacité d un groupe Des informations doivent notamment être échangées sur le status du travail, les décisions de conception, les changements Une bonne communication renforce la cohésion du groupe car il promeut la compréhension

40 Communication de groupe 40 Taille du groupe Plus le groupe est large, plus la communication est difficile Structure du groupe La communication est meilleure dans les groupes informels que dans les groupes avec une structure hiérachique Composition du groupe La communication est meilleure lorsque différents types de personnalités sont présentes et lorsque le groupe est mixte plutôt que unisexe L environnement physique Un bon environnement de travail peut favoriser la communication

41 41 FIN DE LA 7 ème PARTIE