les systèmes d’information · systèmes d’information opérationnels (sio) environnement...
TRANSCRIPT
Les Systèmes d’Information
Sommaire
1. Définitions
2. Typologie
3. Exemples
4. Périmètre
5. Techniques et usages
6. Dimensions
7. Cycle de vie
3
Données, Informations, Connaissances
Donnée
▬ Décrit des objets ou des événements dignes d ’intérêt.
▬ Ex:La quantité achetée du produit A dans la facture N°6 est de 20 unités.
Information
▬ Modifie notre vision du monde et réduit l’incertitude. Les données deviennent
information par un processus d’interprétation qui fait intervenir les connaissances de
l’individu.
▬ Ex: Les ventes du produit A sur la région Nord ont augmenté de 10%en 2012.
Connaissance
▬ Ensemble de schémas qui augmente notre compréhension (M.J. Earl).
▬ connaissance formalisée ou explicite. Se transmet par le discours. Exemple: le
modèle comptable.
▬ connaissance tacite. S’acquiert par la pratique. Exemple: faire du ski nautique.
▬ Ex: Généralement, un client qui a acheté le produit A achète ensuite le produit B
Définitions des systèmes d’information
Ensemble de composantes inter-reliées qui recueillent de l’information, la traitent, la stockent et la diffusent afin de soutenir les processus métiers de l’entreprise, la prise de décision et le contrôle au sein de l’organisation
Ensemble d’informations nécessaires au fonctionnement de l’entreprise. Ces informations sont internes ou externes, structurées ou non et dont le traitement est automatisé ou non
C’est un système au sein de l’organisation qui comprend l’ infrastructure, les applications, les systèmes, et le personnel qui exploite les TI pour mettre à disposition des acteurs de l’entreprise l’information et les moyens de communication pour réaliser les transactions et les activités.
C’est un système qui utilise les ordinateurs et les moyens de communication, les procédures manuelles, les référentiels de données internes et externes. Il applique une combinaison d’actions automatiques et humaines ainsi que des interactions homme/machine.
Le SI sert de support aux processus métiers réalisés par les acteurs dans un cadre organisationnel
Typologie des systèmes d’information
Activité
Fonction Ressources Humaines
(SIRH)
Marketing/Vente
(SIM)
Compta/Finance
(SIFC)
Logistique/Production
(SIL)
Activités opérationnelles (SIO)
Activités tactiques (SID)
Activités
stratégiques (SIS)
Exemples de systèmes d’information
- Suivi des
commandes
- Traitement
des
commandes
- Contrôle
des machines
- Ordonnancement
des usines
- Contrôle des
flux de matériels
- Paie
- Gestion des
comptes
débiteurs
- Gestion des
comptes
créditeurs
- Audit
- Reporting
fiscal
- Gestion de
la trésorerie
- Compensation
- Formation
- Gestion des
carrières
Systèmes
d’aide
stratégique
Systèmes
d’aide à
la décision
Systèmes
transac-
tionnels
Ventes Production Comptabilité Finance Personnel
- Gestion des
ventes
- Analyse des
ventes
- Contrôle
d ’inventaire
- Echéancier
de production
- Budget
annuel
- Analyse des
investissements
- Analyse
prix/profit
- Analyse des
localisations
- Analyse
des coûts
- Plan
à 5
ans
- Planification
de la force
de travail
- Prévisions
budgétaires
à moyen et long
terme
- Prévision des
ventes à
moyen terme
Caractéristiques des SI
Entrées Traitements Sorties Utilisateurs
SID
SIS
TYPE
SIO
Données agrégées,
internes et externes
Volume de
données faible
Données issues
des SIO
Transactions
Evénements
Graphiques
simulations
interactivité
Interactivité
Simulation
Analyse
Etats simples
Modèles simples
Peu d’analyse
Tris, listes,
fusion, mise à
jour
Projections,
réponses à des
requêtes
Etats de gestion,
Analyse des
décisions,
Réponse
à des requêtes
Etats d’exception
Etats détaillés,
listes,
Etats de gestion
Senior managers
Managers (staff)
Middle managers
Opérationnels
Superviseurs
Volume de
données élevé
Systèmes d’information opérationnels (SIO)
▬ Environnement informatique à travers lequel des transactions sont réalisées en quasi-temps réel
▬ Environnement comprenant une ou plusieurs applications ainsi que des acteurs internes et/ou externes à l'entreprise
▬ Concerner tout type de flux (financiers, commerciaux, production, etc.)
▬ Chaque transaction engendre des mises à jour des bases de données
▬ Repose typiquement sur une architecture clients serveurs
▬ Traite plusieurs transactions simultanément
▬ Ex: infrastructures informatiques des places boursières, le réseau mondial de transaction interbancaire SwiftNet, les systèmes de réservation centralisés tels Amadeus, Sabre, Galileo, WorldSpan.
Préoccupation des entreprises
▬ automatiser les opérations de gestion
▬ rationaliser les coûts
▬ gérer la maintenance et l’évolution
▬ faciliter l’intégration des SI
▬ améliorer la qualité des données
Systèmes d’information décisionnels (SID)
Aide à la décision en amplifiant le raisonnement du décideur
Systèmes individuels, orientés métier
Données externes, agrégées
S’appuient sur les SI opérationnels et les entrepôts de données
Un entrepôt de données est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d ’un processus d ’aide à la décision.
C’est un système d ’information dédié aux applications décisionnelles dont les principales contraintes sont :
▬ des requêtes complexes à plusieurs niveaux d ’agrégation
▬ la nécessité de disposer d ’informations synthétiques
▬ le stockage des données sous une forme multidimensionnelle
▬ des mises à jour périodiques
Préoccupations des entreprises :
▬ Gestion du temps des dirigeants
▬ Nécessité de disposer de la bonne information
▬ Nécessité de piloter l’activité de façon efficace
Niveau Caractéristiques
Individuel
Système utilisé par un seul individu,
à son poste de travail.
Exemples
- Suivi de tableaux de bord par un
contrôleur de gestion,
- Profession libérale (médecin)
Collectif
Plusieurs individus dans l’organi-
sation utilisent le même système.
Concerne une fonction, un service,
un groupe, etc..
- La plupart des applications informa-
tiques classiques
- Système d’aide à la décision de
groupe
Organisationnel
- Accessible à l’ensemble des
membres de l’organisation
- Intranet
- système de consultation de docu-
mentation générale, etc..
Étendue des SI
Niveau Caractéristiques
Inter-
organisationnel
Des organisations différentes
échangent des informations de
manière + ou - formalisée.
Exemples
- Échange de données informatisées
(EDI) –
- Extranet
- Commerce électronique B to B
et B to A
Organisation
à individu
Une organisation échange des
informations avec des particuliers
(clients en général)
Commerce électronique B to C
(Business to Consumer)
Étendue des SI (suite)
12
Quelques techniques et outils
Base de Données : Une collection intégrée de données liées entre elles, utilisée par un certain nombre d ’applications dans une organisation et gérée par un SGBD.
Progiciel : Logiciel applicatif standard. Ex: comptabilité, paie, facturation…
Progiciel de Gestion Intégré (PGI – ERP) : Ensemble de progiciels de gestion intégrés dans une architecture unique
Data Warehouse (entrepôt de données) : Base de données à vocation décisionnelle.
Data mining (fouille de données) : Découverte de connaissances à partir de données.
Gestion de la Relation Client (GRC - CRM) ▬ Capacité à bâtir une relation profitable sur le long terme avec les meilleurs clients en
capitalisant sur l’ensemble des points de contacts
▬ Distinction entre CRM opérationnel et analytique.
Système expert : Système qui utilise les connaissances d’un domaine d’application et une procédure d’inférence (raisonnement) pour résoudre des problèmes de manière automatique.
Internet, Intranet
Extranet : Intranet ouvert à un ensemble prédéfini de partenaires (clients, fournisseurs, anciens élèves…).
Groupware : Logiciels facilitant le travail en groupe (collecticiels).
13
Management des
opérations
Executive Information Systems (EIS)
Communication
Aide à la décision
Progiciels de gestion (comptabilité …)
Progiciels de Gestion Intégrés (ERP)
Bases de données Systèmes d’Aide à la Décision (BI)
Data warehouses Data mining
Systèmes experts
Internet, Intranet, Extranet
Groupware
Systèmes d’Aide à la
Décision de groupe
Quels outils/techniques pour quelles utilisations?
Gestion de la Relation Client (CRM)
Les dimensions des Systèmes
d’Information
Les dimensions du SI
Dimension Humaine
Les dimensions
du SI
Dimension
Technologique Dimension
Organisationnelle
Dimension Financière
La dimension humaine
Des utilisateurs
▬ expriment des besoins généralement dans un cahier des charges
▬ partenaires, clients
Des informaticiens
▬ compétence en évolution rapide
▬ combiner des connaissances techniques et des connaissances métiers
▬ difficultés d ’ajustement offre-demande sur le marché de l ’emploi
▬ problèmes de G.R.H. au sein de l ’entreprise
La dimension humaine: les utilisateurs
Objectif : comprendre ce que les utilisateurs attendent du système
▬ Les faits :
▬31% des projets sont abandonnés
▬13% des projets respectent les coûts et délais
▬ Pourquoi ?
▬Cahier des charges incomplet (13%) ***
▬Manque d’implication des utilisateurs (12%) ***
▬Manque de ressources (1%) *
▬Attentes irréalistes (10%) *
▬Manque de soutien hiérarchique (9%)
▬Besoins et spécifications qui évoluent (9%) ***
▬Manque de planification (8%)
▬Système devenu sans objet (7%) *
La dimension humaine: Qu’est ce qu’un besoin ?
De la définition très abstraite d’un service ou d’une contrainte jusqu’à la spécification fonctionnelle mathématique détaillée
Caractéristique du système ou description de ce que le système est capable de faire
Les besoins ou exigences sont la description des services du système et des contraintes générées pendant le processus
les services que le client attend d’un système et les contraintes dans lesquelles il est développé et dans lesquelles il opère
La dimension humaine : Typologie des besoins
Besoins utilisateurs : Expressions en langage naturel ou graphique représentant les services que le système fournit et ses contraintes opérationnelles
Besoins systèmes : Document structuré détaillant les fonctions du système, définit ce qui devrait être implémenté
Besoins pérennes : Liés à l’activité principale du client. Dérivables du domaine
Besoins volatiles : Changent pendant le développement ou pendant l’exploitation du système
Besoins mutants : liés à l’évolution de l’organisation
Besoins émergents : liés à la compréhension par le client des possibilités éventuelles du système
Besoins induits : résultent de l’introduction du système et de son impact sur les processus
Besoins de compatibilité : dépend des systèmes particuliers au sein d’une organisation et de leurs changements propres
Besoins du domaine: Découlent du domaine d’application
Besoins fonctionnels : Services que le système doit rendre
Besoins non fonctionnels : Contraintes sur les services ou fonctions du système (performance, sécurité, fiabilité, qualité, etc.)
La dimension humaine : besoins fonctionnels
Décrivent les fonctionnalités du système. Dépendent du type du logiciel, des utilisateurs
supposés et du type d’environnement où le logiciel est utilisé
Deux niveaux: Forme abstraite de haut niveau et/ou Forme détaillée
Exemple : Un système de bibliothèque qui fournit une interface unique à différentes bases
d’articles dans différentes bibliothèques électroniques. Les utilisateurs peuvent chercher,
télécharger et imprimer les articles à fin d’usage personnel. L’utilisateur doit pouvoir chercher
dans toutes les bases ou dans une sélection de bases. Le système doit fournir des outils de
visualisation adaptés pour que l’utilisateur lise les documents dans la bibliothèque. A chaque
commande, on associera un identifiant unique que l’utilisateur pourra copier dans son espace
propre
L’imprécision des besoins exprimés
▬ Ambiguïté : visionneuses adaptées
▬ Peut vouloir dire un outil de visualisation spécifique pour chaque type de document
▬ Ou encore un outil de visualisation du texte, quel que soit le contenu du document
Complétude et cohérence
▬ La spécification des besoins doit inclure toutes les fonctionnalités souhaitées
▬ Il ne doit pas y avoir de conflit ni de contradiction dans la description de toutes les
fonctionnalités
▬ Impossible à assurer
La dimension humaine: besoins non fonctionnels
Propriétés et contraintes du système
▬ Fiabilité, temps de réponse, besoins de stockage, possibilités des matériels d’interface, etc.
Besoins liés au processus
▬ Utilisation d’un AGL, d’un langage, d’une méthode particulière
Les besoins non fonctionnels peuvent être aussi critiques que les besoins fonctionnels :
▬ S’ils ne sont pas assurés, le système peut être sans utilité
Types de besoins non fonctionnels:
▬ Besoins produits: Exigences liées au comportement du produit : temps de réponse, fiabilité, etc.
Ex: l’interface utilisateur doit être implémentée sous forme HTML sans frames ni applets Java
▬ Besoins organisationnels: Liés aux procédures organisationnelles : respect des standards,
contraintes d’implémentation, contraintes de délais, etc. Ex: Besoin organisationnel : le
processus de développement et les documents associés doivent respecter la norme IEEE xxx
▬ Besoins externes: Dus à des facteurs externes au produit et au processus : interopérabilité,
exigences légales, sécurité, respect de la vie privée, etc. Ex: le système ne doit pas dévoiler
d’information personnelle autre que le nom du client et son numéro de référence
La dimension humaine :
qualité des spécifications des besoins
Exactitude
Cohérence
Complétude
▬ Externe : contient toutes les propriétés souhaitées
▬ Interne : toutes les références entre les spécifications sont décrites
précisément
Les exigences sont-elles réalistes ?
Est ce que chaque spécification décrit quelque chose de
nécessaire pour le système ? ▬ Pas de restriction inutile ni de fonctions non directement reliées au
système
Les spécifications sont-elles vérifiables ?
Traçabilité
La dimension humaine: buts vs besoins
Les besoins non-fonctionnels peuvent être très difficiles à exprimer très
précisément
S’ils sont imprécis, il est difficile de les vérifier
But : intention générale de l’utilisateur comme la facilité d’utilisation
Besoin non fonctionnel vérifiable : contenant une mesure qui peut être
testée objectivement
Les buts permettent aux développeurs de préciser les intentions des
utilisateurs
Exemple:
▬ But : le système doit être facile à utiliser par des contrôleurs expérimentés et
il doit être organisé de sorte que les erreurs des utilisateurs soient
minimisées
▬ Besoin non fonctionnel vérifiable : un contrôleur expérimenté doit être
capable d’utiliser toutes les fonctions du système après 2 heures de
formation ; le nombre moyen d’erreurs ne doit pas excéder 2 / jour et /
utilisateur
La dimension humaine : mesures des besoins
Propriété Mesure
Rapidité Nb de transactions traitées par seconde
temps de réponse
temps de rafraîchissement de l'écran
Taille Moctets
Nb de puces
Facilité d'utilisation Temps de formation
nombre d'écrans d'aide
Fiabilité Temps moyen entre pannes
Probabilité d'indisponibilité
Taux d'occurrence d'un échec
Disponibilité
Robustesse Temps de redémarrage après panne
pourcentage d'événements provoquant des erreurs
Portabilité pourcentage d'instructions dépendant du système cible
Nombre de systèmes cibles
La dimension humaine :
problèmes liés au langage naturel
Manque de clarté : s’il est trop précis, il est indigeste
Confusion : fonctionnels et non fonctionnels sont mélangés
Amalgame : plusieurs besoins différents peuvent être exprimés dans
une même phrase
Ambiguïté
Multiplicité : la même chose peut être dite de différentes façons
Manque de modularité : le LN ne conduit pas naturellement à la
structuration
Exemple1: Le système doit fournir un système de comptabilité financière qui maintient la
liste de tous les paiements faits par les utilisateurs du système. Les gestionnaires du
système doivent configurer ce système pour que les clients fidèles puissent recevoir des
promotions. (Mixe une information générale et une information détaillée).
Exemple2: Pour l’assister dans le positionnement des objets sur le graphique, l’utilisateur
peut activer une grille en centimètres ou en pouces. La grille peut être activée ou
désactivée à tout moment pendant une session. L’option de grille doit permettre aussi de
réduire les objets selon les limites de la grille. (Mixe fonctionnel, non fonctionnel et interface
utilisateur).
La dimension humaine : le dossier de spécifications
Définition officielle de ce qui est attendu des développeurs du système
Doit inclure les spécifications générales (besoins utilisateurs) et les
spécifications détaillées (besoins système)
Ce n’est pas le dossier de conception : décrit le QUOI et pas le
COMMENT, autant que faire se peut
Qui l’utilise?
▬ Clients : spécifient les besoins et lisent le dossier pour vérifier et rectifier les
spécifications
▬ Ingénieurs d’affaires : sur la base du dossier de spécifications, font une offre
et un planning de développement du système
▬ Ingénieurs système : utilisent le dossier pour comprendre ce qu’ils doivent
développer
▬ Ingénieurs testeurs : utilisent le dossier pour créer les cas et procédures de
test
▬ Ingénieurs de maintenance : utilisent le dossier pour comprendre le système
La dimension humaine :
standard de spécifications IEEE
Environnement physique : ▬ Où le système doit-il être installé ?
▬ A un endroit ou plusieurs ?
▬ Y a-t-il des restrictions environnementales comme la température, l’humidité ou les interférences magnétiques ?
Interfaces : ▬ Les entrées du système proviennent-elles d’un ou plusieurs autres systèmes ?
▬ Les sorties du système doivent-elles alimenter un ou plusieurs systèmes ?
▬ Y a-t-il un format imposé pour les données ?
▬ Y a-t-il un médium imposé pour les données ?
Utilisateurs et facteurs humains ▬ Qui utilisera le système ?
▬ Y a-t-il plusieurs types d’utilisateurs ?
▬ Quel est le niveau de compétence de chaque type d’utilisateur ?
▬ Quelle type de formation est nécessaire pour chaque type d’utilisateur ?
▬ La compréhension et l’utilisation du système seront-elles aisées pour l’utilisateur ?
▬ Sera-t-il difficile pour l’utilisateur de « mal se servir » du système ?
Fonctionnalités ▬ Que fera le système ?
▬ Quand le système le fera-t-il ?
▬ Y a-t-il plusieurs modes opératoires ?
▬ Comment et quand le système sera-t-il modifié ou renforcé ?
▬ Y a-t-il des contraintes en termes de vitesse d’exécution, temps de réponse et de capacité de traitement ?
La dimension humaine :
standard de spécifications IEEE
Documentation ▬ Jusqu’à quel point la documentation est-elle nécessaire ?
▬ Sous quelle forme doit-elle être disponible : en ligne, sous forme papier, les deux ?
▬ A quel public chaque type de documentation s’adresse ?
Données
▬ Pour les entrées et les sorties, quel devrait être le format des données ?
▬ A quelle fréquence seront-elles reçues ? Envoyées ?
▬ Quel est le degré d’exactitude souhaité ?
▬ Quelle est la précision demandée pour les calculs ?
▬ Quels flux de données traverseront le système ?
▬ Certaines données doivent-elles être stockées pendant une certaine durée ?
Ressources
▬ Quels matériels, personnes ou autres ressources sont requises pour construire, utiliser et maintenir le système ?
▬ Quelles compétences doivent avoir les développeurs ?
▬ Combien d’espace physique sera occupé par le système ?
▬ Quelles sont les exigences en termes de puissance, chaleur ou d’air conditionné ?
▬ Y a-t-il un planning imposé pour le développement ?
▬ Y a-t-il un budget limité pour le développement ou pour le matériel et le logiciel ?
Sécurité
▬ L’accès au système ou à l’information doit-il être contrôlé ?
▬ Comment les données d’un utilisateur seront-elles isolées des autres ?
▬ Comment les programmes seront-ils isolés des autres programmes et du système d’exploitation ?
▬ A quelle fréquence le système sera-t-il sauvegardé ?
▬ Les sauvegardes doivent-elles être stockées à un endroit différent ?
▬ Doit-on prendre des précautions contre le feu, les dégâts des eaux, le vol ?
Assurance qualité
▬ Quelle sont les exigences en termes de fiabilité, disponibilité, maintenabilité et autres attributs de qualité ?
▬ Comment le système doit-il être expliqué aux autres ?
▬ Le système doit-il détecter et isoler les erreurs ?
▬ Quel est le MTBF imposé ?
▬ Y a-t-il un délai maximum autorisé pour redémarrer le système après panne ?
▬ Comment le système peut-il intégrer des changements de conception ?
▬ La maintenance va-t-elle simplement corriger les erreurs ou aussi inclure des améliorations ?
▬ Quelles mesures d’efficacité vont être appliquées à l’utilisation du système et au temps de réponse ?
▬ Quelle possibilité de déplacer le système d’un endroit à un autre ou d’un ordinateur à un autre doit être prévue ?
La dimension organisationnelle
Une organisation
▬ des règles de gestion
▬ des processus
Définition d’un processus
Ensemble de tâches logiquement reliées qui utilisent les ressources de l'entreprise pour réaliser un résultat.
Suite d'activités qui, à partir d'une ou plusieurs entrées, produit un résultat représentant une valeur pour un client
Typologie des processus
Processus Identitaire : objet central de l'entreprise
Processus Prioritaire : élément important de l'entreprise (logistique, service, qualité).
Processus d'Arrière-Plan : Ce que la compagnie doit faire mais sans y consacrer trop d'efforts ou de ressources.
Processus Obligatoire : Lois et régulations.
La dimension organisationnelle : processus
Traitement d’une commande
Service clientèle
Service financier
Service ventes
MagasinService planning
Service Fabrication
Service Logistique
Service Manutention
Transporteur
CLIENT Saisie & contrôle
Contrôle crédit
Détermine prix facture
Contrôle stocks dispo
Ordonnan- cem ent
Fabrication
Program me expédition
Choix transporteur
Prélèvement Emballage
Confirme transporteur Achemine
La dimension organisationnelle :
exemples de processus
Etude de marché Analyse de l a concurrence Concepti on global e Concepti on détai llée Approbation produi t Test produit Concepti on du processus
Ventes Trai tement des commandes Livraison Servi ce après vente Gestion des comptes
Développement Nouveau Produit Service client
Recrutement Evaluations Formation Actions disciplines Promotion et Sél ecti on
Gestion Ressources Humaines
DADS Impôts …
Concepti on réseau physique Logistique Evaluation service et coûts Management des contrats Partnership Management des partenai res Management des ressources
Management Chaîne Fournisseur
Suivi des coûts Budget Prévision financière Planification des taxes Reporting fi nancier
Gestion Financière
Identitaire
Arrière-Plan
Prioritaire
Prioritaire
Obligatoire
Arrière-Plan
La dimension organisationnelle :
des processus à re-configurer
Une fois les processus identifiés, il faut choisir les
candidats à la re-configuration et l'ordre dans lequel on
les traitera.
Le choix se portera en priorité sur :
les processus brisés : ceux dont les dirigeants savent déjà
qu'ils posent problème.
les processus importants (identitaires, prioritaires) : les clients
sont une bonne source d'information sur l'importance
respective des différents processus ; se mettre à la place des
clients du processus
La dimension organisationnelle :
la reconfiguration de processus
» Démarche méthodologique utilisant les technologies de l'information
afin de redéfinir les processus de gestion de l'entreprise et d'atteindre
ses objectifs.
» Redéfinition des processus de gestion et des structures de
l'organisation qui limitent la compétitivité, l'efficacité et l'efficience de
l'entreprise.
» Reconception des processus de gestion pour réaliser des
améliorations significatives dans les coûts, la qualité et le service.
» Combinaison d'une vision de l'entreprise fondée sur les processus et
de l'application de l'innovation (notamment technologique) pour
atteindre et améliorer les objectifs de l'entreprise.
» Toute activité ou groupe d'activités qui prend une entrée (input), lui
rajoute de la valeur, et la transforme en sortie (output) destinée à un
client interne et externe à l'entreprise.
La dimension organisationnelle :
exemple de reconfiguration de processus (Ford)
AVANT
Achats
Commandes d'achat Fournisseur
Biens
Réception
Réception document
Comptabilité
Copie de la commande
d'achat documents traités séquentiellement
par trois fonctions
500 personnes pour réaliser toutes
les tâches intermédiaires
Paiement
Facture
La dimension organisationnelle : exemple de reconfiguration APRES
Achats
Commande d'achat
Fournisseur Biens
Réception
Paiement
Comptabilité Base de données
125 personnes
base de données réparties
permettant d'éliminer des
étapes intermédiaires et un
flot de papier séquentiel
La dimension technologique
Architectures matérielles
Architectures logicielles
Exemples d’architectures matérielles
▬ Architecture centralisée: mainframe / terminaux
▬ Architecture client/serveur: 2 ordinateurs se répartissent les tâches de :
▬gestion des données
▬ logique applicative
▬présentation des résultats
▬ Architecture 3 tiers
▬serveur de données
▬serveur d ’applications
▬un poste client (« léger ») : navigateur web
▬ Architecture n tiers
▬ répartition de la logique applicative sur plusieurs serveurs
La dimension technologique
Centralisation vs décentralisation
Centralisation ▬ Améliore contrôle et sécurité
▬ Permet des économies d’échelle
▬ Equipes plus concentrées et plus homogènes en meilleure synergie
▬ Facilite la standardisation
Décentralisation ▬ Apporte plus de flexibilité
▬ Plus proche des besoins des utilisateurs
▬ Améliore la disponibilité globale
La dimension financière
But d'un système d'information : recherche et élaboration de l'information nécessaire à l'atteinte
des objectifs.
Les résultats obtenus
▬ financiers
▬ diminution des coûts (liée à l'automatisation des traitements par exemple),
▬ accroissement d'activité (par amélioration du service client par exemple),
▬ impact sur la trésorerie par accélération de la rotation des actifs.
▬ politiques
▬ variation (augmentation ou diminution) de la flexibilité
▬ qualité du service au client
▬ variation de la satisfaction (augmentation ou diminution)des salariés au
travail
Amélioration =
résultats obtenus
moyens mis en œuvre
La dimension financière :
structure du budget informatique
répartition entre matériel, personnel et autres :
Budget matériel
Industrie
34 %
Services
31 %
Budget personnel 50 % 55 %
Fournitures, locaux et services externes 16 % 14 %
La dimension financière: coûts du SI
Ratio: Coût informatique/CA
Pour certains ce sont les frais généraux puisque c'est l'activité des
grandes fonctions de l'entreprise de traiter et échanger l'information
Ratio = frais généraux / chiffre d ’affaires
Fonctions administratives 5,58 %
Fonctions commerciales 3,82 %
Fonctions de production 5,44 %
Frais généraux divers 4,43 %
Total frais généraux 18,83 %
=> budget significatif qu'il faut maîtriser car il représente entre
1 et 20% du chiffre d'affaires.
Pourcentage par rapport au CA Frais généraux des fonctions
La dimension financière :
Total Cost of Ownership (TCO)
Le TCO est une évaluation du coût total de possession d’un système
Le TCO intègre dans son calcul tous les coûts directs et indirects liés à la possession et l'utilisation du système :
▬ coût matériel, logiciel, consommations, locaux, personnel, formation, support, maintenance, sécurité, etc.
En pratique, le calcul n'est pas si simple du fait de la difficulté liée à la répartition des frais généraux sur des postes indépendants.
La méthodologie Gartner identifie 4 catégories de TCO
Les frais de gestion : Par exemple les frais généraux
Le coût du matériel et des logiciels : Le PC, les upgrades….
Les frais de fonctionnement : Support technique, déploiement
Le coût des arrêts et des défaillances, qu’ils soient planifiés ou non
Quelques coûts cachés…
▬ Consommation électrique
▬ Coût d’installation
▬ Coût de mise à disposition
▬ Coût logiciel
▬ Explosion anarchique des machines virtuelles (coût de stockage, coût de maintenance…)
▬ Coût de maintien opérationnel des serveurs
▬ Frais de recherche et de suivi du prestataire
▬ Coûts des postes si on ne passe pas avec des clients légers.
La dimension financière :
coût d’un projet: méthodes d’estimation
Raisons
▬ 30% des projets abandonnés
▬ Les coûts sont généralement multipliés par 2
▬ Seulement 16% des projets réussissent
Difficultés
▬ Complexité des systèmes
▬ La complexité croît suivant le carré de la taille
▬ Il existe des biais dans l’estimation
Problèmes
▬ Pas facile à réaliser
▬ Fondée sur une information incomplète
▬ L’estimation définit le budget alors que le produit est ajusté pour
tenir compte du budget
La dimension financière :
coût d’un projet: méthodes d’estimation
Analogie avec des: ▬ Projets de taille similaire
▬ Projets de même type
▬ Composants de taille similaire
▬ Types de besoins similaires
Delphi ▬ Planification
▬ Démarrage
▬ Préparation individuelle
▬ Réunion d’estimation ( 4 tours)
▬ Tâche d’assemblage
▬ Revue des résultats
Clarck ▬ Produit modularisé
▬ Estimation de chaque module
▬ Détermination des limites inf et sup de la taille
▬ Taille=(sup+4*médiane+inf)/6
Facteurs critiques ▬ X5 pour les logiciels critiques
▬ X5 pour les logiciels embarqués
▬ X1.5 pour les codes réutilisables
▬ X2.5 pour les logiciels répartis
La dimension financière
coût d’un projet : approches
Estimation fondée sur le problème
▬ Décomposer le problème en fonctions que l’on peut estimer
▬ Estimer chaque fonction (PF)
▬ Evaluation optimiste, réaliste et pessimiste
▬ Valeur espérée= (opt+4*réal+pess)/6
▬ Appliquer les métriques de productivité pour estimer coût et effort
Estimation fondée sur le processus
▬ Décomposer le processus en tâches (ou activités)
▬ Estimer l’effort pour chaque activité
Modèles empiriques
▬ E=A+BXC
▬ E= effort en h.m
▬ X= variable d’estimation (LOC ou FP)
▬ A,B,C sont des constantes
La dimension financière
estimation : outils
Outils d’estimation des coûts ▬ Estimacs
▬ Knowledge PLAN
▬ Price Systems
▬ Seer
▬ Slim
Outils pour Cocomo II
COSTAR
CostXpert
Estimate Professional
USC Cocomo II.2000
La dimension financière
estimation : outils
Outils d’estimation des coûts
▬ Estimacs
▬ Knowledge PLAN
▬ Price Systems
▬ Seer
▬ Slim
Outils pour Cocomo II
COSTAR
CostXpert
Estimate Professional
USC Cocomo II.2000
La dimension financière
estimation : quelques règles de base
Effort ( 2 * taille) = 2 * Effort (taille) + coût des interactions
Si l’on découpe une tâche de développement pour faire travailler en
parallèle plusieurs équipes, il faut introduire un coût de fractionnement
qui inclut :
Activité de découpage
+ Activité de communication entre les parties
+ Activité supplémentaire de test (plus de chemins à tester)
- Meilleures spécifications
Dès qu’on prend en compte de nouveaux besoins, coûts et délais
dérapent
Il faut intégrer les risques prévisibles dans l’estimation
Pas d’excès d’optimisme
La dimension financière
quelques données simples
40 – 20 - 40
Spécification
Conception
Programmation
Test unitaire
Test d’intégration
Validation
Vérification
Dont ( ou plus ?) 15 à 20% de tâches transversales :
MOA/MOE
communication
assurance qualité
formation
documentation
La dimension financière
quelques données simples
Dérapages quasiment systématiques => ne pas allouer immédiatement toutes les ressources
Estimation du délai : à la fin de la programmation (avant les tests), on est généralement à mi-parcours
La revue de conception et de programmation permet de détecter 50% des erreurs
Durée moyenne du projet = environ 0,5 * racine cubique (effort en hommes*années)
▬ Exemple :
▬8 h.a. => un an
▬27 h.a. => un an et demi
Productivité moyenne /personne/mois pour un projet de complexité
moyenne :
▬ 350 instructions
La dimension financière :
Coût, Qualité, Délais, Fonctionnalités
Le coût -> contraint par le budget du client
La qualité dépend des méthodes et des hommes
Le délai -> souvent contraint
La variable devient la fonctionnalité
Le plus grand risque : absence de méthode
Importance de la compétence (plus que des outils)
▬ Loi des 20/80 : 20% de l’équipe produit 80% de l’effort
Importance du planning : incluant des jalons internes et des jalons clients
Négocier les régressions de fonctionnalités au plus tôt = plus digeste
Vérifier la qualité du cahier des charges
Le cycle de vie des
Systèmes d’Information
Cycle de vie des SI
Concept analogue au cycle de vie d’un nouveau produit:
▬ Quel que soit le type de produit, il y a des étapes incontournables.
Ignorer une de ces étapes risque d’entraîner des retards et des surcoûts.
La dénomination des étapes diffère selon les auteurs et les entreprises mais la séquence des opérations est à peu près la même.
Modèles:
▬ En cascade: Le modèle en cascade représente le processus de développement comme un processus linéaire avec possibilité de retours arrières. Chaque étape est caractérisée par un ensemble de produits à livrer et s’achève par une phase de vérification/validation.
▬ Vérification: S’assurer que les résultats fournis par une étape correspondent bien à ceux attendus par la suivante.
▬ Validation: S’assurer que le produit est conforme aux besoins et exigences de l’utilisateur.
▬ Par prototypage: S’oppose aux méthodes de développement traditionnelles (type cascade). L’objectif:
▬ Raccourcir le cycle de développement en livrant rapidement une ébauche du système, avec les fonctionnalités principales.
▬ Le prototype est amélioré/complété de manière incrémentale en fonction du feed-back des utilisateurs (démarche participative).
▬ Exemple: méthode RAD (Rapid Application Development: développement rapide d’applications)
▬ Autres: V, WW, X, Y
Cycle de vie des SI : modèle en cascade
Etude préalable Analyse
Analyse des besoins
Conception logique
Conception physique
Codage et tests
Mise en œuvre
Conception
Programmation
(développement)
Mise en œuvre
Cycle de vie des SI: modèle par prototypage
ETUDE DE
FAISA-
BILITE
spécification des besoins et analyse
CONCEPTION
PROTOTYPE
IMPLAN-
TATION
VALIDATION ET TEST UTILISATION
des données et des programmes
corriger et compléter les besoins
commence avec le chargement des données inclut la maintenance
déterminer le coût et l'efficacité de différentes alternatives de conception et les priorités entre différents
composants du S. I.
comprendre la mission du SI et les
problèmes qu'il doit résoudre
implantation simplifiée pour vérifier que les
phases précédentes sont OK
Cycle de vie des SI :
la démarche de développement par prototypage
Identification des principaux
besoins des utilisateurs
Développement rapide du
prototype
Expérimentation du prototype
par les utilisateurs
Feed-back des utilisateurs
Prototype « jetable »:
Poursuivre le développement
par une méthode conventionnelle
Modification du prototype
Développement évolutif:
Compléter et documenter le prototype
pour obtenir le système final
Amélioration itérative
du prototype
Cycle de vie des SI: maintenance
Phase cruciale.
▬ Peut représenter, au cours du temps, le double des coûts
de développement.
3 types de maintenance:
▬ Maintenance corrective: correction d’erreurs (bugs).
▬ Maintenance préventive: anticiper les erreurs
▬ Maintenance évolutive: adaptation à de nouveaux
besoins, à des changements de l’environnement, à de
nouvelles règles de gestion,à de nouvelles architectures
matérielles et logicielles, etc.
Cycle de vie des SI : qualité du logiciel
Spécificités du produit-logiciel
▬ le logiciel est un produit complexe
▬beaucoup de modules
▬beaucoup d’opérations différentes possibles
▬ le logiciel est un produit obscur
▬défauts non visibles à l’œil nu
▬ leur détection nécessite des tests
Spécificités de l’environnement de production
▬ contrat coût-délai-fonctionnalités
▬ coopération étroite avec le client
▬ travail d’équipe nécessitant une coopération et une coordination interne et externe
▬ interfaces avec d’autres logiciels
▬ taux important de rotation des équipes
▬ nécessité de maintenance du logiciel pendant plusieurs années
Cycle de vie des SI: causes des erreurs
Définition incorrecte des besoins
Mauvaise communication entre le demandeur et le
développeur
Modification délibérée du programme
Erreurs de logique
Erreurs de codage
Tests insuffisants
Erreurs dans les procédures
Problème Conséquence pour le “client”
Définition insuffisante des besoins
* Ecart entre l’attendu et le livré * Insatisfaction du client
Pas d’estimation des ressources
* Attentes irréalistes par rapport à la faisabilité du projet
Planning inexistant ou succinct
* Pas d’échéancier pour la livraison du produit
Méconnaissance
des risques
* Client non préparé aux risques liés au projet et à leurs conséquences
Cycle de vie des SI : les risques (1)
Problème Conséquence pour le développeur
Définition insuffisante des besoins
* Changement constant des demandes du client
Pas d’estimation des ressources
•Dérive des coûts
•Frictions dues aux demandes de “rallonges”
Planning inexistant ou succinct
•Pas de contrainte de délai •Dérapage dans les délais et la qualité
Méconnaissance
des risques
* Prise en compte tardive des problèmes
Cycle de vie des SI : les risques (2)
Cycle de vie des SI : 10 risques de Boehm et Ross
Développer des fonctionnalités non correctes
Délais et budgets irréalistes
Interfaces utilisateurs non adaptées
«Plaqué or »
Arrivée incessante de changements dans les demandes
Défauts dans les composants externes
Défauts dans les développements externes
Défaillance du personnel (« turnover »)
Performances système insuffisantes
Limites des possibilités techniques
Phase du projet Pourcentage moyen de défauts
générés
Coût moyen relatif d’élimination
du défaut
Spécification des besoins 15% 1
Conception 35% 2.5
Codage unitaire 30% 6.5
Intégration 10% 16
Documentation 10% 40
Test du système ----- 40
Exploitation ----- 110
Cycle de vie des SI :
estimation des coûts liés aux défauts