Processus 1 Flashcards

1
Q

Pourquoi un processus logiciel permet de gérer la complexité d’un projet de développement?

A
  • 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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Connaître les étapes de la construction d’une équipe

A
  • 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é
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Connaître le concept d’équipe maillée et ses avantages (le rôle du leadership, les ingrédients d’une équipe maillée)

A

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é

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Connaître la loi de Conway

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Savoir la définition de cycle de vie en développement logiciel et des concepts rattachés (phase, jalon).

A

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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Cycle de vie en cascade

A

○ 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).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Cycle de vie incrémental

A

○ 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).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Cycle de vie transformationnel

A

○ Définition : Un modèle où le logiciel est généré automatiquement à partir de spécifications formelles.
○ Caractéristiques : Utilisation d’outils automatisés pour transformer les spécifications en code.
○ Avantages : peut revenir en arrière pour faire des corrections
○ 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).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Cycle de vie en spirale

A

○ 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).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Connaître le cycle de vie du processus unifié et pouvoir associer des objectifs et des critères aux phases et jalons

A
  1. Création: Définir la porté du projet
    Question posée au jalon: a-t-on tous les objectifs du projet ?
  2. Élaboration: Planifier le projet, spécifier les caractéristiques, et les bases du système
    Question: Architecture stable?
  3. Construction: réaliser le produit
    Jalon: Opérabilité inititale
    Question: système fonctionnel?
  4. Transition: Installer le produit dans le système
    Jalon: Livraison du produit
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Rôle, artéfact, activité

A

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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Distinction entre projet et processus

A

Processus: décrit comment l’information est transformée durant le développement du logiciel
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Connaître les caractéristiques du processus unifié

A
  • Itératif et incrémental
    -Dirigé par les cas d’utilisation
    -Centré sur l’architecture
    -Concentré sur les risques
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Définir ce qu’est une itération et les avantages d’un processus itératif
Itération

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Distinctions entre processus discipliné et agile

A
  • 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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Connaître la définition des termes cérémonieux et opportuniste dans un contexte de développement logiciel.

A
  • 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.
17
Q

Comprendre les objectifs de la discipline de gestion de configuration et changement et son bénéfice principal

A

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

18
Q
  • Quels sont les problèmes qu’on essaie d’éviter ?
A
  • 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.
19
Q

Connaître les 3 dimensions de la GCC

A
  • 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)
20
Q

Connaître les distinctions entre les systèmes de gestion de version centralisé et distribué ainsi que les bénéfices de ces derniers.

A
  • 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.
21
Q

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

A
  • 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
22
Q

Savoir distinguer ce qu’est un besoin d’une exigence en génie logiciel.

A

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

23
Q

Connaître les attributs d’une bonne exigence

A

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.

24
Q

Connaître les trois types d’exigence en génie logiciel et pouvoir donner des exemples

A
  • 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)
25
Q

Connaître le concept de partie-prenante

A

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

26
Q

Connaître les étapes de gestion des exigences.

A
  1. Obtention/saisie des exigences (elicitation)
    1. Détailler et spécifier les exigences
    2. Valider les exigences
  2. Maintenir les exigences
27
Q

Comprendre les liens entre exigences et tests, exigences et changements en génie logiciel.

A

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.

28
Q

Les avantages d’un processus itératif dans le contexte de gestion des exigences

A

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.

29
Q

Avantage général de processus itératif

A

-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

30
Q

Connaître ce que sont analyse et conception et leurs distinctions

A

-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

31
Q

Connaître les caractéristiques des activités d’analyse et de conception

A
  • 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.
32
Q

Comprendre pourquoi on utilise des modèles dans cette discipline

A
  • 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.
33
Q

connaître les principaux modèles (avec leurs exemples)

A

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

34
Q

Connaître la définition du concept d’architecture logicielle et des exemples

A

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

35
Q

Connaître les bénéfices d’une bonne architecture

A

➢ 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.