UML - Processus de développement, partie 2

Une fois que nous savons comment fonctionnaient les méthodologies de développement d'un projet ou d'un système dans les temps anciens, nous pouvons prendre en compte les différentes erreurs et points dangereux pour l'équipe qui ont été rencontrés.
Comme nous sommes des êtres évolutifs, ayant tellement de problèmes avec les limitations déjà soulevées dans la première partie du didacticiel, cela commence à modifier la méthodologie, Il n'y a plus une séparation stricte des étapes, mais plutôt la collaboration de l'équipe, où chaque membre participe au développement des étapes, par exemple les développeurs aident à la collecte d'informations, les concepteurs et les modélisateurs dans le développement, etc…
Méthode récente
Comme nous l'avions anticipé au début du tutoriel, la méthode récente nous permet de mettre en œuvre collaboration à chaque étape du développement, en aidant cela à augmenter la compréhension du projet dans son ensemble au sein de l'équipe, à une meilleure compréhension et compréhension, nous aurons de meilleures solutions qui nécessiteront moins d'ajustements lors du codage du logiciel.
Bien que tout puisse sembler une preuve de points contre, nous devons mettre en évidence certains problèmes qui peuvent être présents dans notre processus de développement afin de voir que nous sommes encore loin d'une façon parfaite de faire un projet.
Un des premiers problèmes Ce que l'on peut constater c'est le manque de participation des membres de l'équipe, même si c'est de moins en moins, on peut encore trouver des personnes timides qui ont peur de donner leur avis, donc elles sont laissées de côté, fragilisant l'état des connaissances collectives.
Un autre point est que de nombreux chefs de projet doivent donner l'avancement du projet aux clients ou aux utilisateurs, il est donc difficile de dire que l'analyse est déjà terminée et le développement commencé; Fixer ce type de limites peut être contre-productif car cela peut générer des attentes incorrectes et mettre la pression sur l'équipe.
RAD3
Ce méthodologie tire son nom de l'acronyme de "Développement et distribution rapides de la conception d'applications», qui resterait comme Développement de conception et distribution rapide d'applications.

Comme nous le voyons dans le graphique précédent, cette méthodologie nous permet d'intégrer les 3 zones d'exécution De cette façon, les étapes importantes du développement du projet ne sont pas isolées, de sorte qu'un développeur peut accéder aux données importantes du projet au moment de sa génération, tout comme un analyste peut intervenir à d'autres étapes.
Une fois que tout est conforme à la première livraison du projet, nous obtiendrons ainsi les commentaires nécessaires dans un délai plus court qu'avec l'ancienne méthodologie et, grâce à cela, les corrections et améliorations suggérées par l'utilisateur final pourront être intégrées.
Comme on peut le voir, malgré les différentes étapes, cette approche méthodologique nous laisse un espace pour générer les diagrammes UML concentrant ainsi les idées dans un espace avec un langage compréhensible pour toutes les parties.
Avec cela, nous terminons cette deuxième partie du tutoriel, où nous avons appris à intégrer la méthodologie dans nos développements et nous aider également à UML.
Partie 1 de ce tutoriel

Processus de développement UML, partie 1

Avez-vous aimé et aidé ce tutoriel ?Vous pouvez récompenser l'auteur en appuyant sur ce bouton pour lui donner un point positif