Modélisation Unifiée Et Réalisation D'un Système de Gestion Des Projets de Création Des Startups

Modélisation unifiée et réalisation d’un système de gestion des projets de création des startups
Dédicaces
C’est premièrement à mes parents que je dédie ce travail académique, Monsieur

NGOUANDA Fabrice Nelson et Mme NGOUANDA Née LOUKANOU Edine Bety. Je leur
suis profondément reconnaissant pour l’amour démontré à mon égard sur tous les plans de ma
vie. Je vous honore et je vous célèbre.
J’aimerai aussi dédier ces travaux de fin de cycle à mon grand-père paternel, Monsieur
DECKAILLAUD Pascal pour m’avoir orienté stratégiquement après l’obtention de mon bac
vers l’informatique. Je suis sincèrement reconnaissant et je vous célèbre.
Et enfin, je consacre cet ouvrage à mon directeur de mémoire, le docteur Roch Corneille
NGOUBOU pour le mentorat qu’il exerce sur moi dans le domaine de l’informatique et son
influence multifacette qu’il a eu sur mes études durant ces trois (03) solides et chargées
années d’études académiques au CFI-CIRAS et ailleurs.
NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

Remerciements
Par ces humbles mots, j’aimerai premièrement et avant tout rendre grâce mon seigneur
JESUS-CHRIST, qui la source ultime de mon intelligence et de ma sagesse et le maitre de ma
vie.
Je tiens aussi à exprimer ma profonde reconnaissance a la personne du COLONEL ALAIN
EKONDZI, directeur du Centre de Formation en Informatique du CIRAS pour son leadership
avéré et efficace au sein du Centre. Son leadership à faciliter mes années d’études
académiques et m’a permis de me former dans un environnement adéquat sans luttes et
inquiétudes. Je vous célèbre monsieur !!!
Je n’oublierais pas aussi d’honorer tous les enseignants et formateurs qui passent en cycle
Licence Informatique. J’ai bénéficié de leurs expertises, attentions et formations durant mon
parcours et sans leur excellente pédagogie, ce travail ne verrait jamais la lumière du jour. Mes
remerciements vont particulièrement à la personne du Docteur Roch Corneille NGOUBOU,
mon encadreur dans la cadre de ces travaux académiques pour sa supervision et son
approbation.
Je suis profondément reconnaissant envers les membres du Jury pour ce privilège qu’il me
cède en acceptant de juger mon travail académique.
Encore je remercie mes parents, pour leur accompagnement durant tout le long de ma
formation professionnelle et pour leurs soutiens à mon égard. J’en suis vivement touché.
A mes collègues de classes aussi, je tiens à ici exprimer ma gratitude pour la fraternité et la
collaboration qui a régné durant ce voyage.
Sommaire
Dédicaces .....................................................................................................................................
.... I
Remerciements .............................................................................................................................
.. Ii
Sommaire .....................................................................................................................................
.. iii
Listes des
figures ............................................................................................................................. V
Listes des
tableaux ......................................................................................................................... Vi

Abréviations et sigles ...................................................................................................................

Vii
Introduction ..................................................................................................................................
... 1
PARTIE 1 : PRÉSENTATION DE LA STRUCTURE
D’ACCUEILLE ....................................... 1
Chapitre 1 : Présentation de la
structure .......................................................................................... 2
1.1.
Historique .....................................................................................................................................
.......... 3
1.2.
Mission .........................................................................................................................................
........... 4
1.3. Organisation
générale ....................................................................................................................... 4
1.4. Organigramme
général ..................................................................................................................... 4
1.5. Attributions des structures de l’organigramme
général ...................................................... 7
1.6. Chiffres
caractéristiques ................................................................................................................ 10
Chapitre 2 : Situation
informatique ............................................................................................... 12
2.1. Organisation
informatique ........................................................................................................... 12
2.2. Matériel
informatique .................................................................................................................... 12
2.3. Applications
Informatiques .......................................................................................................... 13
Chapitre 3 : Présentation du domaine
d’étude .............................................................................. 14
3.1. Contexte du
domaine ...................................................................................................................... 14
3.2. Problématique du
sujet .................................................................................................................. 14
3.3. Intérêts du
sujet ................................................................................................................................ 14

3.4. Concepts liés au

sujet ...................................................................................................................... 15
PARTIE 2 : ANALYSE ET
CONCEPTION .................................................................................. 7
Chapitre 4 : Approche
méthodologique......................................................................................... 16
4.1. Langage de
modélisation ............................................................................................................... 16
4.2. Présentation
d’UML ......................................................................................................................... 17
4.3. Les types de diagrammes
d’UML ................................................................................................ 18
4.4. Le processus de
Développement ................................................................................................ 21
4.5. Présentation du Processus Unifié
(UP) .................................................................................... 23
4.6. Présentation du Processus 2TUP (Twa Track Unified) .....................................................
24
4.7. 2TUP et
UML ...................................................................................................................................... 26
Chapitre 5 : Étude de
l’existant ..................................................................................................... 27
5.1. Description des
activités ............................................................................................................... 27
5.2. Critique de
l’existant ....................................................................................................................... 28
5.3. Proposition des
solutions .............................................................................................................. 30
5.4. Choix de la
solution ......................................................................................................................... 30
Chapitre 6 :
Analyse ...................................................................................................................... 31
6.1. Analyse des
besoins ......................................................................................................................... 31
6.2. Spécification
fonctionnelle ........................................................................................................... 32
6.3. Spécification
détaillée ..................................................................................................................... 43
Chapitre 7 :
Conception ................................................................................................................. 53

7.1. Réalisation des cas

d’utilisation .................................................................................................. 53
7.2. Diagramme de classe du
système .............................................................................................. 58
7.3. Conception
architecturale ............................................................................................................. 65
Chapitre 8 :
Implémentation .......................................................................................................... 68
8.1. Environnements techniques de développement .................................................................
68
8.2. Diagramme de
déploiement ......................................................................................................... 71
8.3. Production du
logiciel ..................................................................................................................... 73
8.4. Présentation des interfaces (les captures d’écrans de l’application) ........................... 77
Conclusion ...................................................................................................................................
.. 82
Table des
matières .......................................................................................................................... A
Bibliographie ...............................................................................................................................
... D
Introduction

Dans le monde en constante évolution de l'innovation et de l'entrepreneuriat, les mécanismes

de financement et de soutien jouent un rôle crucial dans le développement de startups
prometteuses. Le Centre d’Encadrement Technologique, Universitaire et Professionnel
(CETUP) se positionne comme un acteur majeur dans la promotion de l'entrepreneuriat en
offrant des formations professionnelles et des financements précieux aux jeunes en herbe.
Pour optimiser cette initiative, il est impératif de mettre en place un système de gestion
efficace, capable de gérer les financements octroyés par les partenaires du CETUP et
d'orchestrer les appels à formation visant à réaliser la création de startups financées par cet
organisme.
C’est dans ce contexte qu’il m’a été proposé en vue de mes travaux de fin de cycle de réaliser
une application de gestion des financements octroyés et des projets de création des
startups pour le compte du Centre d’Encadrement Technologique, Universitaire et
Professionnel (CETUP).
Pour la réalisation de mon travail, j’ai porté le choix sur la démarche 2TUP joint au langage
de modélisation UML.
Ce travail est structuré en deux parties :
 La première partie est conçu pour la présentation de la structure d’accueil.
 La deuxième partie a conçu pour la description du déroulement du stage

PARTIE 1 : PRESENTATION DE LA STRUCTURE

D’ACCEUILLE
Chapitre 1 : Présentation de la structure

DIRECTEUR GENERAL
ASSISTANTE DU
DIRECTEUR
Responsable
Technologiques
avancées des Big Data
et Analyse
Responsable des Responsable des
des Données
encadrements encadrement Génie
réseaux et systèmes Logiciel
ET

Chapitre 3 : Présentation du domaine d’étude
3.1. Contexte du domaine
Le contexte de cette étude repose sur la nécessité croissante de promouvoir l'entrepreneuriat et

l'innovation au sein des institutions éducatives et de soutenir la création de start-ups parmi les
étudiants en vue de résoudre l’épineux problème de l’employabilité que face notre génération.
Dans cette perspective, le Centre d’Encadrement Technologique, Universitaire et
Professionnel (CETUP) veut jouer sa partition en acquérant des partenariats de financements
pour organiser des formations professionnelles et des projets de créations de start-ups pour
faciliter l’insertion professionnelle des jeunes.
Cependant, la gestion de ces financements octroyés ainsi que le déroulement des formations
professionnelles et la réalisation des projets de créations de start-ups peuvent rapidement
devenir complexes et nécessitent la mise en place d’une solution informatique. Les défis
auxquels le CETUP est confronté comprennent la gestion des appels à la formation, le
traitement des dossiers de candidatures, la gestion des demandes de financements et le
processus de créations des startups sponsorisés.

C'est dans ce contexte que nait la nécessité de concevoir et de mettre en place une application
web dédiée à la gestion des financements octroyés et des projets de créations de start-ups pour
le CETUP. Cette application vise à digitaliser et à automatiser les processus de gestion et
d’élaborer quelques outils d'évaluation performants, et à offrir une plateforme de suivi
transparente pour toutes les parties prenantes.
Ce projet de conception et de mise en place de l'application web représente une réponse à un
besoin crucial dans un contexte éducatif et entrepreneurial constante évolution, et il offre
l'opportunité de contribuer à l'essor de l'innovation et de l'entrepreneuriat par offrant aux
jeunes sans emploi de poser leurs candidatures sur la plateforme suite aux appels à formation
qui y seront publiés. Il permettra aussi au CETUP de gérer les formations organisées, les
financements octroyés auprès de ses partenaires ainsi que les finalistes et les décrochages.
3.2. Problématique du sujet

Comment concevoir, développer et mettre en place une application web de gestion des
financements octroyés et des projets de créations de startup pour le CETUP, tout en répondant
aux besoins spécifiques de cette institution, en garantissant la sécurité et la confidentialité des
données et permettant aux intéressés de déposer leur candidature avec facilité ?
3.3 Concepts liés au sujet
o Start-up : organisation temporaire à la recherche d'un business model industrialisable,

rentable et permettant la croissance (Steve Blank,
https://bpifrance-creation.fr/moment-de-vie/quest-ce-quune-startup)
o Financement : argent octroyé au CETUP par ses partenaires pour réaliser des
formations et sponsoriser les projets de création de startup ;
o Système : En informatique, un système désigne l’ensemble d’éléments en interaction
dynamique organisés, en fonction d’un but à atteindre ;
o Système d’information : est un ensemble de ressources et de dispositifs permettant de
collecter, stocker, traiter et diffuser les informations nécessaires au fonctionnement
d’une organisation. (Https://payfit.com/fr/fiches-pratiques/systeme-information)
o Système Informatique : est un sous-ensemble du système d’information. Il regroupe
l’ensemble des moyens informatiques nécessaires au traitement de l’information :
ordinateurs, programmes, réseau, logiciels, etc. (Https://payfit.com/fr/fiches-
pratiques/systeme-informatique)
o Application web : désigne un logiciel applicatif hébergé sur un serveur et accessible
via un navigateur web.
o Serveur Web : Un serveur web est soit un logiciel de service de ressources web
(serveur HTTP), soit un serveur informatique (ordinateur) qui répond à des requêtes
du World Wide Web sur un réseau public (Internet) ou privé (intranet), en utilisant
principalement le protocole http ;
o Architecture logicielle : l’architecture logicielle décrit d’une manière symbolique et
schématique les différents éléments d’un ou de plusieurs systèmes informatiques, leurs
interrelations et leurs interactions.

PARTIE 2 : ANALYSE ET CONCEPTION

Chapitre 4 : Approche méthodologique
L’approche méthodologique décrit le stage de conception d’une étude ou d’un projet. Elle
englobe l’ensemble des méthodes et procédures utilisées pour collecter, analyser et interpréter
les données dans le contexte d’un projet informatique.
4.1. Le Langage de Modélisation
Un langage de modélisation en informatique est un langage utilisé pour créer des modèles
informatiques conceptuels qui représentent les différents aspects d'un système, d'un processus,
ou d'une structure de données. Ces modèles peuvent servir à analyser, concevoir, documenter
et communiquer des informations complexes de manière plus compréhensible et graphique.
Les langages de modélisation sont couramment utilisés dans le domaine de l'ingénierie
logicielle, de la conception de systèmes, et dans d'autres domaines informatiques pour
visualiser et spécifier des concepts et des solutions.
En effet, Un langage de modélisation est un langage artificiel qui peut être utilisé pour
exprimer de l'information ou de la connaissance ou des systèmes dans une structure qui est
définie par un ensemble cohérent de règles( https://fr.wikipedia.org/wiki/Langage). Il peut être
graphique ou textuel.
Voici quelques exemples de langage de modélisation populaire en Informatique :
1. UML (Unified Modeling Language) : Utilisé pour la modélisation de systèmes

logiciels. Il comprend des diagrammes de classes, de séquence, d'activité, etc., pour
représenter des aspects différents du logiciel.
2. ERD (Entity-Relationship Diagrams) : Utilisé pour modéliser des bases de données
relationnelles en représentant les entités, les relations et les attributs.
3. BPMN (Business Process Model and Notation) : Utilisé pour modéliser les
processus métier, en représentant les étapes, les flux, les acteurs, et les décisions dans
les diagrammes de processus.

4. SysML (Systems Modeling Language) : Utilisé pour la modélisation de systèmes

complexes, en particulier dans l'ingénierie des systèmes. Il étend UML pour englober
les aspects systèmes.
5. SDL (Specification and Description Language) : Utilisé pour modéliser la
spécification formelle de systèmes de communication.
Dans le cadre de notre travail et en fonction des connaissances acquises pendant notre
formation, nos travaux de conception et de modélisation seront faits avec le Langage UML.
4.2 Présentation d’UML
Le Langage de Modélisation Unifié, de

l'anglais Unified Modeling Language (UML), est
un langage de modélisation graphique à base
de pictogrammes conçu comme une méthode
normalisée de visualisation dans les domaines
du développement logiciel et en conception
orientée objet.
UML est une synthèse de langage de modélisation objet antérieurs : Booch, OMT,
OOSE. Principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar
Jacobson, UML est à présent un langage standard adopté par l'Object Management
Group (OMG). UML 1.0 a été normalisé en janvier 1997 ; UML 2.0 a été adopté UML
est destiné à faciliter la conception des documents nécessaires au développement d'un
logiciel orienté objet, comme standard de modélisation de l'architecture logicielle.
UML est actuellement à sa version 2.5.1 d'après OMG. Il pour objectif de fournir un
langage graphique commun et unifié pour la conception, la modélisation et la
documentation des systèmes logiciels, qu'il s'agisse d'applications simples ou
complexes. Il est largement utilisé dans en génie logiciel pour documenter les
systèmes, modéliser et conceptualiser les processus métiers. A travers UML, nous
pouvons décrire graphiquement la structure et les comportements du futur système.
UML occupe une place significative dans le génie logiciel aujourd'hui. Il est utilisé pour la
communication visuelle, la documentation, la conception, la génération de code, les tests,
l'analyse de systèmes existants et peut être intégré dans diverses méthodologies de
développement.
Les deux termes importants d’UML sont :

 Le formalisme : UML est un langage de modélisation, la version actuelle d’UML est

la 2.5, composée de 14 types de diagrammes dont sept structurels et sept
comportementaux. À titre de comparaison, UML 1.3 comportait 25 types de
diagrammes. UML n'étant pas une méthode, l'utilisation des diagrammes est laissée à
l'appréciation de chacun.
 L’utilisation : UML est destiné à faciliter l’élaboration des documents nécessaires au
développement d'un logiciel par l’approche orienté objet. Il est considéré comme
standard de modélisation de l'architecture logicielle orienté objet. Les différents
éléments représentables sont :
Activité d'un objet/logiciel
 Acteurs
 Processus
 Schéma de base de données
 Composants logiciels
 Réutilisation de composants.
A partir des documents réalisés, il existe une possibilité de génération des parties de codes
utilisables lors de l’implémentation.
4.3. La notion de diagramme en UML
En UML, le diagramme est un ensemble d'éléments graphiques qui décrivent le contenu des
vues.
UML offre un ensemble de diagrammes standard qui permettent ingénieurs logiciels de
représenter graphiquement différents aspects d'un système.
UML définit 9 types de diagrammes repartis dans deux catégories de vues : vues statiques et
vues dynamiques.
4.3.1. Les vues
 Les vues sont les observables du système. Elles décrivent le système d'un point de vue
donné, qui peut être organisationnel, dynamique, temporel, architectural,
géographique, logique, etc. En combinant toutes ces vues, il est possible de définir (ou
retrouver) le système complet. En UML il existe deux (2) types de vues :
 Les vues statiques : se réfèrent à la représentation statique ou structurelle d'un
système logiciel. Elles permettent de modéliser les composants et les entités du
système, ainsi que leurs relations, sans tenir compte de l'aspect dynamique de leur
fonctionnement. Les principaux diagrammes UML qui sont utilisés pour décrire la vue
statique d'un système sont les suivants :

 Le diagramme de cas d’utilisation : ce diagramme est destiné à représenter les

besoins des utilisateurs par rapport au système. Il constitue un de diagrammes le plus
structurants dans l’analyse d’un système.
 Le diagramme de classe : ce diagramme présente la description

statique du système. C’est une représentation des classes qui sont formées à partir d’un
couplage des données et de traitements. C’est le diagramme pivot de
l’ensemble de la modélisation du système.
 Le diagramme d’objet : permet de représenter les instances des classes, c'est-à-dire
des objets. Comme le diagramme de classes, il exprime les relations qui existent entre
les objets, mais aussi l'état des objets, ce qui permet d'exprimer des contextes
d'exécution.
 Le diagramme de composant : il représente la structure des composants logiciels et

leurs relations, aidant à modéliser l'architecture du système.
 Le diagramme de déploiement : ce diagramme décrit l’architecture technique d’un

système avec une vue centrée sur la répartition des composants dans la configuration
d’exploitation.
 Les vues dynamiques : Elles se réfèrent à la représentation du comportement et des
interactions en temps réel d'un système logiciel. Contrairement à la vue statique qui se
concentre sur la structure et les relations entre les éléments du système, la vue
dynamique met en évidence comment les objets, les composants et les classes
interagissent et évoluent pendant l'exécution du système. Voici quelques-uns des
principaux diagrammes UML utilisés pour représenter la vue dynamique :
▪ Le diagramme de communication : c’est une représentation simplifiée d'un
diagramme de séquence qui s’accentue sur les échanges de messages entre les
objets. En fait, le diagramme de séquence et le diagramme de communication sont
deux vues différentes mais logiquement équivalentes (on peut construire l'une à
partir de l'autre) d'une même chronologie, ils sont dits isomorphes.
▪ Le diagramme d’état-transition : ce diagramme montre les différents états des

objets en réaction aux évènements.

▪ Le diagramme d’activité : c’est le diagramme comportemental d'UML,

permettant de représenter le déclenchement d'événements en fonction des états du
système et de modéliser des comportements parallélisables (multi-threads ou
multiprocessus). Le diagramme d'activité est également utilisé pour décrire un flux
de travail.
▪ Le diagramme de séquence : Il modélise l'interaction entre les objets au fil du
temps. Il montre la séquence des messages échangés entre les objets et comment le
système réagit aux événements au fil du temps.
4.3.2. Les modèles d’éléments
Les modèles d'éléments sont les éléments graphiques des diagrammes UML tels que :
les acteurs, les classes, etc.
4.4. Le Processus de Développement

Un processus de développement définit une séquence d'étapes ordonnées qui permet
de produire un logiciel ou d’en faire évoluer. Un processus est décomposé suivant les deux
axes suivants :
 Axe de Développement Technique : Cet axe se concentre sur les aspects liés à
la technologie, à l'architecture et à l'implémentation du logiciel. Il inclut le
choix des technologies, la conception du système, la création du code source,
les tests techniques et l'optimisation. Cet axe vise à garantir que le logiciel est
techniquement solide et qu'il répond aux exigences techniques.
 Axe de Gestion du Développement : Cet axe se concentre sur la planification,
la coordination, le suivi et le contrôle de l'ensemble du processus de
développement. Il englobe la gestion des ressources, la communication, la
gestion des risques, la livraison et le déploiement du logiciel. Cet axe vise à
garantir que le projet se déroule de manière organisée, respecte les délais et
reste conforme aux objectifs du projet.

Figure 2 : Cycle en V général par niveau de décomposition
4.5. Présentation du Processus Unifié (UP)

Le processus unifié (Unified Processus en anglais) est un processus de développement piloté
par les cas d’utilisation, centré sur l’architecture, itératif et incrémental (Le processus unifié
de développement Traduit par V. Zaïm de The Unified Software Development Process I.
Jacobson, G. Booch, J. Rumbaugh c/o Eyrolles, 2000 ISBN 2-212-09142-7).
C’est un processus de développement qui divise le projet en cycles de développement répétés
et met l'accent sur la gestion de projet, la qualité et la communication. Le PU favorise
l'architecture centrale, la modélisation et la réutilisation de composants.
Le Processus Unifié est principalement caractérisé par son adaptabilité. L'adaptabilité du
Processus Unifié permet aux équipes de développement de personnaliser et d'ajuster la
méthodologie pour répondre aux besoins spécifiques de leur projet. Cela inclut la flexibilité
dans les phases, les artefacts, les rôles, la planification, et la possibilité d'incorporer d'autres
méthodologies. Cela en fait un modèle de développement logiciel polyvalent et adaptable.
Le processus unifié est une méthode de développement de logiciel caractérisée par les points
suivants :
 Centré sur l'architecture : dès le démarrage du processus, on aura une vue sur
l'architecture à mettre en place. L'architecture d'un système logiciel peut être décrite
comme les différentes vues et structures du système qui doit être construit.
L'architecture logicielle équivaut aux aspects statiques et dynamiques les plus
significatifs du système. L'architecture émerge des besoins de l'entreprise, tels qu'ils

sont exprimés par les utilisateurs et autres intervenants et tels qu'ils sont reflétés par
les cas d'utilisation.
 Utilisation de cas d'utilisation : Les cas d'utilisation jouent un rôle central dans le
Processus Unifié. Ils sont utilisés pour capturer les besoins du système du point de vue
de l'utilisateur, ce qui facilite la communication entre les parties prenantes et l'équipe
de développement.
 Le processus unifié est itératif et incrémental : le développement d'un produit
logiciel est vaste et peut s'étendre sur une période plus ou moins courte.
 Rôles définis : Le Processus Unifié définit des rôles clés dans le développement
logiciel, tels qu’analyste, développeur, testeur, chef de projet, architecte, etc. Chaque
rôle a des responsabilités spécifiques dans le processus.
 Utilisation de modèles : Le Processus Unifié encourage l'utilisation de modèles pour
représenter les différents aspects du projet, y compris les diagrammes UML, les
modèles de données, les modèles de conception, etc.
Le processus unifié automatise les processus métiers. Il vise ainsi à assurer un cycle de
développement avec des enchaînements d'activités systématiques et répétables basés sur des
artefacts bien définis, tout en facilitant l'intégration de nouvelles personnes dans les équipes.
La méthode considère en outre que le produit est constitué non seulement du code, mais aussi
de tous les éléments contribuant à la pérennité et aux évolutions ultérieures du logiciel. La
méthode considère en outre que le produit est constitué non seulement du code, mais aussi de
tous les éléments contribuant à la pérennité et aux évolutions ultérieures du logiciel. L'objectif
principal d'un système logiciel est de rendre un service à ses utilisateurs, il faut par
conséquent comprendre les désirs et les besoins des utilisateurs du futur système.
Certaines variantes du processus UP sont :
● RUP (Rational Unified Process)

● XUP (eXtreme Unified Process)
● AUP (Agile Unified Process)
● 2TUP (two Tracks Unified Process)
● EssUP (Essential Unified Process)
Il est clair que le processus unifié est un processus de développement complet. Il fournit une
architecture solide du produit demandé et permet de répondre aux besoins des utilisateurs.
Son découpage en cycle permet un meilleur suivi et une maîtrise du processus de
développement.
Ces différents cycles s'articulent en 4 phases : création, élaboration, construction et transition,
chacune d’elles se subdivisent à son tour en itérations.

 Création (Inception) : la création traduit une idée en vision de produit fini et

présente l'étude de rentabilité pour ce produit. Elle répond à un certain nombre de
questions : Que va faire le système pour les utilisateurs ? A quoi peut ressembler
l'architecture d'un tel système ? Quels sont l'organisation et les coûts du
développement de ce produit ? C'est à ce niveau où les principaux cas d'utilisation
seront spécifiés. L'identification des risques majeurs, la mise sur place d'une
architecture provisoire du système à concevoir et la préparation de la phase
d'élaboration seront les principales tâches à effectuer durant cette étape de la création.
 Elaboration : Elle permet de préciser la plupart des cas d'utilisation et de concevoir

l'architecture du système. L'architecture doit être exprimée sous forme de vue de
chacun des modèles. Lors de cette phase une architecture de référence sera conçue.
Au terme de cette étape, le chef de projet doit être en mesure de prévoir les activités
et d'estimer les ressources nécessaires à l'achèvement du projet.
 Construction : C'est le moment où l'on construit le produit. L'architecture de

référence est convertie en produit complet. Le produit contient tous les cas
d'utilisation que le chef de projet, en accord avec les utilisateurs a décidé de mettre au
point pour cette version. Celle-ci doit encore avoir des anomalies qui peuvent être en
partie résolue lors de la phase de transition.
 Transition : Le produit est en version bêta. Un groupe d'utilisateurs essaye le
produit et détecte les anomalies et défauts. Cette phase suppose des activités comme
la fabrication, la formation des utilisateurs clients, la mise en œuvre d'un service
d'assistance et la correction des anomalies constatées.
4.6 Présentation du Processus 2TUP (Two Track Unified)
2TUP est un processus qui est suit le processus unifié et qui a pour but d'apporter une solution
aux contraintes de changement fonctionnelles et techniques qui s'imposent aux systèmes
d'information. 2TUP propose un cycle de développement qui sépare les aspects techniques des
aspects fonctionnels. Cette séparation permet de gérer et de traiter toute évolution du système
information suivant deux différents axes : une gestion selon l’axe technique et une gestion
selon l’axe fonctionnel. Par conséquent, il est distingué par deux branches, une branche
technique et une branche fonctionnelle, dont les différents résultats respectifs fusionnés
ensemble forment le système à réaliser. C’est pourquoi c’est un processus de développement
en Y comme l'illustre la figure suivante (cf. Figure 4).
L’étude préliminaire constitue la première étape du processus 2TUP. Cette étude constitue à
d'identifier les acteurs qui vont interagir avec le système, les messages qu'échangent les
acteurs et le système, puis à produire un cahier de charges et enfin à modéliser le contexte : le

système est une boîte noire, les acteurs l'entourent et sont reliés à lui, sur l'axe qui lie un
acteur au système on met les messages que les deux s'échangent avec le sens de l’orientation.
Le processus 2TUP est régie par trois (03) principales composantes à savoir : une branche
fonctionnelle, une branche technique et une phase de réalisation.
Figure 4 : Vision du processus de développement 2TUP
La branche fonctionnelle capture la connaissance du métier de l’entreprise. Cette branche

identifie les besoins fonctionnels, ce qui permettra de produire un modèle centré sur le métier
des utilisateurs finaux.
La branche technique capitalise un savoir-faire technique et/ou des contraintes techniques.
Les techniques développées par le système le sont indépendamment des fonctions à réaliser.
La phase de réalisation consiste à fusionner les deux branches, permettant de mener une
conception applicative et enfin la livraison d’une solution conforme au besoin.
4.7. Le processus 2TUP et le langage de modélisation UML
Le processus 2 Track Unified Process (2TUP) s’appuie sur UML tout au long du cycle
de développement, car les différents diagrammes de ce dernier permettent de bien
modéliser le système d’information. [Référence à vérifier]
UML est un langage de modélisation graphique et textuel destiné à faire comprendre et
décrire des besoins, spécifier, concevoir des solutions et communiquer des points de vue.
UML unifie à la fois les notations et les concepts orientés objet. Il ne s'agit pas d'une
simple notation, mais les concepts illustrés par un diagramme ont une sémantique

précise et sont porteurs de sens au même titre que les mots d'un langage. Il sied de
bien noté qu’UML n’est pas une méthode comme le suggèrerait la confusion qui nait
lors de l’élucidation de ses caractéristiques.
UML unifie également les notations nécessaires aux différentes activités d'un processus de
développement et offre, par ce biais, le moyen d'établir le suivi des décisions prises, depuis la
définition des besoins jusqu'au codage. (Roques, 2006)
Le diagramme de cas d'utilisation : Représente la structure des fonctionnalités
nécessaires aux utilisateurs du système. Il est normalement utilisé lors des étapes de
capture des besoins fonctionnels et techniques.
Le diagramme de contexte statique : Délimite le domaine d'étude en précisant ce qui
est à la charge du système et en identifiant l'environnement extérieur au système étudié
avec lequel ce dernier communique.
Le diagramme de classes : Sûrement l'un des diagrammes les plus importants dans un
développement orienté objet. Sur la branche fonctionnelle, ce diagramme est prévu
pour développer la structure des entités manipulées par les utilisateurs. En conception,
le diagramme de classes représente la structure d'un code orienté objet.
Le diagramme de séquence : Représente les échanges de messages entre objets, dans le
cadre d'un fonctionnement particulier du système.
Le diagramme d’activité : Représente les règles d’enchaînement des activités et actions dans
le système. Il peut être assimilé comme un algorithme mais schématisé.
Le diagramme de déploiement : Est une vue statique qui sert à représenter
l'utilisation de l'infrastructure physique par le système et la manière dont les
composants du système sont répartis ainsi que leurs relations entre eux.
Chapitre 5 : Analyse
5.1. Analyse du besoin
L’analyse du besoin permet d’identifier toutes les fonctionnalités du système. Dans

cette partie, deux types de besoins seront détaillés : Les besoins fonctionnels (les
taches que permet d’accomplir le logiciel) et les besoins techniques (les
fonctionnalités proposées par le logiciel pour accomplir les tâches).
5.1.1. Les besoins fonctionnels
Les besoins fonctionnels décrivent les fonctionnalités spécifiques et les opérations que le
logiciel doit être en mesure d'accomplir pour répondre aux objectifs de l'utilisateur. Ce sont

les besoins spécifiant un comportement d’entrée/sortie du système. Dans notre cas, le système
devra permettre aux utilisateurs d'effectuer les tâches suivantes :
● La gestion des demandes de financement ;

● La gestion des publications des offres de formations ;
● La gestion des partenaires techniques et financiers ;
● La gestion des dossiers de candidatures ;
● La gestion des formations et formateurs ;
● La gestion des projets de création des start-ups ;
5.1.2. Les besoins techniques
Les besoins techniques, également appelés besoins non fonctionnels, décrivent les exigences
techniques, les contraintes et les spécifications que le logiciel doit respecter pour fonctionner
de manière efficace, sécurisée et évolutive. Ils complètent les besoins fonctionnels en
définissant les paramètres techniques dans lesquels le logiciel doit opérer. Les différents
besoins techniques recensés sont :
● La sécurité des données : Assurer la sécurité des données personnelles des candidats
et des informations sensibles liées aux formations
● L’ergonomie : l'application doit être facile à utiliser. Il doit présenter un enchaînement
logique entre les interfaces et un texte compréhensible, visible et lisible.
● Disponibilité : Le système doit garantir des temps de réponse relativement court au

moment de l’authentification et du traitement des informations ;
● L’accès à la partie administration et utilisateur doit être sécurisé et authentifié.

5.1.3. Spécifications fonctionnelles
5.1.3.1 Identification des acteurs
Un acteur est un rôle joué par une entité qui interagit avec le système à
modéliser. L'acteur est toujours externe à ce système et peut être identifié
comme un humain, un logiciel, un matériel, ou un autre système. Un acteur ne
représente pas toujours une entité physique spécifique, mais un rôle pertinent
dans la spécification des cas d'utilisation du système. Ainsi, une entité physique
peut jouer le rôle de plusieurs acteurs.
Formalisme :

Figure 5 : Représentation d’un acteur en UML

Les acteurs qui participent à notre système sont :
 Administrateur : L'administrateur joue un rôle central dans le système, responsable de
la gestion globale. Il crée et gère les sessions de formation, supervise les partenariats
et les financements. De plus, l'administrateur a le pouvoir de valider ou rejeter les
candidatures, assurant le bon déroulement du processus de création de startups.
 Candidat: Peut soumettre une candidature. Accède à des informations sur les sessions
de formation et peut suivre l'état d'avancement de sa candidature.
 Formateur : c’est un utilisateur authentifié qui peut accéder aux details de la session de
formation et ajouter des ressources pédagogiques
 Statupeur : c’est le candidat qui a été retenu. Il peut accéder aux ressources
pédagogiques.
5.1.3.2 Diagramme de contexte statique
Le diagramme de contexte statique délimite le domaine d'étude en précisant ce qui est à la
charge du système et en identifiant l'environnement extérieur au système étudié avec lequel ce
dernier communique. On représente les interactions des acteurs avec le système étudié, mais
pas les interactions entre acteurs.
Ses composants sont :
- Les acteurs externes
- Un processus unique symbolisant le système d’information étudié
- Echange entre le système étudié et son environnement.
SYSTEME
FORMAT EUR
CANDIDAT
ST ART UPEUR
ADMINIST RAT EUR

Figure 6 : Diagramme de contexte statique
5.2.3. Identification des cas d’utilisations

Un cas d'utilisation (use case) est une technique de modélisation qui représente une
interaction entre le système et un ou plusieurs acteurs (utilisateurs ou autres systèmes
externes). Un cas d'utilisation décrit comment un acteur interagit avec le système pour
atteindre un objectif spécifique.Il modélise donc un service rendu par le système sans pour
autant imposer le mode de réalisation de ce service.
Figure 7 : Représentation d’un cas d’utilisation en UML
Pour notre système , les cas d’utilisations retenues sont :

 Gérer les Sessions de Formation :
Permet à l'administrateur du CETUP de créer, modifier ou supprimer des sessions de
formation.
Permet aux formateurs de visualiser et mettre à jour les détails des sessions de formation.
 Lancer un Appel à Candidatures :
Permet à l'administrateur de lancer un appel à candidatures pour une session de formation
spécifique.
 Soumettre une Candidature :
Permet aux candidats de soumettre une candidature en réponse à un appel.
 Traiter les Candidatures :
Permet à l'administrateur de traiter les candidature c’est-à-dire les valider ou les rejeter.
 Gestion les Startups :
Permet à l'équipe du CETUP d’identifier les startups crées.
 Visualiser les Sessions et Ressources :

Permet aux candidats, formateurs, et startupers de visualiser les informations sur les sessions
de formation et les ressources disponibles.
 Gérer les Financements :
Permet à l'administrateur de gérer les informations liés aux financements reçus
 Suivre l'Évolution d'une Candidature :
Permet aux candidats de suivre l'état d'avancement de leur candidature.
 Gérer les Partenariats :
Permet à l'administrateur de gérer ses partenaires de financement.
 Rapports Statistiques :
Permet à l'administrateur de générer des rapports statistiques sur les candidatures, les
formations, et les startups créées.
Notons ici que Gérer englobe les cas d’utilisation : Ajouter, Supprimer, Modifier.
5.2.4. Relation entre les cas d’utilisation (Use Case) :

Les relations entre les cas d’utilisation ont pour but de décomposer les systèmes en
fonctionnalités à granularité plus fine. Il existe trois (3) types de relations entre Use
Case:
● L’inclusion, l’héritage et l’extension.
L’inclusion : Relation stéréotypée « include » entre cas d’utilisation : le cas

d’utilisation de base en incorpore explicitement un autre, de façon obligatoire,
à un endroit spécifié dans ses enchaînements.
Formalisme :
Figure 8 : Représentation d’une relation d’inclusion en UML
● L’extension : Relation stéréotypée « extend » entre cas d’utilisation : le cas

d’utilisation de base en incorpore implicitement un autre, de façon optionnelle, à un
endroit spécifié Indirectement dans celui qui procède à l’extension
Formalisme :

Figure 10 : Représentation d’une relation d’extension en UML
● L’héritage : Mécanisme par lequel des éléments plus spécifiques récupèrent

automatiquement la structure et le comportement d’éléments plus généraux ;
principale technique de réalisation de la généralisation.
Formalisme :
Figure 11 : Représentation d’une relation de généralisation en UML
Classification par package :

En UML, les packages offrent une méthode structurée pour organiser les éléments d'un
système. Ils favorisent la modularité, facilitent la gestion des dépendances, offrent des
niveaux d'abstraction. Les packages améliorent la visibilité, la cohérence, et facilitent
l'analyse des dépendances, rendant la modélisation et la compréhension des systèmes plus
efficaces.
Un package peut contenir la plupart des éléments UML : classes, objets, cas
d'utilisations, composantes, etc. Il peut également contenir d'autres packages, selon
une organisation hiérarchique.
L'intérêt des packages est de permettre de structurer les diagrammes et de donner une vision
globale plus claire.
Ainsi notre système a été decomposé en plusieurs packages parmis lesquelles nous avons :

Package : Gestion des Sessions de Formation
F
i
g
u
r
e
12 : Diagramme de cas d’utilisation « Gestion de sessions de formation»
Package : Gestion des Candidatures

Package : Gestion des Startups

Acteurs : Administrateur
Cas d'Utilisation Description

Ajouter les details des startups Permet à l’utilisateur d’enregistrer les details sur les
crées startups crées.
Modifier les details des startups Permet à l’utilisateur de modifier les details des
Supprimer les details des startups Permet à l’utilisateur de supprimer les details des
Package : Gestion des Ressources et Informations

Acteurs : Administrateur , Candidat
Visualiser la session Permet à l’utilisateur de visualiser les informations de la session
de formation de formation
Visualiser ressource Permet à l’utilisateur de visualiser les ressources pédagogiques de
pédagogiques la session de formation
Visualiser l’historique Permet à l’utilisateur de visualiser l’historique de participation aux
de participation sessions de formations

Demander une Permet a l’utilisateur de soumettre des demandes spécifiques pour

ressource pédagogique des ressources pédagogiques qui ne sont pas encore disponibles
dans le système.
Package : Gestion Administrative

Acteurs : Administrateur , Candidat
Ajouter les details d’un Permet à l’utilisateur d’ajouter les informations sur un
financement financement reçu
Modifier les details d’un Permet à l’utilisateur de modifier les informations d’ un
Supprimer les details d’un Permet à l’utilisateur de supprimer les informations d’ un
Ajouter un partenariat Permet à l’utilisateur d’enregistrer les details sur un
partenariat financier
Modifier un partenariat Permet à l’utilisateur de modifier les details d’un
Supprimer un partenariat Permet à l’utilisateur de supprimer les details d’un
Rapports Statistiques Permet à l'administrateur de générer des rapports
statistiques sur les données.

Modélisation Unifiée Et Réalisation D'un Système de Gestion Des Projets de Création Des Startups

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Modélisation Unifiée Et Réalisation D'un Système de Gestion Des Projets de Création Des Startups

Transféré par

Droits d'auteur :

Formats disponibles

Modélisation unifiée et réalisation d’un système de gestion des projets de création des startups

C’est premièrement à mes parents que je dédie ce travail académique, Monsieur

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

Abréviations et sigles ...................................................................................................................

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

3.4. Concepts liés au

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

7.1. Réalisation des cas

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

Dans le monde en constante évolution de l'innovation et de l'entrepreneuriat, les mécanismes

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

PARTIE 1 : PRESENTATION DE LA STRUCTURE

Chapitre 1 : Présentation de la structure

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

Chapitre 3 : Présentation du domaine d’étude

3.1. Contexte du domaine

Le contexte de cette étude repose sur la nécessité croissante de promouvoir l'entrepreneuriat et

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

3.2. Problématique du sujet

3.3 Concepts liés au sujet

o Start-up : organisation temporaire à la recherche d'un business model industrialisable,

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

PARTIE 2 : ANALYSE ET CONCEPTION

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

Chapitre 4 : Approche méthodologique

4.1. Le Langage de Modélisation

Voici quelques exemples de langage de modélisation populaire en Informatique :

1. UML (Unified Modeling Language) : Utilisé pour la modélisation de systèmes

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

4. SysML (Systems Modeling Language) : Utilisé pour la modélisation de systèmes

Le Langage de Modélisation Unifié, de

Les deux termes importants d’UML sont :

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

 Le formalisme : UML est un langage de modélisation, la version actuelle d’UML est

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

 Le diagramme de cas d’utilisation : ce diagramme est destiné à représenter les

 Le diagramme de classe : ce diagramme présente la description

 Le diagramme de composant : il représente la structure des composants logiciels et

 Le diagramme de déploiement : ce diagramme décrit l’architecture technique d’un

▪ Le diagramme d’état-transition : ce diagramme montre les différents états des

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

▪ Le diagramme d’activité : c’est le diagramme comportemental d'UML,

4.4. Le Processus de Développement

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

Figure 2 : Cycle en V général par niveau de décomposition

4.5. Présentation du Processus Unifié (UP)

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

● RUP (Rational Unified Process)

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

 Création (Inception) : la création traduit une idée en vision de produit fini et

 Elaboration : Elle permet de préciser la plupart des cas d'utilisation et de concevoir

 Construction : C'est le moment où l'on construit le produit. L'architecture de

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

Figure 4 : Vision du processus de développement 2TUP

La branche fonctionnelle capture la connaissance du métier de l’entreprise. Cette branche

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

5.1. Analyse du besoin

L’analyse du besoin permet d’identifier toutes les fonctionnalités du système. Dans

NGOUANDA EDEN DIEUVEIL ANNEE ACADEMIQUE 2022-2023

● La gestion des demandes de financement ;

● Disponibilité : Le système doit garantir des temps de réponse relativement court au