SlideShare une entreprise Scribd logo
1  sur  19
Membres du Groupe :
1. Josué ISAMUNA NKEMBO
2. LUNGELA KIKOBYA Serge
3. NTWARI JUSTIN
4. Prince SALUMU
Travail proposé par
BAGAYAMUKWE BYAMUNGU Trésor
Année académique
2011-2012
Gestion de la
Comptabilité de l’ISIG
TP DE GENIE LOGICIEL
I. MODELISATION (ANALYSE) DU SYSTEME EXISTANT ET
FUTUR
I.1. Objectif
Rédiger la spécification UML de l'application correspondant au cahier des charges ci-
dessous. On se limitera aux cas d'utilisation, à l'élaboration du diagramme des classes, du
diagramme de collaboration et du diagramme des séquences.
I.2. Cahier de charge
Il s'agit de réaliser un logiciel de Gestion de la Comptabilité de l’Institut Supérieure
d’Informatique et de Gestion (I.S.I.G). Le Comptable se charge de la tenue courante des
comptes (passation des écritures comptable) lors des paiements des Etudiants.
Les étudiants remettent le bordereau de paiement de la MECREGO au comptable et ils
reçoivent un document (Jeton) de la part de ce dernier s’ils sont en ordre avec la comptabilité,
c'est-à-dire avoir payé la totalité des frais d’une tranche donnée.
Le Comptable rassemble, coordonne et vérifie les données comptables (bordereaux des
paiements des étudiants) aux fiches de paie de la MECREGO. Actuellement, cette tâche n'est
pas informatisée.
Le Comptable établit régulièrement et présente sous forme normalisée les documents
comptables légaux : bilan annuel, compte de résultats, et toutes informations ponctuelles
demandées par la Direction (situations journalière, mensuelles, trimestrielles...).
Le Comptable possède un système manuel qui lui fournit, chaque soir après le paiement
du dernier étudiant, la liste des étudiants ayant payés ce jour là.
Le Responsable du service de Comptabilité peut à tout moment, demander au système
la liste des étudiants et leurs soldes, la liste de paie des Enseignants et leurs soldes, les autres
dépenses effectuée par l’Entreprise. Il peut aussi obtenir différentes statistiques pour
déterminer les centres de profits et établir des prévisions budgétaires ainsi que des procédures
de contrôle.
I.3 Diagramme de Cas d’Utilisation
I.3.1 Utilité du diagramme et quelques notions de base
Le diagramme de cas d'utilisation nous aide à donner une vision globale du comportement
fonctionnel d'un système logiciel. Il est utile pour des présentations auprès de la direction ou
des acteurs d'un projet, mais pour le développement, le cas d'utilisation est plus approprié. Un
cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou
machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas
d'utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas
d'utilisation (use cases).
I.3.2. Diagramme
I.4. Diagramme (model) de Classe
I.4.1. Utilités et quelques notions de base
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et
les interfaces des systèmes ainsi que les différentes relations entre celles-ci.
Ce diagramme fait partie de la partie statique d'UML car il fait abstraction des aspects
temporels et dynamiques.
Une classe décrit les responsabilités, le comportement et le type d'un ensemble d'objets. Les
éléments de cet ensemble sont les instances de la classe.
Une classe est un ensemble de fonctions et de données (attributs) qui sont liées ensemble par
un champ sémantique. Les classes sont utilisées dans la programmation orientée objet. Elles
permettent de modéliser un programme et ainsi de découper une tâche complexe en plusieurs
petits travaux simples.
Les classes peuvent être liées entre elles grâce au mécanisme d'héritage qui permet de mettre
en évidence des relations de parenté.
Elles sont finalement instanciées pour créer des objets (une classe est un moule à objet : elle
décrit les caractéristiques des objets, les objets contiennent leurs valeurs propres pour chacune
de ces caractéristiques lorsqu'ils sont instanciés).
I.4.2. Diagramme
+ Personne
- nom : String(50)
- postnom : String(50)
- prenom : String(30)
- sexe : String(2) default(‘M’)
- adresse : String(200)
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
+ Etudiant
- id : Integer(10)
- matricule :
String(13)
- lieu_naissance: String(30)
- promotion: String(30)
- option : String(30)
- section : String(30)
+ ajouter(): void
+ supprimer(): void
+ modiffier(): void
+ afficher(): void
+ Enseignant
- telephone : Integer(12)
- email : String(30)
- nbre_enfant : Integer(5)
- anciennete : Integer(5)
- grade : String(30)
- titre : String(30)
+ ajouter(): void
+ supprimer(): void
+ modiffier(): void
+ afficher(): void
+ Salaire
- id_paimt : Integer(12)
- id_enseign : Integer(12)
- date_pmt : datetime
- montantPayer: float(5)
- montantPayerC: String(30)
- motif_paiemt: String(30)
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
+ Cours
- id_cours : Integer(12)
- id_enseignant: Integer(12)
- designation : String(5)
- vol_horaire : Integer(5)
- date_debut : datetime(30)
- date_fin : datetime(30)
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
+ PaiementEtudiant
- id_etutdiant : Integer(12)
- id_paiement : Integer(12)
- mtant_chifre : float(5)
- mtant_lett : String(50)
- code_mecre : integer(10)
- nom_mecre : String(30)
- motif_pmt : String(50)
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
+ Compte
- id : Integer(12)
- compte : Integer(12)
- designation : String(50)
- type : Integer(50)
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
+ Entrer_caisse
- id_operation : Integer(12)
- id_compte: Integer(12)
- montant_chiffre: float(5)
- montant_lettre: String(50)
- date_operation : dateTime
- motif : String(200)
- observation : datetime(30)
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
+ Sortie_caisse
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
- id_operation : Integer(12)
- id_compte: Integer(12)
- montant_chiffre: float(5)
- montant_lettre: String(50)
- date_operation : dateTime
- motif : String(200)
- observation : datetime(30)
+ Utilisateur
+ ajouter() : void
+ supprimer() : void
+ modiffier() : void
+ afficher() : void
- id_user : Integer(12)
- nom : String(30)
- postnom : String(30)
- prenom : String(30)
- mot_passe : String(50)
- niveau : String(20)
1..* 1..*
enseigner
dispenser
1..*
0..1
percevoir
1..*
0..1
0..1
effectuer
1..*
1..*
concerne concerne
0..1 0..1
1..*
I.5. Diagramme (model) de Collaboration/Communication
I.5.1. Utilités et quelques notions de base
Le diagramme de collaboration est un diagramme d'interactions UML 1.x, représentation
simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les
objets, et où la chronologie n'intervient que de façon annexe.
Il consiste en un graphe dont les nœuds sont des objets et les arcs (numérotés selon la
chronologie) les échanges entre ces objets.
Les diagrammes de collaboration ont été remplacés en UML 2.x par les diagrammes de
communication.
I.5.2. Diagramme
Cd Gestion Comptabilité ISIG
Comptable
MECRE DirectionEnseignant
Présentation bordereau de paiement
Remise du Jeton
Demande
paiement
Paiement
effectué
Demande vérification
bordereau
Vérification
effectuée Présentation
Etat financier
Etat financier
vérifier
I.6. Diagramme (model) de Séquence
I.6.1. Utilités et quelques notions de base
Les diagrammes de séquences sont la représentation graphique des interactions entre les
acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling
Language.
Le diagramme de séquences permet de cacher les interactions d'objets dans le cadre d'un
scénario d'un Diagramme des cas d'utilisation. Dans un souci de simplification, on représente
l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du
système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets.
La dimension verticale du diagramme représente le temps, permettant de visualiser
l'enchaînement des actions dans le temps, et de spécifier la naissance et la mort d'objets. Les
périodes d'activité des objets sont symbolisées par des rectangles, et ces objets dialoguent par
le biais de messages.
I.6.2. Diagramme
Pour notre cas, on a 3 diagrammes selon les opérations de nos 3 acteurs principaux :
- Diagramme de séquence pour l’opération étudiant ;
- Diagramme de séquence pour l’opération direction ;
- Diagramme de séquence pour l’opération comptabilité.
Sd Opération Etudiant Life Line : etudiant, : MECRE, :Comptable
Sd Opération Enseignant Life Line :Enseignant, :Comptable, :Direction
I.7. Présentation de l’application
I.7.1. Script de la création de la Base des données
create database comptabiliteISIG
go
use comptabiliteISIG
go
create table etudiant
(
id integer not null,
matricule varchar(15),
nom varchar(30) not null,
postnom varchar(30),
prenom varchar(30),
sexe char(1) not null default('M'),
date_naissance smalldatetime,
lieu_naissance varchar(50),
nationalite varchar(30),
adresse varchar(200) not null,
promotion varchar(30),
optio varchar(30),
sectio varchar(10),
constraint pk_etudiant primary key(id)
)
go
create table paiementEtudiant
(
id integer not null,
id_etudiant integer not null,
date_paiement smalldatetime,
montant_paye_chiffre varchar(10),
montant_paye_lettre varchar(100),
code_mecre varchar(10),
nom_mecre varchar(50),
motif_paiement varchar(100),
constraint pk_paiementEtudiant primary key(id),
constraint uk_code_mecre unique(code_mecre),
constraint fk_Etudiant_paiementEtudiant foreign
key(id_etudiant) references etudiant(id)
)
go
create table enseignant
(
id integer not null,
nom varchar(30) not null,
postnom varchar(30),
prenom varchar(30),
datenaissance smalldatetime,
nationalite varchar(50),
telephone varchar(13),
email varchar(30),
etat_civil varchar(30),
nbre_enfant integer,
anciennete varchar(30),
grade varchar(50),
titre varchar(100),
sexe varchar(1) default('M'),
adresse varchar(200) not null,
constraint pk_eneignat primary key(id)
)
go
create table paiementEnseignant
(
id integer not null,
id_enseignant integer not null,
date_paiement smalldatetime,
montant_percu_chiffre varchar(10),
montant_percu_lettre varchar(100),
motif_paiement varchar(200),
constraint pk_paiementEnseignant primary key(id),
constraint fk_Enseignant_paiementEnseignant foreign
key(id_enseignant) references Enseignant(id)
)
go
create table cours
(
id integer not null,
id_enseignant integer,
designation varchar(100) not null,
volume_horaire varchar(10),
date_debut smalldatetime,
date_fin smalldatetime,
constraint pk_cours primary key(id),
constraint fk_enseignant_cours foreign
key(id_enseignant) references enseignant(id)
)
go
create table compte
(
id integer not null,
compte integer not null default(10),
designation varchar(30),
constraint pk_compte primary key(id),
)
go
create table sortie_caisse
(
id integer not null,
id_compte integer,
montant_sortie_chiffre float,
montant_sortie_lettre varchar(200),
date_depense smalldatetime,
designation_sortie_caisse varchar(100),
autres_detaille_sortie_caisse varchar(100),
constraint pk_sortie_caisse primary key(id),
constraint fk_compte_depense foreign key(id_compte)
references compte(id)
)
go
create table entre_caisse
(
id integer not null,
id_compte integer,
montant_entre_chiffre float,
montant_entre_lettre varchar(200),
date_entre smalldatetime,
autres_detaille_entre_caisse varchar(100),
constraint pk_entre_caisse primary key(id),
constraint fk_entrer_caisse_compte foreign key(id_compte)
references compte(id)
)
go
create table utilisateur
(
id integer identity not null,
nom varchar(50) not null,
postnom varchar(50),
prenom varchar(30),
sexe varchar(1) default 'M',
niveau integer not null,
nomuser varchar(50) not null,
motpass varchar(50) not null,
constraint pk_utilisateur primary key(id)
)
go
I.7.2. Présentation Physique des Données (BD)
I.7.3. Page d’accueille de l’application
I.7.4. Formulaire d’Etudiants inscris Etudiant
I.7.5. Formulaire du Paiement Etudiant
I.7.6. Formulaire d’Enseignant
Annexes
I. PRESENTATION DE L’ISIG
I.1. Historique de la création de l’I.S.I.G
Toute organisation naît à partir des idées. Ces dernières étant considérées comme une
autre forme des ressources. L‘ISIG n‘a pas échappé à cette évidence et à travers le temps,
voici le chemin déjà parcouru.
En 1987, Alain WODON et KATULANYA ISU Deo constatent la carence en personnel
qualifié en informatique et en gestion dans la région du Nord Kivu. Alain WODON est
professeur en Santé Publique à l‘Université Libre de Bruxelles. Ayant beaucoup
d‘expériences de travail dans le domaine de Santé publique en Afrique, il était normal qu‘il
appuie l‘idée de créer un institut qui, outre l‘informatique, devrait pourvoir à la carence de
personnel de santé dans la ville et les périphéries de Goma.
Déo KATULANYA ISU a aussi fait la santé publique et la statistique. Après avoir
travaillé longtemps au CEMUBAC Nord-Kivu, il se lance dans diverses activités
entreprenariales. Co - fondateur de notre institution (ISIG-GOMA), il crée une mutuelle
d‘épargne et de crédit (MECREGO) en 2002 à GOMA. Le succès de cette mutuelle n‘a pas
traîné à s‘étendre sur tout le pays qui compte aujourd’hui plusieurs institutions.
Outre les études de Santé Publique et de Statistique, Déo KATULANYA a obtenu un
diplôme en Nouvelles Technologie de l‘Information et de la Communication à l‘Institut
COREMANS à Bruxelles, puis a suivi une formation de maîtrise en Gestion des Petites et
Moyennes entreprises (formation à distance avec CIESA/Canada). C‘est notamment grâce à
toutes ces différentes formations que le promoteur principal de l‘ISIG/GOMA a pu gérer
l‘institution à bon escient, en lui assurant toujours une relève en personnel qualifié, et probe.
Ainsi donc, en septembre 1991, l‘idée de créer une école de formation en informatique
de gestion est formalisée par Déo KATULANYA et Alain WODON. Au mois de Janvier
1992, les cours débutent dans l‘enceinte des bâtiments de l‘école « LES VOLCANS » pour
l‘option Informatique de Gestion. En mars 1994 commence la construction du bâtiment de
l‘ISIG et en décembre 1995, l‘ISIG obtient son agrément par l‘arrêté ministériel n°
ESURS/CAB.MIN/A5/178/95 portant agrément. En 1997, début de l‘option Gestion de
Développement et en 2000, début de l‘option Gestion des Institutions de Santé. En Octobre
2004, l‘ISIG obtient l‘autorisation d‘organiser la licence en Gestion de Développement. En
mai 2006, il obtient l‘agrément définitif par décret présidentiel n° 06/0106 du 12 juin 2006
portant agrément de quelques établissements privés d‘enseignements Supérieur et
Universitaire. A partir de cet acte l‘ISIG obtient sa personnalité juridique et les diplômes
doivent désormais être homologués par le Ministère de tutelle.
I.2. Objectif de l’I.S.I.G
L´ISIG a pour objectif de contribuer au développement de l´Afrique en général de la
République Démocratique du Congo en particulier à travers la formation de cadres en
Informatique et en Gestion.
Il se propose à cet effet :
♣ Satisfaire un besoin présent, celui de former les techniciens capables d’être utilises dans
la micro − informatique en vue de résoudre l´ensemble des problèmes liés à la gestion et
à des routines dans les services ;
♣ D´appliquer les principales méthodes et techniques de gestion appliquée à l´informatique
en utilisant l´outil informatique de gestion moderne qu´on appelle «Ordinateur» ;
♣ Résoudre les problèmes statistiques de management et de comptabilité au moyen de l
´ordinateur.
♣ S´occuper des personnes les plus défavorisées par l´information et la formation.
Cependant, pour attendre ces objectifs, il met en évidence une organisation bien
structurée.
I.3. Organisation de l’ISIG
I.3.1. Gouvernance de l‘I.S.I.G.
L‘objectif de cette sous - section est de présenter les relations entre les organes chargés
de la vie de l‘institution, particulièrement entre le Conseil d‘Administration et le Comité de
Gestion de l‘Institut. La section est volontairement descriptive en vue de dégager les points
qui nécessiteraient des améliorations dans l‘avenir.
I.3.2. Structure organisationnelle de l‘I.S.I.G
I.3.2.1. Organigramme
Personnes affectées aux différents postes
I.3.2.2. Organisation de la fonction Financière et comptable
Type de financement
L‘Institut Supérieur d‘Informatique et de Gestion est entièrement financé par les frais
académiques payés par les étudiants. Ceci constitue à la fois une force et une faiblesse. Une
force dans la mesure où l‘ISIG peut prévoir ses différentes dépenses en fonction de ses
ressources financières internes (indépendance et autofinancement). Une faiblesse dans la
mesure où il devient moins compétitif, notamment face aux institutions publiques. Ceci est
d‘autant plus vrai que l‘Etat Congolais commence à améliorer la rémunération des
enseignants des institutions publiques, tant au niveau de l‘ampleur que de la régularité.
Tous les payements s‘effectuent à la Coopérative (MECRECO) aux divers guichets
ouverts dans la ville de Goma et où l‘institution possède des comptes à vue et d‘épargne. Cela
permet d‘éviter la perception au sein des bureaux de l‘Institut ; perception qui, dans le temps,
occasionnait beaucoup de fuites. Les recouvrements se font périodiquement en respectant les
modalités précisées sur un papier « échéancier » qui est remis aux étudiants à chaque début
de l‘année académique.
Assemblée Générale
Déo KATULANYA ISU Alain WODON Mr NOTERMAN
Conseil d’Administration
Membre
Mr NOTERMAN
Membre
Pf Dr BITIJULA
Membre
Pf Dr Katanga
Président du Conseil
Déo KATULANYA ISU
Membre
Jospin
MALIGHE
Comité de Gestion
Secr Gen Adm
CT Léon Balemba
Admin Budget
CT Emmanuel Baguma
Directeur Général
Pf Dr Déogratias
Corps Scientifique
Exécution des dépenses
Les dépenses sont exécutées par un caissier sur base des états des besoins approuvés et
vérifiés par les autorités compétentes de l‘Institution. Chaque service est appelé à présenter un
état de besoin lorsqu‘une dépense s‘impose. Les différents états de besoin sont synthétisés sur
un même document qui sera présenté à l‘Administrateur de Budget, puis au Directeur
Général. Après approbation, un chèque est signé par l‘Administrateur de Budget et le
Directeur Général ; ou alors l‘Administrateur de Budget et le Secrétaire Général Administratif
(en l‘absence du Directeur Général). Cela permet le suivi de la transparence dans l‘affectation
des fonds retirés de la coopérative pour diverses dépenses.
Elaboration du Budget annuel
L‘ISIG prévoit à chaque début de l‘année académique un budget prévisionnel qui va
servir de guide pour toutes les dépenses et les recettes à réaliser tout au long de l‘année (en
annexe 1, modèle des prévisions budgétaires de l‘ISIG). Cela permet à chaque fois, de
comparer les prévisions aux réalisations en vue de prendre des dispositions y afférentes.
Presque toutes les dépenses prévues dans le budget sont réalisées à 100% à la fin de l‘exercice
comptable.
II. GENERALITES SUR LA COMPTABILITE
II.1. Introduction
La Comptabilité1
est une science, art, action de tenir des comptes. Elle a pour objectifs :
1. Permettre le contrôle ;
2. Fournir un moyen de preuve ;
3. Aider à la prise des décisions ;
4. Autres finalités de la comptabilité :
•Diagnostic économique et financier ;
•Une des sources de la Comptabilité Nationale ;
•Instrument de régulation sociale.
1
Cours de Comptabilité G1 ISIG 2009
Pièces justificatives
Livre journal Grand livre
Balance de vérification
Inventaire et travaux
Comptables de fin d'exercice
Balance définitive
Bilan
Compte de résultats
Annexe
Comptabilité
II.2. Notion de Bilan
Le bilan est un état financier de synthèse qui regroupe les éléments actifs et passifs du
Patrimoine de l’entreprise. Le bilan est le document présentant la valeur du patrimoine brut de
l’entreprise à une date donnée.
Il fait apparaître par différence et de façon distincte ses capitaux propres.
Fondamentalement toute acquisition de moyens de production (emplois) s’accompagne
obligatoirement d’un financement mis à la disposition de l’entreprise (ressources)
Actif Passif
N°
Compte
Désignation Date Modification Date
Débit Crédit
II.3. Comptabilité et Inventaire
La comptabilité présente un aspect mécanique qui consiste à classer, enregistrer des
pièces comptables au jour le jour, additionner des opérations, alors que l’inventaire consiste à
prévoir, apprécier, évaluer.
Pour déterminer le résultat d’une période donnée à partir des éléments enregistrés au
jour le jour, il faut procéder à des opérations d’inventaire pour :
- Vérifier que les enregistrements effectués au jour le jour correspondent à la réalité des
ceux existants physiquement (inventaire des biens possédés et des dettes) ;
- Répartir les charges et les produits dans le temps sans tenir compte du fait que les
dettes et les créances sont payées ou non;
- Apprécier les augmentations de valeur ou les dépréciations subies ;
- Porter un jugement sur l’avenir en constituant si nécessaire des provisions lorsque des
évènements en cours rendent probables certaines dépenses ou charges.
II.4. Le Compte
Afin de suivre l’évolution des postes du bilan et du résultat de l’exercice, est ouvert,
pour chaque poste, un Compte du même nom. Instrument de classement fonctionnel, il permet
de suivre l’évolution d’un élément particulier du patrimoine ou d’un élément de l’activité.
Le compte est un tableau dans lequel sont enregistrées les augmentations et les diminutions
qui surviennent aux postes du bilan à la suite des diverses opérations de l’exercice.
II.5. La comptabilité en partie double
Pour que les comptes soient équilibrés, il faut nécessairement qu’un compte soit débité
et l’autre crédité selon un mécanisme appelé partie double respectant l’égalité suivante :
Biens – Dettes = Résultat = Produits – Charges
Cette égalité fondamentale car permet d’expliquer la technique de la comptabilité à
partie double. Pour assurer son respect, il est nécessaire que les comptes de biens et de
charges fonctionnent de la même manière et que les comptes de dettes et de produits
fonctionnent aussi de manière identique mais en sens inverse de la précédente.
II.6. Le Journal
N° Ope N° Compte Libelle Somme
D C D C
II.7. Le Grand-livre
Le grand livre est constitué de l’ensemble des comptes qu’utilise l’entreprise pour la
tenue de sa comptabilité.
Compte n°…… Nom…………………………………..
Date Libelle Pièce JO Débit Crédit
II.8. Balance
N° Cpt Désignation Somme Solde
D C D C

Contenu connexe

Tendances

La spécification des besoins
La spécification des besoinsLa spécification des besoins
La spécification des besoins
Ismahen Traya
 
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
bouzidi26
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
Lina Meddeb
 

Tendances (20)

Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...Présentation pfe - Etude, conception et réalisation d'une application web de ...
Présentation pfe - Etude, conception et réalisation d'une application web de ...
 
Rapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humainesRapport projet c : Logiciel de gestion des ressources humaines
Rapport projet c : Logiciel de gestion des ressources humaines
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Ecole ESMA : Projet Fin de semestre - Application de gestion d'une école - Di...
Ecole ESMA : Projet Fin de semestre - Application de gestion d'une école - Di...Ecole ESMA : Projet Fin de semestre - Application de gestion d'une école - Di...
Ecole ESMA : Projet Fin de semestre - Application de gestion d'une école - Di...
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
La spécification des besoins
La spécification des besoinsLa spécification des besoins
La spécification des besoins
 
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
Realisation d une application de gestion d-un -tablissement priv-e 26-04_08
 
Conception et mise en place d'un site web dynamique de gestion de passation ...
Conception et mise en place d'un site web  dynamique de gestion de passation ...Conception et mise en place d'un site web  dynamique de gestion de passation ...
Conception et mise en place d'un site web dynamique de gestion de passation ...
 
RapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRITRapportPFE_IngenieurInformatique_ESPRIT
RapportPFE_IngenieurInformatique_ESPRIT
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
MEMOIRE DE STAGE
MEMOIRE DE STAGEMEMOIRE DE STAGE
MEMOIRE DE STAGE
 
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIRRapport du Projet de Fin d'année Génie informatique ENSA AGADIR
Rapport du Projet de Fin d'année Génie informatique ENSA AGADIR
 
rapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFErapport de projet de fin d'étude_PFE
rapport de projet de fin d'étude_PFE
 
Réalisation d'un site web dynamique mobile pour Air Algérie
Réalisation d'un site web dynamique mobile pour Air AlgérieRéalisation d'un site web dynamique mobile pour Air Algérie
Réalisation d'un site web dynamique mobile pour Air Algérie
 
Presentation PPT-Marwen ben khalifa
Presentation PPT-Marwen ben khalifaPresentation PPT-Marwen ben khalifa
Presentation PPT-Marwen ben khalifa
 
Projet Fin D'étude Application Mobile
Projet Fin D'étude Application MobileProjet Fin D'étude Application Mobile
Projet Fin D'étude Application Mobile
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 

Similaire à 556ef78d93c3b

U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception Objet
Amine Chkr
 
Uml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementUml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnement
CERTyou Formation
 
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFUnified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VF
cifaf13039
 
Présentation cours UML.pptx
Présentation  cours UML.pptxPrésentation  cours UML.pptx
Présentation cours UML.pptx
PrinceLankoand
 

Similaire à 556ef78d93c3b (20)

Tp3 - UML
Tp3 - UMLTp3 - UML
Tp3 - UML
 
diagramme de cas d'utilisation
diagramme de cas d'utilisationdiagramme de cas d'utilisation
diagramme de cas d'utilisation
 
7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation7 diagramme de cas d'utilisation
7 diagramme de cas d'utilisation
 
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfSupport de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdf
 
U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception Objet
 
Uml
UmlUml
Uml
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
 
CM uml-diag-dynamiques-interaction
CM uml-diag-dynamiques-interactionCM uml-diag-dynamiques-interaction
CM uml-diag-dynamiques-interaction
 
Uml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnementUml2 a formation-uml-2-perfectionnement
Uml2 a formation-uml-2-perfectionnement
 
CM CU-cockburn
CM CU-cockburnCM CU-cockburn
CM CU-cockburn
 
Uml
UmlUml
Uml
 
CM uml-intro
CM uml-introCM uml-intro
CM uml-intro
 
Uml: Diagrammes de classes -- Concepts avances --- 27
Uml: Diagrammes de classes -- Concepts avances --- 27Uml: Diagrammes de classes -- Concepts avances --- 27
Uml: Diagrammes de classes -- Concepts avances --- 27
 
COURS UML INFORMATQIUE TELECOM2 2007.pdf
COURS UML INFORMATQIUE TELECOM2 2007.pdfCOURS UML INFORMATQIUE TELECOM2 2007.pdf
COURS UML INFORMATQIUE TELECOM2 2007.pdf
 
Unified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VFUnified Modeling Language Intro 2021-2022 VF
Unified Modeling Language Intro 2021-2022 VF
 
Présentation cours UML.pptx
Présentation  cours UML.pptxPrésentation  cours UML.pptx
Présentation cours UML.pptx
 
UML.pptx
UML.pptxUML.pptx
UML.pptx
 
UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
 
programmation orienté objet c++
programmation orienté objet c++programmation orienté objet c++
programmation orienté objet c++
 
generation_code.pdf
generation_code.pdfgeneration_code.pdf
generation_code.pdf
 

Dernier

conception d'un batiment r+4 comparative de defferente ariante de plancher
conception d'un  batiment  r+4 comparative de defferente ariante de plancherconception d'un  batiment  r+4 comparative de defferente ariante de plancher
conception d'un batiment r+4 comparative de defferente ariante de plancher
mansouriahlam
 

Dernier (7)

comprehension de DDMRP dans le domaine de gestion
comprehension de DDMRP dans le domaine de gestioncomprehension de DDMRP dans le domaine de gestion
comprehension de DDMRP dans le domaine de gestion
 
firefly algoriyhm sac a dos step by step .pdf
firefly algoriyhm sac a dos step by step .pdffirefly algoriyhm sac a dos step by step .pdf
firefly algoriyhm sac a dos step by step .pdf
 
optimisation logistique MLT_231102_155827.pdf
optimisation logistique  MLT_231102_155827.pdfoptimisation logistique  MLT_231102_155827.pdf
optimisation logistique MLT_231102_155827.pdf
 
JTC 2024 Bâtiment et Photovoltaïque.pdf
JTC 2024  Bâtiment et Photovoltaïque.pdfJTC 2024  Bâtiment et Photovoltaïque.pdf
JTC 2024 Bâtiment et Photovoltaïque.pdf
 
Algo II: les files cours + exercices corrigés
Algo II: les files cours + exercices corrigésAlgo II: les files cours + exercices corrigés
Algo II: les files cours + exercices corrigés
 
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
Présentation_Soirée-Information_ Surverse_Thibert _30 avril 2024
 
conception d'un batiment r+4 comparative de defferente ariante de plancher
conception d'un  batiment  r+4 comparative de defferente ariante de plancherconception d'un  batiment  r+4 comparative de defferente ariante de plancher
conception d'un batiment r+4 comparative de defferente ariante de plancher
 

556ef78d93c3b

  • 1. Membres du Groupe : 1. Josué ISAMUNA NKEMBO 2. LUNGELA KIKOBYA Serge 3. NTWARI JUSTIN 4. Prince SALUMU Travail proposé par BAGAYAMUKWE BYAMUNGU Trésor Année académique 2011-2012 Gestion de la Comptabilité de l’ISIG TP DE GENIE LOGICIEL
  • 2. I. MODELISATION (ANALYSE) DU SYSTEME EXISTANT ET FUTUR I.1. Objectif Rédiger la spécification UML de l'application correspondant au cahier des charges ci- dessous. On se limitera aux cas d'utilisation, à l'élaboration du diagramme des classes, du diagramme de collaboration et du diagramme des séquences. I.2. Cahier de charge Il s'agit de réaliser un logiciel de Gestion de la Comptabilité de l’Institut Supérieure d’Informatique et de Gestion (I.S.I.G). Le Comptable se charge de la tenue courante des comptes (passation des écritures comptable) lors des paiements des Etudiants. Les étudiants remettent le bordereau de paiement de la MECREGO au comptable et ils reçoivent un document (Jeton) de la part de ce dernier s’ils sont en ordre avec la comptabilité, c'est-à-dire avoir payé la totalité des frais d’une tranche donnée. Le Comptable rassemble, coordonne et vérifie les données comptables (bordereaux des paiements des étudiants) aux fiches de paie de la MECREGO. Actuellement, cette tâche n'est pas informatisée. Le Comptable établit régulièrement et présente sous forme normalisée les documents comptables légaux : bilan annuel, compte de résultats, et toutes informations ponctuelles demandées par la Direction (situations journalière, mensuelles, trimestrielles...). Le Comptable possède un système manuel qui lui fournit, chaque soir après le paiement du dernier étudiant, la liste des étudiants ayant payés ce jour là. Le Responsable du service de Comptabilité peut à tout moment, demander au système la liste des étudiants et leurs soldes, la liste de paie des Enseignants et leurs soldes, les autres dépenses effectuée par l’Entreprise. Il peut aussi obtenir différentes statistiques pour déterminer les centres de profits et établir des prévisions budgétaires ainsi que des procédures de contrôle.
  • 3. I.3 Diagramme de Cas d’Utilisation I.3.1 Utilité du diagramme et quelques notions de base Le diagramme de cas d'utilisation nous aide à donner une vision globale du comportement fonctionnel d'un système logiciel. Il est utile pour des présentations auprès de la direction ou des acteurs d'un projet, mais pour le développement, le cas d'utilisation est plus approprié. Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur (humain ou machine) et un système. Il est une unité significative de travail. Dans un diagramme de cas d'utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent avec les cas d'utilisation (use cases). I.3.2. Diagramme
  • 4. I.4. Diagramme (model) de Classe I.4.1. Utilités et quelques notions de base Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci. Ce diagramme fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et dynamiques. Une classe décrit les responsabilités, le comportement et le type d'un ensemble d'objets. Les éléments de cet ensemble sont les instances de la classe. Une classe est un ensemble de fonctions et de données (attributs) qui sont liées ensemble par un champ sémantique. Les classes sont utilisées dans la programmation orientée objet. Elles permettent de modéliser un programme et ainsi de découper une tâche complexe en plusieurs petits travaux simples. Les classes peuvent être liées entre elles grâce au mécanisme d'héritage qui permet de mettre en évidence des relations de parenté. Elles sont finalement instanciées pour créer des objets (une classe est un moule à objet : elle décrit les caractéristiques des objets, les objets contiennent leurs valeurs propres pour chacune de ces caractéristiques lorsqu'ils sont instanciés).
  • 5. I.4.2. Diagramme + Personne - nom : String(50) - postnom : String(50) - prenom : String(30) - sexe : String(2) default(‘M’) - adresse : String(200) + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void + Etudiant - id : Integer(10) - matricule : String(13) - lieu_naissance: String(30) - promotion: String(30) - option : String(30) - section : String(30) + ajouter(): void + supprimer(): void + modiffier(): void + afficher(): void + Enseignant - telephone : Integer(12) - email : String(30) - nbre_enfant : Integer(5) - anciennete : Integer(5) - grade : String(30) - titre : String(30) + ajouter(): void + supprimer(): void + modiffier(): void + afficher(): void + Salaire - id_paimt : Integer(12) - id_enseign : Integer(12) - date_pmt : datetime - montantPayer: float(5) - montantPayerC: String(30) - motif_paiemt: String(30) + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void + Cours - id_cours : Integer(12) - id_enseignant: Integer(12) - designation : String(5) - vol_horaire : Integer(5) - date_debut : datetime(30) - date_fin : datetime(30) + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void + PaiementEtudiant - id_etutdiant : Integer(12) - id_paiement : Integer(12) - mtant_chifre : float(5) - mtant_lett : String(50) - code_mecre : integer(10) - nom_mecre : String(30) - motif_pmt : String(50) + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void + Compte - id : Integer(12) - compte : Integer(12) - designation : String(50) - type : Integer(50) + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void + Entrer_caisse - id_operation : Integer(12) - id_compte: Integer(12) - montant_chiffre: float(5) - montant_lettre: String(50) - date_operation : dateTime - motif : String(200) - observation : datetime(30) + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void + Sortie_caisse + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void - id_operation : Integer(12) - id_compte: Integer(12) - montant_chiffre: float(5) - montant_lettre: String(50) - date_operation : dateTime - motif : String(200) - observation : datetime(30) + Utilisateur + ajouter() : void + supprimer() : void + modiffier() : void + afficher() : void - id_user : Integer(12) - nom : String(30) - postnom : String(30) - prenom : String(30) - mot_passe : String(50) - niveau : String(20) 1..* 1..* enseigner dispenser 1..* 0..1 percevoir 1..* 0..1 0..1 effectuer 1..* 1..* concerne concerne 0..1 0..1 1..*
  • 6. I.5. Diagramme (model) de Collaboration/Communication I.5.1. Utilités et quelques notions de base Le diagramme de collaboration est un diagramme d'interactions UML 1.x, représentation simplifiée d'un diagramme de séquence se concentrant sur les échanges de messages entre les objets, et où la chronologie n'intervient que de façon annexe. Il consiste en un graphe dont les nœuds sont des objets et les arcs (numérotés selon la chronologie) les échanges entre ces objets. Les diagrammes de collaboration ont été remplacés en UML 2.x par les diagrammes de communication. I.5.2. Diagramme Cd Gestion Comptabilité ISIG Comptable MECRE DirectionEnseignant Présentation bordereau de paiement Remise du Jeton Demande paiement Paiement effectué Demande vérification bordereau Vérification effectuée Présentation Etat financier Etat financier vérifier
  • 7. I.6. Diagramme (model) de Séquence I.6.1. Utilités et quelques notions de base Les diagrammes de séquences sont la représentation graphique des interactions entre les acteurs et le système selon un ordre chronologique dans la formulation Unified Modeling Language. Le diagramme de séquences permet de cacher les interactions d'objets dans le cadre d'un scénario d'un Diagramme des cas d'utilisation. Dans un souci de simplification, on représente l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets. La dimension verticale du diagramme représente le temps, permettant de visualiser l'enchaînement des actions dans le temps, et de spécifier la naissance et la mort d'objets. Les périodes d'activité des objets sont symbolisées par des rectangles, et ces objets dialoguent par le biais de messages. I.6.2. Diagramme Pour notre cas, on a 3 diagrammes selon les opérations de nos 3 acteurs principaux : - Diagramme de séquence pour l’opération étudiant ; - Diagramme de séquence pour l’opération direction ; - Diagramme de séquence pour l’opération comptabilité. Sd Opération Etudiant Life Line : etudiant, : MECRE, :Comptable
  • 8. Sd Opération Enseignant Life Line :Enseignant, :Comptable, :Direction
  • 9. I.7. Présentation de l’application I.7.1. Script de la création de la Base des données create database comptabiliteISIG go use comptabiliteISIG go create table etudiant ( id integer not null, matricule varchar(15), nom varchar(30) not null, postnom varchar(30), prenom varchar(30), sexe char(1) not null default('M'), date_naissance smalldatetime, lieu_naissance varchar(50), nationalite varchar(30), adresse varchar(200) not null, promotion varchar(30), optio varchar(30), sectio varchar(10), constraint pk_etudiant primary key(id) ) go create table paiementEtudiant ( id integer not null, id_etudiant integer not null, date_paiement smalldatetime, montant_paye_chiffre varchar(10), montant_paye_lettre varchar(100), code_mecre varchar(10), nom_mecre varchar(50), motif_paiement varchar(100), constraint pk_paiementEtudiant primary key(id), constraint uk_code_mecre unique(code_mecre), constraint fk_Etudiant_paiementEtudiant foreign key(id_etudiant) references etudiant(id) ) go create table enseignant ( id integer not null, nom varchar(30) not null, postnom varchar(30), prenom varchar(30), datenaissance smalldatetime, nationalite varchar(50), telephone varchar(13), email varchar(30), etat_civil varchar(30), nbre_enfant integer, anciennete varchar(30), grade varchar(50), titre varchar(100), sexe varchar(1) default('M'), adresse varchar(200) not null, constraint pk_eneignat primary key(id) ) go create table paiementEnseignant ( id integer not null, id_enseignant integer not null, date_paiement smalldatetime, montant_percu_chiffre varchar(10), montant_percu_lettre varchar(100), motif_paiement varchar(200), constraint pk_paiementEnseignant primary key(id), constraint fk_Enseignant_paiementEnseignant foreign key(id_enseignant) references Enseignant(id) ) go create table cours ( id integer not null, id_enseignant integer, designation varchar(100) not null, volume_horaire varchar(10), date_debut smalldatetime, date_fin smalldatetime, constraint pk_cours primary key(id), constraint fk_enseignant_cours foreign key(id_enseignant) references enseignant(id) ) go create table compte ( id integer not null, compte integer not null default(10), designation varchar(30), constraint pk_compte primary key(id), ) go create table sortie_caisse ( id integer not null, id_compte integer, montant_sortie_chiffre float, montant_sortie_lettre varchar(200), date_depense smalldatetime, designation_sortie_caisse varchar(100), autres_detaille_sortie_caisse varchar(100), constraint pk_sortie_caisse primary key(id), constraint fk_compte_depense foreign key(id_compte) references compte(id) ) go create table entre_caisse ( id integer not null, id_compte integer, montant_entre_chiffre float, montant_entre_lettre varchar(200), date_entre smalldatetime, autres_detaille_entre_caisse varchar(100), constraint pk_entre_caisse primary key(id), constraint fk_entrer_caisse_compte foreign key(id_compte) references compte(id) ) go create table utilisateur ( id integer identity not null, nom varchar(50) not null, postnom varchar(50), prenom varchar(30), sexe varchar(1) default 'M', niveau integer not null, nomuser varchar(50) not null, motpass varchar(50) not null, constraint pk_utilisateur primary key(id) ) go
  • 10. I.7.2. Présentation Physique des Données (BD) I.7.3. Page d’accueille de l’application I.7.4. Formulaire d’Etudiants inscris Etudiant I.7.5. Formulaire du Paiement Etudiant I.7.6. Formulaire d’Enseignant
  • 12. I. PRESENTATION DE L’ISIG I.1. Historique de la création de l’I.S.I.G Toute organisation naît à partir des idées. Ces dernières étant considérées comme une autre forme des ressources. L‘ISIG n‘a pas échappé à cette évidence et à travers le temps, voici le chemin déjà parcouru. En 1987, Alain WODON et KATULANYA ISU Deo constatent la carence en personnel qualifié en informatique et en gestion dans la région du Nord Kivu. Alain WODON est professeur en Santé Publique à l‘Université Libre de Bruxelles. Ayant beaucoup d‘expériences de travail dans le domaine de Santé publique en Afrique, il était normal qu‘il appuie l‘idée de créer un institut qui, outre l‘informatique, devrait pourvoir à la carence de personnel de santé dans la ville et les périphéries de Goma. Déo KATULANYA ISU a aussi fait la santé publique et la statistique. Après avoir travaillé longtemps au CEMUBAC Nord-Kivu, il se lance dans diverses activités entreprenariales. Co - fondateur de notre institution (ISIG-GOMA), il crée une mutuelle d‘épargne et de crédit (MECREGO) en 2002 à GOMA. Le succès de cette mutuelle n‘a pas traîné à s‘étendre sur tout le pays qui compte aujourd’hui plusieurs institutions. Outre les études de Santé Publique et de Statistique, Déo KATULANYA a obtenu un diplôme en Nouvelles Technologie de l‘Information et de la Communication à l‘Institut COREMANS à Bruxelles, puis a suivi une formation de maîtrise en Gestion des Petites et Moyennes entreprises (formation à distance avec CIESA/Canada). C‘est notamment grâce à toutes ces différentes formations que le promoteur principal de l‘ISIG/GOMA a pu gérer l‘institution à bon escient, en lui assurant toujours une relève en personnel qualifié, et probe. Ainsi donc, en septembre 1991, l‘idée de créer une école de formation en informatique de gestion est formalisée par Déo KATULANYA et Alain WODON. Au mois de Janvier 1992, les cours débutent dans l‘enceinte des bâtiments de l‘école « LES VOLCANS » pour l‘option Informatique de Gestion. En mars 1994 commence la construction du bâtiment de l‘ISIG et en décembre 1995, l‘ISIG obtient son agrément par l‘arrêté ministériel n° ESURS/CAB.MIN/A5/178/95 portant agrément. En 1997, début de l‘option Gestion de Développement et en 2000, début de l‘option Gestion des Institutions de Santé. En Octobre 2004, l‘ISIG obtient l‘autorisation d‘organiser la licence en Gestion de Développement. En mai 2006, il obtient l‘agrément définitif par décret présidentiel n° 06/0106 du 12 juin 2006 portant agrément de quelques établissements privés d‘enseignements Supérieur et Universitaire. A partir de cet acte l‘ISIG obtient sa personnalité juridique et les diplômes doivent désormais être homologués par le Ministère de tutelle.
  • 13. I.2. Objectif de l’I.S.I.G L´ISIG a pour objectif de contribuer au développement de l´Afrique en général de la République Démocratique du Congo en particulier à travers la formation de cadres en Informatique et en Gestion. Il se propose à cet effet : ♣ Satisfaire un besoin présent, celui de former les techniciens capables d’être utilises dans la micro − informatique en vue de résoudre l´ensemble des problèmes liés à la gestion et à des routines dans les services ; ♣ D´appliquer les principales méthodes et techniques de gestion appliquée à l´informatique en utilisant l´outil informatique de gestion moderne qu´on appelle «Ordinateur» ; ♣ Résoudre les problèmes statistiques de management et de comptabilité au moyen de l ´ordinateur. ♣ S´occuper des personnes les plus défavorisées par l´information et la formation. Cependant, pour attendre ces objectifs, il met en évidence une organisation bien structurée. I.3. Organisation de l’ISIG I.3.1. Gouvernance de l‘I.S.I.G. L‘objectif de cette sous - section est de présenter les relations entre les organes chargés de la vie de l‘institution, particulièrement entre le Conseil d‘Administration et le Comité de Gestion de l‘Institut. La section est volontairement descriptive en vue de dégager les points qui nécessiteraient des améliorations dans l‘avenir. I.3.2. Structure organisationnelle de l‘I.S.I.G I.3.2.1. Organigramme Personnes affectées aux différents postes
  • 14. I.3.2.2. Organisation de la fonction Financière et comptable Type de financement L‘Institut Supérieur d‘Informatique et de Gestion est entièrement financé par les frais académiques payés par les étudiants. Ceci constitue à la fois une force et une faiblesse. Une force dans la mesure où l‘ISIG peut prévoir ses différentes dépenses en fonction de ses ressources financières internes (indépendance et autofinancement). Une faiblesse dans la mesure où il devient moins compétitif, notamment face aux institutions publiques. Ceci est d‘autant plus vrai que l‘Etat Congolais commence à améliorer la rémunération des enseignants des institutions publiques, tant au niveau de l‘ampleur que de la régularité. Tous les payements s‘effectuent à la Coopérative (MECRECO) aux divers guichets ouverts dans la ville de Goma et où l‘institution possède des comptes à vue et d‘épargne. Cela permet d‘éviter la perception au sein des bureaux de l‘Institut ; perception qui, dans le temps, occasionnait beaucoup de fuites. Les recouvrements se font périodiquement en respectant les modalités précisées sur un papier « échéancier » qui est remis aux étudiants à chaque début de l‘année académique. Assemblée Générale Déo KATULANYA ISU Alain WODON Mr NOTERMAN Conseil d’Administration Membre Mr NOTERMAN Membre Pf Dr BITIJULA Membre Pf Dr Katanga Président du Conseil Déo KATULANYA ISU Membre Jospin MALIGHE Comité de Gestion Secr Gen Adm CT Léon Balemba Admin Budget CT Emmanuel Baguma Directeur Général Pf Dr Déogratias Corps Scientifique
  • 15. Exécution des dépenses Les dépenses sont exécutées par un caissier sur base des états des besoins approuvés et vérifiés par les autorités compétentes de l‘Institution. Chaque service est appelé à présenter un état de besoin lorsqu‘une dépense s‘impose. Les différents états de besoin sont synthétisés sur un même document qui sera présenté à l‘Administrateur de Budget, puis au Directeur Général. Après approbation, un chèque est signé par l‘Administrateur de Budget et le Directeur Général ; ou alors l‘Administrateur de Budget et le Secrétaire Général Administratif (en l‘absence du Directeur Général). Cela permet le suivi de la transparence dans l‘affectation des fonds retirés de la coopérative pour diverses dépenses. Elaboration du Budget annuel L‘ISIG prévoit à chaque début de l‘année académique un budget prévisionnel qui va servir de guide pour toutes les dépenses et les recettes à réaliser tout au long de l‘année (en annexe 1, modèle des prévisions budgétaires de l‘ISIG). Cela permet à chaque fois, de comparer les prévisions aux réalisations en vue de prendre des dispositions y afférentes. Presque toutes les dépenses prévues dans le budget sont réalisées à 100% à la fin de l‘exercice comptable.
  • 16. II. GENERALITES SUR LA COMPTABILITE II.1. Introduction La Comptabilité1 est une science, art, action de tenir des comptes. Elle a pour objectifs : 1. Permettre le contrôle ; 2. Fournir un moyen de preuve ; 3. Aider à la prise des décisions ; 4. Autres finalités de la comptabilité : •Diagnostic économique et financier ; •Une des sources de la Comptabilité Nationale ; •Instrument de régulation sociale. 1 Cours de Comptabilité G1 ISIG 2009 Pièces justificatives Livre journal Grand livre Balance de vérification Inventaire et travaux Comptables de fin d'exercice Balance définitive Bilan Compte de résultats Annexe Comptabilité
  • 17. II.2. Notion de Bilan Le bilan est un état financier de synthèse qui regroupe les éléments actifs et passifs du Patrimoine de l’entreprise. Le bilan est le document présentant la valeur du patrimoine brut de l’entreprise à une date donnée. Il fait apparaître par différence et de façon distincte ses capitaux propres. Fondamentalement toute acquisition de moyens de production (emplois) s’accompagne obligatoirement d’un financement mis à la disposition de l’entreprise (ressources) Actif Passif N° Compte Désignation Date Modification Date Débit Crédit II.3. Comptabilité et Inventaire La comptabilité présente un aspect mécanique qui consiste à classer, enregistrer des pièces comptables au jour le jour, additionner des opérations, alors que l’inventaire consiste à prévoir, apprécier, évaluer. Pour déterminer le résultat d’une période donnée à partir des éléments enregistrés au jour le jour, il faut procéder à des opérations d’inventaire pour : - Vérifier que les enregistrements effectués au jour le jour correspondent à la réalité des ceux existants physiquement (inventaire des biens possédés et des dettes) ; - Répartir les charges et les produits dans le temps sans tenir compte du fait que les dettes et les créances sont payées ou non; - Apprécier les augmentations de valeur ou les dépréciations subies ; - Porter un jugement sur l’avenir en constituant si nécessaire des provisions lorsque des évènements en cours rendent probables certaines dépenses ou charges. II.4. Le Compte Afin de suivre l’évolution des postes du bilan et du résultat de l’exercice, est ouvert, pour chaque poste, un Compte du même nom. Instrument de classement fonctionnel, il permet de suivre l’évolution d’un élément particulier du patrimoine ou d’un élément de l’activité.
  • 18. Le compte est un tableau dans lequel sont enregistrées les augmentations et les diminutions qui surviennent aux postes du bilan à la suite des diverses opérations de l’exercice. II.5. La comptabilité en partie double Pour que les comptes soient équilibrés, il faut nécessairement qu’un compte soit débité et l’autre crédité selon un mécanisme appelé partie double respectant l’égalité suivante : Biens – Dettes = Résultat = Produits – Charges Cette égalité fondamentale car permet d’expliquer la technique de la comptabilité à partie double. Pour assurer son respect, il est nécessaire que les comptes de biens et de charges fonctionnent de la même manière et que les comptes de dettes et de produits fonctionnent aussi de manière identique mais en sens inverse de la précédente. II.6. Le Journal N° Ope N° Compte Libelle Somme D C D C II.7. Le Grand-livre Le grand livre est constitué de l’ensemble des comptes qu’utilise l’entreprise pour la tenue de sa comptabilité. Compte n°…… Nom………………………………….. Date Libelle Pièce JO Débit Crédit
  • 19. II.8. Balance N° Cpt Désignation Somme Solde D C D C