Dans l'article suivant : [ http://www.linuxfocus.org/Francais/November2002/article265.shtml(...) ] titré "Gorm et ProjectCenter, les outils RAD de GNUstep", j'ai remarqué qu'ils faisaient *allusion* à la méthode de développement nommée RAD. Etant donné que je me suis vu intrigué par la manière dont ils allaient aborder la chose et surtout à propos des logiciels qu'ils allaient présenter, j'ai été creuser un peu.
En allant voir la page de description de Gorm et ProjectCenter, il apparait clairement qu'il s'agit d'IDE ("Interface Development Environment") et non d'outils de RAD.
Je voudrais donc corrigé le tir. Il est vrai que le rapid de RAD est trop souvent compris de travers. De plus des personnes plus éclairées que moi pourront me corriger... ce qui m'en apprendra plus... ;c)
RAD est une méthode de développement basé sur le principe de prototype. Elle est sencé garantir la non-régression de l'application ainsi qu'un code toujours plus sain (rien à voir donc avec les IDE).
Il est question, avec RAD, de procéder avec des prototypes (comme je le disais), cela dans le but de faire participer plus activement le maître d'ouvrage (le client) et ainsi, d'avoir aussi une application répondant mieux aux demandes de celui-ci, tout en gardant le contact dans le temps (les clients aiment je crois).
En gros, une application est découpée en fonctionnalités de différents niveau. Ces fonctionnalités seront regroupées en de multiples ensembles (entre 2 et 5 par exemple) selon leur priorité dans la réalisation du logiciel. Ainsi, on obtient "les fiches techniques" des divers prototypes que l'équipe devra développer successivement.
Chaque prototype se voit affécter diverses fonctionnalités (comme énoncé plus haut). De la spécification aux beta-tests en passant par le développement et les alpha-tests.
Chaque prototype validé par les beta-tests passe en version finale (sinon quoi, on retourne en phase de développement et on recommence) et débute la phase du prototype suivant. Le code de chaque prototype se doit de rester inchangé lors du développement du prototype suivant.
Dans la pratique, cette méthode s'applique plus facilement à des approches objet et force les notions de modularités.
J'espère que ce petit essai n'aura pas été trop truffé de fautes tant sur le fond que sur la forme. J'espère aussi avoir été suffisament simple pour être compréhensible par la plupart (c'est un de mes défauts). J'attends vos correctifs ;c)
De même j'espère que si l'article de LinuxFocus contient vraiment une erreur, ils seront à même de la corriger ! :c/
# RAD ?
Posté par Baptiste SIMON . En réponse à la dépêche LinuxFocus a 5 ans !. Évalué à 10.
En allant voir la page de description de Gorm et ProjectCenter, il apparait clairement qu'il s'agit d'IDE ("Interface Development Environment") et non d'outils de RAD.
Je voudrais donc corrigé le tir. Il est vrai que le rapid de RAD est trop souvent compris de travers. De plus des personnes plus éclairées que moi pourront me corriger... ce qui m'en apprendra plus... ;c)
RAD est une méthode de développement basé sur le principe de prototype. Elle est sencé garantir la non-régression de l'application ainsi qu'un code toujours plus sain (rien à voir donc avec les IDE).
Il est question, avec RAD, de procéder avec des prototypes (comme je le disais), cela dans le but de faire participer plus activement le maître d'ouvrage (le client) et ainsi, d'avoir aussi une application répondant mieux aux demandes de celui-ci, tout en gardant le contact dans le temps (les clients aiment je crois).
En gros, une application est découpée en fonctionnalités de différents niveau. Ces fonctionnalités seront regroupées en de multiples ensembles (entre 2 et 5 par exemple) selon leur priorité dans la réalisation du logiciel. Ainsi, on obtient "les fiches techniques" des divers prototypes que l'équipe devra développer successivement.
Chaque prototype se voit affécter diverses fonctionnalités (comme énoncé plus haut). De la spécification aux beta-tests en passant par le développement et les alpha-tests.
Chaque prototype validé par les beta-tests passe en version finale (sinon quoi, on retourne en phase de développement et on recommence) et débute la phase du prototype suivant. Le code de chaque prototype se doit de rester inchangé lors du développement du prototype suivant.
Dans la pratique, cette méthode s'applique plus facilement à des approches objet et force les notions de modularités.
J'espère que ce petit essai n'aura pas été trop truffé de fautes tant sur le fond que sur la forme. J'espère aussi avoir été suffisament simple pour être compréhensible par la plupart (c'est un de mes défauts). J'attends vos correctifs ;c)
De même j'espère que si l'article de LinuxFocus contient vraiment une erreur, ils seront à même de la corriger ! :c/