Gestion du patrimoine immobilier OPGI de Khenchela

II. Présentation de processus 2TUP

1. Introduction :

La complexité croissante des systèmes informatiques a conduit les concepteurs à s'intéresser aux méthodes. Chaque méthode se définit par une notation et un processus spécifique.

UML a ouvert le terrain en fusionnant la notation. Il reste cependant à définir le processus pour réellement capitaliser des règles dans le domaine du développement logiciel.

Le groupe UML travaillé à unifier non pas les processus, mais plus exactement les meilleures pratiques de développement objet.

Ces processus se distinguera par le générique « Unified Process ». Le processus unifié

Le processus unifié est un processus de développement logiciel : il regroupe les activités à mener pour transformer les besoins d'un utilisateur en système logiciel. Caractéristiques essentielles du processus unifié : - Le processus unifié est à base de composants, - Le processus unifié utilise le langage UML (ensemble d'outils et de diagramme),

- Le processus unifié est piloté par les cas d'utilisation, - Centré sur l'architecture,

- Itératif et incrémental.

Le processus adopté dans notre travail: 2TUP

Le processus 2TUP :

2TUP signifie (2Track Unifie Process).c'est un processus UP qui répond aux caractéristiques que nous venons de citer.

Le processus 2TUP apporte une réponse aux contrainte de changements continuel imposées aux systèmes d'information de l'entreprise.

En ce sens, il renforce le contrôle sur les capacités d'évolution et de correction de tels système (2track) signifie littéralement que le processus suit deus chemins.il s'agit des chemins (Fonctionnels) et (D'architecture technique) qui correspondent au système informatique.

Contraintes Fonctionnelles

Fig13. Le systime d'information soumis a deux Nature de contraintes

Système d'information
d'entreprise

Contraintes
Techniques

Le processus unifié utilise le langage UML pour la création des plans d'élaboration et de construction du système logiciel. En fait, UML fait partie intégrante de processus unifié : l'un et l'autre ont été développé concret il est :

· Itératif et incrémentale.

· Centré sur l'architecture.

· Conduit par les cas d'utilisation et piloté par les risques. La gestion d'un tel processus est organisée suivant 4 phases :

· Pré étude.

· Elaboration.

· Construction.

· Transition.

Les activités de développement sont défini par :

· La capture des besoins.

· L'analyse.

· La conception.

· L'implémentation.

· Le test.

Contraintes
Fonctionnelles

Capture des besois
Fonctionnels

Fig14. Le processus de développement en Y

Analyse

Conception prèliminaire

Conception dètaillèe

Codage et testes

Recette

Conception gènirique

Capture des besois
Techniques

Contraintes
Techniques

L'axiome fondateur du 2TUP consiste à constater que toute évolution imposé au système d'information peut se décomposé et se traiter parallèlement, suivant un axe fonctionnel et un axe technique.

L'étude de ces évolutions pourra être menée indépendamment, suivant les deux branches du 2TUP.

A l'issue des évolutions du modèle fonctionnel et de l'architecture technique, la réalisation du système consiste à fusionner les résultats des deux branches ; cette fusion conduit à l'obtention d'un processus de développement en forme de Y, comme illustré par la figure.

la branche gauche (fonctionnelle):

La branche fonctionnelle correspond à la tâche traditionnelle de modélisation du domaine, du problème à résoudre et des besoins des utilisateurs. On distingue deux phases :

a. Capture des besoins fonctionnels : Qui produisent le modèle des besoins focalisés sur le métier des utilisateurs.

Elle qualifie, au plus tôt le risque de produire un système inadapté aux utilisateurs :

Le niveau contexte a pour objet de définir la frontière fonctionnelle entre le système et son environnement.

Le niveau « cas d'utilisation » définit ensuite les activités attendues des différents utilisateurs par rapport au système.

b. L'analyse :

Qui consiste à étudier précisément la spécification fonctionnelle de manière à obtenir une idée de ce que va réaliser le système en terme de métier, ouvre le système pour établir la structure des objets utilisés. Le modèle d'analyse du domaine définit la structure et le comportement des objets connus dans le métier des utilisateurs du système.

Le modèle d'analyse de l'application y rajoute, suivant le mrme processus les objets qui sont connus des utilisateurs, dans le cadre de la mise en application de leur besoins.

La branche droite (architecture technique):

En effet, on a longtemps considéré que l'aspect technique se déduisait d'une manière ou d'une autre des aspects fonctionnels. ce qui a changé et que :

· Il faut faire des choix en matière de technique.

· ,Il n'y a plus nécessairement une base de données centrale unique mais des bases de données réparties qui communique entre elles.

· Il faut donc créer de toutes pièces un modèle de ces composants et de leur interaction.

a. La capture des besoins techniques :

Qui recense toutes les contraintes sur les choix de dimensionnant et la conception du système. Les outils et les matériels sélectionnés ainsi que la prise en compte des contraintes d'intégrations avec l'existant (pré requis d'architecture technique).

b.

La conception générique :

Qui définit ensuite les composants nécessaires à la construction de l'architecture technique. Cette conception est complètement indépendante des aspects fonctionnels. Elle a pour objectif de d'uniformiser et de réutiliser les mrme mécanismes pour tout un système.

L'objectif de la branche technique est

> Rassembler les besoins technique (sécurité, intégration à l'existant, ..) dans un dossier.

> Elaborer une architecture logiciell e et applicative qui réponde aux contraintes
présentées dans le dossier technique.

>

Identifier les besoins en Framework technique afin de pallier aux manques de la technologie.

> Propose des règles de développement afin d'industrialiser l'implémentation (gestion d'exception, règles de nom mage, règles de codage,..).

la branche du milieu:

ü La conception préliminaire :

Qui représente une étape délicate, car elle intègre le modèle d'analyse fonctionnelle dans l'architecture technique de manière à tracer la cartographe des composants du système à développer.

ü La conception détaillée : Qui étudie ensuite comment réaliser chaque composant.

ü L'étape de codage : Qui produit ses composants et test au fur et à mesure les unités de code

réalisées.

ü L'étape de recette : ³Qui consiste enfin à valider les fonctionnalités du système développé.

Conclusion (processus 2TUP ) : n peut dire que le processus 2TUP

> S'articule autour de l'architecture

> Propose un cycle de développement en Y

> Détaillé dans « UML en action »

> Cible des projets de toute taille

Ces points forts :

> Itératif ;

> Fait une large pla ce à la technologie et à la gestion de risque ;

> Dé finir les profils des intervenants, les livrable, les plannings, les prototypes ;
Ces points faibles :

Plutôt superficiel sur les phases situées en amont et en aval développement : capture des besoins, support, maintenance, gestion changement... Ne propose pas de documents types.