Rational Unified Process in Software Testing
La méthodologie Rational Unified Process (RUP) utilise l’approche orientée objet dans sa conception et l’utilisation de la notation UML (Unified Modeling Language) est conçue et documentée pour illustrer les processus en action. Elle utilise des techniques et des pratiques commercialement éprouvées.
C’est un processus considéré comme lourd et applicable de préférence aux grandes équipes de développement et aux grands projets, mais le fait qu’il soit largement personnalisable permet de l’adapter à des projets de toute envergure.
Spécifiques
Pour la gestion de projet, le modèle RUP(Rational Unified Process) fournit une solution disciplinée telle que les tâches et les responsabilités décrites au sein d’une organisation de développement logiciel.
RUP (Rational Unified Process) est, en soi, un produit logiciel. Il est modulaire et automatisé, et toute sa méthodologie est soutenue par plusieurs outils de développement intégrés et vendus par IBM à travers ses « Rational Suites ».
Les méthodes de compétition dans le domaine du génie logiciel comprennent les « salles blanches » (considérées comme lourdes) et agiles (légères) telles que la programmation extrême (XP-Extreme Programming), Scrum, FDD, et autres.
Il existe certaines directives et modèles qui sont définis, pour les membres du personnel d’un cycle de production, par RUP : une partie du client et une évaluation de l’avancement du projet par sa direction. Cela aide les développeurs à rester concentrés sur le projet.
Exigences de gestion
Une documentation appropriée est essentielle pour tout projet à grande échelle ; notez que RUP décrit comment documenter la fonctionnalité, les limites du système, les restrictions de conception et les exigences commerciales.
Les cas d’utilisation et les scénarios sont des exemples d’artefacts de processus dépendants, qui ont été considérés comme beaucoup plus efficaces pour capturer les exigences fonctionnelles.
L’utilisation d’une architecture basée sur les composants
L’architecture basée sur les composants crée un système qui peut être facilement extensible, favorisant la réutilisation et les logiciels une compréhension intuitive. Un composant fait généralement référence à un objet dans la programmation orientée objet.
RUP fournit une manière systématique de construire ce type de système, en se concentrant sur la production d’une architecture exécutable dans les premières étapes du projet, c’est-à-dire avant d’engager des ressources à grande échelle.
Les composants dont il est question ici sont généralement inclus dans les infrastructures déjà existantes sur place. Ces infrastructures comprennent CORBA ainsi que le Component Object Model (COM).
L’utilisation de modèles logiciels visuels dans le modèle RUP
En abstrayant la programmation de votre code et en la représentant à l’aide de blocs de construction graphiques, RUP peut être un moyen efficace d’obtenir une vue d’ensemble d’une solution.
L’utilisation de modèles visuels peut également permettre à des individus ayant un profil moins technique (comme les clients) d’avoir une meilleure compréhension d’un problème donné, et donc d’être plus impliqués dans le projet dans son ensemble.
Le langage de modélisation UML est devenu une norme industrielle pour représenter les projets, et est largement utilisé par RUP !
En savoir plus : Lisez les détails exclusifs des tests agiles
Vérifier la qualité du logiciel
Il n’assure pas la qualité du logiciel est l’échec le plus courant dans tous les projets de systèmes informatiques. Habituellement, on pense à la qualité du logiciel après l’achèvement des projets ou la qualité est la responsabilité d’une autre équipe de développement.
Gestion et contrôle du changement de logiciel
Dans tous les projets de logiciels, l’existence de changement est inévitable. RUP définit des méthodes pour contrôler et surveiller les changements. Comme un petit changement peut affecter les applications de manière totalement imprévisible, le contrôle des changements est essentiel pour le succès d’un projet.
RUP (Rational Unified Process)définit également les domaines de travail et de sécurité, ce qui garantit à un programmeur que les changements dans un autre système n’affecteront pas votre système.
Phases de la méthodologie RUP
Jusqu’ici, ces directives sont générales, à respecter tout au long de la vie d’un cycle de projet. Les phases (voir la figure ci-dessous) indiquent l’importance accordée au projet à un moment donné. Pour capturer la dimension temporelle d’un projet, RUP divise le projet en quatre phases différentes:
Initiation ou conception : accent sur la portée du système;
Préparation : accent sur l’architecture;
Construction : accent sur le développement;
Transition : accent sur l’application.
RUP est également basé sur les 4 P:
- People
- Design
- Product
- Process
Les couches sont composées d’itérations. Les itérations sont des fenêtres de temps ; les itérations ont défini le terme comme les phases sont objectives.
Toutes les phases génèrent des artefacts. Ceux-ci seront utilisés dans la phase suivante et documentent le projet et permet un meilleur suivi.
Phase de conception
La phase de conception ou d’initiation contient les flux de travail nécessaires à l’accord des parties intéressées – les acteurs – avec les objectifs, l’architecture et la planification du projet. Si ces acteurs ont de bonnes connaissances, il ne sera pas nécessaire d’analyser. Dans le cas contraire, une analyse plus élaborée est nécessaire.
Dans cette étape, les exigences essentielles du système sont transformées en cas d’utilisation. L’objectif n’est pas de les clore tous, mais seulement ceux qui sont nécessaires pour façonner l’opinion.
Cette étape est généralement courte et sert à définir s’il est possible de poursuivre le projet et à définir les risques et le coût du dernier. Un prototype peut être réalisé pour être approuvé par le client. Comme le cite le RUP, l’idéal est d’effectuer des itérations, qui doivent être bien définies en termes de quantité et d’objectifs.
Phase d’élaboration
La préparation sera pour la conception du système, en complément de l’enquête et/ou de la documentation des cas d’utilisation, devant l’architecture du système, pour revoir le modèle économique du projet et pour commencer la version du manuel utilisateur. Il faut accepter : La description du produit (augmentation + intégration) est stable ; le plan du projet est fiable ? Les coûts sont admissibles?
Phase de construction
Dans la phase de construction, le développement physique du logiciel commence, codes de production, tests alpha. Les tests bêta sont effectués au début de la phase de transition.
Vous devez accepter les tests, les processus stables et de test, et le code du système est « baseline ».
Phase de transition
Dans cette phase se trouve la livraison (« déploiement ») du logiciel, qui réalise le plan de déploiement et de livraison, le suivi et la qualité du logiciel. Les produits (releases, versions) vont être livrés, et placer la satisfaction du client. Cette étape a également lieu la formation des utilisateurs.
Disciplines de la méthodologie RUP (Rational Unified Process)
La discipline de modélisation métier
Les organisations sont de plus en plus dépendantes des systèmes informatiques, il est donc impératif que les ingénieurs des systèmes d’information sachent comment les applications sont intégrées dans le développement de l’organisation. Les entreprises investissent dans l’informatique, qui comprend l’avantage concurrentiel de la valeur ajoutée par la technologie.
Le but de la modélisation de l’entreprise est d’abord d’établir une meilleure compréhension et communication entre l’ingénierie d’entreprise et l’ingénierie logicielle.
Comprendre l’entreprise signifie que les ingénieurs logiciels doivent comprendre la structure et la dynamique de l’entreprise cible (le client), les problèmes actuels auxquels l’organisation est confrontée et les méthodes et stratégies potentielles pour s’amender.
Un autre aspect important qui ne doit pas être sous-estimé est que les parties concernées telles que les développeurs ainsi que les clients et aussi les utilisateurs finaux doivent avoir une compréhension claire de l’organisation, et une caractéristique importante de cette compréhension est qu’elle doit être commune à toutes les parties impliquées.
La modélisation d’entreprise explique comment décrire la vision d’une organisation dans laquelle le système sera mis en œuvre et comment utiliser cette vision comme base pour décrire les processus, les fonctions et les responsabilités.
Exigences du cours
Ce cours explique comment obtenir les demandes des parties intéressées (« parties intéressées ») et les convertir en un ensemble d’exigences selon lesquelles les produits fonctionnent dans le système à construire et fournir les exigences détaillées de ce qui est nécessaire pour le système.
Analyse et conception de la discipline (« conception »)
Le but de l’analyse et de la conception est de montrer comment le système sera réalisé. L’objectif est de construire un système qui :
Exécute dans un environnement d’exécution spécifique, les tâches et les fonctions spécifiées dans les descriptions des cas d’utilisation
Satisfait tous vos besoins
Il est facile à maintenir quand il n’y a pas de changements dans les exigences fonctionnelles, les résultats du projet dans un modèle d’analyse et de conception a optionnellement un modèle d’analyse.
Le modèle de conception est utilisé comme une version conceptuelle du code source, affichant seulement le strict minimum. Cela permet à l’utilisateur de n’importe quelle inspection de déterminer le style dans lequel le code source a été rendu.
Le modèle de conception est rendu de telle manière qu’il contient différentes divisions de conceptions. Ces divisions sont stockées dans des sous-systèmes définis.
Chaque sous-système a une interface distincte qui est conçue avec précision. Il contient également des descriptions de la façon dont les objets de ces classes collaborent pour réaliser la conception des cas d’utilisation.
La discipline Mise en œuvre
Les effets de l’application sont :
- En référence aux sous-systèmes en couches organisés pour une application, le code d’organisation est configuré.
- Les différentes classes ou divisions de composants sont réalisées. Ces composants comprennent
- Les fichiers sources
- Les exécutables et
- Les binaires
- Les composants développés en tant qu’unités sont testés
Intégrer les résultats produits par les exécutants individuels (ou équipes), dans un système exécutable. Les systèmes sont réalisés à travers les composants de l’application.
Le processus vise à remplir une fonction importante, qui est de définir la procédure exacte à utiliser, afin de réutiliser les composants qui sont soit ; déjà existants ou qui ont été fraîchement introduits.
Cela permet une possibilité de maintenance du système de hassle et une amélioration substantielle des chances d’utilisation des composants.
Test de discipline
Les objectifs du test de discipline sont :
- Vérifier l’interaction entre les objets
- Vérifier l’intégration correcte de tous les composants logiciels
- Vérifier que toutes les exigences ont été exécutées correctement
- Identifier et s’assurer que les défauts sont traités avant la mise en œuvre du logiciel
- S’assurer que tous les défauts sont corrigés, examinés et fermés
Conclusion
En cas de défauts dans le projet, leur correction peut entraîner des coûts inutiles parce que les défauts ne sont pas mis en évidence en temps voulu.
Si le projet, cependant, est testé dans son intégralité, cela serait bénéfique car tous les défauts qui pourraient se glisser dans les projets peuvent être identifiés et vérifiés au plus tôt.
Cela aura, à son tour, une réduction massive des coûts liés à la rectification des défauts. C’est l’approche itérative proposée par le Rational Unified Process.
Pour que le test porte ses fruits et ait les meilleurs résultats possibles, les tests doivent être effectués sur quatre paramètres de qualité et aussi il doit y avoir des normes établies qui doivent être respectées pour que le projet soit considéré comme ayant passé le test.