MINISTÈRE DE L'ÉDUCATION

DIPLOME EN TECHNOLOGIE DE L'INFORMATION ET DE LA COMMUNICATION

INSTITUT KENYAN DE DÉVELOPPEMENT CURRICULUM

NOTES D'ÉTUDE

ANALYSE ET CONCEPTION DES SYSTÈMES (SAD)

MODULE II

SUJETS COUVERTS

Introduction à l'analyse et la conception des systèmes

Système de théorie/Concept

Sujet 3 : Cycle de vie du développement des systèmes (SDLC)

Thème 4 : Définition du problème

Sujet 5 : Étude de faisabilité

Analyse des systèmes

Sujet 7 : Conception et développement de systèmes

Sujet 8 : Mise en œuvre du système

Sujet 9 : Maintenance et Revue du Système

Sujet 10 : Documentation du système

Sujet 11 : Acquisition de systèmes

Sujet 11 : Gestion de projet TIC

Sujet 12 : Tendances Émergentes dans la Dépression Saisonnière

 SUJET 1 : INTRODUCTION À L'ANALYSE ET À LA CONCEPTION DES SYSTÈMES

THÉORIE

[Link].T0 Objectifs spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) expliquer la signification de la DÉS

b) décrire les composants d'un système d'information

c) décrire les rôles des parties prenantes des systèmes d'information

d) décrire les types de systèmes d'information

CONTENU
Signification des termes :

Système

Un système est un ensemble d'un regroupement ordonné de composants interdépendants liés/assemblés.

selon un plan pour atteindre un objectif spécifique. Les exemples incluent, système informatique, musique
système etc.

Information
Ceci est les données traitées qui sont significatives pour l'utilisateur. Cela peut être stocké, ainsi que cela peut être
communiqué

système d'information

Est un ensemble de personnes, de procédures, d'une base de données et (parfois) de matériel et de logiciels qui
collecte, traite, stocke et communique des données pour le traitement des transactions au niveau opérationnel et
informations pour soutenir la prise de décision de la direction.

technologie de l'information

C'est un terme qui englobe toutes les formes de technologie utilisées pour créer, stocker, échanger et utiliser.
information sous ses diverses formes c'est-à-dire.

Données commerciales
Films
Présentations multimédias, etc.

Data:

1
 Ce sont des faits bruts qui n'ont aucune forme de signification en termes alphanumériques (lettre,
et des chiffres), du texte et des figures, des caractères spéciaux, etc. à l'utilisateur.

Analyse :

Ceci est l'évaluation/étude détaillée des composants des systèmes existants et de son
exigences.

Analyse du système :

Implique l'évaluation des composants du système actuel et de ses exigences à l'aide des faits recueillis ou
informations. Il faut évaluer si les besoins des utilisateurs actuels et prévus sont satisfaits, si
il/elle ne devrait pas donner de recommandations sur ce qui doit être fait.

Objets de l'analyse des systèmes :

Pour déterminer les besoins d'information d'une organisation et des utilisateurs de l'information
Détermination des activités actuelles du système, c'est-à-dire des fonctions impliquées dans la conversion des entrées.
à des résultats
Détermination des résultats système prévus
Détermination des ressources nécessaires pour le système prévu
Déterminez les capacités requises dans le système pour répondre aux besoins d'information de l'organisation.

Composants d'un système d'information

Les composants d'une information comprennent :

Les gens : utilisent les systèmes pour satisfaire leurs besoins d'information. Ils incluent les utilisateurs finaux et les opérations.
personnel tel que les opérateurs d'ordinateurs, les analystes système, les programmeurs, les administrateurs de données, etc.
Matériel informatique : il s'agit des équipements et dispositifs informatiques physiques, qui fournissent pour
cinq fonctions majeures à savoir :
Saisie de données
oOutput
Processeur central (fonctions de calcul et de contrôle)
Stockage secondaire pour les données et les programmes
oCommunication
Le logiciel informatique : fait référence aux instructions qui dirigent les opérations de l'ordinateur.
matériel. Les logiciels informatiques sont classés en logiciels système et logiciels d'application.
Des exemples de logiciels système incluent : OS, Windows, Linux, Macintosh, etc.
Exemples de logiciels d'application : les logiciels généraux (Microsoft Office)
La base de données : contient toutes les données utilisées par le logiciel applicatif. Un ensemble individuel de données stockées est

appelé un fichier.
Procédure : ce sont des étapes définies suivies pour accomplir une tâche donnée. Les procédures existent dans
formes physiques sous forme de manuels ou de livrets d'instructions. Trois types principaux de procédures sont requis.
Instructions pour les utilisateurs de l'application pour enregistrer des données, utiliser un terminal pour la saisie ou la récupération de données
Instructions pour la préparation des entrées par le personnel de préparation des données.
Instructions de fonctionnement pour le personnel des opérations informatiques.

2
 Types de systèmes d'information

Systèmes de traitement des transactions

Qu'est-ce qu'un système de traitement des transactions ?

Les systèmes de traitement des transactions sont des systèmes de niveau opérationnel à la base de la pyramide. Ils
sont généralement opérés directement par les travailleurs de l'atelier ou le personnel de première ligne, qui fournissent les données clés

nécessaire pour soutenir la gestion des opérations. Ces données sont généralement obtenues par le
suivi automatisé ou semi-automatisé des activités de bas niveau et des transactions de base.

Fonctions d'un TPS

Les TPS ne sont finalement guère plus que de simples systèmes de traitement des données.

Fonctions d'un TPS en termes de besoins en traitement des données

Entrées Traitement Sorties

Validation
Tri Listes
Transactions Liste Détail rapports
Événements Fusion Action rapports
Mise à jour Rapports de synthèse ?
Calcul

Quelques exemples de TPS

systèmes de paie
Systèmes de traitement des commandes

Systèmes de réservation
Systèmes de contrôle des stocks

Systèmes de paiements et de transferts de fonds

Le rôle du TPS

Produire des informations pour d'autres systèmes

Franchir des frontières (internes et externes)

Utilisé par le personnel opérationnel et les niveaux de supervision

Orienté vers l'efficacité

Systèmes d'information de gestion

3
 Qu'est-ce qu'un Système d'Information de Gestion ?

Pour des raisons historiques, de nombreux types différents de systèmes d'information se trouvent dans le commerce.
les organisations sont appelées « Systèmes d'Information de Gestion ». Cependant, au sein de notre
modèle pyramidal, les Systèmes d'information de gestion sont des systèmes de niveau management qui sont utilisés
par les cadres intermédiaires pour aider à garantir le bon fonctionnement de l'organisation à court et moyen terme
Le terme. Les informations hautement structurées fournies par ces systèmes permettent aux gestionnaires d'évaluer
la performance d'une organisation en comparant les résultats actuels avec les résultats précédents.

Fonctions d'un Système d'Information de Management (SIM)

Les SIG sont construits sur les données fournies par les STP.

Fonctions d'un SIS en termes de exigences de traitement des données

Entrées Traitement Sorties

Interne Tri des transactions Résumé rapports

Interne Fusion des fichiers Action rapports
Données structurées Résumer Rapports détaillés

Quelques exemples de SIG

Systèmes de gestion des ventes

Systèmes de contrôle des stocks
Systèmes de budgétisation

Systèmes de Rapport de Gestion (MRS)

Systèmes de gestion des ressources humaines (GRH)

Le rôle des SI

Basé sur les flux d'informations internes

Soutenir des décisions relativement structurées
Inflexible et ayant peu de capacité analytique
Utilisé par les niveaux managériaux inférieurs et intermédiaires

traite du passé et du présent plutôt que du futur

Orienté vers l'efficacité ?

Systèmes d'aide à la décision

Un système d'aide à la décision peut être considéré comme un système basé sur la connaissance, utilisé par des cadres supérieurs.

qui facilite la création de connaissances et permet leur intégration dans l'organisation. Ces
Les systèmes sont souvent utilisés pour analyser les informations structurées existantes et permettre aux gestionnaires de projeter

les effets potentiels de leurs décisions dans le futur. De tels systèmes sont généralement interactifs et sont

4
 utilisés pour résoudre des problèmes mal structurés. Ils offrent un accès à des bases de données, des outils analytiques, permettent des "que

si des simulations, et peuvent soutenir l'échange d'informations au sein de l'organisation.

Fonctions d'un système d'information décisionnel

DSS manipule et s'appuie sur les informations d'un MIS et/ou TPS pour générer des insights et
nouvelles informations.

Fonctions d'un Système d'Aide à la Décision en termes d'exigences de traitement des données

Entrées Traitement Résultats

Modélisation
Interne Transactions Résumé rapports
Simulation
Interne Fichiers Prévisions
Analyse
Informations externes? Graphiques / Diagrammes
Résumé

Quelques exemples de DSS

Systèmes d'aide à la décision de groupe (SADG)

Travail coopératif soutenu par ordinateur (CSCW)
systèmes oLogistics
Systèmes de planification financière

Modèles de tableurs ?

Le rôle des DSS

Soutenir des décisions mal structurées ou semi-structurées

Avoir une capacité d'analyse et/ou de modélisation
Utilisé par des niveaux de direction plus élevés

sont concernés par la prévision de l'avenir

Êtes-vous orienté vers l'efficacité ?

Systèmes experts

Systèmes d'automatisation de bureau

5
 Les systèmes d'automatisation de bureau, également appelés OAS, se composent d'applications conçues pour aider le
travail quotidien de l'administration d'une organisation, partie de ce type de logiciel sont les mots
processeurs, le calcul des feuilles, les éditeurs de présentations, l'email client, etc.. Quand
plusieurs de ces applications sont regroupées dans un seul paquet logiciel pour une distribution facile et
l'installation, l'ensemble est connu sous le nom de suite bureautique.

Peut-être le logiciel le plus populaire qui peut correspondre à la définition de OAS (et au bureau
Suite ) est Microsoft Office dans toutes ses versions. Ce logiciel, fait partie de la société Microsoft ,
fonctionne officiellement sous les systèmes d'exploitation Microsoft Windows et Apple Mac OS, bien que
cela le fait sous Linux lors de l'utilisation d'émulateurs.

Il existe d'autres suites bureautiques disponibles pour tout utilisateur à être distribuées librement, dont certaines sont :

Aujourd'hui, avec l'émergence de la philosophie du Web 2.0, les suites bureautiques prolifèrent en ligne.
qui ne sont rien d'autre que des applications qui effectuent les mêmes fonctions que l'OAS classique
bureau, mais disponible pour une utilisation dans n'importe quel portail Internet. Ces suites ont l'avantage qu'un utilisateur
peut travailler avec vos propres documents depuis n'importe quel ordinateur connecté à Internet, également dans ceux-ci
Les systèmes facilitent généralement le partage de documents, ce qui facilite le travail collaboratif.

Autres

2. Systèmes d'information exécutifs

Qu'est-ce qu'un EIS ?

Les systèmes d'information exécutifs sont des systèmes d'information de niveau stratégique qui se trouvent au sommet de
la Pyramide. Ils aident les dirigeants et les cadres supérieurs à analyser l'environnement dans lequel le
l'organisation fonctionne, pour identifier des tendances à long terme, et pour planifier des actions appropriées. Le
l'information dans de tels systèmes est souvent faiblement structurée et provient à la fois de sources internes et externes
Les systèmes d'information exécutifs sont conçus pour être utilisés directement par les cadres sans
le besoin d'intermédiaires et facilement adapté aux préférences de l'individu qui les utilise.

Fonctions d'un EIS

EIS organise et présente des données et des informations provenant à la fois de sources de données externes et de systèmes d'information de gestion internes.

ou TPS afin de soutenir et d'étendre les capacités inhérentes des dirigeants seniors.

Fonctions d'un EIS en termes d'exigences de traitement des données

Entrées Traitement Résultats

Externe Résumé des données Résumé rapports

Interne Simulation de fichiers Prévisions

6
 Modèles pré-définis Forer Graphiques / Courbes

Quelques exemples de SIE

Les systèmes d'information pour dirigeants ont tendance à être très individualisés et sont souvent fabriqués sur mesure pour un
groupe de clients particulier ; cependant, un certain nombre de solutions EIS prêtes à l'emploi existent et beaucoup
Les systèmes de niveau entreprise offrent un module EIS personnalisable.

Le rôle de l'EIS

sont préoccupés par la facilité d'utilisation

sont concernés par la prédiction de l'avenir

sont orientés vers l'efficacité
sont très flexibles
Soutenir des décisions non structurées
Utilisez des sources de données internes et externes

Utilisé uniquement aux niveaux de direction les plus élevés

Rôles des parties prenantes des systèmes d'information

propriétaires de systèmes

Sont généralement les individus ayant un contrôle budgétaire sur le système. Cette personne devrait être capable de
autoriser l'achat de logiciels et/ou de matériel nécessaire pour répondre aux exigences de la politique, et/ou
avoir l'autorité de décommissionner le système.

Les propriétaires du système possèdent les systèmes parce qu'ils ont investi dans les actifs. Ils sont
responsable d'eux et reconnaître leur potentiel. Ils gardent vos clients heureux et ont un impact
votre résultat net. Bien sûr, vous voulez maximiser leur valeur. Pour cela, vous devez surveiller
efficacité de performance et événements de maintenance. Vous devez suivre et gérer vos actifs pour
réaliser une conformité totale et des résultats d'investissement positifs.

. Les utilisateurs du système sont classés en deux catégories à savoir :

. Utilisateurs du système interne
.
. Travailleurs de bureau et de services
. Personnel technique et professionnel
. Superviseurs, Cadres intermédiaires et Cadres supérieurs
.

7
. Les utilisateurs du système externe se composent de ce qui suit :
. Clients
. Fournisseurs
. Partenaires

. Les utilisateurs finaux du système font référence aux personnes qui utilisent des ordinateurs pour effectuer leur travail, comme
opérateurs de bureau. De plus, les utilisateurs finaux peuvent être divisés en différentes catégories.

. Les tout premiers utilisateurs sont les utilisateurs pratiques, qui interagissent réellement avec le système. Ce sont les personnes
qui alimente les données d'entrée et obtient des données de sortie.

. D'autres utilisateurs sont les utilisateurs finaux indirects qui n'interagissent pas avec le matériel et le logiciel des systèmes.
Cependant, ces utilisateurs bénéficient des résultats de ces systèmes. Ce type d'utilisateurs peut être
responsables d'organisation utilisant ce système.
. Il existe un troisième type d'utilisateurs qui ont des responsabilités de gestion pour les systèmes d'application.
Ils supervisent l'investissement dans le développement ou l'utilisation du système.

. Le quatrième type d'utilisateurs est constitué des cadres supérieurs. Ils sont responsables de l'évaluation de l'organisation.
exposition au risque provenant de la défaillance des systèmes.

Analystes Système

1. Les analystes systèmes collaborent avec les professionnels de l'informatique tout au long du SDLC

Les analystes systèmes ne se limitent certainement pas à travailler uniquement sur des projets de développement logiciel. Pourtant,
pour certains analystes de systèmes, c'est tout ce sur quoi ils travaillent. À chaque étape du cycle de vie du développement des systèmes
cycle de développement logiciel (SDLC), ils font équipe avec des programmeurs, des concepteurs de systèmes, des testeurs QA, des intégrateurs de systèmes
et ainsi de suite, pour construire des systèmes.

2. Les analystes systèmes documentent les systèmes

Parce qu'ils collaborent avec des professionnels à travers l'ensemble du SLDC, les analystes systèmes servent souvent
en tant que courtiers d'information. La documentation préparée par les analystes systèmes devient souvent la finale
un mot sur ce qu'est un système ou ce qu'il fait.

Les analystes systèmes documentent les systèmes informatiques pour comprendre, modifier, améliorer et aider à les construire.

systèmes. En gros, ils documentent ce qui se passe dans les systèmes actuels. Mais ils documentent aussi
ce qui peut être attendu dans des systèmes qui n'ont pas encore été construits. Ce travail est souvent effectué dans
collaboration avec des rédacteurs techniques, des concepteurs de systèmes et des architectes de systèmes. Choses typiques qui
les documents des analystes systèmes incluent :

8
Scénarios d'utilisateur
Activités fonctionnelles
Classes
Flux de données
Interfaces entre systèmes

Exemples de documents que les analystes systèmes rédigent ou co-rédigent incluent :

Documents de exigences
Études de faisabilité
Spécifications de conception
Kits de développement logiciel (SDK)
Organigrammes et diagrammes
Documents de formation
Documents de test
Plans de reprise après sinistre (PRS)

3. Les analystes systèmes rassemblent et analysent les exigences

La surcharge d'informations arrive parfois à chacun d'entre nous. C'est là que les analystes systèmes interviennent.
pratique. Ils transforment une avalanche d'informations apparemment incompréhensible en quelque chose
utile et tout ce qui traduira les objectifs commerciaux en solutions techniques. Voici quelques
exemples de questions que les analystes systèmes peuvent poser lors de la phase des exigences d'un projet :

Objectifs

Que voulez-vous que le système fasse ?

Qu'est-ce qui est inclus et exclu du périmètre de ce projet ?
Quand voulez-vous que le système soit opérationnel ?
Combien d'argent dans le budget est consacré à l'analyse des systèmes ?

Problèmes

Quels problèmes le nouveau système proposé résoudra-t-il ?

Quels problèmes souhaitez-vous résoudre qui concernent le système existant ?
Y a-t-il un journal de tous les bugs logiciels ?
Les bugs ont-ils été priorisés et classés ?
Quel logiciel de suivi des bogues utilisez-vous ?

Changements

Quels types de changements sont nécessaires ?

Les changements sont-ils classés comme des modifications ou des améliorations ?

9
 Il existe plusieurs types de exigences qu'un analyste système collectera et analysera. Trois des ...
les principaux sont :

Exigences commerciales. Exigences de haut niveau que les responsables et les directeurs auraient typiquement.
comprendre.
Exigences fonctionnelles. Exigences détaillées qui spécifient exactement ce qui doit être
livrés. Ceux-ci sont généralement lus par des analystes commerciaux, des ingénieurs logiciels et des chefs de projet.
les gestionnaires.
Exigences techniques. Exigences détaillées sur la façon dont le système est construit, y compris lequel
langue dans laquelle il sera programmé, quels standards doivent être suivis, etc. Exigences techniques
sont souvent lus par des architectes logiciels et des développeurs.

4. Les analystes systèmes choisissent, mettent à niveau et configurent les logiciels

Il est clair que tous les logiciels ne sont pas conçus sur mesure. Il existe des milliers d'applications qui sont
préemballés. Ce type de programmes peut être personnalisé en définissant diverses préférences, mais ils
ne peut pas être aussi individualisé que les logiciels programmés sur mesure.

Les analystes de systèmes jouent souvent un rôle crucial dans le choix et la configuration des logiciels. Voici
Quelques exemples de tâches que les analystes systèmes effectuent en collaboration avec les architectes systèmes et les systèmes
designers

Sélection de logiciel

Invitation aux fournisseurs de logiciels à soumettre des demandes de propositions (RFP).

Vérification des fournisseurs.
Révision des systèmes.
Déterminer quel système correspond le mieux à vos exigences.
Recommander quel système mettre en œuvre.

Configuration logicielle

Travailler avec l'administrateur système pour installer le logiciel.

Attribution des rôles et des privilèges aux utilisateurs.

5. Les analystes systèmes travaillent avec des tonnes de personnes

Pour accomplir le travail, les analystes systèmes doivent travailler avec une grande variété de personnes, en plus des technologies de l'information.
des professionnels avec lesquels ils collaborent toujours. Voici quelques-uns d'entre eux :

Les sponsors sont les personnes qui souhaitent qu'un système soit construit afin qu'elles puissent en tirer de l'argent.
les analystes systèmes travaillent avec des sponsors pour évaluer si l'investissement financier dans
un système sera récupéré par des gains en efficacité et en efficacité.
Les analystes de systèmes travaillent souvent avec des programmeurs qui écrivent du code pour modifier des systèmes existants.
et/ou en construire de nouveaux.

10
 Les analystes systèmes travaillent avec des rédacteurs techniques pour rédiger des guides d'utilisation, des aperçus techniques,

manuels d'instruction et questions fréquentes (FAQ).

Les analystes systèmes travaillent avec les analysts de l'Assurance Qualité (AQ) pour tester les systèmes afin de garantir que
les exigences critiques sont satisfaites.

les concepteurs de systèmes : ce sont les personnes concernées par la conception de systèmes et incluent les
suivant
Administrateurs de bases de données

Architectes Réseau
oWeb Architectes
Artistes graphiques
Experts en sécurité
spécialistes en technologie

Développeurs de systèmes :
Ce sont les personnes qui créent et écrivent des programmes informatiques. Certains développent les applications.
des programmes qui permettent aux gens d'effectuer des tâches spécifiques sur un ordinateur ou un autre appareil. D'autres développent le
systèmes sous-jacents qui font fonctionner les dispositifs ou contrôlent les réseaux

Autre

Programmeurs informatiques

Les programmeurs informatiques écrivent du code pour créer des logiciels. Ils transforment les conceptions des programmes.
créé par des développeurs de logiciels et des ingénieurs en instructions qu'un ordinateur peut suivre.

Constructeurs de systèmes

. Les programmeurs d'applications (écrivent des programmes d'application)

. Les programmeurs système (écrivent des programmes de systèmes d'exploitation)
. Programmeurs de bases de données
. Administrateurs réseau
. Administrateurs de la sécurité
. Webmasters (gèrent des pages web)
. Intégrateurs de logiciels (ils intègrent différents logiciels et ont un système fonctionnel)

Architectes de réseaux informatiques :

Concevoir et construire des réseaux de communication de données, y compris des réseaux locaux (LAN), des réseaux étendus
réseaux (WAN), et intranets. Ces réseaux vont d'une petite connexion entre deux
bureaux d'une série multinationale de systèmes de communication répartis à l'échelle mondiale.

Spécialistes du support informatique :

11
Fournir de l'aide et des conseils aux personnes et aux organisations utilisant des logiciels ou des équipements informatiques.
Certains, appelés spécialistes du support des réseaux informatiques, soutiennent les technologies de l'information (TI)
employés au sein de leur organisation. D'autres, appelés spécialistes du support aux utilisateurs d'ordinateurs, assistent les non-
Les utilisateurs informatiques qui ont des problèmes d'ordinateur.

Administrateurs de bases de données (DBA) :

Utilisez des logiciels spécialisés pour stocker et organiser des données, telles que des informations financières et des données clients.
enregistrements d'expédition. Ils s'assurent que les données sont disponibles pour les utilisateurs et sont sécurisées contre

accès non autorisé.

Réseaux informatiques :

Sont des parties critiques de presque chaque organisation. Les administrateurs de réseaux et de systèmes informatiques sont
responsable de l'exploitation quotidienne de ces réseaux.

Développeurs web : Ce sont les personnes qui conçoivent et créent des sites web.

Ils sont responsables de l'apparence du site. Ils sont également responsables de l'aspect technique du site.
aspects, tels que la performance et la capacité, qui sont des mesures de la vitesse d'un site web et de la façon dont
beaucoup de trafic que le site peut gérer. Ils peuvent également créer du contenu pour le site.

12
SYSTÈME 2 : THÉORIE/CONCEPT DES SYSTÈMES

THÉORIE

[Link]. Objectifs spécifiques T0

À la fin de ce sujet, le stagiaire devrait être capable de :

a) Expliquer le concept de systèmes

b) Décrivez les composants d'un système

c) Décrivez la classification des systèmes

d) Expliquer les propriétés du système

e) Décrivez les types de systèmes

CONTENU

Théorie/concept des systèmes.

La théorie des systèmes a été introduite par le biologiste L. von Bertalanffy dans les années 1930 en tant qu'outil de modélisation

qui prend en compte les interrelations et les chevauchements entre les disciplines séparées. La réalité est
que lorsque les scientifiques et les philosophes ont d'abord essayé d'expliquer comment les choses fonctionnaient dans l'univers,
il n'y avait pas de disciplines séparées. Il n'y avait simplement des questions auxquelles répondre. Mais au fur et à mesure que nous avons commencé

comprenant de plus en plus, les sciences se sont divisées en chimie, physique, biologie, et ensuite
biophysique, biochimie, chimie physique, etc. afin que les composants liés à un problème soient
étudié en isolation les uns des autres. La théorie des systèmes introduite par von Bertalanffy
nous rappelle la valeur de l'intégration des parties d'un problème. Les problèmes ne peuvent pas être résolus aussi bien si
ils sont considérés de manière isolée des composants interconnectés. Un énorme avantage des systèmes
les analystes ont dans la connaissance des définitions de la théorie des systèmes qu'ils nous présentent comme idéaux
lignes directrices pour notre familiarisation initiale avec un nouveau problème, qui est bien sûr un nouveau système.

Termes/PRINCIPES de la théorie des systèmes

Problème
Un problème peut être une question à la recherche d'une réponse, une situation (comme une situation existante)
système d'information) qui ne fonctionne pas correctement et nécessite des améliorations, ou un nouveau
opportunité ou idée digne d'une considération plus approfondie. En d'autres termes, lorsque nous parlons

13
 d'un "problème" dans l'analyse et la conception des systèmes, nous ne voulons pas nécessairement dire qu'il y a
quelque chose ne va pas. Nous voulons dire qu'il y a une situation qui doit être comprise et un
solution à déterminer.
Système
Un système est un ensemble de composants liés qui fonctionnent ensemble dans un environnement particulier pour
effectuer toutes les fonctions nécessaires pour atteindre l'objectif du système.
Recherche d'objectif

Un système est par définition orienté vers un objectif. Lorsque la définition d'un système dit qu'un
Les composants du système travaillent ensemble pour atteindre un objectif commun, cela signifie que
le système cherche à atteindre un objectif. Par exemple, l'objectif du système digestif est
assurez-vous que la nourriture est digérée, avec certains sous-produits entrant dans la circulation associée
système pour nourrir le corps et d'autres sous-produits étant expulsés. L'objectif d'une paie
le système est susceptible de produire des résultats complets, corrects et en temps voulu sous forme de
chèques, rapports et fichiers d'historique mis à jour. Il est important de pouvoir identifier le
objectifs de tout système existant ou nouveau afin de pouvoir le comprendre et évaluer son
efficacité.Dans un système d'information, les composants incluent les personnes, les procédures, les données,
logiciel et matériel.
Entropie
L'entropie est une mesure du degré de désordre dans un système. C'est un terme familier dans
la thermodynamique, lorsqu'on considère les systèmes chimiques, et est également pertinente pour l'information
systèmes. Le concept d'entropie dit que tout système tendra vers le désordre. Savoir
que nous pouvons mettre en place des contrôles pour surveiller la justesse de la sortie d'un système.
Environnement interne
Un système fonctionne dans un environnement comportant à la fois des composants internes et externes. Son
L'environnement interne est cette partie de son environnement sur laquelle il a un certain contrôle. Si
un aspect de l'environnement interne cause des difficultés au système, que
l'aspect peut être modifié. Par exemple, un système d'information particulier fonctionne dans un contexte particulier.
environnement de bureau. Si une exigence du système d'information est que ses utilisateurs doivent
collecter des données qui n'ont pas été collectées auparavant, cette nouvelle activité peut leur être demandée.
Environnement Externe
L'environnement externe d'un système est la partie de son environnement sur laquelle il n'a aucun
contrôle, mais cela affecte toujours les exigences du système. Par exemple, dans une paie
système, les lois fiscales de l'autorité des revenus, les lois NHIF affectent les procédures dans le système.
Les lois fiscales doivent être reflétées dans le système, et si les lois changent, le système doit
changer pour s'adapter à ces changements. Donc, un analyste doit être conscient des exigences
des environnements internes et externes dans lesquels un système d'information fonctionnera.
Sous-système
Un système est généralement composé de systèmes autonomes mais interconnectés qui sont appelés
sous-systèmes. Il est important de pouvoir reconnaître ces sous-systèmes, car
Comprendre cette interdépendance est vital pour développer un système complet.

Supersystème
Un système composé de deux systèmes ou plus peut être appelé un supersystème de ceux-ci.
systèmes.

14
 Limite du système
Une frontière de système peut être considérée comme le point auquel les données circulent (peut-être en tant que sortie)
d'un système à un autre (peut-être comme entrée). Le degré auquel les données peuvent circuler librement
d'un système à un autre est connu sous le nom de perméabilité de la frontière. Une perméable
la frontière permet aux données de circuler librement, résultant en un système ouvert. Une imperméabilité
la frontière est celle qui contrôle strictement (voire restreint) l'acceptation ou la distribution de
données, résultant en un système fermé.

Interdépendance
L'un des concepts les plus importants de la théorie des systèmes est la notion d'interdépendance
entre les systèmes (ou sous-systèmes). Les systèmes existent rarement en isolation. Par exemple, un service de paie
le système doit accéder et mettre à jour un système de personnel. Il est important pour un analyste de
identifiez ces interdépendances tôt. Il se peut que les changements que vous apportez à l'un
le système affectera un autre de manières que vous n'avez pas considérées, ou vice versa.
Composants/éléments d'un système

entrée

Tout ce que nous souhaitons intégrer dans un système pour un certain type d'utilisation. Une variété de sources est utilisée.
à entrer : clavier, scanner, microphone, souris, voire un autre ordinateur. Ce que nous entrons a un
objectif - mais tant qu'il n'est pas traité et généré sous une forme de sortie, cela ne nous sert pas beaucoup
bien.

traitement

Le traitement se déroule dans les parties internes de l'ordinateur. C'est l'acte de prendre des données saisies.
et en le transformant en quelque chose d'utilisable. Ce que nous voyons généralement à l'écran sur l'ordinateur d'aujourd'hui
le monde (connu sous le nom de ce que vous voyez est ce que vous obtenez ou WYSIWYG) est le résultat de notre saisie étant
traité par un programme afin que nous puissions avoir une sortie utilisable :

Sortie
La sortie, ou information traitée dans un format utilisable, se présente sous plusieurs formes différentes : moniteur ou
imprimante pour le travail visuel, un haut-parleur pour l'audio. Parfois, notre sortie est à court terme, comme l'impression d'un
photo, et parfois ce sur quoi nous travaillons doit être conservé pendant un certain temps. C'est là qu'intervient le stockage

entre

Le stockage est le terme utilisé pour indiquer que nous allons sauvegarder des données pendant une période de temps. Nous stockons pour
de nombreuses raisons : pour référence future ; pour prévenir une perte totale de données ; Mais, le stockage est vital. Il y a
plusieurs supports sur lesquels nous pouvons conserver les données de sortie et les données traitées : un disque dur, une clé USB, un

CD.

Retour d'information

15
Pour être efficace et efficient, un système a besoin d'un mécanisme de rétroaction qui peut déterminer si le
Les sorties du système sont ce qu'elles devraient être. Sinon, un système devrait avoir la capacité d'ajuster ses
entrées ou processus pour améliorer les résultats. Un système idéal est autocontrôlé. Le retour d'information
Le mécanisme dans un système d'information peut être automatisé ou peut être manuel.
Types de systèmes

Systèmes créés par l'homme

Comme nous l'avons défini précédemment, un certain nombre de ces systèmes sont construits, organisés,
et entretenus par des humains. Ces systèmes fabriqués par l'homme incluent des choses telles que :

Système social : inclure des organisations de lois, de doctrines, de clients, etc.

Systèmes de transport : cela inclut les réseaux d'autoroutes, de canaux, de compagnies aériennes, d'océans
pétroliers etc.
Systèmes de communication : comprend le téléphone, le télex, les signaux de fumée, les signaux manuels utilisés
par des traders du marché boursier, etc.
Systèmes de fabrication : où nous avons des usines, des chaînes de montage, etc.
Systèmes financiers : cela inclut la comptabilité, l'inventaire, le grand livre, la bourse.

La plupart de ces systèmes comprennent des ordinateurs aujourd'hui, en effet beaucoup ne pourraient pas survivre sans.
les ordinateurs. Cependant, il est tout aussi important de souligner que de tels systèmes existaient avant cela.
des ordinateurs, certains de ces systèmes sont encore complètement non informatisés et peuvent demeurer
de cette manière pendant de nombreuses années à venir. En tant qu'analyste système, vous supposerez naturellement que chaque système

que vous contactez devrait être informatisé, et le client ou l'utilisateur (le propriétaire de
le système) avec lequel vous interagissez supposera généralement que vous avez ce type de biais.

Pourquoi certains systèmes d'information ne devraient-ils pas être automatisés ? Il peut y avoir de nombreuses raisons, mais ici

sont quelques-uns des plus courants :

Coût : il peut être moins cher de continuer à effectuer les fonctions du système et de stocker le
informations systèmes manuellement.
Praticité : un système automatisé peut prendre trop de place, faire trop de bruit,
générer trop de chaleur, ou consommer trop d'électricité, etc.
Sécurité : si le système d'information maintient des données sensibles et confidentielles, l'utilisateur
peut ne pas sentir qu'un système automatisé est suffisamment sécurisé. L'utilisateur peut vouloir la capacité
pour garder les informations physiquement protégées et verrouillées.
Maintenabilité : l'utilisateur pourrait faire valoir qu'un système d'information informatisé serait
économique sauf qu'il n'y a personne dans le personnel capable de maintenir l'ordinateur
matériel et logiciel, personne ne réparerait le système s'il tombait en panne.
Système automatisé
Les systèmes automatisés sont en réalité des systèmes créés par l'homme qui interagissent avec ou sont contrôlés par un ou
plus d'ordinateurs.. sans aucun doute, vous avez vu de nombreux exemples différents de systèmes automatisés dans votre
la vie quotidienne. Il semble que chaque aspect de notre société moderne soit informatisé. En conséquence, nous
peut distinguer de nombreux types de systèmes automatisés.

16
 Bien qu'il existe de nombreux types de systèmes automatisés, ils ont tous tendance à avoir des points communs.
composants. Et ces composants incluent :

Matériel informatique - Processeurs, disques, imprimantes, unités de bande magnétique, etc.

Logiciel informatique - programmes système tels que les systèmes d'exploitation, les systèmes de base de données, et
programmes de contrôle des télécommunications et programmes d'application qui exécutent le
fonctions que l'utilisateur souhaite.
Les gens - ceux qui font fonctionner le système.
Données - l'information que le système se souvient pendant une période de temps
Procédures - ce sont les règles, politiques formelles et instructions pour fonctionner.
système

Une classification plus utile des systèmes automatisés inclut :

Systèmes en ligne
Systèmes temps réel
Systèmes d'aide à la décision
Systèmes à base de connaissances.

Classification des systèmes

ouvert Vs fermé
Un système ouvert est celui qui interagit avec son environnement et échange donc des informations.
matériel, ou énergie avec l'environnement, y compris des entrées aléatoires et indéfinies. Systèmes ouverts
sont adaptatifs par nature car ils ont tendance à réagir avec l'environnement de manière à s'organiser.
le sens qu'ils changent leur existence continue. De tels systèmes sont 'autonomes', car ils
changer leur organisation en réponse aux conditions changeantes.
Un système fermé est celui qui n'interagit pas avec son environnement. De tels systèmes, en affaires
Le monde, est rare. Ainsi, les systèmes qui sont relativement isolés de l'environnement mais pas
Les systèmes complètement fermés sont appelés systèmes fermés.

adaptatif

Un système est dit adaptatif s'il se modifie avec les changements de son environnement.
Un système gouvernemental démocratique est un exemple de système adaptatif car il évolue pour
s'adapter aux changements de l'environnement.
Un système non adaptatif ne réagit pas aux changements de son environnement.

Un système de gouvernance autocratique est un exemple de système non adaptatif. Il ne le fait pas.
changer ou s'adapter aux changements dans l'environnement.

déterministe

Un système déterministe est celui dans lequel l'occurrence de tous les événements est connue avec certitude. Si le
une description de l'état du système à un moment particulier de son fonctionnement est donnée, le prochain état
peut être parfaitement prédit.

Probabiliste

17
Un système probabiliste est un système dans lequel l'occurrence d'événements ne peut pas être parfaitement prédite.
Bien que le comportement d'un tel système puisse être décrit en termes de probabilité, un certain degré
L'erreur est toujours attachée à la prédiction du comportement du système.

Classification des propriétés

PROPRIÉTÉS DURES
La plupart des problèmes d'affaires ou organisationnels peuvent être définis en termes d'information avec
à la fois des propriétés dures et molles. Quel que soit le secteur dans lequel nous travaillons, certains des problèmes auxquels nous faisons face

peut être mesuré avec précision, par exemple le coût d'un article, la résistance d'un élément particulier
morceau de matériau, ou le nombre d'employés dans notre organisation - et la réponse est
non conditionnée par le sens de valeur du mesureur. Ces données sont dites avoir du mal
propriétés.

Propriétés Douces

D'autre part, certains problèmes ne peuvent pas être mesurés avec une telle précision, et le
L'évaluation contient au moins un élément de jugement ou est subjective d'une certaine manière.
Des informations telles que l'attractivité d'un matériau, si nous devrions recruter un
personne particulière ou quel sera le taux moyen d'inflation des prix au cours des 10 prochaines années
les années sont subjectives et nous disons qu'elles ont des propriétés douces.

Il va sans dire que ces définitions peuvent devenir floues. Par exemple, lorsque nous mesurons
les absences au travail, que quelqu'un soit absent ou non semble être clair
coupe et pas une question de jugement, nous pourrions donc être enclins à considérer cette information comme
ayant des propriétés dures.

18
 SUJET 3 : VIDE DU CYCLE DE VIE DU DÉVELOPPEMENT DES SYSTÈMES (SDLC)

THÉORIE

[Link].T0 Objectifs Spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) expliquer la signification du SDLC

b) décrire les étapes du SDLC

CONTENU
Signification de SDLC

Phases du SDLC

définition du problème
étude de faisabilité
analyse des systèmes
conception et développement de systèmes
mise en œuvre
maintenance et révision

Le cycle de développement des systèmes :

L'approche systémique peut être appliquée à la solution de nombreux types de problèmes. Lorsque cela
implique le développement de solutions de systèmes d'information pour des problèmes d'entreprise, on l'appelle
développement de systèmes d'information ou développement d'applications. La plupart des informations basées sur des ordinateurs
les systèmes sont conçus, conçus et mis en œuvre à l'aide de certaines formes de développement systématique
processus. Dans ce processus, les utilisateurs finaux et les spécialistes de l'information conçoivent des systèmes d'information basés sur

sur une analyse des besoins d'information d'une organisation. Ainsi, une grande partie de cela
le processus est connu sous le nom d'analyse et de conception des systèmes.

Lorsque l'approche systémique est appliquée au développement de solutions de systèmes d'information, un

un processus ou un cycle multi-étapes émerge. Ceci est souvent appelé les systèmes d'information
cycle de développement, également connu sous le nom de cycle de vie du développement des systèmes (SDLC).
Étapes impliquées et produits générés dans le cycle de développement des systèmes d'information traditionnels :
1. Investigation des systèmes - Produit : Rapport d'étude de faisabilité
2. Analyse des systèmes - Produit : Exigences fonctionnelles
3. Conception des systèmes - Produit : Spécifications des systèmes
4. Mise en œuvre des systèmes - Produit : Système opérationnel
Maintenance des systèmes - Produit : Système amélioré
1 Toutes les activités impliquées sont fortement liées et interdépendantes.
2. Plusieurs activités de développement peuvent se produire en même temps.
3. Différentes parties d'un projet de développement peuvent être à différents stades du cycle de développement.
4. Les analystes peuvent revenir à tout moment pour répéter des activités précédentes afin de modifier et
améliorer un système en cours de développement.

19
5. Des développements tels que les systèmes assistés par ordinateur et le développement par l'utilisateur final automatisent et

modifier certaines des activités de développement des systèmes d'information. Ces développements sont
améliorer la qualité du développement des systèmes et faciliter la tâche des professionnels des systèmes d'information, tout en
permettant à davantage d'utilisateurs finaux de développer leurs propres systèmes.

Démarrer le processus de développement des systèmes :

La première étape du processus de développement des systèmes est la phase d'investigation des systèmes. Cette étape
peut impliquer la prise en compte des propositions générées par un processus de planification des systèmes d'information.
La phase d'enquête comprend également l'étude préliminaire du système d'information proposé.
solutions pour résoudre les problèmes commerciaux des utilisateurs finaux.

Les trois étapes de la phase d'enquête sur les systèmes impliquent :

1. Déterminez si un problème ou une opportunité d'affaires existe.
Définition des problèmes et opportunités :
Pour résoudre un problème ou saisir une opportunité, il est nécessaire de bien comprendre la situation.
main. Cela nécessite de séparer les problèmes des symptômes, de déterminer les objectifs et les contraintes,
et, plus important, considérer le problème ou l'opportunité dans un contexte systémique.
Le problème : - est une condition de base qui entraîne des résultats indésirables.
L'opportunité : - est une condition de base qui présente le potentiel de résultats souhaitables.
Les symptômes : - ne sont que des signaux d'une cause ou d'un problème sous-jacent.
2. Réaliser une étude de faisabilité pour déterminer si une nouvelle ou améliorée information
le système est une solution réalisable

3. Développer un plan de gestion de projet et obtenir l'approbation de la direction.

Études de faisabilité
Parce que le processus de développement d'un grand système d'information peut être coûteux, les systèmes
La phase d'enquête nécessite souvent une étude préliminaire appelée étude de faisabilité. Une faisabilité
étude est une étude préliminaire qui examine les besoins d'information des utilisateurs potentiels et
déterminer les besoins en ressources, les coûts, les avantages et la faisabilité d'un projet proposé.
Étapes d'une étude de faisabilité :
1. Rassembler des informations/données pour une étude de faisabilité.

2. Formaliser un rapport écrit incluant les spécifications préliminaires et un développement

plan pour le système proposé.
3. Soumettez le rapport de gestion pour approbation.
4. Commencer l'analyse système (si la direction approuve les recommandations de la faisabilité)
étude).
L'objectif des études de faisabilité est de :
1. Évaluer des systèmes alternatifs
2. Proposer les systèmes les plus réalisables et souhaitables pour le développement.
La faisabilité d'un système peut être évaluée en termes de quatre grandes catégories :
1. Faisabilité organisationnelle - se concentre sur la façon dont un système d'information proposé soutient le
objectifs de l'organisation et son plan stratégique pour les systèmes d'information.

20
2. Faisabilité économique - se concentre sur les coûts et les avantages tangibles du système proposé
dépassera les coûts de développement et d'exploitation.
3. Faisabilité technique - se concentre sur la fiabilité/les capacités du matériel et des logiciels pour répondre
les besoins du système proposé, et s'ils peuvent être acquis ou développés dans le délai requis
temps.
4. Faisabilité de l'opération - se concentre sur la volonté et la capacité de la direction,
employés, clients, fournisseurs et autres pour faire fonctionner, utiliser et soutenir le système proposé.
Analyse Coût/Bénéfice
Chaque solution légitime aura des avantages ou des bénéfices, ainsi que des inconvénients ou des coûts.
Ces avantages et inconvénients sont identifiés lorsque chaque solution alternative est évaluée.
Ce processus est généralement appelé analyse coût-bénéfice.
Coûts tangibles - sont des coûts et des avantages qui peuvent être quantifiés (par exemple, le coût du matériel et des logiciels,
salaires des employés, et d'autres coûts quantifiables nécessaires pour développer et mettre en œuvre une solution).
Coûts intangibles - coûts et avantages qui ne peuvent pas être quantifiés (par exemple, perte de la bonne volonté des clients ou
le moral des employés causé par des erreurs et des perturbations résultant de l'installation d'un nouveau système.
Avantages tangibles - sont des résultats favorables (par exemple, diminution des coûts de personnel due à une réduction dans
personnel ou une diminution des coûts de stockage des inventaires causée par une réduction des stocks)
Les avantages intangibles - sont difficiles à estimer (par exemple, un meilleur service client ou un service plus rapide et plus précis)
informations pour la direction).
Analyse du système
L'analyse des systèmes est une étude approfondie des besoins en information des utilisateurs finaux qui produit des fonctions.

exigences qui servent de base à la conception d'un nouveau système d'information. Système
L'analyse implique traditionnellement une étude détaillée de :
1. Les besoins en information de l'organisation et des utilisateurs finaux.
2. Les activités, ressources et produits de tout système d'information présent
3. Les capacités des systèmes d'information nécessaires pour répondre aux besoins d'information des utilisateurs finaux.
Analyse organisationnelle
L'analyse organisationnelle implique l'évaluation des systèmes organisationnels et environnementaux et
systèmes impliqués dans toute situation. L'analyse des systèmes implique traditionnellement une étude détaillée de
les organisations :
1. Environnement
2. Structure de gestion
3. Les gens
4. Activités commerciales
5. Systèmes environnementaux, il s'agit de
6. Systèmes d'information actuels
Analyse du système actuel
Avant de concevoir un nouveau système, une analyse détaillée du système actuel (manuel ou automatisé)
doit être complété. Une analyse du système actuel implique l'analyse des activités, des ressources,
et les produits. Vous devez analyser comment le système actuel utilise :
1. Matériel, logiciels, ressources humaines pour convertir les ressources de données en produits d'information, tels que
rapports et affichages.
2. Documentez comment les activités d'information telles que l'entrée, le traitement, la sortie, le stockage et le contrôle se déroulent.

être accompli.

21
 Analyse des exigences fonctionnelles
Cette étape de l'analyse des systèmes est l'une des plus difficiles. Les étapes impliquent :
1. Déterminer des besoins d'information spécifiques
2. Déterminer les capacités de traitement de l'information requises pour chaque activité du système (entrée,
traitement, sortie, stockage et contrôle) pour répondre aux besoins. L'objectif est d'identifier ce qui devrait être
faites NON pas comment le faire.

3. Développer des exigences fonctionnelles (exigences d'information qui ne sont pas liées à la
matériel, logiciels et ressources humaines que les utilisateurs finaux utilisent actuellement ou pourraient utiliser dans le nouveau

système).
Conception des systèmes

L'analyse système décrit ce qu'un système doit faire pour répondre aux besoins d'information des utilisateurs.
La conception du système précise comment le système accomplira cet objectif. La conception des systèmes consiste
d'activités de conception, qui produisent des spécifications de systèmes satisfaisant les exigences fonctionnelles
développées lors de la phase d'analyse des systèmes. Ces spécifications sont utilisées comme base pour :
Développement logiciel
2. Acquisition de matériel
3. Test du système
4. Autres activités de la phase de mise en œuvre.
Conception de l'interface utilisateur, des données et des processus

Le concept de conception des systèmes se concentre sur trois produits ou livrables majeurs, qui devraient en résulter.
à partir de la phase de conception. La conception du système se compose de trois activités :
Conception de l'interface utilisateur
2. Conception des données
3. Conception du processus
Conception de l'interface utilisateur :
La conception de l'interface utilisateur se concentre sur le soutien des interactions entre les utilisateurs finaux et leur
applications informatiques. Les concepteurs se concentrent sur :
La conception de formes d'entrée et de sortie utilisateur attrayantes et efficaces, telles que des interfaces Internet faciles à utiliser.
ou pages web intranet
Conception de méthodes de conversion de documents lisibles par l'homme en entrée lisible par machine, comme
numérisation optique des formulaires commerciaux.

Conseils de design à garder à l'esprit :

Gardez-le simple
Gardez-le propre
Organisez logiquement
La conception de l'interface utilisateur est souvent un processus de prototypage, où des modèles de travail ou des prototypes de
Les méthodes d'interface utilisateur sont conçues et modifiées en tenant compte des retours des utilisateurs finaux. Interface utilisateur

la conception produit des spécifications détaillées pour des produits d'information tels que :
Écrans d'affichage
2. Dialogues interactifs utilisateur/ordinateur
3. Audio responses
4. Formes
5. Documents

22
 6. Rapports.
Conception des données
L'activité de conception des données se concentre sur la conception de la structure des bases de données et des fichiers à utiliser par
un système d'information proposé. La conception des données produit fréquemment un dictionnaire de données, qui
catalogues descriptions détaillées des :
1. Attributs ou caractéristiques des entités (objets, personnes, lieux, événements) à propos desquelles le
le système d'information proposé doit maintenir l'information.
2. Relations que ces entités ont entre elles.
3. Éléments de données spécifiques (bases de données, fichiers, enregistrements, etc.) qui doivent être conservés pour chaque entité
suivi par le système d'information
4. Les règles d'intégrité qui régissent la manière dont chaque élément de données est spécifié et utilisé dans le système d'information.
Conception de processus
L'activité de conception de processus se concentre sur la conception des ressources logicielles, c'est-à-dire des ordinateurs.

programmes et procédures nécessaires au système d'information proposé. Il se concentre sur

développer des spécifications détaillées pour les modules du programme qui devront être achetés comme
des logiciels ou développés par programmation sur mesure. La conception de processus produit :
1. Spécifications détaillées du programme et procédures nécessaires pour répondre à l'interface utilisateur et aux données
spécifications de conception qui sont développées.
2. Produit des spécifications qui répondent aux exigences de contrôle fonctionnel et de performance
développé dans la phase d'analyse.
Spécifications du système
La spécification du système se concentre sur la définition des spécifications du système requises pour le proposé.
système d'information. Typiquement, il spécifie :
1. Ressources matérielles (machines et supports)
2. Ressources logicielles (programmes et procédures)
3. Ressources réseau (médias de communication et réseaux)
3. Ressources humaines (utilisateurs finaux et personnel des systèmes d'information).

4. Comment les ressources seront utilisées pour convertir les ressources de données (stockées dans des fichiers et des bases de données)

design) en produits d'information (affichages, réponses, rapports et documents).

Développement de système - Mise en œuvre d'un nouveau système d'information :
Une fois qu'un système d'information proposé a été conçu, il doit être mis en œuvre. Les systèmes
la phase de mise en œuvre implique :
1. Acquisition de matériel et de logiciels
2. Développement logiciel
3. Test des programmes et procédures
4. Développement de la documentation
5. Activités d'installation
6. Formation et éducation des utilisateurs finaux et des spécialistes qui utiliseront le nouveau système.
7. Passer de l'utilisation du système actuel à l'exploitation d'un nouveau ou d'un système amélioré
système.
La conversion à un nouveau système peut impliquer :
Système parallèle - Faire fonctionner à la fois un nouveau système et un ancien système en même temps pour un
période d'essai.
Système pilote - Faire fonctionner un système pilote à titre d'essai à un endroit.

23
 Phase - Phasage dans le nouveau système une application ou un emplacement à la fois.
Plongée (Changement) - Conversion immédiate au nouveau système.

Maintenance des systèmes d'information

La maintenance des systèmes est la dernière étape du cycle de développement des systèmes. Elle implique la
suivi, évaluation et modification d'un système pour apporter des améliorations souhaitables ou nécessaires.
Cela peut inclure :
1 Processus de révision post-implémentation pour garantir que le nouveau système répond aux objectifs
établi pour cela.
2. Les erreurs détectées dans le développement ou l'utilisation du système sont corrigées.
3. Des modifications ultérieures d'un système peuvent également devenir nécessaires en raison de changements au sein de
le monde des affaires ou l'environnement des affaires.

SUJET 4 : DÉFINITION DU PROBLÈME

THÉORIE

[Link].T0 Objectifs spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) identifier les indicateurs de problème

b) décrire le contenu d'un TOR

CONTENU

Indicateurs de problème

Contenu d'un Cahier des charges (TOR)

Un ToR est un document formel, mais il n'est généralement pas très long. Il peut être utilisé pour décrire un projet
avant qu'une charte de projet complète (ou document d'initiation de projet) ne soit produite. Il est plus couramment utilisé
définir les termes de référence pour un flux de travail ou un sous-projet particulier, et est rédigé par le
responsable de projet avec l'apport du responsable fonctionnel qui gère cette section du travail.
Vous pourriez également en produire un pour une phase du projet, par exemple, la phase de cadrage initial.
bref, un Cahier des Charges peut couvrir de nombreuses choses mais définit généralement l'étendue de ce qui doit être fait sur un
particulier pièce de travail.
Le document de TdR comprend :

24
Contexte

Le contexte de l'œuvre, les objectifs globaux de l'œuvre et toutes les références à d'autres œuvres.
que l'équipe devrait prendre en compte lors du commencement du travail.

Objectifs

Que va accomplir cette pièce de travail ? Quel problème va-t-elle résoudre ? Cela devrait être
présenté d'une manière que tout le monde peut comprendre, en évitant le jargon.

Portée

Cette section couvre brièvement ce qui est inclus et ce qui est exclu du travail. Il est plus facile de l'énumérer dans
format en points, si plus de détails sont nécessaires, cela peut être produit dans une demande complète
document. Les points clés dans cette section devraient couvrir des domaines tels que :

Les systèmes techniques impliqués ou qui sont requis

Les processus commerciaux qui seront affectés par ce travail
Quel matériel et logiciel est requis (ou spécifiquement hors du champ d'application)
Où le projet aura-t-il lieu, quelles sont les localités touchées et quelles seront les localités ?
hors du champ d'application pour les besoins de ce travail

Quels tiers seront impliqués

Qui sera affecté, et quelles équipes ou individus seront spécifiquement hors de portée.

Vous penserez probablement à d'autres choses à inclure dans le champ d'application. Un bon conseil est d'impliquer l'équipe.
ensemble (si vous n'avez pas une équipe complète à ce stade, rassemblez quelques collègues).

Contraintes

Cette courte section documente les contraintes de projet, telles que les délais, le budget disponible, le
ressources disponibles ou tout cadre législatif ou réglementaire qui doit être pris en compte.

Hypothèses

Incluez toutes les hypothèses dans le Cahier des Charges. Ce sont des choses que vous ne savez pas encore avec certitude mais qui...

aura un impact sur le travail plus tard. Si vous mettez à jour votre TdR plus tard, vous pouvez
Mettez à jour cette section car vous avez peut-être pu ratifier vos hypothèses d'ici là.

Rôles et responsabilités

Qui est dans l'équipe ? Dans cette section, documentez les noms et les rôles des personnes qui seront
la réalisation du travail. Vous pouvez également inclure leur disponibilité, par exemple s'ils ne sont disponibles que pour
travailler sur le projet deux jours par semaine. Inclure également des détails sur qui parraine le travail. Si c'est un

25
projet complet, cela sera le sponsor du projet. Si c'est un flux de travail ou une partie d'un projet existant, le
la personne à qui le responsable du flux de travail rend compte (probablement vous, le chef de projet) est le bon
personne à mentionner ici.

Livrables

Quel est le travail qui va être livré ? Faites une liste - cela n'a pas besoin d'être trop détaillé à ce stade car
tout ce dont vous avez vraiment besoin est une description générale des résultats du travail. Vous pourriez inclure un
une capture d'écran des jalons de haut niveau de votre plan de projet ici aussi.

Format

Idéalement, vous devriez viser à obtenir votre TdR sur quelques pages. Il n'est pas nécessaire d'avoir une couverture élégante.
page ou annexes. Mettez un en-tête et un pied de page sur le document et commencez ! Vous pouvez toujours
inclure des informations de contrôle de version dans un tableau court au début ou à la fin.

D'autres utilisations pour un ToR

Vous pouvez également établir un cahier des charges pour les réunions, afin que votre comité de projet ou votre groupe de pilotage puisse avoir un

Devis qui explique ce qu'ils sont là pour faire et comment ils vont procéder aux affaires.
gouvernance ou supervision du projet. Vous pourriez également en avoir un pour d'autres types de réunions, tels que
en tant que termes de référence pour les réunions de gestion des risques. Tant que les TdR définissent clairement les
La portée d'une activité et explique ce qui est également hors de portée, alors elle fera son travail.

26
SUJET 5 : ÉTUDE DE FAISABILITÉ

THÉORIE

CONTENU

Introduction

Le processus d'analyse de la faisabilité ou non de la proposition s'appelle l'analyse de faisabilité.

n'est pas faisable, nous devons chercher d'autres alternatives. L'étude de faisabilité se concentre principalement sur le
la demande du système qui affecte le développement global du système d'information.

C'est une évaluation de la praticité d'un plan ou d'une méthode proposée. Cela aide à trouver le
strengths and weaknesses of an existing business or proposed venture, opportunities and threats
présent dans l'environnement, les ressources nécessaires pour mener à bien, et en fin de compte les perspectives
pour le succès.

L'étude de faisabilité est utilisée pour :

1. Pour déterminer si les objectifs énoncés dans le cahier des charges sont raisonnables
atteignable dans la période des limitations et des contraintes financières.
2. Définir les principaux domaines de problème, afin que l'analyste système puisse planifier la stratégie pour le
enquête de terrain.
3. Trouver des domaines où il existe un potentiel d'économies d'argent, de temps ou d'efforts.
4. Déterminer le temps approximatif nécessaire pour l'enquête complète et le coût.
5. Découvrir les domaines où des connaissances spécialisées sont nécessaires pour l'enquête complète.

Il existe différents types d'études de faisabilité... qui comprennent :

Faisabilité technique
Faisabilité économique
Faisabilité opérationnelle
Faisabilité du calendrier

Faisabilité technique
C'est une mesure de la disponibilité des ressources techniques (composants matériels ou techniques)
équipement). Il étudie également la disponibilité de la main-d'œuvre technique pour le projet. [ si le travail
les performances du personnel technique ne sont pas expérimentées, l'ensemble du système sera certainement
insuffisant.

Faisabilité économique
La faisabilité économique mesure si des finances (investissements) sont disponibles pour les propositions.
solution, c'est-à-dire qu'elle examine les aspects financiers (coût/effectivité) du projet. Cela est souvent
appelée une analyse coût-bénéfice.

27
 Faisabilité opérationnelle
C'est une mesure de l'efficacité de la solution aux problèmes ou d'une solution alternative spécifique.
l'organisation. C'est également une mesure de ce que les gens pensent du système. Si le système n'est pas facile
Pour fonctionner, le processus opérationnel serait difficile. L'opérateur du système devrait être
une formation appropriée. Le système devrait être conçu de manière à ce que l'utilisateur puisse interagir avec le système
sans aucun problème.

Faisabilité du calendrier
Si une date limite (un délai) est établie, elle est appelée faisabilité du calendrier, c'est-à-dire la date limite du
Le projet est étudié dans le cadre de la faisabilité prévue. La faisabilité prévue dépend également de
main-d'œuvre disponible et condition économique également.

Legal/Ethical Feasibility- What are the legal implications of the project? What sort of ethical
Quelles considérations sont là ? Vous devez vous assurer que tout projet entrepris respectera toutes les obligations légales.
et des exigences éthiques avant que le projet ne soit sur la table.
Faisabilité des ressources - Avez-vous suffisamment de ressources, quelles ressources seront nécessaires, quoi
des installations seront nécessaires pour le projet, etc.

Méthodes de collecte d'informations

Cela implique la collecte d'informations sur le système existant sur lequel fonder une analyse dans
afin de déterminer si les besoins actuels des utilisateurs sont satisfaits.

Les activités suivantes sont impliquées

1. Exigence fonctionnelle. L'exigence doit être établie.

2.Détermination des exigences du système proposé. Cela est nécessaire, cela peut suggérer un changement
dans les exigences du système existant.
3. Établir toutes les faiblesses ou problèmes associés aux méthodes de travail du système actuel et
procédures
4. La détermination du taux de croissance organisationnelle aidera à déterminer la croissance de la
volume des transactions à traiter.
5. Détermination de l'objectif de la structure des organisations et du coût associé à la situation actuelle
système
La recherche de faits comprend les éléments suivants :

Collecte de faits
Enregistrement des faits
Évaluation des faits

Outils/techniques/méthodes de collecte de données

Les méthodes largement utilisées pour la collecte de données incluent les suivantes :

28
 a) Questionnaires
b) Entretiens
c) Observations
d) Inspection des dossiers / examens des documents
e) Échantillonnage

A. Questionnaires
Le questionnaire est un document spécial qui permet à l'analyste de poser un certain nombre de questions standard prêtes.
questions destinées à être posées à un grand nombre de personnes afin de recueillir des informations à leur sujet.

Pertinence :
Il est approprié de l'utiliser quand :

. L'analyste système se trouve à une distance considérable des répondants.

. Il y a un grand nombre de répondants, de sorte que les interviews seront limitées par le temps.
. Les questions à poser sont simples et directes et nécessitent des réponses directes.
. Des informations limitées sont requises de la part d'un grand nombre de personnes.
. Utilisé comme un moyen de vérifier les faits trouvés à l'aide d'autres méthodes

Avantages de l'utilisation de questionnaires

Je. Ils fournissent un moyen bon marché de recueillir des informations auprès d'un grand nombre de personnes.
II. Ils encouragent les individus à fournir des réponses sans crainte, intimidation ou victimisation.
III. Les répondants peuvent compléter les questionnaires à leur propre convenance avec un minimum
interruption de leur travail
IV. Les questionnaires sont présentés de manière cohérente à tous les participants sans biais.

Inconvénients

Je. La réponse est souvent trop lente car les répondants remplissent et renvoient les formulaires à leur propre rythme.
commodité
II. Ils ne fournissent pas aux répondants l'opportunité d'obtenir des clarifications sur des questions qui pourraient
sembler vague ou ambigu
III. La conception de questionnaires nécessite un expert qui peut facturer cher et qui peut ne pas être
économique lorsqu'il est administré à un petit groupe de répondants
IV. Tous les formulaires ne peuvent pas être retournés et toutes les questions ne peuvent pas être répondues, ce qui conduit à des informations incomplètes.

données pour analyse

Exigences pour préparer un questionnaire

Les questions doivent être simples et claires

Les formulaires doivent être soignés
Les questions devraient être logiquement organisées
Les questions doivent être orientées objectivement et doivent éviter les questions suggestives.
B. Interviews

29
 Ceci est une conversation en face à face entre l'analyste (l'intervieweur) et les utilisateurs.
interviewé). Les analystes obtiendront des réponses aux questions qu'il pose à l'interviewé. Le
L'interviewé formulera des suggestions et des recommandations qui pourraient aider lors de la conception du
système proposé.

But de l'entretien

i. Ils agissent comme une méthode de recherche de faits pour recueillir des informations ou des réponses sur le système existant.
ii. Utilisé pour vérifier des faits recueillis par d'autres méthodes
iii. Utilisé pour impliquer l'utilisateur dans le développement du nouveau système

Les entretiens sont utilisés dans les circonstances suivantes

i. Quand les répondants sont peu nombreux

ii. Lorsque les répondants sont physiquement disponibles et accessibles

iii. Lorsque une réponse immédiate est requise
iv. Lorsque l'analyste souhaite vérifier la validité des faits recueillis par d'autres méthodes
v. Lorsque l'analyste souhaite obtenir des réponses directes, des avis, des suggestions et d'autres détails
informations concernant le système à développer.

Avantages des entretiens

je. Le taux de réponse a tendance à être élevé et immédiat

ii. Des faits détaillés peuvent être obtenus auprès de chaque répondant.
iii. Ils sont un moyen plus puissant d'obtenir des informations car il y a un contact direct avec le
répondant (le langage corporel peut facilement être vu)
iv. L'analyste peut poser des questions directement à chaque individu en fonction de leur niveau de compréhension.
permettant d'obtenir des faits.

Inconvénients

i. Ils sont coûteux et prennent du temps lorsque de grands groupes sont impliqués
ii. Le succès dépend fortement de la compétence des analystes, de leurs compétences en relations humaines et de leur expérience.

iii. Les répondants peuvent avoir l'impression d'être interrogés.

C. Observations

C'est la technique de recherche de faits la plus efficace, mais elle nécessite que l'analyste participe à
effectuer certaines activités réalisées par l'utilisateur. L'analyste peut choisir d'observer les utilisateurs pendant qu'ils
effectuer leurs activités et rassembler les faits envisagés

Circonstances nécessitant une observation

Lorsque la validité des faits recueillis par d'autres méthodes est douteuse
Lorsque la complexité de certains aspects d'un système empêche une explication claire de la part des répondants ou
l'utilisateur

30
 Utilisé pour confirmer que les procédures spécifiées dans les manuels sont suivies dans le cas d'une
système existant
Lorsqu'il est nécessaire d'obtenir des informations de première main et fiables

Avantages

Les données recueillies sont très fiables, donc la méthode peut être utilisée pour vérifier les faits collectés via
autres méthodes
Il y a une opportunité pour l'analyste de voir ce qui se passe exactement, y compris les tâches qui sont
difficile à expliquer clairement en mots.
Des tâches décrites avec précision peuvent facilement être identifiées
Relativement bon marché par rapport à d'autres méthodes

Inconvénients

Les gens se sentent toujours mal à l'aise lorsqu'ils sont observés et peuvent donc se comporter anormalement.
influencer la conclusion de l'analyste.
L'exercice peut se dérouler à des horaires inhabituels, ce qui peut déranger les personnes impliquées.
L'analyste peut observer des activités exceptionnelles laissant certaines zones critiques.

Groupe de discussion de classe

Recherche sur les méthodes de collecte de données suivantes

1. Révision de documents/Inspection des dossiers et

2. Méthode d'échantillonnage et énoncer leurs avantages et inconvénients

31
 SUIVI 6 : ANALYSE DES SYSTÈMES

Sous-thème : Signification et importance de l'analyse des systèmes

L'analyse des systèmes est une étude approfondie des besoins en information des utilisateurs finaux qui produit des fonctionnalités.

exigences qui sont utilisées comme base pour la conception d'un nouveau système d'information.

Sous-sujet : Importance de l'analyse des systèmes

L'importance de l'analyse système implique traditionnellement une étude détaillée et la détermination de

détails suivants :

1. La détermination des besoins d'information de l'organisation et des utilisateurs finaux.

2. L'analyste sera capable d'identifier les activités, les ressources et les produits de tout présent / actuel
systèmes d'information

3. L'analyse révélera les capacités des systèmes d'information nécessaires pour répondre aux besoins d'information.
besoins des utilisateurs finaux.

Sous-thème : Approches/méthodes d'analyse des systèmes

Modèle-dirigé : il existe principalement quatre approches utilisées dans le modèle dirigé, à savoir :

Design structuré moderne

Une technique de conception de système qui décompose les processus du système en composants gérables.

•Les synonymes (bien que techniquement inexactes) sont la conception de programmes de haut en bas et structurée
programmation.
Concevoir dans une hiérarchie de modules de haut en bas

•Plus facile à mettre en œuvre et à maintenir (changer).

Les modules doivent être hautement cohésifs

•Accomplir une seule fonction

Les modules doivent être faiblement couplés
Minimement dépendants les uns des autres

Ingénierie de l'information (IE)

Une technique axée sur les modèles et centrée sur les données, mais sensible aux processus pour la planification, l'analyse et
conception de systèmes d'information. Les modèles IE sont des images qui illustrent et synchronisent le système.
données et processus.

32
L'outil principal de l'IE est un diagramme de modèle de données, c'est-à-dire un DIAGRAMME ER.

Prototypage

Un échantillon de système souhaité, à petite échelle, incomplet mais fonctionnel est développé.

Impliquant un processus itératif faisant intervenir une relation de travail étroite entre le designer et le
utilisateurs.

Principaux avantages :

Encourage et exige la participation active des utilisateurs finaux.

L'itération prend en compte les utilisateurs finaux qui ont tendance à changer d'avis.

Approuve la philosophie selon laquelle les utilisateurs finaux ne sauront pas ce qu'ils veulent jusqu'à ce qu'ils le voient.

•Modèle actif avec lequel les utilisateurs finaux peuvent interagir.

Les erreurs peuvent être détectées plus tôt.

Peut augmenter la créativité car elle permet d'obtenir des retours d'utilisateur plus rapidement.

Accélère plusieurs phases du cycle de vie.

Inconvénients et pièges :
• Encourage un cycle de vie "coder, mettre en œuvre et réparer" qui entraîne des cauchemars de maintenance.

•Il faut encore des phases d'analyse des systèmes, mais il est si facile de les sauter.

•Ne peut pas complètement remplacer un prototype par une spécification papier (comme un architecte sans un)
plan.
De nombreux problèmes de conception ne sont pas abordés par le prototypage.

Souvent conduit à un engagement prématuré dans un design.

33
• La portée et la complexité du système peuvent devenir incontrôlables.

Peut réduire la créativité dans les designs.

Souvent souffrent d'une performance plus lente en raison de considérations linguistiques (devenant rapidement un)
non-problème).

Analyse orientée objet

L'analyse orientée objet utilise principalement des cas d'utilisation et des diagrammes CASE. Les cas d'utilisation sont différents.

manière de modéliser la fonctionnalité commerciale d'un processus commercial qui facilite le développement de
systèmes d'information pour soutenir ce processus. Bien que commun dans les systèmes orientés objet
l'analyse et la conception, la modélisation des cas d'utilisation peuvent également être utilisées avec des méthodes plus traditionnelles pour

processus commercial

Cas d'utilisation : Un cas d'utilisation montre le comportement ou la fonctionnalité d'un système. Il consiste en un ensemble de
séquences possibles d'interactions entre un système et un utilisateur dans un environnement particulier,
des séquences possibles qui sont liées à un objectif particulier. Un cas d'utilisation décrit le comportement d'un
système sous diverses conditions alors que le système répond aux demandes des principaux acteurs

Un acteur principal initie une demande au système, liée à un objectif, et le système répond.
le cas d'utilisation peut être formulé comme une phrase verbale au présent (ce que le système est censé faire) et le
objet du verbe ( ce sur quoi le système doit agir ). Par exemple, les noms de cas d'utilisation incluraient
Saisir les données de ventes, calculer les commissions, générer des rapports trimestriels

Un modèle de cas d'utilisation se compose d'acteurs et de cas d'utilisation. Un acteur est une entité externe qui interagit.
avec le système. C'est quelqu'un ou quelque chose qui échange des informations avec le système.

Inscrivez-vous pour

Classes

Étudiant Inscription
Clerc
Identifier les prérequis
S'inscrire pour
Cours Non Terminés
Classe spéciale

Étudiant Bill

Instructeur
Bureau du trésorier

34
 L'analyse et la conception orientées objet (OOAD) est une approche de développement dont le souci est de
modéliser les objets du monde réel dans un logiciel. Un objet est une chose dont les caractéristiques peuvent être
décrits. Dans le paradigme orienté objet, toutes les choses vivantes et non vivantes sont considérées
objets. Et en tant que tel, lorsqu'un programmeur développe un logiciel pour une organisation, il/elle doit
considérez tous les objets d'intérêt pour l'organisation et capturez-les dans le logiciel. Certains des
Les objets peuvent avoir une existence tangible réelle, tels que les véhicules des employés, les chaises, les tables, etc. L'objectif
de l'OOAD est de rendre les éléments des systèmes plus réutilisables, améliorant ainsi la qualité du système et le
productivité de l'analyse et de la conception des systèmes.

Cependant, certains des objets peuvent avoir une existence abstraite et donc ne pas être visibles ou tangibles.
mais le programmeur doit les inclure dans le logiciel car ils sont d'un intérêt pour l'organisation.
Le support orienté objet repose sur le concept de base d'un véritable langage de programmation orientée objet, à savoir :

L'héritage : c'est la capacité d'acquérir les caractéristiques, traits ou fonctionnalités d'un déjà
objets existants d'une classe donnée. La classe dont les fonctionnalités sont héritées par une autre est
dit être une super classe ou classe de base, ou classe parente. La classe qui acquiert la fonctionnalité de
une autre classe est connue sous le nom de sous-classe ou de classe dérivée, ou classe enfant. Grâce au processus de
L'héritage, la structure d'arbre hiérarchique peut s'étendre avec différents niveaux de hiérarchie pour donner un
impression d'enfant, parent, grand-parent, etc.
L'encapsulation : c'est l'enveloppement des données et des fonctions en une seule unité de classe.
n'est pas accessible au monde extérieur, seules les fonctions encapsulées dans la classe peuvent y accéder. Le
L'isolation des données par rapport aux opérations est connue sous le nom de masquage d'informations.

Le polymorphisme : c'est la capacité d'un objet à changer ou à prendre une forme différente selon le
circonstances prévalantes
Abstraction : c'est le fait de cacher les détails internes complexes de l'implémentation d'une entité par
fournissant une interface par laquelle ils peuvent être manipulés ou interagis. Les programmeurs
mettre en œuvre l'abstraction par la création d'objets dont les propriétés sont dissimulées de
mais une interface est fournie via les fonctions associées à cet objet.
Structuré

Sous-sujet : Application des outils d'analyse de systèmes

Diagrammes de flux
DIAGRAMMES DE FLUX.

Un organigramme est une représentation diagrammatique ou picturale de l'algorithme d'un programme.

C'est un graphique qui démontre la séquence logique des événements qui doivent être effectués pour résoudre un
problème.

Types de diagrammes de flux.

Il existe 2 types courants de diagrammes de flux :

35
1). Organigramme du système.

Un organigramme système est un modèle graphique qui illustre chaque étape de base d'un traitement de données.
système.

Cela illustre (en résumé) la séquence des événements dans un système, montrant le département ou
fonction responsable de chaque événement.

2). Organigramme du programme.

Ceci est un diagramme qui décrit, en séquence, toutes les opérations nécessaires pour traiter des données dans un
programme informatique.

Un organigramme de programme représente graphiquement les types d'instructions contenues dans un ordinateur.
programme ainsi que leur séquence et logique.

DIAGRAMMES DE FLUX DE PROGRAMME.

Un organigramme est construit à l'aide d'un ensemble de formes (ou symboles) spéciaux qui ont une signification spécifique.
Les symboles sont utilisés pour représenter des opérations ou le flux de données sur un organigramme.

Chaque symbole contient des informations (texte court) qui décrivent ce qui doit être fait à ce point.

Les symboles sont reliés par des flèches pour obtenir un organigramme complet. Les flèches montrent l'ordre dans
la quelle l'instruction doit être exécutée.

SYMBOLS UTILISÉS DANS LES ORGANIGRAMMES DE PROGRAMME.

Voici un ensemble standard de symboles utilisés pour dessiner des diagrammes de flux de programmes tels que créés par les Américains.

Institut National des Normes (ANSI).

1. Symbole terminal.

Ellipsse (en forme d'oval)

Il est utilisé pour indiquer le point où un organigramme, un processus ou un algorithme commence et se termine.

Tous les organigrammes doivent avoir un symbole DE DÉBUT et DE FIN. Le symbole DE DÉBUT/DE DÉPART est le

premier symbole d'un organigramme, & identifie le point auquel l'analyse de l'organigramme
devrait commencer. Le symbole ARRÊT/FIN est le dernier symbole d'un diagramme de flux et indique le
fin du diagramme de flux.

36
 Les mots Début & Fin (ou Démarrer & Arrêter) doivent être insérés dans le symbole Terminal.

2. Symbole d'entrée ou de sortie.

Parallélogramme

Il est utilisé pour identifier/spécifier une opération d'entrée ou une opération de sortie.

Par exemple ;

LIRE le nom de l'employé IMPRIMER le nom de l'employé

Opération d'entrée Opération de sortie

Remarque. Les mots principalement associés aux opérations d'entrée/sortie sont LIRE et IMPRIMER. LIRE
décrit l'entrée de données informatiques, tandis que PRINT se rapporte à la sortie imprimée de
informations.

3. Symbole de processus.

(Rectangle)

Le symbole de processus est utilisé pour indiquer qu'un traitement ou une transformation de données est en cours.

Les informations placées dans le symbole de processus peuvent être une formule algébrique ou une phrase.
décrire le traitement.

SOMME = A + B La commission est calculée à 20 % des ventes totales

Le traitement défini comme une formule Le traitement défini comme une phrase

4. Symbole de décision.

NON Losange

OUI

Il est utilisé pour indiquer/ spécifier une condition ou pour montrer la décision à prendre.
Il y a 2 composants principaux d'un symbole de décision :

(i). Une question posée dans le symbole de décision, qui indique la comparaison / logique
opération.
37
 (ii). Les résultats de la comparaison (qui sont exprimés en termes de OUI ou NON).
Les flèches étiquetées OUI ou NON mènent à l'action requise correspondant à la réponse à la
question.

5. Lignes de flux.

Les lignes de flux avec des flèches sont utilisées pour indiquer la direction du traitement du programme.
logique, c'est-à-dire qu'ils montrent l'ordre dans lequel les instructions doivent être exécutées.

Le flux normal d'un organigramme va de haut en bas et de gauche à droite.

Note. Les lignes de flux ne doivent jamais se croiser.

6. Symbole de connecteur.

Parfois, un organigramme devient trop long pour tenir sur une seule page, de sorte que les lignes de flux commencent
se croiser à plusieurs endroits causant de la confusion et rendant également le diagramme de flux difficile à
comprendre.

Le symbole TheConnector est utilisé comme un point de connexion pour les flèches provenant de différents
directions.

Un symbole de connecteur est représenté par un cercle, et une lettre ou un chiffre est placé à l'intérieur du cercle.
pour indiquer le lien.

Remarque. Les connecteurs ne représentent aucune opération. Ils sont utilisés pour relier deux parties d'un
organigramme, indiquant que le flux de données n'est pas interrompu.

Directives générales pour dessiner un organigramme de programme.

[Link] organigramme ne doit avoir qu'un seul point d'entrée/départ et un seul point de sortie.
le diagramme de flux a un début et une fin logique).
Le diagramme de flux doit être clair, soigné et facile à suivre.
[Link] le symbole correct à chaque étape du diagramme de flux.
4. Le organigramme ne doit pas être sujet à plus d'une interprétation.
5. Évitez de chevaucher les lignes utilisées pour montrer le flux de logique, car cela peut créer de la confusion dans le
organigramme.
6. Rendez les instructions de comparaison simples, c'est-à-dire capables de réponses OUI/NON.

38
7. Le flux logique doit être clairement montré à l'aide de flèches.
Remarque. Un organigramme doit s'écouler de haut en bas d'une page, et de gauche à droite.
D'accord.
8. Lorsqu'il est nécessaire, utilisez des connecteurs pour réduire le nombre de lignes de flux.

Les connecteurs sont utiles lorsque un organigramme s'étend sur plusieurs pages et où plusieurs boucles sont présentes.
nécessaire dans la logique du diagramme de flux.

9. Vérifiez que le diagramme de flux est logiquement correct et complet.

Exemple 1 :
Dessinez un organigramme pour un programme qui peut être utilisé pour demander à l'utilisateur d'entrer deux nombres, trouver

la somme et la moyenne des deux nombres puis afficher le résultat à l'écran.

Exemple 2 : Commencer

X, Y

Somme = X + Y

Average = Sum/2

IMPRIMER Somme, Moyenne

Arrêter

Concevez un organigramme pour un programme qui peut être utilisé pour classer les personnes selon l'âge. Si un
Adulte

Commencer

Âge

Âge > 20 ? Jeune personne

Non
Adulte

Oui
Arrête

39
Modules
Les symboles de cartographie des processus peuvent être appliqués aux processus manuels - comment une personne accomplit une tâche - ou à

une fonction informatisée - comme un précurseur à l'écriture du programme. L'analyste doit souvent ajouter
informations pour rendre un processus compréhensible pour les humains ou pour les machines. Par exemple, l'idée de
Rassembler des données ou des matériaux avant de commencer un processus peut ne pas être évident au premier abord. Dans cet exemple,
Une personne est en train de calculer la moyenne des scores des étudiants à un quiz. Imaginez-vous en train de faire cette tâche.
cette première itération, les principales fonctions sont identifiées :
1. Écrivez le score de chaque quiz de l'étudiant
2. Ajouter le score au total courant
3. Comptez le nombre de devoirs
4. Divisez le total cumulé par le nombre de devoirs

40
 Jusqu'à présent, tout va bien. Mais un ordinateur doit être informé de bien plus de choses :
Commencez le processus de calcul de la moyenne des notes des étudiants

2. Les quiz sont-ils disponibles ?

a. Sinon, obtenez-les
b. Si c'est le cas, traiter

3. Score en cours = 0
4. Nombre de quiz traités = 0;
5. tant qu'il y a des quiz à traiter
a. obtenir le score de ce quiz
b. ajouter le score au score courant
c. ajouter 1 au nombre de quiz traités
6. Divisez le score en cours par le nombre de quiz traités
7. Enregistrez la réponse
8. Terminer le processus

Puisque les organigrammes sont une représentation graphique des étapes, la séquence est indiquée par des flèches.
Notez cependant que s'il y a de nombreux connecteurs hors page, le diagramme de flux est probablement trop grand. Dans ce
cas, reconsidérer la modularisation : pouvez-vous identifier les processus redondants ou les processus dont
le niveau de granularité est incohérent avec les autres sur le graphique ? Dans cette situation, vous pourriez préférer un
technique de graphiques différente.

DIAGRAMMES DE FLUX DE DONNÉES (DFD)

Les diagrammes de flux de données sont utilisés pour représenter le système en cours d'analyse. Les diagrammes/symboles utilisés
pour les éléments de base sont :

Processus

C'est toute activité qui modifie des données de quelque manière que ce soit.

Entité externe (source/puits)

41
Cela est utilisé pour représenter des entités externes ou des choses qui existent en dehors du système et qui envoient
ou recevoir des messages du système. Cela peut être des utilisateurs ou d'autres systèmes et ils représentent le
source et destination (puits) du flux d'informations qui est modélisé.
Magasin de données.

Cela correspond au fichier maître des données qu'elles soient manuelles, informatisées ou une base de données ou
toute unité de données stockées.

Flux de données

Montre le mouvement des données entre les composants d'autres systèmes.

Pour construire un DFD, nous utilisons l'approche descendante qui commence par la fonction la plus élevée.
et les principaux flux de données entrants et sortants.

Un diagramme avec un petit nombre de processus est construit (diagramme de contexte) pour représenter le sommet
niveau. Il est ensuite élargi pour produire un diagramme plus détaillé (niveau 0). La dernière étape est atteinte
lorsque chaque processus correspond à une seule tâche ou module qui peut clairement être simple et
défini.

ÉTAPES POUR DESSINER DES DFD

Remarque : nous en sommes encore à l'étape d'analyse du développement des systèmes. Et donc nous sommes concernés par
ce que nous exigeons du système, comment cela sera réalisé est laissé à la phase de conception.

Étape 1 :

Commencez par identifier toutes les entités sources et de destination du système à modéliser. Ceci est
probablement un sous-système du système total qui aura été partitionné en gestion
pièces.

Les noms et les groupes nominaux dans la description du scénario donné fourniront un guide pour identifier le
Entités et magasins de données.

Étape 2 :
Dessinez le diagramme de contexte approprié ou le diagramme de niveau 0.

Étape 3 :

42
Affinez le diagramme contextuel en identifiant tous les processus au sein des processus principaux du système.
Les VERBes (mots d'action) dans la description du scénario aideront à identifier ces processus.

Étape 4 :

Commencez par la source et décidez quel processus doit recevoir cette entrée, puis décidez où la sortie de
ce processus est à faire.

Répétez tous ces exercices pour toutes les entrées et les processus de sortie. Cela produira des données complètes.
chaîne de flux dans un DFD de niveau 1.

Étape 5 :
À partir de l'étape 4, prenez chaque processus à tour de rôle et répétez l'étape 4 pour chacun, en traçant un DFD séparé pour
chaque processus. Ce sont les DFD de niveau 2.

REMARQUE : NE JAMAIS CONNECTER UNE SOURCE DIRECTEMENT À UNE DESTINATION. CELA DOIT
TRAVERSER TOUJOURS UN PROCESSUS!!!!!!!

Dictionnaire de données

Un dictionnaire de données décrit les éléments de données présents dans les diagrammes de flux de données et les relations d'entité.
diagrammes. Il fournit un point de départ pour le développement des mises en page d'écran, des rapports imprimés et
logique de programmation. Il offre une opportunité de détecter les erreurs de conception. Il est maintenu et
étendu tout au long du processus d'analyse et de conception des systèmes.
Exemple de dictionnaire de données

formulaire d'inscription complet

+ nomDeL'étudiant
+ dateDeNaissanceDeL'Étudiant

+ codeDuCours
+ dateDeFinDeCours

entier(6)
Les deux premiers chiffres représentent l'année d'inscription, par exemple 07 pour 2007. Les quatre chiffres restants
identifier de manière unique l'étudiant

studentNam prénomÉtudiant
NomDeFamilleÉtudiant

char(15)
jusqu'à 15 caractères sont autorisés

nom de famille= caractère(15)

ou nom de famille. Jusqu'à 15 caractères sont autorisés

43
format court de date e.g. 16Mai1989
l'année doit être avant 1989 c'est-à-dire qu'ils doivent avoir au moins 16 ans le
1er septembre quand ils s'inscrivent

char(5)
jusqu'à cinq caractères par exemple A0371 = Cours d'accès à l'informatique
Chaque code de cours est associé à un titre de cours.

format de date courte, par exemple 30Juin2008

la date à laquelle la personne cesse d'être un étudiant

formulaireDinscription
lecturerName
+ dateConférencierSigné

initiales
nom de famille

initiales = char(3)
jusqu'à trois caractères autorisés

FichierDeCours { enregistrementDeCours }
CourseFile contient zéro, un ou plusieurs courseRecords

intituléDeCours
codeDeCours

caractère(25)
jusqu'à 25 caractères [Link]. BTEC Nat Dip Comp Studies

Histoire de la vie d'entité

Une raison majeure de la construction de systèmes d'information informatisés est de fournir des informations à jour et
informations précises. L'information évolue ou change constamment, par exemple le nombre de
lits disponibles dans un hôpital, le prix de l'essence, ainsi que les noms et adresses des gens. Un
le système d'information doit être capable de suivre ces changements. Les notes précédentes ont décrit
comment le système est modélisé du point de vue des flux d'informations (DFDs) et de
point de vue de l'information (c'est-à-dire des entités) qui est détenue (modélisation ER).

Les Histoires de Vie des Entités (HVE) modèlent le système du point de vue de la façon dont le
Les entités/informations dans un système évoluent au fil du temps. Ce que montrent les ELH, c'est l'ensemble complet des changements.

44
 qui peut éventuellement se produire aux entités/informations au sein du système, ainsi qu'au contexte de
chaque changement.

Au départ, chaque entité au sein d'un système est examinée isolément car c'est une unité gérable de
informations à modéliser. Ce sont les stimuli des changements qui sont modélisés plutôt que l'entité, un
une image composite est formée, spécifiant finalement l'ensemble des changements qui se produiront à l'intérieur
le système.

Un ELH est une représentation diagrammatique de la vie d'une seule entité, de sa création à son
suppression. La vie s'exprime comme la séquence d'événements autorisés qui peuvent provoquer l'entité à
changement. Un événement peut être considéré comme tout ce qui déclenche un processus pour changer des entités, donc
bien que ce soit un processus qui change l'entité, c'est l'événement qui est la cause du changement.

Création des Histoires de Vie des Entités

Les pré-requis nécessaires au développement des histoires de vie sont la connaissance de

les trois composants ELH suivants :

Les entités du système et leurs attributs.

Les événements qui affectent une ou plusieurs des entités du système pendant leur durée de vie dans le système.

Une notation de base pour décrire graphiquement la séquence chronologique dans laquelle les événements et
des sous-structures d'événements peuvent se produire.

Structure des Histoires de Vie des Entités

La forme générale d'un ELH suit certaines conventions et a l'apparence montrée dans le
figure ci-dessous.

ENTITÉ
NOM

NAISSANCE MILIEU LA MORT

ÉVÉNEMENT ÉVÉNEMENTS DE VIE ÉVÉNEMENTS

ITÉRATION *
D'ÉVÉNEMENTS

Figure Un Structure d'un diagramme ELH

45
 La structure générale d'un ELH comme indiqué dans la figure un montre qu'il existe trois fondamentaux.
types d'événements

Événements de naissance

Événements de décès

Événements de la vie moyenne (ou mise à jour)

Les effets correspondants de ceux-ci sont qu'ils provoquent une occurrence de l'entité à être :

Créé par le système.

Supprimé par le système.

Modifié en termes de changements dans ses valeurs d'attribut.

Ainsi, les questions initiales à poser lorsqu'on essaie d'identifier les événements de l'histoire de la vie sont :

Comment le système parvient-il à connaître cette entité ?

Pourquoi cela quitte-t-il le système ?

Qu'est-ce qui provoque des changements dans ses attributs ?

Tous les ELH contiennent deux types de nœuds :

Nœuds intermédiaires et

Feuilles (ou nœuds terminaux).

Dans la figure un, l'événement de naissance, l'itération des événements et l'événement de mort sont tous des nœuds feuilles, les événements de la vie moyenne.

est un nœud intermédiaire. La racine de l'arbre donne le nom de l'entité dont nous souhaitons la vie
Une diagramme ELH est construit pour chaque entité dans le diagramme ER.

Le passage du temps est considéré comme un flux uniforme de gauche à droite dans le diagramme. Au temps
zéro dans la vie d'une entité, le système en prend connaissance par le biais de l'arrivée d'un (ou
généralement l'un d'un ensemble) d'événements système entraînant la création d'une occurrence de l'entité dans
le système. La vie intermédiaire, la période entre la naissance et la mort, est généralement un ensemble de répétitions ou
itérations d'événements provoquant des changements à l'entité. Ce délai représente la majorité de la vie de la
entité dans le système, ainsi cette partie du diagramme peut devenir assez complexe. Finalement, la vie est
terminé par l'arrivée d'un événement de 'mort' provoquant la suppression de cette occurrence d'entité et
retiré du système.

Notation ELH
La notation de base des histoires de vie est utilisée après l'identification des événements pour enregistrer graphiquement le
séquence dans laquelle des événements et des sous-structures d'événements peuvent se produire légalement. Le nombre de distinct

les symboles pour le travail initial ELH sont limités à seulement trois, qui, avec la convention pour
représentant le passage du temps, compléter la notation. Les symboles sont :

46
 Noms d'entités, titres de groupes et événements.

* Répétition ou itération d'événements.

0 Une sélection entre deux événements ou plus.

Structures de contrôle

Il existe trois structures de contrôle qui peuvent s'appliquer à un ELH :

1. Séquence d'événements

2. Sélection d'événements

3. Itération d'événements

2.2.1 Séquence d'événements

Une séquence est représentée par une série de cases de gauche à droite comme montré dans la figure deux.

ENTITÉ X

A B C D

Figure Deux Séquence d'Événements

La boîte étiquetée A sera toujours la première à apparaître, suivie de B qui est à son tour suivie de C.
Puis D. C'est la seule séquence possible. Bien que la séquence puisse être considérée comme un
progression à travers le temps, il n'y a aucune indication des intervalles de temps entre les cases dans un
séquence. Celles-ci pourraient s'étendre sur des minutes, des heures, des jours ou des années.

47
Sélection d'événements

Une sélection définit un certain nombre d'effets ou de nœuds qui sont des alternatives les uns aux autres à un moment donné.
point dans l'ELH. Notez qu'un, et un seul, de deux ou plusieurs événements possibles se produira à un
un moment particulier dans une séquence. Une sélection est représentée par un ensemble de cases avec des cercles en haut
coins droits comme indiqué dans la figure trois.

ENTITÉ X

A B C D

E F G

Figure Trois Sélection d'Événements

Comme le nœud A est au début de l'ELH, ce diagramme montre qu'une occurrence de l'entité X doit
être créé par un seul des trois événements : E, F ou G.

Itération d'événements

Une itération est un endroit où un effet ou un nœud peut être répété un nombre quelconque de fois au même point.
dans un ELH. Une restriction sur l'itération est que chaque occurrence de l'itération doit être
compléter avant que le prochain ne commence. Cela est le plus pertinent lorsque un nœud est répété. Un
l'itération est représentée par un astérisque dans le coin supérieur droit d'une boîte comme indiqué dans la figure
quatre.

ENTITÉ X

Un B C D

*
E F G H

Itération de l'événement Figure Quatre

48
Après que l'entité X a été créée par E, F ou G, l'événement H peut affecter l'entité un nombre quelconque de fois.
Il est important de noter que 'n'importe quel nombre de fois' inclut zéro, donc une itération est
une autre façon de montrer que quelque chose peut ou non se produire.

Les 'Niveaux' dans un ELH

Une structure ELH peut s'étendre sur plusieurs niveaux de détail où chaque niveau est représenté par un
barre horizontale, immédiatement au-dessus de laquelle se trouvera un titre de groupe et en dessous les 'détails' qui
décrire collectivement la construction du titre.
Les structures d'histoire de vie devraient être des structures minimales en termes de niveaux nécessaires pour décrire un
la durée de vie de l'entité en tant que collection d'événements système. Une exigence fondamentale qui affecte directement
le nombre de niveaux montrés dans des situations particulières est que, étant donné que toutes les cases sont en dessous d'un horizontal
ligne décrivant la construction de la boîte au-dessus, le mélange des constructions dans les boîtes en dessous d'un
Une ligne horizontale entraînerait une description contradictoire. En pratique, cela signifie que toutes les cases
suspendu en dessous d'une ligne horizontale doit avoir la même structure (séquence de types d'événements, itérations
ou une sélection). Chaque fois que cette exigence ne peut pas être satisfaite, de nouveaux niveaux et des titres de groupe doivent être

introduit pour rectifier la situation.

3 Exemple travaillé (Ashworth & Goodland, 1990)

Imaginez que Maurice a décidé d'ouvrir un compte bancaire chez Cash & Grabbs Bank. Quand Maurice
a convaincu M. Cash, le directeur, qu'il serait un client convenable, M. Cash se tourne vers
son terminal informatique et enregistre le nouveau code de compte bancaire de Maurice dans le système. L'ER
Le diagramme du système informatique de la banque contient une entité appelée Compte Bancaire. L'événement
l'occurrence qui crée l'occurrence Maurice de l'entité Compte Bancaire est l'ouverture de
compte par M. Cash.

La survenue de cet événement et les suivants sont :

Compte ouvert pour Maurice.

Dépôt en espèces 2000 £

Chèque encaissé pour 20 £

Dépôt Direct 1000 £

Chèque encaissé pour 20 £

Dépôt Direct 2000 £ etc.

Jonnes est un autre client à la banque, les occurrences d'événements qui affectent son compte bancaire sont :

Compte ouvert pour Jonnes

Payer le dépôt par virement bancaire 500 £

Chèque encaissé de 200 £

49
 Chèque encaissé pour 300 £

Chèque encaissé pour 300 £

D'autres comptes peuvent se comporter de manière similaire, mais aucun d'eux n'est précisément le même. Cependant, il est
possible de dresser un tableau général qui conviendra à toutes les occurrences de comptes bancaires à la caisse et
Grabbs Bank. En gros, tous les comptes sont ouverts, et plusieurs dépôts et plusieurs retraits.
peut être fait. La façon dont ces événements affectent le compte bancaire de l'entité est montrée dans la figure cinq.

Banque
Compte

Compte Compte Compte Compte

Ouvert La vie Clôture Suppression

*
Transaction

Payer Direct Chèque

Dépôt Dépôt Encaisse

Figure Cinq ELH pour le Compte Bancaire (Cash & Grabb Bank)

Cet ELH montre que le premier événement à affecter l'entité Compte Bancaire sera Ouverture de Compte pour
toutes les occurrences. Ensuite, le compte a une vie qui est une série de transactions. Chaque transaction est
l'un des : un dépôt d'acompte, un dépôt direct ou un chèque encaissé. Après un nombre indéfini de
Des transactions ont eu lieu, le compte sera fermé et finalement supprimé.

50
SUJET 7 : CONCEPTION ET DÉVELOPPEMENT DES SYSTÈMES

THÉORIE
Signification et importance de la conception système

La conception de systèmes est le processus de définition de l'architecture, des composants, des modules, des interfaces, et
des données pour un système afin de satisfaire des exigences spécifiées. La conception des systèmes peut être considérée comme le
application de la théorie des systèmes au développement de produits.
L'analyse système décrit ce qu'un système devrait faire pour répondre aux besoins d'information des utilisateurs.
La conception du système spécifie comment le système atteindra cet objectif. La conception des systèmes consiste en
d'activités de conception, qui produisent des spécifications système satisfaisant aux exigences fonctionnelles
développées lors de la phase d'analyse des systèmes. Ces spécifications servent de base pour :
Développement de logiciels
2. Acquisition de matériel
3. Test système
4. Autres activités de la phase de mise en œuvre.

Qualités d'un bon design système

Attributs de qualité. Une bonne conception de système doit avoir les éléments suivants :

Attribut de qualité Définition

Agilité La capacité d'un système à être à la fois flexible et à subir des changements rapidement.
La facilité avec laquelle un système ou un composant peut être modifié pour être utilisé dans

Flexibilité applications ou environnements, autres que ceux pour lesquels il a été

spécialement conçu.
La capacité de deux systèmes ou plus à échanger
Interopérabilité
informations et utilise les informations qui ont été échangées.
L'aptitude d'un système à subir des réparations et une évolution.
(1) La facilité avec laquelle un système ou un composant logiciel peut être
modifié pour corriger des défauts, améliorer les performances ou d'autres attributs, ou
Maintenabilité s'adapter à un environnement changé.
La facilité avec laquelle un système ou un composant matériel peut être
conservé dans, ou restauré à, un état dans lequel il peut effectuer sa fonction requise
fonctions.
La réactivité du système, c'est-à-dire le temps nécessaire pour répondre
aux événements ou au nombre d'événements traités dans un certain intervalle de temps.
Performance Les qualités de performance sont souvent exprimées par le nombre de
transactions par unité de temps, ou par la quantité de temps que cela prend à
compléter une transaction avec le système.
La capacité du système à continuer de fonctionner dans le temps. La fiabilité est
Fiabilité généralement mesuré par le temps moyen jusqu'à la défaillance.

51
 Le degré auquel un module logiciel ou un autre produit de travail peut être
utilisé dans plus d'un programme informatique ou système logiciel. Ceci est
Réutilisabilité
typiquement sous la forme de réutiliser un logiciel qui est une unité encapsulée de
fonctionnalité.
La capacité à maintenir ou à améliorer les performances tout en répondant à la demande du système
Scalabilité
augmente.
Une mesure de la capacité du système à résister aux tentatives non autorisées de
utilisation et déni de service, tout en fournissant toujours ses services à
Sécurité
utilisateurs légitimes. La sécurité est catégorisée en fonction des types de menaces
qui pourrait être apportées au système.
La facilité avec laquelle un système logiciel peut être opérationnel
Soutenabilité
entretenu.
Le degré auquel un système ou un composant facilite le
établissement de critères de test et réalisation de tests pour déterminer
Testabilité
si ces critères ont été respectés.

La mesure de la capacité d'un utilisateur à utiliser efficacement un système

La facilité avec laquelle un utilisateur peut apprendre à utiliser, préparer des entrées pour, et
interpréter les sorties d'un système ou d'un composant.
Utilisabilité
Une mesure de la capacité des utilisateurs à tirer parti d'un système
fonctionnalité. L'utilisabilité est différente de l'utilité, qui est une mesure de
si cette fonctionnalité répond à ce qui est nécessaire.
Modèles de conception système
Un modèle de données conceptuel identifie les relations de plus haut niveau entre les différentes entités.
Les caractéristiques du modèle de données conceptuel incluent :

Inclut les entités importantes et les relations entre elles.

Aucun attribut n'est spécifié.
Aucune clé primaire n'est spécifiée.
La figure ci-dessous est un exemple d'un modèle de données conceptuel.

Modèle de données conceptuel

52
 D'après la figure ci-dessus, nous pouvons voir que la seule information présentée via le modèle de données conceptuel
ce sont les entités qui décrivent les données et les relations entre ces entités. Aucun autre
l'information est présentée à travers le modèle de données conceptuel.

MODÈLE LOGIQUE
Un modèle de données logique décrit les données dans le plus de détails possible, sans tenir compte de la façon dont elles
sera physiquement implémenté dans la base de données. Les caractéristiques d'un modèle de données logique incluent :
Comprend toutes les entités et les relations entre elles.
Tous les attributs pour chaque entité sont spécifiés.
La clé primaire pour chaque entité est spécifiée.
Les clés étrangères (clés identifiant la relation entre différentes entités) sont spécifiées.
La normalisation se produit à ce niveau.
Les étapes pour concevoir le modèle de données logique sont les suivantes :
1. Spécifiez les clés primaires pour toutes les entités.
2. Trouvez les relations entre différentes entités.
3. Trouvez tous les attributs pour chaque entité.
4. Résoudre les relations plusieurs à plusieurs.
5. Normalisation.
La figure ci-dessous est un exemple d'un modèle de données logique.

Modèle de données logique

53
 En comparant le modèle de données logique montré ci-dessus avec le diagramme du modèle de données conceptuel, nous voyons
les principales différences entre les deux :

Dans un modèle de données logique, des clés primaires sont présentes, tandis que dans un modèle de données conceptuel, aucune clé primaire n'est présente.
la clé est présente.
Dans un modèle de données logique, tous les attributs sont spécifiés au sein d'une entité. Aucun attribut n'est spécifié dans un
modèle de données conceptuel.
Les relations entre les entités sont spécifiées à l'aide de clés primaires et de clés étrangères dans un schéma de données logique.
modèle. Dans un modèle de données conceptuel, les relations sont simplement énoncées, sans être précisées, donc nous simplement
sachez que deux entités sont liées, mais nous ne spécifions pas quels attributs sont utilisés pour cela.
relation.
Le modèle de données physique représente comment le modèle sera construit dans la base de données.

Conception logique - Résumé

Un design logique est un design conceptuel et abstrait. Vous ne vous occupez pas du physique.
détails de mise en œuvre pour l'instant ; vous vous occupez uniquement de définir les types d'informations dont vous avez besoin.

Le processus de conception logique consiste à organiser les données en une série de relations logiques appelées
entités et attributs. Une entité représente un morceau d'information. Dans les bases de données relationnelles, un
Une entité correspond souvent à une table. Un attribut est un composant d'une entité et aide à définir le
unicité de l'entité. Dans les bases de données relationnelles, un attribut correspond à une colonne.

Modèle de données physique

54
 Un modèle de base de données physique montre toutes les structures de table, y compris le nom de la colonne, le type de données de la colonne.

contraintes de colonne, clé primaire, clé étrangère, et relations entre les tables. Caractéristiques d'un
le modèle de données physique inclut :
Spécification de toutes les tables et colonnes.
Les clés étrangères sont utilisées pour identifier les relations entre les tables.
La dénormalisation peut se produire en fonction des exigences des utilisateurs.
Les considérations physiques peuvent rendre le modèle de données physique très différent du modèle logique.
modèle de données.

Le modèle de données physique sera différent pour différents SGBDR. Par exemple, le type de données pour une colonne
peut différer entre MySQL et SQL Server.
Les étapes de la conception du modèle de données physiques sont les suivantes :

1. Convertir les entités en tableaux.

2. Convertir les relations en clés étrangères.
3. Convertir les attributs en colonnes.
4. Modifier le modèle de données physique en fonction des contraintes / exigences physiques.
La figure ci-dessous est un exemple d'un modèle de données physiques.

Modèle de données physique

55
 En comparant le modèle de données physique montré ci-dessus avec le diagramme du modèle de données logique, nous voyons le
principales différences entre les deux :

Les noms d'entités sont maintenant des noms de tables.

Les attributs sont maintenant des noms de colonnes.
Le type de données pour chaque colonne est spécifié. Les types de données peuvent être différents en fonction du réel.
base de données utilisée.

Résumé de logique vs. physique

À ce moment, les exigences commerciales sont déjà définies, la portée de l'application

a été convenu, et vous avez un design conceptuel. Donc maintenant vous devez traduire votre
exigences en un livrable système. Dans cette étape, vous créez la conception logique et physique pour
l'entrepôt de données et, dans le processus, définir le contenu de données spécifique, les relations internes et
entre les groupes de données, l'environnement système soutenant votre entrepôt de données, les données
transformations requises, et la fréquence à laquelle les données sont actualisées.

Dans la conception logique, vous examinez les relations logiques entre les objets.

Dans la conception physique, vous examinez le moyen le plus efficace de stocker et de récupérer les objets.

Votre conception doit être orientée vers les besoins des utilisateurs finaux. Les utilisateurs finaux souhaitent généralement
effectuer une analyse et examiner les données agrégées/globales, plutôt que les transactions individuelles. Votre
la conception est principalement motivée par l'utilité pour l'utilisateur final, mais les utilisateurs finaux peuvent ne pas savoir ce dont ils ont besoin
jusqu'à ce qu'ils le voient. Un design bien planifié permet la croissance et les changements en fonction des besoins des utilisateurs

changer et évoluer.

En commençant par la conception logique, vous vous concentrez principalement sur les besoins en information sans
s'enliser immédiatement dans les détails de l'implémentation.

Composants de conception système

Entrée

Les utilisateurs méritent une sortie de qualité. La qualité de l'entrée du système détermine la qualité de la sortie du système.
Il est essentiel que les formulaires d'entrée, les affichages et les documents Web interactifs soient conçus avec ce critère essentiel.

relation en tête. Formulaires d'entrée, affichages et formulaires interactifs bien conçus

doit répondre aux objectifs d'efficacité, d'exactitude, de facilité d'utilisation, de cohérence, de simplicité, et
attractivité. Tous ces objectifs sont réalisables grâce à l'utilisation de principes de conception de base, le
connaissance de ce qui est nécessaire en entrée pour le système, et compréhension de la façon dont les utilisateurs réagissent
à différents éléments de formulaires et d'affichages.

L'efficacité signifie que les formulaires d'entrée, les affichages d'entrée et les formulaires à remplir sur le Web servent tous à
des objectifs spécifiques pour les utilisateurs du système d'information, tandis que la précision se réfère à la conception qui
assure une bonne réalisation. La facilité d'utilisation signifie que les formulaires et les affichages sont simples et directs.

56
 ne nécessitent pas de temps supplémentaire pour que les utilisateurs puissent les déchiffrer. La cohérence signifie que tous les formulaires d'entrée, qu'ils soient
sont des affichages d'entrée ou des formulaires à remplir sur le Web, regroupent des données de manière similaire d'une application à l'autre

ensuite, tandis que la simplicité fait référence à garder ces mêmes designs épurés d'une manière qui se concentre
l'attention de l'utilisateur. L'attrait implique que les utilisateurs apprécieront utiliser des formulaires d'entrée en raison de leur

design attrayant

Conception de processus

L'activité de conception de processus se concentre sur la conception des ressources logicielles, c'est-à-dire des ordinateurs.

programmes et procédures nécessaires au système d'information proposé. Il se concentre sur

élaborer des spécifications détaillées pour les modules du programme qui devront être achetés en tant que
logiciels ou développés par programmation sur mesure. La conception de processus produit :
1. Spécifications détaillées du programme et procédures nécessaires pour répondre à l'interface utilisateur et aux données
spécifications de conception qui sont développées.
2. Produit des spécifications qui répondent aux exigences de contrôle fonctionnel et de performance
développé au stade d'analyse.

Rapports

Principalement utilisé pour transmettre de grandes quantités de données dans la base de données. La sortie peut être spécialement formatée
pour une variété de purposes telles que l'impression d'étiquettes de messagerie.

Conception de code

La conception du système doit être mise en œuvre pour en faire un système fonctionnel. Cela exige le
la codification du design dans un langage compréhensible par l'ordinateur, c'est-à-dire, le langage de programmation. Cela est également

appelée la phase de programmation dans laquelle le programmeur convertit les spécifications du programme en
Instructions informatiques, que nous appelons des programmes. C'est une étape importante où les définitions
les procédures sont transformées en spécifications de contrôle grâce à un langage informatique. Le
les programmes coordonnent les mouvements de données et contrôlent l'ensemble du processus dans un système. Il est généralement
ressentait que les programmes doivent être de nature modulaire. Cela aide au développement rapide, à la maintenance et
changements futurs, si nécessaire.

Conception de base de données

Si vous créez une base de données, vous devez inclure un diagramme E-R. Vous devez montrer le
diagramme et explique ce que signifie chacune des relations. Par exemple :

Un étudiant peut avoir de nombreuses réservations

Chaque réservation n'a qu'un seul étudiant
Chaque réservation n'a qu'un seul livre

57
Un livre peut être impliqué dans de nombreuses réservations

Exemple de requêtes SQL planifiées

Si vous créez une base de données, vous devez écrire sur le SQL que vous utilisez pour SELECT,
INSÉRER, METTRE À JOUR et SUPPRIMER des éléments de vos tables. Dans certains cas, vous pourriez également être
rédaction du code derrière la création des tables individuelles, le langage de définition de données. En fait, ceux
Les en-têtes sont exactement ce dont vous avez besoin.

Mots réservés

Lorsque vous interrogez votre base de données, vous pourriez rencontrer des erreurs inattendues, où une requête échoue.
s'exécuter lorsqu'il ne semble pas y avoir de problème avec cela. Cela peut être dû à l'utilisation d'un réservé
mot dans votre requête. SQL a beaucoup de mots réservés, des mots qui ont des significations particulières, et si
vous utilisez l'un de ces éléments dans une requête, il ne sera pas traité comme un nom de champ. Par exemple :

SÉLECTIONNER NomD'utilisateur, MotDePasse DE tblUtilisateurs

Cela pourrait entraîner une erreur car le mot de passe est un mot réservé en SQL. Pour contourner ce problème, vous
vous voudrez peut-être changer vos noms de champ en quelque chose d'un peu plus sensé ou mettre le nom du champ dans
crochets

SÉLECTIONNER NomUtilisateur,[MotDePasse] DE tblUtilisateurs

Il y a beaucoup d'autres mots réservés là-bas, alors soyez prudent :

POURCENT
SAUVEGARDE, ÉTRANGER, LIRE, TEXTE_EN_CLAR, DE, RÉFÉRENCES, BULK
COMPLET
STATISTIQUES
DISQUE

Différentes bases de données ont des ensembles différents de mots réservés.

Remarque : Si vous n'utilisez pas un serveur SQL (par exemple, si vous utilisez MySQL avec PHP), vous devrez peut-être
utilisez des `backticks` au lieu de la notation entre crochets.

SÉLECTIONNER

Cette section devrait lister tout le SQL que vous avez écrit qui renvoie des sélections de dossiers. Vous
devrait décrire en anglais simple où le SQL est utilisé et ce qu'il fait et ensuite inclure le
SQL avec toutes les annotations dont vous avez besoin. Par exemple :

French Description
Cette instruction SQL sélectionne les détails (ID, Nom, Prix, Description) d'un produit qui a été

58
sélectionné par l'utilisateur. Ainsi, l'utilisateur peut voir les détails du produit sur l'écran d'aperçu avant
acheter le produit

SQL :

SÉLECTIONNER ID, Nom, Prix, Description DE Produits

OÙ ID=?

INSÉRER

Cette section devrait lister tout le SQL que vous avez écrit qui insère de nouveaux enregistrements dans votre base de données.
Vous devriez décrire en anglais simple où le SQL est utilisé et ce qu'il fait, puis inclure le
SQL avec toutes les annotations dont vous avez besoin. Par exemple :

Anglais Description
Cette instruction SQL ajoute un nouveau score élevé ainsi que la date à laquelle le score a été atteint pour un utilisateur.
compte.

SQL :

INSÉRER DANS Scores (ID, DateDuScore, Score)

VALEURS(?,?,?)

MISE À JOUR

Cette section doit lister tout le SQL que vous avez écrit qui met à jour un ancien enregistrement avec de nouveaux détails.
Vous devriez décrire en anglais simple où le SQL est utilisé et ce qu'il fait, puis inclure le
SQL avec toutes les annotations dont vous avez besoin. Par exemple :

Anglais Description
Cette déclaration SQL met à jour la date de naissance d'un utilisateur, après qu'il ait mis à jour le formulaire qui
se lance lorsqu'ils se connectent pour la première fois au programme.

SQL :

METTRE À JOUR L'UTILISATEUR

DEUX DoB=?
OÙ ID=?

Langage de définition de données

Si vous avez conçu vos tables de base de données à l'aide d'un programme tel qu'Open ModelSphere, vous pouvez
définissez ensuite le code derrière la création de vos tables que vous pouvez ensuite alimenter dans MySQL ou MSSQL
pour créer votre base de données. Obtenez du crédit pour cela et listez votre DDL. Par exemple, la commande pour
créez une table nommée employés avec quelques colonnes d'exemple telles que :

59
 CREERTABLE employés (
id CLEPRIMAIREENTIÈRE
CHAR(50)NULL
nom_de_famille CHAR(75)NONNULL
DATENULL
);

Conception de fichier

Outils de conception de systèmes

Tables de décision

Un tableau de décision est créé en énumérant toutes les variables pertinentes (parfois appelées conditions ou
entrées) et toutes les actions pertinentes sur le côté gauche du tableau ; notez que les variables et actions
ont été séparés de manière pratique par une lourde ligne horizontale. Dans cet exemple, chaque variable est un
variable logique, ce qui signifie qu'elle peut prendre la valeur de vrai ou faux.

Dans de nombreuses applications, il est facile (et préférable) d'exprimer les variables sous forme binaire (vrai-faux)
des variables, mais des tables de décision peuvent également être construites à partir de variables multivaluées ; par exemple, on pourrait

moins que
10, entre 10 et 30, et plus de 30.

60
 Ensuite, chaque combinaison possible des valeurs des variables est répertoriée dans une colonne séparée ; chaque
Une colonne est généralement appelée une règle. Une règle décrit l'action (ou les actions) qui doivent être effectuées.
pour une combinaison spécifique de valeurs des variables. Au moins une action doit être spécifiée pour
chaque règle (c'est-à-dire pour chaque colonne verticale dans le tableau de décision), ou le comportement du système pour
cette situation sera non spécifiée.

S'il y a N variables avec des valeurs binaires (vrai-faux), alors il y aura 2Nrègles distinctes; ainsi, si
il y a 3 conditions, il y aura 8 règles.

Vous devez discuter chaque règle avec l'utilisateur pour vous assurer que vous avez identifié la bonne action, ou
actions, pour chaque combinaison de variables. Il est assez courant, lorsque l'on fait cela, de constater que le
l'utilisateur n'a jamais pensé à certaines combinaisons de variables ou qu'elles ne se sont jamais produites dans
son ou sa expérience.

Avantages de DT

L'avantage de l'approche par tableau de décision est que vous pouvez vous concentrer sur une règle à la fois.

2. Cela n'implique aucune forme particulière de mise en œuvre. C'est-à-dire que lorsque l'analyste des systèmes
livre la table de décision (avec les DFD, etc.) au concepteur/programmeur, il y a un
une immense liberté de choix en termes de stratégie de mise en œuvre : le tableau de décision peut être
programmé avec des instructions IF imbriquées, avec une construction CASE ou un GO TO SELON
construire en COBOL; dans le cas extrême, un générateur de code de tableau de décision peut automatiquement
générer du code à partir du tableau de décision. Ainsi, les tableaux de décision sont souvent appelés un
outil de modélisation de système non procédural, car ils n'exigent aucun algorithme procédural spécifique pour
effectuer les actions requises.

En résumé, nous devons suivre les étapes suivantes pour créer un tableau de décision pour un processus
spécification :

1. Identifiez toutes les conditions, ou variables, dans la spécification. Identifiez toutes les valeurs que chacune
variable peut prendre.
2. Calculez le nombre de combinaisons de conditions. Si toutes les conditions sont binaires, alors il y a
2N combinaisons de N variables.
3. Identifiez chaque action possible qui est requise dans la spécification.
4. Créez un tableau de décision « vide » en répertoriant toutes les conditions et actions sur le côté gauche et
numéroter les combinaisons de conditions en haut du tableau.
5. Listez toutes les combinaisons de conditions, une pour chaque colonne verticale du tableau.
6. Examinez chaque colonne verticale (appelée règle) et identifiez les actions appropriées à entreprendre.
7. Identifier toute omission, contradiction ou ambiguïté dans la spécification (par exemple, les règles dans le
table de décision pour laquelle la spécification n'indique pas que des actions doivent être entreprises).
8. Discutez des omissions, des contradictions et des ambiguïtés avec l'utilisateur.

Anglais structuré

61
Structure de décision
Seulement SI une condition est vraie
Complétez ce qui suit
Déclarations ; sinon, passez à la déclaration suivante
SINON
Code d'exemple
SI le code A est vrai
ALORS mettez en œuvre l'action A
SINON mettre en œuvre l'Action B
FIN SI

DIAGRAMMES DE RELATION D'ENTITÉS (ERD)

Un ERD est un modèle qui identifie les concepts ou entités qui existent dans un système et le
les relations entre ces entités. Un ERD est souvent utilisé comme un moyen de visualiser une relation
base de données : chaque entité représente une table de base de données, et les lignes de relation représentent les clés dans
une table qui pointe vers des enregistrements spécifiques dans des tables associées. Les DER peuvent également être plus abstraits, pas
nécessairement capturer chaque table nécessaire dans une base de données, mais servant à diagrammer les principaux
concepts et relations.

Règles pour dessiner des ERD

62
Termes utilisés dans les DER

Entités

Les entités sont des concepts au sein du modèle de données. Chaque entité est représentée par une boîte dans le DER.
Les entités sont des concepts abstraits, chacun représentant une ou plusieurs instances du concept en question.
Une entité peut être considérée comme un conteneur qui contient toutes les instances d'une chose particulière dans un
Les entités sont équivalentes à des tables de base de données dans une base de données relationnelle, chaque ligne de la
table représentant une instance de cette entité.

Rappelez-vous que chaque entité représente un conteneur pour les instances de la chose en question.
Le diagramme ci-dessous comporte une entité pour « étudiant » et une autre pour « école ». Cela indique que le
le système modélisé peut contenir un ou plusieurs étudiants et une ou plusieurs écoles.

ÉTUDIANT ÉCOLE

63
Jusqu'à présent, aucune relation entre les étudiants et les écoles n'a été indiquée.

Relations

Les relations sont représentées par des lignes entre les entités. Les lignes de relation indiquent que chacune
Une instance d'une entité peut avoir une relation avec des instances de l'entité connectée, et vice versa.
versa.

ÉTUDIANT ÉCOLE

Le diagramme ci-dessus indique maintenant que les étudiants peuvent avoir une certaine relation avec les écoles.
Plus précisément, il peut y avoir une relation entre un élève particulier (une instance de la
entité étudiante) et une école particulière (une instance de l'entité école).

Si nécessaire, une ligne de relation peut être étiquetée pour définir la relation. Dans ce cas, une
on peut déduire qu'un étudiant peut fréquenter une école, ou qu'une école peut inscrire des étudiants. Mais si nécessaire,
cette relation pourrait être étiquetée pour clarification :

attends
ÉTUDIANT ÉCOLE
s'inscrire

Lisez la première définition de la relation, ―attend,‖ en traçant la relation de gauche à droite ou de haut en bas.
inférieur. Lisez la deuxième définition, ―enregistre ‖, en traçant la relation de droite à gauche ou vers le bas
en haut.

Optionalité et Cardinalité

Les symboles à la fin des lignes de relation indiquent l'optionnalité et la cardinalité de

Chaque relation. ―L'« optionnalité » exprime si la relation est optionnelle ou obligatoire.
« Cardinalité » exprime le nombre maximum de relations.

Lorsqu'une ligne de relation est tracée d'une entité à une autre, près de l'entité associée, deux
) indique que
des symboles apparaîtront. Le premier de ceux-ci est l'indicateur d'optionnalité. Un cercle (
la relation est optionnelle - le nombre minimum de relations entre chaque instance de la
la première entité et les instances de l'entité liée sont nulles. On peut penser au cercle comme à un zéro, ou à un
La lettre O pour « optionnel ». Une barre ( | ) indique que la relation est obligatoire—le minimum
nombre de relations entre chaque instance de la première entité et les instances de l'entité liée
est un.

Le deuxième symbole indique la cardinalité. Un trait ( | ) indique que le nombre maximum de

les relations en sont une. Un « pied de corbeau » ( ) indique qu'il existe de nombreuses relations de ce type entre
des instances des entités connexes pourraient exister.

64
Le diagramme suivant indique toutes les combinaisons possibles :

Chaque instance deAest liée à un minimum de

A B
zéro et un maximum d'une instance de B

Chaque instance de B est liée à un minimum de

Un B
une et au maximum une instance deA

Chaque instance deAest liée à un minimum de

Un B
un et un maximum de nombreuses instances de B

Chaque instance de B est liée à un minimum de

Un B
zéro et un maximum de nombreuses instances deA

Dans notre modèle, nous souhaitons indiquer que chaque école peut inscrire de nombreux élèves, ou ne peut en inscrire aucun.
les étudiants en tout. Nous souhaitons également indiquer que chaque étudiant fréquente exactement une école.
Le diagramme suivant indique cette optionalité et cardinalité :

ÉTUDIANT
Chaque école inscrit Chaqueétudiantassiste

aumoinszéro aumoinsun

etauplusbeaucoup etauplusun

étudiants école
ÉCOLE

Il est important de noter que les contraintes d'optionnalité et de cardinalité des relations s'appliquent.
spécifiquement au système modélisé, pas à tous les systèmes possibles. Selon l'exemple
modélisé ci-dessus, une école pourrait ne pas inscrire d'élèves - cette relation est optionnelle. Une école
sans élèves, il n'y a pas grand-chose à une école, et en effet si le système modélisé était une école
base de données d'inscription du système, la relation serait probablement obligatoire. Cependant, si le
le système modélisé est un programme d'honneurs parascolaire, il peut y avoir des écoles qui n'ont pas
étudiants participant actuellement au programme.

Entités de pont

65
 Lorsqu'une instance d'une entité peut être liée à plusieurs instances d'une autre entité et
réciproquement, cela s'appelle une « relation plusieurs à plusieurs ». Dans l'exemple ci-dessous, un fournisseur peut
offrir de nombreux produits différents, et chaque type de produit peut être proposé par de nombreux fournisseurs :

fournit/
FOURNISSEUR PRODUIT
offertpar

Bien que ce modèle de relation soit parfaitement valide, il ne peut pas être traduit directement en un
conception de base de données relationnelle. Dans une base de données relationnelle, les relations sont exprimées par des clés dans une table

colonne qui pointe vers l'instance correcte dans la table associée. Une relation plusieurs-à-plusieurs fait
ne pas autoriser cette expression de relation, car chaque enregistrement dans chaque table pourrait devoir pointer vers
plusieurs enregistrements dans l'autre table.

Afin de construire une base de données relationnelle qui capture cette relation, il est nécessaire de construire un
un pont entre les deux entités qui exprime de manière unique chaque instance de relation. Cela peut être
modélisé dans un DER avec une « entité pont », une boîte d'entité contenant un diamant, qui peut
remplacer la relation plusieurs-à-plusieurs. (Le losange est utilisé dans d'autres systèmes de modélisation ER pour
indique des relations, ou peut être considéré comme le lien—le pont—du plusieurs à plusieurs
―pattes d'oie‖).

FOURNIT
FOURNISSEUR PRODUIT
OFFERTPAR

Ce diagramme exprime la même relation que le diagramme ci-dessus. Chaque instance de la

L'entité de pont « fournit » indique qu'un certain fournisseur peut fournir un certain produit.

En plus de décrire explicitement une structure de base de données relationnelle pouvant capturer un relation plusieurs à plusieurs
Dans de nombreuses relations, l'entité de liaison a une fonction supplémentaire dans l'entité-relationship abstraite.
modélisation : Une entité de pont peut capturer des attributs qui sont spécifiques à la relation entre
instances des entités reliées. Dans l'exemple du fournisseur et du produit, un produit n'a pas d'
coût inhérent ; il n'a de coût qu'en relation avec le fournisseur qui le vend. De même, un fournisseur peut
n'ont pas de délai de livraison uniforme ; les délais de livraison peuvent varier en fonction du produit étant
livré. Tous les attributs qui dépendent de la relation seraient associés au
entité pont de la relation.

Relations récursives

Les instances d'entités peuvent avoir des relations avec d'autres instances de la même entité. Ces
Les relations peuvent être établies avec des lignes de relation qui commencent et se terminent connectées au même
entité. Des occurrences courantes de ces relations récursives incluent des relations parent/enfant :

66
 PERSONNE

père de
enfant de

Le diagramme ci-dessus indique qu'une personne peut être le père de zéro ou de plusieurs personnes, et que
une personne peut avoir zéro ou un père. (Le père de chaque personne ne sera pas nécessairement enregistré dans le système,
donc la relation est modélisée comme facultative).

Relations multiples entre les entités

Une entité peut avoir plusieurs relations avec une autre entité. Celles-ci sont représentées dans le DER.
avec plusieurs lignes de relation reliant les deux entités

vendeur

EMPLOYÉ CLIENT

représentantduserviceclient

Le diagramme ci-dessus indique qu'un employé peut être le vendeur assigné à zéro ou
de nombreux clients, et un employé peut être le représentant du service client pour zéro ou de nombreux
clients. Chaque client a exactement un vendeur et exactement un représentant du service clientèle.
Le vendeur de chaque client peut ou non être le même employé que le service client du client.
représentant; chaque relation est traitée indépendamment.

Sous-types d'entités

Il y a des moments où il est pratique de représenter des relations qui s'appliquent à une classe entière de
choses, ainsi que dépeindre des relations qui s'appliquent uniquement à certains types de la classe plus grande. Entité
les sous-types accommodent ces représentations de relations. Dans le DER, les sous-types d'entité peuvent être
représenté par des boîtes d'entités montrées à l'intérieur de plus grandes boîtes d'entités. La grande entité représente la classe,
et les cases plus petites décrivent les sous-types

67
 INVENTAIRE

VÉHICULE MODÈLE

MFG.
EMPLACEMENT
PARTIE

L'exemple ci-dessus illustre une entité « inventaire », avec les sous-types « véhicule » et « pièce ».
Un véhicule a une ou plusieurs pièces, et chaque pièce est associée à un seul et unique type de véhicule.
(selon ce diagramme, il n'y a pas de composants interchangeables). Tous les articles en stock,
qu'ils soient des véhicules ou des pièces, ont un lieu de fabrication, mais seuls les véhicules sont d'un
modèle particulier.

Graphiques structurés

Utiliser des diagrammes de structure pour concevoir des systèmes modulaires

Une fois l'approche de conception descendante adoptée, l'approche modulaire est utile en programmation.
Cette approche consiste à diviser la programmation en portions logiques et gérables, ou modules.
Ce type de programmation fonctionne bien avec la conception descendante car il met l'accent sur les interfaces.
entre les modules et ne les néglige pas jusqu'à plus tard dans le développement des systèmes. Idéalement, chaque
Chaque module individuel doit être cohérent fonctionnellement afin qu'il soit chargé d'accomplir uniquement
une fonction.

La conception de programmes modulaires présente trois principaux avantages.

1. Les modules sont plus faciles à écrire et à déboguer car ils sont pratiquement autonomes. Suivre un
Une erreur dans un module est moins compliquée, car un problème dans un module ne devrait pas causer
problèmes chez les autres.

2. Les modules sont plus faciles à maintenir. Les modifications seront généralement limitées à quelques modules et
ne sera pas réparti sur un programme entier. Un troisième avantage de la conception modulaire est que les modules
sont plus faciles à comprendre, car ce sont des sous-systèmes autonomes. Ainsi, un lecteur peut saisir un
liste de code d'un module et comprendre sa fonction.

Quelques directives pour la programmation modulaire incluent les éléments suivants :

1. Gardez chaque module à une taille gérable (idéalement en incluant uniquement une fonction).
2. Portez une attention particulière aux interfaces critiques (les variables de données et de contrôle qui sont
passé à d'autres modules).

68
 3. Minimisez le nombre de modules que l'utilisateur doit modifier lors des changements.
4. Maintenez les relations hiérarchiques établies dans les phases descendantes.

L'outil recommandé pour concevoir un système modulaire, de haut en bas, s'appelle un diagramme de structure.
Le diagramme de structure est simplement un diagramme composé de boîtes rectangulaires, qui représentent les modules,
et des flèches de connexion.

La figure illustrée ci-dessous est un ensemble de modules utilisés pour modifier un enregistrement client, montre sept
modules qui sont étiquetés 000, 100, 110, 120, et ainsi de suite. Les modules de niveau supérieur sont numérotés par
Les centaines, et les modules de niveau inférieur sont numérotés par dizaines. Cette numérotation permet aux programmeurs de

insérer des modules en utilisant un numéro entre les numéros de modules adjacents. Par exemple, un module
inséré entre les modules 110 et 120 recevrait le numéro 115.

Un diagramme de structure encourage la conception descendante en utilisant des modules.

Sur les côtés des lignes de connexion, deux types de flèches sont dessinées. Les flèches avec le
les cercles vides sont appelés couples de données, et les flèches avec les cercles remplis sont appelées contrôle
des indicateurs ou des commutateurs. Un commutateur est le même qu'un indicateur de contrôle, sauf qu'il est limité à deux valeurs :

soit oui soit non. Ces flèches indiquent que quelque chose est transmis soit au module inférieur
ou jusqu'à celui du haut.

Idéalement, l'analyste devrait maintenir ce couplage au minimum. Moins il y a de couples de données et de contrôle
plus il y a de drapeaux dans le système, plus il est facile de changer le système. Lorsque ces modules sont réellement
programmé, il est important de faire passer le moins de couples de données entre les modules.

Il est encore plus important d'éviter de nombreux indicateurs de contrôle. Le contrôle est conçu pour être
passé des modules de niveau inférieur à ceux de niveau supérieur dans la structure. Cependant, dans de rares occasions, il
il sera nécessaire de passer le contrôle vers le bas dans la structure. Lorsque le contrôle est transmis vers le bas, un
un module de bas niveau est autorisé à prendre une décision, et le résultat est un module qui exécute deux
différentes tâches. Ce résultat viole l'idéal d'un module fonctionnel : il ne devrait exécuter qu'une seule
tâche.

Même lorsqu'un diagramme de structure accomplit tous les objectifs pour lesquels il a été réalisé, la structure
le graphique ne peut pas se tenir seul comme la seule technique de conception et de documentation. D'abord, il ne montre pas

69
 l'ordre dans lequel les modules doivent être exécutés (un diagramme de flux de données accomplira cela).
Deuxièmement, cela ne montre pas assez de détails (un anglais structuré y parviendra)

Autre

Méthodologies de développement système

Il existe plusieurs approches ou méthodologies qui peuvent être utilisées. Parmi elles figurent :

structuré

L'objectif de l'approche structurée est de construire un nouveau et meilleur système et pas seulement d'améliorer le
ancien système. C'est essentiellement une approche d'équipe et donc applicable à de grands projets. Le
approche utilisant des diagrammes de flux de données et des graphiques de structure avec documentation accompagnante
définir une méthode logique de ce qui est requis, laissant la mise en œuvre du comment jusqu'à plus tard.

L'approche de base est :

a) examinez le système actuel et voyez ce qu'il peut accomplir,

b) ensemble avec toutes nouvelles exigences, produire un modèle logique de la spécification complète. Cela
le modèle spécifie ce qui est requis.

REMARQUE :

Les spécifications réalisées de manière structurée doivent être concises, faciles à modifier et capables
d'un développement de haut en bas. C'est-à-dire que nous commençons par un problème global et que nous l'identifions à l'intérieur.

pièces de composants et ensuite des parties des parties, etc. Cela crée une hiérarchie de détails jusqu'à
niveau le plus basique. Afin d'identifier les parties, nous utilisons des diagrammes de flux de données et à partir de cela nous
dériver des diagrammes de structure, puis les modules individuels ou composants des diagrammes de structure peuvent être
rédigé dans un langage de conception appelé PSEUDO codes ou Anglais Structuré.

Méthode/approche traditionnelle

L'approche traditionnelle consiste à informatiser une amélioration du système existant. Beaucoup de

les défauts sont transférés au nouveau système et il n'y a aucune possibilité d'implication des utilisateurs

conception orientée objet

Méthodes de conception de systèmes

70
Prototypage

Le prototypage consiste à construire un système expérimental rapidement et à moindre coût pour les utilisateurs finaux.
pour évaluer. En interagissant avec le prototype, les utilisateurs peuvent avoir une meilleure idée de leurs informations
Les exigences. Le prototype approuvé par les utilisateurs peut être utilisé comme modèle pour créer le produit final.
système.

Le prototype est une version fonctionnelle d'un système d'information ou d'une partie du système, mais il est destiné
être uniquement un modèle préliminaire. Une fois opérationnel, le prototype sera encore affiné jusqu'à ce qu'il
conforme précisément aux exigences des utilisateurs. Une fois le design finalisé, le prototype peut
être transformé en un système de production poli.

Le processus de création d'un design préliminaire, de l'essayer, de le peaufiner et de le réessayer a été

appelé un processus itératif de développement de systèmes parce que les étapes requises pour construire le système
peut être répété encore et encore et promeut activement des changements de conception du système. Cela a été
a déclaré que le prototypage remplace le retravail non planifié par une itération planifiée, chaque version étant plus
réfléchissant précisément aux exigences des utilisateurs.

Identifier les bases

Étape 1
exigences

Développer un travail
Étape 2
prototype

Utilisez le prototype Étape 3

Oui Utilisateur satisfait ?

No

Réviser et
Opérationnel
améliorer le
prototype Étape 4
prototype

71
 Le modèle en quatre étapes du processus de prototypage,

Étape 1 Identifiez les besoins de base des utilisateurs. Le concepteur système (généralement un système d'information
Le spécialiste travaille avec l'utilisateur juste assez longtemps pour saisir ses besoins fondamentaux.
Étape 2 Développez un prototype initial. Le concepteur du système crée un prototype fonctionnel rapidement en utilisant 4th
génération de logiciels, multimédia interactif ou génie logiciel assisté par ordinateur (CASE)
outils.

Étape 3 Utilisez le prototype. L'utilisateur est encouragé à travailler avec le système afin de déterminer comment
eh bien le prototype répond à leurs besoins et pour faire des suggestions pour améliorer le prototype.

Étape 4 Réviser et améliorer le prototype. Le constructeur du système note tous les changements demandés par l'utilisateur et
affine le prototype en conséquence. Après que le prototype a été révisé, le cycle revient à l'étape 3
et les étapes 3 et 4 sont répétées jusqu'à ce que l'utilisateur soit satisfait.

Avantages et Inconvénients
Le prototypage est le plus utile lorsqu'il y a une certaine incertitude concernant les exigences ou les solutions de conception.
Le prototypage est particulièrement utile dans la conception de l'interface utilisateur des systèmes d'information - la partie
du système avec lequel les utilisateurs interagissent. Parce que le prototypage encourage une intense interaction avec les utilisateurs finaux.

l'implication tout au long du processus de développement des systèmes est plus susceptible de produire des systèmes
qui répondent aux exigences des utilisateurs.
Cependant, le prototypage rapide peut passer sous silence des étapes essentielles dans le développement des systèmes. Si le
le prototype terminé fonctionne raisonnablement bien, la direction peut ne pas voir la nécessité de
reprogrammation, redesign ou documentation complète et tests pour construire un système de production raffiné.
Certaines de ces systèmes construits à la hâte peuvent ne pas facilement accueillir de grandes quantités de données ou
un grand nombre d'utilisateurs dans un environnement de production.

Développement du Système Jackson (JSD)

Jackson System Development (JSD) est une méthode de développement de systèmes qui couvre le
le cycle de vie des logiciels soit directement, soit en fournissant un cadre dans lequel des éléments plus spécialisés
les techniques peuvent s'adapter. Le développement du système Jackson peut commencer à l'étape d'un projet où il
n'est qu'une déclaration générale des exigences. Cependant, de nombreux projets qui ont utilisé Jackson
Le développement du système a en fait commencé légèrement plus tard dans le cycle de vie, réalisant les premières étapes en grande partie
à partir de documents existants plutôt que directement avec les utilisateurs.

D'un point de vue technique, il y a trois étapes majeures dans le développement du système Jackson,
chacun divisé en étapes et sous-étapes :

JSD : La phase de modélisation

Au stade de modélisation, les développeurs font une description des aspects de l'entreprise ou
organisation dont le système sera concerné. Pour en faire une description, ils doivent analyser

72
 leur entreprise, choisissant ce qui est pertinent et ignorant ce qui ne l'est pas. Ils doivent prendre en compte le
l'organisation telle qu'elle sera, pas telle qu'elle est maintenant.

La description du modèle est écrite très précisément. Cette précision oblige le développeur à demander
questions détaillées. Cela encourage une bonne communication et compréhension entre les développeurs,
utilisateurs, et tous les autres impliqués dans le nouveau système.

La description du modèle se compose d'actions, d'entités et d'informations connexes. Une action est un événement,
habituellement dans la réalité externe, qui est pertinente pour le système et dont la survenance le système
doit être enregistré. En termes de mise en œuvre, les actions peuvent entraîner des mises à jour de la base de données. Nous commençons par Jackson

Développement de système en établissant une liste d'actions avec définitions et attributs associés.
Les diagrammes décrivent les relations d'ordre entre les actions. Les diagrammes décrivent les entités,
les personnes ou les choses qui préoccupent le système.

Les données à stocker pour chaque entité sont ensuite définies. En effet, nous choisissons ce qui doit être
souvenir par chaque entité des actions qui l'affectent. La définition complète de ces données inclut
une élaboration du diagramme d'entités pour montrer en détail les règles de mise à jour.

Le résultat de la phase de modélisation est un ensemble de tableaux, de définitions et de diagrammes qui décrivent :

en termes d'utilisateur, exactement ce qui se passe dans l'organisation et ce qui doit être enregistré à propos de quoi
arrive, et
en termes d'implémentation, le contenu de la base de données, les contraintes d'intégrité et la mise à jour
règles.

JSD : La Scène Réseau

Dans la phase de réseau, nous élaborons une description précise de ce que le système doit faire, y compris le
les résultats qui doivent être produits et la façon dont le système doit apparaître à l'utilisateur. Cette description est
en termes de réseau de programmes. Nous commençons ce réseau en créant un programme pour chacun des
entités qui ont été définies lors de l'étape de modélisation. Le réseau est ensuite construit de manière incrémentale par
ajout de nouveaux programmes et connexion à l'infrastructure existante. De nouveaux programmes sont ajoutés
pour les raisons suivantes :

Pour collecter des entrées pour les actions, les vérifier pour des erreurs et les transmettre aux programmes des entités. Dans ce
la manière dont les programmes d'entités sont tenus à jour avec ce qui se passe à l'extérieur;
Pour générer des entrées pour des actions qui ne correspondent pas à des événements externes. De telles actions sont
substituts pour les événements du monde réel, peut-être parce que ces événements ne peuvent pas être détectés;
Calculer et produire des résultats.

Il existe deux moyens de connecter des programmes dans le réseau. Ce sont des flux de données.
(représenté sur notre diagramme de réseau de cercles) et par inspection du vecteur état (représenté sur notre
diagrammes de réseau par des diamants). Quel que soit le type de connexion approprié, les programmes d'entité
jouer un rôle essentiel dans la construction du réseau. La plupart des nouveaux programmes peuvent être connectés
directement aux programmes d'entités.

73
 Nous dessinons un ensemble complet de diagrammes de réseau pour décrire le système. Différents réseaux n'ont généralement que
ont des programmes d'entité en commun. Le système complet est représenté par le superposition de tous les
diagrammes.

Les diagrammes sont accompagnés d'informations textuelles décrivant le contenu des flux de données et
connexions de vecteur d'état. Les nouveaux programmes qui sont ajoutés au réseau sont définis à l'aide de
la même notation diagrammatique utilisée pour décrire l'ordre des actions. Ces nouveaux programmes sont
conçu en utilisant la méthode JSP (Jackson Structured Programming), qui est maintenant un sous-ensemble de JSD.

JSD : La phase de mise en œuvre

Le résultat de la phase de mise en œuvre est le système final. Cette étape est la seule directement
concerné par la machine et le logiciel associé sur lequel le système doit fonctionner. Par conséquent,
tout en produisant et en testant du code, la phase d'implémentation couvre les problèmes de conception physique. Dans
particulièrement cela couvre :

conception des données physiques, et

reconfigurer le réseau en combinant des programmes.

La conception des données physiques concerne la conception des fichiers ou des bases de données. Les détails de la conception de la base de données.

dépend du SGBD particulier utilisé. Cependant, les informations nécessaires sur le

l'application est entièrement disponible depuis l'étape réseau. Le plus important est les données définies pour
chaque entité et le volume élevé d'accès à ces données tel que défini par l'état fréquemment utilisé
connexions vectorielles.

Le résultat de la phase réseau est un réseau de programmes hautement distribué. Souvent, pour
commodité ou efficacité, nous convertissons les programmes en sous-routines, combinant en effet plusieurs
programmes en un seul, de sorte qu'un fragment du réseau soit implémenté comme un programme unique. Le
le réseau est reconfiguré d'une forme appropriée pour la spécification en une forme appropriée pour
mise en œuvre.

SSADM - Méthode d'analyse et de conception de systèmes structurés

SSADM est l'une des méthodes les plus matures et les plus utilisées. Cependant, elle nécessite un investissement significatif.
investissement dans la formation et l'apprentissage.

Cet exemple plutôt simpliste illustre la nécessité de spécifier les exigences avant la construction.
d'une maison (ou d'un système) est lancé. Bien qu'il puisse sembler que les exigences soient très claires
Les contraintes en amont peuvent être manquées ou les interdépendances négligées pendant le développement. Un
le problème est bien moins cher à résoudre tôt dans le processus que de le laisser jusqu'au dernier jour avant
implémentation. L'analyste système joue un rôle similaire à celui de l'architecte–un
communicateur entre le client et le constructeur. Certains des principes sous-jacents des systèmes
l'analyse, qui est également un principe de SSADM, aide à s'assurer que les exigences des utilisateurs sont entièrement
spécifié.

74
 Implication des utilisateurs – C'est un principe de base de SSADM que les utilisateurs soient impliqués dans et
engagement envers le développement de leur système dès un très jeune âge. En veillant à ce que le
la spécification et la conception correspondent aux exigences des utilisateurs à chaque étape de l'analyse et de la conception
les risques de produire le « mauvais » système sont considérablement réduits et les problèmes possibles peuvent être
résolus avant de devenir ingérables.
Assurance qualité - Dans SSADM, des revues formelles d'assurance qualité sont organisées à la fin de chaque étape.
où l'utilisateur est invité à "valider" le design jusqu'à présent. Les produits finaux pour cette étape sont
examiné pour sa qualité, son intégralité, sa cohérence et son applicabilité par les utilisateurs, les développeurs et
par du personnel système expérimenté externe au projet.
Séparation entre spécifications logiques et physiques - SSADM sépare la conception logique de
conception physique. Une conception logique indépendante du matériel/de logiciel est produite, ce qui peut facilement être
traduit en un design physique initial. Cela aide les développeurs à résoudre un problème à un
le temps et prévient des contraintes inutiles à un stade trop précoce du développement. Cela aide également
communication avec les utilisateurs qui ne sont peut-être pas à l'aise avec l'informatique mais qui sont parfaitement capables de valider

une spécification logique ou un design de leurs systèmes.

Pourquoi utiliser une méthode structurée ?

La méthode structurée partage les caractéristiques suivantes

Ils structurent un projet en petites activités bien définies et spécifient la séquence et l'interaction.
de ces activités.
Ils utilisent des techniques de modélisation diagrammatique et autres pour donner une précision plus exacte (structurée)
définition compréhensible à la fois par les utilisateurs et les développeurs.

Avantages des méthodes structurées - à l'opposé d'un analyste système utilisant simplement son expérience pour
posez toutes les bonnes questions !
L'analyse structurée fournit une déclaration de besoins claire que tout le monde peut comprendre.
est une base solide pour la conception et la mise en œuvre ultérieures. Une partie du problème avec un
analyste de systèmes ― juste poser les bonnes questions‖ est-ce que c'est souvent difficile pour une personne technique
décrire les concepts du système à l'utilisateur en des termes que l'utilisateur peut comprendre. Structuré
Les méthodes incluent généralement l'utilisation de techniques diagrammatiques non techniques facilement compréhensibles.
il est important que ces diagrammes ne contiennent pas de jargon informatique et de détails techniques que l'utilisateur
ne comprendra pas – et n'a pas besoin de comprendre.
Utilisation plus efficace du personnel expérimenté et inexpérimenté. Une méthode structurée ne
supprimer le besoin de personnel expérimenté mais cela offre la possibilité de répartir l'expérience
plus finement. L'utilisation de techniques structurées signifie que certaines tâches peuvent être déléguées à
du personnel inexpérimenté qui peut ensuite être guidé par les plus expérimentés.
Amélioration de la planification et du contrôle des projets. L'utilisation d'une approche structurée permet de
gestion efficace des projets. Diviser un projet en étapes et en sous-étapes permet une meilleure
estimation du temps nécessaire pour compléter un projet. De plus, en suivant un plan détaillé, cela sera
possible de détecter le glissement au fur et à mesure qu'il se produit et pas seulement avant que le système ne soit prêt à être mis en œuvre.

Meilleurs systèmes de qualité. En rendant les spécifications très complètes, il est possible de garantir
que le système construit sera de haute qualité. L'utilisation de techniques structurelles a été trouvée pour
mène à un système qui est très flexible et propice au changement. Dans SSADM, l'utilisateur participe à
révisions formelles d'assurance qualité et visites informelles et « validation » de chaque étape avant le

75
 les développeurs progressent au suivant. Cela signifie que les analystes peuvent être confiants que le nouveau
le système répondra aux exigences des utilisateurs avant qu'il ne soit construit.

Pourquoi choisir SSADM ?

L'un des principaux avantages est que SSADM élabore plusieurs vues différentes du système que
sont utilisés pour se vérifier mutuellement. Dans l'exemple de bâtiment plus tôt pour aider le client
visualiser le bâtiment final que l'architecte a dessiné plusieurs représentations différentes - une coupe transversale
vue, impression d'artistes, etc. Cela a probablement aidé l'architecte à valider les plans qu'il a réalisés.
s'assure que chaque vue était cohérente avec les autres. Dans SSADM, il y a trois vues différentes du système
sont développées dans l'analyse. Ces points de vue sont étroitement liés les uns aux autres et sont vérifiés croisée.
de manière extensive pour la cohérence et l'exhaustivité. Le poids égal accordé à ces trois techniques
et les procédures prescrites pour les vérifier les unes par rapport aux autres sont une grande force de la
Approche SSADM. Les trois vues sont,
Structure sous-jacente des données des systèmes (Structure de données logique)
Comment les données circulent à l'intérieur et à l'extérieur du système et sont transformées au sein du système (flux de données
diagrammes)
Comment les données du système sont modifiées par les événements au fil du temps (histoires de vie des entités).

Un autre avantage de la SSADM par rapport à un certain nombre de méthodes est qu'elle combine des techniques en un
cadre bien établi et tout en fournissant les techniques pour l'analyste, il donne
des conseils sur comment et quand les utiliser. Même si SSADM adopte cette approche plutôt préscriptive
l'approche il reste encore une grande flexibilité dans la méthode et elle devrait être adaptée à
circonstances spécifiques du projet.

Principes de base de SSADM

SSADM est un modèle basé sur les données - cela signifie qu'il y a une hypothèse de base selon laquelle les systèmes ont.
une structure de données sous-jacente et générique qui change très peu au fil du temps, bien que le traitement
les exigences peuvent changer. Dans SSADM, cette structure de données sous-jacente est modélisée à partir d'un
étape précoce. La représentation de cette structure de données est vérifiée par rapport au traitement et
exigences de reporting et finalement intégrées dans l'architecture des systèmes.

Les techniques structurées de SSADM s'inscrivent dans un cadre d'étapes et de phases, chacune avec des définitions claires.
informations et résultats. Il y a également un certain nombre de formulaires et de documents qui sont spécifiés et qui ajoutent
informations contenues dans les diagrammes. Ainsi, SSADM se compose de trois caractéristiques importantes

Structures - définir des cadres d'étapes et des phases ainsi que leurs entrées et sorties.
Techniques – définissent comment les étapes et les tâches sont effectuées.
La documentation définit comment les produits des étapes sont présentés.
Chaque module est conçu pour être autonome avec l'idée que les projets pourraient choisir de l'utiliser.
SSADM pour un module et pas pour les autres. SSADM est divisé en 5 modules et chacun de ces
sont divisés en étapes. Chaque étape est divisée en actions.

76
 Analyse des exigences
Étape 1 – Enquête sur l'environnement actuel.

Le système actuel est examiné pour plusieurs raisons

Les analystes apprennent la terminologie et le fonctionnement de l'environnement des utilisateurs

L'ancien système peut former la base du nouveau système
Les données requises par le système peuvent être examinées
Il offre aux utilisateurs une bonne introduction aux techniques
Les limites de l'enquête peuvent être clairement définies.

La vue actuelle du système créée lors de la phase 1 est redessinée pour extraire ce que le système fait sans aucun
indication de la manière dont cela est réalisé. L'image résultante est la vue logique du système actuel.
Cela permet à l'analyste de se concentrer sur les fonctions qui sont exécutées dans le système actuel et
prendre des décisions sur ce qui doit être inclus dans le nouveau système.

Étape 2 - Options de système d'affaires

Ils reflètent différentes manières (options) dont le système pourrait être organisé pour répondre aux
des exigences. Une décision est prise par les utilisateurs quant à l'option ou la combinaison d'options qui convient le mieux
répond à leurs besoins.

Spécification des exigences

Étape 3 – Définition des exigences

En fonction de l'option des systèmes d'affaires sélectionnée, une spécification détaillée du système requis
est construit et vérifié de manière extensive. Afin que le nouveau système ne soit pas contraint par le
dans l'implémentation actuelle, il y a un certain nombre d'étapes dans cette phase pour guider les analystes progressivement
loin du système actuel vers une nouvelle vision des exigences.

Cette étape élabore la conception des données afin que toutes les données requises soient incluses. Elle applique un
technique d'analyse relationnelle pour des groupes d'éléments de données dans le système pour servir de vérification croisée sur le
définitions des données.

Spécifications des systèmes logiques

Les deux étapes de ce module sont souvent effectuées simultanément

Étape 4 – Sélection des options techniques

À ce stade, l'équipe de développement dispose de suffisamment d'informations pour compiler les différents
options de mise en œuvre pour le système. Chaque option est coûtée et les avantages sont évalués
contre les coûts pour donner à l'utilisateur une aide dans le choix de la solution finale. Cela pourrait former le
base pour sélectionner le matériel système final.

Étape 5 – Conception logique

77
 La spécification développée à l'étape 3 est approfondie à un niveau de détail très élevé afin que le
Le constructeur peut recevoir tous les détails nécessaires pour construire le système.

Conception physique

Étape 6 - Conception physique

La conception logique complète – à la fois des données et du traitement – est convertie en une conception qui fonctionnera
sur l'environnement cible. La conception physique initiale est ajustée avant la mise en œuvre afin que
répondra aux exigences du système.

Décomposition fonctionnelle

Méthodologies de développement de systèmes.

Une méthodologie de développement de système fait référence au cadre utilisé pour structurer, planifier et
contrôler le processus de développement d'un système d'information. Une grande variété de tels cadres ont
évolué au fil des ans, chacun avec ses propres forces et faiblesses reconnues. Un système
La méthodologie de développement n'est pas nécessairement adaptée à tous les projets. Chacun des disponibles
les méthodologies sont mieux adaptées à des types spécifiques de projets, en fonction de divers aspects techniques,
considérations organisationnelles, de projet et d'équipe.
Critères pour choisir des méthodologies de développement de systèmes

SUJET 8 : MISE EN ŒUVRE DU SYSTÈME

THÉORIE

[Link].T0 Objectifs spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) expliquer la signification et l'importance de la mise en œuvre du système

b) expliquer les procédures de mise en œuvre du système

c) décrire les techniques de mise en œuvre du système

d) décrire les techniques de test système

e) expliquer les niveaux de test d'acceptation

f) expliquer la nécessité de la formation des utilisateurs

g) expliquer les méthodes de formation des utilisateurs

h) décrire les types d'utilisateurs à former

CONTENU

78
 Signification et importance de la mise en œuvre du système

La mise en œuvre des systèmes est la construction du nouveau système et la livraison de ce système dans
production (c'est-à-dire, l'activité quotidienne ou l'exploitation de l'organisation).

La phase de construction de la mise en œuvre des systèmes

La phase de construction fait deux choses :

construit et teste un système fonctionnel qui satisfait aux exigences de conception d'entreprise ou d'organisation,
et
implémente l'interface entre le nouveau système et le système de production existant.

L'équipe du projet doit construire la base de données, les programmes d'application, les interfaces utilisateur et système,
et réseaux. Certains de ces éléments peuvent déjà exister dans votre projet ou être soumis à
amélioration.

Procédure de mise en œuvre du système

Techniques de mise en œuvre des systèmes

La mise en œuvre du nouveau système se produit lorsque l'ancien système est remplacé par le nouveau.
Il existe principalement quatre types de techniques d'implémentation appliquées dans les systèmes

1 Changement direct
L'ancien système est complètement arrêté, et le nouveau système est démarré. Toutes les données qui étaient utilisées
être saisi dans l'ancien système, maintenant passe dans le nouveau.

Avantages...

Prend le minimum de temps et d'effort

Le nouveau système est opérationnel immédiatement

Inconvénients...

79
Si le nouveau système échoue, il n'y a pas de système de secours, donc des données peuvent être perdues.

Parfois, un changement direct est le seul moyen d'implémenter un nouveau système.

Par exemple, le système de pilote automatique d'un avion ne peut pas avoir une nouvelle et une ancienne version fonctionnant côte à côte,

discuter de ce qu'il faut faire !

2 Fonctionnement Parallèle

Le nouveau système est lancé, mais l'ancien système continue de fonctionner en parallèle (côte à côte) pour un
Pendant ce temps. Toutes les données saisies dans l'ancien système sont également saisies dans le nouveau. Finalement,
l'ancien système sera arrêté, mais seulement lorsque le nouveau système aura prouvé qu'il fonctionne.

Avantages...

Si quelque chose ne va pas avec le nouveau système, l'ancien système agira comme une sauvegarde.
Les résultats des anciens et nouveaux systèmes peuvent être comparés pour vérifier que le nouveau système est
fonctionne correctement

Inconvénients...

Saisir des données dans deux systèmes et faire fonctionner deux systèmes ensemble prend beaucoup de temps supplémentaire.
effort

Mise en œuvre en 3 phases

Le nouveau système est introduit par étapes, remplaçant progressivement des parties de l'ancien.
système jusqu'à ce que finalement, le nouveau système ait pris le contrôle.

80
 Avantages...

Permet aux utilisateurs de s'habituer progressivement au nouveau système.

La formation du personnel peut se faire par étapes

Inconvénients...

Si une partie du nouveau système échoue, il n'y a pas de système de sauvegarde, donc les données peuvent être perdues.

Course de pilotage

Le nouveau système est d'abord testé dans une partie de l'entreprise / organisation (par exemple dans)
juste un bureau, ou dans juste un département). Une fois le système pilote fonctionnant avec succès, le nouveau
le système est introduit à toutes les affaires / organisations.

Avantages...

Toutes les fonctionnalités du nouveau système peuvent être entièrement testées

Si quelque chose ne va pas avec le nouveau système, seule une petite partie de l'organisation est affectée.
Le personnel qui faisait partie du projet pilote peut aider à former d'autres employés.

Inconvénients...
Pour le bureau / département réalisant le projet pilote, il n'y a pas de système de secours si quelque chose tourne mal.

Tests système et techniques

81
Les tests système sont le type de test qui vérifie le comportement d'un système complet et entièrement intégré.
produit logiciel basé sur le document de spécification des exigences logicielles (SRS). Le principal
L'objectif de ce test est d'évaluer les exigences commerciales / fonctionnelles / utilisateur final.

C'est un type de test en boîte noire où le fonctionnement externe du logiciel est évalué avec l'aide
des documents d'exigences & c'est totalement basé sur le point de vue des utilisateurs. Pour ce type de test, faites
aucune connaissance requise de la conception interne, de la structure ou du code.

Dans les tests d'intégration, les testeurs se concentrent sur la recherche de bogues/défauts dans les modules intégrés.
Mais dans le test de systèmes logiciels, les testeurs se concentrent sur la recherche de bogues/défauts basés sur
comportement de l'application logicielle, conception logicielle et attentes de l'utilisateur final.

Pourquoi le test système est-il important :

a) Dans le cycle de vie du développement logiciel, les tests système sont effectués comme le premier niveau de
test où le système est testé dans son ensemble.

b) Dans cette étape de test, vérifiez si le système répond ou non aux exigences fonctionnelles.

c) Les tests système vous permettent de tester, valider et vérifier à la fois l'architecture de l'application et
Exigences commerciales.

d) L'application/le système est testé dans un environnement qui ressemble particulièrement à l'effectif
environnement de production où l'application/logiciel sera finalement déployé.

En général, une équipe distincte et dédiée est responsable des tests système. Et, le test système
est effectué sur un serveur de staging qui est similaire au serveur de production. Cela signifie donc que vous testez
application logicielle aussi bonne que l'environnement de production.

Différents niveaux hiérarchiques de test :

Comme presque tout processus technique, le test logiciel a un ordre prescrit dans lequel les choses
doit être fait. Différents niveaux de test sont utilisés dans le processus de test ; chaque niveau de test
vise à tester différents aspects du système. Ce qui suit est une liste des catégories de tests logiciels
organisé de manière séquentielle.

Niveaux hiérarchiques de test

Les tests unitaires - Les tests sont effectués dans le processus de développement pendant que le développeur termine l'unité

développement. L'objectif de ce test est de vérifier la conformité du module. Le but de

les tests unitaires consistent à vérifier que les différentes parties fonctionnent comme prévu. Essentiellement, les tests unitaires
est généralement effectué par le développeur.

82
Les tests d'intégration - Les tests d'intégration système commencent après les modules logiciels individuels.
sont intégrés en tant que groupe. Un projet logiciel typique est composé de plusieurs modules et ceux-ci sont
développé par différents développeurs. Ainsi, dans les tests d'intégration, l'accent est mis sur la vérification que après
L'intégration des modules signifie que deux modules communiquent entre eux ou non. Il est crucial de tester.
l'effet de chaque module sur l'ensemble du modèle de programme. La plupart des problèmes sont observés dans ce type de
test

Tests système - C'est la première fois que l'on teste de bout en bout l'application sur l'ensemble et pleinement
produit logiciel intégré avant son lancement sur le marché.

Test d'acceptation – L'acceptation par l'utilisateur est un type de test effectué par le client pour certifier le
système en ce qui concerne les exigences qui ont été convenues. Il s'agit de tests bêta du produit
& évalué par les utilisateurs finaux réels. Le but principal de ce test est de valider l'expérience de bout en bout
flux d'affaires

Tests d'acceptation
Qu'est-ce que le test d'acceptation utilisateur ?

Les tests d'acceptation utilisateur sont le processus de test logiciel où le système est testé
pour l'acceptabilité. Ce type de test est réalisé par le client dans un environnement séparé (similaire à
environnement de production) et confirmer si le système répond aux exigences selon
spécification des exigences ou non.

UAT est effectué après que les tests système soient terminés et que tous ou la plupart des défauts majeurs aient été corrigés.

corrigé. Ce test doit être réalisé à la dernière étape du cycle de vie du développement logiciel.
(SDLC) avant que le système ne soit livré dans un environnement en direct

Les tests d'acceptation sont des tests « boîte noire », ce qui signifie que les utilisateurs UAT ne sont pas au courant de l'interne.

structure du code, ils se contentent de spécifier l'entrée du système et vérifient si le système répond
avec le bon résultat.

Niveaux de test – Test d'acceptation utilisateur

Le test d'acceptation par l'utilisateur, également connu sous le nom de test d'acceptation par le client (CAT)

Le CAT ou UAT sont la confirmation finale du client avant que le système soit prêt pour
production. Les clients commerciaux sont les principaux propriétaires de ces tests UAT. C'est un
collaboration entre les clients commerciaux, les analystes commerciaux, les testeurs et les développeurs. Cela consiste en
suites de tests qui impliquent plusieurs cas de test et chaque cas de test contient des données d'entrée (si nécessaire) comme
Ainsi que le résultat attendu. Le résultat du cas de test est soit un succès, soit un échec.

Prérequis pour les tests d'acceptation par les utilisateurs :

Avant de commencer l'UAT, les points de contrôle suivants doivent être pris en considération :

83
Les exigences commerciales devraient être disponibles.
Le développement de l'application logicielle doit être terminé et différents niveaux de tests comme
Les tests unitaires, les tests d'intégration et les tests système sont terminés.
Tous les défauts de haute gravité et de haute priorité doivent être vérifiés. Aucun défaut bloquant dans le
système.
Vérifiez si tous les défauts signalés doivent être vérifiés avant le début des tests d'acceptation utilisateur.
Vérifiez si la matrice de traçabilité pour tous les tests doit être complétée.
Avant le début des tests utilisateur, des erreurs mineures comme des erreurs cosmétiques sont acceptables mais doivent être signalées.
Après avoir corrigé tous les défauts, des tests de régression doivent être effectués pour vérifier que le défaut est réparé.
casser l'autre zone de travail.
L'environnement UAT séparé, similaire à la production, devrait être prêt à commencer l'UAT.
La validation doit être donnée par l'équipe de tests système qui indique que l'application logicielle est prête.
pour l'exécution des UAT.

TYPES D'ACCEPTATION DES TESTS

A] Test Alpha

Les tests alpha sont réalisés par le client sur le site du développeur, ils sont effectués par des utilisateurs potentiels.
comme les développeurs, les utilisateurs finaux ou les utilisateurs d'organisation avant qu'il ne soit mis à disposition des clients externes et de faire un rapport

le défauts trouvé tandis que Alpha test

Ce test de produit logiciel n'est pas la version finale de l'application logicielle, après avoir corrigé tous les problèmes signalés.
bug (après le triage des bugs) la nouvelle version de l'application logiciel sera publiée. Parfois, l'Alpha
Les tests sont effectués par le client ou un externe en présence du développeur et du testeur.
La version de la publication sur laquelle les tests Alpha sont effectués est appelée « Version Alpha ».

B] Test de version bêta

La plupart du temps, nous avons le terme d'ouïe « version/lancement Beta », donc il est lié à Beta.
Test

Fondamentalement, le test bêta doit être réalisé sans aucune aide des développeurs sur le site de l'utilisateur final.
par les utilisateurs finaux &, il est donc effectué dans un environnement non contrôlé. Les tests bêta sont également connus
comme test sur le terrain. Cela est utilisé pour obtenir des retours du marché.

Ce test est réalisé par un nombre limité d'utilisateurs et tous les problèmes rencontrés lors de ce test sont signalés sur
sur une base continue ce qui aide à améliorer le système. Les développeurs agissent sur tous les problèmes
rapporté lors des tests bêta après le triage des bugs et ensuite l'application logicielle est prête pour la version finale
version. La version publiée après les tests bêta est appelée « Version Bêta ».
C'est la dernière étape des tests où le produit est envoyé en dehors de l'entreprise ou pour une offre d'essai à
télécharger.

Que tester lors des tests d'acceptation utilisateur ?

Sur la base des cas d'utilisation de la phase de définition des exigences, les cas de test sont créés.

84
Les cas de test sont également créés en tenant compte des scénarios du monde réel pour l'application.
Les tests réels doivent être réalisés dans des environnements qui reproduisent l'environnement de production.
Ainsi, le type de test se concentre sur l'utilisation réelle exacte de l'application.
Les cas de test sont conçus de manière à ce que tous les domaines d'application soient couverts pendant les tests afin de garantir qu'un
tests d'acceptation utilisateur efficaces.

Quels sont les livrables clés des tests d'acceptation utilisateur ?

L'achèvement des tests d'acceptation utilisateur est une étape importante des tests traditionnels.
méthode. Le livrable clé suivant de la phase de test d'acceptation utilisateur :

Plan de Test : Cela décrit la Stratégie de Test

Cas de test UAT : Les cas de test aident l'équipe à tester efficacement l'application en UAT
environnement.
Résultats des tests et rapports d'erreurs : Ceci est un journal de tous les cas de test exécutés et le réel
résultats.
Validation de l'acceptation par l'utilisateur : Ceci est le système, la documentation et les supports de formation ont été approuvés.
tous les tests dans des marges acceptables.
Instructions d'installation : Ceci est un document qui aide à installer le système en production.
environnement.
Matériaux de documentation : Documentation utilisateur et matériels de formation testés et mis à jour sont
finalisé lors des tests d'acceptation utilisateur

Besoin de formation des utilisateurs

Vous avez donc pris la décision, sélectionné votre logiciel, l'implémentation est en cours et vous êtes
bientôt en ligne. Tellement à organiser et pourtant souvent le processus crucial d'incorporation d'un
la stratégie axée sur l'utilisateur final est oubliée – sans doute la plus importante. À moins que votre personnel ne soit formé sur
Avec votre nouveau logiciel, vous ne pouvez pas vous attendre à en récolter tous les avantages de l'investissement.

En plus de cela, il y a souvent le défi de la résistance des employés au changement. En expliquant le

raisons derrière un nouveau système pour créer une compréhension, décrivant les avantages et fournissant
formation, vous serez sur la voie d'une équipe adoptant ces changements.

La clé de la planification de la stratégie utilisateur final est de passer en revue les aspects pratiques–Combien de personnes ont besoin
pour utiliser et comprendre le nouveau système ? À quelle vitesse souhaitez-vous le déploiement à tout le personnel ?

Une fois que vous avez une idée de ce qui précède, vous pouvez décider de la méthode de formation la plus appropriée.
Vous pouvez choisir une formation informatique pratique avec un instructeur, de manière séminaire avec un présentateur,
formation manuelle ou peut-être même apprentissage virtuel. vous devrez également envisager de mener
la formation individuellement ou en séances de groupe axées.

Le choix de la meilleure méthode de livraison dépendra de plusieurs facteurs :

85
Le nombre de personnel en formation et le calendrier de livraison – cela déterminera si vous
s'entraîner en groupe ou individuellement
Comment votre personnel est-il réparti géographiquement - trouver le meilleur endroit pour réaliser la formation et
considérer l'apprentissage virtuel
Les processus impliqués dans le nouveau logiciel que le personnel doit comprendre, par exemple peut-être pratique
la formation par le biais de l'activité accélérera le processus d'apprentissage par rapport à une présentation sur
comment utiliser.
Quelles ressources sont nécessaires pour la formation - Téléchargement de logiciels ou utilisation d'internet, manuel
production?
Le niveau d'interactivité requis par exemple – le jeu de rôle sera-t-il nécessaire, une activité de groupe augmenterait-elle ?
comprendre et augmenter les niveaux de motivation ?
Qui est le mieux placé pour faciliter et dispenser la formation - la société de logiciels recommande-t-elle ou fournit-elle ?
formation pour le personnel ou aurez-vous besoin d'un animateur externe/interne ?

Créer le bon environnement d'entraînement est une autre considération. Un aspect de cela est le lien
l'écart entre les compétences du personnel, tous les employés n'ont pas besoin du même niveau de formation, cela pourrait être
apprentissage plus efficace et en termes de temps pour dispenser une formation par niveaux de compétences à des groupes distincts.

Suite à cela, l'environnement d'apprentissage physique choisi aura un impact sur l'apprentissage. Le personnel doit être
confortable, détendu, avoir les outils nécessaires et aucune distraction pour écouter, interpréter et
s'engager activement dans les informations qui leur sont transmises. Si souvent, les problèmes informatiques et techniques peuvent
entraver l'apprentissage ; la bonne gestion de la formation est essentielle pour ceux qui la reçoivent et élimine
frustration de ceux qui livrent. En faisant bien les choses, vous économiserez du temps et de l'argent en dépenses inutiles.
erreurs commises. Pour maintenir les avantages de votre nouveau système, il est tout aussi important d'éduquer
nouveaux arrivants, envisager éventuellement de l'incorporer dans les plans d'induction et pour ceux qui sont entièrement formés,
Des mises à jour et une formation de remise à niveau devraient être planifiées.

Méthodes de formation des utilisateurs

Types d'utilisateurs à former

86
SUJET 9 : MAINTENANCE ET REVUE DU SYSTÈME

THÉORIE

[Link].T0 Objectifs spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) expliquer la signification de la maintenance et de la révision du système

b) expliquer l'importance de la maintenance des systèmes

c) décrire les types de maintenance système

CONTENU
Signification et importance de la maintenance et de la révision des systèmes

Importance de la maintenance système

Types de maintenance système

SUJET 10 : DOCUMENTATION SYSTÈME

THÉORIE

[Link].T0 Objectifs Spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) expliquer la signification de la documentation des systèmes

b) expliquer la nécessité de la documentation système

c) décrire les types de documentation système

CONTENU
Signification de la documentation système

Dans le développement de produits matériels et logiciels, la documentation fait référence à :

informations qui décrivent le produit à ses utilisateurs. Cela consiste en la technique du produit.
manuels. Le terme est parfois utilisé pour désigner les informations sources sur le produit
contenu dans les documents de conception, les commentaires de code détaillés, etc.

Le terme est dérivé de l'idée que les ingénieurs et les programmeurs "documentent" leurs produits dans
Les premiers utilisateurs d'ordinateurs recevaient parfois simplement les documents des ingénieurs ou
la "documentation" des programmeurs. Au fur et à mesure que le public du produit s'est agrandi, il est devenu nécessaire d'ajouter

87
 des rédacteurs techniques et des éditeurs professionnels au processus. Dans cette vision axée sur les tâches, le produit
l'information peut être divisée en et parfois organisée physiquement en ces catégories de tâches :
évaluer, planifier, mettre en place ou installer, personnaliser, administrer, utiliser, et
maintenir le produit. La documentation est désormais souvent intégrée directement dans le produit dans le cadre de
interface utilisateur et dans les pages d'aide.

Cahier des charges fonctionnel

Définition

Une spécification fonctionnelle est un document formel utilisé pour décrire en détail aux développeurs de logiciels
les capacités prévues d'un produit, son apparence et ses interactions avec les utilisateurs.

La spécification fonctionnelle est une sorte de directive et de point de référence continu alors que
les développeurs écrivent le code de programmation. Typiquement, la spécification fonctionnelle d'une application
programmer avec une série de fenêtres interactives et de boîtes de dialogue avec un utilisateur afficherait le visuel
apparence de l'interface utilisateur et décrire chacune des actions possibles d'entrée de l'utilisateur et le
programmer des actions de réponse. Une spécification fonctionnelle peut également contenir des descriptions formelles de l'utilisateur.
tâches, dépendances avec d'autres produits, et critères d'utilisabilité.

Pour avoir une idée de l'endroit où la spécification fonctionnelle s'inscrit dans le processus de développement, voici un
série typique d'étapes dans le développement d'un produit logiciel :

Exigences. Il s'agit d'une déclaration formelle de ce que les planificateurs de produits ont informé par leurs
la connaissance du marché et les contributions spécifiques des clients existants ou potentiels sont considérées comme
nécessaires pour un nouveau produit ou une nouvelle version d'un produit existant. Les exigences sont généralement
exprimé en termes de déclarations narratives et de manière relativement générale.
Objectifs. Les objectifs sont rédigés par les concepteurs de produits en réponse aux exigences. Ils
décrire de manière plus spécifique à quoi ressemblera le produit. Les objectifs peuvent décrire
architectures, protocoles et normes auxquels le produit se conformera. Objectifs mesurables
sont ceux qui établissent certains critères selon lesquels le produit final peut être jugé. Les objectifs doivent
reconnaître les contraintes de temps et de ressources.
Spécification fonctionnelle. La spécification fonctionnelle (généralement spécification fonctionnelle ou simplement spécification ou juste spécification)
court) est la réponse formelle aux objectifs. Il décrit tous les utilisateurs externes et la programmation.
interfaces que le produit doit prendre en charge.
Demandes de changement de conception. Tout au long du processus de développement, alors que le besoin de changement se présente.
la spécification fonctionnelle est reconnue, un changement formel est décrit dans une demande de changement de conception.
Spécification logique. La spécification logique décrit les interfaces internes et est destinée à être utilisée uniquement par
les développeurs, les testeurs et, par la suite, dans une certaine mesure, les programmeurs qui assurent le service du produit et
fournir des corrections de code au domaine.
Documentation utilisateur. En général, tous les documents précédents (sauf la spécification logique)
sont utilisés comme matériel source pour les manuels techniques et les informations en ligne (comme les pages d'aide)
qui sont préparés pour les utilisateurs du produit.

88
Plan de test. La plupart des groupes de développement ont un plan de test formel qui décrit les cas de test qui seront
exécuter le programme qui est écrit. Les tests sont effectués au niveau du module (ou unitaire), à
niveau des composants, et au niveau du système dans le contexte d'autres produits. Cela peut être considéré comme
test alpha. Le plan peut également prévoir un test bêta. Certaines entreprises fournissent une version préliminaire de
le produit à un groupe sélectionné de clients pour des tests dans une situation 'réelle'.
Le produit final. Idéalement, le produit final est une mise en œuvre complète de la fonctionnelle.
demandes de changement de spécification et de conception, dont certaines peuvent résulter de tests formels et de versions bêta
test.

Le cycle est ensuite répété pour la prochaine version du produit, en commençant par de nouvelles exigences.
déclaration, qui utilise idéalement les retours des clients sur le produit actuel pour déterminer
ce que les clients ont besoin ou veulent ensuite.

La plupart des développeurs de logiciels adhèrent à un processus de développement formel similaire à celui décrit ci-dessus.

Besoin de documentation système

Il est utile de fournir une description claire du travail effectué jusqu'à présent. Il est essentiel que les documents
préparé doit être mis à jour régulièrement cela aidera à suivre facilement l'avancement du travail. Avec
une documentation appropriée et de bonne qualité, il est très facile de comprendre les aspects de fonctionnement du système
travaillera pour l'entreprise où le système doit être installé. Cela aide également à comprendre le type de
données qui seront saisies dans le système et comment la sortie peut être produite.

Après l'installation du système, et si le système ne fonctionne pas correctement, il sera très facile
pour que l'administrateur comprenne le flux de données dans le système avec une documentation qui permettra
aidez-le/la à corriger les défauts et à faire fonctionner le système en un rien de temps.

Usages de la documentation

Il facilite la communication efficace concernant le système entre les techniques et les non.
utilisateurs techniques.
C'est très utile pour former de nouveaux utilisateurs. Avec une bonne documentation, les nouveaux utilisateurs peuvent facilement s'y retrouver.
familiers avec le fonctionnement des systèmes.
La documentation aide également les utilisateurs à résoudre des problèmes comme le dépannage, même pour ceux qui ne sont pas techniques.
l'utilisateur peut résoudre les problèmes.

Il joue un rôle significatif dans le processus d'évaluation.

Cela aide non seulement à exercer un meilleur contrôle sur le fonctionnement interne de l'entreprise, mais cela aide également
externe aussi surtout pendant l'audit.
Les documentations peuvent aider le manager à prendre de meilleures décisions financières pour l'organisation.

La valeur de la documentation

La documentation est précieuse en tant que matériel de référence et de normalisation et parce qu'elle crée de la valeur.
pour les organisations et les produits :

89
Une bonne documentation a tendance à réduire le volume des demandes de support et des bogues/problèmes erronés.
rapport. De plus, une bonne documentation complète facilite la réponse aux questions restantes
les demandes de support plus faciles.

Une bonne documentation sort les connaissances de la tête des gens et les met dans un format partagé.
augmente la fiabilité, car elle réduit la dépendance aux mémoires et aux notes des gens, qui peuvent
pas toujours accessible, ou peut être incohérent.
En l'absence d'une spécification, la documentation peut aider à définir et à réguler l'expérience utilisateur comme
le développement progresse.
Sans documentation, les utilisateurs peuvent ne pas être conscients des fonctionnalités et des comportements, ce qui réduit leur
valeur. Si les utilisateurs n'apprennent jamais à connaître ou à tirer parti des nouvelles fonctionnalités et des nouvelles options, alors
Les ressources de développement sont essentiellement gaspillées.

Cela ne signifie pas que vous devez rédiger de la documentation dans des situations où organiser un système ou
l'environnement est plus pratique et efficace, ou que la standardisation d'un processus avec un script ou
le programme n’a pas sa place. Cependant, pour des problèmes complexes où les utilisateurs interagissent avec votre
les interfaces ou les processus, la documentation est souvent la réponse. Prenez fierté dans la documentation, traitez-la
sérieusement, et le retour sera formidable.

Types de documentation système

Sommerville décrit deux catégories principales de documentations logicielles : le processus et le produit

documents.

Processus :
Les documentations sont utilisées pour gérer le processus de développement, par exemple la planification, la programmation.
et le suivi des coûts, les normes entre autres.

Documentation des produits :

Décrivez le principal livrable (produit logiciel) et certains des documents dans cette catégorie
fait partie des livrables. Cela inclut ;
Spécification des exigences
Documents de conception,
Code source commenté
Plans de test comprenant des cas de test,
Plan et résultats de validation et de vérification

Application et avantages de la documentation

Le rôle de la documentation dans un environnement de génie logiciel est de communiquer
informer son public et inculquer des connaissances sur le système qu'il décrit.
La documentation système joue un autre rôle, à savoir la maintenance des logiciels, et
Identification de plusieurs avantages de la documentation. Ceux-ci incluent :
réutilisation plus facile des anciens designs
meilleure communication sur les exigences,
des revues de design plus utiles,

90
intégration plus facile de modules écrits séparément,
inspection de code plus efficace,
des tests plus efficaces, et
corrections et améliorations plus efficaces.
Les chercheurs et les praticiens ont également examiné les utilisations de la documentation logiciel et juste pour
compile quelques notes indiquant que la documentation aide au développement logiciel, maintient le logiciel-
qualité à des niveaux élevés et facilite le transfert de projets.
La documentation peut également être utilisée pour :

apprendre un système logiciel,

tester un système logiciel,
travailler avec un nouveau système logiciel
résoudre des problèmes lorsque d'autres développeurs ne sont pas disponibles pour répondre aux questions,
à la recherche d'informations générales sur un système logiciel
maintenir un système logiciel
répondre aux questions sur un système de gestion ou des clients,
à la recherche d'informations approfondies sur un système logiciel, et
facilite une communication efficace concernant le système entre les techniciens et les non-techniques
utilisateurs techniques,

formation de nouveaux utilisateurs,

résoudre des problèmes comme le dépannage, le processus d'évaluation et quantifier le financier
ramifications/empreinte du système.

91
SUJET 11 : ACQUISITION DE SYSTÈMES

THÉORIE

[Link].T0 Objectifs Spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) décrire les méthodes d'acquisition des systèmes d'information

b) expliquer les critères pour choisir une méthode d'acquisition d'un système d'information

CONTENU

Méthodes d'acquisition de systèmes d'information

Critères pour l'acquisition de systèmes d'information

Il existe plusieurs méthodes qui peuvent être appliquées pour acquérir des systèmes d'information pour un
organisation.

Facteurs clés dans la sélection des alternatives disponibles

Il existe plusieurs alternatives principales pour acquérir des applications informatiques/systèmes d'information. Certaines options majeures sont d'acheter,

louer, développer en interne ou sous-traiter un système auprès d'autres entreprises. Quand cela a-t-il du sens ?
plus sens d'acheter les applications ? Quand est-ce que cela a plus de sens de louer ? Devons-nous
externaliser nos applications à d'autres entreprises ? L'ensemble des processus pour la décision d'acquisition
doit être identique pour chaque instance ou opportunité d'affaires qui se présente. Dans le passé, tout ce qui
a été jugé stratégique, a été construit en interne, mais la tendance est à l'externalisation et à l'achat de plus.
les systèmes ont grandi. Voici quelques facteurs critiques qui devraient être évalués avant de choisir
stratégie d'approvisionnement en TI préférée, que ce soit pour acheter, louer, construire en interne ou sous-traiter l'informatique

applications.

1. Acheter les applications (solution prête à l'emploi)

L'achat de solutions disponibles dans le commerce nécessite que l'entreprise s'adapte à

fonctionnalité du système. Acheter un package existant peut être une solution économique et faire gagner du temps
stratégie comparée au développement interne. Le processus d'adaptation des entreprises oblige que le

92
l'organisation pourrait également personnaliser le produit logiciel et ensuite en assurer la maintenance
personnalisations au sein des processus qui ont été modifiés et changés. La plupart des organisations sont
rarement pleinement satisfait par un logiciel. Par conséquent, il est parfois nécessaire d'acquérir
plusieurs paquets pour soutenir même un processus d'affaires. Notez que lors de la sélection d'un fournisseur
dans le cadre d'un paquet, les organisations devraient prendre en compte les facteurs clés suivants :

Stabilité du fournisseur Matériel et logiciel

Mises à jour système exigences
Support client fourni par Personnalisation requise de la base
vendeur logiciel

Une option d'achat doit être soigneusement considérée pour s'assurer que toutes les caractéristiques critiques de la
Les besoins actuels et futurs sont inclus dans le package. Acheter a du sens si un organisme planifie.
garder quelque chose pendant longtemps, mais la technologie devient généralement obsolète tous les deux à trois
années. La raison pour laquelle un client de petite entreprise n'achète jamais d'équipement informatique est
car il y a une courbe d'obsolescence. Quand vous savez que quelque chose va devenir obsolète,
Pourquoi un client de petite entreprise voudrait-il être propriétaire de cet équipement, au lieu d'être simplement un
utilisateur de cet équipement ? Quand l'entreprise est entièrement axée sur la technologie de pointe, acheter peut rendre
bon sens. En fin de compte, une décision d'achat signifie généralement choisir quelque chose d'inexpensive à faire
le travail en ce moment.

Les avantages et les inconvénients de l'option « acheter » sont résumés dans le Tableau 2.

TABLEAU 2. Avantages et inconvénients de l'option « Acheter »

AVANTAGES INCONVÉNIENTS
· Temps de mise en œuvre plus court Incompatibilité avec les besoins de l'entreprise

Utilisation de technologies éprouvées Incompatibilité entre différents

applications
Disponibilité d'une assistance technique extérieure

expertise Limitation sur la personnalisation du logiciel

· Plus facile de définir les coûts N'avoir aucun contrôle sur le logiciel
améliorations
Mises à jour fréquentes du logiciel
Dépendance à long terme au soutien des fournisseurs
Le prix est généralement moins cher
· Matériel ou logiciel spécifique
Personnel informatique minimal exigences

93
2. Location des applications

L'option de location peut entraîner des économies substantielles de coûts et de temps par rapport à l'option d'achat ou à...
développement de maison. La location peut être un bon choix pour les petites et moyennes entreprises qui ne peuvent pas se le permettre
gros investissement dans les applications informatiques. De plus, de nombreuses fonctionnalités communes qui sont nécessaires à la plupart

les organisations sont généralement incluses dans le paquet loué même si cela peut ne pas toujours
inclure exactement toutes les fonctionnalités requises. De plus, en ce qui concerne la pénurie de personnel informatique, de nombreux

les entreprises choisissent de louer plutôt que de développer des logiciels en interne. Louer peut vous aider à réduire
le coût total de possession des actifs technologiques. Il vous permet de suivre, de standardiser et de manière régulière
modernisez la technologie de votre pratique. Par conséquent, la location nécessite un autre type de compétence en gestion,
aussi, qui est : la gestion du cycle de vie. Alors que l'achat signifie généralement prendre quelque chose
peu coûteux pour faire le travail en ce moment, le leasing signifie qu'une entreprise regarde la big picture,
planification des futures mises à niveau et des besoins évolutifs. Lorsque le contrôle de la trésorerie est critique et que vous
n'avoir pas le temps de s'inquiéter de votre équipement, la location peut être une excellente option. D'autres fournisseurs
convenir que les protections intégrées contre l'obsolescence peuvent encourager la location.

Lorsque vous entrez dans un bail, la capacité de progresser d'une génération de technologie à
le suivant, pour développer votre solution technologique, se débarrasser de l'équipement obsolète est beaucoup plus facile
et beaucoup plus fluide, en raison de la façon dont un bail est structuré pour les petites et moyennes entreprises.

Les avantages et les inconvénients de l'option de 'bail' sont résumés dans le tableau 3.

TABLEAU 3. Avantages et inconvénients de l'option 'Location'

AVANTAGES INCONVÉNIENTS
Mise en œuvre plus rapide Peut ne pas correspondre exactement aux besoins de l'entreprise

Économies de coûts (moins cher que l'option d'achat)

Limitation sur la personnalisation du logiciel

Facilité de maintenir le flux de trésorerie N'avoir aucun contrôle sur le logiciel

améliorations
· Nécessite seulement un minimum de personnel informatique

Matériel ou logiciel spécifique

Moins risqué d'anticiper la technologie exigences
updates
· Inclure un composant d'intérêt qu'un
Avoir la plupart des fonctionnalités requises l'achat au comptant n'inclurait pas

3. Développer les applications en interne

Une autre stratégie d'acquisition informatique est de construire l'application en interne. Cette option fonctionne
eh bien pour l'organisation qui a les ressources et le temps de développer les applications informatiques par elle-même.

94
 Cette approche peut prendre du temps et être assez coûteuse, mais l'entreprise peut avoir un système
qui répondent à toutes les exigences objectives de l'organisation. Son avantage principal était la liberté de
créer un système qui s'adapterait étroitement aux processus commerciaux de l'entreprise. Contrairement à d'autres
des solutions, ce serait relativement peu coûteux ; cependant, cela prendrait plus de temps (peut-être
significativement plus) à mettre en œuvre. Si cela réussit, le résultat pourrait mener à une autre source de revenus
des redevances pour les ventes de logiciels.

Il existe deux façons principales de développer le système en interne.

Tout d'abord, construire l'application à partir de zéro est l'une des approches pour répondre aux spécificités.
application avec les exigences.

Une autre façon de créer l'application en interne est d'utiliser les composants ou fonctionnalités standard.
qui ont été inclus dans certains packages commerciaux (c'est-à-dire Java, Visual Basic, C++) ou en utilisant
logiciels packagés disponibles qui peuvent être personnalisés. Cependant, la deuxième approche offre une plus grande
flexibilité, économies de coûts et de temps plutôt que de construire le logiciel à partir de la base.

Les avantages et les limitations de l'option de 'développement interne' sont résumés dans le tableau 4.

TABLEAU 4. Avantages et Inconvénients de l'Option de 'Développement Interne'

AVANTAGES INCONVÉNIENTS
Meilleure adéquation avec l'entreprise Besoin de plus de personnel informatique

exigences
Coût de fonctionnement élevé
Avoir le contrôle sur le logiciel
améliorations Takes du temps

Avoir toutes les fonctionnalités requises Problème d'utilisation du système

· Compétences clés principales et maintien· Coût de commutation élevé

niveau de qualité de service
Difficile de passer à une technologie plus récente
· Faire une distinction avec les autres
entreprises

4. Externalisation des applications

L'un des récents pionniers dans la stratégie d'acquisition des TI/SI est l'externalisation. L'externalisation est un
utilisation stratégique de ressources extérieures pour effectuer des activités traditionnellement gérées par le personnel interne et
ressources. Laudon et Laudon le définissent comme le processus de transformation d'un ordinateur d'organisation
centre, développement de réseaux de télécommunication ou d'applications vers des fournisseurs externes. Cependant, dans
En général, les raisons se résument à un facteur. Il est moins coûteux pour l'entreprise acheteuse de se tourner

95
faire les travaux en interne. Cette stratégie n'a pas besoin de l'expertise et elle est moins
coûteux d'acheter l'expertise que de la construire. Peut-être qu'il n'a pas le temps de mener à bien un projet.
Cependant, il peut tirer parti des économies d'échelle dont dispose le fournisseur et que le
l'entreprise d'achat ne le fait pas. En fait, l'organisation se tourne vers l'externalisation pour économiser
argent. Les décisions concernant ce qu'il faut externaliser et si cela doit être fait doivent être liées à une identification et

compréhension des compétences clés d'une organisation et de ses facteurs de succès critiques. Si une tâche est un
à la fois une compétence clé et un facteur de succès critique, cela ne devrait pas être considéré comme de l'externalisation.
De tels projets sont au cœur de l'entreprise. Le succès ou l'échec de telles fonctions est directement lié
au succès ou à l'échec de l'entreprise dans son ensemble. En général, de telles fonctions sont critiques pour un
les opérations quotidiennes de l'organisation, sa capacité à se différencier de manière compétitive, sa capacité à livrer
valeur pour les clients et les partenaires, et capacité à innover.

Certaines types différents de relations d'externalisation sont le partenariat, le fournisseur de services, et

fournisseur. Des partenariats stratégiques pourraient même établir une forme de propriété mutuelle ou de revenus.
le partage. Une relation de fournisseur de services est établie lorsqu'un ASP gère des applications de MIS et
les contrats sont flexibles pour répondre aux besoins changeants de l'organisation. La plupart des FAI développent
applications logicielles personnalisées pour la ligne d'affaires. En attendant, fournisseur ou transaction
Les partenariats sont des arrangements d'externalisation plus typiques où une entreprise contracte simplement avec un
le fournisseur doit fournir le service ou le produit. Le fournisseur fournit généralement du matériel,
télécommunications, sauvegarde et applications gérées pour l'entreprise. Dans ce terme de
partenariat, les contrats augmentent généralement les frais en fonction des niveaux d'utilisation des services de ligne.

L'externalisation peut être utilisée pour exploiter la base de coûts inférieure des prestataires de services externes.
ce qui permet de réduire les coûts d'exploitation. Avoir accès à un savoir-faire en informatique serait
un autre avantage de l'externalisation ; ainsi, cela réduit le risque d'obsolescence technologique et
dépasser les concurrents sur le plan technologique. De plus, cela permet à une entreprise de se concentrer sur
son activité principale et réduire sa charge de travail. Certaines limitations de cette stratégie incluent le risque de
perte des compétences clés de l'organisation, réduction de la qualité du service reçu par un
client, et aussi un certain risque d'augmentation des dépenses imprévues.

Les avantages et les inconvénients de l'option de 'sous-traitance' sont résumés dans le tableau
5.[23]

TABLEAU 5. Avantages et Inconvénients de l'Externalisation

AVANTAGES INCONVÉNIENTS
Réduction des coûts Perte des compétences organisationnelles

Accès à un spécialiste de classe mondiale Réduction de la qualité des services

fournisseurs
Augmentation des coûts en raison de dépenses imprévues
Amélioration de la concentration sur le cœur de métier

96
 Sous-traitance de la charge de travail

Meilleure gestion des risques

SUJET 12 : GESTION DE PROJET TIC

THÉORIE

[Link].T0 Objectifs Spécifiques

114 À la fin de ce sujet, le stagiaire devrait être capable de :

a) expliquer le sens et l'importance de la gestion de projet ICT

b) décrire les outils de gestion de projet TIC

c) expliquer les critères d'évaluation des projets TIC

d) expliquer les signes d'un projet TIC en échec

e) expliquer les raisons de l'échec des projets TIC

f) expliquer les stratégies pour gérer un projet TIC en difficulté

CONTENU

97
Signification et importance de la gestion de projet TIC

Un projet est une série d'activités connexes planifiées pour atteindre un objectif commercial spécifique.
Les projets de systèmes d'information comprennent :

développement de nouveaux systèmes d'information,

Amélioration des systèmes existants, ou mise à niveau ou remplacement des informations de l'entreprise
infrastructure technologique (TI).

La gestion de projet fait référence à l'application de connaissances, de compétences, d'outils et de techniques pour
atteindre des objectifs spécifiques dans des budgets et des délais définis. Gestion de projet
les activités comprennent :

planification du travail
évaluer le risque,
évaluer les ressources nécessaires pour accomplir le travail,
organiser le travail
acquérir des ressources humaines et matérielles
assignation de tâches
diriger des activités
contrôle de l'exécution du projet,
faire le point sur les avancées, et

analyser les résultats.

Comme dans d'autres domaines des affaires, la gestion de projet pour les systèmes d'information doit faire face à cinq
variables majeures

portée
temps
coût
qualité, et
risque

Le périmètre définit ce qui est ou n'est pas inclus dans un projet. Par exemple, le périmètre d'un projet pour un
un nouveau système de traitement des commandes pourrait inclure de nouveaux modules pour la saisie des commandes et
les transmettre à la production et à la comptabilité mais pas de changements aux comptes associés
systèmes de créances, de fabrication, de distribution ou de contrôle des stocks. La gestion de projet définit
tout le travail nécessaire pour mener à bien un projet et doit garantir que la portée d'un
Le projet ne s'étend pas au-delà de ce qui était initialement prévu.

Le temps est la quantité de temps nécessaire pour terminer le projet. La gestion de projet typiquement
établit le temps nécessaire pour compléter

principales composantes d'un projet. Chacune de ces composantes est ensuite décomposée

98
décomposer en activités et tâches. La gestion de projet tente de déterminer le temps nécessaire pour
complétez chaque tâche et établissez un calendrier pour terminer le travail.

Les coûts sont basés sur le temps nécessaire pour réaliser un projet multiplié par le coût des ressources humaines.
nécessaires pour compléter le projet. Les coûts des projets de systèmes d'information comprennent également le coût de
matériel, logiciel et espace de travail. La gestion de projet élabore un budget pour le projet et
surveille les dépenses des projets en cours.

La qualité est un indicateur de la mesure dans laquelle le résultat final d'un projet satisfait les objectifs spécifiés par
La qualité des projets de systèmes d'information se résume généralement à une amélioration
performance organisationnelle et prise de décision. La qualité prend également en compte l'exactitude et
actualité des informations produites par le nouveau système et facilité d'utilisation.

Outils de gestion de projet TIC

La gestion de projet est une tâche difficile avec de nombreuses responsabilités complexes. Heureusement, il y a
Il existe de nombreux outils disponibles pour aider à accomplir les tâches et à exécuter les responsabilités.

Les chefs de projet doivent choisir un outil de gestion de projet qui correspond le mieux à leur style de gestion.
Aucun outil ne répond à tous les besoins en gestion de projet.

La technique d'évaluation de programme (PERT) et les graphiques de Gantt sont deux des méthodes les plus couramment utilisées

outils de gestion de projet utilisés. Ces deux outils de gestion de projet peuvent être produits
manuellement ou avec des logiciels de gestion de projet disponibles dans le commerce.

Le PERT est un outil de planification et de contrôle utilisé pour définir et contrôler les tâches nécessaires à
compléter un projet. Les diagrammes PERT et les diagrammes de la méthode du chemin critique (CPM) sont souvent utilisés
de manière interchangeable ; la seule différence réside dans la façon dont les temps de tâche sont calculés. Les deux graphiques affichent le total

projet avec toutes les tâches programmées affichées dans l'ordre. Les tâches affichées montrent lesquelles sont en
parallèle, ces tâches qui peuvent être effectuées en même temps. Une représentation graphique appelée un
"Réseau de projet" ou "Diagramme CPM" est utilisé pour représenter graphiquement les interrelations du
éléments d'un projet et montrer l'ordre dans lequel les activités doivent être effectuées.

La planification PERT implique les étapes suivantes :

1. Identifiez les activités et jalons spécifiques. Les activités sont les tâches du projet.
Les jalons sont les événements qui marquent le début et la fin d'un ou plusieurs
activités.
2. Déterminez la séquence appropriée des activités. Cette étape peut être combinée avec la #1 ci-dessus.
puisque la séquence d'activité est évidente pour certaines tâches. D'autres tâches peuvent nécessiter un certain
analyse pour déterminer l'ordre exact dans lequel elles doivent être effectuées.
3. Construire un diagramme de réseau. En utilisant les informations de séquence d'activités, un diagramme de réseau
peut être dessiné montrant la séquence des activités successives et parallèles. Fléché
Les lignes représentent les activités et les cercles ou « bulles » représentent les jalons.

99
 4. Estimez le temps nécessaire pour chaque activité. Les semaines sont une unité de temps couramment utilisée pour
achèvement de l'activité, mais toute unité de temps cohérente peut être utilisée. Une caractéristique distinctive
de PERT est sa capacité à gérer l'incertitude dans les temps d'achèvement des activités. Pour chaque
activité, le modèle comprend généralement trois estimations de temps :
oTemps optimiste - le temps le plus court dans lequel l'activité peut être complétée.
oTemps le plus probable - le temps d'achèvement ayant la plus haute probabilité.
oTemps pessimiste - le temps maximal qu'une activité peut prendre.

À partir de cela, le temps attendu pour chaque activité peut être calculé en utilisant les éléments suivants
moyenne pondérée

Temps attendu = (Optimiste + 4 x Le plus probable + Pessimiste) / 6

5.Déterminez le chemin critique. Le chemin critique est déterminé en ajoutant les temps pour le
activités dans chaque séquence et détermination du chemin le plus long dans le projet. Le critique
le chemin détermine le temps total du calendrier requis pour le projet. La quantité de temps qu'un
une activité non critique peut être retardée sans retarder le projet est appelée
temps libre.

Si le chemin critique n'est pas immédiatement évident, il peut être utile de déterminer le
quatre fois pour chaque activité :

TEM - Temps de début le plus tôt

Temps de Fin le Plus Tôt

oLS - Heure de début la plus récente

oLF - Heure de fin la plus tardive

Ces temps sont calculés en utilisant le temps attendu pour les activités pertinentes. Le plus tôt
Les heures de début et de fin de chaque activité sont déterminées en avançant (passage en avant)
à travers le réseau et en déterminant le moment le plus tôt auquel une activité peut commencer et
terminer en prenant en compte les activités de son prédécesseur.

Les heures de début et de fin les plus récentes sont les dernières heures auxquelles une activité peut commencer et finir sans
retardant le projet. LS et LF sont trouvés en travaillant à rebours (retour en arrière) à travers le
réseau. La différence entre la dernière et la première fin de chaque activité est le temps de latence de cette activité. Le
Le chemin critique est donc le chemin à travers le réseau dans lequel aucune des activités n'a de marge.

Critères d'évaluation des projets TIC

Signes d'un projet TIC en échec

Votre projet est-il devenu incontrôlable, menaçant d'être à la fois en retard et dépassé en budget ?
Les signes d'alarme étaient probablement là depuis le début. Voici comment comprendre ce qui a mal tourné.
et ce que vous pouvez faire pour sauver un projet en difficulté.

100
Les projets de SI qui deviennent ingérables nécessitent des chefs de projet avec des compétences, de l'expérience et de la résilience pour
ramenez-les sur la bonne voie. Vous pouvez avoir l'idée qu'un projet commence à échappé à tout contrôle
lorsque vous remarquez que les parties prenantes n'assistent pas aux réunions de projet, les développeurs partent
le projet, ou le groupe financier pose tout simplement trop de questions sur les dépenses quotidiennes/ressources
allocations.
Votre défi en tant que responsable de projet ou de développement est d'identifier de manière proactive des projets qui ont
devenu mauvais puis décider de réingénierie (c'est-à-dire moderniser) ces problèmes. Mauvais projets, laissés
intouché, pourrait causer des dommages irréparables à toute organisation.

Certains problèmes typiques que vous pouvez rencontrer sur un projet, ainsi que des solutions possibles, sont
montré dans la Figure A.

Figure A
Symptôme Solution
Mauvaises communications Élaborez un plan de communication et informez tout le monde
parties prenantes
· Établir des réunions de projet fréquentes
· Documents les rôles et responsabilités
Mauvaise estimation et planification Utilisez des analystes, des PME et/ou des estimateurs de coûts pour aider à
estimation
Documentation minimale Identifier la documentation minimale nécessaire sur le projet
· Étude de cas / Résumé de projet
Spécification des exigences utilisateur
· Spécification(s) technique(s) selon les besoins
· Plan de déploiement
· Calendrier du projet
· Calendrier d'entraînement

· Plan de test
Mauvaise gestion de projet Soit remplacer le chef de projet par un plus fort
candidat ou impliquer la direction exécutive et le leadership
Mauvais soutien des dirigeants Obtenez un soutien exécutif immédiat par l'escalade
Mauvaises exigences utilisateur Documenter et approuver les exigences des utilisateurs et établir le
contrôles de changement nécessaires pour soutenir d'éventuels changements futurs

En fonction des aspects uniques d'un projet, il pourrait y avoir une multitude de raisons pour un
le projet sort de contrôle. Les facteurs de risque incluent les suivants :

Exigences approximatives : Chaque projet dépend d'exigences utilisateur solides étant fermement
verrouillé avant qu'un travail soit entrepris. Le non-respect de cette consigne est une cause principale de
échec de projet. D'une certaine manière, la tendance est que de nombreuses équipes de projet pensent qu'elles peuvent commencer.

en précipitant la phase de collecte des exigences. Ces projets sont ensuite lancés avec enthousiasme avec

101
 exigences incomplètes. Si vous développez un projet en utilisant un modèle en cascade standard
méthodologie, toute exigence incomplète aura à la fois un coût et un calendrier négatifs
impact sur le projet. Sur les projets de développement itératif, les exigences des utilisateurs sont toujours de
d'une importance capitale, mais peut être négocié avant tout développement réel.
Retard dans le calendrier : De nombreuses fois, les délais de projet deviennent incontrôlables lorsque les dates et
les livrables ne sont pas surveillés ni suivis de manière agressive sur une base quotidienne. Trop souvent,
les gestionnaires laissent des problèmes non résolus pendant des jours, ce qui entraîne des dépassements de calendrier. Je
Je recommande que vous vérifiiez les horaires des projets quotidiennement.
Dépassement de budget : Les projets qui dépassent le budget sont parfois plus sujets à être
annulé car les cadres supérieurs s'inquiètent des flux de trésorerie entrants et sortants
coffres de l'entreprise. Si un projet commence à montrer des dépassements de coûts progressifs, le projet est souvent encore
donné une chance, mais, alors que les pertes s'accumulent et ne montrent aucun signe de récupération, annuler le
un projet peut être nécessaire. En réalité, cependant, certains projets sont si critiques pour l'entreprise
la survie qu'ils ne peuvent pas être arrêtés. Par conséquent, les dépassements de coûts sont simplement absorbés ou
habilement transférés ailleurs. Cela signifie que les chefs de projet doivent gérer leur
budgets réels par rapport au budget prévu et tenir leurs parties prenantes informées de tout
déviation.
Élargissement du périmètre : Lorsque les clients insistent sur des modifications de plus en plus nombreuses du produit en cours de réalisation.
développé, le dépassement de portée peut compromettre le projet. Je ne connais pas trop de projets
des responsables qui peuvent gérer trop de changements en même temps. Une situation encore plus difficile
pour un chef de projet, cela se manifeste lorsque de nouveaux changements sont introduits après que le projet a été
lancé. Cela augmente généralement le coût, les exigences en ressources, les livrables, et
temps d'achèvement. L'élargissement du champ d'application doit être géré et le chef de projet doit avoir
un processus de contrôle des changements en place pour évaluer l'impact et le coût du changement et,
possiblement, négocier le changement pour une future version.
Planification et estimation médiocres : Les projets qui sont mal estimés et planifiés tendent
échouer à la fois en termes de coût et de calendrier, ce qui entraîne finalement l'échec global du projet.
Les gestionnaires ont tendance à commencer des projets sans s'appuyer sur une analyse adéquate et un dimensionnement approprié, et échouent à

consulter des experts en la matière ou des estimateurs de coûts pour valider combien de travail de projet
les colis coûteront.
Mauvaise documentation : Maintenir une documentation de projet inadéquate est une source de préoccupation
et devrait tirer la sonnette d'alarme. Les leçons tirées de nombreux projets échoués révèlent que
il y avait trop peu de documentation pour décrire adéquatement le projet dans ses termes les plus larges, et
servir de canal de communication clair.
Nouveaux technologies : Projets nécessitant l'intégration de nouveaux outils et le déploiement de nouveaux fournisseurs
les applications/appareils sont toujours beaucoup plus difficiles, car généralement, seul le vendeur
Les ingénieurs comprennent clairement les limites et la fonctionnalité des produits. Cela résulte
dans des retards dans le calendrier du projet et pourrait nécessiter des semaines ou des mois avant que les produits ne soient
suffisamment stable pour être déployé. Si un projet est entrepris en utilisant une nouvelle technologie, les gestionnaires
devraient être conscients des risques associés et planifier leurs emplois du temps en conséquence.
Communications pauvres : L'une des principales raisons pour lesquelles un projet échoue est due à un
manque de communication. J'ai vu de nombreux projets échouer simplement parce que personne ne comprend
que faire et ne reçoit aucune communication sur l'avancement actuel ; cela, inévitablement, résulte
dans l'échec du projet.

102
 Mauvaise prise de décision : Décisions qui ne sont pas prises du tout et décisions qui sont retardées en raison
Le fait de douter et de renverser sont tous deux des facteurs de risque. De plus, certaines décisions sont tellement retournées-
hors contexte alors que la responsabilité leur est transmise le long de la chaîne, ils finissent par être fabriqués
basé sur des informations erronées. Cela ne prévoit rien de bon pour un projet critique.
Mauvaise gestion de projet : La personne en charge du projet n'a peut-être pas les compétences nécessaires ou
expérience pour y parvenir. Oui, tout projet peut être bloqué par un manager incompétent. Dans de tels cas
dans certains cas, il peut être nécessaire d'arrêter le projet, de remplacer le chef de projet, de faire le
ajustements nécessaires et recommencer. Le directeur sortant devrait avoir la possibilité
pour fournir sa version de l'histoire, cependant, avant de passer à autre chose.
Mauvais test : Un grand coupable dans tout projet est d'avoir soit trop peu de tests, soit dans beaucoup
cas—si une équipe de test est impliquée—tester trop tard dans le processus. À la fois les tests et la qualité
L'assurance doit être intégrée au projet dès le jour du lancement du projet.

Raisons de l'échec des projets TIC

Stratégies pour gérer un projet TIC en échec

Mesures de contrôle - Étapes vers la recherche de la solution
Pour les chefs de projet travaillant contre la montre (c'est-à-dire dans des industries concurrentielles), il peut être utile d'essayer de

remettre le projet sur les rails en suivant les étapes suivantes :

Lisez entre les lignes :

Une fois que vous commencez à avoir vent de problèmes tels que le calendrier, la qualité, le coût, les conflits de ressources
ou des rapports de statut en retard, je recommanderais alors une revue en tête-à-tête avec le projet applicable
gestionnaire dès que possible pour déterminer le véritable état du projet.

Reconnaître ce qui a mal tourné :

Essayez d'évaluer quelles étaient les raisons de l'échec du projet au départ. Ça ne sert à rien.
blâmer simplement les gens. Si l'échec était dû à une mauvaise estimation ou à une mauvaise planification, alors les efforts

doivent être mises en place pour corriger tout futur projet suivant le même chemin.

Déterminez quoi faire :

Devez-vous annuler un mauvais projet ou essayer de le remettre sur les rails ? Les organisations sont confrontées
avec de mauvais projets, il faudrait d'abord essayer de sauver leurs mauvais performers plutôt que d'annuler
eux.

Éduquez votre personnel de projet :

103
 La formation et l'éducation vont vraiment loin pour corriger les mauvaises pratiques de projet.

Tendances émergentes dans la SAD

THÉORIE

[Link].T0 Objectifs spécifiques

À la fin de ce sujet, le stagiaire devrait être capable de :

a) identifier les tendances émergentes dans le SAD

b) expliquer les défis des tendances émergentes en SAD

c) faire face aux défis des tendances émergentes

104
CONTENU
Tendances émergentes dans le TDAH

Défis des tendances émergentes en SAD

Faire face aux défis des tendances émergentes dans le TDA

DEVOIR

Les deux questions chacune valent 15 points.

Question 1.

a) Décrivez les méthodes d'acquisition des systèmes d'information

b) Expliquer les critères de choix d'une méthode d'acquisition de système d'information

Question 2
a) Identifier les tendances émergentes en Analyse et Conception de Systèmes

b) Décrivez les défis des tendances émergentes en analyse et conception de systèmes

c) Expliquez comment les organisations font face aux défis des tendances émergentes en analyse des systèmes
et Design

105