Processus 1 Flashcards
Pourquoi un processus logiciel permet de gérer la complexité d’un projet de développement?
- Structuration des activités : Un processus définit des étapes claires (analyse, conception, implémentation, tests, déploiement) qui permettent de décomposer un projet complexe en tâches plus petites et gérables.
- Qualité du logiciel : Les processus incluent des pratiques comme les revues de code, les tests automatisés et la gestion des exigences, ce qui améliore la qualité du produit final.
- Respect des délais et des coûts : Un processus bien défini permet de planifier les ressources, d’estimer les délais et de suivre l’avancement du projet.
- Collaboration efficace : Un processus facilite la communication entre les membres de l’équipe et clarifie les rôles et responsabilités de chacun.
- Fournit des guides et des pratiques
- Satisfaire certaines normes
- Va faciliter la planification
Connaître les étapes de la construction d’une équipe
- La formation: chacun a sa propre technique de travail
- Les conflits: divergence et lutte de pouvoir
- La normalisation: La confiance s’installe et les consensus apparaissent
La performance: l’équipe a une identité
Connaître le concept d’équipe maillée et ses avantages (le rôle du leadership, les ingrédients d’une équipe maillée)
Une équipe maillée a une forte cohésion, un objectif clair et une tâche explicite. Ses avantages sont le partage de connaissance et l’amélioration continuelle. Le rôle de leadership est la cohérence dans le traitement de ses coéquipiers, le respect, l’inclusion et l’honnêteté
Connaître la loi de Conway
La loi de Conway stipule que la structure d’un système logiciel reflète la structure de communication de l’organisation qui l’a conçu
Donc pour obtenir une architecture souhaitée, il faut organiser les équipes en conséquence
Savoir la définition de cycle de vie en développement logiciel et des concepts rattachés (phase, jalon).
Le cycle de vie en développement logiciel décrit les étapes par lesquelles passe un projet logiciel, de sa conception à sa livraison et sa maintenance. Il structure le processus de développement en phases distinctes, chacune ayant des objectifs spécifiques.
Phase : Une étape du cycle de vie qui regroupe des activités similaires. Par exemple, les phases classiques incluent la conception, l’implémentation, les tests et le déploiement.
Jalon : Un point clé dans le cycle de vie qui marque la fin d’une phase ou la réalisation d’un objectif important. Les jalons servent à évaluer l’avancement du projet.
Cycle de vie en cascade
○ Définition: un modèle linéaire et séquentiel ou chaque phase doit être complétée avant de passer à la suivante
○ Caractéristiques : Rigide, bien documenté, peu flexible aux changements.
○ Avantages : Clair et facile à comprendre, idéal pour les projets aux exigences stables.
○ Inconvénients : Difficile de revenir en arrière, peu adapté aux projets complexes ou changeants.
○ Projets appropriés : Projets avec des exigences bien définies et peu susceptibles de changer (exemple : systèmes critiques comme les logiciels médicaux).
Cycle de vie incrémental
○ Définition : Le logiciel est développé par incréments, chaque incrément ajoutant de nouvelles fonctionnalités.
○ Caractéristiques : produit fractionné en ensemble de fonctionnalités, itération de production d’un produit fonctionnel
○ Avantages :génère du code fonctionnel rapidement, flexible, gestion du risque plus facile
○ Inconvénients : des problèmes d’architecture peuvent survenir car les requis ne sont pas tous connus au départ, difficile de déterminer la fin du projet
○ Projets appropriés : Projets où les exigences évoluent avec une petite équipe facile à fractionner (exemple : applications web).
Cycle de vie transformationnel
○ Définition : prototypage évolutif
○ Caractéristiques : Toutes les parties sont développés simultanément
○ Avantages : peut revenir en arrière pour faire des corrections, permet un regroupement entre les itérations
○ Inconvénients :difficile à gérer, qualité du code déficiente
○ Projets appropriés : Projets où les spécifications sont bien définies et stables (exemple : systèmes embarqués).
Cycle de vie en spirale
○ Définition : Un modèle itératif qui est axé sur la gestion des risques
○ Caractéristiques : Cycles itératifs, gestion proactive des risques.
○ Avantages : Analyse de risque très élaborée, prototype fonctionnel dispo rapidement
○ Inconvénients : Complexité de gestion, possibilité que ça devienne en cascade, difficile à réutiliser
Projets appropriés : Projets complexes avec des risques élevés (exemple : systèmes de défense).
Connaître le cycle de vie du processus unifié et pouvoir associer des objectifs et des critères aux phases et jalons
- Création: Définir la porté du projet
Question posée au jalon: a-t-on tous les objectifs du projet ? - Élaboration: Planifier le projet, spécifier les caractéristiques, et les bases du système
Question: Architecture stable? - Construction: réaliser le produit
Jalon: Opérabilité inititale
Question: système fonctionnel? - Transition: Installer le produit dans le système
Jalon: Livraison du produit
Rôle, artéfact, activité
Rôle: Définit un ensemble de compétences et de responsabilités joué par un ou plusieurs individus
Artéfact: Élément d’information produit dans le cadre du processus, il peut évoluer (ex: code source)
Activité: travail accompli pour produire ou faire évoluer les artéfacts (ex: écrire du code)
Distinction entre projet et processus
Processus: décrit comment l’information est transformée durant le développement du logiciel
Méthodologie,
Un ensemble structuré d’activités et de pratiques utilisées pour atteindre un objectif
Projet: Planifie et assigne les ressources durant le développement logiciel
Un projet est unique et limité dans le temps, tandis qu’un processus est réutilisable et peut être appliqué à plusieurs projets.
Connaître les caractéristiques du processus unifié
- Itératif et incrémental
-Dirigé par les cas d’utilisation
-Centré sur l’architecture
-Concentré sur les risques
Définir ce qu’est une itération et les avantages d’un processus itératif
Itération
Les itérations sont des structures de gestion qui permettent de contrôler la réalisation des phases du cycle de vie. Une itération est une séquence d’activités distinctes suivant un plan et ayant des critères d’évaluation basés sur la modification d’un artéfact
Avantages :
- Flexibilité pour s’adapter aux changements.
- Livraison précoce de fonctionnalités.
- Amélioration continue grâce aux retours fréquents.
Distinctions entre processus discipliné et agile
- Processus discipliné :
○ Structuré et planifié à l’avance.
○ Documentation détaillée.
○ Adapté aux projets avec des exigences stables.- Processus agile :
○ Flexible et itératif.
○ Priorité aux fonctionnalités livrables plutôt qu’à la documentation.
○ Adapté aux projets avec des exigences changeantes.
- Processus agile :
Connaître la définition des termes cérémonieux et opportuniste dans un contexte de développement logiciel.
- Cérémonieux : Un processus rigide avec des étapes et des documents formels, souvent associé aux méthodes traditionnelles comme la cascade.
- Opportuniste : Un processus flexible et adaptatif, souvent associé aux méthodes agiles, où les décisions sont prises en fonction des besoins immédiats.
Comprendre les objectifs de la discipline de gestion de configuration et changement et son bénéfice principal
identifier les artéfacs pour lesquels on veut garder une trace
- Établir les relations entre les artéfacts
- Définir les mécanismes de versions
- Contrôler les changements
- Gérer les requêtes de changements
- Auditer la complétude
Quels sont les problèmes qu’on essaie d’éviter avec la gestion de configuration et de changement?
- Incohérences : Des versions différentes d’un même artefact utilisées simultanément.
- Perte de données : Des modifications non sauvegardées ou écrasées par erreur.
- Manque de traçabilité : Impossible de retracer l’origine d’un bogue ou d’une fonctionnalité.
- Délais supplémentaires : Temps perdu à résoudre des conflits de versions ou à retrouver des informations manquantes.
- Non-conformité : Le produit final ne répond pas aux exigences initiales en raison de changements non contrôlés.
Connaître les 3 dimensions de la GCC
- Gestion des requêtes de changement : Infrastructure pour évaluer : les coûts des requêtes, les changements, l’impacts sur le produit existant. Et pour faire le suivi.
- Mesure: État de configuration basé sur : type, nombre, taux, sévérité des défauts nécessitant une requête de changement trouvés et corrigés durant le développement. Suivi du changement.
- Gestion de la configuration: Structure du produit et items de configuration (gestion du référentiel et des espaces de travail)
Connaître les distinctions entre les systèmes de gestion de version centralisé et distribué ainsi que les bénéfices de ces derniers.
- Systèmes centralisés (exemple : SVN) :
○ Un seul référentiel maître.
○ Les développeurs doivent se connecter au référentiel pour travailler.
○ Moins flexible, mais plus simple à gérer pour les petits projets.- Systèmes distribués (exemple : Git) :
○ Chaque développeur a une copie locale du référentiel.
○ Permet de travailler hors ligne et de fusionner les changements plus facilement.
○ Idéal pour les projets complexes et les équipes distribuées.
- Systèmes distribués (exemple : Git) :
Connaître les bénéfices d’établir des bases de référence dans un référentiel
- Pour élucider des bugs, reproduire des problèmes
- Point de départ pour de nouveaux projets
- Mises à jour de versions stables entre équipes
- Retours en arrière
Savoir distinguer ce qu’est un besoin d’une exigence en génie logiciel.
Besoin :
- Un besoin est une expression générale et souvent floue de ce que l’utilisateur ou le client souhaite obtenir du système.
- Il est de haut niveau et ne précise pas comment le système doit fonctionner.
- Exemple : “Le système doit être facile à utiliser.”
Exigence :
- Une exigence est une spécification détaillée et formelle qui décrit ce que le système doit faire ou comment il doit se comporter.
- Elle est précise, mesurable et testable.
- Exemple : “Chaque fonctionnalité du système doit avoir une bulle d’aide (tooltip) explicative.”
Exigence: expression d’un besoin documenté sur ce que le produit logiciel devrait être ou faire
Connaître les attributs d’une bonne exigence
Une bonne exigence doit posséder les attributs suivants :
- Clarté : Elle doit être facile à comprendre et sans ambiguïté.
- Précision : Elle doit être spécifique et détaillée.
- Testabilité : Elle doit pouvoir être vérifiée par des tests.
- Pertinence : Elle doit être alignée sur les objectifs du projet et les besoins des parties prenantes.
- Réalisme : Elle doit être réalisable avec les ressources disponibles.
Traçabilité : Elle doit être liée à un besoin ou à une fonctionnalité spécifique.
Connaître les trois types d’exigence en génie logiciel et pouvoir donner des exemples
- Exigence d’affaire: décrit pourquoi le système est développé (ex: Le système doit augmenter de 20% le taux de rétention des utilisateurs)
- Exigence fonctionnelle: Les fonctionnalités du produit (ex: le système doit permettre à l’utilisateur de créer un compte)
- Exigences non fonctionnelles: le comportement du produit et les contraintes techniques (ex: Le logiciel doit être facile à maintenir)
Connaître le concept de partie-prenante
Une partie-prenante (ou stakeholder) est toute personne ou organisation affectée par le fonctionnement du système. Cela inclut :
- Clients
- Utilisateurs
- Développeurs
- Experts du domaine
Collaborateurs
Connaître les étapes de gestion des exigences.
- Obtention/saisie des exigences (elicitation)
- Détailler et spécifier les exigences
- Valider les exigences
- Maintenir les exigences
Comprendre les liens entre exigences et tests, exigences et changements en génie logiciel.
Les exigences servent de base pour les tests.
Chaque exigence doit être testable pour vérifier qu’elle est correctement implémentée.
Exigences et changements :
Les exigences évoluent souvent au cours du projet en raison de nouveaux besoins ou de changements dans l’environnement.
Une bonne gestion des exigences permet de suivre ces changements et de s’assurer qu’ils sont correctement implémentés.
Les avantages d’un processus itératif dans le contexte de gestion des exigences
Flexibilité : Permet d’adapter les exigences aux changements et aux retours des utilisateurs.
Validation précoce : Les exigences sont testées et validées dès les premières itérations, réduisant les risques d’erreurs.
Réduction des risques : Les problèmes sont identifiés et résolus plus tôt dans le projet.
Avantage général de processus itératif
-Prendre des gros objectifs et les séparer en petits objectifs à court terme
-Diviser la planification
-Augmente la résilience au changement
-facilite le suivi
-encourage le développement incrémental (divise le produit)
-améliore l’efficacité de l’équipe
Connaître ce que sont analyse et conception et leurs distinctions
Analyse :
* Objectif : Comprendre le problème et les besoins du système.
* Question centrale : “Quel est le problème ?”
* Activités : Identifier les exigences, comprendre le domaine, modéliser les besoins.
* Focus : Sur les besoins des utilisateurs et les caractéristiques du domaine.
Conception :
* Objectif : Définir une solution technique au problème identifié.
* Question centrale : “Comment construire la solution ?”
* Activités : Concevoir l’architecture, définir les composants, modéliser les interactions.
Focus : Sur la construction de solutions techniques
Connaître les caractéristiques des activités d’analyse et de conception
- Génération de solutions : Elles visent à résoudre des problèmes complexes en générant des solutions adaptées.
- Itératives et réflexives : Les solutions sont affinées par essais-erreurs et en utilisant des représentations graphiques (diagrammes).
- Opportunistes : Le processus de conception ne peut pas être entièrement prédit à l’avance ; il s’adapte aux informations acquises en cours de route.
- Utilisation de modèles : Les modèles (diagrammes, schémas) sont utilisés pour représenter et explorer les idées.
Comprendre pourquoi on utilise des modèles dans cette discipline
- Représentation visuelle : Les modèles permettent de visualiser des systèmes complexes.
- Communication : Ils facilitent la communication entre les parties prenantes (développeurs, clients, etc.).
- Exploration : Ils aident à explorer et à valider des idées avant l’implémentation.
- Documentation : Ils servent de documentation technique pour le système.
connaître les principaux modèles (avec leurs exemples)
Modèle de contexte: définir les limites du système et son environnement (ex: diagramme d’état)
Modèle d’interaction: Représenter les interactions entre les acteurs et le système. (ex: modèle de cas d’utilisation)
Modèles structuraux: Décrire la structure des composants du système. (ex: diagramme de classe)
Modèle comportementaux: Représenter le comportement dynamique du système. (diagramme d’activité)
Un premier type montre le flux de traitement d’informations, le deuxième type de modèle montre le flux d’évènement
Connaître la définition du concept d’architecture logicielle et des exemples
L’architecture logicielle décrit l’organisation des composants d’un système, leurs interactions et leurs interrelations. Elle définit la structure globale du système pour répondre aux exigences fonctionnelles et non fonctionnelles.
- Modèle-Vue-Contrôle
- Architecture en couches
Architecture client-serveur
Connaître les bénéfices d’une bonne architecture
➢ Une architecture bien conçue permet aux développeurs d’avoir et de maintenir un contrôle intellectuel sur leur projet, de gérer sa complexité et de maintenir l’intégrité du système.
➢ Une bonne architecture permet une réutilisation significative des composants du système.
➢ Une architecture bien ficelée servira de cadre à la gestion de projet.
➢ Une bonne architecture facilite le développement incrémental.
connaître les compétences de base pour la discipline d’implémentation
- Programmer: traduire la spécification en code
○ Compétence: Compréhension de la conception du langage de programmation et des API- Déboguer: Enlever les fautes de programmation
○ Compétence: le langage de programmation - Exécuter des tests unitaires: Enlever les fautes de traduction
○ Compétence: Compréhension de la conception - Intégrer: Préparer l’identification des fautes de système
○ Compétence: Outils et API
- Déboguer: Enlever les fautes de programmation
Connaître ce qu’est un test unitaire et pourquoi ce genre de test fait partie de cette discipline.
C’est un bout de code automatisé qui appelle une autre méthode/fonction et qui vérifie que son comportement logique est celui qui est attendu. Les tests sont écrits en même temps qjue le code, la personne qui écrit le code est la mieux placée pour écrire les tests
Connaître la description de l’intégration continue, les pratiques qui la soutiennent
définition: pratique où les membres de l’équipe intègre leur travail fréquemment, chaque intégration est vérifié automatiquement par un build automatique, des tests pour détecter des erreurs le plus rapidement possible. Il va souvent y avoir batterie de test et rétroaction
pratiques qui la soutienne:
- commits fréquents
- aucun commit de code dysfonctionnel
- réparation immédiate de build problématique
- écriture de tests automatisés
- tous les tests doivent être réussis
- éviter de récupérer du code problématique
- faire des intégration dans un espace privé
Connaitre les risques que l’intégration continue réduit
- ne pas avoir de logiciel déployable
- tarder à découvrir des défauts
- absence de visibilité du projet
- mauvaise qualité du logiciel
Connaître la relation qui existe entre les tests et la qualité d’un logiciel.
Réponse: Les tests peuvent confirmer la présence d’éléments de qualité dans le produit, mais ne peuvent pas créer de la qualité.
Tester se limite à une approche corrective d’assurance-qualité. Mais certains facteurs de qualité sont construits et demandent donc une approche préventive d’assurance-qualité
Les tests cibles principalement l’évaluation de la qualité du produit logiciel
- Vérifier les fonctions du logiciel telles que conçues
- Trouver et documenter les défauts dans la qualité du logiciel
- Évaluer la qualité du logiciel
- Démontrer concrètement la validité des hypothèses lors des requis
- Valider que les requis ont été implémentés correctement
Connaître les principaux types de tests et leur définition : intégration, système, acceptation et ce qui les distinguent des tests unitaires.
Unitaire: testent une unité en isolation des autres
Intégration: testent l’intégration entre des composantes, permet de tester le flot de données entre les composantes
Système: testent le système au complet, toutes les couches de l’interface utilisateur aux bases de données
Acceptation: testent si le logiciel fait ce qui est demandé par le client. Centré sur un scénario d’utilisation
Connaître les particularités des projets de développement logiciel et les facteurs organisationnels qui l’affectent.
- La nature intellectuelle du travail
- L’évolution rapide de la technologie: il faut les besoins d’apprentissage de la/les technologies
- Le nombre élevé de changements en cours d’execution: ne pas sous estimer l’influence sur les échéances
- L’ambiguïté du rôle de chef de projet
Connaître la notion de risque et les concepts associés : origine, incertitude, perte, catégories de risque
Risque: une variable dont la valeur peut mettre en danger ou réduire le succès d’un projet. la probabilité qu’un événement indésirable ait lieu.
Incertitude:les évènements ne se produiront pas de manière certaine
Perte: plus l‘événement est indésirable, plus le risque est grand
Origine: élément déclencheur
Catégories de risques:
- risques de projet (concernent le déroulement du projet)
- risques techniques
- risques d’affaire (ex: un compétiteur met en marché un produit similaire)
Connaître la démarche de maîtrise des risques (4 étapes) et les stratégies de préparation aux risques
- Identifier les causes potentielles de risques et mettre en évidence les risques critiques
- Analyser les risques: leurs conséquences en termes de charge, de délais et de qualité
- Trouver les solutions pour les réduire (avoir un plan)
- Piloter la mise en œuvre des solutions en surveillant les charges et les délais.
Stratégies de préparation:
- Éviter le risque (pour ne pas être affecté par le risque)
- Transférer le risque (que quelque chose puisse supporter le risque)
- Accepter le risque
- Atténuer le risque (prendre des mesures immédiates pour réduire la probabilité ou l’impact)
- Définir un plan d’action (si le risque devient un problème)
Définir la pratique de déploiement continu
Le déploiement continu est une approche dans laquelle les fonctionnalités logicielles sont livrées fréquemment par le biais de déploiements automatisés.
Connaître les trois environnements du logiciel
➢ Environnement de développement Là où vous développez votre code en travail collaboratif
➢ Environnement de staging Un environnement simulé le plus similaire possible à l’environnement de production.
➢ Environnement de production Là où le système est live et où les utilisateurs accèdent au système. C’est là où l’opération du logiciel génère des revenus.
Objectifs du déploiement continu
- Que toutes les étapes du processus d’implémentation, de déploiement, de tests et de livraison du logiciel soient visibles pour toutes les personnes impliquées
- Améliorer la rétroaction pour que des problèmes soient identifiés et résolus le plus tôt possible dans le processus.
- Donner à l’équipe de développeurs la capacité de déployer et livrer n’importe quelle version du logiciel
Ce qu’il faut mettre en place pour le développement continu
Pour qu’une équipe retire des bénéfices de la pratique du déploiement continu, les déploiements doivent être automatisés et fréquents.
➢ La rétroaction y est cruciale.
➢ Ainsi:
▪ Un changement doit déclencher le processus de rétroaction.
▪ Les développeurs doivent être informés de la rétroaction rapidement.
▪ Les développeurs réagissent rapidement à l’information contenue dans la rétroaction.
anti-patterns du déploiement continu
- Le déploiement manuel du logiciel
- Déployer dans un environnement de production uniquement lorsque le développement est terminé
- La gestion de la configuration de l’environnement de production se fait manuellement
bénéfices du déploiement continu
▪ La responsabilisation des équipes (empowering)
▪ La réduction d’erreurs
▪ La baisse du stress de déploiement
▪ Une plus grande flexibilité de déploiement
▪ C’est en forgeant qu’on devient forgeron (practice makes perfect)
Connaître le concept d’itération et les avantages d’un processus itératif dans le cadre de la gestion de projet
Les itérations rendent un projet plus facile à gérer…
➢ Le projet devient plus facile à planifier et peut s’adapter.
➢ Les risques sont plus faciles à contrôler.
➢ L’avancement est plus facile à mesurer
Comprendre comment les processus logiciel sont utiles et dans quel contexte
Développer du logiciel c’est des taches complexes
Besoin d’expertise poussée
La technologie évolue
Un contexte d’affaire qui change rapidement
Les processus rassemblent les meilleures pratiques
Méthodologie cohérente
Facilite la collaboration et le développement en équipe
Réalisation plus efficace du développement logiciel
Utilisation d’outils
Connaître les distinctions et les similarités entre l’ingénierie logicielle et les autres domaines du génie en termes de compétences et de la nature du travail.
- Ingénieur classique impliqué dans la conception et la surveillance
Logiciel: on couvre plus de compétence(tout le cycle de vie), gestion de projet, de configuration, toutes les phases de réalisation
Expliquer le déroulement d’un projet qui suit le processus unifié
Phases, disciplines, jalons
Itératif et incrémental, passe par les différentes phases, chaque phase passe par toutes les disciplines
Un projet suivant le processus unifié se déroule en quatre phases (création, élaboration, construction, transition), chacune composée de plusieurs itérations. Chaque itération inclut des activités de conception, de développement, de test et de revue. Les risques sont évalués et gérés à chaque étape.
Connaître les liens avec les autres disciplines du génie logiciel et la gestion changement et configuration
La GCC est étroitement liée aux autres disciplines du génie logiciel :
- Analyse et Design : Les changements dans les exigences ou l’architecture doivent être tracés et gérés. - Implémentation : Le code source est un élément de configuration clé, et ses versions doivent être contrôlées. - Test : Les cas de test et les résultats doivent être versionnés pour assurer la reproductibilité. - Gestion de projet : La GCC fournit des données pour suivre l’avancement et gérer les risques.
Connaître la méthode de planification de l’implémentation pendant un projet pour un développement efficace.
Identifier les composants à développer pour livrer une features un cas d’utilisation. Planification plus micro
Savoir comment la discipline des tests se déroule généralement dans le cycle de vie du processus unifié
es tests sont synchronisés avec les itérations, des tests aussi à chaque phase du cycle de vie
Connaître les erreurs communes dans la réalisation des tests et savoir comment y remédier à l’aide de pratiques.
Faire les tests à la fin
Laisser les tests à des développeurs juniors
Sous estimer l’importance des tests
Comprendre la planification à deux niveaux d’un processus itératif
Planification haut niveau plus grossière sur la totalité du projet, milestone et phase
Planification bas niveau une itération à la fois
Connaître la place des mesures en gestion de projet
Tableau de bord, mesure de progrès, de qualité, de ressources
