Le Touilleur Express

  • Accueil
  • A propos de l’auteur
  • A propos du Touilleur Express

Les "-ilities" d'un projet: usability, scalability…

6 septembre, 2005

J’avais lu un post à propos des « ilities » d’un projet. C’est une petite technique de gestion de projet qui permet de recadrer les attentes entre le client d’une part et l’équipe de dévelopement d’autre part. La méthode consiste à noter de 1 à 10 une liste d’adjectif qui définit les caracteristiques d’un projet informatique. La liste d’origine est en anglais et j’ai traduit en francais les différents adjectifs.

Prenez cette liste, demandez à un programmeur de la remplir. Faire de même avec le chef de projet et enfin avec l’équipe business ou avec votre client. Un score de 1 pour « pas du tout important » et 10 pour « critique ». L’idéal est de le faire avant le début du projet, en cours et lors de la phase de recette.

  • Adaptability (flexibilité) ? une application qui peut être facilement étendue pour ajouter de nouvelles fonctions (extensibilité marche aussi)
  • Configurability (configurabilité) – permet sans recoder ou compiler d’élèment de changer le comportement d’une application.
  • Maintainability (maintenance) ? capacité à administrer l’application. Un doc d’exploitation, des procédures d’urgence améliorent la maintenance et le travail du support.
  • Stability(stabilité) – capacité à rester en fonctionnement quelque soit le type d’erreur ou la charge. Cependant en cas d’erreur, l’application doit s’arrêter pour reporter le plus rapidement possible une erreur (fast error fail) sans bloquer de ressources.
  • Deployability(deployabilité) le système est capable de déployer de nouvelles fonctions ou des corrections d’erreur rapidement, éventuellement sans s’arrêter. Ce critère est important si les mise-à-jour sont fréquentes. Par exemple le système « Windows Update » facilite le travail de l’administrateur.
  • Scalability(capacité à monter en charge) un système est dit scalable lorsqu’il accepte de traiter une plus grande quantité d’information sans intervenir sur le matériel (CPU, mémoire…). C’est aussi valable pour des applications réparties sur plusieurs machines.
  • Usability (ergonomie) ce critère caractérise la qualité ergonomique de l’interface. Une interface doit être rapide, robuste et éventuellement internationalisée (i18n). Valable aussi pour la documentation utilisateur.
  • Testibility (testabilité) capacité qu’a le système à s’auto-tester que ce soit en cours de dévelopement (tests unitaires) ou en production (tests de bon fonctionnement). Se dit aussi d’un systeme ou d’une application qui donnerait un contexte d’exemple et de démonstration.
  • Performability(réponse) autant la scalability définit l’accéleration, autant la performability serait la vitesse maximum que l’application ou le système peut atteindre. Parfois la vitesse de traitement n’est pas une priorité (système asynchrone) et parfois le temps réel est un critère indispensable.
  • Interoptibility(interopérabilité) capacité d’un système à s’interfacer avec d’autres applications externes. Ceci rajoute des efforts lors du dévelopement pour supporter par exemple un autre type de plateforme, de base de données, de langage… Ce paramètre aura une influence sur la stabilité et la testabilité. Plus votre application utilise d’autres systèmes, plus celle-ci est complexe à tester et débuger.

L’idéal est de voir quels sont les 3 critères les plus important afin que chacun s’accorde dessus. Grâce à cette technique il sera peut-être facile de voir que le client n’est pas intéressé par un système maintenable (Maintainability) puisqu’il n’envisage pas d’autres versions par la suite… D’autre part cela évitera de se lancer dans des dévelopements complexes pour des critères qui ne seront pas discriminant aux yeux de l’équipe Business.

Sur ce, je retourne à mon code pour terminer la partie « Scalability » avec JGroups… j’ai encore pas mal de travail en perspective.

Articles similaires:

Default ThumbnailA toi, Chef de projet, qui veut passer à Scrum Default ThumbnailRetour sur le livre "Gestion de Projet Agile v3" par V.Messager Rota Default ThumbnailQuelques chiffres sur un projet Play2/Scala, 15 mois après Redis : le créateur du projet passe de Pivotal à Redis Labs

Derniers articles

  • Vis ma vie de Staff/Principal Engineer

    Suite de l’article précédent sur le Staff Engineer. Aujourd’hui, voyons un peu

    20 juillet, 2022
  • Inari

    Devenir Staff Engineer : comment et pourquoi ?

    Après une dizaine d’années en tant que développeur, vous serez un jour

    17 juillet, 2022
  • WeAreDevelopers 2022, conférence à Berlin – jour 1

    Il est 8h40, 19 degrés, vous êtes à Berlin. La queue dehors

    24 juin, 2022

Tweets @nmartignole

  • RT  @katecrawford : Umm, anyone a little concerned that Bard is saying its training dataset includes... Gmail? I'm assuming that's flat out…

    2 days ago
  • Je découvre qu’ils apprennent le SQL en Terminal, très intéressant https://t.co/MrfcHve9wo

    3 days ago
  • RT  @AmelieBenoit33 : Je m’essaye à de nouveaux formats ! Un premier sketch qui me trottait en tête depuis le sketchnote précédent; la techn…

    4 days ago

Mots clés

Apple (32) Architecture (13) Big Data (5) Conference (8) Devoxx (55) Dev Web (37) Doctolib (2) geekevent (1) groovy (2) Innoteria (11) Java (517) Linux (10) Non classé (14) Perso (266) Recrutement (3) Scala (30) scrum (43) Société (3) Startup (20) Web 2.0 (67)

Le Touilleur Express

Blog par Nicolas Martignole

Contactez-moi : nicolas@touilleur-express.fr

Suivez-moi sur Twitter : @nmartignole

Copyright© 2008 - 2020 Nicolas Martignole | Tous droits réservés
  • A propos de l’auteur
  • A propos du Touilleur Express
  • Log In
  • My Account
  • My Profile
  • Reset Password

Le Touilleur Express