Collaboration à la conception d’applications¶

Introduction à la conception d’applications¶

Notes importants¶

  • Ce cours est un plagit du cours donnés par Anastasiya Basanets

  • Anastasiya.Basanets@collegeahuntsic.qc.ca

Le development d'application c'est n'importe quoi¶

Il y a une excellente source pour mettre de l'ordre dans ce tas de kakashka: https://neverworkintheory.org/

Cours¶

À quoi sert les différentes méthodes?¶

Beaucoup de types différents de logiciels :

  • Logiciel de base (système d'exploitation, pilotes)
  • Applications traditionnelles et web
  • Jeux vidéos
  • Logiciel scientifique et de recherche
  • Logiciel embarqué (sur circuit électronique)
  • Modules d'intelligence artificielle
  • Etc

Chaque logiciel est développé en utilisant une approche différente, qui demande réflexion!

Exemples¶

On ne programme pas de la même manière un jeu vidéo et un électrocardiogramme.

Jeux video¶

Livraison: Pression du marché (ex.: sortir pour Noel, pour une plateforme, pour devancer la compétition).

Impact d'un bogue: On fera un correctif (« patch »).

électrocardiogramme¶

Livraison: Préférable d’être en retard que de livrer un produit dangereux.

Impact d'un bogue: Dommages aux personnes

Exemples¶

On ne programme pas de la même manière un jeu vidéo et un électrocardiogramme.

Firefox version 1¶

Priorités du développement: Découvrir les besoins des clients, trouver des solutions, implémenter, et valider que cela correspond aux besoins, etc.

Firefox version 57¶

Priorités de la maintenance: Corriger les bogues, fermer les failles de sécurité, identifier des besoins émergents, assurer que l'architecture reste saine, etc.

À quoi sert les différentes méthodes?¶

Ainsi, dans un projet typique, entre 60% et 80% de l’effort consacré au logiciel a lieu après la livraison, soit avec la correction des bogues et la maintenance.

Le développement doit donc produire un logiciel maintenable, en plus de 4 défis majeurs.

Étapes de développement¶

Discipline Exemple d’activités
Exigences Définition du problème
Définition des exigences (spécifications)
Conception Conception architecturale
Conception détaillée
Implémentation Codage et débogage
Tests unitaires
Intégration et tests d’intégration
Tests Tests boîtes blanche (vérification)
Tests boîte noire (validation)
Déploiement Période de rodage (ajustement post-livraison)
Maintenance corrective (correction bogues)
Maintenance perfective (ajout de fonctionnalités)

Cycle de development¶

ss

Question 1¶

Pourquoi est-il important de penser à la maintenance du logiciel avant de commencer le développement ?

  1. Parce que la maintenance est la première étape du développement logiciel.
  2. Parce que la majorité du coût du logiciel provient de l'effort effectué durant la maintenance.
  3. Parce que la maintenance est l'étape où le code est écrit.
  4. Parce que nos logiciels sont toujours pleins de bogues et qu'il faut prévoir beaucoup de temps pour les corriger.

Question 2¶

Un logiciel n'est pas comme un bâtiment : il ne peut pas s'effondrer et tuer une personne. En conséquence, il est normal que les logiciels soient moins stables que les bâtiments

  1. Vrai

  2. Faux

Cycle de vie et cas d’utilisation¶

Terminologie¶

Processus de développement logiciel: Ensemble d'activités, de documents et des compétences nécessaires pour la réalisation d'un produit. Approche adaptée au contexte.

Cycle de vie: Vue de très haut niveau décrivant l'ordre dans lequel les disciplines sont effectuées.

Activités: Élément de travail. Décrit les tâches qui réalisent les artéfacts.

Artéfacts: Élément d’information. Généralement un document, mais peut être un courriel, ou même un échange verbal.

Rôle: Décrit les compétences requises pour faire une activité. Les responsables assignées à un rôle sont responsables des artéfacts produit par l’activité.

Cycles de vie: Cascade¶

Faisable si toutes les informations requises sont disponibles au début du projet.

Avantages:

  • Gestion facile
  • Toutes les tâches se planifient
  • Points de contrôle précis permettant de décider si l’on va de l’avant (go/no go)

Cycles de vie: Cascade¶

Cascade peut être approprié lorsque:

  • Faible incertitude au niveau des besoins du clients
  • Faible incertitude technique
  • Réalisation répétitive
  • Peu d’aspects novateurs
  • Faible participation du client/utilisateurs
  • Pas d’urgence de voir le produit fini

*** Un changement mineur peut avoir des répercussions à travers tout le projet.

Cycles de vie: Cascade (V, W ou X)¶

  • V : Activités de développement.

  • W, X : Ajout des activités d'assurance-qualité.

  • Approche essentiellement en cascade avec des revues et des inspections.

Cycles de vie: Incrémental (itératif/évolutif)¶

Itérations (cycles rapides) de production d’un produit fonctionnel. Les itérations sont indépendantes les unes des autres. Généralement, une itération dure entre 2 à 6 semaines. Une portion des exigences est connue au préalable.

Cycles de vie: Incrémental (itératif/évolutif)¶

Avantages

  • Génère du code fonctionnel rapidement dès le début du projet
  • Plus de flexibilité: plus facile de changer les exigences en cours de projet
  • Gestion du risque plus facile: une itération permet de passer à travers toutes les étapes du développement et d’identifier les problèmes.
  • Chaque itération est une petite approche cascade facile à gérer.

Désavantages

  • Des problèmes d’architecture peuvent survenir parce que les exigences ne sont pas toutes claires au départ.
  • Difficile de déterminer la fin du projet.
  • Difficile d’estimer adéquatement les tâches pour finir l’itération du temps.

Importance des exigences¶

À quoi servent les exigences?¶

  • Servent à définir le travail à faire : budget, échéancier, contrat avec les clients.

  • Servent de base a la conception: document d'architecture permettant la création du code.

  • Servent à définir les tests d'acceptation.

À quoi servent les exigences?¶

Document de vision¶

  • Une simple formulation du problème sur quelques pages. Problème décrit du point de vue des utilisateurs (décrit leurs besoins).

  • Besoin ≠ Exigence

    • Besoin est de haut niveau et flou Ex: Le système sera facile à utiliser.
    • Exigence est de plus bas niveau et plus formel
    • Ex: Chaque fonctionnalité du système doit avoir une info-bulle.

Les projets sont en retard à cause des exigences¶

  1. Requirements redinement
  2. Task dependencies
  3. Organizational alignment
  4. Organixational politics
  5. Geographic distribution

n.b.: "technical problems" ne fait meme pas parti du top 5

source: https://youtu.be/g3b8JfkV5jQ?feature=shared&t=334

Méthodes pour avoir les Exigence: Working Backwards (the Amazon Method) (addition par didier)¶

Idée¶

  • Partir d'une idée concrètes de ce que l'on veut à la fin

Sources¶

  • https://www.productplan.com/glossary/working-backward-amazon-method/
  • https://www.quora.com/What-is-Amazons-approach-to-product-development-and-product-management?ref=http://www.product-frameworks.com/

Méthodes pour avoir les Exigence: Building A Plane While Flying (addition par didier)¶

ide¶

  • construire le plus rapidement possible

  • Évite de construire des choses innnutile

  • Force d'avoir un produit rapidement

Sources¶

  • https://medium.com/@coachjennie/the-freedom-of-building-the-plane-while-flying-it-96dd2d899656

  • Pis 1 000 000 de résultats sur google

In [ ]:
https://neverworkintheory.org/