Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

INF2050 > Introduction > Flashcards

Introduction Flashcards

1
Q

Une Méthodologie?

A

Une méthodologie fournit un ensemble de lignes directrices
complètes pour la réalisation de chacune des activités du
cycle de développement des systèmes.

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

methodologie inclut quoi?

A
  • Un processus d’encadrement de projet basé sur un cycle donné
  • Des livrables
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Une Méthodologie?
Plusieurs types de projets mais tous passent par les mêmes
étapes de développement

A
  • Initiation
    • Quand le projet commence, objectives et portée définis
  • Planification
    • Lister qui fait quoi, quand
  • Exécution
    • Identification et execution des taches
  • Test
    • Assurance qualité
    • Critères d’acceptation
  • Lancement
    • livraison
  • Revue
    • Fermer le projet
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Certaines méthodologies conventionnels de
processus de développement logiciel:
Modèles conventionnels

A

Coder et corriger : Écriture de code sans analyse ou sans plan
(Code and fix)

Exigences-codage : Codage fondé sur les besoins opérationnels
(Requirements to code)

En cascade : Phases séquentielles et analyse de tendance de jalons
(Waterfall)

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

Qualité
Ressources :

A

§ Equipe dédié d’utilisateurs
§ Ressources compétentes de projet
§ Un environnement de
collaboration adéquat

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

Qualité
Processus:

A

§ Approche / méthodologie de développement
§ Planification de projet
§ Gestion des besoins
§ Ensemble de techniques
§de modélisation
§gestion de projets
§Interview des utilisateurs
§ Critères de succès

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

Qualité
Technologie:

A

§ Standards
§ Outils
§ Architectures de référence

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

Quels problèmes rencontrons-nous ?

A

Succès: Le projet est réalisé selon le
budget et les délais convenus. Il
comporte les fonctions et
caractéristiques demandées.

Défi: Le projet est en retard, le budget a
été dépassé ou il manque certaines
fonctions et caractéristiques demandées.

Échec: Le projet a été arrêté avant sa
fin ou le logiciel développé a été livré
mais n’a jamais été utilisé.

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

Problèmes de communication?
Le développement logiciel est un
jeu coopératif d’invention et de
communication. Il est apparenté au
développement de produit.

A

Les sources de problème dans
notre profession sont les gens et
les interactions dysfonctionnelles
plutôt que les processus et les
outils.

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

Une complexité inhérente
Selon Grady Booch, la complexité est une
caractéristique inhérente au logiciel et elle
provient de quatre éléments :

A

1) la complexité des problèmes ;
2) la difficulté à contrôler le processus de développement ;
3) la flexibilité dans la programmation ;
4) le passage du monde continu au monde discret.

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

L’approche classique se décompose en trois phases et donner les problemes :

A

Conception:
Il faut concevoir tout le produit et répondre à toutes les questions dès le début;
Les utilisateurs sont sollicités dans un délai court pour valider l’intégralité du dossier
de conception;

Réalisation
Les travaux sont fortement parallélisés et sont souvent bloqués par des questions
fonctionnelles;
Toutes les fonctionnalités sont intégralement développées sans arbitrages sur le R.O.I.;
Les utilisateurs sont sollicités dans des démonstrations trop longues leur montrant de
nombreuses fonctionnalités;

Recette
Les utilisateurs sont fortement sollicités sur une période très courte;
Certains points soulevés en recette peuvent remettre en cause profondément d’autres
fonctionnalités;

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

Les constats
Il est très difficile de faire une conception exhaustive au démarrage du projet.

La phase de réalisation est basée sur cette exhaustivité et elle n’intègre pas
la notion de complément de conception ni de variation du besoin.

Les erreurs de conception ou de programmation ou variation du besoin sont
détectées au dernier moment ce qui aggrave leurs conséquences.

Il n’est pas efficace de solliciter les utilisateurs de manière intense sur des
périodes courtes.

L’application opérationnelle n’est disponible qu’à la fin du projet.
Il est difficile de communiquer directement avec les utilisateurs

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

Les constats
Les meilleures idées ne viennent pas forcément au
début du projet

A
  • Modèle en cascade
  • Il est plus facile de construire par étape que tout imaginer dès le début
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Les constats
Les besoins peuvent évoluer pendent le projet

A
  • Demandes de changements
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Les constats
Le formalisme n’est pas naturel

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

Les constats
Contraintes contractuelles

A
  • Insatisfaction constante du client
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Les constats
Chiffrages et Reste à Faire sont difficiles à évaluer

A
  • On ne sait pas estimer la charge restante
18
Q

Certaines méthodologies itératives de
processus de développement logiciel
Modèles itératifs:

A

Construction incrémentale
Cycles itératifs de développement, de vérification et de démonstration

Modèle évolutif
Développement exploratoire

Agile (aussi SCRUM)
Participation du client

En spirale
Gestion des risques

19
Q

Alors pourquoi le développement
Agile?

A
  • Pour satisfaire rapidement notre client avec des solutions logicielles utiles
  • Pour augmenter la qualité
  • Pour faire face à la complexité
  • Pour réduire les inefficacités
  • Pour éviter les longues périodes de stabilisation en fin de projet
  • Pour maximiser la collaboration
  • Pour augmenter la motivation et l’engagement des individus
  • Pour avoir du plaisir au travail
20
Q

C’est quoi l’Agilité ?

A

La capacité d’une personne à se mouvoir facilement, avec aisance.
Implique les réflexes, la coordination et l’équilibre de l’individu

21
Q

C’est quoi l’Agilité ?
Nouvelle manière d’organiser le travail

A

Approche réactive et itérative d’organisation de travail

22
Q

C’est quoi l’Agilité ?
Evolution des métiers

A

Focalisée sur la fonctionnalité et satisfaction client

23
Q

C’est quoi l’Agilité ?
Valorisation du capital immatériel

A
  • Construit en adéquation avec les capacités et limites humaines
24
Q

Les méthodes agiles
* Une méthode agile est une approche itérative et incrémentale, qui est menée
dans un esprit collaboratif avec juste ce qu’il faut de formalisme

  • Elle génère un produit de haute qualité tout en prenant en compte l’évolution
    des besoins des clients
A

Cependant…
Agile ne donne pas la recette secrète du développement logiciel;

Agile fournit simplement les mécanismes permettant de mettre en lumière les
problèmes et difficultés que nous rencontrons dans nos projets de
développement logiciel afin d’être en mesure de les régler;

Une équipe Agile apprend à s’améliorer
continuellement

25
Q

La genèse du phénomène Agile

A

En 2001, dix-sept figures du développement logiciel
se sont réunies pour débattre du thème unificateur
de leurs méthodes respectives.
De cette réunion devait émerger le Manifeste Agile,
considéré comme la définition canonique
du développement Agile.

26
Q

La genèse du phénomène Agile
Le manifeste Agile, Il se compose de 4 valeurs et de 12 principes.

A

Personnes et interactions <- que Processus et outils

Un produit opérationnel <- Documentation exhaustive

Collaboration avec le client <- Négociation d’un contrat

Adaptation au changement <- Suivi d’un plan

27
Q

12 principes sous-jacents au
manifeste

A
  1. Notre plus haute priorité est de satisfaire le client en livrant rapidement
    et régulièrement des fonctionnalités à grande valeur ajoutée.
  2. Accueillez positivement les changements de besoins, même tard dans
    le projet. Les processus Agiles exploitent le changement pour donner
    un avantage compétitif au client.
  3. Livrez fréquemment un logiciel opérationnel avec des cycles de
    quelques semaines à quelques mois et une préférence pour les plus
    courts.
  4. Les utilisateurs ou leurs représentants et les développeurs doivent
    travailler ensemble quotidiennement tout au long du projet.
  5. Réalisez les projets avec des personnes motivées. Fournissez-leur
    l’environnement et le soutien dont ils ont besoin et faites-leur
    confiance pour atteindre les objectifs fixés.
  6. La méthode la plus simple et la plus efficace pour transmettre de
    l’information à l’équipe de développement et à l’intérieur de celle-ci est
    le dialogue en face à face.
  7. Un logiciel opérationnel est la principale mesure d’avancement.
  8. Les processus Agiles encouragent un rythme de développement
    soutenable. Ensemble, les commanditaires, les développeurs et les
    utilisateurs devraient être capables de maintenir indéfiniment un rythme
    constant.
  9. Une attention continue à l’excellence technique et à une bonne
    conception renforce l’Agilité.
  10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile
    – est essentielle.
  11. Les meilleures architectures, spécifications et conceptions émergent
    d’équipes auto-organisées.
  12. À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus
    efficace, puis règle et modifie son comportement en conséquence.
28
Q

Les Méthodes ‘Agiles’
Les méthodes classique fonctionnent bien, à
condition d’avoir:

A
  • Stabilité et prévisibilité
  • Communication et compréhension parfaite
  • Choix parfaits dès le départ
29
Q

Libérer le génie humain
pour l’auto-organisation dans un contexte qu’il peut maîtriser :

A
  • La taille de l’équipe est limitée
  • le domaine du problème est limité
  • Petites équipes autogérées
  • Portée fonctionnelle restreinte à un moment donné
  • Garder un rythme de travail soutenable
  • Avancement par itération
30
Q

Les Méthodes ‘Agiles
Adaptables :

A
  • Réactives aux nouveaux besoins
  • Réceptives aux nouvelles solutions
  • Prendre les décisions définitives le plus tard possible
  • De courtes itérations permettent de changer de direction sans laisser des
    éléments à moitié fait
31
Q

Les Méthodes ‘Agiles
Collaboration avec le client:
* Pourquoi on veut des contrats ?

A
  • Instaurer la confiance autrement
  • Eviter les effets pervers d’un contrat
32
Q

Les Méthodes ‘Agiles’
Toujours focalisées sur le produit final:

A
  • Une vision commune pour l’équipe
    Ø la satisfaction du client
  • Découper le projet autrement
    Ø par fonctionnalité
  • Organiser en cycles de développement réduits
    Ø itérations
33
Q

Les Méthodes ‘Agiles’
L’estimation de charge est difficile, mais les courtes
itérations nous aident:

A
  • On est plus précis sur les petites tâches
  • Feedback très rapide
  • Plus facile à s’adapter face aux dérives, surprises
34
Q

Les Méthodes ‘Agiles’
Points forts

A
  • Itératif à planification souple
  • Simple à mettre en œuvre
  • Fait une large place aux aspects techniques : prototypes, règles de
    développement, tests…
  • Innovant: programmation en duo, kick-off, rétrospective, meetings
    debout …
35
Q

Les Méthodes ‘Agiles’
Points faibles

A
  • Ne couvre pas les phases en amont et en aval au développement :
    capture des besoins, support, maintenance, tests d’intégration…
  • Élude la phase d’analyse, si bien qu’on peut dépenser son énergie à
    faire et défaire
  • Assez flou dans sa mise en œuvre: quels intervenants, quels
    livrables ?
36
Q

Adapter son processus de
développement…
Travailler de façon itérative et incrémentale:

A
  • Que ce soit au niveau des plannings, des spécifications, ou des
    développements…
37
Q

Adapter son processus de
développement…
L’itératif permet une gestion efficace des risques,

A
  • Aborder dès les premières itérations, les points difficiles
  • Par exemple, les premières itérations de la phase technique aborderont les
    aspects sécurité et transaction.
38
Q

Adapter son processus de
développement…
L’itératif permet de présenter rapidement des éléments de
validation aux utilisateurs:

A
  • Réaliser des prototypes de validation
39
Q

Les bénéfices attendus de l’agilité :

A

Un produit qui correspond mieux aux attentes des utilisateurs;

Produit plus rentable;

Mise à jour en temps réel des jalons et des coûts;

Transparence sur l’avancement du projet;

Améliorer la qualité et la maintenabilité du projet;

Les utilisateurs connaissent déjà l’application;

Satisfaction de toute l’équipe

40
Q

Particularités communes
Développement itératif et incrémental

A

Emphase sur la qualité:
Tests automatisés
Inspection et adaptation
Intégration continue
Satisfaction du client

41
Q

Erreurs communes

A
  • Faire de l’Agile « pour être dans le vent »
  • Faire du développement itératif et non incrémental
  • Commencer à sprinter seulement lorsque tous les besoins sont recueillis
  • Effectuer des « mini cascade »
  • Laisser les spécialistes travailler en silo
  • Avoir un client qui ne s’implique pas suffisamment
  • Ne pas travailler en équipe

INF2050 (15 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions