Discussion:Cycle de développement (logiciel)
- Admissibilité
- Neutralité
- Droit d'auteur
- Article de qualité
- Bon article
- Lumière sur
- À faire
- Archives
- Commons
Cet article est indexé par le projet Informatique.
Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.
| Avancement | Importance | pour le projet | |
|---|---|---|---|
| Bon début | Moyenne |  | Informatique (discussion • critères • liste • stats • hist. • comité • stats vues) |
Cet article ne comporte pas de liste de tâches suggérées. Vous pouvez saisir une liste de tâches à accomplir (par exemple sous forme d'une liste à puces), puis sauvegarder. Vous pouvez aussi consulter la page d'aide.
Les grandes familles[modifier le code]
Modèle en cascade[modifier le code]
On a un peu de mal à lire le premier schéma à droite, peut-être qu'il serait judicieux de séparer les quatre images ou d'agrandir l'image.
Cycle en V[modifier le code]
Je ne sais pas si le lien vers les années 1980 est vraiment nécessaire ici.
Cycle en spirale[modifier le code]
Cycle semi-itératif[modifier le code]
Ce serait plus parlant d'avoir toutes les significations des acronymes ( pour ceux qui n'ont pas de lien )
Cycle itératif[modifier le code]
Comparaison des approches Cascade, V et Itératif[modifier le code]
Références[modifier le code]
Voir aussi[modifier le code]
Il ne faut pas confondre un cycle de développement avec le développement d'un cycle, qui désigne le déplacement dudit cycle par tour de pédale. Ce dernier est calculé en multipliant le braquet par la circonférence de la roue.c'est moi youcef 4 eme année informatique ingégniorat 212.198.57.32 27 sep 2004 à 14:34 (CEST)
"Le cycle itératif n'est pas une bijection avec le cycle en V du type faisabilité = spécifications, élaboration = Architecture, fabrication = développement prototype, transition = tests Sachant que chaque itération ne dépasse jamais huit semaines, cette tactique est donc impossible."
Je trouve ce paragraphe particulièrement subjectif. Chaque entreprise ne fonctionne pas forcement de la même manière. Est-ce réellement une norme, ou un conseil? Le terme Bijection est un peu complexe (terme de matheu), il doit y avoir un moyen d'être plus simple.
Améliorations nécessaires[modifier le code]
La structuration en méthodes semi-itérative et itérative est très discutable et nécessite impérativement d'être revue. En effet:
- les méthodologistes distinguent les méthodes itératives (on fait plusieurs itérations avant d'arriver au résultat final), et les méthodes incrémentales (on livre plusieurs incréments après des itérations, mais chaque incrément est utilisable).
- la description de la section "semi-itérative" correspond en fait à des méthodes itératives. RAD est un parfait exemple, puisqu'on développe un prototype par itérations successives, mais un seul produit fini est livré à la fin du projet.
- l'attribution de RUP (ou plus généralement UP) dans la catégorie "semi-itérative" est erronnée puisque la méthode est considérée comme itérative et incrémentale. En fait, dans UP un projet est itératif (correspondant à la description "semi-itérative" utilisée dans l'article), mais UP considère le cycle de développement comme composé de plusieurs projets (2ème niveau d'itérations) livrant des incréments du produit.
- l'attribution de Scrum et d'autres méthodes agiles à la catégorie semi-itérative est complètement erronée, car ces méthodes ne comportent pas de phasage mais uniquement d'itérations et sont en plus en générale incrémentale.
- pour finir, des variantes du cycle en V existent et on introduit des itérations tant au niveau du composant qu'au niveau du système. Ces variantes seraiet elles-aussi à catégoriser dans "semi-titeratif" (en réalité "itératif").
- il n'y a pas suffisamment de référence pour étayer cette classification. Certaines références (exemple: celle pour RUP) ne justifient pas la classification proposée (par exemple, j'ai lu l'ouvrage pour indiqué RUP de A à Z et il ne mentionne nullement une méthode semi-itérative, bien au contraire).
Approche proposée: Remplacer les 2 sections en cause par 2 sections: 1) les cycles itératifs linéraires (RAD, etc...) 2) les cyles itératifs et incrémentaux (UP et agile). Ces sections pourraient également mentionner d'autres caractéristiques comme le recours ou non a des blocs de temps (timeboxing) ou la variabilité du contenu des itération.
Par ailleurs, il faut rappeler que l'article est sur les cycles (c'est à dire la structuration des activités) et non les méthodes (définition détaillée des tâches, techniques particulières appliquées). Ceci justifie que l'on ne base pas la distinction sur des critères philosophiques (i.e. entre UP et agile), mais qu'on en reste à des critères qui permettent de distinguer objectivement les cycles indépendamment des autres caractéristiques qui forment une méthode.