Les Systèmes d’Information · Systèmes d’information opérationnels (SIO) Environnement...

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


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


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 ?


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


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 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.


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


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.


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


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


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


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


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


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


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


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


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

Les Systèmes d’Information · Systèmes d’information opérationnels (SIO) Environnement...

Documents

Transcript of Les Systèmes d’Information · Systèmes d’information opérationnels (SIO) Environnement...